Ich bin beim Einstellen des Dusk-Indexers über eine Falle gestolpert: Ich habe die Transaktions-ID und die Contract-ID denselben Hash-Algorithmus teilen lassen. Block-Hashes und der Merkle-Root nutzen SHA3-256; Contract-Bytecode und der Event-Bloom-Filter nutzen BLAKE3; Contract-ID und Transaktions-ID nutzen BLAKE2b; die Wallet-Integrität und die Schlüsselableitung nutzen SHA2-256.
Das ist wie mit vier Stempeln in einem Archiv. Ein Lagerstempel, ein Vertragsstempel und ein Abholstempel können jeweils Nummern pressen – aber das Registrierungssystem erkennt nur den einen, der vorgesehen ist. Wenn man den Algorithmus falsch wählt, sieht die Ausgabe trotzdem wie ein normaler Hash aus, aber die Nodes finden das zugehörige Objekt nicht. Eine weitere Falle ist, den Hex-Anzeigestring noch einmal zu hashen; Protokoll-Schnittstellen verarbeiten normalerweise die Rohbytes. Wenn man das Encoding noch eine Stufe extra verwickelt, ändert sich am Ende alles.
Darum behalte ich beim Anbinden die ursprünglichen Bytes bei, generiere IDs mit dem offiziellen SDK oder mit Rusk und teste mit bekannten Vektoren aus Block-, Transaktions- und Contract-Daten. @Dusk Dusk-Dokumentation empfiehlt außerdem, die Protokollcodierung nicht mehrfach selbst zu implementieren. Wenn man verschiedene Algorithmen die Aufgaben trennen lässt, trennt man auch Version, Byte-Reihenfolge und Eingabeformat – und macht sie zu Abnahmekriterien. Eine Zeichenkette korrekter Länge zu erzeugen heißt nur, dass die Funktion durchläuft; die On-Chain-Identität muss trotzdem durch Rückabfrage bestätigt werden. #dusk $DUSK
Das ist wie mit vier Stempeln in einem Archiv. Ein Lagerstempel, ein Vertragsstempel und ein Abholstempel können jeweils Nummern pressen – aber das Registrierungssystem erkennt nur den einen, der vorgesehen ist. Wenn man den Algorithmus falsch wählt, sieht die Ausgabe trotzdem wie ein normaler Hash aus, aber die Nodes finden das zugehörige Objekt nicht. Eine weitere Falle ist, den Hex-Anzeigestring noch einmal zu hashen; Protokoll-Schnittstellen verarbeiten normalerweise die Rohbytes. Wenn man das Encoding noch eine Stufe extra verwickelt, ändert sich am Ende alles.
Darum behalte ich beim Anbinden die ursprünglichen Bytes bei, generiere IDs mit dem offiziellen SDK oder mit Rusk und teste mit bekannten Vektoren aus Block-, Transaktions- und Contract-Daten. @Dusk Dusk-Dokumentation empfiehlt außerdem, die Protokollcodierung nicht mehrfach selbst zu implementieren. Wenn man verschiedene Algorithmen die Aufgaben trennen lässt, trennt man auch Version, Byte-Reihenfolge und Eingabeformat – und macht sie zu Abnahmekriterien. Eine Zeichenkette korrekter Länge zu erzeugen heißt nur, dass die Funktion durchläuft; die On-Chain-Identität muss trotzdem durch Rückabfrage bestätigt werden. #dusk $DUSK