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

Transcript

[Music] Uh hello everyone. Uh I'm Hal from Prada team. I'm excited to introduce crystity to you guys and crystallity actually the two words we make these one words crystal plus solidity. That means we want to provide the structured solidity. Uh let's start. Oh, this work was published in ACM Pipop conference this year, a premier academic uh conference for programming language.

Uh my presentation includes three parts. The first one is a cryst design. It is a low program model for smart contracts on parallel EVMS enabling transactions to be executed in parallel under explicit developer control. The second part is Christi AMM. It is the first parallel AMM prototype. This prototype can process AMS web transactions concurrently even for a single trading pair. And in our preliminary results, we found our methods can achieve up to more than 10 times speed or over the sequential execution method. The third part is GPT based auto transpiliners. This

transpiler can help developers to migrate solidity contract to crystallity simplifying the adoption. Um you may not know many blockchain systems do not provide the parallel execution layer and the newer systems provide the execution layer in different ways like so say mer uh apttos and many others. Mostly they use two different methods. The first one is a optimistic one and the second one is a pessimistic one. The optimist the optimistic methods the system assume there's no conflicts in transactions and allow the par

execution and when they found there is a conflicts during the validation they go back and reexecute the transactions. In the pessimistic methods, the systems pre-check all the all the transactions and only allow the transactions without any conflicts to be executed in parallel. We also check the new EIP I mean the EIP 7928. They propose a block level access list. Intentionally it is for the parallel IO but I think this can be combined with the parallel execution.

The key challenge in parallel execution is resolving state conflicts different with the previous parallel methods. We propose a crystality use a different way. We break down state access and dependencies for each transaction and execute transactions state by state eliminating all the conflicts. We think the EIP7928 and Crystality is a perfect match. Let's check how Crystality executes transactions.

We assume we execute N token transfer transactions on P parallel EVMS. Each transaction has a unique source account SI but shares the same decision SX. In crystity, we also assume one EVM, in this case, EVM P3 exclusively updates state SX and the EVMS P 0 to P2 handle other states. At the time zero, P 0 to P2 note three transactions TX0 to tier 2 to execute and generate three relays.

At the T1, P 0 to P2 note three more transactions TX3 to TX5. At the same time, P3 execute two relays at T2. This pattern continues and going on. In this way, crystallity achieve an intransaction level paralism in a pipeline manner. This table summarizes key takeaways of crystallity. You can find in this table crystality is distinct with pris method especially in parallel granularity and execution model.

Let's check the detail how we implemented crystality. We think the major problem for the paralization is a smart contract language like solidity, move and others. They all use a shared everything architecture. That means all transactions can access all states at the runtime. Additionally, this program language use sequential program model. It is very difficult for developer to express parizen in deps and algorithms.

We use three different step major step to implement crystality. The first step we partition states into non-over overlapping segments each segment assigned to a dedicated EVM instance at runtime. For the second step for transactions in this example include two states SI and SJ. This transaction is first processed by EVM instance managing SI and then processed by another EVM instance responsible for SJ.

The address to EVM mapping is computed using this formula. We use the lowest m bits of address as the EVM ID. The execution flow switching between EVMS is managed by a relay directive. It is explicitly defined by the programmer in the program. We introduce crystity directives in two solidity. Our directives includes two major parts.

The first one is programmable cont contract scope. These scopes guide the underlying system for data partitioning and the storage. The second part is asynchronized function relay. This keyword is used to manage execution flow across different virtual machines. I show the example of solitic code and crystal static code. In this picture on the left hand side you can find this is ERC20 solidity code and on the on the right side is a crystal static code. It is really simple to add the directives.

We use add address directive to define the binance variable that guide the underlying system to partition data by address. And then we do the similar things to add the at address that for the trans to define transfer function. It enable this function to process different incoming transaction with different EVM instance. When we meet the state switching in this case from the serer address to the pace address we use a we use a relay we use a relay to define this switch in this lambda

expression. This is our preliminary results in crystallity. We compare crystality to solidity on EVM su and appos on their own execution engine. We can find crystali have much better performance. We develop cristati amm. Our key motivation is to paralyze swap transactions even within a single pool. Our key insight is that price change is primarily driven by large transactions.

User historical data from unis swap pools we found more than 27% of transaction cost 0.1% price change with this observation we implemented our crystal amm this is unified liquided pool but supports the paral execution for small transactions and for n transactions we handle handle the nse sequential the n transaction sequentially Okay, this our preliminary results. We can find we can obtain more than 10 times better speed up over sequential execution method in 16 paral event.

Last part we implemented GPT based out transpers. We we let the chat GPT learning our language specification and six contract example with that chat GPT can transfer 22 contracts from 45 inputs and with one more step with a few short learning methods I mean developer prompts the chat DBT for O model can generate 10 more contracts into crystalic code.

This picture showed two different uh case, one successful, one failure. And for the failure one, we found that the chat GPT the auto transpiler struggled to retrieve the binance of function output in URC 721 uh contracts. We are this is what we are working right now. Okay, this is the major thing about my talk. My talk includes the program model and our crystity implementation and a very brief introduce about the crystal AMA about the application built on the paral event. Thank you for your attentions and I'm happy to take any question.

Yeah, it's fine. What are you most excited about? like what are you excit Oh, sorry. What are you most excited about in this space? Oh, okay. Yeah, it's very I'm very excited because this one I think is we can use our method to improve the execution speed on the Ethereum and we provide the total EVM compatibility. That means you don't need to change anything underlying the underlying EVM system. I mean you don't need change EVM you don't need change consensus layer you don't need change anything under that that part then only care about the execution error and the

applica application this most excited part for me yeah okay thank [Music]