- Tema
13k Popularidad
44k Popularidad
845 Popularidad
14k Popularidad
30k Popularidad
804 Popularidad
91k Popularidad
25k Popularidad
26k Popularidad
7k Popularidad
- Anclado
13k Popularidad
44k Popularidad
845 Popularidad
14k Popularidad
30k Popularidad
804 Popularidad
91k Popularidad
25k Popularidad
26k Popularidad
7k Popularidad
¿Cómo logra Polkadot una alta escalabilidad sin sacrificar la seguridad y la Descentralización?
La compensación y los desafíos de la escalabilidad de la cadena de bloques: La solución de Polkadot
En la actualidad, con la continua búsqueda de una mayor eficiencia en la tecnología de cadena de bloques, un problema clave ha comenzado a surgir: ¿cómo mejorar el rendimiento sin sacrificar la seguridad y la resiliencia del sistema? Este no solo es un desafío a nivel técnico, sino también 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 tiene dificultades para sostener una innovación verdaderamente sostenible.
Polkadot, como un importante impulsor de la escalabilidad en Web3, ¿ha hecho concesiones en términos de 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 se comparará con las soluciones de otras cadenas de bloques principales, explorando sus diferentes elecciones de rutas entre rendimiento, seguridad y descentralización.
Desafíos en el diseño de expansión de Polkadot
Equilibrio entre elasticidad y descentralización
La arquitectura de Polkadot depende de una red de validadores y de una Cadena de bloques de retransmisión (Relay Chain), lo que podría introducir riesgos de centralización en ciertos aspectos. La operación de Rollup depende de un secuenciador (sequencer) que conecta la Cadena de bloques de retransmisión, cuya comunicación utiliza el mecanismo del protocolo collator. Este protocolo no requiere permisos, ni confianza, cualquier persona con conexión a la red puede usarlo, conectando una pequeña cantidad de nodos de la Cadena de bloques de retransmisión y enviando solicitudes de cambio de estado de rollup.
Compromiso de expansión vertical
Rollup puede lograr la escalabilidad vertical aprovechando la arquitectura de múltiples núcleos de Polkadot. Esta nueva capacidad es introducida por la función de "Escalabilidad Elástica". Sin embargo, dado que la validación de bloques de rollup no se ejecuta de manera fija en un núcleo específico, esto puede afectar su elasticidad. Los atacantes pueden aprovechar esto, presentando repetidamente bloques legítimos que ya han sido validados en diferentes núcleos, consumiendo recursos de manera maliciosa, lo que reduce el rendimiento y la eficiencia general del rollup.
Problemas de confianza del Secuenciador
Una solución simple es configurar 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. Sin embargo, en la filosofía de diseño de Polkadot, no se pueden hacer suposiciones de confianza sobre el secuenciador, ya que es necesario mantener las características de "sin confianza" y "sin licencia" del sistema.
La solución de Polkadot
La solución finalmente elegida por Polkadot es: delegar completamente el problema a la función de conversión de estado de rollup (Runtime). Runtime es la única fuente confiable de toda la información de consenso y debe declarar 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 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 cualquier bloque de rollup se escriba en la capa de disponibilidad de datos (DA) de Polkadot, un grupo de aproximadamente 5 validadores verificará primero su legalidad. Reciben los recibos candidatos y las pruebas de validez presentadas por el ordenante, que contienen bloques 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á re-ejecutada 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 debe verificarse 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 asegura que el sistema mantenga siempre las propiedades de no confiar y no requerir 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, pueda mantener la resiliencia.
seguridad
En su 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 organizador honesto para mantener la supervivencia. Con el 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 limitación o suposición sobre la cantidad de núcleos utilizados.
Usabilidad
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 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 de compensación aceptable en el diseño de sistemas. El 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 la cadena o fuera de la cadena. Por ejemplo:
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 flexible no afecta la capacidad de transmisión de mensajes. La comunicación de mensajes entre rollups es realizada por la capa de transporte subyacente, y el espacio de bloques de comunicación de cada rollup es fijo, independientemente de la cantidad de núcleos asignados.
En el futuro, Polkadot también admitirá la mensajería fuera de la cadena, utilizando la cadena de retransmisión 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, lo que fortalecerá aún más la capacidad de escalabilidad vertical del sistema.
Compromisos de otros protocolos
Como todo el mundo sabe, 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 tan satisfactorio.
Solana
Solana utiliza una arquitectura de alta capacidad de procesamiento de una sola capa para lograr escalabilidad, 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. Su diseño clave es un mecanismo de programación de líderes que es públicamente accesible y verificable.
Sin embargo, 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 juego, mayor es la oportunidad de que generen bloques, mientras que los nodos pequeños prácticamente no tienen slot, 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, ha sacrificado la descentralización y la capacidad de resistencia a ataques, 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 bajo 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 puede exponer 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 de apostadores", los atacantes pueden 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 les permite alterar el estado.
En comparación, los validadores de Polkadot son asignados aleatoriamente y su identidad se revela con retraso, por lo que los atacantes no pueden conocer de antemano la identidad de los validadores. Para que un ataque tenga éxito, deben controlar todo, y si hay un validador honesto que inicia una disputa, el ataque fracasará y resultará en la pérdida de la participación del atacante.
Avalanche
Avalanche utiliza una arquitectura de red principal + subredes para escalar. 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 teóricamente ~5,000 TPS, similar a la idea de Polkadot: reducir la carga de un solo bloque 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 o KYC, 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 pueden ser completamente centralizadas. Si se desea aumentar la seguridad, aún se debe comprometer en 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 resolver 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.
La mayoría de los Optimistic Rollup son actualmente centralizados, lo que presenta problemas de insuficiencia de seguridad, aislamiento entre sí y alta latencia (se requiere esperar el período de prueba de fraude, que suele ser de varios días).
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" tiende a llevar a la centralización del sistema. Para garantizar 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 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 de ZK rollup también agudiza sus desventajas. Para asegurar que cualquiera pueda verificar las transacciones, aún se necesita proporcionar datos completos de transacción. 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 descentralización por rendimiento ni la 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 un mecanismo de gestión de recursos flexible.
En la búsqueda de la implementación de aplicaciones a mayor escala hoy en día, la "escalabilidad de cero confianza" que defiende Polkadot podría ser la verdadera solución que sustente el desarrollo a largo plazo de Web3.