I had the pleasure of attending a few conferences and side events over August in San Francisco and New York. There was a lot to absorb, and many conversations to have had.

This piece will be a small summary and my main takeaways of the conferences and talks. For a detailed summary, see my next post.

While this might not be the full coverage of the events, if there’s any interest in some of these topics, I would highly recommend taking a look at the YouTube videos of the recordings, or, reading the documentation/papers.

The conferences and talks were organised as part of:

On to my takeaways!

SBC 2025

The science of blockchain conference has a lot of research that displayed advancements in privacy, consensus, zk, and network research. There were some great topics, and great people to meet; a conference I wish to return to.

These are my personal takeaways, so you’ll notice a bit of a bias to the infra/p2p/consensus tracks, but I do recommend checking out the papers to learn more.

Overall, this conference was able to highlight a few things to me, (1) that the network and data availability require significant investment of time to optimise and improve, especially as we push the limits of what data is being send and received, (2) ZK-powered/enabled tech has some brilliant usage, especially with improving infrastructure and better algorithms and support, (3) interoperability between chains is still critical - making sure that people are safely able to exchange is important, and (4) user privacy is something that all blockchains should look into - not only from the UX/UI perspective, but some hooks deep into the consensus and infrastructure.

On to the notes:

Blockchain P2P networks need a lot of careful attention; especially in the eyes of privacy and efficiency.

Measuring and Attacking Ethereum (paper | video) showed the impact of same-service peers.

  • Ethereum’s network has many services piggy-backing on top of it, making it quite noisy.
  • Those like BitTorrent and Bitcoin require a smaller number of hops to connect with someone worthwhile.
  • The nodes that are eternally online make it more difficult to connect, since their peer tables are full

Deanonymizing Validators (paper | video) showed that messaging patterns can sometimes be analysed to pinpoint the location.

  • Attestations happen in subgroups, and nodes are often placed into these subgroups.
  • Occasionally, one will be asked to aggregate for an external subgroup.
  • Validators would propose blocks in different subgroups, so there would be times that the node would send messages for a different subnet.

Address poisoning

  • Attackers are targeting ’test’ transactions (when Alice wishes to send money to Bob, Alice typically first sends a small test transaction to Bob to see that the transaction succeeded correctly).
  • They send transactions with similar addresses of first + last characters matching - the user (Alice) will then use the latest transaction address to send thinking that it’s Bob’s address.
  • Big problem - solved by better UI (warnings for similarity addresses, human readable naming such as ENS in-protocol, etc.), or potentially removing 0-value transactions.

Data Availability Sampling with Efficient Repair (paper | video)

  • DAS requires sampling from random peers (implementations: Celstia, Ethereum);
  • Repairing lost chunks
    • Construct with erasure codes or multiplicity codes.
    • Locally repairable codes use locality, gossip framework for information dispersal.
    • Encode data using local correctable code, repair by querying others.
  • New multivariate polynomial commitment.

Consensus

Accountable liveness ( paper | video )

  • Is a difficult problem, need to find a way that only byzantine nodes get identified and no honest nodes are falsely accused.
  • Especially with message delays, showing that someone failed to vote is harder than the safety proofs for accountability in safety.

Mysticeti: Reaching Latency Limits with Uncertified DAGs ( paper | video )

  • Talk focused on approaches of different message patterns, how messages aren’t equal (propose message vs data message are different).
  • Pipelining has been shown to increase performance, Sui switched to this consensus from Narwhal and Bullshark.

Consensus flavours post-blockchain (video)

  • Blockchain is State Machine Replication (SMR) as a service, bootstrapped from bottom up, and miners are rewarded based on token rules.
  • Developing a model: if we don’t understand, we can’t learn or say if it works.
  • Perils of uncontrolled pooling
    • Economies of scale = pooling of resources (e.g. mining pools, pooled stake)
    • Pooling could lead to single pool takeovers
  • Facilitate pooling on-chain (arxiv:1807.11218)
    • Cap sizes
    • Node reward proportional to reputation and pledging (PoS)
  • Beyond SMR

Frontrunning DAG-based blockchains ( paper )

  • Intra-block frontrunning = builder frontruns.
  • Inter-block frontrunning = exploit block ordering rules for profit.
  • Mitigations:
    • Ordering (paper: Zhang OSDI'20)
    • Hidden content in blocks
    • Non-deterministic ordering rules
    • Transaction reordering

Selfish mining strategies (paper)

  • Motivation: fee-driven blockchain systems.
  • Framework
    • Strategy formulation (profitability)
    • Model formulation (number, incentives, …)
  • Conclusions drawn:
    • Miners act as service providers; fees are revenue!
    • Fee-based strategies need to be considered

Good Things Come to Those Who Wait: Dishonest-Majority Coin-Flipping Requires Delay Functions (paper)

  • Need an unbiased, secure random beacon (tolerating dishonest majority??)
    • Colluding participant can predict things without changing attacks.
    • Performing offline timed drop-outs
  • Delay functions circumvent impossibility results seen previously

Privacy and ZK

Liquefaction: Privately Liquefying Blockchain Assets (paper)

  • TEE-based key gets encumbered with policies.
  • Allow users to select and choose the policies that the wallet can interact with (sending X tokens, interact with contract, etc.)
  • Fine-grained allowing people to add more security focused policies on their wallets.

Interactive Multi-Credential Authentication (paper)

  • Hacks continue to happen - multi-sig isn’t working.
  • A lot of interaction requires synchrony
    • e.g. bank account has a cooling off period when adding someone as beneficiary.
  • Mechanism of a 2-player game (user, attacker); user has mechanism/vault with N-credentials, adversary trying to gain access.

Dynamic zk-SNARKs (paper | video)

  • Motivation: data structure in proof that can have updates without re-computing entire proof.
  • Dynamic SNARK = SNARK + update
  • Runtime goal is sub-linear (else just recompute the proof)
  • Relaxed permutation relations
  • Introduce Dynamo

Efficient Vector Range Proofs and Their Application to PVSS (paper)

  • batch ZKRP called DekartProof, \(O(m\ log\ n)\) proving elements of v are in \([0, n)\).
  • generalised to a set of values in arbitrary ranges.
  • Uses the ZK sum-check protocol.

Bitcoin and interop

  • BitVM2
    • Key ideas: snark verifier, stateful scripts.
      • use signature as state, enforce value x in script for A and B.
        • reuse the signature as state.
        • Lamport signatures make it possible.
  • Optimistic computation and falsification.
  • BitVM bridge = getting BTC to other chains, but is clunky because of setup and requirements.
    • Most people use swaps
    • Use the bridge for high-value bridging.
  • BitVM3 updates with garbled circuits to make it more efficient.
    • Trustless Bitcoin Vaults (David Tse, Babylon)
  • Bitcoin-backed lending
    • collateral to borrow
    • vault as collateral; all withdraw on bitcoin.
    • Uses HTLC for verifications, don’t need covenants yet.
  • Babylon whitepaper released.
  • Working on more efficient proofs and making the unhappy path more efficient.

Frontiers by Paradigm

Probably one of the most enjoyable engineering-focused conferences that I’ve attended, and a special place in my heart because there was so much about Rust. I’ve been following the frontiers / Ethereum-rust conference since its inception, and finally got a chance to visit in-person!

The talks ranged from user-focused libraries and UX, all the way down to optimisations in underlying clients and consensus changes. It definitely exceeded far beyond my expectations, and I will definitely be looking to go back. I highly encourage everyone to check out the Paradigm YouTube Playlist that goes through the content of the conference.

Let’s get down to some of the epic talks! I do encourage everyone to watch any of the talks that interest you, since I won’t be able to cover everything.

Reth

The future of Reth By Mattias Seitz: https://www.youtube.com/watch?v=cc45Rcmrro4

  • Users are looking for tooling and want to build on-top of the EVM to interact with the chain.
  • Moved to more of an SDK-style codebase
  • New architecture to remove just feature flags, more into a flexible architecture.
  • Reth SDK: a fully type configurable node.

Ethereum Acceleration with Reth by Roman Krasiuk: https://www.youtube.com/watch?v=FW1Fe15Y9KA

  • ZK unlocks for Ethereum
    • Has prerequisites
    • Need slot restructuring and gas pricing
  • ePBS gives allocated time for provers to prove blocks.
  • Gas repricing (point_eval, ecpairing,…) and inefficiencies within the EVM.
  • Provide endpoints so that a user can use a prove_* to prove something.

Hyperoptimizing Reth by Alexey Shekhirin and Dan Cline: https://www.youtube.com/watch?v=z3tj8Lk_Ydo

  • Approach
    • Pipelining
    • Utilising intelligent resources
    • Optimistic execution
  • Profiling (samply) and benchmarks.
  • Thread pinning and using all resources as they can.
  • Optimisations:
    • Caching and prewarming
      • Optimistic execution of transactions.
      • Pulls everything off disk before the full transaction is executed.
      • 30% improvement.
    • Sparse tries, parallel hashing,m prewarming can fetch the trie nodes.
      • Split the trie into smaller tries.
  • Next steps:
    • Trie DB: store the merkle tree directly on disk instead of converting into B-Tree or LSM.
    • Minimise overhead of IO or trie calculations.
    • Parallel EVM.

User Facing (UX/UI/Wallets)

Porto by Awkweb: https://www.youtube.com/watch?v=Pg4gDE_eZh0

  • A lot of on-boarding non-native crypto users are not very friendly.
  • Porto = auth + payments in a library.
  • Developer libraries, gives an authenticated user that can be managed in the db.
  • Drop-in SDK; Passkeys; and builds with all the tooling from the ground up.

Leveraging Protocols to Transform UX by Henri Stern: https://www.youtube.com/watch?v=diBMz27M70o

  • So many standards and protocols, how do you get user experience to be better?
  • UX:
    • done right: can ship better and faster. (leverage existing infra, TAM expansion, tech flexibility)
    • done wrong: will destroy you. (won’t ship, exhaust to your constraints)
  • Privy wallet
    • MPC, TEE, Secret sharing
  • Protocols need time to mature.
  • Lean on existing protocols (it will ease adoption and future-proof your build).

Foundry by 0xRusowsky and Dani Popes: https://www.youtube.com/watch?v=lpD83wlnOhQ

  • Need for better guardrails (hundreds of millions of dollars are at stake due to small bugs and hacks that can be avoided).
  • What’s next?
    • built-in lints and formatter, middle-end IR (backend agnostic intermediate representation) and code generation.
  • Alloy
    • rewrite of ethers-rs from the ground up
    • faster encoding and operations
  • support for new codes and ERCs
  • Uses the revm for testing, improves speedup.

Cool talks

Scaling Ethereum’s State Trie by Brian Bland: https://www.youtube.com/watch?v=rq4EghqoIZk

  • TrieDB: speeds up the data access from \(O(log^2\ n)\) to \(O(log\ n)\).
  • Problem: existing nodes store the MPT, lots of data.
  • Multiple databases available, but are a poor fit for the Ethereum MPT.
  • Smaller subtries are stored into 4KB pages (since that is optimised for an IO write.)
  • No overlap for subtries (might be good for parallelism)

MonadBFT: Tail-fork resistant streamlined consensus by Michael Chen: https://www.youtube.com/watch?v=n0_gtcLWDno

  • Implemented a fan-in-fan-out, fast version of HotStuff.
    • During testnet, they found a pattern of back-to-back skipped blocks.
  • Pipelined HotStuff
    • Proposal is sent, QC will be on the next round.
    • Problem: if a node is offline, there will be a two-block timeout because they won’t get the votes or the next round’s information.
  • Tail forking?
    • lost rewards (for honest nodes)
    • MEV exploits (malicious bundling so that they can unbundle a block and capture the rewards)
    • bad UX: voted block reverting.
  • Tail-fork resistance:
    • Next leader will form QC using tip_vote or re-propose the highest tip.

Malachite: A fast and flexible BFT Consensus Engine by Adi Seredinschi: https://www.youtube.com/watch?v=blOJtUTFGb0

  • Crypto is stuck on a local minimum
    • not many people doing hard and difficult problems
    • we should be doing more to build the better protocols
  • Need flexible alternative for CometBFT.
  • Three APIs:
    • Channels API (tokio, streaming, connectors.)
    • Actor API (block sync, mempool, p2p, discovery)
    • Core Libraries API (consensus state machine)
  • In reality, not many actors that are interacting in the BFT consensus.
    • Supporting very large is quite a difficult problem.
  • ZCash Crosslink - they want to go from PoW to hybrid / PoS.
  • Multiproposer
    • Muppet - constructed on top of tendermint, pipelined. (~10x improvement)
    • Two-phase tendermint. (~30% latency reduction)
    • EVM compatibility.

Real-time Proving Ethereum with SP1 and Reth by John Guibas: https://www.youtube.com/watch?v=7tl6B0FbUpM

  • Real-time proving: generate zk proof of execution of a block in < 12 seconds.
  • What does it look like?
    • Block proof without re-executing the block.
    • Verification takes milliseconds (can do it on a Raspberry Pi!)
    • Paves the path to Ethereum becoming the real world computer (100x improvement).
  • SDK: SP1 (a RISC-v zkVM)
    • lets you prove any piece of software.
    • Sp1 is the easiest way to use zk proofs with great performance.