nanopay

NanoPay est une bibliothèque Node.js et TypeScript pour le réseau de cryptomonnaie Nano. Son README décrit deux modes d'utilisation : un client de haut niveau pour des workflows complets et des fonctions exportées pour un contrôle étape par étape. Les deux partagent la même cryptographie Nano et les mêmes constructeurs de blocs. Installation avec npm install nanopay. La version 0.2.0 utilise le RPC public Nano mainnet de BerryPay lorsque createClient() ou createRpcClient() est appelé sans URL ; la version 0.1.0 exige une URL explicite. Node.js 22+, ESM, CommonJS, TypeScript et les navigateurs modernes sont pris en charge. Un bundle de script navigateur expose NanoPay. Les comptes peuvent être créés ou récupérés avec createWallet, walletFromSeed, accountFromPrivateKey et walletFromMnemonic. Les seeds Nano hexadécimaux natifs utilisent la dérivation BLAKE2b, tandis que les seeds mnémoniques BIP39 suivent le chemin Nano SLIP-0010 m/44'/165'/index'. Le README avertit que les utilisateurs doivent sauvegarder le seed du portefeuille, ou la mnémonique et sa phrase de passe, et qu'une clé privée ne contrôle qu'un seul compte. Les seeds et clés privées doivent rester hors des logs et des requêtes RPC. Pour envoyer, recevoir et confirmer, createClient renvoie un client avec getBalance, send, waitForConfirmation, receiveAll et changeRepresentative. Le client lit l'état du compte, construit un bloc, signe localement, demande le work, le vérifie et soumet une fois. Les écritures sur le même compte sont mises en file dans une instance client ; les comptes différents et les lectures indépendantes s'exécutent en parallèle. Un statut submitted signifie que le nœud a accepté le bloc, mais waitForConfirmation doit être utilisé avant de le considérer comme réglé. TransactionError conserve le hash exact et le bloc signé. ReceiveAllError.completed préserve les soumissions réussies antérieures. Les écritures ne sont pas retentées automatiquement, et un échec de soumission bloque les écritures suivantes sur ce compte avec AccountBlockedError jusqu'à ce que la transaction échouée soit réconciliée et que client.resumeAccount soit appelé. Pour un contrôle total, la bibliothèque exporte generateSeed, derivePrivateKey, derivePublicKey, deriveAddress, buildSendBlock, hashBlock, signHash, attachSignature, getWorkRoot, attachWork et createRpcClient. Les fonctions de construction ne nécessitent aucune clé privée. signBlock combine hachage et signature. createSendBlock, createReceiveBlock et createChangeBlock combinent construction et signature et renvoient un objet avec hash et block. Ces fonctions ne contactent pas de nœud. prepareSend, prepareReceive et prepareChangeRepresentative ajoutent des lectures de registre et renvoient des transactions non signées. Les signataires externes implémentent publicKey et sign(hash). Les signatures doivent utiliser Ed25519-BLAKE2b de Nano, pas Ed25519-SHA512 standard. Les fournisseurs de work implémentent work avec root, threshold et signal, et peuvent utiliser WASM local, un service GPU ou un nœud de work séparé. Les montants utilisent des chaînes plutôt que des nombres à virgule flottante. nanoToRaw et rawToNano sont disponibles, amount signifiant Nano et amountRaw ou balanceRaw signifiant raw. Un Nano vaut 10^30 raw. Les raw fractionnaires et le dépassement uint128 sont rejetés. L'Unit.nano historique signifie 10^24 raw, donc nanoToRaw doit être utilisé pour les montants Nano ordinaires. Les liens de paiement et les confirmations en direct sont pris en charge via createPaymentUri, parsePaymentUri et watchConfirmations. Les URIs de paiement encodent raw comme requis par Nano. Les notifications WebSocket peuvent se répéter, donc les utilisateurs doivent dédupliquer par hash. Une déconnexion, un message malformé ou un buffer plein lève une erreur. Le flux n'a pas de reconnexion automatique ni de comptabilité persistante des paiements. Les points d'entrée ciblés incluent nanopay/keys, nanopay/blocks, nanopay/work, nanopay/amounts, nanopay/mnemonic, nanopay/rpc, nanopay/payments et nanopay/confirmations, chacun prenant en charge ESM, CommonJS et TypeScript. Le point d'entrée keys ne contient ni WASM ni la liste de mots mnémoniques. Le moteur de work WASM se compile une fois par realm, isole les appels concurrents et cède entre les lots. workerIndex et workerCount partitionnent l'espace de nonce et doivent être exécutés dans des Workers séparés. Le work mainnet est probabiliste ; un service de work GPU est recommandé pour des charges soutenues. Portée et compatibilité : la boîte à outils couvre les comptes locaux, la dérivation native et mnémonique, les blocs d'état, la signature, le work, les lectures de registre, les workflows d'envoi/réception/changement, le suivi des confirmations et les liens de paiement. client.request et rpc.request exposent des commandes RPC Nano supplémentaires prises en charge par le nœud. Elle n'exécute pas de nœud de consensus, ne choisit pas de représentant, ne persiste ni ne chiffre les secrets, ne gère pas la comptabilité d'échange et ne fournit pas de transport matériel. Les nouveaux blocs utilisent le format d'état, tandis que les lectures de blocs RPC prennent aussi en charge les contenus de blocs historiques. Les noms de fonctions et signatures d'appel d'origine sont préservés sous nanopay/legacy, y compris deriveSecretKey et signBlock basé sur le hachage. L'ancienne API de wrapper de paiement nanopay est remplacée. Les commandes de développement incluent npm ci, npm run check et npm run bench. Les vérifications couvrent les vecteurs de protocole, les workflows, l'exécution navigateur et Worker, le formatage et l'installation dans un projet npm propre. Playwright Chromium peut être installé avec npx playwright install chromium. npm run build:wasm reconstruit le binaire versionné avec LLVM clang et wasm-ld ; les builds ordinaires utilisent le binaire existant. NanoPay est sous GPL-3.0-only et basé sur nanocurrency-js. Le code source, les scripts de build, les avis originaux et les licences des dépendances incluses sont fournis avec le paquet.