Redis EVM: Supercharging Ethereum calls with in-memory execution
Devcon 7 · 14 Nov 2024 · 9:43
Everton Fraga presents Redis EVM at Devcon 7, an approach to speeding up Ethereum call execution by running state access through an in-memory data store rather than disk-backed storage. The talk covers where in-memory execution delivers the biggest latency wins for read-heavy workloads like simulation and indexing, and what consistency tradeoffs come with moving state off disk.
Speakers
Topics
From Devcon 7, hosted by Ethereum Foundation.
Transcript
[Music] [Music] uh thank you all for coming can everybody hear me even in the back all right cool amazing so let's talk about this unusual combo R is an evm so for context I worked for the ethum foundation before had the honor and privilege to do so now I help customers uh exclusively from the have three space to deploy and scale on AWS which uh gives me visibility to some of the problems that they face right okay big one uh challenges on RPC scaling that's uh super
fun so uh to begin with uh whenever you have a consumer facing application let's let's think about a um defi router right uh you have to serve uh all those RPC requests to millions of people uh it is the traffic can be uh unpredictable and you might have some huge surges in traffic so some strategies that folks typically do is horizontal scalability of nodes super fair but it comes with uh some challenges right so first of all is reaction time the time it takes for you to deploy a new instance so take the snapshot load cop files and um load the
chain data and also synchronize the difference uh from that time second that's not a trivial challenge though by the way second um forecasting to understand you know your user patterns and see oh uh on weekends I have you know lower usage and then on you know on Tuesdays I might have um U more access and then you react accordingly proactively but that is a very specialized task right so the caveat is of over provisioning which happens a lot basically people paying for more servers with idle capacity that's not good for any
business final boss consistency right so when you scale horizontally well you you suffer from that you have potentially nodes that are behind the chain um you have have uh you know different states across and people use typically the latest data right so you do not uh scale horizontally to serve archive data some businesses they operate on only on current data so consistency I would I would say that is a final boss that typically um makes people delegate the task of managing these uh RPC t uh RPC nodes management two infrastructure
providers some of you know the ones that you know right but they suffer from the same problem so they they need to get really good at forecasting reaction time and that's all perpetuating and putting lots of pressure on those players well typ typical uh strategy to deal with with a lot of read um access is caching some of those RPC methods are pretty easy CH ID would never change block by hash one parameter get logs you can offload uh the data to some U database index and but the list goes on
and it becomes even harder eth call is the main villain because it is typically used for over 70% compared so if you want to address this issue we should you know first and foremost tackle the eth call problem word of the day externalization so can we is there any opportunity to externalize the processing of evm op codes to a very fast engine so I'm introducing today the evm Lua project that it is technical validation mode it is a micro evm interpreted implemented in Lua and it executes inside redus with minimal
storage read uh latency and it is able to process ultimately evm operations so e calls uh uh estimate gas in the future of course uh and and others how it works you can actually select what are the contracts you you have there and then you load uh the attributes that you from that contract so code balance on storage all the storage EAS are scripts for you to do that and and we have some phases so R&D stage this is where we're at so loading the entire storage from selected
contracts keeping up with the stative processing evm code strips Next Step evm compliance so implementing all the op codes including transient storage and adding evm metering SO gas metering and further steps include deployment so benchmarks optimization feedback loop and building for uh catering to user specific features so this is those are Baseline numbers from Amazon elasticache Benchmark using uh of course at the simplest um the simplest data structures this is not our project yet but uh 1.2 million requests per
second uh for a single instance that is a lot right and in a cluster you can have over 5 million requests per second and and if you scale those uh radest nodes horizontally so here's the project uh have fun please start it and well thank you very much thank you so much Everton so now we'll move on to a quick Q&A so we have one question thus far what are some potential security risks of embedding an evm interpreter within redis all right uh interesting question so uh you can have uh several guard rails uh for that uh but because you control you have control of the up codes
that are being executed uh that would be only for read and not to write so uh uh you can separate who writes and who reads at a user level uh and have several folks only reading from from that uh in memory database does that answer the question whoever asked I think so oh okay just on time we have another question how large is the Ram size needed that's another great question so to begin with uh only um you know just a couple megabytes uh and it is already enough to start playing and it depends on the contract storage you want to load up there right so uh on AWS the instances go up to two terabyte of
memory within a single instance so the sky can be really the limit here it could fit the entire state all right and I accidentally press answered for one of the questions so it's not showing up but I'll read it out why don't we access State DB remotely why do we access the B State remotely great question uh I thought about that too so we can create a compute unit uh that is external to the node and scale that out however they will all be executing um G Storage at uh sequentially as you execute the evm uh instruction and you will get the penalty of latency right so the thesis here is to to get together to put together both uh storage
and the the execution in an scalable way all right now we have a lot of questions um next what happens if the evm hits an unimplemented OP code it breaks really hard okay next one I'm assuming can this run on reddest Community absolutely yes all right there even uh yeah so there there are even a a novel uh engines there one of them is called valky uh that is a dropin replacement for red is uh should be the same thing right and there's uh yeah you know there's a developing space okay and our last question does it need archive notes to feed the data is Redd is sorting all
archive data great question so the project is uh currently focused on current state uh you need uh you don't need to have an archive note to feed that in but uh your RPC uh uh uh Source he needs to have uh some specific debug methods available right so U debug uh the the way to export the entire state of a contract is one of them all right we'll just have one last question when can we use this for full block execution oh wow I don't know soon please help me all right I think unfortunately that's all the time we have I know we have one more question but I believe
Everton will be hanging around here so yeah you can catch up with him after this session uh thank you so much Everton let's give him another round of applause thank you