1 00:00:00,480 --> 00:00:04,640 If Web 3 needs to scale to the scale of Internet, the only way 2 00:00:04,640 --> 00:00:09,480 it scales is through ZK, and we have our all our bets on ZK. 3 00:00:09,600 --> 00:00:12,280 The biggest problem facing Etherium and facing Etherium's 4 00:00:12,280 --> 00:00:15,000 ability to scale is fragmentation of L twos. 5 00:00:15,040 --> 00:00:18,440 Because right now we have this proliferation of L twos, but 6 00:00:18,840 --> 00:00:21,240 liquidity is not shared between those L twos. 7 00:00:21,240 --> 00:00:23,360 State is not easily shared between those L twos. 8 00:00:23,560 --> 00:00:26,320 Like users have a difficult time moving between those L twos. 9 00:00:26,520 --> 00:00:30,920 What Polygon is building is basically a guarantee of safety 10 00:00:31,320 --> 00:00:35,120 for a shared bridge, which allows different L twos to have 11 00:00:35,120 --> 00:00:37,720 asset fungibility between their chains. 12 00:00:37,920 --> 00:00:41,680 L twos are submitting blocks to the AG layer, and the Ag layer 13 00:00:41,680 --> 00:00:45,480 is proving to Ethereum that all of these properties hold. 14 00:00:59,720 --> 00:01:01,680 This episode is brought to you by Gnosis. 15 00:01:02,240 --> 00:01:05,400 Gnosis builds decentralized infrastructure for the Ethereum 16 00:01:05,480 --> 00:01:08,240 ecosystem. With a rich history dating back 17 00:01:08,240 --> 00:01:13,840 to 2015 and products like Safe Cow Swap or Gnosis Chain, Gnosis 18 00:01:13,840 --> 00:01:17,800 combines needs driven development with deep technical 19 00:01:17,800 --> 00:01:21,040 expertise. This year marks the launch of 20 00:01:21,040 --> 00:01:24,400 Gnosis Pay, the world's first decentralized payment network. 21 00:01:25,120 --> 00:01:29,320 With a Gnosis card, you can spend self custody crypto at any 22 00:01:29,320 --> 00:01:31,560 Visa accepting merchant around the world. 23 00:01:32,240 --> 00:01:35,640 If you're an individual looking to live more on chain or 24 00:01:35,640 --> 00:01:39,760 business looking to white label the stack, visit gnosispay.com. 25 00:01:40,640 --> 00:01:43,640 There are lots of ways you can join the Gnosis journey. 26 00:01:44,040 --> 00:01:47,760 Drop in the Gnosis Dow governance form, become a Gnosis 27 00:01:47,760 --> 00:01:51,960 validator with a single GNO token and low cost hardware, or 28 00:01:51,960 --> 00:01:55,400 deploy your product on the EVM compatible and highly 29 00:01:55,400 --> 00:02:00,160 decentralized Gnosis chain. Get started today at gnosis dot 30 00:02:00,200 --> 00:02:03,920 IO. Course One is one of the biggest 31 00:02:03,920 --> 00:02:07,960 node operators globally and help you stake your tokens on 45 plus 32 00:02:07,960 --> 00:02:11,520 networks like Ethereum, Cosmos, Celestia and Dydx. 33 00:02:12,880 --> 00:02:16,320 More than 100,000 delegators stake with Chorus One, including 34 00:02:16,320 --> 00:02:18,800 institutions like BIT, Go and Ledger. 35 00:02:19,280 --> 00:02:23,320 Staking with Chorus One not only gets you the highest years, but 36 00:02:23,320 --> 00:02:27,240 also the most robust security practices and infrastructure 37 00:02:27,480 --> 00:02:29,720 that are usually exclusive for institutions. 38 00:02:30,600 --> 00:02:33,600 You can stake directly to Chorus One's public note from your 39 00:02:33,600 --> 00:02:36,760 wallet, set up a white label note, or use the recently 40 00:02:36,760 --> 00:02:41,520 launched product Opus to stake up to 8000 ETH in a single 41 00:02:41,520 --> 00:02:44,560 transaction. You can even offer high yield 42 00:02:44,560 --> 00:02:47,920 staking to your own customers using their API. 43 00:02:48,240 --> 00:02:51,040 Your assets always remain in your custody so you can have 44 00:02:51,040 --> 00:02:55,280 complete Peace of Mind. Start staking today at Corus .1. 45 00:02:56,120 --> 00:02:58,680 Welcome to Epicentre, the show which talks about the 46 00:02:58,680 --> 00:03:01,560 technologies, projects and people driving decentralization 47 00:03:01,560 --> 00:03:04,640 and the blockchain revolution. I'm Frederica Anst and today I'm 48 00:03:04,640 --> 00:03:07,800 speaking with Brandon Farmer and Sandeep Nawal who are the Co 49 00:03:07,800 --> 00:03:11,880 founders of Polygon. Sandeep and Brandon, thank you 50 00:03:11,880 --> 00:03:15,800 so much for coming on. Sandeep, you have been on 51 00:03:15,800 --> 00:03:19,720 multiple times before, so let's start with Brandon today. 52 00:03:20,080 --> 00:03:24,640 Brandon, you are a Co founder of Polygon by way of having founded 53 00:03:24,640 --> 00:03:27,440 Mir Protocol which was then acquired by Polygon. 54 00:03:28,000 --> 00:03:30,600 Tell us about Mir. Yeah. 55 00:03:30,600 --> 00:03:36,120 So Mir was a, it was an L1 that was trying to use ZK for privacy 56 00:03:36,120 --> 00:03:39,640 and scalability. And so we started Mirror in 2019 57 00:03:39,640 --> 00:03:44,920 and by 2021 really realized that we did not want to build an L1 58 00:03:44,920 --> 00:03:47,080 and wanted to build in the Ethereum ecosystem. 59 00:03:47,280 --> 00:03:51,560 And Sandeep and Mahilo and and the Polygon founders were, you 60 00:03:51,560 --> 00:03:54,960 know, gracious enough to, to offer us a, a platform to do 61 00:03:54,960 --> 00:03:57,720 that. Yeah, super nice. 62 00:03:57,720 --> 00:04:02,640 So Sandeep, during that time frame, you guys acquired quite a 63 00:04:02,680 --> 00:04:06,240 few CK teams. Maybe let's talk about that for 64 00:04:06,240 --> 00:04:08,120 a while. So, so I mean the other very 65 00:04:08,120 --> 00:04:12,360 well known one is a mess, but I think there were there were a 66 00:04:12,400 --> 00:04:14,520 couple of other ones as well, right? 67 00:04:16,760 --> 00:04:22,920 Yeah, like there was like Hermes and you know, the like male 68 00:04:22,920 --> 00:04:26,800 protocol and then other was not an acquisition, more of a equi 69 00:04:26,800 --> 00:04:31,320 hire like was the Facebook's Winterfell project, which is 70 00:04:31,320 --> 00:04:33,040 like, you know, which became Polygon Maiden. 71 00:04:33,480 --> 00:04:39,440 Even now, you know, we decently finished the acquisition of 72 00:04:39,440 --> 00:04:45,560 Topos where who is also one of the, you know, one of the 73 00:04:45,560 --> 00:04:48,480 leading companies who are working on this aggregation 74 00:04:48,480 --> 00:04:51,320 thesis. And you know, we have been 75 00:04:51,320 --> 00:04:55,200 working very closely on our code base and the fun part is like 76 00:04:55,200 --> 00:05:00,240 now Polygon ZK is like so deep into the, into the whole 77 00:05:00,360 --> 00:05:05,480 ecosystem, whether it's like succinct SP1 building on Plonky 78 00:05:05,480 --> 00:05:10,040 3 or like, you know, different, different protocols using either 79 00:05:10,040 --> 00:05:13,680 directly using the open source code or get, you know, their 80 00:05:13,680 --> 00:05:16,160 architectures fully, you know, inspired by that. 81 00:05:16,440 --> 00:05:18,760 So we are already doing a lot of stuff. 82 00:05:18,760 --> 00:05:21,960 So Toposphere was also like one of the teams was working on our 83 00:05:21,960 --> 00:05:25,680 code base and thinking about like a more of an aggregated, 84 00:05:26,320 --> 00:05:28,120 you know, future the way we were thinking. 85 00:05:28,120 --> 00:05:31,520 And it was like it made a total sense to, you know, bring them 86 00:05:31,560 --> 00:05:35,440 in, especially related to the Type 1 prover that we have and 87 00:05:35,440 --> 00:05:38,400 things like that. So yeah, that has been like a 88 00:05:38,400 --> 00:05:42,320 long journey because we are absolutely clear that, you know, 89 00:05:42,320 --> 00:05:46,440 if Web 3 needs to scale to the scale of Internet, the only way 90 00:05:46,440 --> 00:05:51,320 it scales is through ZK and we have our all our bets on ZK. 91 00:05:52,520 --> 00:05:54,800 Yeah. And I think those were very good 92 00:05:55,000 --> 00:05:57,920 beds to place. You're kind of bringing a lot of 93 00:05:57,920 --> 00:06:02,240 the research you have done over the years together in this thing 94 00:06:02,240 --> 00:06:05,640 called aggregation layer that you launched earlier this year. 95 00:06:06,040 --> 00:06:09,000 Can you set the stage here? So what what what's aggregation 96 00:06:09,000 --> 00:06:10,960 layer? What problems are you looking to 97 00:06:10,960 --> 00:06:14,280 solve with it? Yeah, sure I can. 98 00:06:14,320 --> 00:06:18,520 I can take that. So the way that we see the world 99 00:06:18,680 --> 00:06:22,320 is that that the biggest problem facing Etherium and facing 100 00:06:22,320 --> 00:06:25,400 Etherium's ability to scale is fragmentation of L twos. 101 00:06:25,480 --> 00:06:28,880 Because right now we have this proliferation of L twos, but 102 00:06:29,240 --> 00:06:32,360 liquidity is not shared between those L twos, State is not 103 00:06:32,360 --> 00:06:33,800 easily shared between those L twos. 104 00:06:34,000 --> 00:06:36,760 Like users have a difficult time moving between those L twos. 105 00:06:37,120 --> 00:06:40,640 And so we are scaling Etherium by adding additional block 106 00:06:40,640 --> 00:06:43,560 space, but we aren't scaling Etherium in the sense that we're 107 00:06:43,560 --> 00:06:47,680 not scaling access to liquidity into shared state. 108 00:06:48,760 --> 00:06:52,680 Like if you think about like, you know, the, the value that's 109 00:06:52,680 --> 00:06:56,200 bridged to arbitrary, that doesn't help optimism. 110 00:06:56,200 --> 00:06:58,360 It doesn't help other L2's and it doesn't help the, the 111 00:06:58,360 --> 00:07:00,880 Ethereum L1. And so right now we're in this 112 00:07:00,880 --> 00:07:04,560 mode where everyone is basically trying to build their own like 113 00:07:04,680 --> 00:07:08,240 mini copy of Ethereum where there's sort of liquidity and, 114 00:07:08,240 --> 00:07:10,080 and bridge value and defy activity. 115 00:07:11,000 --> 00:07:14,760 But we're not able to contribute to Etherium's network effects 116 00:07:14,760 --> 00:07:18,440 globally and, and, and to contribute to, to like the 117 00:07:18,440 --> 00:07:21,680 overall way that, that Etherium functions for users and 118 00:07:21,680 --> 00:07:23,720 developers. And so the ag layer is an 119 00:07:23,720 --> 00:07:26,200 attempt to, to fix fragmentation on Etheria. 120 00:07:26,200 --> 00:07:30,080 It's an attempt to make it really easy for users to to move 121 00:07:30,080 --> 00:07:35,360 state and value and liquidity between L2 chains so that we can 122 00:07:35,360 --> 00:07:38,480 have like a horizontally scalable ecosystem for an 123 00:07:38,480 --> 00:07:41,720 execution layer for Etherium, but one in which we're able to 124 00:07:41,720 --> 00:07:45,040 scale access to to liquidity insurance. 125 00:07:45,040 --> 00:07:48,440 That basically like a multi chain ecosystem that feels like 126 00:07:48,440 --> 00:07:51,600 you're still using a single chin where we have composability and 127 00:07:51,960 --> 00:07:54,000 and all these nice properties that we like on that one. 128 00:07:54,920 --> 00:07:57,720 OK. So basically, if I kind of take 129 00:07:57,720 --> 00:08:03,360 one step back, what you're saying is say I am a user on 130 00:08:03,360 --> 00:08:05,960 base and I want to do something on Arbitrum. 131 00:08:06,560 --> 00:08:09,920 The way that I kind of get from base to Arbitrum, despite the 132 00:08:09,920 --> 00:08:13,520 fact that they're both layer twos on this shared security 133 00:08:13,520 --> 00:08:18,360 layer of Etherium is by kind of exiting to Etherium at the cost 134 00:08:18,360 --> 00:08:21,960 of kind of doing a transaction on mainnet, which is notoriously 135 00:08:21,960 --> 00:08:26,920 expensive, and then kind of moving into the other L2. 136 00:08:27,480 --> 00:08:32,120 And there's no way for me to kind of laterally move from base 137 00:08:32,120 --> 00:08:34,640 to Arbitrum. And that's what we're fixing. 138 00:08:34,640 --> 00:08:36,960 Is that correct? Yeah, exactly. 139 00:08:36,960 --> 00:08:40,760 So, so exactly like you said, like like suppose that I have 140 00:08:40,760 --> 00:08:44,760 some ETH on base and there's like an NFT mint on Arbitrum and 141 00:08:44,760 --> 00:08:47,800 I want to be able to claim an NFT from that mint, There are 142 00:08:47,800 --> 00:08:52,200 two things that I can do, right. So the first is I can withdraw 143 00:08:52,200 --> 00:08:57,800 my ETH through the native bridge on base and then submit an L1 144 00:08:57,800 --> 00:08:59,800 transaction and deposit into Arbitrum. 145 00:09:00,760 --> 00:09:03,480 Obviously the problem is that base is an optimistic roll up 146 00:09:03,480 --> 00:09:06,800 and it takes seven days for me to withdraw via the native 147 00:09:06,800 --> 00:09:09,640 bridge and then I have to wait for that transaction to be 148 00:09:09,640 --> 00:09:11,600 finalized. I have to wait for my deposit to 149 00:09:11,600 --> 00:09:14,640 arbitrary to be finalized and the L1 transaction is expensive. 150 00:09:15,920 --> 00:09:18,520 Some of this gets a little better with ZK roll ups because 151 00:09:18,520 --> 00:09:22,120 we have a much shorter window where users can withdraw funds. 152 00:09:22,520 --> 00:09:25,320 But fundamentally like it's not good enough. 153 00:09:25,320 --> 00:09:29,120 Like we, we, we need a way for users to be able to take their 154 00:09:29,200 --> 00:09:33,800 ETH, they're native ETH on some L2 and instantly bridge it over 155 00:09:33,920 --> 00:09:40,320 to, to Arbitrum and get native ETH and be able to do things on 156 00:09:40,320 --> 00:09:43,240 that chain. The second option that users can 157 00:09:43,240 --> 00:09:46,800 do is that they can withdraw via third party bridge. 158 00:09:46,880 --> 00:09:49,560 So there are third party bridges that connect different L2 159 00:09:49,560 --> 00:09:51,920 chains. But the problem here is like the 160 00:09:51,920 --> 00:09:55,040 trust assumption for using a third party bridge is much, much 161 00:09:55,040 --> 00:09:59,040 different, and there's a requirement for users to rely on 162 00:09:59,120 --> 00:10:02,920 liquidity providers and market makers to basically swap from 163 00:10:02,920 --> 00:10:04,760 the wrapped synthetic version of a token. 164 00:10:04,760 --> 00:10:08,080 So let's say I use wormhole to bridge from base to Arbitrum. 165 00:10:08,400 --> 00:10:12,160 I get wormhole wrap teeth on Arbitrum and I have to pay some 166 00:10:12,160 --> 00:10:15,480 amount of money to swap that into Arbitrum native ETH so that 167 00:10:15,480 --> 00:10:18,280 I can claim my retainment. And So what we can think about 168 00:10:18,280 --> 00:10:21,080 the Agglera is doing is providing two things. 169 00:10:21,120 --> 00:10:23,080 So the first is asset fungibility. 170 00:10:23,400 --> 00:10:26,400 You should be able to take your assets and move them between 171 00:10:26,400 --> 00:10:29,840 chains without having to rely on a market maker or liquidity 172 00:10:29,840 --> 00:10:31,760 provider. And you should be able to do 173 00:10:31,760 --> 00:10:36,440 this safely at super super low latency, even lower than like 174 00:10:36,840 --> 00:10:39,320 etherium block time or etherium finality. 175 00:10:40,960 --> 00:10:44,040 OK, I I understand the goal in here. 176 00:10:45,200 --> 00:10:46,480 How? How do you make it work? 177 00:10:47,160 --> 00:10:49,440 Sure. So this is a good question and 178 00:10:49,440 --> 00:10:53,720 and sad me if I'm getting two in the weeds, but what Polygon is 179 00:10:53,720 --> 00:10:58,600 building is basically a guarantee of safety for a shared 180 00:10:58,600 --> 00:11:02,440 bridge which allows different L twos to have asset fungibility 181 00:11:02,960 --> 00:11:06,280 between their chains. So, so this is what allows us to 182 00:11:06,280 --> 00:11:09,400 avoid making an L1 transaction when we move funds. 183 00:11:09,400 --> 00:11:13,640 We can just take L1 native ETH and move it between chains and 184 00:11:13,640 --> 00:11:18,040 we never have to touch the L1. And the second thing is it 185 00:11:18,040 --> 00:11:21,160 allows us to provide this cryptographic guarantee of 186 00:11:21,160 --> 00:11:27,040 safety so that chains that are interoperating at lower latency 187 00:11:27,280 --> 00:11:29,560 than like even Ethereum block time. 188 00:11:29,560 --> 00:11:32,320 But certainly the time that it takes to finalize an Ethereum 189 00:11:32,320 --> 00:11:36,960 block aren't at risk of some sort of malicious behavior like 190 00:11:36,960 --> 00:11:40,640 a chain can't equivocate or a shared sequencer can't, you 191 00:11:40,640 --> 00:11:43,160 know, lie about the messages that are sent between chains. 192 00:11:44,240 --> 00:11:47,360 And so the ag layer fundamentally is like this very, 193 00:11:47,360 --> 00:11:50,880 very minimal guarantee of safety for the shared bridge and for 194 00:11:50,880 --> 00:11:54,520 interoperability. And it provides a foundation for 195 00:11:54,720 --> 00:11:57,120 what we call emergent coordination infrastructure. 196 00:11:57,280 --> 00:12:00,360 So the way that chains interoperate is up to them. 197 00:12:00,440 --> 00:12:04,600 They could use a shared sequencer or relay or, you know, 198 00:12:04,600 --> 00:12:09,080 a builder. And these mechanisms benefit 199 00:12:09,080 --> 00:12:12,360 from the shared bridge and the safety guarantees the AG layer 200 00:12:12,360 --> 00:12:15,640 provides. So like that, like, like one 201 00:12:15,640 --> 00:12:17,200 case would be for a shared sequencer. 202 00:12:18,640 --> 00:12:22,000 If users wanted like synchronous composability between chains, 203 00:12:22,400 --> 00:12:25,160 they could opt in to using the same shared sequencer. 204 00:12:25,600 --> 00:12:30,160 And that shared sequencer would allow the same block builder to 205 00:12:30,160 --> 00:12:32,760 simultaneously build blocks across chains. 206 00:12:32,920 --> 00:12:38,720 So a user could submit a transaction on on 1L2 to move 207 00:12:38,720 --> 00:12:41,960 funds and and claim the mint on another chain and then swap back 208 00:12:41,960 --> 00:12:47,280 to the original chain or you know, access some key store 209 00:12:47,280 --> 00:12:50,960 that's located on 1/3 chain. And the builder could do all of 210 00:12:50,960 --> 00:12:53,920 this simultaneously. And the ag layer would guarantee 211 00:12:53,920 --> 00:12:58,640 that for all of these chains, the builder can't misbehave and 212 00:12:58,880 --> 00:13:03,040 asset fungibility is guaranteed. And so that's sort of like the 213 00:13:03,040 --> 00:13:04,520 way that we can think about this work it. 214 00:13:05,640 --> 00:13:09,200 But would that mean that the builder kind of any builder kind 215 00:13:09,200 --> 00:13:14,000 of to to to build the next block would actually have to opt into 216 00:13:14,480 --> 00:13:20,440 all of these chains? So kind of if if I want to start 217 00:13:20,440 --> 00:13:25,040 transaction on base and that kind of bridges to Arbitrum and 218 00:13:25,040 --> 00:13:30,520 then back in one in one transaction, the the the builder 219 00:13:30,520 --> 00:13:35,480 has to support both, right? Yeah, so, so, so this is, I 220 00:13:35,480 --> 00:13:38,120 think that that we should emphasize that there are, there 221 00:13:38,120 --> 00:13:41,560 are different roles that that exist in this model that that 222 00:13:41,560 --> 00:13:43,560 maybe don't exist in the same way for L1. 223 00:13:43,960 --> 00:13:47,880 And so it in the shared sequencer case where we want, we 224 00:13:47,880 --> 00:13:50,800 have synchronous composability and and you know, this isn't 225 00:13:50,800 --> 00:13:52,520 required for all chains. Chains could operate 226 00:13:52,520 --> 00:13:56,040 asynchronously too. But in in the synchronous case, 227 00:13:56,040 --> 00:13:59,600 which is sort of the Holy Grail of composability, a builder 228 00:13:59,600 --> 00:14:04,720 would be executing transactions and producing blocks for all of 229 00:14:04,720 --> 00:14:07,200 these chains, which, which sounds bad, right? 230 00:14:07,200 --> 00:14:10,440 It, it sounds like, oh, like this can't scale, like our 231 00:14:10,440 --> 00:14:11,960 hardware requirements are going to blow up. 232 00:14:13,080 --> 00:14:16,360 But we have to distinguish between the actors that are 233 00:14:16,360 --> 00:14:20,160 building blocks that are super sophisticated. 234 00:14:20,160 --> 00:14:23,800 They might be running in data centers and, and have access to 235 00:14:23,800 --> 00:14:28,600 a large amount of hardware and the validators on L1 that that 236 00:14:28,600 --> 00:14:32,040 that can be fully, you know, have, have very minimal trust 237 00:14:32,040 --> 00:14:34,480 requirement or very minimal hardware requirements and can 238 00:14:34,480 --> 00:14:36,800 fully validate everything that happens at L2. 239 00:14:38,520 --> 00:14:42,040 I think it's up to chains, whether they're comfortable with 240 00:14:42,120 --> 00:14:45,560 this model in which we have super sophisticated builders 241 00:14:45,720 --> 00:14:48,840 that have that, that are able to operate a bunch of full nodes 242 00:14:48,840 --> 00:14:52,200 concurrently. But they still exist in this 243 00:14:52,200 --> 00:14:55,240 competitive marketplace, right? Like builders are limited in 244 00:14:55,240 --> 00:14:57,200 what they can do. They're limited in how they can 245 00:14:57,200 --> 00:15:00,680 misbehave, in the extent to which they can extract rent. 246 00:15:02,000 --> 00:15:05,000 And so I, I, I, I think we're sort of moving to this world 247 00:15:05,360 --> 00:15:11,480 where block building is just a role and a function that might 248 00:15:11,480 --> 00:15:13,960 not be accessible to everyone who's running a node on their 249 00:15:13,960 --> 00:15:19,440 laptop or a Raspberry Pi. But I wonder to what extent it's 250 00:15:19,440 --> 00:15:25,160 like a necessary step to deliver very, very good UX, at least for 251 00:15:25,160 --> 00:15:29,560 synchronous composability. Yeah, I also want to add one 252 00:15:29,560 --> 00:15:32,760 thing on that, like the question you asked from a very simple 253 00:15:32,760 --> 00:15:37,800 user's point of view that if I am let's say or in fact a chain 254 00:15:37,800 --> 00:15:40,000 point of view, right. Let's say there is a transaction 255 00:15:40,120 --> 00:15:44,600 where you know there is a cross chain transaction between three 256 00:15:44,600 --> 00:15:48,600 different chains and you want to do it in one single transaction. 257 00:15:48,600 --> 00:15:52,000 And you can actually break, you know, break it down into two 258 00:15:52,000 --> 00:15:55,560 categories, one where you really want to have it in under one 259 00:15:55,560 --> 00:15:58,600 single transaction. That means like synchronous that 260 00:15:58,600 --> 00:16:01,240 we call synchronous composability across chains. 261 00:16:01,520 --> 00:16:04,200 And that would require what Brendan was saying that some 262 00:16:04,200 --> 00:16:08,920 level of shared sequencing or like, you know, a sequencer 263 00:16:08,920 --> 00:16:12,280 marketplace where you people are the chains are selling rights 264 00:16:12,280 --> 00:16:14,240 to, you know, sequence the blocks. 265 00:16:14,240 --> 00:16:17,600 And then for these cross chain transactions, somebody who has 266 00:16:17,600 --> 00:16:20,560 the rights to all three chains, they they create the block. 267 00:16:20,920 --> 00:16:24,080 But there is another form which is a very much much simpler, 268 00:16:24,080 --> 00:16:26,280 which where Aglier is more focused on. 269 00:16:26,760 --> 00:16:30,040 And then on top of that, people can build shared sequencing kind 270 00:16:30,040 --> 00:16:34,280 of mechanisms is the asynchronous composability where 271 00:16:34,480 --> 00:16:37,640 you know, if you want to do, if your user, let's say I come to a 272 00:16:37,640 --> 00:16:42,600 user, which is let's say cannot connected to a chain, chain A 273 00:16:42,600 --> 00:16:45,160 and I do a transaction. But that transaction interacts 274 00:16:45,160 --> 00:16:49,640 with chain B and chain C in a async add layer provides you the 275 00:16:49,640 --> 00:16:53,000 mechanism or the safety guarantees that that transaction 276 00:16:53,000 --> 00:16:56,880 will go through the chain B and chain C and you will and it will 277 00:16:56,880 --> 00:16:59,520 come back to let's say some action comes back to your chain, 278 00:17:00,520 --> 00:17:04,800 but it will go asynchronously. You cannot guarantee the aglier 279 00:17:04,800 --> 00:17:07,839 doesn't guarantee you that this the entire series of transaction 280 00:17:07,839 --> 00:17:11,119 will go through with the same set of conditions that the user 281 00:17:11,119 --> 00:17:14,560 initially started with, but asynchronously. 282 00:17:14,560 --> 00:17:17,200 There are like safety guarantees that the chains are not playing 283 00:17:17,200 --> 00:17:19,280 a role in that. If the market condition, let's 284 00:17:19,280 --> 00:17:22,359 say it's a, you know, a text transaction or something, 285 00:17:22,359 --> 00:17:24,800 something changes things, that transaction might or might not 286 00:17:24,800 --> 00:17:26,599 fail. But if the conditions are 287 00:17:26,599 --> 00:17:29,200 correct, the chains will honour that transaction in a 288 00:17:29,200 --> 00:17:32,320 asynchronous way. Whereas you know, if you needed 289 00:17:33,160 --> 00:17:35,720 this synchronous one single transaction and you are 290 00:17:35,720 --> 00:17:38,120 guaranteed that the entire sequence of the transaction will 291 00:17:38,120 --> 00:17:40,720 go through for that you need some sort of shared sequencing. 292 00:17:40,720 --> 00:17:44,000 And Aglayer provides an environment where people can 293 00:17:44,000 --> 00:17:46,600 come and build the shared sequencing mechanism. 294 00:17:46,640 --> 00:17:49,440 And, and we see the world growing into a place where you 295 00:17:49,440 --> 00:17:52,840 will have we will have like Aglayer will have like hundreds 296 00:17:53,000 --> 00:17:54,680 or like, you know, not even hundreds, like I would say 297 00:17:54,680 --> 00:17:57,240 hundreds of thousands of chains connected in next 5 years. 298 00:17:57,240 --> 00:18:01,520 Like I think the space where we are heading into by the end of 299 00:18:01,520 --> 00:18:05,720 2025, only you'll probably have like 1000 chains and each 300 00:18:05,720 --> 00:18:08,240 application eventually spinning up their own chains, meaning 301 00:18:08,440 --> 00:18:12,360 like 10s of thousands of chains. And but how we see is that there 302 00:18:12,360 --> 00:18:17,440 will be like 9, a large number of that those, those chains 303 00:18:17,440 --> 00:18:20,200 connected to that layer will be individual sequence chains. 304 00:18:20,200 --> 00:18:23,760 So you can do you know, asynchronous transactions across 305 00:18:23,760 --> 00:18:27,720 other chains, whereas a few clusters of chains will be 306 00:18:27,720 --> 00:18:31,520 shared sequence chains which have much faster and synchronous 307 00:18:31,520 --> 00:18:34,160 composability across across the chains. 308 00:18:34,160 --> 00:18:37,160 And that is dependent on the use case and how those chains want 309 00:18:37,160 --> 00:18:40,880 to choose and join one somebody custodians, consortiums and all 310 00:18:40,880 --> 00:18:43,240 that is fully dependent on the use cases. 311 00:18:43,240 --> 00:18:45,680 Agglate is pretty pretty agnostic to that. 312 00:18:47,400 --> 00:18:49,400 OK. So I think there's a there. 313 00:18:49,440 --> 00:18:52,200 There's kind of like a lot to unpack here, but what I'm taking 314 00:18:52,200 --> 00:18:55,960 away from this is basically yours is your distinguishing two 315 00:18:55,960 --> 00:19:00,240 cases here. So one where kind of the 316 00:19:00,960 --> 00:19:03,080 transactions happen one after the other. 317 00:19:03,080 --> 00:19:06,120 So kind of say for instance, I bridge from chain A to chain B. 318 00:19:06,320 --> 00:19:12,640 There I swap token X for token Y, then I bridge to chain C by 319 00:19:12,640 --> 00:19:16,640 an NFT against token Y that I really want it, and then bridge 320 00:19:16,960 --> 00:19:21,040 back to to chain A. And then there's the other case 321 00:19:21,040 --> 00:19:24,640 where kind of everything where kind of all the transaction, all 322 00:19:24,640 --> 00:19:29,000 the transactions happen at once or they don't happen, right? 323 00:19:29,000 --> 00:19:32,720 Kind of what, what I would call kind of an atomic transaction, 324 00:19:32,720 --> 00:19:34,080 right? So basically you, you bundle 325 00:19:34,080 --> 00:19:36,520 everything together. So for instance, if I want to 326 00:19:36,520 --> 00:19:41,120 do, if I want to AB something, that's kind of how, how I would 327 00:19:41,120 --> 00:19:44,280 want to do it in order to kind of minimize my own risk, right? 328 00:19:44,800 --> 00:19:48,520 And you're saying that the subsequent transactions that is 329 00:19:48,520 --> 00:19:52,000 possible today with with AG layer where as kind of the 330 00:19:52,000 --> 00:19:55,400 atomic transactions that is something that would require 331 00:19:55,400 --> 00:20:00,160 shared sequencing, which is kind of very much in which is 332 00:20:00,200 --> 00:20:02,720 optional for chains to kind of opt into. 333 00:20:02,920 --> 00:20:07,080 And you kind of see specialized cases coming up where that will 334 00:20:07,080 --> 00:20:11,320 be that where that will be done. Is that more or less correct? 335 00:20:12,080 --> 00:20:14,000 Yeah, that was very well summarized to me. 336 00:20:15,080 --> 00:20:17,720 I would say like the we're, we're still working on both the 337 00:20:17,720 --> 00:20:20,160 async and the and the synchronous and atomic case. 338 00:20:21,120 --> 00:20:24,160 But yeah, I, I, I, I think that's exactly the way to frame 339 00:20:24,160 --> 00:20:26,200 it. Yeah. 340 00:20:26,440 --> 00:20:29,080 I just thought that not to get off topic, but, but I, I think 341 00:20:29,080 --> 00:20:32,560 this is sort of interesting. Like the ARP case that you 342 00:20:32,560 --> 00:20:37,080 describe, I, I think is like a really good example of, of when 343 00:20:37,080 --> 00:20:38,920 atomicity is, is really important. 344 00:20:40,000 --> 00:20:42,840 I think it's interesting to like, imagine what the world 345 00:20:42,840 --> 00:20:45,000 will look like. Like I, I, I, I'm not sure that 346 00:20:45,000 --> 00:20:48,480 every single chain in the world will be using the same shared 347 00:20:48,480 --> 00:20:50,240 sequencer and the same shared builder. 348 00:20:51,280 --> 00:20:54,680 But you could imagine, like if we're trying to scale D5 to like 349 00:20:54,680 --> 00:20:58,160 Internet scale or to like global scale, what that looks like it, 350 00:20:58,160 --> 00:21:01,840 it, it could be a bunch of different chains that are all 351 00:21:01,840 --> 00:21:05,440 providing liquidity sort of in parallel and they're all using 352 00:21:05,440 --> 00:21:08,000 the same shared sequencer. Because it's really necessary 353 00:21:08,000 --> 00:21:12,240 for, for people trying to arbitrage to be able to do 354 00:21:12,640 --> 00:21:17,640 atomic arms between chains and, and like it's, it's very, very 355 00:21:17,640 --> 00:21:20,360 important for us to be able to guarantee like within some 356 00:21:20,360 --> 00:21:25,480 slippage parameters that like either both legs of an arc go 357 00:21:25,480 --> 00:21:31,240 through or neither. And so I think like, I, I wonder 358 00:21:31,240 --> 00:21:37,400 if most of the world composes asynchronously with these sort 359 00:21:37,400 --> 00:21:42,800 of like Defy hubs, which are like synchronously connected via 360 00:21:42,800 --> 00:21:46,880 shared sequencer, or whether it's sort of synchronous 361 00:21:46,880 --> 00:21:48,760 composability becomes important for everyone. 362 00:21:48,760 --> 00:21:51,720 I, I, I, I think it's just there are a lot of open questions as 363 00:21:51,720 --> 00:21:54,520 to how the world looks with the ad clerk. 364 00:21:55,440 --> 00:22:00,520 This is kind of an aside here. I I want to get back to to the 365 00:22:00,520 --> 00:22:04,280 asynchronous case because that's kind of what works today. 366 00:22:04,960 --> 00:22:08,960 But do you think kind of in the synchronous case where you kind 367 00:22:08,960 --> 00:22:12,000 of have to have shared sequencing between different 368 00:22:12,000 --> 00:22:16,120 chains. Do you think it's it's possible 369 00:22:16,120 --> 00:22:21,040 to have a composite model where where you say every other block 370 00:22:21,040 --> 00:22:26,600 is kind of executed by synchronous sequences and every 371 00:22:26,600 --> 00:22:30,000 other block is done by regular people? 372 00:22:30,000 --> 00:22:34,920 Because obviously, or at least my concern would be that the 373 00:22:34,920 --> 00:22:39,960 hardware requirements and kind of the DevOps capabilities 374 00:22:39,960 --> 00:22:44,360 needed to kind of run the hardware behind a shared 375 00:22:44,360 --> 00:22:50,400 sequencing setup would be very difficult and not achievable for 376 00:22:50,400 --> 00:22:52,480 many people. So kind of you would have a 377 00:22:52,560 --> 00:22:57,000 small number of entities actually doing this shared 378 00:22:57,000 --> 00:23:03,920 sequencing setup, which would result in much lower censorship 379 00:23:04,760 --> 00:23:09,880 resistance then you would have with a much wider validator set. 380 00:23:10,600 --> 00:23:13,880 So do you think it's conceivable to kind of have both where you 381 00:23:13,880 --> 00:23:17,160 have like dedicated slots for shared sequencing and then kind 382 00:23:17,160 --> 00:23:20,040 of if you want to do something atomically, you wait for that 383 00:23:20,040 --> 00:23:24,840 slot and every other block is built by independent builders? 384 00:23:25,800 --> 00:23:27,640 Yeah. So I, I, I, I think that's 385 00:23:27,640 --> 00:23:30,760 definitely one approach. Another approach would just be 386 00:23:30,760 --> 00:23:33,960 to like, I, I, I think implicit in the shared sequencing 387 00:23:33,960 --> 00:23:38,640 construction is sort of a, a natural fall back where if a 388 00:23:38,640 --> 00:23:42,320 block builder goes offline or, or misbehaves or, or attempts to 389 00:23:42,320 --> 00:23:47,000 rent seek chains can always default to allowing anyone to 390 00:23:47,000 --> 00:23:49,880 produce blocks for that chain. They, they wouldn't be a 391 00:23:49,880 --> 00:23:52,920 sophisticated builder running full nodes for every chain, but 392 00:23:52,920 --> 00:23:55,680 it would sort of like fall back to the asynchronous case. 393 00:23:56,840 --> 00:24:00,080 But I think that like ultimately it's not for us to decide. 394 00:24:00,080 --> 00:24:03,240 It's, it's up to the chains. But I I do think having like 395 00:24:03,320 --> 00:24:06,400 periodic blocks that are produced that are not 396 00:24:06,720 --> 00:24:09,480 synchronously composable, it is like an interesting solution to 397 00:24:09,480 --> 00:24:12,880 sort of guarantee that there exists block producing enough 398 00:24:12,880 --> 00:24:15,360 block producing nodes to provide censorship resistance. 399 00:24:16,640 --> 00:24:19,000 Yeah, super interesting. So let's talk about the 400 00:24:19,000 --> 00:24:22,520 asynchronous case. So in my head, this currently 401 00:24:23,000 --> 00:24:27,040 takes the shape, as I would almost call it, like a unified 402 00:24:27,040 --> 00:24:29,240 bridge. Is that kind of a fair 403 00:24:29,880 --> 00:24:32,000 conception of what you're building? 404 00:24:32,720 --> 00:24:34,640 Yeah. So I would, yeah. 405 00:24:34,640 --> 00:24:37,240 So, so I, I, I would say that it has two components, right. 406 00:24:37,240 --> 00:24:40,880 So, so there's the unified bridge, which means that all L1 407 00:24:40,880 --> 00:24:44,320 and L2 native assets that are in the Agglar ecosystem are locked 408 00:24:44,320 --> 00:24:48,640 in the same contracts. So all L twos that that opt into 409 00:24:48,640 --> 00:24:52,560 the Agglar have this shared deposit contract that saves us 410 00:24:52,560 --> 00:24:56,240 from or saves them from having to submit an L1 transaction 411 00:24:56,560 --> 00:25:00,880 every time we do asset movement or asset transfer across chance. 412 00:25:02,200 --> 00:25:04,760 And so the, the interesting thing would be with the async 413 00:25:04,760 --> 00:25:10,000 case is like, so, so we had asset fungibility and we also 414 00:25:10,000 --> 00:25:11,960 really want low latency interrupt. 415 00:25:12,080 --> 00:25:16,600 So right now, like if you want to, we were talking about this 416 00:25:16,600 --> 00:25:21,040 earlier, but if you want to move assets between L twos, even if 417 00:25:21,040 --> 00:25:25,480 you have a shared bridge, there's still this like heavy 418 00:25:25,480 --> 00:25:28,360 latency penalty. Because let's say that I'm on 419 00:25:28,760 --> 00:25:32,160 roll up A and I want to move my ETH to roll up B. 420 00:25:33,280 --> 00:25:36,720 In order for roll up B to accept the message that's that 421 00:25:36,720 --> 00:25:40,720 transfers assets from roll up A to roll up B, it has to have a 422 00:25:40,720 --> 00:25:43,480 guarantee that roll up A state is finalized. 423 00:25:44,000 --> 00:25:46,360 Otherwise roll up A could equivocate. 424 00:25:46,480 --> 00:25:49,360 It could create two blocks, one of which has a transfer to roll 425 00:25:49,360 --> 00:25:54,080 up B1 of which doesn't and it could submit the the block with 426 00:25:54,080 --> 00:25:58,040 the transfer to roll up B to roll up B and it could submit 427 00:25:58,040 --> 00:26:01,000 the block without the transfer to roll up B to Ethereum to be 428 00:26:01,000 --> 00:26:06,000 settled on Ethereum. In the case in which in which we 429 00:26:06,000 --> 00:26:07,680 have to wait for finality on Etherium. 430 00:26:07,960 --> 00:26:10,360 That's a really bad user experience, right, Because we 431 00:26:10,360 --> 00:26:14,320 have this like 12 to 19 minute latency delay for for that block 432 00:26:14,320 --> 00:26:17,040 to be finalized. So instead what we can do in the 433 00:26:17,040 --> 00:26:21,320 AG layer is roll up B can declare that it has this 434 00:26:21,320 --> 00:26:23,520 dependency on some state of roll up A. 435 00:26:23,680 --> 00:26:26,280 So I can say, OK, I I've received the state of roll up A 436 00:26:26,280 --> 00:26:29,520 that includes a message telling me to mint a bunch of ETH and 437 00:26:29,520 --> 00:26:34,880 give it to this user. But like I'm going to via the AG 438 00:26:34,880 --> 00:26:39,600 layer guarantee that my roll up roll up B can only be settled to 439 00:26:39,600 --> 00:26:43,280 Ethereum if this state of roll up Bay is settled. 440 00:26:43,400 --> 00:26:46,920 And so if roll up A equivocates, roll up B would just have 441 00:26:46,920 --> 00:26:50,840 delayed settlement until it reorgs the transaction from roll 442 00:26:50,840 --> 00:26:56,480 up A out of out of its history. And so, so there's this 443 00:26:56,480 --> 00:26:59,520 potential for like, like we're we're basically prioritizing 444 00:26:59,520 --> 00:27:03,320 safety over liveness. And so there's this potential 445 00:27:03,320 --> 00:27:06,880 where if the operator of a chain misbehaves or acts maliciously, 446 00:27:08,480 --> 00:27:10,400 settlement of roll up B could be delayed. 447 00:27:11,120 --> 00:27:13,680 But fundamentally this is a necessary trade off for us to 448 00:27:13,680 --> 00:27:16,160 provide super low latency interop. 449 00:27:17,400 --> 00:27:21,360 OK, I, I, I think I understand the value proposition. 450 00:27:21,360 --> 00:27:25,440 What kind of is missing for me in in my head is how do you 451 00:27:25,440 --> 00:27:29,480 ensure the security and integrity of that AG layer? 452 00:27:29,480 --> 00:27:33,360 So kind of where does it check in or does it have collateral 453 00:27:33,360 --> 00:27:35,680 somewhere or how does it guarantee all this? 454 00:27:36,200 --> 00:27:38,760 Yeah, So it proves it cryptographically with A0 455 00:27:38,760 --> 00:27:41,720 knowledge proof. So, so like what's happening is 456 00:27:42,320 --> 00:27:46,240 L twos are submitting blocks to the AG layer and the AG layer is 457 00:27:46,240 --> 00:27:49,800 proving to Ethereum that all of these properties hold. 458 00:27:49,920 --> 00:27:54,960 So the shared bridge is protected and safe and chains 459 00:27:54,960 --> 00:27:57,480 are interoperating in a way that's consistent and no one's 460 00:27:57,480 --> 00:28:00,920 behaving maliciously. And so it's aggregating all the 461 00:28:00,920 --> 00:28:04,480 validity proofs from every single chain and also these 462 00:28:04,480 --> 00:28:07,440 additional proofs that guarantee the safety properties. 463 00:28:07,760 --> 00:28:10,120 And it's submitting all of this to Ethereum. 464 00:28:10,440 --> 00:28:12,760 And so that's where where settlement happens. 465 00:28:13,360 --> 00:28:16,080 For every block. That sounds very expensive. 466 00:28:16,880 --> 00:28:21,880 So it's not necessarily submitting, submitting to 467 00:28:21,920 --> 00:28:26,360 Ethereum on every block, but it's accepting blocks or batches 468 00:28:26,360 --> 00:28:29,560 from each roll up. And so it's not like the the 469 00:28:29,560 --> 00:28:33,400 cost of, of aggregating proofs or, or proving this is like it 470 00:28:33,400 --> 00:28:36,600 actually very, very minimal relative to like your typical 471 00:28:36,600 --> 00:28:39,600 cost for AZKVM. So like like proving AZKVM 472 00:28:39,600 --> 00:28:43,320 transaction which which we do routinely is is actually a lot 473 00:28:43,320 --> 00:28:47,520 more expensive than the the types of proofs that that the AG 474 00:28:47,520 --> 00:28:49,440 layer is creating. OK. 475 00:28:49,440 --> 00:28:52,800 But then kind of in between the check insurance or the AG layer 476 00:28:52,800 --> 00:28:56,560 into Ethereum, what security guarantees do you have in that 477 00:28:56,560 --> 00:28:58,200 interval? Yeah. 478 00:28:58,200 --> 00:29:04,440 So, so like obviously you are running the risk of, of some 479 00:29:04,440 --> 00:29:07,680 other chain misbehaving or of of the AG layer misbehaving. 480 00:29:08,600 --> 00:29:12,400 But I think fundamentally like there's a very small window 481 00:29:12,400 --> 00:29:17,720 where this can happen and the AG layer can never like settle a 482 00:29:17,720 --> 00:29:21,040 malicious action or or malicious behavior to Ethereum. 483 00:29:21,480 --> 00:29:25,840 And so the way that I look at it is like it's, it's very similar 484 00:29:25,840 --> 00:29:29,800 to how roll ups work now. So, so most people use roll ups 485 00:29:29,800 --> 00:29:32,480 and, and rely on like the pre confirmation guarantee that's 486 00:29:32,480 --> 00:29:35,760 provided by the sequencer. So the sequencer basically says 487 00:29:35,760 --> 00:29:38,800 like, OK, I'm accepting this transaction at, at very low 488 00:29:38,800 --> 00:29:40,800 latency, maybe it's like 400 milliseconds. 489 00:29:41,080 --> 00:29:44,480 And for most users, that's fine. They're, they're, they're, they 490 00:29:44,480 --> 00:29:47,800 sort of have enough trust that the sequencer is not going to 491 00:29:47,800 --> 00:29:52,120 misbehave and they're fine with operating on, on that guarantee. 492 00:29:52,560 --> 00:29:57,280 It could be the case that certain users are, are 493 00:29:57,280 --> 00:30:00,640 transacting in, in large enough amounts or, or like need a 494 00:30:00,640 --> 00:30:04,000 further guarantee. And so they wait until their 495 00:30:04,000 --> 00:30:06,800 transaction is posted to Etherium or until a proof is 496 00:30:06,800 --> 00:30:09,680 posted to Etherium. And so like, if you're like 497 00:30:09,680 --> 00:30:11,960 selling a house and accepting cryptocurrency, you're like 498 00:30:11,960 --> 00:30:14,880 selling the Lamborghini, you you just have like a different 499 00:30:14,960 --> 00:30:20,120 requirement for settlement versus if you're like buying us 500 00:30:20,360 --> 00:30:24,840 a a low value NFT or something. And so similarly, if you are 501 00:30:24,840 --> 00:30:28,120 using a chain that's on the AG layer, you have these different 502 00:30:28,120 --> 00:30:30,280 stages of guarantees. So you have the initial 503 00:30:30,280 --> 00:30:32,680 guarantee that's provided by the sequencer of your chain. 504 00:30:32,960 --> 00:30:36,360 You have then the guarantee that's provided by the AG layer 505 00:30:36,360 --> 00:30:39,440 if you need an additional guarantee. 506 00:30:39,680 --> 00:30:42,960 And finally, you have the guarantee of of settlement on 507 00:30:42,960 --> 00:30:46,320 Etherium. And so once everything is 508 00:30:46,320 --> 00:30:49,400 settled on Etherium, it's final like that we know that it's 509 00:30:49,400 --> 00:30:51,640 valid. It can never be reverted. 510 00:30:51,880 --> 00:30:55,640 And so I think it's up to the to users to sort of figure out 511 00:30:55,640 --> 00:30:59,880 which which assumption which guarantee sort of fits their 512 00:30:59,960 --> 00:31:03,680 use. OK, so I understand that the AG 513 00:31:03,680 --> 00:31:08,840 layer can't set the false transactions to Ethereum, but 514 00:31:08,840 --> 00:31:12,120 can it sense the transactions? Yeah. 515 00:31:12,120 --> 00:31:16,120 So, so there, there will be a mechanism to force transactions 516 00:31:16,120 --> 00:31:20,960 like to force settlement without explicit cooperation of the AG 517 00:31:20,960 --> 00:31:22,840 layer. The AG layer will be 518 00:31:22,840 --> 00:31:24,880 decentralized. So there will be like a 519 00:31:24,880 --> 00:31:29,120 censorship resistance component. But like fundamentally that the 520 00:31:29,120 --> 00:31:33,360 goal is to is, is for for chains to be able to use the AG layer 521 00:31:33,640 --> 00:31:35,480 with no additional trust assumptions. 522 00:31:35,560 --> 00:31:39,320 So, so they, they should be able to, to guarantee that like the 523 00:31:39,320 --> 00:31:43,520 AG layer can't censor, can't censor settlement of chains for 524 00:31:44,480 --> 00:31:47,320 for a long period. And you know there are no 525 00:31:47,320 --> 00:31:50,080 additional trust or security assumptions from from the chains 526 00:31:50,080 --> 00:31:51,920 perspective. OK. 527 00:31:51,920 --> 00:31:56,560 So who builds who kind of? Who makes the proofs for the 528 00:31:56,560 --> 00:31:58,840 Aglayer and is it currently centralized? 529 00:31:59,320 --> 00:32:02,200 Yeah, so, so the, the initial version is centralized just 530 00:32:02,200 --> 00:32:05,160 like, you know, ZK roll ups are, are centralized just because, 531 00:32:05,800 --> 00:32:07,800 you know, we're we're trying to do like a bunch of different 532 00:32:07,800 --> 00:32:11,080 things. And I like building the system 533 00:32:11,720 --> 00:32:13,760 sort of takes precedence over decentralizing it. 534 00:32:15,000 --> 00:32:17,760 But in the future it will just be centralized. 535 00:32:17,760 --> 00:32:20,120 Stake notes that are that are producing proofs. 536 00:32:20,120 --> 00:32:23,920 And but, but again, like these, these proofs are, are, are 537 00:32:23,920 --> 00:32:28,960 relatively lightweight, certainly relative to to AZKVM. 538 00:32:28,960 --> 00:32:34,600 And so like you know, we, we use laptops to test proof generation 539 00:32:34,600 --> 00:32:39,280 and and that will be an option for for users that are that are 540 00:32:39,280 --> 00:32:42,080 producing these proofs. OK. 541 00:32:42,080 --> 00:32:46,120 And so, so in, in your time when kind of the AG layers 542 00:32:46,760 --> 00:32:50,720 decentralized, who will be able to generate these proofs? 543 00:32:50,720 --> 00:32:52,560 So who who will run the AG layer? 544 00:32:53,640 --> 00:32:59,720 Yeah, so, so stick notes. So, so we'll just have a leader 545 00:32:59,720 --> 00:33:02,800 that that occurs on every AG layer slot and that leader will 546 00:33:02,800 --> 00:33:05,560 be in charge of producing proofs. 547 00:33:07,920 --> 00:33:10,560 OK, who's already using the AG layer? 548 00:33:12,960 --> 00:33:19,120 Currently there is there are four chains connected to it, 549 00:33:19,840 --> 00:33:26,360 four O 5 and which includes the Polygon ZKVM OK XSX layer is 550 00:33:26,360 --> 00:33:28,680 connected to it, a star is connected to it. 551 00:33:29,080 --> 00:33:32,840 And as we recently announced that we have the pessimistic 552 00:33:32,840 --> 00:33:37,880 proof, you know stage one is getting you know built and it 553 00:33:37,880 --> 00:33:43,080 comes very shortly, I think in four to eight weeks then I think 554 00:33:43,080 --> 00:33:49,760 many other stack based chains will be able to connect into the 555 00:33:49,760 --> 00:33:53,640 agglia. So you know, previously near 556 00:33:53,640 --> 00:33:56,680 protocol like as a layer one has also declared that they'll be 557 00:33:56,680 --> 00:34:00,040 connecting into that layer once they have the ZK. 558 00:34:00,040 --> 00:34:05,320 The ZK was on proofs, so similarly like, you know, we 559 00:34:05,320 --> 00:34:10,159 expect many other, you know, chains and not only new chains, 560 00:34:10,159 --> 00:34:12,080 but the existing chains also connecting into it. 561 00:34:12,440 --> 00:34:16,400 We in the next 2-3 weeks, for example, we also have another 562 00:34:17,040 --> 00:34:20,520 one of the biggest names in the space connecting into BRT. 563 00:34:20,520 --> 00:34:25,719 So yeah. What's the pessimistic proof? 564 00:34:26,800 --> 00:34:29,199 The pessimistic proof. So, so this is it's an 565 00:34:29,199 --> 00:34:33,480 interesting idea. So like part of the vision for 566 00:34:33,480 --> 00:34:38,679 the Aglayer is that we're not opinionated about anything. 567 00:34:38,800 --> 00:34:42,239 So chains should be able to use their own sequencers, their own 568 00:34:42,239 --> 00:34:44,719 tokens, their own governance mechanism. 569 00:34:45,520 --> 00:34:47,960 They should also be able to use their own execution environment. 570 00:34:48,159 --> 00:34:51,960 So you should have chains that are able to run AZKVM type one 571 00:34:51,960 --> 00:34:59,120 and type 2, the SVM miden, you know, a move VM like a custom 572 00:34:59,120 --> 00:35:03,320 Rust VM, like basically whatever they want of this is that if 573 00:35:03,320 --> 00:35:07,600 we're using a shared bridge, then for every VM and every 574 00:35:07,600 --> 00:35:11,160 prover that we include in the agglare, the probability that 575 00:35:11,160 --> 00:35:15,680 one of these provers is unsound, it can be used to generate a 576 00:35:15,680 --> 00:35:19,000 proof that that's valid, but but contains an invalid transaction 577 00:35:19,600 --> 00:35:22,120 goes up. And so this would be really 578 00:35:22,120 --> 00:35:26,440 catastrophic because it would allow some chain to construct, 579 00:35:26,880 --> 00:35:28,560 you know, proof that that verifies. 580 00:35:28,920 --> 00:35:32,440 But maybe it like the block that that proof is validating 581 00:35:32,440 --> 00:35:35,720 includes a transaction that allows someone to withdraw like 582 00:35:35,720 --> 00:35:38,560 a millionaire or something. And, and they can drain the 583 00:35:38,560 --> 00:35:40,920 entire shared bridge of all funds. 584 00:35:40,920 --> 00:35:44,120 And so we don't want this to be possible. 585 00:35:44,280 --> 00:35:47,480 And we, this is like a very, very important part of 586 00:35:47,480 --> 00:35:51,200 guaranteeing the chains have the same security using the AG layer 587 00:35:51,640 --> 00:35:54,600 as not using the AG layer. And So what we do is we 588 00:35:54,600 --> 00:35:58,000 basically say, OK, from the AG layer's perspective, we assume 589 00:35:58,000 --> 00:36:02,240 that every proof is unsound that that every prover has some 590 00:36:02,240 --> 00:36:04,880 soundest bug that's sort of like hidden and deeper than the code. 591 00:36:06,600 --> 00:36:09,800 And so instead we have this special proof that's very, very 592 00:36:09,800 --> 00:36:15,120 simple and it checks it. It basically like takes in all 593 00:36:15,120 --> 00:36:19,280 of the asset transfers from the bridge and it checks that the, 594 00:36:19,400 --> 00:36:23,120 the token balances on each chain are conserved. 595 00:36:23,320 --> 00:36:26,680 So no chain can withdraw more tokens than are currently 596 00:36:26,680 --> 00:36:29,880 deposited to that chain. And so this guarantees that, you 597 00:36:29,880 --> 00:36:33,080 know, I, I, I can't spin up some chain that, that has a prover 598 00:36:33,080 --> 00:36:36,680 that I know is unsound and use it to, to drain, drain the 599 00:36:36,680 --> 00:36:38,320 entire bridge. And so we call it the 600 00:36:38,320 --> 00:36:40,800 pessimistic proof because we're basically assuming that there's 601 00:36:40,800 --> 00:36:44,640 a soundness error everywhere in in every prover. 602 00:36:44,640 --> 00:36:47,960 And we still want to guard against that possibility. 603 00:36:48,600 --> 00:36:50,280 So, yeah. So that allows us to provide the 604 00:36:50,280 --> 00:36:56,280 same security for chains as as if they were deployed on on 605 00:36:56,280 --> 00:36:59,600 separate bridges. So if you're on Polygon CKVM, 606 00:37:00,280 --> 00:37:03,280 your funds are safe even if there's some compromise chain 607 00:37:03,280 --> 00:37:05,320 that exists elsewhere in the ecosystem. 608 00:37:06,120 --> 00:37:07,480 Yeah, that makes a. Lot of sense. 609 00:37:08,120 --> 00:37:10,440 So we were talking about different kind of chains 610 00:37:10,440 --> 00:37:13,760 integrating into the Agda. Does this also work for 611 00:37:13,760 --> 00:37:16,800 optimistic roll ups? So I think kind of we we've kind 612 00:37:16,800 --> 00:37:22,640 of touched upon different ZK broad UPS, but is optimistic 613 00:37:22,960 --> 00:37:26,120 fundamentally different? Yeah, so so. 614 00:37:26,320 --> 00:37:30,920 Because there's such a long fraud proof challenge period, we 615 00:37:30,920 --> 00:37:34,920 can't offer the same guarantees because there's no like fast 616 00:37:34,920 --> 00:37:37,480 finality. That's that's, that's guaranteed 617 00:37:37,480 --> 00:37:41,440 by by the chain. And so, so the chains that can 618 00:37:41,440 --> 00:37:44,760 connect to the eye glare are obviously ZK roll ups and 619 00:37:44,760 --> 00:37:48,440 they're also side chains that have that have finality. 620 00:37:48,760 --> 00:37:53,640 And so, so, so, so you could say like, OK, I'm not going to to 621 00:37:53,640 --> 00:37:55,280 generate validity proofs for my chain. 622 00:37:55,360 --> 00:37:58,320 Maybe your users don't care or, or you think that, you know, 623 00:37:58,680 --> 00:38:01,480 having side chain security is a sufficient security guarantee, 624 00:38:01,480 --> 00:38:03,320 which which I think is a valid position. 625 00:38:03,840 --> 00:38:07,200 And from the Agglio's perspective, we already have the 626 00:38:07,200 --> 00:38:10,920 pessimistic proof. And so for the AG layer, like 627 00:38:10,920 --> 00:38:14,040 we, we actually already assume that your, your validity proof 628 00:38:14,640 --> 00:38:16,400 is not valid or there's some issue with it. 629 00:38:16,640 --> 00:38:20,840 And so we can accept like a proof of consensus that verifies 630 00:38:20,840 --> 00:38:25,200 the security of the side chain. The problem is like we can't 631 00:38:25,720 --> 00:38:30,360 have optimistic roll ups because there's no way to offer this 632 00:38:30,600 --> 00:38:35,920 short interop period where where it like like we we can't, we 633 00:38:35,920 --> 00:38:39,000 can't guarantee that like the state of the optimistic roll up 634 00:38:39,080 --> 00:38:44,080 won't fork if say the validators say that a particular state is 635 00:38:44,080 --> 00:38:46,720 final and then a fraud proof is submitted later. 636 00:38:47,680 --> 00:38:52,840 Like the aggler has to be sort of fork free after, after like 637 00:38:52,840 --> 00:38:56,960 finality is reached. So that's, that's sort of the 638 00:38:57,240 --> 00:38:59,280 the, the big issue with optimistic roll ups. 639 00:39:00,240 --> 00:39:02,560 OK, I see. You very recently introduced 640 00:39:02,560 --> 00:39:04,320 something called a Type 1 prover. 641 00:39:05,240 --> 00:39:13,480 So for everyone like me, not well versed in ZKEVM proofers, 642 00:39:13,840 --> 00:39:18,640 what does type one mode mean? Yeah, so, so Vitalik. 643 00:39:18,640 --> 00:39:22,560 Came up with this classification framework for for ZKVMS and it 644 00:39:22,560 --> 00:39:27,120 ranges from type 1 to I think type 4 and it basically refers 645 00:39:27,120 --> 00:39:31,120 to like how similar an environment is to the EVM. 646 00:39:31,320 --> 00:39:35,360 So, so AZKVM is like a special type of computer that's running 647 00:39:35,360 --> 00:39:38,440 inside is your knowledge proof that allows us to verify 648 00:39:38,440 --> 00:39:44,480 execution of EBM transactions. And so a type 4 is basically 649 00:39:44,480 --> 00:39:48,720 like, OK, this computer is it's different from the EBM in, in, 650 00:39:48,720 --> 00:39:52,880 in like concrete ways. But maybe we have a compiler or 651 00:39:52,880 --> 00:39:56,920 something that allows us to take existing Solidity code and 652 00:39:56,920 --> 00:40:01,120 compile it to this new target. And maybe, you know, it's like 653 00:40:01,240 --> 00:40:04,680 90% similar or like they're, they're like, you know, there's 654 00:40:04,680 --> 00:40:07,160 some parts that you have to change, you have to re audit, 655 00:40:07,160 --> 00:40:09,840 but but otherwise it's it's similar and, and functionally 656 00:40:09,840 --> 00:40:15,320 equivalent. Type 2 is type 2 and three are 657 00:40:16,680 --> 00:40:20,120 are basically like you have an environment, you have a ZKVM 658 00:40:20,560 --> 00:40:26,600 that presents a functionally identical environment to to 659 00:40:26,600 --> 00:40:29,520 users and developers. And so you can take your 660 00:40:29,520 --> 00:40:32,800 Solidity code, you can use it as is, users can transact with the 661 00:40:32,800 --> 00:40:35,960 chain with basically no difference from from Etherium. 662 00:40:37,000 --> 00:40:41,280 But we can't use that ZKVM to prove existing EVM chains. 663 00:40:41,440 --> 00:40:42,880 And so that's where a type one comes in. 664 00:40:43,200 --> 00:40:46,360 It allows us to take any existing EVM chain, whether it's 665 00:40:46,360 --> 00:40:50,600 like an optimistic roll up, like the Polygon POS chain and we can 666 00:40:50,600 --> 00:40:54,960 upgrade it to being AZK roll up. So it's so seamlessly we we can 667 00:40:54,960 --> 00:40:58,080 just immediately start generating proofs and we can 668 00:40:58,080 --> 00:41:02,200 convert it into a chain that's secured by Philip Lipres. 669 00:41:03,920 --> 00:41:08,480 OK, OK, I see. And how does this kind of fit 670 00:41:08,480 --> 00:41:11,760 into kind of the the Ag layer integration? 671 00:41:14,360 --> 00:41:16,600 Yeah. So, so it allows us to take 672 00:41:16,600 --> 00:41:20,080 existing like optimistic roll ups that already exist and 673 00:41:20,240 --> 00:41:23,160 upgrade them to ZK roll ups so they can join the Agler. 674 00:41:24,080 --> 00:41:26,200 OK, so basically this is a. Way for kind of fixing 675 00:41:26,200 --> 00:41:30,200 optimistic roll up such that kind of they are compatible with 676 00:41:30,600 --> 00:41:37,120 the egg layer architecture then yeah exactly so if the type 1 677 00:41:37,120 --> 00:41:42,200 prover is a way of kind of making an optimistic chain 678 00:41:42,480 --> 00:41:46,640 integrable into the app layer are there any drawbacks for that 679 00:41:48,720 --> 00:41:51,040 I don't like I. Don't think that there are the 680 00:41:52,200 --> 00:41:54,480 drawbacks. I would just say that when an 681 00:41:54,480 --> 00:41:59,440 optimistic chain uses a Type 1 prover, then they don't need to 682 00:41:59,440 --> 00:42:03,160 remain an optimistic chain. They can be a fully validity 683 00:42:03,160 --> 00:42:07,360 proven, fully proven chain and don't need to have those 684 00:42:07,360 --> 00:42:11,880 optimistic fraud proofs which need for seven days to seven 685 00:42:11,880 --> 00:42:14,560 days challenge period as a safety mechanism and all those 686 00:42:14,560 --> 00:42:16,800 things and they can settle instantly. 687 00:42:17,240 --> 00:42:22,760 So you know, when I see of I think of optimistic chains using 688 00:42:22,760 --> 00:42:27,200 the Type 1 prover, I am thinking of them upgrading into a ZK 689 00:42:27,880 --> 00:42:31,240 rather than like you know, going along with both of these 690 00:42:31,720 --> 00:42:33,800 mechanisms. OK, so how? 691 00:42:33,800 --> 00:42:39,120 Exactly does the type 1 prover? How does it generate proofs for 692 00:42:39,120 --> 00:42:43,040 for these optimistic chains? Yeah, so, so it. 693 00:42:43,040 --> 00:42:50,880 It you know, it can take in what we call witness data from from 4 694 00:42:50,880 --> 00:42:54,920 nerds and use it to like generate a proof that every 695 00:42:54,920 --> 00:42:58,480 transaction in the block is is applied correctly to the 696 00:42:58,480 --> 00:43:03,880 existing state of the chain. And so it we can just prove that 697 00:43:03,880 --> 00:43:06,720 that a block is valid given a previous state. 698 00:43:07,840 --> 00:43:09,120 Yeah. And Felipe, I think. 699 00:43:09,120 --> 00:43:13,640 Your real question is like how does the type 1 prover kind of 700 00:43:13,640 --> 00:43:16,520 like, you know, work with the optimistic or generate the proof 701 00:43:16,520 --> 00:43:19,760 for optimistic chain? Actually you have to understand 702 00:43:19,760 --> 00:43:21,400 what is it? What is an optimistic chain? 703 00:43:21,400 --> 00:43:24,560 Like there is a simple mostly like I'm talking about EVM 704 00:43:24,560 --> 00:43:27,080 chain. There is a simple, let's say get 705 00:43:27,080 --> 00:43:30,880 node, right, which is running somewhere and the chain and the 706 00:43:30,880 --> 00:43:34,080 get node doesn't know anything about optimistic proofs being 707 00:43:34,080 --> 00:43:36,200 sent somewhere. It's a simple get node. 708 00:43:36,480 --> 00:43:39,520 And then on the Ethereum, you have some few smart contracts 709 00:43:39,520 --> 00:43:43,720 which are the optimistic part of the of the, of the, of the, of 710 00:43:43,720 --> 00:43:47,320 the whole system, right? And when you create the ZK 711 00:43:47,320 --> 00:43:49,640 proof, the ZK proofs are being created of the chain. 712 00:43:50,360 --> 00:43:54,120 ZK proofs don't have anything to do with the optimistic proofs of 713 00:43:54,120 --> 00:43:57,000 the smart contracts that they have on the Ethereum blockchain. 714 00:43:57,000 --> 00:43:59,640 All the ZK proofs are just creating a proof for a get 715 00:43:59,640 --> 00:44:04,920 chain, get based chain or any, you know, Ethereum or EVM client 716 00:44:04,920 --> 00:44:08,160 based chain. And you what you do is as 717 00:44:08,160 --> 00:44:10,680 optimistic chain is that you just simply strip out the 718 00:44:10,800 --> 00:44:14,840 optimistic part of the chain and just use replace it with the ZK 719 00:44:14,840 --> 00:44:17,640 proofs and upgraded into AZK chain. 720 00:44:19,160 --> 00:44:20,440 So basically what you do is kind. 721 00:44:20,440 --> 00:44:25,160 Of you, you go back to the last state of the chain that can't be 722 00:44:25,160 --> 00:44:29,240 rolled back because kind of the challenge period has lapsed and 723 00:44:29,240 --> 00:44:33,800 then kind of you prove that your current state is a valid 724 00:44:33,800 --> 00:44:35,640 successor state of that. Is that correct? 725 00:44:36,520 --> 00:44:38,240 Absolutely. Absolutely. 726 00:44:38,960 --> 00:44:41,080 Oh, OK, good. What are the? 727 00:44:41,080 --> 00:44:44,440 Challenges in. Building these because it it 728 00:44:44,440 --> 00:44:48,120 sounds like sounds too good to be true. 729 00:44:48,160 --> 00:44:52,200 So what what are the challenges in kind of building a type 1 730 00:44:52,200 --> 00:44:55,440 prover? Or does it only apply to certain 731 00:44:55,440 --> 00:44:57,880 kinds of chains? Yeah. 732 00:44:57,880 --> 00:45:00,720 So so. So I think the challenges are 733 00:45:01,560 --> 00:45:04,680 there are a few. So like a lot of the 734 00:45:04,680 --> 00:45:07,800 cryptographic primitives that are used in the EBM, 735 00:45:07,840 --> 00:45:10,800 specifically Catch Shack, some of the pairings, they're, 736 00:45:10,800 --> 00:45:15,040 they're actually not very friendly to, to being proven in 737 00:45:15,040 --> 00:45:18,320 Israel knowledge proof. And so there's like a lot of 738 00:45:18,320 --> 00:45:21,680 engineering and, and research work that has gone into making 739 00:45:21,680 --> 00:45:24,800 those more efficient. So specifically, yeah, like 740 00:45:24,800 --> 00:45:31,320 Catch Act and, and parents. And so beyond that, things like 741 00:45:31,800 --> 00:45:35,120 the NPT and RLP encoding, they're, they're just not very 742 00:45:35,120 --> 00:45:39,160 ZK friendly. But what we discovered was that 743 00:45:39,160 --> 00:45:43,360 a lot of the work that we've been doing in R&D in Polygon, so 744 00:45:43,840 --> 00:45:47,840 developing Pocky 2 and Pocky 3, that has gotten us to the point 745 00:45:48,080 --> 00:45:51,600 where we can actually accept this extra complexity and cost 746 00:45:52,000 --> 00:45:55,320 and we're able to generate transactions at at very, very 747 00:45:55,320 --> 00:45:58,800 low cost. And so we've been generating 748 00:45:58,800 --> 00:46:01,640 basically a proof for every single Ethereum block from I 749 00:46:01,640 --> 00:46:03,200 think the beginning of Shanghai or something. 750 00:46:03,560 --> 00:46:08,880 And what we've seen is that for these, for these proofs the OR 751 00:46:08,880 --> 00:46:13,120 these transactions, the average proving cost is between one and 752 00:46:13,120 --> 00:46:16,760 2/10 of a cent. And so this is already like a 753 00:46:16,760 --> 00:46:21,840 very, very competitive cost in relation to transaction fees 754 00:46:21,840 --> 00:46:27,400 that users are already paying. And we think that, that the, the 755 00:46:27,400 --> 00:46:30,320 proving costs will, will continue to, to decrease because 756 00:46:31,040 --> 00:46:33,720 our type 1Z KB M is, is built on plucky 2. 757 00:46:34,240 --> 00:46:38,280 And when we move to clock E3, that will be like a, a huge, 758 00:46:38,280 --> 00:46:42,240 huge unlock and speed up. And so I, I, I think like, it's 759 00:46:42,240 --> 00:46:45,400 fair to say that we're already there in terms of proving cost. 760 00:46:45,720 --> 00:46:49,560 We're just trying to push the frontier of applications where 761 00:46:49,560 --> 00:46:53,080 it becomes economically feasible and practical to generate 762 00:46:53,080 --> 00:46:54,760 proofs. So it's right now like 763 00:46:55,120 --> 00:46:57,720 everything that you currently do, I don't know too. 764 00:46:58,160 --> 00:47:02,160 I think is is feasible and practical and, and the cost is 765 00:47:02,160 --> 00:47:03,640 low enough to generate proofs for. 766 00:47:04,000 --> 00:47:07,360 But if we want to do like games and social applications that 767 00:47:07,360 --> 00:47:10,400 that aren't as like economically valuable and and don't have as 768 00:47:10,400 --> 00:47:14,240 as high fee component, we need to further reduce proving costs 769 00:47:14,240 --> 00:47:16,800 to to to make those sort of practical as well. 770 00:47:17,800 --> 00:47:20,560 OK, so kind of the the. Only reason why kind of type 1 771 00:47:20,560 --> 00:47:25,240 provers are feasible is kind of because the cost of generating 772 00:47:25,240 --> 00:47:29,680 proofs has decreased so much that you can now kind of just 773 00:47:29,680 --> 00:47:34,680 prove the state of the chain since the last uncontestable 774 00:47:34,680 --> 00:47:37,040 state. So let let's talk about these 775 00:47:37,040 --> 00:47:39,120 advances, advances in cryptography. 776 00:47:39,120 --> 00:47:42,400 So you were you, you, you were talking about Plonke 2 and 777 00:47:42,400 --> 00:47:45,080 Plonke 3. And the fact aside that all of 778 00:47:45,080 --> 00:47:47,800 these prover systems seem to have really wacky names. 779 00:47:48,560 --> 00:47:52,880 Can, can, can you walk us through kind of the evolution of 780 00:47:52,880 --> 00:47:56,120 CKP system? So kind of like back in the day, 781 00:47:56,120 --> 00:48:01,800 kind of we had, we had ZK snacks and ZK stocks and then kind of 782 00:48:02,080 --> 00:48:08,360 these, these come with inherent limitations and challenges that 783 00:48:08,360 --> 00:48:12,240 were then kind of counteracted by kind of like polynomial 784 00:48:12,240 --> 00:48:14,160 commitments and recursion and so on. 785 00:48:14,400 --> 00:48:18,720 Can you, can you dive in? Can you, can you dive into a 786 00:48:18,720 --> 00:48:21,200 little bit more detail here? Yeah. 787 00:48:21,200 --> 00:48:24,120 I I, I I. Think by by wacky names, you 788 00:48:24,120 --> 00:48:29,640 mean like brilliant branding and very, actually very good names? 789 00:48:30,560 --> 00:48:32,320 No, I I see, see that, see that's a. 790 00:48:32,320 --> 00:48:35,040 Reason why we don't put mathematicians in the marketing 791 00:48:35,040 --> 00:48:37,040 departments. Yeah, yeah, I, I. 792 00:48:37,320 --> 00:48:40,560 I, I do think the placky naming might be like some of the worst 793 00:48:40,560 --> 00:48:44,480 branding that's, that's ever been introduced to crypto, but I 794 00:48:44,480 --> 00:48:47,080 don't know, like people, people know what it is and it's 795 00:48:47,080 --> 00:48:49,760 recognizable. But yeah, so, so I, I think if 796 00:48:49,760 --> 00:48:56,720 we rewind to 2019, so Daniel Lubrov, who's my Co founder of 797 00:48:56,720 --> 00:49:02,120 Mir, he and I raised money for Mir in, in 2019 and it was like 798 00:49:02,400 --> 00:49:08,240 a very, very nerve wracking time because the primitives that were 799 00:49:08,240 --> 00:49:12,680 available for, for, for ZK tech, we're not fast enough to do what 800 00:49:12,680 --> 00:49:16,080 we wanted to do. And we weren't sure how quickly 801 00:49:16,120 --> 00:49:19,880 they would become faster. And so we put in a ton of effort 802 00:49:19,920 --> 00:49:24,680 in 2020 and 2021 to, to improving ZK tech. 803 00:49:24,760 --> 00:49:30,000 And our approach was like in the academic community, there's a 804 00:49:30,000 --> 00:49:32,920 lot of focus on like asymptotic efficiency. 805 00:49:32,960 --> 00:49:37,640 So like how many field operations approver requires to, 806 00:49:37,640 --> 00:49:40,640 to generate a proof. And this is like a proxy for 807 00:49:41,120 --> 00:49:43,800 computational cost and, and latency and improving 808 00:49:43,800 --> 00:49:47,920 efficiency. But our insight was that not all 809 00:49:47,920 --> 00:49:49,520 field operations are created equal. 810 00:49:50,040 --> 00:49:54,400 And we should have this notion of like hardware and software 811 00:49:54,400 --> 00:49:59,440 and theory code design. So we should look at like which 812 00:49:59,440 --> 00:50:03,200 operations can be, can be optimized to, to be more 813 00:50:03,200 --> 00:50:06,920 efficient on hardware and how that can feed into the theory 814 00:50:06,920 --> 00:50:09,440 piece. And so one of the things that we 815 00:50:09,480 --> 00:50:13,480 that we hit on was like Frye, which is the polynomial 816 00:50:13,480 --> 00:50:16,880 commitment scheme used in Starks has this nice property that it 817 00:50:16,880 --> 00:50:18,960 doesn't depend on elliptic curves. 818 00:50:19,400 --> 00:50:23,880 And what this means is that like unlike elliptic curves that that 819 00:50:23,880 --> 00:50:30,280 depend on or that require very large fields, so at least 256 820 00:50:30,280 --> 00:50:34,280 bit fields, with Fry you, you basically have a lot of freedom 821 00:50:34,640 --> 00:50:37,240 in selecting a field that might be much smaller. 822 00:50:37,720 --> 00:50:43,240 And if you think about like modern CPUs, they operate on 64 823 00:50:43,240 --> 00:50:46,520 bit word sizes. And so when you're simulating 824 00:50:46,560 --> 00:50:51,320 256 bit field arithmetic, it's actually a lot less efficient 825 00:50:51,560 --> 00:50:54,880 than if you had a field element that could fit in a single word. 826 00:50:55,480 --> 00:51:00,640 And so we discovered, or Hamish from, from our team proposed the 827 00:51:00,640 --> 00:51:03,920 Goldilocks field, which is this field that has like a very, very 828 00:51:03,920 --> 00:51:07,520 specific structure that makes it really, really efficient on 829 00:51:07,520 --> 00:51:11,240 modern CPUs. And so from there, there there 830 00:51:11,240 --> 00:51:14,240 were a ton of optimizations and a ton of work that went into 831 00:51:15,120 --> 00:51:20,360 Plucky 2, which was this like this vision of, of Starks that 832 00:51:20,920 --> 00:51:24,200 operate on, on these small like very carefully chosen fields. 833 00:51:24,680 --> 00:51:28,640 And that yielded like A50 to 100X speed up over what was 834 00:51:28,640 --> 00:51:33,160 currently available on Etherium. And so, so, so that's been sort 835 00:51:33,160 --> 00:51:36,360 of like the route that we've taken with with Pucky 2 and and 836 00:51:36,360 --> 00:51:40,480 now with Pucky 3 where we have picked another even smaller 837 00:51:40,480 --> 00:51:43,800 field that had like, it was really, really nice on CB us, 838 00:51:43,800 --> 00:51:47,400 but it had this like theoretical drawback where you couldn't, it 839 00:51:47,400 --> 00:51:49,760 didn't have the size property that we needed for Starks. 840 00:51:50,120 --> 00:51:53,840 And so Ulrich from our team, working alongside some 841 00:51:53,840 --> 00:51:57,120 researchers at Starkwear, basically figured out a way to 842 00:51:57,120 --> 00:52:00,720 like change the protocol a little bit so that we could use 843 00:52:00,720 --> 00:52:06,120 this, this really, really nice field with, with, with really 844 00:52:06,120 --> 00:52:08,840 nice structure. And so that's kind of been the 845 00:52:08,840 --> 00:52:13,040 progression is like going from the an academic mindset where 846 00:52:13,760 --> 00:52:17,560 we're really, really far from like the concrete efficiency on 847 00:52:17,560 --> 00:52:21,320 hardware to more of like a hardware software Co design 848 00:52:21,320 --> 00:52:25,200 where we have we have engineers that are working alongside 849 00:52:25,520 --> 00:52:29,240 researchers and people on the theory side to to 850 00:52:29,240 --> 00:52:31,360 collaboratively build faster protocols. 851 00:52:32,400 --> 00:52:34,600 OK, so I think. I'm missing like a little bit in 852 00:52:34,600 --> 00:52:37,720 between here. So, so I totally understand kind 853 00:52:37,720 --> 00:52:40,200 of how you set your constraints, right. 854 00:52:40,200 --> 00:52:44,200 So you, you said, OK, this is kind of the GPU, this kind of 855 00:52:44,200 --> 00:52:49,760 the number of CPUs with certain specs that are with that should 856 00:52:49,920 --> 00:52:53,600 that this should somehow run on. And then you kind of you, you 857 00:52:53,600 --> 00:52:56,280 determine the field size based on that. 858 00:52:56,520 --> 00:53:01,240 But how was the field field size size chosen initially? 859 00:53:01,400 --> 00:53:05,120 So how how was it decided that kind of you would need 200 and 860 00:53:05,120 --> 00:53:12,320 5065 bit feared in the 1st place if kind of like half the size it 861 00:53:12,320 --> 00:53:15,920 would have easily been enough. Yeah, because for. 862 00:53:15,920 --> 00:53:19,040 Elliptic curves you need. You're working over a group that 863 00:53:19,200 --> 00:53:22,800 that is defined by an elliptic curve, and so in order for that 864 00:53:23,320 --> 00:53:26,440 to be secure, in order for the discrete log problem to be hard 865 00:53:26,440 --> 00:53:29,720 enough, it needs to have a a certain minimum field size. 866 00:53:30,120 --> 00:53:33,160 You you you can define an elliptic curve over an extension 867 00:53:33,160 --> 00:53:34,880 field. So you could pick a small field 868 00:53:34,880 --> 00:53:37,880 and and use some higher order extension, but there's still 869 00:53:37,880 --> 00:53:40,000 like like that that's not what people were doing. 870 00:53:40,000 --> 00:53:45,400 And and it's you're still stuck doing a bunch of arithmetic in 871 00:53:45,680 --> 00:53:51,600 at least a 256 bit sized field. And so with Fry, there's no 872 00:53:51,600 --> 00:53:55,920 dependence on an elliptic curve. And so, so we don't have this 873 00:53:55,920 --> 00:54:00,800 minimum size requirement. OK, and so now the. 874 00:54:00,800 --> 00:54:03,600 Difference between Plonke 2 and Plonke 3 is that you can use an 875 00:54:03,600 --> 00:54:07,000 even smaller field, making it much cheaper. 876 00:54:07,240 --> 00:54:11,840 So is this the limit or can you make it smaller still so I I? 877 00:54:11,840 --> 00:54:16,480 I think it might be minimal gains from making the field size 878 00:54:16,480 --> 00:54:18,440 smaller. So so the the nice thing about 879 00:54:18,440 --> 00:54:22,360 Pocky 3 is that it it has a a small field that also has this 880 00:54:22,360 --> 00:54:25,800 really nice structure. It's, it's a Mersenne prime, 881 00:54:25,800 --> 00:54:31,440 which means that it's of the form 2 to the north -1 And I 882 00:54:31,440 --> 00:54:38,240 think that the further, further improvements will come from like 883 00:54:38,240 --> 00:54:42,080 on the theory side and on the like the zero knowledge proof 884 00:54:42,080 --> 00:54:45,520 protocol side. And so like using different 885 00:54:46,360 --> 00:54:49,920 polynomial commitment schemes, using polynomial commitment 886 00:54:49,920 --> 00:54:52,840 schemes with a more efficient verifier for better recursion 887 00:54:52,840 --> 00:54:55,000 efficiency. I think that these will kind of 888 00:54:55,000 --> 00:54:59,040 be the routes for for future improvements, not so much 889 00:54:59,520 --> 00:55:02,280 improvements on just just from reducing a field test. 890 00:55:03,080 --> 00:55:04,840 What about specialized? Hardware. 891 00:55:04,840 --> 00:55:10,760 So I mean this is run on on regular multi core CPUs I assume 892 00:55:10,760 --> 00:55:13,000 right? So. 893 00:55:13,000 --> 00:55:15,000 If you were. To build like specialized 894 00:55:15,000 --> 00:55:19,200 chipsets, Would that make it much simpler or more much more 895 00:55:19,200 --> 00:55:21,760 efficient? Yeah, so it so it would. 896 00:55:22,600 --> 00:55:24,600 And, and there are a bunch of different projects that are 897 00:55:24,600 --> 00:55:29,080 currently developing chips that that support, you know, 898 00:55:29,080 --> 00:55:32,120 Goldilocks field arithmetic or, or other operations that are 899 00:55:32,240 --> 00:55:36,800 that are used in improving the. The tricky thing is that some of 900 00:55:36,800 --> 00:55:42,320 these some of like FPGA and GPUs might be like hardware or might 901 00:55:42,320 --> 00:55:44,080 be memory or, or bandwidth limited. 902 00:55:44,320 --> 00:55:48,440 And so you might be able to really accelerate certain parts 903 00:55:48,480 --> 00:55:52,040 of the prover, but end to end it might be, it might still be the 904 00:55:52,040 --> 00:55:54,400 case that you know things are cheaper on ACPU. 905 00:55:55,400 --> 00:55:59,440 But I think that we're seeing a lot of efforts toward hardware 906 00:55:59,440 --> 00:56:02,760 improvement and I think that a lot of these are going to are 907 00:56:02,760 --> 00:56:06,360 going to yield very significant speed UPS in the near future. 908 00:56:08,120 --> 00:56:12,320 OK, so do. You remember when Z Cash had the 909 00:56:12,320 --> 00:56:16,880 bug in the cryptography for the shielded pools. 910 00:56:17,280 --> 00:56:20,440 So kind of with all of this very advanced cryptography, the 911 00:56:20,440 --> 00:56:26,120 problem is that the number of people who really understand it 912 00:56:26,120 --> 00:56:29,920 to the core is very small. And kind of you always, you 913 00:56:29,920 --> 00:56:32,560 always run the risk that kind of there's a vulnerability 914 00:56:32,560 --> 00:56:36,160 somewhere in there that just no one's found yet, right. 915 00:56:36,520 --> 00:56:40,440 So I, I hear that kind of like if if you look at kind of like 916 00:56:40,440 --> 00:56:44,160 how you set up the egg layer with kind of the pessimistic 917 00:56:44,160 --> 00:56:48,440 proof and so on, kind of, I mean, you, you everywhere, 918 00:56:48,440 --> 00:56:52,200 you're kind of trying to contain the risk of introduced 919 00:56:52,200 --> 00:56:54,560 vulnerabilities. But if something like Plunky 920 00:56:54,560 --> 00:56:59,440 three were to kind of be faulty on some level, what would that 921 00:56:59,440 --> 00:57:01,800 mean for the system? Yeah. 922 00:57:01,800 --> 00:57:06,320 So, so I, I, I, I think this is like the very much a top of mind 923 00:57:06,520 --> 00:57:11,240 concern for us. And our strategy has been to 924 00:57:11,320 --> 00:57:14,640 sort of have a gradual progression of, of like 925 00:57:14,640 --> 00:57:17,720 governance minimization and, and decentralization. 926 00:57:18,240 --> 00:57:22,320 I think it's really important for ZK roll ups or for protocols 927 00:57:22,320 --> 00:57:26,920 that use ZK technology to launch with training wheels and to give 928 00:57:26,920 --> 00:57:31,320 their systems time to, to be scrutinized and, and to develop 929 00:57:31,320 --> 00:57:34,200 and, and to, you know, potentially have formal 930 00:57:34,200 --> 00:57:37,840 verification. And so I think that we're, we're 931 00:57:37,840 --> 00:57:40,960 still like very much in the early stage of this process. 932 00:57:41,920 --> 00:57:44,960 And I think it's important to, you know, we're, we're, we're 933 00:57:44,960 --> 00:57:47,840 also doing audits and, and like we're, we're, we're very much 934 00:57:47,840 --> 00:57:50,800 like in bug bounties and, and taking like an approach that, 935 00:57:50,800 --> 00:57:53,240 that we really want these systems to be scrutinized and, 936 00:57:53,280 --> 00:57:57,680 and to be secured. But I think like with a lot of 937 00:57:57,800 --> 00:58:00,480 things in cryptography, it's just a, a question of time. 938 00:58:00,600 --> 00:58:05,680 And we just need these systems to be in production and securing 939 00:58:05,680 --> 00:58:10,880 value in kind of a training wheels mode where if there is a 940 00:58:10,880 --> 00:58:14,120 soundness issue, it can be detected and it can be remedied 941 00:58:14,120 --> 00:58:17,160 by, you know, an emergency Security Council or something 942 00:58:17,160 --> 00:58:19,640 like that. And so I, I, I, I think that 943 00:58:19,640 --> 00:58:23,440 that's the best strategy because, you know, we, we need 944 00:58:23,440 --> 00:58:26,800 like to provide a sufficient incentive or, or, or like a 945 00:58:27,520 --> 00:58:30,720 sufficient level of exposure to systems to harden them. 946 00:58:31,240 --> 00:58:33,800 But at the same time, we can't progress too quickly and, and 947 00:58:33,800 --> 00:58:36,280 really put user funds at risk. And so that's kind of the, 948 00:58:36,280 --> 00:58:39,320 we're, we're like trying to balance those, those two 949 00:58:39,320 --> 00:58:41,480 concerns. What shape do the? 950 00:58:41,480 --> 00:58:45,520 Training wheels take here then. Yeah, so, so right now. 951 00:58:45,520 --> 00:58:48,960 Like for like, like we, we can take the ZKVM roll up for 952 00:58:48,960 --> 00:58:52,200 example. So, so like, like I think like 953 00:58:52,200 --> 00:58:56,640 every ZK roll up that currently exists, only a single designated 954 00:58:56,640 --> 00:58:59,400 party can provide proofs to this roll up. 955 00:59:00,080 --> 00:59:03,520 So, so we are the only approver. I, I, I believe that this is the 956 00:59:03,520 --> 00:59:06,920 case for stock Ware and, and for ZK sync and for scroll. 957 00:59:08,280 --> 00:59:11,760 There's only one party that can provide proofs so that if there 958 00:59:11,760 --> 00:59:17,200 is a soundness issue, it cannot be exploited by, by an attacker. 959 00:59:18,480 --> 00:59:24,920 The second training wheel is an emergency Security Council where 960 00:59:25,360 --> 00:59:28,000 if there is an issue that's detected like we, we, we 961 00:59:28,000 --> 00:59:30,600 basically run every transaction twice. 962 00:59:30,600 --> 00:59:34,120 We, we, we run it once to prove, but, but we also run it to, to 963 00:59:34,120 --> 00:59:36,680 basically check that execution is correct and, and that the 964 00:59:36,680 --> 00:59:40,200 proof is consistent with, with what we're executing in the 965 00:59:40,200 --> 00:59:42,680 client. And if those two were ever to 966 00:59:42,680 --> 00:59:45,960 differ or if someone were to submit a transaction that could 967 00:59:45,960 --> 00:59:49,040 potentially cause an issue, we, we have the ability to fault the 968 00:59:49,040 --> 00:59:50,880 system and to rely on the Security Council. 969 00:59:50,880 --> 00:59:56,840 That's the majority is from outside Polygon to address that, 970 00:59:57,120 --> 00:59:58,800 that issue. And so, so I, I think that this 971 00:59:58,800 --> 01:00:02,600 is the same strategy as As for the AG layer where, you know, 972 01:00:03,320 --> 01:00:08,440 users are still getting a much higher level of security because 973 01:00:08,520 --> 01:00:12,480 like we cannot steal. User funds because we would have 974 01:00:12,480 --> 01:00:17,040 to like exploit a soundness issue or or or or or, you know, 975 01:00:17,040 --> 01:00:22,120 prove something that's invalid. But if a soundness issue is 976 01:00:22,120 --> 01:00:27,000 detected like we have the ability to to address them. 977 01:00:28,280 --> 01:00:30,960 OK, so. Maybe this is a question for 978 01:00:30,960 --> 01:00:34,440 Sandeep now. So Sandeep, you guys have put 979 01:00:34,440 --> 01:00:39,480 together this very ambitious vision of how the future of the 980 01:00:39,480 --> 01:00:43,320 Internet should kind of look under the hood, right? 981 01:00:43,880 --> 01:00:46,400 And it is. It's certainly super compelling. 982 01:00:46,920 --> 01:00:52,360 If I were to tell you I had a crystal ball and I had a crystal 983 01:00:52,360 --> 01:00:55,400 ball and I could look into the future and in five years it 984 01:00:55,400 --> 01:00:59,320 doesn't work anything like that. What do you think the issue will 985 01:00:59,320 --> 01:01:02,080 have been? So if this fails, why will it 986 01:01:02,080 --> 01:01:05,000 fail? I would say that the your. 987 01:01:05,000 --> 01:01:08,240 Crystal ball is not paying its Internet bill and it's not 988 01:01:08,240 --> 01:01:15,560 showing you the correct results. So use Moses pay to pay the 989 01:01:15,600 --> 01:01:17,200 Internet bills of your crystal ball. 990 01:01:18,040 --> 01:01:23,880 No, I mean seriously, I think that you know, we as a unit have 991 01:01:23,880 --> 01:01:30,280 been working on this problem and many times like, you know, 992 01:01:30,280 --> 01:01:33,920 people come to us today that Polygon is not doing this. 993 01:01:33,920 --> 01:01:36,920 And they talk about a lot of these short term things like you 994 01:01:36,920 --> 01:01:39,760 know, Polygon is not doing this, Polygon is not doing that this 995 01:01:39,760 --> 01:01:42,160 that they should do this, they should that. 996 01:01:42,160 --> 01:01:46,040 But The thing is that for us the mission has been extremely clear 997 01:01:46,040 --> 01:01:49,440 from get go and that mission is very simple that how do we 998 01:01:49,440 --> 01:01:54,400 create this infinitely growing web three, you know, 999 01:01:54,400 --> 01:01:56,560 infrastructure, right? Our blockchain network, 1000 01:01:56,560 --> 01:01:59,360 infinitely grown blockchain. You know, if somebody tells me 1001 01:01:59,360 --> 01:02:02,880 like, OK, this system works for 50,000 DBS, this system works 1002 01:02:02,880 --> 01:02:08,440 for 100,000 DBS, not interested. We want to build an infinitely 1003 01:02:08,440 --> 01:02:11,640 growing network. So which can take like even like 1004 01:02:12,160 --> 01:02:14,760 who knows, 1,000,000, two million, 2 million, even 1 1005 01:02:14,760 --> 01:02:18,440 billion TPS in 20 years, it should be able to take that. 1006 01:02:18,440 --> 01:02:23,480 So if you ask me that architecture, I don't see, I 1007 01:02:23,480 --> 01:02:26,840 mean, as of now, like I don't see there, there there can be an 1008 01:02:27,440 --> 01:02:30,400 there can be an alternate architecture which can achieve 1009 01:02:30,400 --> 01:02:35,120 this, you know, this infinite scalability while like, you 1010 01:02:35,120 --> 01:02:40,080 know, also solving from this fragmented liquidity and you 1011 01:02:40,080 --> 01:02:41,480 know, user experience and all that. 1012 01:02:41,840 --> 01:02:45,600 And if let's say that doesn't happen, Aglier is not that I 1013 01:02:45,600 --> 01:02:49,400 would say somebody else would be there, but their architecture 1014 01:02:49,400 --> 01:02:53,080 will be very similar to Aglier. Like something like this will 1015 01:02:53,080 --> 01:02:56,120 win, whether it's polygons, Aglier or somebody else's Aglier 1016 01:02:56,120 --> 01:02:58,760 that nobody can tell. But somebody like this will win 1017 01:02:58,800 --> 01:03:01,240 something like this will win. I think those. 1018 01:03:01,360 --> 01:03:05,840 Are fantastic parting words. So Sandeep and Brendan, if 1019 01:03:05,840 --> 01:03:08,880 people want to learn more about this, they kind of dive into the 1020 01:03:08,880 --> 01:03:12,000 docks and so on because obviously this was we we've 1021 01:03:12,000 --> 01:03:13,560 barely scratched the surface here. 1022 01:03:14,120 --> 01:03:17,000 Where do they go? How can they start building on 1023 01:03:17,000 --> 01:03:18,800 this? Yeah. 1024 01:03:18,800 --> 01:03:23,760 So, so the Aglayer docks are, I believe on, on the Polygon 1025 01:03:23,760 --> 01:03:25,800 website. I, I believe that we, we will be 1026 01:03:25,800 --> 01:03:30,880 spinning up a separate website that's Aglayer focused that 1027 01:03:30,880 --> 01:03:35,520 we'll have the, the docks there. But yeah, they're welcome to, to 1028 01:03:35,520 --> 01:03:37,160 go there. They, they're welcome to reach 1029 01:03:37,160 --> 01:03:41,520 out to me directly and, or anyone from our, our engineering 1030 01:03:41,520 --> 01:03:44,120 team. And yeah, go from there. 1031 01:03:46,000 --> 01:03:48,720 And I also want to as a. Parting way, just want to say 1032 01:03:48,720 --> 01:03:52,360 that you know, with this AG layer, that Polygon like kind of 1033 01:03:52,360 --> 01:03:56,200 extends beyond a layer two network like, you know, we I 1034 01:03:56,240 --> 01:03:59,960 like with AG layer, once the AG layer comes in fully, you can't 1035 01:03:59,960 --> 01:04:02,400 really like add layer is not a layer one or layer two. 1036 01:04:02,400 --> 01:04:06,680 It's a it's kind of a meta layer which allows layer tools and 1037 01:04:06,680 --> 01:04:10,560 many of them will be simple connected chains who are not 1038 01:04:10,560 --> 01:04:13,440 even using the layer two validity proofs, but they still 1039 01:04:13,440 --> 01:04:16,280 can exist in this multi chain environment. 1040 01:04:17,600 --> 01:04:20,880 And so, you know, that is that the Polygon transcends this 1041 01:04:20,880 --> 01:04:23,960 layer two layer one debate and then, you know, goes into a 1042 01:04:23,960 --> 01:04:27,680 place where it can actually support this infinite 1043 01:04:28,000 --> 01:04:31,760 scalability while using Ethereum as the settlement layer. 1044 01:04:31,920 --> 01:04:34,200 And that has been our core thesis from day zero. 1045 01:04:34,560 --> 01:04:38,200 And I think like now we are at a place with Aglayer where we can 1046 01:04:38,200 --> 01:04:41,360 take it to, you know, more closer to reality. 1047 01:04:42,160 --> 01:04:43,800 Cool super. Nice. 1048 01:04:44,200 --> 01:04:46,200 Thank you guys. As always. 1049 01:04:46,200 --> 01:04:49,960 It's been very elucidating. I look forward to having you 1050 01:04:49,960 --> 01:04:53,080 guys on in six months time and see what you've felt then. 1051 01:04:55,240 --> 01:04:56,160 Yeah. Thanks Rodriga. 1052 01:04:57,240 --> 01:04:58,560 Thanks for the weekend, always nice. 1053 01:04:58,560 --> 01:04:59,720 Talking to you. Thank you. 1054 01:04:59,720 --> 01:05:00,480 Bye. Bye. 1055 01:05:02,560 --> 01:05:03,840 Thank you for joining us on this week. 1056 01:05:03,840 --> 01:05:06,280 'S episode We release new episodes every week. 1057 01:05:06,880 --> 01:05:09,680 You can find and subscribe to the show on iTunes, Spotify, 1058 01:05:09,680 --> 01:05:12,720 YouTube, SoundCloud, or wherever you listen to podcasts. 1059 01:05:13,160 --> 01:05:16,000 And if you have a Google Home or Alexa device, you can tell it to 1060 01:05:16,000 --> 01:05:18,000 listen to the latest episode of the Epicenter podcast. 1061 01:05:18,720 --> 01:05:22,080 Go to epicenter.tv/subscribe for a full list of places where you 1062 01:05:22,080 --> 01:05:24,320 can watch and listen. And while you're there, be sure 1063 01:05:24,320 --> 01:05:26,800 to sign up for the newsletter so you get new episodes in your 1064 01:05:26,800 --> 01:05:29,880 inbox as they're released. If you want to interact with us 1065 01:05:30,200 --> 01:05:32,600 guests or other podcast listeners, you can follow us on 1066 01:05:32,600 --> 01:05:34,480 Twitter. And please leave us a review on 1067 01:05:34,480 --> 01:05:36,040 iTunes. It helps people find the show, 1068 01:05:36,040 --> 01:05:37,440 and we're always happy to read them. 1069 01:05:38,240 --> 01:05:40,840 But thanks so much and we look forward to being back next week.