Application-specific rollup

Application-specific rollup is a proprietary rollup that typically serves only one application. Developers can focus solely on the application rather than deploying the chain. In addition to bringing excellent user experience to the application, certain special capabilities can be customized, such as Opside's ability to provide 0 gas for the application.



An ordered list of transactions and chain-related metadata that gets bundled together and published to the DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over.


Execution layer sequencers gather executed transaction related data and store it on the base layers for security. The frequency of data batching is decided by the Sequencer but may be enforced by the underlying protocol.



Sometimes labelled interchangeably as a “node”, they are tasked with processing transactions and managing the rollup’s state. They run the computations for each transaction according to the rollup’s virtual machine and protocol rules. If comparing to Ethereum clients, these would be execution clients such as Geth, as opposed to consensus clients.


An agreement on the latest and correct state of a blockchain. Unlike L1 blockchains which coordinate participating nodes with consensus rules, rollups rely on L1s for reaching consensus by checking the state of the rollup smart contract deployed thereon.


Deposit Contract

A smart contract deployed on L1, you can think of the deposit contract as a transfer of funds from an Opside account to a proof-of-stake validator account.It specifies who is staking, who is validating, how much is being staked, and who can withdraw the funds.

Data Availability

The block proposer must publish all of the data and anyone would be able to detect transactions.



1 Epoch = 32 Slots Represents the number of 32 slots and takes approximately 6.4 minutes.


Fraud Proof

Fraud proofs indicate that a state transitions was invalid. This is proven by replaying the transaction which caused the state transition onchain and comparing the resulting state root with the one that was published by the sequencer. If the state roots do not match, then the fraud proof is successful and the state transition is cancelled.



Miner is an actor who participates in cryptocurrency transactions, and in turn, plays a crucial role both in creating new cryptocurrencies and in verifying transactions on the blockchain. It adds new blocks to the existing chain, and ensures that these additions are accurate.

To Opside, miner is an actor who submits the ZKP (Zero-Knowledge-Proof) to L1 layer.



A software client that participates in the network.


Optimistic rollup

A rollup that optimistically updates state with the possibility of fraud proofs being generated to revert faulty state transitions. Optimistic rollups have primarily been EVM-compatible to date. Compared to ZK-Rollups, they have longer time to finality as there is a time window (challenge period) during which anyone can challenge the results of a rollup transaction by computing a fraud proof.



An entity that generates the cryptographic proof to convince the verifier that the statement is true (without revealing its inputs). In a ZK-Rollup, the prover generates the ZK (validity) proof to submit to the verifier contract. If used in the context of an optimistic rollup, the prover generates the fraud proof to show that an incorrect state was submitted.



Rollups are one of several scaling systems, which are simply methods to make a slow blockchain faster and cheaper.


An SDK or service that allows anyone to launch rollups quickly.



Slashing has two purposes: (1) to make it prohibitively expensive to attack the network, and (2) to stop validators from being lazy by checking that they actually perform their duties. If you're slashed because you've acted in a provably destructive manner, a portion of your stake will be destroyed. If you're slashed you're prevented from participating in the protocol further and are forcibly exited.


32 Slots = 1 Epoch

A time period of 12 seconds in which a randomly chosen validator has time to propose a block. Each slot may or may not have a block in it. The total number of validators is split up in committees and one or more individual committees are responsible to attest to each slot. One validator from the committee will be chosen to be the aggregator, while the other 127 validators are attesting. After each Epoch, the validators are mixed and merged to new committees. There is a minimum of 128 validators per committee.


A party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the batch to Opside L1 as a single transaction.



A node in a blockchain system responsible for processing transactions, and adding or verifying new blocks to the blockchain.

Validator Key

As seen in the cutout below the validator signing key consists of two elements:

  • Validator private key

  • Validator public key

The purpose of the validator private key is to actively sign on-chain (ETH2) operations such as block proposals and attestations. Therefore these keys have to be held in a hot wallet.

The validator public key is included in the deposit data which allows ETH2 to identify the validator.

Validity proof

The output of a cryptographic proving system attesting to correct computation. ZK-Rollups use succinct validity proofs (also called zero-knowledge proofs) to prove a batch of rollup transactions and blocks were properly executed. Validity proofs are submitted to a verifier, such as an Ethereum smart contract, which accepts them if properly constructed.


Withdraw Credencial

Withdrawal Credentials is a 32-byte field in the deposit, for verifying the destination of valid withdrawals. Currently, there are two types of withdrawals: BLS withdrawal and Opside address withdrawal.

  1. BLS withdrawal: By default, the deposit-cli would generate withdrawal credentials with the withdrawal key derived via mnemonics in EIP2334 format.

  2. Opside address withdrawal: If you want to withdraw to your execution wallet address after the Shanghai/Capella upgrade, you can set --opside_withdrawal_address <YOUR IDE ADDRESS> when running deposit-cli. Please ensure that you have control over the keys to this address.



A rollup that uses ZKPs (also often called validity proofs to validate the correctness of the state transition function and update the rollup state. This is one of two main types of rollup constructions, along with optimistic rollups. In general, ZK-Rollups do not provide privacy preserving properties; privacy preserving ZK-Rollups are sometimes called ZK-ZK-Rollups.

Last updated