xuejun

Lately, the term “parallelized optimistic execution” has been thrown around a lot of people have asked me what “parallelized optimistic execution” actually means. Keep reading below to find out 👇 In Proof-of-Stake consensus, validators receive a block from a single proposer at that height. Usually, validators wait for +2/3 of the network’s voting power to approve that block before a validator commits and executes the transactions inside of the block. Optimistic execution refers to validators executing blocks before the block has been committed. Instead of waiting for the entire consensus round to finish (which could take multiple seconds), the validators "jump the gun" and execute block transactions in a cloned version of the state, before the block is approved. In the majority case, proposed blocks are approved in the first round of consensus, so when the validators receive +2/3 votes from the rest of the network, they only need to commit the cloned version of the state that they were working on, instead of re-executing all of the block’s transactions, which reduces the time to start validating the next block. In the minority case where the block fails the consensus round, the validators discard the results on the cloned version of the state and restart consensus with a new block proposer. No transactions can be committed without +2/3 of the voting power behind it. Parallel execution refers to two or more transactions being executed at the same time. It’s only possible if the transactions are logically proven to be mutually exclusive from each other, i.e. they update different parts of state. For example, if Alice send a transaction to interact with smart contract 1, and Bob sends a transaction to interact with smart contract 2, and SC1 and SC2 don’t interact with each other, then it’s possible to execute those two transactions in parallel on a multi-core validator. For example, SC1 and SC2 can be different CW-20 token contracts. However, if Alice sends a transaction to transfer tokens to Bob, and Bob sends a transaction to transfer tokens to Charlie, then these two transactions are dependent, so it’s not possible to execute them in parallel and they must be executed serially. In high-user environments, the majority of transactions are mutually exclusive, so executing them in parallel increases throughput and lowers block times even more. Stay tuned for Nibiru’s parallelized optimistic execution implementation!