Design Draft: Removing Kademlia

Hello everyone!
If you haven’t already heard: we’ve decided to remove our implementation of the Kademlia DHT protocol.
You can read more about the decision here: https://storj.io/blog/2019/08/so-youre-a-storage-node-operator.-which-satellites-do-you-trust/

As such, we’ve begun to discuss design options on implementing our new “Opt-In” approach to Satellite-Storage Node relationships here: https://github.com/storj/storj/pull/2686

Please let us know what you think. We welcome your ideas and feedback!

3 Likes

This is nice. Kademlia may trip up some cheap routers due to the connection count and since it is used for only one thing it can be replaced. Honestly it seemed to me that Kademlia in v3 is a leftover from the previous versions where IIRC it was used more.

So, the satellite is like a torrent tracker and the list (option #3) is like a list of recommended trackers. This seems more efficient than Kademlia and also allows for separate networks - right now nodes are a part of a big network even if they have no common satellites, but without Kademlia there could be nodes that do not have common satellites and they would not affect each other at all.

With the opt-out approach - how would I even know if a satellite paid me? Let’s say my node is in contact with 10 satellites and I received 9 payments - which satellite did not pay? It’s not like I can have a separate wallet address per satellite on the same node (and managing separate Ethereum addresses are more annoying than separate Bitcoin addresses).

That’s still a partially unsolved problem. Even with the chosen option we need a way to know which satellite is paying. I believe you can add metadata to a payout to do this, so that might be one option. Would be nice to integrate that in a central dashboard that shows payout history. Though I’m sure I’m not suggesting anything new.

1 Like

I think that list would be managed by SNO with something like vote. If satellite downvoted - removed from the list at the end

It would be relatively easy to programmatically tie the payouts on the ethereum blockchain to the data stored and bandwidth used on the node. This would save a lot of effort on the SNO side to do all this manually. I agree that a rating system would be needed, but in order to rate a satellite it would be nice to be able to automatically know that payouts are done as expected. Especially when judging new satellites.

1 Like

Satellite could send, for example, the transaction id to the node it paid. That could get logged (with the upload/storage numbers of the month) to a file or something where I could check it periodically to see if nobody is cheating me.
If the satellite does not send a transaction id for two months, the node stops accepting data from it (or even deletes the data it has), unless the SNO creates an exception or whatever.

I would like to be able to select satellites as a per node setting and have two node viewed as independent on different machines with of course different identities, just a thought

You’ll be able to do that.
The list of satellites will be configurable.

1 Like