doc: add TP#001 for Big Blocks

docs/test-plans/001-Big-Blocks/test-cases/tc-001-val-large-txs.md

@@ -0,0 +1,28 @@
+# Test-Case #001 - Validators submit large txs
+
+## Pre-Requisites:
+
+1. Every validator has enough funds in the account
+2. The chain has created the first block
+3. Every validator has enough peers
+4. Validators’ set is not changing during test execution
+   1. All validators are created during genesis
+
+## Steps for each of the validators:
+
+1. Setups network with:
+   1. `I` mb of bandwidth
+   2. `J` milliseconds of network latency
+2. Generates and broadcasts
+   1. `X` kb of random data
+   2. `Y` times
+3. Checks the block size is bigger then 3.5 MiB
+
+## Data Set:
+
+| Number of Validators<br />`I` |            Bandwidth / Latency per validator<br />`J`             | KB of random data<br />`X` | Submit amount<br />`Y` |
+| :---------------------------: | :---------------------------------------------------------------: | :------------------------: | :--------------------: |
+|              20               | 1. 256MiB / 0ms <br /> 2. 256MiB / 100ms <br /> 3. 256MiB / 200ms |            200             |           10           |
+|              40               |  1. 256MiB / 0ms <br />2. 320MiB / 100ms <br />3. 320MiB / 200ms  |            100             |           10           |
+|              80               |  1. 320MiB / 0ms <br />2. 320MiB / 100ms <br />3. 320MiB / 200ms  |             50             |           10           |
+|              100              |  1. 320MiB / 0ms <br />2. 320MiB / 100ms <br />3. 320MiB / 200ms  |             40             |           10           |

docs/test-plans/001-Big-Blocks/test-cases/tc-002-da-sync.md

@@ -0,0 +1,38 @@
+# Test-Case #002 - DA nodes are in sync with validators’
+
+## Pre-Requisites:
+
+1. Every validator has enough funds in the account
+2. The chain has created the first block
+3. Every validator has enough peers
+4. Validators’ set is not changing during test execution
+   1. All validators are created during genesis
+5. DA Nodes amount is not changing during the test execution
+   1. We gracefully add DA Nodes as the first block is produced
+
+## Steps for each of the validators:
+
+1. Setups network with:
+   1. `I` mb of bandwidth
+   2. `J` milliseconds of network latency
+2. Generates and broadcasts
+   1. `X` kb of random data
+   2. `Y` times
+   3. IP and Genesis Hash for DA Bridge nodes
+3. Checks the block size is bigger then 3.5 MiB
+
+## Steps for each of the DA nodes:
+
+1. Setups network with:
+   1. `I` mb of bandwidth
+   2. `J` milliseconds of network latency
+2. Bridge nodes connect to respective Validators
+3. Full / Light nodes connect to Bridge Nodes
+4. Check that the latest received height is the same as for the validators
+
+## Data Set:
+
+| Number of Validators / Bridges / Fulls / Lights <br /> `I` |                                Bandwidth / Latency per v/b/f/l <br /> `J`                                | KB of random data <br /> `X` | Submit amount <br /> `Y` |
+| :--------------------------------------------------------: | :------------------------------------------------------------------------------------------------------: | :--------------------------: | :----------------------: |
+|                     40 / 40 / 20 / 100                     | 1. 256(v/b/f)-100(l)MiB / 0ms <br />2. 320(v/b/f)-100(l)MiB / 100ms<br />3. 320(v/b/f)-100(i)MiB / 200ms |             100              |            10            |
+|                   100 / 100 / 50 / 1000                    | 1. 320(v/b/f)-100(l)MiB / 0ms<br />2. 320(v/b/f)-100(l)MiB / 100ms<br />3. 320(v/b/f)-100(i)MiB / 200ms  |              40              |            10            |

docs/test-plans/001-Big-Blocks/test-cases/tc-003-da-sync-past.md

@@ -0,0 +1,53 @@
+# Test-Case #003 - DA nodes are syncing past headers faster then validators produce new ones
+
+## Pre-Requisites:
+
+1. Every validator has enough funds in the account
+2. The chain has created the first block
+3. Every validator has enough peers
+4. Validators’ set is not changing during test execution
+   1. All validators are created during genesis
+5. DA Nodes amount is not changing during the test execution
+   1. We gracefully add DA Nodes as the first block is produced
+
+## Steps for each of the validators:
+
+1. Setups network with:
+   1. `I` mb of bandwidth
+   2. `J` milliseconds of network latency
+2. Generates and broadcasts
+   1. `X` kb of random data
+   2. `Y` times
+   3. IP and Genesis Hash for DA Bridge nodes
+3. Checks the block size is bigger then 3.5 MiB
+
+## Steps for each of the DA Bridge nodes:
+
+1. Setups network with:
+   1. `I` mb of bandwidth
+   2. `J` milliseconds of network latency
+2. Connects to respective Validator
+3. Shares the genesis hash and ip to Full / Light Nodes
+4. Check that it is synced
+5. Broadcasts new blocks to the DA network
+
+## Steps for each of DA Full / Light nodes:
+
+1. Setups network with:
+   1. `I` mb of bandwidth
+   2. `J` milliseconds of network latency
+2. Receives the trusted genesis hash and ip from Bridge Nodes
+3. Waits until `N` amount of block has been produced by the chain
+4. Starts syncing the chain afterwards
+5. Checks that it can catch up the chain faster then new blocks are produced (\*)
+
+## Data Set:
+
+| Number of Validators / Bridges / Fulls / Lights <br/> `I` |                               Bandwidth / Latency per v/b/f/l <br/> `J`                                | KB of random data <br/> `X` | Submit amount <br/> `Y` | Amount of Past Blocks <br/> `N` |
+| :-------------------------------------------------------: | :----------------------------------------------------------------------------------------------------: | :-------------------------: | :---------------------: | :-----------------------------: |
+|                    40 / 40 / 20 / 100                     | 1. 256(v/b/f)-100(l)MiB / 0ms <br/>2. 320(v/b/f)-100(l)MiB / 100ms<br/>3. 320(v/b/f)-100(i)MiB / 200ms |             100             |           50            |               30                |
+|                   100 / 100 / 50 / 1000                   | 1. 320(v/b/f)-100(l)MiB / 0ms<br/>2. 320(v/b/f)-100(l)MiB / 100ms<br/>3. 320(v/b/f)-100(i)MiB / 200ms  |             40              |           100           |               50                |
+
+## Notes:
+
+(\*) - We need to measure the sync time to have a baseline for further benchmarking of the new p2p stack that is implemented

docs/test-plans/001-Big-Blocks/test-cases/tc-004-das-current.md

@@ -0,0 +1,52 @@
+# Test-Case #004 - DASing of the latest header is faster then the block production time
+
+## Pre-Requisites:
+
+1. Every validator has enough funds in the account
+2. The chain has created the first block
+3. Every validator has enough peers
+4. Validators’ set is not changing during test execution
+   1. All validators are created during genesis
+5. DA Nodes amount is not changing during the test execution
+   1. We gracefully add DA Nodes as the first block is produced
+
+## Steps for each of the validators:
+
+1. Setups network with:
+   1. `I` mb of bandwidth
+   2. `J` milliseconds of network latency
+2. Generates and broadcasts
+   1. `X` kb of random data
+   2. `Y` times
+   3. IP and Genesis Hash for DA Bridge nodes
+3. Checks the block size is bigger then 3.5 MiB
+
+## Steps for each of the DA Bridge nodes:
+
+1. Setups network with:
+   1. `I` mb of bandwidth
+   2. `J` milliseconds of network latency
+2. Connects to respective Validator
+3. Shares the genesis hash and ip to Full / Light Nodes
+4. Check that it is synced
+5. Broadcasts new blocks to the DA network
+
+## Steps for each of DA Full / Light nodes:
+
+1. Setups network with:
+   1. `I` mb of bandwidth
+   2. `J` milliseconds of network latency
+2. Receives the trusted genesis hash and ip from Bridge Nodes
+3. Starts syncing the chain afterwards
+4. DASes the latest header faster then `T` seconds (\*)
+
+## Data Set:
+
+| Number of Validators / Bridges / Fulls / Lights <br /> `I` |                                Bandwidth / Latency per v/b/f/l <br /> `J`                                | KB of random data <br /> `X` | Submit amount <br /> `Y` | Block Time in seconds <br /> `T` |
+| :--------------------------------------------------------: | :------------------------------------------------------------------------------------------------------: | :--------------------------: | :----------------------: | :------------------------------: |
+|                     40 / 40 / 20 / 100                     | 1. 256(v/b/f)-100(l)MiB / 0ms <br />2. 320(v/b/f)-100(l)MiB / 100ms<br />3. 320(v/b/f)-100(i)MiB / 200ms |             100              |            10            |                30                |
+|                   100 / 100 / 50 / 1000                    | 1. 320(v/b/f)-100(l)MiB / 0ms <br />2. 320(v/b/f)-100(l)MiB / 100ms<br />3. 320(v/b/f)-100(i)MiB / 200ms |              40              |            10            |                30                |
+
+## Notes:
+
+(\*) - We need to measure the DAS time to have a baseline for further benchmarking of the new p2p stack that is implemented

docs/test-plans/001-Big-Blocks/test-cases/tc-005-das-past.md

@@ -0,0 +1,55 @@
+# Test-Case #005 - DA nodes are DASing past headers faster then validators produce new ones
+
+## Pre-Requisites:
+
+1. Every validator has enough funds in the account
+2. The chain has created the first block
+3. Every validator has enough peers
+4. Validators’ set is not changing during test execution
+   1. All validators are created during genesis
+5. DA Nodes amount is not changing during the test execution
+   1. We gracefully add DA Nodes as the first block is produced
+
+## Steps for each of the validators:
+
+1. Setups network with:
+   1. `I` mb of bandwidth
+   2. `J` milliseconds of network latency
+2. Generates and broadcasts
+   1. `X` kb of random data
+   2. `Y` times
+   3. IP and Genesis Hash for DA Bridge nodes
+3. Checks the block size is bigger then 3.5 MiB
+
+## Steps for each of the DA Bridge nodes:
+
+1. Setups network with:
+   1. `I` mb of bandwidth
+   2. `J` milliseconds of network latency
+2. Connects to respective Validator
+3. Shares the genesis hash and ip to Full / Light Nodes
+4. Check that it is synced
+5. Broadcasts new blocks to the DA network
+
+## Steps for each of DA Full / Light nodes:
+
+1. Setups network with:
+   1. `I` mb of bandwidth
+   2. `J` milliseconds of network latency
+2. Receives the trusted genesis hash and ip from Bridge Nodes
+3. Waits until `N` amount of block has been produced by the chain
+4. Starts DASing the chain afterwards
+5. Checks that it can:
+   1. DASes the past headers faster then new blocks are produced (\*)
+   2. DASes the current header in parallel
+
+## Data Set:
+
+| Number of Validators / Bridges / Fulls / Lights <br /> `I` |                                Bandwidth / Latency per v/b/f/l <br /> `J`                                | KB of random data <br />`X` | Submit amount <br />`Y` | Amount of Past Blocks <br />`N` |
+| :--------------------------------------------------------: | :------------------------------------------------------------------------------------------------------: | :-------------------------: | :---------------------: | :-----------------------------: |
+|                     40 / 40 / 20 / 100                     | 1. 256(v/b/f)-100(l)MiB / 0ms <br />2. 320(v/b/f)-100(l)MiB / 100ms<br />3. 320(v/b/f)-100(i)MiB / 200ms |             100             |           50            |               30                |
+|                   100 / 100 / 50 / 1000                    | 1. 320(v/b/f)-100(l)MiB / 0ms<br />2. 320(v/b/f)-100(l)MiB / 100ms<br />3. 320(v/b/f)-100(i)MiB / 200ms  |             40              |           100           |               50                |
+
+## Notes:
+
+(\*) - We need to measure the DAS of past headers time to have a baseline for further benchmarking of the new p2p stack that is implemented

docs/test-plans/001-Big-Blocks/test-cases/tc-006-da-node-pfd.md

@@ -0,0 +1,47 @@
+# Test-Case #006 - All DA nodes can submit data
+
+## Pre-Requisites:
+
+1. Every validator has enough funds in the account
+2. The chain has created the first block
+3. Every validator has enough peers
+4. Validators’ set is not changing during test execution
+   1. All validators are created during genesis
+5. DA Nodes amount is not changing during the test execution
+   1. We gracefully add DA Nodes as the first block is produced
+
+## Steps for each of the validators:
+
+1. Setups network with:
+   1. `I` mb of bandwidth
+   2. `J` milliseconds of network latency
+2. Generates and broadcasts
+   1. IP and Genesis Hash for DA Bridge nodes
+3. Checks the block size is bigger then 3.5 MiB
+
+## Steps for each of the DA nodes:
+
+1. Setups network with:
+   1. `I` mb of bandwidth
+   2. `J` milliseconds of network latency
+2. Bridge nodes connect to respective Validators
+3. Full / Light nodes connect to Bridge Nodes
+4. Checks that the latest received height is the same as for the validators
+5. Generates and broadcasts (\*) (\*\*) (\*\*\*)
+   1. `X` kb of random data
+   2. `Y` times
+
+## Data Set:
+
+| Number of Validators / Bridges / Fulls / Lights <br /> `I` |                                Bandwidth / Latency per v/b/f/l <br />`J`                                | KB of random data <br />`X` | Submit amount <br />`Y` |
+| :--------------------------------------------------------: | :-----------------------------------------------------------------------------------------------------: | :-------------------------: | :---------------------: |
+|                     40 / 40 / 20 / 100                     | 1. 256(v/b/f)-100(l)MiB / 0ms<br />2. 320(v/b/f)-100(l)MiB / 100ms<br />3. 320(v/b/f)-100(i)MiB / 200ms |             25              |           10            |
+|                   100 / 100 / 50 / 1000                    | 1. 320(v/b/f)-100(l)MiB / 0ms<br />2. 320(v/b/f)-100(l)MiB / 100ms<br />3. 320(v/b/f)-100(i)MiB / 200ms |             3.5             |           10            |
+
+## Notes:
+
+(\*) - Here All Bridge/Full/Light nodes are submitting data
+
+(\*\*) - In the future cases we explore how will the chain work if Light/Full posts data
+
+(\*\*\*) - It is also interesting to see what will happen to a chain if only 4-5 big TXs (aprox 500kb each) are submitted by light nodes

docs/test-plans/001-Big-Blocks/tp-001-big-blocks-creation-sync.md

@@ -0,0 +1,83 @@
+# Test Plan #001: Big Blocks Creation/Sync
+
+- [Test Plan #001: Big Blocks Creation/Sync](#test-plan-001-big-blocks-creationsync)
+  - [Introduction](#introduction)
+  - [In-Scope](#in-scope)
+  - [Out-of-Scope](#out-of-scope)
+  - [Risks](#risks)
+  - [Entry Conditions](#entry-conditions)
+  - [Exit Conditions](#exit-conditions)
+  - [Test Environment](#test-environment)
+  - [Notes](#notes)
+  - [Test-Cases](#test-cases)
+
+## Introduction
+
+The motivation behind this plan is to test how our stack(celestia-core/celestia-app/celestia-node) can withstand the max peak usage of the network from submitting data into our DA/Consensus Layer.
+
+## In-Scope
+
+- Max 4 MB block size
+- Celestia App Instances
+  - We are covering here only `validator` mode
+  - 40/100 validators’ set
+- Celestia Node Instances
+  - Bridge / Full / Light
+
+## Out-of-Scope
+
+- Optimint submitting data using public api or any other way
+- Syncing from a long-live chain(i.e. more then 500 block)(\*)
+- Malicious behaviour from the validators’ set
+- Withhelding the data
+- Losing/Restoring connection between peers
+- Gas fees for submitting data(\*\*)
+
+## Risks
+
+- This plan is not covering the sync time for a long-live chain, which might uncover further defects before start of incentivised testnet
+- From an economic stand point, we need to be aware of the costs that the users will bear if the block space is too scarce and how much premium should be payed to get the data included in the block
+
+## Entry Conditions
+
+- Sync between DA Network and underlying Consensus network is happening in a baseline test-case(core/app can produce empty blocks and node can sync/propagate them)(\*\*\*)
+  - e.g. not a dependency upgrade/downgrade issue in the code-base
+- Reporting of any encountered defects during execution of this test-plan
+- No blocking issues before execution of this test-plan
+
+## Exit Conditions
+
+- All In-Scope testing has been done
+- No unresolved encountered Critical or High level defects
+- Medium to Low level defects are documented in respective repos
+- Test Report is presented
+
+## Test Environment
+
+- Testground
+- K8s cluster
+- Metrics' dashboards
+
+## Notes
+
+[E2E: Celestia Network Tests](https://github.com/celestiaorg/celestia-node/issues/7)
+
+[DASing with different max block sizes](https://github.com/celestiaorg/celestia-node/issues/266)
+
+(\*) - Considering that we have 30 seconds block time and we want to test on the span of 500 blocks, the test run will be around 4 hours
+
+(\*\*) - We make an assumption that all wallets have more then enough money to cover all the costs of submitting txs
+
+## Test-Cases
+
+[Test-Case #001 - Validators submit large txs](test-cases/tc-001-val-large-txs.md)
+
+[Test-Case #002 - DA nodes are in sync with validators’ ](test-cases/tc-002-da-sync.md)
+
+[Test-Case #003 - DA nodes are syncing past headers faster then validators produce new ones](test-cases/tc-003-da-sync-past.md)
+
+[Test-Case #004 - DASing of the latest header is faster then the block production time](test-cases/tc-004-das-current.md)
+
+[Test-Case #005 - DA nodes are DASing past headers faster then validators produce new ones](test-cases/tc-005-das-past.md)
+
+[Test-Case #006 - All DA nodes can submit data ](test-cases/tc-006-da-node-pfd.md)