CometBFT for Cross-Chain Communication in Polygon

Transcript

[Music] Hello everyone. My name is Marel Ditson. I work as a staff blockchain engineer at uh Polygon Labs for three years now. And today I will be presenting you the outcome of a very complex and long project we have been working on uh in the last 1.5 years which enables um heal v2 uh by leveraging comet BFT and in this case we'll be looking at how we leverage that for crosschain communication in in polygon.

So as you may know the architecture of polygon chain is a dual layer architecture where we have Ethereum as our um security and settlement layer that we use for finality. Then we have our side chain which can run on bore or argon. Uh in particular bore is a fork of get and it's basically the execution layer. And then we have in the middle Heimdel which is a Cosmos SDK based chain um yeah based on tender mint consensus which acts as the consensus and coordination layer and you can think of it as basically the nervous system of the network uh because it's coordinating uh all the crosschain communication between layer 1 and layer two. So there

are many transaction that go back and forth uh from L1 to L2 and vice versa. We will be focusing on state syncs and checkpoints. Checkpoint is basically uh the way we um commit the cryptographic state of L2 to L1 and state sync the way around is when you want to take the state from L1 to L2. For example, as a user, you want to deposit some funds on a bridge contract and this needs to trigger some actions on L2. Um all of this is basically done by side transaction which are non-user transactions performing the crosschain uh coordination logic and with the upgrade that we lately rolled out on

Amoy test net last week. We are basically upgrading Cosmos to the latest version 050 uh by yeah removing basically a tech dep of more than four years development upstream and we are migrating from tender mint to comet BFT. So since this is not a backward compatible uh kind of upgrade it's a coordinated upgrade where we will be wiping the blocks history and we only keep the application data and we are doing a regen to make it compatible with with V2. We are also lowering the finality time by uh quite some uh high percentage from 90 seconds to around four 5 seconds. We're reducing the block time in handle and we are basically trying to solve the difficulties of

current v1 site transaction implementation where they're basically kind of outside the blocks execution workflow because of the limitations that tenderint had back then and we have to handle them by using some custom ms which make it difficult to reason about and and verify. So with site transaction in V2 we are going back to first principles by um you know using first class consensus logic for site transaction and part of the blocks execution workflow. So here you have a basically an overview on what are the main methods that come BFT can invoke on the application layer going from prepared proposal where the transaction are um included in a set of candidate transaction you can you can order them basically and act as a decentralized sequencer for example then those

transaction are uh simulated and validated or rejected and then there's this key step which is the extend right where you can basically attach nondeterministic data to the pre-commit messages uh and here we basically embed our site transaction which is nothing else than a a stream of bytes, right? Then um we can decode to execute whatever we want to do crosschain and then we have verify extension for the verification of the you know the the site transaction themselves and um at the end in finalized block this gets delivered to the app layer to um basically commit the the state. Um this is the implementation on one use case that we have uh checkpoints where

basically at block X the candidate set of transaction gets proposed by the wrong proposer and the first one by design is always going to be a site transaction and in case we have to submit a checkpoint then it's going to be a message checkpoint and in the same block all the validators we process that proposal by uh simulating it at check transaction and then we extend the vote by embedding the side transaction basically with the vote extension which includes you know the signature of each and every validator which then gets um verified in verify vote extension where everyone ensures that the vote extensions are wellformed and signed and at the end at the next block height at finalized block step the

results are retrieved from the previous block and the uh vote extension which reached the super majority of the voting power will be executed. So that in this case the payload signed will be ready to be submitted to Ethereum. Um yeah I think we can get to a small demo. It's not purely a demo but we will looking at some logs and if we are lucky we will see a checkpoint going through live if the SSH connection is still alive. Apparently it is. So what I will be doing now is to trigger uh a state sync transaction on this um GCP devet where we have three validators running and one sentry.

So what this this doing currently is just generating a deposit on uh L1 which will be then you know fetched by hand and it will be verified by each and every validator extended with votes and in the end um basically submitted to bore to yeah mint tokens or basically reflect the state of uh L1. So as we can see here a checkpoint just went through and we're waiting for the state sync but basically uh at step prepare proposal which happens at this height uh the side message server which is our handler was success you know in checking that the state of the local board matches what is coming from uh L2 this validator specifically voted yes and the same

happened on the other one and then um all the checks on the message server was successful so that at the next step another checkpoint just went through. But basically at the next step, next block height um the the height the the checkpoint was submitted and the post handler will be updating the state and flashing the buffer waiting for a checkpoint acknowledgement which is basically letting paving the way for the next checkpoint uh proposer to propose his it checkpoint. Um and this is basically the the result on Intel where you can see that you have a new checkpoint being submitted and you can even you know uh leverage this block to

have uh a verification on the data by using this command that we have implemented the boat extension decode. As I said, it's just a bite stream, right? Uh, and by the way, yeah, the state sync is what we just triggered. So, it got detected by handle. Everyone voted yes. So, it was successfully submitted. And with the decoding, we see basically that the vote extension was submitted at this height at this round. And we have a set of votes which includes the validator address, the power and its result. Basically, yes, voting. And you can see the um the summary at the end where you see the site transaction with this hash uh voted by yeah 100% of the voting power. Um and this is basically whatever gets

submitted to L1 which matches what we just seen for the checkpoints. And if we want to see also at the state sync level, this is what just got submitted. Yeah, one minute ago, which is whatever we just triggered on um on that tap net, right? So yeah, uh I think that is basically it for the demo. So just wanted to present you that the way we migrated to um v2 um will basically brings nativeist support for ABCI++ and both extensions and site transaction now for us are truly native and part of the dynamic blocks execution workflow provided by comet. We migrated uh Amoi test net successfully last week

and mainet is coming up soon um in the next two weeks and this is just you know paving the way. It's just the first bidding block for what's coming next on polygon chain with um validator elected block producer faster finality that we achieved and reduced block time and next is going to be the integration with the act layer. Um yeah that is it uh for the presentation. Thank you. Um, happy to take any question. [Applause] I think we're good. Thank you.

[Music]