WEBVTT Kind: captions Language: en 00:00:04.200 --> 00:00:07.280 align:start position:0% hi<00:00:04.950> my<00:00:05.910> name<00:00:06.030> is<00:00:06.060> Michael<00:00:06.420> Sproul<00:00:06.690> I<00:00:06.900> work<00:00:07.109> at 00:00:07.280 --> 00:00:07.290 align:start position:0% hi my name is Michael Sproul I work at 00:00:07.290 --> 00:00:09.560 align:start position:0% hi my name is Michael Sproul I work at Sigma<00:00:07.710> Prime<00:00:08.100> in<00:00:08.400> Australia<00:00:08.969> all<00:00:09.270> that 00:00:09.560 --> 00:00:09.570 align:start position:0% Sigma Prime in Australia all that 00:00:09.570 --> 00:00:12.500 align:start position:0% Sigma Prime in Australia all that distance<00:00:10.080> away<00:00:10.440> on<00:00:11.250> the<00:00:11.460> lighthouse<00:00:12.030> f2 00:00:12.500 --> 00:00:12.510 align:start position:0% distance away on the lighthouse f2 00:00:12.510 --> 00:00:13.879 align:start position:0% distance away on the lighthouse f2 client<00:00:12.870> and<00:00:13.019> today<00:00:13.410> I'm<00:00:13.530> gonna<00:00:13.650> be<00:00:13.769> talking 00:00:13.879 --> 00:00:13.889 align:start position:0% client and today I'm gonna be talking 00:00:13.889 --> 00:00:18.740 align:start position:0% client and today I'm gonna be talking about<00:00:14.070> optimizing<00:00:14.730> aetherium<00:00:15.389> -<00:00:17.210> so<00:00:18.210> with 00:00:18.740 --> 00:00:18.750 align:start position:0% about optimizing aetherium - so with 00:00:18.750 --> 00:00:21.439 align:start position:0% about optimizing aetherium - so with aetherium<00:00:19.050> -<00:00:19.380> we<00:00:19.710> have<00:00:19.920> the<00:00:20.360> benefit<00:00:21.360> of 00:00:21.439 --> 00:00:21.449 align:start position:0% aetherium - we have the benefit of 00:00:21.449 --> 00:00:23.810 align:start position:0% aetherium - we have the benefit of having<00:00:21.600> a<00:00:21.810> nice<00:00:22.160> executable<00:00:23.160> specification 00:00:23.810 --> 00:00:23.820 align:start position:0% having a nice executable specification 00:00:23.820 --> 00:00:26.420 align:start position:0% having a nice executable specification it's<00:00:24.359> written<00:00:24.600> in<00:00:24.720> Python<00:00:25.170> and<00:00:25.410> it's<00:00:26.220> written 00:00:26.420 --> 00:00:26.430 align:start position:0% it's written in Python and it's written 00:00:26.430 --> 00:00:28.820 align:start position:0% it's written in Python and it's written with<00:00:26.550> a<00:00:26.670> focus<00:00:27.029> on<00:00:27.180> being<00:00:27.510> very<00:00:27.869> clear<00:00:28.199> very 00:00:28.820 --> 00:00:28.830 align:start position:0% with a focus on being very clear very 00:00:28.830 --> 00:00:30.470 align:start position:0% with a focus on being very clear very readable 00:00:30.470 --> 00:00:30.480 align:start position:0% readable 00:00:30.480 --> 00:00:32.659 align:start position:0% readable now<00:00:31.170> with<00:00:31.350> lighthouse<00:00:31.710> our<00:00:31.980> implementation 00:00:32.659 --> 00:00:32.669 align:start position:0% now with lighthouse our implementation 00:00:32.669 --> 00:00:34.910 align:start position:0% now with lighthouse our implementation is<00:00:32.850> in<00:00:33.059> rust<00:00:33.360> and<00:00:33.690> we<00:00:34.050> have<00:00:34.170> a<00:00:34.199> focus<00:00:34.559> on<00:00:34.710> being 00:00:34.910 --> 00:00:34.920 align:start position:0% is in rust and we have a focus on being 00:00:34.920 --> 00:00:37.939 align:start position:0% is in rust and we have a focus on being fast<00:00:35.340> and<00:00:35.699> secure<00:00:35.940> which<00:00:36.839> you<00:00:37.379> know<00:00:37.500> we<00:00:37.800> also 00:00:37.939 --> 00:00:37.949 align:start position:0% fast and secure which you know we also 00:00:37.949 --> 00:00:39.680 align:start position:0% fast and secure which you know we also want<00:00:38.190> to<00:00:38.220> be<00:00:38.309> readable<00:00:38.580> but<00:00:38.940> most<00:00:39.360> of<00:00:39.449> all<00:00:39.540> we 00:00:39.680 --> 00:00:39.690 align:start position:0% want to be readable but most of all we 00:00:39.690 --> 00:00:42.049 align:start position:0% want to be readable but most of all we want<00:00:39.720> to<00:00:39.900> be<00:00:39.960> secure<00:00:40.470> and<00:00:40.729> performance<00:00:41.729> also 00:00:42.049 --> 00:00:42.059 align:start position:0% want to be secure and performance also 00:00:42.059 --> 00:00:43.399 align:start position:0% want to be secure and performance also helps<00:00:42.269> with<00:00:42.360> security<00:00:42.809> because<00:00:43.019> it<00:00:43.140> helps<00:00:43.350> us 00:00:43.399 --> 00:00:43.409 align:start position:0% helps with security because it helps us 00:00:43.409 --> 00:00:46.310 align:start position:0% helps with security because it helps us avoid<00:00:43.650> denial<00:00:44.220> of<00:00:44.280> service<00:00:44.549> attacks<00:00:45.110> so<00:00:46.110> we're 00:00:46.310 --> 00:00:46.320 align:start position:0% avoid denial of service attacks so we're 00:00:46.320 --> 00:00:47.990 align:start position:0% avoid denial of service attacks so we're the<00:00:46.440> spec<00:00:46.739> might<00:00:47.010> prioritize<00:00:47.549> readability 00:00:47.990 --> 00:00:48.000 align:start position:0% the spec might prioritize readability 00:00:48.000 --> 00:00:50.060 align:start position:0% the spec might prioritize readability and<00:00:48.210> use<00:00:48.600> some<00:00:48.809> quadratic<00:00:49.320> time<00:00:49.500> algorithms 00:00:50.060 --> 00:00:50.070 align:start position:0% and use some quadratic time algorithms 00:00:50.070 --> 00:00:52.070 align:start position:0% and use some quadratic time algorithms in<00:00:50.220> lighthouse<00:00:51.000> and<00:00:51.299> in<00:00:51.479> most<00:00:51.720> death<00:00:51.930> to 00:00:52.070 --> 00:00:52.080 align:start position:0% in lighthouse and in most death to 00:00:52.080 --> 00:00:53.329 align:start position:0% in lighthouse and in most death to clients<00:00:52.440> you<00:00:52.470> really<00:00:52.769> want<00:00:52.920> to<00:00:52.979> make<00:00:53.100> sure 00:00:53.329 --> 00:00:53.339 align:start position:0% clients you really want to make sure 00:00:53.339 --> 00:00:55.399 align:start position:0% clients you really want to make sure that<00:00:53.879> you're<00:00:54.030> running<00:00:54.120> quickly<00:00:54.479> and<00:00:54.750> using 00:00:55.399 --> 00:00:55.409 align:start position:0% that you're running quickly and using 00:00:55.409 --> 00:00:57.530 align:start position:0% that you're running quickly and using linear<00:00:55.710> time<00:00:56.030> algorithms<00:00:57.030> are<00:00:57.180> pretty<00:00:57.360> close 00:00:57.530 --> 00:00:57.540 align:start position:0% linear time algorithms are pretty close 00:00:57.540 --> 00:00:59.240 align:start position:0% linear time algorithms are pretty close to<00:00:57.720> that<00:00:57.750> particularly<00:00:58.530> over<00:00:58.860> the<00:00:58.949> set<00:00:59.129> of 00:00:59.240 --> 00:00:59.250 align:start position:0% to that particularly over the set of 00:00:59.250 --> 00:01:00.859 align:start position:0% to that particularly over the set of validators<00:00:59.699> which<00:00:59.879> could<00:01:00.089> be<00:01:00.210> you<00:01:00.540> know<00:01:00.629> up<00:01:00.839> to 00:01:00.859 --> 00:01:00.869 align:start position:0% validators which could be you know up to 00:01:00.869 --> 00:01:05.020 align:start position:0% validators which could be you know up to 4<00:01:01.290> million<00:01:01.500> validators<00:01:02.040> you<00:01:02.250> know<00:01:02.369> in<00:01:03.180> a<00:01:03.299> list 00:01:05.020 --> 00:01:05.030 align:start position:0% 4 million validators you know in a list 00:01:05.030 --> 00:01:08.270 align:start position:0% 4 million validators you know in a list so<00:01:06.030> first<00:01:06.960> of<00:01:07.080> all<00:01:07.170> one<00:01:07.409> example<00:01:07.770> of<00:01:07.979> where<00:01:08.159> the 00:01:08.270 --> 00:01:08.280 align:start position:0% so first of all one example of where the 00:01:08.280 --> 00:01:10.639 align:start position:0% so first of all one example of where the spec<00:01:08.640> is<00:01:08.939> slightly<00:01:09.689> inefficient<00:01:10.289> in<00:01:10.439> how<00:01:10.590> it 00:01:10.639 --> 00:01:10.649 align:start position:0% spec is slightly inefficient in how it 00:01:10.649 --> 00:01:12.859 align:start position:0% spec is slightly inefficient in how it phrases<00:01:11.609> things<00:01:11.820> is<00:01:12.000> the<00:01:12.180> shuffling<00:01:12.689> of 00:01:12.859 --> 00:01:12.869 align:start position:0% phrases things is the shuffling of 00:01:12.869 --> 00:01:16.429 align:start position:0% phrases things is the shuffling of validators<00:01:14.329> so<00:01:15.329> we<00:01:15.479> use<00:01:15.630> this<00:01:15.750> one<00:01:16.049> at<00:01:16.170> a<00:01:16.229> time 00:01:16.429 --> 00:01:16.439 align:start position:0% validators so we use this one at a time 00:01:16.439 --> 00:01:18.889 align:start position:0% validators so we use this one at a time sort<00:01:17.219> of<00:01:17.280> shuffling<00:01:17.729> in<00:01:17.939> the<00:01:18.030> spec<00:01:18.270> to<00:01:18.450> swap<00:01:18.750> or 00:01:18.889 --> 00:01:18.899 align:start position:0% sort of shuffling in the spec to swap or 00:01:18.899 --> 00:01:21.560 align:start position:0% sort of shuffling in the spec to swap or not<00:01:19.020> shuffling<00:01:19.469> and<00:01:19.619> the<00:01:20.549> spec<00:01:20.789> says<00:01:21.119> you<00:01:21.450> know 00:01:21.560 --> 00:01:21.570 align:start position:0% not shuffling and the spec says you know 00:01:21.570 --> 00:01:23.810 align:start position:0% not shuffling and the spec says you know for<00:01:21.780> each<00:01:21.869> index<00:01:22.320> which<00:01:22.799> index<00:01:23.310> does<00:01:23.490> this<00:01:23.609> get 00:01:23.810 --> 00:01:23.820 align:start position:0% for each index which index does this get 00:01:23.820 --> 00:01:25.730 align:start position:0% for each index which index does this get shuffled<00:01:24.030> to<00:01:24.299> and<00:01:24.450> it<00:01:24.539> does<00:01:24.689> H<00:01:24.929> index<00:01:25.350> one<00:01:25.560> at<00:01:25.679> a 00:01:25.730 --> 00:01:25.740 align:start position:0% shuffled to and it does H index one at a 00:01:25.740 --> 00:01:29.080 align:start position:0% shuffled to and it does H index one at a time<00:01:26.119> and<00:01:27.119> it<00:01:27.659> also<00:01:27.810> does<00:01:28.109> this<00:01:28.259> thing<00:01:28.530> where 00:01:29.080 --> 00:01:29.090 align:start position:0% time and it also does this thing where 00:01:29.090 --> 00:01:32.539 align:start position:0% time and it also does this thing where it<00:01:30.090> will<00:01:30.299> extract<00:01:30.750> committees<00:01:31.289> on<00:01:31.590> demand<00:01:32.310> so 00:01:32.539 --> 00:01:32.549 align:start position:0% it will extract committees on demand so 00:01:32.549 --> 00:01:34.219 align:start position:0% it will extract committees on demand so if<00:01:32.729> you<00:01:32.850> get<00:01:32.969> an<00:01:33.060> attestation<00:01:33.630> from<00:01:34.140> the 00:01:34.219 --> 00:01:34.229 align:start position:0% if you get an attestation from the 00:01:34.229 --> 00:01:36.020 align:start position:0% if you get an attestation from the network<00:01:34.530> and<00:01:34.799> you<00:01:34.829> need<00:01:35.070> to<00:01:35.159> know<00:01:35.310> well<00:01:35.789> who 00:01:36.020 --> 00:01:36.030 align:start position:0% network and you need to know well who 00:01:36.030 --> 00:01:38.270 align:start position:0% network and you need to know well who the<00:01:36.179> validate<00:01:36.539> is<00:01:36.659> in<00:01:36.840> this<00:01:37.219> committee<00:01:38.219> for 00:01:38.270 --> 00:01:38.280 align:start position:0% the validate is in this committee for 00:01:38.280 --> 00:01:39.950 align:start position:0% the validate is in this committee for this<00:01:38.520> attestation<00:01:38.939> it'll<00:01:39.390> compute<00:01:39.810> the 00:01:39.950 --> 00:01:39.960 align:start position:0% this attestation it'll compute the 00:01:39.960 --> 00:01:42.169 align:start position:0% this attestation it'll compute the shuffling<00:01:40.380> and<00:01:40.590> then<00:01:41.310> extract<00:01:41.850> the<00:01:41.939> Committee 00:01:42.169 --> 00:01:42.179 align:start position:0% shuffling and then extract the Committee 00:01:42.179 --> 00:01:44.029 align:start position:0% shuffling and then extract the Committee on<00:01:42.359> demand<00:01:43.020> and<00:01:43.200> then<00:01:43.320> throw<00:01:43.560> it<00:01:43.649> away<00:01:43.740> and 00:01:44.029 --> 00:01:44.039 align:start position:0% on demand and then throw it away and 00:01:44.039 --> 00:01:45.319 align:start position:0% on demand and then throw it away and recompute<00:01:44.460> it<00:01:44.640> when<00:01:44.909> you<00:01:44.999> get<00:01:45.119> another 00:01:45.319 --> 00:01:45.329 align:start position:0% recompute it when you get another 00:01:45.329 --> 00:01:47.660 align:start position:0% recompute it when you get another attestation<00:01:45.749> for<00:01:46.079> the<00:01:46.140> same<00:01:46.289> committee<00:01:46.670> which 00:01:47.660 --> 00:01:47.670 align:start position:0% attestation for the same committee which 00:01:47.670 --> 00:01:50.809 align:start position:0% attestation for the same committee which is<00:01:47.700> not<00:01:47.969> so<00:01:48.119> efficient<00:01:48.479> so<00:01:49.369> why<00:01:50.369> not<00:01:50.520> just 00:01:50.809 --> 00:01:50.819 align:start position:0% is not so efficient so why not just 00:01:50.819 --> 00:01:53.209 align:start position:0% is not so efficient so why not just shuffle<00:01:51.359> all<00:01:51.659> the<00:01:51.869> validators<00:01:52.319> once<00:01:52.590> at<00:01:53.100> the 00:01:53.209 --> 00:01:53.219 align:start position:0% shuffle all the validators once at the 00:01:53.219 --> 00:01:55.429 align:start position:0% shuffle all the validators once at the beginning<00:01:53.310> of<00:01:53.520> the<00:01:53.640> epoch<00:01:54.200> cash<00:01:55.200> that 00:01:55.429 --> 00:01:55.439 align:start position:0% beginning of the epoch cash that 00:01:55.439 --> 00:01:56.899 align:start position:0% beginning of the epoch cash that shuffling<00:01:55.890> and<00:01:56.069> then<00:01:56.219> read<00:01:56.429> the<00:01:56.579> committees 00:01:56.899 --> 00:01:56.909 align:start position:0% shuffling and then read the committees 00:01:56.909 --> 00:01:59.239 align:start position:0% shuffling and then read the committees off<00:01:57.060> that<00:01:57.240> on<00:01:57.420> demand<00:01:57.600> as<00:01:57.899> you<00:01:58.049> need<00:01:58.200> to<00:01:58.249> and 00:01:59.239 --> 00:01:59.249 align:start position:0% off that on demand as you need to and 00:01:59.249 --> 00:02:01.700 align:start position:0% off that on demand as you need to and that's<00:01:59.399> exactly<00:01:59.609> what<00:01:59.850> we<00:01:59.939> do<00:02:00.060> and<00:02:00.420> we<00:02:01.289> use<00:02:01.499> an 00:02:01.700 --> 00:02:01.710 align:start position:0% that's exactly what we do and we use an 00:02:01.710 --> 00:02:03.590 align:start position:0% that's exactly what we do and we use an algorithm<00:02:02.189> that<00:02:02.219> proto<00:02:02.789> lambda<00:02:03.179> came<00:02:03.329> up<00:02:03.450> with 00:02:03.590 --> 00:02:03.600 align:start position:0% algorithm that proto lambda came up with 00:02:03.600 --> 00:02:05.929 align:start position:0% algorithm that proto lambda came up with I<00:02:03.840> think<00:02:04.200> proto's<00:02:04.560> probably<00:02:04.889> here<00:02:05.009> somewhere 00:02:05.929 --> 00:02:05.939 align:start position:0% I think proto's probably here somewhere 00:02:05.939 --> 00:02:08.809 align:start position:0% I think proto's probably here somewhere and<00:02:06.299> it<00:02:06.479> ends<00:02:06.810> up<00:02:06.869> being<00:02:07.079> 250<00:02:08.039> times<00:02:08.280> faster 00:02:08.809 --> 00:02:08.819 align:start position:0% and it ends up being 250 times faster 00:02:08.819 --> 00:02:11.960 align:start position:0% and it ends up being 250 times faster than<00:02:09.360> shuffling<00:02:10.050> the<00:02:10.530> list<00:02:10.860> one<00:02:11.280> at<00:02:11.370> a<00:02:11.460> time<00:02:11.670> so 00:02:11.960 --> 00:02:11.970 align:start position:0% than shuffling the list one at a time so 00:02:11.970 --> 00:02:14.630 align:start position:0% than shuffling the list one at a time so 250<00:02:12.659> times<00:02:12.870> speed<00:02:13.110> up<00:02:13.230> is<00:02:13.440> not<00:02:13.620> bad<00:02:13.799> and<00:02:14.010> then 00:02:14.630 --> 00:02:14.640 align:start position:0% 250 times speed up is not bad and then 00:02:14.640 --> 00:02:16.940 align:start position:0% 250 times speed up is not bad and then there's<00:02:14.970> also<00:02:15.209> the<00:02:15.629> benefit<00:02:15.989> of<00:02:16.049> not<00:02:16.440> redoing 00:02:16.940 --> 00:02:16.950 align:start position:0% there's also the benefit of not redoing 00:02:16.950 --> 00:02:17.809 align:start position:0% there's also the benefit of not redoing the<00:02:17.190> computation 00:02:17.809 --> 00:02:17.819 align:start position:0% the computation 00:02:17.819 --> 00:02:20.420 align:start position:0% the computation each<00:02:17.939> time<00:02:18.359> you<00:02:18.780> get<00:02:18.900> an<00:02:19.019> attestation<00:02:19.260> so<00:02:19.829> it's 00:02:20.420 --> 00:02:20.430 align:start position:0% each time you get an attestation so it's 00:02:20.430 --> 00:02:25.250 align:start position:0% each time you get an attestation so it's 250<00:02:20.909> times<00:02:21.209> or<00:02:21.450> better<00:02:23.180> in<00:02:24.180> lighthouse<00:02:25.049> what 00:02:25.250 --> 00:02:25.260 align:start position:0% 250 times or better in lighthouse what 00:02:25.260 --> 00:02:27.289 align:start position:0% 250 times or better in lighthouse what this<00:02:25.379> looks<00:02:25.590> like<00:02:25.650> is<00:02:25.980> we<00:02:26.099> have<00:02:26.280> three<00:02:26.730> caches 00:02:27.289 --> 00:02:27.299 align:start position:0% this looks like is we have three caches 00:02:27.299 --> 00:02:30.110 align:start position:0% this looks like is we have three caches of<00:02:27.769> shuffled<00:02:28.769> validators<00:02:29.280> one<00:02:29.849> for<00:02:30.060> the 00:02:30.110 --> 00:02:30.120 align:start position:0% of shuffled validators one for the 00:02:30.120 --> 00:02:32.209 align:start position:0% of shuffled validators one for the previous<00:02:30.510> epoch<00:02:30.870> the<00:02:31.170> current<00:02:31.499> epoch<00:02:31.799> and<00:02:32.040> for 00:02:32.209 --> 00:02:32.219 align:start position:0% previous epoch the current epoch and for 00:02:32.219 --> 00:02:35.390 align:start position:0% previous epoch the current epoch and for the<00:02:32.280> next<00:02:32.549> epoch<00:02:32.790> and<00:02:33.469> when<00:02:34.469> we<00:02:34.560> hit<00:02:34.829> an<00:02:35.010> epoch 00:02:35.390 --> 00:02:35.400 align:start position:0% the next epoch and when we hit an epoch 00:02:35.400 --> 00:02:36.979 align:start position:0% the next epoch and when we hit an epoch transition<00:02:36.030> so<00:02:36.269> when<00:02:36.420> we<00:02:36.510> move<00:02:36.719> from<00:02:36.750> one 00:02:36.979 --> 00:02:36.989 align:start position:0% transition so when we move from one 00:02:36.989 --> 00:02:39.500 align:start position:0% transition so when we move from one epoch<00:02:37.379> to<00:02:37.530> the<00:02:37.620> next<00:02:37.950> we<00:02:38.609> update<00:02:38.790> these<00:02:39.180> caches 00:02:39.500 --> 00:02:39.510 align:start position:0% epoch to the next we update these caches 00:02:39.510 --> 00:02:42.920 align:start position:0% epoch to the next we update these caches by<00:02:39.989> shifting<00:02:40.980> them<00:02:41.129> along<00:02:41.400> by<00:02:41.579> one<00:02:41.790> and<00:02:42.030> then 00:02:42.920 --> 00:02:42.930 align:start position:0% by shifting them along by one and then 00:02:42.930 --> 00:02:45.740 align:start position:0% by shifting them along by one and then computing<00:02:43.859> from<00:02:44.040> scratch<00:02:44.340> the<00:02:44.909> shuffling<00:02:45.480> for 00:02:45.740 --> 00:02:45.750 align:start position:0% computing from scratch the shuffling for 00:02:45.750 --> 00:02:49.009 align:start position:0% computing from scratch the shuffling for the<00:02:45.810> next<00:02:46.079> epoch<00:02:46.200> and<00:02:47.299> this<00:02:48.299> works<00:02:48.569> perfectly 00:02:49.009 --> 00:02:49.019 align:start position:0% the next epoch and this works perfectly 00:02:49.019 --> 00:02:52.220 align:start position:0% the next epoch and this works perfectly so<00:02:49.950> long<00:02:50.219> as<00:02:50.370> you<00:02:50.639> do<00:02:50.819> know<00:02:51.030> the<00:02:51.239> seed<00:02:51.540> for<00:02:52.169> the 00:02:52.220 --> 00:02:52.230 align:start position:0% so long as you do know the seed for the 00:02:52.230 --> 00:02:55.159 align:start position:0% so long as you do know the seed for the next<00:02:52.260> epoch<00:02:52.709> and<00:02:52.980> by<00:02:53.909> design<00:02:54.090> in<00:02:54.419> a<00:02:54.510> stew<00:02:54.780> we 00:02:55.159 --> 00:02:55.169 align:start position:0% next epoch and by design in a stew we 00:02:55.169 --> 00:02:56.689 align:start position:0% next epoch and by design in a stew we are<00:02:55.290> meant<00:02:55.469> to<00:02:55.530> know<00:02:55.680> the<00:02:55.799> seed<00:02:56.010> for<00:02:56.459> the<00:02:56.519> next 00:02:56.689 --> 00:02:56.699 align:start position:0% are meant to know the seed for the next 00:02:56.699 --> 00:02:59.479 align:start position:0% are meant to know the seed for the next epoch<00:02:56.819> so<00:02:57.000> when<00:02:57.689> we're<00:02:57.840> transitioning<00:02:58.409> from<00:02:58.769> B 00:02:59.479 --> 00:02:59.489 align:start position:0% epoch so when we're transitioning from B 00:02:59.489 --> 00:03:02.300 align:start position:0% epoch so when we're transitioning from B to<00:02:59.519> C<00:02:59.840> into<00:03:00.840> the<00:03:01.049> current<00:03:01.319> epoch<00:03:01.560> we<00:03:01.919> already 00:03:02.300 --> 00:03:02.310 align:start position:0% to C into the current epoch we already 00:03:02.310 --> 00:03:04.909 align:start position:0% to C into the current epoch we already know<00:03:02.489> the<00:03:03.090> round<00:03:03.540> our<00:03:03.689> mix<00:03:03.930> and<00:03:04.169> the<00:03:04.290> seed<00:03:04.530> for 00:03:04.909 --> 00:03:04.919 align:start position:0% know the round our mix and the seed for 00:03:04.919 --> 00:03:06.439 align:start position:0% know the round our mix and the seed for the<00:03:05.010> next<00:03:05.250> epoch<00:03:05.370> and<00:03:05.699> we're<00:03:05.879> able<00:03:06.120> to<00:03:06.180> compute 00:03:06.439 --> 00:03:06.449 align:start position:0% the next epoch and we're able to compute 00:03:06.449 --> 00:03:09.020 align:start position:0% the next epoch and we're able to compute that<00:03:06.659> shuffling<00:03:07.250> at<00:03:08.250> least<00:03:08.489> that's<00:03:08.699> the<00:03:08.790> case 00:03:09.020 --> 00:03:09.030 align:start position:0% that shuffling at least that's the case 00:03:09.030 --> 00:03:11.780 align:start position:0% that shuffling at least that's the case with<00:03:09.510> the<00:03:09.599> spec<00:03:09.840> today<00:03:10.549> when<00:03:11.549> we<00:03:11.669> were 00:03:11.780 --> 00:03:11.790 align:start position:0% with the spec today when we were 00:03:11.790 --> 00:03:15.080 align:start position:0% with the spec today when we were implementing<00:03:12.530> V<00:03:13.530> 0.8<00:03:14.250> of<00:03:14.459> the<00:03:14.609> spec<00:03:14.849> we 00:03:15.080 --> 00:03:15.090 align:start position:0% implementing V 0.8 of the spec we 00:03:15.090 --> 00:03:16.879 align:start position:0% implementing V 0.8 of the spec we noticed<00:03:15.599> that<00:03:15.750> our<00:03:15.870> next<00:03:16.319> epoch<00:03:16.620> cache 00:03:16.879 --> 00:03:16.889 align:start position:0% noticed that our next epoch cache 00:03:16.889 --> 00:03:18.979 align:start position:0% noticed that our next epoch cache actually<00:03:17.430> broke<00:03:17.730> and<00:03:18.239> we<00:03:18.419> were<00:03:18.510> going<00:03:18.659> oh<00:03:18.810> this 00:03:18.979 --> 00:03:18.989 align:start position:0% actually broke and we were going oh this 00:03:18.989 --> 00:03:20.959 align:start position:0% actually broke and we were going oh this is<00:03:19.109> weird<00:03:19.319> like<00:03:19.590> maybe<00:03:19.859> you<00:03:20.579> know<00:03:20.669> maybe<00:03:20.790> the 00:03:20.959 --> 00:03:20.969 align:start position:0% is weird like maybe you know maybe the 00:03:20.969 --> 00:03:23.509 align:start position:0% is weird like maybe you know maybe the spec<00:03:21.239> isn't<00:03:21.810> meant<00:03:21.989> to<00:03:22.049> be<00:03:22.109> like<00:03:22.349> this<00:03:22.650> and<00:03:23.430> we 00:03:23.509 --> 00:03:23.519 align:start position:0% spec isn't meant to be like this and we 00:03:23.519 --> 00:03:24.800 align:start position:0% spec isn't meant to be like this and we went<00:03:23.639> digging<00:03:23.849> through<00:03:24.120> some<00:03:24.299> Docs<00:03:24.540> and<00:03:24.750> we 00:03:24.800 --> 00:03:24.810 align:start position:0% went digging through some Docs and we 00:03:24.810 --> 00:03:25.999 align:start position:0% went digging through some Docs and we were<00:03:24.900> going<00:03:25.109> oh<00:03:25.169> this<00:03:25.259> is<00:03:25.379> really<00:03:25.620> strange<00:03:25.859> you 00:03:25.999 --> 00:03:26.009 align:start position:0% were going oh this is really strange you 00:03:26.009 --> 00:03:28.069 align:start position:0% were going oh this is really strange you know<00:03:26.159> the<00:03:26.280> random<00:03:26.549> mix<00:03:26.759> is<00:03:26.879> updating<00:03:27.449> right 00:03:28.069 --> 00:03:28.079 align:start position:0% know the random mix is updating right 00:03:28.079 --> 00:03:30.649 align:start position:0% know the random mix is updating right till<00:03:28.379> the<00:03:28.409> red<00:03:28.799> arrow<00:03:29.040> just<00:03:29.819> before<00:03:30.269> the<00:03:30.419> start 00:03:30.649 --> 00:03:30.659 align:start position:0% till the red arrow just before the start 00:03:30.659 --> 00:03:33.259 align:start position:0% till the red arrow just before the start of<00:03:30.810> the<00:03:30.959> next<00:03:31.079> epoch<00:03:31.609> which<00:03:32.609> means<00:03:32.909> that<00:03:33.150> the 00:03:33.259 --> 00:03:33.269 align:start position:0% of the next epoch which means that the 00:03:33.269 --> 00:03:34.759 align:start position:0% of the next epoch which means that the block<00:03:33.449> proposer<00:03:33.840> at<00:03:34.169> the<00:03:34.290> start<00:03:34.560> of<00:03:34.620> the 00:03:34.759 --> 00:03:34.769 align:start position:0% block proposer at the start of the 00:03:34.769 --> 00:03:36.979 align:start position:0% block proposer at the start of the current<00:03:35.069> epoch<00:03:35.310> here<00:03:35.579> has<00:03:36.150> less<00:03:36.509> than<00:03:36.540> once 00:03:36.979 --> 00:03:36.989 align:start position:0% current epoch here has less than once 00:03:36.989 --> 00:03:39.379 align:start position:0% current epoch here has less than once lot<00:03:37.409> of<00:03:37.680> notice<00:03:38.430> that<00:03:38.639> they<00:03:38.819> are<00:03:38.849> the<00:03:39.209> block 00:03:39.379 --> 00:03:39.389 align:start position:0% lot of notice that they are the block 00:03:39.389 --> 00:03:40.909 align:start position:0% lot of notice that they are the block proposer<00:03:39.720> so<00:03:40.079> you<00:03:40.470> know<00:03:40.590> they're<00:03:40.709> kind<00:03:40.859> of 00:03:40.909 --> 00:03:40.919 align:start position:0% proposer so you know they're kind of 00:03:40.919 --> 00:03:42.229 align:start position:0% proposer so you know they're kind of doing<00:03:41.069> their<00:03:41.280> epoch<00:03:41.549> transition<00:03:42.000> and<00:03:42.150> then 00:03:42.229 --> 00:03:42.239 align:start position:0% doing their epoch transition and then 00:03:42.239 --> 00:03:44.809 align:start position:0% doing their epoch transition and then they<00:03:42.329> going<00:03:42.540> oh<00:03:42.659> crap<00:03:43.109> I'm<00:03:43.319> the<00:03:43.590> I'm<00:03:44.489> the<00:03:44.639> block 00:03:44.809 --> 00:03:44.819 align:start position:0% they going oh crap I'm the I'm the block 00:03:44.819 --> 00:03:46.069 align:start position:0% they going oh crap I'm the I'm the block proposed<00:03:45.060> that<00:03:45.180> I<00:03:45.269> better<00:03:45.449> get<00:03:45.599> on<00:03:45.750> this<00:03:45.900> and 00:03:46.069 --> 00:03:46.079 align:start position:0% proposed that I better get on this and 00:03:46.079 --> 00:03:49.309 align:start position:0% proposed that I better get on this and propose<00:03:46.620> a<00:03:46.650> block<00:03:47.599> so<00:03:48.599> we<00:03:48.629> clarified<00:03:49.109> this 00:03:49.309 --> 00:03:49.319 align:start position:0% propose a block so we clarified this 00:03:49.319 --> 00:03:52.069 align:start position:0% propose a block so we clarified this with<00:03:49.949> the<00:03:50.220> spec<00:03:50.729> and<00:03:51.060> found<00:03:51.840> out<00:03:51.959> that 00:03:52.069 --> 00:03:52.079 align:start position:0% with the spec and found out that 00:03:52.079 --> 00:03:53.179 align:start position:0% with the spec and found out that actually<00:03:52.229> no<00:03:52.500> it's<00:03:52.620> not<00:03:52.799> meant<00:03:53.009> to<00:03:53.040> be<00:03:53.129> like 00:03:53.179 --> 00:03:53.189 align:start position:0% actually no it's not meant to be like 00:03:53.189 --> 00:03:56.330 align:start position:0% actually no it's not meant to be like this<00:03:53.459> and<00:03:53.720> really<00:03:54.720> we<00:03:55.229> should<00:03:55.470> be<00:03:55.650> looking<00:03:56.159> at 00:03:56.330 --> 00:03:56.340 align:start position:0% this and really we should be looking at 00:03:56.340 --> 00:03:59.210 align:start position:0% this and really we should be looking at the<00:03:56.729> the<00:03:57.659> read<00:03:57.840> a<00:03:57.870> mix<00:03:58.199> from<00:03:58.349> to<00:03:58.620> epochs<00:03:58.979> back 00:03:59.210 --> 00:03:59.220 align:start position:0% the the read a mix from to epochs back 00:03:59.220 --> 00:04:01.129 align:start position:0% the the read a mix from to epochs back so<00:03:59.759> where<00:04:00.000> the<00:04:00.090> green<00:04:00.299> arrow<00:04:00.509> is<00:04:00.719> there<00:04:00.959> and 00:04:01.129 --> 00:04:01.139 align:start position:0% so where the green arrow is there and 00:04:01.139 --> 00:04:04.339 align:start position:0% so where the green arrow is there and that<00:04:01.169> was<00:04:01.650> fixed<00:04:01.919> in<00:04:02.189> V<00:04:02.400> 0.8<00:04:03.000> 0.3<00:04:03.449> of<00:04:04.019> the<00:04:04.139> spec 00:04:04.339 --> 00:04:04.349 align:start position:0% that was fixed in V 0.8 0.3 of the spec 00:04:04.349 --> 00:04:07.429 align:start position:0% that was fixed in V 0.8 0.3 of the spec so<00:04:05.000> something<00:04:06.000> surprising<00:04:06.180> here<00:04:06.810> is<00:04:06.959> that<00:04:07.169> by 00:04:07.429 --> 00:04:07.439 align:start position:0% so something surprising here is that by 00:04:07.439 --> 00:04:09.709 align:start position:0% so something surprising here is that by implementing<00:04:07.949> an<00:04:08.280> optimization<00:04:09.060> it<00:04:09.239> actually 00:04:09.709 --> 00:04:09.719 align:start position:0% implementing an optimization it actually 00:04:09.719 --> 00:04:12.020 align:start position:0% implementing an optimization it actually allowed<00:04:09.959> us<00:04:09.989> to<00:04:10.169> discover<00:04:10.500> a<00:04:10.889> bug<00:04:11.370> in<00:04:11.609> the<00:04:11.790> spec 00:04:12.020 --> 00:04:12.030 align:start position:0% allowed us to discover a bug in the spec 00:04:12.030 --> 00:04:15.349 align:start position:0% allowed us to discover a bug in the spec and<00:04:12.919> I<00:04:13.919> think<00:04:14.250> this<00:04:14.430> speaks<00:04:14.579> to<00:04:14.909> something 00:04:15.349 --> 00:04:15.359 align:start position:0% and I think this speaks to something 00:04:15.359 --> 00:04:17.810 align:start position:0% and I think this speaks to something more<00:04:15.629> general<00:04:16.079> in<00:04:16.259> the<00:04:16.829> etherium<00:04:17.280> space<00:04:17.519> which 00:04:17.810 --> 00:04:17.820 align:start position:0% more general in the etherium space which 00:04:17.820 --> 00:04:19.520 align:start position:0% more general in the etherium space which is<00:04:18.000> that<00:04:18.329> by<00:04:18.449> having<00:04:18.479> a<00:04:18.870> diversity<00:04:19.289> of 00:04:19.520 --> 00:04:19.530 align:start position:0% is that by having a diversity of 00:04:19.530 --> 00:04:21.319 align:start position:0% is that by having a diversity of implementations<00:04:20.280> in<00:04:20.489> different<00:04:20.820> languages 00:04:21.319 --> 00:04:21.329 align:start position:0% implementations in different languages 00:04:21.329 --> 00:04:22.909 align:start position:0% implementations in different languages and<00:04:21.599> with<00:04:21.989> different<00:04:22.169> optimizations 00:04:22.909 --> 00:04:22.919 align:start position:0% and with different optimizations 00:04:22.919 --> 00:04:24.110 align:start position:0% and with different optimizations phrasing<00:04:23.370> the<00:04:23.400> same<00:04:23.669> thing<00:04:23.940> in<00:04:24.090> different 00:04:24.110 --> 00:04:24.120 align:start position:0% phrasing the same thing in different 00:04:24.120 --> 00:04:26.750 align:start position:0% phrasing the same thing in different ways<00:04:24.509> that<00:04:25.169> can<00:04:25.440> actually<00:04:25.620> lead<00:04:25.949> to<00:04:25.979> clarity 00:04:26.750 --> 00:04:26.760 align:start position:0% ways that can actually lead to clarity 00:04:26.760 --> 00:04:28.640 align:start position:0% ways that can actually lead to clarity of<00:04:26.969> the<00:04:27.449> specification<00:04:28.080> and<00:04:28.229> I<00:04:28.260> think<00:04:28.469> that's 00:04:28.640 --> 00:04:28.650 align:start position:0% of the specification and I think that's 00:04:28.650 --> 00:04:30.409 align:start position:0% of the specification and I think that's something<00:04:28.860> that's<00:04:29.130> really<00:04:29.520> important<00:04:30.300> and 00:04:30.409 --> 00:04:30.419 align:start position:0% something that's really important and 00:04:30.419 --> 00:04:31.790 align:start position:0% something that's really important and it's<00:04:30.570> a<00:04:30.630> good<00:04:30.750> way<00:04:30.900> to<00:04:30.930> design<00:04:31.320> so 00:04:31.790 --> 00:04:31.800 align:start position:0% it's a good way to design so 00:04:31.800 --> 00:04:36.770 align:start position:0% it's a good way to design so we're<00:04:34.340> let's<00:04:35.340> talk<00:04:35.520> a<00:04:35.550> bit<00:04:35.729> more<00:04:35.759> about<00:04:36.210> epoch 00:04:36.770 --> 00:04:36.780 align:start position:0% we're let's talk a bit more about epoch 00:04:36.780 --> 00:04:38.839 align:start position:0% we're let's talk a bit more about epoch processing<00:04:37.319> because<00:04:38.250> there's<00:04:38.430> a<00:04:38.490> few<00:04:38.669> more 00:04:38.839 --> 00:04:38.849 align:start position:0% processing because there's a few more 00:04:38.849 --> 00:04:40.309 align:start position:0% processing because there's a few more optimizations<00:04:39.599> that<00:04:39.750> we<00:04:39.810> do<00:04:39.930> around<00:04:40.199> this 00:04:40.309 --> 00:04:40.319 align:start position:0% optimizations that we do around this 00:04:40.319 --> 00:04:42.080 align:start position:0% optimizations that we do around this maybe<00:04:40.770> less<00:04:41.039> important<00:04:41.490> than<00:04:41.610> the<00:04:41.669> shuffling 00:04:42.080 --> 00:04:42.090 align:start position:0% maybe less important than the shuffling 00:04:42.090 --> 00:04:44.350 align:start position:0% maybe less important than the shuffling one<00:04:42.270> which<00:04:42.479> is<00:04:42.629> such<00:04:42.840> a<00:04:42.870> massive<00:04:43.139> speed<00:04:43.530> up 00:04:44.350 --> 00:04:44.360 align:start position:0% one which is such a massive speed up 00:04:44.360 --> 00:04:48.260 align:start position:0% one which is such a massive speed up with<00:04:45.360> the<00:04:45.479> epoch<00:04:45.750> processing<00:04:46.580> the<00:04:47.580> the<00:04:48.000> spec 00:04:48.260 --> 00:04:48.270 align:start position:0% with the epoch processing the the spec 00:04:48.270 --> 00:04:50.689 align:start position:0% with the epoch processing the the spec occasionally<00:04:49.139> will<00:04:49.289> iterate<00:04:49.470> over<00:04:49.889> lists<00:04:50.580> of 00:04:50.689 --> 00:04:50.699 align:start position:0% occasionally will iterate over lists of 00:04:50.699 --> 00:04:52.430 align:start position:0% occasionally will iterate over lists of added<00:04:50.970> stations<00:04:51.330> and<00:04:51.479> validators<00:04:51.930> kind<00:04:52.349> of 00:04:52.430 --> 00:04:52.440 align:start position:0% added stations and validators kind of 00:04:52.440 --> 00:04:55.700 align:start position:0% added stations and validators kind of redundantly<00:04:53.009> and<00:04:53.870> one<00:04:54.870> example<00:04:55.139> of<00:04:55.289> this<00:04:55.470> is 00:04:55.700 --> 00:04:55.710 align:start position:0% redundantly and one example of this is 00:04:55.710 --> 00:04:58.189 align:start position:0% redundantly and one example of this is when<00:04:56.069> you're<00:04:56.220> calculating<00:04:56.430> the<00:04:56.970> reward<00:04:57.870> for<00:04:58.139> a 00:04:58.189 --> 00:04:58.199 align:start position:0% when you're calculating the reward for a 00:04:58.199 --> 00:05:01.339 align:start position:0% when you're calculating the reward for a proposer<00:04:59.060> based<00:05:00.060> on<00:05:00.330> the<00:05:00.750> other<00:05:00.930> stations 00:05:01.339 --> 00:05:01.349 align:start position:0% proposer based on the other stations 00:05:01.349 --> 00:05:03.439 align:start position:0% proposer based on the other stations that<00:05:01.500> they've<00:05:01.650> included<00:05:01.830> in<00:05:02.250> their<00:05:02.370> blocks<00:05:02.639> it 00:05:03.439 --> 00:05:03.449 align:start position:0% that they've included in their blocks it 00:05:03.449 --> 00:05:07.040 align:start position:0% that they've included in their blocks it uses<00:05:03.810> time<00:05:04.169> o<00:05:04.500> V<00:05:05.190> times<00:05:05.759> a<00:05:06.000> so<00:05:06.509> it's<00:05:06.719> kind<00:05:06.900> of<00:05:06.960> a 00:05:07.040 --> 00:05:07.050 align:start position:0% uses time o V times a so it's kind of a 00:05:07.050 --> 00:05:08.540 align:start position:0% uses time o V times a so it's kind of a quadratic<00:05:07.409> u<00:05:07.650> time<00:05:07.860> where<00:05:08.099> V<00:05:08.250> is<00:05:08.280> the 00:05:08.540 --> 00:05:08.550 align:start position:0% quadratic u time where V is the 00:05:08.550 --> 00:05:10.100 align:start position:0% quadratic u time where V is the validators<00:05:09.030> and<00:05:09.210> a<00:05:09.330> is<00:05:09.479> the<00:05:09.629> pending<00:05:09.930> out<00:05:10.020> of 00:05:10.100 --> 00:05:10.110 align:start position:0% validators and a is the pending out of 00:05:10.110 --> 00:05:11.869 align:start position:0% validators and a is the pending out of stations<00:05:10.409> and<00:05:10.590> really<00:05:11.250> that<00:05:11.400> validators 00:05:11.869 --> 00:05:11.879 align:start position:0% stations and really that validators 00:05:11.879 --> 00:05:13.670 align:start position:0% stations and really that validators because<00:05:12.210> that<00:05:12.330> list<00:05:12.659> is<00:05:12.810> so<00:05:12.990> large<00:05:13.229> we<00:05:13.500> really 00:05:13.670 --> 00:05:13.680 align:start position:0% because that list is so large we really 00:05:13.680 --> 00:05:15.439 align:start position:0% because that list is so large we really don't<00:05:13.860> want<00:05:14.009> any<00:05:14.219> sort<00:05:14.580> of<00:05:14.610> quadratic<00:05:15.120> factor 00:05:15.439 --> 00:05:15.449 align:start position:0% don't want any sort of quadratic factor 00:05:15.449 --> 00:05:18.200 align:start position:0% don't want any sort of quadratic factor in<00:05:15.599> there<00:05:15.840> with<00:05:16.440> that<00:05:16.639> this<00:05:17.639> is<00:05:17.789> the<00:05:17.879> code<00:05:18.060> from 00:05:18.200 --> 00:05:18.210 align:start position:0% in there with that this is the code from 00:05:18.210 --> 00:05:19.550 align:start position:0% in there with that this is the code from the<00:05:18.270> spec<00:05:18.509> where<00:05:18.659> you<00:05:18.719> can<00:05:18.840> see<00:05:18.990> the<00:05:19.110> nested 00:05:19.550 --> 00:05:19.560 align:start position:0% the spec where you can see the nested 00:05:19.560 --> 00:05:21.709 align:start position:0% the spec where you can see the nested for-loops<00:05:20.520> giving<00:05:21.000> you<00:05:21.060> the<00:05:21.150> quadratic<00:05:21.539> time 00:05:21.709 --> 00:05:21.719 align:start position:0% for-loops giving you the quadratic time 00:05:21.719 --> 00:05:25.129 align:start position:0% for-loops giving you the quadratic time thing<00:05:21.960> so<00:05:22.169> there's<00:05:22.349> the<00:05:23.419> the<00:05:24.419> loop<00:05:24.629> over<00:05:24.780> the 00:05:25.129 --> 00:05:25.139 align:start position:0% thing so there's the the loop over the 00:05:25.139 --> 00:05:26.930 align:start position:0% thing so there's the the loop over the validators<00:05:26.129> and<00:05:26.310> then<00:05:26.430> the<00:05:26.520> loop<00:05:26.669> over<00:05:26.819> the 00:05:26.930 --> 00:05:26.940 align:start position:0% validators and then the loop over the 00:05:26.940 --> 00:05:30.619 align:start position:0% validators and then the loop over the other<00:05:27.120> stations<00:05:27.509> within<00:05:27.719> that<00:05:29.120> so<00:05:30.120> rather 00:05:30.619 --> 00:05:30.629 align:start position:0% other stations within that so rather 00:05:30.629 --> 00:05:32.450 align:start position:0% other stations within that so rather than<00:05:30.900> doing<00:05:31.050> that<00:05:31.289> quadratic<00:05:31.650> time<00:05:31.949> thing<00:05:32.250> in 00:05:32.450 --> 00:05:32.460 align:start position:0% than doing that quadratic time thing in 00:05:32.460 --> 00:05:34.189 align:start position:0% than doing that quadratic time thing in light<00:05:32.759> house<00:05:32.940> what<00:05:33.150> we<00:05:33.240> do<00:05:33.389> is<00:05:33.629> just<00:05:33.659> a<00:05:34.020> linear 00:05:34.189 --> 00:05:34.199 align:start position:0% light house what we do is just a linear 00:05:34.199 --> 00:05:37.159 align:start position:0% light house what we do is just a linear pass<00:05:34.620> over<00:05:35.460> the<00:05:35.610> over<00:05:36.479> the<00:05:36.569> validators<00:05:37.020> and 00:05:37.159 --> 00:05:37.169 align:start position:0% pass over the over the validators and 00:05:37.169 --> 00:05:39.379 align:start position:0% pass over the over the validators and the<00:05:37.259> attestation<00:05:37.590> so<00:05:38.039> we<00:05:38.699> do<00:05:38.819> it<00:05:38.909> in<00:05:39.029> three 00:05:39.379 --> 00:05:39.389 align:start position:0% the attestation so we do it in three 00:05:39.389 --> 00:05:41.029 align:start position:0% the attestation so we do it in three parts<00:05:39.810> we<00:05:39.960> first<00:05:40.199> go<00:05:40.380> over<00:05:40.409> the<00:05:40.620> validators 00:05:41.029 --> 00:05:41.039 align:start position:0% parts we first go over the validators 00:05:41.039 --> 00:05:42.769 align:start position:0% parts we first go over the validators get<00:05:41.219> some<00:05:41.550> basic<00:05:41.880> info<00:05:42.180> like<00:05:42.389> whether<00:05:42.599> they're 00:05:42.769 --> 00:05:42.779 align:start position:0% get some basic info like whether they're 00:05:42.779 --> 00:05:44.300 align:start position:0% get some basic info like whether they're active<00:05:42.960> in<00:05:43.229> the<00:05:43.289> current<00:05:43.560> epoch<00:05:43.830> things<00:05:44.190> like 00:05:44.300 --> 00:05:44.310 align:start position:0% active in the current epoch things like 00:05:44.310 --> 00:05:46.189 align:start position:0% active in the current epoch things like that<00:05:44.460> then<00:05:45.210> we<00:05:45.360> iterate<00:05:45.479> over<00:05:45.750> the<00:05:46.050> other 00:05:46.189 --> 00:05:46.199 align:start position:0% that then we iterate over the other 00:05:46.199 --> 00:05:48.860 align:start position:0% that then we iterate over the other stations<00:05:46.650> to<00:05:46.860> find<00:05:47.099> out<00:05:47.250> how<00:05:47.880> people<00:05:47.940> voted<00:05:48.690> in 00:05:48.860 --> 00:05:48.870 align:start position:0% stations to find out how people voted in 00:05:48.870 --> 00:05:50.990 align:start position:0% stations to find out how people voted in things<00:05:49.770> whether<00:05:50.009> they<00:05:50.159> voted<00:05:50.460> on<00:05:50.520> the<00:05:50.639> correct 00:05:50.990 --> 00:05:51.000 align:start position:0% things whether they voted on the correct 00:05:51.000 --> 00:05:54.019 align:start position:0% things whether they voted on the correct Kaspar<00:05:51.870> FFG<00:05:52.319> targets<00:05:52.830> and<00:05:53.009> sources<00:05:53.400> and<00:05:53.580> then 00:05:54.019 --> 00:05:54.029 align:start position:0% Kaspar FFG targets and sources and then 00:05:54.029 --> 00:05:56.180 align:start position:0% Kaspar FFG targets and sources and then we<00:05:54.120> do<00:05:54.240> one<00:05:54.479> final<00:05:54.750> pass<00:05:55.139> to<00:05:55.440> sum<00:05:55.710> up<00:05:55.889> some 00:05:56.180 --> 00:05:56.190 align:start position:0% we do one final pass to sum up some 00:05:56.190 --> 00:05:58.100 align:start position:0% we do one final pass to sum up some balances<00:05:56.699> so<00:05:57.029> different<00:05:57.389> types<00:05:57.599> of<00:05:57.779> total 00:05:58.100 --> 00:05:58.110 align:start position:0% balances so different types of total 00:05:58.110 --> 00:06:00.260 align:start position:0% balances so different types of total balances<00:05:58.560> for<00:05:58.740> validators<00:05:59.250> and<00:05:59.400> in<00:05:59.969> total 00:06:00.260 --> 00:06:00.270 align:start position:0% balances for validators and in total 00:06:00.270 --> 00:06:04.670 align:start position:0% balances for validators and in total that's<00:06:00.389> order<00:06:01.110> V<00:06:01.440> plus<00:06:01.680> a<00:06:01.949> time<00:06:02.849> and<00:06:03.259> the<00:06:04.259> sum 00:06:04.670 --> 00:06:04.680 align:start position:0% that's order V plus a time and the sum 00:06:04.680 --> 00:06:06.170 align:start position:0% that's order V plus a time and the sum of<00:06:04.710> the<00:06:04.830> total<00:06:04.979> balances<00:06:05.490> just<00:06:05.669> as<00:06:05.789> an<00:06:05.940> example 00:06:06.170 --> 00:06:06.180 align:start position:0% of the total balances just as an example 00:06:06.180 --> 00:06:09.680 align:start position:0% of the total balances just as an example these<00:06:07.050> are<00:06:07.110> the<00:06:07.490> totals<00:06:08.490> we<00:06:08.639> compute<00:06:09.000> so<00:06:09.240> the 00:06:09.680 --> 00:06:09.690 align:start position:0% these are the totals we compute so the 00:06:09.690 --> 00:06:12.559 align:start position:0% these are the totals we compute so the total<00:06:10.080> balance<00:06:10.229> of<00:06:10.590> all<00:06:10.830> the<00:06:10.949> people<00:06:11.250> who<00:06:12.240> were 00:06:12.559 --> 00:06:12.569 align:start position:0% total balance of all the people who were 00:06:12.569 --> 00:06:14.269 align:start position:0% total balance of all the people who were active<00:06:12.930> in<00:06:12.990> the<00:06:13.050> current<00:06:13.319> epoch<00:06:13.620> all<00:06:13.949> the 00:06:14.269 --> 00:06:14.279 align:start position:0% active in the current epoch all the 00:06:14.279 --> 00:06:17.029 align:start position:0% active in the current epoch all the validators<00:06:14.729> who<00:06:15.560> attested<00:06:16.560> in<00:06:16.650> the<00:06:16.770> current 00:06:17.029 --> 00:06:17.039 align:start position:0% validators who attested in the current 00:06:17.039 --> 00:06:18.709 align:start position:0% validators who attested in the current epoch<00:06:17.279> who<00:06:17.819> were<00:06:17.940> tested<00:06:18.300> to<00:06:18.389> the<00:06:18.479> correct 00:06:18.709 --> 00:06:18.719 align:start position:0% epoch who were tested to the correct 00:06:18.719 --> 00:06:23.659 align:start position:0% epoch who were tested to the correct target<00:06:18.990> etc<00:06:19.710> so<00:06:20.279> on<00:06:20.430> and<00:06:20.550> so<00:06:20.669> forth<00:06:22.099> as<00:06:23.099> I<00:06:23.490> said 00:06:23.659 --> 00:06:23.669 align:start position:0% target etc so on and so forth as I said 00:06:23.669 --> 00:06:25.909 align:start position:0% target etc so on and so forth as I said before<00:06:23.930> usually<00:06:24.930> when<00:06:25.379> you<00:06:25.469> implement<00:06:25.680> an 00:06:25.909 --> 00:06:25.919 align:start position:0% before usually when you implement an 00:06:25.919 --> 00:06:27.619 align:start position:0% before usually when you implement an optimization<00:06:26.610> you<00:06:26.879> run<00:06:27.060> the<00:06:27.210> risk<00:06:27.419> of 00:06:27.619 --> 00:06:27.629 align:start position:0% optimization you run the risk of 00:06:27.629 --> 00:06:32.240 align:start position:0% optimization you run the risk of breaking<00:06:28.529> your<00:06:29.400> your<00:06:30.180> client<00:06:30.599> and<00:06:30.719> and<00:06:31.250> you 00:06:32.240 --> 00:06:32.250 align:start position:0% breaking your your client and and you 00:06:32.250 --> 00:06:34.070 align:start position:0% breaking your your client and and you know<00:06:32.370> running<00:06:32.759> afoul<00:06:33.090> of<00:06:33.389> what<00:06:33.539> the<00:06:33.629> spec<00:06:33.870> says 00:06:34.070 --> 00:06:34.080 align:start position:0% know running afoul of what the spec says 00:06:34.080 --> 00:06:37.550 align:start position:0% know running afoul of what the spec says you<00:06:34.259> should<00:06:34.440> be<00:06:34.529> doing<00:06:34.879> so<00:06:35.960> what<00:06:36.960> we<00:06:37.080> what<00:06:37.440> we 00:06:37.550 --> 00:06:37.560 align:start position:0% you should be doing so what we what we 00:06:37.560 --> 00:06:39.140 align:start position:0% you should be doing so what we what we really<00:06:37.800> need<00:06:37.949> to<00:06:37.979> do<00:06:38.159> is<00:06:38.370> when<00:06:38.550> we<00:06:38.639> implement 00:06:39.140 --> 00:06:39.150 align:start position:0% really need to do is when we implement 00:06:39.150 --> 00:06:41.480 align:start position:0% really need to do is when we implement an<00:06:39.240> optimization<00:06:39.810> we<00:06:39.930> need<00:06:40.110> to<00:06:40.490> guarantee 00:06:41.480 --> 00:06:41.490 align:start position:0% an optimization we need to guarantee 00:06:41.490 --> 00:06:43.159 align:start position:0% an optimization we need to guarantee that<00:06:41.940> it<00:06:42.060> has<00:06:42.210> the<00:06:42.389> correct<00:06:42.599> behavior<00:06:42.719> and 00:06:43.159 --> 00:06:43.169 align:start position:0% that it has the correct behavior and 00:06:43.169 --> 00:06:45.650 align:start position:0% that it has the correct behavior and isn't<00:06:43.979> going<00:06:44.130> to<00:06:44.190> break<00:06:44.339> out<00:06:44.460> by<00:06:44.580> it<00:06:44.639> so 00:06:45.650 --> 00:06:45.660 align:start position:0% isn't going to break out by it so 00:06:45.660 --> 00:06:47.600 align:start position:0% isn't going to break out by it so in<00:06:45.840> roughly<00:06:46.200> increasing<00:06:46.890> order<00:06:47.100> of<00:06:47.190> strength 00:06:47.600 --> 00:06:47.610 align:start position:0% in roughly increasing order of strength 00:06:47.610 --> 00:06:49.760 align:start position:0% in roughly increasing order of strength we've<00:06:48.270> got<00:06:48.480> you<00:06:48.780> know<00:06:48.900> looking<00:06:49.440> at<00:06:49.500> the<00:06:49.590> code 00:06:49.760 --> 00:06:49.770 align:start position:0% we've got you know looking at the code 00:06:49.770 --> 00:06:51.020 align:start position:0% we've got you know looking at the code looking<00:06:50.040> at<00:06:50.130> the<00:06:50.250> spec<00:06:50.610> looking<00:06:50.910> at<00:06:50.970> the 00:06:51.020 --> 00:06:51.030 align:start position:0% looking at the spec looking at the 00:06:51.030 --> 00:06:52.370 align:start position:0% looking at the spec looking at the optimized<00:06:51.390> version<00:06:51.600> and<00:06:51.930> just<00:06:52.110> kind<00:06:52.350> of 00:06:52.370 --> 00:06:52.380 align:start position:0% optimized version and just kind of 00:06:52.380 --> 00:06:54.440 align:start position:0% optimized version and just kind of rockin<00:06:53.130> that<00:06:53.250> they're<00:06:53.400> the<00:06:53.520> same<00:06:53.700> that's<00:06:54.240> the 00:06:54.440 --> 00:06:54.450 align:start position:0% rockin that they're the same that's the 00:06:54.450 --> 00:06:55.880 align:start position:0% rockin that they're the same that's the weakest<00:06:54.870> guarantee<00:06:55.350> you<00:06:55.470> can<00:06:55.620> do<00:06:55.740> because 00:06:55.880 --> 00:06:55.890 align:start position:0% weakest guarantee you can do because 00:06:55.890 --> 00:06:58.970 align:start position:0% weakest guarantee you can do because people<00:06:56.160> are<00:06:56.340> pretty<00:06:56.520> terrible<00:06:57.380> and<00:06:58.380> then 00:06:58.970 --> 00:06:58.980 align:start position:0% people are pretty terrible and then 00:06:58.980 --> 00:07:01.040 align:start position:0% people are pretty terrible and then moving<00:06:59.160> into<00:06:59.370> like<00:06:59.580> unit<00:07:00.000> tests<00:07:00.480> the<00:07:00.720> etherium 00:07:01.040 --> 00:07:01.050 align:start position:0% moving into like unit tests the etherium 00:07:01.050 --> 00:07:02.840 align:start position:0% moving into like unit tests the etherium foundations<00:07:01.530> test<00:07:01.860> vectors<00:07:02.280> which<00:07:02.520> have<00:07:02.670> been 00:07:02.840 --> 00:07:02.850 align:start position:0% foundations test vectors which have been 00:07:02.850 --> 00:07:06.920 align:start position:0% foundations test vectors which have been super<00:07:03.240> useful<00:07:03.560> and<00:07:04.560> then<00:07:05.400> into<00:07:05.730> fuzzing<00:07:06.360> so 00:07:06.920 --> 00:07:06.930 align:start position:0% super useful and then into fuzzing so 00:07:06.930 --> 00:07:08.300 align:start position:0% super useful and then into fuzzing so we've<00:07:07.110> been<00:07:07.260> doing<00:07:07.470> quite<00:07:07.650> a<00:07:07.740> bit<00:07:07.800> of<00:07:07.920> fuzzing 00:07:08.300 --> 00:07:08.310 align:start position:0% we've been doing quite a bit of fuzzing 00:07:08.310 --> 00:07:10.790 align:start position:0% we've been doing quite a bit of fuzzing on<00:07:08.460> lighthouse<00:07:08.850> both<00:07:09.540> crash<00:07:09.930> fuzzing<00:07:10.410> to<00:07:10.620> see 00:07:10.790 --> 00:07:10.800 align:start position:0% on lighthouse both crash fuzzing to see 00:07:10.800 --> 00:07:12.440 align:start position:0% on lighthouse both crash fuzzing to see you<00:07:11.130> know<00:07:11.220> make<00:07:11.460> sure<00:07:11.490> functions<00:07:12.000> never<00:07:12.210> crash 00:07:12.440 --> 00:07:12.450 align:start position:0% you know make sure functions never crash 00:07:12.450 --> 00:07:14.000 align:start position:0% you know make sure functions never crash -<00:07:12.690> regardless<00:07:13.350> of<00:07:13.440> what<00:07:13.530> inputs<00:07:13.800> you<00:07:13.890> give 00:07:14.000 --> 00:07:14.010 align:start position:0% - regardless of what inputs you give 00:07:14.010 --> 00:07:15.980 align:start position:0% - regardless of what inputs you give them<00:07:14.190> and<00:07:14.340> differential<00:07:15.090> fuzzing<00:07:15.480> comparing 00:07:15.980 --> 00:07:15.990 align:start position:0% them and differential fuzzing comparing 00:07:15.990 --> 00:07:18.080 align:start position:0% them and differential fuzzing comparing two<00:07:16.200> different<00:07:16.230> implementations<00:07:17.100> and<00:07:17.370> midis 00:07:18.080 --> 00:07:18.090 align:start position:0% two different implementations and midis 00:07:18.090 --> 00:07:20.000 align:start position:0% two different implementations and midis doing<00:07:18.330> more<00:07:18.510> work<00:07:18.660> along<00:07:18.990> those<00:07:19.170> lines<00:07:19.410> in<00:07:19.800> the 00:07:20.000 --> 00:07:20.010 align:start position:0% doing more work along those lines in the 00:07:20.010 --> 00:07:23.240 align:start position:0% doing more work along those lines in the next<00:07:20.250> couple<00:07:21.150> of<00:07:21.270> months<00:07:21.510> and<00:07:21.660> also<00:07:22.470> similar 00:07:23.240 --> 00:07:23.250 align:start position:0% next couple of months and also similar 00:07:23.250 --> 00:07:25.040 align:start position:0% next couple of months and also similar to<00:07:23.490> that<00:07:23.580> randomized<00:07:24.180> testing<00:07:24.630> property 00:07:25.040 --> 00:07:25.050 align:start position:0% to that randomized testing property 00:07:25.050 --> 00:07:27.130 align:start position:0% to that randomized testing property testing<00:07:25.470> similar<00:07:25.950> to<00:07:26.070> quick<00:07:26.280> check<00:07:26.520> and 00:07:27.130 --> 00:07:27.140 align:start position:0% testing similar to quick check and 00:07:27.140 --> 00:07:29.060 align:start position:0% testing similar to quick check and because<00:07:28.140> I've<00:07:28.260> got<00:07:28.440> a<00:07:28.470> bit<00:07:28.620> of<00:07:28.710> a<00:07:28.770> formal 00:07:29.060 --> 00:07:29.070 align:start position:0% because I've got a bit of a formal 00:07:29.070 --> 00:07:30.620 align:start position:0% because I've got a bit of a formal verification<00:07:29.220> background<00:07:29.850> I've<00:07:30.030> got<00:07:30.540> this 00:07:30.620 --> 00:07:30.630 align:start position:0% verification background I've got this 00:07:30.630 --> 00:07:32.600 align:start position:0% verification background I've got this itch<00:07:30.900> that<00:07:31.260> I<00:07:31.590> haven't<00:07:31.740> scratched<00:07:32.040> yet<00:07:32.400> for 00:07:32.600 --> 00:07:32.610 align:start position:0% itch that I haven't scratched yet for 00:07:32.610 --> 00:07:34.760 align:start position:0% itch that I haven't scratched yet for formal<00:07:32.880> verification<00:07:33.030> and<00:07:33.750> that<00:07:34.320> you<00:07:34.650> know 00:07:34.760 --> 00:07:34.770 align:start position:0% formal verification and that you know 00:07:34.770 --> 00:07:36.620 align:start position:0% formal verification and that you know we'll<00:07:35.190> see<00:07:35.370> if<00:07:35.610> I<00:07:35.790> get<00:07:35.910> around<00:07:36.120> to<00:07:36.210> scratching 00:07:36.620 --> 00:07:36.630 align:start position:0% we'll see if I get around to scratching 00:07:36.630 --> 00:07:41.930 align:start position:0% we'll see if I get around to scratching that<00:07:38.030> yeah<00:07:39.030> I<00:07:40.040> think<00:07:41.040> I've<00:07:41.340> got<00:07:41.490> time<00:07:41.670> so<00:07:41.880> I'm 00:07:41.930 --> 00:07:41.940 align:start position:0% that yeah I think I've got time so I'm 00:07:41.940 --> 00:07:45.290 align:start position:0% that yeah I think I've got time so I'm gonna<00:07:42.060> do<00:07:42.210> this<00:07:42.300> section<00:07:42.570> as<00:07:42.810> well<00:07:43.460> as<00:07:44.460> well<00:07:45.270> as 00:07:45.290 --> 00:07:45.300 align:start position:0% gonna do this section as well as well as 00:07:45.300 --> 00:07:47.330 align:start position:0% gonna do this section as well as well as optimizing<00:07:45.840> for<00:07:46.170> performance<00:07:46.650> another<00:07:47.130> thing 00:07:47.330 --> 00:07:47.340 align:start position:0% optimizing for performance another thing 00:07:47.340 --> 00:07:49.370 align:start position:0% optimizing for performance another thing we<00:07:47.430> can<00:07:47.550> optimize<00:07:47.730> for<00:07:48.270> when<00:07:48.900> we're<00:07:49.020> making<00:07:49.290> an 00:07:49.370 --> 00:07:49.380 align:start position:0% we can optimize for when we're making an 00:07:49.380 --> 00:07:52.550 align:start position:0% we can optimize for when we're making an F<00:07:49.500> to<00:07:49.680> client<00:07:50.040> is<00:07:50.250> the<00:07:50.910> profit<00:07:51.330> that<00:07:51.600> the<00:07:51.870> that 00:07:52.550 --> 00:07:52.560 align:start position:0% F to client is the profit that the that 00:07:52.560 --> 00:07:54.950 align:start position:0% F to client is the profit that the that the<00:07:52.650> validator<00:07:53.070> will<00:07:53.370> bring<00:07:53.700> in<00:07:53.880> for<00:07:54.780> being<00:07:54.900> a 00:07:54.950 --> 00:07:54.960 align:start position:0% the validator will bring in for being a 00:07:54.960 --> 00:07:56.690 align:start position:0% the validator will bring in for being a validator<00:07:55.320> and<00:07:55.530> there's<00:07:56.130> one<00:07:56.280> interesting 00:07:56.690 --> 00:07:56.700 align:start position:0% validator and there's one interesting 00:07:56.700 --> 00:07:58.160 align:start position:0% validator and there's one interesting problem<00:07:56.970> here<00:07:57.150> that<00:07:57.180> caught<00:07:57.480> my<00:07:57.630> eye<00:07:57.660> a<00:07:57.810> few 00:07:58.160 --> 00:07:58.170 align:start position:0% problem here that caught my eye a few 00:07:58.170 --> 00:07:59.900 align:start position:0% problem here that caught my eye a few months<00:07:58.380> ago<00:07:58.470> and<00:07:58.770> I'm<00:07:58.890> maybe<00:07:59.310> a<00:07:59.400> bit<00:07:59.580> obsessed 00:07:59.900 --> 00:07:59.910 align:start position:0% months ago and I'm maybe a bit obsessed 00:07:59.910 --> 00:08:01.490 align:start position:0% months ago and I'm maybe a bit obsessed with<00:08:00.030> it<00:08:00.150> if<00:08:00.330> if<00:08:00.660> you<00:08:00.780> talk<00:08:00.960> to<00:08:01.080> anyone<00:08:01.290> around 00:08:01.490 --> 00:08:01.500 align:start position:0% with it if if you talk to anyone around 00:08:01.500 --> 00:08:05.360 align:start position:0% with it if if you talk to anyone around CP<00:08:02.150> and<00:08:03.150> that<00:08:03.870> is<00:08:04.020> the<00:08:04.230> attestation<00:08:04.620> inclusion 00:08:05.360 --> 00:08:05.370 align:start position:0% CP and that is the attestation inclusion 00:08:05.370 --> 00:08:08.870 align:start position:0% CP and that is the attestation inclusion problem<00:08:06.260> so<00:08:07.260> this<00:08:07.350> problem<00:08:07.590> is<00:08:07.830> kind<00:08:08.820> of 00:08:08.870 --> 00:08:08.880 align:start position:0% problem so this problem is kind of 00:08:08.880 --> 00:08:12.020 align:start position:0% problem so this problem is kind of leading<00:08:09.840> on<00:08:10.110> from<00:08:10.410> what<00:08:10.700> we<00:08:11.700> were<00:08:11.790> talking 00:08:12.020 --> 00:08:12.030 align:start position:0% leading on from what we were talking 00:08:12.030 --> 00:08:13.490 align:start position:0% leading on from what we were talking about<00:08:12.090> before<00:08:12.270> with<00:08:12.660> aggregating<00:08:13.320> out<00:08:13.380> of 00:08:13.490 --> 00:08:13.500 align:start position:0% about before with aggregating out of 00:08:13.500 --> 00:08:15.560 align:start position:0% about before with aggregating out of stations<00:08:13.860> is<00:08:14.070> if<00:08:14.610> you've<00:08:14.850> got<00:08:15.030> a<00:08:15.060> whole<00:08:15.330> bunch 00:08:15.560 --> 00:08:15.570 align:start position:0% stations is if you've got a whole bunch 00:08:15.570 --> 00:08:17.420 align:start position:0% stations is if you've got a whole bunch of<00:08:15.690> aggregation<00:08:16.410> if<00:08:16.980> you've<00:08:17.160> got<00:08:17.280> a<00:08:17.310> whole 00:08:17.420 --> 00:08:17.430 align:start position:0% of aggregation if you've got a whole 00:08:17.430 --> 00:08:18.980 align:start position:0% of aggregation if you've got a whole bunch<00:08:17.610> of<00:08:17.670> other<00:08:17.880> stations<00:08:18.360> from<00:08:18.540> the<00:08:18.690> network 00:08:18.980 --> 00:08:18.990 align:start position:0% bunch of other stations from the network 00:08:18.990 --> 00:08:21.500 align:start position:0% bunch of other stations from the network and<00:08:19.980> you've<00:08:20.130> got<00:08:20.310> more<00:08:20.610> than<00:08:20.850> you<00:08:20.940> can<00:08:21.120> fit<00:08:21.330> in 00:08:21.500 --> 00:08:21.510 align:start position:0% and you've got more than you can fit in 00:08:21.510 --> 00:08:24.620 align:start position:0% and you've got more than you can fit in a<00:08:21.600> single<00:08:21.930> block<00:08:22.910> deciding<00:08:23.910> which<00:08:24.120> ones<00:08:24.390> to 00:08:24.620 --> 00:08:24.630 align:start position:0% a single block deciding which ones to 00:08:24.630 --> 00:08:26.690 align:start position:0% a single block deciding which ones to include<00:08:25.020> in<00:08:25.260> the<00:08:25.380> block<00:08:25.590> such<00:08:26.370> that<00:08:26.610> you 00:08:26.690 --> 00:08:26.700 align:start position:0% include in the block such that you 00:08:26.700 --> 00:08:28.460 align:start position:0% include in the block such that you maximize<00:08:26.880> the<00:08:27.540> profit<00:08:27.900> that<00:08:28.050> you<00:08:28.110> get<00:08:28.320> from 00:08:28.460 --> 00:08:28.470 align:start position:0% maximize the profit that you get from 00:08:28.470 --> 00:08:30.590 align:start position:0% maximize the profit that you get from the<00:08:28.620> rewards<00:08:29.040> is<00:08:29.220> actually<00:08:30.180> an<00:08:30.270> np-hard 00:08:30.590 --> 00:08:30.600 align:start position:0% the rewards is actually an np-hard 00:08:30.600 --> 00:08:33.409 align:start position:0% the rewards is actually an np-hard problem<00:08:31.200> and<00:08:32.190> it's<00:08:32.460> an<00:08:32.580> instance<00:08:33.000> of<00:08:33.150> this 00:08:33.409 --> 00:08:33.419 align:start position:0% problem and it's an instance of this 00:08:33.419 --> 00:08:34.969 align:start position:0% problem and it's an instance of this classical<00:08:34.050> computer<00:08:34.410> science<00:08:34.710> problem 00:08:34.969 --> 00:08:34.979 align:start position:0% classical computer science problem 00:08:34.979 --> 00:08:38.719 align:start position:0% classical computer science problem called<00:08:35.280> maximum<00:08:36.090> coverage<00:08:37.010> and<00:08:38.010> just<00:08:38.400> to<00:08:38.520> show 00:08:38.719 --> 00:08:38.729 align:start position:0% called maximum coverage and just to show 00:08:38.729 --> 00:08:39.740 align:start position:0% called maximum coverage and just to show you<00:08:38.820> exactly<00:08:39.030> what<00:08:39.270> that<00:08:39.390> looks<00:08:39.539> like 00:08:39.740 --> 00:08:39.750 align:start position:0% you exactly what that looks like 00:08:39.750 --> 00:08:42.770 align:start position:0% you exactly what that looks like so<00:08:40.580> attestation<00:08:41.580> inclusion<00:08:42.180> says<00:08:42.419> something 00:08:42.770 --> 00:08:42.780 align:start position:0% so attestation inclusion says something 00:08:42.780 --> 00:08:45.410 align:start position:0% so attestation inclusion says something like<00:08:42.830> we<00:08:43.830> have<00:08:44.039> a<00:08:44.219> whole<00:08:44.400> bunch<00:08:44.640> of<00:08:44.850> other 00:08:45.410 --> 00:08:45.420 align:start position:0% like we have a whole bunch of other 00:08:45.420 --> 00:08:48.140 align:start position:0% like we have a whole bunch of other stations<00:08:45.750> n<00:08:46.050> data<00:08:46.410> stations<00:08:46.890> and<00:08:47.160> we<00:08:47.910> need<00:08:48.060> to 00:08:48.140 --> 00:08:48.150 align:start position:0% stations n data stations and we need to 00:08:48.150 --> 00:08:51.320 align:start position:0% stations n data stations and we need to find<00:08:48.390> a<00:08:48.660> subset<00:08:49.200> of<00:08:49.380> these<00:08:49.950> of<00:08:50.280> some<00:08:51.090> maximum 00:08:51.320 --> 00:08:51.330 align:start position:0% find a subset of these of some maximum 00:08:51.330 --> 00:08:54.470 align:start position:0% find a subset of these of some maximum size<00:08:51.840> such<00:08:52.710> that<00:08:52.980> the<00:08:53.160> sum<00:08:53.550> of<00:08:53.610> the<00:08:53.850> rewards<00:08:54.330> we 00:08:54.470 --> 00:08:54.480 align:start position:0% size such that the sum of the rewards we 00:08:54.480 --> 00:08:56.270 align:start position:0% size such that the sum of the rewards we get<00:08:54.660> for<00:08:54.930> all<00:08:54.960> the<00:08:55.380> validators<00:08:56.010> that<00:08:56.160> we've 00:08:56.270 --> 00:08:56.280 align:start position:0% get for all the validators that we've 00:08:56.280 --> 00:08:57.890 align:start position:0% get for all the validators that we've covered<00:08:56.550> with<00:08:57.000> those<00:08:57.120> outer<00:08:57.330> stations<00:08:57.750> is 00:08:57.890 --> 00:08:57.900 align:start position:0% covered with those outer stations is 00:08:57.900 --> 00:08:58.970 align:start position:0% covered with those outer stations is maximal 00:08:58.970 --> 00:08:58.980 align:start position:0% maximal 00:08:58.980 --> 00:09:01.390 align:start position:0% maximal and<00:08:59.240> the<00:09:00.240> abstract<00:09:00.780> version<00:09:01.050> of<00:09:01.140> this<00:09:01.200> problem 00:09:01.390 --> 00:09:01.400 align:start position:0% and the abstract version of this problem 00:09:01.400 --> 00:09:04.280 align:start position:0% and the abstract version of this problem weighted<00:09:02.400> maximum<00:09:02.850> coverage<00:09:03.150> says<00:09:03.480> we<00:09:04.140> have 00:09:04.280 --> 00:09:04.290 align:start position:0% weighted maximum coverage says we have 00:09:04.290 --> 00:09:06.680 align:start position:0% weighted maximum coverage says we have some<00:09:04.530> set<00:09:04.860> of<00:09:04.890> sets<00:09:05.400> and<00:09:05.700> we<00:09:06.000> need<00:09:06.150> to<00:09:06.270> find<00:09:06.480> a 00:09:06.680 --> 00:09:06.690 align:start position:0% some set of sets and we need to find a 00:09:06.690 --> 00:09:08.930 align:start position:0% some set of sets and we need to find a subset<00:09:07.200> of<00:09:07.230> those<00:09:07.470> sets<00:09:07.800> of<00:09:08.070> the<00:09:08.280> maximum<00:09:08.700> size 00:09:08.930 --> 00:09:08.940 align:start position:0% subset of those sets of the maximum size 00:09:08.940 --> 00:09:11.870 align:start position:0% subset of those sets of the maximum size so<00:09:09.570> that<00:09:09.600> when<00:09:09.960> we<00:09:10.080> Union<00:09:10.650> all<00:09:11.010> the<00:09:11.400> sets<00:09:11.670> in 00:09:11.870 --> 00:09:11.880 align:start position:0% so that when we Union all the sets in 00:09:11.880 --> 00:09:15.020 align:start position:0% so that when we Union all the sets in that<00:09:12.030> subset<00:09:12.510> together<00:09:12.900> the<00:09:13.740> combined<00:09:14.640> weight 00:09:15.020 --> 00:09:15.030 align:start position:0% that subset together the combined weight 00:09:15.030 --> 00:09:19.760 align:start position:0% that subset together the combined weight of<00:09:15.330> all<00:09:15.510> those<00:09:15.660> elements<00:09:15.870> is<00:09:16.290> maximal 00:09:19.760 --> 00:09:19.770 align:start position:0% 00:09:19.770 --> 00:09:21.800 align:start position:0% the<00:09:20.310> problem<00:09:20.610> with<00:09:20.730> np-hard<00:09:21.210> problems<00:09:21.600> is 00:09:21.800 --> 00:09:21.810 align:start position:0% the problem with np-hard problems is 00:09:21.810 --> 00:09:27.170 align:start position:0% the problem with np-hard problems is that<00:09:22.590> they're<00:09:22.800> hard<00:09:22.980> and<00:09:25.100> usually<00:09:26.180> solving 00:09:27.170 --> 00:09:27.180 align:start position:0% that they're hard and usually solving 00:09:27.180 --> 00:09:28.940 align:start position:0% that they're hard and usually solving them<00:09:27.300> exactly<00:09:27.600> requires<00:09:28.500> a<00:09:28.620> sort<00:09:28.920> of 00:09:28.940 --> 00:09:28.950 align:start position:0% them exactly requires a sort of 00:09:28.950 --> 00:09:30.770 align:start position:0% them exactly requires a sort of exponential<00:09:29.430> or<00:09:29.760> semi<00:09:30.060> exponential<00:09:30.660> time 00:09:30.770 --> 00:09:30.780 align:start position:0% exponential or semi exponential time 00:09:30.780 --> 00:09:34.040 align:start position:0% exponential or semi exponential time algorithm<00:09:31.370> so<00:09:32.370> for<00:09:32.910> now<00:09:33.060> we're<00:09:33.480> using<00:09:33.540> a 00:09:34.040 --> 00:09:34.050 align:start position:0% algorithm so for now we're using a 00:09:34.050 --> 00:09:36.200 align:start position:0% algorithm so for now we're using a greedy<00:09:34.470> algorithm<00:09:34.800> that<00:09:35.220> works<00:09:35.370> quite<00:09:35.760> simply 00:09:36.200 --> 00:09:36.210 align:start position:0% greedy algorithm that works quite simply 00:09:36.210 --> 00:09:39.550 align:start position:0% greedy algorithm that works quite simply by<00:09:36.960> just<00:09:37.560> starting<00:09:38.400> with<00:09:38.640> an<00:09:38.760> empty<00:09:38.970> solution 00:09:39.550 --> 00:09:39.560 align:start position:0% by just starting with an empty solution 00:09:39.560 --> 00:09:42.410 align:start position:0% by just starting with an empty solution looking<00:09:40.560> at<00:09:40.710> the<00:09:40.950> the<00:09:41.550> list<00:09:41.760> of<00:09:42.000> other 00:09:42.410 --> 00:09:42.420 align:start position:0% looking at the the list of other 00:09:42.420 --> 00:09:44.450 align:start position:0% looking at the the list of other stations<00:09:42.720> that<00:09:42.960> you've<00:09:43.140> got<00:09:43.350> and<00:09:43.560> greedily 00:09:44.450 --> 00:09:44.460 align:start position:0% stations that you've got and greedily 00:09:44.460 --> 00:09:46.340 align:start position:0% stations that you've got and greedily choosing<00:09:45.270> the<00:09:45.420> best<00:09:45.630> adder<00:09:45.870> stations 00:09:46.340 --> 00:09:46.350 align:start position:0% choosing the best adder stations 00:09:46.350 --> 00:09:48.020 align:start position:0% choosing the best adder stations repeatedly<00:09:46.980> and<00:09:47.160> adding<00:09:47.490> them<00:09:47.700> to<00:09:48.000> your 00:09:48.020 --> 00:09:48.030 align:start position:0% repeatedly and adding them to your 00:09:48.030 --> 00:09:50.780 align:start position:0% repeatedly and adding them to your solution<00:09:48.480> and<00:09:48.870> so<00:09:49.860> the<00:09:49.980> best<00:09:50.190> data<00:09:50.370> stations 00:09:50.780 --> 00:09:50.790 align:start position:0% solution and so the best data stations 00:09:50.790 --> 00:09:52.550 align:start position:0% solution and so the best data stations are<00:09:51.240> going<00:09:51.480> to<00:09:51.540> be<00:09:51.600> the<00:09:51.690> ones<00:09:51.840> that<00:09:51.960> cover<00:09:52.230> new 00:09:52.550 --> 00:09:52.560 align:start position:0% are going to be the ones that cover new 00:09:52.560 --> 00:09:54.260 align:start position:0% are going to be the ones that cover new validators<00:09:53.130> that<00:09:53.310> are<00:09:53.400> not<00:09:53.520> yet<00:09:53.640> covered<00:09:53.880> by 00:09:54.260 --> 00:09:54.270 align:start position:0% validators that are not yet covered by 00:09:54.270 --> 00:09:56.330 align:start position:0% validators that are not yet covered by other<00:09:54.930> stations<00:09:55.380> included<00:09:55.800> on<00:09:55.890> chain<00:09:56.160> or 00:09:56.330 --> 00:09:56.340 align:start position:0% other stations included on chain or 00:09:56.340 --> 00:09:57.800 align:start position:0% other stations included on chain or adder<00:09:56.490> stations<00:09:56.910> already<00:09:57.300> in<00:09:57.390> your<00:09:57.510> solution 00:09:57.800 --> 00:09:57.810 align:start position:0% adder stations already in your solution 00:09:57.810 --> 00:10:00.950 align:start position:0% adder stations already in your solution and<00:09:58.140> that<00:09:59.070> include<00:09:59.700> of<00:09:59.940> those<00:10:00.300> validators<00:10:00.840> the 00:10:00.950 --> 00:10:00.960 align:start position:0% and that include of those validators the 00:10:00.960 --> 00:10:02.630 align:start position:0% and that include of those validators the ones<00:10:01.110> that<00:10:01.230> include<00:10:01.350> the<00:10:01.650> most<00:10:01.800> high<00:10:02.160> balanced 00:10:02.630 --> 00:10:02.640 align:start position:0% ones that include the most high balanced 00:10:02.640 --> 00:10:04.310 align:start position:0% ones that include the most high balanced validators<00:10:03.390> because<00:10:03.600> the<00:10:03.750> reward<00:10:04.080> that<00:10:04.170> you 00:10:04.310 --> 00:10:04.320 align:start position:0% validators because the reward that you 00:10:04.320 --> 00:10:07.460 align:start position:0% validators because the reward that you get<00:10:04.470> paid<00:10:04.710> is<00:10:05.150> proportional<00:10:06.150> to<00:10:06.450> the<00:10:06.690> balance 00:10:07.460 --> 00:10:07.470 align:start position:0% get paid is proportional to the balance 00:10:07.470 --> 00:10:09.380 align:start position:0% get paid is proportional to the balance of<00:10:07.650> the<00:10:07.920> validator<00:10:08.310> who's<00:10:08.700> at<00:10:08.910> a<00:10:08.940> station<00:10:09.300> you 00:10:09.380 --> 00:10:09.390 align:start position:0% of the validator who's at a station you 00:10:09.390 --> 00:10:13.820 align:start position:0% of the validator who's at a station you include<00:10:11.090> this<00:10:12.090> greedy<00:10:12.750> algorithm<00:10:13.020> performs 00:10:13.820 --> 00:10:13.830 align:start position:0% include this greedy algorithm performs 00:10:13.830 --> 00:10:16.550 align:start position:0% include this greedy algorithm performs quite<00:10:14.010> well<00:10:14.330> within<00:10:15.330> a<00:10:15.510> factor<00:10:15.870> of<00:10:15.900> one<00:10:16.170> minus 00:10:16.550 --> 00:10:16.560 align:start position:0% quite well within a factor of one minus 00:10:16.560 --> 00:10:19.370 align:start position:0% quite well within a factor of one minus one<00:10:16.710> on<00:10:16.860> a<00:10:17.100> of<00:10:17.340> optimality<00:10:17.880> so<00:10:18.330> it's<00:10:19.170> always 00:10:19.370 --> 00:10:19.380 align:start position:0% one on a of optimality so it's always 00:10:19.380 --> 00:10:21.950 align:start position:0% one on a of optimality so it's always going<00:10:19.650> to<00:10:19.740> get<00:10:19.890> you<00:10:19.980> at<00:10:20.130> least<00:10:20.390> 63<00:10:21.390> percent<00:10:21.840> of 00:10:21.950 --> 00:10:21.960 align:start position:0% going to get you at least 63 percent of 00:10:21.960 --> 00:10:23.510 align:start position:0% going to get you at least 63 percent of the<00:10:22.110> maximum<00:10:22.500> reward<00:10:22.680> that<00:10:23.010> you<00:10:23.100> could<00:10:23.340> get 00:10:23.510 --> 00:10:23.520 align:start position:0% the maximum reward that you could get 00:10:23.520 --> 00:10:26.360 align:start position:0% the maximum reward that you could get and<00:10:24.110> in<00:10:25.110> a<00:10:25.350> lot<00:10:25.500> of<00:10:25.530> cases<00:10:25.770> it<00:10:25.980> will<00:10:26.070> do<00:10:26.190> better 00:10:26.360 --> 00:10:26.370 align:start position:0% and in a lot of cases it will do better 00:10:26.370 --> 00:10:26.870 align:start position:0% and in a lot of cases it will do better than<00:10:26.550> that 00:10:26.870 --> 00:10:26.880 align:start position:0% than that 00:10:26.880 --> 00:10:28.700 align:start position:0% than that there's<00:10:27.090> the<00:10:27.420> sort<00:10:27.720> of<00:10:27.750> pathological<00:10:28.230> cases 00:10:28.700 --> 00:10:28.710 align:start position:0% there's the sort of pathological cases 00:10:28.710 --> 00:10:31.010 align:start position:0% there's the sort of pathological cases that<00:10:29.040> hit<00:10:29.280> this<00:10:29.460> lower<00:10:29.850> bound<00:10:30.060> a<00:10:30.300> kind<00:10:30.900> of 00:10:31.010 --> 00:10:31.020 align:start position:0% that hit this lower bound a kind of 00:10:31.020 --> 00:10:34.430 align:start position:0% that hit this lower bound a kind of unusual<00:10:31.790> but<00:10:32.790> nonetheless<00:10:33.270> I<00:10:33.750> would<00:10:34.110> like<00:10:34.290> to 00:10:34.430 --> 00:10:34.440 align:start position:0% unusual but nonetheless I would like to 00:10:34.440 --> 00:10:36.950 align:start position:0% unusual but nonetheless I would like to look<00:10:34.560> into<00:10:34.740> doing<00:10:35.010> some<00:10:35.400> exact<00:10:35.790> solving<00:10:36.210> using 00:10:36.950 --> 00:10:36.960 align:start position:0% look into doing some exact solving using 00:10:36.960 --> 00:10:38.840 align:start position:0% look into doing some exact solving using integer<00:10:37.800> linear<00:10:37.860> programming<00:10:38.400> at<00:10:38.550> some<00:10:38.700> point 00:10:38.840 --> 00:10:38.850 align:start position:0% integer linear programming at some point 00:10:38.850 --> 00:10:40.060 align:start position:0% integer linear programming at some point in<00:10:38.910> the<00:10:38.970> future<00:10:39.060> I<00:10:39.240> think<00:10:39.300> that<00:10:39.540> could<00:10:39.690> be<00:10:39.780> fun 00:10:40.060 --> 00:10:40.070 align:start position:0% in the future I think that could be fun 00:10:40.070 --> 00:10:42.590 align:start position:0% in the future I think that could be fun but<00:10:41.070> it<00:10:41.190> might<00:10:41.370> require<00:10:41.550> kind<00:10:42.000> of<00:10:42.090> scheduling 00:10:42.590 --> 00:10:42.600 align:start position:0% but it might require kind of scheduling 00:10:42.600 --> 00:10:45.110 align:start position:0% but it might require kind of scheduling your<00:10:42.810> block<00:10:43.440> production<00:10:44.100> well<00:10:44.370> in<00:10:44.490> advance<00:10:44.820> of 00:10:45.110 --> 00:10:45.120 align:start position:0% your block production well in advance of 00:10:45.120 --> 00:10:46.730 align:start position:0% your block production well in advance of when<00:10:45.240> you<00:10:45.390> actually<00:10:45.750> need<00:10:45.900> to<00:10:45.930> produce<00:10:46.260> the 00:10:46.730 --> 00:10:46.740 align:start position:0% when you actually need to produce the 00:10:46.740 --> 00:10:51.200 align:start position:0% when you actually need to produce the block<00:10:47.310> which<00:10:47.490> could<00:10:47.700> be<00:10:47.850> not<00:10:48.150> so<00:10:48.300> good<00:10:49.910> yeah<00:10:50.910> so 00:10:51.200 --> 00:10:51.210 align:start position:0% block which could be not so good yeah so 00:10:51.210 --> 00:10:54.230 align:start position:0% block which could be not so good yeah so in<00:10:51.450> conclusion<00:10:52.250> optimizing<00:10:53.250> s<00:10:53.430> 2<00:10:53.670> is<00:10:53.910> a<00:10:53.940> lot<00:10:54.150> of 00:10:54.230 --> 00:10:54.240 align:start position:0% in conclusion optimizing s 2 is a lot of 00:10:54.240 --> 00:10:56.030 align:start position:0% in conclusion optimizing s 2 is a lot of fun<00:10:54.480> and<00:10:54.690> all<00:10:55.350> the<00:10:55.530> clients<00:10:55.860> should 00:10:56.030 --> 00:10:56.040 align:start position:0% fun and all the clients should 00:10:56.040 --> 00:10:57.440 align:start position:0% fun and all the clients should definitely<00:10:56.400> be<00:10:56.550> doing<00:10:56.820> it<00:10:56.910> and<00:10:57.060> I'm<00:10:57.120> sure<00:10:57.150> they 00:10:57.440 --> 00:10:57.450 align:start position:0% definitely be doing it and I'm sure they 00:10:57.450 --> 00:11:01.880 align:start position:0% definitely be doing it and I'm sure they are<00:10:59.000> there's<00:11:00.000> a<00:11:00.060> link<00:11:00.330> between<00:11:00.890> performance 00:11:01.880 --> 00:11:01.890 align:start position:0% are there's a link between performance 00:11:01.890 --> 00:11:04.490 align:start position:0% are there's a link between performance and<00:11:02.100> security<00:11:02.750> so<00:11:03.750> avoiding<00:11:04.170> denial<00:11:04.410> of 00:11:04.490 --> 00:11:04.500 align:start position:0% and security so avoiding denial of 00:11:04.500 --> 00:11:07.250 align:start position:0% and security so avoiding denial of service<00:11:04.770> optimization<00:11:05.460> is<00:11:05.550> important<00:11:06.000> and<00:11:06.260> if 00:11:07.250 --> 00:11:07.260 align:start position:0% service optimization is important and if 00:11:07.260 --> 00:11:09.140 align:start position:0% service optimization is important and if we<00:11:07.770> are<00:11:07.890> all<00:11:08.010> optimizing<00:11:08.640> and<00:11:08.790> writing<00:11:08.970> things 00:11:09.140 --> 00:11:09.150 align:start position:0% we are all optimizing and writing things 00:11:09.150 --> 00:11:10.250 align:start position:0% we are all optimizing and writing things in<00:11:09.240> different<00:11:09.390> ways<00:11:09.600> there's<00:11:09.840> a<00:11:09.900> chance<00:11:10.110> we 00:11:10.250 --> 00:11:10.260 align:start position:0% in different ways there's a chance we 00:11:10.260 --> 00:11:12.240 align:start position:0% in different ways there's a chance we might<00:11:10.290> find<00:11:10.800> some<00:11:10.950> more<00:11:11.010> spec<00:11:11.430> bugs<00:11:11.670> which<00:11:12.000> you 00:11:12.240 --> 00:11:12.250 align:start position:0% might find some more spec bugs which you 00:11:12.250 --> 00:11:14.880 align:start position:0% might find some more spec bugs which you lots<00:11:12.700> of<00:11:12.790> fun<00:11:12.940> sir<00:11:13.300> thank<00:11:14.020> you<00:11:14.080> very<00:11:14.200> much 00:11:14.880 --> 00:11:14.890 align:start position:0% lots of fun sir thank you very much 00:11:14.890 --> 00:11:27.180 align:start position:0% lots of fun sir thank you very much [Applause] 00:11:27.180 --> 00:11:27.190 align:start position:0% 00:11:27.190 --> 00:11:29.250 align:start position:0% you