godave

 ____                      
|  _ \  __ ___   _____  
| | | |/ _` \ \ / / _ \ 
| |_| | (_| |\ V /  __/
|____/ \__,_| \_/ \___|
Anonymised continuous packet sharing peer-to-peer network protocol.

Dave is an open protocol designed to simply, efficiently, and continuously distribute a hash table in a byzantine environment. Applications such as serverless contact forms and social media applications could built on this interoperable protocol that quickly and reliably disseminates information.

Packets of data currently up to 1500 bytes in length are continuously pushed and pulled via a set of operations executed at random. We call these packets "dats".

Storage is prioritised according to the age and difficulty of the proof-of-work. We call this "mass".

An amount of trust equal to the mass of a dat is earned by sending a dat not already in the remote's hash table. Trust is used to modify the probability of a peer being randomly selected for a small subset of operations, such as seeding and pushes. Trust values are not gossiped or weighed into peer sharing.



1.      Configurable Settings

Listen      UDP listen ip-port address.
Edges       A slice of edge node ip-port addresses.
DatCap      Number of dats to store. Adjust for available memory.
FilterCap   Capacity of cuckoo filter. 10K or 100K should be fine.
Prune       Number of epochs between refreshing maps. 100K is probably goodu
Log         A string channel for sending log messages.



2.      Message Operation Codes

GETPEER     Packet containing only the op-code. Remote should reply with NPEER random peer descriptors.
PEER        Packet containing NPEER peer descriptors.
DAT         Packet containing a value, time, and output of the cost function: work, salt.
GET         Packet containing the work hash, remote should reply with a message of op-code DAT, if available.



3.      Binary Serialisation

A message is serialized into binary using protobuf.

Transpiling Protobuf Spec for Go:
#!/bin/bash
protoc --go_out=. dave.proto

FIELD       DESCRIPTION                                 BYTE LENGTH

OP          Operation code.                             1
PEERS       List of peers.                              20*NPEER
VAL         The data.                                   0 | <= 1388 when NPEER=2
TIME        Little-endian unix milliseconds.            0 | 8
SALT        Random bytes used to solve WORK.            0 | 32
WORK        BLAKE2B256(SALT, BLAKE2B256(VAL, TIME)).    0 | 32



4.      Packet Filter

Dropping packets efficiently is critical for resilience to DoS attack. Cuckoo filters leverage cuckoo hashing to efficiently store fingerprints in a compact hash table, enabling constant-time insertions and lookups. This makes them well-suited for this application. Packets that deviate from the protocol are detected & dropped without further processing.

The key inserted uniquely into the filter:

FNV64A(OP, HASH4(REMOTE_PORT), REMOTE_IP)

Failing unique insertion, the packet is dropped. The filter is reset every epoch, therefore each op-code may be sent once per ip-port per epoch. The number of ports allowed per ip address is limited using a 4-bit multiply-then-shift hash function.



5.      Peer Discovery & Liveness

The protocol ensures a cohesive network by combining liveness and peer discovery into a single pair of direct messages (GETPEER & PEER). A node replies to a GETPEER message with a PEER message with up to NPEER peer descriptors.



6.      Mass

MASS = DIFFICULTY * (1 / AGE_MILLISECONDS)

Where DIFFICULTY is the number of leading zero bytes in WORK, amd AGE_MILLISECONDS is calculated from message TIME and current time.



7.      Replacement by Mass

Every PRUNE EPOCH, a user defined (DatCap) number of most massive dats are kept, and the remaining dropped.



8.      Random Push 

Every SEED/NPEER EPOCH, each node sends one random dat to one random peer, excluding edges. This ensures reliable distribution and sender anonymitiy.

Propagating dats in this way ensures that an adversary is unable to create a timing-attack to discern the source of a dat, even with a broad view of network traffic.

Note: In the current implementation, messages are sent from the main routine and we have not yet finished ensuring resistance to timing attack when sending new dats.



9.      Random Pull

Every PULL/NPEER EPOCH, a message is sent with op-code GET, and a randomly selected work hash already known. This further improves anonymity, at the cost of bandwidth.