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
P2P messages are currently sent as raw buffers, but they can be compressed.
Ethereum opts to use snappy compression for the propagation of p2p messages (https://github.com/google/snappy), although it is not a perfect compression algorithm it runs very very quickly.
We should see a large improvement here when propagating transactions as although they contain "random" data, they have G1 Points encoded over 4 field elements ~508bits, when they are only ~256 bits each. ( This is done as the points are encoded as Fr scalars, that can be directly used in transcript hashing ).
Add snappy compression on all p2p sending functions
in propagate of p2p client
in send of reqresp
Add snappy decompression on receipt
in processFromPeer of p2p client
in recieve of reqresp
The text was updated successfully, but these errors were encountered:
Overview
P2P messages are currently sent as raw buffers, but they can be compressed.
Ethereum opts to use snappy compression for the propagation of p2p messages (https://github.com/google/snappy), although it is not a perfect compression algorithm it runs very very quickly.
We should see a large improvement here when propagating transactions as although they contain "random" data, they have G1 Points encoded over 4 field elements ~508bits, when they are only ~256 bits each. ( This is done as the points are encoded as Fr scalars, that can be directly used in transcript hashing ).
Add snappy compression on all p2p sending functions
Add snappy decompression on receipt
The text was updated successfully, but these errors were encountered: