Je lisais la documentation de SXT et je me suis arrêté sur un sujet moins spectaculaire que les preuves ZK : qui est réellement autorisé à écrire dans une table.
Lorsqu’un développeur crée une table avec une instruction CREATE TABLE signée, il peut choisir entre trois modèles d’écriture : écriture publique, où tout le monde peut soumettre des lignes ; accès contrôlé par le propriétaire, où seul le propriétaire ou une liste d’autorisation peut le faire ; et vérification par l’utilisateur, où chaque ligne doit être accompagnée de la signature ECDSA/ED25519 de l’utilisateur, avec en option une vérification zkTLS ou par un indexeur.
J’aime le fait que ces autorisations ne soient pas traitées comme une solution universelle. Un flux d’activité public, un jeu de données appartenant à un protocole et des enregistrements soumis par les utilisateurs reposent sur des hypothèses de confiance différentes. La propriété peut aussi être déléguée au moyen de jetons d’autorisation Biscuit, de sorte que le contrôle n’a pas à rester entre les mains du portefeuille qui a créé la table.
Je ne pense pas que cette flexibilité soit en soi un défaut. Mais elle place une véritable décision entre les mains du développeur : la couche de données peut faire respecter la politique qui lui a été définie, mais elle ne peut pas sauver une application qui a choisi une politique trop permissive. Pour les actifs tokenisés ou les enregistrements DeFi, une mauvaise politique d’écriture peut avoir des conséquences bien avant que quiconque ne pose une question SQL ingénieuse.
Je me demande souvent si les développeurs considéreront les autorisations des tables comme un élément essentiel de la conception de la sécurité ou comme un simple champ de configuration qu’ils cochent machinalement. Quelle devrait être l’option par défaut pour les jeux de données sensibles : des écritures contrôlées par le propriétaire ou des lignes signées par les utilisateurs ??
#SXT @SpaceandTime $SXT
#sxt $SXT @SpaceandTime #SXT
Lorsqu’un développeur crée une table avec une instruction CREATE TABLE signée, il peut choisir entre trois modèles d’écriture : écriture publique, où tout le monde peut soumettre des lignes ; accès contrôlé par le propriétaire, où seul le propriétaire ou une liste d’autorisation peut le faire ; et vérification par l’utilisateur, où chaque ligne doit être accompagnée de la signature ECDSA/ED25519 de l’utilisateur, avec en option une vérification zkTLS ou par un indexeur.
J’aime le fait que ces autorisations ne soient pas traitées comme une solution universelle. Un flux d’activité public, un jeu de données appartenant à un protocole et des enregistrements soumis par les utilisateurs reposent sur des hypothèses de confiance différentes. La propriété peut aussi être déléguée au moyen de jetons d’autorisation Biscuit, de sorte que le contrôle n’a pas à rester entre les mains du portefeuille qui a créé la table.
Je ne pense pas que cette flexibilité soit en soi un défaut. Mais elle place une véritable décision entre les mains du développeur : la couche de données peut faire respecter la politique qui lui a été définie, mais elle ne peut pas sauver une application qui a choisi une politique trop permissive. Pour les actifs tokenisés ou les enregistrements DeFi, une mauvaise politique d’écriture peut avoir des conséquences bien avant que quiconque ne pose une question SQL ingénieuse.
Je me demande souvent si les développeurs considéreront les autorisations des tables comme un élément essentiel de la conception de la sécurité ou comme un simple champ de configuration qu’ils cochent machinalement. Quelle devrait être l’option par défaut pour les jeux de données sensibles : des écritures contrôlées par le propriétaire ou des lignes signées par les utilisateurs ??
#SXT @SpaceandTime $SXT
#sxt $SXT @SpaceandTime #SXT