ChainSafe / das-prototype

Research prototypes of Data Availability Sampling for Ethereum (WIP)

Home Page:https://hackmd.io/@timofey/SyqzhA4vo

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Iterative dissemination

nulltea opened this issue · comments

Summary

  • current dissemination strategies are recursive, this one is the alternative to them
  • overview: originator asks the closest known peers it whether they know closer ones to the given keys, if they don’t originator sends them samples to store, otherwise originator keeps asking peers it receives until it reaches the closest known ones
  • it should be trivial to do using a custom protocol over TALK_REQ, no need to change Discv5 or OverlayProtocol logic

Specification

  1. originator groups samples by known closest peers using the bucket-wise or distance-wise strategy, and sends batches of keys as KEYS(Vec<SampleKey>) to individual nodes
  2. for each received key node checks if it knows nodes who are closer to that key, if it finds such nodes it responds with CLOSER_NODES(SampleKey, Vec<Enr>), otherwise with STORE(SampleKey) (these can be grouped as STORE(Vec<SampleKey>) but UDP packet size limitation should be considered or use uTP instead).
  3. for each STORE response, the originator sends SAMPLES(Vec<SampleValue>)
  4. for each CLOSER_NODES response, the originator repeats the first step including newly discovered peers.
  5. dissemination finishes when all samples are passed to the closest discovered nodes

Response approaches:

  • FullResponse {strore: Vec<SampleValue>, closer_enrs: Vec<Enr>} - send values for all elements in store; apply all enrs to batching (how?)
  • series of (index, total, CLOSER_NODES(SampleKey, Vec<Enr>) | STORE(Vec<SampleKey>))
  • series of (index, total, CLOSER_NODES(SampleKey, Vec<Enr>) | STORE(Vec<SampleKey>))
  • OptimizedResponse(Vec<Enr>) - based on received Enrs and remote node_id, originator figures out which values to send and which keys continue to search

Benchmarks (256 keys, 800 nodes, no redundancies):

  • with Libp2p: time.busy:18.5µs time.idle:760ms
    • communication overhead = 920 messages
    • storage overhead = 256 keys
  • with Discv5: time.busy:19.5µs time.idle:6.21s
    • communication overhead = 996 messages
    • storage overhead = 256 keys