There was one night when I only meant to fix the withdraw button, but somehow the transaction receipt did not come through until nearly dawn... that was when I realized the problem was not gas, but the way I understood the transaction lifecycle.
DuskEVM feels so familiar: JSON-RPC, Solidity, Foundry, Remix, eth_estimateGas, EIP-1559, tx.value, calldata, gas limit, base fee... familiar enough that I almost forgot EVM compatibility does not mean the architecture is the same as Ethereum.
I changed the way I debug: where does execution happen, where does settlement happen, which layer does data availability go through, what fields does the Sequencer return?
the test case has State diff, Phoenix note commitment, Hedger state change and PLONK proof.
to be candid, I used to set the gas limit close to the estimate.
one time eth_estimateGas returned 91,500, I added a 20% buffer according to gasLimit = estimatedGas × 1.2; the transaction went through, but that margin exists to absorb edge cases.
L2 execution fee, L1 DA fee, 18 decimals, DuskDS, meta.l1Fee, dusk_estimateL1Fee... only when put together correctly do you get totalValue = L2fee + L1fee.
I log note count, changed-byte count, PLONK proof length and transaction hash in Foundry using vm.rpc, because “success” does not distinguish execution cost from DA cost.
deploying ConfidentialERC20 is done; you still have to open the receipt, look at gas used, effective gas price, then compare them against the State diff.
from then on I started treating estimate as observability: estimate, simulate, submit, inspect, compare...
OP Mainnet has l1Fee, DuskEVM also has l1Fee, but sharing the same name does not mean following the same path... this is where it is easiest to become complacent.
I believe the best interface is not one that hides complexity, but one that exposes exactly what developers need to verify.
if an app shows only one word, “fee”, while execution, DA and settlement are three different stories, do you guys see that as minimalist UX or abstraction taken too far?
#dusk $DUSK @Dusk
DuskEVM feels so familiar: JSON-RPC, Solidity, Foundry, Remix, eth_estimateGas, EIP-1559, tx.value, calldata, gas limit, base fee... familiar enough that I almost forgot EVM compatibility does not mean the architecture is the same as Ethereum.
I changed the way I debug: where does execution happen, where does settlement happen, which layer does data availability go through, what fields does the Sequencer return?
the test case has State diff, Phoenix note commitment, Hedger state change and PLONK proof.
to be candid, I used to set the gas limit close to the estimate.
one time eth_estimateGas returned 91,500, I added a 20% buffer according to gasLimit = estimatedGas × 1.2; the transaction went through, but that margin exists to absorb edge cases.
L2 execution fee, L1 DA fee, 18 decimals, DuskDS, meta.l1Fee, dusk_estimateL1Fee... only when put together correctly do you get totalValue = L2fee + L1fee.
I log note count, changed-byte count, PLONK proof length and transaction hash in Foundry using vm.rpc, because “success” does not distinguish execution cost from DA cost.
deploying ConfidentialERC20 is done; you still have to open the receipt, look at gas used, effective gas price, then compare them against the State diff.
from then on I started treating estimate as observability: estimate, simulate, submit, inspect, compare...
OP Mainnet has l1Fee, DuskEVM also has l1Fee, but sharing the same name does not mean following the same path... this is where it is easiest to become complacent.
I believe the best interface is not one that hides complexity, but one that exposes exactly what developers need to verify.
if an app shows only one word, “fee”, while execution, DA and settlement are three different stories, do you guys see that as minimalist UX or abstraction taken too far?
#dusk $DUSK @Dusk
