Das gefährlichste Ergebnis ist nicht unbedingt, dass sich Knoten gegenseitig bekämpfen, sondern dass alle Knoten dieselbe Menge an Verifikationscode aufrufen und dann sauber und ordentlich einen Fehler prüfen.
Ich habe die historischen Whitepaper von @Dusk mit der aktuellen Dokumentation abgeglichen. Frühere Unterlagen nennen diese Rust/WASM-Laufzeit Piecrust; die aktuelle Doku verwendet stattdessen DuskVM. Der Name hat sich weiterentwickelt, aber das Kerndesign ist gleich geblieben: Verträge können kryptografische Verifikationen wie PLONK, Groth16, BLS usw. an die öffentliche Einstiegsschicht des Hosts delegieren, statt alles jeweils selbst zu implementieren.
Die Vorteile sind ganz real. Entwickler müssen weniger fehleranfälligen Kryptocode schreiben, und Knoten müssen die grundlegenden Rechenoperationen nicht mehrfach in der WASM-Sandbox wiederholen; das macht Anwendungen leichter und die Verifikationsregeln lassen sich leichter vereinheitlichen.
Die Kosten konzentrieren sich ebenfalls. Wenn ein Anwendungs-Contract falsch geschrieben ist, trifft es zuerst sich selbst; wenn ein gemeinsam genutzter Verifikator bei der Eingabeanalyse, der Versionsauswahl oder bei Randbedingungen einen Fehler macht, können alle von ihm abhängigen Verträge betroffen sein. Im gesamten Netzwerk ist dann alles konsistent – man kann lediglich beweisen, dass alle dieselbe Regel ausgeführt haben.
Dusk hat im Aegis-Upgrade im März 2026 PLONK V3 und ein neues BLS-Verhalten aktiviert, und auch die BLS-Host-Queries, die Verträge nutzen, werden je nach Blockhöhe umgeschaltet. Historische Blöcke rufen den alten Verifikator auf, neue Daten verwenden die neue Version; wenn die Höhe falsch gewählt wird, können Transaktionen unter Umständen zu unterschiedlichen Ergebnissen hinsichtlich ihrer Gültigkeit führen.
Darum werde ich nicht nur die Auditberichte zählen, sondern auch auf die Verifikator-Version, die Upgrade-Höhe, Testvektoren, Cache-Invalidierungen und Rollback-Übungen achten. $DUSK trägt Gas und Konsenssicherheit, aber diese öffentlichen Verifikations-Einstiegspunkte stützen auch die Finanzanwendungen. Geschwindigkeit bestimmt, wie schnell das System laufen kann, und der Verifikator entscheidet, ob es auch Fehler schneller mit ausführt.
#dusk
Ich habe die historischen Whitepaper von @Dusk mit der aktuellen Dokumentation abgeglichen. Frühere Unterlagen nennen diese Rust/WASM-Laufzeit Piecrust; die aktuelle Doku verwendet stattdessen DuskVM. Der Name hat sich weiterentwickelt, aber das Kerndesign ist gleich geblieben: Verträge können kryptografische Verifikationen wie PLONK, Groth16, BLS usw. an die öffentliche Einstiegsschicht des Hosts delegieren, statt alles jeweils selbst zu implementieren.
Die Vorteile sind ganz real. Entwickler müssen weniger fehleranfälligen Kryptocode schreiben, und Knoten müssen die grundlegenden Rechenoperationen nicht mehrfach in der WASM-Sandbox wiederholen; das macht Anwendungen leichter und die Verifikationsregeln lassen sich leichter vereinheitlichen.
Die Kosten konzentrieren sich ebenfalls. Wenn ein Anwendungs-Contract falsch geschrieben ist, trifft es zuerst sich selbst; wenn ein gemeinsam genutzter Verifikator bei der Eingabeanalyse, der Versionsauswahl oder bei Randbedingungen einen Fehler macht, können alle von ihm abhängigen Verträge betroffen sein. Im gesamten Netzwerk ist dann alles konsistent – man kann lediglich beweisen, dass alle dieselbe Regel ausgeführt haben.
Dusk hat im Aegis-Upgrade im März 2026 PLONK V3 und ein neues BLS-Verhalten aktiviert, und auch die BLS-Host-Queries, die Verträge nutzen, werden je nach Blockhöhe umgeschaltet. Historische Blöcke rufen den alten Verifikator auf, neue Daten verwenden die neue Version; wenn die Höhe falsch gewählt wird, können Transaktionen unter Umständen zu unterschiedlichen Ergebnissen hinsichtlich ihrer Gültigkeit führen.
Darum werde ich nicht nur die Auditberichte zählen, sondern auch auf die Verifikator-Version, die Upgrade-Höhe, Testvektoren, Cache-Invalidierungen und Rollback-Übungen achten. $DUSK trägt Gas und Konsenssicherheit, aber diese öffentlichen Verifikations-Einstiegspunkte stützen auch die Finanzanwendungen. Geschwindigkeit bestimmt, wie schnell das System laufen kann, und der Verifikator entscheidet, ob es auch Fehler schneller mit ausführt.
#dusk
