Network usage

[b00f]

For some users who run Pactus on their personal computers or laptops, the cost of internet service can be high due to the monthly fee. This is compared to the one-time purchase of a CPU or storage device (Hard drive). Therefore, it's important to keep network usage as low as possible without harming the overall consensus mechanism or the operation of the blockchain.

At present, we don't have a really good measure of network usage. However, there are two interesting metrics that we can look at:

1- How many bytes the sync module has sent or received.
2- If we run Pactus on Docker, we can see how many bytes a Docker instance has sent or received.

Comparing these two can provide us with interesting insights. For example, in one of the public nodes, we have these metrics from the sync module:

Total Sent Bytes:       602434591
Total Received Bytes:   1196449061

Over a period of more than 3 days, we received 1.1 GB and sent 0.6 GB data.

Meanwhile, Docker provides us with these stats:

NET I/O 
69.7GB / 75.1GB

This means that during the same period, we received 69.7 GB and sent 75.1 GB.

This finding is quite interesting. It shows that Libp2p received 60 times more data than what we actually consumed. As for sending data, we sent 120 times more than what we actually sent out. I think that due to the nature of P2P networks, we may receive some data (like we are bridging data?) but this is a big difference.

So, what do we need to do?

Gather More Metrics

In LibP2p, we can extract additional metrics from the Resource Manager module. This would really help us get a better understanding of network usage in the Libp2p layer.

In our sync module, we need to detail exactly how much data we have sent or received per message type.

Limit Inbound/Outbound Rates

We can define some configurable parameters that allow users to set limits for the inbound and outbound rates.

Reduce Network Usage in the Sync Module

We can reduce data usage without affecting the consensus mechanism. For instance, each node can stop broadcasting the block-announce message if it's received from another peer. In this case, at each height, instead of 21 block-announce messages, we might have fewer than 10. There may also be other ways to reduce the network usage.

Reduce Network Usage in the Libp2p Layer

We should explore ways to do this.

We can try data compression in Libp2p. I'm not sure if compressing data would help us, especially as most of the data is random, like hashes or signatures. It seems that compressing data might not give us a significant benefit. However, it's worth noting that we already have our own compression for block-response messages.

We could also limit the number of open connections, but we need to determine the optimal and secure.

Is there any thing else, we can do?

---

Some useful links:

• Interesting way to compact blocks by removing transaction from most recent blocks in Bitcoin: https://bitcoincore.org/en/2016/06/07/compact-blocks-faq/
• Get peer info API in bitcoin: https://developer.bitcoin.org/reference/rpc/getpeerinfo.html
• Compression in Libp2p: https://discuss.libp2p.io/t/compression-in-libp2p/728
• DoS Mitigation in Libp2p: https://docs.libp2p.io/concepts/security/dos-mitigation/

[b00f]

@kehiy @amirvalhalla

[kehiy]

good idea!
when we can have the DEV meeting?

[b00f]

This Saturday? Or next week?

[amirvalhalla]

@b00f
I'm okay with both

[kehiy]

@b00f Saturday that better, but I'm ok with both too

[b00f]

Ok, Let's fix it on Saturday evening. Tomorrow we work on the announcement together.

[fonty1]

Hey, very interesting thread!

Have you considered using a decentralized publish/subscribe network to relay your blocks and other related consensus information?

One such option is the Streamr Network. The transport protocol is WebRTC so peers can connect through difficult NATs, it has very low and predictable latency, it's decentralized, permissionless and so on. Your nodes will connect to 4 nodes in your topology to relay messages, so its much more efficient than Gossip flooding.
Whitepaper

Happy to answer any questions about the protocol. No tokens are needed. We also do decentralized metrics gathering if you'd like to better inspect your nodes in a decentralized way.
Polygon case study
Blog article on decentralized metrics gathering

[amirvalhalla]

@fonty1

thanks for your suggestion, we have a DEV-meeting which will be held very soon, we'll consider your offer and talk about it, also you could join our DEV-meeting and there we discuss different solutions.
Our Discord Server
Dev Meeting Announcement

[fonty1]

Thanks @amirvalhalla - I've joined your Discord server and I'll try to make it to the call this Sunday.

[amirvalhalla]

@fonty1
great, it's an honor for us to have you at the meeting.