Modèle de compte NEAR : noms, clés et stockage

["Qu'est-ce que le protocole NEAR ?","TL;DR : Le modèle de compte NEAR en un coup d'œil","Qu'est-ce que le modèle de compte NEAR ?","Comptes nommés et comptes implicites : Comment NEAR identifie les utilisateurs","Sous-comptes : Organisation hiérarchique des comptes sur NEAR","Clés d'accès NEAR : Permissions d'accès complet vs. appels de fonction","Staking de stockage : Pourquoi les comptes NEAR nécessitent un solde minimum","Modèle de compte NEAR vs. Ethereum : Comparaison côte à côte","Démarrer : Créer et gérer votre compte NEAR","Questions fréquemment posées : Modèle de compte NEAR","Conclusion : Ce que le modèle de compte NEAR signifie pour les développeurs et les utilisateurs"]

Qu'est-ce que NEAR Protocol ? (Une brève introduction)

NEAR Protocol est une blockchain Layer-1 en proof-of-stake conçue pour l'accessibilité des développeurs, avec des frais transaction faibles et prévisibles et une architecture de sharding conçue pour passer à l'échelle sans sacrifier la facilité d'utilisation. Co-fondé par Illia Polosukhin et Alexander Skidanov, NEAR Protocol a été conçu dès le départ avec l'expérience développeur et l'accessibilité pour l'utilisateur final comme objectifs principaux, plutôt que d'adapter a posteriori la facilité d'utilisation à une architecture conçue à d'autres fins.

NEAR scale grâce au sharding Nightshade, un mécanisme qui distribue l'état des comptes et les calculs sur des chaînes de traitement parallèles, permettant au réseau de gérer des volumes élevés de transaction sans augmenter proportionnellement les frais. Le protocole prend en charge les contrats intelligents compilés en WebAssembly et maintient les coûts de gaz bas par conception, contrairement aux blockchains où la volatilité des frais crée des frictions pour les développeurs comme pour les utilisateurs. Le développement de l'écosystème est supervisé par la NEAR Foundation, l'organe de gouvernance à but non lucratif qui gérait auparavant le NEAR Wallet officiel avant de passer à des alternatives maintenues par la communauté.

L'expression la plus claire de cette philosophie axée sur les développeurs est le modèle de compte de NEAR, une conception qui repense de fond en comble le fonctionnement de l'identité et de la gestion des permissions sur la Blockchain.

TL;DR : Aperçu du modèle de compte NEAR

Résumé rapide pour les lecteurs pressés :

• Les comptes NEAR utilisent des noms lisibles par l'humain (par ex. alice.near) au lieu de chaînes de hachage cryptographiques comme les adresses 0x742d35Cc... d'Ethereum.
• Chaque compte peut détenir plusieurs clés d'accès simultanément, chacune avec son propre niveau de permission, allant du contrôle illimité aux interactions de contrat à portée restreinte.
• N'importe quel compte NEAR peut déployer un contrat intelligent ; il n'y a pas de type de compte de contrat distinct comme dans Ethereum.
• Les sous-comptes suivent un espace de noms hiérarchique (par ex. contract.myapp.near sous myapp.near), fonctionnant comme des sous-domaines pour les comptes Blockchain.
• Les comptes doivent maintenir un solde minimum de Token NEAR proportionnel à leur utilisation du stockage On-Chain, un mécanisme appelé jalonnement de stockage (storage staking).
• Le système natif de permissions multi-clés de NEAR atteint bon nombre des objectifs vers lesquels Ethereum tend avec l'abstraction de compte (EIP-4337), mais via une approche architecturale différente intégrée dès la création.

Qu'est-ce que le modèle de compte NEAR ?

Le modèle de compte NEAR est l'architecture d'identité et de permissions on-chain qui définit comment les comptes sont nommés, quel état ils stockent, comment l'accès est géré via des permissions de clés granulaires, et comment ils sont liés aux contrats intelligents sur la blockchain NEAR.

Dans le contexte de la Blockchain, un « modèle de compte » fait référence au système qu'un protocole utilise pour représenter les Participants On-Chain : ce qu'un compte contient, comment il est identifié, comment il autorise les transactions et s'il peut exécuter du code. Ethereum utilise un modèle de compte ; Bitcoin utilise un paradigme entièrement différent (le modèle UTXO, où les soldes sont suivis en tant que sorties de transaction non dépensées plutôt que comme des soldes de comptes). NEAR utilise un modèle basé sur les comptes, mais son implémentation diffère considérablement de celle d'Ethereum d'une manière qui importe tant pour la convivialité que pour le développement d'applications.

Un compte NEAR détient simultanément cinq éléments : un identifiant de compte unique, un solde de Token NEAR, l'état du compte (stockage de données On-Chain), un Contrat intelligent déployé optionnel compilé en WebAssembly (WASM, permettant des contrats écrits en Rust ou JavaScript), et une ou plusieurs clés d'accès avec des niveaux d'autorisation distincts. Cette structure unifiée signifie qu'il n'y a pas de séparation entre les "comptes utilisateur" et les "comptes de Contrat intelligent" comme sur Ethereum. Tout compte NEAR peut éventuellement héberger un Contrat intelligent sans devenir une catégorie d'objet différente. Les comptes sans Contrats intelligents déployés fonctionnent comme des comptes utilisateur ordinaires ; les comptes avec des Contrats intelligents déployés sont simultanément des comptes utilisateur et des hôtes de contrat.

Le contexte pratique permettant de comprendre pourquoi cela est important est l'application décentralisée (dApp), une application logicielle qui s'exécute sur un réseau blockchain plutôt que sur des serveurs centralisés. L'architecture des comptes de NEAR a été conçue pour rendre les interactions avec les dApps plus sécurisées et plus accessibles que ne le permettent les modèles de comptes blockchain existants. Le système d'identifiants de compte est l'endroit où cette philosophie de conception est la plus immédiatement visible, et c'est par là que commence la présentation de l'architecture.

Pour obtenir les spécifications techniques complètes, consultez la documentation sur le modèle de compte du protocole NEAR sur docs.near.org/concepts/basics/accounts/model.

Comptes nommés et Comptes implicites : Comment NEAR identifie les utilisateurs

NEAR identifie les utilisateurs et les applications On-Chain via deux formats de compte : comptes nommés, qui utilisent des chaînes de caractères lisibles par l'homme comme alice.near, et les comptes implicites, qui sont des chaînes hexadécimales de 64 caractères dérivées d'une Clé publique.

Comptes nommés : Identités Blockchain lisibles par l'homme

Les comptes nommés sur NEAR sont des identifiants de compte lisibles par l'humain qui suivent une structure de type domaine, se terminant par .near sur le Mainnet et par .testnet sur le testnet, remplaçant les chaînes de hachage cryptographiques utilisées par des blockchains comme Ethereum.

Le contraste est immédiat : alice.near contre 0x742d35Cc6634C0532925a3b844Bc454e4438f44e. Les deux sont des identifiants de blockchain valides, mais l'un est lisible et l'autre nécessite une vérification minutieuse par copier-coller. Considérez un compte nommé NEAR comme une adresse e-mail : lisible et lié à une identité, plutôt qu'une chaîne de caractères aléatoire qui nécessite une comparaison caractère par caractère pour être vérifiée.

Les comptes nommés suivent des règles de nommage spécifiques : les identifiants de compte sont des chaînes alphanumériques, peuvent utiliser des points comme séparateurs, doivent comporter entre 2 et 64 caractères, et doivent se terminer par .near sur mainnet ou .testnet sur le réseau de test. La structure séparée par des points crée une hiérarchie similaire à un domaine : myapp.near est un compte nommé de niveau supérieur, et contract.myapp.near est un sous-compte rattaché à celui-ci (plus d'informations sur les sous-comptes dans la section suivante).

La justification de l'UX derrière les comptes nommés va au-delà de l'esthétique. Les identifiants lisibles réduisent le risque d'envoyer des transactions à de mauvais comptes, facilitent la découverte des adresses de contrat et réduisent la charge cognitive de la gestion des identités On-Chain. Pour quiconque a vérifié trois fois une adresse MetaMask avant d'envoyer un transaction, l'attrait de alice.near par rapport à une chaîne hexadécimale de 42 caractères est concret plutôt qu'abstrait. Les utilisateurs enregistrent et gèrent les comptes nommés via MyNEARWallet à mynearwallet.com, l'interface de compte principale maintenue par la communauté (le portefeuille original wallet.near.org géré par la Fondation NEAR a été déprécié).

Comptes implicites : Le format de compte alternatif

Les comptes implicites sont le deuxième format de compte sur NEAR : des chaînes hexadécimales de 64 caractères en minuscules dérivées directement d'une clé publique, qui entrent en existence dès que des tokens NEAR sont envoyés à cet identifiant de compte, sans nécessiter d'Action de la part d'un compte existant.

La distinction pratique clé : un compte nommé nécessite un compte On-Chain existant pour parrainer son enregistrement via un transaction, tandis qu'un compte implicite se crée automatiquement lorsque des fonds arrivent sur l'identifiant de compte dérivé. Cela rend les comptes implicites utiles dans des contextes où un démarrage à partir de zéro est nécessaire, ou lorsque des noms lisibles par l'homme ne sont pas nécessaires. Les plateformes d'échange de Cryptomonnaie utilisent généralement des comptes implicites lors du crédit des dépôts NEAR aux utilisateurs, en générant un identifiant de compte unique à partir de la Clé publique de l'utilisateur sans nécessiter de compte On-Chain préexistant.

Une précision qu'il convient d'énoncer clairement : les comptes implicites ne sont pas anonymes. Ils sont dérivés de manière déterministe d'une clé publique et sont entièrement transparents On-Chain. Le mot « implicite » fait référence à la manière dont l'identifiant du compte est dérivé (à partir de la clé elle-même, sans étape d'enregistrement explicite), et non à une quelconque propriété de confidentialité.

Les comptes nommés et implicites définissent comment NEAR identifie les Participants On-Chain. Les comptes peuvent également contenir d'autres comptes sous leur espace de noms, et cette structure hiérarchique est l'origine des sous-comptes.

Sous-comptes : organisation hiérarchique des comptes sur NEAR

Les sous-comptes sur NEAR fonctionnent comme des sous-domaines sur le Web : tout comme docs.myapp.com et api.myapp.com sont des adresses distinctes sous le domaine myapp.com, token.myapp.near et staking.myapp.near sont des comptes Blockchain distincts sous l'espace de noms myapp.near.

Un sous-compte est un compte dont l'identifiant existe sous l'espace de noms d'un compte parent. Le compte contract.myprotocol.near est un sous-compte de myprotocol.near. Seul le compte parent peut créer un sous-compte : myprotocol.near peut créer contract.myprotocol.near, mais aucun autre compte ne peut créer de compte sous cet espace de noms sans l'autorisation du parent.

Important : Un compte parent ne peut pas accéder aux fonds ou à l'état d'un sous-compte après la création de celui-ci. Les sous-comptes sont des comptes entièrement indépendants qui partagent uniquement un espace de noms, et non des entités subordonnées contrôlées par un parent.

Cette indépendance est une source fréquente de confusion. La relation parent-enfant ne s'applique qu'au moment de la création. Une fois que contract.myprotocol.near existe, il possède ses propres clés d'accès, son propre solde de Token NEAR et son propre état On-Chain. Le compte parent myprotocol.near n'a aucun privilège spécial sur celui-ci.

Pour les développeurs de dApp, les sous-comptes offrent un modèle d'architecture pratique. Étant donné que n'importe quel compte NEAR peut déployer un contrat intelligent (compilé en WASM), les sous-comptes deviennent un moyen naturel de donner à chaque composant de contrat un identifiant de compte lisible et organisé. Un protocole DeFi pourrait déployer token.myprotocol.near pour son contrat de Token, staking.myprotocol.near pour son contrat de staking et governance.myprotocol.near pour son contrat de gouvernance. Chacun est un compte distinct avec son propre contrat, son propre état et sa propre gestion de clés, mais l'espace de noms rend la relation entre les composants immédiatement lisible pour quiconque consulte la chaîne. Pour obtenir des instructions de création de sous-compte étape par étape, consultez la documentation NEAR sur les sous-comptes à l'adresse docs.near.org/concepts/basics/accounts/model#named-accounts.

Comprendre comment les comptes sont nommés et organisés pose les bases de la couche architecturale suivante : leur sécurisation et la gestion des autorisations par le biais de clés d'accès.

Clés d'accès NEAR : Accès complet vs. Permissions d'appel de fonction

Les clés d'accès NEAR constituent la couche de permission qui contrôle les actions pouvant être effectuées sur un compte NEAR, et la caractéristique la plus distinctive du système sur le plan architectural : un seul compte NEAR peut détenir simultanément plusieurs paires de clés indépendantes, chacune avec son propre niveau d'autorisation.

Comment fonctionne le système multi-clés de NEAR

Contrairement à la plupart des comptes blockchain, où une seule clé privée contrôle tout, un compte NEAR unique peut détenir plusieurs paires de clés indépendantes, chacune associée à un type de permission spécifique, allant d'un contrôle total à des interactions avec les contrats à portée limitée.

Les clés d'accès NEAR utilisent par défaut des paires de clés Ed25519 (secp256k1 étant également pris en charge pour la compatibilité avec la chaîne d'outils Ethereum). Le système de permissions élaboré à partir de ces paires de clés est ce qui rend le modèle de NEAR architecturalement distinct. Imaginez cela comme un trousseau de clés : une Full Access Key (clé d'accès complet) est la clé maîtresse qui ouvre toutes les serrures ; une Function Call Access Key (clé d'accès à l'appel de fonction) est une clé conçue à cet effet qui n'ouvre qu'une porte spécifique. Chaque transaction signée par n'importe quelle clé d'accès sur un compte consomme du gaz payé en jetons NEAR, mais les frais transaction de NEAR sont faibles et prévisibles par conception, contrairement à la tarification historiquement variable du gaz d'Ethereum.

Pour plus de détails sur l'ajout et la gestion des clés d'accès par programme, consultez la documentation de référence sur les clés d'accès NEAR sur docs.near.org/concepts/basics/accounts/access-keys.

Clés d'accès complètes : Contrôle de compte sans restriction

Une Clé d'accès complet sur NEAR est une paire de clés qui peut effectuer n'importe quelle Action sur le compte auquel elle est rattachée : transférer des tokens, déployer des smart contracts, créer des sous-comptes, ajouter ou supprimer d'autres clés, et supprimer le compte lui-même.

Parce qu'une clé d'accès complet contrôle l'intégralité du compte, elle présente le même profil de risque qu'un mot de passe maître. Les clés d'accès complet ne devraient jamais être partagées avec des applications tierces et devraient être stockées dans un stockage à froid (portefeuille matériel ou stockage hors ligne) pour tout compte détenant des fonds importants. Si une clé d'accès complet est compromise, l'attaquant a un contrôle total du compte sans mécanisme de récupération natif, à moins qu'un ne soit configuré à l'avance.

La comparaison avec Ethereum est instructive ici. Dans Ethereum, votre Clé privée unique pour un Compte Externe (EOA) fonctionne comme une clé d'accès complet : elle contrôle tout, et il n'existe aucun moyen natif de donner à une dApp une clé à autorisation réduite pour une interaction de contrat spécifique. Chaque connexion de dApp via MetaMask expose votre clé de compte complète au flux de signature transaction. Cette limitation à une seule clé est précisément le problème que l'abstraction de compte EIP-4337 est conçue pour résoudre sur Ethereum. Sur NEAR, la solution a été intégrée au modèle de compte de base.

Clés d'accès aux appels de fonction : autorisations délimitées pour la sécurité des dApps

Une clé d'accès pour appel de fonction est une clé restreinte qui ne peut appeler que des méthodes spécifiées sur un contrat intelligent désigné, avec un plafond de frais de gaz optionnel qui limite la dépense totale des frais.

Alors qu'une Full Access Key n'a aucune restriction, une Function Call Access Key est précisément délimitée. La clé spécifie : un ID de compte de contrat qu'elle est autorisée à appeler, les méthodes de ce contrat qu'elle peut invoquer (ou toutes les méthodes Public, si elles ne sont pas plus restreintes), et une allocation optionnelle de NEAR Token qui plafonne le montant de gas que la clé peut dépenser avant de nécessiter un réapprovisionnement. Une fois l'allocation épuisée, la clé ne peut pas signer d'autres Transactions avant d'être rechargée ou remplacée.

Le cas d'utilisation de l'authentification basée sur la session est l'endroit où les Clés d'accès par appel de fonction montrent leur valeur pratique pour le développement de dApps. Lorsque vous connectez une dApp à votre compte NEAR, la dApp demande une Clé d'accès par appel de fonction limitée à son propre contrat. Cette clé est stockée dans votre session de navigateur. À partir de ce moment, la dApp peut soumettre des Transactions en votre nom (approuver un échange, Minting de NFT, interagir avec un contrat de jeu) sans vous demander de signer chaque Action individuelle. Votre Clé d'accès complète ne quitte jamais votre portefeuille sécurisé. Si la dApp est compromise ou malveillante, les dégâts sont limités : l'attaquant ne peut appeler que les méthodes contractuelles spécifiques auxquelles la clé était limitée, et uniquement jusqu'à concurrence du montant de l'allocation. Une Clé d'accès par appel de fonction fonctionne comme un jeton de session dans une application web : elle accorde un accès temporaire et limité à des Actions spécifiques sans exposer les identifiants complets du compte.

Les clés d'accès contrôlent les actions qu'un compte peut entreprendre. Le jalonnement de stockage (storage staking) régit ce qu'un compte doit détenir pour exister On-Chain.

Staking de stockage : pourquoi les comptes NEAR nécessitent un solde minimum

Le staking de stockage sur NEAR est le mécanisme par lequel chaque compte doit maintenir un solde minimum de tokens NEAR proportionnel à la quantité de stockage on-chain (état) que le compte utilise.

Le mécanisme fonctionne comme suit : NEAR alloue un espace de stockage On-Chain mesuré en octets. Pour chaque octet d'état stocké dans un compte (enregistrements de solde, code de contrat, données stockées, clés d'accès), un montant correspondant de tokens NEAR doit être détenu dans le solde du compte. Ces tokens ne sont ni dépensés ni détruits ; ils sont réservés en tant que solde bloqué correspondant à l'empreinte de stockage. Si vous réduisez le stockage de votre compte en supprimant des données d'état ou de contrat, les tokens correspondants sont débloqués et renvoyés à votre solde disponible. Le stockage par mise (storage staking) fonctionne comme un dépôt de garantie remboursable : vous bloquez un montant proportionnel de tokens NEAR pour le stockage utilisé par votre compte, et vous récupérez ces tokens si vous réduisez votre empreinte de stockage.

L'objectif de cette conception est économique : elle empêche l'inflation de l'état en veillant à ce que la partie qui bénéficie du stockage on-chain en supporte le coût. Sans un mécanisme comme celui-ci, un réseau blockchain peut accumuler des quantités illimitées d'état obsolète provenant de comptes ou de contrats abandonnés, dégradant les performances de tous les participants.

Concrètement, le taux de staking de stockage est d'environ 1 Token NEAR pour 10 Ko de stockage on-chain, et un compte NEAR vide nouvellement créé nécessite un solde minimum d'environ 0.00182 NEAR pour couvrir son empreinte d'état de base. Vérifiez les chiffres actuels par rapport à la documentation sur le staking de stockage NEAR à docs.near.org/concepts/storage/storage-staking avant de vous fier à ces chiffres pour la planification du développement, car les paramètres du protocole changent avec les mises à niveau.

Pour les développeurs de Contrat intelligent, l'implication du staking de stockage nécessite une planification active. Lorsqu'un compte NEAR déploie un contrat, le code du contrat lui-même occupe de l'espace de stockage dans l'état du compte. Un binaire de contrat plus volumineux nécessite un solde réservé proportionnellement plus important. Si votre contrat stocke des données importantes (enregistrements d'utilisateurs, soldes de Token, votes de gouvernance), le compte hébergeant ce contrat doit maintenir un solde suffisamment important pour couvrir à la fois le code du contrat et l'état accumulé. C'est une exigence de capital qui évolue avec l'usage de l'application, et elle doit être prise en compte dans votre modèle économique avant le déploiement.

Le staking de stockage crée une véritable exigence de blocage de capital. Certains développeurs trouvent cela contraignant par rapport aux chaînes qui n'exigent pas de soldes de stockage réservés. Le compromis est délibéré : la contrainte empêche l'état du réseau de croître sans limite, et les jetons sont récupérables. Mais la contrainte est réelle et doit être anticipée plutôt que découverte après le déploiement.

Staking de stockage vs. staking de validateur : Il s'agit de deux mécanismes distincts sur NEAR. Le staking de stockage verrouille des jetons NEAR en fonction de l'empreinte des données On-Chain de votre compte ; ces jetons agissent comme un solde réservé proportionnel au stockage utilisé. Le staking de validateur verrouille des jetons NEAR par rapport au Mécanisme de consensus, où les validateurs vont staker des jetons pour participer à la production de blocs et gagner des récompenses de staking. Cet article traite uniquement du staking de stockage. Ne confondez pas ces deux utilisations du mot « staking ».

Les frais de gaz (coûts d'exécution transaction) sont distincts du staking de stockage. Les frais de gaz sont consommés par transaction et payés en jetons NEAR au moment de la signature ; le staking de stockage est un solde réservé qui persiste avec le compte tant que l'état associé existe.

Comprendre le jalonnement de stockage permet de compléter la vision du fonctionnement isolé des comptes NEAR. La question suivante est de savoir comment cette architecture se compare à celle d'Ethereum.

Modèle de compte NEAR vs. Ethereum : Une comparaison côte à côte

NEAR et Ethereum adoptent des approches fondamentalement différentes en matière d'architecture de compte On-Chain, et ces différences ont des conséquences sur la manière dont les développeurs construisent des applications décentralisées et sur la manière dont les utilisateurs gèrent leurs identités On-Chain.

Le Système à Deux Comptes d'Ethereum vs. le Modèle de Compte Unifié de NEAR

Le tableau ci-dessous compare les deux modèles de compte selon huit dimensions architecturales. La différence la plus significative est qu'Ethereum sépare les comptes d'utilisateurs (Externally Owned Accounts, ou EOA) des comptes de contrats intelligents en deux types distincts, tandis que NEAR utilise un type de compte unique et unifié pour les deux.

La séparation entre les comptes EOA et les comptes de contrat d'Ethereum crée des frictions dans la pratique. La plupart des interactions avec les dApps nécessitent un EOA pour appeler un compte de contrat, ce qui signifie que les utilisateurs doivent gérer les deux types comme des entités distinctes. Un EOA est contrôlé par une seule Clé privée sans moyen natif de limiter la portée des autorisations : chaque dApp connectée à un compte MetaMask peut demander des signatures qui exposent la Clé privée complète du compte au flux transaction. Le modèle d'Ethereum a une logique de conception claire et a bien servi ses objectifs d'origine, mais la limitation de clé unique est devenue évidente à mesure que les interactions avec les dApps devenaient plus fréquentes et variées.

Le type de compte unifié de NEAR élimine la séparation EOA/contrat. Chaque compte NEAR est potentiellement un hôte de contrat, et le système multi-clés avec les clés d'accès aux appels de fonction résout la limitation de clé unique sans nécessiter de couche de protocole distincte. NEAR et Ethereum fonctionnent tous deux selon le paradigme basé sur les comptes, contrairement au modèle UTXO de Bitcoin où les soldes sont suivis comme des sorties transaction non dépensées plutôt que comme un état de compte ; la différence entre NEAR et Ethereum réside dans la manière dont ces comptes sont structurés et autorisés, et non dans le paradigme fondamental.

Modèle de compte de NEAR et abstraction de compte Ethereum (EIP-4337)

L'EIP-4337 (abstraction de compte) est l'effort d'Ethereum pour doter les EOA du type de permissions programmables et de capacités de clés de session que le modèle de compte de NEAR a été conçu pour inclure dès le départ.

EIP-4337 est une norme Ethereum active (et non une proposition théorique) qui permet aux portefeuilles basés sur des Contrats intelligents de fonctionner comme des citoyens de première classe, prenant en charge la validation programmable de transaction, les clés de session, la récupération sociale et les transaction sponsorisés. Elle nécessite une infrastructure de bundler spécifique pour fonctionner et est activement déployée dans tout l'écosystème Ethereum, bien qu'il ne s'agisse pas d'une mise à niveau universelle appliquée automatiquement à tous les comptes.

Le parallèle avec les clés d'accès aux appels de fonction (Function Call Access Keys) de NEAR est réel : les deux approches résolvent le problème de l'octroi aux dApps d'un accès limité et spécifique pour des interactions données, sans exposer la clé complète du compte. Un développeur familier avec les clés de session EIP-4337 trouvera les clés d'accès aux appels de fonction de NEAR conceptuellement familières. La nuance importante est qu'il s'agit de mises en œuvre architecturalement distinctes d'idées convergentes, et non de systèmes identiques. Le modèle de permission multi-clés de NEAR est natif au protocole de base ; l'EIP-4337 superpose une logique de portefeuille par contrat intelligent sur le modèle EOA existant d'Ethereum. Les problèmes qu'ils traitent se recoupent considérablement ; les mécanismes diffèrent. Pour la spécification complète de l'EIP-4337, consultez la spécification de l'abstraction de compte EIP-4337 sur eips.ethereum.org/EIPS/eip-4337.

Pour les développeurs Ethereum évaluant NEAR, deux ponts de l'écosystème sont à noter. Aurora sur aurora.dev, un environnement compatible avec l'EVM construit sur NEAR, permet aux développeurs Ethereum de déployer des contrats Solidity sur l'infrastructure NEAR, tandis que les comptes NEAR servent de couche d'identité sous-jacente. Les développeurs travaillant sur les deux écosystèmes peuvent utiliser Rainbow Bridge sur rainbowbridge.app pour transférer des actifs entre des comptes NEAR et des adresses Ethereum sans dépendre d'une garde centralisée.

Maintenant que l'architecture est claire, voici ce que la création et la gestion d'un compte NEAR impliquent concrètement.

Pour commencer : créer et gérer votre compte NEAR

Vous pouvez créer votre premier compte NEAR via MyNEARWallet à mynearwallet.com, l'interface principale maintenue par la communauté pour l'enregistrement des comptes NEAR et la gestion des clés. Vérifiez la recommandation de portefeuille canonique actuelle au moment où vous lisez ceci, car l'écosystème des portefeuilles NEAR continue d'évoluer ; d'autres applications de portefeuille compatibles existent aux côtés de MyNEARWallet.

Si vous venez d'Ethereum et de MetaMask, la différence conceptuelle mérite d'être comprise avant de commencer. Un portefeuille MetaMask est principalement un gestionnaire de clés et un signataire transaction pour les EOA Ethereum : il détient votre Clé privée et le présente aux dApps pour la signature transaction. Un compte NEAR est une identité on-chain complète avec un nom lisible, un stockage d'état on-chain, des permissions de clés programmables, et un hébergement de contrat optionnel. L'application portefeuille (MyNEARWallet) est l'interface ; le compte NEAR est l'objet on-chain. Ce sont des choses différentes, et la distinction est importante pour la gestion de vos clés.

La création d'un compte NEAR nécessite un petit solde initial de NEAR token pour couvrir l'exigence de base de staking de stockage (environ 0,00182 NEAR pour un compte vide, comme expliqué dans la section Storage Staking ci-dessus). Ce solde initial couvre l'empreinte d'état de base d'un nouveau compte.

Trois risques méritent d'être connus avant de commencer. Premièrement, si vous perdez votre Full Access Key sans qu'aucun mécanisme de récupération ne soit configuré, le compte est irrécupérable. Conservez votre Full Access Key dans un stockage à froid et configurez toutes les options de récupération disponibles avant d'en avoir besoin. Deuxièmement, les jetons NEAR réservés au jalonnement de stockage sont verrouillés tant que l'état associé existe ; il s'agit d'un engagement de capital, et non de frais. Troisièmement, la suppression d'un compte sur NEAR est irréversible. Pour un guide complet de création de compte étape par étape, consultez la documentation destinée aux développeurs NEAR à l'adresse docs.near.org/concepts/basics/accounts/model (https://docs.near.org/concepts/basics/accounts/model).

Les questions les plus fréquentes concernant le modèle de compte NEAR sont traitées ci-dessous.

Foire aux questions : modèle de compte NEAR

Les questions ci-dessous abordent les points de confusion les plus courants concernant le modèle de compte de NEAR, avec des renvois aux sections pertinentes ci-dessus pour les lecteurs souhaitant une couverture complète.

N'importe quel compte NEAR peut-il déployer un contrat intelligent ?

Oui. Sur NEAR, tout compte peut déployer facultativement un contrat intelligent compilé en WebAssembly (WASM). Il n'existe pas de type de compte de contrat distinct, contrairement à Ethereum où le déploiement d'un contrat nécessite la création d'un Compte de Contrat distinct. Un compte sans contrat déployé fonctionne comme un compte utilisateur standard ; un compte avec un contrat déployé fonctionne comme les deux simultanément. Consultez la section Quel est le modèle de compte NEAR ci-dessus pour l'explication architecturale complète.

Comment les clés d'accès NEAR rendent-elles les dApps plus sûres à utiliser ?

Les clés d'accès aux appels de fonction restreignent une dApp à des méthodes de contrat spécifiques avec un plafond d'allocation de gas optionnel. Lorsque vous vous connectez à une dApp à l'aide d'une clé d'accès aux appels de fonction limitée au contrat de cette dApp, votre clé d'accès complet (et le solde complet de votre compte) n'est jamais exposé à l'application Tiers. Si la dApp est compromise, les dommages sont limités à l'allocation et au contrat spécifié. Consultez la section Clés d'accès NEAR pour obtenir l'analyse complète.

Que se passe-t-il si je perds ma clé d'accès complet ?

La perte d'une Clé d'accès complet sans mécanisme de récupération préconfiguré rend le compte irrécupérable de manière permanente. Vous ne pouvez pas réinitialiser ou récupérer une Clé d'accès complet comme vous réinitialisez un mot de passe, car il n'existe pas d'autorité centrale qui contrôle le compte. Stockez toujours les Clés d'accès complet dans un stockage froid sécurisé, et configurez toutes les options de récupération de compte disponibles via votre application de portefeuille avant d'en avoir besoin. Certains portefeuilles offrent des configurations de récupération sociale ou de récupération multi-clés.

Les frais de gaz sont-ils les mêmes que le stockage en staking ?

Non. Les frais de gaz sont des coûts par transaction execution consommés au moment où une transaction est signée ; ils sont payés en tokens NEAR et ne persistent pas une fois que la transaction est terminée. Le 'storage staking' est un solde minimum réservé en tokens NEAR qui persiste avec le compte tant que l'état on-chain associé existe. Les deux impliquent des tokens NEAR, mais ils fonctionnent comme des mécanismes entièrement distincts. Voir la section Storage Staking pour l'explication complète.

Comment le modèle de compte de NEAR se rapporte-t-il à l'abstraction de compte d'Ethereum (EIP-4337) ?

Le système de permission multi-clés natif de NEAR atteint bon nombre des objectifs que l'EIP-4337 est conçu pour ajouter à Ethereum, notamment les permissions basées sur des sessions à portée limitée pour les interactions dApp et la logique de clé programmable. Les deux sont des implémentations architecturalement distinctes d'idées qui se recoupent : l'approche de NEAR est native au protocole de base, tandis que l'EIP-4337 superpose une logique de portefeuille de contrat intelligent au modèle EOA existant d'Ethereum. Ils résolvent des problèmes similaires via des architectures différentes. Voir la section de comparaison NEAR vs Ethereum pour l'analyse détaillée.

Quelle est la différence entre un compte nommé et un compte implicite sur NEAR ?

Les comptes nommés sont des identifiants lisibles par l'homme (par exemple, alice.near) enregistrés via un transaction à partir d'un compte existant, se terminant par .near sur Mainnet et par .testnet sur testnet. Les comptes implicites sont des chaînes hexadécimales de 64 caractères dérivées directement d'une clé publique, qui apparaissent automatiquement lorsque des jetons NEAR sont envoyés à cet identifiant de compte, sans qu'aucun transaction d'enregistrement ne soit nécessaire. Consultez la section Comptes nommés et comptes implicites pour obtenir le tableau de comparaison complet.

Combien de clés d'accès un seul compte NEAR peut-il détenir ?

Un compte NEAR peut détenir plusieurs clés d'accès simultanément, chaque clé se voyant attribuer son propre Type de permission (Clé d'accès complet ou Clé d'accès aux appels de fonction) et, pour les clés d'accès aux appels de fonction, son propre périmètre de contrat et sa propre allocation de gas. Il n'y a pas de limite documentée stricte sur le nombre de clés par compte. Cette capacité multi-clés est ce qui distingue le modèle de permission de NEAR de l'approche à clé unique par EOA d'Ethereum. Consultez la section Clés d'accès NEAR pour plus de détails.

Le jalonnement (staking) de stockage signifie-t-il que je perds mes jetons NEAR ?

Non. Les jetons NEAR réservés pour le staking de stockage sont verrouillés mais pas dépensés. Ils restent sur votre compte en tant que solde réservé et sont reversés sur votre solde disponible si vous réduisez l'empreinte de données on-chain de votre compte en supprimant de l'état. Les jetons constituent un dépose contre l'utilisation du stockage, et non des frais. Consultez la section Storage Staking pour connaître le mécanisme et les chiffres actuels.

Conclusion : Ce que le modèle de compte NEAR signifie pour les développeurs et les utilisateurs

Le modèle de compte NEAR reflète un ensemble de choix architecturaux délibérés : des noms de compte lisibles par l'humain abaissent la barrière à l'entrée et réduisent les erreurs transaction ; un système de permissions multi-clés réduit les risques de sécurité pour les interactions avec les dApps en limitant l'accès des tiers sans exposer les clés maîtresses ; le staking de stockage crée un alignement économique entre l'utilisation des ressources et le coût ; et une structure compte-contrat unifiée élimine la séparation EOA/contrat qui ajoute de la friction au développement sur Ethereum.

L'exigence de solde minimum pour le staking de stockage est une contrainte réelle à anticiper, et non une simple note de bas de page. Si votre application stocke un état On-Chain important, l'exigence de solde réservé augmente proportionnellement à cet état. Prévoyez-le dans le modèle économique de votre application avant le déploiement, et non après.

Prochaines étapes par persona :

• Développeurs : Commencez à construire sur NEAR Protocol à docs.near.org/develop
• Utilisateurs : Créez votre compte NEAR sur MyNEARWallet sur mynearwallet.com
• Chercheurs : Plongez dans la spécification complète du modèle de compte à Documentation du modèle de compte NEAR Protocol à docs.near.org/concepts/basics/accounts/model

Les spécifications techniques de cet article reflètent le protocole NEAR au moment de la rédaction. Le protocole NEAR fait l'objet d'un développement actif ; vérifiez les chiffres actuels sur docs.near.org avant de vous fier à des valeurs numériques spécifiques pour le développement ou la planification opérationnelle. Ce contenu est à titre informatif uniquement et ne constitue pas un conseil financier ou d'investissement.