grimadas
commented
2 months ago Main idea of `rapprochement':
- It is a synchronisation protocol, that allows peers to quickly synchronise (any?) data in a peer-to-peer network.
- Goals: data convergence, gossip and accountability (detection of policy violations)
- A collection of synchronisation primitives specifically designed for Byzantine-resilience, unreliability of peer-to-peer networks.
We start with the simplest primitives and see if we need more. Ideally we would like to see a very simple and clean API.
Stage 1: Key-value Synchronisation
Use-case: Distribute the MeritRank scores in the network. Each score is a tuple: (key, value, version).
keyis composite, it is an id of the edge (entity A, entity B) - opinion of A on B.value- is some numericalversion- is a number that is always increasing. You store only the latest version of the edge.
The goal is to eventually synchronise the Key-Value Database between peers, and benchmark what approach is best with bandwidth/throughput, latency (convergence), latency (average specific edge update).
Design Hypothesis 1.
Use modified RIBLT to support key-value-version.
Baseline solution:
- Use gossip from iron-gossip
- Record average latency (is present in iron-quinn implementation)
- gossip local new scores to the network
- Build meritrank graph
- Report rankings
The Rapprochement protocol is the networked version of MeritRank. The first application is an experimental network of peers that measures round-trip times to other peers and connects to those with the best uptimes and lowest RTT.
RTT service architecture
The architecture of this service will become the blueprint for other services (NAT puncturing, P2P data storage, etc.) that we will build later. The service should be embeddable at mobile platforms, so it should be written in Rust, sans-io style.
Networking layer
Rapprochement-RTT ("RT2") will use the Iroh networking library for peer-to-peer connections.
Persistent storage
RocksDB or some other high-performance embeddable key-value storage
MeritRank
We will use our MeritRank Rust library. This will require extracting some functions from MeritRank-service-rust to support asynchronous execution, etc.
Signatures and peer identification
Hosts are identified by public keys. Every key-value-version tuple is signed by the host that created it. This enables 3rd-party-based replication and state dissemination
Key-value reconciliation
RIBLT protocol. Note that reconciling versioned key-value pairs will sometimes require exchanging duplicates. Peers will exchange versioned and signed edges of the "opinions" graph.
Every peer exchanges all the key-value-version tuples with its peers.
Connectivity logic
(Eventually, we should implement a more sophisticated algorithm for decentralized peer shuffle for the stochastic part, e.g. PeerSwap)
Peer exchange
Periodically, a node asks its current peers to "introduce" it to other random peers from the pool (public key + IP + port).
Simulation
The initial version should be developed sans io and provide Python bindings so we can run simulations in Jupyter Notebook