You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, CESS's storage network protocol stack uses 'libp2p', but the main business scenarios have not increased efficiency due to the use of 'libp2p'. For example, the transmission of file data blocks is designed in such a way that data is transferred only between two nodes, not shared with other nodes to create a BitTorrent-like effect that accelerates transmission. In addition, due to the use of the address discovery, reporting, and subscription features of 'libp2p', additional traffic will be generated for storing miners. These functions are unnecessary in the current design, as the meta-information of the storage miners can be obtained on-chain.
Proposed Solution
Remove the libp2p library;
Remove the 'bootnode' service of the storage network, and directly report the address information of the storage miners to the chain;
Replace the data block transmission with other protocols, such as the simple HTTP protocol;
Remaining Issues
There is a risk of exposing the addresses of storage miners.
One of the initial reasons for using libp2p was the belief that exposing only the PeerId of storage miners on-chain would be beneficial for their security. While this approach means we cannot directly obtain the addresses of storage miners, it does not meet the requirements for address security. As long as an attacker can establish a connection with a storage miner, they can still obtain their address.
If the need to conceal the addresses of storage miners is reasonable and strong, this should be considered at another level. For example: address encryption, using privacy networks like I2P or TOR.
Existing Problems
Currently, CESS's storage network protocol stack uses 'libp2p', but the main business scenarios have not increased efficiency due to the use of 'libp2p'. For example, the transmission of file data blocks is designed in such a way that data is transferred only between two nodes, not shared with other nodes to create a BitTorrent-like effect that accelerates transmission. In addition, due to the use of the address discovery, reporting, and subscription features of 'libp2p', additional traffic will be generated for storing miners. These functions are unnecessary in the current design, as the meta-information of the storage miners can be obtained on-chain.
Proposed Solution
libp2p
library;Remaining Issues
One of the initial reasons for using
libp2p
was the belief that exposing only the PeerId of storage miners on-chain would be beneficial for their security. While this approach means we cannot directly obtain the addresses of storage miners, it does not meet the requirements for address security. As long as an attacker can establish a connection with a storage miner, they can still obtain their address.If the need to conceal the addresses of storage miners is reasonable and strong, this should be considered at another level. For example: address encryption, using privacy networks like I2P or TOR.
Repositories or Modules That May Be Involved
Tasklist
cess-miner
config-gen#28bootAddr
config item for thestorage-miner
cess-nodeadm#46MinerInfo.peer_id
field of the storage miner is no longer applicable #404storage-miner
The text was updated successfully, but these errors were encountered: