Xiangru Ma - Beyond Account Model Fine-Grained Deterministic State Access for Parallelization on EVM

[snorts] Hi everyone, my name is Stefan Deator. I have a pleasure here to introduce you uh our first panel of the afternoon. I'm here with Shanguma directly from Hong Kong. So it's really exciting for us uh having her here to uh introducing uh us what is the parallel EVM. So what is happening beyond uh the scalability and the velocity in the EVA ecosystem.

So thank you very much Tanguma and you have your space here. Thank you.

Thank you. I'm going to take the stage. Hey everyone. Uh I'm super excited to be here. I'm Shangu.

I'm I'm Daido actually from the pria dev team and I've traveled a long way to make it happen here in in Napoli and I love the city. is a lovely place to be and um my teammate just a few days ago my teammate just gave a keynote speech during ECC in Ghana in France and on crystallity and now it's my turn to introduce crystals to you and I will be honest that it will be a little bit tag focused but I assure you uh like by the second half of this talk it's going to be fun and cool for the traders and for the builders in this Uh so first let's start with what is crystallity. Crystal is actually a combination of crystal and solidity which means we bring structure we add structure to solidity and it will be the first time for solidity developers to express parallelism parallelism at the uh language level. So uh this this is actually a paper uh just released published at PPOPPP25 which is kind of a top tier academic conference in Europe and that's I guess that's why we were accepted by ECZ to be a keynote speech keynote speaker and just have our debut on the stage and a little bit quick background of our team. uh we are a team I'm not flax here but our team is really from high performance system design background and they are from Microsoft research from AMD and people from Ohio State University so we've been in this industry for over five years and uh still I'm going to show you share with you what what we have been working on today so the firstly we the the keyword word of today is definitely parallelization.

And when we talk about par paralization, it's actually it reminds you of a bunch of different things. Parallel IO, parallel zk, snarf uh generation, but today we will keep the scope really narrow. We will only talk about the paralization of transaction execution on Ethereum. So that's our focus today. And for for the first time, crystallity brings deterministic paralization to Ethereum.

Uh to make it easier to understand, crystallity sit in the same class as Caleb of Salana and the same class as block STM to apples. So uh when we categorize the layer one blockchains in different categories usually I' I'm going to like introduce three types. So there are no paralization op paralization and pessimistic ones. So firstly we know eer bitcoin has no paralization at all. They execute transactions one by one or sequentially.

And for the ops like what's adopted by a monut and say they are the optimistic optimistic one I'll d in later to for your understanding and the third one is pessimistic which is implemented by salana sui and the latest one an eip uh 7928 is what we consider one of the most important EIP released by Ethereum foundation which basically enforce a block level access lists at the block level. So that's basically the first time that Ethereum is taking a huge step towards parallelism on Ethereum and that's and on other day I remember our team say our day has come it's time for our show and so you may ask so what is crystality where what's the positioning of crystality among all these paralization approaches so before diving into the details uh I So have there's one very key uh point to understand which is at the heart of paralization there's a very important um they're very important issue which is state conflict. So how we analyze and detect state conflicts and how we resolve them and then have getting the results just correct and different answers actually lead to different paralization approaches. So as mentioned before, Ethereum has no paralization for I mean for most uh execution clients they have no so they don't worry about state conflicts we just execute everything one by one and then for OP like capitals Monut and Bessu Bessu is one uh Ethereum execution client says we know that they already adopting OP paralization they just ex ignore they just assume there are no state conflicts and they are execute the transactions anyway and they are going to check if the correct if if the results are correct afterwards. Then what we do by uh what what is implemented by Salana and SUI is they are going to check and analyze dependency analyzes conflicts beforehand and they will have to know if they are there are like resource contention beforehand and they only of execute transactions that with no state conflicts that's what they do so Chris Crystal's positioning is Here we are a deterministic paralization that we decompose one trans one transaction into non-over overlapping parts and then we will maximize the paralyzable parts by minimizing the state conflicts.

So if that is just too abstract to understand I'll make it simple here. So uh this is an axis we use and the x-axises xaxis meaning uh time or block height the yaxis meaning different transactions. So when there are bunch of transactions coming in there are no paral paralization on serium and appto which is also their block SCM that's their execution client. So what they do now is uh they just as I mentioned before that transactions are initially assumed with no state confess at all. They're going to just execute them and then find okay there's a state conflict here.

I'm going to abort it and re-execute it with uh serially or with a different scheduling. That's what they do. So it is especially efficient in low to moderate conflict scenarios because there are when there are many many transactions coming in they're are going to execute them anyway and just handle the conflicts when they arise. So when there is no conflict then they don't need to have to deal with that. But the question is this is the mechanism that they borrow from database and big data system where right exec where right requests are rare but in the real blockchain world we we know that because those on frequent onchain execution there will be inducing spiking gas fees which might become a performance bottleneck of the system.

So next we have sui the move today what they do is um they're going to pre-check the state conflicts. So basically they will have like a traffic manager, a traffic policer here, a traffic policer here just categorizing objects with those transactions are touching owned or those transaction are are touching shared objects and in most cases in SUI only the transactions touching share uh own objects will be paralyzable. This is what is so doing and it's especially efficient in high conflict scenario. So we know they will just only execute transactions with no state conflicts. But we know in the blockchain real blockchain world today um actually most of transactions are very simple.

They just involve very simple operations like ERC token transfer, move token transfer, move NFT transfer. they're just simply deducting assets from one address and adding it to another. So this checking time would be too long. So the whole pattern would be too long checking time and too short execution time. And in that case the checking time would become the bottleneck of the system performance.

And here in this illustration, if you can notice, we like make a small changes to the y-axis because we need more physical hardware. And this P number zero to pin number three actually represent parallel EVM instances. So we're going to need more parallel EVM instances for for executing the transactions. So as shown in this chart, we basically decompose one transa one transaction into multiple parts non-over overlapping multiple parts. The the first one is a microtransaction and the second one is what we call a relay transaction in crystallity.

So basically this means one transaction transaction number zero is going to touch state A and state X. Then we're gonna just petition this transaction based on their trans uh state dependencies. And we see in this there's a very special one P3 and P number three which means on this EVM instance it is exclusively for exclusively responsible for dealing anything touching state X. So what's happened? What's going to happen is if we zoom in on this pin number three, we're going to see whatever microtransactions relay transactions are going to touch state X will be relayed here will be sent to this EVM instance and executed here.

And this pattern also replicates to all other M microtransactions. they will be sent to that specific EBM instance that where that specific state stores and this relaying and the whole executing paral uh the mechanism is what we call a deterministic paralization. So each station each transaction is partitioned and assigned to a specific EVM instance. That's basically the core idea of this whole design. So this is actually a code example.

On the left side we have the solidity code and on the right side we have the crystallity code. And if you don't read code I'll just make it simplified for you to understand that if we say Alice is sending 10 USDT to Bob. So what is going to happen in the code is 10 USDT is first deducted that minus uh minus signal over there it's going to deducted from Alice balance and then when as the execution flow continues the system finds oh there's a Bob balance here so Bob balance is stored on another EVM instance so I'm I'm going to move the execution flow to where Bob's address is stored and then the the whole the the the logic just continue the whole flow just continues in that way. So what's different between solitic code and crystallity code? You see we've highlight highlighted uh the indifferences in red.

You see so for the crystallity developers they need to highlight the they need to guide what guide the system that what kind of data partitioning I'm doing I'm working on and the secondly is there is a very important semantic here it's not shown here anyway it's relay so the developers also has to let the system know where the execution flow how it's going to switch between the different EVM instances is okay if that's too technical I'm going to like concluding everything in one table uh that's key takeaway here is crystallity we have a finer granularity of paralization that's basically we are the only one in this space doing that decomposing one transaction into non-over overlapping parts and that's what we call intransaction level and for the other thing just like I mentioned before uh the OP paralization execute first check later and the pessimistic ones like su and salana will manage check first and execute next and then for the resource cont utilization we will say crystallity the determinist paralization when it's excellent it's the best one I'm going to have the numbers let the numbers do the talking later I'm going to show you a performance comparison later so this is basically if you zoom zoom out and take a look at the bigger picture. We see so the state of a contract are petitioned onto different EVM instances. So basically there are two things worth noting here which is um unlike smart languages like solidity or move crystallity adopts a shared nothing architecture. What that means? It means each single EVM instance has its own disk, has its own memory, has its own computing resources.

It's not shared by anyone. So they all like operate independently and that is actually what we borrow from distributed system design from the computer science just to make things more scalable and more isolated. And the second thing is beyond a runtime crystallity is also a c a code and language just like solidity is. So it basically is the first time for the developers to express parallelism in at the language level. If there are any coders here you can you probably could resonate with me.

Okay. So now we come to this image. This image just illustrates how functional relay works just as I mentioned before. So if apt is sending 10 USDT to Bob and the the system will find okay Bob's address is on is stored on another instant uh EVM instance. So the the execution flow is going to be relayed to another EVM instance.

So is the execution flow switching switching between the EMS EVMS rather than the states. And now is the time to have the numbers do the talking. So we have the performance comparison uh between crystallity and solidity between crystallity and sui and apptos. So in the first image we basically um have run this performance test using three very typical smart contracts. So the the result turns out to be excellent.

Crystality de delivers up to 99 times over solidity on when there are 128 parallel units which are the EVM instances where they are executed on. And for the second and third images basically we replay the real ERC20 transactions on crystallity on sui and on apptos. So we see actually the scalability there here is is even is even more outstanding. All right, enough of the tech talk. Okay.

So if now if you uh you're working on some like scaling solutions or or you are a defi builder or or you're a trader and you might be excited for what what I'm going to introduce uh as follows. And um this is actually a quote a line I come across on one of the most recent research proposal by paradigm which is the top VC VC in this in the crypto space and this line writes the future holds a million coins within the pool and today's infrastructure is just is just not ready. though that actually reminds me that as with the stable coins currently as a as a trendy topic the the stable coins coming on chain and the crypto world has seen the real incoming liquidity that has been creeping for so long for so much time and then finally the money comes where are what are we going to do with it so in my thoughts it all comes down to one line we will going to keep the money long chain and we will going to like make them flow like water. But how? But how?

Okay. So now we are uh I am introducing two ready to use tools. One is a parallel AMM prototype and the other one is for the developers to to save their efforts when migrating a solid decodes to to to crystallity. So basically um the the the uh parallel AMMX actually the first parallel AMM in the space that paralyzing transactions from one single liquidity pool. You've never seen that before and I'll dive into it later but I'll give you a preview that it basically achieves up to over 10 times speed up on 12 on 16 parallel EVMS over unis swap.

And that is something we make amm firstly faster or fast enough to be the infrastruct infrastructure ready for mass adoption. And uh this is actually how we designed this thing how we designed this parallel amm from one single liquidity pool. So from what we've observed in the real world in the the real world of AMM the first thing is that on unis swap version two the leading the top 10 pools accounted for over 31% of total swaps on unis swap version two and th this means that amm trading like unis swap is highly concentrated in only the top several pools. So if you do paralyze like different pools, it does not it's not going to help. You're going to paralyze transactions from one single pool just to relieve that the hottest pool, the hottest bots in the space.

That's the first thing. And the second thing is all right, we know that AMM like unis swap they all are based on that constant product formula. So how can we how can we make that happen? If it is sequ has to be se like executed sequentially then what if we paralyze transaction from one pool then what what is going to do what is going to happen on the algorithm. So our second observation is that the price impact of one pool is mainly driven by large transactions and the numbers are from the historical data from unis swap version two.

The hottest polls shows that over 97% of transactions cause the price change smaller than 1,000. So that means only the large transaction have the like significant price impact. So this is actually an overall pattern of our architecture how we designed this. So basically all the transactions from one pool are going to be categorized based on their price impact. So there are two types of transactions large sum ones and the small sums ones.

And the large sum ones is going to send to a global liquidity pool which has usually has leaper liquidity and all the transactions over there are going to be executed sequentially and the rest over 70% of small transactions are going to be executed in parallel and in this smaller parallel pause. So what we do and how we make this happen is we treat the the liquidity of each pool as a unified one and we will have two mechanisms which are periodic synchronization and on demand repalancing between the smaller parallel pause and the global pause just to make sure the pricing is still accurate and still fair. That's basically the design philosophy of our parallel amm and we not only shipping the codes we we were not only shipping like the concept we also shipping the codes so we replay the transactions from the top three unis swap v2 pools which are e USDT uscc um crystality parallel amm running on 16 cores delivers speed ups of over 10 times over a single core execution and that's enough for the parallel amm if you are interested I'm going to like share you with the link and so you can try it out yourself and then we come to this uh Chris Solity developer heart we do have a developer tool for all the sol developers so what we do is we input language specifications s and we input these six contract examples to chat GBT. We have them learn I learned for a very long time and then we have like chat GBT successfully shipped 22 contracts from Crystality from Solidity to Crystality. So that basically there's no bugs.

It's just flawless perfect codes that Chubby is able to to write. And then we have our crystality de crystality developers u have some like guidance and prompts and feeding the trag then it is able to ship 10 more contracts. So that's basically covering 77 contract 77 cases and 45 contracts from solidity to crystallity. Okay. Our ultimate goal would be like we will have everything whatever you write in solidity we're going to ship it and migrate it into uh crystality in automatic way and that's our ultimate goal.

So where we are right now is for the simple codes like uh ERC20 transfer. So it's is a transfer from code uh this auto transpiler is doing very well. No bug flawless codes and running very well. And what it still struggles is for a little bit complex like cases like ERC uh 721. So the auto transpiler still struggles to retrieve the balance or function output inc uh 721 contract.

So that's what we are now. That's the progress we've making we've made till now. And so to conclude this talk uh I still I I'm here uh like laying out a layer of architecture. So we have two things actually. We have pred programming model that's why uh I said earlier and I'm from the pre-adab team that is basically the team we founded five years ago and then we have Chriselli on top so on the foundational layer we have create predomming model that is the foundation for general purpose parallel contracts it is decoupled from blockchain architecture and basically we can make it compatible with any blockchain not only Ethereum and probably Apto Salana anyone you you name And on top of that we have a crystallity EVM version that's basically the EVM execution runtime version of PRIA that we have and on the top of that we have a Calia language which is a solidity compatible language that for the first time bringing solidity to the pred world to the paralization world.

So that is basically the model the runtime the EBM runtime and the the solidity compatible language we have and that's the talk for today and if you're happy to like like if you're interested in any part of that just I'm happy to talk to anyone of you and probably I'm more I'm I'm I'm actually here to collaborate and to like hear thoughts from the scaling solution builders or the defy users and builders Thank you.