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