Validación sin estado de NEAR: Sharding de fase 2

La validación sin estado de NEAR es la actualización de Fase 2 del framework de fragmentación Nightshade del NEAR Protocol, en la que los validadores de fragmentos ya no mantienen una copia local persistente del estado del fragmento. En su lugar, el productor de fragmentos empaqueta todos los datos de estado requeridos en un testigo de estado, una estructura de datos criptográfica que contiene cada saldo de cuenta, entrada de almacenamiento de contrato y clave de acceso necesarios para ejecutar un fragmento específico, y lo entrega junto con el fragmento a los validadores. Este diseño desacopla los requisitos de hardware de los validadores del tamaño del estado de la red, permitiendo a NEAR escalar horizontalmente añadiendo más fragmentos sin forzar aumentos proporcionales en los costes de almacenamiento sobre su conjunto de validadores.

Este artículo cubre qué es NEAR Protocol, cómo funciona el sharding de Nightshade, la mecánica precisa de la validación sin estado, incluyendo el ciclo de vida del testigo de estado y la jerarquía de roles de los validadores, los beneficios para la descentralización y la escalabilidad, una comparación directa con la hoja de ruta sin estado de Ethereum, y las implicaciones para validadores, quienes hacen staking, desarrolladores y cualquiera que evalúe NEAR para el despliegue de dApps.

¿Qué es NEAR Protocol?

NEAR Protocol es una blockchain de capa 1, de prueba de participación, que utiliza sharding Nightshade (el marco de sharding propietario de NEAR) para dividir el procesamiento de transacciones entre múltiples fragmentos paralelos, permitiendo un alto rendimiento con tarifas de transacción casi nulas. NEAR está diseñado para desplegar aplicaciones descentralizadas a escala, con herramientas para desarrolladores y una arquitectura de consenso construida bajo la suposición de que el número de fragmentos crecerá con el tiempo.

Arquitectura Central de NEAR

NEAR funciona como una red de prueba de participación (proof-of-stake) en la que los validadores realizan staking de tokens NEAR para participar en el consenso y son asignados aleatoriamente a fragmentos (shards) en cada época (epoch), un periodo de tiempo fijo equivalente aproximadamente a medio día. NEAR Protocol fue cofundado por Illia Polosukhin, coautor del histórico artículo de aprendizaje automático "Attention Is All You Need", y Alexander Skidanov; la Fundación NEAR supervisa el desarrollo continuo del protocolo y las subvenciones al ecosistema.

El Token NEAR cumple dos funciones principales: el pago de las comisiones de gas por las transacciones y la ejecución de contratos, y el staking como garantía para que los validadores obtengan el derecho a participar en el consenso. Los contratos inteligentes de NEAR se compilan en WebAssembly (WASM), un formato binario portátil que permite que los contratos escritos en Rust o JavaScript se ejecuten dentro de un entorno de ejecución determinista. El procesamiento de transacciones en NEAR sigue un modelo basado en chunks, donde cada shard produce un chunk (un bloque a nivel de shard procesado en paralelo) en cada intervalo de bloque, y todos los chunks se agregan en un único bloque canónico.

¿Qué hace que NEAR sea diferente de otras blockchains de Capa 1?

NEAR se distingue de otras blockchains de capa 1 principalmente por su modelo de sharding de ejecución, el cual divide tanto el estado como el procesamiento de transacciones entre diferentes shards en lugar de manejar toda la ejecución en una única cadena. Los diferenciadores clave incluyen:

• Sharding de ejecución Nightshade: NEAR fragmenta tanto el estado como la computación, no solo la disponibilidad de datos. Esto difiere del enfoque Danksharding de Ethereum (EIP-4844), que se dirige al sharding de disponibilidad de datos para rollups Layer 2 en lugar del sharding de ejecución.
• Validación sin estado (Fase 2): Los validadores de fragmentos operan sin almacenamiento de estado local, una elección de diseño con implicaciones directas para la descentralización y la escalabilidad de los fragmentos, cubierto en profundidad en este artículo.
• Entorno de ejecución de contratos inteligentes WASM: Los contratos se ejecutan en un sandbox WASM, soportando Rust y JavaScript como lenguajes de desarrollo principales.
• Nombres de cuenta legibles: Las cuentas NEAR utilizan identificadores con nombre en lugar de hashes de clave pública brutos.
• Modelo de staking de almacenamiento: Los contratos pagan por el almacenamiento On-Chain haciendo staking de tokens NEAR, vinculando los costes de almacenamiento a la garantía depositada en staking en lugar de a tarifas por byte.
• Tarifas de transacción cercanas a cero: La estructura de tarifas de NEAR está diseñada para seguir siendo accesible incluso bajo carga moderada de red.

Solana escala a través de paralelismo de cadena única utilizando su entorno de ejecución Sealevel; NEAR escala mediante sharding entre shards paralelos independientes. Estas son diferentes respuestas arquitectónicas al mismo problema de capacidad de procesamiento. La comparación con Ethereum recibe un tratamiento dedicado más adelante en este artículo.

¿Qué es la validación sin estado?

La validación sin estado (stateless validation) es un modelo de validación de Blockchain en el que los validadores procesan transacciones sin mantener una copia local persistente del estado de la red, recibiendo todos los datos de estado necesarios como parte de cada bloque o fragmento que validan. La palabra «stateless» se refiere a la relación del validador con el almacenamiento de estado, no al estado de la propia Blockchain, que sigue existiendo y creciendo. Desde la perspectiva del validador, cada tarea de validación llega ya empaquetada con todo lo necesario para completarla.

Validación con estado (stateful) frente a validación sin estado (stateless): la diferencia clave

La diferencia entre la validación con estado y la validación sin estado radica en dónde residen los datos de estado durante la ejecución: en el validador o en la tarea.

En la validación con estado, el validador es el custodio del estado: posee una copia de los datos del shard relevante y los consulta durante cada transacción. En la validación sin estado, los datos del estado viajan con el trabajo. El validador recibe exactamente lo que necesita, lo utiliza y lo descarta.

Por qué NEAR necesitaba la validación sin estado

Bajo la arquitectura original basada en estado de NEAR, cada validador de fragmentos asignado a un shard tenía que mantener una copia local completa del estado de ese shard, y a medida que crecía el número de shards de NEAR, también lo hicieron los requisitos de hardware de almacenamiento para cada validador en la red. Cada nuevo shard añadía obligaciones de almacenamiento proporcionales para los validadores asignados a él. Esto creó un acoplamiento directo entre las ambiciones de escalabilidad de NEAR y la barrera del coste de hardware para la participación de los validadores. A medida que la red añadía shards para aumentar el rendimiento, simultáneamente aumentaba el coste de convertirse en un validador, concentrando la participación entre operadores con una gran infraestructura de almacenamiento.

La validación sin estado rompe este acoplamiento. Un validador de fragmentos ya no almacena ningún estado de fragmento. Recibe exactamente los datos de estado necesarios para cada fragmento que valida, ejecuta transacciones contra esos datos y los descarta. Añadir más fragmentos aumenta el rendimiento de la red sin aumentar los requisitos de almacenamiento por validador. Esto aborda una de las tensiones principales en el trilema de escalabilidad de Blockchain: NEAR puede añadir fragmentos para escalar el rendimiento sin forzar la centralización del hardware, mientras que la integridad criptográfica del testigo de estado preserva la seguridad.

Entendiendo el Sharding: Los cimientos de la escalabilidad de NEAR

La validación sin estado de NEAR funciona dentro de la arquitectura de sharding Nightshade, que divide el estado global de la red y el procesamiento de las transacciones en múltiples fragmentos (shards) paralelos. Comprender esta arquitectura es un requisito previo para la explicación del mecanismo que se presenta a continuación, ya que la validación sin estado es una mejora específica de la forma en que los validadores participan en la estructura de Nightshade.

Cómo funciona el sharding Nightshade en NEAR

Nightshade es el framework de sharding de NEAR Protocol, en el cual el estado global de la Blockchain se divide en múltiples shards, cada uno produciendo un chunk (un bloque a nivel de shard) en cada intervalo de bloque. Múltiples chunks se producen en paralelo a través de todos los shards activos y se agregan en un único bloque canónico por el productor de bloques para ese intervalo.

El principio de diseño principal de Nightshade es que todos los shards se tratan como componentes de una única Blockchain lógica, no como cadenas separadas. Cada bloque de NEAR contiene un fragmento (chunk) por cada shard activo. Esto significa que el libro mayor global permanece unificado incluso cuando el procesamiento de las transacciones está distribuido. Las transacciones entre shards (cross-shard) se gestionan a través de un mecanismo de recibos asíncronos que transmite mensajes entre los shards.

Los validadores se asignan aleatoriamente a los shards en cada época, lo que limita el riesgo de que el conjunto de validadores de cualquier shard individual pueda ser atacado o capturado de forma selectiva. Un validador no posee de forma permanente una asignación de shard; esta rota con cada época, distribuyendo tanto la responsabilidad como el riesgo por toda la red.

La implementación completa de Nightshade se desarrolla en tres fases. La Fase 1 estableció el sharding básico con procesamiento de fragmentos (chunks), donde los validadores mantenían copias completas del estado local. La Fase 2 es la validación sin estado (stateless validation), el tema de este artículo. La Fase 3 es el re-sharding dinámico, que otorga a NEAR la capacidad de ajustar automáticamente su número de shards en función de la demanda de la red en tiempo real. Para obtener documentación técnica completa sobre el modelo de sharding de NEAR, consulta docs.near.org/concepts/advanced/sharding.

Cómo funciona la validación sin estado de NEAR

La validación sin estado de NEAR funciona porque los datos de estado necesarios para validar un fragmento viajan con el propio fragmento, empaquetados por el productor del fragmento como un testigo de estado. Los validadores de fragmentos reciben el fragmento y su testigo de estado juntos, ejecutan todas las transacciones utilizando únicamente los datos del testigo y nunca consultan una base de datos de estado local. El resultado es que la clase más numerosa de validadores en la red de NEAR puede operar con requisitos de almacenamiento de estado casi nulos.

¿Qué es un Testigo de Estado?

Un state witness es una estructura de datos criptográfica generada por el productor de chunks que contiene cada pieza de datos de estado necesaria para ejecutar las transacciones de un chunk específico, incluidos los saldos de las cuentas afectadas, las entradas de almacenamiento de contratos, las claves de acceso y el código de los contratos.

Imagine un 'state witness' (testigo de estado) como un expediente preparado por un secretario judicial antes de una vista: contiene cada documento que el juez necesita para dictar sentencia, recopilado de antemano para que el juez no tenga que realizar búsquedas en los archivos del tribunal durante el proceso. En la arquitectura de NEAR, el 'state witness' es ese expediente. El validador de fragmentos (chunk validator) lo recibe junto con el fragmento y ejecuta todas las transacciones utilizando únicamente su contenido, sin consultar nunca un almacenamiento de estado local.

El ciclo de vida del testigo de estado (state witness) abarca cinco etapas distintas:

1. Contenido: El testigo de estado incluye los saldos de cuentas, las entradas de almacenamiento de contratos, las claves de acceso y el código de contrato para cada cuenta afectada por las transacciones en el fragmento. Solo se incluye el estado que se lee o escribe realmente durante la ejecución; el estado completo del fragmento no se empaqueta.

2. Generación: El productor de trozos, el rol de validador responsable de construir el trozo, lee las entradas de estado relevantes de su copia local del estado del shard y las empaqueta en el testigo de estado. El productor de trozos conserva su estado local porque debe poder generar testigos para trozos futuros.

3. Transmisión: El productor de fragmentos transmite conjuntamente el fragmento y su testigo de estado a los validadores de fragmentos asignados aleatoriamente a ese shard para el intervalo de bloques actual.

4. Ejecución: cada validador de fragmentos ejecuta las transacciones del fragmento utilizando exclusivamente los datos del testigo de estado. No se produce ninguna consulta al estado local en ningún momento. Tras la ejecución, el validador del fragmento genera una atestación que confirma que el fragmento es válido.

5. Descartar: una vez completada la validación, el validador de fragmentos (chunk validator) descarta el testigo de estado (state witness). El testigo no se conserva, no se almacena y no se utiliza para actualizar ninguna base de datos de estado local.

La estructura de testigo de estado se especifica formalmente como una Propuesta de Mejora de NEAR (NEP). Para la especificación precisa y el número de NEP actual, consulte el repositorio de NEPs de NEAR en GitHub. Para detalles de implementación en el cliente del protocolo principal, consulte el repositorio de nearcore en GitHub.

El papel de los validadores de fragmentos frente a los productores de bloques

La arquitectura de validadores de NEAR bajo la validación sin estado implica tres roles distintos: productores de chunks, validadores de chunks y productores de bloques, cada uno con responsabilidades y requisitos de almacenamiento de estado diferentes.

La idea estructural clave es que los validadores de fragmentos (chunks) son la clase más numerosa de la red y, bajo la validación sin estado (stateless validation), ya no necesitan un hardware de almacenamiento costoso. Solo los productores de fragmentos, un conjunto mucho más reducido, mantienen el requisito de almacenamiento del estado porque deben leer el estado local para generar el testigo (witness) de cada fragmento. Esta asimetría es lo que permite que el conjunto de validadores crezca sin aumentar proporcionalmente los costes totales de almacenamiento en toda la red. Las ganancias en descentralización se concentran precisamente en la clase de validadores más numerosa.

El flujo de validación bajo la validación sin estado

Los siguientes pasos describen lo que sucede desde el momento en que comienza un nuevo intervalo de bloque hasta el momento en que se finaliza un bloque validado en NEAR.

1. Producción de fragmentos: El productor de fragmentos asignado a cada shard activo construye un fragmento (un bloque a nivel de shard) que contiene las transacciones pendientes para ser procesadas en este intervalo de bloques.

2. Generación de testigos de estado: El productor de fragmentos lee las entradas de estado pertinentes de su copia local del estado del fragmento y las empaqueta en un testigo de estado, que contiene cada saldo de cuenta, entrada de almacenamiento de contrato y clave de acceso afectados por las transacciones del fragmento.

3. Transmisión a los validadores de fragmentos: El productor de fragmentos transmite el fragmento y su testigo de estado a los validadores de fragmentos asignados aleatoriamente a ese shard para este intervalo de bloque.

4. Ejecución sin estado: Cada validador de fragmento ejecuta las transacciones del fragmento utilizando únicamente los datos del testigo de estado, sin realizar ninguna consulta al estado local en ningún momento. Tras la ejecución, el validador de fragmento certifica la validez del fragmento y descarta el testigo de estado.

5. Ensamblaje de bloques: El productor de bloques de este intervalo recopila los fragmentos certificados de todos los fragmentos (shards) activos, los agrega en un único bloque canónico y lo difunde a la red para su finalización.

En ningún momento de los pasos 3 y 4 requiere un validador de fragmentos almacenamiento de estado local. El testigo de estado proporciona todo el acceso al estado necesario durante la operación de validación.

--- ## Beneficios de la Validación sin estado de NEAR

La validación sin estado aporta tres categorías de mejora a la red de NEAR: reduce los requisitos de hardware para la clase de validadores más numerosa, elimina el techo de escalabilidad que la validación con estado imponía al número de fragmentos y al rendimiento, y mejora las condiciones de infraestructura para los desarrolladores que crean aplicaciones descentralizadas sobre la red.

Menores requisitos de hardware y mayor descentralización

La consecuencia más directa de la validación sin estado (stateless validation) para el conjunto de validadores de NEAR es la eliminación del almacenamiento del estado de la fragmentación (shard state) como requisito de hardware para los validadores de chunks. Con la validación con estado (stateful validation), las demandas de almacenamiento para los validadores de chunks crecían con el tiempo según el tamaño del estado del shard, escalando desde cientos de gigabytes hacia terabytes a medida que la red procesaba más transacciones y acumulaba más estado. Esto creaba una barrera progresiva en los costes de hardware.

La validación sin estado elimina por completo esta carga para los validadores de fragmentos. Los requisitos de almacenamiento para esta función se reducen a casi cero para la infraestructura relacionada con el estado, dejando únicamente los requisitos de cómputo y ancho de banda de red para la ejecución de transacciones y la transmisión de atestaciones dentro de las restricciones de tiempo del bloque.

El efecto de descentralización se deriva directamente de este cambio en el hardware. Los menores costes de almacenamiento reducen el coste operativo total de ejecutar un validador de fragmentos, lo que disminuye la barrera económica efectiva para la participación. Esto permite un conjunto de validadores más grande y geográficamente diverso, que a su vez reduce el riesgo de concentración de validadores. Una red cuyos validadores más numerosos puedan ejecutarse en hardware comercial es estructuralmente más resistente a la centralización que una en la que la elegibilidad del validador requiera una inversión de capital significativa en infraestructura de almacenamiento. Las especificaciones actuales de requisitos de hardware para validadores de fragmentos bajo validación sin estado se mantienen en docs.near.org/validator; consulte esa documentación para conocer las cifras actuales.

Escalabilidad sin sacrificar la seguridad

La validación sin estado desacopla el número de fragmentos de NEAR de los requisitos de hardware de los validadores, lo que elimina el límite de escalabilidad que la validación con estado imponía al rendimiento de la red. Bajo el modelo anterior con estado, duplicar el número de fragmentos habría requerido que cada validador asignado a esos nuevos fragmentos aprovisionara almacenamiento adicional proporcional, haciendo que un gran número de fragmentos fuera restrictivo económicamente. La validación sin estado rompe esta relación: añadir fragmentos aumenta la capacidad de la red sin aumentar las obligaciones de almacenamiento por validador.

El rendimiento de la red en NEAR escala de forma aproximadamente proporcional al número de shards. Una mayor cantidad de shards activos significa que se procesan más chunks en paralelo por cada intervalo de bloque, lo que aumenta el número de transacciones que la red puede confirmar por segundo. La validación sin estado es el requisito previo para que NEAR alcance un mayor número de shards a escala. La documentación de la Fundación NEAR proporciona cifras de rendimiento actualizadas; para consultar los datos de TPS actuales vinculados a configuraciones de shards específicas, consulta docs.near.org.

Esto aborda directamente el pilar de la escalabilidad dentro del trilema de la escalabilidad de la Blockchain. La tensión histórica entre escalabilidad y descentralización en las redes fragmentadas (sharded) surge porque el aumento de la capacidad suele incrementar los costes de hardware de los validadores, lo que reduce la descentralización. La validación sin estado (stateless validation) elimina el mecanismo que causaba este compromiso, permitiendo a NEAR buscar incrementos en el número de fragmentos sin la correspondiente presión de centralización. El modelo de escalabilidad alcanza su máxima expresión en la Fase 3, el re-fragmentado dinámico (dynamic resharding), donde NEAR adquiere la capacidad de ajustar automáticamente el número de fragmentos basándose en la demanda de la red en tiempo real sin necesidad de coordinación manual.

Qué significa esto para los desarrolladores que construyen en NEAR

Si estás evaluando NEAR como plataforma de despliegue, la validación sin estado afecta a tus aplicaciones en la capa de infraestructura, no en la capa de contratos. Hay cuatro implicaciones prácticas que conviene entender antes de comprometerse con una decisión de arquitectura:

No se requieren cambios en los contratos. La validación sin estado es un cambio a nivel de protocolo. Sus contratos inteligentes no requieren modificación para beneficiarse de ella. Los contratos ya desplegados en NEAR operan automáticamente en la red actualizada y más escalable. No hay ningún paso de migración, ningún requisito de redespliegue ni cambio en la API.

Mayor rendimiento a medida que aumenta el número de shards. A medida que NEAR añade más shards habilitados por validación sin estado, aumenta la capacidad total de transacciones de la red. Para tu dApp, esto significa una menor probabilidad de congestión durante períodos de alta demanda y costes de transacción más estables y predecibles a medida que la red escala.

Infraestructura más resiliente. Un conjunto de validadores más descentralizado, propiciado por unas barreras de hardware más bajas para la participación de los validadores de fragmentos (chunks), reduce el riesgo de interrupciones de red relacionadas con la centralización. Las dApps en producción se benefician de una red de validadores más difícil de interrumpir mediante la concentración de operadores o fallos de hardware agrupados en un pequeño número de validadores con grandes recursos.

Ruta para desarrolladores de Ethereum. NEAR es compatible con Aurora, un entorno de ejecución compatible con EVM que permite a los desarrolladores de Ethereum desplegar contratos de Solidity en NEAR sin tener que reescribirlos en Rust o JavaScript. Esos contratos se ejecutan en la misma red subyacente y se benefician de las mismas mejoras en la infraestructura de validación sin estado (stateless validation).

Validación sin estado de NEAR frente a la hoja de ruta sin estado de Ethereum

Los desarrolladores familiarizados con la hoja de ruta de clientes sin estado de Ethereum descubrirán que la validación sin estado de NEAR aborda el mismo problema subyacente: desacoplar el hardware de validadores y nodos del tamaño del estado de la red. Los dos enfoques operan en diferentes niveles arquitectónicos y a través de diferentes mecanismos, moldeados por las estructuras fundamentalmente diferentes de las dos redes. No son diseños que compiten entre sí, sino respuestas paralelas a la carga de hardware del crecimiento del estado de Blockchain.

Ambos enfoques empaquetan los datos de estado que un validador o cliente necesita junto al bloque o fragmento (chunk) que se va a validar, por lo que la parte ejecutora nunca requiere una base de datos de estado local. La diferencia estructural es que la validación sin estado de NEAR se aplica dentro de un sistema fragmentado (sharded), dirigiéndose a los validadores a nivel de fragmento que constituyen la mayoría de su red. La hoja de ruta de validación sin estado de Ethereum se dirige a los nodos completos en una capa de ejecución monolítica, donde el estado de toda la cadena debe poder direccionarse finalmente a través de testigos (witnesses) de árboles de Verkle, en lugar de un trie de estado local.

Específicamente en cuanto a la dimensión de la fragmentación (sharding): el framework Nightshade de NEAR es un diseño de fragmentación de ejecución que divide tanto el estado como el cómputo entre fragmentos. La propuesta Danksharding de Ethereum se centra en la fragmentación de la disponibilidad de datos para los rollups de Layer 2 y no es un diseño de fragmentación de ejecución. Estos son objetivos arquitectónicamente diferentes que sirven a estructuras de red distintas, y las comparaciones directas entre Nightshade y Danksharding requieren reconocer que resuelven problemas diferentes.

¿Dónde encaja la validación sin estado en la hoja de ruta de NEAR?

La Fase 2 de Nightshade es la validación sin estado. Merece la pena exponer esta equivalencia con claridad porque la documentación de NEAR y los debates de la comunidad a veces utilizan «Fase 2» y «validación sin estado» de forma intercambiable, y comprender en qué fase nos encontramos permite conocer el estado de la arquitectura de escalado de la red.

Explicación de las tres fases de Nightshade

La implementación completa de Nightshade se desarrolla en tres fases distintas, cada una construyendo sobre la anterior y estableciendo las precondiciones para la siguiente.

Fase 1: Sharding Básico (Completado)

NEAR dividió el estado de su red en múltiples shards, con cada shard procesando transacciones en paralelo. Los validadores mantenían copias locales completas del estado de su shard asignado. Los productores de bloques agregaban fragmentos de todos los shards en bloques canónicos únicos. La Fase 1 estableció la arquitectura basada en fragmentos de Nightshade, pero dejó los requisitos de hardware directamente acoplados al tamaño del estado del shard, lo que creó el techo de escalabilidad que la Fase 2 aborda.

Fase 2: Validación sin estado (fase actual)

Los validadores de fragmentos ya no mantienen el estado local de la parcela. Los productores de fragmentos generan testigos de estado y los entregan junto con los fragmentos. Esto desacopla los requisitos de hardware de los validadores del tamaño del estado de la parcela y permite que la red escale a más parcelas sin aumentar proporcionalmente los costes de hardware de los validadores. En el momento de escribir este artículo, la Fase 2 se ha activado en la Mainnet de NEAR; para conocer la fecha exacta de activación y el estado actual de la red, consulte el blog de la Fundación NEAR y docs.near.org, ya que las fases del protocolo se activan progresivamente y la documentación se actualiza según corresponda.

Fase 3: Resharding dinámico (planificado)

NEAR obtendrá la capacidad de aumentar o disminuir automáticamente su número de shards en función de la demanda de la red en tiempo real, sin coordinación manual ni actualizaciones de hardware de los validadores. La validación sin estado es un prerrequisito directo para la reasignación de shards dinámica: sin la Fase 2 activa, añadir shards forzaría aumentos proporcionales en los costes de almacenamiento para los validadores, haciendo que el ajuste automático de shards sea económicamente inviable. La Fase 3 es el paso arquitectónico que permite la escalabilidad horizontal teóricamente ilimitada en NEAR.

En conjunto, las tres fases representan la progresión de NEAR desde una Blockchain fragmentada con asignaciones de fragmentos fijas y validadores con estado, hasta una red escalable dinámicamente que ajusta su propia capacidad de procesamiento sin requerir que su conjunto de validadores crezca proporcionalmente en costes de hardware.

Validación sin estado de NEAR: Implicaciones para validadores y stakers

Para los validadores de fragmentos, la validación sin estado elimina el principal impulsor de costes de hardware en la arquitectura anterior de NEAR: el requisito de mantener una copia local completa del estado del fragmento. Esto tiene implicaciones directas para la economía de la operación de los validadores y la accesibilidad práctica de la participación de los validadores.

Anteriormente, un validador de fragmentos necesitaba una capacidad de almacenamiento proporcional al tamaño del estado de su fragmento asignado, y ese requisito aumentaba a medida que la red acumulaba más cuentas, datos de contratos e historial de transacciones. El coste operativo de un validador de fragmentos incluía no solo el cómputo y el ancho de banda, sino también una infraestructura de almacenamiento continua que escalaba con el crecimiento de la red.

Los validadores de fragmentos que operan bajo validación sin estado ya no provisionan almacenamiento de estado. Sus requisitos de hardware pasan a ser la capacidad de cómputo para la ejecución de transacciones y el ancho de banda de red para recibir testigos de estado y transmitir atestaciones dentro del tiempo de bloque. Este es un perfil de costes fundamentalmente diferente: estable en lugar de creciente, y menor para cualquier número de fragmentos que el modelo anterior.

La validación sin estado cambia los requisitos de hardware para los validadores de fragmentos, pero no altera la mecánica fundamental del contrato de staking. Los validadores todavía hacen staking de tokens NEAR por encima del umbral de asiento para participar en el consenso, y siguen sujetos a slashing por mal comportamiento del validador. El coste de hardware para cumplir ese requisito de participación disminuye para los validadores de fragmentos, lo que amplía la reserva de participantes que pueden ejecutar un nodo validador de fragmentos a costes operativos económicamente viables. Para conocer las especificaciones de hardware actuales y los umbrales de asiento de staking, consulte docs.near.org/validator.

Tenga en cuenta que los productores de fragmentos todavía requieren el estado completo del fragmento local para generar testigos de estado. La reducción de hardware se aplica a los validadores de fragmentos, el rol más numeroso en la red. Los productores de fragmentos conservan sus requisitos de almacenamiento de estado, aunque representan una parte menor del número total de validadores.

Para convertirse en un validador en NEAR, un participante apuesta tokens NEAR por encima del umbral de asiento actual y ejecuta el software de validador. Para obtener instrucciones completas de configuración y las especificaciones de hardware actuales actualizadas para reflejar los requisitos de validación sin estado, consulte docs.near.org/validator) directamente.

Preguntas frecuentes

¿Para qué se utiliza NEAR Protocol?

NEAR Protocol es una blockchain de capa 1 diseñada para desplegar aplicaciones descentralizadas, incluyendo protocolos DeFi, plataformas NFT, aplicaciones de gaming y herramientas para desarrolladores. Utiliza la fragmentación Nightshade para procesar transacciones a través de múltiples fragmentos paralelos, permitiendo un alto rendimiento con comisiones de transacción casi nulas. El Token NEAR paga las comisiones de gas para la ejecución de transacciones y contratos, y los validadores staking de Tokens NEAR como garantía para participar en el consenso. ### ¿Cómo funciona NEAR Protocol?

Fundamentalmente, NEAR opera como una blockchain de prueba de participación (staking) dividida en múltiples fragmentos (shards), cada uno procesando transacciones en paralelo. Cada fragmento produce un fragmento (chunk) (un bloque a nivel de fragmento) en cada intervalo de bloque; un productor de bloques agrega estos fragmentos (chunks) en un único bloque canónico. Los validadores se asignan aleatoriamente a los fragmentos (shards) en cada época (epoch) y son responsables de ejecutar y dar fe de las transacciones en el fragmento (chunk) de su fragmento (shard) asignado, con la validación sin estado (stateless validation) que permite a los validadores de fragmentos (chunk validators) realizar esta función sin mantener el estado local del fragmento.

¿Qué es el sharding de Nightshade?

Nightshade es el framework de sharding de NEAR Protocol, en el que el estado global de la red y el procesamiento de transacciones se dividen en múltiples shards paralelos. A diferencia de los diseños que tratan cada shard como una blockchain separada, Nightshade trata todos los shards como componentes de una única blockchain lógica, con cada bloque conteniendo un fragmento (chunk) por shard activo. Nightshade se implementa en tres fases: sharding básico (Fase 1), validación sin estado (Fase 2) y re-sharding dinámico (Fase 3).

¿Qué es un testigo de estado en blockchain?

Un testigo de estado (state witness) es una estructura de datos criptográfica que contiene todos los datos de estado necesarios para validar un bloque o fragmento (chunk) específico, empaquetados y entregados a los validadores para que no necesiten acceder a una base de datos de estado local durante la ejecución. En el Protocolo NEAR, el testigo de estado de un fragmento incluye los saldos de las cuentas, las entradas de almacenamiento de los contratos y las claves de acceso afectadas por las transacciones de dicho fragmento. El productor del fragmento genera el testigo de estado y lo transmite junto con el fragmento a los validadores del fragmento, quienes ejecutan las transacciones utilizando los datos del testigo y luego los descartan tras producir su atestación.

¿Cómo funcionan los validadores de NEAR?

Los validadores de NEAR operan en tres roles distintos bajo la validación sin estado: productores de fragmentos (chunk producers), validadores de fragmentos (chunk validators) y productores de bloques (block producers). Los productores de fragmentos construyen fragmentos (bloques a nivel de shard) y generan testigos de estado (state witnesses) leyendo el estado relevante de la copia del estado de su shard local. Los validadores de fragmentos reciben el fragmento y el testigo de estado, ejecutan transacciones utilizando únicamente los datos del testigo sin almacenamiento de estado local, dan fe de la validez del fragmento y descartan el testigo. Los productores de bloques agregan los fragmentos validados (attested chunks) de todos los shards activos en un único bloque canónico. Los validadores realizan staking de tokens NEAR por encima de un umbral de asientos para participar en el consenso y se les asignan aleatoriamente shards cada época.

¿Cómo mejora la escalabilidad la validación sin estado?

La validación sin estado mejora la escalabilidad al desacoplar el número de shards de los requisitos de hardware del validador. Bajo la validación con estado, añadir más shards requería que los validadores asignados a cada nuevo shard mantuvieran un almacenamiento local proporcional, creando un límite de hardware para la cantidad de shards que la red podía soportar prácticamente. Con la validación sin estado, los validadores de fragmentos reciben todos los datos de estado requeridos por fragmento como un testigo de estado y los descartan después de su uso, por lo que añadir shards no aumenta los requisitos de almacenamiento por validador, permitiendo a NEAR escalar horizontalmente aumentando el número de shards para procesar más transacciones en paralelo.

¿Es NEAR una buena Blockchain para desarrolladores?

NEAR Protocol ofrece a los desarrolladores contratos inteligentes basados en WASM que pueden escribirse en Rust o JavaScript, un modelo de staking de almacenamiento que vincula los costes de almacenamiento de los contratos a los tokens NEAR en staking, compatibilidad con Aurora EVM para los desarrolladores de Ethereum que despliegan contratos en Solidity y nombres de cuenta legibles por humanos. La validación sin estado (stateless validation) es una mejora de la infraestructura a nivel de protocolo que beneficia a todos los contratos desplegados de forma automática, sin requerir cambios en el código. A medida que aumenta el número de fragmentos (shards), la capacidad de procesamiento de la red crece y los contratos se benefician de una menor congestión. Los desarrolladores que evalúen NEAR para el despliegue de dApps en producción deben consultar docs.near.org para obtener las especificaciones actuales del SDK y la documentación de las herramientas.

¿Está activa la validación sin estado de NEAR?

La Fase 2 de Nightshade, que es la validación sin estado, se ha activado en la mainnet de NEAR. Las fases del protocolo se implementan progresivamente y la documentación es actualizada por la NEAR Foundation a medida que cada fase alcanza la activación completa. Para conocer el estado de despliegue más actual, incluyendo la fecha de activación precisa y cualquier nota específica de la fase, consulte el blog de la NEAR Foundation) y la documentación oficial de NEAR Protocol.