[Conceptual] Looking up an account #166
Conversation
trin-state/src/network.rs
Outdated
|
|
||
| async fn find_content(&self, content_key: &[u8]) -> Result<Vec<u8>, String> { | ||
| // TODO stop cloning content_key, when find_nodes_close_to_content API has changed | ||
| let ENRs = self.overlay.find_nodes_close_to_content(content_key.clone()).await; |
There was a problem hiding this comment.
er, I think these should be to_vec() instead of clone(), until #165 gets merged.
There was a problem hiding this comment.
In my previous DDHT iteration, I ended up needing/wanting two independent APIs here.
find_nodes_close_to_thing: will return the very closest nodes after an exhaustive search.stream_nodes_close_to_thing: will stream the nodes as they are found in the order of:- up until the point where it has found the very closest node, it will only stream nodes closer than the previously returned one.
- once the closest node has been found, it will continue streaming them in distance order.
An example using linear ordering.
Supposing we are looking for node 0 and there exists nodes 0, 1, 2, 3, 4, 5, 6.
We encounter the nodes in the order of: 4, 3, 5, 2, 0, 1, 6.
Then the APIs above would return:
find_nodes_close_to_thing: [0, 1, 2, 3, ... (probably cutting off at some default limit)]stream_nodes_close_to_thing: [4, 3, 2, 0, 1, 3, 6]
The general idea is that we want to prioritize being able to start requesting content and acting on the nodes we find well before we find the actual closest node.
There was a problem hiding this comment.
Another similar thing at play here is that stream_nodes_close_to_thing should potentially zero in on the very closest node, and then after that, continue searching outwards, eventually enumerating the entire search space in the network if you continue streaming nodes.
There was a problem hiding this comment.
Ok, I think I see where you're going. One thing that surprised me was: if 5 is the only node we have, this strategy wouldn't ask 5, it would just block waiting for another candidate to come in? I'd think you'd want to have a request in-flight as much as possible (maybe even 2 or 3 in parallel).
For short-term, my instinct is to keep the approach as trivial as possible, until it works.
There was a problem hiding this comment.
Yeah, the edge cases for degenerative small networks are awkward. In the algorithm I implemented the stream concludes when all nodes have been asked (or timed out). Feel free to just use this as a reference for where you might be going. No need to try and do the complex thing first.
carver
force-pushed
the
look-up-account
branch
from
fe48e30 to
c8524be
Compare
| }; | ||
| match response { | ||
| Response::FoundContent(val) => Ok(val), | ||
| // The following is unreachable, right? |
There was a problem hiding this comment.
Hah, not sure why I wrote that. It's definitely reachable.
|
@ogenev I'm totally on board with closing this pr. Just wanted to say that before you close an issue/pr I'd recommend leaving a short comment that explains why an issue / pr is being closed, for future reference. Even in cases like this, where the pr is outdated and no longer appears to be relevant/active, it's still useful to drop a quick comment explaining why before closing. |
|
Sorry for the inconvenience. I deleted the upstream branch which was outdated (stale for more than 2 years) and this closed the PR automatically. |
Just starting to feel out what it might look like to get the encoded account from the state trie.
So far, this totally ignores the question of state root. That will be addressed by v0.1.1 of eth-trie: carver/eth-trie.rs#20