Skip to content

Commit f819cf5

Browse files
rkuhnrkuhn
committed
add simulation-model-parameters.{json,md} content
1 parent b0f8631 commit f819cf5

File tree

3 files changed

+277
-26
lines changed

3 files changed

+277
-26
lines changed

‎.DS_Store

6 KB
Binary file not shown.

‎docs/simulation-model-parameters.json

+71
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,71 @@
1+
{
2+
"network": {
3+
"announcement_size": null,
4+
"data_request_size": null,
5+
"Txn_size": null,
6+
"Txn_reserved_bandwidth": null,
7+
"IB_header_size": null,
8+
"IB_body_size": null,
9+
"EB_header_size": null,
10+
"EB_body_size": null,
11+
"EB_vote_size": null,
12+
"Leios_reserved_bandwidth": null,
13+
"RB_size": null,
14+
"Praos_reserved_bandwidth": null
15+
},
16+
"net_model": {
17+
"topology": {
18+
"size": 2500,
19+
"avg_degree": 15,
20+
"cluster_coeff": 0.07,
21+
"block_producers": 500
22+
},
23+
"simple": {
24+
"short": {
25+
"small": 0.012,
26+
"midsize": 0.024,
27+
"large": 0.078
28+
},
29+
"medium": {
30+
"small": 0.069,
31+
"midsize": 0.143,
32+
"large": 0.404
33+
},
34+
"long": {
35+
"small": 0.268,
36+
"midsize": 0.531,
37+
"large": 1.598
38+
}
39+
}
40+
},
41+
"computation": {
42+
"Txn_validation_latency": null,
43+
"Txn_validation_intensity": null,
44+
"VRF_lottery_latency": null,
45+
"VRF_lottery_intensity": null,
46+
"IB_creation_latency": null,
47+
"IB_creation_intensity": null,
48+
"IB_validation_latency": null,
49+
"IB_validation_intensity": null,
50+
"EB_creation_latency": null,
51+
"EB_creation_intensity": null,
52+
"EB_validation_latency": null,
53+
"EB_validation_intensity": null,
54+
"EB_vote_creation_latency": null,
55+
"EB_vote_creation_intensity": null,
56+
"EB_vote_validation_latency": null,
57+
"EB_vote_validation_intensity": null,
58+
"RB_creation_latency": null,
59+
"RB_creation_intensity": null
60+
},
61+
"storage": {
62+
"Txn_store_delay": null,
63+
"IB_store_delay": null,
64+
"EB_store_delay": null,
65+
"EB_vote_store_delay": null,
66+
"RB_store_delay": null,
67+
"Ledger_store_delay": null,
68+
"Ledger_update_delay": null,
69+
"Txn_prune_delay": null
70+
}
71+
}

‎docs/simulation-model-parameters.md

+206-26
Original file line numberDiff line numberDiff line change
@@ -3,6 +3,14 @@
33
This document attempts to provide an overview and a reference of all relevant system parameters for analyzing, simulating, or prototyping the Leios protocol on top of Ouroboros Praos.
44
The Leios protocol has several open design choices and free parameters that will need to be fixed before proposing its production implementation, which is the reason for performing the aforementioned analyses and tests.
55

6+
The referenced parameters themselves are presented in machine-readable form in [simulation-model-parameters.json](simulation-model-parameters.json).
7+
Each parameter is given in the natural unit corresponding to its nature:
8+
9+
- sizes are given in bytes
10+
- durations, delays, and latencies are given in seconds
11+
- bandwidths are given in bytes per second
12+
- CPU intensities are given in standard CPU core equivalents
13+
614
## Node roles and their activities
715

816
In this section we look at the participants of the Ouroboros Leios network to enumerate the relevant activities that they are expected to perform.
@@ -13,36 +21,37 @@ We then characterise said activities in the next section.
1321
Block producers form the backbone of the Cardano network as they provide the actual functionality and thus create the value of the whole enterprise.
1422
Their activities are:
1523

16-
- reception of transactions from the relays
24+
- reception of transactions
1725
- storing of transactions in the mempool
1826
- validating of transactions against the latest ledger state
1927
- executing the VRF lotteries for input blocks, endorser blocks, and ranking blocks
2028
- creating input blocks
2129
- storing input blocks
22-
- sending input blocks to the relays
23-
- receiving input blocks from the relays
30+
- sending input blocks
31+
- receiving input blocks
2432
- validating input blocks
2533
- creating endorser blocks
2634
- storing endorser blocks
27-
- sending endorser blocks to the relays
28-
- receiving endorser blocks from the relays
35+
- sending endorser blocks
36+
- receiving endorser blocks
2937
- validating endorser blocks
3038
- computing EB votes
31-
- sending EB votes to relays
32-
- receiving EB votes from relays
39+
- sending EB votes
40+
- receiving EB votes
3341
- validating EB votes
3442
- creating ranking blocks
3543
- storing ranking blocks
36-
- sending ranking blocks to the relays
37-
- receiving ranking blocks from the relays
44+
- sending ranking blocks
45+
- receiving ranking blocks
3846
- validating ranking blocks
3947
- updating the ledger state upon chain head change
4048
- storing ledger state
4149
- removing transactions from the mempool
4250

4351
### Relay
4452

45-
*TODO*
53+
Relays are typically used to shield a block producer from the internet, acting as an application layer gateway within a demilitarised network zone.
54+
Technically, a relay is identical to a block producer that holds no stake, which means that it performs all the same activities as a block producer apart from those that create data (like blocks, votes, or transactions).
4655

4756
### Client
4857

@@ -51,34 +60,205 @@ Their activities are:
5160
## Network activities
5261

5362
This section gathers all network-based activities from the per-role sections above and discusses their structure as well as relevant parameters.
63+
The parameters referenced below are found under `network/` in the JSON file.
5464

55-
### sending a ranking block to a node
65+
### reception of transactions
5666

57-
This action is a two-step process where the recipient asks for the block by sending a request to the sender, who will then transfer either the block or an error response back to the recipient.
58-
Note the inversion of control here, which is deliberate to implement strict flow control on the network: a node manages its own ingress traffic by asking for blocks to be sent to it.
67+
Relays and block producers receive transactions that originate from clients and are diffused across the network.
68+
This process is initiated by a node when it has a new transaction available by announcing it to its peers, but those peers control the transfer of the transaction data by requesting it when they are ready to receive and process it (which depends among others on whether there is room in their mempools).
5969

6070
relevant parameters:
6171

62-
- request size: XXX B
63-
- block size: XXX kiB
64-
- latency distribution: (depends on how we want to slice it)
65-
- CPU usage at block sender: (some profile over time)
66-
- memory usage at block sender: (some profile over time)
72+
- `announcement_size`
73+
- `data_request_size`
74+
- `Txn_size`
75+
- `Txn_reserved_bandwidth`
6776

68-
### receiving a ranking block at a node
77+
### sending an input block from node to node
6978

70-
*TODO*
79+
This action is a five-step process which the sender initiates by announcing the availability by sending a hash.
80+
The recipient may then decide to request the block header (if it doesn’t yet have it), which is subsequently transferred back.
81+
Based on the header contents the recipient may decide to request the block data, which is subsequently transferred back.
82+
The last request–reply pair is governed by the “freshest first” traffic shaping policy in the Leios network, with freshness (and validity) being judged based on the header contents.
83+
84+
relevant parameters:
85+
86+
- `announcement_size`
87+
- `data_request_size`
88+
- `IB_header_size`
89+
- `IB_body_size`
90+
- `Leios_reserved_bandwidth`
91+
92+
### sending an endorser block from node to node
93+
94+
This action is a five-step process which the sender initiates by announcing the availability by sending a hash.
95+
The recipient may then decide to request the block header (if it doesn’t yet have it), which is subsequently transferred back.
96+
Based on the header contents the recipient may decide to request the block data, which is subsequently transferred back.
97+
The last request–reply pair is governed by the “freshest first” traffic shaping policy in the Leios network, with freshness (and validity) being judged based on the header contents.
98+
99+
relevant parameters:
100+
101+
- `announcement_size`
102+
- `data_request_size`
103+
- `EB_header_size`
104+
- `EB_body_size`
105+
- `Leios_reserved_bandwidth`
106+
107+
### sending an EB vote from node to node
108+
109+
This process is initiated by a node when it has a new vote available by announcing it to its peers, but those peers control the transfer of the vote data by requesting it when they are ready to receive and process it.
110+
111+
relevant parameters:
112+
113+
- `announcement_size`
114+
- `data_request_size`
115+
- `EB_vote_size`
116+
- `Leios_reserved_bandwidth`
117+
118+
### sending a ranking block from node to node
119+
120+
This action is a three-step process where the sender announces the availability by sending a hash, the recipient asks for the block by sending a request to the sender, who will then transfer either the block or an error response back to the recipient.
121+
Note the inversion of control here for the main data transfer, which is deliberate to implement strict flow control on the network: a node manages its own ingress traffic by asking for blocks to be sent to it.
122+
123+
relevant parameters:
124+
125+
- `announcement_size`
126+
- `data_request_size`
127+
- `RB_size`
128+
- `Praos_reserved_bandwidth`
129+
130+
## Network properties
131+
132+
While the section above describes how nodes intend to use the network, this section describes how the network responds to those intents.
133+
134+
### Topology
135+
136+
The statistical model of the network has been fitted to the observed block diffusion times within the Peras investigation using as basis a random graph modified by an average local cluster coefficient.
137+
The corresponding parameters are found under `net_model/topology/` in the JSON file.
138+
139+
That section also contains the network size as well as the number of block producers; these can be used to compute e.g. the stake per producer according to some chosen distribution.
140+
141+
### Simplified model
142+
143+
The simplified model used so far for initial analyses has been taken from the [Peras Technical Report 1](https://peras.cardano-scaling.org/docs/reports/tech-report-1/#certificates-in-block-header).
144+
It classifies inter-node connections as short/medium/long range and regards data of classes small (1500B)/midsize (64kB)/large (1MB).
145+
The respective network latencies are found under `net_model/simple/` in the JSON file.
146+
147+
## Computation activities
148+
149+
This section gathers all computations from the per-role sections above that happen locally to a node.
150+
In this context, “intensity” refers to a CPU utilization metric that at this point still remains to be defined.
151+
The parameters referenced below are found under `computation/` in the JSON file.
152+
153+
### validating a transaction
154+
155+
A transaction is validated both syntactically and semantically, where the latter requires a ledger state to ascertain that all inputs are still available.
156+
157+
relevant parameters:
158+
159+
- `Txn_validation_latency`
160+
- `Txn_validation_intensity`
161+
162+
### executing VRF lottery
163+
164+
Whenever a block producer may be allowed to create something, it runs a VRF lottery to discover whether it shall actually do so.
165+
166+
relevant parameters:
167+
168+
- `VRF_lottery_latency`
169+
- `VRF_lottery_intensity`
71170

72-
## Local activities
171+
### creating an input block
73172

74-
This section gathers all activities from the per-role sections above that happen locally to a node.
173+
When a node wins the VRF lottery for IB creation it will assemble transactions from its mempool and create an IB containing them.
174+
175+
relevant parameters:
176+
177+
- `IB_creation_latency`
178+
- `IB_creation_intensity`
179+
180+
### validating an input block
181+
182+
Validating an IB validates the contained transactions for validity (but it isn’t yet clear to me against which ledger state).
183+
184+
relevant parameters:
185+
186+
- `IB_validation_latency`
187+
- `IB_validation_intensity`
188+
189+
### creating an endorser block
190+
191+
When a node wins the VRF lottery for EB creation it will create an EB referencing all valid IBs it has received for the pipeline that is currently in the endorse phase.
192+
193+
relevant parameters:
194+
195+
- `EB_creation_latency`
196+
- `EB_creation_intensity`
197+
198+
### validating an endorser block
199+
200+
Validating an EB validates the referenced IB and their contained transactions for validity (but it isn’t yet clear to me against which ledger state).
201+
202+
relevant parameters:
203+
204+
- `EB_validation_latency`
205+
- `EB_validation_intensity`
206+
207+
### creating an EB vote
208+
209+
For a pipeline in the voting phase a node may create a certificate for an EB it has seen and validated.
210+
211+
relevant parameters:
212+
213+
- `EB_vote_creation_latency`
214+
- `EB_vote_creation_intensity`
215+
216+
### validating an EB vote
217+
218+
The vote is validated syntactically and semantically by verifying the availability and correctness of its block references and signatures.
219+
220+
relevant parameters:
221+
222+
- `EB_vote_validation_latency`
223+
- `EB_vote_validation_intensity`
224+
225+
### creating a ranking block
226+
227+
A node that has seen enough votes for an EB and has won the Praos VRF lottery may create a certificate for the EB and place it within a newly minted ranking block.
228+
229+
relevant parameters:
230+
231+
- `RB_creation_delay`
232+
- `RB_creation_intensity`
75233

76234
### validating a ranking block
77235

78-
*precise description to be done*
236+
Praos blocks are validated syntactically and semantically against the latest ledger state as they diffuse across the network.
237+
238+
relevant parameters:
239+
240+
- `RB_validation_delay`
241+
- `RB_validation_intensity`
242+
243+
### updating the ledger
244+
245+
Whenever a new longest chain is found, the ledger state is computed for this chain, expanding each Praos block potentially into EBs and in turn into IBs to extract transactions.
79246

80247
relevant parameters:
81248

82-
- CPU usage: (some time profile in useful units)
83-
- latency distribution: (some profile over time)
84-
- memory usage: (some profile over time)
249+
- `Ledger_update_intensity`
250+
- `Ledger_update_delay`
251+
252+
## Storage activities
253+
254+
This section lists all parameters related to storage activities, where the mempool is considered as a storage arena.
255+
The parameters referenced below are found under `storage/` in the JSON file.
256+
257+
- `Txn_store_delay` is the duration it takes to add a transaction to the mempool
258+
- `IB_store_delay` is the duration it takes to store an input block on disk and update indexes
259+
- `EB_store_delay` is the duration it takes to store an endorser block on disk and update indexes
260+
- `EB_vote_store_delay` is the duration it takes to store an EB vote on disk and update indexes
261+
- `RB_store_delay` is the duration it takes to store a Praos block on disk and update indexes
262+
- `Ledger_store_delay` is the duration it takes to store a ledger snapshot on disk
263+
- `Ledger_update_delay` is the duration it takes to compute and make available in memory a new ledger snapshot by applying an RB to the preceding ledger state
264+
- `Txn_prune_delay` is the duration it takes to remove transactions referenced by a Praos block from the mempool

0 commit comments

Comments
 (0)