Shimmer will be the first network to realize the full capabilities of IOTA’s Stardust upgrade. This will include on Layer 1 a powerful framework for tokenization (including NFT Wallets), output types to script transaction conditions (e.g. unlock functions, timelocks, etc.), among other native protocol performance improvements. On Layer 2, the IOTA Smart Contracts (ISC) framework will launch for the first time with full smart contract support through WebAssembly and EVM-compatible smart contract chains. Any dApp from Ethereum or other EVM-chains can thus be easily ported over to the Shimmer network.
The Smart Contracts framework of Shimmer already offers multi-chain capabilities for anyone to deploy their own smart contract chain and benefit from the feeless and trust-less interoperability provided by Layer 1. What this means is that dApps can deploy their own chain on Shimmer to unlock the full transaction throughput for their applications, while users can freely and securely transfer assets cross-chain without having to worry about bridge security, fees or significant time delays.
While this will open up Shimmer to new levels of scaling by going multi-chain, there are still significant shortcomings to the current solution that are worthwhile to mention. Most notably, each smart contract chain is permissioned or semi-permissioned as the validators of a smart contract chain are pre-selected by the creator of the chain (e.g. the dApp team). This significantly increases the trust requirements of a smart contract chain, as the security is dependent on the integrity of the chosen validators. Even though validators can be replaced, there is no staking, slashing or similar mechanism implemented yet to make the validator selection fully decentralized. (FYI, that is exactly where Assembly comes into place, as it makes the smart contract chains fully decentralized and permissionless).
In order to allow our emerging dApp ecosystem to safely bootstrap during the initial growth phase before we scale towards a multi-chain solution, we intend to launch Shimmer with one (or several) community-governed ShimmerEVM chains. The ShimmerEVM will empower the community to easily deploy and scale their dApps without having to worry about the security of the underlying network or the integrity of the validators.
When launching Shimmer, scalability will not be our biggest concern. The biggest concern is actually building and growing our emerging dApp ecosystem. During the early bootstrap phase of Shimmer we have to maximize dApp composability, compatibility with tooling and infrastructure (e.g. Block Explorers and Wallets), and increase network security. dApp builders should worry about their dApps, and not worry about the underlying infrastructure they build on.
We will therefore deploy a single EVM chain - called the “ShimmerEVM” - which will become the main EVM smart contract chain deployed on Shimmer. The ShimmerEVM will be fully community-governed, with trusted community members / projects validating the chain. This will make the ShimmerEVM similar to other Proof of Authority chains (e.g. Polkadot during launch, VeChain, etc.).
The ShimmerEVM will be a highly performant public smart contract network with fast transaction speed and very low and reliable fees. It will be accessible to anyone to publish their smart contracts or to deploy nodes to validate and verify the network.
Summary overview of the ShimmerEVM
|VM||Ethereum Virtual Machine (with performance improvements added), hosted through the IOTA Smart Contracts framework|
|Consensus||Honey Badger BFT (HBBFT)|
|# of Validators||12|
|Validator selection||Based of Proof of Authority (Public Identity at stake of validators)|
|Block times||Several seconds|
|Finality times||10 seconds|
|Fees||Dynamic fee, which will be raised at times of congestions|
The total number of validators securing the ShimmerEVM initially will be 12. While in theory this number could be higher, we propose to bootstrap the ShimmerEVM with 12 validators, and later scale up this number if needed.
Validators are special nodes that create the blocks that will be added to the ShimmerEVM chain, and will then be anchored into the Shimmer ledger. In a 12 validator-set, a single node is randomly selected to propose the next block. If this block is approved by a majority (2/3) of the Validator-set, it is included in the Blockchain. The responsibilities of the validators in the network include securing and confirming transactions, operating the ShimmerEVM, connecting with community nodes, performing chain upgrades and performing validator rotation (upon DAO approval) if needed. Obviously one of the most important responsibilities is running the validator nodes and the underlying server infrastructure.
Choosing the 12 validators needs to be done carefully, as the performance and uptime of the entire network are dependent on every validator to reliably run their server infrastructure. Even though the node requirements are fairly low, it is a big responsibility to become a chosen validator of the ShimmerEVM and requires the necessary skills. Not least because the public identity of that validator is at stake.
I would propose to divide the validators into 3 categories (Community Projects, Corporate Partners, IOTA Foundation). From each of these categories we will initially select the most trusted and reliable partners to become a validator of the ShimmerEVM. At a later stage, these validators can either be replaced or expanded if need be.
Proposed validator distribution:
Community (4 Validators)
- RockX (Staking Provider)
- Other community projects to consider: TangleBay, HiveRoad, EinfachIOTA, GreenDLT
IOTA Foundation (4 Validators)
- Smart Contracts
- Spice (Staking Provider)
Corporate Partners (4 Validators)
- Dell Technologies
- Software AG
- ETO Group
- Energie Knip
The validators are selected because of their reputation and standing within our ecosystem. They therefore stake their identity and reputation. Any misbehavior or performance degradation of a validator will be tracked, allowing the entire network to act and take certain repercussions (such as replacing the validator).
Even with ⅓ of validators failing, the chain will still be secure. Only if 2/3 +1 is dishonest, the chain can be attacked. Validators can be replaced at any time through a majority vote of the remaining validators, or through decision by the chain owner (which will most likely be a DAO).
Apart from the more obvious parameters of the ShimmerEVM such as block times we also have a very exciting discussion around token economics. In particular, fees, incentives and rewards in the network.
While the Shimmer network will be feeless on Layer 1, the ShimmerEVM will require fees to be able to operate. The fees in the ShimmerEVM will be significantly less than on Ethereum and highly competitive against other L1 smart contract networks (Fantom, Solana, etc.). The transaction ordering in each block is done randomly, which will avoid MEV or bots manipulating transactions.
The fees in the ShimmerEVM are not used as incentives for the validators. Which in turn means that we can use the accrued fees paid for smart contract execution as rewards within the network or as incentives for certain network participants.
There has been some interesting work done by other EVM chains, and I highly encourage you all to read about them. For example, EVMOS introduced gas rebates, while MetisDAO distributes fees as rewards to dApps.
Apart from fees, we can also make use of the close to 8% inflation which will be introduced in the Shimmer network for staking rewards. For example, a portion of the inflation in Shimmer could be used to give fee rebates in the ShimmerEVM.
(Note: This list is just a starting point. If you have any ideas, please share in the comments below. I will then add it to the list here).
|Burn transaction fees||Fees will be burnt, effectively helping to reduce the token supply. This was first introduced in Ethereum through EIP 1559, and is quite common in other networks (such as Avalanche).|
|Allocate fees to Community Treasury||Part of the fees will be transferred to the Community Treasury, empowering the community to vote on how to allocate the fees (grants, token buy-back programs, etc.). This is something that is for example used in Polkadot.|
|Share fees as rewards to active dApps||Part of the fees in the network will be distributed to the most active dApps. This will give developers a further reward to be successful in the Shimmer ecosystem. An objective metric to measure (which would be difficult to cheat) would be gas usage by a particular dApp.|
|Fee rebates from SMR inflation||A portion of the inflation in $SMR could be used as fee rebates in the ShimmerEVM. These fee rebates would have to be carefully defined, most likely designed at helping to on-board new users.|
The EVM is limited to about 25 TPS, while the IOTA team has added some performance improvements to the EVM itself (without breaking compatibility), we will certainly hit the throughput limit if we are successful with our ecosystem growth. Luckily we have a potential short-term solution to this problem, as it will be possible to expand the ShimmerEVM beyond a single chain.
Therefore, if the transaction throughput in the network will be reached or transaction fees increase too high, we could deploy additional EVM chains operated by the same, or a different validator set. While these additional EVM chains will not break composability and interoperability, they do complicate things with the user experience (bridging assets cross-chain), the tooling and infrastructure. These issues are manageable, and our teams are already starting to prepare to host additional EVM chains on Shimmer.
The ShimmerEVM will be a community-governed EVM chain on Shimmer, ensuring maximum security, composability and the perfect user experience. There are important discussions we need to have on who will be the first validators of the ShimmerEVM committee, as well as make a decision on the tokenomics of the ShimmerEVM. There are interesting combinations of Token Burn, Fee Reward Share and Fee Rebates that we can introduce to make Shimmer a competitive Layer 1 smart contract network.
I would like to get feedback on the community on the following topics:
- ShimmerEVM validators and the proposed initial distribution
- How should the fees in the ShimmerEVM be distributed?
- Which of the new incentive / rewards ideas should we introduce into the ShimmerEVM (fee rebates, fee distribution to active dApps, etc.)