Summary DAS Networking in Ethereum requires lots of small blob samples to be placed in a distributed network where arbitrary nodes can query "the network" to make sure these samples are available. What this "network" actually looks like is still an open question, but there seems to be high level consensus on its process and design: Initial Dissemination - Builder sends rows and columns to validators via gossipsub-like protocol (unstructured network) Continued Dissemination - Validators distribute samples to rest of network via Kademlia-style DHT(structured network) Querying DHT for samples - Sampling nodes ask DHT for individual samples Reconstruction - If there's a liveness failure within the network and there are enough individual samples held amongst participants, participants send samples to at least one honest validator (or full node?) to reconstruct (and begin redistribution?) of the blob.

This is a living document of my favorite Data Availability Sampling resources.   DAS These resources answer the "what" and "why" behind data availability sampling. Vitalik's DAS Proposal (Old) Vitalik's DAS Proposal (New) Ethereum's Data Availability - Introductory post Dankrad's post on Data Availability Checks

Before we get to the normal Dev Update... Over the past 4 months I dove deep into Danksharding, Ethereum Networking, and then p2p networking in rust + building out a discv5 overlay simulation. A few days back, I read a few "big-picture" Ethereum developer documents: Network Layer and Data Availability. Somewhere along the journey I lost the thread. I was building this Data Availability Sampling p2p network simulation without understanding the "why" behind it all.  

Tackling the DAS Networking problem requires a p2p network that has low-latency, is privacy preserving and is sybil-resistant. The idea behind Model DAS is to measure benchmarks on DAS querying via Secure Kademlia DHT Discv5 overlay network. This Secure K-DHT is a seperate validator-only overlay network that leverages validators' incentive alignment to create a robust DAS network if the primary network were to come under attack. Status Report The original vision for Model DAS didn't entail creating a new DAS simulation; the idea was just to extend the functionality of another. But seeing that I was new to gerenal networking concepts and the Rust programming language, it quickly became aparent that building a simplified version of DAS Prototype was an escential prerequisite to executing the vision behind Model DAS. Finished

Within this document I talk about specific concepts within DAS-Playground.   Motivation Required Reading: What is Danksharding? A TLDR on Required Reading: Ethereum's rollup-centric roadmap requires extra blob data to be placed on chain. The more blob data that can be placed on chain, the more Ethereum can scale. But... Extra data = extra cost to run a node = reduced decentralization =    : (

For a p2p network to exist, nodes need to be able to communicate (make requests and respond to one another). Remember: Each node is a client and server at the same time! Message processing implements the server-side logic needed for a node to respond to another node's request. Since my previous update I've set up some custom message processing for discv5 + overlay events within DAS Playground, have been digging into implementing message processing to support multiple overlay subnetworks, and continued writing within Summary of DAS Playground.   Overlay Message Processing Message processing allows the server side of our DASNodes to filter through the different possible message requests (services) it provides and responds to requesters appropriately.

In the previous update I mentioned creating a repository, DAS-Playground, built to facilitate the understanding of Ethereum p2p networking concepts. This repository has been my primary focus over the past two weeks. I've also been working on a summary of the entire repository where I explain the p2p networking concepts that are being implemented. You can check out the summary of DAS Playground here!   TLDR To model a future DAS networking design, you need to create the network(s) that Ethereum nodes would use to communicate. The networking stack that makes up a secure K-DHT overlay consists of three two major protocols:

It's been a long time since the last update. Well friends, I'm back!A lot has been happening behind the scenes... I dove into the DAS-Prototype codebase Created DAS-Playground Run DAS-Prototype on my local machine Friendly reminder: DAS-Prototype is a repository that Eric and Timofey have built to test possible DAS networking solutions. I'm modeling one of these possible solutions.  

This past week I put my project proposal out into the world and went deep into learning Rust. Project Things I threw my project proposal on Twitter and Eth R&D's DAS Channel, presented the proposal during office hours, and sent my proposal to Dankrad. There were no bites on feedback within the DAS channel, but Dankrad gave advice on expanding upon some of my bullet points within the project's roadmap and benchmarks. Timofey expressed interest in seeing how the S/Kademlia would affect performance within their simulations, giving a thumbs up on creating a tightly coupled project with DAS Prototype. Side Note

Ideas within this document are subject to change upon feedback from peers and mentors. Model-DAS is a Rust implementation of a Secure Kademlia DHT overlay atop the discv5 protocol, modeling one possible solution to DAS networking. Motivation Full-scale Danksharding requires a lot of small pieces of data (samples), and attestations to said data, to be communicated efficiently across a large peer to peer network. There are a few ideas for how peers should communicate about data availability within Danksharding, but nothing has been set in stone. Model-DAS aims to provide insight into one of these possible DAS networking solutions. "In an ideal world we have a low-latency DHT that is also sybil-resistant. Doing all of this is an open research question." - Alex Stokes

This past Tuesday I met with Eric and Timofey of Chainsafe's DAS R&D. I told them about my idea to create a Secure Kademlia DHT on top of discv5, building upon Proto's old dv5das repo. They then told me about their current project, das-prototype. We are all trying to prototype and benchmark possible networking solutions for data availability sampling. Meeting Summary Eric warned about building on top of Proto's old repository and said that his repo was a great place to understand concepts, but to not necessarily base my project off of Proto's. They'd previously tried to do the same, but Go's major p2p benchmarking platform was designed specifically to integrate with libp2p network models (not discv5) and Proto's repository had been abandonded.

This week I got more context of Ethereum's networking specs, continued learning Go, and have gotten in touch with Alex and Dankrad about my project idea. Also will be meeting with Eric Tu, DAS researcher/dev for Chainsafe, on Tuesday! Research and Development Forked Proto's dv5das repo Read through Geth's p2p modules Read consensus p2p networking specifications. Refining project proposal and sending it into data availability sampling channel within the next few days Mentor Things

Once proposal is merged into Cohort 3's projects directory, move link there Project Proposal - Model DAS Update For the Fellowship, I originally intended to continue working on Model Danksharding and implement new networking concepts within the repo. Since then, I've gone through several iterations of project ideas... Within the previous update (Update #3 v.1), I wrote about making a Secure Kademlia DHT and a blob creation, dissemination, and reconstruction script that integrates into the distributed hash table. The idea was to measure important benchmarks for preliminary DAS networking questions via some sort of peer to peer testing suite. Earlier this week, I stumbled upon Proto's dv5das repo and saw that he was basically creating exactly what I was wanting to implement (aside from making a Secure K-DHT overlay and writing the project in Python). I began questioning whether creating my own DHT from scratch, as opposed to implementing the 'Secure' part of the K-DHT on top of an already implemented discv5 DHT, was the best move.

This past week I had a vague idea of what I wanted to do: Make some sort of test suite that implemented a lot of Danksharding's core logic with respect to peer to peer networking and data availability sampling. I ran a rough draft project proposal for Model Danksharding by Cayman. He provided a ton of feedback, which has been great for refining the vision of the whole thing.   Project Summary Danksharding has a lot of questions that still need to be addressed in order for this scaling solution to become a reality- specifically with respect to the distribution of data amongst peers.

Now that the Ethereum Protocol Fellowship has kicked off, it's time to choose between which project to focus on building (see A Fork in the Road... for context). Long story short: I've decided to continue working on Model Danksharding. Danksharding is the medium to long-term scaling solution that Ethereum will implement with rollups, where computation of transactions are moved off chain, while settlement is broadcasted on chain. For more information check out Model Danksharding's readme. Creating a model of Danksharding is a big task, but I believe that taking a "breadth first" view of the project will help facilitate a great understanding of the underlying system. The idea is to oscillate between building out major functionalities within data availability sampling and peer to peer networking while stubbing complexities until subsequent rounds. The trick is to identify benchmarks for the layers of complexity.

There have been two projects that I've been focused on for the past 5 months: python-light-client and Model-Danksharding. Both projects have, and continue to, serve as fantastic opportunities to gain a much deeper understanding of Ethereum. Details for projects are inside of their respective readme files Python Light Client: I first began this journey with the protocol through the desire to build a light client, derived from learning about trustless bridges. The original goal was to create an MVP light client which tracks the current head of the Beacon chain: the updated goal is to do this via the Portal Network instead of through Lodestar's LES. After a few months of hacking, I came across two frustrating cryptography bugs: py_ecc (v2.0.0) wasn't able to run bls.FastAggVerify() on correct inputs. Upgrading to py_ecc (v6.0.0) solved the original bls bug. I was passing the sync committee signature into bls.FastAggVerify() as an SSZ encoded byte array instead of passing the signature in as bytes.