Fragmentación de estado

¿Qué es la fragmentación de estado en cripto?

La fragmentación de estado es un diseño de escalabilidad blockchain que divide el estado activo de la red en partes más pequeñas denominadas shards, para que diferentes grupos de validadores puedan procesar y almacenar distintas partes de la blockchain en paralelo.

En cripto, el estado es el registro actual de cuentas, saldos, datos de contratos inteligentes, posiciones de almacenamiento, información de validadores y otros valores necesarios para procesar nuevas transacciones.

La fragmentación consiste en dividir un sistema grande en secciones más pequeñas para que toda la red no tenga que realizar cada tarea al mismo tiempo.

La documentación oficial de escalabilidad de Ethereum describe la fragmentación como el proceso de dividir una base de datos para que subconjuntos de validadores puedan ser responsables de shards individuales en lugar de realizar un seguimiento de todo.

La fragmentación de estado aplica esta idea directamente al estado de la blockchain.

En lugar de que cada validador almacene y ejecute el estado completo de toda la blockchain, cada shard puede mantener solo una parte del estado.

Esto puede aumentar el rendimiento, ya que varios shards pueden procesar transacciones al mismo tiempo.

También puede reducir las exigencias de hardware, porque quizá cada nodo no necesite almacenar todo el estado activo.

Sin embargo, la fragmentación de estado es compleja porque las aplicaciones blockchain suelen necesitar interactuar entre shards.

En términos sencillos, la fragmentación de estado busca escalar una blockchain distribuyendo su base de datos activa y su carga de ejecución entre numerosos grupos de shards paralelos.

Por qué importa la fragmentación de estado

La fragmentación de estado es importante porque las blockchains de contratos inteligentes pueden volverse costosas de ejecutar a medida que crece su uso.

Cada nueva cuenta, saldo de tokens, contrato, NFT, posición de liquidez, registro de gobernanza y posición de almacenamiento puede aumentar la cantidad de estado activo que la red debe mantener.

Si cada validador debe almacenar y ejecutar el estado completo para siempre, puede resultar más difícil para las personas verificar la red de forma independiente.

Esto puede debilitar la descentralización, ya que solo los grandes operadores podrían llegar a ejecutar nodos completos.

La fragmentación de estado trata de resolver este problema permitiendo que la red escale horizontalmente.

El escalado horizontal consiste en añadir más grupos de validadores y más shards, en lugar de obligar a cada nodo a ser más potente.

La página oficial de documentos de NEAR describe Nightshade como un diseño de fragmentación en el que la blockchain se divide en múltiples cadenas paralelas o shards para escalar horizontalmente según la demanda.

Este enfoque resulta atractivo porque puede aumentar la capacidad sin exigir que cada nodo procese todas las transacciones.

Por tanto, la fragmentación de estado no es solo una mejora de velocidad.

También es una estrategia de descentralización, ya que mantener unos requisitos de nodo asumibles ayuda a que más participantes verifiquen la red.

Cómo funciona la fragmentación de estado

Una blockchain con fragmentación de estado divide el estado global en múltiples shards.

Cada shard es responsable de un subconjunto de cuentas, contratos, objetos o entradas de estado.

Los validadores pueden asignarse a un shard, a varios shards o a comités de shards rotativos, según el diseño del protocolo.

Las transacciones que afectan a un único shard a menudo pueden procesarse dentro de ese shard.

Las transacciones que afectan a varios shards requieren comunicación cross-shard.

Un coordinador, una beacon chain, una cadena principal, una capa global de consenso o un protocolo de comunicación entre shards puede ayudar a mantener la coherencia del sistema.

La red debe garantizar que ningún shard acepte transacciones no válidas.

También debe garantizar que una acción cross-shard no genere doble gasto, mensajes perdidos ni estados incoherentes.

Por eso la fragmentación de estado es más compleja que simplemente ejecutar muchas blockchains independientes.

Una verdadera cadena con fragmentación de estado debe hacer que muchos shards se comporten como un único sistema blockchain coherente.

Fragmentación de estado frente a fragmentación de transacciones

La fragmentación de transacciones divide el procesamiento de transacciones entre grupos diferentes.

La fragmentación de estado divide el estado real de la blockchain entre grupos diferentes.

Un sistema puede fragmentar las transacciones sin fragmentar completamente el estado si todos los validadores siguen necesitando conocer todo el estado.

La fragmentación de estado es más profunda porque cada shard almacena y actualiza únicamente una parte de la base de datos activa.

Esto puede generar mayores beneficios de escalabilidad, pero también mayores retos de coordinación.

Por ejemplo, un pago de una cuenta a otra dentro del mismo shard puede ser sencillo.

Un pago de un shard a otro necesita un sistema seguro de mensajes o recibos cross-shard.

Una llamada a un contrato inteligente que interactúe con contratos de dos shards puede requerir ejecución asíncrona, bloqueos, recibos u otras reglas de coherencia.

La fragmentación de transacciones mejora el rendimiento al dividir el trabajo.

La fragmentación de estado mejora tanto el rendimiento como la escalabilidad del almacenamiento al dividir los datos de los que depende ese trabajo.

Fragmentación de estado frente a fragmentación de datos

La fragmentación de estado es diferente de la fragmentación de datos.

La fragmentación de estado divide el estado activo de ejecución de una blockchain.

La fragmentación de datos se centra en hacer que los datos de transacciones estén disponibles en partes más pequeñas o paralelas para que los sistemas de escalabilidad puedan publicar y verificar datos de forma más económica.

Esta distinción es importante porque la hoja de ruta moderna de escalabilidad de Ethereum se centra en la disponibilidad de datos, en lugar de en la fragmentación de estado tradicional.

La documentación de danksharding de Ethereum afirma que ni danksharding ni proto-danksharding siguen el modelo tradicional de fragmentación que divide la blockchain en múltiples partes.

Esa documentación explica que danksharding está diseñado en torno a grandes blobs de datos para rollups, en lugar de dividir Ethereum Mainnet en shards de ejecución tradicionales.

Esto significa que los usuarios no deben asumir que toda mención a la fragmentación de Ethereum se refiere a fragmentación de estado.

Los debates anteriores sobre la hoja de ruta de Ethereum incluían ideas de fragmentación de ejecución y de estado.

La escalabilidad moderna de Ethereum utiliza rollups, blobs, investigación sobre muestreo de disponibilidad de datos y conceptos de danksharding en lugar de un modelo tradicional de ejecución con numerosos shards.

La fragmentación de estado y la fragmentación de datos son ambas ideas de escalabilidad, pero resuelven cuellos de botella distintos.

Fragmentación de estado frente a rollups

Los rollups escalan una blockchain ejecutando muchas transacciones fuera de la capa base y publicando datos o pruebas de vuelta en ella.

La fragmentación de estado escala una blockchain dividiendo el estado y la ejecución de la capa base entre shards.

Los rollups pueden ser más fáciles de añadir a una cadena existente porque no requieren que la capa base divida su propio estado de ejecución.

La fragmentación de estado supone un cambio arquitectónico más profundo en la capa base.

Los rollups siguen necesitando disponibilidad de datos, liquidación y verificación de pruebas de la cadena base.

Las cadenas con fragmentación de estado necesitan asignación de shards, comunicación cross-shard, seguridad de los shards y finalidad compartida.

La documentación de disponibilidad de datos de Ethereum explica que la disponibilidad de datos importa porque los rollups necesitan que los datos de transacciones estén disponibles para que otros puedan verificar o reconstruir el estado del rollup.

Por eso la hoja de ruta actual de Ethereum respalda la escalabilidad de los rollups con datos de blobs, en vez de la fragmentación de estado tradicional.

La fragmentación de estado puede seguir utilizándose en otros diseños de Layer 1.

La diferencia fundamental es que los rollups separan la ejecución en sistemas Layer 2, mientras que la fragmentación de estado divide la ejecución y el estado dentro de la propia Layer 1.

Por qué es difícil la fragmentación de estado

La fragmentación de estado es difícil porque las blockchains deben seguir siendo seguras, coherentes y descentralizadas mientras dividen el trabajo.

Si un shard cuenta con muy pocos validadores, los atacantes podrían dirigirse a ese shard con mayor facilidad.

Si los validadores no se asignan de manera aleatoria y segura, los atacantes podrían concentrar poder en un shard.

Si los mensajes cross-shard son lentos, las aplicaciones pueden parecer fragmentadas.

Si los mensajes cross-shard no son seguros, los usuarios pueden enfrentarse a riesgos de doble gasto o de estado incoherente.

Si los desarrolladores deben pensar constantemente en la ubicación de los shards, diseñar aplicaciones se vuelve más difícil.

Si los usuarios deben comprender los shards manualmente, la experiencia de usuario empeora.

El estudio académico Building Blocks of Sharding Blockchain Systems identifica componentes clave de la fragmentación, como la selección de nodos, la aleatoriedad, la asignación de nodos, el consenso dentro del shard, el procesamiento de transacciones cross-shard, la reconfiguración de shards y los mecanismos de incentivos.

Esto demuestra que la fragmentación de estado no es una única función.

Es una arquitectura completa de sistema con numerosas partes móviles.

Shards

Un shard es una partición del estado de la blockchain y del entorno de ejecución.

Cada shard puede contener un subconjunto de cuentas, contratos, objetos, almacenamiento o transacciones.

En un diseño sencillo, las cuentas pueden asignarse a shards según rangos de direcciones, valores hash o ubicaciones explícitas de las cuentas.

En un diseño más avanzado, los límites de los shards pueden cambiar con el tiempo mediante resharding.

Un shard debería poder procesar transacciones locales sin pedir aprobación a todos los demás shards.

Este procesamiento en paralelo es el principal beneficio de escalabilidad.

Sin embargo, los shards no pueden estar completamente aislados si los usuarios y las aplicaciones necesitan interactuar en toda la red.

Un buen diseño de fragmentación debe hacer que los shards sean lo bastante independientes para ofrecer rendimiento, pero lo bastante conectados para resultar útiles.

Este equilibrio es difícil porque demasiada independencia fragmenta la red, mientras que demasiada coordinación reduce el beneficio de escalabilidad.

Por tanto, un shard es tanto una unidad de escalabilidad como un reto de coordinación.

Validadores de shards

Los validadores de shards son validadores asignados para comprobar, producir o aprobar actividad en un shard específico.

En algunos diseños, los validadores rotan entre shards para reducir el riesgo de captura prolongada de un shard.

En otros diseños, los validadores pueden seguir solo determinados datos de shards o proporcionar validación sin estado mediante testigos.

La asignación de validadores es crítica, ya que cada shard debe seguir siendo seguro aunque solo un subconjunto de la red pueda validarlo directamente.

Si un atacante puede predecir o influir en la asignación de validadores, podría intentar controlar un shard.

Por ello, la aleatoriedad es importante en muchos sistemas de fragmentación.

Los incentivos de los validadores también importan, ya que los validadores de shards deben recibir recompensas por participar honestamente y ser penalizados por conductas deshonestas.

La fragmentación de estado no elimina la necesidad de consenso.

Crea numerosas responsabilidades de consenso más pequeñas que deben seguir conectadas a la seguridad de toda la red.

La seguridad de una cadena con fragmentación de estado depende en gran medida de cómo se asignan, rotan, supervisan y protegen económicamente los validadores.

Transacciones cross-shard

Una transacción cross-shard es una transacción que afecta al estado de más de un shard.

Las transacciones cross-shard son una de las partes más difíciles de la fragmentación de estado.

Una transferencia sencilla dentro de un shard puede procesarse localmente.

Una transferencia desde una cuenta de un shard a una cuenta de otro shard debe coordinarse entre los shards.

Una llamada a un contrato inteligente que implique múltiples shards puede ser aún más compleja.

El sistema debe garantizar que el shard de origen y el shard de destino coincidan sobre lo ocurrido.

También debe garantizar que los fondos no se gasten dos veces y que los efectos del contrato se produzcan en el orden correcto.

Algunos sistemas utilizan recibos asíncronos, en los que un shard registra una acción saliente y otro aplica posteriormente el resultado entrante.

Otras investigaciones exploran la ejecución cross-shard síncrona, la confirmación en dos fases o la coordinación basada en pruebas.

El diseño de las transacciones cross-shard determina a menudo si la fragmentación de estado resulta fluida o fragmentada para los usuarios.

Ejecución asíncrona

La ejecución asíncrona significa que las acciones entre shards no ocurren de forma instantánea en un único paso global.

En su lugar, un shard puede crear un mensaje o recibo que otro shard procesa posteriormente.

Esto puede mejorar la escalabilidad porque los shards no necesitan detenerse y coordinar cada acción al mismo tiempo.

Sin embargo, la ejecución asíncrona cambia cómo los desarrolladores crean aplicaciones.

Es posible que un contrato no pueda llamar a otro shard y recibir el resultado de inmediato dentro de la misma transacción.

Los desarrolladores pueden necesitar diseñar flujos de trabajo en torno a callbacks, recibos, liquidación diferida o transiciones de estado de varios pasos.

Esto puede dificultar las aplicaciones DeFi, los juegos, los marketplaces y las aplicaciones componibles cross-shard.

La fragmentación asíncrona es potente, pero puede debilitar la componibilidad sencilla que los usuarios esperan de los entornos de contratos inteligentes de un único shard.

La contrapartida es velocidad y paralelismo frente a la simplicidad de aplicaciones síncronas.

Un buen ecosistema con fragmentación de estado necesita herramientas para desarrolladores que faciliten el uso seguro de la ejecución asíncrona.

Componibilidad atómica

La componibilidad atómica significa que varias acciones de contratos inteligentes pueden realizarse juntas como una única transacción indivisible.

Si alguna parte falla, falla toda la transacción.

Los sistemas de contratos inteligentes de un único shard suelen facilitar la componibilidad atómica porque todo el estado relevante está disponible en un entorno de ejecución.

La fragmentación de estado puede dificultar la componibilidad atómica cuando los contratos se encuentran en shards diferentes.

Una operación DeFi puede necesitar interactuar con un protocolo de préstamos, un pool de liquidez, un oráculo y una bóveda en una transacción.

Si esos contratos están en shards diferentes, la ejecución síncrona puede resultar difícil o costosa.

Esta es una de las razones por las que la fragmentación de estado plantea retos de diseño para DeFi.

Algunos sistemas fragmentados pueden animar a que los contratos relacionados residan en el mismo shard.

Otros sistemas pueden ofrecer herramientas especiales de comunicación cross-shard.

La componibilidad atómica es una de las principales contrapartidas que usuarios y desarrolladores deben comprender al estudiar la fragmentación de estado.

Fragmentación de estado y contratos inteligentes

Los contratos inteligentes dificultan la fragmentación de estado porque los contratos pueden depender de un estado compartido.

Un sistema de pagos sencillo puede asignar cuentas a shards y enviar mensajes entre ellos.

Un ecosistema de contratos inteligentes necesita gestionar llamadas a contratos, lecturas y escrituras de almacenamiento, transferencias de tokens, aprobaciones, liquidaciones, swaps y transacciones componibles.

Si todos los contratos pueden llamar a cualquier otro contrato de forma síncrona, la red puede perder gran parte de los beneficios de la fragmentación.

Si las llamadas cross-shard son asíncronas, los desarrolladores necesitan un modelo de programación diferente.

Por ello, las plataformas de contratos inteligentes fragmentadas deben diseñar cuidadosamente la ubicación de cuentas, el despliegue de contratos, el paso de mensajes y las herramientas para desarrolladores.

La fragmentación de estado es más sencilla para transferencias de cuentas simples que para sistemas DeFi altamente componibles.

También resulta más sencilla cuando las aplicaciones pueden agruparse naturalmente en shards.

Por ejemplo, un juego o un entorno similar a una appchain puede mantener la mayor parte de la actividad dentro de un shard.

Las aplicaciones financieras altamente interconectadas pueden necesitar un diseño cross-shard más complejo.

Fragmentación de estado y NEAR

NEAR es uno de los ejemplos más conocidos de blockchain diseñada en torno a la fragmentación.

La documentación oficial de NEAR afirma que la fragmentación Nightshade permite un escalado lineal del rendimiento a medida que aumenta el número de validadores.

Nightshade es el diseño de fragmentación de NEAR.

La página oficial de documentos de NEAR describe Nightshade como un diseño en el que, en su forma actualizada, tanto el estado como el procesamiento se dividen entre shards.

La arquitectura de NEAR es importante porque muestra la fragmentación de estado como una dirección de diseño activa y no solo como un concepto de investigación.

NEAR también ha trabajado en la validación sin estado, que cambia la forma en que los validadores participan en la validación de shards.

La publicación sobre el lanzamiento de NEAR Nightshade 2.0 afirma que Nightshade 2.0 introdujo la validación sin estado en NEAR Mainnet en agosto de 2024.

La validación sin estado puede reducir la cantidad de estado que un validador necesita mantener localmente para un shard.

Esto muestra cómo la fragmentación de estado y la validación sin estado pueden combinarse para mejorar la escalabilidad y la participación de nodos.

Fragmentación de estado y Ethereum

Ethereum es importante para la historia de la fragmentación de estado porque sus primeras hojas de ruta de escalabilidad abordaban extensamente la fragmentación.

Sin embargo, la hoja de ruta actual de Ethereum no se centra en la fragmentación tradicional de ejecución ni de estado para Mainnet.

La página oficial de danksharding de Ethereum afirma que ni proto-danksharding ni danksharding siguen el modelo tradicional de fragmentación.

En su lugar, Ethereum se centra ahora en escalar los rollups proporcionando una disponibilidad de datos más económica mediante blobs y el futuro danksharding.

Esta distinción es importante para el SEO y la formación de usuarios, ya que muchos artículos antiguos siguen describiendo Ethereum como encaminado hacia cadenas de shards tradicionales.

Esas descripciones anteriores pueden resultar engañosas si se presentan como hechos actuales de la hoja de ruta.

La dirección actual de escalabilidad de Ethereum se centra en los rollups.

Esto significa que los sistemas Layer 2 realizan la mayor parte de la ejecución, mientras Ethereum proporciona liquidación, seguridad y mejoras de disponibilidad de datos.

La fragmentación de estado sigue siendo un concepto blockchain importante, pero no debe describirse como el plan actual de ejecución de Ethereum Mainnet.

Para una formación cripto precisa, Ethereum debería utilizarse como ejemplo de cómo evolucionó la investigación sobre fragmentación, y no como un despliegue actual de fragmentación de estado.

Fragmentación de estado y validación sin estado

La validación sin estado significa que un validador puede verificar la ejecución de un bloque o shard sin almacenar localmente todo el estado relevante.

En su lugar, el validador recibe testigos o pruebas que incluyen los datos de estado necesarios para la verificación.

Este concepto puede funcionar con la fragmentación de estado porque los validadores quizá no quieran almacenar el estado de todos los shards.

También puede hacer más flexible la validación de shards, ya que los validadores pueden verificar trabajo con menores requisitos de almacenamiento local.

Nightshade 2.0 de NEAR es un ejemplo práctico de validación sin estado añadida a una arquitectura de fragmentación.

La investigación de Ethereum también ha explorado clientes sin estado y testigos más pequeños mediante cambios en los compromisos de estado.

La validación sin estado no es idéntica a la fragmentación de estado.

La fragmentación de estado divide el estado entre shards.

La validación sin estado reduce cuánto estado debe almacenar un validador para verificar un bloque o shard.

Juntas, pueden ayudar a reducir los requisitos de hardware de los nodos mientras preservan la verificación.

Fragmentación de estado y disponibilidad de datos

La disponibilidad de datos es la garantía de que los datos necesarios para verificar o reconstruir transiciones de estado están disponibles para la red.

La fragmentación de estado no puede ser segura si los validadores no pueden acceder a los datos necesarios para verificar los bloques de shards.

Un productor malicioso de shards podría ocultar datos e impedir que otros comprueben si la transición de estado del shard es válida.

Por eso la disponibilidad de datos es un problema central en los sistemas fragmentados.

Una blockchain fragmentada puede necesitar muestreo de disponibilidad de datos, codificación de borrado, comités, pruebas de fraude, pruebas de validez u otros mecanismos para dificultar los ataques de ocultación de datos.

La documentación de disponibilidad de datos de Ethereum explica que la disponibilidad de datos no es lo mismo que el almacenamiento de datos, porque se centra en si los datos se han publicado lo suficiente para su verificación.

Este concepto se aplica ampliamente a los sistemas de escalabilidad, incluidos los rollups y las cadenas fragmentadas.

La fragmentación de estado aumenta la importancia de la disponibilidad de datos porque cada shard puede producir datos que otras partes de la red necesitan para confiar.

Si los datos de un shard no están disponibles, los mensajes cross-shard y el consenso global pueden volverse inseguros.

Un diseño sólido de fragmentación de estado debe resolver tanto la división de ejecución como la disponibilidad de datos.

Fragmentación de estado y seguridad

La seguridad en la fragmentación de estado depende de la asignación de shards, la honestidad de los validadores, la aleatoriedad, las pruebas cross-shard, la finalidad y los incentivos.

Un único shard no debería resultar fácil de corromper solo porque se le asignen menos validadores.

Esto se denomina a veces el problema de la toma de control de un shard.

Si un atacante puede controlar un shard, podría intentar crear transacciones no válidas, robar fondos o corromper mensajes cross-shard.

Los protocolos reducen este riesgo mediante la asignación aleatoria de validadores, comités rotativos, slashing, seguridad compartida, pruebas de fraude, pruebas de validez o reglas de finalidad global.

La seguridad también debe abordar a atacantes adaptativos que intenten corromper validadores después de conocer su asignación de shard.

La reconfiguración de shards debe diseñarse cuidadosamente porque mover validadores y estado entre shards puede crear ventanas de ataque.

Las transacciones cross-shard necesitan sistemas de prueba que impidan que un shard mienta a otro.

La fragmentación de estado puede escalar una red, pero también aumenta el número de puntos en los que puede fallar el diseño del protocolo.

Para los usuarios, la cuestión clave es si la cadena fragmentada mantiene cada shard tan seguro como necesita serlo toda la red.

Fragmentación de estado y descentralización

La fragmentación de estado puede respaldar la descentralización al reducir la carga de recursos de los nodos individuales.

Si un nodo no necesita almacenar y ejecutar todo el estado global, más participantes podrían poder unirse a la red.

Esto puede ayudar a evitar un futuro en el que solo grandes centros de datos puedan verificar la cadena.

Sin embargo, la fragmentación de estado también puede crear riesgos de descentralización si solo una infraestructura especializada puede gestionar la coordinación cross-shard.

Si los usuarios dependen de un pequeño número de proveedores de RPC para seguir todos los shards, la capa de aplicaciones puede centralizarse.

Si los bridges o routers cross-shard se convierten en cuellos de botella, la actividad económica puede concentrarse en torno a esos servicios.

Si los validadores necesitan una infraestructura compleja para participar, el conjunto de validadores podría seguir centralizándose.

Una buena fragmentación de estado debería reducir la carga de los nodos individuales sin crear nuevas dependencias centralizadas en otros puntos.

La descentralización debería medirse entre validadores, nodos completos, clientes, proveedores de RPC, bridges, wallets e infraestructura de aplicaciones.

La fragmentación de estado solo ayuda si el sistema completo sigue siendo abierto y verificable.

Fragmentación de estado y experiencia de usuario

Idealmente, la fragmentación de estado debería ser invisible para los usuarios.

Un usuario no debería necesitar saber qué shard contiene su cuenta o qué shard contiene un contrato inteligente.

Una cartera debería enrutar las transacciones correctamente sin requerir la selección manual de un shard.

Una dApp debería explicar claramente los retrasos o pasos cross-shard cuando se produzcan.

Si los usuarios deben gestionar manualmente direcciones de shards, saldos de gas por shard y tiempos cross-shard, la adopción puede verse afectada.

Las transferencias cross-shard pueden tardar más que las transferencias dentro del mismo shard, según el diseño del protocolo.

Las interacciones cross-shard con contratos inteligentes también pueden requerir más confirmaciones o callbacks asíncronos.

Las buenas interfaces de usuario pueden ocultar gran parte de esta complejidad.

Sin embargo, los usuarios deben comprender que la fragmentación de estado puede afectar al tiempo de las transacciones, la componibilidad, la liquidez y el diseño de las aplicaciones.

Los mejores sistemas fragmentados se sienten como una sola cadena, aunque funcionen internamente como numerosos entornos de ejecución paralelos.

Fragmentación de estado y desarrolladores

Los desarrolladores que crean aplicaciones en cadenas con fragmentación de estado deben comprender dónde reside el estado de su aplicación.

Si la plataforma expone los límites de los shards, los desarrolladores pueden necesitar elegir dónde se despliegan los contratos.

Si las llamadas cross-shard son asíncronas, los desarrolladores deben diseñar para resultados retrasados y flujos de trabajo parciales.

Si los usuarios pueden proceder de shards diferentes, los desarrolladores deben gestionar el enrutamiento de mensajes y el movimiento de saldos.

Si la liquidez se divide entre shards, las aplicaciones DeFi pueden necesitar enrutamiento o agregación especiales.

Las pruebas también son más complejas porque los desarrolladores deben probar casos dentro del mismo shard y entre shards.

La supervisión puede ser más difícil porque la actividad de la aplicación puede producirse en varios shards.

Las revisiones de seguridad deben incluir la gestión de mensajes cross-shard, protección contra repetición, lógica de callbacks y estados de fallo.

La fragmentación de estado ofrece a los desarrolladores más capacidad, pero también puede requerir una arquitectura más cuidadosa.

Las mejores plataformas para desarrolladores ofrecen abstracciones que hacen que la programación consciente de shards sea más segura y sencilla.

Fragmentación de estado y DeFi

DeFi es especialmente sensible a la fragmentación de estado porque depende de la componibilidad y de la liquidez compartida.

Un swap puede depender de un pool de liquidez.

Una liquidación puede depender de un oráculo, un mercado de préstamos, un saldo de garantía y un registro de deuda.

Una estrategia de rendimiento puede depender de varios contratos que interactúan en una única transacción.

Si esos contratos residen en shards diferentes, la ejecución puede volverse asíncrona o más costosa.

Esto puede reducir la componibilidad atómica.

Los sistemas DeFi con fragmentación de estado pueden necesitar enrutamiento de liquidez, mensajería cross-shard, pools de liquidez específicos por shard o agrupación de aplicaciones.

Algunas aplicaciones pueden optar por mantener todos los contratos principales en un shard para simplificar.

Otras pueden diseñar flujos de trabajo cross-shard nativos para llegar a más usuarios y liquidez.

La fragmentación de estado puede ampliar el rendimiento total, pero los desarrolladores DeFi deben gestionar cuidadosamente el riesgo de fragmentación.

Para los usuarios, la principal preocupación es si DeFi cross-shard sigue siendo seguro, líquido y predecible.

Fragmentación de estado y NFT

Los NFT pueden beneficiarse de la fragmentación de estado porque los grandes ecosistemas de NFT pueden generar muchos registros de propiedad, enlaces de metadatos, listados en marketplaces y objetos de juego.

La fragmentación puede distribuir este estado entre múltiples shards.

Esto puede reducir la congestión cuando muchos usuarios interactúan al mismo tiempo con diferentes colecciones o juegos.

Sin embargo, los NFT también crean retos cross-shard.

Un NFT en un shard puede necesitar venderse a un comprador de otro shard.

Un objeto de juego puede necesitar interactuar con contratos o marketplaces de distintos shards.

Una cartera puede necesitar mostrar saldos de NFT de muchos shards.

Los marketplaces pueden necesitar sistemas de indexación y enrutamiento que comprendan la ubicación de los shards.

La fragmentación de estado puede facilitar la escalabilidad de NFT, pero también puede hacer más complejos el descubrimiento, la liquidez y las transferencias.

Una buena infraestructura de carteras y marketplaces es esencial para una experiencia fluida de NFT fragmentados.

Fragmentación de estado y bridges

La fragmentación de estado y los bridges están relacionados porque la comunicación cross-shard se parece en algunos aspectos a la comunicación cross-chain.

Un mensaje debe pasar de un entorno de estado a otro.

El entorno receptor debe saber que el mensaje es válido.

El entorno emisor debe impedir el doble uso o la repetición.

La diferencia es que los shards normalmente forman parte de un protocolo compartido, mientras que cadenas independientes pueden tener supuestos de seguridad propios.

Por tanto, la mensajería cross-shard puede ser más segura que el bridging convencional si está integrada en el protocolo base y protegida por consenso compartido.

Sin embargo, los sistemas cross-shard mal diseñados pueden seguir creando riesgos similares a los de los bridges.

Los usuarios deberían prestar atención a si las transferencias cross-shard son acciones nativas del protocolo o acciones de bridges a nivel de aplicación.

La mensajería cross-shard nativa suele tener una integración más sólida con las reglas de consenso de la cadena.

Los bridges a nivel de aplicación pueden añadir riesgos adicionales de contratos inteligentes, validadores, relayers o liquidez.

Fragmentación de estado y resharding

El resharding es el proceso de cambiar la estructura de los shards a lo largo del tiempo.

Una cadena puede necesitar resharding cuando aumenta el uso, cuando algunos shards acumulan demasiada actividad o cuando la distribución del estado se vuelve desigual.

Los shards estáticos pueden volverse ineficientes si uno recibe la mayor parte de la actividad mientras otros permanecen infrautilizados.

El resharding dinámico trata de ajustar los límites o el número de shards según la demanda.

Esto puede mejorar el uso de recursos, pero añade complejidad.

Mover estado entre shards debe ser seguro y coherente.

Las aplicaciones deben seguir funcionando mientras cambian las asignaciones de shards.

Los validadores e indexadores deben seguir correctamente la nueva estructura.

Las carteras y dApps no deberían dejar de funcionar cuando se produce resharding.

El resharding demuestra que la fragmentación de estado no consiste solo en dividir el estado una vez, sino también en gestionarlo durante toda la vida de la red.

Ventajas de la fragmentación de estado

La primera ventaja de la fragmentación de estado es un mayor rendimiento.

Varios shards pueden procesar transacciones en paralelo, en lugar de obligar a que toda la actividad pase por un único canal de ejecución.

La segunda ventaja es una mejor escalabilidad del almacenamiento.

Es posible que los nodos no necesiten almacenar cada parte del estado global.

La tercera ventaja es un mejor escalado horizontal.

La red puede añadir capacidad incorporando shards o recursos de validadores, en lugar de aumentar únicamente los requisitos de hardware de los nodos.

La cuarta ventaja es una menor congestión para aplicaciones que pueden operar mayoritariamente dentro de un shard.

La quinta ventaja es una vía hacia una participación más amplia si los requisitos para validadores y nodos siguen siendo asumibles.

La sexta ventaja es una mayor especialización, ya que diferentes shards pueden atender distintos grupos de aplicaciones o cargas de trabajo según el diseño.

Estas ventajas son la razón por la que la fragmentación de estado sigue siendo un concepto de escalabilidad importante.

Las ventajas son mayores cuando la comunicación cross-shard es segura, rápida y sencilla para usuarios y desarrolladores.

Riesgos y limitaciones de la fragmentación de estado

El primer riesgo es la complejidad cross-shard.

Las aplicaciones que necesitan estado de varios shards pueden ser más difíciles de crear y utilizar.

El segundo riesgo es la fragmentación de la seguridad.

Cada shard debe protegerse de ataques aunque solo una parte del conjunto de validadores pueda validarlo directamente.

El tercer riesgo es la fragmentación de la liquidez.

Los activos y mercados pueden dividirse entre shards, haciendo que los precios y la ejecución sean menos eficientes.

El cuarto riesgo es una componibilidad atómica más débil.

Las transacciones que eran sencillas en un estado compartido pueden necesitar un diseño asíncrono entre shards.

El quinto riesgo es la confusión de los usuarios.

Los usuarios pueden no comprender los retrasos cross-shard, el enrutamiento o los mensajes fallidos.

El sexto riesgo es la complejidad de la infraestructura.

Los proveedores de RPC, indexadores, carteras, exploradores y bridges deben seguir correctamente numerosos shards.

El séptimo riesgo es la carga desigual.

Algunos shards pueden congestionarse mientras otros tienen capacidad disponible.

La fragmentación de estado es potente, pero no es una solución de escalabilidad gratuita.

Malentendidos habituales sobre la fragmentación de estado

Un malentendido habitual es que la fragmentación de estado simplemente significa transacciones más rápidas.

En realidad, la fragmentación de estado es una arquitectura compleja que divide las responsabilidades de estado, ejecución, validación y comunicación.

Otro malentendido es que la fragmentación de estado es lo mismo que los rollups.

Los rollups trasladan la ejecución a sistemas Layer 2, mientras que la fragmentación de estado divide el propio estado y ejecución de la capa base.

Un tercer malentendido es que la hoja de ruta actual de Ethereum es la fragmentación de estado tradicional.

La hoja de ruta actual de Ethereum se centra en rollups, blobs y disponibilidad de datos al estilo danksharding, en vez de cadenas de shards de estado de ejecución tradicionales.

Un cuarto malentendido es que la fragmentación de estado preserva automáticamente la componibilidad.

La componibilidad cross-shard es una de las partes más difíciles del diseño.

Un quinto malentendido es que una cadena fragmentada son simplemente muchas cadenas independientes.

Una blockchain realmente fragmentada necesita seguridad compartida, finalidad compartida y comunicación nativa entre shards.

Cómo evaluar una blockchain con fragmentación de estado

Empieza comprobando si la cadena realmente fragmenta el estado o si solo fragmenta los datos o las transacciones.

Después, comprueba cómo se asignan los validadores a los shards.

Revisa si la asignación de validadores utiliza una aleatoriedad sólida.

Comprueba cómo se procesan las transacciones cross-shard.

Revisa si la ejecución cross-shard es síncrona o asíncrona.

Comprueba si las aplicaciones pueden mantener la componibilidad atómica entre shards.

Revisa cómo gestiona el protocolo la disponibilidad de datos de los bloques de shards.

Comprueba si la red admite resharding dinámico o shards fijos.

Revisa la experiencia de usuario de las transferencias cross-shard.

Estudia si las carteras, exploradores, proveedores de RPC e indexadores admiten todos los shards de forma fiable.

Una blockchain con fragmentación de estado debe evaluarse por su seguridad, facilidad de uso, experiencia para desarrolladores y rendimiento real en condiciones cross-shard.

Buenas prácticas para usuarios

Comprende si la red que utilizas cuenta con direcciones específicas por shard, saldos de gas o retrasos de transferencia.

Utiliza, cuando sea posible, carteras que gestionen automáticamente el enrutamiento entre shards.

Empieza con pequeñas transferencias de prueba antes de mover un valor significativo entre shards.

Comprueba si una aplicación opera dentro de un shard o entre varios shards.

Actúa con cautela al utilizar bridges o routers que no sean nativos del protocolo fragmentado.

Ten en cuenta posibles retrasos adicionales cuando los fondos se mueven entre shards.

No des por hecho que una transacción es definitiva en todos los shards hasta que el protocolo o la cartera lo confirme.

Consulta la documentación de la aplicación al utilizar DeFi cross-shard o mercados de NFT.

Mantén suficientes tokens nativos para pagar comisiones si la red exige pagos de comisiones específicos por shard.

Considera la fragmentación de estado como una infraestructura que puede mejorar el rendimiento, pero que no elimina el riesgo de contratos inteligentes ni el riesgo de mercado.

Buenas prácticas para desarrolladores

Diseña aplicaciones teniendo en cuenta la ubicación de los shards y el comportamiento cross-shard.

Evita llamadas cross-shard innecesarias cuando sea posible un diseño dentro del mismo shard.

Utiliza patrones asíncronos de forma segura cuando el protocolo requiera ejecución cross-shard asíncrona.

Protege los mensajes cross-shard frente a repetición, errores de ordenación y lógica de callbacks fallida.

Prueba por separado los flujos de transacciones dentro del mismo shard y entre shards.

Supervisa la fragmentación de la liquidez si la aplicación depende de mercados de tokens.

Explica claramente los retrasos cross-shard en las interfaces de usuario.

Utiliza los SDK y la documentación oficial del protocolo para el paso de mensajes y el enrutamiento de shards.

Planifica el resharding si la red admite cambios dinámicos de shards.

Considera la ejecución cross-shard como una parte del diseño de aplicaciones sensible para la seguridad.

Preguntas frecuentes

¿Qué significa fragmentación de estado?

La fragmentación de estado consiste en dividir el estado activo de una blockchain en múltiples shards para que diferentes grupos de validadores puedan procesar y almacenar distintas partes en paralelo.

¿Qué es un shard?

Un shard es una partición del estado y de la carga de trabajo de ejecución de una blockchain.

¿Por qué las blockchains utilizan fragmentación de estado?

Las blockchains utilizan la fragmentación de estado para aumentar el rendimiento, reducir la carga de almacenamiento por nodo y escalar la ejecución entre grupos de shards paralelos.

¿La fragmentación de estado es lo mismo que la fragmentación de datos?

No. La fragmentación de estado divide el estado activo de ejecución, mientras que la fragmentación de datos se centra en hacer que los datos de transacciones estén disponibles en partes escalables.

¿La fragmentación de estado es lo mismo que los rollups?

No. Los rollups ejecutan transacciones fuera de la capa base, mientras que la fragmentación de estado divide el propio estado y la ejecución de la capa base.

¿Ethereum utiliza actualmente la fragmentación de estado?

No. La hoja de ruta actual de Ethereum se centra en rollups, blobs y disponibilidad de datos al estilo danksharding, en lugar de la fragmentación de ejecución o de estado tradicional.

¿Qué blockchain es conocida por la fragmentación de estado?

NEAR es ampliamente conocida por su diseño de fragmentación Nightshade, que divide el estado y el procesamiento entre shards.

¿Qué son las transacciones cross-shard?

Las transacciones cross-shard son transacciones que afectan al estado de más de un shard y requieren comunicación entre shards.

¿Por qué la fragmentación de estado es difícil para DeFi?

La fragmentación de estado es difícil para DeFi porque DeFi a menudo depende de la componibilidad atómica, la liquidez compartida y las interacciones entre múltiples contratos en un estado unificado.

¿La fragmentación de estado hace que una blockchain no tenga riesgos?

No. La fragmentación de estado puede mejorar la escalabilidad, pero sigue presentando riesgos como errores cross-shard, fragmentación de la seguridad, fragmentación de la liquidez y complejidad de infraestructura.

Conclusión

La fragmentación de estado es un método de escalabilidad blockchain que divide el estado activo y la ejecución entre múltiples shards.

Su objetivo principal es aumentar el rendimiento y reducir la carga sobre validadores o nodos individuales.

Se diferencia de la fragmentación de datos porque divide el estado de ejecución real, en lugar de limitarse a mejorar la disponibilidad de datos.

También se diferencia de los rollups porque modifica la arquitectura de la capa base, en vez de trasladar la ejecución a un entorno Layer 2 independiente.

La fragmentación de estado puede hacer que una blockchain sea más escalable, pero también introduce problemas complejos relacionados con transacciones cross-shard, asignación de validadores, disponibilidad de datos, componibilidad atómica, fragmentación de la liquidez y experiencia de usuario.

El diseño Nightshade de NEAR es un ejemplo activo importante de cómo la investigación sobre fragmentación se convierte en infraestructura de producción.

Ethereum es importante históricamente, pero su hoja de ruta actual utiliza escalabilidad centrada en rollups y disponibilidad de datos al estilo danksharding, en vez de la fragmentación de estado tradicional.

Para los usuarios, la fragmentación de estado puede traducirse en actividad blockchain más rápida y económica cuando el soporte de carteras y aplicaciones es sólido.

Para los desarrolladores, la fragmentación de estado implica que la arquitectura de aplicaciones debe tener en cuenta la ubicación de los shards, los mensajes cross-shard, la ejecución asíncrona y los casos límite de seguridad.

Para las redes, la fragmentación de estado es una forma de buscar el escalado horizontal mientras se intenta preservar la descentralización.

En el contexto de un glosario cripto, State Sharding significa dividir el estado activo de una blockchain en shards paralelos para que la red pueda procesar y almacenar más actividad sin exigir que cada validador gestione todo.

La idea clave es que la fragmentación de estado puede mejorar considerablemente la escalabilidad, pero solo si el protocolo resuelve la comunicación cross-shard, la seguridad compartida, la disponibilidad de datos y la facilidad de uso para desarrolladores sin debilitar el modelo de confianza de la blockchain.