gbl08ma.com / didplcbft
A very experimental PLC implementation which uses BFT consensus for decentralization
fork atom

Continue improving README

gbl08ma.com e612e8d6 7bce97e5

verified
+16 -5
unified split
+16 -5
README.md
··· 17 17 It is safe to assume that a network of didplcbft nodes is not becoming the official PLC implementation any time soon (and probably never), so one may wonder: why bother? Even in an initial phase where it is non-authoritative, didplcbft can prove useful: 18 18 19 19 - For AT Protocol service operators and researchers, the hope is that didplcbft can be a sufficiently efficient local replica of the centralized PLC directory. This can be useful for applications with a high volume of read queries, where any latency and reliability issues associated with accessing a more "distant" internet service become a concern. 20 - - For AT Protocol users who may not necessarily want to trust the data provided by the official plc.directory at face value, didplcbft can, through its deterministic and consensus-backed state transitions, can offer a more auditable history of events. In a sense, it can help "keep plc.directory in check." This is somewhat similar to what initiatives like [plcbundle](https://tangled.org/atscan.net/plcbundle) offered, but didplcbft is more ambitious in that it tries to be a path towards full decentralization of the directory, including for write operations, rather than being a mere read-only replica. 21 - - From a R&D point of view, it can help with understanding whether a blockchain-based approach can deal with the transactional volume of plc.directory without introducing excessive overhead or reliability issues, when compared to a centralized solution. 20 + - For AT Protocol users who may not necessarily want to trust the data provided by the official plc.directory at face value, didplcbft can offer a possibly more trustworthy record of changes, through its deterministic and consensus-backed state transitions. In a sense, it can help "keep plc.directory in check." This is somewhat similar to what initiatives like [plcbundle](https://tangled.org/atscan.net/plcbundle) offered, but didplcbft is more ambitious in that it tries to be a path towards full decentralization of the directory, including the creation of PLC operations, rather than being a mere read-only replica. 21 + - From a R&D point of view, it is a research artifact into whether a blockchain-based approach can deal with the transactional volume of plc.directory, without introducing excessive overhead or reliability issues, when compared to a centralized solution. 22 22 23 23 In a hypothetical future where AT Protocol stewardship decides that didplcbft should become the effective PLC implementation, meaning that the didplcbft network becomes the authoritative source of PLC data, it could offer some benefits over the current centralized approach, most of which are common to many blockchain implementations: 24 24 ··· 29 29 - With transparency around the transitions that led to the current state 30 30 - Looking very far into the future, interoperability between different node implementations could help highlight/avoid certain classes of bugs 31 31 32 - **Isn't did:web the answer to decentralizing identities?** 32 + #### Isn't did:web the answer to decentralizing identities? 33 + 34 + did:web is certainly a valid option for participating in ATProto without depending on the plc.directory. However, did:plc was developed precisely because did:web presented usability and scalability limitations in the context of ATProto. did:web probably "isn't for everyone;" it presents trade-offs too. We believe that the choice for decentralized identifier methods should not be between "dependent on DNS but independent from [single organization]" and "self-authenticating but dependent on [organization]." A decentralized identifier for one's (social) identity/ies feels like something that is too fundamental to be heavily dependent on what is essentially a different form of identifier (a DNS name), particularly when DNS at the internet level is ultimately controlled by the root zone administrators, or in more practical terms, the administrators of each TLD (which very much feels like a "pick your poison" type of scenario). 35 + 36 + There is also the more practical argument that, between did:web and did:plc, the latter is the one that has millions of active users - regardless of whether we like this situation or the path that led to it. It would certainly be nice if all of those identities could be preserved in a decentralized way, without the identities themselves changing to a different method. 37 + 38 + We are aware that did:web will keep evolving, and it could even get to a point where it no longer strictly depends on DNS, for example. However, this is not a battle where there can only be one winner. 39 + did:plc definitely has its merits, and to further improve its chance of long-term success, ideally even beyond ATProto, we believe that sooner or later a concrete path to the decentralization of the PLC must be developed. We are trying to work on precisely that. 40 + 41 + #### Wouldn't a blockchain-based approach be something that warrants its own DID method, rather than piggybacking on did:plc? 42 + 43 + We could definitely see our work being the basis for a new, independent identifier method, e.g. "did:blc"/"did:dlc"/[insert even funnier three letter combo here], which could largely keep did:plc's semantics while being internally based on distributed consensus. However, it seemed much more appealing to build a system that can act as a drop-in replacement for the centralized service in certain roles, a system that can resolve real identifiers that already exist right now, instead of a system which would forever wait for user (and service) adoption to be minimally relevant. 33 44 34 - did:web is certainly a valid option to be able to participate in ATProto without depending on the plc.directory. However, all the reasons that led to the development of did:plc remain valid. To summarize, did:web probably "isn't for everyone;" it presents trade-offs too (e.g. dependency on DNS). We are aware that did:web too will keep evolving, but as the name implies, it will always be connected to "web" technologies in some capacity (once again, DNS comes to mind) and this might be enough to disqualify it from some use cases. did:plc definitely has its merits, and to further improve its chance of long-term success, ideally even beyond ATProto, we believe that sooner or later a concrete path to the decentralization of the PLC must be developed. We are trying to work on precisely that. 45 + We doubt that convincing the ATProto ecosystem to support a different DID method would be easy. Nobody would want to run a node for a DID method used by just a few dozen people, therefore, it would never be a truly decentralized network - the incentives just wouldn't be there. Offering a more gradual path towards decentralization that can keep existing identifiers working without their owners having to do anything seems more realistic, with the benefit that, if didplcbft gets to a point where it can be used "in production" as a mirror of plc.directory, and gains some user adoption due to that, then the hard work (of having _real world adoption_ and _a truly decentralized network_) will be basically done. 35 46 36 47 ## Features 37 48 ··· 71 82 72 83 ## Technical notes 73 84 74 - - Consensus-backed data is stored in an [IAVL+ tree]((https://pkg.go.dev/github.com/cosmos/iavl)), which can cryptographically prove and disprove the presence of specific leaves. 85 + - Consensus-backed data is stored in an [IAVL+ tree](https://pkg.go.dev/github.com/cosmos/iavl), which can cryptographically prove and disprove the presence of specific leaves. 75 86 - This tree and some non-consensus-backed auxiliary/derived data live in a couple [badger](https://github.com/dgraph-io/badger) key-value stores, using settings specifically tuned for the use cases at hand. 76 87 - The PLC HTTP API reads the IAVL+ tree directly for read operations, and submits write operations as blockchain transactions. 77 88 - The current implementation of the "proofs of useful storage" involves zkSNARK proofs, mostly as the means to attain a "bounded proof of work" mechanism, where proofs require some effort to produce, but can be verified instantly. By "bounded proof of work" we mean that honest nodes don't gain anything from throwing more resources at the system (so it shouldn't devolve into an arms race like Bitcoin's proof of work), and dishonest nodes attempting a Sybil attack will need to spend as many compute resources to operate each Sybil identity, as a single honest node would have to spend operating its own honest identity.