aboutsummaryrefslogtreecommitdiff
path: root/doc/proposals
diff options
context:
space:
mode:
authorRasmus Dahlberg <rasmus.dahlberg@kau.se>2021-11-15 11:35:34 +0100
committerRasmus Dahlberg <rasmus.dahlberg@kau.se>2021-11-15 11:35:34 +0100
commit32ee3924c528d715bf45fb135bcec6c123055aa8 (patch)
tree0e2f4b984b0150bcade9fa0c1c7dd7001b3c4ec6 /doc/proposals
parent5b2f9a7c12a74a0fb0da8e2e90a3bea1fa3ec83e (diff)
added open-ended shard interval proposal
Diffstat (limited to 'doc/proposals')
-rw-r--r--doc/proposals/2021-11-open-ended-shard-interval.md34
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.