Excited to announce Sei v2 - the first parallelized EVM, allowing Sei to get the best of Solana and Ethereum - a hyper optimized execution layer that benefits from the tooling and mindshare around the EVM
A technical 🧵
2/ Sei has been live for over 3 months now, and has consistently been the fastest chain out there, finalizing blocks in 390ms. Sei is seeing greater engagement from developers, and the biggest pain point for devs is lack of EVM support. As a result, @Sei_Labs is proposing Sei v2
3/ Sei v2 is a purely additive change. None of the existing functionalities (ex. cosmwasm smart contracts) are being removed. There are three major improvements that are part of this proposal
- EVM support
- Optimistic parallelization
- SeiDB
One of the biggest questions we got when starting @SeiNetwork is how we plan to economically secure Sei in the longer term.
The long term solution? Additive security - lets dive in🧵
2/ One way to take over a proof of stake chain is by having a validator that has a substantial supply of the staked tokens. On Tendermint based chains, this requires control over 1/3 of the staked tokens.
The lower the market cap of a chain, the easier it is to take over
3/ If you get started building on a chain like Ethereum, you immediately benefit from high economic security
If you start building a sovereign chain, you are start off with a market cap of $0, and need to expand the security of the chain from there
The @SeiNetwork whitepaper came out today. There are alot of moving parts, so let's dive in 🧵
2/ There are a seven major areas of innovation that Sei has:
- Intelligent block propagation
- Optimistic block processing
- DeliverTx Parallelization
- Endblock Parallelization
- Native price oracles
- Frequent batch auctioning
- Transaction order bundling
3/ Intelligent block propagation
Sei sends transaction hashes in the block proposal, allowing blocks to get reconstructed locally by validators (by looking at their mempools) rather than waiting to receive them over the network.
1/ @SeiNetwork Sei’s native order matching engine uses frequent batch auctioning (FBA) to help match and fill trades. Rather than executing trades sequentially, market orders are aggregated at the end of a block and executed at the same price
2/ As an example, lets say that the orderbook has 2 limit sell orders, one to sell 1 unit of asset ABC for $10, and another to sell 1 unit of asset ABC for $11. Two market orders to buy 1 unit of the asset come in - what price would they get filled at?
3/ With sequential execution, the first market buy would get filled at $10, and the second one will get filled at $11. Even though both market orders are in the same block, the second order gets a worse price due to its ordering in the block.
1/ I’ve been getting questions about how @SeiNetwork prevents MEV (maximal extractable value). In the longer term, rather than actively trying to prevent MEV entirely, I anticipate Sei validators will use auctions to allow searchers to privately submit profitable transactions
2/ MEV is when validators profit from deciding which transactions to include in a block and their respective ordering. @Tendermint_Core orders transactions based off when they are added to the mempool, but validators can change this code and run a custom binary to profit from MEV
3/ Some profitable use cases for MEV include front-running, liquidations, and arbitrages. In an ideal world, there would be absolutely no front-running on Sei, and there would be no spam associated with liquidations and arbitrages
1/ @Seinetwork is currently working on optimistic block processing to improve block speed and throughput:
2/ During the propose step in @Tendermint_Core, a block is proposed and disseminated to other validators. Validators then send prevote and precommit messages to each other to agree that this is the block they want to commit
3/ After the precommit message is sent, validators will go through each transaction in the block and execute state changes. When there is a lot of data to process, this step can get quite slow