Episode Transcript
[00:00:06] Speaker A: Welcome to the Rubrik. I'm your host, Joe Andrew.
[00:00:09] Speaker B: I'm Erica Connell.
[00:00:11] Speaker C: And I'm Eric Shue.
[00:00:12] Speaker B: Today on the show we talk with Martin Riedel and Daniel Kelleher, co editors and implementers of the didsol specification.
This is part one of a two part interview. Part two of the conversation can be found at Rubrik.
[00:00:30] Speaker D: It'd be interesting if we dug into this a little bit.
[00:00:36] Speaker A: On the rubric we talk to the folks making decentralized identity happen. We chat about the technologies and motivations behind decentralized identifiers, including DIDs, DID documents and DID methods so that our listeners that's you can make better decisions about which DID method is best for your use.
[00:00:53] Speaker B: Decentralized identifiers enable verifiable interactions without dependence on a trusted third party. So instead of being forced to use centralized verification services like Facebook, Google, or the Department of Motor Vehicles, dids can be created by anyone, anywhere and used for any purpose.
[00:01:14] Speaker C: DID methods are the magic ingredient that give DID their flexibility.
Before creating any specific did, you first choose a DID method which determines how you perform the create, request, 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. This is so when you use the did, others know how to retrieve the associated DID document that contains the cryptographic material for verifiable interactions.
[00:01:40] Speaker B: Different DID methods use different underlying mechanisms with different performance, security and privacy trade offs.
[00:01:49] Speaker A: This show the rubric reviews different DID methods with their creators and implementers so you can make better decisions about when and how to use dids in your applications.
[00:01:58] Speaker C: Martin Riedel was most recently the CTO of identity.com he has been working in the digital identity space for over a decade and is an active contributor to leading organizations like DIFF, W3C and OMA3.
Martin's journey in digital identity began in 2014 at the Wu is Notar Kammer, Germany, where he worked on an EIDAS compliant trust service for lawyers and notaries since 2018. He has dedicated his efforts to the evolving decentralized identity landscape, holding significant roles at Civic Technologies, consensus, mesh, and identity.com Martin, welcome to the show.
[00:02:36] Speaker E: Thanks for having me.
[00:02:37] Speaker B: Daniel Kelleher is the VP of Engineering at Civic Technologies and has been working at the Cross section of Decentralized Identity and blockchain since 2018. He is passionate about building a self sovereign future for all that is both secure, egalitarian and user friendly. Daniel has a background in finance and E government and since 2020 has been a leading voice and builder in the Solana community, co building with Martin one of the first account abstraction frameworks on Solana, the first encrypted instant messenger, as well as products in the carbon market space, among others. Daniel, welcome to the show.
[00:03:16] Speaker D: Hi, how's it going? Thanks for having me.
[00:03:18] Speaker A: Glad you have me both. So let's get started. Didsol is the Solana DID method. Solana is an application centric blockchain praised for its high throughput and its composability.
So in your own words, what is ditsall?
[00:03:34] Speaker E: Well, you said some of it already. So didsol is the DID method on Solana and it uses Solana as the verifiable data registry to stay in the DID spec terms.
Ditzol inherits a lot of the properties of the underlying verifiable data registry for Solana. That's high throughput, low latency, short time to finalization and especially low costs.
And specifically didsol as a layer one DID method is very feature rich and learned from previous DID methods and it has features that are familiar from other DID methods, but also extends like we have like a default generative DID state. We have native on chain support for ED25519 and SECP256K1.
We have flags like ownership proof of verification methods or mark verification methods protected. We have usability features like lockout protection and many more features.
[00:04:39] Speaker B: Excellent. Daniel, anything to add?
[00:04:41] Speaker D: I think Martin, you listed the features very well there. I hope we get a chance to go into a few of those over the next hour or so.
[00:04:50] Speaker B: Let's jump right in.
What are the features of didsol that are unique innovations?
[00:04:56] Speaker D: Okay Martin, jump in if you want to add any more details, but I think that one of our focuses is the on chain functionality.
So we take advantage of the fact that didsol is built upon a smart contract in the blockchain speak, so it has functionality. A lot of DID methods don't really have a kind of a logic layer and so concretely, as Martin mentioned, it allows the verification of signatures on chain. And although the base key algorithm of Solana is ED25519, the smart contract layer that Didsol is built on lets you be a little bit more flexible. You don't have to just use ED2551,25519 keys to sign messages that will change your DID state on didsol.
For example, if you have an Ethereum key or from a bitcoin key, then you can also update your state with that key, and that's quite rare, I think another feature that's a very cryptocurrency specific one. So another feature that is very important, again inherited or inspired by other DID methods is the kind of default generative state.
So by default, if you have a key, then you have a key of this ED25519 algorithm, then you automatically have a didsol. You don't need to make any update to the chain, you don't need to use any relayer or anything like that to create your did.
Just like with DidKey and did ether and things like that, you automatically have a did. And it's only then when you want to change that default state that you need to make any kind of blockchain transaction, for example.
[00:06:55] Speaker E: Yeah, I think these are the two most important usability features. Like everything then on top is more.
It ends on top. Not every user might require the features that we list.
I talk a little bit more in detail.
Like proof of ownership is an element where when you add a verification method, you don't necessarily need to prove ownership of a key initially, but often you want to have the guarantee, especially in an on chain scenario, that that verification method key that was added was actually verified by the chain.
So that is a feature that we specifically support. So when you add a key, mostly you use an existing key to add a new key, but that new key is not necessarily proven. And I think that's the same for other methods.
But Dizzol has a feature that you can query this ownership proof, which we call so you can later go ahead to any unproven verification method and say this was actually proven on chain. And that is a feature that we often more use on chain than off chain.
But it could also, because it's not exposed in a DIT standard yet, and we can discuss about should there be an extension for DID that represents that provable aspect or this ownership aspect.
But that's something that we feel is very important for ditzo.
[00:08:33] Speaker D: Yeah, I think that's. It'd be interesting if we dug into this a little bit because for me, and I think one of the motivations for adding that particular feature was that verification methods are public. If you know the did, anyone can look up the DID document and see those verification methods. And although they're intended to be access control sort of things, so if somebody signs with a verification method, then you.
They can sign a message for that did, so they can update that did or they can authenticate using that DID or whatever. But because they're public they can be interpreted potentially in another way. And that's very relevant to one of the first use cases that we had for didsol at my company Civic, was that they could also be interpreted as indicating the reverse relationship, that an owner of a did also, by definition, owns that key that's in the verification method.
And that's an incorrect interpretation, as I understand it, of the spec. You shouldn't assume that a verification, a key that's in on the did is automatically under the control of the person who owns the did.
But it could be misinterpreted that way. And this ownership flag effectively allows you to disambiguate that. So the use case we often thought about would be what if somebody who owned a did managed to add, say, Elon Musk's public key to their did and then use that to masquerade as Elon Musk? And that sort of use case, we tried to avoid using this extension.
[00:10:03] Speaker C: Yeah, that was great.
Before we get too much deeper into didsol itself, we would like to ask a couple questions about Solana as a chain, just for anyone listening that's not familiar with Solana.
So first, can you give a rundown of how the account term is used in Solana and how someone coming to didsol should think about a didsol program account versus a regular Solana account?
[00:10:31] Speaker D: Yes, that's right. That's a very important part of the programming model in Solana. So under other other blockchains with smart contract capabilities like Ethereum, logic and state are combined together in what's called a smart contract.
And the smart contract encapsulates the state, and then there are operations on the smart contract that govern how that state is changed.
That's a little bit different in Solana in that the logic and the state are separated. The state is in accounts and the logic is in programs, and the accounts are still owned by programs. So it amounts to the same thing.
But the accounts can also be queried, and especially queried separately from the programs. So everything is an account. If you have a balance on Solana, a balance of SOL tokens, you have an account and that account tells everyone else what that balance is. And that account is owned by what's called the system program. So it's again the kind of default account.
If you have an account with the Didsol program, that account doesn't store your balance of SOL tokens. It instead stores your state or your did's state. So then you need to have a way of addressing, of looking up that account, because that's a different account to your, your system program and account that tells you what your SOL balance is. That's a separate account and that's owned by the Didsol program, as I mentioned. So there is a way of performing that lookup of finding out, given a particular person represented by their public key, what their didsol program account is.
And that's called a program derived address.
So basically a deterministic mathematical function that goes from your address, the address of the program that you're referring to, to this, this account.
So that means that you can, given a public key, and given the program ID of the didsol program which is public, find out what their didsol program account is and query that. And that's effectively what the DID resolver for the didsoul DID method is doing.
[00:12:57] Speaker E: And just to add to this, I think that the important aspect in the separation of program and account is the READ operations are generally independent of the program.
So if I just want to query any state on Solana and I know how to look up accounts, which, which is like definition in the Solana program, I can just query it directly. So for didsol, that means any resolver functionality, any lookup doesn't go through the program. It goes through a client that understands the account derivation model and looks it up directly while only writing or modifying operations go through the program. Because that's where the access control lives.
[00:13:52] Speaker D: Exactly. And that's how the generative feature also works. So the DID resolver, a Didsol compliant resolver, will make that derivation. It knows the address to look up, it looks up the Solana blockchain for that address, it will find no account, and then it interprets the absence of account to mean that that DID is the generative did, the default DID state, essentially.
[00:14:20] Speaker A: So this is starting to make sense to me.
The accounts in Solana are all bound to a given program.
The currency we think of as SOL is run by the system account I think you mentioned. But all the other accounts really don't deal with sol. They could access it if they wanted to, but they're maintaining their own application state and that is in account.
I'm curious how this. Because I know you did some work with the account abstraction work over at Solana, and if we were to look at Bitcoin, all of those accounts might be addresses, and then I could have as many addresses as I want. But Solana uses a different term and account abstraction was a bit of work. So could you unpack? How does that work? What is this account abstraction stuff?
[00:15:03] Speaker D: Yes, sure. So I mentioned at the Start that your public key is like one of the inputs into this function that derives, let's say, for example, your didsol program account.
And the implication there was that the public key was what's called an externally owned account. In other words, it's got a private key behind it and it's derived off chain by some function. But equally, that public key itself could be essentially the account ID of a separate account.
So each account itself has a public key. Now, you need to be a bit. You need to bend the definition of a public key. In that case, it's not really a public key because there is no private key. But each Account essentially account IDs and externally owned account public keys look the same and they're interpreted the same by the Solana programming model.
And that means that while you might have a system program account associated against your public key that says you have tensol, equally a separate program account could have its own balance of tensol. And that's what allows you, for example, theoretically. Well, not theoretically. This is what we've built on top of didsol.
A.
A didsol account is itself an owner of a balance.
That balance is by default zero, but you can transfer balance into that account and then the DIDSOL program works with other programs, the account abstraction programs. We call it Cryptid. That's the one that we built on top, this account abstraction program called Cryptid to govern how to spend that balance and what to do with that balance. That's the kind of the basis on which account abstraction works in general on Solana, the one that we built on top of didsol. Like I said, it's called Cryptid is a very early example of that. Martin, did I leave anything out there?
[00:17:04] Speaker E: No, I think the important aspect there is a whole terminology around account abstraction in the Web3 community to push features of my account. Our wallet is not just a key pair into the specification or into the nodes directly, like Ethereum is doing this. And I'm not sure, Dan, if you know that Solana is doing something in that regard, but what Cryptid is, is a program implementation of an account abstraction which gives us complete control, but which is a feature that is not provided by the Solana chain by default. So we provide it through a dedicated program that interprets your DIT SOL state as your account state and enables you to use your DIDSOL as a wallet in very easy terms.
[00:18:09] Speaker A: Great. So could you give us a brief overview of the Solana chain and how its proof of history consensus works?
[00:18:15] Speaker E: I think I can start with a very high level Interpretation and then please, if you have a deeper understanding, please add on to it.
So in a way, Solana uses a proof of stake consensus algorithm in a leader based validator network to produce and validate plots.
But it has a certain trick to be more efficient in this process, especially to resolve conflicts around leader selection and conflicts around timing for leader iteration, which is a lot of the source of inefficiencies in consensus algorithms. And this is where this proof of history algorithm comes in.
And in a way what it does is it calculates hash function repetitively, so it hashes something and the output is hashed again and the output is hashed again, which means it is a function that can only be produced by a single core because you always have to wait for the output of the first hash function in order to generate the next hash in the cycle. And in a way all the validators in the Solana network do these operations.
And by doing these operations they can prove to other people in the network that they've done this iterative hashing approach with the Solana network associates with a certain tick or timing that goes, that passes by.
And in this block producing sequence, this proof of history algorithm comes in to verify that validators, for example, do not jump the chain or later validator doesn't produce a block, that it was not entitled to produce that because it wasn't the leader yet. Because it has to also prove that it has gone through this hash producing mechanism and has to always present in the block production this kind of hash production. And the cool thing is hash production is single threaded, while the hash validation, like if you get 100 iterative hashes is like multi core. They can just split that up and it can be much more efficient than the production. And that's how you can time the block production much more thoroughly, let's say like this, leading to higher throughput and faster transaction times.
Dan, anything you want to add?
[00:21:04] Speaker D: Nothing to add from my side on that, that's a good answer.
[00:21:07] Speaker C: Okay, then Solana does have some differences from other well known chains such as Ethereum.
Could you talk a little bit about how fees and rents are handled maybe specifically in regard to didsol?
[00:21:21] Speaker D: Yeah, sure. So there's effectively two types of fees. The first is a transaction fee, that's a base small number of 5,000 lamp ports, which is the minor version of Sol per signature to be validated. I won't go into too much of the details of the per signature thing, but you can basically think of it as a fee per transaction.
Then there's Also a fee for the storage of data. And that's calculated by.
That's calculated by byte.
And that fee is called rent. It's actually slightly archaic or legacy. The reason why it's called rent because originally this was envisaged as to be kind of an account that each. Sorry, a balance that each account needed to maintain and that it would be periodically skimmed off the top every few days until it reached zero. At which point, if it reached zero and it hadn't been topped up, that would be considered old data and be just dropped by the validators.
That actually doesn't happen anymore. In later versions of Solana, you have to basically store enough SOL or LAMP ports against an account in order to make it rent exempt.
It's basically two years worth of rent, at which point it is exempt from having that skimming function and it will stay there forever.
So it's still called rent for slightly kind of archaic reasons.
What it means to DID SOL when you A did is free, right? A did itself, the generative did, the basic did is free because there's no data stored on chain at that point. As I mentioned before, the absence of data on the chain indicates that this is in its default state. But as soon as you update the state in any way, then that creates that account. And that account will automatically then be provisioned with two years worth of SOL in order to be rent exempt. Now, the amount is still very small. I can't remember the number exactly in front of me. It varies depending on the price of sol, but it's the order of, I think less than a cent. But it is then locked against that account forever. And that basically compensates the validators for storing that information.
[00:23:37] Speaker E: And to add to this, from a didsol perspective, that also means that your didsol size is dynamic.
So if you add one key, it has a certain number of 32 bytes, maybe 34 bytes that get added to it. If you add another key, there's another 34 bytes added to it. And that of course influences your rent exempt amount that you need to provide.
So DID Cell has some usability that makes it really easy. You could just say, I put a big amount of SOL rent in and I never worry about the sizing. I have enough. But what we provided as a client, we make it really easy to always provide the right amount of rent for your transaction. So in a way, you could always dynamically grow your account and only have the minimum amount of SOL or the exact matching amount of rent accept SOL that you need to provide, no matter if you Add or remove or change the size of your account.
[00:24:41] Speaker A: So did I understand this correctly? Is that if I stake enough money, enough sol to be clear, then my individual updates to a given DID don't have a transaction cost.
[00:24:53] Speaker D: They still have a transaction fee, but they don't have any additional rent fee.
[00:24:57] Speaker A: I see. And that's about the one penny.
Was that the number?
[00:25:02] Speaker D: Yeah. The transaction fee is significantly smaller than $0.01. The transaction fee itself is.
Is something like to the tune of a hundredth or a few hundredths of a cent.
[00:25:09] Speaker A: Got it. Okay. And what's the threshold on that number for how much sol I need to put in to be rent exempt?
[00:25:20] Speaker D: It can grow to be any size you like, actually. So as Martin says, the absolute smallest update you can make is an update that probably adds another key, and that's 32 bytes plus maybe a little bit of fat.
I don't know how much that translates to into rent, but again, we're talking about less than a cent, I think.
[00:25:38] Speaker E: But obviously, yeah, like really small amounts.
I think maybe a few cents. But it depends on the low SOL price and it's size dependent. So if you add 20 keys to your Ditzel, it's 20 times as much as if you add one key to your didsoul. But the important factor is it's locked SOL, and it's recoverable. So if you delete 19 keys, again, you get that money back. So it's not lost capital, it's just locked capital.
[00:26:14] Speaker A: So have you done any calculations about how this scales? Like this free rent or low rent option complicates the math here, but have you run like, hey, if everyone on the planet has every square foot of their home have its own did, and they're updating that every hour, does it break didsol?
It probably does. Right? That's a ridiculous use case. But understanding the context in which you could scale is the essence of the question.
[00:26:43] Speaker D: We did do some scaling calculations right at the start about this. I just don't have the numbers hand now. When it comes to decentralized registries, specifically blockchain based ones, one of the real motivators for Dizol was that we felt that the economics worked out on Solana far better than on other blockchains at the time. And I suspect also now.
So aside from the fact that if you have every square foot of your house represented by a did, you probably won't need to be performing that many updates on them, and the generative dids probably meet the use case for 99% of the time, especially in an IoT sort of environment like that.
But even with updates and the initial version of DDSOL did have more requirement for updates then it would scale a lot better than any equivalent blockchain. But obviously having the information on a blockchain in itself has trade offs. I think the pro is the decentralized logic layer and, and the censorship resistance of being unable to change or remove the state easily.
And one of the negatives is that it is comparatively higher data storage cost compared to just storing it on an S3 bucket or something like that. But actually as it happens, not prohibitively higher I think for the vast majority of use cases.
[00:28:16] Speaker E: Yeah, but compared to any other level one chain it's unbeatably cheap. Like show me any other L1. And the question is, will that change in the future? And I think I cannot say, like I don't know how. That's more like a Solana chain perspective. Like how well does like not charging regularly for data ownership scale but right now it's super cost efficient and the, the more restrictive factors right now is the compute budget. Actually I don't know Dan, if you mentioned that. So transaction fees are fixed at 5,000 lamp ports, which is quite low. But with these 5,000 lamp ports comes a compute budget based on what you do. So you're restricted in the calculations that you can do, which for like crud, it's not computationally intense. Generally where we just say put data there or don't put data there.
We will see that some of the account abstraction aspects or some of the Ethereum verification keys that takes a lot of compute. So that's where we hit these limits.
But we found innovative ideas to get around these limits in a way.
[00:29:37] Speaker D: Yeah. And those limits have also since we built the original version of Didsol, those limits are now made more flexible. So there were some constraints on the Solana blockchain that existed when we built it that have been lifted now.
[00:29:50] Speaker E: Yeah, certainly. So I listed them here. I will just go down and describe everyone and then we can talk about each of the operations in more detail.
So we have an operation which is called Initialize, which does nothing else than turn a non initialized which we call generative DID into like a persisted state. State. Did we have resize operations which we talked about. You could without changing the state of your did, just allocate much more sol and data to your account.
Then we have add verification method to add a new verification method to your did we have remove verification method to remove a verification method from your did we have Set verification method flags which modifies by modify in certain ways, like sets or remove flags from a verification method. And we can talk about in greater detail what these flags can be.
We have add service to add a service definition, we have remove service to remove a service definition. And we have a set controllers operation that sets or replaces all the controllers of a did.
And lastly, we have a close operation that closes an existing DID account.
[00:31:18] Speaker A: Does this imply that there isn't a way to add an arbitrary property to the DID document?
[00:31:25] Speaker E: Yes. Not without changing the DID program or the DIT SOL program. And I think that was a very active decision.
That was a design decision that we are more restrictive in a way. You cannot add what you don't know and we have to like, we have to go through these details. But for verification method types we have like an enum list of on chain verification method types that we accept at the certain stage. That doesn't mean that this is locked in in a way, but we want it to be more restrictive of what we can support.
But iterating on the Ditzol program we could extend these lists.
Exactly.
[00:32:20] Speaker A: So I appreciate the restricting unknown properties.
What about within the verification methods? Can I use a method that isn't supported on chain and have that in my DID document?
[00:32:30] Speaker D: There are methods that are not supported on chain as in the signature verification cannot be interpreted by the program, but they're still supported.
So you can still add for example a P256 or a sec P256R1 key to your did, but that a message signed by that key would not be interpretable by the program. If that makes sense.
[00:32:58] Speaker A: Yep. Yeah. Now the use case I'm thinking of is when I'm using this DID document to interface with some other system and they have some requirement on what crypto I use or whatever. And so I'm going to use whatever that system needs.
So as long as I have the flexibility to say, hey, this is my verification method with a custom type is that that's supported with this.
[00:33:21] Speaker E: The data or the key field in a way is just a byte blob and it's a byte blob for on chain supported as well as only off chain new methods. And in a way you can write anything into this byte blob, but you will not have any on chain verification for unknown types.
[00:33:41] Speaker A: Okay, great.
Is it possible for a controller of a Solana DID document and the DID to restrict updates to a method call on another Solana app.
Could I introduce some custom logic that is on chain There is an app somewhere.
Is there a way to hook into that and call it before we update the document? Or is that crazy futuristic, nice to have kind of an idea.
[00:34:13] Speaker E: Can you mean more specific, like controller? You mean the DID controller relationship? So as a relationship from. Or you mean the controller, the one that has a key verification method key with a capability invocation.
[00:34:30] Speaker A: So by controller I mean the person who controls the DID functionally, which in your case I think is your capability invocation to update the DID document.
Could I, for example, on one layer restricted. Hey, before you update a verification method, make a method call to this other app that's on Solana and based on what that app decides, proceed or not with this DID document update, then I could have arbitrary complexity. I don't know that's a good idea. But given that Solana has these different apps with different accounts, it seems that I could use the same key to have an account in another app and that maybe I could have this kind of a feature. But it also seems a little advanced and maybe a little bit complexity driving.
[00:35:20] Speaker D: You can.
And just. Martin, again, correct me if I'm saying anything wrong here, but the facts that the account IDs, as we mentioned, look the same as a public key means that it. I mean, you could argue that this is a hack, right? But the account that controls the account, representing the controller, let's put it that way, has an id. You could place that into the capability invocation club, part of the DID you're trying to control, and the program will still interpret that. The program doesn't actually check whether it's an externally owned account which has a private key behind it, or whether it's an account id, we should probably mention the difference between those two things.
Again, I call it a bit of a hack because in a way, it's a bit of a hack. On the Solana programming model in the first place, they identified that about half of the possible public keys in the space for ED25519, or indeed I think for any elliptic curve keys, we're going a bit deep here, but about half of the space of all possible, so to speak, public keys have a private key behind them, and the other ones definitely don't.
And that means that you can basically use the same space, the same 32 byte space, to refer to both types and the type that doesn't have a private key. That space is reserved for program accounts. So whenever you create an account, again for any program on Solana other than the system program. So if you create a DID SOL program account that will have an account ID that looks like a public key, but explicitly isn't because it doesn't have a private key.
You can use that in the didsol program. The didsol program will just say, okay, that's come from this account, that's come from this key. So it's been verified as a controller of the did. It won't check whether there was a private key behind it because it doesn't care.
But officially, According to the DidSpec, it's going to be put into the verification method. And the type of the verification method is going to be ED25519 key or whatever it is.
And it's officially not one because it's got no private key behind it, if you know what I mean.
[00:37:50] Speaker A: Right. So that's brilliant. So because you use the same abstraction to represent both keys and keys controlled by applications, I can just seamlessly slip that in and I get this sort of hook. Yeah, that's really nice.
[00:38:02] Speaker D: Powerful.
[00:38:05] Speaker E: Maybe I rephrase that answer and then Dan can also correct me. So we, like correct each other until the answer is truly right.
So I would describe didsoul as a foundational program, meaning it doesn't have a lot of other dependencies and the program itself doesn't have a generic hook or callback mechanism.
Because also the attack surface would like, multiply if you start adding these custom code elements.
However, and that's the approach that Dan now took, is there's a lot of way to automate DID manipulation through other programs, for example, and the key to this is like adding a program, a DITZO program, as a capability invocation to your program.
So that's exactly what Dan described. Don't use a generic externally owned key pair to control your did, but use a didsol program that doesn't have a associated private key, but can be validated on chain. Manipulate your DID and then do the callback mechanisms there.
And you could drive that to the next level, just as a use case, like we use this Cryptid program to do on chain execution that is accessed via your didsoul state. And now you could drive it one level further where you can say you can use Cryptid to write your DID soul into another did. Like, this is maybe a little confusing and I'm not sure if the application would be. But that's how it would look like on chain if you don't do DID controller relationship. Like you can also do digital controller relationship, but I'm now specifically talking about you have a digital on chain and you want that account slash, that cryptid representation to be in another digital.
And you could do that and in a way have like one ditzol being able to control another Ditzol with some customization to it.
[00:40:33] Speaker D: Circular relationship. One example of that sort of model that I actually have on my DID that I use most frequently is that one of the verification methods on mydid is not in fact a public key with a private key, but it's in fact an account that represents a multisig and that multisig.
For non cryptocurrency people, multisig is basically a construct of more than one key where some proportion of those keys have to sign for any update to be accepted. So you might have.
It's like a lock that needs two keys to open.
So this multisig is controlled by a separate program. It's not controlled by the DID program.
And I use it as a form of social recovery. I mean, I'm playing with it as a form of social recovery. I've never actually luckily had to use it for that. But the idea would be if I lose my key, then closest friends and family would be able to go onto this multisig program UI and sign an update that would add a new key to my did, presumably my replacement key. And they would only do that if they trust me.
So that's an example of what you're talking about. And a pretty powerful use case, I think.
[00:41:57] Speaker E: Exactly. And we don't need to have that support natively in the didsol program, but we can build these use cases in Solana based on the Ditzol program. And I think it was very important for us that we don't say we built multisig into the DSOL program because the attack surface is so much higher, but we can have generic DSOL programs in there and they can be multisig.
Sorry, not.
We can have generic Solana programs in there and they can be multisig. I just said DID SOUL programs, which was technically wrong.
[00:42:36] Speaker A: Yeah, I caught that. It was a good correction.
So Martin, during our pre show prep, you mentioned that you want to talk a bit about the on chain verification for both Solana and Ethereum. Could you talk to us about that a bit?
[00:42:50] Speaker E: Yeah, certainly. And I think it's one of the features that we are most proud of or didsol.
So Ethereum and the account model and everything that we talked to before is ED255ED25519 based, meaning the chain and the chain logic takes over the signature verification. It takes over the replay protection, all these things you would expect a chain to do natively.
Now, Solana enables the validation of EC recover in a way. So the the recovery of an Ethereum address of a 20 byte Ethereum key from a signed message.
And we build logic in a way to allow all the didsol operations to be done with a verification method that is a SECP 251K1 recovery method or full key to be performed. But this needs to be now verified in the program and is not done in the Solana native layer automatically in a way.
So I just want to talk a little bit about it. So the first thing is we audited our code and I think that was one element that was looked at really intensely because it's an implementation that the program provides and not the blockchain infrastructure per se and things that you need to consider. There is, for example, replay protection.
So every Ditzol account now also has to provide its own nouns that it leads in order to protect every Ethereum signed transaction from being replayed.
So if you want to do this recovery transaction, you look up that nounce on your account on chain and you build a predefined signature from the nouns and from what you want to do from the operation and sign it with your Ethereum key and the program then verifies this by recovery.
And, and the cool thing is like Solana still says someone needs to pay the rent, for example, all these infrastructure elements still needs to exist. Like you cannot just come along with a Ethereum only key and do your operations, but that key only needs to do these transactions. So in a way, what does a Ethereum signed transaction look like? It looks like you generate the transaction body by signing like a predefined sub body with your Ethereum transaction and then you sign that outer package with some Solana key. And that could be anyone, because it doesn't matter from an authoritative point of view, like you can make up any Solana. I could send that transaction to Joe and say please submit it to Chain for me and pay the transaction fee. So this wrapped Solana key only is responsible for paying for the transaction fee and the rent change if they want to, but the decision if the change happens is solely done by the Ethereum signature. So it's a pretty neat implementation and it is audited and we're really proud of it.
[00:46:42] Speaker B: This is the end of part one and concludes our show today. The conversation continues on our next episode.
[00:46:50] Speaker A: Martin, thank you for joining us on the show. Daniel, also thank you. Thanks also to our staff our producer, Eric o' Connell and my co host, Eric Shue. I'm your host, Joe Andrew.
[00:47:01] Speaker B: You can find all of our episodes at Rubrik cc. Consider subscribing 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 speaker's employer, organization, committee, or other group or individual.
