Skip to content

Commit

Permalink
Merge pull request #55 from Bidon15/test_plan_001
Browse files Browse the repository at this point in the history 
doc: add TP#001 for Big Blocks
  • Loading branch information
@Bidon15
Bidon15 authored Aug 29, 2022
2 parents a718cad + 2a91b87 commit 8d7d3a3
Show file tree
Hide file tree
Showing 9 changed files with 382 additions and 0 deletions.
28 changes: 28 additions & 0 deletions docs/test-plans/001-Big-Blocks/test-cases/tc-001-val-large-txs.md
View file
Original file line number Diff line number Diff line change
@@ -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 |
39 changes: 39 additions & 0 deletions docs/test-plans/001-Big-Blocks/test-cases/tc-002-da-sync.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,39 @@
# Test-Case #2 - 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. Starts syncing the chain
5. Checks 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 |
62 changes: 62 additions & 0 deletions docs/test-plans/001-Big-Blocks/test-cases/tc-003-full-sync-past.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,62 @@
# Test-Case #003 - Full 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 the DA 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
4. Check that it is synced

## Steps for each of DA Full 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
56 changes: 56 additions & 0 deletions docs/test-plans/001-Big-Blocks/test-cases/tc-004-full-light-past.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,56 @@
# Test-Case #004 - Full and Light 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 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. Light checks that it can:
1. DASes the past headers faster then new blocks are produced (\*)
6. Full checks that it can:
1. Sync the past headers 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 DAS of past headers time to have a baseline for further benchmarking of the new p2p stack that is implemented
63 changes: 63 additions & 0 deletions docs/test-plans/001-Big-Blocks/test-cases/tc-005-light-past.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,63 @@
# Test-Case #005 - Light 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 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 the DA Full 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
4. Check that it is synced

## Steps for each of DA 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 (\*)

## 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
47 changes: 47 additions & 0 deletions docs/test-plans/001-Big-Blocks/test-cases/tc-006-da-node-pfd.md
View file
Original file line number Diff line number Diff line change
@@ -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
87 changes: 87 additions & 0 deletions docs/test-plans/001-Big-Blocks/tp-001-big-blocks-creation-sync.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,87 @@
# 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 addition, this plan is covering cases where we will have different implementations of the stack(i.e. celestia-core/celestia-app/celestia-node are developed in Rust, etc.) and the plan should
be applied for them, too as we are having for current implementation(Go)

## 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
- Network Latencies / Chaos
- Chain up to 500 blocks (\*)
- Implementation of either of the stack in different language

## Out-of-Scope

- Optimint submitting data using public api or any other way
- 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 - Full nodes are syncing past headers faster then validators produce new ones](test-cases/tc-003-full-sync-past.md)

[Test-Case #004 - Full and Light nodes are syncing past headers faster then validators produce new ones](test-cases/tc-004-full-light-past.md)

[Test-Case #005 - Light nodes are DASing past headers faster then validators produce new ones](test-cases/tc-005-light-past.md)

[Test-Case #006 - All DA nodes can submit data ](test-cases/tc-006-da-node-pfd.md)
0 docs/test_plans/README.md → docs/test-plans/README.md
View file
File renamed without changes.
0 docs/test_plans/tp-template.md → docs/test-plans/tp-template.md
View file
File renamed without changes.

0 comments on commit 8d7d3a3

Please sign in to comment.