Compromiso entre escalabilidad y seguridad: Diseño de la arquitectura Web3 de Polkadot
En la actualidad, en la que la tecnología blockchain busca constantemente una mayor eficiencia, un problema clave ha ido surgiendo: ¿cómo mejorar el rendimiento sin sacrificar la seguridad y la resiliencia del sistema? Este no es solo un desafío a nivel técnico, sino que también implica consideraciones profundas en el diseño de la arquitectura. Para el ecosistema de Web3, un sistema de alta velocidad que sacrifica la confianza y la seguridad a menudo no puede sostener una innovación verdaderamente sostenible.
Como un importante impulsor de la escalabilidad en Web3, ¿ha hecho Polkadot ciertas concesiones en su búsqueda de alta capacidad de procesamiento y baja latencia? ¿Ha hecho su modelo de rollup sacrificios en descentralización, seguridad o interoperabilidad de la red? Este artículo discutirá estas cuestiones, analizando en profundidad los compromisos y equilibrios de Polkadot en el diseño de escalabilidad, y comparará sus soluciones con las de otras cadenas de bloques importantes, explorando sus diferentes elecciones entre rendimiento, seguridad y 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 una cadena de retransmisión, podría esto 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?
La operación de Rollup depende de un ordenante de la cadena de retransmisión conectado, cuya comunicación utiliza el mecanismo de protocolo collator. Este protocolo es completamente sin permisos y sin confianza; cualquier persona con conexión a la red puede usarlo, conectando un pequeño número de nodos de la cadena de retransmisión y enviando solicitudes de cambio de estado del rollup. Estas solicitudes serán verificadas por algún núcleo de la cadena de retransmisión, siempre que se cumpla una condición: debe ser un cambio de estado válido, de lo contrario, el estado del rollup no avanzará.
Compromisos 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, se descubrió que, dado que la validación de bloques de rollup no se ejecuta 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 intermediación es sin permiso y sin confianza, cualquier persona puede enviar bloques para ser verificados en cualquiera de los núcleos asignados al rollup. Los atacantes pueden aprovechar esto para enviar repetidamente bloques legítimos que ya han sido verificados a diferentes núcleos, consumiendo recursos de manera maliciosa y 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.
Problemas de confianza del secuenciador
Una solución sencilla es configurar 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, asegurando así la actividad del rollup.
Sin embargo, en la filosofía de diseño de Polkadot, no podemos hacer ninguna suposición de confianza sobre el secuenciador, ya que debemos mantener las características de "sin confianza" y "sin permisos" del sistema. Cualquier persona debería poder usar el protocolo de colators para enviar solicitudes de cambio de estado de rollup.
Polkadot: Solución sin compromisos
La solución finalmente elegida por Polkadot es: dejar la cuestión completamente en manos de la función de conversión de estado del rollup (Runtime). Runtime es la única fuente confiable de toda la información de consenso, por lo que debe declararse explícitamente en la salida en qué núcleo de Polkadot se debe realizar la validación.
Este diseño logra una doble garantía de flexibilidad y seguridad. Polkadot volverá a ejecutar la transición de estado del rollup en el proceso de disponibilidad y garantizará la corrección de la asignación del núcleo a través del protocolo económico criptográfico ELVES.
Antes de que se escriban los datos de los rollups en la capa de disponibilidad de datos de Polkadot, un grupo de aproximadamente 5 validadores primero verificará su legitimidad. Reciben los recibos candidatos y las pruebas de validez presentados por el ordenante, que contienen el bloque de rollup y la correspondiente prueba de almacenamiento. Esta información será procesada por la función de verificación de la cadena paralela y será re-ejecutada por los validadores en la cadena de retransmisión.
El resultado de la verificación incluye un selector de núcleo, que se utiliza para especificar en qué núcleo se debe validar el bloque. El validador comparará si este í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 las propiedades de no requerir confianza y de no requerir 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 elasticidad.
seguridad
En el proceso de búsqueda de escalabilidad, Polkadot no ha comprometido la seguridad. La seguridad de los rollups es garantizada por la cadena de retransmisión, y solo se necesita un ordenante honesto para mantener la vitalidad.
Con el 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, los rollups de Polkadot pueden 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 completos de Turing 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 compensación en el diseño de sistemas.
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 cadena o fuera de cadena. Por ejemplo:
Estrategia simple: siempre usa una cantidad fija de core, o ajusta manualmente fuera de la cadena;
Estrategia ligera: monitorear cargas de transacciones específicas en el mempool del nodo;
Estrategias automatizadas: configurar recursos anticipadamente mediante 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 admite la interoperabilidad entre diferentes rollups, y la escalabilidad flexible no afectará el rendimiento de la mensajería.
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, sin relación con el número de núcleos asignados.
En el futuro, Polkadot también admitirá 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, lo que potenciará aún más la capacidad de escalado vertical del sistema.
Compensaciones de otros protocolos
Como todos saben, la mejora del rendimiento a menudo tiene como costo la descentralización y la seguridad. Sin embargo, desde la perspectiva del coeficiente de Nakamoto, incluso si algunos competidores de Polkadot tienen un grado de descentralización más bajo, su rendimiento no es tan satisfactorio.
Solana
Solana no utiliza la arquitectura de fragmentación de Polkadot o Ethereum, sino que implementa escalabilidad con una arquitectura de alto rendimiento de una sola capa, confiando en pruebas históricas, 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úblico y verificable de antemano:
Al comienzo de cada epoch (aproximadamente dos días o 432,000 slots), se asignan slots según la cantidad de staking;
Cuanto más se apueste, más se distribuirá. Por ejemplo, un validador que apueste el 1% obtendrá aproximadamente un 1% de oportunidad de crear bloques;
Todos los mineros se anuncian con antelació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 alto nivel de hardware, lo que lleva a la centralización de los nodos de validación. Cuantos más nodos se apuesten, mayor será la oportunidad de crear bloques, mientras que los nodos pequeños prácticamente 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 busca de TPS, sacrificó la descentralización y la capacidad de resistencia a ataques, su coeficiente de Nakamoto es solo 20, muy por debajo de los 172 de Polkadot.
TON
TON afirma que puede alcanzar hasta 104,715 TPS, pero esta cifra 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 expondrá de antemano. 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 del apostador", 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 su identidad se revela con retraso, lo que impide que los atacantes conozcan la identidad de los validadores de antemano. El ataque requiere apostar todo el control para tener éxito; siempre que haya un validador honesto que inicie una disputa, el ataque fracasará y el atacante perderá su participación.
Avalanche
Avalanche utiliza una arquitectura de red principal + subredes 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 shard para lograr la escalabilidad. Sin embargo, Avalanche permite a los validadores elegir libremente participar en subredes, y estas subredes pueden establecer requisitos adicionales como geográficos y 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, 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 escalabilidad de Ethereum se basa en apostar por la escalabilidad de la capa de rollup, en lugar de resolver los 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.
Rollup Optimista
Actualmente, la mayoría de las Optimistic rollups son centralizadas, lo que conlleva problemas de seguridad insuficiente, aislamiento entre sí y alta latencia (se debe 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 por transacción. La demanda computacional para generar pruebas de conocimiento cero es extremadamente alta, y el mecanismo de "el ganador se lleva todo" tiende a 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 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 criptográfica central de Polkadot.
Además, los problemas de disponibilidad de datos en ZK rollup también agravarán sus desventajas. Para garantizar que cualquiera pueda verificar las transacciones, aún se necesita proporcionar datos de transacción completos. 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 extremo de la escalabilidad no debería ser un compromiso.
En comparación con otras cadenas de bloques públicas, Polkadot no ha optado por el camino de cambiar la centralización por rendimiento, ni por el de cambiar la 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 la implementación a mayor escala en la actualidad, la "escalabilidad de cero confianza" que sostiene Polkadot, quizás sea la verdadera solución que puede apoyar 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.
19 me gusta
Recompensa
19
5
Republicar
Compartir
Comentar
0/400
NFT_Therapy
· 07-16 00:58
¡Otra vez veo a mi viejo fren dot!
Ver originalesResponder0
LayerZeroHero
· 07-14 19:38
Está claro que definitivamente hay un trade-off, y se necesita correr benchmarks para verificarlo...
Ver originalesResponder0
BearMarketBuyer
· 07-14 19:17
dot es realmente bueno.. he sido holder durante tres años
Ver originalesResponder0
WalletAnxietyPatient
· 07-14 19:16
Volvió a invertir demasiado pronto y murió demasiado pronto.
La arquitectura Web3 de Polkadot: el equilibrio perfecto entre escalabilidad y seguridad
Compromiso entre escalabilidad y seguridad: Diseño de la arquitectura Web3 de Polkadot
En la actualidad, en la que la tecnología blockchain busca constantemente una mayor eficiencia, un problema clave ha ido surgiendo: ¿cómo mejorar el rendimiento sin sacrificar la seguridad y la resiliencia del sistema? Este no es solo un desafío a nivel técnico, sino que también implica consideraciones profundas en el diseño de la arquitectura. Para el ecosistema de Web3, un sistema de alta velocidad que sacrifica la confianza y la seguridad a menudo no puede sostener una innovación verdaderamente sostenible.
Como un importante impulsor de la escalabilidad en Web3, ¿ha hecho Polkadot ciertas concesiones en su búsqueda de alta capacidad de procesamiento y baja latencia? ¿Ha hecho su modelo de rollup sacrificios en descentralización, seguridad o interoperabilidad de la red? Este artículo discutirá estas cuestiones, analizando en profundidad los compromisos y equilibrios de Polkadot en el diseño de escalabilidad, y comparará sus soluciones con las de otras cadenas de bloques importantes, explorando sus diferentes elecciones entre rendimiento, seguridad y 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 una cadena de retransmisión, podría esto 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?
La operación de Rollup depende de un ordenante de la cadena de retransmisión conectado, cuya comunicación utiliza el mecanismo de protocolo collator. Este protocolo es completamente sin permisos y sin confianza; cualquier persona con conexión a la red puede usarlo, conectando un pequeño número de nodos de la cadena de retransmisión y enviando solicitudes de cambio de estado del rollup. Estas solicitudes serán verificadas por algún núcleo de la cadena de retransmisión, siempre que se cumpla una condición: debe ser un cambio de estado válido, de lo contrario, el estado del rollup no avanzará.
Compromisos 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, se descubrió que, dado que la validación de bloques de rollup no se ejecuta 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 intermediación es sin permiso y sin confianza, cualquier persona puede enviar bloques para ser verificados en cualquiera de los núcleos asignados al rollup. Los atacantes pueden aprovechar esto para enviar repetidamente bloques legítimos que ya han sido verificados a diferentes núcleos, consumiendo recursos de manera maliciosa y 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.
Problemas de confianza del secuenciador
Una solución sencilla es configurar 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, asegurando así la actividad del rollup.
Sin embargo, en la filosofía de diseño de Polkadot, no podemos hacer ninguna suposición de confianza sobre el secuenciador, ya que debemos mantener las características de "sin confianza" y "sin permisos" del sistema. Cualquier persona debería poder usar el protocolo de colators para enviar solicitudes de cambio de estado de rollup.
Polkadot: Solución sin compromisos
La solución finalmente elegida por Polkadot es: dejar la cuestión completamente en manos de la función de conversión de estado del rollup (Runtime). Runtime es la única fuente confiable de toda la información de consenso, por lo que debe declararse explícitamente en la salida en qué núcleo de Polkadot se debe realizar la validación.
Este diseño logra una doble garantía de flexibilidad y seguridad. Polkadot volverá a ejecutar la transición de estado del rollup en el proceso de disponibilidad y garantizará la corrección de la asignación del núcleo a través del protocolo económico criptográfico ELVES.
Antes de que se escriban los datos de los rollups en la capa de disponibilidad de datos de Polkadot, un grupo de aproximadamente 5 validadores primero verificará su legitimidad. Reciben los recibos candidatos y las pruebas de validez presentados por el ordenante, que contienen el bloque de rollup y la correspondiente prueba de almacenamiento. Esta información será procesada por la función de verificación de la cadena paralela y será re-ejecutada por los validadores en la cadena de retransmisión.
El resultado de la verificación incluye un selector de núcleo, que se utiliza para especificar en qué núcleo se debe validar el bloque. El validador comparará si este í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 las propiedades de no requerir confianza y de no requerir 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 elasticidad.
seguridad
En el proceso de búsqueda de escalabilidad, Polkadot no ha comprometido la seguridad. La seguridad de los rollups es garantizada por la cadena de retransmisión, y solo se necesita un ordenante honesto para mantener la vitalidad.
Con el 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, los rollups de Polkadot pueden 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 completos de Turing 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 compensación en el diseño de sistemas.
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 cadena o fuera de cadena. Por ejemplo:
Aunque la automatización es más eficiente, los costos de implementación y prueba también aumentan significativamente.
interoperabilidad
Polkadot admite la interoperabilidad entre diferentes rollups, y la escalabilidad flexible no afectará el rendimiento de la mensajería.
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, sin relación con el número de núcleos asignados.
En el futuro, Polkadot también admitirá 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, lo que potenciará aún más la capacidad de escalado vertical del sistema.
Compensaciones de otros protocolos
Como todos saben, la mejora del rendimiento a menudo tiene como costo la descentralización y la seguridad. Sin embargo, desde la perspectiva del coeficiente de Nakamoto, incluso si algunos competidores de Polkadot tienen un grado de descentralización más bajo, su rendimiento no es tan satisfactorio.
Solana
Solana no utiliza la arquitectura de fragmentación de Polkadot o Ethereum, sino que implementa escalabilidad con una arquitectura de alto rendimiento de una sola capa, confiando en pruebas históricas, 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úblico y verificable de antemano:
La historia demuestra que el procesamiento paralelo requiere un alto nivel de hardware, lo que lleva a la centralización de los nodos de validación. Cuantos más nodos se apuesten, mayor será la oportunidad de crear bloques, mientras que los nodos pequeños prácticamente 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 busca de TPS, sacrificó la descentralización y la capacidad de resistencia a ataques, su coeficiente de Nakamoto es solo 20, muy por debajo de los 172 de Polkadot.
TON
TON afirma que puede alcanzar hasta 104,715 TPS, pero esta cifra 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 expondrá de antemano. 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 del apostador", 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 su identidad se revela con retraso, lo que impide que los atacantes conozcan la identidad de los validadores de antemano. El ataque requiere apostar todo el control para tener éxito; siempre que haya un validador honesto que inicie una disputa, el ataque fracasará y el atacante perderá su participación.
Avalanche
Avalanche utiliza una arquitectura de red principal + subredes 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 shard para lograr la escalabilidad. Sin embargo, Avalanche permite a los validadores elegir libremente participar en subredes, y estas subredes pueden establecer requisitos adicionales como geográficos y 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, 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 escalabilidad de Ethereum se basa en apostar por la escalabilidad de la capa de rollup, en lugar de resolver los 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.
Rollup Optimista
Actualmente, la mayoría de las Optimistic rollups son centralizadas, lo que conlleva problemas de seguridad insuficiente, aislamiento entre sí y alta latencia (se debe 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 por transacción. La demanda computacional para generar pruebas de conocimiento cero es extremadamente alta, y el mecanismo de "el ganador se lleva todo" tiende a 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 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 criptográfica central de Polkadot.
Además, los problemas de disponibilidad de datos en ZK rollup también agravarán sus desventajas. Para garantizar que cualquiera pueda verificar las transacciones, aún se necesita proporcionar datos de transacción completos. 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 extremo de la escalabilidad no debería ser un compromiso.
En comparación con otras cadenas de bloques públicas, Polkadot no ha optado por el camino de cambiar la centralización por rendimiento, ni por el de cambiar la 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 la implementación a mayor escala en la actualidad, la "escalabilidad de cero confianza" que sostiene Polkadot, quizás sea la verdadera solución que puede apoyar el desarrollo a largo plazo de Web3.