next-generation p2p protocol

[cc32d9]

This is a wishlist for a next generation p2p protocol that may eventually be implemented.

[matthewdarwin]

• supports ipv6
• works over web socket or something that doesn't require dedicated IP address/port firewall rules
• improved handling on forks

[spoonincode]

supports ipv6

fwiw there isn't anything in the current protocol that prohibits this from being added.

[heifner]

supports ipv6

fwiw there isn't anything in the current protocol that prohibits this from being added.

Just the few hard-coded ipv4 calls like: https://github.com/eosnetworkfoundation/mandel/blob/main/plugins/net_plugin/net_plugin.cpp#L2254

[cc32d9]

Todd mentioned some difficulties in Boost library, but I don't know the details. But IPv6 would definitely be a nice thing.

[spoonincode]

peer discovery

[matthewdarwin]

EOSIO/eos#8170

[matthewdarwin]

EOSIO/eos#8171

[matthewdarwin]

EOSIO/eos#8260

[matthewdarwin]

EOSIO/eos#8442

[matthewdarwin]

EOSIO/eos#8821

[matthewdarwin]

https://docs.libp2p.io/introduction/what-is-libp2p/

[matthewdarwin]

Todd mentioned some difficulties in Boost library, but I don't know the details. But IPv6 would definitely be a nice thing.

EOSIO/eos#8169

[spoonincode]

Yes IME IPv6 troubles with asio is (as often the case with asio) asio being pedantic and pretty raw.

For example the existing http plugin when setting up the listening socket does something like

tcp::resolver::query query( tcp::v4(), host, port);
my->listen_endpoint = *resolver.resolve( query );

Sure, that works for IPv4 today. But what if I wanted to support IPv6 too? Well I could do something like

tcp::resolver::query query(host /* "localhost" */, port);
my->listen_endpoint = *resolver.resolve( query );

BUG: the resolve here will actually return two endpoints: one with 127.0.0.1 and one with ::1. So application code needs to be smart enough to iterate through and listen on all of them.

For asio that abstracts away the address family nicely, that's actually usually enough. Without asio, if you're writing closer to BSD sockets, IMO it's nice to always use IPv6 family across the board. Just for illustration purposes, you might emulate something like that in asio with

resolver.resolve(tcp::v6(), "localhost", "5555", tcp::resolver::v4_mapped | tcp::resolver::all_matching);

This will return ::1 and ::ffff:127.0.0.1 But wait! BUG: IPV6_V6ONLY is set off by default on Linux and on by default on MacOS. So trying to listen on ::ffff:127.0.0.1 will error out on MacOS, I believe, unless you go and set boost::asio::ip::v6_only too!

We've only talked about listening sockets; outgoing sockets is a whole other ball game. You'll want to read up on "Happy Eyeballs" -- RFC6555 & RFC8305. cleos, imo needs to follow these suggestions. It's another reason on top of #110 I'm suggesting moving to the platform HTTP provider for cleos. Something like libcurl, WinHTTP, NSURLSession, all already have lots of smarts like Happy Eyeballs built in.

p2p probably doesn't need Happy Eyeballs because it's probably acceptable to round robin resolved addresses after they naturally time out.

Anyways, mostly want to point out that properly supporting IPv6 does require a little love beyond just flipping something in the code.

[jgiszczak]

Swarm download.

[matthewdarwin]

BPs run multiple public p2p endpoint as a cluster of nodeos together behind a load balancer. Today all nodeos have to have all the blocks. Ideally all the "older" blocks are not stored on all nodes, but can retrieve them from another node to send them out. Eg for block producers they might run 10 p2p servers. Most clients are asking about the last few blocks only so having every node in the cluster have all blocks is waste of disk space. Could be done via some sort of smart proxy?

[matthewdarwin]

Ability to start from snapshot via p2p.

[cc32d9]

Ability to start from snapshot via p2p.

this will require your neighbor to freeze operation until you download the state. Not something applicable to public peers

[roger-eosuk]

Sure will drop the link to Impervious the p2p method over Bitcoin Lightning network on Bitcoin.
https://www.impervious.ai/
https://twitter.com/ImperviousAi
https://docs.impervious.ai/
https://www.publicdomain.live/Impervious
This is a great demo video https://www.youtube.com/watch?v=O0Dcx6ScnRY
So in theory what they do for 15sats in the demo we could do for free on eosio, right?

[jgiszczak]

@roger-eosuk Impervious is orthogonal to this thread. This thread is about the protocol nodes would use which are participating in the network that actually produces and propagates the chain.

Having said that, yes, a version of Impervious could be implemented on eosio, and it could operate for free, requiring only sufficient staking (which is refundable) for the activity of each user. It could be done now, implemented entirely in smart contracts. No changes are required to the code the nodes run.

[sunburntcat]

Ability to begin sync from specific irreversible block

[tedcahalleos]

Per KevinH, it is now multi-threaded and stable performance is great. But the syncing performance and algorithms need to be rewritten. LIB catch-up, Head catch up, in_sync (Synchronize), transition of those barriers is not healthy. Not micro-fork aware. Some awareness helps it not redo work (re-requesting and re-fetching blocks). Likely needs queues to hold data it will need again. The current state machine is convoluted.

[matthewdarwin]

Don't connect to p2p peers while replaying blocks.log (this is more a bug fix)

[matthewdarwin]

Dedicated blocks-only p2p peers exist in the network exist to ensure blocks propagate even when there is some sort of unexpected p2p transaction load. See if this requirement can be removed with the p2p redesign.

[matthewdarwin]

Remove the feature to have public/private key for connecting p2p peers; peer-private-key in config.ini. This is accomplished normally today via firewall rules or wireguard connections.

[matthewdarwin]

Ability to start from snapshot via p2p.

this will require your neighbor to freeze operation until you download the state. Not something applicable to public peers

If your neighbour generates snapshots on a regular basis, then you just get the last one.

[matthewdarwin]

The new "next-gen" p2p protocol should run in parallel to (on a different port) to the existing p2p protocol. The existing p2p protocol would be removed at some point. Like what "bnet" plugin used to do.

[matthewdarwin]

The goal should be to allow BPs to have same control they have today, but for the average developer, they should be able to just start nodeos with a static configuration and things just work without messing with peers and snapshots and whatever else.

[DenisCarriere]

Perhaps gRPC instead of Websocket ?

@matthewdarwin

• supports ipv6
• works over web socket or something that doesn't require dedicated IP address/port firewall rules
• improved handling on forks

[sunburntcat]

Title:

Move transaction headers (TaPOS) into the p2p protocol

Background:
Block head number and block prefix are currently required for every eosio transaction. This was done to improve fork handling and prevent double-spend of a transaction as it moves around the p2p network. However, this means end users need to query a network RPC node to get this information before they submit a transaction... a very time intensive process.

Suggested solution:
Remove this requirement and instead allow RPC nodes to append these TaPOS fields to a broadcasted transaction. And then append their own signature before they propagate it onto the next peer. Ideally, it could be implemented as a --signature-provider argument inside http plugin in nodeos.

Expected Outcomes:

• Significant reduction in overhead and latency for client libraries like eosjs.
• Opens the door to sending transactions from devices with poor network connection, including sensors wanting to broadcast transactions to the chain.

[swatanabe]

Move transaction headers (TaPOS) into the p2p protocol

This won't work. tapos in the p2p protocol cannot fulfill the same role as tapos in transaction signatures. Also, getting tapos doesn't need to be expensive. It's only slow because the API did not provide a lightweight interface for getting it.

[sunburntcat]

tapos in the p2p protocol cannot fulfill the same role as tapos in transaction signatures.

The point is still there that ideally a transaction should not need ref_block_num and ref_block_prefix if the RPC they are submitting to already has this information.

If a transaction, for whatever reason, was meant to be applicable to a particular fork of the chain (implied by num/prefix), then they could simply choose an RPC node on that fork.