Adversarial procurement in blockchains
Abstract: An emerging blockchain protocol design pattern leverages the asymmetry between the computational effort in performing versus verifying tasks. For example, cryptographic validity proofs (e.g., SNARKS) require the prover to expend significant effort demonstrating the correctness of their claim, while the verifiers benefit from extremely easy validation. The operationalization of this paradigm requires efficiently soliciting the performance of expensive tasks in pseudonymous, adversarial environments. We formalize this as a mechanism design question. The protocol balances the economic cost of a liveness fault, where the work is not completed, with the payments required to incentivize specific behavior from candidate suppliers. We show that the loss of the optimal protocol scales logarithmically in the cost of a liveness fault, scaled up by the adversarial fraction of the network. Further, we find that the optimal equilibria have an intuitive structure, allowing us to provide concrete advice to practitioners. Specifically, in many regimes, the optimum designates a single, random node as the primary worker and a committee as a fallback, which is reminiscent of leader-based consensus mechanisms. We also characterize the asymptotic regimes where having negative payments (i.e., slashing in blockchain parlance) is especially helpful.
Paper Prompts
Sign up for free to create and run prompts on this paper using GPT-5.
Top Community Prompts
Explain it Like I'm 14
What this paper is about (big picture)
Imagine a group project where checking the final answer is easy, but doing the work is hard. You need at least one teammate to do the hard part each time. If nobody does it, the whole project gets a big penalty. Paying everyone to do it is safe but very expensive. Paying just one person is cheap but risky if that person disappears.
This paper studies how a blockchain (like Ethereum) can reliably get at least one “prover” to do a hard job—creating a mathematical proof that a block is correct—while keeping costs low, even if some people in the network are lazy or trying to sabotage things. The authors design and analyze simple rules for who should work and how they should be paid so the system almost never gets stuck.
What questions the paper asks
- How can we pick and pay people to do a hard task so that:
- at least one person does it most of the time (so the chain doesn’t halt),
- we don’t waste money paying too many people, and
- even if some people act maliciously, the system still runs well?
- What simple “who works and who gets paid” plan gives the best balance between reliability and cost?
- How much worse can things get if an attacker controls some fraction of the network?
- When does asking people to put down a deposit that can be taken away (called “slashing”) help a lot?
How they studied it (in plain terms)
Think of each block as a round in that group project:
- The network needs one valid proof per round.
- Verifying a proof is easy for everyone; making a proof is hard and costs “1 unit.”
- If no proof appears, the system pays a big penalty, called (think: ≫ 1).
- There are potential provers; at least of them are honest. Up to might be controlled by an attacker.
The “mechanism” (the rulebook) has two parts:
- Who is asked to do the work (and with what probability they should try).
- How much each person gets paid depending on who actually delivers.
The authors:
- Model how honest provers will behave if they’re trying to maximize their payoff.
- Imagine a worst-case attacker who chooses up to people to misbehave in the most damaging way.
- Measure the “cost” as total payments plus the big penalty if no proof shows up.
- Propose simple, practical rules and then use math to prove how good (or bad) those rules are, even in the worst case.
Two intuitive rule families they analyze:
- Symmetric “lottery” style: ask a group to each try with the same probability and give a prize to those who deliver.
- Designated leader with backups: pick one “leader” who definitely tries, and also pick a small “committee” of backups who each try with some probability, just in case.
They also use a lower-bound math tool (think of it like a “best-possible score you can hope for”) to show how close their rules are to the absolute best you could ever do.
What they found (main results)
- A simple plan works extremely well: pick one random leader to definitely do the proof, plus a small backup committee where each member tries with some probability. Pay a fixed amount if at least one proof arrives. This looks a lot like leader-based systems many blockchains already use.
- This “designated leader + backups” plan is either:
- exactly optimal in many realistic situations, or
- at most “one extra proof’s cost” worse than the absolute best possible plan. In other words, it’s near-perfect.
- How the worst-case cost grows:
- The worst-case total cost grows slowly with the penalty —specifically like a logarithm: .
- In simple terms: if is huge, the cost increases, but only slowly (logarithms grow very slowly), and it also gets worse if the attacker controls a bigger share of the network (smaller ).
- Negative payments (slashing) can help a lot:
- If provers must put down a deposit that they lose when they misbehave, the system can be cheaper and more reliable.
- With enough total stake compared to the penalty , costs can become almost constant, even under attack.
- The paper also explores when a symmetric “lottery” style rule can be good, but the leader-with-backups approach tends to be the most practical and robust, especially for today’s blockchain settings.
Why this matters
- For blockchains moving toward zk-proofs (like a zk-EVM), producing the proof is hard but checking it is easy. You want at least one proof per block without overpaying or risking a halt. This paper gives a clear, implementable way to do that.
- The advice is practical:
- Randomly choose one leader per round who must prove.
- Have a small backup committee who might also try, with some probability.
- Pay a fixed amount if at least one proof arrives.
- Use staking/slashing to improve reliability and reduce costs.
- This idea is useful beyond blockchain proofs. Any system where:
- doing the task is hard,
- checking is easy, and
- you can have many potential workers you don’t fully trust,
- can use a similar leader-plus-backups approach. Examples include outsourcing heavy computations that can be verified (like certain AI inference tasks with trusted hardware or cryptographic proofs).
Bottom line
The paper shows how to reliably get exactly one expensive job done each round, even among untrusted participants, without blowing the budget. The winning recipe is surprisingly simple: appoint a leader, have a few backups, pay a fixed reward if someone delivers, and consider slashing to keep everyone honest. It’s robust, cost-effective, and fits how modern blockchains are evolving.
Knowledge Gaps
Knowledge gaps, limitations, and open questions
Below is a concise list of concrete gaps and unresolved questions that future work could address:
- Robustness to Sybil identities
- The model assumes a fixed set of pseudonymous provers and at least honest provers; mechanisms are not analyzed under identity inflation where the adversary can create new IDs cheaply. How to design near-optimal procurement that is Sybil-proof (e.g., via endogenous identity costs, deposits, or admission rules) remains open.
- Unknown or misestimated honesty levels
- Protocols are tuned as functions of and , which are taken as known. How to choose (and payments) when is uncertain, time-varying, or adversarially misreported (robust/agnostic mechanisms with performance guarantees under ambiguity) is not addressed.
- Heterogeneous and private prover costs
- All provers are assumed to have identical, known unit proving cost. Extending the mechanism and analysis to heterogeneous, potentially private costs and capacities (including DSIC or Sybil-proof procurement with private types) is not explored.
- Capacity constraints and task concurrency
- Provers are implicitly unconstrained and face a single task. Realistic settings feature limited capacity, queueing, and concurrent tasks. How to set payments and assignment probabilities under capacity and latency constraints is left open.
- Dynamic and repeated-interaction settings
- The analysis is single-shot with a one-off attack. Designing mechanisms for repeated rounds with learning, reputation, adaptive attackers, and cross-round coupling (e.g., budget-smoothed payments, rotating committees) is not treated.
- Time and latency modeling
- There is no model of proof deadlines, variable proving times, or timing races (e.g., staggered backups, timeouts, early-delivery bonuses). How to incorporate and optimize over temporal structure is not analyzed.
- Network-layer adversaries and censorship
- The model treats delivery as a binary choice by provers and ignores adversarial network conditions (DoS, censorship by proposers/relays, propagation delays). Mechanism robustness and payment conditioning under network faults remain unexplored.
- Task verification and payout implementation details
- Payments are conditioned on the vector of deliveries, but the paper does not specify how to ensure only valid, non-duplicative proofs are paid, or how to prevent proof relaying/free-riding. Designing on-chain verifiable payout rules that prevent gaming is an open implementation gap.
- Leader/committee selection security
- The designated mechanism presumes secure, unbiased, and corruption-resistant selection of the leader and backups. How to instantiate leader election (e.g., VRF, commit-reveal) so attackers cannot preemptively corrupt leaders remains unspecified.
- Adversary adaptivity and information timing
- The adversary observes but not honest private coins. Practical systems may leak timing and partial information. Mechanism performance under more adaptive or partially informed adversaries is not analyzed.
- Sensitivity to the liveness penalty parameter
- is treated as exogenous and constant. In reality, the cost of a liveness fault is stochastic and time-varying (e.g., market volatility). Designing mechanisms robust to stochastic or adversarially time-varying (or learning ) is open.
- Full characterization of optimal mechanisms outside implementable regimes
- The paper notes regimes where the lower-bound minimizer is symmetric but not implementable against the full adversary and leaves full characterization of the optimal mechanism in these regimes as an open problem (beyond the additive-1 approximation).
- Exact transition boundaries between designated and symmetric optima
- While the paper provides structural insights and numerical evidence, closed-form or tight analytical characterizations of the parameter regions where designated vs symmetric mechanisms are optimal/implementable are not fully derived.
- Correlated strategies and public randomness
- The analysis assumes independent mixed strategies. The benefits or risks of correlated strategies or common randomness (e.g., correlation devices) are not investigated.
- Negative payments (staking/slashing): practical frictions
- The extension with negative payments assumes deposits but does not model capital costs, risk aversion, default risk, or enforcement frictions. Determining optimal stake size and economics under realistic frictions is left open.
- Budget, revenue, and funding constraints
- The objective minimizes expected cost without considering budget constraints, funding sources, or interactions with protocol revenue (e.g., MEV rebate flows). Mechanism design with budget balance or revenue-coupled objectives is not addressed.
- Interactions with PBS and proposer behavior
- The analysis abstracts from proposer incentives and relay behavior (e.g., withholding proofs to reshuffle MEV). Joint mechanism design for builders/proposers/provers, including cross-market strategic effects, is not explored.
- Data availability coupling and multi-layer dependencies
- Proof success can depend on data availability and other layers. The interaction of procurement with DA sampling, blob timing, and cross-layer failure modes is not modeled.
- Empirical validation and calibration
- Recommendations rely on qualitative assumptions (e.g., “C is large,” proving costs small, stake magnitude) without empirical calibration or stress tests. Building datasets to estimate , , proving costs, and validating the mechanisms in simulations or testnets remains future work.
- Generalization beyond binary outcomes
- Outcomes are binary (proof delivered or not). Tasks with partial progress, quality levels, or multiple alternative proofs (e.g., different circuits) are not modeled. Mechanisms that price quality/time trade-offs are not considered.
- Multi-task markets and brokered matching
- The paper focuses on single-task procurement. How to orchestrate many tasks, match heterogeneous jobs to provers, and compose per-task mechanisms into market-level protocols is not addressed.
- Inter-prover collusion beyond adversarial set
- While the adversary fully coordinates corrupted provers, the possibility of coalition formation among nominally honest provers (e.g., to share payments or manipulate delivery probabilities) is not analyzed.
- Privacy and information leakage
- The mechanisms assume no private information and no strategic signaling. In practice, private costs/capacities and information leakage can affect equilibrium. Designing IC mechanisms with privacy-preserving verification is open.
- Robustness to misreporting of deliveries or replay attacks
- The model assumes truthful observability of whether a prover delivered. Securing attestations and preventing replay/duplicate claims in payment rules is left to future implementation work.
Practical Applications
Overview
This paper studies how to reliably procure expensive but verifiable work (e.g., zk-SNARK proofs, TEE attestations) from pseudonymous actors in adversarial environments. It introduces and analyzes a simple, leader-based procurement mechanism (“designated mechanism”) that minimizes worst‑case total cost (payments plus liveness failure penalty) when up to a fraction of the network can behave adversarially. Key findings that drive applications:
- A near-optimal procurement workflow: designate a single “leader” to deliver, plus a backup committee that each attempts delivery with a set probability. Pay a fixed amount if any valid output is delivered.
- Provable performance: this designated scheme is optimal in many regimes and always within the cost of one extra task of the best possible mechanism.
- Economic scaling law: worst‑case loss scales as O((n/h) * log C), where n is total suppliers, h is honest suppliers, and C is the penalty for a liveness fault relative to a single task’s cost.
- Negative payments (slashing) meaningfully improve guarantees when collateral (stake) is available.
Below are practical use cases and workflows that follow directly from these findings.
Immediate Applications
These applications can be deployed with current infrastructure and commonly used tooling.
- Ethereum rollups and zk prover markets (sector: software/blockchain)
- Use case: Robust procurement of batch proofs for zk-rollups and zkEVM blocks.
- Workflow/product:
- Implement a “Designated + Backup” procurement module in rollup sequencers or proving marketplaces:
- Randomly select one designated prover (leader) to deliver with probability 1.
- Sample a committee of k backups; each attempts with probability s.
- Commit to a fixed payout P ≈ 1 + k·s (in units of a single proof’s cost), paid if any proof is received, independent of the number of submissions.
- If staking is available, add deposits and slashing to reduce P and improve robustness.
- Integrate with existing relays/brokers (e.g., MEV-Boost-like relays, BuilderNet, or marketplace APIs) and contracts that enforce the payout rule.
- Assumptions/dependencies:
- Known or bounded C (economic cost of a liveness fault) and a lower bound on h/n (honest fraction).
- On-chain or off-chain verifiable randomness for leader/committee selection; reliable attestation of delivery timeouts.
- Proof verification is negligible vs. proving cost (true for SNARKs).
- Basic Sybil resistance (e.g., registration fee, whitelisting, or stake).
- Prover marketplaces and ZK coprocessors (Succinct, Axiom, Brevis, RISC Zero, Ritual, EigenCloud) (sector: software/marketplaces)
- Use case: Replace overprovisioned “pay-all” or pure lotteries with near-optimal leader+committee procurement to cut spend and maintain liveness guarantees.
- Workflow/product:
- Broker layer computes k and s and posts a fixed bounty P with designated leader identity and backup committee list.
- Marketplace smart contracts codify “pay-if-any-deliver” and optional deposit/slashing rules.
- Assumptions/dependencies:
- Homogeneous (or normalized) task costs or price discovery mechanisms that convert heterogeneity to a common unit per job.
- Oracle and data services (sector: finance/software)
- Use case: Liveness-robust procurement of zk proofs for oracle data transformations (e.g., TWAP, settlement proofs) or DA commitments.
- Workflow/product:
- “Oracle Proving Pool” that assigns a leader and backups for each data epoch, with fixed payout on successful proofs.
- Assumptions/dependencies:
- Tight SLAs and deterministic verifiability of outputs.
- Cross-chain bridges and light clients (sector: software/finance)
- Use case: Procuring succinct proofs (or signatures/attestations) with high liveness guarantees for bridge finality.
- Workflow/product:
- Bridge contracts implement leader+committee proofs for periodic state commitments; require stake for key signers/provers.
- Assumptions/dependencies:
- On-chain verification of succinct proofs or trusted attestations.
- Verifiable AI inference via TEEs (sector: AI/software)
- Use case: Procuring TEE-attested inference outputs with high availability.
- Workflow/product:
- A broker assigns one primary TEE provider and a probabilistic backup committee; pays a fixed amount on verified attestation.
- Assumptions/dependencies:
- Commodity TEE attestation verification available; clear SLA and attestation formats.
- Validator and client software modules (sector: software)
- Use case: Integrate procurement logic directly into validator/rollup client stacks to minimize outages during demand spikes.
- Workflow/product:
- A “Prover Procurement Module” that:
- Estimates C (per-slot/epoch liveness cost) and h/n.
- Sets k and s and P using a rule-of-thumb (see below).
- Exposes metrics and alerts for failure probabilities.
- Assumptions/dependencies:
- Access to randomness beacons and payment rails; observability to recalibrate parameters.
- Parameterization cookbook (sector: software/DevOps)
- Use case: Practical tuning to achieve low failure probability without overpaying.
- Workflow/product:
- Rule-of-thumb based on the paper’s asymptotics:
- Target failure probability ≈ 1/C.
- Expected honest backup effort ≈ (n/h)·ln C.
- Choose integers k and s such that k·s ≈ (n/h)·ln C (e.g., pick k then set s ≈ [(n/h)·ln C]/k).
- Set fixed payout P ≈ 1 + k·s (in “one-proof” cost units); lower P further if staking/slashing is used.
- Assumptions/dependencies:
- Reasonable estimates of C and h/n; monitoring to adjust over time.
- Exchanges and DeFi protocols (sector: finance)
- Use case: Obtain proof-backed risk calculations, audits, or settlement attestations with strong liveness guarantees during volatility.
- Workflow/product:
- Internal procurement service using leader+committee for time-critical computations (e.g., proof of reserves transforms) with fixed bounties.
- Assumptions/dependencies:
- Internal compliance with stake or vendor bonding for negative payments.
- Standard operating procedures (sector: software governance)
- Use case: Governance policies for economic security budgets (C), how to compute it, and how to disclose procurement parameters.
- Workflow/product:
- Policy documents and on-chain configs that specify C estimation (e.g., lost fees, MEV leakage), committee size, payout, and whether stake is required.
- Assumptions/dependencies:
- Access to historical economics and risk modeling; community sign-off.
- User-facing reliability improvements (sector: daily life via infrastructure)
- Use case: Fewer outages and faster confirmations for wallets and dApps as back-end services adopt robust procurement.
- Workflow/product:
- Wallets surface “prover redundancy” status; dApps integrate fallback proof providers transparently.
- Assumptions/dependencies:
- Under-the-hood adoption by infrastructure providers.
Long-Term Applications
These require additional research, scaling, standardization, or ecosystem changes.
- Ethereum L1 zkEVM endgame integration (sector: software/blockchain)
- Use case: Protocol-level adoption of designated+committee proving (or its variants) for block validity proofs.
- Potential evolution:
- Incorporate leader selection and backup committees into consensus; protocol-native fixed payouts; on-chain parameter governance.
- Dependencies/assumptions:
- Mature real-time proving; social consensus around C and staking economics; protocol changes.
- General-purpose decentralized compute markets (sector: software/AI/robotics)
- Use case: Apply the mechanism to heterogeneous jobs (ML training/inference, simulation, robotics planning) with verifiable outputs.
- Potential products:
- “Adversarial Procurement” broker standard that supports dynamic pricing for different tasks, with per-task k, s, P.
- Dependencies/assumptions:
- Verifiable computation or attestations for diverse workloads; pricing models for heterogeneous costs.
- Negative payments at scale (staking/slashing) (sector: finance/software)
- Use case: Substantially reduce payouts and improve liveness by bonding providers.
- Potential products:
- “Bonded Prover Registries” with dynamic slashing tied to failure to deliver; pooled insurance for rare events.
- Dependencies/assumptions:
- Legal and regulatory clarity on staking/collateral; reliable adjudication of “non-delivery.”
- Sybil-resistant open markets (sector: software/policy)
- Use case: Ensuring the h/n assumptions are meaningful in fully open, pseudonymous settings.
- Potential products:
- Lightweight identity or stake-based gateways; registration costs; reputation overlays that do not replace incentives but reduce identity churn.
- Dependencies/assumptions:
- Community acceptance and privacy-preserving identity mechanisms.
- Adaptive/e-learning mechanisms (sector: academia/software)
- Use case: Extend the mechanism to repeated settings with on-chain learning of h/n and C, and heterogeneity of costs.
- Potential tools:
- Simulation frameworks and dashboards to fit (n/h)·log C scaling to observed failures and payments; online adjustment of k, s, P.
- Dependencies/assumptions:
- Data availability; safeguards against adversarial manipulation of metrics.
- Sector-specific standardization (sector: policy/standards)
- Use case: Standards for “verifiable outsourcing procurement” in finance, healthcare, and public sector IT.
- Potential products:
- RFC/standards that specify payout rules, fallback committees, and staking guidelines for critical digital infrastructure.
- Dependencies/assumptions:
- Regulator buy-in; alignment with data protection and safety standards.
- Quality- and latency-aware extensions (sector: software/AI)
- Use case: Mechanisms that price different proof latencies or quality metrics (e.g., performance/cost in ML inference).
- Potential products:
- Multi-tier payouts (faster delivery earns more) integrated into designated+committee framework; partial credit with slashing for missed SLOs.
- Dependencies/assumptions:
- Reliable timestamping and verifiable performance metrics.
- Composability with other protocol roles (sector: software/blockchain)
- Use case: Joint design with proposer-builder separation and other unbundled roles (e.g., data availability committees).
- Potential products:
- Unified “duty procurement” layer that handles multiple roles with correlated liveness costs and shared staking.
- Dependencies/assumptions:
- Clear isolation of duties and verification pathways; market design to prevent cross-role collusion.
- Public risk disclosures and insurance (sector: finance/policy)
- Use case: External insurance products priced using the O((n/h)·log C) loss model; public dashboards of procurement risk.
- Potential products:
- Underwriting models for liveness risk; parametric covers for outages tied to procurement KPIs.
- Dependencies/assumptions:
- Actuarial data; enforceable definitions of liveness failures.
- Consumer AI and verifiable apps (sector: daily life/AI)
- Use case: Consumer-facing services (e.g., verified AI content, secure personal computations) that depend on robust, verifiable outsourcing.
- Potential products:
- Apps that display provider redundancy and “verifiability status”; pay-per-job with leader+backup procurement under the hood.
- Dependencies/assumptions:
- Mainstream availability of verifiable compute and attestations; UX that conceals complexity.
Notes on Assumptions and Dependencies
- Cost estimates and parameters:
- Need a defensible estimate of C (penalty for liveness failure), including lost fees, MEV leakage, reputation, and downstream impact. The designated mechanism’s expected backup effort should be tuned to roughly (n/h)·ln C.
- Require a conservative lower bound on h/n (fraction of honest providers). If uncertain, use worst-case lower-bound to size committees.
- Incentives and verification:
- Providers are risk-neutral; verification is cheaper than production (true for SNARKs and TEE attestations).
- Payout rule must be credibly committed: fixed payment if any deliver; backups’ payments may be conditioned on the leader not being corrupted (as per the paper’s implementable design).
- Identity and Sybils:
- The analysis is robust to a large adversarial set but does not remove the need for Sybil resistance. Practical deployments should pair the mechanism with stake or registration costs to control n-h.
- Randomness and fairness:
- Unbiased randomness (e.g., RANDAO, drand) for choosing leaders/committees; transparent selection mitigates bribery and collusion.
- Legal and operational:
- For negative payments, ensure enforceable deposits/slashing and clarity on dispute resolution for alleged non-delivery.
- Monitoring and SLA enforcement (timeouts, proof formats) are required to trigger payments/slashing deterministically.
By adopting the designated leader + probabilistic backup committee with fixed payouts—and adding staking when feasible—teams can substantially reduce costs while preserving strong liveness guarantees for verifiable outsourcing today, and build toward standardized, resilient compute markets across sectors.
Glossary
- Additive 1-approximation: An algorithmic or mechanism guarantee that the achieved value is within an additive constant (here, 1 unit of cost) of the optimum. "is an additive $1$-approximation"
- Anonymous mechanism: A mechanism that treats agents identically, without relying on their identities. "we construct an anonymous mechanism"
- Asymptotic cost: The growth rate of a mechanism’s cost as parameters increase, emphasizing scaling behavior rather than exact values. "analyzes the asymptotic cost of the optimal mechanism"
- Byzantine attacker: An adversary that can arbitrarily deviate from prescribed behavior and corrupt agents to maximize harm. "against a Byzantine attacker"
- Designated mechanism: A mechanism that appoints a single leader to act deterministically with others as probabilistic backups. "Our core proposed mechanism is designated: pick a single
leader'' (ordesignate'') from whom to definitely request a proof, and a set of ``backups'' from whom to request a proof with probability " - Designated uniform committee equilibrium: An equilibrium where one agent delivers with probability 1 and a uniform committee mixes with the same probability, with others inactive. "A strategy vector is a designated uniform committee equilibrium"
- False-name proof: A property of mechanisms designed to be robust to participants creating multiple fake identities. "introduced ``false-name proof'' mechanisms"
- Implementable: An equilibrium is realizable by a payment rule that induces the targeted strategies and associated loss. "is implementable"
- Incentive compatible: A mechanism property where following the prescribed strategy maximizes each agent’s expected utility. "This mechanism must be incentive compatible"
- Leader-based consensus mechanisms: Consensus protocols that select a leader to coordinate progress, often for efficiency or liveness. "which is reminiscent of leader-based consensus mechanisms."
- Liveness fault: A failure mode where the system fails to make progress because required work isn’t completed. "the economic cost of a liveness fault, where the work is not completed"
- Lower bound: A provable minimum on the cost or loss any mechanism must incur under given constraints. "We first introduce a lower-bound"
- Lottery payment rule: A payment scheme that awards a fixed prize to one of the deliverers selected at random, incentivizing probabilistic participation. "Lottery payment rule"
- Maximal Extractable Value (MEV): The extra value extractable by controlling transaction ordering, inclusion, and exclusion within a block. "Maximal Extractable Value (MEV)"
- Mechanism design: A field that designs rules and incentives to achieve desired outcomes with strategic agents. "We formalize this as a mechanism design question."
- Mixed-strategy Nash equilibrium: An equilibrium where players randomize over actions so that each is indifferent among its options. "is a mixed-strategy Nash equilibrium"
- One-of-n: A redundancy pattern where any one of n agents delivering suffices for success. "As long as at least one-of- provers is honest"
- Payment rule: The mapping from observed outcomes (e.g., who delivers) to payments given to agents. "The payment rule specifies, for each prover and each vector $#1{d}$, what is the payment $p_i(#1{d})$"
- Price of Malice: A measure of efficiency degradation due to malicious behavior in strategic systems. "coins the term ``Price of Malice''"
- Pre-image search: The computational task of finding an input that hashes to a given output under a hash function. "pre-image search of SHA-256"
- Proposer-Builder Separation (PBS): An architectural pattern where block construction is outsourced to specialized builders while proposers handle consensus. "Proposer-Builder Separation (PBS)"
- Prover: An agent that performs expensive computation to produce a proof of correctness for others to verify cheaply. "There are pseudonymous provers capable of producing the proof"
- Pure-strategy Nash equilibrium: An equilibrium where players choose actions deterministically rather than randomizing. "is a pure-strategy Nash equilibrium"
- Pseudonymous IDs: Identities that are distinct but not linked to real-world identities, allowing addressable yet anonymous participation. "The players have pseudonymous IDs"
- Quasilinear: A utility model where monetary transfers enter linearly, so utility equals value minus cost plus payments. "Provers are risk-neutral and quasilinear"
- Relay: A trusted intermediary that validates and forwards blocks or bids between builders and proposers. "rely on relays as trusted third parties to verify the value (and validity) of that block"
- Remote Procedure Call (RPC) provider: A service exposing blockchain APIs so clients can interact with the network without running full nodes. "RPC (remote-procedure call) providers expose simple blockchain APIs such as eth_sendTransaction."
- Reverse (procurement) auctions: Auctions where a buyer solicits sellers to provide a good or service, typically minimizing cost. "Reverse (or procurement) auctions"
- Slashing: The practice of imposing negative payments by seizing posted collateral when expected behavior is violated. "having negative payments (i.e., slashing in blockchain parlance) is especially helpful."
- SNARKS: Succinct, non-interactive arguments of knowledge—short proofs that can be verified quickly. "cryptographic validity proofs (e.g., SNARKS) require the prover to expend significant effort"
- Soundness (of ZK proofs): The property that invalid statements cannot be proven, preventing dishonest provers from convincing verifiers. "Soundness of ZK proof systems guarantees that a malicious prover cannot trick validators into believing an incorrect endState"
- Staking: Posting collateral that can be forfeited upon misbehavior to align incentives. "each prover stakes a deposit "
- Strategy profile: The vector of strategies (e.g., delivery probabilities) specified for all agents. "The protocol specifies a strategy profile $#1{s}$"
- Symmetric committee equilibrium: An equilibrium where a committee of agents mixes with the same probability, others being inactive. "A strategy vector is a symmetric committee equilibrium"
- Symmetric mechanism: A mechanism that treats all agents identically, often requesting identical actions or probabilities. "a symmetric mechanism requests that each of providers provide a proof with probability "
- Sybil-proof mechanism: A mechanism robust to participants creating multiple fake identities to game outcomes. "the only ``Sybil-proof'' mechanism"
- Trusted Execution Environment (TEE): Hardware-backed secure enclaves that attest computations and protect integrity/confidentiality. "Trusted Execution Environments (TEEs)"
- Tullock contest: A competition where winning probabilities depend on effort, commonly modeling rent-seeking or prize competitions. "in effect running a Tullock contest"
- Trustless verifiability: The ability for validators to check correctness without trusting specific parties. "loses its trustless verifiability"
- Validator: A consensus participant responsible for validating blocks and maintaining protocol rules. "every consensus participant (henceforth, validator)"
- Verifiable outsourcing: Delegating expensive computation to untrusted parties while enabling cheap verification of results. "Verifiable outsourcing to untrusted sources."
- ZK coprocessor: An architecture where off-chain proofs attest to computations for on-chain verification. "coined as a ``ZK coprocessor'' architecture"
- ZK proof: A zero-knowledge proof that certifies correctness without revealing underlying inputs. "a ZK proof (henceforth, ``proof'')"
- Zero-Knowledge EVM (zk-EVM): An EVM variant where execution correctness is proven via zero-knowledge proofs instead of re-execution by validators. "Zero-Knowledge EVM (zk-EVM)"
- Proof-of-Work: A consensus mechanism where miners solve computational puzzles to append blocks. "Proof-of-Work."
Collections
Sign up for free to add this paper to one or more collections.