Les reçus, et pourquoi une transaction en devient plusieurs
Une transaction NEAR est une requête. Ce qui s’exécute réellement est un reçu, et une transaction peut en générer plusieurs.
La raison est le sharding. NEAR répartit l’état à travers des shards, et un contrat sur un shard appelant un contrat sur un autre ne peut pas le faire synchroniquement. L’appel devient un reçu, routé vers le shard cible, exécuté là-bas, et son résultat renvoyé comme un reçu supplémentaire.
Une seule action utilisateur — échanger des tokens, par exemple — produit donc un arbre : la transaction initiale, un reçu pour le premier contrat, des reçus pour chaque appel inter-contrat qu’il fait, et des reçus rapportant les résultats. Chacun est exécuté séparément, potentiellement dans des blocs différents.
C’est le même schéma asynchrone que TON, avec un vocabulaire différent. Et cela produit le même mode d’échec : une transaction peut réussir alors qu’un reçu profond dans l’arbre échoue, et un explorateur ne montrant que la transaction rapporte un succès.
NearBlocks rend l’arbre avec le statut de chaque reçu. C’est le produit, et sans lui, les interactions de contrat NEAR sont essentiellement illisibles.
Comptes nommés et clés d’accès
Les comptes NEAR ont des noms lisibles par un humain — alice.near plutôt qu’une chaîne hexadécimale — implémentés au niveau du protocole plutôt que comme un service de nommage rajouté par-dessus. Les sous-comptes suivent le même schéma, donc app.alice.near est contrôlé par alice.near.
La fonctionnalité la plus intéressante est les clés d’accès. Un compte NEAR peut avoir plusieurs clés avec des permissions différentes. Une clé d’accès complet peut tout faire. Une clé d’appel de fonction ne peut appeler que des méthodes spécifiées sur un contrat spécifié, avec une allocation de dépense.
C’est un modèle de sécurité véritablement bon qui manque aux autres chaînes. Une application peut détenir une clé qui lui permet d’appeler son propre contrat en votre nom, avec une allocation plafonnée, et rien d’autre. Elle ne peut pas vider votre compte car ce pouvoir ne lui a jamais été accordé — ce qui est structurellement meilleur que le schéma d’approbation de token illimitée qui domine les chaînes EVM.
NearBlocks liste les clés d’accès sur un compte avec leurs permissions et allocations. Réviser cette liste périodiquement est l’équivalent NEAR de vérifier les approbations de tokens, et c’est nettement plus facile à raisonner.
Le staking de stockage, qui surprend tout le monde
NEAR facture le stockage d’état en exigeant que les comptes verrouillent du NEAR proportionnellement aux données qu’ils occupent. Stockez plus, verrouillez plus. Supprimez des données et le montant verrouillé est libéré.
La conséquence pratique est qu’une partie de votre solde n’est pas dépensable. Tenter d’envoyer la totalité échoue car cela vous ferait descendre sous votre exigence de stockage, ce qui est déroutant si vous ne savez pas que le mécanisme existe.
Cela signifie aussi que recevoir un token peut vous coûter. S’enregistrer auprès d’un contrat de token alloue du stockage, et quelqu’un doit payer le dépôt — ce qui explique pourquoi certains transferts de tokens NEAR exigent que le destinataire soit enregistré d’abord, et pourquoi un transfert vers un compte non enregistré peut échouer.
NearBlocks montre l’usage de stockage et le montant verrouillé sur les pages de compte. C’est la première chose à vérifier quand un transfert échoue sans raison apparente.
API et open source
NearBlocks est open source avec un niveau gratuit d’API nécessitant une clé. Pouvoir lire comment les arbres de reçus sont assemblés compte ici, car cet assemblage implique de vraies décisions — quel reçu est le reçu « principal », comment attribuer le gas à travers un arbre, comment présenter un échec partiel.
Le propre JSON-RPC de NEAR est l’alternative pour les données brutes. Il vous donne les transactions et reçus sans la reconstruction de l’arbre, qui est la partie qui demande du travail.
Pour tout ce qui est destiné aux utilisateurs sur NEAR, la reconstruction n’est pas optionnelle. Montrer à un utilisateur la transaction initiale et déclarer que c’est fait produira des tickets de support de personnes dont l’action a réussi au sommet et échoué trois reçus plus bas.
Ce que nos tests de référence ont montré
Notre ensemble de référence NEAR a été construit autour du problème des reçus : un transfert simple, un transfert de token vers un compte enregistré, un transfert de token vers un compte non enregistré, un swap inter-contrats, et un compte avec plusieurs clés d’accès.
Le transfert simple était banal. Le transfert de token vers un compte enregistré s’affichait comme un court arbre de reçus et se lisait proprement.
Le transfert vers un compte non enregistré était le test qui comptait, et il s’est comporté comme le prédit le modèle de staking de stockage : la transaction a réussi, un reçu plus profond dans l’arbre a échoué car le destinataire n’avait aucun dépôt de stockage enregistré auprès du contrat de token, et les tokens n’ont pas bougé. Un utilisateur regardant seulement la transaction aurait conclu que le transfert avait fonctionné.
NearBlocks a montré le reçu en échec avec son erreur, à plusieurs niveaux de profondeur, clairement marqué. C’est la chose la plus précieuse que fait cet explorateur, et c’est la raison pour laquelle un explorateur NEAR qui ne rend pas les arbres de reçus n’est utilisable pour rien au-delà de confirmer un simple transfert.
Le swap inter-contrats a produit un arbre nettement plus grand — une douzaine de reçus à travers plusieurs contrats — et est resté lisible, ce qui est un véritable exploit d’interface vu la complexité sous-jacente.
Le test de clé d’accès listait à la fois une clé d’accès complet et une clé d’appel de fonction avec son allocation et ses méthodes autorisées. Comparer cela à l’exercice équivalent sur une chaîne EVM, où réviser les approbations de tokens signifie lire une liste de permissions illimitées accordées à des contrats que vous ne reconnaissez peut-être pas, a rendu l’avantage de sécurité du modèle de NEAR concret plutôt que théorique.