Blockchain protocol security audit for New L1s: Consensus, P2P, and Cryptography Review

Short description (1-2 sentences): This playbook is your go-to guide for decision-makers diving into new Layer-1 blockchains. It’s all about getting your hands dirty and figuring things out as you go! This guide dives into checking the safety and liveness of consensus mechanisms, making sure peer-to-peer systems hold strong, and picking the right cryptographic methods with clear guidelines. Plus, it looks at recent events and gives you some solid criteria to measure acceptance. You can expect to discover some exciting new best practices from Ethereum, Cosmos/CometBFT, and libp2p that you can start implementing in just a month or so! Whether you’re looking to dive into something fresh or just want to upgrade your skills, these insights are definitely worth checking out.

Who this is for and why it matters

So, when you're choosing or launching a new Layer 1 solution--whether it's for a public network, an enterprise rollup setup, or a regulated consortium--just running a code scan isn't going to cut it. In this guide, we're going to explore three crucial factors that play a big role in whether your chain can handle tough situations: consensus, peer-to-peer networking, and cryptography. Let’s break it down! Let’s keep things down to earth. We’re going to dive into some recent bugs and CVEs, check out the current RFCs, and outline some testable criteria that you can easily weave into your RFPs and go-live checkpoints. Sound good?

So, here’s what you can look forward to when you go through an audit:
Here’s a handy list that ranks safety and liveness risks. Plus, I’ve included some test cases that you can easily replicate!
We’ve got clear key performance indicators (KPIs) for things like propagation speed, finality, and how our validators perform under pressure.
We've got a crypto setup that's all set for migration, along with some thoughts on our plans for dealing with post-quantum challenges. We're putting together a 90-day plan to get things back on track. This plan will break down who’s in charge of what and highlight which versions we're working with.

1) Consensus review: from whitepaper to adversarial reality

1.1 Choose (and constrain) the consensus family

Most new Layer 1 blockchains usually fit into one of three key categories:

BFT/leader-based: Imagine something like Tendermint/CometBFT or those HotStuff offshoots. These are awesome for wrap-up sessions and they come with pretty straightforward rules about slashing.
Nakamoto-style: So, this is all about the longest-chain method, which depends on either Proof of Work (PoW) or Proof of Stake (PoS) to keep things running smoothly. It provides a sort of probabilistic finality, which is pretty cool, and it also simplifies networking a bit.
Hybrids: So, hybrids mix things up a bit by bringing together different elements. For instance, they might use finality gadgets instead of sticking strictly to a fork-choice rule. A great example of this is Ethereum’s Gasper. It pairs the LMD-GHOST fork choice method with Casper FFG finality, which really makes it interesting! For more info, check this out here. You'll find all the details you need!

Why This Matters for Audit

Alright, so here’s the scoop: the safety proof only kicks in if we stick to the timing and leader assumptions we've got in the protocol. When we actually try to put this into action, we come across some pretty tricky situations. Things like catch-up scenarios, vote extensions, changes in the proposer, and those DRY-run phases aren't really addressed in the original paper. It definitely keeps us on our toes!

Check out HotStuff's history and updates, like HotStuff-1. It includes one-phase speculation and linear communication, which can really help you understand how to keep things running smoothly, even when the network isn’t totally in sync. We really need to make sure that any "speculative confirm" pathways won't jeopardize safety. It's especially important to think about this if a leader tries to play both sides or if the network ends up getting split. If you're curious and want to dive deeper into the details, feel free to check out the paper here. It’s got all the info you need!

Practical Acceptance Criteria

Alright, let's break this down. First things first, write down the key things you want to keep in check. You definitely want to make sure that no two conflicting blocks get the green light at the same time. Also, it’s important to keep things moving along smoothly, especially when that Δ-synchrony comes into play. And don’t forget to keep an eye out for slashing when it comes to certain equivocations!

After that, you'll want to back those up at the specification level using some cool tools like TLA+, Coq, or Agda. Once you've got your implementation paths sorted out--like catch-up, reorg, and proposer changes--try putting them through some tough situations. Testing them in adversarial scenarios is a great way to make sure that your proof assumptions are still rock solid. Take a look at this link: (arxiv.org). It's pretty interesting!

1.2 Learn from recent incidents (and bake the lessons into go‑live gates)

So, back on January 21, 2024, there was this annoying bug with the Ethereum Nethermind execution client that really messed things up. Some validators ran into a hiccup where they mistakenly marked a valid block as invalid. This happened because they hit an unhandled overflow while trying to decode a revert message. So, unfortunately, that meant those validators had to pause their attestation, which really stung because they ended up missing out on rewards until they managed to roll out a hotfix. It's tough when glitches like that happen! 25. 2). So, what’s the bottom line here? We really need to keep those JSON-RPC/UI "convenience" paths totally separate from the code that’s essential for reaching consensus. It’s super important! Also, it's a good idea to do some cross-client differential tests before we roll out any updates that could impact transaction decoding or error messages. It just helps us catch any potential issues in advance! If you want to dive deeper into the details, just click here. Happy exploring!

In the CometBFT world, we've got some CVEs on the horizon for 2024-2025 that really point out how even the smallest hiccups in the validation process during sync and vote extension can seriously slow things down. It's a good reminder that every little detail counts! Hey there! So, there was this little hiccup with the VoteExtensionsEnableHeight validation bug, but don't worry, they patched it up in version 0. 38. 3. So, there was this really frustrating issue with the block sync peer that kept getting stuck on the “latest height.” It felt like we were stuck in an endless loop of sync attempts! Thankfully, they managed to fix it in version 0. 38. 17/1. 0.

1. Oh, and we can’t overlook the bit of a disaster that was the invalid BitArray handling--it could seriously trip up networks and bring them to a standstill. Thankfully, that issue was addressed in version 0. 37. 16 and 0. 38. 19. So, what’s the takeaway? We’ve got to seriously think about those bootstrap and sync protocols, plus the default settings when it comes to evidence that’s crucial for reaching consensus.
It’s smart to throw in some rogue peer behavior simulations while you’re syncing. It really helps to be ready for any surprises! If you want to explore this further, you can check it out here.

Operational Gate

Before we dive into the mainnet launch, it's super important that we have a mix of clients and reliable failover procedures sorted out. Let’s make sure that no single client holds more than a two-thirds stake, okay? We definitely need to make sure we’ve got a solid plan in place for handling emergency downgrades or hotfixes, and it would be great to have practiced that on the testnet beforehand. It's really crucial for us to have some monitoring set up. That way, we can quickly spot any drops in participation or stalls in finality. For our testing, we’re going to use the upstream consensus specs as our main regression suites. That way, we can keep everything consistent and reliable. If you want to take a look, you can find them right here: github.com.

1.3 How we audit consensus (deep‑dive steps)

Spec conformance
Just double-check that your implementation matches the official spec. If there isn't one available, feel free to create your own! If you’re aiming for something similar to Ethereum’s Proof of Stake, make sure to connect those test vectors to the executable PySpec. It’s also a good idea to keep an eye on those fork-epoch transitions--just like you’d do with Deneb, Electra, Fulu, and even your own fork heuristics. If you're looking for more details, check this out here.
Formal invariants If you're up for it, why not dive into modeling fork choice, finalization, and slashing using TLA+? It could be a fun challenge! And hey, if you prefer Agda or Coq, feel free to explore those options instead. Whatever works for you! Let’s dive into some fun stuff! We need to show that our system is safe and can keep on chugging, even when things get a bit crazy. Think about throwing in some random network hiccups and those tricky Byzantine proposers. You know the type--those who might hold back votes, show up late with their proposals, or even play both sides. It’s all about testing the limits and ensuring everything runs smoothly, no matter what kind of shenanigans come our way! Want to explore this more? Check it out here!
Adversarial fuzzing Whenever you get the chance, try out differential fuzzing with two or more clients. It can really pay off! When it comes to those beacon-style systems, it’s best to stick with that community-driven approach we’ve seen tackle a ton of tricky consensus edge cases, like the beacon-fuzz lineage. Just make sure to keep those crash reproducers close to the vest until you’ve patched everything up! Check it out here.
Slashing correctness Hey, just a reminder to double-check those slashing protection databases and interchange workflows (EIP-3076). It's really important to ensure they actually prevent any accidental double-signing, especially when you're migrating clients or dealing with any time skew issues. Hey, just a quick reminder to make sure you test your watermark repair and check out those import/export flows! You can find all the details you need right here. Happy experimenting!

KPIs to Demand in Reports

Time-to-Finality Percentile (p50/p95): This metric is really crucial, particularly when you're dealing with unreliable links and hesitant leaders.
Reorg Depth Distribution: Make sure to watch this closely during those chaos tests. It’s a great way to see how everything stands up when things get hectic!
Evidence Processing Throughput: Our goal here is to spot those slashing events without missing a single one - let's make sure we're on top of it and catching everything!
Client Diversity and Auto-Failover MTTR: It’s really important for us to keep an eye on the variety of our clients and how fast we can bounce back if something goes wrong.

2) P2P layer review: resist eclipse, DoS, and routing‑layer attacks

2.1 Know your attack surface

Eclipse/DoS at the gossip layer: So, things like Sybil floods, dropping messages selectively, and messing with the mesh can really throw a wrench in the works. They can isolate nodes or slow down how quickly messages get around, which can really put a damper on the whole network's activity. If you want to dive deeper into it, just click here for more details!
Routing-level attacks: BGP hijacking is such a pain! It can mess with traffic, censoring or redirecting it for validators and peers, which is definitely not ideal. So, there was this study from 2025 that took a deep dive into Ethereum's proof of stake. It uncovered some pretty concerning stuff, like how tactics called “StakeBleed” and “KnockBlock” can be used to mess with traffic. Definitely not the best news, huh? On top of that, the IPFS ecosystem really shows how centralization at the Autonomous System (AS) level can amp up BGP censorship efforts. Hey, just so you know, your L1 isn't completely in the clear either! If you want to dive deeper into this, feel free to take a look at the study here. It has some great insights!
Real-world example: Hey, do you recall the KLAYswap situation from 2022? They had this BGP hijack that really messed things up, redirecting users to some sketchy assets. It was a wild ride! It's a great reminder that audits shouldn't just focus on the on-chain stuff. There's so much more to consider! Don’t forget to consider the infrastructure along with any CDN or S3 dependencies because these can really affect how the node software, relayers, and frontends work together. If you’re curious to dive deeper into this topic, feel free to check it out here. It's worth a read!

2.2 Adopt hardened gossip and transport defaults

So, if your L1 is running on libp2p, here are a few things you should definitely consider:

Enable GossipSub v1. 1 Hardening: So, this covers a few things like peer scoring, keeping our mesh in check, making sure we flood publish for that initial hop, and using backoff-on-prune. These features are built to help your system deal with Sybil and eclipsing attacks in a smoother way. Take a look at this link for all the details: research.protocol.ai. You’ll find some really interesting insights there!
Adjust the peering degree: Kick things off with D set to around 6--aim for somewhere in the ballpark of 4 to 12. Don't forget to put your setup to the test with some scale testing to make sure everything's running smoothly! If you set your degree too high, you'll end up wasting bandwidth, and if it's too low, you might make your system a bit shaky. If you're looking for more details, check this out: docs.libp2p.io. It's got a ton of useful information!
Choose QUIC with UDP: Make sure to use TLS 1. You’ll love how it speeds up those handshakes! Plus, with built-in multiplexing, you'll get more done and won't have to deal with that annoying head-of-line blocking. Oh, and if you’re using browsers or wasm peers, they’d definitely get a lot out of WebTransport over QUIC. It could really enhance their experience! Hey, just a quick reminder to double-check those early data points and take a look at the certificate/peer-ID binding when you're working in your testnets. It’s always good to stay on top of that! If you're curious to dive deeper into this topic, feel free to check it out right here: (docs.libp2p.io). Happy reading!
Get ready for DoS attacks: Make sure to set some limits for each peer and IP, and don't forget to establish CPU and memory budgets for every stream. This way, you’ll be better equipped to handle any potential attacks! Hey, just a quick reminder about reputation decay--it's something you definitely want to keep in mind! Also, it might be smart to tie these measures in with your operations tools, like fail2ban. And don’t forget to rate-limit any heavy RPCs; it'll save you some headaches down the line! If you want to dive deeper into this topic, feel free to take a look here: (docs.libp2p.io). Happy reading!

Hey there! If your L1 is using Ethereum's devp2p, here are a few things you might want to take a look at:

Hey there! Just a quick reminder to take a look at the discovery (v5) process, check out the RLPx/TCP transport, and dive into how the compression works. It’s super important to get a good audit on all of that! Thanks! Hey, just double-check that you’ve got Snappy negotiation set up and that the DoS guardrails are in place like EIP-706 suggests. Let's also beef up the hello/version parsing and make sure that the snap/eth protocol limits match up with the specs. If you want to dive deeper into it, check it out here: (eips.ethereum.org).

Network-level controls (chain-agnostic)

Get some multi-home validators and seed nodes up and running with different ISPs and ASNs. Don’t forget to set up RPKI ROAs for the prefixes you’re announcing! It’s super important to keep everything secure and running smoothly. Whenever you get the chance, it’s a smart move to use anycast for your bootnodes and trackers. Trust me, it really pays off! To keep things safe and sound, it's a good idea to handle TLS termination at the nodes or VPN peers that you’re in charge of. Try not to share any plaintext discoveries or metrics out there on the public internet. It's better to keep that kind of info private!

2.3 Test at scale (before launch)

Hey, why not try out some attack scenarios using libp2p’s hardening and test plans? You could mix in some GossipSub-aware tracers like Hermes for a more detailed look at the interactions. That way, you’ll get a better understanding of how everything works together! This will give us a clearer picture of how grafting and pruning work, plus we'll be able to see scores and message delays when we encounter Sybil flood attacks. Check it out here!. Alright, let's dive into testing the topic-level backpressure and pruning with a bunch of simulated nodes. I'm talking about scaling it up to tens or even hundreds of them! When you’re going through this, be sure to check out:

The p50/p95 block and transaction propagation is hitting over 90% of our peers.
Let's take a look at how the mesh churn rate and score distribution fare when it comes to those targeted drop attacks.
Keeping the balance of inbound and outbound ratios steady can be tricky, especially when teammates start exaggerating their capabilities.

3) Cryptography review: BLS, KZG, threshold signing, and PQC readiness

3.1 BLS12‑381 done right

BLS is really gaining traction for validator aggregation, but there are a few key things you should be aware of:

Just a heads up, it's really important to stick with a reliable library that’s been audited and is constantly being verified--like blst. This way, you’ll ensure your work is secure and up to date! Make sure to follow RFC 9380 when you're hashing to a curve. This way, you can steer clear of those pesky side-channel attacks and any potential problems with invalid curves. It's a smart move to keep your data safe! Just a quick reminder to make sure you’re checking those subgroups and clearing out any cofactors. It’s super important!

To protect against those pesky rogue-key attacks, it’s a good idea to set up proof-of-possession (PoP) modes. So, with Ethereum, they actually use what's called a deposit signature as a Proof of Presence (PoP). Pretty interesting, right? If you're collecting signatures without Proof of Possession (PoP), you'll need to gather different messages and ensure that this requirement is enforced right at the API level. Check it out here.

If you're thinking about BLS-signed transactions or precompiles, I really recommend checking out the design trade-offs in EIP-7591 and EIP-2537. Make sure to pay attention to the gas costs and any potential DoS situations before you jump in. It’ll make a big difference in your understanding! If you’re looking for more details, just check this link here. Happy reading!

Practical Checks

Let’s do a bit of static analysis to check for any non-constant-time branches when we're handling scalar multiplication, pairings, and hash-to-curve. Let’s run some fuzz tests on those invalid encodings, infinity points, and subgroup twists and see how they handle it all. It’ll be interesting to see what shakes out! Hey, just a quick heads up! Be sure to use deterministic serialization, and don’t forget to include some test vectors that are compatible with various implementations. It’ll save you a lot of headaches down the line!

3.2 KZG commitments and data availability assumptions

Hey there! If your L1 or L2 is using KZG commitments--like for handling blob data--it's really crucial to take a moment and review your trust assumptions and retention windows. You want to make sure everything's in check! Thanks to the Dencun upgrade on Ethereum, we now have EIP-4844! This update introduced these cool “blob” transactions that are shaking things up a bit. These hold onto the data for roughly 18 days, which is around 4096 epochs. They’re built on a KZG ceremony that’s open for everyone to verify. This ceremony saw a whopping 141,416 contributions and went through several audits to ensure everything is legit! If you're working with those assumptions, just be sure to keep track of how your nodes handle pruning and verification. It's super important to document that stuff! If you want to dive deeper into this, head over to ethereum.org. There's a lot of great info there!

Audit Checklist

Hey there! Just a friendly reminder to double-check that your KZG implementation is using the exact SRS and that you've got the transcript verification process all set up correctly. It’s super important for everything to run smoothly! It's a smart move to stick with the versions you've already audited.

Make sure to set up alerts so you know right away if there are any problems with blob availability. Also, don’t forget to put together some workflows to help you deal with any late or pruned data that comes up.

3.3 Threshold signatures and DVT

So, get this: Threshold Schnorr using FROST just got approved as RFC 9591 by IRTF back in June 2024. Pretty exciting stuff! This protocol is a total game-changer! With its two-round signing and the ability to identify aborts, it’s just right for distributed validators (DVT) and custody setups. It's like having the best tool in your toolbox for those setups!

Hey, have you considered switching your validator keys to threshold signing? It might be a good idea to look into reliable wrappers like ROAST. Or maybe you want to check out those newer “high-threshold” schemes, like HARTS, especially when it comes to those tricky asynchronous situations. Just some food for thought! Make sure you've got some solid procedures set up for recovering at the protocol level and for rotating your keys. It'll save you a lot of headaches down the road! If you want to dive deeper into the details, just head over to this link: datatracker.ietf.org. Happy exploring!

Operational Safety

Think of your signer as a crucial part of your setup. When you're making the switch to DVT or HSMs, don't forget to add those slashing protection watermarks. They're super important! Oh, and make sure to double-check the import/export with EIP-3076 before you go ahead and make any changes. It's super important! (eips.ethereum.org).

3.4 Post‑quantum (PQC) migration you can actually execute

So, back in August 2024, NIST dropped some fresh PQC standards. They came out with ML-KEM (FIPS 203) for key establishment, which is based on Kyber. And when it comes to signatures, they rolled out two new options: ML-DSA (FIPS 204), which is built on Dilithium, and SLH-DSA (FIPS 205), which is derived from SPHINCS+. It’s pretty exciting stuff for anyone keeping an eye on quantum-safe cryptography!

Let's start things off by using hybrid handshakes for your node-to-node channels. They’re a great way to get things rolling! Oh, and don’t forget to keep your protocol crypto-agile! That way, you can easily change your signature schemes without stressing about a hard fork of state. It's all about keeping things flexible!

Oh, and don't forget to stay updated on the SHA‑3 changes, like the FIPS 202 and SP 800‑185 revisions, especially for XOF streaming. Take a look at all the info right here: (csrc.nist.gov). You’ll find everything you need!

Audit Deliverables

Alright, here’s the deal: we’ve got a PQC-ready interface contract. It covers a few important things, like different versions of signer types, estimates for your on-chain verification budget, and some cool hybrid modes for both transport and identity keys. Plus, there’s a timeline in place for phasing out the older, non-PQC ciphers. Pretty neat, right?

4) A pragmatic 30/60/90‑day audit plan for new L1s

Day 0 Artifacts to Request

A protocol spec that outlines the fork schedule and gives you the lowdown on safety and liveness invariants.
Documentation for the P2P protocol (you know, stuff like gossip topics, scoring setups, and rate limits).
We've got a crypto inventory that includes all sorts of goodies like libraries, parameter sets, SRS sources, and the PoP requirements. I’ve got some info for you on the release process and the client diversity plan. Let’s dive into it!
You’ll find test harnesses paired with monitoring dashboards.

Days 1-30: Get a Failing Test Up and Running

Consensus: Let’s kick things off by drafting some adversarial test plans. We need to address issues like proposer equivocation, vote withholding, and those pesky delayed messages, especially when we’re navigating partial synchrony. We're also looking to check out a few fork-choice metrics, such as reorg depth and finality latency. If you've got different clients ready to go, let's connect those differential fuzzers! You can take a look at it right here: (github.com).
P2P: Let’s dive into some simulations! We’re looking at stuff like Sybil attacks, eclipses, score-poisoning, and bandwidth exhaustion. It'll be interesting to see how these scenarios play out! Alright, so here's the plan: we really need to check on the D targets and how the backoff is working. We'll also want to grab those p50 and p95 gossip latencies to see what’s going on there. Plus, let's not forget to make sure we're sticking to the QUIC/TLS defaults and keeping an eye on the quotas for each topic. Sound good? Check out the details over at this link: (research.protocol.ai). It’s pretty interesting!
Crypto: Let’s dive into fuzzing deserialization, check out subgroup validations, and explore the hash-to-curve processes. We should take a close look at our Proof of Possession process from beginning to end. Plus, let’s make sure we can recreate the KZG transcript verification as well. Oh, and make sure you run those side-channel scanners on the hot paths to snag any sneaky issues that might pop up! If you're looking for more details, you can check it out here: datatracker.ietf.org.

Days 31-60: Patch and Harden

Alright, let’s dive into those tricky consensus edge cases we found. We need to re-check the invariants for the updated paths and throw in some regression tests to make sure everything stays on the right path. We'll tweak those GossipSub scores a bit, set some solid limits on CPU and memory for each peer, and add in some anycast bootnodes. Also, let’s make sure we’re really sticking to those peer and ASN diversity SLOs. (docs.libp2p.io). Alright, so here's the plan: we need to get our crypto versions finalized, make sure we document the SRS provenance, and throw in some hybrid KEMs for our transports. Let’s get to it! Let’s get those DVT pilots rolling with some mandatory watermarks, shall we? (csrc.nist.gov).

Days 61-90: Production Readiness Review

Alright, here’s the plan: let’s run a chaos test for a solid 72 hours. We’re going to mix things up a bit with some packet loss and jitter, throw in a few bootnode outages on purpose, and just for fun, we'll add some tricky malicious peers into the mix. It'll be a wild ride, but it'll give us some great insights! The aim here is to ensure that finality remains within our service level agreement (SLA). Let's set up an incident drill that focuses on a bug that’s specific to one of our clients, similar to the issue Nethermind faced back in 2024. We're aiming to get a hotfix out the door in under two hours, and we need to make sure our client diversity helps us avoid any finality loss. (hackmd.io). Hey there! Could you put together a signed risk memo for me? It should highlight any lingering risks and show how they connect to our compensating controls. Also, let’s include a plan for any patches we need to roll out. Thanks!

5) Acceptance criteria you can copy into contracts

Consensus

So, we’ve got really solid performance here--less than 1% packet loss and an average round-trip time of just 100 milliseconds. For most cases, about 95% of them, you’re looking at finality happening in X seconds. Plus, we ran 10,000 adversarial trials, and guess what? No safety issues popped up at all. Pretty reassuring, right?

When it comes to handling evidence, we’re doing great! We’re right on track with 95% of cases being wrapped up in Y milliseconds. Plus, our slashing detection is absolutely on point, hitting a perfect 100% for any defined equivocations. That’s some solid performance!

P2P

Block Propagation: When everything's running smoothly, about 90% of the honest peers manage to get the data within T ms p95. However, if we've got around 30% Sybils in the mix, things slow down a bit and it takes around T’ ms to get the data out there.
Eclipse resistance: We're ensuring that at least Z% of the incoming peers come from different /24s and that we have at least K ASNs in the mix. So, basically, score-poisoning isn't going to drag honest peers below that important threshold.

Cryptography

Hey there! So, just a quick update: we’ve got all the curve operations nailed down, and they run in constant time, which is awesome. Plus, our compliance tests for the RFC 9380 hash-to-curve are doing great too--passing with flying colors! Oh, and just so you know, we’ve got Proof of Possession (PoP) sorted out right from the moment you’re admitted, and the KZG transcript is fully verified, too. No need to stress! Our SRS is locked in and completely reproducible! Check it out here if you want more details!

Alright, here’s the latest on our PQC roadmap: the hybrid transport is ready to roll, and the signer interface is now all set up to handle both ML-DSA and SLH-DSA. Exciting stuff! We've put together a plan to phase out those outdated legacy curves. (csrc.nist.gov).

Supply-Chain Hygiene

We’re all about keeping our supply chain clean, so we make it a priority to create reproducible builds. This helps us achieve that trusted source we’re after--kind of like what you’d find with SLSA Build L2+. When you're about to roll out a new release, it's super important to run differential tests with different clients. And don't forget to have a solid rollback plan ready, just in case things don't go as planned! For all the juicy details, head over to slsa.dev! You’ll find everything you need there.

6) Common design pitfalls (and how to catch them early)

So, remember that incident with Nethermind back in 2024? It really highlights a key point: while it’s super important to enhance user experience, we can’t let that compromise the consensus outcomes. Balancing those elements is crucial! Alright, let’s make it a point to keep decoding and logging paths separate. And don't forget to really dive into those error payloads during testing. We want to make sure they’re all sorted out! (hackmd.io).

So, let’s talk about under-validated sync announcements. A perfect example of this is the CometBFT blocksync regression. It really highlights the importance of regularly checking those peer height reports and making sure we boot out any regressors. It's a great idea to write property tests that simulate non-monotonic latest heights! (rapid7.com).
Gossip knobs set to default: If the D value is too low, things might get a bit wobbly, and if it's cranked up too high, you’re just blowing through bandwidth for no reason. It really comes down to figuring out the right balance for those topic-specific D and heartbeat intervals. After that, you want to run some scale tests to back it up--not just go with your gut. (docs.libp2p.io).

If we're dealing with weak Proof of Possession (PoP) or if things aren’t sticking to hash-to-curve compliance, we’ve got to step up our game. It's super important to make sure we’re using RFC-compliant suites and running PoP checks. Otherwise, we risk letting those rogue keys slip through the cracks! Just a quick reminder: make sure to include some negative tests for any invalid encodings and subgroup violations. It’s really important! (datatracker.ietf.org).

Don’t ignore routing threats: It’s super important to use RPKI, set up a multi-home infrastructure, and stay vigilant for any weird BGP behavior. Running drills that mimic hijacking situations is a fantastic way to keep validator participation and finality above the levels we need. It really helps reinforce our security measures and ensures everything runs smoothly! (arxiv.org).

7) What “good” looks like on day one

A strong, well-agreed foundation that we can back up with real evidence, including tests that challenge it based on actual events and updated code fixes. We've got a P2P stack that’s been really beefed up with some cool features like GossipSub scoring, QUIC/TLS, and smart limits on how resources are used and how peers behave. It's been put through its paces, and it’s showing some impressive results! Alright, so we're talking about some pretty cool cryptography here! We're looking at constant-time encryption that keeps things safe with Proofs of Possession (PoP) in mind. It also has a solid understanding of KZG and post-quantum cryptography (PQC). Plus, there's this version-pinned Structured Reference String (SRS) and a handy signer interface that’s all set up for threshold operations and can easily adapt to different algorithms. How neat is that?
We’ve got release engineering that aligns perfectly with SLSA. This includes cross-client testing and practice runs to make sure rollbacks go smoothly. (slsa.dev).

8) How 7Block Labs can help

We put together a consensus model using TLA+ and give you some solid machine-verified safety proofs. Plus, we take it a step further by recreating scenarios to show what might go wrong in the implementation. So, we got together and put together a testbed for libp2p/devp2p where we could really push things to their limits. We made some adjustments to the scoring system and set some boundaries, and from there, we cranked out key performance indicators (KPIs) for both propagation and eclipse. We even established clear pass/fail criteria so we know exactly where we stand. We really dig into the world of crypto, focusing on stuff like BLS, KZG, PQC, and DVT. This means we go all out with detailed side-channel reviews of libraries and make sure to validate those PoP and KZG transcripts. We've got you covered with a comprehensive 90-day hardening plan, and we're just a call away to help you navigate your first major upgrade.

So, if you’re getting ready to launch your mainnet in the next few months, it’s smart to start your audit around 8 to 12 weeks before you actually freeze your code. Trust me, it’ll give you enough time to catch any issues! Just a quick reminder: any fixes at the protocol level could use a bit of extra care and attention. We're here for you, no matter what stage you're at. Whether you're kicking things off from the ground up or just want to iron out a few issues, we've got your back. Let's make "secure by construction" the norm for your L1!

References and Further Reading

Hey there! Just wanted to share some info about the activation details for Ethereum Dencun/EIP-4844. It’s pretty cool how it’s going to impact data availability and blobs, so give it a look! (ethereum.org).

Curious about the Ethereum consensus specs and the fork schedule for Deneb, Electra, or Fulu? You’ve come to the right place! Check it out here: github.com. Hey, why don’t you check out the HotStuff lineage? It’s pretty cool to see how HotStuff-1 has made some neat improvements. (arxiv.org). Hey, make sure you check out the Nethermind 2024 incident post-mortem along with all the reporting details. You won't want to miss it! (hackmd.io).
If you want the scoop on CometBFT advisories and CVEs for 2024-2025, you’ve come to the right spot! (wiz.io).
Check out the latest updates on libp2p GossipSub hardening! We’ll dive into some cool DoS mitigation techniques, share tips on peering degree guidance, and explore QUIC, TLS, and WebTransport. It's packed with info you won’t want to miss! (research.protocol.ai). Let’s dive into some interesting stuff! We’re going to take a look at routing attacks in Ethereum’s Proof of Stake (PoS) system. We can’t forget about the potential dangers of censorship in BGP and IPFS, either. Plus, I’ll share a case study on a BGP hijack to really give you the lowdown. (arxiv.org). Hey there! If you're on the hunt for BLS libraries and PoP guidance, make sure to take a look at RFC 9380 about hash-to-curve. You can find all the info you need over at GitHub. Happy exploring!
Stay in the loop with the latest news on the KZG ceremony wrap-up and audits! (blog.ethereum.org). Check out the FROST threshold signatures (that’s RFC 9591) and don’t forget to explore the robust and asynchronous versions too! (datatracker.ietf.org).
Keep an eye on the latest news about PQC FIPS approvals and updates on SHA-3! (csrc.nist.gov).
And don't forget to take a look at the SLSA software supply-chain specification to keep yourself in the loop! (slsa.dev).

7Block Labs--Delivering Strong Blockchains from Concept to Mainnet