Protocol papers
Scaling papers.
Watch the data, the challenge window, or the proof. A header without the body is a different security claim.
How to read this shelf
Each card opens a study. The study is a reading of a public paper, not the paper and not a description of today's network. Status is a design paper unless the record says historical or failure case.
How to read this page
Research status is named on the page. Primary sources are linked. This is a mechanism and operating note, not investment suitability, legal advice, a security guarantee or an implementation certificate.
Lightning · 2016 · Design paper
The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments
Poon and Dryja's 2016 design for Bitcoin payments that stay off the main chain inside penalty-backed channels, and that route across a network of those channels using hashed timelock contracts.
Plasma · 2017 · Design paper
Plasma: Scalable Autonomous Smart Contracts
A 2017 construction for trees of child chains whose state commitments are posted to a parent chain, with exits so a user can leave if the child operator misbehaves. It is an ancestor of later rollup and validium designs, not a synonym for them.
Arbitrum · 2018 · Design paper
Arbitrum: Scalable, private smart contracts
The 2018 USENIX paper on Arbitrum: a verifier that checks a manager's execution of a virtual machine by bisecting disputes, instead of re-executing every instruction. Offchain Labs' later Nitro stack is a descendant, not this paper line for line.
StarkWare · 2018 · Design paper
Scalable, transparent, and post-quantum secure computational integrity
The STARK paper: proofs of computational integrity that are succinct, do not need a trusted setup, and are argued to resist quantum attackers on the underlying hashes. StarkWare's later systems, including StarkEx and Starknet, are built on this proof system. They are not identical to it.
Celestia · 2019 · Design paper
LazyLedger: A Distributed Data Availability Ledger With Client-Side Smart Contracts
Al-Bassam's LazyLedger paper, the research origin of Celestia. The base layer orders and makes data available. It does not execute application transitions. Clients check availability with sampling, and applications execute on their own.
EigenLayer · 2023 · Design paper
EigenLayer: The Restaking Collective
Eigen Labs' design for letting Ethereum stakers opt in to additional slashing conditions, so new services can rent economic security instead of bootstrapping a new token set from zero.
Polygon · 2019 · Design paper
Matic Network white paper
The 2019 Matic paper for a Plasma-inspired sidechain with a proof-of-stake checkpoint layer posting to Ethereum. Polygon is the later organisation and product family. This page is about the 2019 document, not about every subsequent Polygon stack.
Fraud and data availability proofs · 2018 · Design paper
Fraud and Data Availability Proofs
Light clients can refuse a block if a fraud proof shows it is invalid, but only if the block's data was actually published. The paper shows how erasure coding and sampling let clients check publication without downloading everything.
TrueBit · 2017 · Design paper
A scalable verification solution for blockchains
Pay a solver to run a heavy computation off-chain, and pay a verifier only when they find a lie. An interactive game narrows the lie to one step. A jackpot is there so verifiers show up even when solvers are usually honest.
KZG commitments · 2010 · Design paper
Constant-Size Commitments to Polynomials and Their Applications
Commit to a polynomial and later open it at a point, in constant size, with a pairing. The commitment is binding if the setup's trapdoor stays secret. Modern data-availability schemes use this as a brick. The paper is older than those schemes.
EIP-4844 · 2022 · Design paper
Shard Blob Transactions
A new transaction type carries a blob: a large chunk of data that consensus nodes hold briefly and that the execution layer cannot read byte by byte. Rollups are the intended user. The blob is not cheap forever, and it is not the rollup's proof.
BitVM · 2023 · Design paper
BitVM: Compute Anything on Bitcoin
A way to dispute an arbitrary computation between two Bitcoin parties using hashlocks, timelocks and large Taproot trees, without a new opcode. Honest execution stays off-chain. A false claim can be challenged on-chain. It is not a global virtual machine.
Cairo · 2021 · Design paper
Cairo – a Turing-complete STARK-friendly CPU architecture
A CPU whose every instruction was chosen so that a STARK can prove 'this program ran'. You write a program instead of a new set of polynomial equations for each statement. The paper is the machine, not a network's throughput.
Perun · 2017 · Design paper
Perun: Virtual Payment Hubs over Cryptocurrencies
Lightning routes each payment through the intermediaries. Perun asks those intermediaries to set up a virtual channel and then step out of the individual payments. The paper gives the construction for one hub, on a chain that can run the contracts.
OmniLedger · 2018 · Design paper
OmniLedger: A Secure, Scale-Out, Decentralized Ledger via Sharding
OmniLedger reassigns validators to shards, uses a bias-resistant randomness beacon, and atomically commits cross-shard transactions.
RapidChain · 2018 · Design paper
RapidChain: Scaling Blockchain via Full Sharding
RapidChain shards the ledger completely and uses a committee protocol that tolerates a smaller honest fraction inside a committee than a classical open network.
SuperNova · 2022 · Design paper
SuperNova: Proving Universal Machine Executions without Universal Circuits
SuperNova folds a universal machine by switching among circuits without a universal circuit that contains every instruction.
HyperNova · 2023 · Design paper
HyperNova: Recursive Arguments for Customizable Constraint Systems
HyperNova generalises folding to customisable constraint systems so a recursive proof can follow the arithmetisation the circuit actually uses.
Vault · 2019 · Design paper
Vault: Fast Bootstrapping for the Algorand Cryptocurrency
Vault compresses Algorand's state and the proofs a client needs so a bootstrapping node does not replay the entire history.
OHIE · 2020 · Design paper
OHIE: Blockchain Scaling Made Simple
Run many parallel Nakamoto chains. A block is assigned to a chain by its hash. The safety argument stays close to bitcoin's, and the throughput is the sum.
Chainspace · 2017 · Design paper
Chainspace: A Sharded Smart Contracts Platform
Chainspace shards objects, and a transaction names the objects it will read and write so the shards involved can run a distributed commit.
Optimism Cannon · 2023 · Design paper
The Fault Proof System
A dispute walks a single instruction of a state transition on a parent chain, so anyone who can post a bond can force the on-chain step that decides a bad proposal.
Sovereign rollups · 2022 · Design paper
Rollups as Sovereign Chains
Publish transaction data to a data-availability layer. Let the rollup's own nodes interpret it. Fraud or validity proofs are checked by those nodes, not by an Ethereum bridge, unless someone adds one.
Validium · 2020 · Design paper
Validium and the Data-Availability Spectrum
Validium proves execution and keeps the data off the parent chain, with a committee or another store. Volition lets a user choose, per state, whether the data sits on the parent.
Based rollups · 2023 · Design paper
Based Rollups
A based rollup lets the parent's proposers order the rollup's transactions. There is no separate sequencer to bribe or to wait for.
Espresso · 2022 · Design paper
The Espresso Sequencer
A shared sequencer orders transactions for many rollups. Each rollup still executes its own state. The sequencer sells order, not execution.
Verkle trees · 2018 · Design paper
Verkle Trees
Verkle trees use vector commitments so a proof of many leaves shares one commitment path. The proof is shorter, at the cost of a polynomial-commitment assumption.
BIP 141 · 2015 · Design paper
Segregated Witness
Move witness data outside the input script. The transaction id that contracts depend on no longer covers the witness. A new weight limit counts witness bytes less than base bytes.
BIP 35 · 2012 · Design paper
mempool message
BIP 35, mempool message. Make a network node's transaction memory pool accessible via a new "mempool" message.
BIP 37 · 2012 · Design paper
Connection Bloom filtering
BIP 37, Connection Bloom filtering. New support to the peer-to-peer protocol that allows peers to reduce the amount of transaction data they are sent.
BIP 67 · 2015 · Design paper
Deterministic Pay-to-script-hash multi-signature addresses through public key sorting
BIP 67, Deterministic Pay-to-script-hash multi-signature addresses through public key sorting. A method to deterministically generate multi-signature pay-to-script-hash transaction scripts.
BIP 87 · 2020 · Design paper
Hierarchy for Deterministic Multisig Wallets
BIP 87, Hierarchy for Deterministic Multisig Wallets. A sane hierarchy for deterministic multisig wallets based on an algorithm described in BIP-0032 (BIP32 from now on), purpose scheme described in BIP-0043 (BIP43 from now on), and multi-account hierarchy described in BIP-0044 (BIP44 from now on).
BIP 90 · 2016 · Design paper
Buried Deployments
BIP 90, Buried Deployments. Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated via miner signaling in block version numbers.
BIP 125 · 2015 · Design paper
Opt-in Full Replace-by-Fee Signaling
BIP 125, Opt-in Full Replace-by-Fee Signaling. Many nodes today will not replace any transaction in their mempool with another transaction that spends the same inputs, making it difficult for spenders to adjust their previously-sent transactions to deal with unexpected confirmation delays or to perform other useful replacements.
BIP 144 · 2016 · Design paper
Segregated Witness (Peer Services)
BIP 144, Segregated Witness (Peer Services). New messages and serialization formats for propagation of transactions and blocks committing to segregated witness structures.
BIP 157 · 2017 · Design paper
Client Side Block Filtering
BIP 157, Client Side Block Filtering. A new light client protocol in Bitcoin that improves upon currently available options.
BIP 352 · 2023 · Design paper
Silent Payments
BIP 352, Silent Payments. We use the following functions and conventions: ''outpoint'' (36 bytes): the COutPoint of an input (32-byte txid, least significant byte first || 4-byte vout, least significant byte first) '''Why are outpoints little-endian?''' Despite using big endian throughout the rest of the BIP, outpoints are sorted and hashed matching their transaction serialization, which is little-endian.
BIP 388 · 2023 · Design paper
Wallet Policies for Descriptor Wallets
BIP 388, Wallet Policies for Descriptor Wallets. Software wallets and hardware signing devices typically partition funds into separate "accounts".
EIP 140 · 2017 · Design paper
REVERT instruction
EIP 140, REVERT instruction. The REVERT instruction provides a way to stop execution and revert state changes, without consuming all provided gas and with the ability to return a reason.
EIP 141 · 2017 · Design paper
Designated invalid EVM instruction
EIP 141, Designated invalid EVM instruction. An instruction is designated to remain as an invalid instruction.
EIP 145 · 2017 · Design paper
Bitwise shifting instructions in EVM
EIP 145, Bitwise shifting instructions in EVM. Native bitwise shifting instructions are introduced, which are more efficient processing wise on the host and are cheaper to use by a contract.
EIP 196 · 2017 · Design paper
Precompiled contracts for addition and scalar multiplication on the elliptic curve alt_bn128
EIP 196, Precompiled contracts for addition and scalar multiplication on the elliptic curve alt_bn128. Precompiled contracts for elliptic curve operations are required in order to perform zkSNARK verification within the block gas limit.
EIP 197 · 2017 · Design paper
Precompiled contracts for optimal ate pairing check on the elliptic curve alt_bn128
EIP 197, Precompiled contracts for optimal ate pairing check on the elliptic curve alt_bn128. Precompiled contracts for elliptic curve pairing operations are required in order to perform zkSNARK verification within the block gas limit.
EIP 211 · 2017 · Design paper
New opcodes: RETURNDATASIZE and RETURNDATACOPY
EIP 211, New opcodes: RETURNDATASIZE and RETURNDATACOPY. A mechanism to allow returning arbitrary-length data inside the EVM has been requested for quite a while now.
EIP 214 · 2017 · Design paper
New opcode STATICCALL
EIP 214, New opcode STATICCALL. To increase smart contract security, this proposal adds a new opcode that can be used to call another contract (or itself) while disallowing any modifications to the state during the call (and its subcalls, if present).
EIP 658 · 2017 · Design paper
Embedding transaction status code in receipts
EIP 658, Embedding transaction status code in receipts. This EIP replaces the intermediate state root field of the receipt with a status code indicating if the top-level call succeeded or failed.
EIP 684 · 2023 · Design paper
Revert creation in case of collision
EIP 684, Revert creation in case of collision. This EIP causes contract creation to throw an error when attempted at an address with pre-existing code.
EIP 712 · 2017 · Design paper
Typed structured data hashing and signing
EIP 712, Typed structured data hashing and signing. This is a standard for hashing and signing of typed structured data as opposed to just bytestrings.