GTON Capital | GC
  • GTON Capital ⚜️ Explained
  • LEARN
    • Brief Intro
    • GTON Capital in Detail
    • GameFi, SocialFi, & Real World Assets
    • GTON Network
      • Basics of Rollups
      • Protocol Overview
      • L2 Processes
      • Bridge
    • GTON Dollar (GCD)
      • Lending, CDP, and Money Markets
      • Fees
      • GCD Contracts
        • Solidity API
    • OGXT
    • Oracles
  • USE
    • GTON → OGXT Token Swap
    • OGXT/GCD Ratio
    • GTON CLI
    • Connect to GTON Testnet
    • Metamask Settings
    • Deploy to GTON Network
    • Contract Verification
    • Mint & Bridge GCD
    • Tech Support
    • Positions Liquidation and Closing the Project
  • GTON Ecosystem
    • GTON Ecosystem
  • Contributors
    • Multisig
    • Github
  • Treasury
    • Treasury Management
    • Treasury Snapshot Reports (TSR)
      • TSR 1 - 19 Jan 2022
      • TSR 2 - 19 Feb 2022
      • TSR 3 - 19 Mar 2022
      • TSR 4 - 19 Apr 2022
      • TSR 5 - 19 May 2022
      • TSR 6 - 19 Jun 2022
      • TSR 7 - 19 Jul 2022
      • TSR 8 - 19 Aug 2022
      • TSR 9 - 19 Sept 2022
      • TSR 10 - 19 Oct 2022
      • TSR 11 - 19 Nov 2022
      • TSR 12 - 19 Dec 2022
      • TSR 13 - 19 Jan 2023
      • TSR 14 - 19 Feb 2023
      • TSR 15 - 19 Mar 2023
      • TSR 16 - 19 Apr 2023
      • TSR 17 - 19 May 2023
      • TSR 18 - 19 Jun 2023
      • TSR 19 - 19 Jul 2023
      • TSR 20 - 19 Aug 2023
      • TSR 21 - 27 Feb 2024
  • Audits
    • Certik Audit
    • Securing Audit
    • Hacken Audit
  • Community
    • Snapshot (Fantom)
    • Snapshot (Ethereum)
    • ⚠️Legal Disclaimer
    • Code of Conduct
  • History & Legacy
    • Legacy Articles
      • 🪙Staking
      • 🪢Bonding
      • 🧬Pathway (PW)
        • PW FAQ
      • Roadmap
      • 👼Angels
    • Timeline Overview
    • Unlocking from staking v0/v1
    • 2021 Vision
    • GTON Token
Powered by GitBook
On this page
Export as PDF
  1. LEARN
  2. GTON Network

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.

Fraud Prevention

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.

PreviousProtocol OverviewNextBridge

Last updated 2 years ago