path: root/design-documents/011-auditor-db-sync.rst
diff options
authorChristian Grothoff <>2021-01-04 19:25:19 +0100
committerChristian Grothoff <>2021-01-04 19:25:19 +0100
commit9b55859fa3c3c02857955546ea84a09eca4c5050 (patch)
treeb50ac35224c7268d39d56b3eec4dbc2aa67da6da /design-documents/011-auditor-db-sync.rst
parentfe16f69805aa62ff0394542a7aa43b09b9d9e65e (diff)
clarifications based on discussion with Florian
Diffstat (limited to 'design-documents/011-auditor-db-sync.rst')
1 files changed, 37 insertions, 11 deletions
diff --git a/design-documents/011-auditor-db-sync.rst b/design-documents/011-auditor-db-sync.rst
index 71d83bd..bf8f9a5 100644
--- a/design-documents/011-auditor-db-sync.rst
+++ b/design-documents/011-auditor-db-sync.rst
@@ -48,8 +48,13 @@ Requirements
tables due to a CASCADE from expired denomination keys).
* The synchronization mechanism should raise an alert if the exchange violates basic
constraints (unexpected schema changes, deletion/motification on append-only
- tables) and then NOT replicate those changes. It may then soft-fail until the
- exchange has rectified the problem.
+ tables) and then NOT replicate those changes. The auditor's internal asynchronous
+ helper may then soft-fail (log and exit) until the exchange has rectified the
+ problem (by manual, human intervention resulting in an exchange master database
+ that again maintains the required invariants).
+ After the corrected master database has been again synchronized with the
+ primary copy of the auditor, the auditor's helper is resumed and can continue to
+ copy the (now valid) database records into the auditor's internal version.
* A good solution would work independently of the specific database used.
@@ -60,24 +65,34 @@ Proposed Solution
approproate for the exchange database setup, synchronous
or asynchronous) to make a 1:1 copy of the exchange database
at the auditor. This should work for any full-featured
- modern database. The copy cannot be trusted, as constraint
+ modern database. This "ingress" copy cannot be trusted, as constraint
violations or deletions would also be replicated.
-* Use helper process to SELECT against the local copy (by
+* Use helper process to SELECT against the local "ingress" copy (by
SERIAL ID => make sure all append-only tables have one!)
- to copy append-only tables to 2nd auditor-controlled copy
- of the database. Order (or transactionally group) SELECT
+ to copy append-only tables to a second, "trusted" and fully
+ auditor-controlled copy of the database.
+ Order (or transactionally group) SELECT
statements to ensure foreign key constraints are maintained.
For mutable tables (basically, only current reserve balance)
do not make another copy, but do have logic to recompute mutable
tables from other data *if* we need to recover from backup.
* On schema migration, halt exchange, once auditor DB has
- synchronized, update all DB schema, then resume DB synchronization
- and then restart exchange.
-* For GC, simply run GC logic also on auditor's "secure" copy.
+ synchronized, update all DB schema (the "ingress" DB schema
+ may be update automatically when the exchange DB schema is
+ migrated, but the "trusted" DB of the auditor must most likely
+ be manually migrated), then finally resume "ingress" to "trusted"
+ helper-based DB synchronization and restart the exchange.
+* For GC, simply run GC logic also on auditor's "trusted" copy.
(The synchronization mechanism will take care of the primary copy,
and the helper to copy should not be disturbed by the DELETE operations
+* The auditor's "ingress" database should be well isolated from
+ the rest of the auditor's system and database
+ (different user accounts). The reason is that we should not
+ assume that the Postgres replication code is battle-tested with
+ malicious parties in mind.
+* The canonical Postgres synchronization between exchange and the
+ auditor's "ingress" database must use transport security.
@@ -114,7 +129,18 @@ Drawbacks
the order in which new entries are to be copied. It may also
be that simply running "big" transactions across all tables
is the answer, to be investigated what performs better.
+* A malicious exchange could theoretically send expensive transactions
+ to the auditor via the replication mechanism (possibly ones that
+ it did not even execute locally itself) to DoS the "ingres"
+ database. This would be noticed primarily by load
+ monitoring or even the auditor lagging unusually far behind the
+ exchange's transaction history. We believe this is acceptable,
+ as it would imply highly visible malicious exchange behavior for
+ virtually no significant gain.
+* The proposed solution does not create a transactional, synchronous
+ write-only log as suggested by CodeBlau (see audit report, Section 9.4).
+ We believe doing so would be overly costly, both in terms of
+ complexity and performance, for limited gains.
Discussion / Q&A