-
Notifications
You must be signed in to change notification settings - Fork 113
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[storage + vm] Allow VM to delete proposervm
blocks (or make blocks smaller)
#130
Comments
We can avoid this problem if we only put hashes of transaction blobs into consensus (instead of the full block) and then prune transaction blobs after some period of time. This also allows us to have blocks that contain more than 2MB of data. We would fetch these blobs during parse concurrently over the network layer. One interesting observation to consider would be attempting to use the same tx blob of other processing blocks at the same height. Perhaps a more interesting observation would be to pre-gossip the tx blob to other nodes (where nodes would validate if they got that message from someone producing soon -> maybe with a signature to attest to this to avoid having producer send to all). We could alternatively have nodes gossip the tx blobs they possess (ordered from newest to oldest to try and optimize the number of O(1) fetches). This should be of the format |
proposervm
blocksproposervm
blocks (or make blocks smaller)
At some point, the only way to continue increasing TPS is to amortize the state root generation over larger numbers of txs (that hopefully update some components of the same state). |
This issue has become stale because it has been open 60 days with no activity. Adding the |
Blocked: ava-labs/avalanchego#1929 |
Add an optional We should move this into the VM scope to remove duplicate, useful code from |
Allowing a VM to delete old blocks from the
proposervm
(and from its block store) would prevent ever-growing disk size (relying entirely on state sync for new nodes to join the network).On a
tokenvm
devnet with 10k accounts that send 100M transactions, only 125MB of state is used but 32 GB of block storage (16 GB in tokenvm and 16 GB in proposervm) is used. The state size remains constant during this test but block storage grows unbounded.The text was updated successfully, but these errors were encountered: