Estava lendo a documentação do SXT e fiquei preso em algo menos chamativo do que provas ZK: quem realmente tem permissão para gravar em uma tabela.
Quando um desenvolvedor cria uma tabela com uma instrução CREATE TABLE assinada, pode escolher entre três modelos de gravação: Gravação Pública, em que qualquer pessoa pode enviar linhas; Com Permissão do Proprietário, em que apenas o proprietário ou uma lista de permissões pode fazer isso; e Verificado pelo Usuário, em que cada linha precisa da assinatura ECDSA/ED25519 do usuário, com verificação opcional por zkTLS ou indexador.
Gosto que essas opções não sejam tratadas como permissões universais. Um feed público de atividades, um conjunto de dados pertencente a um protocolo e registros enviados por usuários têm diferentes pressupostos de confiança. A propriedade também pode ser delegada por meio de tokens de autorização Biscuit, então o controle não precisa permanecer com a carteira que criou a tabela.
Não acho que essa flexibilidade seja, por si só, uma falha. Mas ela coloca uma decisão importante nas mãos do desenvolvedor: a camada de dados pode aplicar a política que recebeu, mas não salvar um aplicativo de escolher uma política permissiva demais. Para ativos tokenizados ou registros DeFi, uma política de gravação inadequada pode fazer diferença muito antes de alguém sequer fazer uma pergunta inteligente em SQL.
Fico me perguntando se os desenvolvedores vão tratar as permissões de tabela como parte essencial do projeto de segurança ou apenas como mais um campo de configuração que marcam sem pensar. Qual deveria ser o padrão para conjuntos de dados sensíveis: gravações controladas pelo proprietário ou linhas assinadas pelos usuários??
#SXT @SpaceandTime $SXT
#sxt $SXT @SpaceandTime #SXT
Quando um desenvolvedor cria uma tabela com uma instrução CREATE TABLE assinada, pode escolher entre três modelos de gravação: Gravação Pública, em que qualquer pessoa pode enviar linhas; Com Permissão do Proprietário, em que apenas o proprietário ou uma lista de permissões pode fazer isso; e Verificado pelo Usuário, em que cada linha precisa da assinatura ECDSA/ED25519 do usuário, com verificação opcional por zkTLS ou indexador.
Gosto que essas opções não sejam tratadas como permissões universais. Um feed público de atividades, um conjunto de dados pertencente a um protocolo e registros enviados por usuários têm diferentes pressupostos de confiança. A propriedade também pode ser delegada por meio de tokens de autorização Biscuit, então o controle não precisa permanecer com a carteira que criou a tabela.
Não acho que essa flexibilidade seja, por si só, uma falha. Mas ela coloca uma decisão importante nas mãos do desenvolvedor: a camada de dados pode aplicar a política que recebeu, mas não salvar um aplicativo de escolher uma política permissiva demais. Para ativos tokenizados ou registros DeFi, uma política de gravação inadequada pode fazer diferença muito antes de alguém sequer fazer uma pergunta inteligente em SQL.
Fico me perguntando se os desenvolvedores vão tratar as permissões de tabela como parte essencial do projeto de segurança ou apenas como mais um campo de configuração que marcam sem pensar. Qual deveria ser o padrão para conjuntos de dados sensíveis: gravações controladas pelo proprietário ou linhas assinadas pelos usuários??
#SXT @SpaceandTime $SXT
#sxt $SXT @SpaceandTime #SXT