WEBVTT Kind: captions Language: en 00:00:07.630 --> 00:00:40.110 align:start position:0% [Music] 00:00:40.110 --> 00:00:40.120 align:start position:0% 00:00:40.120 --> 00:00:43.720 align:start position:0% hello<00:00:41.120> again<00:00:41.320> so<00:00:42.320> this<00:00:42.649> is<00:00:42.710> going<00:00:43.070> to<00:00:43.160> be<00:00:43.489> a 00:00:43.720 --> 00:00:43.730 align:start position:0% hello again so this is going to be a 00:00:43.730 --> 00:00:49.200 align:start position:0% hello again so this is going to be a longer<00:00:44.719> talk<00:00:45.399> the<00:00:47.320> intended<00:00:48.320> audience<00:00:48.500> are 00:00:49.200 --> 00:00:49.210 align:start position:0% longer talk the intended audience are 00:00:49.210 --> 00:00:53.979 align:start position:0% longer talk the intended audience are developers<00:00:50.210> who<00:00:50.409> want<00:00:51.409> to<00:00:51.500> build<00:00:52.989> scalable 00:00:53.979 --> 00:00:53.989 align:start position:0% developers who want to build scalable 00:00:53.989 --> 00:00:57.219 align:start position:0% developers who want to build scalable and<00:00:54.670> responsive<00:00:55.670> distributed<00:00:56.510> applications 00:00:57.219 --> 00:00:57.229 align:start position:0% and responsive distributed applications 00:00:57.229 --> 00:01:06.399 align:start position:0% and responsive distributed applications on<00:00:57.649> top<00:00:58.039> of<00:00:58.190> swarm<00:00:58.549> using<00:00:59.510> DNS<00:01:04.600> so<00:01:05.600> first<00:01:06.170> I 00:01:06.399 --> 00:01:06.409 align:start position:0% on top of swarm using DNS so first I 00:01:06.409 --> 00:01:08.350 align:start position:0% on top of swarm using DNS so first I would<00:01:06.530> like<00:01:06.680> to<00:01:06.920> talk<00:01:07.399> a<00:01:07.670> little<00:01:07.820> bit<00:01:08.030> about 00:01:08.350 --> 00:01:08.360 align:start position:0% would like to talk a little bit about 00:01:08.360 --> 00:01:10.960 align:start position:0% would like to talk a little bit about the<00:01:09.110> distributed<00:01:09.830> application<00:01:10.460> paradigm 00:01:10.960 --> 00:01:10.970 align:start position:0% the distributed application paradigm 00:01:10.970 --> 00:01:14.649 align:start position:0% the distributed application paradigm itself<00:01:11.450> because<00:01:12.409> in<00:01:12.710> many<00:01:12.979> ways<00:01:13.280> it's<00:01:13.700> a<00:01:14.149> very 00:01:14.649 --> 00:01:14.659 align:start position:0% itself because in many ways it's a very 00:01:14.659 --> 00:01:18.789 align:start position:0% itself because in many ways it's a very radical<00:01:15.159> departure<00:01:16.159> from<00:01:16.600> the<00:01:17.799> client-server 00:01:18.789 --> 00:01:18.799 align:start position:0% radical departure from the client-server 00:01:18.799 --> 00:01:21.789 align:start position:0% radical departure from the client-server model<00:01:19.039> that<00:01:20.000> is<00:01:20.360> prevalent<00:01:20.960> on<00:01:21.170> the<00:01:21.409> Internet 00:01:21.789 --> 00:01:21.799 align:start position:0% model that is prevalent on the Internet 00:01:21.799 --> 00:01:24.460 align:start position:0% model that is prevalent on the Internet today<00:01:21.979> and<00:01:22.460> with<00:01:23.179> which<00:01:23.420> most<00:01:23.810> web<00:01:24.289> developers 00:01:24.460 --> 00:01:24.470 align:start position:0% today and with which most web developers 00:01:24.470 --> 00:01:30.219 align:start position:0% today and with which most web developers are<00:01:25.130> intimately<00:01:25.640> familiar<00:01:28.509> then<00:01:29.509> I'm<00:01:29.810> going 00:01:30.219 --> 00:01:30.229 align:start position:0% are intimately familiar then I'm going 00:01:30.229 --> 00:01:33.850 align:start position:0% are intimately familiar then I'm going to<00:01:30.259> talk<00:01:30.709> about<00:01:31.539> the<00:01:32.539> various<00:01:32.869> challenges<00:01:33.200> of 00:01:33.850 --> 00:01:33.860 align:start position:0% to talk about the various challenges of 00:01:33.860 --> 00:01:36.990 align:start position:0% to talk about the various challenges of scaling<00:01:34.459> and<00:01:34.700> what<00:01:34.940> the<00:01:35.060> bottlenecks<00:01:35.509> are 00:01:36.990 --> 00:01:37.000 align:start position:0% scaling and what the bottlenecks are 00:01:37.000 --> 00:01:41.130 align:start position:0% scaling and what the bottlenecks are then<00:01:38.000> we<00:01:38.450> are<00:01:38.539> going<00:01:38.810> to<00:01:39.170> discuss<00:01:39.709> how 00:01:41.130 --> 00:01:41.140 align:start position:0% then we are going to discuss how 00:01:41.140 --> 00:01:43.449 align:start position:0% then we are going to discuss how reliability<00:01:42.140> issues<00:01:42.560> are<00:01:42.890> being<00:01:43.130> addressed 00:01:43.449 --> 00:01:43.459 align:start position:0% reliability issues are being addressed 00:01:43.459 --> 00:01:47.039 align:start position:0% reliability issues are being addressed in<00:01:44.149> a<00:01:44.299> dynamic<00:01:44.990> decentralized<00:01:45.859> and 00:01:47.039 --> 00:01:47.049 align:start position:0% in a dynamic decentralized and 00:01:47.049 --> 00:01:49.690 align:start position:0% in a dynamic decentralized and essentially<00:01:48.049> low<00:01:48.200> trust<00:01:48.469> environment<00:01:49.340> of<00:01:49.579> a 00:01:49.690 --> 00:01:49.700 align:start position:0% essentially low trust environment of a 00:01:49.700 --> 00:01:54.700 align:start position:0% essentially low trust environment of a distributed<00:01:50.180> application<00:01:53.140> we<00:01:54.140> are<00:01:54.170> going<00:01:54.439> to 00:01:54.700 --> 00:01:54.710 align:start position:0% distributed application we are going to 00:01:54.710 --> 00:01:57.760 align:start position:0% distributed application we are going to discuss<00:01:55.719> availability<00:01:56.719> of<00:01:56.840> content<00:01:57.320> which<00:01:57.530> is 00:01:57.760 --> 00:01:57.770 align:start position:0% discuss availability of content which is 00:01:57.770 --> 00:02:01.840 align:start position:0% discuss availability of content which is a<00:01:58.070> very<00:01:58.369> important<00:01:58.820> issue<00:01:58.939> and<00:01:59.799> finally<00:02:00.850> I'm 00:02:01.840 --> 00:02:01.850 align:start position:0% a very important issue and finally I'm 00:02:01.850 --> 00:02:05.050 align:start position:0% a very important issue and finally I'm going<00:02:01.909> to<00:02:02.299> talk<00:02:02.689> about<00:02:02.990> how<00:02:03.829> a<00:02:04.189> distributed 00:02:05.050 --> 00:02:05.060 align:start position:0% going to talk about how a distributed 00:02:05.060 --> 00:02:08.279 align:start position:0% going to talk about how a distributed application<00:02:05.320> can<00:02:06.320> be<00:02:06.850> operated<00:02:07.850> and 00:02:08.279 --> 00:02:08.289 align:start position:0% application can be operated and 00:02:08.289 --> 00:02:12.220 align:start position:0% application can be operated and developed<00:02:09.289> and<00:02:09.530> improved<00:02:10.870> over<00:02:11.870> its 00:02:12.220 --> 00:02:12.230 align:start position:0% developed and improved over its 00:02:12.230 --> 00:02:13.800 align:start position:0% developed and improved over its lifecycle 00:02:13.800 --> 00:02:13.810 align:start position:0% lifecycle 00:02:13.810 --> 00:02:16.840 align:start position:0% lifecycle so<00:02:14.810> first<00:02:15.109> the<00:02:15.590> distributed<00:02:16.280> application 00:02:16.840 --> 00:02:16.850 align:start position:0% so first the distributed application 00:02:16.850 --> 00:02:23.530 align:start position:0% so first the distributed application paradigm<00:02:21.519> distributed<00:02:22.519> applications<00:02:23.269> are 00:02:23.530 --> 00:02:23.540 align:start position:0% paradigm distributed applications are 00:02:23.540 --> 00:02:28.300 align:start position:0% paradigm distributed applications are much<00:02:24.019> more<00:02:24.380> heavy<00:02:24.769> on<00:02:25.280> the<00:02:26.290> leaf<00:02:27.290> nodes<00:02:27.650> so 00:02:28.300 --> 00:02:28.310 align:start position:0% much more heavy on the leaf nodes so 00:02:28.310 --> 00:02:31.780 align:start position:0% much more heavy on the leaf nodes so endpoint<00:02:28.910> nodes<00:02:29.650> perform<00:02:30.650> a<00:02:30.890> lot<00:02:31.220> more<00:02:31.549> work 00:02:31.780 --> 00:02:31.790 align:start position:0% endpoint nodes perform a lot more work 00:02:31.790 --> 00:02:35.770 align:start position:0% endpoint nodes perform a lot more work than<00:02:33.640> clients<00:02:34.640> in<00:02:34.850> a<00:02:35.060> client-server 00:02:35.770 --> 00:02:35.780 align:start position:0% than clients in a client-server 00:02:35.780 --> 00:02:39.309 align:start position:0% than clients in a client-server applications<00:02:36.700> very<00:02:37.700> large<00:02:38.030> part<00:02:38.420> of<00:02:38.720> the 00:02:39.309 --> 00:02:39.319 align:start position:0% applications very large part of the 00:02:39.319 --> 00:02:42.520 align:start position:0% applications very large part of the business<00:02:39.680> logic<00:02:39.920> are<00:02:40.400> actually<00:02:41.180> done<00:02:42.019> on<00:02:42.260> the 00:02:42.520 --> 00:02:42.530 align:start position:0% business logic are actually done on the 00:02:42.530 --> 00:02:49.539 align:start position:0% business logic are actually done on the client<00:02:42.889> side<00:02:44.889> so<00:02:46.750> on<00:02:47.750> the<00:02:48.290> slide<00:02:48.440> you<00:02:49.250> see 00:02:49.539 --> 00:02:49.549 align:start position:0% client side so on the slide you see 00:02:49.549 --> 00:02:53.240 align:start position:0% client side so on the slide you see several<00:02:50.530> possible 00:02:53.240 --> 00:02:53.250 align:start position:0% several possible 00:02:53.250 --> 00:02:59.270 align:start position:0% several possible nodes<00:02:54.250> which<00:02:55.090> have<00:02:55.480> their<00:02:56.320> own<00:02:58.080> requirements 00:02:59.270 --> 00:02:59.280 align:start position:0% nodes which have their own requirements 00:02:59.280 --> 00:03:06.660 align:start position:0% nodes which have their own requirements but<00:03:00.280> which<00:03:00.520> can<00:03:00.850> be<00:03:01.470> the<00:03:02.470> nodes<00:03:03.070> in<00:03:03.550> a<00:03:05.670> which 00:03:06.660 --> 00:03:06.670 align:start position:0% but which can be the nodes in a which 00:03:06.670 --> 00:03:08.520 align:start position:0% but which can be the nodes in a which can<00:03:06.700> be<00:03:07.030> the<00:03:07.210> nodes<00:03:07.450> of<00:03:07.750> a<00:03:08.050> distributed 00:03:08.520 --> 00:03:08.530 align:start position:0% can be the nodes of a distributed 00:03:08.530 --> 00:03:13.110 align:start position:0% can be the nodes of a distributed application<00:03:09.630> so<00:03:11.160> it's<00:03:12.160> not<00:03:12.400> necessarily 00:03:13.110 --> 00:03:13.120 align:start position:0% application so it's not necessarily 00:03:13.120 --> 00:03:16.290 align:start position:0% application so it's not necessarily web-based<00:03:13.660> there<00:03:14.110> can<00:03:14.380> be<00:03:14.410> in<00:03:14.650> native<00:03:15.300> mobile 00:03:16.290 --> 00:03:16.300 align:start position:0% web-based there can be in native mobile 00:03:16.300 --> 00:03:19.500 align:start position:0% web-based there can be in native mobile applications<00:03:17.760> Internet<00:03:18.760> of<00:03:18.790> Things<00:03:18.910> devices 00:03:19.500 --> 00:03:19.510 align:start position:0% applications Internet of Things devices 00:03:19.510 --> 00:03:28.230 align:start position:0% applications Internet of Things devices and<00:03:22.530> also<00:03:24.180> we<00:03:25.180> need<00:03:25.450> to<00:03:26.370> keep<00:03:27.370> in<00:03:27.550> mind<00:03:27.760> that 00:03:28.230 --> 00:03:28.240 align:start position:0% and also we need to keep in mind that 00:03:28.240 --> 00:03:31.020 align:start position:0% and also we need to keep in mind that key<00:03:28.660> and<00:03:28.690> identity<00:03:29.440> management<00:03:29.770> is<00:03:30.280> sometimes 00:03:31.020 --> 00:03:31.030 align:start position:0% key and identity management is sometimes 00:03:31.030 --> 00:03:34.680 align:start position:0% key and identity management is sometimes outsourced<00:03:31.930> to<00:03:32.230> this<00:03:32.350> hardware<00:03:32.890> keys<00:03:33.100> and<00:03:33.690> we 00:03:34.680 --> 00:03:34.690 align:start position:0% outsourced to this hardware keys and we 00:03:34.690 --> 00:03:39.390 align:start position:0% outsourced to this hardware keys and we need<00:03:34.870> to<00:03:35.110> take<00:03:35.830> that<00:03:35.980> into<00:03:36.040> account<00:03:38.400> the 00:03:39.390 --> 00:03:39.400 align:start position:0% need to take that into account the 00:03:39.400 --> 00:03:43.200 align:start position:0% need to take that into account the backend<00:03:39.880> is<00:03:40.830> typically<00:03:41.830> generic<00:03:42.400> and<00:03:42.610> I<00:03:43.000> will 00:03:43.200 --> 00:03:43.210 align:start position:0% backend is typically generic and I will 00:03:43.210 --> 00:03:46.050 align:start position:0% backend is typically generic and I will talk<00:03:43.450> a<00:03:43.720> little<00:03:43.990> bit<00:03:44.200> later<00:03:44.230> about<00:03:45.130> the<00:03:45.520> deeper 00:03:46.050 --> 00:03:46.060 align:start position:0% talk a little bit later about the deeper 00:03:46.060 --> 00:03:48.660 align:start position:0% talk a little bit later about the deeper reasons<00:03:46.420> behind<00:03:46.630> that<00:03:46.930> but<00:03:47.890> the<00:03:48.250> kind<00:03:48.520> of 00:03:48.660 --> 00:03:48.670 align:start position:0% reasons behind that but the kind of 00:03:48.670 --> 00:03:54.630 align:start position:0% reasons behind that but the kind of backends<00:03:49.300> on<00:03:49.540> which<00:03:49.990> we<00:03:50.230> rely<00:03:50.410> are<00:03:51.270> the<00:03:53.640> ETH 00:03:54.630 --> 00:03:54.640 align:start position:0% backends on which we rely are the ETH 00:03:54.640 --> 00:03:58.260 align:start position:0% backends on which we rely are the ETH and<00:03:55.170> less<00:03:56.170> protocols<00:03:57.010> for<00:03:57.310> consensus<00:03:57.970> so<00:03:58.150> it's 00:03:58.260 --> 00:03:58.270 align:start position:0% and less protocols for consensus so it's 00:03:58.270 --> 00:04:01.110 align:start position:0% and less protocols for consensus so it's either<00:03:58.480> a<00:03:58.630> full<00:03:58.960> node<00:03:59.230> or<00:03:59.530> a<00:04:00.280> light<00:04:00.580> node<00:04:00.850> on 00:04:01.110 --> 00:04:01.120 align:start position:0% either a full node or a light node on 00:04:01.120 --> 00:04:04.140 align:start position:0% either a full node or a light node on the<00:04:01.270> etherium<00:04:01.690> network<00:04:02.100> so<00:04:03.100> each<00:04:03.370> node<00:04:03.820> needs 00:04:04.140 --> 00:04:04.150 align:start position:0% the etherium network so each node needs 00:04:04.150 --> 00:04:09.000 align:start position:0% the etherium network so each node needs to<00:04:04.420> be<00:04:04.540> an<00:04:04.750> ethereal<00:04:05.200> node<00:04:06.450> we<00:04:07.450> use<00:04:07.660> swarm<00:04:08.170> for 00:04:09.000 --> 00:04:09.010 align:start position:0% to be an ethereal node we use swarm for 00:04:09.010 --> 00:04:11.310 align:start position:0% to be an ethereal node we use swarm for permanently<00:04:09.820> storing<00:04:10.300> large<00:04:10.780> amounts<00:04:10.870> of 00:04:11.310 --> 00:04:11.320 align:start position:0% permanently storing large amounts of 00:04:11.320 --> 00:04:15.120 align:start position:0% permanently storing large amounts of data<00:04:11.560> and<00:04:12.210> accessing<00:04:13.210> data<00:04:13.420> and<00:04:14.100> we<00:04:15.100> use 00:04:15.120 --> 00:04:15.130 align:start position:0% data and accessing data and we use 00:04:15.130 --> 00:04:20.580 align:start position:0% data and accessing data and we use either<00:04:16.350> PSS<00:04:17.350> or<00:04:17.710> Whisperer<00:04:18.340> for<00:04:19.290> node<00:04:20.290> 2<00:04:20.470> node 00:04:20.580 --> 00:04:20.590 align:start position:0% either PSS or Whisperer for node 2 node 00:04:20.590 --> 00:04:23.460 align:start position:0% either PSS or Whisperer for node 2 node communication<00:04:21.430> so<00:04:22.240> all<00:04:22.480> of<00:04:22.660> these<00:04:22.840> backends 00:04:23.460 --> 00:04:23.470 align:start position:0% communication so all of these backends 00:04:23.470 --> 00:04:25.530 align:start position:0% communication so all of these backends are<00:04:23.590> entirely<00:04:24.160> general-purpose<00:04:24.910> they're<00:04:25.330> not 00:04:25.530 --> 00:04:25.540 align:start position:0% are entirely general-purpose they're not 00:04:25.540 --> 00:04:32.520 align:start position:0% are entirely general-purpose they're not application<00:04:26.170> specific<00:04:27.480> and<00:04:31.050> even<00:04:32.050> though<00:04:32.230> I 00:04:32.520 --> 00:04:32.530 align:start position:0% application specific and even though I 00:04:32.530 --> 00:04:36.360 align:start position:0% application specific and even though I told<00:04:32.830> you<00:04:33.220> that<00:04:34.170> there<00:04:35.170> are<00:04:35.200> no<00:04:35.380> clients<00:04:36.160> and 00:04:36.360 --> 00:04:36.370 align:start position:0% told you that there are no clients and 00:04:36.370 --> 00:04:40.470 align:start position:0% told you that there are no clients and servers<00:04:36.640> in<00:04:37.210> a<00:04:37.510> distributed<00:04:38.190> application<00:04:39.480> you 00:04:40.470 --> 00:04:40.480 align:start position:0% servers in a distributed application you 00:04:40.480 --> 00:04:42.660 align:start position:0% servers in a distributed application you should<00:04:40.720> still<00:04:40.990> keep<00:04:41.200> in<00:04:41.410> mind<00:04:41.680> that<00:04:42.430> the 00:04:42.660 --> 00:04:42.670 align:start position:0% should still keep in mind that the 00:04:42.670 --> 00:04:45.570 align:start position:0% should still keep in mind that the contribution<00:04:43.570> of<00:04:43.720> resources<00:04:44.710> is<00:04:44.920> by<00:04:45.310> no<00:04:45.370> means 00:04:45.570 --> 00:04:45.580 align:start position:0% contribution of resources is by no means 00:04:45.580 --> 00:04:49.050 align:start position:0% contribution of resources is by no means equal<00:04:46.360> so<00:04:47.320> peer-to-peer<00:04:47.710> applications<00:04:48.190> are 00:04:49.050 --> 00:04:49.060 align:start position:0% equal so peer-to-peer applications are 00:04:49.060 --> 00:04:54.060 align:start position:0% equal so peer-to-peer applications are not<00:04:49.420> necessarily<00:04:51.720> not<00:04:52.720> necessarily<00:04:53.070> balanced 00:04:54.060 --> 00:04:54.070 align:start position:0% not necessarily not necessarily balanced 00:04:54.070 --> 00:04:56.460 align:start position:0% not necessarily not necessarily balanced in<00:04:54.460> terms<00:04:54.520> of<00:04:55.060> the<00:04:55.240> use<00:04:55.450> and<00:04:55.750> contribution<00:04:56.380> of 00:04:56.460 --> 00:04:56.470 align:start position:0% in terms of the use and contribution of 00:04:56.470 --> 00:04:58.760 align:start position:0% in terms of the use and contribution of resources<00:04:57.130> so<00:04:57.610> even<00:04:57.940> if<00:04:58.090> you<00:04:58.210> think<00:04:58.510> about 00:04:58.760 --> 00:04:58.770 align:start position:0% resources so even if you think about 00:04:58.770 --> 00:05:02.010 align:start position:0% resources so even if you think about BitTorrent<00:04:59.770> there<00:05:00.580> are<00:05:00.790> Cedars<00:05:01.330> and<00:05:01.360> leechers 00:05:02.010 --> 00:05:02.020 align:start position:0% BitTorrent there are Cedars and leechers 00:05:02.020 --> 00:05:05.640 align:start position:0% BitTorrent there are Cedars and leechers and<00:05:02.400> in<00:05:03.400> the<00:05:03.550> general<00:05:04.030> terminology 00:05:05.640 --> 00:05:05.650 align:start position:0% and in the general terminology 00:05:05.650 --> 00:05:08.990 align:start position:0% and in the general terminology we<00:05:06.190> distinguish<00:05:06.940> between<00:05:07.110> consumers<00:05:08.110> and 00:05:08.990 --> 00:05:09.000 align:start position:0% we distinguish between consumers and 00:05:09.000 --> 00:05:12.810 align:start position:0% we distinguish between consumers and suppliers<00:05:10.000> of<00:05:10.690> resources<00:05:11.440> and<00:05:11.680> of<00:05:12.100> course 00:05:12.810 --> 00:05:12.820 align:start position:0% suppliers of resources and of course 00:05:12.820 --> 00:05:16.020 align:start position:0% suppliers of resources and of course each<00:05:13.210> participant<00:05:14.110> can<00:05:14.530> choose<00:05:15.250> and<00:05:15.610> even 00:05:16.020 --> 00:05:16.030 align:start position:0% each participant can choose and even 00:05:16.030 --> 00:05:18.689 align:start position:0% each participant can choose and even change<00:05:16.330> over<00:05:16.750> time<00:05:17.020> to<00:05:17.740> what<00:05:17.919> extent<00:05:18.430> they 00:05:18.689 --> 00:05:18.699 align:start position:0% change over time to what extent they 00:05:18.699 --> 00:05:21.210 align:start position:0% change over time to what extent they supply<00:05:19.150> and<00:05:19.419> consume<00:05:19.810> resources<00:05:20.220> but 00:05:21.210 --> 00:05:21.220 align:start position:0% supply and consume resources but 00:05:21.220 --> 00:05:26.550 align:start position:0% supply and consume resources but typically<00:05:21.820> consumers<00:05:22.479> are<00:05:25.560> are 00:05:26.550 --> 00:05:26.560 align:start position:0% typically consumers are are 00:05:26.560 --> 00:05:31.590 align:start position:0% typically consumers are are characterized<00:05:27.520> by<00:05:29.190> high<00:05:30.190> churn<00:05:30.580> so<00:05:31.419> they 00:05:31.590 --> 00:05:31.600 align:start position:0% characterized by high churn so they 00:05:31.600 --> 00:05:34.370 align:start position:0% characterized by high churn so they leave<00:05:31.840> the<00:05:32.320> network<00:05:32.500> and<00:05:33.040> join<00:05:33.490> the<00:05:33.699> network 00:05:34.370 --> 00:05:34.380 align:start position:0% leave the network and join the network 00:05:34.380 --> 00:05:36.810 align:start position:0% leave the network and join the network frequently<00:05:35.380> you<00:05:35.710> cannot<00:05:36.070> rely<00:05:36.430> on<00:05:36.460> them 00:05:36.810 --> 00:05:36.820 align:start position:0% frequently you cannot rely on them 00:05:36.820 --> 00:05:39.570 align:start position:0% frequently you cannot rely on them staying<00:05:37.120> on<00:05:37.360> the<00:05:37.479> network<00:05:37.840> for<00:05:38.560> a<00:05:38.830> prolonged 00:05:39.570 --> 00:05:39.580 align:start position:0% staying on the network for a prolonged 00:05:39.580 --> 00:05:45.779 align:start position:0% staying on the network for a prolonged period<00:05:39.820> of<00:05:40.240> time<00:05:43.740> typically<00:05:44.740> they<00:05:45.310> spend 00:05:45.779 --> 00:05:45.789 align:start position:0% period of time typically they spend 00:05:45.789 --> 00:05:48.480 align:start position:0% period of time typically they spend accounting<00:05:46.600> units<00:05:46.960> whether<00:05:47.500> they<00:05:47.889> are<00:05:48.039> ethers 00:05:48.480 --> 00:05:48.490 align:start position:0% accounting units whether they are ethers 00:05:48.490 --> 00:05:53.240 align:start position:0% accounting units whether they are ethers or<00:05:48.820> special-purpose<00:05:49.720> tokens<00:05:50.350> and<00:05:51.270> they<00:05:52.270> have 00:05:53.240 --> 00:05:53.250 align:start position:0% or special-purpose tokens and they have 00:05:53.250 --> 00:05:56.850 align:start position:0% or special-purpose tokens and they have resource<00:05:54.250> limits<00:05:54.699> which<00:05:55.300> in<00:05:55.660> some<00:05:56.139> cases<00:05:56.410> can 00:05:56.850 --> 00:05:56.860 align:start position:0% resource limits which in some cases can 00:05:56.860 --> 00:06:01.560 align:start position:0% resource limits which in some cases can be<00:05:56.919> quite<00:05:57.280> severe<00:05:58.620> suppliers<00:05:59.620> are<00:06:00.570> typically 00:06:01.560 --> 00:06:01.570 align:start position:0% be quite severe suppliers are typically 00:06:01.570 --> 00:06:04.620 align:start position:0% be quite severe suppliers are typically there<00:06:01.930> in<00:06:02.289> order<00:06:02.800> to<00:06:03.190> earn<00:06:03.460> accounting<00:06:04.270> units 00:06:04.620 --> 00:06:04.630 align:start position:0% there in order to earn accounting units 00:06:04.630 --> 00:06:07.409 align:start position:0% there in order to earn accounting units so<00:06:05.260> they<00:06:05.530> are<00:06:05.770> providing<00:06:06.639> a<00:06:06.760> service<00:06:06.789> and 00:06:07.409 --> 00:06:07.419 align:start position:0% so they are providing a service and 00:06:07.419 --> 00:06:11.310 align:start position:0% so they are providing a service and expect<00:06:07.960> to<00:06:08.199> be<00:06:08.289> paid<00:06:08.590> for<00:06:08.770> it<00:06:09.479> they<00:06:10.479> have<00:06:11.020> a 00:06:11.310 --> 00:06:11.320 align:start position:0% expect to be paid for it they have a 00:06:11.320 --> 00:06:13.529 align:start position:0% expect to be paid for it they have a launcher<00:06:11.919> so<00:06:12.700> they<00:06:12.849> can<00:06:13.030> still<00:06:13.300> leave<00:06:13.510> the 00:06:13.529 --> 00:06:13.539 align:start position:0% launcher so they can still leave the 00:06:13.539 --> 00:06:15.480 align:start position:0% launcher so they can still leave the network<00:06:13.840> and<00:06:14.260> join<00:06:14.440> the<00:06:14.650> network<00:06:14.830> but<00:06:15.340> they 00:06:15.480 --> 00:06:15.490 align:start position:0% network and join the network but they 00:06:15.490 --> 00:06:18.750 align:start position:0% network and join the network but they don't<00:06:15.729> do<00:06:15.910> that<00:06:16.060> frequently<00:06:17.220> they<00:06:18.220> have<00:06:18.460> high 00:06:18.750 --> 00:06:18.760 align:start position:0% don't do that frequently they have high 00:06:18.760 --> 00:06:21.330 align:start position:0% don't do that frequently they have high availability<00:06:19.030> and<00:06:19.810> they<00:06:20.440> have<00:06:20.710> adequate 00:06:21.330 --> 00:06:21.340 align:start position:0% availability and they have adequate 00:06:21.340 --> 00:06:26.580 align:start position:0% availability and they have adequate resources<00:06:21.630> for<00:06:22.630> providing<00:06:23.530> the<00:06:24.660> the<00:06:25.660> services 00:06:26.580 --> 00:06:26.590 align:start position:0% resources for providing the the services 00:06:26.590 --> 00:06:29.040 align:start position:0% resources for providing the the services that<00:06:26.950> need<00:06:27.160> to<00:06:27.310> be<00:06:27.430> provided<00:06:27.970> for<00:06:28.240> this 00:06:29.040 --> 00:06:29.050 align:start position:0% that need to be provided for this 00:06:29.050 --> 00:06:34.680 align:start position:0% that need to be provided for this distributed<00:06:29.710> application<00:06:32.789> so<00:06:33.789> in<00:06:34.210> the<00:06:34.419> next 00:06:34.680 --> 00:06:34.690 align:start position:0% distributed application so in the next 00:06:34.690 --> 00:06:37.980 align:start position:0% distributed application so in the next part<00:06:34.930> I'm<00:06:35.889> going<00:06:36.310> to<00:06:36.490> talk<00:06:36.729> about<00:06:37.000> the 00:06:37.980 --> 00:06:37.990 align:start position:0% part I'm going to talk about the 00:06:37.990 --> 00:06:41.760 align:start position:0% part I'm going to talk about the challenges<00:06:38.830> of<00:06:39.750> scaling<00:06:40.770> distributed 00:06:41.760 --> 00:06:41.770 align:start position:0% challenges of scaling distributed 00:06:41.770 --> 00:06:44.760 align:start position:0% challenges of scaling distributed applications<00:06:42.370> and<00:06:43.470> identify<00:06:44.470> bottlenecks 00:06:44.760 --> 00:06:44.770 align:start position:0% applications and identify bottlenecks 00:06:44.770 --> 00:06:51.469 align:start position:0% applications and identify bottlenecks and<00:06:47.039> proposed<00:06:48.039> ways<00:06:48.639> of<00:06:48.960> dealing<00:06:49.960> with<00:06:50.139> them 00:06:51.469 --> 00:06:51.479 align:start position:0% and proposed ways of dealing with them 00:06:51.479 --> 00:06:56.279 align:start position:0% and proposed ways of dealing with them so<00:06:52.479> the<00:06:53.550> most<00:06:54.550> important<00:06:55.180> bottleneck<00:06:55.690> is<00:06:56.050> the 00:06:56.279 --> 00:06:56.289 align:start position:0% so the most important bottleneck is the 00:06:56.289 --> 00:06:59.990 align:start position:0% so the most important bottleneck is the blockchain<00:06:56.530> of<00:06:57.160> course<00:06:57.849> we<00:06:58.300> have<00:06:58.510> heard 00:06:59.990 --> 00:07:00.000 align:start position:0% blockchain of course we have heard 00:07:00.000 --> 00:07:04.379 align:start position:0% blockchain of course we have heard wonderful<00:07:01.000> talks<00:07:01.270> about<00:07:02.110> how<00:07:03.389> scaling 00:07:04.379 --> 00:07:04.389 align:start position:0% wonderful talks about how scaling 00:07:04.389 --> 00:07:06.270 align:start position:0% wonderful talks about how scaling problems<00:07:04.900> on<00:07:05.110> the<00:07:05.229> blockchain<00:07:05.440> are<00:07:05.860> going<00:07:06.099> to 00:07:06.270 --> 00:07:06.280 align:start position:0% problems on the blockchain are going to 00:07:06.280 --> 00:07:10.800 align:start position:0% problems on the blockchain are going to be<00:07:06.400> solved<00:07:06.729> over<00:07:06.910> time<00:07:07.210> and<00:07:08.610> in<00:07:09.610> a<00:07:09.880> ideal<00:07:10.479> world 00:07:10.800 --> 00:07:10.810 align:start position:0% be solved over time and in a ideal world 00:07:10.810 --> 00:07:15.000 align:start position:0% be solved over time and in a ideal world in<00:07:11.169> which<00:07:11.530> we<00:07:11.800> had<00:07:12.039> a<00:07:13.500> essentially<00:07:14.500> infinitely 00:07:15.000 --> 00:07:15.010 align:start position:0% in which we had a essentially infinitely 00:07:15.010 --> 00:07:17.000 align:start position:0% in which we had a essentially infinitely scalable<00:07:15.280> blockchain 00:07:17.000 --> 00:07:17.010 align:start position:0% scalable blockchain 00:07:17.010 --> 00:07:19.720 align:start position:0% scalable blockchain everything<00:07:17.580> I'm<00:07:17.730> talking<00:07:17.940> about<00:07:18.300> would<00:07:19.230> be 00:07:19.720 --> 00:07:19.730 align:start position:0% everything I'm talking about would be 00:07:19.730 --> 00:07:22.190 align:start position:0% everything I'm talking about would be unnecessary<00:07:20.730> because<00:07:21.150> we<00:07:21.300> could<00:07:21.480> host<00:07:21.750> the 00:07:22.190 --> 00:07:22.200 align:start position:0% unnecessary because we could host the 00:07:22.200 --> 00:07:24.260 align:start position:0% unnecessary because we could host the entire<00:07:22.530> distributed<00:07:23.250> application<00:07:23.940> on<00:07:24.150> the 00:07:24.260 --> 00:07:24.270 align:start position:0% entire distributed application on the 00:07:24.270 --> 00:07:25.790 align:start position:0% entire distributed application on the blockchain<00:07:24.510> keep<00:07:24.990> all<00:07:25.170> the<00:07:25.350> data<00:07:25.530> on<00:07:25.770> the 00:07:25.790 --> 00:07:25.800 align:start position:0% blockchain keep all the data on the 00:07:25.800 --> 00:07:28.130 align:start position:0% blockchain keep all the data on the blockchain<00:07:26.130> and<00:07:26.640> submit<00:07:27.420> every<00:07:27.750> transaction 00:07:28.130 --> 00:07:28.140 align:start position:0% blockchain and submit every transaction 00:07:28.140 --> 00:07:30.650 align:start position:0% blockchain and submit every transaction that<00:07:28.440> the<00:07:28.860> application<00:07:29.490> ever<00:07:29.700> does<00:07:30.000> directly 00:07:30.650 --> 00:07:30.660 align:start position:0% that the application ever does directly 00:07:30.660 --> 00:07:31.540 align:start position:0% that the application ever does directly to<00:07:30.780> the<00:07:30.900> blockchain 00:07:31.540 --> 00:07:31.550 align:start position:0% to the blockchain 00:07:31.550 --> 00:07:34.100 align:start position:0% to the blockchain but<00:07:32.550> there<00:07:32.730> are<00:07:32.790> two<00:07:33.000> reasons<00:07:33.180> why<00:07:33.510> I<00:07:33.660> feel 00:07:34.100 --> 00:07:34.110 align:start position:0% but there are two reasons why I feel 00:07:34.110 --> 00:07:36.860 align:start position:0% but there are two reasons why I feel that<00:07:34.800> the<00:07:35.760> techniques<00:07:36.150> that<00:07:36.390> I'm<00:07:36.540> going<00:07:36.840> to 00:07:36.860 --> 00:07:36.870 align:start position:0% that the techniques that I'm going to 00:07:36.870 --> 00:07:39.860 align:start position:0% that the techniques that I'm going to introduce<00:07:37.290> are<00:07:37.710> still<00:07:37.950> relevant<00:07:38.480> one<00:07:39.480> of<00:07:39.630> them 00:07:39.860 --> 00:07:39.870 align:start position:0% introduce are still relevant one of them 00:07:39.870 --> 00:07:43.730 align:start position:0% introduce are still relevant one of them is<00:07:40.110> that<00:07:40.760> the<00:07:41.760> scaling<00:07:42.660> of<00:07:42.870> the<00:07:43.110> blockchain<00:07:43.350> is 00:07:43.730 --> 00:07:43.740 align:start position:0% is that the scaling of the blockchain is 00:07:43.740 --> 00:07:47.080 align:start position:0% is that the scaling of the blockchain is a<00:07:43.890> slow<00:07:44.130> process<00:07:44.670> and<00:07:45.440> it's<00:07:46.440> a<00:07:46.680> much<00:07:46.890> harder 00:07:47.080 --> 00:07:47.090 align:start position:0% a slow process and it's a much harder 00:07:47.090 --> 00:07:52.720 align:start position:0% a slow process and it's a much harder much<00:07:48.830> harder<00:07:49.830> challenge<00:07:50.760> than<00:07:51.420> scaling<00:07:52.140> the 00:07:52.720 --> 00:07:52.730 align:start position:0% much harder challenge than scaling the 00:07:52.730 --> 00:07:54.950 align:start position:0% much harder challenge than scaling the particular<00:07:53.730> dab<00:07:54.030> bottlenecks<00:07:54.600> that<00:07:54.840> I'm 00:07:54.950 --> 00:07:54.960 align:start position:0% particular dab bottlenecks that I'm 00:07:54.960 --> 00:07:58.130 align:start position:0% particular dab bottlenecks that I'm going<00:07:55.200> to<00:07:55.350> talk<00:07:55.530> about<00:07:55.560> it<00:07:56.120> so<00:07:57.120> people<00:07:57.510> want<00:07:57.960> to 00:07:58.130 --> 00:07:58.140 align:start position:0% going to talk about it so people want to 00:07:58.140 --> 00:08:00.290 align:start position:0% going to talk about it so people want to create<00:07:58.380> scalable<00:07:58.950> applications<00:07:59.640> even<00:08:00.120> before 00:08:00.290 --> 00:08:00.300 align:start position:0% create scalable applications even before 00:08:00.300 --> 00:08:02.780 align:start position:0% create scalable applications even before all<00:08:01.050> the<00:08:01.380> problems<00:08:01.830> of<00:08:01.920> blockchain<00:08:02.370> scaling 00:08:02.780 --> 00:08:02.790 align:start position:0% all the problems of blockchain scaling 00:08:02.790 --> 00:08:05.440 align:start position:0% all the problems of blockchain scaling are<00:08:03.000> going<00:08:03.270> to<00:08:03.420> be<00:08:03.540> solved<00:08:03.930> and<00:08:04.250> secondly 00:08:05.440 --> 00:08:05.450 align:start position:0% are going to be solved and secondly 00:08:05.450 --> 00:08:08.120 align:start position:0% are going to be solved and secondly because<00:08:06.450> the<00:08:06.750> techniques<00:08:07.170> that<00:08:07.320> I'm<00:08:07.650> going<00:08:07.980> to 00:08:08.120 --> 00:08:08.130 align:start position:0% because the techniques that I'm going to 00:08:08.130 --> 00:08:12.070 align:start position:0% because the techniques that I'm going to talk<00:08:08.550> about<00:08:08.760> are<00:08:09.360> actually<00:08:10.290> useful<00:08:10.790> for 00:08:12.070 --> 00:08:12.080 align:start position:0% talk about are actually useful for 00:08:12.080 --> 00:08:15.050 align:start position:0% talk about are actually useful for scaling<00:08:13.080> the<00:08:13.230> blockchain<00:08:13.470> so<00:08:14.280> for<00:08:14.490> example 00:08:15.050 --> 00:08:15.060 align:start position:0% scaling the blockchain so for example 00:08:15.060 --> 00:08:18.110 align:start position:0% scaling the blockchain so for example the<00:08:15.240> initial<00:08:15.630> motivation<00:08:16.290> behind<00:08:16.530> swarm<00:08:17.190> was 00:08:18.110 --> 00:08:18.120 align:start position:0% the initial motivation behind swarm was 00:08:18.120 --> 00:08:21.680 align:start position:0% the initial motivation behind swarm was to<00:08:18.420> store<00:08:18.840> his<00:08:19.640> historical<00:08:20.640> record<00:08:21.120> of<00:08:21.270> the 00:08:21.680 --> 00:08:21.690 align:start position:0% to store his historical record of the 00:08:21.690 --> 00:08:24.860 align:start position:0% to store his historical record of the etherium<00:08:22.080> blockchain<00:08:22.650> so<00:08:23.510> archive<00:08:24.510> nodes 00:08:24.860 --> 00:08:24.870 align:start position:0% etherium blockchain so archive nodes 00:08:24.870 --> 00:08:27.290 align:start position:0% etherium blockchain so archive nodes which<00:08:25.380> store<00:08:25.830> the<00:08:26.190> entire<00:08:26.400> blockchain 00:08:27.290 --> 00:08:27.300 align:start position:0% which store the entire blockchain 00:08:27.300 --> 00:08:29.690 align:start position:0% which store the entire blockchain history<00:08:27.780> as<00:08:28.200> far<00:08:28.260> as<00:08:28.650> I<00:08:28.770> know<00:08:28.830> there<00:08:29.310> are<00:08:29.460> very 00:08:29.690 --> 00:08:29.700 align:start position:0% history as far as I know there are very 00:08:29.700 --> 00:08:33.770 align:start position:0% history as far as I know there are very few<00:08:29.910> of<00:08:29.970> them<00:08:30.240> maybe<00:08:30.510> none<00:08:30.900> and<00:08:32.090> but<00:08:33.090> we<00:08:33.479> still 00:08:33.770 --> 00:08:33.780 align:start position:0% few of them maybe none and but we still 00:08:33.780 --> 00:08:35.990 align:start position:0% few of them maybe none and but we still want<00:08:34.080> to<00:08:34.380> keep<00:08:34.740> the<00:08:35.070> entire<00:08:35.370> history<00:08:35.669> of 00:08:35.990 --> 00:08:36.000 align:start position:0% want to keep the entire history of 00:08:36.000 --> 00:08:40.610 align:start position:0% want to keep the entire history of etherium<00:08:36.900> available<00:08:37.740> and<00:08:38.660> swarm<00:08:39.660> is<00:08:39.960> the 00:08:40.610 --> 00:08:40.620 align:start position:0% etherium available and swarm is the 00:08:40.620 --> 00:08:45.830 align:start position:0% etherium available and swarm is the perfect<00:08:41.040> vehicle<00:08:41.160> for<00:08:41.640> that<00:08:43.880> so<00:08:44.880> all<00:08:45.570> the 00:08:45.830 --> 00:08:45.840 align:start position:0% perfect vehicle for that so all the 00:08:45.840 --> 00:08:47.470 align:start position:0% perfect vehicle for that so all the techniques<00:08:46.230> that<00:08:46.350> I'm<00:08:46.620> going<00:08:46.860> to<00:08:47.040> talk<00:08:47.250> about 00:08:47.470 --> 00:08:47.480 align:start position:0% techniques that I'm going to talk about 00:08:47.480 --> 00:08:51.710 align:start position:0% techniques that I'm going to talk about can<00:08:48.480> be<00:08:48.540> used<00:08:49.200> for<00:08:50.010> scaling<00:08:50.640> various<00:08:51.060> aspects 00:08:51.710 --> 00:08:51.720 align:start position:0% can be used for scaling various aspects 00:08:51.720 --> 00:08:57.410 align:start position:0% can be used for scaling various aspects of<00:08:51.870> the<00:08:52.170> blockchain<00:08:55.250> so<00:08:56.250> on<00:08:56.550> the<00:08:56.880> slide<00:08:57.030> you 00:08:57.410 --> 00:08:57.420 align:start position:0% of the blockchain so on the slide you 00:08:57.420 --> 00:09:00.550 align:start position:0% of the blockchain so on the slide you see<00:08:57.690> in<00:08:58.500> what<00:08:58.980> ways<00:08:59.310> the<00:09:00.000> blockchain 00:09:00.550 --> 00:09:00.560 align:start position:0% see in what ways the blockchain 00:09:00.560 --> 00:09:05.840 align:start position:0% see in what ways the blockchain constitutes<00:09:01.560> a<00:09:01.800> bottleneck<00:09:03.380> so<00:09:04.380> because<00:09:05.370> all 00:09:05.840 --> 00:09:05.850 align:start position:0% constitutes a bottleneck so because all 00:09:05.850 --> 00:09:08.090 align:start position:0% constitutes a bottleneck so because all information<00:09:06.720> needs<00:09:06.930> to<00:09:07.050> be<00:09:07.140> replicated<00:09:07.440> over 00:09:08.090 --> 00:09:08.100 align:start position:0% information needs to be replicated over 00:09:08.100 --> 00:09:11.180 align:start position:0% information needs to be replicated over every<00:09:08.610> node<00:09:08.910> that<00:09:09.690> means<00:09:09.750> that<00:09:10.680> storing 00:09:11.180 --> 00:09:11.190 align:start position:0% every node that means that storing 00:09:11.190 --> 00:09:13.070 align:start position:0% every node that means that storing information<00:09:11.430> on<00:09:12.120> the<00:09:12.270> blockchain<00:09:12.480> is<00:09:12.720> very 00:09:13.070 --> 00:09:13.080 align:start position:0% information on the blockchain is very 00:09:13.080 --> 00:09:14.780 align:start position:0% information on the blockchain is very expensive<00:09:13.650> so<00:09:13.830> you<00:09:13.860> don't<00:09:14.160> want<00:09:14.430> to<00:09:14.580> burden 00:09:14.780 --> 00:09:14.790 align:start position:0% expensive so you don't want to burden 00:09:14.790 --> 00:09:19.720 align:start position:0% expensive so you don't want to burden the<00:09:15.120> blockchain<00:09:15.330> with<00:09:15.720> too<00:09:15.870> much<00:09:16.020> information 00:09:19.720 --> 00:09:19.730 align:start position:0% 00:09:19.730 --> 00:09:28.639 align:start position:0% also<00:09:23.990> the<00:09:24.990> blockchain<00:09:25.290> can<00:09:26.070> only<00:09:26.340> be<00:09:26.640> updated 00:09:28.639 --> 00:09:28.649 align:start position:0% also the blockchain can only be updated 00:09:28.649 --> 00:09:30.710 align:start position:0% also the blockchain can only be updated at<00:09:28.680> the<00:09:28.860> block<00:09:29.040> time<00:09:29.279> speed<00:09:29.639> which<00:09:30.059> is<00:09:30.089> on 00:09:30.710 --> 00:09:30.720 align:start position:0% at the block time speed which is on 00:09:30.720 --> 00:09:33.679 align:start position:0% at the block time speed which is on average<00:09:31.139> a<00:09:31.439> dozen<00:09:31.800> seconds<00:09:32.249> or<00:09:32.399> so<00:09:32.639> which<00:09:33.420> is 00:09:33.679 --> 00:09:33.689 align:start position:0% average a dozen seconds or so which is 00:09:33.689 --> 00:09:39.769 align:start position:0% average a dozen seconds or so which is not<00:09:33.930> exactly<00:09:35.569> responsive<00:09:36.680> and<00:09:38.240> you<00:09:39.240> have<00:09:39.569> to 00:09:39.769 --> 00:09:39.779 align:start position:0% not exactly responsive and you have to 00:09:39.779 --> 00:09:42.410 align:start position:0% not exactly responsive and you have to pay<00:09:40.050> for<00:09:40.649> submitting<00:09:41.459> transactions<00:09:42.149> to<00:09:42.389> the 00:09:42.410 --> 00:09:42.420 align:start position:0% pay for submitting transactions to the 00:09:42.420 --> 00:09:44.600 align:start position:0% pay for submitting transactions to the blockchain<00:09:42.749> so<00:09:43.319> if<00:09:43.470> you<00:09:43.680> do<00:09:43.860> updates<00:09:44.369> very 00:09:44.600 --> 00:09:44.610 align:start position:0% blockchain so if you do updates very 00:09:44.610 --> 00:09:46.519 align:start position:0% blockchain so if you do updates very frequently<00:09:45.240> or<00:09:45.569> your<00:09:45.749> updates<00:09:46.139> are<00:09:46.319> very 00:09:46.519 --> 00:09:46.529 align:start position:0% frequently or your updates are very 00:09:46.529 --> 00:09:49.460 align:start position:0% frequently or your updates are very large<00:09:46.860> then<00:09:47.699> it<00:09:48.059> again<00:09:48.629> becomes<00:09:48.990> overly 00:09:49.460 --> 00:09:49.470 align:start position:0% large then it again becomes overly 00:09:49.470 --> 00:09:52.280 align:start position:0% large then it again becomes overly expensive<00:09:50.059> the<00:09:51.059> other<00:09:51.240> bottleneck<00:09:51.899> that<00:09:51.929> we 00:09:52.280 --> 00:09:52.290 align:start position:0% expensive the other bottleneck that we 00:09:52.290 --> 00:09:55.040 align:start position:0% expensive the other bottleneck that we are<00:09:52.350> going<00:09:52.589> to<00:09:52.860> encounter<00:09:53.699> are<00:09:54.209> individual 00:09:55.040 --> 00:09:55.050 align:start position:0% are going to encounter are individual 00:09:55.050 --> 00:09:58.179 align:start position:0% are going to encounter are individual nodes<00:09:55.290> so<00:09:56.129> basically<00:09:56.730> you<00:09:57.029> don't<00:09:57.269> want 00:09:58.179 --> 00:09:58.189 align:start position:0% nodes so basically you don't want 00:09:58.189 --> 00:10:02.359 align:start position:0% nodes so basically you don't want individual<00:09:59.189> nodes<00:09:59.490> to<00:10:00.269> perform<00:10:00.839> all<00:10:01.800> the<00:10:02.160> work 00:10:02.359 --> 00:10:02.369 align:start position:0% individual nodes to perform all the work 00:10:02.369 --> 00:10:05.689 align:start position:0% individual nodes to perform all the work of<00:10:02.579> a<00:10:03.389> particular<00:10:04.139> area<00:10:04.470> of<00:10:04.679> the<00:10:05.100> distributed 00:10:05.689 --> 00:10:05.699 align:start position:0% of a particular area of the distributed 00:10:05.699 --> 00:10:07.429 align:start position:0% of a particular area of the distributed application<00:10:06.360> so<00:10:06.600> you<00:10:06.629> want<00:10:06.929> to<00:10:07.079> distribute 00:10:07.429 --> 00:10:07.439 align:start position:0% application so you want to distribute 00:10:07.439 --> 00:10:12.650 align:start position:0% application so you want to distribute all<00:10:08.129> the<00:10:09.230> tasks<00:10:10.230> of<00:10:10.350> ADAP<00:10:11.160> or<00:10:11.459> as<00:10:11.819> many<00:10:12.209> tasks 00:10:12.650 --> 00:10:12.660 align:start position:0% all the tasks of ADAP or as many tasks 00:10:12.660 --> 00:10:15.410 align:start position:0% all the tasks of ADAP or as many tasks of<00:10:12.809> the<00:10:12.959> app<00:10:13.110> as<00:10:13.290> you<00:10:13.439> can<00:10:13.709> over<00:10:13.980> a<00:10:14.819> large 00:10:15.410 --> 00:10:15.420 align:start position:0% of the app as you can over a large 00:10:15.420 --> 00:10:17.090 align:start position:0% of the app as you can over a large number<00:10:15.839> of<00:10:15.869> nodes<00:10:16.139> that<00:10:16.470> are<00:10:16.619> working<00:10:16.829> in 00:10:17.090 --> 00:10:17.100 align:start position:0% number of nodes that are working in 00:10:17.100 --> 00:10:21.439 align:start position:0% number of nodes that are working in parallel<00:10:17.579> and<00:10:18.920> also<00:10:19.920> bottlenecks<00:10:20.879> can<00:10:21.179> be<00:10:21.389> in 00:10:21.439 --> 00:10:21.449 align:start position:0% parallel and also bottlenecks can be in 00:10:21.449 --> 00:10:25.400 align:start position:0% parallel and also bottlenecks can be in network<00:10:21.869> links<00:10:22.230> so<00:10:23.129> for<00:10:23.339> example<00:10:24.199> you<00:10:25.199> do<00:10:25.379> not 00:10:25.400 --> 00:10:25.410 align:start position:0% network links so for example you do not 00:10:25.410 --> 00:10:28.879 align:start position:0% network links so for example you do not necessarily<00:10:26.040> want<00:10:26.790> to<00:10:27.329> broadcast<00:10:27.889> every 00:10:28.879 --> 00:10:28.889 align:start position:0% necessarily want to broadcast every 00:10:28.889 --> 00:10:30.679 align:start position:0% necessarily want to broadcast every interaction<00:10:29.189> to<00:10:29.999> the<00:10:30.119> entire<00:10:30.420> network 00:10:30.679 --> 00:10:30.689 align:start position:0% interaction to the entire network 00:10:30.689 --> 00:10:32.840 align:start position:0% interaction to the entire network because<00:10:31.529> then<00:10:31.740> you're<00:10:31.980> going<00:10:32.189> to<00:10:32.279> have<00:10:32.610> a 00:10:32.840 --> 00:10:32.850 align:start position:0% because then you're going to have a 00:10:32.850 --> 00:10:38.230 align:start position:0% because then you're going to have a network<00:10:33.149> congestion<00:10:33.509> and<00:10:36.170> in<00:10:37.170> case<00:10:37.769> of 00:10:38.230 --> 00:10:38.240 align:start position:0% network congestion and in case of 00:10:38.240 --> 00:10:41.360 align:start position:0% network congestion and in case of systems<00:10:39.240> like<00:10:39.449> whisperer<00:10:39.990> you<00:10:40.559> may<00:10:40.769> need<00:10:41.040> to 00:10:41.360 --> 00:10:41.370 align:start position:0% systems like whisperer you may need to 00:10:41.370 --> 00:10:44.480 align:start position:0% systems like whisperer you may need to pay<00:10:41.639> in<00:10:42.269> terms<00:10:42.569> of<00:10:42.839> proof<00:10:43.139> of<00:10:43.319> work<00:10:43.559> for<00:10:44.129> doing 00:10:44.480 --> 00:10:44.490 align:start position:0% pay in terms of proof of work for doing 00:10:44.490 --> 00:10:48.379 align:start position:0% pay in terms of proof of work for doing so<00:10:45.829> so<00:10:46.829> these<00:10:47.009> are<00:10:47.279> the<00:10:47.429> bottlenecks<00:10:47.790> that 00:10:48.379 --> 00:10:48.389 align:start position:0% so so these are the bottlenecks that 00:10:48.389 --> 00:10:54.619 align:start position:0% so so these are the bottlenecks that we're<00:10:48.689> going<00:10:48.929> to<00:10:49.079> be<00:10:49.199> dealing<00:10:49.350> with<00:10:52.879> so<00:10:53.879> the 00:10:54.619 --> 00:10:54.629 align:start position:0% we're going to be dealing with so the 00:10:54.629 --> 00:10:57.739 align:start position:0% we're going to be dealing with so the storage<00:10:54.929> bottleneck<00:10:55.589> is<00:10:55.829> best<00:10:56.459> overcome<00:10:57.179> by 00:10:57.739 --> 00:10:57.749 align:start position:0% storage bottleneck is best overcome by 00:10:57.749 --> 00:11:00.530 align:start position:0% storage bottleneck is best overcome by storing<00:10:58.439> everything<00:10:59.009> that<00:10:59.220> you<00:10:59.339> can<00:10:59.610> inform 00:11:00.530 --> 00:11:00.540 align:start position:0% storing everything that you can inform 00:11:00.540 --> 00:11:04.600 align:start position:0% storing everything that you can inform and<00:11:01.189> put<00:11:02.189> the<00:11:02.639> root<00:11:02.879> hash<00:11:03.149> of<00:11:03.509> your<00:11:03.899> data<00:11:04.170> in 00:11:04.600 --> 00:11:04.610 align:start position:0% and put the root hash of your data in 00:11:04.610 --> 00:11:10.639 align:start position:0% and put the root hash of your data in iana's<00:11:05.839> so<00:11:06.839> the<00:11:07.529> root<00:11:07.709> hash<00:11:08.009> is<00:11:08.540> just<00:11:09.540> 32<00:11:10.410> bytes 00:11:10.639 --> 00:11:10.649 align:start position:0% iana's so the root hash is just 32 bytes 00:11:10.649 --> 00:11:15.400 align:start position:0% iana's so the root hash is just 32 bytes and<00:11:11.720> it<00:11:12.720> can<00:11:13.259> integrity<00:11:14.040> protect<00:11:14.519> as<00:11:14.730> well<00:11:15.120> as 00:11:15.400 --> 00:11:15.410 align:start position:0% and it can integrity protect as well as 00:11:15.410 --> 00:11:19.730 align:start position:0% and it can integrity protect as well as identify<00:11:16.879> data<00:11:17.879> of<00:11:18.299> arbitrary<00:11:18.990> size<00:11:19.319> and 00:11:19.730 --> 00:11:19.740 align:start position:0% identify data of arbitrary size and 00:11:19.740 --> 00:11:23.569 align:start position:0% identify data of arbitrary size and complexity<00:11:20.279> and<00:11:20.549> structure<00:11:21.439> meaning<00:11:22.439> that<00:11:22.709> no 00:11:23.569 --> 00:11:23.579 align:start position:0% complexity and structure meaning that no 00:11:23.579 --> 00:11:28.549 align:start position:0% complexity and structure meaning that no matter<00:11:24.619> how<00:11:25.619> much<00:11:25.860> data<00:11:26.189> you're<00:11:26.579> updating<00:11:27.559> you 00:11:28.549 --> 00:11:28.559 align:start position:0% matter how much data you're updating you 00:11:28.559 --> 00:11:31.220 align:start position:0% matter how much data you're updating you still<00:11:28.920> on<00:11:29.189> the<00:11:29.670> blockchain<00:11:29.910> you<00:11:30.420> only<00:11:30.660> need<00:11:30.990> to 00:11:31.220 --> 00:11:31.230 align:start position:0% still on the blockchain you only need to 00:11:31.230 --> 00:11:35.269 align:start position:0% still on the blockchain you only need to change<00:11:31.639> 32<00:11:32.639> bytes<00:11:32.970> which<00:11:33.779> is<00:11:34.019> obviously<00:11:34.799> a<00:11:35.040> lot 00:11:35.269 --> 00:11:35.279 align:start position:0% change 32 bytes which is obviously a lot 00:11:35.279 --> 00:11:41.119 align:start position:0% change 32 bytes which is obviously a lot cheaper<00:11:35.549> than<00:11:35.939> changing<00:11:36.839> megabytes 00:11:41.119 --> 00:11:41.129 align:start position:0% 00:11:41.129 --> 00:11:44.159 align:start position:0% the<00:11:42.129> transaction<00:11:42.819> bottleneck<00:11:43.389> can<00:11:43.689> also<00:11:43.899> be 00:11:44.159 --> 00:11:44.169 align:start position:0% the transaction bottleneck can also be 00:11:44.169 --> 00:11:50.429 align:start position:0% the transaction bottleneck can also be overcome<00:11:44.679> so<00:11:47.519> for<00:11:48.519> those<00:11:48.699> of<00:11:48.759> you<00:11:49.229> who<00:11:50.229> don't 00:11:50.429 --> 00:11:50.439 align:start position:0% overcome so for those of you who don't 00:11:50.439 --> 00:11:55.439 align:start position:0% overcome so for those of you who don't know<00:11:50.909> EMS<00:11:51.989> has<00:11:52.989> resolver<00:11:53.919> contracts<00:11:54.609> so<00:11:55.149> each 00:11:55.439 --> 00:11:55.449 align:start position:0% know EMS has resolver contracts so each 00:11:55.449 --> 00:12:00.229 align:start position:0% know EMS has resolver contracts so each time<00:11:55.779> you<00:11:56.169> ask<00:11:56.909> Ian<00:11:57.909> us<00:11:58.209> what<00:11:59.019> the<00:11:59.319> particular 00:12:00.229 --> 00:12:00.239 align:start position:0% time you ask Ian us what the particular 00:12:00.239 --> 00:12:04.309 align:start position:0% time you ask Ian us what the particular address<00:12:01.919> corresponding<00:12:02.919> to<00:12:03.129> a<00:12:03.159> name<00:12:03.459> is 00:12:04.309 --> 00:12:04.319 align:start position:0% address corresponding to a name is 00:12:04.319 --> 00:12:07.259 align:start position:0% address corresponding to a name is you're<00:12:05.319> going<00:12:05.589> to<00:12:05.859> have<00:12:06.039> a<00:12:06.069> contract<00:12:06.759> answer 00:12:07.259 --> 00:12:07.269 align:start position:0% you're going to have a contract answer 00:12:07.269 --> 00:12:10.949 align:start position:0% you're going to have a contract answer you<00:12:07.479> and<00:12:07.979> those<00:12:08.979> contracts<00:12:09.549> can<00:12:09.970> be<00:12:10.209> more 00:12:10.949 --> 00:12:10.959 align:start position:0% you and those contracts can be more 00:12:10.959 --> 00:12:14.189 align:start position:0% you and those contracts can be more complicated<00:12:11.379> than<00:12:12.039> a<00:12:12.459> simple<00:12:12.489> storage<00:12:13.449> of<00:12:13.720> 32 00:12:14.189 --> 00:12:14.199 align:start position:0% complicated than a simple storage of 32 00:12:14.199 --> 00:12:16.979 align:start position:0% complicated than a simple storage of 32 bytes<00:12:14.439> in<00:12:15.009> particular<00:12:15.729> you<00:12:16.419> can<00:12:16.449> implement 00:12:16.979 --> 00:12:16.989 align:start position:0% bytes in particular you can implement 00:12:16.989 --> 00:12:21.299 align:start position:0% bytes in particular you can implement Radin<00:12:17.829> style<00:12:18.159> updates<00:12:18.639> on<00:12:18.909> els<00:12:19.829> meaning<00:12:20.829> that 00:12:21.299 --> 00:12:21.309 align:start position:0% Radin style updates on els meaning that 00:12:21.309 --> 00:12:23.699 align:start position:0% Radin style updates on els meaning that you<00:12:21.789> can<00:12:21.999> send<00:12:22.389> those<00:12:22.569> updates<00:12:23.139> to<00:12:23.379> all<00:12:23.529> the 00:12:23.699 --> 00:12:23.709 align:start position:0% you can send those updates to all the 00:12:23.709 --> 00:12:27.119 align:start position:0% you can send those updates to all the interested<00:12:24.249> nodes<00:12:25.349> but<00:12:26.349> you<00:12:26.470> don't<00:12:26.709> have<00:12:26.919> to 00:12:27.119 --> 00:12:27.129 align:start position:0% interested nodes but you don't have to 00:12:27.129 --> 00:12:31.469 align:start position:0% interested nodes but you don't have to commit<00:12:27.459> all<00:12:27.759> of<00:12:28.029> them<00:12:28.239> immediately<00:12:29.079> to<00:12:29.919> the<00:12:30.479> to 00:12:31.469 --> 00:12:31.479 align:start position:0% commit all of them immediately to the to 00:12:31.479 --> 00:12:35.849 align:start position:0% commit all of them immediately to the to the<00:12:31.599> blockchain<00:12:32.999> and<00:12:33.999> yet<00:12:34.479> all<00:12:35.169> the<00:12:35.229> nodes 00:12:35.849 --> 00:12:35.859 align:start position:0% the blockchain and yet all the nodes 00:12:35.859 --> 00:12:37.829 align:start position:0% the blockchain and yet all the nodes that<00:12:36.039> are<00:12:36.279> interested<00:12:36.879> are<00:12:37.029> going<00:12:37.299> to<00:12:37.599> know 00:12:37.829 --> 00:12:37.839 align:start position:0% that are interested are going to know 00:12:37.839 --> 00:12:41.249 align:start position:0% that are interested are going to know that<00:12:38.679> the<00:12:39.189> content<00:12:39.669> has<00:12:39.759> changed<00:12:40.419> and<00:12:40.569> any<00:12:41.049> of 00:12:41.249 --> 00:12:41.259 align:start position:0% that the content has changed and any of 00:12:41.259 --> 00:12:44.369 align:start position:0% that the content has changed and any of them<00:12:41.499> can<00:12:41.939> commit<00:12:42.939> it<00:12:43.119> to<00:12:43.329> the<00:12:43.419> blockchain<00:12:43.779> in 00:12:44.369 --> 00:12:44.379 align:start position:0% them can commit it to the blockchain in 00:12:44.379 --> 00:12:48.869 align:start position:0% them can commit it to the blockchain in case<00:12:45.009> it<00:12:45.429> becomes<00:12:46.439> it<00:12:47.439> becomes<00:12:47.619> critical<00:12:48.459> that 00:12:48.869 --> 00:12:48.879 align:start position:0% case it becomes it becomes critical that 00:12:48.879 --> 00:12:51.899 align:start position:0% case it becomes it becomes critical that a<00:12:49.149> consensus<00:12:49.779> is<00:12:49.959> reached<00:12:50.169> so<00:12:50.589> this<00:12:51.129> way<00:12:51.639> we 00:12:51.899 --> 00:12:51.909 align:start position:0% a consensus is reached so this way we 00:12:51.909 --> 00:12:55.710 align:start position:0% a consensus is reached so this way we take<00:12:52.149> the<00:12:52.359> burden<00:12:53.019> of<00:12:53.639> updates<00:12:54.639> of<00:12:54.939> the 00:12:55.710 --> 00:12:55.720 align:start position:0% take the burden of updates of the 00:12:55.720 --> 00:12:57.929 align:start position:0% take the burden of updates of the blockchain<00:12:55.989> and<00:12:56.589> we<00:12:56.739> can<00:12:56.919> have<00:12:57.159> in<00:12:57.369> frequent 00:12:57.929 --> 00:12:57.939 align:start position:0% blockchain and we can have in frequent 00:12:57.939 --> 00:13:00.479 align:start position:0% blockchain and we can have in frequent updates<00:12:58.209> to<00:12:58.749> the<00:12:58.869> blockchain<00:12:59.139> and<00:12:59.589> yet<00:13:00.189> have 00:13:00.479 --> 00:13:00.489 align:start position:0% updates to the blockchain and yet have 00:13:00.489 --> 00:13:02.669 align:start position:0% updates to the blockchain and yet have immediate<00:13:01.179> and<00:13:01.419> very<00:13:01.720> very<00:13:01.959> frequent<00:13:02.470> updates 00:13:02.669 --> 00:13:02.679 align:start position:0% immediate and very very frequent updates 00:13:02.679 --> 00:13:05.549 align:start position:0% immediate and very very frequent updates to<00:13:03.639> the<00:13:03.789> root<00:13:03.939> hash<00:13:04.209> of<00:13:04.539> the<00:13:04.779> data<00:13:04.959> that<00:13:05.349> we<00:13:05.529> are 00:13:05.549 --> 00:13:05.559 align:start position:0% to the root hash of the data that we are 00:13:05.559 --> 00:13:10.309 align:start position:0% to the root hash of the data that we are using<00:13:07.769> broadcast<00:13:08.789> bottlenecks 00:13:10.309 --> 00:13:10.319 align:start position:0% using broadcast bottlenecks 00:13:10.319 --> 00:13:14.369 align:start position:0% using broadcast bottlenecks they<00:13:11.319> can<00:13:11.529> also<00:13:11.679> be<00:13:11.889> overcome<00:13:12.519> using<00:13:12.939> PSS<00:13:13.509> so 00:13:14.369 --> 00:13:14.379 align:start position:0% they can also be overcome using PSS so 00:13:14.379 --> 00:13:19.969 align:start position:0% they can also be overcome using PSS so just<00:13:14.859> as<00:13:16.169> Louis<00:13:17.169> had<00:13:17.669> explained<00:13:18.669> before<00:13:19.119> me 00:13:19.969 --> 00:13:19.979 align:start position:0% just as Louis had explained before me 00:13:19.979 --> 00:13:23.729 align:start position:0% just as Louis had explained before me PSS<00:13:20.979> can<00:13:21.339> be<00:13:21.519> used<00:13:21.819> to<00:13:22.179> broadcast<00:13:22.419> messages<00:13:23.049> to 00:13:23.729 --> 00:13:23.739 align:start position:0% PSS can be used to broadcast messages to 00:13:23.739 --> 00:13:25.679 align:start position:0% PSS can be used to broadcast messages to parts<00:13:24.159> of<00:13:24.399> the<00:13:24.549> network<00:13:24.699> instead<00:13:25.389> of<00:13:25.539> the 00:13:25.679 --> 00:13:25.689 align:start position:0% parts of the network instead of the 00:13:25.689 --> 00:13:28.669 align:start position:0% parts of the network instead of the entire<00:13:25.959> network<00:13:26.169> so<00:13:27.129> if<00:13:27.459> you<00:13:27.729> have<00:13:28.389> this 00:13:28.669 --> 00:13:28.679 align:start position:0% entire network so if you have this 00:13:28.679 --> 00:13:34.379 align:start position:0% entire network so if you have this pops-up<00:13:30.449> model<00:13:31.449> then<00:13:32.139> PSS<00:13:32.919> will<00:13:33.279> make<00:13:34.089> sure 00:13:34.379 --> 00:13:34.389 align:start position:0% pops-up model then PSS will make sure 00:13:34.389 --> 00:13:38.069 align:start position:0% pops-up model then PSS will make sure that<00:13:35.459> even<00:13:36.459> though<00:13:36.609> there<00:13:36.849> is<00:13:36.970> an<00:13:37.149> overhead 00:13:38.069 --> 00:13:38.079 align:start position:0% that even though there is an overhead 00:13:38.079 --> 00:13:43.710 align:start position:0% that even though there is an overhead you<00:13:38.829> won't<00:13:39.129> burden<00:13:39.939> the<00:13:41.249> swarm<00:13:42.249> network<00:13:42.759> with 00:13:43.710 --> 00:13:43.720 align:start position:0% you won't burden the swarm network with 00:13:43.720 --> 00:13:46.909 align:start position:0% you won't burden the swarm network with every<00:13:44.379> message<00:13:44.799> broadcast<00:13:45.699> it<00:13:45.939> to<00:13:45.970> every<00:13:46.449> node 00:13:46.909 --> 00:13:46.919 align:start position:0% every message broadcast it to every node 00:13:46.919 --> 00:13:50.519 align:start position:0% every message broadcast it to every node of<00:13:47.919> course<00:13:48.519> this<00:13:48.879> only<00:13:49.119> becomes<00:13:49.659> a<00:13:49.809> problem<00:13:50.079> if 00:13:50.519 --> 00:13:50.529 align:start position:0% of course this only becomes a problem if 00:13:50.529 --> 00:13:51.999 align:start position:0% of course this only becomes a problem if your 00:13:51.999 --> 00:13:52.009 align:start position:0% your 00:13:52.009 --> 00:13:54.980 align:start position:0% your application<00:13:53.009> scales<00:13:53.339> really<00:13:53.730> big<00:13:53.910> so<00:13:54.540> for 00:13:54.980 --> 00:13:54.990 align:start position:0% application scales really big so for 00:13:54.990 --> 00:13:57.499 align:start position:0% application scales really big so for many<00:13:55.709> applications<00:13:56.360> broadcasting<00:13:57.360> is 00:13:57.499 --> 00:13:57.509 align:start position:0% many applications broadcasting is 00:13:57.509 --> 00:14:00.139 align:start position:0% many applications broadcasting is perfectly<00:13:57.959> adequate<00:13:58.079> and<00:13:58.649> if<00:13:59.129> you<00:13:59.370> are<00:13:59.579> more 00:14:00.139 --> 00:14:00.149 align:start position:0% perfectly adequate and if you are more 00:14:00.149 --> 00:14:02.150 align:start position:0% perfectly adequate and if you are more interested<00:14:00.689> in<00:14:00.779> darkness<00:14:01.290> you<00:14:01.470> can<00:14:01.649> still<00:14:01.920> use 00:14:02.150 --> 00:14:02.160 align:start position:0% interested in darkness you can still use 00:14:02.160 --> 00:14:04.999 align:start position:0% interested in darkness you can still use whisper<00:14:02.699> but<00:14:03.329> then<00:14:03.509> you<00:14:03.689> will<00:14:03.839> have<00:14:04.050> to<00:14:04.319> keep 00:14:04.999 --> 00:14:05.009 align:start position:0% whisper but then you will have to keep 00:14:05.009 --> 00:14:07.910 align:start position:0% whisper but then you will have to keep in<00:14:05.189> mind<00:14:05.459> that<00:14:06.149> you<00:14:06.420> have<00:14:06.660> a<00:14:06.990> network 00:14:07.910 --> 00:14:07.920 align:start position:0% in mind that you have a network 00:14:07.920 --> 00:14:15.019 align:start position:0% in mind that you have a network bottleneck<00:14:11.600> so<00:14:12.600> in<00:14:13.379> the<00:14:13.800> next<00:14:14.069> part<00:14:14.309> I'm<00:14:14.730> going 00:14:15.019 --> 00:14:15.029 align:start position:0% bottleneck so in the next part I'm going 00:14:15.029 --> 00:14:18.530 align:start position:0% bottleneck so in the next part I'm going to<00:14:15.269> discuss<00:14:15.689> challenges<00:14:16.370> of<00:14:17.370> a<00:14:17.540> trade-off 00:14:18.530 --> 00:14:18.540 align:start position:0% to discuss challenges of a trade-off 00:14:18.540 --> 00:14:21.699 align:start position:0% to discuss challenges of a trade-off between<00:14:19.160> responsiveness<00:14:20.160> and<00:14:20.550> consistency 00:14:21.699 --> 00:14:21.709 align:start position:0% between responsiveness and consistency 00:14:21.709 --> 00:14:23.629 align:start position:0% between responsiveness and consistency it's<00:14:22.709> a<00:14:22.860> trade-off 00:14:23.629 --> 00:14:23.639 align:start position:0% it's a trade-off 00:14:23.639 --> 00:14:27.199 align:start position:0% it's a trade-off because<00:14:24.319> the<00:14:25.319> faster<00:14:25.800> things<00:14:26.040> happen<00:14:26.639> the 00:14:27.199 --> 00:14:27.209 align:start position:0% because the faster things happen the 00:14:27.209 --> 00:14:29.660 align:start position:0% because the faster things happen the more<00:14:27.420> difficult<00:14:27.660> it<00:14:28.139> becomes<00:14:28.319> to<00:14:28.829> agree<00:14:29.129> in<00:14:29.519> a 00:14:29.660 --> 00:14:29.670 align:start position:0% more difficult it becomes to agree in a 00:14:29.670 --> 00:14:38.929 align:start position:0% more difficult it becomes to agree in a timely<00:14:30.029> fashion<00:14:35.149> so<00:14:36.149> the<00:14:37.370> consistency<00:14:38.370> is 00:14:38.929 --> 00:14:38.939 align:start position:0% timely fashion so the consistency is 00:14:38.939 --> 00:14:41.989 align:start position:0% timely fashion so the consistency is only<00:14:39.269> guaranteed<00:14:40.170> on<00:14:40.499> the<00:14:41.249> blockchain 00:14:41.989 --> 00:14:41.999 align:start position:0% only guaranteed on the blockchain 00:14:41.999 --> 00:14:45.230 align:start position:0% only guaranteed on the blockchain but<00:14:42.720> this<00:14:42.899> consistency<00:14:43.589> is<00:14:44.040> a<00:14:44.339> eventual 00:14:45.230 --> 00:14:45.240 align:start position:0% but this consistency is a eventual 00:14:45.240 --> 00:14:47.840 align:start position:0% but this consistency is a eventual consistency<00:14:45.680> which<00:14:46.680> is<00:14:46.709> rather<00:14:47.069> slow<00:14:47.490> so<00:14:47.819> you 00:14:47.840 --> 00:14:47.850 align:start position:0% consistency which is rather slow so you 00:14:47.850 --> 00:14:49.989 align:start position:0% consistency which is rather slow so you can<00:14:48.120> see<00:14:48.360> a<00:14:48.889> back-of-the-envelope 00:14:49.989 --> 00:14:49.999 align:start position:0% can see a back-of-the-envelope 00:14:49.999 --> 00:14:52.730 align:start position:0% can see a back-of-the-envelope calculation<00:14:50.999> that<00:14:51.029> tells<00:14:51.569> you<00:14:51.839> that<00:14:52.050> you<00:14:52.559> will 00:14:52.730 --> 00:14:52.740 align:start position:0% calculation that tells you that you will 00:14:52.740 --> 00:14:56.869 align:start position:0% calculation that tells you that you will reach<00:14:52.920> consensus<00:14:53.759> in<00:14:54.269> a<00:14:54.930> time<00:14:55.309> that<00:14:56.309> can 00:14:56.869 --> 00:14:56.879 align:start position:0% reach consensus in a time that can 00:14:56.879 --> 00:14:59.269 align:start position:0% reach consensus in a time that can hardly<00:14:57.240> be<00:14:57.449> called<00:14:58.009> responsive<00:14:59.009> and<00:14:59.220> you 00:14:59.269 --> 00:14:59.279 align:start position:0% hardly be called responsive and you 00:14:59.279 --> 00:15:03.259 align:start position:0% hardly be called responsive and you don't<00:14:59.879> want<00:15:00.689> to<00:15:00.899> wait<00:15:01.350> that<00:15:01.740> much<00:15:02.610> time<00:15:02.939> for 00:15:03.259 --> 00:15:03.269 align:start position:0% don't want to wait that much time for 00:15:03.269 --> 00:15:06.379 align:start position:0% don't want to wait that much time for every<00:15:03.540> update<00:15:03.959> to<00:15:04.379> be<00:15:05.160> visible<00:15:05.670> to<00:15:05.939> all<00:15:06.149> the 00:15:06.379 --> 00:15:06.389 align:start position:0% every update to be visible to all the 00:15:06.389 --> 00:15:09.069 align:start position:0% every update to be visible to all the users<00:15:06.660> of<00:15:07.110> your<00:15:07.230> application 00:15:09.069 --> 00:15:09.079 align:start position:0% users of your application 00:15:09.079 --> 00:15:16.699 align:start position:0% users of your application so<00:15:13.639> essentially<00:15:14.639> you<00:15:15.209> need<00:15:15.480> to<00:15:15.779> broadcast<00:15:16.079> the 00:15:16.699 --> 00:15:16.709 align:start position:0% so essentially you need to broadcast the 00:15:16.709 --> 00:15:20.139 align:start position:0% so essentially you need to broadcast the updates<00:15:17.160> to<00:15:17.490> all<00:15:18.029> the<00:15:18.269> interested<00:15:18.839> parties 00:15:20.139 --> 00:15:20.149 align:start position:0% updates to all the interested parties 00:15:20.149 --> 00:15:25.249 align:start position:0% updates to all the interested parties and<00:15:21.620> then<00:15:22.620> you<00:15:23.009> only<00:15:23.220> need<00:15:23.430> to<00:15:23.819> commit<00:15:24.209> to<00:15:24.269> the 00:15:25.249 --> 00:15:25.259 align:start position:0% and then you only need to commit to the 00:15:25.259 --> 00:15:30.879 align:start position:0% and then you only need to commit to the blockchain<00:15:25.790> once<00:15:26.790> it<00:15:27.480> becomes<00:15:28.379> important<00:15:29.339> to 00:15:30.879 --> 00:15:30.889 align:start position:0% blockchain once it becomes important to 00:15:30.889 --> 00:15:35.179 align:start position:0% blockchain once it becomes important to to<00:15:31.889> guarantee<00:15:32.899> the<00:15:33.899> consistency<00:15:34.889> over<00:15:35.160> a 00:15:35.179 --> 00:15:35.189 align:start position:0% to guarantee the consistency over a 00:15:35.189 --> 00:15:38.540 align:start position:0% to guarantee the consistency over a longer<00:15:35.730> period<00:15:36.209> of<00:15:36.449> time<00:15:36.589> so<00:15:37.589> here<00:15:38.309> I<00:15:38.339> would 00:15:38.540 --> 00:15:38.550 align:start position:0% longer period of time so here I would 00:15:38.550 --> 00:15:42.110 align:start position:0% longer period of time so here I would like<00:15:38.879> to<00:15:39.089> give<00:15:39.269> you<00:15:39.420> a<00:15:39.449> few<00:15:40.110> examples<00:15:40.550> so<00:15:41.550> one 00:15:42.110 --> 00:15:42.120 align:start position:0% like to give you a few examples so one 00:15:42.120 --> 00:15:45.650 align:start position:0% like to give you a few examples so one one<00:15:43.110> is<00:15:43.379> a<00:15:43.410> online<00:15:44.009> discussion<00:15:44.699> where<00:15:45.300> there's 00:15:45.650 --> 00:15:45.660 align:start position:0% one is a online discussion where there's 00:15:45.660 --> 00:15:48.650 align:start position:0% one is a online discussion where there's some<00:15:45.959> kind<00:15:46.259> of<00:15:46.379> content<00:15:46.860> be<00:15:47.220> it<00:15:47.250> a<00:15:47.519> video<00:15:47.759> or<00:15:48.269> a 00:15:48.650 --> 00:15:48.660 align:start position:0% some kind of content be it a video or a 00:15:48.660 --> 00:15:52.309 align:start position:0% some kind of content be it a video or a blog<00:15:48.689> post<00:15:49.079> or<00:15:49.589> a<00:15:50.490> picture<00:15:50.999> that<00:15:51.749> several 00:15:52.309 --> 00:15:52.319 align:start position:0% blog post or a picture that several 00:15:52.319 --> 00:15:55.400 align:start position:0% blog post or a picture that several users<00:15:52.589> are<00:15:53.009> viewing<00:15:53.399> and<00:15:53.670> commenting<00:15:54.240> and<00:15:54.509> the 00:15:55.400 --> 00:15:55.410 align:start position:0% users are viewing and commenting and the 00:15:55.410 --> 00:15:59.210 align:start position:0% users are viewing and commenting and the other<00:15:55.559> is<00:15:56.009> a<00:15:56.809> massively<00:15:57.809> multiplayer<00:15:58.319> game<00:15:58.889> in 00:15:59.210 --> 00:15:59.220 align:start position:0% other is a massively multiplayer game in 00:15:59.220 --> 00:16:02.660 align:start position:0% other is a massively multiplayer game in which<00:16:00.290> different<00:16:01.290> players<00:16:01.649> are<00:16:02.040> interacting 00:16:02.660 --> 00:16:02.670 align:start position:0% which different players are interacting 00:16:02.670 --> 00:16:04.819 align:start position:0% which different players are interacting with<00:16:02.819> each<00:16:02.850> other<00:16:03.120> obviously<00:16:03.829> submitting 00:16:04.819 --> 00:16:04.829 align:start position:0% with each other obviously submitting 00:16:04.829 --> 00:16:05.510 align:start position:0% with each other obviously submitting everything<00:16:05.309> to 00:16:05.510 --> 00:16:05.520 align:start position:0% everything to 00:16:05.520 --> 00:16:10.310 align:start position:0% everything to blockchain<00:16:06.030> is<00:16:06.180> hopeless<00:16:06.630> in<00:16:06.840> both<00:16:06.990> cases<00:16:09.320> so 00:16:10.310 --> 00:16:10.320 align:start position:0% blockchain is hopeless in both cases so 00:16:10.320 --> 00:16:15.050 align:start position:0% blockchain is hopeless in both cases so in<00:16:11.220> both<00:16:11.580> cases<00:16:12.140> you<00:16:13.140> can<00:16:13.350> notice<00:16:13.920> that<00:16:14.520> it<00:16:14.850> is 00:16:15.050 --> 00:16:15.060 align:start position:0% in both cases you can notice that it is 00:16:15.060 --> 00:16:20.720 align:start position:0% in both cases you can notice that it is relatively<00:16:15.720> easy<00:16:16.140> to<00:16:17.720> scope<00:16:18.720> the<00:16:19.550> circle<00:16:20.550> of 00:16:20.720 --> 00:16:20.730 align:start position:0% relatively easy to scope the circle of 00:16:20.730 --> 00:16:23.710 align:start position:0% relatively easy to scope the circle of interested<00:16:21.360> parties<00:16:21.870> of<00:16:22.140> a<00:16:22.890> particular 00:16:23.710 --> 00:16:23.720 align:start position:0% interested parties of a particular 00:16:23.720 --> 00:16:29.900 align:start position:0% interested parties of a particular update<00:16:24.830> so<00:16:25.830> in<00:16:26.370> case<00:16:26.730> of<00:16:27.030> a<00:16:28.040> online<00:16:29.040> discussion 00:16:29.900 --> 00:16:29.910 align:start position:0% update so in case of a online discussion 00:16:29.910 --> 00:16:33.110 align:start position:0% update so in case of a online discussion it<00:16:30.240> is<00:16:30.690> perfectly<00:16:31.560> enough<00:16:31.830> to<00:16:32.490> make<00:16:32.700> updates 00:16:33.110 --> 00:16:33.120 align:start position:0% it is perfectly enough to make updates 00:16:33.120 --> 00:16:37.130 align:start position:0% it is perfectly enough to make updates fast<00:16:34.020> to<00:16:34.830> those<00:16:35.070> who<00:16:35.490> are<00:16:35.640> actually<00:16:36.300> viewing 00:16:37.130 --> 00:16:37.140 align:start position:0% fast to those who are actually viewing 00:16:37.140 --> 00:16:39.320 align:start position:0% fast to those who are actually viewing that<00:16:37.470> discussion<00:16:38.100> who<00:16:38.250> are<00:16:38.340> participating<00:16:38.970> in 00:16:39.320 --> 00:16:39.330 align:start position:0% that discussion who are participating in 00:16:39.330 --> 00:16:43.160 align:start position:0% that discussion who are participating in it<00:16:39.510> and<00:16:40.010> it<00:16:41.010> is<00:16:41.040> acceptable<00:16:41.940> that<00:16:42.240> others<00:16:42.660> who 00:16:43.160 --> 00:16:43.170 align:start position:0% it and it is acceptable that others who 00:16:43.170 --> 00:16:44.690 align:start position:0% it and it is acceptable that others who are<00:16:43.260> not<00:16:43.470> browsing<00:16:43.980> that<00:16:44.160> particular 00:16:44.690 --> 00:16:44.700 align:start position:0% are not browsing that particular 00:16:44.700 --> 00:16:48.140 align:start position:0% are not browsing that particular discussion<00:16:44.970> right<00:16:45.450> now<00:16:45.680> will<00:16:46.680> only<00:16:46.950> have<00:16:47.340> the 00:16:48.140 --> 00:16:48.150 align:start position:0% discussion right now will only have the 00:16:48.150 --> 00:16:52.010 align:start position:0% discussion right now will only have the update<00:16:49.490> much<00:16:50.490> later<00:16:50.820> and<00:16:51.210> they<00:16:51.720> are<00:16:51.780> only 00:16:52.010 --> 00:16:52.020 align:start position:0% update much later and they are only 00:16:52.020 --> 00:16:54.350 align:start position:0% update much later and they are only interested<00:16:52.830> in<00:16:52.860> the<00:16:53.070> final<00:16:53.880> state<00:16:54.150> of<00:16:54.180> the 00:16:54.350 --> 00:16:54.360 align:start position:0% interested in the final state of the 00:16:54.360 --> 00:16:56.210 align:start position:0% interested in the final state of the discussion<00:16:54.990> they<00:16:55.170> don't<00:16:55.380> need<00:16:55.590> to<00:16:55.830> receive 00:16:56.210 --> 00:16:56.220 align:start position:0% discussion they don't need to receive 00:16:56.220 --> 00:16:59.930 align:start position:0% discussion they don't need to receive every<00:16:57.180> update<00:16:57.390> at<00:16:57.870> all<00:16:58.080> times<00:16:58.410> and<00:16:58.940> similarly 00:16:59.930 --> 00:16:59.940 align:start position:0% every update at all times and similarly 00:16:59.940 --> 00:17:03.290 align:start position:0% every update at all times and similarly in<00:17:00.390> online<00:17:00.870> games<00:17:01.460> there<00:17:02.460> are<00:17:02.670> typically 00:17:03.290 --> 00:17:03.300 align:start position:0% in online games there are typically 00:17:03.300 --> 00:17:06.290 align:start position:0% in online games there are typically locations<00:17:03.990> and<00:17:04.290> there<00:17:05.010> are<00:17:05.220> some<00:17:05.550> players<00:17:05.820> in 00:17:06.290 --> 00:17:06.300 align:start position:0% locations and there are some players in 00:17:06.300 --> 00:17:10.120 align:start position:0% locations and there are some players in that<00:17:06.630> location<00:17:07.020> and<00:17:07.470> you<00:17:08.339> only<00:17:08.550> need<00:17:08.970> to<00:17:09.480> send 00:17:10.120 --> 00:17:10.130 align:start position:0% that location and you only need to send 00:17:10.130 --> 00:17:13.340 align:start position:0% that location and you only need to send quick<00:17:11.130> updates<00:17:11.640> to<00:17:12.240> those<00:17:12.420> players<00:17:12.839> whose 00:17:13.340 --> 00:17:13.350 align:start position:0% quick updates to those players whose 00:17:13.350 --> 00:17:15.710 align:start position:0% quick updates to those players whose characters<00:17:13.950> are<00:17:14.310> in<00:17:14.670> that<00:17:15.120> particular 00:17:15.710 --> 00:17:15.720 align:start position:0% characters are in that particular 00:17:15.720 --> 00:17:17.960 align:start position:0% characters are in that particular location<00:17:15.930> you<00:17:16.440> don't<00:17:16.650> need<00:17:16.950> to<00:17:17.459> send<00:17:17.730> updates 00:17:17.960 --> 00:17:17.970 align:start position:0% location you don't need to send updates 00:17:17.970 --> 00:17:21.590 align:start position:0% location you don't need to send updates to<00:17:18.390> all<00:17:18.570> the<00:17:18.750> players<00:17:19.100> and<00:17:20.209> the<00:17:21.209> update 00:17:21.590 --> 00:17:21.600 align:start position:0% to all the players and the update 00:17:21.600 --> 00:17:26.780 align:start position:0% to all the players and the update structure<00:17:22.200> is<00:17:22.440> also<00:17:24.560> more<00:17:25.560> complicated<00:17:26.130> than 00:17:26.780 --> 00:17:26.790 align:start position:0% structure is also more complicated than 00:17:26.790 --> 00:17:29.920 align:start position:0% structure is also more complicated than simply<00:17:27.060> a<00:17:27.450> hash<00:17:27.839> because<00:17:28.800> if<00:17:29.250> all<00:17:29.490> you 00:17:29.920 --> 00:17:29.930 align:start position:0% simply a hash because if all you 00:17:29.930 --> 00:17:33.800 align:start position:0% simply a hash because if all you broadcast<00:17:30.930> is<00:17:31.260> the<00:17:31.950> new<00:17:32.190> root<00:17:32.430> hash<00:17:32.730> of<00:17:33.030> the 00:17:33.800 --> 00:17:33.810 align:start position:0% broadcast is the new root hash of the 00:17:33.810 --> 00:17:37.120 align:start position:0% broadcast is the new root hash of the swarm<00:17:34.080> content<00:17:34.610> then<00:17:35.610> you're<00:17:35.820> running<00:17:36.060> into<00:17:36.750> a 00:17:37.120 --> 00:17:37.130 align:start position:0% swarm content then you're running into a 00:17:37.130 --> 00:17:41.300 align:start position:0% swarm content then you're running into a responsiveness<00:17:38.130> problem<00:17:38.900> that<00:17:39.950> it<00:17:40.950> takes 00:17:41.300 --> 00:17:41.310 align:start position:0% responsiveness problem that it takes 00:17:41.310 --> 00:17:44.870 align:start position:0% responsiveness problem that it takes time<00:17:41.760> for<00:17:42.540> swarm<00:17:42.840> content<00:17:43.440> to<00:17:43.620> sync<00:17:43.920> even<00:17:44.760> if 00:17:44.870 --> 00:17:44.880 align:start position:0% time for swarm content to sync even if 00:17:44.880 --> 00:17:48.080 align:start position:0% time for swarm content to sync even if we<00:17:45.090> will<00:17:45.300> improve<00:17:45.900> and<00:17:46.320> we<00:17:46.650> will<00:17:46.800> improve<00:17:47.220> the 00:17:48.080 --> 00:17:48.090 align:start position:0% we will improve and we will improve the 00:17:48.090 --> 00:17:51.890 align:start position:0% we will improve and we will improve the performance<00:17:49.310> of<00:17:50.310> the<00:17:50.520> syncing<00:17:50.910> protocol<00:17:51.480> it 00:17:51.890 --> 00:17:51.900 align:start position:0% performance of the syncing protocol it 00:17:51.900 --> 00:17:54.620 align:start position:0% performance of the syncing protocol it will<00:17:52.140> never<00:17:52.410> be<00:17:52.710> as<00:17:52.890> fast<00:17:53.250> as<00:17:53.610> a<00:17:54.240> direct 00:17:54.620 --> 00:17:54.630 align:start position:0% will never be as fast as a direct 00:17:54.630 --> 00:17:57.680 align:start position:0% will never be as fast as a direct message<00:17:54.840> passing<00:17:55.670> simply<00:17:56.670> because<00:17:57.030> a<00:17:57.360> much 00:17:57.680 --> 00:17:57.690 align:start position:0% message passing simply because a much 00:17:57.690 --> 00:18:00.610 align:start position:0% message passing simply because a much larger<00:17:58.200> amount<00:17:58.470> of<00:17:58.650> data<00:17:58.860> needs<00:17:59.280> to<00:17:59.400> be 00:18:00.610 --> 00:18:00.620 align:start position:0% larger amount of data needs to be 00:18:00.620 --> 00:18:02.690 align:start position:0% larger amount of data needs to be transported<00:18:01.620> and<00:18:01.830> it<00:18:01.950> also<00:18:02.130> needs<00:18:02.490> to<00:18:02.610> be 00:18:02.690 --> 00:18:02.700 align:start position:0% transported and it also needs to be 00:18:02.700 --> 00:18:04.040 align:start position:0% transported and it also needs to be stored<00:18:03.120> along<00:18:03.390> the<00:18:03.570> way 00:18:04.040 --> 00:18:04.050 align:start position:0% stored along the way 00:18:04.050 --> 00:18:08.360 align:start position:0% stored along the way so<00:18:04.530> if<00:18:04.800> you<00:18:04.980> only<00:18:05.250> send<00:18:05.900> the<00:18:06.900> root<00:18:07.080> hash<00:18:07.380> then 00:18:08.360 --> 00:18:08.370 align:start position:0% so if you only send the root hash then 00:18:08.370 --> 00:18:12.230 align:start position:0% so if you only send the root hash then the<00:18:08.700> response<00:18:09.240> time<00:18:09.600> is<00:18:09.840> going<00:18:10.620> to<00:18:10.890> be<00:18:11.240> much 00:18:12.230 --> 00:18:12.240 align:start position:0% the response time is going to be much 00:18:12.240 --> 00:18:16.610 align:start position:0% the response time is going to be much longer<00:18:12.630> than<00:18:13.620> the<00:18:14.840> message<00:18:15.840> passing<00:18:16.110> time 00:18:16.610 --> 00:18:16.620 align:start position:0% longer than the message passing time 00:18:16.620 --> 00:18:18.960 align:start position:0% longer than the message passing time because<00:18:17.490> you<00:18:18.090> also<00:18:18.300> need 00:18:18.960 --> 00:18:18.970 align:start position:0% because you also need 00:18:18.970 --> 00:18:22.080 align:start position:0% because you also need wait<00:18:19.210> for<00:18:20.020> the<00:18:20.440> corresponding<00:18:21.280> sworn<00:18:21.580> content 00:18:22.080 --> 00:18:22.090 align:start position:0% wait for the corresponding sworn content 00:18:22.090 --> 00:18:24.360 align:start position:0% wait for the corresponding sworn content to<00:18:22.450> become<00:18:22.750> available<00:18:22.929> for<00:18:23.500> the<00:18:23.919> interested 00:18:24.360 --> 00:18:24.370 align:start position:0% to become available for the interested 00:18:24.370 --> 00:18:28.970 align:start position:0% to become available for the interested parties<00:18:24.789> and<00:18:26.100> instead<00:18:27.100> what<00:18:27.580> you<00:18:27.730> can<00:18:27.940> do<00:18:28.150> is 00:18:28.970 --> 00:18:28.980 align:start position:0% parties and instead what you can do is 00:18:28.980 --> 00:18:32.760 align:start position:0% parties and instead what you can do is you<00:18:29.980> can<00:18:30.190> also<00:18:30.549> include<00:18:31.150> in<00:18:31.539> the<00:18:31.720> updates<00:18:32.200> the 00:18:32.760 --> 00:18:32.770 align:start position:0% you can also include in the updates the 00:18:32.770 --> 00:18:37.320 align:start position:0% you can also include in the updates the actual<00:18:33.280> information<00:18:34.260> that<00:18:35.549> was<00:18:36.549> changed<00:18:37.090> so 00:18:37.320 --> 00:18:37.330 align:start position:0% actual information that was changed so 00:18:37.330 --> 00:18:41.370 align:start position:0% actual information that was changed so for<00:18:37.929> example<00:18:38.559> if<00:18:38.830> a<00:18:39.280> comment<00:18:39.789> was<00:18:40.030> added<00:18:40.539> then 00:18:41.370 --> 00:18:41.380 align:start position:0% for example if a comment was added then 00:18:41.380 --> 00:18:45.390 align:start position:0% for example if a comment was added then in<00:18:41.980> addition<00:18:42.340> to<00:18:42.909> the<00:18:43.179> new<00:18:43.390> -<00:18:43.929> you<00:18:44.530> also<00:18:44.799> send 00:18:45.390 --> 00:18:45.400 align:start position:0% in addition to the new - you also send 00:18:45.400 --> 00:18:48.960 align:start position:0% in addition to the new - you also send around<00:18:45.580> in<00:18:46.140> messages<00:18:47.140> and<00:18:47.350> PSS<00:18:47.770> messages<00:18:48.400> the 00:18:48.960 --> 00:18:48.970 align:start position:0% around in messages and PSS messages the 00:18:48.970 --> 00:18:51.419 align:start position:0% around in messages and PSS messages the actual<00:18:49.450> the<00:18:49.900> actual<00:18:50.020> comment<00:18:50.620> that<00:18:50.770> was<00:18:50.980> added 00:18:51.419 --> 00:18:51.429 align:start position:0% actual the actual comment that was added 00:18:51.429 --> 00:18:54.390 align:start position:0% actual the actual comment that was added so<00:18:52.120> that<00:18:52.330> the<00:18:52.539> nodes<00:18:52.809> that<00:18:53.350> are<00:18:53.679> monitoring 00:18:54.390 --> 00:18:54.400 align:start position:0% so that the nodes that are monitoring 00:18:54.400 --> 00:18:56.789 align:start position:0% so that the nodes that are monitoring the<00:18:54.669> discussion<00:18:55.299> will<00:18:55.990> be<00:18:56.169> able<00:18:56.409> to 00:18:56.789 --> 00:18:56.799 align:start position:0% the discussion will be able to 00:18:56.799 --> 00:18:59.549 align:start position:0% the discussion will be able to immediately<00:18:57.100> update<00:18:58.000> their<00:18:58.390> local<00:18:58.809> model<00:18:59.230> and 00:18:59.549 --> 00:18:59.559 align:start position:0% immediately update their local model and 00:18:59.559 --> 00:19:04.320 align:start position:0% immediately update their local model and yet<00:19:00.490> they<00:19:00.909> can<00:19:01.150> verify<00:19:01.620> whenever<00:19:02.620> the<00:19:03.330> swarm 00:19:04.320 --> 00:19:04.330 align:start position:0% yet they can verify whenever the swarm 00:19:04.330 --> 00:19:07.350 align:start position:0% yet they can verify whenever the swarm of<00:19:04.630> date<00:19:04.840> happens<00:19:05.380> and<00:19:05.620> especially<00:19:06.429> when<00:19:07.179> the 00:19:07.350 --> 00:19:07.360 align:start position:0% of date happens and especially when the 00:19:07.360 --> 00:19:09.570 align:start position:0% of date happens and especially when the blockchain<00:19:07.750> update<00:19:08.289> happens<00:19:08.500> they<00:19:09.340> can 00:19:09.570 --> 00:19:09.580 align:start position:0% blockchain update happens they can 00:19:09.580 --> 00:19:12.390 align:start position:0% blockchain update happens they can verify<00:19:09.850> that<00:19:10.179> they<00:19:10.600> haven't<00:19:10.780> been<00:19:10.990> lied<00:19:11.320> to<00:19:11.400> so 00:19:12.390 --> 00:19:12.400 align:start position:0% verify that they haven't been lied to so 00:19:12.400 --> 00:19:15.779 align:start position:0% verify that they haven't been lied to so this<00:19:13.240> does<00:19:13.539> not<00:19:13.570> present<00:19:14.320> a<00:19:14.590> security<00:19:15.520> problem 00:19:15.779 --> 00:19:15.789 align:start position:0% this does not present a security problem 00:19:15.789 --> 00:19:20.970 align:start position:0% this does not present a security problem it<00:19:16.240> just<00:19:16.990> speeds<00:19:17.230> things<00:19:17.500> up<00:19:17.799> and<00:19:19.380> also<00:19:20.380> I 00:19:20.970 --> 00:19:20.980 align:start position:0% it just speeds things up and also I 00:19:20.980 --> 00:19:25.549 align:start position:0% it just speeds things up and also I would<00:19:21.820> encourage<00:19:22.240> you<00:19:22.770> instead<00:19:23.770> of<00:19:24.539> creating 00:19:25.549 --> 00:19:25.559 align:start position:0% would encourage you instead of creating 00:19:25.559 --> 00:19:30.480 align:start position:0% would encourage you instead of creating very<00:19:26.559> complicated<00:19:27.309> update<00:19:28.000> rules<00:19:28.299> and<00:19:29.490> then 00:19:30.480 --> 00:19:30.490 align:start position:0% very complicated update rules and then 00:19:30.490 --> 00:19:33.840 align:start position:0% very complicated update rules and then you<00:19:30.669> need<00:19:31.080> various<00:19:32.080> ways<00:19:32.770> to<00:19:33.159> actually<00:19:33.429> verify 00:19:33.840 --> 00:19:33.850 align:start position:0% you need various ways to actually verify 00:19:33.850 --> 00:19:38.549 align:start position:0% you need various ways to actually verify that<00:19:34.390> the<00:19:34.570> updates<00:19:34.960> were<00:19:35.789> legal<00:19:36.789> or<00:19:37.380> so<00:19:38.380> they 00:19:38.549 --> 00:19:38.559 align:start position:0% that the updates were legal or so they 00:19:38.559 --> 00:19:42.020 align:start position:0% that the updates were legal or so they were<00:19:38.620> the<00:19:39.309> kind<00:19:39.549> that<00:19:39.760> is<00:19:39.909> allowed<00:19:40.770> instead 00:19:42.020 --> 00:19:42.030 align:start position:0% were the kind that is allowed instead 00:19:42.030 --> 00:19:44.669 align:start position:0% were the kind that is allowed instead what<00:19:43.030> I<00:19:43.059> would<00:19:43.419> suggest<00:19:43.630> is<00:19:44.200> to<00:19:44.500> do 00:19:44.669 --> 00:19:44.679 align:start position:0% what I would suggest is to do 00:19:44.679 --> 00:19:51.450 align:start position:0% what I would suggest is to do aggregation<00:19:45.640> on<00:19:46.120> the<00:19:47.429> on<00:19:48.429> the<00:19:49.950> front<00:19:50.950> end<00:19:51.159> side 00:19:51.450 --> 00:19:51.460 align:start position:0% aggregation on the on the front end side 00:19:51.460 --> 00:19:54.299 align:start position:0% aggregation on the on the front end side so<00:19:52.360> for<00:19:52.570> example<00:19:53.110> if<00:19:53.320> we're<00:19:53.620> looking<00:19:53.650> at<00:19:54.070> a 00:19:54.299 --> 00:19:54.309 align:start position:0% so for example if we're looking at a 00:19:54.309 --> 00:19:57.539 align:start position:0% so for example if we're looking at a online<00:19:54.880> discussion<00:19:55.570> then<00:19:56.380> every<00:19:56.799> participant 00:19:57.539 --> 00:19:57.549 align:start position:0% online discussion then every participant 00:19:57.549 --> 00:20:02.130 align:start position:0% online discussion then every participant would<00:19:58.450> update<00:19:59.380> the<00:20:00.010> route<00:20:00.370> hash<00:20:00.669> of<00:20:01.059> all<00:20:01.900> the 00:20:02.130 --> 00:20:02.140 align:start position:0% would update the route hash of all the 00:20:02.140 --> 00:20:04.500 align:start position:0% would update the route hash of all the comments<00:20:02.679> that<00:20:03.130> they<00:20:03.370> have<00:20:03.640> sent<00:20:04.000> to 00:20:04.500 --> 00:20:04.510 align:start position:0% comments that they have sent to 00:20:04.510 --> 00:20:09.180 align:start position:0% comments that they have sent to different<00:20:04.990> parts<00:20:05.679> of<00:20:05.770> the<00:20:06.809> of<00:20:07.809> the<00:20:08.770> service 00:20:09.180 --> 00:20:09.190 align:start position:0% different parts of the of the service 00:20:09.190 --> 00:20:15.779 align:start position:0% different parts of the of the service and<00:20:11.700> whenever<00:20:12.700> a<00:20:14.159> participant<00:20:15.159> looks<00:20:15.460> at<00:20:15.669> a 00:20:15.779 --> 00:20:15.789 align:start position:0% and whenever a participant looks at a 00:20:15.789 --> 00:20:18.090 align:start position:0% and whenever a participant looks at a particular<00:20:16.360> discussion<00:20:17.049> they<00:20:17.559> should<00:20:17.830> gather 00:20:18.090 --> 00:20:18.100 align:start position:0% particular discussion they should gather 00:20:18.100 --> 00:20:20.430 align:start position:0% particular discussion they should gather the<00:20:18.789> participant<00:20:19.480> the<00:20:19.539> addresses<00:20:20.169> of<00:20:20.320> the 00:20:20.430 --> 00:20:20.440 align:start position:0% the participant the addresses of the 00:20:20.440 --> 00:20:23.070 align:start position:0% the participant the addresses of the participants<00:20:21.130> of<00:20:21.250> that<00:20:21.429> discussion<00:20:21.850> on<00:20:22.270> ENS 00:20:23.070 --> 00:20:23.080 align:start position:0% participants of that discussion on ENS 00:20:23.080 --> 00:20:26.130 align:start position:0% participants of that discussion on ENS and<00:20:23.289> then<00:20:24.250> monitor<00:20:24.970> the<00:20:25.179> updates<00:20:25.600> of<00:20:25.900> those 00:20:26.130 --> 00:20:26.140 align:start position:0% and then monitor the updates of those 00:20:26.140 --> 00:20:29.610 align:start position:0% and then monitor the updates of those participants<00:20:26.890> and<00:20:28.470> independently<00:20:29.470> of<00:20:29.530> each 00:20:29.610 --> 00:20:29.620 align:start position:0% participants and independently of each 00:20:29.620 --> 00:20:32.070 align:start position:0% participants and independently of each other<00:20:29.830> and<00:20:30.190> do<00:20:30.700> the<00:20:30.880> aggregation<00:20:31.390> in 00:20:32.070 --> 00:20:32.080 align:start position:0% other and do the aggregation in 00:20:32.080 --> 00:20:34.860 align:start position:0% other and do the aggregation in to<00:20:32.140> a<00:20:32.169> discussion<00:20:33.269> themselves<00:20:34.269> on<00:20:34.450> the 00:20:34.860 --> 00:20:34.870 align:start position:0% to a discussion themselves on the 00:20:34.870 --> 00:20:38.549 align:start position:0% to a discussion themselves on the client-side<00:20:35.519> so<00:20:36.519> that's<00:20:36.789> a<00:20:37.090> much<00:20:37.750> simpler<00:20:38.260> and 00:20:38.549 --> 00:20:38.559 align:start position:0% client-side so that's a much simpler and 00:20:38.559 --> 00:20:44.669 align:start position:0% client-side so that's a much simpler and much<00:20:39.549> more<00:20:40.230> reliable<00:20:41.230> way<00:20:41.440> of<00:20:43.500> dealing<00:20:44.500> with 00:20:44.669 --> 00:20:44.679 align:start position:0% much more reliable way of dealing with 00:20:44.679 --> 00:20:49.380 align:start position:0% much more reliable way of dealing with concurrent<00:20:45.460> access<00:20:47.370> in<00:20:48.370> the<00:20:48.549> next<00:20:48.850> part<00:20:49.090> I'm 00:20:49.380 --> 00:20:49.390 align:start position:0% concurrent access in the next part I'm 00:20:49.390 --> 00:20:52.759 align:start position:0% concurrent access in the next part I'm going<00:20:49.450> to<00:20:49.809> briefly<00:20:50.260> address<00:20:51.299> issues<00:20:52.299> of 00:20:52.759 --> 00:20:52.769 align:start position:0% going to briefly address issues of 00:20:52.769 --> 00:21:01.230 align:start position:0% going to briefly address issues of reliability<00:20:53.769> and<00:20:54.010> availability<00:20:58.980> so<00:21:00.210> here<00:21:01.210> I 00:21:01.230 --> 00:21:01.240 align:start position:0% reliability and availability so here I 00:21:01.240 --> 00:21:04.529 align:start position:0% reliability and availability so here I would<00:21:01.630> like<00:21:01.840> to<00:21:02.140> go<00:21:02.320> back<00:21:02.399> to<00:21:03.399> the<00:21:03.610> things<00:21:04.269> that 00:21:04.529 --> 00:21:04.539 align:start position:0% would like to go back to the things that 00:21:04.539 --> 00:21:08.430 align:start position:0% would like to go back to the things that I<00:21:04.570> said<00:21:04.750> about<00:21:06.539> about<00:21:07.539> distributed 00:21:08.430 --> 00:21:08.440 align:start position:0% I said about about distributed 00:21:08.440 --> 00:21:11.879 align:start position:0% I said about about distributed applications<00:21:09.269> whenever<00:21:10.269> possible<00:21:10.889> you 00:21:11.879 --> 00:21:11.889 align:start position:0% applications whenever possible you 00:21:11.889 --> 00:21:14.909 align:start position:0% applications whenever possible you should<00:21:11.919> not<00:21:12.460> try<00:21:13.000> to<00:21:13.029> build<00:21:13.809> your<00:21:14.679> own 00:21:14.909 --> 00:21:14.919 align:start position:0% should not try to build your own 00:21:14.919 --> 00:21:18.350 align:start position:0% should not try to build your own infrastructure<00:21:15.720> try<00:21:16.720> to<00:21:16.779> rely<00:21:17.289> on<00:21:17.620> generic 00:21:18.350 --> 00:21:18.360 align:start position:0% infrastructure try to rely on generic 00:21:18.360 --> 00:21:19.529 align:start position:0% infrastructure try to rely on generic infrastructure 00:21:19.529 --> 00:21:19.539 align:start position:0% infrastructure 00:21:19.539 --> 00:21:22.110 align:start position:0% infrastructure because<00:21:20.169> that<00:21:20.440> way<00:21:20.710> it<00:21:21.279> becomes<00:21:21.460> somebody 00:21:22.110 --> 00:21:22.120 align:start position:0% because that way it becomes somebody 00:21:22.120 --> 00:21:25.590 align:start position:0% because that way it becomes somebody else's<00:21:22.539> problem<00:21:23.669> so<00:21:24.669> in<00:21:24.940> order<00:21:25.120> for<00:21:25.299> a 00:21:25.590 --> 00:21:25.600 align:start position:0% else's problem so in order for a 00:21:25.600 --> 00:21:28.560 align:start position:0% else's problem so in order for a distributed<00:21:26.320> system<00:21:26.559> to<00:21:27.039> work<00:21:27.220> well<00:21:27.580> it<00:21:28.269> would 00:21:28.560 --> 00:21:28.570 align:start position:0% distributed system to work well it would 00:21:28.570 --> 00:21:30.720 align:start position:0% distributed system to work well it would it<00:21:28.779> needs<00:21:29.049> to<00:21:29.320> have<00:21:29.529> a<00:21:29.559> sufficient<00:21:30.279> number<00:21:30.429> of 00:21:30.720 --> 00:21:30.730 align:start position:0% it needs to have a sufficient number of 00:21:30.730 --> 00:21:32.730 align:start position:0% it needs to have a sufficient number of nodes<00:21:31.029> those<00:21:31.690> nodes<00:21:32.080> need<00:21:32.320> to<00:21:32.350> have 00:21:32.730 --> 00:21:32.740 align:start position:0% nodes those nodes need to have 00:21:32.740 --> 00:21:36.149 align:start position:0% nodes those nodes need to have sufficient<00:21:33.659> incentives<00:21:34.659> they<00:21:35.620> have<00:21:35.889> they 00:21:36.149 --> 00:21:36.159 align:start position:0% sufficient incentives they have they 00:21:36.159 --> 00:21:39.720 align:start position:0% sufficient incentives they have they need<00:21:36.370> to<00:21:36.580> have<00:21:36.789> adequate<00:21:37.330> resources<00:21:37.360> each<00:21:38.730> and 00:21:39.720 --> 00:21:39.730 align:start position:0% need to have adequate resources each and 00:21:39.730 --> 00:21:44.870 align:start position:0% need to have adequate resources each and all<00:21:40.570> these<00:21:40.809> things<00:21:41.169> they<00:21:41.860> are<00:21:41.889> difficult<00:21:42.659> so 00:21:44.870 --> 00:21:44.880 align:start position:0% all these things they are difficult so 00:21:44.880 --> 00:21:48.870 align:start position:0% all these things they are difficult so for<00:21:45.880> example<00:21:46.450> if<00:21:46.659> you<00:21:46.960> only<00:21:47.260> use<00:21:47.620> swarm<00:21:48.580> as<00:21:48.820> a 00:21:48.870 --> 00:21:48.880 align:start position:0% for example if you only use swarm as a 00:21:48.880 --> 00:21:52.379 align:start position:0% for example if you only use swarm as a generic<00:21:49.720> information<00:21:49.889> storing<00:21:51.389> framework 00:21:52.379 --> 00:21:52.389 align:start position:0% generic information storing framework 00:21:52.389 --> 00:21:55.710 align:start position:0% generic information storing framework then<00:21:53.019> making<00:21:53.289> sure<00:21:53.500> that<00:21:54.490> swarm<00:21:54.940> content<00:21:55.480> will 00:21:55.710 --> 00:21:55.720 align:start position:0% then making sure that swarm content will 00:21:55.720 --> 00:21:58.580 align:start position:0% then making sure that swarm content will be<00:21:55.750> available<00:21:56.529> is<00:21:56.860> our<00:21:57.250> problem<00:21:57.610> as 00:21:58.580 --> 00:21:58.590 align:start position:0% be available is our problem as 00:21:58.590 --> 00:22:01.049 align:start position:0% be available is our problem as infrastructure<00:21:59.590> developers<00:22:00.309> it's<00:22:00.580> not<00:22:00.820> your 00:22:01.049 --> 00:22:01.059 align:start position:0% infrastructure developers it's not your 00:22:01.059 --> 00:22:05.570 align:start position:0% infrastructure developers it's not your problem<00:22:01.389> as<00:22:01.750> an<00:22:01.929> application<00:22:02.350> developer<00:22:02.789> and 00:22:05.570 --> 00:22:05.580 align:start position:0% problem as an application developer and 00:22:05.580 --> 00:22:10.769 align:start position:0% problem as an application developer and in<00:22:06.580> general<00:22:07.240> so<00:22:07.840> there's<00:22:08.200> a<00:22:09.179> reliability<00:22:10.179> kind 00:22:10.769 --> 00:22:10.779 align:start position:0% in general so there's a reliability kind 00:22:10.779 --> 00:22:15.389 align:start position:0% in general so there's a reliability kind of<00:22:11.019> ranking<00:22:11.590> between<00:22:12.399> these<00:22:12.970> services<00:22:13.740> so<00:22:14.740> ETH 00:22:15.389 --> 00:22:15.399 align:start position:0% of ranking between these services so ETH 00:22:15.399 --> 00:22:18.450 align:start position:0% of ranking between these services so ETH is<00:22:15.880> the<00:22:16.299> most<00:22:16.510> reliable<00:22:17.010> light<00:22:18.010> client 00:22:18.450 --> 00:22:18.460 align:start position:0% is the most reliable light client 00:22:18.460 --> 00:22:24.509 align:start position:0% is the most reliable light client protocol<00:22:19.000> is<00:22:19.179> less<00:22:19.450> reliable<00:22:22.799> bzz<00:22:23.799> is<00:22:24.010> even 00:22:24.509 --> 00:22:24.519 align:start position:0% protocol is less reliable bzz is even 00:22:24.519 --> 00:22:26.700 align:start position:0% protocol is less reliable bzz is even less<00:22:24.730> reliable<00:22:25.149> and<00:22:25.480> PSS<00:22:26.049> is<00:22:26.230> the<00:22:26.470> least 00:22:26.700 --> 00:22:26.710 align:start position:0% less reliable and PSS is the least 00:22:26.710 --> 00:22:31.200 align:start position:0% less reliable and PSS is the least reliable<00:22:27.070> of<00:22:27.549> these<00:22:29.159> generic<00:22:30.210> services 00:22:31.200 --> 00:22:31.210 align:start position:0% reliable of these generic services 00:22:31.210 --> 00:22:34.830 align:start position:0% reliable of these generic services simply<00:22:32.169> because<00:22:32.740> of<00:22:33.130> the<00:22:33.490> popularity<00:22:33.940> of<00:22:34.269> the 00:22:34.830 --> 00:22:34.840 align:start position:0% simply because of the popularity of the 00:22:34.840 --> 00:22:37.500 align:start position:0% simply because of the popularity of the of<00:22:35.500> that<00:22:35.889> particular<00:22:36.549> service<00:22:37.059> on<00:22:37.389> the 00:22:37.500 --> 00:22:37.510 align:start position:0% of that particular service on the 00:22:37.510 --> 00:22:40.110 align:start position:0% of that particular service on the etherium<00:22:37.899> network<00:22:38.320> and<00:22:38.529> if<00:22:39.220> you<00:22:39.490> do<00:22:39.730> something 00:22:40.110 --> 00:22:40.120 align:start position:0% etherium network and if you do something 00:22:40.120 --> 00:22:43.139 align:start position:0% etherium network and if you do something yourself<00:22:40.510> it<00:22:41.200> will<00:22:41.679> be<00:22:41.889> way<00:22:42.190> way<00:22:42.580> way<00:22:42.880> behind 00:22:43.139 --> 00:22:43.149 align:start position:0% yourself it will be way way way behind 00:22:43.149 --> 00:22:43.790 align:start position:0% yourself it will be way way way behind all 00:22:43.790 --> 00:22:43.800 align:start position:0% all 00:22:43.800 --> 00:22:52.220 align:start position:0% all these<00:22:43.920> on<00:22:44.220> the<00:22:44.700> reliability<00:22:44.940> scale<00:22:49.850> so<00:22:51.230> also 00:22:52.220 --> 00:22:52.230 align:start position:0% these on the reliability scale so also 00:22:52.230 --> 00:22:56.150 align:start position:0% these on the reliability scale so also you<00:22:52.980> should<00:22:53.280> keep<00:22:53.850> in<00:22:54.060> mind<00:22:54.090> that<00:22:54.980> the<00:22:55.980> only 00:22:56.150 --> 00:22:56.160 align:start position:0% you should keep in mind that the only 00:22:56.160 --> 00:22:58.160 align:start position:0% you should keep in mind that the only thing<00:22:56.640> that<00:22:56.880> is<00:22:57.030> certain<00:22:57.300> is<00:22:57.630> the<00:22:57.900> blockchain 00:22:58.160 --> 00:22:58.170 align:start position:0% thing that is certain is the blockchain 00:22:58.170 --> 00:23:01.370 align:start position:0% thing that is certain is the blockchain everything<00:22:59.160> else<00:22:59.400> is<00:22:59.730> ephemeral<00:23:00.210> so<00:23:01.170> if 00:23:01.370 --> 00:23:01.380 align:start position:0% everything else is ephemeral so if 00:23:01.380 --> 00:23:04.030 align:start position:0% everything else is ephemeral so if there's<00:23:01.650> some<00:23:01.950> important<00:23:02.610> state<00:23:02.910> update 00:23:04.030 --> 00:23:04.040 align:start position:0% there's some important state update 00:23:04.040 --> 00:23:06.740 align:start position:0% there's some important state update eventually<00:23:05.040> you<00:23:05.220> have<00:23:05.370> to<00:23:05.430> make<00:23:05.760> sure<00:23:05.790> that<00:23:06.570> it 00:23:06.740 --> 00:23:06.750 align:start position:0% eventually you have to make sure that it 00:23:06.750 --> 00:23:11.090 align:start position:0% eventually you have to make sure that it reaches<00:23:07.230> the<00:23:07.590> blockchain<00:23:07.830> and<00:23:08.780> finally<00:23:10.100> you 00:23:11.090 --> 00:23:11.100 align:start position:0% reaches the blockchain and finally you 00:23:11.100 --> 00:23:16.120 align:start position:0% reaches the blockchain and finally you should<00:23:11.160> be<00:23:12.080> paying<00:23:13.080> attention<00:23:13.340> to<00:23:14.340> incentives 00:23:16.120 --> 00:23:16.130 align:start position:0% should be paying attention to incentives 00:23:16.130 --> 00:23:19.850 align:start position:0% should be paying attention to incentives so<00:23:17.130> in<00:23:18.120> case<00:23:18.510> if<00:23:18.810> you<00:23:18.870> want<00:23:19.080> to<00:23:19.440> enforce 00:23:19.850 --> 00:23:19.860 align:start position:0% so in case if you want to enforce 00:23:19.860 --> 00:23:23.390 align:start position:0% so in case if you want to enforce compliant<00:23:20.550> behavior<00:23:21.320> then<00:23:22.320> the<00:23:22.680> two<00:23:23.040> tricks 00:23:23.390 --> 00:23:23.400 align:start position:0% compliant behavior then the two tricks 00:23:23.400 --> 00:23:27.370 align:start position:0% compliant behavior then the two tricks that<00:23:24.180> can<00:23:24.900> make<00:23:25.770> things<00:23:26.040> more<00:23:26.400> scalable<00:23:26.730> is 00:23:27.370 --> 00:23:27.380 align:start position:0% that can make things more scalable is 00:23:27.380 --> 00:23:31.850 align:start position:0% that can make things more scalable is instead<00:23:28.380> of<00:23:28.440> using<00:23:29.420> pre-emptive<00:23:30.420> measures<00:23:30.900> so 00:23:31.850 --> 00:23:31.860 align:start position:0% instead of using pre-emptive measures so 00:23:31.860 --> 00:23:35.660 align:start position:0% instead of using pre-emptive measures so writing<00:23:33.110> complicated<00:23:34.110> contract<00:23:34.650> code<00:23:34.890> that 00:23:35.660 --> 00:23:35.670 align:start position:0% writing complicated contract code that 00:23:35.670 --> 00:23:40.040 align:start position:0% writing complicated contract code that can<00:23:36.000> only<00:23:37.460> drive<00:23:38.460> the<00:23:38.490> application<00:23:39.450> mechanics 00:23:40.040 --> 00:23:40.050 align:start position:0% can only drive the application mechanics 00:23:40.050 --> 00:23:42.410 align:start position:0% can only drive the application mechanics as<00:23:40.260> the<00:23:40.950> smart<00:23:41.250> contract<00:23:41.460> executes<00:23:42.390> that 00:23:42.410 --> 00:23:42.420 align:start position:0% as the smart contract executes that 00:23:42.420 --> 00:23:45.980 align:start position:0% as the smart contract executes that block<00:23:42.900> time<00:23:43.190> instead<00:23:44.190> you<00:23:44.880> can<00:23:45.060> use<00:23:45.120> reactive 00:23:45.980 --> 00:23:45.990 align:start position:0% block time instead you can use reactive 00:23:45.990 --> 00:23:48.440 align:start position:0% block time instead you can use reactive security<00:23:46.650> that<00:23:46.860> everybody<00:23:47.370> updates<00:23:47.940> the<00:23:48.300> way 00:23:48.440 --> 00:23:48.450 align:start position:0% security that everybody updates the way 00:23:48.450 --> 00:23:53.120 align:start position:0% security that everybody updates the way they<00:23:48.780> the<00:23:49.650> way<00:23:49.800> they<00:23:50.010> can<00:23:50.310> locally<00:23:51.650> however<00:23:52.650> if 00:23:53.120 --> 00:23:53.130 align:start position:0% they the way they can locally however if 00:23:53.130 --> 00:23:56.240 align:start position:0% they the way they can locally however if there's<00:23:54.060> some<00:23:54.330> dispute<00:23:54.600> then<00:23:55.560> you<00:23:55.800> can<00:23:56.010> turn 00:23:56.240 --> 00:23:56.250 align:start position:0% there's some dispute then you can turn 00:23:56.250 --> 00:23:58.820 align:start position:0% there's some dispute then you can turn to<00:23:56.520> the<00:23:56.640> blockchain<00:23:56.910> and<00:23:57.510> figure<00:23:58.350> out<00:23:58.410> who's 00:23:58.820 --> 00:23:58.830 align:start position:0% to the blockchain and figure out who's 00:23:58.830 --> 00:24:02.590 align:start position:0% to the blockchain and figure out who's right<00:23:59.100> and<00:23:59.130> who's<00:23:59.400> wrong<00:23:59.550> and<00:24:00.060> this<00:24:00.510> way<00:24:01.460> if 00:24:02.590 --> 00:24:02.600 align:start position:0% right and who's wrong and this way if 00:24:02.600 --> 00:24:05.570 align:start position:0% right and who's wrong and this way if everything<00:24:03.600> happens<00:24:03.840> correctly<00:24:04.340> you<00:24:05.340> rarely 00:24:05.570 --> 00:24:05.580 align:start position:0% everything happens correctly you rarely 00:24:05.580 --> 00:24:07.760 align:start position:0% everything happens correctly you rarely touch<00:24:06.030> the<00:24:06.330> blockchain<00:24:06.570> so<00:24:07.110> that<00:24:07.320> helps<00:24:07.680> you 00:24:07.760 --> 00:24:07.770 align:start position:0% touch the blockchain so that helps you 00:24:07.770 --> 00:24:10.220 align:start position:0% touch the blockchain so that helps you scale<00:24:08.130> so<00:24:08.730> instead<00:24:09.120> of<00:24:09.180> using<00:24:09.480> proactive 00:24:10.220 --> 00:24:10.230 align:start position:0% scale so instead of using proactive 00:24:10.230 --> 00:24:12.320 align:start position:0% scale so instead of using proactive security<00:24:10.800> measures<00:24:11.160> you<00:24:11.490> use<00:24:11.670> reactive 00:24:12.320 --> 00:24:12.330 align:start position:0% security measures you use reactive 00:24:12.330 --> 00:24:19.400 align:start position:0% security measures you use reactive security<00:24:14.810> and<00:24:16.100> the<00:24:17.390> you<00:24:18.390> only<00:24:18.840> bother<00:24:19.080> the 00:24:19.400 --> 00:24:19.410 align:start position:0% security and the you only bother the 00:24:19.410 --> 00:24:24.140 align:start position:0% security and the you only bother the blockchain<00:24:19.650> in<00:24:20.250> case<00:24:20.730> of<00:24:21.060> disputes<00:24:22.730> and<00:24:23.730> the 00:24:24.140 --> 00:24:24.150 align:start position:0% blockchain in case of disputes and the 00:24:24.150 --> 00:24:27.970 align:start position:0% blockchain in case of disputes and the final<00:24:24.630> part<00:24:24.840> of<00:24:24.990> my<00:24:25.170> talk<00:24:25.230> I<00:24:25.740> would<00:24:25.830> like<00:24:26.250> to 00:24:27.970 --> 00:24:27.980 align:start position:0% final part of my talk I would like to 00:24:27.980 --> 00:24:34.810 align:start position:0% final part of my talk I would like to introduce<00:24:29.300> some<00:24:30.300> ways<00:24:30.600> of<00:24:33.440> maintaining<00:24:34.440> and 00:24:34.810 --> 00:24:34.820 align:start position:0% introduce some ways of maintaining and 00:24:34.820 --> 00:24:38.540 align:start position:0% introduce some ways of maintaining and improving<00:24:35.840> and<00:24:36.840> developing<00:24:37.710> and<00:24:38.430> adding 00:24:38.540 --> 00:24:38.550 align:start position:0% improving and developing and adding 00:24:38.550 --> 00:24:43.160 align:start position:0% improving and developing and adding feature<00:24:39.000> to<00:24:39.420> a<00:24:39.450> distributed<00:24:40.080> application<00:24:42.170> it 00:24:43.160 --> 00:24:43.170 align:start position:0% feature to a distributed application it 00:24:43.170 --> 00:24:45.710 align:start position:0% feature to a distributed application it is<00:24:43.410> very<00:24:43.800> different<00:24:44.370> from<00:24:44.700> from<00:24:45.570> the 00:24:45.710 --> 00:24:45.720 align:start position:0% is very different from from the 00:24:45.720 --> 00:24:48.350 align:start position:0% is very different from from the client-server<00:24:46.230> model<00:24:46.640> because<00:24:47.640> in<00:24:48.000> a 00:24:48.350 --> 00:24:48.360 align:start position:0% client-server model because in a 00:24:48.360 --> 00:24:50.030 align:start position:0% client-server model because in a client-server<00:24:49.140> model<00:24:49.170> you<00:24:49.680> can<00:24:49.890> do 00:24:50.030 --> 00:24:50.040 align:start position:0% client-server model you can do 00:24:50.040 --> 00:24:53.600 align:start position:0% client-server model you can do everything<00:24:50.340> on<00:24:50.640> the<00:24:50.790> server<00:24:51.090> and<00:24:52.340> you<00:24:53.340> don't 00:24:53.600 --> 00:24:53.610 align:start position:0% everything on the server and you don't 00:24:53.610 --> 00:24:54.750 align:start position:0% everything on the server and you don't have<00:24:53.850> to 00:24:54.750 --> 00:24:54.760 align:start position:0% have to 00:24:54.760 --> 00:24:59.620 align:start position:0% have to consider<00:24:55.760> the<00:24:56.090> fact<00:24:56.360> that<00:24:57.549> your<00:24:58.630> application 00:24:59.620 --> 00:24:59.630 align:start position:0% consider the fact that your application 00:24:59.630 --> 00:25:03.450 align:start position:0% consider the fact that your application is<00:24:59.809> not<00:24:59.870> entirely<00:25:00.679> under<00:25:01.220> your<00:25:01.429> control<00:25:02.080> so 00:25:03.450 --> 00:25:03.460 align:start position:0% is not entirely under your control so 00:25:03.460 --> 00:25:06.870 align:start position:0% is not entirely under your control so when<00:25:04.460> you're<00:25:04.669> rolling<00:25:05.120> out<00:25:05.270> a<00:25:05.330> new<00:25:05.570> version 00:25:06.870 --> 00:25:06.880 align:start position:0% when you're rolling out a new version 00:25:06.880 --> 00:25:10.690 align:start position:0% when you're rolling out a new version obviously<00:25:07.880> you<00:25:08.809> need<00:25:09.020> to<00:25:09.260> update<00:25:09.440> ENS<00:25:10.250> to 00:25:10.690 --> 00:25:10.700 align:start position:0% obviously you need to update ENS to 00:25:10.700 --> 00:25:13.270 align:start position:0% obviously you need to update ENS to point<00:25:11.000> to<00:25:11.480> the<00:25:11.630> root<00:25:12.380> hash<00:25:12.620> of<00:25:12.919> the<00:25:13.130> new 00:25:13.270 --> 00:25:13.280 align:start position:0% point to the root hash of the new 00:25:13.280 --> 00:25:17.799 align:start position:0% point to the root hash of the new version<00:25:13.750> but<00:25:14.750> also<00:25:14.919> you<00:25:15.919> need<00:25:16.159> somehow<00:25:16.940> to 00:25:17.799 --> 00:25:17.809 align:start position:0% version but also you need somehow to 00:25:17.809 --> 00:25:21.220 align:start position:0% version but also you need somehow to notify<00:25:18.409> all<00:25:18.679> the<00:25:18.950> active<00:25:19.990> users<00:25:20.990> of<00:25:21.020> your 00:25:21.220 --> 00:25:21.230 align:start position:0% notify all the active users of your 00:25:21.230 --> 00:25:23.289 align:start position:0% notify all the active users of your application<00:25:22.070> that<00:25:22.100> things<00:25:22.549> have<00:25:22.789> changed 00:25:23.289 --> 00:25:23.299 align:start position:0% application that things have changed 00:25:23.299 --> 00:25:25.480 align:start position:0% application that things have changed because<00:25:23.900> otherwise<00:25:24.200> they<00:25:25.010> just<00:25:25.280> keep 00:25:25.480 --> 00:25:25.490 align:start position:0% because otherwise they just keep 00:25:25.490 --> 00:25:28.299 align:start position:0% because otherwise they just keep continuing<00:25:26.210> using<00:25:26.630> the<00:25:26.809> old<00:25:26.929> the<00:25:27.650> old<00:25:27.799> version 00:25:28.299 --> 00:25:28.309 align:start position:0% continuing using the old the old version 00:25:28.309 --> 00:25:31.090 align:start position:0% continuing using the old the old version and<00:25:28.490> it<00:25:29.150> might<00:25:29.360> even<00:25:29.630> interfere<00:25:30.530> with<00:25:30.950> the 00:25:31.090 --> 00:25:31.100 align:start position:0% and it might even interfere with the 00:25:31.100 --> 00:25:33.730 align:start position:0% and it might even interfere with the workings<00:25:31.520> of<00:25:31.669> the<00:25:31.850> new<00:25:32.000> version<00:25:32.380> so<00:25:33.380> in<00:25:33.530> this 00:25:33.730 --> 00:25:33.740 align:start position:0% workings of the new version so in this 00:25:33.740 --> 00:25:35.529 align:start position:0% workings of the new version so in this way<00:25:34.010> it<00:25:34.309> is<00:25:34.340> very<00:25:34.640> different<00:25:35.270> from 00:25:35.529 --> 00:25:35.539 align:start position:0% way it is very different from 00:25:35.539 --> 00:25:40.390 align:start position:0% way it is very different from client-server<00:25:36.260> application<00:25:37.450> also<00:25:39.039> with<00:25:40.039> apps 00:25:40.390 --> 00:25:40.400 align:start position:0% client-server application also with apps 00:25:40.400 --> 00:25:43.299 align:start position:0% client-server application also with apps we<00:25:41.030> have<00:25:41.240> the<00:25:41.480> same<00:25:41.750> thing<00:25:42.110> as<00:25:42.350> what<00:25:42.860> we<00:25:42.890> have 00:25:43.299 --> 00:25:43.309 align:start position:0% we have the same thing as what we have 00:25:43.309 --> 00:25:47.620 align:start position:0% we have the same thing as what we have with<00:25:44.260> block<00:25:45.260> chains<00:25:45.590> we<00:25:45.980> can<00:25:46.159> have<00:25:46.370> Forks<00:25:46.789> it's 00:25:47.620 --> 00:25:47.630 align:start position:0% with block chains we can have Forks it's 00:25:47.630 --> 00:25:50.470 align:start position:0% with block chains we can have Forks it's entirely<00:25:48.110> feasible<00:25:48.470> that<00:25:49.280> somebody<00:25:49.789> likes<00:25:50.150> a 00:25:50.470 --> 00:25:50.480 align:start position:0% entirely feasible that somebody likes a 00:25:50.480 --> 00:25:53.890 align:start position:0% entirely feasible that somebody likes a particular<00:25:51.230> version<00:25:51.530> over<00:25:52.490> that<00:25:52.850> and<00:25:53.179> they 00:25:53.890 --> 00:25:53.900 align:start position:0% particular version over that and they 00:25:53.900 --> 00:25:57.909 align:start position:0% particular version over that and they register<00:25:54.590> it<00:25:54.740> under<00:25:55.730> their<00:25:56.330> own<00:25:56.919> iana's 00:25:57.909 --> 00:25:57.919 align:start position:0% register it under their own iana's 00:25:57.919 --> 00:26:01.390 align:start position:0% register it under their own iana's domain<00:25:58.309> and<00:25:59.020> people<00:26:00.020> keep<00:26:00.230> using<00:26:00.260> that<00:26:00.650> so 00:26:01.390 --> 00:26:01.400 align:start position:0% domain and people keep using that so 00:26:01.400 --> 00:26:03.850 align:start position:0% domain and people keep using that so whenever<00:26:01.700> you<00:26:01.970> introduce<00:26:02.150> a<00:26:02.659> change<00:26:03.020> that<00:26:03.740> the 00:26:03.850 --> 00:26:03.860 align:start position:0% whenever you introduce a change that the 00:26:03.860 --> 00:26:05.919 align:start position:0% whenever you introduce a change that the community<00:26:04.460> disagrees<00:26:05.000> will<00:26:05.240> or<00:26:05.480> at<00:26:05.570> least<00:26:05.780> a 00:26:05.919 --> 00:26:05.929 align:start position:0% community disagrees will or at least a 00:26:05.929 --> 00:26:07.600 align:start position:0% community disagrees will or at least a large<00:26:06.110> part<00:26:06.440> of<00:26:06.530> the<00:26:06.650> community<00:26:06.770> disagrees 00:26:07.600 --> 00:26:07.610 align:start position:0% large part of the community disagrees 00:26:07.610 --> 00:26:11.169 align:start position:0% large part of the community disagrees with<00:26:07.780> you<00:26:08.780> will<00:26:08.990> have<00:26:09.169> Forks<00:26:09.679> I<00:26:10.460> think<00:26:11.000> I'm 00:26:11.169 --> 00:26:11.179 align:start position:0% with you will have Forks I think I'm 00:26:11.179 --> 00:26:14.289 align:start position:0% with you will have Forks I think I'm running<00:26:11.360> out<00:26:11.630> of<00:26:11.690> time<00:26:12.340> so<00:26:13.340> the<00:26:13.789> last<00:26:13.970> thing 00:26:14.289 --> 00:26:14.299 align:start position:0% running out of time so the last thing 00:26:14.299 --> 00:26:16.299 align:start position:0% running out of time so the last thing that<00:26:14.330> I<00:26:14.539> wanted<00:26:14.960> to<00:26:15.020> mention<00:26:15.289> is<00:26:15.650> analytics 00:26:16.299 --> 00:26:16.309 align:start position:0% that I wanted to mention is analytics 00:26:16.309 --> 00:26:20.049 align:start position:0% that I wanted to mention is analytics which<00:26:16.580> is<00:26:16.760> much<00:26:17.000> more<00:26:17.210> difficult<00:26:18.010> than<00:26:19.010> in<00:26:19.909> a 00:26:20.049 --> 00:26:20.059 align:start position:0% which is much more difficult than in a 00:26:20.059 --> 00:26:22.330 align:start position:0% which is much more difficult than in a centralized<00:26:20.600> environment<00:26:21.350> and<00:26:21.590> it's<00:26:21.770> ADAP<00:26:22.159> in 00:26:22.330 --> 00:26:22.340 align:start position:0% centralized environment and it's ADAP in 00:26:22.340 --> 00:26:24.610 align:start position:0% centralized environment and it's ADAP in itself<00:26:22.730> that<00:26:23.059> will<00:26:23.270> be<00:26:23.510> eventually<00:26:23.900> developed 00:26:24.610 --> 00:26:24.620 align:start position:0% itself that will be eventually developed 00:26:24.620 --> 00:26:26.649 align:start position:0% itself that will be eventually developed but<00:26:25.159> unfortunately<00:26:25.940> I<00:26:25.970> ran<00:26:26.120> out<00:26:26.240> of<00:26:26.270> time<00:26:26.450> so 00:26:26.649 --> 00:26:26.659 align:start position:0% but unfortunately I ran out of time so 00:26:26.659 --> 00:26:28.480 align:start position:0% but unfortunately I ran out of time so if<00:26:26.960> you<00:26:27.020> want<00:26:27.289> to<00:26:27.409> talk<00:26:27.590> about<00:26:27.620> analytics 00:26:28.480 --> 00:26:28.490 align:start position:0% if you want to talk about analytics 00:26:28.490 --> 00:26:31.500 align:start position:0% if you want to talk about analytics please<00:26:29.059> see<00:26:29.360> me<00:26:29.539> in<00:26:30.080> Saturday<00:26:30.860> at<00:26:31.070> the 00:26:31.500 --> 00:26:31.510 align:start position:0% please see me in Saturday at the 00:26:31.510 --> 00:26:34.950 align:start position:0% please see me in Saturday at the breakout<00:26:32.510> session<00:26:32.960> thank<00:26:33.830> you 00:26:34.950 --> 00:26:34.960 align:start position:0% breakout session thank you 00:26:34.960 --> 00:26:39.820 align:start position:0% breakout session thank you you 00:26:39.820 --> 00:26:39.830 align:start position:0% 00:26:39.830 --> 00:26:47.410 align:start position:0% [Music]