La compensación de la escalabilidad de la cadena de bloques: Exploración de Polkadot y el ecosistema Web3
En la actualidad, en la que la Cadena de bloques busca constantemente 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 arquitectónico. Especialmente 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 de Web3, ¿ha hecho Polkadot algunos sacrificios bajo el objetivo de alto rendimiento y baja latencia? ¿Su modelo de rollup ha hecho concesiones en términos de descentralización, seguridad o interoperabilidad de la red?
Este artículo se centrará en estas cuestiones, analizando en profundidad los compromisos y concesiones de Polkadot en el diseño de escalabilidad, y comparando sus soluciones con las de otras cadenas de bloques principales, explorando sus diferentes elecciones de camino 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 la cadena de retransmisión (Relay Chain), ¿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?
El funcionamiento de Rollup depende de un secuenciador (sequencer) que conecta la cadena de bloques (Bloquear), cuya comunicación utiliza un mecanismo llamado 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 cadena de bloques (Bloquear) y enviando solicitudes de cambio de estado de rollup. Estas solicitudes se validarán a través de un core de la cadena de bloques (Bloquear), siempre y cuando se cumpla una premisa: debe ser una transición de estado válida, de lo contrario, el estado de ese rollup no se avanzará.
Compromisos 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 verificación de bloques de rollup no se ejecuta de manera fija en un core determinado, esto podría afectar su elasticidad.
Dado que el protocolo para enviar bloques a la cadena de retransmisión no requiere permisos ni confianza, cualquier persona puede enviar bloques a cualquiera de los núcleos 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 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 relevos, sin afectar las características clave del sistema.
¿Es confiable el Sequencer?
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, 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 sequencer, ya que debemos mantener las características de "sin confianza" y "sin permiso" del sistema. Cualquiera debería poder utilizar el protocolo de collator para enviar solicitudes de cambio de estado del rollup.
Polkadot: Solución sin compromisos
La solución finalmente 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 transición de estado del rollup en el proceso de disponibilidad y asegurará la corrección de la asignación del núcleo 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. Ellos reciben los recibos candidatos (candidate receipt) y las pruebas de validez (PoV) presentados 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 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 validar 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 necesidad de confianza y sin necesidad de 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 elasticidad.
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.
Gracias al protocolo ELVES, Polkadot extiende su seguridad de manera completa a todos los rollups, verificando todos los cálculos en el core, 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 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 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 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 transacciones específicas en el mempool de nodos;
Estrategias automatizadas: configurar recursos anticipadamente mediante el 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 afectará el volumen 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, independientemente del 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 retransmisión como plano de control en lugar de plano 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é 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 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 implementa escalabilidad a través de una arquitectura de alto rendimiento de una sola capa, confiando en la prueba histórica (PoH), el procesamiento paralelo de CPU y un mecanismo de consenso basado en líderes, con una TPS teórica que puede alcanzar 65,000.
Un diseño clave es su mecanismo de programación de líderes que es público y verificable de antemano:
Al inicio de cada epoch (aproximadamente dos días o 432,000 slots), 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% obtendrá aproximadamente el 1% de las oportunidades de bloque.
Todos los validadores de bloques 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 requieren hardware extremadamente alto, lo que conduce a la centralización de los nodos de validación. Cuantos más nodos estén en staking, mayores serán las oportunidades 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 se paralice 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 solo 20, muy por debajo de los 172 de Polkadot.
TON
TON afirma que el TPS puede alcanzar 104,715, pero este número se logró en una red de pruebas privada, con 256 nodos, 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 expone 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 "bancarrota 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 modificar el estado.
En comparación, los validadores de Polkadot son asignados de manera aleatoria y su identidad se revela con retraso, lo que impide que los atacantes conozcan 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 causará pérdidas al atacante en su participación.
Avalanche
Avalanche utiliza una arquitectura de red principal + subredes para escalar, 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 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, 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, algunas incluso pueden ser completamente centralizadas. Si se desea aumentar la seguridad, aún se debe comprometer el rendimiento, y es difícil proporcionar una promesa de seguridad determinista.
Ethereum
La estrategia de escalado de Ethereum apuesta por la escalabilidad de la capa 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.
Optimistic Rollup
Actualmente, la mayoría de los rollups optimistas son centralizados (algunos incluso tienen solo un secuenciador), lo que genera problemas de insuficiencia de seguridad, aislamiento entre sí y alta latencia (se requiere esperar el período de prueba de fraude, que generalmente es 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" 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 un aumento en el gas durante períodos de alta demanda, afectando la experiencia del usuario.
En comparación, el costo del ZK rollup Turing completo es aproximadamente 2x10^6 veces el del protocolo de seguridad económica central de Polkadot.
Además, el problema de disponibilidad de datos de ZK rollup también agravará sus desventajas. Para garantizar que cualquiera pueda verificar las transacciones, aún se necesita proporcionar datos completos de la 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 el camino de intercambiar centralización por rendimiento o confianza preestablecida por eficiencia, sino que ha logrado un equilibrio multidimensional de seguridad, descentralización y alto rendimiento a través de una expansión flexible, un diseño de protocolo 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, el "escala de confianza cero" que sostiene Polkadot podría ser realmente la solución que respalde el desarrollo a largo plazo de Web3.
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
14 me gusta
Recompensa
14
5
Compartir
Comentar
0/400
SignatureCollector
· 07-30 01:18
¡Vamos a la cadena, rápido subir, rápido subir!
Ver originalesResponder0
ForumMiningMaster
· 07-30 01:15
Con estos pocos cadenas, puedes ganar cien mil al mes.
Ver originalesResponder0
LostBetweenChains
· 07-30 01:12
Solo hay que aumentar la posición de BTC.
Ver originalesResponder0
BearMarketSunriser
· 07-30 01:12
¿Con este poco de tps también te atreves a presumir?
Ver originalesResponder0
ApeWithNoChain
· 07-30 01:04
¡Impactante! Resulta que el dot que compré es así.
Escalabilidad flexible de Polkadot: el camino de alto rendimiento de Web3 sin compromisos
La compensación de la escalabilidad de la cadena de bloques: Exploración de Polkadot y el ecosistema Web3
En la actualidad, en la que la Cadena de bloques busca constantemente 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 arquitectónico. Especialmente 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 de Web3, ¿ha hecho Polkadot algunos sacrificios bajo el objetivo de alto rendimiento y baja latencia? ¿Su modelo de rollup ha hecho concesiones en términos de descentralización, seguridad o interoperabilidad de la red?
Este artículo se centrará en estas cuestiones, analizando en profundidad los compromisos y concesiones de Polkadot en el diseño de escalabilidad, y comparando sus soluciones con las de otras cadenas de bloques principales, explorando sus diferentes elecciones de camino 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 la cadena de retransmisión (Relay Chain), ¿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?
El funcionamiento de Rollup depende de un secuenciador (sequencer) que conecta la cadena de bloques (Bloquear), cuya comunicación utiliza un mecanismo llamado 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 cadena de bloques (Bloquear) y enviando solicitudes de cambio de estado de rollup. Estas solicitudes se validarán a través de un core de la cadena de bloques (Bloquear), siempre y cuando se cumpla una premisa: debe ser una transición de estado válida, de lo contrario, el estado de ese rollup no se avanzará.
Compromisos 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 verificación de bloques de rollup no se ejecuta de manera fija en un core determinado, esto podría afectar su elasticidad.
Dado que el protocolo para enviar bloques a la cadena de retransmisión no requiere permisos ni confianza, cualquier persona puede enviar bloques a cualquiera de los núcleos 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 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 relevos, sin afectar las características clave del sistema.
¿Es confiable el Sequencer?
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, 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 sequencer, ya que debemos mantener las características de "sin confianza" y "sin permiso" del sistema. Cualquiera debería poder utilizar el protocolo de collator para enviar solicitudes de cambio de estado del rollup.
Polkadot: Solución sin compromisos
La solución finalmente 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 transición de estado del rollup en el proceso de disponibilidad y asegurará la corrección de la asignación del núcleo 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. Ellos reciben los recibos candidatos (candidate receipt) y las pruebas de validez (PoV) presentados 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 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 validar 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 necesidad de confianza y sin necesidad de 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 elasticidad.
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.
Gracias al protocolo ELVES, Polkadot extiende su seguridad de manera completa a todos los rollups, verificando todos los cálculos en el core, 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 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 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 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 transacciones específicas en el mempool de nodos;
Estrategias automatizadas: configurar recursos anticipadamente mediante el 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 afectará el volumen 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, independientemente del 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 retransmisión como plano de control en lugar de plano 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é 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 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 implementa escalabilidad a través de una arquitectura de alto rendimiento de una sola capa, confiando en la prueba histórica (PoH), el procesamiento paralelo de CPU y un mecanismo de consenso basado en líderes, con una TPS teórica que puede alcanzar 65,000.
Un diseño clave es su mecanismo de programación de líderes que es público y verificable de antemano:
Al inicio de cada epoch (aproximadamente dos días o 432,000 slots), 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% obtendrá aproximadamente el 1% de las oportunidades de bloque.
Todos los validadores de bloques 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 requieren hardware extremadamente alto, lo que conduce a la centralización de los nodos de validación. Cuantos más nodos estén en staking, mayores serán las oportunidades 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 se paralice 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 solo 20, muy por debajo de los 172 de Polkadot.
TON
TON afirma que el TPS puede alcanzar 104,715, pero este número se logró en una red de pruebas privada, con 256 nodos, 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 expone 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 "bancarrota 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 modificar el estado.
En comparación, los validadores de Polkadot son asignados de manera aleatoria y su identidad se revela con retraso, lo que impide que los atacantes conozcan 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 causará pérdidas al atacante en su participación.
Avalanche
Avalanche utiliza una arquitectura de red principal + subredes para escalar, 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 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, 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, algunas incluso pueden ser completamente centralizadas. Si se desea aumentar la seguridad, aún se debe comprometer el rendimiento, y es difícil proporcionar una promesa de seguridad determinista.
Ethereum
La estrategia de escalado de Ethereum apuesta por la escalabilidad de la capa 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.
Optimistic Rollup
Actualmente, la mayoría de los rollups optimistas son centralizados (algunos incluso tienen solo un secuenciador), lo que genera problemas de insuficiencia de seguridad, aislamiento entre sí y alta latencia (se requiere esperar el período de prueba de fraude, que generalmente es 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" 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 un aumento en el gas durante períodos de alta demanda, afectando la experiencia del usuario.
En comparación, el costo del ZK rollup Turing completo es aproximadamente 2x10^6 veces el del protocolo de seguridad económica central de Polkadot.
Además, el problema de disponibilidad de datos de ZK rollup también agravará sus desventajas. Para garantizar que cualquiera pueda verificar las transacciones, aún se necesita proporcionar datos completos de la 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 el camino de intercambiar centralización por rendimiento o confianza preestablecida por eficiencia, sino que ha logrado un equilibrio multidimensional de seguridad, descentralización y alto rendimiento a través de una expansión flexible, un diseño de protocolo 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, el "escala de confianza cero" que sostiene Polkadot podría ser realmente la solución que respalde el desarrollo a largo plazo de Web3.