Recent Latest Message Driven GHOST with Luca Zanolini | a16z crypto research talks

Transcript

okay welcome everyone to today's a16z crypto research seminar uh very happy to introduce Luca zanolini um Luca recently finished his PhD at University of burn working with Christian k catchen um and ever since he was a graduate student and now continuing to today sort of where he's at the ethereum foundation um he's sort of been a leader in sort of synthesizing classical models of consensus with the developments that have been happening um in blockchain consensus so I'm looking forward to hear about his latest stuff today Luka hi everyone thank you for having me here today I will talk about our latest work with Franchesco damato uh in this work we device air lmd ghost a dynamically available consensus protocol that can be

thought as a potential substitute candidate for replacing lmd ghost the con the consensus protocol with the component of Gasper the current implemented consensus protocol within ethereum that copes with Dynamic participation moreover seeing that these dynamically available Protocols are synchronous protocol we observe that most of them I mean most of them all of them fail in whenever when a synchrony a synchronous perios come and in this work we found we device we find a trade-off between dynamical availability and as synchron resilience and I will also specify what a synchron resilient means in this context but let's start with

some background I will start to introduce the notion of consensus so that we can all synchronize with terminology here I will use the term consensus and total order broadcast interchangeably meaning a protocol that outputs at every well behaved participants as the same sequence of blocks or in particular that outputs a chain at every well behave participants and satisfying these two properties safety and livess here seeing that all the protocols that I'm going to present will proceed in rounds also the notion of consensus and in particular of property safety and liveness are defined with respect to rounds and for example

in the case of safety we have that for any two rounds R and R Prime during an execution and for any two honest participants VI and VJ at Round are and RP Prime respectively we say that the the chain output at participants VI VII at Round R is a prefix of the chain output at participants bu at our round RP prime or vice versa this is the safety safety property and as you can see also safe also the liveness property is guaranteed also for uh with respect to rounds let me now introduce and present the notion of dynamic participation in the context of uh distributed system recently Dynamic

participation became a key requirement for devising specific class of permissionless protocol and in particular with Dynamic participation we are able to encapsulate the the behavior of a system that enable participants participating at the protocol to go offline stopping to participating at at the protocol or to coming back online or to become online for the first time the very first pro permissionless protocol that worked under Dynamic participation can be thought as the Bitcoin protocol but one of the first formalization of this behavior in the context of distributed system came with the Sleepy model of consensus bypass and she in 2017 in this model which is a

synchronous model an execution proceeds in rounds at every round there are some participants that can be a sleep or offline meaning that they do not participate in the protocol at the time or online or awake then in and there they participate in the protocol we have the requirement that at every round or at any time step the majority of the participants that are online are honest this is the Sleepy model of consensus and pass and she Dei devised a consensus protocol working in this model we say that a dynamically a consensus protocol in the Sleepy model is dynamically available so from now on when I say a

dynamically available consensus protocol I refer to a consensus protocol satisfying safety and liveness as in the previous slides in this sleepy model one problem of one limitation of this dynamically available consensus protocol from the cap theorem is that they do not tolerate Network partitions in other term dynamically available consensus protocol must be synchronous in other terms we mean that it's not possible to find one consensus protocol that outputs one chain that is both dynamically available and that can guarantee transaction final finality in the case of network partitions yes so a question about the

sleeping model the way you described it it sort of sounded like the a 50% threshold was built in to the sleeping model yes is there I is there something special about a half in these considerations or uh usually like in synchronous model is the minority is like the better like resilience that can tolerate so they try to model this kind of resiliency also in the system by enabling just the majority of the AWA participants to be uh honest I'm just wonder is it conceivable you could get more properties if you assume 2/3 like have a version like it seems weird to say like a version of the sleeping model but with two3 right it's a little right the sleeping model has codified inside this notion of majority yes even though

there are protocols that tolerate one3 so it's not really the Sleepy model as originally thought they are just a modification enabling some small changes but the sppy model assumed this majority uh noi Tas and say device has a potential to potentially overcome this impossibility result devis this e and flow family of protocols an e and flow protocol is a protocol as a consensus protocol that is made by two components or by two protocols each one with their own with own confirmation rule outputting one chain each and one component is a synchronous dynamically available consensus protocol so one of

these two component is exactly this protocol that enable Dynamic participation and another component is a partially synchronous consensus protocol which aims at finalizing blocks output by the synchronous dynamically available protocol and because of that the chain output by The partially synchronous component it's a prefix of the chain output by the dynamically available component interestingly the Proto Gasper the protocol currently implemented in ethereum can be seen in some way as an e and flow protocol at least having this same structure where lmd ghost is the synchronous dynamically available component and Casper is the partially

synchronous component for finality in other ways lmd ghost outputs an available ch chain and Casper finalizes blocks on this chain here I put a question mark next to dynamically available component and the reason will become clear soon and because of that also our protocol will become the reason behind our protocol will become also clear let's first start to give have an overview at lmd Ghost Protocol as originally thought lmd Ghost Protocol is a synchronous protocol that copes with dynamic partic participation so it allows participants in this protocol to vary in the participation level it proceeds in slot every slot consists of

two Delta rounds where Delta is the message delay 32 slots Define an APO we are considering n validators participating in this in this protocol every validator has a stake the set of validators here is partitioned into this joint committees one committee per slot each slot has a proposer randomly picked from this committee and it proposes a block at the beginning of this slot all the other validators in this committee vote for optimistically for the block that has been proposed in this in this lot lmd ghost is equipped by a fork Choice

function a fork Choice function is a deterministic function that is locally computed by every validator and that outputs a canonical chain which is a chain that um is made is output by this virtu function based on my current view So based on the set of messages that I've received so far in the case of lmd Ghost Protocol the fork Choice function that is used is the lmd ghost for Choice function and originally this for Choice function how it works is that validator feed into this for Chase function its own view so the set of messages that had received so far the Fortress function starts from the

Genesis block and it goes through all the block three and it chooses if we find the fork it chooses as a next block the child with the heaviest subtree and with heaviest sub threee we mean with the most stake weighted latest votes on his descendants observe that this is a sort of vanilla Fortress function in the sense that the currently implementing for Choice function within ethereum is not properly like this and the reason for that is that what it's implementing now also has to account for the influence of Casper on top of the protocol while here instead I'm just analyzing lmd ghost as a single protocol what happens is that during an

execution the proposer evaluates The Fortress function based on its own view this Fortress function outputs a canonical chain and the proposer build a block and that pend this block on the tip of this canonical chain it broadcast the block the voters before voting execute the fork CH function based on their own View and optimistically this canonical chain will have as a tip the block that has just been proposed and they will cast a vote on this block the problem is that lmd ghost is not dynamically available yes so when you so latest that just says like each validator you're only going to count them once you only count the latest vote that a validator cast so for example if

I cast a vote then I cast another vote and another vote I only count the latest one and it's latest with respect to like slot number yes yeah okay um and then I almost can you say much about the original motivation for this Fork chint function because if I've got my history right this was first developed in a proof of work setting when they were thinking about cranking up the block rate in Bitcoin and we're worried about having lots of Orphans and so you wanted things to still count sort of even if they were orphaned and here with this like deterministic block timeon Pro a stake model it's less clear to me the intuition why this is a good idea to be honest I don't know historically why this forun function has been chosen I

know that they started with the Ghost Protocol and they did some modification also because the original Ghost Protocol is not based on votes but it's based on number of blocks that are touched in order to count this heavy but the reason why the historical reason behind that I cannot say right now I need to read about it more but yeah so one of the problem of lmd ghost is that it is not dynamically available and always no proved a balancing attack against this uh protocol where this Pro this attack works by assuming the fact by assuming a malicious proposal and

this malicious proposal exploit the fact that the view that every validator has that is used to compute The Fortress function is local meaning that an adversary could exploit this the fact that views are local by creating conflicting views among two subsets of validator for example leading to conflicting canonical chains and this has been shown to be kept going on forever preventing liveness of the protocol and because of that preventing the fact that this is consensus protocol in the dynamically available setting another attack has been shown by exploiting the existence of committees

in the protocol and this is called ex an reor attack where the adversary could can exploit the fact that seen that in this protocol we are counting all the latest votes that have been cast from the Genesis until slot T where we are evaluating The Fortress function and seeing that the validator set is partitioned into committees in every Epoch the adversary could exploit this fact by withholding all the malicious votes in every committees and releasing them later on time this has been shown to enable reor attack where parts of the chain can be reared and these of course prevent safety so with these two attacks

we show we have SE we have seen that lmd ghost is not dynamically available at least in this formulation a solution to this problem has been presented by damato noas and say with the development of goldfish goldfish is a synchronous consensus protocol that enjoys safety and liveness and because of that is dynamically available goldfish Builds on top with on top of two mechanism one is called View merch and with the view merch we prevent balancing attacks in the sense that view merch is a technique that is used to coordinate to synchronize the view of the proposer with the view of the voters in the sense that the proposer now it computes the

fortras function before proposing and other than proposing the block it also broadcast its own view if synchron holds a voter before casting a vote it merge it merges this view received by the proposer with its own view if synchrony holds and the network delay is respected this view of The Proposal will be a super set of the set of the voter meaning that the voter when feeding its own view in the Fortress function the result will be the block that has been proposed so that in this way we prevent balancing attack another technique that it builds on is this vote expiry where basically we enable we an messages with

an expiration period of one slot in other terms now we don't count in the fork Choice function we don't count any more all the votes that have been cast from The Genesis block until slot T but we consider only the votes that have been cast in slot T minus one meaning that only votes cast at slot T minus one influence the pro protocol Behavior at slot T the combination between view merge and vote expiry implies reor resilience which implies also dynamically available so here now we found a protocol goldfish which by the way it also has a very similar structure to lmd ghost in the sense that it proceeds in slot we have committees in

every slot there is a proposer there is a voter now goldfish can be thought as a potential replacement for lmd ghost in the sense that it tenancies LM ghost with a similar structure and it also allow to achieve dyamic participation the problem is that because of how we count votes in the sense that only vote cast at slotty minus one influence the protocol Behavior lot T if Network partitions if in general a period of a synchrony comes and a period of a synchrony of just one slot this might lead to lose completely safety of the chain in the sense that if periods of a synchrony of one slot

happens what could happen is that all the votes cast a slot T minus one might never enter the views of the validators because synchron is not holding so we cannot guarantee anything because of that in slot T when it's time to evaluate the Fortress function we might not have any votes received in slot T minus one other than mine that I cast in slot T minus one and potentially votes cast by malicious adversary that forced them into my own View and because of that even one slot of asynchrony might lead an adversary to reor completely the whole chain in if we are considering only goldfish without any kind of partially synchronous gadget on top of it so what we asked ourself is that is

can we have a sort of tradeoff between Dynamic availability and a synchron resilience in the sense that we know that this kind of protocol cannot tolerate Network partition this is a possibility result but can we in some way give up a bit of resiliency in the adversary during dynamic participation but enabling some sort of resilience to bounded periods of asynchrony and this is what we device we device a protocol that is able to achieve all the nice properties of goldfish and that can resist bounded periods of a synchrony by removing a bit of by adding a bit more constraints on

the resiliency of the protocol to considerations based on what I just said it seems that strict vote expiry does not seems to not be compatible with resilience to a synchrony in the same with strict vote expiry I mean vote expir of just one slot while not expiring votes so by counting all the votes ever cast seems not compatible with Dynamic availability as I mentioned with lmd ghost so we devis this air lmd ghost which has a very similar structure to lmd Ghost and goldfish it's a synchronous protocol it proceeds in slot of three Delta rounds each so not anymore in two Delta rounds

lmd ghost but three Delta rounds exactly as goldfish we consider n validators here we are removing subsampling in the sense that here we are not we not don't have anymore the validator set partitioned into this joint committees but in every slot the whole set of validators vote each slot has a proposal that proposes a block at the beginning of the of the of the slot all active validator vote in the same way as just as it happens with lmd Ghost and with goldfish the last part of the slot are used is used for this view merch technique that I will present

later we parameterized messages with a generalized vote expiry period so we are not considering anymore only votes cast in slot T minus one but we consider a um expiry period of AA meaning that only the latest votes cast from slot T minus AA until T minus one influenc the protocol Behavior so we increase the range where we consider messages and we Pro that lmd ghost extend and generalizes both lmd ghost and goldfish it also keeped with a fortress function and very similarly to how lmd ghost and goldfish works it considers only the votes cast from

latest votes cast from slot T minus zaa until T minus one disc carting equivocation and this is what is used to evaluate the Fortress functional slot T and this is the P code so in some sense we have this kind of framework where we have protocols proceeding in a very similar way so with this propose phase vote phase and view merge phase that in some sense are uniquely identified by the behavior of a fortress function in the sense that we have the kind the behavior of the protocol and by defining the Fortress function we obtain either goldfish if we are only considering VES casting slot time minus

one we consider R lmd ghost if we consider votes casting in this range or lmd ghost if we are implementing this view merge technique in also in lmd ghost where we consider all the ever cast and so you're basically saying you have a protocol kind of parameterized by the fork Choice rule yes and then just that just gets plugged in in the proposed step and then also again in the vote step yes we have this Behavior where at the beginning of the slot there is a proposer votes voters and view merge and basically the only way that it changes is how the proposer the decides the chain upon to append block or the voters how to select the chain chain in

order to cast a vote and this is done by by following the rule of the Fortress function so by defining a fortress function we obtain goldfish lmd ghost or LM air lmd ghost depending on where you and ideally I would think you'd want properties of the fork Choice rule which when plugged into this protocol gives you properties of the yes protocol okay yes so now we ask is it done like is it just enough to increase the range from which taking from which we take the messages and then just by assuming that at this lot T we want that the majority of participants are honest is this enough as it happens with the Sleepy M as it happens in goldfish actually no

the reason for that is that now seeing that we are increasing the range from which we are considering the votes for the CH fortras function we might consider a scenario where there is a latest unexpired vote cast by a validator at some point in this range but that at slot T this validator is not anymore awake it means that it the vote that it cast is not up to date to the current slot meaning that the adversary could potentially exploit the fact that there is an an expired latest message that is not up to date a lot T and it could use this to place some sort of attack as it happens in the context of lmd cost so we gener we need to

generalize the Sleepy model by defining this to Sleepy model here just some notation HT is the uh the active validator the active validators honest validators as lot t a t are the adversary and H St are all the honest validators active from slot s until slot T and we Define that for some tow that can goes from one to Infinity this condition is required in other terms here here the intuition behind behind this is that a slot now let's not focus on the on this T minus one here I just want to give you an intuition intuition is that that's slotty we need to consider as adversary the adversary

and all the validators that have been active at some point between slot T minus one and T minus to that cast a vote or that can could have potentially cast a vote but it is not active anymore at slot T So in other ways we have to give away a bit of resiliency a bit of adversar resiliency but as we will see we will be able to obtain some interesting properties when it comes to face as synchrony so again we are considering as adversary both the adversary and all the validators that were have been awake at some point in the interval T minus to T but that are not active anymore as lot

T so we need to count as adversary validators that are not active active and we call this condition to sleepiness turns out that rlmd ghost is a dynamically available protocol or to be more precise is a to dynamically available protocol what does it mean to div dynamically available it's just saying that is a consensus protocol in the to leppy model so by assuming this condition and erand GH is AA dynamically available where AA is the expiration period that we are considering in other terms like the optimal probably choice for as a good trade-off between adversar resiliency and expiration is to fix AA

to be equals to T and we are considering basically this equation on the expiration period and we can have a dynamically available consensus protocol assuming this condition moreover lmd go results also in a protocol that is a synchrony resilience what does it mean first of all we have to Define what does it mean periods of asynchrony for periods of asynchrony we are considering a period where to sleepiness doesn't hold so we cannot do any kind of assumption related to adversar resiliency and what we want is that we want we say that a protocol is a synchronous is a synchron resilience if

any honest proposal made before a synchrony will always be in the canonical chain of every validator that is active before a synchrony after a synchrony the intuition behind that is that if before a synchrony we have a set of validators that have a canonical chain and we are under synchrony so everything is good we want that during a synchrony and after a synchrony those validator that were active before a synchrony will never decide something that conflicts with the chain that they decided before a synchron of course we cannot guarantee anything for the participant for the validators that join during a synchrony

because of course they could be manipulated by the adversary but at least we were able to find sort of condition that enabled us to preserve some sort of safety in some sense to those that were are awake before a synchrony and could you mean any honest proposal or any honest confirmed proposal yes so confirmed yes sorry yes thank you we say that ERM the ghost resist to periods of a synchrony of AA minus one slots the intuition behind that is that if we have messages that expires every for example two AO just to give a number and we have a period of a synchrony of less than two epochs say one Epoch it means that after these

asynchronous periods end ends votes are still valid so we are still we still can rely on them in order to make make decisions in the context of the Fortress function of course this is not enough in the sense that on top of that we also had to find a necessary condition for for this to hold in the in the sense that here what we want is that during a synchrony not too many validators join the protocol and the intuition behind that is that let's assume that we have 100 validators before a synchrony but during a synchrony 2,000 validator Center they can be manipulated by the adversary and the contribution of this poor 100

validator before a synchrony is completely lost so we have to require this condition that is exactly what I just said so we want to bound the joining rate of the validators during a synchrony we have that if this condition holds and if an asynchronous period happens then we can guarantee safety to all the honest validators that were active before a synchrony and that they remain active throughout the period of a synchrony so that for them after a synchrony nothing conflicting is decided and optimistically also to them to those that join during a synchrony can after a synchrony heals from a synchrony by adhering to this same chain and yes so

LM ghost resists P of a synchrony of AA minus one slots by assuming this AA sleepiness condition and this condition so so yes now what what happened is that we have this kind of protocol where by doing a sort of trade-off between dynamically avilability and a synchron resilience could be thought as a potential candidate for Gasper or at least from a theoretical point of view from a practical point of view there are still some issues that we need to figure out and the main issue as I imagine you already understood from the beginning is that here we are requiring the whole set of validators to vote in every slot and this clearly is not very easy to achieve

from a point of view of throughput so this is probably the major block that blocks us to go further but at least this is a sort of starting point to think about how we could better device protocols considering the possibility of a synchrony in this kind of system can you clarify why you need everybody to vote every single time why why why is it so we have to prevent the exante reor attack if you remember like the ex exan RoR attack as I introduced let so why can't we just ignore votes from people outside the committee F getting why the committee doesn't work like in the same

sense that as before the adversary could use unexpired latest votes cast from this range from each committee and gain weight and it placed the kind of similar attack of exante in the sense that what we figured out is that the the existence of subsampling leads to ex Anor attack and this is also one of the things that we are trying to figure it out in the sense that is it possible to achieve any way a synchron resilience even with protocols with subsampling it seems that with goldfish even though they have goldfish

has subsampling however given this stct vote expiry H the power that the adversary could gain is useless in the sense that already after one slot votes are expired meaning that even if we have committees for all the 32 slots the adversary cannot gain any value because if you assume after three rounds all the votes will be anyway expired and this cannot happen in our case because we have a longer experience period meaning that if you have committees within this expiration period the adversary can still use votes that are unexpired but not up to date to place this kind of attack yes so is this sort of a trade-off between how many periods of

how long the period of a you can tolerate versus pris how long you can do this uh attack precisely yes exactly and in fact we have some limitations of this protocol and as you as you mentioned like the protocol is not dynamically available for any ETA that is bigger than to in the sense that if we have an expiration period of five Epoch for example but the to sleepiness is only for the first two epochs all the messages from Epoch 2 to Epoch 5 can still be used by the adversary in some sense and it's also not a synchrony resilience for any asynchronous period that is longer than the expiration

period And this is clear in the the sense that if we have messages that expires after that expire after two SL two slots for example but you have an expiration period of two apox during a synchrony these votes will just expire and even if we have a condition that I mentioned before still votes expire so we don't we cannot do much so in some sense exactly we have to find a sort of tradeoff between how much a synchrony we could consider feasible in the context of ethereum for example how much synchronous period can we expect in this kind of environment and how much Dynam how much adversary adversary resilience are we willing to give up because of

course the big the longer is the as synchronous asynchronous per that we can tolerate the longer will be the expiration period that we consider and the stricter is the the to sleepiness condition because we have to consider all the validators that cast a vote that are not anymore awake so the longer the stricter Bec becomes this notion of dynamic availability in the sense that if we consider an expiration period of infinity meaning from Genesis block until now what we are requiring is that if we have n validators at every slot we need n / two meaning that in that sense we are considering damic availability only in a very very very very narrow sense so we need to find the right tradeoff so uh what could be the right

measure of a synchron that we can tolerate how much expiration do we want to give so this these are still the challenges that we are facing and what we are working on actually we are already worked on is to combine this rmd ghost with a partially synchronous component achieving an e flow protocol or a to e andf flow protocol in the sense that an e and flow protocol in the tow sleepy model the goal could is optimistically to reach single slot finality basically and what we showed is that by combining lmd ghost with a specific kind of confirmation rule called Fast confirmation together with a partially synchronous

component we can optimistically achieve single slot finality in the sense that the block proposed as slot T is conf is finalized by the end of slot T of course again in order to implement the single slot finality we need to try to understand how to cope with the fact that this whole set of validator is voting at every round so this is some sense a block in every kind of protocols where we plug in rmd coost in some sense another thing that we are working on right now is how to apply these techniques so aspiration to sleeping mode to sleepiness and everything to deterministically Safe dynamically available protocols like for example I

don't know if you already heard about this protocol like the protocol by MOS and ren or Maly MOS and ren or Loa and Gaff they have this uh dynamically available protocols that work using quorums and they achieve deterministic safety but probabilistic liveness but and what we are trying to achieve is to to do is let's take one of these protocol let's apply the techniques of expiration and to leppy model so that we can then compare the two families of protocol so longest chain or heaviest chain and uh Quorum based family in order to see which one could be better fit for the dynamical

available component in this e and flow protocol and and as I mentioned before another thing that we are trying to investigate is as I was mentioned before finding a sort of is it possible to find a trade-off between dynamical availability and a synchron resilience in a protocol that enables sub sampling this of course in the context of single slot finality is not yet clear the utility for that see that any way for to achieve finality we need a whole set of validators to vote but it's still uh we believe to be um interesting interesting potential thing

to to to understand and thank you very much back to the fork Choice Ru so like what's what's the intuition of what makes a fork Choice rule like good or bad you know when they what sorry a fork Choice rule so like what what makes a fork Choice rule good or bad intuitively uh I would say it's good or bad depending on the properties that you can derive from that in the sense that um maybe another way so what properties of a for Choice rule tend to lead to a protocol with good guarantees versus not uh actually like the Fortress function is just used to compute a canonical chain right so the fact that

we can have a good or bad result it also depends on how the protocol is how the protocol works for example in the case of lmd ghost we have this Fortress function that as we saw given the right context it enables it it leads to dynamical availability but if even if we have this amazing Fortress function but for example to sleepiness doesn't hold we cannot much anyway so in some sense I would say that it's not the fork Choice function in this context that is good or bad it's better or worse depending on the condition around so for example in the case of goldfish the fortras function if we consider a syn a synchronous model is is amazing because

it allows to have the minority corruption at every slot and it achieves dynamical availability or resilience but if we take into consideration a synchrony then it doesn't perform very well so for that you need it depends on on on the problem that you're trying to solve if you are just forget if you want to forget about a synchrony then goldfish is the the way to go I would say otherwise if you want to contemplate possibility of network partitions then we need to maybe move to more generalized protocols like her de ghost or yeah I don't know if this answers to to your question yeah I mean it sounds like at the moment I understand standing is very like non- modular right so like

what what to me would be very satisfying would be like you know combine this gadget with these properties with this gadget with these properties and you get this consensus protocol with kind of these other properties and like the EV and flow Protocols are kind of pretty nicely modular in that way for example right yes and so somehow like the whole once you've got the ghost and Fork twist roll stuff going on it seems like a little more uh muddled together you know what I mean yeah I I think it's the way because ym flow protocol is a very general protocol but in their instantiation for example by using goldfish they also makes use of a fortress function so I believe that the ab and flow family of protocol is very interesting formalization of also practical protocols like for example ethereum but

then when you consider a specific family of protocol then you need to take into consideration the challenge for example what we also are trying to do is to take this Quorum based dynamically available protocol apply this techniques for a synchron resilience and in that case we do not have a fork Choice function so but we still can achieve a benlow protocol because we have the base layer that is a dynamically available protocol on top of that we put a partially synchronous Gadget and we can achieve e and flow protocol without considering the Fortress function so but but yes I I see what what you mean and in this case like the choice of the Fortress function should be based on the kind of

properties that you would like to achieve and the kind of scenarios that you want to prevent in some sense yeah I guess my comments they're probably motivated just by you know I'm sure you remember there was that um you know sequence of sort of attacks on ethereum livess attacks and then like tweets to the protocol right and just like during that whole discussion I I I totally believe the people on the EF side had intuition about why they were proposing the tweaks that they did but I didn't share that intuition and I still don't have that intuition so so I'm just I'm just like I just love a little more get a better feeling for kind of what's going to give you good properties but it sounds like we're not we're maybe not totally there yet so yes all right thanks again thank you very

[Applause] much