Glossary

Blind signing is a security feature where a party (in this case, the sequencer) signs a piece of information without knowing its full contents. It’s like signing a sealed envelope without being able to see what’s inside.

Key points:

1. The signer only sees a hash (a unique digital fingerprint) of the content, not the actual content itself.
2. This prevents the signer from selectively censoring or manipulating the content based on what it contains.
3. It enhances privacy and reduces the potential for bias or censorship.

In Signet’s context: The sequencer blind signs blocks. It only sees the block’s hash and the builder’s identity, not the actual contents of the block. This ensures fair and unbiased block inclusion while preventing potential censorship.

Block builders are specialized participants in a blockchain network who assemble and propose new blocks to be added to the blockchain. They’re like puzzle makers who gather and arrange transactions into a format that fits the blockchain’s rules.

Traditionally:

1. Block builders collect pending transactions from the network’s mempool (a pool of unconfirmed transactions).
2. They organize these transactions in a way that maximizes their profit (through transaction fees) while adhering to the network’s rules.
3. In some systems, block builders compete to have their blocks chosen by proposers or validators.
4. They often use sophisticated algorithms and infrastructure to optimize block composition.

Signet takes a different approach to block building compared to traditional systems:

1. Instead of using auctions where wealthy builders can dominate, Signet uses a round-robin style system.
2. A central sequencer assigns block production rights to different block builders in turns.
3. This approach aims to prevent centralization and ensure fairer participation among block builders.
4. The sequencer uses blind signing (as we discussed earlier) to prevent censorship and ensure unbiased block inclusion.

Conditional transactions are operations that only execute if certain predefined conditions are met. They’re like “if-then” statements in programming, but for blockchain transactions.

Key points:

1. The transaction is only processed and finalized if all specified conditions are satisfied.
2. If any condition is not met, the entire transaction is cancelled as if it never happened.
3. This feature enables more complex and secure interactions, especially between Signet and Ethereum.

In Signet’s context: Conditional transactions are used for cross-chain transfers. They ensure that the transfer is fully executed in the same block on both chains. If the conditions aren’t met, the transaction is invalidated and has no effect on Signet’s state.

State roots are like a cryptographic snapshot of the entire state of a blockchain at a specific point in time. They serve as a compact way to represent and verify all the accounts, balances, and smart contract data on the blockchain without needing to store or process the entire history of transactions.

To break it down further:

1. Think of the blockchain as a giant ledger or database.
2. This ledger contains information about every account, its balance, and all the data stored in smart contracts.
3. The state root is a single, unique hash (a fixed-length string of characters) that represents the entire contents of this ledger at a specific block.
4. Any change to any part of the ledger, no matter how small, will result in a completely different state root.

Atomic, instant, cross-chain swaps between Signet and Ethereum. Orders specify inputs (what you’re providing on Signet) and outputs (the assets you want to receive, the chain, and address for delivery). Orders can be created on-chain via the Orders Contract or off-chain via SignedOrder objects. Cross-chain transfers must be fully executed in the same block on both chains; otherwise, the transaction is invalid and has no effect on Signet’s state.

See Working with Orders for implementation details.

MEV Searchers who compete to fulfill Orders by providing the output tokens. When a Filler provides the outputs specified in an Order, they receive the Order’s inputs.

See How Orders Work for more details.

Flashbots-style bundles of transactions wrapped with a host_fills field. Host fills must be atomically included with their corresponding rollup transactions. If a host fill is included without its corresponding rollup transaction, the bundle is considered invalid. Block builders must respect ordering (preserved), atomicity (all or nothing), and revertibility (no unexpected reverts) guarantees.

See Bundle Guarantees for details.

Terminology used in Signet configuration and APIs. Host Chain refers to Ethereum. Rollup Chain refers to Signet. On the Pecorino testnet, Host Chain ID is 3151908 and Rollup Chain ID is 14174.

See Pecorino Quickstart for network configuration.

Sequencers are special entities in rollup systems that are responsible for ordering and batching transactions. Think of a sequencer as a traffic controller for blockchain transactions.

Most rollups use a single centralized Sequencer with near-total control over transaction ordering. Signet’s sequencer doesn’t actually order transactions. Instead, it delegates that to block builders, and then co-signs the blocks.

1. Round-robin assignment: Instead of using auctions, the sequencer assigns block production rights to different block builders in turns.
2. Blind signing: The sequencer only sees the block’s hash and the builder’s identity, not the actual contents of the block. This prevents selective censorship.
3. Simplicity: Signet’s sequencer is designed to be simple, easy to maintain, and less prone to errors.