This week we:
-
Continued upstreamimg Peras code:
- We merged Peras 61 through 66, containing the bulk of the integration workstream: changes to the extended ledger state and the HardFork combinator plumbing.
- Undrafted Peras 67: Add new Peras methods to ChainDB
- Opened Peras 68: Rewire DijkstraEra to use Peras V1 types, which depends on changes recently merged into the
cardano-ledger.
-
Continued improving the certificate size estimation, needed to avoid forging certificates that could potentially not fit inside a block body.
-
Defined a concrete, initial set of protocol parameters needed by Peras, along with an implementation draft. In addition, we documented why other parameters can’t be governable for now, and what do they depend on.
-
Continued with the investigation of historical certificate syncing through
ObjectDiffusion, and how out-of-order certs could be handled in the sliding window protocol given time-limited validation constraints. We have evaluated several competing designs, but all of them are inherently complex. We are currently evaluating if there is a formal argument to justify the correctness of a simpler design. -
In the meantime, the network team continued the adaptation of
ObjectDiffusionto indicate clearly when the client is caught-up with a distinct state (plus the corresponding state transitions). We are now updating the last remaining tests to fit the updated protocol, and will soon start internal code review. -
The historical certificates team is still working on the first prototype implementation of the
PerasImmutableCertDB, and how to transform the currentPerasCertDBinto thePerasVolatileCertDB. An initial draft should be ready soon. -
Produced an initial list of Peras implementation requirements that could help non-Haskell/alternative implementation of Cardano to implement their version of Peras.
-
The team is also actively working on considerations about Peras crypto and committee selection scheme in the light of the recent recommendations made by ARC researchers.