Ich habe immer wieder an Dusk’ Implementierung von BLS12-381 gedacht, nachdem ich bei der technischen Arbeit eine kleine Einzelheit gesehen hatte: Das Team benötigte zusätzliche Funktionalität rund um den Kurvenbereich, um die eigenen Netzwerkanforderungen abzudecken.
Zunächst klang das nach ganz gewöhnlichem Engineering.
Aber je mehr ich mir das ansah, desto weniger gewöhnlich fühlte es sich an.
BLS12-381 ist eine etablierte, paarungsfreundliche elliptische Kurve, die in Systemen eingesetzt wird, welche auf fortgeschrittenen Proof- und Signatur-Operationen beruhen. Dusk hat die Kurve nicht erfunden. Sie haben die Implementierung so angepasst, dass die Kryptografie tatsächlich zu der Art passt, wie ihr Netzwerk funktioniert.
Diese Unterscheidung ist wichtig.
Ein Großteil der Blockchain-Infrastruktur wird so beschrieben, als wäre die größte Herausforderung, die richtige kryptografische Primzahl zu finden und sie in das Protokoll einzubauen.
In der Praxis kann der schwierigere Teil jedoch erst danach kommen.
Die Kryptografie muss in einer Ausführungsumgebung leben. Sie muss das Verifikationsmodell unterstützen, korrekt mit dem Rest des Protokolls interagieren und unter den Bedingungen zuverlässig bleiben, die das Netzwerk tatsächlich erzeugt.
Das bedeutet: Die Grenze zwischen „Kryptografie“ und „Protokoll-Engineering“ ist dünner, als es auf den ersten Blick scheint.
Und ich denke, genau auf diesen Teil lohnt es sich, bei Dusk zu achten.
Die zugrunde liegende Mathematik stammt weiterhin aus einer etablierten Konstruktion. Die zusätzliche Arbeit liegt darin, diese Konstruktion innerhalb einer spezifischen Netzwerkarchitektur nutzbar zu machen, ohne vorzutäuschen, dass die Anpassung allein die Kryptografie automatisch magisch sicherer macht.
Sicherheit hängt weiterhin von der Mathematik, der Qualität der Implementierung, dem Testen und allem drum herum ab.
Vielleicht wird die nächste Generation der Blockchain-Infrastruktur nicht dadurch definiert, gänzlich neue Kryptografie zu erfinden.
Vielleicht wird sie dadurch definiert, wie gut sich vorhandene Kryptografie so in Systeme bringen lässt, die etwas Spezifischeres verlangen.
@Dusk #DUSK $DUSK
Zunächst klang das nach ganz gewöhnlichem Engineering.
Aber je mehr ich mir das ansah, desto weniger gewöhnlich fühlte es sich an.
BLS12-381 ist eine etablierte, paarungsfreundliche elliptische Kurve, die in Systemen eingesetzt wird, welche auf fortgeschrittenen Proof- und Signatur-Operationen beruhen. Dusk hat die Kurve nicht erfunden. Sie haben die Implementierung so angepasst, dass die Kryptografie tatsächlich zu der Art passt, wie ihr Netzwerk funktioniert.
Diese Unterscheidung ist wichtig.
Ein Großteil der Blockchain-Infrastruktur wird so beschrieben, als wäre die größte Herausforderung, die richtige kryptografische Primzahl zu finden und sie in das Protokoll einzubauen.
In der Praxis kann der schwierigere Teil jedoch erst danach kommen.
Die Kryptografie muss in einer Ausführungsumgebung leben. Sie muss das Verifikationsmodell unterstützen, korrekt mit dem Rest des Protokolls interagieren und unter den Bedingungen zuverlässig bleiben, die das Netzwerk tatsächlich erzeugt.
Das bedeutet: Die Grenze zwischen „Kryptografie“ und „Protokoll-Engineering“ ist dünner, als es auf den ersten Blick scheint.
Und ich denke, genau auf diesen Teil lohnt es sich, bei Dusk zu achten.
Die zugrunde liegende Mathematik stammt weiterhin aus einer etablierten Konstruktion. Die zusätzliche Arbeit liegt darin, diese Konstruktion innerhalb einer spezifischen Netzwerkarchitektur nutzbar zu machen, ohne vorzutäuschen, dass die Anpassung allein die Kryptografie automatisch magisch sicherer macht.
Sicherheit hängt weiterhin von der Mathematik, der Qualität der Implementierung, dem Testen und allem drum herum ab.
Vielleicht wird die nächste Generation der Blockchain-Infrastruktur nicht dadurch definiert, gänzlich neue Kryptografie zu erfinden.
Vielleicht wird sie dadurch definiert, wie gut sich vorhandene Kryptografie so in Systeme bringen lässt, die etwas Spezifischeres verlangen.
@Dusk #DUSK $DUSK
