Rollup architecture¶

Overview¶

In this section, we describe the principles we use in the Rollup design.

Design Principles¶

Complexity minimization¶

The Rollup ledger validation logic is purposefully designed to be as simple as possible, yet still having full smart contract capabilities and L1 security guarantees. All application logic, including token issuance, staking, and governance, can be implemented as smart contracts on the Rollup ledger.

ZK-friendliness¶

The Rollup ledger is designed to be efficient for use in zero-knowledge proving protocols. The choices for data types, hashing and signature algorithms are made with this in mind.

Decomposition of ledger and transaction validation¶

Validation of transaction batches is decoupled from the validation of individual transactions. The ledger validation logic is kept simple to reduce the infrastructure costs (i.e., the cost of running the aggregation server) to a minimum. Transaction validation is dedicated to the client side.

UTxO-based model¶

Symbolic Ledger uses the UTxO model as it works better with our data compression techniques. For example, in value transfer transactions, the sender does not need to know the state of the recipient's account. This kind of decoupling is not present in the account-based model.

On-chain data compression¶

In this rollup design, one does not post transactions verbatim on the underlying blockchain but rather an aggregation server makes a batch of transaction ids (corresponding to those transactions) and store the batch commitment on-chain.

Each user's client wallet software is responsible for maintaining their past transaction history, which can be used to prove ownership of the user's unspent outputs.

Address Indexing¶

To increase network's throughput and reduce data footprint, one may utilize address indexing. It works as follows. Every address is assigned a unique index number. One can then reference addresses by their short index numbers instead of full byte strings.

Address indexing can be implemented as a part of the ledger rules. One way to do it is to limit the number of simultaneosly "active" addresses by requiring every indexed address to own at least some amount of some token. Then, the required bitsize of an index can be estimated based on the total token supply. For example, if the minimal value at an indexed address is \(0.05\) ada, then address index numbers can be \(40\) bits long.

Partial transactions¶

Another key feature of our ledger is partial transactions. Individual transactions in the batch are not required to be balanced. The batch itself, however, must be balanced. This allows for more atomic individual transactions which improves smart contract composability.

Transaction lifecycle¶

As our primary design goal is to minimize the data communication inside the underlying blockchain's network while ensuring safety and liveliness of the Symbolic Ledger, we use a 2-round communication protocol between the user and the aggregation server for submitting a transaction.

Specifically, we use Merkle trees to efficiently commit to a transaction batch, while posting address indices on-chain to maintain the user's ability to store and spend funds without additional trust assumptions. With this approach, the marginal on-chain storage cost of a single transaction is bitsize(AddressIndex).

This is because we only need to post the user's address index number on-chain to indicate that this user's valid transaction is in the batch. This information is required when we want to prove that a transaction output has not been spent. The rest of transaction data is stored in the Merkle tree.

Below we provide a diagram, detailing the online transaction lifecycle.

    sequenceDiagram
        participant Data Indexer
        participant User
        participant Aggregation Server
        participant Blockchain

        Note over User: Maintains Address Tx History

        Data Indexer ->> User: Rollup State

        Note over User: Proves Tx

        User ->> Aggregation Server: Transaction envelope

        Note over Aggregation Server: Builds a Merkle tree of transactions

        Aggregation Server ->> User: Merkle Path to the user's leaf

        User ->> Aggregation Server: Transaction proof

        Note over Aggregation Server: Proves Rollup Update

        Aggregation Server ->> Blockchain: Rollup Batch, Proof