Didplcbft - a decentralized approach to did:plc

Share your project
1

I was encouraged to open a discussion about my didplcbft project here. I figure it is indeed a bit better than trying to discuss this 300 characters at a time on a mostly one-on-one basis :laughing:

didplcbft is an experimental PLC implementation. It is built on top of CometBFT: uses BFT consensus to decentralize the hosting and maintenance of did:plc credentials. I would recommend that you read the README that is on the project in Tangled so I don’t have to repeat myself too much here.

didplcbft uses blockchain technology, but it purposefully avoids building on top of any existing cryptocurrency network, or being a cryptocurrency itself. This limits the options for how to implement certain aspects and prevent certain types of attacks, but it should avoid many regulatory concerns. This is a positive in my book: I am not a lawyer but I am a software engineer, so I definitely can deal with one domain better than the other. This also immediately distinguishes it from ideas like did:fid, which intentionally pull in cryptocurrency. Finally, not bringing in cryptocurrency should outright avoid the ethical/emotional/legal problems many people have with it. The emotional problems people have with blockchain-sans-cryptocurrency are enough of a hurdle. :laughing:

I think did:web does not present a complete alternative to did:plc. I think this is sufficiently explained in the project README, but the gist of it is: did:web (in its current form at least) inherently relies on DNS. So the identities are, at best, at the mercy of some TLD authority, and at worst, if one doesn’t want to pay for a domain, delegated to a subdomain and thus at the mercy of some domain owner.

DNS is often the subject of court decisions regarding censorship, even in healthy democracies (because of blocking piracy websites and unregulated gambling websites, just to name some examples) and having AT Protocol be vulnerable to these sorts of decisions is, in my opinion, not great. I don’t want to stop being able to resolve the social media identity of some gambling website just because it is disallowed in my country, for example (and in such healthy democracies at least, that was probably not the goal of the court when they made that decision).

As to why did:plc needs to be decentralized, that’s probably one of the most debatable aspects, and I present some arguments in the readme. At a limit, I would say it is a matter of consistency: looks like everything in ATProto can be decentralized and replicated to some degree, and I don’t think the PLC should stick out like a sore thumb forever.

My approach for this project has been, and will probably continue to be for the time being, an “implementation-first” one. Sure, I am doing some research before writing code, but I definitely want to have a functional proof of concept first and foremost, perhaps even one that can be used in certain production scenarios, before overly focusing on theoreticals and politics. I am deciding to build it in the open as I usually do with my most serious side projects, but everyone should be mindful that

  1. Everything I’ve built so far is still very much in flux and unproven, and I am open to feedback and suggestions.
  2. At the same time, I am largely building this because I found it a fun thing to do, and there is a limit to how far I will “bend” my ideas and implementation; if you’re not happy about this, the Apache License 2.0 allows forking :wink: In fact, it is not completely unlikely that I will lose the motivation to continue working on this, especially if the interest others are having in this project wanes, but if that were to happen I’d definitely be happy if others took the torch from me.
4 Likes
2

Thank for sharing. As DID PLC moves into a Swiss entity, having others run it as well is important. Feels like this is going to see movement this year.

3

I’m not by any means fluent in DIDs but the readme is sounding really good. Big fan of extending plc rather than building a wholesale alternative to it.

Being operationalized as a functional plc mirror as a means to bootstrap the alt-method seems like a great way to set the stage for a prospective migration down the road while providing immediate benefit in the meantime by making the mainline directory more robust.

From a foundational point of view, didplcbft is designed to operate independently from plc.directory, such that it could eventually replace it, becoming the de facto PLC service. However, as a transitional approach, didplcbft can act as more of a mirror of an authoritative PLC implementation, namely, plc.directory.

This transitional period can last indefinitely; with didplcbft being a consensus-based distributed system, this period would last until a sufficient quorum of participants agrees that it should operate independently from the centralized directory.

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.

4

What’s the incentive to run a node? Cryptocurrencies offer a financial incentive, but this “is not and will not be a cryptocurrency”

What I’m seeing enabled here is the potential for ‘bounded decentralization’. We don’t have to solve for decentralization all the way down to the individual level, we just need to de-centralize one institution into a syndicate of institutions that’ll keep each other honest.

The existence of did:plc:bft means that, in theory, one of the first items on the agenda of the PLC association in Switzerland could be to further disintermediate itself by bringing in a small selection of other trusted institutions to participate in the ‘PLC directory syndicate’, governed by regular democratic processes more so than crypto math.

Tangentially related: Ringspace: a webrings protocol

5

There’s definitely different degrees to “decentralization.” A network made up of a mostly fixed set of validator nodes determined by off-chain processes is definitely technically possible, even with didplcbft: it’d avoid the complexity of having something at stake on chain (which in my plans would be the “reputation” one gains from being online and solving the “proofs of useful storage”). Such a system is not as “permissionless” as what I have in mind: users would be placing their trust in the “syndicate,” which I suppose is still better than placing it on a single entity, regardless of whether it is in the US, Switzerland or Lapland :santa_claus: . Such a system with a fixed validator set, is in fact how CometBFT “works out of the box” and how I’ve been testing my local setups so far.

However…

In practical terms, considering that didplcbft will likely never go past the point where it is volunteer-run, for now I will continue trying to achieve a consensus system where anyone with sufficient bandwidth and compute resources can “just show up” and contribute to the functioning of the network through those resources. Of course, “anyone” includes large companies/associations/syndicate members too.

I feel that achieving consensus via a manually-managed set of validators would be a bit of a defeat, but it’s definitely a plan B that’s on my mind, should the reputation system prove to be too complex or too vulnerable. Now that I’ve got the proofs working, I think the robustness of the reputation system will largely depend on how well designed its “economics” are (how fast entities gain reputation, how fast they lose them, what are the penalties for misbehavior, etc.), which is the next big work item I plan on tackling.

1 Like
6

Thanks for writing this up, I love this, it’s a very professional and neutral/objective way of presenting this approach, and IMHO a very defensible proposal within the universe of possible “consensus mechanism”/directory-P2P-sync technical approaches. Two points, one major and one minor.

Minor point:

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.

I think this conflates did:web and did:webvh. The latter actually exists exactly because the former is NOT evolving– it’s basically been set in stone as a stable version, with core contributors (including the editor of webvh, d zagudulin) asked to make a separate DID method rather than create a “v2”. did:web is generally seen as a “not for production” tool rather than a method for human-controlled identifiers; its usage for human-controlled identifiers was specifically discouraged by a major R&D funding program that sponsored much of the early DID work, and it was frozen and splintered in multiple competing “successors” specifically because it is used in production as-is for non-human identifier systems (like labelers) as a result of that early R&D funding. Other noteworthy successors/variants on did:web potentially relevant for ATP purposes include did:dns, did:webplus and the High Assurance DID internet-draft, proposed as an RFC with the DNSOPs WG at IETF, as it relies on DNS_SEC (note that did:webvh optionally incorporates the current draft of the latter).

Major point:
I love that this proposal assumes backwards-compatibility at both the level of all today’s individual DID:PLCs AND at the plc.directory level. Today, plc.directory is canonical and definitive; replicas are replicas, downstream copies, with discrepancies, conflicts, or omissions somewhat TBD. This proposal seems to assume a governance future where multiple directories could sync bidirectionally/P2P– which is a totally valid possibility, but one that I think needs to be decided first at the non-technical requirements/human/legal level. I think it’s awesome as R&D to prototype and benchmark and experiment but fundamentally the governance and authority of multiple directories (and the interop/obligations where they might contain conflicting data or omissions) feels to me a more fundamental question.

I have written elsewhere about did:webvh as a backwards-compatible upgrade for each of today’s existing did:plcs, and potentially a backwards-compatible approach at the directory lookup level as well, but I never got around to writing up something as thought-through as this because it feels like wasted effort until the upstream governance stuff is clearer. i don’t say “decided” because it can’t be decided in advance, but until there’s some positions staked out by northsky and/or blacksky and/or eurosky on what their requirements are for conflicting directories… it feels like we’re out on a limb projecting futures of the protocol.

2 Likes
7

I’d also note that I agree with Matheiu’s point on bsky that “reputation system” is 100% downstream of governance choices, and even naming it a “reputation system” (for deciding which nodes are authorized) kind of elides the biggest choices…

2 Likes
8

Yes, it is definitely written too loosely. It is the second time I rewrite those paragraphs and I will certainly edit them again.

did:plc resolution works as long as everyone has access to the same key-value store through some means (in printed paper distributed over mail, at a ridiculous limit), and changes to identities are applied in a verifiable way such that anyone can tell whether the transition played by the rules or not.

I like that did:plc is “flat” and quite simple to understand; did:webvh introduces trust hierarchies and generally feels more complex to me. It is definitely just a matter of personal taste, but it makes me keep coming back to “if only everyone worked on top of the same distributed database”…

”Blockchain” is brought in here as the means to achieve “everyone has access to the same key-value store” while taking advantage of “changes to identities are applied in a verifiable way such that anyone can tell whether the transition played by the rules or not.”
There are certainly other ways, but this is the one didplcbft explores.

it feels like wasted effort until the upstream governance stuff is clearer

Yes, hence why this is more a thing I am doing for fun rather than a too serious of a proposal. In the more serious and realistic sense, “This transitional period can last indefinitely” is probably what will end up happening.

reputation system

I don’t have any particular love for the “reputation system” and I slightly regret mentioning it before being able to flesh it out and validate it minimally. I see it as mostly a necessary evil that’s a consequence of the choices I made for the tech stack, given that CometBFT does require some way to “punish” misbehaving validators, when used for a permissionless network. Since CometBFT requires validators to have some voting power, and the set of validators shouldn’t be infinite (from what I’ve seen, most networks using it seem to cap the number of active validators at no more than 100), I need some way to derive that voting power. (Cryptocurrencies often put money at stake directly, but we don’t want that here.)

The issue with giving every node the same voting power is that then we can’t decide which nodes should be a validator at a given time. If I could guarantee that every person on the planet can only run one node, maybe just assigning validator roles at random, selecting a new set periodically, would be enough. The problem is that a Sybil attacker can (pretend to) run 10000 nodes and get a much higher likelihood of attaining 66% of the BFT quorum, derailing the entire thing as they please. So really, the “reputation system” is just my current WIP solution for preventing Sybil attackers from bending the rules of the blockchain in their favor.

In my mind, the perfect solution would be such that all nodes would be equal, misbehaving nodes would be magically ignored, the notion of “voting weight” wouldn’t be present at all, a malicious entity would have nothing to gain from operating one more node, etc. In practice this is, as far as I know, a distributed systems pipe dream.

I should also note that there is one type of attack that a on-chain proof-of-storage system can’t really protect from, and that is one of nodes which decide to omit the latest operations of certain identifiers from the responses they serve, effectively freezing identities in the past against their will.[1] The idea is that didplcbft would allow “anyone” to run their own node and confirm that there is indeed nothing in the blockchain that they could be missing.

[1] You could have nodes conduct random checks on other nodes, but there’s nothing stopping nodes from serving different answers to different IP addresses. Still, there are some ideas floating in my mind… maybe we could use the IAVL+ inclusion/exclusion proofs as the means to assure clients that there is no more operations beyond what the PLC server is reporting, or to submit as evidence against other nodes… These proofs could go in headers in the PLC responses… ugh, so many ideas and so little time, I can barely explain it all, let alone implement it.

2 Likes
9

The readme mentions

Looking very far into the future, interoperability between different node implementations could help highlight/avoid certain classes of bugs

Is it too early to do some experimental porting of what you’ve already got as a way to test the spec whilst still in motion?

I just floated this idea to the tranquil devs; being rustaceans they may be amicably nerd-baited into a RIIR :grinning_face_with_smiling_eyes:

There’s also prior art in smokesignal.events/atproto-plc at main · tangled

10

I think it’d be an extremely ambitious thing, at least if the goal were to be interoperability with my implementation. They’d be looking at reimplementing the entirety of CometBFT, for a start…

Of course, another option is to reimplement just the part that sits on top of CometBFT (the ABCI app and any other associated logic), while still using CometBFT. CometBFT supports this, instead of the ABCI app being part of the same process, it can communicate with it over RPC.

In any case, I think it’s probably still too early.

1 Like
11

Yeah I was thinking the latter, since cometbft-rs is a thing.

But I guess the same sort of lang-specific client lib could eventually exist on top of your didplcbft as well? So not really a matter of porting, but rather just making a language interface.

12

For interacting with didplcbft the intention is that the same clients used with plc.directory can be used transparently with didplcbft, as it implements the same PLC API.

1 Like