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.
Validators are required to submit price feeds, and bad data/nonparticipation results in the validators getting slashed
8/ Frequent batch auctioning
Rather than processing orders sequentially, Sei aggregates all orders in a block together at the end of the block, and then fills them at the same price. This helps ensure price fairness and frontrunning prevention
Sei allows transactions to consist of multiple independent orders. This helps reduce gas costs for market makers that are submitting transactions, and improves block space usage (removes overhead tied to submitting multiple transactions)
10/ To recap, Sei is an L1 that is optimized for trading. It makes use of novel approaches for block propagation, block processing, parallelization, and has a native order matching engine that helps exchanges scale.
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
1/ After building on Terra for while, I get questions about how experienced web2 engineers can get onboarded as Terra developers. This is my journey to getting started
2/ Learn the fundamentals of Rust. Terra smart contracts are written in Rust, and you should familiarize yourself with basic rust programming. You can go through doc.rust-lang.org/stable/book/ (chapters 1,3,4,5,6,8) or go through the rust section of academy.terra.money
3/ Write a sample Terra smart contract. Rather than writing it from scratch, you can use a template from github.com/InterWasm/cw-t… (important: Terra uses cosmwasm 0.16, NOT 1.0)