ich bin aufgewachsen, während ich meinen Vater beobachtete, wie er ein kleines Importgeschäft führte und nebenbei mit BITCOIN und GOLD handelte, und ehrlich gesagt war das, was mir am meisten im Gedächtnis geblieben ist, nicht die Produkte oder die Margen, sondern die Papierarbeit 😂
jede Zahlung hatte Bedingungen. Zahlung bei Lieferung. Zahlung, wenn das Inspektionszertifikat eintrifft. Zahlung dreißig Tage nach der Zollabfertigung der Waren. Das Geld war immer bereit. Die Frage war immer, ob die Bedingung erfüllt war. Und die Hälfte der Streitigkeiten in seinem Geschäft betraf nicht, ob jemand etwas schuldete.
sie drehten sich darum, ob die Bedingung bereits erfüllt war.
ich habe diese Zahlungsstreitigkeiten diese Woche durchgelesen, während ich durch die rCBDC programmierbaren Geldmechaniken im SIGN-Stack gelesen habe. Denn das Design versucht genau, dieses Problem zu automatisieren. Und der Ort, an dem es wirklich kompliziert wird, ist der gleiche Ort, an dem die Streitigkeiten meines Vaters immer begonnen haben.
Was das Design erreichen will:
die Einzelhandels-CBDC in der SIGN-Architektur unterstützt programmierbare Zahlungen auf der Token-Ebene selbst. nicht auf einer Anwendungsebene, die über der Währung sitzt. innerhalb der Token-Operationen.
zeitverriegelte Übertragungen geben Gelder zu einem festgelegten Zeitpunkt ohne erforderlichen externen Auslöser frei
wiederkehrende Zahlungen werden automatisch nach einem festgelegten Zeitplan ausgeführt. Konformitätszertifizierungen können als Bedingungen eingebettet werden, eine Übertragung wird nur abgeschlossen, wenn eine spezifische Zertifizierung vorhanden und gültig ist. Mehrfachsignaturanforderungen können eine Übertragung blockieren, sodass mehr als eine autorisierte Partei zustimmen muss, bevor Gelder bewegt werden.
die Programmierbarkeit befindet sich im Fabric Token SDK unter Verwendung des UTXO-Modells. Jede ungenutzte Ausgabe kann Bedingungen tragen. Die Bedingungen werden ausgewertet, wenn die Ausgabe verbraucht wird. Ein Token, das eine Zeitverriegelungsbedingung trägt, kann nicht ausgegeben werden, bevor die Sperre abläuft, unabhängig davon, was ein Teilnehmer möchte.
die Durchsetzung erfolgt auf Protokollebene
nicht abhängig von einer Partei, die eine Vereinbarung einhält.
das ist wirklich mächtig für ein souveränes Zahlungssystem. Sozialleistungen, die vor einem festgelegten Freigabedatum nicht umgeleitet werden können. Landwirtschaftliche Subventionen, die einen Landwirt nur nach einem verifizierten Lieferereignis erreichen. Konformitätsprüfungen, die in die Zahlung selbst eingebettet sind, anstatt als separater Prozess oben drauf zu sein.
Der Teil, der meiner Meinung nach unterbewertet wird:
die Automatisierung von Konformität innerhalb des Tokens ist die Designentscheidung, die am meisten verändert, was souveräne Zahlungen tun können
heute verteilt eine Regierung eine Leistung und hofft, dass nachgelagerte Konformitätsprüfungen Missbrauch aufdecken. Mit programmierbaren Bedingungen reist die Konformitätsanforderung mit dem Geld. Die Zahlung und die Regel, die die Zahlung regelt, sind dasselbe Objekt.
geografische Einschränkungen bedeuten, dass ein Verteilungstoken so konstruiert werden kann, dass es nur innerhalb einer definierten Region ausgegeben werden kann. Nutzungsbeschränkungen bedeuten, dass ein Subventionstoken für landwirtschaftliche Inputs nicht für nicht verwandte Käufe umgeleitet werden kann. Vesting-Programme bedeuten, dass langfristige Leistungsprogramme automatisch in Phasen freigegeben werden, ohne dass bei jedem Freigabeereignis manuelles Eingreifen erforderlich ist.
jeder dieser Punkte ist ein politische Ziel, das derzeit administrative Aufwendungen erfordert, um nach der Zahlung durchgesetzt zu werden
die Verlagerung der Durchsetzung in das Token selbst ist architektonisch die richtige Richtung.
Wo ich jedoch immer wieder stecken bleibe:
programmierbare Bedingungen, die auf den On-Chain-Zustand verweisen, sind klar. eine Zeitverriegelung ist selbstgenügsam. eine Mehrfachsignaturanforderung ist selbstgenügsam. die Bedingung und die Daten, die zur Bewertung benötigt werden, befinden sich beide im System.
programmierbare Bedingungen, die auf den Off-Chain-Zustand verweisen, sind nicht auf die gleiche Weise klar.
eine Bedingung für die Konformitätszertifizierung erfordert, dass das Token überprüft, dass eine spezifische Zertifizierung existiert und zum Zeitpunkt der Ausführung gültig ist. Wenn diese Zertifizierung im Sign Protocol-Register vorhanden ist und das Register zum Zeitpunkt der Ausführung der Übertragung abfragbar ist, wird die Bedingung korrekt gelöst.
aber wenn das Zertifizierungsregister zum Zeitpunkt der Ausführung nicht verfügbar ist, steht das Token vor einer Wahl, die die Dokumentation nicht löst. trotzdem ausführen und die Konformitätsbedingung ignorieren, was den Zweck der Einbettung zunichte macht. unbestimmt warten, bis das Register verfügbar wird, was bedeutet, dass eine Bürgerzahlung durch eine Infrastrukturabhängigkeit eingefroren wird, über die der Bürger keine Sichtbarkeit oder Kontrolle hat. fehlschlagen und die Gelder zurückgeben, was einen definierten Fehler-Modus erfordert, den die Spezifikation für programmierbare Zahlungen nicht beschreibt.
dies ist je nach Bedingungstyp unterschiedlich wichtig
ein Zeitverriegelungsfehler-Modus ist offensichtlich
ein Fehler-Modus bei der Konformitätszertifizierung ist es nicht.
für souveräne Infrastrukturen, die Sozialleistungen, landwirtschaftliche Subventionen und Gesundheitsleistungen an Bürger verteilen, ist eine programmierbare Bedingung, die stillschweigend stockt oder fehlschlägt, weil ein externes Register kurzzeitig nicht verfügbar war, kein Randfall, der später behandelt werden kann. Es ist der Fehler-Modus, der das Vertrauen in das gesamte System beim ersten Mal, dass es in großem Maßstab passiert, untergräbt.
ehrlich gesagt weiß ich nicht, ob die programmierbaren Geldmechaniken innerhalb der Token-Ebene die richtige Architektur für souveräne bedingte Zahlungen darstellen oder ob die Einbettung von Off-Chain-Bedingungsabhängigkeiten in irreversible Token-Operationen eine Fehleroberfläche schafft, die das Design noch nicht vollständig erfasst hat?? 🤔
\u003ct-24/\u003e\u003cm-25/\u003e\u003cc-26/\u003e
