Sobre o projeto
NanoPay é uma biblioteca para Node.js e TypeScript voltada à rede de criptomoeda Nano. Seu README descreve dois modos de uso: um cliente de nível mais alto para fluxos completos e funções exportadas para controle passo a passo. Ambos compartilham a mesma criptografia Nano e os mesmos construtores de blocos.
Instale com npm install nanopay. A versão 0.2.0 usa o RPC público da mainnet Nano da BerryPay quando createClient() ou createRpcClient() é chamado sem URL; a versão 0.1.0 exige uma URL explícita. Node.js 22+, ESM, CommonJS, TypeScript e navegadores modernos são suportados. Um bundle de script para navegador expõe NanoPay.
Contas podem ser criadas ou recuperadas com createWallet, walletFromSeed, accountFromPrivateKey e walletFromMnemonic. Seeds hexadecimais nativas da Nano usam derivação BLAKE2b, enquanto seeds de mnemônicos BIP39 seguem o caminho Nano SLIP-0010 m/44'/165'/index'. O README alerta que os usuários devem fazer backup da seed da carteira, ou do mnemônico e sua passphrase, e que uma chave privada controla apenas uma conta. Seeds e chaves privadas devem ser mantidas fora de logs e requisições RPC.
Para enviar, receber e confirmar, createClient retorna um cliente com getBalance, send, waitForConfirmation, receiveAll e changeRepresentative. O cliente lê o estado da conta, constrói um bloco, assina localmente, solicita work, verifica-o e submete uma vez. Escritas na mesma conta entram em fila dentro de uma instância de cliente; contas diferentes e leituras independentes executam concorrentemente. Um status submitted significa que o nó aceitou o bloco, mas waitForConfirmation deve ser usado antes de tratá-lo como liquidado. TransactionError retém o hash exato e o bloco assinado. ReceiveAllError.completed preserva envios anteriores bem-sucedidos. Escritas não são repetidas automaticamente, e uma falha de submissão bloqueia novas escritas naquela conta com AccountBlockedError até que a transação falha seja reconciliada e client.resumeAccount seja chamado.
Para controle total, a biblioteca exporta generateSeed, derivePrivateKey, derivePublicKey, deriveAddress, buildSendBlock, hashBlock, signHash, attachSignature, getWorkRoot, attachWork e createRpcClient. As funções de construção não precisam de chaves privadas. signBlock combina hashing e assinatura. createSendBlock, createReceiveBlock e createChangeBlock combinam construção e assinatura e retornam um objeto com hash e block. Essas funções não contatam um nó. prepareSend, prepareReceive e prepareChangeRepresentative adicionam leituras do ledger e retornam transações não assinadas. Assinadores externos implementam publicKey e sign(hash). As assinaturas devem usar Ed25519-BLAKE2b da Nano, não Ed25519-SHA512 padrão. Provedores de work implementam work com root, threshold e signal, e podem usar WASM local, um serviço de GPU ou um nó de work separado.
Valores usam strings em vez de números de ponto flutuante. nanoToRaw e rawToNano estão disponíveis, com amount significando Nano e amountRaw ou balanceRaw significando raw. Um Nano equivale a 10^30 raw. Raw fracionário e overflow de uint128 são rejeitados. A Unit.nano histórica significa 10^24 raw, portanto nanoToRaw deve ser usado para valores comuns em Nano.
Links de pagamento e confirmações ao vivo são suportados por createPaymentUri, parsePaymentUri e watchConfirmations. URIs de pagamento codificam raw, conforme exigido pela Nano. Notificações WebSocket podem se repetir, então os usuários devem deduplicar por hash. Uma desconexão, mensagem malformada ou buffer cheio gera um erro. O stream não tem reconexão automática nem contabilização persistente de pagamentos.
Pontos de entrada focados incluem nanopay/keys, nanopay/blocks, nanopay/work, nanopay/amounts, nanopay/mnemonic, nanopay/rpc, nanopay/payments e nanopay/confirmations, cada um com suporte a ESM, CommonJS e TypeScript. O ponto de entrada keys não contém WASM nem a lista de palavras mnemônicas. O motor de work WASM compila uma vez por realm, isola chamadas concorrentes e cede entre lotes. workerIndex e workerCount particionam o espaço de nonces e devem ser executados em Workers separados. O work na mainnet é probabilístico; um serviço de work em GPU é recomendado para cargas sustentadas.
Escopo e compatibilidade: o kit de ferramentas cobre contas locais, derivação nativa e por mnemônico, blocos de estado, assinatura, work, leituras do ledger, fluxos de envio/recebimento/troca, rastreamento de confirmações e links de pagamento. client.request e rpc.request expõem comandos RPC adicionais da Nano suportados pelo nó. Ele não executa um nó de consenso, não escolhe representante, não persiste nem criptografa segredos, não gerencia contabilização de exchanges nem fornece transporte para dispositivos de hardware. Novos blocos usam o formato de estado, enquanto leituras de blocos via RPC também suportam conteúdos históricos de blocos. Os nomes originais de funções upstream e as assinaturas de chamada são preservados em nanopay/legacy, incluindo deriveSecretKey e o signBlock baseado em hash. A antiga API de wrapper de pagamento nanopay foi substituída.
Comandos de desenvolvimento incluem npm ci, npm run check e npm run bench. As verificações cobrem vetores de protocolo, fluxos, execução em navegador e Worker, formatação e instalação em um projeto npm limpo. O Playwright Chromium pode ser instalado com npx playwright install chromium. npm run build:wasm reconstrói o binário incluído no repositório com LLVM clang e wasm-ld; builds comuns usam o binário existente. NanoPay é GPL-3.0-only e baseada em nanocurrency-js. Código-fonte, scripts de build, avisos originais e licenças de dependências empacotadas acompanham o pacote.
Comments
0 Rating appears after 10 ratings
Sign in to join the discussion.