Estaba leyendo la documentación de SXT y me quedé atascado en algo menos llamativo que las pruebas ZK: quién tiene realmente permiso para escribir en una tabla.
Cuando un desarrollador crea una tabla mediante una instrucción CREATE TABLE firmada, puede elegir entre tres modelos de escritura: escritura pública, donde cualquiera puede enviar filas; escritura con permisos del propietario, donde solo puede hacerlo el propietario o una lista de permitidos; y escritura verificada por el usuario, donde cada fila necesita la firma ECDSA/ED25519 del usuario, con verificación opcional mediante zkTLS o un indexador.
Me gusta que no se trate todo como un conjunto de permisos universal. Un feed público de actividad, un conjunto de datos propiedad de un protocolo y los registros enviados por usuarios tienen distintos supuestos de confianza. También se puede delegar la propiedad mediante tokens de autorización Biscuit, así que el control no tiene por qué permanecer en la billetera que creó la tabla.
No creo que esa flexibilidad sea un defecto en sí misma. Pero deja una decisión importante en manos del desarrollador: la capa de datos puede hacer cumplir la política que se le haya dado, pero no puede rescatar una aplicación de elegir una política demasiado permisiva. En el caso de activos tokenizados o registros de DeFi, una política de escritura deficiente podría tener consecuencias mucho antes de que alguien plantee una ingeniosa consulta SQL.
No dejo de preguntarme si los desarrolladores considerarán los permisos de las tablas una parte fundamental del diseño de seguridad o simplemente otro campo de configuración que marcan sin pensarlo. ¿Cuál debería ser la opción predeterminada para los conjuntos de datos sensibles: escrituras controladas por el propietario o filas firmadas por el usuario?
#SXT @SpaceandTime $SXT
#sxt $SXT @SpaceandTime #SXT
Cuando un desarrollador crea una tabla mediante una instrucción CREATE TABLE firmada, puede elegir entre tres modelos de escritura: escritura pública, donde cualquiera puede enviar filas; escritura con permisos del propietario, donde solo puede hacerlo el propietario o una lista de permitidos; y escritura verificada por el usuario, donde cada fila necesita la firma ECDSA/ED25519 del usuario, con verificación opcional mediante zkTLS o un indexador.
Me gusta que no se trate todo como un conjunto de permisos universal. Un feed público de actividad, un conjunto de datos propiedad de un protocolo y los registros enviados por usuarios tienen distintos supuestos de confianza. También se puede delegar la propiedad mediante tokens de autorización Biscuit, así que el control no tiene por qué permanecer en la billetera que creó la tabla.
No creo que esa flexibilidad sea un defecto en sí misma. Pero deja una decisión importante en manos del desarrollador: la capa de datos puede hacer cumplir la política que se le haya dado, pero no puede rescatar una aplicación de elegir una política demasiado permisiva. En el caso de activos tokenizados o registros de DeFi, una política de escritura deficiente podría tener consecuencias mucho antes de que alguien plantee una ingeniosa consulta SQL.
No dejo de preguntarme si los desarrolladores considerarán los permisos de las tablas una parte fundamental del diseño de seguridad o simplemente otro campo de configuración que marcan sin pensarlo. ¿Cuál debería ser la opción predeterminada para los conjuntos de datos sensibles: escrituras controladas por el propietario o filas firmadas por el usuario?
#SXT @SpaceandTime $SXT
#sxt $SXT @SpaceandTime #SXT