La compensación de la escalabilidad de la cadena de bloques: el camino del equilibrio entre Polkadot y Web3

En un mundo donde la Cadena de bloques busca constantemente mayor eficiencia, surge una cuestión clave: ¿es necesario sacrificar la seguridad y la resiliencia del sistema al mismo tiempo que se mejora el rendimiento? Este no solo es un desafío a nivel técnico, sino también una decisión profunda en el diseño arquitectónico. Para el ecosistema Web3, un sistema más rápido que se basa en sacrificar la confianza y la seguridad a menudo no puede sostener una innovación realmente sostenible.

Polkadot, como un importante impulsor de la escalabilidad en 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 sacrificios de Polkadot en el diseño de la escalabilidad y lo comparará con las soluciones de otras cadenas de bloques principales, explorando sus diferentes enfoques en cuanto a rendimiento, seguridad y descentralización.

Desafíos en el diseño de 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 la Cadena de bloques Relay Chain(, ¿es posible que esto introduzca riesgos de centralización en algunos aspectos? ¿Es posible que se forme un punto único de fallo o control, lo que afectaría a sus características de descentralización?

La ejecución de Rollup depende del secuenciador ) que conecta la cadena de bloques intermedia (, cuya comunicación utiliza un mecanismo llamado protocolo de collation. Este protocolo no requiere permisos ni confianza, cualquier persona con conexión a la red puede usarlo, conectar un pequeño número de nodos de la cadena de bloques intermedia y enviar solicitudes de transformación de estado de rollup. Estas solicitudes serán verificadas por algún core de la cadena de bloques intermedia, solo se necesita cumplir con un requisito: debe ser una transformación de estado válida, de lo contrario, el estado de ese rollup no se avanzará.

) Compensación de expansión vertical

Rollup puede lograr la escalabilidad vertical aprovechando la arquitectura multicore de Polkadot. Esta nueva capacidad es introducida por la función de "Escalado Elástico" ###Elastic Scaling(. Durante el proceso de diseño, descubrimos que, dado que la validación de bloques de rollup no se realiza de manera fija en un solo core, esto podría afectar su elasticidad.

Dado que el protocolo para enviar bloques a la cadena de bloques intermedia es sin permisos y sin confianza, cualquier persona puede enviar bloques a cualquiera de los núcleos asignados al rollup para su validación. Los atacantes pueden aprovechar esto para enviar repetidamente bloques legítimos que ya han sido validados a diferentes núcleos, consumiendo maliciosamente recursos y reduciendo así el rendimiento y la eficiencia general del rollup.

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

) ¿Es confiable Sequencer?

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

Sin embargo, en el diseño de Polkadot, no podemos hacer ninguna suposición de confianza sobre el sequencer, 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 cambio de estado del rollup.

Polkadot: una solución sin compromisos

La solución finalmente elegida por Polkadot es: dejar que la función de transición de estado del rollup resuelva completamente el problema ###Runtime(. Runtime es la única fuente de confianza para toda la información de consenso, por lo que debe declararse explícitamente en la salida en qué núcleo de Polkadot debe llevarse a cabo la verificación.

Este diseño logra una doble garantía de elasticidad y seguridad. Polkadot volverá a ejecutar la transición 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 de ELVES.

Antes de que se escriba cualquier bloque de rollup en la capa de disponibilidad de datos de Polkadot )DA(, un grupo de aproximadamente 5 validadores verificará su legalidad. Reciben el recibo candidato )candidate receipt( y la prueba de validez )PoV(, que contiene el bloque de rollup y la prueba de almacenamiento correspondiente. Esta información será procesada por la función de verificación de la cadena paralela, siendo reejecutada por los validadores en la cadena de retransmisión.

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

Este mecanismo garantiza que el sistema mantenga siempre propiedades de no confianza y no permiso, evitando que actores maliciosos como los ordenadores manipulen la posición de verificación, asegurando que incluso si el rollup utiliza múltiples núcleos, se mantenga la 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.

Gracias al protocolo ELVES, Polkadot extiende su seguridad de manera integral 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 escalabilidad elástica no limitará la programabilidad de los rollups. El modelo de rollup de Polkadot admite la ejecución de cálculos Turing completos en un entorno de WebAssembly, siempre que una ejecución individual se complete en menos de 2 segundos. Con la escalabilidad elástica, la cantidad total de cálculos que se pueden realizar en cada ciclo de 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 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 parte de los requisitos 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 la cadena o fuera de la cadena. Por ejemplo:

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

• Estrategia ligera: monitorear cargas de transacción específicas en el mempool del nodo;

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

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

Interoperabilidad

Polkadot admite la interoperabilidad entre diferentes rollups, y la escalabilidad elástica no afecta el rendimiento del envío de mensajes.

La comunicación de mensajes entre rollups es implementada por la capa de transporte subyacente, y el espacio de bloque de comunicación de cada rollup es fijo, sin relación con el número de núcleos asignados.

En el futuro, Polkadot también soportará la mensajería fuera de la cadena ###off-chain messaging(, con la cadena de relevos actuando 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 escalabilidad elástica, aumentando aún más la capacidad de escalado vertical del sistema.

¿Qué concesiones han hecho otros protocolos?

Como todos saben, la mejora del rendimiento a menudo se logra 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 menor grado de descentralización, su rendimiento no es satisfactorio.

) Solana

Solana no utiliza la arquitectura de fragmentación de Polkadot o Ethereum, sino que implementa escalabilidad con una arquitectura de alta capacidad de procesamiento en una sola capa, dependiendo de 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:

• Cada epoch ) dura aproximadamente dos días o 432,000 slots ( al inicio, se asignan slots según la cantidad de staking;

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

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

PoH y el procesamiento paralelo requieren un hardware extremadamente alto, lo que lleva a la centralización de los nodos de validación. Cuanto más se stakea un nodo, mayores son las oportunidades de que produzca 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 sacrificó la descentralización y la capacidad de resistencia a ataques en su búsqueda de TPS, su coeficiente de Nakamoto es de solo 20, muy por debajo del 172 de Polkadot.

) TON

TON afirma que su TPS puede alcanzar los 104,715, pero este número se logró en una red de prueba privada, con 256 nodos, bajo condiciones ideales de red y hardware. En cambio, Polkadot ha alcanzado 128K TPS en su red pública descentralizada.

El mecanismo de consenso de TON presenta vulnerabilidades de seguridad: la identidad de los nodos de validación de fragmentos puede ser expuesta por adelantado. 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 de apostadores", los atacantes pueden esperar a que un fragmento esté completamente bajo su control, o interrumpir a los validadores honestos mediante ataques DDoS, lo que les permite alterar el estado.

En comparación, los validadores de Polkadot se distribuyen aleatoriamente y se revelan con retraso, lo que impide que los atacantes conozcan por adelantado la identidad de los validadores. Para que el ataque tenga éxito, deben apostar todo el control; siempre que haya un validador honesto que inicie una disputa, el ataque fallará y causará pérdidas al atacante.

Avalanche

Avalanche utiliza una arquitectura de red principal + subred para la escalabilidad, la red principal consiste en transferencias de X-Chain###, ~4,500 TPS(, contratos inteligentes de C-Chain), ~100--200 TPS(, y la P-Chain) que gestiona los validadores y las subredes(.

Cada subred puede alcanzar un TPS teórico de ~5,000, similar a la idea de Polkadot: reducir la carga de un solo Bloquear para lograr escalabilidad. Sin embargo, Avalanche permite a los validadores elegir libremente participar en subredes, y estas pueden establecer requisitos adicionales geográficos, KYC, etc., sacrificando descentralización y seguridad.

En Polkadot, todos los rollups comparten una garantía de seguridad unificada; mientras que las subredes de Avalanche no tienen garantías de seguridad por defecto, algunas 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 se basa en apostar por la escalabilidad de la capa de rollup, en lugar de resolver el problema directamente en la capa base. Esta forma de abordar el problema no lo resuelve esencialmente, sino que lo transfiere a la capa superior del stack.

Optimistic Rollup

Actualmente, la mayoría de los rollups optimistas son centralizados, ### algunos incluso tienen solo un secuenciador (, lo que plantea problemas de seguridad insuficiente, aislamiento mutuo, alta latencia ) y la necesidad de esperar el período de prueba de fraude, que suele ser de varios días (.

)# ZK Rollup

La implementación de ZK rollup está limitada por la cantidad de datos que se pueden procesar por 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 del ZK rollup Turing completo es aproximadamente 2x10^6 veces el protocolo de seguridad económica criptográfica central de Polkadot.

Además, el problema de la disponibilidad de datos de ZK rollup también agravará sus desventajas. Para garantizar que cualquier persona pueda verificar las transacciones, aún se requiere proporcionar datos completos de las transacciones. Esto suele depender 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 un camino que intercambia centralización por rendimiento o confianza preestablecida por eficiencia, sino que ha logrado un equilibrio multidimensional entre seguridad, descentralización y alto rendimiento a través de un diseño de protocolo flexible, sin permisos, una capa de seguridad unificada y mecanismos de gestión de recursos flexibles.

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