#dusk $DUSK @Dusk
Als ich Zedgers Transfer-Logik durchging, blieb mir eine Regel besonders im Kopf: Der Empfänger muss einen Transfer genehmigen, bevor er sich erfüllt. Nicht die Person, die ihn sendet. Sondern die Person auf der anderen Seite.
Ich war davon ausgegangen, dass ein Transfer einfach durchläuft, sobald er initiiert wurde—so wie es bei den meisten Kontomodellen funktioniert. Zedger macht das nicht. Bis zur Zustimmung wird der Saldo weiterhin auf der Seite des Absenders mitgezählt. Es gibt einen CLAIM-Pfad, falls die Genehmigung nie kommt, bevor der Transfer abläuft. Das sagt mir, dass dieser Status „ausstehend“ so vorgesehen ist und nicht nur eine seltene Ausnahme.
Stell es dir einfach vor. Jemand hält einen Teil einer tokenisierten Anleihe über ein Setup wie NPEX. Er initiiert einen Transfer an ein anderes zugelassenes Konto. Der Empfänger hat noch nicht akzeptiert. Wenn man also in genau diesem Moment den Besitz prüft, würde hypothetisch immer noch der ursprüngliche Inhaber angezeigt, weil auf Zedgers Seite noch nichts finalisiert wurde.
Das Seltsame ist nicht, dass es einen ausstehenden Status gibt. Sondern, dass Zedger ansonsten sehr präzise ist: ein Konto pro zugelassenem Nutzer, eine vollständige Historie jeder Saldenänderung, ohne Mehrdeutigkeit in Bezug auf die Vergangenheit. Aber der aktuelle Besitz kann für eine gewisse Zeit bewusst ungeklärt bleiben—aus Designgründen—weil der Empfänger tatsächlich die Entscheidung treffen muss, es zu akzeptieren.
Ich halte das nicht für einen Fehler. Die Anforderung zur Akzeptanz statt einer automatischen Abwicklung dürfte einem zugelassenen Vertragspartner die Möglichkeit geben, ein Asset abzulehnen, anstatt dass es einfach in sein Konto „gezwungen“ wird. Aber es bedeutet auch: Wenn zwei Personen denselben Transfer zur gleichen Zeit prüfen, bevor die Genehmigung erfolgt ist, würden sie unterschiedliche Antworten darüber sehen, wer ihn aktuell besitzt.
Das Whitepaper ist konkret bezüglich des Mechanismus. Es sagt nichts darüber, wie oft diese Lücke tatsächlich getestet wird, sobald echte Settlement-Aktivität im Spiel ist.
Ist dieses Zeitfenster im ausstehenden Zustand etwas, das Operatoren selten antreffen, oder ist es ein Zustand, den sie ständig managen müssen, sobald das Transfervolumen anzieht?
$BTC $TUT
Als ich Zedgers Transfer-Logik durchging, blieb mir eine Regel besonders im Kopf: Der Empfänger muss einen Transfer genehmigen, bevor er sich erfüllt. Nicht die Person, die ihn sendet. Sondern die Person auf der anderen Seite.
Ich war davon ausgegangen, dass ein Transfer einfach durchläuft, sobald er initiiert wurde—so wie es bei den meisten Kontomodellen funktioniert. Zedger macht das nicht. Bis zur Zustimmung wird der Saldo weiterhin auf der Seite des Absenders mitgezählt. Es gibt einen CLAIM-Pfad, falls die Genehmigung nie kommt, bevor der Transfer abläuft. Das sagt mir, dass dieser Status „ausstehend“ so vorgesehen ist und nicht nur eine seltene Ausnahme.
Stell es dir einfach vor. Jemand hält einen Teil einer tokenisierten Anleihe über ein Setup wie NPEX. Er initiiert einen Transfer an ein anderes zugelassenes Konto. Der Empfänger hat noch nicht akzeptiert. Wenn man also in genau diesem Moment den Besitz prüft, würde hypothetisch immer noch der ursprüngliche Inhaber angezeigt, weil auf Zedgers Seite noch nichts finalisiert wurde.
Das Seltsame ist nicht, dass es einen ausstehenden Status gibt. Sondern, dass Zedger ansonsten sehr präzise ist: ein Konto pro zugelassenem Nutzer, eine vollständige Historie jeder Saldenänderung, ohne Mehrdeutigkeit in Bezug auf die Vergangenheit. Aber der aktuelle Besitz kann für eine gewisse Zeit bewusst ungeklärt bleiben—aus Designgründen—weil der Empfänger tatsächlich die Entscheidung treffen muss, es zu akzeptieren.
Ich halte das nicht für einen Fehler. Die Anforderung zur Akzeptanz statt einer automatischen Abwicklung dürfte einem zugelassenen Vertragspartner die Möglichkeit geben, ein Asset abzulehnen, anstatt dass es einfach in sein Konto „gezwungen“ wird. Aber es bedeutet auch: Wenn zwei Personen denselben Transfer zur gleichen Zeit prüfen, bevor die Genehmigung erfolgt ist, würden sie unterschiedliche Antworten darüber sehen, wer ihn aktuell besitzt.
Das Whitepaper ist konkret bezüglich des Mechanismus. Es sagt nichts darüber, wie oft diese Lücke tatsächlich getestet wird, sobald echte Settlement-Aktivität im Spiel ist.
Ist dieses Zeitfenster im ausstehenden Zustand etwas, das Operatoren selten antreffen, oder ist es ein Zustand, den sie ständig managen müssen, sobald das Transfervolumen anzieht?
$BTC $TUT
