Replies: 2 comments 12 replies
-
Beta Was this translation helpful? Give feedback.
-
|
good idea! |
Beta Was this translation helpful? Give feedback.
-
|
This Saturday? Or next week? |
Beta Was this translation helpful? Give feedback.
-
|
@b00f |
Beta Was this translation helpful? Give feedback.
-
|
@b00f Saturday that better, but I'm ok with both too |
Beta Was this translation helpful? Give feedback.
-
|
Ok, Let's fix it on Saturday evening. Tomorrow we work on the announcement together. |
Beta Was this translation helpful? Give feedback.
-
|
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. 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. |
Beta Was this translation helpful? Give feedback.
-
|
thanks for your suggestion, we have a |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @amirvalhalla - I've joined your Discord server and I'll try to make it to the call this Sunday. |
Beta Was this translation helpful? Give feedback.
-
|
@fonty1 |
Beta Was this translation helpful? Give feedback.
-
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:
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:
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:
Beta Was this translation helpful? Give feedback.
All reactions