3.8.3 Virtual Machine Compatibility

One of the key interoperability patterns in the DGT ecosystem is the compatibility of virtual machines. Virtual machines serve as execution environments for smart contracts, enabling developers to create decentralized applications that can run on the blockchain. This compatibility at the level of smart contracts is vital for fostering a versatile and accessible development ecosystem that can accommodate a wide range of applications.

In the realm of blockchain, there are two predominant types of virtual machines - the Ethereum Virtual Machine (EVM) and WebAssembly (WASM):

• Ethereum Virtual Machine (EVM): The EVM is a powerful, sandboxed virtual stack embedded within each Ethereum node, responsible for executing Ethereum’s smart contracts. With its Turing-complete scripting language, the EVM can run scripts of any algorithmic complexity. The EVM only supports Solidity as its native language.

• WebAssembly (WASM): WASM is a binary instruction format designed as a portable target for the compilation of high-level languages like C, C++, and Rust. WASM is designed to be a low-level virtual machine that runs at near-native speed by taking advantage of common hardware capabilities.

DGT, being a fork of Sawtooth, has inherited the support for two important transaction families - SETH (EVM compatible) and SABRE (WASM compatible).

• SETH, or Sawtooth Ethereum, provides an EVM implementation on the Sawtooth platform. It interprets the EVM bytecode and interacts with the state in the blockchain. With SETH, developers can deploy and run Ethereum smart contracts on the DGT network.

• SABRE, or Sawtooth Sabre, defines a framework for executing smart contracts compiled to WASM. It allows smart contract developers to use a variety of programming languages, offering greater flexibility and opening up the DGT ecosystem to a wider developer audience.

Creating, deploying, and executing smart contracts on SABRE in the DGT network generally involves the following steps:

Step	Action	Description
1	Developing the Smart Contract	The first step involves writing the smart contract in a language that can be compiled into WebAssembly (WASM), such as Rust, C, or C++. The smart contract contains the business logic that will be executed on the blockchain.
2	Compiling the Smart Contract	After the smart contract is written, it needs to be compiled into WASM bytecode. This bytecode is what will eventually be deployed to the DGT network.
3	Creating a Transaction Family for the Smart Contract	The compiled smart contract is then packaged into a Sabre "smart contract" (not to be confused with the smart contract code we wrote earlier) that includes metadata like the contract's name, version, and the inputs and outputs it will access.
4	Deploying the Smart Contract	Next, the Sabre smart contract is included in a "ContractRegistry" transaction and sent to the DGT network. If the transaction is valid, the smart contract will be added to the DGT's global state, and it's ready to be used.
5	Creating an Instance of the Smart Contract	Before the smart contract can be executed, an instance of the contract needs to be created in a "NamespaceRegistry". The instance (also called a "NamespaceRegistry") specifies the permissions for who can use the smart contract and which parts of the state it can access
6	Executing the Smart Contract	Once the smart contract is deployed and an instance is created, it can be executed by creating a "ContractRegistry" transaction that references the smart contract's name and version and includes the inputs and outputs for the execution. The transaction is then sent to the DGT network, where it will be routed to the Sabre transaction processor.
7	Verification and Finalization	The Sabre transaction processor will verify the transaction, execute the smart contract, and if everything is valid, update the state accordingly.
8	Reading the Execution Results	The results of the smart contract execution can then be read from the updated state on the DGT blockchain.

In terms of their implementation, both SETH and SABRE operate as transaction families within the DGT ecosystem, just as they do in Hyperledger Sawtooth. They handle specific types of transaction requests, enabling the execution of EVM or WASM compiled smart contracts on the DGT network. Each transaction sent to the DGT network is routed to the appropriate transaction processor (either SETH or SABRE) based on the transaction's family name, version, and namespaces.