Stardust Ready, Extended EVM, and Much More
Today the IOTA Smart Contracts team is proud to release the latest version of IOTA Smart Contracts (ISC), version 0.3.0. This first fully functional version of ISC is compatible with the latest version of Hornet, paving the way to mainnet support and interaction with the new native tokenization features introduced with the Stardust release of the Shimmer/IOTA protocol.
What has happened since the previous release?
Last year, we released a fully-functional version of IOTA Smart Contracts based on GoShimmer, our experimental node software for the IOTA 2.0 DevNet, that is incompatible with the current IOTA mainnet. ISC was released together with a test chain to experiment with supporting Solidity smart contracts on a standalone EVM chain. This release brought a lot of excitement, given that there was something to work with on a working network resulting in new projects spawning up eager to work with ISC in the future. We learned a lot from this release and testnet and defined the following next steps:
- ISC needs to be mainnet compatible.
- EVM chains need to be able to access ISC/L1 assets instead of being completely standalone.
- We need better tools for Wasm-based smart contracts.
- We need a universal way to calculate gas-based fees.
- We need to ensure that ISC is reliable and recoverable at all times.
These conclusions are at the core of what we've been building for this release and we’re pleased to say they have all been addressed.
The biggest change in version 0.3.0 is the switch from using a GoShimmer-based network to compatibility with a mainnet-ready node software. GoShimmer is an experimental node software developed by the IOTA research department and was initially used for ISC because of the lack of smart contract anchoring support on the IOTA mainnet. Due to its experimental nature, the code for GoShimmer changed quite often, resulting in instability with ISC. But because GoShimmer is an experimental node software and we want to have smart contracts available on the mainnet as well, we decided to upgrade the mainnet’s Hornet node and underlying UTXO ledger to incorporate exciting new features first implemented on GoShimmer, such as aliases and Alias outputs. This upgrade is known as the Stardust upgrade.
In parallel, we upgraded the ISC node software (known as “Wasp”). While the concepts of ISC and the architecture of the Wasp node didn’t change much, a significant effort was required to implement and essentially completely rewrite the VM (Virtual Machine), now known as the StardustVM. The StardustVM incorporates all new features introduced by the Stardust protocol: aliases, NFTs, foundries, native tokens, and so on. It also brings EVM and Wasm support to the next level (more below). We also had to significantly modify the protocol between Wasp and the L1 due to very different approaches by Hornet and GoShimmer. This release will be available on the Shimmer Beta Network first, then Shimmer, and later on, once Stardust is also released to the IOTA mainnet, there too.
Extended EVM Support
GoShimmer added experimental support for EVM to ISC, allowing builders to run existing and new Solidity smart contracts in a proven way on top of ISC. This experimental version was a big success and attracted a lot of attention from builders and users excited to catch a glimpse of a potential DeFi ecosystem on IOTA. This release was a standalone EVM chain on top of ISC with no direct way of interacting between GoShimmer (the ISC chain) and the EVM chain on top of it, making it an interesting but not very useful or unique proposition. With this new release, we add a lot of new functionality on top of this implementation to make the EVM support a first-class citizen in ISC.
With the release of version 0.3.0, the EVM chain is started together with the ISC chain, and the JSON/RPC entry point for it is directly available as soon as Wasp runs. While the EVM chain still runs as a separate chain on top of the ISC chain it’s much more interwoven now. A “magic smart contract” which is always available on this chain can be called to interact with the ISC sandbox directly, allowing you to utilize all the goodies ISC can offer directly within the EVM chain (think of things like unpredictable random numbers without needing an Oracle, and moving IOTA/Shimmer native assets/NFTs from within EVM without needing to wrap/bridge them). This functionality allows the EVM chain to communicate outside of the chain and interact, through the IOTA/Shimmer layer, with other chains and even non-EVM chain smart contracts.
Next to this extended functionality we also made Ethereum addresses first-class citizens within ISC. This allows you to hold a native asset balance on an ISC chain controlled by your Ethereum keypair. What this means in practice is that you can use your existing tools and wallets like Metamask to access ISC functionality through the magic smart contract without needing a dedicated IOTA keypair/wallet, which should contribute to the user experience of using these EVM chains.
Firefly will allow native assets to be deposited to an Ethereum address on a chain and simplify the process of going from an IOTA/Shimmer balance in Firefly to a Metamask-addressable balance on a smart contract chain. For the sake of convenience, the token configured to be used for gas fee payments will show up in your Metamask balance as the ‘native token’. This means that you only have to check in one place to see whether you have enough gas tokens to pay for your transactions. (The native tokens on the EVM chain are currently not transferable through Metamask; we are considering this functionality and might add it at a later stage). We are working on improving this experience with more convenient EVM features for a follow-up release.
Improved tooling for Wasm-based smart contracts
The Wasm-based smart contract support has also received its fair share of love and attention. Numerous improvements have been made, including support for fee payments in gas, vastly improved schema tool support, and a newly generated client library for all three supported languages (Go, Rust, and AssemblyScript). The Wasm VM is now fully Stardust-aware and can use the new native asset functionality as well. We’ll continue to improve and document these implementations.
Introduction of gas and gas fees
In the previous release, there was no concept of gas in the VM. At the same time, paying fees for smart contract execution was a bit of a placeholder, where gas fees were used for the EVM chain and fixed fees for the Wasm-based chains.
Just like in any other Turing-programmable smart contract platform, ISC needs to apply the concept of gas and a gas budget to control and charge fees for execution time and other resources used during the execution of smart contracts. The Stardust release of ISC implements gas, a gas budget, and gas fees consistently and universally.
Paying gas for both Wasm and EVM-based smart contracts is calibrated and the operations will have a similar gas price for similar types of executions. We added functionality to the governance contract so a chain owner can decide in what token the fees are charged (it can be the base token of the chain used (Shimmer or later IOTA) or any native asset), how many tokens are charged per gas unit, and where the collected fees will end up (a ratio between the chain owner and validators). Gas is an important tool in smart contract chains as it protects the limited available computing power and incentivizes the entities running the chain: we believe that we now have a good answer to that with this implementation, allowing anyone to define gas fees themselves, consistently and universally.
Reliability and recoverability
One learning from the past release and (primarily) the public testnet is that the smart contract node software has to be reliable and able to recover from any potential issues that might arise, even if all nodes crash at the same time. We’ve had several occurrences where we had to reset the testnet because we ran into a very much undesired issue.
We resolved several issues during the initial weeks of the testnet and set up a workgroup that exclusively focussed on reliability and administrative tooling. This workgroup successfully implemented write-ahead logs (which ensure that, even if the state is lost on all nodes during a state transition, the node will be able to recover) as well as improved logging, additional metrics, plain text configuration for chains, secure key storage, and many other small improvements that contribute in one way or the other to node reliability and management.
We are constantly making improvements that count towards the reliability of the nodes and we hope to make additional improvements based on the learnings from anyone utilizing this release.
Why this release?
With this release, we want to prepare builders in our ecosystem for what is to come. With Stardust being ready, it’s only a matter of time before the Shimmer public testnet evolves into Shimmer itself and we want to be ready to start running smart contracts there. We are currently at a stage where everything is working, but still see room for improvement from a user experience perspective, which we will address in upcoming releases. We welcome your suggestions for improvement as well as learnings from using these chains in public. This way, we can offer the best possible version once Shimmer and, later, Stardust for IOTA are available.
In the meantime, we'll continue improving based on what’s still pending and your feedback. We will soon be releasing a public ISC testnet to tinker with. Meanwhile, everyone can now start running their own chain on the new Shimmer public testnet or your own private tangle, please refer to the documentation for more details. Please share your findings and thoughts with us using GitHub Issues and Discord so we can offer you a better experience once we are ready to launch chains on a mainnet.
After further improving and documenting this release we will go through all requested functionality and evaluate what we need to add for this and follow-up releases. Our main focus right now will be user experience improvements and reliability. Once we are satisfied with this we will re-evaluate our priorities and start working on exciting new features based on community demand. Let us know what you think and reach out on Discord for any feedback or assistance!