preface
Substrate Contract Book is used to introduce Substrate contract system related knowledge. This book is led by Patract (patract.io/) and written by Aten (github.com/atenjin). … Github.com/patractlabs… New Window), we welcome people with lofty ideals to contribute to this book.
This book is mainly introduced on Pallets -Contracts (namely Wasm contract) as the main body. Therefore, the contents of this book include:
- Contract platform (module) running contract
- Pallet-Contracts
- Write the language of the contract
- ink!
- Ask!
- Solang
- Tools to help contract development
- Redspot
- Europa
- Elara
Pallet-EVM (EVM/Solidity system contract) has rich pallets in Itaipan ecology, so it will not be explained in this contract. Other pallets, such as Palm-Actor, or Libra, are in their early stages of research, so they won’t be the focus of this book.
In order to make contract developers better understand how Palm-Contracts and Wasm contract work, this book will also cover some introduction of Wasm and the introduction of blockchain contract model.
Contract model
Now that we have the concept of contracts and contract sandboxes, we can begin to discuss the concept of a contract model.
The contract sandbox simply represents the environment in which the contract is run, and how the contract works, interacts with the contract, and interacts with the data in the chain, are problems of the contract model.
In other words, the contract model is what model the contract runs in the contract sandbox/virtual machine.
As shown in the figure, the contract model and the contract virtual machine are essentially decoupled, where the relationship only exists whether the contract virtual machine can support the contract model required by the upper layer, for example:
1.Bitcoin virtual machine is the stack executor of Bitcoin script. Since the executor design is not Turing-complete OP_CODE, the upper contract model can only support Bitcoin script.
Following Bitcoin’s inspiration, Ethereum designed a Turing-complete OP_CODE, or EVM Virtual Machine. However, EVM OP_CODE is relatively simple, and only the design of stack, there is no concept of heap. However, EVM introduces OP_CODE for reading and writing state, so the state model can be supported by the contract model from the virtual machine mechanism. Thus EVM is also seen as a state transition machine that performs state transitions (as described in the Ethereum Yellow Book by Gavin Wood).
In fact, the state model is a relatively general abstract model, and most of the models can be simulated by the state model (such as building UTXO model in the state model). Therefore, theoretically, as long as the OP_CODE of EVM continues to be improved, the upper layer of EVM can also build other contract models.
3.Libra believes that the core of blockchain is the processing of assets, so it proposes Move Virtual Machine to define the contract model from Virtual machines, which can be understood as a specialized logic of OP_CODE collection. Therefore, the upper layer of MVM can only run the Move model.
From the above discussion, we can realize the concept of contract model, and understand the restrictions of virtual machines on the upper contract model, so next we can discuss the contract model for Wasm VIRTUAL machines to run and the contract model for Palm-contracts.
Wasm virtual machine
Wasm is a binary instruction format for a stack-based virtual machine running it WebAssembly
is a binary instruction format for a stack-based virtual Machine, from webassembly.org/).
Therefore, Wasm’s model structure is similar to that of mainstream computer programs. On the other hand, Wasm was designed to be a more general form and WASI was designed to support the runtime environment to define the Host Function freely. Therefore, although Wasm evolved from the browser, the current usage scenario is no longer limited to the browser, starting to calculate on the edge, hot update, Serverless platform takes effect.
If the ability of a virtual machine is measured by the completeness of instructions, EVM is in the degree of semi-finished product, with many restrictions and not flexible enough. While THE JVM, Wasm virtual machine is relatively complete, less restrictions, strong functionality. On the other hand, the rationality of instruction design will also affect the execution efficiency of virtual machines to a certain extent, and the implementation scheme adopted by virtual machines will also have a great impact on the execution efficiency.
For example, EVM can only be run as an Interpreter, and the current implementation process body (Go, C++, etc.) does not see any optimizations for the Interpreter. The execution efficiency is relatively low, while JVM, Wasm and other virtual machines are implemented in JIT mode. The execution efficiency is quite high and even close to the performance of local execution.
Note: Palm-Contracts currently only use Wasmi (interpreter) for Wasm code, so the performance of the contract is not as good as that of the Runtime using Wasmtime.
Meanwhile, compared with other VMS such as JVM, Wasm VMS are LightWeight, fast, and highly customizable. Besides, Host Function provides a channel for Wasm VMS to interact with hosts. Therefore, compared with other VMS, It is easy to combine the Wasm virtual machine as a blockchain contract sandbox with the capabilities of the chain.
On the other hand, in my opinion, Wasm is a better abstraction layer between the bottom code and the upper code, and its complexity and completeness are far more than EVM, so it is more suitable for the needs of the blockchain contract field.
Therefore, the sandbox environment provided by the Wasm VM also meets the following two requirements:
Complete instructions, rich functionality, high execution efficiency there are appropriate interfaces to interact with the host (here refers to the environment running Wasm, namely chain), so that the host can provide the required functions.
Contract model of EVM
Since Ethereum is a blockchain that stores state, it makes sense that EVM’s contract model requires basic state reading and writing capabilities. If you think of each contract run as a process from the start of the program to the end of execution, then the change in the state data corresponds to the change in the data that the program needs to persist. Therefore, ethereum EVM provides SLOAD and SSTORE instructions for read and write states.
On the other hand, Ethereum uses “account model” to describe an account, which means that both the contract and the user calling the contract are regarded as one account. Under this account, there are concepts such as Balance. Therefore, EVM provides CALLER, ORIGIN, CALLVALUE and a series of instructions to describe this model.
At the same time, in EVM’s abstract system, the contract is considered consistent with the user, so the model of “contract CALL contract” appears, namely, CALL, DELEGATECALL and other instructions, which brings the combinability of the contract and creates a thriving ecosystem of Ethereum. In EVM, a contract runs on one EVM, so a contract invocation contract starts another EVM in one EVM and loads instructions for execution.
Of course, the original intention of EVM virtual machine is to solve the non-Turing complete problem of bitcoin script. In order to solve this problem and ensure that downtime does not occur, the Gas charging model of instructions is introduced. Therefore, it can be concluded that the EVM contract model has the following characteristics:
1. The data processing model is a state machine model, and the state change is triggered by external call (analogous to the process of calling the state change function); 2. Chain dependent features are needed in contract models; 3. Treat the contract as consistent with the user and allow the contract to invoke the contract; 4. Introduce instruction charging model.
Pallets contract model
Palm-contracts use Wasm virtual machines to execute code, but their contract model is basically the same as EVM contract model.
That is to say, the contract models of Palm-contracts also have the following four characteristics:
Data processing model is the state machine model; Chain dependence is needed in contract models; Allow contracts to invoke contracts by treating contracts as users; Introduce instruction accounting model.
On the basis of the above four features, the storage Lease Model is added:
- Rent Storage lease charging
It has been stated above that the environment and contract model of contract execution can be decoupled. Since EVM was designed earlier without the concept of decoupling, SLOAD, SSTORE and similar chain-related instructions are combined with other EVM instructions. Wasm was not designed for blockchain, so there must be no instructions related to the chain environment.
So Wasm’s Host Function is used to do just that. The chain, as the Host, simply provides the Wasm VIRTUAL machine with the methods it thinks the contract will use to import these function objects and use them during the execution of the contract. Therefore, through Host Function, palm-contracts contract modules can have pallets 1,2,4 and provide some functions required by pallets 3. At the same time, the fifth feature (rental and charging) can also be introduced.
In addition, the implementation of the third Function is consistent with EVM. When the contract calls the contract, Host Function is used to return palm-contracts from Wasm to the module, and a new Wasm VIRTUAL machine is started to execute the invoked contract. (This section will be described in a future article)
So in summary, the contract model of Palm-contracts has the following characteristics:
1. The contract model is consistent with the CONTRACT model of EVM, and storage charging model 2 is added on this basis. The interaction with the chain is implemented through Wasm’s Host Function feature
Implement other contract models using the Wasm virtual machine
Palm-contracts are ready for Implementation On Wasm VMS. Since VMS and contract models are decoupled from each other, palm-Contracts can be implemented on Wasm VMS as well.
For example, we can consider porting the Move vm to the Wasm vm as well. There are two possible implementations:
1. Analog to the IMPLEMENTATION of EVM running in the Wasm environment of Runtime, you can compile the implementation of MVM into Wasm (for example, named Pallet-MVM) and run it in Runtime Wasm.
Based on this implementation, Move will still compile in the normal way and run on pallets -EVM in accordance with the Solidity compilation, while Move will run on pallets -MVM for example.
2. Abstract the characteristics related to MVM, ownership and chain at one layer, make them into the form of palm-contracts, and design the intermediate code IR compiled by Move language to Wasm.
With this implementation, you can compile Move into Wasm and run it in the Wasm VIRTUAL machine.
Other Contract Models
EOS contract model
EOS’s contract model is similar to EVM, while reinforcing the concept of an account model. So the way EOS uses Wasm is also based on Wasm execution and introduces chain-related functionality through Host Function.
The main difference between EOS and EVM model lies in that the process of EOS contract calling contract is called in the form of transaction, and EOS resource model is mortgage model. The current consensus is that it was EOS’s mortgage model that ultimately prevented EOS from becoming a success.
Asynchronous contract model
Palm-actor is the beginning of Pallet’s attempt to realize asynchronous contract model, and pallet has not made much progress at present. Pallet – Actor model is going to use Wasm virtual machine as the environment, and on this basis, add asynchronous features to improve performance.
At present, there are a few other studies on asynchronous contract models, but they are in a relatively preliminary stage.
About Patract
Patract provides solutions for parallel chain and DApp development in boca’s Wasm contract ecosystem. We help the community design and develop on-chain contract module and Runtime support, and provide DApp developers with a full stack of tools and services covering the development, testing, debugging, deployment, monitoring, data provisioning, and front-end development phases.
How to join Patract
1. For contract developers, visit the official website (Patract.io) to familiarize yourself with the test chain and tool suite. Element (app.element. IO /#/room/#Pat… Discord (Discord. Gg/wJ8TnTfjcq)
2. For parallel chain projects that will integrate Wasm contract functions, or DApp projects developed using Wasm contract, please contact [email protected] for business cooperation
3. For users, welcome to join: Telegram (t.me/ Patract) Twitter (twitter.com/PatractLabs…
4. For job seekers, we are recruiting blockchain development engineer, front-end/full stack development engineer, developer operation and other positions, you can contact [email protected]