Compromisos de escalabilidad: la elección entre Polkadot y Web3

En la actualidad, en la que la tecnología blockchain busca constantemente mejorar la eficiencia, surge una pregunta clave: ¿cómo mejorar la escalabilidad sin sacrificar la seguridad y la resiliencia del sistema? Este no solo es un desafío a nivel técnico, sino una profunda elección de diseño arquitectónico. Para el ecosistema Web3, un sistema más rápido que se base en sacrificar la confianza y la seguridad a menudo resulta difícil de sostener para una innovación verdaderamente sostenible.

Como un impulsor importante de la escalabilidad en Web3, ¿ha hecho Polkadot algunas concesiones en su búsqueda de alta capacidad de procesamiento y baja latencia? ¿Su modelo de rollup ha hecho compromisos en descentralización, seguridad o interoperabilidad de la red? Este artículo analizará en profundidad las decisiones y compromisos de Polkadot en el diseño de escalabilidad y comparará sus soluciones con las de otras cadenas de bloques principales, explorando sus diferentes elecciones en 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 una cadena de retransmisión, lo que podría introducir riesgos de centralización en ciertos aspectos? ¿Es posible que se forme un punto único de fallo o control que afecte sus características de descentralización?

La ejecución de Rollup depende de un ordenante de la cadena de retransmisión conectada, y su comunicación utiliza un mecanismo llamado protocolo collator. Este protocolo es completamente sin permisos y sin 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 serán verificadas por algún core de la cadena de retransmisión, siempre y cuando cumplan con un requisito: deben ser cambios de estado válidos, de lo contrario, el estado de ese rollup no será avanzado.

Compromisos de escalado vertical

Rollup puede lograr la escalabilidad vertical aprovechando la arquitectura multicore de Polkadot. Esta nueva capacidad fue introducida por la función de "escalabilidad elástica". Durante el proceso de diseño, se descubrió que, dado que la validación de bloques rollup no se ejecuta de manera fija en un core específico, esto podría afectar su elasticidad.

Dado que el protocolo para enviar bloques a la cadena de retransmisión es sin permisos y sin confianza, cualquier persona puede enviar bloques a cualquier core asignado al rollup para su verificación. Un atacante podría aprovechar esto para enviar repetidamente bloques legítimos que ya han sido verificados a diferentes cores, 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 relevos sin afectar las características clave del sistema.

¿Es confiable Sequencer?

Una solución sencilla es configurar el protocolo como "con licencia": por ejemplo, implementar un mecanismo de lista blanca, o confiar 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 debemos mantener las características de "sin confianza" y "sin permisos" del sistema. Cualquiera debería poder utilizar el protocolo collator para enviar solicitudes de cambios de estado de rollup.

Polkadot: Una solución sin compromisos

La solución final elegida por Polkadot es: dejar que la función de transición de estado del rollup (Runtime) resuelva completamente el problema. Runtime es la única fuente confiable de toda la información de consenso, por lo que debe declararse claramente 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 garantizará la corrección de la asignación del core a través del protocolo económico de ELVES.

Antes de que se escriban los datos de Polkadot en cualquier bloque de rollup, un grupo de aproximadamente 5 validadores verificará su legalidad. Reciben los recibos candidatos y las pruebas de validez enviados 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 validación incluye un selector de núcleo, que se utiliza para especificar en qué núcleo se debe validar el bloque. El validador comparará si este índice coincide con el núcleo del que es responsable; si no coincide, el bloque será descartado.

Este mecanismo asegura que el sistema mantenga siempre las propiedades de ser sin confianza y sin permisos, evitando que actores maliciosos como los ordenadores manipulen la posición de verificación, garantizando que incluso si el rollup utiliza múltiples núcleos, pueda mantener su resiliencia.

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.

A través del protocolo ELVES, Polkadot extiende completamente su seguridad 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, los rollups de Polkadot pueden lograr una verdadera escalabilidad sin sacrificar la seguridad.

versatilidad

La expansión elástica no limitará la programabilidad del rollup. El modelo de rollup de Polkadot admite la ejecución de cálculos Turing-completos en un entorno de WebAssembly, siempre que la ejecución única se complete en menos de 2 segundos. Con la expansión elástica, la cantidad total de cálculos ejecutables en cada ciclo de 6 segundos se incrementa, pero el tipo de cálculo no se ve afectado.

complejidad

Una mayor capacidad de procesamiento y una menor latencia inevitablemente introducen complejidad, que es la única forma aceptable de compensación en el diseño del sistema.

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 la 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: siempre usa una cantidad fija de core, o ajusta manualmente fuera de la cadena;

• Estrategia ligera: Monitorear cargas de transacciones específicas en el mempool del nodo;

• Estrategia de automatización: Configurar recursos anticipadamente a través de datos históricos y la interfaz XCM para invocar el servicio coretime.

Aunque el método automatizado 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 el rendimiento del intercambio de mensajes.

La comunicación de mensajes entre rollups se implementa mediante la capa de transporte subyacente, y el espacio de bloques de comunicación de cada rollup es fijo, sin relación con el número de núcleos asignado.

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

¿Qué compromisos han hecho otros protocolos?

Como todos saben, la mejora del rendimiento a menudo se logra a costa de la descentralización y la seguridad. Sin embargo, desde la perspectiva del coeficiente de Nakamoto, incluso si algunos competidores de Polkadot tienen un grado de descentralización inferior, su rendimiento no es satisfactorio.

Solana

Solana no utiliza la arquitectura de fragmentación de Polkadot o Ethereum, sino que implementa escalabilidad a través de una arquitectura de alto rendimiento de una sola capa, confiando en la prueba histórica (PoH), 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 la apuesta;

• Cuanto más se stakee, más se asigna. Por ejemplo, un validador que stakee el 1% obtendrá aproximadamente el 1% de oportunidades de bloque.

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

PoH y el procesamiento paralelo requieren 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 producción de bloques, 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 tras un ataque.

Solana sacrifica la descentralización y la resistencia a ataques en busca de TPS, su coeficiente de Nakamoto es de solo 20, muy por debajo de los 172 de Polkadot.

TON

TON afirma que puede alcanzar 104,715 TPS, 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 TON presenta vulnerabilidades de seguridad: la identidad de los nodos de validación de fragmentos se revela con anticipación. El libro blanco de TON 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 apostador", los atacantes pueden esperar a que un fragmento esté completamente bajo su control, o interrumpir a los validadores honestos mediante un ataque DDoS, alterando así el estado.

En comparación, los validadores de Polkadot son asignados aleatoriamente y se revelan con retraso, por lo que los atacantes no pueden conocer de antemano la identidad de los validadores. El ataque debe apostar todo el control para tener éxito; siempre que haya un validador honesto que inicie una disputa, el ataque fracasará y el atacante perderá su participación.

Avalanche

Avalanche utiliza una arquitectura de red principal + subred para su escalabilidad, 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).

El TPS teórico de cada subred puede alcanzar ~5,000, similar a la idea de Polkadot: reducir la carga de un solo shard para lograr escalabilidad. Pero Avalanche permite a los validadores elegir libremente participar en subredes, y las subredes pueden establecer requisitos adicionales como geográficos, KYC, etc., sacrificando así la descentralización y la seguridad.

En Polkadot, todos los rollups comparten una garantía de seguridad unificada; mientras que las subredes de Avalanche no tienen una garantía de seguridad por defecto, algunas incluso pueden ser completamente centralizadas. Si se desea aumentar la seguridad, aún se debe comprometer el rendimiento, y es difícil proporcionar compromisos de seguridad deterministas.

Ethereum

La estrategia de escalado de Ethereum se basa en apostar por la escalabilidad de la capa de rollup, en lugar de abordar el problema directamente en la capa base. Este enfoque, en esencia, no resuelve el problema, sino que lo traslada a la capa superior del stack.

Optimistic Rollup

Actualmente, la mayoría de los rollups optimistas son centralizados, lo que plantea problemas de insuficiencia de seguridad, aislamiento entre ellos y alta latencia (se debe 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 conocimiento cero 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 causar congestión en la red y 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 disponibilidad de datos en ZK rollup también agudiza sus desventajas. Para asegurar que cualquiera pueda verificar las transacciones, aún es necesario proporcionar datos completos de las transacciones. Esto a menudo 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 fin de la escalabilidad no debería ser un compromiso.

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

En la búsqueda de la implementación de aplicaciones a mayor escala, la "escalabilidad sin confianza" defendida por Polkadot puede ser la verdadera solución que respalde el desarrollo a largo plazo de Web3.