Explicación del modelo de cuentas de NEAR: claves y almacenamiento

El Modelo de Cuentas de NEAR es el sistema a nivel de protocolo de NEAR Protocol para gestionar la identidad y los permisos de las cuentas junto con el estado On-Chain. Cada cuenta en NEAR tiene un ID de cuenta legible por humanos, puede tener múltiples claves de acceso con diferentes ámbitos de permisos y puede almacenar simultáneamente tanto un saldo de Token como un Contrato inteligente desplegado. Las blockchains gestionan el valor y la identidad a través de diferentes sistemas (Bitcoin utiliza un modelo de Salida de Transacción No Gastada, o UTXO, mientras que Ethereum y NEAR utilizan un modelo basado en cuentas donde cada cuenta mantiene el estado directamente), y el diseño basado en cuentas de NEAR es lo que hace posible la arquitectura que se cubre aquí.

NEAR Protocol es una Layer 1 Blockchain de proof-of-stake (PoS) que lanzó su mainnet en 2020. Fue creada por NEAR Inc. (que ahora opera como Pagoda), una organización de herramientas para desarrolladores que continúa manteniendo el NEAR SDK y la infraestructura del protocolo principal. NEAR Protocol utiliza el sharding Nightshade para particionar la red en shards paralelos, y los identificadores de cuenta desempeñan un papel en la asignación de shards, lo que es importante para los desarrolladores que piensan en patrones de llamadas entre contratos.

Cuatro propiedades diferencian el Modelo de Cuentas de NEAR de otros sistemas de cuentas de Layer 1:

• Los ID de cuenta son cadenas legibles por humanos, no secuencias hexadecimales aleatorias
• Una sola cuenta puede tener un número ilimitado de claves de acceso, cada una con su propio alcance de permiso
• Cualquier cuenta puede tener tanto un saldo de Token como un contrato inteligente desplegado, sin distinción arquitectónica entre "cuentas de usuario" y "cuentas de contrato"
• Las cuentas deben mantener un saldo de Token NEAR proporcional a su uso de almacenamiento On-Chain, un mecanismo denominado almacenamiento por staking

Este artículo aborda cada uno de estos componentes de forma secuencial: tipos de ID de cuenta, tipos de claves de acceso, staking de almacenamiento, subcuentas, la comparación con la arquitectura de Ethereum y un ejemplo práctico detallado.

Ir a una sección:

• ID de cuenta de NEAR: cuentas con nombre y cuentas implícitas
• Claves de acceso de NEAR: cómo funcionan los permisos de las cuentas
• Staking de almacenamiento: cómo vincula NEAR el saldo de Token al almacenamiento On-Chain
• Subcuentas de NEAR: espacios de nombres de cuentas jerárquicos
• Modelo de cuentas de NEAR frente a Ethereum: diferencias arquitectónicas clave
• Lo que la arquitectura de cuentas unificada de NEAR significa en la práctica
• Preguntas frecuentes sobre el modelo de cuentas de NEAR
• Conclusiones clave y próximos pasos

--- ## IDs de cuenta NEAR: Cuentas con nombre y Cuentas implícitas

Cada cuenta NEAR se identifica mediante un ID de cuenta único. A diferencia de Ethereum, donde las cuentas se identifican por una dirección hexadecimal de 42 caracteres derivada de una clave pública, los IDs de cuenta NEAR vienen en dos formas estructuralmente distintas: cuentas con nombre y cuentas implícitas. Comprender la diferencia entre ellas es la base para trabajar con el sistema de cuentas de NEAR.

Cuentas con nombre: Identificadores legibles por humanos

Una cuenta con nombre es un identificador de cuenta legible por humanos registrado bajo un dominio de nivel superior: .near en Mainnet, .testnet en la red de pruebas. Las cuentas con nombre funcionan como nombres de usuario de internet o nombres de dominio: son únicas, elegidas por el registrante y fáciles de compartir y recordar. Algunos ejemplos incluyen alice.near, myprotocol.near y nft.myprotocol.near. A diferencia de un nombre de usuario, una cuenta con nombre es un objeto a nivel de protocolo que mantiene un saldo de Token NEAR, puede tener un contrato inteligente desplegado en ella y controla claves de acceso criptográficas.

Registrar una cuenta con nombre requiere un pequeño Depósitos de token NEAR. Para crear una, visita una interfaz de billetera compatible con NEAR como MyNEARWallet o Meteor Wallet, elige tu ID de cuenta y realiza el Depósitos de registro. Las cuentas con nombre también pueden crear subcuentas dentro de su espacio de nombres (por ejemplo, alice.near puede crear app.alice.near), un tema cubierto en detalle en la sección de subcuentas a continuación.

Las cuentas con nombre son una característica nativa del protocolo integrada directamente en el modelo de cuentas de NEAR Protocol. No son un servicio de nombres externo superpuesto al protocolo, que es como funciona Ethereum Name Service (ENS) en Ethereum. ENS es un sistema de contratos inteligentes independiente; las cuentas con nombre de NEAR son una parte de primer nivel del propio protocolo.

Cuentas implícitas: derivadas de claves públicas

Una cuenta implícita es un ID de cuenta hexadecimal de 64 caracteres derivado de forma determinista de una clave pública Ed25519. Un ejemplo de ID de cuenta implícita es: 98793cd91a3f870fb126f66285808c7e094afcfc4b4a2ca57271d8b8b6a4a7c0. Para los desarrolladores que vienen de Ethereum, este es el tipo de cuenta estructuralmente más familiar, ya que el proceso de derivación es análogo a cómo se calculan las direcciones de Ethereum a partir de claves públicas.

La mecánica de creación de cuentas implícitas difiere de las cuentas nombradas en un aspecto clave: no se requiere una transacción de registro. Una cuenta implícita se activa en el momento en que alguien envía tokens NEAR a su ID de cuenta. Esto hace que las cuentas implícitas sean muy adecuadas para la creación programática de cuentas, las direcciones de Depósitos del exchange y escenarios donde la legibilidad humana no es una prioridad.

El descriptor "implícito" se refiere al mecanismo de creación, no al anonimato. Las cuentas implícitas son propiedad y están controladas en su totalidad por el poseedor de la Clave privada de la cual se derivó el ID de cuenta. Una distinción adicional: un ID de cuenta implícito se deriva de una Clave pública, pero no es idéntico a la Clave pública en sí misma. El ID de cuenta es una representación hexadecimal en minúsculas de los bytes brutos de la Clave pública. Los desarrolladores de Ethereum familiarizados con la derivación de direcciones reconocerán el patrón, pero no deben asumir que las dos representaciones son iguales.

Cuentas Nombradas vs. Implícitas: Una Comparación Lado a Lado

Los dos tipos de ID de cuenta se diferencian en cinco dimensiones:

Las cuentas con nombre son ideales para billeteras de usuario y despliegues de protocolo donde la legibilidad es importante. Las cuentas implícitas son adecuadas para exchanges, herramientas programáticas y escenarios donde las cuentas se crean masivamente sin interacción del usuario.

Claves de Acceso NEAR: Cómo Funcionan los Permisos de Cuenta

Las claves de acceso de NEAR son la capa de autorización del modelo de cuenta. Cada cuenta de NEAR puede tener varias claves de acceso simultáneamente, y cada clave tiene un ámbito de permiso distinto. Una cuenta de NEAR puede tener un número ilimitado de claves de acceso a la vez. Cada clave es un par de claves criptográficas Ed25519 independiente, y puedes añadir o eliminar claves sin crear una nueva cuenta. Las claves se añaden a través de una transacción firmada por una Clave de Acceso Completa existente, utilizando la NEAR CLI (near add-key) o mediante programación a través del SDK.

Esto difiere de Ethereum, donde una única clave privada controla cada dirección. El diseño multi-clave de NEAR permite un control de permisos más detallado sin comprometer la continuidad de la cuenta. NEAR admite dos tipos de claves: Claves de Acceso Completo y Claves de Acceso para Llamada a Función. Consulte la documentación del Protocolo NEAR sobre claves de acceso) para conocer la especificación técnica completa.

Claves de Acceso Completo: Credenciales Maestras

Una Full Access Key es una clave de acceso con permisos ilimitados sobre una cuenta. Puede autorizar transferencias de Tokens, el despliegue de un Contrato inteligente, añadir o eliminar otras claves y la eliminación de la cuenta. Piense en una Full Access Key como una llave maestra de su casa: abre todas las puertas. A diferencia de una llave de casa, una Full Access Key es un par de claves criptográficas que firma transacciones en la Blockchain de NEAR, por lo que se aplican las mismas prácticas de seguridad. Guárdela en un monedero de hardware o fuera de línea, por las mismas razones por las que los usuarios de Ethereum protegen sus frases semilla.

Una cuenta NEAR puede tener múltiples Claves de Acceso Completo. Una por dispositivo es un patrón común, y cada clave tiene el mismo nivel de permiso completo. Este es un punto arquitectónico importante: no existe una única "clave privada maestra" como la que tienen las cuentas de Ethereum. Múltiples Claves de Acceso Completo pueden coexistir en una sola cuenta simultáneamente.

Nota del desarrollador: Una Clave de Acceso de Llamada a Función comprometida no otorga permisos de Clave de Acceso Completo. Los ámbitos de permisos están arquitectónicamente separados a nivel de protocolo. La revocación de una Clave de Acceso de Llamada a Función no afecta a ninguna Clave de Acceso Completo en la misma cuenta, y viceversa.

Claves de Acceso de Llamada a Función: Permisos con ámbito para dApps

Una Clave de Acceso de Llamada a Función (Function Call Access Key) es una clave de acceso con ámbito que solo puede llamar a métodos específicos en un contrato específico, con una asignación opcional de Token NEAR que limita la cantidad de gas que la clave puede gastar. Piense en ello como un token de sesión o un permiso OAuth con ámbito: otorga a una aplicación específica el derecho de realizar acciones específicas en su nombre, sin darle acceso a su cuenta completa. A diferencia de un token OAuth, una Clave de Acceso de Llamada a Función es un par de claves criptográficas almacenado en la cadena, y los límites de sus permisos se aplican a nivel de protocolo, no por la aplicación.

Cuando conectas tu cuenta de NEAR a una aplicación descentralizada (dApp) y apruebas una clave de acceso de llamada a función, la dApp puede enviar ciertas transacciones automáticamente sin que aparezca una ventana emergente de confirmación del monedero para cada una. Esto permite una experiencia de usuario basada en sesiones en juegos, protocolos DeFi y aplicaciones sociales. En Ethereum, cada una de esas interacciones requeriría una confirmación de MetaMask por separado. En NEAR, el usuario aprueba la clave una sola vez y la dApp opera dentro de ese alcance durante la sesión.

Las claves de acceso a llamadas a funciones pueden conllevar un límite opcional de Token NEAR, que restringe la cantidad total de gas que la clave tiene permitido gastar. Una vez que este límite se agota, la clave ya no puede enviar transacciones hasta que el usuario la recargue o emita una nueva clave.

Concepto erróneo común: Otorgar una Clave de Acceso de Llamada a Función a una dApp no le da a la dApp control sobre tu cuenta. La clave está estrictamente limitada a métodos de contrato definidos y a una asignación de gas. No puede transferir tu saldo de Tokens NEAR, no puede desplegar contratos, ni añadir o eliminar otras claves en tu cuenta.

Nota del desarrollador: Las Function Call Access Keys permiten patrones de claves de sesión en dApps. Un usuario puede autorizar una clave para una sesión de juego o una sesión de trading de DeFi, y la aplicación opera dentro de ese ámbito sin requerir aprobaciones por cada transacción. Esta es una de las diferencias de UX más relevantes para los desarrolladores al construir en NEAR frente a Ethereum.

Full Access Key frente a Function Call Access Key: Diferencias clave

Las claves de acceso total y las claves de acceso para llamadas a funciones se diferencian en seis dimensiones:

Las Claves de Acceso Completo pertenecen al propietario de la cuenta y deben conservarse sin conexión o en hardware. Las Claves de Acceso de Llamada a Función se emiten a aplicaciones y pueden ser revocadas por el propietario de la cuenta en cualquier momento.

Staking de almacenamiento: Cómo NEAR vincula el saldo de Token al almacenamiento de On-Chain

El staking de almacenamiento es un componente de la arquitectura de cuentas de NEAR que la mayoría de los recursos educativos sobre blockchain omiten, pero tiene implicaciones prácticas directas para cada desarrollador que construye en NEAR y cada usuario que gestiona una cuenta.

Por qué NEAR requiere un saldo de Token para el almacenamiento

Definición: El storage staking (también conocido como state staking en parte de la documentación de NEAR) es el requisito de que las cuentas de NEAR mantengan un saldo de Token NEAR proporcional a la cantidad de datos On-Chain que almacenan. Este saldo bloqueado actúa como un Depósitos reembolsable, no como una comisión.

El staking de almacenamiento funciona como un depósito de seguridad para un apartamento. Tus tokens NEAR se bloquean en proporción al espacio de almacenamiento que ocupas y se te devuelven cuando eliminas esos datos almacenados. A diferencia del pago de un alquiler, los tokens no se transfieren a nadie; permanecen en tu cuenta, simplemente reservados en función del almacenamiento que ocupas.

Una distinción que vale la pena aclarar: el staking de almacenamiento no es lo mismo que el staking de validador. Ambos mecanismos bloquean tokens NEAR, pero cumplen propósitos completamente diferentes. El staking de validador bloquea tokens para participar en la producción de bloques y obtener recompensas de consenso. El staking de almacenamiento bloquea tokens de forma proporcional al uso de almacenamiento On-Chain para evitar la hinchazón del estado (state bloat) y alinear el coste del almacenamiento con las entidades que lo consumen. Son saldos bloqueados independientes con propósitos separados.

El staking de almacenamiento también está separado de las tarifas de gas. Las tarifas de gas son costes de ejecución por transacción pagados en tokens NEAR y quemados después de cada transacción. El staking de almacenamiento es un requisito de saldo continuo vinculado a la cantidad de datos que tiene una cuenta, no al número de transacciones que envía.

Staking de Almacenamiento en la Práctica: Qué Significa para las Cuentas y los Contratos

El staking de almacenamiento afecta a las cuentas en tres niveles:

• Creación de cuenta: requiere un saldo mínimo de Token NEAR. La tasa actual es de aproximadamente 0,00182 NEAR por byte de estado (consulta las tasas actuales en la documentación oficial de staking de almacenamiento de NEAR antes de tomar decisiones de desarrollo, ya que la gobernanza del protocolo puede ajustar esta cifra).
• Despliegue de contratos: requiere unos Depósitos proporcionalmente mayores en función del tamaño del contrato compilado. El bytecode WASM del contrato se almacena On-Chain como parte del estado de la cuenta, y los Depósitos de almacenamiento escalan con ese tamaño.
• Datos de estado del contrato: los datos almacenados en el estado del contrato (como los saldos de los usuarios en un contrato de Token o el estado del juego en un juego On-Chain) requieren un saldo continuo mantenido por quien controle la cuenta del contrato.

Si el saldo de una cuenta de NEAR cae por debajo de su requisito de almacenamiento, la cuenta no podrá realizar transacciones salientes hasta que se recargue el saldo. La cuenta no se elimina y sus datos no se pierden; simplemente queda inactiva para transacciones salientes hasta que se depositen suficientes tokens NEAR.

Nota del desarrollador: decide pronto si tu aplicación adelantará los Depósitos por almacenamiento para los usuarios durante su incorporación o si requerirá que los usuarios mantengan su propio saldo. Muchos protocolos absorben los costes de almacenamiento para reducir la fricción. Esta es una decisión real sobre la economía del proceso de incorporación que afecta a la adquisición de usuarios, así que tenla en cuenta en el modelo de costes de tu dApp antes del lanzamiento.

Subcuentas de NEAR: espacios de nombres de cuentas jerárquicos

Una subcuenta de NEAR es una cuenta cuya ID tiene como prefijo la ID de una cuenta principal. Por ejemplo, app.alice.near es una subcuenta de alice.near, y solo alice.near puede crear cuentas en ese espacio de nombres.

Un detalle importante a precisar: después de crear una subcuenta, la cuenta principal NO la controla. La subcuenta es completamente independiente: tiene sus propias claves de acceso, su propio saldo de Token NEAR y su propio estado On-Chain. La única autoridad especial de la cuenta principal es la capacidad de crear subcuentas en su espacio de nombres. Más allá de ese acto de creación, las dos cuentas no tienen ninguna relación de control en curso.

La jerarquía de nombres se asemeja a la de dominios y subdominios web. alice.near es como un dominio, y app.alice.near es como un subdominio. Al igual que registrar un dominio no te otorga control continuo sobre el contenido alojado en sus subdominios, crear una subcuenta no confiere a la cuenta principal autoridad sobre cómo se utiliza esa subcuenta posteriormente.

Un patrón de uso típico para los equipos de protocolos es el siguiente:

myprotocol.near → token.myprotocol.near → staking.myprotocol.near → dao.myprotocol.near

Cada subcuenta se controla de forma independiente tras su creación. Cada una tiene sus propias claves de acceso, posee su propio saldo y puede tener un contrato inteligente independiente desplegado en ella. La creación se inicia por la cuenta principal, ya sea a través de la NEAR CLI o mediante programación a través de una llamada a contrato. Tras esa transacción, el control se transfiere completamente a quien posea las claves de acceso de la nueva subcuenta.

Concepto erróneo común: La cuenta principal no rige las subcuentas después de su creación. Las subcuentas son cuentas totalmente autónomas a nivel de protocolo. La convención de nomenclatura refleja quién las creó, no quién las controla.

Nota del desarrollador: Las subcuentas son un patrón estándar para la arquitectura de protocolos modulares. El despliegue de contratos independientes en subcuentas separadas proporciona a cada módulo una gestión de claves de acceso independiente, rutas de actualización independientes y un aislamiento de permisos más claro. Muchos protocolos de NEAR en producción utilizan este patrón para contratos de Token, módulos de gobernanza y lógica de staking.

Modelo de Cuenta NEAR frente a Ethereum: Principales Diferencias Arquitectónicas

El modelo de cuenta de NEAR y el modelo de cuenta de Ethereum adoptan diferentes enfoques arquitectónicos para los mismos problemas: cómo identificar cuentas, cómo autorizar transacciones y cómo desplegar contratos inteligentes. Para los desarrolladores que evalúan NEAR como una plataforma de desarrollo, comprender estas diferencias es un requisito previo para tomar decisiones de arquitectura fundamentadas.

Ethereum separa las cuentas en dos tipos: Cuentas Poseídas Externamente (EOA) y Cuentas de Contrato. Una EOA está controlada por una única clave privada y no puede alojar código desplegado. Una Cuenta de Contrato está controlada por código y no tiene clave privada. Esta separación significa que si deseas que una dirección de Ethereum tanto posea ETH como ejecute lógica de contrato inteligente, necesitas dos objetos de cuenta separados que trabajen juntos.

NEAR utiliza un modelo unificado. Cualquier cuenta de NEAR puede tener un saldo de Token y un contrato inteligente desplegado de forma simultánea. No existe un tipo de "cuenta de contrato" independiente. La cuenta alice.near puede tener Tokens NEAR, ejecutar un contrato WASM desplegado y mantener múltiples claves de acceso con diferentes alcances de permisos, todo ello como un único objeto de protocolo. Cualquier cuenta de NEAR puede albergar un contrato inteligente, un saldo de Token y múltiples claves de acceso al mismo tiempo.

Las cuentas de Ethereum están controladas cada una por una Clave privada. Las cuentas de NEAR admiten múltiples claves de acceso con diferentes ámbitos de permisos, lo que permite patrones como las claves de sesión y la gestión de claves multidispositivo que el modelo de cuentas de Ethereum no soporta de forma nativa a nivel de protocolo.

Nota: los contratos inteligentes compatibles con Ethereum pueden ejecutarse en NEAR a través de Aurora, una capa de compatibilidad con EVM desplegada como un contrato inteligente en NEAR. Aurora es una capa independiente; el desarrollo nativo de NEAR utiliza WebAssembly (WASM) compilado desde Rust o JavaScript, no Solidity. Consulta la documentación del modelo de cuentas de Ethereum para obtener la especificación completa de las cuentas de Ethereum.

Qué significa en la práctica la arquitectura de cuentas unificada de NEAR

Los componentes del Modelo de Cuentas de NEAR (ID de cuenta, claves de acceso, staking de almacenamiento y subcuentas) forman un sistema unificado que genera diferencias concretas en cómo se comportan las aplicaciones y en la experiencia de los usuarios con ellas.

Considera una única cuenta NEAR, alice.near. La cuenta de Alice puede simultáneamente:

1. Mantener un saldo del token NEAR
2. Tener un contrato inteligente desplegado, compilado a WebAssembly (WASM) desde Rust
3. Portar tres claves de acceso: una clave de acceso total almacenada en su monedero de hardware, una clave de acceso total en su ordenador portátil y una clave de acceso de llamada a función otorgada a una dApp DeFi para el trading basado en sesiones
4. Poseer dos subcuentas (app.alice.near para un contrato de juego desplegado y vault.alice.near para un contrato de ahorros), cada una controlada de forma independiente

El ID de la cuenta de Alice es legible y se puede compartir. Ella nunca tiene que copiar una cadena hexadecimal de 42 caracteres para recibir tokens o interactuar con un contrato.

Para los desarrolladores, las implicaciones prácticas son sustanciales. Los patrones de claves de sesión eliminan la fricción del monedero en cada transacción en juegos y aplicaciones sociales. La arquitectura de subcuentas permite a los equipos de protocolos desplegar contratos modulares con rutas de actualización independientes. El staking de almacenamiento crea un modelo de costes predecible para los datos On-Chain que debe tenerse en cuenta en la economía de incorporación. Las cuentas también pueden interactuar con el Rainbow Bridge para transferir activos entre NEAR y Ethereum, y se gestionan a través de interfaces de monedero compatibles con NEAR, como MyNEARWallet o Meteor Wallet.

Para los usuarios finales, el modelo de cuenta se traduce en identificadores de cuenta legibles que funcionan como nombres de usuario, sesiones de dApp que no interrumpen la experiencia con ventanas emergentes del monedero y un modelo de rotación de claves que permite la recuperación de la cuenta sin depender de una única frase semilla.

Preguntas frecuentes sobre el modelo de cuentas de NEAR

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

Las cuentas con nombre son identificadores legibles por humanos (como alice.near) registrados bajo un dominio de nivel superior, requieren un pequeño Depósito de Token NEAR al registrarse y son elegidos por el usuario. Las cuentas implícitas son IDs hexadecimales de 64 caracteres derivados de una Clave pública Ed25519, no requieren registro y se activan automáticamente cuando se envían Tokens NEAR al ID de cuenta. Las cuentas con nombre son típicas para carteras de usuario y despliegues de protocolos; las cuentas implícitas son comunes para exchanges y herramientas programáticas. Consulte la tabla comparativa de cuentas con nombre frente a implícitas anterior para obtener un desglose completo comparativo.

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

Una cuenta de NEAR puede tener un número ilimitado de claves de acceso simultáneamente. Cada clave tiene su propio ámbito de permisos: una Clave de acceso total con permisos sin restricciones o una Clave de acceso para llamadas a funciones limitada a métodos de contrato específicos. Esto permite a los usuarios mantener claves independientes para diferentes dispositivos o dApps sin necesidad de crear nuevas cuentas. Puede añadir o revocar claves individuales en cualquier momento sin afectar a las demás. Consulte la sección de claves de acceso para obtener detalles sobre cada tipo de clave.

¿Qué es el staking de almacenamiento en NEAR Protocol?

El staking de almacenamiento es el requisito para que las cuentas NEAR mantengan un saldo de Token NEAR proporcional a la cantidad de datos On-Chain que almacenan. Los Token se bloquean como Depósitos, no se gastan, y se liberan si los datos almacenados se eliminan. Este mecanismo evita la saturación del estado en la red y garantiza que los consumidores de almacenamiento asuman el coste de los recursos que ocupan. El staking de almacenamiento es independiente de las comisiones de gas (que se queman por transacción) y del staking de validador (que asegura el consenso de la red). Consulta la sección de staking de almacenamiento para obtener la explicación completa.

¿Puede una cuenta NEAR albergar un Contrato inteligente?

Sí. Cualquier cuenta de NEAR puede tener un contrato inteligente desplegado. A diferencia de Ethereum, que separa las Cuentas de Propiedad Externa (cuentas de usuario que no pueden contener código) de las Cuentas de Contrato (cuentas que contienen código sin clave privada), NEAR utiliza un modelo de cuenta unificado donde cualquier cuenta puede mantener simultáneamente un saldo de Token NEAR y código de contrato desplegado. Los contratos en NEAR se compilan a WebAssembly (WASM) a partir de código fuente en Rust o JavaScript, no Solidity. Consulta la sección de comparación con Ethereum para obtener el desglose arquitectónico completo.

¿Qué ocurre si el saldo de mi cuenta NEAR cae por debajo del requisito de almacenamiento?

Si el saldo de una cuenta de NEAR cae por debajo del mínimo requerido para su uso de almacenamiento, la cuenta no podrá enviar transacciones salientes hasta que el saldo se recargue. La cuenta no se elimina y sus datos no se pierden; simplemente se vuelve inactiva para las transacciones salientes hasta que se depositen suficientes tokens NEAR. Los datos almacenados permanecen intactos en la cadena. Consulte la sección sobre el almacenamiento mediante staking en la práctica para obtener detalles sobre los requisitos de saldo.

¿Qué es una subcuenta en NEAR y quién la controla?

Una subcuenta de NEAR es una cuenta cuyo ID tiene como prefijo el ID de una cuenta principal. Por ejemplo, app.alice.near es una subcuenta de alice.near, y solo alice.near puede crear cuentas en ese espacio de nombres. Tras su creación, la cuenta principal NO controla la subcuenta. La subcuenta es totalmente independiente, con sus propias claves de acceso, su propio saldo de NEAR Token y su propio estado On-Chain. La autoridad de nomenclatura de la cuenta principal se limita al acto de creación. Consulte la sección de subcuentas para obtener una explicación completa.

¿En qué se diferencia NEAR Protocol de Ethereum en cuanto a las cuentas?

La principal diferencia arquitectónica es la estructura de cuentas. Ethereum tiene dos tipos de cuentas separadas: Cuentas Propietarias Externas (controladas por una única clave privada, sin código) y Cuentas de Contrato (controladas por código, sin clave privada). NEAR utiliza un modelo de cuenta unificado donde cualquier cuenta NEAR puede contener simultáneamente un saldo de Token y un contrato inteligente desplegado. Las cuentas NEAR también admiten múltiples claves de acceso con diferentes ámbitos de permisos, mientras que las cuentas de Ethereum son controladas individualmente por una única clave privada. Los IDs de cuenta NEAR pueden ser nombres de cuenta legibles por humanos, mientras que las direcciones de Ethereum son siempre cadenas hexadecimales. Consulte la tabla de comparación completa para un desglose detallado.

¿Qué es una Clave de Acceso Completo frente a una Clave de Acceso de Llamada a Función en NEAR?

Una Clave de acceso total tiene permisos sin restricciones sobre una cuenta: puede autorizar transferencias de Token, el despliegue de contratos y la adición o eliminación de otras claves. Una Clave de acceso total es la credencial de mayor confianza del propietario de la cuenta y debe almacenarse en un monedero de hardware o fuera de línea. Una Clave de acceso para llamadas a funciones está limitada a llamar a métodos específicos en un contrato específico, con una asignación opcional de Token NEAR para gas. No puede transferir saldos de Token ni modificar otras claves. Las Claves de acceso total son para los propietarios de las cuentas; las Claves de acceso para llamadas a funciones se emiten a las dApps para permitir interacciones similares a sesiones sin requerir acceso total a la cuenta. Consulta la tabla de comparación de claves para obtener un desglose completo.

¿Cómo es un ID de cuenta de NEAR?

Los identificadores de cuenta de NEAR vienen en dos formatos. Las cuentas con nombre parecen nombres de usuario o nombres de dominio legibles: alice.near, myprotocol.near, app.alice.near. Las cuentas implícitas son cadenas hexadecimales de 64 caracteres derivadas de una Clave pública, similares en formato visual a las direcciones de Ethereum pero más largas: por ejemplo, 98793cd91a3f870fb126f66285808c7e094afcfc4b4a2ca57271d8b8b6a4a7c0. Las cuentas con nombre usan el sufijo .near en Mainnet y .testnet en la red de pruebas. Consulte la sección de identificadores de cuenta para obtener el desglose completo y la tabla comparativa.

¿Es NEAR Protocol una prueba de stake?

NEAR Protocol utiliza un mecanismo de consenso proof-of-stake (PoS). Los validadores realizan staking de tokens NEAR para participar en la producción de bloques y obtener recompensas del protocolo. Las cuentas de validador son cuentas NEAR estándar con contratos de staking desplegados en ellas, lo que ilustra el modelo de cuenta unificado en la práctica. El staking de validadores es un mecanismo separado del staking de almacenamiento; ambos bloquean tokens NEAR pero sirven para propósitos completamente diferentes.

Puntos clave y próximos pasos

El Modelo de Cuentas de NEAR unifica la identidad de la cuenta con permisos y la gestión de almacenamiento On-Chain en una única arquitectura. En lugar de separar las cuentas de usuario de las cuentas de contrato, o limitar cada cuenta a una única Clave privada, NEAR integra flexibilidad y permisos con alcance directamente en la capa de cuentas.

Conclusiones principales:

• Los IDs de cuenta NEAR son cuentas con nombre legibles por humanos (por ejemplo, alice.near) o cuentas implícitas de 64 caracteres derivadas de una clave pública, no direcciones hexadecimales
• Las cuentas con nombre requieren un Depósito de token NEAR al registrarse; las cuentas implícitas se activan automáticamente al recibir el primer token
• Cada cuenta NEAR puede tener múltiples claves de acceso simultáneamente, cada una con un ámbito de permisos distinto
• Las claves de acceso completo autorizan todas las acciones de la cuenta y pertenecen al propietario de la cuenta; las claves de acceso a llamadas de función están limitadas a métodos de contrato específicos y se emiten a aplicaciones
• Cualquier cuenta NEAR puede tener tanto un saldo de token NEAR como un contrato inteligente desplegado. No existe un tipo de cuenta de contrato separado
• El staking de almacenamiento requiere un saldo de token NEAR bloqueado proporcional al consumo de almacenamiento On-Chain. Es un Depósito reembolsable, no una comisión, y es distinto tanto de las comisiones de gas como del staking de validadores
• Las subcuentas siguen una convención de nomenclatura jerárquica, pero la cuenta principal no controla las subcuentas después de la creación. Cada subcuenta es completamente autónoma

Los desarrolladores preparados para construir en NEAR pueden comenzar con la documentación del modelo de cuenta de NEAR Protocol,), que proporciona las especificaciones técnicas y las referencias del SDK. Para conocer los detalles específicos sobre el staking de almacenamiento y los parámetros de las tasas actuales, consulte la documentación oficial de NEAR sobre el staking de almacenamiento) antes de tomar decisiones sobre la arquitectura, ya que los parámetros del protocolo pueden cambiar mediante la gobernanza. Los usuarios que deseen crear su primera cuenta de NEAR pueden hacerlo a través de una interfaz de monedero compatible con NEAR, como MyNEARWallet o Meteor Wallet.

Nota de precisión técnica: NEAR Protocol es una Blockchain activa y en evolución. Las especificaciones técnicas, incluidas las tasas de staking por almacenamiento y los requisitos de creación de cuentas, pueden cambiar a medida que se actualiza el protocolo. Verifique las especificaciones actuales en la documentación oficial de NEAR Protocol antes de tomar decisiones de desarrollo.