L2 Rollup Protocol: On-Rollup Transactions

This is the protocol through which prover nodes communicate with one another and with the other components of the system.

Prover nodes are responsible for

1. Responding to queries regarding the rollup.

2. Remembering the state of the rollup.

3. Updating the state of the rollup

4. Executing the L1 rollup protocol.

Because the task of building zk-SNARKs that validate large numbers of on-rollup transactions is computationally difficult, being able to build a distributed computing cluster for executing the L2 protocol is useful. For this reason, among others, the prover node protocol allows for an unlimited number of prover nodes.

Another benefit of allowing for more than one prover node is that the L2 protocol can be decentralized. Full decentralization of the L2 protocol is an eventual goal to which the Orbis team is committed.

Prover API

The prover API contains endpoints necessary to perform operations, including the endpoints for submitting transactions and querying the rollup state.

Transaction-submission API

This API allows Orbis users to interact with their funds on the L2 chain. The endpoints involved are listed below:

1. Submitting a smart contract by the user to L2 via this API

2. Checking whether a smart contract exists

3. Fetching a smart contract

4. Reserving inputs: (Reserving inputs for a transaction by the user is necessary to use inputs in a transaction. This reservation can be performed via this API )

5. Submitting a transaction. (Here The transaction is validated and either accepted or rejected with a reason)

Query-state API

Issuing a rollup metadata fetch request yields the number and hash of the current highest-rollup block. Users can use these to fetch more information about this block.

The endpoints involved are listed below:

1. Fetching rollup metadata - Issuing a rollup metadata fetch request yields the number and hash of the current highest-rollup block.

2. Fetching fee structure - Issuing a fee structure fetch request yields the fee structure parameters as of the given time.

3. Fetching block by hash - The request returns a set of matching blocks, because hash collisions may occur.

4. Fetching block by time

5. Fetching transaction - This endpoint allows for fetching of all details of a transaction ac- cording to its ID.

6. Fetching TxOut - This endpoint can be used to obtain a set of transaction outputs for a given address, which can later be used to construct inputs for a transaction.

Voting and governance

The endpoints involved in voting and governance are listed below:

1. Fetch board - This endpoint returns a list of the current Orbis governance board members.

2. Get voting power - This endpoint returns the current voting power held by a given address.

3. Create a proposal - This endpoint creates a new board election.

4. Fetch active proposals - This endpoint returns a list of active proposals, which have been created but not expired nor executed.

5. Vote - This endpoint adds a vote to an active proposal, or changes the vote of an address which has already voted.

6. Execute election - This endpoint takes the id of an active proposal which has enough votes to pass, and the signatures of the board members, and enacts the change to the governance protocol to govern Orbis under the accepted proposal.

7. Update fee structure - This endpoint updates the fee structure to a new value.