Ask Me Anything with LiquidApps CTO, Tal Muskal — #TALAMA:
EdgeOS, Immortal dApps, Interoperability, DAPP Network on EVM, and LiquidChains
The text outlined below was derived from the transcript from the #TALAMA session in the DAPP Network Telegram channel on August 9. Some minor edits were made for conciseness and clarity. For full context from the entire AMA, we suggest listening to the audio version on the LiquidApps YouTube channel. Each question listed below also contains a direct hyperlink to the timestamp on the audio relating to it.
What is EdgeOS and where did the concept for it originate from? (00:3:00)
EdgeOS evolved from early services from the DAPP Network, LiquidDocker and generic services for computation and running and offloading resources for applications, offloading it from blockchain. It started from that, and the ability to run arbitrary applications that you can control or govern on the blockchain, but it doesn’t run on the blockchain. The blockchain only verifies the integrity of everything, and what you would expect from governance, like approving upgrades, and fixing bugs. It evolved to be an architecture for building the next generation of peer-to-peer applications.
Back in the early internet, we had pure peer-to-peer applications like immune or torrents or these kinds of protocols. They lacked a component of consensus. Obviously, before that we had server-client architectures. Then we moved to blockchain, where the state is agreed by everyone. And, because it requires finality and the consensus on the state, it’s kind of slow and bandwidth is very low, and it’s very costly. So, EdgeOS is trying to bridge those two worlds and provide fully immortal applications where only the governance aspect is on the blockchain.
EdgeOS is the operating system that all the components are running inside. It’s a POSIX compatible operating system that you can see is kind of a Docker replacement that can run in the browser.
What are some of the products you envision being able to be built using EdgeOS? (00:07:00)
I think any service that you could imagine running on a conventional cloud, whether it’s Facebook or a search engine — any web service or product that would normally need servers.
So it could be social networks, it could be blogs, it could be any service that the users can control the product. So imagine, if you remember, in the early days of Facebook, the service was more about a platform for other applications. It slowly evolved, not because of censorship, and not because it’s what the user wanted. It was the only way they could monetize, by making it a much more closed platform. It’s a good example where the users would want to control the system and not because of censorship.
What would a peer-to-peer web app look like where the end users themselves are distributing the front-ends and the backends of the web app itself? (00:09:44)
There we see it as a kind of hierarchy. You have the high level, which is the governance, which decides what all the nodes in the systems are running. There is this EdgeDSPs, which coordinate everything according to the blockchain and what happens in the governance. And there’s nodes, which are divided into two classes, kind of like the early peer-to-peer applications. There are super nodes and nodes, where nodes with high bandwidth and high uptime are automatically promoted to supernode.
What is the difference between EdgeOS and EdgeDSP? (00:11:05)
EdgeOS is the entire operating system. Most of the new components are running on it — the super nodes, the nodes, and the EdgeDSP.
EdgeDSP are the entities that provide services from the blockchain where the consumers are contracts and it’s provisioned by DAPP token. So EdgeDSP is one use case of EdgeOS, or one application that we already started building.
Will EdgeOS/EdgeDSP be available for ordinary DAPP Network community members to offer services? (00:12:21)
With EdgeOS, you could probably use it without even knowing just by browsing a service website that utilizes the technology. EdgeDSP is just like legacy DSPs. They require some knowhow in EOS accounts. registering packages, and all of that. But unlike a full DSP, it doesn’t require a full EOS node, which is much lighter, much less expensive.
Could some of these complexities be abstracted through some sort of community portal or frontend interface to make registering EdgeDSPs simpler? (00:13:35)
Sure, sure. It could be as easy as interacting with any website that uses either MetaMask or an EOS wallet.
Will EdgeDSPs be able to run EOSIO LiquidChains? (00:14:14)
Yeah, potentially. I can’t imagine it will run heavy types of chain, but you could definitely run a blockchain node inside EdgeOS. I call it a mini chain.
Once you get the costs and the maintenance and the barrier of entry, I don’t see a reason not to run your company or your group’s infrastructure on that. Instead of running things on AWS or having to trust someone specifically with keys.
Will LiquidChains be EVM compatible? (00:47:37)
We touched a bit about mini chains; I would really want to see EVM mini chains. Obviously, it’s not the first thing in the backlog, but any chain that’s being developed right now, whether it’s small or large, private or public, I think it all should be EVM compatible. I think there is no point in not re-using everything that’s been done, and there aren’t really hard blocks there. EVM specifically has a bad rep, first because it has a new paradigm that it introduced. The second problem with it is that it’s considered very inefficient. EVM by itself is not really inefficient, it got a bad rep for being very inefficient. You could get it to be just as fast as EOSIO, and we’ve seen it with the EOSIO EVM.
It’s very fast and it’s using the EVM. I think it’s a good example where EVM can really shine without really coupling it to the consensus or to the way the blockchain itself works. It’s just the runtime. Just because of the network effect, I think any blockchain should support it as a first class citizen.
Using EdgeDSP, can we run Docker containers? Could it be used for Docker containers with some high end GPUs to run AI models? (00:15:50)
So regarding GPU, not yet, but we use WASM instead of the Docker container as it’s much more efficient. It can run in a browser environment as well and it’s much more portable and they’re both POSIX compatible. Everything is containerized or sandboxed, but using WASM containers and not WASM processes, so not Docker containers, per se.
Would there be any incentive for traditional applications running on cloud to move to a EdgeOS strictly for cost savings? Do you envision it being cheaper than traditional services? (00:20:48)
I think if you offload most of the work on the users, it could potentially save 99% of the cost. You just need proper coordination, depending on the type of application. If you have enough users in your site all the time, you could potentially just utilize them. We’re even contemplating a new business model, where if you have too much traffic, or you have too much computation or capacity on your users’ devices, you could sell it to sites that don’t have it and create a network to balance that.
With a lot of other bridges popping up, why do you see DAPP Network bridging as superior to its competitors? (00:22:17)
I think where all the other bridges are right now is where we were a couple of years ago, the first iteration.
I think we’re now in the third iteration already. And God knows there’s a lot of lessons learned. I do hope they are not relearning those lessons. Besides having more maturity and being more battle tested in terms of how much the tech is in production, there is also the aspect of bridges usually being very specific. There’s a lot of nuances for a bridge. We provide the tools to address all of them, we’re kind of an SDK that allows you to build any of those types of bridges.
We’ve seen many people come to us that want help with bridges and for some of the blockchains they’re interested in connecting, there’s already a bridge, sometimes even an official bridge such as Binance. However, it usually doesn’t fit their requirements and no other framework really allows you to customize those details to your needs as a developer.
An example would be the impermanent loss protection for Bancor, for example. There’s a lot of nuances that are very specific to Bancor, and they require you to own the bridge or have special permissions on the chain for that bridge to issue tokens on demand according to what it owes the users with the impermanent loss protection. So it needs to allow you to mint tokens on both sides.
Another good example is not exactly token bridge, but bridges for NFTs. There are a couple of standards in all of the different chains. That’s a classic example for something that requires customization because there isn’t a single standard.
A few months ago, you mentioned a model where DAPP could potentially be used as gas… Can you provide some additional information about that and share what is the path to introducing this model? (00:30:24)
One of the things we’re heavily working on right now is that kind of architecture that I described earlier where only the governance is on-chain with super nodes and nodes. Also, to introduce a time-based gas model, but we still need to define a global pricing mechanism for all of these things.
We can’t really have it on the same free market basis like it is today. That’s one thing we can do now as with the DAPP Network governance. I think we discussed it in one of the calls before, which was to have DSPs that are “official” who are selected by the governance to run the core services at the same price. That’s two things that we’re working on.
It would use a “Nexus” contract on each chain that holds all the processes that are running in all the different nodes. So that’s the on-chain component, and it also handles the provisioning. It consumes the gas according to how much time a process is running. Since spawning and killing processes are all done on-chain, the contract knows how much time has passed, and how many processes were running in-between. It’s a convenient model in that sense, and the Nexus only coordinates those things. It’s kind of like a process list in a task manager, but on-chain, for all the different devices. It can be deployed on any Ethereum compatible chain that has the DAPP token on it. It handles all the gas pricing for the processes and you can spawn any WASM POSIX process through it, for any of the listed DSPs.
You would send DAPPs to a deposit contract and then you can dispatch commands to it. All of the nodes are constantly listening to the chain. Every time there’s a new process, they’re running it. The way I see it, is that staking will stay for EOSIO, but EVM will probably only use the gas model. Obviously, it’s all open for discussion and there’s the governance model to decide.
Which DAPP services do you think will be most useful for Ethereum DeFi and why? (00:36:54)
I think oracles, randomness, bridges, storage. These are all the basic ones that are obviously useful for any blockchain application, but also for any DeFi application. Also, usually the DeFi applications are running on servers besides the blockchain. They usually communicate with some kind of a server that does the indexing and processing of the information that’s too heavy to be processed on-chain, and so I would say a big percentage of the software is not really decentralized or running on blockchain, even in DeFi projects. I think they could definitely adopt more and more decentralization in that aspect.
What are some of the differences between using DAPP Network for Ethereum compared to EOSIO? (00:38:11)
The DAPP Network evolved to be a layer where you can do anything that you want to do in a decentralized way beyond what can be done in a typical smart contract on the blockchain. Usually blockchains are not efficient enough to run all the parts of your setup. So the more inefficient the blockchain is, the more those kinds of complimentary services are needed and are crucial. Things that we could do on EOS, we can’t necessarily do on Ethereum in terms of the gas prices. Things like complex queries that are not even complex, but they’re still much more complex than what you have on Ethereum compared to what we are currently used to on EOS. The less efficient the blockchain is, the more help is needed.
I think the need is much, much bigger. Not specifically for the services that we started with, not specifically for vRam, just because resources are priced differently. The idea of offloading a lot of what you do, from the contract to a secondary network of nodes — I think that’s more useful. That’s a lot of the principle of second layers. So that’s why Ethereum needed a second layer in the first place.
What is an Immortal dApps and what are some specific use cases that you envision being built? (00:41:17)
The first kind of immortal dApp that I encountered was the piracy torrent indexing sites. The Pirate Bay ecosystem, let’s call it. I think that’s the first really immortal application that I encountered, in the sense that as long as people want it to be alive, it’s alive. It uses a lot of techniques. It’s way before the blockchain, so it uses a lot of techniques to accomplish that. But theoretically, anything could be like that. Anything could be something that could stay forever.
Now that the world is discovering NFTs, and what you can actually do with them and starting to build dynamics around them, I think that kind of vision comes back very strong. With collectibles, it’s very, very important that you could show it to your grandson, especially if you paid a lot of money for it. So, the lifespan and that kind of immortality is very important when you’re talking about NFTs. That’s a reason why I don’t think current NFT applications are really immortal. Like the token itself is on-chain in some cases, also in IPFS, the images and the resources, but you have an entire front-end and usually a backend to get it going.
In many cases, it’s not even possible on Ethereum if you want to do a lot of calculations and it’s very expensive. I think that’s the demand. We should see it rising for things like digital assets that you could own forever. With NFT’s it’s all about the context. The industry itself isn’t worth anything, if it wasn’t for the group that gave it the subjective value. Part of that subjective value is what you can do with it, the website that allows you to interact with it. So if there isn’t a destination that even shows you your NFT anymore, it doesn’t matter if it’s on-chain. It’s not immortal; you wouldn’t be able to show it to your grandchildren.
I would like to know what you think will be the risks that the internet might face in the future? Can immortal dApps potentially give us the tools to create a free environment for social interactions? (00:45:34)
I think the answer is in the question. Our freedom is at risk. We touched on it at the beginning of this call. Facebook was a very good example. As users, we got demoted in the experience. The experience degraded, and it wasn’t for us, it wasn’t what the users wanted, and it wasn’t a regulatory issue. It was purely because we are the product and not the consumer. They turned us into the product instead of the consumer. That happens almost in any new unicorn that’s based on traffic for KPIs. Eventually, the users become the product. That’s something that can’t really happen with proper decentralization. It doesn’t mean that things are immutable forever. It just means that the users are deciding where the platform evolves.
Who are some of the customers for the DAPP Network that the community may not be as aware of as the more common ones like DeFi projects such as Bancor? (00:54:35)
I think there’s two types of customers. One, there’s the enterprise customer that wants to get involved in blockchain, for one reason or another. We’ve seen some of those. They come and go according to the hype of the market, whether it’s a bull market or a bear market. From time to time someone cracks an actual killer application, like recently with NFTs or DeFi.
So an NFT is, I think, a really good example of something that we’re just beginning to scratch the surface with the use cases, and almost anywhere you look, you will need to be able to scale those different components. Currently, the demand is much, much bigger than what those systems can handle. We’re not actively looking for the killer applications, but we’re obviously seeing them popping out more candidates bringing it to the mainstream.
I hope NFTs will be the thing that makes more people be aware of the tech and what it allows and why all of us crazy people have been building this stack for years.
With new kinds of paradigms, you need to experiment with new kinds of business models. I think what’s lacking for that is a business model that doesn’t rely on a central entity. The more we feel liquidity for and acceptance for cryptocurrencies, the more you can imagine sites that actually make money but they’re not controlled by a single entity. So it’s also kind of a chicken and an egg with liquidity.
Which services can be offered with EdgeOS and at what iteration are you into on the repo for EdgeOS and EdgeDSP? (01:04:44)
Since we released the OS itself, the alpha version, we’ve kind of changed the focus a little bit to try to make it fit specific applications that can potentially be adopted. We don’t want to port every one of the services. Some services don’t make a lot of sense to port in the first place. Oracle’s and Randomness, what we call LiquidHarmony type services. Those are services that we want to see running on EdgeDSP. As I mentioned in the beginning of the call, there are still a couple of gaps in the pricing and having it fit a more holistic architecture. That’s what we’re focused on right now — the ability to build completely immortal applications that are not really reliant on blockchain resources for scaling.
If you install WASI SDK and the WASI end, it could take any application that runs under POSIX without the UI, for example. Any command line or any UNIX process, take the code and compile it with SDK. If it’s successfully compiled, then you could run it on the browser and direct with STD in and STD out just like you would with the UNIX process. There’s even scripts. If you want to play with it, feel free to ping me while you’re on it. Anyone — if you’re doing sessions with our alpha things and adopting early, feel free to ping me anytime.
Once you compile something to EdgeOS, you could upload it to IPFS or to LiquidStorage and then have an IPFS link for it. Then with a Nexus contract, wherever it’s deployed, you can run that IPFS binary with parameters, with arguments. That’s what makes it the DSP. You run arbitrary processes, and you pay for the time as gas in DAPPs. So any process that runs on EdgeOS can potentially become a DSP service. Any processing, you can compile to it, you can offer it as a service, and EdgeDSP could run it. You don’t need to coordinate with them.
As a user tomorrow morning, you can write something, a new kind of service. Something that holds keys, custodian, cheap, whatever you want. Just select DSPs and run it on those DSPs. The only caveat for that is for storage. It’s probably not a good idea to price storage. It shouldn’t be time plus bandwidth. Very similar to EC2 to the Amazon cloud in the instance.
Hopefully we’ll be able to dog food it enough so there’s plenty of references and you won’t need to reinvent the wheel.
DAPP Network
Voting Portal | DSP Portals | Github | Documentation
DAPP Network Telegram| DAPP Network Gov | DAPP Network Devs
