Start Deploying and Exploring Now

TL;DR:
In preparation for ShimmerEVM, today we are launching the EVM test chain on the Shimmer Testnet. This test chain aims to improve the resilience and performance of a public smart contract chain with multiple validators to get everything well tested and polished for the ‘real’ ShimmerEVM chain: if bugs are found, they will be fixed and thereby make the actual release better

Today we’re happy to announce the launch of the ShimmerEVM test chain on the Shimmer Testnet. The introduction of the EVM chain on the testnet is another step in expanding the reach of the interoperable and highly scalable Shimmer protocol to a broader community of blockchain users and developers who build EVM-compatible smart contracts.

Starting with what we affectionately call “Magic Smart Contracts” (which enable seamless and bridgeless native asset transfer between Shimmer L1 and EVM chains that build the basis for extended EVM compatibility) and covering the most important changes to the node software, the following summary addresses all changes, improvements and the next steps in preparation of the ShimmerEVM launch. The launch of ShimmerEVM on the testnet precedes its highly anticipated release on the Shimmer network and brings with it a wide variety of new possibilities and access to unique features available in the Shimmer protocol.

Considering the importance of ShimmerEVM for the Shimmer and IOTA ecosystems, and the fact that in the near future tokens worth hundreds of millions of dollars will be exchanged, traded, and bridged from other networks to the Shimmer network, we wanted to invest extra time to ensure the security of the network. This is why the refactoring of the codebase, several audits, and countless hours of internal testing were crucial to be confident about the network's stability and safety.

In this public testnet phase, we (together with our dedicated community and dozens of dApps) will further test and validate the ShimmerEVM, helping to find bugs or improvements to be made. This will help expedite the launch of ShimmerEVM on the Shimmer network in production, which is why we invite everyone to participate. We are incredibly excited about this major step on our roadmap and look forward to bringing the power of smart contracts to a DAG-based ledger.

What’s happened since the last update?

Over the last four months, the IOTA Smart Contract team has been working on improving the first Shimmer-compatible release of IOTA Smart Contracts (ISC) on several fronts, mainly focusing on getting the node software ready for usage on a real network with developer experience, reliability, security and recoverability to match.

Consensus refactor

Arguably the biggest change in Wasp (our smart contracts node implementation) since its last release has been a major refactoring of the consensus-related modules. The consensus modules consist of logic that enables a group of validators (the committee) to form a consensus (agreement) without having to assign a leader to decide on what the next state update of the smart contract chain will be.

This might sound quite straightforward but it’s pretty complicated, things like deterministic selection of transactions from the mempool, synchronization with other validators, ordering, chain rotation, Layer 1 anchoring, distributed key generation, common coin implementation, and reaching an agreement, amongst a lot of other details. The previous version of the consensus modules worked but was quite hard to debug and understand. It evolved from the GoShimmer-based Wasp version (running on the IOTA 2.0 prototype) to the Hornet-based Wasp version (running on the Stardust protocol on Shimmer), refactoring a lot of traces from early versions. To improve these points and to be confident about these crucial components working towards ShimmerEVM we could not cut corners and we’ve spent quite a bit of time on proper refactoring.

Historical state lookup

Another important change made to the node software is that we now support looking up the historical state of smart contracts and not just the most recent state. This is now implemented on both ISC and EVM levels and allows us to run a proper block explorer and indexation services on EVM chains, something not previously possible.

To get to this point we needed to step away from having a dynamically updating key-value store for storing the state of a chain towards a very different design where the state is stored read-only in a sparse Merkle tree. This allows efficient state storage without the overhead of keeping track of the complete state of every block, which would quickly escalate storage requirements. This major change took a while but is very much needed given that a smart contract chain without a proper block explorer isn’t transparent enough to be useful.

Extended EVM functionality

EVM compatibility also received a nice upgrade focused on adding convenient support for using Shimmer native assets from L1 on an EVM chain as if they were ERC20 tokens (for native assets) or ERC721 NFTs (for L1 NFTs). We implemented several interfacing contracts that allow you to use native assets deposited to a chain directly within EVM without losing the flexibility to seamlessly transfer those assets back to L1 if desired. This eliminates the need for custom bridges within the Shimmer ecosystem.

The documentation provides the details needed to use this new functionality but to summarize:

  • We now support transferring the SMR token as if it’s the native token of the EVM chain, and we provide a wrapped ERC20 of this as well for convenience.
  • We offer interface contracts for native assets represented as an ERC20 token on the EVM chain, individual NFTs as ERC721s, and NFT collections also as ERC721 collection contracts without having to write and deploy these contracts yourself.
  • This is in addition to what we call the magic EVM functionality, which, like the native randomness and interacting with ISC/L1,  we’ve already offered previously,.

We’ll make more improvements to the developer experience of this functionality over the next weeks.

A brand new API, used by a new dashboard and CLI implementation

This latest release also introduces a new API utilizing the OpenAPI specification standard. This allows us to fully automate the generation of documentation for the API and its client libraries in almost every programming language imaginable. With this new API, we introduce a more versatile, standard-compliant, and consistent replacement for the previous version. In addition, the API supports new functionality like directly calling smart contract call-views through the API, user management, and node/peer management.

To accommodate the new API we have made a completely new dashboard for Wasp that runs standalone next to Wasp and that now comes as an optional image. Along with a new and improved look, we’ve added more functionality such as the newly introduced user management, and the management of peers and access nodes.

The CLI tool has also had a makeover, utilizing the new API and generated client libraries with added convenience. We are still making some improvements to this tool to make node management even easier: you can expect this update during the next few weeks.

Given how interwoven the API, CLI, and dashboard were in the previous release, these changes have been considerable. Lots of code has been touched to get to this point and, as a first version, we are expecting some potential new edge-case issues here and there when using the CLI or API. We’ll further improve these new tools over the next few weeks and are looking forward to your feedback to make it even better. Please start a new GitHub issue for this if you come across something we could still improve here.

Reliability, compatibility, and recoverability

In the last several months, we worked closely with the Hornet team (going as far as adopting a Hornet team member) to implement their learnings from building and maintaining Hornet into Wasp. Thanks to this, we were able to improve our codebase substantially while also working towards a more cross-team shared codebase using Hive.go for overlapping functionality. Support for running a production-grade Wasp node using Docker with a local Hornet setup and all the extra tooling you might need was added to the node-docker-setup project as well, making it a breeze to set up a good node infrastructure.

Next to this, we worked on many improvements throughout the code to improve the overall experience, ranging from small usability fixes in the Wasp CLI tool to many more automated tests to ensure a consistent experience while using ISC. Next to automated testing we also manually tested Wasp during several team-wide exercises, running and managing our own test chain as well as allowing community projects to have a sneak peek and provide us with feedback on what we should pay more attention to. There is still a lot we could improve on, but we have already made giant steps and are looking forward to receiving more feedback soon from your experience with this new Shimmer Testnet.

How to use the new testnet

The easiest way to get started is to connect to our public node infrastructure through Metamask. You can use the EVM toolkit to add the testnet to your Metamask settings at the click of a button, request some testnet SMR through the Faucet and start interacting with any deployed dApps – or deploy your own!

Chain details

You can monitor the chain using the block explorer. Over the next few weeks, several community projects will promote their work and come up with exciting test exercises that will demonstrate what can be done on ShimmerEVM, allowing you to experiment with and get a preview of what’s to come. We’ll publish more on this soon.

We offer a faucet service for several common simulated bridged tokens (fETH, fBTC, fUSDT, etc.) on the testnet, which enables you to experiment with these assets. We encourage dApps to use these tokens instead of their own simulated bridged tokens, as this will ensure compatibility and interoperability across different applications without requiring a swap. The ERC20 simulated token faucet can be found here.

The Shimmer Testnet runs on a setup with several committee nodes and a few access nodes. Only the access nodes are publicly exposed for interaction. This setup closely resembles how the ShimmerEVM setup will look and is designed to continue operation even if several nodes fail at the same time (unlike previous testnet setups). Resets or halted chains are big threats and it’s our goal to avoid them at all costs. We can test and improve on this by running and stress-testing the network together with you.

The ShimmerEVM testnet is connected to the Shimmer testnet, so please ensure that you use the latest BETA version of the Shimmer Firefly wallet if you plan to interact with L1 functionality. More information can be found here.

What’s next?

We want our community developers to start deploying their amazing projects and work with the community to battle-test our testnet. The feedback and insights we can gain from this are crucial to getting to a point where we can be confident about launching ShimmerEVM.

In parallel with this effort, we’re still working on several improvements that will be rolled out for the duration of the testing phase, including:

  • More improvements to the Wasp-CLI that make it easier to use for anyone managing or developing on a chain.
  • Performance fixes.
  • Further improvements in the reliability and recoverability of chains.
  • Improved documentation.
  • More flexibility when it comes to chain management.
  • Whatever might come out of testing and much more!

Links in this article

Follow us on our official channels for all the latest Shimmer news:
Discord | Twitter | LinkedIn | Reddit

Follow us on our official channels for the latest updates:
Discord | Twitter | LinkedIn | Reddit | CoinMarketCap

Tags

Shimmer

Official posts from the Shimmer Network.

Recommended for you