2.6 Optimistic Rollup Contract

The Optimistic Rollup Contract (ORC) holds the Node State, the Gateway State, the Transaction State, and the Account State. The Account State is most frequent across all account-based optimistic rollups, what will continue to be the status quo in transaction execution for both mainchains and rollups, despite the recent popularity in UTXO-based optimistic rollups [19]. All states are represented on the Ethereum mainchain as hashes of their corresponding Patricia Merkle Trie [20]. The Node and Gateway Tries are of depth 14, allowing for Nodes and Gateways, with the ability for the depth size to be increased in the future via an APiiP. The Account State is of depth 22, allowing accounts (which sums to the Users, Gateways, and Nodes), with the ability for depth size to be increased in the future via an APiiP. The Transaction State Trie is of depth 40, allowing for transactions, with transactions that have been processed and not challenged either in the DRC Factor or the ORC for 50,000 blocks (7.52 days) pruned and removed from the Transaction Trie. Transactions pruned from Trie can be maintained by Nodes and Gateways for longer if desired, although there is no reason to hold them via the incentives of the APIS protocol.

The Transaction Trie has three sub-Tries, of which referenced prior has only been the Payment Trie. In addition to the Payment Trie, a Node Update Trie and Gateway Update Trie have been implemented to allow for the customized updating of the Node State and Gateway State Tries. Both Node and Gateway Transactions contains identical structures, with the primary purpose of allowing Nodes and Gateways to increase or decrease their API at stake, which, to be valid, must already have been deposited into the ORC via a standard smart contract deposit transaction on the Ethereum mainnet: <Node/Gateway Address, Node/Gateway Signature, Node/Gateway Staked Deposit (negative integers are allowed, with a check that the Account Stake as listed in the Node/Gateway State Trie is greater than or equal to the withdrawal amount), ID hash (the hash of all IDs currently supported by that Node or Gateway), Nonce>.

 {
      struct NodeUpdateTransaction {
               address node;
               signature node;
               int change;
               string identity;
               uint nonce;
}
  }
    }

Figure 2.6.1: Customized Node State Update Transaction Field.

The ORC also contains the Optimism Fraud Proof’s standard public functions, which allow for fraudulent state updates to be challenged and resolved without requiring interaction other than the initiated challenge itself [21]. It should be noted for emphasis that DRC and ORC fraud proofs are distinct processes (The DCR is highly interactive, due to the subjectivity over the truthfulness of the items being disputed, whereas the ORC will become highly objective overtime, due to the usage of the Ethereum mainchain as a data storage layer.). ORC Fraud Proofs rely on data availability, namely that all state updates have corresponding transactions readily available on the Ethereum mainnet, primarily stored as call data [22].

To ensure data availability while maintain scalability, a pruned-version of transaction information that is included in the Transaction Trie is stored as call data on the Ethereum mainchain: <TrieID (a reference to one of the three transaction tries), TransactionHash (a hash representation of the transaction)>, where the Trie ID is 4 bytes and the Transaction Hash is 32 bytes, such that each transaction only uses 36 bytes of call data. A standard Ethereum transaction is 247 bytes [23] and requires 21,000 gas because of its use of the Ethereum State Trie; APIS’s optimistic rollup architecture has effectively batched transactions at a ratio of 125:1, thus allowing for 1,875 transactions per second, or 1,875 API calls per second, compared to the Ethereum mainnet’s current throughput of 15 transactions per second.

If an ORC state update is found to be fraudulent, the validator’s bonded APX tokens are slashed and distributed to the party that found and report the fraudulent block transition. Any party can submit an APIS ORC block to the blockchain so long as they have bonded API tokens bonded in the ORC contract. Like the DRC Factory, tokens staked in the APIS GC can be staked in the ORC as a validator, per the system’s design requirement of superfluidity.

If our optimistic rollup design cannot scale to meet demand, we will transition to a zero-knowledge rollup design, leveraging either a modified version of zkSync or Validium, depending on scaling requirements required by user demand [24].