#dusk $DUSK @Dusk Ich komme immer wieder auf eine Zeile im Abschnitt „Genesis Contracts“ zurück: Das Dusk-Protokoll bringt genau vier native Contracts mit, die im Genesis-Block bereitgestellt und von Anfang an fest in jede Node eingebaut sind.
Beim ersten Lesen klingt das nach einem Stabilitätsvorteil. Die Kernmechanik – DUSK-Accounting, Staking, Bidding, Rewards – wird nicht neu deployed oder durch konkurrierende Implementierungen fragmentiert. Jeder Teilnehmer läuft von Block Null an mit derselben grundlegenden Logik.
Doch „hardcoded“ bedeutet auch „fest“. Das sind keine Contracts, über die eine DAO nächstes Quartal neu abstimmen und sie neu deployen würde. Sie sind direkt im Genesis-Status verankert, genauso wie die anfänglichen Validator- und Provisioner-Sets. Die spannende Frage lautet also nicht „Was machen diese Contracts“, sondern „Was passiert, wenn einer von ihnen geändert werden muss?“
Ein Bug in einem typischen Smart Contract wird durch das Deployen einer neuen Version behoben. Ein Fehler oder eine sich weiterentwickelnde Anforderung in einem Genesis-Contract ist jedoch eine andere Art von Problem – eher eine Protokoll-Entscheidung als ein Anwendungs-Update.
Das ist keine Kritik am Design: Die Dauerhaftigkeit auf dieser Ebene ist möglicherweise sogar der eigentliche Zweck. Aber es verschiebt, wo der reale Einfluss liegt: nicht bei der Person, die den besten Ersatz-Contract schreibt, sondern bei der, die eine Änderung an etwas koordinieren kann, das als Grundlage gedacht ist.
Wenn die Kernlogik per Design unveränderlich sein soll – wo findet dann die legitime Weiterentwicklung tatsächlich statt, wenn das System sie irgendwann doch benötigt?
$DUSK #dusk @Dusk
Beim ersten Lesen klingt das nach einem Stabilitätsvorteil. Die Kernmechanik – DUSK-Accounting, Staking, Bidding, Rewards – wird nicht neu deployed oder durch konkurrierende Implementierungen fragmentiert. Jeder Teilnehmer läuft von Block Null an mit derselben grundlegenden Logik.
Doch „hardcoded“ bedeutet auch „fest“. Das sind keine Contracts, über die eine DAO nächstes Quartal neu abstimmen und sie neu deployen würde. Sie sind direkt im Genesis-Status verankert, genauso wie die anfänglichen Validator- und Provisioner-Sets. Die spannende Frage lautet also nicht „Was machen diese Contracts“, sondern „Was passiert, wenn einer von ihnen geändert werden muss?“
Ein Bug in einem typischen Smart Contract wird durch das Deployen einer neuen Version behoben. Ein Fehler oder eine sich weiterentwickelnde Anforderung in einem Genesis-Contract ist jedoch eine andere Art von Problem – eher eine Protokoll-Entscheidung als ein Anwendungs-Update.
Das ist keine Kritik am Design: Die Dauerhaftigkeit auf dieser Ebene ist möglicherweise sogar der eigentliche Zweck. Aber es verschiebt, wo der reale Einfluss liegt: nicht bei der Person, die den besten Ersatz-Contract schreibt, sondern bei der, die eine Änderung an etwas koordinieren kann, das als Grundlage gedacht ist.
Wenn die Kernlogik per Design unveränderlich sein soll – wo findet dann die legitime Weiterentwicklung tatsächlich statt, wenn das System sie irgendwann doch benötigt?
$DUSK #dusk @Dusk