La descentralización no es negociable
Correcciones: Sisu.Cumulo
Traducción del original: https://massa.net/blog/post/0/
Las blockchains actuales que escalan a transacciones de altos rendimientos están centralizadas o son inseguras. En Massa, diseñamos una nueva arquitectura, llamada Blockclique, que escala el rendimiento de las transacciones hasta 10,000 transacciones por segundo sin sacrificar la descentralización ni la seguridad. Nuestra arquitectura se basa en la fragmentación de transacciones sobre un gráfico de bloques multiproceso. En esta publicación presentamos los conceptos principales de Blockclique. También puede sumergirse en el documento técnico o interactuar con la testnet en test.massa.net.
· Combinamos fragmentación de transacciones y una arquitectura de gráfico de bloques multiproceso que permite bloques paralelos con transacciones compatibles.
· Extendemos la regla de consenso de Nakamoto al caso de bloques paralelos, lo que permite un consenso seguro y descentralizado utilizando Proof-of-Stake.
· La arquitectura Blockclique puede manejar miles de transacciones por segundo, a la par de los sistemas financieros tradicionales.
Tenemos un problema de escalabilidad
Las blockchains actuales no son escalables. Para convertirse en alternativas viables a las soluciones financieras clásicas, las blockchains deberían poder manejar una serie de transacciones similares a las de los sistemas clásicos. Actualmente, Bitcoin permite solo 5 transacciones por segundo (tx/s) en toda la red, mientras que Ethereum permite 15–20 tx/s. Estos números no se acercan a los de los sistemas financieros clásicos. Por ejemplo, el sistema VISA procesó 111 mil millones de transacciones en 2017 (un promedio de 3500 tx/s). Como resultado, las blockchains pueden congestionarse fácilmente como lo demuestra el Cryptokitties hype.
¿Por qué? Estructura de datos y regla de consenso de Nakamoto
Las limitaciones de las blockchains se deben a su propio diseño. Una blockchain se define como la “mejor” cadena de un árbol de bloques, donde cada bloque hace referencia a un bloque padre en el árbol además de llevar un conjunto de transacciones.
Cuando un nodo crea un bloque, transmite el bloque a otros nodos de una red peer-to-peer, que a su vez lo retransmiten a otros nodos, y así sucesivamente hasta que la mayoría de los nodos son conscientes del bloque. Este proceso lleva tiempo, especialmente si los bloques son grandes. Por lo tanto, en un momento dado, diferentes nodos pueden conocer diferentes subconjuntos de bloques creados. Como resultado, dos nodos pueden transmitir dos bloques con el mismo bloque padre, incluso si son honestos. Esto se llama fork (bifurcación) y da lugar a dos cadenas alternativas de bloques que se originan en el mismo bloque ancestro.
Debido a que las cadenas alternativas pueden contener conjuntos de transacciones diferentes e incompatibles, los nodos deben acordar una única cadena común para lograr un consenso sobre las transacciones ejecutadas. Una forma elegante de lograr el consenso en una red descentralizada se conoce como la regla de consenso de Nakamoto. Desde el punto de vista de un nodo, la idea es calificar cada cadena del árbol de bloques asignándole una aptitud escalar, y solo producir nuevos bloques extendiendo la cadena de aptitud máxima. La cadena de máxima aptitud es la denominada “blockchain”: solo se consideran ejecutadas las transacciones que aparecen en bloques de la blockchain.
Para prevenir los ataques Sybil, la aptitud debe representar algo difícil de crear u obtener: un recurso. En los sistemas de Proof-of-Work como Bitcoin, la aptitud de una cadena se define como el trabajo computacional total realizado para crear todos sus bloques. En los sistemas Proof-of-Stake como Tezos, la aptitud de una cadena está vinculada al número total de monedas que se pusieron en juego en los bloques de la cadena. Nakamoto es la regla de consenso más utilizada para las cadenas de bloques descentralizadas, sin embargo, se han implementado muchos otros mecanismos de consenso. Para profundizar en los mecanismos de consenso, recomendamos comenzar aquí o aquí.
La regla de consenso de Nakamoto mantiene sin problemas a los nodos enfocados en una sola cadena de bloques común siempre que la velocidad a la que suceden las bifurcaciones siga siendo razonable. Un tamaño de bloque pequeño que se adapta a pocas transacciones y una frecuencia de bloque baja (1 MB cada 10 minutos en promedio en Bitcoin) aseguran que la mayor parte del tiempo, un bloque se pueda transmitir a toda la red antes de que se cree otro. Por lo tanto, la tasa de bifurcación es baja y el consenso es fácil, pero el número promedio de transacciones procesadas por segundo es limitado.
¿Superando los limites?
El número de tx/s se puede aumentar de una manera simple, ya sea aumentando la frecuencia del bloque (la velocidad a la que se crean los bloques) o aumentando el tamaño del bloque para adaptarse a más transacciones por bloque. Sin embargo, esto solo es posible en una pequeña parte.
Si la frecuencia del bloque aumenta demasiado (digamos un bloque de 1 MB por segundo), los bloques tienen poco tiempo para propagarse en la red antes de que se encuentre otro bloque: los nodos crean muchos bloques incompatibles, lo que lleva a una alta tasa de bifurcación y un error de consenso. Si, en cambio, el tamaño del bloque se aumenta demasiado (digamos a 1 GB), la transmisión del bloque se vuelve demasiado lenta, la tasa de bifurcación se vuelve alta y el consenso también falla.
Este problema se ilustra en el video a continuación, en el que simulamos una red de nodos que producen bloques en una configuración de Proof-of-Work.
https://massa.net/blog/post/0/media/ClassicalBlockchain.mp4
Blockchain con parámetros de Bitcoin (primera parte) o bloques muy grandes (segunda parte).
Varias criptomonedas han aumentado el número de transacciones por segundo al cambiar el tamaño del bloque o la frecuencia del bloque. Por ejemplo, Bitcoin Cash aumentó el tamaño del bloque en un factor de 8, aumentando el número de transacciones por segundo en la misma cantidad. Sin embargo, este número sigue siendo bastante bajo. Por lo tanto, para aumentar significativamente el número de transacciones procesadas, es necesario confiar en otros enfoques.
¿Restringir el tamaño de la red?
Una forma de reducir el tiempo necesario para transferir bloques en una red es limitar el tamaño de la red. Por ejemplo, en EOS, solo 21 productores de bloques autorizados pueden procesar transacciones, lo que arroja alrededor de 3000 a 4000 tx/s. En Ripple, una sola empresa decide quién puede convertirse en validador y producir bloques, de modo que el protocolo puede alcanzar unas 1500 tx/s.
Sin embargo, restringir el tamaño de la red es incompatible con la idea de una red descentralizada abierta en la que cualquier nodo puede participar sin permiso. Como lo acuñaron los desarrolladores de Ethereum, parece haber un trilema de escalabilidad en las arquitecturas blockchain actuales: una compensación entre descentralización, escalabilidad y seguridad.
El verdadero desafío es, por lo tanto, diseñar una cadena de bloques capaz de manejar miles de transacciones sin dejar de ser completamente descentralizada y segura, permitiendo que miles de nodos participen en la producción y el consenso de bloques.
¿Cambiar la estructura de datos y las reglas de consenso?
Recientemente, ha habido varios intentos de escalar monedas descentralizadas a través de cambios en la estructura de datos y reglas de consenso. Una línea de trabajo implementa la fragmentación de transacciones, que consiste en distribuir las transacciones en varios grupos (“fragmentos”) que se pueden procesar en paralelo, como en Elastico o Zilliqa. Sin embargo, en estos protocolos, los nodos que procesan diferentes fragmentos deben acordar regularmente una cadena de bloques común, lo que limita los beneficios del paralelismo del fragmento.
Otra línea de trabajo busca extender la estructura del árbol de bloques a una estructura de gráfico de bloques permitiendo que los bloques tengan más de un padre. Las primeras estructuras de gráficos de bloques acíclicos dirigidos (bloque DAG) se describen en [Lewenberg, 2015], [Sompolinsky, 2015] y [Sompolinsky, 2016]. Sin embargo, en esos protocolos, las transacciones de un bloque pueden ser incompatibles con las transacciones de otro bloque paralelo porque las transacciones en sí no están fragmentadas. Se requiere un proceso de votación adicional para ordenar transacciones y elegir cuáles se ejecutan.
La solución blockclique utilizada en Massa
Blockclique es una nueva arquitectura que combina la fragmentación de transacciones y un DAG de bloque multiproceso. Resuelve el problema de la escalabilidad paralelizando la estructura de datos y adaptando la regla de consenso.
https://massa.net/blog/post/0/media/Blockclique.mp4
Blockclique con 2 subprocesos: alto rendimiento de transacciones, baja tasa de bifurcación
Estructura de datos de Blockclique y regla de consenso
En la arquitectura Blockclique, los bloques se pueden crear en un número fijo de subprocesos. Un bloque creado en un hilo específico hace referencia a un bloque principal en cada uno de los hilos. La estructura de datos resultante es un gráfico acíclico dirigido multiproceso de bloques (DAG multiproceso).
Sin embargo, una dirección podría intentar gastar las mismas monedas en fees dos veces ejecutando transacciones en dos subprocesos paralelos al mismo tiempo. Blockclique evita ese doble gasto al permitir que una dirección determinada gaste monedas solo en un hilo específico (definido por los primeros bits de la dirección). Por lo tanto, los bloques de un hilo dado solo contienen transacciones con direcciones de entrada que pertenecen a ese hilo. Este proceso se conoce como fragmentación de transacciones. Aún así, la salida de una transacción puede ser cualquier dirección, independientemente del hilo de las direcciones de entrada.
Una propiedad única surge de esta combinación de fragmentación de transacciones y bloque DAG: los nodos pueden crear bloques en paralelo cuyas transacciones adjuntas son compatibles por construcción.
En esta nueva estructura de bloques, los nodos aún pueden crear bifurcaciones en subprocesos particulares creando dos bloques incompatibles en el mismo subproceso con el mismo padre en ese subproceso. Por lo tanto, ampliamos la regla de Nakamoto para permitir que los nodos alcancen un consenso sobre el conjunto global de bloques compatibles (llamado “ clique “) de máxima aptitud. Esta regla de consenso asegura que cada subproceso se comporte como una cadena de bloques normal y que los bloques que se encuentran en un subproceso también tengan en cuenta los bloques anteriores en otros subprocesos, al tiempo que permite ligeras desincronizaciones entre subprocesos.
A diferencia de las cadenas de bloques anteriores basadas en una arquitectura DAG, el DAG de bloque multiproceso con fragmentación de transacciones y una regla de consenso adaptada permite beneficiarse completamente de la paralelización de bloques y no requiere otorgar privilegios especiales a algunos nodos.
Resultados de la simulación
Probamos nuestras ideas a través de simulaciones, puedes ver el open-source aquí. Usando parámetros de red similares a los que se encuentran en Ethereum (ancho de banda de carga promedio de 32 Mb/s y latencia promedio de 100 ms, miles de nodos), demostramos que usando 32 subprocesos paralelos y un mecanismo de resistencia Sybil Proof-of-Stake, nuestra arquitectura puede soportar hasta 10,000 tx/s con tiempos de confirmación de transacciones del orden de 40 segundos.
Esta mejora se puede entender de la siguiente manera:
· En las cadenas de bloques estándar, los nodos deben tener el último bloque para comenzar a trabajar en el siguiente bloque (de lo contrario, crearían una bifurcación).
· En Blockclique, no es necesario tener todos los bloques más recientes para trabajar en uno nuevo. Los nodos crean bloques en subprocesos paralelos sin llevar a una bifurcación.
· La arquitectura Blockclique asegura la consistencia secuencial de los débitos de monedas para cada dirección, al tiempo que permite que los créditos de monedas se desincronicen ligeramente.
Por supuesto, hay mucho más en estos resultados. Probamos un gran conjunto de parámetros, demostramos que nuestra arquitectura es resistente a diferentes tipos de ataques e incluso propusimos mejoras a los esquemas de consenso existentes. Le recomendamos que lea el documento técnico si está interesado en obtener más detalles.
¡Dale una oportunidad!
¡Nuestra testnet está operativa! En test.massa.net, verá los bloques creados en tiempo real.
En este explorador, también puede interactuar con la testnet creando una billetera y recibiendo o enviando tokens.
Si tienes un equipo con Internet confiable, ¡ejecuta un nodo! Puedes seguir los pasos en nuestro Github.
Conclusion
Hemos demostrado que es posible resolver el problema de escalado de las blockchains utilizando fragmentación de transacciones en un gráfico de bloques multiproceso. Massa alcanza miles de transacciones por segundo sin poner en peligro la descentralización ni la seguridad del blockchain. Una cosa que no mencionamos es que nuestra arquitectura es compatible con contratos inteligentes que pueden implementarse dentro de un hilo o adaptarse para admitir subprocesos múltiples.
Creemos que Massa puede cumplir las promesas de una cadena de bloques escalable, segura y verdaderamente descentralizada. Esperamos que estés tan emocionado como nosotros y nos encantaría escuchar tus comentarios. ¡Ven a nuestro Telegram, Discord o Reddit para dar tu opinión!
Autores: Sébastien Forestier & Damir Vodenicaveric & Adrien Laversanne-Finot
Contacto: info@massa.net
Documento técnico: arxiv.org/pdf/1803.09029
Código fuente: github.com/massalabs/massa
Explorador Testnet Online: test.massa.net
Telegram: t.me/massanetwork
Discord: discord.com/invite/TnsJQzXkRN
Reddit: r/massa