Hola, soy uno de los desarrolladores del protocolo cercano de blockchain fragmentado, y en este artículo quiero hablar sobre qué es el fragmentación de blockchain, cómo se implementa y qué problemas existen en los diseños de fragmentación de blockchain.
Es bien sabido que Ethereum, la cadena de bloques de propósito general más utilizada en el momento de escribir este artículo, solo puede procesar menos de 20 transacciones por segundo en la cadena principal. Esta limitación, junto con la popularidad de la red, conduce a altos precios del gas (el costo de ejecutar una transacción en la red) y largos tiempos de confirmación; a pesar del hecho de que en el momento de escribir este artículo, se produce un nuevo bloque aproximadamente cada 10-20 segundos, el tiempo promedio que se tarda en agregar una transacción a la cadena de bloques es de 1.2 minutos, según la ETH Gas Station . El bajo rendimiento, los altos precios y la alta latencia hacen que Ethereum no sea adecuado para ejecutar servicios que necesitan escalarse con la adopción.
¿Cuál es la razón principal del bajo rendimiento de Ethereum? La razón es que cada nodo en la red necesita procesar cada transacción individual. Los desarrolladores han propuesto muchas soluciones para abordar el problema del rendimiento a nivel de protocolo. Estas soluciones se pueden separar principalmente en aquellas que delegan toda la computación a un pequeño conjunto de nodos potentes, y aquellas que tienen cada nodo en la red solo hacen un subconjunto de la cantidad total de trabajo. Un caso extremo del primer enfoque es Thunder que tiene un solo nodo que procesa todas las transacciones y reclamaciones para lograr 1200 tx / seg, una mejora de 100x sobre Ethereum (sin embargo, no respaldo a Thunder ni atestiguo la validez de sus reclamaciones ) Algorand , SpaceMesh , Solana encajan en la categoría anterior, construyendo varias mejoras en el consenso y la estructura de la propia cadena de bloques para ejecutar significativamente más transacciones, pero aún limitado por lo que puede procesar una sola máquina (aunque muy poderosa).
El último enfoque, en el que el trabajo se divide entre todos los nodos participantes, se denomina fragmentación. Así es como Ethereum Foundation actualmente planea escalar Ethereum. En el momento de escribir esto, la especificación completa aún no se ha publicado. Aquí hay enlaces a una descripción detallada de las cadenas de fragmentos Ethereum y la cadena Beacon .
En esta publicación, resumo las ideas centrales de fragmentación de blockchain, en las que se basan tanto Near como la mayoría de otros protocolos fragmentados. La publicación posterior describirá temas más avanzados en sharding.
El fragmentación más simple, también conocido como beanstalk
Comencemos con el enfoque más simple para fragmentar, que a lo largo de este artículo llamaremos Beanstalk. Esto también es lo que Vitalik llama "escalar por mil monedas alternativas" en esta presentación.
En este enfoque, en lugar de ejecutar una cadena de bloques, ejecutaremos múltiples y llamaremos a cada una de estas cadenas de bloques un "fragmento". Cada fragmento tendrá su propio conjunto de validadores. Aquí y a continuación usamos un término genérico "validador" para referirnos a los participantes que verifican las transacciones y producen bloques, ya sea por minería, como en Prueba de trabajo, o mediante un mecanismo basado en la votación. Por ahora supongamos que los fragmentos nunca se comunican entre sí.
El diseño de Beanstalk, aunque simple, es suficiente para delinear algunos desafíos importantes en el fragmentación.
Validación de particionamiento y cadenas de baliza
El primer desafío es que cada fragmento tiene sus propios validadores, cada fragmento es ahora 10 veces menos seguro que toda la cadena. Entonces, si una cadena no fragmentada con validadores X decide bifurcarse en una cadena fragmentada y divide los validadores X en 10 fragmentos, cada fragmento ahora solo tiene validadores X / 10, y corromper un fragmento solo requiere corromper 5.1% (51% / 10) del número total de validadores.
Lo que nos lleva al segundo punto: ¿quién elige validadores para cada fragmento? Controlar el 5.1% de los validadores solo es perjudicial si todos esos 5.1% de los validadores están en el mismo fragmento. Si los validadores no pueden elegir en qué fragmento van a validar, es muy poco probable que un participante que controla el 5,1% de los validadores obtenga todos sus validadores en el mismo fragmento, lo que reduce en gran medida su capacidad de comprometer el sistema.
Casi todos los diseños de fragmentos de hoy dependen de alguna fuente de aleatoriedad para asignar validadores a los fragmentos. La aleatoriedad en blockchain en sí misma es un tema muy desafiante y merecería una publicación de blog por separado en una fecha posterior, pero por ahora supongamos que hay alguna fuente de aleatoriedad que podemos usar.
Tanto la aleatoriedad como la asignación de validadores requieren un cálculo que no es específico de ningún fragmento en particular. Para ese cálculo, prácticamente todos los diseños existentes tienen una cadena de bloques separada que se encarga de realizar las operaciones necesarias para el mantenimiento de toda la red. Además de generar números aleatorios y asignar validadores a los fragmentos, estas operaciones a menudo también incluyen recibir actualizaciones de los fragmentos y tomar instantáneas de ellos, procesar estacas y recortar en los sistemas de Prueba de estaca y reequilibrar los fragmentos cuando se admite esa característica. Dicha cadena se llama cadena Beacon en Ethereum y Near, una cadena Relay en PolkaDot y el Cosmos Hub en Cosmos.
A lo largo de esta publicación nos referiremos a dicha cadena como una cadena Beacon . La existencia de la cadena Beacon nos lleva al siguiente tema interesante, el fragmentación cuadrática.
Fragmentación cuadrática
Sharding a menudo se anuncia como una solución que se escala infinitamente con el número de nodos que participan en la operación de la red. Si bien en teoría es posible diseñar una solución de fragmentación de este tipo, cualquier solución que tenga el concepto de una cadena Beacon no tiene una escalabilidad infinita. Para entender por qué, tenga en cuenta que la cadena Beacon tiene que hacer algunos cálculos de contabilidad, como asignar validadores a fragmentos o tomar instantáneas de bloques de cadena de fragmentos, que es proporcional al número de fragmentos en el sistema. Dado que la cadena Beacon es en sí misma una cadena de bloques única, con un cómputo limitado por las capacidades computacionales de los nodos que lo operan, la cantidad de fragmentos es naturalmente limitada.
Sin embargo, la estructura de una red fragmentada otorga un efecto multiplicador a cualquier mejora en sus nodos. Considere el caso en el que se realiza una mejora arbitraria en la eficiencia de los nodos en la red que les permitirá tiempos de procesamiento de transacciones más rápidos.
Si los nodos que operan la red, incluidos los nodos en la cadena Beacon, se vuelven cuatro veces más rápidos, entonces cada fragmento podrá procesar cuatro veces más transacciones, y la cadena Beacon podrá mantener 4 veces más fragmentos. El rendimiento en todo el sistema aumentará en un factor de 4 x 4 = 16, de ahí el nombre de fragmentación cuadrática .
Es difícil proporcionar una medición precisa de cuántos fragmentos son viables hoy en día, pero es poco probable que en un futuro previsible las necesidades de rendimiento de los usuarios de blockchain superen las limitaciones del fragmentación cuadrática. La gran cantidad de nodos necesarios para operar un volumen de fragmentos de manera segura es un orden de magnitud mayor que la cantidad de nodos que operan todas las cadenas de bloques combinadas hoy en día.
Sin embargo, si queremos construir protocolos a prueba de futuro, podría valer la pena comenzar a investigar soluciones a este problema hoy. La propuesta más desarrollada a partir de ahora es el fragmento exponencial, en el que los fragmentos mismos están formando un árbol, y cada fragmento principal está orquestando una serie de fragmentos secundarios, mientras que puede ser hijo de algún otro fragmento.
Se sabe que Vlad Zamfir de la Fundación Ethereum está trabajando en un diseño de fragmentación que no involucra una cadena de baliza; Trabajé con él en uno de los prototipos, cuyo resumen detallado está aquí .
Fragmentación del estado
Hasta ahora no hemos definido muy bien qué es exactamente y qué no está separado cuando una red se divide en fragmentos. Específicamente, los nodos en la cadena de bloques realizan tres tareas importantes: no solo 1) procesan transacciones, también 2) retransmiten transacciones validadas y bloques completados a otros nodos y 3) almacenan el estado y el historial de todo el libro mayor de la red. Cada una de estas tres tareas impone un requisito creciente en los nodos que operan la red:
- La necesidad de procesar transacciones requiere más potencia de cómputo con el mayor número de transacciones que se procesan;
- La necesidad de retransmitir transacciones y bloques requiere más ancho de banda de red con el mayor número de transacciones que se retransmiten;
- La necesidad de almacenar datos requiere más almacenamiento a medida que crece el estado. Es importante destacar que, a diferencia de la potencia de procesamiento y la red, el requisito de almacenamiento aumenta incluso si la tasa de transacción (número de transacciones procesadas por segundo) permanece constante.
De la lista anterior, puede parecer que el requisito de almacenamiento sería el más urgente, ya que es el único que se incrementa con el tiempo, incluso si el número de transacciones por segundo no cambia, pero en la práctica el requisito más urgente hoy en día. es la potencia de cálculo El estado completo de Ethereum a partir de este escrito es de 100 GB, fácilmente manejable por la mayoría de los nodos. Pero la cantidad de transacciones que Ethereum puede procesar es de alrededor de 20, órdenes de magnitud menos de lo que se necesita para muchos casos de uso práctico.
Zilliqa es el proyecto más conocido que fragmenta el procesamiento pero no el almacenamiento. El fragmentación del procesamiento es un problema más fácil porque cada nodo tiene el estado completo, lo que significa que los contratos pueden invocar libremente otros contratos y leer cualquier información de la cadena de bloques. Se necesita una ingeniería cuidadosa para asegurarse de que las actualizaciones de varios fragmentos que actualizan las mismas partes del estado no entren en conflicto. En esos aspectos, Zilliqa está adoptando un enfoque muy simplista, cuyas críticas se pueden encontrar en esta publicación .
Si bien se propuso fragmentar el almacenamiento sin fragmentar el procesamiento, no conozco ningún proyecto que funcione en él. Por lo tanto, en la práctica, el fragmentación del almacenamiento, o fragmentación de estado, casi siempre implica fragmentación del procesamiento y fragmentación de la red.
Prácticamente, bajo Fragmento de estado, los nodos en cada fragmento están construyendo su propia cadena de bloques que contiene transacciones que afectan solo a la parte local del estado global asignado a ese fragmento. Por lo tanto, los validadores en el fragmento solo necesitan almacenar su parte local del estado global y solo ejecutar, y como tal solo retransmitir, las transacciones que afectan su parte del estado. Esta partición reduce linealmente el requisito de toda la potencia de cómputo, el almacenamiento y el ancho de banda de la red, pero presenta nuevos problemas, como la disponibilidad de datos y las transacciones de fragmentos cruzados, los cuales cubriremos a continuación.
Transacciones de fragmentos cruzados
Beanstalk como modelo no es un enfoque muy útil para fragmentar, porque si los fragmentos individuales no pueden comunicarse entre sí, no son mejores que múltiples cadenas de bloques independientes. Incluso hoy, cuando el fragmentación no está disponible, existe una gran demanda de interoperabilidad entre varias blockchains.
Consideremos por ahora solo transacciones de pago simples, donde cada participante tiene una cuenta en exactamente un fragmento. Si se desea transferir dinero de una cuenta a otra dentro del mismo fragmento, los validadores de ese fragmento pueden procesar completamente la transacción. Sin embargo, si Alice, que reside en el fragmento n. ° 1, quiere enviar dinero a Bob que reside en el fragmento n. ° 2, ni los validadores en el fragmento n. ° 1 (no podrán acreditar la cuenta de Bob) ni los validadores en el fragmento n. ° 2 ( no podrán debitar la cuenta de Alice) puede procesar la transacción completa.
Hay dos familias de enfoques para las transacciones entre fragmentos:
- Sincrónico : cada vez que se necesita ejecutar una transacción de fragmentos cruzados, los bloques en fragmentos múltiples que contienen la transición de estado relacionada con la transacción se producen todos al mismo tiempo, y los validadores de fragmentos múltiples colaboran en la ejecución de tales transacciones. La propuesta más detallada que conozco es Merge Blocks, que se describe aquí .
- Asíncrono : una transacción de fragmentos cruzados que afecta a múltiples fragmentos se ejecuta en esos fragmentos de forma asíncrona, el fragmento de "Crédito" ejecuta su mitad una vez que tiene evidencia suficiente de que el fragmento de "Débito" ha ejecutado su parte. Este enfoque tiende a ser más frecuente debido a su simplicidad y facilidad de coordinación. Este sistema se propone hoy en Cosmos, Ethereum Serenity, Near, Kadena y otros. Un problema con este enfoque radica en que si los bloques se producen de forma independiente, existe una probabilidad distinta de cero de que uno de los múltiples bloques quede huérfano, por lo que la transacción solo se aplica parcialmente. Considere la figura a continuación que muestra dos fragmentos que encontraron una bifurcación y una transacción de fragmentos cruzados que se registró en los bloques A y X 'correspondientemente. Si las cadenas AB y V'-X'-Y'-Z 'terminan siendo canónicas en los fragmentos correspondientes, la transacción está completamente finalizada. Si A'-B'-C'-D 'y VX se vuelven canónicos, entonces la transacción se abandona por completo, lo cual es aceptable. Pero si, por ejemplo, AB y VX se vuelven canónicos, entonces una parte de la transacción se finaliza y otra se abandona, creando una falla de atomicidad. Cubriremos cómo se aborda este problema en los protocolos propuestos en la segunda parte, cuando cubramos los cambios en las reglas de elección de la bifurcación y los algoritmos de consenso propuestos para los protocolos fragmentados.
Tenga en cuenta que la comunicación entre cadenas también es útil fuera de las blockchains fragmentadas. La interoperabilidad entre cadenas es un problema complejo que muchos proyectos están tratando de resolver. En las cadenas de bloques fragmentadas, el problema es algo más fácil ya que la estructura de bloques y el consenso son los mismos en todos los fragmentos, y hay una cadena de baliza que se puede usar para la coordinación. Sin embargo, en una cadena de bloques fragmentada, todas las cadenas de fragmentos son iguales, mientras que en el ecosistema global de cadenas de bloques hay muchas cadenas de bloques diferentes, con diferentes casos de uso objetivo, descentralización y garantías de privacidad.
La construcción de un sistema en el que un conjunto de cadenas tenga diferentes propiedades pero use un consenso y una estructura de bloques suficientemente similares y tenga una cadena de baliza común podría permitir un ecosistema de cadenas de bloques heterogéneas que tengan un subsistema de interoperabilidad funcional. Es poco probable que dicho sistema tenga rotación de validador, por lo que se deben tomar algunas medidas adicionales para garantizar la seguridad. Tanto Cosmos como PolkaDot son efectivamente tales sistemas. Este artículo escrito por Zaki Manian de Cosmos proporciona una descripción detallada y una comparación de los aspectos clave de los dos proyectos.
Comportamiento malicioso
Ahora tiene una buena comprensión de cómo se implementa el fragmentación, incluidos los conceptos de la cadena de baliza, las rotaciones del validador y las transacciones de fragmentos cruzados.
Con toda esa información, hay una última cosa importante a considerar. Específicamente, qué comportamiento de confrontación pueden ejercer los validadores maliciosos.
Horquillas maliciosas
Un conjunto de validadores maliciosos podría intentar crear una bifurcación. Tenga en cuenta que no importa si el consenso subyacente es BFT o no, corromper un número suficiente de validadores siempre hará posible crear una bifurcación.
Es significativamente más probable que se corrompa más del 50% de un solo fragmento, que que se corrompa más del 50% de toda la red (profundizaremos en estas probabilidades en la segunda parte). Como se discutió anteriormente, las transacciones de fragmentos cruzados implican ciertos cambios de estado en fragmentos múltiples, y los bloques correspondientes en dichos fragmentos que aplican dichos cambios de estado deben estar todos finalizados (es decir, aparecer en las cadenas seleccionadas en sus fragmentos correspondientes), o todos quedar huérfanos. (es decir, no aparece en las cadenas seleccionadas en sus fragmentos correspondientes). Dado que, en general, la probabilidad de que los fragmentos se corrompan no es insignificante, no podemos suponer que las horquillas no sucederán incluso si se alcanza un consenso bizantino entre los validadores de fragmentos, o si se produjeron muchos bloques en la parte superior del bloque con el cambio de estado .
Este problema tiene múltiples soluciones, la más común es la reticulación ocasional del último bloque de cadena de fragmentos con la cadena de baliza. La regla de elección de la bifurcación en las cadenas de fragmentos se cambia para preferir siempre la cadena que está entrecruzada, y solo aplica la regla de elección de la bifurcación específica de fragmento para los bloques que se publicaron desde el último enlace cruzado.
Aprobar bloques inválidos
Un conjunto de validadores podría intentar crear un bloque que aplique la función de transición de estado incorrectamente. Por ejemplo, comenzando con un estado en el que Alice tiene 10 tokens y Bob tiene 0 tokens, el bloque puede contener una transacción que envía 10 tokens de Alice a Bob, pero termina con un estado en el que Alice tiene 0 tokens y Bob tiene 1000 fichas
En una cadena de bloques clásica no fragmentada, tal ataque no es posible, ya que todos los participantes en la red validan todos los bloques, y el bloque con una transición de estado no válida será rechazado por los otros productores de bloques y los participantes de la red. que no crean bloques Incluso si los validadores maliciosos continúan creando bloques encima de un bloque tan inválido más rápido que los validadores honestos construyen la cadena correcta, por lo que la cadena con el bloque inválido es más larga, no importa, ya que cada participante que está usando la cadena de bloques para cualquier propósito valida todos los bloques y descarta todos los bloques construidos encima del bloque no válido.
En la figura anterior hay cinco validadores, tres de los cuales son maliciosos. Crearon un bloque no válido A ', y luego continuaron construyendo nuevos bloques encima de él. Dos validadores honestos descartaron A 'como inválido y estaban construyendo sobre el último bloque válido conocido por ellos, creando una bifurcación. Como hay menos validadores en la bifurcación honesta, su cadena es más corta. Sin embargo, en la cadena de bloques clásica no fragmentada, cada participante que usa blockchain para cualquier propósito es responsable de validar todos los bloques que reciben y volver a calcular el estado. Por lo tanto, cualquier persona que tenga algún interés en la cadena de bloques observará que A 'no es válido y, por lo tanto, también descartará inmediatamente B', C 'y D', por lo que tomará la cadena AB como la cadena válida más larga actual.
Sin embargo, en una cadena de bloques fragmentada, ningún participante puede validar todas las transacciones en todos los fragmentos, por lo que deben tener alguna forma de confirmar que en ningún momento de la historia de cualquier fragmento de la cadena de bloques no se haya incluido ningún bloque no válido.
Tenga en cuenta que, a diferencia de las horquillas, la reticulación a la cadena Beacon no es una solución suficiente, ya que la cadena Beacon no tiene la capacidad de validar los bloques. Solo puede validar que un número suficiente de validadores en ese fragmento firmó el bloque (y como tal atestiguó su corrección).
Solo conozco dos soluciones a este problema, ninguna de las cuales es realmente satisfactoria hoy:
- Tenga algún mecanismo razonable que alertará al sistema si se intenta aplicar la transición de estado de manera incorrecta. Asumiendo que cada fragmento está ejecutando algún tipo de consenso BFT, mientras el número de validadores maliciosos en un fragmento particular sea menor que ⅔, al menos un validador honesto necesitaría dar fe de un bloque y verificar que la función de transición de estado sea aplicado correctamente Si más de ⅔ de los nodos son maliciosos, pueden finalizar un bloque sin la participación de un solo nodo honesto. Suponiendo que al menos un nodo en el fragmento no es malicioso, se necesita algún mecanismo que permita a dichos nodos monitorear qué bloques se están produciendo y tener tiempo suficiente para desafiar a los nodos con una transición de estado no válida.
- Tenga alguna información en los bloques que sea suficiente para demostrar que la transición de estado se aplica correctamente pero que es significativamente más barata de validar que la aplicación real de la función de transición de estado. El mecanismo más cercano para lograrlo es zk-SNARKs (aunque realmente no necesitamos la parte "zk", o conocimiento cero, una SNARK que no sea zk sería suficiente), pero los zk-SNARK son notoriamente lentos para calcular en este punto
En la actualidad, muchos protocolos suponen que con la rotación adecuada del validador y un consenso tolerante a fallos bizantinos, no son posibles bifurcaciones ni transiciones de estado inválidas. La razón por la cual esta suposición no es razonable es un tema para un artículo separado.
Outro
Escribo mucho sobre blockchains y sharding, y también tenemos una serie de videos donde hablamos con los fundadores de protocolos escalables, como Cosmos y Solana, con inmersiones profundas tecnológicas. Puedes seguirme en twitter aquí .