- Tema
75k Popularidad
32k Popularidad
9k Popularidad
4k Popularidad
4k Popularidad
29k Popularidad
16k Popularidad
22k Popularidad
13k Popularidad
3k Popularidad
- Anclado
75k Popularidad
32k Popularidad
9k Popularidad
4k Popularidad
4k Popularidad
29k Popularidad
16k Popularidad
22k Popularidad
13k Popularidad
3k Popularidad
El camino innovador de Polkadot: cómo lograr un equilibrio entre escalabilidad, seguridad y Descentralización
La elección de la escalabilidad de la Cadena de bloques: el camino innovador de Polkadot
En la actualidad, donde la tecnología de la cadena de bloques busca constantemente una mayor eficiencia, surge una pregunta clave: ¿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 base en sacrificar la confianza y la seguridad a menudo no puede sostener una innovación verdaderamente sostenible.
Como un importante impulsor de la escalabilidad de Web3, ¿ha hecho Polkadot ciertas concesiones en su búsqueda de alta capacidad de procesamiento y baja latencia? ¿Su modelo de rollup ha hecho compromisos en descentralización, seguridad o interoperabilidad de la red? Este artículo analizará 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 principales, explorando sus diferentes elecciones de trayectoria en 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 de la Cadena de bloques Relay Chain(, ¿es posible que esto introduzca riesgos de centralización en algunos 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 del secuenciador ) que conecta la cadena de bloques intermedia (, cuya comunicación utiliza un mecanismo llamado protocolo collator. Este protocolo es completamente sin permisos y sin confianza; cualquier persona con conexión a la red puede utilizarlo, conectando un pequeño número de nodos de la cadena de bloques intermedia y enviando solicitudes de cambio de estado de rollup. Estas solicitudes serán verificadas por algún core de la cadena de bloques intermedia, siempre que se cumpla una premisa: debe ser un cambio de estado válido, de lo contrario, el estado de ese rollup no será avanzado.
) Compensaciones de 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" ###Elastic Scaling(. Durante el proceso de diseño, se descubrió que, dado que la validación de bloques 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 permisos y sin confianza, cualquiera puede enviar bloques a cualquiera de los núcleos asignados al rollup para su verificación. Un atacante podría aprovechar esto para enviar repetidamente bloques legítimos que ya han sido verificados a diferentes núcleos, consumiendo recursos de manera maliciosa y, por lo tanto, reduciendo el rendimiento y la eficiencia general del rollup.
El objetivo de Polkadot es mantener la flexibilidad 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, adoptar un mecanismo de lista blanca, o confiar por defecto en que los ordenadores no actuarán 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 permiso" del sistema. Cualquiera debería poder utilizar el protocolo de colator para enviar solicitudes de transformación de estado del 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 resuelva completamente el problema ###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 elasticidad y seguridad. Polkadot volverá a ejecutar la transició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 de ELVES.
Antes de que cualquier bloque de rollup se escriba en la capa de disponibilidad de datos de Polkadot )DA(, un grupo de aproximadamente 5 validadores verificará su legitimidad. Ellos reciben el recibo candidato )candidate receipt( y la prueba de validez )PoV(, que contiene el bloque de rollup y la prueba de almacenamiento correspondiente. Esta información será procesada por la función de validación de la cadena paralela, siendo 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 verificar el Bloquear. El validador comparará si el índice coincide con el núcleo que le corresponde; si no coincide, se descartará el Bloquear.
Este mecanismo asegura que el sistema mantenga siempre propiedades de no confianza y no permiso, evitando que actores maliciosos como los ordenadores manipulen la posición de verificación, garantizando 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 está garantizada por la cadena de retransmisión, y solo se necesita un validador honesto para mantener la viabilidad.
Con el protocolo ELVES, Polkadot extiende su seguridad de manera completa a todos los rollups, verificando 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. 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 ciertos requisitos de RFC103 para adaptarse a diferentes escenarios de uso.
La complejidad específica depende de la estrategia de gestión de recursos del rollup, que puede depender de variables en la cadena o fuera de la cadena. Por ejemplo:
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 afecta la capacidad de transmisión de mensajes.
La comunicación de mensajes entre rollups se realiza a través de la capa de transporte subyacente, y el espacio de bloque 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 como superficie de control, en lugar de superficie de datos. Esta actualización mejorará la capacidad de comunicación entre rollups junto con la escalabilidad elástica, fortaleciendo aún más la capacidad de escalabilidad vertical del sistema.
Compromisos de otros protocolos
Como todos saben, la mejora del rendimiento a menudo implica sacrificar 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 la escalabilidad a través de una arquitectura de alto rendimiento en una sola capa, confiando en la prueba histórica ###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 los nodos de validación. Cuanto más se apueste, mayor será la oportunidad de los nodos de crear bloques, y los nodos pequeños prácticamente 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 resistencia a ataques en busca 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, en condiciones ideales de red y hardware. Por otro lado, Polkadot ha alcanzado 128K TPS en una red pública descentralizada.
El mecanismo de consenso de TON presenta riesgos de seguridad: la identidad de los nodos de validación por fragmentos puede ser expuesta con anticipació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 esté completamente bajo su control, o pueden interrumpir a los validadores honestos mediante ataques DDoS, lo que les permite alterar el estado.
En comparación, los validadores de Polkadot son asignados de forma aleatoria y revelados con retraso, los atacantes no pueden conocer la identidad de los validadores por adelantado, el ataque requiere apostar todo el control para tener éxito, y siempre que haya un validador honesto que inicie una disputa, el ataque fallará y resultará en la pérdida de la garantía del atacante.
Avalanche
Avalanche utiliza una arquitectura de red principal + subred para la escalabilidad, la red principal está compuesta por transferencias X-Chain###, ~4,500 TPS(, contratos inteligentes C-Chain), ~100--200 TPS(, y la P-Chain) que gestiona los validadores y subredes(.
Cada subred tiene una TPS teórica 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 la subred, y la subred puede establecer requisitos adicionales 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ía de seguridad por defecto, algunas incluso pueden ser completamente centralizadas. Si se desea aumentar la seguridad, todavía se debe comprometer el rendimiento, y es difícil proporcionar un compromiso de seguridad determinista.
) Ethereum
La estrategia de escalabilidad de Ethereum apuesta por la escalabilidad de la capa de rollup, en lugar de resolver los problemas directamente en la capa base. Esta forma, 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 Optimistic rollups son centralizados ###, algunos incluso tienen solo un secuenciador (, lo que genera problemas como falta de seguridad, aislamiento entre ellos, alta latencia ) y la necesidad de 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 de cálculo para generar pruebas de cero conocimiento es extremadamente alta, y el mecanismo de "el ganador se lo lleva todo" tiende a llevar a la centralización del sistema. Para garantizar el TPS, ZK rollup a menudo limita 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 del 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 de ZK rollup también agravará sus desventajas. Para asegurar que cualquiera pueda verificar las transacciones, aún se requiere proporcionar datos completos de las transacciones. Esto a menudo depende de soluciones adicionales de disponibilidad de datos, lo que incrementa 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.
En comparación con 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 de seguridad, descentralización y alto rendimiento a través de un diseño de protocolos de escalabilidad flexible, 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.