WEBVTT Kind: captions Language: en 00:00:05.070 --> 00:00:16.310 align:start position:0% [Music] 00:00:16.310 --> 00:00:16.320 align:start position:0% 00:00:16.320 --> 00:00:18.269 align:start position:0% I've<00:00:16.480> been<00:00:16.680> working<00:00:17.119> on<00:00:17.279> the<00:00:17.439> like<00:00:17.720> client 00:00:18.269 --> 00:00:18.279 align:start position:0% I've been working on the like client 00:00:18.279 --> 00:00:20.550 align:start position:0% I've been working on the like client implementation<00:00:19.279> and<00:00:19.439> in<00:00:19.560> this<00:00:19.800> presentation 00:00:20.550 --> 00:00:20.560 align:start position:0% implementation and in this presentation 00:00:20.560 --> 00:00:22.150 align:start position:0% implementation and in this presentation I<00:00:20.640> would<00:00:20.840> like<00:00:20.960> to<00:00:21.119> talk<00:00:21.359> about<00:00:21.640> how<00:00:21.840> far<00:00:22.039> we 00:00:22.150 --> 00:00:22.160 align:start position:0% I would like to talk about how far we 00:00:22.160 --> 00:00:23.830 align:start position:0% I would like to talk about how far we have<00:00:22.320> already<00:00:22.640> progressed<00:00:23.080> with<00:00:23.240> that<00:00:23.680> and 00:00:23.830 --> 00:00:23.840 align:start position:0% have already progressed with that and 00:00:23.840 --> 00:00:29.189 align:start position:0% have already progressed with that and also<00:00:24.599> uh<00:00:25.199> discuss<00:00:25.720> the<00:00:26.439> uh<00:00:27.199> future<00:00:28.039> uh<00:00:28.679> ways<00:00:28.920> of 00:00:29.189 --> 00:00:29.199 align:start position:0% also uh discuss the uh future uh ways of 00:00:29.199 --> 00:00:32.310 align:start position:0% also uh discuss the uh future uh ways of uh<00:00:29.320> development<00:00:30.279> concerning<00:00:31.320> scalability 00:00:32.310 --> 00:00:32.320 align:start position:0% uh development concerning scalability 00:00:32.320 --> 00:00:33.510 align:start position:0% uh development concerning scalability security<00:00:32.800> and 00:00:33.510 --> 00:00:33.520 align:start position:0% security and 00:00:33.520 --> 00:00:35.630 align:start position:0% security and decentralization<00:00:34.520> I<00:00:34.600> am<00:00:34.760> proud<00:00:34.960> to<00:00:35.160> announce 00:00:35.630 --> 00:00:35.640 align:start position:0% decentralization I am proud to announce 00:00:35.640 --> 00:00:38.069 align:start position:0% decentralization I am proud to announce that<00:00:35.879> we<00:00:36.480> already<00:00:36.840> have<00:00:37.079> a<00:00:37.280> proof<00:00:37.520> of<00:00:37.680> concept 00:00:38.069 --> 00:00:38.079 align:start position:0% that we already have a proof of concept 00:00:38.079 --> 00:00:39.950 align:start position:0% that we already have a proof of concept implementation<00:00:39.000> of<00:00:39.120> the<00:00:39.280> light<00:00:39.520> client 00:00:39.950 --> 00:00:39.960 align:start position:0% implementation of the light client 00:00:39.960 --> 00:00:42.229 align:start position:0% implementation of the light client protocol<00:00:40.960> as<00:00:41.120> many<00:00:41.320> of<00:00:41.399> you<00:00:41.600> probably<00:00:41.920> already 00:00:42.229 --> 00:00:42.239 align:start position:0% protocol as many of you probably already 00:00:42.239 --> 00:00:44.990 align:start position:0% protocol as many of you probably already know<00:00:43.039> a<00:00:43.440> the<00:00:43.640> purpose<00:00:43.920> of<00:00:44.039> a<00:00:44.239> light<00:00:44.480> client<00:00:44.920> is 00:00:44.990 --> 00:00:45.000 align:start position:0% know a the purpose of a light client is 00:00:45.000 --> 00:00:47.069 align:start position:0% know a the purpose of a light client is to<00:00:45.239> Pro<00:00:45.520> provide<00:00:46.039> safe<00:00:46.399> access<00:00:46.680> to<00:00:46.879> the 00:00:47.069 --> 00:00:47.079 align:start position:0% to Pro provide safe access to the 00:00:47.079 --> 00:00:49.470 align:start position:0% to Pro provide safe access to the ethereum<00:00:47.559> network<00:00:48.320> without<00:00:48.680> having<00:00:48.920> to<00:00:49.360> uh 00:00:49.470 --> 00:00:49.480 align:start position:0% ethereum network without having to uh 00:00:49.480 --> 00:00:51.830 align:start position:0% ethereum network without having to uh download<00:00:49.840> and<00:00:50.000> process<00:00:50.360> every<00:00:50.559> block<00:00:51.160> and<00:00:51.480> uh 00:00:51.830 --> 00:00:51.840 align:start position:0% download and process every block and uh 00:00:51.840 --> 00:00:54.069 align:start position:0% download and process every block and uh keep<00:00:52.160> and<00:00:52.440> update<00:00:52.879> an<00:00:53.079> entire<00:00:53.480> copy<00:00:53.760> of<00:00:53.920> the 00:00:54.069 --> 00:00:54.079 align:start position:0% keep and update an entire copy of the 00:00:54.079 --> 00:00:56.750 align:start position:0% keep and update an entire copy of the state 00:00:56.750 --> 00:00:56.760 align:start position:0% 00:00:56.760 --> 00:00:59.229 align:start position:0% locally<00:00:57.760> uh<00:00:57.960> for<00:00:58.160> all<00:00:58.359> these<00:00:58.559> purposes<00:00:59.120> we 00:00:59.229 --> 00:00:59.239 align:start position:0% locally uh for all these purposes we 00:00:59.239 --> 00:01:02.150 align:start position:0% locally uh for all these purposes we have<00:00:59.399> developed<00:01:00.239> the<00:01:00.680> uh<00:01:00.840> last 00:01:02.150 --> 00:01:02.160 align:start position:0% have developed the uh last 00:01:02.160 --> 00:01:03.910 align:start position:0% have developed the uh last protocol 00:01:03.910 --> 00:01:03.920 align:start position:0% protocol 00:01:03.920 --> 00:01:07.710 align:start position:0% protocol uh<00:01:04.920> it's<00:01:05.159> a<00:01:05.880> the<00:01:06.080> there's<00:01:06.280> a<00:01:06.520> topology<00:01:07.320> shown 00:01:07.710 --> 00:01:07.720 align:start position:0% uh it's a the there's a topology shown 00:01:07.720 --> 00:01:11.870 align:start position:0% uh it's a the there's a topology shown on<00:01:08.040> in<00:01:08.159> the<00:01:08.360> slide<00:01:09.320> uh<00:01:09.520> which<00:01:10.119> shows<00:01:10.600> that<00:01:10.960> uh 00:01:11.870 --> 00:01:11.880 align:start position:0% on in the slide uh which shows that uh 00:01:11.880 --> 00:01:14.910 align:start position:0% on in the slide uh which shows that uh uh<00:01:12.439> just<00:01:12.759> the<00:01:12.960> blue<00:01:13.240> diamonds<00:01:14.240> who<00:01:14.439> represent 00:01:14.910 --> 00:01:14.920 align:start position:0% uh just the blue diamonds who represent 00:01:14.920 --> 00:01:16.630 align:start position:0% uh just the blue diamonds who represent traditional<00:01:15.439> full<00:01:15.720> notes<00:01:16.040> and<00:01:16.200> the<00:01:16.320> green 00:01:16.630 --> 00:01:16.640 align:start position:0% traditional full notes and the green 00:01:16.640 --> 00:01:18.910 align:start position:0% traditional full notes and the green diamonds<00:01:17.320> who<00:01:17.439> are<00:01:17.920> light<00:01:18.159> notes<00:01:18.479> connecting 00:01:18.910 --> 00:01:18.920 align:start position:0% diamonds who are light notes connecting 00:01:18.920 --> 00:01:20.870 align:start position:0% diamonds who are light notes connecting to<00:01:19.119> them<00:01:19.920> and 00:01:20.870 --> 00:01:20.880 align:start position:0% to them and 00:01:20.880 --> 00:01:23.950 align:start position:0% to them and uh<00:01:21.880> and<00:01:22.280> uh<00:01:22.520> the<00:01:22.720> green<00:01:23.119> light<00:01:23.360> notes<00:01:23.680> are 00:01:23.950 --> 00:01:23.960 align:start position:0% uh and uh the green light notes are 00:01:23.960 --> 00:01:26.870 align:start position:0% uh and uh the green light notes are downloading<00:01:24.520> only<00:01:24.799> block<00:01:25.159> headers<00:01:26.159> as<00:01:26.400> each 00:01:26.870 --> 00:01:26.880 align:start position:0% downloading only block headers as each 00:01:26.880 --> 00:01:28.550 align:start position:0% downloading only block headers as each new<00:01:27.079> block<00:01:27.320> appears<00:01:27.640> in<00:01:27.720> the<00:01:27.880> blockchain 00:01:28.550 --> 00:01:28.560 align:start position:0% new block appears in the blockchain 00:01:28.560 --> 00:01:31.270 align:start position:0% new block appears in the blockchain which<00:01:28.720> is<00:01:28.880> a<00:01:29.600> uh<00:01:29.920> lot<00:01:30.119> less<00:01:30.320> Network<00:01:30.720> traffic 00:01:31.270 --> 00:01:31.280 align:start position:0% which is a uh lot less Network traffic 00:01:31.280 --> 00:01:34.910 align:start position:0% which is a uh lot less Network traffic uh<00:01:31.439> than<00:01:32.159> downloading<00:01:32.720> entire<00:01:33.079> blocks<00:01:34.040> and<00:01:34.479> uh 00:01:34.910 --> 00:01:34.920 align:start position:0% uh than downloading entire blocks and uh 00:01:34.920 --> 00:01:38.389 align:start position:0% uh than downloading entire blocks and uh they<00:01:35.119> only<00:01:35.759> uh<00:01:36.280> download<00:01:37.280> uh<00:01:37.399> block<00:01:37.720> and<00:01:38.000> state 00:01:38.389 --> 00:01:38.399 align:start position:0% they only uh download uh block and state 00:01:38.399 --> 00:01:42.590 align:start position:0% they only uh download uh block and state data<00:01:39.200> uh<00:01:39.399> as<00:01:39.680> it<00:01:39.799> is<00:01:40.000> required<00:01:40.520> by<00:01:41.000> uh<00:01:41.240> the 00:01:42.590 --> 00:01:42.600 align:start position:0% data uh as it is required by uh the 00:01:42.600 --> 00:01:46.109 align:start position:0% data uh as it is required by uh the applications<00:01:43.600> uh<00:01:44.320> this<00:01:44.719> so<00:01:45.320> This<00:01:45.479> protocol<00:01:45.960> is 00:01:46.109 --> 00:01:46.119 align:start position:0% applications uh this so This protocol is 00:01:46.119 --> 00:01:48.469 align:start position:0% applications uh this so This protocol is for<00:01:46.399> for<00:01:46.640> for<00:01:47.200> on<00:01:47.399> demand<00:01:47.680> retal<00:01:48.159> and<00:01:48.280> block 00:01:48.469 --> 00:01:48.479 align:start position:0% for for for on demand retal and block 00:01:48.479 --> 00:01:51.950 align:start position:0% for for for on demand retal and block and<00:01:48.680> state<00:01:49.000> data<00:01:49.640> and<00:01:50.000> uh<00:01:50.360> also<00:01:51.000> uh<00:01:51.360> it<00:01:51.479> can<00:01:51.799> uh 00:01:51.950 --> 00:01:51.960 align:start position:0% and state data and uh also uh it can uh 00:01:51.960 --> 00:01:54.270 align:start position:0% and state data and uh also uh it can uh relay<00:01:52.360> transactions<00:01:52.920> to<00:01:53.079> the<00:01:53.320> E<00:01:53.680> consensus 00:01:54.270 --> 00:01:54.280 align:start position:0% relay transactions to the E consensus 00:01:54.280 --> 00:01:57.670 align:start position:0% relay transactions to the E consensus Network<00:01:54.960> because<00:01:55.399> the<00:01:55.840> L<00:01:56.079> network<00:01:56.600> is<00:01:56.960> uh 00:01:57.670 --> 00:01:57.680 align:start position:0% Network because the L network is uh 00:01:57.680 --> 00:02:00.029 align:start position:0% Network because the L network is uh somewhat<00:01:58.079> separated<00:01:58.719> from<00:01:59.000> the<00:01:59.640> from<00:01:59.920> from 00:02:00.029 --> 00:02:00.039 align:start position:0% somewhat separated from the from from 00:02:00.039 --> 00:02:03.789 align:start position:0% somewhat separated from the from from the<00:02:00.240> consensus<00:02:00.759> network<00:02:01.640> uh<00:02:02.640> the<00:02:03.159> full<00:02:03.439> nodes 00:02:03.789 --> 00:02:03.799 align:start position:0% the consensus network uh the full nodes 00:02:03.799 --> 00:02:06.069 align:start position:0% the consensus network uh the full nodes definitely<00:02:04.600> support<00:02:05.159> both<00:02:05.399> e<00:02:05.640> and<00:02:05.840> less 00:02:06.069 --> 00:02:06.079 align:start position:0% definitely support both e and less 00:02:06.079 --> 00:02:08.229 align:start position:0% definitely support both e and less protocol<00:02:06.680> serving<00:02:07.119> the<00:02:07.280> light<00:02:07.479> nodes<00:02:08.039> and<00:02:08.160> the 00:02:08.229 --> 00:02:08.239 align:start position:0% protocol serving the light nodes and the 00:02:08.239 --> 00:02:10.150 align:start position:0% protocol serving the light nodes and the light<00:02:08.479> notes<00:02:08.720> are<00:02:08.840> only<00:02:09.119> communicating<00:02:09.879> with 00:02:10.150 --> 00:02:10.160 align:start position:0% light notes are only communicating with 00:02:10.160 --> 00:02:12.150 align:start position:0% light notes are only communicating with with<00:02:10.319> the<00:02:11.080> uh<00:02:11.239> last 00:02:12.150 --> 00:02:12.160 align:start position:0% with the uh last 00:02:12.160 --> 00:02:15.430 align:start position:0% with the uh last protocol<00:02:13.160> uh<00:02:13.640> this<00:02:13.840> structure<00:02:14.400> is<00:02:14.720> uh<00:02:15.000> working 00:02:15.430 --> 00:02:15.440 align:start position:0% protocol uh this structure is uh working 00:02:15.440 --> 00:02:18.869 align:start position:0% protocol uh this structure is uh working and<00:02:15.599> it<00:02:15.720> is<00:02:16.160> uh<00:02:17.000> uh<00:02:17.239> quite<00:02:17.519> efficient<00:02:18.040> at<00:02:18.280> a 00:02:18.869 --> 00:02:18.879 align:start position:0% and it is uh uh quite efficient at a 00:02:18.879 --> 00:02:21.589 align:start position:0% and it is uh uh quite efficient at a with<00:02:19.040> a<00:02:19.200> low<00:02:19.440> number<00:02:19.840> of<00:02:20.239> light<00:02:20.519> nodes<00:02:21.160> but<00:02:21.480> uh 00:02:21.589 --> 00:02:21.599 align:start position:0% with a low number of light nodes but uh 00:02:21.599 --> 00:02:24.070 align:start position:0% with a low number of light nodes but uh as<00:02:21.800> the<00:02:22.080> network<00:02:22.480> grows<00:02:23.319> we<00:02:23.560> we<00:02:23.640> will<00:02:23.879> come 00:02:24.070 --> 00:02:24.080 align:start position:0% as the network grows we we will come 00:02:24.080 --> 00:02:26.110 align:start position:0% as the network grows we we will come into<00:02:24.480> scalability<00:02:25.160> and<00:02:25.280> centralization 00:02:26.110 --> 00:02:26.120 align:start position:0% into scalability and centralization 00:02:26.120 --> 00:02:28.150 align:start position:0% into scalability and centralization issues<00:02:26.680> because<00:02:27.000> as<00:02:27.319> you<00:02:27.440> can<00:02:27.680> see<00:02:27.879> in<00:02:28.000> the 00:02:28.150 --> 00:02:28.160 align:start position:0% issues because as you can see in the 00:02:28.160 --> 00:02:31.150 align:start position:0% issues because as you can see in the picture<00:02:29.160> uh<00:02:29.400> light<00:02:29.640> not<00:02:30.280> currently<00:02:30.680> can<00:02:30.800> only 00:02:31.150 --> 00:02:31.160 align:start position:0% picture uh light not currently can only 00:02:31.160 --> 00:02:34.550 align:start position:0% picture uh light not currently can only connect<00:02:31.480> to<00:02:31.599> full<00:02:31.879> noes<00:02:32.720> and<00:02:33.120> uh<00:02:34.120> uh<00:02:34.280> this<00:02:34.400> is 00:02:34.550 --> 00:02:34.560 align:start position:0% connect to full noes and uh uh this is 00:02:34.560 --> 00:02:37.309 align:start position:0% connect to full noes and uh uh this is also<00:02:35.040> both<00:02:35.319> a<00:02:35.519> performance<00:02:36.360> uh<00:02:36.599> battl<00:02:36.959> neck 00:02:37.309 --> 00:02:37.319 align:start position:0% also both a performance uh battl neck 00:02:37.319 --> 00:02:40.630 align:start position:0% also both a performance uh battl neck and<00:02:37.640> uh<00:02:37.959> after<00:02:38.239> some<00:02:38.480> time<00:02:38.720> even<00:02:39.319> uh<00:02:39.840> a<00:02:40.360> can<00:02:40.519> be 00:02:40.630 --> 00:02:40.640 align:start position:0% and uh after some time even uh a can be 00:02:40.640 --> 00:02:42.790 align:start position:0% and uh after some time even uh a can be a<00:02:40.800> security<00:02:41.800> uh 00:02:42.790 --> 00:02:42.800 align:start position:0% a security uh 00:02:42.800 --> 00:02:44.869 align:start position:0% a security uh issue<00:02:43.800> so 00:02:44.869 --> 00:02:44.879 align:start position:0% issue so 00:02:44.879 --> 00:02:50.190 align:start position:0% issue so uh<00:02:45.879> it<00:02:46.000> would<00:02:46.200> be<00:02:47.080> beneficial<00:02:48.080> if<00:02:48.239> we<00:02:49.200> uh 00:02:50.190 --> 00:02:50.200 align:start position:0% uh it would be beneficial if we uh 00:02:50.200 --> 00:02:52.350 align:start position:0% uh it would be beneficial if we uh consider<00:02:50.800> consider<00:02:51.440> uh<00:02:51.560> serving<00:02:52.000> serving 00:02:52.350 --> 00:02:52.360 align:start position:0% consider consider uh serving serving 00:02:52.360 --> 00:02:55.589 align:start position:0% consider consider uh serving serving light<00:02:52.800> the<00:02:53.000> service<00:02:53.720> that<00:02:54.000> if<00:02:54.360> uh<00:02:54.720> light<00:02:55.040> notes 00:02:55.589 --> 00:02:55.599 align:start position:0% light the service that if uh light notes 00:02:55.599 --> 00:02:58.229 align:start position:0% light the service that if uh light notes could<00:02:55.840> become<00:02:56.400> uh<00:02:57.120> providers<00:02:57.599> of<00:02:57.760> the<00:02:57.920> service 00:02:58.229 --> 00:02:58.239 align:start position:0% could become uh providers of the service 00:02:58.239 --> 00:03:00.470 align:start position:0% could become uh providers of the service too 00:03:00.470 --> 00:03:00.480 align:start position:0% too 00:03:00.480 --> 00:03:02.670 align:start position:0% too uh<00:03:01.480> if<00:03:01.640> we<00:03:01.800> are<00:03:01.959> talking<00:03:02.280> about 00:03:02.670 --> 00:03:02.680 align:start position:0% uh if we are talking about 00:03:02.680 --> 00:03:04.750 align:start position:0% uh if we are talking about centralization<00:03:03.560> problems<00:03:04.159> in<00:03:04.280> the<00:03:04.440> context 00:03:04.750 --> 00:03:04.760 align:start position:0% centralization problems in the context 00:03:04.760 --> 00:03:07.309 align:start position:0% centralization problems in the context of<00:03:04.879> a<00:03:05.040> light<00:03:05.280> client<00:03:06.040> uh<00:03:06.440> we<00:03:06.560> have<00:03:06.720> to<00:03:07.000> address 00:03:07.309 --> 00:03:07.319 align:start position:0% of a light client uh we have to address 00:03:07.319 --> 00:03:09.550 align:start position:0% of a light client uh we have to address two<00:03:07.480> important<00:03:08.000> questions<00:03:08.840> one<00:03:09.000> of<00:03:09.159> them<00:03:09.400> is 00:03:09.550 --> 00:03:09.560 align:start position:0% two important questions one of them is 00:03:09.560 --> 00:03:13.830 align:start position:0% two important questions one of them is the<00:03:10.080> concern<00:03:10.440> of<00:03:10.799> security<00:03:11.799> uh<00:03:11.959> how<00:03:12.159> can<00:03:12.400> we<00:03:13.239> uh 00:03:13.830 --> 00:03:13.840 align:start position:0% the concern of security uh how can we uh 00:03:13.840 --> 00:03:16.509 align:start position:0% the concern of security uh how can we uh trust<00:03:14.159> our<00:03:14.360> headers<00:03:15.200> because<00:03:15.599> uh<00:03:16.120> the<00:03:16.280> light 00:03:16.509 --> 00:03:16.519 align:start position:0% trust our headers because uh the light 00:03:16.519 --> 00:03:20.070 align:start position:0% trust our headers because uh the light cents<00:03:17.360> work<00:03:17.560> in<00:03:17.680> a<00:03:17.879> way<00:03:18.799> that<00:03:19.120> uh<00:03:19.720> for<00:03:19.920> the 00:03:20.070 --> 00:03:20.080 align:start position:0% cents work in a way that uh for the 00:03:20.080 --> 00:03:22.630 align:start position:0% cents work in a way that uh for the patri<00:03:20.680> structure<00:03:21.040> ensures<00:03:21.959> that<00:03:22.360> if<00:03:22.480> we 00:03:22.630 --> 00:03:22.640 align:start position:0% patri structure ensures that if we 00:03:22.640 --> 00:03:23.670 align:start position:0% patri structure ensures that if we download 00:03:23.670 --> 00:03:23.680 align:start position:0% download 00:03:23.680 --> 00:03:26.589 align:start position:0% download any<00:03:24.680> block<00:03:24.959> of<00:03:25.159> State<00:03:25.440> data<00:03:25.920> we<00:03:26.000> can<00:03:26.159> check<00:03:26.400> its 00:03:26.589 --> 00:03:26.599 align:start position:0% any block of State data we can check its 00:03:26.599 --> 00:03:30.429 align:start position:0% any block of State data we can check its validity<00:03:27.360> by<00:03:27.760> uh<00:03:28.599> by<00:03:28.799> checking<00:03:29.159> a<00:03:29.280> mer<00:03:29.799> proof 00:03:30.429 --> 00:03:30.439 align:start position:0% validity by uh by checking a mer proof 00:03:30.439 --> 00:03:32.910 align:start position:0% validity by uh by checking a mer proof and<00:03:30.879> uh<00:03:31.319> and<00:03:31.599> uh<00:03:31.720> checking<00:03:32.040> it<00:03:32.280> against<00:03:32.599> the 00:03:32.910 --> 00:03:32.920 align:start position:0% and uh and uh checking it against the 00:03:32.920 --> 00:03:34.750 align:start position:0% and uh and uh checking it against the root<00:03:33.200> hashes<00:03:33.560> found<00:03:33.799> in<00:03:33.879> the<00:03:34.000> block<00:03:34.280> headers 00:03:34.750 --> 00:03:34.760 align:start position:0% root hashes found in the block headers 00:03:34.760 --> 00:03:36.550 align:start position:0% root hashes found in the block headers so<00:03:35.000> if<00:03:35.120> we<00:03:35.319> have<00:03:35.519> correct<00:03:35.879> headers<00:03:36.200> we<00:03:36.319> have<00:03:36.400> a 00:03:36.550 --> 00:03:36.560 align:start position:0% so if we have correct headers we have a 00:03:36.560 --> 00:03:39.750 align:start position:0% so if we have correct headers we have a secure<00:03:36.879> access<00:03:37.120> to<00:03:37.200> the<00:03:37.360> network<00:03:38.480> but<00:03:39.480> as<00:03:39.640> we 00:03:39.750 --> 00:03:39.760 align:start position:0% secure access to the network but as we 00:03:39.760 --> 00:03:41.710 align:start position:0% secure access to the network but as we are<00:03:39.920> not<00:03:40.400> processing<00:03:40.959> light<00:03:41.200> noes<00:03:41.439> are<00:03:41.560> not 00:03:41.710 --> 00:03:41.720 align:start position:0% are not processing light noes are not 00:03:41.720 --> 00:03:43.589 align:start position:0% are not processing light noes are not processing<00:03:42.239> the<00:03:42.439> blocks<00:03:43.080> they<00:03:43.239> cannot 00:03:43.589 --> 00:03:43.599 align:start position:0% processing the blocks they cannot 00:03:43.599 --> 00:03:45.110 align:start position:0% processing the blocks they cannot directly<00:03:44.040> check<00:03:44.280> the<00:03:44.439> validity<00:03:44.840> of<00:03:44.959> the 00:03:45.110 --> 00:03:45.120 align:start position:0% directly check the validity of the 00:03:45.120 --> 00:03:47.630 align:start position:0% directly check the validity of the headers<00:03:45.840> so<00:03:46.360> we<00:03:46.640> definitely<00:03:47.040> need<00:03:47.280> some 00:03:47.630 --> 00:03:47.640 align:start position:0% headers so we definitely need some 00:03:47.640 --> 00:03:51.149 align:start position:0% headers so we definitely need some security<00:03:48.640> uh<00:03:49.120> measures<00:03:49.599> to<00:03:49.959> prevent 00:03:51.149 --> 00:03:51.159 align:start position:0% security uh measures to prevent 00:03:51.159 --> 00:03:53.990 align:start position:0% security uh measures to prevent attacks<00:03:52.159> uh<00:03:52.599> one<00:03:52.840> obvious<00:03:53.319> way<00:03:53.519> is<00:03:53.840> uh 00:03:53.990 --> 00:03:54.000 align:start position:0% attacks uh one obvious way is uh 00:03:54.000 --> 00:03:55.990 align:start position:0% attacks uh one obvious way is uh checking<00:03:54.480> the<00:03:54.840> proof<00:03:55.079> of<00:03:55.239> work<00:03:55.519> and<00:03:55.680> later 00:03:55.990 --> 00:03:56.000 align:start position:0% checking the proof of work and later 00:03:56.000 --> 00:03:57.630 align:start position:0% checking the proof of work and later proof<00:03:56.200> of<00:03:56.319> stake<00:03:56.760> found<00:03:57.000> in<00:03:57.120> the<00:03:57.200> block 00:03:57.630 --> 00:03:57.640 align:start position:0% proof of stake found in the block 00:03:57.640 --> 00:04:00.949 align:start position:0% proof of stake found in the block headers<00:03:58.640> uh<00:03:59.439> which<00:03:59.840> makes<00:04:00.040> it<00:04:00.400> harder<00:04:00.799> and 00:04:00.949 --> 00:04:00.959 align:start position:0% headers uh which makes it harder and 00:04:00.959 --> 00:04:04.229 align:start position:0% headers uh which makes it harder and more<00:04:01.159> expensive<00:04:01.599> to<00:04:01.879> forge<00:04:02.599> false<00:04:02.959> blocks<00:04:03.680> or 00:04:04.229 --> 00:04:04.239 align:start position:0% more expensive to forge false blocks or 00:04:04.239 --> 00:04:06.789 align:start position:0% more expensive to forge false blocks or headers<00:04:05.239> uh<00:04:05.920> proof<00:04:06.159> of<00:04:06.280> stake<00:04:06.599> will 00:04:06.789 --> 00:04:06.799 align:start position:0% headers uh proof of stake will 00:04:06.799 --> 00:04:09.630 align:start position:0% headers uh proof of stake will definitely<00:04:07.640> uh<00:04:08.159> provide<00:04:08.560> a<00:04:08.840> better<00:04:09.200> level<00:04:09.400> of 00:04:09.630 --> 00:04:09.640 align:start position:0% definitely uh provide a better level of 00:04:09.640 --> 00:04:12.350 align:start position:0% definitely uh provide a better level of security<00:04:10.519> in<00:04:10.720> this<00:04:10.959> aspect<00:04:11.400> but<00:04:11.720> uh<00:04:11.920> proof<00:04:12.159> of 00:04:12.350 --> 00:04:12.360 align:start position:0% security in this aspect but uh proof of 00:04:12.360 --> 00:04:15.429 align:start position:0% security in this aspect but uh proof of work<00:04:12.840> will<00:04:13.040> also<00:04:13.319> be<00:04:13.560> sufficient<00:04:14.360> even<00:04:14.879> uh<00:04:15.280> and 00:04:15.429 --> 00:04:15.439 align:start position:0% work will also be sufficient even uh and 00:04:15.439 --> 00:04:17.710 align:start position:0% work will also be sufficient even uh and if<00:04:15.560> we<00:04:15.760> can<00:04:16.000> also<00:04:16.280> incre<00:04:16.680> increase<00:04:17.479> its 00:04:17.710 --> 00:04:17.720 align:start position:0% if we can also incre increase its 00:04:17.720 --> 00:04:20.430 align:start position:0% if we can also incre increase its security<00:04:18.479> if<00:04:18.600> we<00:04:18.799> de<00:04:19.079> demand<00:04:19.560> a<00:04:19.919> few 00:04:20.430 --> 00:04:20.440 align:start position:0% security if we de demand a few 00:04:20.440 --> 00:04:22.469 align:start position:0% security if we de demand a few confirmations<00:04:21.320> before<00:04:21.600> we<00:04:21.919> accept<00:04:22.280> each 00:04:22.469 --> 00:04:22.479 align:start position:0% confirmations before we accept each 00:04:22.479 --> 00:04:25.469 align:start position:0% confirmations before we accept each other<00:04:23.320> we<00:04:23.400> can<00:04:23.560> also<00:04:23.840> increase<00:04:24.479> security<00:04:25.280> by 00:04:25.469 --> 00:04:25.479 align:start position:0% other we can also increase security by 00:04:25.479 --> 00:04:28.070 align:start position:0% other we can also increase security by fetching<00:04:26.160> headers<00:04:26.560> from<00:04:26.759> multiple<00:04:27.199> peers 00:04:28.070 --> 00:04:28.080 align:start position:0% fetching headers from multiple peers 00:04:28.080 --> 00:04:30.909 align:start position:0% fetching headers from multiple peers preferably<00:04:29.080> randomly<00:04:30.039> selected<00:04:30.479> peers<00:04:30.759> and 00:04:30.909 --> 00:04:30.919 align:start position:0% preferably randomly selected peers and 00:04:30.919 --> 00:04:32.629 align:start position:0% preferably randomly selected peers and only<00:04:31.520> accept<00:04:31.800> headers<00:04:32.160> as<00:04:32.320> part<00:04:32.440> of<00:04:32.560> the 00:04:32.629 --> 00:04:32.639 align:start position:0% only accept headers as part of the 00:04:32.639 --> 00:04:34.629 align:start position:0% only accept headers as part of the canonical<00:04:33.160> chain<00:04:33.600> when<00:04:33.759> we<00:04:33.919> have<00:04:34.440> received 00:04:34.629 --> 00:04:34.639 align:start position:0% canonical chain when we have received 00:04:34.639 --> 00:04:37.909 align:start position:0% canonical chain when we have received them<00:04:34.800> from<00:04:35.000> the<00:04:35.240> majority<00:04:35.759> of<00:04:36.120> of<00:04:36.240> our<00:04:36.919> peers 00:04:37.909 --> 00:04:37.919 align:start position:0% them from the majority of of our peers 00:04:37.919 --> 00:04:39.870 align:start position:0% them from the majority of of our peers the<00:04:38.039> other<00:04:38.360> question<00:04:39.000> brings<00:04:39.280> us<00:04:39.440> to<00:04:39.560> the<00:04:39.680> main 00:04:39.870 --> 00:04:39.880 align:start position:0% the other question brings us to the main 00:04:39.880 --> 00:04:42.950 align:start position:0% the other question brings us to the main topic<00:04:40.120> of<00:04:40.280> my<00:04:40.639> presentation<00:04:41.639> the<00:04:41.960> efficient 00:04:42.950 --> 00:04:42.960 align:start position:0% topic of my presentation the efficient 00:04:42.960 --> 00:04:47.110 align:start position:0% topic of my presentation the efficient uh<00:04:43.880> distribution<00:04:44.880> uh<00:04:45.080> of<00:04:45.479> uh<00:04:45.800> the<00:04:46.520> blockchain 00:04:47.110 --> 00:04:47.120 align:start position:0% uh distribution uh of uh the blockchain 00:04:47.120 --> 00:04:48.749 align:start position:0% uh distribution uh of uh the blockchain the<00:04:47.199> block<00:04:47.440> and<00:04:47.680> state 00:04:48.749 --> 00:04:48.759 align:start position:0% the block and state 00:04:48.759 --> 00:04:52.270 align:start position:0% the block and state data<00:04:49.919> uh<00:04:50.919> and 00:04:52.270 --> 00:04:52.280 align:start position:0% data uh and 00:04:52.280 --> 00:04:56.629 align:start position:0% data uh and the<00:04:53.280> the<00:04:53.680> uh<00:04:54.080> general<00:04:54.720> idea<00:04:55.199> about<00:04:55.600> this<00:04:56.440> was 00:04:56.629 --> 00:04:56.639 align:start position:0% the the uh general idea about this was 00:04:56.639 --> 00:04:59.710 align:start position:0% the the uh general idea about this was originally<00:04:57.440> that<00:04:57.880> uh<00:04:58.720> uh<00:04:58.880> the<00:04:59.080> light<00:04:59.320> no 00:04:59.710 --> 00:04:59.720 align:start position:0% originally that uh uh the light no 00:04:59.720 --> 00:05:03.469 align:start position:0% originally that uh uh the light no should<00:05:00.080> collectively<00:05:00.720> run<00:05:01.120> a<00:05:01.360> DHT<00:05:02.160> Service<00:05:03.160> uh 00:05:03.469 --> 00:05:03.479 align:start position:0% should collectively run a DHT Service uh 00:05:03.479 --> 00:05:05.350 align:start position:0% should collectively run a DHT Service uh either<00:05:03.759> swarm<00:05:04.240> or 00:05:05.350 --> 00:05:05.360 align:start position:0% either swarm or 00:05:05.360 --> 00:05:09.670 align:start position:0% either swarm or ipfs<00:05:06.360> or<00:05:06.680> whatever<00:05:07.560> and<00:05:08.120> uh<00:05:08.800> and<00:05:09.080> and<00:05:09.240> store 00:05:09.670 --> 00:05:09.680 align:start position:0% ipfs or whatever and uh and and store 00:05:09.680 --> 00:05:13.189 align:start position:0% ipfs or whatever and uh and and store the<00:05:09.880> state<00:05:10.280> data<00:05:10.680> in<00:05:10.840> the 00:05:13.189 --> 00:05:13.199 align:start position:0% 00:05:13.199 --> 00:05:16.029 align:start position:0% DHD<00:05:14.199> uh<00:05:14.400> this<00:05:14.600> approach<00:05:14.880> is<00:05:15.039> demonstrated<00:05:15.840> on 00:05:16.029 --> 00:05:16.039 align:start position:0% DHD uh this approach is demonstrated on 00:05:16.039 --> 00:05:16.990 align:start position:0% DHD uh this approach is demonstrated on this<00:05:16.199> next 00:05:16.990 --> 00:05:17.000 align:start position:0% this next 00:05:17.000 --> 00:05:20.110 align:start position:0% this next slide<00:05:18.000> where<00:05:18.440> uh<00:05:18.880> one<00:05:19.080> node<00:05:19.560> shown<00:05:19.840> on<00:05:19.960> the 00:05:20.110 --> 00:05:20.120 align:start position:0% slide where uh one node shown on the 00:05:20.120 --> 00:05:24.189 align:start position:0% slide where uh one node shown on the left<00:05:20.520> tries<00:05:20.800> to<00:05:21.199> uh<00:05:21.360> do<00:05:21.720> a<00:05:22.400> uh<00:05:23.240> uh<00:05:23.360> State 00:05:24.189 --> 00:05:24.199 align:start position:0% left tries to uh do a uh uh State 00:05:24.199 --> 00:05:27.270 align:start position:0% left tries to uh do a uh uh State retrial<00:05:25.080> he<00:05:25.919> wants<00:05:26.160> to<00:05:26.440> retrieve<00:05:26.840> a<00:05:27.000> key 00:05:27.270 --> 00:05:27.280 align:start position:0% retrial he wants to retrieve a key 00:05:27.280 --> 00:05:31.150 align:start position:0% retrial he wants to retrieve a key starting<00:05:27.759> with<00:05:28.000> B4<00:05:28.680> F3<00:05:29.400> whatever<00:05:29.680> ever<00:05:30.520> uh<00:05:31.000> he 00:05:31.150 --> 00:05:31.160 align:start position:0% starting with B4 F3 whatever ever uh he 00:05:31.160 --> 00:05:34.870 align:start position:0% starting with B4 F3 whatever ever uh he once<00:05:31.520> needs<00:05:31.759> to<00:05:32.160> retrieve<00:05:32.759> the<00:05:33.199> the<00:05:33.720> state<00:05:34.479> TR 00:05:34.870 --> 00:05:34.880 align:start position:0% once needs to retrieve the the state TR 00:05:34.880 --> 00:05:39.230 align:start position:0% once needs to retrieve the the state TR node<00:05:35.600> take<00:05:36.000> the<00:05:36.479> hash<00:05:36.840> from<00:05:37.840> the<00:05:38.080> element<00:05:38.479> B<00:05:39.039> of 00:05:39.230 --> 00:05:39.240 align:start position:0% node take the hash from the element B of 00:05:39.240 --> 00:05:41.430 align:start position:0% node take the hash from the element B of the<00:05:39.440> of<00:05:39.520> the<00:05:39.639> node<00:05:40.240> and<00:05:40.400> then<00:05:40.880> use<00:05:41.080> it<00:05:41.199> as<00:05:41.280> a 00:05:41.430 --> 00:05:41.440 align:start position:0% the of the node and then use it as a 00:05:41.440 --> 00:05:43.749 align:start position:0% the of the node and then use it as a hash<00:05:41.639> and<00:05:41.800> retrieve<00:05:42.160> that<00:05:42.360> node<00:05:42.759> and<00:05:43.120> uh 00:05:43.749 --> 00:05:43.759 align:start position:0% hash and retrieve that node and uh 00:05:43.759 --> 00:05:47.430 align:start position:0% hash and retrieve that node and uh sequentially<00:05:44.720> retrieve<00:05:45.720> retrieve<00:05:46.440> try<00:05:46.759> noes 00:05:47.430 --> 00:05:47.440 align:start position:0% sequentially retrieve retrieve try noes 00:05:47.440 --> 00:05:49.830 align:start position:0% sequentially retrieve retrieve try noes until<00:05:47.960> it<00:05:48.120> finds<00:05:48.520> the<00:05:48.840> final<00:05:49.199> node<00:05:49.520> which<00:05:49.639> is 00:05:49.830 --> 00:05:49.840 align:start position:0% until it finds the final node which is 00:05:49.840 --> 00:05:54.309 align:start position:0% until it finds the final node which is the<00:05:50.120> value<00:05:50.560> it<00:05:50.720> is<00:05:50.880> looking<00:05:51.160> for<00:05:52.199> uh<00:05:53.199> there<00:05:53.319> are 00:05:54.309 --> 00:05:54.319 align:start position:0% the value it is looking for uh there are 00:05:54.319 --> 00:05:56.390 align:start position:0% the value it is looking for uh there are lot<00:05:54.479> of<00:05:54.639> other<00:05:55.080> light<00:05:55.319> notes<00:05:55.600> shown<00:05:56.039> on<00:05:56.199> this 00:05:56.390 --> 00:05:56.400 align:start position:0% lot of other light notes shown on this 00:05:56.400 --> 00:05:58.390 align:start position:0% lot of other light notes shown on this picture<00:05:57.080> because<00:05:57.360> if<00:05:57.479> we<00:05:57.560> are<00:05:58.000> putting<00:05:58.280> the 00:05:58.390 --> 00:05:58.400 align:start position:0% picture because if we are putting the 00:05:58.400 --> 00:06:00.550 align:start position:0% picture because if we are putting the state<00:05:58.600> on<00:05:58.759> DHT 00:06:00.550 --> 00:06:00.560 align:start position:0% state on DHT 00:06:00.560 --> 00:06:04.870 align:start position:0% state on DHT well<00:06:00.720> dhts<00:06:01.240> use<00:06:01.759> some<00:06:02.240> uh<00:06:02.680> most<00:06:02.919> dhts<00:06:03.440> use<00:06:04.240> a 00:06:04.870 --> 00:06:04.880 align:start position:0% well dhts use some uh most dhts use a 00:06:04.880 --> 00:06:06.870 align:start position:0% well dhts use some uh most dhts use a the<00:06:05.000> So-Cal<00:06:05.440> cadamia<00:06:05.960> structure<00:06:06.440> which<00:06:06.560> is<00:06:06.680> a 00:06:06.870 --> 00:06:06.880 align:start position:0% the So-Cal cadamia structure which is a 00:06:06.880 --> 00:06:09.110 align:start position:0% the So-Cal cadamia structure which is a great<00:06:07.039> and<00:06:07.240> efficient<00:06:07.880> DHD<00:06:08.360> topology<00:06:08.919> both 00:06:09.110 --> 00:06:09.120 align:start position:0% great and efficient DHD topology both 00:06:09.120 --> 00:06:13.950 align:start position:0% great and efficient DHD topology both swarm<00:06:09.440> and<00:06:09.599> ipfs<00:06:10.120> use<00:06:10.360> it<00:06:11.120> and<00:06:11.680> uh<00:06:12.680> uh<00:06:13.360> it<00:06:13.720> uh 00:06:13.950 --> 00:06:13.960 align:start position:0% swarm and ipfs use it and uh uh it uh 00:06:13.960 --> 00:06:18.469 align:start position:0% swarm and ipfs use it and uh uh it uh requires<00:06:14.759> uh<00:06:15.440> uh<00:06:16.440> uh<00:06:16.560> nodes<00:06:17.240> uh<00:06:17.560> to<00:06:18.000> access<00:06:18.360> a 00:06:18.469 --> 00:06:18.479 align:start position:0% requires uh uh uh nodes uh to access a 00:06:18.479 --> 00:06:20.550 align:start position:0% requires uh uh uh nodes uh to access a few<00:06:18.800> intermediate<00:06:19.479> other<00:06:19.759> nodes<00:06:20.199> before 00:06:20.550 --> 00:06:20.560 align:start position:0% few intermediate other nodes before 00:06:20.560 --> 00:06:22.870 align:start position:0% few intermediate other nodes before before<00:06:20.840> finding<00:06:21.639> the<00:06:21.800> node<00:06:22.280> that<00:06:22.400> can<00:06:22.520> serve 00:06:22.870 --> 00:06:22.880 align:start position:0% before finding the node that can serve 00:06:22.880 --> 00:06:24.710 align:start position:0% before finding the node that can serve the<00:06:23.039> data<00:06:23.319> they<00:06:23.440> are<00:06:23.599> looking<00:06:23.880> for<00:06:24.440> they<00:06:24.520> are 00:06:24.710 --> 00:06:24.720 align:start position:0% the data they are looking for they are 00:06:24.720 --> 00:06:26.990 align:start position:0% the data they are looking for they are getting<00:06:25.360> closer<00:06:25.759> to<00:06:25.960> the<00:06:26.240> looking<00:06:26.720> uh<00:06:26.880> the 00:06:26.990 --> 00:06:27.000 align:start position:0% getting closer to the looking uh the 00:06:27.000 --> 00:06:28.390 align:start position:0% getting closer to the looking uh the address<00:06:27.319> they<00:06:27.400> are<00:06:27.520> looking<00:06:27.720> for<00:06:28.000> and<00:06:28.160> even 00:06:28.390 --> 00:06:28.400 align:start position:0% address they are looking for and even 00:06:28.400 --> 00:06:30.510 align:start position:0% address they are looking for and even closer<00:06:28.759> and<00:06:28.919> even<00:06:29.120> closer<00:06:29.720> after<00:06:29.960> some<00:06:30.199> time 00:06:30.510 --> 00:06:30.520 align:start position:0% closer and even closer after some time 00:06:30.520 --> 00:06:33.469 align:start position:0% closer and even closer after some time they're<00:06:30.759> finding<00:06:31.080> the<00:06:31.240> data<00:06:31.960> so<00:06:32.400> uh<00:06:32.840> this<00:06:33.000> DHD 00:06:33.469 --> 00:06:33.479 align:start position:0% they're finding the data so uh this DHD 00:06:33.479 --> 00:06:36.550 align:start position:0% they're finding the data so uh this DHD approach<00:06:33.759> is<00:06:34.000> great<00:06:34.759> it<00:06:34.960> has<00:06:35.240> one<00:06:35.639> minor<00:06:36.280> uh 00:06:36.550 --> 00:06:36.560 align:start position:0% approach is great it has one minor uh 00:06:36.560 --> 00:06:39.110 align:start position:0% approach is great it has one minor uh drawback<00:06:37.160> that<00:06:37.440> uh<00:06:37.840> ad<00:06:38.000> DH<00:06:38.360> look<00:06:38.520> up<00:06:38.680> is<00:06:38.840> not 00:06:39.110 --> 00:06:39.120 align:start position:0% drawback that uh ad DH look up is not 00:06:39.120 --> 00:06:40.950 align:start position:0% drawback that uh ad DH look up is not not<00:06:39.360> particularly<00:06:39.960> fast<00:06:40.360> I<00:06:40.440> don't<00:06:40.639> want<00:06:40.800> to 00:06:40.950 --> 00:06:40.960 align:start position:0% not particularly fast I don't want to 00:06:40.960 --> 00:06:43.270 align:start position:0% not particularly fast I don't want to give<00:06:41.160> any<00:06:41.440> estimates<00:06:41.919> of<00:06:42.080> how<00:06:42.360> fast<00:06:42.560> it<00:06:42.720> is<00:06:43.000> but 00:06:43.270 --> 00:06:43.280 align:start position:0% give any estimates of how fast it is but 00:06:43.280 --> 00:06:46.390 align:start position:0% give any estimates of how fast it is but uh<00:06:43.720> it<00:06:43.960> it<00:06:44.080> takes<00:06:44.360> some<00:06:44.599> time<00:06:45.400> and<00:06:45.800> uh<00:06:46.160> it<00:06:46.240> is 00:06:46.390 --> 00:06:46.400 align:start position:0% uh it it takes some time and uh it is 00:06:46.400 --> 00:06:47.950 align:start position:0% uh it it takes some time and uh it is usually<00:06:46.680> not<00:06:46.840> a<00:06:47.000> problem<00:06:47.280> with<00:06:47.400> a<00:06:47.560> general 00:06:47.950 --> 00:06:47.960 align:start position:0% usually not a problem with a general 00:06:47.960 --> 00:06:49.870 align:start position:0% usually not a problem with a general purpose<00:06:48.440> data<00:06:48.639> storage<00:06:49.039> application<00:06:49.639> where 00:06:49.870 --> 00:06:49.880 align:start position:0% purpose data storage application where 00:06:49.880 --> 00:06:52.150 align:start position:0% purpose data storage application where we<00:06:50.039> if<00:06:50.120> you<00:06:50.240> are<00:06:50.440> looking<00:06:50.680> for<00:06:51.360> lot<00:06:51.560> of<00:06:51.840> small 00:06:52.150 --> 00:06:52.160 align:start position:0% we if you are looking for lot of small 00:06:52.160 --> 00:06:55.270 align:start position:0% we if you are looking for lot of small pieces<00:06:52.440> of<00:06:52.639> data<00:06:53.160> you<00:06:53.280> can<00:06:53.560> usually<00:06:54.160> do<00:06:54.440> that 00:06:55.270 --> 00:06:55.280 align:start position:0% pieces of data you can usually do that 00:06:55.280 --> 00:06:58.350 align:start position:0% pieces of data you can usually do that lookups<00:06:55.960> uh<00:06:56.120> those<00:06:56.319> lookups<00:06:57.039> in<00:06:57.240> parallel<00:06:58.000> but 00:06:58.350 --> 00:06:58.360 align:start position:0% lookups uh those lookups in parallel but 00:06:58.360 --> 00:06:59.990 align:start position:0% lookups uh those lookups in parallel but this<00:06:58.479> is<00:06:58.599> not<00:06:58.759> the<00:06:58.879> case<00:06:59.080> with<00:06:59.160> the<00:06:59.280> tri<00:06:59.599> lookup 00:06:59.990 --> 00:07:00.000 align:start position:0% this is not the case with the tri lookup 00:07:00.000 --> 00:07:02.510 align:start position:0% this is not the case with the tri lookup because<00:07:00.560> you<00:07:00.800> only<00:07:01.199> get<00:07:01.360> to<00:07:01.479> know<00:07:01.680> the<00:07:01.840> hashes 00:07:02.510 --> 00:07:02.520 align:start position:0% because you only get to know the hashes 00:07:02.520 --> 00:07:06.029 align:start position:0% because you only get to know the hashes sequentially<00:07:03.520> so<00:07:04.039> uh<00:07:04.599> a<00:07:04.800> state<00:07:05.160> lookup<00:07:05.560> could 00:07:06.029 --> 00:07:06.039 align:start position:0% sequentially so uh a state lookup could 00:07:06.039 --> 00:07:08.710 align:start position:0% sequentially so uh a state lookup could uh<00:07:06.840> take<00:07:07.080> pretty<00:07:07.319> long 00:07:08.710 --> 00:07:08.720 align:start position:0% uh take pretty long 00:07:08.720 --> 00:07:13.150 align:start position:0% uh take pretty long uh<00:07:09.720> well<00:07:10.199> uh<00:07:10.879> so<00:07:11.360> uh<00:07:11.560> to<00:07:11.759> address<00:07:12.360> this<00:07:12.599> problem 00:07:13.150 --> 00:07:13.160 align:start position:0% uh well uh so uh to address this problem 00:07:13.160 --> 00:07:16.430 align:start position:0% uh well uh so uh to address this problem uh<00:07:13.400> let<00:07:13.560> me<00:07:13.800> present<00:07:14.440> a<00:07:14.840> an<00:07:15.120> an<00:07:15.280> alternative<00:07:16.160> uh 00:07:16.430 --> 00:07:16.440 align:start position:0% uh let me present a an an alternative uh 00:07:16.440 --> 00:07:18.589 align:start position:0% uh let me present a an an alternative uh approach<00:07:16.919> which<00:07:17.039> is<00:07:17.280> a<00:07:18.000> which<00:07:18.120> is<00:07:18.360> quite 00:07:18.589 --> 00:07:18.599 align:start position:0% approach which is a which is quite 00:07:18.599 --> 00:07:21.029 align:start position:0% approach which is a which is quite similar<00:07:19.039> to<00:07:19.319> the<00:07:19.479> DHD<00:07:19.960> approach<00:07:20.319> actually<00:07:20.879> and 00:07:21.029 --> 00:07:21.039 align:start position:0% similar to the DHD approach actually and 00:07:21.039 --> 00:07:24.270 align:start position:0% similar to the DHD approach actually and it<00:07:21.199> can<00:07:21.440> use<00:07:22.440> much<00:07:22.879> most<00:07:23.120> of<00:07:23.280> the<00:07:23.800> mostly<00:07:24.120> the 00:07:24.270 --> 00:07:24.280 align:start position:0% it can use much most of the mostly the 00:07:24.280 --> 00:07:26.430 align:start position:0% it can use much most of the mostly the same<00:07:24.560> same<00:07:24.759> code<00:07:25.039> base<00:07:25.479> is<00:07:25.680> just<00:07:25.879> a<00:07:26.039> slight 00:07:26.430 --> 00:07:26.440 align:start position:0% same same code base is just a slight 00:07:26.440 --> 00:07:28.909 align:start position:0% same same code base is just a slight modification<00:07:27.440> but<00:07:27.599> a<00:07:27.800> great<00:07:28.080> Improvement<00:07:28.599> in 00:07:28.909 --> 00:07:28.919 align:start position:0% modification but a great Improvement in 00:07:28.919 --> 00:07:31.629 align:start position:0% modification but a great Improvement in efficiency 00:07:31.629 --> 00:07:31.639 align:start position:0% 00:07:31.639 --> 00:07:37.150 align:start position:0% see<00:07:32.639> so<00:07:33.280> uh<00:07:34.280> while<00:07:34.440> in<00:07:34.560> a<00:07:34.720> DHT<00:07:35.680> uh<00:07:36.039> nodes<00:07:36.960> each 00:07:37.150 --> 00:07:37.160 align:start position:0% see so uh while in a DHT uh nodes each 00:07:37.160 --> 00:07:39.990 align:start position:0% see so uh while in a DHT uh nodes each node<00:07:37.400> is<00:07:37.599> assigned<00:07:38.199> a<00:07:38.319> range<00:07:38.680> of<00:07:38.840> hashes<00:07:39.639> and 00:07:39.990 --> 00:07:40.000 align:start position:0% node is assigned a range of hashes and 00:07:40.000 --> 00:07:43.550 align:start position:0% node is assigned a range of hashes and stores<00:07:40.919> data<00:07:41.919> whose<00:07:42.160> hash<00:07:42.680> falls<00:07:43.039> into<00:07:43.319> into 00:07:43.550 --> 00:07:43.560 align:start position:0% stores data whose hash falls into into 00:07:43.560 --> 00:07:46.309 align:start position:0% stores data whose hash falls into into that<00:07:43.800> range<00:07:44.680> we<00:07:44.840> can<00:07:45.319> uh<00:07:45.639> modify<00:07:46.080> this 00:07:46.309 --> 00:07:46.319 align:start position:0% that range we can uh modify this 00:07:46.319 --> 00:07:48.790 align:start position:0% that range we can uh modify this approach<00:07:46.919> to<00:07:47.080> be<00:07:47.280> more<00:07:47.759> uh<00:07:47.960> State<00:07:48.360> try 00:07:48.790 --> 00:07:48.800 align:start position:0% approach to be more uh State try 00:07:48.800 --> 00:07:52.670 align:start position:0% approach to be more uh State try specific<00:07:49.720> and<00:07:50.240> uh<00:07:50.800> assign<00:07:51.240> each<00:07:51.440> node<00:07:51.960> a<00:07:52.159> range 00:07:52.670 --> 00:07:52.680 align:start position:0% specific and uh assign each node a range 00:07:52.680 --> 00:07:57.110 align:start position:0% specific and uh assign each node a range of<00:07:52.919> the<00:07:53.240> state<00:07:53.919> Keys<00:07:54.319> State<00:07:54.680> addresses<00:07:55.639> so<00:07:56.159> uh 00:07:57.110 --> 00:07:57.120 align:start position:0% of the state Keys State addresses so uh 00:07:57.120 --> 00:08:00.149 align:start position:0% of the state Keys State addresses so uh basically<00:07:57.720> each<00:07:58.199> Pier<00:07:58.800> uh<00:07:58.919> would<00:07:59.199> uh 00:08:00.149 --> 00:08:00.159 align:start position:0% basically each Pier uh would uh 00:08:00.159 --> 00:08:02.670 align:start position:0% basically each Pier uh would uh store<00:08:00.479> and<00:08:00.759> constantly<00:08:01.240> observe<00:08:01.680> and<00:08:01.840> update 00:08:02.670 --> 00:08:02.680 align:start position:0% store and constantly observe and update 00:08:02.680 --> 00:08:05.270 align:start position:0% store and constantly observe and update a<00:08:02.840> slice<00:08:03.400> of<00:08:03.560> the<00:08:03.759> state<00:08:04.759> basically 00:08:05.270 --> 00:08:05.280 align:start position:0% a slice of the state basically 00:08:05.280 --> 00:08:07.909 align:start position:0% a slice of the state basically technically<00:08:05.840> few<00:08:06.199> adjacent<00:08:06.720> sub<00:08:07.000> trees<00:08:07.800> which 00:08:07.909 --> 00:08:07.919 align:start position:0% technically few adjacent sub trees which 00:08:07.919 --> 00:08:11.670 align:start position:0% technically few adjacent sub trees which is<00:08:08.759> uh<00:08:09.759> quite<00:08:10.280> uh<00:08:10.720> efficient<00:08:11.120> in<00:08:11.240> terms<00:08:11.520> of 00:08:11.670 --> 00:08:11.680 align:start position:0% is uh quite uh efficient in terms of 00:08:11.680 --> 00:08:14.469 align:start position:0% is uh quite uh efficient in terms of storage<00:08:12.199> and<00:08:12.960> updating 00:08:14.469 --> 00:08:14.479 align:start position:0% storage and updating 00:08:14.479 --> 00:08:18.469 align:start position:0% storage and updating uh<00:08:15.479> and<00:08:15.960> the<00:08:16.680> advantage<00:08:17.159> of<00:08:17.319> this<00:08:17.520> approach<00:08:18.199> uh 00:08:18.469 --> 00:08:18.479 align:start position:0% uh and the advantage of this approach uh 00:08:18.479 --> 00:08:21.510 align:start position:0% uh and the advantage of this approach uh is<00:08:18.800> uh<00:08:19.159> pretty<00:08:19.479> obvious<00:08:20.360> because<00:08:21.000> these<00:08:21.159> notes 00:08:21.510 --> 00:08:21.520 align:start position:0% is uh pretty obvious because these notes 00:08:21.520 --> 00:08:24.070 align:start position:0% is uh pretty obvious because these notes can<00:08:21.680> be<00:08:21.960> organized<00:08:22.479> in<00:08:22.560> a<00:08:22.720> cadamia<00:08:23.240> table<00:08:23.919> the 00:08:24.070 --> 00:08:24.080 align:start position:0% can be organized in a cadamia table the 00:08:24.080 --> 00:08:27.629 align:start position:0% can be organized in a cadamia table the same<00:08:24.360> way<00:08:24.960> the<00:08:25.080> DHD<00:08:25.639> notes<00:08:26.000> can<00:08:26.199> be<00:08:26.639> organized 00:08:27.629 --> 00:08:27.639 align:start position:0% same way the DHD notes can be organized 00:08:27.639 --> 00:08:31.230 align:start position:0% same way the DHD notes can be organized basically<00:08:28.120> with<00:08:28.240> the<00:08:28.400> same<00:08:28.759> code<00:08:29.639> same<00:08:30.000> same 00:08:31.230 --> 00:08:31.240 align:start position:0% basically with the same code same same 00:08:31.240 --> 00:08:34.990 align:start position:0% basically with the same code same same implementation<00:08:32.240> and<00:08:32.919> uh<00:08:33.919> it<00:08:34.240> it<00:08:34.360> only<00:08:34.599> takes 00:08:34.990 --> 00:08:35.000 align:start position:0% implementation and uh it it only takes 00:08:35.000 --> 00:08:38.070 align:start position:0% implementation and uh it it only takes one<00:08:35.560> uh<00:08:35.919> one<00:08:36.279> Global<00:08:36.719> lookup<00:08:37.719> which<00:08:37.839> is 00:08:38.070 --> 00:08:38.080 align:start position:0% one uh one Global lookup which is 00:08:38.080 --> 00:08:41.190 align:start position:0% one uh one Global lookup which is expensive<00:08:39.080> to<00:08:39.599> uh<00:08:39.880> to<00:08:40.080> find<00:08:40.279> a<00:08:40.399> node<00:08:40.800> who<00:08:40.959> can 00:08:41.190 --> 00:08:41.200 align:start position:0% expensive to uh to find a node who can 00:08:41.200 --> 00:08:44.430 align:start position:0% expensive to uh to find a node who can serve<00:08:41.560> us<00:08:41.880> an<00:08:42.080> entire<00:08:42.440> mercur<00:08:42.919> proof<00:08:43.680> which<00:08:43.839> is 00:08:44.430 --> 00:08:44.440 align:start position:0% serve us an entire mercur proof which is 00:08:44.440 --> 00:08:47.350 align:start position:0% serve us an entire mercur proof which is basically<00:08:45.440> uh<00:08:46.080> all<00:08:46.320> the<00:08:46.480> nodes<00:08:46.839> starting<00:08:47.200> from 00:08:47.350 --> 00:08:47.360 align:start position:0% basically uh all the nodes starting from 00:08:47.360 --> 00:08:50.630 align:start position:0% basically uh all the nodes starting from the<00:08:47.560> state<00:08:48.160> route<00:08:48.640> up<00:08:48.760> to<00:08:48.959> the<00:08:49.320> value<00:08:49.680> node 00:08:50.630 --> 00:08:50.640 align:start position:0% the state route up to the value node 00:08:50.640 --> 00:08:54.750 align:start position:0% the state route up to the value node this<00:08:51.120> uh<00:08:51.519> this<00:08:51.720> picture<00:08:52.040> shows<00:08:52.600> uh<00:08:53.080> two<00:08:53.720> such 00:08:54.750 --> 00:08:54.760 align:start position:0% this uh this picture shows uh two such 00:08:54.760 --> 00:08:58.829 align:start position:0% this uh this picture shows uh two such nodes<00:08:55.880> uh<00:08:56.880> uh<00:08:57.040> one<00:08:57.200> of<00:08:57.399> them<00:08:57.680> is<00:08:58.160> observing<00:08:58.640> the 00:08:58.829 --> 00:08:58.839 align:start position:0% nodes uh uh one of them is observing the 00:08:58.839 --> 00:09:03.190 align:start position:0% nodes uh uh one of them is observing the KE<00:08:59.120> range<00:08:59.440> which<00:08:59.560> is<00:08:59.920> B4<00:09:00.560> C<00:09:01.240> to<00:09:01.839> b4f<00:09:02.839> the<00:09:02.959> other 00:09:03.190 --> 00:09:03.200 align:start position:0% KE range which is B4 C to b4f the other 00:09:03.200 --> 00:09:04.910 align:start position:0% KE range which is B4 C to b4f the other one<00:09:03.480> is<00:09:03.680> observing<00:09:04.160> the<00:09:04.320> right<00:09:04.519> one<00:09:04.760> is 00:09:04.910 --> 00:09:04.920 align:start position:0% one is observing the right one is 00:09:04.920 --> 00:09:13.230 align:start position:0% one is observing the right one is observing<00:09:05.720> uh<00:09:06.240> B<00:09:06.680> e0<00:09:07.680> to<00:09:08.279> B<00:09:08.720> E7 00:09:13.230 --> 00:09:13.240 align:start position:0% 00:09:13.240 --> 00:09:15.949 align:start position:0% prefixes<00:09:14.240> and<00:09:14.440> this<00:09:14.640> next<00:09:14.839> slide<00:09:15.079> shows<00:09:15.560> how 00:09:15.949 --> 00:09:15.959 align:start position:0% prefixes and this next slide shows how 00:09:15.959 --> 00:09:20.110 align:start position:0% prefixes and this next slide shows how this<00:09:16.160> approach<00:09:16.640> actually<00:09:17.200> works<00:09:18.079> would<00:09:18.600> work 00:09:20.110 --> 00:09:20.120 align:start position:0% this approach actually works would work 00:09:20.120 --> 00:09:24.470 align:start position:0% this approach actually works would work uh<00:09:21.120> each<00:09:21.600> uh<00:09:22.399> each<00:09:22.600> node<00:09:23.160> uh<00:09:23.560> uh<00:09:23.720> as<00:09:24.160> as<00:09:24.279> new 00:09:24.470 --> 00:09:24.480 align:start position:0% uh each uh each node uh uh as as new 00:09:24.480 --> 00:09:26.389 align:start position:0% uh each uh each node uh uh as as new blocks<00:09:24.880> blocks<00:09:25.200> appear<00:09:25.480> in<00:09:25.560> the<00:09:25.680> canonical 00:09:26.389 --> 00:09:26.399 align:start position:0% blocks blocks appear in the canonical 00:09:26.399 --> 00:09:30.509 align:start position:0% blocks blocks appear in the canonical chain<00:09:27.399> each<00:09:27.880> uh<00:09:28.600> each<00:09:28.880> peer<00:09:29.200> can<00:09:29.680> uh<00:09:30.000> update 00:09:30.509 --> 00:09:30.519 align:start position:0% chain each uh each peer can uh update 00:09:30.519 --> 00:09:32.910 align:start position:0% chain each uh each peer can uh update their<00:09:30.880> part<00:09:31.079> of<00:09:31.279> the<00:09:31.640> part<00:09:31.839> of<00:09:31.959> the<00:09:32.079> try<00:09:32.600> from<00:09:32.760> a 00:09:32.910 --> 00:09:32.920 align:start position:0% their part of the part of the try from a 00:09:32.920 --> 00:09:35.949 align:start position:0% their part of the part of the try from a node<00:09:33.480> who<00:09:33.640> is<00:09:33.800> observing<00:09:34.320> the<00:09:34.480> same<00:09:34.760> or<00:09:35.000> larger 00:09:35.949 --> 00:09:35.959 align:start position:0% node who is observing the same or larger 00:09:35.959 --> 00:09:40.430 align:start position:0% node who is observing the same or larger uh<00:09:36.440> key<00:09:37.079> range<00:09:38.079> uh<00:09:38.360> and<00:09:39.160> in<00:09:39.399> this<00:09:39.800> uh<00:09:40.079> aspect 00:09:40.430 --> 00:09:40.440 align:start position:0% uh key range uh and in this uh aspect 00:09:40.440 --> 00:09:43.829 align:start position:0% uh key range uh and in this uh aspect full<00:09:40.720> nodes<00:09:41.160> are<00:09:41.720> uh<00:09:42.279> are<00:09:42.720> are<00:09:42.880> nodes<00:09:43.200> who<00:09:43.360> are 00:09:43.829 --> 00:09:43.839 align:start position:0% full nodes are uh are are nodes who are 00:09:43.839 --> 00:09:46.110 align:start position:0% full nodes are uh are are nodes who are observing<00:09:44.399> the<00:09:44.680> entire<00:09:45.279> entire<00:09:45.680> state<00:09:45.959> of 00:09:46.110 --> 00:09:46.120 align:start position:0% observing the entire entire state of 00:09:46.120 --> 00:09:48.310 align:start position:0% observing the entire entire state of course<00:09:46.839> but<00:09:47.079> even<00:09:47.320> light<00:09:47.560> notes<00:09:47.800> can<00:09:48.040> choose 00:09:48.310 --> 00:09:48.320 align:start position:0% course but even light notes can choose 00:09:48.320 --> 00:09:51.590 align:start position:0% course but even light notes can choose to<00:09:48.680> observe<00:09:49.279> the<00:09:50.079> uh<00:09:50.279> the<00:09:50.480> entire<00:09:51.000> state<00:09:51.440> but 00:09:51.590 --> 00:09:51.600 align:start position:0% to observe the uh the entire state but 00:09:51.600 --> 00:09:53.670 align:start position:0% to observe the uh the entire state but not<00:09:51.800> process<00:09:52.200> blocks<00:09:52.440> just<00:09:52.600> downlo<00:09:53.000> states 00:09:53.670 --> 00:09:53.680 align:start position:0% not process blocks just downlo states 00:09:53.680 --> 00:09:56.509 align:start position:0% not process blocks just downlo states there<00:09:53.839> is<00:09:54.040> a<00:09:54.800> a<00:09:55.040> big<00:09:55.399> advantage<00:09:55.839> of<00:09:56.079> this<00:09:56.320> this 00:09:56.509 --> 00:09:56.519 align:start position:0% there is a a big advantage of this this 00:09:56.519 --> 00:09:58.470 align:start position:0% there is a a big advantage of this this approach<00:09:57.160> in<00:09:57.320> addition<00:09:57.760> to<00:09:58.000> increased 00:09:58.470 --> 00:09:58.480 align:start position:0% approach in addition to increased 00:09:58.480 --> 00:10:00.069 align:start position:0% approach in addition to increased performance 00:10:00.069 --> 00:10:00.079 align:start position:0% performance 00:10:00.079 --> 00:10:03.269 align:start position:0% performance uh<00:10:00.640> which<00:10:00.800> is<00:10:01.040> the<00:10:01.240> fact<00:10:01.839> that<00:10:02.279> uh<00:10:02.760> if<00:10:02.880> you<00:10:03.000> are 00:10:03.269 --> 00:10:03.279 align:start position:0% uh which is the fact that uh if you are 00:10:03.279 --> 00:10:05.790 align:start position:0% uh which is the fact that uh if you are updating<00:10:04.160> your<00:10:04.399> try<00:10:04.800> downloading<00:10:05.240> the<00:10:05.360> new<00:10:05.519> TR 00:10:05.790 --> 00:10:05.800 align:start position:0% updating your try downloading the new TR 00:10:05.800 --> 00:10:09.110 align:start position:0% updating your try downloading the new TR noes<00:10:06.160> that<00:10:06.360> the<00:10:07.120> uh<00:10:08.079> that<00:10:08.360> exist<00:10:08.640> in<00:10:08.760> the<00:10:08.920> new 00:10:09.110 --> 00:10:09.120 align:start position:0% noes that the uh that exist in the new 00:10:09.120 --> 00:10:11.550 align:start position:0% noes that the uh that exist in the new version<00:10:09.399> of<00:10:09.519> the<00:10:09.680> state<00:10:10.000> in<00:10:10.200> that<00:10:10.560> uh<00:10:10.959> slice<00:10:11.440> of 00:10:11.550 --> 00:10:11.560 align:start position:0% version of the state in that uh slice of 00:10:11.560 --> 00:10:14.870 align:start position:0% version of the state in that uh slice of the<00:10:11.920> triy<00:10:12.920> uh<00:10:13.240> you<00:10:13.360> can<00:10:13.640> exactly<00:10:14.040> know<00:10:14.720> when 00:10:14.870 --> 00:10:14.880 align:start position:0% the triy uh you can exactly know when 00:10:14.880 --> 00:10:17.870 align:start position:0% the triy uh you can exactly know when you<00:10:15.000> have<00:10:15.200> red<00:10:15.920> all<00:10:16.200> those<00:10:16.640> uh<00:10:17.480> all<00:10:17.720> those 00:10:17.870 --> 00:10:17.880 align:start position:0% you have red all those uh all those 00:10:17.880 --> 00:10:20.829 align:start position:0% you have red all those uh all those nodes<00:10:18.600> uh<00:10:18.760> this<00:10:18.839> is<00:10:19.040> basically<00:10:19.600> similar<00:10:20.000> to<00:10:20.680> uh 00:10:20.829 --> 00:10:20.839 align:start position:0% nodes uh this is basically similar to uh 00:10:20.839 --> 00:10:22.470 align:start position:0% nodes uh this is basically similar to uh checking<00:10:21.440> downloading<00:10:21.880> and<00:10:22.040> checking<00:10:22.320> a 00:10:22.470 --> 00:10:22.480 align:start position:0% checking downloading and checking a 00:10:22.480 --> 00:10:25.430 align:start position:0% checking downloading and checking a Merle<00:10:22.920> proof<00:10:23.519> it's<00:10:23.800> just<00:10:24.160> uh<00:10:24.600> works<00:10:24.880> for<00:10:25.120> an 00:10:25.430 --> 00:10:25.440 align:start position:0% Merle proof it's just uh works for an 00:10:25.440 --> 00:10:28.190 align:start position:0% Merle proof it's just uh works for an entire<00:10:25.839> range<00:10:26.120> of<00:10:26.320> keys<00:10:26.839> an<00:10:27.040> entire<00:10:27.320> sub<00:10:27.600> tree 00:10:28.190 --> 00:10:28.200 align:start position:0% entire range of keys an entire sub tree 00:10:28.200 --> 00:10:30.110 align:start position:0% entire range of keys an entire sub tree but<00:10:28.519> it<00:10:28.600> can<00:10:28.760> be<00:10:28.880> similarly<00:10:29.440> checked<00:10:29.760> against 00:10:30.110 --> 00:10:30.120 align:start position:0% but it can be similarly checked against 00:10:30.120 --> 00:10:33.470 align:start position:0% but it can be similarly checked against the<00:10:30.440> state<00:10:30.800> rout<00:10:31.600> found<00:10:31.920> in<00:10:32.040> the<00:10:32.160> block<00:10:32.480> header 00:10:33.470 --> 00:10:33.480 align:start position:0% the state rout found in the block header 00:10:33.480 --> 00:10:35.350 align:start position:0% the state rout found in the block header this<00:10:33.560> is<00:10:33.800> big<00:10:34.079> this<00:10:34.200> is<00:10:34.320> a<00:10:34.440> big<00:10:34.680> Advantage 00:10:35.350 --> 00:10:35.360 align:start position:0% this is big this is a big Advantage 00:10:35.360 --> 00:10:39.670 align:start position:0% this is big this is a big Advantage because<00:10:35.839> uh<00:10:36.360> this<00:10:36.560> way<00:10:37.200> uh<00:10:38.079> we<00:10:38.200> can<00:10:38.440> easily<00:10:39.200> uh 00:10:39.670 --> 00:10:39.680 align:start position:0% because uh this way uh we can easily uh 00:10:39.680 --> 00:10:41.990 align:start position:0% because uh this way uh we can easily uh measure<00:10:40.279> the<00:10:40.480> equality<00:10:41.079> of<00:10:41.200> the<00:10:41.360> service<00:10:41.839> if 00:10:41.990 --> 00:10:42.000 align:start position:0% measure the equality of the service if 00:10:42.000 --> 00:10:45.550 align:start position:0% measure the equality of the service if we<00:10:42.240> consider<00:10:42.920> serving<00:10:43.680> uh<00:10:44.560> either<00:10:44.920> sub<00:10:45.279> trees 00:10:45.550 --> 00:10:45.560 align:start position:0% we consider serving uh either sub trees 00:10:45.560 --> 00:10:47.990 align:start position:0% we consider serving uh either sub trees or<00:10:45.880> individual<00:10:46.519> keys<00:10:47.200> which<00:10:47.360> is<00:10:47.680> well<00:10:47.880> which 00:10:47.990 --> 00:10:48.000 align:start position:0% or individual keys which is well which 00:10:48.000 --> 00:10:51.629 align:start position:0% or individual keys which is well which is<00:10:48.120> a<00:10:48.279> service<00:10:49.040> and<00:10:49.320> which<00:10:50.079> eventually<00:10:51.079> uh<00:10:51.240> no 00:10:51.629 --> 00:10:51.639 align:start position:0% is a service and which eventually uh no 00:10:51.639 --> 00:10:52.910 align:start position:0% is a service and which eventually uh no will<00:10:51.839> be<00:10:52.079> paying 00:10:52.910 --> 00:10:52.920 align:start position:0% will be paying 00:10:52.920 --> 00:10:55.910 align:start position:0% will be paying for<00:10:53.920> then<00:10:54.160> it<00:10:54.279> is<00:10:54.600> uh<00:10:54.959> it<00:10:55.040> is<00:10:55.200> very<00:10:55.399> beneficial 00:10:55.910 --> 00:10:55.920 align:start position:0% for then it is uh it is very beneficial 00:10:55.920 --> 00:10:59.710 align:start position:0% for then it is uh it is very beneficial if<00:10:56.040> he<00:10:56.279> can<00:10:57.079> exactly<00:10:57.639> measure<00:10:58.240> its<00:10:58.720> uh<00:10:59.399> it's 00:10:59.710 --> 00:10:59.720 align:start position:0% if he can exactly measure its uh it's 00:10:59.720 --> 00:11:01.629 align:start position:0% if he can exactly measure its uh it's it's<00:11:00.040> uh<00:11:00.519> this<00:11:00.720> the<00:11:00.839> value<00:11:01.079> of<00:11:01.200> the<00:11:01.320> service 00:11:01.629 --> 00:11:01.639 align:start position:0% it's uh this the value of the service 00:11:01.639 --> 00:11:03.629 align:start position:0% it's uh this the value of the service the<00:11:01.760> quality<00:11:02.079> of<00:11:02.200> the<00:11:02.320> service<00:11:02.880> and<00:11:03.040> this<00:11:03.200> is 00:11:03.629 --> 00:11:03.639 align:start position:0% the quality of the service and this is 00:11:03.639 --> 00:11:06.190 align:start position:0% the quality of the service and this is uh<00:11:04.000> especially<00:11:04.480> beneficial<00:11:05.000> for<00:11:05.200> smaller 00:11:06.190 --> 00:11:06.200 align:start position:0% uh especially beneficial for smaller 00:11:06.200 --> 00:11:10.269 align:start position:0% uh especially beneficial for smaller ndes<00:11:07.279> uh<00:11:08.279> because<00:11:08.760> uh<00:11:09.560> uh<00:11:09.839> if<00:11:09.959> they<00:11:10.079> are 00:11:10.269 --> 00:11:10.279 align:start position:0% ndes uh because uh uh if they are 00:11:10.279 --> 00:11:14.670 align:start position:0% ndes uh because uh uh if they are choosing<00:11:11.200> uh<00:11:11.560> a<00:11:12.440> key<00:11:12.680> range<00:11:13.320> that<00:11:13.480> is<00:11:14.079> not<00:11:14.320> yet 00:11:14.670 --> 00:11:14.680 align:start position:0% choosing uh a key range that is not yet 00:11:14.680 --> 00:11:17.430 align:start position:0% choosing uh a key range that is not yet so<00:11:15.000> heavily<00:11:15.399> served<00:11:16.120> they<00:11:16.279> can<00:11:17.000> provide<00:11:17.279> a 00:11:17.430 --> 00:11:17.440 align:start position:0% so heavily served they can provide a 00:11:17.440 --> 00:11:19.829 align:start position:0% so heavily served they can provide a service<00:11:17.880> that<00:11:18.120> that<00:11:18.200> is<00:11:18.399> just<00:11:18.560> as<00:11:18.760> valuable<00:11:19.720> as 00:11:19.829 --> 00:11:19.839 align:start position:0% service that that is just as valuable as 00:11:19.839 --> 00:11:21.590 align:start position:0% service that that is just as valuable as the<00:11:20.040> service<00:11:20.360> of<00:11:20.480> the<00:11:20.560> full<00:11:20.839> notes<00:11:21.320> of<00:11:21.399> course 00:11:21.590 --> 00:11:21.600 align:start position:0% the service of the full notes of course 00:11:21.600 --> 00:11:32.350 align:start position:0% the service of the full notes of course with<00:11:21.720> a<00:11:21.839> smaller<00:11:22.519> volume 00:11:32.350 --> 00:11:32.360 align:start position:0% 00:11:32.360 --> 00:11:33.389 align:start position:0% and 00:11:33.389 --> 00:11:33.399 align:start position:0% and 00:11:33.399 --> 00:11:36.710 align:start position:0% and uh<00:11:34.399> uh<00:11:34.760> I<00:11:35.040> so<00:11:35.240> far<00:11:35.440> I<00:11:35.519> have<00:11:35.680> only<00:11:35.920> talked<00:11:36.200> about 00:11:36.710 --> 00:11:36.720 align:start position:0% uh uh I so far I have only talked about 00:11:36.720 --> 00:11:41.150 align:start position:0% uh uh I so far I have only talked about uh<00:11:37.519> the<00:11:38.519> uh<00:11:39.399> distribution<00:11:40.279> and<00:11:40.600> storage<00:11:41.000> of 00:11:41.150 --> 00:11:41.160 align:start position:0% uh the uh distribution and storage of 00:11:41.160 --> 00:11:44.990 align:start position:0% uh the uh distribution and storage of the<00:11:41.320> state<00:11:42.160> and<00:11:42.639> we<00:11:42.880> we<00:11:43.000> also<00:11:43.279> have<00:11:43.399> to<00:11:43.920> uh<00:11:44.720> uh 00:11:44.990 --> 00:11:45.000 align:start position:0% the state and we we also have to uh uh 00:11:45.000 --> 00:11:47.310 align:start position:0% the state and we we also have to uh uh made<00:11:45.440> make<00:11:45.839> the<00:11:46.320> the<00:11:46.560> the<00:11:46.800> the<00:11:47.000> actual 00:11:47.310 --> 00:11:47.320 align:start position:0% made make the the the the actual 00:11:47.320 --> 00:11:50.230 align:start position:0% made make the the the the actual blockchain<00:11:47.920> accessible<00:11:48.839> which<00:11:49.240> uh<00:11:49.600> includes 00:11:50.230 --> 00:11:50.240 align:start position:0% blockchain accessible which uh includes 00:11:50.240 --> 00:11:54.430 align:start position:0% blockchain accessible which uh includes the<00:11:50.920> uh<00:11:51.839> transactions<00:11:52.839> and<00:11:53.079> the<00:11:53.880> receipts 00:11:54.430 --> 00:11:54.440 align:start position:0% the uh transactions and the receipts 00:11:54.440 --> 00:11:56.590 align:start position:0% the uh transactions and the receipts belonging<00:11:54.839> to<00:11:55.040> those<00:11:55.240> transactions<00:11:56.120> for<00:11:56.360> each 00:11:56.590 --> 00:11:56.600 align:start position:0% belonging to those transactions for each 00:11:56.600 --> 00:11:59.310 align:start position:0% belonging to those transactions for each block<00:11:57.320> this<00:11:57.440> is<00:11:57.600> a<00:11:57.920> much<00:11:58.079> easier<00:11:58.560> problem<00:11:58.880> than 00:11:59.310 --> 00:11:59.320 align:start position:0% block this is a much easier problem than 00:11:59.320 --> 00:12:02.990 align:start position:0% block this is a much easier problem than Distributing<00:11:59.839> the<00:12:00.160> state<00:12:01.160> for<00:12:01.440> this<00:12:01.959> the<00:12:02.440> the 00:12:02.990 --> 00:12:03.000 align:start position:0% Distributing the state for this the the 00:12:03.000 --> 00:12:06.470 align:start position:0% Distributing the state for this the the uh<00:12:03.920> the<00:12:04.120> traditional<00:12:04.639> DH<00:12:05.279> approach<00:12:05.639> is<00:12:06.240> just 00:12:06.470 --> 00:12:06.480 align:start position:0% uh the traditional DH approach is just 00:12:06.480 --> 00:12:10.350 align:start position:0% uh the traditional DH approach is just as<00:12:06.760> efficient<00:12:07.360> as<00:12:07.600> as<00:12:07.760> any<00:12:08.440> but<00:12:08.839> uh<00:12:09.639> maybe<00:12:10.160> if 00:12:10.350 --> 00:12:10.360 align:start position:0% as efficient as as any but uh maybe if 00:12:10.360 --> 00:12:14.069 align:start position:0% as efficient as as any but uh maybe if we<00:12:10.680> we<00:12:11.000> we<00:12:11.600> uh<00:12:12.079> we<00:12:12.240> already<00:12:12.600> have<00:12:12.959> uh<00:12:13.920> have 00:12:14.069 --> 00:12:14.079 align:start position:0% we we we uh we already have uh have 00:12:14.079 --> 00:12:17.269 align:start position:0% we we we uh we already have uh have peers<00:12:14.920> uh<00:12:15.040> who<00:12:15.240> are<00:12:15.720> who<00:12:15.920> who<00:12:16.079> have<00:12:16.639> ranges 00:12:17.269 --> 00:12:17.279 align:start position:0% peers uh who are who who have ranges 00:12:17.279 --> 00:12:20.269 align:start position:0% peers uh who are who who have ranges assigned<00:12:17.639> to<00:12:17.839> them<00:12:18.639> uh<00:12:19.240> it<00:12:19.519> it<00:12:19.639> is<00:12:19.880> it<00:12:19.959> might<00:12:20.120> be 00:12:20.269 --> 00:12:20.279 align:start position:0% assigned to them uh it it is it might be 00:12:20.279 --> 00:12:22.870 align:start position:0% assigned to them uh it it is it might be beneficial<00:12:20.839> to<00:12:21.360> store<00:12:21.880> every<00:12:22.199> transaction 00:12:22.870 --> 00:12:22.880 align:start position:0% beneficial to store every transaction 00:12:22.880 --> 00:12:26.990 align:start position:0% beneficial to store every transaction and<00:12:23.240> especially<00:12:24.000> rece<00:12:24.240> it<00:12:25.040> uh<00:12:25.600> by<00:12:26.000> uh<00:12:26.399> referenc 00:12:26.990 --> 00:12:27.000 align:start position:0% and especially rece it uh by uh referenc 00:12:27.000 --> 00:12:29.590 align:start position:0% and especially rece it uh by uh referenc by<00:12:27.199> the<00:12:27.560> block<00:12:27.920> block<00:12:28.240> hash<00:12:28.839> of<00:12:28.959> the<00:12:29.199> block 00:12:29.590 --> 00:12:29.600 align:start position:0% by the block block hash of the block 00:12:29.600 --> 00:12:31.910 align:start position:0% by the block block hash of the block they<00:12:29.720> are<00:12:29.959> belonging<00:12:30.399> to<00:12:31.000> because<00:12:31.399> uh<00:12:31.680> if<00:12:31.800> we 00:12:31.910 --> 00:12:31.920 align:start position:0% they are belonging to because uh if we 00:12:31.920 --> 00:12:36.350 align:start position:0% they are belonging to because uh if we are<00:12:32.920> uh<00:12:33.920> uh<00:12:34.399> processing<00:12:34.880> logs<00:12:35.519> yeah<00:12:35.760> SL<00:12:36.000> cents 00:12:36.350 --> 00:12:36.360 align:start position:0% are uh uh processing logs yeah SL cents 00:12:36.360 --> 00:12:38.750 align:start position:0% are uh uh processing logs yeah SL cents definitely<00:12:36.720> need<00:12:36.880> to<00:12:37.399> process<00:12:37.839> logs 00:12:38.750 --> 00:12:38.760 align:start position:0% definitely need to process logs 00:12:38.760 --> 00:12:42.110 align:start position:0% definitely need to process logs efficiently<00:12:39.760> uh<00:12:40.320> then<00:12:41.160> then<00:12:41.320> log<00:12:41.560> processing 00:12:42.110 --> 00:12:42.120 align:start position:0% efficiently uh then then log processing 00:12:42.120 --> 00:12:44.670 align:start position:0% efficiently uh then then log processing consists<00:12:42.519> of<00:12:42.839> checking<00:12:43.399> Bloom<00:12:43.720> filters<00:12:44.480> and 00:12:44.670 --> 00:12:44.680 align:start position:0% consists of checking Bloom filters and 00:12:44.680 --> 00:12:46.910 align:start position:0% consists of checking Bloom filters and if<00:12:44.839> we<00:12:44.959> are<00:12:45.560> uh<00:12:45.720> finding<00:12:46.040> a<00:12:46.199> positive<00:12:46.560> match<00:12:46.800> we 00:12:46.910 --> 00:12:46.920 align:start position:0% if we are uh finding a positive match we 00:12:46.920 --> 00:12:48.430 align:start position:0% if we are uh finding a positive match we have<00:12:47.040> to<00:12:47.160> download<00:12:47.600> all<00:12:47.760> the<00:12:47.920> receipts 00:12:48.430 --> 00:12:48.440 align:start position:0% have to download all the receipts 00:12:48.440 --> 00:12:51.990 align:start position:0% have to download all the receipts belonging<00:12:48.839> to<00:12:49.040> a<00:12:49.199> to<00:12:49.320> a<00:12:49.440> block<00:12:50.079> so<00:12:50.600> uh<00:12:51.040> storing 00:12:51.990 --> 00:12:52.000 align:start position:0% belonging to a to a block so uh storing 00:12:52.000 --> 00:12:54.269 align:start position:0% belonging to a to a block so uh storing storing<00:12:52.600> the<00:12:52.959> the<00:12:53.240> the<00:12:53.399> receips<00:12:53.800> belonging<00:12:54.120> to 00:12:54.269 --> 00:12:54.279 align:start position:0% storing the the the receips belonging to 00:12:54.279 --> 00:12:57.590 align:start position:0% storing the the the receips belonging to one<00:12:54.440> block<00:12:54.800> at<00:12:54.959> one<00:12:55.199> place<00:12:55.760> might<00:12:55.959> be<00:12:56.079> a<00:12:56.199> good 00:12:57.590 --> 00:12:57.600 align:start position:0% one block at one place might be a good 00:12:57.600 --> 00:12:59.710 align:start position:0% one block at one place might be a good idea<00:12:58.600> uh 00:12:59.710 --> 00:12:59.720 align:start position:0% idea uh 00:12:59.720 --> 00:13:03.269 align:start position:0% idea uh and<00:12:59.959> it<00:13:00.079> is<00:13:00.279> also<00:13:00.760> uh<00:13:00.959> worth<00:13:01.279> mentioning<00:13:02.240> that 00:13:03.269 --> 00:13:03.279 align:start position:0% and it is also uh worth mentioning that 00:13:03.279 --> 00:13:09.110 align:start position:0% and it is also uh worth mentioning that uh<00:13:04.360> uh<00:13:05.360> the<00:13:06.519> relaying<00:13:07.519> of<00:13:08.000> transaction 00:13:09.110 --> 00:13:09.120 align:start position:0% uh uh the relaying of transaction 00:13:09.120 --> 00:13:13.829 align:start position:0% uh uh the relaying of transaction transactions<00:13:10.560> uh<00:13:11.560> can<00:13:12.040> be<00:13:12.600> uh<00:13:13.000> how<00:13:13.240> how<00:13:13.440> how<00:13:13.560> we 00:13:13.829 --> 00:13:13.839 align:start position:0% transactions uh can be uh how how how we 00:13:13.839 --> 00:13:15.350 align:start position:0% transactions uh can be uh how how how we how<00:13:13.959> we<00:13:14.040> should<00:13:14.240> approach<00:13:14.560> this<00:13:14.760> problem<00:13:15.040> in<00:13:15.199> a 00:13:15.350 --> 00:13:15.360 align:start position:0% how we should approach this problem in a 00:13:15.360 --> 00:13:16.870 align:start position:0% how we should approach this problem in a network<00:13:15.800> where<00:13:15.920> we<00:13:16.040> have<00:13:16.199> a<00:13:16.360> lot<00:13:16.519> of<00:13:16.639> light 00:13:16.870 --> 00:13:16.880 align:start position:0% network where we have a lot of light 00:13:16.880 --> 00:13:19.550 align:start position:0% network where we have a lot of light nodes<00:13:17.880> uh<00:13:18.199> if<00:13:18.320> we<00:13:18.480> have<00:13:18.720> much<00:13:18.880> more<00:13:19.079> light<00:13:19.279> noes 00:13:19.550 --> 00:13:19.560 align:start position:0% nodes uh if we have much more light noes 00:13:19.560 --> 00:13:21.509 align:start position:0% nodes uh if we have much more light noes than<00:13:19.680> full<00:13:19.920> nodes<00:13:20.320> which<00:13:20.720> will<00:13:20.959> hopefully<00:13:21.360> be 00:13:21.509 --> 00:13:21.519 align:start position:0% than full nodes which will hopefully be 00:13:21.519 --> 00:13:25.269 align:start position:0% than full nodes which will hopefully be the<00:13:21.680> case<00:13:21.920> in<00:13:22.040> a<00:13:22.120> healthy<00:13:22.800> network<00:13:23.800> uh<00:13:24.760> we<00:13:24.920> can 00:13:25.269 --> 00:13:25.279 align:start position:0% the case in a healthy network uh we can 00:13:25.279 --> 00:13:27.870 align:start position:0% the case in a healthy network uh we can um<00:13:26.120> we<00:13:26.360> we<00:13:26.440> will<00:13:26.680> probably<00:13:27.000> have<00:13:27.120> to<00:13:27.360> propagate 00:13:27.870 --> 00:13:27.880 align:start position:0% um we we will probably have to propagate 00:13:27.880 --> 00:13:29.590 align:start position:0% um we we will probably have to propagate every<00:13:28.040> new<00:13:28.279> transaction<00:13:28.720> to<00:13:28.839> the<00:13:29.240> Network 00:13:29.590 --> 00:13:29.600 align:start position:0% every new transaction to the Network 00:13:29.600 --> 00:13:32.350 align:start position:0% every new transaction to the Network through<00:13:29.839> multiple<00:13:30.519> multiple<00:13:31.000> light<00:13:31.240> nodes<00:13:32.240> uh 00:13:32.350 --> 00:13:32.360 align:start position:0% through multiple multiple light nodes uh 00:13:32.360 --> 00:13:34.150 align:start position:0% through multiple multiple light nodes uh because<00:13:32.639> most<00:13:32.800> of<00:13:32.920> them<00:13:33.079> won't<00:13:33.279> have<00:13:33.480> direct 00:13:34.150 --> 00:13:34.160 align:start position:0% because most of them won't have direct 00:13:34.160 --> 00:13:36.790 align:start position:0% because most of them won't have direct access<00:13:34.399> to<00:13:34.519> a<00:13:34.600> full<00:13:34.839> node<00:13:35.480> and<00:13:35.639> if<00:13:35.720> we<00:13:35.920> do<00:13:36.160> that 00:13:36.790 --> 00:13:36.800 align:start position:0% access to a full node and if we do that 00:13:36.800 --> 00:13:39.189 align:start position:0% access to a full node and if we do that it<00:13:37.120> it<00:13:37.199> would<00:13:37.360> be<00:13:37.519> beneficial<00:13:38.040> to<00:13:38.240> demand<00:13:38.920> that 00:13:39.189 --> 00:13:39.199 align:start position:0% it it would be beneficial to demand that 00:13:39.199 --> 00:13:41.870 align:start position:0% it it would be beneficial to demand that every<00:13:39.440> new<00:13:39.680> transaction<00:13:40.440> is<00:13:40.760> propagated<00:13:41.760> uh 00:13:41.870 --> 00:13:41.880 align:start position:0% every new transaction is propagated uh 00:13:41.880 --> 00:13:45.629 align:start position:0% every new transaction is propagated uh through<00:13:42.120> the<00:13:42.360> peers<00:13:43.160> whose<00:13:44.000> address<00:13:44.639> ranges 00:13:45.629 --> 00:13:45.639 align:start position:0% through the peers whose address ranges 00:13:45.639 --> 00:13:48.670 align:start position:0% through the peers whose address ranges include<00:13:46.600> the<00:13:46.920> account<00:13:47.600> that<00:13:47.800> has<00:13:47.959> signed<00:13:48.440> the 00:13:48.670 --> 00:13:48.680 align:start position:0% include the account that has signed the 00:13:48.680 --> 00:13:52.189 align:start position:0% include the account that has signed the actual<00:13:49.480> transaction<00:13:50.480> the<00:13:50.959> uh<00:13:51.560> it<00:13:51.680> is<00:13:51.920> it<00:13:52.040> is 00:13:52.189 --> 00:13:52.199 align:start position:0% actual transaction the uh it is it is 00:13:52.199 --> 00:13:54.910 align:start position:0% actual transaction the uh it is it is very<00:13:52.360> useful<00:13:53.079> because<00:13:53.560> this<00:13:53.720> way<00:13:54.120> every<00:13:54.680> every 00:13:54.910 --> 00:13:54.920 align:start position:0% very useful because this way every every 00:13:54.920 --> 00:13:57.430 align:start position:0% very useful because this way every every propagating<00:13:55.560> every<00:13:55.720> forwarding<00:13:56.360> peer<00:13:56.959> can 00:13:57.430 --> 00:13:57.440 align:start position:0% propagating every forwarding peer can 00:13:57.440 --> 00:13:59.790 align:start position:0% propagating every forwarding peer can check<00:13:57.839> the<00:13:58.519> validity<00:13:58.880> of<00:13:59.120> the 00:13:59.790 --> 00:13:59.800 align:start position:0% check the validity of the 00:13:59.800 --> 00:14:01.790 align:start position:0% check the validity of the transaction<00:14:00.800> uh<00:14:00.920> because<00:14:01.360> they<00:14:01.519> have 00:14:01.790 --> 00:14:01.800 align:start position:0% transaction uh because they have 00:14:01.800 --> 00:14:03.710 align:start position:0% transaction uh because they have information<00:14:02.399> about<00:14:02.839> the<00:14:03.079> account<00:14:03.399> that<00:14:03.560> has 00:14:03.710 --> 00:14:03.720 align:start position:0% information about the account that has 00:14:03.720 --> 00:14:05.949 align:start position:0% information about the account that has signed<00:14:04.040> it<00:14:04.639> and<00:14:04.880> the<00:14:05.000> checking<00:14:05.279> the<00:14:05.440> validity 00:14:05.949 --> 00:14:05.959 align:start position:0% signed it and the checking the validity 00:14:05.959 --> 00:14:08.030 align:start position:0% signed it and the checking the validity mostly<00:14:06.279> consists<00:14:06.759> of<00:14:07.360> checking<00:14:07.800> the 00:14:08.030 --> 00:14:08.040 align:start position:0% mostly consists of checking the 00:14:08.040 --> 00:14:11.990 align:start position:0% mostly consists of checking the available<00:14:08.839> uh<00:14:09.199> funds<00:14:10.199> uh<00:14:10.399> of<00:14:10.639> the<00:14:10.920> the<00:14:11.079> signer 00:14:11.990 --> 00:14:12.000 align:start position:0% available uh funds uh of the the signer 00:14:12.000 --> 00:14:15.629 align:start position:0% available uh funds uh of the the signer and<00:14:12.480> uh<00:14:12.839> and<00:14:13.040> the<00:14:13.279> transaction<00:14:14.160> nors<00:14:15.160> so<00:14:15.360> if 00:14:15.629 --> 00:14:15.639 align:start position:0% and uh and the transaction nors so if 00:14:15.639 --> 00:14:18.310 align:start position:0% and uh and the transaction nors so if every<00:14:16.199> propagating<00:14:17.199> light<00:14:17.480> note 00:14:18.310 --> 00:14:18.320 align:start position:0% every propagating light note 00:14:18.320 --> 00:14:22.670 align:start position:0% every propagating light note can<00:14:19.519> uh<00:14:20.519> uh<00:14:21.000> both<00:14:21.519> check<00:14:21.920> the<00:14:22.320> account 00:14:22.670 --> 00:14:22.680 align:start position:0% can uh uh both check the account 00:14:22.680 --> 00:14:25.389 align:start position:0% can uh uh both check the account balances<00:14:23.160> and<00:14:23.360> nones<00:14:24.000> and<00:14:24.160> also<00:14:24.680> do<00:14:24.880> some 00:14:25.389 --> 00:14:25.399 align:start position:0% balances and nones and also do some 00:14:25.399 --> 00:14:28.629 align:start position:0% balances and nones and also do some filtering<00:14:25.920> and<00:14:26.120> ordering<00:14:26.959> by<00:14:27.240> the<00:14:27.839> gas<00:14:28.160> price 00:14:28.629 --> 00:14:28.639 align:start position:0% filtering and ordering by the gas price 00:14:28.639 --> 00:14:32.990 align:start position:0% filtering and ordering by the gas price of<00:14:29.399> the<00:14:30.240> uh<00:14:30.480> by<00:14:30.680> the<00:14:30.880> transaction<00:14:31.600> Creator<00:14:32.600> uh 00:14:32.990 --> 00:14:33.000 align:start position:0% of the uh by the transaction Creator uh 00:14:33.000 --> 00:14:35.389 align:start position:0% of the uh by the transaction Creator uh this<00:14:33.279> this<00:14:33.560> forms<00:14:33.959> a<00:14:34.160> very<00:14:34.480> effective<00:14:35.040> spam 00:14:35.389 --> 00:14:35.399 align:start position:0% this this forms a very effective spam 00:14:35.399 --> 00:14:37.990 align:start position:0% this this forms a very effective spam protection<00:14:36.040> for<00:14:36.360> the<00:14:36.720> from<00:14:36.920> the<00:14:37.120> consensus 00:14:37.990 --> 00:14:38.000 align:start position:0% protection for the from the consensus 00:14:38.000 --> 00:14:40.550 align:start position:0% protection for the from the consensus network<00:14:39.000> uh<00:14:39.399> by<00:14:39.560> only<00:14:39.839> forwarding 00:14:40.550 --> 00:14:40.560 align:start position:0% network uh by only forwarding 00:14:40.560 --> 00:14:42.550 align:start position:0% network uh by only forwarding transactions<00:14:41.120> to<00:14:41.279> the<00:14:41.480> main<00:14:41.759> Network<00:14:42.440> which 00:14:42.550 --> 00:14:42.560 align:start position:0% transactions to the main Network which 00:14:42.560 --> 00:14:45.990 align:start position:0% transactions to the main Network which will<00:14:42.839> probably<00:14:43.240> be<00:14:43.759> actually<00:14:44.759> included<00:14:45.759> in 00:14:45.990 --> 00:14:46.000 align:start position:0% will probably be actually included in 00:14:46.000 --> 00:14:51.350 align:start position:0% will probably be actually included in the<00:14:46.279> in<00:14:46.360> the<00:14:46.519> canonical 00:14:51.350 --> 00:14:51.360 align:start position:0% 00:14:51.360 --> 00:14:56.350 align:start position:0% chain<00:14:52.360> and<00:14:53.079> uh<00:14:54.079> finally<00:14:54.759> to<00:14:55.360> uh<00:14:55.560> conclude<00:14:55.959> my 00:14:56.350 --> 00:14:56.360 align:start position:0% chain and uh finally to uh conclude my 00:14:56.360 --> 00:14:57.150 align:start position:0% chain and uh finally to uh conclude my uh 00:14:57.150 --> 00:14:57.160 align:start position:0% uh 00:14:57.160 --> 00:15:00.150 align:start position:0% uh presentation<00:14:58.160> uh<00:14:58.480> I<00:14:58.560> would<00:14:58.720> like<00:14:58.880> to<00:14:59.040> to<00:14:59.519> uh<00:15:00.000> uh 00:15:00.150 --> 00:15:00.160 align:start position:0% presentation uh I would like to to uh uh 00:15:00.160 --> 00:15:03.829 align:start position:0% presentation uh I would like to to uh uh talk<00:15:00.440> about<00:15:00.920> our<00:15:01.240> future<00:15:01.759> B<00:15:02.320> uh<00:15:02.759> give<00:15:02.959> a<00:15:03.399> quick 00:15:03.829 --> 00:15:03.839 align:start position:0% talk about our future B uh give a quick 00:15:03.839 --> 00:15:07.350 align:start position:0% talk about our future B uh give a quick road<00:15:04.160> map<00:15:04.480> of<00:15:04.800> uh<00:15:05.440> of<00:15:05.720> of<00:15:05.959> of<00:15:06.160> of<00:15:06.360> of<00:15:06.600> the<00:15:06.839> future 00:15:07.350 --> 00:15:07.360 align:start position:0% road map of uh of of of of of the future 00:15:07.360 --> 00:15:10.030 align:start position:0% road map of uh of of of of of the future developments<00:15:08.079> as<00:15:08.360> I<00:15:08.519> currently<00:15:08.920> see<00:15:09.199> it<00:15:09.880> we 00:15:10.030 --> 00:15:10.040 align:start position:0% developments as I currently see it we 00:15:10.040 --> 00:15:12.870 align:start position:0% developments as I currently see it we have<00:15:10.199> planned<00:15:10.639> several<00:15:11.040> stages<00:15:11.519> of<00:15:11.880> release 00:15:12.870 --> 00:15:12.880 align:start position:0% have planned several stages of release 00:15:12.880 --> 00:15:15.389 align:start position:0% have planned several stages of release uh<00:15:13.240> the<00:15:13.399> first<00:15:13.680> stage<00:15:14.639> uh<00:15:14.880> which<00:15:15.079> is<00:15:15.279> which 00:15:15.389 --> 00:15:15.399 align:start position:0% uh the first stage uh which is which 00:15:15.399 --> 00:15:17.870 align:start position:0% uh the first stage uh which is which should<00:15:15.600> hopefully<00:15:16.000> be<00:15:16.320> ready<00:15:17.079> pretty<00:15:17.519> pretty 00:15:17.870 --> 00:15:17.880 align:start position:0% should hopefully be ready pretty pretty 00:15:17.880 --> 00:15:20.790 align:start position:0% should hopefully be ready pretty pretty pretty<00:15:18.079> soon<00:15:19.079> uh<00:15:19.440> may<00:15:19.639> be<00:15:20.000> released<00:15:20.399> in<00:15:20.519> our 00:15:20.790 --> 00:15:20.800 align:start position:0% pretty soon uh may be released in our 00:15:20.800 --> 00:15:23.350 align:start position:0% pretty soon uh may be released in our next<00:15:21.040> version<00:15:21.279> of<00:15:21.440> the<00:15:21.680> go<00:15:21.839> etherum<00:15:22.320> client<00:15:23.120> we 00:15:23.350 --> 00:15:23.360 align:start position:0% next version of the go etherum client we 00:15:23.360 --> 00:15:25.949 align:start position:0% next version of the go etherum client we already<00:15:23.880> be<00:15:24.040> able<00:15:24.440> to<00:15:24.959> uh<00:15:25.079> retrieve<00:15:25.519> data<00:15:25.759> on 00:15:25.949 --> 00:15:25.959 align:start position:0% already be able to uh retrieve data on 00:15:25.959 --> 00:15:27.910 align:start position:0% already be able to uh retrieve data on demand<00:15:26.399> to<00:15:26.680> the<00:15:26.880> first<00:15:27.160> version<00:15:27.440> of<00:15:27.560> the<00:15:27.680> last 00:15:27.910 --> 00:15:27.920 align:start position:0% demand to the first version of the last 00:15:27.920 --> 00:15:30.710 align:start position:0% demand to the first version of the last protocol<00:15:29.199> uh<00:15:29.680> right<00:15:29.839> now<00:15:30.000> only<00:15:30.279> from<00:15:30.560> from 00:15:30.710 --> 00:15:30.720 align:start position:0% protocol uh right now only from from 00:15:30.720 --> 00:15:33.829 align:start position:0% protocol uh right now only from from Full<00:15:31.000> nodes<00:15:31.839> and<00:15:32.079> probably<00:15:32.480> also<00:15:33.040> be<00:15:33.199> able<00:15:33.480> to 00:15:33.829 --> 00:15:33.839 align:start position:0% Full nodes and probably also be able to 00:15:33.839 --> 00:15:35.189 align:start position:0% Full nodes and probably also be able to relay 00:15:35.189 --> 00:15:35.199 align:start position:0% relay 00:15:35.199 --> 00:15:38.350 align:start position:0% relay transactions<00:15:36.199> uh<00:15:36.720> this<00:15:37.079> will<00:15:37.399> be<00:15:37.839> a<00:15:38.000> more<00:15:38.160> or 00:15:38.350 --> 00:15:38.360 align:start position:0% transactions uh this will be a more or 00:15:38.360 --> 00:15:41.749 align:start position:0% transactions uh this will be a more or less<00:15:38.680> usable<00:15:39.279> light<00:15:39.600> client<00:15:40.600> but<00:15:41.000> uh<00:15:41.440> full 00:15:41.749 --> 00:15:41.759 align:start position:0% less usable light client but uh full 00:15:41.759 --> 00:15:43.990 align:start position:0% less usable light client but uh full functionality<00:15:42.720> will<00:15:42.920> be<00:15:43.079> reached<00:15:43.480> at<00:15:43.680> stage 00:15:43.990 --> 00:15:44.000 align:start position:0% functionality will be reached at stage 00:15:44.000 --> 00:15:46.910 align:start position:0% functionality will be reached at stage two<00:15:44.720> which<00:15:44.959> will<00:15:45.199> also<00:15:45.480> be<00:15:45.720> able<00:15:46.040> to<00:15:46.600> process 00:15:46.910 --> 00:15:46.920 align:start position:0% two which will also be able to process 00:15:46.920 --> 00:15:51.550 align:start position:0% two which will also be able to process and<00:15:47.079> filter<00:15:47.600> logs<00:15:48.600> and<00:15:49.000> uh<00:15:49.399> probably<00:15:50.360> the<00:15:51.120> uh 00:15:51.550 --> 00:15:51.560 align:start position:0% and filter logs and uh probably the uh 00:15:51.560 --> 00:15:53.790 align:start position:0% and filter logs and uh probably the uh multi<00:15:51.959> sampling<00:15:52.560> header<00:15:52.839> retal<00:15:53.279> will<00:15:53.480> also<00:15:53.680> be 00:15:53.790 --> 00:15:53.800 align:start position:0% multi sampling header retal will also be 00:15:53.800 --> 00:15:55.829 align:start position:0% multi sampling header retal will also be included<00:15:54.319> which<00:15:54.440> is<00:15:54.720> what<00:15:54.880> I<00:15:55.079> talked<00:15:55.399> about 00:15:55.829 --> 00:15:55.839 align:start position:0% included which is what I talked about 00:15:55.839 --> 00:15:58.230 align:start position:0% included which is what I talked about before<00:15:56.639> uh<00:15:56.759> fetching<00:15:57.240> headers<00:15:57.600> from<00:15:57.800> multiple 00:15:58.230 --> 00:15:58.240 align:start position:0% before uh fetching headers from multiple 00:15:58.240 --> 00:16:00.189 align:start position:0% before uh fetching headers from multiple PS<00:15:58.560> to<00:15:59.040> increase 00:16:00.189 --> 00:16:00.199 align:start position:0% PS to increase 00:16:00.199 --> 00:16:03.749 align:start position:0% PS to increase security<00:16:01.199> uh<00:16:01.959> this<00:16:02.160> release<00:16:02.720> will<00:16:03.240> uh<00:16:03.399> still 00:16:03.749 --> 00:16:03.759 align:start position:0% security uh this release will uh still 00:16:03.759 --> 00:16:05.790 align:start position:0% security uh this release will uh still have<00:16:04.160> uh<00:16:05.120> uh<00:16:05.240> will<00:16:05.399> still<00:16:05.639> have 00:16:05.790 --> 00:16:05.800 align:start position:0% have uh uh will still have 00:16:05.800 --> 00:16:08.030 align:start position:0% have uh uh will still have centralization<00:16:06.560> issues<00:16:07.360> with<00:16:07.560> very<00:16:07.800> great 00:16:08.030 --> 00:16:08.040 align:start position:0% centralization issues with very great 00:16:08.040 --> 00:16:11.069 align:start position:0% centralization issues with very great networks<00:16:08.639> but<00:16:08.880> for<00:16:09.519> for<00:16:09.759> the<00:16:10.120> time<00:16:10.480> coming<00:16:10.959> I 00:16:11.069 --> 00:16:11.079 align:start position:0% networks but for for the time coming I 00:16:11.079 --> 00:16:13.230 align:start position:0% networks but for for the time coming I think<00:16:11.519> it<00:16:11.639> will<00:16:11.880> be<00:16:12.160> it<00:16:12.279> will<00:16:12.480> be<00:16:12.720> quite 00:16:13.230 --> 00:16:13.240 align:start position:0% think it will be it will be quite 00:16:13.240 --> 00:16:16.189 align:start position:0% think it will be it will be quite sufficient<00:16:14.240> and<00:16:14.600> uh<00:16:15.079> in<00:16:15.199> the<00:16:15.319> subsequent 00:16:16.189 --> 00:16:16.199 align:start position:0% sufficient and uh in the subsequent 00:16:16.199 --> 00:16:19.110 align:start position:0% sufficient and uh in the subsequent stages<00:16:16.880> of<00:16:17.199> uh<00:16:17.639> development<00:16:18.639> uh<00:16:18.759> we<00:16:18.880> should 00:16:19.110 --> 00:16:19.120 align:start position:0% stages of uh development uh we should 00:16:19.120 --> 00:16:21.590 align:start position:0% stages of uh development uh we should definitely<00:16:19.720> address<00:16:20.199> the<00:16:20.480> scalability 00:16:21.590 --> 00:16:21.600 align:start position:0% definitely address the scalability 00:16:21.600 --> 00:16:24.829 align:start position:0% definitely address the scalability issues<00:16:22.600> uh<00:16:23.199> it<00:16:23.360> is<00:16:23.800> uh<00:16:23.920> it<00:16:24.040> will<00:16:24.240> still<00:16:24.759> it 00:16:24.829 --> 00:16:24.839 align:start position:0% issues uh it is uh it will still it 00:16:24.839 --> 00:16:26.430 align:start position:0% issues uh it is uh it will still it should<00:16:25.079> still<00:16:25.440> be<00:16:25.600> up<00:16:25.720> for<00:16:25.959> discussion 00:16:26.430 --> 00:16:26.440 align:start position:0% should still be up for discussion 00:16:26.440 --> 00:16:29.150 align:start position:0% should still be up for discussion whether<00:16:26.759> we<00:16:27.399> try<00:16:27.639> to<00:16:27.800> go<00:16:28.000> with<00:16:28.199> the<00:16:28.600> regular 00:16:29.150 --> 00:16:29.160 align:start position:0% whether we try to go with the regular 00:16:29.160 --> 00:16:33.430 align:start position:0% whether we try to go with the regular traditional<00:16:29.639> DHT<00:16:30.240> approach<00:16:30.880> or<00:16:31.199> the<00:16:32.160> uh<00:16:33.040> uh 00:16:33.430 --> 00:16:33.440 align:start position:0% traditional DHT approach or the uh uh 00:16:33.440 --> 00:16:36.430 align:start position:0% traditional DHT approach or the uh uh State<00:16:34.440> splitting<00:16:35.000> by<00:16:35.319> by<00:16:35.519> by<00:16:35.680> state<00:16:35.920> Keys 00:16:36.430 --> 00:16:36.440 align:start position:0% State splitting by by by state Keys 00:16:36.440 --> 00:16:38.910 align:start position:0% State splitting by by by state Keys approach<00:16:37.199> whatever<00:16:37.680> we<00:16:37.839> have<00:16:37.959> to<00:16:38.279> we<00:16:38.440> have<00:16:38.560> to 00:16:38.910 --> 00:16:38.920 align:start position:0% approach whatever we have to we have to 00:16:38.920 --> 00:16:41.590 align:start position:0% approach whatever we have to we have to uh<00:16:39.040> develop<00:16:39.440> a<00:16:39.639> distributed<00:16:40.360> service<00:16:41.360> which 00:16:41.590 --> 00:16:41.600 align:start position:0% uh develop a distributed service which 00:16:41.600 --> 00:16:43.829 align:start position:0% uh develop a distributed service which all<00:16:42.079> which<00:16:42.319> which<00:16:42.480> also<00:16:42.759> includes<00:16:43.319> a<00:16:43.480> simple 00:16:43.829 --> 00:16:43.839 align:start position:0% all which which also includes a simple 00:16:43.839 --> 00:16:46.670 align:start position:0% all which which also includes a simple microp<00:16:44.160> payment<00:16:44.959> system<00:16:45.959> and<00:16:46.279> for<00:16:46.480> this 00:16:46.670 --> 00:16:46.680 align:start position:0% microp payment system and for this 00:16:46.680 --> 00:16:49.350 align:start position:0% microp payment system and for this purpose<00:16:47.319> we<00:16:47.440> can<00:16:47.639> probably<00:16:48.000> use<00:16:48.639> the<00:16:48.920> So-Cal 00:16:49.350 --> 00:16:49.360 align:start position:0% purpose we can probably use the So-Cal 00:16:49.360 --> 00:16:52.150 align:start position:0% purpose we can probably use the So-Cal swap<00:16:49.720> protocol<00:16:50.120> swarm<00:16:50.920> counting<00:16:51.360> protocol 00:16:52.150 --> 00:16:52.160 align:start position:0% swap protocol swarm counting protocol 00:16:52.160 --> 00:16:54.670 align:start position:0% swap protocol swarm counting protocol which<00:16:52.319> is<00:16:52.600> a<00:16:52.800> a<00:16:52.959> very<00:16:53.199> simple<00:16:53.600> but<00:16:53.800> very<00:16:54.000> useful 00:16:54.670 --> 00:16:54.680 align:start position:0% which is a a very simple but very useful 00:16:54.680 --> 00:16:59.790 align:start position:0% which is a a very simple but very useful uh<00:16:55.720> uh<00:16:56.720> useful<00:16:57.480> uh<00:16:58.440> kind<00:16:58.600> of<00:16:58.920> payment<00:16:59.199> Channel 00:16:59.790 --> 00:16:59.800 align:start position:0% uh uh useful uh kind of payment Channel 00:16:59.800 --> 00:17:02.470 align:start position:0% uh uh useful uh kind of payment Channel implementation<00:17:00.800> that<00:17:00.920> is<00:17:01.079> used<00:17:01.440> by<00:17:01.600> swarm<00:17:02.160> and 00:17:02.470 --> 00:17:02.480 align:start position:0% implementation that is used by swarm and 00:17:02.480 --> 00:17:04.909 align:start position:0% implementation that is used by swarm and uh<00:17:03.079> we<00:17:03.199> can<00:17:03.399> also<00:17:03.759> use<00:17:03.959> it<00:17:04.120> for<00:17:04.439> for<00:17:04.640> like 00:17:04.909 --> 00:17:04.919 align:start position:0% uh we can also use it for for like 00:17:04.919 --> 00:17:06.590 align:start position:0% uh we can also use it for for like client 00:17:06.590 --> 00:17:06.600 align:start position:0% client 00:17:06.600 --> 00:17:11.069 align:start position:0% client services<00:17:07.600> and<00:17:08.199> uh<00:17:09.199> by<00:17:09.679> uh<00:17:09.959> when<00:17:10.199> when<00:17:10.439> the<00:17:10.919> uh 00:17:11.069 --> 00:17:11.079 align:start position:0% services and uh by uh when when the uh 00:17:11.079 --> 00:17:13.230 align:start position:0% services and uh by uh when when the uh development<00:17:11.959> of<00:17:12.199> developments<00:17:12.720> of<00:17:12.880> the<00:17:13.000> proof 00:17:13.230 --> 00:17:13.240 align:start position:0% development of developments of the proof 00:17:13.240 --> 00:17:16.949 align:start position:0% development of developments of the proof of<00:17:13.360> State<00:17:13.640> consensus<00:17:14.160> protocol<00:17:14.839> uh<00:17:15.959> Advance 00:17:16.949 --> 00:17:16.959 align:start position:0% of State consensus protocol uh Advance 00:17:16.959 --> 00:17:19.710 align:start position:0% of State consensus protocol uh Advance we<00:17:17.079> can<00:17:17.319> also<00:17:17.959> uh<00:17:18.679> uh<00:17:18.839> employ<00:17:19.480> those 00:17:19.710 --> 00:17:19.720 align:start position:0% we can also uh uh employ those 00:17:19.720 --> 00:17:22.429 align:start position:0% we can also uh uh employ those mechanisms<00:17:20.720> uh<00:17:21.160> so<00:17:21.439> basically<00:17:21.880> porting<00:17:22.280> the 00:17:22.429 --> 00:17:22.439 align:start position:0% mechanisms uh so basically porting the 00:17:22.439 --> 00:17:24.590 align:start position:0% mechanisms uh so basically porting the light<00:17:22.679> client<00:17:23.120> to<00:17:23.400> proof<00:17:23.640> of<00:17:23.799> sake<00:17:24.280> will 00:17:24.590 --> 00:17:24.600 align:start position:0% light client to proof of sake will 00:17:24.600 --> 00:17:27.549 align:start position:0% light client to proof of sake will provide<00:17:25.160> a<00:17:25.360> much<00:17:25.559> better<00:17:26.000> protection<00:17:26.839> against 00:17:27.549 --> 00:17:27.559 align:start position:0% provide a much better protection against 00:17:27.559 --> 00:17:30.870 align:start position:0% provide a much better protection against uh<00:17:28.360> uh<00:17:29.000> against<00:17:29.520> fraudulent<00:17:30.120> nodes<00:17:30.600> and<00:17:30.760> the 00:17:30.870 --> 00:17:30.880 align:start position:0% uh uh against fraudulent nodes and the 00:17:30.880 --> 00:17:33.390 align:start position:0% uh uh against fraudulent nodes and the Cil<00:17:31.320> attacks<00:17:32.200> basically<00:17:32.799> it<00:17:32.919> works<00:17:33.160> as<00:17:33.280> a 00:17:33.390 --> 00:17:33.400 align:start position:0% Cil attacks basically it works as a 00:17:33.400 --> 00:17:36.070 align:start position:0% Cil attacks basically it works as a reputation<00:17:33.960> system<00:17:34.440> because<00:17:35.440> nodes<00:17:35.799> with<00:17:35.919> a 00:17:36.070 --> 00:17:36.080 align:start position:0% reputation system because nodes with a 00:17:36.080 --> 00:17:38.510 align:start position:0% reputation system because nodes with a stake<00:17:36.520> that<00:17:36.679> they<00:17:36.880> can<00:17:37.000> lose<00:17:37.600> by<00:17:38.000> trying<00:17:38.280> to 00:17:38.510 --> 00:17:38.520 align:start position:0% stake that they can lose by trying to 00:17:38.520 --> 00:17:40.909 align:start position:0% stake that they can lose by trying to attack<00:17:39.360> it<00:17:39.600> it<00:17:39.799> it<00:17:40.000> it<00:17:40.200> it<00:17:40.320> gives<00:17:40.559> them<00:17:40.760> some 00:17:40.909 --> 00:17:40.919 align:start position:0% attack it it it it it gives them some 00:17:40.919 --> 00:17:43.710 align:start position:0% attack it it it it it gives them some kind<00:17:41.080> of<00:17:41.240> reputation<00:17:42.200> and<00:17:42.520> definitely<00:17:43.000> makes 00:17:43.710 --> 00:17:43.720 align:start position:0% kind of reputation and definitely makes 00:17:43.720 --> 00:17:45.630 align:start position:0% kind of reputation and definitely makes attempted<00:17:44.320> attacks<00:17:44.880> more 00:17:45.630 --> 00:17:45.640 align:start position:0% attempted attacks more 00:17:45.640 --> 00:17:50.350 align:start position:0% attempted attacks more expensive<00:17:46.640> so<00:17:46.880> by<00:17:47.000> the<00:17:47.200> time<00:17:48.080> uh<00:17:49.080> uh<00:17:49.679> we<00:17:50.160> we 00:17:50.350 --> 00:17:50.360 align:start position:0% expensive so by the time uh uh we we 00:17:50.360 --> 00:17:52.029 align:start position:0% expensive so by the time uh uh we we will<00:17:50.559> reach<00:17:50.799> the<00:17:51.000> point<00:17:51.280> we<00:17:51.400> can<00:17:51.559> switch<00:17:51.840> over 00:17:52.029 --> 00:17:52.039 align:start position:0% will reach the point we can switch over 00:17:52.039 --> 00:17:54.590 align:start position:0% will reach the point we can switch over to<00:17:52.200> the<00:17:52.559> proof<00:17:52.760> of<00:17:52.960> the<00:17:53.120> consensus<00:17:54.000> consensus 00:17:54.590 --> 00:17:54.600 align:start position:0% to the proof of the consensus consensus 00:17:54.600 --> 00:17:57.789 align:start position:0% to the proof of the consensus consensus protocol<00:17:55.600> uh<00:17:56.000> we<00:17:56.159> will<00:17:56.480> hopefully<00:17:57.320> also<00:17:57.640> have 00:17:57.789 --> 00:17:57.799 align:start position:0% protocol uh we will hopefully also have 00:17:57.799 --> 00:17:59.430 align:start position:0% protocol uh we will hopefully also have a<00:17:58.000> massively<00:17:58.400> scalable 00:17:59.430 --> 00:17:59.440 align:start position:0% a massively scalable 00:17:59.440 --> 00:18:03.270 align:start position:0% a massively scalable and<00:18:00.320> and<00:18:00.679> secure<00:18:01.440> light<00:18:01.679> client<00:18:02.039> Network<00:18:02.440> too 00:18:03.270 --> 00:18:03.280 align:start position:0% and and secure light client Network too 00:18:03.280 --> 00:18:06.190 align:start position:0% and and secure light client Network too and<00:18:03.640> I<00:18:03.760> think<00:18:04.280> this<00:18:04.400> is<00:18:04.559> all<00:18:04.880> I<00:18:05.000> could<00:18:05.799> tell<00:18:06.000> you 00:18:06.190 --> 00:18:06.200 align:start position:0% and I think this is all I could tell you 00:18:06.200 --> 00:18:09.669 align:start position:0% and I think this is all I could tell you about<00:18:06.679> this<00:18:07.200> these<00:18:07.720> uh<00:18:08.720> developments<00:18:09.240> in<00:18:09.400> 20 00:18:09.669 --> 00:18:09.679 align:start position:0% about this these uh developments in 20 00:18:09.679 --> 00:18:12.700 align:start position:0% about this these uh developments in 20 minutes<00:18:10.120> so<00:18:10.440> thank<00:18:10.559> you<00:18:10.640> for<00:18:10.799> your<00:18:10.960> attention 00:18:12.700 --> 00:18:12.710 align:start position:0% minutes so thank you for your attention 00:18:12.710 --> 00:18:19.680 align:start position:0% minutes so thank you for your attention [Applause] 00:18:19.680 --> 00:18:19.690 align:start position:0% 00:18:19.690 --> 00:18:23.809 align:start position:0% [Music]