Skip to main content
Helpful?

Architecture

t1 is a TEE-enabled cross-chain application infrastructure that leverages defense-in-depth to achieve real-time proving. In the short-term (v1), we achieve RTP with TEE proofs. Longer term, t1 will become a permissionless and decentralized network that will complement TEE proofs with crypto-economic security and bespoke zero-knowledge proofs. You can read more about our long term architecture in our litepaper.

Network Architecture v1​

  1. A user, Alice, deposits funds to a t1 bridge contract on Ethereum or on a Partner Rollup. Once the deposit is confirmed on the source chain, it gets processed by t1 and Alice gets her funds credited towards her aggregate t1 balance.

  2. Alice creates a t1-native transaction either to interact with applications on t1 or to trigger transactions (including withdrawals) on Ethereum or a Partner Rollup.

  3. A TEE enabled sequencer (node) receives the transactions, sequences and executes the block. As a part of execution, when required, the sequencer reads from (xChain Read) and writes (xChain Write) to Partner Rollups, both enabled within the TEE.

  4. The TEE-enabled sequencer generates new trie roots r and a TEE proof. These are submitted to the t1 Canonical Bridge contract on Ethereum and the full compressed transaction data is submitted to Ethereum blob DA.

  5. t1’s Canonical Bridge contract on Ethereum checks the newly submitted t1 trie root r and TEE proof and transaction data availability for consistency. If successful, the trie root r is accepted. This facilitates withdrawals to L1 with a single L1 slot delay (6s on average).

Note: Suppose, Alice had desired to withdraw funds, in step 2. She may now submit to the Canonical Bridge an Ethereum claim transaction with an inclusion proof of her withdrawal transaction in t1 (as contained within the withdrawal trie committed to in r). The contract then releases the funds to Alice on Ethereum.

Network Architecture v2​

  1. A user, Alice, deposits funds to a t1 bridge contract on Ethereum or on a Partner Rollup. Once the deposit is confirmed on the source chain, it gets processed by t1 and Alice gets her funds credited towards her aggregate t1 balance.

  2. Alice changes her wallet’s network to t1, creates a t1-native transaction (with some fields encrypted to the shared rotating TEE pubkey), uses her wallet to sign it, and submits it to the network (i.e. the t1 mempool); this may or may not be a specially-treated withdrawal transaction (to Ethereum or a Partner Rollup).

  3. A t1 Sequencer receives and gossips such a partially-blind transaction to other Sequencers in the t1 Sequencing AVS network.

  4. After collecting transactions for one t1 slot (currently set to one second), the slot-leading Sequencer proposes an ordering (a blind non-executed bundle). The rest of Sequencers vote on it using Espresso HotShot, to form Sequencing Consensus. This bundle and a proof of Sequencing Consensus is then passed on to the Execution AVS network.

  5. t1 Executors validate the proof of Sequencing Consensus, decrypt the encrypted parts of the received bundle (if needed and due) using their TEE-derived shared rotating private key, and execute its now fully plaintext ordered transactions against the current state of the t1 blockchain. The slot-leading Executor proposes a new trie root tuple r of state trie root, withdrawals trie root, and proof-of-read trie root—and the rest of the Executors vote on such new trie tuple r to form Execution Consensus.

    • Note: Executors use follower nodes also running in TEEs to read from and write to Partner Rollups (whenever required by a t1 tx).

  6. The Execution AVS posts t1’s new trie roots r and all the corresponding consensus proofs to the Ethereum t1 Canonical Bridge contract and the full compressed transactions to Ethereum blob DA.

    • In addition, t1 progressively incentivizes the generation and posting of periodic ZKPs to the Canonical Bridge on Ethereum to create ZKP checkpoints resetting the value-at-risk counters and also speeding up the potential on-demand ZKP creation when required. t1 dynamic gas pricing considers how much AVS security budget is still available, to reach an equilibrium.
    • In the rare event that new t1 transactions’ (as per all new trie root tuples) cumulative value since the last ZKP checkpoint, despite the mechanisms above, would exceed the crypto-economic security budget provided by Execution AVS, also an on-demand ZKP is required by the Canonical Bridge, pausing finalization until then; this would increase the withdrawal delay to hours under such extreme conditions.

  7. t1’s Canonical Bridge contract on Ethereum checks the new submitted t1 trie root tuple r, Sequencing Consensus, Execution Consensus and transaction data availability for consistency. If successful, such r is accepted. This then generally facilitates withdrawals from t1 to Ethereum with a single-Ethereum-block delay only (i.e. 6 seconds on average).

    • Suppose, Alice had desired to withdraw funds, in step 2. She may now submit to the Canonical Bridge an Ethereum claim transaction with an inclusion proof of her withdrawal transaction in t1 (as contained within the withdrawal trie committed to in r). The contract then releases the funds to Alice on Ethereum.

  8. If Alice wishes to withdraw funds to her account on a Partner Rollup rather than on Ethereum, the same trie root tuple r update in the Canonical Bridge (i.e. on Ethereum) is required as in 7. However, she submits the claim transaction with an inclusion proof of the withdrawal to the (non-canonical) t1 bridge contract on Partner Rollup instead. The Partner Rollup bridge contract verifies the inclusion proof with respect to r as accepted by the Canonical Bridge on Ethereum (using Partner Rollup’s Ethereum read abilities, usually via Partner Rollup’s own L1 canonical bridge) and then releases the funds to Alice on Partner Rollup.

Helpful?