La elección y el equilibrio en la escalabilidad de la Cadena de bloques: un ejemplo de Polkadot
En la actualidad, en la que la tecnología de la cadena de bloques busca constantemente una mayor eficiencia, un problema clave ha ido surgiendo: ¿cómo evitar sacrificar la seguridad y la resiliencia del sistema al mismo tiempo que se mejora el rendimiento? Este no solo es un desafío a nivel técnico, sino también una profunda elección de diseño arquitectónico. Para el ecosistema Web3, un sistema más rápido basado en el sacrificio de la confianza y la seguridad a menudo resulta difícil de sostener para una innovación verdaderamente sostenible.
Como un importante impulsor de la escalabilidad en Web3, ¿ha hecho Polkadot ciertos sacrificios bajo el 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 preguntas, analizando en profundidad los compromisos y elecciones de diseño de escalabilidad de Polkadot, y comparará sus soluciones con las de otras cadenas de bloques principales, explorando sus diferentes enfoques en relación con el rendimiento, la seguridad y la 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 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, lo que afectaría sus características de descentralización?
La operación de Rollup depende de un ordenante de la cadena de bloques intermedia, cuya comunicación utiliza un mecanismo llamado protocolo collator. Este protocolo es completamente sin permiso y sin confianza, cualquier persona con conexión a la red puede usarlo, conectando una pequeña cantidad de nodos de la cadena de bloques intermedia y enviando solicitudes de conversión de estado de rollup. Estas solicitudes serán verificadas por algún core de la cadena de bloques intermedia, siempre que se cumpla un requisito: debe ser una conversión de estado válida, de lo contrario, el estado de ese rollup no avanzará.
Compensación de expansión 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 "escalado flexible". Durante el proceso de diseño, se descubrió que, dado que la validación de bloques de rollup no se realiza en un core fijo, esto podría afectar su elasticidad.
Debido a 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. Un atacante podría aprovechar esto para volver a enviar bloques legítimos que ya han sido verificados a diferentes núcleos, consumiendo recursos maliciosamente, lo que reduciría 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 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 en 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 es necesario mantener las características de "sin confianza" y "sin permiso" del sistema. Cualquiera debería poder utilizar el protocolo collator para enviar solicitudes de cambio de estado de rollup.
Polkadot: Solución sin compromisos
La solución elegida finalmente por Polkadot es: dejar que la función de conversión de estado del rollup (Runtime) resuelva completamente el problema. 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 ejecutar la validación.
Este diseño logra una doble garantía de elasticidad y seguridad. Polkadot volverá a ejecutar la transición de estado del rollup en el proceso de disponibilidad y asegurará la correcta asignación del núcleo a través del protocolo económico de ELVES.
Antes de que cualquier bloque de rollup escriba en la capa de disponibilidad de datos de Polkadot, un grupo compuesto por alrededor de 5 validadores verificará primero su legalidad. Reciben los recibos candidatos y las pruebas de validez presentadas por el ordenante, que contienen 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 (core selector) que se utiliza para especificar en qué núcleo (core) se debe validar el Bloquear. El validador comparará si el índice coincide con el núcleo (core) del que es responsable; si no coincide, el Bloquear será descartado.
Este mecanismo garantiza que el sistema mantenga siempre las propiedades de ser sin necesidad de confianza y sin permisos, 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 resiliencia.
seguridad
En el proceso de búsqueda de escalabilidad, Polkadot no ha comprometido la seguridad. La seguridad del rollup está garantizada por la cadena de retransmisión, y solo se necesita un reordenador 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 los núcleos, sin necesidad de imponer restricciones o suposiciones 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 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 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 compensar 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 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 cadena o fuera de cadena. Por ejemplo:
Estrategia simple: siempre usar una cantidad fija de core, o ajustar manualmente fuera de la cadena.
Estrategia ligera: monitorear la carga de transacciones específicas en el mempool del nodo;
Estrategia automatizada: configurar recursos anticipadamente a través de datos históricos y la interfaz XCM para llamar al servicio coretime.
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 rendimiento del envío 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 admitirá la mensajería fuera de la cadena, 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, lo que fortalecerá aún más la capacidad de escalabilidad vertical del sistema.
¿Qué concesiones han hecho otros protocolos?
Como todos saben, la mejora del rendimiento a menudo viene a expensas de la descentralización y la seguridad. Sin embargo, desde la perspectiva del coeficiente de Nakamoto, incluso si algunos competidores de Polkadot tienen un menor grado de descentralización, su rendimiento tampoco 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, apoyándose en la prueba de historia, 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 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 asignará. Por ejemplo, un validador que apueste el 1% tendrá aproximadamente un 1% de oportunidad de bloquear.
Todos los productores de bloques se anuncian con anticipación, lo que aumenta el riesgo de que la red sufra ataques DDoS dirigidos y caídas frecuentes.
La historia demuestra que el procesamiento paralelo requiere un hardware extremadamente alto, lo que lleva a la centralización de los nodos de verificación. Cuantos más nodos se apuestan, mayores son las oportunidades de que esos nodos generen bloques, mientras que los nodos pequeños casi no tienen slot, 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 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 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 permite alterar el estado.
En comparación, los validadores de Polkadot son asignados aleatoriamente y se revelan con retraso, los atacantes no pueden conocer de antemano la identidad de los validadores, el ataque debe apostar todo el control para tener éxito; tan pronto como un validador honesto inicie una disputa, el ataque fracasará y causará pérdidas al atacante en 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 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 garantías 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 se basa en 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 traslada 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 plantea problemas de seguridad insuficiente, aislamiento entre ellos y alta latencia (se debe esperar el período de prueba de fraude, que suele durar 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 centralizar el 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 ZK rollup Turing completo es aproximadamente 2x10^6 veces el del protocolo de seguridad económica criptográfica 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 se necesita proporcionar datos de transacción completos. Esto a menudo depende de soluciones adicionales de disponibilidad de datos, lo que eleva 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, el 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 implementación a mayor escala hoy en día, la "escalabilidad de cero 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.
Escalabilidad flexible de Polkadot: buscando un equilibrio entre rendimiento y Descentralización
La elección y el equilibrio en la escalabilidad de la Cadena de bloques: un ejemplo de Polkadot
En la actualidad, en la que la tecnología de la cadena de bloques busca constantemente una mayor eficiencia, un problema clave ha ido surgiendo: ¿cómo evitar sacrificar la seguridad y la resiliencia del sistema al mismo tiempo que se mejora el rendimiento? Este no solo es un desafío a nivel técnico, sino también una profunda elección de diseño arquitectónico. Para el ecosistema Web3, un sistema más rápido basado en el sacrificio de la confianza y la seguridad a menudo resulta difícil de sostener para una innovación verdaderamente sostenible.
Como un importante impulsor de la escalabilidad en Web3, ¿ha hecho Polkadot ciertos sacrificios bajo el 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 preguntas, analizando en profundidad los compromisos y elecciones de diseño de escalabilidad de Polkadot, y comparará sus soluciones con las de otras cadenas de bloques principales, explorando sus diferentes enfoques en relación con el rendimiento, la seguridad y la 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 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, lo que afectaría sus características de descentralización?
La operación de Rollup depende de un ordenante de la cadena de bloques intermedia, cuya comunicación utiliza un mecanismo llamado protocolo collator. Este protocolo es completamente sin permiso y sin confianza, cualquier persona con conexión a la red puede usarlo, conectando una pequeña cantidad de nodos de la cadena de bloques intermedia y enviando solicitudes de conversión de estado de rollup. Estas solicitudes serán verificadas por algún core de la cadena de bloques intermedia, siempre que se cumpla un requisito: debe ser una conversión de estado válida, de lo contrario, el estado de ese rollup no avanzará.
Compensación de expansión 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 "escalado flexible". Durante el proceso de diseño, se descubrió que, dado que la validación de bloques de rollup no se realiza en un core fijo, esto podría afectar su elasticidad.
Debido a 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. Un atacante podría aprovechar esto para volver a enviar bloques legítimos que ya han sido verificados a diferentes núcleos, consumiendo recursos maliciosamente, lo que reduciría 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 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 en 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 es necesario mantener las características de "sin confianza" y "sin permiso" del sistema. Cualquiera debería poder utilizar el protocolo collator para enviar solicitudes de cambio de estado de rollup.
Polkadot: Solución sin compromisos
La solución elegida finalmente por Polkadot es: dejar que la función de conversión de estado del rollup (Runtime) resuelva completamente el problema. 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 ejecutar la validación.
Este diseño logra una doble garantía de elasticidad y seguridad. Polkadot volverá a ejecutar la transición de estado del rollup en el proceso de disponibilidad y asegurará la correcta asignación del núcleo a través del protocolo económico de ELVES.
Antes de que cualquier bloque de rollup escriba en la capa de disponibilidad de datos de Polkadot, un grupo compuesto por alrededor de 5 validadores verificará primero su legalidad. Reciben los recibos candidatos y las pruebas de validez presentadas por el ordenante, que contienen 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 (core selector) que se utiliza para especificar en qué núcleo (core) se debe validar el Bloquear. El validador comparará si el índice coincide con el núcleo (core) del que es responsable; si no coincide, el Bloquear será descartado.
Este mecanismo garantiza que el sistema mantenga siempre las propiedades de ser sin necesidad de confianza y sin permisos, 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 resiliencia.
seguridad
En el proceso de búsqueda de escalabilidad, Polkadot no ha comprometido la seguridad. La seguridad del rollup está garantizada por la cadena de retransmisión, y solo se necesita un reordenador 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 los núcleos, sin necesidad de imponer restricciones o suposiciones 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 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 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 compensar 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 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 cadena o fuera de cadena. Por ejemplo:
Estrategia simple: siempre usar una cantidad fija de core, o ajustar manualmente fuera de la cadena.
Estrategia ligera: monitorear la carga de transacciones específicas en el mempool del nodo;
Estrategia automatizada: configurar recursos anticipadamente a través de datos históricos y la interfaz XCM para llamar al servicio coretime.
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 rendimiento del envío 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 admitirá la mensajería fuera de la cadena, 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, lo que fortalecerá aún más la capacidad de escalabilidad vertical del sistema.
¿Qué concesiones han hecho otros protocolos?
Como todos saben, la mejora del rendimiento a menudo viene a expensas de la descentralización y la seguridad. Sin embargo, desde la perspectiva del coeficiente de Nakamoto, incluso si algunos competidores de Polkadot tienen un menor grado de descentralización, su rendimiento tampoco 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, apoyándose en la prueba de historia, 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 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 asignará. Por ejemplo, un validador que apueste el 1% tendrá aproximadamente un 1% de oportunidad de bloquear.
Todos los productores de bloques se anuncian con anticipación, lo que aumenta el riesgo de que la red sufra ataques DDoS dirigidos y caídas frecuentes.
La historia demuestra que el procesamiento paralelo requiere un hardware extremadamente alto, lo que lleva a la centralización de los nodos de verificación. Cuantos más nodos se apuestan, mayores son las oportunidades de que esos nodos generen bloques, mientras que los nodos pequeños casi no tienen slot, 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 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 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 permite alterar el estado.
En comparación, los validadores de Polkadot son asignados aleatoriamente y se revelan con retraso, los atacantes no pueden conocer de antemano la identidad de los validadores, el ataque debe apostar todo el control para tener éxito; tan pronto como un validador honesto inicie una disputa, el ataque fracasará y causará pérdidas al atacante en 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 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 garantías 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 se basa en 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 traslada 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 plantea problemas de seguridad insuficiente, aislamiento entre ellos y alta latencia (se debe esperar el período de prueba de fraude, que suele durar 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 centralizar el 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 ZK rollup Turing completo es aproximadamente 2x10^6 veces el del protocolo de seguridad económica criptográfica 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 se necesita proporcionar datos de transacción completos. Esto a menudo depende de soluciones adicionales de disponibilidad de datos, lo que eleva 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, el 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 implementación a mayor escala hoy en día, la "escalabilidad de cero confianza" que sostiene Polkadot podría ser la verdadera solución que respalde el desarrollo a largo plazo de Web3.