WEBVTT Kind: captions Language: en 00:00:00.000 --> 00:00:04.350 align:start position:0% foreign 00:00:04.350 --> 00:00:04.360 align:start position:0% 00:00:04.360 --> 00:00:13.549 align:start position:0% [Music] 00:00:13.549 --> 00:00:13.559 align:start position:0% 00:00:13.559 --> 00:00:14.930 align:start position:0% so<00:00:13.980> in<00:00:14.040> my<00:00:14.219> talk<00:00:14.340> today<00:00:14.519> I'm<00:00:14.700> going<00:00:14.820> to<00:00:14.880> be 00:00:14.930 --> 00:00:14.940 align:start position:0% so in my talk today I'm going to be 00:00:14.940 --> 00:00:16.910 align:start position:0% so in my talk today I'm going to be talking<00:00:15.059> for<00:00:15.420> the<00:00:15.540> first<00:00:15.660> time<00:00:15.839> about 00:00:16.910 --> 00:00:16.920 align:start position:0% talking for the first time about 00:00:16.920 --> 00:00:19.730 align:start position:0% talking for the first time about um<00:00:17.340> how<00:00:18.180> we've<00:00:18.480> designed<00:00:18.840> a<00:00:19.080> polygon<00:00:19.440> Milan 00:00:19.730 --> 00:00:19.740 align:start position:0% um how we've designed a polygon Milan 00:00:19.740 --> 00:00:21.410 align:start position:0% um how we've designed a polygon Milan roll<00:00:19.859> up<00:00:20.039> and<00:00:20.220> specifically<00:00:20.580> how<00:00:20.820> we<00:00:21.000> use<00:00:21.180> this 00:00:21.410 --> 00:00:21.420 align:start position:0% roll up and specifically how we use this 00:00:21.420 --> 00:00:23.269 align:start position:0% roll up and specifically how we use this hybrid<00:00:21.720> utx<00:00:22.199> or<00:00:22.380> an<00:00:22.500> account<00:00:22.619> based<00:00:22.980> model<00:00:23.039> to 00:00:23.269 --> 00:00:23.279 align:start position:0% hybrid utx or an account based model to 00:00:23.279 --> 00:00:25.070 align:start position:0% hybrid utx or an account based model to achieve<00:00:23.580> some<00:00:23.699> interesting<00:00:24.060> properties 00:00:25.070 --> 00:00:25.080 align:start position:0% achieve some interesting properties 00:00:25.080 --> 00:00:27.910 align:start position:0% achieve some interesting properties so<00:00:25.980> just<00:00:26.160> to<00:00:26.340> set<00:00:26.460> the<00:00:26.580> context<00:00:26.880> at<00:00:27.119> first 00:00:27.910 --> 00:00:27.920 align:start position:0% so just to set the context at first 00:00:27.920 --> 00:00:30.589 align:start position:0% so just to set the context at first the<00:00:28.920> goal<00:00:29.220> that<00:00:29.580> we<00:00:29.699> have<00:00:29.820> in<00:00:30.000> mind<00:00:30.119> is<00:00:30.300> we<00:00:30.480> want 00:00:30.589 --> 00:00:30.599 align:start position:0% the goal that we have in mind is we want 00:00:30.599 --> 00:00:31.849 align:start position:0% the goal that we have in mind is we want to<00:00:30.720> build<00:00:30.779> a<00:00:31.019> scalable<00:00:31.320> decentralized 00:00:31.849 --> 00:00:31.859 align:start position:0% to build a scalable decentralized 00:00:31.859 --> 00:00:33.590 align:start position:0% to build a scalable decentralized roll-up<00:00:32.220> with<00:00:32.460> privacy<00:00:33.239> enabling 00:00:33.590 --> 00:00:33.600 align:start position:0% roll-up with privacy enabling 00:00:33.600 --> 00:00:35.510 align:start position:0% roll-up with privacy enabling architecture<00:00:34.200> and<00:00:34.800> what<00:00:34.920> I<00:00:34.980> mean<00:00:35.100> by<00:00:35.219> that<00:00:35.399> is 00:00:35.510 --> 00:00:35.520 align:start position:0% architecture and what I mean by that is 00:00:35.520 --> 00:00:37.130 align:start position:0% architecture and what I mean by that is that<00:00:35.700> our<00:00:35.940> immediate<00:00:36.300> goal<00:00:36.600> is<00:00:36.719> to<00:00:36.899> achieve 00:00:37.130 --> 00:00:37.140 align:start position:0% that our immediate goal is to achieve 00:00:37.140 --> 00:00:38.930 align:start position:0% that our immediate goal is to achieve scaling<00:00:37.559> but<00:00:37.980> we<00:00:38.160> want<00:00:38.280> to<00:00:38.399> design<00:00:38.520> the<00:00:38.700> role 00:00:38.930 --> 00:00:38.940 align:start position:0% scaling but we want to design the role 00:00:38.940 --> 00:00:40.130 align:start position:0% scaling but we want to design the role up<00:00:39.059> in<00:00:39.120> such<00:00:39.239> a<00:00:39.360> way<00:00:39.480> that<00:00:39.600> when<00:00:39.780> we<00:00:39.899> want<00:00:40.020> to 00:00:40.130 --> 00:00:40.140 align:start position:0% up in such a way that when we want to 00:00:40.140 --> 00:00:42.170 align:start position:0% up in such a way that when we want to turn<00:00:40.260> on<00:00:40.379> privacy<00:00:40.739> it<00:00:40.980> will<00:00:41.160> not<00:00:41.280> require<00:00:41.520> a 00:00:42.170 --> 00:00:42.180 align:start position:0% turn on privacy it will not require a 00:00:42.180 --> 00:00:43.910 align:start position:0% turn on privacy it will not require a complete<00:00:42.660> architecture<00:00:43.020> overhaul<00:00:43.500> it<00:00:43.739> should 00:00:43.910 --> 00:00:43.920 align:start position:0% complete architecture overhaul it should 00:00:43.920 --> 00:00:47.150 align:start position:0% complete architecture overhaul it should be<00:00:44.040> very<00:00:44.460> easy<00:00:44.700> to<00:00:44.879> achieve<00:00:45.180> that 00:00:47.150 --> 00:00:47.160 align:start position:0% be very easy to achieve that 00:00:47.160 --> 00:00:48.950 align:start position:0% be very easy to achieve that um<00:00:47.219> and<00:00:47.700> I'm<00:00:47.879> sure<00:00:48.059> a<00:00:48.300> lot<00:00:48.360> of<00:00:48.420> you<00:00:48.539> here<00:00:48.780> are 00:00:48.950 --> 00:00:48.960 align:start position:0% um and I'm sure a lot of you here are 00:00:48.960 --> 00:00:50.330 align:start position:0% um and I'm sure a lot of you here are already<00:00:49.079> familiar<00:00:49.559> with<00:00:49.680> this<00:00:49.860> but<00:00:50.039> just<00:00:50.219> to 00:00:50.330 --> 00:00:50.340 align:start position:0% already familiar with this but just to 00:00:50.340 --> 00:00:51.709 align:start position:0% already familiar with this but just to set<00:00:50.460> a<00:00:50.579> context<00:00:50.820> of<00:00:50.940> what<00:00:51.120> is<00:00:51.239> a<00:00:51.360> decentralized 00:00:51.709 --> 00:00:51.719 align:start position:0% set a context of what is a decentralized 00:00:51.719 --> 00:00:54.410 align:start position:0% set a context of what is a decentralized roll<00:00:51.960> up<00:00:52.140> we<00:00:52.800> have<00:00:52.980> users<00:00:53.340> we<00:00:53.879> have<00:00:54.000> rollup 00:00:54.410 --> 00:00:54.420 align:start position:0% roll up we have users we have rollup 00:00:54.420 --> 00:00:55.549 align:start position:0% roll up we have users we have rollup operators 00:00:55.549 --> 00:00:55.559 align:start position:0% operators 00:00:55.559 --> 00:00:58.610 align:start position:0% operators um<00:00:55.620> and<00:00:56.160> we<00:00:56.280> have<00:00:56.399> ethereum<00:00:56.820> L1<00:00:57.300> and<00:00:57.960> in<00:00:58.500> this 00:00:58.610 --> 00:00:58.620 align:start position:0% um and we have ethereum L1 and in this 00:00:58.620 --> 00:01:01.250 align:start position:0% um and we have ethereum L1 and in this model<00:00:59.180> users<00:01:00.180> and<00:01:00.420> transactions<00:01:00.899> to<00:01:01.079> The 00:01:01.250 --> 00:01:01.260 align:start position:0% model users and transactions to The 00:01:01.260 --> 00:01:02.810 align:start position:0% model users and transactions to The Operators<00:01:01.680> operators<00:01:02.219> aggregate<00:01:02.640> those 00:01:02.810 --> 00:01:02.820 align:start position:0% Operators operators aggregate those 00:01:02.820 --> 00:01:04.670 align:start position:0% Operators operators aggregate those transactions<00:01:03.180> into<00:01:03.359> blocks<00:01:03.840> and<00:01:04.440> then<00:01:04.500> they 00:01:04.670 --> 00:01:04.680 align:start position:0% transactions into blocks and then they 00:01:04.680 --> 00:01:06.350 align:start position:0% transactions into blocks and then they submit<00:01:05.040> kind<00:01:05.220> of<00:01:05.339> the<00:01:05.400> state<00:01:05.580> Delta<00:01:06.060> in<00:01:06.180> a 00:01:06.350 --> 00:01:06.360 align:start position:0% submit kind of the state Delta in a 00:01:06.360 --> 00:01:08.210 align:start position:0% submit kind of the state Delta in a context<00:01:06.600> of<00:01:06.720> a<00:01:06.840> ZK<00:01:07.080> roll<00:01:07.260> up<00:01:07.439> with<00:01:07.560> a<00:01:07.680> ZK<00:01:07.979> proof 00:01:08.210 --> 00:01:08.220 align:start position:0% context of a ZK roll up with a ZK proof 00:01:08.220 --> 00:01:10.670 align:start position:0% context of a ZK roll up with a ZK proof to<00:01:08.400> A3<00:01:08.700> ml1<00:01:09.119> and<00:01:10.020> then 00:01:10.670 --> 00:01:10.680 align:start position:0% to A3 ml1 and then 00:01:10.680 --> 00:01:13.730 align:start position:0% to A3 ml1 and then um<00:01:11.240> uh<00:01:12.240> what<00:01:12.600> we<00:01:12.720> get<00:01:12.900> and<00:01:13.200> this<00:01:13.380> is<00:01:13.560> not 00:01:13.730 --> 00:01:13.740 align:start position:0% um uh what we get and this is not 00:01:13.740 --> 00:01:15.170 align:start position:0% um uh what we get and this is not specific<00:01:13.979> to<00:01:14.159> a<00:01:14.280> decentralized<00:01:14.640> roll-up<00:01:15.000> this 00:01:15.170 --> 00:01:15.180 align:start position:0% specific to a decentralized roll-up this 00:01:15.180 --> 00:01:17.990 align:start position:0% specific to a decentralized roll-up this is<00:01:15.299> a<00:01:15.479> true<00:01:15.600> for<00:01:15.780> any<00:01:15.900> roll-up<00:01:16.580> we<00:01:17.580> inherit 00:01:17.990 --> 00:01:18.000 align:start position:0% is a true for any roll-up we inherit 00:01:18.000 --> 00:01:19.910 align:start position:0% is a true for any roll-up we inherit security<00:01:18.119> from<00:01:18.479> ethereum 00:01:19.910 --> 00:01:19.920 align:start position:0% security from ethereum 00:01:19.920 --> 00:01:21.950 align:start position:0% security from ethereum um<00:01:19.979> what<00:01:20.759> is<00:01:20.880> specific<00:01:21.180> for<00:01:21.360> a<00:01:21.479> decentralized 00:01:21.950 --> 00:01:21.960 align:start position:0% um what is specific for a decentralized 00:01:21.960 --> 00:01:24.050 align:start position:0% um what is specific for a decentralized rollup<00:01:22.259> is<00:01:22.439> that<00:01:22.619> a<00:01:22.860> roll-up<00:01:23.220> is<00:01:23.460> has<00:01:23.700> its<00:01:24.000> own 00:01:24.050 --> 00:01:24.060 align:start position:0% rollup is that a roll-up is has its own 00:01:24.060 --> 00:01:27.109 align:start position:0% rollup is that a roll-up is has its own L2<00:01:24.540> chain<00:01:25.200> and<00:01:25.680> it's<00:01:26.220> um<00:01:26.220> its<00:01:26.700> own<00:01:26.759> consensus 00:01:27.109 --> 00:01:27.119 align:start position:0% L2 chain and it's um its own consensus 00:01:27.119 --> 00:01:28.730 align:start position:0% L2 chain and it's um its own consensus mechanism<00:01:27.540> because<00:01:27.780> the<00:01:28.020> operators<00:01:28.439> need<00:01:28.680> to 00:01:28.730 --> 00:01:28.740 align:start position:0% mechanism because the operators need to 00:01:28.740 --> 00:01:31.010 align:start position:0% mechanism because the operators need to agree<00:01:29.100> on<00:01:29.700> the<00:01:29.820> state<00:01:30.000> of<00:01:30.180> the<00:01:30.299> of<00:01:30.600> the<00:01:30.840> chain 00:01:31.010 --> 00:01:31.020 align:start position:0% agree on the state of the of the chain 00:01:31.020 --> 00:01:33.170 align:start position:0% agree on the state of the of the chain and<00:01:31.740> then<00:01:31.799> we<00:01:32.100> want<00:01:32.220> to<00:01:32.340> have<00:01:32.520> these<00:01:32.820> operators 00:01:33.170 --> 00:01:33.180 align:start position:0% and then we want to have these operators 00:01:33.180 --> 00:01:35.210 align:start position:0% and then we want to have these operators to<00:01:33.479> be<00:01:33.720> the<00:01:34.380> set<00:01:34.560> of<00:01:34.680> operators<00:01:34.979> to<00:01:35.159> be 00:01:35.210 --> 00:01:35.220 align:start position:0% to be the set of operators to be 00:01:35.220 --> 00:01:36.649 align:start position:0% to be the set of operators to be permissionless<00:01:35.640> meaning<00:01:35.880> anybody<00:01:36.240> can<00:01:36.420> join 00:01:36.649 --> 00:01:36.659 align:start position:0% permissionless meaning anybody can join 00:01:36.659 --> 00:01:39.890 align:start position:0% permissionless meaning anybody can join and<00:01:36.780> leave<00:01:36.960> the<00:01:37.140> set<00:01:37.259> as<00:01:37.560> they<00:01:37.680> please 00:01:39.890 --> 00:01:39.900 align:start position:0% 00:01:39.900 --> 00:01:41.870 align:start position:0% um now<00:01:40.200> compared<00:01:40.619> to<00:01:40.740> a<00:01:41.040> centralized<00:01:41.520> roll-up 00:01:41.870 --> 00:01:41.880 align:start position:0% um now compared to a centralized roll-up 00:01:41.880 --> 00:01:44.149 align:start position:0% um now compared to a centralized roll-up where<00:01:42.060> we<00:01:42.240> have<00:01:42.360> only<00:01:42.479> one<00:01:42.659> operator<00:01:43.159> a 00:01:44.149 --> 00:01:44.159 align:start position:0% where we have only one operator a 00:01:44.159 --> 00:01:45.410 align:start position:0% where we have only one operator a decentralized<00:01:44.579> rollup<00:01:45.000> has<00:01:45.119> a<00:01:45.180> number<00:01:45.299> of 00:01:45.410 --> 00:01:45.420 align:start position:0% decentralized rollup has a number of 00:01:45.420 --> 00:01:46.850 align:start position:0% decentralized rollup has a number of challenges<00:01:45.780> and<00:01:46.020> the<00:01:46.200> most<00:01:46.259> important<00:01:46.560> ones 00:01:46.850 --> 00:01:46.860 align:start position:0% challenges and the most important ones 00:01:46.860 --> 00:01:47.870 align:start position:0% challenges and the most important ones are 00:01:47.870 --> 00:01:47.880 align:start position:0% are 00:01:47.880 --> 00:01:49.130 align:start position:0% are um<00:01:47.939> you<00:01:48.119> know<00:01:48.180> you<00:01:48.420> need<00:01:48.600> to<00:01:48.720> have<00:01:48.840> a<00:01:48.960> separate 00:01:49.130 --> 00:01:49.140 align:start position:0% um you know you need to have a separate 00:01:49.140 --> 00:01:51.109 align:start position:0% um you know you need to have a separate consensus<00:01:49.560> mechanism 00:01:51.109 --> 00:01:51.119 align:start position:0% consensus mechanism 00:01:51.119 --> 00:01:53.090 align:start position:0% consensus mechanism um<00:01:51.180> you<00:01:51.420> need<00:01:51.540> you<00:01:51.899> also<00:01:52.140> have<00:01:52.259> this<00:01:52.619> execution 00:01:53.090 --> 00:01:53.100 align:start position:0% um you need you also have this execution 00:01:53.100 --> 00:01:54.590 align:start position:0% um you need you also have this execution bloat<00:01:53.460> problem<00:01:53.579> and<00:01:53.820> I'll<00:01:53.939> explain<00:01:54.119> what<00:01:54.420> it 00:01:54.590 --> 00:01:54.600 align:start position:0% bloat problem and I'll explain what it 00:01:54.600 --> 00:01:57.350 align:start position:0% bloat problem and I'll explain what it is<00:01:54.720> in<00:01:55.380> a<00:01:55.619> couple<00:01:55.860> of<00:01:56.040> seconds<00:01:56.340> and<00:01:57.119> then<00:01:57.240> you 00:01:57.350 --> 00:01:57.360 align:start position:0% is in a couple of seconds and then you 00:01:57.360 --> 00:02:00.170 align:start position:0% is in a couple of seconds and then you have<00:01:57.479> a<00:01:57.540> state<00:01:57.659> load<00:01:58.020> problem<00:01:58.680> so<00:01:59.100> in<00:01:59.280> this<00:01:59.579> uh 00:02:00.170 --> 00:02:00.180 align:start position:0% have a state load problem so in this uh 00:02:00.180 --> 00:02:01.730 align:start position:0% have a state load problem so in this uh talk<00:02:00.479> in<00:02:00.960> this<00:02:01.020> talk<00:02:01.140> I'm<00:02:01.380> going<00:02:01.500> to<00:02:01.560> talk 00:02:01.730 --> 00:02:01.740 align:start position:0% talk in this talk I'm going to talk 00:02:01.740 --> 00:02:03.469 align:start position:0% talk in this talk I'm going to talk about<00:02:01.860> specifically<00:02:02.579> execution<00:02:02.939> bloat<00:02:03.360> and 00:02:03.469 --> 00:02:03.479 align:start position:0% about specifically execution bloat and 00:02:03.479 --> 00:02:05.990 align:start position:0% about specifically execution bloat and state<00:02:03.600> load<00:02:03.960> and<00:02:04.860> so<00:02:05.159> let's<00:02:05.340> get<00:02:05.579> into<00:02:05.700> it<00:02:05.880> so 00:02:05.990 --> 00:02:06.000 align:start position:0% state load and so let's get into it so 00:02:06.000 --> 00:02:08.570 align:start position:0% state load and so let's get into it so what<00:02:06.299> is<00:02:06.479> execution<00:02:07.259> bloat<00:02:07.680> an<00:02:08.160> execution 00:02:08.570 --> 00:02:08.580 align:start position:0% what is execution bloat an execution 00:02:08.580 --> 00:02:09.830 align:start position:0% what is execution bloat an execution load<00:02:08.940> basically<00:02:09.179> means<00:02:09.420> that<00:02:09.539> the<00:02:09.660> network 00:02:09.830 --> 00:02:09.840 align:start position:0% load basically means that the network 00:02:09.840 --> 00:02:11.570 align:start position:0% load basically means that the network needs<00:02:10.200> to<00:02:10.319> execute<00:02:10.739> all<00:02:10.920> the<00:02:11.039> transactions 00:02:11.570 --> 00:02:11.580 align:start position:0% needs to execute all the transactions 00:02:11.580 --> 00:02:13.850 align:start position:0% needs to execute all the transactions and<00:02:11.940> more<00:02:12.120> specifically<00:02:12.599> a<00:02:13.260> block<00:02:13.440> producer 00:02:13.850 --> 00:02:13.860 align:start position:0% and more specifically a block producer 00:02:13.860 --> 00:02:15.229 align:start position:0% and more specifically a block producer needs<00:02:14.160> to<00:02:14.220> execute<00:02:14.459> on<00:02:14.580> the<00:02:14.760> transactions<00:02:15.120> in 00:02:15.229 --> 00:02:15.239 align:start position:0% needs to execute on the transactions in 00:02:15.239 --> 00:02:17.930 align:start position:0% needs to execute on the transactions in the<00:02:15.420> block<00:02:15.540> but<00:02:16.319> also<00:02:16.739> everybody<00:02:17.340> else<00:02:17.640> in<00:02:17.819> the 00:02:17.930 --> 00:02:17.940 align:start position:0% the block but also everybody else in the 00:02:17.940 --> 00:02:19.250 align:start position:0% the block but also everybody else in the network<00:02:18.120> needs<00:02:18.480> to<00:02:18.540> re-execute<00:02:19.140> the 00:02:19.250 --> 00:02:19.260 align:start position:0% network needs to re-execute the 00:02:19.260 --> 00:02:20.510 align:start position:0% network needs to re-execute the transactions<00:02:19.620> to<00:02:19.739> make<00:02:19.860> sure<00:02:19.980> that<00:02:20.099> block<00:02:20.340> is 00:02:20.510 --> 00:02:20.520 align:start position:0% transactions to make sure that block is 00:02:20.520 --> 00:02:22.610 align:start position:0% transactions to make sure that block is valid<00:02:20.819> and<00:02:21.420> you<00:02:21.599> know<00:02:21.720> that<00:02:21.900> leads<00:02:22.319> to<00:02:22.379> a<00:02:22.560> lot 00:02:22.610 --> 00:02:22.620 align:start position:0% valid and you know that leads to a lot 00:02:22.620 --> 00:02:24.050 align:start position:0% valid and you know that leads to a lot of<00:02:22.680> free<00:02:22.800> executing<00:02:23.280> the<00:02:23.400> same<00:02:23.520> code<00:02:23.640> over<00:02:23.879> and 00:02:24.050 --> 00:02:24.060 align:start position:0% of free executing the same code over and 00:02:24.060 --> 00:02:26.869 align:start position:0% of free executing the same code over and over<00:02:24.180> again<00:02:24.379> what<00:02:25.379> is<00:02:25.500> State<00:02:25.620> load<00:02:25.980> I'm<00:02:26.580> sure<00:02:26.760> a 00:02:26.869 --> 00:02:26.879 align:start position:0% over again what is State load I'm sure a 00:02:26.879 --> 00:02:27.949 align:start position:0% over again what is State load I'm sure a lot<00:02:26.940> of<00:02:27.000> you<00:02:27.120> are<00:02:27.239> familiar<00:02:27.480> with<00:02:27.599> that<00:02:27.780> this 00:02:27.949 --> 00:02:27.959 align:start position:0% lot of you are familiar with that this 00:02:27.959 --> 00:02:30.050 align:start position:0% lot of you are familiar with that this is<00:02:28.140> basically<00:02:28.440> means<00:02:28.739> that<00:02:28.860> state<00:02:29.160> size<00:02:29.700> grows 00:02:30.050 --> 00:02:30.060 align:start position:0% is basically means that state size grows 00:02:30.060 --> 00:02:31.490 align:start position:0% is basically means that state size grows with<00:02:30.239> time<00:02:30.420> the<00:02:30.720> more<00:02:30.840> accounts<00:02:31.260> there<00:02:31.379> are 00:02:31.490 --> 00:02:31.500 align:start position:0% with time the more accounts there are 00:02:31.500 --> 00:02:33.410 align:start position:0% with time the more accounts there are the<00:02:31.739> more<00:02:31.920> tokens<00:02:32.400> accounts<00:02:32.819> hold<00:02:32.940> and<00:02:33.180> all<00:02:33.300> of 00:02:33.410 --> 00:02:33.420 align:start position:0% the more tokens accounts hold and all of 00:02:33.420 --> 00:02:35.869 align:start position:0% the more tokens accounts hold and all of that<00:02:33.800> you<00:02:34.800> know<00:02:34.860> the<00:02:34.980> state<00:02:35.099> size<00:02:35.340> increases 00:02:35.869 --> 00:02:35.879 align:start position:0% that you know the state size increases 00:02:35.879 --> 00:02:38.330 align:start position:0% that you know the state size increases and<00:02:36.420> the<00:02:36.599> reason<00:02:36.720> why<00:02:37.020> we<00:02:37.260> can't<00:02:37.500> do<00:02:37.860> much<00:02:38.099> with 00:02:38.330 --> 00:02:38.340 align:start position:0% and the reason why we can't do much with 00:02:38.340 --> 00:02:41.210 align:start position:0% and the reason why we can't do much with about<00:02:38.640> that<00:02:38.819> is<00:02:39.000> that<00:02:39.379> nodes<00:02:40.379> or<00:02:40.739> operators 00:02:41.210 --> 00:02:41.220 align:start position:0% about that is that nodes or operators 00:02:41.220 --> 00:02:43.070 align:start position:0% about that is that nodes or operators need<00:02:41.580> to<00:02:41.700> be<00:02:41.879> able<00:02:42.060> need<00:02:42.300> to<00:02:42.480> hold<00:02:42.780> the<00:02:42.959> full 00:02:43.070 --> 00:02:43.080 align:start position:0% need to be able need to hold the full 00:02:43.080 --> 00:02:46.130 align:start position:0% need to be able need to hold the full state<00:02:43.260> to<00:02:43.500> be<00:02:43.620> able<00:02:43.739> to<00:02:43.920> validate<00:02:44.340> the<00:02:45.000> blocks 00:02:46.130 --> 00:02:46.140 align:start position:0% state to be able to validate the blocks 00:02:46.140 --> 00:02:48.830 align:start position:0% state to be able to validate the blocks and<00:02:47.099> nodes<00:02:47.819> need<00:02:48.060> the<00:02:48.239> full<00:02:48.300> state<00:02:48.480> to<00:02:48.660> be<00:02:48.780> able 00:02:48.830 --> 00:02:48.840 align:start position:0% and nodes need the full state to be able 00:02:48.840 --> 00:02:50.330 align:start position:0% and nodes need the full state to be able to<00:02:48.959> produce<00:02:49.200> new<00:02:49.440> blocks 00:02:50.330 --> 00:02:50.340 align:start position:0% to produce new blocks 00:02:50.340 --> 00:02:52.670 align:start position:0% to produce new blocks now<00:02:50.819> why<00:02:51.180> are<00:02:51.360> these<00:02:51.599> things<00:02:51.660> bad<00:02:51.900> like<00:02:52.200> I<00:02:52.560> said 00:02:52.670 --> 00:02:52.680 align:start position:0% now why are these things bad like I said 00:02:52.680 --> 00:02:54.229 align:start position:0% now why are these things bad like I said there<00:02:52.860> are<00:02:52.980> challenges<00:02:53.340> so<00:02:53.519> why<00:02:53.760> exactly<00:02:54.120> are 00:02:54.229 --> 00:02:54.239 align:start position:0% there are challenges so why exactly are 00:02:54.239 --> 00:02:56.630 align:start position:0% there are challenges so why exactly are they<00:02:54.360> challenges<00:02:54.720> so<00:02:54.900> the<00:02:55.019> first<00:02:55.200> thing<00:02:55.379> is 00:02:56.630 --> 00:02:56.640 align:start position:0% they challenges so the first thing is 00:02:56.640 --> 00:02:58.070 align:start position:0% they challenges so the first thing is um if<00:02:56.940> you<00:02:57.060> have<00:02:57.180> state<00:02:57.360> load<00:02:57.720> and<00:02:57.780> execution 00:02:58.070 --> 00:02:58.080 align:start position:0% um if you have state load and execution 00:02:58.080 --> 00:02:59.930 align:start position:0% um if you have state load and execution bloat<00:02:58.440> you<00:02:58.560> need<00:02:58.680> powerful<00:02:59.040> machines<00:02:59.400> to<00:02:59.640> like 00:02:59.930 --> 00:02:59.940 align:start position:0% bloat you need powerful machines to like 00:02:59.940 --> 00:03:01.190 align:start position:0% bloat you need powerful machines to like let's<00:03:00.300> say<00:03:00.420> we<00:03:00.599> have<00:03:00.720> thousands<00:03:01.140> and 00:03:01.190 --> 00:03:01.200 align:start position:0% let's say we have thousands and 00:03:01.200 --> 00:03:02.630 align:start position:0% let's say we have thousands and transactions<00:03:01.739> per<00:03:01.860> second<00:03:01.980> you<00:03:02.280> need<00:03:02.459> a 00:03:02.630 --> 00:03:02.640 align:start position:0% transactions per second you need a 00:03:02.640 --> 00:03:04.070 align:start position:0% transactions per second you need a powerful<00:03:02.819> powerful<00:03:03.360> machine<00:03:03.540> to<00:03:03.840> process 00:03:04.070 --> 00:03:04.080 align:start position:0% powerful powerful machine to process 00:03:04.080 --> 00:03:05.750 align:start position:0% powerful powerful machine to process that<00:03:04.319> if<00:03:04.860> you<00:03:04.980> have<00:03:05.099> a<00:03:05.280> large<00:03:05.340> you<00:03:05.700> know 00:03:05.750 --> 00:03:05.760 align:start position:0% that if you have a large you know 00:03:05.760 --> 00:03:07.610 align:start position:0% that if you have a large you know terabyte<00:03:06.239> size<00:03:06.420> State<00:03:06.720> you<00:03:07.140> need<00:03:07.260> a<00:03:07.440> large 00:03:07.610 --> 00:03:07.620 align:start position:0% terabyte size State you need a large 00:03:07.620 --> 00:03:10.130 align:start position:0% terabyte size State you need a large machine<00:03:07.860> to<00:03:08.340> hold<00:03:09.000> that<00:03:09.180> in<00:03:09.420> memory<00:03:09.599> and<00:03:10.019> that 00:03:10.130 --> 00:03:10.140 align:start position:0% machine to hold that in memory and that 00:03:10.140 --> 00:03:11.509 align:start position:0% machine to hold that in memory and that leads<00:03:10.379> to<00:03:10.440> essentialization<00:03:11.099> and<00:03:11.280> if<00:03:11.400> you 00:03:11.509 --> 00:03:11.519 align:start position:0% leads to essentialization and if you 00:03:11.519 --> 00:03:12.530 align:start position:0% leads to essentialization and if you don't<00:03:11.640> have<00:03:11.760> good<00:03:11.940> solutions<00:03:12.239> to<00:03:12.420> this 00:03:12.530 --> 00:03:12.540 align:start position:0% don't have good solutions to this 00:03:12.540 --> 00:03:13.910 align:start position:0% don't have good solutions to this problem<00:03:12.720> you<00:03:13.019> might<00:03:13.080> as<00:03:13.200> well<00:03:13.319> just<00:03:13.440> build<00:03:13.620> a 00:03:13.910 --> 00:03:13.920 align:start position:0% problem you might as well just build a 00:03:13.920 --> 00:03:15.530 align:start position:0% problem you might as well just build a centralized<00:03:14.220> roll<00:03:14.459> up<00:03:14.640> uh<00:03:15.120> the<00:03:15.239> other<00:03:15.360> one 00:03:15.530 --> 00:03:15.540 align:start position:0% centralized roll up uh the other one 00:03:15.540 --> 00:03:16.910 align:start position:0% centralized roll up uh the other one because<00:03:15.659> everyone<00:03:16.019> sees<00:03:16.500> everything<00:03:16.680> and 00:03:16.910 --> 00:03:16.920 align:start position:0% because everyone sees everything and 00:03:16.920 --> 00:03:17.930 align:start position:0% because everyone sees everything and everybody<00:03:17.099> needs<00:03:17.459> to<00:03:17.519> re-execute 00:03:17.930 --> 00:03:17.940 align:start position:0% everybody needs to re-execute 00:03:17.940 --> 00:03:19.550 align:start position:0% everybody needs to re-execute transactions<00:03:18.420> and<00:03:18.659> have<00:03:18.959> the<00:03:19.140> full<00:03:19.319> State 00:03:19.550 --> 00:03:19.560 align:start position:0% transactions and have the full State 00:03:19.560 --> 00:03:23.030 align:start position:0% transactions and have the full State there<00:03:20.519> is<00:03:20.700> inherently<00:03:21.300> less<00:03:21.480> privacy<00:03:21.959> in<00:03:22.860> this 00:03:23.030 --> 00:03:23.040 align:start position:0% there is inherently less privacy in this 00:03:23.040 --> 00:03:24.649 align:start position:0% there is inherently less privacy in this uh<00:03:23.280> in<00:03:23.519> the<00:03:23.580> setup 00:03:24.649 --> 00:03:24.659 align:start position:0% uh in the setup 00:03:24.659 --> 00:03:27.949 align:start position:0% uh in the setup and<00:03:25.440> last<00:03:25.860> one<00:03:26.099> is<00:03:26.340> especially<00:03:26.819> specific<00:03:27.720> to 00:03:27.949 --> 00:03:27.959 align:start position:0% and last one is especially specific to 00:03:27.959 --> 00:03:29.930 align:start position:0% and last one is especially specific to State<00:03:28.319> load<00:03:28.739> this<00:03:29.099> is<00:03:29.159> not<00:03:29.400> sustainable<00:03:29.760> if 00:03:29.930 --> 00:03:29.940 align:start position:0% State load this is not sustainable if 00:03:29.940 --> 00:03:31.610 align:start position:0% State load this is not sustainable if the<00:03:30.060> state<00:03:30.180> grows<00:03:30.480> you<00:03:30.659> can<00:03:30.840> you<00:03:31.080> know<00:03:31.140> scale 00:03:31.610 --> 00:03:31.620 align:start position:0% the state grows you can you know scale 00:03:31.620 --> 00:03:32.930 align:start position:0% the state grows you can you know scale the<00:03:31.739> role<00:03:31.980> up<00:03:32.099> only<00:03:32.159> as<00:03:32.400> fast<00:03:32.519> as<00:03:32.640> the<00:03:32.760> hardware 00:03:32.930 --> 00:03:32.940 align:start position:0% the role up only as fast as the hardware 00:03:32.940 --> 00:03:34.910 align:start position:0% the role up only as fast as the hardware scales<00:03:33.360> you<00:03:33.480> can<00:03:33.599> you<00:03:33.780> can<00:03:33.959> go<00:03:34.260> uh<00:03:34.680> like<00:03:34.860> a 00:03:34.910 --> 00:03:34.920 align:start position:0% scales you can you can go uh like a 00:03:34.920 --> 00:03:35.930 align:start position:0% scales you can you can go uh like a Hardware<00:03:35.040> in<00:03:35.280> a<00:03:35.400> single<00:03:35.580> machine<00:03:35.700> or 00:03:35.930 --> 00:03:35.940 align:start position:0% Hardware in a single machine or 00:03:35.940 --> 00:03:37.190 align:start position:0% Hardware in a single machine or something<00:03:36.060> like<00:03:36.239> that 00:03:37.190 --> 00:03:37.200 align:start position:0% something like that 00:03:37.200 --> 00:03:38.809 align:start position:0% something like that um<00:03:37.260> so<00:03:37.680> what<00:03:37.800> do<00:03:37.920> we<00:03:38.040> want<00:03:38.159> to<00:03:38.280> achieve<00:03:38.519> what<00:03:38.640> is 00:03:38.809 --> 00:03:38.819 align:start position:0% um so what do we want to achieve what is 00:03:38.819 --> 00:03:41.030 align:start position:0% um so what do we want to achieve what is the<00:03:38.940> ideal<00:03:39.239> solution<00:03:39.599> to<00:03:39.840> this<00:03:40.019> so<00:03:40.799> the<00:03:40.920> first 00:03:41.030 --> 00:03:41.040 align:start position:0% the ideal solution to this so the first 00:03:41.040 --> 00:03:42.289 align:start position:0% the ideal solution to this so the first thing<00:03:41.159> we<00:03:41.340> want<00:03:41.459> to<00:03:41.580> minimize<00:03:41.879> execution 00:03:42.289 --> 00:03:42.299 align:start position:0% thing we want to minimize execution 00:03:42.299 --> 00:03:44.210 align:start position:0% thing we want to minimize execution bloat<00:03:42.659> and<00:03:42.840> that<00:03:43.019> means<00:03:43.260> we<00:03:43.799> want<00:03:43.860> to<00:03:43.980> execute 00:03:44.210 --> 00:03:44.220 align:start position:0% bloat and that means we want to execute 00:03:44.220 --> 00:03:46.970 align:start position:0% bloat and that means we want to execute transaction<00:03:44.580> only<00:03:44.879> once<00:03:45.720> and<00:03:46.319> also<00:03:46.680> we<00:03:46.799> want 00:03:46.970 --> 00:03:46.980 align:start position:0% transaction only once and also we want 00:03:46.980 --> 00:03:48.350 align:start position:0% transaction only once and also we want to<00:03:47.099> make<00:03:47.159> sure<00:03:47.340> that<00:03:47.580> it<00:03:47.879> doesn't<00:03:48.000> have<00:03:48.180> to<00:03:48.239> be 00:03:48.350 --> 00:03:48.360 align:start position:0% to make sure that it doesn't have to be 00:03:48.360 --> 00:03:50.210 align:start position:0% to make sure that it doesn't have to be executed<00:03:48.840> by<00:03:49.019> the<00:03:49.200> same<00:03:49.379> party<00:03:49.680> so<00:03:49.980> it's<00:03:50.099> not 00:03:50.210 --> 00:03:50.220 align:start position:0% executed by the same party so it's not 00:03:50.220 --> 00:03:51.410 align:start position:0% executed by the same party so it's not the<00:03:50.340> same<00:03:50.400> block<00:03:50.580> producer<00:03:51.060> that<00:03:51.180> needs<00:03:51.360> to 00:03:51.410 --> 00:03:51.420 align:start position:0% the same block producer that needs to 00:03:51.420 --> 00:03:52.789 align:start position:0% the same block producer that needs to execute<00:03:51.659> all<00:03:51.780> transactions<00:03:52.260> we<00:03:52.379> want<00:03:52.560> to<00:03:52.620> have 00:03:52.789 --> 00:03:52.799 align:start position:0% execute all transactions we want to have 00:03:52.799 --> 00:03:54.289 align:start position:0% execute all transactions we want to have distinct<00:03:53.220> actors<00:03:53.580> in<00:03:53.700> a<00:03:53.819> network<00:03:53.940> that<00:03:54.180> can 00:03:54.289 --> 00:03:54.299 align:start position:0% distinct actors in a network that can 00:03:54.299 --> 00:03:56.330 align:start position:0% distinct actors in a network that can execute<00:03:54.659> transactions<00:03:55.200> we<00:03:55.920> also<00:03:56.159> want<00:03:56.220> to 00:03:56.330 --> 00:03:56.340 align:start position:0% execute transactions we also want to 00:03:56.340 --> 00:03:58.149 align:start position:0% execute transactions we also want to minimize<00:03:56.640> the<00:03:56.760> state<00:03:56.879> load<00:03:57.239> and<00:03:57.360> that<00:03:57.540> means 00:03:58.149 --> 00:03:58.159 align:start position:0% minimize the state load and that means 00:03:58.159 --> 00:04:00.410 align:start position:0% minimize the state load and that means we<00:03:59.159> don't<00:03:59.340> want<00:03:59.700> to<00:03:59.819> enforce<00:04:00.180> the<00:04:00.360> condition 00:04:00.410 --> 00:04:00.420 align:start position:0% we don't want to enforce the condition 00:04:00.420 --> 00:04:01.789 align:start position:0% we don't want to enforce the condition where<00:04:00.720> you<00:04:00.840> need<00:04:00.959> to<00:04:01.080> know<00:04:01.200> the<00:04:01.319> full<00:04:01.440> state<00:04:01.620> to 00:04:01.789 --> 00:04:01.799 align:start position:0% where you need to know the full state to 00:04:01.799 --> 00:04:03.890 align:start position:0% where you need to know the full state to validate<00:04:02.159> blocks<00:04:02.580> and<00:04:03.120> we<00:04:03.360> also<00:04:03.599> don't<00:04:03.720> want 00:04:03.890 --> 00:04:03.900 align:start position:0% validate blocks and we also don't want 00:04:03.900 --> 00:04:05.270 align:start position:0% validate blocks and we also don't want to<00:04:04.019> enforce<00:04:04.379> the<00:04:04.500> condition<00:04:04.799> where<00:04:05.099> you<00:04:05.220> need 00:04:05.270 --> 00:04:05.280 align:start position:0% to enforce the condition where you need 00:04:05.280 --> 00:04:06.530 align:start position:0% to enforce the condition where you need to<00:04:05.400> know<00:04:05.519> the<00:04:05.640> full<00:04:05.760> state<00:04:05.940> to<00:04:06.120> produce<00:04:06.360> new 00:04:06.530 --> 00:04:06.540 align:start position:0% to know the full state to produce new 00:04:06.540 --> 00:04:09.830 align:start position:0% to know the full state to produce new blocks<00:04:07.340> zkps<00:04:08.340> can<00:04:08.640> give<00:04:08.879> us<00:04:09.120> you<00:04:09.480> know<00:04:09.540> these 00:04:09.830 --> 00:04:09.840 align:start position:0% blocks zkps can give us you know these 00:04:09.840 --> 00:04:12.170 align:start position:0% blocks zkps can give us you know these two<00:04:09.900> upper<00:04:10.260> properties<00:04:10.680> if<00:04:11.459> you<00:04:11.580> have<00:04:11.700> the<00:04:11.819> KPS 00:04:12.170 --> 00:04:12.180 align:start position:0% two upper properties if you have the KPS 00:04:12.180 --> 00:04:14.149 align:start position:0% two upper properties if you have the KPS you<00:04:13.019> can<00:04:13.140> you<00:04:13.260> know<00:04:13.379> produce<00:04:13.680> a<00:04:13.860> proof<00:04:14.099> of 00:04:14.149 --> 00:04:14.159 align:start position:0% you can you know produce a proof of 00:04:14.159 --> 00:04:15.410 align:start position:0% you can you know produce a proof of execution<00:04:14.459> for<00:04:14.700> example<00:04:14.879> and<00:04:15.060> you<00:04:15.239> don't<00:04:15.299> need 00:04:15.410 --> 00:04:15.420 align:start position:0% execution for example and you don't need 00:04:15.420 --> 00:04:16.729 align:start position:0% execution for example and you don't need to<00:04:15.540> re-execute<00:04:15.959> the<00:04:16.019> same<00:04:16.139> transaction<00:04:16.500> over 00:04:16.729 --> 00:04:16.739 align:start position:0% to re-execute the same transaction over 00:04:16.739 --> 00:04:18.590 align:start position:0% to re-execute the same transaction over and<00:04:16.859> over<00:04:17.040> again<00:04:17.160> but<00:04:17.880> to<00:04:18.120> achieve<00:04:18.359> the<00:04:18.479> other 00:04:18.590 --> 00:04:18.600 align:start position:0% and over again but to achieve the other 00:04:18.600 --> 00:04:19.729 align:start position:0% and over again but to achieve the other two<00:04:18.780> properties<00:04:19.079> you<00:04:19.260> need<00:04:19.380> something<00:04:19.560> else 00:04:19.729 --> 00:04:19.739 align:start position:0% two properties you need something else 00:04:19.739 --> 00:04:21.650 align:start position:0% two properties you need something else zkp<00:04:20.459> is<00:04:20.519> alone<00:04:20.699> are<00:04:21.000> not<00:04:21.180> enough<00:04:21.299> you<00:04:21.540> need 00:04:21.650 --> 00:04:21.660 align:start position:0% zkp is alone are not enough you need 00:04:21.660 --> 00:04:24.469 align:start position:0% zkp is alone are not enough you need what<00:04:21.900> I<00:04:22.079> call<00:04:22.199> a<00:04:22.320> concurrent<00:04:22.800> State<00:04:23.340> model<00:04:23.580> and 00:04:24.469 --> 00:04:24.479 align:start position:0% what I call a concurrent State model and 00:04:24.479 --> 00:04:25.610 align:start position:0% what I call a concurrent State model and before<00:04:24.540> I<00:04:24.720> get<00:04:24.840> into<00:04:24.960> the<00:04:25.139> concurrent<00:04:25.500> State 00:04:25.610 --> 00:04:25.620 align:start position:0% before I get into the concurrent State 00:04:25.620 --> 00:04:27.290 align:start position:0% before I get into the concurrent State model<00:04:25.860> let's<00:04:26.160> talk<00:04:26.280> about<00:04:26.460> like<00:04:26.759> the<00:04:27.060> popular 00:04:27.290 --> 00:04:27.300 align:start position:0% model let's talk about like the popular 00:04:27.300 --> 00:04:29.390 align:start position:0% model let's talk about like the popular approaches<00:04:28.199> to<00:04:28.380> what<00:04:28.560> that<00:04:28.800> you<00:04:29.040> know<00:04:29.100> the 00:04:29.390 --> 00:04:29.400 align:start position:0% approaches to what that you know the 00:04:29.400 --> 00:04:31.550 align:start position:0% approaches to what that you know the popular<00:04:29.880> state<00:04:30.120> models<00:04:30.540> right<00:04:30.720> now<00:04:30.840> so<00:04:31.440> we 00:04:31.550 --> 00:04:31.560 align:start position:0% popular state models right now so we 00:04:31.560 --> 00:04:32.930 align:start position:0% popular state models right now so we usually<00:04:31.860> have<00:04:31.979> an<00:04:32.100> account<00:04:32.280> based<00:04:32.639> State<00:04:32.759> and 00:04:32.930 --> 00:04:32.940 align:start position:0% usually have an account based State and 00:04:32.940 --> 00:04:36.290 align:start position:0% usually have an account based State and a<00:04:33.060> utxo<00:04:33.540> based<00:04:33.840> date<00:04:34.440> and<00:04:35.040> if<00:04:35.220> we<00:04:35.400> look<00:04:35.520> at<00:04:35.820> pros 00:04:36.290 --> 00:04:36.300 align:start position:0% a utxo based date and if we look at pros 00:04:36.300 --> 00:04:38.090 align:start position:0% a utxo based date and if we look at pros and<00:04:36.360> cons<00:04:36.479> of<00:04:36.780> each<00:04:36.960> let's<00:04:37.500> say<00:04:37.680> for<00:04:37.860> account 00:04:38.090 --> 00:04:38.100 align:start position:0% and cons of each let's say for account 00:04:38.100 --> 00:04:40.070 align:start position:0% and cons of each let's say for account based<00:04:38.580> date<00:04:39.180> um<00:04:39.240> you<00:04:39.479> know<00:04:39.540> it's<00:04:39.660> great<00:04:39.900> for 00:04:40.070 --> 00:04:40.080 align:start position:0% based date um you know it's great for 00:04:40.080 --> 00:04:41.330 align:start position:0% based date um you know it's great for expressive<00:04:40.500> smart<00:04:40.680> contracts<00:04:41.040> this<00:04:41.160> is<00:04:41.220> what 00:04:41.330 --> 00:04:41.340 align:start position:0% expressive smart contracts this is what 00:04:41.340 --> 00:04:43.070 align:start position:0% expressive smart contracts this is what we<00:04:41.460> love<00:04:41.580> about<00:04:41.699> ethereum<00:04:42.240> we<00:04:42.419> can<00:04:42.540> write<00:04:42.780> very 00:04:43.070 --> 00:04:43.080 align:start position:0% we love about ethereum we can write very 00:04:43.080 --> 00:04:45.110 align:start position:0% we love about ethereum we can write very cool<00:04:43.919> applications<00:04:44.400> you<00:04:44.699> have<00:04:44.820> a<00:04:44.880> lot<00:04:45.000> of 00:04:45.110 --> 00:04:45.120 align:start position:0% cool applications you have a lot of 00:04:45.120 --> 00:04:47.030 align:start position:0% cool applications you have a lot of freedom<00:04:45.419> and<00:04:46.020> they<00:04:46.259> all<00:04:46.500> interact<00:04:46.800> with<00:04:46.919> each 00:04:47.030 --> 00:04:47.040 align:start position:0% freedom and they all interact with each 00:04:47.040 --> 00:04:49.189 align:start position:0% freedom and they all interact with each other<00:04:47.160> very<00:04:47.400> well<00:04:47.660> uh<00:04:48.660> it's<00:04:48.780> not<00:04:48.960> great<00:04:49.080> for 00:04:49.189 --> 00:04:49.199 align:start position:0% other very well uh it's not great for 00:04:49.199 --> 00:04:51.050 align:start position:0% other very well uh it's not great for concurrent<00:04:49.620> execution<00:04:50.040> it<00:04:50.400> is<00:04:50.520> possible<00:04:50.820> to 00:04:51.050 --> 00:04:51.060 align:start position:0% concurrent execution it is possible to 00:04:51.060 --> 00:04:53.330 align:start position:0% concurrent execution it is possible to achieve<00:04:51.300> but<00:04:51.419> it<00:04:51.600> is<00:04:51.780> not<00:04:51.900> very<00:04:52.080> easy<00:04:52.320> and<00:04:53.160> you 00:04:53.330 --> 00:04:53.340 align:start position:0% achieve but it is not very easy and you 00:04:53.340 --> 00:04:55.550 align:start position:0% achieve but it is not very easy and you know<00:04:53.460> has<00:04:53.580> a<00:04:53.759> lot<00:04:53.820> of<00:04:53.940> issues<00:04:54.540> and<00:04:55.139> it<00:04:55.259> is<00:04:55.380> also 00:04:55.550 --> 00:04:55.560 align:start position:0% know has a lot of issues and it is also 00:04:55.560 --> 00:04:57.830 align:start position:0% know has a lot of issues and it is also bad<00:04:55.680> anonymity<00:04:56.280> because<00:04:56.520> if<00:04:56.820> you<00:04:56.940> want<00:04:57.180> to<00:04:57.300> if 00:04:57.830 --> 00:04:57.840 align:start position:0% bad anonymity because if you want to if 00:04:57.840 --> 00:04:59.270 align:start position:0% bad anonymity because if you want to if you<00:04:57.960> have<00:04:58.080> accounts<00:04:58.500> and<00:04:58.800> you<00:04:58.979> know<00:04:59.100> which 00:04:59.270 --> 00:04:59.280 align:start position:0% you have accounts and you know which 00:04:59.280 --> 00:05:00.890 align:start position:0% you have accounts and you know which account<00:04:59.460> participation<00:05:00.300> which<00:05:00.540> transaction 00:05:00.890 --> 00:05:00.900 align:start position:0% account participation which transaction 00:05:00.900 --> 00:05:03.110 align:start position:0% account participation which transaction it's<00:05:01.800> very<00:05:01.979> difficult<00:05:02.280> to<00:05:02.460> hide<00:05:02.639> kind<00:05:02.820> of<00:05:02.940> this 00:05:03.110 --> 00:05:03.120 align:start position:0% it's very difficult to hide kind of this 00:05:03.120 --> 00:05:04.909 align:start position:0% it's very difficult to hide kind of this transaction<00:05:03.419> graph<00:05:03.780> so<00:05:03.900> to<00:05:04.139> say 00:05:04.909 --> 00:05:04.919 align:start position:0% transaction graph so to say 00:05:04.919 --> 00:05:06.950 align:start position:0% transaction graph so to say utxo<00:05:05.820> base<00:05:05.940> model<00:05:06.120> is<00:05:06.300> kind<00:05:06.419> of<00:05:06.540> opposite<00:05:06.840> of 00:05:06.950 --> 00:05:06.960 align:start position:0% utxo base model is kind of opposite of 00:05:06.960 --> 00:05:08.510 align:start position:0% utxo base model is kind of opposite of that<00:05:07.080> it's<00:05:07.320> great<00:05:07.500> for<00:05:07.680> concurrent<00:05:08.100> execution 00:05:08.510 --> 00:05:08.520 align:start position:0% that it's great for concurrent execution 00:05:08.520 --> 00:05:10.850 align:start position:0% that it's great for concurrent execution because<00:05:08.759> in<00:05:09.419> a<00:05:09.540> utxo<00:05:10.020> model<00:05:10.139> transactions<00:05:10.680> are 00:05:10.850 --> 00:05:10.860 align:start position:0% because in a utxo model transactions are 00:05:10.860 --> 00:05:12.950 align:start position:0% because in a utxo model transactions are logically<00:05:11.280> separate<00:05:11.820> from<00:05:12.000> each<00:05:12.180> other 00:05:12.950 --> 00:05:12.960 align:start position:0% logically separate from each other 00:05:12.960 --> 00:05:14.629 align:start position:0% logically separate from each other it's<00:05:13.740> actually<00:05:13.919> a<00:05:14.100> very<00:05:14.220> good<00:05:14.340> tool<00:05:14.580> for 00:05:14.629 --> 00:05:14.639 align:start position:0% it's actually a very good tool for 00:05:14.639 --> 00:05:16.189 align:start position:0% it's actually a very good tool for anonymity<00:05:15.060> like<00:05:15.419> if<00:05:15.540> you<00:05:15.660> want<00:05:15.780> to<00:05:15.840> achieve<00:05:16.080> an 00:05:16.189 --> 00:05:16.199 align:start position:0% anonymity like if you want to achieve an 00:05:16.199 --> 00:05:18.469 align:start position:0% anonymity like if you want to achieve an image<00:05:16.500> you<00:05:16.919> almost<00:05:17.280> have<00:05:17.580> to<00:05:17.759> use<00:05:17.820> a<00:05:17.940> utxo 00:05:18.469 --> 00:05:18.479 align:start position:0% image you almost have to use a utxo 00:05:18.479 --> 00:05:19.670 align:start position:0% image you almost have to use a utxo model<00:05:18.660> it's<00:05:18.960> not<00:05:19.080> the<00:05:19.199> only<00:05:19.320> thing<00:05:19.440> that<00:05:19.560> you 00:05:19.670 --> 00:05:19.680 align:start position:0% model it's not the only thing that you 00:05:19.680 --> 00:05:21.710 align:start position:0% model it's not the only thing that you have<00:05:19.800> to<00:05:19.919> use<00:05:20.040> but<00:05:20.340> it<00:05:20.820> is<00:05:20.940> one<00:05:21.120> of<00:05:21.240> the<00:05:21.360> kind<00:05:21.660> of 00:05:21.710 --> 00:05:21.720 align:start position:0% have to use but it is one of the kind of 00:05:21.720 --> 00:05:24.110 align:start position:0% have to use but it is one of the kind of basic<00:05:21.960> building<00:05:22.139> blocks<00:05:22.759> but<00:05:23.759> it<00:05:23.880> is<00:05:24.000> not 00:05:24.110 --> 00:05:24.120 align:start position:0% basic building blocks but it is not 00:05:24.120 --> 00:05:26.270 align:start position:0% basic building blocks but it is not great<00:05:24.240> for<00:05:24.479> expressive<00:05:24.960> smart<00:05:25.139> contracts<00:05:25.620> you 00:05:26.270 --> 00:05:26.280 align:start position:0% great for expressive smart contracts you 00:05:26.280 --> 00:05:28.010 align:start position:0% great for expressive smart contracts you can<00:05:26.400> kind<00:05:26.580> of<00:05:26.639> get<00:05:26.820> smart<00:05:26.940> contracts<00:05:27.360> in<00:05:27.479> utxo 00:05:28.010 --> 00:05:28.020 align:start position:0% can kind of get smart contracts in utxo 00:05:28.020 --> 00:05:29.629 align:start position:0% can kind of get smart contracts in utxo model<00:05:28.139> but<00:05:28.320> it's<00:05:28.440> not<00:05:28.620> easy<00:05:28.860> and<00:05:29.160> you<00:05:29.340> know<00:05:29.460> the 00:05:29.629 --> 00:05:29.639 align:start position:0% model but it's not easy and you know the 00:05:29.639 --> 00:05:30.830 align:start position:0% model but it's not easy and you know the more<00:05:29.820> expressive<00:05:30.120> they<00:05:30.300> are<00:05:30.419> the<00:05:30.539> more<00:05:30.720> it 00:05:30.830 --> 00:05:30.840 align:start position:0% more expressive they are the more it 00:05:30.840 --> 00:05:31.969 align:start position:0% more expressive they are the more it starts<00:05:31.020> to<00:05:31.080> look<00:05:31.139> like<00:05:31.259> an<00:05:31.380> account<00:05:31.560> based 00:05:31.969 --> 00:05:31.979 align:start position:0% starts to look like an account based 00:05:31.979 --> 00:05:35.290 align:start position:0% starts to look like an account based model<00:05:32.039> so<00:05:32.759> what<00:05:33.120> we<00:05:33.240> want<00:05:33.360> to<00:05:33.539> do<00:05:33.600> is<00:05:33.780> combine 00:05:35.290 --> 00:05:35.300 align:start position:0% model so what we want to do is combine 00:05:35.300 --> 00:05:37.490 align:start position:0% model so what we want to do is combine the<00:05:36.300> nice<00:05:36.419> properties<00:05:36.780> of<00:05:36.960> each<00:05:37.080> of<00:05:37.199> this<00:05:37.380> into 00:05:37.490 --> 00:05:37.500 align:start position:0% the nice properties of each of this into 00:05:37.500 --> 00:05:39.050 align:start position:0% the nice properties of each of this into a<00:05:37.740> single<00:05:37.979> model<00:05:38.100> and<00:05:38.400> I<00:05:38.520> call<00:05:38.639> this<00:05:38.820> like 00:05:39.050 --> 00:05:39.060 align:start position:0% a single model and I call this like 00:05:39.060 --> 00:05:40.550 align:start position:0% a single model and I call this like basically<00:05:39.360> account<00:05:39.600> based<00:05:39.900> model<00:05:39.960> each<00:05:40.199> Excel 00:05:40.550 --> 00:05:40.560 align:start position:0% basically account based model each Excel 00:05:40.560 --> 00:05:42.710 align:start position:0% basically account based model each Excel based<00:05:40.800> model<00:05:40.919> and<00:05:41.639> combine<00:05:42.180> that<00:05:42.360> with<00:05:42.479> EK 00:05:42.710 --> 00:05:42.720 align:start position:0% based model and combine that with EK 00:05:42.720 --> 00:05:44.210 align:start position:0% based model and combine that with EK proofs<00:05:43.020> and<00:05:43.139> we'll<00:05:43.320> get<00:05:43.680> something<00:05:43.860> that<00:05:44.100> I 00:05:44.210 --> 00:05:44.220 align:start position:0% proofs and we'll get something that I 00:05:44.220 --> 00:05:46.670 align:start position:0% proofs and we'll get something that I call<00:05:44.340> is<00:05:44.520> the<00:05:44.699> actor<00:05:45.060> based<00:05:45.780> model<00:05:46.380> with 00:05:46.670 --> 00:05:46.680 align:start position:0% call is the actor based model with 00:05:46.680 --> 00:05:48.770 align:start position:0% call is the actor based model with concurrent<00:05:47.160> of<00:05:47.460> chain<00:05:47.639> State<00:05:48.000> and<00:05:48.419> I'll<00:05:48.600> get 00:05:48.770 --> 00:05:48.780 align:start position:0% concurrent of chain State and I'll get 00:05:48.780 --> 00:05:51.230 align:start position:0% concurrent of chain State and I'll get into<00:05:48.960> what<00:05:49.199> all<00:05:49.380> of<00:05:49.620> those<00:05:49.740> terms<00:05:50.039> mean<00:05:50.220> in<00:05:50.400> the 00:05:51.230 --> 00:05:51.240 align:start position:0% into what all of those terms mean in the 00:05:51.240 --> 00:05:52.610 align:start position:0% into what all of those terms mean in the course<00:05:51.360> of<00:05:51.479> this<00:05:51.600> presentation 00:05:52.610 --> 00:05:52.620 align:start position:0% course of this presentation 00:05:52.620 --> 00:05:54.830 align:start position:0% course of this presentation so<00:05:53.400> first 00:05:54.830 --> 00:05:54.840 align:start position:0% so first 00:05:54.840 --> 00:05:56.510 align:start position:0% so first thing<00:05:55.259> that<00:05:55.500> I<00:05:55.680> want<00:05:55.740> to<00:05:55.860> explain<00:05:55.979> of<00:05:56.220> how<00:05:56.400> this 00:05:56.510 --> 00:05:56.520 align:start position:0% thing that I want to explain of how this 00:05:56.520 --> 00:05:57.950 align:start position:0% thing that I want to explain of how this works<00:05:56.699> is<00:05:56.820> how<00:05:56.940> do<00:05:57.120> transactions<00:05:57.600> work<00:05:57.780> in 00:05:57.950 --> 00:05:57.960 align:start position:0% works is how do transactions work in 00:05:57.960 --> 00:05:58.790 align:start position:0% works is how do transactions work in this<00:05:58.139> model 00:05:58.790 --> 00:05:58.800 align:start position:0% this model 00:05:58.800 --> 00:06:01.070 align:start position:0% this model and<00:05:59.220> what<00:05:59.460> is<00:05:59.639> an<00:06:00.060> actual<00:06:00.419> model<00:06:00.660> specifically 00:06:01.070 --> 00:06:01.080 align:start position:0% and what is an actual model specifically 00:06:01.080 --> 00:06:02.390 align:start position:0% and what is an actual model specifically and<00:06:01.199> how<00:06:01.380> we<00:06:01.500> think<00:06:01.620> of<00:06:01.740> transactions<00:06:02.160> in<00:06:02.280> that 00:06:02.390 --> 00:06:02.400 align:start position:0% and how we think of transactions in that 00:06:02.400 --> 00:06:03.110 align:start position:0% and how we think of transactions in that model 00:06:03.110 --> 00:06:03.120 align:start position:0% model 00:06:03.120 --> 00:06:05.210 align:start position:0% model so<00:06:03.539> just<00:06:03.900> to<00:06:04.080> take<00:06:04.259> a<00:06:04.440> step<00:06:04.680> back<00:06:04.860> and<00:06:05.039> explain 00:06:05.210 --> 00:06:05.220 align:start position:0% so just to take a step back and explain 00:06:05.220 --> 00:06:06.710 align:start position:0% so just to take a step back and explain what<00:06:05.520> is<00:06:05.639> an<00:06:05.699> actual<00:06:06.000> model<00:06:06.180> it's<00:06:06.360> a<00:06:06.479> concept 00:06:06.710 --> 00:06:06.720 align:start position:0% what is an actual model it's a concept 00:06:06.720 --> 00:06:08.510 align:start position:0% what is an actual model it's a concept from<00:06:06.900> distributed<00:06:07.380> uh<00:06:07.800> kind<00:06:08.039> of<00:06:08.160> systems 00:06:08.510 --> 00:06:08.520 align:start position:0% from distributed uh kind of systems 00:06:08.520 --> 00:06:10.909 align:start position:0% from distributed uh kind of systems where<00:06:08.820> you<00:06:09.120> have<00:06:09.240> actors<00:06:09.660> which<00:06:10.020> are<00:06:10.199> kind<00:06:10.800> of 00:06:10.909 --> 00:06:10.919 align:start position:0% where you have actors which are kind of 00:06:10.919 --> 00:06:14.629 align:start position:0% where you have actors which are kind of state<00:06:11.400> machines<00:06:11.759> with<00:06:11.940> inboxes<00:06:13.080> and<00:06:13.740> actors 00:06:14.629 --> 00:06:14.639 align:start position:0% state machines with inboxes and actors 00:06:14.639 --> 00:06:16.189 align:start position:0% state machines with inboxes and actors communicate<00:06:15.060> by<00:06:15.240> sending<00:06:15.539> messages<00:06:15.720> to<00:06:16.020> each 00:06:16.189 --> 00:06:16.199 align:start position:0% communicate by sending messages to each 00:06:16.199 --> 00:06:18.590 align:start position:0% communicate by sending messages to each other<00:06:16.320> and<00:06:17.220> the<00:06:17.520> important<00:06:18.060> property<00:06:18.360> is<00:06:18.419> that 00:06:18.590 --> 00:06:18.600 align:start position:0% other and the important property is that 00:06:18.600 --> 00:06:19.790 align:start position:0% other and the important property is that the<00:06:18.780> messages<00:06:18.840> are<00:06:19.139> asynchronous<00:06:19.560> so<00:06:19.680> an 00:06:19.790 --> 00:06:19.800 align:start position:0% the messages are asynchronous so an 00:06:19.800 --> 00:06:21.650 align:start position:0% the messages are asynchronous so an actor<00:06:20.100> can<00:06:20.220> produce<00:06:20.460> a<00:06:20.580> message<00:06:20.759> and<00:06:21.360> then<00:06:21.479> a 00:06:21.650 --> 00:06:21.660 align:start position:0% actor can produce a message and then a 00:06:21.660 --> 00:06:23.029 align:start position:0% actor can produce a message and then a different<00:06:22.020> doctor<00:06:22.259> can<00:06:22.560> consume<00:06:22.919> this 00:06:23.029 --> 00:06:23.039 align:start position:0% different doctor can consume this 00:06:23.039 --> 00:06:25.010 align:start position:0% different doctor can consume this message<00:06:23.160> at<00:06:23.460> a<00:06:23.580> later<00:06:23.699> point<00:06:23.880> in<00:06:24.060> time<00:06:24.240> the<00:06:24.900> way 00:06:25.010 --> 00:06:25.020 align:start position:0% message at a later point in time the way 00:06:25.020 --> 00:06:26.689 align:start position:0% message at a later point in time the way we<00:06:25.259> apply<00:06:25.680> this<00:06:25.860> active<00:06:26.220> model<00:06:26.400> to<00:06:26.580> a 00:06:26.689 --> 00:06:26.699 align:start position:0% we apply this active model to a 00:06:26.699 --> 00:06:28.370 align:start position:0% we apply this active model to a blockchain<00:06:27.060> is<00:06:27.360> that<00:06:27.539> in<00:06:27.780> our<00:06:27.900> context<00:06:28.199> in 00:06:28.370 --> 00:06:28.380 align:start position:0% blockchain is that in our context in 00:06:28.380 --> 00:06:30.070 align:start position:0% blockchain is that in our context in context<00:06:28.620> of<00:06:28.740> Maiden 00:06:30.070 --> 00:06:30.080 align:start position:0% context of Maiden 00:06:30.080 --> 00:06:32.749 align:start position:0% context of Maiden actors<00:06:31.080> are<00:06:31.259> accounts<00:06:31.740> an<00:06:31.919> account<00:06:32.160> holds<00:06:32.699> a 00:06:32.749 --> 00:06:32.759 align:start position:0% actors are accounts an account holds a 00:06:32.759 --> 00:06:35.390 align:start position:0% actors are accounts an account holds a state<00:06:33.120> and<00:06:33.660> exposes<00:06:34.139> an<00:06:34.319> interface<00:06:34.919> and 00:06:35.390 --> 00:06:35.400 align:start position:0% state and exposes an interface and 00:06:35.400 --> 00:06:36.469 align:start position:0% state and exposes an interface and interface<00:06:35.819> is<00:06:35.880> just<00:06:36.060> a<00:06:36.180> collection<00:06:36.360> of 00:06:36.469 --> 00:06:36.479 align:start position:0% interface is just a collection of 00:06:36.479 --> 00:06:37.909 align:start position:0% interface is just a collection of methods<00:06:36.900> which<00:06:37.080> you<00:06:37.319> know<00:06:37.440> every<00:06:37.620> of<00:06:37.860> those 00:06:37.909 --> 00:06:37.919 align:start position:0% methods which you know every of those 00:06:37.919 --> 00:06:39.710 align:start position:0% methods which you know every of those methods<00:06:38.220> is<00:06:38.280> a<00:06:38.400> mighty<00:06:38.759> NVM<00:06:39.000> program<00:06:39.539> and 00:06:39.710 --> 00:06:39.720 align:start position:0% methods is a mighty NVM program and 00:06:39.720 --> 00:06:41.150 align:start position:0% methods is a mighty NVM program and might<00:06:39.900> and<00:06:40.080> VM<00:06:40.319> is<00:06:40.500> a<00:06:40.620> you<00:06:40.740> know<00:06:40.860> fully<00:06:41.039> to 00:06:41.150 --> 00:06:41.160 align:start position:0% might and VM is a you know fully to 00:06:41.160 --> 00:06:43.430 align:start position:0% might and VM is a you know fully to recomplete<00:06:41.759> sck<00:06:42.360> VM 00:06:43.430 --> 00:06:43.440 align:start position:0% recomplete sck VM 00:06:43.440 --> 00:06:45.890 align:start position:0% recomplete sck VM um<00:06:43.500> so<00:06:44.100> you<00:06:44.460> can<00:06:44.580> think<00:06:44.639> about<00:06:44.759> it<00:06:44.940> as<00:06:45.120> very<00:06:45.479> you 00:06:45.890 --> 00:06:45.900 align:start position:0% um so you can think about it as very you 00:06:45.900 --> 00:06:47.330 align:start position:0% um so you can think about it as very you know<00:06:46.020> expressive<00:06:46.560> functions<00:06:46.919> that<00:06:47.100> you<00:06:47.220> can 00:06:47.330 --> 00:06:47.340 align:start position:0% know expressive functions that you can 00:06:47.340 --> 00:06:49.670 align:start position:0% know expressive functions that you can write<00:06:47.520> uh<00:06:47.940> for<00:06:48.180> the<00:06:48.300> account<00:06:48.539> interface 00:06:49.670 --> 00:06:49.680 align:start position:0% write uh for the account interface 00:06:49.680 --> 00:06:51.650 align:start position:0% write uh for the account interface accounts<00:06:50.460> communicate<00:06:50.880> with<00:06:51.060> each<00:06:51.300> other<00:06:51.419> by 00:06:51.650 --> 00:06:51.660 align:start position:0% accounts communicate with each other by 00:06:51.660 --> 00:06:52.969 align:start position:0% accounts communicate with each other by sending<00:06:51.960> nodes<00:06:52.139> to<00:06:52.319> each<00:06:52.440> other<00:06:52.560> and<00:06:52.740> nodes 00:06:52.969 --> 00:06:52.979 align:start position:0% sending nodes to each other and nodes 00:06:52.979 --> 00:06:55.070 align:start position:0% sending nodes to each other and nodes can<00:06:53.220> carry<00:06:53.460> assets<00:06:53.819> and<00:06:54.300> the<00:06:54.419> node<00:06:54.660> also<00:06:54.960> has 00:06:55.070 --> 00:06:55.080 align:start position:0% can carry assets and the node also has 00:06:55.080 --> 00:06:56.809 align:start position:0% can carry assets and the node also has this<00:06:55.319> pen<00:06:55.560> script<00:06:55.919> which<00:06:56.280> needs<00:06:56.699> to<00:06:56.759> be 00:06:56.809 --> 00:06:56.819 align:start position:0% this pen script which needs to be 00:06:56.819 --> 00:06:58.430 align:start position:0% this pen script which needs to be executed<00:06:57.240> to<00:06:57.360> be<00:06:57.479> able<00:06:57.600> to<00:06:57.720> consume<00:06:58.080> a<00:06:58.199> node 00:06:58.430 --> 00:06:58.440 align:start position:0% executed to be able to consume a node 00:06:58.440 --> 00:07:01.670 align:start position:0% executed to be able to consume a node and<00:06:59.280> one<00:06:59.940> important<00:07:00.900> property<00:07:01.259> is<00:07:01.380> that<00:07:01.560> in 00:07:01.670 --> 00:07:01.680 align:start position:0% and one important property is that in 00:07:01.680 --> 00:07:02.749 align:start position:0% and one important property is that in this<00:07:01.800> model<00:07:01.919> is<00:07:02.160> actually<00:07:02.280> takes<00:07:02.580> two 00:07:02.749 --> 00:07:02.759 align:start position:0% this model is actually takes two 00:07:02.759 --> 00:07:05.629 align:start position:0% this model is actually takes two transactions<00:07:03.419> to<00:07:03.900> move<00:07:04.620> assets<00:07:05.100> from<00:07:05.400> one 00:07:05.629 --> 00:07:05.639 align:start position:0% transactions to move assets from one 00:07:05.639 --> 00:07:07.490 align:start position:0% transactions to move assets from one account<00:07:05.759> to<00:07:06.060> another<00:07:06.240> so<00:07:06.900> in<00:07:07.020> a<00:07:07.199> traditional 00:07:07.490 --> 00:07:07.500 align:start position:0% account to another so in a traditional 00:07:07.500 --> 00:07:09.529 align:start position:0% account to another so in a traditional kind<00:07:07.800> of<00:07:07.919> ethereum<00:07:08.460> model<00:07:08.639> for<00:07:08.880> example<00:07:09.120> you 00:07:09.529 --> 00:07:09.539 align:start position:0% kind of ethereum model for example you 00:07:09.539 --> 00:07:10.969 align:start position:0% kind of ethereum model for example you usually<00:07:09.900> have<00:07:10.080> just<00:07:10.199> one<00:07:10.380> transaction<00:07:10.740> that 00:07:10.969 --> 00:07:10.979 align:start position:0% usually have just one transaction that 00:07:10.979 --> 00:07:12.770 align:start position:0% usually have just one transaction that moves<00:07:11.280> assets<00:07:12.000> from<00:07:12.120> one<00:07:12.300> account<00:07:12.419> to<00:07:12.600> another 00:07:12.770 --> 00:07:12.780 align:start position:0% moves assets from one account to another 00:07:12.780 --> 00:07:15.770 align:start position:0% moves assets from one account to another in<00:07:13.440> this<00:07:13.560> model<00:07:13.680> you<00:07:13.979> have<00:07:14.100> to<00:07:14.280> have<00:07:14.520> two<00:07:15.060> uh 00:07:15.770 --> 00:07:15.780 align:start position:0% in this model you have to have two uh 00:07:15.780 --> 00:07:17.029 align:start position:0% in this model you have to have two uh transactions<00:07:16.380> because<00:07:16.560> the<00:07:16.919> first 00:07:17.029 --> 00:07:17.039 align:start position:0% transactions because the first 00:07:17.039 --> 00:07:18.469 align:start position:0% transactions because the first transactions<00:07:17.580> create<00:07:17.759> a<00:07:17.940> node<00:07:18.120> and<00:07:18.300> the 00:07:18.469 --> 00:07:18.479 align:start position:0% transactions create a node and the 00:07:18.479 --> 00:07:20.809 align:start position:0% transactions create a node and the second<00:07:18.539> transactions<00:07:19.080> consume<00:07:19.440> a<00:07:19.500> node 00:07:20.809 --> 00:07:20.819 align:start position:0% second transactions consume a node 00:07:20.819 --> 00:07:22.730 align:start position:0% second transactions consume a node now<00:07:21.419> let's<00:07:21.660> talk<00:07:21.840> about<00:07:21.960> transactions<00:07:22.560> have 00:07:22.730 --> 00:07:22.740 align:start position:0% now let's talk about transactions have 00:07:22.740 --> 00:07:23.990 align:start position:0% now let's talk about transactions have been<00:07:22.860> in<00:07:22.979> a<00:07:23.039> bit<00:07:23.160> more<00:07:23.220> detail<00:07:23.520> so<00:07:23.639> what<00:07:23.759> is<00:07:23.940> the 00:07:23.990 --> 00:07:24.000 align:start position:0% been in a bit more detail so what is the 00:07:24.000 --> 00:07:26.089 align:start position:0% been in a bit more detail so what is the transaction<00:07:24.300> in<00:07:24.479> the<00:07:24.599> context<00:07:24.780> of<00:07:24.960> Maiden<00:07:25.620> a 00:07:26.089 --> 00:07:26.099 align:start position:0% transaction in the context of Maiden a 00:07:26.099 --> 00:07:27.830 align:start position:0% transaction in the context of Maiden a transaction<00:07:26.460> always<00:07:26.880> involves<00:07:27.360> only<00:07:27.599> one 00:07:27.830 --> 00:07:27.840 align:start position:0% transaction always involves only one 00:07:27.840 --> 00:07:29.510 align:start position:0% transaction always involves only one account<00:07:28.020> the<00:07:28.560> transaction<00:07:28.860> does<00:07:29.099> not<00:07:29.220> enroll 00:07:29.510 --> 00:07:29.520 align:start position:0% account the transaction does not enroll 00:07:29.520 --> 00:07:30.950 align:start position:0% account the transaction does not enroll more<00:07:29.699> account<00:07:29.880> and<00:07:30.120> you<00:07:30.360> know<00:07:30.419> as<00:07:30.599> a<00:07:30.720> in<00:07:30.900> the 00:07:30.950 --> 00:07:30.960 align:start position:0% more account and you know as a in the 00:07:30.960 --> 00:07:31.969 align:start position:0% more account and you know as a in the course<00:07:31.080> of<00:07:31.199> a<00:07:31.259> different<00:07:31.380> section<00:07:31.620> the<00:07:31.860> state 00:07:31.969 --> 00:07:31.979 align:start position:0% course of a different section the state 00:07:31.979 --> 00:07:33.890 align:start position:0% course of a different section the state of<00:07:32.099> the<00:07:32.220> account<00:07:32.340> gets<00:07:32.759> updated 00:07:33.890 --> 00:07:33.900 align:start position:0% of the account gets updated 00:07:33.900 --> 00:07:36.710 align:start position:0% of the account gets updated um<00:07:34.340> transaction<00:07:35.340> can<00:07:35.639> consume<00:07:36.120> zero<00:07:36.539> more 00:07:36.710 --> 00:07:36.720 align:start position:0% um transaction can consume zero more 00:07:36.720 --> 00:07:37.550 align:start position:0% um transaction can consume zero more nodes 00:07:37.550 --> 00:07:37.560 align:start position:0% nodes 00:07:37.560 --> 00:07:39.830 align:start position:0% nodes and<00:07:38.099> a<00:07:38.280> transaction<00:07:38.699> can<00:07:39.000> produce<00:07:39.360> zero<00:07:39.780> more 00:07:39.830 --> 00:07:39.840 align:start position:0% and a transaction can produce zero more 00:07:39.840 --> 00:07:41.150 align:start position:0% and a transaction can produce zero more nodes<00:07:40.080> so<00:07:40.259> in<00:07:40.380> the<00:07:40.500> previous<00:07:40.620> example<00:07:41.039> for 00:07:41.150 --> 00:07:41.160 align:start position:0% nodes so in the previous example for 00:07:41.160 --> 00:07:42.529 align:start position:0% nodes so in the previous example for example<00:07:41.400> there<00:07:41.580> was<00:07:41.699> a<00:07:41.819> one<00:07:42.060> transaction<00:07:42.360> that 00:07:42.529 --> 00:07:42.539 align:start position:0% example there was a one transaction that 00:07:42.539 --> 00:07:43.730 align:start position:0% example there was a one transaction that produced<00:07:42.840> One<00:07:42.960> node<00:07:43.139> and<00:07:43.319> one<00:07:43.440> transaction 00:07:43.730 --> 00:07:43.740 align:start position:0% produced One node and one transaction 00:07:43.740 --> 00:07:45.650 align:start position:0% produced One node and one transaction that<00:07:43.919> consumed<00:07:44.280> one<00:07:44.400> node<00:07:44.699> and<00:07:45.180> we<00:07:45.360> can<00:07:45.479> have 00:07:45.650 --> 00:07:45.660 align:start position:0% that consumed one node and we can have 00:07:45.660 --> 00:07:46.850 align:start position:0% that consumed one node and we can have also<00:07:45.960> transactions<00:07:46.380> that<00:07:46.500> produce<00:07:46.740> and 00:07:46.850 --> 00:07:46.860 align:start position:0% also transactions that produce and 00:07:46.860 --> 00:07:48.890 align:start position:0% also transactions that produce and consume<00:07:47.220> nodes<00:07:47.400> in<00:07:47.520> the<00:07:47.639> same<00:07:47.699> transactions 00:07:48.890 --> 00:07:48.900 align:start position:0% consume nodes in the same transactions 00:07:48.900 --> 00:07:50.330 align:start position:0% consume nodes in the same transactions um<00:07:49.020> now 00:07:50.330 --> 00:07:50.340 align:start position:0% um now 00:07:50.340 --> 00:07:52.070 align:start position:0% um now the<00:07:50.759> execution<00:07:51.180> graph<00:07:51.479> of<00:07:51.660> how<00:07:51.780> like<00:07:51.960> let's 00:07:52.070 --> 00:07:52.080 align:start position:0% the execution graph of how like let's 00:07:52.080 --> 00:07:53.930 align:start position:0% the execution graph of how like let's say<00:07:52.199> nodes<00:07:52.380> get<00:07:52.620> consumed<00:07:53.340> um<00:07:53.460> kind<00:07:53.639> of<00:07:53.819> to 00:07:53.930 --> 00:07:53.940 align:start position:0% say nodes get consumed um kind of to 00:07:53.940 --> 00:07:55.610 align:start position:0% say nodes get consumed um kind of to explain<00:07:54.120> how<00:07:54.539> this<00:07:54.720> whole<00:07:54.900> process<00:07:55.199> works<00:07:55.500> is 00:07:55.610 --> 00:07:55.620 align:start position:0% explain how this whole process works is 00:07:55.620 --> 00:07:57.230 align:start position:0% explain how this whole process works is let's<00:07:55.979> say<00:07:56.099> we<00:07:56.340> have<00:07:56.460> a<00:07:56.580> transaction<00:07:56.880> that 00:07:57.230 --> 00:07:57.240 align:start position:0% let's say we have a transaction that 00:07:57.240 --> 00:07:58.790 align:start position:0% let's say we have a transaction that wants<00:07:57.479> to<00:07:57.539> consume<00:07:57.840> two<00:07:57.960> nodes<00:07:58.199> in<00:07:58.440> a<00:07:58.560> context 00:07:58.790 --> 00:07:58.800 align:start position:0% wants to consume two nodes in a context 00:07:58.800 --> 00:08:00.110 align:start position:0% wants to consume two nodes in a context of<00:07:58.919> one<00:07:59.039> account<00:07:59.280> so<00:07:59.460> the<00:07:59.580> way<00:07:59.759> it<00:07:59.819> would<00:07:59.940> start 00:08:00.110 --> 00:08:00.120 align:start position:0% of one account so the way it would start 00:08:00.120 --> 00:08:01.309 align:start position:0% of one account so the way it would start is<00:08:00.240> like<00:08:00.479> we<00:08:00.599> have<00:08:00.720> this<00:08:00.900> product<00:08:01.080> and 00:08:01.309 --> 00:08:01.319 align:start position:0% is like we have this product and 00:08:01.319 --> 00:08:03.050 align:start position:0% is like we have this product and epilogue<00:08:01.800> that<00:08:01.919> do<00:08:02.039> some<00:08:02.220> bookkeeping<00:08:02.699> to 00:08:03.050 --> 00:08:03.060 align:start position:0% epilogue that do some bookkeeping to 00:08:03.060 --> 00:08:04.309 align:start position:0% epilogue that do some bookkeeping to make<00:08:03.180> sure<00:08:03.300> that<00:08:03.479> like<00:08:03.720> let's<00:08:03.900> say<00:08:04.020> sum<00:08:04.199> of 00:08:04.309 --> 00:08:04.319 align:start position:0% make sure that like let's say sum of 00:08:04.319 --> 00:08:06.770 align:start position:0% make sure that like let's say sum of inputs<00:08:04.620> is<00:08:04.680> equal<00:08:04.800> to<00:08:04.919> sum<00:08:05.099> of<00:08:05.220> outputs<00:08:05.639> uh<00:08:06.599> and 00:08:06.770 --> 00:08:06.780 align:start position:0% inputs is equal to sum of outputs uh and 00:08:06.780 --> 00:08:08.150 align:start position:0% inputs is equal to sum of outputs uh and nothing<00:08:06.900> kind<00:08:07.199> of<00:08:07.319> no<00:08:07.380> new<00:08:07.680> assets<00:08:07.979> get 00:08:08.150 --> 00:08:08.160 align:start position:0% nothing kind of no new assets get 00:08:08.160 --> 00:08:09.529 align:start position:0% nothing kind of no new assets get created<00:08:08.400> in<00:08:08.520> the<00:08:08.699> process<00:08:09.120> of<00:08:09.180> transaction 00:08:09.529 --> 00:08:09.539 align:start position:0% created in the process of transaction 00:08:09.539 --> 00:08:11.330 align:start position:0% created in the process of transaction but<00:08:09.720> then<00:08:09.840> we<00:08:10.020> go<00:08:10.199> into<00:08:10.319> this<00:08:10.500> execution<00:08:10.979> stage 00:08:11.330 --> 00:08:11.340 align:start position:0% but then we go into this execution stage 00:08:11.340 --> 00:08:13.670 align:start position:0% but then we go into this execution stage where<00:08:12.240> the<00:08:12.599> first<00:08:12.840> thing<00:08:12.960> that<00:08:13.080> happens<00:08:13.259> is<00:08:13.500> we 00:08:13.670 --> 00:08:13.680 align:start position:0% where the first thing that happens is we 00:08:13.680 --> 00:08:15.770 align:start position:0% where the first thing that happens is we call<00:08:13.860> execute<00:08:14.400> we<00:08:14.580> execute<00:08:15.000> a<00:08:15.180> script<00:08:15.419> of<00:08:15.599> the 00:08:15.770 --> 00:08:15.780 align:start position:0% call execute we execute a script of the 00:08:15.780 --> 00:08:17.930 align:start position:0% call execute we execute a script of the node<00:08:16.160> of<00:08:17.160> the<00:08:17.340> first<00:08:17.460> node<00:08:17.699> in<00:08:17.819> this 00:08:17.930 --> 00:08:17.940 align:start position:0% node of the first node in this 00:08:17.940 --> 00:08:20.029 align:start position:0% node of the first node in this transaction<00:08:18.240> and<00:08:18.720> then<00:08:18.840> this<00:08:19.139> uh<00:08:19.440> execute 00:08:20.029 --> 00:08:20.039 align:start position:0% transaction and then this uh execute 00:08:20.039 --> 00:08:21.770 align:start position:0% transaction and then this uh execute script<00:08:20.340> can<00:08:20.580> call<00:08:20.759> any<00:08:21.000> number<00:08:21.180> of<00:08:21.360> methods<00:08:21.660> on 00:08:21.770 --> 00:08:21.780 align:start position:0% script can call any number of methods on 00:08:21.780 --> 00:08:23.450 align:start position:0% script can call any number of methods on the<00:08:21.900> account<00:08:22.020> interface<00:08:22.560> so<00:08:22.919> you<00:08:23.280> know<00:08:23.400> in 00:08:23.450 --> 00:08:23.460 align:start position:0% the account interface so you know in 00:08:23.460 --> 00:08:24.650 align:start position:0% the account interface so you know in this<00:08:23.639> case<00:08:23.699> let's<00:08:23.879> say<00:08:24.000> there<00:08:24.180> is<00:08:24.300> a<00:08:24.419> receive 00:08:24.650 --> 00:08:24.660 align:start position:0% this case let's say there is a receive 00:08:24.660 --> 00:08:25.969 align:start position:0% this case let's say there is a receive method<00:08:25.020> that<00:08:25.139> receives<00:08:25.379> assets<00:08:25.740> on<00:08:25.860> the 00:08:25.969 --> 00:08:25.979 align:start position:0% method that receives assets on the 00:08:25.979 --> 00:08:28.309 align:start position:0% method that receives assets on the account<00:08:26.160> so<00:08:26.460> a<00:08:26.819> node<00:08:27.060> can<00:08:27.360> pass<00:08:27.720> assets<00:08:28.139> to 00:08:28.309 --> 00:08:28.319 align:start position:0% account so a node can pass assets to 00:08:28.319 --> 00:08:29.210 align:start position:0% account so a node can pass assets to their<00:08:28.440> account<00:08:28.620> through<00:08:28.860> this<00:08:29.039> receive 00:08:29.210 --> 00:08:29.220 align:start position:0% their account through this receive 00:08:29.220 --> 00:08:31.189 align:start position:0% their account through this receive method<00:08:29.699> and<00:08:30.300> one<00:08:30.419> important<00:08:30.780> thing<00:08:30.900> is<00:08:31.020> that 00:08:31.189 --> 00:08:31.199 align:start position:0% method and one important thing is that 00:08:31.199 --> 00:08:33.350 align:start position:0% method and one important thing is that account<00:08:31.500> uh<00:08:32.339> methods<00:08:32.760> are<00:08:32.880> the<00:08:33.000> only<00:08:33.120> ones 00:08:33.350 --> 00:08:33.360 align:start position:0% account uh methods are the only ones 00:08:33.360 --> 00:08:34.610 align:start position:0% account uh methods are the only ones that<00:08:33.479> have<00:08:33.599> access<00:08:33.779> to<00:08:33.959> account<00:08:34.140> State<00:08:34.440> and 00:08:34.610 --> 00:08:34.620 align:start position:0% that have access to account State and 00:08:34.620 --> 00:08:36.230 align:start position:0% that have access to account State and node<00:08:34.800> cannot<00:08:35.159> modify<00:08:35.520> the<00:08:35.760> state<00:08:35.940> of<00:08:36.120> their 00:08:36.230 --> 00:08:36.240 align:start position:0% node cannot modify the state of their 00:08:36.240 --> 00:08:37.490 align:start position:0% node cannot modify the state of their account<00:08:36.360> directly<00:08:36.719> it<00:08:36.899> needs<00:08:37.080> to<00:08:37.200> call<00:08:37.260> a 00:08:37.490 --> 00:08:37.500 align:start position:0% account directly it needs to call a 00:08:37.500 --> 00:08:38.750 align:start position:0% account directly it needs to call a method<00:08:37.680> on<00:08:37.800> the<00:08:37.919> account<00:08:38.039> interface<00:08:38.520> to 00:08:38.750 --> 00:08:38.760 align:start position:0% method on the account interface to 00:08:38.760 --> 00:08:41.930 align:start position:0% method on the account interface to modify<00:08:39.599> an<00:08:39.719> account<00:08:39.839> and<00:08:40.560> then<00:08:40.760> the<00:08:41.760> account 00:08:41.930 --> 00:08:41.940 align:start position:0% modify an account and then the account 00:08:41.940 --> 00:08:44.029 align:start position:0% modify an account and then the account interface<00:08:42.899> methods<00:08:43.320> can<00:08:43.380> create<00:08:43.560> other<00:08:43.740> nodes 00:08:44.029 --> 00:08:44.039 align:start position:0% interface methods can create other nodes 00:08:44.039 --> 00:08:45.590 align:start position:0% interface methods can create other nodes that's<00:08:44.279> how<00:08:44.459> you<00:08:44.760> can<00:08:44.880> for<00:08:45.000> example<00:08:45.240> create 00:08:45.590 --> 00:08:45.600 align:start position:0% that's how you can for example create 00:08:45.600 --> 00:08:47.389 align:start position:0% that's how you can for example create new<00:08:46.260> nodes<00:08:46.500> in<00:08:46.680> the<00:08:46.800> process<00:08:47.160> of<00:08:47.279> a 00:08:47.389 --> 00:08:47.399 align:start position:0% new nodes in the process of a 00:08:47.399 --> 00:08:49.850 align:start position:0% new nodes in the process of a transaction<00:08:47.839> and<00:08:48.839> then<00:08:48.959> you<00:08:49.500> know<00:08:49.620> if<00:08:49.680> we<00:08:49.800> have 00:08:49.850 --> 00:08:49.860 align:start position:0% transaction and then you know if we have 00:08:49.860 --> 00:08:51.170 align:start position:0% transaction and then you know if we have another<00:08:49.980> node<00:08:50.160> we<00:08:50.279> do<00:08:50.700> the<00:08:50.880> same<00:08:51.060> thing 00:08:51.170 --> 00:08:51.180 align:start position:0% another node we do the same thing 00:08:51.180 --> 00:08:53.750 align:start position:0% another node we do the same thing sequentially<00:08:52.019> execute<00:08:52.920> the<00:08:53.040> second<00:08:53.220> node<00:08:53.519> in 00:08:53.750 --> 00:08:53.760 align:start position:0% sequentially execute the second node in 00:08:53.760 --> 00:08:56.090 align:start position:0% sequentially execute the second node in the<00:08:53.940> context<00:08:54.120> of<00:08:54.300> the<00:08:54.480> same<00:08:54.660> account<00:08:55.080> and<00:08:55.860> that 00:08:56.090 --> 00:08:56.100 align:start position:0% the context of the same account and that 00:08:56.100 --> 00:08:57.829 align:start position:0% the context of the same account and that node<00:08:56.459> can<00:08:56.640> again<00:08:56.820> call<00:08:57.180> the<00:08:57.480> same<00:08:57.660> or 00:08:57.829 --> 00:08:57.839 align:start position:0% node can again call the same or 00:08:57.839 --> 00:08:59.810 align:start position:0% node can again call the same or different<00:08:58.019> method<00:08:58.380> on<00:08:58.560> the<00:08:58.980> account<00:08:59.100> to<00:08:59.519> have 00:08:59.810 --> 00:08:59.820 align:start position:0% different method on the account to have 00:08:59.820 --> 00:09:02.750 align:start position:0% different method on the account to have different<00:09:00.060> effects<00:09:00.480> and<00:09:00.660> so<00:09:00.779> forth<00:09:01.019> now 00:09:02.750 --> 00:09:02.760 align:start position:0% different effects and so forth now 00:09:02.760 --> 00:09:05.389 align:start position:0% different effects and so forth now in<00:09:03.300> our<00:09:03.420> context<00:09:03.779> the 00:09:05.389 --> 00:09:05.399 align:start position:0% in our context the 00:09:05.399 --> 00:09:08.690 align:start position:0% in our context the because<00:09:05.820> we<00:09:06.240> can<00:09:06.420> kind<00:09:06.959> of<00:09:07.080> execute<00:09:07.560> and<00:09:08.100> nodes 00:09:08.690 --> 00:09:08.700 align:start position:0% because we can kind of execute and nodes 00:09:08.700 --> 00:09:10.490 align:start position:0% because we can kind of execute and nodes only<00:09:08.880> touch<00:09:09.060> a<00:09:09.300> single<00:09:09.540> account<00:09:09.660> what<00:09:10.200> we<00:09:10.380> do 00:09:10.490 --> 00:09:10.500 align:start position:0% only touch a single account what we do 00:09:10.500 --> 00:09:11.750 align:start position:0% only touch a single account what we do is<00:09:10.620> we<00:09:10.740> execute<00:09:11.040> a<00:09:11.220> transaction<00:09:11.519> and 00:09:11.750 --> 00:09:11.760 align:start position:0% is we execute a transaction and 00:09:11.760 --> 00:09:13.430 align:start position:0% is we execute a transaction and immediately<00:09:12.120> produce<00:09:12.480> a<00:09:12.600> proof<00:09:12.839> for<00:09:12.959> it<00:09:13.019> so<00:09:13.200> in 00:09:13.430 --> 00:09:13.440 align:start position:0% immediately produce a proof for it so in 00:09:13.440 --> 00:09:14.810 align:start position:0% immediately produce a proof for it so in our<00:09:13.560> case<00:09:13.740> we<00:09:13.920> use<00:09:13.980> the<00:09:14.160> Stark<00:09:14.339> proving<00:09:14.700> system 00:09:14.810 --> 00:09:14.820 align:start position:0% our case we use the Stark proving system 00:09:14.820 --> 00:09:16.970 align:start position:0% our case we use the Stark proving system so<00:09:15.060> might<00:09:15.240> and<00:09:15.360> VM<00:09:15.660> is<00:09:15.720> a<00:09:15.839> stark<00:09:16.019> based<00:09:16.320> VM<00:09:16.560> so 00:09:16.970 --> 00:09:16.980 align:start position:0% so might and VM is a stark based VM so 00:09:16.980 --> 00:09:18.590 align:start position:0% so might and VM is a stark based VM so whenever<00:09:17.339> a<00:09:17.459> transaction<00:09:17.700> is<00:09:17.940> executed<00:09:18.360> we 00:09:18.590 --> 00:09:18.600 align:start position:0% whenever a transaction is executed we 00:09:18.600 --> 00:09:20.870 align:start position:0% whenever a transaction is executed we immediately<00:09:18.899> produce<00:09:19.260> a<00:09:19.380> proof<00:09:19.620> of<00:09:19.680> execution 00:09:20.870 --> 00:09:20.880 align:start position:0% immediately produce a proof of execution 00:09:20.880 --> 00:09:22.670 align:start position:0% immediately produce a proof of execution and<00:09:21.540> because<00:09:21.779> again<00:09:22.080> I<00:09:22.320> mentioned<00:09:22.560> the 00:09:22.670 --> 00:09:22.680 align:start position:0% and because again I mentioned the 00:09:22.680 --> 00:09:24.050 align:start position:0% and because again I mentioned the transactions<00:09:23.160> are<00:09:23.279> logically<00:09:23.580> distinct<00:09:23.880> they 00:09:24.050 --> 00:09:24.060 align:start position:0% transactions are logically distinct they 00:09:24.060 --> 00:09:26.210 align:start position:0% transactions are logically distinct they only<00:09:24.180> touch<00:09:24.420> each<00:09:25.080> account<00:09:25.260> separately<00:09:25.800> we 00:09:26.210 --> 00:09:26.220 align:start position:0% only touch each account separately we 00:09:26.220 --> 00:09:28.190 align:start position:0% only touch each account separately we can<00:09:26.399> produce<00:09:26.820> many<00:09:27.120> transaction<00:09:27.660> proofs<00:09:28.140> in 00:09:28.190 --> 00:09:28.200 align:start position:0% can produce many transaction proofs in 00:09:28.200 --> 00:09:30.590 align:start position:0% can produce many transaction proofs in parallel<00:09:28.560> so<00:09:29.040> we<00:09:29.760> actually<00:09:29.940> produce<00:09:30.300> all<00:09:30.480> the 00:09:30.590 --> 00:09:30.600 align:start position:0% parallel so we actually produce all the 00:09:30.600 --> 00:09:32.269 align:start position:0% parallel so we actually produce all the all<00:09:30.660> the<00:09:30.839> transaction<00:09:31.080> groups<00:09:31.440> in<00:09:31.500> parallel 00:09:32.269 --> 00:09:32.279 align:start position:0% all the transaction groups in parallel 00:09:32.279 --> 00:09:34.310 align:start position:0% all the transaction groups in parallel and<00:09:32.640> then<00:09:32.700> what<00:09:32.940> we<00:09:33.060> do<00:09:33.180> is<00:09:33.420> once<00:09:34.019> we<00:09:34.140> have<00:09:34.200> a 00:09:34.310 --> 00:09:34.320 align:start position:0% and then what we do is once we have a 00:09:34.320 --> 00:09:36.829 align:start position:0% and then what we do is once we have a bunch<00:09:34.440> of<00:09:34.560> these<00:09:34.740> transaction<00:09:35.040> proofs<00:09:35.839> we 00:09:36.829 --> 00:09:36.839 align:start position:0% bunch of these transaction proofs we 00:09:36.839 --> 00:09:38.449 align:start position:0% bunch of these transaction proofs we recursively<00:09:37.380> aggregate<00:09:37.800> them<00:09:37.920> into<00:09:38.100> the<00:09:38.279> into 00:09:38.449 --> 00:09:38.459 align:start position:0% recursively aggregate them into the into 00:09:38.459 --> 00:09:40.310 align:start position:0% recursively aggregate them into the into batches<00:09:39.000> and<00:09:39.660> this<00:09:39.779> batches<00:09:40.140> then 00:09:40.310 --> 00:09:40.320 align:start position:0% batches and this batches then 00:09:40.320 --> 00:09:42.710 align:start position:0% batches and this batches then recursively<00:09:40.800> get<00:09:40.980> aggregated<00:09:41.399> into<00:09:41.760> block 00:09:42.710 --> 00:09:42.720 align:start position:0% recursively get aggregated into block 00:09:42.720 --> 00:09:44.570 align:start position:0% recursively get aggregated into block proofs<00:09:43.140> and<00:09:43.680> then<00:09:43.740> these<00:09:43.980> blog<00:09:44.160> proofs<00:09:44.399> get 00:09:44.570 --> 00:09:44.580 align:start position:0% proofs and then these blog proofs get 00:09:44.580 --> 00:09:46.790 align:start position:0% proofs and then these blog proofs get further<00:09:44.880> aggregated<00:09:45.300> into<00:09:45.839> like<00:09:46.380> Epoch 00:09:46.790 --> 00:09:46.800 align:start position:0% further aggregated into like Epoch 00:09:46.800 --> 00:09:47.990 align:start position:0% further aggregated into like Epoch proofs<00:09:47.040> and<00:09:47.160> that's<00:09:47.220> what<00:09:47.399> gets<00:09:47.580> submitted<00:09:47.820> to 00:09:47.990 --> 00:09:48.000 align:start position:0% proofs and that's what gets submitted to 00:09:48.000 --> 00:09:49.030 align:start position:0% proofs and that's what gets submitted to ethereum 00:09:49.030 --> 00:09:49.040 align:start position:0% ethereum 00:09:49.040 --> 00:09:51.230 align:start position:0% ethereum now<00:09:50.040> it's<00:09:50.339> important<00:09:50.640> to<00:09:50.760> know<00:09:50.880> that<00:09:51.000> all<00:09:51.120> of 00:09:51.230 --> 00:09:51.240 align:start position:0% now it's important to know that all of 00:09:51.240 --> 00:09:52.550 align:start position:0% now it's important to know that all of this<00:09:51.360> recursive<00:09:51.720> aggregation<00:09:52.140> can<00:09:52.320> also<00:09:52.500> be 00:09:52.550 --> 00:09:52.560 align:start position:0% this recursive aggregation can also be 00:09:52.560 --> 00:09:53.990 align:start position:0% this recursive aggregation can also be done<00:09:52.680> in<00:09:52.860> parallel<00:09:53.160> so<00:09:53.339> as<00:09:53.519> I<00:09:53.640> mentioned<00:09:53.820> all 00:09:53.990 --> 00:09:54.000 align:start position:0% done in parallel so as I mentioned all 00:09:54.000 --> 00:09:56.630 align:start position:0% done in parallel so as I mentioned all transactions<00:09:54.540> have<00:09:54.779> been<00:09:54.959> can<00:09:55.260> be<00:09:55.519> proved<00:09:56.519> in 00:09:56.630 --> 00:09:56.640 align:start position:0% transactions have been can be proved in 00:09:56.640 --> 00:09:58.370 align:start position:0% transactions have been can be proved in parallel<00:09:57.000> but<00:09:57.420> also<00:09:57.660> all<00:09:57.779> batches<00:09:58.140> can<00:09:58.320> be 00:09:58.370 --> 00:09:58.380 align:start position:0% parallel but also all batches can be 00:09:58.380 --> 00:10:00.050 align:start position:0% parallel but also all batches can be proved<00:09:58.620> in<00:09:58.740> parallel<00:09:59.040> the<00:09:59.519> only<00:09:59.640> thing<00:09:59.820> that 00:10:00.050 --> 00:10:00.060 align:start position:0% proved in parallel the only thing that 00:10:00.060 --> 00:10:01.370 align:start position:0% proved in parallel the only thing that doesn't<00:10:00.240> get<00:10:00.480> proof<00:10:00.779> to<00:10:00.839> parallel<00:10:01.140> is<00:10:01.200> the 00:10:01.370 --> 00:10:01.380 align:start position:0% doesn't get proof to parallel is the 00:10:01.380 --> 00:10:03.410 align:start position:0% doesn't get proof to parallel is the final<00:10:01.560> kind<00:10:01.800> of<00:10:01.920> tip<00:10:02.220> of<00:10:02.459> this<00:10:02.640> block<00:10:03.000> proof 00:10:03.410 --> 00:10:03.420 align:start position:0% final kind of tip of this block proof 00:10:03.420 --> 00:10:05.030 align:start position:0% final kind of tip of this block proof and<00:10:04.080> then<00:10:04.200> there<00:10:04.320> is<00:10:04.440> another<00:10:04.560> interesting 00:10:05.030 --> 00:10:05.040 align:start position:0% and then there is another interesting 00:10:05.040 --> 00:10:06.769 align:start position:0% and then there is another interesting property<00:10:05.399> is<00:10:05.519> that<00:10:05.820> we<00:10:06.300> can<00:10:06.420> prove 00:10:06.769 --> 00:10:06.779 align:start position:0% property is that we can prove 00:10:06.779 --> 00:10:08.509 align:start position:0% property is that we can prove transactions<00:10:07.320> locally<00:10:07.680> and<00:10:07.980> I'll<00:10:08.160> get<00:10:08.399> into 00:10:08.509 --> 00:10:08.519 align:start position:0% transactions locally and I'll get into 00:10:08.519 --> 00:10:10.190 align:start position:0% transactions locally and I'll get into that<00:10:08.760> in<00:10:09.000> a<00:10:09.300> second<00:10:09.420> of<00:10:09.540> what<00:10:09.720> exactly<00:10:10.080> it 00:10:10.190 --> 00:10:10.200 align:start position:0% that in a second of what exactly it 00:10:10.200 --> 00:10:12.829 align:start position:0% that in a second of what exactly it means<00:10:10.860> um<00:10:10.920> but<00:10:11.459> then<00:10:11.580> the<00:10:12.120> segregation<00:10:12.540> steps 00:10:12.829 --> 00:10:12.839 align:start position:0% means um but then the segregation steps 00:10:12.839 --> 00:10:13.970 align:start position:0% means um but then the segregation steps need<00:10:12.959> to<00:10:13.080> be<00:10:13.200> done<00:10:13.320> by<00:10:13.440> the<00:10:13.620> network<00:10:13.680> for 00:10:13.970 --> 00:10:13.980 align:start position:0% need to be done by the network for 00:10:13.980 --> 00:10:15.350 align:start position:0% need to be done by the network for example<00:10:14.160> a<00:10:14.339> block<00:10:14.459> producer<00:10:14.940> or<00:10:15.120> a<00:10:15.240> block 00:10:15.350 --> 00:10:15.360 align:start position:0% example a block producer or a block 00:10:15.360 --> 00:10:17.329 align:start position:0% example a block producer or a block producer<00:10:15.779> can<00:10:15.899> delegate<00:10:16.260> this<00:10:16.560> kind<00:10:17.160> of 00:10:17.329 --> 00:10:17.339 align:start position:0% producer can delegate this kind of 00:10:17.339 --> 00:10:18.650 align:start position:0% producer can delegate this kind of aggregation<00:10:17.700> to<00:10:17.880> someone<00:10:18.060> else<00:10:18.240> some<00:10:18.480> other 00:10:18.650 --> 00:10:18.660 align:start position:0% aggregation to someone else some other 00:10:18.660 --> 00:10:20.090 align:start position:0% aggregation to someone else some other actors 00:10:20.090 --> 00:10:20.100 align:start position:0% actors 00:10:20.100 --> 00:10:21.769 align:start position:0% actors now<00:10:20.700> let's<00:10:21.000> talk<00:10:21.180> a<00:10:21.300> little<00:10:21.360> bit<00:10:21.480> more<00:10:21.600> about 00:10:21.769 --> 00:10:21.779 align:start position:0% now let's talk a little bit more about 00:10:21.779 --> 00:10:23.389 align:start position:0% now let's talk a little bit more about what<00:10:22.080> this<00:10:22.320> concept<00:10:22.680> of<00:10:22.860> local<00:10:23.100> versus 00:10:23.389 --> 00:10:23.399 align:start position:0% what this concept of local versus 00:10:23.399 --> 00:10:25.370 align:start position:0% what this concept of local versus Network<00:10:23.700> execution<00:10:24.240> so<00:10:24.779> in<00:10:24.899> a<00:10:25.080> traditional 00:10:25.370 --> 00:10:25.380 align:start position:0% Network execution so in a traditional 00:10:25.380 --> 00:10:27.470 align:start position:0% Network execution so in a traditional kind<00:10:25.620> of<00:10:25.740> uh<00:10:26.160> model<00:10:26.339> okay<00:10:26.700> when<00:10:26.940> we<00:10:27.060> execute<00:10:27.360> a 00:10:27.470 --> 00:10:27.480 align:start position:0% kind of uh model okay when we execute a 00:10:27.480 --> 00:10:29.210 align:start position:0% kind of uh model okay when we execute a transaction<00:10:27.720> we<00:10:28.080> have<00:10:28.200> you<00:10:28.560> know<00:10:28.680> a<00:10:28.860> step<00:10:28.980> that 00:10:29.210 --> 00:10:29.220 align:start position:0% transaction we have you know a step that 00:10:29.220 --> 00:10:30.470 align:start position:0% transaction we have you know a step that prepares<00:10:29.580> some<00:10:29.760> inputs<00:10:30.000> for<00:10:30.120> the<00:10:30.240> transaction 00:10:30.470 --> 00:10:30.480 align:start position:0% prepares some inputs for the transaction 00:10:30.480 --> 00:10:32.630 align:start position:0% prepares some inputs for the transaction signs<00:10:31.019> the<00:10:31.080> transaction<00:10:31.380> and<00:10:31.620> so<00:10:31.740> forth<00:10:31.980> then 00:10:32.630 --> 00:10:32.640 align:start position:0% signs the transaction and so forth then 00:10:32.640 --> 00:10:34.310 align:start position:0% signs the transaction and so forth then we<00:10:32.820> execute<00:10:33.300> it 00:10:34.310 --> 00:10:34.320 align:start position:0% we execute it 00:10:34.320 --> 00:10:36.590 align:start position:0% we execute it um<00:10:34.440> then<00:10:34.740> in<00:10:34.920> the<00:10:35.040> context<00:10:35.279> of<00:10:35.459> SDK<00:10:35.940> system<00:10:36.300> we 00:10:36.590 --> 00:10:36.600 align:start position:0% um then in the context of SDK system we 00:10:36.600 --> 00:10:37.850 align:start position:0% um then in the context of SDK system we generate<00:10:37.019> a<00:10:37.140> proof<00:10:37.380> for<00:10:37.500> this<00:10:37.560> transaction 00:10:37.850 --> 00:10:37.860 align:start position:0% generate a proof for this transaction 00:10:37.860 --> 00:10:39.170 align:start position:0% generate a proof for this transaction and<00:10:38.100> finally<00:10:38.339> we<00:10:38.519> get<00:10:38.640> this<00:10:38.820> transaction 00:10:39.170 --> 00:10:39.180 align:start position:0% and finally we get this transaction 00:10:39.180 --> 00:10:41.449 align:start position:0% and finally we get this transaction proof<00:10:39.660> that<00:10:40.440> you<00:10:40.620> know<00:10:40.740> according<00:10:41.160> to<00:10:41.279> the 00:10:41.449 --> 00:10:41.459 align:start position:0% proof that you know according to the 00:10:41.459 --> 00:10:42.650 align:start position:0% proof that you know according to the previous<00:10:41.580> slide<00:10:41.880> gets<00:10:42.180> aggregated<00:10:42.480> into 00:10:42.650 --> 00:10:42.660 align:start position:0% previous slide gets aggregated into 00:10:42.660 --> 00:10:44.269 align:start position:0% previous slide gets aggregated into batches<00:10:43.080> and<00:10:43.200> it<00:10:43.380> finally<00:10:43.740> end<00:10:43.920> UPS<00:10:44.160> in<00:10:44.220> the 00:10:44.269 --> 00:10:44.279 align:start position:0% batches and it finally end UPS in the 00:10:44.279 --> 00:10:47.090 align:start position:0% batches and it finally end UPS in the block<00:10:44.399> now<00:10:45.360> in<00:10:45.959> a<00:10:46.140> network<00:10:46.320> model<00:10:46.680> the<00:10:46.980> block 00:10:47.090 --> 00:10:47.100 align:start position:0% block now in a network model the block 00:10:47.100 --> 00:10:48.710 align:start position:0% block now in a network model the block producer<00:10:47.579> so<00:10:47.760> that<00:10:47.940> the<00:10:48.120> user<00:10:48.300> prepares<00:10:48.660> the 00:10:48.710 --> 00:10:48.720 align:start position:0% producer so that the user prepares the 00:10:48.720 --> 00:10:50.630 align:start position:0% producer so that the user prepares the transaction<00:10:49.079> sends<00:10:49.620> it<00:10:49.740> to<00:10:49.860> the 00:10:50.630 --> 00:10:50.640 align:start position:0% transaction sends it to the 00:10:50.640 --> 00:10:51.769 align:start position:0% transaction sends it to the um you<00:10:50.880> know<00:10:50.940> the<00:10:51.060> network<00:10:51.180> and<00:10:51.420> then<00:10:51.540> a<00:10:51.720> block 00:10:51.769 --> 00:10:51.779 align:start position:0% um you know the network and then a block 00:10:51.779 --> 00:10:53.030 align:start position:0% um you know the network and then a block producer<00:10:52.200> would<00:10:52.320> execute<00:10:52.620> this<00:10:52.740> transaction 00:10:53.030 --> 00:10:53.040 align:start position:0% producer would execute this transaction 00:10:53.040 --> 00:10:55.610 align:start position:0% producer would execute this transaction generator<00:10:53.519> proof<00:10:53.940> and<00:10:54.480> then<00:10:54.600> you<00:10:55.560> know 00:10:55.610 --> 00:10:55.620 align:start position:0% generator proof and then you know 00:10:55.620 --> 00:10:57.050 align:start position:0% generator proof and then you know aggregate<00:10:56.040> this<00:10:56.160> proof<00:10:56.399> as<00:10:56.519> I<00:10:56.700> described<00:10:56.940> on 00:10:57.050 --> 00:10:57.060 align:start position:0% aggregate this proof as I described on 00:10:57.060 --> 00:10:59.449 align:start position:0% aggregate this proof as I described on the<00:10:57.180> previous<00:10:57.240> slide<00:10:58.019> in<00:10:58.680> a<00:10:58.800> local<00:10:58.980> context 00:10:59.449 --> 00:10:59.459 align:start position:0% the previous slide in a local context 00:10:59.459 --> 00:11:01.190 align:start position:0% the previous slide in a local context the<00:10:59.820> user<00:11:00.120> can<00:11:00.240> actually<00:11:00.360> do<00:11:00.660> all<00:11:00.839> of<00:11:00.899> this<00:11:01.019> so 00:11:01.190 --> 00:11:01.200 align:start position:0% the user can actually do all of this so 00:11:01.200 --> 00:11:02.750 align:start position:0% the user can actually do all of this so the<00:11:01.440> user<00:11:01.740> can<00:11:01.980> both<00:11:02.220> prepare<00:11:02.640> the 00:11:02.750 --> 00:11:02.760 align:start position:0% the user can both prepare the 00:11:02.760 --> 00:11:04.550 align:start position:0% the user can both prepare the transaction<00:11:03.120> execute<00:11:03.720> it<00:11:03.839> and<00:11:04.019> generate<00:11:04.380> a 00:11:04.550 --> 00:11:04.560 align:start position:0% transaction execute it and generate a 00:11:04.560 --> 00:11:07.370 align:start position:0% transaction execute it and generate a transaction<00:11:04.800> proof<00:11:05.279> and<00:11:06.120> then<00:11:06.360> what<00:11:07.079> gets 00:11:07.370 --> 00:11:07.380 align:start position:0% transaction proof and then what gets 00:11:07.380 --> 00:11:08.750 align:start position:0% transaction proof and then what gets sent<00:11:07.500> to<00:11:07.680> the<00:11:07.800> network<00:11:07.920> is<00:11:08.160> actually<00:11:08.279> just<00:11:08.579> the 00:11:08.750 --> 00:11:08.760 align:start position:0% sent to the network is actually just the 00:11:08.760 --> 00:11:10.670 align:start position:0% sent to the network is actually just the transactional<00:11:09.180> proof<00:11:09.420> itself<00:11:09.660> and<00:11:10.320> then<00:11:10.440> the 00:11:10.670 --> 00:11:10.680 align:start position:0% transactional proof itself and then the 00:11:10.680 --> 00:11:12.530 align:start position:0% transactional proof itself and then the block<00:11:11.399> producer<00:11:11.820> doesn't<00:11:12.000> actually<00:11:12.180> need<00:11:12.420> to 00:11:12.530 --> 00:11:12.540 align:start position:0% block producer doesn't actually need to 00:11:12.540 --> 00:11:14.090 align:start position:0% block producer doesn't actually need to execute<00:11:12.899> the<00:11:13.019> transaction<00:11:13.380> and<00:11:13.620> doesn't<00:11:13.800> need 00:11:14.090 --> 00:11:14.100 align:start position:0% execute the transaction and doesn't need 00:11:14.100 --> 00:11:15.069 align:start position:0% execute the transaction and doesn't need to 00:11:15.069 --> 00:11:15.079 align:start position:0% to 00:11:15.079 --> 00:11:17.389 align:start position:0% to generate<00:11:16.079> the<00:11:16.260> proof<00:11:16.440> for<00:11:16.560> it<00:11:16.680> it<00:11:16.920> just<00:11:17.220> the 00:11:17.389 --> 00:11:17.399 align:start position:0% generate the proof for it it just the 00:11:17.399 --> 00:11:18.829 align:start position:0% generate the proof for it it just the block<00:11:17.640> producer<00:11:18.060> just<00:11:18.180> needs<00:11:18.360> to<00:11:18.420> aggregate 00:11:18.829 --> 00:11:18.839 align:start position:0% block producer just needs to aggregate 00:11:18.839 --> 00:11:20.449 align:start position:0% block producer just needs to aggregate it<00:11:19.019> but<00:11:19.140> it<00:11:19.380> was<00:11:19.560> other<00:11:19.680> transactions<00:11:20.220> for 00:11:20.449 --> 00:11:20.459 align:start position:0% it but it was other transactions for 00:11:20.459 --> 00:11:22.970 align:start position:0% it but it was other transactions for which<00:11:20.940> it<00:11:21.060> has<00:11:21.240> generated<00:11:21.660> the<00:11:21.899> proofs 00:11:22.970 --> 00:11:22.980 align:start position:0% which it has generated the proofs 00:11:22.980 --> 00:11:24.769 align:start position:0% which it has generated the proofs um one<00:11:23.339> important<00:11:23.640> thing<00:11:23.760> to<00:11:23.880> note<00:11:24.000> is<00:11:24.240> how<00:11:24.660> do 00:11:24.769 --> 00:11:24.779 align:start position:0% um one important thing to note is how do 00:11:24.779 --> 00:11:26.329 align:start position:0% um one important thing to note is how do we<00:11:24.899> handle<00:11:25.140> shared<00:11:25.440> State<00:11:25.620> because<00:11:25.860> you<00:11:26.220> know 00:11:26.329 --> 00:11:26.339 align:start position:0% we handle shared State because you know 00:11:26.339 --> 00:11:28.009 align:start position:0% we handle shared State because you know it<00:11:26.640> works<00:11:26.880> what<00:11:27.060> I<00:11:27.240> described<00:11:27.540> works<00:11:27.839> very 00:11:28.009 --> 00:11:28.019 align:start position:0% it works what I described works very 00:11:28.019 --> 00:11:29.990 align:start position:0% it works what I described works very nice<00:11:28.560> when<00:11:28.860> you<00:11:28.980> have<00:11:29.160> like<00:11:29.339> transactions 00:11:29.990 --> 00:11:30.000 align:start position:0% nice when you have like transactions 00:11:30.000 --> 00:11:32.030 align:start position:0% nice when you have like transactions which<00:11:30.300> go<00:11:30.600> and<00:11:31.260> don't<00:11:31.440> touch<00:11:31.680> multiple 00:11:32.030 --> 00:11:32.040 align:start position:0% which go and don't touch multiple 00:11:32.040 --> 00:11:33.590 align:start position:0% which go and don't touch multiple accounts<00:11:32.399> or<00:11:32.519> like<00:11:32.760> when<00:11:32.940> you<00:11:33.120> have<00:11:33.360> nodes 00:11:33.590 --> 00:11:33.600 align:start position:0% accounts or like when you have nodes 00:11:33.600 --> 00:11:34.850 align:start position:0% accounts or like when you have nodes that<00:11:33.779> go<00:11:33.959> to<00:11:34.019> different<00:11:34.200> accounts<00:11:34.620> and<00:11:34.740> so 00:11:34.850 --> 00:11:34.860 align:start position:0% that go to different accounts and so 00:11:34.860 --> 00:11:36.290 align:start position:0% that go to different accounts and so forth<00:11:35.100> but<00:11:35.579> let's<00:11:35.700> say<00:11:35.820> we<00:11:36.000> have<00:11:36.120> something 00:11:36.290 --> 00:11:36.300 align:start position:0% forth but let's say we have something 00:11:36.300 --> 00:11:38.210 align:start position:0% forth but let's say we have something like<00:11:36.480> a<00:11:36.660> uni<00:11:36.899> swap<00:11:37.140> situation<00:11:37.500> where<00:11:37.740> we<00:11:37.980> want 00:11:38.210 --> 00:11:38.220 align:start position:0% like a uni swap situation where we want 00:11:38.220 --> 00:11:39.949 align:start position:0% like a uni swap situation where we want we<00:11:38.940> have<00:11:39.060> several<00:11:39.300> accounts<00:11:39.600> that<00:11:39.720> want<00:11:39.839> to 00:11:39.949 --> 00:11:39.959 align:start position:0% we have several accounts that want to 00:11:39.959 --> 00:11:42.170 align:start position:0% we have several accounts that want to send<00:11:40.079> nodes<00:11:40.380> in<00:11:40.560> exchange<00:11:40.860> let's<00:11:41.459> say<00:11:41.700> assets 00:11:42.170 --> 00:11:42.180 align:start position:0% send nodes in exchange let's say assets 00:11:42.180 --> 00:11:44.630 align:start position:0% send nodes in exchange let's say assets for<00:11:42.660> some<00:11:42.839> other<00:11:42.959> assets<00:11:43.380> uh<00:11:43.800> using<00:11:44.100> uni<00:11:44.459> swap 00:11:44.630 --> 00:11:44.640 align:start position:0% for some other assets uh using uni swap 00:11:44.640 --> 00:11:45.410 align:start position:0% for some other assets uh using uni swap account 00:11:45.410 --> 00:11:45.420 align:start position:0% account 00:11:45.420 --> 00:11:47.690 align:start position:0% account so<00:11:45.959> in<00:11:46.140> the<00:11:46.500> way<00:11:46.560> we<00:11:46.740> would<00:11:46.860> do<00:11:46.980> it<00:11:47.160> is<00:11:47.339> that 00:11:47.690 --> 00:11:47.700 align:start position:0% so in the way we would do it is that 00:11:47.700 --> 00:11:49.850 align:start position:0% so in the way we would do it is that first<00:11:48.420> we<00:11:48.959> would<00:11:49.140> have<00:11:49.320> you<00:11:49.680> know<00:11:49.740> each 00:11:49.850 --> 00:11:49.860 align:start position:0% first we would have you know each 00:11:49.860 --> 00:11:51.530 align:start position:0% first we would have you know each account<00:11:50.040> generates<00:11:50.640> its<00:11:50.880> own<00:11:50.940> transaction<00:11:51.300> to 00:11:51.530 --> 00:11:51.540 align:start position:0% account generates its own transaction to 00:11:51.540 --> 00:11:53.150 align:start position:0% account generates its own transaction to create<00:11:51.720> a<00:11:51.839> node<00:11:52.079> that<00:11:52.260> targets<00:11:52.620> a<00:11:52.740> uni<00:11:52.920> swap 00:11:53.150 --> 00:11:53.160 align:start position:0% create a node that targets a uni swap 00:11:53.160 --> 00:11:54.410 align:start position:0% create a node that targets a uni swap account 00:11:54.410 --> 00:11:54.420 align:start position:0% account 00:11:54.420 --> 00:11:56.630 align:start position:0% account um<00:11:54.540> this<00:11:54.720> would<00:11:54.839> be<00:11:54.959> two<00:11:55.140> separate<00:11:55.560> kind<00:11:56.519> of 00:11:56.630 --> 00:11:56.640 align:start position:0% um this would be two separate kind of 00:11:56.640 --> 00:11:58.329 align:start position:0% um this would be two separate kind of logically<00:11:56.940> separate<00:11:57.240> transactions 00:11:58.329 --> 00:11:58.339 align:start position:0% logically separate transactions 00:11:58.339 --> 00:12:00.829 align:start position:0% logically separate transactions then<00:11:59.339> the<00:11:59.579> block<00:11:59.700> producer<00:12:00.180> will<00:12:00.300> generate<00:12:00.660> a 00:12:00.829 --> 00:12:00.839 align:start position:0% then the block producer will generate a 00:12:00.839 --> 00:12:02.389 align:start position:0% then the block producer will generate a third<00:12:00.899> transaction<00:12:01.320> that<00:12:01.620> would<00:12:01.800> consume<00:12:02.279> the 00:12:02.389 --> 00:12:02.399 align:start position:0% third transaction that would consume the 00:12:02.399 --> 00:12:03.889 align:start position:0% third transaction that would consume the first<00:12:02.579> two<00:12:02.760> nodes<00:12:03.000> in<00:12:03.240> a<00:12:03.360> single<00:12:03.600> transaction 00:12:03.889 --> 00:12:03.899 align:start position:0% first two nodes in a single transaction 00:12:03.899 --> 00:12:05.870 align:start position:0% first two nodes in a single transaction and<00:12:04.260> also<00:12:04.440> as<00:12:04.560> a<00:12:04.740> result<00:12:04.800> of<00:12:05.100> this<00:12:05.339> consumption 00:12:05.870 --> 00:12:05.880 align:start position:0% and also as a result of this consumption 00:12:05.880 --> 00:12:06.949 align:start position:0% and also as a result of this consumption of<00:12:06.000> this<00:12:06.060> node<00:12:06.300> that<00:12:06.420> would<00:12:06.540> generate<00:12:06.839> other 00:12:06.949 --> 00:12:06.959 align:start position:0% of this node that would generate other 00:12:06.959 --> 00:12:08.690 align:start position:0% of this node that would generate other two<00:12:07.200> nodes<00:12:07.440> that<00:12:07.680> would<00:12:07.860> kind<00:12:08.100> of<00:12:08.160> Target<00:12:08.339> back 00:12:08.690 --> 00:12:08.700 align:start position:0% two nodes that would kind of Target back 00:12:08.700 --> 00:12:11.150 align:start position:0% two nodes that would kind of Target back create<00:12:09.060> like<00:12:09.360> the<00:12:09.480> exchange<00:12:09.779> tokens<00:12:10.200> back<00:12:10.980> to 00:12:11.150 --> 00:12:11.160 align:start position:0% create like the exchange tokens back to 00:12:11.160 --> 00:12:13.250 align:start position:0% create like the exchange tokens back to their<00:12:11.339> original<00:12:11.459> accounts<00:12:12.480> and<00:12:12.959> then<00:12:13.079> we 00:12:13.250 --> 00:12:13.260 align:start position:0% their original accounts and then we 00:12:13.260 --> 00:12:14.509 align:start position:0% their original accounts and then we would<00:12:13.800> um 00:12:14.509 --> 00:12:14.519 align:start position:0% would um 00:12:14.519 --> 00:12:16.910 align:start position:0% would um and<00:12:15.180> then<00:12:15.360> we<00:12:15.720> would<00:12:15.899> have<00:12:16.079> the<00:12:16.440> you<00:12:16.860> know 00:12:16.910 --> 00:12:16.920 align:start position:0% and then we would have the you know 00:12:16.920 --> 00:12:19.009 align:start position:0% and then we would have the you know additional<00:12:17.519> transactions<00:12:18.060> that<00:12:18.360> uh<00:12:18.720> the 00:12:19.009 --> 00:12:19.019 align:start position:0% additional transactions that uh the 00:12:19.019 --> 00:12:20.569 align:start position:0% additional transactions that uh the accounts<00:12:19.440> the<00:12:19.560> users<00:12:19.800> of<00:12:19.980> accounts<00:12:20.339> one<00:12:20.399> and 00:12:20.569 --> 00:12:20.579 align:start position:0% accounts the users of accounts one and 00:12:20.579 --> 00:12:22.069 align:start position:0% accounts the users of accounts one and two<00:12:20.700> would<00:12:20.880> execute<00:12:21.240> to<00:12:21.360> consume<00:12:21.779> kind<00:12:21.959> of 00:12:22.069 --> 00:12:22.079 align:start position:0% two would execute to consume kind of 00:12:22.079 --> 00:12:24.590 align:start position:0% two would execute to consume kind of this<00:12:22.200> nodes<00:12:22.500> back<00:12:22.740> into<00:12:22.860> the<00:12:23.279> uh<00:12:24.180> back<00:12:24.480> into 00:12:24.590 --> 00:12:24.600 align:start position:0% this nodes back into the uh back into 00:12:24.600 --> 00:12:27.170 align:start position:0% this nodes back into the uh back into the<00:12:24.959> their<00:12:25.260> respective<00:12:25.740> accounts<00:12:26.459> so 00:12:27.170 --> 00:12:27.180 align:start position:0% the their respective accounts so 00:12:27.180 --> 00:12:29.870 align:start position:0% the their respective accounts so basically<00:12:27.600> in<00:12:27.779> this<00:12:27.959> model<00:12:28.579> we<00:12:29.579> still<00:12:29.700> have 00:12:29.870 --> 00:12:29.880 align:start position:0% basically in this model we still have 00:12:29.880 --> 00:12:31.490 align:start position:0% basically in this model we still have this<00:12:30.060> ability<00:12:30.300> to<00:12:30.540> interact<00:12:30.779> with<00:12:30.959> a<00:12:31.140> contract 00:12:31.490 --> 00:12:31.500 align:start position:0% this ability to interact with a contract 00:12:31.500 --> 00:12:34.130 align:start position:0% this ability to interact with a contract or<00:12:31.980> account<00:12:32.160> with<00:12:32.399> a<00:12:32.579> shared<00:12:32.820> State<00:12:33.019> just<00:12:34.019> in 00:12:34.130 --> 00:12:34.140 align:start position:0% or account with a shared State just in 00:12:34.140 --> 00:12:37.190 align:start position:0% or account with a shared State just in this<00:12:34.260> case<00:12:34.380> the<00:12:35.000> transaction<00:12:36.000> that<00:12:36.779> interacts 00:12:37.190 --> 00:12:37.200 align:start position:0% this case the transaction that interacts 00:12:37.200 --> 00:12:38.569 align:start position:0% this case the transaction that interacts with<00:12:37.260> the<00:12:37.500> account<00:12:37.860> of<00:12:38.100> the<00:12:38.220> shared<00:12:38.459> State 00:12:38.569 --> 00:12:38.579 align:start position:0% with the account of the shared State 00:12:38.579 --> 00:12:40.190 align:start position:0% with the account of the shared State needs<00:12:38.820> to<00:12:38.880> be<00:12:39.000> a<00:12:39.060> network<00:12:39.240> transactions<00:12:39.899> it's 00:12:40.190 --> 00:12:40.200 align:start position:0% needs to be a network transactions it's 00:12:40.200 --> 00:12:41.870 align:start position:0% needs to be a network transactions it's not<00:12:40.320> a<00:12:40.560> locally<00:12:40.860> executed<00:12:41.339> transaction<00:12:41.579> must 00:12:41.870 --> 00:12:41.880 align:start position:0% not a locally executed transaction must 00:12:41.880 --> 00:12:43.670 align:start position:0% not a locally executed transaction must be<00:12:42.000> executed<00:12:42.480> by<00:12:42.600> the<00:12:42.720> network<00:12:42.899> or<00:12:43.440> the<00:12:43.560> block 00:12:43.670 --> 00:12:43.680 align:start position:0% be executed by the network or the block 00:12:43.680 --> 00:12:44.990 align:start position:0% be executed by the network or the block producer<00:12:44.160> because<00:12:44.279> the<00:12:44.459> block<00:12:44.519> producer 00:12:44.990 --> 00:12:45.000 align:start position:0% producer because the block producer 00:12:45.000 --> 00:12:47.269 align:start position:0% producer because the block producer needs<00:12:45.240> to<00:12:45.300> sequence<00:12:46.019> the<00:12:46.200> nodes<00:12:46.500> according<00:12:47.160> to 00:12:47.269 --> 00:12:47.279 align:start position:0% needs to sequence the nodes according to 00:12:47.279 --> 00:12:48.949 align:start position:0% needs to sequence the nodes according to whatever<00:12:47.459> logic<00:12:48.060> they<00:12:48.180> want<00:12:48.300> to<00:12:48.420> do<00:12:48.540> and<00:12:48.839> then 00:12:48.949 --> 00:12:48.959 align:start position:0% whatever logic they want to do and then 00:12:48.959 --> 00:12:50.329 align:start position:0% whatever logic they want to do and then execute<00:12:49.320> all<00:12:49.500> of<00:12:49.620> the<00:12:49.680> nodes<00:12:49.860> against<00:12:50.040> the 00:12:50.329 --> 00:12:50.339 align:start position:0% execute all of the nodes against the 00:12:50.339 --> 00:12:52.490 align:start position:0% execute all of the nodes against the same<00:12:50.519> account 00:12:52.490 --> 00:12:52.500 align:start position:0% same account 00:12:52.500 --> 00:12:54.829 align:start position:0% same account now<00:12:53.160> just<00:12:53.519> to<00:12:53.639> kind<00:12:53.820> of<00:12:53.880> summarize<00:12:54.240> this<00:12:54.540> you 00:12:54.829 --> 00:12:54.839 align:start position:0% now just to kind of summarize this you 00:12:54.839 --> 00:12:56.030 align:start position:0% now just to kind of summarize this you know<00:12:54.959> pros<00:12:55.260> and<00:12:55.320> cons<00:12:55.440> of<00:12:55.680> local<00:12:55.800> versus 00:12:56.030 --> 00:12:56.040 align:start position:0% know pros and cons of local versus 00:12:56.040 --> 00:12:57.949 align:start position:0% know pros and cons of local versus Network<00:12:56.339> execution<00:12:56.880> so<00:12:57.300> if<00:12:57.480> we<00:12:57.600> want<00:12:57.720> to<00:12:57.839> have 00:12:57.949 --> 00:12:57.959 align:start position:0% Network execution so if we want to have 00:12:57.959 --> 00:12:59.750 align:start position:0% Network execution so if we want to have a<00:12:58.139> shared<00:12:58.440> State<00:12:58.680> kind<00:12:59.220> of<00:12:59.399> an<00:12:59.459> account<00:12:59.579> with 00:12:59.750 --> 00:12:59.760 align:start position:0% a shared State kind of an account with 00:12:59.760 --> 00:13:00.829 align:start position:0% a shared State kind of an account with share<00:12:59.940> State<00:13:00.180> we<00:13:00.360> cannot<00:13:00.540> use<00:13:00.660> local 00:13:00.829 --> 00:13:00.839 align:start position:0% share State we cannot use local 00:13:00.839 --> 00:13:02.150 align:start position:0% share State we cannot use local transactions<00:13:01.380> but<00:13:01.560> we<00:13:01.680> can<00:13:01.800> use<00:13:01.980> Network 00:13:02.150 --> 00:13:02.160 align:start position:0% transactions but we can use Network 00:13:02.160 --> 00:13:03.530 align:start position:0% transactions but we can use Network transactions 00:13:03.530 --> 00:13:03.540 align:start position:0% transactions 00:13:03.540 --> 00:13:05.870 align:start position:0% transactions now<00:13:04.320> if<00:13:04.680> we<00:13:04.800> use<00:13:04.920> a<00:13:05.040> local<00:13:05.160> transaction<00:13:05.519> we<00:13:05.760> can 00:13:05.870 --> 00:13:05.880 align:start position:0% now if we use a local transaction we can 00:13:05.880 --> 00:13:08.449 align:start position:0% now if we use a local transaction we can have<00:13:06.000> privacy<00:13:06.480> because<00:13:07.380> nobody<00:13:08.040> actually<00:13:08.220> on 00:13:08.449 --> 00:13:08.459 align:start position:0% have privacy because nobody actually on 00:13:08.459 --> 00:13:09.530 align:start position:0% have privacy because nobody actually on a<00:13:08.579> network<00:13:08.700> needs<00:13:09.000> to<00:13:09.060> execute<00:13:09.420> those 00:13:09.530 --> 00:13:09.540 align:start position:0% a network needs to execute those 00:13:09.540 --> 00:13:10.910 align:start position:0% a network needs to execute those transactions 00:13:10.910 --> 00:13:10.920 align:start position:0% transactions 00:13:10.920 --> 00:13:12.230 align:start position:0% transactions um<00:13:10.980> we<00:13:11.160> cannot<00:13:11.339> have<00:13:11.459> privacy<00:13:11.880> with<00:13:12.060> network 00:13:12.230 --> 00:13:12.240 align:start position:0% um we cannot have privacy with network 00:13:12.240 --> 00:13:13.370 align:start position:0% um we cannot have privacy with network transactions<00:13:12.720> because<00:13:12.839> obviously<00:13:13.200> somebody 00:13:13.370 --> 00:13:13.380 align:start position:0% transactions because obviously somebody 00:13:13.380 --> 00:13:15.889 align:start position:0% transactions because obviously somebody needs<00:13:13.740> to<00:13:13.800> execute<00:13:14.160> them<00:13:14.760> now<00:13:15.180> generating 00:13:15.889 --> 00:13:15.899 align:start position:0% needs to execute them now generating 00:13:15.899 --> 00:13:18.050 align:start position:0% needs to execute them now generating proofs<00:13:16.440> is<00:13:16.740> a<00:13:16.980> fairly<00:13:17.579> computationally 00:13:18.050 --> 00:13:18.060 align:start position:0% proofs is a fairly computationally 00:13:18.060 --> 00:13:20.090 align:start position:0% proofs is a fairly computationally intensive<00:13:18.480> process<00:13:18.839> so<00:13:19.200> the<00:13:19.500> client<00:13:19.740> Hardware 00:13:20.090 --> 00:13:20.100 align:start position:0% intensive process so the client Hardware 00:13:20.100 --> 00:13:22.069 align:start position:0% intensive process so the client Hardware requirements<00:13:20.820> might<00:13:21.000> be<00:13:21.180> high<00:13:21.420> for<00:13:21.839> local 00:13:22.069 --> 00:13:22.079 align:start position:0% requirements might be high for local 00:13:22.079 --> 00:13:23.290 align:start position:0% requirements might be high for local transactions 00:13:23.290 --> 00:13:23.300 align:start position:0% transactions 00:13:23.300 --> 00:13:25.670 align:start position:0% transactions but<00:13:24.300> on<00:13:24.600> the<00:13:24.720> flip<00:13:24.959> side<00:13:25.079> because<00:13:25.440> you 00:13:25.670 --> 00:13:25.680 align:start position:0% but on the flip side because you 00:13:25.680 --> 00:13:27.590 align:start position:0% but on the flip side because you generated<00:13:26.040> the<00:13:26.220> proof<00:13:26.459> locally<00:13:26.760> there<00:13:27.420> is 00:13:27.590 --> 00:13:27.600 align:start position:0% generated the proof locally there is 00:13:27.600 --> 00:13:29.210 align:start position:0% generated the proof locally there is much<00:13:27.720> less<00:13:27.899> work<00:13:28.200> than<00:13:28.440> a<00:13:28.620> Blog<00:13:28.800> producer 00:13:29.210 --> 00:13:29.220 align:start position:0% much less work than a Blog producer 00:13:29.220 --> 00:13:30.829 align:start position:0% much less work than a Blog producer needs<00:13:29.459> to<00:13:29.519> do<00:13:29.639> they<00:13:30.240> don't<00:13:30.360> need<00:13:30.480> to<00:13:30.540> generate 00:13:30.829 --> 00:13:30.839 align:start position:0% needs to do they don't need to generate 00:13:30.839 --> 00:13:32.210 align:start position:0% needs to do they don't need to generate the<00:13:30.959> proof<00:13:31.139> for<00:13:31.500> the<00:13:31.560> transaction<00:13:31.860> they<00:13:32.100> don't 00:13:32.210 --> 00:13:32.220 align:start position:0% the proof for the transaction they don't 00:13:32.220 --> 00:13:33.590 align:start position:0% the proof for the transaction they don't need<00:13:32.339> to<00:13:32.399> execute<00:13:32.700> the<00:13:32.820> transaction<00:13:33.060> so<00:13:33.420> the 00:13:33.590 --> 00:13:33.600 align:start position:0% need to execute the transaction so the 00:13:33.600 --> 00:13:35.150 align:start position:0% need to execute the transaction so the fees<00:13:33.839> for<00:13:34.079> such<00:13:34.380> transactions<00:13:34.800> for<00:13:35.040> local 00:13:35.150 --> 00:13:35.160 align:start position:0% fees for such transactions for local 00:13:35.160 --> 00:13:36.889 align:start position:0% fees for such transactions for local transactions<00:13:35.940> would<00:13:36.120> be<00:13:36.240> lower<00:13:36.360> than<00:13:36.540> for<00:13:36.720> the 00:13:36.889 --> 00:13:36.899 align:start position:0% transactions would be lower than for the 00:13:36.899 --> 00:13:38.810 align:start position:0% transactions would be lower than for the ones<00:13:37.200> that<00:13:37.380> are<00:13:37.620> requested<00:13:38.459> for<00:13:38.579> the<00:13:38.700> network 00:13:38.810 --> 00:13:38.820 align:start position:0% ones that are requested for the network 00:13:38.820 --> 00:13:41.870 align:start position:0% ones that are requested for the network to<00:13:39.120> execute<00:13:39.620> now<00:13:40.620> the<00:13:41.279> next<00:13:41.339> thing<00:13:41.519> I<00:13:41.639> want<00:13:41.760> to 00:13:41.870 --> 00:13:41.880 align:start position:0% to execute now the next thing I want to 00:13:41.880 --> 00:13:43.550 align:start position:0% to execute now the next thing I want to talk<00:13:41.940> about<00:13:42.060> is<00:13:42.420> what<00:13:42.779> kind<00:13:42.959> of<00:13:43.019> a<00:13:43.139> state<00:13:43.320> model 00:13:43.550 --> 00:13:43.560 align:start position:0% talk about is what kind of a state model 00:13:43.560 --> 00:13:46.310 align:start position:0% talk about is what kind of a state model do<00:13:43.860> we<00:13:43.980> need<00:13:44.160> to<00:13:44.459> support<00:13:45.079> this<00:13:46.079> type<00:13:46.200> of 00:13:46.310 --> 00:13:46.320 align:start position:0% do we need to support this type of 00:13:46.320 --> 00:13:48.110 align:start position:0% do we need to support this type of transaction<00:13:46.680> model<00:13:47.040> and<00:13:47.579> this<00:13:47.700> is<00:13:47.820> where<00:13:48.000> the 00:13:48.110 --> 00:13:48.120 align:start position:0% transaction model and this is where the 00:13:48.120 --> 00:13:50.090 align:start position:0% transaction model and this is where the uatxon<00:13:48.779> account<00:13:49.019> based<00:13:49.380> model<00:13:49.500> kind<00:13:49.740> of<00:13:49.860> comes 00:13:50.090 --> 00:13:50.100 align:start position:0% uatxon account based model kind of comes 00:13:50.100 --> 00:13:51.050 align:start position:0% uatxon account based model kind of comes together 00:13:51.050 --> 00:13:51.060 align:start position:0% together 00:13:51.060 --> 00:13:52.430 align:start position:0% together so 00:13:52.430 --> 00:13:52.440 align:start position:0% so 00:13:52.440 --> 00:13:54.230 align:start position:0% so um My<00:13:53.100> Little<00:13:53.279> roll<00:13:53.519> up<00:13:53.700> state<00:13:53.880> is<00:13:54.120> actually 00:13:54.230 --> 00:13:54.240 align:start position:0% um My Little roll up state is actually 00:13:54.240 --> 00:13:56.030 align:start position:0% um My Little roll up state is actually described<00:13:54.600> by<00:13:54.720> three<00:13:54.839> databases<00:13:55.380> usually<00:13:55.740> you 00:13:56.030 --> 00:13:56.040 align:start position:0% described by three databases usually you 00:13:56.040 --> 00:13:57.650 align:start position:0% described by three databases usually you have<00:13:56.160> a<00:13:56.279> single<00:13:56.459> database<00:13:56.820> you<00:13:57.060> have<00:13:57.240> usually 00:13:57.650 --> 00:13:57.660 align:start position:0% have a single database you have usually 00:13:57.660 --> 00:13:59.750 align:start position:0% have a single database you have usually an<00:13:58.019> account<00:13:58.260> database<00:13:58.740> or<00:13:59.100> you<00:13:59.399> know<00:13:59.519> in<00:13:59.639> each 00:13:59.750 --> 00:13:59.760 align:start position:0% an account database or you know in each 00:13:59.760 --> 00:14:01.670 align:start position:0% an account database or you know in each Excel<00:14:00.120> context<00:14:00.360> you<00:14:00.540> have<00:14:00.660> a<00:14:00.899> kind<00:14:01.079> of<00:14:01.139> ATX<00:14:01.500> or 00:14:01.670 --> 00:14:01.680 align:start position:0% Excel context you have a kind of ATX or 00:14:01.680 --> 00:14:03.470 align:start position:0% Excel context you have a kind of ATX or database<00:14:02.040> but<00:14:02.639> in<00:14:02.820> our<00:14:02.940> context<00:14:03.240> actually 00:14:03.470 --> 00:14:03.480 align:start position:0% database but in our context actually 00:14:03.480 --> 00:14:05.030 align:start position:0% database but in our context actually three<00:14:03.839> separate<00:14:04.200> databases<00:14:04.560> there<00:14:04.800> is<00:14:04.920> an 00:14:05.030 --> 00:14:05.040 align:start position:0% three separate databases there is an 00:14:05.040 --> 00:14:06.470 align:start position:0% three separate databases there is an account<00:14:05.160> database<00:14:05.639> there<00:14:06.060> is<00:14:06.240> a<00:14:06.300> nodes 00:14:06.470 --> 00:14:06.480 align:start position:0% account database there is a nodes 00:14:06.480 --> 00:14:07.910 align:start position:0% account database there is a nodes database<00:14:06.899> and<00:14:07.079> there<00:14:07.320> is<00:14:07.500> a<00:14:07.560> nullifier 00:14:07.910 --> 00:14:07.920 align:start position:0% database and there is a nullifier 00:14:07.920 --> 00:14:10.009 align:start position:0% database and there is a nullifier database<00:14:08.220> and<00:14:08.399> I'll<00:14:08.519> explain<00:14:08.639> why<00:14:09.540> you<00:14:09.959> know 00:14:10.009 --> 00:14:10.019 align:start position:0% database and I'll explain why you know 00:14:10.019 --> 00:14:11.990 align:start position:0% database and I'll explain why you know why<00:14:10.200> all<00:14:10.380> of<00:14:10.500> them<00:14:10.560> are<00:14:10.680> needed<00:14:10.980> and<00:14:11.760> then<00:14:11.820> in 00:14:11.990 --> 00:14:12.000 align:start position:0% why all of them are needed and then in 00:14:12.000 --> 00:14:13.670 align:start position:0% why all of them are needed and then in our<00:14:12.180> case<00:14:12.360> updates<00:14:12.720> to<00:14:12.959> all<00:14:13.019> of<00:14:13.139> this<00:14:13.260> three 00:14:13.670 --> 00:14:13.680 align:start position:0% our case updates to all of this three 00:14:13.680 --> 00:14:15.110 align:start position:0% our case updates to all of this three database<00:14:13.920> so<00:14:14.040> like<00:14:14.220> when<00:14:14.339> you<00:14:14.459> have<00:14:14.519> a<00:14:14.639> Blog<00:14:14.880> a 00:14:15.110 --> 00:14:15.120 align:start position:0% database so like when you have a Blog a 00:14:15.120 --> 00:14:17.030 align:start position:0% database so like when you have a Blog a block<00:14:15.360> contains<00:14:15.899> information<00:14:16.079> that<00:14:16.620> updates 00:14:17.030 --> 00:14:17.040 align:start position:0% block contains information that updates 00:14:17.040 --> 00:14:18.530 align:start position:0% block contains information that updates all<00:14:17.220> of<00:14:17.339> the<00:14:17.459> three<00:14:17.579> databases<00:14:18.060> and<00:14:18.300> you<00:14:18.480> know 00:14:18.530 --> 00:14:18.540 align:start position:0% all of the three databases and you know 00:14:18.540 --> 00:14:21.410 align:start position:0% all of the three databases and you know takes<00:14:18.779> the<00:14:19.019> state<00:14:19.260> of<00:14:19.500> the<00:14:19.760> network<00:14:20.760> from<00:14:21.180> you 00:14:21.410 --> 00:14:21.420 align:start position:0% takes the state of the network from you 00:14:21.420 --> 00:14:25.069 align:start position:0% takes the state of the network from you know<00:14:21.540> stay<00:14:21.720> tuned<00:14:21.899> to<00:14:22.139> extend<00:14:22.380> n<00:14:23.040> plus<00:14:23.220> one 00:14:25.069 --> 00:14:25.079 align:start position:0% know stay tuned to extend n plus one 00:14:25.079 --> 00:14:25.610 align:start position:0% know stay tuned to extend n plus one um 00:14:25.610 --> 00:14:25.620 align:start position:0% um 00:14:25.620 --> 00:14:27.829 align:start position:0% um account<00:14:26.100> database<00:14:26.639> account<00:14:26.940> database<00:14:27.420> holds 00:14:27.829 --> 00:14:27.839 align:start position:0% account database account database holds 00:14:27.839 --> 00:14:30.350 align:start position:0% account database account database holds all<00:14:28.079> of<00:14:28.260> the<00:14:28.620> you<00:14:29.519> know<00:14:29.579> current<00:14:29.820> states<00:14:30.120> of 00:14:30.350 --> 00:14:30.360 align:start position:0% all of the you know current states of 00:14:30.360 --> 00:14:32.870 align:start position:0% all of the you know current states of their<00:14:30.480> accounts<00:14:31.200> and<00:14:32.160> we<00:14:32.279> use<00:14:32.399> the<00:14:32.579> sparse 00:14:32.870 --> 00:14:32.880 align:start position:0% their accounts and we use the sparse 00:14:32.880 --> 00:14:37.250 align:start position:0% their accounts and we use the sparse Merkle<00:14:33.180> tree<00:14:33.440> to<00:14:34.579> kind<00:14:35.579> of<00:14:35.760> uh<00:14:36.480> as<00:14:36.899> a<00:14:37.079> data 00:14:37.250 --> 00:14:37.260 align:start position:0% Merkle tree to kind of uh as a data 00:14:37.260 --> 00:14:39.410 align:start position:0% Merkle tree to kind of uh as a data structure<00:14:37.500> that<00:14:37.680> holds<00:14:37.920> this<00:14:38.040> information<00:14:38.420> uh 00:14:39.410 --> 00:14:39.420 align:start position:0% structure that holds this information uh 00:14:39.420 --> 00:14:41.150 align:start position:0% structure that holds this information uh and<00:14:39.720> the<00:14:40.019> sparse<00:14:40.320> Michael<00:14:40.440> tree<00:14:40.680> Maps<00:14:41.040> account 00:14:41.150 --> 00:14:41.160 align:start position:0% and the sparse Michael tree Maps account 00:14:41.160 --> 00:14:44.930 align:start position:0% and the sparse Michael tree Maps account IDs<00:14:41.760> to<00:14:42.000> account<00:14:42.360> hashes<00:14:43.440> but<00:14:44.339> we<00:14:44.519> have<00:14:44.639> one 00:14:44.930 --> 00:14:44.940 align:start position:0% IDs to account hashes but we have one 00:14:44.940 --> 00:14:46.129 align:start position:0% IDs to account hashes but we have one kind<00:14:45.060> of<00:14:45.120> twist<00:14:45.360> to<00:14:45.480> this<00:14:45.660> we<00:14:45.839> have<00:14:45.959> two 00:14:46.129 --> 00:14:46.139 align:start position:0% kind of twist to this we have two 00:14:46.139 --> 00:14:47.509 align:start position:0% kind of twist to this we have two different<00:14:46.320> types<00:14:46.680> of<00:14:46.800> two<00:14:47.040> different<00:14:47.220> modes 00:14:47.509 --> 00:14:47.519 align:start position:0% different types of two different modes 00:14:47.519 --> 00:14:49.970 align:start position:0% different types of two different modes of<00:14:47.639> storing<00:14:47.940> accounts<00:14:48.360> in<00:14:48.540> this<00:14:48.720> database<00:14:49.380> the 00:14:49.970 --> 00:14:49.980 align:start position:0% of storing accounts in this database the 00:14:49.980 --> 00:14:51.470 align:start position:0% of storing accounts in this database the first<00:14:50.100> one<00:14:50.220> is<00:14:50.399> on<00:14:50.579> chainstate<00:14:51.120> which<00:14:51.300> is 00:14:51.470 --> 00:14:51.480 align:start position:0% first one is on chainstate which is 00:14:51.480 --> 00:14:53.210 align:start position:0% first one is on chainstate which is basically<00:14:51.839> the<00:14:52.199> same<00:14:52.320> as<00:14:52.440> what<00:14:52.680> you<00:14:52.800> would<00:14:52.980> get 00:14:53.210 --> 00:14:53.220 align:start position:0% basically the same as what you would get 00:14:53.220 --> 00:14:55.430 align:start position:0% basically the same as what you would get was<00:14:53.399> ethereum<00:14:53.880> where<00:14:54.060> for<00:14:54.660> each<00:14:54.839> hash<00:14:55.079> the 00:14:55.430 --> 00:14:55.440 align:start position:0% was ethereum where for each hash the 00:14:55.440 --> 00:14:58.069 align:start position:0% was ethereum where for each hash the nodes<00:14:55.800> store<00:14:56.220> also<00:14:57.000> all<00:14:57.120> the<00:14:57.300> associated<00:14:57.720> data 00:14:58.069 --> 00:14:58.079 align:start position:0% nodes store also all the associated data 00:14:58.079 --> 00:14:59.329 align:start position:0% nodes store also all the associated data for<00:14:58.139> the<00:14:58.260> accounts<00:14:58.560> such<00:14:58.680> as<00:14:58.800> like<00:14:59.040> storage 00:14:59.329 --> 00:14:59.339 align:start position:0% for the accounts such as like storage 00:14:59.339 --> 00:15:02.210 align:start position:0% for the accounts such as like storage code<00:14:59.940> you<00:15:00.540> know<00:15:00.660> nons<00:15:00.959> and<00:15:01.199> so<00:15:01.260> forth 00:15:02.210 --> 00:15:02.220 align:start position:0% code you know nons and so forth 00:15:02.220 --> 00:15:04.069 align:start position:0% code you know nons and so forth but<00:15:02.699> there<00:15:02.880> is<00:15:03.000> also<00:15:03.180> an<00:15:03.360> option<00:15:03.540> to<00:15:03.720> do<00:15:03.839> just 00:15:04.069 --> 00:15:04.079 align:start position:0% but there is also an option to do just 00:15:04.079 --> 00:15:07.129 align:start position:0% but there is also an option to do just an<00:15:04.380> off-chain<00:15:04.800> state<00:15:05.040> where<00:15:05.779> what<00:15:06.779> the<00:15:06.959> node 00:15:07.129 --> 00:15:07.139 align:start position:0% an off-chain state where what the node 00:15:07.139 --> 00:15:08.710 align:start position:0% an off-chain state where what the node store<00:15:07.320> adjusts<00:15:07.740> the<00:15:07.800> hash<00:15:07.980> of<00:15:08.160> the<00:15:08.279> account 00:15:08.710 --> 00:15:08.720 align:start position:0% store adjusts the hash of the account 00:15:08.720 --> 00:15:12.410 align:start position:0% store adjusts the hash of the account and<00:15:09.720> uh<00:15:10.199> the<00:15:10.860> the<00:15:10.980> user<00:15:11.399> himself<00:15:11.820> or<00:15:12.060> herself 00:15:12.410 --> 00:15:12.420 align:start position:0% and uh the the user himself or herself 00:15:12.420 --> 00:15:14.930 align:start position:0% and uh the the user himself or herself is<00:15:12.600> responsible<00:15:13.079> for<00:15:13.560> storing<00:15:14.279> the<00:15:14.699> actual 00:15:14.930 --> 00:15:14.940 align:start position:0% is responsible for storing the actual 00:15:14.940 --> 00:15:17.769 align:start position:0% is responsible for storing the actual state<00:15:15.120> of<00:15:15.300> the<00:15:15.480> account<00:15:15.600> so<00:15:16.440> network 00:15:17.769 --> 00:15:17.779 align:start position:0% state of the account so network 00:15:17.779 --> 00:15:20.210 align:start position:0% state of the account so network not<00:15:18.779> Network<00:15:18.959> don't<00:15:19.380> do<00:15:19.620> not<00:15:19.800> store<00:15:19.980> the 00:15:20.210 --> 00:15:20.220 align:start position:0% not Network don't do not store the 00:15:20.220 --> 00:15:21.889 align:start position:0% not Network don't do not store the actual<00:15:20.399> account<00:15:20.579> State<00:15:20.880> let's<00:15:21.540> go<00:15:21.720> to<00:15:21.779> the 00:15:21.889 --> 00:15:21.899 align:start position:0% actual account State let's go to the 00:15:21.899 --> 00:15:23.750 align:start position:0% actual account State let's go to the nodes<00:15:22.139> database<00:15:22.500> next<00:15:22.740> the<00:15:23.160> nodes<00:15:23.399> database 00:15:23.750 --> 00:15:23.760 align:start position:0% nodes database next the nodes database 00:15:23.760 --> 00:15:25.310 align:start position:0% nodes database next the nodes database stores<00:15:24.060> all<00:15:24.360> nodes<00:15:24.720> that<00:15:24.899> have<00:15:25.019> been<00:15:25.139> ever 00:15:25.310 --> 00:15:25.320 align:start position:0% stores all nodes that have been ever 00:15:25.320 --> 00:15:27.530 align:start position:0% stores all nodes that have been ever created<00:15:25.740> and<00:15:26.339> for<00:15:26.519> this<00:15:26.639> we<00:15:26.880> use<00:15:27.000> a<00:15:27.180> miracle 00:15:27.530 --> 00:15:27.540 align:start position:0% created and for this we use a miracle 00:15:27.540 --> 00:15:29.030 align:start position:0% created and for this we use a miracle mountain<00:15:27.660> range<00:15:28.079> which<00:15:28.320> is<00:15:28.440> a<00:15:28.620> append<00:15:28.920> only 00:15:29.030 --> 00:15:29.040 align:start position:0% mountain range which is a append only 00:15:29.040 --> 00:15:32.210 align:start position:0% mountain range which is a append only accumulator<00:15:29.720> and<00:15:30.720> a<00:15:31.019> leaf<00:15:31.320> in<00:15:31.440> this<00:15:31.680> miracle 00:15:32.210 --> 00:15:32.220 align:start position:0% accumulator and a leaf in this miracle 00:15:32.220 --> 00:15:33.949 align:start position:0% accumulator and a leaf in this miracle mountain<00:15:32.339> range<00:15:32.639> is<00:15:32.820> basically<00:15:33.120> just<00:15:33.420> a<00:15:33.600> set 00:15:33.949 --> 00:15:33.959 align:start position:0% mountain range is basically just a set 00:15:33.959 --> 00:15:35.750 align:start position:0% mountain range is basically just a set of<00:15:34.199> nodes<00:15:34.680> that<00:15:34.860> were<00:15:34.980> created<00:15:35.279> in<00:15:35.399> a<00:15:35.579> specific 00:15:35.750 --> 00:15:35.760 align:start position:0% of nodes that were created in a specific 00:15:35.760 --> 00:15:36.590 align:start position:0% of nodes that were created in a specific block 00:15:36.590 --> 00:15:36.600 align:start position:0% block 00:15:36.600 --> 00:15:39.050 align:start position:0% block and<00:15:37.199> one<00:15:37.380> of<00:15:37.500> the<00:15:37.560> reasons<00:15:37.860> we<00:15:38.040> chose<00:15:38.279> this<00:15:38.699> uh 00:15:39.050 --> 00:15:39.060 align:start position:0% and one of the reasons we chose this uh 00:15:39.060 --> 00:15:40.490 align:start position:0% and one of the reasons we chose this uh there<00:15:39.480> are<00:15:39.600> a<00:15:39.839> number<00:15:39.959> of<00:15:40.019> reasons<00:15:40.260> why<00:15:40.380> we 00:15:40.490 --> 00:15:40.500 align:start position:0% there are a number of reasons why we 00:15:40.500 --> 00:15:41.689 align:start position:0% there are a number of reasons why we chose<00:15:40.620> the<00:15:40.740> miracle<00:15:41.040> mountain<00:15:41.160> region<00:15:41.579> it's 00:15:41.689 --> 00:15:41.699 align:start position:0% chose the miracle mountain region it's 00:15:41.699 --> 00:15:43.670 align:start position:0% chose the miracle mountain region it's very<00:15:42.000> convenient<00:15:42.420> for<00:15:42.779> a<00:15:43.079> number<00:15:43.260> of<00:15:43.380> purposes 00:15:43.670 --> 00:15:43.680 align:start position:0% very convenient for a number of purposes 00:15:43.680 --> 00:15:45.650 align:start position:0% very convenient for a number of purposes but<00:15:43.920> one<00:15:44.100> of<00:15:44.220> this<00:15:44.279> is<00:15:44.399> that 00:15:45.650 --> 00:15:45.660 align:start position:0% but one of this is that 00:15:45.660 --> 00:15:48.530 align:start position:0% but one of this is that um<00:15:46.199> you<00:15:46.860> can<00:15:46.980> extend<00:15:47.399> or<00:15:47.579> add<00:15:47.820> new<00:15:48.060> nodes<00:15:48.300> to 00:15:48.530 --> 00:15:48.540 align:start position:0% um you can extend or add new nodes to 00:15:48.540 --> 00:15:49.670 align:start position:0% um you can extend or add new nodes to this<00:15:48.720> accumulator<00:15:49.079> without<00:15:49.380> actually 00:15:49.670 --> 00:15:49.680 align:start position:0% this accumulator without actually 00:15:49.680 --> 00:15:51.050 align:start position:0% this accumulator without actually knowing<00:15:50.040> most<00:15:50.220> of<00:15:50.339> the<00:15:50.399> previous<00:15:50.519> nodes<00:15:50.940> so 00:15:51.050 --> 00:15:51.060 align:start position:0% knowing most of the previous nodes so 00:15:51.060 --> 00:15:53.150 align:start position:0% knowing most of the previous nodes so you<00:15:51.120> can<00:15:51.240> discard<00:15:51.480> the<00:15:51.660> big<00:15:51.839> part<00:15:52.079> of<00:15:52.260> the<00:15:52.500> uh 00:15:53.150 --> 00:15:53.160 align:start position:0% you can discard the big part of the uh 00:15:53.160 --> 00:15:55.310 align:start position:0% you can discard the big part of the uh of<00:15:53.459> the<00:15:53.639> nodes<00:15:53.760> database<00:15:54.240> and<00:15:54.839> still<00:15:54.959> be<00:15:55.139> able 00:15:55.310 --> 00:15:55.320 align:start position:0% of the nodes database and still be able 00:15:55.320 --> 00:15:58.009 align:start position:0% of the nodes database and still be able to<00:15:55.440> add<00:15:55.620> new<00:15:55.800> nodes<00:15:56.100> to<00:15:56.220> it<00:15:56.339> without<00:15:56.459> problem 00:15:58.009 --> 00:15:58.019 align:start position:0% to add new nodes to it without problem 00:15:58.019 --> 00:15:59.449 align:start position:0% to add new nodes to it without problem the<00:15:58.380> other<00:15:58.500> property<00:15:59.040> that<00:15:59.220> is<00:15:59.339> very 00:15:59.449 --> 00:15:59.459 align:start position:0% the other property that is very 00:15:59.459 --> 00:16:01.009 align:start position:0% the other property that is very important<00:15:59.760> is<00:15:59.940> EK<00:16:00.240> context<00:16:00.540> because<00:16:00.720> we<00:16:00.899> need 00:16:01.009 --> 00:16:01.019 align:start position:0% important is EK context because we need 00:16:01.019 --> 00:16:04.850 align:start position:0% important is EK context because we need to<00:16:01.139> prove<00:16:01.440> the<00:16:01.620> inclusion<00:16:02.040> of<00:16:03.000> um<00:16:03.500> you<00:16:04.500> need<00:16:04.680> we 00:16:04.850 --> 00:16:04.860 align:start position:0% to prove the inclusion of um you need we 00:16:04.860 --> 00:16:06.110 align:start position:0% to prove the inclusion of um you need we need<00:16:04.980> to<00:16:05.040> prove<00:16:05.220> that<00:16:05.339> we're<00:16:05.459> spending<00:16:05.820> a<00:16:05.940> node 00:16:06.110 --> 00:16:06.120 align:start position:0% need to prove that we're spending a node 00:16:06.120 --> 00:16:07.790 align:start position:0% need to prove that we're spending a node that<00:16:06.240> has<00:16:06.360> been<00:16:06.600> you<00:16:07.139> know<00:16:07.260> has<00:16:07.380> been<00:16:07.560> created 00:16:07.790 --> 00:16:07.800 align:start position:0% that has been you know has been created 00:16:07.800 --> 00:16:09.470 align:start position:0% that has been you know has been created at<00:16:07.980> some<00:16:08.100> point<00:16:08.220> in<00:16:08.339> the<00:16:08.519> past<00:16:08.639> is<00:16:09.180> that<00:16:09.300> the 00:16:09.470 --> 00:16:09.480 align:start position:0% at some point in the past is that the 00:16:09.480 --> 00:16:11.389 align:start position:0% at some point in the past is that the witness<00:16:09.660> kind<00:16:10.500> of<00:16:10.620> inclusion<00:16:10.980> witness<00:16:11.160> does 00:16:11.389 --> 00:16:11.399 align:start position:0% witness kind of inclusion witness does 00:16:11.399 --> 00:16:13.370 align:start position:0% witness kind of inclusion witness does not<00:16:11.519> become<00:16:11.760> stale<00:16:12.120> so<00:16:12.480> you<00:16:12.959> know<00:16:13.019> if<00:16:13.139> you<00:16:13.260> have 00:16:13.370 --> 00:16:13.380 align:start position:0% not become stale so you know if you have 00:16:13.380 --> 00:16:14.930 align:start position:0% not become stale so you know if you have a<00:16:13.440> mortal<00:16:13.740> path<00:16:14.040> it<00:16:14.339> actually<00:16:14.459> just<00:16:14.699> needs<00:16:14.880> to 00:16:14.930 --> 00:16:14.940 align:start position:0% a mortal path it actually just needs to 00:16:14.940 --> 00:16:16.189 align:start position:0% a mortal path it actually just needs to be<00:16:15.000> extended<00:16:15.360> from<00:16:15.480> time<00:16:15.660> to<00:16:15.779> time<00:16:15.899> very 00:16:16.189 --> 00:16:16.199 align:start position:0% be extended from time to time very 00:16:16.199 --> 00:16:18.110 align:start position:0% be extended from time to time very infrequently<00:16:16.800> but<00:16:17.160> it<00:16:17.279> doesn't<00:16:17.399> become<00:16:17.760> stale 00:16:18.110 --> 00:16:18.120 align:start position:0% infrequently but it doesn't become stale 00:16:18.120 --> 00:16:19.850 align:start position:0% infrequently but it doesn't become stale and<00:16:18.480> that<00:16:18.660> means<00:16:18.899> that<00:16:18.959> the<00:16:19.139> hdk<00:16:19.500> proof<00:16:19.740> that 00:16:19.850 --> 00:16:19.860 align:start position:0% and that means that the hdk proof that 00:16:19.860 --> 00:16:21.170 align:start position:0% and that means that the hdk proof that you<00:16:19.920> generate<00:16:20.220> does<00:16:20.519> not<00:16:20.579> become<00:16:20.820> absolute 00:16:21.170 --> 00:16:21.180 align:start position:0% you generate does not become absolute 00:16:21.180 --> 00:16:23.269 align:start position:0% you generate does not become absolute very<00:16:21.420> quickly<00:16:21.660> this<00:16:22.199> is<00:16:22.440> a<00:16:22.680> very<00:16:22.980> important 00:16:23.269 --> 00:16:23.279 align:start position:0% very quickly this is a very important 00:16:23.279 --> 00:16:24.889 align:start position:0% very quickly this is a very important SDK<00:16:23.699> context 00:16:24.889 --> 00:16:24.899 align:start position:0% SDK context 00:16:24.899 --> 00:16:28.189 align:start position:0% SDK context uh<00:16:25.560> and<00:16:25.740> then<00:16:25.860> lastly<00:16:26.420> we<00:16:27.420> have<00:16:27.540> the<00:16:27.720> nullify 00:16:28.189 --> 00:16:28.199 align:start position:0% uh and then lastly we have the nullify 00:16:28.199 --> 00:16:29.750 align:start position:0% uh and then lastly we have the nullify database<00:16:28.560> and<00:16:29.040> the<00:16:29.100> reason<00:16:29.220> why<00:16:29.399> we<00:16:29.579> need<00:16:29.639> this 00:16:29.750 --> 00:16:29.760 align:start position:0% database and the reason why we need this 00:16:29.760 --> 00:16:32.150 align:start position:0% database and the reason why we need this nullifier<00:16:30.180> database<00:16:30.480> is<00:16:30.660> that<00:16:31.440> um<00:16:31.440> you<00:16:32.040> know 00:16:32.150 --> 00:16:32.160 align:start position:0% nullifier database is that um you know 00:16:32.160 --> 00:16:33.829 align:start position:0% nullifier database is that um you know we<00:16:32.699> have<00:16:32.820> the<00:16:33.000> account<00:16:33.120> database<00:16:33.660> which 00:16:33.829 --> 00:16:33.839 align:start position:0% we have the account database which 00:16:33.839 --> 00:16:35.090 align:start position:0% we have the account database which stores<00:16:34.019> states<00:16:34.320> of<00:16:34.440> accounts<00:16:34.740> we<00:16:34.860> have<00:16:34.980> the 00:16:35.090 --> 00:16:35.100 align:start position:0% stores states of accounts we have the 00:16:35.100 --> 00:16:37.430 align:start position:0% stores states of accounts we have the nodes<00:16:35.279> database<00:16:35.639> that<00:16:35.880> stores<00:16:36.240> all<00:16:36.720> the<00:16:37.079> all 00:16:37.430 --> 00:16:37.440 align:start position:0% nodes database that stores all the all 00:16:37.440 --> 00:16:38.810 align:start position:0% nodes database that stores all the all the<00:16:37.560> nodes<00:16:37.740> ever<00:16:37.920> created<00:16:38.220> but<00:16:38.399> we<00:16:38.579> do<00:16:38.699> not 00:16:38.810 --> 00:16:38.820 align:start position:0% the nodes ever created but we do not 00:16:38.820 --> 00:16:42.290 align:start position:0% the nodes ever created but we do not remove<00:16:39.000> nodes<00:16:39.480> from<00:16:39.959> the<00:16:40.259> uh<00:16:40.880> nodes<00:16:41.880> database 00:16:42.290 --> 00:16:42.300 align:start position:0% remove nodes from the uh nodes database 00:16:42.300 --> 00:16:43.550 align:start position:0% remove nodes from the uh nodes database because<00:16:42.600> we<00:16:42.899> want<00:16:42.959> to<00:16:43.139> have<00:16:43.199> this<00:16:43.380> nice 00:16:43.550 --> 00:16:43.560 align:start position:0% because we want to have this nice 00:16:43.560 --> 00:16:44.930 align:start position:0% because we want to have this nice property<00:16:43.920> of<00:16:44.040> append<00:16:44.279> only<00:16:44.459> accumulator 00:16:44.930 --> 00:16:44.940 align:start position:0% property of append only accumulator 00:16:44.940 --> 00:16:47.449 align:start position:0% property of append only accumulator therefore<00:16:45.899> we<00:16:46.139> need<00:16:46.259> another<00:16:46.500> data<00:16:47.160> structure 00:16:47.449 --> 00:16:47.459 align:start position:0% therefore we need another data structure 00:16:47.459 --> 00:16:48.590 align:start position:0% therefore we need another data structure that<00:16:47.579> will<00:16:47.699> tell<00:16:47.820> us<00:16:47.880> which<00:16:48.060> nodes<00:16:48.300> have<00:16:48.480> been 00:16:48.590 --> 00:16:48.600 align:start position:0% that will tell us which nodes have been 00:16:48.600 --> 00:16:50.930 align:start position:0% that will tell us which nodes have been consumed<00:16:49.019> so<00:16:49.800> the<00:16:49.920> notify<00:16:50.339> database<00:16:50.699> is 00:16:50.930 --> 00:16:50.940 align:start position:0% consumed so the notify database is 00:16:50.940 --> 00:16:52.370 align:start position:0% consumed so the notify database is something<00:16:51.120> that<00:16:51.300> keeps<00:16:51.600> track<00:16:51.720> of<00:16:51.899> nodes<00:16:52.199> that 00:16:52.370 --> 00:16:52.380 align:start position:0% something that keeps track of nodes that 00:16:52.380 --> 00:16:54.470 align:start position:0% something that keeps track of nodes that have<00:16:52.500> been<00:16:52.620> consumed<00:16:53.040> and<00:16:53.820> for<00:16:54.000> this<00:16:54.120> we<00:16:54.300> also 00:16:54.470 --> 00:16:54.480 align:start position:0% have been consumed and for this we also 00:16:54.480 --> 00:16:55.730 align:start position:0% have been consumed and for this we also use<00:16:54.540> a<00:16:54.660> sparse<00:16:54.899> Merkel<00:16:55.199> tree<00:16:55.320> where<00:16:55.560> we 00:16:55.730 --> 00:16:55.740 align:start position:0% use a sparse Merkel tree where we 00:16:55.740 --> 00:16:58.009 align:start position:0% use a sparse Merkel tree where we basically<00:16:56.040> map<00:16:56.579> a<00:16:56.759> node<00:16:57.000> hash<00:16:57.240> to<00:16:57.420> either<00:16:57.600> zero 00:16:58.009 --> 00:16:58.019 align:start position:0% basically map a node hash to either zero 00:16:58.019 --> 00:16:59.749 align:start position:0% basically map a node hash to either zero one<00:16:58.199> zero<00:16:58.800> indicates<00:16:59.040> that<00:16:59.160> the<00:16:59.339> node<00:16:59.519> hasn't 00:16:59.749 --> 00:16:59.759 align:start position:0% one zero indicates that the node hasn't 00:16:59.759 --> 00:17:01.069 align:start position:0% one zero indicates that the node hasn't been<00:16:59.820> consumed<00:17:00.180> one<00:17:00.300> indicator<00:17:00.660> the<00:17:00.899> nodes 00:17:01.069 --> 00:17:01.079 align:start position:0% been consumed one indicator the nodes 00:17:01.079 --> 00:17:02.629 align:start position:0% been consumed one indicator the nodes has<00:17:01.259> been<00:17:01.380> consumed<00:17:01.740> so<00:17:02.160> whenever<00:17:02.459> we 00:17:02.629 --> 00:17:02.639 align:start position:0% has been consumed so whenever we 00:17:02.639 --> 00:17:04.370 align:start position:0% has been consumed so whenever we generate<00:17:03.000> a<00:17:03.180> proof<00:17:03.480> for<00:17:03.540> a<00:17:03.660> block<00:17:03.839> the<00:17:04.260> the 00:17:04.370 --> 00:17:04.380 align:start position:0% generate a proof for a block the the 00:17:04.380 --> 00:17:05.990 align:start position:0% generate a proof for a block the the proof<00:17:04.679> must<00:17:04.799> include<00:17:05.220> that<00:17:05.339> you<00:17:05.699> know<00:17:05.819> this 00:17:05.990 --> 00:17:06.000 align:start position:0% proof must include that you know this 00:17:06.000 --> 00:17:08.329 align:start position:0% proof must include that you know this node<00:17:06.299> existed<00:17:06.839> in<00:17:07.140> a<00:17:07.319> accounts<00:17:07.860> database<00:17:08.160> and 00:17:08.329 --> 00:17:08.339 align:start position:0% node existed in a accounts database and 00:17:08.339 --> 00:17:09.829 align:start position:0% node existed in a accounts database and it<00:17:08.459> did<00:17:08.579> not<00:17:08.699> exist<00:17:09.000> in<00:17:09.179> the<00:17:09.299> nullifier 00:17:09.829 --> 00:17:09.839 align:start position:0% it did not exist in the nullifier 00:17:09.839 --> 00:17:11.870 align:start position:0% it did not exist in the nullifier database 00:17:11.870 --> 00:17:11.880 align:start position:0% database 00:17:11.880 --> 00:17:12.890 align:start position:0% database um 00:17:12.890 --> 00:17:12.900 align:start position:0% um 00:17:12.900 --> 00:17:14.329 align:start position:0% um we<00:17:13.500> actually<00:17:13.620> have<00:17:13.860> a<00:17:14.040> slightly<00:17:14.280> more 00:17:14.329 --> 00:17:14.339 align:start position:0% we actually have a slightly more 00:17:14.339 --> 00:17:16.549 align:start position:0% we actually have a slightly more sophisticated<00:17:14.819> data<00:17:15.240> structure<00:17:15.540> where<00:17:16.319> there 00:17:16.549 --> 00:17:16.559 align:start position:0% sophisticated data structure where there 00:17:16.559 --> 00:17:18.049 align:start position:0% sophisticated data structure where there are<00:17:16.740> multiple<00:17:16.919> epochs<00:17:17.520> and<00:17:17.579> you<00:17:17.819> know<00:17:17.880> those 00:17:18.049 --> 00:17:18.059 align:start position:0% are multiple epochs and you know those 00:17:18.059 --> 00:17:19.250 align:start position:0% are multiple epochs and you know those are<00:17:18.240> time<00:17:18.360> periods<00:17:18.720> and<00:17:18.839> for<00:17:18.959> each<00:17:19.079> airport 00:17:19.250 --> 00:17:19.260 align:start position:0% are time periods and for each airport 00:17:19.260 --> 00:17:21.530 align:start position:0% are time periods and for each airport you<00:17:19.559> have<00:17:19.679> a<00:17:19.740> separate<00:17:19.919> nullifier<00:17:20.400> tree<00:17:20.640> uh 00:17:21.530 --> 00:17:21.540 align:start position:0% you have a separate nullifier tree uh 00:17:21.540 --> 00:17:22.730 align:start position:0% you have a separate nullifier tree uh and<00:17:21.900> then 00:17:22.730 --> 00:17:22.740 align:start position:0% and then 00:17:22.740 --> 00:17:23.990 align:start position:0% and then um you<00:17:22.980> know<00:17:23.040> nodes<00:17:23.339> are<00:17:23.520> expected<00:17:23.760> to<00:17:23.939> keep 00:17:23.990 --> 00:17:24.000 align:start position:0% um you know nodes are expected to keep 00:17:24.000 --> 00:17:25.909 align:start position:0% um you know nodes are expected to keep the<00:17:24.179> last<00:17:24.299> two<00:17:24.480> epochs<00:17:25.020> but<00:17:25.140> can<00:17:25.319> discard<00:17:25.679> the 00:17:25.909 --> 00:17:25.919 align:start position:0% the last two epochs but can discard the 00:17:25.919 --> 00:17:28.970 align:start position:0% the last two epochs but can discard the nullifiers<00:17:26.459> for<00:17:26.640> the<00:17:26.819> prior<00:17:27.299> epochs<00:17:27.900> now<00:17:28.500> uh 00:17:28.970 --> 00:17:28.980 align:start position:0% nullifiers for the prior epochs now uh 00:17:28.980 --> 00:17:30.710 align:start position:0% nullifiers for the prior epochs now uh we<00:17:29.220> have<00:17:29.340> two<00:17:29.580> uh<00:17:30.000> we<00:17:30.179> have<00:17:30.299> this<00:17:30.480> different 00:17:30.710 --> 00:17:30.720 align:start position:0% we have two uh we have this different 00:17:30.720 --> 00:17:32.450 align:start position:0% we have two uh we have this different databases<00:17:31.320> and<00:17:31.740> there<00:17:32.040> are<00:17:32.220> very<00:17:32.340> different 00:17:32.450 --> 00:17:32.460 align:start position:0% databases and there are very different 00:17:32.460 --> 00:17:33.830 align:start position:0% databases and there are very different growth<00:17:32.940> drivers<00:17:33.240> for<00:17:33.419> each<00:17:33.540> of<00:17:33.660> these 00:17:33.830 --> 00:17:33.840 align:start position:0% growth drivers for each of these 00:17:33.840 --> 00:17:35.150 align:start position:0% growth drivers for each of these databases<00:17:34.260> so 00:17:35.150 --> 00:17:35.160 align:start position:0% databases so 00:17:35.160 --> 00:17:37.549 align:start position:0% databases so An<00:17:35.580> accounts<00:17:35.940> database<00:17:36.299> grows<00:17:37.140> primarily 00:17:37.549 --> 00:17:37.559 align:start position:0% An accounts database grows primarily 00:17:37.559 --> 00:17:39.169 align:start position:0% An accounts database grows primarily with<00:17:37.740> the<00:17:37.860> state<00:17:38.039> of<00:17:38.220> with<00:17:38.580> a<00:17:38.820> number<00:17:38.940> of 00:17:39.169 --> 00:17:39.179 align:start position:0% with the state of with a number of 00:17:39.179 --> 00:17:40.970 align:start position:0% with the state of with a number of Public<00:17:39.360> Accounts 00:17:40.970 --> 00:17:40.980 align:start position:0% Public Accounts 00:17:40.980 --> 00:17:42.890 align:start position:0% Public Accounts um<00:17:41.100> or<00:17:41.700> the<00:17:41.880> accounts<00:17:42.240> that<00:17:42.299> have<00:17:42.480> on<00:17:42.660> chain 00:17:42.890 --> 00:17:42.900 align:start position:0% um or the accounts that have on chain 00:17:42.900 --> 00:17:45.590 align:start position:0% um or the accounts that have on chain State<00:17:43.340> because<00:17:44.340> if<00:17:44.760> you<00:17:44.880> you<00:17:45.120> know<00:17:45.299> it<00:17:45.419> does 00:17:45.590 --> 00:17:45.600 align:start position:0% State because if you you know it does 00:17:45.600 --> 00:17:46.909 align:start position:0% State because if you you know it does grow<00:17:45.720> within<00:17:46.080> a<00:17:46.200> total<00:17:46.380> number<00:17:46.440> of<00:17:46.559> accounts 00:17:46.909 --> 00:17:46.919 align:start position:0% grow within a total number of accounts 00:17:46.919 --> 00:17:48.409 align:start position:0% grow within a total number of accounts but<00:17:47.100> if<00:17:47.220> you<00:17:47.340> only<00:17:47.400> have<00:17:47.640> to<00:17:47.820> store<00:17:48.000> a<00:17:48.179> single 00:17:48.409 --> 00:17:48.419 align:start position:0% but if you only have to store a single 00:17:48.419 --> 00:17:49.970 align:start position:0% but if you only have to store a single hash<00:17:48.600> for<00:17:48.780> an<00:17:48.900> account<00:17:49.080> that<00:17:49.440> you<00:17:49.679> know<00:17:49.740> that's 00:17:49.970 --> 00:17:49.980 align:start position:0% hash for an account that you know that's 00:17:49.980 --> 00:17:51.350 align:start position:0% hash for an account that you know that's almost<00:17:50.160> negligible<00:17:50.640> like<00:17:50.820> you<00:17:51.000> can<00:17:51.120> store<00:17:51.179> a 00:17:51.350 --> 00:17:51.360 align:start position:0% almost negligible like you can store a 00:17:51.360 --> 00:17:52.370 align:start position:0% almost negligible like you can store a billion<00:17:51.600> accounts<00:17:51.900> and<00:17:51.960> it's<00:17:52.080> going<00:17:52.260> to<00:17:52.320> be 00:17:52.370 --> 00:17:52.380 align:start position:0% billion accounts and it's going to be 00:17:52.380 --> 00:17:54.169 align:start position:0% billion accounts and it's going to be only<00:17:52.500> 64<00:17:52.860> gigabytes 00:17:54.169 --> 00:17:54.179 align:start position:0% only 64 gigabytes 00:17:54.179 --> 00:17:56.570 align:start position:0% only 64 gigabytes uh<00:17:54.960> and<00:17:55.260> also<00:17:55.500> we<00:17:55.620> can<00:17:55.799> dynamically<00:17:56.220> kind<00:17:56.460> of 00:17:56.570 --> 00:17:56.580 align:start position:0% uh and also we can dynamically kind of 00:17:56.580 --> 00:17:58.789 align:start position:0% uh and also we can dynamically kind of prune<00:17:56.940> this<00:17:57.059> we<00:17:57.299> can<00:17:57.480> you<00:17:57.900> know<00:17:58.020> for<00:17:58.320> accounts 00:17:58.789 --> 00:17:58.799 align:start position:0% prune this we can you know for accounts 00:17:58.799 --> 00:18:00.169 align:start position:0% prune this we can you know for accounts for<00:17:58.919> example<00:17:59.100> that<00:17:59.280> haven't<00:17:59.460> been<00:17:59.700> used<00:17:59.820> in<00:18:00.059> a 00:18:00.169 --> 00:18:00.179 align:start position:0% for example that haven't been used in a 00:18:00.179 --> 00:18:02.630 align:start position:0% for example that haven't been used in a while<00:18:00.240> we<00:18:00.480> can<00:18:00.660> just<00:18:01.039> remove<00:18:02.039> all<00:18:02.280> the<00:18:02.460> data 00:18:02.630 --> 00:18:02.640 align:start position:0% while we can just remove all the data 00:18:02.640 --> 00:18:04.070 align:start position:0% while we can just remove all the data and<00:18:02.760> store<00:18:02.940> the<00:18:03.059> hash<00:18:03.179> for<00:18:03.419> that<00:18:03.600> account<00:18:03.780> or 00:18:04.070 --> 00:18:04.080 align:start position:0% and store the hash for that account or 00:18:04.080 --> 00:18:05.390 align:start position:0% and store the hash for that account or nodes<00:18:04.380> can<00:18:04.559> choose<00:18:04.740> to<00:18:04.799> do<00:18:04.919> that<00:18:04.980> if<00:18:05.100> they<00:18:05.280> wish 00:18:05.390 --> 00:18:05.400 align:start position:0% nodes can choose to do that if they wish 00:18:05.400 --> 00:18:06.350 align:start position:0% nodes can choose to do that if they wish to 00:18:06.350 --> 00:18:06.360 align:start position:0% to 00:18:06.360 --> 00:18:09.169 align:start position:0% to uh<00:18:06.900> the<00:18:07.080> notes<00:18:07.320> database<00:18:07.820> grows<00:18:08.820> with<00:18:08.940> the 00:18:09.169 --> 00:18:09.179 align:start position:0% uh the notes database grows with the 00:18:09.179 --> 00:18:10.669 align:start position:0% uh the notes database grows with the number<00:18:09.240> of<00:18:09.360> unconsumed<00:18:09.900> nodes<00:18:10.080> so<00:18:10.200> as<00:18:10.440> soon<00:18:10.559> as 00:18:10.669 --> 00:18:10.679 align:start position:0% number of unconsumed nodes so as soon as 00:18:10.679 --> 00:18:12.049 align:start position:0% number of unconsumed nodes so as soon as the<00:18:10.740> node<00:18:10.980> is<00:18:11.100> consumed<00:18:11.400> it<00:18:11.520> can<00:18:11.700> be<00:18:11.760> safely 00:18:12.049 --> 00:18:12.059 align:start position:0% the node is consumed it can be safely 00:18:12.059 --> 00:18:13.549 align:start position:0% the node is consumed it can be safely discarded<00:18:12.539> you<00:18:12.900> don't<00:18:13.020> need<00:18:13.140> to<00:18:13.260> store<00:18:13.380> it 00:18:13.549 --> 00:18:13.559 align:start position:0% discarded you don't need to store it 00:18:13.559 --> 00:18:15.950 align:start position:0% discarded you don't need to store it anymore<00:18:13.880> so<00:18:14.880> unconsumed<00:18:15.419> nodes<00:18:15.660> is<00:18:15.780> what 00:18:15.950 --> 00:18:15.960 align:start position:0% anymore so unconsumed nodes is what 00:18:15.960 --> 00:18:18.169 align:start position:0% anymore so unconsumed nodes is what drives<00:18:16.260> the<00:18:17.160> um<00:18:17.160> the<00:18:17.460> size<00:18:17.580> of<00:18:17.760> the<00:18:17.820> database 00:18:18.169 --> 00:18:18.179 align:start position:0% drives the um the size of the database 00:18:18.179 --> 00:18:19.610 align:start position:0% drives the um the size of the database but<00:18:18.360> also<00:18:18.539> you<00:18:18.720> can<00:18:18.840> have<00:18:18.960> this<00:18:19.140> pruning<00:18:19.500> where 00:18:19.610 --> 00:18:19.620 align:start position:0% but also you can have this pruning where 00:18:19.620 --> 00:18:20.870 align:start position:0% but also you can have this pruning where you<00:18:19.740> can<00:18:19.860> you<00:18:20.039> can<00:18:20.160> remove<00:18:20.280> some<00:18:20.460> of<00:18:20.580> the<00:18:20.700> notes 00:18:20.870 --> 00:18:20.880 align:start position:0% you can you can remove some of the notes 00:18:20.880 --> 00:18:22.190 align:start position:0% you can you can remove some of the notes and<00:18:21.000> just<00:18:21.120> keep<00:18:21.240> the<00:18:21.360> hash 00:18:22.190 --> 00:18:22.200 align:start position:0% and just keep the hash 00:18:22.200 --> 00:18:23.870 align:start position:0% and just keep the hash then<00:18:22.799> finally<00:18:23.100> we<00:18:23.280> have<00:18:23.400> the<00:18:23.460> nullifier 00:18:23.870 --> 00:18:23.880 align:start position:0% then finally we have the nullifier 00:18:23.880 --> 00:18:25.310 align:start position:0% then finally we have the nullifier database<00:18:24.240> and<00:18:24.360> this<00:18:24.539> one<00:18:24.660> is<00:18:24.720> a<00:18:24.900> different<00:18:25.020> one 00:18:25.310 --> 00:18:25.320 align:start position:0% database and this one is a different one 00:18:25.320 --> 00:18:26.450 align:start position:0% database and this one is a different one because<00:18:25.500> you<00:18:25.740> can't<00:18:25.860> easily<00:18:26.160> prune 00:18:26.450 --> 00:18:26.460 align:start position:0% because you can't easily prune 00:18:26.460 --> 00:18:28.190 align:start position:0% because you can't easily prune nullifiers<00:18:26.940> to<00:18:27.059> be<00:18:27.120> able<00:18:27.299> to<00:18:27.419> create<00:18:27.960> new 00:18:28.190 --> 00:18:28.200 align:start position:0% nullifiers to be able to create new 00:18:28.200 --> 00:18:29.570 align:start position:0% nullifiers to be able to create new blocks<00:18:28.500> you<00:18:28.679> actually<00:18:28.799> need<00:18:29.039> to<00:18:29.160> keep<00:18:29.280> all<00:18:29.460> the 00:18:29.570 --> 00:18:29.580 align:start position:0% blocks you actually need to keep all the 00:18:29.580 --> 00:18:31.669 align:start position:0% blocks you actually need to keep all the notifiers<00:18:30.120> and<00:18:30.780> the<00:18:30.900> nullifier<00:18:31.320> database 00:18:31.669 --> 00:18:31.679 align:start position:0% notifiers and the nullifier database 00:18:31.679 --> 00:18:33.289 align:start position:0% notifiers and the nullifier database depends<00:18:31.980> on<00:18:32.100> the<00:18:32.220> throughput<00:18:32.520> so<00:18:32.760> like<00:18:33.000> the 00:18:33.289 --> 00:18:33.299 align:start position:0% depends on the throughput so like the 00:18:33.299 --> 00:18:35.270 align:start position:0% depends on the throughput so like the more<00:18:33.539> transactions<00:18:34.080> per<00:18:34.200> second<00:18:34.380> you<00:18:35.220> have 00:18:35.270 --> 00:18:35.280 align:start position:0% more transactions per second you have 00:18:35.280 --> 00:18:36.770 align:start position:0% more transactions per second you have the<00:18:35.520> more<00:18:35.640> nullifiers<00:18:36.179> you<00:18:36.299> need<00:18:36.360> to<00:18:36.480> keep<00:18:36.600> in 00:18:36.770 --> 00:18:36.780 align:start position:0% the more nullifiers you need to keep in 00:18:36.780 --> 00:18:38.990 align:start position:0% the more nullifiers you need to keep in for<00:18:37.140> a<00:18:37.260> given<00:18:37.440> Epoch<00:18:37.919> we<00:18:38.220> can<00:18:38.340> make<00:18:38.520> Epoch 00:18:38.990 --> 00:18:39.000 align:start position:0% for a given Epoch we can make Epoch 00:18:39.000 --> 00:18:40.310 align:start position:0% for a given Epoch we can make Epoch smaller<00:18:39.360> but<00:18:39.660> you<00:18:39.900> know<00:18:39.960> there<00:18:40.140> are<00:18:40.260> some 00:18:40.310 --> 00:18:40.320 align:start position:0% smaller but you know there are some 00:18:40.320 --> 00:18:43.970 align:start position:0% smaller but you know there are some downsides<00:18:40.799> to<00:18:40.860> that<00:18:40.980> so<00:18:41.220> overall 00:18:43.970 --> 00:18:43.980 align:start position:0% downsides to that so overall 00:18:43.980 --> 00:18:46.549 align:start position:0% downsides to that so overall you<00:18:44.520> know<00:18:44.580> if<00:18:44.700> we<00:18:44.820> look<00:18:45.000> at<00:18:45.179> kind<00:18:45.600> of<00:18:45.660> like<00:18:45.900> what 00:18:46.549 --> 00:18:46.559 align:start position:0% you know if we look at kind of like what 00:18:46.559 --> 00:18:48.049 align:start position:0% you know if we look at kind of like what sizes<00:18:46.980> of<00:18:47.160> these<00:18:47.280> databases<00:18:47.640> could<00:18:47.820> be<00:18:47.940> that 00:18:48.049 --> 00:18:48.059 align:start position:0% sizes of these databases could be that 00:18:48.059 --> 00:18:49.549 align:start position:0% sizes of these databases could be that nullifier<00:18:48.480> database<00:18:48.840> is<00:18:48.960> going<00:18:49.140> to<00:18:49.200> be<00:18:49.260> by<00:18:49.380> far 00:18:49.549 --> 00:18:49.559 align:start position:0% nullifier database is going to be by far 00:18:49.559 --> 00:18:50.750 align:start position:0% nullifier database is going to be by far the<00:18:49.740> ones<00:18:49.919> that<00:18:50.039> drive<00:18:50.220> the<00:18:50.400> size<00:18:50.520> of<00:18:50.700> the 00:18:50.750 --> 00:18:50.760 align:start position:0% the ones that drive the size of the 00:18:50.760 --> 00:18:51.830 align:start position:0% the ones that drive the size of the overall<00:18:51.000> State<00:18:51.120> it's<00:18:51.299> going<00:18:51.480> to<00:18:51.480> be<00:18:51.600> larger 00:18:51.830 --> 00:18:51.840 align:start position:0% overall State it's going to be larger 00:18:51.840 --> 00:18:53.930 align:start position:0% overall State it's going to be larger than<00:18:52.020> the<00:18:52.320> nodes<00:18:53.039> or<00:18:53.220> accounts<00:18:53.580> databases 00:18:53.930 --> 00:18:53.940 align:start position:0% than the nodes or accounts databases 00:18:53.940 --> 00:18:56.750 align:start position:0% than the nodes or accounts databases combined<00:18:54.419> now<00:18:55.080> I<00:18:55.980> have<00:18:56.039> a<00:18:56.160> few<00:18:56.280> slides<00:18:56.520> to<00:18:56.640> wrap 00:18:56.750 --> 00:18:56.760 align:start position:0% combined now I have a few slides to wrap 00:18:56.760 --> 00:18:58.310 align:start position:0% combined now I have a few slides to wrap up<00:18:56.820> the<00:18:57.000> talk<00:18:57.120> to<00:18:57.240> say<00:18:57.480> well<00:18:57.600> well<00:18:57.780> what<00:18:58.080> did<00:18:58.200> we 00:18:58.310 --> 00:18:58.320 align:start position:0% up the talk to say well well what did we 00:18:58.320 --> 00:19:00.950 align:start position:0% up the talk to say well well what did we achieve<00:18:58.620> first<00:18:59.160> we<00:18:59.820> have<00:19:00.000> this<00:19:00.179> concept<00:19:00.539> of 00:19:00.950 --> 00:19:00.960 align:start position:0% achieve first we have this concept of 00:19:00.960 --> 00:19:02.870 align:start position:0% achieve first we have this concept of different<00:19:01.559> models<00:19:02.100> of<00:19:02.160> execution<00:19:02.520> so<00:19:02.760> the 00:19:02.870 --> 00:19:02.880 align:start position:0% different models of execution so the 00:19:02.880 --> 00:19:04.610 align:start position:0% different models of execution so the network<00:19:03.059> execution<00:19:03.780> and<00:19:03.960> local<00:19:04.140> execution 00:19:04.610 --> 00:19:04.620 align:start position:0% network execution and local execution 00:19:04.620 --> 00:19:06.830 align:start position:0% network execution and local execution and<00:19:05.160> we<00:19:05.280> have<00:19:05.400> this<00:19:05.580> concept<00:19:05.880> of<00:19:06.120> on-chain 00:19:06.830 --> 00:19:06.840 align:start position:0% and we have this concept of on-chain 00:19:06.840 --> 00:19:08.990 align:start position:0% and we have this concept of on-chain data<00:19:07.140> and<00:19:07.260> off-chain<00:19:07.679> data<00:19:08.100> and<00:19:08.820> the 00:19:08.990 --> 00:19:09.000 align:start position:0% data and off-chain data and the 00:19:09.000 --> 00:19:10.669 align:start position:0% data and off-chain data and the combination<00:19:09.360> of<00:19:09.539> this<00:19:09.720> gives<00:19:10.020> us<00:19:10.200> you<00:19:10.559> know 00:19:10.669 --> 00:19:10.679 align:start position:0% combination of this gives us you know 00:19:10.679 --> 00:19:12.110 align:start position:0% combination of this gives us you know different<00:19:10.860> nice<00:19:11.100> properties<00:19:11.520> so<00:19:11.760> for<00:19:11.880> example 00:19:12.110 --> 00:19:12.120 align:start position:0% different nice properties so for example 00:19:12.120 --> 00:19:13.909 align:start position:0% different nice properties so for example if<00:19:12.539> we<00:19:12.600> have<00:19:12.720> on-chain<00:19:13.320> data<00:19:13.620> and<00:19:13.740> network 00:19:13.909 --> 00:19:13.919 align:start position:0% if we have on-chain data and network 00:19:13.919 --> 00:19:15.770 align:start position:0% if we have on-chain data and network execution<00:19:14.400> this<00:19:14.820> is<00:19:14.940> a<00:19:15.059> typical<00:19:15.240> you<00:19:15.600> know 00:19:15.770 --> 00:19:15.780 align:start position:0% execution this is a typical you know 00:19:15.780 --> 00:19:16.970 align:start position:0% execution this is a typical you know public<00:19:15.960> transactions<00:19:16.500> something<00:19:16.740> that 00:19:16.970 --> 00:19:16.980 align:start position:0% public transactions something that 00:19:16.980 --> 00:19:19.130 align:start position:0% public transactions something that happens<00:19:17.100> on<00:19:17.340> ethereum<00:19:17.760> right<00:19:17.880> now<00:19:18.539> we<00:19:18.960> can 00:19:19.130 --> 00:19:19.140 align:start position:0% happens on ethereum right now we can 00:19:19.140 --> 00:19:20.690 align:start position:0% happens on ethereum right now we can also<00:19:19.320> have<00:19:19.440> stateless<00:19:19.799> transactions<00:19:20.340> if<00:19:20.520> we 00:19:20.690 --> 00:19:20.700 align:start position:0% also have stateless transactions if we 00:19:20.700 --> 00:19:21.890 align:start position:0% also have stateless transactions if we have<00:19:20.820> off-chain<00:19:21.299> data<00:19:21.600> but<00:19:21.720> Network 00:19:21.890 --> 00:19:21.900 align:start position:0% have off-chain data but Network 00:19:21.900 --> 00:19:24.409 align:start position:0% have off-chain data but Network execution<00:19:22.380> where<00:19:23.880> um<00:19:23.880> you<00:19:24.120> know<00:19:24.179> the<00:19:24.299> network 00:19:24.409 --> 00:19:24.419 align:start position:0% execution where um you know the network 00:19:24.419 --> 00:19:25.909 align:start position:0% execution where um you know the network doesn't<00:19:24.720> store<00:19:25.020> the<00:19:25.200> state<00:19:25.380> of<00:19:25.500> the<00:19:25.559> accounts 00:19:25.909 --> 00:19:25.919 align:start position:0% doesn't store the state of the accounts 00:19:25.919 --> 00:19:27.110 align:start position:0% doesn't store the state of the accounts for<00:19:26.039> example<00:19:26.220> but<00:19:26.460> the<00:19:26.580> user<00:19:26.820> needs<00:19:27.059> to 00:19:27.110 --> 00:19:27.120 align:start position:0% for example but the user needs to 00:19:27.120 --> 00:19:28.549 align:start position:0% for example but the user needs to provide<00:19:27.419> the<00:19:27.600> state<00:19:27.720> of<00:19:27.900> the<00:19:28.020> account<00:19:28.140> with 00:19:28.549 --> 00:19:28.559 align:start position:0% provide the state of the account with 00:19:28.559 --> 00:19:29.930 align:start position:0% provide the state of the account with every<00:19:28.679> transaction<00:19:29.039> so<00:19:29.280> the<00:19:29.460> network<00:19:29.640> can 00:19:29.930 --> 00:19:29.940 align:start position:0% every transaction so the network can 00:19:29.940 --> 00:19:31.430 align:start position:0% every transaction so the network can execute<00:19:30.240> the<00:19:30.360> transaction 00:19:31.430 --> 00:19:31.440 align:start position:0% execute the transaction 00:19:31.440 --> 00:19:33.350 align:start position:0% execute the transaction and<00:19:31.860> the<00:19:31.980> next<00:19:32.100> thing<00:19:32.220> we<00:19:32.400> can<00:19:32.520> do<00:19:32.640> if<00:19:32.820> the<00:19:33.179> data 00:19:33.350 --> 00:19:33.360 align:start position:0% and the next thing we can do if the data 00:19:33.360 --> 00:19:34.909 align:start position:0% and the next thing we can do if the data is<00:19:33.480> off<00:19:33.660> chain<00:19:33.840> and<00:19:34.080> local<00:19:34.260> execution<00:19:34.740> is 00:19:34.909 --> 00:19:34.919 align:start position:0% is off chain and local execution is 00:19:34.919 --> 00:19:35.990 align:start position:0% is off chain and local execution is happening<00:19:35.160> we<00:19:35.400> can<00:19:35.520> have<00:19:35.640> private 00:19:35.990 --> 00:19:36.000 align:start position:0% happening we can have private 00:19:36.000 --> 00:19:37.850 align:start position:0% happening we can have private transactions<00:19:36.539> where<00:19:36.900> the<00:19:37.260> network<00:19:37.380> is<00:19:37.679> not 00:19:37.850 --> 00:19:37.860 align:start position:0% transactions where the network is not 00:19:37.860 --> 00:19:39.470 align:start position:0% transactions where the network is not aware<00:19:38.100> not<00:19:38.280> only<00:19:38.460> of<00:19:38.640> what<00:19:38.760> code<00:19:38.940> was<00:19:39.120> executed 00:19:39.470 --> 00:19:39.480 align:start position:0% aware not only of what code was executed 00:19:39.480 --> 00:19:40.970 align:start position:0% aware not only of what code was executed necessarily<00:19:40.080> but<00:19:40.140> also<00:19:40.380> is<00:19:40.500> not<00:19:40.620> aware<00:19:40.740> of<00:19:40.860> the 00:19:40.970 --> 00:19:40.980 align:start position:0% necessarily but also is not aware of the 00:19:40.980 --> 00:19:42.289 align:start position:0% necessarily but also is not aware of the data<00:19:41.160> that<00:19:41.280> is<00:19:41.400> in<00:19:41.580> the<00:19:41.700> account<00:19:41.820> and<00:19:42.059> we<00:19:42.179> can 00:19:42.289 --> 00:19:42.299 align:start position:0% data that is in the account and we can 00:19:42.299 --> 00:19:44.029 align:start position:0% data that is in the account and we can also<00:19:42.539> hide<00:19:42.960> the<00:19:43.140> transaction<00:19:43.440> graph<00:19:43.740> using 00:19:44.029 --> 00:19:44.039 align:start position:0% also hide the transaction graph using 00:19:44.039 --> 00:19:45.230 align:start position:0% also hide the transaction graph using utxos 00:19:45.230 --> 00:19:45.240 align:start position:0% utxos 00:19:45.240 --> 00:19:46.789 align:start position:0% utxos um<00:19:45.299> it's<00:19:45.660> I'm<00:19:45.900> not<00:19:46.080> going<00:19:46.200> to<00:19:46.260> get<00:19:46.380> into<00:19:46.620> that 00:19:46.789 --> 00:19:46.799 align:start position:0% um it's I'm not going to get into that 00:19:46.799 --> 00:19:48.230 align:start position:0% um it's I'm not going to get into that right<00:19:46.980> now<00:19:47.100> but<00:19:47.280> it's<00:19:47.460> a<00:19:47.700> bit<00:19:47.820> slightly<00:19:48.120> more 00:19:48.230 --> 00:19:48.240 align:start position:0% right now but it's a bit slightly more 00:19:48.240 --> 00:19:50.090 align:start position:0% right now but it's a bit slightly more complicated<00:19:48.600> but<00:19:48.780> we<00:19:48.900> can<00:19:49.020> do<00:19:49.140> that<00:19:49.260> as<00:19:49.380> well 00:19:50.090 --> 00:19:50.100 align:start position:0% complicated but we can do that as well 00:19:50.100 --> 00:19:51.890 align:start position:0% complicated but we can do that as well and<00:19:50.580> then<00:19:50.760> finally<00:19:51.000> for<00:19:51.240> completeness<00:19:51.660> there 00:19:51.890 --> 00:19:51.900 align:start position:0% and then finally for completeness there 00:19:51.900 --> 00:19:53.450 align:start position:0% and then finally for completeness there is<00:19:52.020> this<00:19:52.260> uh<00:19:52.440> you<00:19:52.620> know<00:19:52.679> local<00:19:52.860> execution<00:19:53.280> and 00:19:53.450 --> 00:19:53.460 align:start position:0% is this uh you know local execution and 00:19:53.460 --> 00:19:55.250 align:start position:0% is this uh you know local execution and on<00:19:53.640> chain<00:19:53.880> data<00:19:54.299> I<00:19:54.720> personally<00:19:54.960> don't<00:19:55.140> know 00:19:55.250 --> 00:19:55.260 align:start position:0% on chain data I personally don't know 00:19:55.260 --> 00:19:56.570 align:start position:0% on chain data I personally don't know which<00:19:55.500> use<00:19:55.679> cases<00:19:55.860> that<00:19:56.100> would<00:19:56.220> cover<00:19:56.340> but 00:19:56.570 --> 00:19:56.580 align:start position:0% which use cases that would cover but 00:19:56.580 --> 00:19:57.830 align:start position:0% which use cases that would cover but maybe<00:19:56.760> people<00:19:57.000> will<00:19:57.240> come<00:19:57.419> up<00:19:57.480> with<00:19:57.600> something 00:19:57.830 --> 00:19:57.840 align:start position:0% maybe people will come up with something 00:19:57.840 --> 00:20:00.049 align:start position:0% maybe people will come up with something how<00:19:58.679> did<00:19:58.799> we<00:19:58.919> address<00:19:59.039> execution<00:19:59.520> load<00:19:59.880> with 00:20:00.049 --> 00:20:00.059 align:start position:0% how did we address execution load with 00:20:00.059 --> 00:20:02.029 align:start position:0% how did we address execution load with those<00:20:00.179> models<00:20:00.660> so<00:20:01.140> first<00:20:01.320> we<00:20:01.620> achieved<00:20:01.919> no 00:20:02.029 --> 00:20:02.039 align:start position:0% those models so first we achieved no 00:20:02.039 --> 00:20:03.650 align:start position:0% those models so first we achieved no re-execution<00:20:02.640> so<00:20:02.880> all<00:20:03.059> transactions<00:20:03.539> are 00:20:03.650 --> 00:20:03.660 align:start position:0% re-execution so all transactions are 00:20:03.660 --> 00:20:06.350 align:start position:0% re-execution so all transactions are executed<00:20:04.020> only<00:20:04.260> once<00:20:05.100> uh<00:20:05.820> second<00:20:06.000> we<00:20:06.240> have 00:20:06.350 --> 00:20:06.360 align:start position:0% executed only once uh second we have 00:20:06.360 --> 00:20:08.270 align:start position:0% executed only once uh second we have concurrent<00:20:06.780> processing<00:20:07.200> where<00:20:07.500> transactions 00:20:08.270 --> 00:20:08.280 align:start position:0% concurrent processing where transactions 00:20:08.280 --> 00:20:10.490 align:start position:0% concurrent processing where transactions can<00:20:08.460> be<00:20:08.580> processed<00:20:09.000> in<00:20:09.120> parallel<00:20:09.539> uh<00:20:10.320> on 00:20:10.490 --> 00:20:10.500 align:start position:0% can be processed in parallel uh on 00:20:10.500 --> 00:20:11.990 align:start position:0% can be processed in parallel uh on Independent<00:20:10.980> machines<00:20:11.280> and<00:20:11.460> you<00:20:11.580> can<00:20:11.700> almost 00:20:11.990 --> 00:20:12.000 align:start position:0% Independent machines and you can almost 00:20:12.000 --> 00:20:14.090 align:start position:0% Independent machines and you can almost scale<00:20:12.419> this<00:20:12.660> thing<00:20:12.960> horizontally<00:20:13.500> by<00:20:13.740> adding 00:20:14.090 --> 00:20:14.100 align:start position:0% scale this thing horizontally by adding 00:20:14.100 --> 00:20:15.650 align:start position:0% scale this thing horizontally by adding more<00:20:14.340> and<00:20:14.460> more<00:20:14.640> machines<00:20:14.880> to<00:20:15.059> generate 00:20:15.650 --> 00:20:15.660 align:start position:0% more and more machines to generate 00:20:15.660 --> 00:20:17.870 align:start position:0% more and more machines to generate proofs<00:20:16.440> and<00:20:17.039> finally<00:20:17.220> we<00:20:17.400> have<00:20:17.520> this<00:20:17.700> local 00:20:17.870 --> 00:20:17.880 align:start position:0% proofs and finally we have this local 00:20:17.880 --> 00:20:21.049 align:start position:0% proofs and finally we have this local execution<00:20:18.360> where<00:20:18.860> transactions<00:20:19.940> can<00:20:20.940> be 00:20:21.049 --> 00:20:21.059 align:start position:0% execution where transactions can be 00:20:21.059 --> 00:20:23.150 align:start position:0% execution where transactions can be executed<00:20:21.419> by<00:20:21.780> the<00:20:22.320> users<00:20:22.620> that<00:20:22.799> are<00:20:22.919> involved 00:20:23.150 --> 00:20:23.160 align:start position:0% executed by the users that are involved 00:20:23.160 --> 00:20:24.770 align:start position:0% executed by the users that are involved in<00:20:23.280> those<00:20:23.400> transactions<00:20:24.000> and<00:20:24.419> the<00:20:24.600> nice 00:20:24.770 --> 00:20:24.780 align:start position:0% in those transactions and the nice 00:20:24.780 --> 00:20:26.390 align:start position:0% in those transactions and the nice property<00:20:25.140> here<00:20:25.320> is<00:20:25.500> the<00:20:25.620> more<00:20:25.740> locally<00:20:26.039> proven 00:20:26.390 --> 00:20:26.400 align:start position:0% property here is the more locally proven 00:20:26.400 --> 00:20:28.010 align:start position:0% property here is the more locally proven transactions<00:20:26.820> you<00:20:27.000> have<00:20:27.120> the<00:20:27.360> less<00:20:27.600> burden 00:20:28.010 --> 00:20:28.020 align:start position:0% transactions you have the less burden 00:20:28.020 --> 00:20:29.750 align:start position:0% transactions you have the less burden computation<00:20:28.620> loaded<00:20:28.980> in<00:20:29.100> the<00:20:29.220> network<00:20:29.340> has<00:20:29.640> to 00:20:29.750 --> 00:20:29.760 align:start position:0% computation loaded in the network has to 00:20:29.760 --> 00:20:31.850 align:start position:0% computation loaded in the network has to encounter<00:20:30.179> because<00:20:30.780> let's<00:20:31.080> say<00:20:31.200> 90<00:20:31.440> of 00:20:31.850 --> 00:20:31.860 align:start position:0% encounter because let's say 90 of 00:20:31.860 --> 00:20:32.930 align:start position:0% encounter because let's say 90 of transactions<00:20:32.280> are<00:20:32.460> something<00:20:32.640> that<00:20:32.820> has 00:20:32.930 --> 00:20:32.940 align:start position:0% transactions are something that has 00:20:32.940 --> 00:20:34.730 align:start position:0% transactions are something that has proven<00:20:33.240> locally<00:20:33.539> there<00:20:33.960> is<00:20:34.200> very<00:20:34.320> little<00:20:34.500> work 00:20:34.730 --> 00:20:34.740 align:start position:0% proven locally there is very little work 00:20:34.740 --> 00:20:36.409 align:start position:0% proven locally there is very little work that<00:20:34.980> the<00:20:35.220> block<00:20:35.400> producer<00:20:35.880> needs<00:20:36.120> to<00:20:36.179> do<00:20:36.299> to 00:20:36.409 --> 00:20:36.419 align:start position:0% that the block producer needs to do to 00:20:36.419 --> 00:20:38.090 align:start position:0% that the block producer needs to do to uh<00:20:36.780> to<00:20:37.140> they<00:20:37.380> don't<00:20:37.500> need<00:20:37.620> to<00:20:37.679> execute<00:20:37.980> them 00:20:38.090 --> 00:20:38.100 align:start position:0% uh to they don't need to execute them 00:20:38.100 --> 00:20:39.110 align:start position:0% uh to they don't need to execute them they<00:20:38.280> don't<00:20:38.400> need<00:20:38.520> to<00:20:38.580> prove<00:20:38.760> them<00:20:38.880> they<00:20:39.000> just 00:20:39.110 --> 00:20:39.120 align:start position:0% they don't need to prove them they just 00:20:39.120 --> 00:20:40.850 align:start position:0% they don't need to prove them they just aggregate<00:20:39.539> them<00:20:39.660> into<00:20:39.780> blocks 00:20:40.850 --> 00:20:40.860 align:start position:0% aggregate them into blocks 00:20:40.860 --> 00:20:43.370 align:start position:0% aggregate them into blocks and<00:20:41.520> then<00:20:41.700> regarding<00:20:42.299> State<00:20:42.480> load<00:20:42.900> we<00:20:43.200> have 00:20:43.370 --> 00:20:43.380 align:start position:0% and then regarding State load we have 00:20:43.380 --> 00:20:45.590 align:start position:0% and then regarding State load we have kind<00:20:43.919> of<00:20:44.039> this<00:20:44.160> Dynamic<00:20:44.520> pruning<00:20:45.299> where<00:20:45.419> we 00:20:45.590 --> 00:20:45.600 align:start position:0% kind of this Dynamic pruning where we 00:20:45.600 --> 00:20:47.330 align:start position:0% kind of this Dynamic pruning where we can<00:20:45.780> collapse<00:20:46.260> accounts<00:20:46.799> and<00:20:46.860> nodes<00:20:47.160> into 00:20:47.330 --> 00:20:47.340 align:start position:0% can collapse accounts and nodes into 00:20:47.340 --> 00:20:48.950 align:start position:0% can collapse accounts and nodes into their<00:20:47.520> hashes 00:20:48.950 --> 00:20:48.960 align:start position:0% their hashes 00:20:48.960 --> 00:20:50.330 align:start position:0% their hashes um<00:20:49.020> we<00:20:49.200> can<00:20:49.320> have<00:20:49.440> very<00:20:49.620> light<00:20:49.860> verifying 00:20:50.330 --> 00:20:50.340 align:start position:0% um we can have very light verifying 00:20:50.340 --> 00:20:51.890 align:start position:0% um we can have very light verifying notes<00:20:50.580> if<00:20:50.820> you<00:20:50.940> only<00:20:51.059> want<00:20:51.240> to<00:20:51.360> verify<00:20:51.720> State 00:20:51.890 --> 00:20:51.900 align:start position:0% notes if you only want to verify State 00:20:51.900 --> 00:20:53.390 align:start position:0% notes if you only want to verify State Transitions<00:20:52.440> and<00:20:52.559> you<00:20:52.679> don't<00:20:52.860> want<00:20:53.100> to<00:20:53.280> create 00:20:53.390 --> 00:20:53.400 align:start position:0% Transitions and you don't want to create 00:20:53.400 --> 00:20:54.890 align:start position:0% Transitions and you don't want to create new<00:20:53.640> blocks<00:20:53.940> you<00:20:54.360> actually<00:20:54.480> don't<00:20:54.720> need<00:20:54.840> to 00:20:54.890 --> 00:20:54.900 align:start position:0% new blocks you actually don't need to 00:20:54.900 --> 00:20:56.450 align:start position:0% new blocks you actually don't need to maintain<00:20:55.200> the<00:20:55.320> nullifier<00:20:55.740> database<00:20:56.100> at<00:20:56.340> all 00:20:56.450 --> 00:20:56.460 align:start position:0% maintain the nullifier database at all 00:20:56.460 --> 00:20:58.610 align:start position:0% maintain the nullifier database at all and<00:20:56.880> in<00:20:57.000> that<00:20:57.179> case<00:20:57.419> as<00:20:58.020> I<00:20:58.200> mentioned<00:20:58.380> the 00:20:58.610 --> 00:20:58.620 align:start position:0% and in that case as I mentioned the 00:20:58.620 --> 00:21:00.230 align:start position:0% and in that case as I mentioned the nullify<00:20:59.100> database<00:20:59.460> is<00:20:59.640> the<00:20:59.760> biggest<00:20:59.880> part<00:21:00.120> of 00:21:00.230 --> 00:21:00.240 align:start position:0% nullify database is the biggest part of 00:21:00.240 --> 00:21:01.370 align:start position:0% nullify database is the biggest part of the<00:21:00.360> state<00:21:00.480> so<00:21:00.720> you<00:21:00.840> can<00:21:00.900> actually<00:21:01.020> discard 00:21:01.370 --> 00:21:01.380 align:start position:0% the state so you can actually discard 00:21:01.380 --> 00:21:03.529 align:start position:0% the state so you can actually discard the<00:21:01.500> biggest<00:21:01.620> part<00:21:01.860> of<00:21:01.980> the<00:21:02.100> state<00:21:02.280> and<00:21:03.240> we 00:21:03.529 --> 00:21:03.539 align:start position:0% the biggest part of the state and we 00:21:03.539 --> 00:21:05.330 align:start position:0% the biggest part of the state and we have<00:21:03.720> this<00:21:03.900> nice<00:21:04.080> thing<00:21:04.260> where<00:21:04.500> because<00:21:04.860> the 00:21:05.330 --> 00:21:05.340 align:start position:0% have this nice thing where because the 00:21:05.340 --> 00:21:06.890 align:start position:0% have this nice thing where because the nullifier<00:21:05.760> database<00:21:06.179> dominates<00:21:06.660> this 00:21:06.890 --> 00:21:06.900 align:start position:0% nullifier database dominates this 00:21:06.900 --> 00:21:09.409 align:start position:0% nullifier database dominates this overall<00:21:07.260> State<00:21:07.500> size<00:21:07.760> the<00:21:08.760> oral<00:21:09.059> State<00:21:09.240> size 00:21:09.409 --> 00:21:09.419 align:start position:0% overall State size the oral State size 00:21:09.419 --> 00:21:11.090 align:start position:0% overall State size the oral State size really<00:21:09.660> depends<00:21:09.960> on<00:21:10.080> GPS<00:21:10.200> so<00:21:10.620> the<00:21:10.740> higher<00:21:10.980> the 00:21:11.090 --> 00:21:11.100 align:start position:0% really depends on GPS so the higher the 00:21:11.100 --> 00:21:13.669 align:start position:0% really depends on GPS so the higher the GPS<00:21:11.220> the<00:21:11.820> higher<00:21:12.059> the<00:21:12.120> nullifier<00:21:12.600> the<00:21:13.380> bigger 00:21:13.669 --> 00:21:13.679 align:start position:0% GPS the higher the nullifier the bigger 00:21:13.679 --> 00:21:15.230 align:start position:0% GPS the higher the nullifier the bigger the<00:21:13.799> state<00:21:13.980> but<00:21:14.160> it<00:21:14.280> doesn't<00:21:14.400> vary<00:21:14.700> with<00:21:14.940> the 00:21:15.230 --> 00:21:15.240 align:start position:0% the state but it doesn't vary with the 00:21:15.240 --> 00:21:16.610 align:start position:0% the state but it doesn't vary with the number<00:21:15.360> of<00:21:15.539> accounts<00:21:15.900> for<00:21:16.020> example<00:21:16.260> as<00:21:16.500> much 00:21:16.610 --> 00:21:16.620 align:start position:0% number of accounts for example as much 00:21:16.620 --> 00:21:18.710 align:start position:0% number of accounts for example as much or<00:21:16.799> number<00:21:16.980> of<00:21:17.220> nodes<00:21:17.520> in<00:21:17.640> the<00:21:17.760> system 00:21:18.710 --> 00:21:18.720 align:start position:0% or number of nodes in the system 00:21:18.720 --> 00:21:20.750 align:start position:0% or number of nodes in the system and<00:21:19.500> last<00:21:19.980> thing<00:21:20.100> that<00:21:20.280> I<00:21:20.400> want<00:21:20.460> to<00:21:20.580> leave<00:21:20.640> you 00:21:20.750 --> 00:21:20.760 align:start position:0% and last thing that I want to leave you 00:21:20.760 --> 00:21:21.950 align:start position:0% and last thing that I want to leave you with<00:21:20.820> is<00:21:21.000> that<00:21:21.179> this<00:21:21.360> is<00:21:21.480> what<00:21:21.600> we're<00:21:21.720> trying 00:21:21.950 --> 00:21:21.960 align:start position:0% with is that this is what we're trying 00:21:21.960 --> 00:21:23.630 align:start position:0% with is that this is what we're trying to<00:21:22.080> achieve<00:21:22.380> where<00:21:22.620> the<00:21:23.039> more<00:21:23.100> privacy<00:21:23.460> there 00:21:23.630 --> 00:21:23.640 align:start position:0% to achieve where the more privacy there 00:21:23.640 --> 00:21:25.310 align:start position:0% to achieve where the more privacy there is<00:21:23.820> in<00:21:23.940> a<00:21:24.240> network<00:21:24.360> the<00:21:24.660> more<00:21:24.780> scalable<00:21:25.080> it<00:21:25.260> is 00:21:25.310 --> 00:21:25.320 align:start position:0% is in a network the more scalable it is 00:21:25.320 --> 00:21:26.750 align:start position:0% is in a network the more scalable it is the<00:21:25.500> more<00:21:25.620> scalable<00:21:25.919> it<00:21:26.039> is<00:21:26.160> the<00:21:26.340> more<00:21:26.520> private 00:21:26.750 --> 00:21:26.760 align:start position:0% the more scalable it is the more private 00:21:26.760 --> 00:21:28.730 align:start position:0% the more scalable it is the more private it<00:21:26.880> is<00:21:27.059> and<00:21:27.299> this<00:21:27.539> is<00:21:27.600> our<00:21:27.960> goal<00:21:28.320> with<00:21:28.500> the 00:21:28.730 --> 00:21:28.740 align:start position:0% it is and this is our goal with the 00:21:28.740 --> 00:21:32.149 align:start position:0% it is and this is our goal with the maiden<00:21:29.100> roll-up<00:21:29.460> thank<00:21:30.000> you 00:21:32.149 --> 00:21:32.159 align:start position:0% 00:21:32.159 --> 00:21:35.149 align:start position:0% so<00:21:32.820> how<00:21:33.539> would<00:21:33.659> the<00:21:33.780> network<00:21:33.960> result<00:21:34.559> when<00:21:34.919> two 00:21:35.149 --> 00:21:35.159 align:start position:0% so how would the network result when two 00:21:35.159 --> 00:21:37.490 align:start position:0% so how would the network result when two accounts<00:21:35.580> try<00:21:35.700> to<00:21:35.940> spend<00:21:36.299> the<00:21:36.419> same<00:21:36.539> utxo<00:21:37.200> like 00:21:37.490 --> 00:21:37.500 align:start position:0% accounts try to spend the same utxo like 00:21:37.500 --> 00:21:39.649 align:start position:0% accounts try to spend the same utxo like in<00:21:37.620> a<00:21:37.799> text<00:21:37.919> or<00:21:38.220> something<00:21:38.400> like<00:21:38.580> that 00:21:39.649 --> 00:21:39.659 align:start position:0% in a text or something like that 00:21:39.659 --> 00:21:40.730 align:start position:0% in a text or something like that so 00:21:40.730 --> 00:21:40.740 align:start position:0% so 00:21:40.740 --> 00:21:42.289 align:start position:0% so um<00:21:40.799> if<00:21:41.159> two<00:21:41.340> accounts<00:21:41.700> are<00:21:41.820> trying<00:21:42.000> to<00:21:42.120> spend 00:21:42.289 --> 00:21:42.299 align:start position:0% um if two accounts are trying to spend 00:21:42.299 --> 00:21:43.909 align:start position:0% um if two accounts are trying to spend the<00:21:42.419> same<00:21:42.539> utx<00:21:42.960> oh<00:21:43.080> that's<00:21:43.320> a<00:21:43.440> conflict<00:21:43.679> you 00:21:43.909 --> 00:21:43.919 align:start position:0% the same utx oh that's a conflict you 00:21:43.919 --> 00:21:46.549 align:start position:0% the same utx oh that's a conflict you can't<00:21:44.039> spend<00:21:44.340> the<00:21:44.460> same<00:21:44.580> ejx<00:21:45.000> or<00:21:45.179> twice<00:21:45.840> um<00:21:45.900> so 00:21:46.549 --> 00:21:46.559 align:start position:0% can't spend the same ejx or twice um so 00:21:46.559 --> 00:21:48.590 align:start position:0% can't spend the same ejx or twice um so I<00:21:47.340> think<00:21:47.460> the<00:21:47.700> problem 00:21:48.590 --> 00:21:48.600 align:start position:0% I think the problem 00:21:48.600 --> 00:21:50.510 align:start position:0% I think the problem um<00:21:48.659> so<00:21:49.440> it's<00:21:49.620> not<00:21:49.740> really<00:21:49.860> a<00:21:50.039> problem<00:21:50.159> in<00:21:50.400> that 00:21:50.510 --> 00:21:50.520 align:start position:0% um so it's not really a problem in that 00:21:50.520 --> 00:21:52.130 align:start position:0% um so it's not really a problem in that case<00:21:50.700> like<00:21:50.940> if<00:21:51.120> you<00:21:51.419> are<00:21:51.600> trying<00:21:51.780> to<00:21:51.960> spend 00:21:52.130 --> 00:21:52.140 align:start position:0% case like if you are trying to spend 00:21:52.140 --> 00:21:53.870 align:start position:0% case like if you are trying to spend like<00:21:52.320> if<00:21:52.500> you<00:21:52.679> if<00:21:52.860> you<00:21:53.039> have<00:21:53.100> utxo<00:21:53.640> and<00:21:53.760> I<00:21:53.820> have 00:21:53.870 --> 00:21:53.880 align:start position:0% like if you if you have utxo and I have 00:21:53.880 --> 00:21:55.490 align:start position:0% like if you if you have utxo and I have utxo<00:21:54.360> and<00:21:54.480> we<00:21:54.720> submit<00:21:55.020> transactions<00:21:55.380> for 00:21:55.490 --> 00:21:55.500 align:start position:0% utxo and we submit transactions for 00:21:55.500 --> 00:21:57.289 align:start position:0% utxo and we submit transactions for whatever<00:21:55.620> reason<00:21:55.799> that<00:21:56.159> both<00:21:56.880> of<00:21:57.000> us<00:21:57.120> can 00:21:57.289 --> 00:21:57.299 align:start position:0% whatever reason that both of us can 00:21:57.299 --> 00:21:59.149 align:start position:0% whatever reason that both of us can consume<00:21:57.720> the<00:21:58.080> blog<00:21:58.380> producer<00:21:58.740> will<00:21:58.860> need<00:21:59.039> to 00:21:59.149 --> 00:21:59.159 align:start position:0% consume the blog producer will need to 00:21:59.159 --> 00:22:01.310 align:start position:0% consume the blog producer will need to decide<00:21:59.400> which<00:21:59.760> of<00:22:00.419> those<00:22:00.600> transaction<00:22:00.960> goes 00:22:01.310 --> 00:22:01.320 align:start position:0% decide which of those transaction goes 00:22:01.320 --> 00:22:02.690 align:start position:0% decide which of those transaction goes through<00:22:01.440> because 00:22:02.690 --> 00:22:02.700 align:start position:0% through because 00:22:02.700 --> 00:22:05.570 align:start position:0% through because um<00:22:02.760> you<00:22:03.000> know<00:22:03.059> you<00:22:03.240> can't<00:22:03.419> you<00:22:04.260> can't<00:22:04.580> execute 00:22:05.570 --> 00:22:05.580 align:start position:0% um you know you can't you can't execute 00:22:05.580 --> 00:22:06.289 align:start position:0% um you know you can't you can't execute both<00:22:05.700> of<00:22:05.820> those<00:22:05.880> transactions 00:22:06.289 --> 00:22:06.299 align:start position:0% both of those transactions 00:22:06.299 --> 00:22:07.909 align:start position:0% both of those transactions simultaneously<00:22:06.900> because<00:22:07.080> there<00:22:07.320> will<00:22:07.440> be<00:22:07.620> you 00:22:07.909 --> 00:22:07.919 align:start position:0% simultaneously because there will be you 00:22:07.919 --> 00:22:08.930 align:start position:0% simultaneously because there will be you know<00:22:07.980> one<00:22:08.220> of<00:22:08.340> them<00:22:08.460> will<00:22:08.580> produce<00:22:08.880> a 00:22:08.930 --> 00:22:08.940 align:start position:0% know one of them will produce a 00:22:08.940 --> 00:22:10.490 align:start position:0% know one of them will produce a nullifier<00:22:09.360> that<00:22:09.600> the<00:22:10.020> second<00:22:10.140> transaction 00:22:10.490 --> 00:22:10.500 align:start position:0% nullifier that the second transaction 00:22:10.500 --> 00:22:11.810 align:start position:0% nullifier that the second transaction will<00:22:10.740> not<00:22:10.860> succeed<00:22:11.159> because<00:22:11.280> the<00:22:11.460> nullifier 00:22:11.810 --> 00:22:11.820 align:start position:0% will not succeed because the nullifier 00:22:11.820 --> 00:22:13.970 align:start position:0% will not succeed because the nullifier for<00:22:12.000> this<00:22:12.120> utxo<00:22:12.600> has<00:22:12.780> already<00:22:12.900> been<00:22:13.080> created 00:22:13.970 --> 00:22:13.980 align:start position:0% for this utxo has already been created 00:22:13.980 --> 00:22:16.010 align:start position:0% for this utxo has already been created so<00:22:14.520> like<00:22:14.760> in<00:22:14.880> the<00:22:15.000> union<00:22:15.120> swap<00:22:15.419> example<00:22:15.780> you 00:22:16.010 --> 00:22:16.020 align:start position:0% so like in the union swap example you 00:22:16.020 --> 00:22:18.230 align:start position:0% so like in the union swap example you can<00:22:16.140> send<00:22:16.380> so<00:22:16.620> like<00:22:16.799> you<00:22:16.919> can<00:22:17.100> send<00:22:17.280> a<00:22:17.760> note 00:22:18.230 --> 00:22:18.240 align:start position:0% can send so like you can send a note 00:22:18.240 --> 00:22:19.850 align:start position:0% can send so like you can send a note that<00:22:18.480> says<00:22:18.659> I<00:22:18.840> want<00:22:19.020> to<00:22:19.140> swap<00:22:19.260> token<00:22:19.620> a<00:22:19.679> for 00:22:19.850 --> 00:22:19.860 align:start position:0% that says I want to swap token a for 00:22:19.860 --> 00:22:22.130 align:start position:0% that says I want to swap token a for token<00:22:20.159> B<00:22:20.280> right<00:22:20.520> at<00:22:20.700> this<00:22:20.880> price<00:22:21.059> and<00:22:21.360> somebody 00:22:22.130 --> 00:22:22.140 align:start position:0% token B right at this price and somebody 00:22:22.140 --> 00:22:23.630 align:start position:0% token B right at this price and somebody else<00:22:22.380> can<00:22:22.559> do<00:22:22.679> the<00:22:22.799> same<00:22:22.919> thing<00:22:23.039> and<00:22:23.280> those<00:22:23.400> are 00:22:23.630 --> 00:22:23.640 align:start position:0% else can do the same thing and those are 00:22:23.640 --> 00:22:25.370 align:start position:0% else can do the same thing and those are two<00:22:23.820> different<00:22:24.179> requests<00:22:24.720> but<00:22:25.080> then<00:22:25.200> the 00:22:25.370 --> 00:22:25.380 align:start position:0% two different requests but then the 00:22:25.380 --> 00:22:26.750 align:start position:0% two different requests but then the block<00:22:25.500> producer<00:22:25.980> will<00:22:26.159> aggregate<00:22:26.580> those 00:22:26.750 --> 00:22:26.760 align:start position:0% block producer will aggregate those 00:22:26.760 --> 00:22:28.909 align:start position:0% block producer will aggregate those requests<00:22:27.179> sequence<00:22:27.840> them<00:22:28.080> in<00:22:28.559> a<00:22:28.679> single 00:22:28.909 --> 00:22:28.919 align:start position:0% requests sequence them in a single 00:22:28.919 --> 00:22:30.289 align:start position:0% requests sequence them in a single transaction<00:22:29.220> and<00:22:29.520> execute<00:22:29.880> them<00:22:30.000> and<00:22:30.179> there 00:22:30.289 --> 00:22:30.299 align:start position:0% transaction and execute them and there 00:22:30.299 --> 00:22:31.970 align:start position:0% transaction and execute them and there will<00:22:30.419> be<00:22:30.539> no<00:22:30.720> conflict<00:22:31.020> on<00:22:31.200> that<00:22:31.380> because<00:22:31.500> the 00:22:31.970 --> 00:22:31.980 align:start position:0% will be no conflict on that because the 00:22:31.980 --> 00:22:34.490 align:start position:0% will be no conflict on that because the the<00:22:32.340> state<00:22:32.580> of<00:22:32.820> the<00:22:33.120> uni<00:22:33.539> swap<00:22:33.780> contract<00:22:34.080> gets 00:22:34.490 --> 00:22:34.500 align:start position:0% the state of the uni swap contract gets 00:22:34.500 --> 00:22:37.270 align:start position:0% the state of the uni swap contract gets updated<00:22:34.740> sequentially<00:22:35.220> after<00:22:35.580> each<00:22:36.059> uh 00:22:37.270 --> 00:22:37.280 align:start position:0% updated sequentially after each uh 00:22:37.280 --> 00:22:39.590 align:start position:0% updated sequentially after each uh consume<00:22:38.280> node<00:22:38.520> so<00:22:38.880> you're<00:22:39.000> not<00:22:39.120> consuming<00:22:39.480> the 00:22:39.590 --> 00:22:39.600 align:start position:0% consume node so you're not consuming the 00:22:39.600 --> 00:22:41.330 align:start position:0% consume node so you're not consuming the same<00:22:39.720> utxo<00:22:40.260> you're<00:22:40.500> applying<00:22:40.980> the<00:22:41.159> different 00:22:41.330 --> 00:22:41.340 align:start position:0% same utxo you're applying the different 00:22:41.340 --> 00:22:43.310 align:start position:0% same utxo you're applying the different nodes<00:22:41.640> to<00:22:41.820> the<00:22:42.000> same<00:22:42.120> account<00:22:42.240> but<00:22:42.720> yes<00:22:43.080> that 00:22:43.310 --> 00:22:43.320 align:start position:0% nodes to the same account but yes that 00:22:43.320 --> 00:22:44.570 align:start position:0% nodes to the same account but yes that cannot<00:22:43.559> be<00:22:43.679> done<00:22:43.799> locally<00:22:44.100> that<00:22:44.280> needs<00:22:44.460> to<00:22:44.460> be 00:22:44.570 --> 00:22:44.580 align:start position:0% cannot be done locally that needs to be 00:22:44.580 --> 00:22:46.909 align:start position:0% cannot be done locally that needs to be done<00:22:44.640> by<00:22:44.820> a<00:22:44.940> block<00:22:45.059> producer 00:22:46.909 --> 00:22:46.919 align:start position:0% done by a block producer 00:22:46.919 --> 00:22:49.310 align:start position:0% done by a block producer um it's<00:22:47.460> an<00:22:47.640> optimization<00:22:48.179> uh<00:22:48.720> the<00:22:48.900> idea<00:22:49.200> is 00:22:49.310 --> 00:22:49.320 align:start position:0% um it's an optimization uh the idea is 00:22:49.320 --> 00:22:51.770 align:start position:0% um it's an optimization uh the idea is that<00:22:49.620> if<00:22:49.980> you<00:22:50.159> want<00:22:50.280> to<00:22:50.400> have<00:22:50.580> an<00:22:51.240> um<00:22:51.240> if<00:22:51.600> like 00:22:51.770 --> 00:22:51.780 align:start position:0% that if you want to have an um if like 00:22:51.780 --> 00:22:52.970 align:start position:0% that if you want to have an um if like let's<00:22:52.080> say 00:22:52.970 --> 00:22:52.980 align:start position:0% let's say 00:22:52.980 --> 00:22:54.830 align:start position:0% let's say um<00:22:53.039> your<00:22:53.580> node<00:22:53.820> was<00:22:54.059> created<00:22:54.299> in<00:22:54.480> a<00:22:54.659> prior 00:22:54.830 --> 00:22:54.840 align:start position:0% um your node was created in a prior 00:22:54.840 --> 00:22:56.690 align:start position:0% um your node was created in a prior Epoch<00:22:55.380> and<00:22:55.500> the<00:22:55.620> nullifier<00:22:56.039> was<00:22:56.280> created<00:22:56.460> then 00:22:56.690 --> 00:22:56.700 align:start position:0% Epoch and the nullifier was created then 00:22:56.700 --> 00:22:58.789 align:start position:0% Epoch and the nullifier was created then you<00:22:57.360> you<00:22:57.539> will<00:22:57.780> need<00:22:57.900> to<00:22:58.020> provide<00:22:58.320> the<00:22:58.559> path 00:22:58.789 --> 00:22:58.799 align:start position:0% you you will need to provide the path 00:22:58.799 --> 00:23:00.710 align:start position:0% you you will need to provide the path that<00:22:59.159> proves<00:22:59.460> that<00:22:59.640> it<00:22:59.760> was<00:23:00.240> it<00:23:00.419> hasn't<00:23:00.659> been 00:23:00.710 --> 00:23:00.720 align:start position:0% that proves that it was it hasn't been 00:23:00.720 --> 00:23:02.450 align:start position:0% that proves that it was it hasn't been consumed<00:23:01.080> yourself<00:23:01.260> the<00:23:01.679> node<00:23:01.919> the<00:23:02.159> nodes<00:23:02.340> are 00:23:02.450 --> 00:23:02.460 align:start position:0% consumed yourself the node the nodes are 00:23:02.460 --> 00:23:04.610 align:start position:0% consumed yourself the node the nodes are not<00:23:02.640> responsible<00:23:03.059> for<00:23:03.240> that<00:23:03.360> so<00:23:03.900> the<00:23:04.080> notes 00:23:04.610 --> 00:23:04.620 align:start position:0% not responsible for that so the notes 00:23:04.620 --> 00:23:05.930 align:start position:0% not responsible for that so the notes are<00:23:04.740> meant<00:23:04.919> to<00:23:05.039> be<00:23:05.100> like<00:23:05.340> a<00:23:05.520> short-lived 00:23:05.930 --> 00:23:05.940 align:start position:0% are meant to be like a short-lived 00:23:05.940 --> 00:23:07.610 align:start position:0% are meant to be like a short-lived object<00:23:06.240> so<00:23:06.480> they<00:23:06.659> are<00:23:06.780> not<00:23:06.900> meant<00:23:07.140> to<00:23:07.200> stay<00:23:07.440> in 00:23:07.610 --> 00:23:07.620 align:start position:0% object so they are not meant to stay in 00:23:07.620 --> 00:23:09.350 align:start position:0% object so they are not meant to stay in a<00:23:07.740> state<00:23:07.919> for<00:23:08.159> a<00:23:08.280> long<00:23:08.400> time<00:23:08.580> and<00:23:09.059> if<00:23:09.179> for 00:23:09.350 --> 00:23:09.360 align:start position:0% a state for a long time and if for 00:23:09.360 --> 00:23:10.669 align:start position:0% a state for a long time and if for whatever<00:23:09.419> reason<00:23:09.659> you<00:23:09.840> decided<00:23:10.200> to<00:23:10.320> keep<00:23:10.500> the 00:23:10.669 --> 00:23:10.679 align:start position:0% whatever reason you decided to keep the 00:23:10.679 --> 00:23:12.649 align:start position:0% whatever reason you decided to keep the state<00:23:10.860> there<00:23:11.159> for<00:23:11.520> uh<00:23:12.059> quite<00:23:12.240> long<00:23:12.419> that's 00:23:12.649 --> 00:23:12.659 align:start position:0% state there for uh quite long that's 00:23:12.659 --> 00:23:13.789 align:start position:0% state there for uh quite long that's your<00:23:12.780> responsibility<00:23:13.200> to<00:23:13.440> be<00:23:13.559> able<00:23:13.679> to 00:23:13.789 --> 00:23:13.799 align:start position:0% your responsibility to be able to 00:23:13.799 --> 00:23:15.529 align:start position:0% your responsibility to be able to provide<00:23:14.039> this<00:23:14.220> proof<00:23:14.520> to<00:23:14.700> uh<00:23:15.179> the<00:23:15.419> network 00:23:15.529 --> 00:23:15.539 align:start position:0% provide this proof to uh the network 00:23:15.539 --> 00:23:17.090 align:start position:0% provide this proof to uh the network it's<00:23:15.840> not<00:23:16.020> Network's<00:23:16.380> responsibility<00:23:16.860> to 00:23:17.090 --> 00:23:17.100 align:start position:0% it's not Network's responsibility to 00:23:17.100 --> 00:23:18.830 align:start position:0% it's not Network's responsibility to keep<00:23:17.220> it<00:23:17.400> for<00:23:17.580> more<00:23:18.120> than<00:23:18.240> let's<00:23:18.419> say<00:23:18.539> six 00:23:18.830 --> 00:23:18.840 align:start position:0% keep it for more than let's say six 00:23:18.840 --> 00:23:21.490 align:start position:0% keep it for more than let's say six months<00:23:19.080> or<00:23:19.200> so 00:23:21.490 --> 00:23:21.500 align:start position:0% 00:23:21.500 --> 00:23:24.679 align:start position:0% thank<00:23:22.500> you