A very experimental PLC implementation which uses BFT consensus for decentralization
Update README to better reflect project status
+3
-3
+3
-3
README.md
+3
-3
README.md
···
54
54
- didplcbft is already able to work as a decentralized, standard-compliant PLC implementation, independently from plc.directory
55
55
- Supports **Websocket-based Export** equivalent to that of the official plc.directory service (described [here](https://github.com/did-method-plc/did-method-plc/pull/129)).
56
56
- **Validation:** On-chain validation of PLC operations to ensure history integrity.
57
+
- **Authoritative Mirroring:** An "authoritative import" mechanism to pull historical data from the official plc.directory.
57
58
- **Node-to node fast syncing:** Support for snapshot-based sync, to quickly bring new replicas online, making use of the facilities offered by CometBFT.
58
59
- A custom compact serialization format is used, able to archive/transmit the entire directory using around 30 GB of space/data transfer as of January 2026.
59
60
60
61
### In progress
61
62
62
-
- **Authoritative Mirroring:** (mostly functional, needs adjustments): An "authoritative import" mechanism to pull historical data from the official plc.directory.
63
-
- **Reputation System:** A "proof of useful storage" system where nodes submit periodic proofs to maintain validator status.
63
+
- **Reputation System:** (mostly ready, pending validation) A "proof of useful storage" system where nodes submit periodic proofs to maintain validator status.
64
64
- Due to the way CometBFT works, it is ideal if there is a limit to how many nodes perform validator duties. The reputation system is meant to select, over time, the "best" nodes for this task, and manage their "voting power."
65
65
- The reputation system will have some resistance against Sybil attacks - a single entity operating N identities should not be able to get away with putting in less effort than that of N different honest entities combined.
66
+
- **Dynamic Validator Sets:** (mostly ready, pending validation) automatic management of which nodes perform validator duties based on their reputation.
66
67
67
68
### Planned
68
69
69
70
- **Bi-directional Sync:** submitting operations observed on the didplcbft network back to the official plc.directory, while still deferring to operations served by the latter in case of conflict.
70
71
- **Spam Prevention:** developing a non-currency-based throttling mechanism.
71
72
- For example, by gossipping hashes of IP addresses and AS numbers across the network in order to limit how quickly spammers can create new identities in the PLC. The challenge is that certain entities (e.g. Bluesky's own official PDSs) will naturally need to create many more identities than others... maybe some sort of allowlisting mechanism would need to be implemented.
72
-
- **Dynamic Validator Sets:** automatic management of which nodes perform validator duties based on their reputation.
73
73
- **Public Testnet:** moving from local clusters to a distributed internet-based environment.
74
74
- Not really a feature, but more of a cross-cutting aspect: proper test coverage (will probably require refactoring the code first to better separate concerns), and perhaps some proper specs around how the proofs and reputation system work.
75
75