BigInt

BigInt ist ein in ES2020 hinzugefügter JavaScript-Primitivtyp für Ganzzahl-Arithmetik mit beliebiger Genauigkeit. Anders als der reguläre Number-Typ – der IEEE-754-Doppelpräzision nutzt und jenseits von etwa 2⁵³ an Genauigkeit verliert – kann BigInt Ganzzahlen beliebiger Größe darstellen.

Literal-Syntax: Hängen Sie ein n an eine Zahl an oder rufen Sie BigInt(x) auf. Operatoren wie +, -, *, / funktionieren, aber Sie können BigInt nicht mit Number mischen – 1n + 1 wirft einen Fehler. Die Division schneidet zur Null hin ab (Ganzzahldivision).

Wo BigInt zählt: Ethereum-Wei-Beträge (bis zu 10¹⁸ pro ETH), kryptographische Operationen (RSA-Schlüssel, ECC), große Datenbank-IDs (Snowflake, ULID), Zähler im großen Maßstab, Finanzsysteme, die Cent als Ganzzahlen speichern.

Unser Wei / Gwei / ETH-Umrechner nutzt durchgängig BigInt, sodass 18-stellige Wei-Beträge ohne Verlust hin- und zurückgerechnet werden. Siehe unsere Krypto-Methodik für die Implementierungsdetails.

Wo Number vor BigInt still versagt: die Grenze ist Number.MAX_SAFE_INTEGER = 2⁵³ − 1 = 9.007.199.254.740.991. Darüber sind aufeinanderfolgende Ganzzahlen nicht mehr alle darstellbar – 9007199254740992 und 9007199254740993 runden auf dasselbe Double. JSON-Parser, die nicht ausdrücklich BigInt-Unterstützung aktivieren, verfälschen still große IDs, die von APIs zurückkommen (Twitter-Snowflake-IDs, Stripe-Objekt-IDs in 64-Bit-Konten, Ethereum-Beträge). Die Verfälschung erfolgt lautlos: keine Ausnahme, keine Warnung, einfach eine andere Zahl. JSON.parse kann mit einer Reviver-Funktion konfiguriert werden, die Ganzzahl-Strings erkennt und sie ausdrücklich in BigInt umwandelt.

BigInt und Serialisierung: JSON.stringify(1n) wirft standardmäßig einen TypeError – JSON kennt keinen BigInt-Typ. Der pragmatische Ausweg ist, BigInts als Dezimal-Strings zu serialisieren und sie auf der konsumierenden Seite zurückzuparsen, genau das tun alle Blockchain-RPC-APIs (Ethereum gibt Hex-Strings zurück, Solana gibt Dezimal-Strings zurück). Widerstehen Sie der Versuchung, beim Hinausgehen .toString() und beim Hereinkommen Number() zu nutzen – das vollendet einen Rundlauf durch den verlustbehafteten Typ und untergräbt den ganzen Sinn. Verwandt: IEEE 754 (warum 0.1 + 0.2 !== 0.3 in derselben Sprache), Wei, Gwei. Quelle: TC39 BigInt proposal.

Durchgerechnetes Beispiel: ETH-Guthaben-Arithmetik

Betrachten wir ein Konto mit 1.234567890123456789 ETH, on-chain gespeichert als 1234567890123456789 Wei. Als JavaScript-Number wird daraus 1234567890123456800 – die letzten beiden Ziffern sind weg. Der Fehler (etwa 11 Wei) ist in Fiat-Begriffen winzig, aber wenn Sie viele solcher Guthaben bei einer buchhalterischen Abstimmung summieren, häuft sich die Rundungsverzerrung und das Off-Chain-Hauptbuch weicht von der On-Chain-Wahrheit ab. Mit BigInt: const bal = 1234567890123456789n; const fee = 21000n * 30n * 10n**9n; const net = bal - fee; – exakt bis auf das Wei, ohne Verlust. Der Term 10n**9n ist eine Milliarde, der Gwei-zu-Wei-Multiplikator.

Performance und Fallstricke

BigInt-Operationen sind langsamer als Number – typischerweise 10-100×, je nach Operandengröße – weil sie in V8 Arithmetik mit beliebiger Genauigkeit berühren statt einer einzigen CPU-Instruktion. Für heiße Schleifen über Millionen von Werten, die sicher in ein Double passen, bleiben Sie bei Number. Weitere Fallstricke: Math.max, Math.abs, Math.floor weisen BigInt zurück; JSON.stringify wirft einen Fehler; typeof 1n === "bigint", nicht "number"; das Mischen von Typen mit < und === folgt überraschenden Coercion-Regeln (1n == 1 ist true, 1n === 1 ist false). MDNs BigInt-Referenz listet die Coercion-Tabelle auf; behandeln Sie sie als Checkliste, wenn Sie BigInt in eine zuvor reine Number-Codebasis einführen.