Side BFT-CRDT PoC

This is a proof of concept implementation of a BFT-CRDT blockchain system.

Prerequisites

Install a recent version of Rust.

Running in development

Run the watcher first:

cd crdt-relayer
cargo watch -x run

To init a Side node:

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:

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 key parts: the Crdt Node, and the Crdt Relayer.

Side 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.

Next dev tasks:

we don't need a relayer, the first crdt node can act as a leader until people decide they don't want to trust it any more
the leader node can have a timer in it for block creation
code up the ability to switch leaders (can be a human decision at first, later an (optional) automated choice)
pick a commit and reveal scheme to remove MEV. One thing to investigate is single-use seals
enable Crdt Nodes should download current P2P chain/dag state so that they start - out with a consistent copy of transaction 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
add smart contract execution engine (CosmWasm would be a good first choice)
enable Crdt Nodes to download contract code for a given contract
enable Crdt Nodes to download current contract state for a given contract
switch to full P2P messaging instead of websockets

Crdt Relayer

The Crdt Relayer is a simple relayer node that sits between a Cosmos chain and the decentralized Crdt Nodes. At the moment, it simply relays transactions between nodes via a websocket. We aim to eliminate this component from the architecture, but for the moment it simplifies networking and consensus agreement while we experiment with higher-value concepts.

In future, the Crdt Relayer needs to:

make a block for the BFT-CRDT chain when the Cosmos chain creates a block
submit BFT-CRDT chain data to the Cosmos chain

Later, we will aim to remove the Crdt Relayer from the architecture, by (a) moving to pure P2P transactions between Crdt Nodes, and (b) doing leader election of a Crdt Node to reach agreement on the submitted block.

Bitcoin integration

There is a Bitcoin client integrated into the node, which can do simple coin transfers using esplora and the Mutinynet server's Signet (30 second blocktime).

The client's demo driver can be run by doing:

cargo run -- init dave
cargo run -- init sammy
cargo run -- btc

You'll need to have funded the "dave" address prior to running the btc command - otherwise the transfer will fail gracefully.

I was using this primarily as a way to experiment with constructing and broadcasting Bitcoin transactions, with the hope that it would be possible to move on to more advanced constructions (e.g. state channels). However, now that I look at all the options, it seems that multi-party state channels in Bitcoin are (probably) impossible to construct.

There is a second, unused Bitcoin client in place which uses Blockstream's Electrum server, but this didn't seem to be working properly with respect to Signet Bitcoin network during my testing, so I went with the esplora / Mutiny version instead.

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 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?

4.9 KiB Raw Blame History