Actualización de Safe Network Dev 🇪🇸 15 septiembre 2022

Esta es una traducción automática. El original en inglés está aquí: Update 15 September, 2022

Esta semana nos fijamos en la cuestión de la autoridad. ¿Quién puede hacer qué y qué credenciales se requieren para hacerlo? El tema surge cuando buscamos simplificar el código, eliminando los patrones de filtrado de mensajes que ya no usamos y asegurando que los fundamentos sean lógicos y fáciles de entender.

Progreso general

@anselme implementó una capa de chismes para manejar instancias perdidas cuando el nuevo sistema DKG no termina y ahora está analizando casos en los que tenemos DKG divididos concurrentes que terminan juntos. Sin embargo, DKG parece bastante estable.

Y @roland prácticamente completó el cambio de SectionChain (una lista enlazada segura) al nuevo diseño de Section DAG. Un poco más de prueba y estamos allí.

@qi.ma ha estado buscando errores potenciales en FilesContainers, ya que las redes de comunicación destacaron algunos conflictos de versiones sospechosas recientemente.

También hemos estado investigando algunos problemas de conexión de clientes de los nodos, que parecen arrojar algunas respuestas. Y eliminando pasos de serialización innecesarios alrededor de OperationId, aligerando aún más la carga en los nodos.

Autoridad

Si piensas en la autoridad en términos de poder, podrías pensar que los ancianos, los viejos astutos de barba gris, tendrían la mayor autoridad. Después de todo, ellos son los que controlan todo lo que sucede en su sección, incluso tienen el poder de vida y muerte de otros nodos. Estarías equivocado. Cuando se trata de realizar cambios en la red, los nodos individuales no tienen autoridad individual alguna. Los adultos no tienen voz, mientras que los ancianos solo tienen autoridad como colectivo, por medio de un voto de umbral.

De hecho, el actor más poderoso es el cliente: el cliente es el rey, si se quiere. Esto se debe a que el cliente puede hacer cosas como editar datos mutables (contenedores) que posee y firmar la reemisión de un DBC. Los nodos son realmente solo mensajeros, que pasan información sobre operaciones y juicios de un lado a otro, y en su mayoría hacen lo que se les dice.

¿Por qué importa esto? Bueno, es importante porque queremos líneas divisorias claras sobre quién puede hacer qué. En la medida de lo posible, queremos que la autoridad esté implícita en los tipos de datos y las operaciones y que esté controlada por criptografía, no por jerarquías complejas, y queremos las estructuras de autorización más simples posibles.

Tipos de datos

Los permisos están integrados en los tipos de datos.
Datos inmutables
Cuando se trata de mutación, los fragmentos son impermeables a la autoridad. No hay ninguna autoridad en el planeta que le permita cambiar los datos. Por lo tanto, no necesitamos preocuparnos por diseñar una lógica de autorización para ellos.
Sin embargo, para almacenar un fragmento, necesitamos autorización, en este caso la proporciona la Sección en la que se almacenará y, una vez otorgada, esta autorización se aplica para siempre. SectionAuth es una clave de sección válida más una firma.

Datos mutables
Almacenar contenedores requiere SectionAuth, mientras que mutarlos requiere ClientAuth; solo el propietario debería poder cambiar sus datos. Por lo tanto, implícito en este tipo de datos es que requiere la firma de un cliente antes de poder cambiarlo. ClientAuth es una firma de cliente válida.

El otro tipo de datos mutables es el SectionTree, que es un árbol que se ramifica desde Génesis. Aquí la situación es un poco diferente ya que efectivamente hay múltiples propietarios (todas las secciones), pero cada sección solo puede agregar una hoja a su rama particular con su SectionAuth.

Los DBC son un poco más complejos porque requieren que un cliente autorice una reemisión (ClientAuth) y una sección para firmarlo (SectionAuth), pero nuevamente hasta que tenga esos dos bits de autoridad adjuntos, un DBC es efectivamente inútil.

Lo importante aquí es que para las operaciones de datos, los nodos son meros portadores de mensajes y el mensaje es independiente del portador. No nos importa de dónde viene el mensaje, y no nos importa quién lo firmó. Solo nos importa que el elemento de datos lleve el tipo correcto de firma (cliente o sección) más una clave.

En el ejemplo más simple, un fragmento de datos con una clave de firma de sección válida adjunta puede volar por todo el universo y, cuando regresa, la red debe aceptarlo, porque una firma de sección en los datos significa que existe para siempre.

Operaciones de datos

En los términos de la API REST, las operaciones de datos se ven así:
Las operaciones GET no requieren autorización alguna.
Las operaciones PUT requieren SectionAuth para el almacenamiento y una combinación de ClientAuth y SectionAuth para el pago.
Las operaciones POST requieren ClientAuth para mutar los contenedores SectionAuth para mutar las hojas individuales de SectionDAG

Las transferencias de tokens requieren una combinación de ClientAuth y SectionAuth.

Operaciones de red

Los cambios en la composición de una sección en términos de ancianos y adultos, divisiones, etc., todos requieren SectionAuth. Pero mientras que los nodos individuales no tienen ninguna autoridad en estos procesos, los ancianos al menos no son meros portadores de mensajes pasivos como lo son con los datos. Por ejemplo, si un anciano nota que un nodo se comporta de manera disfuncional, puede forzar una votación sobre si debed ser sancionado.

Para que esto funcione, los nodos deben ser identificables en ciertos casos, lo que significa que deben firmar los mensajes con sus claves públicas. Entonces, si un cliente envía una solicitud de un fragmento y ese fragmento llega tarde o hay alguna corrupción, la firma es una evidencia criptográfica irrefutable contra ese nodo y el cliente puede informar a los ancianos que es un error.

Y para DKG es vital que los mensajes que se envían entre mayores con sus acciones de voto estén autorizados. La autoridad del mensaje es la del remitente y se verifica con su firma en el mensaje. Esto se llama NodeAuth.

Está bien, pero ¿para qué es todo esto?

Al centrarnos en la autoridad y eliminar comprobaciones innecesarias, especialmente en los mensajes, estamos simplificando las operaciones en la medida de lo posible y confiando en la criptografía y los tipos de datos para que hagan el trabajo duro por nosotros. Todavía tenemos algunas firmas de mensajes innecesarias pendientes de iteraciones anteriores de la red, y todo esto tiene un costo de rendimiento además de crear confusión. Un diseño limpio y simple es un diseño eficiente.


Enlaces útiles

No dude en responder a continuación con enlaces a las traducciones de esta actualización para desarrolladores y los moderadores las agregarán aquí.

Como proyecto de código abierto, siempre estamos buscando retroalimentación, comentarios y contribuciones de la comunidad, así que no sea tímido, únase y creemos la red segura juntos.