La compensación de la escalabilidad de la cadena de bloques: la elección entre Polkadot y Web3
En la actualidad, mientras la Cadena de bloques sigue buscando mejorar la eficiencia, surge una pregunta clave: ¿cómo se puede 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 profunda elección en el diseño de la arquitectura. Para el ecosistema Web3, buscar únicamente sistemas más rápidos mientras se ignora la confianza y la seguridad, es difícil de sostener para una innovación verdaderamente sostenible.
Como un importante impulsor de la escalabilidad en Web3, ¿ha hecho Polkadot algún sacrificio en su búsqueda de un alto rendimiento y baja latencia? ¿Su modelo de rollup ha comprometido la descentralización, la seguridad o la interoperabilidad de la red?
Este artículo discutirá estas cuestiones, analizando en profundidad las compensaciones de diseño de escalabilidad de Polkadot y comparándolas con las soluciones de otras cadenas de bloques principales, explorando sus diferentes elecciones en 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 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 a sus características de descentralización?
La operación de Rollup depende del ordenamiento del conector de la cadena de bloques, cuya comunicación utiliza el mecanismo del protocolo collator. Este protocolo es completamente sin permisos y sin confianza, cualquier persona con conexión a la red puede usarlo, conectándose a un número reducido de nodos de la cadena de bloques, y enviando solicitudes de cambio de estado de rollup. Estas solicitudes serán verificadas por un core de la cadena de bloques, y solo necesitan cumplir con un requisito: deben ser cambios de estado válidos, de lo contrario, el estado de ese rollup no será avanzado.
Compromiso de expansión vertical
Rollup puede lograr escalabilidad vertical al aprovechar 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 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 retransmisión es sin permiso y sin confianza, cualquier persona puede enviar bloques a cualquiera de los núcleos asignados al rollup para su validación. Un atacante podría aprovechar esto para enviar repetidamente 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.
¿Es de confianza Sequencer?
Una solución simple es configurar el protocolo como "con licencia": por ejemplo, adoptar un mecanismo de lista blanca, o confiar 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 secuenciador, ya que se deben mantener las características de «sin confianza» y «sin permisos» del sistema. Cualquiera debería poder utilizar el protocolo de collator para enviar solicitudes de transformación 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 completamente. 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 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 del core a través del protocolo económico criptográfico ELVES.
Antes de que cualquier bloque de rollup se escriba en la capa de disponibilidad de datos de Polkadot, un grupo compuesto por aproximadamente 5 validadores verificará primero su legalidad. Ellos 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 validación de la cadena paralela, y será re-ejecutada por los validadores en la cadena de retransmisión.
En el resultado de la verificación se incluye un selector de núcleo, que se utiliza para especificar en qué núcleo se debe validar el Bloquear. El validador comparará si este índice coincide con el núcleo del que es responsable; si no coincide, el Bloquear será descartado.
Este mecanismo asegura que el sistema mantenga siempre las propiedades de no requerir confianza y no requerir permisos, evitando que actores maliciosos como los ordenadores manipulen la posición de validación, garantizando que incluso si el rollup utiliza múltiples núcleos, pueda mantener su 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 validador honesto para mantener la viabilidad.
Gracias al protocolo ELVES, Polkadot extiende su seguridad de manera integral a todos los rollups, validando todos los cálculos en el núcleo, sin necesidad de imponer ninguna 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. Gracias a la expansión elástica, se incrementa la cantidad total de cálculos que se pueden ejecutar en cada ciclo de 6 segundos, 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 ciertos requisitos del 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 del nodo;
Estrategia automatizada: a través de datos históricos y la interfaz XCM, se llama por adelantado al servicio coretime para configurar recursos.
Aunque el método automatizado 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 flexible no afecta el rendimiento de la mensajería.
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, independientemente de la cantidad de núcleos asignados.
En el futuro, Polkadot también soportará la transmisión de mensajes fuera de la cadena, utilizando la cadena de retransmisión como la interfaz de control, en lugar de la interfaz 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 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 con una arquitectura de alta capacidad de procesamiento en una sola capa, dependiendo de la prueba histórica (PoH), el procesamiento paralelo de la 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úblico y verificable por adelantado:
Al inicio de cada epoch (aproximadamente dos días o 432,000 slots), se asignan slots según la cantidad de participación;
Cuanto más se apueste, más se distribuirá. Por ejemplo, un validador que apueste el 1% tendrá aproximadamente un 1% de oportunidad de generar bloques;
Todos los productores de bloques se anuncian con antelación, lo que aumenta el riesgo de que la red sufra ataques DDoS dirigidos y caídas frecuentes.
PoH y el procesamiento paralelo tienen requisitos de hardware extremadamente altos, lo que lleva a la centralización de los nodos de validación. Cuantos más nodos se apuesten, mayor será la oportunidad de que generen 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, en su búsqueda de TPS, sacrificó la descentralización y la capacidad de resistencia a ataques, su coeficiente de Nakamoto es de solo 20, muy por debajo de los 172 de Polkadot.
TON
TON afirma que su TPS puede alcanzar 104,715, pero esta cifra se logró en una red de prueba privada, con 256 nodos, en condiciones ideales de red y hardware. Por otro lado, Polkadot ha alcanzado 128K TPS en su red pública descentralizada.
El mecanismo de consenso de TON presenta riesgos de seguridad: la identidad de los nodos de validación de fragmentos se expone con antelación. El libro blanco de TON también señala claramente que, aunque esto puede optimizar el ancho de banda, también puede ser explotado maliciosamente. Debido a la falta de un mecanismo de "quiebra de apostadores", los atacantes pueden esperar a que un fragmento sea completamente controlado por ellos 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, lo que impide que los atacantes conozcan de antemano la identidad de los validadores. Para que un ataque tenga éxito, se debe apostar por el control total; tan pronto como un validador honesto inicie una disputa, el ataque fallará y el atacante perderá su participación.
Avalanche
Avalanche utiliza una arquitectura de red principal + subred 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 tiene un TPS teórico de ~5,000, similar a la idea de Polkadot: reducir la carga de un solo bloque para lograr 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, y 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 rollup, en lugar de resolver los problemas 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.
Optimistic Rollup
En la actualidad, la mayoría de los rollups optimistas son centralizados (algunos incluso tienen solo un secuenciador), lo que presenta problemas de seguridad insuficiente, aislamiento entre ellos y alta latencia (deben esperar el período de prueba de fraude, que generalmente dura 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 causar 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 aumentos 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, el problema de la disponibilidad de datos en ZK rollup también agravará sus desventajas. Para asegurar que cualquier persona pueda verificar las transacciones, aún se necesita proporcionar los 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 la escalabilidad flexible, diseño de protocolos 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, la "escalabilidad sin confianza" que sostiene 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.
16 me gusta
Recompensa
16
6
Republicar
Compartir
Comentar
0/400
Fren_Not_Food
· 07-23 13:22
El proyecto se presenta bastante bien, pero veamos el rendimiento real.
Ver originalesResponder0
BlockchainDecoder
· 07-23 11:10
Citando datos recientes del grupo de investigación Cho, el tps de cadena única generalmente es inferior a 3k, y la cuestión de la compensación necesita ser superada urgentemente.
Ver originalesResponder0
GasGuzzler
· 07-21 02:15
La expansión lineal pura no ganará.
Ver originalesResponder0
DataOnlooker
· 07-21 02:15
Mira de nuevo~ DOT siempre ha estado sin despegar.
Ver originalesResponder0
LidoStakeAddict
· 07-21 02:04
Decir cosas bonitas, se desvanecen en el aire con solo una frase.
Escalabilidad sin compromisos de Polkadot: una nueva opción para el ecosistema Web3
La compensación de la escalabilidad de la cadena de bloques: la elección entre Polkadot y Web3
En la actualidad, mientras la Cadena de bloques sigue buscando mejorar la eficiencia, surge una pregunta clave: ¿cómo se puede 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 profunda elección en el diseño de la arquitectura. Para el ecosistema Web3, buscar únicamente sistemas más rápidos mientras se ignora la confianza y la seguridad, es difícil de sostener para una innovación verdaderamente sostenible.
Como un importante impulsor de la escalabilidad en Web3, ¿ha hecho Polkadot algún sacrificio en su búsqueda de un alto rendimiento y baja latencia? ¿Su modelo de rollup ha comprometido la descentralización, la seguridad o la interoperabilidad de la red?
Este artículo discutirá estas cuestiones, analizando en profundidad las compensaciones de diseño de escalabilidad de Polkadot y comparándolas con las soluciones de otras cadenas de bloques principales, explorando sus diferentes elecciones en 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 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 a sus características de descentralización?
La operación de Rollup depende del ordenamiento del conector de la cadena de bloques, cuya comunicación utiliza el mecanismo del protocolo collator. Este protocolo es completamente sin permisos y sin confianza, cualquier persona con conexión a la red puede usarlo, conectándose a un número reducido de nodos de la cadena de bloques, y enviando solicitudes de cambio de estado de rollup. Estas solicitudes serán verificadas por un core de la cadena de bloques, y solo necesitan cumplir con un requisito: deben ser cambios de estado válidos, de lo contrario, el estado de ese rollup no será avanzado.
Compromiso de expansión vertical
Rollup puede lograr escalabilidad vertical al aprovechar 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 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 retransmisión es sin permiso y sin confianza, cualquier persona puede enviar bloques a cualquiera de los núcleos asignados al rollup para su validación. Un atacante podría aprovechar esto para enviar repetidamente 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.
¿Es de confianza Sequencer?
Una solución simple es configurar el protocolo como "con licencia": por ejemplo, adoptar un mecanismo de lista blanca, o confiar 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 secuenciador, ya que se deben mantener las características de «sin confianza» y «sin permisos» del sistema. Cualquiera debería poder utilizar el protocolo de collator para enviar solicitudes de transformación 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 completamente. 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 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 del core a través del protocolo económico criptográfico ELVES.
Antes de que cualquier bloque de rollup se escriba en la capa de disponibilidad de datos de Polkadot, un grupo compuesto por aproximadamente 5 validadores verificará primero su legalidad. Ellos 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 validación de la cadena paralela, y será re-ejecutada por los validadores en la cadena de retransmisión.
En el resultado de la verificación se incluye un selector de núcleo, que se utiliza para especificar en qué núcleo se debe validar el Bloquear. El validador comparará si este índice coincide con el núcleo del que es responsable; si no coincide, el Bloquear será descartado.
Este mecanismo asegura que el sistema mantenga siempre las propiedades de no requerir confianza y no requerir permisos, evitando que actores maliciosos como los ordenadores manipulen la posición de validación, garantizando que incluso si el rollup utiliza múltiples núcleos, pueda mantener su 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 validador honesto para mantener la viabilidad.
Gracias al protocolo ELVES, Polkadot extiende su seguridad de manera integral a todos los rollups, validando todos los cálculos en el núcleo, sin necesidad de imponer ninguna 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. Gracias a la expansión elástica, se incrementa la cantidad total de cálculos que se pueden ejecutar en cada ciclo de 6 segundos, 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 ciertos requisitos del RFC103 para adaptarse a diferentes escenarios de uso.
La complejidad específica depende de la estrategia de gestión de recursos del rollup, que puede depender de variables en la cadena o fuera de la cadena. Por ejemplo:
Aunque el método automatizado 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 flexible no afecta el rendimiento de la mensajería.
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, independientemente de la cantidad de núcleos asignados.
En el futuro, Polkadot también soportará la transmisión de mensajes fuera de la cadena, utilizando la cadena de retransmisión como la interfaz de control, en lugar de la interfaz 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 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 con una arquitectura de alta capacidad de procesamiento en una sola capa, dependiendo de la prueba histórica (PoH), el procesamiento paralelo de la 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úblico y verificable por adelantado:
PoH y el procesamiento paralelo tienen requisitos de hardware extremadamente altos, lo que lleva a la centralización de los nodos de validación. Cuantos más nodos se apuesten, mayor será la oportunidad de que generen 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, en su búsqueda de TPS, sacrificó la descentralización y la capacidad de resistencia a ataques, su coeficiente de Nakamoto es de solo 20, muy por debajo de los 172 de Polkadot.
TON
TON afirma que su TPS puede alcanzar 104,715, pero esta cifra se logró en una red de prueba privada, con 256 nodos, en condiciones ideales de red y hardware. Por otro lado, Polkadot ha alcanzado 128K TPS en su red pública descentralizada.
El mecanismo de consenso de TON presenta riesgos de seguridad: la identidad de los nodos de validación de fragmentos se expone con antelación. El libro blanco de TON también señala claramente que, aunque esto puede optimizar el ancho de banda, también puede ser explotado maliciosamente. Debido a la falta de un mecanismo de "quiebra de apostadores", los atacantes pueden esperar a que un fragmento sea completamente controlado por ellos 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, lo que impide que los atacantes conozcan de antemano la identidad de los validadores. Para que un ataque tenga éxito, se debe apostar por el control total; tan pronto como un validador honesto inicie una disputa, el ataque fallará y el atacante perderá su participación.
Avalanche
Avalanche utiliza una arquitectura de red principal + subred 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 tiene un TPS teórico de ~5,000, similar a la idea de Polkadot: reducir la carga de un solo bloque para lograr 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, y 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 rollup, en lugar de resolver los problemas 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.
Optimistic Rollup
En la actualidad, la mayoría de los rollups optimistas son centralizados (algunos incluso tienen solo un secuenciador), lo que presenta problemas de seguridad insuficiente, aislamiento entre ellos y alta latencia (deben esperar el período de prueba de fraude, que generalmente dura 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 causar 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 aumentos 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, el problema de la disponibilidad de datos en ZK rollup también agravará sus desventajas. Para asegurar que cualquier persona pueda verificar las transacciones, aún se necesita proporcionar los 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 la escalabilidad flexible, diseño de protocolos 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, la "escalabilidad sin confianza" que sostiene Polkadot podría ser la verdadera solución que respalde el desarrollo a largo plazo de Web3.