BigInt

BigInt é um tipo primitivo JavaScript adicionado no ES2020 para aritmética inteira de precisão arbitrária. Ao contrário do tipo Number regular — que usa precisão dupla IEEE 754 e perde precisão acima de cerca de 2⁵³ — BigInt pode representar inteiros de qualquer tamanho.

Sintaxe literal: acrescente n a um número ou chame BigInt(x). Operadores como +, -, *, / funcionam, mas você não pode misturar BigInt com Number — 1n + 1 lança um erro. A divisão trunca em direção ao zero (divisão inteira).

Onde BigInt importa: valores de Wei do Ethereum (até 10¹⁸ por ETH), operações criptográficas (chaves RSA, ECC), IDs grandes de banco de dados (Snowflake, ULID), contadores em escala, sistemas financeiros que armazenam centavos como inteiros.

Nosso conversor Wei / Gwei / ETH usa BigInt em todo lugar para que valores de Wei de 18 dígitos façam round-trip sem perda. Veja nossa metodologia cripto para os detalhes de implementação.

Onde Number falha silenciosamente antes do BigInt: o limite é Number.MAX_SAFE_INTEGER = 2⁵³ − 1 = 9.007.199.254.740.991. Acima disso, inteiros consecutivos não são mais todos representáveis — 9007199254740992 e 9007199254740993 arredondam para o mesmo double. Analisadores JSON que não optam pelo suporte a BigInt distorcem silenciosamente IDs grandes retornados de APIs (IDs de snowflake do Twitter, IDs de objetos Stripe em contas de 64 bits, valores Ethereum). A corrupção é silenciosa: sem exceção, sem aviso, apenas um número diferente. JSON.parse pode ser configurado com uma função reviver que detecta strings de inteiros e as converte explicitamente para BigInt.

BigInt e serialização: JSON.stringify(1n) lança um TypeError por padrão — JSON não tem tipo BigInt. A solução pragmática é serializar BigInts como strings decimais e analisá-las de volta no lado consumidor, que é o que toda API RPC de blockchain faz (Ethereum retorna strings hexadecimais, Solana retorna strings decimais). Evite a tentação de fazer .toString() na saída e Number() na entrada — isso completa um round-trip pelo tipo com perdas e derrota o propósito. Relacionado: IEEE 754 (por que 0.1 + 0.2 !== 0.3 na mesma linguagem), Wei, Gwei. Referência: Proposta BigInt TC39.

Exemplo prático: aritmética de saldo ETH

Considere uma conta com 1,234567890123456789 ETH, armazenada on-chain como 1234567890123456789 Wei. Como um Number JavaScript, isso se torna 1234567890123456800 — os dois últimos dígitos se foram. O erro (cerca de 11 wei) é insignificante em termos fiduciários, mas se você somar muitos desses saldos durante a reconciliação contábil, o viés de arredondamento acumula e o livro-razão off-chain diverge da verdade on-chain. Com BigInt: const bal = 1234567890123456789n; const fee = 21000n * 30n * 10n**9n; const net = bal - fee; — exato até o wei, sem perda. O termo 10n**9n é um bilhão, o multiplicador de gwei para wei.

Desempenho e armadilhas

As operações BigInt são mais lentas que Number — tipicamente 10-100× dependendo do tamanho do operando — porque tocam aritmética de precisão arbitrária no V8 em vez de uma única instrução CPU. Para loops quentes sobre milhões de valores que cabem com segurança em um double, use Number. Outras armadilhas: Math.max, Math.abs, Math.floor rejeitam BigInt; JSON.stringify lança erro; typeof 1n === "bigint", não "number"; misturar tipos com < e === segue regras de coerção surpreendentes (1n == 1 é verdadeiro, 1n === 1 é falso). A referência BigInt do MDN enumera a tabela de coerção; trate-a como uma lista de verificação ao introduzir BigInt em uma base de código que antes usava apenas Number.