Showing 6 summaries per page
uulong9507/10/2026
Qingming-STARK-G64: a Goldilocks STARK backend on AMD ROCm/HIP
This article is about a tool that lets an AMD graphics card quickly create a special “math receipt” (a STARK proof) showing that a big computation was done correctly. The tool outputs a proof file that anyone can check with a separate verifier program. The author demonstrates it works at multiple sizes, including around a million steps very quickly, suggesting real apps could start attaching these proofs to their results.
Key takeaways
- Introduces and releases `qingming-stark-g64`, a Goldilocks/G64 STARK backend implemented for AMD GPUs using ROCm/HIP, available as an open repository.
- Provides a clear, modular pipeline boundary: CLI prover → `.qsp` proof file → standalone verifier, enabling independent verification and proof portability.
- End-to-end correctness is demonstrated across multiple benchmark scales (SCALE20 through SCALE27), with both prover and standalone verifier passing at every scale.
- Practical “application point” performance is shown at SCALE24 (~1,048,576 trace rows / 2^24 rows): ~337 ms proving time with a ~192 MiB retained Merkle tree, verified successfully—suggesting sub-second, million-row proving on consumer AMD GPUs.
- Upper-end benchmark at SCALE27 (~8,388,608 trace rows / 2^27 rows): ~2.05 s proving time with a ~1.5 GiB retained Merkle tree, indicating the approach scales to larger proofs while motivating a shift from plain computation to proof-carrying computation (output → output + proof) for real-world applications.
nuconstruct7/8/2026
Builders' Defection and Incentive Compatibility
Ethereum blocks are often built by a “builder” who gets to see everyone’s secret trading plans (bids + transaction bundles) before deciding what goes in the next block. Even if the builder runs an auction and promises to include the winning bundle, it can secretly copy the best bundle for itself and keep the profit. The paper asks: can we rely on the builder’s reputation (fear of losing future business) to stop this? The answer is usually no, because copying is hard to detect and the one-time profit can be big. So the fix should be technical: design the system so the builder can’t reuse what it sees (using TEEs or cryptography), instead of hoping it behaves.
Key takeaways
- PBS creates an imperfect-commitment problem: builders observe all bids and full payloads, and nothing cryptographically forces them to honor the auction outcome rather than replicate/profit from bundles.
- In a repeated-game model, honesty is incentive-compatible only if the one-shot defection gain (Δ) is smaller than the expected discounted loss from being caught: Δ ≤ p * (δ/(1−δ)) * π_h; low detection probability p or low patience δ makes defection rational.
- Empirically (libmev panel, Sep 2024–Aug 2025), replication-style defection is likely hard to detect on-chain, implying low p (plausibly 0.01–0.1), under which incentive compatibility fails for every major non-TEE builder unless the builder is extremely forward-looking.
- The potential economic scale is large: the paper estimates roughly $26M/year of counterfactual defection surplus available to non-TEE builders in the panel, and ~$49M total exposure when including BuilderNet’s TEE-neutralized share.
- Therefore commitment must be restored architecturally, not reputationally: prevent builders from learning usable bid/payload details (e.g., TEEs like BuilderNet, commitment-based settlement designs, or cryptographic approaches such as threshold-encrypted mempools / commit-reveal / ZK), while noting ePBS (EIP-7732) and FOCIL (EIP-7805) don’t address this replication/confidentiality channel.
WGlynn7/6/2026
Augmented Mechanism Design: One Operator, Every Substrate
Sometimes a system (like a market rule, a blockchain consensus rule, or an AI assistant) is mostly good, but clever people find loopholes because the real world is messier than the math. Instead of throwing the system away or adding a powerful human “admin” to police it, this article argues you should keep the core system and wrap it with extra hard rules that block the loopholes automatically. These protective add-ons come in a few common types: (1) change the structure so the bad trick is impossible, (2) make the trick not worth doing, (3) use time delays so speed tricks don’t work, and (4) add checkable proofs so claims can be verified. The key claim is that this same “add protections without replacing the core” pattern works across markets, blockchain consensus, and AI systems.
Key takeaways
- Core thesis: mechanisms usually fail not because their fundamental math is wrong, but because adversaries exploit gaps between the formal mechanism and its social/strategic context; Augmented Mechanism Design (AMD) addresses this by adding bounded, math-enforced invariants rather than replacing the mechanism.
- AMD is described as an operator A applied to a mechanism M with vulnerability V, producing M' = A(M) that preserves M’s core property while shrinking V with bounded added complexity—and explicitly avoids introducing an admin (a new trust/capture surface).
- The augmentation toolkit has four recurring invariant types—structural, economic, temporal, and verification—and real systems typically compose multiple types to “armor” the original mechanism.
- DeFi/market deployments illustrate the pattern concretely: augmented bonding curves (e.g., exit tributes + participation-gated vesting), augmented Harberger taxes (e.g., loyalty multiplier, right of first refusal, superlinear portfolio tax, displacement premium), and commit-reveal batch auctions (uniform clearing price + commit/reveal windows + slashing + deterministic shuffle) to eliminate classes of manipulation like pump-and-dump and MEV-style attacks.
- The article argues substrate-independence via additional deployments: a consensus-layer anti-concentration structural invariant requiring independent minimum support from both capital and contribution dimensions (MIN_DIM_BPS = 5000), and AI “harnesses” that wrap LLMs with deterministic gates, verifiers, and escalation policies—plus the observation that similar scaffolding appears in external systems (e.g., Claude Code), while noting cross-substrate universality is argued from evidence, not yet formally proven.
conalloreilly7/6/2026
Lean Execution: a holistic approach to secure, efficient, adaptive, and resourceful execution throughput to scale the world-computer
Ethereum is like a huge shared computer that everyone uses together. Right now, making it faster is hard because (1) everyone has to re-check (re-run) the same work, and (2) only a small part of the network’s total computing power is actually used to do useful work at once. This article explains how to scale Ethereum by:
- Splitting the system into four parts: agreeing on truth (consensus), doing the computations (execution), holding pending transactions (memory/mempool), and storing data/state (data).
- Using cryptographic “receipts” (SNARK proofs) so lots of computation can be checked quickly without everyone redoing it.
- Letting many computers run different pieces of work in parallel (execution sharding), and then combining the results.
- Improving how transactions get into blocks (a more shared/‘virtual’ mempool) to reduce censorship and MEV.
- Spreading storage across the network (data availability sampling) and using state expiry so storage doesn’t grow forever without payment.
Key takeaways
- A useful scaling lens is four capacities—consensus, execution, memory (transaction inclusion/sequencing), and data (availability/state storage)—and the main long-term bottleneck is usually capacity-utilization (how much of the network’s total resources are actually used in parallel), not just faster single-thread execution.
- SNARK-based validity proofs “decouple” execution from verification: validators can verify correctness in (roughly) constant time instead of re-executing blocks, enabling higher throughput without raising validator hardware requirements and improving decentralization.
- Attester–proposer separation (and related designs like ePBS) becomes more powerful once execution is SNARK-proven: low-resource nodes can focus on consensus security while higher-resource proposers/builders provide throughput, reducing economies-of-scale pressures on validators.
- Scaling shouldn’t rely solely on heterogeneous, socially-coordinated L2 operators: rollups inherit L1 verification security but often centralize sequencing and execution; the paper argues the endgame trends toward native/based rollups and ultimately L1 execution sharding to re-homogenize throughput.
- A proposed endgame is adaptive, real-time execution sharding coordinated by a ‘virtual mempool’ plus recursive SNARK ‘execution trees’: transactions are partitioned by state access, executed in parallel by committees, and recursively aggregated into a single consensus root—optimizing best/mid-case parallelism while degrading safely toward today’s monolithic behavior in worst cases.
uulong9507/6/2026
Qingming-g64-ntt-cuda: RTX4090-24G results for native Goldilocks/G64 STARK-LDE NTT
This work is about making a very big, very fast “number shuffler” (an NTT, like an FFT but for modular arithmetic) run on an NVIDIA RTX 4090 GPU. This shuffler is a key step in STARK proofs when you “stretch” data to a bigger size (LDE, low-degree extension). The author shares a CUDA implementation, gives two ways to feed data in and read it out (a fast GPU-friendly one and a standard easy-to-use one), and publishes benchmark + correctness tests so others can reproduce the results.
Key takeaways
- Released a reproducible CUDA benchmark/report for native Goldilocks/G64 NTT used in STARK-style LDE (modulus 2^64 - 2^32 + 1, generator 7, LDE factor 8), as a CUDA follow-up to prior AMD HIP/ROCm work.
- Two validated interfaces are provided on RTX4090-24G: (1) qingming_fast (device-native tiled input, mapped output) and (2) qingming_standard (natural-order input, standard materialized output).
- Correctness was independently validated via fresh clone + rebuild on RTX4090-24G; checks passed (self_test, gpu_cpu_check, radix512_check) and both interfaces passed for domain_logn 20 through 30.
- Performance at the common STARK LDE-8 point (logical_logn=24 → domain_logn=27) is: qingming_fast median 9.1535 ms (703.82 GB/s) vs qingming_standard median 38.1430 ms (~168.90 GB/s), showing a large speed/throughput advantage for the fast GPU-native interface.
- Supported-size boundary on RTX4090-24G is domain_logn 20..30 validated; domain_logn=31 is “capacity gated” (cannot run due to resource limits), and domain_logn >= 32 is currently unsupported.
vbuterin7/6/2026
The Extremely Lean Chain
Ethereum needs to keep track of lots of information about each validator (the computers that help secure the network). That tracking is expensive and makes it hard to have millions of validators. This article suggests a different approach: keep almost nothing about validators on the chain, and instead make each validator periodically prove (with cryptographic “receipts” called STARK proofs) that they behaved correctly and what their updated balance should be. Later, it extends the idea to privacy: validators can use a fresh identity (new key) each day, while still proving they’re the same staker underneath—so outsiders can’t easily track them over time.
Key takeaways
- Per-validator consensus state can be reduced dramatically (from many fields like pubkey, withdrawal credentials, epochs, balances, slashing flags) down to essentially just an effective balance (1 byte) plus a deposit-tree pubkey index (5 bytes) in the non-privacy version.
- STARK-based verification is used not only to aggregate attestations/signatures but also to remove the need for the chain to store validator pubkeys and withdrawal credentials: the validator supplies the pubkey + Merkle proof from the deposit tree inside the signature/proof.
- Reward/penalty accounting is moved off the real-time state transition: each validator submits a periodic (eg daily) STARK proving their participation over the period and computing their updated balance; if they’re late, they just can’t attest until they submit—no immediate slashing for lateness.
- To scale to very large validator sets, onchain verification must also aggregate these periodic balance-update STARKs (since at 1M validators, naive submission would imply >100 proofs per slot).
- A privacy-focused Phase 2 redesign makes validator identities re-anonymize daily: validators register a fresh pubkey each day and use ZK-STARKs to prove continuity (and slashing status) across days, enabling strong anonymity and providing SSLE-like properties (single secret leader election) with minimal extra machinery.