Compromiso de escalabilidad: desafíos de Polkadot y Web3
En la búsqueda de una mayor eficiencia en la blockchain hoy en día, surge una cuestión clave: ¿cómo lograr una mayor escalabilidad sin sacrificar la seguridad y la resiliencia del sistema? Este no solo es un reto 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 construya sobre la base de sacrificar la confianza y la seguridad, a menudo resulta incapaz de sostener una innovación verdaderamente sostenible.
Como un importante impulsor de la escalabilidad de Web3, ¿ha hecho Polkadot algunos 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 sacrificios de Polkadot en el diseño de la escalabilidad, y comparándolo con las soluciones de otras cadenas de bloques principales, explorando sus 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 flexibilidad y descentralización
¿La arquitectura de Polkadot depende de una red de validadores y una cadena de retransmisión, lo que podría 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?
El funcionamiento de Rollup depende de un ordenante conectado a la cadena de relé, cuya comunicación utiliza el mecanismo de protocolo collator. Este protocolo es completamente sin permisos y sin confianza, cualquier persona con conexión a la red puede usarlo, conectando un pequeño número de nodos de la cadena de relé y enviando solicitudes de cambio de estado de rollup. Estas solicitudes serán verificadas por algún core de la cadena de relé, solo se requiere cumplir con una premisa: debe ser un cambio de estado válido, de lo contrario, el estado del rollup no avanzará.
Compromiso de escalabilidad vertical
El Rollup puede lograr la escalabilidad vertical al aprovechar la arquitectura multicore de Polkadot. Esta nueva capacidad se introduce a través de la funcionalidad de "escalado elástico". 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 núcleo fijo, esto podría afectar su elasticidad.
Dado que el protocolo para enviar bloques a la cadena intermedia es sin permiso y sin confianza, cualquier persona puede enviar bloques a cualquiera de los núcleos asignados al rollup para su verificación. Los atacantes pueden aprovechar esto para enviar repetidamente bloques legítimos que ya han sido verificados a diferentes núcleos, consumiendo recursos de manera maliciosa y disminuyendo así el rendimiento y la eficiencia general del rollup.
El objetivo de Polkadot es mantener la flexibilidad del rollup y la utilización efectiva de los recursos de la cadena de retransmisión sin afectar las características clave del sistema.
¿Es confiable ### Sequencer?
Una solución simple es configurar el protocolo como "con licencia": por ejemplo, adoptando un mecanismo de lista blanca, o confiando por defecto que el ordenante no actuará 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. Cualquiera debería poder usar el protocolo de collation para enviar solicitudes de transición de estado de rollup.
Polkadot: Una solución sin compromisos
La solución final elegida por Polkadot es: delegar completamente la cuestión a la función de transición de estado del rollup (Runtime). El Runtime es la única fuente confiable de toda la información de consenso, por lo que debe declararse 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 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 core a través del protocolo económico de ELVES.
Antes de que se escriba cualquier rollup en la capa de disponibilidad de datos de Polkadot, un grupo de aproximadamente 5 validadores primero verificará su legitimidad. Reciben los recibos candidatos y las pruebas de validez presentados 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á 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 se debe validar el bloque. Los validadores compararán si el índice coincide con el núcleo del cual son responsables; si no coincide, el bloque será descartado.
Este mecanismo asegura que el sistema mantenga siempre propiedades de confianza y permiso cero, 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, se mantenga 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 retransmisión, y solo se necesita un ordenante honesto para mantener la viabilidad.
A través del protocolo ELVES, Polkadot extiende su seguridad de manera completa a todos los rollups, validando 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, el rollup de Polkadot puede lograr una verdadera escalabilidad sin sacrificar la seguridad.
versatilidad
La expansión elástica no limitará la programabilidad de los rollups. 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 realizar 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.
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 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 cadena o fuera de 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 del nodo;
Estrategia de automatización: configurar recursos anticipadamente a través de datos históricos y la interfaz XCM llamando 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 flexible no afecta el rendimiento del envío de mensajes.
La comunicación de mensajes entre rollups es implementada por 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, 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 a medida que se expanda de manera flexible, aumentando 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 tiene un costo en 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 implementa escalabilidad a través de una arquitectura de alto rendimiento de una sola capa, confiando 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 comienzo 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% tendrá aproximadamente un 1% de oportunidad de crear bloques;
Todos los mineros son anunciados con antelación, lo que aumenta el riesgo de ataques DDoS dirigidos y caídas frecuentes de la red.
PoH y el procesamiento en paralelo requieren un hardware extremadamente alto, lo que conduce a la centralización de los nodos de validación. Cuantos más nodos estén en juego, mayores serán las oportunidades de creación de 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 sacrifica la descentralización y la capacidad de resistencia a ataques en su búsqueda de TPS, 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 pruebas 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 riesgos 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", 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 aleatoriamente y revelados con retraso, por lo que los atacantes no pueden conocer la identidad de los validadores de antemano. 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 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. Sin embargo, Avalanche permite a los validadores elegir libremente participar en la subred, y la subred puede 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 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 del stack.
Optimistic Rollup
Actualmente, la mayoría de las Optimistic rollups son centralizadas (algunas incluso tienen un solo secuenciador), lo que plantea problemas de seguridad insuficiente, aislamiento entre ellas y alta latencia (se debe 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 de cálculo para generar pruebas de cero conocimiento 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 Turing completo es aproximadamente 2x10^6 veces el del protocolo de seguridad económica central de Polkadot.
Además, los problemas de disponibilidad de datos en ZK rollup también agravan sus desventajas. Para garantizar que cualquier persona pueda verificar las transacciones, todavía es necesario 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.
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 entre seguridad, descentralización y alto rendimiento a través de una escalabilidad 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 la implementación de aplicaciones a mayor escala hoy en día, la "escalabilidad de cero confianza" que defiende Polkadot puede ser la verdadera 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.
12 me gusta
Recompensa
12
8
Compartir
Comentar
0/400
LiquidityWhisperer
· 07-22 15:35
¿No se puede tener velocidad y seguridad a la vez?
Ver originalesResponder0
DiamondHands
· 07-22 13:17
La velocidad y la seguridad son inherentemente contradictorias, ¿verdad?
Ver originalesResponder0
GasGuru
· 07-21 22:12
Ya hay otra cadena haciendo malabares.
Ver originalesResponder0
TokenVelocity
· 07-21 22:10
¿Es realmente estable Polkadot? ¿O solo es tomar a la gente por tonta?
Ver originalesResponder0
BearMarketSage
· 07-21 21:53
No se pueden tener tanto el pez como la mano del oso.
Ver originalesResponder0
MidnightSeller
· 07-21 21:52
Sacrificar la seguridad por velocidad, casi es como esperar a subir al tejado.
Ver originalesResponder0
PermabullPete
· 07-21 21:48
Entendido, pero ¿dónde están los puntos?
Ver originalesResponder0
MEVSandwichMaker
· 07-21 21:48
El costo del sacrificio siempre debe pagarse, solo queda ver quién explota primero.
¿Cómo Polkadot logra la expansión de cero confianza liderando el futuro de Web3?
Compromiso de escalabilidad: desafíos de Polkadot y Web3
En la búsqueda de una mayor eficiencia en la blockchain hoy en día, surge una cuestión clave: ¿cómo lograr una mayor escalabilidad sin sacrificar la seguridad y la resiliencia del sistema? Este no solo es un reto 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 construya sobre la base de sacrificar la confianza y la seguridad, a menudo resulta incapaz de sostener una innovación verdaderamente sostenible.
Como un importante impulsor de la escalabilidad de Web3, ¿ha hecho Polkadot algunos 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 sacrificios de Polkadot en el diseño de la escalabilidad, y comparándolo con las soluciones de otras cadenas de bloques principales, explorando sus 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 flexibilidad y descentralización
¿La arquitectura de Polkadot depende de una red de validadores y una cadena de retransmisión, lo que podría 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?
El funcionamiento de Rollup depende de un ordenante conectado a la cadena de relé, cuya comunicación utiliza el mecanismo de protocolo collator. Este protocolo es completamente sin permisos y sin confianza, cualquier persona con conexión a la red puede usarlo, conectando un pequeño número de nodos de la cadena de relé y enviando solicitudes de cambio de estado de rollup. Estas solicitudes serán verificadas por algún core de la cadena de relé, solo se requiere cumplir con una premisa: debe ser un cambio de estado válido, de lo contrario, el estado del rollup no avanzará.
Compromiso de escalabilidad vertical
El Rollup puede lograr la escalabilidad vertical al aprovechar la arquitectura multicore de Polkadot. Esta nueva capacidad se introduce a través de la funcionalidad de "escalado elástico". 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 núcleo fijo, esto podría afectar su elasticidad.
Dado que el protocolo para enviar bloques a la cadena intermedia es sin permiso y sin confianza, cualquier persona puede enviar bloques a cualquiera de los núcleos asignados al rollup para su verificación. Los atacantes pueden aprovechar esto para enviar repetidamente bloques legítimos que ya han sido verificados a diferentes núcleos, consumiendo recursos de manera maliciosa y disminuyendo así el rendimiento y la eficiencia general del rollup.
El objetivo de Polkadot es mantener la flexibilidad del rollup y la utilización efectiva de los recursos de la cadena de retransmisión sin afectar las características clave del sistema.
¿Es confiable ### Sequencer?
Una solución simple es configurar el protocolo como "con licencia": por ejemplo, adoptando un mecanismo de lista blanca, o confiando por defecto que el ordenante no actuará 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. Cualquiera debería poder usar el protocolo de collation para enviar solicitudes de transición de estado de rollup.
Polkadot: Una solución sin compromisos
La solución final elegida por Polkadot es: delegar completamente la cuestión a la función de transición de estado del rollup (Runtime). El Runtime es la única fuente confiable de toda la información de consenso, por lo que debe declararse 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 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 core a través del protocolo económico de ELVES.
Antes de que se escriba cualquier rollup en la capa de disponibilidad de datos de Polkadot, un grupo de aproximadamente 5 validadores primero verificará su legitimidad. Reciben los recibos candidatos y las pruebas de validez presentados 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á 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 se debe validar el bloque. Los validadores compararán si el índice coincide con el núcleo del cual son responsables; si no coincide, el bloque será descartado.
Este mecanismo asegura que el sistema mantenga siempre propiedades de confianza y permiso cero, 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, se mantenga 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 retransmisión, y solo se necesita un ordenante honesto para mantener la viabilidad.
A través del protocolo ELVES, Polkadot extiende su seguridad de manera completa a todos los rollups, validando 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, el rollup de Polkadot puede lograr una verdadera escalabilidad sin sacrificar la seguridad.
versatilidad
La expansión elástica no limitará la programabilidad de los rollups. 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 realizar 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.
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 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 cadena o fuera de 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 del nodo;
Estrategia de automatización: configurar recursos anticipadamente a través de datos históricos y la interfaz XCM llamando 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 flexible no afecta el rendimiento del envío de mensajes.
La comunicación de mensajes entre rollups es implementada por 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, 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 a medida que se expanda de manera flexible, aumentando 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 tiene un costo en 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 implementa escalabilidad a través de una arquitectura de alto rendimiento de una sola capa, confiando 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 comienzo 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% tendrá aproximadamente un 1% de oportunidad de crear bloques;
Todos los mineros son anunciados con antelación, lo que aumenta el riesgo de ataques DDoS dirigidos y caídas frecuentes de la red.
PoH y el procesamiento en paralelo requieren un hardware extremadamente alto, lo que conduce a la centralización de los nodos de validación. Cuantos más nodos estén en juego, mayores serán las oportunidades de creación de 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 sacrifica la descentralización y la capacidad de resistencia a ataques en su búsqueda de TPS, 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 pruebas 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 riesgos 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", 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 aleatoriamente y revelados con retraso, por lo que los atacantes no pueden conocer la identidad de los validadores de antemano. 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 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. Sin embargo, Avalanche permite a los validadores elegir libremente participar en la subred, y la subred puede 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 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 del stack.
Optimistic Rollup
Actualmente, la mayoría de las Optimistic rollups son centralizadas (algunas incluso tienen un solo secuenciador), lo que plantea problemas de seguridad insuficiente, aislamiento entre ellas y alta latencia (se debe 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 de cálculo para generar pruebas de cero conocimiento 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 Turing completo es aproximadamente 2x10^6 veces el del protocolo de seguridad económica central de Polkadot.
Además, los problemas de disponibilidad de datos en ZK rollup también agravan sus desventajas. Para garantizar que cualquier persona pueda verificar las transacciones, todavía es necesario 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.
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 entre seguridad, descentralización y alto rendimiento a través de una escalabilidad 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 la implementación de aplicaciones a mayor escala hoy en día, la "escalabilidad de cero confianza" que defiende Polkadot puede ser la verdadera solución que respalde el desarrollo a largo plazo de Web3.