📌 Welcome to Cryptolytic Research Channel This channel dives deep into the infrastructure and theory behind crypto: consensus protocols, scaling solutions, data availability layers, L1s, L2s… we cover it all.🧑‍🔬 The goal is to help you understand blockchain tech from the

🦈💧Just published a new article breaking down Sui’s original consensus Narwhal & Bullshark. A great entry point to understand DAG based consensus protocols. 🎥 Last week I also gave a live lecture on this topic. 🧵 A summary thread on Narwhal & Bullshark is coming soon. 📘I’m

Intro to Sui Part 2: Understanding DAG-Based Consensus — Narwhal & BullShark (Sui’s previous consensus model)

Intro to SuiNetwork Part 1 : Understanding Sui's Fast path - FastPay and Sui Lutris.

🧵[17/17] Thanks for reading! If you found this thread useful, please like, retweet, and follow so more people can learn what is behind blockchain. Comments or questions? Drop them below. ❤️ If there is any protocol or topic you want me to research, let me know 🧑‍🔬🧪 Keep

🧵[16/17] 📄 Want the full deep dive with diagrams and math? Check out the full article: 📚 https://t.co/9AxUeoJxPo 📚

[15/17] And that wraps up MonadBFT Explained Part 4 and the entire series. 🚀 We covered: 🔷Introduction to 2-phase BFT and tail-forking 🔷MonadBFT 🔷Erasure codes and Raptor codes 🔷RaptorCast Thanks for following along 🙏 For the full deep dive, check the articles in the

[14/17] Now that we have summarized the goals of RaptorCast, let’s put everything together and walk through the full flow step by step: 1. The leader creates a block and partitions it into smaller chunks 2. The leader applies erasure coding to those chunks to add redundancy 3.

[13/17] Now we have seen the full flow of RaptorCast and the problems it addresses step by step. Let’s summarize the goals of RaptorCast to make sure we are on the same page: 🔷Naive block propagation is inefficient since the leader’s upload cost increases as validators increase

[12/17] So why stop at 32 packets per Merkle tree when larger trees would reduce the number of signatures even further? The reason is that bigger trees also make Merkle proofs larger, which means more data must be attached to every packet. There is always a trade-off between

[11/17] In RaptorCast, a Merkle tree is built over a group of 32 packets. That means the leader signs only 1 root instead of 32 separate packets. When a validator receives a packet, it checks the Merkle proof against the signed root. If the proof matches, the validator can be

[10/17] RaptorCast solves this with Merkle trees. Instead of signing every packet, the leader groups packets into sets. For each set, it builds a Merkle tree and signs only the root. Each packet then carries its Merkle proof along with the signed root. With this method, one

[9/17] If every packet had to be signed individually, the leader would need thousands of signatures, which is highly inefficient and computationally expensive. This would make the leader a bottleneck again, exactly what RaptorCast is designed to avoid.

[8/17] Erasure codes already solve problems 1 and 2, but the authentication problem remains. Networks cannot send a full block as a single message. Data must be broken into packets, usually around 1500 bytes each. A 3 MB block therefore requires about 2000 packets, and with

[7/17] Next, the final ingredient of RaptorCast: ensuring message integrity. To make broadcasting fast, RaptorCast uses UDP instead of TCP. UDP is lightweight and fast, but it comes with tradeoffs: 1. No guarantee of delivery 2. Packets can be lost or arrive out of order 3. No

[6/17] After splitting the block into chunks, the leader encodes them with erasure codes to add redundancy. With this, even if some messages are lost due to faulty nodes or poor connections, validators can still reconstruct the block. The redundancy factor must be carefully

[5/17] This approach looks great, but it has a critical weakness: it cannot handle message loss. If some validators go offline or packets are dropped, the block cannot be fully reconstructed. This is where erasure codes, which we introduced in Part 3, come in.

[4/17] A tree-like broadcast structure can solve this problem. The leader splits the block into smaller chunks and gives each validator a different set. Validators then forward their sets to others. As a result, the workload is distributed across all validators. The upload cost

[3/17] In the previous part, we saw how naive block propagation leads to an unscalable system. The leader becomes the bottleneck because its upload bandwidth grows linearly with the number of validators in the network.

[2/17] As always, if you want the full deep dive, check the article: 📚 https://t.co/9AxUeoJxPo 📚 https://t.co/bS7IOX7j45 If you prefer a simplified breakdown you can quickly absorb, just keep reading. 👇

[1/17] Welcome back to the Monad Series Part 4! In Part 3, we explored erasure codes, what they are used for, and gained a rough idea of Raptor codes by looking at LT codes. In this final part, we focus on RaptorCast. It uses erasure codes to ensure a high probability of