#dusk $DUSK @Dusk ......Ich erwartete, dass das Transaktionsmodell von Dusk nur eine kleinere Implementierungsdetails ist. Das tiefere Problem war schwieriger zu erkennen: Eine einzige Benutzerabsicht kann dennoch mehrere unabhängige Transaktionen erfordern....
Betrachten Sie eine Blockchain-Transaktion wie eine versiegelte Anweisung. Wenn Ihre Aktion fünf Anweisungen benötigt, bedeutet das gemeinsame Signieren nicht automatisch, dass das Netzwerk sie als eine einzige Aktion behandelt. Eine kann ausgeführt werden, während eine andere fehlschlägt.
Genau das untersucht Dusk in Issue #4058.....
Heute trägt eine Moonlight- oder Phoenix-Transaktion eine einzelne optionale TransactionData-Operation. Daher muss ein Ablauf wie approve → swap → stake auf mehrere Transaktionen aufgeteilt werden, jeweils mit eigener Signatur, eigenem Nonce und Einfüge-/Inklusionsrisiko.
Es geht noch tiefer....
Dusk erwägt eine Batch-Transaktion auf Protokollebene, die mehrere Vertragsaufrufe atomar unter der Identität des Benutzers ausführen könnte. Das würde auch ermöglichen, dass jede Operation ihren eigenen Wert oder ihr eigenes Deposit trägt, und dabei potenziell Phoenix abdecken, ohne dessen Transfer-Schaltkreis oder das vertrauenswürdige Setup zu ändern...
Aber es gibt noch einen anderen Weg.
Ein Batcher-Contract könnte mehrere Aufrufe ausführen, ohne das Protokoll zu ändern. Der Trade-off ist die Autorisierung: Verträge, die caller() verwenden, könnten den Batcher statt des ursprünglichen Benutzers sehen, während public_sender() das ursprünglich herkunftende Moonlight-Konto bewahren kann.
Dieser Unterschied hat meine Aufmerksamkeit erregt....
Der schwierige Teil beim Batchen ist nicht, mehrere Calls in einen einzigen Container zu packen. Der schwierige Teil ist festzulegen, was Identität, Gas, Wert und Fehlschlag bedeuten, wenn diese Calls zu einem einzigen Zustandsübergang werden.
Und #4058 ist noch offen – mit der tatsächlichen Implementierung und der Protokollspezifikation ausdrücklich für nachgelagerte Arbeiten offengehalten.....
Wenn eine Kette auf finanzielle Workflows abzielt: Sollte atomare Multi-Step-Ausführung zu einem Protokoll-Primitiv werden oder etwas bleiben, das Contracts selbst zusammensetzen?
$ADA $TUT
Betrachten Sie eine Blockchain-Transaktion wie eine versiegelte Anweisung. Wenn Ihre Aktion fünf Anweisungen benötigt, bedeutet das gemeinsame Signieren nicht automatisch, dass das Netzwerk sie als eine einzige Aktion behandelt. Eine kann ausgeführt werden, während eine andere fehlschlägt.
Genau das untersucht Dusk in Issue #4058.....
Heute trägt eine Moonlight- oder Phoenix-Transaktion eine einzelne optionale TransactionData-Operation. Daher muss ein Ablauf wie approve → swap → stake auf mehrere Transaktionen aufgeteilt werden, jeweils mit eigener Signatur, eigenem Nonce und Einfüge-/Inklusionsrisiko.
Es geht noch tiefer....
Dusk erwägt eine Batch-Transaktion auf Protokollebene, die mehrere Vertragsaufrufe atomar unter der Identität des Benutzers ausführen könnte. Das würde auch ermöglichen, dass jede Operation ihren eigenen Wert oder ihr eigenes Deposit trägt, und dabei potenziell Phoenix abdecken, ohne dessen Transfer-Schaltkreis oder das vertrauenswürdige Setup zu ändern...
Aber es gibt noch einen anderen Weg.
Ein Batcher-Contract könnte mehrere Aufrufe ausführen, ohne das Protokoll zu ändern. Der Trade-off ist die Autorisierung: Verträge, die caller() verwenden, könnten den Batcher statt des ursprünglichen Benutzers sehen, während public_sender() das ursprünglich herkunftende Moonlight-Konto bewahren kann.
Dieser Unterschied hat meine Aufmerksamkeit erregt....
Der schwierige Teil beim Batchen ist nicht, mehrere Calls in einen einzigen Container zu packen. Der schwierige Teil ist festzulegen, was Identität, Gas, Wert und Fehlschlag bedeuten, wenn diese Calls zu einem einzigen Zustandsübergang werden.
Und #4058 ist noch offen – mit der tatsächlichen Implementierung und der Protokollspezifikation ausdrücklich für nachgelagerte Arbeiten offengehalten.....
Wenn eine Kette auf finanzielle Workflows abzielt: Sollte atomare Multi-Step-Ausführung zu einem Protokoll-Primitiv werden oder etwas bleiben, das Contracts selbst zusammensetzen?
$ADA $TUT
