specs icon indicating copy to clipboard operation
specs copied to clipboard

IPNS Record Owner Optimisation

Open Winterhuman opened this issue 3 years ago • 4 comments

Here's the current situation when fetching the latest IPNS record:

  • Peer 12D3KooWowner creates an IPNS record k51key... and distributes it through the network.
  • Peer 12D3KooWresolver wants to find the latest version of k51key....
  • 12D3KooWresolver searches the network and finds n peers who advertise k51key..., they then fetch the record from n number of peers and check which record has the highest sequence value.

The problem with this system is that it's very slow needing multiple peers to verify that you've fetched the latest record, however, there is an optimisation for speeding this up for when one of the n peers happens to be the record owner. Here's how it might work:

  • Peer 12D3KooWowner creates an IPNS record k51key... and distributes it through the network.
  • Peer 12D3KooWresolver wants to find the latest version of k51key....
  • 12D3KooWresolver searches the network and finds n peers who advertise k51key.... Instead of trying to fetch n number of records, they start by fetching a few at random (let's say three for this example).
  • 12D3KooWresolver reads the record to find PeerID 12D3KooWowner, they then check to see if any of the n peers they found have PeerID 12D3KooWowner.
  • If one of the 3 random peers was the record owner, the search can immediately stop since the record owner's copy of k51key... is guaranteed to be the latest and has already been fetched.
  • If one of the n-3 peers is the record holder, 12D3KooWresolver can attempt to fetch k51key... directly from them. If it succeeds, the search can immediately stop since the record owner's copy of k51key... is guaranteed to be the latest.
  • If 12D3KooWowner isn't any of the n peers, or the attempt to fetch k51key... from 12D3KooWowner failed, 12D3KooWresolver will continue to fetch all remaining records to compare them as before.

Because IPNS records expire, record owners are likely to be online most of the time in order to ensure the record doesn't disappear from the network, this means the chance of finding the record holder amongst the n peers will be relatively high in the current environment.

Winterhuman avatar Mar 27 '22 13:03 Winterhuman

Yeah, this would be really nice. Basically, IPNS records could contain "canonical" sources for finding the latest version.

Stebalien avatar Apr 11 '22 12:04 Stebalien

Turns out you actually mentioned something very similar to this about 4 years ago: https://github.com/libp2p/go-libp2p-kad-dht/issues/145#issuecomment-410831110

Winterhuman avatar Apr 20 '22 17:04 Winterhuman

Having an optional IpnsEntry.data[trust] field for defining an array of PeerIDs to trust (with the owner's PeerID being implicitly trusted) seems like a possible way forward, what do you think? @Stebalien @lidel

Context: https://github.com/ipfs/specs/pull/319

Winterhuman avatar Sep 05 '22 19:09 Winterhuman

I've created https://github.com/ipfs/specs/pull/350 to close this issue

Winterhuman avatar Nov 27 '22 14:11 Winterhuman