En la historia de blockchain que se escribirá en los libros de texto, el 2018 probablemente se conocerá como el año de fallas en la escala. La protesta por los sistemas blockchain escalables en el 2017 llevó a varias compañías a intentar resolver el problema de escalar y gradualmente darse cuenta de que no es tan simple.
Al concluir el año, el departamento de Ciencias de Blockchain de ModernToken presenta una visión general de los enfoques conocidos para mejorar la escalabilidad.
La gran carrera hacia la escalabilidad confiable comenzó con el estallido de nuevas empresas y campañas de financiación que intentaban llevar la tecnología de registros distribuidos (DLT) a las aplicaciones empresariales y al mundo real. La primera ola de proyectos que entraron triunfalmente en el mercado con la promesa de resolver específicamente este problema, como predijeron los expertos, han perdido espectacularmente sus objetivos.
No dejes de leer: El problema de Escala de Bitcoin, Explicado
Los ejemplos más notorios de esto son EOS —no son rápidos, no son una cadena de bloques, no son bizantinos tolerantes a fallas, según un informe de la firma de investigación Whiteblock— y IOTA, que ha reconocido públicamente su propia centralización y afirmó que nunca ha tenido una sólida visión de un protocolo descentralizado.
Un número de proyectos que no fueron presionados por su equipo de marketing para presentar sus productos aún están en funcionamiento, y esperamos ver su progreso —ya sea positivo o negativo— en el próximo año. Mientras tanto, vale la pena explorar el problema en sí y las formas en que la industria lo está abordando.
Resumen del problema
A grandes rasgos, el desafío para DLT se puede ilustrar con el llamado trilema de escalabilidad, acuñado por Vitalik Buterin: de las tres propiedades fundamentales de las redes distribuidas: descentralización, escalabilidad y seguridad, es difícil tener dos sin comprometer el tercero, a sabiendas o no.
Para bases de datos distribuidas con estado compartido, también existe el teorema de CAP, que se refiere a la disponibilidad (siempre obteniendo una respuesta oportuna a una consulta [query]), consistencia (siempre obteniendo la actualización más reciente o un mensaje de error) y tolerancia a la partición (¿el sistema pierde vitalidad si la red se divide?). Aparentemente, solo es posible mantener como máximo dos de estas propiedades.
Para ilustrarlo un poco mejor, si la red se divide a la mitad pero permanece operativa, uno tiene que elegir entre la consistencia y la disponibilidad, ya que la parte inalcanzable de la red puede hacer actualizaciones al estado que no se propagará a la parte accesible. El teorema tiene efectos variables también en las arquitecturas DLT.
El truco es dividir el estado (los datos que constituyen un registro [ledger], es decir, la lista de todos los balances actuales, la recopilación de los estados actuales de cada contrato inteligente, etc.) en partes, manteniendo las altas expectativas de seguridad y preservando la homogeneidad de las interacciones. Es decir, cualquier entidad (cuenta de usuario, contrato inteligente) necesita la capacidad de realizar transacciones con cualquier otra entidad, independientemente de los lugares relativos que terminen después de que el espacio del estado se compartimenta.
Puede interesarte: CEO de Abra: ruta de las criptoempresas hacia las remesas a escala será compleja pero exitosa
Líneas de consulta
Con la experiencia de la industria y la elaboración de la teoría acumulada hasta el momento, hay varios enfoques posibles para intentar construir sistemas de blockchain escalables. Algunos de ellos son solo vagos bocetos de ideas, mientras que para otros, numerosos proyectos y equipos de investigación están trabajando en arquitecturas de prototipos e implementaciones de prueba de concepto.
Cada enfoque tiene su propia manera de dividir el estado, y cada uno conlleva su propio conjunto de restricciones y cuellos de botella.
Para mantenernos enfocados en los conceptos, nos abstenemos de mencionar compañías y proyectos particulares, por lo que cualquier parecido con productos reales —vigentes o descontinuados— o eventos reales, es una coincidencia.
Fragmentación con prueba de participación
Sharding [fragmentación] ataca el problema de frente: en lugar de que cada nodo replique todo el estado, lo dividimos en segmentos (fragmentos) y los distribuimos entre grupos de nodos. Si una transacción solo tiene que ocurrir dentro del fragmento, su procesamiento es muy parecido al de una cadena de bloques clásica: los nodos del fragmento tienen el conocimiento suficiente para validarlo por completo. De lo contrario, es necesario que exista algún tipo de comunicación entre fragmentos. Esto trae tres grandes preguntas:
- ¿Cómo procesar transacciones de fragmentos cruzados, ya que la mayoría de los nodos solo mantienen el estado dentro de su fragmento?
- Para un nodo que solo mantiene el estado de su fragmento, ¿cómo sabe con certeza que el estado de otros fragmentos es coherente con las reglas de protocolo y es inmutable (es decir, cómo evitamos o procesamos las reorganizaciones de fragmentos, en relación con otros fragmentos)?
- ¿Cómo debería la red lidiar con la partición?
Uno de los puntos importantes cuando se trata de fragmentación es deshacerse de la prueba de trabajo (PoW). Ya que estamos tratando de construir una red homogénea que consta de una gran cantidad de partes, los recursos computacionales deberán extenderse y, por lo tanto, realizar un ataque del 51% en un fragmento en particular será demasiado fácil.
La prueba de participación, por otro lado, puede tener varias propiedades vitales: selección aleatoria de participantes por ronda (por lo que es difícil coordinar un ataque en un lugar), reducir el riesgo de comportamiento bizantino (a diferencia de la PoW, por lo que fallar en un ataque tiene principalmente costos de oportunidad) y el bloqueo de la participación (de modo que entrar y salir del juego de participación también tiene costos de tiempo).
Fragmentación con prueba de autoridad
La fragmentación en sí misma con este enfoque recuerda más a la fragmentación en las bases de datos clásicas, ya que más o menos se reduce a una parte confiable —o un pequeño grupo fijo de partes confiables— para mantener los datos.
Para los maximalistas de DLT, esta es una resignación conceptual, ya que una red de este tipo nunca puede carecer de permiso, es decir, completamente independiente de cualquier parte o grupo realísticamente corruptible o coercible.
Por otro lado, todavía puede interesar a grandes empresas e instituciones financieras, ofreciendo un medio para operaciones conjuntas con validación cruzada, siempre que haya actividades que tengan sentido comercial en el entorno mutuamente transparente. La ventaja es que los requisitos de confianza entre las contrapartes se pueden reducir, si no se eliminan por completo, siempre que las reglas de interacción se puedan codificar.
Sigue leyendo: CEO de SWIFT revela sus planes para lanzar PoC de pasarela con tecnología del consorcio blockchain R3
Prueba de participación delegada
Este diseño solo tiene un puñado de nodos maestros que validan las transacciones, emiten nuevos bloques y prometen mantener el estado actual completo. Los usuarios de la red no apuestan divisas en nuevos bloques (como en la prueba de la participación), sino que apuestan a sus validadores preferentes, lo que les da poder de voto.
La idea es que la competencia por estar en una lista de nodos maestros, asociada a altos ingresos en recompensas y tarifas en bloque, hará que los nodos maestros tengan un buen desempeño y tengan el mejor hardware posible, mucho más allá de una computadora personal.
Existen inquietudes sobre posibles tendencias a la centralización. Una de ellas es que dado que los usuarios solo reciben ROI en su participación de delegado si su delegado está en la lista del nodo maestro, es contraproducente dar participación a un extraño: hasta que ingresan, cualquier votante solo paga el costo de oportunidad de no dar participación a un interno en su lugar.
Como resultado, los usuarios internos tienen mayor poder, ya que solo deben preocuparse por la posible pérdida masiva de votos, pero probablemente puedan salirse con cosas bizantinas más pequeñas.
También hay incertidumbres acerca de la capacidad de auditoría: el gran estado que se mantiene dentro de un pequeño número de validadores pagados crea una situación en la que una auditoría completa desde fuera de la lista de nodos maestros es un gran gasto —ya que el hardware debe ser igualado— pero proporciona ingresos cero.
Algunas implementaciones prácticas de esta arquitectura conocida hasta la fecha también tienen opacidad del estado, por lo que un observador externo, incluso uno que esté dispuesto a comprometer recursos, nunca puede saber lo que está sucediendo dentro de los nodos maestros.
Interoperabilidad general
¿Qué pasaría si hubiera un protocolo entre cadenas de bloques para entregar de forma confiable las transacciones y el estado de cualquier cadena de bloques a cualquier otra blockchain?
Si hubiera existido, tal solución permitiría escalar en la medida en que el estado pueda dividirse en cadenas separadas. También significaría una gran flexibilidad: las cadenas de bloques pueden especializarse en su negocio particular o datos específicos y aún así tener la capacidad de interactuar con otras cadenas especializadas. Por ejemplo, una red de distribución de contenido que utiliza un medio de red de intercambio ya existente para las interacciones pagas.
Desafortunadamente, esta es una tarea muy compleja. El problema del que nadie habla es que debe manejar las bifurcaciones y la reorganización de la cadena para que la lógica de las cadenas de bloques arbitrarias que dependen de un estado externo no se rompa. Por ejemplo, debe asegurarse de que no sea posible duplicar el gasto en la cadena Aristóteles pagando por algo con una transacción de Platón y luego realizar un ataque del 51% en Platón, bifurcando la cadena y eliminando la transacción pagada.
Entre otros enfoques para escalar, la interoperabilidad de propósito general es quizás la que más se basa en la teoría de juegos y el diseño de incentivos. Poco o nada se sabe, a priori, de los sistemas que deberían estar conectados, y no se puede esperar que el consumidor de las transacciones retransmitidas las valide por sí mismas, de lo contrario no hay sentido en la retransmisión.
Puede interesarte: JPMorgan destaca mejoras marginales en el sistema de pago con tecnología de cadena de bloques
Plasma: cadenas de bloques jerárquicas con salidas en la capa base
Este concepto para DLT se propuso por primera vez en agosto del 2017. Se trata de varias capas de blockchains: la blockchain de la capa secundaria se ancla a la blockchain de la capa principal mediante un contrato inteligente especial que permite el retiro de activos, incluso si el operador de la capa secundaria es Bizantino.
Cada bloque de la capa secundaria está anclado en el contrato inteligente, junto con un árbol de Merkle de los activos de seguimiento del árbol. Los clientes de la capa secundaria deben supervisar el contrato de anclaje en la cadena principal y asegurarse de que el operador les envíe cada bloque que remiten a la cadena principal.
Si algo está mal (es decir, el operador no le envía a un usuario el bloque que acaban de verificar, o si el bloque no está formado correctamente), cada usuario puede iniciar un retiro, solicitando al contrato principal que devuelva sus activos en la cadena principal, proporcionando un prueba de la propiedad. Después de un período de espera, cuando el proceso se puede impugnar con una prueba de fraude, el retiro se completa y el activo se recupera en la cadena principal.
Si bien es un gran concepto, Plasma presenta varios de sus propios desafíos y problemas. En primer lugar, todas sus arquitecturas conocidas se basan en que el usuario almacena el historial completo de sus activos en la cadena y disputa activamente los intentos de retiro malicioso dentro de las ventanas de tiempo esperadas. La ventana es el equilibrio entre el tiempo que los activos están atascados en el contrato y la presencia regular del usuario.
En segundo lugar, los escenarios para retiros en masa, especialmente de múltiples cadenas de plasma en la misma cadena principal al mismo tiempo, son difíciles de razonar, y hasta ahora no se ha presentado ningún buen modelo de seguridad.
Por último, hasta ahora no se han propuesto arquitecturas que permitan que contratos inteligentes arbitrarios mantengan sus propios activos en la cadena de plasma. Solo hay unidades de activos no fungibles (Plasma Cash), unidades de activos fungibles en forma de canales de pago (Plasma Debit) y UTXOs arbitrarios (Plasma Mínima Viable).
Tener contratos con el estado y los activos en poder representa un problema teórico difícil, ya que cada escenario propuesto para quién y cómo podría impugnar exactamente un estado de contrato inteligente en caso de que el comportamiento bizantino de alguien ha sido propenso a ataques.
Sigue leyendo: Tecnología blockchain y la industria energética: Más descentralización y mayor eficiencia
Gráficos acíclicos directos
En lugar de construir una cadena de bloques, donde cada bloque nuevo se agrega en un extremo, ¿por qué no sembrar un árbol que se expanda en múltiples direcciones? De esta manera no habría necesidad de un lugar o grupo que tenga que validar agregando un bloque a un lugar en particular, lo que es un cuello de botella.
La carga computacional de actualizaciones se distribuye entre las hojas actuales del árbol. También podría significar que el almacenamiento se divide entre las sucursales que no necesitan ser monitoreadas todas a la vez, siempre y cuando estén vinculadas criptográficamente de alguna manera.
Con los DAG, es bastante difícil definir la finalidad de una manera no abusable. Si uno agrega o ve una transacción en una hoja, debe tener una fuerte expectativa de que la sucursal permanecerá dentro del estado de consenso, lo que probablemente significa que más transacciones necesitan extenderla (y, por lo tanto, confirmarla).
El problema, entonces, es garantizar una forma robusta para que los clientes realicen una selección de hojas que se desarrolle de forma bastante aleatoria en las ramas no bizantinas e ignore las bizantinas. Si para hacer eso el cliente tiene que monitorear todo el DAG, no hay escala, debido al espacio de estado. Si el cliente confía en un tercero, esa parte se convierte en un cuello de botella de confianza.
El desafío es encontrar una manera de hacer la selección aleatoria de hojas que se pueda demostrar que es justa y resistente a la manipulación bajo supuestos razonables. Y, por supuesto, está relacionado con la división del almacenamiento de estado.
¿Qué sigue?
Muchos de los proyectos que se han desarrollado a lo largo del año probablemente traerán primeros resultados tangibles en los próximos seis meses. Si bien no esperamos un protocolo completamente listo para la producción con escala horizontal y estado arbitrario —ni siquiera uno grandemente centralizado— es probable que la prueba de conceptos y las soluciones mínimamente viables lleguen al mercado pronto.
Y aunque el 2019 aún puede seguir siendo el año del cerdo de tierra, el 2020 en DLT probablemente será el año del armadillo escalador.
El artículo fue escrito por Collis Aventinus, un experto de Blockchain en Modern Token.