We are thrilled to share our latest development update. Our team has made advances in different aspects of the project, such as implementing our unique Volatile Virtual Machine, providing a handy API fetch_contracts to access on-chain contracts and benchmarking in preparation for the t3rn MVP.

‍Volatile Virtual Machine Implemented‍

A considerable step forward for the t3rn project has been the implementation of our Volatile Virtual Machine. Volatile VM is used by the t3rn Circuit to run received smart contracts and change the execution context between the three following execution modes:

• Dry-run: static contract analytics and producing actionable calls metadata. 

• Pre-run: produces outbound messages instead of executing contracts locally. Those messages can be then submitted to foreign consensus systems and dispatched onto Gateways

• Run - regular smart contracts run on Circuit, if no outbound information is necessary to be dispatched into Gateways. This mode is no different from industry-standard smart contracts VM.
  
  

The Volatile Virtual Machine is based on the WASM Virtual Machine implemented by Parity as part of the Contracts Pallet. Keyword Volatile is there to stipulate the VM’s unique mechanics - destined for foreign execution contracts that are not stored and run locally, but necessary for dispatch messages that are being produced and signed instead. From the VM, the messages are ready to be relayed onto appointed foreign consensus systems. This was a nontrivial task that required considerable development efforts and signals a huge step forward in the development of the t3rn product. ‍

Upgraded Gateways introduce split execution to follow the gateway protocol into several methods and also upgrade the previous implementation (Dev. Phase 0) to the latest version of Substrate - FRAMEv2. ‍

Integrated pallet-multifinality-verifier with pallet-xdns in order to provide fresh data about active gateways.

This task was a core part of delivering an interoperable solution that enables the discovery of potential gateways across different blockchains. It involves creating a functional interface between pallet multi-finality-verifier, a product responsible for handling block finality across different consensus mechanisms and pallet xdns, which is developed to serve in the future as the on-chain smart contract metadata and analytics registry. 

The use-case that we had in mind when allocating time to this task was to provide optimal execution paths between all kinds of requested cross-chain operations. At this time, we set up the first integration point, in which every time a block is finalized and verified (coming from any compatible blockchain like Ethereum or Polkadot) is picked up by multi-finality-verifier, checking if any of our known gateways were involved in the block's transactions, and subsequently updates our metadata registry with important metadata regarding the transaction.

This process enables us to have an up-to-date repository of transaction fees, availability, and gateway 'quality'. This repository is then used to locate the best available gateways who shall be considered to perform cross-chain composite transactions in future blocks. Such a process can currently be found in aggregators and meta-transaction contracts, which aim to reduce gas fees and find paths of execution with minimal chance of failure.

‍The Road to t3rn MVP

‍The MVP is a major milestone for t3rn, wherein our team may test different features and integrations. A demo MVP is currently in progress, which will be followed by a cross-chain smart contracts hub. As a result, we will soon be able to begin integrating with partner projects and testing scenarios of composable smart contracts.

Integration testing using RPC API and benchmarking are an essential part of the MVP, as our team ensures that the entire product is usable and stable. After the testing phase is completed, we will begin integration with Internal Gateways with a few selected integration partners. - active Kusama Parachains, in addition to integration with Polkadot and Kusama with our External Gateways.

The Relayer logic has been put in place, as we cannot use the bridge-pallet-messages since it is synchronous, followed by the cover of pallets with benchmarks. Finally, the team can write integration tests by checking all the functionality of the RPC API, and implement these tests for the Circuit.

Significant progress has been made in the Circuit's benchmarking, beginning with the basic Benchmark suite implementation, followed by benchmarking on execution requests, confirmation steps and on-chain repository.

Be sure to watch updates on our social media and blogs.

👉 Subscribe to our newsletter: Join 15,000 subscribers for exclusive monthly updates and insights, directly from Maciej Baj, founder & CTO of t3rn. - no spam, unsubscribe anytime.