Der Gas-Token von DuskEVM ist in DUSK mit 18 Dezimalstellen – nicht nach dem 6-stelligen USDC-Muster rechnen
a m Testnet-Deployment-Tag habe ich beim Schreiben des Deployments nach der „Muscle-Memory“ aus DeFi transfer(addr, 1000000) reingetippt, um 1 DUSK zu überweisen. Ergebnis: Der Node meldet „insufficient balance“ – mein Wallet hatte aber eindeutig 15 Test-DUSK. Erst auf Blockscout geschaut und dann verstanden: DUSK im Mainnet und in DuskEVM haben beide 18 Dezimalstellen (wie ETH), nicht 6 wie USDC und auch nicht 8 wie bei manchen BEP-20s. 1 DUSK = 1000000000000000000 in der kleinsten Einheit.
Dieser Stolperstein ist beim Schreiben von Code über verschiedene Umgebungen besonders leicht: In Solidity ist uint amount = 1 * 10**18 korrekt. Aber wenn das Frontend in JS ethers.parseUnits("1", 6) übernimmt, ist es falsch. Ein Node-Skript, das den DUSK-Preis aus der Binance-REST liest (Notierungseinheit 1 DUSK = x U), ist kein Problem. Wenn du aber beim Erzeugen einer DuskEVM-Transaktion value 1e6 als „1 DUSK“ für Gas verwendest, wird die Transaktion effektiv zu null – und du zahlst trotzdem Base-Fee.
Noch verwirrender ist die Fee-Schätzung in DuskEVM, die in zwei Teile zerfällt: Die L2-exec-fee wird in DUSK mit 18 Dezimalstellen berechnet, und die L1(DA)-fee wird ebenfalls in DUSK mit 18 Dezimalstellen an DuskDS-Produzenten bezahlt. In meinem Remix-Deployment habe ich beim ersten Mal nach dem Ausfüllen von gas limit den value-Bereich falsch mit 2000000 ausgefüllt (entspricht 2 DUSK). Tatsächlich waren das aber nur 0.000002 DUSK – und das war niedriger als die base fee, daher wurde es abgelehnt. Erst mit 2000000000000000000 (2e18) hat es geklappt.
Analog zur von Hedger markierten geheimen Variable: Du @hedged uint256 shares; bedeutet 1000 Anteile eines Bond. Dafür musst du 1000 * 10**18 speichern. Der view key wird erst entschlüsselt, dann zeigt das Frontend 1000 über formatUnits(18) an – aber wenn du formatUnits(6) verwendest, sieht es wie 0.001 aus.
Ist euch die erste Transaktion von ERC-20 kommend auch von den Dezimalstellen „gebissen“ worden?
@Dusk $DUSK #dusk
a m Testnet-Deployment-Tag habe ich beim Schreiben des Deployments nach der „Muscle-Memory“ aus DeFi transfer(addr, 1000000) reingetippt, um 1 DUSK zu überweisen. Ergebnis: Der Node meldet „insufficient balance“ – mein Wallet hatte aber eindeutig 15 Test-DUSK. Erst auf Blockscout geschaut und dann verstanden: DUSK im Mainnet und in DuskEVM haben beide 18 Dezimalstellen (wie ETH), nicht 6 wie USDC und auch nicht 8 wie bei manchen BEP-20s. 1 DUSK = 1000000000000000000 in der kleinsten Einheit.
Dieser Stolperstein ist beim Schreiben von Code über verschiedene Umgebungen besonders leicht: In Solidity ist uint amount = 1 * 10**18 korrekt. Aber wenn das Frontend in JS ethers.parseUnits("1", 6) übernimmt, ist es falsch. Ein Node-Skript, das den DUSK-Preis aus der Binance-REST liest (Notierungseinheit 1 DUSK = x U), ist kein Problem. Wenn du aber beim Erzeugen einer DuskEVM-Transaktion value 1e6 als „1 DUSK“ für Gas verwendest, wird die Transaktion effektiv zu null – und du zahlst trotzdem Base-Fee.
Noch verwirrender ist die Fee-Schätzung in DuskEVM, die in zwei Teile zerfällt: Die L2-exec-fee wird in DUSK mit 18 Dezimalstellen berechnet, und die L1(DA)-fee wird ebenfalls in DUSK mit 18 Dezimalstellen an DuskDS-Produzenten bezahlt. In meinem Remix-Deployment habe ich beim ersten Mal nach dem Ausfüllen von gas limit den value-Bereich falsch mit 2000000 ausgefüllt (entspricht 2 DUSK). Tatsächlich waren das aber nur 0.000002 DUSK – und das war niedriger als die base fee, daher wurde es abgelehnt. Erst mit 2000000000000000000 (2e18) hat es geklappt.
Analog zur von Hedger markierten geheimen Variable: Du @hedged uint256 shares; bedeutet 1000 Anteile eines Bond. Dafür musst du 1000 * 10**18 speichern. Der view key wird erst entschlüsselt, dann zeigt das Frontend 1000 über formatUnits(18) an – aber wenn du formatUnits(6) verwendest, sieht es wie 0.001 aus.
Ist euch die erste Transaktion von ERC-20 kommend auch von den Dezimalstellen „gebissen“ worden?
@Dusk $DUSK #dusk