EIPs function as the roadmap and recording of Ethereum’s upgrades. Every notable change to Ethereum’s software – for example, new transaction types or fee mechanisms – is documented by an EIP. Before an upgrade is merged into clients, its specification lives in the EIP repository. This makes the process transparent: developers, miners/validators, and users can all review exactly what is changing and why. In fact, the very first EIP (EIP-1) formally defined this process: “An EIP is a design document providing information to the Ethereum community, or describing a new feature for Ethereum”. In practice, then, EIPs are how the Ethereum community coordinates changes in an open, standardized way.

How EIPs Are Proposed and Approved

The EIP process is open and collaborative. Anyone can suggest an idea – often discussing it informally first on forums or community calls – and then write up an EIP describing the idea in detail. Typically, a proposer will start a discussion on the Ethereum Magicians forum or GitHub to refine the idea. Once a draft EIP is ready, an editor can merge it into the official EIP repository, assigning it an EIP number. At that point it officially enters the tracked process.

The stages are straightforward. Per EIP-1, an EIP begins as a Draft. It then goes through peer review (often on GitHub or in developer calls). When it’s mature, the author requests a “Last Call” for final community feedback. If no major objections remain, editors mark the EIP as Final, signaling it’s ready to be implemented. (Some proposals may also be marked “Deferred” if they’re good ideas but not urgent.) In short: Draft → Review → Last Call → Final. These stages ensure people can comment and revise the proposal – much like writing a report, getting feedback, and then finalizing it.

Importantly, there is no single arbiter deciding EIPs. Ethereum is run by a decentralized community of developers and node operators, not a central authority. As one expert puts it, Ethereum relies on “off-chain governance”: proposals are debated in biweekly dev meetings, GitHub threads, and public forums – but there is no on-chain vote or token-based election. If the core developers reach consensus that an EIP is solid, it gets implemented in the client software. Then, when that software is rolled out in a network upgrade (hard fork), the change becomes live on the blockchain. In that sense, EIPs are self-governing: they only become binding when enough client teams adopt them. This is similar to Bitcoin’s model – developers propose BIPs and node operators ultimately enforce them – rather than a formal democracy.

Case Study: EIP-1559 – Reforming Fees in the London Upgrade

A famous example of an EIP is EIP-1559, which overhauled Ethereum’s fee market in the 2021 London upgrade. Before EIP-1559, users had to bid fees in an opaque auction, often wildly overpaying. EIP-1559 introduced a new mechanism: every block has a base fee that the protocol computes based on demand, plus an optional priority tip to pay miners (validators) for faster processing. The base fee is burned (destroyed), while only the tip goes to miners.

The effect is twofold. First, it simplifies fee estimation. It’s analogous to a ride-share: “the cost to go from A to B is the same regardless of which driver picks you up (the base fee)… [and] you can add a tip to get picked up faster”. In other words, users no longer need to guess a bid; the network tells them the current price (base fee), and they simply add a tip if they want priority. Wallets like MetaMask can now show a reasonable fee estimate without complex bidding.

Second, by burning the base fee, EIP-1559 changed Ethereum’s monetary policy. Fees paid by users are no longer given to miners; they’re removed from circulation. This puts constant downward pressure on ETH supply. In fact, as one analysis notes, “fees paid after EIP-1559 will instead be destroyed (‘burned’), constricting the total supply of ETH. It is possible that ETH burned could exceed the newly minted ETH, resulting in a net-deflationary policy”. In practice, many ETH have been burned since London, making Ether a bit scarcer. However, the main intent was fairness, not explicit deflation – miners still receive tips and block rewards, but non-critical fees benefit holders (by increasing scarcity) rather than miners.

Overall, EIP-1559 dramatically improved the user experience. Gas fees became more predictable, avoiding the wild bidding game of before. The network now targets an 12.5 million gas-limit per block and adjusts the base fee by up to ±12.5% each block based on congestion. This means fees rise only gradually under demand, and users can choose to wait for a cheaper block if they wish. In short, EIP-1559 “simplifies the transaction fee process” and makes Ethereum’s fee market work more like a transparent toll system.

Case Study: EIP-4844 – Layer-2 Scaling with “Blob” Data

Another important recent EIP is EIP-4844 (also called proto-danksharding), finalized in March 2024. This proposal targets scalability for Layer-2 networks (rollups) by adding a special new transaction type carrying large temporary data chunks called “blobs.” These blobs are stored on Ethereum nodes for only a short time (about two weeks) and then dropped. The idea is like giving rollups a dedicated “bus lane” for data: rollup transactions can post bulky data cheaply to Ethereum without bloating the chain forever. As one analogy explains, imagine Ethereum as a highway: mainnet transactions are cars, rollups are buses carrying many users, and EIP-4844 essentially adds a dedicated bus lane.

The impact has been substantial. By adding blob space, EIP-4844 reduced Layer-2 transaction costs drastically. For example, on Optimism (an L2), per-transaction fees fell by about 1000× after blobs went live (though prices may rise later as demand grows). In effect, EIP-4844 made rollups far cheaper and more efficient without sacrificing decentralization. It is a first step toward Ethereum’s full sharding roadmap. Technically, EIP-4844 uses KZG commitments to certify blob data (forward-compatible with future data availability sampling), and it only requires changes in beacon nodes (not the execution layer).

In summary, EIP-4844 introduced large, ephemeral data storage for rollups – a game-changing upgrade for scaling. It slashed L2 fees and expanded capacity. Today, the network handles up to six blobs per block (each ~128 KB), which users can use for rollup data, knowing it will vanish after a couple of weeks. This has unlocked new use-cases and paves the way for even more aggressive future scaling (full danksharding).

Recent and Upcoming EIPs (2023–2025)

Ethereum follows a semi-annual upgrade cadence. Recent major hard forks have included multiple EIPs. For example:

• Shapella/Shanghai (April 2023). This upgrade (EIP-4895) finally allowed validators to withdraw staked ETH. Until then, staking was a one-way commitment; Shanghai completed the Proof-of-Stake transition by enabling both partial and full unstaking of ETH. (Developers also included other minor gas improvements in that fork.)

• Dencun (March 2024). This bundle of nine EIPs included EIP-4844 as described above, along with other protocol tweaks. (Post-merge upgrades like Dencun are mostly internal optimizations – for instance, various gas cost adjustments – but 4844 was the headline.)

• Pectra (May 2025). The Pectra upgrade (May 7, 2025) comprised 11 EIPs focused on developer/user experience, staking, and rollup efficiency. Notably, it enabled smart accounts by allowing Externally Owned Accounts (EOAs) to run code for one transaction. This means a normal user wallet can batch actions or sponsor gas without migrating to a contract-wallet. Pectra also boosted staking flexibility – for example, raising the validator max effective balance from 32 to 2048 ETH (EIP-7251) to lower entry barriers – and increased Layer-2 data capacity (doubling the allowed blobs per block, EIP-7691). In summary, Pectra made staking easier and doubled Ethereum’s L2 throughput, among other fixes.

• Fusaka (Nov/Dec 2025). The upcoming Fusaka hard fork (targeted Nov. 2025) packs in 11 EIPs aimed purely at scaling and node health. There are no user-facing changes; instead it adds advanced features like Peer Data Availability Sampling (PeerDAS, EIP-7594) to let nodes probabilistically verify rollup data without downloading everything. Fusaka also phases in more blob capacity per block (increasing from 6 to 15 to 21 blobs over time) to accommodate growing rollup traffick. Other EIPs include spam resistance checks (EIP-7825) to block malicious transactions, higher gas limits for increased throughput, and deterministic proposer scheduling (EIP-7917) for efficiency. In short, Fusaka is a behind-the-scenes boost: it expands rollup bandwidth, hardens security (spam limits, crypto op limits), and fine-tunes gas policies – all without breaking existing smart contracts.

Other EIPs on the horizon include continued work on sharding and layer2 support. Ethereum’s road map (the “Surge” and “Scourge” workstreams) envisions further blob capacity upgrades and eventually reducing block time. In all cases, each proposed change goes through the EIP process described above and will only be activated when the community is ready.

Governance: EIPs vs Bitcoin’s BIPs vs Polkadot’s Proposals

EIPs are Ethereum’s way of decentralized decision-making, but how does this compare to other chains?

• Bitcoin’s BIPs (Bitcoin Improvement Proposals): Bitcoin also uses a proposal system (BIPs) that is very similar in spirit to EIPs. A BIP is “a formal proposal to change Bitcoin”. Like Ethereum, anyone can draft a BIP and discuss it in public forums or mailing list. BIPs go through review by the Bitcoin community and developers. If consensus is reached, the proposed change is implemented in Bitcoin Core (or other software). Crucially, actual adoption is decided by the nodes and miners. For example, SegWit was defined in a BIP and its activation depended on miners/ nodes upgrading their software. In general, Bitcoin keeps governance off-chain and consensus is signaled by software adoption. As one explainer notes, “the BIP process organizes Bitcoin’s development” in absence of a central leader, and whether a change happens is “entirely decided by the nodes of the network”. Ethereum is similar: EIPs guide development, but changes only take effect if clients upgrade. (There is no formal “voting” token or centralized approval.)

• Polkadot’s Proposal System: Polkadot takes a very different approach. Governance in Polkadot is fully on-chain and voting-based. Any DOT holder can submit a proposal (often through the Polkadot governance app), and proposals become binding if they win a token-weighted referendum. In Polkadot, everything is recorded on-chain: proposals are encoded as transactions, votes are tallied on-chain, and approved changes automatically take effect. In other words, it’s like a blockchain democracy. For example, Polkadot’s OpenGov allows token holders to vote on treasury spending or network upgrades with a fixed voting period. As described in a Polkadot forum, “proposals are submitted as executable code, votes are recorded on the chain, and if passed, the changes automatically take effect”. This is the opposite of Ethereum’s model: Ethereum “relies almost entirely on off-chain governance,” with decisions coming via developer calls and GitHub discussions. Polkadot’s on-chain approach reduces ambiguity (all votes are public and binding), but requires users to engage in voting.

In summary, EIPs, BIPs, and Polkadot proposals all serve to coordinate changes, but with different mechanics. Ethereum’s EIPs are open proposals ratified by developer consensus off-chain. Bitcoin’s BIPs are similarly community-driven documents decided by node upgrade consensus. By contrast, Polkadot uses formal on-chain referenda. Each system reflects trade-offs between decentralization, speed, and transparency: Ethereum and Bitcoin favor flexible coordination, while Polkadot enforces changes through explicit voting.

Groups used in cryptography are typically finite. A common example is the integers modulo nn under addition (this forms an infinite or finite group depending on context) or under multiplication mod a prime. A subgroup of particular interest is the cyclic subgroup generated by an element: if g∈Gg∈G has order mm (so gm=egm=e), then the set {g0,e,g1,g2,…,gm−1}{g0,e,g1,g2,…,gm−1} is a cyclic group of order mm. In a finite prime-order group one often chooses a generator gg so that every group element is a power of gg (i.e. G=⟨g⟩G=⟨g⟩). For example, in the multiplicative group of integers mod pp, denoted Fp∗={1,2,…,p−1}Fp∗​={1,2,…,p−1}, if gg is a generator then its cyclic subgroup of order qq (with q∣p−1q∣p−1) consists of {1,g,g2,…,gq−1}{1,g,g2,…,gq−1} with gq≡1(modp)gq≡1(modp)n. Such cyclic groups underpin schemes like Diffie–Hellman and DSA.

Many groups of interest in cryptography are abelian (commutative). An abelian group satisfies a⋅b=b⋅aa⋅b=b⋅a for all a,b∈Ga,b∈G. Equivalently, one often uses additive notation a+ba+b with identity 00 and writes a+b=b+aa+b=b+a. Abelian groups are simpler to work with, and most practical cryptographic groups are abelian (for example, Z/pZZ/pZ under addition, or the multiplicative group Fp∗Fp∗​, or elliptic curve point groups). In such groups one freely uses notation like na=a+a+⋯+ana=a+a+⋯+a (repeated addition) or gkgk for repeated multiplication.

Fields and Finite Fields

A field is an algebraic structure with two operations (addition and multiplication) satisfying commutativity, associativity, distributivity, and the existence of additive and multiplicative identities and inverses (except 0 has no multiplicative inverse). Many cryptographic constructions use finite fields. The simplest example is the prime field FpFp​ for prime pp, consisting of the integers {0,1,…,p−1}{0,1,…,p−1} with addition and multiplication performed modulo pp. In other words, if pp is prime then

Fp={0,1,…,p−1},Fp​={0,1,…,p−1},

with a+ba+b and a⋅ba⋅b defined modp. This indeed satisfies all field axioms: addition and multiplication are closed, associative, commutative, and distributive, with identities 00 and 11, and every nonzero element has a multiplicative inverse (by Fermat’s little theorem).

In FpFp​ the set of nonzero elements Fp∗={1,…,p−1}Fp∗​={1,…,p−1} forms a cyclic multiplicative group of order p−1p−1. One typically works in a large prime-order subgroup: if qq is a prime dividing p−1p−1, one chooses a generator gg of the unique cyclic subgroup of order qq (so q ∣ (p−1)q∣(p−1) and gq≡1(modp)gq≡1(modp))n. In cryptographic key exchange (e.g. finite-field Diffie–Hellman), the base gg and prime pp are public parameters, and the security rests on the difficulty of solving exponentiation inversely (the discrete logarithm). Beyond prime fields, one also uses binary fields F2mF2m​ and extension fields FpnFpn​ in standards, but the prime-field FpFp​ model suffices for many protocols.

The Discrete Logarithm Problem

Central to many cryptosystems is the discrete logarithm problem (DLP) in a finite group. In a cyclic group G=⟨g⟩G=⟨g⟩ of order mm, the DLP is: given gg and an element h∈Gh∈G, find the integer kk (if it exists) such that

gk=h  .gk=h.

Equivalently, kk is the discrete logarithm of hh to the base gg. In multiplicative notation this is gk=hgk=h, and in additive notation (e.g.\ in an elliptic curve) one writes kP=RkP=R. For an elliptic curve group, NIST observes that if R=kPR=kP then kk is called the discrete logarithm of RR to the base p. The DLP is believed to be hard when GG is chosen appropriately (large prime order, random generator). In fact, the security of Diffie–Hellman key exchange, DSA/ECDSA digital signatures, and related schemes depends on the intractability of computing discrete logs in either Fp∗Fp∗​ or elliptic curve group. (NIST explicitly states that approved key-establishment schemes “depend upon the intractability of the discrete logarithm problem in certain settings”) No subexponential-time classical algorithm is known for general DLP in suitably chosen groups.

Elliptic Curve Groups

An elliptic curve over a field KK (e.g.\ K=FpK=Fp​ or F2mF2m​) is given by a nonsingular cubic equation. In prime-characteristic fields it is common to use the short Weierstrass form

E:y2=x3+ax+b  ,E:y2=x3+ax+b,

where a,b∈Ka,b∈K and the discriminant 4a3+27b2≠04a3+27b2=0 ensures no singuarities. The points on EE are the affine solutions (x,y)∈K2(x,y)∈K2 satisfying the equation, together with a distinguished “point at infinity” OO. Remarkably, these points form a group under a geometric “chord-and-tangent” addition law: given two points P=(xP,yP)P=(xP​,yP​) and Q=(xQ,yQ)Q=(xQ​,yQ​) on EE, one draws the line through PP and QQ (or the tangent at PP if P=QP=Q), finds its third intersection RR with the curve, and then reflects RR in the xx-axis to obtain P+QP+Q. One verifies that this operation is associative, commutative, and has identity OO (the point at infinity)n. In particular, SEC 1 (a standard for ECC) explicitly notes that OO is a special point called the point at infinity, which serves as the additive identity of the elliptic curve group. By symmetry, the inverse of any point P=(x,y)P=(x,y) is simply −P=(x,−y)−P=(x,−y). Since A+B=B+AA+B=B+A for all points A,B∈EA,B∈E, the elliptic curve group is abelian.

Points on an elliptic curve over a finite field form a finite abelian group E(K)E(K). Its size #E(K)#E(K) is often (by Hasse’s theorem) roughly q+1q+1 if K=FqK=Fq​, and one usually selects a large prime divisor of #E(K)#E(K) as the order of the cryptographic subgroup. Concretely, standardized curves (such as those in NIST FIPS 186-5 or SEC 2) are chosen so that E(K)E(K) contains a cyclic subgroup of large prime order nn. Then a generator point G∈E(K)G∈E(K) of that subgroup is published. Scalar multiplication kGkG (adding GG to itself kk times) is easy, while the reverse problem (“given GG and kGkG, find kk”) is the elliptic curve discrete logarithm problem (ECDLP)n. The presumed hardness of ECDLP allows elliptic-curve Diffie–Hellman, ECDSA, etc., to achieve strong security at smaller key sizes than finite-field DLP schemes.

Standards bodies define many details of elliptic-curve groups. For example, NIST SP 800-186 (2023) surveys recommended elliptic curves over prime fields and explicitly mentions the curve secp256k1 (used by Bitcoin and Ethereum) as an approved curve for blockchain appications. SEC 1 (Standards for Efficient Cryptography, version 2.0) provides the mathematical foundations of ECC, including noting that the point at infinity OO is the additive identity. (SEC 1 also describes how to encode curve points to bytes, verify group membership, etc.) In practice, a standard curve such as secp256k1 or NIST P-256 is used as the underlying group; cryptographic protocols then operate on the subgroup generated by its base point.

Discrete Logarithm Hardness

The difficulty of the discrete logarithm problem in these groups is critical. In a prime field group Fp∗Fp∗​, the best known classical attacks are sub-exponential (e.g. number field sieve), but for elliptic curves no sub-exponential classical attack is known. NIST and others note that if the group’s order nn is a large prime, then computing kk from GG and kGkG (or computing xx from gg and gxgx) is assumed hard. This is why ECC allows 256-bit keys to match roughly 3072-bit RSA security: ECDLP appears much harder to solve for equivalently sized parameters. Standards such as FIPS 186-5 specify domain parameters (curve coefficients, base point, order nn) so that the subgroup is prime-order and cofactor small, maximizing DLP difficulty. Ethereum’s key agreement (ECDH) and signature (ECDSA) schemes implicitly rely on secp256k1’s DLP hardness.

Ethereum and secp256k1

In the Ethereum protocol, each account’s key pair uses the secp256k1 elliptic curve. The Ethereum Yellow Paper formally specifies that a private key prpr is mapped to a public key via ECDSA on secp256k1, and then to an address by taking the rightmost 160 bits of the Keccak-256 hash of the public key. In equations (ref. (214)–(215) of the Yellow Paper), if KEC(⋅)KEC(⋅) denotes Keccak-256 and ECDSAPUBKEY(pr)ECDSAPUBKEY(pr) the 64-byte public key on secp256k1, then the address is

A(pr)=KEC(ECDSAPUBKEY(pr))96..255 ,A(pr)=KEC(ECDSAPUBKEY(pr))96..255​,

i.e. bits 96–255 of the hash. The Yellow Paper also enforces the requirement 0<r,s<secp256k1n0<r,s<secp256k1n in signatures (where secp256k1nsecp256k1n is the curve order). More simply, Ethereum uses the same curve and signature scheme as Bitcoin, but with Keccak-256 instead of SHA-256 for hashing. In sum, secp256k1’s use in Ethereum is explicitly acknowledged by standards: NIST SP 800-186 even lists secp256k1 as a curve allowed for blockchain-related use, and the Ethereum spec (Yellow Paper) defines addresses and signatures in terms of secp256k1 ECDSA.

Conclusion

Group theory provides the algebraic backbone of cryptography. Formalizing groups (closure, associativity, identity, inverses) and special cases like abelian group and fields lays the foundation. Cryptographic protocols rest on finite fields (e.g.\ FpFp​) and on elliptic curve groups (points on y2=x3+ax+by2=x3+ax+b over FqFq​). The key hardness assumption is the discrete logarithm problem in these groups. Modern standards (FIPS, SEC, etc.) codify specific groups and parameters: for example, SEC 1 states that the elliptic-curve “point at infinity” is the group identity, and NIST SP 800-186 officially recognizes secp256k1 for blockchain use. Ethereum’s usage of secp256k1 (Yellow Paper definitions) is a concrete example: each Ethereum account is an ECDSA key on an elliptic-curve group, and security derives from group properties and DLP hardness. In sum, rigorous group-theoretic concepts pervade cryptography, from defining the algebraic setting to ensuring the intractability that underlies protocols.

References: Formal definitions and discussions of groups can be found in algebra texts (cf. math.mit.edu). NIST and SECG documents detail cryptographic applications: e.g. NIST SP 800-186 (2023) on elliptic curvesnvlpubs.nist.govnvlpubs.nist.gov, NIST SP 800-56A on discrete-log key schemesnvlpubs.nist.govnvlpubs.nist.gov, and SEC 1 v2.0 on ECC foundationssecg.org. Ethereum’s Yellow Paper (formal spec) provides the exact definitions of addresses and signatures using secp256k1files.gitter.im.

Ethereum’s shift is epitomized by the rollup-centric roadmap. In this vision, L2 rollups handle most computation and transaction execution, while Ethereum L1 focuses on finality, data availability, and security. Vitalik Buterin and others have articulated that Ethereum’s base chain should prioritize raw data throughput over on-chain computation. In practice, that means increasing the amount of data per block (through sharding and “blobs”) and keeping computation minimal. As one Ethereum roadmap summary explains, “the only determinant of rollup scalability is how much data the chain can hold”, since rollups post transaction data to L1 for security. In the short term, base-layer improvements like proto-danksharding (EIP-4844) have already increased this capacity, allowing rollups to include large ephemeral data “blobs”. Crucially, features that mainly affect L1 execution (like new opcodes or account abstraction) become relatively less urgent, because most application logic will run on L2. Instead, core dev efforts emphasize data throughput and stateless client support (e.g. binary trees and stateless precompiles) to scale rollups.

At the same time, Ethereum’s infrastructure and UX must adapt. Users will hold assets and run dapps mainly on L2s, so things like ENS names, wallet support, and cross-rollup transfers need to migrate off L1. For example, proposals are underway for registering ENS names on rollups, and wallets (like MetaMask) are being extended to speak rollup chains natively. Interfaces and bridges must be unified so moving tokens between rollups is frictionless.

Shared and L1 Sequencing – Rethinking Transaction Ordering

A key assumption of Ethereum’s past is that L1 provides the universal transaction ordering and finality. In a fully modular system, however, this assumption is breaking. Today each rollup typically runs its own sequencer: a centralized (or committee) operator that orders that rollup’s transactions. But new designs are exploring shared or L1-driven sequencing, where multiple rollups rely on a common ordering layer. For instance, shared sequencer networks (e.g. Astria’s shared sequencer) propose a rollup-agnostic set of sequencers that process transactions for many rollups in one network. As Maven 11 explains, a shared sequencer cluster “can serve a cluster of different rollups”, aggregating transactions to improve throughput and ensure fuller blocks. Other proposals adopt L1-based sequencing: the L1 block proposer directly includes rollup blocks (“based rollups”). In Justin Drake’s terminology, a based rollup is one where the next L1 proposer (together with searchers/builders) can permissionlessly include the rollup’s block in the L1 block, inheriting Ethereum’s liveness and censorship resistance.

These innovations aim to reduce fragmentation. CoinShares research notes that current rollups have “asynchronous and proprietary sequencing,” leading to a “fragmented global state” and liquidity largely stuck on L1. By sharing sequencers or tying sequencing to L1, rollups can better interoperate and automatically send MEV and fees to Ethereum’s ecosystem. For example, a based rollup forgoes its own MEV extraction so that searchers and proposers capture rollup MEV on L1, aligning economic incentives with Ethereum. Shared sequencing similarly pools traffic for many rollups, which can improve censorship resistance and liveness (since many nodes, rather than a single sequencer, guarantee inclusion).

However, these approaches challenge L1 assumptions. If multiple rollups rely on an external sequencer set, it shifts trust from Ethereum’s one million validators to smaller sequencer networks. Similarly, based rollups constrain sequencing flexibility (for example, pre-confirmations or FCFS ordering become harder). The trade-off is between pure decentralization (each L2 independent) and efficiency/interoperability. In sum, while rollups and shared sequencing greatly boost scalability, they require new trust models and raise questions about where security ultimately resides.

EigenLayer Restaking: A Universal Trust Marketplace

Meanwhile, EigenLayer is a leading experiment in extending Ethereum’s security via restaking. EigenLayer lets ETH stakers restake their deposits (beyond securing L1) to secure other services called Actively Validated Services (AVSs) — for example bridges, or new DA networks. In effect, it turns ETH into a “universal trust marketplace.” Validators can opt in to validate any AVS, allowing these services to “tap into Ethereum’s established trust”. As the EigenLayer whitepaper notes, it “creates a free market for decentralized trust, delivered from Ethereum stakers to modules that desire stake and validation services”. In practical terms, an EigenLayer AVS bundles an additional smart contract that specifies custom slashing rules. An honest ETH staker joins by approving this contract, and then its stake is slashed if the AVS’s rules are violated.

This model has several attractions. ETH stakers earn extra yield by “rehypothecating” their staking power. New protocols gain instant security without bootstrapping their own validator set. For example, EigenDA (a DA layer built on EigenLayer) already has ~4.3 million ETH staked behind it – literally billions of dollars of security at launch. Since the same ETH secures both Ethereum and the AVSs, incentives align: reputation or penalties flow directly to ETH, and MEV from AVS work can ultimately benefit Ethereum’s economy. Blocknative’s analysis emphasizes that EigenLayer “endeavors to establish a decentralized trust marketplace by harnessing Ethereum’s inherent decentralized trust”. In other words, ETH’s security is being programmatically reused to secure a broader ecosystem.

Of course, restaking introduces new risks. With the same ETH backing multiple services, a catastrophic failure in one AVS (e.g. a slashing event) could affect Ether’s stakers. EigenLayer’s design therefore includes “guard rails” and requires robust audits. But the intent is clear: rather than fracturing security across many chains, Ethereum is leveraged to back even more chains and services. EigenLayer essentially makes ETH a credential that can be rented out, which could strengthen Ethereum’s influence if successful.

Data Availability Wars: Blobs, Celestia, EigenDA, and Beyond

A central battleground in Ethereum’s modular future is data availability (DA). Rollups need to publish data so anyone can reconstruct the state; doing this on the congestion-prone Ethereum L1 has always been costly. With the surge in L2s, specialized DA solutions have emerged. Ethereum’s interim answer is EIP-4844 (Proto-Danksharding), which introduces large temporary data blobs. Since the Dencun upgrade (Mar 2024), each block can carry up to 6 blobs (each ~128 KB), vastly more data than traditional calldata. These blobs are cheaper than calldata (drastically cutting L2) but persist only ~18 days off-chain. In practice, EIP-4844 has slashed rollup fees: it caused some optimistic rollup costs to drop by ~98%. However, EIP-4844 still has limits. As the Eclipse project notes, big rollups like Arbitrum still paid ~$90K/month and Base ~$300K/month in blob fees, and there simply isn’t enough blob capacity for truly high-throughput chains.

Enter dedicated DA networks. Celestia was the first such network: a modular blockchain that does only ordering and data availability (using Data Availability Sampling). Celestia’s mainnet launched with 2–8MB blocks (upgradeable on-chain), and plans to scale up to ~1GB blocks. Unlike Ethereum’s modest 64-blob goal (~8–16MB), Celestia already handles orders of magnitude more data per block. In practice, rollups using Celestia have found data posting significantly cheaper: one analysis shows Celestia costs about $7.31/MB of data, compared to $20.56/MB using Ethereum blobs. (Notably most Celestia rollups’ total cost still goes to settlement on Ethereum, but the DA portion is much lower.) By pooling many rollups’ data, Celestia can amortize overhead and scale throughput aggressively.

Other DA projects are vying for attention. Avail is another DA-specific chain (launching on Polygon) that uses validity proofs for quick DA finality. Like Celestia, Avail supports block expansion; currently ~4MB blocks, with benchmarks up to 128MB. Avail’s design aims for near-instant finality (no fraud-proof window) at the expense of validator “blame games” (a standard trade-off).

EigenDA is a nascent approach built on EigenLayer. Rather than a public blockchain, EigenDA is a Data Availability Committee (DAC) with restaked ETH validators. In lab tests, EigenDA achieved ~100 MB/s throughput and plans to push toward 1 GB/s. Its advantage is eliminating the on-chain DA bottleneck via erasure-coding and KZG proofs. It also natively leverages Ethereum for settlement and security: rollups simply include an EigenDA blob’s KZG proof on L1 for checkpointing. However, because EigenDA is not a public blockchain, public verification is replaced by trust in the DAC’s attestations.

Several projects even propose integrating bridges and DA across ecosystems. For example, Cosmos’ IBC (Inter-Blockchain Communication) and projects like Sunrise envision interoperable DA/liquidity layers that span Ethereum, Solana, etc. But the core dynamic remains: rollups may choose between posting data on L1 (blobs), on Celestia, on Avail, on EigenDA, or hybrid schemes. Each choice has trade-offs in trust, cost, and latency. Ethereum’s approach (blobs + future full sharding) is trust-minimized but limited in capacity. External DA chains offer huge capacity and reduced fees, but introduce new economic security models (IBC bridges, token-based staking, DAC trust assumptions).

To summarize the DA comparisons: Ethereum with EIP-4844 offers ~128 KiB blobs and a target of 3–6 blobs/block, with up to ~~8 MB per block in ultimate full sharding. Celestia starts at multi-MB blocks (8 MB today, aiming 1 GB) and finalizes data after a short fraud-proof period. Avail currently does ~4 MB blocks (expandable to hundreds) with instant validity proof finality. EigenDA touts tens of MB/s but only provides attestation via Ethereum. In practical rollup use, Celestia and EigenDA are already hosting multi-GB daily data volumes for large rollups, far beyond what Ethereum’s blobs can handle. Thus the “data availability wars” continue: Ethereum will scale by sharding over time, but specialized DA networks compete fiercely to become the preferred publish layer for rollups.

Security and Value Capture: Fragmentation vs. Reinforcement

All these shifts raise the question: does modularity weaken or strengthen Ethereum’s core? Opinions vary. On one hand, Ethereum’s high-assurance consensus (PoS with >1M validators) can now undergird a vast ecosystem. With mechanisms like EigenLayer restaking, Ethereum’s security is literally being shared with new services, potentially reinforcing ETH’s economic role. Many researchers emphasize designing rollups and bridges to remain “Ethereum-aligned.” The proposed Ethereum Settlement Score (ESS) framework quantifies this: it finds that many current L2s use only ~25–30% on-chain Ethereum settlement (most activity uses third-party bridges or L2 tokens). ESS advocates argue that future “Stage 3 native rollups” and features like force-inclusion or instant ZK withdrawals will ensure L2s export censorship resistance back to Ethereum. In this view, modularity is a net positive: Ethereum becomes the ultimate settlement and censorship-resistant source for a much larger volume of transactions, without bloating its own chain.

On the other hand, there is a cautionary perspective. Some industry analysts warn that offloading so much to L2s risks diluting Ethereum’s value. A recent analysis by IOSG/PA News observed that rollups could become “insurmountable moats” with strong network effects, eventually relegating Ethereum to a “commoditized” settlement layer. Indeed, if most activity and fees flow to L2 tokens, ETH holders may see diminished returns. The CoinShares research blog similarly points out that asynchronous rollup design has “fragmented” Ethereum’s composability. Coordination among rollups is harder, and liquidity tends to stick to whichever chains have the most activity. This fragmentation erodes the one-chain perspective that once gave Ethereum its strength.

In practice, the outcome will depend on alignments and interoperability. New proposals like “based rollups” and shared sequencers explicitly channel MEV and priority fees back to Ethereum, while projects like Sunrise aim to reintegrate liquidity across chains. Ethereum’s core developers have also signaled that modularity does not imply abandoning decentralization: they envision eventually running one high-security execution shard (for consensus) alongside many data shards. If implemented, this would mean most L2s post data only, but final execution results could still be committed to the single Ethereum execution layer.

Overall, modularity is fracturing assumptions but not necessarily fracturing security. Ethereum’s evolution into a network of networks creates tension between specialization (which benefits performance) and cohesion (which benefits value capture). The cutting-edge work happening now — from rollup design to EigenLayer AVSs to DA research — will determine whether Ethereum ultimately reinforces its dominance by acting as a ubiquitous settlement layer, or whether value and trust diffuse into a more fragmented web of chains. In either case, this modular future is crucial for scaling, decentralization, and “future-proofing” Ethereum’s architecture.

Sources: The analysis above synthesizes Ethereum core-dev discussions, protocol whitepapers, and recent research.

Key references include Vitalik Buterin’s rollup-centric roadmap ethereum-magicians.orgethereum-magicians.org, the EigenLayer whitepaper docs.eigencloud.xyz and documentation docs.eigencloud.xyz, comparative DA studies conduit.xyz eclipse.xyz blog.availproject.org, and fragmentation analysis panewslab.comethresear.ch. These illustrate how execution, data, and security are being re-engineered across layers in Ethereum’s evolving ecosystem.

Coordination vs. Traditional Institutions

In political science and economics, institutions are formal structures or norms that coordinate individual actions and stabilize expectations. Historically, institutions (governments, corporations, banks, etc.) achieved coordination through centralized authority and trust: e.g. a government enforces laws, a CEO directs a company, a bank guarantees transactions. These hierarchical organizations suffer from information bottlenecks, slow reaction to change, and concentration of power. By contrast, Ethereum enables distributed coordination: the blockchain itself is the neutral ledger, and rules are enforced by consensus. No single party needs to be trusted. For example, De Filippi et al. observe that “Ethereum eliminates the need for trust between parties as well as the need for a centralized entity coordinating them” – people can thus “coordinate themselves, in a trustless and decentralized manner, without relying on any third-party institution”. In effect, Ethereum provides a self-enforcing institution: agreements (smart contracts) execute automatically without lawyers or courts, and state transitions are finalized by consensus nodes rather than elected officials. As a result, Ethereum has been described as a “decentralized alternative to the notion of organization per se”.

From an institutional-theory perspective, blockchain networks can even be modeled as polycentric governance systems (a concept developed by Vincent and Elinor Ostrom). In a polycentric system there are multiple overlapping authorities and flexible rules rather than a single hierarchy; crucially, actors can enter or exit and duplicate functions without permission. This framework fits Ethereum well. The Ethereum network itself is governed by code and decentralized consensus, while countless DAOs (decentralized organizations) and smart-contract protocols form overlapping centers of decision-making. According to De Filippi et al., polycentricity allows us to understand blockchain systems’ structure, process, and outcome. Likewise, Madison et al. (2022) interpret blockchains as “knowledge commons” – community-managed platforms that pool distributed information for collective governance. In each case, the core idea is that Ethereum’s open protocols enable a new kind of institutional order: one built on shared code and cryptographic rules, not top-down command.

Game Theory and Coordination Primitives

Ethereum’s design mirrors classic game-theoretic solutions to coordination problems. Smart contracts act as credible commitment devices: parties can lock in future actions without fear of reneging, because the code enforces them. This extends the “program equilibrium” literature (Tennenholtz 2004, Kalai et al. 2010) to one-shot interactions: users submit algorithms (contracts) that react to others’ actions, and equilibrium outcomes are enforced by the blockchain. For example, in a public-goods game, a smart contract can automatically trigger refunds or rewards based on participants’ choices, overcoming free-rider issues that plague informal agreements. Indeed, Gudmundsson and Hougaard show that blockchain commitment devices can “overcome trust and free-riding barriers” in investment and public-good games.

Another key coordination concept is the Schelling point (focal point) – a default solution that people converge on absent communication. In blockchains, the global state and protocol rules act as Schelling points. The blockchain’s immutability and transparency establish a common “truth” that every actor can anticipate. As a Vitalik glossary notes, a Schelling point on a blockchain is “a conclusion that agents will tend to converge on when they cannot communicate with each other”. Importantly, Ethereum can even encode Schelling points into software: for instance, emergency recovery processes or voting triggers can be hardcoded so that “large groups of people quickly coordinate around a single path forward,” as Vitalik discusses. In short, the Ethereum protocol itself provides mechanical focal points for coordination.

Beyond these primitives, several market mechanisms emerge organically on Ethereum as coordination layers. A prominent example is MEV (Maximal Extractable Value) auctions. Since The Merge (2022), Ethereum implements Proposer-Builder Separation: independent block builders bid to construct profitable blocks, and proposers (validators) sell these slots via MEV-Boost auctions. This creates a competitive market where builders align to pack each block with the most valuable transactions (arbitrages, liquidations, etc.), and proposers select the highest bid. In game-theory terms, MEV auctions are a coordination game: many miners and searchers coordinate on transaction ordering through price signals. As one model explains, builders submit bids representing priority fees and payments from searchers (“indicative of the amount of MEV opportunities” in the block). Though not intentionally designed as a governance tool, MEV markets illustrate how economic incentives on Ethereum spontaneously coordinate otherwise-independent agents to achieve a common outcome (maximizing total block value).

Ethereum also instantiates collective decision games. Token-voting is a form of weighted voting, akin to the governance structures in corporations or parliaments. Newer schemes like Quadratic Voting/Funding are being used to better aggregate community preferences. Gitcoin Grants is a clear case: it uses quadratic funding to allocate public-good grants. Rather than a committee, Gitcoin runs funding “rounds” where community members donate and a matching pool allocates funds quadratically (more contributors to a project triggers larger matching). This mechanism is explicitly designed to be “more democratic” than centralized grantmaking: every donor signals support, but the number of contributors matters more than dollar. As Gitcoin’s blog emphasizes: “We are merely the tool by which [the community] chose to deploy the funds. Gitcoin Grants is a coordination layer to connect these projects to contributors.”. In other words, Gitcoin (built on Ethereum) is effectively an institutional infrastructure coordinating funding decisions at scale. No traditional organization or hierarchy is needed – the protocol and community voting rules align incentives to fund public software.

Case Studies in Ethereum Coordination

• Gitcoin Quadratic Funding: Gitcoin’s Grants program shows Ethereum as a public-goods coordination layer. By pooling a matching fund and distributing it via quadratic formulas, the community collectively chooses open-source projects to support. Instead of a single foundation board, thousands of small contributors coordinate through the protocol: projects that many people care about (even if each gives a little) receive outsized funding. This has funded millions for Ethereum-related infrastructure. The system explicitly tries to reflect community sentiment (“the number of contributors matters more than the amount funded”), and Gitcoin itself states that it is simply the coordination layer linking donors to projects. Gitcoin’s success shows how crypto-economic design can solve the classic public-goods problem in a way traditional funding models do not.

• Nouns DAO: Nouns is an NFT-based DAO with a novel perpetual-auction governance model. One Noun (a pixel-art avatar NFT) is minted and auctioned every day, and the entire ETH proceeds go into a community treasury. Each Noun holder has one vote in DAO governance, and auctions are auto-triggered: “settlement of one auction kicks off the next”. This creates a rhythm and focal point for the community: each day, participants decide how the treasury will be used. All Nouns (NFTs) are essentially members of the DAO, and there are no pre-set beneficiaries – the community coordinates spontaneously on proposals. Because the process is fully on-chain and trustless, participants need not trust any organizers. As a result, Nouns DAO has become a continuously running coordination mechanism: it unites art, tokenomics, and governance into one protocol. It exemplifies how Ethereum can sustain a living constitution – the code defines the institution’s mechanics, and holders coordinate political and cultural values around it.

• EigenLayer Restaking: A recent innovation, EigenLayer, introduces “restaking” to coordinate blockchain security. Traditionally, each new network or service (e.g. a rollup, oracle, or sidechain) must secure itself with its own token and validators. EigenLayer changes this: Ethereum validators can “opt in” their staked ETH to new modules on EigenLayer, reusing their trust for multiple services. In effect, ETH stakers share their security capital across many systems. The EigenLayer whitepaper describes this as pooled security via restaking, extending Ethereum’s security to “any system” and eliminating inefficiencies of siloed governance. From a coordination standpoint, EigenLayer is a marketplace: validators coordinate by choosing which external services to secure (based on rewards and risks), and developers coordinate by posting service opportunities that validators can join. It overlays a new dimension of coordination on Ethereum: the same stake links together different projects’ trust models. This is like a binding contract between chains and validators, enforced by the Ethereum protocol. While still experimental, EigenLayer’s concept underscores how Ethereum’s ecosystem can coordinate security and governance across independent systems, effectively forming a coordination network of networks.

Coordination Dynamics in Protocol Design

Ethereum’s underlying primitives enable novel coordination mechanisms:

• Smart Contracts as Credible Commitment: By hard-coding actions and outcomes in immutable contracts, Ethereum ensures that no party can renege. Gudmundsson & Hougaard formalize this as “a new take on credible commitment” – players can precommit to reaction strategies, turning one-shot games into enforceable agreements. In practice, DAOs often put large sums in multisig or contract-based escrow to signal serious intent (e.g. DAO treasury funds in a DAO-controlled vault). Mechanisms like time-locks, collateral bonds, or slashing conditions (all implemented via contracts) serve as commitment devices ensuring honest behavior. These digital commitments analogize to binding international treaties or corporate bylaws, but automated and transparent.

• MEV and Emergent Auctions: The competition for MEV illustrates spontaneous coordination. Builders and validators bid in MEV-Boost auctions to include profitable bundles of transactions. Searchers (arbitrageurs, liquidators) prepare bundles with attached payments; builders incorporate the best bundles into blocks; proposers pick the highest bids. Though adversarial in nature, this process self-organizes for mutual benefit: builders get MEV revenue, proposers earn more fees, and users’ transactions get executed in a welfare-maximizing order. This market-like mechanism arose organically out of protocol changes, showing how economic incentives can coordinate the blockchain’s internal state without any human management.

• Blockchain Consensus and Public Goods: Ethereum’s proof-of-stake consensus itself can be seen as a coordination game. Every validator has incentives (rewards/penalties) designed to align on a common chain. MEV aside, the protocol rewards honest consensus and punishes conflicting blocks (slashing), making the honest chain a Schelling point. The network’s very design is a game where following protocol is a dominant strategy, because any deviation can be detected and penalized. Thus, the consensus mechanism functions as an institution for coordination (with no central authority), reflecting game-theoretic design principles.

• Schelling and Oracles: Beyond code, Ethereum leverages oracles and on-chain data as coordination tools. Many oracle systems (like Chainlink) operate via Schelling mechanisms: multiple parties submit data, and the median or consensus value is adopted as truth. This is literally using a Schelling point of pooled answers. Prediction markets (e.g. Augur, Polymarket) similarly harness common knowledge: participants converge on the true probability of events. In coordination terms, these systems let markets or collective heuristics solve uncertainties (e.g. real-world data, event outcomes) so that smart contracts can align actions on widely-agreed facts.

Political Theory Perspectives

Framing Ethereum in political-science terms highlights its novelty:

• Polycentric Governance: As noted, Ethereum embodies polycentricity. Unlike a state with one sovereign, Ethereum hosts myriad rule-enforcers (developers, miners/validators, DAOs, users) who each have autonomy but share protocol-level constraints. This mirrors Elinor Ostrom’s vision of complex systems where multiple authorities coexist and compete under a common framework. Ostrom’s work shows that such polycentric systems can manage commons effectively through local knowledge and varied rules. Ethereum’s model is congruent: it coordinates a global commons (the blockchain) without centralized oversight, relying on layered rules (protocol code, DAO constitutions, economic incentives) that participants themselves create and modify.

• Public Choice and Legitimacy: Public choice theory studies how groups make collective decisions. Ethereum changes the calculus: the costs of participation, voting, and coordination are dramatically lower. For example, anyone can propose an Ethereum Improvement Proposal (EIP) or submit a pull request in an open-source repo; token holders can vote in governance forums; users can signal support via spending decisions. The system’s legitimacy derives from transparency and distributed verification: protocol changes must pass through multiple “coordination institutions” (e.g. community discussion, voting on funding, client updates). Vitalik emphasizes that Ethereum’s future depends on “legitimacy production” – its ability to let communities enact change without coercion. In effect, Ethereum is a laboratory for participatory governance, where theory of democracy and collective action meets code.

• Hayekian Knowledge and Decentralization: Friedrich Hayek argued that markets outperform central planning because they aggregate dispersed information via price signals. Ethereum extends this insight: price and vote signals (e.g. token prices, bounty markets, gas fees) coordinate actors around scarce resources. But Ethereum goes further by codifying rules: rather than an invisible hand, it has an “auditable hand” – everyone sees the rules and state changes. In this sense, Ethereum is a perfect-information market of protocols: the knowledge about past decisions is on-chain and visible to all, reducing uncertainty in coordination. The platform therefore mitigates informational asymmetries that beset traditional institutions.

• Schelling’s Coordination: Thomas Schelling’s work on focal points and credible commitments underpins much of blockchain coordination. Schelling noted that people often converge on salient options in ambiguous situations. On Ethereum, the protocol and widely-used contract standards serve as predefined focal points. For instance, the ERC-20 token standard gives a common language for value transfer. More abstractly, many DAOs pre-commit to schemes like 1-token-1-vote, regularly scheduled auctions, or time-locked fund releases. These conventions become the Schelling equilibria around which communities align. As Vitalik notes, even complex Schelling points “could potentially be implemented in code” on , further crystallizing coordination.

Speculative Coordination Mechanisms

Looking ahead, Ethereum’s architecture suggests many untapped coordination tools. Here are a few speculative ideas:

• Futarchy and Prediction-based Governance: Building on Robin Hanson’s futarchy, DAOs might vote on values (metrics) and then use on-chain prediction markets to choose policies that maximize those values. For example, a DAO could bet on outcomes (e.g. overall treasury growth) to decide investment allocations. The combination of auctions and bets (as explored in Ethereum research) could yield incentive-compatible decision rules far richer than simple voting. Some researchers even propose hybrid VCG-style voting auctions that incorporate truthful preference reporting and predictions. Implementing such schemes could allow communities to aggregate both their preferences and information in complex public-good choices.

• Reputation and Commitment Schemes: New cryptographic identity systems could enable on-chain reputations or proof-of-stake commitments for social coordination. For instance, protocols might issue reputation NFTs to individuals or DAOs, reflecting past reliable contributions. These reputations could weight votes or trigger trustless credit lines. Similarly, smart contracts could allow groups to form trust committees: e.g. sharded validators or citizen juries that coordinate by cryptographic lottery. Ethereum already supports verifiable credentials and zk-proofs; leveraging these could yield sophisticated coordination games where truthfulness and identity matter.

• Algorithmic Coalitions: Smart contracts could facilitate the creation and coordination of temporary coalitions for common tasks. For example, consider a protocol where stakeholders can dynamically form and dissolve alliances based on cost–benefit rules: if a group of DAOs agree to share or reassign funds and votes under certain conditions, a contract could automatically enact the agreed plan when triggers occur. This is like corporate mergers or treaty clauses automated on-chain. By encoding mechanisms for coalition formation, Ethereum could enable flexible networks of organizations (e.g. research consortia, ad-hoc public projects) to coordinate resource pooling and decision-making without bureaucracy.

• Constitution DAOs and Layered Governance: Just as countries have constitutions, Ethereum might see constitutional DAOs that set binding meta-rules for other DAOs or protocols. For instance, a “DAO of DAOs” could formalize principles (transparency, minority rights, exit options) and enforce them by controlling funding or development access. Smart contracts could enforce these constitutional rules across projects. Layer-2 solutions (rollups) might also embody unique governance that coordinates with Ethereum’s Layer-1 – creating a hierarchy of coordination layers. Designing such multi-level governance protocols is an open challenge but could dramatically expand how societies self-organize on-chain.

Each of these proposals is speculative, but they illustrate the space of possibilities: Ethereum isn’t limited to known financial primitives. Its composability (DeFi Lego bricks) allows entirely new coordination mechanisms to be invented. In the words of Shilina (2025), Ethereum “embodies a recursive, self-modifying philosophy – an open system where critique becomes code”. In practice, this means Ethereum can implement meta-coordination: the users themselves design and refine how they will coordinate, all transparently and iteratively.

Conclusion

Recasting Ethereum as a coordination layer shifts how we evaluate its impact. Instead of comparing it only to banks or cloud providers, we compare it to governments, regulatory bodies, and cultural institutions. Ethereum can align incentives across dispersed participants via code, solving Schelling problems at global scale. This is a profound intersection of game theory, political economy, and computer science.

The implications are vast: Ethereum-based systems could rival traditional institutions in domains like collective action, governance, and public goods funding. By facilitating transparent commitments and market-based coordination, Ethereum offers a model where “cooperation does not require trust” and governance is not a mysterious black box but a set of public algorithms. While many challenges remain (governance capture, inequality of stake, technical complexity), the platform’s open-ended design invites continuous innovation in organizing social and economic life. Viewed through political theory, Ethereum is not just about crypto-assets; it is about new forms of organization and collective decision-making – from credit unions run by smart contracts to on-chain federations of communities.

In sum, Ethereum functions as a digital coordination engine. It extends institutional economics into code, enabling humans, DAOs, and machines to converge on shared truths and actions at previously impossible speed and scale. As Davidson et al. (2018) argue, blockchains are “an institutional technology” and “an instance of institutional evolution”. Ethereum exemplifies this evolution by embedding coordination protocols directly into infrastructure. For researchers and practitioners, the task is to understand and design these protocols: to borrow from thinkers like Ostrom, Schelling, Hayek, and others; and to write the next lines of code that will coordinate our collective future.

References: Key sources include Ostrom’s polycentric theory research.ed.ac.uk, Vitalik’s essays on coordination nathanschneider.info nathanschneider.info, and analyses of Ethereum’s societal role policyreview.infomedium.com, as well as case studies like Gitcoin Grants gitcoin.co, Nouns DAO nftplazas.com, and EigenLayer docs.eigencloud.xyz. Each demonstrates how Ethereum’s protocols facilitate coordination where traditional institutions have failed or cannot reach.

Figure: Typical TLS 1.2 handshake sequence (ClientHello → ServerHello, Certificate, ServerKeyExchange, etc.)【2†】.

TLS 1.2: Signature Usage in Handshake

• Server Certificate: The server sends an X.509 certificate (chain) in the Certificate message. This certificate includes a public key (RSA or ECDSA) used for authentication.

• ServerKeyExchange (signed): If the chosen cipher suite uses ephemeral Diffie–Hellman (DHE or ECDHE), the server sends a ServerKeyExchange containing its ephemeral public parameters. These parameters are wrapped in a digitally-signed struct that covers the client random, server random, and DH/ECDH. The signature is computed with the server’s private key (matching the certificate). For example, in an ECDHE_RSA suite the server uses its RSA key to sign the parameters. The TLS 1.2 spec defines this as:

  ServerKeyExchange…signed_params; For non-anonymous key exchanges, a signature over the server’s key exchange parameters.
  The client then verifies this signature with the public key from the server’s certificate, ensuring the parameters came from the legitimate server.

• RSA Key Exchange (no signature): If the cipher suite uses plain RSA key exchange (TLS_RSA), the server does not send a ServerKeyExchange or Instead, the client encrypts a premaster secret with the RSA public key from the certificate. (Because no signed message is sent, TLS 1.2 does not use a digital signature in the handshake when static RSA key exchange is chosen.)

• Client Certificate (optional): If client authentication is used, the client sends its own certificate and then a CertificateVerify message. This contains a signature (over all handshake messages so far) made with the client’s private key to prove possession. As RFC 5246 notes:

  “If the client has sent a certificate with signing ability, a digitally-signed CertificateVerify message is sent to explicitly verify possession of the private key in the certificate.”.
  The server verifies this signature using the client’s public key from the certificate.

TLS 1.3: Signature Usage in Handshake

TLS 1.3 dramatically streamlines the handshake. All key exchanges are ephemeral (e.g. X25519 or ECDHE), and authentication signatures occur after the ServerHello. The message flow is: ClientHello → (HelloRetryRequest, if needed) → ServerHello → EncryptedExtensions → (CertificateRequest) → Certificate, CertificateVerify, Finished → [client’s auth if requested]. In particular:

• Server Certificate: The server sends its certificate chain in the Certificate message.

• CertificateVerify (signed): Immediately after the certificate, the server sends CertificateVerify, which is a signature over the entire handshake transcript (excluding the pending Finished). RFC 8446 states:

  “CertificateVerify: A signature over the entire handshake using the private key corresponding to the public key in the Certificate message.”This signature binds the server’s identity to the handshake. The client uses the server’s certificate public key to verify it.

• Client Authentication (optional): If the server requested client auth, the client will likewise send its Certificate and CertificateVerify. Each side then sends a Finished message (a MAC) to confirm key exchange integrity. As IBM’s documentation explains, after the server’s CertificateVerify and Finished, “the client responds with its own Certificate, CertificateVerify, and Finished”Thus in TLS 1.3 the only signature apart from Finished MACs is in the CertificateVerify messages. This replaces the TLS 1.2 ServerKeyExchange signature. TLS 1.3 also includes a final Finished message MAC that binds the shared keys to the transcript, ensuring handshake integrity

Signature Algorithms in TLS

TLS supports several public-key signature schemes. The choice of algorithm affects performance and security:

• RSA (PKCS#1 v1.5 and PSS): RSA signatures have long been supported. In TLS 1.2 the server commonly used an RSA certificate (e.g. 2048-bit) to sign the ServerKeyExchange or to decrypt the premaster. RSA signatures in TLS 1.3 can be either RSASSA-PKCS1-v1_5 or RSA-PSS. In fact, TLS 1.3 mandates support for RSA with SHA-256 in both PKCS#1v1.5 (rsa_pkcs1_sha256) and PSS modes (rsa_pss_rsae_sha256).

• RSA-2048 offers roughly 112 bits of security; larger keys (3072-bit) give ~128 bits, but at a cost of slower operations. RSA is widely supported (all implementations handle it) and simple to use, but its key sizes and computation cost are much larger than elliptic-curve schemes. Legacy v1.5 padding has had vulnerabilities (e.g. Bleichenbacher attacks and BERserk forgery), so RSA-PSS (which is stronger by randomizing padding) is preferred for new use. RFC 8446 (TLS 1.3) still lists PKCS#1v1.5 schemes but notes that RSASSA-PSS is required support.

• ECDSA (secp256r1/P-256, secp384r1, etc.): Elliptic Curve DSA offers similar security with much smaller keys. For example, P-256 (aka secp256r1) gives ~128-bit security with 256-bit public keys, vs. 3072-bit RSA. TLS 1.3 makes ECDSA-on-P-256 mandatory (ecdsa_secp256r1_sha256).

• P-384 (ecdsa_secp384r1_sha384) is also supported for higher security (~192-bit). ECDSA signatures are generally faster on modern CPUs (and very small in output size), though more complex to implement. They do require a good source of randomness for each signature (to avoid key leaks). In TLS, if an ECDSA certificate is used, all signatures (e.g. on ServerKeyExchange or CertificateVerify) are done with ECDSA. RFC 8422 explicitly defines an ECDHE_ECDSA key-exchange where the server’s ephemeral ECDH parameters must be signed with ECDSA or EdDSA by the certificate’s private key.

• (The table in RFC8422 calls it “Ephemeral ECDH with ECDSA or EdDSA signatures”)

• EdDSA (Ed25519, Ed448): Modern elliptic-curve signature schemes based on Edwards curves (Ed25519 and Ed448, standardized in RFC 8032) are increasingly supported. These schemes are very fast (especially signature verification) and deterministic (avoiding the random-nonce issue). TLS 1.3’s SignatureScheme list includes ed25519 and ed448

• In ECDHE_ECDSA suites, a certificate with an Ed25519 public key can be used, and the server may sign with Ed25519

• However, note that Ed25519 is relatively new to the TLS ecosystem. As of 2024, major web browsers and public CAs generally do not issue or accept Ed25519-signed certificates (e.g. the CA/Browser Baseline Requirements forbid Ed25519 in publicly-trusted certificates). Thus Ed25519 is rarely seen in mainstream TLS, but it can be used in private PKI or future deployments.

• Other algorithms: Legacy RSA/SHA1 (rsa_pkcs1_sha1) and ECDSA/SHA1 (ecdsa_sha1) are deprecated. TLS 1.3 removes them entirely. In fact, TLS implementations must reject MD5-based signatures and discourage SHA-1. RFC 8446 explicitly says any certificate requiring an MD5 signature algorithm must be rejected, and SHA-1 is deprecated to the point of handshake abort. (These hash weaknesses mainly affect the certificate signatures in the chain.) Current best practice is to use SHA-256 or better for all signature hashing.

TLS cipher suites are designed so that the certificate’s public-key algorithm matches the signature algorithm used. For example, in an ECDHE_RSA suite, the server’s RSA certificate key is used to sign (RSA); in ECDHE_ECDSA, the server’s EC key is used (ECDSA or EdDSA). TLS 1.3 provides negotiated “signature_algorithms” extensions so the client advertises which hash+sig schemes it supports. The mandatory-to-implement list for TLS 1.3 (RFC 8446) requires RSA/PKCS1-SHA256, RSA-PSS-SHA256, and ECDSA/P-256-SHA256, and recommends support for X25519 key exchange as well.

Signature Verification and Certificate Chain

Once the client receives the server’s signed handshake messages, it must verify the signatures and validate the certificate chain:

• Verify handshake signature: In TLS 1.2 ephemeral DHE/ECDHE, the client uses the server’s public key (from the first certificate) to verify the signature in the ServerKeyExchange (the signed_params struct).

• In TLS 1.3, the client uses the server’s public key to verify the CertificateVerify signature over the transcript. If client authentication is used, the same applies in reverse for the client’s CertificateVerify. Any failure (bad signature or mismatched key) causes the handshake to abort.

• Certificate chain validation: The client also performs standard X.509 path validation on the certificate chain. It checks that each certificate is signed by the next one up, and ultimately by a trusted root (trust anchor). RFC 5246 notes that the server should send the leaf first, with each chain certificate certifying the previous one.

• The client is expected to already have the trusted root CA in its store (the root is usually omitted from the chain since it is independently known). As RFC 5246 states, “the self-signed [root] certificate…MAY be omitted from the chain, under the assumption that the remote end must already possess it”.

• The client also checks each cert’s validity period, revocation status (if any), and that the key-usage extensions allow signing (e.g. digitalSignature bit is set for an ECDSA or RSA cert used for signing).

• Server identity (name) check: Crucially, the client must verify that the server’s certificate is actually for the intended host. Following RFC 6125, the client compares the requested server name (e.g. DNS hostname or IP) to the certificate’s subjectAltName entries. If a DNS-name altName is present it must match the host. Otherwise (no suitable altName) the client falls back to the subject’s Common Name (though CN is deprecated). For example, RFC 6125 says:

  “If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the Common Name field in the Subject…MUST be used.”
  If no match is found, the client aborts. This prevents Man-in-the-Middle attacks by ensuring the certificate presented is actually issued to the server’s hostname.

• Finished message (key binding): After verifying signatures and certificates, both sides exchange Finished messages (MACs) that cover the entire handshake. This step provides final integrity and binds the negotiated keys to the verified identities. RFC 8446 emphasizes that the Finished message “provides key confirmation, binds the endpoint’s identity to the exchanged keys”. In practice, once both Finished messages verify, the handshake is complete and the TLS channel is secure.

In sum, TLS signature verification is a two-phase process: first the cryptographic checks (verify the signature on the handshake data using the public key, then verify that the certificate chain is valid), and second the identity checks (confirm that the leaf certificate matches the server name as expected). Only if all checks pass does the client conclude that it is talking to the genuine server and proceed to send application data.