Interchain Timestamping for Interchain Security with David Tse | a16z crypto research talks

Transcript

okay so um welcome everyone to today's a16z crypto research seminar very happy um to introduce David say from um Stanford and also now Babylon chain um David's group over at Stanford I think has been doing some of the absolute best work in blockchain consensus for many years now so very happy to have him have him here David floor is yours all right thanks a lot Tim for inviting me here um yeah so um I'm at Stanford um and today I want to talk about some research we've been working on under the general umbrella we call interchange time stamping and we are also doing a startup Babylon chain but I'm going to leave right now from

Stanford working on that so I'll uh give some discussion on the theory as well as give a demo of something that we've been building Okay so the merge has just happened a month ago by the way that's a month ago but it's a long time since I made other things have happened so the merch I guess is no longer sort of current it was like five years ago five years ago but actually it took seven years to do this merge and it just happened a month ago so it's still pretty recent so proven Works super mistake there are certain advantages well no less energy

that's the confirmation and business mechanism which is absent improve of work called slashing which gives stronger so-called stronger Economic Security however there are actually several even with the slashing there's several limitations of proof of Stack protocols that we sort of learned over the years as we work on proven State protocols and contrasting group of stake improval white protocol as Tim said we spent quite a few years working on this kind of consensus protocol permissionless consensus protocol so one thing we realize is that although a proven stake protocols or

so-called permission list is not really completely permissionless because stick unbonding in other words to leave the system there is a unborn period and typically in consensus approves the concept program because this is very long multiple weeks the second is that slashing succeeds for um safe Jack tags double signing however sensation is not accountable I think Tim actually mentioned that in one of your open problems and uh so how to deal with censorship is a limitation Improvement and three

Economic Security is sort of measured by the value of the chain the token valuation and so if you start with a small chain with more violation bootstrapping could be quite difficult so those are the three limitations we identified and um so we've been doing some research on how to overcome these limitations and we're also building a project called Babylon to solve these problems but more specifically in context so I think it's always good like you know Nakamoto has eight page paper inventing Bitcoin as I mentioned is a bit of a like a system paper rather than a

Theory paper so I I always think it's good to have a system to focus on so you can focus on our talk so the system we have in mind is like Cosmos okay so what is cosmos Cosmos is this system where you can summarize in one equation okay so the equation is that you have many sovereign chain AB chain specific to particular applications like a tax or gaming application uh these are relatively typically very comparatively small proof of stake chain but they communicate with each other through a bridging technology called IBC inter blockchain communication and

together they form this Network called one name for this The Interchange I think it's a pretty good name The Interchange because it's carries idea of multiple chains but at the same time there are inter communicated so like the internet and this IBC is actually very interesting technology uh we were talking about the live client so the lifeline was invented by Nakamoto SPV uh uh I think one of the significant realization of the lifeline is actually in this IBC because this bridge is a light climb Bridge so to maintain this bridge there are likewise on each end viewing the other

so the light climb was the IBC was invented as a transport layer if you think about the energy with internet as a transport layer but of course the main thing people transport is basically token transfer what we realize is that this IBC is actually much more versatile and it can be used to transfer security and I'll talk about that uh later on in the talk okay so this is a free limitations um I would talk about one or three of them one after another so for brief of time I will have to focus on Q of these three the first and the third and I've briefly mentioned the middle one okay so here's a deal about proof of

work to proof of Stack so Bitcoin is uh a example proof of work chain the first group work chain people say slow Bitcoin confirmation take hours okay slow the proof of say comes along and the finale is fast seconds so going from hours to seconds amazing however there seems to be some kind of conservation of latency because there is another event which is unbonding which is very slow so it seems like you speed up something but then sort of something got lost so improve of work you know if a minor

wants to leave they can leave anytime they want they can stop mining but for proven State chain if you want to Unborn often take weeks so going back to our system Cosmos a typical Cosmos chain takes three weeks to unborn three weeks some are longer four weeks some are a little bit shorter two weeks but three weeks is the typical number and uh so let's understand why okay so our first question is why is it so loud before we can try to fix it everything I mean one possible complaint about this line is it's sort of apples versus oranges right I mean it's users end users they care about latency right and then a bonding is relevant only for the validators right so yeah it's it's conceivable that one time

scale would be more appropriate or more reasonable for one of those two sets of entities than versus the other uh so the clients are worried about clear information right and uh stakers not necessarily the values right I mean you delegate Stacks so whoever has steak would be worry about that right and uh so you're saying this different audience is involved yeah because I'm saying like the value of being in seconds might be much higher for one of these groups like perhaps there might be much more important for the clients good than for the sake yes okay that is the is there any slashing concerns that

would delay finality from the perspective of the clients as well like uh what does that mean sorry I guess maybe uh responding to what Tim was saying saying that if there is a world in which someone doesn't invalid thing and that they could be slashed yes um that might take a while yeah this will travel later yeah so the question is why is it so long right and it's religious is that the question okay good yeah it's completely related to slashing okay all right so Juno is a as a cosmo strain so let's see what happens to Juno under

the attack so we're growing so Juno is growing a canonical change so these are the blocks produced on this chain it's growing like a chain so it's nice what is an attack attack is a fork it's a fork on this chain and The Economic Security is realized here through catching the attacker because now the attacker has the double sign on these two folks and so this is so-called slashable Funk okay and so attacker is now punished and that provides a deterrent to forking okay so this is

and you can think of the economic security say called as you know is the slashing penalty so typically one-third of the people can slash slashing counties what's called s Juno now unfortunately not all attacks are slashable and here's an example of an attack that's not slashable so to slash someone not only you have to catch them you're not going to prove that they have double side but you have to be able to slash the steak before they unbond so if they have already unbonded and then they grow the fork

which they can do because they have the signatures they can certainly they have the keys so they can still grow this unslashable Fork so although we have double sign then now cannot be slashed so this is an example of an unslashable cloth Okay so the problem is kind of pretty well known improve steak metallic talked about it in back in Back in the Day 2014 when you start thinking about the proof of stake ethereum and uh so the typical solution that is adopted by most people change is this idea of a long and bonding okay so let's see what that means so there's

a we have to do this a little bit carefully because the key um slide here okay so you have a validator a sticker they issue an unbonding request in a block then one request goes into The Ledger and then I'm going to request it granted only after a certain long period of time okay so 21 days in the case of our Cosmos example so 21 days okay so let's say what is the use of this law and bonding and how does that prevent this attack okay all right so let's consider two cases

one is that suppose oh so one thing I forgot to mention okay when I forgot to mention is really what is this attack worry about okay so if you go back to the previous slide is really for a client for a client that is not always online because you're always online then you will see that the canonical chain in the middle here growing and you will not be fooled by this Fork that is created later so the concern is that users or clients are not always online

they come online and then they leave the system and they come online again and when they view the system then they see these two false then they don't know which to follow or even worse they may only see one of the two folks and they may follow the wrong Fork so the 21 days should be understood in this context okay so 21 days basically means what it means that if you come online within 21 days of the last time you left the system then your chain will have a block in the canonical chain okay so then you will continue following this

chain so when the attacker tries to create a fork the fog will be has to be before The Unborn request because after The Unborn request the um steak is already Frozen it cannot vote anymore so it has to be great before so therefore when you join within 21 days and you see a fork the network will be slashable but we don't see the fault in yourself okay so that means that the system is now safe if you join the system within 21 days okay so for example in college

most this 21 days is used in the case of the design of the IBC like client so the the most important client for Cosmos is actually the IBC like client so you know on the other chain and you're viewing this chain and you don't want you want to verify that the transactions that is communicating to you is valid so you want to know we will be able to follow the correct Fork on the sandwich and this allows you to say that as long as you send a message an IBC message every 21 days then you're safe okay you're protected by slashing okay so that's where the 21 days come in in Cosmos they want to make sure that

even though IBC like client may not be always on as long as they're always on every 21 days then you're fine now what happens if you go beyond 41 days okay that's when Things become really quite fuzzy because we have been on 21 days then you're no longer protected and this is one so-called social consensus which means that you're beyond 21 days you really have to trust your friends to be able to find the right chain of Junction so this is a very kind of a protocol which is not really fully specified what that really means okay all right and in the case of IBC if your IPC connection is not updated for 21 days then you have to shut down the

entire busy connection you need to restart which is effectively another social consensus process okay sorry so this is uh the reason why there's 21 days okay now so uh the question is really how do you have a more secure way of onboarding late joining claims without having needed to wait 21 days or be able to join even safely beyond the 21 beyond that burning period however long it is so what is going on here what is the confusion here is that there are two chains you created

and the user who is always online the client always online knows that the upper chain is the correction because it's growing this one is later arriving and so the online client will reject it the problem is the late joining client so therefore what we need is really someone to be always online watching you watching this train and someone that can be trusted by the clients the system so basically what we need is a timestamp server so in nakamoto's paper when he introduced Bitcoin he said

hey what I want to build here is a peer-to-peer distributed timestamp server to timestamp bitcoin transactions as to when they occur okay so what we're going to do is we can use Bitcoin to not only time stamp Bitcoin transactions but to timestamp events that are happening outside the big country and the events that are happening is the creation of blocks in The Proven State chain that's really thinking about this wait so when you're talking about the so like if you go back to the reporting question so if it were true that every

block had embedded in it an accurate timestamp of its creation yes then you're saying just program the client so whenever this conflicting a block I'll follow the earlier yes and so that's just kind of the client-side way of doing for resolution for everybody yeah it stays in sync and so being always online just means that like well the blocks don't have timestamps but you know the timestamp because because I keep track of my time okay as I'm just saying like let's replace that with like Bitcoin basically being a public service yeah correct so we're using Bitcoin as like a public time stamping service to his timestamp events that are happening on the promo State chain yeah

so that's the high level idea so maybe I'm jumping ahead but I think technically you need more than just time stamping you need time stamping Plus data availability yeah it's coming okay if you are jumping ahead that's good yes yeah so let's let's understand that a little bit more carefully okay all right so we have the slashing of Juno which cannot be resolved uh and now we use Bitcoin and we basically send a timestamp say of

every block of the Juno chain so to say so what we do is we send a so-called checkpoint transaction onto the Bitcoin Network which goes into the Bitcoin Network and the transaction is recorded and that provides a timestamp to a fork let's say to a fork okay so now the canonical Fork has a timestamp which is earlier than the later created unslashable funk which has a later time step and so now a late joining client weather is

coming short or long time later will always be able to see the timestamp because it can observe Bitcoin and therefore can determine the earlier Fork as the canonical fork and no one will get confused okay no one get confused so that's a general idea that's the idea and the good thing about Bitcoin is indeed you can send transactions into Bitcoin that are not Bitcoin transaction they call op return transaction it's a particular transaction type Bitcoin that allows you to send arbitrary data by very small only 48 bytes only 48 bytes okay

all right so now the question is okay so if you have future system then can I change the I'm bonding time so I'm one time used to be 21 days but now so what is the effect of unborn in time for this system using Bitcoin as the time stamping server well as long as the timestamp is confirmed on the Bitcoin chain where confirmed means a certain depth interpretch on chain as as reliability that you like then the reversion probability is very small

and then you can now trust that time step so really the unbonding time is now equal to the BTC timestamp confirmation time and this confirmation time can be chosen to your level of security so for example if you think 20 plug deep is what you like then your and one time will be the time in which the confirmation the checkpoint or timestamp becomes 20 blocks deep into the Bitcoin chain and this you can observe roughly 20 block deep would be roughly 200 minutes but this could be a random variable okay

so therefore now we reduce the important time from 21 days to the Bitcoin confirmation plan okay all right uh so to prove a security theorem is not enough to just give you one example of an attack and make sure that the attack and restart it right because you know well that's what Nakamoto did in his paper but that was Nakamoto I'm not Nakamoto so I think I have to be more careful so in fact this is one particular attack let's call it the post unborn hair type that means you grow the fork after you embark

post and bondage but actually there's another attack possible okay and this is a data availability attack somehow this concept of data availability always Crips in no matter how hard you try to avoid it it just always shows up don't know why okay all right so here's that attack so instead of doing post Hawk Attack post-borne Attack you first the attacker first create a private book where the data is hidden

and then the canonical chain get grown okay and you only review the private form after the economic coaching so this is like a pre-hog attack and this could still cause confusion okay so let's understand how Bitcoin timestamping could help or can it help okay now for this pre-hawk I try to work with a Bitcoin time stamping service then the attacker cannot just grow a private fault within data and keep it invisible to everybody

because otherwise it doesn't have a earlier timestamp than the canonical chain so it has to put a timestamp onto Bitcoin it has to put a constant breakup otherwise it cannot confuse the late joining client now at this moment there's a timestamp with Bitcoin but imagine now the all the other validators they say hey there's a timestamp on bitcoin all right but there's no I don't see the blocks I don't see the actual block so what happened here okay so

now the question is what is actually what is actually this checkpoint or this time stamp put into the block okay even with just a hash a block hash of the data is not sufficient because now everybody can put a hash on timestamp and that is not enough of a signal to tell you something goes wrong so what we require is that it should has the Quorum certificate in other words the same people who signed the blogs also assign this checkpoint or this timestamp okay what does that do for me all right first it means that to create such a Blog the attacker has to have a lot of voting power to create this block

right because it has to have the core because if it doesn't then I just reject the timestamp it's not valid second I observed it I don't have the data so then what what can well the protocol will do our particle would do is at this moment you say hey there's something wrong here nobody should go forward with growing the chain nobody should follow the chain anymore okay so therefore this becomes a holding condition that means basically you say that hey Danger someone has taken over this chain we should now go to social consensus and try to restart the whole thing so therefore what happens here is that because we have a data availability

problem we have to deal with it and we're using this BT signal to co uh to host the system to store the system and avoid a safety problem now you could completely solve the problem if I could put the entire data onto Bitcoin then there's no data available problem but Bitcoin you cannot put so much data on it this problem comes from the fact that the Bitcoin has a unlimited is a limited time Centric service data limited timestamping service and therefore what this protocol does is it translates

to a limitation on the liveness of the protocol however by doing this I can protect the slashable state okay so in this paper that we are going through the review process of SNP we prove the following theorem so this protocol we build it on say nament then what we can show is that this protocol has one third slash will save okay so what one third slash website means it means that no matter what attacks you go on this protocol

I can guarantee you that whenever there's a safety violation I can slash at least one third of the letters so therefore I was this protocol can protect against all unslashables okay so that's the first statement of it too now what about live list right so security theorems usually have safety and that's likeness so what we show here is we have Slash Road Safety one of our liveness now liveness of attendance protocol typically is one foot okay that means that if the values take

over one third of the voting power then they can sense the transactions or they can store the protocol what we showed in this paper but no time to show in this talk is that by using Bitcoin as cable a censorship complaint platform you can actually improve the resilience what from one third standard tournament to one half so you can strengthen the censorship require essential protection of the base proof of security so that's what we saw however we also showed that as long as the timestamping

service is data Limited and you want to provide slash for safety then the liveness resilience threshold cannot exceed one half and thus due to the data availability constraint because your data Limited you cannot put on data on the Bitcoin you also cannot exceed a lot less results of more than one half okay so that's what we're showing this paper the question so on the first poem you said slash I will save should I think of that how does that connect to definitions out there with accountability right so accountable safety means that

whenever there's a safety violation you can provably identify valid violators of the protocol and you'll never identify the honest product you'll never misidentifying the honest protocols honest values so that's what accountability is slashable means that you can also catch them with this crime and Slash the state before they unbonded so it's a stronger requirement so I'll give you an infinite unbounding unbounding period yes exactly accountable and apply slashable yeah so in a promotion particularly in a permission protocol which is a which is the definition of unborn infinite when

the period Then a conversion slash which is the same thing in a permissionless proof of stake protocol they're not the same thing okay it's stronger and the meanwhile and liveness like this is gonna this is actually not gonna be a slashable attack is that right so you're saying like despite the facts that's right exactly so liveness we're showing this paper not only cannot be slashed but we cannot do better than one half so slashing basically means that it doesn't matter how many people are bad okay as long as they commit a crime a safety violation then I can I can slash that okay so that's stronger than your

classic sort of assuming a certain fraction of people are on this type of assumption so that we can do for safety for liveness what we showed is that it's not slashable if you give your time stamping service is data Limited well and we need an assumption of majority owners okay so in this range between a third and a half you think it is it is it is flashable or no no between winter and one half we retain liveness okay you become a theorem which says that

give us above one half we can slash them for committing alive we don't have that and in fact what we showed in the negative result is that you can't have that as long as the time sentence will stay Limited okay yeah can you go to your previous slide for a second so like the example for why um so why can't you slash the person who uh published a false type stamp on bitcoin can you do so this seems like an attack on Legends where to me it seems like slashing would help um

um why can't you slash someone who published because you may end up slashing let me think about this I think you may end up slashing honest people if you do that so okay so the problem is okay so here's the problem is that you the the the the evidence you see okay the difference you see is that I don't receive the block right but I see a signature but you see not receiving a block is not a probable evidence as it's not a verifiable evidence right because you may be pretending that you don't receive the plug

so therefore you cannot really it's not like double signing whereas in irrefutable evidence pretty honest right yeah okay so it's not ability do not assume I do not assume majority are honest it's like the Britain says no matter what happens you can still provably verify uh evidence okay but for the impossibility is that synchronous model or yeah the impossibility is uh any model yeah even even partial synchronous it applies so let's say if I assume I suppose it's

like supposed synchronous or making it harder for you to prevent possibility result yes so the The Impossible is proof under the synchronous model but the Polish thing was even worse so it's easier it will be implied from this result got it okay all right so we decided to uh build this thing for Cosmos okay and uh so we have Bitcoin in one side and Cosmos all these many many proof of stake chains on the right hand side so when we're building this is to have each one of these chains time stamping on bitcoin obviously it's not a very scalable

solution because of two reasons one is that all of these chains uh if they all have the constant Bitcoin then you're getting many many checkpointing transactions into Bitcoin two is that it is very hard to optimize the checkpointing mechanism onto Bitcoin without a significant change to each of them protocol so what we came up with is sort of a intermediate architecture so we build a chain which is a cosmos chain so Cosmos have this thing called Cosmos SDK it allows you to build a chain uh and we built this Cosmos chain and we use this chain to timestample

into Bitcoin to get the Bitcoin security that we discussed earlier okay and then we Bridge Babylon to all of these other chains in order to spread the security from Bitcoin to all the unchains so let me go into a little bit more detail how this works because that's where the connection with IBC comes in okay so first is high so this part is uh quite a lot of engineering effort required and the reason is because Bitcoin has only very limited capacity to pick in arbitrary data because it is this 48

byte so basically we have to fill in the checkpoints the timestamp the signal Church all into 48 bytes if possible okay so we couldn't do it we couldn't do for it but we could do 96 by no for two transaction I was going to say 48's not really a it's not really a hard limit you can have as much as you want it's just yeah but yeah but then you can put in many transactions hundreds of transactions that makes it engineering wise very difficult and two the miners really don't like this you want yourself stay sort of a little bit low profile because once you start sending in hundreds of dollars of these transactions

then God knows what will happen so right now we send two transactions okay do you send two transactions or a transaction with two outputs uh two or two op return transactions a pair of transactions separate transactions okay so there's quite a bit of engineering here probably won't go into details but the whole point is that first we uh remember that we are basically signed we're basically sending in signed header as our timestamp okay so every time Nevada data set changes you have to send a checkpoint in so yeah the values that changes

arbitrarily then you have to send checkpoint basically for every block times that very block by making sure that the values that don't change very often on Babylon then we can assure that we don't have the checkpoint very often so in Babylon we checkpoint about once every half an hour once everything happened now second we don't want in Cosmos they don't use Aggregates nature so they keep the list of all the individual signatures of say Hydro validators that's way too much for time stamping onto Bitcoin so we wrap around that and use a aggregate PLS initial to do that so all these optimization

uh basically if you think about it what we're doing here is roughly speaking we're building a bridge from Babylon to bitcoin to get the time stamping in okay all right so there's a quite a bit of work now once however we get Babylon the Bitcoin security then this point is actually much easier and based at this point is through IBC okay so it turns out that we can connect Babylon to audio zones through IBC and through this IBC they can get the Bitcoin timestamp security so let's see how it works

all right so the first observation is the following okay IBC actually provides a Time stamping service already okay so let's see how it works so in IBC you have ascended chain and you'll receive a chain and what the standard chain does is it sends the signed headers of the sender chain from the sanction to the receiver chain through the IBC connection it's actually through some relay notes what this does is to allow the receiver chain

to maintain a Lifeline of the sentencing so what is a lifeline like clients basically you OBS you have the chain of headers of the blocks but not the blocks themselves that's why it's called light the headers allows you to know keep track of the raw data set to know that the the stuff that has been sent over is valid by doing a miracle inclusion proof so the receiver chain Basin maintains a Lifeline Center Zone but what is it like my like plan is nothing but a sequence of headers and this like client is a so-called on chain like clock that means it's like playing is stored in The Ledger of the

receiver chain why why why do you want to be in The Ledger because you want to make sure that all the validate is on the receiver Zone agrees on just like that so that everyone is in consensus but thus effectively the same as putting the timestamps on the headers of the center chain at the receiver chain reserves up so therefore having an IBC with a Lifeline is already automatically providing a Time stamping for you on the receiver chain okay so what does that mean for us so you're sort of saying the receiver chain is always online and so that's that's sort of no the receiver chain is

not always okay the receiver chain in this case is always online because it's Babylon right okay okay so therefore what's going on here is that using IBC we can have individual Cosmos chains to first time send one Babylon and then through the timestamp from Babylon optimized to bitcoin in as an aggregate they will also get on a Bitcoin timestamps and so therefore we don't need 100 chains of 1000 chains or time stepping under Bitcoin one times them can aggregate all time stamps because that's that's our design to make this time stamping ideas scalable okay

all right so right now we are integrating in congress with a bunch of Cosmos chains and this is work in progress so to integrate with them we have to do governance proposal so we were talking about earlier uh on chain governance versus off-chain governance and Cosmos uses oil change companies so we have to write a governance proposal to propose them to integrate with us and then they will have their community members the validators to vote on whether or not the acceptance so this is in progress but so right now what we're doing is we're opening IPC

connection with them and we're giving them Bitcoin time stamping information so this is the Bitcoin so right now Babylon is in the devnet mode it is time stamping to the mainnet of Bitcoin the minute of Bitcoin and um all right so here we have a box of 400 blocks on Babylon and each at the end of apoc we sent one timestamp onto Bitcoin so these are the recent most recent time stamps under Bitcoin whenever you issue an unbonding request

we wait until the timestamp of that and responding request becomes 20 block deep and this devnet and the unbonding time which is the delay to get into the Bitcoin chain and we're into its 20 block deep is on average four and a half hours no experiments so far so you can see that the checkpointing is actually rather irregular ly irregular it does because of the statistical nature of Bitcoin it takes time to get a transaction into Bitcoin sometimes slower sometimes fast depends on the congestion

then blog creation process is also random so you can see the randomness here but you can see that with 20 block table which is pretty good you can get a bonding time of four and a half hours if you prefer 100 block big then it will be five times that so it's going to be about 20 hours in less than a day I don't think any pure exchange would like it in one period of four hours it's probably too fast but it may be a little bit longer like a day or so so the people that we're talking to they think about in one period of a day okay all right so that's the Babylon chain running with time stamping onto Bitcoin

and the unbonding right now is applied to the Babylon chain itself so this is our eat our own dog food chain now in terms of providing service to others so right now we have uh four four Cosmos chains injective osmosis icons in Juno some of them are pretty big like osmosis and Juno pretty big chains so they are opening an IBC connection RBC connection to Babylon and that one in return is giving them the time stamping information on which block has the BTC timestamps and what BDS that

timestamps or their age blocks so here are the height of these blocks who has 50 times them and these are the finalized BTC block that time stamped them so that means that whatever your client you look at this article you know sort of the timestamp on your blocks and that can help you to safely join the system okay so the next step is to automate this and to use this timestamp information in an automated way to help them safely Unborn so that's work in progress but this is a it's a live running chain right now all right so the second part is about bootstrapping small chain

so Bitcoin allows us to make all that tax collectible okay but if the token violation of a small chain is low then you're still limited by The Economic Security okay here's an example the boys have a new Cosmos on called right pool so it is communicating with osmosis which is a Dax which is a deck so I need to communicate with it for IBC so the founder blocks one million drug tokens for 100 Osmos perken on the rightful chain in a sense an IBC message to osmosis and at the other end the osmosis founder

receives 100 osmo token to add the osmosis so very good however and then there's a double spend a fork on the send and chain and so this transaction is now negated so that means it got now 100 more token without paying anything for it okay you say hey how can that happen of course it can happen it can happen because it can Fork to find this depend on more than one thought they can Fork the chain after you get an Osmos token of course it's forking is

not punishable by slacking hey but if the small if there's a small chain the slashing country could be less than the amount stolen okay so in this case the economic security itself although I could slash is not sufficient to protect in some sense against this IBC communication is that money is now stolen okay and so osmosis is now saying hey you know it's not so good to communicate with this guy okay all right so actually think about what we did for Bitcoin time stamping what are we actually doing here is you can think of the time stamping

it's like providing Bitcoin level security to a particular transaction type earlier which is the unbonding request right so all the transactions or the POS change is going through the fast analogy process except for this unborn request which is going through the slow Bitcoin confirmation and based on that we act on that based on bonding so a natural question is why don't we just apply Bitcoin confirmation to all transactions every transaction you have to wait until this Bitcoin confirmed so it's a double confirmation process

first you finalize on the right food chain and then you wait until the timestamp is confirmed Bitcoin only then you finally considered transaction really final final now in that case then for the attacker to steal the money it has to Fork Bitcoin which is very hard and so in some sense your Economic Security is now the sum of the Bitcoin Economic Security and the right poor Economic Security you have to Fork both trades Bitcoin and right tool the best thing about this is Bitcoin is slow so you do this for every transaction

everything slows down into Bitcoin confirmation we don't want that we don't want that okay and the reason is because here we are relying on double confirmation not only on a special transaction like and bonding but for every transaction okay so however there is actually a chain that can actually provide this time stamping naturally because remember that we are talking to osmosis through an IBC

right but the IBC as I mentioned provides a natural time stamping onto osmosis so actually osmosis but this factor is running a Litecoin to observe right pull is a really time stamping right for his blocks and so that becomes the natural chain that can provide additional Economic Security to raiku so I find that quite fascinating is that you're running a Lifeline to observe the other guy to make sure that the translator valid but at the same time you also put running economic security protection production so let's see how that works

all right so now instead of thinking about time stamping to bitcoin which is very slow I now timestamp to osmosis which is a proven State chain which is much faster so it's a way for double confirmation or I need to wait for is to confirm let's see what we have to wait for now is a confirmation on us on broadpool and a confirmation on osmosis which is much faster

now the economic security is not as good as Bitcoin No Doubt but it's much faster so the trail between speed and security but the good thing about this is because the IBC already provides a natural time stamping yeah I don't need to do this explicitly additionally anymore so therefore to extract this whole system the attacker not only has to Fork off Blackpool which is easier because there's lower Economic Security you also have Funk of Osmosis which is a bigger check so osmosis by virtue of economic sort of communication economic transaction with the smaller chain can also provide

security to it and digital security and that makes the confidence of the economic exchange stronger so I think it's quite nice Okay so so osmosis is transferring security from itself to the right protein you can apply this concept to even two big chains osmosis can provide security Journal because they do communication through IBC and in fact you can make this both ways because the IPC is time stamping in both Direction so they can exchange security and you can get the sum of security so you can prove some security clearance behind this as well

okay all right so I find that quite interesting because the whole point of The Interchange is you have this Sovereign chain although the countries having economic alliances through IBC what we're observing here is that security alliances can follow naturally from economic alliances which I think is quite interesting and can be developed further I believe thank you David said a question more about the first

part of the talk that's true and I guess what happens if Bitcoin collapses right and you're short year on bonding period because you're sort of trusting Bitcoin for a Time stamping yeah so that's right there's no free lunch yeah if you trust something then if that thing collapses then you have a bit of problem however if Bitcoin collapses there may be many other public stuff then your yeah so I don't know so we we thought about about how one could design a system in which one can have some fallback your Bitcoin gets

formed we have not succeeded and I think that's probably impossible to reserve which says that you know yes so and the second part of the slide you were kind of registering at an additive Economic Security situation for additive confirmation time adding like is there a theorem of that form is it literally exists yeah the theorem we'll work on right now and it's the idea that like you take the minimum of all of those timestamps but if for every blog yeah so you so what's the confirmation route right let's see let's look at this so normally I confirm when I see enough signatures on this block okay

so now this timestamp goes into this chain and this chain will now have a clear chance to vote on it so it's like having two committee committee rug tool first vote okay and then committee from osmosis then vote okay so to destroy this finality you have to Fork both Raku and osmosis and that's why the economic security acts because now you're paying slashing penalty on both the purple train and the yellow chain so what if we also have Bitcoin as a third chain then you're trying to derive

Economic Security from both yeah so I guess it's unclear to me how that Microsoft would work yes that's right yeah that's research yes yes so your question is if I check points simultaneously to more than one thing then how do I combine yeah and get more security that's open research problem still working on that right now it's just one uh is now the yellow chain checkpointing tour is IBC partner which is the purple team but I think one can probably prove a theorem which is more straightforward which is suppose the yellow chain is checkpointing to the purple chain for fast Economic Security and

simultaneously checkpoint of Bitcoin to get long range protection you can prove a theorem which you can get more that's that's pretty straightforward I think thank you