Closed jessicadaugherty closed 1 year ago
Analysis on how much required data can fit in a block. If using probabilistic proofs, that needs to be a variable to determine what block size can be scaled to.
Edited to include tx bot directory link @iajrz hope that helps!
Do we have contacts over the tendermint side who can lean in and provide implications of increasing block size.. Top of mind, obviously it would increase overhead on consensus since we're gossiping larger blocks. But any gotchas that tendermint devs have came across?
Do we have contacts over the tendermint side who can lean in and provide implications of increasing block size.. Top of mind, obviously it would increase overhead on consensus since we're gossiping larger blocks. But any gotchas that tendermint devs have came across?
Given that Tendermint has a 100MB block size (source), I am hopeful but need to validate.
As part of the RC 0.10 release guide and probabilistic proof work, this work was completed.
This GitHub gist shows the block composition.
These instructions can be used to validate Block size increases locally.
Run a LocalNet
Open a few terminals and export all the environment variables in each one
# Start inspecting the logs
# Watch the block size parameter value
watch -n 1 "pocket query param pocketcore/BlockByteSize --remoteCLIURL ${POCKET_ENDPOINT}"
# Watch the block height and num of transactions
watch -n 1 "curl -s -X 'POST' "http://localhost:8083/v1/query/block" | jq '{num_txs: (.block.data.txs | length), height: (.block.header.height), total_txs: .block.header.total_txs}'"
# Watch the upgrade and features
watch -n 1 "pocket query upgrade --remoteCLIURL ${POCKET_ENDPOINT}"
Run all the commands
# Upgrade the protocol
pocket gov upgrade $DAO <HEIGHT> 0.0.1 $NETWORK 10000 --remoteCLIURL ${POCKET_ENDPOINT}
# Enable CODEC
pocket gov enable $DAO <HEIGHT> CODEC $NETWORK 10000 --remoteCLIURL ${POCKET_ENDPOINT}
# Enable BLOCK
pocket gov enable $DAO <HEIGHT> BLOCK $NETWORK 10000 --remoteCLIURL ${POCKET_ENDPOINT}
# Fill the block using tx-bot while looking at logs and num_txs
Inspection of logs & output
# Compare `totalBytes` relative to `maxDataBytes`; we should be able to fit in more
# Compare `num_txs` that fit in a block; we shold be able to fit in more
# Before enabling the parameter (~1MB)
f95bdfcbdd38_node4.dev.pokt | [00] ReapMaxBytesMaxGas 1 - totalBytes 13298
f95bdfcbdd38_node4.dev.pokt | [00] CreateProposalBlock - maxDataBytes 13444
{
"num_txs": 57,
"height": "23",
"total_txs": "59"
}
# After enabling the parameter (~4MB)
f95bdfcbdd38_node4.dev.pokt | [00] ReapMaxBytesMaxGas 3 - totalBytes 193383
f95bdfcbdd38_node4.dev.pokt | [00] CreateProposalBlock - maxDataBytes 3998444
{
"num_txs": 831,
"height": "30",
"total_txs": "1697"
}
# After increasing it (~8MB)
8cf19b0b1f6f_node3.dev.pokt | [00] ReapMaxBytesMaxGas 3 - totalBytes 434382
8cf19b0b1f6f_node3.dev.pokt | [00] CreateProposalBlock - maxDataBytes 7998444
{
"num_txs": 1866,
"height": "38",
"total_txs": "6024"
}
Objective
To measure the efficacy of pocket-score scalability efforts, we should experiment with different block sizes against standard node configurations to understand the impact of increasing block size on how many transactions can be processed in a block.
Origin Document
Guardrails Projects
Guardrails Recommendations
Goal
Deliverable
Non-goals / Non-deliverables
General issue deliverables
Creator: @jessicadaugherty