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

En la búsqueda de una mayor eficiencia en la blockchain hoy en día, un problema clave está emergiendo gradualmente: ¿cómo garantizar la seguridad y la resiliencia del sistema al mismo tiempo que se mejora el rendimiento de escalabilidad? Esto no solo es un desafío a nivel técnico, sino también 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 innovación verdaderamente sostenible.

Como un importante impulsor de la escalabilidad en Web3, ¿ha hecho Polkadot algunas concesiones en su búsqueda de un alto rendimiento y baja latencia? ¿Ha comprometido su modelo de rollup en términos de descentralización, seguridad o interoperabilidad de la red? Este artículo profundizará en las elecciones y compensaciones de diseño de escalabilidad de Polkadot, y comparará estas con las soluciones 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 centralizada, lo que podría introducir riesgos de centralización en algunos aspectos? ¿Es posible que se forme un punto único de fallo o control, lo que afectaría sus características de descentralización?

La ejecución de Rollup depende de un ordenante conectado a la cadena de retransmisión, cuya comunicación utiliza un mecanismo denominado protocolo de collation. 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 del rollup. Estas solicitudes serán verificadas por algún núcleo de la cadena de retransmisión, solo deben cumplir con un requisito: deben ser cambios de estado válidos, de lo contrario, el estado del rollup no avanzará.

Compromisos de escalabilidad 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, descubrimos que, dado que la validación de bloques de rollup no se ejecuta de manera fija en un solo core, esto podría afectar su elasticidad.

Dado que el protocolo para enviar bloques a la cadena de intermediación es sin permisos y sin confianza, cualquier persona puede enviar bloques para ser verificados en cualquier núcleo asignado al rollup. 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 elasticidad de los rollups y la utilización efectiva de los recursos de la cadena de relevo sin comprometer las características clave del sistema.

¿Es confiable Sequencer?

Una solución sencilla es establecer el protocolo como "con licencia": por ejemplo, adoptar un mecanismo de lista blanca, o suponer que los ordenadores de confianza no actuarán de manera maliciosa, asegurando 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 de colator para enviar solicitudes de cambio de estado del rollup.

Polkadot: una solución que no hace 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 claramente en la salida sobre cuál 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 la transición de estado del rollup en el proceso de disponibilidad y asegurará la corrección de la asignación de core a través del protocolo económico encriptado ELVES.

Antes de que se escriba cualquier rollup bloque en la capa de disponibilidad de datos de Polkadot (DA), un grupo de aproximadamente 5 validadores validará su legitimidad. Reciben los recibos candidatos y las pruebas de validez presentadas por el ordenante, que contienen el bloque 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 núcleo, que se utiliza para especificar en qué núcleo se debe verificar 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 garantiza que el sistema siempre mantenga las propiedades de confianza y permiso, evitando que actores maliciosos como los ordenadores manipulen las posiciones de verificación, asegurando 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, solo se necesita un validador honesto para mantener la viabilidad.

Con el protocolo ELVES, Polkadot extiende su seguridad de manera completa a todos los rollups, verificando todos los cálculos en el núcleo, sin necesidad de imponer restricciones o suposiciones 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 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 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 parcialmente con los requisitos del 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: utilizar siempre una cantidad fija de core, o ajustar manualmente fuera de la cadena;

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

• Estrategias automatizadas: configurar recursos anticipadamente mediante datos históricos y la interfaz XCM para llamar al servicio coretime.

Aunque los métodos automatizados son más eficientes, los costos de implementación y prueba también aumentan significativamente.

interoperabilidad

Polkadot admite la interoperabilidad entre diferentes rollups, y la escalabilidad flexible no afectará el rendimiento de la mensajería.

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 la cantidad de núcleos asignados.

En el futuro, Polkadot también soportará la mensajería fuera de la cadena, con la cadena de retransmisión 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, 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 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.

Solana

Solana no utiliza la arquitectura de fragmentación de Polkadot o Ethereum, sino que logra la escalabilidad a través de una arquitectura de alta capacidad en una sola capa, dependiendo de la prueba de historia (PoH), el procesamiento paralelo de CPU y un mecanismo de consenso basado en líderes, con un TPS teórico que puede alcanzar 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 distribuirá. Por ejemplo, un validador que apueste el 1% tendrá aproximadamente un 1% de oportunidad de crear bloques;

• Todos los mineros se anuncian con antelación, lo que aumenta el riesgo de ataques DDoS dirigidos a la red 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 se apuesten, mayor será la oportunidad de que generen bloques, mientras que los nodos más 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 resistencia a ataques en su búsqueda de TPS, su coeficiente de Nakamoto es de solo 20, muy por debajo de los 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 y 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 puede revelar con antelación. El libro blanco de TON también señala claramente que, aunque esto puede optimizar el ancho de banda, también puede ser mal utilizado. 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 un ataque DDoS, lo que les permite alterar el estado.

En comparación, los validadores de Polkadot son asignados de manera aleatoria y su identidad se revela con retraso, por lo que los atacantes no pueden conocer con anticipación la identidad de los validadores. Para llevar a cabo un ataque, deben apostar el control total para tener éxito; si un validador honesto inicia una disputa, el ataque fracasará y causará pérdidas a los atacantes por el colateral.

Avalanche

Avalanche utiliza una arquitectura de red principal + subredes para la escalabilidad. La red principal está compuesta por transferencias X-Chain(, ~4,500 TPS), contratos inteligentes en C-Chain(, ~100-200 TPS), y P-Chain( que gestiona validadores y subredes).

Cada subred puede alcanzar un TPS teórico de ~5,000, similar a la idea de Polkadot: reducir la carga de una sola shard para lograr la escalabilidad. Pero Avalanche permite a los validadores elegir libremente participar en subredes, y las subredes pueden establecer requisitos adicionales geográficos, de 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 una garantía 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 de la capa de rollup, en lugar de abordar los problemas directamente en la capa base. Esta forma de proceder, en esencia, no resuelve el problema, sino que lo transfiere a la capa superior de la pila.

Optimistic Rollup

Actualmente, la mayoría de los rollups optimistas son centralizados, lo que conlleva problemas de seguridad insuficiente, aislamiento mutuo y alta latencia, ya que deben 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 de cálculo 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 provocar congestión en la red y un aumento en el gas durante períodos de alta demanda, afectando la experiencia del usuario.

En comparación, el costo de un ZK rollup completamente Turing 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 agravará sus desventajas. Para asegurar 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.

En comparación con otras cadenas de bloques públicas, Polkadot no ha optado por el camino de intercambiar la centralización por rendimiento ni de intercambiar la confianza preestablecida por eficiencia, sino que ha logrado un equilibrio multidimensional de 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 mecanismos de gestión de recursos flexibles.

En la búsqueda de una implementación a mayor escala hoy en día, la "escalabilidad de cero confianza" que Polkadot defiende, quizás sea la verdadera solución que puede sostener el desarrollo a largo plazo de Web3.