Escalabilidad y compensaciones: Elecciones tecnológicas de Polkadot y el ecosistema Web3
En la actualidad, en la que la tecnología blockchain busca continuamente una mayor eficiencia, un problema clave ha comenzado a surgir: ¿cómo equilibrar la seguridad y la resiliencia del sistema mientras se mejora el rendimiento de la escalabilidad? Este no es solo un desafío a nivel técnico, sino también una profunda elección en el diseño arquitectónico. Para el ecosistema Web3, buscar simplemente sistemas más rápidos a costa de la confianza y la seguridad dificulta el soporte de una innovación verdaderamente sostenible.
Como un importante impulsor de la escalabilidad de Web3, ¿ha hecho Polkadot ciertos sacrificios en su búsqueda de altos niveles de rendimiento y baja latencia? ¿Su modelo de rollup ha comprometido la descentralización, la seguridad o la interoperabilidad de la red? Este artículo abordará estas cuestiones, analizando en profundidad los compromisos y concesiones de Polkadot en el diseño de escalabilidad y comparándolo con las soluciones de otras cadenas de bloques principales, explorando sus diferentes elecciones de caminos 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, lo que podría introducir riesgos de centralización en ciertos aspectos? ¿Es posible que se forme un punto único de fallo o control que afecte sus características de descentralización?
El funcionamiento de Rollup depende del ordenante de la cadena de retransmisión conectada, 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, conectar una pequeña cantidad de nodos de la cadena de retransmisión y enviar solicitudes de transición de estado de Rollup. Estas solicitudes serán verificadas por algún núcleo de la cadena de retransmisión, siempre que se cumpla una premisa: debe ser una transición de estado válida, de lo contrario, el estado de ese Rollup no avanzará.
Compromisos de escalabilidad vertical
Rollup puede lograr la escalabilidad vertical aprovechando la arquitectura multicore de Polkadot. Esta nueva capacidad se introduce con la función de "escalado elástico". Durante el proceso de diseño, se descubrió que, dado que la validación de bloques de rollup no se realiza de manera fija en un solo core, esto podría afectar su elasticidad.
Debido a que el protocolo para enviar bloques a la cadena de retransmisión es sin permiso y sin confianza, cualquier persona puede enviar bloques a cualquiera de los núcleos asignados al rollup para su verificación. Un atacante puede aprovechar esto para enviar repetidamente bloques legítimos que ya han sido verificados a diferentes núcleos, consumiendo recursos de manera maliciosa, lo que reduce 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 confiabilidad del secuenciador
Una solución simple es configurar el protocolo como "con licencia": por ejemplo, adoptar un mecanismo de lista blanca, o confiar por defecto en que los ordenadores no actuarán de manera maliciosa, asegurando así la actividad del rollup.
Sin embargo, en el concepto 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 necesidad de confianza" y "sin permisos" del sistema. Cualquiera debería poder usar el protocolo de colador para enviar solicitudes de cambio de estado de rollup.
Polkadot: Solución sin compromisos
La solución final elegida por Polkadot es: dejar que la función de transición de estado del rollup (Runtime) resuelva completamente el problema. Runtime es la única fuente confiable de toda la información de consenso, por lo que debe declararse explícitamente en la salida en qué núcleo de Polkadot se debe realizar la validación.
Este diseño logra una doble garantía de elasticidad y seguridad. Polkadot volverá a ejecutar la transformación de estado del rollup en el proceso de disponibilidad y asegurará la corrección de la distribución del core a través del protocolo económico criptográfico ELVES.
Antes de que cualquier rollup bloque se escriba en la capa de disponibilidad de datos (DA) de Polkadot, un grupo de alrededor de 5 validadores verificará primero su legitimidad. Reciben los recibos candidatos y las pruebas de validez presentados por el ordenante, que contienen el bloque 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 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 propiedades de no confianza y de 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 resiliencia.
seguridad
En la búsqueda de la escalabilidad, Polkadot no ha comprometido la seguridad. La seguridad de los rollups está garantizada por la cadena de retransmisión, solo se necesita un validador honesto para mantener la viabilidad.
Gracias al protocolo ELVES, Polkadot extiende su seguridad de manera integral a todos los rollups, validando todos los cálculos en el núcleo sin necesidad de imponer restricciones o suposiciones 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 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 una 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 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 compromiso 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 algunos requisitos de la 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 transacción específicas en el mempool del nodo;
Estrategias automatizadas: Configuración de recursos anticipada 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 elástica no afecta la capacidad de procesamiento de mensajes.
La comunicación de mensajes entre rollups es implementada por la capa de transporte subyacente, y el espacio de bloques de comunicación de cada rollup es fijo, independientemente de la cantidad de núcleos asignados.
En el futuro, Polkadot también soportará la mensajería fuera de la cadena, utilizando la cadena de retransmisión como plano de control, en lugar del plano de datos. Esta actualización mejorará la capacidad de comunicación entre rollups junto con la expansión elástica, lo que a su vez fortalecerá la capacidad de escalado vertical del sistema.
Compensaciones de otros protocolos
Como es bien sabido, la mejora del rendimiento a menudo se logra 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 no es satisfactorio.
Cadena pública A
Una cierta cadena pública A 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 de una sola capa, confiando en la prueba histórica, el procesamiento paralelo de CPU y un mecanismo de consenso basado en líderes, con un TPS teórico que puede alcanzar los 65,000.
Un diseño clave es su mecanismo de programación de líderes previamente divulgado y verificable:
Al inicio 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% tendrá aproximadamente un 1% de oportunidad de crear bloques;
Todos los mineros que producen bloques se anuncian con anticipación, lo que aumenta el riesgo de ataques DDoS dirigidos a la red y caídas frecuentes.
La historia demuestra que el procesamiento paralelo tiene unas exigencias de hardware extremadamente altas, lo que lleva a la centralización de los nodos de validación. Cuantos más nodos estén en staking, mayor será la oportunidad de crear bloques; los nodos pequeños casi no tienen slots, lo que agrava aún más la centralización y aumenta el riesgo de que el sistema colapse tras un ataque.
Una cierta cadena pública A, en su búsqueda de TPS, sacrificó la descentralización y la capacidad de resistencia a ataques, su coeficiente de Nakamoto es solo de 20, muy por debajo de los 172 de Polkadot.
Cadena pública B
Una cadena de bloques pública B afirma que su TPS puede alcanzar 104,715, pero este número se logró en una red de pruebas privada, con 256 nodos y 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 una cadena de bloques pública B presenta riesgos de seguridad: la identidad de los nodos de validación de fragmentos se expone con antelación. El libro blanco de la cadena de bloques pública B también señala claramente que, aunque esto puede optimizar el ancho de banda, también puede ser utilizado maliciosamente. Debido a la falta de un mecanismo de "quiebra de apostadores", 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 modificar el estado.
En comparación, los validadores de Polkadot son asignados aleatoriamente y su identidad se revela con retraso, los atacantes no pueden conocer de antemano la identidad de los validadores, el ataque debe apostar todo el control para tener éxito, y tan pronto como un validador honesto inicie una disputa, el ataque fallará y resultará en la pérdida del staking del atacante.
Una cadena pública C
La cadena pública C utiliza una arquitectura de red principal + subred para la expansión, 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 escalabilidad. Sin embargo, una cadena pública C permite a los validadores elegir libremente participar en subredes, y las subredes pueden establecer requisitos adicionales geográficos, de KYC, etc., sacrificando la descentralización y la seguridad.
En Polkadot, todos los rollups comparten una garantía de seguridad unificada; mientras que la subred de cierta cadena pública C no tiene una garantía de seguridad por defecto, y algunas pueden ser completamente centralizadas. Si se desea mejorar la seguridad, aún se debe comprometer el rendimiento, y es difícil proporcionar un compromiso de seguridad determinista.
alguna cadena de bloques D
La estrategia de escalabilidad de la cadena pública D se basa en apostar por la escalabilidad de la capa rollup, en lugar de resolver 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 Optimistic rollups son centralizados (algunos incluso tienen solo un secuenciador), lo que plantea problemas de seguridad insuficiente, aislamiento entre ellos y alta latencia (debido al tiempo de espera para la prueba de fraude, que suele ser de 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 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 aumentar el gas en momentos de alta demanda, afectando la experiencia del usuario.
En comparación, el costo de un ZK rollup Turing-completo es aproximadamente 2x10^6 veces el del protocolo de seguridad económica central de Polkadot.
Además, los problemas de disponibilidad de datos de ZK rollup también agravan sus desventajas. Para garantizar que cualquiera 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 públicas, Polkadot no ha optado por sacrificar la centralización por el rendimiento, ni por la confianza preestablecida por la eficiencia, sino que ha logrado un equilibrio multidimensional entre seguridad, descentralización y alto rendimiento a través de una escalabilidad flexible, un diseño de protocolo 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 defiende Polkadot podría ser la verdadera solución que respalde el desarrollo a largo plazo de Web3.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
13 me gusta
Recompensa
13
6
Compartir
Comentar
0/400
FlashLoanKing
· hace15h
¿Se puede ganar solo con velocidad? Echarle la culpa a los usuarios, ¿verdad?
Ver originalesResponder0
LiquidityWizard
· hace15h
teóricamente hablando, la escalabilidad de dot = 73.8% compromiso de seguridad... no es óptimo, para ser honesto
Ver originalesResponder0
0xOverleveraged
· hace15h
Sigue igual, todo se refiere a rollup.
Ver originalesResponder0
OneBlockAtATime
· hace15h
Dot es la piedra angular, lo demás son ilusiones.
Ver originalesResponder0
WalletDoomsDay
· hace15h
Diviértete rompiendo, déjame primero, ¿qué hay de bueno en la Cadena de bloques que te preocupa?
Ver originalesResponder0
ContractSurrender
· hace15h
Sacrificar la seguridad y eso, mejor capitular pronto.
Polkadot escalabilidad elástica: equilibrio entre escalabilidad y seguridad en el ecosistema Web3
Escalabilidad y compensaciones: Elecciones tecnológicas de Polkadot y el ecosistema Web3
En la actualidad, en la que la tecnología blockchain busca continuamente una mayor eficiencia, un problema clave ha comenzado a surgir: ¿cómo equilibrar la seguridad y la resiliencia del sistema mientras se mejora el rendimiento de la escalabilidad? Este no es solo un desafío a nivel técnico, sino también una profunda elección en el diseño arquitectónico. Para el ecosistema Web3, buscar simplemente sistemas más rápidos a costa de la confianza y la seguridad dificulta el soporte de una innovación verdaderamente sostenible.
Como un importante impulsor de la escalabilidad de Web3, ¿ha hecho Polkadot ciertos sacrificios en su búsqueda de altos niveles de rendimiento y baja latencia? ¿Su modelo de rollup ha comprometido la descentralización, la seguridad o la interoperabilidad de la red? Este artículo abordará estas cuestiones, analizando en profundidad los compromisos y concesiones de Polkadot en el diseño de escalabilidad y comparándolo con las soluciones de otras cadenas de bloques principales, explorando sus diferentes elecciones de caminos 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, lo que podría introducir riesgos de centralización en ciertos aspectos? ¿Es posible que se forme un punto único de fallo o control que afecte sus características de descentralización?
El funcionamiento de Rollup depende del ordenante de la cadena de retransmisión conectada, 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, conectar una pequeña cantidad de nodos de la cadena de retransmisión y enviar solicitudes de transición de estado de Rollup. Estas solicitudes serán verificadas por algún núcleo de la cadena de retransmisión, siempre que se cumpla una premisa: debe ser una transición de estado válida, de lo contrario, el estado de ese Rollup no avanzará.
Compromisos de escalabilidad vertical
Rollup puede lograr la escalabilidad vertical aprovechando la arquitectura multicore de Polkadot. Esta nueva capacidad se introduce con la función de "escalado elástico". Durante el proceso de diseño, se descubrió que, dado que la validación de bloques de rollup no se realiza de manera fija en un solo core, esto podría afectar su elasticidad.
Debido a que el protocolo para enviar bloques a la cadena de retransmisión es sin permiso y sin confianza, cualquier persona puede enviar bloques a cualquiera de los núcleos asignados al rollup para su verificación. Un atacante puede aprovechar esto para enviar repetidamente bloques legítimos que ya han sido verificados a diferentes núcleos, consumiendo recursos de manera maliciosa, lo que reduce 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 confiabilidad del secuenciador
Una solución simple es configurar el protocolo como "con licencia": por ejemplo, adoptar un mecanismo de lista blanca, o confiar por defecto en que los ordenadores no actuarán de manera maliciosa, asegurando así la actividad del rollup.
Sin embargo, en el concepto 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 necesidad de confianza" y "sin permisos" del sistema. Cualquiera debería poder usar el protocolo de colador para enviar solicitudes de cambio de estado de rollup.
Polkadot: Solución sin compromisos
La solución final elegida por Polkadot es: dejar que la función de transición de estado del rollup (Runtime) resuelva completamente el problema. Runtime es la única fuente confiable de toda la información de consenso, por lo que debe declararse explícitamente en la salida en qué núcleo de Polkadot se debe realizar la validación.
Este diseño logra una doble garantía de elasticidad y seguridad. Polkadot volverá a ejecutar la transformación de estado del rollup en el proceso de disponibilidad y asegurará la corrección de la distribución del core a través del protocolo económico criptográfico ELVES.
Antes de que cualquier rollup bloque se escriba en la capa de disponibilidad de datos (DA) de Polkadot, un grupo de alrededor de 5 validadores verificará primero su legitimidad. Reciben los recibos candidatos y las pruebas de validez presentados por el ordenante, que contienen el bloque 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 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 propiedades de no confianza y de 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 resiliencia.
seguridad
En la búsqueda de la escalabilidad, Polkadot no ha comprometido la seguridad. La seguridad de los rollups está garantizada por la cadena de retransmisión, solo se necesita un validador honesto para mantener la viabilidad.
Gracias al protocolo ELVES, Polkadot extiende su seguridad de manera integral a todos los rollups, validando todos los cálculos en el núcleo sin necesidad de imponer restricciones o suposiciones 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 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 una 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 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 compromiso 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 algunos requisitos de la 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 elástica no afecta la capacidad de procesamiento de mensajes.
La comunicación de mensajes entre rollups es implementada por la capa de transporte subyacente, y el espacio de bloques de comunicación de cada rollup es fijo, independientemente de la cantidad de núcleos asignados.
En el futuro, Polkadot también soportará la mensajería fuera de la cadena, utilizando la cadena de retransmisión como plano de control, en lugar del plano de datos. Esta actualización mejorará la capacidad de comunicación entre rollups junto con la expansión elástica, lo que a su vez fortalecerá la capacidad de escalado vertical del sistema.
Compensaciones de otros protocolos
Como es bien sabido, la mejora del rendimiento a menudo se logra 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 no es satisfactorio.
Cadena pública A
Una cierta cadena pública A 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 de una sola capa, confiando en la prueba histórica, el procesamiento paralelo de CPU y un mecanismo de consenso basado en líderes, con un TPS teórico que puede alcanzar los 65,000.
Un diseño clave es su mecanismo de programación de líderes previamente divulgado y verificable:
La historia demuestra que el procesamiento paralelo tiene unas exigencias de hardware extremadamente altas, lo que lleva a la centralización de los nodos de validación. Cuantos más nodos estén en staking, mayor será la oportunidad de crear bloques; los nodos pequeños casi no tienen slots, lo que agrava aún más la centralización y aumenta el riesgo de que el sistema colapse tras un ataque.
Una cierta cadena pública A, en su búsqueda de TPS, sacrificó la descentralización y la capacidad de resistencia a ataques, su coeficiente de Nakamoto es solo de 20, muy por debajo de los 172 de Polkadot.
Cadena pública B
Una cadena de bloques pública B afirma que su TPS puede alcanzar 104,715, pero este número se logró en una red de pruebas privada, con 256 nodos y 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 una cadena de bloques pública B presenta riesgos de seguridad: la identidad de los nodos de validación de fragmentos se expone con antelación. El libro blanco de la cadena de bloques pública B también señala claramente que, aunque esto puede optimizar el ancho de banda, también puede ser utilizado maliciosamente. Debido a la falta de un mecanismo de "quiebra de apostadores", 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 modificar el estado.
En comparación, los validadores de Polkadot son asignados aleatoriamente y su identidad se revela con retraso, los atacantes no pueden conocer de antemano la identidad de los validadores, el ataque debe apostar todo el control para tener éxito, y tan pronto como un validador honesto inicie una disputa, el ataque fallará y resultará en la pérdida del staking del atacante.
Una cadena pública C
La cadena pública C utiliza una arquitectura de red principal + subred para la expansión, 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 escalabilidad. Sin embargo, una cadena pública C permite a los validadores elegir libremente participar en subredes, y las subredes pueden establecer requisitos adicionales geográficos, de KYC, etc., sacrificando la descentralización y la seguridad.
En Polkadot, todos los rollups comparten una garantía de seguridad unificada; mientras que la subred de cierta cadena pública C no tiene una garantía de seguridad por defecto, y algunas pueden ser completamente centralizadas. Si se desea mejorar la seguridad, aún se debe comprometer el rendimiento, y es difícil proporcionar un compromiso de seguridad determinista.
alguna cadena de bloques D
La estrategia de escalabilidad de la cadena pública D se basa en apostar por la escalabilidad de la capa rollup, en lugar de resolver 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 Optimistic rollups son centralizados (algunos incluso tienen solo un secuenciador), lo que plantea problemas de seguridad insuficiente, aislamiento entre ellos y alta latencia (debido al tiempo de espera para la prueba de fraude, que suele ser de 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 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 aumentar el gas en momentos de alta demanda, afectando la experiencia del usuario.
En comparación, el costo de un ZK rollup Turing-completo es aproximadamente 2x10^6 veces el del protocolo de seguridad económica central de Polkadot.
Además, los problemas de disponibilidad de datos de ZK rollup también agravan sus desventajas. Para garantizar que cualquiera 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 públicas, Polkadot no ha optado por sacrificar la centralización por el rendimiento, ni por la confianza preestablecida por la eficiencia, sino que ha logrado un equilibrio multidimensional entre seguridad, descentralización y alto rendimiento a través de una escalabilidad flexible, un diseño de protocolo 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 defiende Polkadot podría ser la verdadera solución que respalde el desarrollo a largo plazo de Web3.