Ich habe die SXT-Dokumentation gelesen und bin bei etwas hängen geblieben, das weniger spektakulär ist als ZK-Beweise: Wer darf eigentlich in eine Tabelle schreiben.

Wenn ein Entwickler mit einem signierten CREATE-TABLE-Statement eine Tabelle erstellt, kann er zwischen drei Schreibmodellen wählen: Public Write, bei dem jeder Zeilen einreichen kann; Owner-Permissioned, bei dem nur der Eigentümer oder eine Allowlist dies darf; und User-Verified, bei dem jede Zeile die ECDSA-/ED25519-Signatur des Nutzers benötigt, optional mit zkTLS- oder Indexer-Verifizierung.

Mir gefällt, dass diese Berechtigungen nicht nach dem Einheitsprinzip behandelt werden. Ein öffentlicher Aktivitätsfeed, ein protokolleigener Datensatz und von Nutzern eingereichte Einträge haben unterschiedliche Vertrauensannahmen. Die Eigentümerschaft kann außerdem über Biscuit-Autorisierungstoken delegiert werden, sodass die Kontrolle nicht bei der Wallet bleiben muss, die die Tabelle erstellt hat.

Ich glaube nicht, dass diese Flexibilität an sich ein Fehler ist. Aber sie legt eine echte Entscheidung in die Hände des Entwicklers: Die Datenschicht kann die Richtlinie durchsetzen, die ihr vorgegeben wurde, aber eine App nicht davor bewahren, eine zu großzügige Richtlinie zu wählen. Bei tokenisierten Vermögenswerten oder DeFi-Datensätzen könnte eine schlechte Schreibrichtlinie lange relevant sein, bevor jemand eine clevere SQL-Frage stellt.

Ich frage mich immer wieder, ob Entwickler Tabellenberechtigungen als wesentlichen Teil des Sicherheitskonzepts betrachten oder nur als weiteres Einrichtungsfeld, das sie wegklicken. Was sollte bei sensiblen Datensätzen der Standard sein: vom Eigentümer kontrollierte Schreibvorgänge oder vom Nutzer signierte Zeilen??

#SXT @SpaceandTime $SXT

#sxt $SXT @SpaceandTime #SXT