bft-crdt-experiment/README.md

# BFT-CRDT PoC

This is a proof of concept implementation of a [BFT-CRDT](https://jzhao.xyz/posts/bft-json-crdt) system.

This code is based on the ideas of [Martin Kleppmann](https://martin.kleppmann.com/papers/bft-crdt-papoc22.pdf) and the ideas and code of [Jacky Zhao](https://jzhao.xyz/). Have a read, they are both excellent writers and have some of the most interesting computing ideas I've run across in quite a while.

It is not clear what this thing is for, yet. It's not a blockchain. It makes a kind of secure DAG. It uses BFT-CRDTs to make a Sybil-proof and secure information transmission system for messages, with eventual consistency guarantees.

Initially I was thinking it could perhaps be used to make a kind of opt-in blockchain, but I don't think it'll work (and reading up on things like e.g. vector clocks, which I had initially thought about for ordering, the literature goes out of its way to note that they can't work in Byzantine environments).

So if it can't be a blockchain, what can it be? Is it useful at all?

Potentially, yes. There are lots of things in crypto land which do not necessarily need consensus and/or a Total Global Ordering. Some brainstormed ideas for these are in the `docs/` folder.

## Prerequisites

Install a recent version of Rust.

## Running in development

Run the watcher first:

```bash
cd crdt-relayer
cargo watch -x run
```

To init a Side node:

```bash
cd crdt-node
cargo run -- init node1
cargo run -- init node2
cargo run -- init node3
cargo run -- init node4
```

To start a node with a cargo watch for development purposes (from the `crdt-node` dir), open up a few terminals and run:

```bash
cargo watch -x "run -- run -- node1"
cargo watch -x "run -- run -- node2"
cargo watch -x "run -- run -- node3"
cargo watch -x "run -- run -- node4"
```
You can then type directly into each of the Crdt Node consoles. Messages will be relayed to each Crdt Node, and the transaction history will end up being the same on all nodes.

## Discussion

What we have here is a very simple system comprised of two parts: the Crdt Node, and the Crdt Relayer.

It is pretty cool in the sense that it is actually Sybil-proof. But you can't get a Total Global Ordering out of it, so you can't use it for e.g. account transfers in a blockchain.

However, there may be other cases that

### Crdt Node(s)

The Crdt Nodes make up a system of BFT-CRDT-producing nodes that can make a sort of wildly insecure blockchain. Currently, they can reliably send transactions to each other in a secure way, such that all nodes they communicate with can tell whether received transactions are obeying the rules of the system.

The Crdt Node does not download any chain state, and if one goes off-line it will miss transactions. This is expected at the moment and fairly easy to fix, with a bit of work.

### Crdt Relayer

The Crdt Relayer replicates transactions between nodes using a websocket. We aim to eliminate this component from the architecture, but for the moment it simplifies networking while we experiment with higher-value concepts.

Later, we will aim to remove the Crdt Relayer from the architecture, by (a) moving to pure P2P transactions between Crdt Nodes

## Possible uses

### DKG

It strikes me that there are many, many systems which rely on a trusted setup, and which might be able to use Distributed Key Generation (DKG) instead. SNARK systems for instance all have this problem. Could BFT-CRDTs help here?

It is not necessarily the case that e.g. signer participants and Cosmos validators are the same entities. Being able to quickly spin up a blockchain and use it to sign (potentially temporary or ephemeral) keyshare data might be pretty useful.

### Cross chain transfers

Might the ability to be part of multiple consensus groups at once provide new opportunities for cross-chain transfers?

### Others

There are some brainstormed ideas in `docs/` and `examples/` as well as an ai-generated example in `crates/oracle-demo`. Have a look.

## Next dev tasks:

- [ ] pick a commit and reveal scheme to remove MEV. One thing to investigate is [single-use seals](https://docs.rgb.info/distributed-computing-concepts/single-use-seals)
- [ ] enable Crdt Nodes should download current P2P dag state so that they start out with a consistent copy of dag data, and also do catch-up after going off-line
- [ ] remove the proc macro code from bft-json-crdt, it's not really needed in this implementation
- [ ] switch to full P2P messaging instead of websockets