On Chain Don

Q: Can you explain this: "Note that burn can be negative (i.e., currency could be minted) due to the effect of the storage refund." When a new storage slot is created within a tx, the person submitting the tx gets charged a storage fee. - This is true in both Ethereum and Monad When a storage slot gets destroyed within a tx, the person submitting the tx gets a storage refund. - This is true in both Ethereum and Monad - However in Ethereum, there are a bunch of constraints which make the refund very unlikely to recoup the original cost of creating the slot: 1. the refund is only 28% of the original cost of creating the storage slot (in gas terms) 2. refunds cannot decrease the cost of the transaction it's contained in by more than 20% (these constraints were introduced in EIP-3529, which nerfed storage refunds for reasons described in section 5.3 of the Category Labs proposal) - Whereas in Monad, in ordinary cases, most (96%) of the original cost of creating the storage slot is refunded (subject to one other condition which I'll explain later) - Because refunds aren't capped to the other gas in the transaction, it's possible for the refund to exceed the other costs incurred in the transaction, so that that individual transaction has a negative fee. However, this isn't cause for alarm - someone couldn't submit infinite negative-fee transactions at will; every such transaction requires freeing a slot that previously had a storage fee paid. Although this concludes the answer to the original question, I also want to say a few words about the motivation for this change to storage fees and refunds. By making refunds much closer to fees, we make the fee system more rational. State growth should be costly, because state has to get replicated across thousands of nodes forever. But if someone cleans up some state, then the burden of that state disappears so we should give them most of the "down payment" back. By making refunds a much higher percentage of fees, we can raise storage creation fees (in units of gas) to a level that sufficiently discourages state growth without being overly taxing on users (since as long as they destroy unneeded storage later they'll get most if it back). Monad has really high gas throughput (currently 400x vs Ethereum; 1.25m gas/s vs 500m gas/s), so 1 unit of Monad gas is likely to be many orders of magnitude cheaper (in dollar terms) than 1 unit of Eth gas. We want to have those really cheap costs for execution, but we don't want as a side effect to make it really cheap for someone to fill terabytes of data with garbage (see: XEN token). Here is one last analogy: - imagine a city, Everett, where glass bottles cost $20 per bottle, and if you recycle it you get $3 back - imagine a second city, Memphis, where glass bottles cost $0.02, and if you recycle it, you get $0.003 back. - someone thinks it's funny how cheap glass bottles are in Memphis so they buy 100 million of them for $2m and just leave them in the landfill, causing the landfill to run out of space. They couldn't pull this stunt off in Everett because that would have cost them $2 billion - Memphis realizes this is terrible so they raise the cost of glass bottles to $0.50 each, but give you $0.48 back when you recycle the bottle - results: more recycling in Memphis than in Everett + less deadweight loss from high fees pricing out users

This is a primer on async execution: how we made it work in Monad, why EIP-7702 broke it, and how to fix it For context, async execution has been in Monad since the consensus and execution clients were wired up to each other. Async execution allows execution to lag consensus by a fixed number of blocks from an interaction perspective. Most blockchains have interleaved consensus. That is, execution happens before consensus, which means cramming execution into a time budget that is a small fraction of the block time (the rest is occupied by round-the-world messaging, aka consensus). This inherently limits the gas per second of the system. L2s get around this by not having consensus at all. But we want the behavior of a distributed, decentralized L1 that maintains high performance. Async execution lets us evade this problem by moving execution out of the hot path of consensus. Instead, consensus and execution happen in parallel swim lanes. Consensus on block 2 occurs while execution of block 1 is running in parallel. There still needs to be an agreement between consensus and execution though. Specifically, that agreement is: execution is only allowed to lag consensus by up to k blocks, because block proposals contain a delayed merkle root. Also, consensus is building blocks with a delayed view of state (delayed by k blocks). This means that there is a danger that consensus will include a transaction from a sender who, by the time we execute, turns out has an empty balance. It would be bad if the protocol allowed this to happen, because it would open up a Denial-of-Service (DOS) vector. Therefore, to address this problem and safely enable asynchronous execution, the Monad consensus client calculates the max MON debit of each transaction as MON_spent = gas_bid * gas_limit + value. The consensus client keeps a running list of available account balances for each sender after deducting MON_spent for each transaction they sent. Goign off of that running balance, the consensus client only includes transactions if it can be sure that the transaction can be paid for. This is a pessimistic approach to block-building since it doesn't take into account the possibility of any accounts gaining in balance from a transfer in. Let me explain what I mean with an example. Suppose that Alice's account has 100 MON. Then, the following 3 transactions are included in block 1000: Tx 1: Alice sends 20 MON to Bob, costing 1 MON in fees Tx 2: Alice spends 70 MON buying a memecoin, costing 1 MON in fees Tx 3: Charlie sends 100 MON to Alice, costing 1 MON in fees Now it is block 1001. The leader is deciding whether to include the following transaction: Tx 4: Alice sends 40 MON to Bob, costing 1 MON in fees When we eyeball this, we know that it would be safe to include tx 4 because Alice's balance is 100 - 21 - 71 + 100 = 108. But because of async execution, at time of consensus, we don't know the result of all execution, we only know the worst-case balance of Alice is 100 - 21 - 71 = 8. The old algorithm relied on this pessimistic running balance to utilize lagged state in consensus decisions. It works pretty well, aside from the fact that it can be too conservative sometimes (as seen in the example above where tx 4 can't be immediately included until the delayed merkle root catches up to include the block with tx 3 in it).

The goal was never just to build a fast blockchain. If that were the only goal, we could have been done three and a half years ago by running geth, or erigon, or reth, or solana, with minor changes, on a bigger box, on a few nodes located close to each other. We could have done that quickly, and people might have been excited for a little while. But we would not have really contributed anything, and the hype would quickly fade, and you would already have forgotten about us. Every startup needs a north star, a reason for being. Market sentiment is inherently volatile, but without a reason, faith falters when sentiment wanes. A team and a community can keep moving consistently forward, gaining new strength and experience every day, regardless of the sentiment, if there is a clear raison d'être and a clear plan of attack. For our team, the north star has always been decentralization. Empowering decentralized systems with new architecture that makes the most of every cache line, every SSD IOP and every bit of bandwidth. Existing blockchain systems don't have the performance engineering advancements that characterize modern finance (Nasdaq ITCH, CME Globex, Goldman SecDb). We can change that, and support an ecosystem of ambitious builders who take advantage of these new superpowers. We can change that. Rolling out the last round of features soon, open sourcing the execution client soon, audit contest soon, mainnet soon. The future is indeterminate and incredibly exciting.