Equilibrio de escalabilidad de la Cadena de bloques: el caso de Polkadot
En la actualidad, en la búsqueda de una mayor eficiencia en la tecnología de cadena de bloques, un problema clave ha comenzado a surgir: ¿cómo mejorar el rendimiento sin sacrificar la seguridad y la resiliencia del sistema? Este no solo es un desafío a nivel técnico, sino también una profunda elección en el diseño de la arquitectura. Para el ecosistema Web3, un sistema más rápido que se basa en sacrificar la confianza y la seguridad, a menudo tiene dificultades para sostener una innovación verdaderamente sostenible.
Este artículo profundizará en los compromisos y sacrificios de Polkadot en el diseño de escalabilidad, y lo comparará con las soluciones de otras cadenas de bloques principales, analizando sus diferentes enfoques en relación con el rendimiento, la seguridad y la descentralización.
Desafíos en el diseño de expansión de Polkadot
Equilibrio entre elasticidad y descentralización
La arquitectura de Polkadot depende de una red de validadores y de la Cadena de bloques de retransmisión (Relay Chain). El funcionamiento de Rollup depende de un secuenciador (sequencer) que conecta la Cadena de bloques de retransmisión, cuya comunicación utiliza el mecanismo del protocolo collator. Este protocolo no requiere permisos ni confianza, cualquier persona con conexión a la red puede usarlo, conectar unos pocos nodos de la Cadena de bloques de retransmisión y enviar solicitudes de cambio de estado de rollup. Estas solicitudes serán verificadas por algún núcleo de la Cadena de bloques de retransmisión, solo se debe cumplir un requisito: debe ser un cambio de estado válido, de lo contrario, el estado del rollup no avanzará.
Compensación de la expansión vertical
Rollup puede lograr la escalabilidad vertical aprovechando la arquitectura multicore de Polkadot. Esta nueva capacidad es introducida por la función de "Escalado Elástico". Durante el proceso de diseño se descubrió que, dado que la verificación de bloques de rollup no se realiza de manera fija en un core específico, 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 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 maliciosamente recursos 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 efectiva de los recursos de la cadena de retransmisión sin afectar las características clave del sistema.
Problemas de confianza del Secuenciador
Una solución simple es establecer el protocolo como "con licencia": por ejemplo, utilizando un mecanismo de lista blanca, o confiando por defecto en que el ordenante no actuará de manera maliciosa, garantizando 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 licencia" del sistema. Cualquiera debería poder usar el protocolo de collator para enviar solicitudes de cambio de estado del rollup.
Polkadot: Solución sin compromisos
La solución finalmente elegida por Polkadot es: dejar que la función de transformación de estado (Runtime) del rollup resuelva el problema por completo. El 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 conversió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 criptográfico ELVES.
Antes de que cualquier bloque de rollup se escriba en la capa de disponibilidad de datos (DA) de Polkadot, un grupo compuesto por aproximadamente 5 validadores verificará primero su legalidad. Reciben recibos de candidatos (candidate receipt) y pruebas de validez (PoV) enviados por el ordenante, que contienen bloques 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 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 las posiciones de verificación, asegurando 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.
Con el protocolo ELVES, Polkadot extiende completamente su seguridad a todos los rollups, validando todos los cálculos en el núcleo, sin necesidad de imponer limitaciones 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 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 WebAssembly, siempre que la ejecución única se complete en menos de 2 segundos. Gracias a la escalabilidad elástica, la cantidad total de cálculos que se pueden ejecutar en un ciclo de 6 segundos se incrementa, pero el tipo de cálculo no se ve afectado.
complejidad
Un mayor rendimiento y una menor latencia inevitablemente introducen complejidad, que es la única forma aceptable de compensación en el diseño del sistema.
Rollup puede ajustar dinámicamente los recursos a través de la interfaz Agile Coretime para mantener un nivel de seguridad consistente. También deben cumplir con parte de los requisitos RFC103 para adaptarse a diferentes escenarios de uso.
La complejidad específica depende de la estrategia de gestión de recursos del rollup, que puede depender de variables en la cadena o fuera de la cadena. Por ejemplo:
Estrategia simple: siempre utiliza una cantidad fija de core, o ajusta manualmente fuera de la cadena;
Estrategia ligera: monitorear cargas de transacción específicas en el mempool del nodo;
Estrategias automatizadas: a través de datos históricos y la interfaz XCM, se llaman por adelantado los servicios 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 admite la interoperabilidad entre diferentes rollups, y la escalabilidad elástica no afectará el rendimiento de la mensajería.
La comunicación de mensajes entre rollups se realiza a través de la capa de transmisión 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 admitirá la mensajería fuera de la cadena (off-chain messaging), con la cadena de retransmisión actuando 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, aumentando aún más la capacidad de escalabilidad vertical del sistema.
Compensaciones de otros protocolos
Como es bien sabido, la mejora del rendimiento a menudo tiene un costo en la descentralización y la seguridad. Pero 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 la escalabilidad a través de una arquitectura de alta capacidad de procesamiento de una sola capa, dependiendo de 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 públicamente accesible y verificable:
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% obtendrá aproximadamente el 1% de la oportunidad de bloquear.
Todos los bloqueadores se anuncian por adelantado, 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 nodos de validación. Cuantos más nodos estén en staking, mayor será la oportunidad de que 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 sacrificó 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 este número se logró en una red de prueba privada, con 256 nodos y 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 vulnerabilidades 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 a través de un ataque DDoS, alterando así el estado.
En comparación, los validadores de Polkadot son asignados de manera aleatoria y se revelan con retraso, por lo que los atacantes no pueden conocer la identidad de los validadores de antemano. El ataque requiere apostar el control total para tener éxito; mientras haya un validador honesto que inicie una disputa, el ataque fracasará y resultará en la pérdida de la garantía 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 tiene un TPS teórico de hasta ~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 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 predeterminada, algunas 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 resolver problemas directamente en la capa base. Este enfoque, en esencia, no resuelve el problema, sino que lo transfiere a la capa superior de la pila.
Optimistic Rollup
Actualmente, la mayoría de los rollups optimistas son centralizados (algunos incluso tienen un solo secuenciador), lo que plantea problemas de seguridad insuficiente, 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 se ve limitada por la cantidad de datos que se pueden procesar por transacción. La demanda de cálculo para generar pruebas de conocimiento cero es extremadamente alta, y el mecanismo de "el ganador se lleva todo" puede llevar a la centralización del sistema. Para garantizar el TPS, ZK rollup a menudo limita la cantidad de transacciones por lote, lo que puede causar congestión en la red y un aumento del gas en momentos de alta demanda, afectando la experiencia del usuario.
En comparación, el costo del ZK rollup totalmente compatible con Turing es aproximadamente 2x10^6 veces el del protocolo de seguridad económica central de Polkadot.
Además, el problema de disponibilidad de datos en ZK rollup también agravará sus desventajas. Para garantizar que cualquier persona pueda verificar las transacciones, aún se necesita 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 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, 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 la implementación a gran escala hoy en día, la "escalabilidad sin 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.
9 me gusta
Recompensa
9
6
Compartir
Comentar
0/400
GateUser-a5fa8bd0
· hace8h
¡Hay que aprender bien dot! Dependiendo del viejo oficio, ya no es confiable.
Ver originalesResponder0
AirdropworkerZhang
· 08-01 00:33
Esta eficiencia es increíblemente alta y el costo es increíblemente bajo. Jefe, me voy a la minería.
Ver originalesResponder0
MEVHunter
· 07-31 10:51
meh... la relaychain de dot todavía tiene cuellos de botella bajo una fuerte presión de mempool, para ser honesto. vi picos de flujo tóxico la semana pasada
Ver originalesResponder0
Lonely_Validator
· 07-31 10:51
Soy un veterano en cadenas públicas, Dot ha sido muy popular durante todo el proceso.
Escalabilidad flexible de Polkadot: un equilibrio intransigente entre rendimiento y seguridad en Web3
Equilibrio de escalabilidad de la Cadena de bloques: el caso de Polkadot
En la actualidad, en la búsqueda de una mayor eficiencia en la tecnología de cadena de bloques, un problema clave ha comenzado a surgir: ¿cómo mejorar el rendimiento sin sacrificar la seguridad y la resiliencia del sistema? Este no solo es un desafío a nivel técnico, sino también una profunda elección en el diseño de la arquitectura. Para el ecosistema Web3, un sistema más rápido que se basa en sacrificar la confianza y la seguridad, a menudo tiene dificultades para sostener una innovación verdaderamente sostenible.
Este artículo profundizará en los compromisos y sacrificios de Polkadot en el diseño de escalabilidad, y lo comparará con las soluciones de otras cadenas de bloques principales, analizando sus diferentes enfoques en relación con el rendimiento, la seguridad y la descentralización.
Desafíos en el diseño de expansión de Polkadot
Equilibrio entre elasticidad y descentralización
La arquitectura de Polkadot depende de una red de validadores y de la Cadena de bloques de retransmisión (Relay Chain). El funcionamiento de Rollup depende de un secuenciador (sequencer) que conecta la Cadena de bloques de retransmisión, cuya comunicación utiliza el mecanismo del protocolo collator. Este protocolo no requiere permisos ni confianza, cualquier persona con conexión a la red puede usarlo, conectar unos pocos nodos de la Cadena de bloques de retransmisión y enviar solicitudes de cambio de estado de rollup. Estas solicitudes serán verificadas por algún núcleo de la Cadena de bloques de retransmisión, solo se debe cumplir un requisito: debe ser un cambio de estado válido, de lo contrario, el estado del rollup no avanzará.
Compensación de la expansión vertical
Rollup puede lograr la escalabilidad vertical aprovechando la arquitectura multicore de Polkadot. Esta nueva capacidad es introducida por la función de "Escalado Elástico". Durante el proceso de diseño se descubrió que, dado que la verificación de bloques de rollup no se realiza de manera fija en un core específico, 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 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 maliciosamente recursos 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 efectiva de los recursos de la cadena de retransmisión sin afectar las características clave del sistema.
Problemas de confianza del Secuenciador
Una solución simple es establecer el protocolo como "con licencia": por ejemplo, utilizando un mecanismo de lista blanca, o confiando por defecto en que el ordenante no actuará de manera maliciosa, garantizando 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 licencia" del sistema. Cualquiera debería poder usar el protocolo de collator para enviar solicitudes de cambio de estado del rollup.
Polkadot: Solución sin compromisos
La solución finalmente elegida por Polkadot es: dejar que la función de transformación de estado (Runtime) del rollup resuelva el problema por completo. El 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 conversió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 criptográfico ELVES.
Antes de que cualquier bloque de rollup se escriba en la capa de disponibilidad de datos (DA) de Polkadot, un grupo compuesto por aproximadamente 5 validadores verificará primero su legalidad. Reciben recibos de candidatos (candidate receipt) y pruebas de validez (PoV) enviados por el ordenante, que contienen bloques 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 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 las posiciones de verificación, asegurando 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.
Con el protocolo ELVES, Polkadot extiende completamente su seguridad a todos los rollups, validando todos los cálculos en el núcleo, sin necesidad de imponer limitaciones 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 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 WebAssembly, siempre que la ejecución única se complete en menos de 2 segundos. Gracias a la escalabilidad elástica, la cantidad total de cálculos que se pueden ejecutar en un ciclo de 6 segundos se incrementa, pero el tipo de cálculo no se ve afectado.
complejidad
Un mayor rendimiento y una menor latencia inevitablemente introducen complejidad, que es la única forma aceptable de compensación en el diseño del sistema.
Rollup puede ajustar dinámicamente los recursos a través de la interfaz Agile Coretime para mantener un nivel de seguridad consistente. También deben cumplir con parte de los requisitos RFC103 para adaptarse a diferentes escenarios de uso.
La complejidad específica depende de la estrategia de gestión de recursos del rollup, que puede depender de variables en la cadena o fuera de la cadena. Por ejemplo:
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 de la mensajería.
La comunicación de mensajes entre rollups se realiza a través de la capa de transmisión 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 admitirá la mensajería fuera de la cadena (off-chain messaging), con la cadena de retransmisión actuando 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, aumentando aún más la capacidad de escalabilidad vertical del sistema.
Compensaciones de otros protocolos
Como es bien sabido, la mejora del rendimiento a menudo tiene un costo en la descentralización y la seguridad. Pero 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 la escalabilidad a través de una arquitectura de alta capacidad de procesamiento de una sola capa, dependiendo de 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 públicamente accesible y verificable:
PoH y el procesamiento paralelo requieren un hardware extremadamente alto, lo que lleva a la centralización de nodos de validación. Cuantos más nodos estén en staking, mayor será la oportunidad de que 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 sacrificó 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 este número se logró en una red de prueba privada, con 256 nodos y 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 vulnerabilidades 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 a través de un ataque DDoS, alterando así el estado.
En comparación, los validadores de Polkadot son asignados de manera aleatoria y se revelan con retraso, por lo que los atacantes no pueden conocer la identidad de los validadores de antemano. El ataque requiere apostar el control total para tener éxito; mientras haya un validador honesto que inicie una disputa, el ataque fracasará y resultará en la pérdida de la garantía 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 tiene un TPS teórico de hasta ~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 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 predeterminada, algunas 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 resolver problemas directamente en la capa base. Este enfoque, en esencia, no resuelve el problema, sino que lo transfiere a la capa superior de la pila.
Optimistic Rollup
Actualmente, la mayoría de los rollups optimistas son centralizados (algunos incluso tienen un solo secuenciador), lo que plantea problemas de seguridad insuficiente, 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 se ve limitada por la cantidad de datos que se pueden procesar por transacción. La demanda de cálculo para generar pruebas de conocimiento cero es extremadamente alta, y el mecanismo de "el ganador se lleva todo" puede llevar a la centralización del sistema. Para garantizar el TPS, ZK rollup a menudo limita la cantidad de transacciones por lote, lo que puede causar congestión en la red y un aumento del gas en momentos de alta demanda, afectando la experiencia del usuario.
En comparación, el costo del ZK rollup totalmente compatible con Turing es aproximadamente 2x10^6 veces el del protocolo de seguridad económica central de Polkadot.
Además, el problema de disponibilidad de datos en ZK rollup también agravará sus desventajas. Para garantizar que cualquier persona pueda verificar las transacciones, aún se necesita 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 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, 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 la implementación a gran escala hoy en día, la "escalabilidad sin confianza" que defiende Polkadot podría ser la verdadera solución que respalde el desarrollo a largo plazo de Web3.