Discussion on the design mode and upgrade method of intelligent contract in Ethernet workshop __ Smart Contracts

Discussion on design mode and upgrade method of intelligent contract in Ethernet Square 1. Best Practice 2. Practical Design Case 2.1 controller contract and Data contract: 1->1 2.2 controller contract and Data contract: 1->N 2.3 Controller contract and Data contract: N->1 2.4 Controller contract and Data contract: N->n 2.5 Summary 3. Upgrade 3.1 Controller contract upgrade, data contract does not upgrade 3.2 controller contract does not upgrade, Data Contract upgrade 3.3 Controller contract upgrade, data contract upgrade 4. Data Migration 4.1 Hard-coded migration method 4.2 Hard Copy migration method 4.3 Merck Tree Migration method discussion on design mode and upgrade method of intelligent contract in Ethernet square

Ethernet Square EVM is the most widely used virtual machine in block chain industry. The Intelligent contract language that it supports is Turing complete. The language supports a variety of base types (booleans,integers,address,string,enum,address, etc.), complex types (struct,mapping,array, etc.), Complex expression and control structure and interface inheritance, such as object-oriented characteristics.

Because of the powerful intelligent contract language, the complex business logic and application in the real world can be easily realized in the block chain. It should be noted, however, that although the public chain can achieve a reasonable gas mechanism for self-protection, the alliance chain can use other mechanism to replace gas calculation and token to protect EVM sandbox security, but because of the mechanism of block chain operation, the operation of intelligent contract even the abnormal operation will run independently on all block chain nodes. Therefore, whether it is in the public chain or alliance chain to run the smart contract is very expensive (computing resources, storage resources) operations.

In addition, there is a difference between a smart contract and a traditional application that an intelligent contract cannot be tampered with once it is posted on the block chain, and even if there are bugs in the smart contract that need fixing or business logic changes, it cannot be directly modified and republished directly on the original contract. Therefore, at the beginning of the design, we need to consider the reasonable upgrade mechanism combined with the business scenario.

In short, the realization of the intelligent contract to achieve the goal is: Complete business functions, strong code logic, good module abstraction, clear contract structure, reasonable security checks, complete upgrade program.

The life cycle of intelligent contracts is designed, developed, deployed, run, upgraded and destroyed. The following is mainly based on the objectives in the design phase, the upgrade phase of some of the carding summary. 1. Best Practices

From a business point of view, the smart contract only needs to do two things, one is how to define the structure of the data and read and write methods, the second is how to deal with data and provide service interfaces externally.

In order to better the module abstraction and the contract structure stratification, separates these two things, is not only separates the business control logic and the data from the contract code level, such processing in the complex business logic scene has been practiced is the current thought best pattern.

This mode is referred to as CD (controller-data) mode. The contract is divided into two categories: the controller contract (Controller Contract) and the Data Contract (information Contract).

The controller contract obtains data by accessing the data contract and makes logical processing of the data, then writes back to the data contract. It focuses on the logical processing of data and the provision of services externally. According to the different processing logic, the common namespace controller contract, agent Controller contract, business Controller contract, factory controller contract and so on. In general, a controller contract does not need to store any data, and it relies entirely on external input to determine access to the data contract. In special cases, a controller contract can store the address or namespace of a fixed data contract (obtain the contract address through the namespace at run time).

The data contract concentrates on the raw interface between data structure definition and the read-write of the stored information. In order to achieve the goal of data unified access management and data access control, it is best to expose the data read-write interface only to the corresponding controller contract. Other ways of reading and writing are prohibited.

Based on this model, follow the analysis from the top to the next, from the external service interface to design all kinds of controller contracts, and then gradually transition to the service interface required data model and storage mode, and then design all kinds of data contracts, can be more rapid completion of the contract structure design. 2. Practical Design Case

In CD mode, the operational relationship between the controller contract and the data contract is logically summed up to four categories: Controller contract and data contract 1->1 controller contract and data contract 1->n controller contract and data contract n->1 controller contract and data contract N->n

Suppose a business scenario: Chain the business and information of all the banks in the country. 2.1 Controller contract and Data contract: 1->1

Suppose there are only two banks in the country, bank A and Bank B. A bank only deposits business, B bank only withdrawals business. One possible design is this:

Agent controller contract: For Dapp, is the entry point for all business contracts, provides namespace services, and provides a mapping of namespaces to contract addresses. Allows Dapp to have no sense of address changes caused by contract escalation on the chain. For example, Dapp needs only ("Banka", Deposit,args) for a bank's deposit request. B Bank's request for withdrawals is only required ("bankb", Withdraw,args). Agent control contract implementation should be embedded in the bottom of the block chain, curing, or very few changes in the business. Dapp has a clear idea of the address of the proxy controller contract before the business runs.

Named controller contracts: chain-oriented contracts, providing namespace services that provide a mapping of namespaces to contract addresses. This allows the contract to obtain the actual contract address at runtime according to the name. For example, a bank controller contract requests to a named controller contract ("Banka-data") to obtain a bank data contract address so that a bank controller contract can access the a bank data contract at run time. The main difference between it and the agent controller contract is that the service object is different, the agent controller contract is oriented to Dapp, and the name controller contract is oriented to the chain contract. In addition, the naming controller contract contains a version-controlled design (described in section 3.2 below) that can be used to match the implementation of the grayscale policy.

A Bank controller contract: provides the deposit service interface deposit. When the deployment was initialized, it was clear that the identity was "Banka". And the address of the "Banka" Data Contract "Banka-data" can be obtained at runtime through a named control contract.

A Bank data contract: The current balance of bank A is saved. Provide the add and sub interfaces to the a bank controller contract to update the balance information.

B Bank Controller contract: provides the deposit service interface withdraw. When the deployment was initialized, it was clear that the identity was "bankb". And the address of the "bankb" Data Contract "Bankb-data" can be obtained at runtime through a named control contract.

B Bank Data contract: The current balance of bank B is saved. Provide the add and sub interfaces to the B Bank controller contract to update the balance information.

The process of deposit request for Bank A is this: dapp specifies the proxy controller contract address, request deposit transaction ("Banka", Deposit,money) the proxy controller contract, the runtime obtains "Banka" the corresponding a bank controller contract address, And to a Bank controller contract request deposit Trading (Deposit,money) a bank controller contract deposit interface to the naming controller contract request a bank of the data Contract "Banka-data" address, and access to a bank data contract data, and then carry out some deposit business logic. Returns the result. Returns the result to Dapp in turn. 2.2 Controller contract and Data contract: 1->n

Suppose there are n banks all over the country, all banks have deposits and withdrawals, and business processes are the same. One possible design is this:

The design is not the same as the 2.1 above, where both the deposit service interface and the withdrawal interface are summed up in the banking controller contract. This means that any bank's deposit and withdrawal operations are uniformly handled by a banking controller contract, which no longer logically distinguishes between Bank A or B, except that access to different bank data contracts is required in the context of data access.

Also, in 2.1, for Dapp, it only needs to send the request to a fixed "bank", not specific care of a bank.

In addition, because the banks have many, and their storage structure is the same, so you can design a bank data contract factory controller contract, to be responsible for the new data Contract generation implementation template.

The process of deposit request for Bank A is as follows: DAPP Specifies the proxy controller contract address, requests the deposit transaction ("bank", deposit, "Banka", money) the proxy controller contract, the runtime obtains "bank" the corresponding bank business controller contract address, Request for deposit trading (deposit, "Banka", money) to the banking controller contract the deposit interface to the named controller contract requests the address of bank A's data contract "Banka-data" and access to the data contract of bank A, Then execute some deposit business logic. Returns the result. Returns the result to Dapp in turn. 2.3 Controller contract and Data contract: N->1

Assuming that there are N banks all over the country, all banks have deposits and withdrawals, and business processes are the same, but due to the complexity of the business logic, the need for modular maintenance requires the separation of deposit and withdrawal operations. One possible design is this:

The design differs from the 2.2 above in that the Deposit service interface and the withdrawal interface are split into different business controller contracts. This means that different business logic makes a clear segmentation from the module. For Dapp, it needs to explicitly point to the corresponding business interface when it makes a request.

The process of deposit request for Bank A is this: dapp specifies the proxy controller contract address, request Deposit transaction ("deposit", "Banka", money) the proxy controller contract, the runtime obtains "deposit" the corresponding deposit business controller contract address, Deposit Business Controller Contract Request deposit trading ("Banka", money) deposit Business Controller Contract deposit interface to the named controller contract request a bank's data contract "Banka-data" address, and access to a bank data contract data, Then execute some deposit business logic. Returns the result. Returns the result to Dapp in turn. 2.4 Controller contract and Data contract: N->n

This type of situation can be disassembled into a combination of the above three cases. Don't repeat it. 2.5 Summary

From the Dapp point of view, can be summed up as follows:

CD Mode	features
1->1	Business-oriented objects
1->n	Business process oriented
N->1	Business-oriented interface
N->n	/

3. Upgrade

In CD mode, when the business logic changes need to upgrade the contract, according to the controller contract and data contract upgrade relationship to divide, can be summed up in the following three kinds of situations:

Controller Contract	Data Contracts
Upgrade	Do not upgrade
Do not upgrade	Upgrade
Upgrade	Upgrade

During the upgrade process, you also need to consider whether a full or gray level upgrade. If it is a grayscale upgrade, what is the grayscale policy? In addition, in the chain scene and the single chain scene, across the chain scene, the upgrade process is different. How to consider the gray strategy of the multi-chain scene. Whether the old and new versions of data coexist. If data migrations are needed, how do you migrate seamlessly?

The following are the most common 1->n scenarios for different upgrades. 3.1 Controller contract upgrade, data contract not upgraded

As shown in the figure above, the bank business controller contract is upgraded from V1 to V2, while the other contracts and interfaces are not updated, assuming that the V2 version is only upgraded withdraw this interface relative to the V1 version.

At this point, the V2 version of the banking controller contract to do is: Inherit the V1 version of the banking controller contract. Add a member variable that points to the V1 version of the contract address on the chain. Add a withdraw switch interface that allows the external account to operate the V2 version contract's start-and-stop grayscale strategy through ordinary transactions. Overloaded withdraw interface. Upgrade the corresponding interface logic. and customize the implementation of grayscale policies (such as grayscale-specific users, or a certain percentage of users or other policies) before the business logic really begins to execute. And note that in the case of turning on a grayscale switch, if the request does not hit the grayscale policy, the direct pass through parameter invokes the V1 version of the contract interface, and the V2 version of the withdraw interface does no additional work.