Sobre el proyecto

NanoPay es una biblioteca de Node.js y TypeScript para la red de criptomoneda Nano. Su README describe dos modos de uso: un cliente de nivel superior para flujos de trabajo completos y funciones exportadas para control paso a paso. Ambos comparten la misma criptografía de Nano y los mismos constructores de bloques. Se instala con npm install nanopay. La versión 0.2.0 usa el RPC público de Nano mainnet de BerryPay cuando se llama a createClient() o createRpcClient() sin una URL; la versión 0.1.0 requiere una URL explícita. Se admiten Node.js 22+, ESM, CommonJS, TypeScript y navegadores modernos. Un paquete de script para navegador expone NanoPay. Las cuentas se pueden crear o recuperar con createWallet, walletFromSeed, accountFromPrivateKey y walletFromMnemonic. Las semillas hexadecimales nativas de Nano usan derivación BLAKE2b, mientras que las semillas de mnemónico BIP39 siguen la ruta Nano SLIP-0010 m/44'/165'/index'. El README advierte que los usuarios deben respaldar la semilla de la cartera, o el mnemónico y su passphrase, y que una clave privada controla solo una cuenta. Las semillas y las claves privadas deben mantenerse fuera de los registros y de las solicitudes RPC. Para enviar, recibir y confirmar, createClient devuelve un cliente con getBalance, send, waitForConfirmation, receiveAll y changeRepresentative. El cliente lee el estado de la cuenta, construye un bloque, firma localmente, solicita work, lo verifica y lo envía una sola vez. Las escrituras a la misma cuenta se encolan dentro de una instancia de cliente; las distintas cuentas y las lecturas independientes se ejecutan de forma concurrente. Un estado submitted significa que el nodo aceptó el bloque, pero debe usarse waitForConfirmation antes de considerarlo liquidado. TransactionError conserva el hash exacto y el bloque firmado. ReceiveAllError.completed conserva los envíos exitosos anteriores. Las escrituras no se reintentan automáticamente, y un fallo de envío bloquea las escrituras posteriores a esa cuenta con AccountBlockedError hasta que la transacción fallida se reconcilie y se llame a client.resumeAccount. Para tener control total, la biblioteca exporta generateSeed, derivePrivateKey, derivePublicKey, deriveAddress, buildSendBlock, hashBlock, signHash, attachSignature, getWorkRoot, attachWork y createRpcClient. Las funciones de construcción no necesitan claves privadas. signBlock combina hashing y firma. createSendBlock, createReceiveBlock y createChangeBlock combinan construcción y firma y devuelven un objeto con hash y block. Estas funciones no contactan con ningún nodo. prepareSend, prepareReceive y prepareChangeRepresentative añaden lecturas del ledger y devuelven transacciones sin firmar. Los firmantes externos implementan publicKey y sign(hash). Las firmas deben usar Ed25519-BLAKE2b de Nano, no Ed25519-SHA512 estándar. Los proveedores de work implementan work con root, threshold y signal, y pueden usar WASM local, un servicio de GPU o un nodo de work separado. Los importes usan cadenas en lugar de números de coma flotante. Están disponibles nanoToRaw y rawToNano, donde amount significa Nano y amountRaw o balanceRaw significan raw. Un Nano son 10^30 raw. Se rechazan los raw fraccionarios y el desbordamiento de uint128. El Unit.nano histórico significa 10^24 raw, por lo que debe usarse nanoToRaw para los importes ordinarios de Nano. Los enlaces de pago y las confirmaciones en vivo se admiten mediante createPaymentUri, parsePaymentUri y watchConfirmations. Las URIs de pago codifican raw según lo exige Nano. Las notificaciones por WebSocket pueden repetirse, por lo que los usuarios deben deduplicar por hash. Una desconexión, un mensaje mal formado o un búfer lleno provocan un error. El flujo no tiene reconexión automática ni contabilidad persistente de pagos. Los puntos de entrada específicos incluyen nanopay/keys, nanopay/blocks, nanopay/work, nanopay/amounts, nanopay/mnemonic, nanopay/rpc, nanopay/payments y nanopay/confirmations, y cada uno admite ESM, CommonJS y TypeScript. El punto de entrada keys no contiene WASM ni la lista de palabras de mnemónicos. El motor de work WASM se compila una vez por realm, aísla las llamadas concurrentes y cede entre lotes. workerIndex y workerCount dividen el espacio de nonces y deben ejecutarse en Workers separados. El work de mainnet es probabilístico; se recomienda un servicio de work con GPU para cargas de trabajo sostenidas. Alcance y compatibilidad: el conjunto de herramientas cubre cuentas locales, derivación nativa y de mnemónico, bloques de estado, firma, work, lecturas del ledger, flujos de envío/recepción/cambio, seguimiento de confirmaciones y enlaces de pago. client.request y rpc.request exponen comandos RPC de Nano adicionales admitidos por el nodo. No ejecuta un nodo de consenso, no elige un representante, no persiste ni cifra secretos, no gestiona contabilidad de exchanges ni proporciona transporte para dispositivos hardware. Los bloques nuevos usan el formato de estado, mientras que las lecturas de bloques por RPC también admiten contenidos de bloques históricos. Los nombres de funciones y las firmas de llamada originales del upstream se conservan en nanopay/legacy, incluidos deriveSecretKey y el signBlock basado en hash. La antigua API de envoltorio de pagos de nanopay queda reemplazada. Los comandos de desarrollo incluyen npm ci, npm run check y npm run bench. Las comprobaciones cubren vectores de protocolo, flujos de trabajo, ejecución en navegador y Worker, formato e instalación en un proyecto npm limpio. Playwright Chromium se puede instalar con npx playwright install chromium. npm run build:wasm reconstruye el binario incluido en el repositorio con LLVM clang y wasm-ld; las compilaciones ordinarias usan el binario existente. NanoPay es GPL-3.0-only y se basa en nanocurrency-js. El código fuente, los scripts de compilación, los avisos originales y las licencias de dependencias incluidas se distribuyen con el paquete.