Modelo de Cuenta NEAR: Nombres, Claves y Almacenamiento

Contenido

• ¿Qué es NEAR Protocol?
• TL;DR: El modelo de cuentas de NEAR de un vistazo
• ¿Qué es el modelo de cuentas de NEAR?
• Cuentas con nombre y cuentas implícitas: Cómo identifica NEAR a los usuarios
• Subcuentas: Organización jerárquica de cuentas en NEAR
• Claves de acceso de NEAR: Acceso total frente a permisos de llamada a funciones
• Staking de almacenamiento: Por qué las cuentas de NEAR requieren un saldo mínimo
• Modelo de cuentas de NEAR frente a Ethereum: Una comparación directa
• Primeros pasos: Creación y gestión de tu cuenta de NEAR
• Preguntas frecuentes: El modelo de cuentas de NEAR
• Conclusión: Qué significa el modelo de cuentas de NEAR para desarrolladores y usuarios

¿Qué es NEAR Protocol? (Una breve introducción)

NEAR Protocol es una blockchain de Capa 1, proof-of-stake, diseñada para la accesibilidad de los desarrolladores, con tarifas de transacción bajas y predecibles y una arquitectura de fragmentación (sharding) concebida para escalar sin sacrificar la usabilidad. Cofundado por Illia Polosukhin y Alexander Skidanov, NEAR Protocol fue diseñado desde el principio con la experiencia del desarrollador y la accesibilidad del usuario final como objetivos principales, en lugar de adaptar la usabilidad a una arquitectura creada para otros propósitos.

NEAR escala a través del sharding Nightshade, un mecanismo que distribuye el estado de las cuentas y la computación en cadenas de procesamiento paralelas, permitiendo que la red gestione un alto volumen de transacciones sin un aumento proporcional de las comisiones. El protocolo soporta contratos inteligentes compilados a WebAssembly y mantiene los costes de gas bajos por diseño, en contraste con blockchains donde la volatilidad de las comisiones genera fricción tanto para desarrolladores como para usuarios. El desarrollo del ecosistema está supervisado por la NEAR Foundation, el organismo de gobernanza sin ánimo de lucro que anteriormente gestionaba la NEAR Wallet oficial antes de migrar a alternativas mantenidas por la comunidad.

La expresión más clara de esta filosofía centrada en el desarrollador es el modelo de cuentas de NEAR, un diseño que replantea desde cero cómo funcionan la identidad y la gestión de permisos en la Blockchain.

--- ## TL;DR: Modelo de Cuenta de NEAR de un vistazo

Resumen rápido para lectores con prisas:

• Las cuentas de NEAR utilizan nombres legibles por humanos (por ejemplo, alice.near) en lugar de cadenas de hashes criptográficos como las direcciones 0x742d35Cc... de Ethereum.
• Cada cuenta puede tener múltiples claves de acceso simultáneamente, cada una con su propio nivel de permiso, desde el control total hasta interacciones con contratos de alcance limitado.
• Cualquier cuenta de NEAR puede desplegar un Contrato inteligente; no existe un tipo de cuenta de contrato separado como en Ethereum.
• Las subcuentas siguen un espacio de nombres jerárquico (por ejemplo, contract.myapp.near bajo myapp.near), funcionando como subdominios para cuentas de Blockchain.
• Las cuentas deben mantener un saldo mínimo de Token NEAR proporcional al uso de su almacenamiento On-Chain, un mecanismo llamado storage staking.
• El sistema nativo de permisos multiclave de NEAR logra muchos de los objetivos que Ethereum busca alcanzar con la abstracción de cuentas (EIP-4337), pero mediante un enfoque arquitectónico diferente integrado desde su creación.

¿Qué es el modelo de cuenta NEAR?

El modelo de cuenta de NEAR es la arquitectura de identidad y permisos On-Chain que define cómo se nombran las cuentas, qué estado almacenan, cómo se gestiona el acceso mediante permisos de clave granulares y cómo se relacionan con los contratos inteligentes en la Blockchain de NEAR.

En el contexto de la Blockchain, un "modelo de cuenta" se refiere al sistema que un protocolo utiliza para representar a los participantes on-chain: lo que contiene una cuenta, cómo se identifica, cómo autoriza transacciones y si puede ejecutar código. Ethereum utiliza un modelo de cuenta; Bitcoin utiliza un paradigma completamente diferente (el modelo UTXO, donde los saldos se rastrean como salidas de transacción no gastadas en lugar de saldos de cuenta). NEAR utiliza un modelo basado en cuentas, pero su implementación difiere significativamente de la de Ethereum en aspectos que son importantes tanto para la usabilidad como para el desarrollo de aplicaciones.

Una cuenta de NEAR contiene cinco elementos simultáneamente: un ID de cuenta único, un saldo de Token NEAR, el estado de la cuenta (almacenamiento de datos On-Chain), un contrato inteligente desplegado opcional compilado en WebAssembly (WASM, lo que permite contratos escritos en Rust o JavaScript) y una o más claves de acceso con distintos niveles de permisos. Esta estructura unificada significa que no hay separación entre las "cuentas de usuario" y las "cuentas de contrato inteligente" como ocurre en Ethereum. Cualquier cuenta de NEAR puede alojar opcionalmente un contrato inteligente sin convertirse en una categoría de objeto diferente. Las cuentas sin contratos desplegados funcionan como cuentas de usuario ordinarias; las cuentas con contratos desplegados son simultáneamente cuentas de usuario y anfitriones de contratos.

El contexto práctico para comprender por qué esto es importante es la aplicación descentralizada (dApp), una aplicación de software que se ejecuta en una red blockchain en lugar de en servidores centralizados. La arquitectura de cuentas de NEAR se diseñó para que las interacciones con las dApps sean más seguras y accesibles de lo que permiten los modelos de cuentas de blockchain existentes. El sistema de ID de cuenta es donde esta filosofía de diseño resulta más visible de inmediato, y ahí es donde comienza el recorrido por la arquitectura.

Para consultar la especificación técnica completa, consulta la documentación del modelo de cuentas de NEAR Protocol en docs.near.org/concepts/basics/accounts/model.

Cuentas con nombre y cuentas implícitas: cómo NEAR identifica a los usuarios

NEAR identifica usuarios y aplicaciones On-Chain mediante dos formatos de cuenta: cuentas con nombre, que utilizan cadenas de texto legibles como alice.near, y cuentas implícitas, que son cadenas hexadecimales de 64 caracteres derivadas de una Clave pública.

Cuentas con nombre: Identidades Legibles Blockchain

Cuentas con nombre en NEAR son identificadores de cuenta legibles por humanos que siguen una estructura similar a un dominio, terminando en .near en mainnet y .testnet en testnet, reemplazando las cadenas hash criptográficas utilizadas por blockchains como Ethereum.

El contraste es inmediato: alice.near frente a 0x742d35Cc6634C0532925a3b844Bc454e4438f44e. Ambos son identificadores de blockchain válidos, pero uno es legible y el otro requiere una cuidadosa verificación de Copiar y pegar. Piensa en una cuenta con nombre de NEAR como una dirección de correo electrónico: legible y ligada a una identidad, en lugar de una cadena aleatoria de caracteres que requiere una comparación carácter por carácter para verificar.

Las cuentas con nombre siguen reglas de nomenclatura específicas: los ID de cuenta son cadenas alfanuméricas, pueden usar puntos como separadores, deben tener entre 2 y 64 caracteres y deben terminar en .near en Mainnet o en .testnet en la red de prueba. La estructura separada por puntos crea una jerarquía similar a la de un dominio: myapp.near es una cuenta con nombre de nivel superior y contract.myapp.near es una subcuenta dentro de ella (más información sobre las subcuentas en la siguiente sección).

La razón de ser de la experiencia de usuario (UX) de las cuentas con nombre va más allá de la estética. Los identificadores legibles reducen el riesgo de enviar transacciones a cuentas incorrectas, hacen que las direcciones de contratos sean descubribles y disminuyen la carga cognitiva de gestionar identidades On-Chain. Para cualquiera que haya revisado tres veces una dirección de MetaMask antes de enviar una transacción, el atractivo de alice.near frente a una cadena hexadecimal de 42 caracteres es concreto en lugar de abstracto. Los usuarios registran y gestionan cuentas con nombre a través de MyNEARWallet en mynearwallet.com, la interfaz de cuenta principal mantenida por la comunidad (la original wallet.near.org operada por NEAR Foundation ha sido descontinuada).

Cuentas implícitas: El formato de cuenta alternativo

Las cuentas implícitas son el segundo formato de cuenta en NEAR: cadenas hexadecimales en minúscula de 64 caracteres derivadas directamente de una clave pública, que se crean en cuanto se envían tokens NEAR a ese ID de cuenta sin necesidad de ninguna acción por parte de una cuenta ya existente.

La distinción práctica clave: una cuenta con nombre requiere una cuenta On-Chain existente para patrocinar su registro mediante una transacción, mientras que una cuenta implícita entra en existencia automáticamente cuando los fondos llegan a la ID de cuenta derivada. Esto hace que las cuentas implícitas sean útiles en contextos donde se necesita un arranque desde cero, o donde los nombres legibles por humanos no son necesarios. Los exchanges de Criptomoneda utilizan típicamente cuentas implícitas al acreditar depósitos de NEAR a los usuarios, generando una ID de cuenta única a partir de la Clave pública del usuario sin requerir una cuenta On-Chain preexistente.

Una aclaración que vale la pena hacer de forma clara: las cuentas implícitas no son anónimas. Se derivan de forma determinista a partir de una Clave pública y son completamente transparentes on-chain. El término "implícito" se refiere a cómo se deriva el ID de la cuenta (a partir de la propia clave, sin un paso de registro explícito), no a ninguna propiedad de privacidad.

Las cuentas con nombre y las cuentas implícitas establecen cómo NEAR identifica a los participantes On-Chain. Las cuentas también pueden contener otras cuentas bajo su espacio de nombres, y esa estructura jerárquica es donde aparecen las subcuentas.

Subcuentas: Organización Jerárquica de Cuentas en NEAR

Las subcuentas en NEAR funcionan como los subdominios en la web: al igual que docs.myapp.com y api.myapp.com son direcciones distintas bajo el dominio myapp.com, token.myapp.near y staking.myapp.near son cuentas blockchain distintas dentro del espacio de nombres myapp.near.

Una subcuenta es una cuenta cuyo ID existe bajo el espacio de nombres de una cuenta principal. La cuenta contract.myprotocol.near es una subcuenta de myprotocol.near. Solo la cuenta principal puede crear una subcuenta: myprotocol.near puede crear contract.myprotocol.near, pero ninguna otra cuenta puede crear una cuenta bajo ese espacio de nombres sin la autorización del principal.

Importante: Una cuenta principal no puede acceder a los fondos ni al estado de una subcuenta una vez que esta ha sido creada. Las subcuentas son cuentas totalmente independientes que solo comparten un espacio de nombres, no son subsidiarias controladas por una cuenta principal.

Esta independencia es un punto común de confusión. La relación padre-hijo se aplica solo en el momento de la creación. Una vez que contract.myprotocol.near existe, tiene sus propias claves de acceso, su propio balance de Token NEAR y su propio estado on-chain. La cuenta padre myprotocol.near no tiene privilegios especiales sobre él.

Para los desarrolladores de dApps, las subcuentas proporcionan un patrón de arquitectura práctico. Dado que cualquier cuenta de NEAR puede desplegar un contrato inteligente (compilado a WASM), las subcuentas se convierten en una forma natural de dar a cada componente del contrato un ID de cuenta legible y organizado. Un protocolo DeFi podría desplegar token.myprotocol.near para su contrato de Token, staking.myprotocol.near para su contrato de staking y governance.myprotocol.near para su contrato de gobernanza. Cada una es una cuenta distinta con su propio contrato, su propio estado y su propia gestión de claves, pero el espacio de nombres hace que la relación entre los componentes sea inmediatamente legible para cualquiera que lea la cadena. Para obtener instrucciones paso a paso sobre la creación de subcuentas, consulte la documentación de subcuentas de NEAR en NEAR sub-account documentation at docs.near.org/concepts/basics/accounts/model#named-accounts.)

Comprender cómo se nombran y organizan las cuentas sienta las bases para la siguiente capa arquitectónica: cómo se protegen y gestionan sus permisos mediante claves de acceso.

Claves de acceso de NEAR: Acceso total frente a permisos de llamada de función

Las claves de acceso NEAR son la capa de permisos que controla qué acciones se pueden realizar en una cuenta NEAR, y la característica arquitectónica más distintiva del sistema: una única cuenta NEAR puede contener múltiples pares de claves independientes simultáneamente, cada uno con su propio nivel de permisos.

Cómo funciona el sistema multillave de NEAR

A diferencia de la mayoría de las cuentas de blockchain, donde una sola clave privada lo controla todo, una única cuenta de NEAR puede albergar múltiples pares de claves independientes, cada uno de ellos asignado a un tipo de permiso específico, desde el control sin restricciones hasta interacciones de contrato de alcance limitado.

Las claves de acceso de NEAR utilizan pares de claves Ed25519 por defecto (con secp256k1 también soportado para compatibilidad con la cadena de herramientas de Ethereum). El sistema de permisos construido sobre estos pares de claves es lo que hace que el modelo de NEAR sea arquitectónicamente distinto. Piénsalo como un llavero: una Clave de Acceso Completo es la llave maestra que abre todas las cerraduras; una Clave de Acceso a Llamada de Función es una llave diseñada específicamente que solo abre una puerta concreta. Cada transacción firmada por cualquier clave de acceso en una cuenta consume gas pagado en tokens NEAR, pero las comisiones de transacción de NEAR son bajas y predecibles por diseño, en contraste con los precios de gas históricamente variables de Ethereum.

Para obtener más detalles sobre cómo añadir y gestionar las claves de acceso de forma programática, consulte la documentación de referencia de las claves de acceso de NEAR en docs.near.org/concepts/basics/accounts/access-keys.

Claves de acceso total: control de cuenta sin restricciones

Una Clave de acceso completo en NEAR es un par de claves que puede realizar cualquier acción en la cuenta a la que está vinculada: transferir tokens, desplegar contratos inteligentes, crear subcuentas, añadir o eliminar otras claves y eliminar la propia cuenta.

Dado que una Clave de Acceso Completo controla toda la cuenta, conlleva el mismo perfil de riesgo que una contraseña maestra. Las Claves de Acceso Completo nunca deben compartirse con aplicaciones de terceros y deben almacenarse en almacenamiento en frío (billetera de hardware o almacenamiento sin conexión) para cualquier cuenta que contenga fondos significativos. Si una Clave de Acceso Completo se ve comprometida, el atacante tiene control total de la cuenta sin un mecanismo de recuperación nativo, a menos que se haya configurado uno de antemano.

La comparación con Ethereum es instructiva aquí. En Ethereum, tu única Clave privada para una Cuenta de Propiedad Externa (EOA) funciona como una Clave de Acceso Total: lo controla todo, y no hay una forma nativa de otorgar a una dApp una clave con permisos inferiores para una interacción de contrato específica. Cada conexión de dApp a través de MetaMask expone tu clave de cuenta completa al flujo de firma de transacciones. Esa limitación de clave única es precisamente el problema que la abstracción de cuentas EIP-4337 está diseñada para abordar en Ethereum. En NEAR, la solución se integró en el modelo de cuenta base.

Claves de Acceso para Llamadas a Funciones: Permisos Limitados para la Seguridad de dApps

Una clave de acceso de llamada a función es una clave restringida que solo puede llamar a métodos especificados en un contrato inteligente designado, con un límite opcional de asignación de gas que limita el gasto total de comisiones.

Mientras que una Clave de Acceso Completo no tiene restricciones, una Clave de Acceso para Llamada a Función está delimitada con precisión. La clave especifica: un ID de cuenta de contrato al que tiene permiso para llamar, qué métodos de ese contrato puede invocar (o todos los métodos públicos, si no hay más restricciones), y una asignación opcional de tokens NEAR que limita la cantidad de gas que la clave puede gastar antes de que requiera recarga. Una vez que la asignación se agota, la clave no puede firmar más transacciones hasta que se recargue o reemplace.

El caso de uso de autenticación basada en sesiones es donde las Function Call Access Keys muestran su valor práctico para el desarrollo de dApps. Cuando conectas una dApp a tu cuenta de NEAR, la dApp solicita una Function Call Access Key limitada a su propio contrato. Esta clave se almacena en la sesión de tu navegador. A partir de ese momento, la dApp puede enviar transacciones en tu nombre (aprobar un Trade, acuñar un NFT, interactuar con un contrato de juego) sin pedirte que firmes cada acción individual. Tu Full Access Key nunca sale de tu billetera segura. Si la dApp se ve comprometida o es maliciosa, el daño es limitado: el atacante solo puede llamar a los métodos de contrato específicos para los que se definió la clave, y solo hasta el importe permitido. Una Function Call Access Key funciona como un Token de sesión en una aplicación web: otorga acceso temporal y limitado a acciones específicas sin exponer las credenciales completas de la cuenta.

Las claves de acceso controlan qué acciones puede realizar una cuenta. El staking de almacenamiento determina lo que una cuenta debe mantener para existir On-Chain.

Staking de Almacenamiento: Por qué las cuentas NEAR requieren un saldo mínimo

El staking de almacenamiento en NEAR es el mecanismo por el cual cada cuenta debe mantener un saldo mínimo de NEAR token proporcional a la cantidad de almacenamiento on-chain (estado) que utiliza la cuenta.

El mecanismo funciona de la siguiente manera: NEAR asigna almacenamiento On-Chain medido en bytes. Por cada byte de estado almacenado en una cuenta (registros de saldo, código de contrato, datos almacenados, claves de acceso), se debe mantener una cantidad correspondiente de tokens NEAR en el saldo de la cuenta. Esos tokens no se gastan ni se destruyen; se reservan como un saldo bloqueado contra la huella de almacenamiento. Si reduces el almacenamiento de tu cuenta eliminando estado o datos del contrato, los tokens correspondientes se desbloquean y se devuelven a tu saldo disponible. El staking de almacenamiento funciona como un depósito de seguridad reembolsable: bloqueas una cantidad proporcional de tokens NEAR para el almacenamiento que utiliza tu cuenta, y recuperas esos tokens si reduces tu huella de almacenamiento.

El propósito de este diseño es económico: evita el exceso de datos en el estado (state bloat) al garantizar que la parte que se beneficia del almacenamiento On-Chain asuma el coste de dicho almacenamiento. Sin un mecanismo como este, una red Blockchain puede acumular cantidades ilimitadas de estado muerto procedente de cuentas o contratos abandonados, lo que degrada el rendimiento para todos los participantes.

En términos concretos, la tasa de staking de almacenamiento es aproximadamente 1 Token NEAR por cada 10 KB de almacenamiento on-chain, y una cuenta NEAR vacía recién creada requiere un saldo mínimo de aproximadamente 0,00182 NEAR para cubrir su huella de estado base. Verifica las cifras actuales consultando la documentación sobre staking de almacenamiento de NEAR en docs.near.org/concepts/storage/storage-staking) antes de basar la planificación de tu desarrollo en estas cifras, ya que los parámetros del protocolo cambian con las actualizaciones.

Para los desarrolladores de contratos inteligentes, la implicación del staking de almacenamiento requiere una planificación activa. Cuando una cuenta de NEAR despliega un contrato, el propio código del contrato ocupa almacenamiento en el estado de la cuenta. Un binario de contrato más grande requiere un saldo reservado proporcionalmente mayor. Si su contrato almacena datos significativos (registros de usuarios, saldos de Token, votos de gobernanza), la cuenta que aloja ese contrato debe mantener un saldo lo suficientemente grande como para cubrir tanto el código del contrato como el estado acumulado. Se trata de un requisito de capital que escala con el uso de la aplicación y que debe tenerse en cuenta en su modelo económico antes del despliegue.

El staking de almacenamiento genera un requisito real de inmovilización de capital. Algunos desarrolladores encuentran esto restrictivo en comparación con las cadenas que no requieren saldos de almacenamiento reservados. El Trade-off es deliberado: la restricción evita que el estado de la red crezca de forma ilimitada y los tokens son recuperables. No obstante, la restricción es real y debe planificarse en lugar de descubrirse después del despliegue.

staking de almacenamiento frente a staking de validador: Estos son dos mecanismos distintos en NEAR. El staking de almacenamiento bloquea tokens NEAR en relación con la huella de datos On-Chain de tu cuenta; esos tokens actúan como un saldo reservado proporcional al almacenamiento utilizado. El staking de validador bloquea tokens NEAR frente al Mecanismo de Consenso, donde los validadores hacen staking de tokens para participar en la producción de bloques y ganar recompensas de staking. Este artículo trata únicamente sobre el staking de almacenamiento. No confundas estos dos usos de la palabra «staking».

Las comisiones de gas (costes de ejecución de transacciones) son distintas del staking de almacenamiento. Las comisiones de gas se consumen por transacción y se pagan en tokens NEAR en el momento de la firma; el staking de almacenamiento es un saldo reservado que persiste con la cuenta mientras exista el estado asociado.

Entender el staking de almacenamiento completa la visión de cómo funcionan las cuentas de NEAR de forma aislada. La siguiente pregunta es cómo se compara esta arquitectura con la de Ethereum.

Modelo de Cuenta NEAR vs. Ethereum: Una comparativa lado a lado

NEAR y Ethereum adoptan enfoques fundamentalmente diferentes en cuanto a la arquitectura de cuentas On-Chain, y las diferencias tienen consecuencias importantes en la forma en que los desarrolladores crean aplicaciones descentralizadas y en cómo los usuarios gestionan sus identidades On-Chain.

El sistema de dos cuentas de Ethereum frente al modelo de cuentas unificado de NEAR

La tabla siguiente contrasta los dos modelos de cuenta en ocho dimensiones arquitectónicas. La diferencia más significativa es que Ethereum separa las cuentas de usuario (Cuentas de Propiedad Externa, o EOAs) de las cuentas de contrato inteligente en dos tipos distintos, mientras que NEAR usa un único tipo de cuenta unificado para ambos.

La separación entre las EOA y las cuentas de contrato de Ethereum genera fricciones en la práctica. La mayoría de las interacciones con dApps requieren que una EOA llame a una cuenta de contrato, lo que significa que los usuarios deben gestionar ambos tipos como entidades distintas. Una EOA está controlada por una única clave privada sin una forma nativa de delimitar los permisos: cualquier dApp conectada a una cuenta de MetaMask puede solicitar firmas que expongan la clave completa de la cuenta al flujo de la transacción. El modelo de Ethereum tiene una lógica de diseño clara y cumplió bien sus objetivos originales, pero la limitación de la clave única se hizo evidente a medida que las interacciones con dApps se volvieron más frecuentes y variadas.

El tipo de cuenta unificado de NEAR elimina la separación EOA/contrato. Cada cuenta de NEAR es potencialmente un host de contrato, y el sistema multillave con Claves de Acceso a Llamadas de Función aborda la limitación de clave única sin requerir una capa de protocolo separada. Tanto NEAR como Ethereum operan en el paradigma basado en cuentas, en contraste con el modelo UTXO de Bitcoin, donde los saldos se rastrean como salidas de transacciones no gastadas en lugar de como estado de cuenta; la diferencia entre NEAR y Ethereum radica en cómo se estructuran y gestionan los permisos de esas cuentas, no en el paradigma fundamental.

Modelo de Cuentas de NEAR y Abstracción de Cuentas de Ethereum (EIP-4337)

EIP-4337 (abstracción de cuentas) es el esfuerzo de Ethereum por dotar a las EOA de las capacidades de permisos programables y de claves de sesión que el modelo de cuenta de NEAR fue diseñado para incluir desde el principio.

EIP-4337 es un estándar de Ethereum activo (no una propuesta teórica) que permite que las billeteras de contrato inteligente funcionen como ciudadanos de primera clase, admitiendo validación de transacciones programable, claves de sesión, recuperación social y transacciones patrocinadas. Requiere una infraestructura de bundlers específica para operar y está activamente desplegado en todo el ecosistema de Ethereum, aunque no es una actualización universal aplicada a todas las cuentas automáticamente.

El paralelismo con las Claves de Acceso de Llamada de Función de NEAR es real: ambos enfoques abordan el problema de otorgar a las dApps acceso con permisos limitados y de ámbito reducido para interacciones específicas sin exponer la clave de cuenta completa. Un desarrollador familiarizado con las claves de sesión de EIP-4337 encontrará las Claves de Acceso de Llamada de Función de NEAR conceptualmente familiares. El matiz importante es que estas son implementaciones arquitectónicamente distintas de ideas superpuestas, no sistemas idénticos. El modelo de permisos multiclave de NEAR es nativo del protocolo base; EIP-4337 superpone la lógica de billetera de contrato inteligente sobre el modelo EOA existente de Ethereum. Los problemas que abordan se solapan significativamente; los mecanismos difieren. Para la especificación completa de EIP-4337, consulte la especificación de abstracción de cuentas de EIP-4337 en eips.ethereum.org/EIPS/eip-4337.

Para los desarrolladores de Ethereum que estén evaluando NEAR, vale la pena destacar dos puentes del ecosistema. Aurora en aurora.dev, un entorno compatible con la EVM construido sobre NEAR, permite a los desarrolladores de Ethereum desplegar contratos Solidity en la infraestructura de NEAR, mientras que las cuentas de NEAR actúan como la capa de identidad subyacente. Los desarrolladores que trabajen en ambos ecosistemas pueden utilizar Rainbow Bridge en rainbowbridge.app para transferir activos entre cuentas de NEAR y direcciones de Ethereum sin depender de una custodia de tipo Centralizado.

Ahora que la arquitectura está clara, esto es lo que implica realmente en la práctica crear y gestionar una cuenta de NEAR.

--- ## Primeros pasos: Creación y gestión de tu cuenta NEAR

Puedes crear tu primera cuenta de NEAR a través de MyNEARWallet en mynearwallet.com, la interfaz principal mantenida por la comunidad para el registro de cuentas de NEAR y la gestión de claves. Verifica la recomendación actual del monedero oficial en el momento en que leas esto, ya que el ecosistema de monederos de NEAR sigue evolucionando; existen otras aplicaciones de monedero compatibles además de MyNEARWallet.

Si vienes de Ethereum y MetaMask, la diferencia conceptual merece la pena entenderla antes de empezar. Un monedero MetaMask es principalmente un gestor de claves y firmante de transacciones para EOAs de Ethereum: almacena tu Clave privada y la presenta a las dApps para la firma de transacciones. Una cuenta NEAR es una identidad completa On-Chain con un nombre legible, almacenamiento de estado On-Chain, permisos de clave programables y alojamiento de contratos opcional. La aplicación del monedero (MyNEARWallet) es la interfaz; la cuenta NEAR es el objeto On-Chain. Son cosas diferentes, y la distinción es importante para cómo piensas en la gestión de claves.

Crear una cuenta de NEAR requiere un pequeño saldo inicial de Token NEAR para cubrir el requisito de staking de almacenamiento base (aproximadamente 0,00182 NEAR para una cuenta vacía, tal como se explica en la sección de Staking de almacenamiento anterior). Este saldo inicial cubre la huella de estado base de una nueva cuenta.

Hay tres riesgos que conviene conocer antes de empezar. Primero, si pierde su Clave de Acceso Completo sin ningún mecanismo de recuperación configurado, la cuenta no se podrá recuperar. Guarde su Clave de Acceso Completo en almacenamiento en frío y configure cualquier opción de recuperación disponible antes de que la necesite. Segundo, los tokens NEAR reservados para el staking de almacenamiento permanecen bloqueados mientras exista el estado asociado; esto es un compromiso de capital, no una tarifa. Tercero, la eliminación de cuentas en NEAR es irreversible. Para obtener una guía completa paso a paso sobre la creación de cuentas, consulte la documentación para desarrolladores de NEAR en docs.near.org/concepts/basics/accounts/model.

A continuación, se responden las preguntas más frecuentes sobre el modelo de cuenta NEAR.

Preguntas Frecuentes: Modelo de Cuenta NEAR

Las preguntas siguientes abordan los puntos de confusión más comunes sobre el modelo de cuentas de NEAR, con referencias cruzadas a las secciones pertinentes de arriba para los lectores que deseen una cobertura completa.

¿Puede cualquier cuenta de NEAR implementar un contrato inteligente?

Sí. En NEAR, cualquier cuenta puede implementar opcionalmente un contrato inteligente compilado a WebAssembly (WASM). No existe un tipo de cuenta de contrato separado, a diferencia de Ethereum, donde la implementación de un contrato requiere la creación de una Cuenta de Contrato distinta. Una cuenta sin un contrato implementado funciona como una cuenta de usuario estándar; una cuenta con un contrato implementado funciona como ambas simultáneamente. Consulte la sección ¿Qué es el modelo de cuentas de NEAR? anterior para obtener la explicación arquitectónica completa.

¿Cómo hacen las claves de acceso de NEAR que las dApps sean más seguras de usar?

Las Claves de acceso de llamada a funciones restringen una dApp a métodos de contrato específicos con un límite opcional de asignación de gas. Cuando te conectas a una dApp utilizando una Clave de acceso de llamada a funciones limitada al contrato de esa dApp, tu Clave de acceso total (y el saldo total de tu cuenta) nunca se exponen a la aplicación de un Tercero. Si la dApp se ve comprometida, el daño se limita a la asignación y al contrato especificado. Consulta la sección de Claves de acceso de NEAR para ver el desglose completo.

¿Qué ocurre si pierdo mi Clave de acceso total?

La pérdida de una Clave de Acceso Total sin un mecanismo de recuperación preconfigurado hace que la cuenta sea permanentemente irrecuperable. No puedes restablecer ni recuperar una Clave de Acceso Total de la misma forma que restableces una contraseña, ya que no existe ninguna autoridad central que controle la cuenta. Guarda siempre las Claves de Acceso Total en un almacenamiento en frío seguro y configura cualquier opción de recuperación de cuenta disponible a través de tu aplicación de monedero antes de que las necesites. Algunos monederos ofrecen configuraciones de recuperación social o de recuperación multiclave.

¿Son las comisiones de gas lo mismo que el staking de almacenamiento?

No. Las tarifas de gas son costes de ejecución por transacción que se consumen en el momento en que se firma una transacción; se pagan en tokens NEAR y no persisten una vez completada la transacción. El staking de almacenamiento es un saldo mínimo reservado de tokens NEAR que persiste con la cuenta mientras exista el estado On-Chain asociado. Ambos involucran tokens NEAR, pero operan como mecanismos totalmente independientes. Consulte la sección de Staking de Almacenamiento para obtener la explicación completa.

¿Cómo se relaciona el modelo de cuentas de NEAR con la abstracción de cuentas de Ethereum (EIP-4337)?

El sistema nativo de permisos multiclave de NEAR logra muchos de los objetivos que el EIP-4337 busca añadir a Ethereum, incluyendo permisos basados en sesiones con alcance definido para interacciones con dApps y lógica de claves programable. Ambos son implementaciones arquitectónicamente distintas de ideas que se solapan: el enfoque de NEAR es nativo del protocolo base, mientras que el EIP-4337 añade una capa de lógica de monedero de contrato inteligente sobre el modelo EOA existente de Ethereum. Resuelven problemas similares mediante arquitecturas diferentes. Consulta la sección de comparación entre NEAR y Ethereum para un análisis detallado.

¿Cuál es la diferencia entre una cuenta con nombre y una cuenta implícita en NEAR?

Las cuentas nombradas son identificadores legibles por humanos (por ejemplo, alice.near) registradas mediante una transacción desde una cuenta existente, que terminan en .near en mainnet y .testnet en testnet. Las cuentas implícitas son cadenas hexadecimales de 64 caracteres derivadas directamente de una Clave pública, que se crean automáticamente cuando se envían tokens NEAR a ese ID de cuenta, sin requerir ninguna transacción de registro. Consulte la Sección Cuentas Nombradas y Cuentas Implícitas para ver la tabla comparativa completa.

¿Cuántas claves de acceso puede contener una sola cuenta NEAR?

Una cuenta NEAR puede tener varias claves de acceso simultáneamente, cada una con su propio tipo de permiso (Clave de Acceso Completo o Clave de Llamada a Función) y, para las Claves de Llamada a Función, su propio ámbito de contrato y asignación de gas. No existe un límite máximo documentado para el número de claves por cuenta. Esta capacidad de claves múltiples es lo que distingue el modelo de permisos de NEAR del enfoque de Ethereum de una sola clave por EOA (Cuenta Controlada por Externo). Consulte la sección Claves de Acceso NEAR para obtener más detalles.

¿Significa el staking de almacenamiento que pierdo mis tokens NEAR?

No. Los tokens NEAR reservados para el staking de almacenamiento están bloqueados pero no gastados. Permanecen en tu cuenta como un saldo reservado y se liberan de vuelta a tu saldo disponible si reduces la huella de datos on-chain de tu cuenta eliminando estado. Los tokens son un depósito contra el uso de almacenamiento, no una tarifa. Consulta la sección Staking de almacenamiento para ver el mecanismo y las cifras actuales.

Conclusión: Qué significa el modelo de cuentas NEAR para desarrolladores y usuarios

El modelo de cuenta NEAR refleja una serie de decisiones arquitectónicas deliberadas: los nombres de cuenta legibles por humanos reducen la barrera de entrada y disminuyen los errores de transacción; un sistema de permisos multiclave reduce el riesgo de seguridad para las interacciones de dApps al delimitar el acceso de terceros sin exponer las claves maestras; el 'staking' de almacenamiento crea una alineación económica entre el uso de recursos y el coste; y una estructura unificada de cuenta-contrato elimina la separación entre EOA (cuenta controlada externamente) / contrato que añade fricción al desarrollo en Ethereum.

El requisito de saldo mínimo para el staking de almacenamiento es una restricción real que debe planificarse, no una mera nota al pie. Si su aplicación almacena un estado On-Chain significativo, el requisito de saldo reservado aumentará proporcionalmente a dicho estado. Inclúyalo en el presupuesto del modelo económico de su aplicación antes del despliegue, no después.

Próximos pasos por persona:

• Desarrolladores: Comienza a desarrollar en NEAR Protocol en docs.near.org/develop
• Usuarios: Crea tu cuenta NEAR en MyNEARWallet en mynearwallet.com
• Investigadores: Profundiza en la especificación completa del modelo de cuentas en Documentación del modelo de cuentas de NEAR Protocol en docs.near.org/concepts/basics/accounts/model

Las especificaciones técnicas de este artículo reflejan NEAR Protocol en el momento de su redacción. NEAR Protocol se desarrolla activamente; verifique las cifras actuales consultando docs.near.org antes de basarse en valores numéricos específicos para la planificación de desarrollo u operativa. Este contenido es solo para fines informativos y no constituye asesoramiento financiero o de inversión.