Eventual-consistent hashchain of multiple IPNS endpoints

planetoryd · March 17, 2022, 3:12am

We know that the latest IPNS uses DHT and Pubsub, which enables one publickey to publish a pointer, so we can get a dynamic IPLD owned by one person. Then there are also some ways to extend its functionality.

The first thing I can think of is to introduce a hashchain. (Not sure if it already exists. Theoretically IPNS can work without forming a chain anyway.) For this one-usered IPNS, each change published to IPNS is a block pointing to the previous version of the IPNS pointer. Each block includes a WASM executable, which validates the next block. For the nodes knowing the full history, the executable on the hashchain can limit the permissions of the IPNS owner. Next, we introduce multiple IPNS endpoints, which link each other’s version and forms a single chain when not conflicting by accident. Then that’s a eventual-consistent blockchain, and you know what could be done next.

We then create a block that contains all these IPNS addresses, and when a user visits that dweb site, all addresses are resolved via DHT, and Pubsub, to avoid hidden branches on the chain. (All branches are downloaded before validating. All IPNS endpoints mention the branch they acknowledge. A branch is visible as long as one IPNS endpoint mentions it.) When there’s a conflict, the branch with more addresses (from that block) pointed wins.

This is some kinda small-scale blockchain, without currency. The good thing is that we can have many such chains without too much burden. This is a way of reaching Mutable IPLD that I believe to be quite decentralized.

planetoryd · March 17, 2022, 10:43am

github.com/ipfs/notes

Extending IPNS with hashchains and WASM, one approach to Mutable IPLD

opened 08:12AM - 17 Mar 22 UTC

planetoryd

need/triage

I wonder what is the roadmap for mutable IPLD, and I'd propose one partial solut…ion in case you haven't thought of. In fact, it isn't really about mutability. It's just, functionality, more decentralized, dynamic. It would reduce the reliance on the centralized web. Not sure if that should be added to IPFS or created as a separate package. We know that the latest IPNS implementation uses DHT and Pubsub, and now hypothetically I could change the IPNS so that each IPNS record is a block containing a WASM binary. The binary validates the next block and deals with branch conflicts, ran by some daemon on every IPFS node, so the IPNS endpoint isn't entirely controlled by the public key. The independence of a IPNS endpoint is quite intriguing in terms of decentralization. Now this is a single-ownered IPNS hashchain, with which the owner could, for example, publish an IPNS record to adjust her own permissions, so that only a part of the pointed DAG could be modified or it has to meet certain criteria. The owner could also add moderators, as IPNS links in her hashchain, and set permissions via WASM. However the owner's publickey could be compromised and the chain could be forked, and the original branch could be hidden since the DHT key isn't pointing at it, so we introduce a block that contains all the moderators' IPNS publickeys, and they are equal now. Let me call it a dweb site. When a user visit the site, that block is obtained and all the IPNS records are resolved via DHT to ensure the 'right' branch is always visible. The 'right' branch is visible as long as one moderator points at it on DHT. If all other moderators forked the hashchain when their permissions have been revoked, as long as the 'right branch' is visible they won't succeed. In case of conflicts, the branch with most moderators' IPNS pointed at is chosen (this behavior could be determined by WASM in a block; pointing means signed IPNS records) Pubsub could be used as a fallback when DHT fails or all moderators have been replaced (better change site address block then). This might already been used in other protocols, being called append-only logs or something, I'm not sure. As something similar to blockchain, it is more lightweight and decentralized. Users could easily create many such chains, where everyone validates the blocks. It has eventual consistency. With this kind of hashchain, more interesting things could be built upon it in a very decentralized manner. Besides trusting site moderators, it'd be good to introduce https://github.com/ipfs/roadmap/issues/78 too. Speaking of mutable IPLD, #392

SionoiS · March 17, 2022, 12:53pm

I don’t quite understand how it works maybe use images?

Also terminology (I’m guilty of this often)! AFAIK Mutable IPLD is by definition not possible and if you meant (IPFS) DAG still not mutable.

Would multiple signatures in IPNS records not allow multiple key owners by consensus to control the “chain”?

What is the problem solved by your invention?

Tell us more.

planetoryd · March 17, 2022, 1:05pm

Not exactly an invention. Just application of some existing stuff.

AFAIK Mutable IPLD is by definition not possible and if you meant (IPFS) DAG still not mutable.

It depends on your definition. The word IPLD doesn’t have an ‘immutable’ in it. Just pointers.

Would multiple signatures in IPNS records not allow multiple key owners by consensus to control the “chain”?

Multiple signatures on one IPLD endpoint is asking for problems. Synchronization, etc.

What is the problem solved by your invention?

Intuitively, it creates a multi-owner IPLD, and allows people to vote on it. To use an analogy inappropriately, it’s like the smart contract from blockchain. It deals with power, permissions.

SionoiS · March 17, 2022, 1:23pm

Threshold signatures would work in this case.

For example 5 of 10 people would need to sign for the IPNS record to be updated.

I’m all for updating IPNS, it need more flexibility. I want to be able to use any signature scheme I want!

planetoryd · March 17, 2022, 1:32pm

Threshold signatures

Maybe, in some cases. Hashchain might be more flexible