Ich habe eine Zeile in Hedger's Feature-Liste immer wieder gelesen, weil sie für mich zunächst nicht sofort Sinn ergab: ein hybrides UTXO-/Account-Modell, beschrieben als Unterstützung für „Cross-Layer-Komponierbarkeit“ und die Integration mit realen Finanzsystemen. Ich habe mir das eine Weile angesehen und versucht herauszufinden, warum eine Engine für vertrauliche Transaktionen beide Modelle gleichzeitig brauchen würde, statt einfach eines auszuwählen.

Dann fand ich den Detailpunkt, durch den es klickte. Im Hedger-Alpha-Setup arbeitet ein Nutzer mit zwei getrennten Adressen: einer normalen EVM-Adresse für die Interaktion mit Contracts und einer eigenen Hedger-Adresse, die speziell dafür gedacht ist, verschlüsselte Guthaben zu halten. Das ist der hybride Teil in der Praxis: eine accountartige Adresse für die Bereiche des Systems, die normales EVM-Verhalten benötigen, und darunter eine UTXO-nahe Struktur für die Teile, die verschlüsselt bleiben und über Ebenen hinweg komponierbar sein sollen.

Ich hatte nicht erwartet, dass es ein Zwei-Adress-Modell geben würde, als ich mir zuerst vorstellte, wie das funktionieren soll. Ich ging davon aus: eine Wallet, ein Guthaben, Privatsphäre wird einfach oben drauf angewendet. So aufgeteilt ergibt es mehr Sinn, sobald man darüber nachdenkt, dass DuskEVM auf der einen Seite mit gängigen EVM-Tools sprechen muss, während Hedgers vertrauliche Logik auf der anderen Seite läuft. Aber das bedeutet auch, dass es für einen Nutzer oder die Wallet-Ansicht etwas mehr korrekt zu verwalten gibt.

#dusk $DUSK @Dusk $AIO $PORTAL