字幕記錄


00:01
you
00:11
alright let's get started today I want
00:15
to talk about
00:16
stack and the reason we're looking at
00:19
this paper is that it touches on three
00:22
questions that I find quite interesting
00:25
one is maybe at the lowest level how to
00:27
build a naming system or really a public
00:30
key infrastructure that maps from names
00:32
to public keys and this is like a very
00:35
important question nobody has ever
00:38
really figured out a convincing way to
00:39
build a general-purpose global public
00:43
key infrastructure or PKI so any
00:46
progress in this area with the is
00:49
interesting another reason I'm
00:52
interested in block stack is that it's a
00:54
non cryptocurrency use of a blockchain
00:57
you know so it's just an interesting
00:59
question whether block chains are useful
01:02
for anything other than than financial
01:04
stuff and finally and you know maybe
01:07
most interestingly block sects really a
01:11
proposal for a very different
01:13
architecture for how Internet services
01:16
or really web sites how websites
01:18
ought to be constructed very different
01:20
from the way they're constructed now is
01:21
quite different properties and you know
01:24
the idea is that maybe the the kind of
01:27
approach brock sack
01:28
takes might yield websites that are are
01:32
better you know in some ways than
01:34
current web sites now blocks likes a
01:37
real system there's a company that's
01:40
developing it that's in use by some
01:43
applications i'm just have some users
01:46
however it's really you know you should
01:49
view it as moral work-in-progress then
01:52
kind of this is the final answer they've
01:54
been developing it and making it better
01:56
over some years now i don't think it's
01:59
really to the point where very many
02:01
people would decide to abandon the way
02:04
they build websites now and switch to
02:05
block stack but it's very important that
02:08
somebody out there is exploring how
02:11
things could be different and better and
02:14
block stack is one of a number of
02:16
different projects that are trying to
02:19
push in a different direction for the
02:20
overall architecture of web sites all
02:23
right so the the pitch from block stack
02:26
is that people ought to be building
02:29
decent
02:30
applications so what does decentralize
02:33
mean sort of an idea that's been in the
02:35
air for a couple years now I think maybe
02:40
the best summary is that it's
02:41
applications that are built in a way
02:43
that moves ownership of data out of
02:46
centrally controlled websites you know
02:48
like ordinary web servers and one way or
02:51
another puts control of users
02:53
information more into the users own
02:56
hands so that it's sort of realistic to
03:01
say that users actually own their own
03:02
data instead of you know Facebook or
03:05
Gmail or whoever sort of essentially
03:09
owning their data for them the success
03:15
and the interesting properties of
03:16
Bitcoin have been a lot of what's driven
03:18
the recent activity in this area it's
03:20
kind of an old idea dates back at least
03:22
appeared appear on schemes like Nutella
03:25
and Napster from around 20 years ago and
03:28
further back than that but Bitcoin
03:32
really prompted people to think hard
03:34
about this and to sort of have a bit
03:38
more faith that these kinds of ideas
03:40
could be realized all right so I want to
03:45
kind of outline first what a sort of
03:48
centralized typical you know current web
03:51
site looks like talk a bit about why
03:54
some people aren't really pleased with
03:56
the way current websites work and then
04:00
outline how things might work under a
04:02
decentralized scheme like block stack so
04:05
this is really current websites the view
04:13
is you got a much users sitting in front
04:14
of browsers and there's a internet they
04:20
all talk to the internet you have some
04:22
website out there you know maybe it's
04:24
say Gmail or something and Gmail has a
04:28
bunch of web servers that are owned by
04:34
Gmail right owned by whatever the web
04:37
services and sitting behind the web
04:40
servers is some kind of database
04:43
it's kind of familiar picture for us
04:45
through these individual users this
04:48
database holds the users data like if
04:51
you use Gmail you know your you know
04:54
user ones Gmail is sitting in Gmail's
04:57
database somewhere you know this is a
05:00
database server the Gmail owns and
05:01
that's control over the kind of logic
05:04
for how Gmail operates essentially sits
05:10
in the web servers that own bio are
05:13
owned by Gmail and sort of talk to the
05:15
database to get out of your data alright
05:17
so there's like totally nothing
05:18
surprising here and you know this is the
05:22
way almost every website works this is
05:24
often some JavaScript or something and
05:26
sitting in the users browsers but all
05:28
the kind of critical stuff is sitting in
05:30
web servers or some kind of servers that
05:33
the website yawns you know so four
05:36
different websites the day on the
05:37
database is gonna be things like blog
05:39
posts or mail or you know comments you
05:42
post on other people's reddit or
05:44
something or maybe it's your photos your
05:46
calendar my is your medical records or
05:48
something there's a lot of data that's
05:50
out there at various different websites
05:53
that is in some sense you know the users
05:56
data like it's really the users Gmail
05:57
but gosh it's Gmail or that has control
06:01
over it or reddit that has control over
06:05
the users comments and other people's
06:07
articles
06:07
now this setups been SuperDuper
06:10
successful it's actually and one of the
06:12
reasons to sit it's extremely easy to
06:14
program you know all the logic hears and
06:17
running and servers controlled by Gmail
06:19
they can talk to these databases trough
06:22
in things like sequel databases that
06:23
very flexible query interfaces there's
06:26
like no restrictions on what data can be
06:28
accessed like you know so supposing this
06:32
is a eBay that's running here you know
06:36
the users bids are sitting in eBay's
06:38
database server now the bids are quite
06:41
private right if I'm bidding on
06:42
something I don't want other users to
06:43
see it but there's no restrictions on
06:45
what eBay's web servers can look at they
06:47
can all look at the bids in the in their
06:51
own database they can look at other
06:52
people's bids find the highest bid
06:53
there's really no restrictions so it's
06:55
very very convenient
06:57
for web developers and is very
07:00
successful and so from that point of
07:01
view we should be you know skeptical
07:03
that anything else could possibly be
07:05
this successful or overtake it but the
07:07
reason why you might not think this
07:09
current setup is perfect well there's a
07:12
bunch of reasons that users might be
07:14
dissatisfied one is that if I store my
07:19
mail in Gmail I really have to use
07:20
Gmail's interface to get at it
07:22
you know maybe they provide some other
07:23
ways of getting at it but I generally
07:24
don't have a lot of freedom like Gmail
07:26
sets the rules for how I get at my own
07:29
email right so I might be a little bit
07:31
irritated it's my email but you know I
07:34
don't get to choose what interface I use
07:35
I can't just use any software Lee pretty
07:38
much has to be software that Gmail
07:40
provides or Gmail supports for
07:44
situations like maybe Facebook where
07:48
other people might sometimes see my data
07:50
is really the website that gets to set
07:51
the rules for who gets access to my data
07:54
or how if at all I can control that
07:56
access and websites often are bit murky
07:59
about their promises about how they
08:01
enforce this stuff and again if it's the
08:03
users data like if it's my photos or my
08:05
posts or something it's really kind of
08:08
not that great that I don't have too
08:10
much control over what the website can
08:12
do with it another thing that people
08:15
complain about with the current set up
08:17
is that the website can sniff on my
08:19
stuff like Gmail wants to look through
08:21
my mail they might have good reasons for
08:23
maybe they were training their spam
08:24
generators so that's okay but you know
08:26
maybe looking at my email to think about
08:28
showing me advertisements or to you know
08:31
tell their advertising customers what
08:33
people are interested in these days
08:36
worse the there's a chance that some of
08:41
the employees who work at the web site
08:43
are corrupt and maybe snooping on
08:45
people's data for personal reasons so
08:48
that maybe the company maybe the company
08:50
that runs the website is perfectly
08:51
aboveboard but can't necessarily sit
08:54
claim that it's not always true that all
08:56
the employees are or following all the
09:00
rules anyway so people have a lot
09:05
kind of you know or some people have
09:09
reservations about the way the current
09:11
system works at a kind of more design
09:16
technical level one way to view what's
09:19
going on here is that the main interface
09:22
here is between the entire website and
09:27
the browser's so there's it's HTML
09:31
that's flowing back and forth between
09:32
here typically the websites and the
09:38
database are sort of integrated on this
09:40
side of the interface and all the
09:42
browser really gets to see often is this
09:43
HTML kind of final packaged form of the
09:46
data and you know it's a very user
09:49
interface oriented representation hTML
09:52
is and sort of Nod has nothing to say
09:55
about you know Dave the data itself or
10:00
how the data is controlled and the much
10:03
more interesting interface and where
10:04
this you know a whole discussion is kind
10:06
of going is that this is a much more
10:09
interesting interface because it's much
10:11
closer to the data but in the standard
10:13
setup there's no real boundary there
10:15
though this is sort of the internal
10:17
business how this works is the internal
10:19
business of the website all right so
10:23
that's the existing plan the plan the
10:27
kind of plan that block stack is
10:30
proposing and so there's a number of
10:33
kind of ideas for how decentralized apps
10:36
might work this is kind of one of them
10:40
so I'm not gonna call it block stack yet
10:42
because it's it's kind of much a very
10:46
simplified version we'll just say it's a
10:49
decentralized architecture and here the
10:54
game is that you know we still have a
10:56
bunch of users and users run you know
10:58
iPads or browsers or something
11:04
but we're gonna in this new
11:07
decentralized scheme we're gonna put all
11:09
of the app code is gonna run in the
11:14
client machines in the users machines
11:16
and so this is much more like a sort of
11:18
traditional or it's like you know
11:20
downloading an app from the app store on
11:22
an iPad or buying sort of old-style PC
11:28
hardware like buying a copy of Microsoft
11:30
Word this just runs on your laptop just
11:31
buy some software you run on your laptop
11:34
so no longer running the application
11:38
code in web servers well you know if all
11:42
you want to do is use data on your
11:43
laptop your own data on your own laptop
11:45
and then we're done but what's really
11:49
interesting about you know web-based
11:50
what about internet based applications
11:52
is that you can store your data in the
11:54
cloud and that means you can if you have
11:56
multiple devices which most people do
11:58
you can get at your data from any of
12:00
your devices from your maybe your iPhone
12:02
as well as your laptop and if you've
12:05
stored data in the cloud somehow that
12:07
means you can share data with other
12:09
people and build multi-user applications
12:11
like you know eBay maybe your reddit or
12:15
who knows what shared calendars so the
12:18
other half of the decentralized vision
12:23
is that there's going to be a storage
12:25
system some sort of cloud storage system
12:29
out there by which we mean I mean some
12:35
sort of service that you can buy maybe
12:37
you know from Amazon AWS or
12:39
who-knows-where which was just store
12:41
data for you you can stick data in it
12:43
it's your data they store for you back
12:45
it up
12:46
dumi hopefully some sort of access
12:48
control so whether people can't get at
12:50
it and then you can retrieve it later
12:51
from any of your devices and so now if
12:56
we're building some sort of you know for
12:58
single user applications like you know I
13:01
just need to edit some documents but I
13:03
want to keep them in the cloud you know
13:05
maybe user one is buying storage from
13:07
this storage server maybe it's Amazon
13:10
and user two is buying storage from
13:13
maybe Google's cloud storage system
13:17
for my own data I just talked to my own
13:19
my application code talks across the
13:21
internet to the service storage service
13:24
that I buy storage from presumably pay
13:26
for it myself and user to talk similarly
13:29
to their storage service but if we run
13:32
applications that are built to allow
13:38
users to share data then there's the
13:40
possibility that if I know how to talk
13:42
to you to storage service I can run an
13:44
application that reads data that they
13:47
allow me to read as well so you know if
13:50
you wanted to build some sort of a
13:51
Facebook like thing on this the
13:53
application would know who my friends
13:55
are and reach out to my friends storage
13:59
looking for updates or photos or who
14:01
knows what that my friends have stored
14:03
in their own storage so that means I
14:06
instead of contacting with Facebook's
14:10
website instead in his new model I would
14:11
download an app from Facebook and run it
14:15
and that app would sort of know how to
14:17
find my friends and look at the data
14:20
that they are storing and you know if my
14:24
friend uploads a photo to their storage
14:26
it's really still it's their storage
14:28
they're paying for it it's their photo
14:30
they can use it with Facebook or they
14:33
could use it with other applications too
14:35
because the applications are really
14:36
quite separate now from the from the
14:39
data instead of being combined in the
14:42
existing architecture all right so now
14:47
sort of a technical level the this is
14:52
now the storage interface is now the
14:54
main interface so now we have some sort
14:57
of put get or readwrite or who knows
14:58
what interface as the main interface
15:00
it's no longer HTML it's really a
15:02
primary interface we were worried about
15:04
it's the storage style interface which
15:06
is a much nicer interface to write
15:08
applications to then HTML it's
15:14
furthermore as I mentioned there's a
15:16
much in this architecture where users
15:18
really own and pay for an organizing on
15:20
storage there's a much clearer notion of
15:22
data being actually owned by the user
15:24
and controlled by the user much like you
15:27
own the data on your laptop or in your
15:28
Athena
15:29
as you ones account here in the storage
15:32
service of course there's a number of
15:36
but you know now we're very interested
15:38
in the design of the storage system
15:40
because now this is instead of being
15:42
sort of hidden away inside websites this
15:44
is now the primary interface in the
15:46
system so we care a lot about how it's
15:48
designed so first of all it's quite
15:50
critical that it be a Internet service
15:52
out in the cloud so we can get at it get
15:54
our data from from any of our devices it
15:57
really needs to be general-purpose that
15:59
all the application codes here so we
16:03
don't now in this architecture really
16:04
get to have applications specific code
16:06
at all on the server side because the
16:10
sort of servers aren't don't really have
16:12
anything directly to do with
16:12
applications so we needed a
16:14
general-purpose interface that's
16:15
powerful enough for to let us do
16:17
whatever we need which is a little bit
16:21
difficult to design we now have the
16:25
storage has to be paid for and now
16:28
really the most obvious person to pay
16:30
for it is the user themselves now maybe
16:32
they're willing to do that maybe they're
16:33
not we'd really like to have this
16:36
sharing but we also want to have private
16:37
data and maybe we only want to share our
16:39
data with certain other people so we
16:42
need some reason so the storage
16:43
interface in the storage system one way
16:45
or another needs reasonably powerful
16:47
sharing and permission access control
16:51
systems a more subtle issue is that I
16:56
may run multiple apps some of which I
16:59
don't trust right if I just download
17:02
some multi-user game from the internet
17:04
you know maybe I don't want it to be
17:07
able to look at my email while I'm
17:08
playing that game so that means that as
17:10
well as having a notion of sort of this
17:13
user with this users permission we may
17:16
want to have kind of subsidiary
17:18
permissions where we can talk about not
17:20
just this user as a whole but this user
17:22
when running an application to has
17:24
certain permissions maybe just game
17:27
files this user when running application
17:30
one is allowed to get at the users email
17:33
as well
17:35
alright then interestingly in their
17:38
notices that this storage interface it
17:40
says not as much of a stretch as it
17:42
might have seen say 10 or 20 years ago
17:44
because there's a number of storage
17:47
services out there that are not unlike
17:49
this like Amazon s3 very widely used and
17:52
while it's missing some of the things we
17:54
would need here it's definitely a public
17:57
storage system you can buy storage you
17:59
can let other people use your storage
18:01
you know doesn't have all that access
18:02
control we'd like but it's not too far
18:05
from what's needed here and indeed
18:06
today's papers observes that they can
18:08
layer their storage system on top of one
18:11
of a number of different existing
18:12
storage systems Dropbox is also it's
18:14
another kind of candidate for something
18:16
it's like this and therefore this is not
18:20
as sort of pie in the sky as it might
18:22
seem ok so what would the point of this
18:25
kind of architecture be why would
18:27
anybody care the people who might care
18:31
are the users this this might give users
18:33
more more control of their data it may
18:36
make it easier for users to switch
18:38
applications like if I've uploaded a
18:39
bunch of photos and I'm using one photo
18:42
organization app or photo editing app
18:44
since my photos are totally separate
18:47
from me from the app I could switch
18:48
photo apps and maybe still use all my
18:50
same old set of photos that I already
18:52
have stored it may be easier in this
18:56
architecture to have applications that
18:57
look at multiple kinds of data you know
19:00
maybe it'd be nice that my email system
19:02
be able to look at my calendar and the
19:04
other way around may be nice to be able
19:06
to write backup software they could
19:08
backup all of my data no matter what it
19:10
was
19:10
periodically maybe I'd like to have a
19:12
sort of general-purpose file browser
19:14
which would allow me to look at all of
19:17
my data and none of this is possible or
19:19
convenient and the current architecture
19:21
but it's all seems like within reach now
19:24
that we've kind of concentrated all the
19:27
users data into storage that that they
19:29
own and finally there may well be
19:32
advantages since in terms of privacy and
19:34
snooping
19:35
instead of entrusting my data to a web
19:37
service that who knows what it's doing
19:39
with it if we play our cards right we
19:42
can use encryption these applications
19:44
can encrypt the data before it leaves my
19:46
client machine so that the only thing
19:48
it's a restored here's
19:49
to data and you know when I read it back
19:53
I'll be back encrypted data and then
19:54
decrypt it locally on my own machine so
19:56
Kent storage service never sees private
20:00
data in the clear anyway so those are
20:04
all be sort of you know tantalizing
20:07
possibilities why you might like why
20:09
users might like this architecture all
20:15
right so you you know the if you dig
20:20
down to the nitty-gritty of what these
20:22
applications actually have to do they
20:27
you know you would need to work out a
20:29
whole lot of details like there needs to
20:31
be you know if my application is going
20:33
to be looking at your data there need to
20:35
be sort of conventions for how data
20:37
store here for example you know if I'm
20:41
gonna look at your recent posts you made
20:44
for our social networking application
20:46
you have to have stored them in your
20:48
storage under a key or a name that my
20:50
application knows to try to look look
20:53
for and you have to use a format that we
20:55
all understand so you know there's some
20:56
if we want to do sharing there's some
20:59
kind of standardization obstacles that
21:02
have to be overcome that don't really
21:03
exist for big websites because they can
21:05
just store their data however they like
21:08
okay so there's a question does this
21:10
adversely affect application performance
21:12
absolutely this is likely to be pretty
21:17
bad for performance because in the old
21:19
scheme the old scheme can be the
21:21
existing scheme can be implemented with
21:23
very high performance you know these
21:24
most of the web server may be making
21:27
hundreds of requests the database like
21:28
when you look at an Amazon web page for
21:30
example boy are there hundreds or
21:32
thousands of pieces of information that
21:33
had to be pulled out of Amazon's
21:35
databases you know when they're all in
21:37
the same machine room and those fetters
21:40
from the database take dozens of
21:43
microseconds but if one of these
21:47
applications needs to reach across the
21:49
internet you know maybe hundreds of
21:51
miles away to some storage service you
21:54
know it's now everything's going to take
21:55
ten or a hundred times as long to fetch
21:57
individual piece of data so now that's
22:00
certainly an issue and
22:02
you know it's the kind of that kind of
22:06
issue is the kind of thing that clever
22:08
designers can find ways to deal with so
22:12
it would certainly be a problem but my
22:16
guess is on the sort of total list of
22:18
reasons why this architecture is not
22:19
going to work there's a number of other
22:23
sort of equally unhappy puzzles and
22:26
although it would absolutely change how
22:29
people write applications because
22:31
instead of writing applications that
22:32
assemble lots of they use lots and lots
22:34
of pieces of data you would have to mean
22:36
much more parsimonious I think people
22:39
could work around it all right all right
22:50
so any any questions about this this
22:52
overall arrangement which is the sort of
22:54
arrangement that block stack is shooting
22:56
for so we should just sort of try to
23:01
guess even at this level what kind of
23:03
things might go wrong one reason is that
23:09
this interface is likely to be less
23:12
flexible than database interfaces and
23:15
this actually goes back to the
23:17
performance a little bit you know
23:18
weren't probably not going to be well I
23:20
mean this is sort of subject to design
23:23
but we're unlikely deals to be
23:25
supporting super flexible like sequel
23:29
queries and certainly it's unlikely that
23:31
we're going to be doing sequel queries
23:34
across other people's data as well as
23:36
ours for shared data so that's certainly
23:39
one potential problem is that this
23:40
interface may not be very expressive and
23:43
that's going to be painful for
23:44
programmers another question is could
23:48
this give users an amount of traffic
23:49
they might not handle yeah so that's
23:50
also a potential problem is that you
23:55
know if you don't have very powerful
23:57
queries much of what sequel is doing
23:59
when you talk to a real sequel database
24:01
is that it may be looking through cause
24:05
the database server to look through a
24:06
lot of data but it just finds the one
24:08
answer you're looking for maybe the sum
24:10
of all votes or something it just sends
24:11
that one little piece of final data back
24:13
whereas if you don't have a powerful
24:14
query language you may
24:16
up having to fetch a lot of stuff and
24:18
sort of do the filtering or aggregating
24:20
yourself and that just might be a lot of
24:23
data to be sending across peoples links
24:31
yeah so things might be slower things
24:34
would be slower and it's a question
24:36
whether they'd be too slow maybe in the
24:38
future in which you know everybody has
24:40
broadband internet and we have 5g cell
24:43
phones and none of this one it's
24:44
performance stuff will matter or maybe
24:46
it'll be important I don't know another
24:48
problem with this setup is that there
24:50
are some websites like eBay where it's
24:55
really not the case that all the data is
24:57
sort of definitely owned by one user so
25:00
for eBay for example well I have to have
25:05
two points here one is some data is not
25:07
owned by all users think about the front
25:08
page of Reddit right there's you know
25:10
there's some clever algorithms that
25:12
reddit is running to pick the order of
25:14
items in the front page I mean to do
25:15
with votes and you know who knows what
25:17
like weird those algorithms run and
25:20
where do they get the data and maybe
25:21
where do they store their conclusions
25:23
about the front page so that's something
25:27
it doesn't really fit in me you know
25:29
maybe you could be fit in here but I'd
25:31
be a little bit hard another kind of
25:33
website that seems like could be hard
25:35
here is is a Bay where you want to bid
25:39
against other people you know eBay tells
25:41
you whether you're have the current
25:43
highest bid which requires eBay to look
25:45
at other people's bids and then when you
25:47
finally win you know the amount you pay
25:49
has to do with the second highest bid
25:52
but those bids are private right you
25:55
don't want other people to see your bids
25:58
because then they can just bid one cent
26:00
higher than you and win at a low cost so
26:03
you know maybe you two user two is
26:06
stored a bid here but if my if I'm
26:10
bidding against user two and we need
26:12
this application to tell me if I'm the
26:13
winning bidder that means this
26:15
application needs in order to answer
26:17
that question may need probably needs to
26:19
know user to bid user twos bid which
26:23
means the users to bid has to be
26:24
accessible to me but if my application
26:26
code knows it well it's running on Mike
26:29
computer and I can change it right as
26:31
the usual rules for code you run in your
26:33
own computer and if I change my
26:35
application code to actually reveal your
26:36
bid then that's totally cheating from
26:38
the point of view of what eBay is trying
26:40
to do and so nobody would trust auction
26:42
system that allowed that so it's really
26:46
unclear you know there's probably tricks
26:48
that could be used but you know if we
26:50
just use this architecture and
26:52
straightforward way websites like eBay
26:54
that need to look at other people's
26:57
secret data but not review of the data
26:59
are quite a puzzle as just like and I
27:04
already mentioned that websites that
27:05
have to keep their own data like indexes
27:08
or vote counts or something that's often
27:10
a puzzle also a puzzle because there's
27:12
no notion here of you know the website
27:14
itself
27:15
there's just application code and
27:17
generic user owned storage because
27:22
usually these things so you would
27:23
probably have to augment this with some
27:25
crusted servers to run the privacy
27:28
critical part of eBay or whatever it
27:30
doesn't really fit into the model that
27:31
well another thing that's I'm gonna turn
27:34
out to be bad news here is that if I if
27:38
I have data that I want to share with
27:39
some people than others like I want to
27:41
share data with just six eight to four
27:43
students but not outsiders you know how
27:47
is that actually enforced
27:49
you know we'd really like to use end and
27:52
encryption so we don't have to trust the
27:53
storage server because after all that
27:54
was a big motivation for moving away
27:56
from the current website architectures
27:59
we don't want to have to trust these
28:01
sort of these clouds services so I could
28:05
encrypt the data so that 682 four
28:07
students could read it but it's actually
28:10
quite difficult to do that in any kind
28:12
of straightforward way you know I could
28:15
encrypt the data a hundred times you
28:17
know with once with each of the
28:19
sixty-two for students keys or maybe I
28:22
can encrypt the data once with uh some
28:24
sort of unique key and then encrypt that
28:27
key with a two for students keys or
28:29
something but then you run into a
28:32
question so if somebody drops the course
28:34
and you don't want them to be able to
28:35
see the data you know how do you make
28:36
sure that now they can't see the data so
28:38
you can use encryption for privacy but
28:42
once you get into a sort of complex
28:43
multi user applications with groups of
28:47
users for example cryptography becomes
28:51
can be quite difficult to use to solve
28:54
your privacy problems okay so these are
28:59
ways in which the system may be awkward
29:04
to awkward to program and because it may
29:07
be awkward to program and awkward to
29:08
program up features that may leak
29:10
through into the set of application
29:12
features you can have being limited also
29:14
which it's not going to make users very
29:16
happy either all right this is sort of a
29:20
high-level view of what block stack is
29:24
kind of working towards so now let's
29:28
that's may be focused a little more on
29:30
block stacks specifically where block
29:37
stack actually originated as a project
29:39
was as a secure naming scheme and you
29:43
can still see the the paper we read
29:47
today has a lot of preoccupation with
29:50
naming although if you look at their
29:52
current website and the current stuff
29:54
they write it's much more about this
29:56
decentralized architecture and
29:57
applications and much less about naming
30:00
but name is still very important for
30:02
them so the question is what are they
30:05
you know why are they interested in
30:06
names and what do they need from a
30:08
naming system so the kind of names
30:10
they're talking about in the paper and
30:12
then block stack in general are user
30:15
names these are really human users so
30:20
we're talking about names like you know
30:23
maybe Robert Morris right that's the
30:27
kind of name they're talking about
30:30
because you know in there in there are
30:34
decentralized architecture they don't
30:35
you know those kind of players in the
30:37
game or the users the users of the data
30:39
the users need to control who can see
30:42
their data so they need to be able to
30:44
name other users the specific things
30:47
they need to solve with naming they need
30:51
to if I
30:54
want to look at your data um block stack
30:57
needs to find where your data is you
30:59
know you're storing your data on some
31:00
storage server somewhere I need to know
31:02
what you know are using Amazon AWS or
31:05
maybe Microsoft Azure you know and if so
31:07
which server that Microsoft are
31:10
destroying your data so block stack
31:14
needs a way to map names to the location
31:21
where you store your data so that's one
31:23
big thing that they're doing with names
31:25
but they also need to find out if I
31:28
going to read your data I need to be
31:30
able to do things like check that it's
31:31
really your data you know I can't store
31:34
not the whole point of this is to not
31:36
have to trust the storage services so in
31:40
order for me to be able to check it that
31:42
it's your data we need a way to map the
31:45
name to the public key and we're gonna
31:50
assume that when you store data you sign
31:53
it with your public key first so we need
31:56
both DeMayo names to where to find the
31:57
person's data and map names the public
31:59
key that we used to check that when we
32:01
retrieve data it's really data that you
32:03
wrote and not some kind of misleading
32:05
thing cooked up by the storage service
32:07
or someone else
32:08
now this named a public key thing
32:10
actually is used in other ways too if I
32:12
want to encrypt data so that only you
32:14
can read it probably the way I'm gonna
32:17
do that is to encrypt the data or some
32:19
other key using your public key so that
32:22
only your private key can read it so if
32:25
I want to implement cryptographic ACLs
32:27
or really almost any permissions key
32:29
access control scheme I need you have I
32:32
need to build the name the people who
32:34
can use the data and so if I'm gonna
32:37
make access control lists these are
32:42
usually one way or another
32:44
driven by names and may be able to name
32:46
the people who can read my data so
32:51
this in particular this part that maps
32:55
names of people to public keys this is
32:58
usually often called a public key
33:01
infrastructure or PKI and so what block
33:06
sac is proposing among other things is a
33:08
general-purpose sort of public global
33:12
PKI public key infrastructure to map
33:15
user names to users public keys and this
33:19
is actually quite important because
33:24
people known for a long time decades
33:26
decades that in order to sort of make
33:30
big advances in Internet security almost
33:34
certainly the only way to do that is to
33:37
have some sort of public key scheme so
33:39
that people can sign you know data that
33:43
they produce email and check signatures
33:46
on email or data that they receive for
33:49
other people and also encrypt so that to
33:54
ensure privacy said on the intended
33:55
reader can be the data so almost any
33:59
internet wide scheme or large scheme
34:02
intended to get cryptographic privacy or
34:05
cryptographic authentication ends up
34:07
having to involve some sort of public
34:10
key system public key infrastructure so
34:12
that I can find out now given the
34:14
identity the person I want to talk to
34:16
how do I find their public key and yet
34:20
there kind of isn't a successful public
34:25
key infrastructure system out there
34:26
nobody's really figured out how to build
34:28
one of these that's actually useful and
34:32
as a result people have tended not to
34:34
build or deploy people tended not to
34:38
deploy
34:39
systems with cryptographic privacy and
34:43
authenticity because there's no PKI and
34:46
maybe because of that people haven't
34:48
worked on PGI's because it's not clear
34:49
who would use them but at any rate one
34:53
of the reasons why block stack is
34:54
interesting is because they're trying
34:56
hard to build a global scale public key
34:59
infrastructure
35:02
the kind of names remember the paper
35:04
talks about this Zuko's triangle thing
35:06
the kinds of names the style of names
35:08
that the paper's talking about is three
35:12
these three interesting properties one
35:14
is their unique and what that really
35:17
means actually is that the names have
35:19
global meaning that the name Robert for
35:22
example has the same meaning did it
35:23
everyone in the world you know maps to
35:25
this in the same way the same data
35:28
location same public key to everyone in
35:30
the world of course that's a little
35:31
ridiculous for Robert you know
35:32
presumably my ID under block stack would
35:35
be much longer than that you know maybe
35:37
Robert Morris there's a lot of Robert
35:39
Morris's maybe I'm Robert Morris number
35:41
67 is Robert Morris to register with
35:44
block stack that would probably be
35:45
closer to what my name would be under
35:48
block stack anyway that everybody in the
35:50
world when they see this name and they
35:52
run it through the PKI gets the same
35:53
information about it so this really
35:55
means global might be a better word for
36:00
this the second property the paper talks
36:02
about for names are there human readable
36:06
just like Robert Morris so somebody
36:08
could look at it and you know make a
36:09
guess what a name means and maybe people
36:13
may be able to remember the names
36:14
because they sort of have human
36:18
meaningfulness and the final thing
36:21
they're interested in is that the naming
36:23
system the allocation of names be
36:26
decentralized and you know the paper
36:32
claims on this is the old claim that
36:33
it's difficult to get all three you know
36:40
apparently not impossible since the
36:41
paper does it the sort of intuitive
36:44
reason why it's hard to get all three is
36:48
that if you have a supposing you have
36:51
assistants decentralized there's no one
36:53
entity you know in charge of allocating
36:56
names well if you do that then it's very
36:59
hard to ensure uniqueness that is if you
37:02
don't have some single entity handing
37:03
out the names how do you know you don't
37:04
end up handing out the name same name
37:06
the multiple people if there's not some
37:08
central trusted entity and you can
37:11
actually have decentralized and unique
37:14
names
37:15
but now the most obvious ways to do that
37:18
sacrifice the human readable part so if
37:21
what you decide your names are are gonna
37:23
be you know public keys 1000 bit public
37:26
keys in a public private cryptography
37:29
system anybody can make up a new
37:31
public/private key pair they're
37:34
typically made use random number and
37:37
emmm number generator so since anyone
37:38
can make one up and they're generated
37:41
randomly they're going to be unique but
37:43
they're not human readable so you know
37:46
many of the obvious ways trying to get
37:49
all three of these at the same time
37:51
don't work so well the way block stack
37:59
solves these this at a very high level I
38:03
mean you know they're gonna produce
38:04
their decentralized system and no
38:07
central person handing out names the
38:10
names are human readable and everyone
38:12
sees the same set of mappings the way
38:15
they do this at a high level is that
38:17
they rely on bitcoins ability to produce
38:22
a single ordered log of transactions
38:26
that's one way of viewing Bitcoin is
38:28
that everybody agrees on what the
38:31
sequence of Bitcoin blocks is and you
38:33
know maybe you get temporary Forks but
38:35
Bitcoin rapidly resolves any Forks and
38:37
causes everyone to agree on what the
38:41
sequence of blocks is in Bitcoin ok so
38:44
once we a Bitcoin that's causing
38:47
agreement on a sequence of transactions
38:50
we can stick anyone can stick
38:55
transactions into the Bitcoin log that
38:59
you know as well as maybe being valid
39:01
Bitcoin transactions also have hidden
39:03
away in them name reservation records so
39:06
now this is it's a sort of naming on
39:12
Bitcoin
39:14
you
39:17
blockchain so you know Bitcoin was
39:19
already put getting us sort of unique
39:22
and globally agreed sequence of these
39:25
transaction blocks and now and anybody
39:28
can submit a transaction so in that
39:30
sense it's totally decentralized right
39:32
so how wouldn't what the way block stack
39:37
uses this for naming is that if I want
39:40
to register a name I can pick any name I
39:42
like say Robert Morris as long as it's
39:45
not already you in use and I stick in I
39:48
submit to Bitcoin a transaction you know
39:54
that happens to be a valid Bitcoin
39:55
transaction but it's also going to be
39:59
meaningful to block stack and it's gonna
40:01
say please reserve please allocate the
40:05
name RTM and map it to whatever my
40:10
public key and my information about
40:12
where to have data not man anyone can
40:14
submit these and the block stack servers
40:18
all the blocks tax servers watch the
40:20
Bitcoin blockchain as it involves and
40:22
every time they see one of these records
40:25
that's a block stack transaction as well
40:29
as a Bitcoin transaction the block stack
40:31
servers think about adding this mapping
40:34
to their name database but they have a
40:37
set of rules for rejecting bad block
40:42
stack transactions in the Bitcoin
40:44
blockchain so for example if some bad
40:47
person after I've allocated RTM
40:51
themselves try to allocate RTM well they
40:54
can submit any transaction they like so
40:56
they can perfectly well also submit a
40:59
transaction trying to steal the name RTM
41:01
from me and mapping it to some other
41:03
public key that they know the private
41:05
key for well all the block stack servers
41:09
are watching the Bitcoin chain there's
41:11
only one Bitcoin chain and only has a
41:12
one set of contents and so the block
41:15
stack servers as they you know sort of
41:18
look at successive transactions in the
41:20
Bitcoin chain are gonna see my
41:22
allocation first and then they're gonna
41:26
see this other person's allocation for
41:28
the same name and the rules going to be
41:29
well of a name is already Alec
41:30
you can't be allocated a second time and
41:33
the block stack servers will ignore this
41:36
attempted registration of a name so
41:42
what's being implemented here is a kind
41:45
of first-come first-serve scheme for
41:49
allocating names the first person to get
41:51
a allocation record into the blockchain
41:54
wins that name okay so as far as those
41:59
three properties the Zucco triangle
42:01
properties it's decentralized because
42:04
you know we can uh we believe that
42:06
bitcoin is be decentralized and there's
42:08
no sort of other entity deciding who
42:10
gets what's name it's really just this
42:13
first-come first-served scheme that was
42:16
decentralized the names can be anything
42:18
there's no any strings whatever so
42:21
they're perfectly reasonable to put
42:22
human readable names in here and
42:24
everybody's looking at the same
42:26
blockchain for any name they all see
42:28
they all agree on what the first
42:30
registration of that name is so it's
42:33
unique or globally meaningful as well so
42:37
block sac has managed to actually get
42:40
all three of these Zucco properties in
42:42
their naming system there's a question
42:44
does this mean that the block stack
42:45
servers have to scan the entire chain
42:48
from back to front for adding new names
42:50
yeah so in principle sure the state of
42:54
the name database is really the result
42:59
of interpreting the whole blockchain but
43:01
of course you know the block stack
43:02
servers will will cash you know cash the
43:05
latest state they've seen and as these
43:07
in a database so each block stacks are
43:09
you know maybe he's read this far and
43:11
Bitcoin blockchain and has a database
43:13
that has the current mapping for every
43:16
name seen in all the box before this and
43:19
when they see a new block from Bitcoin
43:21
they'll just look at the transactions
43:23
and update their database incrementally
43:25
to reflect these transactions so getting
43:28
a new block stack server up to speed
43:29
actually does take quite a long time and
43:31
I think when some paper I read said it
43:34
might take up to a couple of days um but
43:38
once your block stack server is up to
43:40
speed then it's all sort of incremental
43:41
additions after that
43:43
but you know there's the larger point is
43:47
that it is indeed the case that block
43:48
stack is kind of piggybacking on Bitcoin
43:52
and you know you could easily argue that
43:54
bitcoin is not very scalable ultimately
43:57
or uses that too much electric power who
44:00
knows what too slow takes a long time to
44:03
reflect new transactions and the cities
44:05
are all sort of somewhat undesirable
44:07
properties that block stack is
44:09
inheriting from Bitcoin but nevertheless
44:11
you know it's not there's not aware of
44:17
another way of getting all three of
44:21
those Zuko's properties in a naming
44:23
system so if you value them your options
44:27
are not you know a lot of options other
44:30
than this approach okay so we may ask
44:35
ourselves whether this naming scheme
44:42
this way of mapping names to public keys
44:45
and places to find the data whether it's
44:49
whether it really has properties that we
44:51
actually like so let's go back over
44:54
those three properties so one the the
45:00
the names are unique everybody in this
45:03
system agrees on what our TM means it's
45:07
really that the names of global meaning
45:09
so question is whether whether we care
45:12
about this whether this is a good
45:13
property so one you know one thing on
45:20
the plus side for this is that it makes
45:22
that having these names like this human
45:28
you know if that having globally
45:32
relevant names means that we can talk
45:34
about names with each other I can email
45:35
you a name and that name will have the
45:37
same meaning for you as it does for me
45:39
because we're both gonna look it up in
45:41
the blockchain and get the same result
45:42
and so that's nice it also means that I
45:46
can look at names that are recorded
45:49
somewhere like in an access control list
45:51
and kind of understand know what they're
45:54
going to me
46:04
but some things that are maybe not so
46:09
great about this is that if you have to
46:12
choose your names from a single global
46:14
pool because that's what we're doing
46:15
here right the since there's just one
46:18
naming system there's just one set of
46:21
names it's gonna mean that it'll be
46:26
actually hard to look at a name and
46:28
decide if it's the name you want like my
46:30
name would actually probably be as I
46:31
mentioned before you know maybe you know
46:34
our TM nine five five eight seven
46:37
depending on how many our teams are so
46:39
this may be my name it's actually very
46:41
hard to look at that and decide is that
46:44
the RTM that you really met and so that
46:47
really undermines the human readable
46:53
property that they have here
46:56
the bigger the system is the kind of
46:58
less valuable having human readable
47:00
names is just people at MIT and maybe
47:02
maybe there's only one Robert Morris at
47:04
MIT although actually there's more than
47:05
one but in other across the world the
47:10
kind of justification for caring about
47:13
what their names are human readable
47:14
that's I guess is very slim it's also a
47:19
human readable can be deceptive
47:21
depending on what's going on so if you
47:24
see a name that looks like you know RTM
47:27
at MIT that edu if you see that name and
47:34
block stack or something it's tempting
47:35
to imagine that it might be connected to
47:38
that email address all right because it
47:40
looks as human readable it like looks
47:42
like it has meaning that's the whole
47:43
point of having human readable names is
47:45
that they kind of suggest meaning to
47:47
people these four blocks stack that's
47:50
deeply misleading a block stack the
47:52
names really don't mean anything it
47:54
simply first-come first-serve so all we
47:56
know all we can tell by seeing this name
47:59
our team at MIT de ed you from block
48:01
stack is that this is this name means
48:04
the first person this name refers to the
48:07
first person who registered this name
48:09
that's all we know initially it might be
48:11
me might be somebody else there's no
48:13
reason to believe it's me or that it's
48:15
associated with MIT or anything else all
48:17
we know is that this name is owned by
48:20
whoever registered at first now if I
48:24
establish say secure email conversation
48:27
with whoever owns this name you know
48:30
using the key that flops that map's us
48:32
to and I spend some time talking to them
48:34
you know maybe I can eventually
48:35
convinced myself that they're the person
48:38
who I think they are but the name alone
48:40
is looks like it's meaningful but
48:43
probably is not in fact very meaningful
48:45
so that's a real defect in human
48:47
readable names it could be defective and
48:53
you know related
48:54
the block SEC naming scheme doesn't help
48:59
me find if if I sort of know who I want
49:01
to talk to block sacks not really
49:04
helping me will fiying the name of the
49:07
person I want to talk to you know I mean
49:09
maybe you know you want to send email to
49:11
Robert Morris you know gosh this is
49:14
deeply unhelpful and it's the only thing
49:16
in the block stack naming system these
49:18
names that are like this so it's really
49:21
not necessarily solving the problem
49:24
people have which is I know I sort of
49:27
know in my head who I want to talk to
49:28
but I don't know their public key and I
49:30
don't know their block stack name either
49:32
how do I find their blocks technique so
49:37
that's a sort of a defect in this system
49:39
you have to really have to already know
49:41
the name if you want to use blocks
49:42
naming scheme but how do you find those
49:45
names some other options that you could
49:49
consider for naming I'm in a system the
49:52
sort of larger decentralized system one
49:55
is that we could just abandon names
49:56
human readable names you know not try to
49:59
get all three of those Zucco properties
50:00
and just use public keys directly so
50:03
that would mean if I want to interact
50:05
with you I need to find your public keys
50:07
somehow maybe you just send it to me
50:09
maybe you tell me something over the
50:11
phone I can use to get your public key
50:13
maybe you send me a secure message or
50:15
write on us with the paper or something
50:17
so we could just use directly use public
50:19
keys and then we wouldn't have to solve
50:21
all these problems although of course
50:22
they're awkward but maybe I can store
50:25
the public keys I know about in my
50:27
personal contact list and they'll be
50:29
helpful be like telephone numbers of
50:31
telephone numbers don't mean anything
50:32
but once I know your phone number I can
50:35
stick it in my contact list another
50:37
possible approach would be to abandon
50:38
the decentralized part and just try to
50:41
cook up some central entity that would
50:43
actually reliably verify identity that
50:46
some centralized entity you know maybe
50:49
the Social Security system that hands
50:51
out Social Security numbers or you know
50:54
whoever it is that hands out driver's
50:55
license or something and kind of
50:56
piggyback on their work to establish a
51:01
centralized notion of you
51:04
any kind of verified names that's
51:09
actually remarkably difficult also but
51:13
you know it's another avenue to think
51:15
about anyway so block stack took this
51:18
particular approach to try to get names
51:21
all right um the let me just kind of
51:29
outline the big picture of the pieces in
51:31
block stack which is sort of a
51:34
refinement of the decentralized
51:36
application diagram that I showed before
51:40
sort of at the bottom they have this
51:42
Bitcoin system that's chugging along
51:46
with Bitcoin blocks and the carry along
51:52
kind of unknown to Bitcoin these blocks
51:55
tech transactions there's a bunch of
51:57
block stack naming system servers and
52:02
it's not really clear whether they
52:04
intend ordinary people to run them or
52:07
that they would be a service in a way it
52:08
makes the most sense for ordinary people
52:10
to run them on their own laptops because
52:12
you have to trust them but that may not
52:16
be so great anyway these blocks like
52:18
naming service servers read the
52:20
blockchain and kind of accumulate a
52:22
database these at least in the first
52:27
instance what's in block what's in the
52:30
Bitcoin blockchain is public keys and
52:34
the hash the cryptographic hash of
52:39
information describing where each user
52:41
stores their data because you could
52:46
store that information this is just you
52:47
know Artyom stores is data in Amazon AWS
52:51
or something but that's too big to sort
52:56
of conveniently store Bitcoin and so
52:57
there's this kind of intermediate layer
53:00
called Atlas it was really it's only job
53:03
is to map hashes of information that are
53:09
stashed and Bitcoin into these own
53:11
information
53:15
one's own record per user and so that
53:17
means that my you know if I have an RT M
53:21
registration and box tack that holds
53:24
with a hash my zone record this just has
53:27
the name or the you know Internet
53:30
address or something of where I store my
53:32
data so it might be you know AWS slash
53:35
know whatever identifier I used to
53:40
uniquely identify the stuff that I store
53:41
in AWS and this is really a reference to
53:46
my where my storage sits where all my
53:48
key value pairs are stored now the paper
53:57
I think the papers vision is that you be
53:59
able to have your zone record point to
54:02
any cloud storage out there
54:04
in fact the cloud storage system has to
54:06
you know obey the block stack interface
54:09
and so you can't just use in the
54:11
existing cloud storage system so in
54:12
practice these all point to block at the
54:15
moment of these blocks tax on gaia
54:18
servers they run this and these are just
54:21
storage servers that know about
54:23
different block stack users and store
54:29
their key value pairs for them and that
54:31
means if i want to read your data out of
54:33
if i'm running in a block second
54:34
application that wants to read your data
54:36
i need to apply your name somehow i
54:38
gotta find your name maybe you tell me
54:41
your name over the phone i type your
54:43
name into the application i'm using
54:45
maybe it's a to do this manager and used
54:48
to go out and find your to do list items
54:51
to show me my app is gonna contact a
54:55
block stack naming system server and ask
54:58
it to translate your name it's been
55:00
watching the blockchain it keeps a
55:03
mapping it knows how to use the hash to
55:06
find your zone record your zone record
55:08
points to some data owned by you and
55:10
Gaia and then my app fetches this data
55:14
it needs to verify the data so all
55:18
blocks active apps expect data to be
55:21
signed by the owner in Gaia and the
55:23
public key to check your signature on
55:25
the data you know I can use your public
55:27
key or public keys embedded and
55:29
your record and Bitcoin and so I can use
55:32
it to my app really can use it to check
55:36
the signature here make sure that this
55:37
is data that you actually produced and
55:39
not something that an untrustworthy gaya
55:41
server okay so that's sort of a basic
55:48
outline of how this works it it turns
55:52
out that sort of embedding their
55:53
information on the Bitcoin blockchain is
55:55
not as straightforward as I described
56:00
they they have they need to take special
56:03
efforts to detect Forks for example
56:05
because they don't get to the blocks
56:07
that name servers don't sort of get to
56:09
realize directly that there's been a
56:11
fork that to detect it I mean they means
56:13
the detective cuz the fork might be part
56:14
of an attack and you know the Bitcoin
56:20
isn't filtering out bad records for them
56:24
and so they have to do their own and
56:26
force their own rules on the records
56:27
they get out like ignoring duplicate
56:29
registrations there's they also turns
56:32
out need to chart they charge fees for
56:34
registering a name and that means that
56:35
the Bitcoin transaction that is the
56:39
registration of a name has to pay some
56:42
money to what's called a burn address
56:44
pay some Bitcoin current bitcoins to a
56:47
burn address in order to have the right
56:49
to register that name and the block
56:52
stack name service actually checked at
56:53
each name registration transaction did
56:56
pay enough Bitcoin to this burn address
57:00
for which there's no private key so that
57:02
money simply disappears and the reason
57:05
they do this the reason why they require
57:08
every name registration to waste some
57:10
money is that otherwise it's too easy
57:13
for bad people to just register lots and
57:16
lots of names like certainly the
57:19
experience with the domain naming system
57:21
where for a while name registration was
57:22
free those that people who just register
57:24
you know every single you know one two
57:27
and three letter combination that's
57:30
possible and they wouldn't own all these
57:32
names for free or somebody knowing that
57:34
I would really like to own the name RTM
57:37
might register before me
57:41
and then if I wanted to use it I have to
57:42
pay them so in order to try to deter
57:44
that they have a they require fees and
57:48
that's actually pulmo probably an
57:50
important part of of the design since
57:53
free stuff on the internet tends to be
57:55
yeah
57:55
tends to be abused or sort of drowned
57:59
out in intentional spam all right one
58:07
detail on this picture so I left out the
58:08
claw in this picture we have the client
58:11
machines running some app this is the
58:16
client device now when the app needs to
58:21
get out my data get at my data it needs
58:26
to be able to decrypt it whenever it
58:30
writes data into my guys storage my app
58:32
needs to be able to encrypt it
58:33
ultimately using my private key and when
58:36
I fetch data back it nice to be able to
58:38
decrypt it also ultimately one way or
58:40
another using my private key so these
58:42
applications need to get at private keys
58:44
but private keys are super duper
58:46
sensitive and whereas these apps are
58:50
just whatever junk I downloaded from the
58:52
block stack app store and possibly
58:54
totally untrustworthy so we never want
58:57
to give them a private key so what
58:59
actually happens is that there's a
59:00
separate program that I'm always running
59:04
called the block stack browser and it's
59:12
this program
59:14
that knows my private key and so if the
59:17
app wants to do stuff as me is really
59:19
got to first do it through the block
59:22
stack browser and in fact the way this
59:25
place has so complicated in detail the
59:27
block style browser essentially makes up
59:29
kind of per app private key in this app
59:32
uses just the per app private key and
59:35
not my real sort of master private key
59:38
so this app again doesn't get to know my
59:39
real private key but this issue of not
59:43
revealing sensitive key material to the
59:45
these apps which may be indeed quite
59:48
untrustworthy as an important detail and
59:51
blocks that keeps my master private key
59:53
secret now on the topic of private keys
59:57
a weakness in essentially every system
60:00
you know like Bitcoin itself and block
60:03
stack and also is that users tend not to
60:09
be as careful as they ought to be about
60:11
private keys so am i you know if I'm
60:13
gonna use block stack from my phone you
60:16
know that means my phone has to know my
60:17
private key if I leave my phone in the
60:21
cafeteria
60:23
then whoever finds it now has a device
60:26
that has my private key in it and can do
60:28
anything as me because as far as block
60:30
attack is concerned they are me they
60:32
know my private key users also tend to
60:36
lose private keys you know I don't use
60:40
the service for a little while you know
60:42
I forget whatever passphrase it was for
60:44
example that was protecting the private
60:45
key or I put my private key on a USB
60:48
someone key from somewhere for
60:49
safekeeping and then lose the USB key so
60:52
that's completely routine problem that
60:56
users have and block attack actually
60:59
does not really have an answer to these
61:01
questions I'm a pretty much assume the
61:04
users will be careful of their private
61:05
keys and if you lose your private key
61:08
blocks that can't get it back for you
61:10
it's like it's in order to be super
61:13
secure in order if you're not to have to
61:14
trust block stack only your client knows
61:16
your private key if you lose your client
61:18
we forget your what are the
61:22
phrases you're just completely out of
61:24
luck and blocks that can't help you and
61:28
so this is just a difficulty in real
61:31
life people don't want to use systems
61:32
that are that brittle and in real life
61:37
what ends up happening is that even
61:38
systems that have you know serious
61:40
cryptography usually have some sort of
61:42
key retrieval scheme whereby I can stir
61:46
something I can tell a block stack maybe
61:47
my mother's maiden name or you know they
61:51
send me an SMS thing to my telephone or
61:53
whatever some scheme I can use to
61:55
recover my private key and those if you
61:59
want to attack a system it's often the
62:02
password recovery of the key recovery
62:04
aspect of the system that's the easiest
62:06
to attack I just call a block stack I
62:08
said I said tell them you know I'm
62:10
really I'm Robert Morris you got to
62:13
believe me please you know we said
62:15
Robert Morris it's key for me your
62:17
password
62:17
nah man tell me the new password and if
62:20
I'm convincing enough you know and the
62:22
system allows sets they're gonna
62:27
let me have it and they're probably also
62:29
presumably if it's an attacker really
62:31
who is calling and pretending to be me
62:32
they'll let the attacker reset the
62:35
password of the key or whatever blocks
62:38
that happens not to allow that because
62:39
it's so obviously insecure but real
62:41
world systems if they don't want their
62:46
users to abandon them need to have a
62:49
better plan and it's not clear how to
62:50
make that better all right
63:01
all right there's a couple of sort of
63:08
issues I want to talk about that come up
63:11
in the system for me the block stack is
63:14
really a kind of source of questions to
63:17
think about or even kind of things that
63:21
are not really well you know suggestions
63:25
for use for more things to work on you
63:28
know block SEC I think black sex
63:29
situation now is that you probably
63:31
wouldn't actually want to use it to
63:34
build a real system for real users but
63:38
it's kind of trying to point the way to
63:40
a system that might someday be if enough
63:42
cleverness was put into it enough
63:44
development was done on it might
63:45
actually be a system that was both
63:47
convenient for programmers and actually
63:50
provided some real value for users but
63:52
probably not there yet but its entrance
63:54
to think about you know how it could be
63:56
designed differently or better in order
63:58
to kind of get it closer to something
64:00
that were really useful so one question
64:05
you might have especially in the context
64:07
of a to for is whether block stack
64:08
really needs to use Bitcoin like that
64:10
points really not you know not that
64:13
great the fees that you have to pay you
64:18
know to register a name you know vary in
64:20
value in Bitcoin by factors of you know
64:22
100 almost every night overnight at
64:26
times in addition people really down the
64:29
way like the way Bitcoin you uses
64:31
proof-of-work to burn up CPU in order to
64:34
be secure so you know Bitcoin is not
64:37
perfect although it's kind of an
64:39
important part of the system otherwise
64:40
they couldn't you know they it's not
64:43
clear how they would do names without
64:44
this whole Bitcoin tie-in and so one
64:46
question you might have eight to four is
64:49
whether I'm certificate transparency
64:51
which is a you know we looked at it last
64:54
week a certificate transparency does not
64:57
have mining does not have proof of work
64:58
and yet you know it's powerful enough to
65:01
be helpful in a naming system and so
65:04
question is whether said of Bitcoin
65:06
whether box that could use something
65:09
like certificate transparency not in
65:12
order to
65:14
enforce adequate rules about names and
65:19
actually don't know the answer to that
65:21
my guess is the answer's no my feeling
65:26
is that while certificate transparency
65:28
can reveal conflicts or conflicts really
65:32
is a to people registering the same name
65:35
like if you required everybody to submit
65:38
their name registrations to a
65:39
certificate transparency log yes indeed
65:41
you would be able to see that two people
65:43
had registered the same name but
65:45
certificate transparency doesn't resolve
65:47
ownership conflicts so if I register RT
65:50
you know supposedly last year I
65:51
registered RT M and I've been using it
65:53
happily for the next year and then
65:55
somebody else registers RT M today yeah
65:59
you know they'll submit their
66:01
registration to a certificate
66:03
transparency log and so now maybe that
66:06
will make my name unusable or something
66:09
but it's not clear really who should own
66:12
the name because certificate
66:13
transparency doesn't have very powerful
66:15
mechanisms for resolving these conflicts
66:19
you might think that order would be
66:21
enough but the same records and
66:25
different certificate transparency logs
66:26
can have different order because there's
66:28
nothing forcing the different
66:29
transparency logs to to have exactly the
66:33
same order and if you want you know how
66:37
come Bitcoin can enforce every replica
66:39
of the blocks you'd add the same order I
66:41
believe the answer to that really boils
66:43
down to bitcoins mining bitcoins mining
66:46
that resolves Forks it resolves
66:49
deferring copies the blockchain and
66:52
forces agreement and if you don't do
66:54
mining at least you know or something
66:57
like mining it's it's not that clear how
67:00
to add a enforce agreement on the order
67:03
of the records so in addition the fees
67:10
the block stack charges are probably
67:13
critical to avoid various kinds of spam
67:15
in the naming system various kinds of
67:18
abuse and you know block stack built on
67:20
Bitcoin can sort of automatically
67:22
require people to pay to register block
67:24
stack built on certificate transparency
67:25
you know
67:27
there's no direct mechanism to require
67:31
fees and in fact that I think the point
67:36
here is actually quite a bit larger and
67:38
that's that a lot of people talk about
67:43
using blockchains for lots of stuff
67:45
other than cryptocurrency but in fact it
67:48
seems difficult to use blockchains open
67:51
block chains with unrestricted access
67:53
except when they're coupled with some
67:57
kind of crypto car
67:58
cryptocurrency again I don't know if
68:01
that's true but it's certainly my
68:02
impression all right so a big question
68:07
with block stack is whether it's going
68:10
to be convenient for programmers and to
68:12
me the this questions absolutely
68:15
critical because it's one of two very
68:18
critical questions the other one is the
68:20
other critical question is whether it
68:22
makes users lives better the my
68:30
perception at the moment is that indeed
68:32
box AK is not particularly convenient
68:33
for programmers I think I've used block
68:36
stack a program block stack I've tried
68:38
to build system to like it and my strong
68:41
impression is that it's just a lot more
68:44
difficult to build a web application on
68:45
one of these decentralized platforms
68:48
than it is on the ordinary platform and
68:51
you know that's kind of damaging because
68:52
if the website developers aren't on
68:55
board then nobody's gonna get a lot of
68:57
traction and if the website developers
69:00
don't like you know I sort of feel that
69:03
the system is difficult to program the
69:05
only way that you're ever gonna get any
69:07
traction is if the attraction to users
69:10
is so strong that it that you know users
69:12
demand decentralized applications and
69:15
that might force programmers to use it
69:18
but the programmers just speaking for
69:20
themselves my guess is that the
69:23
architecture in which basically all the
69:25
code is sitting in the client and we
69:27
don't have special you know website
69:29
servers is just pretty painful it's hard
69:33
to have data that's specific to the
69:34
application because all data is owned by
69:37
users it's hard to have indices or you
69:40
know counts of likes or vote
69:42
you know the kind of front page rankings
69:44
as I mentioned for reddit or hacker news
69:46
are difficult there's all kinds of stuff
69:47
it's a pain if you don't have a notion a
69:51
notion of the website itself with its
69:53
own data this the access control is
69:59
actually equally painful it's very easy
70:01
to write the code and a traditional
70:03
website to decide who gets to see what
70:05
data in a decentralized system and
70:07
really you only can be enforced using
70:09
cryptographic access control or these
70:11
that's the way it seems from the example
70:14
a block stack and it just turns out for
70:17
all except for very straightforward like
70:20
one user using their own private data
70:21
using cryptography to enforce access
70:24
well it's just pretty painful
70:29
so programmers might only be excited if
70:33
users were excited so our users gonna be
70:36
excited you know one way to look at that
70:37
one way to ask that question is whether
70:41
this kind of decentralized use your own
70:42
storage is good for user privacy because
70:46
that's one of the big pitches is that by
70:49
storing data on storage services the
70:52
users own and pay for you know maybe
70:55
that'll keep the data more private more
70:56
secure than storing their data on
70:59
websites so that really am I asking is a
71:02
better than trusting Facebook or Google
71:05
to keep my data private both from
71:09
Facebook employees and from other users
71:11
of the site and from hackers you might
71:13
try to break in and that's just a
71:17
question right you know sort of depends
71:20
on how much you trust Facebook the fact
71:21
is that you're still storing your data
71:23
out there in the cloud on some service
71:25
just maybe not Facebook and you're still
71:30
running software on your client that is
71:33
presumably provided to you by Facebook
71:36
so you're running Facebook software and
71:37
your client you know it's so you're
71:42
still kind of trusting this this this
71:44
code that facebook gives you or wherever
71:46
you get your code from and you know for
71:49
the real hackers among us you can look
71:51
at the code and convince yourself
71:52
because you're running it on your own
71:53
computer and can meet yourself
71:54
okay but for the general public you know
71:57
the difference between talking to
71:59
Facebook's web software on their web
72:01
server and my name's Facebook software
72:03
and their own client may not seem very
72:05
great and who knows maybe the Facebook
72:08
app you're running is sort of sending
72:11
Facebook information about what you're
72:14
up to snooping on you there's a question
72:16
about wise cryptographic access control
72:18
painful for programmers um one way of
72:21
looking at it is that the access control
72:23
checks that you have to do in a sort of
72:26
standard web site are very
72:27
straightforward you just write a little
72:28
bit of Python code or whatever it is to
72:30
decide whether some user should be able
72:33
to see some data and you can even
72:35
compute using data that the user
72:36
shouldn't see as long as you don't
72:39
reveal it to the user
72:40
whereas in anything but simple
72:44
situations doing the cryptography to
72:50
allow some users but not others to get
72:53
out your data it just requires a lot
72:56
more thought so you know suppose the MIT
72:59
registrar maintains a list of all the
73:02
people taking 8 to 4 and if so as a
73:05
group so they maintain that list and I
73:08
want to use it in order to govern the
73:10
protections for some file stored in
73:14
Krypton with cryptographic protection
73:16
and block stack because that lists that
73:18
group list of eight to four students may
73:20
change you know the what I do for
73:24
encryption may have to change too so I
73:27
you know if I encrypt I could encrypt
73:31
the data once with the key of each user
73:34
in the a to four group list and that
73:37
would work because they could just read
73:39
the copy that was encrypted for them but
73:42
then as users are added that the
73:43
Registrar changes the list as or deletes
73:45
users
73:46
I need my software I needs to notice
73:48
that that list has changed and busily go
73:52
out and change the way stuff is
73:55
encrypted we encrypt for the new users
73:56
deleting two copies for the old users
73:59
and that's just like a level of damage
74:01
that or a level of kind of complexity
74:03
that doesn't exist in current systems
74:05
not necessarily they can't be done
74:09
but it just does require a lot of
74:11
machinery that is not ordinarily needed
74:19
all right another sort of trust issue
74:27
from the point of view of users is that
74:30
they still have to trust their storage
74:32
provider to preserve their data and they
74:36
still have just trust their storage
74:37
provider to always serve up the most
74:38
recent copy right the cheating storage
74:41
provider might try to cause trouble by
74:44
serving up an old version so we lease in
74:46
that block stack design you know you're
74:48
really trusting your storage server this
74:50
central service is from your point of
74:52
view to do the right thing with your
74:54
data to preserve it to back it up to
74:57
produce it when asked for to produce the
74:58
right version when asked for and it is a
75:01
bit of a question for just ordinary
75:03
people that if you're trusting Amazon
75:07
AWS to store your data correctly and not
75:11
lose it it's not that much bigger of a
75:14
step to trust Amazon itself to run the
75:16
website and you know we can argue about
75:19
with it that's really exactly true but I
75:21
think you know from a high-level point
75:23
of view from most people most ordinary
75:25
people it's really a pretty pretty small
75:28
distinction and you would have to
75:30
overcome that in order to persuade
75:31
people that boy you know the block stack
75:35
approach of using Amazon as a storage
75:38
service is better than the standard way
75:41
of using Amazon as a website another
75:45
question from users point of view
75:47
another pitch for why that decentralized
75:49
architecture might be better for users
75:51
is that it gives them more control over
75:53
over you know not privacy but just sort
75:56
of what applications they use with their
75:58
data so if you want to switch
76:00
applications but still use the same data
76:02
like change photo editing apps like I
76:04
mentioned in principle that should be
76:07
easier with this sort of decentralized
76:10
app architecture because the you know
76:14
the again the data is not owned by the
76:16
application website if you want to use
76:18
the same data in multiple different
76:20
applications like I want to
76:21
a calendar app but use the same data
76:24
from my email app that also is you know
76:27
relatively convenient with the
76:29
decentralized scheme because the data is
76:31
sort of again independent from the
76:32
applications you know maybe users want
76:37
this maybe they don't probably not at
76:39
the top of anybody's list and there's an
76:42
additional problem that in order even
76:44
for that vision to work there has to be
76:46
a lot of standardization of formats of
76:49
files so you know the calendar file my
76:53
calendar program has to store its
76:54
calendar data in a format that my email
76:57
program can understand otherwise that
77:00
doesn't work and if I'm gonna switch
77:01
email applications well my old email
77:04
application better have been storing my
77:06
email in a format that my new email
77:08
application can understand otherwise
77:11
this vision of decentralized apps me
77:14
easy to switch among can't be made to
77:17
come true a final issue that worries me
77:22
about this whole thing is that it's not
77:24
clear that users are going to be willing
77:25
to pay for their own storage if people
77:28
aren't willing to pay for that I'm
77:29
storage then this whole arrangement is
77:31
pretty unattractive because a lot of the
77:34
point was to sort of give the users more
77:36
responsibility over their own storing
77:39
their own stuff users of I think or so
77:43
used free advertise advertisements
77:47
supported services that they just might
77:50
not be willing to get on board with with
77:52
paying for internet stuff
77:54
alright nevertheless I feel like this
77:59
whole area is you know well worth
78:02
keeping an eye on maybe even worth sort
78:04
of working on different pieces of it to
78:06
be are interested in looking for
78:08
research problems and well I don't
78:12
really believe it right now for the
78:13
reasons that I outlined I think it's
78:17
absolutely worth pursuing because
78:19
someday if like definitely the way this
78:23
these kinds of decentralized systems
78:25
work has been getting better and may
78:28
eventually be good enough that that
78:30
there's serious competition for
78:33
existing website architectures and I
78:35
would just love it if if such serious
78:38
competition like that were to arise all
78:41
right
78:42
that's all I have to say next Tuesday
78:45
the last class amazing meeting is going
78:47
to be project presentation so I'll get
78:50
to hear what what everybody who hasn't
78:52
been doing lab four has been up to
78:56
please ask me questions if you have