I’ve been lucky to attend a few conferences over the start of August and I wanted to write some notes over my takeaways.

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.

I had the chance to attend 3 main conferences, and a few side events:

On to the content!

SBC 2025

Blockchain Address Poisoning

  • Authors: Taro Tsuchiya, Jin-Dong Dong (Carnegie Mellon University); Kyle Soska (Independent); Nicolas Christin (Carnegie Mellon University)
  • paper | video

Notes:

  • Scenario:
    • User A wants to send funds to User B.
    • User A sends a small test transaction to User B’s address to check that it is correct.
    • Mallory (Adversary) sends a small test transaction to User A with a ‘similar’ address (e.g. starting and ending in the same characters) to confuse the user.
      • A smarter strategy uses a smart contract with a token named similar to the original one, where the adversary imitates a transfer from User A to their adversarial address to make it seem like User A sent the funds.
    • User A sends funds to Mallory’s address since they see and use the latest address on their transaction list.
  • Adversary sends money from ‘similar’ addresses (e.g. starting and ending in same characters) very soon after the user sends a test transaction. The aim is to confuse people.
  • What mitigations are there?
    • Better UI
      • Warnings on the wallets, similarity scores.
      • Have safeguards that require checks.
    • Naming (e.g. ENS, naming services)
    • Protocol level human readable names.
      • Delay on wallet creations for adversaries to farm addresses.
      • Remove the 0-value transfer on smart contracts.
    • A pass/deny list for the addresses.
  • Created a real-time site: Toxin Tagger.

Measuring and Attacking Ethereum

  • Authors: Chenyu Li (Institute of Information Engineering, Chinese Academy of Sciences; University of Chinese Academy of Sciences); Ren Zhang (Cryptape and Nervos); Xiaorui Gong (Institute of Information Engineering, Chinese Academy of Sciences; University of Chinese Academy of Sciences)
  • paper | video

Notes:

  • Typical P2P networks are only for 1 purpose/service (e.g. bittorrent)
  • Ethereum’s network has over 7000 services.
    • Testnets, rollups, applications piggy backing off the network, etc.
    • Very noisy
  • How is this possible?
    • Started with DISCv4 - a networkID was built in to the protocol.
      • It meant that other networks were already accounted for.
    • Deliberate design choice and has carried over to DISCv5.
  • What existing studies say?
    • IMC 2018: very noisy network, jumble of clients and services.
    • 2025: many services, inefficient network.
  • Benefits
    • Code Reuse
    • Reduce deployment requirements.
    • Node discovery is better (wider range of nodes operating)
    • Large pool
  • Technical Roadmap of Ethereum’s Global Network (EGN) vs Dedicated
    • EGN:
      • DISCv4: no priority for same service peers.
      • DISCv5: added service advertisements.
        • 91% of nodes don’t advertise a service ID or client ID.
        • Still doesn’t have a deployment of same-service priority as described in the writing.
        • Under 20% of peers are same-service peers.
    • Efficiency of Discovery:
      • ~10k handshakes per successful connection
      • A dedicated network usually has 96% efficiency.
      • Bitcoin (for example) has 4 handshakes per connection.
  • Experiment with DISCv5
    • 1 million+ findnode messages; 100k+ handshakes, 0 connections.
    • 2/3 always online nodes = 81% of the DHT unresponsive.
      • Possibly due to full connection tables.
  • DHT pollution:
    • 300 notes, sending ping, or responding findnode.
    • dedicated network is stronger, less attack surface.
  • Results from experiments:
    • \(1/2\) public nodes have under 5% same-service peers.
    • \(> 3/4\) handshakes are with nodes of different/incorrect service.
    • DISCv5 does not fully implement what it designed (yet).
    • Blended nature of the network is a vulnerability.
    • The large network is good, but must be robust and available to make use of if.
    • Being driven by convenience is not a good argument.
      • Comes with big cost and drawbacks.
      • Makes it a noisy network.
  • Takeaway:
    • Service-specific networks are far more efficient for forming peers with relevant information.
    • Look at the network topologies, what can be done to optimize the service peer routing?

De-anonymizing Ethereum Validators: The P2P Network Has a Privacy Issue

  • Authors: Lioba Heimbach, Yann Vonlanthen (ETH Zurich); Juan Villacis (University of Bern); Lucianna Kiffer (IMDEA Networks); Roger Wattenhofer (ETH Zurich)
  • paper | video

Notes: (aside: I will not go into detail, since there is still a disclosed, but open way to de-anonymize the validators using statistical analysis provided in this paper.)

  • Why does anonymity matter?
    • DoS vector to make validators miss proposals/attestations.
    • If ahead of time-known, can become a target or censored.
  • Ethereum Subnets
    • Way to make attestations more efficiently propagated through the network.
    • Validators maintain a per in various subnets, at least a peer in all subnets.
    • Aggregator has the job of aggregating all the attestations for that subnet, and sending them outward.
  • Peer privacy:
    • Node can see IP of direct peer (and the subnets)
    • They’re not supposed to know if they are validators, or just nodes in the network.
  • Methodology for de-anonymization:
    • Announce all the subnets
    • Whenever a peer sends attestations, look at which subnets they are sending.
    • Can use inference.
  • Validator distribution
    • \(80%\) peers have \(< 100\) validators.
    • One node has \(19K\) validators!
    • Staking pools on average have more, often \(1000\) nodes configured.
    • Node operators have multiple (overlapping) pools.
    • \(90%\) from cloud (\(20%\) AWS; OVH, GCloud)
  • Mitigations?
    • Anonymity
      • Use separate nodes (one for attesting, one for proposing)
      • Try to gossip all together (private peer agreement, all subnets)
    • DoS
      • Network defence.
      • Distributed validators
      • Secret leader elections to hinder who might be rotating in future.
  • Takeaways:
    • Care on messaging patterns and what should be kept private / secure.
    • Gossip should be carefully looked at, gossiping everything vs optimizations.
    • Leader election strategies and public information.

User Perceptions of Security Auditing

  • Authors: Molly Zhuangtong huang, Rui Jiang (University of Macau); Tanusree Sharma (Pennsylvania State University); Kanye Ye Wang (University of Macau)
  • paper | video

Notes:

  • Web3 security deserves much more attention.
  • Insufficient comprehensiveness for everyday users.
    • User’s usually don’t see the reports (unless they are interested and go digging)
    • Information in the report is not detailed enough to give in-depth information.
      • Usually they are oversimplified.
      • Users can’t tell what the problems actually were caused by.
  • Sentiment analysis:
    • Diverse, but signs are skewing to negative sentiment of security review reports.
    • Questioning the independence of the audit firms.
      • And how impartial they are to the product.
    • Lack of reputation amongst many of the audit firms.
    • Cost of an audit
      • Usually no public pricing information (and now way to find except for a quote)
      • Acknowledge that different projects are different, often workload-dependent cost model.
  • Impact of a security audit:
    • Users usually have a brief browse through.
    • They don’t read the full report, only want to know what went wrong.
  • Challenges of users to understand the tech.
    • Big reports and careful writeups help with their understanding.
  • Implications:
    • Blog, Discord, Knowledge sharing channels are a big help.
    • Audit firms should be presenting vulnerabilities and sharing the knowledge and deep look into them.
  • Takeaways:
    • End-users don’t have much care about the full report, but they want to know the depth (as well as explained well).
    • Most of the reports don’t go into detail about what happened, some users want to have a deep dive.
    • Security firms are not openly public, they don’t post their information and could be beneficial to share more and have more knowledge sharing channels.

Accountable Liveness

  • Authors: Andrew Lewis-Pye (London School of Economics); Joachim Neu (a16z Crypto Research); Tim Roughgarden (Columbia University & a16z crypto); Luca Zanolini (Ethereum Foundation)
  • paper | video

Notes:

  • Accountable safety is possible - can identify the byzantine actors in the systems.
  • Accountable liveness, the goal is to also identify the byzantine actors in the system, but need to distinguish from natural faults that occur.
  • Most safety have a safety proof:
    • Honest nodes are not accused because the proofs show their innocence.
    • Slashing/punishment is left for the protocol to define.
  • Liveness: transaction remains unconfirmed for a longer time than necessary.
    • Use logs of messages.
    • Find the votes for nodes that are omitting votes, etc.
    • Prove absence of expected messages.
      • Network Delay?
      • Byzantine adversary can frame another node.
    • Theorem:
      • Only applicable to networks where they are more synchonous than asynchronous.
      • Not even partial-synchrony works.
  • Introduce x-partial-sync:
    • GST for partial sync.
    • Introduce window and views of synchronicity.
    • Break up the time into chunks (windows), with smaller slices (views);
    • Each view can be synchronous or asynchronous.
  • Main result:
    • Augment protocols so that \(f < \frac{n}{2}\); x-partial-sync: \(x < \frac{1}{2}\)
      • \(x\) is the number of synchronous views in a window.
  • Blame accounting: q blames r (e.g. nodes will blame other nodes of not voting if they don’t get the messages)
    • Additional messaging on rounds, having a blame step
    • In synchronous views, the honest nodes will not report other honest nodes.
    • Byzantine nodes will always be identified
      • Because honest nodes will report them in both sync and async views; whereas honest nodes will only be reported in async rounds at most.

Mysticeti: Reaching the Latency Limits with Uncertified DAGs

  • Authors: Kushal Babel (Cornell Tech ; IC3); Andrey Chursin (Mysten Labs); George Danezis (Mysten Labs & University College London (UCL)); Anastasios Kichidi, Lefteris Kokoris-Kogias, Arun Koshy (Mysten Labs); Alberto Sonnino (Mysten Labs & University College London (UCL)); Mingwei Tian (Mysten Labs)
  • paper | video

Notes:

  • Bandwidth vs Latency Delay
    • Not all messages are equal (propose messages, data messages, etc.)
    • Primary node broadcasts to all
      • Gossip / subset replications.
    • Censorship is possible pre-view change.
  • DAG (DAGRider)
    • concurrent proposal; 3 message delay.
    • Block (round number, payload, previous blocks, vote signatures)
    • Links to 2f+1
  • Mysticeti
    • Mysticeti-C (upgrade, happy-path)
      • Accept votes are included by all other blocks.
    • Mysticeti Pipelined
      • Slots can be leader elections
    • Results: 50 nodes has 400K+ TPS (~500K)
      • SUI mainnet changed from Narwhal and Bullshark to Mysticeti.
  • Real world
    • If A links to B; A must be in the DAG before B.
      • If A was slow, B is slowed.
      • Garbage collection added to blocks, better broadcast.
      • Score-based block

Permissionless blockchains from Physical Resources

  • Authors: Mirza Ahad Baig, Christoph U. Günther, Krzysztof Pietrzak (Institute of Science and Technology Austria)
  • paper | video

Notes:

  • Two papers previously:
    • 2025/1410 : Nakamoto consensus from multiple resources
    • 2025/… : On the (in)security of Proof of Space
  • Can’t get Nakamoto-like consensus from storage alone.
  • Fully permissionless: protocol doesn’t know of parties.
  • Physical Resources:
    • Work, space, velocity
  • Proof of Space:
    • Initialization: store p on disk; challenge c on disk with proof
    • Proof is slow because they have to go through n parts, but the challenge c is easy.
    • Creating proofs is slow, proving should be quick.
  • Verifiable Delay:
    • Take some input x and some T steps; should output y with a proof \(\pi\).
    • The proof should verify that T sequential steps were used to produce y from x.
xTVDFyproof

  • Categorising:

    • Quantitative: Work, Space
    • Qualitative: Velocity
    • Timed: Work, Velocity (x/second, e.g. hashes per second)

  • Chia Network: honest * VDF > adversary * VDF

  • Secure Resources: investment goes into weight.