[Virtual Machine Column] An article to understand ava smart contracts - JVM on the chain
—— Introduction——
In the previous article, we introduced a detailed introduction to the history, characteristics, development, Solidity and EVM of the virtual machine. The emergence of Solidity and EVM has opened a new door for blockchain application scenarios, but contract developers use Solidity to develop smart contracts, and there is inevitably a problem of learning new languages.
So, is there such an old friend who can quickly integrate "contract developers" and "blockchain"?
As we all know, Java is a widely used, object-oriented programming language with the cross-platform feature of "write once, execute everywhere". Therefore, we invited Java to our blockchain platform, and developed a set of execution engine HVM that can execute Java smart contracts. The introduction of Java smart contracts into the blockchain mainly serves the following purposes:
*Reduce the cost of smart contract development, allowing contract developers to focus on the contract logic itself rather than grammatical details.
*Provide developers with familiar tools and methods suitable for blockchain scenarios, avoiding repeated "wheel making".
* Solve the problem of a single interaction mode between traditional smart contracts and ledgers, and provide a variety of more convenient and flexible data structures and methods for ledger interaction to better meet the needs of business scenarios.
text
text
From the perspective of a contract developer, the process of using a Java smart contract usually includes the following three steps: contract development, contract deployment, and contract invocation.
▲ Java contract development
Compared with traditional smart contracts, the development and use of Java smart contracts are simpler and more convenient, mainly reflected in:
1) Fast project construction: Developers only need to create a new Java project in the local IDE and import the contract development dependency package to develop the contract. After the coding is completed, the code is packaged into a contract Jar file and can be used for deployment on the chain.
2) There are many tools and methods: developers can use the classes and methods in the JDK to avoid the trouble of repeating "wheel making".
3) Low learning cost: The Java language is widely used, and most developers only need to understand the interface of the contract development dependency package to be able to use Java smart contracts proficiently.
▲Java contract deployment
For the deployment of Java smart contracts, the developer uploads the contract Jar package to the chain through a transaction, and the blockchain will initialize the contract, generate a unique contract address, and pass the contract address to the developer through the transaction receipt.
▲Java contract call
Developers can construct and send a contract call transaction by specifying the contract address and entering the contract method name and parameters. After the blockchain platform receives the transaction, it obtains a JVM instance, loads the class file in the contract Jar corresponding to the contract address into the JVM, creates an instance of the contract class and calls the specified method, obtains the execution result and returns it to the developer through the transaction receipt By.
——HVM Detailed Explanation——
▲ JVM access to blockchain
To implement a Java smart contract execution engine, the problem of connecting the JVM to the blockchain must not be avoided. At present, most blockchain systems are developed using Golang, and most open source JVMs are usually written in C++. If you want to quickly connect the JVM to the blockchain system, you can connect Golang and C++ through CGO. However, considering the need for internal optimization of the JVM in the blockchain system, HVM chose to implement the JVM through Golang. Although implementing the JVM by yourself will introduce a lot of development costs, it greatly facilitates the subsequent performance optimization and function expansion work for blockchain scenarios.
"When the JVM is connected to the blockchain, what else needs to be done to make the JVM the Java contract execution engine in the blockchain?"
▲Virtual machine security adaptation
As mentioned above, we support users to use classes and methods in the JDK in the Java contract engine of the blockchain. Considering that the contract execution engine on the blockchain needs to satisfy the isolation of the execution environment and the certainty of the execution results, we need to make a security adaptation to the JDK and JVM. These include the following:
1) Disable "unsafe" classes and methods: In the smart contract engine, methods that may cause inconsistent execution results are "unsafe". For example, the execution result of the random number method generated in Java is uncertain, and the Java contract engine in the blockchain will disable these "unsafe" classes and methods.
2) Isolate the execution environment of the contract: the Java smart contract in the blockchain platform needs an isolated execution environment, that is, the Java smart contract cannot use threads, networks, access system time and other functions like ordinary Java programs. In addition, we have implemented some blockchain-related methods in JDK, and some methods are not allowed to be called by Java contracts. Therefore, we implemented a method call filter inside HVM to intercept method calls that are not allowed.
3) Determine the logic execution sequence: Like EVM, we have implemented a set of Gas mechanism inside HVM to calculate the cost of contract execution. The difference in instruction execution will cause the Gas value calculated by different nodes to be different. In the original JDK, when some methods are called twice, although the result is the same, the code path of the logic execution is different. Taking a class using the singleton pattern as an example, when calling an instance method of this class for the first time, you need to create an instance of this class; when calling its method later, you no longer need to create an instance. This difference in logic will cause the gas value of the newly started node to be inconsistent with that of other nodes. Therefore, we need to adapt this kind of logic in JDK to ensure that the logic execution sequence is always consistent.
▲Ledger interaction mechanism
To connect the JVM to the blockchain, it is also necessary to ensure the function of the interaction between the contract and the ledger data. There are instructions for ledger interaction in the EVM, but there are no instructions for ledger interaction in the JVM specification, so we need to provide a set of ledger data interaction mechanisms so that Java smart contracts can operate ledger data on the blockchain.
There are two options for implementing the ledger interaction mechanism:
1) Implement a set of custom instruction sets for ledger interaction in the JVM. At the same time, a compiler or plug-in for Java contracts is provided to generate custom instructions dedicated to ledger interaction in the blockchain in the contract bytecode.
2) Implement a set of tool classes and methods for reading and writing ledger data in the JDK. During the contract execution process, the contract execution engine calls these methods to be responsible for the read and write operations of the contract persistent fields.
During the implementation of HVM, the second option was chosen. In the process of contract execution, if the persistent field of the contract is used, the contract execution engine will call the ledger reading method to obtain its data from the ledger. For the ledger write operation, the execution engine will cache first, and after the contract execution is completed, scan the persistent fields in the contract with data updates, and flash the updated data into the ledger.
Compared with the instruction method, using the Java method to realize the ledger data interaction function will have more instruction overhead, but it can provide users with a more friendly way to operate persistent fields. Taking Map as an example, we provide Map with methods other than Get and Put in the Java smart contract, allowing users to use iterators and other methods to easily operate Map. Considering the complex scenarios of reading and writing Maps, maintaining a reliable iterator logic is more complicated. To operate ledger data in the form of instructions, it is necessary to implement a complex set of ledger interaction instructions. Obviously, tool classes and methods are more suitable for completing these complex logical operations, and it is easier to support the expansion of contract data structure functions.
Through this scheme, users can choose a powerful data structure class operation ledger when writing Java smart contracts. These data structure classes encapsulate the Java methods of ledger interaction so that users cannot perceive them, and implement the interfaces in the JDK as much as possible. Data structures such as HVMMap and HVMList respectively implement the Map and List interfaces in the JDK, and are almost the same as other Maps and Lists provided by the JDK.
▲Comparative analysis of virtual machines
In addition to HVM contracts, common contracts include EVM’s Solidity contracts, Fabric’s Chaincode, and so on.
EVM provides a sandboxed, completely isolated contract execution environment. Solidity has been considered as a smart contract language from the beginning of design, and it has great advantages in book operations.
Fabric's Chaincode supports writing in multiple languages. Chaincode runs in a protected Docker container. After receiving the call request sent by the client, it will simulate the read and write set of the account book in the container and return it to the client. Finally, the client will initiate the simulated transaction again. Generate a request to write the read-write set to the ledger.
Compared with other execution engines, HVM has the following main features:
*The HVM contract is executed in a safe closed sandbox environment with high security
*Execution engine embedded in the platform, no network dependence
*HVM provides a complete contract life cycle management mechanism, and the contract can be upgraded only through sdk and api calls
* Provide rich built-in functions, such as log output, cipher suites, and diversified call contracts
In addition to the functions provided by the Java language JDK itself, HVM provides a variety of data structures based on blockchain ledger data operations
—— Summary ——
This article first introduces the development and use process of Java smart contracts from the perspective of developers, then explains the technical solution for accessing JVM in the blockchain, and discusses the code transformation of JDK and the realization of the ledger interaction mechanism. HVM is always groping forward towards the goal of better performance and friendlier user experience. At the same time, contract execution engines in the industry are in full bloom. Next, we will introduce in detail FVM, which supports Rust and other languages to write smart contracts, and KVSQL, which supports SQL execution on the blockchain. Stay tuned!
About the Author
About the Author
Lu Yiming, Yao Bing
references
references
[1] Java Virtual Machine Specification.
