- Tema
88k Popularidad
41k Popularidad
14k Popularidad
4k Popularidad
5k Popularidad
29k Popularidad
16k Popularidad
22k Popularidad
13k Popularidad
3k Popularidad
- Anclado
88k Popularidad
41k Popularidad
14k Popularidad
4k Popularidad
5k Popularidad
29k Popularidad
16k Popularidad
22k Popularidad
13k Popularidad
3k Popularidad
La elección de Polkadot sobre la escalabilidad de Web3: seguridad y Descentralización sin compromisos
Decisiones de escalabilidad: La balanza entre Polkadot y Web3
En el contexto actual de la blockchain, donde se busca una mayor eficiencia, surge una pregunta clave: ¿cómo escalar 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 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 resulta difícil de sostener para una innovación verdaderamente sostenible.
Como un importante impulsor de la escalabilidad de Web3, ¿ha hecho Polkadot ciertos sacrificios en su objetivo de alta capacidad de procesamiento y baja latencia? ¿Su modelo de rollup ha hecho concesiones en descentralización, seguridad o interoperabilidad de la red?
Este artículo abordará estas cuestiones, analizando en profundidad los compromisos y las opciones de diseño de escalabilidad de Polkadot, y comparándolas con las soluciones de otras cadenas de bloques principales, explorando sus diferentes elecciones en cuanto a rendimiento, seguridad y descentralización.
Desafíos en el diseño de la expansión de Polkadot
El equilibrio entre la flexibilidad y la descentralización
¿La arquitectura de Polkadot depende de una red de validadores y de una cadena de retransmisión centralizada, podría esto 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 operación de Rollup depende de un ordenante conectado a la cadena de retransmisión, cuya comunicación utiliza el mecanismo de protocolo collator. Este protocolo es completamente sin permiso y sin confianza, cualquier persona con conexión a la red puede usarlo, conectando una pequeña cantidad 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 que se cumpla un requisito: debe ser un cambio de estado válido, de lo contrario, el estado de ese rollup no avanzará.
Compromiso de escalado vertical
Rollup puede lograr la escalabilidad vertical aprovechando la arquitectura multicore de Polkadot. Esta nueva capacidad se introduce con 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 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 no requiere permisos ni confianza, cualquier persona puede enviar bloques para ser validados en cualquiera de los núcleos asignados al rollup. Los atacantes pueden aprovechar esto para volver a enviar 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 flexibilidad de los rollups y la utilización eficiente de los recursos de la cadena de retransmisión sin afectar las características clave del sistema.
Problemas de confianza del secuenciador
Una solución simple es configurar el protocolo como "con licencia": por ejemplo, utilizando un mecanismo de lista blanca, o confiando por defecto en que los ordenadores no se comporten de forma 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 permiso" del sistema. Cualquiera debería poder utilizar el protocolo collator para enviar solicitudes de cambio 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 el problema por completo. 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 la transformación del 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 encriptado ELVES.
Antes de escribir en la capa de disponibilidad de datos de Polkadot cualquier bloque de rollup, un grupo de aproximadamente 5 validadores primero verificará su legalidad. Reciben los recibos candidatos y las pruebas de validez presentadas por el ordenante, que contienen el bloque de rollup y la correspondiente prueba de almacenamiento. Esta información será procesada por la función de validación de la cadena paralela, que será reevaluada 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 asegura que el sistema mantenga siempre las propiedades de sin confianza y sin permiso, evitando que actores maliciosos como los ordenadores manipulen las posiciones 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 limitación o suposición sobre el número 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 WebAssembly, siempre que una 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 un 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 de sistemas.
Los Rollups pueden 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 ciertos requisitos de 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:
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 a la capacidad de transmisión 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 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 expansión elástica, fortaleciendo aún más la capacidad de escalado vertical del sistema.
Compensaciones de 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 logra escalabilidad mediante una arquitectura de alta capacidad de rendimiento 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 de hasta 65,000.
Un diseño clave es su mecanismo de programación de líderes que es públicamente accesible y verificable:
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 crear 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 se paralice tras un ataque.
Solana sacrifica la descentralización y la resistencia a ataques en busca de TPS, su coeficiente de Nakamoto es solo de 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. En cambio, Polkadot ha alcanzado 128K TPS en su red pública descentralizada.
El mecanismo de consenso de TON presenta riesgos de seguridad: la identidad de los nodos de verificació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 aprovechado maliciosamente. Debido a la falta de un mecanismo de "bancarrota 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 son asignados de manera aleatoria y se revelan con retraso, los atacantes no pueden conocer la identidad de los validadores por adelantado, el ataque debe apostar todo el control para tener éxito, tan pronto como un validador honesto inicie una disputa, el ataque fallará 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 transferencias en X-Chain(, ~4,500 TPS), contratos inteligentes en C-Chain(, ~100-200 TPS), y la gestión de validadores y subredes en P-Chain(.
La TPS teórica de cada subred puede alcanzar ~5,000, similar a la idea de Polkadot: reducir la carga de un solo shard para lograr escalabilidad. Sin embargo, Avalanche permite a los validadores elegir libremente participar en subredes, y las subredes pueden establecer requisitos adicionales como geográficos y 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 predeterminada, 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 resolver problemas directamente en la capa base. Esta forma de actuar, 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 Optimistic rollup son centralizados ###, algunos incluso tienen solo un secuenciador (, lo que plantea problemas como falta de seguridad, aislamiento entre ellos, 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 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 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 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 la disponibilidad de datos de ZK rollup también agravará sus desventajas. Para asegurar que cualquiera pueda verificar las transacciones, aún se necesita proporcionar datos de transacciones 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.
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 predefinida 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 mayor aplicación a gran escala, la "escalabilidad de cero confianza" que sostiene Polkadot podría ser la verdadera solución que respalde el desarrollo a largo plazo de Web3.