Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IPNS Record Owner Optimisation #274

Closed
Winterhuman opened this issue Mar 27, 2022 · 4 comments
Closed

IPNS Record Owner Optimisation #274

Winterhuman opened this issue Mar 27, 2022 · 4 comments
Labels
kind/enhancement A net-new feature or an improvement to an existing feature P3 Low: Not priority right now

Comments

@Winterhuman
Copy link

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 Winterhuman added the need/triage Needs initial labeling and prioritization label Mar 27, 2022
@Stebalien
Copy link
Member

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

@Winterhuman
Copy link
Author

Turns out you actually mentioned something very similar to this about 4 years ago: libp2p/go-libp2p-kad-dht#145 (comment)

@Winterhuman Winterhuman changed the title Record Owner Optimisation IPNS Record Owner Optimisation Sep 5, 2022
@Winterhuman
Copy link
Author

Winterhuman commented Sep 5, 2022

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: #319

@guseggert guseggert added kind/enhancement A net-new feature or an improvement to an existing feature P3 Low: Not priority right now and removed need/triage Needs initial labeling and prioritization labels Oct 6, 2022
@Winterhuman
Copy link
Author

I've created #350 to close this issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement A net-new feature or an improvement to an existing feature P3 Low: Not priority right now
Projects
None yet
Development

No branches or pull requests

3 participants