Anna (00:00):
So today we're chatting with Dieter Shirley, who's the CTO of Dapper Labs and the chief architect of Flow blockchain. Welcome to the show, Dieter.

Dieter (00:09):
It's great to be here. I'm fans of the podcast. So it's a real pleasure to be here and chat with both of you.

Fredrik (00:15):
Thank you very much. And welcome.

Anna (00:17):
Dieter. Tell us a little bit about yourself. What got you started? What are you into and also your name is Dieter. Do you happen to have any like German ancestry or something?

Dieter (00:26):
Indeed, indeed. It is the case. My mother is German. I do not speak a word of German, but her first language was German. And so yes, my name is Dietrich, but I am the only Dieter. I know which for people living in Germany seems like a really strange thing to say, but it's very uncommon here in Canada. Yeah. So the story, the story of how we got here is a long and circuitous, but you know, I think my whole life has been about making technology accessible to people. Back before Apple was cool I was in the Apple because they were like the only computer company that seemed to care about making computers that people could use. So when I started working for Axiom Zen in 2013, and they were building all of this cool technology, but trying to find a consumer bent for it, it was really like coming home.

Dieter (01:12):
And it was it's funny. Like I was 20 years into my career and I finally figured out, you know, where I want it to be because actually working at Apple, which I thought was my lifelong dream ended up being quite, quite terrible because it's quite corporate or at least the parts where I was working. And so we did all sorts of interesting stuff. We researched machine learning and natural language processing, and we did lots of stuff with VR and Google glass and all of that stuff. But crypto was actually something that I was really excited about. And so in 2017, when sort of the crypto world blew up, it made sense for Axiom Zen. Who's this sort of startup Foundry, where we're always trying out new technologies and trying to create interesting new consumer oriented products that surround them. I got into my head that we needed to do something in crypto.

Dieter (01:57):
And so we spent a bunch of time looking into this. And of course what came of that was CryptoKitties. And, you know, the, the goal of CryptoKitties is, was to take this technology that was esoteric for most people. It seemed entirely financial in nature. And just say, no, this is not what this is about. Like, yes, Finance is part of it. Finance like the blood that flows through his veins, but that's not what all of the life about it has to be. And so we wanted to create something that was personal and had a connection to people. And that meant that it was something individual. And so, you know, everyone kept talking about ERC 20 and like, how do we make the CryptoKitties, ERC 20 compatible? I'm like, you guys are crazy. They're non fungible. We can't make them work with the ERC 20. And so of course we wrote I wrote ERC 721 first draft of that and of course the community was the, you know, it was ultimately a community product when it, when it was finalized. But so we put that out and then we released CryptoKitties.

Anna (02:55):
Yeah. We remember Fredrik was just saying this, I think our third and I don't recommend people listen to it, but our third episode it's very bad episode. But in that episode it was right around the time that I think CryptoKitties was launching. And we were talking about it for sure. Over in Berlin, everyone knew. It was kind of clogging up the network, I think, right. It was like the cute little kitty that broke Ethereum for a moment.

Dieter (03:20):
Several million of them. But yes, it's funny cause you know, of all of all the work I've done in my life, the thing I never expected to get cited in academic papers is CryptoKitties. But of course that is what I, you know, when I'm reading papers from various things, they often use that as an example of, of how this stuff can get out of hand. So anyway, so we built CryptoKitties and we were just on top of the moon. We spun out Dapper Labs as its own company. We took investment with, you know, joint leading investment from union square ventures and Andreessen Horowitz. And we were like ready to go. And we were, we were getting phone calls from IP holders.

Anna (03:59):
Wow. This was like 2018, right?

Dieter (04:02):
Late 2017, December of 2017 was, was when CryptoKitties went nuts.

Anna (04:06):
And that was when, where did you actually build that? Where did it come from? Wasn't it from a hackathon.

Dieter (04:11):
We demoed it at a hackathon.

Anna (04:13):
Okay. I always thought it came out of Waterloo.

Dieter (04:16):
The story is, is that at ETH Waterloo, we, we built it. But the reality is, what people played with at ETH Waterloo was actually many weeks of work. Anyway, it would be very difficult to build that at a hackathon, the project we did do for the hackathon was one of the winners, but that, that never became a product. So yeah, so we were very excited. And so the business team was like lining up all these partnerships and they're like, we're going to do, you know, Jurassic Park with crypto, like for crypto kitties or like crypto park, right. Crypto dinosaurs. And I had to send, it was like stand in front of the hoards of business people and say, no, we can't like, why do we want to use these IPS? Because that's a way of attracting more users. We don't need more users.

Dieter (04:59):
We already broke the network. We need to figure out how we can scale this stuff. You know, we had a whole team that was building dapper wallet smart first, you know, first and largest now smart contract wallet for Ethereum. And we were looking at other game ideas that could run on Ethereum. And you know, we had Cheese Wizards come out last year. But what I did was I took a group of engineers and I said, well, let's go find another blockchain. Let's find a blockchain. You know, it's clear that Ethereum, as it stands today is not going to be the future of this technology. So let's go find what the future is going to be. And of course, we started with Ethereum 2 saw that it was dependent on sharding. I was like, Hmm, how does that doesn't seem right to me, sharding doesn't seem right to me.

Dieter (05:39):
It seems like it's going to make building smart contracts way harder. And it's already hard enough. Thank you very much. And so we went and we just, we like, you know, at that time, like it was the ICO fever in 2017, everybody and their dog had an idea for a blockchain. And I swear, we read all their white papers. It must've been a hundred. And we talked to sort of 20 different teams, as you can imagine, it, wasn't difficult to get a phone call with when you, when you dropped the CryptoKitties name and all of the projects either fell into, I mean, some of them were just bad, but they are there fell into like depending heavily on sharding or depending heavily on limiting participation in some way. And we just felt like that neither of those things felt like the answer to us.

Dieter (06:19):
And so, you know, I sort of locked all the people. Who'd read all those white papers in a room together and said like, do we just have to put up with this? We just have to put up with sharding. Cause that seems like it's going to be hard, but it's better than not letting people participate. And it's better than, you know, not letting this stuff scale. And we took inspiration from CPU design and pipelining, and that was the origin of the, what became the flow architecture was this idea that we don't have to make every note in the network, do the same work. We can have them specialize. We can have them do different pieces of the work and by doing so we can actually optimize different parts instead of on the scalability trilemma, right? Like you have those three, three sides of the triangle.

Dieter (07:05):
Each part of the network doesn't have to be in the same place on the triangle. And so what we can do is on the places where, where the security matters, we can be highly secure and we can pull the complexity out of that. So the scaling is less of an issue. And on the places where the work is hard, where the computations are expensive, we can make sure that they're only tasked with doing deterministic operations. And so security is no longer important because as long as we can check their work, we don't need to have like a million people all doing the same computation

Anna (07:36):
That actually, like one of the questions I had was why did you decide to build this like as a standalone chain? But I kind of, before we go completely into that, I want to just kind of go back to, like you had created Crypto Kitties, CryptoKitties still exists, right? Like CryptoKitties as a NFT, still exists on the Ethereum network. But I always understood that the CryptoKitties ERC 721 that you used actually was slightly different from the standard that was finally delivered. Did you change the CryptoKitties after the fact to reflect that? Or is it the same thing from 2017 - ah fair Well, aren't there smart contracts are upgradable somehow, or you could redeploy it I suppose, but because it has to live forever, you can't or something.

Dieter (08:22):
So we, we do have some options. We could put out a smart contract that sort of wraps it. So that you could put your NFTs, assign the ownership of the original Crypto Kitties to this other smart contract. And then it could sort of forward through we haven't done that. Although I, you know, it does seem like it's a pretty good idea. Now it's not a good time. It's just be deploying new smart contracts is fairly expensive. Not a lot of people are doing much with CryptoKitties right now, but I do think that's one possibility is to sort of create that wrapper contract. The problem with that is it just increases the gas price of everything, right? So you have to end up calling a thing and it calls the thing and everything gets more expensive.

Anna (08:56):
And I guess basically you're still struggling on that front with the same issue you were struggling with to some degree as you were in 2017, like it's not like the network has evolved that much since then. So...

Dieter (09:07):
It really hasn't. And you know, and, and I mean, look, it's a testament to how bloody useful this stuff is that people are willing to use it when it's, when it's this quote unquote bad, it's not bad. Right. It's not up to the scale that, that the number of people who want to use it, which again, is a sign of, of how successful it's been. But yeah, so the story with the 721 was that we put together a draft, we published it, we asked for feedback. I sent some emails to some people who, you know, seem to be doing something, you know, sort of on similar directions, but there weren't very many, so we had hardly any feedback. And so no one was like saying much about it and we're like, okay, so we published Crypto Kitties. And of course, then everyone had, you know, all the energy in the world to nitpick ideas and, and provide suggestions for how seven 21 should be. And, and I do think the standard definitely improved with that attention, but of course, by that point in time, it was, it was too late for us to sort of meet the exacts.

Anna (10:06):
Actually we did an episode all about the ERC process all linked to it in the show notes. And in that we definitely cite this as an example in the, and the ERC 721 is like the focus and how that developed after the fact. So that might be interesting for people if they want to see kind of where that went. But we hadn't had a chance to speak to you yet. And so this is cool to kind of finally wrap that story. Yeah.

Fredrik (10:28):
I think that's always the case with standards though, is that it requires that attention to really get to a good level, right. Where, I mean, you have the same case. And I was watching this video yesterday about the standards of EV, like electric vehicle plugs and Tesla was the first to come out with a good plug and then the industry standardized around them. So now standard like Tesla is the only one that doesn't follow the standard anymore.

Anna (10:59):
Pushed the standardization effort, I guess.

Fredrik (11:01):
Yeah, because they popularized electric vehicles and yeah, now there's huge pressure on Tesla to like, Hey, what the fuck is up, guys? Just follow the standard. Cool. So you described a fascinating story and how you got to like, okay, we just got to do this ourselves. You looked at a bunch of options, but what was your, what was your design space? Really? I understand the desire to not shard like the ETH2 model of sharding while still unclear, potentially like, especially around 2018, they were talking about automatically rebalancing shards and all this stuff. And that obviously it is making smart contracts incredibly hard. But what was your other design constraints? So what was the scale that you were actually looking for and what were you looking to push?

Dieter (11:54):
I'm a, I'm a huge believer in state channels. I think that that's a technology that, I mean, I imagine a day when blockchain games are like normal games, like the normal games that we played today, except their net code is state channels. And I don't think that's an impossible dream. Like I think that fundamentally that's it, we could get to that point where we're using state channels to play video games. And no one even thinks twice about the fact that every single video game is completely fair and provably. So because both sides are signing every single action that's happening and, and, you know, confirming that the actions that the other side is taking are valid. So I think that the state channels are really important. Plasma always was something that a lot of people said that we should look into. But it always, it always seemed to me be a bit too hacky.

Dieter (12:41):
But when we thought about layer two solutions, the security of every layer, two solution depends on the ability for people to sort of quote unquote escape to the main chain and the ceiling on what can be done on main Ethereum was so low that even a, I don't even think it has the capacity to handle consumer scale just as a base chain with, with layer two. So now you could say, well, we'll have lots of layer twos. Right? Well then you're just starting again. And so the idea of saying, well, let's use Ethereum sort of as, you know, what we would call the consensus layer, right. Because when I said we were splitting the functionality, right? So we have a group of nodes who are building a chain through consensus. And, you know, one statement is, well, couldn't that be a Ethereum or I suppose, Bitcoin or something else.

Dieter (13:29):
And the answer is, I don't think it could, because it, in order to handle, like I said, consumer scale, that base layer needs to be able to handle, I think at least an order of magnitude or two more than what Ethereum can do today, just for that control channel. And so, so that was, that was a big concern. We also wanted to go to proof of stake. We didn't want to have anything to do with proof of work. I know lots of people have, you know, sort of a, an affinity, I don't know, sort of a, like a visceral feeling of the value of proof of work. But I I've always felt that that was a little bit more philosophical than practical. And so we, we definitely wanted to move to proof of stake, but we needed to have a higher capacity based chain in order to, to really hit the targets we had.

Anna (14:14):
What year? Like, what timeframe did you make that decision to shift to your own chain?

Dieter (14:20):
Yeah, it was the spring of 2018. Yeah.

Anna (14:22):
The Beginning. Okay. Cause like, since then there are now a lot of base chains, L1s that now have like the capacity to either build on top of them in a very different way. Have you ever looked around since then and been like, Oh, shame that wasn't there when, when we were building it or do you feel like, do you think you will end up connecting up with another ecosystem that exists? Or do you really want to build your own? I guess it's this is the L1/L2 interoperability question that comes up a lot

Dieter (14:52):
Yeah. So, so there Is financial interoperability is through these chains that you know, through like binance and Coinbase, if nothing else. Right. Yeah. And so then the real interesting question is, well, what can we do in terms of like trustlessly moving stuff between chains and what can we do about actually moving, you know, like sort of like smart objects, like a CryptoKitty, right? Like I can lock up a crypto kitty on Ethereum and I can create a copy of it on another chain. But it can't breed over there, because the breeding algorithm has to, you know, it has their shared state there. And so you can't, you can't move that thing away because it can't have actions because the actions that it takes depend on the shared state and the shared state is somewhere

Anna (15:34):
Because it actually mutates, like it changes it doesn't, it's not like tokens. You can kind of like lock on one side, go do stuff with it and then the same tokens or the fungible tokens will come back and you can see it

Fredrik (15:45):
They'll don't do anything right there. They're passive. Whereas CryptoKitties are active. And I think lots of interesting things can happen on blockchains that are active. So do I think that that's going to happen? Of course it's going to happen. It's too valuable. It's too, it's too useful. But I also think that that's going to be incredibly limiting. And so like, yes, it will happen. Yes. It will be useful. But I don't think that you'll be able to have, I don't yet know of any mechanism by which you can move an object with its code and then feel like you can trust that that code is going to be properly respected on the system when it comes back. And certainly not any shared state, like that's, to me, the state is the thing. Right. And that's why sharding is problematic. And that's why my cross chain communication is problematic.

Anna (16:28):
This goes to you Fredrik, but like in the, in the Polkadot system, would you, if you had something like an NFT on one of the chains, do you know if you could actually use the Relay Chain to like move it over?

Fredrik (16:37):
Yeah, of course you can. Yeah.

Anna (16:39):
State is, is kept somehow through that.

Fredrik (16:42):
The state would still be kept on one of the chains, but the other chains can read that state and this kind of shared codes thing that Dieter is talking about. Can you move the object with its code? That's still very much a topic that's up for debate. Right. But the way we think about it, as you have some shared code on like the relay chain in what we call spree and shared, protected her on time, and that code is what defines, like your breathing, breathing algorithm, for instance. And then you can have your States on one chain, your code on the relay chain, and then the NFTs can all be spread out and on chain X that no one's ever heard about, they can still breed because they can read the state through the SPREE module on, on the CryptoKitties chain. So that, I mean, there is a vision for that, right. I think you can solve all of these problems in a shortage. Like it depends on charting is such a weird thing. Cause like, if you look at it hard, hard enough, everything ends up being charting. Like when you,

Fredrik (17:51):
When he's talking about the structures that you've come up with where you have certain responsibilities within sub networks kind of right. That's kind of sharding too. It's just that the, you have domain specific shards. Hmm.

Dieter (18:05):
Yeah. And, and that's, I mean, I think that's the essence of why flow is different than other blockchains is that we sort of chopped it the other direction. Right? Like if you think of shards as sort of these vertical slices, we have these horizontal slices where there's, there's different layers instead. But yeah, it's certainly the case that there is no way for everyone to do all the work and for you to scale. Like that's just simply not possible. Yeah.

Anna (18:28):
So that, so you've created this purpose built blockchain for NFTs specifically, but I'm thinking it might make sense for us to talk a little bit about like, what are the properties like, what are these NFTs that are supposed to live on this?

Fredrik (18:42):
I guess a question from me is how purpose-built is it actually I mean, we've talked about it in the context of, of CryptoKitties and where this spawned from, but to me you haven't described anything that makes it specific to NFTs or, or games or any particular application just sounds like you've yeah, you've done this horizontals split of responsibilities, but you could really, that could still be a generic chain.

Dieter (19:08):
Yeah. It is a generic chain. It is intended to be a general purpose blockchain with the benefit of being very high capacity and not resorting to sharding and still being amenable to why participation. I, it's sort of easy to cast us as the NFT people. And obviously we care a lot about that.

Anna (19:25):
That's how I thought about you obviously,

Dieter (19:28):
And look like it's the mission of Dapper Labs is to bring the power of decentralized technology to regular folks. And the means by which we're going to do that is not by explaining Byzantine fault tolerance to them. It's going to be creating experiences that are fun and interesting, but that nonetheless unlock capabilities that you can't have in centralized systems, right around true ownership and unbounded longevity where like the experiences can outlive the companies that created them which has never been true for social software before. And so, yeah, of course, we're a games company. We're an entertainment company. That's how we're going to get people interested, interested in this stuff. But when we were looking at blockchains and people came to us and said, Hey, you should build on our blockchain. It's the game's blockchain. I always like I would come out of those meetings and I would like throw my hands up.

Dieter (20:16):
And I would say, who wants to be stuck on a blockchain? That's only for one thing, right? Like who wants to build a computer? That's only good for one thing, if we're building this giant global shared computer, let's make sure it can do all the things. And so, yeah. So Flow has always been about that. Now having said that, right, our products are NFT products. The products that we're working with, most of our partners on have NFT, as a strong component to them, because that is the thing that most consumers have an easier time latching on to, but I don't think that's where it ends. And you know, it's not where it started and it's definitely not where it ends. And so I think that that's a really important lens for getting people into this. There's nothing about Flow that was designed with a little, but how do we make this better for NFTs?

Anna (21:02):
Okay. So, but then what does Flow look like? Is it, is it an account based blockchain, similar to Ethereum in that you build smart contracts on top of it that just interact with these different sort of zones for different purposes?

Dieter (21:18):
Yeah. I mean, I think, I can't remember if you guys have done it. I haven't listened to it if you have, but have you ever done a blog, a podcast on optimistic roll up?

Anna (21:27):
No, but we've done like ZK roll up a lot. Right. So we might've mentioned optimistic couple times

Dieter (21:32):
Because, and we didn't know about optimistic roll up. I don't think if anyone had been talking about it in 2018, but now that people are talking about optimistic, roll up, what we've realized is that Flow is actually just optimistic roll up, taken to its logical extension. And so if you think about optimistic, roll up, how does it work? Well, you go in, you register a bunch of transactions on the base chain, you know, so that there's a public record of who wants what done and what order should be executed in. Then you have this guy with a really powerful computer burn through all of that stuff and then publish a result. And if they're right, they get paid and if they're wrong, they get slashed. And so you assume that there are like sort of multiple people who are doing this computation so that if somebody tries to, you know, pull a fast one and, and publish an invalid state transition that someone else will point it out and say, Hey, that's wrong.

Dieter (22:20):
And because the set of transactions in their order is defined in this public place. The output is objective. There's an objectively correct output, state transition because everything is deterministic. And so if you start with that, right, that was, that was the sort of the insight we had early on that you then ask yourself, well, what are the problems with that system? Right? So the advantage that system is, is that you can imagine that scaling to just an insane level, you know, you can say, well, if we only have a very small number of nodes doing this execution, the transaction execution, why do we have to start Merkle Trees in a database? Let's just store it in Ram, right? You can get multi terabyte, Ram instances in data centers. We only need a half a dozen of these machines around the world doing this stuff.

Dieter (23:04):
So suddenly like the ability your throughput can go through the roof. Why does it have to be one computer? Right. Well, forget multiple CPUS. Why not multiple computers? Why not do like optimistic concurrency where you're like executing a thousand transactions in parallel looking at what registers they're reading and writing to, and then going through and saying, Oh, well, these two don't conflict. So I can just take those two results. Oh, this one conflicts, this, that one I'll rerun it. Right. But 90% of them probably don't conflict. And so you can just run them in parallel and then only have to rerun the few that had conflicts. And so you can end up extracting parallelism from something that is inherently a serial that looks serial from the outside, right. This serialized from the outside. And so when you look at that idea, you're like, wow, that's amazing, right?

Dieter (23:50):
Like the throughput limits on what optimistic Barolo can be or are in maths. So what are the weaknesses? Well, the first roadblock you're going to run into is that the number of transactions that you can record on Ethereum, even if you're just using call data, you're going to hit a limit pretty quickly because all of the consensus nodes, and even if you change like the gas limits. And I know that I don't know if it's happened yet, but they're talking about decreasing the cost of call data for exactly this reason. And eventually you hit a point where the blocks bite size starts to get really big, right? The amount of data just representing the transactions gets really big. So what do you do about that? Well, the consensus doesn't really need to have the text of the transactions. It just needs to have like some sort of representation of what those transactions are, right. So why not just put a Merkle proof in there? Why put all of the transaction texts in the blockchain let's have another set of people? Oh, we can call them collectors. Right. And Ethereum is toyed with this idea through something called co-leaders, which was being discussed in, I think 2017 and 2018.

Anna (24:54):
And the collectors actually show up in the polka dot infrastructure, as far as I know.

Fredrik (24:57):
Well, it's slightly different role. I mean, so you're talking about a set of people who provide data availability.

Dieter (25:04):
Well, it's actually specifically the collectors. And as I understood co-leaders

Dieter (25:56):
And so now you have these consensus nodes that are able to, you know, indirectly include million transactions in a block. Why not? Right? It's just hashes of hashes of hashes, right? So you can imagine a very lightweight computer being able to participate in consensus. Cause all it's doing is signing these very small blocks, no reason why they ever need to be more than a megabyte in size, even if they do represent tens of thousands or hundreds of thousands of transactions. And, and so they can have a very, very fast block time and very fast propagation speeds. So then the next question is, well, how do we know that the execution nodes are actually watching each other? Right? So the validators dilemma or the verifiers dilemma, I can't remember, I always get wrong. So how do you, how do you solve the verifiers dilemma?

Dieter (26:41):
Because in optimistic up, you know, sort of the version that we talk about most often, there's this idea that like, Oh, well there's going to be five or six people who are all, you know, at least, right. There's gonna be a bunch of people that are all doing this execution. If someone makes a mistake, someone else is gonna immediately jump in and give an error. But we know from the verifiers dilemma that if the leader is too good at solving the problem that the incentive for the followers goes away. And so if I have a really fast computer so that, you know, whenever Fredrik wants to post an answer, I'm always just a little bit faster than him. And I don't have to be much faster than him. I can be 2% faster than him and I will win that race 90% of the time.

Dieter (27:23):
And so now he's running a computer that's just as expensive as mine, except he's only getting paid 10% of the time and I'm getting paid 90% of the time. And he's only hope to make money is to catch me in a mistake. Well, how long is he going to run that computer? Right? Cause remember we're imagining a data center with, you know, terabytes of Ram and multiple CPUS and like this like huge collection of SSDs. That's how we're getting this amazing scaling, but that's expensive. And so now you have to say, well, maybe we just have to like build a system where we pay for multiple executor's at all times, right? Where executor's, aren't just people who come in propose answers. And we hope that someone else also did the execution. We actually say, no, everybody has to do it. Right. We're going to have five or six or 10 of them.

Dieter (28:08):
Let's say 10, we're gonna have 10 of these guys and there'll be staked. And they'll all be expected to produce a result. And if they don't produce a result, then they don't get paid. And so everybody producing a result.

Fredrik (28:19):
How do you verify that they did the work though?

Dieter (28:23):
We'll get to that in a minute. We'll get to that in a minute. So the next question is, well, but that's still pretty darn centralized, right? Even if you have five, you have 10, how well, how much is decentralized enough? Right. I said earlier that like, I, you know, I felt like something like 20 or a hundred, probably isn't enough. And now I'm talking about 10. Surely that's not decentralized enough. And it isn't right. That's not decentralized enough. That's too easy to capture. It's too easy to, to stake for all of those or stake for enough of those.

Dieter (28:49):
And then DDoSs the other ones so that you can get an answer. And so then you have, that's where their verification notes come in. And so our verification notes, what they do is they check part of the computation and this part is subtle. And, and actually metallics talk at Devcon in Osaka, which seems like a million years ago, but was actually just like 12 months ago, not even, yeah, yeah. Was about exactly this. And it was very gratifying to see them talking about it. Cause we'd been, we were already at that point building exactly those systems, but it's this idea that if you have a linear computation, it is the case that to create that computation, you do have to have all the data and you do have to have all the state and you do have to run all those computations in order.

Dieter (29:36):
But if the person who is proposing the solution takes snapshots at partway through that anyone can come along and they can, they can inductively check that the milestones between two milestones is correct. And you can have dozens of different people in our case, we're planning for hundreds, if not thousands of these verifier nodes that they will each check, just, just a few of them between these two milestones, these checkpoints, but collectively they will check the entire block dozens of times. Then you need to use some system whereby the executor's don't know who the verifiers are going to be to check the thing. Because if I know that, you know, Frederick's going to check my answer, then I'm going to be honest. But if I know that Anna is going to check my answer and Anna and I have a little special deal on the side, that's when I can slip the error in.

Dieter (30:28):
And so I can't know when I publish my answer, who's going to be checking me. And so that's built into Flow as well. So now we come to the other part of the verifiers dilemma, which is not just that I go away, but then I just start rubber stamping. Right? And so the verifiers dilemma, you know, one problem is, is that people just don't bother to participate. And the other is, is that they get lazy and they just say, yes, that's correct. You know, the incentives are such that this person would only rationally produce a correct result. So why would I even check it? I'll just rubber stamp it. And so we have these different execution nodes. How do we know that each of them is doing the work themselves? We have these verifiers they're being asked to confirm that the state between checkpoint A and checkpoint B that state transition is correct.

Dieter (31:13):
Why don't they just say yes. Right. And so we looked at a bunch of different ways for doing this. So Arbitrum, is a team offchain labs. They have a system where they what is their thing? It's like a, it's almost like a lottery where if you, if you compute the result, they hide the result and then you compute the result and then you have the result with your public key. And if it's, you know, has a particular ending, then, you know, sort of like a proof of work, you know, if it has a, if it starts with a bunch of zeros, then you win a lottery. And so I'm computing the result before it's released. And then, you know, I can win the lottery. And of course that incentivizes me to compute the result problem with that is, is that you have to wait to release the result until after everyone's checked the work.

Dieter (31:54):
Truebit of course solves this problem by forcing errors. And so someone publishes a result and they have sort of like a random die roll again, based on deterministic hashing, et cetera, that with some small probability that they produce an erroneous result and that has to get caught kind of, and it has to get caught. And then, and then have this whole circular game where like, well, the person who produced the erroneous result knows that it's an erroneous results. Of course, they're going to flag the error. And so you can't just say that the first person who flags the air is going to get it, et cetera, et cetera. And so we came up with a system that we call Spock's which is for a specialized proof of confidential knowledge. And the way it works is you imagine that every computation produces as a side effect, some amount of data that doesn't appear in the output.

Dieter (32:44):
So for example, it could be just which registers are being read and written to. It could be randomly, you know, hashing the program, counter into an accumulator, you know, every 10 instructions or something like that. Something that when you're actually doing the computation is trivial to compute. But when you only see the input and the output is more or less unknowable, so then anybody who's actually done the computation, they have that, that's just free data that they've got on the side. And so then the part is how do you publish the proof that you have that data in a form that someone can't just then copy the proof and say, Oh yeah, I've got that data. See, I've got this proof. And so that's where the specialized proof comes from. And so we originally had a construction that used CDSA our cryptographic engineer working actually with Dan Benet.

Dieter (33:34):
One of Dan Benet grad students was able to adapt it to the, by linear mapping. I can't remember pairing, I can't remember the exact term, but the thing that BLS uses the cool by linear pairing thing that the BLS uses, you can actually set it up. And I, unfortunately, I don't know, off the top of my head enough to explain it. And I'll be honest, even if the paper were in front of me, I'm not sure I could explain it.

Anna (33:56):
Send us the link to the paper though. And we'll add it in the show notes in case anyone wants to read in.

Dieter (34:00):
Yeah. I don't know if it's been published yet. The new formulation that uses BLS, but more or less the essence is that I combine my private key with this secret data in a way that you can confirm that like, so let's say Fredrik is the one who's getting the result, Anna produces her Spock. I produce my Spock. There are different Spocks Anna can't produce her Spock from my Spock, but Fredrik do use BLS, you know, use the Ellipta curve with the by linear mapping to confirm that both Anna and I must have started with the same data, even though that data hasn't been leaked. And so what we can do is we can prove that we have this value, whatever this is, some, some hash of something. And the only way that we can produce our Spock is by having that data. And as I said, that data is not possible to guess from the result too, it's a side effect of actually doing the computation. So it's a way of making sure that everyone whose job it is to verify this stuff actually verifies it because that's the only way that they can create that Spock.

Fredrik (35:12):
So to sort of recap a little bit, you have a blockchain in which there's a core consensus layer where you're just recording, essentially the Merkle root of a block. The transactions, and the transaction data is maintained and made available by a set of collectors. I think you called it. Correct. And you have a third set of entities, who, well, a third and a fourth, a third set of entities who execute those transactions and then publish their sort of intermediate snapshots. And then a fourth set of entities who take those snapshots and recomp, like verify parts of that execution. One question with that structure that I have is how do you reach consensus among the people who execute those parts of the block? Because if you have hundreds of these people executing or like re-executing parts of those box, it feels like they would have to then like resolves have to be registered in some way they have to vote. Yes, this is correct. Or this is not correct, which starts looking like a second layer of consensus.

Dieter (36:21):
Yeah. So I thought you were asking a different question. I'll answer that really quick, which is how do we even decide who's checking which bits and that's done because we built a Definity style, random beacon into the chain. And so every block has a deterministic randomness associated

Fredrik (36:38):
I sort of assumed that that was the case. Cause I couldn't imagine any other way.

Dieter (36:43):
And so this question actually comes up a lot because we're so used to this idea of like voting and, Oh, well, you know, six people say it's true and four people say it's false, then it must be true. Right. But that's not how it works at all. What happens is that a block is not sealed and that's the term we use for a block that has been executed and verified and it should be considered, the result should be considered on rewindable. A block is not considered sealed until we have positive confirmation from a sufficient weight of verifiers that are all putting their state behind the statement that this is correct. Right. So it's not just a, Oh, no one said, there's a problem. Therefore it must be correct. Right. We actually wait for them to say, yes, I check this. And it's correct.

Fredrik (37:25):
Who, who are we, who are getting those?

Dieter (37:29):
Right. So we're going back to the base layer again. And so that base layer, if any, a single execution node or verification node, or even any other stake to node detects and error, they flag that and they, they send it to the consensus nodes and they say, Hey, here's a signed execution receipt from that execution over there. And they claim that this state transition from here to here starts with this Merkle route and ends with this Merkle route. But the third transaction in, I found an error and they can point exactly all of that. Right, right. Down to the single transaction and say, this is where the first transaction happens in this chunk. You go check it. And the consensus nodes themselves, they just execute that one transaction. They can see all of the Merkle proofs up to surrounding that. And they just execute that one transaction and they can say, yup, you're absolutely right.

Dieter (38:25):
You caught it. And so a single, honest execution node is all that's needed in order for the network to mean a live and correct, and a single, honest verifier. That happens to be assigned if you happens to check that block, right. So certain number assigned to it, but they can check other ones if they want. I don't know if they, we, we should expect that in that, in the live system, but we require that that dozens of them are checking each one. And so, you know, you can prove probabilistically that even if, you know, a very large fraction, but still under the one third assumption are willing to lie that somebody somewhere is gonna find it. And so it doesn't, it doesn't depend on a sort of majority makes right thing.

Fredrik (39:06):
Yeah. It's a very interesting architecture you're taking sort of the computational model of, of true bids combined with some sharding aspects of data availability and how you split out the responsibilities. And yeah, it sounds pretty cool. What I wanted to just end on a sort of more philosophical note. Cause when you started talking about the problems of the existing systems, one of the problems that you mentioned was limiting participation and you still limit participation, right? Like you can not, anyone can be an execution node, maybe like protocol wise. If you have a computer that's as powerful you can be. But in reality, most people can't be. And if you talk to like Bitcoin people about limiting participation while having a block size larger than one megabyte is limiting participation because not everyone has that fast internet connection. And there's obviously extremes on both ends. Where do you see that? How do you see limiting participation and how do you, did you take that into account in the design of the system? And like, what do you mean by it?

Dieter (40:12):
Yeah. So the collection nodes and the execution nodes have virtually no determination over what happens in the blockchain. The consensus nodes are the ones that are building the blocks are the ones that are conducting all of the slashing operations. The verification nodes are the ones that are, you know, making sure that the execution will stay honest. And so, yeah, not everyone can run an execution node, but almost anyone should be able to run a verification node. We imagine these chunks that they're checking, being very small. So to say that like in a sharded blockchain say like, eat to where you're like, Oh, well I'm checking every single transaction in the shard. Yeah. But there's still a bunch of other shards that you're not checking. And so, you know, at the end of the day, it all comes down to, well, I have to trust that's that enough.

Dieter (41:01):
Other honest people exist in this network to check the parts of the network that I'm not checking, but at least I'm participant, I'm checking something. I'm a part of the system that keeps it safe. And those consensus knows in those verification nodes are the ones that keep it safe. And what's more is, is that they by design, they represent the vast majority of the stake. And therefore the vast majority of the rewards. Now, the rewards for running an individual execution out will be very high, because we imagine that there's going to be sort of on the order of 10 of those. And there's probably going to be, we hope hundreds of consensus notes, and we hope thousands of verification notes. Fundamentally. We felt that that was a reasonable trade off because those big, huge data centers that are doing all of this hard computation are like just big dumb boxes.

Dieter (41:50):
Right. They have to go where we tell them, they have to do the job that the consensus nodes have laid out or else they don't get paid. They have to produce the correct result. Otherwise they're going to get slashed by those verifiers. And so, yeah, it's a little bit like having a machine that does the work for you. And yes, there's a small number of them, but sort of the worst thing that the execution nodes can do is help the network by just refusing to work. But then they're, they're pretty, fairly replaceable. So that's exactly the mindset. Yeah.

Anna (42:21):
So you did say earlier that you're not purely an NFT project and I did hear you on that, but you also said that a lot of the kind of deals and work that you're doing are using NFT like constructions. So I, I kind of want to bring it back to what you're actually doing as a business. So yeah. I heard announcements about a number of big partnerships with kind of known brands or most of those NFTS.

Dieter (42:48):
Yeah. So they're, they almost all have NFTs as part of them. Right. So we, right now we're in a early access with NBA Top Shots. So that's a NBA licensed collectible where the collectible itself includes a video highlight of an actual play in an actual game by, you know, actual NBA stars. And so, you know, in the same way that you, you know, you might buy baseball card that has a picture of a baseball player on it, you get these, these NFTs and they have, they have a video in them and, and you know, all the stats about the game and whatnot. And so that's so far is been received incredibly well. We have a relatively smallearly access group that's coming in there. But in terms of people, we have probably about one third crypto people that, you know, from CryptoKitties and whatnot.

Dieter (43:36):
And it came over about two thirds of people who are coming in either never done crypto before, or, you know, never been engaged in NFT ecosystem on crypto. And what we're seeing is is that, you know, the crypto people spend about as much money collectively as, as the non crypto people, but everyone's loving it. Everyone's really enjoying the collectible experience. We are currently investigating, putting together a mobile game where you can use those collectibles as game pieces in a mobile game. So you sign in with your dapper account, all of those assets that you own on the blockchain are there, and you can use those in your game to, you know, enhance your gameplay and to sort of show off your credit. Right. So when we look at what other, the other projects, right? So Dr. Seuss is probably going to be sort of a more, a sticker book style project where it's, it's more of a, like a playground creative outlet where you can create, and you can put your various Dr. Seuss stickers into a scene and maybe we'll have like community voting on, you know, people who have created the most creative panoramas and whatnot. Uand so that's sort of the focus there, the UFC product,uproject that we're working on, we've looked at actually building like, like an actual live, like wrestling game, like an actual fighting game where you go in, and again, you're using NFTs, but potentially other, you know, fungible assets that are on chain as well in order to sort of train and set up your fighter or your group of fighters. This is pretty early,usome pretty early ideas there.

Anna (45:06):
I wonder though, like when we go back to that CryptoKitties example where it evolves, so these NFTs evolve so far, what you've described sounds like they're NFTs as like they're an, a single entity that can be traded or something, but do these also evolve? Do they like, is there mutations in this?

Dieter (45:26):
Right now, the base and NBA moments do not. But one of the interesting things that we've, that we're planning on building into Flow is not done yet is the ability to sort of add attachments to NFTs. So one of the ideas is for this mobile game is, is that the NFT, you could sort of attach like a stats card to it that is specific to that game. And so that the NFT can involve inside the game without the base NFT, which is that collectible being changed.

Anna (45:59):
So it´s stays the same. Is this a bit, we talked about this on that episode, the ERC721 episode, where we actually talked about like adding in games specifically where you'd have a character and you're like, you get a sword or you get a hat or something, and it attaches to the NFT, but here you're saying it only would happen within the game, the base NFT isn't affected.

Dieter (46:18):
So it would be like an attachment. It would be an onchain attachment. So the, the NFT would have an, an additional attachment, the line we're trying to draw here. There's two really important things that we're trying to do here. And maybe I explain the philosophy behind it. It'll be more obvious what I'm saying, how it works. One, we do not want to put ourselves dapper labs in a position where we can add functionality to these NFTs that other people could not add. Right. So we don't want to say, Oh, we're building a mobile game. And so we're going to add these stats to the base NFT, and we can update those stats. Right. And if someone else wants to build a game, then, Oh, well, right. So we wanted to make sure that any mechanism we had for enhancing these experience by adding a game well, something other people could do as well.

Dieter (47:02):
That was really important to us. The other thing is, is that some collectors are just collectors, right? If I want to collect that LeBron moment, because I love LeBron James, I don't necessarily want somebody stats from having played the game. I might go buy them, you know, buy that thing from them. But then I might just wipe the game stats and say, yeah, I'm not interested in that part of it. Right. I, I'm not interested in the gameplay part of it. I'm interested in the collectible part of it. And so it was important to keep those things separate. But for example, CryptoKitties 2 which we're planning to put on to Flow, 100% we'll have, you know, like the genetics and the breeding and all of that stuff. Yeah, exactly.

Anna (47:35):
You ended up being though. So like, you've just, you've kind of in this episode, we started from like the team that built this DAP, basically that run on Ethereum, to the protocol builders. So like the layer one builders, but are you in the company itself still kind of like, you must have to handhold a little bit with some of these larger partners, I'm imagining, like you still have to act a bit as like the agency to help them understand what is possible. Like are, is that how your company is kind of structured?

Dieter (48:04):
A little bit. It depends. Right. the NBA was incredibly forward thinking. We were talking to NBA and they were ready for a crypto product. They wanted, they wanted a thing. Now they were open to all sorts of different ideas and they loved our pitch and, and they're really happy with the product, but they knew that they wanted something like this Ubisoft, for example, is somebody else we've been working with. They have an internal team that reports directly to the CEO that as the mandate, figure out how to make crypto interesting in our games, right at that, at the Ubisoft scale. And so a lot of, a lot of companies that we're talking to, you know, and it's not every single company, but a lot, we do talk to a lot of companies that are like, Oh, yes, we've been thinking about this, this, we want to do this.

Dieter (48:47):
Right. We've got, you know, sometimes it's very small. Sometimes it's a little bit more expensive, but they're actually thinking about this. And, you know, I'm not going to name the name of the company because we don't have any sort of deal signed with them, but there are a lot of entertainment companies right now who need a new income stream, theaters are not operating. And, you know, certain, you know, any sort of live entertainment or destination entertainment is like, it's a, it's a dead business right now. And so companies that had previously, you know, we had talked to, and they'd been a little bit skeptical about this like digital ownership thing, or now like going, Hm, digital ownership sounds pretty good. This is an income stream we can have when everyone's in lockdown. And so it is obviously it's a, it's a really unfortunate circumstance, but it does.

Dieter (49:35):
It is one of those things it's sort of pulling these companies forward into sort of the reality that so many of us are living our lives digitally. And so many of us have been pushed into a more digital life, but I don't think that's going away. Right. Like when the lockdowns go away, we're still gonna have a lot of these digital experiences that are going to become familiar and, and a common place for us.

Fredrik (49:57):
And just to play off and ask a question something I'm curious about is, is how you balance those priorities. And like Anna said, like you went from building a DApp, building a L1 to now, a bunch of other, how do you internally organize to, like, do you have your core dev layer one team also build DApps? Are they different divisions? Is there BizDev like in a normal company? Or like, how do you actually split those concerns? Or do you even do that?

Dieter (50:26):
Oh, no. Of course, yeah. It, you know, we have about a hundred employees. We have a dedicated is dev team. As you implied. We have developers here. We have game designers who, you know, have worked in the gaming industry for years who have come and joined us. Our core protocol team is, you know, a bunch of PhDs and masters theses you know, and some just like some really seasoned, excellent engineers. And so, yeah, I mean, we have the float team and it's, you know, got X number of people and we've got the CryptoKitties 2 team and it's got X number of people in NBA and Dapper Wallet, which we haven't talked about much, but is actually really critical to the experience of people coming in.

Dieter (51:05):
And like, you can come and buy an NBA top shot on our blockchain with nothing but an email address and a credit card. And you get to feel that true ownership. You get to go and participate in the peer to peer marketplace, but you don't ever have to feel like you're being forced to learn about crypto. And so each of those, those groups is working separately. And how do you balance it? It's entirely around creating value for our end users. Right. So how many of these features did we have to build in the blockchain before we, you know, publicly versus things that we can incremently add over time? Well, what do we need for NBA to work well, what do we need for have enough partners working on it so that we feel confident that this thing is going to be secure and decentralized.

Dieter (51:48):
And so it's not fully dependent on us. How many features do we have to build into dapper wallet? Well, how is that onboarding experience for an end user? Right? And so it, it really is just like, how do we create this experience? And then, you know, so up until this point, right up until about July-ish, the entire focus of the company was how do we get this flagship experience working correctly? We NBA top shot. We have dapper wallet with its amazing onboarding experience you know, backed by circle so that people can come in and out with USDC and, and credit card, get the core blockchain running, get enough partners on board who are going to be running these nodes who are going to be, you know, who are gonna do so professionally and be responsive to us because this is still early software and there's going to be iteration in the early days.

Dieter (52:39):
And then, you know, somewhere around in July, we had to like, you know, we like actively made the flip over. We're like, okay, NBA is really good. That team can optimize it right now. You know, we've got a team that knows how to take that thing to market now. So they're going to keep going through their early access and then, you know, on unlock the signup gateand just let anyone come in and play there. They've got that right. Dapper is now far enough along that it can build this. So now the question is how do we support the third parties? How do we make sure that these other companies can come in? How can we make sure that individual longtail developers, you know, like whether it's, you know, the guy in his garage or another team, like, you know, the team that, which was quite a small team within axioms and that built Crypto Kitties, right?

Dieter (53:21):
How do those people come and build something? Cause they're not Ubisoft, they're not you know, Warner Music Group and make sure that they have the tools that they need, make sure that there is a facility for them to integrate with dapper and maybe they don't get credit card payments. Right. Because we can't just, you know, we don't want people to go through KYC. And so we can't let them get into crypto, but how can we like set it up so that they can at least use it as a normal wallet software, that they can buy some sort of you know, stabilized coin or currency that they can use it in these experiences. And then once they've got that build and we've seen that, they're what they're built is cool. Then maybe we can strike an agreement with them to let their, their users use credit cards without having to be like a major rewrite of their, of their stuff.

Dieter (54:05):
And so that's the phase we're in right now is how do we make sure that we think of it as a lighthouse, right? Like we, we've got this, this flagship experience so that people know what's possible so that people know that, you know, I think the biggest fear for us when we were looking at other blockchains to build on was, well, what if we pick the wrong one? And so a big part of the strategy of making sure that we have these amazing experiences and this great onboarding experiences that yeah, there might be lots of successful blockchains, but at least ours is going to have users. Right. And so if you come and build on our blockchain, you're, you're gonna have access to users guaranteed. Right. And so that is just like a huge de-risk for anyone who wants to build on it on a new chain. And it was absolutely critical that we get to that.

Anna (54:47):
It was just interesting. I never, I hadn't thought about this, but the idea of KYC for NFTs, like the fact that you, you maybe aren't allowed to buy the, the baseball card or something, unless you've done it. I know that there's gotta be some sort of separation there, but that was just an interesting idea. Well, thank you so much for coming on the show.

Dieter (55:06):
It's a real pleasure. Thanks so much. Yeah.

Fredrik (55:08):
Thank you very much. And to our listeners. Thanks for listening.

Anna (55:11):
Thanks for listening.