#dusk $DUSK
Ich habe in den letzten beiden Tagen das neueste <a>Developer Update</a> unter @Dusk angeschaut, und ich finde, dass ein Update spannender ist als „noch eine ZK-Funktion hinzugefügt“.
zk-tools beginnt jetzt damit, Generierungs- und Verifikationstools für Groth16 Solidity Verifier nachzuliefern.
Auf den ersten Blick wirkt das eher klein.
Aber wenn man wirklich schon mal eine ZK-Anwendung geschrieben hat, weiß man: Proof zu erzeugen ist nur die halbe Miete.
Danach kommt ein sehr konkretes Problem:
Wie „versteht“ ein Solidity-Contract überhaupt diese Proof?
Die Circuit-Definition regelt, wie der Prover den Proof erstellt. Auf der EVM-Seite braucht es dann jedoch noch einen Verifier-Contract, der prüft, ob der Proof und die public inputs die ursprünglichen Constraints erfüllen.
Wenn diese Schicht an Schnittstellen nicht gut umgesetzt ist, dann ist selbst die stärkste Kryptografie für normale Solidity-Entwickler noch sehr weit weg.
Darum sehe ich mir dieses Update von Dusk jetzt an: Der Fokus liegt nicht primär auf dem Namen Groth16.
Sondern darauf, dass sie Folgendes ergänzen:
proof → verifier → Solidity application
Diese dazwischenliegende Engineering-Kette.
Natürlich ist der Verifier auch nicht allmächtig.
Er kann nur bestätigen, ob ein bestimmter Proof mit einer vorab geschriebenen Circuit übereinstimmt. Wo die Daten herkommen, ob diese Regeln einen Geschäftsbezug haben, und ob die Berechtigung aktuell noch gültig ist—das muss die Anwendung selbst definieren.
Das finde ich aber eigentlich normal.
Die Kryptografie sorgt dafür, dass die „Behauptung“ korrekt geprüft wird. Das Produkt entscheidet dann, was man mit diesem Nachweis konkret macht.
DuskEVM befindet sich aktuell noch im Testnet. Ich werde nicht einfach, weil es jetzt ein weiteres verifier tooling gibt, sagen, dass das komplette ZK-Workflow bereits ausgereift ist.
Aber solche Updates sind zumindest greifbarer als nur „ZK wird unterstützt“.
Was Entwickler wirklich zum Einsatz bringt, sind oft genau diese eher unscheinbaren Schnittstellen, die nicht gerade nach viel aussehen.
Ich habe in den letzten beiden Tagen das neueste <a>Developer Update</a> unter @Dusk angeschaut, und ich finde, dass ein Update spannender ist als „noch eine ZK-Funktion hinzugefügt“.
zk-tools beginnt jetzt damit, Generierungs- und Verifikationstools für Groth16 Solidity Verifier nachzuliefern.
Auf den ersten Blick wirkt das eher klein.
Aber wenn man wirklich schon mal eine ZK-Anwendung geschrieben hat, weiß man: Proof zu erzeugen ist nur die halbe Miete.
Danach kommt ein sehr konkretes Problem:
Wie „versteht“ ein Solidity-Contract überhaupt diese Proof?
Die Circuit-Definition regelt, wie der Prover den Proof erstellt. Auf der EVM-Seite braucht es dann jedoch noch einen Verifier-Contract, der prüft, ob der Proof und die public inputs die ursprünglichen Constraints erfüllen.
Wenn diese Schicht an Schnittstellen nicht gut umgesetzt ist, dann ist selbst die stärkste Kryptografie für normale Solidity-Entwickler noch sehr weit weg.
Darum sehe ich mir dieses Update von Dusk jetzt an: Der Fokus liegt nicht primär auf dem Namen Groth16.
Sondern darauf, dass sie Folgendes ergänzen:
proof → verifier → Solidity application
Diese dazwischenliegende Engineering-Kette.
Natürlich ist der Verifier auch nicht allmächtig.
Er kann nur bestätigen, ob ein bestimmter Proof mit einer vorab geschriebenen Circuit übereinstimmt. Wo die Daten herkommen, ob diese Regeln einen Geschäftsbezug haben, und ob die Berechtigung aktuell noch gültig ist—das muss die Anwendung selbst definieren.
Das finde ich aber eigentlich normal.
Die Kryptografie sorgt dafür, dass die „Behauptung“ korrekt geprüft wird. Das Produkt entscheidet dann, was man mit diesem Nachweis konkret macht.
DuskEVM befindet sich aktuell noch im Testnet. Ich werde nicht einfach, weil es jetzt ein weiteres verifier tooling gibt, sagen, dass das komplette ZK-Workflow bereits ausgereift ist.
Aber solche Updates sind zumindest greifbarer als nur „ZK wird unterstützt“.
Was Entwickler wirklich zum Einsatz bringt, sind oft genau diese eher unscheinbaren Schnittstellen, die nicht gerade nach viel aussehen.