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
The current block headers contain commitments for all rows as well as the index for App_id, leading to excessively bulky block headers. In a fully loaded state, the commitments alone can reach up to 128kb. Moreover, after sharding, we must include "commitments only". We should aim to include only the commitment of row commitments and the number of rows in the block headers. This approach requires hashing all row commitments, thereby losing homomorphic properties, but this is inconsequential in our current context.
This change will primarily affect light clients and not validators, as validators can access the actual commitments from storage. Hence, the actual data is more inclined towards using DHT (Distributed Hash Table) rather than Gossip.
The text was updated successfully, but these errors were encountered:
The current block headers contain commitments for all rows as well as the index for App_id, leading to excessively bulky block headers. In a fully loaded state, the commitments alone can reach up to 128kb. Moreover, after sharding, we must include "commitments only". We should aim to include only the commitment of row commitments and the number of rows in the block headers. This approach requires hashing all row commitments, thereby losing homomorphic properties, but this is inconsequential in our current context.
This change will primarily affect light clients and not validators, as validators can access the actual commitments from storage. Hence, the actual data is more inclined towards using DHT (Distributed Hash Table) rather than Gossip.
The text was updated successfully, but these errors were encountered: