From b9b7b7decc31ed4dbc471c41575de06d931e00fb Mon Sep 17 00:00:00 2001 From: Linus Nordberg Date: Wed, 20 Jul 2022 15:42:58 +0200 Subject: add proposal --- ...-replace-shard-hint-with-untrusted-timestamp.md | 32 ++++++++++++++++++++++ 1 file changed, 32 insertions(+) create mode 100644 doc/proposals/2022-07-replace-shard-hint-with-untrusted-timestamp.md diff --git a/doc/proposals/2022-07-replace-shard-hint-with-untrusted-timestamp.md b/doc/proposals/2022-07-replace-shard-hint-with-untrusted-timestamp.md new file mode 100644 index 0000000..aa66d5e --- /dev/null +++ b/doc/proposals/2022-07-replace-shard-hint-with-untrusted-timestamp.md @@ -0,0 +1,32 @@ +# Proposal + +Replace "shard_hint" with "untrusted_timestamp". + +A log requires untrusted_timestamp to contain an integer, seconds +since epoch, in the span [now()-24h, now()] ie which is not in the +future and not older than 24h. + +# Background + +add-leaf's "shard_hint" argument protects against entries being +"replayed" between logs, notably including between two shards of a +given log, eg MyLog2022 and MyLog2023. + +# Motivation + +- The current design with shard hint makes it possible for anyone to + replay entries in log A to log B at any time after they've been + submitted to log A (assuming the two logs are configured with + overlapping shard hint intervals). + +- Bonus: Getting rid of the name "hint" which is not very intuitive. + +# Rationale + +- One problem with replayed entries is that anyone can consume a + submitter's rate limit in another log long after it was actually + submitted. + +- Another problem with replayed entries which we do not address here + is filling up a log operators disk. This is mitigated with stricter + rate limiting, see "rate_limit". -- cgit v1.2.3