Equilibrio entre escalabilidad, seguridad y Descentralización: las decisiones tecnológicas de Polkadot

En la búsqueda de una mayor eficiencia en blockchain hoy en día, una pregunta clave ha comenzado a surgir: ¿es necesario sacrificar la seguridad y la resiliencia del sistema al mismo tiempo que se mejora el rendimiento de escalado?

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

¿Ha hecho Polkadot, como un importante impulsor de la escalabilidad de Web3, ciertos sacrificios en busca de alta capacidad y baja latencia? ¿Ha hecho su modelo de rollup concesiones en términos de Descentralización, seguridad o interoperabilidad de la red?

Este artículo abordará estas cuestiones, analizando en profundidad los compromisos y decisiones de diseño de escalabilidad de Polkadot, y comparará sus soluciones con las de otras cadenas de bloques principales, explorando sus diferentes elecciones de trayectoria entre 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 una cadena de relevo centralizada, ¿podría esto introducir riesgos de centralización en ciertos 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 operación de Rollup depende de los ordenadores de la cadena de retransmisión conectada, cuya comunicación utiliza un mecanismo llamado protocolo collator. Este protocolo es completamente sin permiso y sin confianza, cualquier persona con conexión a la red puede utilizarlo, conectar un pequeño número de nodos de la cadena de retransmisión y enviar solicitudes de cambio de estado de rollup. Estas solicitudes serán verificadas por algún core de la cadena de retransmisión, solo necesitan cumplir con un requisito: deben ser cambios de estado válidos, de lo contrario, el estado de ese rollup no será avanzado.

Compromiso de expansión 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 de rollup no se lleva a cabo en un core fijo, 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 cualquiera de los core asignados 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, por lo tanto, reduciendo 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 relevo, sin afectar las características clave del sistema.

¿Es confiable el Sequencer?

Una solución sencilla es configurar el protocolo como "con licencia": por ejemplo, adoptar un mecanismo de lista blanca, o confiar por defecto en que los ordenadores no actuarán de forma 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. Cualquier persona debería poder utilizar el protocolo collator para enviar solicitudes de cambio de estado de rollup.

Polkadot: Solución sin compromisos

La solución elegida finalmente 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 claramente en la salida dónde debe ejecutarse la validación en el núcleo de Polkadot.

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

Antes de que se escriba cualquier rollup bloque en la capa de disponibilidad de datos de Polkadot, un grupo compuesto por aproximadamente 5 validadores validará primero su legalidad. Ellos reciben los recibos candidatos y las pruebas de validez presentadas por el ordenante, que contienen el bloque rollup y las correspondientes pruebas de almacenamiento. 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 necesitar confianza y no requerir 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 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 relevo, y solo se necesita un ordenante honesto para mantener la viabilidad.

Con el protocolo ELVES, Polkadot extiende su seguridad de manera integral a todos los rollups, verificando 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.

Generalidad

La escalabilidad 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 escalabilidad elástica, la cantidad total de cálculos que se pueden ejecutar 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 compromiso 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 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 use una cantidad fija de core, o ajuste manualmente fuera de la cadena;

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

• Estrategia de automatización: configurar recursos anticipadamente mediante datos históricos y la interfaz XCM para llamar al servicio coretime.

Aunque la automatización 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 la capacidad de procesamiento 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, sin relación con el número de núcleos asignados.

En el futuro, Polkadot también soportará la transmisión de mensajes 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 a medida que se amplíe la elasticidad, aumentando 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 tiene un costo en términos de Descentralización y seguridad. Pero desde el punto de vista del coeficiente de Nakamoto, incluso si algunos competidores de Polkadot tienen un nivel de Descentralización más bajo, su rendimiento no es tan satisfactorio.

Solana

Solana no utiliza la arquitectura de sharding de Polkadot o Ethereum, sino que implementa la escalabilidad a través de una arquitectura de alta capacidad de procesamiento en una sola capa, apoyándose en la prueba de historia (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 previamente público y verificable:

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

• Cuanto más se apueste, más se distribuye. Por ejemplo, un validador que apueste el 1% obtendrá aproximadamente el 1% de la oportunidad de crear bloques;

• 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 tienen requisitos de hardware extremadamente altos, lo que lleva a la centralización de los nodos de validación. Cuanto más se apueste, mayor será la oportunidad de los nodos de generar 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, en su búsqueda de TPS, sacrificó la Descentralización y la capacidad de resistencia a ataques, su coeficiente de Nakamoto es de solo 20, muy por debajo del 172 de Polkadot.

TON

TON 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 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 se expone 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", un atacante puede esperar a que un fragmento esté completamente bajo su control o interrumpir a los validadores honestos mediante un ataque DDoS, lo que permite manipular el estado.

En comparación, los validadores de Polkadot son asignados aleatoriamente y su identidad se revela con retraso, 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 resultará en la pérdida de la garantía del atacante.

Avalanche

Avalanche utiliza una arquitectura de red principal + subredes para la 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).

Cada subred puede alcanzar un TPS teórico de ~5,000, similar a la idea de Polkadot: reducir la carga de un solo shard para lograr la 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 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 garantías de seguridad predeterminadas, 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 escalabilidad de Ethereum se basa en apostar por la escalabilidad de la capa rollup, en lugar de resolver el problema directamente en la capa base. Esta forma de proceder no resuelve el problema en esencia, sino que lo traslada a la capa superior de la pila.

Optimistic Rollup

Actualmente, la mayoría de los Optimistic rollups son centralizados (algunos incluso tienen un solo secuenciador), lo que presenta problemas de seguridad insuficiente, 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 por transacción. La demanda de cálculo para generar pruebas de conocimiento cero es extremadamente alta, y el mecanismo de "el ganador se lo lleva todo" tiende a llevar a la Descentralizació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 en el 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 disponibilidad de datos de ZK rollup también agravará sus desventajas. Para asegurar que cualquier persona pueda verificar las transacciones, aún se necesita proporcionar datos de transacción completos. 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.

En comparación con 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 en seguridad, Descentralización y alto rendimiento a través de una escalabilidad flexible, diseño de protocolos sin permisos, una capa de seguridad unificada y un mecanismo de gestión de recursos flexible.

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