BigInt

BigInt es un tipo primitivo de JavaScript añadido en ES2020 para aritmética de enteros de precisión arbitraria. A diferencia del tipo Number regular — que usa doble precisión IEEE 754 y pierde exactitud por encima de aproximadamente 2⁵³ — BigInt puede representar enteros de cualquier tamaño.

Sintaxis literal: añada n a un número, o llame a BigInt(x). Los operadores como +, -, *, / funcionan, pero no se puede mezclar BigInt con Number — 1n + 1 lanza un error. La división trunca hacia cero (división entera).

Dónde importa BigInt: cantidades de Wei de Ethereum (hasta 10¹⁸ por ETH), operaciones criptográficas (claves RSA, ECC), IDs grandes de bases de datos (Snowflake, ULID), contadores a escala, sistemas financieros que almacenan céntimos como enteros.

Nuestro conversor Wei / Gwei / ETH usa BigInt en todo momento para que las cantidades Wei de 18 dígitos vayan y vuelvan sin pérdida. Consulte nuestra metodología cripto para los detalles de implementación.

Dónde Number falla silenciosamente antes de BigInt: el límite es Number.MAX_SAFE_INTEGER = 2⁵³ − 1 = 9.007.199.254.740.991. Por encima de esto, los enteros consecutivos ya no son todos representables — 9007199254740992 y 9007199254740993 se redondean al mismo doble. Los analizadores JSON que no optan por el soporte de BigInt corrompen silenciosamente los IDs grandes devueltos por las APIs (IDs snowflake de Twitter, IDs de objetos de Stripe en cuentas de 64 bits, cantidades de Ethereum). La corrupción es silenciosa: ninguna excepción, ninguna advertencia, simplemente un número diferente. JSON.parse puede configurarse con una función reviver que detecte cadenas de enteros y las convierta explícitamente a BigInt.

BigInt y serialización: JSON.stringify(1n) lanza un TypeError por defecto — JSON no tiene tipo BigInt. La solución pragmática es serializar los BigInts como cadenas decimales y analizarlos de vuelta en el lado del consumidor, que es lo que hace cada API RPC de blockchain (Ethereum devuelve cadenas hexadecimales, Solana devuelve cadenas decimales). Evite la tentación de usar .toString() al salir y Number() al entrar — eso completa un viaje de ida y vuelta a través del tipo con pérdidas y anula el propósito. Relacionado: IEEE 754 (por qué 0.1 + 0.2 !== 0.3 en el mismo lenguaje), Wei, Gwei. Referencia: Propuesta BigInt de TC39.

Ejemplo práctico: aritmética de saldo ETH

Considere una cuenta con 1,234567890123456789 ETH, almacenada on-chain como 1234567890123456789 Wei. Como Number de JavaScript esto se convierte en 1234567890123456800 — los dos últimos dígitos desaparecen. El error (unos 11 wei) es mínimo en términos de valor fiat, pero si suma muchos saldos de este tipo durante la conciliación contable, el sesgo de redondeo se acumula y el libro mayor off-chain diverge de la verdad on-chain. Con BigInt: const bal = 1234567890123456789n; const fee = 21000n * 30n * 10n**9n; const net = bal - fee; — exacto al wei, sin pérdida. El término 10n**9n es mil millones, el multiplicador de gwei a wei.

Rendimiento y advertencias

Las operaciones con BigInt son más lentas que con Number — típicamente 10-100× dependiendo del tamaño de los operandos — porque recurren a la aritmética de precisión arbitraria en V8 en lugar de una única instrucción de CPU. Para bucles intensivos sobre millones de valores que caben de forma segura en un double, use Number. Otras advertencias: Math.max, Math.abs, Math.floor rechazan BigInt; JSON.stringify lanza error; typeof 1n === "bigint", no "number"; mezclar tipos con < y === sigue reglas de coerción sorprendentes (1n == 1 es true, 1n === 1 es false). La referencia BigInt de MDN enumera la tabla de coerción; trátela como lista de verificación al introducir BigInt en una base de código que antes solo usaba Number.