Die klarste Art, es zu sagen, ist dies: Auf Midnight können Sie einen Eintrag aus einer privaten Liste entfernen und trotzdem einen alten Beweis bestehen lassen.
Das war die Kraftlinie, zu der ich immer wieder zurückkam, während ich die Dokumente zu MerkleTree und HistoricMerkleTree las. Midnight sagt, dass beide bei privater Mitgliedschaft helfen können. Aber es sagt auch, dass HistoricMerkleTree.checkRoot Beweise gegen frühere Versionen des Baums akzeptieren kann. Das ist nützlich, wenn häufige Einfügungen sonst die Beweise ständig brechen würden. Es ist auch der Punkt, an dem ein privates Autorisierungssystem beginnen kann, sich von seinen aktuellen Regeln zu entfernen. Wenn Ihre App Widerruf oder Ersatz benötigt, kann ein alter Beweis weiter bestehen, nachdem die Liste bereits geändert wurde.
Das ist kein kleiner Sonderfall. Es ist eine Designentscheidung mit Konsequenzen.
Midnight's Dokumentation ist hier tatsächlich sehr klar. Ein normaler MerkleTree ermöglicht es dir, die Mitgliedschaft gegen den aktuellen Baum nachzuweisen, ohne zu offenbaren, welches Element übereinstimmt. Ein HistoricMerkleTree ist anders, weil alte Wurzeln weiterhin nutzbar bleiben können. Das gibt den Erstellern Kontinuität. Neue Einfügungen zwingen nicht automatisch alle dazu, sofort Nachweise neu zu erstellen. Für einige Produkte ist das eine echte Verbesserung. Es verhindert, dass das System bei jedem Wachstum des Baums fragil wird.
Aber derselbe Komfort wird gefährlich, sobald das Produkt von aktuellen Wahrheiten anstatt von historischen Wahrheiten abhängt.
Stell dir eine Midnight-App vor, die private Mitgliedschaft als Zugang nutzt. Vielleicht ist es eine private Erlaubenliste. Vielleicht ist es eine widerrufbare Berechtigung. Vielleicht ist es ein Recht, das verschwinden sollte, sobald ein Eintrag ersetzt wird. Der Benutzer muss nicht offenbaren, welchen genauen Eintrag er hat. Midnight kann das schützen. Gut. Aber nehmen wir an, der Ersteller wählte HistoricMerkleTree, der Eintrag wird widerrufen, und der Benutzer hält immer noch einen Nachweis von einer älteren Version des Baums. Der On-Chain-Vertrag ist nicht im gewohnten Sinne unsicher geworden. Der Nachweis kann immer noch sauber verifiziert werden. Der Fehler ist anders. Die App wollte „jetzt wahr“. Die Struktur erkennt immer noch „vorher wahr“ an.
Das ist der echte Unterschied.
Vieles in der Krypto-Schrift behandelt den Erfolg des Nachweises als das Ende des Arguments. Midnight macht das zu oberflächlich. Ein Nachweis kann gültig sein und die App kann trotzdem falsch sein. Die Kryptografie kann genau wie vorgesehen funktionieren, während die Produktregel bereits weitergezogen ist. Das ist der Grund, warum dies nicht nur eine Fußnote zum Merkle-Baum ist. Es ist ein Regel-Zeitproblem, das sich hinter einer Speicherwahl versteckt.
Die Dokumentation gibt das mehr oder weniger direkt zu. Sie sagen, dass HistoricMerkleTree nicht geeignet ist, wenn Elemente häufig entfernt oder ersetzt werden, da alte Nachweise weiterhin als gültig behandelt werden können, auch wenn sie es nicht sollten. Dieser Satz ist wichtig. Er sagt dir, dass Midnight nicht einen einzigen datenschutzfreundlichen Baum als universelle Antwort verkauft. Es sagt den Erstellern, dass sie basierend darauf wählen sollen, wie ihre Regeln altern. Wenn Nachweise Einfügungen überstehen müssen, hilft eine Struktur. Wenn Berechtigungen schnell verfallen müssen, kann dieselbe Struktur die falsche werden.
Dieser Kompromiss ist ernster, als es zunächst klingt.
Ersteller denken oft, sie wählen eine private Mengenrepräsentation. Auf Midnight wählen sie auch eine Widerrufsrichtlinie. Das ist der Teil, den viele Menschen übersehen werden. Ein HistoricMerkleTree beantwortet nicht nur die Frage „Kann ich diese Mitgliedschaft privat nachweisen?“ Es beantwortet auch die Frage „Wie viel Geschichte bin ich bereit, mit diesem Nachweis zu tragen?“ In einem einfügeintensiven System kann das klug sein. In einem widerrufsintensiven System kann es die App zu nachsichtig machen.
Und diese Kosten fallen nicht gleichmäßig aus.
Der Ersteller zahlt zuerst, weil er verstehen muss, ob seine App mehr Wert auf Nachweis-Kontinuität oder Regel-Aktualität legt. Der Prüfer zahlt als Nächstes, weil er nicht bei „dies nutzt einen privaten Mitgliedschaftsbaum“ stehen bleiben kann. Er muss fragen, welcher und welche Art von Gültigkeitsfenster es schafft. Der Benutzer oder die Gegenpartei zahlt zuletzt, weil sie möglicherweise einem privaten Autorisierungscheck vertrauen, der aktuell erscheint, während er tatsächlich ältere Zustände anerkennt.
Deshalb lese ich das nicht als abstrakte Speicherdiskussion. Ich lese es als Produktsyntax.
Midnight's Dokumentation hilft auch zu erklären, warum dies im Vergleich so wichtig ist. Gewöhnliche Hauptbuchwerte und Set-Operationen sind öffentlich, sodass sich die Ersteller in Richtung Merkle-Strukturen bewegen, wenn sie Mitgliedschaft nachweisen möchten, ohne den genauen Wert preiszugeben. Das ist der Datenschutz-Vorteil. Aber sobald du in private Mitgliedschaftsbäume übergehst, hört die Wahl nicht nur auf, das Mitglied zu verstecken. Es geht darum, ob der Nachweis der neuesten Version der Regel folgen oder an früheren Versionen verankert bleiben sollte.
Das ist der Punkt, an dem das Produkt weich werden kann, ohne kaputt auszusehen.
Meine Sicht ist jetzt direkt. Auf Midnight ist datenschutzfreundliche Mitgliedschaft nicht dasselbe wie gegenwärtige Wahrheit. Wenn ein Ersteller HistoricMerkleTree in einer widerrufsintensiven App verwendet, wählt er nicht nur eine Datenstruktur aus. Er entscheidet, dass der Nachweis von gestern weiterhin gültig sein kann, nachdem sich die Regel von heute geändert hat. Die Liste hat sich geändert. Der Nachweis ist damit nicht gestorben. Wenn die App benötigt, dass Widerruf auch Widerruf bedeutet, dann ist das nicht Eleganz. Das ist die falsche Richtlinie, die sich hinter der richtigen Kryptografie versteckt.
@MidnightNetwork $NIGHT #night
