Comment on page
L2 Processes
Merkle Tree Transaction Batch Root (MTTBR) is an ordered list of transactions.
Merkle Tree State Root (MTSR) is a calculated state hash of the transaction execution.
GTON Network Smart Contract L2 infrastructure contains several process loops that prevent possible malfunctions of decentralized actors and unintended behavior of external malicious actors.
Below, the main process of transaction execution in GTON Network is described.
The User, the actor that sends the transactions, submits a transaction to the Block Producer, the actor responsible for propagating the blocks through the Peer Network. The Block Producer forms the blocks for the L2 Smart Contracts and propagates them through the Peer Network.
The User gets confirmation of the transaction from the L2.
Then, the Sequencer, responsible for providing transaction data and the data batch to other entities from the L2, receives the full transaction data from the Peer Network and computes the data batch: Merkle Tree Transaction Batch Root (MTTBR) and Merkle Tree State Root (MTSR).
The Sequencer submits the full transaction data to Memolabs that stores the transaction data off-chain, from where it will be provided to the Verifier, the counterpart of a Sequencer, responsible to verify that sequencer does not provide false/invalid data.
At regular intervals, the Sequencer submits the batch of data to Layer 1 (MTTBR and MTSR), the set of smart contracts on Ethereum that handle the security of the system and solve the disputes between Sequencer and Verifier.
The Verifier attempts to download the full transaction data from Memolabs or the Peer Network by retrieving the MTTBR on Layer 1 that was submitted by the Sequencer. It computes its own MTTBR from the full transaction data it received from Memolabs / Peer Network.
Then, the Verifier downloads the Sequencer’s MTTBR and MTSR from Layer 1. It compares its own roots with the roots submitted to Layer 1 by the Sequencer.
If the Verifier’s MTTBR corresponds to Sequencer’s MTTBR, the Verifier computes its own MTSR, downloads the Sequencer’s MTSR from Layer 1 submitted by the Sequencer, and compares its own calculated MTSR with the Sequencer’s MTSR.
If the Verifier’s MTSR is equal to Sequencer’s MTSR, the transactions and state are valid.
If the Verifier’s MTSR is not equal to Sequencer’s MTSR, the Verifier submits the transaction data it received from the Memolabs or the Peer Network to Layer 1 and marks them challengeable;
The Verifier can submit a Fraud Proof. The Fraud proofing process will proceed just as a regular Optimistic Rollup hereafter.
If the Verifier’s MTTBR is not equal to Sequencer’s MTTBR, then the Verifier requests the Sequencer via fee payment to post the Sequencer’s transaction data on Layer 1. This fee payment is collected on Layer 1 as an upfront amount to pay for the request fees. The fees are sent to the Governance Protocol, responsible for anything related to the efficiency of the system, to pay for potential reimbursements caused due to griefing. The Sequencer will have a time window (in # of blocks, currently set at around 24 hours) to respond and is responsible for the resulting gas fee. Both the Sequencer and Verifier lose money in this process. The System enters the insecure transaction state for the data availability request time window until the next rotation. During this time the Verifier requests the Sequencer to provide valid transaction batch data.
Last modified 1yr ago