Code is Law: a few thoughts on off-chain scaling
Foreword: Since we started publishing the Ontology Tech Point articles, we have received a lot of positive feedback from our tech community, some of them have also expressed their wish to contribute. We welcome contribution from the community and high-quality content will be fairly rewarded. Today we selected an article by one of the community members, RandX, who shared some of his thoughts on off-chain scaling method in the following piece.
I have read some blockchain articles about off-chain scaling methods, which suggested that complex business logic should be moved off the chain so that business verification and operations that need consensus can be done on the chain. A dApp developer myself, I want to share some of my thoughts on off-chain scaling.
Why is off-chain scaling important?
Blockchain offers users a trustless computing environment. For dApp users, the method of using blockchain is generally as follows:
The user sends the signed transaction directly to the blockchain network, and cryptography ensures that the user’s signature is not forged. A trustless blockchain environment will ensure that user requests are processed by the correct smart contract (on-chain code).
However, since the operation of the smart contract on the chain is generally based on the amount of computation consumed, if a smart contract is used to implement complex business logic, the user will have to pay a large fee each time the dApp is used. This will increase the burden on users to use this dApp, which is not conducive to its promotion. Therefore, in reality, most dApp developers generally implement their own complex business logic off the chain, and only perform business result verification and token settlement on the chain (using smart contracts). That is, most dApps today work as shown below:
In order to further reduce the cost, and to facilitate dApp iteration and avoid the security risk of smart contracts, more often than not, dApp developers want to complete all business logic off the chain, and only process token settlement on the chain. dApp developers only call the business result validation logic on the chain when necessary (when off-chain disputes need to be resolved), which is the off-chain scaling method we are discussing in this article.
2. Create an off-chain trustless computing environment
From the above figure, we can see that from the user’s point of view, the trustless computing environment includes the on-chain part and the off-chain part. In this scenario, the user sends his transaction off the chain, which is then processed by the off-chain code. When the user disputes the processing result of the off-chain code, the off-chain status is sent to the on-chain code to be processed, which is responsible for resolving user disputes. The on-chain code here mainly refers to dApp smart contract and off-chain code mainly refers to the result verification in the off-chain code, instead of all dApp business logic.
On the blockchain, code is law. The code only refers to the code running on the blockchain platform, mainly including on-chain smart contracts, virtual machine, and ledger status related codes. As can be seen, in our current off-chain scaling solution, the on-chain code is law, while off-chain code is not law.
Therefore, in the actual design, it is required that the logic of the on-chain code and the off-chain code need to be equivalent. Since the on-chain code is law, the development of the business verification logic can be completed using the development and testing process of the standard smart contract. However, since the off-chain code does not need to be implemented using a smart contract, its coding should be simpler and more convenient. However, this is often not the case. Since the on-chain code has already defined the relevant logic, the off-chain code must be 100% compatible with the logic of the on-chain code, that is, the off-chain code must be the state in ① and ④, and the state in ② and ③ may not exist, otherwise the user will be able to use this inconsistency for fraudulent behavior, and the on-chain code will not be able to identify the fraudulent behavior.
Based on the argument above, we believe in order to maintain a trustless off-chain computing environment, the business verification in the dApp business logic must be consistent on-chain and off-chain. How to keep it consistent then? A good method generally adopted by the community is Counterfactual instantiation. A simple explanation for CounterFactual is: off-chain operations can be sent onto the chain by users very conveniently, which means the on-chain code and off-chain code are equivalent. With the on-chain and off-chain consistency, dApps can encourage the vast majority of users to process their requests off the chain through protocol design, thus achieving scalability off-chain.