Lei Yang

And this process is what we call managing or updating the state tribe.

And before our optimization, state try management takes more than 90% of block building.

In other words, if you spend seven days processing those 11.4 billion transactions, you would spend 70 days on managing the state try.

So in other words, you are kind of only spending 10% of the time running the transactions and 90% of the time like doing transactions.

post-hoc management.

So what we did, I think, which is pretty interesting compared to what other chains have been doing, is we completely redesigned the data structure.

And I think many teams have kind of identified this bottleneck after we did.

And I think what they did was they tried to optimize the database

that stores this state tribe, but I think not many of them has tried to just revamp and redesign the data structure itself, right?

So there's a difference between the mathematical structure and also the physical database that holds this data, right?

I think most people are rearranging the data in the physical medium, but for us, we just completely redesigned the mathematical structure.

And what we optimized for was, okay, so many people are trying to improve the database, but our goal has always been that let's just get rid of the database.

So I think something that's very unique about our state try is it takes so little space that you don't have to constantly update your database.

because you don't have to store it in a database.

You can just fit it in the main memory of your computer, which usually goes at most maybe 128 to 56 gigabytes, and that's it.

So it alleviates the potential bottleneck of constantly reshuffling data from the state tree to the database completely.

And now it's just a very quick memory read.

So I think this, I would say, is one of the secret sauces, like just a complete revamp of...

the Ethereum Merkle state tri-data structure.

Very good question.