Actualización de Safe Network Dev 🇪🇸 25 de noviembre de 2021

Esta es una traducción automática. El original en inglés está aquí: Update 25 November 2021

Todos estamos de acuerdo en que esta semana sería un buen momento para analizar lo que Safe trae a la mesa en términos de consenso distribuido. De hecho, algunos de nosotros pensamos que era una idea tonta, pero una supermayoría votó para seguir adelante, y eso es todo lo que importa :stuck_out_tongue_winking_eye:. Entonces, esta semana explicamos cómo Safe cierra la brecha entre blockchain y los protocolos que subyacen a las bases de datos distribuidas como Cassandra y AWS DynamoDB.

Progreso general

@ChrisO ha completado la tarea de liberación continua para sn y sn_api en el repositorio safe_network. Esto significa que estamos de vuelta en un lugar donde podemos fusionar libremente las confirmaciones y tener confianza en la versión posterior. Con esto en su lugar, @chrisO está pasando a mirar el CLI y estabilizarlo antes de incluirlo en las versiones.

David Rusu ha estado armando una demostración sobre firmas de anillo y Safe. Espere una actualización pronto (advertencia: será ‘pesado en las matemáticas’). :Hombre que corre:

@qi_ma, @yogesh y @lionel.faber han estado refactorizando la caja de DKG y safe_network (nuestra principal fuente actual de problemas, ya que las promociones para personas mayores se detienen antes de las siete) para reducir la cantidad de mensajes que se transmitirán y aumentar estabilidad de arranque y división de la sección. El trabajo continúa allí, pero definitivamente estamos llegando a los problemas subyacentes.

También se ha trabajado en habilitar la prioridad de manejo de mensajes para los nodos, aunque esto aún se está evaluando. Esto debería ayudarnos a asegurarnos de que los cambios más importantes se manejen con más atención que los mensajes menos importantes. Este bloqueo de mensajes de baja prioridad estuvo presente involuntariamente en la base de código menos concurrente, pero se perdió a medida que liberamos nodos para aprovechar más la CPU. Así que, con suerte, esto debería traer un poco de orden a las operaciones del nodo.

Consenso distribuido y cómo Safe cierra la brecha

El núcleo de Safe Network, y lo que lo hace especialmente útil para una amplia variedad de propósitos, es cómo logra un acuerdo entre los nodos distribuidos que pueden no ser confiables.

En la década de 1980, se pensaba que un acuerdo descentralizado sin referencia a un oráculo central era imposible, pero luego apareció Leslie Lamport para demostrar que todos estaban equivocados. De hecho, en realidad estaba tratando de demostrar que de hecho era imposible tener consistencia y tolerancia a fallas, pero luego tropezó con una respuesta, que era promover líderes temporales y garantizar el orden de operaciones en todo el sistema.

El algoritmo resultante fue Paxos, por el que Lamport finalmente ganó un Premio Turing. Paxos garantiza una eventual consistencia en una red distribuida donde algunas máquinas pueden no ser confiables. Significa que las redes pueden evitar tener un solo punto de falla: cualquier nodo, incluso un líder, puede abandonar y el sistema seguirá funcionando.

Paxos ha tenido un gran éxito y ha generado cientos de imitadores y variantes. Se usa principalmente para replicar datos de manera confiable entre máquinas distribuidas y es la base para bases de datos en la nube como AWS DynamoDB y Google Chubby.

Lo hace intentando decidir un orden total de operaciones. Hay dos etapas en una operación de Paxos: promesa y compromiso. Una promesa es un acuerdo para hacer algo y un compromiso es la acción de hacerlo. La mayoría de los nodos deben estar de acuerdo antes de hacer una promesa de mutar el estado o cambiar los permisos. También se necesita una mayoría para pasar de una promesa a un compromiso, por ejemplo, una escritura o un cambio de propiedad.

Debido a que las redes distribuidas son asíncronas, el orden se mantiene dando a cada operación un ID numérico y aumentando los ID con el tiempo. En el caso de un conflicto por una promesa, generalmente ganará el más nuevo (ID más alto).

En Paxos siempre hay un nodo líder. En el caso de una confirmación, el líder agrega cada operación a su registro y pide a los otros servidores que hagan lo mismo. Una vez que ha recibido respuesta de la mayoría de los servidores de su clúster, confirma el cambio.

Se elige un nuevo líder cuando el actual no responde dentro de cierto tiempo. Cuando esto sucede, cualquier nodo puede presentarse. Para convertirse en líder, un nuevo candidato debe recibir una mayoría de votos. Luego, debe actualizar sus registros sincronizándolos con otros nodos. Los nodos de votación envían sus registros con sus votos para facilitar esto, pero aún puede llevar mucho tiempo actualizarse, tiempo durante el cual el clúster está inactivo, lo que puede ser problemático.

Raft (2014), que se basa en Paxos (o más exactamente Multi-Paxos, la versión actualizada) simplifica el proceso de votación y otras operaciones, pero es esencialmente una modificación de Paxos. Raft ahora ha superado a Paxos en términos de actividad de proyectos.

Hasta ahora todo va bien, pero si bien Paxos / Raft son soluciones elegantes para el consenso distribuido, su implementación requiere muchos extras para que funcionen según lo planeado.

Cloudflare se basa en Raft y en 2020 sufrió una interrupción importante debido a que el proceso de elección de líder entró en unbucle dless. Para garantizar la vitalidad, también se requieren optimizaciones PreVote y CheckQuorum, además de muchas más. Ahora no es tan simple.

Ampliar la funcionalidad de Paxos y Raft y otras variantes los hace complejos, lo que en la industria tecnológica significa que se vuelven propietarios. Si solo Amazon sabe cómo configurar DynamoDB de manera confiable, Amazon no revelará ese secreto a toda prisa.

Pero el mayor inconveniente de estos algoritmos es su suposición de que los nodos no se confabulan, mienten o intentan subvertir el protocolo, es decir, no ocurren fallas bizantinas. Si es Amazon, es posible que pueda garantizar que, dado que controla su propio hardware y software, pero para redes públicas mixtas, no hay forma de que pueda hacerlo. Es por eso que no escuchas mucho sobre Paxos et al en el mundo de las criptomonedas, a pesar de que es la base de los Goliath tecnológicos.

Entra Satoshi

Los algoritmos descentralizados bizantinos tolerantes a fallas (BFT) están dominados por blockchain, que resolvió este difícil problema gracias al genio de Satoshi. Las cadenas de bloques están altamente ordenadas * y * BFT. Pero el orden total es esencial y eso bloquea o ralentiza el acceso múltiple y la concurrencia. Las cadenas de bloques no son sistemas de propósito general, sino diseñados específicamente para el intercambio de valor. Las cadenas de bloques no pueden reemplazar a Paxos y sus derivados porque están optimizados para asegurar y compartir transacciones, no operaciones de datos.

Hazte a un lado Satoshi, Safe Network está aquí

Seguro es diferente. Cierra la brecha entre las transacciones de las cadenas de bloques que se guardan para siempre y la gestión de datos distribuidos de Paxos y Raft.

Los datos se almacenan para siempre sin PoW pesado.

No hay un líder general al que atacar, ni siquiera uno temporal (como el ganador de PoW en una cadena de bloques). En cambio, la rendición de cuentas se distribuye entre las supermayorías de las secciones y estas consisten en grupos en constante cambio (pero acordados).

Luego tenemos el problema de la tolerancia a fallas. Paxos y Raft usan el concepto de tolerancia a fallas (CFT) por “choques”. Pero las redes públicas requieren tolerancia a fallas bizantina. La diferencia parece sutil pero no lo es. La tolerancia a fallas de bloqueo cubre cuántos nodos pueden fallar entre ejecuciones de mantenimiento, mientras que la tolerancia a fallas bizantina es cuántos nodos pueden volverse deshonestos en cualquier momento. CFT es calculable, BFT no.

Safe es BFT y está diseñado para estar listo para las condiciones del mundo real donde las cosas fallan y los malvados deambulan. La edad de los nodos garantiza que los nodos bizantinos pierdan poder rápidamente. Por el contrario, Paxos / Raft son atacados fácilmente al promover un líder que no responde o responde demasiado rápido. También dependen hasta cierto punto de los relojes del servidor para gestionar el consenso. Parecen ser simples (al igual que las redes Kademlia) pero necesitan muchas condiciones previas para que funcionen, incluido hardware y software confiables, sin cruce de NAT, etc.

Safe está completamente descentralizado. AE, BRB y CRDT eliminan el requisito de un acuerdo en toda la red para lograr la coherencia y no hay necesidad de un pedido total. Incluso Amazon admite que para los grandes sistemas distribuidos, el juego es una consistencia eventual, no un orden total (la velocidad de la luz es un límite estricto). Tratar de lograr un orden total a gran escala conduce inevitablemente a un bajo rendimiento.

Por lo tanto, Safe cruza muchos límites: una fuerte concurrencia eventual en una red pública, BFT de propósito general y datos permanentes.


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.