Ontology Launches Layer 2, Contributing to a More Comprehensive Public Chain Platform

The Ontology Team
OntologyNetwork
Published in
6 min readMay 21, 2020

Foreword

Imagine a scenario in which a blockchain platform is developing rapidly and the number of users is exploding, quickly reaching tens of millions, bringing a sharp rise in related costs over a short time. At this stage, what strategies are needed to maintain operational efficiency without hindering the pace of development due to complex consensus and confirmation processes? As enterprises agree, scalability has to be a priority.

As an off-chain scalability technology, Ontology Layer 2 offers higher performance and lower rates. Enterprises can safely store a large number of transaction records off-chain and then transfer them to the chain when they need to interact, reducing user transaction costs and drastically increasing performance.

Introduction

As outlined in the Aristotle 2020 roadmap, coupled with Ontology’s cross-chain, Wasm-JIT, Multi-VM and other cutting-edge core technologies, Ontology Layer 2 now shows leading performance in contrast with other Layer 2 solutions. This is reflected in its low storage costs, multi-language support, and full compatibility of parsing and execution versions. enabling deployment contracts to interact seamlessly, like running multiple virtual operating systems on the same computer, resulting in higher execution efficiency and lower processing fees.

Work Process

Ontology Layer 2 has 3 main parts: Ontology Deposit to Layer 2, Layer 2 Withdraw to Ontology, and Layer 2 transactions and security guarantee.

In the Layer 2 trading center, users can make transactions, execute contract requests, and sign contracts. This transaction can be the same as the Ontology main chain transaction format, or it can be different. The transaction collectors (referred to as “Collectors”) are responsible for collecting the user’s Layer 2 transactions. There can be multiple Collectors throughout the process. Users can also broadcast their Layer 2 transactions to multiple Collectors.

The Collector periodically packages the collected Layer 2 transactions and runs them to generate a new State. The Collector is also responsible for submitting the root of the new State to the Ontology main chain. After executing the transactions packaged in the Layer 2 block, the Root of the new state becomes the State of the Layer 2 block. The Challenger is responsible for verifying the Layer 2 block state submitted by the Collector to the Ontology main chain. This requires the Challenger to synchronize the Layer 2 block through the Collector to maintain the complete global state.

The account status proof includes account status information and its merkle proof, which can be obtained from the Collector and Challenger queries. Only they maintain a complete global state.

Deposit to Layer 2

1. Firstly, the user performs a “Deposit” operation on the Ontology main chain. The main chain contract locks the user’s deposit funds and records the state of this fund in Layer 2. At this point, the status is “unreleased”.

2. The Collector is then notified that there is a Deposit operation pending on the main chain of the Ontology. The Collector will modify its state in Layer 2 according to the operation of the Deposit. The Collector then adds a Deposit to release the transaction and packages it with the other user transactions to the Layer 2 block. When the Layer 2 block state reaches the Ontology main chain, it will notify the system that the Deposit has been released.

3. The main chain contract executes the deposit release operation and changes the status of the deposit fund to “released”.

Withdraw from Ontology

1. The user constructs a “Withdraw” Layer 2 transaction and submits it to the Collector.

2. The Collector modifies its state according to Withdraw, and, at the same time, packages the Withdraw transaction and other user transactions together into a Layer 2 block. When submitting the Layer 2 block state to the Ontology main chain, the Withdraw request will be submitted.

3. The main chain contract executes the Withdraw request, records a fund record, and sets the status to “not released”.

4. After state confirmation, the user submits a Withdraw release request.

5. The main chain contract executes the Withdraw release request, transfers funds to the target account, and sets the Withdraw record to “released”.

Layer 2 transactions and security assurance

  • Layer 2 transactions

1. The user constructs a “Transfer” Layer 2 transaction and submits it to the Collector.

2. The Collector packages the transfer transaction and other transactions into a Layer 2 block, executes the transactions in the block, and submits the State of this Layer 2 block to the Ontology main chain.

3. Wait for State confirmation.

  • Security Guarantee

After the Operator submits the Layer 2 block State to the Ontology main chain, the Challenger can also run the Layer 2 block transaction and verify the correctness of the Layer 2 block State. If it is not correct, the Challenger will collect fraud proof and submit to the Layer 2 smart contract to challenge the Operator.

  • How to Use

Currently, Ontology Layer 2 is available on the Ontology TestNet for developers to experiment with.

Link: http://152.32.217.204/

Document link: https://github.com/ontio/layer2

In the next article, we will provide a detailed performance comparison with Layer 2 on other chains.

Appendix: Explanation of Terms

  • Layer 2 Transactions

The user has made a request to transfer or execute a contract at Layer 2 and has already signed it. This transaction can be the same as the transaction format of the Ontology main chain, or it can be different.

  • Collector

The Collector is a Layer 2 transaction collector. It is responsible for collecting user’s Layer 2 transactions, verifying and executing the transaction. Every time a Layer 2 block is generated, the Collector is responsible for executing the transactions in the block, updating the status, and generating Layer 2 contracts that can be interpreted as proof of the state used for security assurance.

  • Layer 2 Block

The Collector periodically packages the collected Layer 2 transactions, generates a block containing all Layer 2 transactions, and generates a new Layer 2 block.

  • Layer 2 State

The Collector executes the packaged transactions in the Layer 2 block, updates the state, sorts all the updated state data to generate a Merkle tree, and calculates the root hash of the Merkle tree. The root hash is the Layer 2 state of the block.

  • Operator

The Operator is the security daemon of Layer 2 and is responsible for monitoring whether there is a token transfer to Layer 2 or a token transfer transaction from Layer 2 to the Ontology main chain. The Operator is also responsible for periodically submitting the status proof of Layer 2. You can go to the Ontology mainnet as proof.

  • Challenger

The Challenger is responsible for verifying the status proof submitted by the Operator to the Ontology main chain. This requires the Challenger to synchronize Layer 2 transactions from the Operator or the chain to maintain the complete global state. After the Challenger synchronously executes the transaction and updates the status, it can verify the correctness of the status proof submitted by the Operator on the mainnet. If it is not correct, the Challenger can generate a fraud proof challenge that the Layer 2 contract can explain.

  • Proof of Account Status

Achieved through Merkle proof, proof of account status requires can be obtained from Operators and Challengers. They are the only parties to maintain a complete global state.

  • Proof of Fraud

Proof of fraud includes the account status proof before the current Layer 2 block update.

The previous Layer 2 block status certificate and the submitted account status certificate, proves the legitimacy of the old state before the update. Proof that the old state is legal can be achieved by running the current block.

Ontology’s enterprise-focused blockchain is ready to help enterprises transform and upgrade their businesses. If you are experiencing problems with off-chain scalability, virtual machines, or a full set of technical systems, please contact us via contact@ont.io.

--

--