WEBVTT Kind: captions Language: en 00:00:00.000 --> 00:00:18.830 align:start position:0% [Music] 00:00:18.830 --> 00:00:18.840 align:start position:0% 00:00:18.840 --> 00:00:21.349 align:start position:0% okay<00:00:19.119> I<00:00:19.199> think<00:00:19.320> we're<00:00:19.520> good<00:00:19.640> to<00:00:19.800> get<00:00:20.359> started 00:00:21.349 --> 00:00:21.359 align:start position:0% okay I think we're good to get started 00:00:21.359 --> 00:00:24.990 align:start position:0% okay I think we're good to get started hello<00:00:22.039> welcome<00:00:22.439> to<00:00:22.720> the<00:00:23.000> workshop<00:00:23.439> for<00:00:23.720> RP 00:00:24.990 --> 00:00:25.000 align:start position:0% hello welcome to the workshop for RP 00:00:25.000 --> 00:00:27.870 align:start position:0% hello welcome to the workshop for RP 7755<00:00:26.000> this<00:00:26.119> is<00:00:26.279> a<00:00:26.480> proposed<00:00:26.920> standard<00:00:27.480> for 00:00:27.870 --> 00:00:27.880 align:start position:0% 7755 this is a proposed standard for 00:00:27.880 --> 00:00:29.830 align:start position:0% 7755 this is a proposed standard for empowering<00:00:28.480> low-level<00:00:29.039> cross-chain<00:00:29.519> calls 00:00:29.830 --> 00:00:29.840 align:start position:0% empowering low-level cross-chain calls 00:00:29.840 --> 00:00:32.670 align:start position:0% empowering low-level cross-chain calls with<00:00:30.080> minimal<00:00:30.840> um<00:00:30.960> trust<00:00:31.520> assumptions<00:00:32.520> my 00:00:32.670 --> 00:00:32.680 align:start position:0% with minimal um trust assumptions my 00:00:32.680 --> 00:00:35.150 align:start position:0% with minimal um trust assumptions my name<00:00:32.800> is<00:00:33.000> Jack<00:00:33.160> chuma<00:00:33.879> I'm<00:00:34.520> uh<00:00:34.760> a<00:00:34.879> senior 00:00:35.150 --> 00:00:35.160 align:start position:0% name is Jack chuma I'm uh a senior 00:00:35.160 --> 00:00:37.150 align:start position:0% name is Jack chuma I'm uh a senior software<00:00:35.480> engineer<00:00:35.840> working<00:00:36.320> in<00:00:36.480> R&D<00:00:36.960> on<00:00:37.040> the 00:00:37.150 --> 00:00:37.160 align:start position:0% software engineer working in R&D on the 00:00:37.160 --> 00:00:40.110 align:start position:0% software engineer working in R&D on the base<00:00:37.399> team<00:00:37.600> at<00:00:38.160> coinbase<00:00:39.160> and<00:00:39.360> I'm<00:00:39.520> so<00:00:39.760> ex 00:00:40.110 --> 00:00:40.120 align:start position:0% base team at coinbase and I'm so ex 00:00:40.120 --> 00:00:41.630 align:start position:0% base team at coinbase and I'm so ex excited<00:00:40.520> to<00:00:40.640> share<00:00:40.920> with<00:00:41.039> you<00:00:41.160> all<00:00:41.360> a<00:00:41.440> little 00:00:41.630 --> 00:00:41.640 align:start position:0% excited to share with you all a little 00:00:41.640 --> 00:00:43.910 align:start position:0% excited to share with you all a little bit<00:00:41.840> about<00:00:42.079> this 00:00:43.910 --> 00:00:43.920 align:start position:0% bit about this 00:00:43.920 --> 00:00:47.069 align:start position:0% bit about this project<00:00:44.920> so<00:00:45.200> a<00:00:45.320> couple<00:00:45.520> of<00:00:45.680> goals<00:00:46.000> for<00:00:46.199> today 00:00:47.069 --> 00:00:47.079 align:start position:0% project so a couple of goals for today 00:00:47.079 --> 00:00:48.750 align:start position:0% project so a couple of goals for today um<00:00:47.280> first<00:00:47.480> and<00:00:47.640> foremost<00:00:48.079> I<00:00:48.160> want<00:00:48.280> to<00:00:48.440> promote 00:00:48.750 --> 00:00:48.760 align:start position:0% um first and foremost I want to promote 00:00:48.760 --> 00:00:51.110 align:start position:0% um first and foremost I want to promote a<00:00:48.879> deeper<00:00:49.480> understanding<00:00:49.879> of<00:00:50.120> rip 00:00:51.110 --> 00:00:51.120 align:start position:0% a deeper understanding of rip 00:00:51.120 --> 00:00:53.830 align:start position:0% a deeper understanding of rip 7755<00:00:52.120> what<00:00:52.320> exactly<00:00:52.640> it<00:00:52.760> is<00:00:52.920> and<00:00:53.079> how<00:00:53.199> it 00:00:53.830 --> 00:00:53.840 align:start position:0% 7755 what exactly it is and how it 00:00:53.840 --> 00:00:57.470 align:start position:0% 7755 what exactly it is and how it works<00:00:54.879> um<00:00:55.879> second<00:00:56.760> considerations<00:00:57.320> for 00:00:57.470 --> 00:00:57.480 align:start position:0% works um second considerations for 00:00:57.480 --> 00:00:59.189 align:start position:0% works um second considerations for adding<00:00:57.719> new<00:00:57.879> chain<00:00:58.120> support<00:00:58.399> in<00:00:58.519> the<00:00:58.640> future 00:00:59.189 --> 00:00:59.199 align:start position:0% adding new chain support in the future 00:00:59.199 --> 00:01:01.790 align:start position:0% adding new chain support in the future as<00:00:59.320> I<00:00:59.480> foresee<00:01:00.039> that<00:01:00.199> being<00:01:00.440> one<00:01:00.559> of<00:01:00.760> the<00:01:01.280> uh 00:01:01.790 --> 00:01:01.800 align:start position:0% as I foresee that being one of the uh 00:01:01.800 --> 00:01:04.189 align:start position:0% as I foresee that being one of the uh main<00:01:02.039> opportunities<00:01:02.559> for<00:01:02.760> open<00:01:02.960> source 00:01:04.189 --> 00:01:04.199 align:start position:0% main opportunities for open source 00:01:04.199 --> 00:01:07.310 align:start position:0% main opportunities for open source contribution<00:01:05.199> number<00:01:05.519> three<00:01:06.000> one<00:01:06.119> of<00:01:06.400> the 00:01:07.310 --> 00:01:07.320 align:start position:0% contribution number three one of the 00:01:07.320 --> 00:01:10.630 align:start position:0% contribution number three one of the main<00:01:08.240> um<00:01:08.560> features<00:01:09.119> of<00:01:09.240> the<00:01:09.400> standard<00:01:10.119> is<00:01:10.439> that 00:01:10.630 --> 00:01:10.640 align:start position:0% main um features of the standard is that 00:01:10.640 --> 00:01:12.789 align:start position:0% main um features of the standard is that it<00:01:10.920> minimizes<00:01:11.479> trust<00:01:11.799> assumptions<00:01:12.560> and 00:01:12.789 --> 00:01:12.799 align:start position:0% it minimizes trust assumptions and 00:01:12.799 --> 00:01:14.990 align:start position:0% it minimizes trust assumptions and that's<00:01:13.040> done<00:01:13.280> via<00:01:13.520> a<00:01:13.640> mechanism<00:01:14.159> called<00:01:14.880> what 00:01:14.990 --> 00:01:15.000 align:start position:0% that's done via a mechanism called what 00:01:15.000 --> 00:01:16.789 align:start position:0% that's done via a mechanism called what we're<00:01:15.119> calling<00:01:15.360> nested<00:01:15.680> storage<00:01:16.040> proofs<00:01:16.560> so 00:01:16.789 --> 00:01:16.799 align:start position:0% we're calling nested storage proofs so 00:01:16.799 --> 00:01:18.990 align:start position:0% we're calling nested storage proofs so I'd<00:01:16.920> like<00:01:17.040> to<00:01:17.119> do<00:01:17.240> a<00:01:17.320> deep<00:01:17.560> dive<00:01:17.840> there<00:01:18.200> and<00:01:18.600> uh 00:01:18.990 --> 00:01:19.000 align:start position:0% I'd like to do a deep dive there and uh 00:01:19.000 --> 00:01:21.350 align:start position:0% I'd like to do a deep dive there and uh promote<00:01:19.479> a<00:01:19.720> a<00:01:19.840> deeper<00:01:20.360> understanding<00:01:21.079> um<00:01:21.240> and 00:01:21.350 --> 00:01:21.360 align:start position:0% promote a a deeper understanding um and 00:01:21.360 --> 00:01:23.630 align:start position:0% promote a a deeper understanding um and then<00:01:21.520> lastly<00:01:21.920> integration<00:01:22.400> details<00:01:23.400> so<00:01:23.560> if 00:01:23.630 --> 00:01:23.640 align:start position:0% then lastly integration details so if 00:01:23.640 --> 00:01:25.590 align:start position:0% then lastly integration details so if you're<00:01:23.759> an<00:01:23.880> app<00:01:24.119> developer<00:01:24.880> and<00:01:25.280> you<00:01:25.400> would 00:01:25.590 --> 00:01:25.600 align:start position:0% you're an app developer and you would 00:01:25.600 --> 00:01:27.630 align:start position:0% you're an app developer and you would like<00:01:25.720> to<00:01:25.840> be<00:01:25.960> able<00:01:26.159> to<00:01:26.799> facilitate<00:01:27.360> some<00:01:27.520> kind 00:01:27.630 --> 00:01:27.640 align:start position:0% like to be able to facilitate some kind 00:01:27.640 --> 00:01:29.310 align:start position:0% like to be able to facilitate some kind of<00:01:27.799> cross-chain<00:01:28.240> call<00:01:28.520> between<00:01:28.759> l2s<00:01:29.159> and<00:01:29.280> the 00:01:29.310 --> 00:01:29.320 align:start position:0% of cross-chain call between l2s and the 00:01:29.320 --> 00:01:31.749 align:start position:0% of cross-chain call between l2s and the ethereum<00:01:29.640> EOS<00:01:30.040> system<00:01:30.759> how<00:01:30.880> would<00:01:31.079> that<00:01:31.240> work 00:01:31.749 --> 00:01:31.759 align:start position:0% ethereum EOS system how would that work 00:01:31.759 --> 00:01:33.749 align:start position:0% ethereum EOS system how would that work um<00:01:32.479> if<00:01:32.600> you're<00:01:32.799> if<00:01:32.880> you're<00:01:33.240> integrating<00:01:33.640> with 00:01:33.749 --> 00:01:33.759 align:start position:0% um if you're if you're integrating with 00:01:33.759 --> 00:01:36.030 align:start position:0% um if you're if you're integrating with the 00:01:36.030 --> 00:01:36.040 align:start position:0% 00:01:36.040 --> 00:01:38.510 align:start position:0% standard<00:01:37.040> so<00:01:37.200> to<00:01:37.320> give<00:01:37.439> you<00:01:37.560> some<00:01:37.759> context<00:01:38.320> in 00:01:38.510 --> 00:01:38.520 align:start position:0% standard so to give you some context in 00:01:38.520 --> 00:01:40.469 align:start position:0% standard so to give you some context in a<00:01:38.799> a<00:01:38.960> highle<00:01:39.399> purpose<00:01:39.799> on<00:01:39.960> where<00:01:40.079> we're<00:01:40.240> coming 00:01:40.469 --> 00:01:40.479 align:start position:0% a a highle purpose on where we're coming 00:01:40.479 --> 00:01:43.149 align:start position:0% a a highle purpose on where we're coming from<00:01:40.720> here<00:01:41.680> I<00:01:41.920> included<00:01:42.320> a<00:01:42.479> screenshot<00:01:43.000> here 00:01:43.149 --> 00:01:43.159 align:start position:0% from here I included a screenshot here 00:01:43.159 --> 00:01:46.510 align:start position:0% from here I included a screenshot here from<00:01:43.320> L2<00:01:43.759> beat<00:01:44.520> um<00:01:44.640> sometime<00:01:45.079> last<00:01:45.280> week<00:01:46.200> and 00:01:46.510 --> 00:01:46.520 align:start position:0% from L2 beat um sometime last week and 00:01:46.520 --> 00:01:48.389 align:start position:0% from L2 beat um sometime last week and what<00:01:46.640> it's<00:01:46.759> showing<00:01:47.240> is<00:01:47.560> activity<00:01:48.159> in 00:01:48.389 --> 00:01:48.399 align:start position:0% what it's showing is activity in 00:01:48.399 --> 00:01:50.910 align:start position:0% what it's showing is activity in ethereum<00:01:48.880> l2s<00:01:49.880> and<00:01:50.040> more<00:01:50.280> specifically<00:01:50.799> how 00:01:50.910 --> 00:01:50.920 align:start position:0% ethereum l2s and more specifically how 00:01:50.920 --> 00:01:53.630 align:start position:0% ethereum l2s and more specifically how it's<00:01:51.079> surged<00:01:51.640> by<00:01:52.000> over<00:01:52.280> 500%<00:01:53.159> in<00:01:53.320> just<00:01:53.479> the 00:01:53.630 --> 00:01:53.640 align:start position:0% it's surged by over 500% in just the 00:01:53.640 --> 00:01:56.590 align:start position:0% it's surged by over 500% in just the last<00:01:53.920> year<00:01:54.719> Alone<00:01:55.719> um<00:01:56.000> and<00:01:56.119> that's<00:01:56.320> being 00:01:56.590 --> 00:01:56.600 align:start position:0% last year Alone um and that's being 00:01:56.600 --> 00:01:58.830 align:start position:0% last year Alone um and that's being spread<00:01:56.920> out<00:01:57.240> over<00:01:57.719> many<00:01:57.960> different<00:01:58.200> networks 00:01:58.830 --> 00:01:58.840 align:start position:0% spread out over many different networks 00:01:58.840 --> 00:02:00.310 align:start position:0% spread out over many different networks so<00:01:59.039> that's<00:01:59.200> why<00:01:59.280> I<00:01:59.360> chose<00:01:59.600> this<00:01:59.880> screenshot 00:02:00.310 --> 00:02:00.320 align:start position:0% so that's why I chose this screenshot 00:02:00.320 --> 00:02:02.510 align:start position:0% so that's why I chose this screenshot specifically<00:02:00.759> it<00:02:00.840> shows<00:02:01.840> um<00:02:02.000> a<00:02:02.119> handful<00:02:02.399> of 00:02:02.510 --> 00:02:02.520 align:start position:0% specifically it shows um a handful of 00:02:02.520 --> 00:02:05.029 align:start position:0% specifically it shows um a handful of networks<00:02:03.159> this<00:02:03.240> is<00:02:03.399> just<00:02:03.520> a<00:02:03.640> small<00:02:03.880> subset<00:02:04.439> of 00:02:05.029 --> 00:02:05.039 align:start position:0% networks this is just a small subset of 00:02:05.039 --> 00:02:06.749 align:start position:0% networks this is just a small subset of um<00:02:05.240> how<00:02:05.320> many<00:02:05.479> l2s<00:02:05.920> there<00:02:06.000> are<00:02:06.280> already<00:02:06.640> and 00:02:06.749 --> 00:02:06.759 align:start position:0% um how many l2s there are already and 00:02:06.759 --> 00:02:08.109 align:start position:0% um how many l2s there are already and that's<00:02:06.920> only<00:02:07.119> just<00:02:07.240> going<00:02:07.320> to<00:02:07.439> continue 00:02:08.109 --> 00:02:08.119 align:start position:0% that's only just going to continue 00:02:08.119 --> 00:02:10.990 align:start position:0% that's only just going to continue expanding<00:02:09.119> um<00:02:09.280> and<00:02:09.440> this<00:02:09.560> has<00:02:09.679> been<00:02:09.959> great<00:02:10.319> for 00:02:10.990 --> 00:02:11.000 align:start position:0% expanding um and this has been great for 00:02:11.000 --> 00:02:13.670 align:start position:0% expanding um and this has been great for scaling<00:02:11.480> ethereum<00:02:12.319> but<00:02:12.599> it<00:02:12.840> has<00:02:13.319> caused 00:02:13.670 --> 00:02:13.680 align:start position:0% scaling ethereum but it has caused 00:02:13.680 --> 00:02:16.350 align:start position:0% scaling ethereum but it has caused fragmentation<00:02:14.440> in<00:02:14.519> the<00:02:14.800> ecosystem<00:02:15.800> um<00:02:16.200> where 00:02:16.350 --> 00:02:16.360 align:start position:0% fragmentation in the ecosystem um where 00:02:16.360 --> 00:02:17.630 align:start position:0% fragmentation in the ecosystem um where if<00:02:16.440> you're<00:02:16.560> a<00:02:16.680> user<00:02:17.120> and<00:02:17.200> you<00:02:17.319> want<00:02:17.440> to 00:02:17.630 --> 00:02:17.640 align:start position:0% if you're a user and you want to 00:02:17.640 --> 00:02:19.190 align:start position:0% if you're a user and you want to interact<00:02:18.000> with<00:02:18.120> an<00:02:18.280> app<00:02:18.480> that's<00:02:18.680> deployed<00:02:19.040> to 00:02:19.190 --> 00:02:19.200 align:start position:0% interact with an app that's deployed to 00:02:19.200 --> 00:02:21.509 align:start position:0% interact with an app that's deployed to a<00:02:19.400> specific<00:02:19.760> chain<00:02:20.480> that<00:02:20.640> you<00:02:21.040> maybe<00:02:21.280> don't 00:02:21.509 --> 00:02:21.519 align:start position:0% a specific chain that you maybe don't 00:02:21.519 --> 00:02:23.670 align:start position:0% a specific chain that you maybe don't have<00:02:21.720> funds<00:02:22.040> on<00:02:22.840> um<00:02:22.959> there<00:02:23.040> are<00:02:23.200> certain<00:02:23.400> Hoops 00:02:23.670 --> 00:02:23.680 align:start position:0% have funds on um there are certain Hoops 00:02:23.680 --> 00:02:24.790 align:start position:0% have funds on um there are certain Hoops that<00:02:23.760> you<00:02:23.879> need<00:02:24.000> to<00:02:24.120> jump<00:02:24.319> through<00:02:24.560> to<00:02:24.680> get 00:02:24.790 --> 00:02:24.800 align:start position:0% that you need to jump through to get 00:02:24.800 --> 00:02:26.470 align:start position:0% that you need to jump through to get funds<00:02:25.080> to<00:02:25.200> the<00:02:25.280> correct<00:02:25.560> location<00:02:25.920> to<00:02:26.080> be<00:02:26.200> able 00:02:26.470 --> 00:02:26.480 align:start position:0% funds to the correct location to be able 00:02:26.480 --> 00:02:29.390 align:start position:0% funds to the correct location to be able to<00:02:27.480> um<00:02:28.120> you<00:02:28.239> know<00:02:28.519> interact<00:02:28.959> with<00:02:29.120> that 00:02:29.390 --> 00:02:29.400 align:start position:0% to um you know interact with that 00:02:29.400 --> 00:02:30.350 align:start position:0% to um you know interact with that application 00:02:30.350 --> 00:02:30.360 align:start position:0% application 00:02:30.360 --> 00:02:32.430 align:start position:0% application and<00:02:30.599> that<00:02:30.720> hurts<00:02:30.959> the<00:02:31.040> user<00:02:31.360> experience<00:02:32.319> it's 00:02:32.430 --> 00:02:32.440 align:start position:0% and that hurts the user experience it's 00:02:32.440 --> 00:02:34.509 align:start position:0% and that hurts the user experience it's a<00:02:32.560> critical<00:02:32.920> problem<00:02:33.200> that<00:02:33.360> has<00:02:33.480> to<00:02:33.599> be<00:02:33.720> solved 00:02:34.509 --> 00:02:34.519 align:start position:0% a critical problem that has to be solved 00:02:34.519 --> 00:02:37.869 align:start position:0% a critical problem that has to be solved um<00:02:34.720> and<00:02:35.040> so<00:02:36.040> to<00:02:36.280> solve<00:02:36.599> that<00:02:36.840> problem<00:02:37.519> uh<00:02:37.680> we 00:02:37.869 --> 00:02:37.879 align:start position:0% um and so to solve that problem uh we 00:02:37.879 --> 00:02:39.630 align:start position:0% um and so to solve that problem uh we believe<00:02:38.160> that<00:02:38.280> there<00:02:38.400> should<00:02:38.560> be<00:02:38.640> a<00:02:38.840> standard 00:02:39.630 --> 00:02:39.640 align:start position:0% believe that there should be a standard 00:02:39.640 --> 00:02:41.030 align:start position:0% believe that there should be a standard between<00:02:39.959> or<00:02:40.040> for<00:02:40.239> communication<00:02:40.760> between 00:02:41.030 --> 00:02:41.040 align:start position:0% between or for communication between 00:02:41.040 --> 00:02:43.589 align:start position:0% between or for communication between chains<00:02:42.040> that<00:02:42.560> uh<00:02:42.879> checks<00:02:43.159> the<00:02:43.280> following 00:02:43.589 --> 00:02:43.599 align:start position:0% chains that uh checks the following 00:02:43.599 --> 00:02:46.710 align:start position:0% chains that uh checks the following three<00:02:43.879> boxes<00:02:44.879> is<00:02:45.360> public<00:02:45.599> and<00:02:45.760> decentralized 00:02:46.710 --> 00:02:46.720 align:start position:0% three boxes is public and decentralized 00:02:46.720 --> 00:02:49.550 align:start position:0% three boxes is public and decentralized in<00:02:46.920> the<00:02:47.080> spirit<00:02:47.360> of<00:02:47.480> web<00:02:47.680> 3<00:02:48.680> relies<00:02:49.040> solely<00:02:49.400> on 00:02:49.550 --> 00:02:49.560 align:start position:0% in the spirit of web 3 relies solely on 00:02:49.560 --> 00:02:51.030 align:start position:0% in the spirit of web 3 relies solely on validation<00:02:50.040> data<00:02:50.319> that<00:02:50.400> is<00:02:50.519> trustless 00:02:51.030 --> 00:02:51.040 align:start position:0% validation data that is trustless 00:02:51.040 --> 00:02:52.750 align:start position:0% validation data that is trustless available<00:02:51.400> on<00:02:51.560> chain<00:02:51.920> so<00:02:52.120> minimal<00:02:52.440> trust 00:02:52.750 --> 00:02:52.760 align:start position:0% available on chain so minimal trust 00:02:52.760 --> 00:02:55.070 align:start position:0% available on chain so minimal trust assumptions<00:02:53.720> and<00:02:53.920> has<00:02:54.080> built-in<00:02:54.480> flexibility 00:02:55.070 --> 00:02:55.080 align:start position:0% assumptions and has built-in flexibility 00:02:55.080 --> 00:02:57.790 align:start position:0% assumptions and has built-in flexibility to<00:02:55.239> support<00:02:55.640> any<00:02:55.800> arbitrary<00:02:56.560> message<00:02:57.560> these 00:02:57.790 --> 00:02:57.800 align:start position:0% to support any arbitrary message these 00:02:57.800 --> 00:02:59.470 align:start position:0% to support any arbitrary message these three<00:02:58.280> uh<00:02:58.400> bullet<00:02:58.680> points<00:02:59.040> where<00:02:59.239> the<00:02:59.319> three 00:02:59.470 --> 00:02:59.480 align:start position:0% three uh bullet points where the three 00:02:59.480 --> 00:03:02.430 align:start position:0% three uh bullet points where the three North<00:02:59.840> stars<00:03:00.360> that<00:03:00.879> uh<00:03:01.000> we<00:03:01.120> kept<00:03:01.360> in<00:03:01.519> mind<00:03:02.000> as 00:03:02.430 --> 00:03:02.440 align:start position:0% North stars that uh we kept in mind as 00:03:02.440 --> 00:03:06.309 align:start position:0% North stars that uh we kept in mind as as<00:03:02.560> we<00:03:02.680> developed<00:03:03.200> the<00:03:03.640> RP<00:03:04.080> 7755<00:03:05.040> proposal<00:03:06.000> and 00:03:06.309 --> 00:03:06.319 align:start position:0% as we developed the RP 7755 proposal and 00:03:06.319 --> 00:03:08.070 align:start position:0% as we developed the RP 7755 proposal and uh<00:03:06.440> we'll<00:03:06.680> dive<00:03:06.920> in 00:03:08.070 --> 00:03:08.080 align:start position:0% uh we'll dive in 00:03:08.080 --> 00:03:11.990 align:start position:0% uh we'll dive in now<00:03:09.080> so<00:03:09.840> because<00:03:10.120> ethereum<00:03:10.480> l2s<00:03:11.319> uh<00:03:11.440> post<00:03:11.840> some 00:03:11.990 --> 00:03:12.000 align:start position:0% now so because ethereum l2s uh post some 00:03:12.000 --> 00:03:14.030 align:start position:0% now so because ethereum l2s uh post some sort<00:03:12.200> of<00:03:12.400> state<00:03:12.799> representation<00:03:13.480> to<00:03:13.599> a<00:03:13.680> shared 00:03:14.030 --> 00:03:14.040 align:start position:0% sort of state representation to a shared 00:03:14.040 --> 00:03:16.430 align:start position:0% sort of state representation to a shared execution<00:03:14.519> environment<00:03:15.519> they<00:03:15.720> are<00:03:15.959> uniquely 00:03:16.430 --> 00:03:16.440 align:start position:0% execution environment they are uniquely 00:03:16.440 --> 00:03:17.670 align:start position:0% execution environment they are uniquely positioned<00:03:16.799> to<00:03:16.920> solve<00:03:17.159> this<00:03:17.319> problem<00:03:17.560> with 00:03:17.670 --> 00:03:17.680 align:start position:0% positioned to solve this problem with 00:03:17.680 --> 00:03:19.630 align:start position:0% positioned to solve this problem with minimal<00:03:18.440> um<00:03:18.760> trust 00:03:19.630 --> 00:03:19.640 align:start position:0% minimal um trust 00:03:19.640 --> 00:03:22.110 align:start position:0% minimal um trust assumptions<00:03:20.640> uh<00:03:20.799> and<00:03:20.920> this<00:03:21.040> is<00:03:21.440> done<00:03:21.760> via<00:03:22.000> a 00:03:22.110 --> 00:03:22.120 align:start position:0% assumptions uh and this is done via a 00:03:22.120 --> 00:03:23.550 align:start position:0% assumptions uh and this is done via a mechanism<00:03:22.519> called<00:03:22.720> nested<00:03:23.000> storage<00:03:23.280> proofs 00:03:23.550 --> 00:03:23.560 align:start position:0% mechanism called nested storage proofs 00:03:23.560 --> 00:03:26.149 align:start position:0% mechanism called nested storage proofs as<00:03:23.720> I<00:03:24.040> previously<00:03:24.440> mentioned<00:03:25.440> um<00:03:25.720> this<00:03:25.879> allows 00:03:26.149 --> 00:03:26.159 align:start position:0% as I previously mentioned um this allows 00:03:26.159 --> 00:03:28.429 align:start position:0% as I previously mentioned um this allows us<00:03:26.280> to<00:03:26.440> prove<00:03:26.720> State<00:03:27.080> about<00:03:27.360> one<00:03:27.560> L2<00:03:28.120> from 00:03:28.429 --> 00:03:28.439 align:start position:0% us to prove State about one L2 from 00:03:28.439 --> 00:03:30.309 align:start position:0% us to prove State about one L2 from another<00:03:28.680> L2<00:03:29.239> even<00:03:29.439> though<00:03:29.599> they<00:03:29.799> don't<00:03:30.120> have<00:03:30.200> a 00:03:30.309 --> 00:03:30.319 align:start position:0% another L2 even though they don't have a 00:03:30.319 --> 00:03:32.789 align:start position:0% another L2 even though they don't have a direct<00:03:30.560> line<00:03:30.720> of 00:03:32.789 --> 00:03:32.799 align:start position:0% direct line of 00:03:32.799 --> 00:03:34.830 align:start position:0% direct line of communication<00:03:33.799> to<00:03:34.280> understand<00:03:34.439> storage 00:03:34.830 --> 00:03:34.840 align:start position:0% communication to understand storage 00:03:34.840 --> 00:03:36.550 align:start position:0% communication to understand storage proofs<00:03:35.439> um<00:03:35.560> I<00:03:35.640> think<00:03:35.760> it<00:03:35.840> makes<00:03:36.040> sense<00:03:36.239> to<00:03:36.360> do<00:03:36.480> a 00:03:36.550 --> 00:03:36.560 align:start position:0% proofs um I think it makes sense to do a 00:03:36.560 --> 00:03:39.190 align:start position:0% proofs um I think it makes sense to do a quick<00:03:36.760> refresher<00:03:37.319> on<00:03:37.879> Merkel<00:03:38.239> trees<00:03:38.959> uh<00:03:39.080> of 00:03:39.190 --> 00:03:39.200 align:start position:0% quick refresher on Merkel trees uh of 00:03:39.200 --> 00:03:42.190 align:start position:0% quick refresher on Merkel trees uh of course<00:03:39.439> this<00:03:39.560> is<00:03:39.720> nothing<00:03:40.000> new<00:03:40.400> but<00:03:41.040> uh<00:03:41.360> a 00:03:42.190 --> 00:03:42.200 align:start position:0% course this is nothing new but uh a 00:03:42.200 --> 00:03:44.309 align:start position:0% course this is nothing new but uh a required<00:03:42.599> prere<00:03:43.000> to<00:03:43.400> understand<00:03:43.840> um<00:03:43.959> storage 00:03:44.309 --> 00:03:44.319 align:start position:0% required prere to understand um storage 00:03:44.319 --> 00:03:46.350 align:start position:0% required prere to understand um storage proofs<00:03:44.760> and<00:03:44.879> how<00:03:45.000> they<00:03:45.080> work<00:03:45.239> under<00:03:45.400> the<00:03:45.519> hood 00:03:46.350 --> 00:03:46.360 align:start position:0% proofs and how they work under the hood 00:03:46.360 --> 00:03:50.070 align:start position:0% proofs and how they work under the hood so<00:03:47.040> uh<00:03:47.200> as<00:03:47.319> a<00:03:47.480> quick<00:03:47.799> quick<00:03:48.040> recap<00:03:48.720> here<00:03:49.720> um<00:03:49.959> a 00:03:50.070 --> 00:03:50.080 align:start position:0% so uh as a quick quick recap here um a 00:03:50.080 --> 00:03:51.750 align:start position:0% so uh as a quick quick recap here um a Merle<00:03:50.360> tree<00:03:50.560> is<00:03:50.680> basically<00:03:51.200> a<00:03:51.280> tree<00:03:51.519> data 00:03:51.750 --> 00:03:51.760 align:start position:0% Merle tree is basically a tree data 00:03:51.760 --> 00:03:54.149 align:start position:0% Merle tree is basically a tree data structure<00:03:52.239> where<00:03:52.400> each<00:03:52.680> node<00:03:53.280> is<00:03:53.560> a<00:03:53.760> hash<00:03:54.040> of 00:03:54.149 --> 00:03:54.159 align:start position:0% structure where each node is a hash of 00:03:54.159 --> 00:03:56.830 align:start position:0% structure where each node is a hash of its<00:03:54.319> direct<00:03:54.840> descendants<00:03:55.840> and<00:03:56.000> so<00:03:56.560> if<00:03:56.680> you 00:03:56.830 --> 00:03:56.840 align:start position:0% its direct descendants and so if you 00:03:56.840 --> 00:03:59.350 align:start position:0% its direct descendants and so if you wanted<00:03:57.120> to<00:03:57.319> represent<00:03:58.280> uh<00:03:58.760> like<00:03:58.879> in<00:03:59.040> this 00:03:59.350 --> 00:03:59.360 align:start position:0% wanted to represent uh like in this 00:03:59.360 --> 00:04:01.630 align:start position:0% wanted to represent uh like in this diagram<00:04:00.079> here<00:04:01.000> I<00:04:01.079> don't<00:04:01.200> know<00:04:01.280> if<00:04:01.360> you<00:04:01.439> can<00:04:01.519> see 00:04:01.630 --> 00:04:01.640 align:start position:0% diagram here I don't know if you can see 00:04:01.640 --> 00:04:03.949 align:start position:0% diagram here I don't know if you can see my<00:04:01.760> mouse<00:04:02.159> yeah<00:04:02.920> um<00:04:03.079> we<00:04:03.200> have<00:04:03.319> these<00:04:03.439> four<00:04:03.720> data 00:04:03.949 --> 00:04:03.959 align:start position:0% my mouse yeah um we have these four data 00:04:03.959 --> 00:04:06.270 align:start position:0% my mouse yeah um we have these four data blocks<00:04:04.280> a<00:04:04.439> b<00:04:04.640> c<00:04:04.799> and<00:04:04.959> d<00:04:05.680> and<00:04:05.799> if<00:04:05.879> you<00:04:06.000> wanted<00:04:06.200> to 00:04:06.270 --> 00:04:06.280 align:start position:0% blocks a b c and d and if you wanted to 00:04:06.280 --> 00:04:08.030 align:start position:0% blocks a b c and d and if you wanted to convert<00:04:06.560> that<00:04:06.680> into<00:04:06.799> a<00:04:06.879> Merkel<00:04:07.159> tree<00:04:07.599> each<00:04:07.840> one 00:04:08.030 --> 00:04:08.040 align:start position:0% convert that into a Merkel tree each one 00:04:08.040 --> 00:04:10.030 align:start position:0% convert that into a Merkel tree each one gets<00:04:08.280> hashed<00:04:08.920> uh<00:04:09.040> respectively<00:04:09.599> to<00:04:09.720> create<00:04:09.959> a 00:04:10.030 --> 00:04:10.040 align:start position:0% gets hashed uh respectively to create a 00:04:10.040 --> 00:04:12.589 align:start position:0% gets hashed uh respectively to create a leaf<00:04:10.280> node<00:04:10.519> for<00:04:10.640> the<00:04:10.760> tree<00:04:11.680> you<00:04:11.959> group<00:04:12.319> The<00:04:12.480> the 00:04:12.589 --> 00:04:12.599 align:start position:0% leaf node for the tree you group The the 00:04:12.599 --> 00:04:14.390 align:start position:0% leaf node for the tree you group The the nodes<00:04:12.840> into<00:04:13.079> groups<00:04:13.319> of<00:04:13.439> two<00:04:13.879> hash 00:04:14.390 --> 00:04:14.400 align:start position:0% nodes into groups of two hash 00:04:14.400 --> 00:04:16.150 align:start position:0% nodes into groups of two hash concatenate<00:04:14.920> them<00:04:15.200> hash<00:04:15.439> them<00:04:15.640> together<00:04:16.000> that 00:04:16.150 --> 00:04:16.160 align:start position:0% concatenate them hash them together that 00:04:16.160 --> 00:04:17.670 align:start position:0% concatenate them hash them together that creates<00:04:16.440> their<00:04:16.560> parent<00:04:16.840> node<00:04:17.359> and<00:04:17.440> you<00:04:17.560> do 00:04:17.670 --> 00:04:17.680 align:start position:0% creates their parent node and you do 00:04:17.680 --> 00:04:19.310 align:start position:0% creates their parent node and you do that<00:04:17.799> recursively<00:04:18.440> until<00:04:18.680> you<00:04:18.959> reach<00:04:19.199> the 00:04:19.310 --> 00:04:19.320 align:start position:0% that recursively until you reach the 00:04:19.320 --> 00:04:21.310 align:start position:0% that recursively until you reach the root<00:04:19.519> node<00:04:19.759> of<00:04:19.880> the<00:04:20.000> tree<00:04:20.759> and<00:04:20.919> effectively 00:04:21.310 --> 00:04:21.320 align:start position:0% root node of the tree and effectively 00:04:21.320 --> 00:04:22.990 align:start position:0% root node of the tree and effectively what<00:04:21.400> you've<00:04:21.600> done<00:04:21.840> is<00:04:22.000> generated<00:04:22.440> a<00:04:22.560> unique 00:04:22.990 --> 00:04:23.000 align:start position:0% what you've done is generated a unique 00:04:23.000 --> 00:04:25.469 align:start position:0% what you've done is generated a unique identifier<00:04:24.000> um<00:04:24.120> for<00:04:24.440> the<00:04:24.560> entire<00:04:24.880> data<00:04:25.120> set 00:04:25.469 --> 00:04:25.479 align:start position:0% identifier um for the entire data set 00:04:25.479 --> 00:04:27.990 align:start position:0% identifier um for the entire data set that<00:04:25.639> is<00:04:25.800> just<00:04:25.919> a<00:04:26.040> single<00:04:26.360> hash<00:04:27.360> so<00:04:27.639> this<00:04:27.759> has<00:04:27.880> a 00:04:27.990 --> 00:04:28.000 align:start position:0% that is just a single hash so this has a 00:04:28.000 --> 00:04:29.870 align:start position:0% that is just a single hash so this has a couple<00:04:28.199> of<00:04:28.400> interesting<00:04:28.800> properties<00:04:29.440> one 00:04:29.870 --> 00:04:29.880 align:start position:0% couple of interesting properties one 00:04:29.880 --> 00:04:32.110 align:start position:0% couple of interesting properties one being<00:04:30.240> that<00:04:30.639> if<00:04:30.960> any<00:04:31.199> of<00:04:31.360> the<00:04:31.520> data<00:04:31.759> blocks 00:04:32.110 --> 00:04:32.120 align:start position:0% being that if any of the data blocks 00:04:32.120 --> 00:04:34.990 align:start position:0% being that if any of the data blocks changes<00:04:32.639> in<00:04:32.880> any<00:04:33.120> way<00:04:33.680> whatsoever<00:04:34.680> the<00:04:34.880> the 00:04:34.990 --> 00:04:35.000 align:start position:0% changes in any way whatsoever the the 00:04:35.000 --> 00:04:37.469 align:start position:0% changes in any way whatsoever the the root<00:04:35.280> hash<00:04:35.520> is<00:04:35.680> going<00:04:35.840> to<00:04:35.960> change<00:04:36.479> completely 00:04:37.469 --> 00:04:37.479 align:start position:0% root hash is going to change completely 00:04:37.479 --> 00:04:40.749 align:start position:0% root hash is going to change completely um<00:04:37.840> and<00:04:37.919> then<00:04:38.280> this<00:04:38.479> also<00:04:39.120> like<00:04:39.639> this<00:04:40.320> property 00:04:40.749 --> 00:04:40.759 align:start position:0% um and then this also like this property 00:04:40.759 --> 00:04:42.469 align:start position:0% um and then this also like this property allows<00:04:41.039> us<00:04:41.160> to<00:04:41.360> efficiently<00:04:41.800> prove<00:04:42.120> inclusion 00:04:42.469 --> 00:04:42.479 align:start position:0% allows us to efficiently prove inclusion 00:04:42.479 --> 00:04:44.550 align:start position:0% allows us to efficiently prove inclusion or<00:04:42.680> exclusion<00:04:43.160> of<00:04:43.320> data<00:04:43.720> within<00:04:44.120> the<00:04:44.240> larger 00:04:44.550 --> 00:04:44.560 align:start position:0% or exclusion of data within the larger 00:04:44.560 --> 00:04:47.150 align:start position:0% or exclusion of data within the larger data<00:04:44.840> set<00:04:45.680> so<00:04:46.080> in<00:04:46.199> this<00:04:46.400> example<00:04:46.720> if<00:04:46.840> we<00:04:46.960> wanted 00:04:47.150 --> 00:04:47.160 align:start position:0% data set so in this example if we wanted 00:04:47.160 --> 00:04:49.270 align:start position:0% data set so in this example if we wanted to<00:04:47.360> prove<00:04:47.800> that<00:04:47.960> data<00:04:48.199> block<00:04:48.520> a<00:04:48.880> it<00:04:49.000> was<00:04:49.120> in 00:04:49.270 --> 00:04:49.280 align:start position:0% to prove that data block a it was in 00:04:49.280 --> 00:04:51.909 align:start position:0% to prove that data block a it was in this<00:04:49.400> larger<00:04:49.720> data<00:04:50.000> set<00:04:50.240> of<00:04:50.400> ABC<00:04:50.880> and<00:04:51.000> D<00:04:51.759> we 00:04:51.909 --> 00:04:51.919 align:start position:0% this larger data set of ABC and D we 00:04:51.919 --> 00:04:53.790 align:start position:0% this larger data set of ABC and D we first<00:04:52.120> would<00:04:52.280> need<00:04:52.400> a<00:04:52.520> verifier<00:04:53.240> to<00:04:53.680> have 00:04:53.790 --> 00:04:53.800 align:start position:0% first would need a verifier to have 00:04:53.800 --> 00:04:56.390 align:start position:0% first would need a verifier to have trustless<00:04:54.360> access<00:04:54.840> to<00:04:55.440> the<00:04:55.600> the<00:04:55.720> root<00:04:56.000> hash 00:04:56.390 --> 00:04:56.400 align:start position:0% trustless access to the the root hash 00:04:56.400 --> 00:04:58.469 align:start position:0% trustless access to the the root hash that<00:04:56.639> is<00:04:57.039> uh<00:04:57.120> represented<00:04:57.680> in<00:04:57.800> this<00:04:57.919> root<00:04:58.120> node 00:04:58.469 --> 00:04:58.479 align:start position:0% that is uh represented in this root node 00:04:58.479 --> 00:05:00.990 align:start position:0% that is uh represented in this root node up<00:04:58.680> here<00:04:59.320> if<00:04:59.479> that's<00:04:59.800> in<00:05:00.000> place<00:05:00.560> all<00:05:00.680> we'd<00:05:00.880> have 00:05:00.990 --> 00:05:01.000 align:start position:0% up here if that's in place all we'd have 00:05:01.000 --> 00:05:04.070 align:start position:0% up here if that's in place all we'd have to<00:05:01.120> supply<00:05:01.479> to<00:05:01.639> the<00:05:01.759> verifier<00:05:02.720> is<00:05:03.520> data<00:05:03.759> block 00:05:04.070 --> 00:05:04.080 align:start position:0% to supply to the verifier is data block 00:05:04.080 --> 00:05:07.350 align:start position:0% to supply to the verifier is data block a<00:05:05.039> and<00:05:05.160> then<00:05:05.479> this<00:05:05.639> node<00:05:06.000> of<00:05:06.199> hash<00:05:06.400> of<00:05:06.600> B<00:05:07.240> and 00:05:07.350 --> 00:05:07.360 align:start position:0% a and then this node of hash of B and 00:05:07.360 --> 00:05:11.029 align:start position:0% a and then this node of hash of B and then<00:05:07.560> this<00:05:07.759> node<00:05:08.120> hash<00:05:08.479> of<00:05:08.720> HC<00:05:09.639> HD<00:05:10.639> and<00:05:10.840> that 00:05:11.029 --> 00:05:11.039 align:start position:0% then this node hash of HC HD and that 00:05:11.039 --> 00:05:12.749 align:start position:0% then this node hash of HC HD and that data<00:05:11.320> alone<00:05:11.800> is<00:05:11.960> all<00:05:12.080> the<00:05:12.199> verifier<00:05:12.600> would 00:05:12.749 --> 00:05:12.759 align:start position:0% data alone is all the verifier would 00:05:12.759 --> 00:05:14.950 align:start position:0% data alone is all the verifier would need<00:05:12.919> to<00:05:13.120> recreate<00:05:13.919> the<00:05:14.160> the<00:05:14.240> root<00:05:14.520> hash<00:05:14.840> at 00:05:14.950 --> 00:05:14.960 align:start position:0% need to recreate the the root hash at 00:05:14.960 --> 00:05:16.909 align:start position:0% need to recreate the the root hash at the<00:05:15.080> top<00:05:15.199> of<00:05:15.280> the<00:05:15.360> tree<00:05:16.080> so<00:05:16.360> the<00:05:16.479> verifier 00:05:16.909 --> 00:05:16.919 align:start position:0% the top of the tree so the verifier 00:05:16.919 --> 00:05:18.870 align:start position:0% the top of the tree so the verifier would<00:05:17.080> then<00:05:17.280> Hash<00:05:17.560> A<00:05:17.840> to<00:05:18.000> create<00:05:18.280> this<00:05:18.400> Hash<00:05:18.639> a 00:05:18.870 --> 00:05:18.880 align:start position:0% would then Hash A to create this Hash a 00:05:18.880 --> 00:05:21.590 align:start position:0% would then Hash A to create this Hash a node<00:05:19.600> combine<00:05:19.960> Hash<00:05:20.199> A<00:05:20.400> with<00:05:20.560> hash<00:05:20.759> B<00:05:21.360> hash 00:05:21.590 --> 00:05:21.600 align:start position:0% node combine Hash A with hash B hash 00:05:21.600 --> 00:05:23.710 align:start position:0% node combine Hash A with hash B hash that<00:05:21.800> together<00:05:22.039> to<00:05:22.160> create<00:05:22.479> this<00:05:22.680> hash<00:05:22.960> ha<00:05:23.319> HB 00:05:23.710 --> 00:05:23.720 align:start position:0% that together to create this hash ha HB 00:05:23.720 --> 00:05:25.430 align:start position:0% that together to create this hash ha HB node<00:05:24.240> and<00:05:24.319> then<00:05:24.479> do<00:05:24.600> that<00:05:24.759> again<00:05:24.919> for<00:05:25.160> this 00:05:25.430 --> 00:05:25.440 align:start position:0% node and then do that again for this 00:05:25.440 --> 00:05:26.909 align:start position:0% node and then do that again for this this<00:05:25.600> final<00:05:25.880> level<00:05:26.120> to<00:05:26.240> recreate<00:05:26.600> the<00:05:26.720> root 00:05:26.909 --> 00:05:26.919 align:start position:0% this final level to recreate the root 00:05:26.919 --> 00:05:29.430 align:start position:0% this final level to recreate the root node<00:05:27.560> and<00:05:27.680> if<00:05:27.919> that<00:05:28.160> is<00:05:28.400> equivalent<00:05:28.880> to<00:05:29.120> this 00:05:29.430 --> 00:05:29.440 align:start position:0% node and if that is equivalent to this 00:05:29.440 --> 00:05:30.990 align:start position:0% node and if that is equivalent to this the<00:05:29.759> the<00:05:29.840> stored<00:05:30.160> root<00:05:30.400> node<00:05:30.680> that<00:05:30.800> the 00:05:30.990 --> 00:05:31.000 align:start position:0% the the stored root node that the 00:05:31.000 --> 00:05:32.990 align:start position:0% the the stored root node that the verifier<00:05:31.520> already<00:05:31.880> had<00:05:32.520> then<00:05:32.720> that's<00:05:32.880> a 00:05:32.990 --> 00:05:33.000 align:start position:0% verifier already had then that's a 00:05:33.000 --> 00:05:34.670 align:start position:0% verifier already had then that's a successful 00:05:34.670 --> 00:05:34.680 align:start position:0% successful 00:05:34.680 --> 00:05:37.189 align:start position:0% successful proof<00:05:35.680> so<00:05:35.880> how<00:05:36.000> does<00:05:36.120> that<00:05:36.240> apply<00:05:36.479> to<00:05:36.600> ethereum 00:05:37.189 --> 00:05:37.199 align:start position:0% proof so how does that apply to ethereum 00:05:37.199 --> 00:05:39.870 align:start position:0% proof so how does that apply to ethereum storage<00:05:38.199> um<00:05:38.400> basically<00:05:38.880> all<00:05:39.039> of<00:05:39.319> ethereum's 00:05:39.870 --> 00:05:39.880 align:start position:0% storage um basically all of ethereum's 00:05:39.880 --> 00:05:42.110 align:start position:0% storage um basically all of ethereum's state<00:05:40.240> is<00:05:40.400> represented<00:05:41.080> as<00:05:41.160> a<00:05:41.319> modified<00:05:41.800> form 00:05:42.110 --> 00:05:42.120 align:start position:0% state is represented as a modified form 00:05:42.120 --> 00:05:43.870 align:start position:0% state is represented as a modified form of<00:05:42.360> that<00:05:42.600> Merkel<00:05:42.960> tree<00:05:43.240> data<00:05:43.479> structure 00:05:43.870 --> 00:05:43.880 align:start position:0% of that Merkel tree data structure 00:05:43.880 --> 00:05:46.870 align:start position:0% of that Merkel tree data structure called<00:05:44.120> a<00:05:44.240> Merkel<00:05:44.680> Patricia<00:05:45.360> Tri<00:05:46.360> and<00:05:46.680> the 00:05:46.870 --> 00:05:46.880 align:start position:0% called a Merkel Patricia Tri and the 00:05:46.880 --> 00:05:49.110 align:start position:0% called a Merkel Patricia Tri and the exact<00:05:47.720> uh<00:05:47.880> details<00:05:48.560> in<00:05:48.639> terms<00:05:48.880> of<00:05:49.000> the 00:05:49.110 --> 00:05:49.120 align:start position:0% exact uh details in terms of the 00:05:49.120 --> 00:05:50.270 align:start position:0% exact uh details in terms of the differences<00:05:49.560> between<00:05:49.800> the<00:05:49.880> two<00:05:50.039> data 00:05:50.270 --> 00:05:50.280 align:start position:0% differences between the two data 00:05:50.280 --> 00:05:52.070 align:start position:0% differences between the two data structures<00:05:50.759> are<00:05:51.199> out<00:05:51.319> of<00:05:51.440> scope<00:05:51.720> for<00:05:51.880> this 00:05:52.070 --> 00:05:52.080 align:start position:0% structures are out of scope for this 00:05:52.080 --> 00:05:54.510 align:start position:0% structures are out of scope for this talk<00:05:52.479> but<00:05:53.280> um<00:05:53.520> it's<00:05:53.919> it's<00:05:54.080> basically<00:05:54.400> a 00:05:54.510 --> 00:05:54.520 align:start position:0% talk but um it's it's basically a 00:05:54.520 --> 00:05:56.590 align:start position:0% talk but um it's it's basically a handful<00:05:55.080> of<00:05:55.400> optimizations<00:05:56.000> for<00:05:56.240> theorem 00:05:56.590 --> 00:05:56.600 align:start position:0% handful of optimizations for theorem 00:05:56.600 --> 00:05:59.029 align:start position:0% handful of optimizations for theorem specific<00:05:56.919> use<00:05:57.160> cases<00:05:58.000> all<00:05:58.120> we<00:05:58.280> really<00:05:58.479> need<00:05:58.639> to 00:05:59.029 --> 00:05:59.039 align:start position:0% specific use cases all we really need to 00:05:59.039 --> 00:06:00.469 align:start position:0% specific use cases all we really need to know<00:05:59.199> or<00:05:59.319> care<00:05:59.479> about<00:05:59.680> about<00:05:59.919> for<00:06:00.080> this 00:06:00.469 --> 00:06:00.479 align:start position:0% know or care about about for this 00:06:00.479 --> 00:06:03.990 align:start position:0% know or care about about for this application<00:06:01.479> is<00:06:02.120> that<00:06:02.479> that<00:06:02.639> Merkel<00:06:03.080> proof<00:06:03.759> uh 00:06:03.990 --> 00:06:04.000 align:start position:0% application is that that Merkel proof uh 00:06:04.000 --> 00:06:07.270 align:start position:0% application is that that Merkel proof uh Paradigm<00:06:04.479> applies<00:06:05.039> here<00:06:06.039> so<00:06:06.599> for<00:06:06.840> every<00:06:07.039> block 00:06:07.270 --> 00:06:07.280 align:start position:0% Paradigm applies here so for every block 00:06:07.280 --> 00:06:09.629 align:start position:0% Paradigm applies here so for every block in<00:06:07.400> a<00:06:07.520> theum<00:06:08.039> there's<00:06:08.520> a<00:06:08.680> handful<00:06:09.039> of<00:06:09.360> block 00:06:09.629 --> 00:06:09.639 align:start position:0% in a theum there's a handful of block 00:06:09.639 --> 00:06:12.270 align:start position:0% in a theum there's a handful of block headers<00:06:10.120> one<00:06:10.240> of<00:06:10.360> which<00:06:10.520> being<00:06:10.720> a<00:06:10.800> state<00:06:11.280> route 00:06:12.270 --> 00:06:12.280 align:start position:0% headers one of which being a state route 00:06:12.280 --> 00:06:14.830 align:start position:0% headers one of which being a state route this<00:06:12.520> is<00:06:13.000> the<00:06:13.360> the<00:06:13.479> root<00:06:13.800> hash<00:06:14.080> for<00:06:14.360> a<00:06:14.479> Merkel 00:06:14.830 --> 00:06:14.840 align:start position:0% this is the the root hash for a Merkel 00:06:14.840 --> 00:06:16.510 align:start position:0% this is the the root hash for a Merkel Patricia<00:06:15.199> to<00:06:15.319> try<00:06:15.639> for<00:06:15.840> all<00:06:16.000> of<00:06:16.120> ethereum 00:06:16.510 --> 00:06:16.520 align:start position:0% Patricia to try for all of ethereum 00:06:16.520 --> 00:06:18.710 align:start position:0% Patricia to try for all of ethereum state<00:06:17.120> where<00:06:17.280> the<00:06:17.440> values<00:06:17.840> in<00:06:18.000> that<00:06:18.160> try<00:06:18.520> are 00:06:18.710 --> 00:06:18.720 align:start position:0% state where the values in that try are 00:06:18.720 --> 00:06:21.309 align:start position:0% state where the values in that try are ethereum<00:06:19.560> accounts<00:06:20.560> um<00:06:20.800> these<00:06:21.000> accounts 00:06:21.309 --> 00:06:21.319 align:start position:0% ethereum accounts um these accounts 00:06:21.319 --> 00:06:23.629 align:start position:0% ethereum accounts um these accounts could<00:06:21.479> be<00:06:21.919> EAS<00:06:22.520> so<00:06:22.720> like<00:06:22.840> any<00:06:23.000> offchain<00:06:23.319> wallet 00:06:23.629 --> 00:06:23.639 align:start position:0% could be EAS so like any offchain wallet 00:06:23.639 --> 00:06:26.150 align:start position:0% could be EAS so like any offchain wallet like<00:06:24.080> coinbase<00:06:24.520> wallet<00:06:24.800> or<00:06:24.960> or<00:06:25.080> metamask<00:06:26.039> or 00:06:26.150 --> 00:06:26.160 align:start position:0% like coinbase wallet or or metamask or 00:06:26.160 --> 00:06:29.350 align:start position:0% like coinbase wallet or or metamask or it<00:06:26.240> could<00:06:26.360> be<00:06:26.479> smart<00:06:26.720> contract<00:06:27.440> accounts<00:06:28.440> um 00:06:29.350 --> 00:06:29.360 align:start position:0% it could be smart contract accounts um 00:06:29.360 --> 00:06:31.189 align:start position:0% it could be smart contract accounts um the<00:06:29.960> like<00:06:30.120> these<00:06:30.319> accounts<00:06:30.919> as<00:06:31.000> they're 00:06:31.189 --> 00:06:31.199 align:start position:0% the like these accounts as they're 00:06:31.199 --> 00:06:32.909 align:start position:0% the like these accounts as they're represented<00:06:31.599> in<00:06:31.680> the<00:06:31.759> try<00:06:32.199> are<00:06:32.360> represented 00:06:32.909 --> 00:06:32.919 align:start position:0% represented in the try are represented 00:06:32.919 --> 00:06:35.350 align:start position:0% represented in the try are represented by<00:06:33.319> a<00:06:33.800> array<00:06:34.199> of<00:06:34.360> four<00:06:34.560> pieces<00:06:34.800> of<00:06:34.919> metadata 00:06:35.350 --> 00:06:35.360 align:start position:0% by a array of four pieces of metadata 00:06:35.360 --> 00:06:36.510 align:start position:0% by a array of four pieces of metadata about<00:06:35.520> the<00:06:35.639> account<00:06:35.960> and<00:06:36.080> that's<00:06:36.199> what<00:06:36.319> I<00:06:36.400> have 00:06:36.510 --> 00:06:36.520 align:start position:0% about the account and that's what I have 00:06:36.520 --> 00:06:38.150 align:start position:0% about the account and that's what I have listed<00:06:36.759> out<00:06:37.000> here<00:06:37.560> so<00:06:37.639> you<00:06:37.720> have<00:06:37.840> the<00:06:37.960> account 00:06:38.150 --> 00:06:38.160 align:start position:0% listed out here so you have the account 00:06:38.160 --> 00:06:41.629 align:start position:0% listed out here so you have the account nons<00:06:38.639> balance<00:06:39.319> storage<00:06:39.720> route<00:06:40.160> and<00:06:40.360> code<00:06:40.680> has 00:06:41.629 --> 00:06:41.639 align:start position:0% nons balance storage route and code has 00:06:41.639 --> 00:06:44.670 align:start position:0% nons balance storage route and code has for<00:06:42.360> um<00:06:43.280> yeah<00:06:43.440> so<00:06:43.599> for<00:06:43.840> smart<00:06:44.199> contract 00:06:44.670 --> 00:06:44.680 align:start position:0% for um yeah so for smart contract 00:06:44.680 --> 00:06:46.589 align:start position:0% for um yeah so for smart contract accounts<00:06:45.680> they're<00:06:45.880> it's<00:06:46.039> highly<00:06:46.240> likely<00:06:46.520> that 00:06:46.589 --> 00:06:46.599 align:start position:0% accounts they're it's highly likely that 00:06:46.599 --> 00:06:48.350 align:start position:0% accounts they're it's highly likely that they're<00:06:46.720> managing<00:06:47.120> some<00:06:47.280> type<00:06:47.440> of<00:06:47.599> state<00:06:48.240> and 00:06:48.350 --> 00:06:48.360 align:start position:0% they're managing some type of state and 00:06:48.360 --> 00:06:50.990 align:start position:0% they're managing some type of state and if<00:06:48.520> they<00:06:48.639> are<00:06:49.080> that<00:06:49.280> state<00:06:49.639> is<00:06:49.960> stored<00:06:50.720> um<00:06:50.880> in 00:06:50.990 --> 00:06:51.000 align:start position:0% if they are that state is stored um in 00:06:51.000 --> 00:06:53.670 align:start position:0% if they are that state is stored um in that<00:06:51.120> contract<00:06:51.840> storage<00:06:52.840> and<00:06:53.000> that<00:06:53.160> contract 00:06:53.670 --> 00:06:53.680 align:start position:0% that contract storage and that contract 00:06:53.680 --> 00:06:55.990 align:start position:0% that contract storage and that contract storage<00:06:54.240> is<00:06:54.479> also<00:06:54.759> represented<00:06:55.319> as<00:06:55.440> a<00:06:55.560> Merkel 00:06:55.990 --> 00:06:56.000 align:start position:0% storage is also represented as a Merkel 00:06:56.000 --> 00:06:58.230 align:start position:0% storage is also represented as a Merkel Patricia<00:06:56.360> try<00:06:56.720> under<00:06:56.919> the<00:06:57.080> hood<00:06:57.560> and<00:06:58.080> you 00:06:58.230 --> 00:06:58.240 align:start position:0% Patricia try under the hood and you 00:06:58.240 --> 00:07:00.029 align:start position:0% Patricia try under the hood and you guessed<00:06:58.479> it<00:06:58.599> the<00:06:58.720> root<00:06:58.960> of<00:06:59.120> that<00:06:59.240> TR<00:06:59.800> is<00:06:59.919> the 00:07:00.029 --> 00:07:00.039 align:start position:0% guessed it the root of that TR is the 00:07:00.039 --> 00:07:01.909 align:start position:0% guessed it the root of that TR is the storage<00:07:00.360> route<00:07:00.639> that<00:07:00.759> is<00:07:01.120> uh<00:07:01.199> stored<00:07:01.639> with<00:07:01.759> the 00:07:01.909 --> 00:07:01.919 align:start position:0% storage route that is uh stored with the 00:07:01.919 --> 00:07:04.589 align:start position:0% storage route that is uh stored with the account<00:07:02.879> so<00:07:03.120> if<00:07:03.280> we<00:07:03.479> have<00:07:03.720> access<00:07:04.039> to<00:07:04.240> a<00:07:04.360> state 00:07:04.589 --> 00:07:04.599 align:start position:0% account so if we have access to a state 00:07:04.599 --> 00:07:08.029 align:start position:0% account so if we have access to a state route<00:07:04.879> for<00:07:05.039> a<00:07:05.440> network<00:07:06.440> um<00:07:06.759> we<00:07:06.919> can<00:07:07.240> supply<00:07:07.840> a 00:07:08.029 --> 00:07:08.039 align:start position:0% route for a network um we can supply a 00:07:08.039 --> 00:07:10.309 align:start position:0% route for a network um we can supply a path<00:07:08.360> down<00:07:08.560> that<00:07:08.680> state<00:07:08.960> try<00:07:09.400> to<00:07:09.759> a<00:07:09.960> specific 00:07:10.309 --> 00:07:10.319 align:start position:0% path down that state try to a specific 00:07:10.319 --> 00:07:12.029 align:start position:0% path down that state try to a specific account<00:07:10.599> within<00:07:10.800> the<00:07:10.919> network<00:07:11.800> and<00:07:11.919> then 00:07:12.029 --> 00:07:12.039 align:start position:0% account within the network and then 00:07:12.039 --> 00:07:13.629 align:start position:0% account within the network and then using<00:07:12.360> that<00:07:12.560> account's<00:07:12.960> storage<00:07:13.280> route<00:07:13.560> which 00:07:13.629 --> 00:07:13.639 align:start position:0% using that account's storage route which 00:07:13.639 --> 00:07:14.830 align:start position:0% using that account's storage route which can<00:07:13.759> be<00:07:13.919> extracted<00:07:14.280> from<00:07:14.400> the<00:07:14.520> account's 00:07:14.830 --> 00:07:14.840 align:start position:0% can be extracted from the account's 00:07:14.840 --> 00:07:17.110 align:start position:0% can be extracted from the account's metadata<00:07:15.840> um<00:07:15.960> we<00:07:16.039> can<00:07:16.160> supply<00:07:16.520> another<00:07:16.800> path 00:07:17.110 --> 00:07:17.120 align:start position:0% metadata um we can supply another path 00:07:17.120 --> 00:07:18.510 align:start position:0% metadata um we can supply another path from<00:07:17.240> the<00:07:17.360> storage<00:07:17.639> route<00:07:17.840> to<00:07:17.960> a<00:07:18.120> specific 00:07:18.510 --> 00:07:18.520 align:start position:0% from the storage route to a specific 00:07:18.520 --> 00:07:20.869 align:start position:0% from the storage route to a specific location<00:07:19.000> in<00:07:19.120> that<00:07:19.280> accounts<00:07:19.720> storage<00:07:20.720> and 00:07:20.869 --> 00:07:20.879 align:start position:0% location in that accounts storage and 00:07:20.879 --> 00:07:22.749 align:start position:0% location in that accounts storage and that's<00:07:21.360> basically<00:07:21.720> the<00:07:21.840> highle<00:07:22.280> concept<00:07:22.599> of 00:07:22.749 --> 00:07:22.759 align:start position:0% that's basically the highle concept of 00:07:22.759 --> 00:07:24.790 align:start position:0% that's basically the highle concept of how<00:07:22.960> a<00:07:23.080> storage<00:07:23.360> proof 00:07:24.790 --> 00:07:24.800 align:start position:0% how a storage proof 00:07:24.800 --> 00:07:28.150 align:start position:0% how a storage proof works<00:07:25.800> so<00:07:26.440> how<00:07:26.599> does<00:07:26.759> that<00:07:26.919> apply<00:07:27.319> to<00:07:27.879> cross 00:07:28.150 --> 00:07:28.160 align:start position:0% works so how does that apply to cross 00:07:28.160 --> 00:07:29.270 align:start position:0% works so how does that apply to cross chain<00:07:28.360> messaging<00:07:28.759> though<00:07:28.960> because<00:07:29.120> that's 00:07:29.270 --> 00:07:29.280 align:start position:0% chain messaging though because that's 00:07:29.280 --> 00:07:32.150 align:start position:0% chain messaging though because that's just<00:07:30.000> proving<00:07:31.000> State<00:07:31.520> like<00:07:31.720> within<00:07:32.000> a 00:07:32.150 --> 00:07:32.160 align:start position:0% just proving State like within a 00:07:32.160 --> 00:07:34.510 align:start position:0% just proving State like within a specific<00:07:32.560> Network<00:07:33.560> so<00:07:33.759> to<00:07:33.919> explain<00:07:34.240> that<00:07:34.400> I 00:07:34.510 --> 00:07:34.520 align:start position:0% specific Network so to explain that I 00:07:34.520 --> 00:07:36.510 align:start position:0% specific Network so to explain that I have<00:07:34.720> this<00:07:34.919> diagram<00:07:35.479> here<00:07:35.840> it's<00:07:36.080> very 00:07:36.510 --> 00:07:36.520 align:start position:0% have this diagram here it's very 00:07:36.520 --> 00:07:39.070 align:start position:0% have this diagram here it's very simplified<00:07:37.319> obviously<00:07:38.280> but<00:07:38.639> um<00:07:38.759> this<00:07:38.919> meant 00:07:39.070 --> 00:07:39.080 align:start position:0% simplified obviously but um this meant 00:07:39.080 --> 00:07:41.350 align:start position:0% simplified obviously but um this meant to<00:07:39.199> represent<00:07:39.599> two<00:07:39.800> rollups<00:07:40.440> in<00:07:40.879> the<00:07:41.000> ethereum 00:07:41.350 --> 00:07:41.360 align:start position:0% to represent two rollups in the ethereum 00:07:41.360 --> 00:07:42.990 align:start position:0% to represent two rollups in the ethereum ecosystem<00:07:41.879> that<00:07:41.960> are<00:07:42.120> both<00:07:42.280> sharing<00:07:42.680> state 00:07:42.990 --> 00:07:43.000 align:start position:0% ecosystem that are both sharing state 00:07:43.000 --> 00:07:45.710 align:start position:0% ecosystem that are both sharing state with<00:07:43.160> a<00:07:43.319> a<00:07:43.400> shared<00:07:43.800> L1<00:07:44.800> um<00:07:44.919> so<00:07:45.080> this<00:07:45.199> L1<00:07:45.520> at<00:07:45.639> the 00:07:45.710 --> 00:07:45.720 align:start position:0% with a a shared L1 um so this L1 at the 00:07:45.720 --> 00:07:46.990 align:start position:0% with a a shared L1 um so this L1 at the bottom<00:07:45.919> would<00:07:46.000> be<00:07:46.080> like<00:07:46.199> ethereum<00:07:46.560> main<00:07:46.759> net 00:07:46.990 --> 00:07:47.000 align:start position:0% bottom would be like ethereum main net 00:07:47.000 --> 00:07:49.070 align:start position:0% bottom would be like ethereum main net and<00:07:47.120> then<00:07:47.319> chain<00:07:47.560> a<00:07:47.680> and<00:07:47.800> chain<00:07:48.000> B<00:07:48.159> are<00:07:48.319> two<00:07:48.599> L2 00:07:49.070 --> 00:07:49.080 align:start position:0% and then chain a and chain B are two L2 00:07:49.080 --> 00:07:51.469 align:start position:0% and then chain a and chain B are two L2 networks<00:07:50.080> what<00:07:50.199> this<00:07:50.319> diagram<00:07:50.680> is<00:07:50.800> depicting 00:07:51.469 --> 00:07:51.479 align:start position:0% networks what this diagram is depicting 00:07:51.479 --> 00:07:53.390 align:start position:0% networks what this diagram is depicting is<00:07:51.800> bidirectional<00:07:52.520> communication<00:07:53.120> between 00:07:53.390 --> 00:07:53.400 align:start position:0% is bidirectional communication between 00:07:53.400 --> 00:07:55.110 align:start position:0% is bidirectional communication between the<00:07:53.560> two<00:07:53.759> layer<00:07:54.000> two<00:07:54.199> chains<00:07:54.599> and<00:07:54.720> the<00:07:54.800> shared 00:07:55.110 --> 00:07:55.120 align:start position:0% the two layer two chains and the shared 00:07:55.120 --> 00:07:58.430 align:start position:0% the two layer two chains and the shared layer<00:07:55.440> one<00:07:56.440> um<00:07:57.120> for<00:07:57.479> this<00:07:57.680> downward<00:07:58.080> Arrow 00:07:58.430 --> 00:07:58.440 align:start position:0% layer one um for this downward Arrow 00:07:58.440 --> 00:08:01.469 align:start position:0% layer one um for this downward Arrow Direction<00:07:58.919> in<00:07:59.039> both<00:07:59.520> CHS<00:08:00.440> uh<00:08:00.599> an<00:08:00.720> ethereum<00:08:01.080> L2 00:08:01.469 --> 00:08:01.479 align:start position:0% Direction in both CHS uh an ethereum L2 00:08:01.479 --> 00:08:03.589 align:start position:0% Direction in both CHS uh an ethereum L2 chain<00:08:01.960> wouldn't<00:08:02.319> be<00:08:02.599> an<00:08:02.720> ethereum<00:08:03.080> L2<00:08:03.360> chain 00:08:03.589 --> 00:08:03.599 align:start position:0% chain wouldn't be an ethereum L2 chain 00:08:03.599 --> 00:08:05.550 align:start position:0% chain wouldn't be an ethereum L2 chain if<00:08:03.680> it<00:08:03.800> wasn't<00:08:04.039> sharing<00:08:04.440> state<00:08:04.800> with<00:08:04.919> L1<00:08:05.400> in 00:08:05.550 --> 00:08:05.560 align:start position:0% if it wasn't sharing state with L1 in 00:08:05.560 --> 00:08:08.309 align:start position:0% if it wasn't sharing state with L1 in some<00:08:06.479> uh<00:08:06.639> context<00:08:07.240> so<00:08:07.800> that's<00:08:07.960> what<00:08:08.080> this<00:08:08.159> is 00:08:08.309 --> 00:08:08.319 align:start position:0% some uh context so that's what this is 00:08:08.319 --> 00:08:10.589 align:start position:0% some uh context so that's what this is representing<00:08:08.840> here<00:08:09.560> uh<00:08:09.680> it's<00:08:09.840> requiring<00:08:10.400> that 00:08:10.589 --> 00:08:10.599 align:start position:0% representing here uh it's requiring that 00:08:10.599 --> 00:08:12.430 align:start position:0% representing here uh it's requiring that both<00:08:10.840> chains<00:08:11.400> are<00:08:11.680> sharing<00:08:12.159> some 00:08:12.430 --> 00:08:12.440 align:start position:0% both chains are sharing some 00:08:12.440 --> 00:08:14.390 align:start position:0% both chains are sharing some representation<00:08:13.039> of<00:08:13.199> their<00:08:13.400> state<00:08:14.080> with<00:08:14.280> what 00:08:14.390 --> 00:08:14.400 align:start position:0% representation of their state with what 00:08:14.400 --> 00:08:16.230 align:start position:0% representation of their state with what I'm<00:08:14.520> calling<00:08:14.720> a<00:08:14.800> rollup<00:08:15.199> contract<00:08:15.680> on<00:08:15.800> layer 00:08:16.230 --> 00:08:16.240 align:start position:0% I'm calling a rollup contract on layer 00:08:16.240 --> 00:08:18.629 align:start position:0% I'm calling a rollup contract on layer one<00:08:17.240> um<00:08:17.639> this<00:08:17.759> could<00:08:17.919> be<00:08:18.039> the<00:08:18.159> state<00:08:18.360> route 00:08:18.629 --> 00:08:18.639 align:start position:0% one um this could be the state route 00:08:18.639 --> 00:08:20.309 align:start position:0% one um this could be the state route directly<00:08:19.120> or<00:08:19.319> it<00:08:19.440> could<00:08:19.599> be<00:08:19.840> some<00:08:20.080> other 00:08:20.309 --> 00:08:20.319 align:start position:0% directly or it could be some other 00:08:20.319 --> 00:08:21.950 align:start position:0% directly or it could be some other representation<00:08:20.879> of<00:08:21.080> State<00:08:21.639> the<00:08:21.720> only 00:08:21.950 --> 00:08:21.960 align:start position:0% representation of State the only 00:08:21.960 --> 00:08:23.589 align:start position:0% representation of State the only requirement<00:08:22.440> being<00:08:22.879> that<00:08:23.039> it<00:08:23.159> has<00:08:23.319> to<00:08:23.479> be 00:08:23.589 --> 00:08:23.599 align:start position:0% requirement being that it has to be 00:08:23.599 --> 00:08:25.469 align:start position:0% requirement being that it has to be verifiably<00:08:24.120> linkable<00:08:24.479> to<00:08:24.639> its<00:08:24.759> state<00:08:24.960> route 00:08:25.469 --> 00:08:25.479 align:start position:0% verifiably linkable to its state route 00:08:25.479 --> 00:08:28.029 align:start position:0% verifiably linkable to its state route at<00:08:25.599> least<00:08:25.800> for<00:08:25.960> the<00:08:26.080> way<00:08:26.319> that<00:08:26.639> um<00:08:26.759> RP<00:08:27.159> 7755<00:08:27.960> is 00:08:28.029 --> 00:08:28.039 align:start position:0% at least for the way that um RP 7755 is 00:08:28.039 --> 00:08:29.990 align:start position:0% at least for the way that um RP 7755 is working<00:08:28.440> thus<00:08:28.639> far 00:08:29.990 --> 00:08:30.000 align:start position:0% working thus far 00:08:30.000 --> 00:08:32.110 align:start position:0% working thus far and<00:08:30.120> then<00:08:30.400> in<00:08:30.520> the<00:08:30.639> other<00:08:30.879> direction<00:08:31.520> we<00:08:31.680> need 00:08:32.110 --> 00:08:32.120 align:start position:0% and then in the other direction we need 00:08:32.120 --> 00:08:34.230 align:start position:0% and then in the other direction we need trustless<00:08:32.680> access<00:08:33.039> to<00:08:33.320> a<00:08:33.479> layer<00:08:33.719> one<00:08:33.959> state 00:08:34.230 --> 00:08:34.240 align:start position:0% trustless access to a layer one state 00:08:34.240 --> 00:08:36.990 align:start position:0% trustless access to a layer one state representation<00:08:35.080> within<00:08:35.479> the<00:08:35.640> L2<00:08:36.399> chains<00:08:36.839> as 00:08:36.990 --> 00:08:37.000 align:start position:0% representation within the L2 chains as 00:08:37.000 --> 00:08:39.110 align:start position:0% representation within the L2 chains as well<00:08:37.519> so<00:08:37.680> that's<00:08:37.800> what<00:08:37.919> these<00:08:38.080> upward<00:08:38.440> arrows 00:08:39.110 --> 00:08:39.120 align:start position:0% well so that's what these upward arrows 00:08:39.120 --> 00:08:40.589 align:start position:0% well so that's what these upward arrows pointing<00:08:39.399> to<00:08:39.599> the<00:08:39.719> beacon<00:08:39.959> Roots<00:08:40.240> Oracle 00:08:40.589 --> 00:08:40.599 align:start position:0% pointing to the beacon Roots Oracle 00:08:40.599 --> 00:08:43.709 align:start position:0% pointing to the beacon Roots Oracle contracts<00:08:41.159> are<00:08:42.159> um<00:08:42.680> this<00:08:42.800> is<00:08:42.959> made<00:08:43.200> possible 00:08:43.709 --> 00:08:43.719 align:start position:0% contracts are um this is made possible 00:08:43.719 --> 00:08:45.230 align:start position:0% contracts are um this is made possible by<00:08:43.919> an<00:08:44.080> improvement<00:08:44.480> proposal<00:08:44.839> that's<00:08:45.080> live 00:08:45.230 --> 00:08:45.240 align:start position:0% by an improvement proposal that's live 00:08:45.240 --> 00:08:48.269 align:start position:0% by an improvement proposal that's live today<00:08:45.519> in<00:08:45.600> many<00:08:45.800> networks<00:08:46.240> called<00:08:46.440> EIP<00:08:47.279> 4788 00:08:48.269 --> 00:08:48.279 align:start position:0% today in many networks called EIP 4788 00:08:48.279 --> 00:08:50.910 align:start position:0% today in many networks called EIP 4788 which<00:08:48.440> trustless<00:08:49.000> exposes<00:08:49.680> the<00:08:49.800> most<00:08:50.160> recent 00:08:50.910 --> 00:08:50.920 align:start position:0% which trustless exposes the most recent 00:08:50.920 --> 00:08:54.590 align:start position:0% which trustless exposes the most recent uh<00:08:51.440> 8,191<00:08:52.440> Beacon<00:08:52.760> routes<00:08:53.600> for<00:08:54.200> um<00:08:54.480> the 00:08:54.590 --> 00:08:54.600 align:start position:0% uh 8,191 Beacon routes for um the 00:08:54.600 --> 00:08:56.470 align:start position:0% uh 8,191 Beacon routes for um the ethereum<00:08:55.000> consensus<00:08:55.440> client<00:08:55.760> within<00:08:55.959> the<00:08:56.040> L2 00:08:56.470 --> 00:08:56.480 align:start position:0% ethereum consensus client within the L2 00:08:56.480 --> 00:08:58.990 align:start position:0% ethereum consensus client within the L2 execution<00:08:57.200> environment<00:08:58.200> it<00:08:58.320> should<00:08:58.480> be<00:08:58.640> noted 00:08:58.990 --> 00:08:59.000 align:start position:0% execution environment it should be noted 00:08:59.000 --> 00:09:01.670 align:start position:0% execution environment it should be noted a<00:08:59.160> beacon<00:08:59.560> route<00:08:59.920> is<00:09:00.160> not<00:09:00.399> the<00:09:00.560> same<00:09:01.040> as<00:09:01.480> uh 00:09:01.670 --> 00:09:01.680 align:start position:0% a beacon route is not the same as uh 00:09:01.680 --> 00:09:03.550 align:start position:0% a beacon route is not the same as uh execution<00:09:02.120> client<00:09:02.399> state<00:09:02.600> route<00:09:03.040> but<00:09:03.160> it<00:09:03.320> is 00:09:03.550 --> 00:09:03.560 align:start position:0% execution client state route but it is 00:09:03.560 --> 00:09:05.750 align:start position:0% execution client state route but it is verifiably<00:09:04.079> linkable<00:09:04.519> to<00:09:04.720> the<00:09:04.800> L1<00:09:05.320> execution 00:09:05.750 --> 00:09:05.760 align:start position:0% verifiably linkable to the L1 execution 00:09:05.760 --> 00:09:07.670 align:start position:0% verifiably linkable to the L1 execution client<00:09:06.040> State<00:09:06.240> Route<00:09:06.720> via<00:09:07.000> very<00:09:07.160> similar 00:09:07.670 --> 00:09:07.680 align:start position:0% client State Route via very similar 00:09:07.680 --> 00:09:10.230 align:start position:0% client State Route via very similar process<00:09:08.560> so<00:09:09.120> from<00:09:09.320> chain<00:09:09.600> a<00:09:09.880> if<00:09:10.000> we<00:09:10.079> were 00:09:10.230 --> 00:09:10.240 align:start position:0% process so from chain a if we were 00:09:10.240 --> 00:09:11.350 align:start position:0% process so from chain a if we were trying<00:09:10.440> to<00:09:10.560> prove<00:09:10.800> something<00:09:11.079> about<00:09:11.240> the 00:09:11.350 --> 00:09:11.360 align:start position:0% trying to prove something about the 00:09:11.360 --> 00:09:14.670 align:start position:0% trying to prove something about the state<00:09:11.560> of<00:09:11.680> chain<00:09:12.040> B<00:09:13.040> um<00:09:13.720> this<00:09:13.920> diagram 00:09:14.670 --> 00:09:14.680 align:start position:0% state of chain B um this diagram 00:09:14.680 --> 00:09:16.190 align:start position:0% state of chain B um this diagram represents<00:09:15.399> everything<00:09:15.640> that<00:09:15.720> needs<00:09:15.920> to<00:09:16.040> be 00:09:16.190 --> 00:09:16.200 align:start position:0% represents everything that needs to be 00:09:16.200 --> 00:09:18.470 align:start position:0% represents everything that needs to be true<00:09:16.440> for<00:09:16.640> that<00:09:16.760> to<00:09:16.920> work<00:09:17.680> so<00:09:17.920> if<00:09:18.079> chain<00:09:18.320> a 00:09:18.470 --> 00:09:18.480 align:start position:0% true for that to work so if chain a 00:09:18.480 --> 00:09:21.790 align:start position:0% true for that to work so if chain a starts<00:09:18.880> with<00:09:19.200> a<00:09:19.760> uh<00:09:20.320> trustless<00:09:20.920> access<00:09:21.240> to<00:09:21.640> a 00:09:21.790 --> 00:09:21.800 align:start position:0% starts with a uh trustless access to a 00:09:21.800 --> 00:09:24.990 align:start position:0% starts with a uh trustless access to a beacon<00:09:22.440> route<00:09:23.079> it<00:09:23.200> can<00:09:23.399> supply<00:09:24.240> uh<00:09:24.800> like<00:09:24.920> a 00:09:24.990 --> 00:09:25.000 align:start position:0% beacon route it can supply uh like a 00:09:25.000 --> 00:09:28.269 align:start position:0% beacon route it can supply uh like a Merle<00:09:25.360> Patricia<00:09:25.760> try<00:09:26.320> based<00:09:26.800> proof<00:09:27.800> um<00:09:28.040> to 00:09:28.269 --> 00:09:28.279 align:start position:0% Merle Patricia try based proof um to 00:09:28.279 --> 00:09:30.110 align:start position:0% Merle Patricia try based proof um to verify<00:09:28.760> the<00:09:28.880> L1<00:09:29.360> execution<00:09:29.640> client<00:09:29.880> State 00:09:30.110 --> 00:09:30.120 align:start position:0% verify the L1 execution client State 00:09:30.120 --> 00:09:32.310 align:start position:0% verify the L1 execution client State Route<00:09:30.720> and<00:09:30.800> then<00:09:30.920> if<00:09:31.040> we<00:09:31.160> have<00:09:31.279> a<00:09:31.399> verified<00:09:31.839> L1 00:09:32.310 --> 00:09:32.320 align:start position:0% Route and then if we have a verified L1 00:09:32.320 --> 00:09:34.230 align:start position:0% Route and then if we have a verified L1 execution<00:09:32.760> client<00:09:33.040> State<00:09:33.279> Route<00:09:33.680> that's<00:09:34.079> that 00:09:34.230 --> 00:09:34.240 align:start position:0% execution client State Route that's that 00:09:34.240 --> 00:09:36.790 align:start position:0% execution client State Route that's that exact<00:09:34.839> storage<00:09:35.240> rout<00:09:35.760> or<00:09:35.920> storage<00:09:36.320> proof 00:09:36.790 --> 00:09:36.800 align:start position:0% exact storage rout or storage proof 00:09:36.800 --> 00:09:39.230 align:start position:0% exact storage rout or storage proof process<00:09:37.120> that<00:09:37.200> I<00:09:37.360> just<00:09:37.480> went<00:09:37.680> through<00:09:38.240> applies 00:09:39.230 --> 00:09:39.240 align:start position:0% process that I just went through applies 00:09:39.240 --> 00:09:41.430 align:start position:0% process that I just went through applies um<00:09:39.640> so<00:09:39.839> we<00:09:39.959> could<00:09:40.120> then<00:09:40.399> prove<00:09:40.839> anything<00:09:41.200> about 00:09:41.430 --> 00:09:41.440 align:start position:0% um so we could then prove anything about 00:09:41.440 --> 00:09:43.750 align:start position:0% um so we could then prove anything about the<00:09:41.560> state<00:09:41.760> of<00:09:41.920> layer<00:09:42.200> one<00:09:42.560> from<00:09:42.959> chain 00:09:43.750 --> 00:09:43.760 align:start position:0% the state of layer one from chain 00:09:43.760 --> 00:09:46.870 align:start position:0% the state of layer one from chain a<00:09:44.760> in<00:09:44.920> this<00:09:45.160> context<00:09:46.160> the<00:09:46.279> first<00:09:46.519> step<00:09:46.720> would 00:09:46.870 --> 00:09:46.880 align:start position:0% a in this context the first step would 00:09:46.880 --> 00:09:49.269 align:start position:0% a in this context the first step would be<00:09:47.040> to<00:09:47.200> go<00:09:47.360> from<00:09:47.519> the<00:09:47.600> state<00:09:47.839> route<00:09:48.120> to<00:09:48.880> um<00:09:49.160> like 00:09:49.269 --> 00:09:49.279 align:start position:0% be to go from the state route to um like 00:09:49.279 --> 00:09:50.910 align:start position:0% be to go from the state route to um like a<00:09:49.480> path<00:09:49.680> to<00:09:49.880> an<00:09:50.040> account<00:09:50.360> within<00:09:50.560> that<00:09:50.680> state 00:09:50.910 --> 00:09:50.920 align:start position:0% a path to an account within that state 00:09:50.920 --> 00:09:53.030 align:start position:0% a path to an account within that state try<00:09:51.760> and<00:09:51.880> the<00:09:52.040> account<00:09:52.360> here<00:09:52.560> would<00:09:52.680> be<00:09:52.800> chain 00:09:53.030 --> 00:09:53.040 align:start position:0% try and the account here would be chain 00:09:53.040 --> 00:09:55.990 align:start position:0% try and the account here would be chain B<00:09:53.240> rollup<00:09:53.880> contract<00:09:54.880> and<00:09:55.040> then<00:09:55.320> using<00:09:55.560> chain<00:09:55.800> B 00:09:55.990 --> 00:09:56.000 align:start position:0% B rollup contract and then using chain B 00:09:56.000 --> 00:09:57.710 align:start position:0% B rollup contract and then using chain B rollup<00:09:56.320> contract<00:09:56.720> storage<00:09:57.040> route<00:09:57.480> we<00:09:57.560> can 00:09:57.710 --> 00:09:57.720 align:start position:0% rollup contract storage route we can 00:09:57.720 --> 00:09:59.030 align:start position:0% rollup contract storage route we can supply<00:09:58.079> another<00:09:58.360> path<00:09:58.560> to<00:09:58.680> a<00:09:58.760> specific 00:09:59.030 --> 00:09:59.040 align:start position:0% supply another path to a specific 00:09:59.040 --> 00:09:59.870 align:start position:0% supply another path to a specific location 00:09:59.870 --> 00:09:59.880 align:start position:0% location 00:09:59.880 --> 00:10:02.590 align:start position:0% location in<00:10:00.440> um<00:10:00.880> in<00:10:01.040> that<00:10:01.360> contract<00:10:02.360> what's 00:10:02.590 --> 00:10:02.600 align:start position:0% in um in that contract what's 00:10:02.600 --> 00:10:05.069 align:start position:0% in um in that contract what's interesting<00:10:03.120> here<00:10:03.680> is<00:10:04.200> if<00:10:04.440> the<00:10:04.600> value<00:10:04.959> that 00:10:05.069 --> 00:10:05.079 align:start position:0% interesting here is if the value that 00:10:05.079 --> 00:10:06.829 align:start position:0% interesting here is if the value that you're<00:10:05.279> verifying<00:10:06.000> inside<00:10:06.320> of<00:10:06.440> chain<00:10:06.680> B 00:10:06.829 --> 00:10:06.839 align:start position:0% you're verifying inside of chain B 00:10:06.839 --> 00:10:08.910 align:start position:0% you're verifying inside of chain B rollup<00:10:07.120> contract<00:10:08.040> is<00:10:08.240> itself<00:10:08.560> a<00:10:08.680> state 00:10:08.910 --> 00:10:08.920 align:start position:0% rollup contract is itself a state 00:10:08.920 --> 00:10:11.670 align:start position:0% rollup contract is itself a state representation<00:10:09.760> for<00:10:10.079> chain<00:10:10.320> B<00:10:11.000> you<00:10:11.120> can<00:10:11.240> then 00:10:11.670 --> 00:10:11.680 align:start position:0% representation for chain B you can then 00:10:11.680 --> 00:10:13.790 align:start position:0% representation for chain B you can then recursively<00:10:12.680> follow<00:10:12.959> the<00:10:13.040> same<00:10:13.200> steps<00:10:13.560> again 00:10:13.790 --> 00:10:13.800 align:start position:0% recursively follow the same steps again 00:10:13.800 --> 00:10:15.790 align:start position:0% recursively follow the same steps again to<00:10:13.959> prove<00:10:14.240> something<00:10:14.560> about<00:10:14.800> chain<00:10:15.040> B's<00:10:15.560> State 00:10:15.790 --> 00:10:15.800 align:start position:0% to prove something about chain B's State 00:10:15.800 --> 00:10:18.350 align:start position:0% to prove something about chain B's State try<00:10:16.440> so<00:10:16.600> then<00:10:16.760> starting<00:10:17.040> from<00:10:17.160> chain<00:10:17.399> B's<00:10:18.240> um 00:10:18.350 --> 00:10:18.360 align:start position:0% try so then starting from chain B's um 00:10:18.360 --> 00:10:20.030 align:start position:0% try so then starting from chain B's um State<00:10:18.600> Route<00:10:18.839> you<00:10:18.920> can<00:10:19.040> supply<00:10:19.360> a<00:10:19.480> path<00:10:19.720> to<00:10:19.839> a 00:10:20.030 --> 00:10:20.040 align:start position:0% State Route you can supply a path to a 00:10:20.040 --> 00:10:22.110 align:start position:0% State Route you can supply a path to a specific<00:10:20.800> account<00:10:21.040> within<00:10:21.240> chain<00:10:21.480> B<00:10:21.760> and<00:10:21.880> then 00:10:22.110 --> 00:10:22.120 align:start position:0% specific account within chain B and then 00:10:22.120 --> 00:10:24.069 align:start position:0% specific account within chain B and then again<00:10:22.320> a<00:10:22.519> path<00:10:22.880> to<00:10:23.160> from<00:10:23.480> that<00:10:23.760> from<00:10:23.920> that 00:10:24.069 --> 00:10:24.079 align:start position:0% again a path to from that from that 00:10:24.079 --> 00:10:25.750 align:start position:0% again a path to from that from that account<00:10:24.360> storage<00:10:24.680> route<00:10:25.160> to<00:10:25.320> a<00:10:25.480> specific 00:10:25.750 --> 00:10:25.760 align:start position:0% account storage route to a specific 00:10:25.760 --> 00:10:28.069 align:start position:0% account storage route to a specific storage<00:10:26.279> location<00:10:27.279> and<00:10:27.519> that<00:10:27.680> effectively 00:10:28.069 --> 00:10:28.079 align:start position:0% storage location and that effectively 00:10:28.079 --> 00:10:31.269 align:start position:0% storage location and that effectively allows<00:10:28.399> us<00:10:28.560> to<00:10:28.800> prove<00:10:29.640> uh<00:10:30.160> verifiably<00:10:31.000> a 00:10:31.269 --> 00:10:31.279 align:start position:0% allows us to prove uh verifiably a 00:10:31.279 --> 00:10:33.430 align:start position:0% allows us to prove uh verifiably a location<00:10:32.000> in<00:10:32.279> storage<00:10:32.760> in<00:10:32.880> an<00:10:33.040> account<00:10:33.279> on 00:10:33.430 --> 00:10:33.440 align:start position:0% location in storage in an account on 00:10:33.440 --> 00:10:35.350 align:start position:0% location in storage in an account on chain<00:10:33.680> B<00:10:34.160> from<00:10:34.320> chain<00:10:34.600> a<00:10:34.880> even<00:10:35.079> though<00:10:35.200> there's 00:10:35.350 --> 00:10:35.360 align:start position:0% chain B from chain a even though there's 00:10:35.360 --> 00:10:38.870 align:start position:0% chain B from chain a even though there's no<00:10:35.519> direct<00:10:35.760> line<00:10:35.920> of 00:10:38.870 --> 00:10:38.880 align:start position:0% 00:10:38.880 --> 00:10:41.030 align:start position:0% communication<00:10:39.880> so<00:10:40.040> that's<00:10:40.279> cool<00:10:40.680> but<00:10:40.880> how 00:10:41.030 --> 00:10:41.040 align:start position:0% communication so that's cool but how 00:10:41.040 --> 00:10:43.230 align:start position:0% communication so that's cool but how does<00:10:41.240> that<00:10:41.440> help<00:10:41.639> us<00:10:41.760> with<00:10:41.920> cross<00:10:42.160> chain<00:10:42.360> calls 00:10:43.230 --> 00:10:43.240 align:start position:0% does that help us with cross chain calls 00:10:43.240 --> 00:10:46.190 align:start position:0% does that help us with cross chain calls um<00:10:44.000> this<00:10:44.200> diagram<00:10:44.920> is<00:10:45.600> an<00:10:45.800> overall 00:10:46.190 --> 00:10:46.200 align:start position:0% um this diagram is an overall 00:10:46.200 --> 00:10:49.030 align:start position:0% um this diagram is an overall architecture<00:10:46.760> for<00:10:46.959> how<00:10:47.240> rip<00:10:47.680> 7755<00:10:48.639> is<00:10:48.760> set<00:10:48.920> up 00:10:49.030 --> 00:10:49.040 align:start position:0% architecture for how rip 7755 is set up 00:10:49.040 --> 00:10:52.069 align:start position:0% architecture for how rip 7755 is set up to<00:10:49.200> work<00:10:50.200> um<00:10:50.519> and<00:10:51.000> that<00:10:51.160> should<00:10:51.440> help<00:10:51.800> answer 00:10:52.069 --> 00:10:52.079 align:start position:0% to work um and that should help answer 00:10:52.079 --> 00:10:54.629 align:start position:0% to work um and that should help answer this<00:10:52.279> question<00:10:52.959> here<00:10:53.480> so<00:10:53.760> as<00:10:53.839> you<00:10:53.959> can<00:10:54.120> see<00:10:54.440> we 00:10:54.629 --> 00:10:54.639 align:start position:0% this question here so as you can see we 00:10:54.639 --> 00:10:56.829 align:start position:0% this question here so as you can see we have<00:10:54.880> two<00:10:55.279> chains<00:10:55.680> represented<00:10:56.200> in<00:10:56.320> origin<00:10:56.720> in 00:10:56.829 --> 00:10:56.839 align:start position:0% have two chains represented in origin in 00:10:56.839 --> 00:10:58.790 align:start position:0% have two chains represented in origin in a<00:10:57.079> destination<00:10:58.079> and<00:10:58.160> then<00:10:58.320> we<00:10:58.440> have<00:10:58.600> both 00:10:58.790 --> 00:10:58.800 align:start position:0% a destination and then we have both 00:10:58.800 --> 00:11:02.550 align:start position:0% a destination and then we have both onchain<00:10:59.519> and<00:10:59.639> offchain<00:11:00.399> components<00:11:01.000> here<00:11:02.000> um 00:11:02.550 --> 00:11:02.560 align:start position:0% onchain and offchain components here um 00:11:02.560 --> 00:11:04.389 align:start position:0% onchain and offchain components here um every<00:11:02.880> supported<00:11:03.320> chain<00:11:03.720> is<00:11:03.839> going<00:11:03.920> to<00:11:04.160> have 00:11:04.389 --> 00:11:04.399 align:start position:0% every supported chain is going to have 00:11:04.399 --> 00:11:06.829 align:start position:0% every supported chain is going to have some<00:11:04.600> sort<00:11:04.760> of<00:11:05.000> inbox<00:11:05.360> and<00:11:05.480> outbox<00:11:05.959> contract 00:11:06.829 --> 00:11:06.839 align:start position:0% some sort of inbox and outbox contract 00:11:06.839 --> 00:11:09.269 align:start position:0% some sort of inbox and outbox contract that<00:11:06.959> we're<00:11:07.120> calling<00:11:07.480> RP<00:11:07.880> 7755<00:11:08.839> inbox<00:11:09.160> and 00:11:09.269 --> 00:11:09.279 align:start position:0% that we're calling RP 7755 inbox and 00:11:09.279 --> 00:11:10.629 align:start position:0% that we're calling RP 7755 inbox and outbox<00:11:09.720> but<00:11:09.800> I'll<00:11:09.920> just<00:11:10.000> stick<00:11:10.200> with<00:11:10.320> inbox 00:11:10.629 --> 00:11:10.639 align:start position:0% outbox but I'll just stick with inbox 00:11:10.639 --> 00:11:13.150 align:start position:0% outbox but I'll just stick with inbox and<00:11:10.720> outbox<00:11:11.200> for<00:11:11.639> for<00:11:11.800> the<00:11:11.880> rest<00:11:12.040> of<00:11:12.120> the<00:11:12.240> talk 00:11:13.150 --> 00:11:13.160 align:start position:0% and outbox for for the rest of the talk 00:11:13.160 --> 00:11:15.750 align:start position:0% and outbox for for the rest of the talk um<00:11:13.680> the<00:11:13.800> outbox<00:11:14.279> contract<00:11:14.880> is<00:11:15.279> basically<00:11:15.639> the 00:11:15.750 --> 00:11:15.760 align:start position:0% um the outbox contract is basically the 00:11:15.760 --> 00:11:18.069 align:start position:0% um the outbox contract is basically the entry<00:11:16.120> point<00:11:16.440> into<00:11:16.800> the<00:11:16.959> standard<00:11:17.720> so<00:11:17.880> if<00:11:17.959> a 00:11:18.069 --> 00:11:18.079 align:start position:0% entry point into the standard so if a 00:11:18.079 --> 00:11:20.110 align:start position:0% entry point into the standard so if a user<00:11:18.360> wants<00:11:18.560> to<00:11:18.760> request<00:11:19.120> a<00:11:19.279> cross-chain<00:11:19.760> call 00:11:20.110 --> 00:11:20.120 align:start position:0% user wants to request a cross-chain call 00:11:20.120 --> 00:11:21.590 align:start position:0% user wants to request a cross-chain call they<00:11:20.240> submit<00:11:20.519> a<00:11:20.600> request<00:11:20.880> to<00:11:20.959> the<00:11:21.040> outbox 00:11:21.590 --> 00:11:21.600 align:start position:0% they submit a request to the outbox 00:11:21.600 --> 00:11:24.509 align:start position:0% they submit a request to the outbox contract<00:11:22.600> if<00:11:22.760> the<00:11:22.920> request<00:11:23.360> settles<00:11:23.800> properly 00:11:24.509 --> 00:11:24.519 align:start position:0% contract if the request settles properly 00:11:24.519 --> 00:11:26.590 align:start position:0% contract if the request settles properly um<00:11:24.639> it'll<00:11:24.880> Emmit<00:11:25.079> an<00:11:25.320> event<00:11:26.160> that<00:11:26.360> some 00:11:26.590 --> 00:11:26.600 align:start position:0% um it'll Emmit an event that some 00:11:26.600 --> 00:11:28.069 align:start position:0% um it'll Emmit an event that some offchain<00:11:27.120> actor<00:11:27.519> that<00:11:27.639> we're<00:11:27.800> calling 00:11:28.069 --> 00:11:28.079 align:start position:0% offchain actor that we're calling 00:11:28.079 --> 00:11:30.629 align:start position:0% offchain actor that we're calling fulfillers<00:11:28.880> should<00:11:29.079> be<00:11:29.360> listening<00:11:29.639> for<00:11:30.519> and 00:11:30.629 --> 00:11:30.639 align:start position:0% fulfillers should be listening for and 00:11:30.639 --> 00:11:32.470 align:start position:0% fulfillers should be listening for and if<00:11:30.760> there's<00:11:31.000> sufficient<00:11:31.399> incentive<00:11:32.200> to 00:11:32.470 --> 00:11:32.480 align:start position:0% if there's sufficient incentive to 00:11:32.480 --> 00:11:33.670 align:start position:0% if there's sufficient incentive to respond<00:11:32.760> to<00:11:32.920> that<00:11:33.040> request<00:11:33.480> then<00:11:33.600> the 00:11:33.670 --> 00:11:33.680 align:start position:0% respond to that request then the 00:11:33.680 --> 00:11:37.230 align:start position:0% respond to that request then the fulfiller<00:11:34.360> will<00:11:35.360> so<00:11:35.680> that<00:11:35.800> brings<00:11:36.040> us<00:11:36.279> back<00:11:36.480> to 00:11:37.230 --> 00:11:37.240 align:start position:0% fulfiller will so that brings us back to 00:11:37.240 --> 00:11:39.750 align:start position:0% fulfiller will so that brings us back to um<00:11:37.560> a<00:11:37.720> way<00:11:37.880> to<00:11:38.040> incentivize<00:11:38.639> fulfillers<00:11:39.240> to 00:11:39.750 --> 00:11:39.760 align:start position:0% um a way to incentivize fulfillers to 00:11:39.760 --> 00:11:42.629 align:start position:0% um a way to incentivize fulfillers to respond<00:11:40.079> to<00:11:40.200> the<00:11:40.360> request<00:11:41.360> another<00:11:41.880> key<00:11:42.120> piece 00:11:42.629 --> 00:11:42.639 align:start position:0% respond to the request another key piece 00:11:42.639 --> 00:11:44.949 align:start position:0% respond to the request another key piece of<00:11:43.279> uh<00:11:43.560> logic<00:11:43.880> that<00:11:44.000> happens<00:11:44.399> here<00:11:44.680> is<00:11:44.880> the 00:11:44.949 --> 00:11:44.959 align:start position:0% of uh logic that happens here is the 00:11:44.959 --> 00:11:46.829 align:start position:0% of uh logic that happens here is the user<00:11:45.279> will<00:11:45.440> also<00:11:45.680> lock<00:11:46.000> some<00:11:46.160> kind<00:11:46.279> of<00:11:46.480> reward 00:11:46.829 --> 00:11:46.839 align:start position:0% user will also lock some kind of reward 00:11:46.839 --> 00:11:49.670 align:start position:0% user will also lock some kind of reward Bounty<00:11:47.839> um<00:11:48.040> for<00:11:48.240> the<00:11:48.360> fulfiller<00:11:48.959> to<00:11:49.360> respond 00:11:49.670 --> 00:11:49.680 align:start position:0% Bounty um for the fulfiller to respond 00:11:49.680 --> 00:11:51.790 align:start position:0% Bounty um for the fulfiller to respond to<00:11:49.800> the<00:11:49.920> request<00:11:50.720> if<00:11:50.839> the<00:11:51.000> reward<00:11:51.279> Bounty<00:11:51.639> is 00:11:51.790 --> 00:11:51.800 align:start position:0% to the request if the reward Bounty is 00:11:51.800 --> 00:11:53.670 align:start position:0% to the request if the reward Bounty is sufficiently<00:11:52.760> like<00:11:52.920> incentivizes<00:11:53.600> the 00:11:53.670 --> 00:11:53.680 align:start position:0% sufficiently like incentivizes the 00:11:53.680 --> 00:11:55.310 align:start position:0% sufficiently like incentivizes the fulfiller<00:11:54.279> then<00:11:54.480> it'll 00:11:55.310 --> 00:11:55.320 align:start position:0% fulfiller then it'll 00:11:55.320 --> 00:11:58.470 align:start position:0% fulfiller then it'll respond<00:11:56.320> so<00:11:56.480> the<00:11:56.600> fulfiller<00:11:57.120> then<00:11:57.920> assuming 00:11:58.470 --> 00:11:58.480 align:start position:0% respond so the fulfiller then assuming 00:11:58.480 --> 00:12:00.470 align:start position:0% respond so the fulfiller then assuming it's<00:11:58.639> a<00:11:58.839> sufficient<00:11:59.320> incentive<00:11:59.800> will<00:12:00.120> submit 00:12:00.470 --> 00:12:00.480 align:start position:0% it's a sufficient incentive will submit 00:12:00.480 --> 00:12:02.110 align:start position:0% it's a sufficient incentive will submit the<00:12:00.639> requested<00:12:01.079> call<00:12:01.360> to<00:12:01.480> the<00:12:01.639> destination 00:12:02.110 --> 00:12:02.120 align:start position:0% the requested call to the destination 00:12:02.120 --> 00:12:03.629 align:start position:0% the requested call to the destination chain<00:12:02.560> over 00:12:03.629 --> 00:12:03.639 align:start position:0% chain over 00:12:03.639 --> 00:12:06.990 align:start position:0% chain over here<00:12:04.639> um<00:12:04.800> that<00:12:04.959> routes<00:12:05.360> through<00:12:05.720> an<00:12:05.839> RP<00:12:06.240> 7755 00:12:06.990 --> 00:12:07.000 align:start position:0% here um that routes through an RP 7755 00:12:07.000 --> 00:12:08.990 align:start position:0% here um that routes through an RP 7755 inbox<00:12:07.399> contract<00:12:08.360> which<00:12:08.480> will<00:12:08.639> perform<00:12:08.920> a 00:12:08.990 --> 00:12:09.000 align:start position:0% inbox contract which will perform a 00:12:09.000 --> 00:12:10.990 align:start position:0% inbox contract which will perform a handful<00:12:09.320> of<00:12:09.440> validation<00:12:09.920> steps<00:12:10.519> mainly 00:12:10.990 --> 00:12:11.000 align:start position:0% handful of validation steps mainly 00:12:11.000 --> 00:12:12.750 align:start position:0% handful of validation steps mainly confirming<00:12:11.560> that<00:12:11.720> the<00:12:11.880> request<00:12:12.200> is<00:12:12.360> arriving 00:12:12.750 --> 00:12:12.760 align:start position:0% confirming that the request is arriving 00:12:12.760 --> 00:12:15.310 align:start position:0% confirming that the request is arriving to<00:12:12.920> the<00:12:13.040> correct<00:12:13.360> chain<00:12:14.279> and<00:12:14.800> uh<00:12:14.920> the<00:12:15.000> correct 00:12:15.310 --> 00:12:15.320 align:start position:0% to the correct chain and uh the correct 00:12:15.320 --> 00:12:18.829 align:start position:0% to the correct chain and uh the correct location<00:12:15.760> at<00:12:15.880> the<00:12:15.959> correct<00:12:16.240> chain<00:12:16.680> at<00:12:17.000> that<00:12:18.000> um 00:12:18.829 --> 00:12:18.839 align:start position:0% location at the correct chain at that um 00:12:18.839 --> 00:12:22.310 align:start position:0% location at the correct chain at that um there's<00:12:19.320> also<00:12:20.160> this<00:12:21.160> custom<00:12:21.720> like<00:12:21.920> optional 00:12:22.310 --> 00:12:22.320 align:start position:0% there's also this custom like optional 00:12:22.320 --> 00:12:24.230 align:start position:0% there's also this custom like optional validation<00:12:22.800> step<00:12:23.320> called<00:12:23.680> a<00:12:23.800> pre-check 00:12:24.230 --> 00:12:24.240 align:start position:0% validation step called a pre-check 00:12:24.240 --> 00:12:26.629 align:start position:0% validation step called a pre-check contract<00:12:25.160> where<00:12:25.760> this<00:12:25.880> could<00:12:26.040> be<00:12:26.199> absolutely 00:12:26.629 --> 00:12:26.639 align:start position:0% contract where this could be absolutely 00:12:26.639 --> 00:12:28.269 align:start position:0% contract where this could be absolutely anything<00:12:27.120> as<00:12:27.240> long<00:12:27.360> as<00:12:27.480> it<00:12:27.639> aderes<00:12:28.000> to<00:12:28.160> a 00:12:28.269 --> 00:12:28.279 align:start position:0% anything as long as it aderes to a 00:12:28.279 --> 00:12:29.750 align:start position:0% anything as long as it aderes to a specific<00:12:28.600> pre-check<00:12:28.920> contract<00:12:29.399> interface 00:12:29.750 --> 00:12:29.760 align:start position:0% specific pre-check contract interface 00:12:29.760 --> 00:12:32.350 align:start position:0% specific pre-check contract interface that<00:12:29.839> the<00:12:29.959> standard<00:12:30.519> requires<00:12:31.519> um<00:12:32.079> and<00:12:32.199> all 00:12:32.350 --> 00:12:32.360 align:start position:0% that the standard requires um and all 00:12:32.360 --> 00:12:34.389 align:start position:0% that the standard requires um and all this<00:12:32.480> is<00:12:32.600> meant<00:12:32.760> to<00:12:32.920> do<00:12:33.240> is<00:12:33.519> allow<00:12:33.839> the<00:12:33.920> user<00:12:34.199> to 00:12:34.389 --> 00:12:34.399 align:start position:0% this is meant to do is allow the user to 00:12:34.399 --> 00:12:36.949 align:start position:0% this is meant to do is allow the user to encode<00:12:34.959> any<00:12:35.160> kind<00:12:35.320> of<00:12:35.480> arbitrary<00:12:36.360> fulfillment 00:12:36.949 --> 00:12:36.959 align:start position:0% encode any kind of arbitrary fulfillment 00:12:36.959 --> 00:12:38.750 align:start position:0% encode any kind of arbitrary fulfillment condition<00:12:37.800> um<00:12:37.959> that<00:12:38.079> should<00:12:38.240> be<00:12:38.399> true<00:12:38.680> in 00:12:38.750 --> 00:12:38.760 align:start position:0% condition um that should be true in 00:12:38.760 --> 00:12:41.269 align:start position:0% condition um that should be true in order<00:12:38.959> for<00:12:39.120> the<00:12:39.240> Fulfillment<00:12:39.760> to<00:12:40.160> to<00:12:40.320> work<00:12:40.519> out 00:12:41.269 --> 00:12:41.279 align:start position:0% order for the Fulfillment to to work out 00:12:41.279 --> 00:12:42.990 align:start position:0% order for the Fulfillment to to work out but<00:12:41.560> like<00:12:41.680> I<00:12:41.800> said<00:12:42.120> it<00:12:42.320> again<00:12:42.480> it's<00:12:42.639> totally 00:12:42.990 --> 00:12:43.000 align:start position:0% but like I said it again it's totally 00:12:43.000 --> 00:12:44.790 align:start position:0% but like I said it again it's totally optional<00:12:43.440> so<00:12:43.720> if<00:12:43.839> it's<00:12:44.199> if<00:12:44.279> it's<00:12:44.440> not<00:12:44.600> being 00:12:44.790 --> 00:12:44.800 align:start position:0% optional so if it's if it's not being 00:12:44.800 --> 00:12:47.069 align:start position:0% optional so if it's if it's not being used<00:12:45.240> this<00:12:45.360> step<00:12:45.560> will<00:12:45.680> be<00:12:45.760> skipped<00:12:46.720> if<00:12:46.880> all 00:12:47.069 --> 00:12:47.079 align:start position:0% used this step will be skipped if all 00:12:47.079 --> 00:12:52.430 align:start position:0% used this step will be skipped if all the<00:12:47.240> validation<00:12:47.880> steps<00:12:48.880> um<00:12:49.800> are<00:12:50.720> like 00:12:52.430 --> 00:12:52.440 align:start position:0% the validation steps um are like 00:12:52.440 --> 00:12:55.509 align:start position:0% the validation steps um are like sufficiently<00:12:53.440> check<00:12:53.680> out<00:12:54.040> properly<00:12:55.000> um<00:12:55.240> then 00:12:55.509 --> 00:12:55.519 align:start position:0% sufficiently check out properly um then 00:12:55.519 --> 00:12:57.670 align:start position:0% sufficiently check out properly um then the<00:12:55.720> requested<00:12:56.160> calls<00:12:56.600> will<00:12:56.800> be<00:12:57.040> routed<00:12:57.440> from 00:12:57.670 --> 00:12:57.680 align:start position:0% the requested calls will be routed from 00:12:57.680 --> 00:13:00.230 align:start position:0% the requested calls will be routed from there<00:12:58.440> um<00:12:58.639> so<00:12:58.959> this<00:12:59.240> could<00:12:59.399> be<00:12:59.519> a<00:12:59.639> batch<00:12:59.839> of<00:13:00.000> any 00:13:00.230 --> 00:13:00.240 align:start position:0% there um so this could be a batch of any 00:13:00.240 --> 00:13:02.629 align:start position:0% there um so this could be a batch of any low-level<00:13:00.760> arbitrary<00:13:01.199> call<00:13:01.800> that<00:13:02.000> goes<00:13:02.199> to<00:13:02.519> a 00:13:02.629 --> 00:13:02.639 align:start position:0% low-level arbitrary call that goes to a 00:13:02.639 --> 00:13:04.189 align:start position:0% low-level arbitrary call that goes to a handful<00:13:02.920> of<00:13:03.040> addresses<00:13:03.440> within<00:13:03.720> coded<00:13:03.959> call 00:13:04.189 --> 00:13:04.199 align:start position:0% handful of addresses within coded call 00:13:04.199 --> 00:13:07.389 align:start position:0% handful of addresses within coded call data<00:13:04.680> um<00:13:04.839> and<00:13:05.160> any<00:13:06.160> native<00:13:06.480> currency<00:13:06.880> value 00:13:07.389 --> 00:13:07.399 align:start position:0% data um and any native currency value 00:13:07.399 --> 00:13:08.750 align:start position:0% data um and any native currency value that<00:13:07.639> may<00:13:07.800> be 00:13:08.750 --> 00:13:08.760 align:start position:0% that may be 00:13:08.760 --> 00:13:10.670 align:start position:0% that may be included<00:13:09.760> if<00:13:09.880> all<00:13:10.000> of<00:13:10.160> those<00:13:10.279> are 00:13:10.670 --> 00:13:10.680 align:start position:0% included if all of those are 00:13:10.680 --> 00:13:13.750 align:start position:0% included if all of those are successfully<00:13:11.680> um<00:13:12.079> are<00:13:12.360> successful<00:13:13.360> the<00:13:13.480> main 00:13:13.750 --> 00:13:13.760 align:start position:0% successfully um are successful the main 00:13:13.760 --> 00:13:15.670 align:start position:0% successfully um are successful the main purpose<00:13:14.240> of<00:13:14.399> this<00:13:14.519> inbox<00:13:14.959> contract<00:13:15.399> is<00:13:15.480> to 00:13:15.670 --> 00:13:15.680 align:start position:0% purpose of this inbox contract is to 00:13:15.680 --> 00:13:18.590 align:start position:0% purpose of this inbox contract is to then<00:13:15.880> store<00:13:16.440> a<00:13:16.880> receipt<00:13:17.240> of<00:13:17.440> successful 00:13:18.590 --> 00:13:18.600 align:start position:0% then store a receipt of successful 00:13:18.600 --> 00:13:21.150 align:start position:0% then store a receipt of successful execution<00:13:19.600> um<00:13:19.800> and<00:13:20.040> this<00:13:20.240> execution<00:13:20.760> receipt 00:13:21.150 --> 00:13:21.160 align:start position:0% execution um and this execution receipt 00:13:21.160 --> 00:13:23.269 align:start position:0% execution um and this execution receipt gets<00:13:21.360> stored<00:13:21.720> in<00:13:21.880> a<00:13:22.000> deterministic<00:13:22.760> location 00:13:23.269 --> 00:13:23.279 align:start position:0% gets stored in a deterministic location 00:13:23.279 --> 00:13:25.230 align:start position:0% gets stored in a deterministic location within<00:13:23.519> this<00:13:23.680> contract<00:13:24.040> storage<00:13:24.959> that<00:13:25.079> is 00:13:25.230 --> 00:13:25.240 align:start position:0% within this contract storage that is 00:13:25.240 --> 00:13:27.189 align:start position:0% within this contract storage that is derivable<00:13:25.839> from<00:13:26.000> the<00:13:26.160> origin<00:13:26.519> chain<00:13:27.000> without 00:13:27.189 --> 00:13:27.199 align:start position:0% derivable from the origin chain without 00:13:27.199 --> 00:13:28.389 align:start position:0% derivable from the origin chain without knowing<00:13:27.519> anything<00:13:27.760> about<00:13:27.880> the<00:13:27.959> state<00:13:28.160> of<00:13:28.279> the 00:13:28.389 --> 00:13:28.399 align:start position:0% knowing anything about the state of the 00:13:28.399 --> 00:13:29.910 align:start position:0% knowing anything about the state of the destination<00:13:28.800> chain 00:13:29.910 --> 00:13:29.920 align:start position:0% destination chain 00:13:29.920 --> 00:13:31.189 align:start position:0% destination chain um<00:13:30.040> so<00:13:30.199> that's<00:13:30.399> important<00:13:30.800> and<00:13:30.920> we'll<00:13:31.079> come 00:13:31.189 --> 00:13:31.199 align:start position:0% um so that's important and we'll come 00:13:31.199 --> 00:13:33.550 align:start position:0% um so that's important and we'll come back<00:13:31.320> to<00:13:31.440> it<00:13:31.519> in<00:13:31.600> a<00:13:31.720> second<00:13:32.720> after<00:13:33.079> the<00:13:33.199> call 00:13:33.550 --> 00:13:33.560 align:start position:0% back to it in a second after the call 00:13:33.560 --> 00:13:35.350 align:start position:0% back to it in a second after the call has<00:13:33.680> been<00:13:33.839> successfully<00:13:34.440> submitted<00:13:35.240> the 00:13:35.350 --> 00:13:35.360 align:start position:0% has been successfully submitted the 00:13:35.360 --> 00:13:36.829 align:start position:0% has been successfully submitted the fulfiller<00:13:35.839> then<00:13:36.000> comes<00:13:36.240> back<00:13:36.320> to<00:13:36.440> the<00:13:36.560> origin 00:13:36.829 --> 00:13:36.839 align:start position:0% fulfiller then comes back to the origin 00:13:36.839 --> 00:13:39.990 align:start position:0% fulfiller then comes back to the origin chain<00:13:37.480> to<00:13:37.800> say<00:13:38.160> hey<00:13:38.440> I<00:13:38.839> I<00:13:39.000> I<00:13:39.079> did<00:13:39.240> the<00:13:39.399> job<00:13:39.800> now 00:13:39.990 --> 00:13:40.000 align:start position:0% chain to say hey I I I did the job now 00:13:40.000 --> 00:13:42.350 align:start position:0% chain to say hey I I I did the job now can<00:13:40.120> I<00:13:40.279> have<00:13:40.519> my<00:13:40.760> my<00:13:40.920> payment<00:13:41.920> and<00:13:42.120> what's 00:13:42.350 --> 00:13:42.360 align:start position:0% can I have my my payment and what's 00:13:42.360 --> 00:13:44.509 align:start position:0% can I have my my payment and what's unique<00:13:42.720> about<00:13:43.079> this<00:13:43.360> standard<00:13:43.959> is<00:13:44.160> that<00:13:44.360> the 00:13:44.509 --> 00:13:44.519 align:start position:0% unique about this standard is that the 00:13:44.519 --> 00:13:46.550 align:start position:0% unique about this standard is that the payment<00:13:45.240> will<00:13:45.399> only<00:13:45.600> be<00:13:45.760> released<00:13:46.279> if<00:13:46.440> the 00:13:46.550 --> 00:13:46.560 align:start position:0% payment will only be released if the 00:13:46.560 --> 00:13:48.189 align:start position:0% payment will only be released if the fulfiller<00:13:47.000> can<00:13:47.160> cryptographically<00:13:47.880> prove 00:13:48.189 --> 00:13:48.199 align:start position:0% fulfiller can cryptographically prove 00:13:48.199 --> 00:13:49.389 align:start position:0% fulfiller can cryptographically prove that<00:13:48.320> they<00:13:48.480> did<00:13:48.720> actually<00:13:48.959> submit<00:13:49.279> the 00:13:49.389 --> 00:13:49.399 align:start position:0% that they did actually submit the 00:13:49.399 --> 00:13:51.310 align:start position:0% that they did actually submit the request<00:13:49.639> to<00:13:49.800> the<00:13:49.920> destination<00:13:50.399> chain<00:13:51.199> and 00:13:51.310 --> 00:13:51.320 align:start position:0% request to the destination chain and 00:13:51.320 --> 00:13:52.790 align:start position:0% request to the destination chain and that's<00:13:51.519> done<00:13:51.800> via<00:13:52.000> that<00:13:52.120> nested<00:13:52.480> storage 00:13:52.790 --> 00:13:52.800 align:start position:0% that's done via that nested storage 00:13:52.800 --> 00:13:54.030 align:start position:0% that's done via that nested storage proof<00:13:53.079> concept<00:13:53.399> that<00:13:53.480> we<00:13:53.600> just<00:13:53.759> walked 00:13:54.030 --> 00:13:54.040 align:start position:0% proof concept that we just walked 00:13:54.040 --> 00:13:57.350 align:start position:0% proof concept that we just walked through<00:13:54.959> um<00:13:55.160> so<00:13:55.320> from<00:13:55.480> the<00:13:55.600> origin<00:13:55.959> chain<00:13:56.880> the 00:13:57.350 --> 00:13:57.360 align:start position:0% through um so from the origin chain the 00:13:57.360 --> 00:13:58.629 align:start position:0% through um so from the origin chain the uh<00:13:57.440> origin<00:13:57.759> chain<00:13:57.959> would<00:13:58.079> have<00:13:58.160> to<00:13:58.279> be<00:13:58.360> able<00:13:58.519> to 00:13:58.629 --> 00:13:58.639 align:start position:0% uh origin chain would have to be able to 00:13:58.639 --> 00:13:59.710 align:start position:0% uh origin chain would have to be able to verify 00:13:59.710 --> 00:13:59.720 align:start position:0% verify 00:13:59.720 --> 00:14:01.749 align:start position:0% verify a<00:13:59.920> specific<00:14:00.320> storage<00:14:00.680> location<00:14:01.199> in<00:14:01.360> the<00:14:01.639> uh 00:14:01.749 --> 00:14:01.759 align:start position:0% a specific storage location in the uh 00:14:01.759 --> 00:14:04.470 align:start position:0% a specific storage location in the uh inbox<00:14:02.240> contract<00:14:02.560> on<00:14:02.759> destination<00:14:03.279> chain<00:14:04.240> and 00:14:04.470 --> 00:14:04.480 align:start position:0% inbox contract on destination chain and 00:14:04.480 --> 00:14:05.910 align:start position:0% inbox contract on destination chain and because<00:14:04.680> of<00:14:04.800> the<00:14:04.959> fact<00:14:05.240> that<00:14:05.360> the<00:14:05.440> outbox 00:14:05.910 --> 00:14:05.920 align:start position:0% because of the fact that the outbox 00:14:05.920 --> 00:14:07.870 align:start position:0% because of the fact that the outbox contract<00:14:06.320> can<00:14:06.519> derive<00:14:07.079> exactly<00:14:07.440> where<00:14:07.600> that 00:14:07.870 --> 00:14:07.880 align:start position:0% contract can derive exactly where that 00:14:07.880 --> 00:14:10.470 align:start position:0% contract can derive exactly where that location<00:14:08.279> is<00:14:08.440> supposed<00:14:08.720> to<00:14:08.839> be<00:14:09.680> then<00:14:10.199> um<00:14:10.360> the 00:14:10.470 --> 00:14:10.480 align:start position:0% location is supposed to be then um the 00:14:10.480 --> 00:14:12.829 align:start position:0% location is supposed to be then um the outbox<00:14:11.240> contract<00:14:11.800> has<00:14:12.040> everything<00:14:12.480> it<00:14:12.600> needs 00:14:12.829 --> 00:14:12.839 align:start position:0% outbox contract has everything it needs 00:14:12.839 --> 00:14:14.629 align:start position:0% outbox contract has everything it needs to<00:14:12.959> be<00:14:13.040> able<00:14:13.240> to<00:14:13.360> verify<00:14:13.839> the<00:14:13.959> successful 00:14:14.629 --> 00:14:14.639 align:start position:0% to be able to verify the successful 00:14:14.639 --> 00:14:17.310 align:start position:0% to be able to verify the successful fulfillment<00:14:15.160> of<00:14:15.279> the<00:14:15.360> call<00:14:16.320> so<00:14:16.680> only<00:14:17.000> if<00:14:17.160> this 00:14:17.310 --> 00:14:17.320 align:start position:0% fulfillment of the call so only if this 00:14:17.320 --> 00:14:21.069 align:start position:0% fulfillment of the call so only if this nested<00:14:17.639> storage<00:14:18.040> proof<00:14:18.959> um<00:14:19.519> checks<00:14:19.880> out<00:14:20.600> will 00:14:21.069 --> 00:14:21.079 align:start position:0% nested storage proof um checks out will 00:14:21.079 --> 00:14:22.870 align:start position:0% nested storage proof um checks out will the<00:14:21.279> outbox<00:14:21.839> contract<00:14:22.199> release<00:14:22.480> the<00:14:22.600> reward 00:14:22.870 --> 00:14:22.880 align:start position:0% the outbox contract release the reward 00:14:22.880 --> 00:14:25.150 align:start position:0% the outbox contract release the reward to<00:14:23.000> the<00:14:23.360> fulfiller<00:14:24.360> and<00:14:24.639> that<00:14:24.720> would<00:14:24.880> close 00:14:25.150 --> 00:14:25.160 align:start position:0% to the fulfiller and that would close 00:14:25.160 --> 00:14:28.470 align:start position:0% to the fulfiller and that would close the<00:14:25.240> loop<00:14:25.519> on<00:14:25.639> the<00:14:25.759> full<00:14:26.079> process<00:14:26.480> for<00:14:27.040> how<00:14:28.040> RP 00:14:28.470 --> 00:14:28.480 align:start position:0% the loop on the full process for how RP 00:14:28.480 --> 00:14:30.310 align:start position:0% the loop on the full process for how RP 775<00:14:29.279> is 00:14:30.310 --> 00:14:30.320 align:start position:0% 775 is 00:14:30.320 --> 00:14:31.829 align:start position:0% 775 is working 00:14:31.829 --> 00:14:31.839 align:start position:0% working 00:14:31.839 --> 00:14:34.949 align:start position:0% working um<00:14:32.839> yeah<00:14:33.120> so<00:14:33.440> for<00:14:33.759> today's 00:14:34.949 --> 00:14:34.959 align:start position:0% um yeah so for today's 00:14:34.959 --> 00:14:38.870 align:start position:0% um yeah so for today's Workshop<00:14:35.959> I<00:14:36.279> have<00:14:36.839> a<00:14:37.639> um<00:14:37.959> example<00:14:38.440> project<00:14:38.720> for 00:14:38.870 --> 00:14:38.880 align:start position:0% Workshop I have a um example project for 00:14:38.880 --> 00:14:41.430 align:start position:0% Workshop I have a um example project for us<00:14:39.040> to<00:14:39.160> go<00:14:39.320> through<00:14:39.639> together<00:14:40.440> so<00:14:40.800> if<00:14:41.000> anyone's 00:14:41.430 --> 00:14:41.440 align:start position:0% us to go through together so if anyone's 00:14:41.440 --> 00:14:44.189 align:start position:0% us to go through together so if anyone's interested<00:14:41.800> in<00:14:42.320> uh<00:14:42.440> coding<00:14:42.759> along<00:14:43.720> there<00:14:43.920> is<00:14:44.040> a 00:14:44.189 --> 00:14:44.199 align:start position:0% interested in uh coding along there is a 00:14:44.199 --> 00:14:46.910 align:start position:0% interested in uh coding along there is a starter<00:14:44.720> repository<00:14:45.560> on<00:14:45.800> my<00:14:46.079> GitHub<00:14:46.680> that<00:14:46.839> I 00:14:46.910 --> 00:14:46.920 align:start position:0% starter repository on my GitHub that I 00:14:46.920 --> 00:14:50.189 align:start position:0% starter repository on my GitHub that I can<00:14:47.440> show<00:14:47.759> in<00:14:47.880> a<00:14:48.199> second<00:14:49.199> um<00:14:49.839> if<00:14:49.920> you're<00:14:50.040> not 00:14:50.189 --> 00:14:50.199 align:start position:0% can show in a second um if you're not 00:14:50.199 --> 00:14:51.629 align:start position:0% can show in a second um if you're not interested<00:14:50.480> in<00:14:50.560> following<00:14:50.880> along<00:14:51.240> I'll<00:14:51.440> just 00:14:51.629 --> 00:14:51.639 align:start position:0% interested in following along I'll just 00:14:51.639 --> 00:14:54.269 align:start position:0% interested in following along I'll just I'll<00:14:51.759> be<00:14:51.880> doing<00:14:52.040> it<00:14:52.160> up<00:14:52.320> here<00:14:52.440> as<00:14:52.560> well<00:14:52.759> so<00:14:53.639> um 00:14:54.269 --> 00:14:54.279 align:start position:0% I'll be doing it up here as well so um 00:14:54.279 --> 00:14:56.150 align:start position:0% I'll be doing it up here as well so um we<00:14:54.399> can<00:14:54.519> go<00:14:54.680> from<00:14:54.880> there<00:14:55.639> so<00:14:55.880> I'm<00:14:55.959> going<00:14:56.040> to 00:14:56.150 --> 00:14:56.160 align:start position:0% we can go from there so I'm going to 00:14:56.160 --> 00:14:57.430 align:start position:0% we can go from there so I'm going to start<00:14:56.360> by<00:14:56.519> walking<00:14:56.839> through<00:14:57.120> all<00:14:57.199> of<00:14:57.320> the 00:14:57.430 --> 00:14:57.440 align:start position:0% start by walking through all of the 00:14:57.440 --> 00:14:59.310 align:start position:0% start by walking through all of the contracts<00:14:57.839> and<00:14:57.959> services<00:14:58.480> that<00:14:58.600> are<00:14:59.040> present 00:14:59.310 --> 00:14:59.320 align:start position:0% contracts and services that are present 00:14:59.320 --> 00:15:01.269 align:start position:0% contracts and services that are present in<00:14:59.440> the<00:14:59.519> starter<00:14:59.959> project<00:15:00.800> uh<00:15:00.959> this<00:15:01.040> is<00:15:01.199> going 00:15:01.269 --> 00:15:01.279 align:start position:0% in the starter project uh this is going 00:15:01.279 --> 00:15:03.990 align:start position:0% in the starter project uh this is going to<00:15:01.440> be<00:15:02.120> a<00:15:02.279> self-contained<00:15:03.000> system<00:15:03.519> that<00:15:03.759> is 00:15:03.990 --> 00:15:04.000 align:start position:0% to be a self-contained system that is 00:15:04.000 --> 00:15:07.269 align:start position:0% to be a self-contained system that is mocking<00:15:04.519> a<00:15:04.680> multi-<00:15:05.079> rollup<00:15:06.000> uh<00:15:06.399> ecosystem 00:15:07.269 --> 00:15:07.279 align:start position:0% mocking a multi- rollup uh ecosystem 00:15:07.279 --> 00:15:08.590 align:start position:0% mocking a multi- rollup uh ecosystem that<00:15:07.360> will<00:15:07.519> run<00:15:07.720> locally<00:15:08.040> on<00:15:08.160> your<00:15:08.360> on<00:15:08.440> your 00:15:08.590 --> 00:15:08.600 align:start position:0% that will run locally on your on your 00:15:08.600 --> 00:15:10.430 align:start position:0% that will run locally on your on your machine<00:15:09.320> so<00:15:09.519> once<00:15:09.680> you<00:15:09.839> once<00:15:09.959> you<00:15:10.079> clone<00:15:10.360> the 00:15:10.430 --> 00:15:10.440 align:start position:0% machine so once you once you clone the 00:15:10.440 --> 00:15:11.790 align:start position:0% machine so once you once you clone the repository<00:15:10.959> you<00:15:11.040> should<00:15:11.240> have<00:15:11.440> everything 00:15:11.790 --> 00:15:11.800 align:start position:0% repository you should have everything 00:15:11.800 --> 00:15:14.430 align:start position:0% repository you should have everything needed<00:15:12.120> to<00:15:12.240> run<00:15:12.440> the<00:15:12.560> entire<00:15:12.880> app<00:15:13.079> end<00:15:13.240> to<00:15:13.360> end 00:15:14.430 --> 00:15:14.440 align:start position:0% needed to run the entire app end to end 00:15:14.440 --> 00:15:17.710 align:start position:0% needed to run the entire app end to end locally<00:15:15.440> so<00:15:15.880> after<00:15:16.279> a<00:15:16.480> brief<00:15:16.720> walkr<00:15:17.320> of<00:15:17.519> all 00:15:17.710 --> 00:15:17.720 align:start position:0% locally so after a brief walkr of all 00:15:17.720 --> 00:15:18.829 align:start position:0% locally so after a brief walkr of all the<00:15:17.800> services<00:15:18.160> and<00:15:18.279> how<00:15:18.399> they're<00:15:18.519> working 00:15:18.829 --> 00:15:18.839 align:start position:0% the services and how they're working 00:15:18.839 --> 00:15:20.389 align:start position:0% the services and how they're working together<00:15:19.040> to<00:15:19.160> make<00:15:19.320> that<00:15:19.480> work<00:15:20.079> we'll 00:15:20.389 --> 00:15:20.399 align:start position:0% together to make that work we'll 00:15:20.399 --> 00:15:21.990 align:start position:0% together to make that work we'll Implement<00:15:20.759> and<00:15:20.880> test<00:15:21.160> a<00:15:21.320> nested<00:15:21.639> storage 00:15:21.990 --> 00:15:22.000 align:start position:0% Implement and test a nested storage 00:15:22.000 --> 00:15:24.790 align:start position:0% Implement and test a nested storage proof<00:15:22.279> validation<00:15:23.120> contract<00:15:24.120> as<00:15:24.480> that<00:15:24.639> is 00:15:24.790 --> 00:15:24.800 align:start position:0% proof validation contract as that is 00:15:24.800 --> 00:15:26.550 align:start position:0% proof validation contract as that is where<00:15:25.000> the<00:15:25.160> bulk<00:15:25.519> of<00:15:25.720> the<00:15:25.880> effort<00:15:26.199> is<00:15:26.360> going<00:15:26.440> to 00:15:26.550 --> 00:15:26.560 align:start position:0% where the bulk of the effort is going to 00:15:26.560 --> 00:15:28.949 align:start position:0% where the bulk of the effort is going to have<00:15:26.680> to<00:15:26.800> be<00:15:26.959> applied<00:15:27.759> to<00:15:28.079> add<00:15:28.399> new<00:15:28.560> chains 00:15:28.949 --> 00:15:28.959 align:start position:0% have to be applied to add new chains 00:15:28.959 --> 00:15:30.870 align:start position:0% have to be applied to add new chains support<00:15:29.160> in<00:15:29.240> the<00:15:29.360> future<00:15:30.319> I<00:15:30.440> also<00:15:30.639> just<00:15:30.720> think 00:15:30.870 --> 00:15:30.880 align:start position:0% support in the future I also just think 00:15:30.880 --> 00:15:34.069 align:start position:0% support in the future I also just think it's<00:15:31.040> really<00:15:31.600> cool<00:15:32.600> um<00:15:33.279> and<00:15:33.440> then<00:15:33.680> once<00:15:33.959> that 00:15:34.069 --> 00:15:34.079 align:start position:0% it's really cool um and then once that 00:15:34.079 --> 00:15:35.350 align:start position:0% it's really cool um and then once that is<00:15:34.199> working<00:15:34.480> properly<00:15:34.759> we'll<00:15:34.920> integrate<00:15:35.240> with 00:15:35.350 --> 00:15:35.360 align:start position:0% is working properly we'll integrate with 00:15:35.360 --> 00:15:37.430 align:start position:0% is working properly we'll integrate with an<00:15:35.440> offchain<00:15:35.800> client<00:15:36.079> application<00:15:36.959> so<00:15:37.199> for 00:15:37.430 --> 00:15:37.440 align:start position:0% an offchain client application so for 00:15:37.440 --> 00:15:39.870 align:start position:0% an offchain client application so for this<00:15:38.000> demo<00:15:38.360> it's<00:15:38.519> just<00:15:38.639> a<00:15:38.800> simple<00:15:39.120> nft<00:15:39.519> mint 00:15:39.870 --> 00:15:39.880 align:start position:0% this demo it's just a simple nft mint 00:15:39.880 --> 00:15:42.069 align:start position:0% this demo it's just a simple nft mint application<00:15:40.600> where<00:15:41.079> the<00:15:41.199> nft<00:15:41.519> owner<00:15:41.800> wants<00:15:41.959> to 00:15:42.069 --> 00:15:42.079 align:start position:0% application where the nft owner wants to 00:15:42.079 --> 00:15:44.949 align:start position:0% application where the nft owner wants to be<00:15:42.160> able<00:15:42.319> to<00:15:42.480> support<00:15:43.319> users<00:15:44.120> who<00:15:44.560> uh<00:15:44.680> don't 00:15:44.949 --> 00:15:44.959 align:start position:0% be able to support users who uh don't 00:15:44.959 --> 00:15:46.230 align:start position:0% be able to support users who uh don't necessarily<00:15:45.360> have<00:15:45.480> funds<00:15:45.720> on<00:15:45.839> the<00:15:45.920> chain<00:15:46.120> that 00:15:46.230 --> 00:15:46.240 align:start position:0% necessarily have funds on the chain that 00:15:46.240 --> 00:15:48.110 align:start position:0% necessarily have funds on the chain that the<00:15:46.319> nft<00:15:46.680> contract<00:15:47.000> lives<00:15:47.199> on<00:15:47.680> so<00:15:47.880> if<00:15:48.000> they 00:15:48.110 --> 00:15:48.120 align:start position:0% the nft contract lives on so if they 00:15:48.120 --> 00:15:51.470 align:start position:0% the nft contract lives on so if they don't<00:15:48.319> it<00:15:48.399> would<00:15:48.519> be<00:15:48.639> an<00:15:48.800> R<00:15:49.519> rip<00:15:49.920> 7755<00:15:50.759> request 00:15:51.470 --> 00:15:51.480 align:start position:0% don't it would be an R rip 7755 request 00:15:51.480 --> 00:15:52.829 align:start position:0% don't it would be an R rip 7755 request to<00:15:51.639> send<00:15:51.800> the<00:15:51.920> cross<00:15:52.120> chain<00:15:52.319> call<00:15:52.480> to<00:15:52.639> still 00:15:52.829 --> 00:15:52.839 align:start position:0% to send the cross chain call to still 00:15:52.839 --> 00:15:53.629 align:start position:0% to send the cross chain call to still Min<00:15:53.040> the 00:15:53.629 --> 00:15:53.639 align:start position:0% Min the 00:15:53.639 --> 00:15:56.949 align:start position:0% Min the nft<00:15:54.639> so<00:15:55.560> once<00:15:55.920> that<00:15:56.040> is<00:15:56.160> all<00:15:56.319> set<00:15:56.519> up<00:15:56.720> we<00:15:56.800> should 00:15:56.949 --> 00:15:56.959 align:start position:0% nft so once that is all set up we should 00:15:56.959 --> 00:16:00.069 align:start position:0% nft so once that is all set up we should be<00:15:57.120> good<00:15:57.279> to<00:15:57.440> run<00:15:57.759> the<00:15:57.920> app<00:15:58.160> end<00:15:58.319> to<00:15:58.440> end 00:16:00.069 --> 00:16:00.079 align:start position:0% be good to run the app end to end 00:16:00.079 --> 00:16:03.430 align:start position:0% be good to run the app end to end before<00:16:00.600> we<00:16:00.800> jump<00:16:01.120> in<00:16:01.560> I'll<00:16:01.720> leave<00:16:01.959> you<00:16:02.720> uh<00:16:03.199> well 00:16:03.430 --> 00:16:03.440 align:start position:0% before we jump in I'll leave you uh well 00:16:03.440 --> 00:16:05.430 align:start position:0% before we jump in I'll leave you uh well I<00:16:03.519> guess<00:16:03.680> I'll<00:16:03.800> leave<00:16:04.079> this<00:16:04.839> presentation 00:16:05.430 --> 00:16:05.440 align:start position:0% I guess I'll leave this presentation 00:16:05.440 --> 00:16:08.030 align:start position:0% I guess I'll leave this presentation piece<00:16:05.959> with<00:16:06.279> that<00:16:06.480> it's<00:16:06.639> still<00:16:07.199> very<00:16:07.360> early<00:16:07.920> in 00:16:08.030 --> 00:16:08.040 align:start position:0% piece with that it's still very early in 00:16:08.040 --> 00:16:10.629 align:start position:0% piece with that it's still very early in the<00:16:08.160> research<00:16:08.600> phase<00:16:09.240> that<00:16:09.600> uh<00:16:10.319> a<00:16:10.399> lot<00:16:10.519> of 00:16:10.629 --> 00:16:10.639 align:start position:0% the research phase that uh a lot of 00:16:10.639 --> 00:16:12.590 align:start position:0% the research phase that uh a lot of these<00:16:10.759> details<00:16:11.079> are<00:16:11.279> subject<00:16:11.560> to<00:16:11.720> change<00:16:12.319> but 00:16:12.590 --> 00:16:12.600 align:start position:0% these details are subject to change but 00:16:12.600 --> 00:16:14.110 align:start position:0% these details are subject to change but we<00:16:12.759> have<00:16:12.920> proven<00:16:13.199> the<00:16:13.319> concept<00:16:13.720> on<00:16:13.920> live 00:16:14.110 --> 00:16:14.120 align:start position:0% we have proven the concept on live 00:16:14.120 --> 00:16:15.910 align:start position:0% we have proven the concept on live networks<00:16:14.600> of<00:16:14.759> this<00:16:14.959> nested<00:16:15.279> storage<00:16:15.600> proof 00:16:15.910 --> 00:16:15.920 align:start position:0% networks of this nested storage proof 00:16:15.920 --> 00:16:18.110 align:start position:0% networks of this nested storage proof and<00:16:16.040> how<00:16:16.240> that<00:16:16.360> can<00:16:16.480> be<00:16:16.639> used<00:16:17.040> to<00:16:17.600> trustless 00:16:18.110 --> 00:16:18.120 align:start position:0% and how that can be used to trustless 00:16:18.120 --> 00:16:20.230 align:start position:0% and how that can be used to trustless verify<00:16:18.440> cross<00:16:18.680> chain<00:16:18.880> calls<00:16:19.680> so<00:16:19.920> this<00:16:20.040> seems 00:16:20.230 --> 00:16:20.240 align:start position:0% verify cross chain calls so this seems 00:16:20.240 --> 00:16:21.870 align:start position:0% verify cross chain calls so this seems to<00:16:20.440> hold<00:16:21.000> a<00:16:21.079> lot<00:16:21.199> of<00:16:21.319> potential<00:16:21.759> it's 00:16:21.870 --> 00:16:21.880 align:start position:0% to hold a lot of potential it's 00:16:21.880 --> 00:16:23.069 align:start position:0% to hold a lot of potential it's something<00:16:22.079> I'm<00:16:22.240> very<00:16:22.399> excited<00:16:22.720> about 00:16:23.069 --> 00:16:23.079 align:start position:0% something I'm very excited about 00:16:23.079 --> 00:16:24.309 align:start position:0% something I'm very excited about something<00:16:23.240> the<00:16:23.360> base<00:16:23.519> team<00:16:23.680> is<00:16:23.800> very<00:16:23.959> excited 00:16:24.309 --> 00:16:24.319 align:start position:0% something the base team is very excited 00:16:24.319 --> 00:16:27.309 align:start position:0% something the base team is very excited about<00:16:25.279> um<00:16:25.440> we<00:16:25.600> do<00:16:25.759> have<00:16:25.920> an<00:16:26.079> open<00:16:26.360> source<00:16:27.079> proof 00:16:27.309 --> 00:16:27.319 align:start position:0% about um we do have an open source proof 00:16:27.319 --> 00:16:29.629 align:start position:0% about um we do have an open source proof of<00:16:27.480> concept<00:16:27.880> repository<00:16:28.600> on<00:16:28.959> the<00:16:29.079> Bas<00:16:29.279> or 00:16:29.629 --> 00:16:29.639 align:start position:0% of concept repository on the Bas or 00:16:29.639 --> 00:16:31.870 align:start position:0% of concept repository on the Bas or GitHub<00:16:30.199> that<00:16:30.360> I<00:16:30.519> fully<00:16:30.880> invite<00:16:31.399> anyone<00:16:31.720> and 00:16:31.870 --> 00:16:31.880 align:start position:0% GitHub that I fully invite anyone and 00:16:31.880 --> 00:16:34.150 align:start position:0% GitHub that I fully invite anyone and everyone<00:16:32.240> to<00:16:32.440> contribute<00:16:32.839> to<00:16:33.079> if<00:16:33.160> you<00:16:33.360> have<00:16:34.040> uh 00:16:34.150 --> 00:16:34.160 align:start position:0% everyone to contribute to if you have uh 00:16:34.160 --> 00:16:37.590 align:start position:0% everyone to contribute to if you have uh interesting<00:16:34.519> ideas<00:16:35.399> so<00:16:36.399> with<00:16:36.639> that<00:16:37.360> uh<00:16:37.480> we 00:16:37.590 --> 00:16:37.600 align:start position:0% interesting ideas so with that uh we 00:16:37.600 --> 00:16:39.949 align:start position:0% interesting ideas so with that uh we should<00:16:37.800> be<00:16:37.920> good<00:16:38.079> to<00:16:38.199> dive<00:16:38.399> into<00:16:38.639> code<00:16:39.240> but<00:16:39.839> as 00:16:39.949 --> 00:16:39.959 align:start position:0% should be good to dive into code but as 00:16:39.959 --> 00:16:42.269 align:start position:0% should be good to dive into code but as a<00:16:40.120> quick<00:16:40.360> gut<00:16:40.600> check<00:16:41.279> uh<00:16:41.399> are<00:16:41.560> there<00:16:41.759> any 00:16:42.269 --> 00:16:42.279 align:start position:0% a quick gut check uh are there any 00:16:42.279 --> 00:16:46.430 align:start position:0% a quick gut check uh are there any questions<00:16:43.040> before<00:16:43.800> doing 00:16:46.430 --> 00:16:46.440 align:start position:0% 00:16:46.440 --> 00:16:48.309 align:start position:0% so<00:16:47.440> and<00:16:47.519> there<00:16:47.600> will<00:16:47.720> be<00:16:47.839> time<00:16:47.959> for<00:16:48.079> questions 00:16:48.309 --> 00:16:48.319 align:start position:0% so and there will be time for questions 00:16:48.319 --> 00:16:53.430 align:start position:0% so and there will be time for questions at<00:16:48.440> the<00:16:48.519> end<00:16:48.720> too<00:16:48.959> and<00:16:49.120> and<00:16:49.279> after<00:16:49.480> this<00:16:49.680> talk 00:16:53.430 --> 00:16:53.440 align:start position:0% 00:16:53.440 --> 00:16:56.949 align:start position:0% so 00:16:56.949 --> 00:16:56.959 align:start position:0% 00:16:56.959 --> 00:16:59.389 align:start position:0% okay<00:16:57.959> so<00:16:58.240> I<00:16:58.319> didn't<00:16:58.600> know<00:16:59.000> the<00:16:59.079> best<00:16:59.199> way<00:16:59.319> to 00:16:59.389 --> 00:16:59.399 align:start position:0% okay so I didn't know the best way to 00:16:59.399 --> 00:17:02.150 align:start position:0% okay so I didn't know the best way to share<00:16:59.600> the<00:16:59.720> link<00:17:00.160> but<00:17:00.720> um<00:17:01.160> my<00:17:01.319> GitHub<00:17:01.759> is<00:17:01.920> is<00:17:02.040> my 00:17:02.150 --> 00:17:02.160 align:start position:0% share the link but um my GitHub is is my 00:17:02.160 --> 00:17:04.590 align:start position:0% share the link but um my GitHub is is my name<00:17:02.440> Jack<00:17:02.680> chuma<00:17:03.120> and<00:17:03.240> I<00:17:03.360> have<00:17:03.480> this<00:17:03.680> Devcon 00:17:04.590 --> 00:17:04.600 align:start position:0% name Jack chuma and I have this Devcon 00:17:04.600 --> 00:17:09.189 align:start position:0% name Jack chuma and I have this Devcon 2024<00:17:05.600> rip<00:17:06.000> 7755<00:17:06.799> Workshop<00:17:07.559> project<00:17:08.559> um<00:17:09.079> if 00:17:09.189 --> 00:17:09.199 align:start position:0% 2024 rip 7755 Workshop project um if 00:17:09.199 --> 00:17:10.549 align:start position:0% 2024 rip 7755 Workshop project um if anyone's<00:17:09.520> interested<00:17:09.799> in<00:17:09.880> coding<00:17:10.160> along<00:17:10.439> you 00:17:10.549 --> 00:17:10.559 align:start position:0% anyone's interested in coding along you 00:17:10.559 --> 00:17:13.270 align:start position:0% anyone's interested in coding along you can<00:17:10.679> clone<00:17:11.000> this<00:17:11.640> repository<00:17:12.640> and<00:17:13.000> uh<00:17:13.160> and 00:17:13.270 --> 00:17:13.280 align:start position:0% can clone this repository and uh and 00:17:13.280 --> 00:17:21.069 align:start position:0% can clone this repository and uh and follow<00:17:13.559> along<00:17:13.799> with 00:17:21.069 --> 00:17:21.079 align:start position:0% 00:17:21.079 --> 00:17:24.630 align:start position:0% me<00:17:22.079> I<00:17:22.439> already<00:17:22.679> have<00:17:22.799> it<00:17:22.959> cloned<00:17:23.400> so<00:17:23.959> um<00:17:24.400> we<00:17:24.480> can 00:17:24.630 --> 00:17:24.640 align:start position:0% me I already have it cloned so um we can 00:17:24.640 --> 00:17:29.750 align:start position:0% me I already have it cloned so um we can start<00:17:24.839> with<00:17:24.919> a<00:17:25.039> brief<00:17:25.280> walk<00:17:25.559> through<00:17:25.799> here 00:17:29.750 --> 00:17:29.760 align:start position:0% 00:17:29.760 --> 00:17:31.350 align:start position:0% so<00:17:29.919> once<00:17:30.080> you<00:17:30.160> have<00:17:30.320> the<00:17:30.480> project<00:17:31.039> what<00:17:31.160> you'll 00:17:31.350 --> 00:17:31.360 align:start position:0% so once you have the project what you'll 00:17:31.360 --> 00:17:33.310 align:start position:0% so once you have the project what you'll notice<00:17:31.760> is<00:17:31.919> there's<00:17:32.120> two<00:17:32.320> main<00:17:32.559> directories 00:17:33.310 --> 00:17:33.320 align:start position:0% notice is there's two main directories 00:17:33.320 --> 00:17:36.549 align:start position:0% notice is there's two main directories we<00:17:33.559> have<00:17:34.080> contracts<00:17:34.919> and<00:17:35.280> services<00:17:36.280> so<00:17:36.480> this 00:17:36.549 --> 00:17:36.559 align:start position:0% we have contracts and services so this 00:17:36.559 --> 00:17:39.789 align:start position:0% we have contracts and services so this is<00:17:37.080> onchain<00:17:37.520> and<00:17:37.679> offchain<00:17:38.600> um<00:17:39.160> components 00:17:39.789 --> 00:17:39.799 align:start position:0% is onchain and offchain um components 00:17:39.799 --> 00:17:42.029 align:start position:0% is onchain and offchain um components from<00:17:40.000> that<00:17:40.120> architecture<00:17:40.799> diagram<00:17:41.799> we<00:17:41.880> can 00:17:42.029 --> 00:17:42.039 align:start position:0% from that architecture diagram we can 00:17:42.039 --> 00:17:43.430 align:start position:0% from that architecture diagram we can start<00:17:42.240> by<00:17:42.360> going<00:17:42.559> through<00:17:42.720> the 00:17:43.430 --> 00:17:43.440 align:start position:0% start by going through the 00:17:43.440 --> 00:17:46.710 align:start position:0% start by going through the contracts<00:17:44.640> um<00:17:45.640> I'll<00:17:45.840> start<00:17:46.039> with<00:17:46.200> the<00:17:46.280> nft 00:17:46.710 --> 00:17:46.720 align:start position:0% contracts um I'll start with the nft 00:17:46.720 --> 00:17:49.630 align:start position:0% contracts um I'll start with the nft contract<00:17:47.120> because<00:17:47.320> it's<00:17:47.600> very<00:17:48.160> very<00:17:48.640> simple 00:17:49.630 --> 00:17:49.640 align:start position:0% contract because it's very very simple 00:17:49.640 --> 00:17:51.190 align:start position:0% contract because it's very very simple um<00:17:49.799> but<00:17:49.960> this<00:17:50.080> is<00:17:50.200> what<00:17:50.320> our<00:17:50.480> demo<00:17:50.799> client<00:17:51.080> is 00:17:51.190 --> 00:17:51.200 align:start position:0% um but this is what our demo client is 00:17:51.200 --> 00:17:53.590 align:start position:0% um but this is what our demo client is going<00:17:51.360> to<00:17:51.480> be<00:17:51.640> using<00:17:52.360> the<00:17:52.480> main<00:17:53.000> piece<00:17:53.280> here<00:17:53.480> is 00:17:53.590 --> 00:17:53.600 align:start position:0% going to be using the main piece here is 00:17:53.600 --> 00:17:55.270 align:start position:0% going to be using the main piece here is this<00:17:53.760> mint<00:17:54.039> function<00:17:54.720> the<00:17:54.799> only<00:17:54.960> reason<00:17:55.159> I'm 00:17:55.270 --> 00:17:55.280 align:start position:0% this mint function the only reason I'm 00:17:55.280 --> 00:17:56.590 align:start position:0% this mint function the only reason I'm covering<00:17:55.559> it<00:17:55.720> is<00:17:55.919> because<00:17:56.200> this<00:17:56.280> is<00:17:56.400> going<00:17:56.480> to 00:17:56.590 --> 00:17:56.600 align:start position:0% covering it is because this is going to 00:17:56.600 --> 00:17:58.430 align:start position:0% covering it is because this is going to be<00:17:56.720> needed<00:17:57.080> to<00:17:57.559> uh<00:17:57.679> set<00:17:57.840> up<00:17:57.960> the<00:17:58.039> integration 00:17:58.430 --> 00:17:58.440 align:start position:0% be needed to uh set up the integration 00:17:58.440 --> 00:18:00.789 align:start position:0% be needed to uh set up the integration when<00:17:58.559> we<00:17:58.640> get<00:17:59.039> there<00:17:59.480> but<00:17:59.600> there's<00:17:59.880> nothing 00:18:00.789 --> 00:18:00.799 align:start position:0% when we get there but there's nothing 00:18:00.799 --> 00:18:02.590 align:start position:0% when we get there but there's nothing too<00:18:01.240> interesting<00:18:01.679> happening 00:18:02.590 --> 00:18:02.600 align:start position:0% too interesting happening 00:18:02.600 --> 00:18:04.310 align:start position:0% too interesting happening here 00:18:04.310 --> 00:18:04.320 align:start position:0% here 00:18:04.320 --> 00:18:07.909 align:start position:0% here um<00:18:05.320> next<00:18:05.559> up<00:18:05.720> we<00:18:05.960> have<00:18:06.240> a<00:18:06.400> rollups<00:18:06.919> directory 00:18:07.909 --> 00:18:07.919 align:start position:0% um next up we have a rollups directory 00:18:07.919 --> 00:18:10.590 align:start position:0% um next up we have a rollups directory and<00:18:08.320> this<00:18:08.520> is<00:18:08.880> used<00:18:09.400> to<00:18:09.799> mock<00:18:10.120> the<00:18:10.240> multi 00:18:10.590 --> 00:18:10.600 align:start position:0% and this is used to mock the multi 00:18:10.600 --> 00:18:14.029 align:start position:0% and this is used to mock the multi rollup<00:18:10.960> system<00:18:11.640> locally<00:18:12.679> um<00:18:13.679> I<00:18:13.760> didn't<00:18:13.960> want 00:18:14.029 --> 00:18:14.039 align:start position:0% rollup system locally um I didn't want 00:18:14.039 --> 00:18:15.310 align:start position:0% rollup system locally um I didn't want to<00:18:14.159> have<00:18:14.240> to<00:18:14.360> rely<00:18:14.640> on<00:18:14.880> good<00:18:15.000> internet 00:18:15.310 --> 00:18:15.320 align:start position:0% to have to rely on good internet 00:18:15.320 --> 00:18:17.230 align:start position:0% to have to rely on good internet connection<00:18:15.679> for<00:18:15.840> this<00:18:16.039> to<00:18:16.200> work<00:18:16.480> so<00:18:16.960> uh<00:18:17.039> we<00:18:17.159> got 00:18:17.230 --> 00:18:17.240 align:start position:0% connection for this to work so uh we got 00:18:17.240 --> 00:18:19.390 align:start position:0% connection for this to work so uh we got a<00:18:17.360> mock<00:18:17.600> system<00:18:17.840> running<00:18:18.240> locally<00:18:19.240> this 00:18:19.390 --> 00:18:19.400 align:start position:0% a mock system running locally this 00:18:19.400 --> 00:18:20.750 align:start position:0% a mock system running locally this rollup<00:18:19.919> contract<00:18:20.280> is<00:18:20.400> what<00:18:20.520> would<00:18:20.640> be 00:18:20.750 --> 00:18:20.760 align:start position:0% rollup contract is what would be 00:18:20.760 --> 00:18:22.990 align:start position:0% rollup contract is what would be deployed<00:18:21.120> to<00:18:21.240> a<00:18:21.320> Mach<00:18:21.559> L1<00:18:22.320> and<00:18:22.480> this<00:18:22.559> is<00:18:22.880> what 00:18:22.990 --> 00:18:23.000 align:start position:0% deployed to a Mach L1 and this is what 00:18:23.000 --> 00:18:24.950 align:start position:0% deployed to a Mach L1 and this is what will<00:18:23.159> be<00:18:23.280> storing<00:18:23.880> a<00:18:24.039> state<00:18:24.280> representation 00:18:24.950 --> 00:18:24.960 align:start position:0% will be storing a state representation 00:18:24.960 --> 00:18:27.950 align:start position:0% will be storing a state representation for<00:18:25.200> the<00:18:25.320> Mach<00:18:25.799> l2s<00:18:26.799> in<00:18:26.960> this<00:18:27.159> context<00:18:27.799> that 00:18:27.950 --> 00:18:27.960 align:start position:0% for the Mach l2s in this context that 00:18:27.960 --> 00:18:30.190 align:start position:0% for the Mach l2s in this context that state<00:18:28.200> representation<00:18:28.960> is<00:18:29.039> a<00:18:29.240> hash<00:18:29.600> of<00:18:29.720> the<00:18:29.799> L2 00:18:30.190 --> 00:18:30.200 align:start position:0% state representation is a hash of the L2 00:18:30.200 --> 00:18:33.750 align:start position:0% state representation is a hash of the L2 block<00:18:30.440> Tim<00:18:30.679> stamp<00:18:31.080> and<00:18:31.200> the<00:18:31.280> L2<00:18:31.640> State<00:18:32.240> Route 00:18:33.750 --> 00:18:33.760 align:start position:0% block Tim stamp and the L2 State Route 00:18:33.760 --> 00:18:36.270 align:start position:0% block Tim stamp and the L2 State Route um<00:18:34.760> and<00:18:34.880> then<00:18:35.000> on<00:18:35.080> the<00:18:35.200> L2<00:18:35.600> side<00:18:35.760> of<00:18:35.919> things<00:18:36.159> we 00:18:36.270 --> 00:18:36.280 align:start position:0% um and then on the L2 side of things we 00:18:36.280 --> 00:18:38.270 align:start position:0% um and then on the L2 side of things we have<00:18:36.440> this<00:18:36.600> Beacon<00:18:36.880> Oracle<00:18:37.320> contract<00:18:38.200> which 00:18:38.270 --> 00:18:38.280 align:start position:0% have this Beacon Oracle contract which 00:18:38.280 --> 00:18:41.669 align:start position:0% have this Beacon Oracle contract which is<00:18:38.440> meant<00:18:38.600> to<00:18:38.760> mock<00:18:39.159> the<00:18:39.280> EIP<00:18:39.720> 4788<00:18:40.679> interface 00:18:41.669 --> 00:18:41.679 align:start position:0% is meant to mock the EIP 4788 interface 00:18:41.679 --> 00:18:44.470 align:start position:0% is meant to mock the EIP 4788 interface interface<00:18:42.159> to<00:18:42.440> query<00:18:43.240> um<00:18:43.880> one<00:18:44.039> of<00:18:44.120> the<00:18:44.200> beacon 00:18:44.470 --> 00:18:44.480 align:start position:0% interface to query um one of the beacon 00:18:44.480 --> 00:18:46.070 align:start position:0% interface to query um one of the beacon routes<00:18:44.840> that<00:18:44.919> are<00:18:45.039> being<00:18:45.200> stored<00:18:45.480> in<00:18:45.559> the<00:18:45.679> L2 00:18:46.070 --> 00:18:46.080 align:start position:0% routes that are being stored in the L2 00:18:46.080 --> 00:18:48.830 align:start position:0% routes that are being stored in the L2 execution<00:18:46.679> environment<00:18:47.679> for<00:18:48.240> this<00:18:48.440> example 00:18:48.830 --> 00:18:48.840 align:start position:0% execution environment for this example 00:18:48.840 --> 00:18:50.390 align:start position:0% execution environment for this example it's<00:18:48.960> a<00:18:49.080> simplified<00:18:49.559> example<00:18:50.000> and<00:18:50.159> this<00:18:50.240> is 00:18:50.390 --> 00:18:50.400 align:start position:0% it's a simplified example and this is 00:18:50.400 --> 00:18:52.590 align:start position:0% it's a simplified example and this is directly<00:18:50.720> storing<00:18:51.200> the<00:18:51.280> L1<00:18:51.840> execution<00:18:52.280> client 00:18:52.590 --> 00:18:52.600 align:start position:0% directly storing the L1 execution client 00:18:52.600 --> 00:18:55.390 align:start position:0% directly storing the L1 execution client State<00:18:52.840> Route<00:18:53.400> so<00:18:54.120> um<00:18:54.320> we<00:18:54.600> we<00:18:54.720> are<00:18:55.000> cutting<00:18:55.280> out 00:18:55.390 --> 00:18:55.400 align:start position:0% State Route so um we we are cutting out 00:18:55.400 --> 00:18:57.909 align:start position:0% State Route so um we we are cutting out a<00:18:55.559> step<00:18:55.880> of<00:18:56.360> ver<00:18:56.760> verification<00:18:57.440> going<00:18:57.720> from 00:18:57.909 --> 00:18:57.919 align:start position:0% a step of ver verification going from 00:18:57.919 --> 00:19:00.909 align:start position:0% a step of ver verification going from Beacon<00:18:58.240> route<00:18:58.440> to<00:18:58.799> state<00:18:58.960> route<00:18:59.360> but<00:19:00.200> um<00:19:00.840> I 00:19:00.909 --> 00:19:00.919 align:start position:0% Beacon route to state route but um I 00:19:00.919 --> 00:19:03.789 align:start position:0% Beacon route to state route but um I think<00:19:01.039> it<00:19:01.200> still<00:19:01.600> gets<00:19:01.760> the<00:19:01.880> message 00:19:03.789 --> 00:19:03.799 align:start position:0% think it still gets the message 00:19:03.799 --> 00:19:06.909 align:start position:0% think it still gets the message across<00:19:04.799> and<00:19:04.919> then<00:19:05.120> we<00:19:05.360> have<00:19:05.600> all<00:19:05.760> of<00:19:05.880> our<00:19:06.120> RP 00:19:06.909 --> 00:19:06.919 align:start position:0% across and then we have all of our RP 00:19:06.919 --> 00:19:10.430 align:start position:0% across and then we have all of our RP 7755<00:19:08.039> contracts<00:19:09.039> so<00:19:09.559> as<00:19:09.679> a<00:19:09.840> brief<00:19:10.120> walk 00:19:10.430 --> 00:19:10.440 align:start position:0% 7755 contracts so as a brief walk 00:19:10.440 --> 00:19:12.430 align:start position:0% 7755 contracts so as a brief walk through<00:19:10.640> for<00:19:10.960> what<00:19:11.120> an<00:19:11.320> actual<00:19:11.760> request<00:19:12.159> looks 00:19:12.430 --> 00:19:12.440 align:start position:0% through for what an actual request looks 00:19:12.440 --> 00:19:16.669 align:start position:0% through for what an actual request looks like<00:19:12.720> we<00:19:12.880> have<00:19:13.120> this<00:19:13.679> RP<00:19:14.120> 7755<00:19:15.039> stru<00:19:15.480> file<00:19:16.480> and 00:19:16.669 --> 00:19:16.679 align:start position:0% like we have this RP 7755 stru file and 00:19:16.679 --> 00:19:19.190 align:start position:0% like we have this RP 7755 stru file and this<00:19:16.799> is<00:19:17.200> exactly<00:19:17.720> what<00:19:18.080> a<00:19:18.360> request<00:19:18.960> would 00:19:19.190 --> 00:19:19.200 align:start position:0% this is exactly what a request would 00:19:19.200 --> 00:19:22.310 align:start position:0% this is exactly what a request would look<00:19:19.400> like<00:19:19.840> so<00:19:20.559> um<00:19:20.720> all<00:19:20.880> the<00:19:21.000> fields<00:19:21.600> are<00:19:22.200> we 00:19:22.310 --> 00:19:22.320 align:start position:0% look like so um all the fields are we 00:19:22.320 --> 00:19:23.909 align:start position:0% look like so um all the fields are we start<00:19:22.480> with<00:19:22.600> a<00:19:22.760> requester<00:19:23.200> so<00:19:23.360> this<00:19:23.440> is<00:19:23.600> the 00:19:23.909 --> 00:19:23.919 align:start position:0% start with a requester so this is the 00:19:23.919 --> 00:19:25.270 align:start position:0% start with a requester so this is the pretty<00:19:24.080> self-explanatory<00:19:24.960> the<00:19:25.039> address 00:19:25.270 --> 00:19:25.280 align:start position:0% pretty self-explanatory the address 00:19:25.280 --> 00:19:27.510 align:start position:0% pretty self-explanatory the address submitting<00:19:25.640> the<00:19:25.799> request<00:19:26.799> we<00:19:26.960> have<00:19:27.120> a<00:19:27.320> batch 00:19:27.510 --> 00:19:27.520 align:start position:0% submitting the request we have a batch 00:19:27.520 --> 00:19:29.630 align:start position:0% submitting the request we have a batch of<00:19:27.799> calls<00:19:28.520> where<00:19:28.720> where<00:19:28.840> each<00:19:29.039> call<00:19:29.400> is<00:19:29.520> a 00:19:29.630 --> 00:19:29.640 align:start position:0% of calls where where each call is a 00:19:29.640 --> 00:19:32.750 align:start position:0% of calls where where each call is a low-level<00:19:30.640> um<00:19:31.080> description<00:19:31.880> of<00:19:32.240> the<00:19:32.400> exact 00:19:32.750 --> 00:19:32.760 align:start position:0% low-level um description of the exact 00:19:32.760 --> 00:19:33.990 align:start position:0% low-level um description of the exact address<00:19:33.039> that<00:19:33.120> you'd<00:19:33.280> like<00:19:33.400> to<00:19:33.480> send<00:19:33.679> the<00:19:33.799> call 00:19:33.990 --> 00:19:34.000 align:start position:0% address that you'd like to send the call 00:19:34.000 --> 00:19:36.870 align:start position:0% address that you'd like to send the call to<00:19:34.679> encoded<00:19:35.200> call<00:19:35.440> data<00:19:35.919> and<00:19:36.080> then<00:19:36.360> any<00:19:36.559> native 00:19:36.870 --> 00:19:36.880 align:start position:0% to encoded call data and then any native 00:19:36.880 --> 00:19:38.510 align:start position:0% to encoded call data and then any native currency<00:19:37.240> value<00:19:37.559> that<00:19:37.679> should<00:19:38.039> be<00:19:38.159> included 00:19:38.510 --> 00:19:38.520 align:start position:0% currency value that should be included 00:19:38.520 --> 00:19:39.870 align:start position:0% currency value that should be included with<00:19:38.679> that 00:19:39.870 --> 00:19:39.880 align:start position:0% with that 00:19:39.880 --> 00:19:42.470 align:start position:0% with that call<00:19:40.880> then<00:19:41.000> we<00:19:41.120> have<00:19:41.200> a<00:19:41.320> specified<00:19:41.760> Prov 00:19:42.470 --> 00:19:42.480 align:start position:0% call then we have a specified Prov 00:19:42.480 --> 00:19:47.190 align:start position:0% call then we have a specified Prov contract<00:19:43.480> um<00:19:43.679> the<00:19:43.840> reason<00:19:44.480> this<00:19:45.400> is<00:19:46.400> here<00:19:46.960> is 00:19:47.190 --> 00:19:47.200 align:start position:0% contract um the reason this is here is 00:19:47.200 --> 00:19:49.909 align:start position:0% contract um the reason this is here is because<00:19:47.559> there's<00:19:47.799> no<00:19:48.120> standard<00:19:48.760> way<00:19:49.000> for<00:19:49.200> L2 00:19:49.909 --> 00:19:49.919 align:start position:0% because there's no standard way for L2 00:19:49.919 --> 00:19:51.590 align:start position:0% because there's no standard way for L2 chains<00:19:50.360> to<00:19:50.559> post<00:19:50.960> their<00:19:51.280> state 00:19:51.590 --> 00:19:51.600 align:start position:0% chains to post their state 00:19:51.600 --> 00:19:55.149 align:start position:0% chains to post their state representation<00:19:52.120> to<00:19:52.559> L1<00:19:53.559> um<00:19:54.159> and<00:19:54.640> because<00:19:54.880> of 00:19:55.149 --> 00:19:55.159 align:start position:0% representation to L1 um and because of 00:19:55.159 --> 00:19:58.190 align:start position:0% representation to L1 um and because of that<00:19:55.720> the<00:19:56.000> exact<00:19:57.000> implementation<00:19:57.640> details 00:19:58.190 --> 00:19:58.200 align:start position:0% that the exact implementation details 00:19:58.200 --> 00:20:00.470 align:start position:0% that the exact implementation details for<00:19:58.720> verifying<00:19:59.320> State<00:19:59.679> about<00:19:59.840> a<00:20:00.000> destination 00:20:00.470 --> 00:20:00.480 align:start position:0% for verifying State about a destination 00:20:00.480 --> 00:20:02.430 align:start position:0% for verifying State about a destination chain<00:20:01.159> will<00:20:01.440> vary<00:20:01.760> depending<00:20:02.039> on<00:20:02.200> what<00:20:02.280> that 00:20:02.430 --> 00:20:02.440 align:start position:0% chain will vary depending on what that 00:20:02.440 --> 00:20:04.430 align:start position:0% chain will vary depending on what that destination<00:20:02.840> chain<00:20:03.200> is<00:20:03.799> so<00:20:04.039> right<00:20:04.200> now<00:20:04.320> we 00:20:04.430 --> 00:20:04.440 align:start position:0% destination chain is so right now we 00:20:04.440 --> 00:20:06.310 align:start position:0% destination chain is so right now we have<00:20:04.559> the<00:20:04.720> setup<00:20:05.039> with<00:20:05.200> the<00:20:05.320> proving<00:20:05.919> logic 00:20:06.310 --> 00:20:06.320 align:start position:0% have the setup with the proving logic 00:20:06.320 --> 00:20:08.470 align:start position:0% have the setup with the proving logic abstracted<00:20:06.919> into<00:20:07.080> two<00:20:07.280> separate<00:20:07.600> contracts 00:20:08.470 --> 00:20:08.480 align:start position:0% abstracted into two separate contracts 00:20:08.480 --> 00:20:10.110 align:start position:0% abstracted into two separate contracts this<00:20:08.679> very<00:20:08.880> likely<00:20:09.240> will<00:20:09.480> change<00:20:09.720> in<00:20:09.840> the<00:20:09.960> near 00:20:10.110 --> 00:20:10.120 align:start position:0% this very likely will change in the near 00:20:10.120 --> 00:20:12.310 align:start position:0% this very likely will change in the near future<00:20:10.640> if<00:20:10.720> we<00:20:10.840> baked<00:20:11.200> that<00:20:11.320> into<00:20:11.559> the<00:20:11.679> outbox 00:20:12.310 --> 00:20:12.320 align:start position:0% future if we baked that into the outbox 00:20:12.320 --> 00:20:14.430 align:start position:0% future if we baked that into the outbox contract<00:20:13.320> um<00:20:13.480> that<00:20:13.600> would<00:20:13.760> require<00:20:14.080> multiple 00:20:14.430 --> 00:20:14.440 align:start position:0% contract um that would require multiple 00:20:14.440 --> 00:20:16.750 align:start position:0% contract um that would require multiple outbox<00:20:14.960> contracts<00:20:15.400> to<00:20:15.520> be<00:20:15.679> deployed<00:20:16.200> to<00:20:16.520> each 00:20:16.750 --> 00:20:16.760 align:start position:0% outbox contracts to be deployed to each 00:20:16.760 --> 00:20:19.750 align:start position:0% outbox contracts to be deployed to each chain<00:20:17.720> um<00:20:17.960> so<00:20:18.440> it's<00:20:18.559> a<00:20:18.679> trade-off<00:20:19.240> but<00:20:19.480> for 00:20:19.750 --> 00:20:19.760 align:start position:0% chain um so it's a trade-off but for 00:20:19.760 --> 00:20:22.029 align:start position:0% chain um so it's a trade-off but for right<00:20:19.919> now<00:20:20.400> this<00:20:20.520> is<00:20:20.640> set<00:20:20.799> up<00:20:20.960> to<00:20:21.039> be<00:20:21.200> one<00:20:21.400> outb 00:20:22.029 --> 00:20:22.039 align:start position:0% right now this is set up to be one outb 00:20:22.039 --> 00:20:24.830 align:start position:0% right now this is set up to be one outb one<00:20:22.200> outbox<00:20:22.720> one<00:20:22.880> inbox<00:20:23.840> and<00:20:23.960> then<00:20:24.440> uh<00:20:24.679> an 00:20:24.830 --> 00:20:24.840 align:start position:0% one outbox one inbox and then uh an 00:20:24.840 --> 00:20:26.310 align:start position:0% one outbox one inbox and then uh an array<00:20:25.080> of<00:20:25.200> pro<00:20:25.360> or<00:20:25.520> contracts<00:20:25.919> deployed<00:20:26.200> to 00:20:26.310 --> 00:20:26.320 align:start position:0% array of pro or contracts deployed to 00:20:26.320 --> 00:20:27.630 align:start position:0% array of pro or contracts deployed to each<00:20:26.440> chain<00:20:26.840> that<00:20:26.960> the<00:20:27.039> user<00:20:27.240> would<00:20:27.400> have<00:20:27.480> to 00:20:27.630 --> 00:20:27.640 align:start position:0% each chain that the user would have to 00:20:27.640 --> 00:20:29.149 align:start position:0% each chain that the user would have to specify<00:20:28.120> which<00:20:28.280> one 00:20:29.149 --> 00:20:29.159 align:start position:0% specify which one 00:20:29.159 --> 00:20:31.870 align:start position:0% specify which one um<00:20:29.320> should<00:20:29.520> be<00:20:29.679> used<00:20:30.000> to<00:20:30.520> verify 00:20:31.870 --> 00:20:31.880 align:start position:0% um should be used to verify 00:20:31.880 --> 00:20:33.750 align:start position:0% um should be used to verify fulfillment<00:20:32.880> and<00:20:33.039> this<00:20:33.200> contract<00:20:33.559> is<00:20:33.640> what 00:20:33.750 --> 00:20:33.760 align:start position:0% fulfillment and this contract is what 00:20:33.760 --> 00:20:35.950 align:start position:0% fulfillment and this contract is what we're<00:20:33.919> going<00:20:34.080> to<00:20:34.200> be<00:20:34.360> implementing<00:20:34.799> in<00:20:34.919> a<00:20:35.000> few 00:20:35.950 --> 00:20:35.960 align:start position:0% we're going to be implementing in a few 00:20:35.960 --> 00:20:37.950 align:start position:0% we're going to be implementing in a few minutes<00:20:36.960> then<00:20:37.080> we<00:20:37.159> have<00:20:37.320> destination<00:20:37.679> chain 00:20:37.950 --> 00:20:37.960 align:start position:0% minutes then we have destination chain 00:20:37.960 --> 00:20:39.669 align:start position:0% minutes then we have destination chain ID<00:20:38.440> which<00:20:38.520> is<00:20:38.679> pretty 00:20:39.669 --> 00:20:39.679 align:start position:0% ID which is pretty 00:20:39.679 --> 00:20:42.070 align:start position:0% ID which is pretty self-explanatory<00:20:40.679> inbox<00:20:41.200> contract<00:20:41.760> is<00:20:41.919> the 00:20:42.070 --> 00:20:42.080 align:start position:0% self-explanatory inbox contract is the 00:20:42.080 --> 00:20:44.710 align:start position:0% self-explanatory inbox contract is the address<00:20:42.360> of<00:20:42.480> the<00:20:42.600> RP<00:20:43.000> 7755<00:20:43.840> inbox<00:20:44.240> contract<00:20:44.640> on 00:20:44.710 --> 00:20:44.720 align:start position:0% address of the RP 7755 inbox contract on 00:20:44.720 --> 00:20:47.789 align:start position:0% address of the RP 7755 inbox contract on the<00:20:44.840> destination<00:20:45.600> chain<00:20:46.600> um<00:20:46.840> L2<00:20:47.280> Oracle 00:20:47.789 --> 00:20:47.799 align:start position:0% the destination chain um L2 Oracle 00:20:47.799 --> 00:20:49.510 align:start position:0% the destination chain um L2 Oracle address<00:20:48.520> that<00:20:48.600> is<00:20:48.760> the<00:20:48.960> address<00:20:49.280> of<00:20:49.400> the 00:20:49.510 --> 00:20:49.520 align:start position:0% address that is the address of the 00:20:49.520 --> 00:20:51.149 align:start position:0% address that is the address of the rollup<00:20:50.000> contract<00:20:50.480> that<00:20:50.559> would<00:20:50.679> get<00:20:50.799> deployed 00:20:51.149 --> 00:20:51.159 align:start position:0% rollup contract that would get deployed 00:20:51.159 --> 00:20:54.029 align:start position:0% rollup contract that would get deployed to<00:20:51.240> L1<00:20:51.880> for<00:20:52.200> the<00:20:52.320> destination<00:20:52.840> chain<00:20:53.720> so<00:20:53.919> this 00:20:54.029 --> 00:20:54.039 align:start position:0% to L1 for the destination chain so this 00:20:54.039 --> 00:20:56.190 align:start position:0% to L1 for the destination chain so this is<00:20:54.200> the<00:20:54.320> user<00:20:54.640> specifying<00:20:55.440> where<00:20:56.000> the 00:20:56.190 --> 00:20:56.200 align:start position:0% is the user specifying where the 00:20:56.200 --> 00:20:58.390 align:start position:0% is the user specifying where the approver<00:20:56.600> contract<00:20:57.000> should<00:20:57.200> be<00:20:57.320> looking<00:20:57.720> for 00:20:58.390 --> 00:20:58.400 align:start position:0% approver contract should be looking for 00:20:58.400 --> 00:20:59.710 align:start position:0% approver contract should be looking for the<00:20:58.600> the<00:20:58.640> state<00:20:58.840> representation<00:20:59.440> for<00:20:59.600> the 00:20:59.710 --> 00:20:59.720 align:start position:0% the the state representation for the 00:20:59.720 --> 00:21:01.350 align:start position:0% the the state representation for the destination<00:21:00.200> chain<00:21:00.559> when<00:21:00.679> it's<00:21:00.880> verifying 00:21:01.350 --> 00:21:01.360 align:start position:0% destination chain when it's verifying 00:21:01.360 --> 00:21:03.789 align:start position:0% destination chain when it's verifying that<00:21:01.440> the<00:21:01.559> call<00:21:01.720> was<00:21:02.159> submitted<00:21:03.159> um<00:21:03.559> so<00:21:03.720> the 00:21:03.789 --> 00:21:03.799 align:start position:0% that the call was submitted um so the 00:21:03.799 --> 00:21:05.470 align:start position:0% that the call was submitted um so the user<00:21:04.000> is<00:21:04.159> specifying<00:21:04.880> the<00:21:05.039> address<00:21:05.320> where 00:21:05.470 --> 00:21:05.480 align:start position:0% user is specifying the address where 00:21:05.480 --> 00:21:06.909 align:start position:0% user is specifying the address where that<00:21:05.559> should<00:21:05.679> be<00:21:05.840> located<00:21:06.280> as<00:21:06.400> well<00:21:06.640> as<00:21:06.799> the 00:21:06.909 --> 00:21:06.919 align:start position:0% that should be located as well as the 00:21:06.919 --> 00:21:08.590 align:start position:0% that should be located as well as the storage<00:21:07.320> key<00:21:07.600> within<00:21:07.880> that 00:21:08.590 --> 00:21:08.600 align:start position:0% storage key within that 00:21:08.600 --> 00:21:11.430 align:start position:0% storage key within that address<00:21:09.600> um<00:21:10.559> and<00:21:10.640> then<00:21:10.760> we<00:21:10.840> have<00:21:10.960> a<00:21:11.080> reward 00:21:11.430 --> 00:21:11.440 align:start position:0% address um and then we have a reward 00:21:11.440 --> 00:21:14.310 align:start position:0% address um and then we have a reward address<00:21:12.200> this<00:21:12.360> could<00:21:12.520> be<00:21:12.840> an<00:21:13.000> erc20<00:21:13.760> address 00:21:14.310 --> 00:21:14.320 align:start position:0% address this could be an erc20 address 00:21:14.320 --> 00:21:17.310 align:start position:0% address this could be an erc20 address or<00:21:14.720> as<00:21:14.880> specified<00:21:15.320> by<00:21:15.440> ERC<00:21:16.000> 7528<00:21:17.000> there's<00:21:17.159> a 00:21:17.310 --> 00:21:17.320 align:start position:0% or as specified by ERC 7528 there's a 00:21:17.320 --> 00:21:18.990 align:start position:0% or as specified by ERC 7528 there's a special<00:21:17.720> address<00:21:18.080> value<00:21:18.360> that<00:21:18.440> can<00:21:18.559> be<00:21:18.679> used 00:21:18.990 --> 00:21:19.000 align:start position:0% special address value that can be used 00:21:19.000 --> 00:21:21.830 align:start position:0% special address value that can be used to<00:21:19.640> um<00:21:20.440> depict<00:21:20.760> native 00:21:21.830 --> 00:21:21.840 align:start position:0% to um depict native 00:21:21.840 --> 00:21:24.430 align:start position:0% to um depict native currency<00:21:22.840> then<00:21:23.000> there's<00:21:23.200> reward<00:21:23.559> amount 00:21:24.430 --> 00:21:24.440 align:start position:0% currency then there's reward amount 00:21:24.440 --> 00:21:26.750 align:start position:0% currency then there's reward amount which<00:21:24.559> is<00:21:24.960> the<00:21:25.240> amount<00:21:25.480> of<00:21:26.000> the<00:21:26.159> reward<00:21:26.520> asset 00:21:26.750 --> 00:21:26.760 align:start position:0% which is the amount of the reward asset 00:21:26.760 --> 00:21:29.310 align:start position:0% which is the amount of the reward asset that<00:21:26.840> should<00:21:26.960> be<00:21:27.080> locked<00:21:27.400> within<00:21:27.720> the<00:21:28.039> request 00:21:29.310 --> 00:21:29.320 align:start position:0% that should be locked within the request 00:21:29.320 --> 00:21:31.590 align:start position:0% that should be locked within the request um<00:21:29.919> should<00:21:30.080> be<00:21:30.200> noted<00:21:30.520> that<00:21:30.679> reward<00:21:31.000> amount 00:21:31.590 --> 00:21:31.600 align:start position:0% um should be noted that reward amount 00:21:31.600 --> 00:21:33.909 align:start position:0% um should be noted that reward amount should<00:21:31.960> cover<00:21:32.840> all<00:21:32.960> of<00:21:33.120> the<00:21:33.320> value<00:21:33.720> that's 00:21:33.909 --> 00:21:33.919 align:start position:0% should cover all of the value that's 00:21:33.919 --> 00:21:36.190 align:start position:0% should cover all of the value that's included<00:21:34.320> in<00:21:34.480> these<00:21:34.640> calls<00:21:35.640> plus<00:21:35.919> whatever 00:21:36.190 --> 00:21:36.200 align:start position:0% included in these calls plus whatever 00:21:36.200 --> 00:21:37.909 align:start position:0% included in these calls plus whatever the<00:21:36.320> gas<00:21:36.679> cost<00:21:36.919> would<00:21:37.080> be<00:21:37.279> for<00:21:37.480> submitting<00:21:37.840> the 00:21:37.909 --> 00:21:37.919 align:start position:0% the gas cost would be for submitting the 00:21:37.919 --> 00:21:39.430 align:start position:0% the gas cost would be for submitting the call<00:21:38.080> to<00:21:38.200> the<00:21:38.279> destination<00:21:38.679> chain<00:21:39.120> plus<00:21:39.279> an 00:21:39.430 --> 00:21:39.440 align:start position:0% call to the destination chain plus an 00:21:39.440 --> 00:21:41.190 align:start position:0% call to the destination chain plus an extra<00:21:39.679> tip<00:21:39.880> for<00:21:40.000> the<00:21:40.080> fulfiller<00:21:40.919> and<00:21:41.039> that 00:21:41.190 --> 00:21:41.200 align:start position:0% extra tip for the fulfiller and that 00:21:41.200 --> 00:21:43.029 align:start position:0% extra tip for the fulfiller and that extra<00:21:41.520> tip<00:21:41.880> is<00:21:42.080> what<00:21:42.240> acts<00:21:42.440> as<00:21:42.600> the<00:21:42.679> incentive 00:21:43.029 --> 00:21:43.039 align:start position:0% extra tip is what acts as the incentive 00:21:43.039 --> 00:21:46.590 align:start position:0% extra tip is what acts as the incentive for<00:21:43.159> the<00:21:43.240> fulfiller<00:21:43.679> to<00:21:44.080> respond<00:21:44.400> to<00:21:44.520> the 00:21:46.590 --> 00:21:46.600 align:start position:0% for the fulfiller to respond to the 00:21:46.600 --> 00:21:48.789 align:start position:0% for the fulfiller to respond to the request<00:21:47.600> then<00:21:47.720> we<00:21:47.840> have<00:21:48.039> finality<00:21:48.480> delay 00:21:48.789 --> 00:21:48.799 align:start position:0% request then we have finality delay 00:21:48.799 --> 00:21:51.630 align:start position:0% request then we have finality delay seconds<00:21:49.559> this<00:21:49.679> is<00:21:50.120> uh<00:21:50.279> the<00:21:50.480> Gap<00:21:50.760> after<00:21:51.120> which 00:21:51.630 --> 00:21:51.640 align:start position:0% seconds this is uh the Gap after which 00:21:51.640 --> 00:21:53.710 align:start position:0% seconds this is uh the Gap after which or<00:21:51.919> after<00:21:52.320> the<00:21:52.559> call<00:21:52.760> is<00:21:52.919> successfully 00:21:53.710 --> 00:21:53.720 align:start position:0% or after the call is successfully 00:21:53.720 --> 00:21:56.590 align:start position:0% or after the call is successfully fulfilled<00:21:54.240> on<00:21:54.320> the<00:21:54.480> destination<00:21:55.200> chain<00:21:56.200> um 00:21:56.590 --> 00:21:56.600 align:start position:0% fulfilled on the destination chain um 00:21:56.600 --> 00:21:58.710 align:start position:0% fulfilled on the destination chain um that<00:21:56.799> has<00:21:56.919> to<00:21:57.279> pass<00:21:57.640> before<00:21:58.039> the<00:21:58.159> fulfill<00:21:58.640> is 00:21:58.710 --> 00:21:58.720 align:start position:0% that has to pass before the fulfill is 00:21:58.720 --> 00:22:00.350 align:start position:0% that has to pass before the fulfill is allowed<00:21:58.919> to<00:21:58.960> claim<00:21:59.159> their<00:21:59.360> reward<00:22:00.080> this<00:22:00.200> is 00:22:00.350 --> 00:22:00.360 align:start position:0% allowed to claim their reward this is 00:22:00.360 --> 00:22:02.549 align:start position:0% allowed to claim their reward this is basically<00:22:00.760> like<00:22:00.960> destination<00:22:01.480> chain<00:22:01.960> reorg 00:22:02.549 --> 00:22:02.559 align:start position:0% basically like destination chain reorg 00:22:02.559 --> 00:22:04.789 align:start position:0% basically like destination chain reorg protection<00:22:03.000> for<00:22:03.159> the<00:22:03.279> user<00:22:04.200> theot<00:22:04.600> like<00:22:04.679> the 00:22:04.789 --> 00:22:04.799 align:start position:0% protection for the user theot like the 00:22:04.799 --> 00:22:07.390 align:start position:0% protection for the user theot like the higher<00:22:05.120> this<00:22:05.279> delay<00:22:05.679> is<00:22:06.559> uh<00:22:06.760> the<00:22:06.880> more<00:22:07.120> likely 00:22:07.390 --> 00:22:07.400 align:start position:0% higher this delay is uh the more likely 00:22:07.400 --> 00:22:09.430 align:start position:0% higher this delay is uh the more likely the<00:22:07.520> reorg<00:22:07.919> chain<00:22:08.279> or<00:22:08.600> the<00:22:08.760> destination<00:22:09.200> chain 00:22:09.430 --> 00:22:09.440 align:start position:0% the reorg chain or the destination chain 00:22:09.440 --> 00:22:11.710 align:start position:0% the reorg chain or the destination chain won't<00:22:09.640> be<00:22:09.760> reorg<00:22:10.559> um<00:22:10.799> and<00:22:11.039> ensure<00:22:11.480> that<00:22:11.600> the 00:22:11.710 --> 00:22:11.720 align:start position:0% won't be reorg um and ensure that the 00:22:11.720 --> 00:22:13.390 align:start position:0% won't be reorg um and ensure that the call<00:22:12.080> was<00:22:12.320> actually<00:22:12.640> submitted<00:22:13.120> and<00:22:13.240> will 00:22:13.390 --> 00:22:13.400 align:start position:0% call was actually submitted and will 00:22:13.400 --> 00:22:15.750 align:start position:0% call was actually submitted and will stay<00:22:14.039> submitted<00:22:15.039> and<00:22:15.120> then<00:22:15.200> we<00:22:15.279> have<00:22:15.360> a<00:22:15.440> nons 00:22:15.750 --> 00:22:15.760 align:start position:0% stay submitted and then we have a nons 00:22:15.760 --> 00:22:18.590 align:start position:0% stay submitted and then we have a nons value<00:22:16.080> for<00:22:16.360> ensuring<00:22:16.760> that<00:22:16.960> every<00:22:17.320> request<00:22:18.000> is 00:22:18.590 --> 00:22:18.600 align:start position:0% value for ensuring that every request is 00:22:18.600 --> 00:22:20.669 align:start position:0% value for ensuring that every request is unique<00:22:19.600> as<00:22:19.799> the<00:22:19.880> way<00:22:20.000> we're<00:22:20.200> identifying 00:22:20.669 --> 00:22:20.679 align:start position:0% unique as the way we're identifying 00:22:20.679 --> 00:22:22.909 align:start position:0% unique as the way we're identifying these<00:22:20.840> requests<00:22:21.240> is<00:22:21.360> by<00:22:21.520> hashing<00:22:21.880> this<00:22:22.000> entire 00:22:22.909 --> 00:22:22.919 align:start position:0% these requests is by hashing this entire 00:22:22.919 --> 00:22:26.230 align:start position:0% these requests is by hashing this entire structure<00:22:23.919> an<00:22:24.120> expir<00:22:24.600> field<00:22:25.080> for<00:22:25.840> uh<00:22:25.960> when<00:22:26.120> the 00:22:26.230 --> 00:22:26.240 align:start position:0% structure an expir field for uh when the 00:22:26.240 --> 00:22:28.230 align:start position:0% structure an expir field for uh when the request<00:22:26.559> should<00:22:26.799> expire<00:22:27.480> this<00:22:27.600> is<00:22:27.840> relevant 00:22:28.230 --> 00:22:28.240 align:start position:0% request should expire this is relevant 00:22:28.240 --> 00:22:30.750 align:start position:0% request should expire this is relevant for<00:22:28.520> for<00:22:29.520> um<00:22:29.840> the<00:22:29.919> user<00:22:30.200> being<00:22:30.400> able<00:22:30.600> to 00:22:30.750 --> 00:22:30.760 align:start position:0% for for um the user being able to 00:22:30.760 --> 00:22:32.470 align:start position:0% for for um the user being able to reclaim<00:22:31.159> the<00:22:31.279> reward<00:22:31.760> if<00:22:31.880> for<00:22:32.080> whatever 00:22:32.470 --> 00:22:32.480 align:start position:0% reclaim the reward if for whatever 00:22:32.480 --> 00:22:34.230 align:start position:0% reclaim the reward if for whatever reason<00:22:33.039> the<00:22:33.200> call<00:22:33.360> was<00:22:33.520> never<00:22:33.720> submitted<00:22:34.080> to 00:22:34.230 --> 00:22:34.240 align:start position:0% reason the call was never submitted to 00:22:34.240 --> 00:22:36.230 align:start position:0% reason the call was never submitted to the<00:22:34.360> destination<00:22:34.880> chain<00:22:35.760> um<00:22:35.880> there<00:22:36.000> should<00:22:36.159> be 00:22:36.230 --> 00:22:36.240 align:start position:0% the destination chain um there should be 00:22:36.240 --> 00:22:38.430 align:start position:0% the destination chain um there should be a<00:22:36.360> mechanism<00:22:37.000> for<00:22:37.159> the<00:22:37.279> user<00:22:37.600> to<00:22:37.919> to<00:22:38.080> recover 00:22:38.430 --> 00:22:38.440 align:start position:0% a mechanism for the user to to recover 00:22:38.440 --> 00:22:40.549 align:start position:0% a mechanism for the user to to recover those<00:22:38.559> funds<00:22:39.480> and<00:22:39.640> that's<00:22:39.799> what<00:22:39.919> this<00:22:40.039> xer<00:22:40.400> Tim 00:22:40.549 --> 00:22:40.559 align:start position:0% those funds and that's what this xer Tim 00:22:40.559 --> 00:22:42.350 align:start position:0% those funds and that's what this xer Tim stamp<00:22:40.840> is<00:22:41.440> if<00:22:41.520> the<00:22:41.640> call<00:22:41.799> is<00:22:41.880> not<00:22:42.000> submitted 00:22:42.350 --> 00:22:42.360 align:start position:0% stamp is if the call is not submitted 00:22:42.360 --> 00:22:44.070 align:start position:0% stamp is if the call is not submitted for<00:22:42.480> the<00:22:42.600> X<00:22:42.919> time<00:22:43.120> stamp<00:22:43.480> then<00:22:43.679> that's<00:22:43.880> when 00:22:44.070 --> 00:22:44.080 align:start position:0% for the X time stamp then that's when 00:22:44.080 --> 00:22:46.149 align:start position:0% for the X time stamp then that's when the<00:22:44.159> user<00:22:44.400> can<00:22:44.679> reclaim<00:22:45.679> and<00:22:45.799> then<00:22:45.919> we<00:22:46.000> have 00:22:46.149 --> 00:22:46.159 align:start position:0% the user can reclaim and then we have 00:22:46.159 --> 00:22:47.549 align:start position:0% the user can reclaim and then we have these<00:22:46.320> last<00:22:46.440> two<00:22:46.559> fields<00:22:46.880> for<00:22:47.000> the<00:22:47.120> pre-check 00:22:47.549 --> 00:22:47.559 align:start position:0% these last two fields for the pre-check 00:22:47.559 --> 00:22:49.510 align:start position:0% these last two fields for the pre-check contract<00:22:48.039> so<00:22:48.200> a<00:22:48.320> pre-check<00:22:48.760> contract<00:22:49.159> address 00:22:49.510 --> 00:22:49.520 align:start position:0% contract so a pre-check contract address 00:22:49.520 --> 00:22:52.070 align:start position:0% contract so a pre-check contract address and<00:22:49.679> an<00:22:49.840> arbitrary<00:22:50.799> bytes<00:22:51.120> array<00:22:51.600> of<00:22:51.960> uh 00:22:52.070 --> 00:22:52.080 align:start position:0% and an arbitrary bytes array of uh 00:22:52.080 --> 00:22:54.710 align:start position:0% and an arbitrary bytes array of uh encoded<00:22:52.559> data<00:22:52.880> for<00:22:53.080> that<00:22:53.360> pre-check<00:22:54.360> um<00:22:54.600> this 00:22:54.710 --> 00:22:54.720 align:start position:0% encoded data for that pre-check um this 00:22:54.720 --> 00:22:57.310 align:start position:0% encoded data for that pre-check um this is<00:22:54.880> for<00:22:55.159> that<00:22:55.440> optional<00:22:56.440> like<00:22:56.600> arbitrary 00:22:57.310 --> 00:22:57.320 align:start position:0% is for that optional like arbitrary 00:22:57.320 --> 00:22:58.590 align:start position:0% is for that optional like arbitrary fulfillment<00:22:57.880> condition<00:22:58.080> that<00:22:58.159> should<00:22:58.279> be 00:22:58.590 --> 00:22:58.600 align:start position:0% fulfillment condition that should be 00:22:58.600 --> 00:23:01.350 align:start position:0% fulfillment condition that should be true<00:22:59.480> if<00:22:59.760> this<00:22:59.880> is<00:23:00.039> the<00:23:00.200> zero<00:23:00.520> address<00:23:01.000> that<00:23:01.120> is 00:23:01.350 --> 00:23:01.360 align:start position:0% true if this is the zero address that is 00:23:01.360 --> 00:23:03.350 align:start position:0% true if this is the zero address that is depicting<00:23:01.919> that<00:23:02.039> we're<00:23:02.320> not<00:23:02.520> going<00:23:02.760> to<00:23:03.000> to<00:23:03.200> use 00:23:03.350 --> 00:23:03.360 align:start position:0% depicting that we're not going to to use 00:23:03.360 --> 00:23:05.190 align:start position:0% depicting that we're not going to to use it<00:23:04.039> and<00:23:04.320> uh<00:23:04.400> we're<00:23:04.559> not<00:23:04.640> going<00:23:04.760> to<00:23:04.840> be<00:23:04.919> doing<00:23:05.080> a 00:23:05.190 --> 00:23:05.200 align:start position:0% it and uh we're not going to be doing a 00:23:05.200 --> 00:23:08.549 align:start position:0% it and uh we're not going to be doing a pre-check<00:23:05.679> step<00:23:06.080> in<00:23:06.200> today's<00:23:06.600> demo<00:23:07.120> but<00:23:07.960> um 00:23:08.549 --> 00:23:08.559 align:start position:0% pre-check step in today's demo but um 00:23:08.559 --> 00:23:10.190 align:start position:0% pre-check step in today's demo but um figure<00:23:08.840> it's<00:23:09.000> worth<00:23:09.440> covering<00:23:09.799> that<00:23:09.960> it's 00:23:10.190 --> 00:23:10.200 align:start position:0% figure it's worth covering that it's 00:23:10.200 --> 00:23:12.470 align:start position:0% figure it's worth covering that it's it's<00:23:10.360> there 00:23:12.470 --> 00:23:12.480 align:start position:0% it's there 00:23:12.480 --> 00:23:15.350 align:start position:0% it's there anyways<00:23:13.480> so<00:23:13.640> then<00:23:13.799> next<00:23:14.039> up<00:23:14.320> we'll<00:23:14.799> do<00:23:15.000> a<00:23:15.200> quick 00:23:15.350 --> 00:23:15.360 align:start position:0% anyways so then next up we'll do a quick 00:23:15.360 --> 00:23:17.669 align:start position:0% anyways so then next up we'll do a quick walkr<00:23:15.760> of<00:23:15.919> the<00:23:16.080> Inbox<00:23:16.440> and<00:23:16.559> outbox<00:23:17.000> contracts 00:23:17.669 --> 00:23:17.679 align:start position:0% walkr of the Inbox and outbox contracts 00:23:17.679 --> 00:23:19.390 align:start position:0% walkr of the Inbox and outbox contracts so<00:23:17.880> the<00:23:18.000> outbox<00:23:18.440> contract<00:23:18.799> being<00:23:19.039> the<00:23:19.120> entry 00:23:19.390 --> 00:23:19.400 align:start position:0% so the outbox contract being the entry 00:23:19.400 --> 00:23:21.750 align:start position:0% so the outbox contract being the entry point<00:23:19.600> to<00:23:19.760> the<00:23:19.880> system<00:23:20.880> um<00:23:21.039> we<00:23:21.159> have<00:23:21.360> one<00:23:21.520> main 00:23:21.750 --> 00:23:21.760 align:start position:0% point to the system um we have one main 00:23:21.760 --> 00:23:23.110 align:start position:0% point to the system um we have one main function<00:23:22.039> that<00:23:22.120> we<00:23:22.240> really<00:23:22.480> care<00:23:22.640> about<00:23:22.840> here 00:23:23.110 --> 00:23:23.120 align:start position:0% function that we really care about here 00:23:23.120 --> 00:23:24.669 align:start position:0% function that we really care about here request<00:23:23.520> cross<00:23:23.760> chain<00:23:24.000> call<00:23:24.400> that's<00:23:24.559> where 00:23:24.669 --> 00:23:24.679 align:start position:0% request cross chain call that's where 00:23:24.679 --> 00:23:27.269 align:start position:0% request cross chain call that's where the<00:23:24.760> user<00:23:24.960> would<00:23:25.120> submit<00:23:25.400> the<00:23:25.760> request<00:23:26.760> um<00:23:27.080> and 00:23:27.269 --> 00:23:27.279 align:start position:0% the user would submit the request um and 00:23:27.279 --> 00:23:28.830 align:start position:0% the user would submit the request um and where<00:23:27.559> the<00:23:27.679> event<00:23:27.919> would<00:23:28.039> be<00:23:28.159> admitted<00:23:28.760> that 00:23:28.830 --> 00:23:28.840 align:start position:0% where the event would be admitted that 00:23:28.840 --> 00:23:31.630 align:start position:0% where the event would be admitted that the<00:23:28.960> fulfillers<00:23:29.480> are<00:23:29.679> listening 00:23:31.630 --> 00:23:31.640 align:start position:0% the fulfillers are listening 00:23:31.640 --> 00:23:34.110 align:start position:0% the fulfillers are listening for<00:23:32.640> then<00:23:32.720> we<00:23:32.840> have<00:23:32.960> a<00:23:33.080> claim<00:23:33.360> reward<00:23:33.720> function 00:23:34.110 --> 00:23:34.120 align:start position:0% for then we have a claim reward function 00:23:34.120 --> 00:23:35.590 align:start position:0% for then we have a claim reward function which<00:23:34.240> is<00:23:34.320> where<00:23:34.440> the<00:23:34.559> fulfiller<00:23:34.960> comes<00:23:35.240> to<00:23:35.480> to 00:23:35.590 --> 00:23:35.600 align:start position:0% which is where the fulfiller comes to to 00:23:35.600 --> 00:23:37.549 align:start position:0% which is where the fulfiller comes to to claim<00:23:35.840> their<00:23:36.000> reward<00:23:36.320> after<00:23:36.640> successfully<00:23:37.480> uh 00:23:37.549 --> 00:23:37.559 align:start position:0% claim their reward after successfully uh 00:23:37.559 --> 00:23:39.430 align:start position:0% claim their reward after successfully uh fulfilling<00:23:37.960> the<00:23:38.080> request<00:23:39.000> and<00:23:39.120> that<00:23:39.240> calls 00:23:39.430 --> 00:23:39.440 align:start position:0% fulfilling the request and that calls 00:23:39.440 --> 00:23:41.789 align:start position:0% fulfilling the request and that calls into<00:23:39.640> the<00:23:39.760> pro<00:23:40.120> contract<00:23:40.600> here<00:23:40.799> on<00:23:40.960> this<00:23:41.159> line 00:23:41.789 --> 00:23:41.799 align:start position:0% into the pro contract here on this line 00:23:41.799 --> 00:23:43.789 align:start position:0% into the pro contract here on this line and<00:23:41.880> so<00:23:42.120> this<00:23:42.320> contract<00:23:42.760> is<00:23:43.120> again<00:23:43.559> what<00:23:43.679> we're 00:23:43.789 --> 00:23:43.799 align:start position:0% and so this contract is again what we're 00:23:43.799 --> 00:23:46.269 align:start position:0% and so this contract is again what we're about<00:23:43.960> to<00:23:44.320> implement<00:23:45.320> uh<00:23:45.440> it<00:23:45.720> expected<00:23:46.080> to 00:23:46.269 --> 00:23:46.279 align:start position:0% about to implement uh it expected to 00:23:46.279 --> 00:23:48.950 align:start position:0% about to implement uh it expected to revert<00:23:46.799> if<00:23:46.960> the<00:23:47.159> proof<00:23:47.520> fails<00:23:48.440> uh<00:23:48.520> so<00:23:48.799> there 00:23:48.950 --> 00:23:48.960 align:start position:0% revert if the proof fails uh so there 00:23:48.960 --> 00:23:51.269 align:start position:0% revert if the proof fails uh so there there's<00:23:49.120> no<00:23:49.360> return<00:23:49.559> value<00:23:49.799> or<00:23:49.919> anything<00:23:50.279> here 00:23:51.269 --> 00:23:51.279 align:start position:0% there's no return value or anything here 00:23:51.279 --> 00:23:52.750 align:start position:0% there's no return value or anything here and<00:23:51.400> then<00:23:51.559> lastly<00:23:51.880> the<00:23:52.000> cancel<00:23:52.360> request 00:23:52.750 --> 00:23:52.760 align:start position:0% and then lastly the cancel request 00:23:52.760 --> 00:23:54.430 align:start position:0% and then lastly the cancel request function<00:23:53.080> so<00:23:53.240> this<00:23:53.360> is<00:23:53.520> like<00:23:53.640> after<00:23:53.840> the<00:23:54.000> exper 00:23:54.430 --> 00:23:54.440 align:start position:0% function so this is like after the exper 00:23:54.440 --> 00:23:56.230 align:start position:0% function so this is like after the exper Tim<00:23:54.640> stamp<00:23:55.000> if<00:23:55.480> the<00:23:55.600> reward<00:23:55.919> has<00:23:56.000> not<00:23:56.120> been 00:23:56.230 --> 00:23:56.240 align:start position:0% Tim stamp if the reward has not been 00:23:56.240 --> 00:23:57.909 align:start position:0% Tim stamp if the reward has not been claimed<00:23:56.600> yet<00:23:56.799> then<00:23:56.960> the<00:23:57.039> user<00:23:57.360> gets<00:23:57.559> to<00:23:57.799> to 00:23:57.909 --> 00:23:57.919 align:start position:0% claimed yet then the user gets to to 00:23:57.919 --> 00:24:01.990 align:start position:0% claimed yet then the user gets to to reclaim<00:23:58.279> it 00:24:01.990 --> 00:24:02.000 align:start position:0% 00:24:02.000 --> 00:24:04.230 align:start position:0% on<00:24:02.120> the<00:24:02.320> destination<00:24:02.880> chain<00:24:03.320> side<00:24:03.720> we<00:24:03.960> have 00:24:04.230 --> 00:24:04.240 align:start position:0% on the destination chain side we have 00:24:04.240 --> 00:24:07.149 align:start position:0% on the destination chain side we have the<00:24:04.360> inbox<00:24:05.200> contract<00:24:06.200> um<00:24:06.400> the<00:24:06.559> main<00:24:06.840> piece<00:24:07.000> of 00:24:07.149 --> 00:24:07.159 align:start position:0% the inbox contract um the main piece of 00:24:07.159 --> 00:24:08.470 align:start position:0% the inbox contract um the main piece of information<00:24:07.520> we<00:24:07.679> care<00:24:07.840> about<00:24:08.080> here<00:24:08.240> is<00:24:08.360> this 00:24:08.470 --> 00:24:08.480 align:start position:0% information we care about here is this 00:24:08.480 --> 00:24:10.750 align:start position:0% information we care about here is this fulfillment<00:24:08.960> info<00:24:09.279> struct<00:24:10.080> so<00:24:10.240> this<00:24:10.360> is<00:24:10.559> that 00:24:10.750 --> 00:24:10.760 align:start position:0% fulfillment info struct so this is that 00:24:10.760 --> 00:24:12.830 align:start position:0% fulfillment info struct so this is that execution<00:24:11.320> receipt<00:24:11.919> that<00:24:12.000> should<00:24:12.240> be<00:24:12.520> created 00:24:12.830 --> 00:24:12.840 align:start position:0% execution receipt that should be created 00:24:12.840 --> 00:24:14.750 align:start position:0% execution receipt that should be created in<00:24:13.039> storage<00:24:13.760> and<00:24:14.200> uh<00:24:14.320> that<00:24:14.440> will<00:24:14.559> be<00:24:14.679> the 00:24:14.750 --> 00:24:14.760 align:start position:0% in storage and uh that will be the 00:24:14.760 --> 00:24:16.510 align:start position:0% in storage and uh that will be the target<00:24:15.080> of<00:24:15.159> the<00:24:15.279> nested<00:24:15.600> storage<00:24:15.919> proof 00:24:16.510 --> 00:24:16.520 align:start position:0% target of the nested storage proof 00:24:16.520 --> 00:24:20.350 align:start position:0% target of the nested storage proof validation<00:24:17.520> um<00:24:18.360> the<00:24:18.520> whole<00:24:18.760> point<00:24:19.240> of<00:24:19.919> the<00:24:20.200> the 00:24:20.350 --> 00:24:20.360 align:start position:0% validation um the whole point of the the 00:24:20.360 --> 00:24:22.830 align:start position:0% validation um the whole point of the the the<00:24:20.440> storage<00:24:20.760> proof<00:24:21.120> there<00:24:21.600> is<00:24:21.760> to<00:24:22.159> prove<00:24:22.679> that 00:24:22.830 --> 00:24:22.840 align:start position:0% the storage proof there is to prove that 00:24:22.840 --> 00:24:24.990 align:start position:0% the storage proof there is to prove that this<00:24:22.960> struct<00:24:23.440> exists<00:24:23.840> in<00:24:24.000> storage<00:24:24.480> for<00:24:24.799> the 00:24:24.990 --> 00:24:25.000 align:start position:0% this struct exists in storage for the 00:24:25.000 --> 00:24:27.430 align:start position:0% this struct exists in storage for the specific<00:24:25.480> request<00:24:26.480> and<00:24:26.679> this<00:24:26.799> is<00:24:26.919> storing<00:24:27.320> the 00:24:27.430 --> 00:24:27.440 align:start position:0% specific request and this is storing the 00:24:27.440 --> 00:24:28.830 align:start position:0% specific request and this is storing the time<00:24:27.640> stamp<00:24:27.880> at<00:24:27.960> which<00:24:28.120> the<00:24:28.360> request<00:24:28.679> was 00:24:28.830 --> 00:24:28.840 align:start position:0% time stamp at which the request was 00:24:28.840 --> 00:24:31.070 align:start position:0% time stamp at which the request was submitted<00:24:29.799> as<00:24:29.919> well<00:24:30.080> as<00:24:30.200> the<00:24:30.320> filler<00:24:30.760> address 00:24:31.070 --> 00:24:31.080 align:start position:0% submitted as well as the filler address 00:24:31.080 --> 00:24:32.870 align:start position:0% submitted as well as the filler address that<00:24:31.200> should<00:24:31.440> be<00:24:31.559> able<00:24:31.760> to<00:24:32.000> claim<00:24:32.279> the<00:24:32.440> reward 00:24:32.870 --> 00:24:32.880 align:start position:0% that should be able to claim the reward 00:24:32.880 --> 00:24:34.950 align:start position:0% that should be able to claim the reward back<00:24:33.039> on<00:24:33.240> the<00:24:33.679> um<00:24:34.039> Source 00:24:34.950 --> 00:24:34.960 align:start position:0% back on the um Source 00:24:34.960 --> 00:24:37.269 align:start position:0% back on the um Source chain<00:24:35.960> and<00:24:36.120> that<00:24:36.279> gets<00:24:36.520> created<00:24:36.880> during<00:24:37.120> this 00:24:37.269 --> 00:24:37.279 align:start position:0% chain and that gets created during this 00:24:37.279 --> 00:24:39.630 align:start position:0% chain and that gets created during this fulfill<00:24:37.880> function<00:24:38.880> so<00:24:39.120> we<00:24:39.240> have<00:24:39.360> all<00:24:39.480> our 00:24:39.630 --> 00:24:39.640 align:start position:0% fulfill function so we have all our 00:24:39.640 --> 00:24:42.310 align:start position:0% fulfill function so we have all our validation<00:24:40.080> steps<00:24:40.399> up<00:24:40.640> here<00:24:41.320> and<00:24:41.480> then<00:24:41.960> uh<00:24:42.120> we 00:24:42.310 --> 00:24:42.320 align:start position:0% validation steps up here and then uh we 00:24:42.320 --> 00:24:44.389 align:start position:0% validation steps up here and then uh we we<00:24:42.440> route<00:24:42.679> the<00:24:42.799> calls<00:24:43.240> here<00:24:44.080> and<00:24:44.200> if 00:24:44.389 --> 00:24:44.399 align:start position:0% we route the calls here and if 00:24:44.399 --> 00:24:45.789 align:start position:0% we route the calls here and if everything<00:24:44.720> successful<00:24:45.159> we're<00:24:45.360> left<00:24:45.640> with 00:24:45.789 --> 00:24:45.799 align:start position:0% everything successful we're left with 00:24:45.799 --> 00:24:48.430 align:start position:0% everything successful we're left with the<00:24:46.000> created<00:24:46.360> fulfillment<00:24:46.799> info 00:24:48.430 --> 00:24:48.440 align:start position:0% the created fulfillment info 00:24:48.440 --> 00:24:51.110 align:start position:0% the created fulfillment info struct<00:24:49.440> so<00:24:49.600> this<00:24:49.760> contract<00:24:50.080> is<00:24:50.200> fairly 00:24:51.110 --> 00:24:51.120 align:start position:0% struct so this contract is fairly 00:24:51.120 --> 00:24:53.350 align:start position:0% struct so this contract is fairly simple<00:24:52.120> um<00:24:52.360> something<00:24:52.640> a<00:24:52.760> little<00:24:52.960> bit<00:24:53.120> more 00:24:53.350 --> 00:24:53.360 align:start position:0% simple um something a little bit more 00:24:53.360 --> 00:24:55.830 align:start position:0% simple um something a little bit more interesting<00:24:54.120> we<00:24:54.279> have<00:24:54.480> this<00:24:54.679> State<00:24:55.000> validator 00:24:55.830 --> 00:24:55.840 align:start position:0% interesting we have this State validator 00:24:55.840 --> 00:24:59.389 align:start position:0% interesting we have this State validator library<00:24:56.840> and<00:24:57.320> if<00:24:58.080> you<00:24:58.559> in<00:24:58.640> the<00:24:58.760> future<00:24:59.200> are 00:24:59.389 --> 00:24:59.399 align:start position:0% library and if you in the future are 00:24:59.399 --> 00:25:01.269 align:start position:0% library and if you in the future are working<00:24:59.720> on<00:25:00.240> setting<00:25:00.559> up<00:25:00.679> a<00:25:00.760> new<00:25:00.880> prover 00:25:01.269 --> 00:25:01.279 align:start position:0% working on setting up a new prover 00:25:01.279 --> 00:25:02.909 align:start position:0% working on setting up a new prover contract<00:25:01.679> for<00:25:01.960> a<00:25:02.080> new<00:25:02.240> destination<00:25:02.679> chain 00:25:02.909 --> 00:25:02.919 align:start position:0% contract for a new destination chain 00:25:02.919 --> 00:25:04.389 align:start position:0% contract for a new destination chain that's<00:25:03.080> not<00:25:03.240> currently<00:25:03.559> supported<00:25:03.919> by<00:25:04.039> the 00:25:04.389 --> 00:25:04.399 align:start position:0% that's not currently supported by the 00:25:04.399 --> 00:25:06.590 align:start position:0% that's not currently supported by the proposal<00:25:05.399> um<00:25:05.880> you<00:25:06.080> likely<00:25:06.360> would<00:25:06.480> be 00:25:06.590 --> 00:25:06.600 align:start position:0% proposal um you likely would be 00:25:06.600 --> 00:25:08.389 align:start position:0% proposal um you likely would be utilizing<00:25:07.000> the<00:25:07.120> State<00:25:07.320> validator<00:25:07.880> Library 00:25:08.389 --> 00:25:08.399 align:start position:0% utilizing the State validator Library 00:25:08.399 --> 00:25:10.830 align:start position:0% utilizing the State validator Library the<00:25:08.480> whole<00:25:08.640> point<00:25:08.799> of<00:25:09.000> this<00:25:09.679> is<00:25:09.799> to<00:25:10.120> abstract<00:25:10.679> a 00:25:10.830 --> 00:25:10.840 align:start position:0% the whole point of this is to abstract a 00:25:10.840 --> 00:25:13.590 align:start position:0% the whole point of this is to abstract a lot<00:25:11.080> of<00:25:11.240> the<00:25:11.440> complexity<00:25:12.279> involved<00:25:12.840> with<00:25:13.440> um 00:25:13.590 --> 00:25:13.600 align:start position:0% lot of the complexity involved with um 00:25:13.600 --> 00:25:16.230 align:start position:0% lot of the complexity involved with um storage<00:25:13.960> proofs<00:25:14.360> away<00:25:14.559> from<00:25:14.720> the<00:25:15.240> developer 00:25:16.230 --> 00:25:16.240 align:start position:0% storage proofs away from the developer 00:25:16.240 --> 00:25:18.190 align:start position:0% storage proofs away from the developer um<00:25:16.720> no<00:25:16.880> need<00:25:17.039> to<00:25:17.159> reinvent<00:25:17.559> the<00:25:17.640> wheel<00:25:17.880> every 00:25:18.190 --> 00:25:18.200 align:start position:0% um no need to reinvent the wheel every 00:25:18.200 --> 00:25:21.710 align:start position:0% um no need to reinvent the wheel every time<00:25:19.200> um<00:25:19.799> so<00:25:20.039> the<00:25:20.159> way<00:25:20.360> that<00:25:20.559> this<00:25:21.240> this<00:25:21.360> is<00:25:21.520> set 00:25:21.710 --> 00:25:21.720 align:start position:0% time um so the way that this this is set 00:25:21.720 --> 00:25:23.230 align:start position:0% time um so the way that this this is set up<00:25:21.840> there<00:25:21.919> are<00:25:22.039> two<00:25:22.200> main<00:25:22.480> functions<00:25:22.960> that<00:25:23.080> we 00:25:23.230 --> 00:25:23.240 align:start position:0% up there are two main functions that we 00:25:23.240 --> 00:25:25.350 align:start position:0% up there are two main functions that we care<00:25:23.480> about<00:25:23.880> there's<00:25:24.159> validate<00:25:24.600> State<00:25:25.240> and 00:25:25.350 --> 00:25:25.360 align:start position:0% care about there's validate State and 00:25:25.360 --> 00:25:27.510 align:start position:0% care about there's validate State and then<00:25:25.480> there's<00:25:25.679> validate<00:25:26.080> account<00:25:26.520> storage 00:25:27.510 --> 00:25:27.520 align:start position:0% then there's validate account storage 00:25:27.520 --> 00:25:30.230 align:start position:0% then there's validate account storage validate<00:25:27.919> state<00:25:28.520> is<00:25:28.720> for<00:25:29.320> if<00:25:29.480> you're<00:25:29.799> starting 00:25:30.230 --> 00:25:30.240 align:start position:0% validate state is for if you're starting 00:25:30.240 --> 00:25:33.149 align:start position:0% validate state is for if you're starting from<00:25:30.480> the<00:25:30.640> beacon<00:25:30.960> route<00:25:31.399> on<00:25:32.080> uh<00:25:32.200> L1<00:25:33.039> and 00:25:33.149 --> 00:25:33.159 align:start position:0% from the beacon route on uh L1 and 00:25:33.159 --> 00:25:36.310 align:start position:0% from the beacon route on uh L1 and you're<00:25:33.360> trying<00:25:33.640> to<00:25:34.480> um<00:25:34.880> verify<00:25:35.559> the<00:25:36.080> like<00:25:36.159> the 00:25:36.310 --> 00:25:36.320 align:start position:0% you're trying to um verify the like the 00:25:36.320 --> 00:25:38.470 align:start position:0% you're trying to um verify the like the L1<00:25:36.640> execution<00:25:37.039> client<00:25:37.320> State<00:25:37.559> Route<00:25:38.200> against 00:25:38.470 --> 00:25:38.480 align:start position:0% L1 execution client State Route against 00:25:38.480 --> 00:25:40.310 align:start position:0% L1 execution client State Route against that<00:25:38.600> Beacon<00:25:38.919> route<00:25:39.880> um<00:25:40.000> that's<00:25:40.159> what 00:25:40.310 --> 00:25:40.320 align:start position:0% that Beacon route um that's what 00:25:40.320 --> 00:25:41.950 align:start position:0% that Beacon route um that's what validate<00:25:40.640> state<00:25:40.880> would<00:25:41.000> do<00:25:41.240> and<00:25:41.399> then<00:25:41.679> from 00:25:41.950 --> 00:25:41.960 align:start position:0% validate state would do and then from 00:25:41.960 --> 00:25:44.389 align:start position:0% validate state would do and then from there<00:25:42.279> using<00:25:42.679> that<00:25:43.080> the<00:25:43.679> the<00:25:43.760> verified<00:25:44.159> State 00:25:44.389 --> 00:25:44.399 align:start position:0% there using that the the verified State 00:25:44.399 --> 00:25:46.630 align:start position:0% there using that the the verified State Route<00:25:44.760> it<00:25:44.840> would<00:25:45.039> then<00:25:45.399> prove<00:25:46.120> uh<00:25:46.240> storage 00:25:46.630 --> 00:25:46.640 align:start position:0% Route it would then prove uh storage 00:25:46.640 --> 00:25:48.750 align:start position:0% Route it would then prove uh storage location<00:25:47.159> for<00:25:47.840> an<00:25:48.039> account<00:25:48.320> within<00:25:48.559> that 00:25:48.750 --> 00:25:48.760 align:start position:0% location for an account within that 00:25:48.760 --> 00:25:51.110 align:start position:0% location for an account within that state<00:25:49.720> because<00:25:50.080> our<00:25:50.279> example<00:25:50.600> today<00:25:50.840> is<00:25:50.960> not 00:25:51.110 --> 00:25:51.120 align:start position:0% state because our example today is not 00:25:51.120 --> 00:25:53.230 align:start position:0% state because our example today is not using<00:25:51.360> Beacon<00:25:51.679> rootes<00:25:52.080> we<00:25:52.279> don't<00:25:52.720> need<00:25:52.880> to<00:25:53.039> use 00:25:53.230 --> 00:25:53.240 align:start position:0% using Beacon rootes we don't need to use 00:25:53.240 --> 00:25:54.669 align:start position:0% using Beacon rootes we don't need to use this<00:25:53.399> function<00:25:53.760> but<00:25:53.880> I<00:25:54.000> figured<00:25:54.240> I'd<00:25:54.399> briefly 00:25:54.669 --> 00:25:54.679 align:start position:0% this function but I figured I'd briefly 00:25:54.679 --> 00:25:56.870 align:start position:0% this function but I figured I'd briefly cover<00:25:54.960> it<00:25:55.799> the<00:25:55.919> function<00:25:56.200> we<00:25:56.360> care<00:25:56.520> about<00:25:56.760> is 00:25:56.870 --> 00:25:56.880 align:start position:0% cover it the function we care about is 00:25:56.880 --> 00:25:58.630 align:start position:0% cover it the function we care about is this<00:25:57.039> validate<00:25:57.440> account<00:25:57.679> storage<00:25:58.360> so<00:25:58.520> this 00:25:58.630 --> 00:25:58.640 align:start position:0% this validate account storage so this 00:25:58.640 --> 00:26:01.149 align:start position:0% this validate account storage so this takes<00:25:58.840> in<00:25:59.120> an<00:25:59.360> account<00:25:59.880> which<00:25:59.960> is<00:26:00.080> a<00:26:00.279> specific 00:26:01.149 --> 00:26:01.159 align:start position:0% takes in an account which is a specific 00:26:01.159 --> 00:26:03.110 align:start position:0% takes in an account which is a specific account<00:26:01.399> within<00:26:01.640> the<00:26:01.760> network<00:26:02.559> a<00:26:02.679> state<00:26:02.919> route 00:26:03.110 --> 00:26:03.120 align:start position:0% account within the network a state route 00:26:03.120 --> 00:26:05.110 align:start position:0% account within the network a state route for<00:26:03.240> the<00:26:03.360> network<00:26:03.960> and<00:26:04.080> then<00:26:04.320> a<00:26:04.440> handful<00:26:04.919> of 00:26:05.110 --> 00:26:05.120 align:start position:0% for the network and then a handful of 00:26:05.120 --> 00:26:07.710 align:start position:0% for the network and then a handful of these<00:26:05.320> account<00:26:05.640> proof<00:26:06.240> parameters<00:26:07.240> and<00:26:07.399> using 00:26:07.710 --> 00:26:07.720 align:start position:0% these account proof parameters and using 00:26:07.720 --> 00:26:09.870 align:start position:0% these account proof parameters and using these<00:26:07.919> account<00:26:08.200> proof<00:26:08.520> parameters<00:26:09.360> which<00:26:09.480> are 00:26:09.870 --> 00:26:09.880 align:start position:0% these account proof parameters which are 00:26:09.880 --> 00:26:11.990 align:start position:0% these account proof parameters which are specified<00:26:10.360> storage<00:26:10.760> key<00:26:11.399> an<00:26:11.600> expected 00:26:11.990 --> 00:26:12.000 align:start position:0% specified storage key an expected 00:26:12.000 --> 00:26:14.470 align:start position:0% specified storage key an expected storage<00:26:12.520> value<00:26:13.520> and<00:26:13.600> then<00:26:13.760> an<00:26:13.919> account<00:26:14.279> proof 00:26:14.470 --> 00:26:14.480 align:start position:0% storage value and then an account proof 00:26:14.480 --> 00:26:16.630 align:start position:0% storage value and then an account proof and<00:26:14.720> storage<00:26:15.080> proof<00:26:15.799> the<00:26:15.960> account<00:26:16.240> proof<00:26:16.520> can 00:26:16.630 --> 00:26:16.640 align:start position:0% and storage proof the account proof can 00:26:16.640 --> 00:26:18.750 align:start position:0% and storage proof the account proof can be<00:26:16.799> thought<00:26:16.960> of<00:26:17.279> as<00:26:17.480> the<00:26:17.679> path<00:26:18.000> down<00:26:18.279> the<00:26:18.480> state 00:26:18.750 --> 00:26:18.760 align:start position:0% be thought of as the path down the state 00:26:18.760 --> 00:26:21.110 align:start position:0% be thought of as the path down the state try<00:26:19.240> from<00:26:19.399> the<00:26:19.520> state<00:26:19.760> route<00:26:20.039> to<00:26:20.440> the<00:26:20.720> specific 00:26:21.110 --> 00:26:21.120 align:start position:0% try from the state route to the specific 00:26:21.120 --> 00:26:22.710 align:start position:0% try from the state route to the specific account<00:26:21.320> we<00:26:21.440> care<00:26:21.640> about<00:26:22.399> and<00:26:22.480> then<00:26:22.600> the 00:26:22.710 --> 00:26:22.720 align:start position:0% account we care about and then the 00:26:22.720 --> 00:26:24.389 align:start position:0% account we care about and then the storage<00:26:23.039> proof<00:26:23.440> would<00:26:23.640> be<00:26:23.880> thought<00:26:24.080> of<00:26:24.279> as 00:26:24.389 --> 00:26:24.399 align:start position:0% storage proof would be thought of as 00:26:24.399 --> 00:26:26.870 align:start position:0% storage proof would be thought of as like<00:26:24.520> a<00:26:24.720> path<00:26:25.039> from<00:26:25.600> that<00:26:25.840> account's<00:26:26.480> storage 00:26:26.870 --> 00:26:26.880 align:start position:0% like a path from that account's storage 00:26:26.880 --> 00:26:30.070 align:start position:0% like a path from that account's storage route<00:26:27.320> to<00:26:27.799> uh<00:26:27.919> the<00:26:28.000> St<00:26:28.559> location<00:26:29.120> that<00:26:29.279> should 00:26:30.070 --> 00:26:30.080 align:start position:0% route to uh the St location that should 00:26:30.080 --> 00:26:32.230 align:start position:0% route to uh the St location that should that<00:26:30.240> exists<00:26:30.559> at<00:26:30.720> storage<00:26:31.120> key<00:26:31.720> and<00:26:31.880> should<00:26:32.080> be 00:26:32.230 --> 00:26:32.240 align:start position:0% that exists at storage key and should be 00:26:32.240 --> 00:26:38.470 align:start position:0% that exists at storage key and should be storing<00:26:32.760> storage 00:26:38.470 --> 00:26:38.480 align:start position:0% 00:26:38.480 --> 00:26:41.430 align:start position:0% value<00:26:39.480> so<00:26:39.640> it<00:26:39.760> should<00:26:39.919> be<00:26:40.159> noted<00:26:40.679> that<00:26:41.039> all<00:26:41.159> of 00:26:41.430 --> 00:26:41.440 align:start position:0% value so it should be noted that all of 00:26:41.440 --> 00:26:44.710 align:start position:0% value so it should be noted that all of the<00:26:41.919> the<00:26:42.159> values<00:26:42.960> in<00:26:43.720> um<00:26:43.880> the<00:26:43.960> state<00:26:44.279> TR<00:26:44.520> are 00:26:44.710 --> 00:26:44.720 align:start position:0% the the values in um the state TR are 00:26:44.720 --> 00:26:46.630 align:start position:0% the the values in um the state TR are keyed<00:26:45.120> by<00:26:45.279> the<00:26:45.480> hash<00:26:45.880> of<00:26:46.000> the<00:26:46.159> ethereum 00:26:46.630 --> 00:26:46.640 align:start position:0% keyed by the hash of the ethereum 00:26:46.640 --> 00:26:48.669 align:start position:0% keyed by the hash of the ethereum address<00:26:46.919> of<00:26:47.039> that<00:26:47.240> account<00:26:48.080> so<00:26:48.480> that's<00:26:48.600> what 00:26:48.669 --> 00:26:48.679 align:start position:0% address of that account so that's what 00:26:48.679 --> 00:26:50.830 align:start position:0% address of that account so that's what we're<00:26:48.840> doing<00:26:49.120> here<00:26:49.440> we're<00:26:49.919> uh<00:26:50.080> deriving<00:26:50.679> the 00:26:50.830 --> 00:26:50.840 align:start position:0% we're doing here we're uh deriving the 00:26:50.840 --> 00:26:53.190 align:start position:0% we're doing here we're uh deriving the account<00:26:51.159> key<00:26:52.039> and<00:26:52.159> then<00:26:52.360> using<00:26:52.679> that<00:26:52.960> we<00:26:53.080> can 00:26:53.190 --> 00:26:53.200 align:start position:0% account key and then using that we can 00:26:53.200 --> 00:26:55.669 align:start position:0% account key and then using that we can do<00:26:53.360> a<00:26:53.520> merry.<00:26:54.440> getet<00:26:54.720> to<00:26:55.120> uh<00:26:55.320> return<00:26:55.520> an 00:26:55.669 --> 00:26:55.679 align:start position:0% do a merry. getet to uh return an 00:26:55.679 --> 00:26:57.909 align:start position:0% do a merry. getet to uh return an encoded<00:26:56.159> account<00:26:57.039> an<00:26:57.200> encoded<00:26:57.600> account<00:26:57.799> is 00:26:57.909 --> 00:26:57.919 align:start position:0% encoded account an encoded account is 00:26:57.919 --> 00:26:59.750 align:start position:0% encoded account an encoded account is basically<00:26:58.640> an<00:26:58.760> encoded<00:26:59.159> array<00:26:59.520> of<00:26:59.640> the 00:26:59.750 --> 00:26:59.760 align:start position:0% basically an encoded array of the 00:26:59.760 --> 00:27:01.149 align:start position:0% basically an encoded array of the account<00:27:00.039> metadata<00:27:00.600> that<00:27:00.679> I<00:27:00.799> went<00:27:00.960> through<00:27:01.080> in 00:27:01.149 --> 00:27:01.159 align:start position:0% account metadata that I went through in 00:27:01.159 --> 00:27:03.710 align:start position:0% account metadata that I went through in the<00:27:01.279> slides<00:27:01.600> earlier<00:27:02.039> that<00:27:02.240> have<00:27:02.640> the<00:27:02.799> the<00:27:02.919> kns 00:27:03.710 --> 00:27:03.720 align:start position:0% the slides earlier that have the the kns 00:27:03.720 --> 00:27:06.269 align:start position:0% the slides earlier that have the the kns the<00:27:03.840> balance<00:27:04.279> the<00:27:04.360> storage<00:27:04.679> route<00:27:04.960> Etc<00:27:05.919> so 00:27:06.269 --> 00:27:06.279 align:start position:0% the balance the storage route Etc so 00:27:06.279 --> 00:27:07.669 align:start position:0% the balance the storage route Etc so from<00:27:06.520> that<00:27:06.679> we<00:27:06.799> can<00:27:06.960> extract<00:27:07.279> the<00:27:07.360> storage 00:27:07.669 --> 00:27:07.679 align:start position:0% from that we can extract the storage 00:27:07.679 --> 00:27:09.430 align:start position:0% from that we can extract the storage route<00:27:08.120> and<00:27:08.200> then<00:27:08.320> using<00:27:08.600> the<00:27:08.679> storage<00:27:09.000> route 00:27:09.430 --> 00:27:09.440 align:start position:0% route and then using the storage route 00:27:09.440 --> 00:27:12.350 align:start position:0% route and then using the storage route we<00:27:09.520> can<00:27:09.760> verify<00:27:10.760> that<00:27:10.960> storage<00:27:11.360> location 00:27:12.350 --> 00:27:12.360 align:start position:0% we can verify that storage location 00:27:12.360 --> 00:27:14.470 align:start position:0% we can verify that storage location using<00:27:12.799> the<00:27:12.919> storage<00:27:13.279> proof<00:27:13.600> that<00:27:13.760> exists<00:27:14.279> in 00:27:14.470 --> 00:27:14.480 align:start position:0% using the storage proof that exists in 00:27:14.480 --> 00:27:16.269 align:start position:0% using the storage proof that exists in the<00:27:14.640> account<00:27:14.880> proof<00:27:15.120> progams<00:27:15.640> struct<00:27:16.080> that<00:27:16.200> I 00:27:16.269 --> 00:27:16.279 align:start position:0% the account proof progams struct that I 00:27:16.279 --> 00:27:18.110 align:start position:0% the account proof progams struct that I just<00:27:16.399> went 00:27:18.110 --> 00:27:18.120 align:start position:0% just went 00:27:18.120 --> 00:27:20.230 align:start position:0% just went through<00:27:19.120> so<00:27:19.279> at<00:27:19.360> a<00:27:19.520> high<00:27:19.679> level<00:27:19.919> that's<00:27:20.080> how 00:27:20.230 --> 00:27:20.240 align:start position:0% through so at a high level that's how 00:27:20.240 --> 00:27:22.990 align:start position:0% through so at a high level that's how that's<00:27:20.880> working<00:27:21.880> um<00:27:22.120> there's<00:27:22.279> a<00:27:22.440> directory<00:27:22.840> in 00:27:22.990 --> 00:27:23.000 align:start position:0% that's working um there's a directory in 00:27:23.000 --> 00:27:24.990 align:start position:0% that's working um there's a directory in here<00:27:23.200> called<00:27:23.440> provs<00:27:24.320> this<00:27:24.480> is<00:27:24.720> what<00:27:24.840> we're 00:27:24.990 --> 00:27:25.000 align:start position:0% here called provs this is what we're 00:27:25.000 --> 00:27:26.310 align:start position:0% here called provs this is what we're about<00:27:25.120> to<00:27:25.279> implement<00:27:25.679> so<00:27:25.840> we'll<00:27:25.960> be<00:27:26.080> coming 00:27:26.310 --> 00:27:26.320 align:start position:0% about to implement so we'll be coming 00:27:26.320 --> 00:27:29.789 align:start position:0% about to implement so we'll be coming back<00:27:26.440> to<00:27:26.559> that<00:27:26.720> in<00:27:26.799> a<00:27:26.919> second 00:27:29.789 --> 00:27:29.799 align:start position:0% back to that in a second 00:27:29.799 --> 00:27:31.350 align:start position:0% back to that in a second just<00:27:30.000> real<00:27:30.279> quick<00:27:30.520> before<00:27:30.720> we<00:27:30.919> dive<00:27:31.080> into<00:27:31.279> the 00:27:31.350 --> 00:27:31.360 align:start position:0% just real quick before we dive into the 00:27:31.360 --> 00:27:33.070 align:start position:0% just real quick before we dive into the implementation<00:27:31.880> details<00:27:32.320> there<00:27:32.760> um<00:27:32.919> I<00:27:32.960> want 00:27:33.070 --> 00:27:33.080 align:start position:0% implementation details there um I want 00:27:33.080 --> 00:27:35.190 align:start position:0% implementation details there um I want to<00:27:33.200> do<00:27:33.679> just<00:27:33.799> a<00:27:34.000> quick<00:27:34.399> summary<00:27:34.799> of<00:27:34.960> what 00:27:35.190 --> 00:27:35.200 align:start position:0% to do just a quick summary of what 00:27:35.200 --> 00:27:37.549 align:start position:0% to do just a quick summary of what offchain<00:27:35.679> services<00:27:36.039> are<00:27:36.200> running<00:27:36.520> here<00:27:37.360> the 00:27:37.549 --> 00:27:37.559 align:start position:0% offchain services are running here the 00:27:37.559 --> 00:27:40.269 align:start position:0% offchain services are running here the demo<00:27:38.120> is<00:27:38.360> the<00:27:38.600> app<00:27:38.960> that<00:27:39.520> uh<00:27:39.640> is<00:27:39.799> facilitating 00:27:40.269 --> 00:27:40.279 align:start position:0% demo is the app that uh is facilitating 00:27:40.279 --> 00:27:42.470 align:start position:0% demo is the app that uh is facilitating the<00:27:40.399> nft<00:27:40.760> mints<00:27:41.159> so<00:27:41.320> we'll<00:27:41.519> be<00:27:41.880> implementing 00:27:42.470 --> 00:27:42.480 align:start position:0% the nft mints so we'll be implementing 00:27:42.480 --> 00:27:44.909 align:start position:0% the nft mints so we'll be implementing some<00:27:42.720> details<00:27:43.200> in<00:27:43.360> this<00:27:43.679> directory<00:27:44.679> um<00:27:44.799> but 00:27:44.909 --> 00:27:44.919 align:start position:0% some details in this directory um but 00:27:44.919 --> 00:27:46.149 align:start position:0% some details in this directory um but then<00:27:45.039> these<00:27:45.200> other<00:27:45.399> two<00:27:45.559> directories<00:27:46.000> are 00:27:46.149 --> 00:27:46.159 align:start position:0% then these other two directories are 00:27:46.159 --> 00:27:47.830 align:start position:0% then these other two directories are surrounding<00:27:46.640> services<00:27:47.120> that<00:27:47.200> are<00:27:47.360> needed<00:27:47.640> for 00:27:47.830 --> 00:27:47.840 align:start position:0% surrounding services that are needed for 00:27:47.840 --> 00:27:50.470 align:start position:0% surrounding services that are needed for the<00:27:48.120> full<00:27:48.440> system<00:27:48.720> to<00:27:48.880> run<00:27:49.360> locally<00:27:50.360> the 00:27:50.470 --> 00:27:50.480 align:start position:0% the full system to run locally the 00:27:50.480 --> 00:27:52.710 align:start position:0% the full system to run locally the Sinker<00:27:50.880> is<00:27:51.000> in<00:27:51.159> charge<00:27:51.440> of<00:27:51.679> sharing<00:27:52.440> State 00:27:52.710 --> 00:27:52.720 align:start position:0% Sinker is in charge of sharing State 00:27:52.720 --> 00:27:54.710 align:start position:0% Sinker is in charge of sharing State representations<00:27:53.519> bidirectionally<00:27:54.279> between 00:27:54.710 --> 00:27:54.720 align:start position:0% representations bidirectionally between 00:27:54.720 --> 00:27:57.669 align:start position:0% representations bidirectionally between the<00:27:54.840> mack<00:27:55.080> L1<00:27:55.559> and<00:27:55.679> the<00:27:55.760> mack<00:27:56.360> l2s<00:27:57.360> um<00:27:57.480> and<00:27:57.559> then 00:27:57.669 --> 00:27:57.679 align:start position:0% the mack L1 and the mack l2s um and then 00:27:57.679 --> 00:27:59.470 align:start position:0% the mack L1 and the mack l2s um and then the<00:27:57.760> fulfill<00:27:58.320> is<00:27:58.399> the<00:27:58.519> offchain<00:27:59.000> agent<00:27:59.320> that's 00:27:59.470 --> 00:27:59.480 align:start position:0% the fulfill is the offchain agent that's 00:27:59.480 --> 00:28:01.630 align:start position:0% the fulfill is the offchain agent that's listening<00:27:59.760> for<00:27:59.960> requests<00:28:00.720> and<00:28:01.000> will<00:28:01.519> uh 00:28:01.630 --> 00:28:01.640 align:start position:0% listening for requests and will uh 00:28:01.640 --> 00:28:03.950 align:start position:0% listening for requests and will uh validate<00:28:02.000> the<00:28:02.200> request<00:28:02.760> and<00:28:03.320> ensure<00:28:03.679> that<00:28:03.799> the 00:28:03.950 --> 00:28:03.960 align:start position:0% validate the request and ensure that the 00:28:03.960 --> 00:28:08.190 align:start position:0% validate the request and ensure that the incentive<00:28:04.840> uh<00:28:05.080> is<00:28:05.360> is<00:28:05.519> enough<00:28:05.799> to<00:28:06.679> um<00:28:07.519> to 00:28:08.190 --> 00:28:08.200 align:start position:0% incentive uh is is enough to um to 00:28:08.200 --> 00:28:10.430 align:start position:0% incentive uh is is enough to um to compensate<00:28:08.640> them<00:28:08.760> for<00:28:08.919> their<00:28:09.120> time<00:28:10.000> and<00:28:10.159> we'll 00:28:10.430 --> 00:28:10.440 align:start position:0% compensate them for their time and we'll 00:28:10.440 --> 00:28:11.870 align:start position:0% compensate them for their time and we'll respond<00:28:10.840> accordingly<00:28:11.320> and<00:28:11.440> submit<00:28:11.720> the 00:28:11.870 --> 00:28:11.880 align:start position:0% respond accordingly and submit the 00:28:11.880 --> 00:28:14.149 align:start position:0% respond accordingly and submit the request<00:28:12.320> and<00:28:12.480> then<00:28:12.760> we'll<00:28:12.960> be<00:28:13.120> generating<00:28:13.880> a 00:28:14.149 --> 00:28:14.159 align:start position:0% request and then we'll be generating a 00:28:14.159 --> 00:28:15.590 align:start position:0% request and then we'll be generating a full<00:28:14.399> nested<00:28:14.720> storage<00:28:15.039> proof<00:28:15.279> that<00:28:15.399> gets 00:28:15.590 --> 00:28:15.600 align:start position:0% full nested storage proof that gets 00:28:15.600 --> 00:28:17.430 align:start position:0% full nested storage proof that gets validated<00:28:16.039> against<00:28:16.279> the<00:28:16.440> contract<00:28:16.919> we're 00:28:17.430 --> 00:28:17.440 align:start position:0% validated against the contract we're 00:28:17.440 --> 00:28:19.830 align:start position:0% validated against the contract we're about<00:28:17.679> to<00:28:18.399> implement<00:28:19.279> and<00:28:19.399> if<00:28:19.519> that<00:28:19.640> checks 00:28:19.830 --> 00:28:19.840 align:start position:0% about to implement and if that checks 00:28:19.840 --> 00:28:21.029 align:start position:0% about to implement and if that checks out<00:28:20.000> we'll<00:28:20.120> be<00:28:20.200> able<00:28:20.360> to<00:28:20.440> see<00:28:20.559> the<00:28:20.640> fulfiller 00:28:21.029 --> 00:28:21.039 align:start position:0% out we'll be able to see the fulfiller 00:28:21.039 --> 00:28:26.430 align:start position:0% out we'll be able to see the fulfiller claiming<00:28:21.360> its<00:28:21.519> rewards<00:28:21.960> in<00:28:22.159> in<00:28:22.279> real 00:28:26.430 --> 00:28:26.440 align:start position:0% 00:28:26.440 --> 00:28:30.070 align:start position:0% time<00:28:27.440> so<00:28:27.679> with<00:28:27.799> all<00:28:27.919> of<00:28:28.240> that<00:28:28.399> being<00:28:28.880> said<00:28:29.720> um 00:28:30.070 --> 00:28:30.080 align:start position:0% time so with all of that being said um 00:28:30.080 --> 00:28:32.029 align:start position:0% time so with all of that being said um we<00:28:30.240> have<00:28:30.480> enough<00:28:30.760> here<00:28:30.960> to<00:28:31.200> dive<00:28:31.440> into 00:28:32.029 --> 00:28:32.039 align:start position:0% we have enough here to dive into 00:28:32.039 --> 00:28:35.789 align:start position:0% we have enough here to dive into beginning<00:28:32.360> to<00:28:32.480> implement<00:28:32.840> a<00:28:32.960> pro<00:28:33.799> contract 00:28:35.789 --> 00:28:35.799 align:start position:0% beginning to implement a pro contract 00:28:35.799 --> 00:28:39.269 align:start position:0% beginning to implement a pro contract um<00:28:36.799> I<00:28:37.000> have<00:28:37.360> a<00:28:37.480> handful<00:28:37.840> of<00:28:38.000> imports<00:28:38.919> just<00:28:39.080> set 00:28:39.269 --> 00:28:39.279 align:start position:0% um I have a handful of imports just set 00:28:39.279 --> 00:28:41.630 align:start position:0% um I have a handful of imports just set up<00:28:39.440> in<00:28:39.559> here<00:28:39.720> already<00:28:40.159> just<00:28:40.320> to<00:28:41.000> save<00:28:41.279> the<00:28:41.440> time 00:28:41.630 --> 00:28:41.640 align:start position:0% up in here already just to save the time 00:28:41.640 --> 00:28:44.470 align:start position:0% up in here already just to save the time from<00:28:41.919> typing<00:28:42.200> them<00:28:42.360> out<00:28:43.360> um<00:28:43.799> you'll<00:28:44.120> notice 00:28:44.470 --> 00:28:44.480 align:start position:0% from typing them out um you'll notice 00:28:44.480 --> 00:28:47.590 align:start position:0% from typing them out um you'll notice the<00:28:44.640> first<00:28:44.960> import<00:28:45.399> is<00:28:45.519> an<00:28:45.679> iover<00:28:46.600> interface 00:28:47.590 --> 00:28:47.600 align:start position:0% the first import is an iover interface 00:28:47.600 --> 00:28:50.669 align:start position:0% the first import is an iover interface uh<00:28:47.720> so<00:28:47.880> we<00:28:48.000> can<00:28:48.159> start<00:28:48.679> here<00:28:49.159> taking<00:28:49.399> a<00:28:49.679> look 00:28:50.669 --> 00:28:50.679 align:start position:0% uh so we can start here taking a look 00:28:50.679 --> 00:28:53.269 align:start position:0% uh so we can start here taking a look and<00:28:51.200> what<00:28:51.320> it<00:28:51.480> defines<00:28:51.919> is<00:28:52.080> a<00:28:52.200> single<00:28:52.519> function 00:28:53.269 --> 00:28:53.279 align:start position:0% and what it defines is a single function 00:28:53.279 --> 00:28:54.990 align:start position:0% and what it defines is a single function and<00:28:53.480> this<00:28:53.559> is<00:28:53.840> all<00:28:54.120> the<00:28:54.279> approver<00:28:54.640> contract 00:28:54.990 --> 00:28:55.000 align:start position:0% and this is all the approver contract 00:28:55.000 --> 00:28:56.990 align:start position:0% and this is all the approver contract needs<00:28:55.399> because<00:28:55.600> this<00:28:55.679> is<00:28:55.799> the<00:28:56.360> the<00:28:56.480> function 00:28:56.990 --> 00:28:57.000 align:start position:0% needs because this is the the function 00:28:57.000 --> 00:28:59.549 align:start position:0% needs because this is the the function that<00:28:57.519> the<00:28:57.679> reward<00:28:58.159> claim<00:28:58.440> function<00:28:58.919> from<00:28:59.360> the 00:28:59.549 --> 00:28:59.559 align:start position:0% that the reward claim function from the 00:28:59.559 --> 00:29:02.269 align:start position:0% that the reward claim function from the outbox<00:29:00.080> contract<00:29:00.440> is<00:29:00.559> going<00:29:00.760> to<00:29:00.960> hit<00:29:01.840> so<00:29:02.159> we 00:29:02.269 --> 00:29:02.279 align:start position:0% outbox contract is going to hit so we 00:29:02.279 --> 00:29:04.669 align:start position:0% outbox contract is going to hit so we can<00:29:02.480> start<00:29:02.840> by<00:29:03.480> literally<00:29:03.919> just<00:29:04.159> copying<00:29:04.519> this 00:29:04.669 --> 00:29:04.679 align:start position:0% can start by literally just copying this 00:29:04.679 --> 00:29:07.310 align:start position:0% can start by literally just copying this entire<00:29:05.039> thing<00:29:05.399> into<00:29:06.360> um<00:29:06.600> into<00:29:06.799> our<00:29:06.960> prover 00:29:07.310 --> 00:29:07.320 align:start position:0% entire thing into um into our prover 00:29:07.320 --> 00:29:09.549 align:start position:0% entire thing into um into our prover contract<00:29:08.039> to<00:29:08.279> initiate<00:29:08.840> the<00:29:09.000> implementation 00:29:09.549 --> 00:29:09.559 align:start position:0% contract to initiate the implementation 00:29:09.559 --> 00:29:12.830 align:start position:0% contract to initiate the implementation of<00:29:09.679> that<00:29:10.039> function<00:29:11.039> so<00:29:11.279> I<00:29:11.360> will<00:29:12.240> replace<00:29:12.640> this 00:29:12.830 --> 00:29:12.840 align:start position:0% of that function so I will replace this 00:29:12.840 --> 00:29:16.190 align:start position:0% of that function so I will replace this comment<00:29:13.679> with<00:29:14.080> that<00:29:14.360> function<00:29:15.200> declaration 00:29:16.190 --> 00:29:16.200 align:start position:0% comment with that function declaration 00:29:16.200 --> 00:29:21.149 align:start position:0% comment with that function declaration and<00:29:16.760> uh<00:29:17.240> add<00:29:17.440> empty<00:29:17.720> curly<00:29:18.000> braces<00:29:18.840> here<00:29:20.000> so<00:29:21.000> oh 00:29:21.149 --> 00:29:21.159 align:start position:0% and uh add empty curly braces here so oh 00:29:21.159 --> 00:29:23.070 align:start position:0% and uh add empty curly braces here so oh and<00:29:21.240> then<00:29:21.320> we<00:29:21.399> can<00:29:21.519> extend<00:29:21.799> that<00:29:21.880> interface<00:29:22.799> is 00:29:23.070 --> 00:29:23.080 align:start position:0% and then we can extend that interface is 00:29:23.080 --> 00:29:25.149 align:start position:0% and then we can extend that interface is I 00:29:25.149 --> 00:29:25.159 align:start position:0% I 00:29:25.159 --> 00:29:28.830 align:start position:0% I approver<00:29:26.159> to<00:29:27.080> take<00:29:27.240> a<00:29:27.559> quick<00:29:28.279> skim<00:29:28.679> through 00:29:28.830 --> 00:29:28.840 align:start position:0% approver to take a quick skim through 00:29:28.840 --> 00:29:30.110 align:start position:0% approver to take a quick skim through the<00:29:28.960> comments<00:29:29.279> here<00:29:29.480> that<00:29:29.559> are<00:29:29.720> explaining 00:29:30.110 --> 00:29:30.120 align:start position:0% the comments here that are explaining 00:29:30.120 --> 00:29:32.909 align:start position:0% the comments here that are explaining what<00:29:30.279> validate<00:29:30.679> proof<00:29:30.919> should<00:29:31.279> even<00:29:31.480> be<00:29:31.919> doing 00:29:32.909 --> 00:29:32.919 align:start position:0% what validate proof should even be doing 00:29:32.919 --> 00:29:34.190 align:start position:0% what validate proof should even be doing um<00:29:33.039> it<00:29:33.200> validates<00:29:33.559> storage<00:29:33.840> proofs<00:29:34.080> and 00:29:34.190 --> 00:29:34.200 align:start position:0% um it validates storage proofs and 00:29:34.200 --> 00:29:36.630 align:start position:0% um it validates storage proofs and verifies<00:29:34.600> fulfillment<00:29:35.360> okay<00:29:35.559> makes<00:29:35.799> sense<00:29:36.519> it 00:29:36.630 --> 00:29:36.640 align:start position:0% verifies fulfillment okay makes sense it 00:29:36.640 --> 00:29:38.190 align:start position:0% verifies fulfillment okay makes sense it should<00:29:36.840> revert<00:29:37.279> if<00:29:37.399> the<00:29:37.519> storage<00:29:37.840> proof<00:29:38.039> is 00:29:38.190 --> 00:29:38.200 align:start position:0% should revert if the storage proof is 00:29:38.200 --> 00:29:40.470 align:start position:0% should revert if the storage proof is invalid<00:29:38.919> also<00:29:39.159> makes<00:29:39.440> sense<00:29:40.159> it<00:29:40.240> should 00:29:40.470 --> 00:29:40.480 align:start position:0% invalid also makes sense it should 00:29:40.480 --> 00:29:42.870 align:start position:0% invalid also makes sense it should revert<00:29:41.039> if<00:29:41.240> fulfillment<00:29:41.720> info<00:29:42.039> is<00:29:42.159> not<00:29:42.360> found 00:29:42.870 --> 00:29:42.880 align:start position:0% revert if fulfillment info is not found 00:29:42.880 --> 00:29:45.710 align:start position:0% revert if fulfillment info is not found at<00:29:43.120> inbox<00:29:43.640> contract<00:29:44.080> storage<00:29:44.360> key<00:29:44.840> on<00:29:45.360> the 00:29:45.710 --> 00:29:45.720 align:start position:0% at inbox contract storage key on the 00:29:45.720 --> 00:29:49.870 align:start position:0% at inbox contract storage key on the specified<00:29:46.159> inbox<00:29:46.919> contract<00:29:47.919> um<00:29:48.279> that<00:29:48.760> is<00:29:49.760> kind 00:29:49.870 --> 00:29:49.880 align:start position:0% specified inbox contract um that is kind 00:29:49.880 --> 00:29:51.470 align:start position:0% specified inbox contract um that is kind of<00:29:50.039> interesting<00:29:50.480> here<00:29:50.720> it<00:29:50.799> should<00:29:50.960> be<00:29:51.080> noted 00:29:51.470 --> 00:29:51.480 align:start position:0% of interesting here it should be noted 00:29:51.480 --> 00:29:53.710 align:start position:0% of interesting here it should be noted that<00:29:51.720> the<00:29:52.399> the<00:29:52.519> storage<00:29:52.919> key<00:29:53.399> like<00:29:53.519> I<00:29:53.600> was 00:29:53.710 --> 00:29:53.720 align:start position:0% that the the storage key like I was 00:29:53.720 --> 00:29:56.190 align:start position:0% that the the storage key like I was saying<00:29:54.039> before<00:29:54.480> is<00:29:54.720> derivable<00:29:55.440> from<00:29:56.080> a 00:29:56.190 --> 00:29:56.200 align:start position:0% saying before is derivable from a 00:29:56.200 --> 00:29:58.029 align:start position:0% saying before is derivable from a network<00:29:56.679> that<00:29:56.840> doesn't<00:29:57.200> actually<00:29:57.559> have<00:29:57.799> cont 00:29:58.029 --> 00:29:58.039 align:start position:0% network that doesn't actually have cont 00:29:58.039 --> 00:30:00.470 align:start position:0% network that doesn't actually have cont context<00:29:58.440> of<00:29:58.559> the<00:29:58.679> destination<00:29:59.200> chain<00:30:00.159> and 00:30:00.470 --> 00:30:00.480 align:start position:0% context of the destination chain and 00:30:00.480 --> 00:30:02.669 align:start position:0% context of the destination chain and because<00:30:00.679> of<00:30:00.840> that<00:30:01.039> this<00:30:01.120> is<00:30:01.279> being<00:30:01.519> done<00:30:02.039> in 00:30:02.669 --> 00:30:02.679 align:start position:0% because of that this is being done in 00:30:02.679 --> 00:30:05.029 align:start position:0% because of that this is being done in the<00:30:03.360> um<00:30:03.519> outbox<00:30:04.039> contract<00:30:04.480> before<00:30:04.880> this 00:30:05.029 --> 00:30:05.039 align:start position:0% the um outbox contract before this 00:30:05.039 --> 00:30:06.950 align:start position:0% the um outbox contract before this function<00:30:05.320> is<00:30:05.519> hit<00:30:06.039> so<00:30:06.200> this<00:30:06.320> is<00:30:06.440> not<00:30:06.600> coming 00:30:06.950 --> 00:30:06.960 align:start position:0% function is hit so this is not coming 00:30:06.960 --> 00:30:09.029 align:start position:0% function is hit so this is not coming from<00:30:07.440> the<00:30:07.559> offchain<00:30:07.960> fulfiller<00:30:08.519> we<00:30:08.640> can<00:30:08.760> trust 00:30:09.029 --> 00:30:09.039 align:start position:0% from the offchain fulfiller we can trust 00:30:09.039 --> 00:30:10.269 align:start position:0% from the offchain fulfiller we can trust this 00:30:10.269 --> 00:30:10.279 align:start position:0% this 00:30:10.279 --> 00:30:14.070 align:start position:0% this value<00:30:11.279> lastly<00:30:12.159> it<00:30:12.240> should<00:30:12.519> revert<00:30:13.200> if<00:30:13.559> the<00:30:13.919> uh 00:30:14.070 --> 00:30:14.080 align:start position:0% value lastly it should revert if the uh 00:30:14.080 --> 00:30:16.190 align:start position:0% value lastly it should revert if the uh fulfillment<00:30:14.559> info<00:30:14.840> Tim<00:30:15.080> stamp<00:30:15.399> is<00:30:15.600> less<00:30:15.880> than 00:30:16.190 --> 00:30:16.200 align:start position:0% fulfillment info Tim stamp is less than 00:30:16.200 --> 00:30:18.110 align:start position:0% fulfillment info Tim stamp is less than the<00:30:16.360> finality<00:30:16.880> delay<00:30:17.159> seconds<00:30:17.679> amount<00:30:17.919> of 00:30:18.110 --> 00:30:18.120 align:start position:0% the finality delay seconds amount of 00:30:18.120 --> 00:30:20.509 align:start position:0% the finality delay seconds amount of time<00:30:18.600> from<00:30:18.760> the<00:30:18.880> current<00:30:19.240> destination<00:30:19.720> chain 00:30:20.509 --> 00:30:20.519 align:start position:0% time from the current destination chain 00:30:20.519 --> 00:30:23.070 align:start position:0% time from the current destination chain block<00:30:20.840> Tim<00:30:21.080> stamp<00:30:21.720> so<00:30:21.880> this<00:30:22.000> is<00:30:22.200> that<00:30:22.640> that<00:30:22.919> uh 00:30:23.070 --> 00:30:23.080 align:start position:0% block Tim stamp so this is that that uh 00:30:23.080 --> 00:30:25.110 align:start position:0% block Tim stamp so this is that that uh destination<00:30:23.600> chain<00:30:23.880> reor<00:30:24.480> protection<00:30:24.960> that<00:30:25.039> I 00:30:25.110 --> 00:30:25.120 align:start position:0% destination chain reor protection that I 00:30:25.120 --> 00:30:28.190 align:start position:0% destination chain reor protection that I was<00:30:25.240> mentioning<00:30:25.720> earlier<00:30:26.720> um<00:30:27.519> we<00:30:27.640> need<00:30:27.760> to 00:30:28.190 --> 00:30:28.200 align:start position:0% was mentioning earlier um we need to 00:30:28.200 --> 00:30:30.230 align:start position:0% was mentioning earlier um we need to ensure<00:30:28.679> that<00:30:29.000> the<00:30:29.200> finality<00:30:29.600> delay<00:30:29.840> second<00:30:30.120> is 00:30:30.230 --> 00:30:30.240 align:start position:0% ensure that the finality delay second is 00:30:30.240 --> 00:30:32.750 align:start position:0% ensure that the finality delay second is not<00:30:30.360> currently<00:30:30.919> like<00:30:31.039> still<00:30:31.240> in 00:30:32.750 --> 00:30:32.760 align:start position:0% not currently like still in 00:30:32.760 --> 00:30:34.950 align:start position:0% not currently like still in progress<00:30:33.760> then<00:30:33.880> we<00:30:34.000> have<00:30:34.080> a<00:30:34.200> note<00:30:34.480> about<00:30:34.840> that 00:30:34.950 --> 00:30:34.960 align:start position:0% progress then we have a note about that 00:30:34.960 --> 00:30:36.389 align:start position:0% progress then we have a note about that the<00:30:35.080> implementation<00:30:35.679> should<00:30:35.960> vary<00:30:36.200> by 00:30:36.389 --> 00:30:36.399 align:start position:0% the implementation should vary by 00:30:36.399 --> 00:30:39.509 align:start position:0% the implementation should vary by destination<00:30:37.279> L2<00:30:38.279> this<00:30:38.360> is<00:30:38.559> due<00:30:38.799> to<00:30:39.159> the<00:30:39.399> the 00:30:39.509 --> 00:30:39.519 align:start position:0% destination L2 this is due to the the 00:30:39.519 --> 00:30:42.310 align:start position:0% destination L2 this is due to the the lack<00:30:39.679> of<00:30:39.799> standardization<00:30:40.720> around<00:30:41.120> how<00:30:41.360> l2s 00:30:42.310 --> 00:30:42.320 align:start position:0% lack of standardization around how l2s 00:30:42.320 --> 00:30:43.990 align:start position:0% lack of standardization around how l2s uh<00:30:42.440> post<00:30:42.760> their<00:30:43.000> state<00:30:43.279> representations<00:30:43.840> to 00:30:43.990 --> 00:30:44.000 align:start position:0% uh post their state representations to 00:30:44.000 --> 00:30:47.789 align:start position:0% uh post their state representations to L1<00:30:44.399> like<00:30:44.519> I<00:30:44.600> was<00:30:44.960> saying<00:30:45.960> um<00:30:46.760> and<00:30:46.919> then<00:30:47.320> a<00:30:47.559> quick 00:30:47.789 --> 00:30:47.799 align:start position:0% L1 like I was saying um and then a quick 00:30:47.799 --> 00:30:49.509 align:start position:0% L1 like I was saying um and then a quick summary<00:30:48.279> of<00:30:48.440> the<00:30:48.559> input<00:30:48.840> parameters<00:30:49.279> that<00:30:49.360> we 00:30:49.509 --> 00:30:49.519 align:start position:0% summary of the input parameters that we 00:30:49.519 --> 00:30:51.509 align:start position:0% summary of the input parameters that we have<00:30:49.640> to<00:30:49.760> work<00:30:49.960> with<00:30:50.159> here<00:30:50.399> so<00:30:50.760> inbox<00:30:51.200> contract 00:30:51.509 --> 00:30:51.519 align:start position:0% have to work with here so inbox contract 00:30:51.519 --> 00:30:53.470 align:start position:0% have to work with here so inbox contract storage<00:30:51.799> key<00:30:52.440> I<00:30:52.519> just<00:30:52.640> kind<00:30:52.760> of<00:30:52.880> mentioned<00:30:53.360> is 00:30:53.470 --> 00:30:53.480 align:start position:0% storage key I just kind of mentioned is 00:30:53.480 --> 00:30:55.149 align:start position:0% storage key I just kind of mentioned is the<00:30:53.600> storage<00:30:53.960> location<00:30:54.519> in<00:30:54.600> the<00:30:54.720> inbox 00:30:55.149 --> 00:30:55.159 align:start position:0% the storage location in the inbox 00:30:55.159 --> 00:30:56.950 align:start position:0% the storage location in the inbox contract<00:30:55.480> on<00:30:55.600> the<00:30:55.720> destination<00:30:56.200> chain<00:30:56.799> where 00:30:56.950 --> 00:30:56.960 align:start position:0% contract on the destination chain where 00:30:56.960 --> 00:31:00.789 align:start position:0% contract on the destination chain where we<00:30:57.159> expect<00:30:57.600> the<00:30:58.159> uh<00:30:58.399> execution<00:30:58.919> receipt<00:30:59.240> to<00:30:59.799> be 00:31:00.789 --> 00:31:00.799 align:start position:0% we expect the uh execution receipt to be 00:31:00.799 --> 00:31:03.149 align:start position:0% we expect the uh execution receipt to be next<00:31:01.039> up<00:31:01.320> is<00:31:01.519> the<00:31:01.679> Fulfillment<00:31:02.200> info<00:31:03.000> um 00:31:03.149 --> 00:31:03.159 align:start position:0% next up is the Fulfillment info um 00:31:03.159 --> 00:31:06.470 align:start position:0% next up is the Fulfillment info um struct<00:31:03.679> so<00:31:03.919> this<00:31:04.120> is<00:31:04.519> that<00:31:05.080> uh<00:31:05.279> exact 00:31:06.470 --> 00:31:06.480 align:start position:0% struct so this is that uh exact 00:31:06.480 --> 00:31:08.669 align:start position:0% struct so this is that uh exact execution<00:31:07.480> uh<00:31:07.639> receipt<00:31:08.159> that<00:31:08.279> should<00:31:08.440> be 00:31:08.669 --> 00:31:08.679 align:start position:0% execution uh receipt that should be 00:31:08.679 --> 00:31:10.549 align:start position:0% execution uh receipt that should be existing<00:31:09.080> at<00:31:09.200> inbox<00:31:09.679> contract<00:31:10.000> storage<00:31:10.320> key 00:31:10.549 --> 00:31:10.559 align:start position:0% existing at inbox contract storage key 00:31:10.559 --> 00:31:13.430 align:start position:0% existing at inbox contract storage key on<00:31:10.639> the<00:31:10.799> destination<00:31:11.240> chains<00:31:11.760> inbox<00:31:12.440> contract 00:31:13.430 --> 00:31:13.440 align:start position:0% on the destination chains inbox contract 00:31:13.440 --> 00:31:15.750 align:start position:0% on the destination chains inbox contract then<00:31:13.600> we<00:31:13.720> have<00:31:13.960> the<00:31:14.120> initial<00:31:14.480> request<00:31:15.360> uh<00:31:15.639> that 00:31:15.750 --> 00:31:15.760 align:start position:0% then we have the initial request uh that 00:31:15.760 --> 00:31:18.590 align:start position:0% then we have the initial request uh that came<00:31:15.960> from<00:31:16.080> the<00:31:16.360> user<00:31:17.360> and<00:31:17.480> then<00:31:17.840> we<00:31:18.000> have<00:31:18.440> an 00:31:18.590 --> 00:31:18.600 align:start position:0% came from the user and then we have an 00:31:18.600 --> 00:31:21.590 align:start position:0% came from the user and then we have an arbitrarily<00:31:19.240> encoded<00:31:19.720> proof<00:31:20.000> data<00:31:20.320> bytes 00:31:21.590 --> 00:31:21.600 align:start position:0% arbitrarily encoded proof data bytes 00:31:21.600 --> 00:31:25.870 align:start position:0% arbitrarily encoded proof data bytes array<00:31:22.600> this<00:31:22.720> is<00:31:23.200> because<00:31:24.000> of<00:31:24.159> the<00:31:24.320> fact<00:31:24.880> that 00:31:25.870 --> 00:31:25.880 align:start position:0% array this is because of the fact that 00:31:25.880 --> 00:31:27.909 align:start position:0% array this is because of the fact that um<00:31:26.440> like<00:31:26.559> I<00:31:26.639> was<00:31:26.760> saying<00:31:27.039> before<00:31:27.440> the<00:31:27.559> lack<00:31:27.679> of 00:31:27.909 --> 00:31:27.919 align:start position:0% um like I was saying before the lack of 00:31:27.919 --> 00:31:29.629 align:start position:0% um like I was saying before the lack of standardization<00:31:28.720> around<00:31:29.000> the<00:31:29.120> state<00:31:29.519> the 00:31:29.629 --> 00:31:29.639 align:start position:0% standardization around the state the 00:31:29.639 --> 00:31:32.669 align:start position:0% standardization around the state the state<00:31:30.120> posting<00:31:31.120> um<00:31:31.840> there<00:31:32.039> could<00:31:32.200> be<00:31:32.320> subtle 00:31:32.669 --> 00:31:32.679 align:start position:0% state posting um there could be subtle 00:31:32.679 --> 00:31:34.870 align:start position:0% state posting um there could be subtle differences<00:31:33.360> in<00:31:33.880> the<00:31:34.039> exact<00:31:34.399> data<00:31:34.679> that<00:31:34.760> is 00:31:34.870 --> 00:31:34.880 align:start position:0% differences in the exact data that is 00:31:34.880 --> 00:31:36.310 align:start position:0% differences in the exact data that is needed<00:31:35.120> for<00:31:35.240> the<00:31:35.360> prover<00:31:35.639> to<00:31:35.760> verify<00:31:36.159> that 00:31:36.310 --> 00:31:36.320 align:start position:0% needed for the prover to verify that 00:31:36.320 --> 00:31:38.509 align:start position:0% needed for the prover to verify that state<00:31:37.000> so<00:31:37.279> there's<00:31:37.480> no<00:31:37.679> enforced<00:31:38.159> structure 00:31:38.509 --> 00:31:38.519 align:start position:0% state so there's no enforced structure 00:31:38.519 --> 00:31:40.470 align:start position:0% state so there's no enforced structure to<00:31:38.679> this<00:31:38.880> data<00:31:39.200> at<00:31:39.320> the<00:31:39.399> outbox<00:31:39.880> level<00:31:40.200> this<00:31:40.320> is 00:31:40.470 --> 00:31:40.480 align:start position:0% to this data at the outbox level this is 00:31:40.480 --> 00:31:42.549 align:start position:0% to this data at the outbox level this is being<00:31:40.760> implemented<00:31:41.279> here<00:31:41.480> within<00:31:41.679> the<00:31:41.799> prover 00:31:42.549 --> 00:31:42.559 align:start position:0% being implemented here within the prover 00:31:42.559 --> 00:31:44.350 align:start position:0% being implemented here within the prover so<00:31:42.720> we'll<00:31:42.880> start<00:31:43.080> to<00:31:43.200> set<00:31:43.399> that<00:31:43.559> up<00:31:43.919> uh<00:31:44.080> in<00:31:44.200> just 00:31:44.350 --> 00:31:44.360 align:start position:0% so we'll start to set that up uh in just 00:31:44.360 --> 00:31:45.789 align:start position:0% so we'll start to set that up uh in just a 00:31:45.789 --> 00:31:45.799 align:start position:0% a 00:31:45.799 --> 00:31:48.029 align:start position:0% a moment<00:31:46.799> okay<00:31:46.919> so<00:31:47.080> with<00:31:47.240> all<00:31:47.360> of<00:31:47.519> that<00:31:47.720> gone 00:31:48.029 --> 00:31:48.039 align:start position:0% moment okay so with all of that gone 00:31:48.039 --> 00:31:49.990 align:start position:0% moment okay so with all of that gone through<00:31:48.360> we<00:31:48.519> have<00:31:48.760> enough<00:31:49.120> here<00:31:49.399> to<00:31:49.600> start<00:31:49.799> to 00:31:49.990 --> 00:31:50.000 align:start position:0% through we have enough here to start to 00:31:50.000 --> 00:31:53.310 align:start position:0% through we have enough here to start to set<00:31:50.240> this<00:31:50.440> up<00:31:51.360> so<00:31:51.679> we<00:31:51.880> can<00:31:52.080> think<00:31:52.360> about<00:31:53.200> uh 00:31:53.310 --> 00:31:53.320 align:start position:0% set this up so we can think about uh 00:31:53.320 --> 00:31:55.710 align:start position:0% set this up so we can think about uh what<00:31:53.480> the<00:31:53.600> steps<00:31:53.919> are<00:31:54.320> for<00:31:55.039> validating<00:31:55.559> a 00:31:55.710 --> 00:31:55.720 align:start position:0% what the steps are for validating a 00:31:55.720 --> 00:31:57.950 align:start position:0% what the steps are for validating a nested<00:31:56.039> storage<00:31:56.360> proof 00:31:57.950 --> 00:31:57.960 align:start position:0% nested storage proof 00:31:57.960 --> 00:32:00.710 align:start position:0% nested storage proof for<00:31:58.559> starters<00:31:59.559> we'll<00:31:59.760> want<00:31:59.960> to<00:32:00.200> enforce<00:32:00.559> a 00:32:00.710 --> 00:32:00.720 align:start position:0% for starters we'll want to enforce a 00:32:00.720 --> 00:32:02.470 align:start position:0% for starters we'll want to enforce a structure<00:32:01.039> to<00:32:01.200> proof<00:32:01.480> data<00:32:01.679> so<00:32:01.799> we<00:32:01.919> can<00:32:02.039> decode 00:32:02.470 --> 00:32:02.480 align:start position:0% structure to proof data so we can decode 00:32:02.480 --> 00:32:05.710 align:start position:0% structure to proof data so we can decode this<00:32:02.679> into<00:32:03.440> some<00:32:03.919> defined<00:32:04.919> um<00:32:05.120> struct<00:32:05.600> that 00:32:05.710 --> 00:32:05.720 align:start position:0% this into some defined um struct that 00:32:05.720 --> 00:32:08.430 align:start position:0% this into some defined um struct that will<00:32:06.000> we'll<00:32:06.159> Define<00:32:06.399> in<00:32:06.559> storage<00:32:06.960> up<00:32:07.159> here<00:32:08.039> so 00:32:08.430 --> 00:32:08.440 align:start position:0% will we'll Define in storage up here so 00:32:08.440 --> 00:32:14.629 align:start position:0% will we'll Define in storage up here so uh<00:32:08.639> decode<00:32:09.639> proof 00:32:14.629 --> 00:32:14.639 align:start position:0% 00:32:14.639 --> 00:32:17.710 align:start position:0% data<00:32:15.639> next<00:32:15.840> with<00:32:15.960> the<00:32:16.080> decoded<00:32:16.519> proof<00:32:16.880> data<00:32:17.600> uh 00:32:17.710 --> 00:32:17.720 align:start position:0% data next with the decoded proof data uh 00:32:17.720 --> 00:32:21.230 align:start position:0% data next with the decoded proof data uh we<00:32:17.840> can<00:32:18.080> use<00:32:18.399> some<00:32:18.679> supplied<00:32:19.480> data<00:32:20.120> to<00:32:21.080> uh 00:32:21.230 --> 00:32:21.240 align:start position:0% we can use some supplied data to uh 00:32:21.240 --> 00:32:23.590 align:start position:0% we can use some supplied data to uh trustless<00:32:21.960> access<00:32:22.399> the<00:32:22.559> beacon<00:32:22.919> route<00:32:23.279> from 00:32:23.590 --> 00:32:23.600 align:start position:0% trustless access the beacon route from 00:32:23.600 --> 00:32:30.070 align:start position:0% trustless access the beacon route from L1<00:32:24.600> so<00:32:24.760> I<00:32:24.880> want<00:32:25.080> to<00:32:25.559> query<00:32:26.840> L1<00:32:27.919> date 00:32:30.070 --> 00:32:30.080 align:start position:0% L1 so I want to query L1 date 00:32:30.080 --> 00:32:32.389 align:start position:0% L1 so I want to query L1 date representation<00:32:31.080> in<00:32:31.279> a<00:32:31.399> real<00:32:31.679> Network<00:32:32.200> this 00:32:32.389 --> 00:32:32.399 align:start position:0% representation in a real Network this 00:32:32.399 --> 00:32:34.350 align:start position:0% representation in a real Network this likely<00:32:32.760> would<00:32:32.960> be<00:32:33.480> or<00:32:33.679> if<00:32:33.760> the<00:32:33.880> network<00:32:34.200> is 00:32:34.350 --> 00:32:34.360 align:start position:0% likely would be or if the network is 00:32:34.360 --> 00:32:35.909 align:start position:0% likely would be or if the network is supporting<00:32:34.840> EIP 00:32:35.909 --> 00:32:35.919 align:start position:0% supporting EIP 00:32:35.919 --> 00:32:38.750 align:start position:0% supporting EIP 4788<00:32:36.919> um<00:32:37.240> this<00:32:37.360> would<00:32:37.519> be<00:32:37.720> a<00:32:37.880> beacon<00:32:38.159> route<00:32:38.559> for 00:32:38.750 --> 00:32:38.760 align:start position:0% 4788 um this would be a beacon route for 00:32:38.760 --> 00:32:40.389 align:start position:0% 4788 um this would be a beacon route for today's<00:32:39.120> example<00:32:39.600> it's<00:32:39.799> the<00:32:39.919> state<00:32:40.159> route 00:32:40.389 --> 00:32:40.399 align:start position:0% today's example it's the state route 00:32:40.399 --> 00:32:42.269 align:start position:0% today's example it's the state route directly<00:32:41.039> so<00:32:41.200> I'll<00:32:41.360> just<00:32:41.519> make<00:32:41.679> a<00:32:42.039> brief 00:32:42.269 --> 00:32:42.279 align:start position:0% directly so I'll just make a brief 00:32:42.279 --> 00:32:47.430 align:start position:0% directly so I'll just make a brief comment<00:32:42.639> explaining<00:32:43.159> that<00:32:44.039> um<00:32:44.320> in<00:32:44.600> real 00:32:47.430 --> 00:32:47.440 align:start position:0% 00:32:47.440 --> 00:32:52.830 align:start position:0% Network<00:32:48.440> likely<00:32:49.039> Beacon<00:32:49.919> route<00:32:50.919> in<00:32:51.200> two<00:32:51.519> days 00:32:52.830 --> 00:32:52.840 align:start position:0% Network likely Beacon route in two days 00:32:52.840 --> 00:32:56.230 align:start position:0% Network likely Beacon route in two days demo<00:32:53.840> State 00:32:56.230 --> 00:32:56.240 align:start position:0% demo State 00:32:56.240 --> 00:32:59.950 align:start position:0% demo State rout<00:32:57.240> okay<00:32:57.360> so<00:32:57.480> then<00:32:57.600> step<00:32:58.120> three<00:32:59.120> um<00:32:59.480> once<00:32:59.679> we 00:32:59.950 --> 00:32:59.960 align:start position:0% rout okay so then step three um once we 00:32:59.960 --> 00:33:04.549 align:start position:0% rout okay so then step three um once we have<00:33:00.600> a<00:33:01.399> state<00:33:01.679> representation<00:33:02.200> for<00:33:02.760> L1<00:33:03.760> um 00:33:04.549 --> 00:33:04.559 align:start position:0% have a state representation for L1 um 00:33:04.559 --> 00:33:07.470 align:start position:0% have a state representation for L1 um using<00:33:05.440> L1<00:33:06.240> State 00:33:07.470 --> 00:33:07.480 align:start position:0% using L1 State 00:33:07.480 --> 00:33:10.590 align:start position:0% using L1 State Route<00:33:08.480> we'll<00:33:08.720> verify<00:33:09.559> uh<00:33:09.760> storage<00:33:10.120> location 00:33:10.590 --> 00:33:10.600 align:start position:0% Route we'll verify uh storage location 00:33:10.600 --> 00:33:13.789 align:start position:0% Route we'll verify uh storage location on<00:33:11.000> L1<00:33:12.000> and<00:33:12.320> that<00:33:12.440> storage<00:33:12.760> location<00:33:13.120> will<00:33:13.320> be 00:33:13.789 --> 00:33:13.799 align:start position:0% on L1 and that storage location will be 00:33:13.799 --> 00:33:16.590 align:start position:0% on L1 and that storage location will be the<00:33:14.000> destination<00:33:14.519> chains<00:33:15.200> rollup<00:33:15.639> contract 00:33:16.590 --> 00:33:16.600 align:start position:0% the destination chains rollup contract 00:33:16.600 --> 00:33:22.549 align:start position:0% the destination chains rollup contract so<00:33:17.120> verify<00:33:18.120> storage<00:33:18.880> location<00:33:19.760> in<00:33:20.480> DST<00:33:21.559> chains 00:33:22.549 --> 00:33:22.559 align:start position:0% so verify storage location in DST chains 00:33:22.559 --> 00:33:26.509 align:start position:0% so verify storage location in DST chains rollup<00:33:23.200> contract<00:33:24.039> on 00:33:26.509 --> 00:33:26.519 align:start position:0% 00:33:26.519 --> 00:33:30.470 align:start position:0% L1<00:33:27.519> step<00:33:28.000> four<00:33:28.559> we'll<00:33:28.840> need<00:33:29.080> to<00:33:29.840> verifiably 00:33:30.470 --> 00:33:30.480 align:start position:0% L1 step four we'll need to verifiably 00:33:30.480 --> 00:33:33.110 align:start position:0% L1 step four we'll need to verifiably link<00:33:30.960> a<00:33:31.120> destination<00:33:31.600> chain<00:33:32.000> state<00:33:32.279> route<00:33:32.799> to 00:33:33.110 --> 00:33:33.120 align:start position:0% link a destination chain state route to 00:33:33.120 --> 00:33:36.350 align:start position:0% link a destination chain state route to that<00:33:34.000> uh<00:33:35.000> oh<00:33:35.159> yeah<00:33:35.320> let's<00:33:35.440> see<00:33:35.639> using<00:33:35.919> L1<00:33:36.200> State 00:33:36.350 --> 00:33:36.360 align:start position:0% that uh oh yeah let's see using L1 State 00:33:36.360 --> 00:33:38.350 align:start position:0% that uh oh yeah let's see using L1 State Route<00:33:36.559> verified<00:33:36.840> storage<00:33:37.240> location<00:33:38.240> this 00:33:38.350 --> 00:33:38.360 align:start position:0% Route verified storage location this 00:33:38.360 --> 00:33:43.149 align:start position:0% Route verified storage location this should<00:33:38.600> be<00:33:39.519> DST<00:33:40.360> chain<00:33:41.360> State 00:33:43.149 --> 00:33:43.159 align:start position:0% should be DST chain State 00:33:43.159 --> 00:33:46.310 align:start position:0% should be DST chain State Rep<00:33:44.159> we'll<00:33:44.360> need<00:33:44.519> to<00:33:45.120> use<00:33:45.519> that<00:33:45.840> verified 00:33:46.310 --> 00:33:46.320 align:start position:0% Rep we'll need to use that verified 00:33:46.320 --> 00:33:49.269 align:start position:0% Rep we'll need to use that verified value<00:33:46.840> to<00:33:47.279> link<00:33:47.919> a<00:33:48.399> state<00:33:48.720> route<00:33:48.960> for<00:33:49.120> the 00:33:49.269 --> 00:33:49.279 align:start position:0% value to link a state route for the 00:33:49.279 --> 00:33:51.269 align:start position:0% value to link a state route for the destination<00:33:49.760> chain<00:33:50.519> um<00:33:50.639> so<00:33:50.760> we<00:33:50.880> can<00:33:51.000> do<00:33:51.120> that 00:33:51.269 --> 00:33:51.279 align:start position:0% destination chain um so we can do that 00:33:51.279 --> 00:33:56.149 align:start position:0% destination chain um so we can do that as<00:33:51.399> its<00:33:51.519> own<00:33:51.760> step<00:33:52.440> here<00:33:53.440> um 00:33:56.149 --> 00:33:56.159 align:start position:0% as its own step here um 00:33:56.159 --> 00:34:02.310 align:start position:0% as its own step here um verifi<00:33:57.159> link 00:34:02.310 --> 00:34:02.320 align:start position:0% 00:34:02.320 --> 00:34:10.790 align:start position:0% to<00:34:03.320> uh<00:34:04.039> chain<00:34:04.679> State 00:34:10.790 --> 00:34:10.800 align:start position:0% 00:34:10.800 --> 00:34:13.909 align:start position:0% Rep<00:34:11.800> after<00:34:12.079> that<00:34:12.240> step<00:34:12.520> we<00:34:12.599> should<00:34:13.000> have<00:34:13.440> a 00:34:13.909 --> 00:34:13.919 align:start position:0% Rep after that step we should have a 00:34:13.919 --> 00:34:16.069 align:start position:0% Rep after that step we should have a verified<00:34:14.440> State<00:34:14.760> root<00:34:15.119> for<00:34:15.440> the<00:34:15.599> destination 00:34:16.069 --> 00:34:16.079 align:start position:0% verified State root for the destination 00:34:16.079 --> 00:34:18.149 align:start position:0% verified State root for the destination chain<00:34:16.480> so<00:34:16.720> then<00:34:16.919> we<00:34:17.040> can<00:34:17.200> essentially<00:34:17.679> repeat 00:34:18.149 --> 00:34:18.159 align:start position:0% chain so then we can essentially repeat 00:34:18.159 --> 00:34:20.710 align:start position:0% chain so then we can essentially repeat step<00:34:18.399> three<00:34:18.720> again<00:34:19.320> so<00:34:19.480> this<00:34:19.599> would<00:34:19.760> be<00:34:20.159> using 00:34:20.710 --> 00:34:20.720 align:start position:0% step three again so this would be using 00:34:20.720 --> 00:34:22.629 align:start position:0% step three again so this would be using L2<00:34:21.359> State 00:34:22.629 --> 00:34:22.639 align:start position:0% L2 State 00:34:22.639 --> 00:34:24.230 align:start position:0% L2 State root 00:34:24.230 --> 00:34:24.240 align:start position:0% root 00:34:24.240 --> 00:34:28.149 align:start position:0% root verify<00:34:25.240> execution<00:34:26.200> RIS<00:34:26.639> seat 00:34:28.149 --> 00:34:28.159 align:start position:0% verify execution RIS seat 00:34:28.159 --> 00:34:34.790 align:start position:0% verify execution RIS seat in<00:34:29.159> inbox<00:34:30.200> contract<00:34:31.200> on<00:34:31.599> DST 00:34:34.790 --> 00:34:34.800 align:start position:0% 00:34:34.800 --> 00:34:37.470 align:start position:0% chain<00:34:35.800> and<00:34:35.879> then<00:34:36.119> lastly<00:34:36.800> the<00:34:36.919> only<00:34:37.159> step<00:34:37.359> that 00:34:37.470 --> 00:34:37.480 align:start position:0% chain and then lastly the only step that 00:34:37.480 --> 00:34:40.869 align:start position:0% chain and then lastly the only step that we<00:34:37.560> haven't<00:34:37.839> covered<00:34:38.520> is<00:34:39.359> the<00:34:40.000> uh<00:34:40.280> this<00:34:40.440> revert 00:34:40.869 --> 00:34:40.879 align:start position:0% we haven't covered is the uh this revert 00:34:40.879 --> 00:34:42.629 align:start position:0% we haven't covered is the uh this revert statement<00:34:41.359> that's<00:34:41.679> saying<00:34:42.040> if<00:34:42.240> finality 00:34:42.629 --> 00:34:42.639 align:start position:0% statement that's saying if finality 00:34:42.639 --> 00:34:44.629 align:start position:0% statement that's saying if finality delay<00:34:42.919> seconds<00:34:43.200> is<00:34:43.320> still<00:34:43.440> in<00:34:43.599> progress<00:34:44.480> this 00:34:44.629 --> 00:34:44.639 align:start position:0% delay seconds is still in progress this 00:34:44.639 --> 00:34:46.550 align:start position:0% delay seconds is still in progress this function<00:34:44.879> should<00:34:45.040> be<00:34:45.200> reverting<00:34:46.079> so<00:34:46.320> we<00:34:46.440> can 00:34:46.550 --> 00:34:46.560 align:start position:0% function should be reverting so we can 00:34:46.560 --> 00:34:50.310 align:start position:0% function should be reverting so we can check<00:34:46.839> that<00:34:47.000> as<00:34:47.119> our<00:34:47.280> final<00:34:47.800> step 00:34:50.310 --> 00:34:50.320 align:start position:0% check that as our final step 00:34:50.320 --> 00:34:52.510 align:start position:0% check that as our final step whoops<00:34:51.320> step 00:34:52.510 --> 00:34:52.520 align:start position:0% whoops step 00:34:52.520 --> 00:34:55.510 align:start position:0% whoops step six<00:34:53.520> revert 00:34:55.510 --> 00:34:55.520 align:start position:0% six revert 00:34:55.520 --> 00:35:04.190 align:start position:0% six revert if<00:34:56.520> finality<00:34:58.000> delay<00:34:58.880> seconds<00:34:59.640> in 00:35:04.190 --> 00:35:04.200 align:start position:0% 00:35:04.200 --> 00:35:06.510 align:start position:0% progress<00:35:05.200> okay<00:35:05.320> so<00:35:05.480> if<00:35:05.599> we<00:35:05.760> can<00:35:05.920> successfully 00:35:06.510 --> 00:35:06.520 align:start position:0% progress okay so if we can successfully 00:35:06.520 --> 00:35:08.950 align:start position:0% progress okay so if we can successfully set<00:35:06.720> up<00:35:06.960> these<00:35:07.200> six<00:35:07.480> steps<00:35:08.079> then<00:35:08.320> we<00:35:08.440> should<00:35:08.680> be 00:35:08.950 --> 00:35:08.960 align:start position:0% set up these six steps then we should be 00:35:08.960 --> 00:35:11.349 align:start position:0% set up these six steps then we should be good<00:35:09.280> to<00:35:09.560> go<00:35:09.920> to<00:35:10.240> verify<00:35:10.839> these<00:35:11.000> nested 00:35:11.349 --> 00:35:11.359 align:start position:0% good to go to verify these nested 00:35:11.359 --> 00:35:12.190 align:start position:0% good to go to verify these nested storage 00:35:12.190 --> 00:35:12.200 align:start position:0% storage 00:35:12.200 --> 00:35:14.430 align:start position:0% storage proofs<00:35:13.200> if<00:35:13.280> we<00:35:13.400> take<00:35:13.560> a<00:35:13.760> look<00:35:13.920> up<00:35:14.119> here<00:35:14.320> you 00:35:14.430 --> 00:35:14.440 align:start position:0% proofs if we take a look up here you 00:35:14.440 --> 00:35:16.230 align:start position:0% proofs if we take a look up here you might<00:35:14.560> have<00:35:14.720> noticed<00:35:15.119> that<00:35:15.599> uh<00:35:15.720> this<00:35:15.880> contract 00:35:16.230 --> 00:35:16.240 align:start position:0% might have noticed that uh this contract 00:35:16.240 --> 00:35:17.670 align:start position:0% might have noticed that uh this contract is<00:35:16.400> expecting<00:35:16.720> to<00:35:16.839> be<00:35:16.960> deployed<00:35:17.359> with<00:35:17.480> an 00:35:17.670 --> 00:35:17.680 align:start position:0% is expecting to be deployed with an 00:35:17.680 --> 00:35:19.870 align:start position:0% is expecting to be deployed with an address<00:35:18.160> in<00:35:18.280> the<00:35:18.440> Constructor<00:35:19.440> this<00:35:19.640> address 00:35:19.870 --> 00:35:19.880 align:start position:0% address in the Constructor this address 00:35:19.880 --> 00:35:21.470 align:start position:0% address in the Constructor this address is<00:35:20.000> for<00:35:20.079> the<00:35:20.200> beacon<00:35:20.440> Roots<00:35:20.680> Oracle<00:35:21.040> contract 00:35:21.470 --> 00:35:21.480 align:start position:0% is for the beacon Roots Oracle contract 00:35:21.480 --> 00:35:23.270 align:start position:0% is for the beacon Roots Oracle contract in<00:35:21.599> a<00:35:21.760> live<00:35:22.000> Network<00:35:22.560> you<00:35:22.760> wouldn't<00:35:23.040> have<00:35:23.119> to 00:35:23.270 --> 00:35:23.280 align:start position:0% in a live Network you wouldn't have to 00:35:23.280 --> 00:35:26.109 align:start position:0% in a live Network you wouldn't have to do<00:35:23.480> this<00:35:24.359> um<00:35:24.520> because<00:35:24.800> EIP 00:35:26.109 --> 00:35:26.119 align:start position:0% do this um because EIP 00:35:26.119 --> 00:35:29.390 align:start position:0% do this um because EIP 4788<00:35:27.119> uh<00:35:27.240> specif<00:35:27.880> I<00:35:28.359> a<00:35:28.800> deterministic 00:35:29.390 --> 00:35:29.400 align:start position:0% 4788 uh specif I a deterministic 00:35:29.400 --> 00:35:30.910 align:start position:0% 4788 uh specif I a deterministic pre-compile<00:35:29.920> address<00:35:30.440> that<00:35:30.520> you<00:35:30.640> could<00:35:30.760> just 00:35:30.910 --> 00:35:30.920 align:start position:0% pre-compile address that you could just 00:35:30.920 --> 00:35:32.589 align:start position:0% pre-compile address that you could just hard<00:35:31.320> hard<00:35:31.599> code<00:35:31.839> into<00:35:32.040> your<00:35:32.200> contract 00:35:32.589 --> 00:35:32.599 align:start position:0% hard hard code into your contract 00:35:32.599 --> 00:35:35.430 align:start position:0% hard hard code into your contract storage<00:35:33.599> but<00:35:33.839> for<00:35:34.119> this<00:35:34.280> to<00:35:34.440> work<00:35:34.839> in<00:35:35.200> both 00:35:35.430 --> 00:35:35.440 align:start position:0% storage but for this to work in both 00:35:35.440 --> 00:35:38.230 align:start position:0% storage but for this to work in both tests<00:35:35.960> and<00:35:36.359> deployed<00:35:36.760> to<00:35:36.920> our<00:35:37.040> local<00:35:37.280> network 00:35:38.230 --> 00:35:38.240 align:start position:0% tests and deployed to our local network 00:35:38.240 --> 00:35:39.670 align:start position:0% tests and deployed to our local network um<00:35:38.400> I<00:35:38.520> have<00:35:38.680> it<00:35:38.800> being<00:35:38.960> deployed<00:35:39.440> with<00:35:39.560> the 00:35:39.670 --> 00:35:39.680 align:start position:0% um I have it being deployed with the 00:35:39.680 --> 00:35:42.109 align:start position:0% um I have it being deployed with the address<00:35:40.000> specified<00:35:40.480> here<00:35:41.280> so<00:35:41.520> as<00:35:41.599> our<00:35:41.839> first 00:35:42.109 --> 00:35:42.119 align:start position:0% address specified here so as our first 00:35:42.119 --> 00:35:43.910 align:start position:0% address specified here so as our first step<00:35:42.400> we<00:35:42.480> can<00:35:42.640> store<00:35:42.960> this<00:35:43.119> as<00:35:43.240> an<00:35:43.400> immutable 00:35:43.910 --> 00:35:43.920 align:start position:0% step we can store this as an immutable 00:35:43.920 --> 00:35:46.510 align:start position:0% step we can store this as an immutable variable<00:35:44.440> in<00:35:44.640> storage<00:35:45.320> so<00:35:45.480> this<00:35:45.560> will<00:35:45.720> be 00:35:46.510 --> 00:35:46.520 align:start position:0% variable in storage so this will be 00:35:46.520 --> 00:35:48.109 align:start position:0% variable in storage so this will be address 00:35:48.109 --> 00:35:48.119 align:start position:0% address 00:35:48.119 --> 00:35:49.829 align:start position:0% address private 00:35:49.829 --> 00:35:49.839 align:start position:0% private 00:35:49.839 --> 00:35:52.430 align:start position:0% private immutable<00:35:50.839> and<00:35:50.920> then<00:35:51.119> call<00:35:51.280> it<00:35:51.680> Beacon<00:35:51.920> Roots 00:35:52.430 --> 00:35:52.440 align:start position:0% immutable and then call it Beacon Roots 00:35:52.440 --> 00:36:00.230 align:start position:0% immutable and then call it Beacon Roots Oracle<00:35:53.240> something<00:35:53.520> like<00:35:53.720> that<00:35:54.720> beon<00:35:55.359> roots 00:36:00.230 --> 00:36:00.240 align:start position:0% 00:36:00.240 --> 00:36:08.750 align:start position:0% and<00:36:00.359> then<00:36:00.520> assign<00:36:00.839> that<00:36:00.960> within<00:36:01.160> the 00:36:08.750 --> 00:36:08.760 align:start position:0% 00:36:08.760 --> 00:36:10.470 align:start position:0% Constructor<00:36:09.760> and<00:36:09.839> then<00:36:09.960> if<00:36:10.079> we<00:36:10.160> start<00:36:10.319> to 00:36:10.470 --> 00:36:10.480 align:start position:0% Constructor and then if we start to 00:36:10.480 --> 00:36:12.349 align:start position:0% Constructor and then if we start to think<00:36:10.640> about<00:36:11.280> how<00:36:11.440> these<00:36:11.599> steps<00:36:11.920> are<00:36:12.160> are 00:36:12.349 --> 00:36:12.359 align:start position:0% think about how these steps are are 00:36:12.359 --> 00:36:14.190 align:start position:0% think about how these steps are are working<00:36:13.040> um<00:36:13.160> the<00:36:13.280> first<00:36:13.480> step<00:36:13.760> being<00:36:14.000> that<00:36:14.119> we 00:36:14.190 --> 00:36:14.200 align:start position:0% working um the first step being that we 00:36:14.200 --> 00:36:16.430 align:start position:0% working um the first step being that we want<00:36:14.359> to<00:36:14.560> decode<00:36:15.040> proof<00:36:15.319> data<00:36:15.680> into<00:36:16.040> some 00:36:16.430 --> 00:36:16.440 align:start position:0% want to decode proof data into some 00:36:16.440 --> 00:36:18.109 align:start position:0% want to decode proof data into some specified<00:36:17.040> structure<00:36:17.520> that<00:36:17.640> we're<00:36:17.800> going<00:36:17.960> to 00:36:18.109 --> 00:36:18.119 align:start position:0% specified structure that we're going to 00:36:18.119 --> 00:36:20.630 align:start position:0% specified structure that we're going to Define<00:36:19.000> we<00:36:19.079> can<00:36:19.240> start<00:36:19.560> by<00:36:19.880> defining<00:36:20.200> a<00:36:20.319> struct 00:36:20.630 --> 00:36:20.640 align:start position:0% Define we can start by defining a struct 00:36:20.640 --> 00:36:23.430 align:start position:0% Define we can start by defining a struct for<00:36:20.839> what<00:36:20.960> that<00:36:21.079> structure<00:36:21.440> should<00:36:21.720> be<00:36:22.640> so<00:36:23.319> uh 00:36:23.430 --> 00:36:23.440 align:start position:0% for what that structure should be so uh 00:36:23.440 --> 00:36:26.470 align:start position:0% for what that structure should be so uh for<00:36:23.680> this<00:36:23.880> context<00:36:24.720> we<00:36:24.839> should<00:36:25.200> call<00:36:25.440> it<00:36:26.280> um 00:36:26.470 --> 00:36:26.480 align:start position:0% for this context we should call it um 00:36:26.480 --> 00:36:28.670 align:start position:0% for this context we should call it um this<00:36:26.599> will<00:36:26.720> be<00:36:26.800> a<00:36:26.920> struct 00:36:28.670 --> 00:36:28.680 align:start position:0% this will be a struct 00:36:28.680 --> 00:36:33.710 align:start position:0% this will be a struct rip<00:36:29.680> 7755 00:36:33.710 --> 00:36:33.720 align:start position:0% 00:36:33.720 --> 00:36:35.710 align:start position:0% proof<00:36:34.720> and<00:36:34.880> the<00:36:35.000> compiler<00:36:35.319> is<00:36:35.400> going<00:36:35.480> to<00:36:35.560> be 00:36:35.710 --> 00:36:35.720 align:start position:0% proof and the compiler is going to be 00:36:35.720 --> 00:36:37.390 align:start position:0% proof and the compiler is going to be mad<00:36:36.040> about<00:36:36.280> the<00:36:36.400> struct<00:36:36.760> being<00:36:36.920> empty<00:36:37.319> but 00:36:37.390 --> 00:36:37.400 align:start position:0% mad about the struct being empty but 00:36:37.400 --> 00:36:39.109 align:start position:0% mad about the struct being empty but we'll<00:36:37.560> come<00:36:37.720> back<00:36:37.839> to<00:36:37.960> that<00:36:38.040> in<00:36:38.119> a 00:36:39.109 --> 00:36:39.119 align:start position:0% we'll come back to that in a 00:36:39.119 --> 00:36:41.829 align:start position:0% we'll come back to that in a second<00:36:40.119> we<00:36:40.240> can<00:36:40.359> set<00:36:40.560> up<00:36:40.720> this<00:36:40.839> first<00:36:41.119> step<00:36:41.720> uh 00:36:41.829 --> 00:36:41.839 align:start position:0% second we can set up this first step uh 00:36:41.839 --> 00:36:44.390 align:start position:0% second we can set up this first step uh with<00:36:41.960> that<00:36:42.079> in<00:36:42.319> place<00:36:43.240> by<00:36:43.560> decoding<00:36:44.000> the<00:36:44.119> proof 00:36:44.390 --> 00:36:44.400 align:start position:0% with that in place by decoding the proof 00:36:44.400 --> 00:36:47.030 align:start position:0% with that in place by decoding the proof data<00:36:44.880> into<00:36:45.680> a<00:36:45.839> local<00:36:46.359> variable<00:36:46.760> that<00:36:46.839> we<00:36:46.920> can 00:36:47.030 --> 00:36:47.040 align:start position:0% data into a local variable that we can 00:36:47.040 --> 00:36:50.069 align:start position:0% data into a local variable that we can call<00:36:47.240> proof<00:36:47.800> that<00:36:48.119> is<00:36:48.839> um<00:36:49.000> adhering<00:36:49.359> to<00:36:49.560> this 00:36:50.069 --> 00:36:50.079 align:start position:0% call proof that is um adhering to this 00:36:50.079 --> 00:36:55.230 align:start position:0% call proof that is um adhering to this RP<00:36:50.520> 7755<00:36:51.359> proof<00:36:51.839> struct<00:36:52.839> so<00:36:53.240> if<00:36:53.359> we<00:36:53.520> copy 00:36:55.230 --> 00:36:55.240 align:start position:0% RP 7755 proof struct so if we copy 00:36:55.240 --> 00:36:58.670 align:start position:0% RP 7755 proof struct so if we copy this<00:36:56.240> paste<00:36:56.400> it<00:36:56.640> here<00:36:57.000> this<00:36:57.079> will<00:36:57.200> be<00:36:57.280> in 00:36:58.670 --> 00:36:58.680 align:start position:0% this paste it here this will be in 00:36:58.680 --> 00:37:02.190 align:start position:0% this paste it here this will be in memory<00:36:59.680> is<00:36:59.800> equal<00:37:00.040> to<00:37:00.280> ai. 00:37:02.190 --> 00:37:02.200 align:start position:0% memory is equal to ai. 00:37:02.200 --> 00:37:06.470 align:start position:0% memory is equal to ai. decode<00:37:03.200> proof<00:37:04.160> data<00:37:05.040> and<00:37:05.160> then<00:37:05.359> pass<00:37:05.599> in<00:37:06.359> the 00:37:06.470 --> 00:37:06.480 align:start position:0% decode proof data and then pass in the 00:37:06.480 --> 00:37:08.030 align:start position:0% decode proof data and then pass in the name<00:37:06.640> of<00:37:06.720> the<00:37:06.880> struct<00:37:07.520> is<00:37:07.680> the<00:37:07.800> second 00:37:08.030 --> 00:37:08.040 align:start position:0% name of the struct is the second 00:37:08.040 --> 00:37:10.750 align:start position:0% name of the struct is the second argument<00:37:08.520> here<00:37:09.319> and<00:37:09.440> then<00:37:09.599> this<00:37:09.760> will<00:37:10.079> decode 00:37:10.750 --> 00:37:10.760 align:start position:0% argument here and then this will decode 00:37:10.760 --> 00:37:12.870 align:start position:0% argument here and then this will decode the<00:37:11.000> proof<00:37:11.280> data<00:37:11.560> bytes<00:37:12.160> into<00:37:12.599> whatever 00:37:12.870 --> 00:37:12.880 align:start position:0% the proof data bytes into whatever 00:37:12.880 --> 00:37:14.470 align:start position:0% the proof data bytes into whatever structure<00:37:13.240> we<00:37:13.359> Define<00:37:13.920> at<00:37:14.040> the<00:37:14.160> top<00:37:14.280> of<00:37:14.400> the 00:37:14.470 --> 00:37:14.480 align:start position:0% structure we Define at the top of the 00:37:14.480 --> 00:37:17.069 align:start position:0% structure we Define at the top of the file 00:37:17.069 --> 00:37:17.079 align:start position:0% 00:37:17.079 --> 00:37:18.870 align:start position:0% here 00:37:18.870 --> 00:37:18.880 align:start position:0% here 00:37:18.880 --> 00:37:21.670 align:start position:0% here so<00:37:19.880> for<00:37:20.119> step<00:37:20.319> two<00:37:20.680> we<00:37:20.800> want<00:37:20.960> to<00:37:21.119> then<00:37:21.319> query 00:37:21.670 --> 00:37:21.680 align:start position:0% so for step two we want to then query 00:37:21.680 --> 00:37:24.069 align:start position:0% so for step two we want to then query the<00:37:21.800> L1<00:37:22.200> state<00:37:22.640> representation<00:37:23.640> um<00:37:23.839> this<00:37:23.920> is 00:37:24.069 --> 00:37:24.079 align:start position:0% the L1 state representation um this is 00:37:24.079 --> 00:37:26.150 align:start position:0% the L1 state representation um this is going<00:37:24.160> to<00:37:24.319> come<00:37:24.599> from<00:37:24.839> that<00:37:25.000> Beacon<00:37:25.440> Oracle 00:37:26.150 --> 00:37:26.160 align:start position:0% going to come from that Beacon Oracle 00:37:26.160 --> 00:37:27.790 align:start position:0% going to come from that Beacon Oracle contract<00:37:26.560> from<00:37:26.680> the<00:37:26.800> rollups<00:37:27.160> directory<00:37:27.680> that 00:37:27.790 --> 00:37:27.800 align:start position:0% contract from the rollups directory that 00:37:27.800 --> 00:37:30.710 align:start position:0% contract from the rollups directory that I<00:37:27.880> covered<00:37:28.319> briefly<00:37:29.319> so<00:37:29.520> if<00:37:29.599> we<00:37:29.760> pull<00:37:30.040> that<00:37:30.200> up 00:37:30.710 --> 00:37:30.720 align:start position:0% I covered briefly so if we pull that up 00:37:30.720 --> 00:37:32.790 align:start position:0% I covered briefly so if we pull that up to<00:37:31.000> take<00:37:31.160> a<00:37:31.280> look<00:37:31.440> at<00:37:31.599> the<00:37:31.800> storage<00:37:32.240> layout 00:37:32.790 --> 00:37:32.800 align:start position:0% to take a look at the storage layout 00:37:32.800 --> 00:37:36.510 align:start position:0% to take a look at the storage layout here<00:37:33.800> of<00:37:34.000> how<00:37:34.240> exactly<00:37:34.560> we<00:37:34.680> should<00:37:34.880> query<00:37:35.520> that 00:37:36.510 --> 00:37:36.520 align:start position:0% here of how exactly we should query that 00:37:36.520 --> 00:37:38.990 align:start position:0% here of how exactly we should query that um<00:37:37.280> this<00:37:37.440> has<00:37:37.560> a<00:37:37.680> fallback<00:37:38.160> function<00:37:38.440> in<00:37:38.680> here 00:37:38.990 --> 00:37:39.000 align:start position:0% um this has a fallback function in here 00:37:39.000 --> 00:37:43.150 align:start position:0% um this has a fallback function in here and<00:37:39.160> that's<00:37:39.400> to<00:37:39.839> mimic<00:37:40.760> the<00:37:41.760> um<00:37:42.520> the<00:37:42.680> interface 00:37:43.150 --> 00:37:43.160 align:start position:0% and that's to mimic the um the interface 00:37:43.160 --> 00:37:44.710 align:start position:0% and that's to mimic the um the interface that<00:37:43.240> would<00:37:43.400> be<00:37:43.599> used<00:37:43.880> to<00:37:44.040> query<00:37:44.359> a<00:37:44.440> beacon 00:37:44.710 --> 00:37:44.720 align:start position:0% that would be used to query a beacon 00:37:44.720 --> 00:37:46.309 align:start position:0% that would be used to query a beacon rout<00:37:45.079> from<00:37:45.440> like<00:37:45.560> the<00:37:45.640> real<00:37:45.839> Beacon<00:37:46.079> Roots 00:37:46.309 --> 00:37:46.319 align:start position:0% rout from like the real Beacon Roots 00:37:46.319 --> 00:37:48.710 align:start position:0% rout from like the real Beacon Roots Oracle<00:37:46.599> contract<00:37:46.920> on<00:37:47.000> a<00:37:47.119> live<00:37:47.480> network<00:37:48.480> uh<00:37:48.599> and 00:37:48.710 --> 00:37:48.720 align:start position:0% Oracle contract on a live network uh and 00:37:48.720 --> 00:37:50.829 align:start position:0% Oracle contract on a live network uh and all<00:37:48.920> this<00:37:49.119> takes<00:37:49.680> is<00:37:49.920> an<00:37:50.040> encoded<00:37:50.480> block 00:37:50.829 --> 00:37:50.839 align:start position:0% all this takes is an encoded block 00:37:50.839 --> 00:37:53.309 align:start position:0% all this takes is an encoded block timestamp<00:37:51.839> so<00:37:52.040> that's<00:37:52.280> actually<00:37:52.640> the<00:37:53.000> first 00:37:53.309 --> 00:37:53.319 align:start position:0% timestamp so that's actually the first 00:37:53.319 --> 00:37:54.829 align:start position:0% timestamp so that's actually the first piece<00:37:53.480> of<00:37:53.680> data<00:37:53.920> that<00:37:54.000> we<00:37:54.119> need<00:37:54.240> to<00:37:54.400> add<00:37:54.599> into 00:37:54.829 --> 00:37:54.839 align:start position:0% piece of data that we need to add into 00:37:54.839 --> 00:37:58.230 align:start position:0% piece of data that we need to add into our<00:37:55.000> RP<00:37:55.440> 7755<00:37:56.440> proof<00:37:56.680> struct<00:37:57.680> is<00:37:57.839> we<00:37:58.000> need<00:37:58.119> to 00:37:58.230 --> 00:37:58.240 align:start position:0% our RP 7755 proof struct is we need to 00:37:58.240 --> 00:38:00.390 align:start position:0% our RP 7755 proof struct is we need to know<00:37:58.400> the<00:37:58.520> L1<00:37:58.880> block<00:37:59.160> time<00:37:59.400> stamp<00:37:59.720> that<00:37:59.880> we're 00:38:00.390 --> 00:38:00.400 align:start position:0% know the L1 block time stamp that we're 00:38:00.400 --> 00:38:02.910 align:start position:0% know the L1 block time stamp that we're um<00:38:00.560> going<00:38:00.640> to<00:38:00.760> be<00:38:00.880> using<00:38:01.160> for<00:38:01.319> the<00:38:01.599> proof<00:38:02.599> so<00:38:02.839> we 00:38:02.910 --> 00:38:02.920 align:start position:0% um going to be using for the proof so we 00:38:02.920 --> 00:38:05.270 align:start position:0% um going to be using for the proof so we can<00:38:03.079> add<00:38:03.240> that<00:38:03.400> in<00:38:03.640> as<00:38:03.720> a<00:38:03.880> u 00:38:05.270 --> 00:38:05.280 align:start position:0% can add that in as a u 00:38:05.280 --> 00:38:11.270 align:start position:0% can add that in as a u 256<00:38:06.280> call<00:38:06.440> it<00:38:06.560> L1 00:38:11.270 --> 00:38:11.280 align:start position:0% 00:38:11.280 --> 00:38:13.990 align:start position:0% timestamp<00:38:12.280> and<00:38:12.400> then<00:38:12.560> using<00:38:13.000> that<00:38:13.599> we<00:38:13.680> can<00:38:13.839> set 00:38:13.990 --> 00:38:14.000 align:start position:0% timestamp and then using that we can set 00:38:14.000 --> 00:38:15.910 align:start position:0% timestamp and then using that we can set up<00:38:14.119> a<00:38:14.280> static<00:38:14.560> call<00:38:14.960> into<00:38:15.160> the<00:38:15.280> beacon<00:38:15.560> Oracle 00:38:15.910 --> 00:38:15.920 align:start position:0% up a static call into the beacon Oracle 00:38:15.920 --> 00:38:18.069 align:start position:0% up a static call into the beacon Oracle contract<00:38:16.839> again<00:38:17.280> if<00:38:17.359> you<00:38:17.480> remember<00:38:17.839> we<00:38:17.960> have 00:38:18.069 --> 00:38:18.079 align:start position:0% contract again if you remember we have 00:38:18.079 --> 00:38:19.390 align:start position:0% contract again if you remember we have the<00:38:18.240> address<00:38:18.480> stored<00:38:18.760> as<00:38:18.880> the<00:38:18.960> immutable 00:38:19.390 --> 00:38:19.400 align:start position:0% the address stored as the immutable 00:38:19.400 --> 00:38:23.510 align:start position:0% the address stored as the immutable variable<00:38:19.800> here<00:38:20.640> so<00:38:20.800> we<00:38:20.920> can<00:38:21.079> take<00:38:21.560> this<00:38:22.560> copy 00:38:23.510 --> 00:38:23.520 align:start position:0% variable here so we can take this copy 00:38:23.520 --> 00:38:27.589 align:start position:0% variable here so we can take this copy that<00:38:24.520> and<00:38:24.680> under<00:38:25.000> step<00:38:25.240> two 00:38:27.589 --> 00:38:27.599 align:start position:0% that and under step two 00:38:27.599 --> 00:38:29.990 align:start position:0% that and under step two paste<00:38:27.960> that<00:38:28.440> that'll<00:38:28.680> be 00:38:29.990 --> 00:38:30.000 align:start position:0% paste that that'll be 00:38:30.000 --> 00:38:32.589 align:start position:0% paste that that'll be uh<00:38:31.000> yeah<00:38:31.160> Beacon<00:38:31.440> Roots<00:38:31.720> Oracle<00:38:32.079> you<00:38:32.160> do 00:38:32.589 --> 00:38:32.599 align:start position:0% uh yeah Beacon Roots Oracle you do 00:38:32.599 --> 00:38:34.230 align:start position:0% uh yeah Beacon Roots Oracle you do static 00:38:34.230 --> 00:38:34.240 align:start position:0% static 00:38:34.240 --> 00:38:37.309 align:start position:0% static call<00:38:35.240> which<00:38:35.400> is<00:38:35.560> like<00:38:35.640> a<00:38:35.720> lowl<00:38:36.200> call<00:38:36.760> but<00:38:37.200> kind 00:38:37.309 --> 00:38:37.319 align:start position:0% call which is like a lowl call but kind 00:38:37.319 --> 00:38:38.550 align:start position:0% call which is like a lowl call but kind of<00:38:37.440> like<00:38:37.520> a<00:38:37.599> view<00:38:37.839> function<00:38:38.240> where<00:38:38.359> it's 00:38:38.550 --> 00:38:38.560 align:start position:0% of like a view function where it's 00:38:38.560 --> 00:38:41.630 align:start position:0% of like a view function where it's expected<00:38:38.880> to<00:38:39.079> not<00:38:39.839> um<00:38:40.480> mutate<00:38:40.920> any<00:38:41.160> state<00:38:41.480> in 00:38:41.630 --> 00:38:41.640 align:start position:0% expected to not um mutate any state in 00:38:41.640 --> 00:38:43.550 align:start position:0% expected to not um mutate any state in the<00:38:41.880> destination<00:38:42.400> address<00:38:42.680> that<00:38:42.800> you're 00:38:43.550 --> 00:38:43.560 align:start position:0% the destination address that you're 00:38:43.560 --> 00:38:46.630 align:start position:0% the destination address that you're calling<00:38:44.560> so<00:38:45.200> uh<00:38:45.400> and<00:38:45.480> then<00:38:45.599> we're<00:38:45.800> passing<00:38:46.119> in 00:38:46.630 --> 00:38:46.640 align:start position:0% calling so uh and then we're passing in 00:38:46.640 --> 00:38:49.309 align:start position:0% calling so uh and then we're passing in the<00:38:46.960> encoded<00:38:47.599> block<00:38:47.880> Tim<00:38:48.119> stamp<00:38:48.440> for<00:38:48.880> the<00:38:49.000> L1 00:38:49.309 --> 00:38:49.319 align:start position:0% the encoded block Tim stamp for the L1 00:38:49.319 --> 00:38:50.910 align:start position:0% the encoded block Tim stamp for the L1 chain<00:38:49.680> which<00:38:49.760> we<00:38:49.880> just<00:38:50.040> added<00:38:50.240> to<00:38:50.400> proof<00:38:50.720> so 00:38:50.910 --> 00:38:50.920 align:start position:0% chain which we just added to proof so 00:38:50.920 --> 00:38:53.710 align:start position:0% chain which we just added to proof so this<00:38:51.000> should<00:38:51.200> be<00:38:51.640> available<00:38:52.160> via<00:38:52.520> ABI<00:38:53.160> do 00:38:53.710 --> 00:38:53.720 align:start position:0% this should be available via ABI do 00:38:53.720 --> 00:38:57.230 align:start position:0% this should be available via ABI do encode<00:38:54.720> with<00:38:55.040> proof.<00:38:56.040> L1<00:38:56.480> timestamp<00:38:57.000> passed 00:38:57.230 --> 00:38:57.240 align:start position:0% encode with proof. L1 timestamp passed 00:38:57.240 --> 00:38:59.910 align:start position:0% encode with proof. L1 timestamp passed in 00:38:59.910 --> 00:38:59.920 align:start position:0% 00:38:59.920 --> 00:39:05.670 align:start position:0% whoops<00:39:00.920> this<00:39:01.119> static<00:39:01.480> call<00:39:02.040> will<00:39:02.480> return<00:39:02.880> a 00:39:05.670 --> 00:39:05.680 align:start position:0% 00:39:05.680 --> 00:39:08.550 align:start position:0% tuple<00:39:06.680> where<00:39:06.880> the<00:39:07.040> first<00:39:07.400> value<00:39:07.760> is<00:39:07.880> a<00:39:08.000> Boolean 00:39:08.550 --> 00:39:08.560 align:start position:0% tuple where the first value is a Boolean 00:39:08.560 --> 00:39:12.150 align:start position:0% tuple where the first value is a Boolean so<00:39:08.680> we<00:39:08.800> can<00:39:08.920> call<00:39:09.040> that<00:39:09.200> bu 00:39:12.150 --> 00:39:12.160 align:start position:0% 00:39:12.160 --> 00:39:15.630 align:start position:0% success<00:39:13.160> and<00:39:13.280> the<00:39:13.520> second<00:39:14.040> value<00:39:14.640> is<00:39:15.119> uh<00:39:15.359> bytes 00:39:15.630 --> 00:39:15.640 align:start position:0% success and the second value is uh bytes 00:39:15.640 --> 00:39:22.550 align:start position:0% success and the second value is uh bytes array<00:39:15.920> and<00:39:16.040> memory<00:39:16.520> so<00:39:17.000> bytes<00:39:17.760> memory 00:39:22.550 --> 00:39:22.560 align:start position:0% 00:39:22.560 --> 00:39:25.870 align:start position:0% data<00:39:23.560> with<00:39:23.720> any<00:39:23.920> low-l<00:39:24.359> call<00:39:24.680> in<00:39:24.800> an<00:39:24.920> evm<00:39:25.319> chain 00:39:25.870 --> 00:39:25.880 align:start position:0% data with any low-l call in an evm chain 00:39:25.880 --> 00:39:27.589 align:start position:0% data with any low-l call in an evm chain you<00:39:26.160> need<00:39:26.359> to<00:39:26.480> confirm<00:39:26.800> that<00:39:26.960> success<00:39:27.400> comes 00:39:27.589 --> 00:39:27.599 align:start position:0% you need to confirm that success comes 00:39:27.599 --> 00:39:29.309 align:start position:0% you need to confirm that success comes back<00:39:27.760> is<00:39:27.920> true<00:39:28.400> because<00:39:28.640> if<00:39:28.800> something<00:39:29.040> weird 00:39:29.309 --> 00:39:29.319 align:start position:0% back is true because if something weird 00:39:29.319 --> 00:39:31.109 align:start position:0% back is true because if something weird happens<00:39:29.680> with<00:39:29.839> this<00:39:30.040> address<00:39:30.560> or<00:39:30.720> the<00:39:30.839> static 00:39:31.109 --> 00:39:31.119 align:start position:0% happens with this address or the static 00:39:31.119 --> 00:39:33.630 align:start position:0% happens with this address or the static call<00:39:31.359> fails<00:39:31.680> for<00:39:31.880> some<00:39:32.040> unexpected<00:39:32.560> reason<00:39:33.520> um 00:39:33.630 --> 00:39:33.640 align:start position:0% call fails for some unexpected reason um 00:39:33.640 --> 00:39:35.950 align:start position:0% call fails for some unexpected reason um and<00:39:33.800> success<00:39:34.119> comes<00:39:34.359> back<00:39:34.560> false<00:39:35.040> we<00:39:35.160> need<00:39:35.400> to 00:39:35.950 --> 00:39:35.960 align:start position:0% and success comes back false we need to 00:39:35.960 --> 00:39:37.589 align:start position:0% and success comes back false we need to uh<00:39:36.119> ensure<00:39:36.400> that<00:39:36.480> we<00:39:36.599> revert<00:39:36.920> the<00:39:37.040> transaction 00:39:37.589 --> 00:39:37.599 align:start position:0% uh ensure that we revert the transaction 00:39:37.599 --> 00:39:40.589 align:start position:0% uh ensure that we revert the transaction here<00:39:38.319> so<00:39:38.880> uh<00:39:39.000> for<00:39:39.240> that<00:39:39.480> case<00:39:39.880> we<00:39:40.000> can<00:39:40.240> add<00:39:40.440> a 00:39:40.589 --> 00:39:40.599 align:start position:0% here so uh for that case we can add a 00:39:40.599 --> 00:39:43.270 align:start position:0% here so uh for that case we can add a custom<00:39:40.920> error<00:39:41.280> at<00:39:41.359> the<00:39:41.520> top<00:39:41.640> of<00:39:41.760> the<00:39:41.880> file<00:39:42.720> for 00:39:43.270 --> 00:39:43.280 align:start position:0% custom error at the top of the file for 00:39:43.280 --> 00:39:46.030 align:start position:0% custom error at the top of the file for if<00:39:44.000> um<00:39:44.440> the<00:39:44.599> the<00:39:44.720> static<00:39:45.000> call<00:39:45.240> fails<00:39:45.800> we<00:39:45.880> can 00:39:46.030 --> 00:39:46.040 align:start position:0% if um the the static call fails we can 00:39:46.040 --> 00:39:47.470 align:start position:0% if um the the static call fails we can call<00:39:46.200> it 00:39:47.470 --> 00:39:47.480 align:start position:0% call it 00:39:47.480 --> 00:39:54.950 align:start position:0% call it error<00:39:48.480> Beacon<00:39:49.400> root<00:39:50.520> Oracle<00:39:51.520> call 00:39:54.950 --> 00:39:54.960 align:start position:0% 00:39:54.960 --> 00:39:57.950 align:start position:0% failed<00:39:55.960> copy<00:39:56.359> that<00:39:56.760> and<00:39:56.839> then<00:39:56.960> underne 00:39:57.950 --> 00:39:57.960 align:start position:0% failed copy that and then underne 00:39:57.960 --> 00:40:02.230 align:start position:0% failed copy that and then underne this<00:39:58.200> line<00:39:58.920> we<00:39:59.040> can<00:39:59.200> do<00:39:59.599> if<00:40:00.280> not 00:40:02.230 --> 00:40:02.240 align:start position:0% this line we can do if not 00:40:02.240 --> 00:40:06.510 align:start position:0% this line we can do if not success<00:40:03.240> revert<00:40:04.040> with<00:40:04.200> that<00:40:04.319> custom 00:40:06.510 --> 00:40:06.520 align:start position:0% success revert with that custom 00:40:06.520 --> 00:40:08.630 align:start position:0% success revert with that custom error<00:40:07.520> so<00:40:07.640> if<00:40:07.760> we<00:40:07.880> get<00:40:08.079> past<00:40:08.319> this<00:40:08.480> if 00:40:08.630 --> 00:40:08.640 align:start position:0% error so if we get past this if 00:40:08.640 --> 00:40:11.710 align:start position:0% error so if we get past this if statement<00:40:09.240> then<00:40:09.400> we<00:40:09.680> have<00:40:09.960> a<00:40:10.280> returned<00:40:11.119> um 00:40:11.710 --> 00:40:11.720 align:start position:0% statement then we have a returned um 00:40:11.720 --> 00:40:14.030 align:start position:0% statement then we have a returned um data<00:40:12.079> bytes<00:40:12.359> array<00:40:13.200> where<00:40:13.440> the<00:40:13.560> data<00:40:13.839> is 00:40:14.030 --> 00:40:14.040 align:start position:0% data bytes array where the data is 00:40:14.040 --> 00:40:17.550 align:start position:0% data bytes array where the data is representing<00:40:14.599> an<00:40:14.800> encoded<00:40:15.800> um<00:40:16.119> version<00:40:17.000> of 00:40:17.550 --> 00:40:17.560 align:start position:0% representing an encoded um version of 00:40:17.560 --> 00:40:21.030 align:start position:0% representing an encoded um version of the<00:40:17.680> state<00:40:17.920> route<00:40:18.200> for<00:40:18.839> L1<00:40:19.839> so<00:40:20.480> after<00:40:20.720> this<00:40:20.880> if 00:40:21.030 --> 00:40:21.040 align:start position:0% the state route for L1 so after this if 00:40:21.040 --> 00:40:23.190 align:start position:0% the state route for L1 so after this if statement<00:40:21.480> we<00:40:21.560> can<00:40:21.760> then<00:40:21.960> decode<00:40:22.480> data<00:40:22.880> into<00:40:23.079> a 00:40:23.190 --> 00:40:23.200 align:start position:0% statement we can then decode data into a 00:40:23.200 --> 00:40:26.430 align:start position:0% statement we can then decode data into a bytes<00:40:23.480> 32<00:40:23.800> stay<00:40:24.119> rout<00:40:24.800> so<00:40:25.000> this<00:40:25.119> would<00:40:25.440> be 00:40:26.430 --> 00:40:26.440 align:start position:0% bytes 32 stay rout so this would be 00:40:26.440 --> 00:40:27.829 align:start position:0% bytes 32 stay rout so this would be bytes<00:40:26.760> 32 00:40:27.829 --> 00:40:27.839 align:start position:0% bytes 32 00:40:27.839 --> 00:40:29.510 align:start position:0% bytes 32 L1<00:40:28.560> State 00:40:29.510 --> 00:40:29.520 align:start position:0% L1 State 00:40:29.520 --> 00:40:34.069 align:start position:0% L1 State root<00:40:30.520> is<00:40:30.680> equal<00:40:30.920> to<00:40:31.240> another<00:40:31.560> ai. 00:40:34.069 --> 00:40:34.079 align:start position:0% root is equal to another ai. 00:40:34.079 --> 00:40:37.589 align:start position:0% root is equal to another ai. dcode<00:40:35.079> with<00:40:35.520> uh<00:40:35.640> data<00:40:35.960> passed<00:40:36.240> in<00:40:37.040> and<00:40:37.160> then<00:40:37.520> uh 00:40:37.589 --> 00:40:37.599 align:start position:0% dcode with uh data passed in and then uh 00:40:37.599 --> 00:40:44.430 align:start position:0% dcode with uh data passed in and then uh the<00:40:37.720> data<00:40:38.000> type<00:40:38.280> is<00:40:38.560> bytes 00:40:44.430 --> 00:40:44.440 align:start position:0% 00:40:44.440 --> 00:40:48.470 align:start position:0% 32<00:40:45.440> okay<00:40:46.040> so<00:40:46.560> that<00:40:46.839> should<00:40:47.520> do<00:40:47.720> it<00:40:47.920> for<00:40:48.240> step 00:40:48.470 --> 00:40:48.480 align:start position:0% 32 okay so that should do it for step 00:40:48.480 --> 00:40:51.069 align:start position:0% 32 okay so that should do it for step two<00:40:48.920> so<00:40:49.119> at<00:40:49.280> this<00:40:49.440> point<00:40:49.720> we<00:40:49.960> have<00:40:50.280> an<00:40:50.400> L1<00:40:50.800> State 00:40:51.069 --> 00:40:51.079 align:start position:0% two so at this point we have an L1 State 00:40:51.079 --> 00:40:52.990 align:start position:0% two so at this point we have an L1 State root<00:40:51.520> that<00:40:51.640> we<00:40:51.720> can<00:40:51.920> then<00:40:52.119> use<00:40:52.440> in<00:40:52.560> a<00:40:52.680> storage 00:40:52.990 --> 00:40:53.000 align:start position:0% root that we can then use in a storage 00:40:53.000 --> 00:40:55.030 align:start position:0% root that we can then use in a storage proof<00:40:53.280> to<00:40:53.440> verify<00:40:53.960> something<00:40:54.319> about<00:40:54.920> the 00:40:55.030 --> 00:40:55.040 align:start position:0% proof to verify something about the 00:40:55.040 --> 00:40:57.910 align:start position:0% proof to verify something about the state<00:40:55.240> of<00:40:55.680> L1<00:40:56.680> um<00:40:56.880> and<00:40:57.000> that<00:40:57.359> exactly<00:40:57.720> what 00:40:57.910 --> 00:40:57.920 align:start position:0% state of L1 um and that exactly what 00:40:57.920 --> 00:41:00.030 align:start position:0% state of L1 um and that exactly what step<00:40:58.200> three<00:40:58.640> is<00:40:58.839> laying<00:40:59.119> out<00:40:59.359> here<00:40:59.599> so<00:40:59.760> using 00:41:00.030 --> 00:41:00.040 align:start position:0% step three is laying out here so using 00:41:00.040 --> 00:41:02.150 align:start position:0% step three is laying out here so using L1<00:41:00.359> state<00:41:00.640> route<00:41:00.920> we<00:41:01.000> want<00:41:01.160> to<00:41:01.400> verify<00:41:02.040> the 00:41:02.150 --> 00:41:02.160 align:start position:0% L1 state route we want to verify the 00:41:02.160 --> 00:41:04.870 align:start position:0% L1 state route we want to verify the storage<00:41:02.920> location<00:41:03.920> um<00:41:04.160> in<00:41:04.319> the<00:41:04.440> destination 00:41:04.870 --> 00:41:04.880 align:start position:0% storage location um in the destination 00:41:04.880 --> 00:41:08.390 align:start position:0% storage location um in the destination chains<00:41:05.280> rollup<00:41:05.680> contract<00:41:06.000> on<00:41:06.359> L1<00:41:07.359> and<00:41:07.720> this<00:41:08.040> is 00:41:08.390 --> 00:41:08.400 align:start position:0% chains rollup contract on L1 and this is 00:41:08.400 --> 00:41:10.349 align:start position:0% chains rollup contract on L1 and this is going<00:41:08.560> to<00:41:08.760> be<00:41:09.200> the<00:41:09.359> state<00:41:09.640> representation<00:41:10.200> for 00:41:10.349 --> 00:41:10.359 align:start position:0% going to be the state representation for 00:41:10.359 --> 00:41:13.430 align:start position:0% going to be the state representation for the<00:41:10.480> destination<00:41:11.240> chain<00:41:12.240> so<00:41:12.760> in<00:41:12.880> order<00:41:13.119> to<00:41:13.280> get 00:41:13.430 --> 00:41:13.440 align:start position:0% the destination chain so in order to get 00:41:13.440 --> 00:41:15.550 align:start position:0% the destination chain so in order to get some<00:41:13.560> more<00:41:13.800> context<00:41:14.240> for<00:41:14.440> how<00:41:14.599> that<00:41:14.720> should 00:41:15.550 --> 00:41:15.560 align:start position:0% some more context for how that should 00:41:15.560 --> 00:41:19.309 align:start position:0% some more context for how that should work<00:41:16.560> uh<00:41:16.720> let's<00:41:16.960> take<00:41:17.079> a<00:41:17.359> look<00:41:18.000> at<00:41:18.599> the<00:41:18.760> rollup 00:41:19.309 --> 00:41:19.319 align:start position:0% work uh let's take a look at the rollup 00:41:19.319 --> 00:41:20.950 align:start position:0% work uh let's take a look at the rollup contract<00:41:19.880> because<00:41:20.119> that's<00:41:20.400> where<00:41:20.800> the 00:41:20.950 --> 00:41:20.960 align:start position:0% contract because that's where the 00:41:20.960 --> 00:41:22.750 align:start position:0% contract because that's where the destination<00:41:21.560> chain<00:41:21.920> will<00:41:22.079> be<00:41:22.240> posting<00:41:22.560> its 00:41:22.750 --> 00:41:22.760 align:start position:0% destination chain will be posting its 00:41:22.760 --> 00:41:24.750 align:start position:0% destination chain will be posting its state<00:41:23.280> representation<00:41:24.280> so<00:41:24.440> that'll<00:41:24.640> be 00:41:24.750 --> 00:41:24.760 align:start position:0% state representation so that'll be 00:41:24.760 --> 00:41:30.309 align:start position:0% state representation so that'll be inside<00:41:24.960> of<00:41:25.040> this<00:41:25.200> rollup<00:41:26.040> contract 00:41:30.309 --> 00:41:30.319 align:start position:0% 00:41:30.319 --> 00:41:33.030 align:start position:0% what's<00:41:30.560> kind<00:41:30.680> of<00:41:30.839> interesting<00:41:31.359> here<00:41:31.960> is<00:41:32.680> in<00:41:32.920> a 00:41:33.030 --> 00:41:33.040 align:start position:0% what's kind of interesting here is in a 00:41:33.040 --> 00:41:35.470 align:start position:0% what's kind of interesting here is in a lot<00:41:33.160> of<00:41:33.359> live<00:41:33.599> networks<00:41:34.359> the<00:41:34.720> exact<00:41:35.040> storage 00:41:35.470 --> 00:41:35.480 align:start position:0% lot of live networks the exact storage 00:41:35.480 --> 00:41:38.109 align:start position:0% lot of live networks the exact storage location<00:41:36.200> that<00:41:36.720> the<00:41:37.079> state<00:41:37.400> representation 00:41:38.109 --> 00:41:38.119 align:start position:0% location that the state representation 00:41:38.119 --> 00:41:41.390 align:start position:0% location that the state representation is<00:41:38.280> going<00:41:38.480> to<00:41:38.760> exist<00:41:39.240> is<00:41:39.440> not<00:41:40.200> necessarily<00:41:41.200> um 00:41:41.390 --> 00:41:41.400 align:start position:0% is going to exist is not necessarily um 00:41:41.400 --> 00:41:43.430 align:start position:0% is going to exist is not necessarily um known<00:41:41.880> at<00:41:42.000> the<00:41:42.119> time<00:41:42.280> of 00:41:43.430 --> 00:41:43.440 align:start position:0% known at the time of 00:41:43.440 --> 00:41:45.950 align:start position:0% known at the time of request<00:41:44.440> um<00:41:44.640> in<00:41:44.800> that<00:41:44.960> case<00:41:45.200> the<00:41:45.359> request<00:41:45.800> just 00:41:45.950 --> 00:41:45.960 align:start position:0% request um in that case the request just 00:41:45.960 --> 00:41:47.710 align:start position:0% request um in that case the request just knows<00:41:46.280> the<00:41:46.440> storage<00:41:46.800> slot<00:41:47.200> maybe<00:41:47.440> where<00:41:47.560> the 00:41:47.710 --> 00:41:47.720 align:start position:0% knows the storage slot maybe where the 00:41:47.720 --> 00:41:49.910 align:start position:0% knows the storage slot maybe where the data<00:41:47.960> structure<00:41:48.680> is<00:41:49.079> located<00:41:49.480> so<00:41:49.640> like<00:41:49.800> in 00:41:49.910 --> 00:41:49.920 align:start position:0% data structure is located so like in 00:41:49.920 --> 00:41:52.870 align:start position:0% data structure is located so like in this<00:41:50.280> example<00:41:51.200> the<00:41:51.400> mapping<00:41:52.040> storing<00:41:52.520> output 00:41:52.870 --> 00:41:52.880 align:start position:0% this example the mapping storing output 00:41:52.880 --> 00:41:56.190 align:start position:0% this example the mapping storing output routes<00:41:53.359> exist<00:41:53.760> at<00:41:54.200> uh<00:41:54.319> storage<00:41:54.640> slot<00:41:54.960> one<00:41:55.800> so 00:41:56.190 --> 00:41:56.200 align:start position:0% routes exist at uh storage slot one so 00:41:56.200 --> 00:41:58.910 align:start position:0% routes exist at uh storage slot one so in<00:41:56.400> this<00:41:56.640> context<00:41:57.280> the<00:41:57.520> request<00:41:58.079> specifying 00:41:58.910 --> 00:41:58.920 align:start position:0% in this context the request specifying 00:41:58.920 --> 00:42:01.670 align:start position:0% in this context the request specifying the<00:41:59.520> um<00:42:00.040> destination<00:42:00.560> chains<00:42:01.280> storage 00:42:01.670 --> 00:42:01.680 align:start position:0% the um destination chains storage 00:42:01.680 --> 00:42:04.510 align:start position:0% the um destination chains storage location<00:42:02.160> for<00:42:02.400> their<00:42:02.560> rollup<00:42:02.960> contract<00:42:03.359> on<00:42:03.520> L1 00:42:04.510 --> 00:42:04.520 align:start position:0% location for their rollup contract on L1 00:42:04.520 --> 00:42:06.270 align:start position:0% location for their rollup contract on L1 would<00:42:04.720> just<00:42:04.839> be<00:42:05.160> specifying<00:42:05.680> storage<00:42:06.000> slot 00:42:06.270 --> 00:42:06.280 align:start position:0% would just be specifying storage slot 00:42:06.280 --> 00:42:07.870 align:start position:0% would just be specifying storage slot one<00:42:06.599> and<00:42:06.680> then<00:42:06.800> we'd<00:42:07.000> have<00:42:07.079> to<00:42:07.240> take<00:42:07.440> that<00:42:07.640> and 00:42:07.870 --> 00:42:07.880 align:start position:0% one and then we'd have to take that and 00:42:07.880 --> 00:42:10.550 align:start position:0% one and then we'd have to take that and derive<00:42:08.760> uh<00:42:08.920> the<00:42:09.079> location<00:42:09.800> of<00:42:09.960> the<00:42:10.160> value<00:42:10.400> for 00:42:10.550 --> 00:42:10.560 align:start position:0% derive uh the location of the value for 00:42:10.560 --> 00:42:12.790 align:start position:0% derive uh the location of the value for the<00:42:10.680> mapping<00:42:11.520> based<00:42:11.839> off<00:42:12.000> of<00:42:12.160> the<00:42:12.319> destination 00:42:12.790 --> 00:42:12.800 align:start position:0% the mapping based off of the destination 00:42:12.800 --> 00:42:15.630 align:start position:0% the mapping based off of the destination chain<00:42:13.240> L2<00:42:13.640> block<00:42:14.160> timestamp<00:42:15.160> so<00:42:15.319> that<00:42:15.400> brings 00:42:15.630 --> 00:42:15.640 align:start position:0% chain L2 block timestamp so that brings 00:42:15.640 --> 00:42:17.750 align:start position:0% chain L2 block timestamp so that brings us<00:42:15.760> to<00:42:15.920> the<00:42:16.040> next<00:42:16.240> piece<00:42:16.440> of<00:42:16.640> data<00:42:17.359> that<00:42:17.599> we 00:42:17.750 --> 00:42:17.760 align:start position:0% us to the next piece of data that we 00:42:17.760 --> 00:42:19.950 align:start position:0% us to the next piece of data that we need<00:42:18.000> for<00:42:18.240> this<00:42:18.440> proof<00:42:18.960> it's<00:42:19.160> going<00:42:19.240> to<00:42:19.400> be<00:42:19.760> the 00:42:19.950 --> 00:42:19.960 align:start position:0% need for this proof it's going to be the 00:42:19.960 --> 00:42:21.950 align:start position:0% need for this proof it's going to be the the<00:42:20.040> block<00:42:20.319> Tim<00:42:20.520> stamp<00:42:20.800> for<00:42:20.920> the<00:42:21.160> destination 00:42:21.950 --> 00:42:21.960 align:start position:0% the block Tim stamp for the destination 00:42:21.960 --> 00:42:24.069 align:start position:0% the block Tim stamp for the destination chain<00:42:22.960> um<00:42:23.160> so<00:42:23.280> we<00:42:23.400> can<00:42:23.520> add<00:42:23.680> that<00:42:23.760> as<00:42:23.880> another 00:42:24.069 --> 00:42:24.079 align:start position:0% chain um so we can add that as another 00:42:24.079 --> 00:42:27.910 align:start position:0% chain um so we can add that as another un<00:42:24.359> 256<00:42:24.920> instead<00:42:25.160> of<00:42:25.280> the<00:42:25.440> proof 00:42:27.910 --> 00:42:27.920 align:start position:0% un 256 instead of the proof 00:42:27.920 --> 00:42:32.390 align:start position:0% un 256 instead of the proof and<00:42:28.000> this<00:42:28.119> can<00:42:28.280> be<00:42:28.760> L2<00:42:29.760> block 00:42:32.390 --> 00:42:32.400 align:start position:0% 00:42:32.400 --> 00:42:34.150 align:start position:0% timestamp<00:42:33.400> by<00:42:33.520> the<00:42:33.640> way<00:42:33.760> for<00:42:33.880> anyone 00:42:34.150 --> 00:42:34.160 align:start position:0% timestamp by the way for anyone 00:42:34.160 --> 00:42:35.710 align:start position:0% timestamp by the way for anyone following<00:42:34.520> along<00:42:34.800> try<00:42:34.960> to<00:42:35.160> stick<00:42:35.400> to<00:42:35.559> the 00:42:35.710 --> 00:42:35.720 align:start position:0% following along try to stick to the 00:42:35.720 --> 00:42:37.950 align:start position:0% following along try to stick to the exact<00:42:36.079> names<00:42:36.440> I<00:42:36.599> have<00:42:36.839> here<00:42:37.079> for<00:42:37.400> the<00:42:37.800> um 00:42:37.950 --> 00:42:37.960 align:start position:0% exact names I have here for the um 00:42:37.960 --> 00:42:41.790 align:start position:0% exact names I have here for the um fulfiller<00:42:38.440> proof<00:42:38.640> to<00:42:38.760> work<00:42:39.319> properly<00:42:40.640> um<00:42:41.640> the 00:42:41.790 --> 00:42:41.800 align:start position:0% fulfiller proof to work properly um the 00:42:41.800 --> 00:42:43.630 align:start position:0% fulfiller proof to work properly um the logic<00:42:42.160> by<00:42:42.319> itself<00:42:42.640> should<00:42:42.960> should<00:42:43.240> work<00:42:43.400> fine 00:42:43.630 --> 00:42:43.640 align:start position:0% logic by itself should should work fine 00:42:43.640 --> 00:42:45.349 align:start position:0% logic by itself should should work fine either<00:42:43.920> way<00:42:44.240> but<00:42:44.599> in<00:42:44.680> order<00:42:44.880> for<00:42:45.040> this<00:42:45.119> to<00:42:45.240> be 00:42:45.349 --> 00:42:45.359 align:start position:0% either way but in order for this to be 00:42:45.359 --> 00:42:46.549 align:start position:0% either way but in order for this to be compatible<00:42:45.800> with<00:42:45.960> the<00:42:46.079> the<00:42:46.160> surrounding 00:42:46.549 --> 00:42:46.559 align:start position:0% compatible with the the surrounding 00:42:46.559 --> 00:42:47.710 align:start position:0% compatible with the the surrounding system<00:42:46.880> we<00:42:47.000> have<00:42:47.079> to<00:42:47.240> we<00:42:47.359> have<00:42:47.440> to<00:42:47.520> use<00:42:47.640> the 00:42:47.710 --> 00:42:47.720 align:start position:0% system we have to we have to use the 00:42:47.720 --> 00:42:49.790 align:start position:0% system we have to we have to use the correct 00:42:49.790 --> 00:42:49.800 align:start position:0% correct 00:42:49.800 --> 00:42:53.349 align:start position:0% correct names<00:42:50.800> so<00:42:51.040> if<00:42:51.280> we<00:42:51.520> have<00:42:52.359> the<00:42:52.640> L2<00:42:53.079> block 00:42:53.349 --> 00:42:53.359 align:start position:0% names so if we have the L2 block 00:42:53.359 --> 00:42:56.829 align:start position:0% names so if we have the L2 block timestamp<00:42:53.960> here<00:42:54.400> then<00:42:54.760> we<00:42:54.960> have<00:42:55.200> enough<00:42:55.640> to<00:42:56.640> um 00:42:56.829 --> 00:42:56.839 align:start position:0% timestamp here then we have enough to um 00:42:56.839 --> 00:42:58.910 align:start position:0% timestamp here then we have enough to um Direct<00:42:57.200> dve<00:42:57.520> the<00:42:57.599> storage<00:42:58.000> location<00:42:58.640> of<00:42:58.800> the 00:42:58.910 --> 00:42:58.920 align:start position:0% Direct dve the storage location of the 00:42:58.920 --> 00:43:00.950 align:start position:0% Direct dve the storage location of the output<00:42:59.319> route<00:43:00.000> associated<00:43:00.480> with<00:43:00.599> that<00:43:00.720> block 00:43:00.950 --> 00:43:00.960 align:start position:0% output route associated with that block 00:43:00.960 --> 00:43:03.349 align:start position:0% output route associated with that block Tim<00:43:01.160> stamp<00:43:01.520> inside<00:43:01.720> of<00:43:01.800> the<00:43:01.880> rollup<00:43:02.359> contract 00:43:03.349 --> 00:43:03.359 align:start position:0% Tim stamp inside of the rollup contract 00:43:03.359 --> 00:43:06.150 align:start position:0% Tim stamp inside of the rollup contract so<00:43:03.640> how<00:43:03.760> do<00:43:03.880> we<00:43:04.119> do<00:43:04.559> that<00:43:05.559> if<00:43:05.640> we<00:43:05.760> take<00:43:05.880> a<00:43:06.000> look 00:43:06.150 --> 00:43:06.160 align:start position:0% so how do we do that if we take a look 00:43:06.160 --> 00:43:08.069 align:start position:0% so how do we do that if we take a look down<00:43:06.359> here<00:43:06.559> so<00:43:06.760> for<00:43:06.960> step<00:43:07.240> three<00:43:07.800> we're<00:43:07.960> going 00:43:08.069 --> 00:43:08.079 align:start position:0% down here so for step three we're going 00:43:08.079 --> 00:43:10.950 align:start position:0% down here so for step three we're going to<00:43:08.160> be<00:43:08.240> using<00:43:08.480> the<00:43:08.599> L1<00:43:08.920> State<00:43:09.480> Route<00:43:10.480> and<00:43:10.839> this 00:43:10.950 --> 00:43:10.960 align:start position:0% to be using the L1 State Route and this 00:43:10.960 --> 00:43:13.790 align:start position:0% to be using the L1 State Route and this is<00:43:11.200> the<00:43:11.480> first<00:43:12.280> example<00:43:13.000> of<00:43:13.319> an<00:43:13.520> actual 00:43:13.790 --> 00:43:13.800 align:start position:0% is the first example of an actual 00:43:13.800 --> 00:43:15.510 align:start position:0% is the first example of an actual storage<00:43:14.200> proof<00:43:14.440> that<00:43:14.520> we're<00:43:14.640> going<00:43:14.720> to 00:43:15.510 --> 00:43:15.520 align:start position:0% storage proof that we're going to 00:43:15.520 --> 00:43:18.870 align:start position:0% storage proof that we're going to use<00:43:16.520> so<00:43:17.119> this<00:43:17.280> is<00:43:17.520> where<00:43:17.839> we<00:43:18.000> would<00:43:18.359> maybe<00:43:18.680> want 00:43:18.870 --> 00:43:18.880 align:start position:0% use so this is where we would maybe want 00:43:18.880 --> 00:43:20.950 align:start position:0% use so this is where we would maybe want to<00:43:19.280> take<00:43:19.440> a<00:43:19.599> look<00:43:19.880> at<00:43:20.079> that<00:43:20.240> State<00:43:20.480> validator 00:43:20.950 --> 00:43:20.960 align:start position:0% to take a look at that State validator 00:43:20.960 --> 00:43:22.390 align:start position:0% to take a look at that State validator Library<00:43:21.440> again<00:43:21.680> because<00:43:21.880> this<00:43:22.000> has<00:43:22.119> a<00:43:22.240> bunch 00:43:22.390 --> 00:43:22.400 align:start position:0% Library again because this has a bunch 00:43:22.400 --> 00:43:25.470 align:start position:0% Library again because this has a bunch of<00:43:22.520> utility<00:43:22.960> functions<00:43:23.680> for<00:43:24.680> um<00:43:24.920> facilitating 00:43:25.470 --> 00:43:25.480 align:start position:0% of utility functions for um facilitating 00:43:25.480 --> 00:43:28.190 align:start position:0% of utility functions for um facilitating storage<00:43:25.839> proofs<00:43:26.359> directly 00:43:28.190 --> 00:43:28.200 align:start position:0% storage proofs directly 00:43:28.200 --> 00:43:29.870 align:start position:0% storage proofs directly be<00:43:28.359> namely<00:43:28.720> being<00:43:29.040> this<00:43:29.319> account<00:43:29.599> proof 00:43:29.870 --> 00:43:29.880 align:start position:0% be namely being this account proof 00:43:29.880 --> 00:43:31.390 align:start position:0% be namely being this account proof parameter<00:43:30.319> struct<00:43:30.839> this<00:43:30.960> is<00:43:31.079> going<00:43:31.160> to<00:43:31.280> come 00:43:31.390 --> 00:43:31.400 align:start position:0% parameter struct this is going to come 00:43:31.400 --> 00:43:33.750 align:start position:0% parameter struct this is going to come in<00:43:31.520> handy<00:43:32.240> um<00:43:32.480> and<00:43:32.599> then<00:43:32.920> that<00:43:33.400> second 00:43:33.750 --> 00:43:33.760 align:start position:0% in handy um and then that second 00:43:33.760 --> 00:43:35.270 align:start position:0% in handy um and then that second function<00:43:34.119> I<00:43:34.200> mentioned<00:43:34.559> for<00:43:34.720> validating 00:43:35.270 --> 00:43:35.280 align:start position:0% function I mentioned for validating 00:43:35.280 --> 00:43:38.510 align:start position:0% function I mentioned for validating account<00:43:35.720> storage<00:43:36.720> so<00:43:37.520> um<00:43:37.760> we'll<00:43:38.040> actually<00:43:38.359> be 00:43:38.510 --> 00:43:38.520 align:start position:0% account storage so um we'll actually be 00:43:38.520 --> 00:43:41.069 align:start position:0% account storage so um we'll actually be using<00:43:38.880> this<00:43:39.040> function<00:43:39.520> here<00:43:40.520> this<00:43:40.680> takes<00:43:40.920> in 00:43:41.069 --> 00:43:41.079 align:start position:0% using this function here this takes in 00:43:41.079 --> 00:43:43.190 align:start position:0% using this function here this takes in an<00:43:41.319> account<00:43:41.559> a<00:43:41.720> state<00:43:41.960> rout<00:43:42.319> and<00:43:42.480> then<00:43:42.760> a<00:43:42.920> proof 00:43:43.190 --> 00:43:43.200 align:start position:0% an account a state rout and then a proof 00:43:43.200 --> 00:43:44.549 align:start position:0% an account a state rout and then a proof parameters<00:43:43.680> that<00:43:43.760> should<00:43:43.920> be<00:43:44.119> provided<00:43:44.440> by 00:43:44.549 --> 00:43:44.559 align:start position:0% parameters that should be provided by 00:43:44.559 --> 00:43:46.589 align:start position:0% parameters that should be provided by the<00:43:44.839> fulfiller<00:43:45.839> so<00:43:45.960> we<00:43:46.040> can<00:43:46.160> start<00:43:46.319> to<00:43:46.440> set 00:43:46.589 --> 00:43:46.599 align:start position:0% the fulfiller so we can start to set 00:43:46.599 --> 00:43:50.670 align:start position:0% the fulfiller so we can start to set that<00:43:46.720> up<00:43:46.920> now<00:43:47.440> starting<00:43:47.800> with<00:43:48.000> State 00:43:50.670 --> 00:43:50.680 align:start position:0% 00:43:50.680 --> 00:43:54.109 align:start position:0% validator<00:43:51.680> and<00:43:51.760> then<00:43:52.440> validate<00:43:53.000> account 00:43:54.109 --> 00:43:54.119 align:start position:0% validator and then validate account 00:43:54.119 --> 00:43:56.630 align:start position:0% validator and then validate account storage<00:43:55.119> my<00:43:55.240> autocomplete<00:43:55.880> added<00:43:56.319> the<00:43:56.440> names 00:43:56.630 --> 00:43:56.640 align:start position:0% storage my autocomplete added the names 00:43:56.640 --> 00:43:57.790 align:start position:0% storage my autocomplete added the names of<00:43:56.720> the<00:43:56.800> variable 00:43:57.790 --> 00:43:57.800 align:start position:0% of the variable 00:43:57.800 --> 00:44:01.309 align:start position:0% of the variable here<00:43:58.800> so<00:43:59.800> for<00:44:00.040> the<00:44:00.240> account<00:44:00.839> what<00:44:01.000> what's<00:44:01.200> the 00:44:01.309 --> 00:44:01.319 align:start position:0% here so for the account what what's the 00:44:01.319 --> 00:44:02.870 align:start position:0% here so for the account what what's the account<00:44:01.559> here<00:44:01.720> this<00:44:01.839> is<00:44:01.920> the<00:44:02.079> rollup<00:44:02.520> contract 00:44:02.870 --> 00:44:02.880 align:start position:0% account here this is the rollup contract 00:44:02.880 --> 00:44:05.430 align:start position:0% account here this is the rollup contract for<00:44:03.040> the<00:44:03.200> destination<00:44:03.839> chain<00:44:04.839> and<00:44:05.200> if<00:44:05.280> you 00:44:05.430 --> 00:44:05.440 align:start position:0% for the destination chain and if you 00:44:05.440 --> 00:44:07.390 align:start position:0% for the destination chain and if you remember<00:44:05.960> from<00:44:06.520> whoops<00:44:06.800> if<00:44:06.920> you<00:44:07.040> remember 00:44:07.390 --> 00:44:07.400 align:start position:0% remember from whoops if you remember 00:44:07.400 --> 00:44:09.549 align:start position:0% remember from whoops if you remember from<00:44:07.599> the<00:44:07.720> Str<00:44:08.240> file<00:44:08.680> that<00:44:08.839> I<00:44:09.040> walked<00:44:09.319> through 00:44:09.549 --> 00:44:09.559 align:start position:0% from the Str file that I walked through 00:44:09.559 --> 00:44:11.670 align:start position:0% from the Str file that I walked through at<00:44:09.640> the<00:44:09.839> beginning<00:44:10.839> one<00:44:10.960> of<00:44:11.079> the<00:44:11.200> fields<00:44:11.559> that 00:44:11.670 --> 00:44:11.680 align:start position:0% at the beginning one of the fields that 00:44:11.680 --> 00:44:13.990 align:start position:0% at the beginning one of the fields that is<00:44:11.880> specified<00:44:12.400> by<00:44:12.520> the<00:44:12.640> requester<00:44:13.319> is<00:44:13.480> this<00:44:13.599> L2 00:44:13.990 --> 00:44:14.000 align:start position:0% is specified by the requester is this L2 00:44:14.000 --> 00:44:15.829 align:start position:0% is specified by the requester is this L2 Oracle<00:44:14.400> address<00:44:14.839> and<00:44:14.960> this<00:44:15.079> is<00:44:15.280> exactly<00:44:15.680> the 00:44:15.829 --> 00:44:15.839 align:start position:0% Oracle address and this is exactly the 00:44:15.839 --> 00:44:17.069 align:start position:0% Oracle address and this is exactly the account<00:44:16.079> that<00:44:16.200> we<00:44:16.319> care<00:44:16.520> about<00:44:16.720> for<00:44:16.880> this 00:44:17.069 --> 00:44:17.079 align:start position:0% account that we care about for this 00:44:17.079 --> 00:44:19.790 align:start position:0% account that we care about for this first<00:44:17.680> storage<00:44:18.079> proof<00:44:18.960> so<00:44:19.160> we<00:44:19.240> can<00:44:19.440> pass<00:44:19.640> that 00:44:19.790 --> 00:44:19.800 align:start position:0% first storage proof so we can pass that 00:44:19.800 --> 00:44:21.670 align:start position:0% first storage proof so we can pass that in<00:44:20.119> here<00:44:20.640> um<00:44:20.760> this<00:44:20.839> is<00:44:20.960> going<00:44:21.079> to<00:44:21.200> come<00:44:21.359> from 00:44:21.670 --> 00:44:21.680 align:start position:0% in here um this is going to come from 00:44:21.680 --> 00:44:23.950 align:start position:0% in here um this is going to come from request<00:44:22.200> which<00:44:22.319> is<00:44:22.440> being<00:44:22.680> passed<00:44:22.960> in<00:44:23.720> so<00:44:23.880> this 00:44:23.950 --> 00:44:23.960 align:start position:0% request which is being passed in so this 00:44:23.960 --> 00:44:25.510 align:start position:0% request which is being passed in so this will<00:44:24.119> be 00:44:25.510 --> 00:44:25.520 align:start position:0% will be 00:44:25.520 --> 00:44:28.910 align:start position:0% will be request.<00:44:26.520> L2<00:44:27.160> Oracle<00:44:27.960> for<00:44:28.160> the 00:44:28.910 --> 00:44:28.920 align:start position:0% request. L2 Oracle for the 00:44:28.920 --> 00:44:31.230 align:start position:0% request. L2 Oracle for the account<00:44:29.920> the<00:44:30.079> state<00:44:30.280> root<00:44:30.520> is<00:44:30.599> the<00:44:30.720> L1<00:44:31.040> State 00:44:31.230 --> 00:44:31.240 align:start position:0% account the state root is the L1 State 00:44:31.240 --> 00:44:33.549 align:start position:0% account the state root is the L1 State rout<00:44:31.480> that<00:44:31.599> we<00:44:31.800> just<00:44:32.079> decoded<00:44:32.680> here<00:44:33.040> so<00:44:33.200> we<00:44:33.319> can 00:44:33.549 --> 00:44:33.559 align:start position:0% rout that we just decoded here so we can 00:44:33.559 --> 00:44:35.190 align:start position:0% rout that we just decoded here so we can use<00:44:33.880> this<00:44:34.160> for<00:44:34.359> State 00:44:35.190 --> 00:44:35.200 align:start position:0% use this for State 00:44:35.200 --> 00:44:37.230 align:start position:0% use this for State root<00:44:36.200> and<00:44:36.280> then<00:44:36.400> the<00:44:36.559> account<00:44:36.880> proof 00:44:37.230 --> 00:44:37.240 align:start position:0% root and then the account proof 00:44:37.240 --> 00:44:40.510 align:start position:0% root and then the account proof parameters<00:44:38.240> uh<00:44:38.599> this<00:44:38.720> is<00:44:39.000> this<00:44:40.000> account<00:44:40.319> proof 00:44:40.510 --> 00:44:40.520 align:start position:0% parameters uh this is this account proof 00:44:40.520 --> 00:44:42.829 align:start position:0% parameters uh this is this account proof parameter<00:44:41.160> struct<00:44:42.160> inside<00:44:42.440> of<00:44:42.520> the<00:44:42.599> state 00:44:42.829 --> 00:44:42.839 align:start position:0% parameter struct inside of the state 00:44:42.839 --> 00:44:45.030 align:start position:0% parameter struct inside of the state validator<00:44:43.720> this<00:44:43.920> is<00:44:44.079> going<00:44:44.200> to<00:44:44.319> be<00:44:44.480> supplied 00:44:45.030 --> 00:44:45.040 align:start position:0% validator this is going to be supplied 00:44:45.040 --> 00:44:47.549 align:start position:0% validator this is going to be supplied by<00:44:45.200> the<00:44:45.319> offchain<00:44:45.760> fulfiller<00:44:46.760> so<00:44:47.119> this<00:44:47.240> is<00:44:47.400> the 00:44:47.549 --> 00:44:47.559 align:start position:0% by the offchain fulfiller so this is the 00:44:47.559 --> 00:44:49.270 align:start position:0% by the offchain fulfiller so this is the next<00:44:47.800> piece<00:44:47.960> of<00:44:48.160> information<00:44:48.599> we<00:44:48.720> need<00:44:49.000> in<00:44:49.119> our 00:44:49.270 --> 00:44:49.280 align:start position:0% next piece of information we need in our 00:44:49.280 --> 00:44:52.430 align:start position:0% next piece of information we need in our proof<00:44:49.559> struct<00:44:50.559> so<00:44:50.720> if<00:44:50.800> we<00:44:50.920> copy 00:44:52.430 --> 00:44:52.440 align:start position:0% proof struct so if we copy 00:44:52.440 --> 00:44:54.870 align:start position:0% proof struct so if we copy this<00:44:53.440> add<00:44:53.599> it<00:44:53.720> as<00:44:53.839> a<00:44:54.000> third<00:44:54.280> argument<00:44:54.640> in<00:44:54.760> the 00:44:54.870 --> 00:44:54.880 align:start position:0% this add it as a third argument in the 00:44:54.880 --> 00:44:58.430 align:start position:0% this add it as a third argument in the proof<00:44:55.160> struct<00:44:55.599> or<00:44:55.800> third<00:44:56.040> field<00:44:57.280> oops<00:44:58.040> um<00:44:58.359> this 00:44:58.430 --> 00:44:58.440 align:start position:0% proof struct or third field oops um this 00:44:58.440 --> 00:45:01.910 align:start position:0% proof struct or third field oops um this will<00:44:58.640> be<00:44:59.160> state<00:45:00.040> validator<00:45:01.040> do<00:45:01.240> account<00:45:01.520> proof 00:45:01.910 --> 00:45:01.920 align:start position:0% will be state validator do account proof 00:45:01.920 --> 00:45:03.670 align:start position:0% will be state validator do account proof parameters<00:45:02.920> and<00:45:03.000> we're<00:45:03.119> going<00:45:03.200> to<00:45:03.359> call<00:45:03.559> this 00:45:03.670 --> 00:45:03.680 align:start position:0% parameters and we're going to call this 00:45:03.680 --> 00:45:14.230 align:start position:0% parameters and we're going to call this one<00:45:04.040> DST<00:45:05.480> L2<00:45:06.480> State<00:45:07.200> root<00:45:08.200> proof<00:45:09.119> or 00:45:14.230 --> 00:45:14.240 align:start position:0% 00:45:14.240 --> 00:45:16.430 align:start position:0% Rams<00:45:15.240> so<00:45:15.400> then<00:45:15.480> we<00:45:15.559> can<00:45:15.720> copy<00:45:15.960> that<00:45:16.079> variable 00:45:16.430 --> 00:45:16.440 align:start position:0% Rams so then we can copy that variable 00:45:16.440 --> 00:45:17.990 align:start position:0% Rams so then we can copy that variable name<00:45:16.800> and<00:45:16.920> this<00:45:17.000> will<00:45:17.119> be<00:45:17.240> the<00:45:17.400> last<00:45:17.599> argument 00:45:17.990 --> 00:45:18.000 align:start position:0% name and this will be the last argument 00:45:18.000 --> 00:45:20.150 align:start position:0% name and this will be the last argument passed<00:45:18.280> into<00:45:18.760> our<00:45:19.079> validate<00:45:19.559> account<00:45:19.800> storage 00:45:20.150 --> 00:45:20.160 align:start position:0% passed into our validate account storage 00:45:20.160 --> 00:45:23.030 align:start position:0% passed into our validate account storage function<00:45:21.119> so<00:45:21.280> this<00:45:21.359> will<00:45:21.520> be<00:45:21.760> proof<00:45:22.480> Dot<00:45:22.920> and 00:45:23.030 --> 00:45:23.040 align:start position:0% function so this will be proof Dot and 00:45:23.040 --> 00:45:31.270 align:start position:0% function so this will be proof Dot and then<00:45:23.480> that<00:45:23.800> copied<00:45:24.440> field<00:45:24.800> name 00:45:31.270 --> 00:45:31.280 align:start position:0% 00:45:31.280 --> 00:45:32.510 align:start position:0% if<00:45:31.359> you<00:45:31.520> take<00:45:31.640> a<00:45:31.760> look<00:45:31.920> at<00:45:32.040> the<00:45:32.160> validate 00:45:32.510 --> 00:45:32.520 align:start position:0% if you take a look at the validate 00:45:32.520 --> 00:45:33.910 align:start position:0% if you take a look at the validate account<00:45:32.760> storage<00:45:33.079> function<00:45:33.440> here<00:45:33.680> you<00:45:33.800> can 00:45:33.910 --> 00:45:33.920 align:start position:0% account storage function here you can 00:45:33.920 --> 00:45:36.510 align:start position:0% account storage function here you can see<00:45:34.079> that<00:45:34.200> it<00:45:34.400> returns<00:45:34.640> a<00:45:34.760> Boolean<00:45:35.240> value<00:45:36.160> um 00:45:36.510 --> 00:45:36.520 align:start position:0% see that it returns a Boolean value um 00:45:36.520 --> 00:45:38.150 align:start position:0% see that it returns a Boolean value um so<00:45:36.760> we<00:45:36.839> need<00:45:37.000> to<00:45:37.200> ensure<00:45:37.520> that<00:45:37.640> the<00:45:37.760> Boolean 00:45:38.150 --> 00:45:38.160 align:start position:0% so we need to ensure that the Boolean 00:45:38.160 --> 00:45:41.230 align:start position:0% so we need to ensure that the Boolean value<00:45:38.599> returned<00:45:39.000> is<00:45:39.520> true<00:45:40.520> so<00:45:40.640> we<00:45:40.760> can<00:45:40.920> capture 00:45:41.230 --> 00:45:41.240 align:start position:0% value returned is true so we can capture 00:45:41.240 --> 00:45:43.069 align:start position:0% value returned is true so we can capture that<00:45:41.359> in<00:45:41.440> a<00:45:41.520> local<00:45:41.760> variable<00:45:42.200> here<00:45:42.760> uh<00:45:42.839> we<00:45:42.960> can 00:45:43.069 --> 00:45:43.079 align:start position:0% that in a local variable here uh we can 00:45:43.079 --> 00:45:44.030 align:start position:0% that in a local variable here uh we can call<00:45:43.200> it 00:45:44.030 --> 00:45:44.040 align:start position:0% call it 00:45:44.040 --> 00:45:48.390 align:start position:0% call it bu<00:45:45.040> um<00:45:45.480> is<00:45:46.040> valid<00:45:46.760> L1 00:45:48.390 --> 00:45:48.400 align:start position:0% bu um is valid L1 00:45:48.400 --> 00:45:51.030 align:start position:0% bu um is valid L1 state<00:45:49.400> is<00:45:49.559> equal<00:45:49.839> to<00:45:49.960> the<00:45:50.079> state<00:45:50.319> validator 00:45:51.030 --> 00:45:51.040 align:start position:0% state is equal to the state validator 00:45:51.040 --> 00:45:52.589 align:start position:0% state is equal to the state validator validate<00:45:51.400> account 00:45:52.589 --> 00:45:52.599 align:start position:0% validate account 00:45:52.599 --> 00:45:55.230 align:start position:0% validate account storage<00:45:53.599> and<00:45:53.760> then<00:45:53.960> for<00:45:54.359> when<00:45:54.680> it's<00:45:54.920> not<00:45:55.119> a 00:45:55.230 --> 00:45:55.240 align:start position:0% storage and then for when it's not a 00:45:55.240 --> 00:45:58.309 align:start position:0% storage and then for when it's not a valid<00:45:55.520> L1<00:45:55.880> State<00:45:56.160> we<00:45:56.240> can<00:45:56.359> define<00:45:56.599> a<00:45:56.680> c 00:45:58.309 --> 00:45:58.319 align:start position:0% valid L1 State we can define a c 00:45:58.319 --> 00:46:00.630 align:start position:0% valid L1 State we can define a c error<00:45:59.319> up 00:46:00.630 --> 00:46:00.640 align:start position:0% error up 00:46:00.640 --> 00:46:07.829 align:start position:0% error up here<00:46:01.640> this<00:46:01.760> will<00:46:01.920> be<00:46:02.119> error<00:46:03.359> invalid<00:46:04.359> L1 00:46:07.829 --> 00:46:07.839 align:start position:0% 00:46:07.839 --> 00:46:10.430 align:start position:0% State<00:46:08.839> copy 00:46:10.430 --> 00:46:10.440 align:start position:0% State copy 00:46:10.440 --> 00:46:12.990 align:start position:0% State copy that<00:46:11.440> and<00:46:11.559> then 00:46:12.990 --> 00:46:13.000 align:start position:0% that and then 00:46:13.000 --> 00:46:17.870 align:start position:0% that and then if<00:46:14.000> not<00:46:14.680> is<00:46:15.000> valid<00:46:15.280> L1<00:46:15.960> State<00:46:16.960> we'll<00:46:17.240> revert 00:46:17.870 --> 00:46:17.880 align:start position:0% if not is valid L1 State we'll revert 00:46:17.880 --> 00:46:20.829 align:start position:0% if not is valid L1 State we'll revert with<00:46:18.040> that<00:46:18.200> custom 00:46:20.829 --> 00:46:20.839 align:start position:0% 00:46:20.839 --> 00:46:23.109 align:start position:0% error<00:46:21.839> and<00:46:22.079> there<00:46:22.200> we 00:46:23.109 --> 00:46:23.119 align:start position:0% error and there we 00:46:23.119 --> 00:46:26.150 align:start position:0% error and there we go<00:46:24.119> as<00:46:24.760> uh<00:46:25.160> all<00:46:25.280> right<00:46:25.440> so<00:46:25.640> what<00:46:25.760> we<00:46:25.880> have 00:46:26.150 --> 00:46:26.160 align:start position:0% go as uh all right so what we have 00:46:26.160 --> 00:46:28.390 align:start position:0% go as uh all right so what we have Happening<00:46:26.599> Here<00:46:27.200> is<00:46:27.559> after<00:46:27.800> this<00:46:28.000> step<00:46:28.280> we 00:46:28.390 --> 00:46:28.400 align:start position:0% Happening Here is after this step we 00:46:28.400 --> 00:46:30.870 align:start position:0% Happening Here is after this step we should<00:46:28.680> have<00:46:28.880> a<00:46:29.280> verified<00:46:30.280> um<00:46:30.440> storage 00:46:30.870 --> 00:46:30.880 align:start position:0% should have a verified um storage 00:46:30.880 --> 00:46:31.990 align:start position:0% should have a verified um storage location<00:46:31.280> in 00:46:31.990 --> 00:46:32.000 align:start position:0% location in 00:46:32.000 --> 00:46:35.230 align:start position:0% location in L1<00:46:33.000> to<00:46:33.280> jog<00:46:33.559> your<00:46:33.760> memory<00:46:34.240> on<00:46:34.520> the<00:46:34.680> prams<00:46:35.119> that 00:46:35.230 --> 00:46:35.240 align:start position:0% L1 to jog your memory on the prams that 00:46:35.240 --> 00:46:37.349 align:start position:0% L1 to jog your memory on the prams that are<00:46:35.319> being<00:46:35.520> passed<00:46:35.760> in<00:46:35.920> by<00:46:36.040> the<00:46:36.359> fulfiller 00:46:37.349 --> 00:46:37.359 align:start position:0% are being passed in by the fulfiller 00:46:37.359 --> 00:46:39.309 align:start position:0% are being passed in by the fulfiller there<00:46:37.599> is<00:46:37.960> something<00:46:38.520> kind<00:46:38.680> of<00:46:38.839> fishy 00:46:39.309 --> 00:46:39.319 align:start position:0% there is something kind of fishy 00:46:39.319 --> 00:46:40.589 align:start position:0% there is something kind of fishy happening<00:46:39.720> with<00:46:39.839> the<00:46:39.960> way<00:46:40.079> we<00:46:40.160> currently<00:46:40.480> have 00:46:40.589 --> 00:46:40.599 align:start position:0% happening with the way we currently have 00:46:40.599 --> 00:46:43.589 align:start position:0% happening with the way we currently have it<00:46:40.760> set<00:46:41.319> up<00:46:42.319> these<00:46:42.559> account<00:46:42.880> proof<00:46:43.119> parameters 00:46:43.589 --> 00:46:43.599 align:start position:0% it set up these account proof parameters 00:46:43.599 --> 00:46:46.150 align:start position:0% it set up these account proof parameters specify<00:46:44.119> an<00:46:44.319> exact<00:46:44.880> storage<00:46:45.319> location<00:46:45.920> and 00:46:46.150 --> 00:46:46.160 align:start position:0% specify an exact storage location and 00:46:46.160 --> 00:46:49.549 align:start position:0% specify an exact storage location and expected<00:46:46.960> value<00:46:47.960> um<00:46:48.119> so<00:46:48.400> if<00:46:48.599> this<00:46:48.839> checks<00:46:49.160> out 00:46:49.549 --> 00:46:49.559 align:start position:0% expected value um so if this checks out 00:46:49.559 --> 00:46:50.910 align:start position:0% expected value um so if this checks out and<00:46:49.839> returns<00:46:50.079> true<00:46:50.359> it<00:46:50.440> means<00:46:50.680> we've 00:46:50.910 --> 00:46:50.920 align:start position:0% and returns true it means we've 00:46:50.920 --> 00:46:53.349 align:start position:0% and returns true it means we've successfully<00:46:51.480> validated<00:46:52.000> that<00:46:52.200> location<00:46:53.200> but 00:46:53.349 --> 00:46:53.359 align:start position:0% successfully validated that location but 00:46:53.359 --> 00:46:54.790 align:start position:0% successfully validated that location but what<00:46:53.480> if<00:46:53.599> that<00:46:53.720> location's<00:46:54.400> the<00:46:54.559> wrong 00:46:54.790 --> 00:46:54.800 align:start position:0% what if that location's the wrong 00:46:54.800 --> 00:46:56.309 align:start position:0% what if that location's the wrong location<00:46:55.280> like<00:46:55.400> what<00:46:55.520> if<00:46:55.599> it's<00:46:55.800> not<00:46:56.000> the<00:46:56.119> state 00:46:56.309 --> 00:46:56.319 align:start position:0% location like what if it's not the state 00:46:56.319 --> 00:46:58.670 align:start position:0% location like what if it's not the state representation<00:46:57.040> for<00:46:57.160> the<00:46:57.280> destination<00:46:57.800> chain 00:46:58.670 --> 00:46:58.680 align:start position:0% representation for the destination chain 00:46:58.680 --> 00:47:02.030 align:start position:0% representation for the destination chain that<00:46:58.800> would<00:46:58.920> be<00:46:59.040> a<00:46:59.200> problem<00:46:59.760> so<00:47:00.720> um<00:47:01.720> this<00:47:01.839> is 00:47:02.030 --> 00:47:02.040 align:start position:0% that would be a problem so um this is 00:47:02.040 --> 00:47:04.190 align:start position:0% that would be a problem so um this is where<00:47:02.200> we'd<00:47:02.480> want<00:47:02.640> to<00:47:02.920> override<00:47:03.680> the<00:47:03.800> storage 00:47:04.190 --> 00:47:04.200 align:start position:0% where we'd want to override the storage 00:47:04.200 --> 00:47:07.030 align:start position:0% where we'd want to override the storage key<00:47:05.040> um<00:47:05.160> we<00:47:05.280> could<00:47:05.480> either<00:47:06.359> derive<00:47:06.839> what<00:47:06.960> it 00:47:07.030 --> 00:47:07.040 align:start position:0% key um we could either derive what it 00:47:07.040 --> 00:47:08.510 align:start position:0% key um we could either derive what it should<00:47:07.240> be<00:47:07.520> and<00:47:07.720> confirm<00:47:08.079> that<00:47:08.200> it's 00:47:08.510 --> 00:47:08.520 align:start position:0% should be and confirm that it's 00:47:08.520 --> 00:47:11.589 align:start position:0% should be and confirm that it's equivalent<00:47:09.359> or<00:47:09.480> we<00:47:09.559> could<00:47:09.720> override<00:47:10.200> it<00:47:11.040> um 00:47:11.589 --> 00:47:11.599 align:start position:0% equivalent or we could override it um 00:47:11.599 --> 00:47:13.710 align:start position:0% equivalent or we could override it um for<00:47:11.839> this<00:47:12.119> example<00:47:12.559> we<00:47:12.720> we'll<00:47:13.040> override<00:47:13.480> it 00:47:13.710 --> 00:47:13.720 align:start position:0% for this example we we'll override it 00:47:13.720 --> 00:47:15.910 align:start position:0% for this example we we'll override it but<00:47:14.160> uh<00:47:14.319> maybe<00:47:14.559> there's<00:47:14.760> a<00:47:15.079> a<00:47:15.319> subtle<00:47:15.720> gas 00:47:15.910 --> 00:47:15.920 align:start position:0% but uh maybe there's a a subtle gas 00:47:15.920 --> 00:47:18.349 align:start position:0% but uh maybe there's a a subtle gas optimization<00:47:16.480> one<00:47:16.599> way<00:47:16.880> over<00:47:17.079> the<00:47:17.200> other<00:47:18.119> um 00:47:18.349 --> 00:47:18.359 align:start position:0% optimization one way over the other um 00:47:18.359 --> 00:47:20.670 align:start position:0% optimization one way over the other um but<00:47:18.480> for<00:47:18.720> starters<00:47:19.480> we'll<00:47:19.720> want<00:47:19.880> to<00:47:20.119> create<00:47:20.520> a 00:47:20.670 --> 00:47:20.680 align:start position:0% but for starters we'll want to create a 00:47:20.680 --> 00:47:22.750 align:start position:0% but for starters we'll want to create a helper<00:47:21.079> function<00:47:21.480> for<00:47:21.800> deriving<00:47:22.240> what<00:47:22.319> the<00:47:22.440> L1 00:47:22.750 --> 00:47:22.760 align:start position:0% helper function for deriving what the L1 00:47:22.760 --> 00:47:24.870 align:start position:0% helper function for deriving what the L1 storage<00:47:23.119> key<00:47:23.359> should<00:47:23.559> be<00:47:24.200> so<00:47:24.359> we<00:47:24.440> can<00:47:24.599> create 00:47:24.870 --> 00:47:24.880 align:start position:0% storage key should be so we can create 00:47:24.880 --> 00:47:26.349 align:start position:0% storage key should be so we can create that<00:47:25.040> down<00:47:25.240> here<00:47:25.480> as<00:47:25.559> a<00:47:25.720> private<00:47:26.040> helper 00:47:26.349 --> 00:47:26.359 align:start position:0% that down here as a private helper 00:47:26.359 --> 00:47:28.790 align:start position:0% that down here as a private helper function 00:47:28.790 --> 00:47:28.800 align:start position:0% function 00:47:28.800 --> 00:47:33.510 align:start position:0% function derive<00:47:29.359> L1<00:47:30.559> storage<00:47:31.559> key<00:47:32.480> this<00:47:32.599> will<00:47:32.760> be<00:47:33.079> a 00:47:33.510 --> 00:47:33.520 align:start position:0% derive L1 storage key this will be a 00:47:33.520 --> 00:47:35.069 align:start position:0% derive L1 storage key this will be a private 00:47:35.069 --> 00:47:35.079 align:start position:0% private 00:47:35.079 --> 00:47:38.510 align:start position:0% private Pier<00:47:36.079> returns<00:47:37.000> bytes 00:47:38.510 --> 00:47:38.520 align:start position:0% Pier returns bytes 00:47:38.520 --> 00:47:40.390 align:start position:0% Pier returns bytes memory<00:47:39.520> because<00:47:39.720> as<00:47:39.800> you<00:47:39.920> see<00:47:40.079> up<00:47:40.200> here<00:47:40.319> the 00:47:40.390 --> 00:47:40.400 align:start position:0% memory because as you see up here the 00:47:40.400 --> 00:47:42.510 align:start position:0% memory because as you see up here the storage<00:47:40.720> key<00:47:40.880> is<00:47:40.960> a<00:47:41.079> by<00:47:41.280> string<00:47:41.599> not<00:47:41.720> a<00:47:41.800> byes<00:47:42.040> 32 00:47:42.510 --> 00:47:42.520 align:start position:0% storage key is a by string not a byes 32 00:47:42.520 --> 00:47:45.190 align:start position:0% storage key is a by string not a byes 32 or<00:47:42.680> anything<00:47:43.200> so 00:47:45.190 --> 00:47:45.200 align:start position:0% or anything so 00:47:45.200 --> 00:47:48.470 align:start position:0% or anything so um<00:47:46.200> yeah<00:47:46.440> so<00:47:47.040> this<00:47:47.119> is<00:47:47.280> the<00:47:47.400> storage<00:47:47.800> key<00:47:48.200> of 00:47:48.470 --> 00:47:48.480 align:start position:0% um yeah so this is the storage key of 00:47:48.480 --> 00:47:50.270 align:start position:0% um yeah so this is the storage key of where<00:47:48.680> the<00:47:48.800> state<00:47:49.079> representation<00:47:49.680> should<00:47:49.920> be 00:47:50.270 --> 00:47:50.280 align:start position:0% where the state representation should be 00:47:50.280 --> 00:47:52.829 align:start position:0% where the state representation should be in<00:47:50.440> the<00:47:50.559> rollup<00:47:51.000> contract<00:47:51.319> on<00:47:51.440> L1<00:47:52.000> so<00:47:52.599> we<00:47:52.680> can 00:47:52.829 --> 00:47:52.839 align:start position:0% in the rollup contract on L1 so we can 00:47:52.839 --> 00:47:54.150 align:start position:0% in the rollup contract on L1 so we can take<00:47:52.920> a<00:47:53.040> look<00:47:53.160> at<00:47:53.240> this<00:47:53.359> rollup<00:47:53.720> contract 00:47:54.150 --> 00:47:54.160 align:start position:0% take a look at this rollup contract 00:47:54.160 --> 00:47:57.190 align:start position:0% take a look at this rollup contract again<00:47:54.920> to<00:47:55.119> see<00:47:55.920> uh<00:47:56.119> how<00:47:56.280> that<00:47:56.400> storage<00:47:56.920> layout 00:47:57.190 --> 00:47:57.200 align:start position:0% again to see uh how that storage layout 00:47:57.200 --> 00:48:00.549 align:start position:0% again to see uh how that storage layout is<00:47:57.319> set<00:47:57.520> up<00:47:58.480> we<00:47:58.720> have<00:47:59.040> a<00:47:59.200> mapping<00:47:59.640> located<00:48:00.200> at 00:48:00.549 --> 00:48:00.559 align:start position:0% is set up we have a mapping located at 00:48:00.559 --> 00:48:03.349 align:start position:0% is set up we have a mapping located at the<00:48:00.760> first<00:48:01.160> storage<00:48:01.599> slot<00:48:02.480> which<00:48:02.720> likely<00:48:03.200> is 00:48:03.349 --> 00:48:03.359 align:start position:0% the first storage slot which likely is 00:48:03.359 --> 00:48:07.030 align:start position:0% the first storage slot which likely is going<00:48:03.559> to<00:48:03.800> be<00:48:04.319> the<00:48:05.200> um<00:48:06.200> inside<00:48:06.440> of<00:48:06.559> the<00:48:06.680> Str 00:48:07.030 --> 00:48:07.040 align:start position:0% going to be the um inside of the Str 00:48:07.040 --> 00:48:10.030 align:start position:0% going to be the um inside of the Str file<00:48:07.359> this<00:48:07.480> likely<00:48:07.800> is<00:48:07.960> going<00:48:08.119> to<00:48:08.359> be<00:48:09.359> the<00:48:09.640> L2 00:48:10.030 --> 00:48:10.040 align:start position:0% file this likely is going to be the L2 00:48:10.040 --> 00:48:12.230 align:start position:0% file this likely is going to be the L2 Oracle<00:48:10.359> storage<00:48:10.720> key<00:48:11.119> so<00:48:11.520> I<00:48:11.599> would<00:48:11.800> expect 00:48:12.230 --> 00:48:12.240 align:start position:0% Oracle storage key so I would expect 00:48:12.240 --> 00:48:14.150 align:start position:0% Oracle storage key so I would expect this<00:48:12.400> to<00:48:12.559> be<00:48:12.800> the<00:48:12.880> bytes<00:48:13.119> 32<00:48:13.599> representation 00:48:14.150 --> 00:48:14.160 align:start position:0% this to be the bytes 32 representation 00:48:14.160 --> 00:48:16.790 align:start position:0% this to be the bytes 32 representation of<00:48:14.319> the<00:48:14.440> number<00:48:15.119> one<00:48:16.119> um<00:48:16.280> and<00:48:16.400> then<00:48:16.520> we<00:48:16.640> can 00:48:16.790 --> 00:48:16.800 align:start position:0% of the number one um and then we can 00:48:16.800 --> 00:48:19.549 align:start position:0% of the number one um and then we can take<00:48:17.119> that<00:48:17.440> and<00:48:17.839> hash<00:48:18.280> that<00:48:18.720> with<00:48:19.040> the<00:48:19.160> L2 00:48:19.549 --> 00:48:19.559 align:start position:0% take that and hash that with the L2 00:48:19.559 --> 00:48:22.190 align:start position:0% take that and hash that with the L2 block<00:48:19.839> Tim<00:48:20.079> stamp<00:48:20.920> which<00:48:21.200> under<00:48:21.440> the<00:48:21.599> hood<00:48:22.000> is 00:48:22.190 --> 00:48:22.200 align:start position:0% block Tim stamp which under the hood is 00:48:22.200 --> 00:48:24.549 align:start position:0% block Tim stamp which under the hood is what<00:48:22.599> solidity<00:48:23.079> is<00:48:23.200> doing<00:48:23.599> to<00:48:23.800> generate<00:48:24.319> the 00:48:24.549 --> 00:48:24.559 align:start position:0% what solidity is doing to generate the 00:48:24.559 --> 00:48:26.109 align:start position:0% what solidity is doing to generate the storage<00:48:24.920> location<00:48:25.280> for<00:48:25.440> the<00:48:25.640> value<00:48:26.000> that 00:48:26.109 --> 00:48:26.119 align:start position:0% storage location for the value that 00:48:26.119 --> 00:48:28.390 align:start position:0% storage location for the value that should<00:48:26.319> be<00:48:27.119> um<00:48:27.319> keyed<00:48:27.800> by<00:48:28.040> the<00:48:28.160> block 00:48:28.390 --> 00:48:28.400 align:start position:0% should be um keyed by the block 00:48:28.400 --> 00:48:30.349 align:start position:0% should be um keyed by the block timestamp<00:48:29.200> so<00:48:29.359> that's<00:48:29.520> exactly<00:48:29.839> what<00:48:29.960> we<00:48:30.079> can 00:48:30.349 --> 00:48:30.359 align:start position:0% timestamp so that's exactly what we can 00:48:30.359 --> 00:48:32.309 align:start position:0% timestamp so that's exactly what we can recreate 00:48:32.309 --> 00:48:32.319 align:start position:0% recreate 00:48:32.319 --> 00:48:35.430 align:start position:0% recreate here<00:48:33.319> in<00:48:33.440> order<00:48:33.640> to<00:48:33.839> do<00:48:34.079> that<00:48:34.559> we<00:48:35.079> need<00:48:35.319> a 00:48:35.430 --> 00:48:35.440 align:start position:0% here in order to do that we need a 00:48:35.440 --> 00:48:37.910 align:start position:0% here in order to do that we need a couple<00:48:35.680> of<00:48:35.880> pieces<00:48:36.119> of<00:48:36.280> information<00:48:36.760> here<00:48:37.760> one 00:48:37.910 --> 00:48:37.920 align:start position:0% couple of pieces of information here one 00:48:37.920 --> 00:48:40.950 align:start position:0% couple of pieces of information here one of<00:48:38.119> them<00:48:38.680> is<00:48:39.160> the<00:48:39.599> L2<00:48:40.000> Oracle<00:48:40.359> storage<00:48:40.720> key 00:48:40.950 --> 00:48:40.960 align:start position:0% of them is the L2 Oracle storage key 00:48:40.960 --> 00:48:42.670 align:start position:0% of them is the L2 Oracle storage key which<00:48:41.079> comes<00:48:41.280> from<00:48:41.400> the<00:48:41.559> request<00:48:42.240> so<00:48:42.400> we<00:48:42.480> can 00:48:42.670 --> 00:48:42.680 align:start position:0% which comes from the request so we can 00:48:42.680 --> 00:48:46.349 align:start position:0% which comes from the request so we can pass<00:48:42.880> in<00:48:43.000> the<00:48:43.160> request<00:48:43.800> here<00:48:44.800> copy<00:48:45.119> this<00:48:45.240> whole 00:48:46.349 --> 00:48:46.359 align:start position:0% pass in the request here copy this whole 00:48:46.359 --> 00:48:49.430 align:start position:0% pass in the request here copy this whole thing<00:48:47.359> pass<00:48:47.640> that<00:48:47.920> in<00:48:48.920> and<00:48:49.000> then<00:48:49.160> the<00:48:49.280> other 00:48:49.430 --> 00:48:49.440 align:start position:0% thing pass that in and then the other 00:48:49.440 --> 00:48:51.190 align:start position:0% thing pass that in and then the other piece<00:48:49.599> of<00:48:49.799> information<00:48:50.319> is<00:48:50.440> the<00:48:50.559> L2<00:48:50.960> block 00:48:51.190 --> 00:48:51.200 align:start position:0% piece of information is the L2 block 00:48:51.200 --> 00:48:53.510 align:start position:0% piece of information is the L2 block timestamp<00:48:52.000> which<00:48:52.480> if<00:48:52.559> you'll<00:48:52.799> remember<00:48:53.280> we 00:48:53.510 --> 00:48:53.520 align:start position:0% timestamp which if you'll remember we 00:48:53.520 --> 00:48:56.910 align:start position:0% timestamp which if you'll remember we added<00:48:54.000> to<00:48:54.400> the<00:48:54.920> uh<00:48:55.079> proof<00:48:55.319> struct<00:48:55.760> up<00:48:55.960> here<00:48:56.799> so 00:48:56.910 --> 00:48:56.920 align:start position:0% added to the uh proof struct up here so 00:48:56.920 --> 00:48:58.670 align:start position:0% added to the uh proof struct up here so we<00:48:57.040> can<00:48:57.200> pass<00:48:57.480> that<00:48:57.640> in<00:48:57.839> as<00:48:58.000> well<00:48:58.240> so<00:48:58.400> if<00:48:58.480> we 00:48:58.670 --> 00:48:58.680 align:start position:0% we can pass that in as well so if we 00:48:58.680 --> 00:49:01.950 align:start position:0% we can pass that in as well so if we copy<00:48:59.559> this 00:49:01.950 --> 00:49:01.960 align:start position:0% copy this 00:49:01.960 --> 00:49:04.150 align:start position:0% copy this declaration<00:49:02.960> we<00:49:03.079> can<00:49:03.240> paste<00:49:03.480> that<00:49:03.680> here<00:49:03.880> as<00:49:04.000> a 00:49:04.150 --> 00:49:04.160 align:start position:0% declaration we can paste that here as a 00:49:04.160 --> 00:49:09.069 align:start position:0% declaration we can paste that here as a second<00:49:04.440> input 00:49:09.069 --> 00:49:09.079 align:start position:0% 00:49:09.079 --> 00:49:11.510 align:start position:0% argument<00:49:10.079> and<00:49:10.280> then<00:49:10.760> so<00:49:11.000> what<00:49:11.079> does<00:49:11.240> this 00:49:11.510 --> 00:49:11.520 align:start position:0% argument and then so what does this 00:49:11.520 --> 00:49:13.349 align:start position:0% argument and then so what does this return<00:49:11.799> so<00:49:11.960> this<00:49:12.079> is<00:49:12.160> going<00:49:12.280> to<00:49:12.520> return<00:49:13.040> a 00:49:13.349 --> 00:49:13.359 align:start position:0% return so this is going to return a 00:49:13.359 --> 00:49:17.190 align:start position:0% return so this is going to return a derived<00:49:13.920> value<00:49:14.400> for<00:49:14.760> the<00:49:14.880> storage<00:49:15.280> key<00:49:16.280> where 00:49:17.190 --> 00:49:17.200 align:start position:0% derived value for the storage key where 00:49:17.200 --> 00:49:21.230 align:start position:0% derived value for the storage key where um<00:49:17.720> the<00:49:18.480> l2's<00:49:19.160> output<00:49:19.520> route<00:49:19.720> should<00:49:20.240> exist 00:49:21.230 --> 00:49:21.240 align:start position:0% um the l2's output route should exist 00:49:21.240 --> 00:49:24.870 align:start position:0% um the l2's output route should exist that<00:49:21.520> is<00:49:21.720> going<00:49:21.920> to<00:49:22.280> use<00:49:22.960> so<00:49:23.160> we'll<00:49:23.680> return<00:49:24.680> an 00:49:24.870 --> 00:49:24.880 align:start position:0% that is going to use so we'll return an 00:49:24.880 --> 00:49:29.710 align:start position:0% that is going to use so we'll return an ai.<00:49:25.799> encode<00:49:26.520> PA 00:49:29.710 --> 00:49:29.720 align:start position:0% 00:49:29.720 --> 00:49:32.549 align:start position:0% act<00:49:30.720> with<00:49:31.160> the<00:49:31.359> block<00:49:31.680> time<00:49:31.880> stamp<00:49:32.160> passed<00:49:32.400> in 00:49:32.549 --> 00:49:32.559 align:start position:0% act with the block time stamp passed in 00:49:32.559 --> 00:49:35.670 align:start position:0% act with the block time stamp passed in so<00:49:32.720> this<00:49:32.799> is<00:49:32.880> going<00:49:32.960> to<00:49:33.040> be<00:49:33.200> proof.<00:49:34.040> L2<00:49:34.480> block 00:49:35.670 --> 00:49:35.680 align:start position:0% so this is going to be proof. L2 block 00:49:35.680 --> 00:49:38.990 align:start position:0% so this is going to be proof. L2 block timestamp<00:49:36.680> and<00:49:36.920> then<00:49:37.720> um<00:49:38.000> the<00:49:38.160> storage<00:49:38.640> key 00:49:38.990 --> 00:49:39.000 align:start position:0% timestamp and then um the storage key 00:49:39.000 --> 00:49:41.910 align:start position:0% timestamp and then um the storage key location<00:49:39.440> so<00:49:39.640> then<00:49:39.760> it's<00:49:39.920> going<00:49:40.000> to<00:49:40.559> be 00:49:41.910 --> 00:49:41.920 align:start position:0% location so then it's going to be 00:49:41.920 --> 00:49:45.349 align:start position:0% location so then it's going to be request.<00:49:42.920> L2<00:49:43.440> Oracle<00:49:43.839> storage 00:49:45.349 --> 00:49:45.359 align:start position:0% request. L2 Oracle storage 00:49:45.359 --> 00:49:48.150 align:start position:0% request. L2 Oracle storage key<00:49:46.359> so<00:49:46.559> this<00:49:46.720> concatenates<00:49:47.680> them<00:49:47.920> together 00:49:48.150 --> 00:49:48.160 align:start position:0% key so this concatenates them together 00:49:48.160 --> 00:49:49.829 align:start position:0% key so this concatenates them together into<00:49:48.319> a<00:49:48.400> single<00:49:48.640> bytes<00:49:48.880> array<00:49:49.240> we<00:49:49.359> now<00:49:49.480> need<00:49:49.640> to 00:49:49.829 --> 00:49:49.839 align:start position:0% into a single bytes array we now need to 00:49:49.839 --> 00:49:52.789 align:start position:0% into a single bytes array we now need to Hash<00:49:50.200> this<00:49:50.400> to<00:49:50.720> generate<00:49:51.119> the<00:49:51.240> storage<00:49:51.680> key<00:49:52.680> so 00:49:52.789 --> 00:49:52.799 align:start position:0% Hash this to generate the storage key so 00:49:52.799 --> 00:49:54.309 align:start position:0% Hash this to generate the storage key so I'll<00:49:53.000> wrap<00:49:53.240> that<00:49:53.359> whole<00:49:53.559> thing<00:49:53.720> in<00:49:53.799> a<00:49:53.920> catch 00:49:54.309 --> 00:49:54.319 align:start position:0% I'll wrap that whole thing in a catch 00:49:54.319 --> 00:49:59.230 align:start position:0% I'll wrap that whole thing in a catch 256<00:49:55.079> hash<00:49:55.400> function 00:49:59.230 --> 00:49:59.240 align:start position:0% 00:49:59.240 --> 00:50:01.190 align:start position:0% and<00:49:59.400> then<00:49:59.920> one<00:50:00.119> final<00:50:00.400> step<00:50:00.640> here<00:50:00.839> because 00:50:01.190 --> 00:50:01.200 align:start position:0% and then one final step here because 00:50:01.200 --> 00:50:03.589 align:start position:0% and then one final step here because catch<00:50:01.599> 256<00:50:02.200> returns<00:50:02.400> a<00:50:02.480> byes<00:50:02.760> 32<00:50:03.240> and<00:50:03.359> we<00:50:03.440> need 00:50:03.589 --> 00:50:03.599 align:start position:0% catch 256 returns a byes 32 and we need 00:50:03.599 --> 00:50:05.630 align:start position:0% catch 256 returns a byes 32 and we need this<00:50:03.720> to<00:50:04.000> return<00:50:04.440> a<00:50:04.680> bytes<00:50:05.000> memory<00:50:05.440> we<00:50:05.559> just 00:50:05.630 --> 00:50:05.640 align:start position:0% this to return a bytes memory we just 00:50:05.640 --> 00:50:11.950 align:start position:0% this to return a bytes memory we just have<00:50:05.760> to<00:50:05.880> wrap<00:50:06.119> this<00:50:06.240> in<00:50:06.440> one<00:50:06.760> more<00:50:07.760> ai. 00:50:11.950 --> 00:50:11.960 align:start position:0% 00:50:11.960 --> 00:50:14.230 align:start position:0% encode<00:50:12.960> and<00:50:13.119> that<00:50:13.240> should<00:50:13.440> be<00:50:13.760> all<00:50:13.920> that<00:50:14.040> we 00:50:14.230 --> 00:50:14.240 align:start position:0% encode and that should be all that we 00:50:14.240 --> 00:50:16.829 align:start position:0% encode and that should be all that we need<00:50:14.640> to<00:50:14.920> derive<00:50:15.359> the<00:50:15.480> storage<00:50:15.880> location<00:50:16.520> for 00:50:16.829 --> 00:50:16.839 align:start position:0% need to derive the storage location for 00:50:16.839 --> 00:50:19.589 align:start position:0% need to derive the storage location for the<00:50:16.960> L1<00:50:17.319> storage<00:50:17.799> key<00:50:18.760> so<00:50:18.960> now<00:50:19.079> we<00:50:19.160> can<00:50:19.280> close 00:50:19.589 --> 00:50:19.599 align:start position:0% the L1 storage key so now we can close 00:50:19.599 --> 00:50:22.349 align:start position:0% the L1 storage key so now we can close these<00:50:19.920> and<00:50:20.000> then<00:50:20.160> use<00:50:20.359> this<00:50:20.960> function<00:50:21.960> to 00:50:22.349 --> 00:50:22.359 align:start position:0% these and then use this function to 00:50:22.359 --> 00:50:23.950 align:start position:0% these and then use this function to overwrite<00:50:22.960> the<00:50:23.079> storage<00:50:23.480> key<00:50:23.680> that<00:50:23.760> gets 00:50:23.950 --> 00:50:23.960 align:start position:0% overwrite the storage key that gets 00:50:23.960 --> 00:50:27.630 align:start position:0% overwrite the storage key that gets passed<00:50:24.240> into<00:50:24.480> this<00:50:24.640> validation<00:50:25.160> step 00:50:27.630 --> 00:50:27.640 align:start position:0% passed into this validation step 00:50:27.640 --> 00:50:31.390 align:start position:0% passed into this validation step um<00:50:28.640> so<00:50:28.839> this<00:50:28.920> will<00:50:29.040> be<00:50:29.359> proof.<00:50:30.200> DST<00:50:30.720> L2<00:50:31.160> State 00:50:31.390 --> 00:50:31.400 align:start position:0% um so this will be proof. DST L2 State 00:50:31.400 --> 00:50:32.430 align:start position:0% um so this will be proof. DST L2 State root<00:50:31.599> proof 00:50:32.430 --> 00:50:32.440 align:start position:0% root proof 00:50:32.440 --> 00:50:36.109 align:start position:0% root proof programs.<00:50:33.440> storage<00:50:33.880> key<00:50:34.559> is<00:50:34.799> equal<00:50:35.079> to<00:50:35.680> derive 00:50:36.109 --> 00:50:36.119 align:start position:0% programs. storage key is equal to derive 00:50:36.119 --> 00:50:39.630 align:start position:0% programs. storage key is equal to derive L1<00:50:36.520> storage<00:50:36.960> key<00:50:37.720> where<00:50:37.880> we<00:50:38.079> pass<00:50:38.400> in<00:50:39.280> uh<00:50:39.480> the 00:50:39.630 --> 00:50:39.640 align:start position:0% L1 storage key where we pass in uh the 00:50:39.640 --> 00:50:47.789 align:start position:0% L1 storage key where we pass in uh the two<00:50:40.160> input<00:50:40.480> parameters<00:50:40.880> of<00:50:41.040> request<00:50:41.400> and 00:50:47.789 --> 00:50:47.799 align:start position:0% 00:50:47.799 --> 00:50:52.309 align:start position:0% proof<00:50:48.799> okay<00:50:49.000> sweet<00:50:49.799> so<00:50:50.440> at<00:50:50.720> this<00:50:50.920> point<00:50:51.240> we<00:50:51.480> now 00:50:52.309 --> 00:50:52.319 align:start position:0% proof okay sweet so at this point we now 00:50:52.319 --> 00:50:55.549 align:start position:0% proof okay sweet so at this point we now have<00:50:53.200> a<00:50:53.359> verified<00:50:53.880> value<00:50:54.400> in<00:50:54.680> the<00:50:55.040> uh<00:50:55.160> rollup 00:50:55.549 --> 00:50:55.559 align:start position:0% have a verified value in the uh rollup 00:50:55.559 --> 00:50:58.510 align:start position:0% have a verified value in the uh rollup contract<00:50:55.880> for<00:50:55.960> the<00:50:56.079> destination<00:50:56.640> chain<00:50:56.880> on<00:50:57.520> L1 00:50:58.510 --> 00:50:58.520 align:start position:0% contract for the destination chain on L1 00:50:58.520 --> 00:51:00.990 align:start position:0% contract for the destination chain on L1 um<00:50:59.319> we've<00:50:59.559> confirmed<00:51:00.160> that<00:51:00.280> it<00:51:00.400> is<00:51:00.520> in<00:51:00.760> the 00:51:00.990 --> 00:51:01.000 align:start position:0% um we've confirmed that it is in the 00:51:01.000 --> 00:51:02.870 align:start position:0% um we've confirmed that it is in the correct<00:51:01.359> location<00:51:01.960> so<00:51:02.119> we<00:51:02.200> can<00:51:02.359> trust<00:51:02.760> that 00:51:02.870 --> 00:51:02.880 align:start position:0% correct location so we can trust that 00:51:02.880 --> 00:51:05.589 align:start position:0% correct location so we can trust that it's<00:51:03.040> the<00:51:03.240> proper<00:51:03.720> state<00:51:04.480> representation<00:51:05.480> and 00:51:05.589 --> 00:51:05.599 align:start position:0% it's the proper state representation and 00:51:05.599 --> 00:51:08.630 align:start position:0% it's the proper state representation and then<00:51:05.720> we<00:51:05.839> can<00:51:06.400> uh<00:51:06.520> move<00:51:06.720> on<00:51:06.920> from<00:51:07.119> there<00:51:08.079> so<00:51:08.520> the 00:51:08.630 --> 00:51:08.640 align:start position:0% then we can uh move on from there so the 00:51:08.640 --> 00:51:11.190 align:start position:0% then we can uh move on from there so the next<00:51:08.880> step<00:51:09.200> here<00:51:09.640> is<00:51:09.760> to<00:51:10.000> verifiably<00:51:10.640> link<00:51:11.040> the 00:51:11.190 --> 00:51:11.200 align:start position:0% next step here is to verifiably link the 00:51:11.200 --> 00:51:13.510 align:start position:0% next step here is to verifiably link the destination<00:51:11.760> chain<00:51:12.599> State<00:51:12.839> Route<00:51:13.200> the 00:51:13.510 --> 00:51:13.520 align:start position:0% destination chain State Route the 00:51:13.520 --> 00:51:16.670 align:start position:0% destination chain State Route the destination<00:51:14.520> chain<00:51:14.880> state<00:51:15.680> representation 00:51:16.670 --> 00:51:16.680 align:start position:0% destination chain state representation 00:51:16.680 --> 00:51:19.349 align:start position:0% destination chain state representation um<00:51:17.319> if<00:51:17.559> the<00:51:17.760> destination<00:51:18.319> chain<00:51:18.799> is<00:51:19.040> directly 00:51:19.349 --> 00:51:19.359 align:start position:0% um if the destination chain is directly 00:51:19.359 --> 00:51:20.670 align:start position:0% um if the destination chain is directly posting<00:51:19.680> their<00:51:19.799> state<00:51:20.000> route<00:51:20.240> this<00:51:20.319> is<00:51:20.440> UN 00:51:20.670 --> 00:51:20.680 align:start position:0% posting their state route this is UN 00:51:20.680 --> 00:51:22.230 align:start position:0% posting their state route this is UN necessary<00:51:21.319> um<00:51:21.400> we<00:51:21.520> just<00:51:21.640> need<00:51:21.760> to<00:51:21.920> make<00:51:22.040> sure 00:51:22.230 --> 00:51:22.240 align:start position:0% necessary um we just need to make sure 00:51:22.240 --> 00:51:25.030 align:start position:0% necessary um we just need to make sure that<00:51:22.359> we<00:51:22.599> have<00:51:23.160> a<00:51:23.319> verified<00:51:23.839> State<00:51:24.079> Route<00:51:24.359> here 00:51:25.030 --> 00:51:25.040 align:start position:0% that we have a verified State Route here 00:51:25.040 --> 00:51:26.750 align:start position:0% that we have a verified State Route here um<00:51:25.160> so<00:51:25.319> in<00:51:25.440> this<00:51:25.599> example<00:51:25.960> because<00:51:26.119> we're<00:51:26.240> not 00:51:26.750 --> 00:51:26.760 align:start position:0% um so in this example because we're not 00:51:26.760 --> 00:51:30.829 align:start position:0% um so in this example because we're not ly<00:51:26.880> posting<00:51:27.240> that<00:51:27.480> it's<00:51:27.839> a<00:51:28.200> hash 00:51:30.829 --> 00:51:30.839 align:start position:0% ly posting that it's a hash 00:51:30.839 --> 00:51:33.349 align:start position:0% ly posting that it's a hash of<00:51:31.839> uh<00:51:32.000> block<00:51:32.280> time<00:51:32.480> stamp<00:51:32.680> and<00:51:32.799> state<00:51:33.000> route 00:51:33.349 --> 00:51:33.359 align:start position:0% of uh block time stamp and state route 00:51:33.359 --> 00:51:35.030 align:start position:0% of uh block time stamp and state route we<00:51:33.480> need<00:51:33.640> to<00:51:33.839> recreate<00:51:34.359> what<00:51:34.559> this<00:51:34.680> output 00:51:35.030 --> 00:51:35.040 align:start position:0% we need to recreate what this output 00:51:35.040 --> 00:51:40.390 align:start position:0% we need to recreate what this output route<00:51:35.319> should<00:51:35.640> be<00:51:36.640> so 00:51:40.390 --> 00:51:40.400 align:start position:0% 00:51:40.400 --> 00:51:44.190 align:start position:0% um<00:51:41.400> we<00:51:41.520> can<00:51:41.680> rederive<00:51:42.319> that<00:51:42.640> with<00:51:42.799> a<00:51:43.000> bytes<00:51:43.280> 32 00:51:44.190 --> 00:51:44.200 align:start position:0% um we can rederive that with a bytes 32 00:51:44.200 --> 00:51:47.030 align:start position:0% um we can rederive that with a bytes 32 uh<00:51:44.280> for<00:51:44.440> a<00:51:44.559> local<00:51:45.119> variable<00:51:46.119> byes 00:51:47.030 --> 00:51:47.040 align:start position:0% uh for a local variable byes 00:51:47.040 --> 00:51:50.630 align:start position:0% uh for a local variable byes 32<00:51:48.040> this<00:51:48.160> will<00:51:48.359> be<00:51:49.160> uh 00:51:50.630 --> 00:51:50.640 align:start position:0% 32 this will be uh 00:51:50.640 --> 00:51:53.430 align:start position:0% 32 this will be uh derived 00:51:53.430 --> 00:51:53.440 align:start position:0% derived 00:51:53.440 --> 00:51:55.510 align:start position:0% derived L2<00:51:54.440> um 00:51:55.510 --> 00:51:55.520 align:start position:0% L2 um 00:51:55.520 --> 00:51:58.470 align:start position:0% L2 um output<00:51:56.599> root<00:51:57.400> is<00:51:57.599> equal 00:51:58.470 --> 00:51:58.480 align:start position:0% output root is equal 00:51:58.480 --> 00:52:01.069 align:start position:0% output root is equal to<00:51:59.480> KCK 00:52:01.069 --> 00:52:01.079 align:start position:0% to KCK 00:52:01.079 --> 00:52:03.349 align:start position:0% to KCK 256<00:52:02.079> and<00:52:02.200> what<00:52:02.319> gets<00:52:02.520> passed<00:52:02.720> in<00:52:02.920> here<00:52:03.119> we're 00:52:03.349 --> 00:52:03.359 align:start position:0% 256 and what gets passed in here we're 00:52:03.359 --> 00:52:05.630 align:start position:0% 256 and what gets passed in here we're basically<00:52:03.760> just<00:52:03.960> recreating<00:52:04.920> this<00:52:05.119> line<00:52:05.480> over 00:52:05.630 --> 00:52:05.640 align:start position:0% basically just recreating this line over 00:52:05.640 --> 00:52:07.510 align:start position:0% basically just recreating this line over here<00:52:05.799> in<00:52:05.880> the<00:52:06.000> rollup<00:52:06.359> contract<00:52:07.160> so<00:52:07.319> this<00:52:07.400> is 00:52:07.510 --> 00:52:07.520 align:start position:0% here in the rollup contract so this is 00:52:07.520 --> 00:52:12.109 align:start position:0% here in the rollup contract so this is going<00:52:07.599> to<00:52:07.680> be<00:52:07.799> an<00:52:07.920> ai.<00:52:08.680> encod 00:52:12.109 --> 00:52:12.119 align:start position:0% 00:52:12.119 --> 00:52:15.510 align:start position:0% packed<00:52:13.119> and<00:52:13.400> inside<00:52:13.720> of<00:52:13.880> the<00:52:14.000> ABI<00:52:14.599> incoda<00:52:15.440> we 00:52:15.510 --> 00:52:15.520 align:start position:0% packed and inside of the ABI incoda we 00:52:15.520 --> 00:52:17.150 align:start position:0% packed and inside of the ABI incoda we want<00:52:15.640> to<00:52:15.839> pass<00:52:16.000> in<00:52:16.160> the<00:52:16.280> block<00:52:16.559> timestamp<00:52:17.040> and 00:52:17.150 --> 00:52:17.160 align:start position:0% want to pass in the block timestamp and 00:52:17.160 --> 00:52:18.030 align:start position:0% want to pass in the block timestamp and a<00:52:17.280> state 00:52:18.030 --> 00:52:18.040 align:start position:0% a state 00:52:18.040 --> 00:52:21.069 align:start position:0% a state route<00:52:19.040> but<00:52:19.200> at<00:52:19.319> this<00:52:19.480> point<00:52:19.760> we<00:52:20.040> don't<00:52:20.760> have<00:52:20.920> a 00:52:21.069 --> 00:52:21.079 align:start position:0% route but at this point we don't have a 00:52:21.079 --> 00:52:23.950 align:start position:0% route but at this point we don't have a state<00:52:21.319> route<00:52:21.559> to<00:52:21.760> use<00:52:22.319> so<00:52:22.960> that<00:52:23.480> uh<00:52:23.599> would<00:52:23.760> be 00:52:23.950 --> 00:52:23.960 align:start position:0% state route to use so that uh would be 00:52:23.960 --> 00:52:25.750 align:start position:0% state route to use so that uh would be the<00:52:24.079> perfect<00:52:24.720> now<00:52:24.839> is<00:52:24.960> the<00:52:25.079> perfect<00:52:25.359> time<00:52:25.559> to 00:52:25.750 --> 00:52:25.760 align:start position:0% the perfect now is the perfect time to 00:52:25.760 --> 00:52:27.710 align:start position:0% the perfect now is the perfect time to add<00:52:25.960> that<00:52:26.119> as<00:52:26.240> the<00:52:26.319> next<00:52:26.520> next<00:52:26.720> field<00:52:27.079> in<00:52:27.200> our 00:52:27.710 --> 00:52:27.720 align:start position:0% add that as the next next field in our 00:52:27.720 --> 00:52:31.150 align:start position:0% add that as the next next field in our RP<00:52:28.200> 7755<00:52:29.119> proof<00:52:29.359> struct<00:52:30.319> um<00:52:30.440> we<00:52:30.559> would<00:52:30.760> expect 00:52:31.150 --> 00:52:31.160 align:start position:0% RP 7755 proof struct um we would expect 00:52:31.160 --> 00:52:33.430 align:start position:0% RP 7755 proof struct um we would expect the<00:52:31.359> fulfiller<00:52:31.880> in<00:52:32.040> this<00:52:32.200> case<00:52:32.400> to<00:52:32.599> supply 00:52:33.430 --> 00:52:33.440 align:start position:0% the fulfiller in this case to supply 00:52:33.440 --> 00:52:35.750 align:start position:0% the fulfiller in this case to supply what<00:52:33.640> the<00:52:33.960> destination<00:52:34.640> chains<00:52:35.200> State<00:52:35.440> Route 00:52:35.750 --> 00:52:35.760 align:start position:0% what the destination chains State Route 00:52:35.760 --> 00:52:38.950 align:start position:0% what the destination chains State Route is<00:52:36.559> and<00:52:36.720> then<00:52:36.880> we<00:52:36.960> can<00:52:37.119> use<00:52:37.359> that<00:52:37.520> to<00:52:37.960> rederive 00:52:38.950 --> 00:52:38.960 align:start position:0% is and then we can use that to rederive 00:52:38.960 --> 00:52:41.589 align:start position:0% is and then we can use that to rederive um<00:52:39.359> the<00:52:39.599> the<00:52:39.720> state<00:52:40.240> representation<00:52:41.240> that<00:52:41.400> was 00:52:41.589 --> 00:52:41.599 align:start position:0% um the the state representation that was 00:52:41.599 --> 00:52:43.630 align:start position:0% um the the state representation that was verified<00:52:42.040> using<00:52:42.319> the<00:52:42.480> first<00:52:42.799> storage<00:52:43.200> proof 00:52:43.630 --> 00:52:43.640 align:start position:0% verified using the first storage proof 00:52:43.640 --> 00:52:44.990 align:start position:0% verified using the first storage proof and<00:52:43.760> if<00:52:43.880> they're<00:52:44.079> equivalent<00:52:44.640> then<00:52:44.760> we<00:52:44.839> can 00:52:44.990 --> 00:52:45.000 align:start position:0% and if they're equivalent then we can 00:52:45.000 --> 00:52:47.670 align:start position:0% and if they're equivalent then we can trust<00:52:45.440> the<00:52:45.680> past<00:52:45.920> in<00:52:46.160> L2<00:52:46.520> State<00:52:46.760> Route<00:52:47.440> so<00:52:47.559> this 00:52:47.670 --> 00:52:47.680 align:start position:0% trust the past in L2 State Route so this 00:52:47.680 --> 00:52:48.950 align:start position:0% trust the past in L2 State Route so this will<00:52:47.760> be<00:52:47.839> a<00:52:47.960> byes 00:52:48.950 --> 00:52:48.960 align:start position:0% will be a byes 00:52:48.960 --> 00:52:54.750 align:start position:0% will be a byes 32<00:52:49.960> L2<00:52:50.680> State 00:52:54.750 --> 00:52:54.760 align:start position:0% 00:52:54.760 --> 00:52:56.910 align:start position:0% Route<00:52:55.760> and<00:52:55.880> we<00:52:56.000> need<00:52:56.119> to<00:52:56.280> pass<00:52:56.520> pass<00:52:56.760> these 00:52:56.910 --> 00:52:56.920 align:start position:0% Route and we need to pass pass these 00:52:56.920 --> 00:52:58.549 align:start position:0% Route and we need to pass pass these arguments<00:52:57.440> in<00:52:57.760> in<00:52:57.880> the<00:52:58.000> same<00:52:58.200> order<00:52:58.440> that 00:52:58.549 --> 00:52:58.559 align:start position:0% arguments in in the same order that 00:52:58.559 --> 00:52:59.910 align:start position:0% arguments in in the same order that they're<00:52:58.680> passed<00:52:58.960> in<00:52:59.079> over<00:52:59.280> here<00:52:59.520> so<00:52:59.680> we'd 00:52:59.910 --> 00:52:59.920 align:start position:0% they're passed in over here so we'd 00:52:59.920 --> 00:53:02.549 align:start position:0% they're passed in over here so we'd start<00:53:00.240> with<00:53:00.400> the<00:53:00.559> L2<00:53:01.000> block<00:53:01.280> time<00:53:01.520> stamp<00:53:02.480> this 00:53:02.549 --> 00:53:02.559 align:start position:0% start with the L2 block time stamp this 00:53:02.559 --> 00:53:07.470 align:start position:0% start with the L2 block time stamp this will<00:53:02.799> be<00:53:03.720> proof.<00:53:04.280> L2<00:53:05.119> oops<00:53:06.119> L2<00:53:06.640> block<00:53:06.960> Tim 00:53:07.470 --> 00:53:07.480 align:start position:0% will be proof. L2 oops L2 block Tim 00:53:07.480 --> 00:53:09.510 align:start position:0% will be proof. L2 oops L2 block Tim stamp<00:53:08.480> and<00:53:08.559> then<00:53:08.680> we'd<00:53:08.839> want<00:53:08.960> to<00:53:09.079> pass<00:53:09.240> in<00:53:09.400> the 00:53:09.510 --> 00:53:09.520 align:start position:0% stamp and then we'd want to pass in the 00:53:09.520 --> 00:53:16.950 align:start position:0% stamp and then we'd want to pass in the state<00:53:09.760> root<00:53:10.119> so<00:53:10.680> proof.<00:53:11.480> L2<00:53:12.480> State 00:53:16.950 --> 00:53:16.960 align:start position:0% 00:53:16.960 --> 00:53:20.630 align:start position:0% root<00:53:17.960> okay<00:53:18.960> so<00:53:19.200> now<00:53:19.359> at<00:53:19.480> this<00:53:19.640> point<00:53:19.839> we<00:53:20.000> have<00:53:20.160> a 00:53:20.630 --> 00:53:20.640 align:start position:0% root okay so now at this point we have a 00:53:20.640 --> 00:53:22.510 align:start position:0% root okay so now at this point we have a rederived<00:53:21.640> uh<00:53:21.760> output<00:53:22.119> route<00:53:22.319> for<00:53:22.440> the 00:53:22.510 --> 00:53:22.520 align:start position:0% rederived uh output route for the 00:53:22.520 --> 00:53:25.109 align:start position:0% rederived uh output route for the destination<00:53:23.119> chain<00:53:24.119> in<00:53:24.240> the<00:53:24.400> case<00:53:24.760> that<00:53:24.920> this 00:53:25.109 --> 00:53:25.119 align:start position:0% destination chain in the case that this 00:53:25.119 --> 00:53:27.030 align:start position:0% destination chain in the case that this doesn't<00:53:25.440> equal<00:53:25.720> the<00:53:25.799> value<00:53:26.040> we<00:53:26.160> just<00:53:26.520> verified 00:53:27.030 --> 00:53:27.040 align:start position:0% doesn't equal the value we just verified 00:53:27.040 --> 00:53:28.789 align:start position:0% doesn't equal the value we just verified we'll<00:53:27.319> create<00:53:27.720> another<00:53:27.960> custom<00:53:28.280> error<00:53:28.559> for 00:53:28.789 --> 00:53:28.799 align:start position:0% we'll create another custom error for 00:53:28.799 --> 00:53:32.109 align:start position:0% we'll create another custom error for that<00:53:29.480> uh<00:53:30.480> to<00:53:30.599> revert<00:53:30.960> in<00:53:31.079> that<00:53:31.240> case<00:53:31.760> so<00:53:31.880> we<00:53:32.000> can 00:53:32.109 --> 00:53:32.119 align:start position:0% that uh to revert in that case so we can 00:53:32.119 --> 00:53:39.910 align:start position:0% that uh to revert in that case so we can call<00:53:32.359> that<00:53:32.760> an<00:53:33.400> error<00:53:34.400> uh<00:53:35.240> invalid<00:53:36.240> L2<00:53:37.200> State 00:53:39.910 --> 00:53:39.920 align:start position:0% 00:53:39.920 --> 00:53:42.430 align:start position:0% root<00:53:40.920> copy 00:53:42.430 --> 00:53:42.440 align:start position:0% root copy 00:53:42.440 --> 00:53:44.710 align:start position:0% root copy that<00:53:43.440> and<00:53:43.520> then<00:53:43.640> we<00:53:43.720> need<00:53:43.880> to<00:53:44.000> compare<00:53:44.400> this<00:53:44.520> to 00:53:44.710 --> 00:53:44.720 align:start position:0% that and then we need to compare this to 00:53:44.720 --> 00:53:46.549 align:start position:0% that and then we need to compare this to the<00:53:44.799> storage<00:53:45.200> value<00:53:45.480> that<00:53:45.599> we<00:53:45.760> verified<00:53:46.359> in 00:53:46.549 --> 00:53:46.559 align:start position:0% the storage value that we verified in 00:53:46.559 --> 00:53:52.390 align:start position:0% the storage value that we verified in this<00:53:46.839> step<00:53:47.839> so<00:53:48.480> that'll<00:53:48.760> be<00:53:49.599> um<00:53:50.520> if<00:53:51.520> derived<00:53:51.960> L2 00:53:52.390 --> 00:53:52.400 align:start position:0% this step so that'll be um if derived L2 00:53:52.400 --> 00:53:56.750 align:start position:0% this step so that'll be um if derived L2 output<00:53:52.760> rout<00:53:53.400> does<00:53:53.720> not<00:53:54.160> equal<00:53:55.160> proof.<00:53:55.839> DST<00:53:56.440> L2 00:53:56.750 --> 00:53:56.760 align:start position:0% output rout does not equal proof. DST L2 00:53:56.760 --> 00:54:00.109 align:start position:0% output rout does not equal proof. DST L2 State<00:53:57.000> root<00:53:57.240> proof<00:53:57.599> prams<00:53:58.599> do<00:53:59.000> storage 00:54:00.109 --> 00:54:00.119 align:start position:0% State root proof prams do storage 00:54:00.119 --> 00:54:07.670 align:start position:0% State root proof prams do storage value<00:54:01.119> then<00:54:01.240> we<00:54:01.400> revert<00:54:01.799> with<00:54:01.920> that<00:54:02.079> custom 00:54:07.670 --> 00:54:07.680 align:start position:0% 00:54:07.680 --> 00:54:10.109 align:start position:0% error<00:54:08.680> and<00:54:08.839> this<00:54:08.920> is<00:54:09.119> yelling<00:54:09.400> at<00:54:09.559> me<00:54:09.799> because 00:54:10.109 --> 00:54:10.119 align:start position:0% error and this is yelling at me because 00:54:10.119 --> 00:54:13.150 align:start position:0% error and this is yelling at me because the<00:54:10.240> storage<00:54:10.640> value<00:54:11.040> is<00:54:11.240> a<00:54:11.520> a<00:54:11.680> byes<00:54:12.520> string<00:54:13.040> and 00:54:13.150 --> 00:54:13.160 align:start position:0% the storage value is a a byes string and 00:54:13.160 --> 00:54:16.030 align:start position:0% the storage value is a a byes string and this<00:54:13.240> is<00:54:13.359> a<00:54:13.480> bytes<00:54:13.839> 32<00:54:14.839> so<00:54:15.319> uh<00:54:15.440> because<00:54:15.680> we'd<00:54:15.880> be 00:54:16.030 --> 00:54:16.040 align:start position:0% this is a bytes 32 so uh because we'd be 00:54:16.040 --> 00:54:17.349 align:start position:0% this is a bytes 32 so uh because we'd be expecting<00:54:16.359> them<00:54:16.480> to<00:54:16.559> be<00:54:16.680> equivalent<00:54:17.119> we<00:54:17.240> can 00:54:17.349 --> 00:54:17.359 align:start position:0% expecting them to be equivalent we can 00:54:17.359 --> 00:54:19.630 align:start position:0% expecting them to be equivalent we can wrap<00:54:17.599> this<00:54:17.680> in<00:54:17.799> a<00:54:17.960> byes 00:54:19.630 --> 00:54:19.640 align:start position:0% wrap this in a byes 00:54:19.640 --> 00:54:23.670 align:start position:0% wrap this in a byes 32<00:54:20.640> for<00:54:20.799> the<00:54:21.000> type<00:54:21.280> safe<00:54:22.079> uh<00:54:23.079> yeah<00:54:23.280> properties 00:54:23.670 --> 00:54:23.680 align:start position:0% 32 for the type safe uh yeah properties 00:54:23.680 --> 00:54:24.829 align:start position:0% 32 for the type safe uh yeah properties of 00:54:24.829 --> 00:54:24.839 align:start position:0% of 00:54:24.839 --> 00:54:26.549 align:start position:0% of solidity<00:54:25.839> and<00:54:25.960> one<00:54:26.079> other<00:54:26.240> thing<00:54:26.440> I'm 00:54:26.549 --> 00:54:26.559 align:start position:0% solidity and one other thing I'm 00:54:26.559 --> 00:54:27.630 align:start position:0% solidity and one other thing I'm noticing<00:54:26.880> here<00:54:27.040> this<00:54:27.119> is<00:54:27.240> kind<00:54:27.319> of<00:54:27.440> just<00:54:27.559> like 00:54:27.630 --> 00:54:27.640 align:start position:0% noticing here this is kind of just like 00:54:27.640 --> 00:54:29.829 align:start position:0% noticing here this is kind of just like a<00:54:27.760> personal<00:54:28.119> preference<00:54:28.480> for<00:54:28.640> me<00:54:28.960> but<00:54:29.440> uh<00:54:29.640> the 00:54:29.829 --> 00:54:29.839 align:start position:0% a personal preference for me but uh the 00:54:29.839 --> 00:54:32.230 align:start position:0% a personal preference for me but uh the State<00:54:30.359> validator<00:54:31.000> Library<00:54:31.400> up<00:54:31.599> here<00:54:31.960> because 00:54:32.230 --> 00:54:32.240 align:start position:0% State validator Library up here because 00:54:32.240 --> 00:54:35.069 align:start position:0% State validator Library up here because we're<00:54:32.440> using<00:54:32.760> it<00:54:33.040> on<00:54:33.359> a<00:54:33.559> specific<00:54:33.960> account<00:54:34.880> for 00:54:35.069 --> 00:54:35.079 align:start position:0% we're using it on a specific account for 00:54:35.079 --> 00:54:37.589 align:start position:0% we're using it on a specific account for solidi<00:54:36.000> purposes<00:54:36.440> we<00:54:36.520> can<00:54:36.720> actually<00:54:37.040> bind 00:54:37.589 --> 00:54:37.599 align:start position:0% solidi purposes we can actually bind 00:54:37.599 --> 00:54:39.349 align:start position:0% solidi purposes we can actually bind that<00:54:37.799> library<00:54:38.160> to<00:54:38.319> the<00:54:38.520> account<00:54:38.920> to<00:54:39.200> just 00:54:39.349 --> 00:54:39.359 align:start position:0% that library to the account to just 00:54:39.359 --> 00:54:41.589 align:start position:0% that library to the account to just improve<00:54:39.799> the<00:54:39.960> legibility<00:54:40.680> of<00:54:40.880> this<00:54:41.200> this<00:54:41.359> line 00:54:41.589 --> 00:54:41.599 align:start position:0% improve the legibility of this this line 00:54:41.599 --> 00:54:43.430 align:start position:0% improve the legibility of this this line make<00:54:41.720> it<00:54:41.799> a<00:54:41.880> little<00:54:42.000> bit<00:54:42.119> more<00:54:42.240> succinct<00:54:43.200> so 00:54:43.430 --> 00:54:43.440 align:start position:0% make it a little bit more succinct so 00:54:43.440 --> 00:54:45.390 align:start position:0% make it a little bit more succinct so I'm<00:54:43.559> going<00:54:43.640> to<00:54:43.799> do<00:54:44.079> that<00:54:44.480> but<00:54:44.640> that's<00:54:45.079> totally 00:54:45.390 --> 00:54:45.400 align:start position:0% I'm going to do that but that's totally 00:54:45.400 --> 00:54:47.230 align:start position:0% I'm going to do that but that's totally just<00:54:45.520> a<00:54:45.680> personal<00:54:46.040> preference<00:54:46.799> so<00:54:46.960> we<00:54:47.079> would 00:54:47.230 --> 00:54:47.240 align:start position:0% just a personal preference so we would 00:54:47.240 --> 00:54:48.670 align:start position:0% just a personal preference so we would add<00:54:47.559> a<00:54:47.640> line<00:54:47.839> at<00:54:47.920> the<00:54:48.040> top<00:54:48.160> of<00:54:48.240> the<00:54:48.319> Prov 00:54:48.670 --> 00:54:48.680 align:start position:0% add a line at the top of the Prov 00:54:48.680 --> 00:54:51.510 align:start position:0% add a line at the top of the Prov contract<00:54:49.040> that<00:54:49.160> says<00:54:49.480> using<00:54:50.400> state<00:54:50.839> validator 00:54:51.510 --> 00:54:51.520 align:start position:0% contract that says using state validator 00:54:51.520 --> 00:54:56.789 align:start position:0% contract that says using state validator for<00:54:52.040> address 00:54:56.789 --> 00:54:56.799 align:start position:0% 00:54:56.799 --> 00:54:58.589 align:start position:0% and<00:54:56.960> then<00:54:57.240> what<00:54:57.359> that<00:54:57.480> allows<00:54:57.760> us<00:54:57.880> to<00:54:58.040> do<00:54:58.280> is<00:54:58.359> to 00:54:58.589 --> 00:54:58.599 align:start position:0% and then what that allows us to do is to 00:54:58.599 --> 00:55:01.030 align:start position:0% and then what that allows us to do is to copy<00:54:58.920> this<00:54:59.079> request.<00:54:59.599> L2<00:54:59.960> Oracle<00:55:00.599> and<00:55:00.760> remove 00:55:01.030 --> 00:55:01.040 align:start position:0% copy this request. L2 Oracle and remove 00:55:01.040 --> 00:55:03.390 align:start position:0% copy this request. L2 Oracle and remove it<00:55:01.200> from<00:55:01.359> the<00:55:01.480> function<00:55:01.839> call<00:55:02.799> and<00:55:02.920> then<00:55:03.160> paste 00:55:03.390 --> 00:55:03.400 align:start position:0% it from the function call and then paste 00:55:03.400 --> 00:55:05.950 align:start position:0% it from the function call and then paste it<00:55:03.640> here<00:55:03.960> instead<00:55:04.359> of<00:55:04.520> state<00:55:04.880> validator<00:55:05.880> and 00:55:05.950 --> 00:55:05.960 align:start position:0% it here instead of state validator and 00:55:05.960 --> 00:55:07.109 align:start position:0% it here instead of state validator and then<00:55:06.079> this<00:55:06.200> is<00:55:06.319> doing<00:55:06.520> the<00:55:06.640> same<00:55:06.839> thing<00:55:07.040> but 00:55:07.109 --> 00:55:07.119 align:start position:0% then this is doing the same thing but 00:55:07.119 --> 00:55:11.990 align:start position:0% then this is doing the same thing but it's<00:55:07.280> just<00:55:07.400> a<00:55:07.480> little<00:55:07.680> bit 00:55:11.990 --> 00:55:12.000 align:start position:0% 00:55:12.000 --> 00:55:14.910 align:start position:0% shorter<00:55:13.000> okay<00:55:13.319> so<00:55:13.520> at<00:55:13.640> this<00:55:13.799> point<00:55:14.040> we<00:55:14.200> have<00:55:14.319> a 00:55:14.910 --> 00:55:14.920 align:start position:0% shorter okay so at this point we have a 00:55:14.920 --> 00:55:18.390 align:start position:0% shorter okay so at this point we have a verified<00:55:15.920> um<00:55:16.160> destination<00:55:16.799> chain<00:55:17.799> store<00:55:18.240> or 00:55:18.390 --> 00:55:18.400 align:start position:0% verified um destination chain store or 00:55:18.400 --> 00:55:21.069 align:start position:0% verified um destination chain store or state<00:55:18.680> route<00:55:19.599> now<00:55:19.720> we<00:55:19.839> can<00:55:19.960> use<00:55:20.200> that<00:55:20.440> to 00:55:21.069 --> 00:55:21.079 align:start position:0% state route now we can use that to 00:55:21.079 --> 00:55:23.829 align:start position:0% state route now we can use that to basically<00:55:21.720> redo<00:55:22.200> step<00:55:22.520> three<00:55:23.119> but<00:55:23.359> now<00:55:23.680> the 00:55:23.829 --> 00:55:23.839 align:start position:0% basically redo step three but now the 00:55:23.839 --> 00:55:25.670 align:start position:0% basically redo step three but now the account<00:55:24.079> we<00:55:24.240> care<00:55:24.480> about<00:55:24.839> is<00:55:25.079> the<00:55:25.200> inbox 00:55:25.670 --> 00:55:25.680 align:start position:0% account we care about is the inbox 00:55:25.680 --> 00:55:28.470 align:start position:0% account we care about is the inbox contract<00:55:26.000> on<00:55:26.079> the<00:55:26.359> destination<00:55:27.000> chain<00:55:28.000> so 00:55:28.470 --> 00:55:28.480 align:start position:0% contract on the destination chain so 00:55:28.480 --> 00:55:31.109 align:start position:0% contract on the destination chain so what<00:55:28.599> that's<00:55:28.799> going<00:55:28.920> to<00:55:29.119> look<00:55:29.319> like<00:55:29.720> is<00:55:30.319> uh 00:55:31.109 --> 00:55:31.119 align:start position:0% what that's going to look like is uh 00:55:31.119 --> 00:55:34.870 align:start position:0% what that's going to look like is uh aou<00:55:32.119> is<00:55:32.559> valid<00:55:33.200> L2 00:55:34.870 --> 00:55:34.880 align:start position:0% aou is valid L2 00:55:34.880 --> 00:55:38.430 align:start position:0% aou is valid L2 state<00:55:35.880> is<00:55:36.039> equal<00:55:36.359> to<00:55:37.280> um<00:55:37.480> and<00:55:37.640> then<00:55:37.960> to<00:55:38.160> jog 00:55:38.430 --> 00:55:38.440 align:start position:0% state is equal to um and then to jog 00:55:38.440 --> 00:55:40.390 align:start position:0% state is equal to um and then to jog your<00:55:38.559> memory<00:55:38.920> again<00:55:39.160> on<00:55:39.319> the<00:55:39.480> structure<00:55:39.839> of<00:55:39.960> a 00:55:40.390 --> 00:55:40.400 align:start position:0% your memory again on the structure of a 00:55:40.400 --> 00:55:43.750 align:start position:0% your memory again on the structure of a request<00:55:41.400> we<00:55:41.640> actually<00:55:42.160> have<00:55:42.920> the<00:55:43.280> inbox 00:55:43.750 --> 00:55:43.760 align:start position:0% request we actually have the inbox 00:55:43.760 --> 00:55:45.309 align:start position:0% request we actually have the inbox contract<00:55:44.119> being<00:55:44.319> defined<00:55:44.640> by<00:55:44.760> the<00:55:44.880> user<00:55:45.200> when 00:55:45.309 --> 00:55:45.319 align:start position:0% contract being defined by the user when 00:55:45.319 --> 00:55:47.390 align:start position:0% contract being defined by the user when they<00:55:45.440> submit<00:55:45.680> the<00:55:45.839> request<00:55:46.640> so<00:55:46.839> this<00:55:47.079> address 00:55:47.390 --> 00:55:47.400 align:start position:0% they submit the request so this address 00:55:47.400 --> 00:55:49.230 align:start position:0% they submit the request so this address is<00:55:47.480> going<00:55:47.599> to<00:55:47.680> be<00:55:47.799> the<00:55:47.920> address<00:55:48.280> that<00:55:48.400> we're<00:55:49.000> um 00:55:49.230 --> 00:55:49.240 align:start position:0% is going to be the address that we're um 00:55:49.240 --> 00:55:52.230 align:start position:0% is going to be the address that we're um verifying<00:55:49.760> State<00:55:50.319> against<00:55:51.319> so<00:55:51.520> this<00:55:51.599> will<00:55:51.799> be 00:55:52.230 --> 00:55:52.240 align:start position:0% verifying State against so this will be 00:55:52.240 --> 00:55:57.549 align:start position:0% verifying State against so this will be request<00:55:53.240> do<00:55:53.480> inbox<00:55:54.079> contract<00:55:55.039> Dot<00:55:56.400> verify<00:55:57.240> uh 00:55:57.549 --> 00:55:57.559 align:start position:0% request do inbox contract Dot verify uh 00:55:57.559 --> 00:55:58.870 align:start position:0% request do inbox contract Dot verify uh what's<00:55:57.720> it<00:55:57.839> called<00:55:58.039> again<00:55:58.240> oh<00:55:58.440> validate 00:55:58.870 --> 00:55:58.880 align:start position:0% what's it called again oh validate 00:55:58.880 --> 00:56:03.549 align:start position:0% what's it called again oh validate account 00:56:03.549 --> 00:56:03.559 align:start position:0% 00:56:03.559 --> 00:56:06.349 align:start position:0% storage<00:56:04.559> and<00:56:05.000> in<00:56:05.240> here<00:56:05.480> we<00:56:05.599> need<00:56:05.720> to<00:56:05.920> pass<00:56:06.079> in<00:56:06.200> a 00:56:06.349 --> 00:56:06.359 align:start position:0% storage and in here we need to pass in a 00:56:06.359 --> 00:56:09.549 align:start position:0% storage and in here we need to pass in a state<00:56:06.640> root<00:56:07.280> and<00:56:08.079> another<00:56:08.880> instance<00:56:09.319> of<00:56:09.440> the 00:56:09.549 --> 00:56:09.559 align:start position:0% state root and another instance of the 00:56:09.559 --> 00:56:10.549 align:start position:0% state root and another instance of the proof 00:56:10.549 --> 00:56:10.559 align:start position:0% proof 00:56:10.559 --> 00:56:13.910 align:start position:0% proof programs<00:56:11.559> so<00:56:11.720> the<00:56:11.839> state<00:56:12.039> root<00:56:12.480> here<00:56:13.280> is 00:56:13.910 --> 00:56:13.920 align:start position:0% programs so the state root here is 00:56:13.920 --> 00:56:16.870 align:start position:0% programs so the state root here is passed<00:56:14.200> in<00:56:14.400> from<00:56:14.559> the<00:56:14.880> proof<00:56:15.440> struct<00:56:16.319> and<00:56:16.760> at 00:56:16.870 --> 00:56:16.880 align:start position:0% passed in from the proof struct and at 00:56:16.880 --> 00:56:18.470 align:start position:0% passed in from the proof struct and at this<00:56:17.039> point<00:56:17.200> we<00:56:17.359> verified<00:56:17.839> that<00:56:18.079> this<00:56:18.200> can<00:56:18.359> be 00:56:18.470 --> 00:56:18.480 align:start position:0% this point we verified that this can be 00:56:18.480 --> 00:56:21.630 align:start position:0% this point we verified that this can be trusted<00:56:19.440> so<00:56:19.640> we'll<00:56:20.079> um<00:56:20.280> use<00:56:20.520> that<00:56:20.720> value<00:56:21.480> so 00:56:21.630 --> 00:56:21.640 align:start position:0% trusted so we'll um use that value so 00:56:21.640 --> 00:56:22.950 align:start position:0% trusted so we'll um use that value so this<00:56:21.760> will<00:56:21.920> be 00:56:22.950 --> 00:56:22.960 align:start position:0% this will be 00:56:22.960 --> 00:56:27.870 align:start position:0% this will be proof.<00:56:23.960> L2<00:56:24.799> State<00:56:25.160> root<00:56:26.520> and<00:56:26.640> then<00:56:26.799> we<00:56:26.920> need<00:56:27.119> to 00:56:27.870 --> 00:56:27.880 align:start position:0% proof. L2 State root and then we need to 00:56:27.880 --> 00:56:29.390 align:start position:0% proof. L2 State root and then we need to um<00:56:28.039> add<00:56:28.240> another<00:56:28.559> instance<00:56:28.839> of<00:56:29.000> those<00:56:29.160> proof 00:56:29.390 --> 00:56:29.400 align:start position:0% um add another instance of those proof 00:56:29.400 --> 00:56:32.470 align:start position:0% um add another instance of those proof prams<00:56:29.960> this<00:56:30.160> time<00:56:30.559> for<00:56:31.559> the<00:56:31.720> inbox<00:56:32.160> contract 00:56:32.470 --> 00:56:32.480 align:start position:0% prams this time for the inbox contract 00:56:32.480 --> 00:56:33.910 align:start position:0% prams this time for the inbox contract on<00:56:32.559> the<00:56:32.640> destination<00:56:33.079> chain<00:56:33.440> so<00:56:33.599> we<00:56:33.680> can 00:56:33.910 --> 00:56:33.920 align:start position:0% on the destination chain so we can 00:56:33.920 --> 00:56:36.549 align:start position:0% on the destination chain so we can duplicate<00:56:34.440> this<00:56:34.920> line<00:56:35.920> and<00:56:36.000> then<00:56:36.160> instead<00:56:36.400> of 00:56:36.549 --> 00:56:36.559 align:start position:0% duplicate this line and then instead of 00:56:36.559 --> 00:56:39.069 align:start position:0% duplicate this line and then instead of calling<00:56:36.760> it<00:56:36.920> DST<00:56:37.359> L2<00:56:37.799> State<00:56:38.079> root<00:56:38.319> proof<00:56:38.559> prams 00:56:39.069 --> 00:56:39.079 align:start position:0% calling it DST L2 State root proof prams 00:56:39.079 --> 00:56:45.270 align:start position:0% calling it DST L2 State root proof prams we<00:56:39.160> can<00:56:39.319> call<00:56:39.480> it<00:56:39.720> DST<00:56:40.839> L2<00:56:41.839> account<00:56:42.599> proof 00:56:45.270 --> 00:56:45.280 align:start position:0% 00:56:45.280 --> 00:56:48.630 align:start position:0% prams<00:56:46.280> and<00:56:46.400> then<00:56:46.599> copy<00:56:46.880> that<00:56:47.000> field<00:56:47.440> name<00:56:48.440> down 00:56:48.630 --> 00:56:48.640 align:start position:0% prams and then copy that field name down 00:56:48.640 --> 00:56:50.029 align:start position:0% prams and then copy that field name down here<00:56:48.760> for<00:56:48.920> the<00:56:49.000> second<00:56:49.240> storage<00:56:49.599> proof<00:56:49.839> we<00:56:49.920> can 00:56:50.029 --> 00:56:50.039 align:start position:0% here for the second storage proof we can 00:56:50.039 --> 00:56:51.789 align:start position:0% here for the second storage proof we can pass<00:56:50.200> that<00:56:50.359> in<00:56:50.480> as<00:56:50.640> the<00:56:50.720> second<00:56:51.000> argument<00:56:51.599> so 00:56:51.789 --> 00:56:51.799 align:start position:0% pass that in as the second argument so 00:56:51.799 --> 00:56:55.630 align:start position:0% pass that in as the second argument so this<00:56:51.960> looks<00:56:52.240> like<00:56:53.079> proof<00:56:53.839> dot.<00:56:54.839> destination 00:56:55.630 --> 00:56:55.640 align:start position:0% this looks like proof dot. destination 00:56:55.640 --> 00:57:00.270 align:start position:0% this looks like proof dot. destination account<00:56:55.880> proof<00:56:56.240> programs<00:56:57.079> um 00:57:00.270 --> 00:57:00.280 align:start position:0% 00:57:00.280 --> 00:57:02.950 align:start position:0% field<00:57:01.280> and<00:57:01.400> then<00:57:01.559> for<00:57:01.760> the<00:57:01.920> case<00:57:02.359> again<00:57:02.720> where 00:57:02.950 --> 00:57:02.960 align:start position:0% field and then for the case again where 00:57:02.960 --> 00:57:04.750 align:start position:0% field and then for the case again where is<00:57:03.160> valid<00:57:03.359> L2<00:57:03.680> State<00:57:03.920> comes<00:57:04.119> back<00:57:04.359> false<00:57:04.680> we 00:57:04.750 --> 00:57:04.760 align:start position:0% is valid L2 State comes back false we 00:57:04.760 --> 00:57:06.990 align:start position:0% is valid L2 State comes back false we need<00:57:04.880> a<00:57:05.039> custom<00:57:05.359> error<00:57:05.640> to<00:57:06.039> to<00:57:06.160> throw<00:57:06.599> as<00:57:06.720> a 00:57:06.990 --> 00:57:07.000 align:start position:0% need a custom error to to throw as a 00:57:07.000 --> 00:57:09.190 align:start position:0% need a custom error to to throw as a reversion<00:57:07.559> in<00:57:07.680> that<00:57:07.880> case<00:57:08.559> so<00:57:08.680> we<00:57:08.799> can<00:57:08.920> Define 00:57:09.190 --> 00:57:09.200 align:start position:0% reversion in that case so we can Define 00:57:09.200 --> 00:57:17.630 align:start position:0% reversion in that case so we can Define that<00:57:09.319> up<00:57:09.960> here<00:57:10.960> error<00:57:11.799> invalid<00:57:12.760> L2 00:57:17.630 --> 00:57:17.640 align:start position:0% 00:57:17.640 --> 00:57:22.109 align:start position:0% State<00:57:18.640> copy 00:57:22.109 --> 00:57:22.119 align:start position:0% 00:57:22.119 --> 00:57:26.589 align:start position:0% that<00:57:23.119> and<00:57:23.240> this<00:57:23.359> will<00:57:23.520> be<00:57:23.799> so<00:57:24.280> if<00:57:25.039> not<00:57:25.680> is<00:57:26.200> valid 00:57:26.589 --> 00:57:26.599 align:start position:0% that and this will be so if not is valid 00:57:26.599 --> 00:57:28.549 align:start position:0% that and this will be so if not is valid L2 00:57:28.549 --> 00:57:28.559 align:start position:0% L2 00:57:28.559 --> 00:57:32.910 align:start position:0% L2 State<00:57:29.559> revert<00:57:30.440> with<00:57:30.640> that<00:57:30.839> custom 00:57:32.910 --> 00:57:32.920 align:start position:0% State revert with that custom 00:57:32.920 --> 00:57:34.829 align:start position:0% State revert with that custom error 00:57:34.829 --> 00:57:34.839 align:start position:0% error 00:57:34.839 --> 00:57:36.750 align:start position:0% error cool<00:57:35.839> and<00:57:35.920> then<00:57:36.039> so<00:57:36.160> if<00:57:36.240> you<00:57:36.359> remember<00:57:36.640> from 00:57:36.750 --> 00:57:36.760 align:start position:0% cool and then so if you remember from 00:57:36.760 --> 00:57:39.270 align:start position:0% cool and then so if you remember from the<00:57:36.880> first<00:57:37.079> storage<00:57:37.480> proof<00:57:38.000> we<00:57:38.359> had<00:57:38.720> an<00:57:38.920> issue 00:57:39.270 --> 00:57:39.280 align:start position:0% the first storage proof we had an issue 00:57:39.280 --> 00:57:40.589 align:start position:0% the first storage proof we had an issue trusting<00:57:39.720> the<00:57:39.839> storage<00:57:40.160> key<00:57:40.359> that<00:57:40.440> gets 00:57:40.589 --> 00:57:40.599 align:start position:0% trusting the storage key that gets 00:57:40.599 --> 00:57:43.270 align:start position:0% trusting the storage key that gets passed<00:57:40.839> in<00:57:40.920> from<00:57:41.079> the<00:57:41.520> fulfiller<00:57:42.520> um<00:57:42.960> you<00:57:43.079> can 00:57:43.270 --> 00:57:43.280 align:start position:0% passed in from the fulfiller um you can 00:57:43.280 --> 00:57:44.910 align:start position:0% passed in from the fulfiller um you can assume<00:57:43.640> that<00:57:43.760> we<00:57:43.880> have<00:57:44.000> the<00:57:44.119> same<00:57:44.359> issue<00:57:44.799> in 00:57:44.910 --> 00:57:44.920 align:start position:0% assume that we have the same issue in 00:57:44.920 --> 00:57:47.510 align:start position:0% assume that we have the same issue in the<00:57:45.039> second<00:57:45.280> storage<00:57:45.640> proof<00:57:45.960> and<00:57:46.119> we<00:57:46.520> do 00:57:47.510 --> 00:57:47.520 align:start position:0% the second storage proof and we do 00:57:47.520 --> 00:57:49.270 align:start position:0% the second storage proof and we do luckily<00:57:47.960> it's<00:57:48.079> a<00:57:48.240> little<00:57:48.480> bit<00:57:48.680> easier<00:57:49.079> to 00:57:49.270 --> 00:57:49.280 align:start position:0% luckily it's a little bit easier to 00:57:49.280 --> 00:57:52.109 align:start position:0% luckily it's a little bit easier to solve<00:57:49.799> on<00:57:50.160> this<00:57:50.400> side<00:57:50.559> of<00:57:50.720> things<00:57:51.079> because<00:57:51.839> um 00:57:52.109 --> 00:57:52.119 align:start position:0% solve on this side of things because um 00:57:52.119 --> 00:57:53.430 align:start position:0% solve on this side of things because um like<00:57:52.240> I<00:57:52.319> said<00:57:52.480> at<00:57:52.599> the<00:57:52.720> beginning<00:57:53.160> of<00:57:53.319> the 00:57:53.430 --> 00:57:53.440 align:start position:0% like I said at the beginning of the 00:57:53.440 --> 00:57:55.789 align:start position:0% like I said at the beginning of the walkth<00:57:53.720> through<00:57:53.960> here<00:57:54.640> the<00:57:54.799> out<00:57:55.240> the<00:57:55.359> outbox 00:57:55.789 --> 00:57:55.799 align:start position:0% walkth through here the out the outbox 00:57:55.799 --> 00:57:57.990 align:start position:0% walkth through here the out the outbox contract<00:57:56.400> red<00:57:56.559> derives<00:57:57.160> where<00:57:57.480> that<00:57:57.599> storage 00:57:57.990 --> 00:57:58.000 align:start position:0% contract red derives where that storage 00:57:58.000 --> 00:58:00.109 align:start position:0% contract red derives where that storage key<00:57:58.280> location<00:57:58.960> should<00:57:59.240> be<00:57:59.520> already<00:57:59.839> and<00:57:59.960> that 00:58:00.109 --> 00:58:00.119 align:start position:0% key location should be already and that 00:58:00.119 --> 00:58:02.510 align:start position:0% key location should be already and that gets<00:58:00.280> passed<00:58:00.559> in<00:58:01.200> so<00:58:01.440> we<00:58:01.520> can<00:58:01.799> just<00:58:02.039> reassign 00:58:02.510 --> 00:58:02.520 align:start position:0% gets passed in so we can just reassign 00:58:02.520 --> 00:58:04.589 align:start position:0% gets passed in so we can just reassign the<00:58:02.640> storage<00:58:03.000> key<00:58:03.200> value<00:58:03.680> with<00:58:03.880> this<00:58:04.160> pass<00:58:04.400> in 00:58:04.589 --> 00:58:04.599 align:start position:0% the storage key value with this pass in 00:58:04.599 --> 00:58:06.589 align:start position:0% the storage key value with this pass in inbox<00:58:05.119> contract<00:58:05.480> storage 00:58:06.589 --> 00:58:06.599 align:start position:0% inbox contract storage 00:58:06.599 --> 00:58:09.549 align:start position:0% inbox contract storage key<00:58:07.599> uh<00:58:07.680> we'll<00:58:07.839> do<00:58:08.000> that<00:58:08.160> above<00:58:08.520> step<00:58:08.920> five<00:58:09.400> so 00:58:09.549 --> 00:58:09.559 align:start position:0% key uh we'll do that above step five so 00:58:09.559 --> 00:58:13.349 align:start position:0% key uh we'll do that above step five so this<00:58:09.680> will<00:58:09.839> be<00:58:10.400> proof.<00:58:11.160> DST<00:58:11.960> L2<00:58:12.720> account<00:58:13.079> proof 00:58:13.349 --> 00:58:13.359 align:start position:0% this will be proof. DST L2 account proof 00:58:13.359 --> 00:58:17.710 align:start position:0% this will be proof. DST L2 account proof prams<00:58:13.839> this<00:58:14.200> time.<00:58:15.200> storage<00:58:15.640> key<00:58:16.200> is<00:58:16.359> equal<00:58:16.720> to 00:58:17.710 --> 00:58:17.720 align:start position:0% prams this time. storage key is equal to 00:58:17.720 --> 00:58:20.990 align:start position:0% prams this time. storage key is equal to inbox<00:58:18.359> contract<00:58:18.760> storage 00:58:20.990 --> 00:58:21.000 align:start position:0% inbox contract storage 00:58:21.000 --> 00:58:23.349 align:start position:0% inbox contract storage key<00:58:22.000> and<00:58:22.200> what<00:58:22.319> that's<00:58:22.520> going<00:58:22.680> to<00:58:22.839> do<00:58:23.119> is 00:58:23.349 --> 00:58:23.359 align:start position:0% key and what that's going to do is 00:58:23.359 --> 00:58:25.870 align:start position:0% key and what that's going to do is ensure<00:58:24.079> that<00:58:24.240> we're<00:58:24.880> uh<00:58:25.000> verifying<00:58:25.599> against 00:58:25.870 --> 00:58:25.880 align:start position:0% ensure that we're uh verifying against 00:58:25.880 --> 00:58:27.829 align:start position:0% ensure that we're uh verifying against the<00:58:26.160> correct<00:58:26.440> storage<00:58:26.839> location<00:58:27.440> where<00:58:27.640> the 00:58:27.829 --> 00:58:27.839 align:start position:0% the correct storage location where the 00:58:27.839 --> 00:58:30.510 align:start position:0% the correct storage location where the execution<00:58:28.400> receipt<00:58:28.799> should<00:58:29.079> exist<00:58:29.680> on<00:58:30.400> the 00:58:30.510 --> 00:58:30.520 align:start position:0% execution receipt should exist on the 00:58:30.520 --> 00:58:33.270 align:start position:0% execution receipt should exist on the inbox<00:58:31.000> contract<00:58:31.359> on<00:58:31.480> the<00:58:31.640> destination 00:58:33.270 --> 00:58:33.280 align:start position:0% inbox contract on the destination 00:58:33.280 --> 00:58:37.270 align:start position:0% inbox contract on the destination chain<00:58:34.280> so<00:58:34.480> at<00:58:34.640> this<00:58:34.839> point<00:58:35.319> we<00:58:35.599> have<00:58:36.000> a<00:58:36.359> fully 00:58:37.270 --> 00:58:37.280 align:start position:0% chain so at this point we have a fully 00:58:37.280 --> 00:58:40.470 align:start position:0% chain so at this point we have a fully verifiable<00:58:38.079> proof<00:58:39.079> um<00:58:39.240> the<00:58:39.400> last<00:58:39.599> step<00:58:40.039> is<00:58:40.319> we 00:58:40.470 --> 00:58:40.480 align:start position:0% verifiable proof um the last step is we 00:58:40.480 --> 00:58:42.230 align:start position:0% verifiable proof um the last step is we just<00:58:40.640> have<00:58:40.760> to<00:58:40.920> confirm<00:58:41.280> that<00:58:41.480> finality<00:58:41.880> delay 00:58:42.230 --> 00:58:42.240 align:start position:0% just have to confirm that finality delay 00:58:42.240 --> 00:58:43.710 align:start position:0% just have to confirm that finality delay seconds<00:58:42.520> is<00:58:42.640> not<00:58:42.760> still<00:58:42.960> in 00:58:43.710 --> 00:58:43.720 align:start position:0% seconds is not still in 00:58:43.720 --> 00:58:46.910 align:start position:0% seconds is not still in progress<00:58:44.720> we<00:58:45.039> have<00:58:45.760> uh<00:58:46.079> the<00:58:46.319> receipt<00:58:46.680> being 00:58:46.910 --> 00:58:46.920 align:start position:0% progress we have uh the receipt being 00:58:46.920 --> 00:58:48.630 align:start position:0% progress we have uh the receipt being passed<00:58:47.160> in<00:58:47.359> here<00:58:47.559> so<00:58:47.720> we<00:58:47.799> can<00:58:47.960> use<00:58:48.200> that<00:58:48.359> for 00:58:48.630 --> 00:58:48.640 align:start position:0% passed in here so we can use that for 00:58:48.640 --> 00:58:51.029 align:start position:0% passed in here so we can use that for this 00:58:51.029 --> 00:58:51.039 align:start position:0% 00:58:51.039 --> 00:58:53.230 align:start position:0% check<00:58:52.039> and<00:58:52.200> for<00:58:52.480> when<00:58:52.680> it<00:58:52.799> is<00:58:52.920> still<00:58:53.079> in 00:58:53.230 --> 00:58:53.240 align:start position:0% check and for when it is still in 00:58:53.240 --> 00:58:54.710 align:start position:0% check and for when it is still in progress<00:58:53.559> we<00:58:53.640> can<00:58:53.760> add<00:58:53.880> a<00:58:54.000> custom<00:58:54.280> error<00:58:54.599> at 00:58:54.710 --> 00:58:54.720 align:start position:0% progress we can add a custom error at 00:58:54.720 --> 00:58:56.349 align:start position:0% progress we can add a custom error at the<00:58:54.880> top<00:58:55.079> this<00:58:55.160> will<00:58:55.280> be<00:58:55.400> our<00:58:55.559> last<00:58:55.720> error<00:58:56.240> so 00:58:56.349 --> 00:58:56.359 align:start position:0% the top this will be our last error so 00:58:56.359 --> 00:58:58.870 align:start position:0% the top this will be our last error so this<00:58:56.480> will<00:58:56.960> be<00:58:57.960> uh 00:58:58.870 --> 00:58:58.880 align:start position:0% this will be uh 00:58:58.880 --> 00:59:00.870 align:start position:0% this will be uh error 00:59:00.870 --> 00:59:00.880 align:start position:0% error 00:59:00.880 --> 00:59:07.270 align:start position:0% error finality<00:59:01.960> delay<00:59:02.960> seconds<00:59:03.839> in 00:59:07.270 --> 00:59:07.280 align:start position:0% 00:59:07.280 --> 00:59:09.789 align:start position:0% progress<00:59:08.280> copy 00:59:09.789 --> 00:59:09.799 align:start position:0% progress copy 00:59:09.799 --> 00:59:11.829 align:start position:0% progress copy that<00:59:10.799> and<00:59:10.920> then<00:59:11.039> down<00:59:11.240> here<00:59:11.359> at<00:59:11.440> the<00:59:11.520> bottom<00:59:11.760> of 00:59:11.829 --> 00:59:11.839 align:start position:0% that and then down here at the bottom of 00:59:11.839 --> 00:59:12.710 align:start position:0% that and then down here at the bottom of this 00:59:12.710 --> 00:59:12.720 align:start position:0% this 00:59:12.720 --> 00:59:17.430 align:start position:0% this function<00:59:13.720> if<00:59:14.640> fulfillment<00:59:15.480> info. 00:59:17.430 --> 00:59:17.440 align:start position:0% function if fulfillment info. 00:59:17.440 --> 00:59:19.390 align:start position:0% function if fulfillment info. timestamp<00:59:18.440> plus 00:59:19.390 --> 00:59:19.400 align:start position:0% timestamp plus 00:59:19.400 --> 00:59:22.470 align:start position:0% timestamp plus request.<00:59:20.400> finality<00:59:20.839> delay<00:59:21.240> seconds<00:59:22.240> is 00:59:22.470 --> 00:59:22.480 align:start position:0% request. finality delay seconds is 00:59:22.480 --> 00:59:25.549 align:start position:0% request. finality delay seconds is greater<00:59:22.839> than<00:59:23.839> if<00:59:23.960> you'll<00:59:24.200> remember<00:59:24.880> for<00:59:25.440> uh 00:59:25.549 --> 00:59:25.559 align:start position:0% greater than if you'll remember for uh 00:59:25.559 --> 00:59:28.069 align:start position:0% greater than if you'll remember for uh the<00:59:25.680> proof<00:59:26.440> we<00:59:26.680> defined<00:59:27.119> the<00:59:27.240> L2<00:59:27.599> block<00:59:27.880> time 00:59:28.069 --> 00:59:28.079 align:start position:0% the proof we defined the L2 block time 00:59:28.079 --> 00:59:29.990 align:start position:0% the proof we defined the L2 block time stamp<00:59:28.400> up<00:59:28.599> here<00:59:29.280> this<00:59:29.359> is<00:59:29.520> exactly<00:59:29.839> what<00:59:29.920> we 00:59:29.990 --> 00:59:30.000 align:start position:0% stamp up here this is exactly what we 00:59:30.000 --> 00:59:34.589 align:start position:0% stamp up here this is exactly what we need<00:59:30.160> to<00:59:30.720> use<00:59:31.760> um<00:59:32.760> for<00:59:33.079> this<00:59:33.440> time<00:59:33.680> stamp<00:59:33.920> based 00:59:34.589 --> 00:59:34.599 align:start position:0% need to use um for this time stamp based 00:59:34.599 --> 00:59:40.150 align:start position:0% need to use um for this time stamp based protection<00:59:35.160> so<00:59:35.319> we<00:59:35.400> can<00:59:35.559> do<00:59:36.280> proof.<00:59:37.280> L2<00:59:37.799> block 00:59:40.150 --> 00:59:40.160 align:start position:0% 00:59:40.160 --> 00:59:42.870 align:start position:0% timestamp<00:59:41.160> if<00:59:41.440> that<00:59:41.720> if<00:59:41.920> the<00:59:42.240> time<00:59:42.480> stamp<00:59:42.760> at 00:59:42.870 --> 00:59:42.880 align:start position:0% timestamp if that if the time stamp at 00:59:42.880 --> 00:59:45.069 align:start position:0% timestamp if that if the time stamp at which<00:59:43.000> it<00:59:43.119> was<00:59:43.240> submitted<00:59:43.839> plus<00:59:44.400> the<00:59:44.960> uh 00:59:45.069 --> 00:59:45.079 align:start position:0% which it was submitted plus the uh 00:59:45.079 --> 00:59:46.710 align:start position:0% which it was submitted plus the uh configured<00:59:45.520> finality<00:59:45.880> delay<00:59:46.160> seconds<00:59:46.520> is 00:59:46.710 --> 00:59:46.720 align:start position:0% configured finality delay seconds is 00:59:46.720 --> 00:59:48.270 align:start position:0% configured finality delay seconds is greater<00:59:47.039> than<00:59:47.200> the<00:59:47.359> time<00:59:47.839> that<00:59:47.920> we're<00:59:48.079> using 00:59:48.270 --> 00:59:48.280 align:start position:0% greater than the time that we're using 00:59:48.280 --> 00:59:50.750 align:start position:0% greater than the time that we're using for<00:59:48.440> this<00:59:48.599> proof<00:59:49.480> then<00:59:49.839> we<00:59:50.079> can't<00:59:50.319> accept<00:59:50.599> this 00:59:50.750 --> 00:59:50.760 align:start position:0% for this proof then we can't accept this 00:59:50.760 --> 00:59:52.670 align:start position:0% for this proof then we can't accept this proof<00:59:51.119> because<00:59:51.440> final<00:59:51.920> finality<00:59:52.359> delay 00:59:52.670 --> 00:59:52.680 align:start position:0% proof because final finality delay 00:59:52.680 --> 00:59:54.589 align:start position:0% proof because final finality delay seconds<00:59:52.960> is<00:59:53.079> still<00:59:53.240> in<00:59:53.440> progress<00:59:54.319> so<00:59:54.480> that's 00:59:54.589 --> 00:59:54.599 align:start position:0% seconds is still in progress so that's 00:59:54.599 --> 00:59:57.390 align:start position:0% seconds is still in progress so that's what<00:59:54.720> this<00:59:54.839> line<00:59:55.039> is<00:59:55.200> doing<00:59:55.440> so<00:59:55.559> we'<00:59:55.720> revert 00:59:57.390 --> 00:59:57.400 align:start position:0% what this line is doing so we' revert 00:59:57.400 --> 00:59:58.950 align:start position:0% what this line is doing so we' revert with<00:59:57.559> that<00:59:57.720> new<00:59:57.880> custom<00:59:58.200> error<00:59:58.520> finality 00:59:58.950 --> 00:59:58.960 align:start position:0% with that new custom error finality 00:59:58.960 --> 01:00:01.950 align:start position:0% with that new custom error finality delay<00:59:59.240> seconds<00:59:59.520> and<01:00:00.000> progress<01:00:01.000> and<01:00:01.079> then<01:00:01.280> cool 01:00:01.950 --> 01:00:01.960 align:start position:0% delay seconds and progress and then cool 01:00:01.960 --> 01:00:04.230 align:start position:0% delay seconds and progress and then cool that's<01:00:02.359> um<01:00:02.520> all<01:00:02.599> of<01:00:02.720> our 01:00:04.230 --> 01:00:04.240 align:start position:0% that's um all of our 01:00:04.240 --> 01:00:08.670 align:start position:0% that's um all of our steps<01:00:05.240> but<01:00:05.400> there<01:00:05.559> is<01:00:05.920> one<01:00:06.520> final<01:00:07.000> piece<01:00:07.599> of<01:00:08.280> uh 01:00:08.670 --> 01:00:08.680 align:start position:0% steps but there is one final piece of uh 01:00:08.680 --> 01:00:10.870 align:start position:0% steps but there is one final piece of uh data<01:00:08.960> connection<01:00:09.400> that<01:00:09.520> we're<01:00:09.680> forgetting 01:00:10.870 --> 01:00:10.880 align:start position:0% data connection that we're forgetting 01:00:10.880 --> 01:00:15.990 align:start position:0% data connection that we're forgetting here<01:00:12.000> and<01:00:13.000> that<01:00:13.160> is<01:00:13.280> stemming<01:00:13.799> because<01:00:14.280> of<01:00:15.160> um 01:00:15.990 --> 01:00:16.000 align:start position:0% here and that is stemming because of um 01:00:16.000 --> 01:00:18.950 align:start position:0% here and that is stemming because of um well<01:00:16.839> we'<01:00:17.039> confirmed<01:00:17.760> a<01:00:18.119> specific<01:00:18.559> storage 01:00:18.950 --> 01:00:18.960 align:start position:0% well we' confirmed a specific storage 01:00:18.960 --> 01:00:20.829 align:start position:0% well we' confirmed a specific storage location<01:00:19.400> in<01:00:19.520> the<01:00:19.599> inbox<01:00:20.119> contract<01:00:20.599> on<01:00:20.720> the 01:00:20.829 --> 01:00:20.839 align:start position:0% location in the inbox contract on the 01:00:20.839 --> 01:00:23.069 align:start position:0% location in the inbox contract on the destination<01:00:21.319> chain<01:00:22.119> and<01:00:22.200> then<01:00:22.359> we<01:00:22.480> confirmed 01:00:23.069 --> 01:00:23.079 align:start position:0% destination chain and then we confirmed 01:00:23.079 --> 01:00:26.750 align:start position:0% destination chain and then we confirmed a<01:00:23.280> past<01:00:23.520> in<01:00:24.039> receipt<01:00:25.039> uh<01:00:26.000> satisfies<01:00:26.559> that 01:00:26.750 --> 01:00:26.760 align:start position:0% a past in receipt uh satisfies that 01:00:26.760 --> 01:00:29.470 align:start position:0% a past in receipt uh satisfies that finality<01:00:27.160> delay<01:00:27.480> seconds<01:00:28.319> requirement<01:00:29.319> but 01:00:29.470 --> 01:00:29.480 align:start position:0% finality delay seconds requirement but 01:00:29.480 --> 01:00:31.230 align:start position:0% finality delay seconds requirement but we<01:00:29.599> did<01:00:29.760> not<01:00:29.960> confirm<01:00:30.640> that<01:00:30.799> that<01:00:30.960> receipt 01:00:31.230 --> 01:00:31.240 align:start position:0% we did not confirm that that receipt 01:00:31.240 --> 01:00:32.630 align:start position:0% we did not confirm that that receipt that<01:00:31.319> we're<01:00:31.440> using<01:00:31.640> for<01:00:31.760> this<01:00:31.880> final<01:00:32.160> check<01:00:32.480> is 01:00:32.630 --> 01:00:32.640 align:start position:0% that we're using for this final check is 01:00:32.640 --> 01:00:34.150 align:start position:0% that we're using for this final check is the<01:00:32.720> same<01:00:32.960> value<01:00:33.280> as<01:00:33.400> the<01:00:33.480> one<01:00:33.599> that<01:00:33.680> we<01:00:33.799> just 01:00:34.150 --> 01:00:34.160 align:start position:0% the same value as the one that we just 01:00:34.160 --> 01:00:36.829 align:start position:0% the same value as the one that we just verified<01:00:35.160> so<01:00:35.720> uh<01:00:35.839> we<01:00:35.960> need<01:00:36.119> to<01:00:36.319> make<01:00:36.440> sure<01:00:36.720> that 01:00:36.829 --> 01:00:36.839 align:start position:0% verified so uh we need to make sure that 01:00:36.839 --> 01:00:38.670 align:start position:0% verified so uh we need to make sure that the<01:00:36.920> storage<01:00:37.359> value<01:00:37.760> for<01:00:37.960> the<01:00:38.079> second<01:00:38.319> storage 01:00:38.670 --> 01:00:38.680 align:start position:0% the storage value for the second storage 01:00:38.680 --> 01:00:40.390 align:start position:0% the storage value for the second storage proof<01:00:39.079> is<01:00:39.240> equal<01:00:39.520> to<01:00:39.720> the 01:00:40.390 --> 01:00:40.400 align:start position:0% proof is equal to the 01:00:40.400 --> 01:00:42.589 align:start position:0% proof is equal to the encoded<01:00:41.400> execution<01:00:41.960> receipt<01:00:42.400> that<01:00:42.480> we're 01:00:42.589 --> 01:00:42.599 align:start position:0% encoded execution receipt that we're 01:00:42.599 --> 01:00:44.910 align:start position:0% encoded execution receipt that we're using<01:00:42.880> for<01:00:43.039> this<01:00:43.200> timestamp<01:00:44.119> um<01:00:44.400> check<01:00:44.680> in<01:00:44.760> the 01:00:44.910 --> 01:00:44.920 align:start position:0% using for this timestamp um check in the 01:00:44.920 --> 01:00:47.630 align:start position:0% using for this timestamp um check in the last<01:00:45.119> step<01:00:45.960> and<01:00:46.079> so<01:00:46.400> that<01:00:46.720> represents<01:00:47.280> the 01:00:47.630 --> 01:00:47.640 align:start position:0% last step and so that represents the 01:00:47.640 --> 01:00:49.470 align:start position:0% last step and so that represents the final<01:00:48.039> piece<01:00:48.319> that<01:00:48.440> we<01:00:48.520> still<01:00:48.720> have<01:00:48.839> to<01:00:48.960> set<01:00:49.160> up 01:00:49.470 --> 01:00:49.480 align:start position:0% final piece that we still have to set up 01:00:49.480 --> 01:00:53.309 align:start position:0% final piece that we still have to set up to<01:00:50.119> um<01:00:50.280> secure<01:00:50.680> this<01:00:51.200> thing<01:00:52.200> we<01:00:52.359> can<01:00:52.760> set<01:00:52.960> up 01:00:53.309 --> 01:00:53.319 align:start position:0% to um secure this thing we can set up 01:00:53.319 --> 01:00:55.549 align:start position:0% to um secure this thing we can set up the<01:00:53.760> encoding<01:00:54.480> of<01:00:54.680> the<01:00:54.799> Fulfillment<01:00:55.280> info 01:00:55.549 --> 01:00:55.559 align:start position:0% the encoding of the Fulfillment info 01:00:55.559 --> 01:01:01.750 align:start position:0% the encoding of the Fulfillment info struct<01:00:56.119> as<01:00:56.359> a<01:00:56.599> separate<01:00:57.520> private<01:00:58.520> um<01:00:58.680> helper 01:01:01.750 --> 01:01:01.760 align:start position:0% 01:01:01.760 --> 01:01:03.870 align:start position:0% function<01:01:02.760> so<01:01:03.000> this<01:01:03.079> will 01:01:03.870 --> 01:01:03.880 align:start position:0% function so this will 01:01:03.880 --> 01:01:08.190 align:start position:0% function so this will be<01:01:05.359> see<01:01:06.359> this<01:01:06.440> will 01:01:08.190 --> 01:01:08.200 align:start position:0% be see this will 01:01:08.200 --> 01:01:10.549 align:start position:0% be see this will be<01:01:09.200> what<01:01:09.319> do<01:01:09.400> we<01:01:09.520> want<01:01:09.599> to<01:01:09.720> call 01:01:10.549 --> 01:01:10.559 align:start position:0% be what do we want to call 01:01:10.559 --> 01:01:14.750 align:start position:0% be what do we want to call that 01:01:14.750 --> 01:01:14.760 align:start position:0% 01:01:14.760 --> 01:01:33.750 align:start position:0% encode<01:01:15.760> fulfillment<01:01:16.559> info 01:01:33.750 --> 01:01:33.760 align:start position:0% 01:01:33.760 --> 01:01:35.549 align:start position:0% okay<01:01:34.000> so<01:01:34.160> for<01:01:34.319> encoding<01:01:34.720> fulfillment<01:01:35.200> info<01:01:35.480> we 01:01:35.549 --> 01:01:35.559 align:start position:0% okay so for encoding fulfillment info we 01:01:35.559 --> 01:01:37.750 align:start position:0% okay so for encoding fulfillment info we need<01:01:35.680> to<01:01:35.880> pass<01:01:36.119> in<01:01:36.599> the<01:01:37.079> uh<01:01:37.200> struct<01:01:37.559> that<01:01:37.640> we're 01:01:37.750 --> 01:01:37.760 align:start position:0% need to pass in the uh struct that we're 01:01:37.760 --> 01:01:43.710 align:start position:0% need to pass in the uh struct that we're using<01:01:37.960> for<01:01:38.039> the<01:01:38.160> validation<01:01:38.599> up 01:01:43.710 --> 01:01:43.720 align:start position:0% 01:01:43.720 --> 01:01:47.349 align:start position:0% here<01:01:44.720> and<01:01:45.400> um<01:01:45.599> inside<01:01:45.839> of<01:01:46.039> this<01:01:46.359> it's<01:01:46.599> a<01:01:46.799> simple 01:01:47.349 --> 01:01:47.359 align:start position:0% here and um inside of this it's a simple 01:01:47.359 --> 01:01:52.269 align:start position:0% here and um inside of this it's a simple ai.<01:01:48.160> encode<01:01:48.640> packed<01:01:49.160> so<01:01:50.160> um<01:01:50.799> return<01:01:51.520> ai. 01:01:52.269 --> 01:01:52.279 align:start position:0% ai. encode packed so um return ai. 01:01:52.279 --> 01:01:53.470 align:start position:0% ai. encode packed so um return ai. encode 01:01:53.470 --> 01:01:53.480 align:start position:0% encode 01:01:53.480 --> 01:01:57.190 align:start position:0% encode packed<01:01:54.599> whoops<01:01:55.599> with 01:01:57.190 --> 01:01:57.200 align:start position:0% packed whoops with 01:01:57.200 --> 01:01:58.789 align:start position:0% packed whoops with fulfillment 01:01:58.789 --> 01:01:58.799 align:start position:0% fulfillment 01:01:58.799 --> 01:02:03.349 align:start position:0% fulfillment info.<01:01:59.799> filler<01:02:00.680> and<01:02:00.799> then 01:02:03.349 --> 01:02:03.359 align:start position:0% 01:02:03.359 --> 01:02:04.910 align:start position:0% fulfillment 01:02:04.910 --> 01:02:04.920 align:start position:0% fulfillment 01:02:04.920 --> 01:02:08.910 align:start position:0% fulfillment info.<01:02:05.960> timestamp<01:02:06.960> passed 01:02:08.910 --> 01:02:08.920 align:start position:0% info. timestamp passed 01:02:08.920 --> 01:02:11.430 align:start position:0% info. timestamp passed in<01:02:09.920> this<01:02:10.000> is<01:02:10.200> because<01:02:10.440> of<01:02:10.640> the<01:02:10.760> struct<01:02:11.160> packing 01:02:11.430 --> 01:02:11.440 align:start position:0% in this is because of the struct packing 01:02:11.440 --> 01:02:14.230 align:start position:0% in this is because of the struct packing rules<01:02:12.000> and<01:02:12.440> um<01:02:12.559> solidity<01:02:13.039> storage<01:02:13.520> we<01:02:13.680> have<01:02:13.799> to 01:02:14.230 --> 01:02:14.240 align:start position:0% rules and um solidity storage we have to 01:02:14.240 --> 01:02:18.589 align:start position:0% rules and um solidity storage we have to custom<01:02:14.799> encode<01:02:15.400> this<01:02:15.960> struct<01:02:16.440> here<01:02:17.000> um<01:02:18.000> if<01:02:18.160> I 01:02:18.589 --> 01:02:18.599 align:start position:0% custom encode this struct here um if I 01:02:18.599 --> 01:02:21.109 align:start position:0% custom encode this struct here um if I show<01:02:18.960> you<01:02:19.640> the<01:02:20.079> definition<01:02:20.520> of<01:02:20.640> the<01:02:20.720> struct<01:02:21.039> in 01:02:21.109 --> 01:02:21.119 align:start position:0% show you the definition of the struct in 01:02:21.119 --> 01:02:23.630 align:start position:0% show you the definition of the struct in the<01:02:21.200> inbox<01:02:21.640> contract<01:02:22.079> again<01:02:22.839> we<01:02:22.960> see<01:02:23.319> that<01:02:23.480> it 01:02:23.630 --> 01:02:23.640 align:start position:0% the inbox contract again we see that it 01:02:23.640 --> 01:02:26.029 align:start position:0% the inbox contract again we see that it has<01:02:23.799> two<01:02:24.000> fields<01:02:24.480> timestamp<01:02:24.920> and<01:02:25.039> filler<01:02:25.920> the 01:02:26.029 --> 01:02:26.039 align:start position:0% has two fields timestamp and filler the 01:02:26.039 --> 01:02:28.069 align:start position:0% has two fields timestamp and filler the time<01:02:26.240> stamp<01:02:26.480> is<01:02:26.520> a<01:02:26.640> u<01:02:26.880> 96<01:02:27.520> and<01:02:27.640> the<01:02:27.720> filler<01:02:27.960> is 01:02:28.069 --> 01:02:28.079 align:start position:0% time stamp is a u 96 and the filler is 01:02:28.079 --> 01:02:29.750 align:start position:0% time stamp is a u 96 and the filler is an<01:02:28.240> address<01:02:28.640> so<01:02:28.799> this<01:02:28.920> can<01:02:29.079> get<01:02:29.240> packed<01:02:29.480> into<01:02:29.680> a 01:02:29.750 --> 01:02:29.760 align:start position:0% an address so this can get packed into a 01:02:29.760 --> 01:02:32.549 align:start position:0% an address so this can get packed into a single<01:02:30.000> U<01:02:30.319> 256<01:02:31.000> slot<01:02:31.960> but<01:02:32.079> the<01:02:32.200> way<01:02:32.359> that<01:02:32.440> it 01:02:32.549 --> 01:02:32.559 align:start position:0% single U 256 slot but the way that it 01:02:32.559 --> 01:02:33.950 align:start position:0% single U 256 slot but the way that it gets<01:02:32.760> packed<01:02:33.000> or<01:02:33.119> the<01:02:33.200> ordering<01:02:33.520> that<01:02:33.640> it<01:02:33.720> gets 01:02:33.950 --> 01:02:33.960 align:start position:0% gets packed or the ordering that it gets 01:02:33.960 --> 01:02:37.109 align:start position:0% gets packed or the ordering that it gets packed<01:02:34.440> is<01:02:34.720> in<01:02:34.880> the<01:02:35.039> order<01:02:35.559> of<01:02:35.920> the<01:02:36.400> uh<01:02:36.559> defined 01:02:37.109 --> 01:02:37.119 align:start position:0% packed is in the order of the uh defined 01:02:37.119 --> 01:02:39.710 align:start position:0% packed is in the order of the uh defined fields<01:02:38.119> and<01:02:38.400> it<01:02:38.799> uh<01:02:38.960> packs<01:02:39.200> them<01:02:39.359> into<01:02:39.559> the 01:02:39.710 --> 01:02:39.720 align:start position:0% fields and it uh packs them into the 01:02:39.720 --> 01:02:42.109 align:start position:0% fields and it uh packs them into the lowest<01:02:40.319> value<01:02:40.799> bits<01:02:41.200> first<01:02:41.559> so<01:02:41.760> the<01:02:41.920> time 01:02:42.109 --> 01:02:42.119 align:start position:0% lowest value bits first so the time 01:02:42.119 --> 01:02:43.870 align:start position:0% lowest value bits first so the time stamp<01:02:42.440> actually<01:02:42.640> ends<01:02:42.880> up<01:02:43.000> on<01:02:43.119> the<01:02:43.319> right<01:02:43.720> side 01:02:43.870 --> 01:02:43.880 align:start position:0% stamp actually ends up on the right side 01:02:43.880 --> 01:02:45.390 align:start position:0% stamp actually ends up on the right side of<01:02:44.000> the<01:02:44.119> storage<01:02:44.440> slot<01:02:44.799> and<01:02:44.880> then<01:02:44.960> the<01:02:45.039> fillers 01:02:45.390 --> 01:02:45.400 align:start position:0% of the storage slot and then the fillers 01:02:45.400 --> 01:02:48.029 align:start position:0% of the storage slot and then the fillers on<01:02:45.520> the<01:02:45.640> left<01:02:46.200> so<01:02:46.359> in<01:02:46.440> order<01:02:46.640> to<01:02:46.799> recreate<01:02:47.440> that 01:02:48.029 --> 01:02:48.039 align:start position:0% on the left so in order to recreate that 01:02:48.039 --> 01:02:51.109 align:start position:0% on the left so in order to recreate that um<01:02:48.720> alignment<01:02:49.400> we<01:02:49.559> have<01:02:49.680> to<01:02:50.200> uh<01:02:50.359> use<01:02:50.480> an<01:02:50.640> ai. 01:02:51.109 --> 01:02:51.119 align:start position:0% um alignment we have to uh use an ai. 01:02:51.119 --> 01:02:53.870 align:start position:0% um alignment we have to uh use an ai. incode<01:02:51.480> PCT<01:02:51.760> here<01:02:52.240> instead<01:02:52.520> of<01:02:53.319> uh<01:02:53.559> where<01:02:53.720> we 01:02:53.870 --> 01:02:53.880 align:start position:0% incode PCT here instead of uh where we 01:02:53.880 --> 01:02:56.109 align:start position:0% incode PCT here instead of uh where we pass<01:02:54.119> in<01:02:54.520> like<01:02:54.760> the<01:02:55.119> the<01:02:55.240> fields<01:02:55.520> in<01:02:55.839> reverse 01:02:56.109 --> 01:02:56.119 align:start position:0% pass in like the the fields in reverse 01:02:56.119 --> 01:02:58.549 align:start position:0% pass in like the the fields in reverse order<01:02:56.720> instead<01:02:56.960> of<01:02:57.119> just<01:02:57.240> doing<01:02:57.480> ai.<01:02:58.200> code<01:02:58.400> and 01:02:58.549 --> 01:02:58.559 align:start position:0% order instead of just doing ai. code and 01:02:58.559 --> 01:03:00.309 align:start position:0% order instead of just doing ai. code and passing<01:02:58.799> in<01:02:58.960> the<01:02:59.079> entire<01:02:59.359> struct<01:03:00.079> we<01:03:00.160> would 01:03:00.309 --> 01:03:00.319 align:start position:0% passing in the entire struct we would 01:03:00.319 --> 01:03:02.269 align:start position:0% passing in the entire struct we would have<01:03:00.440> it<01:03:00.520> in<01:03:00.640> reverse<01:03:00.920> order<01:03:01.200> in<01:03:01.319> that 01:03:02.269 --> 01:03:02.279 align:start position:0% have it in reverse order in that 01:03:02.279 --> 01:03:05.349 align:start position:0% have it in reverse order in that case<01:03:03.279> so<01:03:03.559> using<01:03:04.000> this<01:03:04.200> function<01:03:04.599> now<01:03:04.880> we<01:03:04.960> can 01:03:05.349 --> 01:03:05.359 align:start position:0% case so using this function now we can 01:03:05.359 --> 01:03:07.510 align:start position:0% case so using this function now we can override<01:03:06.359> the<01:03:06.520> storage<01:03:06.920> value<01:03:07.200> for<01:03:07.359> this 01:03:07.510 --> 01:03:07.520 align:start position:0% override the storage value for this 01:03:07.520 --> 01:03:09.349 align:start position:0% override the storage value for this final<01:03:07.720> storage<01:03:08.119> proof<01:03:08.720> so<01:03:08.880> this<01:03:08.960> will<01:03:09.119> be 01:03:09.349 --> 01:03:09.359 align:start position:0% final storage proof so this will be 01:03:09.359 --> 01:03:12.630 align:start position:0% final storage proof so this will be proof.<01:03:10.359> DST<01:03:10.880> L2<01:03:11.400> account<01:03:11.640> proof<01:03:11.920> programs. 01:03:12.630 --> 01:03:12.640 align:start position:0% proof. DST L2 account proof programs. 01:03:12.640 --> 01:03:16.069 align:start position:0% proof. DST L2 account proof programs. storage<01:03:13.440> value<01:03:14.440> is<01:03:14.720> equal 01:03:16.069 --> 01:03:16.079 align:start position:0% storage value is equal 01:03:16.079 --> 01:03:20.670 align:start position:0% storage value is equal to<01:03:17.079> encode<01:03:17.720> fulfillment<01:03:18.319> info<01:03:19.079> we<01:03:19.279> pass<01:03:19.480> in 01:03:20.670 --> 01:03:20.680 align:start position:0% to encode fulfillment info we pass in 01:03:20.680 --> 01:03:28.630 align:start position:0% to encode fulfillment info we pass in fulfillment<01:03:21.680> info 01:03:28.630 --> 01:03:28.640 align:start position:0% 01:03:28.640 --> 01:03:30.390 align:start position:0% excellent 01:03:30.390 --> 01:03:30.400 align:start position:0% excellent 01:03:30.400 --> 01:03:34.910 align:start position:0% excellent so<01:03:31.400> that<01:03:31.559> should<01:03:31.880> be<01:03:32.359> our<01:03:33.200> first<01:03:33.599> pass<01:03:34.160> at<01:03:34.480> a 01:03:34.910 --> 01:03:34.920 align:start position:0% so that should be our first pass at a 01:03:34.920 --> 01:03:37.150 align:start position:0% so that should be our first pass at a full<01:03:35.640> implementation<01:03:36.279> for<01:03:36.520> validating<01:03:37.079> one 01:03:37.150 --> 01:03:37.160 align:start position:0% full implementation for validating one 01:03:37.160 --> 01:03:40.710 align:start position:0% full implementation for validating one of<01:03:37.279> these<01:03:37.400> nested<01:03:37.720> storage<01:03:38.520> proofs<01:03:39.520> um<01:03:40.440> we<01:03:40.559> can 01:03:40.710 --> 01:03:40.720 align:start position:0% of these nested storage proofs um we can 01:03:40.720 --> 01:03:43.430 align:start position:0% of these nested storage proofs um we can now<01:03:40.920> see<01:03:41.119> if<01:03:41.240> this<01:03:41.359> is<01:03:41.520> compiling<01:03:42.200> so<01:03:42.400> if<01:03:42.520> we<01:03:42.799> CD 01:03:43.430 --> 01:03:43.440 align:start position:0% now see if this is compiling so if we CD 01:03:43.440 --> 01:03:46.910 align:start position:0% now see if this is compiling so if we CD into<01:03:43.839> the<01:03:44.119> contracts<01:03:44.799> directory<01:03:45.480> can<01:03:45.680> run<01:03:45.920> a 01:03:46.910 --> 01:03:46.920 align:start position:0% into the contracts directory can run a 01:03:46.920 --> 01:03:49.269 align:start position:0% into the contracts directory can run a forge<01:03:47.599> well<01:03:47.720> I<01:03:47.839> like<01:03:48.000> to<01:03:48.160> format<01:03:48.559> it<01:03:48.799> properly 01:03:49.269 --> 01:03:49.279 align:start position:0% forge well I like to format it properly 01:03:49.279 --> 01:03:52.390 align:start position:0% forge well I like to format it properly first<01:03:49.760> and<01:03:49.880> then<01:03:50.000> we<01:03:50.079> can<01:03:50.200> do<01:03:50.319> a<01:03:50.400> forge 01:03:52.390 --> 01:03:52.400 align:start position:0% first and then we can do a forge 01:03:52.400 --> 01:03:56.069 align:start position:0% first and then we can do a forge build<01:03:53.400> to<01:03:53.599> check<01:03:53.760> if<01:03:53.880> it's<01:03:54.079> compiling 01:03:56.069 --> 01:03:56.079 align:start position:0% build to check if it's compiling 01:03:56.079 --> 01:03:57.069 align:start position:0% build to check if it's compiling it 01:03:57.069 --> 01:03:57.079 align:start position:0% it 01:03:57.079 --> 01:04:01.710 align:start position:0% it is<01:03:58.079> um<01:03:58.240> so<01:03:58.559> now<01:03:59.119> to<01:03:59.480> check<01:03:59.880> this<01:04:00.319> I<01:04:00.599> have<01:04:01.039> a<01:04:01.319> test 01:04:01.710 --> 01:04:01.720 align:start position:0% is um so now to check this I have a test 01:04:01.720 --> 01:04:05.750 align:start position:0% is um so now to check this I have a test file<01:04:02.000> in<01:04:02.359> here<01:04:03.359> with<01:04:03.559> mock<01:04:03.960> data<01:04:04.440> from 01:04:05.750 --> 01:04:05.760 align:start position:0% file in here with mock data from 01:04:05.760 --> 01:04:09.150 align:start position:0% file in here with mock data from um<01:04:06.760> from<01:04:06.880> a<01:04:07.039> working<01:04:07.559> system<01:04:08.559> it's<01:04:08.760> commented 01:04:09.150 --> 01:04:09.160 align:start position:0% um from a working system it's commented 01:04:09.160 --> 01:04:11.470 align:start position:0% um from a working system it's commented out<01:04:09.440> just<01:04:09.640> to<01:04:09.839> prevent<01:04:10.160> compiler<01:04:10.960> issues<01:04:11.359> with 01:04:11.470 --> 01:04:11.480 align:start position:0% out just to prevent compiler issues with 01:04:11.480 --> 01:04:12.910 align:start position:0% out just to prevent compiler issues with the<01:04:11.599> initial<01:04:12.200> like<01:04:12.359> structure<01:04:12.680> of<01:04:12.760> the 01:04:12.910 --> 01:04:12.920 align:start position:0% the initial like structure of the 01:04:12.920 --> 01:04:14.670 align:start position:0% the initial like structure of the project<01:04:13.200> so<01:04:13.319> we<01:04:13.400> can<01:04:13.520> uncomment 01:04:14.670 --> 01:04:14.680 align:start position:0% project so we can uncomment 01:04:14.680 --> 01:04:18.269 align:start position:0% project so we can uncomment this<01:04:15.680> and<01:04:16.160> run<01:04:16.599> a<01:04:16.760> Forge<01:04:17.319> test<01:04:17.799> to<01:04:17.920> make<01:04:18.079> sure 01:04:18.269 --> 01:04:18.279 align:start position:0% this and run a Forge test to make sure 01:04:18.279 --> 01:04:21.910 align:start position:0% this and run a Forge test to make sure that<01:04:18.440> we<01:04:18.760> did<01:04:18.960> Implement<01:04:19.359> that 01:04:21.910 --> 01:04:21.920 align:start position:0% 01:04:21.920 --> 01:04:24.589 align:start position:0% properly<01:04:22.920> it'll<01:04:23.160> recompile<01:04:24.000> recompile<01:04:24.480> this 01:04:24.589 --> 01:04:24.599 align:start position:0% properly it'll recompile recompile this 01:04:24.599 --> 01:04:26.510 align:start position:0% properly it'll recompile recompile this test<01:04:24.839> file<01:04:25.160> and<01:04:25.279> then<01:04:25.559> okay<01:04:25.760> okay<01:04:25.880> cool<01:04:26.119> it's 01:04:26.510 --> 01:04:26.520 align:start position:0% test file and then okay okay cool it's 01:04:26.520 --> 01:04:30.150 align:start position:0% test file and then okay okay cool it's passing<01:04:27.520> so<01:04:27.880> this<01:04:28.000> is<01:04:28.279> using<01:04:29.279> a<01:04:29.640> previously 01:04:30.150 --> 01:04:30.160 align:start position:0% passing so this is using a previously 01:04:30.160 --> 01:04:34.109 align:start position:0% passing so this is using a previously generated<01:04:31.039> proof<01:04:32.200> um<01:04:33.200> that<01:04:33.400> adheres<01:04:33.839> to<01:04:34.000> the 01:04:34.109 --> 01:04:34.119 align:start position:0% generated proof um that adheres to the 01:04:34.119 --> 01:04:35.910 align:start position:0% generated proof um that adheres to the structure<01:04:34.480> that<01:04:34.559> we<01:04:34.680> just<01:04:34.799> set<01:04:34.960> up<01:04:35.119> in<01:04:35.279> that<01:04:35.480> R 01:04:35.910 --> 01:04:35.920 align:start position:0% structure that we just set up in that R 01:04:35.920 --> 01:04:40.390 align:start position:0% structure that we just set up in that R 7755<01:04:36.880> proof<01:04:37.559> struct<01:04:38.559> and<01:04:39.279> um<01:04:39.559> it<01:04:39.760> uses<01:04:40.279> is 01:04:40.390 --> 01:04:40.400 align:start position:0% 7755 proof struct and um it uses is 01:04:40.400 --> 01:04:43.710 align:start position:0% 7755 proof struct and um it uses is being<01:04:40.640> proven<01:04:41.240> against<01:04:41.760> a<01:04:42.200> specific<01:04:43.200> storage 01:04:43.710 --> 01:04:43.720 align:start position:0% being proven against a specific storage 01:04:43.720 --> 01:04:45.750 align:start position:0% being proven against a specific storage route<01:04:44.039> or<01:04:44.359> a<01:04:44.480> specific<01:04:44.839> state<01:04:45.079> route<01:04:45.520> that<01:04:45.640> is 01:04:45.750 --> 01:04:45.760 align:start position:0% route or a specific state route that is 01:04:45.760 --> 01:04:47.269 align:start position:0% route or a specific state route that is being<01:04:45.960> assigned<01:04:46.400> here<01:04:46.599> in<01:04:46.839> this<01:04:47.039> commit 01:04:47.269 --> 01:04:47.279 align:start position:0% being assigned here in this commit 01:04:47.279 --> 01:04:48.630 align:start position:0% being assigned here in this commit Beacon<01:04:47.559> root<01:04:47.839> function<01:04:48.160> in<01:04:48.279> the<01:04:48.359> beacon 01:04:48.630 --> 01:04:48.640 align:start position:0% Beacon root function in the beacon 01:04:48.640 --> 01:04:51.549 align:start position:0% Beacon root function in the beacon Oracle<01:04:49.200> contract<01:04:50.200> um<01:04:50.520> so<01:04:50.960> because<01:04:51.240> this<01:04:51.319> is 01:04:51.549 --> 01:04:51.559 align:start position:0% Oracle contract um so because this is 01:04:51.559 --> 01:04:53.470 align:start position:0% Oracle contract um so because this is passing<01:04:52.319> it's<01:04:52.440> a<01:04:52.640> it's<01:04:52.720> a<01:04:52.839> good<01:04:53.039> sign<01:04:53.240> that<01:04:53.359> our 01:04:53.470 --> 01:04:53.480 align:start position:0% passing it's a it's a good sign that our 01:04:53.480 --> 01:04:58.789 align:start position:0% passing it's a it's a good sign that our implementation<01:04:54.079> is<01:04:54.200> working<01:04:54.559> properly 01:04:58.789 --> 01:04:58.799 align:start position:0% 01:04:58.799 --> 01:05:01.630 align:start position:0% so<01:04:59.359> that<01:04:59.640> wraps<01:05:00.079> up<01:05:00.440> the<01:05:00.920> onchain 01:05:01.630 --> 01:05:01.640 align:start position:0% so that wraps up the onchain 01:05:01.640 --> 01:05:05.630 align:start position:0% so that wraps up the onchain implementation<01:05:02.440> piece<01:05:03.799> um<01:05:04.799> at<01:05:05.000> this<01:05:05.200> point<01:05:05.520> we 01:05:05.630 --> 01:05:05.640 align:start position:0% implementation piece um at this point we 01:05:05.640 --> 01:05:08.789 align:start position:0% implementation piece um at this point we should<01:05:05.920> be<01:05:06.279> good<01:05:06.839> to<01:05:07.760> take<01:05:07.960> a<01:05:08.160> step<01:05:08.400> into<01:05:08.599> the 01:05:08.789 --> 01:05:08.799 align:start position:0% should be good to take a step into the 01:05:08.799 --> 01:05:11.269 align:start position:0% should be good to take a step into the offchain<01:05:09.400> world<01:05:10.200> um<01:05:10.440> and<01:05:10.640> look<01:05:10.920> at<01:05:11.119> the 01:05:11.269 --> 01:05:11.279 align:start position:0% offchain world um and look at the 01:05:11.279 --> 01:05:15.470 align:start position:0% offchain world um and look at the integration<01:05:12.119> for<01:05:13.039> this<01:05:13.200> nft<01:05:13.640> minting<01:05:14.480> um 01:05:15.470 --> 01:05:15.480 align:start position:0% integration for this nft minting um 01:05:15.480 --> 01:05:17.910 align:start position:0% integration for this nft minting um site<01:05:16.480> so<01:05:16.760> I'll<01:05:17.000> close<01:05:17.319> the<01:05:17.440> contracts 01:05:17.910 --> 01:05:17.920 align:start position:0% site so I'll close the contracts 01:05:17.920 --> 01:05:19.829 align:start position:0% site so I'll close the contracts directory<01:05:18.279> for<01:05:18.480> now<01:05:18.760> although<01:05:19.039> we'll<01:05:19.200> be<01:05:19.480> back 01:05:19.829 --> 01:05:19.839 align:start position:0% directory for now although we'll be back 01:05:19.839 --> 01:05:23.470 align:start position:0% directory for now although we'll be back here<01:05:20.039> shortly<01:05:20.559> to<01:05:21.240> reference<01:05:22.240> um<01:05:22.599> different 01:05:23.470 --> 01:05:23.480 align:start position:0% here shortly to reference um different 01:05:23.480 --> 01:05:25.910 align:start position:0% here shortly to reference um different function<01:05:24.279> signatures<01:05:25.279> inside<01:05:25.760> of<01:05:25.839> the 01:05:25.910 --> 01:05:25.920 align:start position:0% function signatures inside of the 01:05:25.920 --> 01:05:28.630 align:start position:0% function signatures inside of the services<01:05:26.359> directory<01:05:27.279> uh<01:05:27.440> we<01:05:27.640> care<01:05:27.880> about<01:05:28.160> this 01:05:28.630 --> 01:05:28.640 align:start position:0% services directory uh we care about this 01:05:28.640 --> 01:05:30.870 align:start position:0% services directory uh we care about this demo<01:05:29.119> directory<01:05:29.960> so<01:05:30.119> if<01:05:30.200> we<01:05:30.319> take<01:05:30.440> a<01:05:30.559> look<01:05:30.680> in 01:05:30.870 --> 01:05:30.880 align:start position:0% demo directory so if we take a look in 01:05:30.880 --> 01:05:33.309 align:start position:0% demo directory so if we take a look in here<01:05:31.520> a<01:05:31.680> brief<01:05:31.960> walk<01:05:32.240> through<01:05:32.640> it's<01:05:32.920> literally 01:05:33.309 --> 01:05:33.319 align:start position:0% here a brief walk through it's literally 01:05:33.319 --> 01:05:35.510 align:start position:0% here a brief walk through it's literally just<01:05:33.559> like<01:05:33.760> a<01:05:33.880> backend<01:05:34.520> like<01:05:34.720> server<01:05:35.119> script 01:05:35.510 --> 01:05:35.520 align:start position:0% just like a backend like server script 01:05:35.520 --> 01:05:36.950 align:start position:0% just like a backend like server script to<01:05:35.720> run<01:05:36.039> it's<01:05:36.200> going<01:05:36.279> to<01:05:36.400> just<01:05:36.520> tell<01:05:36.720> you<01:05:36.839> what 01:05:36.950 --> 01:05:36.960 align:start position:0% to run it's going to just tell you what 01:05:36.960 --> 01:05:41.069 align:start position:0% to run it's going to just tell you what it's<01:05:37.359> doing<01:05:38.359> um<01:05:38.760> if<01:05:38.960> you<01:05:39.640> yeah<01:05:39.760> it'll<01:05:40.079> it'll 01:05:41.069 --> 01:05:41.079 align:start position:0% it's doing um if you yeah it'll it'll 01:05:41.079 --> 01:05:43.870 align:start position:0% it's doing um if you yeah it'll it'll display<01:05:41.680> your<01:05:41.799> current<01:05:42.039> nft<01:05:42.480> balance<01:05:42.880> for<01:05:43.200> the 01:05:43.870 --> 01:05:43.880 align:start position:0% display your current nft balance for the 01:05:43.880 --> 01:05:45.710 align:start position:0% display your current nft balance for the um<01:05:44.440> for<01:05:44.599> the<01:05:44.720> nft<01:05:45.079> contract<01:05:45.400> that's<01:05:45.520> going<01:05:45.640> to 01:05:45.710 --> 01:05:45.720 align:start position:0% um for the nft contract that's going to 01:05:45.720 --> 01:05:47.589 align:start position:0% um for the nft contract that's going to get<01:05:45.839> deployed<01:05:46.240> we're<01:05:46.400> we're<01:05:46.559> calling<01:05:46.839> it 01:05:47.589 --> 01:05:47.599 align:start position:0% get deployed we're we're calling it 01:05:47.599 --> 01:05:49.870 align:start position:0% get deployed we're we're calling it deployed<01:05:48.079> on<01:05:48.279> a<01:05:48.440> mock<01:05:48.720> arbitrum<01:05:49.200> chain<01:05:49.720> and 01:05:49.870 --> 01:05:49.880 align:start position:0% deployed on a mock arbitrum chain and 01:05:49.880 --> 01:05:51.549 align:start position:0% deployed on a mock arbitrum chain and then<01:05:50.200> the<01:05:50.359> user<01:05:50.760> is<01:05:50.880> going<01:05:50.960> to<01:05:51.039> be<01:05:51.160> minting<01:05:51.440> it 01:05:51.549 --> 01:05:51.559 align:start position:0% then the user is going to be minting it 01:05:51.559 --> 01:05:53.990 align:start position:0% then the user is going to be minting it from<01:05:51.799> moach<01:05:52.200> base<01:05:53.200> and<01:05:53.359> so<01:05:53.640> it'll<01:05:53.839> be 01:05:53.990 --> 01:05:54.000 align:start position:0% from moach base and so it'll be 01:05:54.000 --> 01:05:55.630 align:start position:0% from moach base and so it'll be displaying<01:05:54.400> your<01:05:54.520> nft<01:05:54.920> balance<01:05:55.160> on<01:05:55.279> mock 01:05:55.630 --> 01:05:55.640 align:start position:0% displaying your nft balance on mock 01:05:55.640 --> 01:05:57.630 align:start position:0% displaying your nft balance on mock arbitrum<01:05:56.279> your<01:05:56.440> current<01:05:56.760> eth<01:05:57.039> balance<01:05:57.440> on 01:05:57.630 --> 01:05:57.640 align:start position:0% arbitrum your current eth balance on 01:05:57.640 --> 01:06:01.069 align:start position:0% arbitrum your current eth balance on Mach<01:05:57.960> base<01:05:58.799> what<01:05:58.920> the<01:05:59.079> price<01:05:59.480> is<01:05:59.760> of<01:05:59.880> the<01:06:00.079> nft 01:06:01.069 --> 01:06:01.079 align:start position:0% Mach base what the price is of the nft 01:06:01.079 --> 01:06:03.829 align:start position:0% Mach base what the price is of the nft um<01:06:01.359> which<01:06:01.799> I<01:06:02.000> think<01:06:02.319> I<01:06:02.520> have<01:06:02.720> hardcoded<01:06:03.279> as<01:06:03.599> one 01:06:03.829 --> 01:06:03.839 align:start position:0% um which I think I have hardcoded as one 01:06:03.839 --> 01:06:06.990 align:start position:0% um which I think I have hardcoded as one e<01:06:04.279> in<01:06:04.520> the<01:06:04.680> deployment<01:06:05.400> script<01:06:06.400> this<01:06:06.520> is<01:06:06.720> using 01:06:06.990 --> 01:06:07.000 align:start position:0% e in the deployment script this is using 01:06:07.000 --> 01:06:10.150 align:start position:0% e in the deployment script this is using local<01:06:07.279> Anvil<01:06:07.599> nodes<01:06:07.960> so<01:06:08.839> using<01:06:09.480> um<01:06:09.880> easy 01:06:10.150 --> 01:06:10.160 align:start position:0% local Anvil nodes so using um easy 01:06:10.160 --> 01:06:11.870 align:start position:0% local Anvil nodes so using um easy numbers<01:06:10.520> is<01:06:10.920> pretty 01:06:11.870 --> 01:06:11.880 align:start position:0% numbers is pretty 01:06:11.880 --> 01:06:15.710 align:start position:0% numbers is pretty easy<01:06:12.880> uh<01:06:13.039> and<01:06:13.160> then<01:06:13.480> lastly<01:06:14.000> it'll<01:06:15.000> prompt<01:06:15.359> you 01:06:15.710 --> 01:06:15.720 align:start position:0% easy uh and then lastly it'll prompt you 01:06:15.720 --> 01:06:17.309 align:start position:0% easy uh and then lastly it'll prompt you for<01:06:16.119> like<01:06:16.240> once<01:06:16.400> you<01:06:16.520> hit<01:06:16.680> enter<01:06:17.039> it'll 01:06:17.309 --> 01:06:17.319 align:start position:0% for like once you hit enter it'll 01:06:17.319 --> 01:06:19.789 align:start position:0% for like once you hit enter it'll trigger<01:06:18.039> minting<01:06:18.480> the<01:06:18.640> nft<01:06:19.279> and<01:06:19.359> then<01:06:19.440> we<01:06:19.599> can 01:06:19.789 --> 01:06:19.799 align:start position:0% trigger minting the nft and then we can 01:06:19.799 --> 01:06:21.630 align:start position:0% trigger minting the nft and then we can watch<01:06:20.039> the<01:06:20.160> fulfiller<01:06:20.720> in<01:06:20.880> action<01:06:21.200> generating 01:06:21.630 --> 01:06:21.640 align:start position:0% watch the fulfiller in action generating 01:06:21.640 --> 01:06:24.829 align:start position:0% watch the fulfiller in action generating its<01:06:21.839> proof<01:06:22.279> after<01:06:22.480> the<01:06:22.680> fact<01:06:23.680> um<01:06:23.880> which<01:06:24.079> gets 01:06:24.829 --> 01:06:24.839 align:start position:0% its proof after the fact um which gets 01:06:24.839 --> 01:06:26.589 align:start position:0% its proof after the fact um which gets uh<01:06:24.960> verified<01:06:25.400> again<01:06:25.720> that<01:06:25.839> Pro<01:06:26.160> contract<01:06:26.480> we 01:06:26.589 --> 01:06:26.599 align:start position:0% uh verified again that Pro contract we 01:06:26.599 --> 01:06:28.870 align:start position:0% uh verified again that Pro contract we just<01:06:26.680> set<01:06:26.880> up<01:06:27.520> so<01:06:28.160> there's<01:06:28.319> not<01:06:28.480> too<01:06:28.599> much<01:06:28.760> for 01:06:28.870 --> 01:06:28.880 align:start position:0% just set up so there's not too much for 01:06:28.880 --> 01:06:30.710 align:start position:0% just set up so there's not too much for us<01:06:28.960> to<01:06:29.079> change<01:06:29.440> here<01:06:29.680> this<01:06:29.799> is<01:06:30.000> just<01:06:30.520> I<01:06:30.599> just 01:06:30.710 --> 01:06:30.720 align:start position:0% us to change here this is just I just 01:06:30.720 --> 01:06:33.109 align:start position:0% us to change here this is just I just wanted<01:06:30.960> to<01:06:31.480> give<01:06:31.599> you<01:06:31.720> a<01:06:31.839> rundown<01:06:32.359> of<01:06:32.839> uh<01:06:32.960> what 01:06:33.109 --> 01:06:33.119 align:start position:0% wanted to give you a rundown of uh what 01:06:33.119 --> 01:06:35.870 align:start position:0% wanted to give you a rundown of uh what exactly<01:06:33.680> it<01:06:33.839> is<01:06:34.039> that's<01:06:34.520> happening<01:06:35.520> what<01:06:35.680> we 01:06:35.870 --> 01:06:35.880 align:start position:0% exactly it is that's happening what we 01:06:35.880 --> 01:06:37.910 align:start position:0% exactly it is that's happening what we care<01:06:36.119> about<01:06:36.520> is<01:06:36.720> inside<01:06:36.960> of<01:06:37.079> the<01:06:37.200> SRC 01:06:37.910 --> 01:06:37.920 align:start position:0% care about is inside of the SRC 01:06:37.920 --> 01:06:40.349 align:start position:0% care about is inside of the SRC directory<01:06:38.920> there's<01:06:39.079> a<01:06:39.319> client<01:06:39.720> file<01:06:40.119> called 01:06:40.349 --> 01:06:40.359 align:start position:0% directory there's a client file called 01:06:40.359 --> 01:06:42.829 align:start position:0% directory there's a client file called clients.<01:06:41.200> service<01:06:42.200> um<01:06:42.359> this<01:06:42.440> is<01:06:42.520> all<01:06:42.680> in 01:06:42.829 --> 01:06:42.839 align:start position:0% clients. service um this is all in 01:06:42.839 --> 01:06:46.269 align:start position:0% clients. service um this is all in typescript<01:06:43.680> if<01:06:44.359> anyone's<01:06:45.039> familiar<01:06:46.039> there's 01:06:46.269 --> 01:06:46.279 align:start position:0% typescript if anyone's familiar there's 01:06:46.279 --> 01:06:50.029 align:start position:0% typescript if anyone's familiar there's a<01:06:46.480> function<01:06:46.839> called<01:06:47.039> RP<01:06:47.480> 7755<01:06:48.720> mint<01:06:49.720> that<01:06:49.839> is 01:06:50.029 --> 01:06:50.039 align:start position:0% a function called RP 7755 mint that is 01:06:50.039 --> 01:06:52.470 align:start position:0% a function called RP 7755 mint that is completely<01:06:50.359> empty<01:06:50.839> so<01:06:51.079> this<01:06:51.240> is<01:06:51.559> what<01:06:51.920> the<01:06:52.359> uh 01:06:52.470 --> 01:06:52.480 align:start position:0% completely empty so this is what the uh 01:06:52.480 --> 01:06:54.589 align:start position:0% completely empty so this is what the uh developer<01:06:52.920> needs<01:06:53.279> here<01:06:53.960> we<01:06:54.079> have<01:06:54.160> to<01:06:54.279> set<01:06:54.440> this 01:06:54.589 --> 01:06:54.599 align:start position:0% developer needs here we have to set this 01:06:54.599 --> 01:06:58.150 align:start position:0% developer needs here we have to set this up<01:06:54.720> to<01:06:54.880> be<01:06:55.079> an<01:06:55.240> RP<01:06:55.599> P<01:06:55.720> 7755<01:06:56.720> request<01:06:57.720> um<01:06:57.880> to<01:06:58.039> be 01:06:58.150 --> 01:06:58.160 align:start position:0% up to be an RP P 7755 request um to be 01:06:58.160 --> 01:06:59.710 align:start position:0% up to be an RP P 7755 request um to be able<01:06:58.400> to<01:06:58.680> integrate<01:06:59.079> with<01:06:59.160> the<01:06:59.279> cross<01:06:59.480> chain 01:06:59.710 --> 01:06:59.720 align:start position:0% able to integrate with the cross chain 01:06:59.720 --> 01:07:02.910 align:start position:0% able to integrate with the cross chain call<01:07:00.240> and<01:07:01.000> um<01:07:02.000> close<01:07:02.319> the<01:07:02.440> loop<01:07:02.680> for<01:07:02.799> this 01:07:02.910 --> 01:07:02.920 align:start position:0% call and um close the loop for this 01:07:02.920 --> 01:07:05.430 align:start position:0% call and um close the loop for this minting<01:07:03.319> process<01:07:04.319> so<01:07:04.480> we<01:07:04.559> can<01:07:04.720> start<01:07:05.039> here<01:07:05.279> by 01:07:05.430 --> 01:07:05.440 align:start position:0% minting process so we can start here by 01:07:05.440 --> 01:07:07.069 align:start position:0% minting process so we can start here by setting<01:07:05.760> up<01:07:05.960> what<01:07:06.119> this<01:07:06.279> request<01:07:06.559> is<01:07:06.680> going<01:07:06.839> to 01:07:07.069 --> 01:07:07.079 align:start position:0% setting up what this request is going to 01:07:07.079 --> 01:07:12.349 align:start position:0% setting up what this request is going to look<01:07:07.720> like<01:07:08.760> um<01:07:09.760> to<01:07:09.960> do<01:07:10.400> that<01:07:11.400> it<01:07:11.559> would<01:07:11.760> help<01:07:12.039> to 01:07:12.349 --> 01:07:12.359 align:start position:0% look like um to do that it would help to 01:07:12.359 --> 01:07:15.630 align:start position:0% look like um to do that it would help to have<01:07:12.839> the<01:07:13.039> Str<01:07:13.680> file<01:07:14.000> up<01:07:14.200> here<01:07:14.400> as<01:07:14.480> a 01:07:15.630 --> 01:07:15.640 align:start position:0% have the Str file up here as a 01:07:15.640 --> 01:07:18.430 align:start position:0% have the Str file up here as a reference<01:07:16.640> um<01:07:17.200> so<01:07:17.359> I'll<01:07:17.520> open<01:07:17.760> that 01:07:18.430 --> 01:07:18.440 align:start position:0% reference um so I'll open that 01:07:18.440 --> 01:07:21.109 align:start position:0% reference um so I'll open that up<01:07:19.440> because<01:07:20.039> actually<01:07:20.319> before<01:07:20.520> we<01:07:20.680> dive<01:07:20.880> into 01:07:21.109 --> 01:07:21.119 align:start position:0% up because actually before we dive into 01:07:21.119 --> 01:07:22.829 align:start position:0% up because actually before we dive into that<01:07:21.480> as<01:07:21.559> a<01:07:21.680> refresher<01:07:22.119> in<01:07:22.240> the<01:07:22.319> outbox 01:07:22.829 --> 01:07:22.839 align:start position:0% that as a refresher in the outbox 01:07:22.839 --> 01:07:24.910 align:start position:0% that as a refresher in the outbox contract<01:07:23.720> the<01:07:23.839> function<01:07:24.160> that<01:07:24.240> we<01:07:24.400> care<01:07:24.599> about 01:07:24.910 --> 01:07:24.920 align:start position:0% contract the function that we care about 01:07:24.920 --> 01:07:26.789 align:start position:0% contract the function that we care about as<01:07:25.039> the<01:07:25.160> entry<01:07:25.559> point<01:07:25.799> is<01:07:25.960> this<01:07:26.119> request<01:07:26.520> cross 01:07:26.789 --> 01:07:26.799 align:start position:0% as the entry point is this request cross 01:07:26.799 --> 01:07:28.950 align:start position:0% as the entry point is this request cross chain<01:07:27.079> call<01:07:27.839> which<01:07:28.039> accepts<01:07:28.400> one<01:07:28.599> input 01:07:28.950 --> 01:07:28.960 align:start position:0% chain call which accepts one input 01:07:28.960 --> 01:07:31.069 align:start position:0% chain call which accepts one input argument<01:07:29.359> and<01:07:29.520> it's<01:07:29.640> a<01:07:29.760> cross<01:07:30.000> chain<01:07:30.240> request 01:07:31.069 --> 01:07:31.079 align:start position:0% argument and it's a cross chain request 01:07:31.079 --> 01:07:32.549 align:start position:0% argument and it's a cross chain request so<01:07:31.400> really<01:07:31.599> what<01:07:31.680> we<01:07:31.799> need<01:07:31.920> to<01:07:32.000> build<01:07:32.279> here<01:07:32.440> is 01:07:32.549 --> 01:07:32.559 align:start position:0% so really what we need to build here is 01:07:32.559 --> 01:07:33.870 align:start position:0% so really what we need to build here is a<01:07:32.680> cross<01:07:32.880> chain<01:07:33.079> request<01:07:33.559> with<01:07:33.680> all<01:07:33.760> the 01:07:33.870 --> 01:07:33.880 align:start position:0% a cross chain request with all the 01:07:33.880 --> 01:07:36.349 align:start position:0% a cross chain request with all the correct<01:07:34.400> Fields<01:07:35.400> um<01:07:35.599> so<01:07:35.760> that's<01:07:35.960> what<01:07:36.160> I<01:07:36.279> I 01:07:36.349 --> 01:07:36.359 align:start position:0% correct Fields um so that's what I I 01:07:36.359 --> 01:07:38.829 align:start position:0% correct Fields um so that's what I I want<01:07:36.480> to<01:07:36.599> show<01:07:36.760> you 01:07:38.829 --> 01:07:38.839 align:start position:0% want to show you 01:07:38.839 --> 01:07:41.829 align:start position:0% want to show you guys<01:07:39.839> so<01:07:40.039> to<01:07:40.279> start<01:07:40.720> with<01:07:41.680> this 01:07:41.829 --> 01:07:41.839 align:start position:0% guys so to start with this 01:07:41.839 --> 01:07:45.349 align:start position:0% guys so to start with this implementation<01:07:42.799> we<01:07:42.960> can<01:07:43.520> get<01:07:43.680> a<01:07:44.200> um<01:07:45.200> an 01:07:45.349 --> 01:07:45.359 align:start position:0% implementation we can get a um an 01:07:45.359 --> 01:07:47.029 align:start position:0% implementation we can get a um an outline<01:07:45.920> of<01:07:46.079> what<01:07:46.200> this<01:07:46.359> request<01:07:46.640> is<01:07:46.760> going<01:07:46.920> to 01:07:47.029 --> 01:07:47.039 align:start position:0% outline of what this request is going to 01:07:47.039 --> 01:07:48.950 align:start position:0% outline of what this request is going to look<01:07:47.240> like<01:07:47.440> as<01:07:47.559> well<01:07:47.720> as<01:07:48.000> the<01:07:48.200> the<01:07:48.319> lowle<01:07:48.760> call 01:07:48.950 --> 01:07:48.960 align:start position:0% look like as well as the the lowle call 01:07:48.960 --> 01:07:51.150 align:start position:0% look like as well as the the lowle call that<01:07:49.039> we<01:07:49.160> need<01:07:49.279> it<01:07:49.400> to<01:07:49.559> do<01:07:49.799> to<01:07:50.000> facilitate<01:07:51.000> so 01:07:51.150 --> 01:07:51.160 align:start position:0% that we need it to do to facilitate so 01:07:51.160 --> 01:07:54.510 align:start position:0% that we need it to do to facilitate so we<01:07:51.240> can<01:07:51.440> start<01:07:51.760> with<01:07:52.200> uh<01:07:52.760> const<01:07:53.760> calls<01:07:54.400> it's 01:07:54.510 --> 01:07:54.520 align:start position:0% we can start with uh const calls it's 01:07:54.520 --> 01:07:57.109 align:start position:0% we can start with uh const calls it's going<01:07:54.599> to<01:07:54.720> be<01:07:54.920> a<01:07:55.119> it's<01:07:55.240> a<01:07:55.559> batch<01:07:55.960> but<01:07:56.079> it's<01:07:56.960> it's 01:07:57.109 --> 01:07:57.119 align:start position:0% going to be a it's a batch but it's it's 01:07:57.119 --> 01:07:58.390 align:start position:0% going to be a it's a batch but it's it's just<01:07:57.279> one<01:07:57.480> call<01:07:57.680> but<01:07:57.760> it<01:07:57.839> still<01:07:58.000> needs<01:07:58.200> to<01:07:58.279> be 01:07:58.390 --> 01:07:58.400 align:start position:0% just one call but it still needs to be 01:07:58.400 --> 01:08:00.789 align:start position:0% just one call but it still needs to be set<01:07:58.559> up<01:07:58.720> as<01:07:58.799> an<01:07:58.920> array<01:07:59.400> because<01:07:59.599> it's<01:08:00.079> uh<01:08:00.520> uh 01:08:00.789 --> 01:08:00.799 align:start position:0% set up as an array because it's uh uh 01:08:00.799 --> 01:08:02.390 align:start position:0% set up as an array because it's uh uh meant<01:08:00.960> to<01:08:01.119> be<01:08:01.240> able<01:08:01.359> to<01:08:01.480> support<01:08:01.760> a<01:08:01.880> batch<01:08:02.079> of 01:08:02.390 --> 01:08:02.400 align:start position:0% meant to be able to support a batch of 01:08:02.400 --> 01:08:06.750 align:start position:0% meant to be able to support a batch of calls<01:08:03.400> and<01:08:03.599> then<01:08:03.720> we'll<01:08:03.960> have<01:08:04.119> a<01:08:04.279> const 01:08:06.750 --> 01:08:06.760 align:start position:0% 01:08:06.760 --> 01:08:09.910 align:start position:0% request<01:08:07.760> which<01:08:07.880> will<01:08:08.039> be<01:08:08.200> an<01:08:08.319> empty<01:08:08.839> object<01:08:09.839> we 01:08:09.910 --> 01:08:09.920 align:start position:0% request which will be an empty object we 01:08:09.920 --> 01:08:11.230 align:start position:0% request which will be an empty object we can<01:08:10.079> start<01:08:10.319> by<01:08:10.440> just<01:08:10.599> getting<01:08:10.839> the<01:08:10.920> field 01:08:11.230 --> 01:08:11.240 align:start position:0% can start by just getting the field 01:08:11.240 --> 01:08:13.630 align:start position:0% can start by just getting the field names<01:08:11.520> in<01:08:11.760> here<01:08:12.480> um<01:08:12.720> I'm<01:08:12.880> just<01:08:13.000> going<01:08:13.119> to 01:08:13.630 --> 01:08:13.640 align:start position:0% names in here um I'm just going to 01:08:13.640 --> 01:08:16.110 align:start position:0% names in here um I'm just going to assign<01:08:13.960> them<01:08:14.119> all<01:08:14.400> as<01:08:14.720> empty<01:08:15.079> values<01:08:15.480> to<01:08:15.720> start 01:08:16.110 --> 01:08:16.120 align:start position:0% assign them all as empty values to start 01:08:16.120 --> 01:08:18.349 align:start position:0% assign them all as empty values to start just<01:08:16.239> to<01:08:16.640> motor<01:08:17.040> through<01:08:17.319> this<01:08:18.000> and<01:08:18.120> then<01:08:18.239> we 01:08:18.349 --> 01:08:18.359 align:start position:0% just to motor through this and then we 01:08:18.359 --> 01:08:20.349 align:start position:0% just to motor through this and then we can<01:08:18.960> uh<01:08:19.159> go<01:08:19.279> through<01:08:19.520> each<01:08:19.679> one<01:08:19.839> individually 01:08:20.349 --> 01:08:20.359 align:start position:0% can uh go through each one individually 01:08:20.359 --> 01:08:22.149 align:start position:0% can uh go through each one individually to<01:08:20.480> make<01:08:20.600> sure<01:08:20.839> that<01:08:21.000> we're<01:08:21.560> setting<01:08:21.839> it<01:08:21.960> up 01:08:22.149 --> 01:08:22.159 align:start position:0% to make sure that we're setting it up 01:08:22.159 --> 01:08:24.829 align:start position:0% to make sure that we're setting it up properly<01:08:22.799> and<01:08:23.239> um<01:08:23.400> explain<01:08:23.759> it<01:08:23.920> all<01:08:24.120> as<01:08:24.239> we<01:08:24.440> go 01:08:24.829 --> 01:08:24.839 align:start position:0% properly and um explain it all as we go 01:08:24.839 --> 01:08:27.070 align:start position:0% properly and um explain it all as we go so<01:08:25.520> we<01:08:25.640> need<01:08:25.759> to<01:08:25.880> add<01:08:26.040> Prov<01:08:26.440> contracts<01:08:26.960> and 01:08:27.070 --> 01:08:27.080 align:start position:0% so we need to add Prov contracts and 01:08:27.080 --> 01:08:28.669 align:start position:0% so we need to add Prov contracts and again<01:08:27.239> I'm<01:08:27.359> just<01:08:27.759> copying<01:08:28.159> everything<01:08:28.400> to<01:08:28.520> try 01:08:28.669 --> 01:08:28.679 align:start position:0% again I'm just copying everything to try 01:08:28.679 --> 01:08:31.709 align:start position:0% again I'm just copying everything to try to<01:08:28.799> prevent<01:08:29.159> some<01:08:29.640> silly<01:08:30.199> typo 01:08:31.709 --> 01:08:31.719 align:start position:0% to prevent some silly typo 01:08:31.719 --> 01:08:34.870 align:start position:0% to prevent some silly typo mistake<01:08:32.719> um<01:08:33.159> so<01:08:33.520> just<01:08:33.679> bear<01:08:33.920> with<01:08:34.040> me<01:08:34.159> for<01:08:34.279> a 01:08:34.870 --> 01:08:34.880 align:start position:0% mistake um so just bear with me for a 01:08:34.880 --> 01:08:38.669 align:start position:0% mistake um so just bear with me for a second<01:08:35.880> pass<01:08:36.040> in<01:08:36.199> the<01:08:36.319> inbox 01:08:38.669 --> 01:08:38.679 align:start position:0% second pass in the inbox 01:08:38.679 --> 01:08:43.269 align:start position:0% second pass in the inbox contract<01:08:39.679> L2 01:08:43.269 --> 01:08:43.279 align:start position:0% 01:08:43.279 --> 01:08:47.030 align:start position:0% Oracle<01:08:44.279> L2<01:08:44.679> Oracle<01:08:45.000> storage 01:08:47.030 --> 01:08:47.040 align:start position:0% Oracle L2 Oracle storage 01:08:47.040 --> 01:08:50.269 align:start position:0% Oracle L2 Oracle storage key<01:08:48.040> reward 01:08:50.269 --> 01:08:50.279 align:start position:0% key reward 01:08:50.279 --> 01:08:53.430 align:start position:0% key reward asset<01:08:51.279> reward<01:08:51.640> amount<01:08:52.120> we<01:08:52.719> initialize<01:08:53.199> as 01:08:53.430 --> 01:08:53.440 align:start position:0% asset reward amount we initialize as 01:08:53.440 --> 01:08:56.269 align:start position:0% asset reward amount we initialize as zero<01:08:54.000> finality<01:08:54.440> delay<01:08:54.799> seconds 01:08:56.269 --> 01:08:56.279 align:start position:0% zero finality delay seconds 01:08:56.279 --> 01:08:58.910 align:start position:0% zero finality delay seconds initialize<01:08:56.759> a<01:08:57.400> zero<01:08:58.400> we'll<01:08:58.560> come<01:08:58.759> back 01:08:58.910 --> 01:08:58.920 align:start position:0% initialize a zero we'll come back 01:08:58.920 --> 01:09:00.189 align:start position:0% initialize a zero we'll come back through<01:08:59.080> this<01:08:59.199> in<01:08:59.319> a 01:09:00.189 --> 01:09:00.199 align:start position:0% through this in a 01:09:00.199 --> 01:09:04.149 align:start position:0% through this in a second<01:09:01.199> nons<01:09:01.799> is 01:09:04.149 --> 01:09:04.159 align:start position:0% 01:09:04.159 --> 01:09:07.950 align:start position:0% zero<01:09:05.159> xir<01:09:06.000> zero<01:09:06.440> and<01:09:06.560> then<01:09:06.679> the<01:09:06.759> final<01:09:07.040> two 01:09:07.950 --> 01:09:07.960 align:start position:0% zero xir zero and then the final two 01:09:07.960 --> 01:09:10.550 align:start position:0% zero xir zero and then the final two pre-check<01:09:08.960> related<01:09:09.400> fields<01:09:10.120> PreCheck 01:09:10.550 --> 01:09:10.560 align:start position:0% pre-check related fields PreCheck 01:09:10.560 --> 01:09:12.950 align:start position:0% pre-check related fields PreCheck contract<01:09:10.920> and<01:09:11.040> pre-check 01:09:12.950 --> 01:09:12.960 align:start position:0% contract and pre-check 01:09:12.960 --> 01:09:15.789 align:start position:0% contract and pre-check data<01:09:13.960> and<01:09:14.080> then<01:09:14.279> for<01:09:14.600> the<01:09:14.759> individual<01:09:15.279> call 01:09:15.789 --> 01:09:15.799 align:start position:0% data and then for the individual call 01:09:15.799 --> 01:09:17.510 align:start position:0% data and then for the individual call that<01:09:15.920> we<01:09:16.040> want<01:09:16.120> to<01:09:16.279> set<01:09:16.440> up<01:09:16.679> here<01:09:17.120> uh<01:09:17.239> this<01:09:17.400> just 01:09:17.510 --> 01:09:17.520 align:start position:0% that we want to set up here uh this just 01:09:17.520 --> 01:09:19.390 align:start position:0% that we want to set up here uh this just takes<01:09:17.719> in<01:09:17.920> three<01:09:18.120> parameters<01:09:18.640> there's<01:09:18.880> two 01:09:19.390 --> 01:09:19.400 align:start position:0% takes in three parameters there's two 01:09:19.400 --> 01:09:23.229 align:start position:0% takes in three parameters there's two data<01:09:19.719> and<01:09:19.960> value<01:09:20.560> so<01:09:20.759> we<01:09:20.839> can<01:09:21.000> take 01:09:23.229 --> 01:09:23.239 align:start position:0% data and value so we can take 01:09:23.239 --> 01:09:27.349 align:start position:0% data and value so we can take two<01:09:24.239> empty<01:09:24.560> string 01:09:27.349 --> 01:09:27.359 align:start position:0% two empty string 01:09:27.359 --> 01:09:33.229 align:start position:0% two empty string data<01:09:28.359> and<01:09:28.520> then 01:09:33.229 --> 01:09:33.239 align:start position:0% 01:09:33.239 --> 01:09:35.669 align:start position:0% value<01:09:34.239> okay<01:09:34.359> so<01:09:34.520> we<01:09:34.640> have<01:09:34.799> our<01:09:35.279> structure 01:09:35.669 --> 01:09:35.679 align:start position:0% value okay so we have our structure 01:09:35.679 --> 01:09:37.709 align:start position:0% value okay so we have our structure outlined<01:09:36.199> here<01:09:36.600> now<01:09:36.839> we<01:09:36.960> need<01:09:37.120> to<01:09:37.400> make<01:09:37.560> sure 01:09:37.709 --> 01:09:37.719 align:start position:0% outlined here now we need to make sure 01:09:37.719 --> 01:09:39.829 align:start position:0% outlined here now we need to make sure we<01:09:37.880> set<01:09:38.040> up<01:09:38.239> each<01:09:38.400> of<01:09:38.520> these<01:09:38.719> fields<01:09:39.520> um 01:09:39.829 --> 01:09:39.839 align:start position:0% we set up each of these fields um 01:09:39.839 --> 01:09:41.269 align:start position:0% we set up each of these fields um properly<01:09:40.359> and<01:09:40.480> it<01:09:40.560> helps<01:09:40.759> to<01:09:40.880> have<01:09:40.960> an 01:09:41.269 --> 01:09:41.279 align:start position:0% properly and it helps to have an 01:09:41.279 --> 01:09:42.669 align:start position:0% properly and it helps to have an understanding<01:09:41.560> of<01:09:41.759> exactly<01:09:42.080> what<01:09:42.199> each<01:09:42.359> field 01:09:42.669 --> 01:09:42.679 align:start position:0% understanding of exactly what each field 01:09:42.679 --> 01:09:46.709 align:start position:0% understanding of exactly what each field is<01:09:43.440> which<01:09:43.600> we<01:09:43.759> now<01:09:44.000> all<01:09:44.640> should<01:09:45.640> um<01:09:46.400> in<01:09:46.520> order 01:09:46.709 --> 01:09:46.719 align:start position:0% is which we now all should um in order 01:09:46.719 --> 01:09:49.430 align:start position:0% is which we now all should um in order to<01:09:46.880> help<01:09:47.159> with<01:09:47.359> this<01:09:48.000> I<01:09:48.319> have<01:09:48.719> inside<01:09:49.000> of<01:09:49.159> this 01:09:49.430 --> 01:09:49.440 align:start position:0% to help with this I have inside of this 01:09:49.440 --> 01:09:51.309 align:start position:0% to help with this I have inside of this common<01:09:49.880> directory<01:09:50.400> there's<01:09:50.560> a<01:09:50.759> constants 01:09:51.309 --> 01:09:51.319 align:start position:0% common directory there's a constants 01:09:51.319 --> 01:09:54.189 align:start position:0% common directory there's a constants file<01:09:52.040> that<01:09:52.239> has<01:09:52.400> a<01:09:52.520> couple<01:09:52.759> of<01:09:53.199> um<01:09:53.920> chain 01:09:54.189 --> 01:09:54.199 align:start position:0% file that has a couple of um chain 01:09:54.199 --> 01:09:56.830 align:start position:0% file that has a couple of um chain configs<01:09:54.600> in<01:09:54.760> here<01:09:54.920> one<01:09:55.080> for<01:09:55.520> Mock<01:09:55.840> arbitrum 01:09:56.830 --> 01:09:56.840 align:start position:0% configs in here one for Mock arbitrum 01:09:56.840 --> 01:09:59.430 align:start position:0% configs in here one for Mock arbitrum and<01:09:57.040> one<01:09:57.199> for<01:09:57.600> Mach<01:09:57.920> base<01:09:58.880> so<01:09:59.159> this<01:09:59.239> is<01:09:59.360> going 01:09:59.430 --> 01:09:59.440 align:start position:0% and one for Mach base so this is going 01:09:59.440 --> 01:10:02.189 align:start position:0% and one for Mach base so this is going to<01:09:59.560> be<01:09:59.760> very<01:10:00.280> um<01:10:00.440> helpful<01:10:01.000> for<01:10:01.800> where<01:10:01.960> we<01:10:02.040> can 01:10:02.189 --> 01:10:02.199 align:start position:0% to be very um helpful for where we can 01:10:02.199 --> 01:10:04.830 align:start position:0% to be very um helpful for where we can pull<01:10:02.400> the<01:10:02.520> addresses<01:10:03.360> from<01:10:04.360> assuming 01:10:04.830 --> 01:10:04.840 align:start position:0% pull the addresses from assuming 01:10:04.840 --> 01:10:07.070 align:start position:0% pull the addresses from assuming everyone<01:10:05.679> deploys<01:10:06.199> the<01:10:06.320> contracts<01:10:06.760> using<01:10:07.000> the 01:10:07.070 --> 01:10:07.080 align:start position:0% everyone deploys the contracts using the 01:10:07.080 --> 01:10:09.310 align:start position:0% everyone deploys the contracts using the deployment<01:10:07.480> scripts<01:10:07.760> that<01:10:07.840> are<01:10:08.159> provided<01:10:09.159> uh 01:10:09.310 --> 01:10:09.320 align:start position:0% deployment scripts that are provided uh 01:10:09.320 --> 01:10:11.110 align:start position:0% deployment scripts that are provided uh these<01:10:09.520> addresses<01:10:09.960> are<01:10:10.520> I<01:10:10.560> mean<01:10:10.840> they're 01:10:11.110 --> 01:10:11.120 align:start position:0% these addresses are I mean they're 01:10:11.120 --> 01:10:12.950 align:start position:0% these addresses are I mean they're they're<01:10:11.360> deterministic<01:10:12.000> so<01:10:12.640> they're<01:10:12.880> if 01:10:12.950 --> 01:10:12.960 align:start position:0% they're deterministic so they're if 01:10:12.960 --> 01:10:14.310 align:start position:0% they're deterministic so they're if they're<01:10:13.199> deployed<01:10:13.520> in<01:10:13.600> the<01:10:13.719> right<01:10:13.840> order<01:10:14.159> then 01:10:14.310 --> 01:10:14.320 align:start position:0% they're deployed in the right order then 01:10:14.320 --> 01:10:16.510 align:start position:0% they're deployed in the right order then these<01:10:14.480> addresses<01:10:14.920> should<01:10:15.120> all<01:10:15.239> be<01:10:15.400> correct<01:10:16.400> um 01:10:16.510 --> 01:10:16.520 align:start position:0% these addresses should all be correct um 01:10:16.520 --> 01:10:17.990 align:start position:0% these addresses should all be correct um which<01:10:16.600> is<01:10:16.719> why<01:10:16.840> they're<01:10:17.040> pre-populated<01:10:17.840> in 01:10:17.990 --> 01:10:18.000 align:start position:0% which is why they're pre-populated in 01:10:18.000 --> 01:10:19.709 align:start position:0% which is why they're pre-populated in this<01:10:18.199> in<01:10:18.280> this<01:10:18.480> file<01:10:19.159> uh<01:10:19.280> even<01:10:19.520> though<01:10:19.640> the 01:10:19.709 --> 01:10:19.719 align:start position:0% this in this file uh even though the 01:10:19.719 --> 01:10:20.990 align:start position:0% this in this file uh even though the contracts<01:10:20.040> are<01:10:20.159> not<01:10:20.239> currently<01:10:20.560> deployed<01:10:20.920> on 01:10:20.990 --> 01:10:21.000 align:start position:0% contracts are not currently deployed on 01:10:21.000 --> 01:10:22.510 align:start position:0% contracts are not currently deployed on our<01:10:21.120> local 01:10:22.510 --> 01:10:22.520 align:start position:0% our local 01:10:22.520 --> 01:10:25.110 align:start position:0% our local network<01:10:23.520> so<01:10:23.960> okay<01:10:24.480> um<01:10:24.600> let's<01:10:24.719> start<01:10:24.880> filling 01:10:25.110 --> 01:10:25.120 align:start position:0% network so okay um let's start filling 01:10:25.120 --> 01:10:28.189 align:start position:0% network so okay um let's start filling these<01:10:25.440> out<01:10:26.080> for<01:10:26.480> calls<01:10:27.320> the<01:10:27.520> destination 01:10:28.189 --> 01:10:28.199 align:start position:0% these out for calls the destination 01:10:28.199 --> 01:10:30.550 align:start position:0% these out for calls the destination address<01:10:28.640> here<01:10:29.199> uh<01:10:29.440> again<01:10:29.880> what<01:10:30.040> exactly<01:10:30.360> is<01:10:30.440> it 01:10:30.550 --> 01:10:30.560 align:start position:0% address here uh again what exactly is it 01:10:30.560 --> 01:10:32.390 align:start position:0% address here uh again what exactly is it that<01:10:30.640> we're<01:10:30.760> trying<01:10:30.960> to<01:10:31.120> do<01:10:32.000> uh<01:10:32.080> we<01:10:32.159> want<01:10:32.280> to 01:10:32.390 --> 01:10:32.400 align:start position:0% that we're trying to do uh we want to 01:10:32.400 --> 01:10:34.310 align:start position:0% that we're trying to do uh we want to Mint<01:10:32.640> an<01:10:32.760> nft<01:10:33.280> so<01:10:33.440> the<01:10:33.560> two<01:10:33.800> address<01:10:34.120> is<01:10:34.239> going 01:10:34.310 --> 01:10:34.320 align:start position:0% Mint an nft so the two address is going 01:10:34.320 --> 01:10:36.750 align:start position:0% Mint an nft so the two address is going to<01:10:34.440> be<01:10:34.840> the<01:10:35.000> nft<01:10:35.560> address<01:10:36.040> which<01:10:36.199> we<01:10:36.360> have<01:10:36.560> up 01:10:36.750 --> 01:10:36.760 align:start position:0% to be the nft address which we have up 01:10:36.760 --> 01:10:39.830 align:start position:0% to be the nft address which we have up here<01:10:37.000> as<01:10:37.199> mock<01:10:37.480> arbitrum<01:10:38.000> nft<01:10:38.520> address<01:10:39.520> so<01:10:39.719> at 01:10:39.830 --> 01:10:39.840 align:start position:0% here as mock arbitrum nft address so at 01:10:39.840 --> 01:10:41.470 align:start position:0% here as mock arbitrum nft address so at the<01:10:40.000> top<01:10:40.120> of<01:10:40.239> this<01:10:40.400> client<01:10:40.679> service<01:10:41.040> file<01:10:41.360> we 01:10:41.470 --> 01:10:41.480 align:start position:0% the top of this client service file we 01:10:41.480 --> 01:10:45.390 align:start position:0% the top of this client service file we can<01:10:41.640> import<01:10:42.120> that<01:10:42.600> so<01:10:42.800> this<01:10:42.920> will<01:10:43.480> be 01:10:45.390 --> 01:10:45.400 align:start position:0% can import that so this will be 01:10:45.400 --> 01:10:49.110 align:start position:0% can import that so this will be import<01:10:46.400> mock<01:10:46.920> arbitrum<01:10:47.560> nft<01:10:48.080> address<01:10:48.520> from<01:10:48.880> do 01:10:49.110 --> 01:10:49.120 align:start position:0% import mock arbitrum nft address from do 01:10:49.120 --> 01:10:51.510 align:start position:0% import mock arbitrum nft address from do do<01:10:49.760> commmon 01:10:51.510 --> 01:10:51.520 align:start position:0% do commmon 01:10:51.520 --> 01:10:55.790 align:start position:0% do commmon constants<01:10:52.520> and<01:10:52.600> then<01:10:52.719> we<01:10:52.800> can<01:10:52.960> copy<01:10:53.280> that 01:10:55.790 --> 01:10:55.800 align:start position:0% constants and then we can copy that 01:10:55.800 --> 01:10:58.030 align:start position:0% constants and then we can copy that into<01:10:56.120> our<01:10:56.320> two 01:10:58.030 --> 01:10:58.040 align:start position:0% into our two 01:10:58.040 --> 01:11:00.270 align:start position:0% into our two field<01:10:59.040> data<01:10:59.360> is<01:10:59.480> going<01:10:59.560> to<01:10:59.679> be<01:10:59.800> the<01:10:59.880> encoded 01:11:00.270 --> 01:11:00.280 align:start position:0% field data is going to be the encoded 01:11:00.280 --> 01:11:01.709 align:start position:0% field data is going to be the encoded call<01:11:00.520> data<01:11:00.719> for<01:11:00.800> the<01:11:00.880> mint<01:11:01.159> function<01:11:01.640> I'm 01:11:01.709 --> 01:11:01.719 align:start position:0% call data for the mint function I'm 01:11:01.719 --> 01:11:03.030 align:start position:0% call data for the mint function I'm going<01:11:01.840> to<01:11:01.960> leave<01:11:02.159> that<01:11:02.320> for<01:11:02.480> the<01:11:02.640> last<01:11:02.840> step 01:11:03.030 --> 01:11:03.040 align:start position:0% going to leave that for the last step 01:11:03.040 --> 01:11:05.030 align:start position:0% going to leave that for the last step we'll<01:11:03.199> come<01:11:03.360> back<01:11:03.480> to<01:11:03.600> that<01:11:03.719> in<01:11:03.800> a<01:11:04.040> second 01:11:05.030 --> 01:11:05.040 align:start position:0% we'll come back to that in a second 01:11:05.040 --> 01:11:07.310 align:start position:0% we'll come back to that in a second value<01:11:05.679> um<01:11:05.840> as<01:11:05.960> you<01:11:06.080> see<01:11:06.360> here<01:11:06.679> this<01:11:07.000> function 01:11:07.310 --> 01:11:07.320 align:start position:0% value um as you see here this function 01:11:07.320 --> 01:11:09.550 align:start position:0% value um as you see here this function is<01:11:07.440> being<01:11:07.679> called<01:11:08.040> with<01:11:08.159> an<01:11:08.400> address<01:11:09.120> this<01:11:09.280> is 01:11:09.550 --> 01:11:09.560 align:start position:0% is being called with an address this is 01:11:09.560 --> 01:11:11.070 align:start position:0% is being called with an address this is going<01:11:09.760> to<01:11:09.920> be<01:11:10.120> the<01:11:10.199> user<01:11:10.520> address<01:11:10.920> receiving 01:11:11.070 --> 01:11:11.080 align:start position:0% going to be the user address receiving 01:11:11.080 --> 01:11:13.470 align:start position:0% going to be the user address receiving the<01:11:11.239> nft<01:11:12.239> and<01:11:12.320> then<01:11:12.480> the<01:11:12.560> mint<01:11:12.880> price<01:11:13.239> which<01:11:13.360> is 01:11:13.470 --> 01:11:13.480 align:start position:0% the nft and then the mint price which is 01:11:13.480 --> 01:11:15.510 align:start position:0% the nft and then the mint price which is the<01:11:13.600> mint<01:11:13.840> price<01:11:14.040> of<01:11:14.120> the<01:11:14.199> nft<01:11:14.760> denominated<01:11:15.320> in 01:11:15.510 --> 01:11:15.520 align:start position:0% the mint price of the nft denominated in 01:11:15.520 --> 01:11:17.310 align:start position:0% the mint price of the nft denominated in way<01:11:15.960> so<01:11:16.120> we<01:11:16.199> can<01:11:16.360> just<01:11:16.560> pass<01:11:16.719> in<01:11:16.880> this<01:11:17.040> mint 01:11:17.310 --> 01:11:17.320 align:start position:0% way so we can just pass in this mint 01:11:17.320 --> 01:11:18.910 align:start position:0% way so we can just pass in this mint price<01:11:17.560> as<01:11:17.679> the<01:11:17.840> value 01:11:18.910 --> 01:11:18.920 align:start position:0% price as the value 01:11:18.920 --> 01:11:22.669 align:start position:0% price as the value directly<01:11:20.280> um<01:11:21.280> yeah<01:11:21.400> so<01:11:21.560> this<01:11:21.640> will<01:11:21.760> be<01:11:21.880> mint 01:11:22.669 --> 01:11:22.679 align:start position:0% directly um yeah so this will be mint 01:11:22.679 --> 01:11:24.910 align:start position:0% directly um yeah so this will be mint price<01:11:23.679> and<01:11:23.760> then<01:11:23.960> now<01:11:24.239> as<01:11:24.320> we<01:11:24.440> start<01:11:24.600> to<01:11:24.760> fill 01:11:24.910 --> 01:11:24.920 align:start position:0% price and then now as we start to fill 01:11:24.920 --> 01:11:27.630 align:start position:0% price and then now as we start to fill out<01:11:25.000> the<01:11:25.320> request<01:11:25.880> the<01:11:26.080> requester<01:11:27.080> is<01:11:27.280> pretty 01:11:27.630 --> 01:11:27.640 align:start position:0% out the request the requester is pretty 01:11:27.640 --> 01:11:29.470 align:start position:0% out the request the requester is pretty self-explanatory<01:11:28.640> like<01:11:28.760> I<01:11:28.840> said<01:11:29.000> the<01:11:29.159> address 01:11:29.470 --> 01:11:29.480 align:start position:0% self-explanatory like I said the address 01:11:29.480 --> 01:11:31.630 align:start position:0% self-explanatory like I said the address of<01:11:29.719> the<01:11:30.280> of<01:11:30.440> the<01:11:30.640> requester<01:11:31.080> is<01:11:31.159> being<01:11:31.360> passed 01:11:31.630 --> 01:11:31.640 align:start position:0% of the of the requester is being passed 01:11:31.640 --> 01:11:33.470 align:start position:0% of the of the requester is being passed in<01:11:32.360> so<01:11:32.520> we<01:11:32.600> can<01:11:32.719> use 01:11:33.470 --> 01:11:33.480 align:start position:0% in so we can use 01:11:33.480 --> 01:11:38.070 align:start position:0% in so we can use that<01:11:34.520> calls<01:11:35.520> is<01:11:35.840> going<01:11:35.960> to<01:11:36.080> be<01:11:36.280> this<01:11:36.440> calls 01:11:38.070 --> 01:11:38.080 align:start position:0% that calls is going to be this calls 01:11:38.080 --> 01:11:40.790 align:start position:0% that calls is going to be this calls array<01:11:39.080> prover<01:11:39.560> contract<01:11:40.159> is<01:11:40.400> what<01:11:40.520> we<01:11:40.679> just 01:11:40.790 --> 01:11:40.800 align:start position:0% array prover contract is what we just 01:11:40.800 --> 01:11:42.390 align:start position:0% array prover contract is what we just implemented<01:11:41.400> this<01:11:41.520> will<01:11:41.639> be<01:11:41.840> the<01:11:42.040> ad<01:11:42.320> the 01:11:42.390 --> 01:11:42.400 align:start position:0% implemented this will be the ad the 01:11:42.400 --> 01:11:44.390 align:start position:0% implemented this will be the ad the contract<01:11:42.840> address<01:11:43.199> on<01:11:43.320> the<01:11:43.480> source<01:11:43.840> chain 01:11:44.390 --> 01:11:44.400 align:start position:0% contract address on the source chain 01:11:44.400 --> 01:11:47.189 align:start position:0% contract address on the source chain which<01:11:44.520> in<01:11:44.639> this<01:11:44.800> context<01:11:45.199> is<01:11:45.440> is<01:11:45.560> mock<01:11:46.000> base<01:11:47.000> um 01:11:47.189 --> 01:11:47.199 align:start position:0% which in this context is is mock base um 01:11:47.199 --> 01:11:48.750 align:start position:0% which in this context is is mock base um of<01:11:47.360> the<01:11:47.480> prover<01:11:47.920> contract<01:11:48.360> that<01:11:48.480> has<01:11:48.600> been 01:11:48.750 --> 01:11:48.760 align:start position:0% of the prover contract that has been 01:11:48.760 --> 01:11:50.510 align:start position:0% of the prover contract that has been implemented<01:11:49.360> specifically<01:11:49.880> to<01:11:50.080> validate 01:11:50.510 --> 01:11:50.520 align:start position:0% implemented specifically to validate 01:11:50.520 --> 01:11:52.709 align:start position:0% implemented specifically to validate requests<01:11:51.400> or<01:11:51.639> validate<01:11:52.040> State<01:11:52.360> about<01:11:52.600> the 01:11:52.709 --> 01:11:52.719 align:start position:0% requests or validate State about the 01:11:52.719 --> 01:11:54.629 align:start position:0% requests or validate State about the mock<01:11:53.440> about<01:11:53.600> the<01:11:53.719> destination<01:11:54.159> chain<01:11:54.520> which 01:11:54.629 --> 01:11:54.639 align:start position:0% mock about the destination chain which 01:11:54.639 --> 01:11:57.590 align:start position:0% mock about the destination chain which in<01:11:54.760> this<01:11:54.880> context<01:11:55.520> is<01:11:55.840> mock<01:11:56.360> arbitrum<01:11:57.360> so<01:11:57.520> if 01:11:57.590 --> 01:11:57.600 align:start position:0% in this context is mock arbitrum so if 01:11:57.600 --> 01:12:00.070 align:start position:0% in this context is mock arbitrum so if we<01:11:57.760> look<01:11:57.960> over<01:11:58.320> here<01:11:59.320> um<01:11:59.480> there's<01:11:59.679> only<01:11:59.840> one 01:12:00.070 --> 01:12:00.080 align:start position:0% we look over here um there's only one 01:12:00.080 --> 01:12:01.750 align:start position:0% we look over here um there's only one defined<01:12:00.360> in<01:12:00.520> each<01:12:00.800> but<01:12:00.920> this<01:12:01.040> is<01:12:01.199> set<01:12:01.360> up<01:12:01.520> in<01:12:01.600> a 01:12:01.750 --> 01:12:01.760 align:start position:0% defined in each but this is set up in a 01:12:01.760 --> 01:12:03.310 align:start position:0% defined in each but this is set up in a way<01:12:01.960> that<01:12:02.040> we<01:12:02.159> could<01:12:02.360> Define<01:12:02.600> multiple<01:12:02.960> Prov 01:12:03.310 --> 01:12:03.320 align:start position:0% way that we could Define multiple Prov 01:12:03.320 --> 01:12:06.430 align:start position:0% way that we could Define multiple Prov contracts<01:12:03.760> for<01:12:03.920> each<01:12:04.520> chain<01:12:05.520> um<01:12:05.960> but<01:12:06.199> this<01:12:06.280> is 01:12:06.430 --> 01:12:06.440 align:start position:0% contracts for each chain um but this is 01:12:06.440 --> 01:12:07.830 align:start position:0% contracts for each chain um but this is pretty<01:12:06.639> straightforward<01:12:07.199> so<01:12:07.360> we'll<01:12:07.560> start 01:12:07.830 --> 01:12:07.840 align:start position:0% pretty straightforward so we'll start 01:12:07.840 --> 01:12:08.870 align:start position:0% pretty straightforward so we'll start with 01:12:08.870 --> 01:12:08.880 align:start position:0% with 01:12:08.880 --> 01:12:10.910 align:start position:0% with um<01:12:09.880> well<01:12:10.080> first<01:12:10.239> we<01:12:10.360> have<01:12:10.440> to<01:12:10.560> import<01:12:10.840> the 01:12:10.910 --> 01:12:10.920 align:start position:0% um well first we have to import the 01:12:10.920 --> 01:12:12.669 align:start position:0% um well first we have to import the chain<01:12:11.199> configs<01:12:11.760> here<01:12:11.960> so<01:12:12.120> if<01:12:12.239> we<01:12:12.320> go<01:12:12.440> back<01:12:12.560> up 01:12:12.669 --> 01:12:12.679 align:start position:0% chain configs here so if we go back up 01:12:12.679 --> 01:12:14.709 align:start position:0% chain configs here so if we go back up to<01:12:12.800> the<01:12:12.880> top<01:12:13.040> of<01:12:13.120> the<01:12:13.239> file<01:12:14.080> we<01:12:14.159> can<01:12:14.360> import 01:12:14.709 --> 01:12:14.719 align:start position:0% to the top of the file we can import 01:12:14.719 --> 01:12:15.910 align:start position:0% to the top of the file we can import that<01:12:14.880> from<01:12:15.040> the<01:12:15.120> same<01:12:15.320> file<01:12:15.560> that<01:12:15.639> we<01:12:15.760> just 01:12:15.910 --> 01:12:15.920 align:start position:0% that from the same file that we just 01:12:15.920 --> 01:12:20.430 align:start position:0% that from the same file that we just imported<01:12:16.320> the<01:12:16.440> nft 01:12:20.430 --> 01:12:20.440 align:start position:0% 01:12:20.440 --> 01:12:22.910 align:start position:0% address<01:12:21.440> and<01:12:21.560> then<01:12:21.719> down<01:12:22.000> here<01:12:22.239> in<01:12:22.360> our<01:12:22.520> mint 01:12:22.910 --> 01:12:22.920 align:start position:0% address and then down here in our mint 01:12:22.920 --> 01:12:25.790 align:start position:0% address and then down here in our mint function<01:12:23.760> we<01:12:23.920> can<01:12:24.199> destructure<01:12:25.400> the<01:12:25.520> mock 01:12:25.790 --> 01:12:25.800 align:start position:0% function we can destructure the mock 01:12:25.800 --> 01:12:29.470 align:start position:0% function we can destructure the mock arbitrum<01:12:26.360> and<01:12:26.520> mock<01:12:26.800> base<01:12:27.320> configs<01:12:28.320> from<01:12:28.920> uh 01:12:29.470 --> 01:12:29.480 align:start position:0% arbitrum and mock base configs from uh 01:12:29.480 --> 01:12:31.149 align:start position:0% arbitrum and mock base configs from uh that<01:12:29.639> outer<01:12:30.000> object<01:12:30.280> that's<01:12:30.480> containing<01:12:30.920> the 01:12:31.149 --> 01:12:31.159 align:start position:0% that outer object that's containing the 01:12:31.159 --> 01:12:33.350 align:start position:0% that outer object that's containing the the<01:12:31.280> chain<01:12:31.719> configs<01:12:32.719> so<01:12:32.880> this<01:12:32.960> would<01:12:33.159> look 01:12:33.350 --> 01:12:33.360 align:start position:0% the chain configs so this would look 01:12:33.360 --> 01:12:36.629 align:start position:0% the chain configs so this would look like<01:12:33.840> const<01:12:34.840> Curly<01:12:35.199> braces<01:12:35.760> with<01:12:35.960> Mock 01:12:36.629 --> 01:12:36.639 align:start position:0% like const Curly braces with Mock 01:12:36.639 --> 01:12:42.350 align:start position:0% like const Curly braces with Mock arbitrum<01:12:37.440> and<01:12:37.679> mock<01:12:38.480> base<01:12:39.480> is<01:12:39.679> equal<01:12:39.960> to<01:12:40.480> chain 01:12:42.350 --> 01:12:42.360 align:start position:0% arbitrum and mock base is equal to chain 01:12:42.360 --> 01:12:44.629 align:start position:0% arbitrum and mock base is equal to chain configs<01:12:43.360> and<01:12:43.440> then<01:12:43.600> now<01:12:43.719> we<01:12:43.840> can<01:12:44.040> access<01:12:44.480> all 01:12:44.629 --> 01:12:44.639 align:start position:0% configs and then now we can access all 01:12:44.639 --> 01:12:47.390 align:start position:0% configs and then now we can access all of<01:12:44.960> these<01:12:45.639> config<01:12:46.040> Fields<01:12:46.480> directly<01:12:47.000> on<01:12:47.159> Mock 01:12:47.390 --> 01:12:47.400 align:start position:0% of these config Fields directly on Mock 01:12:47.400 --> 01:12:49.750 align:start position:0% of these config Fields directly on Mock arbitr<01:12:47.760> and<01:12:47.880> mock<01:12:48.120> base<01:12:48.960> so<01:12:49.159> for<01:12:49.320> the<01:12:49.440> pro 01:12:49.750 --> 01:12:49.760 align:start position:0% arbitr and mock base so for the pro 01:12:49.760 --> 01:12:52.550 align:start position:0% arbitr and mock base so for the pro contract<01:12:50.239> because<01:12:50.600> this<01:12:50.719> is<01:12:51.080> the<01:12:51.360> base<01:12:52.040> side 01:12:52.550 --> 01:12:52.560 align:start position:0% contract because this is the base side 01:12:52.560 --> 01:12:54.750 align:start position:0% contract because this is the base side of<01:12:53.159> of<01:12:53.360> the<01:12:53.520> equation<01:12:53.920> here<01:12:54.400> this<01:12:54.520> will<01:12:54.639> be 01:12:54.750 --> 01:12:54.760 align:start position:0% of of the equation here this will be 01:12:54.760 --> 01:12:58.310 align:start position:0% of of the equation here this will be mock<01:12:54.960> BAS 01:12:58.310 --> 01:12:58.320 align:start position:0% 01:12:58.320 --> 01:13:00.270 align:start position:0% doover 01:13:00.270 --> 01:13:00.280 align:start position:0% doover 01:13:00.280 --> 01:13:03.310 align:start position:0% doover contracts 01:13:03.310 --> 01:13:03.320 align:start position:0% 01:13:03.320 --> 01:13:05.750 align:start position:0% prover<01:13:04.320> the<01:13:04.480> destination<01:13:04.960> chain<01:13:05.199> ID<01:13:05.520> is<01:13:05.639> going 01:13:05.750 --> 01:13:05.760 align:start position:0% prover the destination chain ID is going 01:13:05.760 --> 01:13:07.550 align:start position:0% prover the destination chain ID is going to<01:13:05.840> be<01:13:05.960> mock<01:13:06.199> arbitrum<01:13:06.679> chain<01:13:06.880> ID<01:13:07.159> so<01:13:07.280> we<01:13:07.360> can 01:13:07.550 --> 01:13:07.560 align:start position:0% to be mock arbitrum chain ID so we can 01:13:07.560 --> 01:13:11.189 align:start position:0% to be mock arbitrum chain ID so we can go<01:13:07.880> Mach<01:13:08.360> arbitrum<01:13:09.159> dochain 01:13:11.189 --> 01:13:11.199 align:start position:0% go Mach arbitrum dochain 01:13:11.199 --> 01:13:13.950 align:start position:0% go Mach arbitrum dochain ID<01:13:12.199> inbox<01:13:12.679> contract<01:13:13.040> is<01:13:13.159> going<01:13:13.239> to<01:13:13.400> be<01:13:13.719> the 01:13:13.950 --> 01:13:13.960 align:start position:0% ID inbox contract is going to be the 01:13:13.960 --> 01:13:16.990 align:start position:0% ID inbox contract is going to be the address<01:13:14.360> of<01:13:14.520> the<01:13:14.639> RP<01:13:15.080> 7755<01:13:16.000> inbox<01:13:16.400> contract<01:13:16.800> on 01:13:16.990 --> 01:13:17.000 align:start position:0% address of the RP 7755 inbox contract on 01:13:17.000 --> 01:13:19.550 align:start position:0% address of the RP 7755 inbox contract on mock<01:13:17.280> arbitrum<01:13:18.199> so<01:13:18.360> this<01:13:18.440> will<01:13:18.600> be<01:13:19.159> mock 01:13:19.550 --> 01:13:19.560 align:start position:0% mock arbitrum so this will be mock 01:13:19.560 --> 01:13:24.110 align:start position:0% mock arbitrum so this will be mock arbitrum<01:13:20.480> do<01:13:21.040> contracts. 01:13:24.110 --> 01:13:24.120 align:start position:0% 01:13:24.120 --> 01:13:27.189 align:start position:0% inbox<01:13:25.120> L2<01:13:25.400> Oracle<01:13:26.040> is<01:13:26.239> the<01:13:26.400> rollup<01:13:26.840> contract 01:13:27.189 --> 01:13:27.199 align:start position:0% inbox L2 Oracle is the rollup contract 01:13:27.199 --> 01:13:29.590 align:start position:0% inbox L2 Oracle is the rollup contract on<01:13:27.320> L1<01:13:28.080> for<01:13:28.440> mock<01:13:28.719> arbitrum<01:13:29.199> here<01:13:29.360> so<01:13:29.520> this 01:13:29.590 --> 01:13:29.600 align:start position:0% on L1 for mock arbitrum here so this 01:13:29.600 --> 01:13:35.790 align:start position:0% on L1 for mock arbitrum here so this will<01:13:29.760> be<01:13:30.159> moach<01:13:30.520> arbitrum<01:13:31.440> dol2 01:13:35.790 --> 01:13:35.800 align:start position:0% 01:13:35.800 --> 01:13:37.830 align:start position:0% Oracle<01:13:36.800> same<01:13:37.000> thing<01:13:37.120> with<01:13:37.239> the<01:13:37.360> storage<01:13:37.679> key 01:13:37.830 --> 01:13:37.840 align:start position:0% Oracle same thing with the storage key 01:13:37.840 --> 01:13:40.030 align:start position:0% Oracle same thing with the storage key or<01:13:37.920> the<01:13:38.000> L2<01:13:38.280> Oracle<01:13:38.600> storage<01:13:38.920> key<01:13:39.159> this<01:13:39.280> is<01:13:39.639> for 01:13:40.030 --> 01:13:40.040 align:start position:0% or the L2 Oracle storage key this is for 01:13:40.040 --> 01:13:41.950 align:start position:0% or the L2 Oracle storage key this is for the<01:13:40.159> L2<01:13:40.480> Oracle<01:13:40.800> contract<01:13:41.159> for<01:13:41.280> Mark<01:13:41.520> arbitrum 01:13:41.950 --> 01:13:41.960 align:start position:0% the L2 Oracle contract for Mark arbitrum 01:13:41.960 --> 01:13:43.990 align:start position:0% the L2 Oracle contract for Mark arbitrum so<01:13:42.080> we'll<01:13:42.320> grab<01:13:42.560> that<01:13:42.679> from<01:13:42.800> the<01:13:42.960> same<01:13:43.520> place 01:13:43.990 --> 01:13:44.000 align:start position:0% so we'll grab that from the same place 01:13:44.000 --> 01:13:48.590 align:start position:0% so we'll grab that from the same place this<01:13:44.159> be<01:13:44.360> Mach<01:13:44.920> arbitrum<01:13:45.600> L2<01:13:46.000> Oracle<01:13:46.360> storage 01:13:48.590 --> 01:13:48.600 align:start position:0% this be Mach arbitrum L2 Oracle storage 01:13:48.600 --> 01:13:51.229 align:start position:0% this be Mach arbitrum L2 Oracle storage key<01:13:49.600> and<01:13:49.679> then<01:13:49.800> for<01:13:49.880> a<01:13:50.040> reward<01:13:50.440> asset<01:13:50.840> for<01:13:51.040> this 01:13:51.229 --> 01:13:51.239 align:start position:0% key and then for a reward asset for this 01:13:51.239 --> 01:13:52.590 align:start position:0% key and then for a reward asset for this example<01:13:51.560> we're<01:13:51.719> just<01:13:51.840> going<01:13:51.920> to<01:13:52.080> use<01:13:52.280> native 01:13:52.590 --> 01:13:52.600 align:start position:0% example we're just going to use native 01:13:52.600 --> 01:13:55.149 align:start position:0% example we're just going to use native currency<01:13:53.280> because<01:13:53.719> we're<01:13:54.280> um<01:13:54.440> sending<01:13:54.760> native 01:13:55.149 --> 01:13:55.159 align:start position:0% currency because we're um sending native 01:13:55.159 --> 01:13:57.390 align:start position:0% currency because we're um sending native currency<01:13:55.639> for<01:13:55.880> the<01:13:56.000> mint<01:13:56.560> function<01:13:57.159> but<01:13:57.280> it 01:13:57.390 --> 01:13:57.400 align:start position:0% currency for the mint function but it 01:13:57.400 --> 01:13:58.950 align:start position:0% currency for the mint function but it doesn't<01:13:57.719> necessarily<01:13:58.280> have<01:13:58.400> to<01:13:58.480> be<01:13:58.639> one<01:13:58.800> to 01:13:58.950 --> 01:13:58.960 align:start position:0% doesn't necessarily have to be one to 01:13:58.960 --> 01:14:01.030 align:start position:0% doesn't necessarily have to be one to one<01:13:59.159> like<01:13:59.320> that<01:14:00.040> um<01:14:00.159> we<01:14:00.280> could<01:14:00.440> be<01:14:00.600> passing<01:14:00.880> in 01:14:01.030 --> 01:14:01.040 align:start position:0% one like that um we could be passing in 01:14:01.040 --> 01:14:02.790 align:start position:0% one like that um we could be passing in some<01:14:01.280> erc20<01:14:02.080> and<01:14:02.199> then<01:14:02.360> expect<01:14:02.679> the 01:14:02.790 --> 01:14:02.800 align:start position:0% some erc20 and then expect the 01:14:02.800 --> 01:14:04.629 align:start position:0% some erc20 and then expect the fulfillers<01:14:03.400> to<01:14:03.920> do<01:14:04.080> the<01:14:04.239> necessary 01:14:04.629 --> 01:14:04.639 align:start position:0% fulfillers to do the necessary 01:14:04.639 --> 01:14:06.149 align:start position:0% fulfillers to do the necessary conversions<01:14:05.120> offchain<01:14:05.600> to<01:14:05.719> make<01:14:05.840> sure<01:14:06.040> that 01:14:06.149 --> 01:14:06.159 align:start position:0% conversions offchain to make sure that 01:14:06.159 --> 01:14:08.350 align:start position:0% conversions offchain to make sure that the<01:14:06.239> rc20<01:14:07.120> is<01:14:07.280> enough<01:14:07.520> value<01:14:07.800> to<01:14:07.960> account<01:14:08.159> for 01:14:08.350 --> 01:14:08.360 align:start position:0% the rc20 is enough value to account for 01:14:08.360 --> 01:14:09.550 align:start position:0% the rc20 is enough value to account for the<01:14:08.440> native<01:14:08.679> currency<01:14:09.000> that's<01:14:09.159> being<01:14:09.320> passed 01:14:09.550 --> 01:14:09.560 align:start position:0% the native currency that's being passed 01:14:09.560 --> 01:14:11.149 align:start position:0% the native currency that's being passed in<01:14:09.760> here<01:14:10.239> but<01:14:10.360> it's<01:14:10.480> a<01:14:10.560> little<01:14:10.679> bit<01:14:10.800> cleaner 01:14:11.149 --> 01:14:11.159 align:start position:0% in here but it's a little bit cleaner 01:14:11.159 --> 01:14:12.910 align:start position:0% in here but it's a little bit cleaner for<01:14:11.400> the<01:14:11.520> demo<01:14:11.840> here<01:14:12.000> to<01:14:12.159> just<01:14:12.320> keep<01:14:12.480> it<01:14:12.600> one<01:14:12.800> to 01:14:12.910 --> 01:14:12.920 align:start position:0% for the demo here to just keep it one to 01:14:12.920 --> 01:14:16.350 align:start position:0% for the demo here to just keep it one to one<01:14:13.239> like<01:14:13.480> that<01:14:14.440> um<01:14:15.199> so<01:14:15.880> uh<01:14:16.000> that's<01:14:16.120> what<01:14:16.239> we're 01:14:16.350 --> 01:14:16.360 align:start position:0% one like that um so uh that's what we're 01:14:16.360 --> 01:14:18.830 align:start position:0% one like that um so uh that's what we're going<01:14:16.440> to 01:14:18.830 --> 01:14:18.840 align:start position:0% 01:14:18.840 --> 01:14:21.350 align:start position:0% do<01:14:19.840> the<01:14:19.960> ERC<01:14:20.400> that<01:14:20.480> I<01:14:20.560> mentioned<01:14:20.880> earlier<01:14:21.199> that 01:14:21.350 --> 01:14:21.360 align:start position:0% do the ERC that I mentioned earlier that 01:14:21.360 --> 01:14:23.669 align:start position:0% do the ERC that I mentioned earlier that had<01:14:21.520> a<01:14:21.760> spe<01:14:22.120> specific<01:14:23.000> uh<01:14:23.280> asset<01:14:23.560> that 01:14:23.669 --> 01:14:23.679 align:start position:0% had a spe specific uh asset that 01:14:23.679 --> 01:14:25.870 align:start position:0% had a spe specific uh asset that represents<01:14:24.080> native<01:14:24.360> currency<01:14:25.159> is<01:14:25.280> hardcoded 01:14:25.870 --> 01:14:25.880 align:start position:0% represents native currency is hardcoded 01:14:25.880 --> 01:14:28.750 align:start position:0% represents native currency is hardcoded here<01:14:26.120> so<01:14:26.320> that's<01:14:26.480> what<01:14:26.679> this<01:14:27.040> like<01:14:27.760> oxe 01:14:28.750 --> 01:14:28.760 align:start position:0% here so that's what this like oxe 01:14:28.760 --> 01:14:31.950 align:start position:0% here so that's what this like oxe address<01:14:29.239> is<01:14:30.239> and<01:14:30.360> this<01:14:30.440> is<01:14:30.679> another<01:14:31.320> exported 01:14:31.950 --> 01:14:31.960 align:start position:0% address is and this is another exported 01:14:31.960 --> 01:14:34.229 align:start position:0% address is and this is another exported constant<01:14:32.480> from<01:14:33.040> this<01:14:33.199> constants<01:14:33.679> file<01:14:34.000> so<01:14:34.120> we 01:14:34.229 --> 01:14:34.239 align:start position:0% constant from this constants file so we 01:14:34.239 --> 01:14:40.390 align:start position:0% constant from this constants file so we can<01:14:34.480> copy<01:14:34.840> that<01:14:35.440> and<01:14:35.600> add<01:14:35.719> it<01:14:35.840> to<01:14:35.960> the<01:14:36.120> import 01:14:40.390 --> 01:14:40.400 align:start position:0% 01:14:40.400 --> 01:14:42.270 align:start position:0% statement<01:14:41.400> and<01:14:41.520> then<01:14:41.679> pass<01:14:41.880> that<01:14:41.960> in<01:14:42.080> for 01:14:42.270 --> 01:14:42.280 align:start position:0% statement and then pass that in for 01:14:42.280 --> 01:14:44.870 align:start position:0% statement and then pass that in for reward 01:14:44.870 --> 01:14:44.880 align:start position:0% 01:14:44.880 --> 01:14:48.390 align:start position:0% address<01:14:45.880> reward<01:14:46.320> amount<01:14:47.040> again<01:14:47.320> to<01:14:47.880> to<01:14:48.080> remind 01:14:48.390 --> 01:14:48.400 align:start position:0% address reward amount again to to remind 01:14:48.400 --> 01:14:50.149 align:start position:0% address reward amount again to to remind you<01:14:48.639> is<01:14:48.800> meant<01:14:49.040> to<01:14:49.159> cover<01:14:49.480> all<01:14:49.560> of<01:14:49.719> the<01:14:49.840> value 01:14:50.149 --> 01:14:50.159 align:start position:0% you is meant to cover all of the value 01:14:50.159 --> 01:14:52.750 align:start position:0% you is meant to cover all of the value from<01:14:50.320> the<01:14:50.480> calls<01:14:51.400> plus<01:14:51.840> whatever<01:14:52.320> the<01:14:52.639> the 01:14:52.750 --> 01:14:52.760 align:start position:0% from the calls plus whatever the the 01:14:52.760 --> 01:14:55.350 align:start position:0% from the calls plus whatever the the destination<01:14:53.280> chain<01:14:53.639> gas<01:14:53.920> cost<01:14:54.239> is<01:14:54.719> Plus<01:14:55.080> a<01:14:55.199> tip 01:14:55.350 --> 01:14:55.360 align:start position:0% destination chain gas cost is Plus a tip 01:14:55.360 --> 01:14:58.910 align:start position:0% destination chain gas cost is Plus a tip for<01:14:55.520> the<01:14:55.960> fulfiller<01:14:56.960> um<01:14:57.800> the<01:14:58.120> exact<01:14:58.440> mechanism 01:14:58.910 --> 01:14:58.920 align:start position:0% for the fulfiller um the exact mechanism 01:14:58.920 --> 01:15:01.750 align:start position:0% for the fulfiller um the exact mechanism to<01:14:59.080> calculate<01:14:59.600> what<01:14:59.800> that<01:15:00.480> Surplus<01:15:01.159> should<01:15:01.400> be 01:15:01.750 --> 01:15:01.760 align:start position:0% to calculate what that Surplus should be 01:15:01.760 --> 01:15:05.149 align:start position:0% to calculate what that Surplus should be can<01:15:01.960> be<01:15:02.280> pretty<01:15:03.199> complicated<01:15:04.199> um<01:15:04.400> but<01:15:04.600> for<01:15:05.040> the 01:15:05.149 --> 01:15:05.159 align:start position:0% can be pretty complicated um but for the 01:15:05.159 --> 01:15:07.110 align:start position:0% can be pretty complicated um but for the sake<01:15:05.360> of<01:15:05.520> today's<01:15:06.120> demo<01:15:06.560> doing<01:15:06.800> it<01:15:06.920> in<01:15:07.000> a 01:15:07.110 --> 01:15:07.120 align:start position:0% sake of today's demo doing it in a 01:15:07.120 --> 01:15:09.430 align:start position:0% sake of today's demo doing it in a simplified<01:15:07.639> context<01:15:08.080> if<01:15:08.199> we<01:15:08.360> add<01:15:08.600> an<01:15:08.719> extra<01:15:09.000> 2% 01:15:09.430 --> 01:15:09.440 align:start position:0% simplified context if we add an extra 2% 01:15:09.440 --> 01:15:11.550 align:start position:0% simplified context if we add an extra 2% to<01:15:09.560> the<01:15:09.719> request<01:15:10.159> that<01:15:10.239> should<01:15:10.400> be<01:15:11.239> uh<01:15:11.360> more 01:15:11.550 --> 01:15:11.560 align:start position:0% to the request that should be uh more 01:15:11.560 --> 01:15:13.990 align:start position:0% to the request that should be uh more than<01:15:11.760> enough<01:15:12.239> for<01:15:12.560> it<01:15:12.719> to<01:15:12.880> be<01:15:13.480> profitable<01:15:13.880> for 01:15:13.990 --> 01:15:14.000 align:start position:0% than enough for it to be profitable for 01:15:14.000 --> 01:15:16.470 align:start position:0% than enough for it to be profitable for the<01:15:14.120> fulfiller<01:15:14.639> in<01:15:14.760> our<01:15:14.880> local<01:15:15.159> network<01:15:16.159> so 01:15:16.470 --> 01:15:16.480 align:start position:0% the fulfiller in our local network so 01:15:16.480 --> 01:15:19.030 align:start position:0% the fulfiller in our local network so we'll<01:15:16.760> do<01:15:16.920> it<01:15:17.120> that<01:15:17.280> way<01:15:17.520> so<01:15:17.719> this<01:15:17.840> will<01:15:18.000> be<01:15:18.880> uh 01:15:19.030 --> 01:15:19.040 align:start position:0% we'll do it that way so this will be uh 01:15:19.040 --> 01:15:20.830 align:start position:0% we'll do it that way so this will be uh reward<01:15:19.360> amount<01:15:19.719> is<01:15:19.840> going<01:15:20.000> to<01:15:20.120> be<01:15:20.320> the<01:15:20.440> mint 01:15:20.830 --> 01:15:20.840 align:start position:0% reward amount is going to be the mint 01:15:20.840 --> 01:15:22.950 align:start position:0% reward amount is going to be the mint price<01:15:21.159> which<01:15:21.280> is<01:15:21.440> already<01:15:21.760> in<01:15:22.000> way<01:15:22.440> to<01:15:22.600> remind 01:15:22.950 --> 01:15:22.960 align:start position:0% price which is already in way to remind 01:15:22.960 --> 01:15:25.830 align:start position:0% price which is already in way to remind you 01:15:25.830 --> 01:15:25.840 align:start position:0% you 01:15:25.840 --> 01:15:27.790 align:start position:0% you we'll<01:15:26.040> add<01:15:26.199> a<01:15:26.320> 2%<01:15:26.719> buffer<01:15:27.000> so<01:15:27.120> we<01:15:27.199> can<01:15:27.320> do<01:15:27.520> that 01:15:27.790 --> 01:15:27.800 align:start position:0% we'll add a 2% buffer so we can do that 01:15:27.800 --> 01:15:30.470 align:start position:0% we'll add a 2% buffer so we can do that with<01:15:27.960> big<01:15:28.159> ints<01:15:28.480> in<01:15:28.840> in<01:15:29.199> typescript<01:15:30.080> by 01:15:30.470 --> 01:15:30.480 align:start position:0% with big ints in in typescript by 01:15:30.480 --> 01:15:33.189 align:start position:0% with big ints in in typescript by multiplying<01:15:31.000> it<01:15:31.239> by<01:15:31.719> something<01:15:31.960> like<01:15:32.120> 102<01:15:32.960> n 01:15:33.189 --> 01:15:33.199 align:start position:0% multiplying it by something like 102 n 01:15:33.199 --> 01:15:36.030 align:start position:0% multiplying it by something like 102 n for<01:15:33.400> a<01:15:33.520> big<01:15:33.679> int<01:15:34.159> and<01:15:34.280> then<01:15:34.400> dividing<01:15:34.679> it<01:15:34.800> by 01:15:36.030 --> 01:15:36.040 align:start position:0% for a big int and then dividing it by 01:15:36.040 --> 01:15:38.510 align:start position:0% for a big int and then dividing it by 100<01:15:37.040> this<01:15:37.199> results<01:15:37.600> in<01:15:37.719> the<01:15:37.800> mint<01:15:38.040> price 01:15:38.510 --> 01:15:38.520 align:start position:0% 100 this results in the mint price 01:15:38.520 --> 01:15:40.870 align:start position:0% 100 this results in the mint price having<01:15:38.760> 2%<01:15:39.239> added<01:15:39.480> to 01:15:40.870 --> 01:15:40.880 align:start position:0% having 2% added to 01:15:40.880 --> 01:15:43.629 align:start position:0% having 2% added to it<01:15:41.880> all<01:15:42.000> right<01:15:42.199> so<01:15:42.320> then<01:15:42.440> for<01:15:42.600> finality<01:15:43.040> delay 01:15:43.629 --> 01:15:43.639 align:start position:0% it all right so then for finality delay 01:15:43.639 --> 01:15:45.830 align:start position:0% it all right so then for finality delay seconds<01:15:44.639> in<01:15:44.760> a<01:15:44.960> live<01:15:45.159> Network<01:15:45.560> this<01:15:45.679> will 01:15:45.830 --> 01:15:45.840 align:start position:0% seconds in a live Network this will 01:15:45.840 --> 01:15:47.669 align:start position:0% seconds in a live Network this will likely<01:15:46.159> be<01:15:46.320> something<01:15:46.719> on<01:15:46.840> the<01:15:46.960> order<01:15:47.199> of<01:15:47.400> days 01:15:47.669 --> 01:15:47.679 align:start position:0% likely be something on the order of days 01:15:47.679 --> 01:15:50.310 align:start position:0% likely be something on the order of days to<01:15:47.880> a<01:15:48.040> week<01:15:48.560> to<01:15:49.040> ensure<01:15:49.760> uh<01:15:49.920> protection 01:15:50.310 --> 01:15:50.320 align:start position:0% to a week to ensure uh protection 01:15:50.320 --> 01:15:52.910 align:start position:0% to a week to ensure uh protection against<01:15:50.560> reorgs<01:15:51.159> on<01:15:51.280> the<01:15:51.440> destination<01:15:51.920> chain 01:15:52.910 --> 01:15:52.920 align:start position:0% against reorgs on the destination chain 01:15:52.920 --> 01:15:55.030 align:start position:0% against reorgs on the destination chain because<01:15:53.520> this<01:15:53.639> is<01:15:53.760> a<01:15:53.880> self-contained<01:15:54.560> system 01:15:55.030 --> 01:15:55.040 align:start position:0% because this is a self-contained system 01:15:55.040 --> 01:15:56.590 align:start position:0% because this is a self-contained system that<01:15:55.159> is<01:15:55.280> going<01:15:55.440> to<01:15:55.600> run<01:15:55.880> locally<01:15:56.320> on<01:15:56.440> your 01:15:56.590 --> 01:15:56.600 align:start position:0% that is going to run locally on your 01:15:56.600 --> 01:15:58.270 align:start position:0% that is going to run locally on your machine<01:15:57.120> we<01:15:57.239> have<01:15:57.400> the<01:15:57.520> flexibility<01:15:58.080> and<01:15:58.159> the 01:15:58.270 --> 01:15:58.280 align:start position:0% machine we have the flexibility and the 01:15:58.280 --> 01:16:00.390 align:start position:0% machine we have the flexibility and the freedom<01:15:58.600> to<01:15:58.760> make<01:15:58.920> this<01:15:59.120> really<01:15:59.360> short<01:16:00.239> and 01:16:00.390 --> 01:16:00.400 align:start position:0% freedom to make this really short and 01:16:00.400 --> 01:16:01.830 align:start position:0% freedom to make this really short and because<01:16:00.639> I<01:16:00.719> want<01:16:00.880> this<01:16:01.000> to<01:16:01.120> be<01:16:01.239> a<01:16:01.400> responsive 01:16:01.830 --> 01:16:01.840 align:start position:0% because I want this to be a responsive 01:16:01.840 --> 01:16:03.189 align:start position:0% because I want this to be a responsive demo<01:16:02.199> and<01:16:02.280> for<01:16:02.400> us<01:16:02.520> to<01:16:02.639> see<01:16:02.800> everything 01:16:03.189 --> 01:16:03.199 align:start position:0% demo and for us to see everything 01:16:03.199 --> 01:16:05.390 align:start position:0% demo and for us to see everything happening<01:16:04.120> uh<01:16:04.199> in<01:16:04.360> real<01:16:04.600> time<01:16:04.840> we'll<01:16:05.040> make<01:16:05.199> it 01:16:05.390 --> 01:16:05.400 align:start position:0% happening uh in real time we'll make it 01:16:05.400 --> 01:16:07.910 align:start position:0% happening uh in real time we'll make it just<01:16:05.679> 10<01:16:06.120> seconds<01:16:07.120> um<01:16:07.280> so<01:16:07.520> what<01:16:07.639> this<01:16:07.719> is<01:16:07.840> going 01:16:07.910 --> 01:16:07.920 align:start position:0% just 10 seconds um so what this is going 01:16:07.920 --> 01:16:10.030 align:start position:0% just 10 seconds um so what this is going to<01:16:08.040> result<01:16:08.280> in<01:16:08.440> is<01:16:08.560> like<01:16:08.679> a<01:16:08.800> 10<01:16:08.960> to<01:16:09.120> 15c<01:16:09.639> delay 01:16:10.030 --> 01:16:10.040 align:start position:0% to result in is like a 10 to 15c delay 01:16:10.040 --> 01:16:11.950 align:start position:0% to result in is like a 10 to 15c delay after<01:16:10.239> the<01:16:10.360> request<01:16:10.639> is<01:16:10.760> submitted<01:16:11.280> before 01:16:11.950 --> 01:16:11.960 align:start position:0% after the request is submitted before 01:16:11.960 --> 01:16:13.470 align:start position:0% after the request is submitted before we'll<01:16:12.159> see<01:16:12.360> the<01:16:12.520> fulfiller<01:16:13.199> actually 01:16:13.470 --> 01:16:13.480 align:start position:0% we'll see the fulfiller actually 01:16:13.480 --> 01:16:15.910 align:start position:0% we'll see the fulfiller actually generate<01:16:13.800> the<01:16:13.920> proof<01:16:14.159> and<01:16:14.280> claim<01:16:14.560> the 01:16:15.910 --> 01:16:15.920 align:start position:0% generate the proof and claim the 01:16:15.920 --> 01:16:18.030 align:start position:0% generate the proof and claim the reward<01:16:16.920> nons<01:16:17.400> doesn't<01:16:17.639> matter<01:16:17.920> because 01:16:18.030 --> 01:16:18.040 align:start position:0% reward nons doesn't matter because 01:16:18.040 --> 01:16:19.189 align:start position:0% reward nons doesn't matter because that's<01:16:18.199> going<01:16:18.280> to<01:16:18.360> get<01:16:18.480> overwritten<01:16:19.000> in<01:16:19.120> the 01:16:19.189 --> 01:16:19.199 align:start position:0% that's going to get overwritten in the 01:16:19.199 --> 01:16:20.790 align:start position:0% that's going to get overwritten in the outbox<01:16:19.800> contract<01:16:20.239> it's<01:16:20.400> just<01:16:20.520> like<01:16:20.639> a 01:16:20.790 --> 01:16:20.800 align:start position:0% outbox contract it's just like a 01:16:20.800 --> 01:16:23.149 align:start position:0% outbox contract it's just like a canonically<01:16:21.400> incrementing<01:16:21.880> nons<01:16:22.280> for<01:16:22.480> every 01:16:23.149 --> 01:16:23.159 align:start position:0% canonically incrementing nons for every 01:16:23.159 --> 01:16:26.390 align:start position:0% canonically incrementing nons for every request<01:16:24.159> expir<01:16:25.199> doesn't<01:16:25.600> really<01:16:26.000> matter<01:16:26.239> too 01:16:26.390 --> 01:16:26.400 align:start position:0% request expir doesn't really matter too 01:16:26.400 --> 01:16:29.310 align:start position:0% request expir doesn't really matter too much<01:16:26.520> for<01:16:26.679> this<01:16:26.840> demo<01:16:27.600> um<01:16:28.080> we<01:16:28.239> can<01:16:28.960> if<01:16:29.040> you<01:16:29.120> see 01:16:29.310 --> 01:16:29.320 align:start position:0% much for this demo um we can if you see 01:16:29.320 --> 01:16:30.430 align:start position:0% much for this demo um we can if you see over<01:16:29.440> here<01:16:29.520> in<01:16:29.600> the<01:16:29.679> constants<01:16:30.040> file<01:16:30.239> we<01:16:30.320> have 01:16:30.430 --> 01:16:30.440 align:start position:0% over here in the constants file we have 01:16:30.440 --> 01:16:33.189 align:start position:0% over here in the constants file we have a<01:16:30.679> onee<01:16:31.679> constant<01:16:32.239> we<01:16:32.360> can<01:16:32.480> just<01:16:32.639> add<01:16:32.880> one<01:16:33.040> week 01:16:33.189 --> 01:16:33.199 align:start position:0% a onee constant we can just add one week 01:16:33.199 --> 01:16:35.229 align:start position:0% a onee constant we can just add one week to<01:16:33.280> the<01:16:33.360> current<01:16:33.600> block<01:16:33.840> time<01:16:34.080> stamp<01:16:34.960> um<01:16:35.120> we 01:16:35.229 --> 01:16:35.239 align:start position:0% to the current block time stamp um we 01:16:35.239 --> 01:16:37.629 align:start position:0% to the current block time stamp um we just<01:16:35.400> need<01:16:36.000> like<01:16:36.159> whatever<01:16:36.480> this<01:16:36.679> value<01:16:36.960> it<01:16:37.080> is 01:16:37.629 --> 01:16:37.639 align:start position:0% just need like whatever this value it is 01:16:37.639 --> 01:16:41.590 align:start position:0% just need like whatever this value it is is<01:16:37.920> it<01:16:38.120> has<01:16:38.239> to<01:16:38.400> be<01:16:38.600> greater<01:16:39.320> than<01:16:40.320> um<01:16:41.280> the 01:16:41.590 --> 01:16:41.600 align:start position:0% is it has to be greater than um the 01:16:41.600 --> 01:16:43.790 align:start position:0% is it has to be greater than um the finality<01:16:42.080> delay<01:16:42.440> seconds<01:16:43.120> in<01:16:43.239> the<01:16:43.360> future 01:16:43.790 --> 01:16:43.800 align:start position:0% finality delay seconds in the future 01:16:43.800 --> 01:16:47.189 align:start position:0% finality delay seconds in the future from<01:16:44.280> like<01:16:44.800> now<01:16:45.719> um<01:16:45.960> plus<01:16:46.239> some<01:16:46.560> extra 01:16:47.189 --> 01:16:47.199 align:start position:0% from like now um plus some extra 01:16:47.199 --> 01:16:49.709 align:start position:0% from like now um plus some extra cancellation<01:16:48.199> buffer<01:16:48.560> period<01:16:49.320> which<01:16:49.560> is 01:16:49.709 --> 01:16:49.719 align:start position:0% cancellation buffer period which is 01:16:49.719 --> 01:16:52.830 align:start position:0% cancellation buffer period which is hardcoded<01:16:50.400> as<01:16:50.520> a<01:16:50.679> constant<01:16:51.320> in<01:16:52.080> the<01:16:52.320> outbox 01:16:52.830 --> 01:16:52.840 align:start position:0% hardcoded as a constant in the outbox 01:16:52.840 --> 01:16:55.990 align:start position:0% hardcoded as a constant in the outbox contract<01:16:53.239> storage<01:16:53.719> as<01:16:53.920> a<01:16:54.040> full<01:16:54.360> day<01:16:55.199> so<01:16:55.679> um<01:16:55.840> for 01:16:55.990 --> 01:16:56.000 align:start position:0% contract storage as a full day so um for 01:16:56.000 --> 01:16:58.070 align:start position:0% contract storage as a full day so um for the<01:16:56.159> demo<01:16:56.600> just<01:16:56.719> to<01:16:56.880> get<01:16:57.000> a<01:16:57.159> valid<01:16:57.639> value<01:16:57.920> in 01:16:58.070 --> 01:16:58.080 align:start position:0% the demo just to get a valid value in 01:16:58.080 --> 01:17:00.070 align:start position:0% the demo just to get a valid value in here<01:16:58.280> one<01:16:58.480> week<01:16:58.639> should<01:16:58.800> be<01:16:58.920> more<01:16:59.080> than 01:17:00.070 --> 01:17:00.080 align:start position:0% here one week should be more than 01:17:00.080 --> 01:17:03.350 align:start position:0% here one week should be more than enough<01:17:01.080> so<01:17:01.239> this<01:17:01.360> will<01:17:01.520> be<01:17:02.320> date.<01:17:02.880> now<01:17:03.080> so<01:17:03.199> in 01:17:03.350 --> 01:17:03.360 align:start position:0% enough so this will be date. now so in 01:17:03.360 --> 01:17:05.070 align:start position:0% enough so this will be date. now so in JavaScript<01:17:03.880> if<01:17:03.960> you're<01:17:04.120> not<01:17:04.280> familiar<01:17:04.639> it<01:17:04.760> has 01:17:05.070 --> 01:17:05.080 align:start position:0% JavaScript if you're not familiar it has 01:17:05.080 --> 01:17:07.590 align:start position:0% JavaScript if you're not familiar it has a<01:17:05.679> global<01:17:06.080> date<01:17:06.480> object<01:17:07.040> that<01:17:07.199> if<01:17:07.280> you<01:17:07.400> do 01:17:07.590 --> 01:17:07.600 align:start position:0% a global date object that if you do 01:17:07.600 --> 01:17:10.030 align:start position:0% a global date object that if you do date.<01:17:08.080> now<01:17:08.239> will<01:17:08.480> return<01:17:08.600> the<01:17:08.719> Unix<01:17:09.120> Tim<01:17:09.320> stamp 01:17:10.030 --> 01:17:10.040 align:start position:0% date. now will return the Unix Tim stamp 01:17:10.040 --> 01:17:12.350 align:start position:0% date. now will return the Unix Tim stamp but<01:17:10.159> in<01:17:10.360> milliseconds<01:17:11.360> and<01:17:11.520> in<01:17:11.679> solidity<01:17:12.199> it's 01:17:12.350 --> 01:17:12.360 align:start position:0% but in milliseconds and in solidity it's 01:17:12.360 --> 01:17:14.629 align:start position:0% but in milliseconds and in solidity it's in<01:17:12.719> seconds<01:17:13.679> so<01:17:13.800> we<01:17:13.920> have<01:17:14.000> to<01:17:14.120> divide<01:17:14.400> that<01:17:14.520> by 01:17:14.629 --> 01:17:14.639 align:start position:0% in seconds so we have to divide that by 01:17:14.639 --> 01:17:17.790 align:start position:0% in seconds so we have to divide that by a<01:17:15.159> th<01:17:16.159> but<01:17:16.320> solidity<01:17:16.800> doesn't<01:17:17.080> like<01:17:17.320> decimals 01:17:17.790 --> 01:17:17.800 align:start position:0% a th but solidity doesn't like decimals 01:17:17.800 --> 01:17:19.629 align:start position:0% a th but solidity doesn't like decimals so<01:17:17.960> then<01:17:18.120> we<01:17:18.239> have<01:17:18.360> to<01:17:18.560> floor<01:17:19.120> that<01:17:19.360> to<01:17:19.520> the 01:17:19.629 --> 01:17:19.639 align:start position:0% so then we have to floor that to the 01:17:19.639 --> 01:17:22.149 align:start position:0% so then we have to floor that to the nearest 01:17:22.149 --> 01:17:22.159 align:start position:0% 01:17:22.159 --> 01:17:25.430 align:start position:0% integer<01:17:23.159> and<01:17:23.320> then<01:17:23.719> from<01:17:24.040> here<01:17:24.320> we<01:17:24.440> can<01:17:24.639> add 01:17:25.430 --> 01:17:25.440 align:start position:0% integer and then from here we can add 01:17:25.440 --> 01:17:26.550 align:start position:0% integer and then from here we can add the<01:17:25.520> onee 01:17:26.550 --> 01:17:26.560 align:start position:0% the onee 01:17:26.560 --> 01:17:28.870 align:start position:0% the onee constant<01:17:27.560> so<01:17:27.719> we'll<01:17:27.920> add<01:17:28.120> that<01:17:28.239> as<01:17:28.600> another 01:17:28.870 --> 01:17:28.880 align:start position:0% constant so we'll add that as another 01:17:28.880 --> 01:17:31.550 align:start position:0% constant so we'll add that as another import<01:17:29.440> from<01:17:29.639> this<01:17:29.800> constants 01:17:31.550 --> 01:17:31.560 align:start position:0% import from this constants 01:17:31.560 --> 01:17:34.790 align:start position:0% import from this constants file<01:17:32.560> and<01:17:32.639> then<01:17:32.800> use<01:17:33.000> it<01:17:33.199> down<01:17:33.440> here<01:17:33.840> for<01:17:34.440> the 01:17:34.790 --> 01:17:34.800 align:start position:0% file and then use it down here for the 01:17:34.800 --> 01:17:39.470 align:start position:0% file and then use it down here for the XPR<01:17:35.320> timestamp<01:17:35.840> we'll<01:17:36.120> add<01:17:36.360> one 01:17:39.470 --> 01:17:39.480 align:start position:0% 01:17:39.480 --> 01:17:42.110 align:start position:0% week<01:17:40.480> okay<01:17:40.800> and<01:17:40.920> then<01:17:41.040> the<01:17:41.159> last<01:17:41.320> two<01:17:41.520> fields 01:17:42.110 --> 01:17:42.120 align:start position:0% week okay and then the last two fields 01:17:42.120 --> 01:17:44.870 align:start position:0% week okay and then the last two fields are<01:17:42.639> this<01:17:43.280> um<01:17:43.880> pre-check<01:17:44.360> contract<01:17:44.719> and 01:17:44.870 --> 01:17:44.880 align:start position:0% are this um pre-check contract and 01:17:44.880 --> 01:17:47.870 align:start position:0% are this um pre-check contract and pre-check 01:17:47.870 --> 01:17:47.880 align:start position:0% 01:17:47.880 --> 01:17:50.390 align:start position:0% data<01:17:48.880> which<01:17:49.080> like<01:17:49.199> I<01:17:49.280> said<01:17:49.480> earlier<01:17:50.080> is<01:17:50.199> an 01:17:50.390 --> 01:17:50.400 align:start position:0% data which like I said earlier is an 01:17:50.400 --> 01:17:53.350 align:start position:0% data which like I said earlier is an optional<01:17:51.320> like<01:17:51.639> fulfillment<01:17:52.639> uh<01:17:52.920> condition 01:17:53.350 --> 01:17:53.360 align:start position:0% optional like fulfillment uh condition 01:17:53.360 --> 01:17:55.870 align:start position:0% optional like fulfillment uh condition that<01:17:53.520> the<01:17:53.719> requester<01:17:54.080> wants<01:17:54.280> to<01:17:54.400> be<01:17:54.520> true 01:17:55.870 --> 01:17:55.880 align:start position:0% that the requester wants to be true 01:17:55.880 --> 01:17:57.030 align:start position:0% that the requester wants to be true uh<01:17:56.040> because<01:17:56.199> it's<01:17:56.400> optional<01:17:56.719> we're<01:17:56.840> not<01:17:56.960> going 01:17:57.030 --> 01:17:57.040 align:start position:0% uh because it's optional we're not going 01:17:57.040 --> 01:17:59.910 align:start position:0% uh because it's optional we're not going to<01:17:57.120> be<01:17:57.239> using<01:17:57.480> it<01:17:57.639> today<01:17:58.199> but 01:17:59.910 --> 01:17:59.920 align:start position:0% to be using it today but 01:17:59.920 --> 01:18:02.350 align:start position:0% to be using it today but um<01:18:00.920> yeah<01:18:01.080> so<01:18:01.320> in<01:18:01.400> order<01:18:01.639> to<01:18:01.840> not<01:18:02.000> use<01:18:02.159> it<01:18:02.280> we 01:18:02.350 --> 01:18:02.360 align:start position:0% um yeah so in order to not use it we 01:18:02.360 --> 01:18:04.070 align:start position:0% um yeah so in order to not use it we have<01:18:02.480> to<01:18:02.560> pass<01:18:02.719> in<01:18:02.840> the<01:18:03.000> zero<01:18:03.320> address<01:18:03.920> and 01:18:04.070 --> 01:18:04.080 align:start position:0% have to pass in the zero address and 01:18:04.080 --> 01:18:07.510 align:start position:0% have to pass in the zero address and there's<01:18:04.239> a<01:18:04.600> a<01:18:05.120> helpful<01:18:06.120> constant<01:18:06.600> from<01:18:07.199> uh<01:18:07.400> the 01:18:07.510 --> 01:18:07.520 align:start position:0% there's a a helpful constant from uh the 01:18:07.520 --> 01:18:11.310 align:start position:0% there's a a helpful constant from uh the web3<01:18:07.920> library<01:18:08.239> I'm<01:18:08.320> using<01:18:09.000> theme<01:18:10.000> um<01:18:10.960> that<01:18:11.080> is 01:18:11.310 --> 01:18:11.320 align:start position:0% web3 library I'm using theme um that is 01:18:11.320 --> 01:18:13.110 align:start position:0% web3 library I'm using theme um that is just<01:18:11.520> called<01:18:11.760> the<01:18:11.840> zero<01:18:12.199> address<01:18:12.719> so<01:18:12.880> we<01:18:12.960> can 01:18:13.110 --> 01:18:13.120 align:start position:0% just called the zero address so we can 01:18:13.120 --> 01:18:15.669 align:start position:0% just called the zero address so we can import<01:18:13.600> that<01:18:14.080> at<01:18:14.199> the<01:18:14.400> top<01:18:14.719> and<01:18:14.840> then<01:18:15.000> use<01:18:15.320> that 01:18:15.669 --> 01:18:15.679 align:start position:0% import that at the top and then use that 01:18:15.679 --> 01:18:19.110 align:start position:0% import that at the top and then use that as<01:18:15.840> the<01:18:16.080> pre-check<01:18:16.600> contract<01:18:17.600> address<01:18:17.920> in 01:18:19.110 --> 01:18:19.120 align:start position:0% as the pre-check contract address in 01:18:19.120 --> 01:18:21.110 align:start position:0% as the pre-check contract address in here<01:18:20.120> and<01:18:20.199> then<01:18:20.400> last<01:18:20.600> but<01:18:20.719> not<01:18:20.880> least 01:18:21.110 --> 01:18:21.120 align:start position:0% here and then last but not least 01:18:21.120 --> 01:18:22.990 align:start position:0% here and then last but not least pre-check<01:18:21.560> data<01:18:22.040> in<01:18:22.159> order<01:18:22.360> for<01:18:22.520> it<01:18:22.600> to<01:18:22.800> pass 01:18:22.990 --> 01:18:23.000 align:start position:0% pre-check data in order for it to pass 01:18:23.000 --> 01:18:24.990 align:start position:0% pre-check data in order for it to pass the<01:18:23.120> offchain<01:18:23.600> validation<01:18:24.080> that<01:18:24.239> vhm<01:18:24.520> does<01:18:24.880> we 01:18:24.990 --> 01:18:25.000 align:start position:0% the offchain validation that vhm does we 01:18:25.000 --> 01:18:27.510 align:start position:0% the offchain validation that vhm does we just<01:18:25.120> have<01:18:25.239> to<01:18:25.440> add<01:18:25.679> an<01:18:25.880> ox<01:18:26.800> but<01:18:26.960> this<01:18:27.159> can<01:18:27.320> be 01:18:27.510 --> 01:18:27.520 align:start position:0% just have to add an ox but this can be 01:18:27.520 --> 01:18:29.390 align:start position:0% just have to add an ox but this can be anything<01:18:28.040> it<01:18:28.199> just<01:18:28.360> has<01:18:28.440> to<01:18:28.600> be<01:18:28.760> some<01:18:28.960> kind<01:18:29.120> of 01:18:29.390 --> 01:18:29.400 align:start position:0% anything it just has to be some kind of 01:18:29.400 --> 01:18:31.350 align:start position:0% anything it just has to be some kind of arbitrary<01:18:30.199> bite<01:18:30.440> string<01:18:30.920> because<01:18:31.080> we're<01:18:31.239> not 01:18:31.350 --> 01:18:31.360 align:start position:0% arbitrary bite string because we're not 01:18:31.360 --> 01:18:36.149 align:start position:0% arbitrary bite string because we're not using<01:18:31.639> this<01:18:31.800> step<01:18:32.199> it<01:18:32.280> doesn't<01:18:32.520> really 01:18:36.149 --> 01:18:36.159 align:start position:0% 01:18:36.159 --> 01:18:41.350 align:start position:0% matter<01:18:37.159> okay<01:18:37.639> so<01:18:38.560> that<01:18:39.520> just<01:18:39.800> about<01:18:40.400> covers 01:18:41.350 --> 01:18:41.360 align:start position:0% matter okay so that just about covers 01:18:41.360 --> 01:18:43.110 align:start position:0% matter okay so that just about covers all<01:18:41.560> of<01:18:41.760> the<01:18:41.960> requests<01:18:42.440> the<01:18:42.560> only<01:18:42.760> thing<01:18:43.000> we 01:18:43.110 --> 01:18:43.120 align:start position:0% all of the requests the only thing we 01:18:43.120 --> 01:18:44.830 align:start position:0% all of the requests the only thing we haven't<01:18:43.400> done<01:18:43.600> yet<01:18:43.800> is<01:18:43.960> encoded<01:18:44.440> the<01:18:44.560> call 01:18:44.830 --> 01:18:44.840 align:start position:0% haven't done yet is encoded the call 01:18:44.840 --> 01:18:47.830 align:start position:0% haven't done yet is encoded the call data<01:18:45.360> for<01:18:46.360> um<01:18:46.679> the<01:18:46.880> the<01:18:46.960> mint<01:18:47.280> function<01:18:47.639> on<01:18:47.760> the 01:18:47.830 --> 01:18:47.840 align:start position:0% data for um the the mint function on the 01:18:47.840 --> 01:18:51.990 align:start position:0% data for um the the mint function on the nft<01:18:48.560> contract<01:18:49.560> so<01:18:50.040> to<01:18:50.920> uh<01:18:51.040> reference<01:18:51.440> the<01:18:51.560> nft 01:18:51.990 --> 01:18:52.000 align:start position:0% nft contract so to uh reference the nft 01:18:52.000 --> 01:18:56.310 align:start position:0% nft contract so to uh reference the nft contract<01:18:52.400> let<01:18:52.480> me<01:18:52.639> pull<01:18:52.840> that<01:18:53.000> up 01:18:56.310 --> 01:18:56.320 align:start position:0% 01:18:56.320 --> 01:18:57.669 align:start position:0% it's<01:18:56.480> just<01:18:56.600> a<01:18:56.719> simple<01:18:56.960> Min<01:18:57.239> function<01:18:57.560> that 01:18:57.669 --> 01:18:57.679 align:start position:0% it's just a simple Min function that 01:18:57.679 --> 01:18:59.709 align:start position:0% it's just a simple Min function that takes<01:18:57.880> one<01:18:58.040> input<01:18:58.400> argument<01:18:59.159> um<01:18:59.400> which<01:18:59.520> is<01:18:59.600> the 01:18:59.709 --> 01:18:59.719 align:start position:0% takes one input argument um which is the 01:18:59.719 --> 01:19:02.590 align:start position:0% takes one input argument um which is the two<01:18:59.960> address<01:19:00.320> that<01:19:00.440> should<01:19:00.560> be<01:19:00.920> receiving<01:19:01.360> the 01:19:02.590 --> 01:19:02.600 align:start position:0% two address that should be receiving the 01:19:02.600 --> 01:19:05.430 align:start position:0% two address that should be receiving the nft<01:19:03.600> uh<01:19:03.719> there's<01:19:04.000> another<01:19:04.320> helpful<01:19:04.800> function 01:19:05.430 --> 01:19:05.440 align:start position:0% nft uh there's another helpful function 01:19:05.440 --> 01:19:11.510 align:start position:0% nft uh there's another helpful function from<01:19:05.840> VM<01:19:06.480> called<01:19:06.760> encode<01:19:07.360> function 01:19:11.510 --> 01:19:11.520 align:start position:0% 01:19:11.520 --> 01:19:14.110 align:start position:0% data<01:19:12.520> that<01:19:12.639> we<01:19:12.760> can<01:19:12.960> use<01:19:13.239> for<01:19:13.600> encoding<01:19:14.000> the 01:19:14.110 --> 01:19:14.120 align:start position:0% data that we can use for encoding the 01:19:14.120 --> 01:19:16.950 align:start position:0% data that we can use for encoding the call<01:19:14.320> data<01:19:14.840> here 01:19:16.950 --> 01:19:16.960 align:start position:0% call data here 01:19:16.960 --> 01:19:19.750 align:start position:0% call data here um<01:19:17.960> we<01:19:18.080> can<01:19:18.239> Define<01:19:18.520> this<01:19:18.840> as<01:19:19.080> another<01:19:19.480> local 01:19:19.750 --> 01:19:19.760 align:start position:0% um we can Define this as another local 01:19:19.760 --> 01:19:21.830 align:start position:0% um we can Define this as another local variable<01:19:20.159> above<01:19:20.400> the<01:19:20.560> calls<01:19:21.199> constant<01:19:21.679> so 01:19:21.830 --> 01:19:21.840 align:start position:0% variable above the calls constant so 01:19:21.840 --> 01:19:24.870 align:start position:0% variable above the calls constant so this<01:19:21.920> will<01:19:22.080> be<01:19:22.239> const<01:19:22.880> encoded 01:19:24.870 --> 01:19:24.880 align:start position:0% this will be const encoded 01:19:24.880 --> 01:19:28.830 align:start position:0% this will be const encoded call<01:19:25.199> data<01:19:25.840> is<01:19:26.000> equal<01:19:26.719> to<01:19:27.719> encode<01:19:28.199> function 01:19:28.830 --> 01:19:28.840 align:start position:0% call data is equal to encode function 01:19:28.840 --> 01:19:31.390 align:start position:0% call data is equal to encode function data<01:19:29.840> and<01:19:30.040> this<01:19:30.239> takes<01:19:30.520> in<01:19:30.960> actually<01:19:31.199> before 01:19:31.390 --> 01:19:31.400 align:start position:0% data and this takes in actually before 01:19:31.400 --> 01:19:33.350 align:start position:0% data and this takes in actually before we<01:19:31.520> Define<01:19:31.880> that<01:19:32.120> we'll<01:19:32.320> just<01:19:32.480> add<01:19:32.719> this<01:19:32.880> in<01:19:33.159> as 01:19:33.350 --> 01:19:33.360 align:start position:0% we Define that we'll just add this in as 01:19:33.360 --> 01:19:36.990 align:start position:0% we Define that we'll just add this in as the<01:19:33.600> value<01:19:34.000> for<01:19:34.679> data<01:19:35.679> encoded<01:19:36.120> call 01:19:36.990 --> 01:19:37.000 align:start position:0% the value for data encoded call 01:19:37.000 --> 01:19:39.350 align:start position:0% the value for data encoded call data<01:19:38.000> um<01:19:38.120> and<01:19:38.239> then<01:19:38.360> now<01:19:38.480> for<01:19:38.679> encode<01:19:39.040> function 01:19:39.350 --> 01:19:39.360 align:start position:0% data um and then now for encode function 01:19:39.360 --> 01:19:42.070 align:start position:0% data um and then now for encode function data<01:19:39.639> this<01:19:39.840> accepts<01:19:40.280> one<01:19:40.920> input<01:19:41.360> parameter 01:19:42.070 --> 01:19:42.080 align:start position:0% data this accepts one input parameter 01:19:42.080 --> 01:19:43.510 align:start position:0% data this accepts one input parameter which<01:19:42.199> is<01:19:42.320> an<01:19:42.600> object<01:19:42.960> with<01:19:43.080> a<01:19:43.199> couple<01:19:43.400> of 01:19:43.510 --> 01:19:43.520 align:start position:0% which is an object with a couple of 01:19:43.520 --> 01:19:46.470 align:start position:0% which is an object with a couple of fields<01:19:43.960> that<01:19:44.040> are<01:19:44.280> necessary<01:19:44.880> here<01:19:45.880> the<01:19:46.199> first 01:19:46.470 --> 01:19:46.480 align:start position:0% fields that are necessary here the first 01:19:46.480 --> 01:19:49.189 align:start position:0% fields that are necessary here the first one<01:19:46.840> being<01:19:47.600> uh<01:19:47.760> the<01:19:47.920> ABI<01:19:48.440> for<01:19:48.679> this<01:19:48.760> nft 01:19:49.189 --> 01:19:49.199 align:start position:0% one being uh the ABI for this nft 01:19:49.199 --> 01:19:51.189 align:start position:0% one being uh the ABI for this nft contract<01:19:49.800> which<01:19:49.920> is<01:19:50.159> actually<01:19:50.600> already<01:19:50.920> being 01:19:51.189 --> 01:19:51.199 align:start position:0% contract which is actually already being 01:19:51.199 --> 01:19:53.790 align:start position:0% contract which is actually already being imported<01:19:52.159> uh<01:19:52.280> as<01:19:52.440> nft<01:19:52.840> ABI<01:19:53.360> for<01:19:53.520> some<01:19:53.639> of<01:19:53.719> the 01:19:53.790 --> 01:19:53.800 align:start position:0% imported uh as nft ABI for some of the 01:19:53.800 --> 01:19:55.709 align:start position:0% imported uh as nft ABI for some of the other<01:19:53.960> help<01:19:54.440> help<01:19:54.840> functions<01:19:55.199> that<01:19:55.280> are 01:19:55.709 --> 01:19:55.719 align:start position:0% other help help functions that are 01:19:55.719 --> 01:19:58.550 align:start position:0% other help help functions that are defined<01:19:56.080> in<01:19:56.239> this<01:19:56.520> class<01:19:57.520> so<01:19:58.080> uh<01:19:58.199> we<01:19:58.280> can<01:19:58.440> just 01:19:58.550 --> 01:19:58.560 align:start position:0% defined in this class so uh we can just 01:19:58.560 --> 01:20:02.470 align:start position:0% defined in this class so uh we can just use<01:19:58.840> that<01:19:58.960> so<01:19:59.120> this<01:19:59.199> will<01:19:59.320> be<01:19:59.480> ABI<01:20:00.080> colon<01:20:00.639> nft 01:20:02.470 --> 01:20:02.480 align:start position:0% use that so this will be ABI colon nft 01:20:02.480 --> 01:20:04.550 align:start position:0% use that so this will be ABI colon nft ABI<01:20:03.480> I<01:20:03.560> don't<01:20:03.679> know<01:20:03.840> why<01:20:03.920> I<01:20:04.000> closed<01:20:04.360> that 01:20:04.550 --> 01:20:04.560 align:start position:0% ABI I don't know why I closed that 01:20:04.560 --> 01:20:07.950 align:start position:0% ABI I don't know why I closed that contract<01:20:04.960> we<01:20:05.040> still<01:20:05.199> need 01:20:07.950 --> 01:20:07.960 align:start position:0% 01:20:07.960 --> 01:20:10.030 align:start position:0% it<01:20:08.960> next<01:20:09.159> up<01:20:09.320> we<01:20:09.400> need<01:20:09.520> to<01:20:09.639> define<01:20:09.920> the 01:20:10.030 --> 01:20:10.040 align:start position:0% it next up we need to define the 01:20:10.040 --> 01:20:11.390 align:start position:0% it next up we need to define the function<01:20:10.320> name<01:20:10.560> that<01:20:10.679> we're<01:20:10.800> encoding<01:20:11.159> data 01:20:11.390 --> 01:20:11.400 align:start position:0% function name that we're encoding data 01:20:11.400 --> 01:20:13.669 align:start position:0% function name that we're encoding data for<01:20:11.840> so<01:20:12.120> that's<01:20:12.320> just<01:20:12.480> simply<01:20:12.800> mint<01:20:13.320> so<01:20:13.440> if<01:20:13.520> we 01:20:13.669 --> 01:20:13.679 align:start position:0% for so that's just simply mint so if we 01:20:13.679 --> 01:20:18.310 align:start position:0% for so that's just simply mint so if we copy<01:20:14.000> that<01:20:14.960> this<01:20:15.120> field<01:20:15.400> name<01:20:15.679> is<01:20:15.960> function 01:20:18.310 --> 01:20:18.320 align:start position:0% copy that this field name is function 01:20:18.320 --> 01:20:21.669 align:start position:0% copy that this field name is function name<01:20:19.320> with<01:20:19.600> mint<01:20:19.920> passed<01:20:20.280> in<01:20:21.280> and<01:20:21.400> then 01:20:21.669 --> 01:20:21.679 align:start position:0% name with mint passed in and then 01:20:21.679 --> 01:20:24.709 align:start position:0% name with mint passed in and then because<01:20:22.080> mint<01:20:22.719> accepts<01:20:23.440> one<01:20:23.840> input<01:20:24.159> parameter 01:20:24.709 --> 01:20:24.719 align:start position:0% because mint accepts one input parameter 01:20:24.719 --> 01:20:26.750 align:start position:0% because mint accepts one input parameter we<01:20:24.840> now<01:20:25.000> have<01:20:25.120> to<01:20:25.360> specify<01:20:25.920> that<01:20:26.239> with<01:20:26.360> a<01:20:26.440> field 01:20:26.750 --> 01:20:26.760 align:start position:0% we now have to specify that with a field 01:20:26.760 --> 01:20:29.830 align:start position:0% we now have to specify that with a field name<01:20:26.960> called<01:20:27.199> args<01:20:28.080> so<01:20:28.239> this<01:20:28.320> will<01:20:28.480> be<01:20:28.840> args 01:20:29.830 --> 01:20:29.840 align:start position:0% name called args so this will be args 01:20:29.840 --> 01:20:30.950 align:start position:0% name called args so this will be args which<01:20:29.960> is<01:20:30.040> an<01:20:30.159> array<01:20:30.400> of<01:20:30.520> the<01:20:30.600> input 01:20:30.950 --> 01:20:30.960 align:start position:0% which is an array of the input 01:20:30.960 --> 01:20:33.350 align:start position:0% which is an array of the input parameters<01:20:31.960> and<01:20:32.159> in<01:20:32.320> this<01:20:32.480> context<01:20:33.040> it's<01:20:33.199> just 01:20:33.350 --> 01:20:33.360 align:start position:0% parameters and in this context it's just 01:20:33.360 --> 01:20:35.350 align:start position:0% parameters and in this context it's just the<01:20:33.480> two<01:20:33.719> address<01:20:34.280> which<01:20:34.400> is<01:20:34.639> passed<01:20:34.920> in<01:20:35.159> here 01:20:35.350 --> 01:20:35.360 align:start position:0% the two address which is passed in here 01:20:35.360 --> 01:20:40.149 align:start position:0% the two address which is passed in here as 01:20:40.149 --> 01:20:40.159 align:start position:0% 01:20:40.159 --> 01:20:41.990 align:start position:0% address<01:20:41.159> and<01:20:41.280> that<01:20:41.400> should<01:20:41.560> be<01:20:41.719> it<01:20:41.800> for 01:20:41.990 --> 01:20:42.000 align:start position:0% address and that should be it for 01:20:42.000 --> 01:20:43.550 align:start position:0% address and that should be it for encoding<01:20:42.440> call 01:20:43.550 --> 01:20:43.560 align:start position:0% encoding call 01:20:43.560 --> 01:20:46.070 align:start position:0% encoding call data<01:20:44.560> all<01:20:44.679> right<01:20:44.800> so<01:20:44.960> at<01:20:45.080> this<01:20:45.199> point<01:20:45.440> we<01:20:45.679> have 01:20:46.070 --> 01:20:46.080 align:start position:0% data all right so at this point we have 01:20:46.080 --> 01:20:50.350 align:start position:0% data all right so at this point we have a<01:20:46.800> uh<01:20:47.040> fully<01:20:47.400> set<01:20:47.639> up<01:20:47.880> RP<01:20:48.800> 7755 01:20:50.350 --> 01:20:50.360 align:start position:0% a uh fully set up RP 7755 01:20:50.360 --> 01:20:52.830 align:start position:0% a uh fully set up RP 7755 request<01:20:51.360> um<01:20:51.760> now<01:20:52.040> we<01:20:52.159> need<01:20:52.320> to<01:20:52.440> set<01:20:52.600> up<01:20:52.719> the 01:20:52.830 --> 01:20:52.840 align:start position:0% request um now we need to set up the 01:20:52.840 --> 01:20:55.709 align:start position:0% request um now we need to set up the function<01:20:53.199> call<01:20:53.440> to<01:20:53.560> submit<01:20:53.840> the<01:20:54.000> request 01:20:55.709 --> 01:20:55.719 align:start position:0% function call to submit the request 01:20:55.719 --> 01:20:58.430 align:start position:0% function call to submit the request so<01:20:56.719> what<01:20:56.840> does<01:20:57.040> that<01:20:57.199> look<01:20:57.400> like<01:20:57.840> to<01:20:58.199> give<01:20:58.320> you 01:20:58.430 --> 01:20:58.440 align:start position:0% so what does that look like to give you 01:20:58.440 --> 01:21:00.390 align:start position:0% so what does that look like to give you a<01:20:58.520> little<01:20:58.639> bit<01:20:58.800> more<01:20:58.960> context<01:20:59.440> on<01:20:59.719> how<01:20:59.960> this 01:21:00.390 --> 01:21:00.400 align:start position:0% a little bit more context on how this 01:21:00.400 --> 01:21:03.550 align:start position:0% a little bit more context on how this class<01:21:00.600> is<01:21:00.760> set<01:21:00.960> up<01:21:01.760> we<01:21:02.000> have<01:21:02.480> uh<01:21:03.199> something 01:21:03.550 --> 01:21:03.560 align:start position:0% class is set up we have uh something 01:21:03.560 --> 01:21:05.990 align:start position:0% class is set up we have uh something called<01:21:03.719> a<01:21:03.880> wallet<01:21:04.199> client<01:21:04.920> in<01:21:05.639> like<01:21:05.760> as<01:21:05.880> a 01:21:05.990 --> 01:21:06.000 align:start position:0% called a wallet client in like as a 01:21:06.000 --> 01:21:08.790 align:start position:0% called a wallet client in like as a local<01:21:06.280> variable<01:21:06.800> here<01:21:07.800> and<01:21:08.520> if<01:21:08.639> you're 01:21:08.790 --> 01:21:08.800 align:start position:0% local variable here and if you're 01:21:08.800 --> 01:21:11.870 align:start position:0% local variable here and if you're unfamiliar<01:21:09.320> with<01:21:09.800> VH<01:21:10.320> as<01:21:10.400> a<01:21:10.760> web<01:21:10.960> 3<01:21:11.199> Library<01:21:11.760> it 01:21:11.870 --> 01:21:11.880 align:start position:0% unfamiliar with VH as a web 3 Library it 01:21:11.880 --> 01:21:13.390 align:start position:0% unfamiliar with VH as a web 3 Library it uses<01:21:12.280> things<01:21:12.520> called<01:21:12.719> public<01:21:13.000> clients<01:21:13.280> and 01:21:13.390 --> 01:21:13.400 align:start position:0% uses things called public clients and 01:21:13.400 --> 01:21:15.229 align:start position:0% uses things called public clients and wallet<01:21:13.679> clients<01:21:14.159> the<01:21:14.280> public<01:21:14.520> client<01:21:14.800> is<01:21:14.920> for 01:21:15.229 --> 01:21:15.239 align:start position:0% wallet clients the public client is for 01:21:15.239 --> 01:21:17.470 align:start position:0% wallet clients the public client is for like<01:21:15.360> reading<01:21:15.719> state<01:21:16.360> from<01:21:16.520> the<01:21:16.639> chain<01:21:17.360> and 01:21:17.470 --> 01:21:17.480 align:start position:0% like reading state from the chain and 01:21:17.480 --> 01:21:18.990 align:start position:0% like reading state from the chain and wallet<01:21:17.760> client<01:21:18.040> is<01:21:18.120> for<01:21:18.239> writing<01:21:18.600> state<01:21:18.840> to 01:21:18.990 --> 01:21:19.000 align:start position:0% wallet client is for writing state to 01:21:19.000 --> 01:21:21.390 align:start position:0% wallet client is for writing state to the<01:21:19.400> chain<01:21:20.400> uh<01:21:20.520> this<01:21:20.679> wallet<01:21:20.960> client<01:21:21.239> is 01:21:21.390 --> 01:21:21.400 align:start position:0% the chain uh this wallet client is 01:21:21.400 --> 01:21:22.950 align:start position:0% the chain uh this wallet client is already<01:21:21.679> defined<01:21:22.040> in<01:21:22.159> the<01:21:22.280> Constructor<01:21:22.760> so<01:21:22.880> we 01:21:22.950 --> 01:21:22.960 align:start position:0% already defined in the Constructor so we 01:21:22.960 --> 01:21:27.510 align:start position:0% already defined in the Constructor so we can<01:21:23.120> just<01:21:23.239> use<01:21:23.400> it<01:21:23.639> as<01:21:23.840> is<01:21:24.840> for<01:21:25.840> um<01:21:26.800> the<01:21:27.239> target 01:21:27.510 --> 01:21:27.520 align:start position:0% can just use it as is for um the target 01:21:27.520 --> 01:21:29.510 align:start position:0% can just use it as is for um the target chain<01:21:27.880> that<01:21:28.040> we<01:21:28.360> are<01:21:28.760> submitting<01:21:29.159> the<01:21:29.239> request 01:21:29.510 --> 01:21:29.520 align:start position:0% chain that we are submitting the request 01:21:29.520 --> 01:21:32.950 align:start position:0% chain that we are submitting the request to<01:21:29.760> which<01:21:29.840> is<01:21:29.960> mock<01:21:30.239> base 01:21:32.950 --> 01:21:32.960 align:start position:0% 01:21:32.960 --> 01:21:35.149 align:start position:0% here<01:21:33.960> so<01:21:34.239> this<01:21:34.320> is<01:21:34.480> going<01:21:34.560> to<01:21:34.679> be<01:21:34.960> an 01:21:35.149 --> 01:21:35.159 align:start position:0% here so this is going to be an 01:21:35.159 --> 01:21:36.709 align:start position:0% here so this is going to be an asynchronous<01:21:35.760> call<01:21:36.080> so<01:21:36.199> we'll<01:21:36.320> start<01:21:36.520> it<01:21:36.600> with 01:21:36.709 --> 01:21:36.719 align:start position:0% asynchronous call so we'll start it with 01:21:36.719 --> 01:21:38.270 align:start position:0% asynchronous call so we'll start it with a 01:21:38.270 --> 01:21:38.280 align:start position:0% a 01:21:38.280 --> 01:21:41.270 align:start position:0% a weight<01:21:39.280> this.<01:21:39.840> wallet 01:21:41.270 --> 01:21:41.280 align:start position:0% weight this. wallet 01:21:41.280 --> 01:21:43.229 align:start position:0% weight this. wallet client<01:21:42.280> and<01:21:42.440> the<01:21:42.560> function<01:21:42.880> name<01:21:43.040> that<01:21:43.159> we 01:21:43.229 --> 01:21:43.239 align:start position:0% client and the function name that we 01:21:43.239 --> 01:21:46.910 align:start position:0% client and the function name that we care<01:21:43.440> about<01:21:43.679> here<01:21:43.880> is<01:21:44.120> right<01:21:44.400> to 01:21:46.910 --> 01:21:46.920 align:start position:0% 01:21:46.920 --> 01:21:50.510 align:start position:0% contract<01:21:47.920> so<01:21:48.120> under<01:21:48.320> the<01:21:48.520> hood<01:21:49.360> this<01:21:50.360> this 01:21:50.510 --> 01:21:50.520 align:start position:0% contract so under the hood this this 01:21:50.520 --> 01:21:53.669 align:start position:0% contract so under the hood this this creates<01:21:51.000> your<01:21:51.719> um<01:21:52.719> your<01:21:53.239> your<01:21:53.520> your 01:21:53.669 --> 01:21:53.679 align:start position:0% creates your um your your your 01:21:53.679 --> 01:21:55.590 align:start position:0% creates your um your your your transaction<01:21:54.360> and<01:21:54.639> assigns<01:21:54.960> it<01:21:55.120> and<01:21:55.280> and<01:21:55.400> sends 01:21:55.590 --> 01:21:55.600 align:start position:0% transaction and assigns it and and sends 01:21:55.600 --> 01:21:56.470 align:start position:0% transaction and assigns it and and sends it<01:21:55.719> to<01:21:55.800> the 01:21:56.470 --> 01:21:56.480 align:start position:0% it to the 01:21:56.480 --> 01:21:59.950 align:start position:0% it to the network<01:21:57.480> this<01:21:57.560> will<01:21:58.000> return<01:21:58.840> a<01:21:59.360> transaction 01:21:59.950 --> 01:21:59.960 align:start position:0% network this will return a transaction 01:21:59.960 --> 01:22:01.709 align:start position:0% network this will return a transaction hash<01:22:00.239> if<01:22:00.360> it's<01:22:00.560> successful<01:22:01.040> so<01:22:01.159> we<01:22:01.280> can<01:22:01.400> store 01:22:01.709 --> 01:22:01.719 align:start position:0% hash if it's successful so we can store 01:22:01.719 --> 01:22:04.709 align:start position:0% hash if it's successful so we can store that<01:22:01.880> as 01:22:04.709 --> 01:22:04.719 align:start position:0% 01:22:04.719 --> 01:22:07.270 align:start position:0% hash<01:22:05.719> and<01:22:05.800> then<01:22:05.920> we<01:22:06.040> need<01:22:06.199> to<01:22:06.440> set<01:22:06.600> up<01:22:06.920> the 01:22:07.270 --> 01:22:07.280 align:start position:0% hash and then we need to set up the 01:22:07.280 --> 01:22:09.390 align:start position:0% hash and then we need to set up the configuration<01:22:08.080> for<01:22:08.560> like<01:22:08.719> what<01:22:08.920> contract<01:22:09.280> we 01:22:09.390 --> 01:22:09.400 align:start position:0% configuration for like what contract we 01:22:09.400 --> 01:22:11.390 align:start position:0% configuration for like what contract we writing<01:22:09.679> to<01:22:10.199> what<01:22:10.360> function<01:22:10.960> we're<01:22:11.120> writing 01:22:11.390 --> 01:22:11.400 align:start position:0% writing to what function we're writing 01:22:11.400 --> 01:22:14.750 align:start position:0% writing to what function we're writing to<01:22:12.080> what<01:22:12.679> parameters<01:22:13.159> are<01:22:13.360> needed<01:22:14.360> um<01:22:14.480> so<01:22:14.679> that 01:22:14.750 --> 01:22:14.760 align:start position:0% to what parameters are needed um so that 01:22:14.760 --> 01:22:16.510 align:start position:0% to what parameters are needed um so that can<01:22:14.880> be<01:22:14.960> a<01:22:15.080> single 01:22:16.510 --> 01:22:16.520 align:start position:0% can be a single 01:22:16.520 --> 01:22:21.229 align:start position:0% can be a single um<01:22:17.520> object<01:22:17.880> in<01:22:18.199> here<01:22:19.199> where<01:22:19.360> we 01:22:21.229 --> 01:22:21.239 align:start position:0% um object in here where we 01:22:21.239 --> 01:22:23.189 align:start position:0% um object in here where we Define<01:22:22.239> for<01:22:22.440> reference<01:22:22.800> I'm<01:22:22.880> going<01:22:22.960> to<01:22:23.080> pull 01:22:23.189 --> 01:22:23.199 align:start position:0% Define for reference I'm going to pull 01:22:23.199 --> 01:22:27.470 align:start position:0% Define for reference I'm going to pull up<01:22:23.320> the<01:22:23.440> constants<01:22:23.960> file<01:22:24.280> again 01:22:27.470 --> 01:22:27.480 align:start position:0% 01:22:27.480 --> 01:22:28.790 align:start position:0% we<01:22:27.600> need<01:22:27.719> to<01:22:27.880> define<01:22:28.159> the<01:22:28.320> address<01:22:28.600> that<01:22:28.679> we're 01:22:28.790 --> 01:22:28.800 align:start position:0% we need to define the address that we're 01:22:28.800 --> 01:22:31.270 align:start position:0% we need to define the address that we're sending<01:22:29.040> the<01:22:29.199> transaction<01:22:29.639> to<01:22:30.120> so<01:22:30.520> address 01:22:31.270 --> 01:22:31.280 align:start position:0% sending the transaction to so address 01:22:31.280 --> 01:22:33.709 align:start position:0% sending the transaction to so address this<01:22:31.360> is<01:22:31.520> going<01:22:31.600> to<01:22:31.800> be<01:22:32.639> coming<01:22:32.960> from<01:22:33.400> mock 01:22:33.709 --> 01:22:33.719 align:start position:0% this is going to be coming from mock 01:22:33.719 --> 01:22:34.750 align:start position:0% this is going to be coming from mock base<01:22:34.080> because<01:22:34.199> we're<01:22:34.320> submitting<01:22:34.679> the 01:22:34.750 --> 01:22:34.760 align:start position:0% base because we're submitting the 01:22:34.760 --> 01:22:36.629 align:start position:0% base because we're submitting the request<01:22:35.040> to<01:22:35.159> mock 01:22:36.629 --> 01:22:36.639 align:start position:0% request to mock 01:22:36.639 --> 01:22:38.950 align:start position:0% request to mock base<01:22:37.639> uh<01:22:37.800> the<01:22:37.960> the<01:22:38.040> contract<01:22:38.400> we<01:22:38.480> care<01:22:38.679> about 01:22:38.950 --> 01:22:38.960 align:start position:0% base uh the the contract we care about 01:22:38.960 --> 01:22:40.870 align:start position:0% base uh the the contract we care about is<01:22:39.080> the<01:22:39.199> outbox<01:22:39.760> contract<01:22:40.120> for<01:22:40.280> the<01:22:40.480> standard 01:22:40.870 --> 01:22:40.880 align:start position:0% is the outbox contract for the standard 01:22:40.880 --> 01:22:44.470 align:start position:0% is the outbox contract for the standard so<01:22:41.040> this<01:22:41.159> will<01:22:41.320> be<01:22:41.880> mock<01:22:42.760> base. 01:22:44.470 --> 01:22:44.480 align:start position:0% so this will be mock base. 01:22:44.480 --> 01:22:47.750 align:start position:0% so this will be mock base. contracts. 01:22:47.750 --> 01:22:47.760 align:start position:0% 01:22:47.760 --> 01:22:50.470 align:start position:0% outbox<01:22:48.760> next<01:22:48.960> we<01:22:49.080> need<01:22:49.199> to<01:22:49.360> specify<01:22:49.840> the<01:22:50.000> ABI 01:22:50.470 --> 01:22:50.480 align:start position:0% outbox next we need to specify the ABI 01:22:50.480 --> 01:22:53.709 align:start position:0% outbox next we need to specify the ABI for<01:22:50.600> the<01:22:50.960> outbox<01:22:51.960> so<01:22:52.440> this<01:22:52.880> can<01:22:53.120> be<01:22:53.600> we're 01:22:53.709 --> 01:22:53.719 align:start position:0% for the outbox so this can be we're 01:22:53.719 --> 01:22:55.590 align:start position:0% for the outbox so this can be we're going<01:22:53.800> to<01:22:53.880> have<01:22:53.960> to<01:22:54.040> import<01:22:54.320> this<01:22:54.520> at<01:22:54.639> the<01:22:54.800> top 01:22:55.590 --> 01:22:55.600 align:start position:0% going to have to import this at the top 01:22:55.600 --> 01:22:57.430 align:start position:0% going to have to import this at the top so<01:22:55.840> this<01:22:55.960> will 01:22:57.430 --> 01:22:57.440 align:start position:0% so this will 01:22:57.440 --> 01:22:59.310 align:start position:0% so this will be 01:22:59.310 --> 01:22:59.320 align:start position:0% be 01:22:59.320 --> 01:23:05.310 align:start position:0% be import<01:23:00.320> outbox<01:23:00.960> ABI<01:23:01.719> from<01:23:02.000> do<01:23:02.239> do<01:23:02.679> slabi 01:23:05.310 --> 01:23:05.320 align:start position:0% import outbox ABI from do do slabi 01:23:05.320 --> 01:23:07.790 align:start position:0% import outbox ABI from do do slabi outbox<01:23:06.320> we<01:23:06.679> already<01:23:06.920> have<01:23:07.080> that<01:23:07.239> populated<01:23:07.679> in 01:23:07.790 --> 01:23:07.800 align:start position:0% outbox we already have that populated in 01:23:07.800 --> 01:23:10.790 align:start position:0% outbox we already have that populated in this<01:23:08.440> um 01:23:10.790 --> 01:23:10.800 align:start position:0% 01:23:10.800 --> 01:23:13.430 align:start position:0% directory<01:23:11.800> so<01:23:11.920> we<01:23:12.000> can<01:23:12.159> Define<01:23:12.480> that<01:23:12.679> as 01:23:13.430 --> 01:23:13.440 align:start position:0% directory so we can Define that as 01:23:13.440 --> 01:23:16.870 align:start position:0% directory so we can Define that as the<01:23:14.440> ABI 01:23:16.870 --> 01:23:16.880 align:start position:0% the ABI 01:23:16.880 --> 01:23:19.229 align:start position:0% the ABI here<01:23:17.880> we<01:23:18.000> then<01:23:18.120> need<01:23:18.239> to<01:23:18.480> define<01:23:18.760> the<01:23:18.880> function 01:23:19.229 --> 01:23:19.239 align:start position:0% here we then need to define the function 01:23:19.239 --> 01:23:20.870 align:start position:0% here we then need to define the function name<01:23:19.520> that<01:23:19.639> we're<01:23:20.040> requesting<01:23:20.480> or<01:23:20.600> sending 01:23:20.870 --> 01:23:20.880 align:start position:0% name that we're requesting or sending 01:23:20.880 --> 01:23:23.709 align:start position:0% name that we're requesting or sending the<01:23:21.040> transaction<01:23:21.520> to<01:23:22.360> um<01:23:22.679> so<01:23:23.080> if<01:23:23.159> we<01:23:23.320> pull<01:23:23.520> up 01:23:23.709 --> 01:23:23.719 align:start position:0% the transaction to um so if we pull up 01:23:23.719 --> 01:23:27.790 align:start position:0% the transaction to um so if we pull up the<01:23:23.880> rip<01:23:24.520> 7755<01:23:25.400> outbox<01:23:25.920> contract<01:23:26.400> over<01:23:26.800> here 01:23:27.790 --> 01:23:27.800 align:start position:0% the rip 7755 outbox contract over here 01:23:27.800 --> 01:23:30.229 align:start position:0% the rip 7755 outbox contract over here the<01:23:27.920> entry<01:23:28.280> point<01:23:29.040> as<01:23:29.159> I<01:23:29.239> said<01:23:29.480> earlier<01:23:30.000> for 01:23:30.229 --> 01:23:30.239 align:start position:0% the entry point as I said earlier for 01:23:30.239 --> 01:23:32.310 align:start position:0% the entry point as I said earlier for the<01:23:30.920> U<01:23:31.040> standard<01:23:31.440> is<01:23:31.560> this<01:23:31.719> request<01:23:32.080> cross 01:23:32.310 --> 01:23:32.320 align:start position:0% the U standard is this request cross 01:23:32.320 --> 01:23:34.430 align:start position:0% the U standard is this request cross chain<01:23:32.600> call<01:23:32.840> function<01:23:33.280> so<01:23:33.440> we<01:23:33.520> can<01:23:33.679> copy<01:23:34.040> that 01:23:34.430 --> 01:23:34.440 align:start position:0% chain call function so we can copy that 01:23:34.440 --> 01:23:38.830 align:start position:0% chain call function so we can copy that into<01:23:35.080> function 01:23:38.830 --> 01:23:38.840 align:start position:0% 01:23:38.840 --> 01:23:41.470 align:start position:0% name<01:23:39.840> we<01:23:40.000> then<01:23:40.120> need<01:23:40.280> to<01:23:40.480> define<01:23:40.920> the<01:23:41.159> input 01:23:41.470 --> 01:23:41.480 align:start position:0% name we then need to define the input 01:23:41.480 --> 01:23:45.030 align:start position:0% name we then need to define the input args<01:23:42.440> so<01:23:43.440> um<01:23:43.639> as<01:23:43.719> you<01:23:43.880> see<01:23:44.199> here<01:23:44.440> it's<01:23:44.639> just<01:23:44.800> one 01:23:45.030 --> 01:23:45.040 align:start position:0% args so um as you see here it's just one 01:23:45.040 --> 01:23:48.910 align:start position:0% args so um as you see here it's just one argument<01:23:45.800> uh<01:23:45.920> which<01:23:46.040> is<01:23:46.159> the<01:23:46.280> cross<01:23:46.520> chain 01:23:48.910 --> 01:23:48.920 align:start position:0% 01:23:48.920 --> 01:23:51.350 align:start position:0% request<01:23:49.920> this<01:23:50.040> is<01:23:50.199> going<01:23:50.400> to 01:23:51.350 --> 01:23:51.360 align:start position:0% request this is going to 01:23:51.360 --> 01:23:53.669 align:start position:0% request this is going to be<01:23:52.360> um<01:23:52.480> the<01:23:52.639> request<01:23:52.920> that<01:23:53.000> we<01:23:53.120> just<01:23:53.239> defined 01:23:53.669 --> 01:23:53.679 align:start position:0% be um the request that we just defined 01:23:53.679 --> 01:23:56.470 align:start position:0% be um the request that we just defined here 01:23:56.470 --> 01:23:56.480 align:start position:0% 01:23:56.480 --> 01:23:57.950 align:start position:0% and<01:23:56.560> then<01:23:56.760> last<01:23:56.960> but<01:23:57.080> not<01:23:57.239> least<01:23:57.440> we<01:23:57.560> need<01:23:57.679> to 01:23:57.950 --> 01:23:57.960 align:start position:0% and then last but not least we need to 01:23:57.960 --> 01:24:00.350 align:start position:0% and then last but not least we need to Define<01:23:58.960> um<01:23:59.280> any<01:23:59.560> value<01:23:59.960> that<01:24:00.080> should<01:24:00.239> be 01:24:00.350 --> 01:24:00.360 align:start position:0% Define um any value that should be 01:24:00.360 --> 01:24:02.030 align:start position:0% Define um any value that should be submitted<01:24:00.840> with<01:24:01.040> this<01:24:01.400> with<01:24:01.560> this 01:24:02.030 --> 01:24:02.040 align:start position:0% submitted with this with this 01:24:02.040 --> 01:24:03.990 align:start position:0% submitted with this with this transaction<01:24:03.040> so<01:24:03.360> that's<01:24:03.560> going<01:24:03.639> to<01:24:03.760> be<01:24:03.920> a 01:24:03.990 --> 01:24:04.000 align:start position:0% transaction so that's going to be a 01:24:04.000 --> 01:24:05.750 align:start position:0% transaction so that's going to be a field<01:24:04.360> called 01:24:05.750 --> 01:24:05.760 align:start position:0% field called 01:24:05.760 --> 01:24:08.510 align:start position:0% field called value<01:24:06.760> and<01:24:07.040> in<01:24:07.199> this<01:24:07.400> context<01:24:07.960> it's<01:24:08.199> not 01:24:08.510 --> 01:24:08.520 align:start position:0% value and in this context it's not 01:24:08.520 --> 01:24:10.430 align:start position:0% value and in this context it's not actually<01:24:08.800> going<01:24:08.960> to<01:24:09.120> be<01:24:09.320> mint<01:24:09.760> price<01:24:10.159> because 01:24:10.430 --> 01:24:10.440 align:start position:0% actually going to be mint price because 01:24:10.440 --> 01:24:12.390 align:start position:0% actually going to be mint price because if<01:24:10.560> you<01:24:10.679> remember<01:24:10.960> we<01:24:11.120> added<01:24:11.360> a<01:24:11.480> 2%<01:24:12.000> buffer<01:24:12.280> to 01:24:12.390 --> 01:24:12.400 align:start position:0% if you remember we added a 2% buffer to 01:24:12.400 --> 01:24:14.189 align:start position:0% if you remember we added a 2% buffer to the<01:24:12.480> mint<01:24:12.719> price<01:24:12.960> as<01:24:13.120> the<01:24:13.280> reward<01:24:13.639> amount<01:24:13.960> for 01:24:14.189 --> 01:24:14.199 align:start position:0% the mint price as the reward amount for 01:24:14.199 --> 01:24:16.950 align:start position:0% the mint price as the reward amount for this<01:24:14.840> um<01:24:15.040> cross<01:24:15.320> chain<01:24:15.560> call<01:24:16.000> so<01:24:16.360> the<01:24:16.560> value 01:24:16.950 --> 01:24:16.960 align:start position:0% this um cross chain call so the value 01:24:16.960 --> 01:24:19.750 align:start position:0% this um cross chain call so the value here<01:24:17.120> should<01:24:17.320> be<01:24:17.520> request.<01:24:18.400> reward<01:24:18.719> amount<01:24:19.440> to 01:24:19.750 --> 01:24:19.760 align:start position:0% here should be request. reward amount to 01:24:19.760 --> 01:24:27.270 align:start position:0% here should be request. reward amount to account<01:24:19.960> for<01:24:20.080> that<01:24:20.239> buffer 01:24:27.270 --> 01:24:27.280 align:start position:0% 01:24:27.280 --> 01:24:30.709 align:start position:0% and<01:24:27.760> that<01:24:28.000> should<01:24:28.480> be<01:24:29.360> it<01:24:29.600> for<01:24:29.880> setting<01:24:30.199> up<01:24:30.440> the 01:24:30.709 --> 01:24:30.719 align:start position:0% and that should be it for setting up the 01:24:30.719 --> 01:24:34.870 align:start position:0% and that should be it for setting up the the<01:24:30.880> contract<01:24:31.320> send<01:24:32.679> um<01:24:33.679> the<01:24:33.880> last<01:24:34.199> piece<01:24:34.520> here 01:24:34.870 --> 01:24:34.880 align:start position:0% the contract send um the last piece here 01:24:34.880 --> 01:24:37.189 align:start position:0% the contract send um the last piece here is<01:24:35.280> using<01:24:35.600> a<01:24:35.760> public<01:24:36.040> client<01:24:36.360> from<01:24:36.560> vhim<01:24:37.080> we 01:24:37.189 --> 01:24:37.199 align:start position:0% is using a public client from vhim we 01:24:37.199 --> 01:24:40.030 align:start position:0% is using a public client from vhim we can<01:24:37.840> um<01:24:38.199> wait<01:24:38.400> for<01:24:38.600> a<01:24:38.719> transaction<01:24:39.239> receipt<01:24:39.800> to 01:24:40.030 --> 01:24:40.040 align:start position:0% can um wait for a transaction receipt to 01:24:40.040 --> 01:24:41.870 align:start position:0% can um wait for a transaction receipt to make<01:24:40.199> sure<01:24:40.440> that<01:24:40.560> the<01:24:40.639> request<01:24:40.920> is<01:24:41.080> confirmed 01:24:41.870 --> 01:24:41.880 align:start position:0% make sure that the request is confirmed 01:24:41.880 --> 01:24:43.750 align:start position:0% make sure that the request is confirmed or<01:24:42.040> the<01:24:42.159> transaction<01:24:42.560> is<01:24:42.719> confirmed<01:24:43.520> so<01:24:43.679> we 01:24:43.750 --> 01:24:43.760 align:start position:0% or the transaction is confirmed so we 01:24:43.760 --> 01:24:46.270 align:start position:0% or the transaction is confirmed so we can<01:24:43.840> do<01:24:44.000> that<01:24:44.119> with<01:24:44.239> another<01:24:44.560> await 01:24:46.270 --> 01:24:46.280 align:start position:0% can do that with another await 01:24:46.280 --> 01:24:50.550 align:start position:0% can do that with another await call<01:24:47.280> um<01:24:47.639> in<01:24:47.840> the<01:24:48.080> Constance<01:24:48.760> file<01:24:49.280> for<01:24:50.199> the 01:24:50.550 --> 01:24:50.560 align:start position:0% call um in the Constance file for the 01:24:50.560 --> 01:24:52.709 align:start position:0% call um in the Constance file for the chain<01:24:51.040> configurations<01:24:52.040> one<01:24:52.159> of<01:24:52.280> the<01:24:52.360> fields 01:24:52.709 --> 01:24:52.719 align:start position:0% chain configurations one of the fields 01:24:52.719 --> 01:24:54.550 align:start position:0% chain configurations one of the fields for<01:24:52.880> Mach<01:24:53.159> base<01:24:53.480> is<01:24:53.560> a<01:24:53.719> public<01:24:53.960> client<01:24:54.400> so<01:24:54.480> we 01:24:54.550 --> 01:24:54.560 align:start position:0% for Mach base is a public client so we 01:24:54.560 --> 01:24:56.310 align:start position:0% for Mach base is a public client so we can<01:24:54.679> use<01:24:54.840> that<01:24:55.000> directly<01:24:55.800> so<01:24:55.960> this<01:24:56.080> will<01:24:56.199> be 01:24:56.310 --> 01:24:56.320 align:start position:0% can use that directly so this will be 01:24:56.320 --> 01:24:58.310 align:start position:0% can use that directly so this will be await<01:24:56.719> mock 01:24:58.310 --> 01:24:58.320 align:start position:0% await mock 01:24:58.320 --> 01:25:01.870 align:start position:0% await mock base.<01:24:59.320> public<01:24:59.679> client<01:25:00.560> dot<01:25:01.280> um<01:25:01.440> the<01:25:01.560> function 01:25:01.870 --> 01:25:01.880 align:start position:0% base. public client dot um the function 01:25:01.880 --> 01:25:03.070 align:start position:0% base. public client dot um the function name<01:25:02.040> that<01:25:02.159> we're<01:25:02.280> going<01:25:02.400> to<01:25:02.480> use<01:25:02.719> here<01:25:02.920> is 01:25:03.070 --> 01:25:03.080 align:start position:0% name that we're going to use here is 01:25:03.080 --> 01:25:06.070 align:start position:0% name that we're going to use here is called<01:25:03.320> wait<01:25:03.520> for<01:25:03.880> transaction 01:25:06.070 --> 01:25:06.080 align:start position:0% called wait for transaction 01:25:06.080 --> 01:25:08.950 align:start position:0% called wait for transaction receipt<01:25:07.080> and<01:25:07.199> that<01:25:07.320> takes<01:25:07.560> in<01:25:07.760> just<01:25:07.920> one<01:25:08.159> input 01:25:08.950 --> 01:25:08.960 align:start position:0% receipt and that takes in just one input 01:25:08.960 --> 01:25:14.590 align:start position:0% receipt and that takes in just one input object<01:25:09.960> which<01:25:10.159> is<01:25:10.880> uh<01:25:11.159> the<01:25:11.360> transaction 01:25:14.590 --> 01:25:14.600 align:start position:0% 01:25:14.600 --> 01:25:17.109 align:start position:0% hash<01:25:15.600> and<01:25:15.760> in<01:25:15.920> JavaScript<01:25:16.440> if<01:25:16.520> the<01:25:16.600> field<01:25:16.880> name 01:25:17.109 --> 01:25:17.119 align:start position:0% hash and in JavaScript if the field name 01:25:17.119 --> 01:25:19.149 align:start position:0% hash and in JavaScript if the field name and<01:25:17.440> the<01:25:18.199> the<01:25:18.440> value<01:25:18.719> name<01:25:18.960> that<01:25:19.040> you're 01:25:19.149 --> 01:25:19.159 align:start position:0% and the the value name that you're 01:25:19.159 --> 01:25:20.950 align:start position:0% and the the value name that you're setting<01:25:19.480> it<01:25:19.639> as<01:25:19.840> are<01:25:20.080> the<01:25:20.159> same<01:25:20.360> name<01:25:20.639> you<01:25:20.760> can 01:25:20.950 --> 01:25:20.960 align:start position:0% setting it as are the same name you can 01:25:20.960 --> 01:25:23.350 align:start position:0% setting it as are the same name you can omit<01:25:21.400> the<01:25:21.719> colon<01:25:22.239> and<01:25:22.360> the<01:25:22.679> the<01:25:22.800> value<01:25:23.080> so<01:25:23.239> like 01:25:23.350 --> 01:25:23.360 align:start position:0% omit the colon and the the value so like 01:25:23.360 --> 01:25:25.390 align:start position:0% omit the colon and the the value so like this<01:25:23.480> is<01:25:23.600> the<01:25:23.719> same<01:25:23.880> thing<01:25:24.080> as 01:25:25.390 --> 01:25:25.400 align:start position:0% this is the same thing as 01:25:25.400 --> 01:25:28.149 align:start position:0% this is the same thing as this<01:25:26.400> um<01:25:26.679> so<01:25:26.960> I'll<01:25:27.119> leave<01:25:27.239> it<01:25:27.360> like<01:25:27.520> this<01:25:27.639> for 01:25:28.149 --> 01:25:28.159 align:start position:0% this um so I'll leave it like this for 01:25:28.159 --> 01:25:30.390 align:start position:0% this um so I'll leave it like this for clarity<01:25:29.159> and<01:25:29.320> if<01:25:29.440> we<01:25:29.600> get<01:25:29.760> through<01:25:30.000> this<01:25:30.159> wait 01:25:30.390 --> 01:25:30.400 align:start position:0% clarity and if we get through this wait 01:25:30.400 --> 01:25:32.910 align:start position:0% clarity and if we get through this wait for<01:25:30.719> transaction<01:25:31.239> receipt<01:25:31.679> call<01:25:32.679> then<01:25:32.800> the 01:25:32.910 --> 01:25:32.920 align:start position:0% for transaction receipt call then the 01:25:32.920 --> 01:25:34.430 align:start position:0% for transaction receipt call then the transaction<01:25:33.320> should<01:25:33.480> be<01:25:33.639> successful<01:25:34.119> so<01:25:34.320> then 01:25:34.430 --> 01:25:34.440 align:start position:0% transaction should be successful so then 01:25:34.440 --> 01:25:37.350 align:start position:0% transaction should be successful so then we'll<01:25:34.719> log<01:25:35.080> something 01:25:37.350 --> 01:25:37.360 align:start position:0% we'll log something 01:25:37.360 --> 01:25:45.590 align:start position:0% we'll log something console.log<01:25:38.400> um<01:25:39.679> transaction 01:25:45.590 --> 01:25:45.600 align:start position:0% 01:25:45.600 --> 01:25:48.910 align:start position:0% success<01:25:46.600> okay<01:25:47.440> so<01:25:47.639> that<01:25:47.760> should<01:25:47.920> be<01:25:48.040> our<01:25:48.280> full 01:25:48.910 --> 01:25:48.920 align:start position:0% success okay so that should be our full 01:25:48.920 --> 01:25:51.149 align:start position:0% success okay so that should be our full request<01:25:49.920> um<01:25:50.119> it's<01:25:50.320> pretty<01:25:50.480> straightforward<01:25:51.080> I 01:25:51.149 --> 01:25:51.159 align:start position:0% request um it's pretty straightforward I 01:25:51.159 --> 01:25:52.430 align:start position:0% request um it's pretty straightforward I just<01:25:51.280> wanted<01:25:51.480> to<01:25:51.600> kind<01:25:51.719> of<01:25:51.840> give<01:25:51.920> you<01:25:52.040> a<01:25:52.159> walk 01:25:52.430 --> 01:25:52.440 align:start position:0% just wanted to kind of give you a walk 01:25:52.440 --> 01:25:53.629 align:start position:0% just wanted to kind of give you a walk through<01:25:52.639> on<01:25:52.800> all<01:25:52.880> the<01:25:53.000> different<01:25:53.199> field<01:25:53.440> names 01:25:53.629 --> 01:25:53.639 align:start position:0% through on all the different field names 01:25:53.639 --> 01:25:55.830 align:start position:0% through on all the different field names and<01:25:53.760> how<01:25:53.880> they<01:25:53.960> should<01:25:54.040> be<01:25:54.360> assigned<01:25:54.920> and<01:25:55.679> um 01:25:55.830 --> 01:25:55.840 align:start position:0% and how they should be assigned and um 01:25:55.840 --> 01:25:57.189 align:start position:0% and how they should be assigned and um what<01:25:55.960> the<01:25:56.080> values<01:25:56.480> mean<01:25:56.800> and<01:25:56.960> like<01:25:57.080> how 01:25:57.189 --> 01:25:57.199 align:start position:0% what the values mean and like how 01:25:57.199 --> 01:25:59.950 align:start position:0% what the values mean and like how they're<01:25:57.360> fitting<01:25:58.040> together<01:25:59.040> um<01:25:59.400> this<01:25:59.639> should 01:25:59.950 --> 01:25:59.960 align:start position:0% they're fitting together um this should 01:25:59.960 --> 01:26:02.510 align:start position:0% they're fitting together um this should be<01:26:00.440> enough<01:26:00.880> in<01:26:01.159> place<01:26:01.400> to<01:26:01.560> run<01:26:01.800> the<01:26:01.960> system<01:26:02.320> end 01:26:02.510 --> 01:26:02.520 align:start position:0% be enough in place to run the system end 01:26:02.520 --> 01:26:05.669 align:start position:0% be enough in place to run the system end to<01:26:02.639> end<01:26:03.639> so<01:26:03.920> if<01:26:04.040> we<01:26:04.239> take<01:26:04.400> a 01:26:05.669 --> 01:26:05.679 align:start position:0% to end so if we take a 01:26:05.679 --> 01:26:09.390 align:start position:0% to end so if we take a look<01:26:06.679> in<01:26:06.880> the<01:26:07.119> root<01:26:07.960> of<01:26:08.119> the<01:26:08.320> directory<01:26:09.239> uh 01:26:09.390 --> 01:26:09.400 align:start position:0% look in the root of the directory uh 01:26:09.400 --> 01:26:11.229 align:start position:0% look in the root of the directory uh this<01:26:09.600> the<01:26:09.679> root<01:26:09.880> read<01:26:10.159> me<01:26:10.480> here<01:26:10.880> there's<01:26:11.040> a 01:26:11.229 --> 01:26:11.239 align:start position:0% this the root read me here there's a 01:26:11.239 --> 01:26:13.310 align:start position:0% this the root read me here there's a list<01:26:11.400> of<01:26:11.600> commands<01:26:12.119> for<01:26:12.440> spinning<01:26:12.840> up<01:26:13.000> all<01:26:13.119> of 01:26:13.310 --> 01:26:13.320 align:start position:0% list of commands for spinning up all of 01:26:13.320 --> 01:26:15.350 align:start position:0% list of commands for spinning up all of these<01:26:13.920> all<01:26:14.119> the<01:26:14.239> infra<01:26:14.600> here<01:26:14.760> to<01:26:14.960> deploy<01:26:15.280> the 01:26:15.350 --> 01:26:15.360 align:start position:0% these all the infra here to deploy the 01:26:15.360 --> 01:26:16.830 align:start position:0% these all the infra here to deploy the contracts<01:26:15.760> on<01:26:15.960> top<01:26:16.119> of<01:26:16.360> and<01:26:16.520> all<01:26:16.600> of<01:26:16.719> the 01:26:16.830 --> 01:26:16.840 align:start position:0% contracts on top of and all of the 01:26:16.840 --> 01:26:18.189 align:start position:0% contracts on top of and all of the services<01:26:17.239> that<01:26:17.360> are<01:26:17.480> needed<01:26:17.800> to<01:26:18.040> get 01:26:18.189 --> 01:26:18.199 align:start position:0% services that are needed to get 01:26:18.199 --> 01:26:21.390 align:start position:0% services that are needed to get everything<01:26:18.480> to<01:26:18.679> work<01:26:19.199> together<01:26:20.199> so<01:26:20.760> um<01:26:21.040> we<01:26:21.159> can 01:26:21.390 --> 01:26:21.400 align:start position:0% everything to work together so um we can 01:26:21.400 --> 01:26:24.590 align:start position:0% everything to work together so um we can start<01:26:21.840> by<01:26:22.400> running<01:26:22.840> these<01:26:23.000> commands<01:26:24.440> the 01:26:24.590 --> 01:26:24.600 align:start position:0% start by running these commands the 01:26:24.600 --> 01:26:27.350 align:start position:0% start by running these commands the first<01:26:24.800> thing<01:26:24.920> we<01:26:25.040> need<01:26:25.199> to<01:26:25.400> do<01:26:25.960> is<01:26:26.800> spin<01:26:27.080> up<01:26:27.239> our 01:26:27.350 --> 01:26:27.360 align:start position:0% first thing we need to do is spin up our 01:26:27.360 --> 01:26:29.910 align:start position:0% first thing we need to do is spin up our local<01:26:27.639> chains<01:26:28.520> so<01:26:28.760> if<01:26:28.840> we<01:26:28.960> open<01:26:29.199> new<01:26:29.360> terminals 01:26:29.910 --> 01:26:29.920 align:start position:0% local chains so if we open new terminals 01:26:29.920 --> 01:26:32.430 align:start position:0% local chains so if we open new terminals that<01:26:30.040> are<01:26:30.199> each<01:26:30.440> at<01:26:30.560> the<01:26:30.679> root<01:26:30.960> of<01:26:31.119> the<01:26:31.440> project 01:26:32.430 --> 01:26:32.440 align:start position:0% that are each at the root of the project 01:26:32.440 --> 01:26:34.709 align:start position:0% that are each at the root of the project we<01:26:32.520> can<01:26:32.679> open<01:26:33.040> three<01:26:33.600> in<01:26:33.760> split<01:26:34.080> screen<01:26:34.480> side 01:26:34.709 --> 01:26:34.719 align:start position:0% we can open three in split screen side 01:26:34.719 --> 01:26:37.149 align:start position:0% we can open three in split screen side by<01:26:34.960> side<01:26:35.760> and<01:26:35.880> this<01:26:35.960> is<01:26:36.080> going<01:26:36.199> to<01:26:36.320> be<01:26:36.480> meant<01:26:36.840> to 01:26:37.149 --> 01:26:37.159 align:start position:0% by side and this is going to be meant to 01:26:37.159 --> 01:26:39.390 align:start position:0% by side and this is going to be meant to represent<01:26:37.960> the<01:26:38.239> the<01:26:38.360> mackl<01:26:38.800> one<01:26:39.040> and<01:26:39.159> then<01:26:39.280> the 01:26:39.390 --> 01:26:39.400 align:start position:0% represent the the mackl one and then the 01:26:39.400 --> 01:26:42.470 align:start position:0% represent the the mackl one and then the two<01:26:39.600> Mach<01:26:39.840> L2<01:26:40.400> chains<01:26:41.400> so<01:26:41.560> we<01:26:41.639> can<01:26:41.840> start<01:26:42.199> that 01:26:42.470 --> 01:26:42.480 align:start position:0% two Mach L2 chains so we can start that 01:26:42.480 --> 01:26:44.629 align:start position:0% two Mach L2 chains so we can start that with<01:26:43.080> um<01:26:43.199> there's<01:26:43.360> a<01:26:43.480> make<01:26:43.760> file<01:26:44.040> defining<01:26:44.440> all 01:26:44.629 --> 01:26:44.639 align:start position:0% with um there's a make file defining all 01:26:44.639 --> 01:26:46.070 align:start position:0% with um there's a make file defining all these<01:26:44.760> commands<01:26:45.360> if<01:26:45.440> you<01:26:45.520> want<01:26:45.639> to<01:26:45.760> see<01:26:45.960> what 01:26:46.070 --> 01:26:46.080 align:start position:0% these commands if you want to see what 01:26:46.080 --> 01:26:48.270 align:start position:0% these commands if you want to see what they're<01:26:46.360> actually<01:26:46.600> doing<01:26:46.920> under<01:26:47.159> the<01:26:47.280> hood<01:26:48.119> we 01:26:48.270 --> 01:26:48.280 align:start position:0% they're actually doing under the hood we 01:26:48.280 --> 01:26:51.229 align:start position:0% they're actually doing under the hood we can<01:26:48.480> run<01:26:49.000> make<01:26:49.440> start<01:26:49.800> mock<01:26:50.080> L1<01:26:50.760> in<01:26:50.880> the<01:26:51.000> first 01:26:51.229 --> 01:26:51.239 align:start position:0% can run make start mock L1 in the first 01:26:51.239 --> 01:26:53.229 align:start position:0% can run make start mock L1 in the first terminal<01:26:52.000> so<01:26:52.199> this<01:26:52.280> is<01:26:52.400> like<01:26:52.520> our<01:26:52.639> mock<01:26:52.840> L1 01:26:53.229 --> 01:26:53.239 align:start position:0% terminal so this is like our mock L1 01:26:53.239 --> 01:26:54.830 align:start position:0% terminal so this is like our mock L1 chain 01:26:54.830 --> 01:26:54.840 align:start position:0% chain 01:26:54.840 --> 01:26:57.669 align:start position:0% chain we<01:26:54.920> can<01:26:55.080> then<01:26:55.280> run<01:26:55.639> make<01:26:55.960> start<01:26:56.280> mock 01:26:57.669 --> 01:26:57.679 align:start position:0% we can then run make start mock 01:26:57.679 --> 01:27:00.030 align:start position:0% we can then run make start mock base<01:26:58.679> this<01:26:58.760> will<01:26:58.920> be<01:26:59.000> our<01:26:59.159> mock<01:26:59.440> base<01:26:59.679> chain<01:26:59.960> in 01:27:00.030 --> 01:27:00.040 align:start position:0% base this will be our mock base chain in 01:27:00.040 --> 01:27:02.390 align:start position:0% base this will be our mock base chain in the<01:27:00.159> middle<01:27:00.960> and<01:27:01.119> then<01:27:01.679> lastly<01:27:02.000> we<01:27:02.119> can<01:27:02.239> do 01:27:02.390 --> 01:27:02.400 align:start position:0% the middle and then lastly we can do 01:27:02.400 --> 01:27:05.109 align:start position:0% the middle and then lastly we can do make<01:27:02.639> start<01:27:02.880> mock<01:27:03.440> arbitrum<01:27:04.440> to<01:27:04.600> run<01:27:04.760> our<01:27:04.880> mock 01:27:05.109 --> 01:27:05.119 align:start position:0% make start mock arbitrum to run our mock 01:27:05.119 --> 01:27:06.830 align:start position:0% make start mock arbitrum to run our mock arbitrum<01:27:05.600> chain<01:27:05.960> in<01:27:06.040> the<01:27:06.159> terminal<01:27:06.560> on<01:27:06.679> the 01:27:06.830 --> 01:27:06.840 align:start position:0% arbitrum chain in the terminal on the 01:27:06.840 --> 01:27:09.229 align:start position:0% arbitrum chain in the terminal on the right<01:27:07.480> here<01:27:08.480> so<01:27:08.639> now<01:27:08.800> with<01:27:08.920> these<01:27:09.080> three 01:27:09.229 --> 01:27:09.239 align:start position:0% right here so now with these three 01:27:09.239 --> 01:27:13.310 align:start position:0% right here so now with these three chains<01:27:09.560> running<01:27:10.520> we<01:27:10.800> have<01:27:11.800> um<01:27:12.800> we<01:27:12.960> have<01:27:13.119> our 01:27:13.310 --> 01:27:13.320 align:start position:0% chains running we have um we have our 01:27:13.320 --> 01:27:14.510 align:start position:0% chains running we have um we have our our<01:27:13.440> local<01:27:13.679> chains<01:27:13.960> running<01:27:14.239> so<01:27:14.360> we<01:27:14.440> can 01:27:14.510 --> 01:27:14.520 align:start position:0% our local chains running so we can 01:27:14.520 --> 01:27:16.550 align:start position:0% our local chains running so we can deploy<01:27:14.840> our<01:27:14.960> contracts<01:27:15.360> on<01:27:15.520> top<01:27:15.639> of<01:27:15.760> them 01:27:16.550 --> 01:27:16.560 align:start position:0% deploy our contracts on top of them 01:27:16.560 --> 01:27:18.990 align:start position:0% deploy our contracts on top of them there's<01:27:16.840> another<01:27:17.480> make<01:27:17.880> file<01:27:18.239> command<01:27:18.679> set<01:27:18.840> up 01:27:18.990 --> 01:27:19.000 align:start position:0% there's another make file command set up 01:27:19.000 --> 01:27:20.510 align:start position:0% there's another make file command set up for<01:27:19.239> deploying<01:27:19.600> the<01:27:19.760> contracts<01:27:20.199> in<01:27:20.360> the 01:27:20.510 --> 01:27:20.520 align:start position:0% for deploying the contracts in the 01:27:20.520 --> 01:27:22.350 align:start position:0% for deploying the contracts in the correct<01:27:20.880> order<01:27:21.280> that<01:27:21.400> is<01:27:21.560> required<01:27:22.040> by<01:27:22.239> the 01:27:22.350 --> 01:27:22.360 align:start position:0% correct order that is required by the 01:27:22.360 --> 01:27:24.709 align:start position:0% correct order that is required by the offchain<01:27:22.800> services<01:27:23.320> here<01:27:23.880> so<01:27:24.199> we<01:27:24.280> can<01:27:24.400> open<01:27:24.560> a 01:27:24.709 --> 01:27:24.719 align:start position:0% offchain services here so we can open a 01:27:24.719 --> 01:27:26.590 align:start position:0% offchain services here so we can open a new<01:27:24.960> terminal<01:27:25.719> um<01:27:25.920> the<01:27:26.040> three<01:27:26.199> blockchains 01:27:26.590 --> 01:27:26.600 align:start position:0% new terminal um the three blockchains 01:27:26.600 --> 01:27:28.950 align:start position:0% new terminal um the three blockchains are<01:27:26.760> still<01:27:26.960> running<01:27:27.480> in<01:27:27.600> the<01:27:27.719> background<01:27:28.239> here 01:27:28.950 --> 01:27:28.960 align:start position:0% are still running in the background here 01:27:28.960 --> 01:27:30.830 align:start position:0% are still running in the background here um<01:27:29.080> I<01:27:29.159> just<01:27:29.280> have<01:27:29.360> a<01:27:29.480> new<01:27:29.600> terminal<01:27:30.400> running<01:27:30.679> on 01:27:30.830 --> 01:27:30.840 align:start position:0% um I just have a new terminal running on 01:27:30.840 --> 01:27:33.750 align:start position:0% um I just have a new terminal running on top<01:27:30.960> of<01:27:31.280> them<01:27:32.280> we<01:27:32.400> can<01:27:32.560> run<01:27:32.880> make<01:27:33.159> setup 01:27:33.750 --> 01:27:33.760 align:start position:0% top of them we can run make setup 01:27:33.760 --> 01:27:36.070 align:start position:0% top of them we can run make setup contracts<01:27:34.760> and<01:27:34.960> that's<01:27:35.239> going<01:27:35.440> to<01:27:35.679> compile 01:27:36.070 --> 01:27:36.080 align:start position:0% contracts and that's going to compile 01:27:36.080 --> 01:27:37.669 align:start position:0% contracts and that's going to compile and<01:27:36.239> deploy<01:27:36.600> all<01:27:36.719> of<01:27:36.840> the<01:27:36.960> contracts<01:27:37.400> to<01:27:37.560> the 01:27:37.669 --> 01:27:37.679 align:start position:0% and deploy all of the contracts to the 01:27:37.679 --> 01:27:41.470 align:start position:0% and deploy all of the contracts to the local<01:27:38.080> network<01:27:39.080> so<01:27:39.239> that'll<01:27:39.480> just<01:27:39.600> take<01:27:39.760> a 01:27:41.470 --> 01:27:41.480 align:start position:0% local network so that'll just take a 01:27:41.480 --> 01:27:43.990 align:start position:0% local network so that'll just take a second<01:27:42.480> while<01:27:42.679> that's<01:27:42.920> going<01:27:43.159> we<01:27:43.280> can<01:27:43.520> copy 01:27:43.990 --> 01:27:44.000 align:start position:0% second while that's going we can copy 01:27:44.000 --> 01:27:48.350 align:start position:0% second while that's going we can copy the<01:27:44.199> make<01:27:44.760> start<01:27:45.760> um<01:27:46.159> Sinker<01:27:47.159> command<01:27:48.000> so<01:27:48.239> what 01:27:48.350 --> 01:27:48.360 align:start position:0% the make start um Sinker command so what 01:27:48.360 --> 01:27:49.470 align:start position:0% the make start um Sinker command so what this<01:27:48.440> is<01:27:48.560> going<01:27:48.639> to<01:27:48.760> do<01:27:48.920> is<01:27:49.080> start<01:27:49.360> the 01:27:49.470 --> 01:27:49.480 align:start position:0% this is going to do is start the 01:27:49.480 --> 01:27:52.030 align:start position:0% this is going to do is start the offchain<01:27:50.000> service<01:27:50.480> for<01:27:51.360> sharing<01:27:51.800> State 01:27:52.030 --> 01:27:52.040 align:start position:0% offchain service for sharing State 01:27:52.040 --> 01:27:53.830 align:start position:0% offchain service for sharing State representations<01:27:52.880> bidirectionally<01:27:53.600> between 01:27:53.830 --> 01:27:53.840 align:start position:0% representations bidirectionally between 01:27:53.840 --> 01:27:56.390 align:start position:0% representations bidirectionally between the<01:27:54.159> m<01:27:54.360> l<01:27:54.480> one<01:27:54.679> and<01:27:54.800> the<01:27:54.920> mackl 01:27:56.390 --> 01:27:56.400 align:start position:0% the m l one and the mackl 01:27:56.400 --> 01:27:59.390 align:start position:0% the m l one and the mackl 2s<01:27:57.400> uh<01:27:57.480> and<01:27:57.639> this<01:27:57.719> one's<01:27:58.159> pretty<01:27:58.400> chatty<01:27:59.000> so<01:27:59.280> we 01:27:59.390 --> 01:27:59.400 align:start position:0% 2s uh and this one's pretty chatty so we 01:27:59.400 --> 01:28:01.669 align:start position:0% 2s uh and this one's pretty chatty so we can<01:27:59.600> now<01:27:59.880> open<01:28:00.080> a<01:28:00.239> new<01:28:00.440> terminal<01:28:01.320> for<01:28:01.520> the 01:28:01.669 --> 01:28:01.679 align:start position:0% can now open a new terminal for the 01:28:01.679 --> 01:28:03.629 align:start position:0% can now open a new terminal for the final<01:28:01.960> two<01:28:02.199> terminals<01:28:02.560> that<01:28:02.639> are<01:28:02.800> needed<01:28:03.119> here 01:28:03.629 --> 01:28:03.639 align:start position:0% final two terminals that are needed here 01:28:03.639 --> 01:28:06.109 align:start position:0% final two terminals that are needed here there's<01:28:03.760> a<01:28:03.880> ton<01:28:04.040> of<01:28:04.159> terminals<01:28:04.679> I<01:28:04.880> know<01:28:05.880> um<01:28:06.000> we 01:28:06.109 --> 01:28:06.119 align:start position:0% there's a ton of terminals I know um we 01:28:06.119 --> 01:28:07.669 align:start position:0% there's a ton of terminals I know um we need<01:28:06.239> to<01:28:06.360> start<01:28:06.600> the<01:28:06.719> offchain<01:28:07.119> fulfiller<01:28:07.560> to 01:28:07.669 --> 01:28:07.679 align:start position:0% need to start the offchain fulfiller to 01:28:07.679 --> 01:28:09.629 align:start position:0% need to start the offchain fulfiller to listen<01:28:07.920> to<01:28:08.199> in<01:28:08.400> response<01:28:08.840> to 01:28:09.629 --> 01:28:09.639 align:start position:0% listen to in response to 01:28:09.639 --> 01:28:12.550 align:start position:0% listen to in response to requests<01:28:10.639> uh<01:28:10.800> so<01:28:11.000> that's<01:28:11.239> make<01:28:11.560> start 01:28:12.550 --> 01:28:12.560 align:start position:0% requests uh so that's make start 01:28:12.560 --> 01:28:14.629 align:start position:0% requests uh so that's make start fulfiller<01:28:13.560> so<01:28:13.719> now<01:28:13.880> we<01:28:14.000> have<01:28:14.119> the<01:28:14.199> fulfiller 01:28:14.629 --> 01:28:14.639 align:start position:0% fulfiller so now we have the fulfiller 01:28:14.639 --> 01:28:16.510 align:start position:0% fulfiller so now we have the fulfiller listening<01:28:15.159> we<01:28:15.280> can<01:28:15.400> do<01:28:15.560> a<01:28:15.719> split<01:28:16.000> screen<01:28:16.360> here 01:28:16.510 --> 01:28:16.520 align:start position:0% listening we can do a split screen here 01:28:16.520 --> 01:28:19.229 align:start position:0% listening we can do a split screen here to<01:28:16.719> now<01:28:16.960> run<01:28:17.159> the<01:28:17.320> demo<01:28:17.800> so<01:28:18.360> to<01:28:18.560> run<01:28:18.719> the<01:28:18.880> demo 01:28:19.229 --> 01:28:19.239 align:start position:0% to now run the demo so to run the demo 01:28:19.239 --> 01:28:21.709 align:start position:0% to now run the demo so to run the demo app<01:28:19.679> and<01:28:19.920> mint<01:28:20.159> the<01:28:20.239> nft<01:28:20.800> we<01:28:20.880> would<01:28:21.080> just<01:28:21.280> run 01:28:21.709 --> 01:28:21.719 align:start position:0% app and mint the nft we would just run 01:28:21.719 --> 01:28:28.510 align:start position:0% app and mint the nft we would just run make<01:28:22.040> demo<01:28:22.840> so<01:28:22.960> if<01:28:23.040> we<01:28:23.159> type<01:28:23.400> that<01:28:23.560> in 01:28:28.510 --> 01:28:28.520 align:start position:0% 01:28:28.520 --> 01:28:30.990 align:start position:0% not<01:28:28.679> too<01:28:28.920> pretty<01:28:29.320> but<01:28:29.560> logs<01:28:29.880> to<01:28:30.040> the<01:28:30.159> console 01:28:30.990 --> 01:28:31.000 align:start position:0% not too pretty but logs to the console 01:28:31.000 --> 01:28:32.870 align:start position:0% not too pretty but logs to the console uh<01:28:31.239> what<01:28:31.360> it<01:28:31.679> what<01:28:31.800> it's<01:28:32.360> what<01:28:32.480> it's<01:28:32.639> doing 01:28:32.870 --> 01:28:32.880 align:start position:0% uh what it what it's what it's doing 01:28:32.880 --> 01:28:34.709 align:start position:0% uh what it what it's what it's doing here<01:28:33.119> current<01:28:33.400> state<01:28:33.920> so<01:28:34.040> we<01:28:34.159> have<01:28:34.320> welcome<01:28:34.600> to 01:28:34.709 --> 01:28:34.719 align:start position:0% here current state so we have welcome to 01:28:34.719 --> 01:28:37.830 align:start position:0% here current state so we have welcome to the<01:28:34.960> demo<01:28:35.960> uh<01:28:36.080> mint<01:28:36.280> your<01:28:36.400> nft<01:28:37.000> the<01:28:37.080> Devcon<01:28:37.480> nft 01:28:37.830 --> 01:28:37.840 align:start position:0% the demo uh mint your nft the Devcon nft 01:28:37.840 --> 01:28:40.430 align:start position:0% the demo uh mint your nft the Devcon nft on<01:28:38.000> mock<01:28:38.199> arbitrum<01:28:38.880> we<01:28:39.000> currently<01:28:39.360> have<01:28:39.639> zero 01:28:40.430 --> 01:28:40.440 align:start position:0% on mock arbitrum we currently have zero 01:28:40.440 --> 01:28:42.870 align:start position:0% on mock arbitrum we currently have zero in<01:28:40.920> um<01:28:41.239> in<01:28:41.639> the<01:28:41.920> wallet<01:28:42.280> address<01:28:42.560> that's<01:28:42.719> being 01:28:42.870 --> 01:28:42.880 align:start position:0% in um in the wallet address that's being 01:28:42.880 --> 01:28:45.390 align:start position:0% in um in the wallet address that's being used<01:28:43.159> for<01:28:43.280> the<01:28:43.400> demo<01:28:43.760> here<01:28:44.400> the<01:28:44.520> price<01:28:44.719> is<01:28:44.840> 1<01:28:45.080> e 01:28:45.390 --> 01:28:45.400 align:start position:0% used for the demo here the price is 1 e 01:28:45.400 --> 01:28:47.350 align:start position:0% used for the demo here the price is 1 e and<01:28:45.520> the<01:28:45.600> current<01:28:45.880> base<01:28:46.159> balance<01:28:46.639> is<01:28:47.080> almost 01:28:47.350 --> 01:28:47.360 align:start position:0% and the current base balance is almost 01:28:47.360 --> 01:28:50.470 align:start position:0% and the current base balance is almost 10,000<01:28:47.840> eth<01:28:48.400> because<01:28:48.639> this<01:28:48.760> is<01:28:49.159> uh<01:28:49.280> one<01:28:49.400> of<01:28:49.560> the 01:28:50.470 --> 01:28:50.480 align:start position:0% 10,000 eth because this is uh one of the 01:28:50.480 --> 01:28:53.030 align:start position:0% 10,000 eth because this is uh one of the default<01:28:51.480> um<01:28:51.760> accounts<01:28:52.159> on<01:28:52.320> the<01:28:52.440> local<01:28:52.679> Anvil 01:28:53.030 --> 01:28:53.040 align:start position:0% default um accounts on the local Anvil 01:28:53.040 --> 01:28:55.629 align:start position:0% default um accounts on the local Anvil nodes<01:28:54.119> so<01:28:54.239> now<01:28:54.360> if<01:28:54.440> we<01:28:54.600> press<01:28:54.880> enter<01:28:55.400> this<01:28:55.520> is 01:28:55.629 --> 01:28:55.639 align:start position:0% nodes so now if we press enter this is 01:28:55.639 --> 01:28:58.109 align:start position:0% nodes so now if we press enter this is going<01:28:55.719> to<01:28:55.840> send<01:28:56.159> that<01:28:56.320> mint<01:28:56.679> request<01:28:57.320> to<01:28:57.920> the 01:28:58.109 --> 01:28:58.119 align:start position:0% going to send that mint request to the 01:28:58.119 --> 01:29:00.189 align:start position:0% going to send that mint request to the local<01:28:58.520> network<01:28:59.520> and<01:28:59.639> we<01:28:59.719> can<01:28:59.840> see<01:29:00.040> if 01:29:00.189 --> 01:29:00.199 align:start position:0% local network and we can see if 01:29:00.199 --> 01:29:03.830 align:start position:0% local network and we can see if everything<01:29:00.639> worked<01:29:01.400> successfully<01:29:02.639> and<01:29:03.639> it 01:29:03.830 --> 01:29:03.840 align:start position:0% everything worked successfully and it 01:29:03.840 --> 01:29:06.310 align:start position:0% everything worked successfully and it did<01:29:04.199> so<01:29:04.639> the<01:29:04.840> transaction<01:29:05.320> went<01:29:05.520> through<01:29:06.119> we 01:29:06.310 --> 01:29:06.320 align:start position:0% did so the transaction went through we 01:29:06.320 --> 01:29:08.070 align:start position:0% did so the transaction went through we actually<01:29:06.560> if<01:29:06.679> we<01:29:06.800> run<01:29:06.960> this<01:29:07.159> again<01:29:07.600> we<01:29:07.760> already 01:29:08.070 --> 01:29:08.080 align:start position:0% actually if we run this again we already 01:29:08.080 --> 01:29:09.669 align:start position:0% actually if we run this again we already have<01:29:08.239> the<01:29:08.520> current<01:29:08.760> nft<01:29:09.080> on<01:29:09.159> the<01:29:09.280> destination 01:29:09.669 --> 01:29:09.679 align:start position:0% have the current nft on the destination 01:29:09.679 --> 01:29:11.629 align:start position:0% have the current nft on the destination chain<01:29:10.360> because<01:29:10.560> the<01:29:10.679> fulfiller<01:29:11.239> if<01:29:11.320> you<01:29:11.440> saw 01:29:11.629 --> 01:29:11.639 align:start position:0% chain because the fulfiller if you saw 01:29:11.639 --> 01:29:13.390 align:start position:0% chain because the fulfiller if you saw over<01:29:11.880> here<01:29:12.400> picked<01:29:12.639> up<01:29:12.760> on<01:29:12.880> the<01:29:13.000> request 01:29:13.390 --> 01:29:13.400 align:start position:0% over here picked up on the request 01:29:13.400 --> 01:29:14.870 align:start position:0% over here picked up on the request almost<01:29:13.719> right<01:29:13.880> away<01:29:14.080> and<01:29:14.239> submitted<01:29:14.639> it 01:29:14.870 --> 01:29:14.880 align:start position:0% almost right away and submitted it 01:29:14.880 --> 01:29:16.709 align:start position:0% almost right away and submitted it because<01:29:15.080> it<01:29:15.400> validated<01:29:15.960> that<01:29:16.159> the<01:29:16.560> um 01:29:16.709 --> 01:29:16.719 align:start position:0% because it validated that the um 01:29:16.719 --> 01:29:18.910 align:start position:0% because it validated that the um incentive<01:29:17.199> was<01:29:17.360> sufficient<01:29:18.360> and<01:29:18.480> then<01:29:18.639> now<01:29:18.800> in 01:29:18.910 --> 01:29:18.920 align:start position:0% incentive was sufficient and then now in 01:29:18.920 --> 01:29:20.229 align:start position:0% incentive was sufficient and then now in a<01:29:19.040> second<01:29:19.280> we<01:29:19.400> should<01:29:19.520> see<01:29:19.719> something<01:29:19.960> else 01:29:20.229 --> 01:29:20.239 align:start position:0% a second we should see something else 01:29:20.239 --> 01:29:22.870 align:start position:0% a second we should see something else happen<01:29:21.159> um<01:29:21.360> because<01:29:21.719> the<01:29:22.040> finality<01:29:22.440> delay<01:29:22.760> of 01:29:22.870 --> 01:29:22.880 align:start position:0% happen um because the finality delay of 01:29:22.880 --> 01:29:25.270 align:start position:0% happen um because the finality delay of 10<01:29:23.159> seconds<01:29:23.560> has<01:29:23.679> gone<01:29:23.880> past 01:29:25.270 --> 01:29:25.280 align:start position:0% 10 seconds has gone past 01:29:25.280 --> 01:29:27.510 align:start position:0% 10 seconds has gone past and<01:29:25.840> uh<01:29:26.000> what<01:29:26.119> the<01:29:26.239> fulfiller<01:29:26.719> just<01:29:26.920> did<01:29:27.280> is<01:29:27.400> it 01:29:27.510 --> 01:29:27.520 align:start position:0% and uh what the fulfiller just did is it 01:29:27.520 --> 01:29:29.310 align:start position:0% and uh what the fulfiller just did is it picked<01:29:27.760> up<01:29:27.880> on<01:29:28.000> the<01:29:28.119> fact<01:29:28.360> that<01:29:28.800> it<01:29:29.000> waited 01:29:29.310 --> 01:29:29.320 align:start position:0% picked up on the fact that it waited 01:29:29.320 --> 01:29:30.669 align:start position:0% picked up on the fact that it waited long<01:29:29.520> enough<01:29:29.719> and<01:29:29.840> it's<01:29:30.040> now<01:29:30.239> allowed<01:29:30.520> to 01:29:30.669 --> 01:29:30.679 align:start position:0% long enough and it's now allowed to 01:29:30.679 --> 01:29:32.990 align:start position:0% long enough and it's now allowed to claim<01:29:31.119> the<01:29:31.280> reward<01:29:31.639> for<01:29:31.800> that<01:29:32.000> request<01:29:32.760> and<01:29:32.880> it 01:29:32.990 --> 01:29:33.000 align:start position:0% claim the reward for that request and it 01:29:33.000 --> 01:29:34.750 align:start position:0% claim the reward for that request and it generated<01:29:33.480> this<01:29:33.719> massive<01:29:34.040> storage<01:29:34.440> proof 01:29:34.750 --> 01:29:34.760 align:start position:0% generated this massive storage proof 01:29:34.760 --> 01:29:38.550 align:start position:0% generated this massive storage proof here<01:29:35.600> and<01:29:35.800> submitted<01:29:36.239> that<01:29:36.360> storage<01:29:36.719> proof<01:29:37.560> to 01:29:38.550 --> 01:29:38.560 align:start position:0% here and submitted that storage proof to 01:29:38.560 --> 01:29:40.350 align:start position:0% here and submitted that storage proof to the<01:29:38.760> outbox<01:29:39.280> contract<01:29:39.639> on<01:29:39.760> the<01:29:39.880> mock<01:29:40.119> base 01:29:40.350 --> 01:29:40.360 align:start position:0% the outbox contract on the mock base 01:29:40.360 --> 01:29:42.350 align:start position:0% the outbox contract on the mock base chain<01:29:40.920> and<01:29:41.239> everything<01:29:41.560> was<01:29:41.719> successful<01:29:42.199> so 01:29:42.350 --> 01:29:42.360 align:start position:0% chain and everything was successful so 01:29:42.360 --> 01:29:44.149 align:start position:0% chain and everything was successful so this<01:29:42.440> was<01:29:42.679> validated<01:29:43.239> against<01:29:43.560> the<01:29:43.760> prover 01:29:44.149 --> 01:29:44.159 align:start position:0% this was validated against the prover 01:29:44.159 --> 01:29:47.669 align:start position:0% this was validated against the prover contract<01:29:44.639> that<01:29:44.760> we<01:29:44.920> just<01:29:45.400> implemented 01:29:47.669 --> 01:29:47.679 align:start position:0% contract that we just implemented 01:29:47.679 --> 01:29:52.390 align:start position:0% contract that we just implemented um<01:29:48.679> and<01:29:48.800> so<01:29:49.040> if<01:29:49.119> you<01:29:49.280> take<01:29:49.440> a<01:29:49.679> look<01:29:50.239> in<01:29:51.239> the 01:29:52.390 --> 01:29:52.400 align:start position:0% um and so if you take a look in the 01:29:52.400 --> 01:29:56.109 align:start position:0% um and so if you take a look in the fulfiller<01:29:53.400> directory<01:29:53.880> here<01:29:54.480> here<01:29:55.480> um<01:29:55.880> after 01:29:56.109 --> 01:29:56.119 align:start position:0% fulfiller directory here here um after 01:29:56.119 --> 01:29:59.229 align:start position:0% fulfiller directory here here um after that<01:29:56.320> ran<01:29:57.199> it<01:29:57.440> logged<01:29:57.920> the<01:29:58.119> proof<01:29:58.440> into<01:29:58.679> a<01:29:58.800> Json 01:29:59.229 --> 01:29:59.239 align:start position:0% that ran it logged the proof into a Json 01:29:59.239 --> 01:30:00.950 align:start position:0% that ran it logged the proof into a Json file<01:29:59.520> so<01:29:59.639> you<01:29:59.719> can<01:29:59.880> see<01:30:00.280> exactly<01:30:00.719> what<01:30:00.800> the 01:30:00.950 --> 01:30:00.960 align:start position:0% file so you can see exactly what the 01:30:00.960 --> 01:30:04.109 align:start position:0% file so you can see exactly what the proof<01:30:01.239> was<01:30:01.440> that<01:30:01.520> it<01:30:01.639> used<01:30:02.199> to<01:30:02.840> um<01:30:03.600> verify<01:30:04.000> that 01:30:04.109 --> 01:30:04.119 align:start position:0% proof was that it used to um verify that 01:30:04.119 --> 01:30:05.510 align:start position:0% proof was that it used to um verify that the<01:30:04.199> call<01:30:04.360> was<01:30:04.480> submitted<01:30:05.080> so<01:30:05.239> that's<01:30:05.360> what 01:30:05.510 --> 01:30:05.520 align:start position:0% the call was submitted so that's what 01:30:05.520 --> 01:30:08.270 align:start position:0% the call was submitted so that's what this<01:30:05.679> file<01:30:05.960> is<01:30:06.880> and<01:30:07.000> then<01:30:07.199> inside<01:30:07.480> of<01:30:07.600> the<01:30:07.719> SRC 01:30:08.270 --> 01:30:08.280 align:start position:0% this file is and then inside of the SRC 01:30:08.280 --> 01:30:10.750 align:start position:0% this file is and then inside of the SRC directory<01:30:09.080> there's<01:30:09.320> a<01:30:09.600> database<01:30:10.119> directory 01:30:10.750 --> 01:30:10.760 align:start position:0% directory there's a database directory 01:30:10.760 --> 01:30:13.870 align:start position:0% directory there's a database directory that<01:30:10.880> is<01:30:11.000> storing<01:30:11.760> uh<01:30:11.920> db.<01:30:12.520> Json<01:30:13.360> which<01:30:13.760> this 01:30:13.870 --> 01:30:13.880 align:start position:0% that is storing uh db. Json which this 01:30:13.880 --> 01:30:15.470 align:start position:0% that is storing uh db. Json which this is<01:30:14.080> the<01:30:14.280> representation<01:30:14.920> of<01:30:15.040> the<01:30:15.159> request 01:30:15.470 --> 01:30:15.480 align:start position:0% is the representation of the request 01:30:15.480 --> 01:30:17.709 align:start position:0% is the representation of the request that<01:30:15.560> it<01:30:15.679> picked<01:30:15.920> up<01:30:16.040> on<01:30:16.840> um<01:30:17.000> that<01:30:17.080> we<01:30:17.239> just 01:30:17.709 --> 01:30:17.719 align:start position:0% that it picked up on um that we just 01:30:17.719 --> 01:30:20.590 align:start position:0% that it picked up on um that we just submitted<01:30:18.719> and<01:30:18.840> then<01:30:19.080> it<01:30:19.239> has<01:30:19.360> a<01:30:19.520> rewards<01:30:20.000> file 01:30:20.590 --> 01:30:20.600 align:start position:0% submitted and then it has a rewards file 01:30:20.600 --> 01:30:22.870 align:start position:0% submitted and then it has a rewards file that<01:30:20.719> it's<01:30:21.000> tracking<01:30:21.560> how<01:30:21.719> many<01:30:22.400> how<01:30:22.480> much<01:30:22.639> eat 01:30:22.870 --> 01:30:22.880 align:start position:0% that it's tracking how many how much eat 01:30:22.880 --> 01:30:24.510 align:start position:0% that it's tracking how many how much eat that<01:30:23.000> it's<01:30:23.119> claimed<01:30:23.400> in<01:30:23.520> Rewards 01:30:24.510 --> 01:30:24.520 align:start position:0% that it's claimed in Rewards 01:30:24.520 --> 01:30:27.750 align:start position:0% that it's claimed in Rewards so<01:30:25.520> we<01:30:25.719> have<01:30:25.880> a<01:30:26.040> locally<01:30:26.440> running<01:30:27.040> like<01:30:27.280> fully 01:30:27.750 --> 01:30:27.760 align:start position:0% so we have a locally running like fully 01:30:27.760 --> 01:30:30.070 align:start position:0% so we have a locally running like fully working<01:30:28.360> system<01:30:29.000> uh<01:30:29.119> end<01:30:29.320> to 01:30:30.070 --> 01:30:30.080 align:start position:0% working system uh end to 01:30:30.080 --> 01:30:35.990 align:start position:0% working system uh end to end<01:30:31.440> wo<01:30:32.840> um<01:30:34.080> yeah<01:30:35.080> and<01:30:35.199> I'm<01:30:35.360> realizing<01:30:35.840> right 01:30:35.990 --> 01:30:36.000 align:start position:0% end wo um yeah and I'm realizing right 01:30:36.000 --> 01:30:37.870 align:start position:0% end wo um yeah and I'm realizing right now<01:30:36.320> that<01:30:36.600> the<01:30:36.880> reward<01:30:37.239> tracking<01:30:37.600> is<01:30:37.719> not 01:30:37.870 --> 01:30:37.880 align:start position:0% now that the reward tracking is not 01:30:37.880 --> 01:30:39.189 align:start position:0% now that the reward tracking is not accounting<01:30:38.159> for<01:30:38.400> gas<01:30:38.719> cost<01:30:38.960> on<01:30:39.080> the 01:30:39.189 --> 01:30:39.199 align:start position:0% accounting for gas cost on the 01:30:39.199 --> 01:30:41.430 align:start position:0% accounting for gas cost on the destination<01:30:39.600> chain<01:30:40.119> but<01:30:40.639> um<01:30:40.760> nonetheless<01:30:41.280> you 01:30:41.430 --> 01:30:41.440 align:start position:0% destination chain but um nonetheless you 01:30:41.440 --> 01:30:43.109 align:start position:0% destination chain but um nonetheless you get<01:30:41.639> the<01:30:41.800> you<01:30:41.960> get<01:30:42.080> the 01:30:43.109 --> 01:30:43.119 align:start position:0% get the you get the 01:30:43.119 --> 01:30:47.109 align:start position:0% get the you get the idea<01:30:44.119> so<01:30:44.800> that<01:30:45.119> just<01:30:45.360> about<01:30:45.960> does<01:30:46.159> it<01:30:46.840> um<01:30:47.040> if 01:30:47.109 --> 01:30:47.119 align:start position:0% idea so that just about does it um if 01:30:47.119 --> 01:30:49.510 align:start position:0% idea so that just about does it um if you<01:30:47.280> take<01:30:47.440> a<01:30:47.600> look<01:30:47.840> here<01:30:48.360> yeah<01:30:48.560> like<01:30:48.719> I<01:30:48.840> said<01:30:49.400> uh 01:30:49.510 --> 01:30:49.520 align:start position:0% you take a look here yeah like I said uh 01:30:49.520 --> 01:30:51.390 align:start position:0% you take a look here yeah like I said uh if<01:30:49.600> we<01:30:49.760> run<01:30:50.000> the<01:30:50.119> demo<01:30:50.520> again<01:30:50.840> we<01:30:51.000> now<01:30:51.119> see<01:30:51.320> that 01:30:51.390 --> 01:30:51.400 align:start position:0% if we run the demo again we now see that 01:30:51.400 --> 01:30:54.149 align:start position:0% if we run the demo again we now see that the<01:30:51.480> current<01:30:51.719> nft<01:30:52.040> balance<01:30:52.280> is<01:30:52.560> one<01:30:53.560> because 01:30:54.149 --> 01:30:54.159 align:start position:0% the current nft balance is one because 01:30:54.159 --> 01:30:55.870 align:start position:0% the current nft balance is one because the<01:30:54.360> the<01:30:54.480> nft<01:30:54.960> was<01:30:55.159> actually<01:30:55.360> minted<01:30:55.679> on<01:30:55.760> the 01:30:55.870 --> 01:30:55.880 align:start position:0% the the nft was actually minted on the 01:30:55.880 --> 01:30:58.030 align:start position:0% the the nft was actually minted on the destination<01:30:56.320> chain<01:30:56.880> as<01:30:57.320> uh<01:30:57.440> defined<01:30:57.840> by<01:30:57.960> the 01:30:58.030 --> 01:30:58.040 align:start position:0% destination chain as uh defined by the 01:30:58.040 --> 01:30:59.830 align:start position:0% destination chain as uh defined by the encoded<01:30:58.400> call<01:30:58.600> data<01:30:58.880> that<01:30:59.000> we<01:30:59.080> set<01:30:59.239> up<01:30:59.440> for<01:30:59.600> the 01:30:59.830 --> 01:30:59.840 align:start position:0% encoded call data that we set up for the 01:30:59.840 --> 01:31:02.470 align:start position:0% encoded call data that we set up for the Target<01:31:00.560> calls<01:31:01.560> um<01:31:01.679> and<01:31:01.760> then<01:31:01.880> so<01:31:02.040> if<01:31:02.080> we<01:31:02.199> run<01:31:02.320> it 01:31:02.470 --> 01:31:02.480 align:start position:0% Target calls um and then so if we run it 01:31:02.480 --> 01:31:04.750 align:start position:0% Target calls um and then so if we run it again<01:31:02.800> now<01:31:03.080> it<01:31:03.159> would<01:31:03.400> be<01:31:04.040> just<01:31:04.239> incrementing 01:31:04.750 --> 01:31:04.760 align:start position:0% again now it would be just incrementing 01:31:04.760 --> 01:31:09.030 align:start position:0% again now it would be just incrementing from<01:31:05.360> there<01:31:06.360> so<01:31:06.719> that<01:31:07.080> does<01:31:07.280> it<01:31:07.440> for<01:31:07.639> the<01:31:08.040> demo 01:31:09.030 --> 01:31:09.040 align:start position:0% from there so that does it for the demo 01:31:09.040 --> 01:31:11.590 align:start position:0% from there so that does it for the demo thank<01:31:09.239> you<01:31:09.480> everyone<01:31:10.000> for<01:31:10.719> coming<01:31:11.280> and<01:31:11.440> I'll 01:31:11.590 --> 01:31:11.600 align:start position:0% thank you everyone for coming and I'll 01:31:11.600 --> 01:31:12.870 align:start position:0% thank you everyone for coming and I'll be<01:31:11.719> hanging<01:31:12.000> around<01:31:12.239> for<01:31:12.360> a<01:31:12.440> little<01:31:12.639> bit<01:31:12.760> if 01:31:12.870 --> 01:31:12.880 align:start position:0% be hanging around for a little bit if 01:31:12.880 --> 01:31:14.470 align:start position:0% be hanging around for a little bit if anyone<01:31:13.199> has<01:31:13.400> questions<01:31:13.880> or<01:31:14.040> if<01:31:14.119> you<01:31:14.199> want<01:31:14.320> to 01:31:14.470 --> 01:31:14.480 align:start position:0% anyone has questions or if you want to 01:31:14.480 --> 01:31:16.830 align:start position:0% anyone has questions or if you want to chat<01:31:15.400> um<01:31:15.520> the<01:31:15.639> standard<01:31:16.000> a<01:31:16.080> little<01:31:16.239> bit<01:31:16.400> more 01:31:16.830 --> 01:31:16.840 align:start position:0% chat um the standard a little bit more 01:31:16.840 --> 01:31:18.629 align:start position:0% chat um the standard a little bit more like<01:31:16.960> I<01:31:17.080> said<01:31:17.239> we<01:31:17.400> have<01:31:17.480> an<01:31:17.600> open<01:31:17.880> source<01:31:18.199> repo 01:31:18.629 --> 01:31:18.639 align:start position:0% like I said we have an open source repo 01:31:18.639 --> 01:31:20.470 align:start position:0% like I said we have an open source repo for<01:31:18.920> proof<01:31:19.119> of<01:31:19.280> concept<01:31:19.719> here<01:31:19.920> so<01:31:20.080> if<01:31:20.199> anyone 01:31:20.470 --> 01:31:20.480 align:start position:0% for proof of concept here so if anyone 01:31:20.480 --> 01:31:22.830 align:start position:0% for proof of concept here so if anyone feels<01:31:20.800> compelled<01:31:21.280> to<01:31:21.880> contribute<01:31:22.440> we<01:31:22.560> fully 01:31:22.830 --> 01:31:22.840 align:start position:0% feels compelled to contribute we fully 01:31:22.840 --> 01:31:27.260 align:start position:0% feels compelled to contribute we fully invite<01:31:23.119> you<01:31:23.239> to<01:31:23.719> uh<01:31:24.320> contribute<01:31:24.920> so<01:31:25.520> thank 01:31:27.260 --> 01:31:27.270 align:start position:0% invite you to uh contribute so thank 01:31:27.270 --> 01:31:52.830 align:start position:0% invite you to uh contribute so thank [Applause] 01:31:52.830 --> 01:31:52.840 align:start position:0% 01:31:52.840 --> 01:31:56.880 align:start position:0% you<01:31:53.880> for