Showing 6 summaries per page
DamonZwicker5/10/2026
Toward a Portable Verification Boundary for Ethereum
Ethereum is getting good at (1) proving a computer program ran correctly (like showing your math work) and (2) making sure the needed data is available to fetch later (like keeping the textbook on the shelf). But there’s still a problem: to verify many things today, you often have to trust special tools or the specific system that produced the result. This article proposes a simple way to make verification “portable”: take the exact bytes of something (a document/log/trace), hash it into a short fingerprint, and publish that fingerprint on a public ledger. Later, anyone can hash the bytes they were given and check that it matches what was recorded. If even one byte changes, the check fails.
Key takeaways
- Despite advances in correctness (ZK proofs) and data availability (DAS/blobs), real-world verification often remains system-dependent (e.g., tied to specific execution environments, rollup provers, indexers/APIs, or app-specific semantics).
- The core requirement is shifting from “was this computed correctly?” to “can any third party independently verify what actually existed later, without trusting the originating system?”—especially as AI generates high-stakes artifacts (legal/financial/audit/execution traces).
- A minimal portable verification model can be built from hashing an observation (byte sequence) and committing that digest to a public ledger; verification is just re-hashing the candidate bytes and checking ledger inclusion.
- The proposed Observation Commitment Protocol (OCP) intentionally defines only the system-independent verification boundary and its portable artifact (digest + transaction reference), while leaving storage, identity/authorship, canonical encoding, execution semantics, and data availability out of scope.
- The framing suggests Ethereum may need a third primitive beyond correctness and availability: a standardized verification boundary that reduces reliance on indexers and bespoke verification logic, and composes cleanly with rollups, ZK systems, and DA layers.
rafajaw5/10/2026
BondRoute: Pricing Abandonment in Commit-Reveal Protocols
Commit-reveal is like putting your move in a sealed envelope so nobody can copy you. But in many systems, you can still choose to open the envelope only if it helps you, and throw it away if it doesn’t. That’s like getting a free “try it later” coupon. BondRoute says: if you want the ability to decide later (and maybe cancel), you should put down a refundable deposit (a bond). If you don’t follow through, you lose the deposit. The app sets how big the deposit should be based on how risky or valuable that ‘decide later’ power is.
Key takeaways
- Commit-reveal provides secrecy (prevents simple mempool copying), but it often fails to create true economic commitment because users can abandon without penalty.
- Cheap pre-commitment enables “multi-branch” abuse: an attacker can commit to many possible actions/bids, observe outcomes, and reveal/executed only the profitable branch—turning the system into underpriced optionality.
- This issue is broader than MEV: it applies to blind auctions, ENS-style registrations, mints, solver/settlement systems, and any protocol pattern that effectively says “commit now, decide later.”
- BondRoute introduces an execution-bond primitive that explicitly prices abandonment/optionality by requiring stake + timing constraints (min stake, min delay, max execution window, valid timestamps, funding requirements) before executing via a protected route.
- Bond sizing must be application-layer because only the application can correctly price the optionality for a specific call (e.g., % of bid in auctions, premium/desirability/window for registrations, trade size/slippage/MEV exposure for swaps), avoiding reliance on weak deterrents like gas, UX friction, or “nobody will spam.”
juandtt, Juan Diez Garcia5/10/2026
3rd gen, Ethereum-based blockchain tech concept (aka "Turing Test Blockchain" concept)
The author proposes an idea for a “third-generation” blockchain built on Ethereum ideas, designed for a world where AI is everywhere. The prototype has three parts: (1) a new kind of validator signup contract that splits validator responsibilities into two roles (one providing liquidity/stake and one providing infrastructure/execution), (2) a simple contract that stores standardized IDs that point to real-world assets, and (3) a very small AI model that looks at network delay/latency data to understand the network’s shape and performance. The goal is to explore how AI can improve blockchain infrastructure and how validator networks might be organized differently.
Key takeaways
- The work positions Ethereum as “2nd generation” and proposes a “3rd generation” concept optimized for an AI era, treating AI as an opportunity across infrastructure, applications, and economics.
- The proof-of-concept centers on a modified deposit contract (ttbv0) that introduces a two-tier validator topology: a liquidity/stake provider paired with an infrastructure/execution provider, resembling a master–slave-inspired structure and a hybrid PoW/PoS frontier concept.
- A separate storage contract (SpearStoragev0) is proposed to hold standardized identifiers (e.g., RFC / IEC / ISO-style IDs) that reference real-world assets, aiming for more structured on-chain asset linkage.
- An ultra-lightweight, unsupervised AI module (decntv0) analyzes validator/network topology using network-latency traces; initial tests were run using Ethereum mainnet data, emphasizing latency as an important signal.
- The implementation is early but running, built from standard Ethereum codebases; the author anticipates further integration work, likely including off-chain mechanisms, and notes current IP/copyright constraints (code kept private for now).
juandtt, Juan Diez Garcia5/10/2026
Trade/commerce app
The author wants to build an online marketplace on Ethereum. First, people need a standard way to name companies and products so everyone talks about the same things. Then the app needs a way for buyers and sellers to find and match each other’s orders. After a match, it needs a safe way to finish the deal (settlement) using smart contracts. Some parts might be easier to do off the blockchain, and the author is asking if similar projects already exist and what common mistakes to avoid.
Key takeaways
- The proposed Ethereum-based commerce system is centered on two main phases: order discovery/matching and trade settlement.
- Standardized identifiers (e.g., company IDs, product/item codes) are considered a key prerequisite for reliable on-chain trading.
- The current prototype approach uses basic data structures (structs), on-chain transactions containing order data, and smart contracts to handle settlement.
- The author anticipates a hybrid architecture: some coordination and potentially the matching engine may need to run off-chain for feasibility and usability.
- The post is primarily a request for prior art and practical guidance—seeking similar existing applications, lessons learned, pitfalls to avoid, and desirable features.
miha-stopar4/30/2026
GPU-Accelerated WHIR Proving on Apple Silicon: Benchmarks and Lessons from Client-Side Metal Compute
Imagine you want to prove something is true (like “I’m allowed to do this transaction”) without showing your secret data. That proof takes a lot of math, so doing it on your own phone/laptop can feel slow. This article shows how to move the heaviest parts of that proof-making work onto the Apple GPU using Metal (Apple’s GPU programming tool). Because Apple chips let the CPU and GPU share the same memory, the program can pass big data around without the slow ‘copy it to the graphics card’ step you’d have on many PCs. The work focuses on speeding up three big jobs: (1) a fast polynomial transform (NTT), (2) building a hash tree (Merkle tree) using Poseidon2 hashes, and (3) proof-of-work “grinding” to find a nonce. The main trick is to fuse several GPU steps into one tightly packed GPU job so the CPU and GPU don’t keep waiting on each other.
Key takeaways
- End-to-end WHIR proving is meaningfully faster on Apple GPUs: up to ~2.03x on M1, up to ~2.58x on a supplementary M3 run (with one outlier cell at 4.07x noted as needing re-check), and ~1.4–2.3x on sampled iPhone (A19) benchmarks.
- The biggest performance win comes from pipeline fusion: combining NTT, bit-reversal, Poseidon2 leaf hashing + Merkle compression, and (optionally) PoW grinding into a single Metal command buffer reduces CPU↔GPU synchronization and avoids costly round-trips.
- Apple unified memory removes PCIe transfer overhead, but buffer choice still matters: shared (CPU+GPU) buffers can slow GPU compute due to cache-coherence costs; the fastest approach is hybrid—shared for I/O, GPU-private buffers for heavy intermediate computation.
- Poseidon2 Merkle hashing dominates runtime (~58% of GPU time in a representative profile) and appears compute-bound with high ALU utilization, suggesting further gains are likely limited without changing the protocol structure (e.g., higher-arity Merkle trees).
- GPU speedups are strongest for large polynomials (≥2^20 coefficients) and for parameter regimes where NTT+Merkle work dominates (low fold, higher rate); remaining bottlenecks include CPU sumcheck (~15%) and variability from PoW grinding and device thermal throttling.
Mahdi1714/29/2026
Upgrade any Ethereum wallet to post-quantum security in one transaction using ZK proofs with a hidden public key
Today, if an Ethereum “normal” wallet (EOA) ever sends a transaction, its public key can be learned from the blockchain. A future powerful quantum computer could use that public key to figure out the private key and steal funds. This article proposes a way to “upgrade” the same wallet address without moving assets: you do one special transaction to install a smart-wallet gate, and after that, every spend must include a zero-knowledge proof that you know a valid ECDSA signature made by a secret (hidden) key—without ever revealing that key on-chain or in the mempool. So attackers (even quantum ones) don’t get the public key they need to attack, but the wallet can still use existing ECDSA-capable hardware (HSMs/MPC) behind the scenes.
Key takeaways
- Single-transaction retrofit with no address change: using EIP-7702 delegation, an existing EOA can delegate execution to a GatedWallet contract so the account becomes post-quantum-hardened without migrating assets or changing consensus.
- Core idea is “hidden public key + ZK proof”: the contract stores only a hash commitment to a new public key (pkHash), and each transaction provides a ZK proof that an ECDSA signature exists under that committed key and is bound to the specific action (userOpHash/chainid/nonce).
- Closes the mempool exposure window of prior ‘ephemeral key rotation’ approaches: no public key for the new signing key ever appears in the mempool or on-chain, removing the window where a cryptographically relevant quantum computer could extract the private key via Shor’s algorithm.
- Practical path for institutions: it does not require post-quantum signature support in HSMs or MPC stacks; those can keep doing ECDSA internally while wallet software adds the ZK layer—positioned as the fastest deployable route to quantum safety for production systems.
- Performance and roadmap: current Longfellow/Ligero-based implementation reports ~87 ms proving, ~65 ms verification, 226 KB proofs, and ~3M gas on-chain; a “designated-prover” optimization could reduce proofs to ~50–80 KB and gas to ~800k, with open work items including Keccak-in-circuit, WHIR backend benchmarking, and proof aggregation.