Compromisos de escalabilidad en Web3: La solución de Polkadot

En la actualidad, en la que la blockchain busca constantemente una mayor eficiencia, surge una cuestión clave: ¿cómo mantener la seguridad y la resiliencia del sistema mientras se mejora el rendimiento de escalado?

Este no solo es un desafío a nivel técnico, sino también una elección profunda en el diseño de la arquitectura. Para el ecosistema de Web3, un sistema más rápido que se basa en sacrificar la confianza y la seguridad a menudo tiene dificultades para sostener una innovación verdaderamente sostenible.

Polkadot, como un importante impulsor de la escalabilidad de Web3, ¿ha hecho concesiones en descentralización, seguridad o interoperabilidad de la red con su modelo de rollup? Este artículo analizará en profundidad los compromisos y equilibrios de Polkadot en el diseño de escalabilidad, y comparará sus soluciones con las de otras cadenas de bloques principales, explorando las diferentes elecciones de caminos entre rendimiento, seguridad y descentralización.

Desafíos en el diseño de la expansión de Polkadot

El equilibrio entre la elasticidad y la descentralización

La arquitectura de Polkadot depende de una red de validadores y de una cadena de retransmisión, ¿es posible que esto introduzca riesgos de centralización en ciertos aspectos? ¿Es posible que se forme un punto único de fallo o control que afecte a sus características de descentralización?

La ejecución de Rollup depende de un ordenante de la cadena de retransmisión conectado, cuya comunicación utiliza un mecanismo llamado protocolo collator. Este protocolo no requiere permisos ni confianza, cualquier persona con conexión a la red puede utilizarlo, conectando un pequeño número de nodos de la cadena de retransmisión y enviando solicitudes de cambio de estado de Rollup. Estas solicitudes se verificarán a través de algún núcleo de la cadena de retransmisión, siempre que se cumpla una condición: debe ser un cambio de estado válido, de lo contrario, el estado de ese Rollup no avanzará.

Compensación de la expansión vertical

Rollup puede lograr la escalabilidad vertical aprovechando la arquitectura de múltiples núcleos de Polkadot. Esta nueva capacidad se introduce a través de la función de "escalado elástico". Durante el proceso de diseño, descubrimos que, dado que la validación de bloques de rollup no se lleva a cabo de manera fija en un núcleo específico, esto podría afectar su elasticidad.

Dado que el protocolo para enviar bloques a la cadena de intermediación no requiere permiso ni confianza, cualquier persona puede enviar bloques a cualquiera de los núcleos asignados al rollup para su validación. Un atacante podría aprovechar esto para enviar repetidamente bloques legítimos que ya han sido validados a diferentes núcleos, consumiendo recursos de manera maliciosa y reduciendo así el rendimiento y la eficiencia general del rollup.

El objetivo de Polkadot es mantener la flexibilidad de los rollups y la utilización efectiva de los recursos de la cadena de retransmisión sin afectar las características clave del sistema.

¿Es confiable el Secuenciador?

Una solución simple es establecer el protocolo como "con licencia": por ejemplo, adoptando un mecanismo de lista blanca, o confiando por defecto en que los ordenadores no actuarán de manera maliciosa, garantizando así la actividad del rollup.

Sin embargo, en la filosofía de diseño de Polkadot, no podemos hacer ninguna suposición de confianza sobre el secuenciador, ya que necesitamos mantener las características de "sin confianza" y "sin permisos" del sistema. Cualquiera debería poder usar el protocolo de colador para enviar solicitudes de conversión de estado de rollup.

Polkadot: Solución sin compromisos

La solución finalmente elegida por Polkadot es: dejar que la función de transición de estado del rollup (Runtime) resuelva completamente el problema. El Runtime es la única fuente confiable de toda la información de consenso, por lo que debe declararse explícitamente en la salida en qué núcleo de Polkadot se debe realizar la validación.

Este diseño logra una doble garantía de flexibilidad y seguridad. Polkadot volverá a ejecutar las transiciones de estado del rollup en el proceso de disponibilidad y asegurará la corrección de la asignación del core a través del protocolo económico criptográfico ELVES.

Antes de que cualquier bloque de rollup escriba en la capa de disponibilidad de datos (DA) de Polkadot, un grupo de aproximadamente 5 validadores verificará primero su legitimidad. Reciben los recibos candidatos y las pruebas de validez presentados por el ordenante, que contienen el bloque de rollup y las pruebas de almacenamiento correspondientes. Esta información será procesada por la función de verificación de la cadena paralela y será reejecutada por los validadores en la cadena de retransmisión.

El resultado de la verificación incluye un selector de core, que se utiliza para especificar en qué core se debe validar el bloque. El validador comparará si este índice coincide con el core del que es responsable; si no coincide, el bloque será descartado.

Este mecanismo asegura que el sistema mantenga siempre las propiedades de no confianza y no permisos, evitando que actores maliciosos como los ordenadores manipulen las posiciones de validación, garantizando que incluso si el rollup utiliza múltiples núcleos, se mantenga la elasticidad.

seguridad

En el proceso de búsqueda de escalabilidad, Polkadot no ha comprometido la seguridad. La seguridad de los rollups está garantizada por la cadena de retransmisión, y solo se necesita un ordenante honesto para mantener la viabilidad.

Con el protocolo ELVES, Polkadot extiende su seguridad de manera completa a todos los rollups, validando todos los cálculos en el núcleo sin necesidad de imponer ninguna restricción o suposición sobre la cantidad de núcleos utilizados.

Por lo tanto, el rollup de Polkadot puede lograr una verdadera escalabilidad sin sacrificar la seguridad.

versatilidad

La expansión elástica no limitará la programabilidad de los rollups. El modelo de rollup de Polkadot soporta la ejecución de cálculos Turing completos en un entorno de WebAssembly, siempre que una ejecución única se complete en menos de 2 segundos. Gracias a la expansión elástica, la cantidad total de cálculos que se pueden ejecutar cada 6 segundos se incrementa, pero el tipo de cálculo no se ve afectado.

complejidad

Un mayor rendimiento y una menor latencia inevitablemente introducen complejidad, que es la única forma aceptable de compensación en el diseño de sistemas.

Rollup puede ajustar dinámicamente los recursos a través de la interfaz Agile Coretime para mantener un nivel de seguridad consistente. También deben cumplir con algunos requisitos de RFC103 para adaptarse a diferentes escenarios de uso.

La complejidad específica depende de la estrategia de gestión de recursos del rollup, que puede depender de variables en cadena o fuera de cadena. Por ejemplo:

• Estrategia simple: usar siempre una cantidad fija de core, o ajustar manualmente fuera de la cadena;

• Estrategia ligera: monitorear la carga de transacciones específicas en el mempool del nodo;

• Estrategia de automatización: configurar recursos mediante la llamada anticipada al servicio coretime a través de datos históricos y la interfaz XCM.

Aunque la automatización es más eficiente, los costos de implementación y prueba también aumentan significativamente.

interoperabilidad

Polkadot soporta la interoperabilidad entre diferentes rollups, y la escalabilidad flexible no afecta la capacidad de transmisión de mensajes.

La comunicación de mensajes entre rollups se realiza a través de la capa de transporte subyacente, y el espacio de bloques de comunicación de cada rollup es fijo, independientemente del número de núcleos asignados.

En el futuro, Polkadot también soportará la mensajería fuera de la cadena, utilizando la cadena de relevo como la capa de control, en lugar de la capa de datos. Esta actualización mejorará la capacidad de comunicación entre rollups junto con la elasticidad de la escalabilidad, lo que fortalecerá aún más la capacidad de escalado vertical del sistema.

¿Qué compromisos han hecho otros protocolos?

Como es bien sabido, la mejora del rendimiento a menudo viene a expensas de la descentralización y la seguridad. Sin embargo, desde la perspectiva del coeficiente de Nakamoto, incluso si algunos competidores de Polkadot tienen un nivel de descentralización más bajo, su rendimiento no es satisfactorio.

Cadena pública A

Una cadena de bloques pública A no utiliza la arquitectura de fragmentación de Polkadot o Ethereum, sino que implementa la escalabilidad mediante una arquitectura de alto rendimiento de capa única, apoyándose en la prueba histórica, el procesamiento paralelo de CPU y un mecanismo de consenso basado en líderes, con un TPS teórico de hasta 65,000.

Un diseño clave es su mecanismo de programación de líderes que es públicamente accesible y verificable:

• Al comienzo de cada epoch (aproximadamente dos días o 432,000 slots), se asignan slots según la cantidad de participación;

• Cuanto más se apueste, más se asignará. Por ejemplo, un validador que apueste el 1% recibirá aproximadamente el 1% de las oportunidades de crear bloques;

• Todos los productores de bloques se anuncian con anticipación, lo que aumenta el riesgo de que la red sufra ataques DDoS dirigidos y caídas frecuentes.

La historia demuestra que el procesamiento en paralelo requiere un hardware extremadamente alto, lo que lleva a la centralización de los nodos de validación. Cuantos más nodos estén en staking, mayor será la oportunidad de bloque para esos nodos, mientras que los nodos pequeños casi no tienen slots, lo que agrava aún más la centralización y aumenta el riesgo de que el sistema colapse después de un ataque.

La cadena de bloques A ha sacrificado la descentralización y la capacidad de resistencia a ataques en busca de TPS, su coeficiente de Nakamoto es solo 20, muy por debajo de los 172 de Polkadot.

Cadena pública B

Una cadena de bloques pública B afirma que su TPS puede alcanzar 104,715, pero este número se logró en una red de prueba privada, con 256 nodos, en condiciones ideales de red y hardware. Por otro lado, Polkadot ha alcanzado 128K TPS en una red pública descentralizada.

El mecanismo de consenso de cierta blockchain B presenta vulnerabilidades de seguridad: la identidad de los nodos de verificación de fragmentos se revela con antelación. El libro blanco de cierta blockchain B también señala claramente que, aunque esto puede optimizar el ancho de banda, también puede ser explotado maliciosamente. Debido a la falta de un mecanismo de "quiebra del jugador", un atacante puede esperar a que un fragmento esté completamente bajo su control o interrumpir a los validadores honestos a través de un ataque DDoS, lo que permite alterar el estado.

En comparación, los validadores de Polkadot son asignados de manera aleatoria y su identidad se revela con retraso, lo que impide que un atacante conozca de antemano la identidad de los validadores. El ataque debe apostar todo el control para tener éxito; tan pronto como un validador honesto inicie una disputa, el ataque fallará y el atacante perderá su participación.

Una cadena de bloques pública C

La cadena pública C utiliza una arquitectura de red principal + subred para la expansión, donde la red principal está compuesta por X-Chain (transferencias, ~4,500 TPS), C-Chain (contratos inteligentes, ~100--200 TPS) y P-Chain (gestión de validadores y subredes).

La TPS teórica de cada subred puede alcanzar aproximadamente 5,000, similar a la idea de Polkadot: reducir la carga de un solo shard para lograr la escalabilidad. Sin embargo, cierta cadena de bloques C permite a los validadores elegir libremente participar en la subred, y la subred puede establecer requisitos adicionales como geográficos y KYC, sacrificando la descentralización y la seguridad.

En Polkadot, todos los rollups comparten una garantía de seguridad unificada; mientras que la subred de una cadena pública C no tiene garantías de seguridad por defecto, y algunas incluso pueden ser completamente centralizadas. Si se desea aumentar la seguridad, aún se debe comprometer el rendimiento, y es difícil proporcionar un compromiso de seguridad determinista.

Ethereum

La estrategia de escalado de Ethereum apuesta por la escalabilidad en la capa de rollup, en lugar de resolver el problema directamente en la capa base. Esta forma de proceder, en esencia, no resuelve el problema, sino que lo transfiere a la capa superior del stack.

Optimistic Rollup

Actualmente, la mayoría de los Optimistic rollups son centralizados (algunos incluso tienen un solo secuenciador), lo que plantea problemas de seguridad insuficiente, aislamiento entre ellos y alta latencia (requieren esperar el período de prueba de fraude, que generalmente dura varios días).

ZK Rollup

La implementación de ZK rollup está limitada por la cantidad de datos que se pueden procesar en una sola transacción. La demanda computacional para generar pruebas de cero conocimiento es extremadamente alta, y el mecanismo de "el ganador se lo lleva todo" puede llevar a la centralización del sistema. Para garantizar el TPS, ZK rollup a menudo limita la cantidad de transacciones por lote, lo que puede provocar congestión en la red y un aumento de gas en momentos de alta demanda, afectando la experiencia del usuario.

En comparación, el costo de un ZK rollup Turing completo es aproximadamente 2x10^6 veces el del protocolo de seguridad económica central de Polkadot.

Además, el problema de la disponibilidad de datos en ZK rollup también agudiza sus desventajas. Para garantizar que cualquiera pueda verificar las transacciones, aún se necesita proporcionar datos completos de las transacciones. Esto generalmente depende de soluciones adicionales de disponibilidad de datos, lo que aumenta aún más los costos y las tarifas para los usuarios.

Conclusión

El final de la escalabilidad no debería ser un compromiso.

A diferencia de otras cadenas de bloques públicas, Polkadot no ha optado por sacrificar la centralización por rendimiento ni por confianza preestablecida por eficiencia, sino que ha logrado un equilibrio multidimensional entre seguridad, descentralización y alto rendimiento a través de la escalabilidad flexible, el diseño de protocolos sin permisos, una capa de seguridad unificada y un mecanismo flexible de gestión de recursos.

En la búsqueda de una mayor aplicación a gran escala, la "escalabilidad sin confianza" defendida por Polkadot podría ser la verdadera solución que respalde el desarrollo a largo plazo de Web3.