Bitcoin Gets Ionic (did:ion)

April 22, 2022 01:12:39
Bitcoin Gets Ionic (did:ion)
The Rubric
Bitcoin Gets Ionic (did:ion)

Apr 22 2022 | 01:12:39

/

Show Notes

The method did:ion began as an exercise in scalability. Backed by Microsoft, did:ion is a layer 2 “identity” network built on top of bitcoin that promises the security of the world’s oldest and largest cryptocurrency with radically lower cost and higher throughput. We talk with Daniel Buchner of Microsoft, the creator of the Sidetree protocol...
View Full Transcript

Episode Transcript

Speaker 1 00:00:07 Welcome to the rubric. I'm your host, Joe Andrew Speaker 2 00:00:10 I'm Erica Connell. Speaker 3 00:00:11 And I'm Eric sch today on the rubric. We talk with Daniel Buckner of Microsoft, the creator of the side tree protocol upon which did iion is based and Tobias Looker of matter, whose products bring, did ion to their customers. We will be discussing how did ion works and how its engineering decisions may give you the did method you are looking for. Speaker 4 00:00:33 Yeah, it's, it's pretty scalable. And, and what, what you notice is absolutely correct. It's actually insanely scalable Speaker 2 00:00:40 On the rubric. We meet the people, making decentralized identity a reality. We discuss the technologies and motivations behind the movement, including decentralized identifiers, which encompass did, did documents and did methods. So you can make better decisions about which did method is appropriate for your use. Decentralized identifiers enable robust identity based services without dependence on a trusted third party. Instead of being forced to use centralized identity verification services like Facebook, Google, or the department of motor vehicles, DIDs can be created by anyone anywhere and be used for any purpose. Did methods are the magic ingredient that gives DIDs their flexibility before creating any specific? Did you first choose a did method, which determines how you perform the create read, update, and deactivate operations on a did of that method once created each did includes the name of its method in the identifier itself, so that when you use that, did others know how to retrieve the associated did document that contains the cryptographic material for secure interactions, different did methods use different underlying mechanisms with different performance security and privacy tradeoffs? This show, the rubric reviews different did methods using a common set of criteria comparing apple to apples. So you can make better decisions about which did method is appropriate for your needs. Speaker 3 00:02:09 Daniel Buckner leads standards and open source development for Microsoft decentralized identity initiatives. Prior to Microsoft, he worked at Mozilla where he ran the developer ecosystem product group and various w three C standards efforts. He represents Microsoft in the decentralized identity foundation and is working with members of dif and w three C to make decentralized identity a reality. Speaker 2 00:02:32 Also joining us today is Tobias Looker. Tobias is a CTO at matter, a company working in the self sovereign and decentralized identity space. He is a software engineer by trade with a passion for all things technology, but with a particular focus on digital identity, he participated in the standardization effort of the underlying protocol that powers ion side tree matter were also an early adopter of the ion did method in their product capabilities. Welcome to the show. Speaker 4 00:03:04 Thanks for having me. Speaker 5 00:03:06 Yeah, thanks for having me Speaker 1 00:03:07 Glad you could join us. The method did ion began as an exercise in scalability backed by Microsoft did ion is a layer two identity network built on top of Bitcoin that promises the security of the world's oldest and largest cryptocurrency with radically lower costs and higher throughput, Speaker 3 00:03:26 Tobi and Daniel. What is did ion Speaker 4 00:03:28 Ion is an implementation of a blockchain or ledger system agnostic protocol called sire. So side's developed in D you know, over a couple years, it's started out as sort of an idea at I, I w one of the years that we were there and what it, what it really does is it allows you to add an overlay network on top of any, you know, trust substrate, uh, whether it's a blockchain ledger in this case for ion Bitcoin and produce a layer two network that's scalable beyond you know, of the anchoring system. So that's, that's in a nutshell what it does. It, it preserves all the properties of decentralization of whatever you're anchoring to. So really ion or any instantiation of side tree is as decentralized as the thing you underpin it with. Uh, if, if that makes sense. Speaker 1 00:04:20 And in this case, that thing is Bitcoin Speaker 4 00:04:23 Bitcoin that's correct. Yes. Speaker 3 00:04:25 I suppose implying that, uh, you could have a side tree for say Ethereum or Cardon or Speaker 4 00:04:30 That's correct. And in fact, uh, you know, element, uh, that transmute was working on is, is, is essentially the exact same protocol applied to Ethereum. Speaker 3 00:04:38 Okay. To bias anything to add on what is did on. Speaker 5 00:04:41 Yeah, to me, I think side tree is the, is the generalized protocol. And the two key kind of, uh, combinatorial innovations in, in this project was the usage of content, addressable storage, which I think is a really big topic in its own right projects like IPFS, which provide a decentralized data storage solution that creates, you know, deduplications through the way in which it, um, content addresses versus vocational addressing of content. And then when that is pegged with a, a global consensus network like Bitcoin or Ethereum, that, uh, realizes what I believe is a truly unique kind of decentralized system for strongly track, really any arbitrary state, but side tree, uh, in, in this particular instance is, is focused around, uh, the documents, uh, and essentially creating robust identifiers that are essentially mutable pointers, that you can change the cryptographic information and, and things like, uh, service endpoints over time to give, uh, end users or consumers are a really quite unique capability, um, that we don't otherwise have on the internet space. Speaker 2 00:05:50 What problem does it solve? Speaker 4 00:05:53 Yeah, I mean, primarily ion was designed to solve scalability of these dead methods. You know, we sort of looked around at a lot of the other attempts at did methods, and it seemed to us at least at the time, and I think it still holds true in the vast majority of cases that people were sort of generally trading properties of decentralization away to get scale or to, to get on these other properties. You, and, you know, a lot of times that would happen by, you know, creating a permission system where it's like, you know, smaller group have to come to consensus. So, you know, that's how we'll scale or, you know, all of these other constraints that they would place, um, on the value they wanted to get out of it and why we wanted to create ion, uh, personally, you know, in working at Microsoft was, and you, maybe this is ironic. Speaker 4 00:06:38 We, we have a great centralized identity business. And if we couldn't have like a really robust decentralized system, there wasn't enough differentiation between the two, like, you know, our people that I would talk to higher up and the company would say, well, if it, if it's anything close to, like, what is centralized or federated today, what is really the value, right? Like, like it's not really bringing all lot to the table. So we wanted to touch on all the points of scale decentralization and security and have them kind of all in one as best we could balance the sort of cap theorum and other sort of triangles involved. Um, and that's really what led to the desire to create it. If, if something like ion or side tree as the underpinning protocol had already existed. And believe me, we did look for quite a while. Um, we would've just used it. Like, I, I would've had no problem going out and just using it. Um, but it was really the desire to have all of those three things in one package that led to it. So scale being one of the harder, harder ones. Speaker 1 00:07:33 So you've mentioned, um, both Bitcoin and IP Fs and that somehow you're what you call a layer two network. So how does it work? How do these two layers inter interate and how does this anchoring actually create value for anyone? Speaker 5 00:07:50 So, so if we take a, take a step back and, and, uh, those familiar with the economics of, uh, of networks like Bitcoin will be familiar that they, they track state usually, uh, transactions or, um, value transfer transactions. And, and the way that network is architected for a variety of reasons is the, uh, the envelope under which those transactions attract is tightly constrained. Um, you know, the economics and the way that plays out means that, um, using that new work is the primary storage of state and mutations of state over time as an arbitrary sort of system isn't scalable. So you, you move to a model where you have to shift that state off chain per se, is, is, is what's often talked about in the industry and, and, and so side tree really represents using Bitcoin or consensus sort of networks to track the anchorings of those state mutations. And I P Fs as the sort of persistence layer or the distribution layer of those state changes. Speaker 4 00:08:51 Yeah. And to, to add a little bit to that, I, I think, you know, what the separation between what, what Bitcoin does and the rest of ion, I think is there's an important distinction. And, and one of the principle things that, you know, we isolated early on is the thing that any true dis truly decentralized D I D method needs to, to account for. And I've called this over time, the chronological world problem, um, really that's what stood in the way of most D PKI systems in the past, the ability to know that like Alice created her idea at time one, and then over several transitions, whereby all other state may, may have changed. You can know how to get to the current state, and it's this problem of how do you that lineage in a way that Alice is in total control, it's decentralized, um, there's no authority saying this is the right, you know, path to her current state. Speaker 4 00:09:44 And so that's actually what blockchains, you know, Bitcoin did for the very first time is gave you a deterministic, decentralized mechanism of encoding events over time. We have never, ever had that. We've actually never had a sequencing Oracle that said, you know, provably mathematically, this is the sequence of that happened in terms of events one after another. So when you have that, that's really the only consensus that you technically need to align things. So the question then becomes, do you want to try and anchor all your things in that core base level system, which you could attempt to do, uh, or should you leverage that system in a, in a lighter way that only leverages that capability and then offload, you know, some of the application specific stuff, which in this case is DDS to a second layer. And so that's really what side tree and ion is. Speaker 4 00:10:36 They, they anchor these aggregated batches of D I D operations, which could be like Alice, creating your ID, you're updating your keys or whatever, um, into the Bitcoin using IPFS C IDs that are embedded in Bitcoin. And the nodes are essentially reading all of these pointers to data and they grab and compile it. And they all come up with the same exact, the, the same exact truth, the same state of the world for all the current state of de IDs and all that they require of Bitcoin. We actually, you know, use it at even a more primitive level than double spend for money is putting things in a line, right. A line that you can replay deterministically. And that is really the, the, the key. And, and so that's why I N doesn't have any secondary consensus. There's no like voting bodies. There's no, you know, subjectivity it's, it's literally just saying, if you give me the data and you tell me the order, I should process it in, compile it in. I'm always coming up with the right answer. Um, and we can do it at scale because we can actually aggregate, you know, and number of operations into one Bitcoin transaction. Speaker 3 00:11:42 Yeah. So there was something, I, I think Daniel, you spoke to a little bit, but this anchoring, can it be thought of kind of in an analogy to normal software engineering, we're programming as a essentially side tree is posting a pointer to Bitcoin, which points to the updates, um, in the IPFS. Is, is that an analogy word? Speaker 4 00:12:03 I would kind of flip it the other way. I'd say, I'd say that Bitcoin is your, sort of the root of your tree, and it is pointing outward toward these, toward these bundles of D I D operations. The, that are the ion specific bundles. So like you look at Bitcoin as your primary source. Like there is actually, no, I guess now that I kind of think about it in sort of an esoteric way, there is no ion, there is really only Bitcoin pointing out to data and ion is the manifestation of processing that data with a, with a deterministic protocol. So it all begins with Bitcoin. And, and from there, you just apply your rules to how you process the data you find from, from there. Yeah. Speaker 1 00:12:40 Can you walk us through the flow of creating and then updating, um, a D I D and the did associated to document and how that start? Like, where does it start and how does it get into IPFS? And then how does that show up eventually on Bitcoin? But Speaker 4 00:12:55 Think, think about it this way. And ion node is anyone who wants to run ion ion is comprised of three fundamental things, right? It's comprised of Bitcoin, you have to run a Bitcoin node. Um, you've gotta run an IPFS node. And then you have this like logic module, which is the protocol rules that, you know, work on those two things. Any node could be an anchoring node, any node could anchor, uh, into ion because all that is required to anchor into ion is writing to Bitcoin, right? So if you can write to Bitcoin, you can anchor an ion, there's no gatekeepers. So the interesting thing is like, let's imagine Alice, she's running her own node, right? And she wants to anchor an ion transaction just for her create of her ID. So she's gonna of create ID. She's gonna create a few keys to start, right? Speaker 4 00:13:37 She's gonna create this recovery key, which is kind of intended. And we separated this in the protocol to be like your cold storage key. So she should keep that, you know, really, really secure. And then she's got this update key, um, which is to do, you know, ordinary updates. You can have it in a, in a slightly less secure environment if you wanted to. And maybe it's like on a device and it's not in cold storage, um, that sort of thing, and that can rotate keys and do things in your DD document. And then any other keys that you want actually outward reflected in your did doc, right? You would create them at that time and kind of put them in, uh, this initial payload, as well as any service endpoints that bundle of things. I just mentioned sort of like what we call the initial state of the ID and, uh, is immediately reflected in your D in your actual ID, cuz the hash of that initial state is your permanent identifier, right? Speaker 4 00:14:28 So when you, when you create an ID and ion, you know, your ID before you ever actually even interacted with any of the distributed systems that ion touching, because like you can pop IDs out and you know, you know them just based on the cryptography and the stuff you put inside now, Alice might want to gain some functionality. Like maybe she wants to anchor her ID cuz she wants it indexable. Or she wants people to find her service endpoint to look her up from anywhere in the world. So if she wanted to go anchor her ID, even though she could use it UN anchored, what she would do is create a Bitcoin transaction with just that operation, that create operation in it. And if Alice didn't have any other operations, it would just be one lonely Bitcoin transaction with one operation from Alice. Right. And that's, that's plenty fun. Speaker 4 00:15:12 She can do that as long as she can pay the fees in Bitcoin. Now, now here's the wrinkle, right? Maybe she doesn't wanna pay the fees in Bitcoin, right? Maybe, maybe she doesn't want to do that at all. Maybe she's not running. Uh, she doesn't have any Bitcoin. Right. What, what ion allows you to do is take that operation, which can't be mutated it in any way, can't be messed with cuz they're signed with, with the keys that you know, are part of the actual D I D and she could send that to someone else running an eye on node that can aggregate 10, 10,000 operations together in one big batch, like Bob, Alice Carroll, all sending their D I D ops to say someone like Microsoft or some other community member, whoever wants to this. And they could anchor in one Bitcoin transaction, 10,000 different D I D operations, for example. Speaker 4 00:15:58 And it's secure because of course that person can't mutate any of those operations, right? They they're integrity, protected. The only, you know, issue that could happen is they just drop one on the ground. They're like, oh, I'm not gonna put your D I D operation in, but that's verifiable. Right? You can actually just check Bitcoin and you know, did they do it or did they not do it? So it, it allows for this secure aggregation and that's what allows the protocol to scale. So that an end user could have a very light, you know, sort of library that creates a D ID and sends it off to one of any number of nodes. And they don't have to incur that cost. The cost is distribute, did widely over an entire batch. So even if Bitcoin was a hundred dollars per transaction, you know, for transaction fees that still equates to just 1 cent per operation, which we think is, you know, pretty economically viable. Speaker 3 00:16:46 Yeah. So we've got into the details of what site tree is this layer two or this idea of layer two and how it relates to Bitcoin, but what design decisions are specific to did ion that push past side tree. So what's in ion that isn't in side tree. Speaker 4 00:17:01 Well, okay. Yeah, there, there are, there are a couple, um, not many. So it is, it is pretty much side tree applied to Bitcoin. You know, there's some requisite adapters, you know, obviously Bitcoin might be different than other blockchains and stuff like that. So, you know, it, writing transactions is gonna look, you know, programmatically different than say Ethereum or something else. So there's all those sort of mundane differences, but there is one really, uh, specific difference, which is, and it's only noted in the spec cuz it's non-normative, which is in the spec for side, it talks about some networks will wanting to put up some barriers to spam and protections around, you know, the economics of the network. And so ion does implement this thing called a, a value locking mechanism, which is based on a, a, a fee, a base fee rate. So essentially ion has this deterministic code in it that looks at Bitcoin and determines just purely based on Bitcoin, purely deterministically, this fee fee that should be computed for each window. Speaker 4 00:18:01 So it's kind of a window function that says for any given snapshot of these blocks, this is this base fee, very, that you should derive based on, you know, different things inside the network volumes and you know, coin scent and all this stuff. And it derives this fee and it imputes this fee that must be paid relative to the number of transactions that you're anchoring. So, and, and the reason here is like, if fees go really low in Bitcoin, we don't want to have people able to do big batches of transactions, which equate to lots of data for like this optimistically low fee that is like, well below what you would expect, right? Like if it's almost $0, an attacker is gonna then seize on those instances to kind of try to bloat the system. So what we wanna do is level that out. So that's what the base fee variable does in of that. Speaker 4 00:18:50 There's also this value locking mechanism, which uses the base fee to say, if you want to go into these very large batches, which generally speaking is gonna be people who are running services, who are larger institutions who are anchoring, you know, thousands and thousands of D I D ops at once. You can imagine that's not gonna be Alice at home, uh, doing that probably there is the requirement that you lock an exponential amount of Bitcoin in re in reference to how large a batches you want to anchor. And what that does is it forces people to have skin in the game. It forces people that want to put a lot of data into the network that has to be circulated by all the nodes and replicated and process to say, I am taking on an encumbrance. I I'm essentially gonna freeze value freeze. An amount of Bitcoin for 30 days is about the number of blocks. And that pointing to that transaction is what allows me to then anchor once per block, a transaction that's very large, that has a lot of IDs in it. And that's just to, to sort of mitigate the ability for a spamer to come in and say, I'm gonna spend one penny of U S D equivalent on the fee, and I'm gonna anchor 10,000 operations. So that's, that is a unique thing that ion contains that that side tree does not specify normatively. Speaker 5 00:20:03 I think just to, just to add the clarification there. So it is, it is for that upper bounds of the transaction limits, but the other thing, so people understand the difference between side tree and ion is side tree. Doesn't define Bitcoin, nor does it define the usage of Ethereum ion does. So ion is an in instantiation and IPFS, right? So content addressable storage solutions and consensus bound sort of networks as, you know, systems and order to order state mute over time and batch those changes side just says, there's these two dependencies. You need to pick a kind of a content addressable system in order to persist your state, preferably because that's how the nodes can readily distribute it. And your system needs to pick some event ordering system or consensus bound network in order to anchor these state changes too ion says we'll use IPFS and Bitcoin, uh, and, and other methods under the side, true protocol, such as element, choose to use IPFS and Ethereum. So I think separate out those layers is, is, is important to understanding exactly what sire defined as an arbitrary protocol versus ion as an in instantiation of that protocol. Speaker 1 00:21:16 I love that distinction because the, the way we've talked about it, and usually we hear about it is that ion is sire applied to Bitcoin, but IPFS is just as much an architectural decision. So it's really applied to Bitcoin and IPFS. And that, I think would've had more light bulbs for me going on earlier in my learning about how these things work together. Speaker 4 00:21:40 Yeah, that's correct. They're both, uh, it talks about it in the side spec as CAS content, adjustable storage. We talk about it in the generic. So we just, you just need to have an integrity proven, uh, peer distributed storage of some kind. And, you know, technically, I guess you could do a sire and instantiation on something with that, or, you know, I don't know something of that nature. Um, you know, any of those other protocols that have that attribute and that functionality. Speaker 2 00:22:04 So Daniel and Tobias, how did you get working on data to ion? Speaker 4 00:22:09 Yeah. Yeah. So I feel like this was an, I w it was either the 2016 fall, or it was like the 2017 spring one. I, I, I can't actually remember exactly, uh, one of those two, um, I, I, we were at steins for one of the, uh, you know, how we, we do eventually. We always have, those is, uh, happy hours that we have at steins that one day. And we were there and I remember it was John Jordan sitting to my right and, uh, Christian lest sitting to my left and, uh, and I've been drinking a bit. And, and, uh, <laugh>, we were talking about how we were actually gonna both these systems at production scale and stuff like that. And I kind of lamented, like, you know, some of the difficulties, because we'd been looking around for something and as we would go through different solutions, it was like always either like it's centralized, you know, at the, at the end of the rainbow, it's centralized, you know, and that's how they're achieving X, Y, or Z, or, you know, it's decentralized, but it just doesn't scale. Speaker 4 00:23:06 And, you know, you know, we're Microsoft, right. If we applied this to like all of our use, what would it look like if we threw 2 billion DS in this thing? Like, would it just fall over? And so that, that was kind of the mosso was in, it was just like, oh, I was just sad about it. You know, love the tech, love the concepts. Couldn't find couldn't find it. Um, we, I remember turning to, to like John and, you know, saying, well, what if we could just, you know, what if there's things that were integrity pro off chain, and really all you were concerned with was the order, because man, like, it's just really the order. That's all that really matters, man. It's the order, the sequence. And like, it was this sort of like, you know, massive B rip opportunity to kind of like think that it, like there was this, this one primitive that really was the solution, which was, if you can just get these pointers to the data that can't be, that's integrity, provable, and you can get 'em in a, in a deterministic order, like Bitcoin does, that's really all you need and that we can scale that we can do. Speaker 4 00:24:01 So I remember like going back that night to the whole hotel and I was like, sort of still kind of zonked, but like I was, I wrote up like a one page, uh, read me. And then I tried, I like walked to the, you know, I w next morning I showed Christian. I was like, Christian, like, tell me I'm nuts. Right. You know, like, just tell me, tell me this, this isn't work for some reason, you know, clearly. And I gave it to him and he came back like later in the day. And he was like, well, I don't, I don't see any reason it wouldn't. So you just keep working on it. And that's kinda how it started. So, Speaker 1 00:24:30 You know, the first time I heard of it was at the spring rebuilding web of trust in Santa Barbara, and that was March of 2018. So just to give you an anchor, maybe it was that fall. I, I w in 2017, how about you Tobias? Speaker 5 00:24:44 Yeah, I forget a, exactly. Um, the time that I was also traveling over to the United States for the I O w conference and, uh, had been chatting to this, uh, this guy, Daniel Buckner from Microsoft who had some pretty kind of crazy ideas. And I remember us sitting down in a cafe and, and Palo Alto and, and having quite a large com around decentralized systems in general, and some of the kind of core premises that decentralized identity foundation was formed by then. And we were both sort of participating in and around the w three C uh, did sort of effort in the credentials community group at large. And we were talking about some of the properties of these networks and, and, and yeah, I think one of the big themes that was coming out of, uh, conversations with Daniel was due to that enterprise background with Microsoft. Speaker 5 00:25:30 It was like internet scale systems. Scalability was one of the biggest sorts of systems and, and how you achieve that scale without compromising on the decentralized sort of aspects or goals that the network kind of had. And that was the first sort of time that I, I'm not sure we were even calling it sidetrack at that point, but that was the first sort of time we were talking about, uh, the concepts and the, and the ideas that, uh, that Daniel had for this. And I think shortly after that, the, the working group at deaf was formed and, and, um, the effort was sort of formally underway and, and, you know, the rest is history really. Speaker 1 00:26:08 So you've mentioned, uh, John Jordan and Chris Quis, as well as the, the two of you who else has been formative in the work that really helped you get things going. Speaker 4 00:26:18 Yeah, I'd say, I'd say Ari or steel from transmute was, you know, came in, uh, sort of, as we started trying to formalize the effort to really, to really specify it, you know, it was, it is more or less a white paper for a while. Like the concepts were there and I think the concepts were solid, but, you know, what, how do you actually make it real in SPECT X to be so specific that you could implement this thing and stand behind it, and really think that it's secure and stable and, uh, Ori what, you know, came in and reviewed it. I mean, he has a super critical eye and he's, you know, he's very diligent. Um, you know, I really love his contributions to the community in general. Um, so he came in there and he really added some rigor to it. Um, challenged us to make hard decisions about how we'd represent keys and this and that. Speaker 4 00:26:59 And just, just, just really, um, you know, I think in a lot of way, iron sharpens iron and, and made, made it end up a whole lot better than it would've if he wasn't there personally. And also, um, the other one I would mention is, is, is Troy Rhonda from security, um, in their very early soft spoken guy. Um, but when he does speak, I mean, I think he always had really, really great contributions. And so he's, he's been a force, you know, and he's, he's using side tree now for another method that he's also working on. So it's showing growth now, I think we're up to like four different methods that use the same core, uh, code, which is like 80%, you know, of ion is, is side tree. And it's, it's cool to see. Speaker 5 00:27:39 Yeah, just to, just to add one more name in there that I thought was, uh, really, really important, you know, when, when you're writing a, a standard, the thing that separates a standard from, uh, developer documentation in my mind or engineering documentation is, is actually testing that it's implementable. And, and to my mind, the person that was doing that most critically beyond Ori was Henry from the, from the Microsoft team who was invaluable in and coming back and saying, you know, this is a great idea guys, but I can't get it to work. Or, you know, like I've, I've encountered these problems. And that implementation feedback kind of loop was, was, uh, you know, was just crucial in any standardization effort. And, uh, I felt like countless, countless sort of situations that was crucial to, you know, ensuring that we got it right by the time we were finished. Speaker 4 00:28:28 Yeah. I mean, I certainly don't wanna leave Henry out. I, I did wanna comment cuz he's obviously on our team, I didn't know that I was, uh, just not wanting to appoint at all Microsoft people, you know, obviously, um, <laugh> but, but yeah, Henry Henry actually coded, I mean, let's get this on the record, Henry coded, you know, probably 80% of the lines of code in the type script, implementa reference implementation. He made these ideas come, come to fruition. Could I have, have banged out an implementation maybe, but I'm, he's so much more of a professional software engineer than, than me that it probably wouldn't have been as good by a long shot. And so Henry is the guy who like took the lump of clay and sort of like mold did it into an actual sculpture you can touch and feel and, and use. Speaker 1 00:29:09 Great. And what's Henry's last name? Speaker 4 00:29:11 Henry SI Speaker 1 00:29:12 SI. Excellent. So what about, uh, sort of upward in your company? Sometimes it's hard to get support for these crazy out there forward looking R and D kind of projects. How did you guys get anyone to agree to pay you money to work on this stuff? And like, what was that internal conversation like? Speaker 4 00:29:30 Yeah. So this is a trip. So, so there's the origin of side and there's like how this even kind of came to be set up, which was I, I was unceremoniously let go from miss Zillow because I tried to do the right thing. Uh, we had a VP who made a very, very Antio decision, uh, to give away the monetary benefits of developers to a couple large companies. And I, I didn't agree with it. I pushed back very hard. In fact, so hard after the meeting where I pushed back two weeks later, I was asked to leave. So I did, and I was like looking around for what to do. I had this R and D gig for a little bit while I was looking and an opportunity presented itself. And at that point I had worked on decentralized in only for a couple years at Mozilla. Speaker 4 00:30:11 And I knew I just wanted to get it done. Like, let's just go do this. You know? And, uh, and the opportunity was a fellow who used to work with me at Mozilla that worked at Microsoft on the edge team. And he said, Hey, you know, I know you like this decentralized anything, but just come work on edge cuz you need a job. And like, you know, come work on the edge team and, and maybe you could figure that out. So I kind of took a few days to think about it. And I was like, okay, well I started researching Microsoft and I was like, oh a D that's like, you know, identity for like all these companies. And like started kind of putting the chess pieces together. Like who would I go to to try and help make a reality? And when you actually look at it, at least on the business side, like Microsoft's kind of really well positioned, you know? Speaker 4 00:30:47 And I didn't even know that before I started looking at it. So I accepted the interview and I, and I told myself I'm, if I get the job, I'm gonna give it 18 months. But the entire goal is that the end of no more than 18 months have moved into the position to really capitalize the keto and decentralized identity. I don't really want to be there to do the edge thing. So I got the job and two days later they said I had to fly up to Austin to do build, uh, build for the new browser and windows 10 launch. Cause that was right before it. And I didn't know anything about edge. And at that point it was on Trident. And I was like, uh, I know about like gecko and Zillow. So I just presented on all you ES six JavaScript things there, but I was in the green room and there was this guy, he was an older individual, you know, he's he, uh, told, I was like, Hey, you know, you're from Microsoft, right? Speaker 4 00:31:31 He's like, yeah, yeah, I'm presenting to, and he's like, do you know, what do you want to do at Microsoft? And at that point, I didn't know who he was. So I kind of said, oh, I mean, you know, if I'm just gonna be, you know, candid, I, I, you know, I have this, this, this Niel plan to sort of invade some area of Microsoft and uh, launch this decentralized identity work and you know, eventually it's gonna take over identity for the planet. And then I was like, cuz I said it in kind of joking way, but those were almost the words. Right. And he's like, oh, do you know who I am? And I was like, no, and I don't really remember you. And he's like, I'm like, are you like friends with my boss? Like, oh no, no, I'm your boss's boss's boss. Speaker 4 00:32:05 You, I interviewed you for like 10 minutes in Redmond, like three weeks ago. <laugh> and I was like, I was like, oh shit. I was like, well, forget about all that crazy stuff. I said, let's just pretend, you know, I'm just working in your org. Like things are cool. And that was Kim Cameron. No, no, that was, uh, Neil Ferguson was his name, Neil fur. And he he's in DX. He was under John shuck, the VP in DX. But what happened was after about six months, I started finding the lay of the land in Microsoft. And um, I found out about Kim Cameron. You know, I kind of knew a little bit about him, but I knew he's in this org. And I knew who was, you know, the VP of identity org. And I had this thing where I set up a meeting, I convinced Kim, I was like, Kim, we have to do it this way. Speaker 4 00:32:45 He kind of got it right away. He sets up a meeting with a VP of identity. And I say, you gotta invest in this. You gotta invest in this because it's good for you guys. You can expand your identity business and all these tools and stuff, but you have to do it. And he said, said, great, sounds great. I mean, think about even if we just like capitalized and got rid of, you know, social off, if we just, you know, made that better for the internet, that actually helps us a lot in our, you know, strategic positioning and all these other things. And so they were looking at it from a monetary perspective, but they were like, eh, just make sense. Just let's let's just try it out and then getting to do things like ion, honestly, we came in with some expertise and they didn't really have a whole lot of pushback cuz at the time it was just like, well, what other system would we use other than Bitcoin? I mean, is anything defensible or any of these other chains secure and defensible and the answer was just empirically. No. Um, so that's why, you know, they allowed us to do that. Speaker 1 00:33:40 Very cool Tobias you're at the other end of the company lifecycle, you you're at a relatively small startup. So how did that come about? Speaker 5 00:33:49 Yeah, yeah, no, I don't have a, um, I don't have a lofty story of climbing a corporate ladder and uh, convincing that the powers that be, uh, like Daniel does. Um, and as you, as you point out matter, we are a, we're a startup. So I think our background story is that we were, we were participating in the decentral identity sort of community and had identified it as, as a growth market and a vertical that we wanted to build products and services in. And I think when we came across ion and started looking at some of the decentralized kind of new networks or efforts in and around the Adjay of identity, the more, the more we investigated really the more it made sense for us on balance. And so really it was, it was about the precedent was set around decentralized identity and decentralized technologies and it was looking for the most kind of the network worth a mixture of things like scale and the decentralized sort of properties that we were looking for in order to achieve the kind of product ambitions. Speaker 2 00:34:47 So we already have BTCR why do we need a different Bitcoin fact method? Speaker 4 00:34:55 So I guess I look at it this way. Um, I think that, I think that ion solves scale in, in a way the, that that is, is straightforward and simple enough that, you know, can, can really like be an exemplar at the time. And I don't know if this has changed. I mean, I'd love to be educated on this, right. Um, we had looked at BTCR and we looked at like, well, what happens when you need to scale that to, you know, 7 billion people who have multiple DIDs and God forbid I O T devices, well, holy crap. You know, there's a lot of those things. I it's a tough, it's tough sling, right? So we, we looked at it really from the need to create a scalable system that we, we thought could run at world scale, um, while retaining all of those great properties that BTCR certainly has, right. It has the properties of decentralization because obviously it's very, you know, it's anchored right there to Bitcoin. Um, but we, we wanted to bring other capabilities as well. Um, to a method Speaker 1 00:35:48 We did some, uh, back of the envelope calculation. Actually I used Excel. I'm a big fan of Microsoft's office products. We did some math cuz I was curious for as, as some of, uh, you guys know, uh, for the did method rubric, there are some questions about transactional through print and not so here's the math that we got. So a typical update size is around 500 bytes I believe in did IM Speaker 4 00:36:12 Um, it's about, it should be about 200. Um, so here's the quick question. When you say update size, are you, there's, there's a couple parts of it, right? There's the anchor file parts and then there's the, the deltas, Speaker 1 00:36:26 Ah, this is what goes on Bitcoin. Speaker 4 00:36:29 Okay. Oh, the Bitcoin one is, oh no, it's only about, let's say one seventy, a hundred seventy bytes. I think 170 200 is, is Speaker 5 00:36:39 Right, right. Cause it's the anchor anchor transaction. You mean? Yeah, the footprinted there. Yeah. Speaker 4 00:36:44 Yeah. Speaker 5 00:36:45 I'd have to go back and give you an exact bite, but yeah, I think that's right. Speaker 1 00:36:49 Okay. Well that's awesome. I don't mind being corrected, but it changes the math by a factor of three. So I'll adjust that at the end because you're gonna get three times a as much for your one 70 than what we're getting for 500. So the Bitcoin block size is limited to one megabyte that gives you transactions per block of that size of about 2000 transactions. Speaker 4 00:37:11 So, uh, so Bitcoin's physical is one megabyte, but there's VBI. So like the, the actual block weight can be higher. Um, I think it's like, gosh, to buy, what is it? Is it one, four or two, four it's uh, the EG, the EG, uh, block weight increase. Does, does effectively make that larger Speaker 1 00:37:28 About 1.4 you thought was effective? Speaker 4 00:37:29 I, I can't, I can't actually recall the exact number, but the block weight, there is a, a noticeable increase in, in, uh, effective block size. Yeah, Speaker 1 00:37:39 That makes sense. So, so we've got a factor of three and 1.4. So we'll, we'll add those back in at the end. So we're correcting my math as we go, but continuing from the 2000 transactions per block, that is, uh, 200 transactions per minute because Bitcoin is designed of a block every 10 minutes, which is three and a half transactions per second. And I think at the high end in did ion, you could get up to 10,000 updates in a given transaction. So with those numbers, that's 35,000 ion transactions or updates per second. And from what we just said, that's off by first a factor of three, which I'm gonna and call that a hundred thousand because that makes my next math really easy. So that's 140,000 ion transactions per second. If all the transactions on Bitcoin were in fact ion updates, which that's a total addressable method, you know, uh, market size, you're, you're almost never gonna fill up the entire block with only, uh, did ion transactions, but still that is a crazy big number. Speaker 4 00:38:47 Yeah. It's, it's pretty scalable. And, and what, what you note is absolutely correct. It's actually insanely scalable. So we had NSR pro file this thing because of the way that it defers resolution computation of the deltas, as we kind of mentioned, um, it's, what's known as an embarrassingly parallel system. So unlike a lot of blockchains that boot up and have to do this computation right on the, like, as it's going it really quickly buckets things and it doesn't actually process signatures and stuff, cuz it doesn't need to, until you resolve like Alice's ID it, it just siphons things into the right bucket. So it's really only bandwidth and storage limited. Those are really like the, the big bottlenecks, right? It's bandwidth and storage, not processing. I mean, that's why you can run this thing on raspberry pie because it's not like doing like insane signature checks and stuff like that. Speaker 4 00:39:30 It's actually so scalable and horizontally scalable that we have to it's it's uh, scalability. So we have the opposite problem at this point. And that's why we limit the network to, uh, low thousands single digit thousands per second, globally as, as the top end. So there's actually much like Bitcoin has a block size, maximum ion has a transactional, a relative through put maximum that, that it, that it caps it us because we actually have to keep the storage growth bounded. So I mean you could, if you wanted to crank it up and you, you were like, Hey, I only care if nodes that are I nine desktop machines with two gigabit connections are the only ones that can catch up to tip. Then you could crank it up. Right. But we actually had to suppress it so that you could continue to run it on commodity hardware because we value people, being able to run nodes on, on things that are feasible for individuals to operate, Speaker 3 00:40:27 Just to give, uh, the listeners an idea of what 140,000 transactions per second would be when compared to Google searches. Um, there are approximately, uh, 63,000 Google searches per second. Speaker 1 00:40:40 Yeah. That's remarkable. Another bit of math is that in the last year, the average BTC fee has been about $3. So $3 average BTC fee, and you're getting 10,000 updates in it. That's 0.00, zero $3 or 0.03 cents per update. Speaker 4 00:41:03 Yeah. 0.03 cents. Yeah. It's, it's very, Speaker 1 00:41:06 That's crazy. Speaker 4 00:41:07 I, I think it's a good number. Speaker 1 00:41:09 <laugh> yeah. It's a really good number. How do, how do, how do either your companies make money off of that? Speaker 4 00:41:15 Uh, we don't, we don't see this as a, as a layer to, to make money. I mean, I, I think it's a, it's a utility for the world. I mean, this is, if it, if it's decentralized, if it's, if it's, if Bitcoin is freedom, money ion is freedom IDs and, and it should always be that way. And that's why we designed it to run on commodity devices, raspberry pies be as efficient, uh, monetarily and resource wise as possible. And so we wanna make like, I can only speak for Microsoft and I'm sure to device is gonna speak for matter in a second. We wanna make money as Microsoft on giving you, you know, credential signing tools and verification tools and you know, thing to interact with data over identity hubs and like all sorts of cool stuff at the application and service layer, um, that is built on top. And some, a lot of that's open source. Some of it could be proprietary, but none of it is ion ion remains a pristine, uh, you know, utility polls style network that no one should own. And, and really we don't want, we don't care if people make money off it. Speaker 5 00:42:14 Yeah. I think, I think that that sums it up really well. Like from our perspective, that kind of layer is really pushing at the, the model of identity networks and how they work today. Right. Which is typically IDPs and service providers are authorities on a group of identities that they manage, right? So there is, there's no way to take the Google out of my Google ID or the apple outta my apple ID. Once I establish a reputation or, or an identity at large with a set of relying parties or services with my apple or Google ID. I can't unwind that there's no portability and, and, and kind of did, I own basically allows this shared infrastructure layer that's incredibly cheap. And the, it allows many service providers to tap into, to build services that are based on a decentralized identity substrate, but allowing, allowing them those service providers to be replaceable and moveable over time, Speaker 2 00:43:08 As you developed, did ion and implemented, I suppose, as well. What has been contr reversal Speaker 4 00:43:15 <laugh> uh, yeah, no, I, I think, um, you know, there's different types of controversies that I think we saw, you know, throughout the, the, the process and the process did take a while. I mean, I, I think this thing was in, it was in concept for a year and a half as we just, you know, we don't wanna be embarrassed, you know, we wanna make sure that, you know, the, even the white paper paper concepts are good. So that took a while. Um, there was people saying, well, why don't you just use X constantly, even that early phase? Why don't you just use my, my widget or my thingy or my system? And, you know, we always did the due diligence. We were like, you know, I tried to be respectful in some way, like, Hey, I'll look into it, but it better be at least as good as the promises were getting out of what we believe we can do with this protocol. Speaker 4 00:43:58 And, um, not a lot stood up to that as you know, as you can imagine, um, then when you moved into implementation, it kind of got to be, there was this initial sort of tribalism like, and you see it out there in these cryptocurrency landscapes, like, oh, use my coin or this coin at coin. And, you know, I faced the ire of, you know, so many people you couldn't even imagine that would just be like, my coin's so much better, it's better, faster, stronger. And I would always have to explain to them, like, I'm, I'm not interested in it because I'm interested in the PR in the premise of security and true decentralization that Bitcoin brings. And it is super hard to replicate. I don't think we are ever going to see in our lifetimes a, a software that was instantiated the way that Satoshi instantiated Bitcoin, it's almost an imaculate conception. Speaker 4 00:44:45 It is so hard to do with that community did. And so we, it, the exemplar and that's why we, we chose it. So that was a little bit of tribalism. Then, as you went through the next phase of the life cycle, um, there was, you know, a lot of PE organizational things, you know, Hey, you know, you're, you're not using the thing that's blessed by this standard org or that standard org, you know, it was like, you know, then you had to define, like, why are you working here versus there? And it was just there's that. And then most recently, um, there's been the, uh, the ESG narratives that you've seen come out that, you know, I personally, and I'm not speaking on behalf, Microsoft are highly dubious, what's ESG. Um, it in, you know, environmental, social and governance, uh, you know, it's just kind of this classification that energy use falls on a lot of the time. And, uh, and that one has been very challenging, but, you know, I think we have the upper hand because the data is with us, right? It's, it's a dubious narrative. I think in the, in the long span of time, it'll prove out, you know, I've done a lot of calculations myself, you know, New York times, others they're off by orders of magnitude in how they see these things. So it's just the latest series of things that, that you gotta overcome and you gotta address with math, science and thoughtful debate. Speaker 3 00:46:00 So, yeah, so that's a great overview of meta conflicts to kind of speak towards maybe a more technical one multi bias. Do you wanna speak a little bit about equivalent properties and give us what they are and the controversy around them? Speaker 5 00:46:12 A step back that that did work at large has been a really good, uh, forum in, in my opinion, at bringing together a whole bunch of communities that otherwise would've done very disparate, um, efforts around decentralization, decentralized networks, right. And what it's done is it's brought all of those kind of communities to, to have a joint up conversation about a range of properties in these decentralized networks, uh, that concentration of expertise really can't be underestimated. And one of the conversations we had was the tension around what was called equivalent IDs. And so in these decentralized systems ion, uh, and to, or its architecture, you don't actually have to anchor well side tree in general. You don't actually have to anchor the dead or interact with the actual network at large, until you wanna do a mutation, right. They're mutable pointers. So the way that side tree and ion is architected is that you don't have to anchor ion or Satre did until strictly, uh, depending on your requirements until you either want it indexable or create a change because they, the first kind of the, there is a determinist of a cryptographic association to the initial state of the document, which means you can start using it, uh, off chain and start interacting and, and worry about resolving it, or, uh, anchoring it to a network. Speaker 5 00:47:38 And later, and there across the kind of dead space, there have been a spectrum of different approaches to what that initial state should be. Should it just be a single key, or should it be a larger document that encapsulates things like service endpoints, uh, and a, and an range of keys. And the equivalence ID conversation was about how to manage the change in that identifier. Once it becomes anchored, because that long form initial state identifier and did ion is effectively an encoded initial of the document. So it's relatively large in certain applications of the network, it would be potentially prohibitively large. And so there's a need to migrate to a shorter form identifier. And the way that we did that is through the equivalence ID, uh, property Speaker 4 00:48:24 To add a little bit to that, you know, there's the equivalence properties, there's a couple different kinds of equivalents properties that we are, that, that are in the, the D I D specification, one of the equivalent properties. Uh, well actually there's three equivalent properties. Let me back up. There's two that are deterministic, that are set by a method. And deterministic means the method. It's not like something the user can set. The method is saying these IDs in, within me, within my method of the same logical ID, they're the same person. You should recognize these as the same ID, right? Soap, aliases, securely, vetted, and evaluated by the method to be exactly equivalent. And then there's this other one that's that's there that we, you know, ion doesn't use, but it's called also known as, and that is not secure. And that is user set. And those equivalents are, you know, evaluated completely outside of the method. Speaker 4 00:49:13 And like, you could put something there and, you know, it's up to you to figure out if they're actually truly linked, right? But ion uses canonical ID and equivalent ID, which are the two properties equivalent ID is just saying, here are some other representations of the same ID, right. That are securely known by the method to be the same. And canonical I D is populated to say, you've resolved a form of the ID, but this is the canonical one. And it's very much like re canonical in the web, right. Or, or the canonical, you know, metatag property, the web, where you can say you came in this big, funky, uh, URL that has all these weird parameters from some ad you clicked on or whatever, but here's the canonical one. Like it's this short te nice looking URL. And that's the one you should like remember, right. And so it's not that you can't use all the IDs, they're all equivalent it's that you want this one ID to carry forward, cuz you might want a te or version O of that, that ID Speaker 3 00:50:04 When updates happen in the case of having these equivalent IDs, then I assume each equivalent ID needs to be updated. Speaker 4 00:50:12 No, no. So they, they all map the, the, the, the ID and ion the ID, the stable identifier that isn't, that is used inside the network to ground all operations is the hash of your initial state. So whenever you do an, an operation in ion, right, when you're anchoring, you are doing an operation on that, that 30 TBI hash, right. Um, and it's in reference to that. And, and all the other forms of IDs are there in present in the system and you know, able to be associated, but you're always acting on that one stable, stable form. Speaker 1 00:50:45 My favorite con around really more about side tree than about did ion, but since they are so closely related, and we talked about this Daniel at Santa Barbara's, uh, rebooting the web of trust, where you presented a topic paper that had some of these ideas. And then we got a chance. I think it was over lunch at the internet identity workshop. And I was like, what is going on here? Because it seemed to me that because of something that I believe you said, the term you guys use as late publishing that there's no definitive way to know, at right now at a given point in time, what the definitive did document is, and you are me through what late publishing is and why you don't perceive that as a problem and how it is approached in SISU. So could you just sort of unpack that? So people who may have heard about this can get a better sense of where you're coming from. Speaker 4 00:51:42 Yeah. So, so late publishing is the concept that let's say I'm Alice, right? I'm Alice. I start out my dead with this certain state and I have these keys in my document. And it's like this, it's basically this operational state that I begin with. Now, let's say I get cute as Alice and I want to take those operation keys. And I wanna create two derivative operations branching from my initial state. Only Alice can do this cuz only she is in possession of her keys. Right? So, so this is strained. The owner of the did, that's the really important premise here. It's not like anyone can do this only, only the did owner could do this, but let's agree on a premise before we take any step further. I think the premise of DDS is the owner should be in total and absolute control of whatever the state of their did is. Speaker 4 00:52:25 Right. That's the whole point. Right? So whatever the D the owner of did wishes their state to be, we should allow their state to be, and that's perfectly acceptable, right? Just like if I wanna do an opt to update my state and not a service standpoint, remove key, do whatever I have control over that. So if you think in terms of my state is whatever I want it to be as the owner of the dead. Great. Now, Alice, she creates her dead. Now she wants to get cute with the protocol. So she's gonna create state two, a and two B. So she's gonna basically create two operations, right. That have like, maybe she rolled the key in one, and she rolled a different key in another. Right. But they all point back to the, to the, the state one as their sort of parent, right in this, in this graph. Speaker 4 00:53:08 And she goes, and she anchors both of them. She let's say she talks to two different ion nodes in the opposite sides of the world. And they're both anchoring. They get her two Doppel ganger operations that are different in, right. And they put 'em in different Bitcoin transactions, but then all the nodes see them. Now here's the, here's the caveat. What if, what if, what if, uh, Alice was to hide, uh, operation one, a right. One of the derivatives, she, she gives the, you know, the operation, she does it herself. So she anchors it in Bitcoin, which has an IPFS address, but she doesn't ever publish the data. She doesn't ever make the actual operation data to available to the network. Well, here's what side tree does. And it's this principle always pick earliest path. So if you think about a, a side tree DIDs progression over time, it's a graph, uh, kind of like a tree graph. Speaker 4 00:53:58 And you always pick the earliest path, the earliest branch path, and earliest is determined by none other than Bitcoin in sequencing. Right? So whatever operations I find for your ID that come first are the, are the ones I'm gonna follow. So in this particular case, let's say Alice, you know, has operation two B and all the nodes in the world. See it, they don't see one. They try, they try to get the, uh, C I D for the data for, for one a, but they don't find it. They only find, or I'm sorry, two a, but they only find two B they all process. And they go, Alice goes from one to two B, they think that's her state. Right. I'm computing that. And that's the state. Now, Alice later in the, in, in, in history publishes the data related to state two a and then all the node would see it. Speaker 4 00:54:46 They immediately say, oh, now that's resolvable, right? Like that, that data for that doppelganger state is resolvable. They all immediately switch to the earliest path because it's a protocol rule that they always follow the earliest path. Now that was Alice, late publishing against herself. Right. Only Alice can do this. Only Alice can determine her state. Right. So we don't see it as an attack because Alice is essentially attacking herself. And really she's not attacking herself. She's just saying, uh, I created these two states and now I want to be in this state. It'd be the same as if she said, oh, I'm gonna go from state two to state three. Right. And, and that is the crux of late publishing. Right. A publishing means the controller could always publish another branch that you don't see if they choose to withhold it. Right. But it doesn't affect anyone else. It's not like, because she withheld this, that like Bob's IDs in a different state or something like that. There's no like cross ID mutations or anything like that, that go on. So it's, it's purely, so I don't know if you wanna drill on what I've said here, but Speaker 1 00:55:49 No, that was great. I'm curious devise, what's your perspective on lay publishing? Speaker 5 00:55:53 We've obviously discussed this at length within the working group, and it largely falls along the lines of the same opinion. I mean, those are, those are the sorts of properties. And, and when you're talking about the, the bounds of the effect, being constrained to the assumed controller of the dig document, those mutations are essentially in kind of my generalized opinion reflected as any other update that that controller can perform. Speaker 1 00:56:18 When I first heard that you could get a discount in effect by posting a larger number of transactions, because you have a staked, some amount of Bitcoin, I got into a big argument with Kyle den Hartog who worked with you, Tobi great guy. He had a lot of great opinions and it was very kind in our debate, but what, what made me crazy was if I understand, right, is it, is it the high end number, a hundred thousand dollars roughly? So, Speaker 4 00:56:47 So let's, let's, let's set the table, I suppose. Sure. One, one thing to, to really be clear on is it's, it's actually not giving a discount. It's actually incurring more money. Uh, the, the larger you, you go the, the more, um, that it ends up costing. So it's, uh, it's the camp down, uh, the P it assumes the people who want to do more can afford to bear more of the network cost and, and of the, the encumbrance. Speaker 1 00:57:10 Well, but the transaction cost goes down to 0.03 cents instead of 3 cents. Speaker 4 00:57:17 Oh, you're just talking about, yeah. Like if you like the, the size of your batch, um, makes the amount spent, uh, you know, distributed amongst lots of more operations. But my point is the amount spent that you actually have to spend on transaction fees and, and, and the, uh, commitment to value is, is, goes up with your batch size. So, so in actual dollar terms, you have to commit more to do larger batches, even though the per operation distribution of that more nets out to lower operational, you know what I'm saying? Like, like lower, lower fixed unit costs, like that's yeah. You're you're right. But you have to actually pay more money. Speaker 1 00:57:52 Right? Well, that's, that's sort of what I'm getting to. So below a hundred updates in a single transaction, but above that, then this state VCC starts allowing you to submit more transaction that the rest of the I network will respect. Speaker 4 00:58:04 That's correct. That is correct. Speaker 1 00:58:07 So, to me that felt like a really arbitrary, an arbitrary advantage for the companies who want to put a hundred K away and then get this discount of an order magnitude on the per transaction cost for the updates. So it seemed like a really weird advantage to give to large companies, but I know you guys have thought through it and Kyle actually had some great arguments. So I want just wanted to give you guys a chance, cuz if anyone else sees that, I think some of 'em are gonna have the same. What, what is happening here? You just made it easy for Microsoft to do all this stuff. And me the little startup, well, I can't put a hundred grand away for a month, you know? So I just wanna give you an opportunity to engage on that. Speaker 4 00:58:47 Yeah. So one thing I'll note is it's not just like a big lump sum or anything. So there's a curve. It starts at a hundred operations. Like, like the reason why we did it that way is we wanted to say that freedom box nodes running on a raspberry PI could always do however many operations. We believe that it would rationally take to maintain their own IDs without having to do sort of complexity. So that's why that's where the hundred comes in because we, you know, we figured if Alice is doing her own IDs, you know, how many operations do you really need to fit in a, in one op you know, transaction, right? Like she can update a bunch of IDs, like one big Bitcoin transaction. So, so that's why it's there. And there's no encumbrance on that. Uh, the encumbrance starts at a hundred operations and it scales up on a curve. Speaker 4 00:59:27 So at a, at like a hundred in one operations, you hardly have to stay really anything. It's, it's, uh, it's very, very small. It, it kind of, it, it's a, it's a curve that goes up more dramatically on the tail end. Like you really want to get into the more size amounts. You, you have to start locking Bitcoin so that you can understand that you are not gonna encumber the network without having to put skin in the game. Right. And you get the Bitcoin back, but like you have to freeze it and you have to go through some encumbrance to prove access to, to that large volume. Um, and that's just again, to protect the network. Now I will say there's one caveat here, the value locking, isn't the only thing. So that, that does allow you to kind of like scale up your operational volumes. Speaker 4 01:00:08 If you have the capacity to kind of stake against what would be larger encumbrance of the network, but that same fee variable that's used to compute the curve of value. Locking is also used for a per operation cost. As you go up, there is actually a per operation cost that's assessed. So it's not like, um, it's just the value locking. And then like, it's exactly whatever the fee costs would be. The actual fee that you need to overpay in Bitcoin mining is related to the size of the batch that you're anchoring. So for under a hundred operations, basically what, whatever you can get into Bitcoin with, if you could send a zero fee transaction to Bitcoin, you could do a hundred operations pay, no fee in Bitcoin terms, right? But if you go over that, even if you you've locked a hundred thousand in Bitcoin, the actual transaction cost you have to pay on a per transaction basis then becomes relative to the size of the batch you have to do. And you're essentially paying the mind a, a, a floor, even if the actual fee to get into Bitcoin is much less. And it's imputing that cost because we wanna set a floor. So people can't hit the network, um, arbitrarily, and, and it, um, incentivizes the transactions in Bitcoin to be picked up, uh, before other, you know, um, transactions that may not be willing to, to pay for, for anything. Speaker 5 01:01:25 I think the only other thing that I would also clarify with this mechanism as well is not every node. Operator's gonna have 10,000 ops that they're gonna want to anchor, um, into a single block. Right? So it's, it's like, it's like almost any economies of scale or commodities of scale, right? If I'm a corner state dairy and I buy 10 lead thousand lit of milk to get the kind of fractional cost of that milk, it's only worth something if I can exercise a return on it. Speaker 3 01:01:52 Yeah. So we've talked a lot about the, uh, details of Didion at this point. Now let's maybe shift gears a little bit and talk about who's actually using it, who I guess other than, uh, Microsoft has picked it a up. And I think Tobias, you had a, uh, mentioned before the show that, uh, your company has just picked it up as well. So do, do you know of any other implementations out there? Speaker 5 01:02:13 So we, we, we have picked it up as, as, uh, as we mentioned at the start, and I think, uh, these kind of a couple of different layers to it, obviously within the side tree realm on the basis that ion has built upon, there has been adoption in the form of different dig methods and that generalized application. And then in the explicit context of M uh, of ion, I think Daniel, you might be best place to talk about the, uh, the adoptions. I know we have Microsoft type capabilities for it near a few others. Speaker 4 01:02:41 Yeah. Yeah. There's a, there's a group of companies. Uh, some, some are not have not gone public with their support yet, but are running nodes. They're, they're rather large companies that those, those announcements probably be forthcoming that they've, you know, also like matters, selected ion, uh, as at least, you know, default or, or a primary, uh, mechanism. Um, there's tons of nodes that you can see by, you know, scouring the IPFS connections that clearly there are nodes out there and, and, and, you know, dozens and dozens of nodes out there that we don't know of. And that's exactly how it should be. Right. We, we, we see, uh, operations coming into Bitcoin, you know, every IM node knows all I on operations cuz gains Bitcoin understands like which ones are on operations or iron transactions rather. So there are clearly inbounds into writing that are not us right, that we know are not our node. Speaker 4 01:03:29 Uh, we're helping people out by some capacity and, you know, offering that up for free. But we, we are seeing other operations grounded and then we on the IPFS side and those are writing nodes on the read node side, we're seeing some, uh, IPFS, clearly dozens of IPFS, uh, connections from nodes that are being run, asking for ion specific data that otherwise would not be. So that indicates that those are read nodes that are sort of a pseudonym and unknown to, to anyone, um, but are certainly mirror of the data and being used in some capacity for resolution. Speaker 1 01:04:04 This specification is currently owned at the decentralized identity foundation, also known as diff do you see it moving into standards, track work? Speaker 4 01:04:14 So, so in terms of the side tree, uh, side tree is a diff specification. Um, you know, we do believe diff is, is a, is a good standards body for some things that it can ratify other things it might want to export to w three C or I ETF, or, you know, any other number of organizations, if the spec is appropriate for such a thing, CIRI one point is a diff ratified spec. So we do look at it as a standard. Um, you know, there was, there was pretty wide there. I, I don't know about, you know, would we want to take it and get it similarly ratified by say an I, I ETF group or something of that nature I'm open to it. I, I don't think we have any plans for it at, at the present, but it's something that I certainly, you know, one could make the argument for it in the future. Speaker 1 01:05:01 Did iion is it if, as well as it Speaker 4 01:05:03 That's correct, it's a, it's a diff project. I, I fought very hard to ensure that Microsoft was not, you know, doing this in its own open source reco repos, that it was essentially acting as a contributor to an open, uh, project that was governed by a, a wider body of people that, you know, were interested in it, not just like Microsoft open source, you know, that sort of thing, because in my opinion, uh, Microsoft has, should, should never have had, and has never had the governance ability over it. And, and it should have been operated and should, and is operated as a separate project. Um, under a foundation that is, you know, has lots of contributions from, from many people, including matter, you know, who's here on the, on the call and I'd love, you know, to bias if you wanna chime in with like, Hey, you know, where, where is Zion? How's it been done? Like, you know, with your experience. Speaker 5 01:05:52 Yeah, I think, I think it is, it's put it in, in, in a great, great light in general, as being another organization participating in this work that did iron was, um, not only was the side true work, done that deaf, but did iron was because that kind of role of governance and sort of open participation model means a lot, especially when we are talking about building, uh, decentralized networks to me, I, I, I dunno how, uh, Daniel person feels about this, but I, on to me is largely like a profile of side tree as, as I said, you know, cause there's a couple of key decisions, right? So side tree says, you know, there's these kind of places you need to plug things in, as we've said before, content addressable storage and, and Bitcoin. And then there's probably a few more rules you might want constrain down in terms of the flexibility, that side, true protocol. So did I on beyond the kind of reference implementation and developer documentation, um, at its heart is a profile of side tree, at least in my mind, Speaker 3 01:06:46 That's, uh, I think a good segue to asking if someone out there wants to get involved with did ion, uh, how would they do so, Speaker 4 01:06:53 Yeah, you know, I would say the best ways to do that, um, you know, become a member of D uh, you can, you can become a member of dif if you're an individual it's free. If you are a company less than a thousand employees, it's also free. Uh, you just have to sign like, you know, IPR agreement saying you're not gonna Sue everyone for, you know, contributions you make and all that sort of good stuff. Um, we have the same exact I P as the w three CS, uh, I P use the same ones, so that we'd be compatible. And like people would feel comfortable cuz w three C's IPR is great and, you know, we don't need to reinvent that wheel at all. So, so yeah, I would encourage you to be a member of D join w three C um, all those other great organizations are working on it. Speaker 4 01:07:34 The side tree working group in dif is the one that does side tree work, ion all the other method that are, you know, based on side tree. And that's where we talk about like new upgrades to the core protocol of side tree. Um, how the evolution of a given methods gonna happen, very keenly Ion's governance, uh, you know, is, is in the side tree working group. It's not Microsoft going in deciding what's gonna happen with ion it's it's the members of that group and the people we provide feedback and do contributions and PRS, um, that decide the shape of ion in, in the future Speaker 3 01:08:06 Tobias, anything to add? Speaker 5 01:08:07 No, I think that's a great summary of where to get involved. Speaker 3 01:08:11 Well then to wrap up the show other than did ion, what is each of your favorite did methods? Speaker 5 01:08:15 Look, I think we've had a lot of simple conversations, uh, that were brought about by did key. I think there's elegance and simplicity and wide applicability, and it actually brought out a lot of really good conversations, especially around the initial state and equivalent IDs and the comparing and contrasting models around the approach is there. So it's definitely, uh, a top favorite of mine. Speaker 4 01:08:38 Yeah. I mean, I, I would've to say the same and the reason why I would, I would agree is because it's a very easy entry method. It's your, it's your gateway? Did you know if you need a gateway, did it's, uh, you, you just, you take one, hit a dead key and you kind of just work with a key and a document it's easy to resolve it's yeah. It's not rotatable, but after you get a, a taste of did key, then you want something that's actually more, uh, you know, feature filled and can be rotated and, uh, updated. Speaker 2 01:09:02 All right. We'd like to take a moment now for our shameless plug segment, who's got a shout Speaker 1 01:09:07 Out. So I wanna give a shout out to ane John and the work he's been doing at department of Homeland securities, Silicon, the innovation program in particular last week, they did a demo week where they highlighted all the different projects that they have been investing in to advance innovation in a number of different areas and a significant amount of their investment over the last couple years has gone into technologies behind DS and verifiable credentials. And they have been a big advocate of that, both within the industry and putting money and grants and contracts into development. And within the federal government, finding the customers who could use this technology and acting as a bit of a midwife to help startups like matter work through the hoops that you have to jump through to actually be qualified to, uh, serve the federal government with this new technology. So, uh, big shout out for that. We will have URLs for the demo week website. So, uh, I think all the videos or most of the videos are available online. So if you're curious about that, go check it out Speaker 5 01:10:10 In general. I would just like to shout out and, and more of a call to action for people to come and join us in these for forums. These open standards, forums, uh, decentralized identity foundation is a, is a growing ecosystem. Um, there's a lot of really smart people there, a lot of really exciting projects going on that, uh, we get to participate in. So anyone from all walks of life, uh, please come and join also over at the credentials community group at the w three C uh, it's a really great forum that's been growing over the last few years and has been responsible for the incubation of many of these technology standards and through the help of great individuals like Aneal John, um, driving that work forward. So yeah. Cool to action. Come get involved. Speaker 4 01:10:52 Yeah, I, I I'll I'll turn my shout out new call to action too. I mean, I, I believe in ion, uh, I, I believe, I believe if it's, if, if not the most, maybe one of the most decentralized robustly decentralized methods out there, I think it's got a lot of great, you know, things it can bring to people, run a node, get feedback, you know, we'd love commentary codes, a anything, and then track some of the emerging work that's gonna make DIDs really pop, which in my opinion is like some of the identity hub slash data store work that kind of, you know, paves the way for some application level stuff. So when you have a did, what do you do with this thing? Right? We, we, we, I think we we're solving that problem. Come join us in the fun problems to come, which are like, how do we actually make apps and signing and all these tools with these DIDs and that's kind of the next frontier and, and that's still being shaped. So you have a, an opportunity to come work from the ground up with these organizations and, and individuals that are doing that. Speaker 2 01:11:47 And that will bring us to the end of our show today. Speaker 1 01:11:50 Daniel Tobias, thank you for joining us on the show. Thanks also to our staff, our producer, Erica Connell, and my co-host Eric shoe. I'm your host, Joe Andrew, Speaker 2 01:12:00 Wherever you find the rubric podcast, please take a moment to subscribe to our feed. So you'll be notified when our next episode is released. We look forward to you joining us next time. The information opinions and recommendations presented in this podcast are for general information only. And any reliance on the information provided in this podcast is done at your own risk. The views, thoughts, and opinions expressed by the speakers in this podcast belong solely to the speakers and not necessarily to the speakers, employer, organization, committee, or other group or individual. Speaker 5 01:12:34 There's no way to take the Google outta my Google ID or the apple outta my apple ID.

Other Episodes

Episode

January 24, 2024 00:36:05
Episode Cover

DIDs for Any Crypto (did:pkh, Part 2)

did:pkh is the minimalist multi-blockchain DID method, designed to work with any blockchain with minimal fuss. Today we talk with two of the authors–and...

Listen

Episode 0

June 21, 2021 01:12:53
Episode Cover

The Granddaddy of DIDs (did:btcr)

BTCR is the grand-daddy of DID Methods. Created by Kim Duffy, Christopher Allen, Ryan Grant, and Dan Pape, it uses the bitcoin ledger to...

Listen

Episode 0

April 01, 2022 00:59:05
Episode Cover

A Pace Apart (did:snail)

did:snail is hands-down the most innovative DID method we know of. It connects the world’s most modern identification architecture with the oldest, most widely...

Listen