Lumoz Docs
  • Introduction
    • Welcome to Lumoz
    • Understand Lumoz
      • Modular AI Computing Network
      • Nodes
    • Lumoz Chain
    • Bridge
  • Lumoz Decentralized AI
    • Overview
    • Architecture
    • Computational Resource Management
    • Use Cases
    • Chat with Lumoz Decentralized AI
      • Plan
  • AI Agents
    • Overview
    • How Lumoz TEE Works
    • The Core Architecture Design
    • Lumoz AI Agent Framework
  • Compute Node
    • Compute Node
      • Why Compute Node
      • How do Compute Nodes Work
      • Rewards
    • Setup Compute Node
  • Rollup as a Service
    • Overview
    • Lumoz RaaS Stack
    • Rollups Built with Lumoz
  • Verifier
    • Verifer Node Explained
      • Why Verifier Node
      • How do Verifier Node Work
      • License
      • Rewards
    • Purchase Verifier Node
      • Purchase License
        • Buyback Guarantee
      • License Tiers
      • Invitation
      • FAQ
    • Setup Verifier Node
      • Who can run a node?
      • Requirements
      • Setup Node
        • Node as a Service
        • Build your own
          • 1. Initialize a Node
          • 2. Run the Node
            • Run with CLI
            • Run with Docker(recommended for multiple nodes)
          • 3. Update Node Information(optional)
      • FAQ
      • Troubleshooting
    • Delegate Licenses
      • Claim License
      • Delegate Guide
      • Undelegate Guide
    • Staking
      • Staking Guide
      • Unstaking Guide
    • Node Tier
    • Time Cooldown
    • Risk Notice and Disclaimer of Lumoz Verifier Node Sale
  • Roadmap
  • Tokenomics
    • Utility
    • Allocation & Distributions
    • Redemption
  • Contracts
  • Technical Reference
    • Lumoz ZK-PoW
      • ZKP Two-Step Submission
    • Cross-Rollup Communication
      • Prerequisits and Compatibility
      • Process of Native Cross-Rollup Transactions
  • Glossary
  • Resources
Powered by GitBook
On this page
  • A
  • B
  • C
  • D
  • E
  • F
  • M
  • N
  • O
  • P
  • R
  • S
  • V
  • W
  • Z

Glossary

PreviousProcess of Native Cross-Rollup TransactionsNextResources

Last updated 1 year ago

A

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.

B

Block

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

Batch

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.

C

Client

Sometimes labelled interchangeably as a “”, they are tasked with processing transactions and managing the ’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 clients.

Consensus

D

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.

E

Epoch

F

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.

M

Miner

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.

N

Node

O

Optimistic rollup

P

Prover

R

Rollup

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

RaaS

S

Slash

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.

Slot
Sequencer

V

Validator
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

W

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. 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.

Z

ZK-Rollup

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.

transactions
DA
Nodes
rollup
node
rollup
consensus
nodes
rollups
Slots
slots
client
rollup
fraud proofs
ZK-Rollups
ZK-Rollup
ZK (validity) proof
optimistic rollup
fraud proof
rollups
Epoch
Epoch
rollup
block
node
blocks
ZK-Rollups
blocks
EIP2334
rollup
validity proofs
optimistic rollups