A Fast Confirmation Rule for the Ethereum Protocol

Transcript

it provides so much more security than just block dep which is what I think people tend to rely on today Fe blockchain to pay for a coffee don't want to wait 16 minutes the fun allow you to trade but that allow you to withdraw anything anything the block is confirmed why say why implementing it is not that complex the algorithm itself is quite complex because [Music] ethereum has come a long way since its Inception and while it has made great improvements in scalability and security

there are still challenges to address one of those is transaction finality how quickly a transaction can be confirmed as permanent and irreversible today we are exploring an exciting proposal that might cut ethereum's confirmation time to as low as 12 seconds sounds too good to be true let's find out how this is [Music] possible hello and welcome to peen your goto place for deep ties into ethereum's research standards and Innovation I'm your host Puja ranjan and today we are delving into a groundbreaking research

topic that could redefine trans transaction finality in ethereum this is the fast confirmation rule for ethereum's POS consensus protocol to discuss this we are joined by one of the five researchers actively working on this confirmation rule Roberto saltini thanks Roberto for joining us here today thank you P for having me on the pp very excited to be here I have been in touch with Roberto for quite some time and um had the pleasure of meeting him in person at Devcon last year I was genuinely impressed by this research and I wanted to have this conversation even before we have an EIP formally proposed for this

but before diving into the details of your research robotto we would love to hear more about you your professional background and how you discovered ethereum maybe a little bit about your journey with the ecosystem yeah yeah sure thank you pleasure to do so I did uh did get into like blockchain into 2017 I was looking for something more exciting than what I was doing at the moment I was I was looking something new something a space with a lot of problems to be solved and I thought blockchain was perfect fit so six years ago I join consensus where I started a research team focused on distributed systems and formal

verification initially we were more focused like on consortion blockchains but then the focus moved to over the past 3 years to main net and we did a lot of work on the consensus protocol itself or looking at some aspects like the fork choice and um and then recently as the beginning of this month I I moved to the etherum foundation to continue the work I was doing and working on this confirmation rule but also my one of the main my main focus would be on a single loot finality well that's pretty interesting I have known many developers who have started with consensus and landed up in ethereum Foundation glad to see you join here as well and uh I hope

to see you continuing the research work thank you all right so without further Ado let's get into the presentation so yeah as mentioned present on this uh algorithm for the the protocol which is called Fast confirmation Rule and we see soon why this C in this way so we start by answering kind not question what is a confirmation now we look at blockchains in general and so is ethereum we have a chain of blocks each block has a reference to its parent down to the initial block which is called as the

Genesis block so way you have potential multiple different chains we have a tree all of these chains are rooted into the Genesis block but we can many different chains now the the canonical chain which is a the concept in blockchain in general is the chain that the validator believes to be the official one the one to follow of course validators might have a different canonical chains so it is really to be precise a local concept is validated might have a different one generally when people speak about canonical chain in general there refer to the in a way the chain that is common to the all the

Hest valid so they have different chains but there is beli to be one that is common to all of them so with keeping in mind this canonical chain concept we can move to what the block confirmation is and Confirmation is some sort of algorithm and the I think the best way to define It Is by defining the properties that this algorithm must give us there are two I'll start with the one that is called the safety property as this say the most important also the more easy to get a grasp of we want that when we confirm a block this block will

always be will will never conflict with a canonical chain of any honest validator so if we look at the uh image in the middle if we say that Block B is confirmed and then with the passage of time the situation evolves to the situation we have on the left hand side then we're good because B is in the canonical chain of any validator however if it happens that we move to the situation on the right hand side we have a problem as you can see B is not in v1's canonical chain anymore what this means it means to mean different things could mean that our this confirmation algorithm to apply

this wrong or it could be that some of the assumptions that the confirmation algorithm relied upon are not true anymore this is also what can happen this you know defining the assumption is something that is quite important so now that we have Define what confirmation rule or confirmation algorithm is we can explore why we need a fast confirmation so we already have a confirmation rule actually in ethereum and this is finalization when we finalize a block we know that that block will always will never conflict with the canonical chain of any honest validator this unless more than one third of the stake is going to be

slashed and under if this happens it is possible to unconfirm a finalized block as you can see this is an assumptions so if we rely on finalization as confirmation rule we have this assumption we assume that it will never happen than one third of the stake is going to commit slash offenses now there is the problem with finalization is that it is low it is great as it has it is very resilient it has this very good economic property but it is quite slow 30 minutes in the best case scenario 16 minute on average this is quite long to wait for some use cases like you go and use some e blockchain to pay for a

coffee don't want to wait 16 minutes and this there are other cases where this is bable but not ideal like if you move money to centralized exchange then you can't use these funds until the chain is being finalized which is not ideal for user experience so because of this lowness people might come up with some say dangerous solution to speed up confirmation one of the say probably most common is to rely on block depth and this is common because this is something we could do with proof of work but block depth alone doesn't tell us much about confirmation another um way potential is to rely on justify block justify block

also is relatively slow it is at least a ni so at least 6 and a half minutes it is better than block depth but it's still lacking information actually for us to determine that that block is confirmed and the general problem actually with both Solutions or is that we don't have a defined set of assumptions that must thought in order for this the safety property that I mentioned before to hold like we don't have this condition one two three that if they hold then we know that the block will always be Canon this is where our work come in so we have two objectives with this confirmation rule is the provide first

confirmation one two three slots one that's what theoretically we think we can do we also we want to to have a well defined set of assumptions that need to hold for a confirmed block safety property to all this is to provide the user so the user knows exactly what assumptions what they believe to hold to be true to rely on this confirmation R so that they we give they are fully aware of say if you want the risk that they are taking the risk rewards that they are taking between you know the is this assumptions might not and the reward of having quite quick confirmation time now before diving into

the details of the confirmation rule algorithm I need to provide a quick recap of how gaspan Works Gasper which is the theum consensus protocol as the confirmation rule is deeply dependent and very on how Gas Works so as we say gaspa is the consensus protocol of ethereum it's a pro State consensus protocol and it is composed of two algorithms one is the lmd ghost which is a consensus protocol that is synchronous so it relies on network being good on messages being delivered in time and this is the protocol that determines the canonical chain and and we have another

protocol which is Casper FFG which is a gadget that finalizes the block outputed by lmb go FG gasp does not need doesn't rely for like finalization to hold on synchrony they can once finalization when the block is finalized it is this is not going to be broken if there is a network partitioning so like these two protocols complement each other you can see like in the picture below you can think of lmd G providing what is called available chains so there are different chains on the right hand side and FG Casper finalizes some prefix of these chains we will I'll discuss more later

how Casper FG and lmd ghost interact initially what we're going to do will focus mainly on lmd goost but I need to provide still some common Concepts so in gaspa time is is uh divided into ooks and each ook is 32 results we also have a set of active validators and the set of active validators is randomly partition across each slot in each ebook and each uh this partitioning gives Rises to committee so to each slot to assign a committee a subset of the overall active validat set and this

committee is the one responsible for voting in that not and out of this committee one uh validator is chosen to be the proposal so looking at how lmd go protocol Works how web this slot which is called second which has two main phases one is the proposed phase the other one is the vote phase in the proposed phase the validator that has been randomly chosen to be the block proposer will propose a block extending what they extending that canonical chain then at the voting phase validators in the committee for this lock will vote if everything goes well they're expecting

to vote for the block that was proposed this is not necessarily the case can Happ vote for different blocks but they do vote for some block and if things go as expected they will vote they vote for the block that has been proposed now very important Concept in lmd goost is the four Choice function which is the function that determines what the canonical change chain is and this is not based on chain depth this is based on uh the weight of the lmd goost fors so if we just consider lmd ghost no FG like we start from the Genesis block the way it works is that we assign a weight an lmd ghost weight to each block and

this weight corresponds to the state of the validators that sent element goes for any Block in the in the tree of the block that we are considering we are considering like in this case if we consider B we consider the entire tree from that is rooted in B and the way we compute the weight we look at all the validator that have cast an L G for V or any of its descendant we take this the accum the overall stake of this set of validators and this will be the way the lmd ghost wave associated with b and then the way the canonical chain is

chosen is by start in the first block if we don't assume kaspa just the Genesis and every time we we we choose the branch that there the highest in this way this is the way thatd go the termines the canonical chain then the head LW now an important kind of details is the and that this we like it impacts how the confirmation rule is is designed is that if a validator in the same stock votes for two different blocks then we say this validator equivocates and their vote is not counted is not counted at all in

Computing the way now this all of this should provide us enough to be able to provide all the concepts that we need to look at how fast confirmation rule just for lmd ghost initially can be designed we add FFG later at the beginning we take this two step approach as it's kind of embedded it's the we do this because of how the gaspa protocol works we have lmd G and then FFG is essentially a gadget that finalizes the prefix so first thing we need to do is to find at least a confirmation rule for the lmd ghost chain I start as I mentioned the beginning one

of the things one of our objectives is to have a defined set of assumptions we have broadly speaking two assumptions that we rely on one is the one normally called synchrony and this is about timing of message delivery what we assume is that lmd g votes sent by Honest validators are delivered by the end of a slope the second assumption is that we know of value beta and this value beta represents a maximum fraction of bantine State for any set of committees so like we take a given set of slots we there will be we take the union of all the

Committees assigned to this law we assume that there is value beta that we know and we know that no more than beta the total stake of this of the Union all the validation in this committee will be dishonest so maximum beta total stake dishonest which means at least one minus beta total stake is honest this value beta can be just aside the confirmation rule is subjective potentially each validator has its own confirmation rule or each user so the beta is a parameter that each user can choose depending on what they believe to be this this function

now that we've done with the assumptions we can start looking a bit how confirmation rule for LM goost works and as I said before confirmation rule cannot be about block depth what we saw that Metals in determine the canonical chain is the weight lmd ghost weight so it must be about lmd ghost weight not chain that so let's start with this simple scenario we assume that B10 is canonical forever for now and then we for this we run numbers and for our example we assume that a beta is 0.2 or 20% so always we take any contigous set of committees no more than

beta the weight of this committee will be dishonest and for our example we assume that the weight of a committee is 100 so one idea is is that we require that the support for b11 so in this case sb11 is the is what I use as like symbol sb1 means the weight the lmd ghost weight will be 11 so one idea is to require that this lmd G weight is larger than the weight of the committee multiply by half plus beta and that's because we see why it's so if we use this example this should be more than 100 MIP by 0.7 is

with to bet be 0.2 so more than 70 let's say the lmd go support for B1 is 71 the weight for this conflict the lmd ghost weight for this block for sure will be less than half the weight of the committee that's because we know that a maximum paid of the state can equivocate so it's possible that from the above from the like the orange Cloud we have beta taken away but that's for sure at least half s the lmd support for B will be larger than half of the committee as honest validators they never equivocate

so what can happen in this case is that for example as the oh there is a mistake here in the slide um this the other line should be sb12 not sb1 so here in the bottom Cloud we referring to B B12 so in this case we require the sb12 the go support B12 is less than 50 so we take for example 49 now what can happen is that again beta of the state equivocates so they send an lmd ghost not before they send they sent lmd go vard for B1 but now they send it for another l so this happens than the lmd go support for B1

decreases from 71 to 20 this is still 51 which is still higher than the 49 that we have for B12 this means that if you apply this rule checking that the L go support for B1 is larger than half plus beta of the overall committee yes we know that the 11 is canonical for every Hest validat however this is not enough what we want is that B1 is Canon equal now and forever and so let's have a look if this is the case using this R so let's start

from where we got to the lmd go support for b11 is 51 Now new block is pended to it all the honest validators will vote for it we say so that will be 80 because of the new committee I we assume 20 might be dishonest and this weight is then added to the weight wa for B1 which comes up to 131 if we work out the numbers the value that we needed was the weight of the new of the committee now now is because removed we have an additional slot now the weight of the over committee that my vote for B1 is the one for the slot of B1 plus there one for this lot to B3 so

the overall weight is 200 so what the threshold we require which is half plus bet of the weight of the committee is now multiplies by 0.7 which is4 this means that the elm G weight for B1 doesn't anymore meet our threshold that be lar Al plus beta multip by so the question is is then B1 still going to be canonical for the answer is yes even though this thres doesn't do anymore but to prove it we need a clever trick and this clever trick is that initially we assume to know who is

honest of course we don't know but we assume it for the moment and we we represent the honest lmd ghost weight with the letter H so in this case hb1 represent the stake of honest validator supporting that are sent that are considering the cost weight lmd ghost weight for B NJ is the the subset of the overall committee that is Hest so in this case C beta is 20% we take J to be 80 so let's have a look at how we can use this to determine whether the B1 is Con what we're going to require is that the nonest lmd go

support is at least half the overall weight and this is enough because we know that honest validators they never equivocate so for sure the lmd go support for B1 will be larger than half of the overall of the maximum weight that can support B1 for sure B1 will be chosen compared to the any conflicting block now however to work things out we need to express this a bit differently what we're going to require is that the OST H support for on support for B1 is larger than the weight of the honest committee multip by half / 1us effect

now this second line implies the first one is that because the beginning we said our assumption is that the weight of the honest validator is at least one minus beta the weight of the overall to so if we plug this equation J 1us beta W in the second online we then can infer that the lmd cost for V1 is larger than half of the commit now if we run our numbers on this it comes out that HB 11 must be at least 50 so we take just one more stay 51 so this case we have a weight honest weight of 51 supporting B1 what you're going

going to work on is actually we just write things a bit differently the same thing we just use this P indicator P indicator is just the ratio between the lmd G honest lmd go supportting B1 and the weight of the honest committe J this case it's 51 over 80 and of course like it's like it's simple like what we required in the second line in the Red Cloud implies this fraction this P indicator is equivalent to require that this P indicator must be larger than half / 1us beta which is the case in this scenario so 51 over 8 is larger is

roughly 0.63 which is larger than half ID 1us beta which is 0.625 now let's see what happens when we move to the next LW now W becomes 200 J become 160 as we have new validators that can potentially vote lmd go for B1 or a descendant now what's going to happen is that B1 because of the rule we Rec that H B1 was L than after the the overall committee we know that V1 is canonical at the point was canonical for every Hest validator so every Hest validator will then vote for B level or descend in this case

B3 assume that all the honest vot for B13 or even B1 will be the same case where 80 value of 80 again 80 is because we assume 20% might be dishonest that is added to be 11 so the El honest El ghost weight for B1 becomes 13 now if you're going to calculate the this indicator P for B1 is 130 over 160 that is larger than 0.81 which is L than our Target of half / 1us beta so this is great because we saw that pb1 being larger than half divided by one beta it implies

that the lmd go support for B1 is larger than half of the overall Committee in this case is larger than 100 and this is enough to determine that the 11 is is canonical even at the next lot which is exactly what we want now so far what I we have worked in a kind of simplified scenario as we assumed we move to the next lot with the next slot still being in the same ebook this makes things easy because when we move to the next to a slot which is in the same ebook we can just essentially add we have a a new set of validators that will vote but when we

cross EO boundaries it's possible that some of the validators that voted the 20 the committee for the slot of B 11 will also be in the committee for the slot to B 13 so in this case before we had J that was moving from 80 to 160 in this case J moved from 80 to 80 plus X well X is some value this represents the the state of the honest validators that are in the committee of the slot of B3 but they were not in the committee of slot of the slot of B1 but what is going to happen this honest validators they will vote for B13 or B1 depending but

definitely for B 11 they see that is canonical so we have X weight added to the honest lmd ghost weight supporting B1 which becomes at least 51 plus set now we going to work out the new P indicator becomes 51+ 6 divided by 80 + x because X is added to both numerator and denominator we know this is larger than 51/8 which is what we had before and we know that this is actually larger than our Target of half ided by 1us Pap so what we see is that P this indicator P which is again the fraction of the

honest lmd ghost weight over the weight of the honest committee never decreases so which means that once we see that this value is larger than enough divided by 1 oneus beta means that B1 is canonical for as we saw like P indicator this value will never be lower than this threshold and you seen before that if this thres is met then it means that B1 is Cano so basically this thresold is always maintained and this TR implies B1 is canic so you can conclude that B1 will be canonical forever this is all good but we said like we rely on this

temporary assumption is that we know who is honest of course we don't how do we get around this it's actually turns sound to be simple not being able to determine who is honest and who is not we can still determine the M the ghost wave for B1 which we represent with s so it turns out that we you use the original idea of checking that the lmd go support bantine or honest we don't know for a block is larger than the weight of the committee multiplied by half plus beta this actually implies the threshold that we want on this P indicator the one that assumes we know

who is onest so this means that if we have this if we at some point we can detect that this ratio S and W is larger than enough plus beta and we Sorry to introduce another term we we call this ratio Q This implies the thresold we want for p which is again the ratio of honest G weight over the honest weight of the committee implies that this is larger than our desire threshold of path divid y Yus beta which then means that b 11 is canonical forever so having this condition on Q which is measurable as just looks at the lmd cost way

supporting a block and the weight of the overall committee is L enough plus beta we do actually know that B1 will be canonical for of course under the condition that our two assumptions hold now the last bit is that we so far we assume that B10 we wor only B1 assuming that B10 will be canonical forever this is a very easy problem to solve we just start asking this checking this threshold for Q on B1 if this is if it is um if 11 passes this test we move back to the parent B10 and so on until we get to the latest finalized block as we know the latest finalized block will

always be canonical of course unless more than one third of the stake isable this this this that will break basically everything so we don't need to progress beond the latest finalized l so all of this what we achieved so far is a pass confirmation rule or a confirmation we see it's fast the confirmation rule for lmd gos now we need to actually also consider the ffz Caspa part to and this will give us confirmation rule for GPA now Mr Heads Up This I won't be able to go into the full details of of everything here because let's try to

explain here the way the protocol is modified wheng cper comes in is say there is a lot there are a lot of details to it I want to give you a high level idea of how we deal with the problem of integrate like modifying the protocol so that we are also okay when FG gper is introduced just explain a bit how FG Gasper and lmd G interacts with FG Gasper we have the concepts of checkpoints checkpoints are a pair of a block and a number where the block number is an equal and FFG votes are votes are links between the source

checkpoint and the destination checkpoint these eff votes are those that determine which blocks are finalized the key concept is the one of Justified blocks one can think of justifi blocks in this in my picture the green ones are those that are finalized the yellow is the justifi we can think of justify block as candidates for finalization so important concept is that the the concept of the latest Justified checkpoint and th it's important to consider that FFG votes are included in the blocks

themselves and this another concept is that we have this concept of Justified according to the change so if you take the chain of B9 in this case when you say Justified B9 or Justified according to the chain of B9 we mean the latest or the justifi checkpoint depending how we say but generally the latest justifi checkpoint according to the FG votes included in the chain of Ben Bic including any of the blocks that are an and Bine or ancestors of B so looking at how the FK Choice function changes when we consider FG Gasper the way it changes that we start

the for Choice call at the beginning I said let's assume we don't have FG gpas so we start from Genesis block with FFG gaspa we start from the latest Justified check point and then we do remove some branches and this is where the details are the quite detail so don't have enough time the say problematic branch is removed and then we just apply the lmd go for Choice algorithm the remaining one um in this case that's pictur the the arrow the yellow arrows represent lmd go BS for so as before we compute element G weight and we choose the bran

that the highest so essentially high level what we need to do to adapt our confirmation rule to this full protocol for a Block B is to require that this is confirmed according to the algorithm that we explored when only considering lmd G and then requiring that this do B is not filtered out by this when considering Casper FG basically that it is included in this uh orange circle that I have on the right hand side that is one of these blocks if this is true then because we just apply L go for chins to this set of blocks in

the OR Circle we know that b is confirmed according to a confirmation rout that works for lmd go so we know that b is also safely confirmed when considering fmg G this B is not filtered out when considering Casper FG amounts to two conditions essentially one is requir that the epoch of the checkpoint Justified according to the chain of b or according to the FG VES including the chain of B so the EP of such Justified checkpoint is the

previsible this is going to guarantee us that B is not going to be filtered out by Casper FG during the Curren then we need to we have another condition which is going to ensure us that this will not happen in any future even this condition is composed like in in different parts in the the first part we compute the FFG votes for the checkpoint of B and this is because again FFG votes are votes not for blocks but for checkpoints so we look at the weight of the F votes supporting the checkpoint to B and the second line we remove beta of the

committee between the first lot of the current people and the current slot as as this committee might be dishonest and so they might get slashed and do if that's lashed their um FFG weight is removed so with this with with what I have in The Orange Box at the moment we come up with can compute the minimum state that will uh the minimum the minimum weight that in terms of FFG the checkpoint of be will have by the end of the current slot and to this we add the minimum on a stake between the next Loot and the end of the ook as we know that everyone will keep voting for The send to B which also

implies the FFG vot for in support of the set point to B so we can this and so these two boxes together they give us the minimum weight in terms of Refuge votes the support the checkpoint of B by the end of the current ebook and we require that this is L than two of the total stake meaning that we know that by the end of the current e book we'll have enough FFG volts to justify the checkpoint of B and we do have this uh additional assumption for all this to work we assume that this FFG votes will be included in in a block at sometime in the next this is quite a loose

assumption as amounts to essentially like if we're we going to drop the limit on number of the stations in a block this would amount to saying it's enough to have an honest proposal in a stok um now there is a limitation on the amount of justification this could be modified potentially to say we extend this limit is this by adding this FG votes allows us to justify some block so there is this addition assumption that we rely on which I think is quite quite B assumption and so all of this will give does give us a confirmation rule for gasa meaning that you confirm a block what we know is this block will always

beot now there is another property that users might be interested in this is monotonist explain what I mean as we saw before this Q indicator that we li on or the ratio between the lmd G weight supporting a block and the weight of theal committee must be larger than plus we already saw before this might be true today now but might not be true in the next L even though B is canonical forever so this repeat just because this is sometime tricky to like we we might have that again this pressure we say is true so we say B is confirmed then this thres is not true the next Lo but B is actually

canonical forever now this is all good the only thing is that user might be confused when they qu again and they see this block is not confirmed anymore they question well it's be at risk of being re down so before diving in looking how we solve this problem I just want to putting towards this property which is monotonicity we want to have this property that once a Block B is confirmed at a given time it will remain confirm at all future times assuming our under the condition that our assumptions so so that's there is Solutions and is that use a square confirmation only once and I remember that forever there is a problem with this is

that again the assumptions on the network being good and both being delivered time might break at some time and we like confirmation to actually not work under those conditions so of course if we just qu for confirmation once and we just stick to it we keep confirming the block forever even though there is a network partion ideally we don't want that so the challenge of course is that the indicator Q is not monotonic and kind of simple solution we can like take the a solution and restrict it and apply for example only to the current so we can do we can keep track of the longest confirm change since the beginning of

the current ook and we confirm any of its ancestors this makes our assumption stronger as we require like this assumption that on network behaving correctly since the beginning of the current ebook it's not as bad as requiring this to be true since the block was first confirmed or we want to actually also confirm blocks from the previous ebook this is because if you are in the first lot of the current ebook some reason the block might not have receive enough attestations enough enough votes we want to be able to confirm blocks from the previous ebook as well so we can extend this to the

previous cbook by keeping track of the longest confirm change since the beginning of the previous cbook and this does require moving our assumptions on network been good since the beginning of the previous but we think this is reasonable as we don't expect user expect user to use the confirmation rule when they when seeing wrong evidence of the network behaving correctly we don't expect them to you know they see the network is bit sketchy for given number of ebooks and now it seems to be good they likely to rine this confirmation rule reasonably they want to see the network to be good for a long time so there is this tradeoff so the question is now what happens the so if you look at this scenario B is

confirmed we because of this previous rule we force it to be confirmed until the end of + one what we need ino plus2 for B to be for B to continue to be confirmed is that we need a descendant like B Prime to be confirmed by the beginning of a + 2 and this we do need the next assumption for this and this assumption want to highlight is only or monoton if this assumption which is admittedly quite complicated and it's complicated because of how Gas Works we don't have monotonicity we still have safety so this key profit of safety still maintained and this is quite

technical I go over it quickly what we need for Block B to be confirmed again at the in e+ 2 we need that this a point C descendant of B in the next ebook so ebook e+ one we need C the checkpoint of B CB not C but the checkpoint of B to be justified in a chain where C is a checkpoint so maybe like the bottom chain C is a checkpoint in the chain and the chain has enough FFG volts to see CBS Justified we also need that in the chain C has received Enough attestations by the end of io+ one or enough Vols so that the block of check point C is

confirmed what happens then in when we transition too plus 2 we have that Block C the block of checkpoint C it's pointed in plus one is confirmed and therefore B is confirmed as a con this assumptions on point four can be seen in this way like according to the value of beta of the fraction maximum fraction of the own State we have a different belief on how many honest validators uh need to attest for C in the during a plus one that the vertical that the number is the ratio of honest validator so one means all honest validat does not mean all validators all all honest and this goes to just below

0.7 to all depending on and increases with the value of beta for this assumption to all we need to Beta can never be more than 160 but again all this ex assumption is for monotonicity also on Final note this assump assumtion could be removed if you had the easy way to look at FFG votes for check points that are old than previous at the moment we don't have an easy way to do that to implement it with if we had this we could remove this extra assumption we could just go back and Bally making sure that for an EPO between B EPO and the current EO no conflicting justifi check

point can never be created but we can do this easily so because of this we need this extra which again is only required for monotonicity I will conclude with some notes on initial experimentals results these were conducted by Circle they run the confirmation rule for over six days they actually already posted the blog post I didn't update this sorry they what they saw is that 56 blocks were detected as being red down including some the or of depth two but the confirmation rule never got three confirmation rule never confirm the

block that was bued out so this is good for the safety property they did execute the confirmation rule by pulling B noes at the 10c intervals and so this confirmation R will be encoded directly in the client code and executed every time at the beginning of a slot also they estimated the FG weight from lmd the go way which is say in under approximation it said that the results were good that none of the reor blocks were confirmed no matter how the aders presss were tuned in terms of time they got confirmations time between 50 seconds to like 80 80 Seconds depending on the adversary

thresholds our belief is that this is because of the PO we believe that the confirmation rule is implemented directly in the time teams and executed at the beginning of each slot we should be able to confirm block within one slot that's one of the things would be cool to someone help implementing it to proove a concept in a D team and and see if this this is but even though like 80 seconds or we're speaking this one and half minutes less than one half minutes compared to the 16 minutes we with oranization so it's pretty fast yeah so this concludes the we a paper

which go in a lot of the technical details we also already have a consensus PP you're interested and yeah of course if you're interested it me on Twitter more than to collaborate and in in bringing aov Concepts or implementation to thank you this is beautiful thank you Roberto I have have never seen in depth for this all these confirmation rule you talked about Gasper you talked about FFG and all these things these are like really good to see when we are like looking into it how it is actually it can be visualized it's nice thank you for sharing all these things thank

[Music] you I had a list I think you have answered some of the questions already so maybe we can quick look into some of the benefits and use cases of that so if you have any like low hanging fruits for application developer that they may be able to use this proposal and be able to create some apps that could be useful would you like to maybe talk about that yeah one like say obvious one is uh s from P anything that requires low value transactions like paying for a coffee or something that it's let say in

the likely scenario that there is aor unlikely scenario there assumptions don't to and the blocks Lo out someone doesn't is a low by transaction that us case like it provides so much more security than just loock up which is what I think people tend to rely on today so that's one use case another use case is for sensorized exchanges so some this sensorized exchanges at the moment they an optimized algorithms as soon as they see a transaction is included in Block they credit the fund allow you to trade but that allow you to withdraw anything until the block is confirmed of course what happens if they when they credit to the fund then the that block

is real out and then the new trade they need to somehow rever back all of these trades that you made which is quite complicated rather than relying on just inclusion or block dep they use the confirmation rule it's far far far less likely they will have to R transactions which or rward trades which is not great us experience and another application which I think is interesting is related to block building so I believe that for Block Builders knowing whether a block is confirmed or they could also look it in another way which is what is the fraction of adversarial stake

that above which a block that is confirmed may be red out like you can see another way around you say this block is confirmed as long as no more than 20% of the state is is honest and you you can determine this value for each block so block be could use this information to the side of much to build like if they're building upon there is a head of the chain that is a very low value of beta it means that it's easy to to Beed out then I want to be less because there is a risk for them to them build upon this block and this block will be will be Lo out and perh their me is so these are some of the use cases I think this is helpful that is great

definitely having low block time would be helping more apps and uh of course uh different infa providers in between I'm curious you mentioned something about assumptions like there are certain assumptions for this proposal so do you think those assumption maybe act as kind of blocker while getting you know consent from different client teams I don't my view this is my view is that it's been more like 10 teams have been very busy with with spe like in a way they know the good thing and the bad thing about this confirmation rule is that doesn't require anyy hard there was a change required to the F Choice

algorithm for this confirmation route works and that already gone into dun so like in a way it's good because a cent team can implement it independently Al there is no pressure like in implementing it because it can be done at any time so I think it's about the assumptions it's probably about that's my that's what I think about spending the time compared to other things where you know they they need to meet a specific timeline to get better train as they they all need to implement is something that is required for hard for that's right I was just trying to understand if we have enough buy in for

this proposal to maybe moving forward we can have a proposal by the way talking about proposal what do you think could be the expected timeline are you planning to document any proposal for this to be someday deployed on the main net yeah so in terms of uh Miss I'm not the one implementing it so but I feel like it's not too complicated to implement like I was thinking some point of implementing a proper concept myself and the main problem I was in finding where to get the informations in the client C so I think once you know where to get the information where to get the test stations how in in the data structure of each client team then I

think applying the the rule like we already respect so should be relatively straight forward I would say no terms of implementation let expect two three months in terms of having a proof of concept and then we need to do some testing of this proof of concept so terms of getting it to my net know be six months something like six s months per depending how much testing you want to do right and I think uh there is a good news for you I just noticed in the chat tence mentioned that he would be trying to finish this implementation for prism and we'll reach out to you for any question so definitely you got one client in

now it's just recorded from the podcast I can't you can't get away from it that's good I can point exactly why you said it great yeah I think that's one of the idea of having this kind of conversation including all developers so if they find an interesting we can perhaps get implementation sooner rather than later yeah yeah def I say probably just to add to some one of my an think so one of the the difficulties is that why say why implementing it is not that complex the algorithm itself is quite complex because of gpas so perhaps actually

there has been some of the delays are due to actually being able to be comfortable with the prop as the algorithm it is indeed quite complex when you look at the details yeah such as make just being that confident that actually it is correct with everything going smoother uh how long do you think we can see this on mainnet can we expect it with the fusaka the next upgrade after the Petra I would think so like I would hope that that because what happened like of dun upgrade when that was deployed we didn't have the spec PR out yet so I

think like when Factory is deployed that will be a good time probably for developers to pick it up is that will be like a bit of perhaps you know time where they are considering what's next and we have TR now so I hope that it be picked up when Petra is is deployed so to have it by the next one but again something can be deployed progressively not all clients need to have implemented it can be something that is progressively implemented it definitely seemed to be like a high value proposal and would be definitely useful for many of the application as well as layer to Solutions so let's hope it makes its way ways to upgrade after Petra very well uh

with that we are done with big question but we have recently started this new section called rapid fire question round where we try to get answer to questions within 1 minute so the answers that you may have to provide is either a one word or one sentence [Music] all right your favorite ethereum use case decentralized Finance de centralized Asset Management one feature you believe makes ethereum stand out for other blockchains their phosy and belief in decentralization your favorite domain of research execution layer or consensus layer consensus layer if you had to

prioritize would it be scalability or or decentralization decentralization what is the most pressing issue in ethereum governance making it effective and essentialized at the same time one word to describe the EIP process could be improved improvable improvable most exciting recent EIP in 2025 we're excited about the 61110 which is let see I don't have one for awesome thank you so much for answering all these questions um sorry there are no prizes for that but you did great this challenging you did great on that so yeah it was pretty interesting to learn

all about this like this is indepth concept and like very few people are actually aware of how blockchain Works behind the scenes so thank you for sharing all this information thank you for having me very well I think the proposed fast confirmation rule marks a significant step to towards making ethereum faster and more user friendly it's a promising achievement for a better ethereum future thank you Roberto saltini for taking the time to share this insightful overview with our community personally I found today's session highly informative offering plenty of valuable insight for the community to discuss and for client

developers to evaluate the tradeoff and conduct thorough testing the ethereum community thrives on collaboration and research like this dear listeners thank you for tuning in to today's episode if you want to explore this research further check out the resources in the show notes and as always we'd love to hear your thoughts connect with us on social media and drop a comment to join the conversation we'll be back with another interesting proposal for you until next time keep exploring keep building and keep affecting the ethereum blockchain this is Puja ranan signing off