 Hi everyone, and welcome to the presentation about the paper Dynamic at Hock Clock Synchronization. This paper is part of EuroCrypt 2021. My name is Christian Baderger, and this is a joint work with Peter Gashi, Agilos Kjajas, Alexander Russell and Vasily Stikas. So let me kick this off by explaining what the problem of clock synchronization actually is. As the basic setup, we assume we have a set of parties that are equipped with so-called local clocks or duration timers. That is, every party has access to a device by which it can measure the passage of time or time intervals, and we assume that those duration timers, they run approximately at the same speed. We further assume that we have a public infrastructure as a setup or alternatively a common reference string. In this case, we can associate each party to a public key and, for example, verify signed messages. We assume that a protocol will be executed over a bounded delay network, and we assume that the majority of parties follow over the protocol and hence are honest. What's the goal of clock synchronization? Well, these parties, they want to jointly, together, emulate a global notion of time. That is, they want to compute over the course of the execution time values, and if you ask two parties what they believe is the current time value, then what they report should be very close together. This is what we call approximate synchrony. The time values they compute should satisfy liveness, which means the time values are increasing, just like real time is. Maybe we want to have monotonicity, basically we demand that we have an arrow of time implemented, and maybe due to imperfection of the protocol realizing this, we might suffer from some jumps in this sequence of time values, but those jumps are required to be limited and small. On a more abstract level, we could say, well, what these parties try to achieve is they want to jointly, together, realize a global clock functionality. In this abstraction, you could imagine we have a functionality available that internally keeps track of real time, and whenever a party asks the functionality, it gets a value that is in the epsilon interval around that real time, where the epsilon could be influenced by, for example, the adversary. The goal of a clock synchronization protocol is to realize this functionality. Clock synchronization protocols have a rich history in the distributed systems literature. Let's look at some of the prior models that were used to prove synchronized secure. Initially, you just assumed a fixed party set, and you assumed that all parties are active, except for potentially the Byzantine nodes, which is the parties under adversarial control. Clock synchronization could be achieved there, or was achieved there, by a smart counting of messages and exchanging timestamps. A relaxation of this, which makes the problem a bit harder, is the so-called ad hoc model, where not all parties are active, but you just know that a priori unknown subset of parties will not start the protocol, so counting becomes a bit more challenging. Typically, the security threshold then requires, for example, known as majority among the active guys. What we are interested in this work is a newer model of party and protocol executions. In this work, we consider the dynamic ad hoc model, which is that the number of online and offline parties changes over time. We don't have a priori knowledge of the participation level that we can expect in the protocol, so no threshold, no counting of parties is reliable, because the participation can drop any time, so we have unannounced disappearance. New commerce must be bootstrapped into the protocol, so we have to accommodate joining. The security threshold is then formulated relative to the current participation level, so meaning that, for example, if always the majority of parties exceeds the number of dishonest parties, no matter what the participation level is, then we are secured. A prominent or prominent protocols in the dynamic ad hoc model are Nakamoto consensus protocols in the POS or POW space, and since clock synchronization could be seen as a form of agreement on time, we might think, okay, can we draw some inspiration to design a clock synchronization technique for the dynamic ad hoc model from those protocols? So let's try it with Bitcoin. So ideas for novel clock synchronization in the dynamic ad hoc model could be to just run Bitcoin, and we know from Bitcoin that a new block arrives roughly every 10 minutes. We have consistency and lifeness, that means we have, except for the possibly most recent blocks, we have a prefix where all parties agree on the stable prefix, and we have lifeness, which means the stable prefix grows over time. So now just say, well, block depth is a proxy of time, right? Every 10 minutes, a block count the number of blocks, you know, roughly the time. This is formally a clock synchronization technique. However, there is a drawback. It's that POW is not a standard assumption for clock synchronizers, right? Clock synchronizers would probably work with a CRS or a PKI, but not with this, with the resource of computing power. And another point to mention is that what I just described yields a rather loose clock. So let's get rid of this POW assumption and just use POS blockchains. So we also have consistency and lifeness. And we only have one source of trust. For example, in the case of Uraboros genesis, we only have one source of trust. It's the genesis block, so a CRS basically. So that would be a clock synchronizer. But wait a moment. So the non-POS protocols that accommodate what we want, right? They either require lower bound or an accurate estimate of participation between, okay, this we just said we would like to avoid. Or alternatively, they have to assume a reliable timing service like Uraboros genesis. So these protocols themselves need time information before they can really work. So that seems like a deadlock situation. The only protocol for agreement we know in a dynamic attack setting, they need time themselves as an external input. So maybe we can still use some ideas from those protocols because they guarantee something. And this is exactly what we investigate here. So the question becomes, is clock synchronization possible in the dynamic attack setting? And note that if the answer was no, that would be very disappointed. It would mean that any cryptographic technique that requires a time in the dynamic attack setting would rely on an external timing service that itself could not be realized in the same way. That would be a disappointment. But luckily, as we prove in this work, it is possible, even in the dynamic attack setting, to synchronize on time and even more is possible. And this brings us to the main result of this paper. So we actually designed the first QS blockchain protocol with the following features. So it's a secure QS protocol in the dynamic attack setting and does not need a global clock or reliable timing information. Instead, it synchronizes itself on time just based on the assumption we have seen on roughly same speed clocks or restoration timers. And second of all, the protocol is a clock synchronizer. You can use it, or any party and any external observer can use it to compute time values that are only a bounded distance apart. We call the protocol PRONOS, and it is a combination of a lecture plus a global clock. We can actually directly sketch the informal idea of our solution that we put forth in this work. So assume we have our set of parties connected over the network and each equipped with the duration timers. And also assume we have parties identified by certain credentials. They, in parallel, the same set of parties run an instance of Uroboros genesis and the protocol now roughly works as follows. So the parties exchange authenticated of synchronization messages. They contain local time stamps. We also restrict the exchange of these messages by the POS lottery to avoid adversarial dominance. The parties try to reach consensus over the set of synchronization messages using the blockchain. The parties then adjust time values, so their global notion of time, based on the agreed set, and some observed delays. This also informs, of course, the parties about which time stamps they should use when executing Uroboros genesis. And finally, we have newcomers that have to retrace the evidence they see in the blockchain and they have to retrace the recent adjustments of those parties. So a word of caution here. While it looked modular, the construction itself is not modular. There are a lot of things intertwined here and, for example, the messages are authenticated and filtered based on the POS lottery. Uroboros genesis has to be modified. We have to include a new procedure, how parties can bootstrap the lecture state and the lecture time. So it will not be as modular as suggested here, but the idea is roughly accurate. This brings us to a natural outline of this talk. So first we have to recap Uroboros genesis in order to see how it works and in order to understand what happens to genesis when we don't have access to a global clock initially, but when we only have these duration timers available. So what can go wrong and what has to be fixed? Then we come to the final part where we present Kronos, our clock synchronizer, which at the same time is then also a blockchain protocol. So let's now see how Uroboros genesis works. In genesis, time is divided into discrete units called slots and a certain amount of slots is called an epoch. In each slot, each party evaluates a private slot leadership lottery. So you're elected proportional to stake and it's a private election and it's seeded by randomness that comes from the chain itself. When you're elected the slot leader as a slot leader, then you can create the block for the slot and append it to your most preferred chain at this point. Let's be more concrete. Let's assume we have the most preferred chain here. Then in order to, so since we're transitioning now here into a new epoch, we have to refresh the lottery. You have to update the stake distribution and we also have to seed pressure randomness into the lottery. So the stake distribution is taken from a snapshot from the last block in the epoch preceding the previous one. This has, the reason for this is that we have, first of all, agreement on the stake distribution. Then the seed, the randomness is taken from the previous epoch from the stable part of the blockchain from the initial blocks from the previous epoch. The reason for this is that we have agreement on the randomness too and even more importantly, the randomness is affected by an honest block after the stake distribution has been fixed. This is needed to ensure or to avoid grinding attacks. So the seed comes from BRF, verifiable random function evaluations that slot leaders pack into their blocks as well. So the lottery itself is then formulated also with respect to a verifiable random function. You evaluate this function based on the fresh randomness slot number and if it's smaller than a certain threshold, depending on your stake, then you're an elected slot leader and you can prove this to everyone, thanks to the properties of the BRF. As we know from Nakamoto consensus in general, so we have slots that are empty, VA can have multiple leaders and so on. So how do parties select the most preferred chain? How does chain selection work in Genesis? The rule says, so if you possess a chain and you see new chains arriving, you decide to adopt a new chain if it's valid and so there are two conditions now, if it's longer than what you have and does not fork by more than K blocks from what you have, so this new chain is long and does not rewrite a whole bunch of what you believe currently is the sequence of blocks, then you adopt that. However, so there is a second condition, if in the other case it forks by more than K blocks, so it tries to override a lot of blocks that you already adopted, but then you adopt it only if it has higher density, block density on a certain interval called int, following the forking point of these two chains. Let's see in this example how Alice, that possesses the green chain on the top, decides whether she wants to adopt blue or keep green. She sees the blue chain rewrites or tries to override a lot of the blocks she already has and hence she goes back to the forking point and says, okay, which one is tensor and she figures out it's the blue one. So the intuition why this rule is secure is the following, under the honest majority assumption, chains held by honest parties, so created and held by honest parties, they must be denser on this interval than any maliciously crafted adversarial chain served to that party. The reason for this comes from the Forkable Strings analysis of previous papers. Intuitively, if someone manages to have two competing chains that are comparably dense and grow at the same rate in that interval, then this actually means we have a large divergence established, which is however ruled out by the analysis. So large divergence only happened with negligible probabilities, so hence this is a safe way to adopt new chains. A useful property for this work of this Genesis chain selection rule is the following, that if parties use this, especially a newly joining party, will adopt a chain with a large come prefix with respect to honest parties. So a party can come online, it just sees, it has access to the Genesis block and it just sees what chains float around and the chains it prefers will share a large come prefix with the honest parties. So the reason why this holds is the following, we have established that entity is a proxy for honesty from slide four. So all parties chains must contain this stable prefix at some point. So the new joiners, they might, so if for example they have no access to reliable time, they might not be able to point to the exact end of this stable prefix, but they are guaranteed that a large portion of the initial blocks are shared with honest guys. This will be very useful later, as we will see and it follows from what we just observed, that this prefix of the honest parties is being any density comparison. And the nice thing about this is that is an argument that is basically independent of reliable time information. So selecting chains according to density is an operation you can perform, even if you don't have access to accurate time information. And we will see later what impact this has and so what benefits it has, but also what disadvantages this has and how we can make use of that. So far in the description of Genesis, in the mode of operation we saw, we assumed the availability of a timing service. So we assumed the following, we had a clock functionality that tells parties times. What this means is that, so if we divide now the view into the time axis that we as analysts have and the slot axis that the protocol has, this means that at every instance of timing or point in the execution of the protocol, every party agreed on the slot number they're using. Because slot numbers is just the discretization of time. So everybody agreed on it. So that's what we assumed and the slot number is used to evaluate the slot leadership and so on and so forth. However, what we want is the same speed or the approximate same speed assumption, which then means that parties might believe in different slot numbers at the same instance of the computation. So while Bob believes it's not s plus two, Alice might believe it's s and some other party might believe it's s minus one. So at each point in the execution, parties might have slightly skewed or drifted a bit apart from what the actual time should be. So let's analyze Genesis, if we just place it in this environment. So what we prove also in this paper, if we manage to keep all on as parties somewhat close, we're kind of good. This requires an extension of the analysis, but doesn't mean that we have to invent an entirely new protocol, at least for this aspect here. So close together means that parties are maybe Delta apart from each other. That depends on the order of network delay and clock drift. And we have to do small adjustments to our Uroboros Genesis to deal with a future change. So if we have a local view of the time, then of course, there is no objective future and past for parties. And so we have to accommodate that. And thanks to the approximately same speed assumptions, so for example, the initial parties, they do stay close enough for our purpose here. However, joining parties, they have a hard life. And it's actually those that create the problem here. So let's see how joining parties come into play here. So let's assume we have honest and or as we also say, alert parties, those that are synchronized, running the protocol and honest, they have a stable prefix established and the newly joining party comes into play. It has no information about what currently the time is. It has only access to the Genesis block. And as we established before, thanks to the Genesis chain selection rule, it will automatically prefer chains that share the common prefix of the honest and alert parties. Because the Genesis rule prefers the dense prefix that is established by the alert parties. However, there is a big negative point here because timing information is not reliable. It has just its local timer and it just shows an arbitrary time. The party cannot cut off any blocks. So it could be that the adversary just serves to a party. Any extension of the honest party's chains and the joining party has no clue in determining whether this is good or bad because there is no objective notion of density. It's only a local comparison we do, but we don't have an objective notion of density here because we have dynamic participation levels. So the joining party knows somewhere there is this stable prefix of alert parties containing the chain, but it cannot know where it is. It cannot cut off blocks without time synchronization. And this is exactly where now time and synchronization comes into play. So now that we identified the core issue of the problem, let's now look at an overview over our new protocol chronos. So first of all, the alert parties, so parties that are synchronized and honest, for example the inaugural set of parties or any other party that has been bootstrapped, they execute Uroboros Genesis and periodically broadcast synchronization beacons and send it to each other and leave evidence of those beacons in the blockchain. At the end of every epoch, those parties, they perform local clock adjustments based on the evidence they then see in the chain. These are small, limited adjustments. And thanks to this, a joining party will be able to bootstrap the time. So once a joining party, thanks to the Genesis rule hooked up on a dense prefix, you can start recording beacons that the alert parties send out and try to retrace the evidence once it's confident enough to have enough of this. Evidence received. And to connect it to what I said before, once the joining party has information about, so retrace the evidence and then compute the good timestamp, then this directly leads to a good blockchain because then we know they are already on a common prefix with the alert parties. We just don't know what time it is. So once we have the time, we can just cut off the blocks from our local point of view in the future and this will then lead to a blockchain that has the usual common prefix property if everyone else. And at that point, you become as a newcomer, this is the point where you become alert and fully synchronized. So let's now look at each of these steps in more detail. The first step is that the business of the synchronization beacons. Synchronization beacons are broadcast as follows. So in parallel to the usual lottery have improved of state, we run a so-called timing lottery in the first part of the epoch. And it's similar to the normal lottery. So we evaluate the VRF on a new domain that is separated from the other domains by this keyword sync. We evaluate this VRF and if it's smaller than a certain threshold, again, depending on the stake that you have, then you're eligible to broadcast the synchronization beacon. The beacon states your current slot number and you prove that you were eligible to send such a beacon and you send this beacon to everyone. And normal slot leaders, those that win the slot leadership lottery, they not only pack transactions into blocks but also those synchronization beacons. So now let's see the end of the epoch approaches. So how do you perform the local clock adjustments? So throughout epoch, every party records the arrival times of valid beacons. That means those that have eligible proofs that they could be sent, it filter out doubly kits and so on. So there is some caution one has to take here but I won't go into details but this is all possible thanks to the VRF properties. And at the end of the epoch, then what you do is for each beacon you receive, you compute a recommendation. This recommendation is computed as the difference between the slot number reported in the beacon minus the arrival time of the beacon, the time when you first learned about this valid beacon. Then what you do is you look at the stable part of your blockchain identified by a certain slot number or prefix number and you see which beacons made it into the blockchain and those will be relevant now. So what you do is you compute all the recommendations of the beacons that also appear in the blockchain and at the end of the epoch what you do is you add the medium of these recommendations to your local time. So why should this be okay to do it like this? Well for the full proof, of course I have to refer to the paper but let's look now at the concrete example. The example is very simple and it basically considers how two parties would compute the recommendation at the new local clocks based on just one honest synchronization beacon. We as analysts of course we have a bird's eye view on the system we know actually the current time t but of course the parties they deviate from that. So Bob on the top here he thinks it's slot number t minus y and Alice on the bottom thinks it's t minus x. So when the beacon is sent out of a party that believes the current slot number is t minus x it would put that into the beacon and send it out to everyone and we know that this beacon will make it to the two parties in a correlated fashion. So we have this delta bounded delay and so each party will learn about this beacon and compute the recommendation. So now Alice will be the first of the two to arrive at the epoch boundary and will now compute this clock adjustment. So this epoch boundary happens around as you can see after the beacon was first created and sent out and then due to the computation of the difference between the slot number and the arrival time Alice updates this clock to the value r plus the slot reporting the beacon and the only disturbance here comes from the network delay which is then just this additional term delta. So now time moves on and Alice clock is taking along and at some point r prime rounds after the beacon was sent out Bob will do its adjustment and similarly he will update to r prime at this point plus t minus x which is the slot number recorded in the beacon again with this additional disturbing term of delta. So now we see that the clocks after both parties have made the adjustment the delta close. Why? Because the arrival times which is the only disturbance here are delta close. Of course this disturbance if you analyze it concretely it also has to include the clocks might not run at exactly the same speed but this can be controlled as well. So this is the first important property of this clock synchronization mechanism. Note that we didn't use in this argument that these parties that try to compute the recommendation that they are close initially. So there was no precondition in these computations that the party eligible to send a beacon and the party who wishes to synchronize they have to be close that's not a precondition this will turn out to be important later. A second important property about this synchronization procedure is that the adjustments computed by alert parties they are bounded. Why? Because we have the honest majority assumption in place and if you take the median of all recommendations we know it's bound from below and above by beacons that were created by alert parties. So the jumps that alert parties do are limited. This is an important property in order not to jeopardize the security properties. This finally puts us in a situation that we can present how joining parties will be able to compute a reliable timestamp based on what we saw before. So when a party joins the Kronos execution and wants to compute the time, a time that is close to the time of the parties that are already synchronized in the system then it first listens to the network and assembles all chains it sees and by the Genesis chain selection rule that we saw on a previous slide we know that it has the property that any chain it will adopt shares of the Alarchicom prefix with the stable part of the chain that the alert parties have. And this prefix so that Alice cannot tell where this prefix ends but it is guaranteed that this prefix grows roughly at the speed that the prefix grows for the alert parties. So at the point she can be sure that she has received enough chains for this to be true, she starts collecting synchronization beacons. That is she starts listening to the network reports arrival times and she does this sufficiently long to be ensured that she has a large dataset available for later computations of recommendations. And at some point since the alert parties will include those beacons in the stable prefix she will eventually see those beacons appear in the prefix and there cannot be any other chain eventually that will claim otherwise or another set of beacons for this input. Once we waited for sufficiently long for this to be true Alice can perform the clock adjustment. So two properties are very cruel for this. So first of all we have to make sure that all beacons that we now take into consideration are generated after Alice became online. So she has to compute arrival times of beacons that were freshly generated after the point she joined and only then or because of that she would be ensured that she validates and filters beacons with respect to fresh lottery and hence in the same way as the alert parties do. So this ensures that her arrival times are correlated with those of the alert parties in the system. Then of course as already mentioned the beacons have to be in the common prefix such that everybody does the computation based on the same base set of values. So now time synchronization is possible for Alice because we have agreement of evidence and the freshness of beacons and hence we can apply the reasoning that we saw in the example basically to conclude delta closeness. Why? Because we already said back then that in order to jump into or to compute the value and conclude that there are delta close we don't need that Alice initial clock is in any way close to the alert parties clocks. It can be way off and she will then jump directly into the interval that is close with all alert parties. So clock adjustments can be retraced exactly and of course you have to get details right here. So it might be that you have to do it not just once but twice but you also see when to do it again and when to stop. So basically when you did your first adjustment as a joining party and you see oh I'm already past next synchronization point the next epoch then of course you have to do it again and you will also find those or disinformation in the blockchain in the stable part of the blockchain. Maybe as a final remark just to make the point once more. So this can be any external observer doing it. So the intention of Alice does not have to be to join the blockchain execution it just it can just listen to the blockchain network in order to compute a global notion of time namely the time the blockchain execution believes in which is as we saw secure. So this brings me now to the end of this talk. As a summary you can say that Uroboros Chronos is a time synchronizer for the dynamic ad hoc setting where we have access to a CRS and the Genesis block and our parties have access to a bounded delay diffusion network and approximately same speed clocks. The protocol is secure under the honest majority condition. At the same time Chronos is a POS blockchain protocol in the dynamic ad hoc setting. Parties can bootstrap the blockchain based on the Genesis block only and in particular there is no dependency on an external timing service for doing so because parties they bootstrap the time based on the aforementioned same speed clocks or approximately same speed clocks. The security here is based on the honest state majority condition. With that I conclude this talk. Thanks everyone for watching.