diff options
author | Rasmus Dahlberg <rasmus.dahlberg@kau.se> | 2021-11-15 11:35:34 +0100 |
---|---|---|
committer | Rasmus Dahlberg <rasmus.dahlberg@kau.se> | 2021-11-15 11:35:34 +0100 |
commit | 32ee3924c528d715bf45fb135bcec6c123055aa8 (patch) | |
tree | 0e2f4b984b0150bcade9fa0c1c7dd7001b3c4ec6 | |
parent | 5b2f9a7c12a74a0fb0da8e2e90a3bea1fa3ec83e (diff) |
added open-ended shard interval proposal
-rw-r--r-- | doc/proposals/2021-11-open-ended-shard-interval.md | 34 |
1 files changed, 34 insertions, 0 deletions
diff --git a/doc/proposals/2021-11-open-ended-shard-interval.md b/doc/proposals/2021-11-open-ended-shard-interval.md new file mode 100644 index 0000000..0cdc339 --- /dev/null +++ b/doc/proposals/2021-11-open-ended-shard-interval.md @@ -0,0 +1,34 @@ +# Open-ended shard interval +We would like to remove `shard_end` from a log's static metadata, and instead +have an open-ended shard-interval. An open-ended shard interval allows an +operator to continue its log operations without starting a new log unless it +really necessary. This should make it easier to maintain lists of known logs. + +## Details +An operator defines how long they intend to run a log at minimum. The log +operator may increase this time later on but should not decrease it. The log +operator should give an account for how they plan to achieve said operations, +and possibly under which circumstances they will (not) extend a log's lifetime. + +So, `shard_end` is not fixed and instead closely related to log policy. + +For a log to accept a submission, the submitted leaf must fit into the log's +shard interval. This interval is open-ended: `[shard_start, now()]`. + +By still having a shard interval, it is possible for a new log to protect itself +from replayed leaves that were logged in a different log before `shard_start`. + +A signer can set `shard_hint` to + + max([ shard_start for shard_start in list_of_active_logs ]) + +to ensure that logging requests can be performed in all active logs. + +We think that this setup could work with hard-coded, manually adjusted, and +dynamically adjusted log policies; all with different trade-offs of course. + +## Other +- We need to create a best practise document for log operations. It would also +be helpful for verifiers to assess if it is a good idea to rely on a log. +- We should probably define an error that indicates that a log was toggled into +read-only mode, in preparation of a complete shutdown. |