# Native Decracy P2P Layer

## Goal:

Acheive a high-performant, encypted p2p layer with QUIC protocol as a base which would be tailored to fit the needs of the Decracy Network

### Why choose QUIC over other protocols:

- QUIC (Quick UDP Internet Connections) is a specification initially penned at Google and later accepted widely with IETF.
- QUIC is an implementation on top of UDP, which makes it overcome many of the problems with the traditional protocols. Also has encryption with built-in TLS certificates, so encryption is free.
- While QUIC is a living standard (in the sense that it is not finalised), it was adopted by the IETF in 2016. The standardisation of this provides added credibility for Decracy newcomers.
- There are many other benefits (such as prevention of IP spoofing, stateless retries etc.) that QUIC brings with it. Being a modern protocol, the specification has considered the shortfalls of the existing mechanisms studied over decades and addressed those issues in QUIC. And even better, would be one of the very few to actively use this protocol.
- It’s a fully-formed, single protocol so there is no requirement for any additional protocol engineering.
- As it has been adopted by the IETF the standard may evolve over time, although any future changes won’t affect the functionality that it already has today that we’ll be relying on. Plus our ambition is to get to full launch as speedily as possible which means we’re more than happy to utilise existing solutions. This is open development and open source at it's best.
- QUIC is also fast, can setup connections cheaper than TCP and can accept hole punched (UDP) sockets.

#### Levels of Encryption: TCP vs QUIC

### Implementation details:

- We would be using [quinn](https://github.com/djc/quinn#quinn) as the base crate that implements the QUIC protocol.
- All our APIs will be wrappers on top of quinn's API to connect to the network.
- The cherry on top is that the quinn architecture is a totally async in nature with tokio runtime. Therefore we would need to support that and not suppress the feature that comes with the base package
- It would be nice to research into async/await terrain of rust and have our p2p crate implement the latest and most efficient of the what Rust can give us.
- IGD and NAT Traversal will be required in later stages of development to support running the network globally.(Many routers do not have the facility to suport UPnP, therefore igd would be required when we roll-out)
- Have bootstrap cache implemented with an LRU right from the start as it makes life easier and clearer to proceed in the future.
- A Config pattern must be used setup a network connection rather than a Builder pattern.

### Functional requirement details(Not wholistic):

#### All the functionalities(except bootstrap) has to be agnostic of the Application Layer above
1. We would want two nodes to `bootstrap to the network via hard_coded contacts
2. We would want to `verify` that we have joned the right network
3. We would want the two nodes to `connect_to` each other or validator. (it has to be agnostic of the Application Layer above)
4. Have a `list of nodes` that we frequently connect_to/being other validators.
5. Finally `send` messages to the network that the validators would process
6. `disconnect` to gracefully exit out of a connection or the network itself.

Research papers to look into:
-
1. Flash routing - https://arxiv.org/pdf/1902.05260.pdf
- Speaks extensively on offchain transactions. Must check to see if we can incorporate this into our systems as we can easily setup validators to hold the network's accounts on which transactions happen.
2. BCR routing - https://www.hindawi.com/journals/wcmc/2018/4029591/
- A routing model originally devised for IoT devices with no central authority(CA) to communicate and route using smart contracts. Resilient to Blackhole problems. Check to see the efficienc(Largely depends on the smartcontracts security and efficiency level).
3. Routing Path-Based Transactions - https://arxiv.org/pdf/1709.05748.pdf
- If are considering to look into having a Offchain transaction, this would an important paper to look into.

4. S/Kademilia - https://ieeexplore.ieee.org/document/4447808
- A key-based routing protocol based on Vanilla Kademilia routing. Overcomes multiple problems/attacks due to it's cryptographic properties. Might be exactly the one we are looking for. Give more reading time and thoughts into this.