BigInt

BigInt è un tipo primitivo JavaScript aggiunto in ES2020 per l’aritmetica intera a precisione arbitraria. A differenza del tipo Number regolare — che usa la doppia precisione IEEE 754 e perde accuratezza oltre circa 2⁵³ — BigInt può rappresentare interi di qualsiasi dimensione.

Sintassi letterale: aggiungere n a un numero, o chiamare BigInt(x). Gli operatori come +, -, *, / funzionano, ma non è possibile mescolare BigInt con Number — 1n + 1 genera un errore. La divisione tronca verso zero (divisione intera).

Dove BigInt è importante: importi Wei di Ethereum (fino a 10¹⁸ per ETH), operazioni crittografiche (chiavi RSA, ECC), ID di database di grandi dimensioni (Snowflake, ULID), contatori su scala, sistemi finanziari che memorizzano i centesimi come interi.

Il nostro convertitore Wei / Gwei / ETH usa BigInt ovunque affinché gli importi Wei a 18 cifre vadano e vengano senza perdite. Vedere la nostra metodologia crypto per i dettagli di implementazione.

Dove Number si rompe silenziosamente prima di BigInt: il confine è Number.MAX_SAFE_INTEGER = 2⁵³ − 1 = 9.007.199.254.740.991. Oltre questo, gli interi consecutivi non sono più tutti rappresentabili — 9007199254740992 e 9007199254740993 si arrotondano allo stesso double. I parser JSON che non scelgono il supporto BigInt alterano silenziosamente i grandi ID restituiti dalle API (ID snowflake di Twitter, ID oggetto Stripe negli account a 64 bit, importi Ethereum). La corruzione è silenziosa: nessuna eccezione, nessun avviso, solo un numero diverso. JSON.parse può essere configurato con una funzione reviver che rileva le stringhe intere e le converte esplicitamente in BigInt.

BigInt e serializzazione: JSON.stringify(1n) genera un TypeError per default — JSON non ha un tipo BigInt. La soluzione pragmatica è serializzare i BigInt come stringhe decimali e analizzarli di nuovo sul lato consumatore, che è ciò che fa ogni API RPC blockchain (Ethereum restituisce stringhe esadecimali, Solana restituisce stringhe decimali). Evitare la tentazione di fare .toString() in uscita e Number() in entrata — questo completa un ciclo di andata e ritorno attraverso il tipo soggetto a perdite e vanifica lo scopo. Correlati: IEEE 754 (perché 0.1 + 0.2 !== 0.3 nello stesso linguaggio), Wei, Gwei. Riferimento: Proposta TC39 BigInt.

Esempio pratico: aritmetica del saldo ETH

Si consideri un account con 1,234567890123456789 ETH, memorizzato on-chain come 1234567890123456789 Wei. Come Number JavaScript diventa 1234567890123456800 — le ultime due cifre sono sparite. L’errore (circa 11 wei) è minuscolo in termini di valore fiat, ma se si sommano molti di questi saldi durante la riconciliazione contabile, la distorsione da arrotondamento si accumula e il libro mastro off-chain diverge dalla verità on-chain. Con BigInt: const bal = 1234567890123456789n; const fee = 21000n * 30n * 10n**9n; const net = bal - fee; — esatto al wei, senza perdita. Il termine 10n**9n è un miliardo, il moltiplicatore da gwei a wei.

Prestazioni e insidie

Le operazioni BigInt sono più lente di Number — tipicamente 10–100× a seconda della dimensione degli operandi — perché toccano l’aritmetica a precisione arbitraria in V8 anziché una singola istruzione CPU. Per i loop intensivi su milioni di valori che rientrano in modo sicuro in un double, usare Number. Altre insidie: Math.max, Math.abs, Math.floor rifiutano BigInt; JSON.stringify genera un errore; typeof 1n === "bigint", non "number"; mescolare tipi con < e === segue regole di coercizione sorprendenti (1n == 1 è true, 1n === 1 è false). Il riferimento BigInt di MDN enumera la tabella di coercizione; trattarla come una checklist quando si introduce BigInt in un codebase precedentemente solo-Number.