¿Qué es NEAR Protocol? Validación sin estado

NEAR Protocol completó su actualización de validación sin estado como Nightshade Fase 2, y el cambio afecta a cada participante de la red de manera diferente. Los desarrolladores que evalúan NEAR como una plataforma de contrato inteligente necesitan entender lo que la arquitectura realmente hace. Los inversores que evalúan la hoja de ruta técnica de NEAR quieren saber si la validación sin estado representa un avance significativo. Los validadores que planifican su infraestructura necesitan el delta operativo: qué cambia, qué permanece igual y qué significa para el hardware.

Este artículo aborda los tres enfoques, comenzando por qué es NEAR y detallando cómo funciona la validación sin estado, qué es un testigo de estado, cómo los validadores y productores de fragmentos dividen sus responsabilidades, y qué se propone conseguir el re-particionamiento dinámico de la Fase 3 una vez que la validación sin estado siente sus bases.

Contenidos

• ¿Qué es NEAR Protocol?
• El problema que NEAR resuelve
• Cómo funciona NEAR: explicación de Nightshade Sharding
• ¿Qué es la Validación sin Estado (Stateless Validation) de NEAR?
• Por qué es importante la Validación sin Estado
• Resharding dinámico: qué viene después de la Validación sin Estado
• NEAR frente a Ethereum y Solana
• El ecosistema de NEAR
• NEAR Token, staking y economía de los validadores
• Lo que la Validación sin Estado significa para los validadores
• Preguntas frecuentes
• Conclusión

¿Qué es NEAR Protocol?

NEAR Protocol es una Blockchain de Capa 1 de prueba de participación diseñada para una alta escalabilidad, bajos costes de transacción y accesibilidad para desarrolladores. La Blockchain de NEAR utiliza una arquitectura de fragmentación llamada sharding Nightshade, que divide la red en carriles de procesamiento paralelo, y ha implementado la validación sin estado como su actualización Nightshade Fase 2 para permitir un procesamiento de transacciones Descentralizado de alto rendimiento. NEAR Protocol (la red Blockchain) utiliza NEAR (el Token Nativo) para las comisiones de transacción y el staking.

NEAR Protocol fue cofundado por Illia Polosukhin (coautor del artículo de 2017 "Attention Is All You Need" que introdujo la arquitectura Transformer subyacente en los modelos de lenguaje grandes modernos) y Alex Skidanov (exingeniero de software en Microsoft y coarquitecto del diseño de sharding Nightshade).

Características clave de NEAR Protocol:

• Fragmentación (sharding) Nightshade: procesamiento paralelo de transacciones a través de múltiples fragmentos (shards), cada uno de los cuales produce un segmento de bloque a nivel de fragmento llamado chunk
• Validación sin estado (Fase 2, activa): los validadores de chunks verifican las transacciones sin almacenar el estado local del fragmento, utilizando en su lugar testigos de estado (state witnesses)
• Tiempo de ejecución WebAssembly (Wasm): los contratos inteligentes se compilan en Wasm, admitiendo Rust y JavaScript como lenguajes de desarrollo
• Nombres de cuenta legibles por humanos: las cuentas siguen un formato de nomenclatura (p. ej., tunombre.near) en lugar de direcciones criptográficas en bruto
• Bajas comisiones de transacción: el modelo de comisiones de NEAR está diseñado para seguir siendo predecible a medida que el rendimiento de la red escala mediante la fragmentación
• Subvenciones para desarrolladores: la Fundación NEAR distribuye financiación del ecosistema para apoyar proyectos adyacentes al protocolo

NEAR utiliza Prueba de Staking con Umbral (una variante en la que los validadores se seleccionan en función de un umbral de staking mínimo en lugar de un ranking estricto de los N mejores). Esto distingue el consenso de NEAR del Delegated Proof of Stake estándar. NEAR tiene aproximadamente 100 validadores activos por época, y los titulares de Token de NEAR pueden delegar staking a los validadores sin ejecutar su propio nodo.

El entorno de ejecución WebAssembly (Wasm) de NEAR ejecuta contratos inteligentes en un formato aislado, determinista y agnóstico del lenguaje. Los desarrolladores escriben contratos en Rust o JavaScript, ambos lenguajes convencionales con grandes comunidades existentes, y los compilan a Wasm para su ejecución. La ejecución determinista es especialmente relevante para la validación sin estado: dadas las mismas entradas de estado proporcionadas a través de un testigo de estado (state witness), cada validador produce un resultado idéntico, lo que hace que la verificación sin estado sea matemáticamente sólida. Para los desarrolladores que evalúen NEAR, consulten la sección ¿Qué es la validación sin estado de NEAR? para conocer cómo afecta esta arquitectura al funcionamiento de la red.

NEAR se utiliza para contratos inteligentes, aplicaciones descentralizadas (dApps), protocolos DeFi, plataformas NFT, aplicaciones de Gaming, e interacción entre cadenas con Ethereum a través del proyecto del ecosistema Aurora.

El problema que resuelve NEAR

Los diseñadores de Blockchain se enfrentan a una tensión ampliamente aceptada conocida como el trilema de la escalabilidad: construir una red que sea simultáneamente escalable, segura y descentralizada es difícil porque optimizar cualquiera de estas dos propiedades tiende a comprometer la tercera. Este marco, asociado con el cofundador de Ethereum, Vitalik Buterin, es una tensión de diseño más que una restricción absoluta, pero describe un trade-off real por el que cada blockchain principal ha navegado de manera diferente.

Ethereum ha priorizado históricamente la seguridad y la descentralización, aceptando limitaciones de rendimiento que generaron comisiones de gas elevadas durante los periodos de congestión. Solana prioriza el rendimiento y la seguridad a través de una arquitectura de fragmento único y hardware de altas prestaciones, lo que concentra la participación de los validadores entre los operadores que pueden permitirse la infraestructura necesaria. Ninguno de los dos enfoques satisface simultáneamente las tres propiedades bajo una carga elevada.

La arquitectura de sharding Nightshade y la actualización de validación sin estado de NEAR están diseñadas para abordar las tres dimensiones: el sharding distribuye el procesamiento de transacciones para aumentar el rendimiento, la validación sin estado reduce los requisitos de hardware de los validadores para permitir una participación más amplia, y el diseño general mantiene la seguridad criptográfica en todo momento. Si NEAR logra esto en la práctica a escala sigue siendo una pregunta abierta. El re-sharding dinámico de Fase 3, que extiende este modelo aún más, todavía está en desarrollo.

Cómo funciona NEAR: Explicación del sharding Nightshade

Nightshade sharding es la arquitectura de NEAR Protocol para el procesamiento de transacciones en paralelo. Divide la Blockchain en carriles de procesamiento independientes denominados shards (carriles de procesamiento en paralelo que gestionan simultáneamente un subconjunto de transacciones de la red). La contribución de cada shard a un bloque se denomina chunk (una parte del bloque a nivel de shard; cada shard produce un chunk por intervalo de bloque). Los validadores se asignan a shards específicos en cada época, y los chunks resultantes se ensamblan en un único bloque final. (Publicación en el blog sobre Nightshade sharding)

Piense en Nightshade como una autopista de varios carriles en lugar de una única carretera. En un sistema de un solo carril, cada transacción espera detrás de todas las demás. Nightshade construye carriles paralelos: cada fragmento (shard) es un carril, y cada bloque parcial (chunk) es la porción de tráfico total de ese carril procesada en un intervalo de bloque determinado. En términos técnicos: NEAR mantiene una única cadena lógica que está físicamente particionada en shards. Cada shard procesa su propio conjunto de transacciones, genera un chunk y esos chunks son fusionados en un bloque unificado por los productores de bloques.

Cómo funciona el sharding de NEAR Protocol:

1. Las transacciones entrantes se enrutan al shard responsable de la cuenta del remitente
2. Cada shard procesa sus transacciones asignadas en paralelo con el resto de los shards
3. El conjunto de validadores de cada shard produce un chunk que contiene sus transacciones procesadas
4. Los validadores de chunks verifican que las transacciones de cada chunk sean válidas
5. Los productores de bloques agrupan todos los chunks de todos los shards en un único bloque final
6. El bloque final se añade a la cadena y se calculan las recompensas de los validadores

Las asignaciones de fragmentos de los validadores cambian en cada límite de época. Antes de la validación sin estado, rotar a un nuevo fragmento requería descargar y sincronizar el estado completo de ese fragmento, una operación lenta y con un uso intensivo de E/S. La validación sin estado cambia esto, tal como se describe en la tabla Hoja de ruta de Nightshade a continuación.

Hoja de ruta de Nightshade

Nightshade es una actualización multifase. Cada fase se basa en la anterior, y la validación sin estado es la segunda de las tres fases planificadas.

Última verificación: 2025. Consulta near.org para el estado actual de la hoja de ruta.

La Fase 1 introdujo mecanismos de control de congestión para gestionar el flujo de transacciones entre fragmentos (cross-shard), asegurando que la sobrecarga de un fragmento no se propague en cascada por toda la red. La Fase 2 (validación sin estado) es la actualización activa que este artículo cubre en profundidad. La Fase 3 (re-fragmentación dinámica) está planeada; consulte Re-fragmentación dinámica: Qué viene después de la validación sin estado para entender por qué la Fase 2 es un requisito previo para la Fase 3.

¿Qué es la validación sin estado de NEAR?

La validación sin estado de NEAR es un modelo de arquitectura blockchain en el que los validadores de fragmentos (chunk validators) verifican las transacciones de partición (shard transactions) sin almacenar una copia local del estado de la partición. En su lugar, los validadores reciben un testigo de estado (state witness) (una prueba criptográfica compacta generada por el productor del fragmento) que contiene solo los datos de estado necesarios para verificar un fragmento específico. Esta es Nightshade Fase 2, desplegada como una actualización de protocolo en vivo. (Publicación de blog Nightshade Fase 2)

Antes de la validación sin estado, cada validador asignado a un shard debía mantener una copia local actualizada continuamente del estado de dicho shard. Almacenar todos los saldos de cuenta, los valores de almacenamiento de contratos inteligentes y otras entradas de estado para cada cuenta dentro del shard era la obligación principal del hardware. Cuando los validadores rotaban a una nueva asignación de shard en el límite de la época, debían descargar y sincronizar todo el estado del nuevo shard antes de poder empezar a validar, un proceso que a menudo requería horas de trabajo de E/S.

La validación sin estado (stateless validation) elimina por completo ese requisito para los validadores de fragmentos (chunk validators). El productor de fragmentos, un nodo con estado que sí mantiene el estado completo de la partición (shard), genera un testigo de estado (state witness) junto con cada fragmento y transmite ambos a los validadores de fragmentos. Los validadores de fragmentos verifican el fragmento comparándolo con el testigo sin necesidad de almacenamiento local del estado. Para obtener una explicación precisa sobre qué contiene un testigo de estado y cómo se genera, consulta ¿Qué es un testigo de estado?

La diferencia práctica entre los dos modelos:

Por qué esto es importante: NEAR puede admitir más validadores con menos costes de infraestructura, una mejora directa de la descentralización de la red.

Para el proceso paso a paso de cómo opera la validación sin estado, consulte Cómo Funciona la Validación Sin Estado de NEAR Paso a Paso. Para la función específica de los validadores de fragmentos frente a los productores de fragmentos, consulte Validadores de Fragmentos vs. Productores de Fragmentos.

Cómo Funciona la Validación Sin Estado de NEAR Paso a Paso

El proceso de validación sin estado se ejecuta de la siguiente manera para cada fragmento procesado en la red de NEAR:

["Una transacción se envía a la red y se enruta al shard responsable de la cuenta del remitente","El productor de chunks ejecuta las transacciones en su shard asignado contra su base de datos del estado local del shard","El productor de chunks genera un testigo de estado que contiene solo las entradas de estado afectadas por las transacciones de este chunk, además de pruebas de Merkle de su inclusión en el trie del estado del shard","El productor de chunks difunde el chunk y el testigo de estado juntos a los validadores de chunks asignados para ese shard","Los validadores de chunks reciben el testigo de estado y verifican que las transacciones en el chunk se apliquen correctamente al estado atestiguado, sin necesidad de una base de datos de estado local","El chunk validado se reenvía a los productores de bloques, quienes agregan todos los chunks de shard en el bloque final"]

Qué significa esto para los validadores: Los validadores de fragmentos ya no necesitan mantener ni sincronizar el estado de los shards. Cada fragmento llega con su propio paquete de pruebas autocontenido. Cuando tu validador cambia a un nuevo shard en el límite de una época, no hay descarga de estado. Comienzas a recibir testigos de estado para los fragmentos de ese shard y empiezas a validar inmediatamente.

Por qué esto es importante: la separación entre el almacenamiento de estado (productores de fragmentos) y la verificación de estado (validadores de fragmentos) permite que el grupo de validadores crezca sin aumentos proporcionales en los costos de hardware.

¿Qué es un testigo de estado?

Un testigo de estado en NEAR es una prueba criptográfica compacta generada por el productor de chunks que contiene todos los datos de estado de la shard que un validador de chunks necesita para verificar un chunk específico. Los validadores de chunks reciben el testigo de estado junto con los datos del chunk y lo utilizan para confirmar la validez de las transacciones sin consultar ninguna base de datos de estado local.

Piense en un testigo de estado como en un extracto notarizado de un archivador. En lugar de enviar el archivador completo a cada validador, el productor del fragmento extrae únicamente las páginas relevantes para las transacciones de dicho fragmento, las certifica criptográficamente y envía solo lo que es necesario. La analogía se mantiene a nivel práctico: el validador recibe un paquete de pruebas autónomo en lugar de una Copia completa del estado.

En términos técnicos: el testigo de estado contiene las entradas del trie de estado (saldos de cuentas, valores de almacenamiento de contratos) tocadas por las transacciones en un fragmento particular, además de las pruebas de Merkle de su inclusión en el trie de estado del shard actual. Un validador que recibe el testigo puede verificar cada prueba de Merkle para confirmar que las entradas de estado son genuinas y, a continuación, ejecutar las transacciones contra dichas entradas para confirmar que las salidas del fragmento son correctas.

Cómo se genera y utiliza un testigo de estado:

1. El productor de chunks ejecuta todas las transacciones de su chunk contra el estado de su shard local
2. Durante la ejecución, registra cada entrada del trie de estado que se haya leído o escrito
3. Genera pruebas de Merkle que demuestran que cada entrada registrada pertenece al trie de estado del shard
4. Empaqueta esas entradas y pruebas en el state witness
5. Los validadores de chunks reciben el witness, verifican las pruebas de Merkle y vuelven a ejecutar las transacciones contra las entradas proporcionadas

Una aclaración importante para los lectores técnicos: los state witnesses de NEAR son atestaciones de datos de estado basadas en pruebas de Merkle. No son pruebas de conocimiento cero (zero-knowledge proofs). El mecanismo no implica circuitos ZK ni sistemas de pruebas; utiliza pruebas de inclusión de árboles de Merkle estándar para certificar que entradas de estado específicas son fragmentos auténticos del estado del shard.

Esto es lo que significa para los validadores: El testigo de estado es el paquete de datos que hace posible tu validación sin estado. No necesitas confiar en la base de datos de estado del productor de fragmentos; verificas tú mismo las pruebas de Merkle incluidas en el testigo. Si las pruebas son correctas y las transacciones se reejecutan correctamente contra las entradas proporcionadas, el fragmento es válido.

Por qué esto es importante: porque los testigos de estado son autocontenidos y verificables, cualquier validador puede comprobar cualquier fragmento sin conocimiento previo del historial de la shard, abriendo la puerta a reasignaciones de shards frecuentes y fluidas.

Validadores de Fragmentos frente a Productores de Fragmentos

Los validadores de fragmentos en NEAR son nodos responsables de validar fragmentos individuales de shard, las porciones a nivel de shard de cada bloque. Bajo validación sin estado, los validadores de fragmentos no almacenan ni mantienen el estado local del shard. Reciben un testigo de estado del productor del fragmento y lo utilizan para verificar que las transacciones en un fragmento se aplican correctamente al estado presenciado.

Los productores de chunks son la contraparte con estado. Un productor de chunks mantiene una copia local completa del estado de su shard asignado, construye el chunk ejecutando transacciones contra ese estado, genera el testigo de estado y transmite tanto el chunk como el testigo a los validadores de chunks. Los productores de chunks tienen requisitos de hardware elevados debido a su obligación de almacenamiento de estado. Esta es la capa con estado que permite al resto de la red operar sin estado.

Los productores de bloques son una tercera función distinta: agregan fragmentos validados de todas las fragmentaciones (shards) en el bloque final. No confunda estos tres roles; tienen diferentes funciones, requisitos de estado y perfiles de hardware.

NEAR utiliza una época (la unidad de tiempo de NEAR, aproximadamente 12 horas, al final de la cual las asignaciones de fragmento de los validadores rotan) para gobernar la rotación de validadores. En cada límite de época, los validadores de fragmentos son reasignados a fragmentos. Bajo el modelo anterior con estado, esta rotación requería descargar y sincronizar el estado completo del nuevo fragmento, una operación costosa que ralentizaba la reasignación de validadores y concentraba el conjunto de validadores. Con la validación sin estado, un validador reasignado a un nuevo fragmento simplemente comienza a recibir testigos de estado para los fragmentos de ese fragmento y empieza a verificar inmediatamente. Las recompensas de staking se calculan y distribuyen en los límites de época. (Documentación de validadores de NEAR,) Documentación de épocas de NEAR))

Lo que esto significa para los validadores: La rotación de fragmentos en el límite de la época ya no requiere una descarga de estado. Si tu validador es reasignado del Fragmento A al Fragmento B en la próxima época, comienzas a recibir testigos de estado de los fragmentos del Fragmento B y puedes empezar a validar a los pocos segundos de que se abra la nueva época.

Por qué esto es importante: la rotación de shards sin fricción hace que sea práctico que participe un conjunto mucho más amplio de validadores, ya que el coste operativo de la reasignación es casi nulo bajo el modelo sin estado.

Por qué importa la validación sin estado

La validación sin estado mejora la descentralización de NEAR al eliminar el requisito de almacenamiento del estado de los fragmentos para los validadores de fragmentos. Menores requisitos de almacenamiento y hardware significan que más participantes pueden operar nodos validadores, ampliando el conjunto de validadores activos y distribuyendo la seguridad de la red entre una base más amplia de operadores.

La cadena de mecanismos es directa: los testigos de estado eliminan la necesidad de que los validadores de fragmentos almacenen el estado del fragmento, lo que elimina el principal coste de hardware para la función de validación. Con un requisito de hardware menor, un grupo mayor de operadores puede ejecutar validadores de fragmentos de forma rentable. Un grupo de validadores más grande y geográficamente distribuido reduce el riesgo de concentración y fortalece la resistencia de la red a la interferencia coordinada.

La validación sin estado por sí sola no cambia el modelo de Tarifa de Gas de NEAR; las tarifas de transacción siguen estando determinadas por la complejidad computacional y la demanda de la red. Sin embargo, al crear el prerrequisito arquitectónico para el re-particionamiento dinámico de la Fase 3, la validación sin estado proporciona la base para la estabilidad de las tarifas a medida que aumenta el volumen de transacciones: más fragmentos significan más capacidad de procesamiento, y esa capacidad puede expandirse sin aumentos proporcionales en las tarifas. Para ver cómo el re-particionamiento dinámico se basa en esto, consulte Re-particionamiento Dinámico: Qué Viene Después de la Validación sin Estado.

La actualización de validación sin estado de NEAR fortalece su base técnica al separar el almacenamiento del estado de la verificación del estado, un cambio estructural que afecta a la economía de los validadores, la descentralización de la red y la viabilidad del escalado elástico del rendimiento.

Particionamiento dinámico: ¿Qué sigue a la validación sin estado?

El resharding dinámico es la mejora de la Fase 3 planificada de NEAR que tiene como objetivo permitir que la red divida o fusione fragmentos (shards) automáticamente en función de la demanda de transacciones en tiempo real, escalando el rendimiento hacia arriba o hacia abajo sin necesidad de tiempo de inactividad de los validadores ni de una reconfiguración manual.

La relación de prerrequisito entre la validación sin estado (stateless validation) y la fragmentación dinámica (dynamic resharding) es de carácter arquitectónico. Bajo la validación con estado, rotar un validador a un nuevo fragmento requería sincronizar el estado completo de dicho fragmento, un proceso que tomaba horas. Añadir un nuevo fragmento de forma dinámica exigiría que todos los validadores asignados a él completaran esta sincronización antes de poder iniciar cualquier validación. Este cuello de botella operativo hacía que la división de fragmentos sobre la marcha fuera poco práctica.

La validación sin estado elimina ese cuello de botella. Dado que los validadores de fragmentos ya no precargan el estado del fragmento, pueden asignarse instantáneamente a un fragmento nuevo, un fragmento dividido o una configuración de fragmento fusionado y comenzar a validar de inmediato; los testigos de estado proporcionan todo lo que necesitan por fragmento. La Fase 3 tiene como objetivo basarse en esta propiedad para permitir que el protocolo aumente automáticamente el número de fragmentos cuando los fragmentos individuales se acercan a su capacidad, y disminuya el número de fragmentos cuando la demanda cae.

El re-particionamiento dinámico de la Fase 3 aún no está activo. La hoja de ruta de NEAR lo describe como una actualización planificada. Las hojas de ruta de los protocolos están sujetas a cambios; consulta near.org para conocer el estado de desarrollo actual.

Por qué esto importa: El efecto inmediato de la validación sin estado son menores requisitos de hardware para los validadores de fragmentos. Su importancia posterior es que hace que el escalado de rendimiento elástico sea arquitectónicamente factible de una manera que no era posible antes de la Fase 2.

NEAR frente a Ethereum y Solana

NEAR se diferencia de Ethereum de tres formas medibles: NEAR utiliza el sharding Nightshade para procesar transacciones a través de fragmentos paralelos, mientras que Ethereum opera como una única cadena de ejecución; NEAR ha implementado la validación sin estado como una funcionalidad activa del protocolo, mientras que la propuesta equivalente de Ethereum (EIP-4762) permanece en fase de investigación y desarrollo a fecha de 2025; y los contratos inteligentes de NEAR se compilan en WebAssembly y pueden escribirse en Rust o JavaScript, mientras que el entorno principal de contratos inteligentes de Ethereum es Solidity en la Máquina Virtual Ethereum (EVM).

Propuesta de cliente sin estado de Ethereum: La investigación de Ethereum sobre los clientes sin estado comparte el mismo objetivo conceptual que la actualización de la Fase 2 de NEAR, permitiendo que los nodos verifiquen bloques sin almacenar el estado completo. El enfoque propuesto por Ethereum, descrito en EIP-4762, requiere la transición de Merkle Patricia Tries a Árboles Verkle como estructura de estado subyacente. Se trata de una migración de protocolo de varios años que sigue en fase de investigación y desarrollo a fecha de 2025. NEAR ha desplegado su implementación de validación sin estado como una funcionalidad activa del protocolo; el equivalente de Ethereum está propuesto pero aún no se ha desplegado. Estas son implementaciones distintas que persiguen un objetivo arquitectónico similar en diferentes etapas de desarrollo.

La contrapartida arquitectónica de Solana: Solana logra un alto rendimiento de transacciones a través de una arquitectura de un solo shard en la que todos los validadores procesan todas las transacciones contra el estado global completo. Este enfoque ofrece un alto rendimiento pero requiere que los validadores mantengan hardware sustancial (CPU de gama alta, asignación de RAM grande, SSD NVMe rápidas), lo que concentra la participación de los validadores entre operadores con recursos de infraestructura significativos. El enfoque fragmentado (sharded) más sin estado de NEAR tiene como objetivo lograr una capacidad de rendimiento comparable, permitiendo al mismo tiempo que los validadores de fragmentos (chunk validators) operen con requisitos de hardware más bajos. NEAR también compite en el mercado de Plataformas de Capa 1 junto a Avalanche y cadenas basadas en Move como Aptos y Sui, aunque esas arquitecturas difieren significativamente del enfoque de sharding de NEAR.

NEAR: fortalezas y limitaciones actuales

Puntos fuertes:

• El sharding Nightshade está activo y procesando transacciones a través de fragmentos paralelos
• La validación sin estado (Fase 2) está desplegada, reduciendo la barrera de hardware para los validadores de fragmentos (chunks)
• El runtime WebAssembly soporta Rust y JavaScript, reduciendo la curva de aprendizaje para los desarrolladores en comparación con entornos solo de Solidity
• Bajas comisiones por transacción por diseño, con un modelo de comisiones diseñado para escalar a través del sharding
• Subvenciones para desarrolladores disponibles a través de la Fundación NEAR

Limitaciones:

• El ecosistema de NEAR es más pequeño que el de Ethereum en términos de valor total bloqueado y actividad de los desarrolladores
• El resharding dinámico de la Fase 3 aún no está activo
• El tamaño de la comunidad de desarrolladores es menor que el de Solana

El ecosistema de NEAR

La Fundación NEAR es una organización suiza sin ánimo de lucro que supervisa el desarrollo del ecosistema, las subvenciones para desarrolladores, las asociaciones y la gobernanza del protocolo para NEAR Protocol. Se distingue de los equipos de ingeniería principales responsables del desarrollo del protocolo. La Fundación administra subvenciones para proyectos que se desarrollan sobre la infraestructura de NEAR y apoya la incorporación de desarrolladores.

NEAR Protocol admite una variedad de categorías de aplicaciones, que incluyen protocolos DeFi, plataformas NFT, aplicaciones de Gaming y plataformas de redes sociales. Las herramientas de desarrollo de NEAR están diseñadas para la accesibilidad: soporte para Rust y JavaScript (ambos lenguajes populares), nombres de cuenta legibles por humanos y documentación en docs.near.org.

Aurora es una capa de ejecución compatible con la Máquina Virtual Ethereum (EVM) construida sobre la infraestructura de NEAR que permite a los desarrolladores desplegar contratos inteligentes de Solidity en NEAR sin necesidad de reescribir código. Aurora es un proyecto de ecosistema independiente, no una característica del NEAR Protocol. Rainbow Bridge permite transferencias de activos sin confianza específicamente entre NEAR y Ethereum, permitiendo a los usuarios mover ETH y tokens ERC-20 entre las dos redes. NEAR también ofrece un servicio de disponibilidad de datos (NEAR DA) utilizado por Rollups de Ethereum y redes de Capa 2 que buscan capas de disponibilidad de datos de bajo coste y alto rendimiento.

Para desarrolladores que consideren NEAR como plataforma: el soporte del entorno de ejecución Wasm para Rust y JavaScript reduce la curva de aprendizaje en comparación con entornos exclusivos de EVM, y el proyecto del ecosistema Aurora proporciona una vía de migración para bases de código Solidity existentes.

NEAR Token, Staking y economía de validadores

El NEAR Token sirve cuatro funciones dentro del protocolo:

• Tarifas de transacción (gas): NEAR paga por la computación en la red; una parte se quema y otra se distribuye a los validadores
• Staking: los validadores y delegadores bloquean NEAR para asegurar la red y obtener recompensas por staking
• Gobernanza: los titulares del token NEAR participan en las decisiones de gobernanza del protocolo
• Subvenciones para el ecosistema: la Fundación NEAR distribuye tokens NEAR como subvenciones para el desarrollo del ecosistema

Los titulares de tokens NEAR pueden participar en la seguridad de la red ejecutando un nodo validador directamente o delegando staking a un validador existente a través de una cartera NEAR. La delegación no requiere ejecutar ninguna infraestructura; los titulares seleccionan un validador y delegan su staking. Para obtener instrucciones detalladas sobre staking, consulta docs.near.org/validator/staking-overview.

El efecto de la validación sin estado en la dinámica del staking es estructural: al reducir los requisitos de hardware para los validadores de fragmentos, la actualización está diseñada para ampliar el grupo de operadores de validadores económicamente viables con el tiempo. Un grupo de validadores más grande significa que el staking está más distribuido, lo cual es positivo para la descentralización de la red. Los rendimientos del staking varían según la participación total en la red y el número de validadores activos; a medida que el grupo de validadores se expande, estas dinámicas pueden cambiar.

Este artículo tiene fines meramente informativos y educativos. Nada en este artículo constituye asesoramiento financiero, de inversión o legal. Las Criptomoneda y los activos de blockchain conllevan un riesgo significativo. Realice siempre su propia investigación antes de tomar decisiones de inversión.

Qué significa la validación sin estado para los validadores

Bajo la validación sin estado, el modelo operativo de los validadores de fragmentos cambia de cinco formas específicas:

1. Sin necesidad de almacenamiento del estado de la fragmentación: los validadores de fragmentos ya no mantienen una Copiar local del estado de su fragmentación asignada
2. Los testigos de estado sustituyen a la sincronización de estado: los validadores de fragmentos reciben un testigo de estado con cada fragmento, que contiene todos los datos de estado necesarios para la verificación
3. Rotación de fragmentos sin fricciones: cuando se asignan a un nuevo fragmento en un límite de época, los validadores comienzan a recibir los testigos de estado de dicho fragmento inmediatamente, sin necesidad de descargar el estado
4. Reducción de los requisitos de hardware de almacenamiento: se ha eliminado la obligación de almacenamiento que anteriormente representaba el mayor coste de hardware para la función de validación de fragmentos
5. Los productores de fragmentos conservan el estado completo: la función de productor de fragmentos sigue requiriendo el mantenimiento del estado completo de la fragmentación y un hardware superior, y esta distinción es importante para la planificación de la infraestructura

¿Aún necesitan los validadores de fragmentos almacenar el estado del fragmento? No. Los validadores de fragmentos ya no necesitan almacenar el estado local del fragmento. Reciben un testigo de estado del productor de fragmentos cada vez que validan un fragmento. Los productores de fragmentos (los nodos que crean los fragmentos y generan los testigos de estado) siguen manteniendo el estado completo del fragmento y conservan requisitos de almacenamiento elevados.

Los validadores de fragmentos en la validación sin estado no necesitan almacenamiento SSD de alta capacidad para el estado del fragmento. El modelo anterior requería este almacenamiento como el coste principal de hardware para la función de validación; ese requisito ya no existe. Los productores de fragmentos mantienen el estado completo del fragmento y requieren hardware de almacenamiento proporcional al tamaño del estado de su fragmento; los operadores que planean ejecutar productores de fragmentos deben tener esto en cuenta. Las especificaciones oficiales de hardware para ambas funciones se publican en docs.near.org/concepts/basics/validators.

La asignación de fragmentos (shards) opera en épocas de aproximadamente 12 horas. En cada límite de época, el mecanismo de selección de validadores de NEAR reasigna los validadores de fragmentos (chunks) entre los fragmentos. Bajo la validación sin estado (stateless validation), esta reasignación no presenta fricciones: el validador recién asignado recibe los testigos de estado (state witnesses) para los fragmentos de su nuevo fragmento por parte del productor de fragmentos y comienza a validar de inmediato. El modelo anterior requería una sincronización de estado que podía tardar horas; ese coste se elimina para los validadores de fragmentos. Los detalles sobre la mecánica de las épocas y la distribución de recompensas están documentados en docs.near.org/concepts/basics/epoch.

Qué significa esto para los validadores: Si operas un nodo validador de chunks, tu modelo de aprovisionamiento de almacenamiento ha cambiado. Ya no es necesario asignar una gran capacidad de SSD para el estado de la shard en el hardware del validador de chunks. La rotación de shards en los límites de época es ahora operativamente insignificante. Si operas o estás considerando un rol de productor de chunks, los requisitos de estado se mantienen: el almacenamiento completo del estado de la shard sigue siendo necesario en esa capa.

Preguntas frecuentes

¿Qué es NEAR Protocol?

NEAR Protocol es una blockchain de prueba de participación (proof-of-stake) de capa 1 que utiliza el sharding de Nightshade para procesar transacciones a través de fragmentos paralelos. Ha implementado la validación sin estado como su actualización de Fase 2, lo que permite a los validadores de fragmentos verificar transacciones sin almacenar el estado del fragmento localmente. NEAR Protocol utiliza el token NEAR para las comisiones de transacción, staking y gobernanza. Para una cobertura completa, consulta: ¿Qué es NEAR Protocol?

¿Quién creó NEAR Protocol?

NEAR Protocol fue cofundado por Illia Polosukhin, coautor del artículo de 2017 "Attention Is All You Need" que introdujo la arquitectura Transformer en la que se basan los modelos de lenguaje extensos modernos, y Alex Skidanov, exingeniero de software en Microsoft y coarquitecto del diseño de sharding Nightshade. Ambos fundadores aportaron trayectorias técnicas distintas que dieron forma a la arquitectura de NEAR, centrada en la investigación. Para obtener información detallada, consulta: ¿Qué es NEAR Protocol?

¿Qué es la validación sin estado en Blockchain?

La validación sin estado es un modelo de arquitectura de Blockchain en el que los validadores verifican transacciones sin mantener una copia local del estado de la red. En lugar de almacenar el estado, los validadores reciben un testigo de estado, una prueba criptográfica que contiene solo los datos de estado necesarios para verificar un bloque o fragmento específico. NEAR ha implementado la validación sin estado como Nightshade Fase 2; es la primera Layer-1 importante en implementar este modelo en producción. Para una cobertura completa, consulte: ¿Qué es la Validación sin Estado de NEAR?

¿Cómo Funciona el Sharding de NEAR?

El sharding Nightshade de NEAR divide la Blockchain en vías de procesamiento paralelas denominadas shards. Cada shard procesa un subconjunto de transacciones simultáneamente y produce un segmento de bloque a nivel de shard denominado chunk. Los validadores se asignan a shards específicos por época, y los productores de bloques agregan todos los chunks de todos los shards en un único bloque final. Para una cobertura completa, consulte: Cómo funciona NEAR: Explicación del sharding Nightshade

¿Qué es un State Witness en NEAR?

Un testigo de estado en NEAR es una prueba criptográfica compacta generada por el productor de fragmentos que contiene todos los datos del estado del fragmento que un validador de fragmentos necesita para verificar un fragmento específico. Incluye las entradas del trie de estado afectadas por las transacciones del fragmento, además de pruebas Merkle de su inclusión en el trie de estado del fragmento. Los testigos de estado son atestaciones basadas en pruebas Merkle; no son pruebas de conocimiento cero. Para una cobertura completa, consulte: ¿Qué es un testigo de estado?

¿Qué son los validadores de fragmentos en NEAR?

Los validadores de fragmentos en NEAR son nodos responsables de validar fragmentos de shard individuales, que son las porciones a nivel de shard de cada bloque. Bajo validación sin estado, no almacenan el estado local del shard; reciben un testigo de estado del productor del fragmento y verifican que las transacciones del fragmento se apliquen correctamente al estado presenciado. Los validadores de fragmentos son distintos de los productores de fragmentos (que crean fragmentos y mantienen el estado) y de los productores de bloques (que ensamblan los bloques finales). Para una cobertura completa, consulte: Validadores de fragmentos vs. Productores de fragmentos

¿Utiliza NEAR Prueba de Participación?

Sí. NEAR utiliza Thresholded Proof of Stake, una variante en la que los validadores se seleccionan en función de un umbral de staking mínimo en lugar de una clasificación estricta de los N mejores por tamaño de staking. NEAR cuenta con aproximadamente 100 validadores activos por época. Los titulares de Token NEAR pueden delegar su staking a los validadores sin necesidad de ejecutar su propia infraestructura. Para obtener información detallada, consulta: ¿Qué es NEAR Protocol?

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

La validación sin estado mejora la descentralización al eliminar el requisito de almacenamiento del estado del fragmento para los validadores de fragmentos (chunks). Unos requisitos de hardware más bajos reducen la barrera económica para operar un nodo validador. A medida que más participantes pueden permitirse operar validadores, el conjunto de validadores se expande, distribuyendo la seguridad de la red entre un conjunto de operadores más amplio y geográficamente más diverso. Para una cobertura completa, consulta: Por qué es importante la validación sin estado

¿Qué es el re-fragmentado dinámico (Dynamic Resharding)?

El resharding dinámico es la actualización prevista para la Fase 3 de NEAR que tiene como objetivo permitir que la red divida o fusione fragmentos (shards) automáticamente en función de la demanda de transacciones en tiempo real, escalando el rendimiento hacia arriba o hacia abajo sin tiempo de inactividad del validador ni reconfiguración manual. Aún no está activo. La validación sin estado (stateless validation) es un prerrequisito arquitectónico para el resharding dinámico porque los validadores sin estado pueden asignarse instantáneamente a fragmentos nuevos o reconfigurados sin una operación de sincronización de estado. Para una cobertura completa, consulta: Dynamic Resharding: What Comes After Stateless Validation

¿Cuáles son los requisitos de hardware para los validadores de NEAR después de la validación sin estado?

Los validadores de fragmentos ya no necesitan almacenamiento SSD de alta capacidad para el estado del shard bajo validación sin estado; se ha eliminado el coste de hardware predominante para el rol de validación de fragmentos. Los productores de fragmentos todavía requieren almacenamiento completo del estado del shard y tienen requisitos de hardware elevados. Las especificaciones de hardware específicas para ambos roles se publican en la documentación de validadores de NEAR. Para contexto operativo, consulte: What Stateless Validation Means for Validators

Conclusión

La actualización de validación sin estado del NEAR Protocol separa la validación de chunks del almacenamiento de estado, reduciendo la barrera de hardware para los validadores de chunks y creando la base técnica para el reparticionamiento dinámico (dynamic resharding) de la Fase 3. Los validadores de chunks ahora reciben un testigo de estado (state witness) por chunk en lugar de mantener una base de datos de estado de shard local. La rotación de shards en los límites de época (epoch boundaries) es fluida. El pool de validadores está diseñado para expandirse a medida que disminuye el umbral de hardware para la validación de chunks.

El roadmap de Nightshade posiciona esto como un desarrollo secuencial: la Fase 1 estableció el control de congestión entre shards, la Fase 2 entregó la validación sin estado, y la Fase 3 tiene como objetivo añadir la re-fragmentación dinámica una vez que el modelo de validador sin estado haga que la reasignación instantánea de shards sea operativamente viable.

Próximos pasos para desarrolladores y validadores:

• Documentación para desarrolladores de NEAR para especificaciones completas del protocolo, guías de SDK y configuración de validadores
• SDK de Rust de NEAR) para crear contratos inteligentes en Rust
• SDK de JavaScript de NEAR) para crear contratos inteligentes en JavaScript
• Descripción general del staking de validadores de NEAR) para la configuración del staking y la delegación
• Subvenciones de la Fundación NEAR para la financiación de proyectos del ecosistema