Protocol Berg Workshop: Aliasgar Merchant - CometBFT: The Shooting Star of Blockchain Consensus
ETHBerlin·Wed, Oct 9, 2024, 12:00 AM
Speaker
Ali will introduce CometBFT and discuss the unique features that set it apart from other blockchain protocols. You will find out why CometBFT is quickly becoming the preferred choice for decentralized applications and how it is addressing the scalability challenges in blockchain technology. During the presentation, Ali will take a deep dive into the technical details of CometBFT. You will learn about its code and architecture, and explore the cryptographic primitives that keep it secure. This part of the presentation will be especially interesting for developers and blockchain enthusiasts who want to understand the inner workings of CometBFT. Furthermore, Ali will discuss how CometBFT is contributing to the realization of decentralization in the blockchain industry. You will find out how CometBFT is enabling decentralized applications to thrive and empowering individuals to take control of their data and assets. Finally, Ali will also introduce ABCI++, its features, and its potential impact on the blockchain industry. This presentation is a must-attend for anyone interested in the latest advancements in blockchain technology. Aliasgar a Blockchain aficionado, has over five years of experience in the field of web3. He first dipped his toes into the blockchain world in 2017 with Ethereum smart contract development, before moving to the cosmos ecosystem in 2019. Currently, Aliasgar's serving as a Developer Relations Engineer at Informal Systems, where he works on CometBFT, a fork of the Tendermint consensus algorithm that powers Cosmos SDK and other Cosmos Blockchain networks. https://protocol.berlin
Transcript
presentations that he did on ABC Plus+ he talks about this exact same problem and he tells and in talks about like how they envisioned ABC i++ to solve it so now what happened inside of ABCI Plus+ as you can see like now at every stage of the transaction the state machine is getting or giving messages back to the application and I'm I'm transcribing this in like very simple terms but like it's much more complicated than that so at every stage the state application engine is sending message receiving messages from the state machine and keep keeping State machine in the loop such that it ensures that that the state machion also has the ability to like modify the transactions as and when needed so let's talk about like these different functions for a minute and and let's see what happens inside of these functions okay so let's start with prepare proposal before that just remember these functions begin begin block deliver TX and block and commit uh because we will have to refer them later on so just remember these functions okay so what happens inside of prepare proposal um so the when the proposal is ready is getting ready the state machine will tell the application that we're ready to create the proposal so now at this point the state machine has an option to maybe say okay we here is our definition of The Proposal so like please check if this proposal is in this format or like we we would want to like maybe um prioritize one transaction over the other so like like you need to do that so all of those things are like being done in the prepare proposal the most important thing is like the sanity of transactions being checked here and and then in process proposal um like the proposal is ready it's given back to the application saying okay we have a proposal that's ready please check if it's like correct and we're ready to like publish uh we're ready to like give it to the consensus engine um extend extend W is is is one of the most fascinating things so um right before the consensus happens right before like the Val start agreeing on the proposal a final call is made to the application saying that do you want to like extend your word do you want to add something to the to the um voting part and this gives the application an opportunity to like add something um and and this this opens up like Suite of applications like in oracles or like in in other places where you need to like add a certain like thing that in the last minute that that can be um that can be added to the consensus engine and um like how is that done we'll see in the application because like this might sound a bit dry like how is this happening but like once we do the app walk through it will be like much more clear like how is what extensions happening and how is it being um checked which is again in the next part which is verify wood extensions uh so this is an opportunity for the application to verify that the votes coming in are like are they correct are they according to how the application imagines the word to be that's being done inside of um verify word extensions and lastly we have finalized block so remember like in the beginning I said like remember the the three things begin block end block and um deliver TX all of that is um collapsed into finalized block where like we don't have like now three steps going we just have like one final block where we we say okay this is the transaction and now it's being fin finalized um and lastly commit is is just like committing to the blockchain so when I demonstrate the app that will be like much more clear to you okay so let's do um a quick a demo so that like we can go through these functions and we can like understand like more clearly like how is how are these happening okay actually before we start the demonstration I just want to like quickly tell you what the app is so that like your head you're clear in your head it's a very simple application where you can send messages and you can query the messages okay so you so the way the transaction will be structured is you will have a sender and then you will have a message like what's the message and what's the sender um and through that we'll like demonstrate the different function that we just saw like prepare proposal Etc so uh um sorry if you missed this link it is available on this particular repository you can like follow along if you want uh but just a quick disclaimer this is temporary and will be available only for a few days the same app will be available on the official com comat BFD docs so that's where you would find it like later on but if you want to like still follow it right now or just like f the core and just play around with it you can like do it um through this particular link there are certain like pre-configuration required like like um you need to initialize a chain and all those kind of things so that's all that's available on the comment B website so you can like follow along from there um like for sake of time I'm just going to like start the blockchain right uh because I've already done all the configurations and everything but it's it's very simple you can just like follow along on on the web page okay so as you can see we have got our blockchain running and the way we'll do it is like first I'll show you how the application is um how what what the application is doing and how it's running and then we'll walk through the code and see like what exactly are those functions prepare proposal process proposal doing in in the context of application is it sufficiently visible to everyone or should I make it bigger okay so as I was saying we have the transaction is in this format where we have a sender and a message so let's say um since I'm a Harry Potter fan I'm going to to be using Harry Potter terminologies and terms so let's say we have the center is a dumble tumble door and then um the messages wand okay uh what just happened is if if you can read this was an invalid transaction format because I did not format the transaction correctly the colon came on the end instead of in after the message so okay so the transaction did go through and we have a hash that's been created so the message was successfully sent how do we know that let's query the message I just realized I spelled dumbledor wrong Dam okay but anyways um you can see that the message wand was created so that was the demo that was like what's happening let's go into the code so the structure of the code is very simple you have got inside of ABCI you got app. go that has all the functions that that's the most important part that you need to need to look at and and that's the part that we are going to like look into this demo for all other things like um like how are the messages being processed how are they adding to the database like what is the moderator doing all of those things are in different helper functions and like inside of model folder so you can like if you want to tweak the application you need to like modify those functions as well but in our case we just have to look at app. goo okay so the very first thing that happened okay so the very first thing that happened um and by the way like app. go has everything so all the handshakes all the like initialization of blockchain everything is happening inside of app. go and I would love to like go through these things as well like but I think interest of time we should focus on the the important functions of ABCI okay so the very first thing that happened was the transaction went through CTX um and what's the use of CTX CTX the very first function that it does is it checks the sanity of the transaction format so it checks if the transaction was correctly formed or not and um with the blender that I did like where I put message later uh I mean like the the colon later that was like an in formed transaction which basically meant that the transaction was not in the correct format so I got this error inval transaction format um but that's not the only thing that cheex does check TX also does a couple of other things it also checks if the user was banned or not how is the user getting banned we'll come back to that in a minute but it checks if the user is getting banned and then it um it also checks if the user exist or not so in this case dumble Lord was not a part of the datab base so it created dumble door in the in the database and um make sure to append the message make sure that the message could be appended to dumble later and and then the transaction goes into prepare proposal so let's ignore the first section of prepare proposal because it's deals with v extensions and we'll come back to V extensions in a minute minute but I just want to like go to the second end where um what happens is the transaction is now added to um to this array where it can be uh it can be like processed so in this case in this situation they're just like being added to this so in this case they're just being check if it's not banned and then like added to appended to the string and inside of process proposal two things happen the very first thing that happens is um it's being sorted so what could have happened in prepare proposal is there could have been a transaction that could ban you but you very carefully place the transaction just below the transaction that was like good so what just happened with that with with that transaction um you you could try and fool the the application so in process proposal we make sure that that doesn't happen and uh we first sorted so now all of the transactions that are like are like the one ones that could could ban you are being placed on the top so if that comes on the top you're just banned out right so all the the transactions below that even if it's a good transaction will not considered and then in finalized block um so like up till this point all the transactions are good and they're just like being added to they're just like being ready to add to the database so they're just being added to the database appended to the database and in the final step they are being committed so in the final State they just being um written to the database persisted to the database okay so now answering the questions two questions right that we have in mind what was like how would the user get banned A and B what is what extension that what is it doing so again like coming back to our demonstration we said that like in word extensions you could add data at the very last minute so what's happening is we have defined curse words that if a sender uses a particular curse word then that user should be banned and there are two parts to it one is we can Define curse words in the Genesis file so we have a couple of curse words that we have already defined in the Genesis file and the second thing is we can add new curse wordss so what happens is like I cannot really show you how the the words added because like that would need um more noes I'm just rning on a single note so I cannot really add but um what would happen is like you could add a new curse word and then that curse word would be should be such that it should be like at least two3 of validators should have that same curse word in their um in their word extensions only then it could be added to the list of curse words so let's demonstrate that so we have a sender Malfoy who is our willing and who is going to send the message mugel and as a wizard that's pretty offensive to use the word muggle and we [Music] will ban Maloy so what really would happen is um the transac wouldn't go through and the user would get banned so the transaction didn't go through so what happened is coming back to prepare proposal remember I said like um ignore the first part of prepare proposal for a minute so here's what happens like now prepare proposal gets all the different curse words from the previous height so if all the validators would have agreed on a particular word to where curse word that would have been on the previous side that have that would be included in the next Heights um prepare proposal so it checks if the word coming in is a curse word and if it's a curse word it does the following it blocks sorry bans the user puts the US um puts the user in the ban users and like just cancels the transaction so that just happened with us where the user got sorry yeah where the user got banned so if I try and send a message which is not a curse message with the same user so let's say I'm going to send magic you could see that the user is banned why because once you do a transaction that's that's that's um a Banning transaction you're no longer allowed in that and if you remember the the three things that we were checking in check TX this was one of it right the user is banned or not and uh in prepare proposal once we got the transaction with the Banning message we added him to the ban list and then in the next transaction onwards the check TX will just check it and outright reject the message yeah so um this is what's happening inside of um W wood extensions like you can add the the word and then in verify word extension what we check is if the if the word is not being added more than once so why do we do that basically it's just a simple way to demonstrate the verify wood extension but in this case why we are doing it is because let's say um there are five valid validators and if one validator says that magic is a curse word and four don't then of course that will not be added to the list of curse words because it doesn't meet the Quorum of 2/3 but what if a validator being Sly just adds the same word five times then that would fool the application where the application would think that okay five times a word is coming that mean like all the five adors agree to that particular word which is incorrect right so um in verify word extension we make sure that the word is being added only once so that the value doesn't not try to cheat US okay um so yeah that was um that was I think we covered like all of the different functions that we have in BCI Plus+ so yeah that that's it um thank you so much for like staying back really appreciate you guys um and you a quick like handles for Twitter and telegram Etc you can let reach out to us and talk to us thank you so much for
Automatic transcript — names and jargon may be misspelled.