Jun 5, 2024

It's been a little slow this past, with my son visiting from school. I've implemented confirmations by the downloading protocols when under checkpoint/milestone, so that confirmations are written in parallel. Otherwise this adds about 10 minutes to the run. I've also implemented a generalized determination of combined checkpoint/milestone (bypass) height by the organizer, which is then broadcasted to the validation and confirmation chasers. This allows them to track and switch modes at almost no cost. However, the block_in protocol also requires this information, but as protocols are many and come and go constantly with channels, it's not possible to initialize the bypass height at startup as with the others. So I'm working on an efficient mechanism for this. One might assume that they could simply initialize active milestone height from the store at startup, but this presents two problems: (1) the query is a cost (though very small), and (2) the organizer controls the candidate chain, to which milestones are relative. Checkpoints on the other hand are assured by header validation, so those are trivial. The issue then is how to ensure proper ordering of the milestone to the protocol. I implemented this as a relay, where the protocol requests it at startup and the organizer responds with the corresponding message. However the need to delay the protocol during this communication relay costs about 20 minutes over a full run. So still looking at it.