Comment on page
Glossary
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 Lumoz'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.
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.
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 Lumoz, miner is an actor who submits the ZKP (Zero-Knowledge-Proof) to L1 layer.
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.
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.
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.
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.
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.
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 Lumoz 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.Lumoz 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 modified 1mo ago