Escalabilidad y compensaciones: Cómo Polkadot busca el equilibrio en el ecosistema Web3
En la actualidad, en la búsqueda de una mayor eficiencia en blockchain, surge una cuestión clave: ¿cómo evitar sacrificar la seguridad y la resiliencia del sistema al mismo tiempo que se mejora el rendimiento? Este no es solo un desafío a nivel técnico, sino una elección profunda 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.
Polkadot, como un importante impulsor de la escalabilidad en Web3, ¿ha hecho 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 decisiones de diseño de escalabilidad de Polkadot, y comparándolos 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 la flexibilidad 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 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 en la cadena de relé conectado, cuya comunicación utiliza un mecanismo llamado 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 núcleo de la cadena de relé, siempre que se cumpla una condición: debe ser un cambio de estado válido; de lo contrario, el estado de ese rollup no será avanzado.
Compromiso de escalado vertical
Rollup puede lograr la escalabilidad vertical aprovechando la arquitectura multicore de Polkadot. Esta nueva capacidad se introduce a través de 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 realiza de manera fija en un solo core, esto podría afectar su elasticidad.
Dado que el protocolo para enviar bloques a la cadena de intermediario es sin permisos y sin confianza, cualquier persona puede enviar bloques para ser verificados en cualquiera de los núcleos asignados al rollup. 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, por lo tanto, reduciendo el rendimiento y la eficiencia general del rollup.
El objetivo de Polkadot es mantener la elasticidad de los rollups y la utilización eficiente de los recursos de la cadena de retransmisión, sin comprometer 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 el ordenante no actuará de manera maliciosa, asegurando así la vitalidad 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 utilizar el protocolo collator para enviar solicitudes de cambios de estado de rollup.
Polkadot: 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 elasticidad y seguridad. Polkadot volverá a ejecutar la transformación del 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 criptográfico ELVES.
Antes de que se escriba en la capa de disponibilidad de datos (DA) de Polkadot cualquier bloque de rollup, un grupo compuesto por aproximadamente 5 validadores verificará primero su legalidad. Reciben los recibos candidatos y las pruebas de validez presentadas por el ordenante, que incluyen el bloque 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á 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 el í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 propiedades de no confianza y no 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, 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, solo se necesita un validador honesto para mantener la viabilidad.
Gracias al protocolo ELVES, Polkadot extiende su seguridad de manera integral a todas las 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.
Por lo tanto, los rollups de Polkadot pueden lograr una verdadera escalabilidad sin sacrificar la seguridad.
versatilidad
La escalabilidad 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 escalabilidad 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 compromiso 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 algunos 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 la cadena o fuera de la cadena. Por ejemplo:
Estrategia simple: siempre usar una cantidad fija de core, o ajustar manualmente fuera de la cadena;
Estrategia ligera: monitorear cargas de transacciones específicas en el mempool de nodos;
Estrategia de automatización: configurar recursos anticipadamente a través de datos históricos y la interfaz XCM para invocar el servicio coretime.
Aunque la automatización es más eficiente, los costos de implementación y prueba también aumentan significativamente.
interoperabilidad
Polkadot soporta la interoperabilidad entre diferentes rollups, y la escalabilidad elástica 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 bloque 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, 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, fortaleciendo aún más la capacidad de escalado vertical del sistema.
¿Qué compromisos han hecho otros protocolos?
Como es bien sabido, la mejora del rendimiento a menudo se logra a costa 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 implementa escalabilidad a través de una arquitectura de alta capacidad de procesamiento en 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 que puede alcanzar 65,000.
Un diseño clave es su mecanismo de programación de líderes que es previamente público y verificable:
Al inicio de cada epoch (aproximadamente cada 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 un 1% de oportunidad de crear bloques;
Todos los mineros 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 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 bloquear, 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, en su búsqueda de TPS, ha sacrificado la descentralización y la resistencia a ataques, su coeficiente de Nakamoto es de solo 20, muy por debajo de los 172 de Polkadot.
TON
Un proyecto de blockchain 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 una red pública descentralizada.
El mecanismo de consenso de este proyecto presenta vulnerabilidades de seguridad: la identidad de los nodos de verificación de fragmentos se expone por adelantado. Su libro blanco también señala claramente que, aunque esto puede optimizar el ancho de banda, también puede ser utilizado maliciosamente. Debido a la falta de un mecanismo de "quiebra de apostadores", un atacante puede esperar a que un fragmento esté completamente bajo su control, o interrumpir a los validadores honestos mediante un ataque DDoS, lo que le 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, siempre que haya un validador honesto que inicie 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 + subred 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 escalabilidad. Sin embargo, Avalanche permite a los validadores elegir libremente participar en subredes, y estas 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, 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 escalabilidad de Ethereum se basa en la escalabilidad de la capa de rollup, en lugar de abordar el problema directamente en la capa base. Esta forma de proceder no resuelve el problema en sí, sino que lo transfiere a la capa superior de la pila.
Rollup Optimista
Actualmente, la mayoría de los rollups optimistas son centralizados (algunos incluso tienen un solo secuenciador), lo que plantea problemas de insuficiente seguridad, aislamiento entre ellos y alta latencia (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 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 el volumen de transacciones por lote, lo que puede causar congestión en la red y aumento de gas durante períodos de alta demanda, afectando la experiencia del usuario.
En comparación, el costo de ZK rollup completamente Turing es aproximadamente 2x10^6 veces el 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 garantizar que cualquiera pueda verificar las transacciones, aún es necesario proporcionar datos completos de las transacciones. Esto suele depender 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 la centralización por rendimiento ni de intercambiar confianza preestablecida por eficiencia, sino que ha logrado un equilibrio multidimensional de 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 una implementación a mayor escala hoy en día, la "escalabilidad de cero confianza" que defiende Polkadot podría 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.
13 me gusta
Recompensa
13
8
Compartir
Comentar
0/400
MysteryBoxOpener
· 07-22 22:03
dot realmente supera a otras cadenas de bloques públicas
Ver originalesResponder0
NotFinancialAdviser
· 07-22 21:00
No hables tanto, dot no es gran cosa.
Ver originalesResponder0
LuckyBearDrawer
· 07-22 00:01
Esta ola de DOT va a To the moon.
Ver originalesResponder0
P2ENotWorking
· 07-19 22:40
¿De qué sirve la velocidad? Primero hay que sobrevivir.
Ver originalesResponder0
BrokenDAO
· 07-19 22:39
Otra vez describiendo el equilibrio perfecto... ¿Recuerdas aquella ola de paralización ecológica en 2021?
Ver originalesResponder0
ser_we_are_early
· 07-19 22:39
¡Genial! En este tipo de artículos técnicos, solo me importa una cosa, subir o no subir.
Ver originalesResponder0
DevChive
· 07-19 22:32
dot es el futuro, ¿quién más se opone?
Ver originalesResponder0
MagicBean
· 07-19 22:31
esperando los resultados de los jugadores de polka, no puedo evitar decir que definitivamente pueden To the moon
La forma de ponderar de Polkadot: escalabilidad sin compromisos en el ecosistema Web3
Escalabilidad y compensaciones: Cómo Polkadot busca el equilibrio en el ecosistema Web3
En la actualidad, en la búsqueda de una mayor eficiencia en blockchain, surge una cuestión clave: ¿cómo evitar sacrificar la seguridad y la resiliencia del sistema al mismo tiempo que se mejora el rendimiento? Este no es solo un desafío a nivel técnico, sino una elección profunda 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.
Polkadot, como un importante impulsor de la escalabilidad en Web3, ¿ha hecho 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 decisiones de diseño de escalabilidad de Polkadot, y comparándolos 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 la flexibilidad 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 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 en la cadena de relé conectado, cuya comunicación utiliza un mecanismo llamado 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 núcleo de la cadena de relé, siempre que se cumpla una condición: debe ser un cambio de estado válido; de lo contrario, el estado de ese rollup no será avanzado.
Compromiso de escalado vertical
Rollup puede lograr la escalabilidad vertical aprovechando la arquitectura multicore de Polkadot. Esta nueva capacidad se introduce a través de 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 realiza de manera fija en un solo core, esto podría afectar su elasticidad.
Dado que el protocolo para enviar bloques a la cadena de intermediario es sin permisos y sin confianza, cualquier persona puede enviar bloques para ser verificados en cualquiera de los núcleos asignados al rollup. 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, por lo tanto, reduciendo el rendimiento y la eficiencia general del rollup.
El objetivo de Polkadot es mantener la elasticidad de los rollups y la utilización eficiente de los recursos de la cadena de retransmisión, sin comprometer 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 el ordenante no actuará de manera maliciosa, asegurando así la vitalidad 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 utilizar el protocolo collator para enviar solicitudes de cambios de estado de rollup.
Polkadot: 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 elasticidad y seguridad. Polkadot volverá a ejecutar la transformación del 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 criptográfico ELVES.
Antes de que se escriba en la capa de disponibilidad de datos (DA) de Polkadot cualquier bloque de rollup, un grupo compuesto por aproximadamente 5 validadores verificará primero su legalidad. Reciben los recibos candidatos y las pruebas de validez presentadas por el ordenante, que incluyen el bloque 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á 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 el í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 propiedades de no confianza y no 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, 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, solo se necesita un validador honesto para mantener la viabilidad.
Gracias al protocolo ELVES, Polkadot extiende su seguridad de manera integral a todas las 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.
Por lo tanto, los rollups de Polkadot pueden lograr una verdadera escalabilidad sin sacrificar la seguridad.
versatilidad
La escalabilidad 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 escalabilidad 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 compromiso 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 algunos 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 la cadena o fuera de la cadena. Por ejemplo:
Estrategia simple: siempre usar una cantidad fija de core, o ajustar manualmente fuera de la cadena;
Estrategia ligera: monitorear cargas de transacciones específicas en el mempool de nodos;
Estrategia de automatización: configurar recursos anticipadamente a través de datos históricos y la interfaz XCM para invocar el servicio coretime.
Aunque la automatización es más eficiente, los costos de implementación y prueba también aumentan significativamente.
interoperabilidad
Polkadot soporta la interoperabilidad entre diferentes rollups, y la escalabilidad elástica 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 bloque 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, 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, fortaleciendo aún más la capacidad de escalado vertical del sistema.
¿Qué compromisos han hecho otros protocolos?
Como es bien sabido, la mejora del rendimiento a menudo se logra a costa 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 implementa escalabilidad a través de una arquitectura de alta capacidad de procesamiento en 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 que puede alcanzar 65,000.
Un diseño clave es su mecanismo de programación de líderes que es previamente público y verificable:
Al inicio de cada epoch (aproximadamente cada 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 un 1% de oportunidad de crear bloques;
Todos los mineros 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 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 bloquear, 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, en su búsqueda de TPS, ha sacrificado la descentralización y la resistencia a ataques, su coeficiente de Nakamoto es de solo 20, muy por debajo de los 172 de Polkadot.
TON
Un proyecto de blockchain 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 una red pública descentralizada.
El mecanismo de consenso de este proyecto presenta vulnerabilidades de seguridad: la identidad de los nodos de verificación de fragmentos se expone por adelantado. Su libro blanco también señala claramente que, aunque esto puede optimizar el ancho de banda, también puede ser utilizado maliciosamente. Debido a la falta de un mecanismo de "quiebra de apostadores", un atacante puede esperar a que un fragmento esté completamente bajo su control, o interrumpir a los validadores honestos mediante un ataque DDoS, lo que le 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, siempre que haya un validador honesto que inicie 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 + subred 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 escalabilidad. Sin embargo, Avalanche permite a los validadores elegir libremente participar en subredes, y estas 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, 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 escalabilidad de Ethereum se basa en la escalabilidad de la capa de rollup, en lugar de abordar el problema directamente en la capa base. Esta forma de proceder no resuelve el problema en sí, sino que lo transfiere a la capa superior de la pila.
Rollup Optimista
Actualmente, la mayoría de los rollups optimistas son centralizados (algunos incluso tienen un solo secuenciador), lo que plantea problemas de insuficiente seguridad, aislamiento entre ellos y alta latencia (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 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 el volumen de transacciones por lote, lo que puede causar congestión en la red y aumento de gas durante períodos de alta demanda, afectando la experiencia del usuario.
En comparación, el costo de ZK rollup completamente Turing es aproximadamente 2x10^6 veces el 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 garantizar que cualquiera pueda verificar las transacciones, aún es necesario proporcionar datos completos de las transacciones. Esto suele depender 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 la centralización por rendimiento ni de intercambiar confianza preestablecida por eficiencia, sino que ha logrado un equilibrio multidimensional de 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 una implementación a mayor escala hoy en día, la "escalabilidad de cero confianza" que defiende Polkadot podría ser la verdadera solución que respalde el desarrollo a largo plazo de Web3.