EIP-7923: A Sparse-Page-Based Memory Model for the EVM

Transcript

Uh, hi everyone. I'm Jamie from Corkchain and Chisu was supposed to be here. He's the author of um co-author of this EIP but he couldn't make it. Um, so we are from Corkchain team. We are building the spore work computer which is a decentralized network on Ethereum and today I'm going to introduce EIP7923 a sparse page based memory model. So this proposal changes how EVM um memory is allocated and charge it with the aim of bringing the model closer to the modern hardware.

So the motivation the current etherum uh trades memory as a continuous range starting at zero and uh expanding that range can incur quadratic cost uh which helps limit deny of service risk and the modern hardware uses a different model. A sparse page pages of about four kilobytes with a page table mapping virture addresses to physical memory and a missing page can trigger a hardware page fault and the operating system um enable the pages become available on demand or reject an invalid access. So the goal here is to enable flexible

memory layouts without paying uh for untouched gaps. Okay. So um the comparison um in the current model on the left so highest excess address expands the entire contiguous range and we charge the difference between the new and old memory cost on the right sparse page model. We examine only the pages exist by um touch it by access and if a page already exist we continue otherwise um we charge the allocation cost and make

that page available. So a software hashmap tracks pages while MAP supports sparse allocation. So this is a conceptual flow but the um key point is read from existing pages keep the same base gas cost. So to estimate the allocation cost we use 2019 era CPU with catch up to 56 throughput of 256 megabytes per second and the calibration is 20 nanconds and for a 30 million gas block uh which gives 0.6 seconds for a processing

budget and allocating a fresh page takes one to two microsconds. So using the upper end uh at the bottom 2,000 nanoconds divided by 20 gives 100 guests per page and uh one detail mnode can cross a boundary and can allocate two new pages. So um the M node here so random bite read within a 32 megabytes range takes seven nconds and a hashmap update with 8,192 entries take nanconds.

So with this measurement the estimated access and tracking is 25 nconds. So the current base cost is strict gas. So at 20 nconds per guest it's 60 nconds for budget and 25 nanconds uh fits within this budget. So the proposal keeps m at three guess there could be further improvements. So experimental allocation with Linux page protection. So accessing a protected page can trigger a zigzag and the application handler can allocate the page on demand. So the goal here is to remove the applications page tracking

hashmaps and there are two concerns um compatibility and memory limits. So the proposer aims to lower the memory charges with most existing contracts are expected to remain compatible and MSI's behavior remains unchanged. So the current model at 30 million gas is 54 megabytes and the proposed cap per transaction 64 megabytes and 100 concrt call request at the cap is 6.4 GB. So as shown at the bottom 64 megabytes times 100 calls would be 6.4 megabytes I mean

gigabytes. That's why um the memory cap matters when u many calls run at the same time. So um so in summary this proposer is um allocating only touched pages without paying for untouched gaps and keep a clear memory limit per transaction. So uh this is pretty much all and since she couldn't make it and she's the author of this proposal so I'm not taking any questions here on stage. You can find me after our talk or join our community and you can um ask direct questions to

ch by scanning this QR code. You can talk to