Glossary
Last updated
Last updated
An agreement on the latest and correct state of a blockchain. Unlike L1 blockchains which coordinate participating with consensus rules, rely on L1s for reaching consensus by checking the state of the rollup smart contract deployed thereon.
1 Epoch = 32 Represents the number of 32 and takes approximately 6.4 minutes.
A software that participates in the network.
A that optimistically updates state with the possibility of being generated to revert faulty state transitions. Optimistic rollups have primarily been EVM-compatible to date. Compared to , 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 , the prover generates the to submit to the verifier contract. If used in the context of an , the prover generates the to show that an incorrect state was submitted.
An SDK or service that allows anyone to launch quickly.
32 Slots = 1
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 , 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 . The sequencer verifies transactions, compresses the data into a , and submits the batch to Opside L1 as a single transaction.
A in a blockchain system responsible for processing transactions, and adding or verifying new to the blockchain.
The output of a cryptographic proving system attesting to correct computation. use succinct validity proofs (also called zero-knowledge proofs) to prove a batch of rollup transactions and were properly executed. Validity proofs are submitted to a verifier, such as an Ethereum smart contract, which accepts them if properly constructed.
BLS withdrawal: By default, the deposit-cli would generate withdrawal credentials with the withdrawal key derived via mnemonics in format.
A that uses ZKPs (also often called 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 . In general, ZK-Rollups do not provide privacy preserving properties; privacy preserving ZK-Rollups are sometimes called ZK-ZK-Rollups.