Exploring Dymension
Dymension is a settlement layer for Cosmos SDK rollups that use Celestia or other DA layers as a data availability layer. Thanks to Celestia's modular approach through Data Availability Sampling, Dymension can support low latency RollApps with different execution environments.
RollApps are built with Dymint and an application framework, just like a Cosmos SDK app-chain but without Tendermint, and they point to the Dymension Hub for settlement/consensus. In this blog post, we will explore the value proposition of Dymension, and why RollApps matter.
Glossary
AMM (Automated Market Maker): A decentralized exchange mechanism facilitating liquidity provision and price discovery.
eIBC (Escrow IBC): An IBC-based protocol facilitating trust-minimized and instantaneous token transfers across optimistic RollApps, addressing issues like the Verifier's Dilemma and enabling instant withdrawals.
Optimistic Rollups: A type of rollup that assumes transaction validity unless proven otherwise, utilizing a system of fault proofs to settle disputes, offering scalability and EVM compatibility.
RollApps: Application-specific blockchains within Dymension's ecosystem, allowing for scalable execution environments without consensus overhead, with the Dymension Hub serving as the settlement/consensus layer.
Rollups: Scaling solutions for blockchains like Ethereum, moving transaction computation off-chain while retaining data on-chain, typically implemented through optimistic or zk rollup designs.
RDK (RollApp Development Kit): A set of generic modules enabling compatible Cosmos SDK functionality for deploying RollApps on Dymension's settlement layer, simplifying development and deployment processes.
Sequencer: Node operators bonded on the Dymension Hub responsible for producing blocks on a RollApp, akin to validators in PoS blockchains.
ZK Rollups: A type of rollup relying on cryptographic proofs for transaction validity, though more complex and less EVM compatible than optimistic rollups.
The problem to solve
To understand the core ethos of Dymension and why they’ve built an ecosystem around RollApps (which we will define later on), we need to first address what rollups are, and then we will be able to introduce why RollApps might solve a crucial dilemma.
Why would we need a rollup on the first place? In the case of Ethereum, committing to the actual layer one has its upsides and cons. You get access to a lot of liquidity, but users will incur into a high transaction cost. However, it has been known for a while that Ethereum’s roadmap includes scaling through a set of layer 2 blockchains built on top of it.
Each block on Ethereum can only house a certain amount of data, limited at around 50 tps. Rollups are considered one of the safest solutions for scaling Ethereum, leveraging its security, and keeping some data per transaction onchain, while keeping the computation off chain, to layer 2 protocols. Rollups use smart contract to take transaction computation outside the Ethereum network, shape them into batches, and publish them back into the network. That’s the work of a Sequencer.
This does not come without issues however. Choosing a type of rollup (optimistic, zk rollup) is the first topic that arises. Optimistic ones are easier and fast, and allow for EVM compatibility, but as their name implies, they're optimistic in the sense that they assume that state changes are valid unless proven wrong, and there's a whole system of fault proofs to settle any disputes. ZK rollups rely on a completely new and cryptographic proof, but are more complex and less EVM compatible.
Another added layer of complexity comes with liquidity fragmentation between rollups, Ethereum layer 1, and the fact that optimistic rollups can take up to two weeks to complete withdrawals to the layer 1, due to its fault proof system.
Furthermore, an additional complexity not often expressed in optimistic rollup designs is the Verifier’s dilemma, which is defined as the observation that there’s no point in checking somebody’s work if you know they’re not going to cheat; but if you’re not going to check then they have an incentive to cheat (there is a follow-up article here). We want to take into account:
Checkers might be cheating (bribed)
Checkers might not be incentivized to check.
Surprisingly, this worsens if more checkers are added, as the chance of it being profitable diminishes with more checkers if the asserter (sequencer) is honest.
And this is where RollApps come into play with Dymension.
RollApps
When you withdraw from a rollup, who is validating the state of the rollup? That’s the settlement layer, in the case of Optimism/Arbitrum that would be Ethereum mainnet. In the Dymension ecosystem, the Dymension Hub is the settlement layer for all RollApps. In short, they execute transactions off-chain and post data and state updates on-chain. With the data posted, anyone can submit a fraud proof and earn slashing rewards in case of a fraudulent state update.
Dymension compatible rollups (from this point on, RollApps) write the transaction data to a data availability layer, while publishing the new state on the settlement layer. This reduces the efforts of each validating node participating in the network. Now each computer doesn’t need to process every transaction. As such, by moving the computational efforts off-chain, nodes with less computational power can keep up with high amounts of information re-processing and participate in the consensus of the network.
The Dymension team has developed the RollApp Development Kit (RDK)is a set of generic modules which enable compatible Cosmos SDK functionality, such as creating accounts and token management, and simplifies the process of deploying rollups on top of dymension’s settlement layer.
RollApps are Dymension’s solution to scaling. They are application-specific blockchains minus the consensus overhead, leaving just a highly scalable execution environment. The IBC-enabled hub allows for a connection to all other IBC-enabled chains, as well as communication between deployed Dymension RollApps, creating greater network effects as more applications are deployed.
RollApps operate under fraud proof design allowing for greater scale and relying on just one honest participant for a well functioning system. One honest participant means that only one actor needs to prove that a malicious action was committed by the RollApp sequencer and if so the sequencer gets slashed. Dymension’s validators are responsible for maintaining the current state and handling any fraud disputes or malicious RollApp sequencers.
eIBC
First presented in the video below, there’s still little documentation which can be found here. Since Dymension’s RollApps are optimistic, the key takeaways are:
eIBC (short for escrow IBC) is an IBC based protocol to facilitate trust minimized and instantaneous token transfers across optimistic RollApps.
Introduces a workaround to try to solve the Verifier’s dilemma as well as instant withdrawals.
With a certain set of assumptions outlined in the documentation, the eIBC protocol is explained as follows:
With two involved actors (Alice, a user on a RollApp; Bob, a relayer in the IBC), eIBC wraps a standard pending finalization IBC message from RollApp to settlement layer (which will confirm post-dispute window) in order to achieve instant trust minimized transferring. As a wrapper, the protocol introduces a similar flow to the IBC protocol in which Alice submits an eIBC transaction on the source RollApp, and Bob relays the message from the RollApp to the settlement layer where it's verified. If Bob decides to fulfill the request, he sends the required tokens to the eIBC middleware module on the settlement layer, which in turn instantly delivers the said tokens to Alice on the settlement layer and re-routes Alice's original pending IBC message to Bob's address.
An interesting dynamic is also introduced in the document, in which a third user Carrol is introduced, which is an investor looking for a return on her capital:
Bob decides to create a “verifier liquidity pool”, that utilizes those tokens on the settlement layer to provide instant liquidity for eIBC users for a specific source RollApp. Since Bob runs a full node of the RollApp, he will actively submit a fraud-proof in case of any fraud.
Carrol decides to pool her funds with Bob’s pool for the RollApp.
Alice submits an eIBC transaction from the RollApp requesting to withdraw tokens (e.g. 10 DYM) and is willing to pay 1 DYM to do so.
Bob relays the eIBC message from the RollApp to the settlement layer where it’s verified, and the liquidity pool can provide liquidity to Alice delivering the tokens to the eIBC module.
The eIBC module distributes the escrowed tokens to Alice and re-routes her original pending finalization tokens to Bob’s LP (10+1).
Carrol is able to withdraw profit from Bob’s LP.
This way, Alice can receive her requested tokens instantly. Verifier pools however also entail risk for liquidity providers who must trust in the verifier’s ability and integrity.
The eIBC protocol addresses both the verifier dilemma and the fraud proof window. We will have to wait, however, until RollApps are live and more documentation is available, since resources so far are limited in this regard, and a few questions arise. If a user wants to withdraw DYM from a RollApp to the hub, in order for him/her not to wait for the fraud proof period, a user on the settlement layer can "clear" it for a fee. If for any reasons no user wants to perform that action, how does the fraud proof period work? How long does it take?
Dymension RollApp Standards
As a settlement layer, Dymension needs the ability to verify RollApps with ZK proofs or fraud proofs. They recently announced a standard to abstract away blockchains:
- DRS (Dymension RollApp Standards) with fraud proofs, enabling verification of RollApp state and standard chains. It is the equivalent of ERC tokens.
They are RollApp execution environments which are registered via governance on Dymension, and they can either be a chain template with a popular VM, or custom built using the RDK. Once they're approved by governance, anyone can permissionlessly use a that standard to deploy a RollApp, removing the need for multi-sig smart contracts.
Liquidity fragmentation and the role of $DYM
Dymension uses an embedded Automated Market Maker (AMM) designed to expose RollApps to efficient asset routing, price discovery, and most importantly shared liquidity for the entire ecosystem. Dymension protocol incentivizes these pools along with RollApp deployers.
Node operators bond assets on the Dymension Hub for the right to produce blocks on a RollApp (i.e. to become a sequencer). Sequencers receive block production rights similar to validators in Proof-of-Stake (PoS) blockchains.
As defined in this blog post, the following assets are eligible for sequencer bonding:
Native DYM: Sequencers are able to bond Dymension Hub’s native token (DYM) for the right to produce blocks on the RollApp.
RollApp token: Enabled by Dymension Hub’s AMM, sequencers will be able to stake the native token of a RollApp once approved by the Dymension Hub’s governance.
LP DYM / ROLLAPP token: Dymension Hub’s native protocol token DYM is required to be established as the base asset of liquidity pools to be eligible. The other side of the liquidity pool may be the RollApp’s own native token.
RollApp governance
The RDK enables application developers to utilize NFTs, SBTs (Soul-bound tokens), delegation to addresses, and other creative means of separating governance obligations from block producers.
Governors have full control of on-chain governance and value accrual mechanisms such as fee collection, token minting, and NFT royalties.
RollApps can have a single deployer or different approaches depending on their criteria. As in DPoS, governors can receive delegations from holders, and in return delegators receive shares. Therefore, transaction fees and block rewards are shared amongst governors, delegators, and sequencers.
Finally, RollApps are required to publish transaction data and state updates on-chain. Costs of publication are incurred by the sequencer. Expenses for sequencers may be broken down into the following categories:
State updates
Data publication
RollApp bonding
Sequencers publish state updates to the Dymension Hub. Sequencers may utilize either DYM or the RollApp’s native token to pay for transaction fees on the hub.
Closing thoughts and challenges
In some ways, RollApps are similar to App-chains. They become connected and independent chains creating a network, they are also application-specific, and they too have their own token which can be used to pay for network fees. The SDK for rollups is the RDK. But, as much as they are alike, there are still a few major differences which constitutes the reason for their creation.
They allow a higher throughput, lower latency and substantially easier bootstrapping than any monolithic blockchain. However, there is a tweet by Jon Charbonneau which shows a rather interesting cycle, where an app on a general purpose chain might want more sovereignty, so they might launch an app chain, which over wants more value capture, becoming a general purpose chain, and successful apps built on top of it might want more sovereignty.. you see the point.
A network of interconnected fast RollApps with high liquidity might be able to break that cycle. On top of that, an additional challenge is both adoption and competition. Rollups on Ethereum seem to be doing fine and thanks to recent developments, they might become cheaper and scalable, and settling on Ethereum is a well established procedure for L2s. Building awareness and fostering adoption of the Dymension ecosystem, including RollApps and the Dymension Hub, among developers and users will be crucial.
