Beginner’s Guide To Monad: Issue 0003
Quick News 🗞️ — The week began with my internship at The Pipeline.
I’ve refined my Twitter bio and you can now expect more detailed and focused content on Monad Labs.
Earlier on “Keeping Up With Monad,” we delved into the concept of executing transactions (TXNs) in parallel on Monad, contrasting it with Ethereum’s sequential system, all from a beginner’s perspective (Beginners Guide To Monad)
Missed it?
Read the articles below
However, we need to understand the above is only a part of many key factors that ensures monad’s high performance.
Let me restate these keys in no specific order:
- Parallel Execution
- Monad BFT (Pipelined HotStuff Consensus)
- Deferred Execution
- MonadDB
The above keys are the icing that makes the Monad — EVM cake super yummy
On this episode: We will be reviewing one of these icing — the Monad BFT and how it helps to optimize decentralization and scalability of EVMs.
Ride With Me, Gmonads
Beginner’s Guide To MonadBFT: Consensus and Execution Architecture
Let us understand the pointers:
- Consensus Mechanism — Is like a group decision-making process where everyone in that group — has to agree before something can be approved or done.
In blockchain, it’s how computers/nodes agree on the validity of TXNs without needing a central authority.
- Byzantine Fault Tolerance (BFT) — Considering the fact that — something can go wrong during a decision-making process, such as a nodes failure or inability to agree to the validity of a TXN.
The BFT exists as a feature that lets a Blockchain withstand situations when a Node or multiple nodes fail to participate in a decision- making process (consensus).
Scenario: 3 Generals (Validators) of the Monad army divisions (King, John and Danny) needs to agree on a battle plan (Consensus) to take most of the EVM volume (Block) but can only communicate via messengers (Nodes), who might betray them (fail or disagree).
The BFT is the tool, the ability of all 3 to still agree to a battle plan and win the battle despite potential traitors’ actions
Examples of BFTs: PoW of Bitcoins (BFT is mining) and PoS of Ethereum (BFT is staking).
Since, you have probably reviewed the concepts above with me — let us dive right into the MonadBFT as a tool for optimizing EVMs (The Parallel Way).
The facts:
- Monad uses staking as a means of validating — hence it is a form of PoS.
- 2. Monad uses pipelining as an added tool to its consensus processing (more info during the Deferred Execution).
- 3. For any TXNs to pass through 2/3 of nodes must approve of it.
- 4. If 2/3 of nodes approve of a TXN — a QC (Quorum Certificate) issued — meaning it can is valid.
- 5. If 2/3 of nodes doesn’t approve of a TXN — a TC (Timed-out Certificate) is issued — meaning there is a problem.
Now lets check Monad BFT — Using the concept of 3 Monad Generals and the EVM battle — MonadBFT works like this:
1. At the start of each battle planning round, one of the Generals (Validators) is randomly chosen as the leader to propose a battle plan (Block).
2. The Generals (Validators) then vote on the proposed plan (Block) — Each round has two stages: proposal delivery and vote collection.
3. If a Generals doesn’t receive the proposal (Block Info) on time, they communicate with each other to move to the next voting round (next block proposal).
4. The proposal includes details of the new battle plan (new block) and feedback from previous voting round — making it a pipeline mechanism.
5. Generals who receive a correct proposal (Block Info) vote ‘YES’ — If more than 2/3 agree, the next round’s leader issues a Quorum Certificate (QC) to show the plan is good.
6. If they receive an incorrect proposal, Generals can declare a timeout and issue a Timed-out Certificate (TC) to show the plan has a fault.
7. The leader of the next round either confirms the QC of the good plan or acknowledges the TC from the previous faulty plan from the previous voting round — before creating a new proposal (next battle plan in line).
8. If a round leader receives the QC from the previous one, it confirms that all Generals have voted ‘YES’ in sufficient numbers, validating the battle plan as good.
All these is perfectly done by leveraging on the pipelining principles
You can also consider MonadBFT without pipelining on the image below
Now to the last major part of all this Battle Planning is the Shared MemePool
A mempool is a temporary storage for TXNs that have not yet been confirmed nor added to a Block.
Think of it has a diary 📔 — that records ideas status (TXNs status) on the Block (Battle Plan)
In context:
a. On ETH: Each General (Validator) maintains its own handwritten MemePool (Diary) — although the General tries to check and unify the contents (TXNs) in their diary, errors will still exist
However
b. On Monad: Each General (Validator) gets a photocopied version of a MemePool (Diary) — meaning they all maintain same amount and exact pending TXNs at all times
This process further verifies the MonadBFT and rids it of errors by letting Generals to check for failed ideas (TXNs) in a plan (Block) and correct it.
All these been said — I do believe I have successfully confused much more on the major parts of the Monad architectural design.
alright a quick recap: study image below
If that is all: Meet me next time — as we check and confuse ourselves again on the topic — Deferred Execution
- Since, you’ve made it this far , it is sure you love what you have been reading
- Then, follow me on Twitter
- Also Like, Retweet and Comment on this Tweet: Beginner’s Guide To Monad: MonadBFT
This way, I can keep you updated on all things Monad 💜
Once again, thank you.
AkureFirstSon
Discord: akurefirstson
Twitter: @akurefirstson
