From 79ce80a4a45d3fbdfcf154a4d31b739949cc5df4 Mon Sep 17 00:00:00 2001 From: Dave Date: Thu, 12 Jun 2025 16:01:10 -0400 Subject: [PATCH] Removed the blockchain ambitions from the README. --- README.md | 28 +++++++++++++++++----------- 1 file changed, 17 insertions(+), 11 deletions(-) diff --git a/README.md b/README.md index 5c13142..91ef491 100644 --- a/README.md +++ b/README.md @@ -1,12 +1,16 @@ # BFT-CRDT PoC -This is a proof of concept implementation of a [BFT-CRDT](https://jzhao.xyz/posts/bft-json-crdt) blockchain-like system. It is willfully, wildly insecure as a blockchain right now. Think of it as an experiment which is strictly for fun and poking at ideas. +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. -The idea that it could be possible to set up a secure Sybil-proof system, negating the energy burn required for proof of work, the financially exclusionary proof of stake, or the meat space hassle of a proof of personhood ceremony, is too attractive to ignore. At least, if you're interested in cool P2P systems. +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 @@ -45,6 +49,10 @@ You can then type directly into each of the Crdt Node consoles. Messages will be 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. @@ -53,9 +61,9 @@ The Crdt Node does not download any chain state, and if one goes off-line it wil ### 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 and consensus agreement while we experiment with higher-value concepts. +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, and (b) doing leader election of a Crdt Node to reach agreement on the submitted block. +Later, we will aim to remove the Crdt Relayer from the architecture, by (a) moving to pure P2P transactions between Crdt Nodes ## Possible uses @@ -69,15 +77,13 @@ It is not necessarily the case that e.g. signer participants and Cosmos validato 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: -- [ ] 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](https://docs.rgb.info/distributed-computing-concepts/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 +- [ ] 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 -- [ ] 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