Universal Hash Time

Transcript

all right actually I'm very fortunate to be able to follow one I'm talking about this beautiful collection of hashes this beautiful forest of hashes because that's exactly what I'm talking about it's the same thing except I'm going to talk about it not from a perspective of content but from a perspective of time so compared to a lot of what you've seen today this is actually a very simple presentation I just want to in the next 15 minutes hopefully get you to think about a new cryptographic way of thinking about time so I think most people when they think of time they think of probably what their local clock says right now they think of a number some of you as developers will think more abstractly as something like UTC or maybe you'll even think of something

even more abstract than that but in either case you're probably thinking of some kind of ordered numbered property and when you get into the cryptographic basics of how a lot of these blockchain systems work you don't have that sort of a numbered property anymore you only have one relation that you can enforce and basically that relation is that if something happened before you wrote created a certain hash then then you know the order in which the hash and the content were created the way that this is commonly used is in proof of existence like the talk mentioned earlier we both were probably all familiar with the example of if I take a document and I hash it and I put that hash inside of the Bitcoin blockchain or

the a theorem blockchain then at a later time I can argue that this document already existed at a certain point in time because it was included in this particular block header and I can give a very efficient merkel proof that that this was the case this is an image I just randomly pulled off the internet about structure block who can see the same shape that's been up here three or four times today of all our wonderful content being hashed up into a route in a series of blocks but a lot of people may not realize that we're creating a little bit of a fragmented approach to time when we do this because every individual blockchain has its own idea of sequence and it's not just block chains actually this is an image of a traditional linked

timestamping provider called guard time you'll notice it's the exact same structure we've got a bunch of individual content being merkel dumped into route and created into something over time and this is really unfortunate because if the only measure of time we have is the relative ordering of two things that one thing happened before the other thing then if we're creating lots of different fragmented versions of time we're losing something and it's unnecessary because we can very cheaply keep all of this information and this is the idea I call universal hash time so just to mention a few sources of time that are out there right now of course we have the etherium network Bitcoin all the blockchain networks have some kind of chain of headers that's keeping track

of time and ticking along traditional links dank linked time stamping providers include guard time the open source true timestamp all strew a couple of other companies and the answer to this is really very very simple and this basic structure where you have some kind of packet of data that is somehow identified it's it's signed but this is an abstract signature it could you be just the existence of some proof of work or compliance with some sort of pre agreed format and that it has a link to the previous tick the previous packet and then on the other side it has the root of some authenticated data

structure it could be a Merkel tree but it could really could be any authenticated data structure of course in a theorem we're familiar with a Patricia tree there's anything any what variety of things that you could use as long as we have these systems there's a very clean and simple way that we can bring all of their concepts of time into alignment and that is we just put the hash of every series of ticks in every other series of ticks simple right this is the ID I call universal hash time and basically this pattern here wherever we see it we're gonna we're going to come up with a term for that that allows us to recognize that we're just going call them tick chains obviously block headers are what we think of in the blockchain world with aetherium of

things like this but it's the exact same format in traditional links times time stamping and any other format anything that constitutes a ticket ain we're just going to try and put hashes of all that into every other system so in terms of the the structure here that we're familiar with this is shared both across blocks with block headers and also traditional link time stamping we have a bunch of hashes that we're going to try and include and we're gonna hash them up into for example Merkle tree or anything else and we're gonna put that root hash inside of the packet and then we're gonna have a sequence of packets and each each packet is going to contain the hash of the previous and this this this

pattern that we use in proof of existence it's the same pattern that is called electronic certification in the link time-saving providers it's it's just one same thing over and over again and I'm just gonna skip ahead here and what it allows us to do is produce these very compact receipts so if the the data is in blue here and we want to be able to prove that that the data was hashed into this particular tick here we only need to store the red parts and so this is how we form our merkel proof for example if this is a Merkel tree or whatever our system is we have some kind

of receipt now in the in the context of universal hash time we're gonna say unlike in block chains we're not going to try and store this we're not going to try and replicate it we're not going to try and make it available if you've got some content that you care about the stamp of your gonna be the one who holds on to this receipt and so for example if one one hash chain is being stamped into another hash chain whoever cares about the hash and they can hold on to the receipts we don't have to store and replicate this data and that means going back to the earlier scalability conversations we were having that all this is going to scale extremely extremely well and so in terms of in terms of scaling we don't have to have every party keeping a copy of everything

every party validating everything we basically just have to sneak these hashes in every once in a while and then ourselves keep track of the fact that we did this as long as we have this property we're going to later be able to come back and give time like guarantees that can be cryptographically verified and importantly those timely guarantees can be cryptographically verified inside of blockchains normally if I want to prove inside of a blockchain that something happened at a certain point in time I have very limited options for that I need some kind of centralized provider to timestamp or something like this and what we're gonna see is that this has a lot of applications in the blockchain world the first question that comes to mind is the economics of this if you're going to be moving between chains and

and stamping between chains and tried to do this reliably how can you pay for it especially if the chains maybe are moving in different cycles and have different cryptocurrencies there's a very very easy answer to this for those of you who are familiar with the concept of payment channels state channels is the generalized idea of payment channels and it's the same basic concept that you'll have heard two or three times today if you can produce a game theoretic smart contract judge that's capable of judging between two participants and accepting their proof accepting their evidence and on the basis of that evidence deciding what's going to happen then you normally won't have to submit that evidence as long as you're confident that someone has signed

something and you could submit it to a smart contract and get something back out then you probably never have to do this because you can kind of just agree that the transfer has already taken place enforced only if necessary by the blockchain the same technique that swarm was referring to earlier this is fantastic because if we can write smart contracts that allow us to payout only in the event that our hashes were included into other chains and this can be paid for by anybody can be the person whose data is being hashed into the chain but it can also be someone who wants to fund this as a public good for example maybe I want to fund as a public good the idea of having all a theorem hashes included in the Merkle tree of Bitcoin and vice versa then I can just write those terms into a smart

contract and I can design that smart contract in the form of a state channel and what's gonna happen is that because the the ability to appeal to the blockchain is present in most cases I'll be able to pay out that entire smart contract instantly in real time very small amounts no transaction fees and even though I'm incentivizing this as a public good so it's all it's all a trustless system it's all very easy to support very easy to have kind of follow the same ipfs model of throw the expectation out there and let the let the network respond if it thinks that what you're doing is valuable so the result that we have if we can do all of this if we can efficiently hash most of our different conceptions of

cryptographic time most of our different tick chains into each other's ideas is that we're going to get a very very helpful property so let me just explain what's happening in this diagram here this along one side is kind of a normal series of ticks this could be for example the headers of the etherium network or it could be the ticks in your centralized link time stamping provider like guard time or whatever your reference point is universal hash time was entirely relativistic it has no concept of an absolute state of things it just tries to be very greedy and collect all of the possible relative information about what's available so for example in inside of these various Merkle trees on this particular hash

chain we have all kinds of different data that's been submit and some of that data is the ticks of other chains that I've colored in yellow and green over here so for example if this is aetherium let's say this could be guard time up here this could be a Bitcoin out here we have some additional data that someone's doing a traditional proof of existence on here hopefully we have ipfs up and running so that we've got the vast majority of data on a system like this addressed by hash and so it's something like a major news event or anything that happens in in real time is being included into this structure out of this we start to get some very important timing information because if you have a normal policy of data all data everywhere being stamped into a tick

chain then then what you end up coming away with is the assumption that the earliest producible is in fact the time that content was created now obviously this isn't true historically if we only start building the system now then the earliest available hash of the Napoleonic Wars will not be the time that the Napoleonic Wars happened but in general this will be true going forward so if you can think of a detailed description of a current event that has enough features in it that someone would not have been able to guess in advance that that news article would be written in that exact way then the earliest example the earliest time receipt that you can get the earliest stamp receipt that you can get of a news article covering that event is a reasonable cryptographic

proxy for the time that this actually happened so you start with the the earliest event of something for example could be this data here and the earliest receipt that's available you can just produce this in a normal challenge/response format by just throwing out a reward to the network now you can ask what happened before the earliest available receipt of this and this turns out to be incredibly useful in the cryptographic context so a simple example would be we've talked about proof of stake and the problem with long-range attacks one of the problems with long-range attacks is that you have no conception of time if you're on if you're online on the network you know what's happening live and you know that for example this person over here was not part of the consensus at this time

but then then the the owners of that stake moved their coins and then only later sold their keys and after those keys were available very cheaply a very little economic cost then the attacker acquired them and then produced this is a time difference and what this allows you to do is is you still have the subjectivity of any proof of stake system but if you have something like universal hash time set up you can take the trust out of the subjectivity so let's say that you've been offline for a period of eight months and you want to figure out what the correct consensus set is now you could find someone that you trust you could try and accumulate trust through a series of social networks or trusted websites but what you could do instead is you could say I know

something that happened four months ago so let me Google for something that's stored on ipfs that happened four months ago that's an article that described this okay I found this let's find the earliest stamp receipt I can find for an article describing this event happened four months ago okay it's it's it's this one here now if I come across a chain and proof of steak that's claiming that it initiated four months before that I can issue a challenge to to those those validators on that chain and I can ask if what you did if you when you sign these blocks and from this consensus was before this event four months ago then why don't you have a hash of this consensus somewhere

upstream somewhere in the past hash cone of this receipt that I've produced because any possible news article that describes an event could only have been created after the event which marks a kind of a barrier in one direction at time so if something happened before that it becomes unreasonable even on your own personal basis before you check anything in the network to think that somebody would have produced this consensus and would not have hashed it somehow into the past of this particular event that's one example there are numerous other examples of how this becomes cryptographically useful I'm running out of time and I'm gonna stick within that so you can come up and ask me questions about this later but I'll just give one other one very quick let's say you're producing some live news

footage and you want to produce a bound on the idea that this news footage was faked and say that if it was faked at least it was faked in real time what you can do is you can take a little monitor just a little display put it right on top of the camera have this hooked up to some thick chain that's producing content relatively often say a theorem it's coming to be 15 seconds or so and then every every few seconds on the live broadcast as the the news photographer whoever is present in the scene looks over to the camera they just read a few of these digits off just just enough that it's it's statistically unlikely that they could have pre-recorded this so this is a recent hash that say something from from here you read off the hash into the data and then the

video hopefully is being stored into something like IP FS is being hashed right back in which means we now have this specific window in between this tick and this tick that we know that the video was actually created or in some sense rendered or modified and this gives us a very narrow window and allows us to in some hence prove that the video was created or faked in real time which is probably harder so that's universal hashtag thank you