You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: Logbook.md
+96
Original file line number
Diff line number
Diff line change
@@ -1,11 +1,107 @@
1
1
# Leios logbook
2
2
3
+
## 2024-12-13
4
+
5
+
### Haskell simulation
6
+
7
+
- Merged leios visualizations on `main`.
8
+
- P2P visualization improvements:
9
+
* Block types are differentiated by shapes, and pipelines by color.
10
+
* Charting diffusion latency of each block type.
11
+
* TODO: chart CPU usage.
12
+
- Reworked generation of EBs and Votes to handle `>= 1` frequencies
13
+
like IBs (except max 1 EB per pipeline per node).
14
+
- Visualizations helped with discovering and fixing some modeling errors.
15
+
16
+
## 2024-12-12
17
+
18
+
### Analysis of vote size and ALBA certificates
19
+
20
+
Keeping votes small is critical to having certificates that fit on a Praos ranking block. In the [draft technical report](docs/technical-report-1.md#structure-of-votes) we have estimated the minimum possible size for votes using either ephemeral keys or KES:
21
+
22
+
| Method | Common to all votes for a given EB | Specific to individual vote | Total |
The KES votes are a challenge for ALBA because they would require a 90% quorum, meaning that an adversary with more than 10% of the stake could prevent voting.
28
+
29
+
The CPU time estimate that we have benchmarked for the "centralized telescope" version of ALBA are favorable, however:
30
+
31
+
- Prove: 9.0 ms
32
+
- Verify: 85 μs
33
+
34
+
### Review Session 1 - Formal Specification
35
+
36
+
Team reviewed formal specification and further provided input for improvements.
37
+
38
+
### Rust simulation
39
+
40
+
Merged virtual time branch. The rust simulation logic is now decoupled from wall clock time.
41
+
42
+
Experimented with using netsim for the networking layer again. It works, but we currently have to simulate network activity 1ms at a time, making the simulation slow. Waiting for the netsim API to expose a "lower bound" of how long to wait until another message will arrive.
43
+
44
+
## 2024-12-11
45
+
46
+
### Discussion with IOG SRE for nodes
47
+
48
+
We met with IOG's SRE for node operations to discuss cloud engineering aspects of the current Cardano node deployments that might be relevant for Leios.
49
+
50
+
- We have information now about what VM sizes are for nodes and each relay.
51
+
- We also have access to the grafana dashboards for examining mainnet and other nodes.
52
+
- They've created custom grafana queries so we can see I/O, network, and disk usage.
53
+
54
+
Recommendations:
55
+
56
+
1. Update the cost calculator so that it has pre-defined cost defaults for several cases such as on-demand VMs, bare metal, etc.
57
+
2. Alter the cost calculator to include a specified amount of "free" IOPS and network egress that are included with the selected base VM and/or disks.
58
+
3. Compare the Praos telemetry on IOG's mainnet nodes to the output of the cost calculator when Leios is turned off.
59
+
60
+
## 2024-12-10
61
+
62
+
### Threat model
63
+
64
+
The technical report now contains a draft section on [the Leios threat mode](docs/technical-report-1.md#threat-model) detailing 25 hypothetical threats. The general types are . . .
65
+
66
+
- Grinding the VRF to obtain an advantage in Leios sortition
67
+
- Equivocating IBs, EBs, or RBs
68
+
- Declining to create IBs, EBs, or votes
69
+
- Manipulating the content of IBs or EBs
70
+
- Sending invalid txs, IBs, EBs, or certificates
71
+
- Abusing the sync protocol
72
+
- Delaying diffusion of IBs, EBs, or votes
73
+
- Submitting invalid, conflicting, or duplicate txs
74
+
75
+
The protocol already fully or partially mitigates many of these, but they are listed for completeness and eventual discussion in the Leios CIP. Others are a subject of ongoing research.
76
+
77
+
The general impact of such attacks varies:
78
+
79
+
- Resource burden on nodes
80
+
- Lower throughput
81
+
- Increased latency
82
+
- Manipulation of dapps or oracles
83
+
84
+
### Summary of mainnet data available
85
+
86
+
-[These slides](https://docs.google.com/presentation/d/1Iy2Vu3jZMsHFrvqmiM8urK9EVXbYJW0knb5XQ7w2tZE/edit?usp=sharing) summarize data we have available for topology, block propagation, transaction delays, etc.
87
+
- Will can reformat data we need for our simulations, so we don't end up with inconsistent input data sets.
88
+
- We will use the [beta-distribution fit](docs/technical-report-1.md#stake-distribution) for representing the unevenness of the stake distribution in our simulations.
89
+
90
+
91
+
### Rust simulation
92
+
93
+
Generated new test data set to match geographical distribution of mainnet nodes. In this dataset, nodes belong to a region (and have an explicit region tag) and are physically clustered near other nodes in that region.
94
+
3
95
## 2024-12-09
4
96
5
97
### Nix development environment
6
98
7
99
We previously had a `nix develop` environment for the Haskell simulation, but this was removed as the Haskell package evolved. Instead of re-nixifying this repository, I created a separate [ouroboros-leios.env](https://github.com/functionally/ouroboros-leios.env) repository where one can open a `nix develop` with the correct Haskell compiler and dependencies.
8
100
101
+
### Rust simulation
102
+
103
+
Roland has written a fully virtual clock. When finished, this will decouple the sim's performance from the wall clock, and ensure traffic timings are still correct even when there are too many messages to simulate in real time.
0 commit comments