Ich verbringe normalerweise nicht viel Zeit damit, Dokumente zur Zahlungsarchitektur zu lesen.
Meistens überfliege ich sie, erfasse die Kernaussage und mache weiter.
Diese war anders.
Ich hatte erwartet, dass das Diagramm direkt zum Transfer führt, aber so beginnt der Ablauf.Bevor die Zahlung fortschreitet, validiert der Vertrag eine Attestation. Dieses kleine Detail hat die Art und Weise verändert, wie ich das gesamte Diagramm betrachtet habe.
Ich habe auch noch etwas anderes bemerkt. Die Dokumentation erklärt, dass der Zahlungs-Contract von NewtonPolicyClient erbt und dass die Validierung dort stattfindet, bevor der Transfer ausgeführt wird. Anstatt alles mit ein paar Marketing-Sätzen zu beschreiben, zeigt die Dokumentation tatsächlich die Abfolge zwischen dem Nutzer, dem Zahlungs-Contract, Newton AVS und der Compliance-Oracle.
Das war viel einfacher zu verfolgen.
Ein weiterer Punkt, der auffiel, ist die Notiz, dass es keinen Off-Chain-Server gibt, der im kritischen Pfad sitzt. Wenn man sich das Flussdiagramm ansieht, kann man verstehen, wo jede Komponente hineinpassen muss, ohne raten zu müssen, was als Nächstes passiert.
Ich mag Dokumentation, die ein Protokoll auf diese Weise erklärt.
Manchmal sagt mir ein einzelnes Diagramm mehr als mehrere Seiten Text, weil ich dem Prozess Schritt für Schritt folgen kann, statt mir vorstellen zu müssen, wie alles zusammenhängt.
Nachdem ich diesen Abschnitt gelesen hatte, dachte ich nicht mehr über Transaktionsgeschwindigkeit oder Token-Preis nach.
Ich habe über das Design selbst nachgedacht.
Zu sehen, wie sich Payment Contract, Policy Evaluation und Attestation zusammenfügen, hat mir die Idee viel besser verstanden lassen, als es eine reine Liste von Funktionen getan hätte.
Deshalb komme ich wahrscheinlich immer wieder zu Architektur-Seiten, wenn ich ein @NewtonProtocol lese. Dort lerne ich in der Regel am meisten.
