WEBVTT 1 00:00:02.000 --> 00:00:04.320 All right, cool. What a way to start an episode, 2 00:00:05.519 --> 00:00:08.199 just leading off with our technical prowess and expertise. 3 00:00:08.560 --> 00:00:13.640 Hey Warren, Yeah, I really set that up nicely because 4 00:00:14.000 --> 00:00:17.760 I've for sure been having any issues. But maybe I'll 5 00:00:17.800 --> 00:00:20.719 just ignore that for a second. Jump straight to the point. 6 00:00:21.239 --> 00:00:23.760 We have a survey going for the podcast. It's of 7 00:00:23.839 --> 00:00:26.839 an Adventures in DevOps dot com slash survey, but you 8 00:00:26.839 --> 00:00:31.879 can see it everywhere. Please submit responses because it's a 9 00:00:31.920 --> 00:00:35.479 good feedback for us, something critical and thoughtful. If you'll 10 00:00:35.520 --> 00:00:41.960 win some a Tobos credits. And if it's not, well, 11 00:00:42.000 --> 00:00:43.439 there's not a lot that I can do about it 12 00:00:43.479 --> 00:00:45.560 at that point. 13 00:00:47.520 --> 00:00:52.320 If it's not helpful feedback, then just put some contact 14 00:00:52.320 --> 00:00:54.399 details in there and I will contact you and we'll 15 00:00:54.399 --> 00:00:57.359 have a good chat about it if you're so interested. 16 00:00:57.759 --> 00:01:01.439 I'm pretty excited today because we've got Paul Marston here 17 00:01:01.479 --> 00:01:03.600 with this as well. Paul, Welcome to the show. 18 00:01:04.599 --> 00:01:07.239 Hello, thank you for affording me the time. Yeah, So 19 00:01:07.879 --> 00:01:10.959 just to introduce myself, So, I work for Anchor slash 20 00:01:10.959 --> 00:01:15.879 Web three. I head up the note operations, so basically 21 00:01:15.959 --> 00:01:19.000 twenty four to seven running of blockchain nodes for integration 22 00:01:19.079 --> 00:01:22.400 partners that we've brought on board and also running you know, 23 00:01:22.480 --> 00:01:25.599 other nodes that we run specifically for our enterprise customers 24 00:01:25.599 --> 00:01:29.599 and other customers to access other blockchains of the networks. So, yeah, 25 00:01:29.640 --> 00:01:31.640 thank you for having me. Nice to be here, nice 26 00:01:31.680 --> 00:01:32.120 to meet you all. 27 00:01:32.239 --> 00:01:36.400 Yeah, for sure, I'm looking forward to this conversation because, well, 28 00:01:36.439 --> 00:01:39.599 for many reasons. One, I think it's super interesting to 29 00:01:39.760 --> 00:01:42.680 understand or just like to get some insight into what 30 00:01:43.120 --> 00:01:47.959 running infrastructure for Web three looks like when you have 31 00:01:48.079 --> 00:01:52.200 like a Web two background, because there are some different challenges. 32 00:01:52.280 --> 00:01:54.719 And I'm particularly excited to have you on the show 33 00:01:54.799 --> 00:01:58.040 because I'm very familiar with your work because a Polygon, 34 00:01:58.159 --> 00:02:01.439 we're a customer of yours, and you run a pretty 35 00:02:01.439 --> 00:02:05.560 significant amount of infrastructure on our behalf and do a 36 00:02:05.599 --> 00:02:08.680 fantastic job of it. I'll be upfront with that, like 37 00:02:09.599 --> 00:02:12.360 we Yeah, we don't even give a second thought to 38 00:02:12.439 --> 00:02:16.280 the infrastructure that y'all run for us, because it's just 39 00:02:16.400 --> 00:02:20.639 always there. And so I think that was one of 40 00:02:20.680 --> 00:02:22.439 the reasons I was excited to have you on this show, 41 00:02:22.479 --> 00:02:26.599 because you've clearly put the time and effort into the 42 00:02:26.639 --> 00:02:29.280 project to figure out how to make these things run 43 00:02:29.360 --> 00:02:35.599 at scale. So there we go. So give us a 44 00:02:35.639 --> 00:02:39.560 little bit about your background before you got into Web three, 45 00:02:39.639 --> 00:02:42.319 what like, what choices you make in life that brought 46 00:02:42.360 --> 00:02:43.159 you to this moment. 47 00:02:44.159 --> 00:02:47.800 Yeah, that's a great question. So yeah, similar to us. 48 00:02:48.199 --> 00:02:50.479 I've been in ANKA for a year now and similar 49 00:02:50.479 --> 00:02:53.000 to as I mentioned in my interview before I joined, 50 00:02:53.280 --> 00:02:57.360 so I've had quite a different ten years doing one 51 00:02:57.400 --> 00:02:59.680 thing ten years doing another. So yeah, I started out 52 00:03:00.479 --> 00:03:04.120 as an underwriter of all things, working in a call center, 53 00:03:04.400 --> 00:03:09.360 working on mainframe based you know, black and green screen 54 00:03:09.800 --> 00:03:14.560 terminals effectively for a retail company in the UK, taking 55 00:03:14.599 --> 00:03:17.120 applications and then deciding if people got loans or not 56 00:03:17.199 --> 00:03:20.000 based on some score that was spat out of you know, 57 00:03:20.879 --> 00:03:24.080 let's call it an arbitrary scoring algorithm for people's credit scores. 58 00:03:26.080 --> 00:03:28.240 And then then sort of slowly moved on from there 59 00:03:28.240 --> 00:03:31.599 doing more in depth and more technical elements. It was 60 00:03:31.680 --> 00:03:33.759 mainly an operational role that was to start with, but 61 00:03:33.800 --> 00:03:37.080 more technical elements in the let's call it Web two 62 00:03:37.360 --> 00:03:40.599 but specifically sort of financial services, moving on to doing 63 00:03:40.639 --> 00:03:45.120 testing and analytics, you know, requirements gathering for software builds, 64 00:03:45.120 --> 00:03:49.240 et cetera. And then I think that the main the 65 00:03:49.319 --> 00:03:52.039 main takeaway from like about three or four years of 66 00:03:52.080 --> 00:03:55.280 that period was I started working on migrations for customers. 67 00:03:55.719 --> 00:03:57.879 So they would come to where I was working at 68 00:03:57.879 --> 00:04:01.240 the time, first data, and we we would effectiveably do 69 00:04:01.360 --> 00:04:04.319 gap analysis between what they ran today for credit card processing, 70 00:04:04.680 --> 00:04:07.800 loan processing, et cetera, and how different our system was 71 00:04:07.840 --> 00:04:09.840 and what we needed to do in order to uplift 72 00:04:09.840 --> 00:04:12.280 our system or change their processes to bring them on board. 73 00:04:12.680 --> 00:04:15.919 And I think one thing I will say is even 74 00:04:15.919 --> 00:04:18.040 said this to my wife at the weekend. Working in 75 00:04:18.079 --> 00:04:23.079 a fast paced environment like you know, financial services migrations 76 00:04:23.079 --> 00:04:28.079 and i'm sure other migrations for other software, it really 77 00:04:28.120 --> 00:04:30.959 gives you a great background in dealing with things that 78 00:04:31.040 --> 00:04:34.759 you just cannot plan for. Every single event that we had, 79 00:04:34.800 --> 00:04:36.639 there was always something that came up that we've forgotten 80 00:04:36.639 --> 00:04:39.680 about or hadn't been captured as a requirement, et cetera. 81 00:04:40.079 --> 00:04:42.959 And being able to think quickly and because you have 82 00:04:43.000 --> 00:04:45.279 a set period where you need to migrate these things right, 83 00:04:45.319 --> 00:04:47.399 people want to use their credit cards to pay for things, 84 00:04:48.199 --> 00:04:50.920 you know, being able to being in that position having 85 00:04:50.959 --> 00:04:54.279 to think quickly, act quickly, resolve issues and move forward. 86 00:04:54.319 --> 00:04:55.920 It was always fixed forward. You know, there was never 87 00:04:56.000 --> 00:04:59.720 any going back. Yeah, I think it sets you up 88 00:04:59.759 --> 00:05:02.319 for for any role that you do in the future. 89 00:05:02.360 --> 00:05:04.800 So yeah, that's that was like migrations, and then I 90 00:05:04.879 --> 00:05:07.720 moved on to working on more digital focused products. That 91 00:05:07.839 --> 00:05:10.920 was the later part of my financial services background. I 92 00:05:10.920 --> 00:05:13.600 was working at Visa, I was looking enough to work 93 00:05:13.639 --> 00:05:15.839 on the Apple payroll out in the UK when they 94 00:05:15.839 --> 00:05:18.759 came to the UK, working with Apple and various other 95 00:05:18.800 --> 00:05:21.759 tokenization providers after that as well, So that was good. 96 00:05:21.759 --> 00:05:24.480 And then yeah, on the on the web free side, 97 00:05:24.519 --> 00:05:28.240 So it's it's almost I shouldn't say this, but I'll 98 00:05:28.279 --> 00:05:30.279 say it anyway, but it's almost like a love story 99 00:05:30.319 --> 00:05:33.639 between me and this guy I met in Discord and 100 00:05:33.720 --> 00:05:37.000 he's gonna hate that I've said that, but yeah, so 101 00:05:37.000 --> 00:05:39.879 so me and me and Pische or Peter. You may 102 00:05:39.879 --> 00:05:42.720 see him in Telegram and he's all over web free. 103 00:05:43.000 --> 00:05:46.920 But we we met. I think it's probably twenty seventeen, 104 00:05:46.920 --> 00:05:49.360 back end of twenty seventeen or twenty eighteen. We met 105 00:05:49.360 --> 00:05:54.360 in Discord for Horizon, you know, the crypto, and from 106 00:05:54.360 --> 00:05:56.199 there just hit it off, you know. We we had 107 00:05:56.399 --> 00:06:01.720 similar opinions, not the Peter would say necessarily that my 108 00:06:01.759 --> 00:06:04.360 opinion would be correct against his, but we had similar 109 00:06:04.360 --> 00:06:07.519 opinions in how we should be setting up servers, provisioning 110 00:06:07.560 --> 00:06:10.800 Linux running nodes, and you know that back then it 111 00:06:10.879 --> 00:06:14.279 was it was the secure node that Horizon had launched 112 00:06:14.319 --> 00:06:16.720 at that time, and yeah, we just we just had 113 00:06:16.959 --> 00:06:20.240 you know, very similar approaches to things, and naturally that 114 00:06:21.279 --> 00:06:23.720 came together and we actually ran a small startup for 115 00:06:23.800 --> 00:06:26.720 us a short time and then you know, i'd life 116 00:06:26.720 --> 00:06:28.040 got in the way of that and that kind of 117 00:06:28.120 --> 00:06:30.480 dwindled out. Peter moved on and continued to work in 118 00:06:30.519 --> 00:06:34.360 web Free, came to Anchor. I was at the time, 119 00:06:34.399 --> 00:06:37.720 I was finishing golf a contract for a UK based acquirer, 120 00:06:37.759 --> 00:06:40.600 so still doing some financial services work. And then I 121 00:06:40.639 --> 00:06:45.000 did another startup just a year prior to coming to Anchor, 122 00:06:45.199 --> 00:06:47.519 and then Peter got in touch and he was like, hey, 123 00:06:47.600 --> 00:06:50.120 there's a great opening here. It's very similar to what 124 00:06:50.160 --> 00:06:51.839 we've done previously. Why don't you come and join me? 125 00:06:52.680 --> 00:06:54.079 And yeah, and that's how I ended up here. And 126 00:06:54.120 --> 00:06:56.199 I'm just coming up to a year being in to 127 00:06:56.319 --> 00:06:58.079 Anchor right on. 128 00:06:58.720 --> 00:07:02.839 Very cool. So for someone who's not spent a lot 129 00:07:02.879 --> 00:07:07.000 of time working in web three specific to like the 130 00:07:07.079 --> 00:07:12.120 infrastructure that powers it. What would you say are the 131 00:07:12.160 --> 00:07:16.959 most significant holly shit factors that they experience. 132 00:07:19.600 --> 00:07:24.600 So from an infrastructure perspective, probably the scale. You know, 133 00:07:25.000 --> 00:07:28.040 certainly where we are, the number of bed and you 134 00:07:28.079 --> 00:07:32.040 know we're our selling point. Our USP is run it 135 00:07:32.079 --> 00:07:36.720 on bear metal, get the best performance possible, have many 136 00:07:36.920 --> 00:07:40.199 independently working systems, so you're not going to worry about 137 00:07:40.199 --> 00:07:45.279 what're losing one, three, five, whatever, your services stormline and yeah, 138 00:07:45.319 --> 00:07:46.920 you know, do it at a cost, do it at 139 00:07:47.079 --> 00:07:50.279 at the right cost to me all those factors, and yeah, 140 00:07:50.319 --> 00:07:54.279 so really the scale at which we have we provisioned 141 00:07:54.319 --> 00:07:56.879 hardware or anchor versus any of the organizations I've worked 142 00:07:56.920 --> 00:07:59.319 for in the past, with the exception of probably Visa, 143 00:07:59.439 --> 00:08:02.680 I would say, yeah, the scale of the hardware, the 144 00:08:02.680 --> 00:08:05.720 the not so much the effort in managing it, but 145 00:08:05.839 --> 00:08:08.319 ensuring that you have you know, the right rollouts, the 146 00:08:08.399 --> 00:08:11.120 right answer will playbooks to configure this host, that host, 147 00:08:11.120 --> 00:08:14.959 et cetera. On the right infrastructure's code in place. You know, 148 00:08:15.000 --> 00:08:18.439 it's significant, And yeah, I think that's the main difference. 149 00:08:18.519 --> 00:08:21.519 I think the other element to it as well is 150 00:08:22.079 --> 00:08:24.879 just the sheer overhead of managing that on a twenty 151 00:08:24.920 --> 00:08:27.959 four to seven three sixty five basis. We don't have 152 00:08:28.040 --> 00:08:30.439 bank holidays in Web three. We did, we did in 153 00:08:30.480 --> 00:08:32.919 financial services, and we used to have this think called 154 00:08:33.240 --> 00:08:35.360 we used to have this think call the weekend. That 155 00:08:35.399 --> 00:08:39.320 doesn't seem to make sist in Web three. So yeah, 156 00:08:39.919 --> 00:08:40.519 scale maintenance. 157 00:08:40.559 --> 00:08:42.440 And I didn't realize that was specific to Web three. 158 00:08:42.480 --> 00:08:45.200 I thought that got killed by COVID. That's that's my 159 00:08:45.279 --> 00:08:46.519 misunderstanding there. 160 00:08:49.159 --> 00:08:49.279 Now. 161 00:08:49.320 --> 00:08:52.559 I think when it talked, when you're talking about scale, like, 162 00:08:52.600 --> 00:08:59.559 one of the things that really sync in for me 163 00:09:00.919 --> 00:09:02.799 was each of the nodes. You know, because when you're 164 00:09:02.799 --> 00:09:06.879 talking about high availability, fault tolerance, redundant see that sort 165 00:09:06.919 --> 00:09:11.600 of stuff in a decentralized environment, what you're actually talking 166 00:09:11.639 --> 00:09:15.879 about there is every single node has to have a complete, 167 00:09:16.799 --> 00:09:20.679 accurate copy of the entire blockchain. 168 00:09:21.240 --> 00:09:24.480 To the extent that it needs to to serve its requirement. Right, 169 00:09:24.559 --> 00:09:27.559 So so we run different types of nodes. We have 170 00:09:28.240 --> 00:09:31.120 which mainly mainly come down as free categories, full node, 171 00:09:31.120 --> 00:09:34.120 which is you know, limited states at the you know, 172 00:09:34.559 --> 00:09:37.519 generally serves requests at the tip of the chain. And 173 00:09:37.559 --> 00:09:39.720 then we have the archive nodes, which, as you point 174 00:09:39.759 --> 00:09:42.039 out there, yeah, all required to store states all the 175 00:09:42.039 --> 00:09:43.799 way back to the genesis block and be able to 176 00:09:43.840 --> 00:09:46.720 serve that on you know, all day, every day twenty 177 00:09:46.799 --> 00:09:48.000 you know, three sixty five. 178 00:09:50.000 --> 00:09:50.799 Yeah, for sure. 179 00:09:51.320 --> 00:09:52.720 Just to add on to that as well, that the 180 00:09:52.840 --> 00:09:54.720 amount of data you have to store, you know, for 181 00:09:54.799 --> 00:09:59.919 an archive node, we're talking terabytes and terabytes, which for 182 00:10:00.080 --> 00:10:03.480 an independent service would be unheard of in the Web 183 00:10:03.559 --> 00:10:07.759 two world, right, you would probably have many services consuming 184 00:10:07.799 --> 00:10:10.919 from an enormous database as opposed to that note over 185 00:10:10.960 --> 00:10:13.759 there having five terabytes, that note over there having five terabytes, 186 00:10:13.799 --> 00:10:15.799 et cetera. So that's another good difference. 187 00:10:17.600 --> 00:10:22.720 So having transition from global payments infrastructure working with like 188 00:10:22.919 --> 00:10:28.399 Visa and some other payments companies into the Web three world, like, 189 00:10:28.440 --> 00:10:30.759 what sort of environment where you met with like is 190 00:10:30.799 --> 00:10:35.000 it common for people to transition from Web two? I mean, 191 00:10:35.080 --> 00:10:37.519 I see there's a lot of overlap in payments and 192 00:10:37.559 --> 00:10:42.039 financial structures within the Web three ecosystem, so you know, 193 00:10:42.080 --> 00:10:44.960 maybe there's some alignment there or was it completely different, 194 00:10:45.000 --> 00:10:47.120 you know, unexpected things coming up left and right that 195 00:10:47.440 --> 00:10:51.759 you just hadn't had experience with having been onside before. 196 00:10:51.919 --> 00:10:55.919 Yeah, So a great, great question. I think there's like two. 197 00:10:56.039 --> 00:10:59.279 There's probably two areas where it differs quite a bit. 198 00:10:59.360 --> 00:11:02.600 So like in the Web two space, a lot of 199 00:11:02.600 --> 00:11:06.759 the time there are there are lockins with vendors who 200 00:11:06.840 --> 00:11:10.759 sold your product, and with that comes additional bolt on 201 00:11:10.799 --> 00:11:15.000 products that you take as an organization because because you 202 00:11:15.039 --> 00:11:18.360 know you can, you can build a cohesive and hopefully 203 00:11:18.399 --> 00:11:22.240 you know, coherent platform to serve credit card traffic, loan traffic, 204 00:11:22.279 --> 00:11:24.360 you know, whatever you need to debit card traffic, et cetera. 205 00:11:24.679 --> 00:11:28.159 And in doing that, you almost make a decision about 206 00:11:28.960 --> 00:11:31.679 a lot of your infrastructure based on one key product 207 00:11:31.720 --> 00:11:34.240 that you need, and then as a result of taking 208 00:11:34.279 --> 00:11:36.240 that key product, you get all these other things as well. 209 00:11:36.320 --> 00:11:40.120 So you kind of mold yourself to working within those 210 00:11:40.159 --> 00:11:42.639 constraints of what those products have and what you've got 211 00:11:42.639 --> 00:11:44.080 off the shelf, and what is the key product that 212 00:11:44.120 --> 00:11:46.720 you've usually bought, whereas in Web three I would say 213 00:11:46.720 --> 00:11:51.320 there's there's there's less of that obviously, you know from 214 00:11:51.960 --> 00:11:54.720 we're not buying it in the Web three space, we're 215 00:11:54.759 --> 00:11:57.879 not buying in products that we run as such, or 216 00:11:58.399 --> 00:12:01.120 let's say a billing platform that we need to implement 217 00:12:01.200 --> 00:12:03.720 and run as part of some kind of processing platform. 218 00:12:04.039 --> 00:12:06.720 It's more that we're you know, our vendors primarily are 219 00:12:06.919 --> 00:12:10.639 our bare metal hosting providers who we deal with and 220 00:12:10.720 --> 00:12:13.799 you know, maintain good relationships with. So I would say 221 00:12:14.440 --> 00:12:18.039 there's more, there's more freedom to choose in the web 222 00:12:18.080 --> 00:12:23.039 free space, and we can dictate our own path more. 223 00:12:24.840 --> 00:12:28.399 I think the main differences between the approach to let's 224 00:12:28.399 --> 00:12:34.600 say development, release management and let's say notification of changes 225 00:12:34.639 --> 00:12:36.960 and version increments, et cetera in the Web two space 226 00:12:37.039 --> 00:12:41.120 versus Web three is web Web three. It happens instantly, right, 227 00:12:41.159 --> 00:12:43.559 you know, we can we can come in on a 228 00:12:43.600 --> 00:12:46.159 morning and a blockchain team that we've worked with can 229 00:12:46.200 --> 00:12:49.000 announce there's a hard falk tomorrow, and we've got to 230 00:12:49.000 --> 00:12:51.240 be ready. It doesn't matter if you're on in ten nodes, 231 00:12:51.840 --> 00:12:55.200 forty eight nodes, however many nodes. You know, the expectation 232 00:12:55.320 --> 00:12:58.080 is that you're ready. To Contrast that with what would 233 00:12:58.080 --> 00:13:00.879 have happened in Web two, we would have tested that 234 00:13:00.919 --> 00:13:03.200 for weeks. You know. I was just joking on a 235 00:13:03.240 --> 00:13:06.759 call with some guys the other day. They they were 236 00:13:06.799 --> 00:13:10.799 talking to someone loosely links to banking. Let's say, I 237 00:13:10.840 --> 00:13:13.320 can't say more than that, and they were saying, oh, yeah, 238 00:13:13.440 --> 00:13:16.159 so they said it's a six month project. I was like, whoa, whoa, 239 00:13:16.360 --> 00:13:18.720 I don't know you, you've not worked in this industry before. 240 00:13:18.720 --> 00:13:22.320 Then every finance project starts out as a six month project, 241 00:13:23.000 --> 00:13:25.879 and then three years later we're still working on implement 242 00:13:26.000 --> 00:13:29.120 to get VP and and and a lot of that is, 243 00:13:29.200 --> 00:13:31.679 you know, obviously there's there's decision making and you know, 244 00:13:31.799 --> 00:13:34.759 changes attack et cetera, and general evolution of what it 245 00:13:34.840 --> 00:13:37.399 is that you want to deploy and offer to your customers. 246 00:13:38.000 --> 00:13:41.840 But in some cases, you know your your timeline for development. 247 00:13:42.279 --> 00:13:44.679 In let's say the Web two space, the finance space 248 00:13:44.840 --> 00:13:48.039 will be shortened and you will have this huge chunk 249 00:13:48.080 --> 00:13:50.879 of testing that happens before things go into production. And 250 00:13:50.960 --> 00:13:54.840 I'm talking you know, business system testing, user acceptance testing, 251 00:13:55.279 --> 00:14:00.840 operational acceptance testing, et cetera, et cetera. So I think, yeah, 252 00:14:01.039 --> 00:14:04.159 I think there's more flexibility. We have more say over 253 00:14:04.240 --> 00:14:06.360 where we want to drive things in the web free space. 254 00:14:07.200 --> 00:14:08.879 In the Web two, I would say it's more rigid, 255 00:14:08.919 --> 00:14:12.519 but I wouldn't necessarily say that's all bad. I think 256 00:14:12.600 --> 00:14:15.360 there are good practices and processes that we can overlay from. 257 00:14:16.000 --> 00:14:18.759 Certainly my experience in Web two slash finance with what 258 00:14:18.919 --> 00:14:22.399 we do and how we approach the web free space. 259 00:14:24.879 --> 00:14:28.080 Makes sense. So just to get a better understanding of 260 00:14:28.639 --> 00:14:30.840 what it is that you're sort of doing. Would it 261 00:14:30.919 --> 00:14:33.480 be accurate to say you're like a cloud provider for 262 00:14:34.039 --> 00:14:36.600 web three companies that are running their own chains and 263 00:14:36.919 --> 00:14:39.840 you're hosting the nodes for them, or there's a gross 264 00:14:39.879 --> 00:14:42.559 oversimplification of what I'm sure you're actually doing. 265 00:14:43.399 --> 00:14:47.519 I mean, that doesn't that's not half bad in terms 266 00:14:47.559 --> 00:14:50.559 of the description. I think, you know, if you coming 267 00:14:50.600 --> 00:14:52.799 in cold and taking that away, I think I think 268 00:14:52.840 --> 00:14:56.360 that's pretty accurate. My only aversion is the cloud thing. 269 00:14:56.480 --> 00:14:59.039 So yes, it's cloud because it's not at your home, 270 00:15:00.279 --> 00:15:03.000 but we explicitly, don't you know, we have some critical 271 00:15:03.080 --> 00:15:07.440 services running in cloud infrastructure, AWS, GCP, etc. That's generally 272 00:15:07.519 --> 00:15:11.879 what I think people think of as cloud. But we're 273 00:15:11.919 --> 00:15:14.799 all about bare metal, least latency and highest performance. 274 00:15:14.840 --> 00:15:19.679 If so, now this is my own for my own understanding, 275 00:15:20.039 --> 00:15:22.960 Like what's the benefit of using a provider that offers 276 00:15:23.039 --> 00:15:26.120 dedicated nodes for the chain that you're developing, Like don't 277 00:15:26.159 --> 00:15:28.960 you have some sort of consensus protocol and so all 278 00:15:29.039 --> 00:15:30.799 of your users are going to be well, some set 279 00:15:30.799 --> 00:15:32.279 of the users are going to be running their own 280 00:15:32.360 --> 00:15:35.720 nodes anyway, how does that work? Like, what's the benefit? 281 00:15:35.759 --> 00:15:37.799 And I've seen, like some of the cloud writers a 282 00:15:38.000 --> 00:15:42.039 ws et cetera, have pretty bad versions of managed blockchain things, 283 00:15:42.120 --> 00:15:44.559 and I have yet to understand why they do that. 284 00:15:45.399 --> 00:15:47.320 I'm sure they're not good. I'm sure you have some 285 00:15:47.759 --> 00:15:50.000 opinions about that as well, but like I just don't 286 00:15:50.039 --> 00:15:51.200 understand what the point is. 287 00:15:52.120 --> 00:15:54.840 Yeah, So to come back to the point that was 288 00:15:54.879 --> 00:15:58.360 made earlier on actually, you know, the if you take 289 00:15:58.480 --> 00:16:00.600 a source, the fact that let's say for a developer, 290 00:16:00.639 --> 00:16:04.399 they have to firstly understand whatever this git repository is 291 00:16:04.440 --> 00:16:06.200 selling them in terms of how to set up a node. 292 00:16:06.600 --> 00:16:10.120 You know, I think there are there are a lot 293 00:16:10.159 --> 00:16:12.279 of good developers out there who have that skill set 294 00:16:12.320 --> 00:16:15.759 who can go from you know, like bootstrapping a Docker environment, 295 00:16:15.879 --> 00:16:18.519 running something in kumerinettes, et cetera, to then actually doing 296 00:16:18.919 --> 00:16:22.919 the code they want to do. But I think certainly 297 00:16:23.000 --> 00:16:26.080 there's there's a number of developers and I don't want 298 00:16:26.080 --> 00:16:28.200 to generalize anyone here, but there are certainly a number 299 00:16:28.240 --> 00:16:31.519 of developers who simply want to hid an API, and 300 00:16:32.399 --> 00:16:34.879 you know, let's say you need an Ethereum archive node 301 00:16:35.080 --> 00:16:39.159 or a Polygon archive node, you're talking about downloading for 302 00:16:39.320 --> 00:16:42.840 many days terabytes worth of data before your node is 303 00:16:42.879 --> 00:16:45.960 even ready to serve those requests. So yeah, So the 304 00:16:46.039 --> 00:16:49.600 simple answer is from from a developer standpoint, it's it's 305 00:16:49.720 --> 00:16:51.600 just plug and play. You know, you come up, you 306 00:16:51.679 --> 00:16:55.679 come up to our anchor website, you register, you start 307 00:16:55.720 --> 00:16:58.159 consuming traffic. If you want a higher rate limit, you 308 00:16:58.240 --> 00:17:00.559 pay a little bit of money. If you want lots 309 00:17:00.600 --> 00:17:02.159 of traffic, then you know, you come and talk to 310 00:17:02.240 --> 00:17:04.480 us about having an enterprise contract. So I think I 311 00:17:04.559 --> 00:17:06.720 think that's the main benefit for a developer. The other 312 00:17:07.759 --> 00:17:12.599 the other benefit, I guess is that ongoing maintenance version upgrades. 313 00:17:13.359 --> 00:17:16.279 You know, the redundancy that we offer and the latency 314 00:17:16.359 --> 00:17:19.519 that we offer, you know that that leads itself to 315 00:17:19.640 --> 00:17:23.480 an easier, let's say development and testing time frame for 316 00:17:23.599 --> 00:17:24.599 that specific development. 317 00:17:25.160 --> 00:17:27.839 So just you know something that I'll basically there's a 318 00:17:27.920 --> 00:17:30.519 lot of parts that go from doing this, like from 319 00:17:30.599 --> 00:17:34.519 the software development to actually running the nodes, like for 320 00:17:34.720 --> 00:17:36.799 the network, for the for the chain that's out there, 321 00:17:36.960 --> 00:17:39.759 and that's a lot of infrastructure, a lot of process, 322 00:17:39.920 --> 00:17:42.720 and that's what's being automated, either helping with the development 323 00:17:42.839 --> 00:17:45.640 side or the testing or rolling out for what the 324 00:17:45.720 --> 00:17:48.039 new versions are that users should pull down and start 325 00:17:48.119 --> 00:17:51.839 running within their Whoever the node hosting providers are, you know, 326 00:17:51.880 --> 00:17:55.920 whether they're general population or whether they're independent companies or whatever. Okay, 327 00:17:55.920 --> 00:17:57.400 so there's a lot of work that actually needs to 328 00:17:57.440 --> 00:18:00.440 be done there make this work effectively, and you're solving 329 00:18:00.720 --> 00:18:01.640 everything in that space. 330 00:18:03.599 --> 00:18:08.960 Absolutely, we are. Yeah, I like to think so. Yeah. 331 00:18:08.960 --> 00:18:10.839 I think really good perspective to put on that is 332 00:18:10.920 --> 00:18:13.960 if you are, like, if you're a developer who wants 333 00:18:14.079 --> 00:18:18.920 to create the like a cryptopunk n FT, you know, 334 00:18:19.039 --> 00:18:23.400 the only thing you're interested in is selling cool little 335 00:18:23.599 --> 00:18:27.279 eight bit graphics, and the barrier to entry to that 336 00:18:27.960 --> 00:18:31.519 without having access to hosted RPC nodes, the barrier to 337 00:18:31.759 --> 00:18:34.519 entry is you've got to set up a node that 338 00:18:34.720 --> 00:18:38.079 has terabytes and terabytes of data on it just to 339 00:18:38.319 --> 00:18:44.920 generate your your NFTs. And that's where services like anchor 340 00:18:44.960 --> 00:18:49.319 come in and take take that barrier away from you 341 00:18:50.720 --> 00:18:54.200 or remove that barrier for you. One question I want 342 00:18:54.240 --> 00:18:56.160 to ask, just to elaborate on it a little bit. 343 00:18:56.200 --> 00:18:59.880 You mentioned hard for earlier. Can you elaborate a little 344 00:18:59.880 --> 00:19:01.400 bit on what a hard fork is. 345 00:19:03.079 --> 00:19:07.440 Yeah, So, in the simplest terms, it's a breaking change 346 00:19:07.799 --> 00:19:13.839 which requires a version upgrade. So essentially, a blockchain will 347 00:19:13.920 --> 00:19:18.039 run to a particular block, and at that block time, 348 00:19:19.079 --> 00:19:22.000 the protocol is in the network, how it talks, how 349 00:19:22.039 --> 00:19:23.960 the notes talk to one another. They will undergo a 350 00:19:24.039 --> 00:19:28.200 breaking change, which means unless you're running this new version 351 00:19:28.279 --> 00:19:31.240 of software, your node is basically going to sit there 352 00:19:31.279 --> 00:19:33.759 stalled and isn't able to communicate with the others here 353 00:19:33.839 --> 00:19:38.000 with them and then you know, propagate blocks and receive transactions, 354 00:19:38.039 --> 00:19:38.480 et cetera. 355 00:19:39.480 --> 00:19:42.960 So I've always looked at this as imagine the blockchain 356 00:19:43.079 --> 00:19:45.720 is your database, and so of hard work is where 357 00:19:45.720 --> 00:19:48.519 you make a non back whards compatible change to the 358 00:19:48.599 --> 00:19:50.920 schema of the database, and all of the clients of 359 00:19:50.960 --> 00:19:53.119 the world need to decide how they're going to interpret 360 00:19:53.240 --> 00:19:56.519 that new new schema of the database. I don't know 361 00:19:56.599 --> 00:19:59.640 that's always worked for me. I don't know if that's accurate, but. 362 00:20:01.880 --> 00:20:04.440 No, there's no harm in that description. Yeah, absolutely. I 363 00:20:04.480 --> 00:20:06.799 think the key element you've got there, right, is that 364 00:20:06.880 --> 00:20:10.480 it's a breaking change, and yeah, that's the main thing. 365 00:20:12.279 --> 00:20:14.359 Yeah, and I think the unique constraint to it is 366 00:20:14.480 --> 00:20:20.599 that the decentralized aspect of it, because when you hit 367 00:20:20.720 --> 00:20:26.160 that block, you're now dependent on everyone who operates a 368 00:20:26.319 --> 00:20:30.559 node on that network, or not everyone, but a majority 369 00:20:30.599 --> 00:20:33.680 of the node operators on that network to adopt that 370 00:20:33.960 --> 00:20:39.079 change and implement it. Otherwise you end up with a 371 00:20:39.160 --> 00:20:43.440 network that now has multiple people claiming that they have 372 00:20:44.400 --> 00:20:45.240 the latest block. 373 00:20:46.519 --> 00:20:47.960 Yeah, yeah, absolutely. 374 00:20:48.440 --> 00:20:50.640 I mean that's an interesting thing here because let's say 375 00:20:50.640 --> 00:20:54.480 the Web two world, if you've exposed your internal database 376 00:20:54.519 --> 00:20:57.400 to your customers and they're you know, making I mean, 377 00:20:57.519 --> 00:20:59.440 no one would ever do this, right, No one ever 378 00:20:59.519 --> 00:21:03.240 did this history of the world, for sure. But you know, 379 00:21:03.400 --> 00:21:06.119 your customers have access to the schema, to the underlying 380 00:21:06.200 --> 00:21:07.960 data that you have in your database, maybe with their 381 00:21:08.000 --> 00:21:11.519 own special user name and password, and you make a 382 00:21:11.559 --> 00:21:13.960 schema change there. I mean, in the Web two world, 383 00:21:14.079 --> 00:21:16.440 I just can't ever fathom a story where you like 384 00:21:16.519 --> 00:21:18.799 go around to each of your customers are like, Okay, 385 00:21:18.839 --> 00:21:20.559 we're going to make a change. I need you to, 386 00:21:21.160 --> 00:21:25.119 you know, change your software to actually support this. And 387 00:21:25.400 --> 00:21:27.279 having worked in a bunch of these companies where we 388 00:21:27.279 --> 00:21:29.799 even had an API, you know, rest or you know 389 00:21:29.920 --> 00:21:32.799 something else, Getting your customers to actually make a change 390 00:21:32.839 --> 00:21:36.480 and start using the latest version is I mean, that's 391 00:21:36.559 --> 00:21:38.880 a gargratuan task that I don't think I ever saw 392 00:21:38.920 --> 00:21:41.200 a company actually do successfully. Oh yeah, we'll just make 393 00:21:41.240 --> 00:21:43.640 a breaking change and get all our customers to update. 394 00:21:43.880 --> 00:21:47.440 Was easier said than done. And I feel like in 395 00:21:47.559 --> 00:21:50.839 the blockchain world you actually end up in this state 396 00:21:51.000 --> 00:21:54.240 where you have customers I'll call them customers, not really customers. Right, 397 00:21:54.400 --> 00:21:58.160 the end users who are using utilizing the chain will 398 00:21:58.240 --> 00:22:01.319 have still been using the previous software version, which doesn't 399 00:22:01.400 --> 00:22:04.160 understand what happens after the fork, and that's sort of 400 00:22:04.200 --> 00:22:09.559 what creates this maybe two future chains or whatever you're utilizing. 401 00:22:11.079 --> 00:22:13.839