Viele Leute diskutieren intelligente Vertragsketten und vergleichen dabei TPS und Gasgebühren. Diese Kennzahlen in ein Szenario der Wertpapierabwicklung für Institutionen zu setzen, könnte von Anfang an die falsche Frage sein.

Diejenigen, die institutionelle Vertragsentwickler wirklich ausbremsen, sind meist nicht, wie viele Transaktionen pro Sekunde verarbeitet werden können, sondern ob sich eine große Inhaber-Registrierung effizient warten lässt – mit Zehntausenden oder sogar Hunderttausenden Einträgen. Außerdem muss bei jeder Übertragung der Anteil überprüft werden, damit bestimmte Grenzen nicht überschritten werden; gleichzeitig darf diese Registrierung selbst nicht öffentlich lesbar sein. Eine allgemeine Key-Value-Speicherstruktur gerät bei solchen komplexen Datenbeziehungen, bei denen man „geheim halten“ und „gleichzeitig die Korrektheit des Zustands nachweisen“ muss, schnell an ihre Grenzen.

Das Microkelvin-Toolset, das im Rusk-Ausführungsumfeld bereitgestellt wird, soll genau das lösen: Entwicklern ermöglichen, sich selbst eine maßgeschneiderte, fortgeschrittene Datenstruktur zusammenzustellen – statt gezwungen zu sein, ein vorhandenes generisches Speichermodell verbiegen zu müssen, um die Anforderungen von Finanzverträgen „hart zusammenzuschustern“.

Mich interessiert dabei weniger, wie technisch fortschrittlich dieses Toolset ist, sondern was es zeigt: eine Einschätzung, dass das Dusk-Team sehr wahrscheinlich zuerst die realen Abläufe der Wertpapierabwicklung untersucht hat, welche Datenstrukturen dafür nötig sind – und erst danach diese Tool-Schicht gebaut hat. Nicht umgekehrt, also nicht erst eine generische Kette zu bauen und dann darauf zu hoffen, dass Entwickler die Finanzlogik irgendwie selbst hineinzwängen. Diese Reihenfolge erklärt – in gewissem Maße – sogar stärker, ob diese Kette wirklich „für Finanzen gebaut“ ist, als die reine Privacy-Erzählung selbst.

Aber ich kann auch nicht so tun, als sei diese Sache bereits verifiziert. Das Toolset ist da, aber das bedeutet nicht, dass schon echte Entwickler damit tatsächlich komplexe Anwendungen auf Institutionsebene gebaut haben. Die öffentlich sichtbaren Praxisfälle sind bisher noch eher wenige. Ob diese Fähigkeiten wirklich gut nutzbar sind, wird sich möglicherweise erst zeigen, wenn mehr echte Verträge damit laufen.

#dusk $DUSK @Dusk
Was denkt ihr: Ist der Weg „erst das Szenario erforschen, dann das Tool bauen“ langfristig einfacher, um in den institutionellen Markt vorzudringen – oder der Weg „erst eine generische Kette bauen und dann auf ein Ökosystem hoffen, das die Lücken füllt“?