aboutsummaryrefslogtreecommitdiff
path: root/archive/2021-08-24-checkpoint-otherdata
diff options
context:
space:
mode:
Diffstat (limited to 'archive/2021-08-24-checkpoint-otherdata')
-rw-r--r--archive/2021-08-24-checkpoint-otherdata59
1 files changed, 59 insertions, 0 deletions
diff --git a/archive/2021-08-24-checkpoint-otherdata b/archive/2021-08-24-checkpoint-otherdata
new file mode 100644
index 0000000..94caca0
--- /dev/null
+++ b/archive/2021-08-24-checkpoint-otherdata
@@ -0,0 +1,59 @@
+Background
+ * The current checkpoint format leaves the [otherdata] section undefined
+ * (The format of [otherdata] is inferred from a log's unique identifier)
+
+Impact on believers
+ * None, makes sense that each ecosystem knows their own format
+
+Impact on witnesses
+ * If witnesses disregard [otherdata] while cosigning: none
+ * Otherwise: may complicate witness configuration and support for [otherdata]
+
+The problem in more detail
+ * (Let's not focus on if these extensions are good ideas or not. It's an example.)
+ * Suppose ecosystem A uses a checkpoint extension that adds a timestamp
+ * First line of otherdata: <timestamp> <diff>
+ * "A witness must only sign a checkpoint if its timestamp is in [now-diff, now]"
+ * Now ecosystem B comes along
+ * "We want timestamp verification too as in ecosystem A"
+ * "Some witnesses support that, just pass 'ecosystem A' as log metadata"
+ * (A little hacky but works)
+ * Now ecosystem C comes along
+ * "We want a timestamp as in ecosystem A and B"
+ * "We also want a secondary root hash because we operate a log-backed map"
+ * Unless witnesses change they will not understand 'ecosystem C' as log metadata
+ * This is unfortunate if witnesses actually do understand the timestamp part :<
+
+Prediction
+ * If [otherdata] catches on, each log ecosystem will do their own thing
+ * This may lead to compatibility issues like the one described above
+
+Mitigation
+ * A well-defined [otherdata] format that is generally useful would go a long way
+
+Example: an unordered key-value format
+ * Identifier: 'checkpoint key-value format'
+ * Might be communicated on the first line in [otherdata]
+ * Would affect the current checkpoint format
+ * Might be communicated as external checkpoint metadata
+ * Would not affect the current checkpoint format
+ * Would probably be good with a 'recommended usage' section though
+ * "If you want witnesses to look into [otherdata], think about X else Y"
+ * Grammar
+ * Each line is composed of <key>=<value>
+ * A line is an extension that is named <key>
+ * A key must not contain '='
+ * A line must adhere to the usual checkpoint v0 restrictions, e.g., no '\n'
+
+What we gained from this example:
+ * Witnesses that peek into [otherdata] would probably have used a common format
+ * Ecosystem A would probably have used that format to define a timestamp extension
+ * verified-timestamp=<timestamp> <diff>
+ * Ecosystem C could come along and set their [otherdata] to:
+ * map-hash=<root hash>
+ * verified-timestamp=<timestamp> <diff>
+ * Now a witness that speaks 'checkpoint key-value format' and which enforces the 'verified-timestamp' extension can do that regardless of if they know 'map-hash'
+
+Conclusion
+ * Allowing witnesses to peek into [otherdata] can get messy.
+ * We can probably avoid this mess by having a recommended or forced [otherdata] usage