Ich habe mir dieses Mal die Dusk-Entwicklungsdokumentation angesehen. Was mich wirklich zum Innehalten gebracht hat, war weder ZK noch Datenschutz.
Es war vielmehr eine kleine Detailfrage an einer Schnittstelle:
**Die Knoten teilen dem Client ihre Rusk-Version mit, und der Client kann zusätzlich aktiv einen Versionsbereich anfordern.**
Wenn die Version nicht kompatibel ist, wird die Anfrage direkt abgelehnt.
Auf den ersten Blick wirkt das überhaupt nicht wie großes Blockchain-Storytelling.
Aber nachdem ich es in einen echten Entwicklungsprozess eingeordnet habe, finde ich es ziemlich interessant.
Denn das, wovor viele On-Chain-Anwendungen am meisten Angst haben, ist nicht, dass die Schnittstelle etwas langsam ist.
Sondern eher:
Dass es heute noch funktioniert und nach einem Upgrade plötzlich diese Situation entsteht, in der „einige Knoten es erkennen und andere nicht“.
Wenn Entwickler nicht wissen, welche Version genau auf dem Knoten läuft, mit dem sie verbunden sind, ist es schwer einzuschätzen, ob das Problem aus dem Code kommt, aus den Knoten oder aus dem Protokoll selbst.
Dusk stellt diese Versionsinformationen jetzt direkt in der HTTP-Antwort bereit und ermöglicht gleichzeitig dem Client einen stricten Version-Check.
Früher war ich eher daran gewöhnt, aus TPS und der Finalität abzuleiten, ob sich eine L1 gut nutzen lässt.
Jetzt denke ich eher: Solche kleinen Regeln auf der Ebene der Schnittstelle machen am ehesten sichtbar, ob ein Netzwerk die Probleme, mit denen Entwickler wirklich konfrontiert werden, ernsthaft bedacht hat.
Denn Infrastrukturen fürchten nicht Komplexität.
Sondern **Ungewissheit**.
Wenn eine Anwendung von bestimmten Knoten-Fähigkeiten abhängt und sich nach einem Knoten-Upgrade das Verhalten ändert, sind die Betroffenen, die am schlechtesten dastehen, in der Regel nicht das Protokoll-Team – sondern die bereits live gegangenen Anwendungen.
Daher löst diese Art von Versionskontrolle, die auf den ersten Blick sehr „ingenieurmäßig“ wirkt, eigentlich ein sehr reales Problem:
Sie sorgt dafür, dass Entwickler wissen, mit welchem Satz von Protokollregeln sie es wirklich zu tun haben.
Und genau das ist ein Punkt, den ich an Dusk aktuell für besonders forschenswert halte.
Eine wirklich ausgereifte L1 besteht nicht nur darin, dass die Kette läuft.
Man muss auch dafür sorgen, dass andere wissen, wo die Grenzen liegen, wenn sie sich anschließen.
#dusk $DUSK @Dusk
Es war vielmehr eine kleine Detailfrage an einer Schnittstelle:
**Die Knoten teilen dem Client ihre Rusk-Version mit, und der Client kann zusätzlich aktiv einen Versionsbereich anfordern.**
Wenn die Version nicht kompatibel ist, wird die Anfrage direkt abgelehnt.
Auf den ersten Blick wirkt das überhaupt nicht wie großes Blockchain-Storytelling.
Aber nachdem ich es in einen echten Entwicklungsprozess eingeordnet habe, finde ich es ziemlich interessant.
Denn das, wovor viele On-Chain-Anwendungen am meisten Angst haben, ist nicht, dass die Schnittstelle etwas langsam ist.
Sondern eher:
Dass es heute noch funktioniert und nach einem Upgrade plötzlich diese Situation entsteht, in der „einige Knoten es erkennen und andere nicht“.
Wenn Entwickler nicht wissen, welche Version genau auf dem Knoten läuft, mit dem sie verbunden sind, ist es schwer einzuschätzen, ob das Problem aus dem Code kommt, aus den Knoten oder aus dem Protokoll selbst.
Dusk stellt diese Versionsinformationen jetzt direkt in der HTTP-Antwort bereit und ermöglicht gleichzeitig dem Client einen stricten Version-Check.
Früher war ich eher daran gewöhnt, aus TPS und der Finalität abzuleiten, ob sich eine L1 gut nutzen lässt.
Jetzt denke ich eher: Solche kleinen Regeln auf der Ebene der Schnittstelle machen am ehesten sichtbar, ob ein Netzwerk die Probleme, mit denen Entwickler wirklich konfrontiert werden, ernsthaft bedacht hat.
Denn Infrastrukturen fürchten nicht Komplexität.
Sondern **Ungewissheit**.
Wenn eine Anwendung von bestimmten Knoten-Fähigkeiten abhängt und sich nach einem Knoten-Upgrade das Verhalten ändert, sind die Betroffenen, die am schlechtesten dastehen, in der Regel nicht das Protokoll-Team – sondern die bereits live gegangenen Anwendungen.
Daher löst diese Art von Versionskontrolle, die auf den ersten Blick sehr „ingenieurmäßig“ wirkt, eigentlich ein sehr reales Problem:
Sie sorgt dafür, dass Entwickler wissen, mit welchem Satz von Protokollregeln sie es wirklich zu tun haben.
Und genau das ist ein Punkt, den ich an Dusk aktuell für besonders forschenswert halte.
Eine wirklich ausgereifte L1 besteht nicht nur darin, dass die Kette läuft.
Man muss auch dafür sorgen, dass andere wissen, wo die Grenzen liegen, wenn sie sich anschließen.
#dusk $DUSK @Dusk
