-
Notifications
You must be signed in to change notification settings - Fork 52
Logbook
Arnaud Bailly edited this page Mar 21, 2022
·
1382 revisions
This page records a log of the team’s work, thinking, discussions, pains, joys, events, and experiences that happen on a daily basis. It’s supposed to be a kind of Stream of consciousness that can later be searched, analyzed, reviewed in more formal retrospectives.
Rules:
-
Log days in reverse chronological order, recent first
-
When the stream is getting too big, such that github refuses to render do the following:
- extract biggest logical section (half-year or quarter) out of this into a correspondingly named
Logbook-Year-Hn.mdorLogbook-Year-Qn.mdpage - update links on top of this page to make it easier to navigate try to fix all links in the wiki at least
- notify the team
- extract biggest logical section (half-year or quarter) out of this into a correspondingly named
-
Move (and link) recurring sections to relevant dedicated pages (TBD).
First Session with JP, some Q&A:
- What's the role of the TestLab?
- What about the repository's organisation? It feels a bit messy right now, with lot of inconsistencies here andther
- JP should feel free to reorganise the code to be cleaner
Work from past week:
- Understanding how it works by Looking at the go node, it's interesting to see a first stab at the node, even though it's definitely not suited for production and there are quite a few problems
- Developed a simple CLI utility in rust-demo to be an easy to use executable for mithril primitives
- currently, it can "run" mithril protocol with several parties, replicating what's done in the integration tests but more configurable
- Could be the basis for a more elaborate tool to be used by SPOs without needing a full blown network
Big question: What's a "signable state" from a cardano-node?
- The node's DB might not be identical between nodes even at the same block no.
- How do we ensure all potential signers sign the same "thing"?
- We need to add stake distribution to the signed "thing" as this is part of the validity of the certificate?
How does bootstrapping would work:
- Sign certificate with genesis keys at epoch
X=> Then parties can produce signature and certificates starting from epochX + 1 - Issuing a new genesis certificate could be a "version boundary". A new genesis certificate is issued with metadata for versions, that makes it clearer when protocol changes, nodes get upgraded...
What if nodes come and go?
- Mithril nodes need Stake + Keys to produce signatures => Nodes that come within an epoch boundary need to wait next epoch
- Each epoch boundary the parameters are recomputed and redistributed to all participants
- Had a first demo integrating the monitor framework with a primitive rust-node: The test lab spins up a number of nodes (actual processes), connects them and intercepts all messages between them, and checks basic properties.
- Tried verifying a simple fault injection during registration process
- We noted it's perfectly fine to "extend" the node's API in order to make testing easier, esp. as there aren't any node right now, as long as we take care of not breaking the "black box" abstraction: The test lab should talk to the node through an API that regular clients could make sense of
- We decided to postpone next meeting till 2022-03-28 in order for everyone to have time to regroup, and think about what the next steps would look like