[Guardrails] Data Collection - Block Size

[jessicadaugherty]

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

• Use a localnet node to increase the block size, simulate mainnet tx volume, and document the impact on node processing or storage requirements and how much tx scale would be achieved.

Deliverable

• Define specs for a localnet node (e.g. 4vCPU - Intel(R) Xeon(R) CPU @ 2.80GHz - 8GB RAM Cloud Provider: GCP)
• Increase the block size in MB (current average size is ~3.8 MB) using Customizable Max Block Size from 0.9.0 (an inactive parameter in mainnet)
• Send txs from the tx bot ($ git clone git@github.com:pokt-network/tx-bot.git)
• Calculate Header Size + Amino Overhead + NumOfValidators * Bytes (Max_Vote Size) + NumOfEvidence * Bytes (Max_Evidence Size)
• Measure how many txs can be included, bucketed by block size value change
• Document the above to recommend if block size should be increased, and if so by how much

Non-goals / Non-deliverables

• Block time

General issue deliverables

• Update the appropriate CHANGELOG
• Update any relevant READMEs (local and/or global)
• Update any relevant global documentation & references
• If applicable, update the source code tree explanation
• If applicable, add or update a state, sequence or flowchart diagram using mermaid

---

Creator: @jessicadaugherty

[jessicadaugherty]

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.

[jessicadaugherty]

Edited to include tx bot directory link @iajrz hope that helps!

[nodiesBlade]

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?

[Olshansk]

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?

1. We merge in the unit test [Test] Unit Tests to validate Block Size increases + minor improvements #1538
2. I will provide instructions to test this on localnet
3. Assuming (2) is successful, we will validate it on TestNet

Given that Tendermint has a 100MB block size (source), I am hopeful but need to validate.

[Olshansk]

As part of the RC 0.10 release guide and probabilistic proof work, this work was completed.

Block Data

This GitHub gist shows the block composition.

Block Size Validation

These instructions can be used to validate Block size increases locally.

1. Run a LocalNet

2. 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}"

3. 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
   

4. 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"
   }