Somnia - Accelerating the EVM to 50 gigagas

Transcript

[Music] Hello there everyone. U my name is Paul. I'm the founder of Somnia and today I'm going to give you a talk about how we're accelerating the EVM to go beyond 50 gigas per second. So first of all I want to give you an overview of what we're building at Somnia. So Somnia is a high performance EVM compatible blockchain. In terms of its performance, it can do over a million transactions per second. So when I say million transactions, I mean ERC20 swaps. We also have very low latency. So we have subsecond finality with 100 millisecond block times. And we are very low cost in terms of gas enabling developers to put more compute on chain.

So I'd like to start this talk by talking about why we built Somnia and what we were thinking about when we were building it. So I used to work at this company called Improbable. We built large-scale multiplayer technology for the games industry and in the sports and music industry. This video behind me, you're seeing that technology. What it allowed you to do is get thousands of consumers in the same digital space at the same time. All could see each other or could talk to each other voice communications and all could be fully customized. So we applied this to gaming where we did things with Yuga Labs doing big events like the other side. We applied this to sports where we did events with people like Major League Baseball. We had digital baseball matches and we did this in the music industry working with people like

Universal Music where we'd have these digital music events. Now the way these were all going to monetize essentially was going to be digital assets. So consumers would go to these buy digital wearables and use them in the events. Now our vision was about these all being interoperable. So as a consumer could go to one of these events, buy some items, wear it and then use it across all the other experiences on the network. So I'd buy an MLE jersey can wear it across all the experiences. So in order to do that we needed a trusted ledger with a complete platform associated with it. Blockchain is a very good solution for that because essentially has no counterparty risk. The issue we had was when you have these events where tens of thousands of people, hundreds of thousands of people show up and all want to interact on chain at the same time.

Existing blockchains in the VM system did not scale. So we had to build our own. So that's what Somn is. Somn is a high performance blockchain designed for these high density scenarios. It's very high performance over a million transactions a second with very low latency subsecond finality. It is fully EVM compatible. So when we mean this anything that runs on the EVM ecosystem today you just need to change the RPC endpoint and it will run on top of Somnia taking advantage of the performance characteristics. It's very low cost. So we uh price gas very cheaply so you can get more compute on chain. We also are what we call a reactive blockchain. So this is a new concept which I could do a whole 30-minute talk on. Basically what allows you to do is use the blockchain like a pub subsystem. So you can listen to

events and data updates all fully on chain without having to use any off-chain architecture. So you could say listen to price updates then modify your protocol based on price or maybe you have a game you're listening some events on chain and your game changes based on those events. So this talk I'm primarily going to go through how we enable those performance characteristics with Somnia. So when we were building Somnia we basically had to build a blockchain from scratch. Uh we tried looking at forks, we tried looking at existing technologies but basically ended up building everything ourselves. Um, I really didn't want to do this. As a computer scientist, you know, you should be reusing stuff, but we end up having to. So, the first layer, we innovate on execution. Um, I'll go through this in more detail later, but essentially we optimize for sequential execution as opposed to parallel. The

next, we wrote a new database from scratch. The database is called DB as what we call predictable performance and also a very fast readwrite caching mechanism. The next is consensus. So, we have a new consensus algorithm called multiream consensus allows for higher throughput, low latency transactions. And then we also wrote a whole new networking algorithm. So the problem when you're getting to these performance characteristics is sending data around the network. So we have new compression techniques that allow us to go to that level. So let's go through this in more technical detail. So first execution. So with execution there are kind of two scaling methods today. One is sharding.

So essentially have multiple blockchains allows you to move horizontally very quickly. This is what Ethereum is essentially doing with the L1 L2 road map today. The issue is interoperability and composability. You kind of lose that as a result. The other way people are doing this is with parallel approaches. So essentially you have multiple threads each processing transactions individually. Now the issue with parallel it works very well for when all the transactions are independent. So if we're doing an ERC20 swap, these people over here are trading on a DEX. These people are doing an NFT mint. Parallel works really well. The issue is when all of the transactions collide and you want to mutate the same piece of onchain state at the same time. Now you may think this doesn't happen very frequently, but this happens during major NFT mints like the other side mint. This happens during memecoin

launches when you're trying to trade the same LP point on a DEX and actually happens a lot. So this graph here is a graph of contract call addresses from Ethereum from 2024. So on the bottom you see the contract addresses. They've been cut off a bit there and at the top you see the uh on the Y axis you see the call frequency. So you can clearly see a power law curve where the few contracts are called multiple orders of magnitude more than everything else in the network. This means you're going to get a lot of collisions which we believe means parallel approaches won't work. So we instead optimize sequential replication. Now the way we do that is essentially compiling EVM bite code to machine code. Um this is used in a lot of different industries because machine code basically takes advantage of what we call hardware parallelism. So if you

look at modern CPU architectures, they're really good at executing machine code. They can do things out of order. They can do branch prediction. And if you're interpreting thing uh things, you can't take advantage of this at all. So we take advantage of this with a custom EVM compiler that takes EVM bite code, turns out the machine code, and then run that across the network. that works at runtime or at pre-ompile time. So that's execution. So now we've made one thread go really fast. The issue now is going to be accessing data and writing data. So for this we created a whole new database from scratch. We looked at other databases in the market like Pebbles, like rocks. The problem is they weren't really optimized for blockchain data structures and really decentralized systems that we're talking about. So we wrote a new database from scratch. So

there's a few different properties. The first it has what we call predictable performance. So we can cost out gas exactly for a rewrite operation and that gives us more gas per second. I'll talk about this a bit later. The next is we kind of thought about a database from scratch thinking about blockchain data structures like potential merch rather than most databases that just think about KV stores. The final thing is a predictive rewrite cache which basically means most stuff is in memory most of the time which means you're not hitting disk which means much faster rewrite performance. So the predictable performance how do we do this? So we created a concept called performance reports. The way this works at a high level is first of all all of the nodes in the network when they're doing a read or write to a database they are deterministic. So all the reads are

consistent across all the validated set. Then whenever you do a read or write a performance report is created. So you understand did this hit disk did this hit cache. Um and therefore you can price the exact amount of go gas for each read and write because you can price that exact amount of gas you can put more gas into a block which means more gas per second which means higher levels of computation. So this concept of performant ports with predictability is very important. The next thing is the caching mechanism. So it's an LU cache that basically predictively puts stuff in memory. It uses that power law curve to say this is probably going to be accessed more frequently and predictively puts that in memory. That means you hit disk much less frequently which means much faster reader writes.

For ISDB you get 15 to 100 ncond read and writes. That for context is very fast. Most databases measure their read or write times in microsconds and we're talking about nanconds here. So that's the database. You've got execution database. Now what do we do in terms of consensus? So consensus is a new consensus mechanism that we call multiream consensus. This is inspired by a white paper called autobomb BFT. Um say recently actually did a very interesting research article going deep on this. They're probably going to adopt this consensus mechanism too. The way this works at a very high level is each validator is running its own kind of mini blockchain. So we call these a data chain. So each of those validators can create blocks for each of their data chains. Now obviously the issue is going to be the validators are going to collide and change data and mutate

different pieces of state. So globally across all of the validators continually we're running what we call the global consensus chain. So that is working out what is the head state of the blockchain and working out what is true and what is not. That consensus chain is also streaming all of the blocks that are created across the validators each of the other validators which they then replay and ensure a consistent ordering across the whole network. Now, the analogy I would give for this is imagine you have a motorway where each validator is a car on a lane and they're all going up creating blocks and then you have a guy at the side of the road with a video camera recording all of the cars and they all have a little screen inside their car so they can see where everyone else is making sure they're not

colliding with each other. Now, the issue with this is you're streaming a lot of data across the network to make this work. So, you need new networking algorithms to ensure you can stream that much data across all of the validator set. So how do we enable that networking? So the first issue in terms of data just to give you some context is how much data you got to shuttle around the place. So when you're running at a million transactions per second, let's say an ESC20 swap is around 200 bytes. You're now looking at 190 megabytes per second. That is 1.5 Gbits per second. That is not going to run across the public internet. If we have all our validators in one data center, sure that will work. But we want a decentralized network at the end of the day. So you need new compression techniques to

enable you to send this much data around the network. So the way we do this first we use that power law function. Again you see this a lot. We are very big fans of information theory at Sumina. So the way a power law works just for people that don't aren't aware you essentially have the thing that occurs and the frequency of which it occurs and you get this steep drop off where some things happen really really frequently and then there's a very long tail. Uh this happens in sales organizations where the top sales guy will do 100x more than any other sales guy. This works in the games industry or revenues. It happens throughout complex systems. So we take advantage of this by saying okay these contracts and these addresses are going to be called and used multiple times and compress that down to one bit and just

send that across the network rather than the full address string. And just to prove this is true remember this graph from before. This graph also holds true across addresses and state mutations as well. So very important graph. The next we use streaming based compression. So streaming based compression is a compression technique used in video streaming. So first of all, most blockchains don't even compress data because they don't need to. If they do, they tend to use blockbased compression. Uh so you guys, if you're computer scientists, you would have used this at university. Essentially, you have a compression algorithm. You send the data across the wire. Then you have the decompression algorithm on the other side. Um if you went to uni, you probably had this lady where you did the decompression algorithm, the compression algorithm.

That's blockbased compression used in file systems using image compression quite a lot. Streaming compression used in video systems. Basically the way this works is you reference data in previous frames to kind of compress the data stream. So it works really well with video because you can just say this block of pixels is the same as it was in the previous frame or three frames back. Just repeat that again. We can do the same thing with Somnia because we have that global consensus mechanism that's continually streaming data. We can reference data in previous blocks and use that to increase compression ratio significantly. So that's a really important technique that gets us much better compression ratios. The final element is signatures. So signatures as you all know are not compressible by definition. So we across the whole of the Somnia network use the BLS signature

scene. So the way this works for people aren't aware is essentially you grab all the public keys together turn that into an aggregate public key and then we grab all the signatures together batch those and send that as a aggregate signature scheme. So those you can send as a batch and then you can decompress unsign them on the other side. So this works already today in Ethereum. If you look at the beacon chain this is used there. We use this across the whole system. So between the clients, between the validators, everyone uses the BLS scheme, signature scheme. Now the issue with this is we have a backwards compatibility break here because most modern um blockchains use elliptic curve. Now the way this works with Somnia is we enable a backwards compatibility mechanism. So we still work with elliptic curve

signatures. You just don't get the same levels of throughput. You're only talking in the hundreds of thousands of transactions per second rather than the millions of transactions per second. What we tend to find is people tend to be using the really high throughput when they're making gaming applications or trading applications and they tend to embed wallets directly in the application for those and so this isn't a big deal. So these three techniques are how we increase compression ratios uh novel compression algorithm that takes advantage of the power law curve streaming compression and signature batching. This gives us better compression ratios than any other blockchain we know in the market today by about 10 to 20x.

So these four things are the key innovations and how we make Somnia so fast. We have improvements in single threaded execution by taking EVM bite code and compiling it down to machine code. We have a new database called ICDB which allows for really fast read and writes and predictable performance. We have a new consensus algorithm called multi-stream consensus allows for higher throughput, lower latency transactions. And then a new compression algorithm allows for 10 10 to 20 times better compression ratios than any other blockchain in the market today. Benchmarks. Let's actually go through the benchmarks we run, how we ran them and the numbers. So the first benchmark was ERC20 swaps. So here we have 100,000 accounts globally distributed. So all around the world with 100 nodes geographic distributed across heterogeneous infrastructure. So bare

metal and cloud. Each of those accounts was basically doing an ERC20 swap between each other. So swapping a token. And this was done through the JSON RPC websocket API with the BLS signature flow. So with this we got to 1.05 million ERC20 swaps per second. So that is our 50 gigas number. So 50k gas per swap. That's how we get to that number. In terms of latencies, this this little chart here shows the different latencies. In the mean case, you're talking just less than 1.2 seconds. And in the worst case, the P95 is just under 2 seconds. Now, you got to remember this is when the system is redlinining. So going into this worst case scenario. In a normal scenario, these latencies wouldn't go that high. And then this is end to end latency. So a lot of people when they talk about latency, they talk

about block time, which I think is a rubbish number, or they talk about finality. This is the end toend client-to-client latency. So a client saying I want to do a swap that going to the blockchain that being finalized and another client reading that data out. So end to end latency. So the next benchmark you ran was unis swaps. So essentially we were running unis swap v3 a single l people where we had 100,000 accounts all trying to swap in that l people. This is essentially like a big memecoin launch where everyone is trying to trade the same token at the same time and the same pair. So everyone hammering the same pair wouldn't scale very well parallel. We can scale this very well. scaling up to 50,000 unis swaps per second. Enough for any memecoin launch that would happen today. Latencies are on the chart

here slightly better than before because the way unis swaps work. We don't estimate the gas. Gas is slightly variable for this one. The final one was NFT mints per second. So here we are minting 721s. 100,000 accounts all trying to mint the same 721 at the same time. Here we do 300,000 NFT mints per second. Now an very important part to note about this is we only ran this benchmark for a minute and a half I think or two minutes because essentially you get a lot of state created very very quickly if you're doing this many NFT mints. So we price uh creation of state very very carefully in Somnia because you could have massive state bloke with a system with this many transactions.

We're really trying to optimize for onchain computation not for state growth. Uh there are other solutions for that today. So these are latencies again less than two seconds end to end mean case per second finality was way less than a second. So that is a high level overview of the technical innovations of Somnia. Just to recap, we are a high performance EV compatible L1 blockchain, 1 million transactions per second, very low latency and very low gas fees. So in terms of where we are on the journey, we are live in TestNet right now. So we launched our test net back in February with around 50 projects currently deployed, currently activations with end users. I think if you are in the crowd, I'd really advise you to go out and check it out. Um you can go and play around. We have quests,

we have point systems, stuff like that. And if you're a developer, I would say, what fully onchain application did you want to build in the past that you couldn't because of blockchain limitations? What idea did you have that I would really like to put this fully on chain, but you can't because blockchains weren't fast enough. You potentially could now with Somnia. So, these are some links. If you want to follow us, follow us at Somnia_work as updates about the project, about the ecosystem. You can follow me at zeroxpool Thomas. I talk about blockchains and gaming. Um or you can go to the test net link, start developing today. We have developer grants, programs, all that kind of jazz. And if you're an end user, you can just play around the test net and use the applications. Uh thank you very much and hope you check it out.

[Applause] [Music]