WEBVTT Kind: captions Language: en 00:00:09.190 --> 00:00:22.590 align:start position:0% [Music] 00:00:22.590 --> 00:00:22.600 align:start position:0% 00:00:22.600 --> 00:00:25.120 align:start position:0% hello<00:00:23.600> okay<00:00:24.170> great 00:00:25.120 --> 00:00:25.130 align:start position:0% hello okay great 00:00:25.130 --> 00:00:27.910 align:start position:0% hello okay great hello<00:00:25.850> everyone<00:00:26.690> my<00:00:26.870> name<00:00:27.020> is<00:00:27.200> Robert<00:00:27.680> Hobart 00:00:27.910 --> 00:00:27.920 align:start position:0% hello everyone my name is Robert Hobart 00:00:27.920 --> 00:00:30.670 align:start position:0% hello everyone my name is Robert Hobart Mayer<00:00:28.070> I<00:00:28.310> work<00:00:28.700> at<00:00:28.880> Paradis<00:00:29.360> technologies<00:00:29.930> and 00:00:30.670 --> 00:00:30.680 align:start position:0% Mayer I work at Paradis technologies and 00:00:30.680 --> 00:00:32.889 align:start position:0% Mayer I work at Paradis technologies and one<00:00:31.610> of<00:00:31.670> the<00:00:31.730> projects<00:00:32.149> that<00:00:32.210> I<00:00:32.329> worked<00:00:32.539> on<00:00:32.689> was 00:00:32.889 --> 00:00:32.899 align:start position:0% one of the projects that I worked on was 00:00:32.899 --> 00:00:35.650 align:start position:0% one of the projects that I worked on was a<00:00:33.200> light<00:00:33.530> client<00:00:33.980> for<00:00:34.190> aetherium<00:00:34.670> if<00:00:35.510> you're 00:00:35.650 --> 00:00:35.660 align:start position:0% a light client for aetherium if you're 00:00:35.660 --> 00:00:38.470 align:start position:0% a light client for aetherium if you're not<00:00:35.780> familiar<00:00:35.930> with<00:00:36.200> Paradis<00:00:37.360> basically<00:00:38.360> will 00:00:38.470 --> 00:00:38.480 align:start position:0% not familiar with Paradis basically will 00:00:38.480 --> 00:00:40.450 align:start position:0% not familiar with Paradis basically will be<00:00:38.510> billed<00:00:38.750> an<00:00:38.990> aetherium<00:00:39.680> node<00:00:39.890> so<00:00:40.220> i'm<00:00:40.280> gonna 00:00:40.450 --> 00:00:40.460 align:start position:0% be billed an aetherium node so i'm gonna 00:00:40.460 --> 00:00:42.310 align:start position:0% be billed an aetherium node so i'm gonna talk<00:00:40.610> about<00:00:40.670> one<00:00:41.180> mode<00:00:41.480> of<00:00:41.510> operation<00:00:42.110> of<00:00:42.200> that 00:00:42.310 --> 00:00:42.320 align:start position:0% talk about one mode of operation of that 00:00:42.320 --> 00:00:46.300 align:start position:0% talk about one mode of operation of that node<00:00:42.610> so<00:00:43.610> first<00:00:43.910> I'd<00:00:44.390> like<00:00:44.450> to<00:00:44.600> split<00:00:45.410> up<00:00:45.590> the 00:00:46.300 --> 00:00:46.310 align:start position:0% node so first I'd like to split up the 00:00:46.310 --> 00:00:49.170 align:start position:0% node so first I'd like to split up the classifications<00:00:47.300> of<00:00:47.510> aetherium<00:00:48.230> clients<00:00:48.680> so 00:00:49.170 --> 00:00:49.180 align:start position:0% classifications of aetherium clients so 00:00:49.180 --> 00:00:51.069 align:start position:0% classifications of aetherium clients so actually<00:00:50.180> we<00:00:50.300> can<00:00:50.450> split<00:00:50.690> these<00:00:50.780> pretty 00:00:51.069 --> 00:00:51.079 align:start position:0% actually we can split these pretty 00:00:51.079 --> 00:00:52.960 align:start position:0% actually we can split these pretty easily<00:00:51.440> into<00:00:51.680> three<00:00:51.860> categories<00:00:52.370> the<00:00:52.550> first 00:00:52.960 --> 00:00:52.970 align:start position:0% easily into three categories the first 00:00:52.970 --> 00:00:54.639 align:start position:0% easily into three categories the first would<00:00:53.329> be<00:00:53.420> a<00:00:53.450> full<00:00:53.720> node<00:00:53.960> so<00:00:54.230> when<00:00:54.380> you<00:00:54.470> run<00:00:54.590> a 00:00:54.639 --> 00:00:54.649 align:start position:0% would be a full node so when you run a 00:00:54.649 --> 00:00:56.560 align:start position:0% would be a full node so when you run a node<00:00:54.860> today<00:00:55.160> you're<00:00:55.760> mostly<00:00:56.030> just<00:00:56.239> running<00:00:56.510> a 00:00:56.560 --> 00:00:56.570 align:start position:0% node today you're mostly just running a 00:00:56.570 --> 00:00:58.240 align:start position:0% node today you're mostly just running a full<00:00:56.780> node<00:00:56.989> and<00:00:57.230> that<00:00:57.680> means<00:00:57.890> that<00:00:58.100> you 00:00:58.240 --> 00:00:58.250 align:start position:0% full node and that means that you 00:00:58.250 --> 00:01:00.459 align:start position:0% full node and that means that you download<00:00:59.030> all<00:00:59.210> the<00:00:59.390> block<00:00:59.570> headers<00:00:59.960> and<00:01:00.140> you 00:01:00.459 --> 00:01:00.469 align:start position:0% download all the block headers and you 00:01:00.469 --> 00:01:02.590 align:start position:0% download all the block headers and you check<00:01:00.649> the<00:01:00.770> consensus<00:01:01.280> process<00:01:01.460> and<00:01:01.940> then<00:01:02.480> you 00:01:02.590 --> 00:01:02.600 align:start position:0% check the consensus process and then you 00:01:02.600 --> 00:01:03.999 align:start position:0% check the consensus process and then you download<00:01:02.719> the<00:01:03.020> block<00:01:03.200> bodies<00:01:03.590> as<00:01:03.739> well<00:01:03.890> and 00:01:03.999 --> 00:01:04.009 align:start position:0% download the block bodies as well and 00:01:04.009 --> 00:01:05.830 align:start position:0% download the block bodies as well and you<00:01:04.100> check<00:01:04.280> that<00:01:04.460> all<00:01:04.549> the<00:01:04.720> transactions<00:01:05.720> have 00:01:05.830 --> 00:01:05.840 align:start position:0% you check that all the transactions have 00:01:05.840 --> 00:01:07.390 align:start position:0% you check that all the transactions have been<00:01:06.049> executed<00:01:06.470> correctly<00:01:06.799> and<00:01:07.190> that<00:01:07.280> they're 00:01:07.390 --> 00:01:07.400 align:start position:0% been executed correctly and that they're 00:01:07.400 --> 00:01:09.820 align:start position:0% been executed correctly and that they're actually<00:01:07.520> valid<00:01:08.350> and<00:01:09.350> this<00:01:09.500> gives<00:01:09.740> you 00:01:09.820 --> 00:01:09.830 align:start position:0% actually valid and this gives you 00:01:09.830 --> 00:01:11.380 align:start position:0% actually valid and this gives you basically<00:01:10.220> full<00:01:10.490> security<00:01:11.060> you've<00:01:11.180> checked 00:01:11.380 --> 00:01:11.390 align:start position:0% basically full security you've checked 00:01:11.390 --> 00:01:14.440 align:start position:0% basically full security you've checked absolutely<00:01:11.990> everything<00:01:12.440> you<00:01:12.530> can<00:01:13.120> but<00:01:14.120> what 00:01:14.440 --> 00:01:14.450 align:start position:0% absolutely everything you can but what 00:01:14.450 --> 00:01:16.510 align:start position:0% absolutely everything you can but what we've<00:01:14.570> seen<00:01:14.600> is<00:01:14.870> that<00:01:15.140> as<00:01:15.530> the<00:01:16.280> blockchain 00:01:16.510 --> 00:01:16.520 align:start position:0% we've seen is that as the blockchain 00:01:16.520 --> 00:01:19.600 align:start position:0% we've seen is that as the blockchain grows<00:01:16.909> heavier<00:01:17.299> and<00:01:17.479> longer<00:01:17.869> it<00:01:18.229> takes<00:01:18.860> a<00:01:19.100> very 00:01:19.600 --> 00:01:19.610 align:start position:0% grows heavier and longer it takes a very 00:01:19.610 --> 00:01:22.630 align:start position:0% grows heavier and longer it takes a very large<00:01:20.270> amount<00:01:20.479> of<00:01:20.690> time<00:01:20.900> resources<00:01:21.830> both<00:01:22.400> for 00:01:22.630 --> 00:01:22.640 align:start position:0% large amount of time resources both for 00:01:22.640 --> 00:01:24.940 align:start position:0% large amount of time resources both for storage<00:01:23.090> and<00:01:23.270> computation<00:01:23.540> and<00:01:24.049> memory<00:01:24.320> to 00:01:24.940 --> 00:01:24.950 align:start position:0% storage and computation and memory to 00:01:24.950 --> 00:01:28.060 align:start position:0% storage and computation and memory to actually<00:01:26.049> synchronize<00:01:27.049> a<00:01:27.080> full<00:01:27.530> client<00:01:27.770> and 00:01:28.060 --> 00:01:28.070 align:start position:0% actually synchronize a full client and 00:01:28.070 --> 00:01:33.580 align:start position:0% actually synchronize a full client and use<00:01:28.220> it<00:01:28.430> so<00:01:29.560> it's<00:01:30.560> not<00:01:30.799> exactly<00:01:31.990> user<00:01:32.990> friendly 00:01:33.580 --> 00:01:33.590 align:start position:0% use it so it's not exactly user friendly 00:01:33.590 --> 00:01:35.109 align:start position:0% use it so it's not exactly user friendly in<00:01:33.740> this<00:01:33.950> sense<00:01:34.189> so<00:01:34.430> if<00:01:34.549> you<00:01:34.670> wanted<00:01:34.850> to<00:01:34.970> run<00:01:35.060> a 00:01:35.109 --> 00:01:35.119 align:start position:0% in this sense so if you wanted to run a 00:01:35.119 --> 00:01:37.030 align:start position:0% in this sense so if you wanted to run a client<00:01:35.510> on<00:01:35.570> your<00:01:35.630> laptop<00:01:36.170> you<00:01:36.710> couldn't 00:01:37.030 --> 00:01:37.040 align:start position:0% client on your laptop you couldn't 00:01:37.040 --> 00:01:39.820 align:start position:0% client on your laptop you couldn't necessarily<00:01:37.189> run<00:01:37.850> a<00:01:38.090> full<00:01:38.659> node<00:01:38.869> so<00:01:39.439> the<00:01:39.680> other 00:01:39.820 --> 00:01:39.830 align:start position:0% necessarily run a full node so the other 00:01:39.830 --> 00:01:41.649 align:start position:0% necessarily run a full node so the other kind<00:01:40.070> of<00:01:40.130> client<00:01:40.490> that<00:01:40.610> we<00:01:40.729> talked<00:01:40.909> about<00:01:41.030> is<00:01:41.390> a 00:01:41.649 --> 00:01:41.659 align:start position:0% kind of client that we talked about is a 00:01:41.659 --> 00:01:43.630 align:start position:0% kind of client that we talked about is a light<00:01:42.110> client<00:01:42.590> so<00:01:42.740> in<00:01:42.830> a<00:01:42.890> light<00:01:43.070> client<00:01:43.490> what 00:01:43.630 --> 00:01:43.640 align:start position:0% light client so in a light client what 00:01:43.640 --> 00:01:46.270 align:start position:0% light client so in a light client what you<00:01:43.729> do<00:01:43.909> is<00:01:44.119> you<00:01:44.600> verify<00:01:45.110> the<00:01:45.650> block<00:01:45.860> headers 00:01:46.270 --> 00:01:46.280 align:start position:0% you do is you verify the block headers 00:01:46.280 --> 00:01:48.460 align:start position:0% you do is you verify the block headers but<00:01:46.790> you're<00:01:46.939> not<00:01:47.090> checking<00:01:47.509> the<00:01:47.780> transactions 00:01:48.460 --> 00:01:48.470 align:start position:0% but you're not checking the transactions 00:01:48.470 --> 00:01:50.830 align:start position:0% but you're not checking the transactions and<00:01:48.759> that<00:01:49.759> means<00:01:50.210> that<00:01:50.330> you're<00:01:50.420> checking<00:01:50.659> that 00:01:50.830 --> 00:01:50.840 align:start position:0% and that means that you're checking that 00:01:50.840 --> 00:01:52.420 align:start position:0% and that means that you're checking that mining<00:01:51.380> or<00:01:51.590> staking<00:01:52.009> has<00:01:52.130> been<00:01:52.310> done 00:01:52.420 --> 00:01:52.430 align:start position:0% mining or staking has been done 00:01:52.430 --> 00:01:54.429 align:start position:0% mining or staking has been done correctly<00:01:52.960> but<00:01:53.960> you're<00:01:54.080> not<00:01:54.229> actually 00:01:54.429 --> 00:01:54.439 align:start position:0% correctly but you're not actually 00:01:54.439 --> 00:01:56.620 align:start position:0% correctly but you're not actually executing<00:01:55.159> those<00:01:55.220> transactions<00:01:55.850> to<00:01:56.030> see<00:01:56.299> if 00:01:56.620 --> 00:01:56.630 align:start position:0% executing those transactions to see if 00:01:56.630 --> 00:02:00.219 align:start position:0% executing those transactions to see if the<00:01:56.900> output<00:01:57.439> state<00:01:57.680> is<00:01:58.509> correct<00:01:59.509> from<00:02:00.049> the 00:02:00.219 --> 00:02:00.229 align:start position:0% the output state is correct from the 00:02:00.229 --> 00:02:01.719 align:start position:0% the output state is correct from the previous<00:02:00.619> state<00:02:00.799> and<00:02:01.040> the<00:02:01.130> new<00:02:01.250> transactions 00:02:01.719 --> 00:02:01.729 align:start position:0% previous state and the new transactions 00:02:01.729 --> 00:02:03.219 align:start position:0% previous state and the new transactions that<00:02:01.850> have<00:02:01.939> been<00:02:02.060> added<00:02:02.210> and<00:02:02.570> the<00:02:02.780> last<00:02:02.960> kind 00:02:03.219 --> 00:02:03.229 align:start position:0% that have been added and the last kind 00:02:03.229 --> 00:02:05.140 align:start position:0% that have been added and the last kind of<00:02:03.320> client<00:02:03.619> that<00:02:03.710> we<00:02:03.829> have<00:02:04.040> which<00:02:04.939> I'm<00:02:05.060> not 00:02:05.140 --> 00:02:05.150 align:start position:0% of client that we have which I'm not 00:02:05.150 --> 00:02:07.030 align:start position:0% of client that we have which I'm not going<00:02:05.270> to<00:02:05.329> talk<00:02:05.509> about<00:02:05.630> too<00:02:05.930> much<00:02:06.110> today<00:02:06.380> but 00:02:07.030 --> 00:02:07.040 align:start position:0% going to talk about too much today but 00:02:07.040 --> 00:02:09.219 align:start position:0% going to talk about too much today but is<00:02:07.189> relevant<00:02:07.790> to<00:02:08.090> the<00:02:08.479> protocol<00:02:08.989> that<00:02:09.019> I'm 00:02:09.219 --> 00:02:09.229 align:start position:0% is relevant to the protocol that I'm 00:02:09.229 --> 00:02:12.309 align:start position:0% is relevant to the protocol that I'm going<00:02:09.439> to<00:02:09.560> discuss<00:02:09.890> now<00:02:10.069> is<00:02:10.310> a<00:02:11.120> thin<00:02:11.690> client<00:02:11.989> so 00:02:12.309 --> 00:02:12.319 align:start position:0% going to discuss now is a thin client so 00:02:12.319 --> 00:02:14.559 align:start position:0% going to discuss now is a thin client so a<00:02:12.349> thin<00:02:12.650> client<00:02:12.950> isn't<00:02:13.700> checking<00:02:14.360> the 00:02:14.559 --> 00:02:14.569 align:start position:0% a thin client isn't checking the 00:02:14.569 --> 00:02:17.199 align:start position:0% a thin client isn't checking the census<00:02:14.989> process<00:02:15.379> itself<00:02:15.709> but<00:02:15.950> rather<00:02:16.209> has 00:02:17.199 --> 00:02:17.209 align:start position:0% census process itself but rather has 00:02:17.209 --> 00:02:18.879 align:start position:0% census process itself but rather has somebody<00:02:17.599> else<00:02:17.840> do<00:02:18.109> that<00:02:18.140> checking<00:02:18.590> for<00:02:18.739> them 00:02:18.879 --> 00:02:18.889 align:start position:0% somebody else do that checking for them 00:02:18.889 --> 00:02:21.550 align:start position:0% somebody else do that checking for them and<00:02:19.159> checks<00:02:19.459> it<00:02:19.639> and<00:02:20.420> and<00:02:20.719> trusts<00:02:21.109> that<00:02:21.290> and 00:02:21.550 --> 00:02:21.560 align:start position:0% and checks it and and trusts that and 00:02:21.560 --> 00:02:23.920 align:start position:0% and checks it and and trusts that and then<00:02:21.739> can<00:02:22.010> fetch<00:02:22.219> data<00:02:22.489> about<00:02:22.730> the<00:02:22.879> chain<00:02:23.090> in 00:02:23.920 --> 00:02:23.930 align:start position:0% then can fetch data about the chain in 00:02:23.930 --> 00:02:25.209 align:start position:0% then can fetch data about the chain in the<00:02:24.079> same<00:02:24.260> way<00:02:24.409> that<00:02:24.530> a<00:02:24.590> light<00:02:24.769> climber<00:02:25.040> would 00:02:25.209 --> 00:02:25.219 align:start position:0% the same way that a light climber would 00:02:25.219 --> 00:02:29.410 align:start position:0% the same way that a light climber would so<00:02:25.819> a<00:02:27.099> light<00:02:28.099> client<00:02:28.459> has<00:02:28.609> these<00:02:28.790> security 00:02:29.410 --> 00:02:29.420 align:start position:0% so a light client has these security 00:02:29.420 --> 00:02:31.179 align:start position:0% so a light client has these security guarantees<00:02:29.870> so<00:02:30.200> it's<00:02:30.379> checking<00:02:30.920> the<00:02:31.010> validity 00:02:31.179 --> 00:02:31.189 align:start position:0% guarantees so it's checking the validity 00:02:31.189 --> 00:02:33.069 align:start position:0% guarantees so it's checking the validity of<00:02:31.370> headers<00:02:31.700> it<00:02:32.239> doesn't<00:02:32.629> check<00:02:32.780> the<00:02:32.959> validity 00:02:33.069 --> 00:02:33.079 align:start position:0% of headers it doesn't check the validity 00:02:33.079 --> 00:02:35.309 align:start position:0% of headers it doesn't check the validity of<00:02:33.319> state<00:02:33.650> transitions<00:02:34.219> necessarily<00:02:35.090> and 00:02:35.309 --> 00:02:35.319 align:start position:0% of state transitions necessarily and 00:02:35.319 --> 00:02:37.959 align:start position:0% of state transitions necessarily and this<00:02:36.319> might<00:02:36.530> leave<00:02:36.739> us<00:02:36.920> open<00:02:37.310> to<00:02:37.459> some<00:02:37.639> kind<00:02:37.879> of 00:02:37.959 --> 00:02:37.969 align:start position:0% this might leave us open to some kind of 00:02:37.969 --> 00:02:40.899 align:start position:0% this might leave us open to some kind of attacks<00:02:38.239> so<00:02:38.620> perhaps<00:02:39.620> a<00:02:39.799> minor<00:02:40.129> would 00:02:40.899 --> 00:02:40.909 align:start position:0% attacks so perhaps a minor would 00:02:40.909 --> 00:02:42.879 align:start position:0% attacks so perhaps a minor would introduce<00:02:41.359> an<00:02:41.510> invalid<00:02:42.109> state<00:02:42.319> transition 00:02:42.879 --> 00:02:42.889 align:start position:0% introduce an invalid state transition 00:02:42.889 --> 00:02:46.899 align:start position:0% introduce an invalid state transition and<00:02:44.409> the<00:02:45.409> thing<00:02:45.650> is<00:02:45.889> these<00:02:46.219> kinds<00:02:46.549> of<00:02:46.579> attacks 00:02:46.899 --> 00:02:46.909 align:start position:0% and the thing is these kinds of attacks 00:02:46.909 --> 00:02:48.789 align:start position:0% and the thing is these kinds of attacks are<00:02:47.120> not<00:02:47.239> particularly<00:02:47.840> likely<00:02:48.409> because<00:02:48.680> they 00:02:48.789 --> 00:02:48.799 align:start position:0% are not particularly likely because they 00:02:48.799 --> 00:02:50.979 align:start position:0% are not particularly likely because they have<00:02:48.919> to<00:02:49.069> be<00:02:49.189> first<00:02:49.730> of<00:02:49.849> all<00:02:49.939> targeted<00:02:50.450> so<00:02:50.900> you 00:02:50.979 --> 00:02:50.989 align:start position:0% have to be first of all targeted so you 00:02:50.989 --> 00:02:52.479 align:start position:0% have to be first of all targeted so you have<00:02:51.139> to<00:02:51.260> target<00:02:51.469> a<00:02:51.680> specific<00:02:52.099> person<00:02:52.459> and 00:02:52.479 --> 00:02:52.489 align:start position:0% have to target a specific person and 00:02:52.489 --> 00:02:54.550 align:start position:0% have to target a specific person and that's<00:02:52.669> because<00:02:53.030> of<00:02:53.209> the<00:02:53.689> assumption<00:02:54.290> that<00:02:54.319> we 00:02:54.550 --> 00:02:54.560 align:start position:0% that's because of the assumption that we 00:02:54.560 --> 00:02:58.479 align:start position:0% that's because of the assumption that we have<00:02:54.799> that<00:02:55.959> minors<00:02:56.959> will<00:02:57.260> only<00:02:57.469> build<00:02:57.859> on<00:02:58.280> top 00:02:58.479 --> 00:02:58.489 align:start position:0% have that minors will only build on top 00:02:58.489 --> 00:03:00.099 align:start position:0% have that minors will only build on top of<00:02:58.549> valid<00:02:59.180> blocks<00:02:59.389> or<00:02:59.569> at<00:02:59.659> least<00:02:59.780> a<00:02:59.930> majority 00:03:00.099 --> 00:03:00.109 align:start position:0% of valid blocks or at least a majority 00:03:00.109 --> 00:03:01.780 align:start position:0% of valid blocks or at least a majority of<00:03:00.590> minors<00:03:00.889> when<00:03:01.010> we<00:03:01.099> talk<00:03:01.250> about<00:03:01.370> the<00:03:01.609> group 00:03:01.780 --> 00:03:01.790 align:start position:0% of minors when we talk about the group 00:03:01.790 --> 00:03:03.250 align:start position:0% of minors when we talk about the group of<00:03:01.939> minors<00:03:02.269> as<00:03:02.419> a<00:03:02.449> whole<00:03:02.689> we<00:03:02.870> say<00:03:03.049> they're 00:03:03.250 --> 00:03:03.260 align:start position:0% of minors as a whole we say they're 00:03:03.260 --> 00:03:06.250 align:start position:0% of minors as a whole we say they're acting<00:03:03.949> honestly<00:03:04.489> so<00:03:04.969> they<00:03:05.959> couldn't 00:03:06.250 --> 00:03:06.260 align:start position:0% acting honestly so they couldn't 00:03:06.260 --> 00:03:07.899 align:start position:0% acting honestly so they couldn't necessarily<00:03:06.469> perform<00:03:07.250> this<00:03:07.370> kind<00:03:07.549> of<00:03:07.639> attack 00:03:07.899 --> 00:03:07.909 align:start position:0% necessarily perform this kind of attack 00:03:07.909 --> 00:03:10.390 align:start position:0% necessarily perform this kind of attack on<00:03:08.120> the<00:03:08.359> whole<00:03:08.629> network<00:03:09.319> but<00:03:09.769> on<00:03:09.859> a<00:03:09.889> specific 00:03:10.390 --> 00:03:10.400 align:start position:0% on the whole network but on a specific 00:03:10.400 --> 00:03:12.429 align:start position:0% on the whole network but on a specific targeted<00:03:10.939> person<00:03:11.150> they<00:03:11.480> could<00:03:11.719> if<00:03:12.109> they<00:03:12.290> took 00:03:12.429 --> 00:03:12.439 align:start position:0% targeted person they could if they took 00:03:12.439 --> 00:03:13.839 align:start position:0% targeted person they could if they took up<00:03:12.620> all<00:03:12.739> their<00:03:12.889> peer<00:03:13.099> slots<00:03:13.370> and<00:03:13.519> started 00:03:13.839 --> 00:03:13.849 align:start position:0% up all their peer slots and started 00:03:13.849 --> 00:03:16.629 align:start position:0% up all their peer slots and started sending<00:03:14.030> them<00:03:14.269> fake<00:03:14.480> headers<00:03:15.370> but<00:03:16.370> we<00:03:16.459> also 00:03:16.629 --> 00:03:16.639 align:start position:0% sending them fake headers but we also 00:03:16.639 --> 00:03:20.710 align:start position:0% sending them fake headers but we also have<00:03:17.030> some<00:03:17.540> kinds<00:03:17.959> of<00:03:19.000> routing<00:03:20.000> mechanisms 00:03:20.710 --> 00:03:20.720 align:start position:0% have some kinds of routing mechanisms 00:03:20.720 --> 00:03:22.839 align:start position:0% have some kinds of routing mechanisms for<00:03:21.379> example<00:03:21.680> something<00:03:21.859> called<00:03:22.159> K<00:03:22.430> buckets 00:03:22.839 --> 00:03:22.849 align:start position:0% for example something called K buckets 00:03:22.849 --> 00:03:24.550 align:start position:0% for example something called K buckets which<00:03:23.000> are<00:03:23.150> Cybil<00:03:23.540> attack<00:03:23.840> resistant<00:03:24.409> which 00:03:24.550 --> 00:03:24.560 align:start position:0% which are Cybil attack resistant which 00:03:24.560 --> 00:03:26.379 align:start position:0% which are Cybil attack resistant which means<00:03:24.769> that<00:03:24.889> it's<00:03:25.009> actually<00:03:25.400> if<00:03:25.639> you<00:03:25.939> have<00:03:25.970> an 00:03:26.379 --> 00:03:26.389 align:start position:0% means that it's actually if you have an 00:03:26.389 --> 00:03:27.819 align:start position:0% means that it's actually if you have an established<00:03:26.629> peer<00:03:27.139> slot<00:03:27.409> it's<00:03:27.620> very 00:03:27.819 --> 00:03:27.829 align:start position:0% established peer slot it's very 00:03:27.829 --> 00:03:30.490 align:start position:0% established peer slot it's very difficult<00:03:28.280> for<00:03:28.699> an<00:03:29.540> attacker<00:03:29.840> to<00:03:29.959> fill<00:03:30.349> up 00:03:30.490 --> 00:03:30.500 align:start position:0% difficult for an attacker to fill up 00:03:30.500 --> 00:03:32.649 align:start position:0% difficult for an attacker to fill up those<00:03:30.739> peer<00:03:31.009> slots<00:03:31.280> and<00:03:31.459> push<00:03:31.699> your<00:03:31.879> valid 00:03:32.649 --> 00:03:32.659 align:start position:0% those peer slots and push your valid 00:03:32.659 --> 00:03:36.009 align:start position:0% those peer slots and push your valid peers<00:03:32.930> out<00:03:33.129> so<00:03:34.129> I<00:03:34.459> would<00:03:34.849> say<00:03:35.150> light<00:03:35.540> clients 00:03:36.009 --> 00:03:36.019 align:start position:0% peers out so I would say light clients 00:03:36.019 --> 00:03:39.039 align:start position:0% peers out so I would say light clients are<00:03:36.169> very<00:03:36.439> useful<00:03:36.919> for<00:03:36.949> low<00:03:37.400> value<00:03:38.090> or<00:03:38.449> medium 00:03:39.039 --> 00:03:39.049 align:start position:0% are very useful for low value or medium 00:03:39.049 --> 00:03:42.030 align:start position:0% are very useful for low value or medium value<00:03:39.319> use<00:03:40.189> cases<00:03:40.459> but<00:03:41.120> of<00:03:41.239> course<00:03:41.509> if<00:03:41.750> you're 00:03:42.030 --> 00:03:42.040 align:start position:0% value use cases but of course if you're 00:03:42.040 --> 00:03:43.960 align:start position:0% value use cases but of course if you're transacting<00:03:43.040> millions<00:03:43.459> of<00:03:43.609> dollars<00:03:43.939> you 00:03:43.960 --> 00:03:43.970 align:start position:0% transacting millions of dollars you 00:03:43.970 --> 00:03:45.819 align:start position:0% transacting millions of dollars you would<00:03:44.239> probably<00:03:44.689> want<00:03:44.900> to<00:03:44.959> have<00:03:45.169> the<00:03:45.409> security 00:03:45.819 --> 00:03:45.829 align:start position:0% would probably want to have the security 00:03:45.829 --> 00:03:49.270 align:start position:0% would probably want to have the security of<00:03:46.159> a<00:03:46.579> full<00:03:46.790> node<00:03:46.970> because<00:03:47.299> that<00:03:47.479> would<00:03:48.280> that 00:03:49.270 --> 00:03:49.280 align:start position:0% of a full node because that would that 00:03:49.280 --> 00:03:51.039 align:start position:0% of a full node because that would that kind<00:03:49.400> of<00:03:49.579> activity<00:03:49.849> would<00:03:50.180> leave<00:03:50.659> you<00:03:50.840> maybe 00:03:51.039 --> 00:03:51.049 align:start position:0% kind of activity would leave you maybe 00:03:51.049 --> 00:03:54.159 align:start position:0% kind of activity would leave you maybe open<00:03:51.409> to<00:03:51.530> attack<00:03:52.269> and<00:03:53.269> those<00:03:53.810> kinds<00:03:54.079> of 00:03:54.159 --> 00:03:54.169 align:start position:0% open to attack and those kinds of 00:03:54.169 --> 00:03:56.170 align:start position:0% open to attack and those kinds of attacks<00:03:54.409> just<00:03:54.680> to<00:03:54.859> clarify<00:03:55.099> are<00:03:55.669> really<00:03:55.970> just 00:03:56.170 --> 00:03:56.180 align:start position:0% attacks just to clarify are really just 00:03:56.180 --> 00:04:00.520 align:start position:0% attacks just to clarify are really just about<00:03:58.569> tricking<00:03:59.569> a<00:03:59.659> user<00:03:59.900> into<00:04:00.199> taking 00:04:00.520 --> 00:04:00.530 align:start position:0% about tricking a user into taking 00:04:00.530 --> 00:04:02.110 align:start position:0% about tricking a user into taking different<00:04:00.709> kinds<00:04:01.159> of<00:04:01.250> actions<00:04:01.669> based<00:04:01.879> on 00:04:02.110 --> 00:04:02.120 align:start position:0% different kinds of actions based on 00:04:02.120 --> 00:04:05.170 align:start position:0% different kinds of actions based on showing<00:04:02.419> them<00:04:02.689> a<00:04:02.900> wrong<00:04:03.290> state<00:04:03.709> so<00:04:04.370> they<00:04:04.939> can't 00:04:05.170 --> 00:04:05.180 align:start position:0% showing them a wrong state so they can't 00:04:05.180 --> 00:04:07.209 align:start position:0% showing them a wrong state so they can't actually<00:04:05.419> steal<00:04:06.259> money<00:04:06.500> from<00:04:06.829> them<00:04:06.979> without 00:04:07.209 --> 00:04:07.219 align:start position:0% actually steal money from them without 00:04:07.219 --> 00:04:10.449 align:start position:0% actually steal money from them without the<00:04:07.310> user<00:04:07.489> taking<00:04:07.849> action<00:04:08.209> themselves<00:04:09.219> so<00:04:10.219> we 00:04:10.449 --> 00:04:10.459 align:start position:0% the user taking action themselves so we 00:04:10.459 --> 00:04:13.270 align:start position:0% the user taking action themselves so we have<00:04:10.579> some<00:04:10.759> network<00:04:11.030> protocol<00:04:11.539> goals<00:04:12.189> so<00:04:13.189> the 00:04:13.270 --> 00:04:13.280 align:start position:0% have some network protocol goals so the 00:04:13.280 --> 00:04:15.610 align:start position:0% have some network protocol goals so the first<00:04:13.519> would<00:04:13.849> be<00:04:13.879> to<00:04:14.269> minimize<00:04:14.780> round<00:04:15.319> trips 00:04:15.610 --> 00:04:15.620 align:start position:0% first would be to minimize round trips 00:04:15.620 --> 00:04:17.110 align:start position:0% first would be to minimize round trips in<00:04:15.769> bandwidth<00:04:16.130> because<00:04:16.400> in<00:04:16.519> a<00:04:16.579> light<00:04:16.729> client 00:04:17.110 --> 00:04:17.120 align:start position:0% in bandwidth because in a light client 00:04:17.120 --> 00:04:20.140 align:start position:0% in bandwidth because in a light client you<00:04:17.509> are<00:04:17.799> requesting<00:04:18.799> data<00:04:19.039> from<00:04:19.219> your<00:04:19.820> peers 00:04:20.140 --> 00:04:20.150 align:start position:0% you are requesting data from your peers 00:04:20.150 --> 00:04:21.759 align:start position:0% you are requesting data from your peers and<00:04:20.299> if<00:04:20.780> you<00:04:20.870> want<00:04:21.049> to<00:04:21.109> run<00:04:21.199> this<00:04:21.289> on<00:04:21.440> a<00:04:21.500> mobile 00:04:21.759 --> 00:04:21.769 align:start position:0% and if you want to run this on a mobile 00:04:21.769 --> 00:04:23.850 align:start position:0% and if you want to run this on a mobile device<00:04:22.310> or<00:04:22.610> on<00:04:22.639> low<00:04:22.880> bandwidth 00:04:23.850 --> 00:04:23.860 align:start position:0% device or on low bandwidth 00:04:23.860 --> 00:04:25.530 align:start position:0% device or on low bandwidth you<00:04:24.040> need<00:04:24.190> to<00:04:24.310> minimize<00:04:24.790> those<00:04:25.030> round<00:04:25.270> trips 00:04:25.530 --> 00:04:25.540 align:start position:0% you need to minimize those round trips 00:04:25.540 --> 00:04:27.990 align:start position:0% you need to minimize those round trips you<00:04:25.660> want<00:04:25.810> to<00:04:25.870> reduce<00:04:26.169> that<00:04:26.410> latency<00:04:26.830> we<00:04:27.790> also 00:04:27.990 --> 00:04:28.000 align:start position:0% you want to reduce that latency we also 00:04:28.000 --> 00:04:30.060 align:start position:0% you want to reduce that latency we also want<00:04:28.360> provable<00:04:29.080> data<00:04:29.320> which<00:04:29.590> means<00:04:29.800> that<00:04:29.979> you 00:04:30.060 --> 00:04:30.070 align:start position:0% want provable data which means that you 00:04:30.070 --> 00:04:32.670 align:start position:0% want provable data which means that you don't<00:04:30.340> rely<00:04:31.030> on<00:04:31.090> any<00:04:31.449> more<00:04:31.870> trust<00:04:32.139> assumption 00:04:32.670 --> 00:04:32.680 align:start position:0% don't rely on any more trust assumption 00:04:32.680 --> 00:04:35.340 align:start position:0% don't rely on any more trust assumption then<00:04:33.310> the<00:04:33.520> fact<00:04:33.729> that<00:04:33.820> miners<00:04:34.360> are<00:04:34.570> updating 00:04:35.340 --> 00:04:35.350 align:start position:0% then the fact that miners are updating 00:04:35.350 --> 00:04:37.830 align:start position:0% then the fact that miners are updating state<00:04:35.560> transitions<00:04:36.070> correctly<00:04:36.639> and<00:04:36.880> of 00:04:37.830 --> 00:04:37.840 align:start position:0% state transitions correctly and of 00:04:37.840 --> 00:04:40.350 align:start position:0% state transitions correctly and of course<00:04:38.139> we<00:04:38.740> have<00:04:38.919> full<00:04:39.310> clients<00:04:39.970> who<00:04:40.330> are 00:04:40.350 --> 00:04:40.360 align:start position:0% course we have full clients who are 00:04:40.360 --> 00:04:42.120 align:start position:0% course we have full clients who are serving<00:04:41.050> the<00:04:41.169> light<00:04:41.350> nodes<00:04:41.620> over<00:04:41.830> the<00:04:41.979> network 00:04:42.120 --> 00:04:42.130 align:start position:0% serving the light nodes over the network 00:04:42.130 --> 00:04:44.670 align:start position:0% serving the light nodes over the network and<00:04:42.370> we<00:04:42.820> don't<00:04:43.030> want<00:04:43.210> these<00:04:43.360> guys<00:04:43.600> to<00:04:43.660> get<00:04:44.169> dust 00:04:44.670 --> 00:04:44.680 align:start position:0% and we don't want these guys to get dust 00:04:44.680 --> 00:04:46.230 align:start position:0% and we don't want these guys to get dust we<00:04:44.949> don't<00:04:45.100> want<00:04:45.220> them<00:04:45.340> to<00:04:45.460> get<00:04:45.550> overloaded<00:04:45.970> we 00:04:46.230 --> 00:04:46.240 align:start position:0% we don't want them to get overloaded we 00:04:46.240 --> 00:04:48.450 align:start position:0% we don't want them to get overloaded we need<00:04:46.360> a<00:04:46.419> sensible<00:04:47.050> way<00:04:47.229> to<00:04:47.500> meter<00:04:48.190> the 00:04:48.450 --> 00:04:48.460 align:start position:0% need a sensible way to meter the 00:04:48.460 --> 00:04:50.550 align:start position:0% need a sensible way to meter the requests<00:04:48.880> that<00:04:48.970> are<00:04:49.030> being<00:04:49.240> made<00:04:49.449> to<00:04:49.660> them<00:04:49.780> so 00:04:50.550 --> 00:04:50.560 align:start position:0% requests that are being made to them so 00:04:50.560 --> 00:04:51.960 align:start position:0% requests that are being made to them so in<00:04:50.949> the<00:04:51.100> next<00:04:51.250> section<00:04:51.460> I'm<00:04:51.699> going<00:04:51.910> to 00:04:51.960 --> 00:04:51.970 align:start position:0% in the next section I'm going to 00:04:51.970 --> 00:04:53.670 align:start position:0% in the next section I'm going to basically<00:04:52.120> discuss<00:04:52.750> a<00:04:52.960> few<00:04:53.259> of<00:04:53.380> the<00:04:53.500> tools 00:04:53.670 --> 00:04:53.680 align:start position:0% basically discuss a few of the tools 00:04:53.680 --> 00:04:57.629 align:start position:0% basically discuss a few of the tools that<00:04:53.889> we<00:04:54.100> use<00:04:54.300> to<00:04:55.300> achieve<00:04:55.449> this<00:04:56.280> so<00:04:57.280> the<00:04:57.490> first 00:04:57.629 --> 00:04:57.639 align:start position:0% that we use to achieve this so the first 00:04:57.639 --> 00:05:01.230 align:start position:0% that we use to achieve this so the first is<00:04:57.820> back<00:04:58.000> referencing<00:04:59.610> when<00:05:00.610> you<00:05:00.760> make<00:05:00.970> a 00:05:01.230 --> 00:05:01.240 align:start position:0% is back referencing when you make a 00:05:01.240 --> 00:05:06.290 align:start position:0% is back referencing when you make a network<00:05:02.080> request<00:05:02.880> what<00:05:03.880> you<00:05:04.000> can<00:05:04.180> do<00:05:04.360> is<00:05:05.100> put 00:05:06.290 --> 00:05:06.300 align:start position:0% network request what you can do is put 00:05:06.300 --> 00:05:09.620 align:start position:0% network request what you can do is put multiple<00:05:07.300> requests<00:05:07.810> in<00:05:07.960> the<00:05:08.020> same<00:05:08.320> packet<00:05:08.770> but 00:05:09.620 --> 00:05:09.630 align:start position:0% multiple requests in the same packet but 00:05:09.630 --> 00:05:12.360 align:start position:0% multiple requests in the same packet but further<00:05:10.630> requests<00:05:11.289> in<00:05:11.380> the<00:05:11.410> packet<00:05:11.830> can<00:05:12.039> rely 00:05:12.360 --> 00:05:12.370 align:start position:0% further requests in the packet can rely 00:05:12.370 --> 00:05:14.580 align:start position:0% further requests in the packet can rely on<00:05:12.400> unresolved<00:05:13.240> outputs<00:05:13.930> of<00:05:14.139> the<00:05:14.320> prior 00:05:14.580 --> 00:05:14.590 align:start position:0% on unresolved outputs of the prior 00:05:14.590 --> 00:05:16.650 align:start position:0% on unresolved outputs of the prior requests<00:05:15.039> so<00:05:15.550> for<00:05:15.699> example<00:05:16.030> you<00:05:16.120> can<00:05:16.240> say<00:05:16.419> I 00:05:16.650 --> 00:05:16.660 align:start position:0% requests so for example you can say I 00:05:16.660 --> 00:05:18.930 align:start position:0% requests so for example you can say I have<00:05:17.320> a<00:05:17.349> block<00:05:17.620> number<00:05:18.039> and<00:05:18.190> I<00:05:18.340> want<00:05:18.610> to<00:05:18.729> get 00:05:18.930 --> 00:05:18.940 align:start position:0% have a block number and I want to get 00:05:18.940 --> 00:05:21.180 align:start position:0% have a block number and I want to get the<00:05:19.360> header<00:05:19.599> for<00:05:19.870> that<00:05:20.020> block<00:05:20.260> but<00:05:20.530> once<00:05:21.039> I 00:05:21.180 --> 00:05:21.190 align:start position:0% the header for that block but once I 00:05:21.190 --> 00:05:23.129 align:start position:0% the header for that block but once I have<00:05:21.400> the<00:05:21.610> header<00:05:21.789> for<00:05:21.970> that<00:05:22.120> block<00:05:22.389> I<00:05:22.630> want 00:05:23.129 --> 00:05:23.139 align:start position:0% have the header for that block I want 00:05:23.139 --> 00:05:25.230 align:start position:0% have the header for that block I want the<00:05:23.320> state<00:05:23.919> of<00:05:24.099> this<00:05:24.250> account<00:05:24.550> at<00:05:24.849> that<00:05:25.030> block 00:05:25.230 --> 00:05:25.240 align:start position:0% the state of this account at that block 00:05:25.240 --> 00:05:27.270 align:start position:0% the state of this account at that block and<00:05:25.570> once<00:05:25.870> I<00:05:25.990> have<00:05:26.199> that<00:05:26.440> account<00:05:26.710> I'd<00:05:26.949> like<00:05:27.130> to 00:05:27.270 --> 00:05:27.280 align:start position:0% and once I have that account I'd like to 00:05:27.280 --> 00:05:29.790 align:start position:0% and once I have that account I'd like to inspect<00:05:27.400> some<00:05:27.820> of<00:05:27.940> its<00:05:28.060> storage<00:05:28.360> and<00:05:28.650> this<00:05:29.650> is 00:05:29.790 --> 00:05:29.800 align:start position:0% inspect some of its storage and this is 00:05:29.800 --> 00:05:31.140 align:start position:0% inspect some of its storage and this is actually<00:05:30.070> very<00:05:30.099> powerful<00:05:30.610> tool<00:05:30.760> because<00:05:31.030> we 00:05:31.140 --> 00:05:31.150 align:start position:0% actually very powerful tool because we 00:05:31.150 --> 00:05:34.050 align:start position:0% actually very powerful tool because we can<00:05:31.300> express<00:05:31.840> very<00:05:32.169> fluid<00:05:32.800> kinds<00:05:33.490> of<00:05:33.580> requests 00:05:34.050 --> 00:05:34.060 align:start position:0% can express very fluid kinds of requests 00:05:34.060 --> 00:05:36.480 align:start position:0% can express very fluid kinds of requests in<00:05:34.210> a<00:05:34.599> single<00:05:35.139> round-trip<00:05:35.979> to<00:05:36.099> the<00:05:36.130> network 00:05:36.480 --> 00:05:36.490 align:start position:0% in a single round-trip to the network 00:05:36.490 --> 00:05:38.760 align:start position:0% in a single round-trip to the network which<00:05:36.639> means<00:05:36.880> that<00:05:37.449> the<00:05:37.990> response<00:05:38.410> time<00:05:38.650> of 00:05:38.760 --> 00:05:38.770 align:start position:0% which means that the response time of 00:05:38.770 --> 00:05:39.810 align:start position:0% which means that the response time of the<00:05:38.860> light<00:05:39.010> client<00:05:39.280> is<00:05:39.370> going<00:05:39.520> to<00:05:39.610> be<00:05:39.669> much 00:05:39.810 --> 00:05:39.820 align:start position:0% the light client is going to be much 00:05:39.820 --> 00:05:45.050 align:start position:0% the light client is going to be much lower<00:05:41.760> another<00:05:42.760> tool<00:05:43.360> that<00:05:43.389> we<00:05:43.599> have<00:05:43.690> is 00:05:45.050 --> 00:05:45.060 align:start position:0% lower another tool that we have is 00:05:45.060 --> 00:05:47.430 align:start position:0% lower another tool that we have is mostly<00:05:46.060> useful<00:05:46.300> for<00:05:46.840> doing<00:05:46.930> things<00:05:47.289> like 00:05:47.430 --> 00:05:47.440 align:start position:0% mostly useful for doing things like 00:05:47.440 --> 00:05:50.550 align:start position:0% mostly useful for doing things like checking<00:05:48.370> the<00:05:48.940> result<00:05:49.810> of<00:05:50.080> a<00:05:50.139> transaction 00:05:50.550 --> 00:05:50.560 align:start position:0% checking the result of a transaction 00:05:50.560 --> 00:05:53.700 align:start position:0% checking the result of a transaction execution<00:05:50.979> on<00:05:51.639> the<00:05:51.970> light<00:05:52.120> client<00:05:52.680> which<00:05:53.680> is 00:05:53.700 --> 00:05:53.710 align:start position:0% execution on the light client which is 00:05:53.710 --> 00:05:55.740 align:start position:0% execution on the light client which is that<00:05:54.010> what<00:05:54.639> you<00:05:54.760> could<00:05:54.970> do<00:05:55.120> is<00:05:55.300> start<00:05:55.570> to 00:05:55.740 --> 00:05:55.750 align:start position:0% that what you could do is start to 00:05:55.750 --> 00:05:57.899 align:start position:0% that what you could do is start to execute<00:05:56.110> the<00:05:56.800> code<00:05:56.979> so<00:05:57.250> you<00:05:57.310> fetch<00:05:57.639> the<00:05:57.699> code 00:05:57.899 --> 00:05:57.909 align:start position:0% execute the code so you fetch the code 00:05:57.909 --> 00:05:59.700 align:start position:0% execute the code so you fetch the code from<00:05:58.120> the<00:05:58.240> network<00:05:58.539> and<00:05:58.750> then<00:05:59.260> you<00:05:59.470> see<00:05:59.680> that 00:05:59.700 --> 00:05:59.710 align:start position:0% from the network and then you see that 00:05:59.710 --> 00:06:01.529 align:start position:0% from the network and then you see that the<00:05:59.979> code<00:06:00.190> execution<00:06:00.669> needs<00:06:00.970> to<00:06:01.150> get<00:06:01.300> some 00:06:01.529 --> 00:06:01.539 align:start position:0% the code execution needs to get some 00:06:01.539 --> 00:06:03.480 align:start position:0% the code execution needs to get some account<00:06:01.840> so<00:06:02.199> we<00:06:02.320> go<00:06:02.440> one<00:06:02.710> round-trip<00:06:02.979> to<00:06:03.340> get 00:06:03.480 --> 00:06:03.490 align:start position:0% account so we go one round-trip to get 00:06:03.490 --> 00:06:05.520 align:start position:0% account so we go one round-trip to get that<00:06:03.639> account<00:06:03.880> and<00:06:04.150> then<00:06:04.599> back<00:06:04.780> executable 00:06:05.520 --> 00:06:05.530 align:start position:0% that account and then back executable 00:06:05.530 --> 00:06:07.379 align:start position:0% that account and then back executable further<00:06:05.800> and<00:06:06.099> we<00:06:06.460> get<00:06:06.610> some<00:06:06.820> more<00:06:06.940> data<00:06:07.180> from 00:06:07.379 --> 00:06:07.389 align:start position:0% further and we get some more data from 00:06:07.389 --> 00:06:10.080 align:start position:0% further and we get some more data from the<00:06:07.479> state<00:06:07.750> and<00:06:07.990> you<00:06:08.500> see<00:06:08.710> that<00:06:08.919> over<00:06:09.190> time 00:06:10.080 --> 00:06:10.090 align:start position:0% the state and you see that over time 00:06:10.090 --> 00:06:11.909 align:start position:0% the state and you see that over time we're<00:06:10.330> jumping<00:06:10.750> back<00:06:10.960> and<00:06:10.990> forth<00:06:11.260> into<00:06:11.830> the 00:06:11.909 --> 00:06:11.919 align:start position:0% we're jumping back and forth into the 00:06:11.919 --> 00:06:13.830 align:start position:0% we're jumping back and forth into the network<00:06:12.220> just<00:06:12.430> to<00:06:12.610> execute<00:06:13.090> that<00:06:13.120> transaction 00:06:13.830 --> 00:06:13.840 align:start position:0% network just to execute that transaction 00:06:13.840 --> 00:06:15.779 align:start position:0% network just to execute that transaction and<00:06:13.930> see<00:06:14.110> what<00:06:14.260> the<00:06:14.409> result<00:06:15.010> would<00:06:15.099> be<00:06:15.250> but 00:06:15.779 --> 00:06:15.789 align:start position:0% and see what the result would be but 00:06:15.789 --> 00:06:18.810 align:start position:0% and see what the result would be but rather<00:06:16.110> what<00:06:17.110> we<00:06:17.139> can<00:06:17.409> do<00:06:17.590> is<00:06:17.889> get<00:06:18.159> a<00:06:18.340> full 00:06:18.810 --> 00:06:18.820 align:start position:0% rather what we can do is get a full 00:06:18.820 --> 00:06:22.740 align:start position:0% rather what we can do is get a full subset<00:06:19.570> the<00:06:20.560> subset<00:06:21.070> of<00:06:21.220> the<00:06:21.639> state<00:06:21.940> tree<00:06:22.360> so 00:06:22.740 --> 00:06:22.750 align:start position:0% subset the subset of the state tree so 00:06:22.750 --> 00:06:25.560 align:start position:0% subset the subset of the state tree so the<00:06:22.840> state<00:06:23.050> is<00:06:23.199> stored<00:06:23.409> in<00:06:23.500> a<00:06:23.560> tree<00:06:24.389> which<00:06:25.389> is 00:06:25.560 --> 00:06:25.570 align:start position:0% the state is stored in a tree which is 00:06:25.570 --> 00:06:27.689 align:start position:0% the state is stored in a tree which is necessary<00:06:26.199> to<00:06:26.380> execute<00:06:26.680> that<00:06:26.889> transaction 00:06:27.689 --> 00:06:27.699 align:start position:0% necessary to execute that transaction 00:06:27.699 --> 00:06:31.890 align:start position:0% necessary to execute that transaction fully<00:06:27.960> so<00:06:28.960> if<00:06:29.289> you<00:06:29.590> are<00:06:30.010> a<00:06:30.280> client<00:06:31.270> writer<00:06:31.659> on<00:06:31.870> a 00:06:31.890 --> 00:06:31.900 align:start position:0% fully so if you are a client writer on a 00:06:31.900 --> 00:06:34.600 align:start position:0% fully so if you are a client writer on a on<00:06:32.260> a<00:06:32.289> if<00:06:32.560> you're<00:06:32.800> a<00:06:32.860> adapt<00:06:33.520> writer 00:06:34.600 --> 00:06:34.610 align:start position:0% on a if you're a adapt writer 00:06:34.610 --> 00:06:35.800 align:start position:0% on a if you're a adapt writer for<00:06:34.789> the<00:06:34.849> light<00:06:35.000> clan<00:06:35.240> and<00:06:35.479> you're<00:06:35.569> calling 00:06:35.800 --> 00:06:35.810 align:start position:0% for the light clan and you're calling 00:06:35.810 --> 00:06:38.200 align:start position:0% for the light clan and you're calling this<00:06:36.020> eath<00:06:36.289> underscore<00:06:36.830> call<00:06:37.129> RPC<00:06:37.759> to<00:06:37.939> see 00:06:38.200 --> 00:06:38.210 align:start position:0% this eath underscore call RPC to see 00:06:38.210 --> 00:06:39.879 align:start position:0% this eath underscore call RPC to see what<00:06:38.419> the<00:06:38.509> output<00:06:38.659> of<00:06:39.020> some<00:06:39.349> transaction 00:06:39.879 --> 00:06:39.889 align:start position:0% what the output of some transaction 00:06:39.889 --> 00:06:42.700 align:start position:0% what the output of some transaction would<00:06:40.039> be<00:06:40.569> this<00:06:41.569> can<00:06:41.870> be<00:06:42.169> resolved<00:06:42.530> in<00:06:42.620> a 00:06:42.700 --> 00:06:42.710 align:start position:0% would be this can be resolved in a 00:06:42.710 --> 00:06:44.679 align:start position:0% would be this can be resolved in a single<00:06:43.219> round<00:06:43.400> trip<00:06:43.669> on<00:06:43.879> the<00:06:44.030> light<00:06:44.180> plant<00:06:44.509> as 00:06:44.679 --> 00:06:44.689 align:start position:0% single round trip on the light plant as 00:06:44.689 --> 00:06:47.140 align:start position:0% single round trip on the light plant as opposed<00:06:45.379> to<00:06:45.620> many<00:06:45.919> and<00:06:46.219> it's<00:06:46.699> unpredictable 00:06:47.140 --> 00:06:47.150 align:start position:0% opposed to many and it's unpredictable 00:06:47.150 --> 00:06:49.209 align:start position:0% opposed to many and it's unpredictable actually<00:06:47.870> what<00:06:48.110> kinds<00:06:48.500> of<00:06:48.590> data<00:06:48.740> are<00:06:48.979> going<00:06:49.129> to 00:06:49.209 --> 00:06:49.219 align:start position:0% actually what kinds of data are going to 00:06:49.219 --> 00:06:51.939 align:start position:0% actually what kinds of data are going to be<00:06:49.280> requested<00:06:49.849> even<00:06:50.030> if<00:06:50.870> the<00:06:51.080> contract<00:06:51.439> state 00:06:51.939 --> 00:06:51.949 align:start position:0% be requested even if the contract state 00:06:51.949 --> 00:06:55.029 align:start position:0% be requested even if the contract state itself<00:06:52.610> has<00:06:52.909> not<00:06:53.090> changed<00:06:53.590> so<00:06:54.590> another<00:06:54.830> thing 00:06:55.029 --> 00:06:55.039 align:start position:0% itself has not changed so another thing 00:06:55.039 --> 00:06:56.920 align:start position:0% itself has not changed so another thing we're<00:06:55.189> looking<00:06:55.430> into<00:06:55.759> is<00:06:55.939> ways<00:06:56.180> of<00:06:56.419> expressing 00:06:56.920 --> 00:06:56.930 align:start position:0% we're looking into is ways of expressing 00:06:56.930 --> 00:06:59.379 align:start position:0% we're looking into is ways of expressing that<00:06:57.620> a<00:06:57.650> contract<00:06:58.189> in<00:06:58.370> fact<00:06:58.639> doesn't<00:06:59.060> do 00:06:59.379 --> 00:06:59.389 align:start position:0% that a contract in fact doesn't do 00:06:59.389 --> 00:07:01.390 align:start position:0% that a contract in fact doesn't do things<00:06:59.629> like<00:06:59.810> branch<00:07:00.439> on<00:07:00.710> the<00:07:00.800> amount<00:07:01.039> of<00:07:01.189> gas 00:07:01.390 --> 00:07:01.400 align:start position:0% things like branch on the amount of gas 00:07:01.400 --> 00:07:03.939 align:start position:0% things like branch on the amount of gas provided<00:07:01.909> to<00:07:02.090> the<00:07:02.180> transaction<00:07:02.900> and<00:07:03.319> that<00:07:03.860> we 00:07:03.939 --> 00:07:03.949 align:start position:0% provided to the transaction and that we 00:07:03.949 --> 00:07:06.010 align:start position:0% provided to the transaction and that we can<00:07:04.129> prove<00:07:04.460> that<00:07:04.699> if<00:07:04.939> this<00:07:05.120> contract<00:07:05.419> state 00:07:06.010 --> 00:07:06.020 align:start position:0% can prove that if this contract state 00:07:06.020 --> 00:07:08.080 align:start position:0% can prove that if this contract state itself<00:07:06.319> has<00:07:06.530> not<00:07:06.680> changed<00:07:07.099> that<00:07:07.520> the<00:07:07.639> output 00:07:08.080 --> 00:07:08.090 align:start position:0% itself has not changed that the output 00:07:08.090 --> 00:07:09.399 align:start position:0% itself has not changed that the output will<00:07:08.120> always<00:07:08.389> be<00:07:08.690> the<00:07:08.810> same<00:07:08.960> and<00:07:09.169> that<00:07:09.259> will 00:07:09.399 --> 00:07:09.409 align:start position:0% will always be the same and that will 00:07:09.409 --> 00:07:11.830 align:start position:0% will always be the same and that will let<00:07:09.500> us<00:07:09.560> re<00:07:09.860> execute<00:07:10.430> from<00:07:10.639> this<00:07:10.849> cached<00:07:11.120> state 00:07:11.830 --> 00:07:11.840 align:start position:0% let us re execute from this cached state 00:07:11.840 --> 00:07:14.379 align:start position:0% let us re execute from this cached state proof<00:07:12.110> over<00:07:12.379> and<00:07:12.800> over<00:07:13.069> and<00:07:13.250> over<00:07:13.490> again<00:07:13.580> until 00:07:14.379 --> 00:07:14.389 align:start position:0% proof over and over and over again until 00:07:14.389 --> 00:07:16.959 align:start position:0% proof over and over and over again until finally<00:07:14.419> it<00:07:14.870> does<00:07:15.020> change<00:07:15.669> that's<00:07:16.669> very 00:07:16.959 --> 00:07:16.969 align:start position:0% finally it does change that's very 00:07:16.969 --> 00:07:20.350 align:start position:0% finally it does change that's very useful<00:07:17.150> for<00:07:17.360> reducing<00:07:17.840> bandwidth<00:07:18.199> as<00:07:18.379> well<00:07:19.360> so 00:07:20.350 --> 00:07:20.360 align:start position:0% useful for reducing bandwidth as well so 00:07:20.360 --> 00:07:22.629 align:start position:0% useful for reducing bandwidth as well so the<00:07:20.870> metering<00:07:21.650> system<00:07:22.009> we<00:07:22.099> use<00:07:22.340> is<00:07:22.580> something 00:07:22.629 --> 00:07:22.639 align:start position:0% the metering system we use is something 00:07:22.639 --> 00:07:26.640 align:start position:0% the metering system we use is something that<00:07:23.270> we<00:07:23.389> would<00:07:23.449> call<00:07:23.659> request<00:07:24.620> credits<00:07:25.039> so 00:07:26.640 --> 00:07:26.650 align:start position:0% that we would call request credits so 00:07:26.650 --> 00:07:29.680 align:start position:0% that we would call request credits so serving<00:07:27.650> nodes<00:07:27.860> are<00:07:28.159> giving<00:07:28.460> peers<00:07:28.789> credits 00:07:29.680 --> 00:07:29.690 align:start position:0% serving nodes are giving peers credits 00:07:29.690 --> 00:07:32.439 align:start position:0% serving nodes are giving peers credits so<00:07:30.069> these<00:07:31.069> credits<00:07:31.550> are<00:07:31.669> pretty<00:07:31.849> arbitrary 00:07:32.439 --> 00:07:32.449 align:start position:0% so these credits are pretty arbitrary 00:07:32.449 --> 00:07:34.240 align:start position:0% so these credits are pretty arbitrary each<00:07:32.599> node<00:07:32.840> comes<00:07:33.110> up<00:07:33.259> with<00:07:33.409> its<00:07:33.560> own<00:07:33.710> pricing 00:07:34.240 --> 00:07:34.250 align:start position:0% each node comes up with its own pricing 00:07:34.250 --> 00:07:36.519 align:start position:0% each node comes up with its own pricing scheme<00:07:34.490> which<00:07:34.699> is<00:07:34.729> based<00:07:35.060> on<00:07:35.300> data<00:07:35.930> it<00:07:36.110> gathers 00:07:36.519 --> 00:07:36.529 align:start position:0% scheme which is based on data it gathers 00:07:36.529 --> 00:07:39.430 align:start position:0% scheme which is based on data it gathers over<00:07:36.830> time<00:07:37.039> on<00:07:37.539> how<00:07:38.539> long<00:07:38.750> these<00:07:38.930> requests<00:07:39.409> are 00:07:39.430 --> 00:07:39.440 align:start position:0% over time on how long these requests are 00:07:39.440 --> 00:07:41.830 align:start position:0% over time on how long these requests are taking<00:07:39.740> to<00:07:39.830> serve<00:07:40.009> and<00:07:40.250> then<00:07:40.819> the<00:07:41.569> light 00:07:41.830 --> 00:07:41.840 align:start position:0% taking to serve and then the light 00:07:41.840 --> 00:07:43.390 align:start position:0% taking to serve and then the light client<00:07:42.199> peers<00:07:42.409> which<00:07:42.590> want<00:07:42.770> to<00:07:42.889> request<00:07:43.190> data 00:07:43.390 --> 00:07:43.400 align:start position:0% client peers which want to request data 00:07:43.400 --> 00:07:46.420 align:start position:0% client peers which want to request data are<00:07:44.240> sort<00:07:44.539> of<00:07:44.569> spending<00:07:45.199> these<00:07:45.319> credits<00:07:45.800> to 00:07:46.420 --> 00:07:46.430 align:start position:0% are sort of spending these credits to 00:07:46.430 --> 00:07:48.490 align:start position:0% are sort of spending these credits to get<00:07:46.669> things<00:07:46.969> like<00:07:47.210> block<00:07:47.479> bodies<00:07:47.930> or<00:07:48.259> to<00:07:48.349> see 00:07:48.490 --> 00:07:48.500 align:start position:0% get things like block bodies or to see 00:07:48.500 --> 00:07:49.749 align:start position:0% get things like block bodies or to see what<00:07:48.680> the<00:07:48.740> outputs<00:07:49.099> of<00:07:49.190> transaction 00:07:49.749 --> 00:07:49.759 align:start position:0% what the outputs of transaction 00:07:49.759 --> 00:07:51.610 align:start position:0% what the outputs of transaction execution<00:07:49.879> would<00:07:50.419> be<00:07:50.539> and<00:07:50.779> we<00:07:51.289> could<00:07:51.469> make 00:07:51.610 --> 00:07:51.620 align:start position:0% execution would be and we could make 00:07:51.620 --> 00:07:53.409 align:start position:0% execution would be and we could make this<00:07:51.800> micro<00:07:52.219> payment<00:07:52.610> based<00:07:52.759> in<00:07:53.000> the<00:07:53.089> future 00:07:53.409 --> 00:07:53.419 align:start position:0% this micro payment based in the future 00:07:53.419 --> 00:07:55.450 align:start position:0% this micro payment based in the future that's<00:07:53.960> another<00:07:54.199> active<00:07:55.159> area<00:07:55.370> of<00:07:55.400> research 00:07:55.450 --> 00:07:55.460 align:start position:0% that's another active area of research 00:07:55.460 --> 00:07:59.230 align:start position:0% that's another active area of research because<00:07:56.029> in<00:07:56.300> fact<00:07:57.339> in<00:07:58.339> the<00:07:58.639> future<00:07:59.029> I<00:07:59.060> think 00:07:59.230 --> 00:07:59.240 align:start position:0% because in fact in the future I think 00:07:59.240 --> 00:08:02.740 align:start position:0% because in fact in the future I think it's<00:07:59.539> very<00:07:59.839> unlikely<00:08:00.169> that<00:08:01.300> your<00:08:02.300> average 00:08:02.740 --> 00:08:02.750 align:start position:0% it's very unlikely that your average 00:08:02.750 --> 00:08:04.749 align:start position:0% it's very unlikely that your average person<00:08:02.960> will<00:08:03.349> be<00:08:03.469> running<00:08:03.680> a<00:08:03.830> full<00:08:04.099> node<00:08:04.310> yet 00:08:04.749 --> 00:08:04.759 align:start position:0% person will be running a full node yet 00:08:04.759 --> 00:08:07.450 align:start position:0% person will be running a full node yet we<00:08:05.150> need<00:08:05.479> full<00:08:05.930> nodes<00:08:06.289> on<00:08:06.620> the<00:08:06.860> network<00:08:06.889> to<00:08:07.339> be 00:08:07.450 --> 00:08:07.460 align:start position:0% we need full nodes on the network to be 00:08:07.460 --> 00:08:09.040 align:start position:0% we need full nodes on the network to be able<00:08:07.550> to<00:08:07.789> serve<00:08:08.089> the<00:08:08.120> requests<00:08:08.779> to<00:08:08.870> light 00:08:09.040 --> 00:08:09.050 align:start position:0% able to serve the requests to light 00:08:09.050 --> 00:08:11.019 align:start position:0% able to serve the requests to light clients<00:08:09.379> so<00:08:09.830> you<00:08:09.919> need<00:08:10.039> an<00:08:10.129> incentivization 00:08:11.019 --> 00:08:11.029 align:start position:0% clients so you need an incentivization 00:08:11.029 --> 00:08:13.029 align:start position:0% clients so you need an incentivization layer<00:08:11.240> and<00:08:11.509> request<00:08:12.139> credits<00:08:12.560> although<00:08:12.889> right 00:08:13.029 --> 00:08:13.039 align:start position:0% layer and request credits although right 00:08:13.039 --> 00:08:17.290 align:start position:0% layer and request credits although right now<00:08:13.219> they're<00:08:13.460> simply<00:08:13.849> just<00:08:14.139> time-based<00:08:16.300> just 00:08:17.290 --> 00:08:17.300 align:start position:0% now they're simply just time-based just 00:08:17.300 --> 00:08:19.360 align:start position:0% now they're simply just time-based just provide<00:08:17.659> a<00:08:17.690> sort<00:08:18.469> of<00:08:18.560> foundation<00:08:19.099> that<00:08:19.129> we<00:08:19.339> can 00:08:19.360 --> 00:08:19.370 align:start position:0% provide a sort of foundation that we can 00:08:19.370 --> 00:08:21.879 align:start position:0% provide a sort of foundation that we can build<00:08:19.520> micro<00:08:20.029> payments<00:08:20.389> on<00:08:20.509> to<00:08:20.750> in<00:08:21.440> the<00:08:21.589> future 00:08:21.879 --> 00:08:21.889 align:start position:0% build micro payments on to in the future 00:08:21.889 --> 00:08:23.860 align:start position:0% build micro payments on to in the future and<00:08:22.039> it's<00:08:22.339> a<00:08:22.400> very<00:08:22.580> generic<00:08:22.669> mechanism<00:08:23.360> that 00:08:23.860 --> 00:08:23.870 align:start position:0% and it's a very generic mechanism that 00:08:23.870 --> 00:08:25.659 align:start position:0% and it's a very generic mechanism that we<00:08:23.960> could<00:08:24.169> plug<00:08:24.860> a<00:08:24.919> whole<00:08:25.159> lot<00:08:25.310> of<00:08:25.430> different 00:08:25.659 --> 00:08:25.669 align:start position:0% we could plug a whole lot of different 00:08:25.669 --> 00:08:28.510 align:start position:0% we could plug a whole lot of different schemes<00:08:25.940> into<00:08:27.039> and<00:08:28.039> of<00:08:28.190> course<00:08:28.400> these 00:08:28.510 --> 00:08:28.520 align:start position:0% schemes into and of course these 00:08:28.520 --> 00:08:30.029 align:start position:0% schemes into and of course these different<00:08:28.849> requests<00:08:29.150> have<00:08:29.270> different<00:08:29.569> costs 00:08:30.029 --> 00:08:30.039 align:start position:0% different requests have different costs 00:08:30.039 --> 00:08:33.159 align:start position:0% different requests have different costs so<00:08:31.039> in<00:08:31.520> the<00:08:31.699> case<00:08:31.879> of<00:08:31.909> getting<00:08:32.419> a<00:08:32.599> transaction 00:08:33.159 --> 00:08:33.169 align:start position:0% so in the case of getting a transaction 00:08:33.169 --> 00:08:34.959 align:start position:0% so in the case of getting a transaction execution<00:08:33.260> you're<00:08:33.829> actually<00:08:34.099> paying<00:08:34.310> per 00:08:34.959 --> 00:08:34.969 align:start position:0% execution you're actually paying per 00:08:34.969 --> 00:08:37.300 align:start position:0% execution you're actually paying per unit<00:08:35.810> of<00:08:35.899> gas<00:08:36.110> per<00:08:36.500> unit<00:08:36.890> of<00:08:36.949> computation 00:08:37.300 --> 00:08:37.310 align:start position:0% unit of gas per unit of computation 00:08:37.310 --> 00:08:39.339 align:start position:0% unit of gas per unit of computation whereas<00:08:38.060> if<00:08:38.449> you're<00:08:38.690> fetching<00:08:38.899> a<00:08:39.110> bunch<00:08:39.260> of 00:08:39.339 --> 00:08:39.349 align:start position:0% whereas if you're fetching a bunch of 00:08:39.349 --> 00:08:42.009 align:start position:0% whereas if you're fetching a bunch of headers<00:08:39.649> you're<00:08:39.860> paying<00:08:40.070> per<00:08:40.310> header<00:08:41.019> so 00:08:42.009 --> 00:08:42.019 align:start position:0% headers you're paying per header so 00:08:42.019 --> 00:08:43.460 align:start position:0% headers you're paying per header so another<00:08:42.680> cool 00:08:43.460 --> 00:08:43.470 align:start position:0% another cool 00:08:43.470 --> 00:08:46.880 align:start position:0% another cool is<00:08:44.360> publish/subscribe<00:08:45.360> so<00:08:45.720> that's<00:08:46.530> kind<00:08:46.770> of 00:08:46.880 --> 00:08:46.890 align:start position:0% is publish/subscribe so that's kind of 00:08:46.890 --> 00:08:49.640 align:start position:0% is publish/subscribe so that's kind of fun<00:08:47.130> to<00:08:47.400> bake<00:08:48.150> into<00:08:48.480> the<00:08:48.570> protocol<00:08:49.050> because 00:08:49.640 --> 00:08:49.650 align:start position:0% fun to bake into the protocol because 00:08:49.650 --> 00:08:51.830 align:start position:0% fun to bake into the protocol because when<00:08:50.220> you're<00:08:50.370> polling<00:08:50.940> for<00:08:51.150> things<00:08:51.360> like<00:08:51.600> log 00:08:51.830 --> 00:08:51.840 align:start position:0% when you're polling for things like log 00:08:51.840 --> 00:08:55.910 align:start position:0% when you're polling for things like log events<00:08:52.260> changing<00:08:52.740> and<00:08:54.410> you<00:08:55.410> that<00:08:55.620> means<00:08:55.800> that 00:08:55.910 --> 00:08:55.920 align:start position:0% events changing and you that means that 00:08:55.920 --> 00:08:57.740 align:start position:0% events changing and you that means that on<00:08:56.040> the<00:08:56.160> light<00:08:56.310> client<00:08:56.760> you<00:08:56.880> may<00:08:56.910> be<00:08:57.120> checking 00:08:57.740 --> 00:08:57.750 align:start position:0% on the light client you may be checking 00:08:57.750 --> 00:08:59.920 align:start position:0% on the light client you may be checking bloom<00:08:58.080> filters<00:08:58.530> and<00:08:58.710> things<00:08:58.860> like<00:08:59.010> that<00:08:59.070> and 00:08:59.920 --> 00:08:59.930 align:start position:0% bloom filters and things like that and 00:08:59.930 --> 00:09:02.150 align:start position:0% bloom filters and things like that and fetching<00:09:00.930> a<00:09:01.020> bunch<00:09:01.230> of<00:09:01.410> headers<00:09:01.620> from<00:09:02.010> the 00:09:02.150 --> 00:09:02.160 align:start position:0% fetching a bunch of headers from the 00:09:02.160 --> 00:09:03.890 align:start position:0% fetching a bunch of headers from the network<00:09:02.430> which<00:09:02.700> may<00:09:02.880> be<00:09:02.940> false<00:09:03.270> positive<00:09:03.720> so 00:09:03.890 --> 00:09:03.900 align:start position:0% network which may be false positive so 00:09:03.900 --> 00:09:06.590 align:start position:0% network which may be false positive so in<00:09:04.050> fact<00:09:04.260> the<00:09:04.740> full<00:09:05.040> node<00:09:05.280> peers<00:09:05.730> know<00:09:06.330> better 00:09:06.590 --> 00:09:06.600 align:start position:0% in fact the full node peers know better 00:09:06.600 --> 00:09:09.050 align:start position:0% in fact the full node peers know better than<00:09:06.840> we<00:09:07.020> do<00:09:07.260> when<00:09:07.590> something<00:09:08.040> has<00:09:08.190> changed<00:09:08.220> so 00:09:09.050 --> 00:09:09.060 align:start position:0% than we do when something has changed so 00:09:09.060 --> 00:09:11.060 align:start position:0% than we do when something has changed so allowing<00:09:09.540> subscriptions<00:09:10.440> at<00:09:10.590> the<00:09:10.680> protocol 00:09:11.060 --> 00:09:11.070 align:start position:0% allowing subscriptions at the protocol 00:09:11.070 --> 00:09:12.410 align:start position:0% allowing subscriptions at the protocol level<00:09:11.130> means<00:09:11.520> that<00:09:11.670> we<00:09:11.730> can<00:09:11.850> have<00:09:11.880> a<00:09:12.000> much<00:09:12.210> more 00:09:12.410 --> 00:09:12.420 align:start position:0% level means that we can have a much more 00:09:12.420 --> 00:09:16.100 align:start position:0% level means that we can have a much more efficient<00:09:12.900> light<00:09:13.080> client<00:09:13.910> the<00:09:14.910> caveat<00:09:15.900> is 00:09:16.100 --> 00:09:16.110 align:start position:0% efficient light client the caveat is 00:09:16.110 --> 00:09:18.590 align:start position:0% efficient light client the caveat is that<00:09:16.170> it's<00:09:16.740> semi<00:09:17.490> difficult<00:09:17.970> to<00:09:18.120> catch<00:09:18.300> out 00:09:18.590 --> 00:09:18.600 align:start position:0% that it's semi difficult to catch out 00:09:18.600 --> 00:09:20.120 align:start position:0% that it's semi difficult to catch out peers<00:09:18.900> who<00:09:19.170> don't<00:09:19.410> publish<00:09:19.800> when<00:09:20.010> they're 00:09:20.120 --> 00:09:20.130 align:start position:0% peers who don't publish when they're 00:09:20.130 --> 00:09:21.710 align:start position:0% peers who don't publish when they're supposed<00:09:20.280> to<00:09:20.520> so<00:09:20.790> for<00:09:21.000> example<00:09:21.390> if<00:09:21.510> we're 00:09:21.710 --> 00:09:21.720 align:start position:0% supposed to so for example if we're 00:09:21.720 --> 00:09:26.860 align:start position:0% supposed to so for example if we're tracking<00:09:22.500> log<00:09:23.370> events<00:09:23.850> in<00:09:24.060> some<00:09:24.420> contract<00:09:25.220> and 00:09:26.860 --> 00:09:26.870 align:start position:0% tracking log events in some contract and 00:09:26.870 --> 00:09:29.570 align:start position:0% tracking log events in some contract and this<00:09:27.870> peer<00:09:28.170> is<00:09:28.290> supposed<00:09:28.620> to<00:09:28.740> send<00:09:29.100> us<00:09:29.310> a 00:09:29.570 --> 00:09:29.580 align:start position:0% this peer is supposed to send us a 00:09:29.580 --> 00:09:31.940 align:start position:0% this peer is supposed to send us a message<00:09:30.030> when<00:09:30.660> log<00:09:30.840> events<00:09:31.110> change<00:09:31.380> or<00:09:31.620> log 00:09:31.940 --> 00:09:31.950 align:start position:0% message when log events change or log 00:09:31.950 --> 00:09:34.280 align:start position:0% message when log events change or log event<00:09:32.190> is<00:09:32.280> issued<00:09:32.640> but<00:09:33.210> doesn't<00:09:33.630> it's<00:09:34.020> fairly 00:09:34.280 --> 00:09:34.290 align:start position:0% event is issued but doesn't it's fairly 00:09:34.290 --> 00:09:35.390 align:start position:0% event is issued but doesn't it's fairly difficult<00:09:34.590> to<00:09:34.890> catch<00:09:35.040> them<00:09:35.220> out<00:09:35.280> without 00:09:35.390 --> 00:09:35.400 align:start position:0% difficult to catch them out without 00:09:35.400 --> 00:09:38.000 align:start position:0% difficult to catch them out without doing<00:09:35.790> some<00:09:35.970> kind<00:09:36.150> of<00:09:36.330> periodic<00:09:37.290> checking<00:09:37.830> of 00:09:38.000 --> 00:09:38.010 align:start position:0% doing some kind of periodic checking of 00:09:38.010 --> 00:09:42.410 align:start position:0% doing some kind of periodic checking of the<00:09:38.130> validity<00:09:38.490> of<00:09:38.670> data<00:09:38.990> but<00:09:39.990> if<00:09:41.180> the<00:09:42.180> network 00:09:42.410 --> 00:09:42.420 align:start position:0% the validity of data but if the network 00:09:42.420 --> 00:09:45.320 align:start position:0% the validity of data but if the network is<00:09:42.750> mostly<00:09:43.080> honest<00:09:43.560> and<00:09:43.920> the<00:09:44.300> damage<00:09:45.300> that 00:09:45.320 --> 00:09:45.330 align:start position:0% is mostly honest and the damage that 00:09:45.330 --> 00:09:48.020 align:start position:0% is mostly honest and the damage that they<00:09:45.540> can<00:09:45.690> do<00:09:45.780> by<00:09:45.930> omitting<00:09:46.520> log<00:09:47.520> events<00:09:47.910> or 00:09:48.020 --> 00:09:48.030 align:start position:0% they can do by omitting log events or 00:09:48.030 --> 00:09:49.580 align:start position:0% they can do by omitting log events or such<00:09:48.240> isn't<00:09:48.570> that<00:09:48.660> high<00:09:48.840> it's<00:09:49.080> very<00:09:49.290> unlikely 00:09:49.580 --> 00:09:49.590 align:start position:0% such isn't that high it's very unlikely 00:09:49.590 --> 00:09:51.530 align:start position:0% such isn't that high it's very unlikely that<00:09:49.740> they<00:09:49.950> would<00:09:50.070> do<00:09:50.190> it 00:09:51.530 --> 00:09:51.540 align:start position:0% that they would do it 00:09:51.540 --> 00:09:53.810 align:start position:0% that they would do it so<00:09:52.020> I<00:09:52.290> would<00:09:52.560> like<00:09:52.710> to<00:09:52.920> now<00:09:53.190> that<00:09:53.250> I<00:09:53.400> have<00:09:53.640> you 00:09:53.810 --> 00:09:53.820 align:start position:0% so I would like to now that I have you 00:09:53.820 --> 00:09:56.150 align:start position:0% so I would like to now that I have you all<00:09:54.000> here<00:09:54.480> make<00:09:55.380> a<00:09:55.410> little<00:09:55.590> bit<00:09:55.770> of<00:09:55.890> a<00:09:55.950> block 00:09:56.150 --> 00:09:56.160 align:start position:0% all here make a little bit of a block 00:09:56.160 --> 00:10:00.410 align:start position:0% all here make a little bit of a block pruning<00:09:56.670> proposal<00:09:57.300> so<00:09:57.840> for<00:09:58.290> example<00:09:59.420> right 00:10:00.410 --> 00:10:00.420 align:start position:0% pruning proposal so for example right 00:10:00.420 --> 00:10:02.840 align:start position:0% pruning proposal so for example right now<00:10:00.630> we<00:10:01.050> have<00:10:01.200> all<00:10:01.470> nodes<00:10:01.800> storing<00:10:02.370> all<00:10:02.640> the 00:10:02.840 --> 00:10:02.850 align:start position:0% now we have all nodes storing all the 00:10:02.850 --> 00:10:06.440 align:start position:0% now we have all nodes storing all the blockchain<00:10:03.420> and<00:10:03.660> that's<00:10:04.520> a<00:10:05.520> pretty<00:10:06.210> high 00:10:06.440 --> 00:10:06.450 align:start position:0% blockchain and that's a pretty high 00:10:06.450 --> 00:10:09.170 align:start position:0% blockchain and that's a pretty high storage<00:10:06.900> requirement<00:10:07.500> and<00:10:07.590> in<00:10:07.710> fact<00:10:07.970> we<00:10:08.970> can 00:10:09.170 --> 00:10:09.180 align:start position:0% storage requirement and in fact we can 00:10:09.180 --> 00:10:12.410 align:start position:0% storage requirement and in fact we can we<00:10:09.510> can<00:10:09.630> do<00:10:09.750> much<00:10:09.930> better<00:10:10.070> so<00:10:11.090> one<00:10:12.090> thing<00:10:12.300> we 00:10:12.410 --> 00:10:12.420 align:start position:0% we can do much better so one thing we 00:10:12.420 --> 00:10:13.820 align:start position:0% we can do much better so one thing we can<00:10:12.570> do<00:10:12.750> on<00:10:12.780> a<00:10:12.990> light<00:10:13.230> client<00:10:13.620> is<00:10:13.710> actually 00:10:13.820 --> 00:10:13.830 align:start position:0% can do on a light client is actually 00:10:13.830 --> 00:10:17.270 align:start position:0% can do on a light client is actually store<00:10:14.310> almost<00:10:14.610> none<00:10:15.510> of<00:10:15.930> the<00:10:16.560> history<00:10:16.920> and<00:10:17.100> we 00:10:17.270 --> 00:10:17.280 align:start position:0% store almost none of the history and we 00:10:17.280 --> 00:10:18.860 align:start position:0% store almost none of the history and we can<00:10:17.430> do<00:10:17.520> this<00:10:17.670> through<00:10:17.850> a<00:10:17.910> cool<00:10:18.090> tool<00:10:18.600> called 00:10:18.860 --> 00:10:18.870 align:start position:0% can do this through a cool tool called 00:10:18.870 --> 00:10:20.810 align:start position:0% can do this through a cool tool called canonical<00:10:19.500> hash<00:10:19.950> trees<00:10:20.340> which<00:10:20.610> will 00:10:20.810 --> 00:10:20.820 align:start position:0% canonical hash trees which will 00:10:20.820 --> 00:10:24.920 align:start position:0% canonical hash trees which will abbreviate<00:10:21.030> to<00:10:21.510> CHT<00:10:22.490> and<00:10:23.490> the<00:10:23.940> basic<00:10:24.300> idea<00:10:24.690> is 00:10:24.920 --> 00:10:24.930 align:start position:0% abbreviate to CHT and the basic idea is 00:10:24.930 --> 00:10:28.520 align:start position:0% abbreviate to CHT and the basic idea is that<00:10:25.340> for<00:10:26.340> every<00:10:26.640> and<00:10:27.240> these<00:10:27.540> so<00:10:27.930> so<00:10:28.290> death 00:10:28.520 --> 00:10:28.530 align:start position:0% that for every and these so so death 00:10:28.530 --> 00:10:30.710 align:start position:0% that for every and these so so death actually<00:10:28.740> has<00:10:29.040> a<00:10:29.430> canonical<00:10:29.910> hash<00:10:30.270> trees<00:10:30.540> but 00:10:30.710 --> 00:10:30.720 align:start position:0% actually has a canonical hash trees but 00:10:30.720 --> 00:10:32.570 align:start position:0% actually has a canonical hash trees but they<00:10:30.810> work<00:10:30.930> slightly<00:10:31.170> differently<00:10:31.320> and<00:10:32.220> I<00:10:32.430> can 00:10:32.570 --> 00:10:32.580 align:start position:0% they work slightly differently and I can 00:10:32.580 --> 00:10:35.090 align:start position:0% they work slightly differently and I can explain<00:10:32.910> the<00:10:33.060> difference<00:10:33.530> but<00:10:34.530> in<00:10:34.710> parody 00:10:35.090 --> 00:10:35.100 align:start position:0% explain the difference but in parody 00:10:35.100 --> 00:10:38.720 align:start position:0% explain the difference but in parody what<00:10:35.250> they<00:10:35.400> do<00:10:35.460> is<00:10:35.960> every<00:10:36.960> batch<00:10:37.200> of<00:10:37.530> say<00:10:37.740> 2048 00:10:38.720 --> 00:10:38.730 align:start position:0% what they do is every batch of say 2048 00:10:38.730 --> 00:10:42.290 align:start position:0% what they do is every batch of say 2048 or<00:10:38.910> 4096<00:10:39.630> blocks<00:10:40.160> you<00:10:41.160> basically<00:10:41.610> make<00:10:41.760> a<00:10:41.790> tree 00:10:42.290 --> 00:10:42.300 align:start position:0% or 4096 blocks you basically make a tree 00:10:42.300 --> 00:10:44.990 align:start position:0% or 4096 blocks you basically make a tree like<00:10:42.840> a<00:10:42.870> Merkel<00:10:43.290> tree<00:10:43.560> mapping<00:10:44.310> block<00:10:44.580> number 00:10:44.990 --> 00:10:45.000 align:start position:0% like a Merkel tree mapping block number 00:10:45.000 --> 00:10:47.930 align:start position:0% like a Merkel tree mapping block number to<00:10:45.480> the<00:10:45.990> canonical<00:10:46.440> block<00:10:46.920> hash<00:10:47.160> as<00:10:47.370> the<00:10:47.790> light 00:10:47.930 --> 00:10:47.940 align:start position:0% to the canonical block hash as the light 00:10:47.940 --> 00:10:49.880 align:start position:0% to the canonical block hash as the light client<00:10:48.330> has<00:10:48.450> seen<00:10:48.750> so<00:10:49.020> the<00:10:49.140> my<00:10:49.320> client<00:10:49.650> sinks 00:10:49.880 --> 00:10:49.890 align:start position:0% client has seen so the my client sinks 00:10:49.890 --> 00:10:52.130 align:start position:0% client has seen so the my client sinks the<00:10:49.980> network<00:10:50.280> and<00:10:50.490> it<00:10:50.790> sees<00:10:51.030> that<00:10:51.330> in<00:10:51.840> ancient 00:10:52.130 --> 00:10:52.140 align:start position:0% the network and it sees that in ancient 00:10:52.140 --> 00:10:54.950 align:start position:0% the network and it sees that in ancient history<00:10:52.880> block<00:10:53.880> one<00:10:54.180> had 00:10:54.950 --> 00:10:54.960 align:start position:0% history block one had 00:10:54.960 --> 00:10:56.240 align:start position:0% history block one had and<00:10:55.050> hash<00:10:55.260> so<00:10:55.560> we<00:10:55.680> have<00:10:55.800> a<00:10:55.830> little<00:10:56.070> diagram 00:10:56.240 --> 00:10:56.250 align:start position:0% and hash so we have a little diagram 00:10:56.250 --> 00:10:59.180 align:start position:0% and hash so we have a little diagram here<00:10:56.730> and<00:10:56.820> they<00:10:57.390> can<00:10:57.600> make<00:10:58.380> this<00:10:58.560> table<00:10:58.860> and 00:10:59.180 --> 00:10:59.190 align:start position:0% here and they can make this table and 00:10:59.190 --> 00:11:02.360 align:start position:0% here and they can make this table and essentially<00:10:59.880> condense<00:11:00.420> this<00:11:00.750> tree<00:11:01.220> made<00:11:02.220> of 00:11:02.360 --> 00:11:02.370 align:start position:0% essentially condense this tree made of 00:11:02.370 --> 00:11:04.400 align:start position:0% essentially condense this tree made of this<00:11:02.460> table<00:11:02.640> down<00:11:02.910> into<00:11:03.210> a<00:11:03.240> single<00:11:03.570> 32<00:11:04.200> byte 00:11:04.400 --> 00:11:04.410 align:start position:0% this table down into a single 32 byte 00:11:04.410 --> 00:11:07.070 align:start position:0% this table down into a single 32 byte hash<00:11:04.620> so<00:11:05.280> instead<00:11:06.270> of<00:11:06.390> a<00:11:06.450> light<00:11:06.630> client 00:11:07.070 --> 00:11:07.080 align:start position:0% hash so instead of a light client 00:11:07.080 --> 00:11:09.680 align:start position:0% hash so instead of a light client storing<00:11:07.680> all<00:11:08.010> those<00:11:08.190> 2048<00:11:08.910> block<00:11:09.180> headers 00:11:09.680 --> 00:11:09.690 align:start position:0% storing all those 2048 block headers 00:11:09.690 --> 00:11:12.260 align:start position:0% storing all those 2048 block headers it's<00:11:10.170> just<00:11:10.470> storing<00:11:10.740> a<00:11:10.890> single<00:11:11.340> 32<00:11:11.760> byte<00:11:12.030> hash 00:11:12.260 --> 00:11:12.270 align:start position:0% it's just storing a single 32 byte hash 00:11:12.270 --> 00:11:17.330 align:start position:0% it's just storing a single 32 byte hash and<00:11:13.730> if<00:11:14.730> we<00:11:15.090> have<00:11:15.210> a<00:11:15.270> full<00:11:15.600> client<00:11:15.900> peer<00:11:16.470> who 00:11:17.330 --> 00:11:17.340 align:start position:0% and if we have a full client peer who 00:11:17.340 --> 00:11:19.640 align:start position:0% and if we have a full client peer who has<00:11:17.970> the<00:11:18.180> same<00:11:18.420> history<00:11:18.840> they<00:11:19.110> can<00:11:19.290> give<00:11:19.410> us<00:11:19.560> a 00:11:19.640 --> 00:11:19.650 align:start position:0% has the same history they can give us a 00:11:19.650 --> 00:11:22.460 align:start position:0% has the same history they can give us a merkel<00:11:20.010> proof<00:11:20.250> of<00:11:20.460> that<00:11:20.820> 32<00:11:21.300> byte<00:11:21.540> hash<00:11:21.750> of<00:11:21.990> the 00:11:22.460 --> 00:11:22.470 align:start position:0% merkel proof of that 32 byte hash of the 00:11:22.470 --> 00:11:25.570 align:start position:0% merkel proof of that 32 byte hash of the tree<00:11:22.740> starting<00:11:23.280> at<00:11:23.400> that<00:11:23.550> 32<00:11:23.970> byte<00:11:24.120> hash<00:11:24.300> to 00:11:25.570 --> 00:11:25.580 align:start position:0% tree starting at that 32 byte hash to 00:11:25.580 --> 00:11:28.400 align:start position:0% tree starting at that 32 byte hash to give<00:11:26.580> us<00:11:26.790> that<00:11:27.210> block<00:11:27.540> header<00:11:27.810> even<00:11:28.260> though 00:11:28.400 --> 00:11:28.410 align:start position:0% give us that block header even though 00:11:28.410 --> 00:11:31.420 align:start position:0% give us that block header even though the<00:11:28.530> light<00:11:28.680> client<00:11:29.010> itself<00:11:29.310> has<00:11:29.460> discarded<00:11:29.970> it 00:11:31.420 --> 00:11:31.430 align:start position:0% the light client itself has discarded it 00:11:31.430 --> 00:11:33.950 align:start position:0% the light client itself has discarded it which<00:11:32.430> is<00:11:32.580> a<00:11:32.610> pretty<00:11:32.880> powerful<00:11:33.030> tool<00:11:33.600> it<00:11:33.780> means 00:11:33.950 --> 00:11:33.960 align:start position:0% which is a pretty powerful tool it means 00:11:33.960 --> 00:11:35.600 align:start position:0% which is a pretty powerful tool it means that<00:11:34.200> instead<00:11:34.500> of<00:11:34.650> storing<00:11:34.890> megabytes<00:11:35.460> and 00:11:35.600 --> 00:11:35.610 align:start position:0% that instead of storing megabytes and 00:11:35.610 --> 00:11:37.280 align:start position:0% that instead of storing megabytes and megabytes<00:11:36.000> or<00:11:36.180> possibly<00:11:36.720> gigabytes<00:11:37.200> of 00:11:37.280 --> 00:11:37.290 align:start position:0% megabytes or possibly gigabytes of 00:11:37.290 --> 00:11:38.480 align:start position:0% megabytes or possibly gigabytes of headers<00:11:37.560> we're<00:11:37.740> just<00:11:37.920> storing<00:11:38.220> a<00:11:38.310> few 00:11:38.480 --> 00:11:38.490 align:start position:0% headers we're just storing a few 00:11:38.490 --> 00:11:40.430 align:start position:0% headers we're just storing a few kilobytes<00:11:38.820> no<00:11:39.180> matter<00:11:39.360> how<00:11:39.780> long<00:11:40.050> the<00:11:40.260> chain 00:11:40.430 --> 00:11:40.440 align:start position:0% kilobytes no matter how long the chain 00:11:40.440 --> 00:11:42.380 align:start position:0% kilobytes no matter how long the chain gets<00:11:40.680> even<00:11:40.980> to<00:11:41.160> the<00:11:41.250> hundred<00:11:41.610> hundreds<00:11:42.300> of 00:11:42.380 --> 00:11:42.390 align:start position:0% gets even to the hundred hundreds of 00:11:42.390 --> 00:11:46.790 align:start position:0% gets even to the hundred hundreds of millions<00:11:42.690> of<00:11:42.840> blocks<00:11:44.090> and<00:11:45.260> the<00:11:46.260> reason<00:11:46.680> we 00:11:46.790 --> 00:11:46.800 align:start position:0% millions of blocks and the reason we 00:11:46.800 --> 00:11:51.890 align:start position:0% millions of blocks and the reason we choose<00:11:47.100> to<00:11:47.730> have<00:11:49.610> separate<00:11:50.610> trees<00:11:50.940> is<00:11:51.210> so<00:11:51.780> that 00:11:51.890 --> 00:11:51.900 align:start position:0% choose to have separate trees is so that 00:11:51.900 --> 00:11:53.630 align:start position:0% choose to have separate trees is so that the<00:11:51.990> light<00:11:52.170> client<00:11:52.560> can<00:11:52.710> calculate<00:11:53.250> them<00:11:53.490> as 00:11:53.630 --> 00:11:53.640 align:start position:0% the light client can calculate them as 00:11:53.640 --> 00:11:56.900 align:start position:0% the light client can calculate them as it<00:11:54.210> goes<00:11:54.420> and<00:11:54.800> furthermore<00:11:55.800> that<00:11:56.100> full<00:11:56.610> nodes 00:11:56.900 --> 00:11:56.910 align:start position:0% it goes and furthermore that full nodes 00:11:56.910 --> 00:11:59.480 align:start position:0% it goes and furthermore that full nodes can<00:11:57.900> recalculate<00:11:58.350> them<00:11:58.740> on<00:11:58.830> the<00:11:58.980> fly<00:11:59.160> so<00:11:59.370> the 00:11:59.480 --> 00:11:59.490 align:start position:0% can recalculate them on the fly so the 00:11:59.490 --> 00:12:01.010 align:start position:0% can recalculate them on the fly so the full<00:11:59.640> nodes<00:11:59.850> don't<00:12:00.090> necessarily<00:12:00.660> need<00:12:00.810> to 00:12:01.010 --> 00:12:01.020 align:start position:0% full nodes don't necessarily need to 00:12:01.020 --> 00:12:02.930 align:start position:0% full nodes don't necessarily need to store<00:12:01.260> these<00:12:01.380> roots<00:12:01.650> but<00:12:02.100> when<00:12:02.280> it<00:12:02.400> receives<00:12:02.730> a 00:12:02.930 --> 00:12:02.940 align:start position:0% store these roots but when it receives a 00:12:02.940 --> 00:12:06.530 align:start position:0% store these roots but when it receives a request<00:12:03.090> for<00:12:03.980> the<00:12:04.980> canonical<00:12:05.490> block<00:12:06.000> hash<00:12:06.270> of 00:12:06.530 --> 00:12:06.540 align:start position:0% request for the canonical block hash of 00:12:06.540 --> 00:12:08.810 align:start position:0% request for the canonical block hash of a<00:12:06.810> certain<00:12:07.140> block<00:12:07.350> number<00:12:07.740> then<00:12:08.550> it<00:12:08.640> can 00:12:08.810 --> 00:12:08.820 align:start position:0% a certain block number then it can 00:12:08.820 --> 00:12:10.820 align:start position:0% a certain block number then it can rebuild<00:12:09.240> reconstruct<00:12:09.930> that<00:12:10.080> tree<00:12:10.290> on<00:12:10.470> the<00:12:10.650> fly 00:12:10.820 --> 00:12:10.830 align:start position:0% rebuild reconstruct that tree on the fly 00:12:10.830 --> 00:12:13.910 align:start position:0% rebuild reconstruct that tree on the fly when<00:12:11.040> it's<00:12:11.070> going<00:12:11.340> to<00:12:11.430> serve<00:12:11.580> that<00:12:11.760> request<00:12:12.920> so 00:12:13.910 --> 00:12:13.920 align:start position:0% when it's going to serve that request so 00:12:13.920 --> 00:12:16.670 align:start position:0% when it's going to serve that request so we<00:12:14.340> can<00:12:14.610> do<00:12:14.880> something<00:12:15.150> similar<00:12:15.330> on<00:12:15.930> full 00:12:16.670 --> 00:12:16.680 align:start position:0% we can do something similar on full 00:12:16.680 --> 00:12:19.850 align:start position:0% we can do something similar on full nodes<00:12:16.920> so<00:12:17.580> we<00:12:18.000> already<00:12:18.360> use<00:12:18.810> this<00:12:19.050> distributed 00:12:19.850 --> 00:12:19.860 align:start position:0% nodes so we already use this distributed 00:12:19.860 --> 00:12:21.920 align:start position:0% nodes so we already use this distributed hash<00:12:20.010> table<00:12:20.460> style<00:12:20.760> routing<00:12:21.270> in<00:12:21.450> the<00:12:21.630> network 00:12:21.920 --> 00:12:21.930 align:start position:0% hash table style routing in the network 00:12:21.930 --> 00:12:24.080 align:start position:0% hash table style routing in the network protocol<00:12:22.320> although<00:12:22.860> it's<00:12:23.010> not<00:12:23.220> really<00:12:23.580> used 00:12:24.080 --> 00:12:24.090 align:start position:0% protocol although it's not really used 00:12:24.090 --> 00:12:25.730 align:start position:0% protocol although it's not really used for<00:12:24.360> anything<00:12:24.720> right<00:12:24.840> now<00:12:24.900> we<00:12:25.050> expect<00:12:25.560> that 00:12:25.730 --> 00:12:25.740 align:start position:0% for anything right now we expect that 00:12:25.740 --> 00:12:28.760 align:start position:0% for anything right now we expect that all<00:12:25.890> nodes<00:12:26.340> are<00:12:26.670> storing<00:12:27.000> all<00:12:27.180> data<00:12:27.690> which<00:12:28.560> is 00:12:28.760 --> 00:12:28.770 align:start position:0% all nodes are storing all data which is 00:12:28.770 --> 00:12:31.780 align:start position:0% all nodes are storing all data which is an<00:12:29.610> assumption<00:12:30.060> that<00:12:30.300> we'd<00:12:30.420> like<00:12:30.510> to<00:12:30.570> relax<00:12:30.930> so 00:12:31.780 --> 00:12:31.790 align:start position:0% an assumption that we'd like to relax so 00:12:31.790 --> 00:12:35.240 align:start position:0% an assumption that we'd like to relax so we<00:12:32.790> have<00:12:33.000> this<00:12:33.510> idea<00:12:33.810> of<00:12:34.170> splitting<00:12:34.710> up<00:12:34.980> nodes 00:12:35.240 --> 00:12:35.250 align:start position:0% we have this idea of splitting up nodes 00:12:35.250 --> 00:12:39.290 align:start position:0% we have this idea of splitting up nodes by<00:12:35.550> node<00:12:35.760> ID<00:12:36.000> so<00:12:36.360> every<00:12:36.600> node<00:12:36.780> has<00:12:36.810> a<00:12:38.300> 160-bit 00:12:39.290 --> 00:12:39.300 align:start position:0% by node ID so every node has a 160-bit 00:12:39.300 --> 00:12:43.820 align:start position:0% by node ID so every node has a 160-bit ID<00:12:41.810> or<00:12:42.810> it<00:12:43.020> may<00:12:43.140> be<00:12:43.170> a<00:12:43.320> slightly<00:12:43.650> different 00:12:43.820 --> 00:12:43.830 align:start position:0% ID or it may be a slightly different 00:12:43.830 --> 00:12:45.200 align:start position:0% ID or it may be a slightly different number<00:12:44.100> but<00:12:44.400> it's<00:12:44.760> not<00:12:44.910> particularly 00:12:45.200 --> 00:12:45.210 align:start position:0% number but it's not particularly 00:12:45.210 --> 00:12:48.110 align:start position:0% number but it's not particularly important<00:12:45.720> exactly<00:12:46.140> how<00:12:46.200> long<00:12:46.350> the<00:12:46.470> ideas<00:12:47.120> but 00:12:48.110 --> 00:12:48.120 align:start position:0% important exactly how long the ideas but 00:12:48.120 --> 00:12:50.420 align:start position:0% important exactly how long the ideas but we<00:12:48.240> split<00:12:48.630> up<00:12:48.750> in<00:12:49.230> the<00:12:49.470> routing<00:12:49.650> mechanism<00:12:50.310> of 00:12:50.420 --> 00:12:50.430 align:start position:0% we split up in the routing mechanism of 00:12:50.430 --> 00:12:52.340 align:start position:0% we split up in the routing mechanism of each<00:12:50.550> of<00:12:50.820> each<00:12:51.000> node<00:12:51.270> we<00:12:51.450> split<00:12:51.780> up<00:12:51.810> all<00:12:52.110> the 00:12:52.340 --> 00:12:52.350 align:start position:0% each of each node we split up all the 00:12:52.350 --> 00:12:55.700 align:start position:0% each of each node we split up all the peers<00:12:52.680> that<00:12:52.740> it<00:12:52.980> has<00:12:53.160> into<00:12:54.120> buckets<00:12:54.930> prefixed 00:12:55.700 --> 00:12:55.710 align:start position:0% peers that it has into buckets prefixed 00:12:55.710 --> 00:13:00.260 align:start position:0% peers that it has into buckets prefixed by<00:12:55.770> certain<00:12:56.220> IDs<00:12:56.580> so<00:12:58.490> that<00:12:59.490> means<00:12:59.760> that<00:13:00.060> each 00:13:00.260 --> 00:13:00.270 align:start position:0% by certain IDs so that means that each 00:13:00.270 --> 00:13:01.940 align:start position:0% by certain IDs so that means that each peer<00:13:00.600> is<00:13:00.720> trying<00:13:01.080> to<00:13:01.260> have<00:13:01.410> a<00:13:01.440> certain<00:13:01.920> number 00:13:01.940 --> 00:13:01.950 align:start position:0% peer is trying to have a certain number 00:13:01.950 --> 00:13:04.790 align:start position:0% peer is trying to have a certain number of<00:13:02.370> other<00:13:02.550> peers<00:13:02.970> whose<00:13:03.510> IDs<00:13:03.780> are<00:13:04.110> distributed 00:13:04.790 --> 00:13:04.800 align:start position:0% of other peers whose IDs are distributed 00:13:04.800 --> 00:13:06.889 align:start position:0% of other peers whose IDs are distributed fairly<00:13:05.750> you 00:13:06.889 --> 00:13:06.899 align:start position:0% fairly you 00:13:06.899 --> 00:13:10.759 align:start position:0% fairly you formerly<00:13:07.259> across<00:13:07.709> that<00:13:08.009> ID<00:13:08.249> space<00:13:08.699> so<00:13:09.389> in<00:13:09.899> the 00:13:10.759 --> 00:13:10.769 align:start position:0% formerly across that ID space so in the 00:13:10.769 --> 00:13:14.150 align:start position:0% formerly across that ID space so in the DHT<00:13:11.430> or<00:13:11.939> distributed<00:13:12.509> hash<00:13:12.749> table<00:13:13.319> world<00:13:13.559> what 00:13:14.150 --> 00:13:14.160 align:start position:0% DHT or distributed hash table world what 00:13:14.160 --> 00:13:16.910 align:start position:0% DHT or distributed hash table world what we're<00:13:14.309> doing<00:13:14.579> is<00:13:14.819> saying<00:13:15.569> nodes<00:13:16.230> with<00:13:16.529> an<00:13:16.649> ID 00:13:16.910 --> 00:13:16.920 align:start position:0% we're doing is saying nodes with an ID 00:13:16.920 --> 00:13:19.519 align:start position:0% we're doing is saying nodes with an ID close<00:13:17.699> to<00:13:18.059> the<00:13:18.360> hash<00:13:18.629> of<00:13:18.990> the<00:13:19.110> file<00:13:19.319> we're 00:13:19.519 --> 00:13:19.529 align:start position:0% close to the hash of the file we're 00:13:19.529 --> 00:13:21.499 align:start position:0% close to the hash of the file we're trying<00:13:19.740> to<00:13:19.829> store<00:13:20.040> are<00:13:20.300> responsible<00:13:21.300> for 00:13:21.499 --> 00:13:21.509 align:start position:0% trying to store are responsible for 00:13:21.509 --> 00:13:23.030 align:start position:0% trying to store are responsible for storing<00:13:21.629> this<00:13:21.809> hot<00:13:21.990> file<00:13:22.259> we<00:13:22.800> can<00:13:22.920> do 00:13:23.030 --> 00:13:23.040 align:start position:0% storing this hot file we can do 00:13:23.040 --> 00:13:24.559 align:start position:0% storing this hot file we can do something<00:13:23.459> fairly<00:13:23.790> similar<00:13:24.179> for<00:13:24.389> block 00:13:24.559 --> 00:13:24.569 align:start position:0% something fairly similar for block 00:13:24.569 --> 00:13:28.669 align:start position:0% something fairly similar for block pruning<00:13:25.050> and<00:13:25.230> say<00:13:26.040> nodes<00:13:26.790> whose<00:13:27.449> ID<00:13:28.019> starts 00:13:28.669 --> 00:13:28.679 align:start position:0% pruning and say nodes whose ID starts 00:13:28.679 --> 00:13:32.329 align:start position:0% pruning and say nodes whose ID starts with<00:13:29.100> zero<00:13:30.029> zero<00:13:30.360> zero<00:13:30.449> one<00:13:30.990> are<00:13:31.740> going<00:13:32.100> to 00:13:32.329 --> 00:13:32.339 align:start position:0% with zero zero zero one are going to 00:13:32.339 --> 00:13:36.230 align:start position:0% with zero zero zero one are going to serve<00:13:32.699> the<00:13:33.300> first<00:13:34.259> out<00:13:34.589> of<00:13:34.889> every<00:13:35.339> batch<00:13:35.970> of 00:13:36.230 --> 00:13:36.240 align:start position:0% serve the first out of every batch of 00:13:36.240 --> 00:13:37.669 align:start position:0% serve the first out of every batch of blocks<00:13:36.449> so<00:13:36.689> we<00:13:36.869> can<00:13:37.019> split<00:13:37.230> up<00:13:37.379> the<00:13:37.529> whole 00:13:37.669 --> 00:13:37.679 align:start position:0% blocks so we can split up the whole 00:13:37.679 --> 00:13:41.059 align:start position:0% blocks so we can split up the whole block<00:13:37.920> chain<00:13:38.249> and<00:13:38.459> to<00:13:38.879> say<00:13:39.059> batches<00:13:39.660> of<00:13:40.069> 2048 00:13:41.059 --> 00:13:41.069 align:start position:0% block chain and to say batches of 2048 00:13:41.069 --> 00:13:43.759 align:start position:0% block chain and to say batches of 2048 or<00:13:41.249> 4096<00:13:41.970> and<00:13:42.300> we<00:13:42.660> can<00:13:42.809> say<00:13:42.990> okay<00:13:43.439> these 00:13:43.759 --> 00:13:43.769 align:start position:0% or 4096 and we can say okay these 00:13:43.769 --> 00:13:45.859 align:start position:0% or 4096 and we can say okay these batches<00:13:44.189> are<00:13:44.279> gonna<00:13:44.429> proceed<00:13:44.879> in<00:13:45.119> cycles<00:13:45.660> of 00:13:45.859 --> 00:13:45.869 align:start position:0% batches are gonna proceed in cycles of 00:13:45.869 --> 00:13:50.269 align:start position:0% batches are gonna proceed in cycles of 16<00:13:46.679> or<00:13:46.709> 32<00:13:47.339> or<00:13:47.579> 256<00:13:48.389> and<00:13:48.689> a<00:13:49.319> node<00:13:49.679> whose<00:13:49.980> ID 00:13:50.269 --> 00:13:50.279 align:start position:0% 16 or 32 or 256 and a node whose ID 00:13:50.279 --> 00:13:52.790 align:start position:0% 16 or 32 or 256 and a node whose ID starts<00:13:50.819> with<00:13:50.970> 0<00:13:51.209> 0<00:13:51.449> 0<00:13:51.660> 1<00:13:51.869> is<00:13:52.110> going<00:13:52.529> to<00:13:52.589> serve 00:13:52.790 --> 00:13:52.800 align:start position:0% starts with 0 0 0 1 is going to serve 00:13:52.800 --> 00:13:58.759 align:start position:0% starts with 0 0 0 1 is going to serve every<00:13:53.420> one<00:13:54.420> out<00:13:54.720> of<00:13:54.869> 256<00:13:56.990> batches<00:13:57.990> or<00:13:58.139> the 00:13:58.759 --> 00:13:58.769 align:start position:0% every one out of 256 batches or the 00:13:58.769 --> 00:14:02.179 align:start position:0% every one out of 256 batches or the person<00:13:59.100> whose<00:13:59.249> ID<00:13:59.429> starts<00:13:59.970> with<00:14:00.350> 0<00:14:01.350> 0<00:14:01.410> 0<00:14:01.800> 4<00:14:02.069> is 00:14:02.179 --> 00:14:02.189 align:start position:0% person whose ID starts with 0 0 0 4 is 00:14:02.189 --> 00:14:04.249 align:start position:0% person whose ID starts with 0 0 0 4 is going<00:14:02.309> to<00:14:02.399> serve<00:14:02.579> every<00:14:02.850> 4th<00:14:03.300> batch<00:14:03.809> out<00:14:04.079> of 00:14:04.249 --> 00:14:04.259 align:start position:0% going to serve every 4th batch out of 00:14:04.259 --> 00:14:09.049 align:start position:0% going to serve every 4th batch out of every<00:14:04.499> group<00:14:05.069> of<00:14:05.279> 256<00:14:05.939> batches<00:14:06.509> so<00:14:07.670> the<00:14:08.670> amount 00:14:09.049 --> 00:14:09.059 align:start position:0% every group of 256 batches so the amount 00:14:09.059 --> 00:14:11.530 align:start position:0% every group of 256 batches so the amount of<00:14:09.269> space<00:14:09.569> we<00:14:09.809> can<00:14:09.959> cut<00:14:10.139> down<00:14:10.379> is<00:14:10.619> really 00:14:11.530 --> 00:14:11.540 align:start position:0% of space we can cut down is really 00:14:11.540 --> 00:14:15.019 align:start position:0% of space we can cut down is really determined<00:14:12.540> by<00:14:12.660> how<00:14:13.019> many<00:14:13.249> peers<00:14:14.249> the<00:14:14.550> average 00:14:15.019 --> 00:14:15.029 align:start position:0% determined by how many peers the average 00:14:15.029 --> 00:14:16.780 align:start position:0% determined by how many peers the average node<00:14:15.209> is<00:14:15.360> likely<00:14:15.540> to<00:14:15.749> have<00:14:15.899> so<00:14:16.199> if<00:14:16.319> we<00:14:16.470> have 00:14:16.780 --> 00:14:16.790 align:start position:0% node is likely to have so if we have 00:14:16.790 --> 00:14:19.189 align:start position:0% node is likely to have so if we have right<00:14:17.790> now<00:14:17.939> it's<00:14:18.209> not<00:14:18.329> really<00:14:18.389> reasonable<00:14:19.079> to 00:14:19.189 --> 00:14:19.199 align:start position:0% right now it's not really reasonable to 00:14:19.199 --> 00:14:20.900 align:start position:0% right now it's not really reasonable to assume<00:14:19.319> that<00:14:19.499> every<00:14:19.980> node<00:14:20.160> is<00:14:20.370> going<00:14:20.670> to<00:14:20.790> be 00:14:20.900 --> 00:14:20.910 align:start position:0% assume that every node is going to be 00:14:20.910 --> 00:14:25.160 align:start position:0% assume that every node is going to be able<00:14:21.089> to<00:14:21.449> connect<00:14:21.809> to<00:14:22.079> 256<00:14:22.980> nodes<00:14:23.399> but<00:14:24.120> 16<00:14:25.019> or 00:14:25.160 --> 00:14:25.170 align:start position:0% able to connect to 256 nodes but 16 or 00:14:25.170 --> 00:14:27.470 align:start position:0% able to connect to 256 nodes but 16 or 32<00:14:25.620> is<00:14:25.800> fairly<00:14:26.160> reasonable<00:14:26.670> and<00:14:26.850> that<00:14:27.269> means 00:14:27.470 --> 00:14:27.480 align:start position:0% 32 is fairly reasonable and that means 00:14:27.480 --> 00:14:30.259 align:start position:0% 32 is fairly reasonable and that means that<00:14:27.660> you<00:14:27.749> can<00:14:27.990> always<00:14:28.889> find<00:14:29.490> a<00:14:29.699> peer<00:14:29.999> who's 00:14:30.259 --> 00:14:30.269 align:start position:0% that you can always find a peer who's 00:14:30.269 --> 00:14:31.970 align:start position:0% that you can always find a peer who's going<00:14:30.540> to<00:14:30.749> be<00:14:30.870> able<00:14:30.990> to<00:14:31.230> serve<00:14:31.470> you<00:14:31.499> the<00:14:31.800> next 00:14:31.970 --> 00:14:31.980 align:start position:0% going to be able to serve you the next 00:14:31.980 --> 00:14:35.840 align:start position:0% going to be able to serve you the next 2048<00:14:32.910> or<00:14:33.410> 4096<00:14:34.410> blocks<00:14:34.860> but<00:14:35.279> those<00:14:35.459> peers 00:14:35.840 --> 00:14:35.850 align:start position:0% 2048 or 4096 blocks but those peers 00:14:35.850 --> 00:14:38.720 align:start position:0% 2048 or 4096 blocks but those peers themselves<00:14:36.480> have<00:14:36.779> cut<00:14:36.990> down<00:14:37.019> their<00:14:37.730> storage 00:14:38.720 --> 00:14:38.730 align:start position:0% themselves have cut down their storage 00:14:38.730 --> 00:14:40.639 align:start position:0% themselves have cut down their storage requirement<00:14:39.420> by<00:14:39.540> quite<00:14:39.959> a<00:14:39.990> large<00:14:40.170> amount<00:14:40.319> so 00:14:40.639 --> 00:14:40.649 align:start position:0% requirement by quite a large amount so 00:14:40.649 --> 00:14:41.840 align:start position:0% requirement by quite a large amount so I'm<00:14:40.829> actually<00:14:41.040> really<00:14:41.309> interested<00:14:41.730> to<00:14:41.759> hear 00:14:41.840 --> 00:14:41.850 align:start position:0% I'm actually really interested to hear 00:14:41.850 --> 00:14:43.249 align:start position:0% I'm actually really interested to hear what<00:14:42.089> you<00:14:42.149> guys<00:14:42.209> think<00:14:42.480> about<00:14:42.629> this<00:14:42.870> proposal 00:14:43.249 --> 00:14:43.259 align:start position:0% what you guys think about this proposal 00:14:43.259 --> 00:14:45.739 align:start position:0% what you guys think about this proposal please<00:14:43.620> find<00:14:44.399> me<00:14:44.519> after<00:14:44.850> I<00:14:45.089> think<00:14:45.240> it's<00:14:45.569> a 00:14:45.739 --> 00:14:45.749 align:start position:0% please find me after I think it's a 00:14:45.749 --> 00:14:48.889 align:start position:0% please find me after I think it's a pretty<00:14:45.959> good<00:14:46.050> idea<00:14:47.059> so<00:14:48.059> another<00:14:48.600> thing<00:14:48.660> that 00:14:48.889 --> 00:14:48.899 align:start position:0% pretty good idea so another thing that 00:14:48.899 --> 00:14:52.910 align:start position:0% pretty good idea so another thing that we<00:14:49.050> can<00:14:49.290> do<00:14:49.439> on<00:14:50.749> light<00:14:51.749> nodes<00:14:52.049> to<00:14:52.350> get<00:14:52.589> up<00:14:52.740> to 00:14:52.910 --> 00:14:52.920 align:start position:0% we can do on light nodes to get up to 00:14:52.920 --> 00:14:55.819 align:start position:0% we can do on light nodes to get up to speed<00:14:53.040> really<00:14:53.399> quickly<00:14:53.790> is<00:14:53.939> warp<00:14:54.329> sync<00:14:54.629> so<00:14:55.170> the 00:14:55.819 --> 00:14:55.829 align:start position:0% speed really quickly is warp sync so the 00:14:55.829 --> 00:14:57.410 align:start position:0% speed really quickly is warp sync so the way<00:14:55.980> it<00:14:56.100> works<00:14:56.279> right<00:14:56.399> now<00:14:56.519> is<00:14:56.910> that<00:14:57.089> you<00:14:57.209> have 00:14:57.410 --> 00:14:57.420 align:start position:0% way it works right now is that you have 00:14:57.420 --> 00:14:59.720 align:start position:0% way it works right now is that you have to<00:14:57.689> synchronize<00:14:58.529> the<00:14:58.829> whole<00:14:59.069> blockchain 00:14:59.720 --> 00:14:59.730 align:start position:0% to synchronize the whole blockchain 00:14:59.730 --> 00:15:02.449 align:start position:0% to synchronize the whole blockchain essentially<00:15:00.449> you<00:15:00.839> have<00:15:00.959> to<00:15:01.110> go<00:15:01.259> from<00:15:01.860> header<00:15:02.069> 0 00:15:02.449 --> 00:15:02.459 align:start position:0% essentially you have to go from header 0 00:15:02.459 --> 00:15:04.129 align:start position:0% essentially you have to go from header 0 from<00:15:02.879> the<00:15:02.999> Genesis<00:15:03.480> and<00:15:03.509> walk<00:15:03.839> the<00:15:03.990> whole 00:15:04.129 --> 00:15:04.139 align:start position:0% from the Genesis and walk the whole 00:15:04.139 --> 00:15:05.720 align:start position:0% from the Genesis and walk the whole chain<00:15:04.439> all<00:15:04.799> the<00:15:05.069> way<00:15:05.160> to<00:15:05.220> the<00:15:05.429> head<00:15:05.519> of<00:15:05.670> the 00:15:05.720 --> 00:15:05.730 align:start position:0% chain all the way to the head of the 00:15:05.730 --> 00:15:11.269 align:start position:0% chain all the way to the head of the chain<00:15:05.939> but<00:15:06.899> in<00:15:07.139> fact<00:15:09.379> most<00:15:10.379> of<00:15:10.619> the<00:15:10.709> time<00:15:10.860> users 00:15:11.269 --> 00:15:11.279 align:start position:0% chain but in fact most of the time users 00:15:11.279 --> 00:15:13.039 align:start position:0% chain but in fact most of the time users don't<00:15:11.429> care<00:15:11.699> about<00:15:11.850> that<00:15:12.149> very<00:15:12.299> ancient<00:15:12.600> data 00:15:13.039 --> 00:15:13.049 align:start position:0% don't care about that very ancient data 00:15:13.049 --> 00:15:14.629 align:start position:0% don't care about that very ancient data so<00:15:13.319> we<00:15:13.410> can<00:15:13.529> introduce<00:15:13.949> something<00:15:14.160> like<00:15:14.399> warp 00:15:14.629 --> 00:15:14.639 align:start position:0% so we can introduce something like warp 00:15:14.639 --> 00:15:18.110 align:start position:0% so we can introduce something like warp sync<00:15:14.939> to<00:15:15.360> try<00:15:15.629> and<00:15:15.990> get<00:15:16.709> users<00:15:17.429> caught<00:15:17.730> up<00:15:17.939> to 00:15:18.110 --> 00:15:18.120 align:start position:0% sync to try and get users caught up to 00:15:18.120 --> 00:15:20.340 align:start position:0% sync to try and get users caught up to the<00:15:18.209> head<00:15:18.389> of<00:15:18.540> the<00:15:18.629> chain<00:15:18.839> quickly 00:15:20.340 --> 00:15:20.350 align:start position:0% the head of the chain quickly 00:15:20.350 --> 00:15:23.509 align:start position:0% the head of the chain quickly and<00:15:20.499> in<00:15:21.429> the<00:15:21.879> current<00:15:22.299> formulation<00:15:22.749> of 00:15:23.509 --> 00:15:23.519 align:start position:0% and in the current formulation of 00:15:23.519 --> 00:15:25.979 align:start position:0% and in the current formulation of aetherium<00:15:24.519> you<00:15:25.359> have<00:15:25.509> this<00:15:25.720> sort<00:15:25.959> of 00:15:25.979 --> 00:15:25.989 align:start position:0% aetherium you have this sort of 00:15:25.989 --> 00:15:28.289 align:start position:0% aetherium you have this sort of thin-client<00:15:26.589> security<00:15:27.369> level<00:15:27.669> as<00:15:27.819> soon<00:15:28.149> as 00:15:28.289 --> 00:15:28.299 align:start position:0% thin-client security level as soon as 00:15:28.299 --> 00:15:29.639 align:start position:0% thin-client security level as soon as you've<00:15:28.449> warp<00:15:28.629> synched<00:15:28.929> but<00:15:29.199> then<00:15:29.350> when<00:15:29.529> you 00:15:29.639 --> 00:15:29.649 align:start position:0% you've warp synched but then when you 00:15:29.649 --> 00:15:31.470 align:start position:0% you've warp synched but then when you download<00:15:30.129> the<00:15:30.279> ancient<00:15:30.639> block<00:15:30.850> headers<00:15:31.179> later 00:15:31.470 --> 00:15:31.480 align:start position:0% download the ancient block headers later 00:15:31.480 --> 00:15:34.859 align:start position:0% download the ancient block headers later you<00:15:32.470> can<00:15:32.739> jump<00:15:33.730> up<00:15:33.850> to<00:15:34.089> like<00:15:34.209> a<00:15:34.239> regular<00:15:34.720> light 00:15:34.859 --> 00:15:34.869 align:start position:0% you can jump up to like a regular light 00:15:34.869 --> 00:15:36.179 align:start position:0% you can jump up to like a regular light client<00:15:35.230> level<00:15:35.439> of<00:15:35.529> security<00:15:35.769> so<00:15:36.009> you<00:15:36.069> have 00:15:36.179 --> 00:15:36.189 align:start position:0% client level of security so you have 00:15:36.189 --> 00:15:37.979 align:start position:0% client level of security so you have exactly<00:15:36.519> the<00:15:36.669> same<00:15:36.699> security<00:15:37.179> proposition<00:15:37.839> as 00:15:37.979 --> 00:15:37.989 align:start position:0% exactly the same security proposition as 00:15:37.989 --> 00:15:41.849 align:start position:0% exactly the same security proposition as if<00:15:38.529> you<00:15:38.799> had<00:15:40.230> synced<00:15:41.230> directly<00:15:41.619> from<00:15:41.709> the 00:15:41.849 --> 00:15:41.859 align:start position:0% if you had synced directly from the 00:15:41.859 --> 00:15:43.889 align:start position:0% if you had synced directly from the Genesis<00:15:42.249> but<00:15:42.519> in<00:15:42.970> future<00:15:43.419> versions<00:15:43.569> of 00:15:43.889 --> 00:15:43.899 align:start position:0% Genesis but in future versions of 00:15:43.899 --> 00:15:47.309 align:start position:0% Genesis but in future versions of aetherium<00:15:44.319> most<00:15:44.799> specifically<00:15:45.249> IP<00:15:45.669> 96<00:15:46.389> or<00:15:46.629> in 00:15:47.309 --> 00:15:47.319 align:start position:0% aetherium most specifically IP 96 or in 00:15:47.319 --> 00:15:49.829 align:start position:0% aetherium most specifically IP 96 or in proof<00:15:48.069> of<00:15:48.189> steak<00:15:48.489> that<00:15:48.790> finalizes<00:15:49.569> blocks 00:15:49.829 --> 00:15:49.839 align:start position:0% proof of steak that finalizes blocks 00:15:49.839 --> 00:15:52.710 align:start position:0% proof of steak that finalizes blocks economically<00:15:50.739> you<00:15:51.399> can<00:15:51.639> jump<00:15:52.059> directly<00:15:52.269> to 00:15:52.710 --> 00:15:52.720 align:start position:0% economically you can jump directly to 00:15:52.720 --> 00:15:54.599 align:start position:0% economically you can jump directly to the<00:15:52.899> head<00:15:53.019> of<00:15:53.049> the<00:15:53.169> chain<00:15:53.470> basically<00:15:53.739> without 00:15:54.599 --> 00:15:54.609 align:start position:0% the head of the chain basically without 00:15:54.609 --> 00:15:59.249 align:start position:0% the head of the chain basically without sacrificing<00:15:55.389> security<00:15:55.959> and<00:15:58.079> ancient<00:15:59.079> block 00:15:59.249 --> 00:15:59.259 align:start position:0% sacrificing security and ancient block 00:15:59.259 --> 00:16:01.019 align:start position:0% sacrificing security and ancient block download<00:15:59.709> might<00:15:59.889> still<00:16:00.189> be<00:16:00.339> useful<00:16:00.549> in<00:16:00.910> that 00:16:01.019 --> 00:16:01.029 align:start position:0% download might still be useful in that 00:16:01.029 --> 00:16:03.509 align:start position:0% download might still be useful in that case<00:16:01.299> if<00:16:01.540> you<00:16:01.569> want<00:16:01.779> to<00:16:01.869> see<00:16:02.109> what<00:16:02.799> the<00:16:03.220> state 00:16:03.509 --> 00:16:03.519 align:start position:0% case if you want to see what the state 00:16:03.519 --> 00:16:06.179 align:start position:0% case if you want to see what the state of<00:16:03.549> a<00:16:03.759> contract<00:16:04.209> was<00:16:04.419> months<00:16:04.839> ago<00:16:05.049> but<00:16:06.040> that 00:16:06.179 --> 00:16:06.189 align:start position:0% of a contract was months ago but that 00:16:06.189 --> 00:16:08.009 align:start position:0% of a contract was months ago but that can<00:16:06.339> be<00:16:06.369> done<00:16:06.609> say<00:16:06.879> on<00:16:07.059> Wi-Fi<00:16:07.540> on<00:16:07.779> a<00:16:07.809> mobile 00:16:08.009 --> 00:16:08.019 align:start position:0% can be done say on Wi-Fi on a mobile 00:16:08.019 --> 00:16:10.739 align:start position:0% can be done say on Wi-Fi on a mobile device<00:16:08.429> where<00:16:09.429> you<00:16:09.519> warp<00:16:09.790> sync<00:16:10.089> when<00:16:10.299> you 00:16:10.739 --> 00:16:10.749 align:start position:0% device where you warp sync when you 00:16:10.749 --> 00:16:12.179 align:start position:0% device where you warp sync when you first<00:16:10.989> start<00:16:11.199> the<00:16:11.290> app<00:16:11.410> regardless<00:16:11.949> of<00:16:12.069> your 00:16:12.179 --> 00:16:12.189 align:start position:0% first start the app regardless of your 00:16:12.189 --> 00:16:13.379 align:start position:0% first start the app regardless of your connection<00:16:12.579> but<00:16:12.790> you<00:16:12.879> don't<00:16:13.029> want<00:16:13.179> to<00:16:13.239> waste 00:16:13.379 --> 00:16:13.389 align:start position:0% connection but you don't want to waste 00:16:13.389 --> 00:16:15.869 align:start position:0% connection but you don't want to waste the<00:16:13.480> bandwidth<00:16:13.989> over<00:16:14.230> data<00:16:14.889> to<00:16:15.339> download<00:16:15.489> all 00:16:15.869 --> 00:16:15.879 align:start position:0% the bandwidth over data to download all 00:16:15.879 --> 00:16:18.749 align:start position:0% the bandwidth over data to download all those<00:16:16.059> blocks<00:16:16.589> all<00:16:17.589> those<00:16:17.769> ancient<00:16:17.980> blocks<00:16:18.399> so 00:16:18.749 --> 00:16:18.759 align:start position:0% those blocks all those ancient blocks so 00:16:18.759 --> 00:16:20.609 align:start position:0% those blocks all those ancient blocks so you<00:16:18.819> wait<00:16:19.029> until<00:16:19.179> you're<00:16:19.389> on<00:16:19.419> Wi-Fi<00:16:19.869> to<00:16:19.929> finish 00:16:20.609 --> 00:16:20.619 align:start position:0% you wait until you're on Wi-Fi to finish 00:16:20.619 --> 00:16:23.159 align:start position:0% you wait until you're on Wi-Fi to finish that<00:16:20.799> process<00:16:21.040> and<00:16:21.399> that's<00:16:21.489> pretty<00:16:21.759> a<00:16:22.449> pretty 00:16:23.159 --> 00:16:23.169 align:start position:0% that process and that's pretty a pretty 00:16:23.169 --> 00:16:25.859 align:start position:0% that process and that's pretty a pretty useful<00:16:23.350> way<00:16:23.619> to<00:16:23.679> do<00:16:23.859> things<00:16:24.329> so<00:16:25.329> I'd<00:16:25.660> like<00:16:25.809> to 00:16:25.859 --> 00:16:25.869 align:start position:0% useful way to do things so I'd like to 00:16:25.869 --> 00:16:29.609 align:start position:0% useful way to do things so I'd like to talk<00:16:26.109> a<00:16:26.169> bit<00:16:26.589> about<00:16:26.709> some<00:16:27.089> RPC<00:16:28.089> pitfalls<00:16:28.720> so<00:16:29.109> if 00:16:29.609 --> 00:16:29.619 align:start position:0% talk a bit about some RPC pitfalls so if 00:16:29.619 --> 00:16:31.679 align:start position:0% talk a bit about some RPC pitfalls so if you're<00:16:29.889> developing<00:16:30.039> on<00:16:30.669> a<00:16:30.699> light<00:16:30.939> client<00:16:31.389> what 00:16:31.679 --> 00:16:31.689 align:start position:0% you're developing on a light client what 00:16:31.689 --> 00:16:33.689 align:start position:0% you're developing on a light client what works<00:16:32.139> and<00:16:32.410> what<00:16:32.589> doesn't<00:16:32.829> because<00:16:33.429> we<00:16:33.549> have 00:16:33.689 --> 00:16:33.699 align:start position:0% works and what doesn't because we have 00:16:33.699 --> 00:16:36.479 align:start position:0% works and what doesn't because we have all<00:16:33.910> these<00:16:34.169> RPC<00:16:35.169> requests<00:16:35.649> that<00:16:35.769> seem<00:16:35.980> fairly 00:16:36.479 --> 00:16:36.489 align:start position:0% all these RPC requests that seem fairly 00:16:36.489 --> 00:16:38.309 align:start position:0% all these RPC requests that seem fairly simple<00:16:36.819> ways<00:16:37.149> to<00:16:37.179> gather<00:16:37.600> data<00:16:37.929> about<00:16:38.199> the 00:16:38.309 --> 00:16:38.319 align:start position:0% simple ways to gather data about the 00:16:38.319 --> 00:16:41.429 align:start position:0% simple ways to gather data about the blockchain<00:16:38.529> from<00:16:39.009> the<00:16:39.129> node<00:16:39.629> but<00:16:40.629> some<00:16:41.319> of 00:16:41.429 --> 00:16:41.439 align:start position:0% blockchain from the node but some of 00:16:41.439 --> 00:16:42.869 align:start position:0% blockchain from the node but some of them<00:16:41.589> under<00:16:41.709> the<00:16:41.919> hood<00:16:42.039> might<00:16:42.249> be<00:16:42.369> doing<00:16:42.549> a<00:16:42.639> lot 00:16:42.869 --> 00:16:42.879 align:start position:0% them under the hood might be doing a lot 00:16:42.879 --> 00:16:45.119 align:start position:0% them under the hood might be doing a lot of<00:16:42.939> work<00:16:43.269> even<00:16:43.509> on<00:16:43.809> full<00:16:44.109> nodes<00:16:44.319> and<00:16:44.619> on<00:16:44.889> light 00:16:45.119 --> 00:16:45.129 align:start position:0% of work even on full nodes and on light 00:16:45.129 --> 00:16:46.559 align:start position:0% of work even on full nodes and on light nodes<00:16:45.429> it's<00:16:45.730> important<00:16:46.119> to<00:16:46.209> know<00:16:46.329> actually 00:16:46.559 --> 00:16:46.569 align:start position:0% nodes it's important to know actually 00:16:46.569 --> 00:16:47.970 align:start position:0% nodes it's important to know actually which<00:16:46.959> requests<00:16:47.379> are<00:16:47.439> going<00:16:47.499> to<00:16:47.619> be<00:16:47.709> the<00:16:47.799> most 00:16:47.970 --> 00:16:47.980 align:start position:0% which requests are going to be the most 00:16:47.980 --> 00:16:51.929 align:start position:0% which requests are going to be the most expensive<00:16:48.189> so<00:16:49.079> first<00:16:50.079> of<00:16:50.259> all<00:16:50.730> getting<00:16:51.730> logs 00:16:51.929 --> 00:16:51.939 align:start position:0% expensive so first of all getting logs 00:16:51.939 --> 00:16:54.840 align:start position:0% expensive so first of all getting logs can<00:16:52.359> be<00:16:52.480> very<00:16:52.809> expensive<00:16:53.109> especially<00:16:54.100> if 00:16:54.840 --> 00:16:54.850 align:start position:0% can be very expensive especially if 00:16:54.850 --> 00:16:56.879 align:start position:0% can be very expensive especially if you're<00:16:55.089> trying<00:16:55.359> to<00:16:55.449> get<00:16:55.689> all<00:16:55.839> the<00:16:56.199> logs<00:16:56.439> in<00:16:56.799> the 00:16:56.879 --> 00:16:56.889 align:start position:0% you're trying to get all the logs in the 00:16:56.889 --> 00:16:59.340 align:start position:0% you're trying to get all the logs in the history<00:16:57.220> of<00:16:57.279> everything<00:16:57.609> that<00:16:58.509> means<00:16:58.779> that<00:16:59.109> if 00:16:59.340 --> 00:16:59.350 align:start position:0% history of everything that means that if 00:16:59.350 --> 00:17:00.720 align:start position:0% history of everything that means that if you're<00:16:59.589> on<00:16:59.739> a<00:16:59.769> light<00:16:59.980> client<00:17:00.369> which<00:17:00.489> isn't 00:17:00.720 --> 00:17:00.730 align:start position:0% you're on a light client which isn't 00:17:00.730 --> 00:17:03.389 align:start position:0% you're on a light client which isn't storing<00:17:01.239> all<00:17:01.389> the<00:17:01.539> headers<00:17:01.919> you<00:17:02.919> need<00:17:03.100> to<00:17:03.249> then 00:17:03.389 --> 00:17:03.399 align:start position:0% storing all the headers you need to then 00:17:03.399 --> 00:17:05.399 align:start position:0% storing all the headers you need to then download<00:17:03.999> all<00:17:04.179> these<00:17:04.329> headers<00:17:04.689> then<00:17:05.139> check 00:17:05.399 --> 00:17:05.409 align:start position:0% download all these headers then check 00:17:05.409 --> 00:17:06.899 align:start position:0% download all these headers then check bloom<00:17:05.709> filters<00:17:06.159> which<00:17:06.370> may<00:17:06.519> have<00:17:06.669> false 00:17:06.899 --> 00:17:06.909 align:start position:0% bloom filters which may have false 00:17:06.909 --> 00:17:11.909 align:start position:0% bloom filters which may have false positives<00:17:07.449> and<00:17:07.659> then<00:17:09.839> finally<00:17:10.839> get<00:17:11.500> receipts 00:17:11.909 --> 00:17:11.919 align:start position:0% positives and then finally get receipts 00:17:11.919 --> 00:17:14.909 align:start position:0% positives and then finally get receipts and<00:17:12.730> and<00:17:13.360> scan<00:17:13.809> for<00:17:13.839> logs<00:17:14.169> so<00:17:14.319> that's<00:17:14.470> a<00:17:14.529> lot<00:17:14.740> of 00:17:14.909 --> 00:17:14.919 align:start position:0% and and scan for logs so that's a lot of 00:17:14.919 --> 00:17:16.350 align:start position:0% and and scan for logs so that's a lot of bandwidth<00:17:15.309> whereas<00:17:15.970> if<00:17:16.089> you're<00:17:16.240> just 00:17:16.350 --> 00:17:16.360 align:start position:0% bandwidth whereas if you're just 00:17:16.360 --> 00:17:17.789 align:start position:0% bandwidth whereas if you're just watching<00:17:16.600> the<00:17:16.929> head<00:17:17.079> of<00:17:17.199> the<00:17:17.289> chain<00:17:17.470> for<00:17:17.679> log 00:17:17.789 --> 00:17:17.799 align:start position:0% watching the head of the chain for log 00:17:17.799 --> 00:17:20.220 align:start position:0% watching the head of the chain for log events<00:17:18.130> it's<00:17:18.279> actually<00:17:18.669> fairly<00:17:19.230> fairly 00:17:20.220 --> 00:17:20.230 align:start position:0% events it's actually fairly fairly 00:17:20.230 --> 00:17:22.590 align:start position:0% events it's actually fairly fairly performant<00:17:21.159> but<00:17:21.880> if<00:17:22.089> you're<00:17:22.209> trying<00:17:22.449> to<00:17:22.480> get 00:17:22.590 --> 00:17:22.600 align:start position:0% performant but if you're trying to get 00:17:22.600 --> 00:17:24.600 align:start position:0% performant but if you're trying to get historical<00:17:23.380> logs<00:17:23.589> it<00:17:23.919> can<00:17:24.069> be<00:17:24.189> very<00:17:24.370> difficult 00:17:24.600 --> 00:17:24.610 align:start position:0% historical logs it can be very difficult 00:17:24.610 --> 00:17:26.850 align:start position:0% historical logs it can be very difficult the<00:17:25.029> reason<00:17:25.299> is<00:17:25.419> they<00:17:25.569> aren't<00:17:25.839> embedded<00:17:26.500> into 00:17:26.850 --> 00:17:26.860 align:start position:0% the reason is they aren't embedded into 00:17:26.860 --> 00:17:28.710 align:start position:0% the reason is they aren't embedded into that<00:17:27.010> Merkle<00:17:27.429> tree<00:17:27.639> of<00:17:27.760> the<00:17:27.909> state<00:17:28.149> it's<00:17:28.539> why 00:17:28.710 --> 00:17:28.720 align:start position:0% that Merkle tree of the state it's why 00:17:28.720 --> 00:17:30.299 align:start position:0% that Merkle tree of the state it's why they're<00:17:28.899> cheaper<00:17:29.379> but<00:17:29.799> it's<00:17:29.950> also<00:17:30.070> why 00:17:30.299 --> 00:17:30.309 align:start position:0% they're cheaper but it's also why 00:17:30.309 --> 00:17:31.640 align:start position:0% they're cheaper but it's also why they're<00:17:30.490> more<00:17:30.669> expensive<00:17:31.000> to 00:17:31.640 --> 00:17:31.650 align:start position:0% they're more expensive to 00:17:31.650 --> 00:17:35.450 align:start position:0% they're more expensive to for<00:17:32.130> more<00:17:32.250> ancient<00:17:32.460> data<00:17:33.059> so<00:17:33.830> there<00:17:34.830> are<00:17:35.010> a<00:17:35.039> few 00:17:35.450 --> 00:17:35.460 align:start position:0% for more ancient data so there are a few 00:17:35.460 --> 00:17:36.830 align:start position:0% for more ancient data so there are a few approaches<00:17:36.000> that<00:17:36.120> you<00:17:36.210> can<00:17:36.240> have<00:17:36.570> so<00:17:36.779> you 00:17:36.830 --> 00:17:36.840 align:start position:0% approaches that you can have so you 00:17:36.840 --> 00:17:38.180 align:start position:0% approaches that you can have so you could<00:17:36.990> have<00:17:37.200> you<00:17:37.529> could<00:17:37.650> have<00:17:37.710> your<00:17:37.860> peers 00:17:38.180 --> 00:17:38.190 align:start position:0% could have you could have your peers 00:17:38.190 --> 00:17:41.600 align:start position:0% could have you could have your peers search<00:17:38.520> for<00:17:38.850> you<00:17:39.029> but<00:17:39.799> again<00:17:40.799> you<00:17:41.429> don't 00:17:41.600 --> 00:17:41.610 align:start position:0% search for you but again you don't 00:17:41.610 --> 00:17:43.399 align:start position:0% search for you but again you don't necessarily<00:17:41.880> know<00:17:42.570> that<00:17:42.600> they've<00:17:42.990> given<00:17:43.320> you 00:17:43.399 --> 00:17:43.409 align:start position:0% necessarily know that they've given you 00:17:43.409 --> 00:17:45.740 align:start position:0% necessarily know that they've given you all<00:17:43.650> the<00:17:43.950> data<00:17:44.070> they<00:17:44.340> were<00:17:44.400> supposed<00:17:44.760> to 00:17:45.740 --> 00:17:45.750 align:start position:0% all the data they were supposed to 00:17:45.750 --> 00:17:48.590 align:start position:0% all the data they were supposed to you<00:17:46.020> can<00:17:46.230> search<00:17:46.640> locally<00:17:47.640> which<00:17:48.299> is<00:17:48.450> what<00:17:48.570> I 00:17:48.590 --> 00:17:48.600 align:start position:0% you can search locally which is what I 00:17:48.600 --> 00:17:50.480 align:start position:0% you can search locally which is what I just<00:17:48.690> described<00:17:49.289> which<00:17:49.500> is<00:17:49.650> to<00:17:49.860> actually<00:17:50.190> go 00:17:50.480 --> 00:17:50.490 align:start position:0% just described which is to actually go 00:17:50.490 --> 00:17:51.860 align:start position:0% just described which is to actually go through<00:17:50.669> this<00:17:50.820> long<00:17:51.059> and<00:17:51.240> involved<00:17:51.480> process 00:17:51.860 --> 00:17:51.870 align:start position:0% through this long and involved process 00:17:51.870 --> 00:17:54.289 align:start position:0% through this long and involved process of<00:17:52.200> downloading<00:17:52.380> everything<00:17:53.070> or<00:17:53.909> you<00:17:54.090> can 00:17:54.289 --> 00:17:54.299 align:start position:0% of downloading everything or you can 00:17:54.299 --> 00:17:56.000 align:start position:0% of downloading everything or you can keep<00:17:54.539> some<00:17:54.809> metadata<00:17:55.200> so<00:17:55.559> that's<00:17:55.710> also 00:17:56.000 --> 00:17:56.010 align:start position:0% keep some metadata so that's also 00:17:56.010 --> 00:17:57.680 align:start position:0% keep some metadata so that's also another<00:17:56.429> approach<00:17:56.610> where<00:17:57.120> the<00:17:57.240> light<00:17:57.360> clients 00:17:57.680 --> 00:17:57.690 align:start position:0% another approach where the light clients 00:17:57.690 --> 00:17:59.600 align:start position:0% another approach where the light clients keep<00:17:57.840> some<00:17:58.080> metadata<00:17:58.950> that<00:17:59.190> helps<00:17:59.460> them 00:17:59.600 --> 00:17:59.610 align:start position:0% keep some metadata that helps them 00:17:59.610 --> 00:18:01.580 align:start position:0% keep some metadata that helps them search<00:17:59.820> but<00:18:00.090> again<00:18:00.299> it<00:18:00.480> raises<00:18:01.140> that<00:18:01.289> storage 00:18:01.580 --> 00:18:01.590 align:start position:0% search but again it raises that storage 00:18:01.590 --> 00:18:03.110 align:start position:0% search but again it raises that storage requirement<00:18:02.159> significantly<00:18:02.789> and<00:18:02.970> there's 00:18:03.110 --> 00:18:03.120 align:start position:0% requirement significantly and there's 00:18:03.120 --> 00:18:05.720 align:start position:0% requirement significantly and there's not<00:18:03.299> really<00:18:03.870> a<00:18:04.080> good<00:18:04.590> way<00:18:04.830> to<00:18:04.890> bring<00:18:05.250> that<00:18:05.460> down 00:18:05.720 --> 00:18:05.730 align:start position:0% not really a good way to bring that down 00:18:05.730 --> 00:18:07.549 align:start position:0% not really a good way to bring that down and<00:18:05.970> if<00:18:06.419> we're<00:18:06.539> trying<00:18:06.690> to<00:18:06.840> target<00:18:07.049> say<00:18:07.380> the 00:18:07.549 --> 00:18:07.559 align:start position:0% and if we're trying to target say the 00:18:07.559 --> 00:18:09.500 align:start position:0% and if we're trying to target say the mobile<00:18:07.950> space<00:18:08.220> where<00:18:08.520> users<00:18:08.820> don't<00:18:09.000> have<00:18:09.120> that 00:18:09.500 --> 00:18:09.510 align:start position:0% mobile space where users don't have that 00:18:09.510 --> 00:18:11.630 align:start position:0% mobile space where users don't have that much<00:18:09.779> storage<00:18:10.200> it<00:18:10.860> may<00:18:11.070> not<00:18:11.309> really<00:18:11.520> be 00:18:11.630 --> 00:18:11.640 align:start position:0% much storage it may not really be 00:18:11.640 --> 00:18:14.930 align:start position:0% much storage it may not really be feasible<00:18:12.480> whereas<00:18:12.840> on<00:18:13.110> the<00:18:13.260> laptop<00:18:14.039> case<00:18:14.309> you 00:18:14.930 --> 00:18:14.940 align:start position:0% feasible whereas on the laptop case you 00:18:14.940 --> 00:18:16.180 align:start position:0% feasible whereas on the laptop case you do<00:18:15.120> have<00:18:15.270> that<00:18:15.390> storage<00:18:15.750> and<00:18:15.990> may<00:18:16.080> be 00:18:16.180 --> 00:18:16.190 align:start position:0% do have that storage and may be 00:18:16.190 --> 00:18:18.980 align:start position:0% do have that storage and may be searching<00:18:17.190> logs<00:18:17.399> can<00:18:17.880> be<00:18:17.909> effective<00:18:18.750> in<00:18:18.840> that 00:18:18.980 --> 00:18:18.990 align:start position:0% searching logs can be effective in that 00:18:18.990 --> 00:18:23.360 align:start position:0% searching logs can be effective in that case<00:18:19.429> another<00:18:20.429> problem<00:18:20.970> is<00:18:21.120> getting<00:18:22.070> stuff<00:18:23.070> by 00:18:23.360 --> 00:18:23.370 align:start position:0% case another problem is getting stuff by 00:18:23.370 --> 00:18:26.330 align:start position:0% case another problem is getting stuff by hash<00:18:23.640> so<00:18:24.000> for<00:18:24.539> recent<00:18:25.020> data<00:18:25.260> transactions<00:18:26.159> and 00:18:26.330 --> 00:18:26.340 align:start position:0% hash so for recent data transactions and 00:18:26.340 --> 00:18:28.220 align:start position:0% hash so for recent data transactions and receipts<00:18:26.700> you<00:18:27.149> don't<00:18:27.390> know<00:18:27.539> anything<00:18:27.899> but<00:18:28.049> the 00:18:28.220 --> 00:18:28.230 align:start position:0% receipts you don't know anything but the 00:18:28.230 --> 00:18:30.440 align:start position:0% receipts you don't know anything but the hash<00:18:28.409> if<00:18:28.890> you<00:18:29.070> just<00:18:29.309> broadcast<00:18:29.490> a<00:18:29.880> transaction 00:18:30.440 --> 00:18:30.450 align:start position:0% hash if you just broadcast a transaction 00:18:30.450 --> 00:18:32.240 align:start position:0% hash if you just broadcast a transaction because<00:18:30.809> that<00:18:31.110> transaction<00:18:31.679> may<00:18:31.860> have<00:18:32.100> not 00:18:32.240 --> 00:18:32.250 align:start position:0% because that transaction may have not 00:18:32.250 --> 00:18:36.049 align:start position:0% because that transaction may have not even<00:18:32.279> been<00:18:32.640> mined<00:18:32.909> yet<00:18:33.179> but<00:18:34.610> the<00:18:35.610> problem<00:18:35.970> is 00:18:36.049 --> 00:18:36.059 align:start position:0% even been mined yet but the problem is 00:18:36.059 --> 00:18:38.600 align:start position:0% even been mined yet but the problem is hashes<00:18:36.570> by<00:18:36.779> design<00:18:37.230> leak<00:18:37.590> no<00:18:37.890> information 00:18:38.600 --> 00:18:38.610 align:start position:0% hashes by design leak no information 00:18:38.610 --> 00:18:40.430 align:start position:0% hashes by design leak no information about<00:18:38.820> the<00:18:39.450> block<00:18:39.659> number<00:18:40.020> so<00:18:40.169> if<00:18:40.260> it's<00:18:40.380> a 00:18:40.430 --> 00:18:40.440 align:start position:0% about the block number so if it's a 00:18:40.440 --> 00:18:42.769 align:start position:0% about the block number so if it's a block<00:18:40.620> hash<00:18:40.860> you<00:18:41.070> don't<00:18:41.250> know<00:18:41.399> which<00:18:42.179> pier<00:18:42.630> to 00:18:42.769 --> 00:18:42.779 align:start position:0% block hash you don't know which pier to 00:18:42.779 --> 00:18:46.669 align:start position:0% block hash you don't know which pier to ask<00:18:42.960> for<00:18:43.799> the<00:18:44.190> the<00:18:44.220> block<00:18:44.880> whose<00:18:45.870> hash<00:18:46.140> is<00:18:46.380> that 00:18:46.669 --> 00:18:46.679 align:start position:0% ask for the the block whose hash is that 00:18:46.679 --> 00:18:48.680 align:start position:0% ask for the the block whose hash is that transaction<00:18:47.580> hashes<00:18:47.940> are<00:18:48.090> even<00:18:48.330> a<00:18:48.390> little<00:18:48.480> bit 00:18:48.680 --> 00:18:48.690 align:start position:0% transaction hashes are even a little bit 00:18:48.690 --> 00:18:51.409 align:start position:0% transaction hashes are even a little bit worse<00:18:48.929> because<00:18:49.309> you<00:18:50.309> have<00:18:50.490> to<00:18:50.669> find<00:18:50.909> out<00:18:51.090> where 00:18:51.409 --> 00:18:51.419 align:start position:0% worse because you have to find out where 00:18:51.419 --> 00:18:53.120 align:start position:0% worse because you have to find out where in<00:18:51.659> the<00:18:51.750> blockchain<00:18:51.990> that<00:18:52.409> transaction<00:18:52.980> hash 00:18:53.120 --> 00:18:53.130 align:start position:0% in the blockchain that transaction hash 00:18:53.130 --> 00:18:54.620 align:start position:0% in the blockchain that transaction hash occurred<00:18:53.520> and<00:18:53.789> there<00:18:54.179> are<00:18:54.270> multiple 00:18:54.620 --> 00:18:54.630 align:start position:0% occurred and there are multiple 00:18:54.630 --> 00:18:56.950 align:start position:0% occurred and there are multiple different<00:18:54.750> Forks<00:18:55.260> where<00:18:55.440> that<00:18:55.620> could<00:18:56.460> occur 00:18:56.950 --> 00:18:56.960 align:start position:0% different Forks where that could occur 00:18:56.960 --> 00:19:00.769 align:start position:0% different Forks where that could occur and<00:18:57.960> actually<00:18:58.500> with<00:18:58.770> one<00:18:58.799> of<00:18:59.010> the<00:18:59.100> new<00:18:59.250> IPs<00:18:59.909> we 00:19:00.769 --> 00:19:00.779 align:start position:0% and actually with one of the new IPs we 00:19:00.779 --> 00:19:02.930 align:start position:0% and actually with one of the new IPs we can<00:19:00.960> have<00:19:01.140> the<00:19:01.470> same<00:19:01.740> transaction<00:19:02.279> exact 00:19:02.930 --> 00:19:02.940 align:start position:0% can have the same transaction exact 00:19:02.940 --> 00:19:04.220 align:start position:0% can have the same transaction exact transaction<00:19:03.510> included<00:19:03.929> in<00:19:03.990> the<00:19:04.049> chain 00:19:04.220 --> 00:19:04.230 align:start position:0% transaction included in the chain 00:19:04.230 --> 00:19:06.529 align:start position:0% transaction included in the chain multiple<00:19:04.440> times<00:19:04.950> which<00:19:05.850> just<00:19:06.059> means<00:19:06.240> even 00:19:06.529 --> 00:19:06.539 align:start position:0% multiple times which just means even 00:19:06.539 --> 00:19:07.960 align:start position:0% multiple times which just means even more<00:19:06.720> work<00:19:06.870> for<00:19:07.049> the<00:19:07.140> light<00:19:07.289> client<00:19:07.620> to<00:19:07.740> check 00:19:07.960 --> 00:19:07.970 align:start position:0% more work for the light client to check 00:19:07.970 --> 00:19:11.210 align:start position:0% more work for the light client to check and<00:19:09.020> for<00:19:10.020> checking<00:19:10.350> these<00:19:10.500> transactions<00:19:11.070> and 00:19:11.210 --> 00:19:11.220 align:start position:0% and for checking these transactions and 00:19:11.220 --> 00:19:12.649 align:start position:0% and for checking these transactions and receipts<00:19:11.520> it<00:19:11.700> means<00:19:11.880> that<00:19:12.059> the<00:19:12.149> full<00:19:12.390> nodes 00:19:12.649 --> 00:19:12.659 align:start position:0% receipts it means that the full nodes 00:19:12.659 --> 00:19:14.330 align:start position:0% receipts it means that the full nodes have<00:19:13.049> to<00:19:13.230> maintain<00:19:13.590> this<00:19:13.710> fairly<00:19:14.039> expensive 00:19:14.330 --> 00:19:14.340 align:start position:0% have to maintain this fairly expensive 00:19:14.340 --> 00:19:16.760 align:start position:0% have to maintain this fairly expensive index<00:19:14.940> mapping<00:19:15.510> transaction<00:19:16.140> hashes<00:19:16.559> to 00:19:16.760 --> 00:19:16.770 align:start position:0% index mapping transaction hashes to 00:19:16.770 --> 00:19:20.090 align:start position:0% index mapping transaction hashes to their<00:19:17.490> location<00:19:18.000> in<00:19:18.149> the<00:19:18.299> blockchain<00:19:19.100> and 00:19:20.090 --> 00:19:20.100 align:start position:0% their location in the blockchain and 00:19:20.100 --> 00:19:23.299 align:start position:0% their location in the blockchain and lastly<00:19:20.669> estimating<00:19:21.419> gas<00:19:21.630> so<00:19:22.320> these<00:19:22.950> state 00:19:23.299 --> 00:19:23.309 align:start position:0% lastly estimating gas so these state 00:19:23.309 --> 00:19:25.940 align:start position:0% lastly estimating gas so these state proofs<00:19:23.549> that<00:19:23.640> I<00:19:23.760> talked<00:19:24.000> about<00:19:24.120> before<00:19:24.830> can<00:19:25.830> be 00:19:25.940 --> 00:19:25.950 align:start position:0% proofs that I talked about before can be 00:19:25.950 --> 00:19:27.590 align:start position:0% proofs that I talked about before can be used<00:19:26.220> for<00:19:26.429> estimate<00:19:26.850> gas<00:19:27.029> and<00:19:27.419> eath 00:19:27.590 --> 00:19:27.600 align:start position:0% used for estimate gas and eath 00:19:27.600 --> 00:19:29.360 align:start position:0% used for estimate gas and eath underscore<00:19:28.049> call<00:19:28.289> but<00:19:28.860> the<00:19:28.980> thing<00:19:29.130> is<00:19:29.250> with 00:19:29.360 --> 00:19:29.370 align:start position:0% underscore call but the thing is with 00:19:29.370 --> 00:19:31.610 align:start position:0% underscore call but the thing is with estimate<00:19:29.820> gas<00:19:30.029> the<00:19:30.510> typical<00:19:30.929> approach<00:19:31.140> is<00:19:31.440> to 00:19:31.610 --> 00:19:31.620 align:start position:0% estimate gas the typical approach is to 00:19:31.620 --> 00:19:33.649 align:start position:0% estimate gas the typical approach is to binary<00:19:31.860> search<00:19:32.340> to<00:19:32.610> find<00:19:32.820> out<00:19:32.940> exactly<00:19:33.390> how 00:19:33.649 --> 00:19:33.659 align:start position:0% binary search to find out exactly how 00:19:33.659 --> 00:19:35.570 align:start position:0% binary search to find out exactly how much<00:19:33.870> gas<00:19:34.169> a<00:19:34.200> transaction<00:19:34.860> will<00:19:34.950> take<00:19:34.980> so<00:19:35.520> you 00:19:35.570 --> 00:19:35.580 align:start position:0% much gas a transaction will take so you 00:19:35.580 --> 00:19:37.700 align:start position:0% much gas a transaction will take so you start<00:19:35.820> at<00:19:35.909> some<00:19:36.059> very<00:19:36.270> high<00:19:36.750> upper<00:19:37.169> bound<00:19:37.380> and 00:19:37.700 --> 00:19:37.710 align:start position:0% start at some very high upper bound and 00:19:37.710 --> 00:19:40.549 align:start position:0% start at some very high upper bound and then<00:19:38.190> you<00:19:38.490> try<00:19:38.970> at<00:19:39.179> a<00:19:39.240> lower<00:19:39.450> bound<00:19:39.720> and<00:19:39.990> then 00:19:40.549 --> 00:19:40.559 align:start position:0% then you try at a lower bound and then 00:19:40.559 --> 00:19:42.200 align:start position:0% then you try at a lower bound and then you<00:19:40.649> sort<00:19:40.830> of<00:19:40.919> narrow<00:19:41.130> and<00:19:41.460> you<00:19:41.520> zoom<00:19:41.850> in<00:19:42.090> on 00:19:42.200 --> 00:19:42.210 align:start position:0% you sort of narrow and you zoom in on 00:19:42.210 --> 00:19:44.200 align:start position:0% you sort of narrow and you zoom in on exactly<00:19:42.809> where<00:19:43.049> that<00:19:43.169> transaction 00:19:44.200 --> 00:19:44.210 align:start position:0% exactly where that transaction 00:19:44.210 --> 00:19:48.740 align:start position:0% exactly where that transaction begins<00:19:45.210> to<00:19:45.450> succeed<00:19:46.460> the<00:19:47.460> problem<00:19:47.940> is<00:19:48.210> that<00:19:48.540> in 00:19:48.740 --> 00:19:48.750 align:start position:0% begins to succeed the problem is that in 00:19:48.750 --> 00:19:51.230 align:start position:0% begins to succeed the problem is that in the<00:19:48.960> general<00:19:49.410> case<00:19:49.620> contracts<00:19:50.400> can<00:19:50.580> branch<00:19:50.940> on 00:19:51.230 --> 00:19:51.240 align:start position:0% the general case contracts can branch on 00:19:51.240 --> 00:19:54.470 align:start position:0% the general case contracts can branch on the<00:19:51.270> amount<00:19:51.570> of<00:19:51.720> gas<00:19:51.930> provided<00:19:52.410> so<00:19:53.270> that<00:19:54.270> means 00:19:54.470 --> 00:19:54.480 align:start position:0% the amount of gas provided so that means 00:19:54.480 --> 00:19:55.940 align:start position:0% the amount of gas provided so that means that<00:19:54.690> the<00:19:54.780> same<00:19:54.990> state<00:19:55.410> proof<00:19:55.620> that<00:19:55.800> you 00:19:55.940 --> 00:19:55.950 align:start position:0% that the same state proof that you 00:19:55.950 --> 00:19:59.090 align:start position:0% that the same state proof that you fetched<00:19:56.280> for<00:19:56.580> the<00:19:57.260> upper<00:19:58.260> bound<00:19:58.440> case<00:19:58.710> may<00:19:59.070> not 00:19:59.090 --> 00:19:59.100 align:start position:0% fetched for the upper bound case may not 00:19:59.100 --> 00:20:01.970 align:start position:0% fetched for the upper bound case may not be<00:19:59.430> enough<00:19:59.760> to<00:20:00.030> re-execute<00:20:00.510> on<00:20:01.470> the<00:20:01.800> lower 00:20:01.970 --> 00:20:01.980 align:start position:0% be enough to re-execute on the lower 00:20:01.980 --> 00:20:03.320 align:start position:0% be enough to re-execute on the lower bound<00:20:02.280> case<00:20:02.520> and<00:20:02.730> that<00:20:02.820> means<00:20:03.000> you<00:20:03.180> might<00:20:03.270> have 00:20:03.320 --> 00:20:03.330 align:start position:0% bound case and that means you might have 00:20:03.330 --> 00:20:05.420 align:start position:0% bound case and that means you might have to<00:20:03.510> take<00:20:03.630> more<00:20:03.930> round<00:20:04.620> trips<00:20:04.860> in<00:20:05.040> general<00:20:05.280> so 00:20:05.420 --> 00:20:05.430 align:start position:0% to take more round trips in general so 00:20:05.430 --> 00:20:08.750 align:start position:0% to take more round trips in general so this<00:20:05.910> is<00:20:06.770> something<00:20:07.770> to<00:20:07.980> be<00:20:08.100> used<00:20:08.130> fairly 00:20:08.750 --> 00:20:08.760 align:start position:0% this is something to be used fairly 00:20:08.760 --> 00:20:12.140 align:start position:0% this is something to be used fairly sparingly<00:20:09.480> only<00:20:09.950> when<00:20:10.950> really<00:20:11.220> necessary<00:20:11.850> and 00:20:12.140 --> 00:20:12.150 align:start position:0% sparingly only when really necessary and 00:20:12.150 --> 00:20:14.810 align:start position:0% sparingly only when really necessary and also<00:20:12.720> think<00:20:13.650> about<00:20:13.770> the<00:20:14.040> contracts<00:20:14.520> you<00:20:14.550> write 00:20:14.810 --> 00:20:14.820 align:start position:0% also think about the contracts you write 00:20:14.820 --> 00:20:17.450 align:start position:0% also think about the contracts you write so<00:20:15.150> that<00:20:15.360> they<00:20:15.570> don't<00:20:15.890> play<00:20:16.890> poorly<00:20:17.190> with 00:20:17.450 --> 00:20:17.460 align:start position:0% so that they don't play poorly with 00:20:17.460 --> 00:20:21.590 align:start position:0% so that they don't play poorly with light<00:20:17.640> clients<00:20:19.220> and<00:20:20.220> lastly<00:20:21.120> I'd<00:20:21.420> like<00:20:21.450> to 00:20:21.590 --> 00:20:21.600 align:start position:0% light clients and lastly I'd like to 00:20:21.600 --> 00:20:24.730 align:start position:0% light clients and lastly I'd like to take<00:20:21.960> a<00:20:22.350> little<00:20:22.920> bit<00:20:23.040> of<00:20:23.160> time<00:20:23.370> to<00:20:23.640> talk<00:20:23.820> about 00:20:24.730 --> 00:20:24.740 align:start position:0% take a little bit of time to talk about 00:20:24.740 --> 00:20:27.980 align:start position:0% take a little bit of time to talk about the<00:20:25.740> light<00:20:25.950> client<00:20:26.430> plus<00:20:26.670> whisper<00:20:27.180> ecosystem 00:20:27.980 --> 00:20:27.990 align:start position:0% the light client plus whisper ecosystem 00:20:27.990 --> 00:20:30.020 align:start position:0% the light client plus whisper ecosystem so<00:20:28.290> we've<00:20:28.980> seen<00:20:29.160> that<00:20:29.310> light<00:20:29.490> clients<00:20:29.820> can<00:20:29.940> be 00:20:30.020 --> 00:20:30.030 align:start position:0% so we've seen that light clients can be 00:20:30.030 --> 00:20:31.790 align:start position:0% so we've seen that light clients can be very<00:20:30.210> useful<00:20:30.270> in<00:20:30.660> mobile<00:20:30.990> devices<00:20:31.470> but<00:20:31.650> then 00:20:31.790 --> 00:20:31.800 align:start position:0% very useful in mobile devices but then 00:20:31.800 --> 00:20:33.920 align:start position:0% very useful in mobile devices but then there's<00:20:31.950> also<00:20:32.130> things<00:20:33.000> like<00:20:33.150> whisper<00:20:33.750> which 00:20:33.920 --> 00:20:33.930 align:start position:0% there's also things like whisper which 00:20:33.930 --> 00:20:35.300 align:start position:0% there's also things like whisper which people<00:20:34.230> are<00:20:34.320> going<00:20:34.440> to<00:20:34.500> talk<00:20:34.680> about<00:20:34.920> a<00:20:35.040> bit 00:20:35.300 --> 00:20:35.310 align:start position:0% people are going to talk about a bit 00:20:35.310 --> 00:20:37.930 align:start position:0% people are going to talk about a bit more<00:20:35.520> which<00:20:36.270> is<00:20:36.420> for<00:20:36.830> decentralized 00:20:37.930 --> 00:20:37.940 align:start position:0% more which is for decentralized 00:20:37.940 --> 00:20:40.010 align:start position:0% more which is for decentralized encrypted<00:20:38.940> messaging<00:20:39.450> essentially<00:20:39.870> with 00:20:40.010 --> 00:20:40.020 align:start position:0% encrypted messaging essentially with 00:20:40.020 --> 00:20:42.160 align:start position:0% encrypted messaging essentially with darkness<00:20:40.350> as<00:20:40.710> well<00:20:40.860> so<00:20:41.070> it's<00:20:41.220> like<00:20:41.280> a<00:20:41.370> global 00:20:42.160 --> 00:20:42.170 align:start position:0% darkness as well so it's like a global 00:20:42.170 --> 00:20:45.710 align:start position:0% darkness as well so it's like a global publish/subscribe<00:20:43.170> system<00:20:43.800> where<00:20:44.720> people 00:20:45.710 --> 00:20:45.720 align:start position:0% publish/subscribe system where people 00:20:45.720 --> 00:20:47.720 align:start position:0% publish/subscribe system where people can't<00:20:45.960> actually<00:20:46.140> see<00:20:46.620> what<00:20:47.040> topics<00:20:47.310> you're 00:20:47.720 --> 00:20:47.730 align:start position:0% can't actually see what topics you're 00:20:47.730 --> 00:20:51.580 align:start position:0% can't actually see what topics you're listening<00:20:48.120> for<00:20:48.330> so<00:20:48.840> that<00:20:49.140> actually<00:20:49.500> makes<00:20:50.390> for 00:20:51.580 --> 00:20:51.590 align:start position:0% listening for so that actually makes for 00:20:51.590 --> 00:20:54.170 align:start position:0% listening for so that actually makes for some<00:20:52.590> pretty<00:20:52.770> interesting<00:20:53.130> platforms<00:20:54.030> like 00:20:54.170 --> 00:20:54.180 align:start position:0% some pretty interesting platforms like 00:20:54.180 --> 00:20:56.780 align:start position:0% some pretty interesting platforms like status<00:20:54.720> to<00:20:54.960> emerge<00:20:55.260> where<00:20:55.800> you<00:20:55.890> can<00:20:56.100> have<00:20:56.490> gaps 00:20:56.780 --> 00:20:56.790 align:start position:0% status to emerge where you can have gaps 00:20:56.790 --> 00:21:00.200 align:start position:0% status to emerge where you can have gaps running<00:20:57.330> on<00:20:57.600> your<00:20:57.750> phone<00:20:58.160> that<00:20:59.160> are<00:20:59.210> messaging 00:21:00.200 --> 00:21:00.210 align:start position:0% running on your phone that are messaging 00:21:00.210 --> 00:21:02.120 align:start position:0% running on your phone that are messaging with<00:21:00.330> people<00:21:00.690> doing<00:21:00.900> medium<00:21:01.380> latency<00:21:01.860> state 00:21:02.120 --> 00:21:02.130 align:start position:0% with people doing medium latency state 00:21:02.130 --> 00:21:03.650 align:start position:0% with people doing medium latency state channels<00:21:02.520> it<00:21:02.700> could<00:21:02.850> even<00:21:02.970> be<00:21:03.180> used<00:21:03.360> for 00:21:03.650 --> 00:21:03.660 align:start position:0% channels it could even be used for 00:21:03.660 --> 00:21:06.200 align:start position:0% channels it could even be used for example<00:21:03.930> as<00:21:04.230> the<00:21:04.860> micro<00:21:05.640> payment<00:21:05.970> for<00:21:06.120> the 00:21:06.200 --> 00:21:06.210 align:start position:0% example as the micro payment for the 00:21:06.210 --> 00:21:07.820 align:start position:0% example as the micro payment for the state<00:21:06.390> channels<00:21:06.720> micro<00:21:07.050> payments<00:21:07.410> layer<00:21:07.560> of 00:21:07.820 --> 00:21:07.830 align:start position:0% state channels micro payments layer of 00:21:07.830 --> 00:21:11.300 align:start position:0% state channels micro payments layer of the<00:21:08.070> light<00:21:08.190> client<00:21:08.580> request<00:21:09.450> credits<00:21:09.840> and<00:21:10.800> of 00:21:11.300 --> 00:21:11.310 align:start position:0% the light client request credits and of 00:21:11.310 --> 00:21:14.120 align:start position:0% the light client request credits and of course<00:21:11.640> we<00:21:12.030> have<00:21:12.240> a<00:21:12.630> roadmap<00:21:13.200> so<00:21:13.680> this<00:21:14.010> is 00:21:14.120 --> 00:21:14.130 align:start position:0% course we have a roadmap so this is 00:21:14.130 --> 00:21:15.830 align:start position:0% course we have a roadmap so this is actually<00:21:14.460> something<00:21:14.700> you<00:21:14.880> can<00:21:15.030> mostly<00:21:15.570> use 00:21:15.830 --> 00:21:15.840 align:start position:0% actually something you can mostly use 00:21:15.840 --> 00:21:18.380 align:start position:0% actually something you can mostly use today<00:21:16.170> so<00:21:16.770> it's<00:21:16.980> in<00:21:17.070> our<00:21:17.160> beta<00:21:17.400> releases<00:21:17.790> you 00:21:18.380 --> 00:21:18.390 align:start position:0% today so it's in our beta releases you 00:21:18.390 --> 00:21:20.060 align:start position:0% today so it's in our beta releases you can<00:21:18.420> just<00:21:18.720> run<00:21:18.900> parity<00:21:19.320> with<00:21:19.470> the<00:21:19.620> dash<00:21:19.800> dash 00:21:20.060 --> 00:21:20.070 align:start position:0% can just run parity with the dash dash 00:21:20.070 --> 00:21:23.480 align:start position:0% can just run parity with the dash dash light<00:21:20.370> flag<00:21:20.750> the<00:21:21.750> UI<00:21:21.990> is<00:21:22.380> still<00:21:22.740> being<00:21:22.980> rebuilt 00:21:23.480 --> 00:21:23.490 align:start position:0% light flag the UI is still being rebuilt 00:21:23.490 --> 00:21:25.580 align:start position:0% light flag the UI is still being rebuilt around<00:21:24.090> light<00:21:24.420> client<00:21:24.810> best<00:21:24.990> practices 00:21:25.580 --> 00:21:25.590 align:start position:0% around light client best practices 00:21:25.590 --> 00:21:27.230 align:start position:0% around light client best practices because<00:21:25.740> it<00:21:26.040> was<00:21:26.160> written<00:21:26.730> mostly<00:21:26.880> with<00:21:27.210> a 00:21:27.230 --> 00:21:27.240 align:start position:0% because it was written mostly with a 00:21:27.240 --> 00:21:28.910 align:start position:0% because it was written mostly with a full<00:21:27.450> client<00:21:27.690> in<00:21:27.990> mind<00:21:28.170> but<00:21:28.350> actually<00:21:28.680> we're 00:21:28.910 --> 00:21:28.920 align:start position:0% full client in mind but actually we're 00:21:28.920 --> 00:21:32.170 align:start position:0% full client in mind but actually we're undergoing<00:21:29.730> this<00:21:29.970> rewrite<00:21:30.360> basically<00:21:31.350> now 00:21:32.170 --> 00:21:32.180 align:start position:0% undergoing this rewrite basically now 00:21:32.180 --> 00:21:35.210 align:start position:0% undergoing this rewrite basically now but<00:21:33.180> if<00:21:33.270> you<00:21:33.390> access<00:21:33.990> the<00:21:34.050> our<00:21:34.260> pcs<00:21:34.590> directly 00:21:35.210 --> 00:21:35.220 align:start position:0% but if you access the our pcs directly 00:21:35.220 --> 00:21:36.430 align:start position:0% but if you access the our pcs directly or<00:21:35.460> if<00:21:35.580> you're<00:21:35.730> using<00:21:35.760> the<00:21:36.090> Chrome<00:21:36.330> extension 00:21:36.430 --> 00:21:36.440 align:start position:0% or if you're using the Chrome extension 00:21:36.440 --> 00:21:38.840 align:start position:0% or if you're using the Chrome extension and<00:21:37.440> you<00:21:37.860> just<00:21:38.040> have<00:21:38.190> some<00:21:38.370> DAP<00:21:38.580> that's 00:21:38.840 --> 00:21:38.850 align:start position:0% and you just have some DAP that's 00:21:38.850 --> 00:21:40.070 align:start position:0% and you just have some DAP that's running<00:21:39.030> independently<00:21:39.660> if<00:21:39.810> the<00:21:39.930> UI 00:21:40.070 --> 00:21:40.080 align:start position:0% running independently if the UI 00:21:40.080 --> 00:21:42.440 align:start position:0% running independently if the UI completely<00:21:40.650> it<00:21:40.800> basically<00:21:41.490> will<00:21:41.790> work<00:21:41.970> I<00:21:42.180> even 00:21:42.440 --> 00:21:42.450 align:start position:0% completely it basically will work I even 00:21:42.450 --> 00:21:44.960 align:start position:0% completely it basically will work I even registered<00:21:43.440> a<00:21:43.530> few<00:21:43.710> names<00:21:43.920> on<00:21:44.100> the<00:21:44.160> ENS<00:21:44.580> using 00:21:44.960 --> 00:21:44.970 align:start position:0% registered a few names on the ENS using 00:21:44.970 --> 00:21:48.590 align:start position:0% registered a few names on the ENS using it<00:21:45.890> it<00:21:46.890> does<00:21:47.580> work<00:21:47.760> in<00:21:47.940> that<00:21:48.030> case<00:21:48.210> if<00:21:48.390> you<00:21:48.420> have 00:21:48.590 --> 00:21:48.600 align:start position:0% it it does work in that case if you have 00:21:48.600 --> 00:21:51.410 align:start position:0% it it does work in that case if you have peers<00:21:48.900> and<00:21:49.740> another<00:21:50.370> really<00:21:50.880> interesting 00:21:51.410 --> 00:21:51.420 align:start position:0% peers and another really interesting 00:21:51.420 --> 00:21:53.390 align:start position:0% peers and another really interesting project<00:21:51.870> that<00:21:52.050> we're<00:21:52.170> thinking<00:21:52.350> of<00:21:52.770> that 00:21:53.390 --> 00:21:53.400 align:start position:0% project that we're thinking of that 00:21:53.400 --> 00:21:54.810 align:start position:0% project that we're thinking of that we're<00:21:53.550> starting<00:21:53.700> to<00:21:53.820> do 00:21:54.810 --> 00:21:54.820 align:start position:0% we're starting to do 00:21:54.820 --> 00:21:56.879 align:start position:0% we're starting to do is<00:21:54.880> compiling<00:21:55.659> the<00:21:55.929> light<00:21:56.080> client<00:21:56.409> down<00:21:56.620> to 00:21:56.879 --> 00:21:56.889 align:start position:0% is compiling the light client down to 00:21:56.889 --> 00:21:58.499 align:start position:0% is compiling the light client down to webassembly<00:21:57.370> so<00:21:57.730> we're<00:21:57.880> writing<00:21:58.059> everything 00:21:58.499 --> 00:21:58.509 align:start position:0% webassembly so we're writing everything 00:21:58.509 --> 00:22:00.299 align:start position:0% webassembly so we're writing everything in<00:21:58.690> this<00:21:58.809> language<00:21:59.169> called<00:21:59.440> rust<00:21:59.860> which<00:22:00.159> is 00:22:00.299 --> 00:22:00.309 align:start position:0% in this language called rust which is 00:22:00.309 --> 00:22:03.029 align:start position:0% in this language called rust which is very<00:22:00.639> low<00:22:00.940> level<00:22:01.330> it's<00:22:01.659> it's<00:22:02.080> that<00:22:02.230> roughly 00:22:03.029 --> 00:22:03.039 align:start position:0% very low level it's it's that roughly 00:22:03.039 --> 00:22:05.249 align:start position:0% very low level it's it's that roughly the<00:22:03.159> same<00:22:03.340> level<00:22:03.730> as<00:22:03.850> C<00:22:04.029> or<00:22:04.179> C++<00:22:04.389> which<00:22:05.080> means 00:22:05.249 --> 00:22:05.259 align:start position:0% the same level as C or C++ which means 00:22:05.259 --> 00:22:08.100 align:start position:0% the same level as C or C++ which means it<00:22:05.409> has<00:22:05.529> no<00:22:06.179> garbage<00:22:07.179> collection<00:22:07.600> or<00:22:07.690> runtime 00:22:08.100 --> 00:22:08.110 align:start position:0% it has no garbage collection or runtime 00:22:08.110 --> 00:22:10.529 align:start position:0% it has no garbage collection or runtime and<00:22:08.350> that<00:22:08.980> makes<00:22:09.190> it<00:22:09.340> very<00:22:09.580> amenable<00:22:10.059> to<00:22:10.299> being 00:22:10.529 --> 00:22:10.539 align:start position:0% and that makes it very amenable to being 00:22:10.539 --> 00:22:14.310 align:start position:0% and that makes it very amenable to being compiled<00:22:11.019> down<00:22:11.350> to<00:22:11.679> web<00:22:11.950> assembly<00:22:12.659> and<00:22:13.659> that 00:22:14.310 --> 00:22:14.320 align:start position:0% compiled down to web assembly and that 00:22:14.320 --> 00:22:17.009 align:start position:0% compiled down to web assembly and that means<00:22:14.529> that<00:22:14.710> we<00:22:14.799> could<00:22:15.039> have<00:22:15.419> this<00:22:16.419> same<00:22:16.750> light 00:22:17.009 --> 00:22:17.019 align:start position:0% means that we could have this same light 00:22:17.019 --> 00:22:19.200 align:start position:0% means that we could have this same light client<00:22:17.350> protocol<00:22:17.799> implementation<00:22:18.700> storage 00:22:19.200 --> 00:22:19.210 align:start position:0% client protocol implementation storage 00:22:19.210 --> 00:22:21.560 align:start position:0% client protocol implementation storage embedded<00:22:20.019> directly<00:22:20.320> into<00:22:20.769> a<00:22:20.919> browser<00:22:21.220> window 00:22:21.560 --> 00:22:21.570 align:start position:0% embedded directly into a browser window 00:22:21.570 --> 00:22:25.110 align:start position:0% embedded directly into a browser window and<00:22:22.570> I<00:22:23.230> think<00:22:23.440> that'll<00:22:23.710> be<00:22:23.740> very<00:22:24.130> interesting 00:22:25.110 --> 00:22:25.120 align:start position:0% and I think that'll be very interesting 00:22:25.120 --> 00:22:28.379 align:start position:0% and I think that'll be very interesting for<00:22:25.149> to<00:22:25.990> see<00:22:26.139> how<00:22:26.590> the<00:22:27.519> app<00:22:27.580> developers<00:22:28.179> use 00:22:28.379 --> 00:22:28.389 align:start position:0% for to see how the app developers use 00:22:28.389 --> 00:22:30.360 align:start position:0% for to see how the app developers use that<00:22:28.600> and<00:22:29.559> if<00:22:29.649> you'd<00:22:29.769> like<00:22:29.799> to<00:22:29.919> follow<00:22:30.250> the 00:22:30.360 --> 00:22:30.370 align:start position:0% that and if you'd like to follow the 00:22:30.370 --> 00:22:32.759 align:start position:0% that and if you'd like to follow the progress<00:22:30.580> I<00:22:31.090> would<00:22:31.720> recommend<00:22:32.110> you<00:22:32.169> do<00:22:32.320> so<00:22:32.500> at 00:22:32.759 --> 00:22:32.769 align:start position:0% progress I would recommend you do so at 00:22:32.769 --> 00:22:35.789 align:start position:0% progress I would recommend you do so at the<00:22:33.070> parody<00:22:33.610> tech<00:22:33.789> slash<00:22:34.059> parody<00:22:34.799> repository 00:22:35.789 --> 00:22:35.799 align:start position:0% the parody tech slash parody repository 00:22:35.799 --> 00:22:37.139 align:start position:0% the parody tech slash parody repository it's<00:22:36.009> all<00:22:36.250> open<00:22:36.759> source 00:22:37.139 --> 00:22:37.149 align:start position:0% it's all open source 00:22:37.149 --> 00:22:39.389 align:start position:0% it's all open source we<00:22:37.899> accept<00:22:38.259> contributions<00:22:38.950> I<00:22:39.070> know<00:22:39.129> you<00:22:39.279> guys 00:22:39.389 --> 00:22:39.399 align:start position:0% we accept contributions I know you guys 00:22:39.399 --> 00:22:41.419 align:start position:0% we accept contributions I know you guys are<00:22:39.580> developers<00:22:40.059> and<00:22:40.330> you<00:22:40.389> love<00:22:40.539> open<00:22:40.870> source 00:22:41.419 --> 00:22:41.429 align:start position:0% are developers and you love open source 00:22:41.429 --> 00:22:44.610 align:start position:0% are developers and you love open source better<00:22:42.429> we<00:22:42.519> get<00:22:42.639> writing<00:22:43.259> well<00:22:44.259> thank<00:22:44.529> you 00:22:44.610 --> 00:22:44.620 align:start position:0% better we get writing well thank you 00:22:44.620 --> 00:22:46.520 align:start position:0% better we get writing well thank you very<00:22:44.769> much 00:22:46.520 --> 00:22:46.530 align:start position:0% very much 00:22:46.530 --> 00:22:53.890 align:start position:0% very much [Music]