[music] So today I will be talking about a thing called a concept called polymorphic crypto chains. It is today's presentation is a design note for uh aimed at people who develop and maintain chain clients. Uh so first question is what is a polymorphic chain? As you can see on the slide behind me, it's an appendon identity protected chain where every block names uh its hash and signature functions uh that protects them in when you get this uh what falls is a primit uh is the fact that primitive can be replaced without any fork and without resigning history. First let's see uh what we have built as a proof of concept yet.
On the screen you can see uh a link to a repository. On the left side of the screen uh there is a QR code that you can scan and you land on the same URL as above. A very short description of what is in the in this repository. First there is a formal definition of security model and uh parameter tables. Also there is a reference implementation made in Python and two C++ uh and two ports one C++ and one of Rust uh that verifies the concept the concept is not just uh an artifact of Python language.
It can be ported to whatever you want. Also uh at the end [snorts] you can see a very short runabout demo demo script that covers uh 10 different scenarios uh from the real life. What's the structure of this presentation? We have five different sections. First is uh what is the principle behind this construct?
What are the high level ideas that we have? Second is uh what's new and what's the novelty here. Uh what we'll have uh we will have in this section is basically a comparison between polymorphic cryptochain and uh currently existing on the market chains. Third is uh very high level overview of the architecture of the what we have right now. Fourth is some useful real life tips that you have to check uh you have to think about even before you start the code and if you have t if we have time we will uh deep uh very shortly in the code itself and I'm as I'm saying if we have time I don't see the timer here which would be bad uh so what's a polymorphic crypto chain The whole idea is uh way simpler than it sounds.
You need just one more field in the block and one substitution in the link function. Everything else falls from only these two facts that you have. Uh first let's see how the box uh what's the box structure in this crypto chain. First three parts are pretty much the same for every uh chain that we have seen so far. It is header, payload and proof.
Uh the new thing is the fourth part which is uh meta. This thing uh holds all the cryptography required to verify the block itself. uh there you see hash ID, signature ID, parameters and chain versions as well. We'll see why chain version is important. And uh one one other thing that I need to mention is the fact that link function is a bit different than the regular one.
In the regular case, you has the same hash applied by link function. Here link function is subscribed on the metadata of the block itself. So we'll see why this is important and what what it gives us later. Now let's answer the question how we define an algorithm suit that we store in the meta section of the block. It is also very simple.
Uh what we need is just four functions. want to generate key, want to uh h the block and especially sign and verify the block itself. Uh it is not that that interesting what is in the block. Way more interesting is what is not in uh this interface. Uh there are no algorithm specific parameters.
uh there are no key sizes and uh something that assumes uh anything about the cryptography and hank itself. Uh if we follow these rules uh what we get is two things and they are almost free. Adding a suit does not require a quant code change because it is just an entry in a table and a hybrid signatures are also supported without a code change. We will see how a bit later. Uh now when we get the construct uh of the suit, let's see how we use uh very simple validator at least at high level.
The validation in the client never assumes anything about the cryptography itself. Everything in the cryptography is uh worked in the algorithm suit that I described in the previous slide. Uh what you can see on the left is uh sudo code for a sample verifier. There are four conditions that need to be mentioned and they are important. First one is index needs to be sequential.
Uh second one uh that second condition that the verifier needs to check is the previous hash matches under this block hash. And the third the third cryptograph cryptography condition is uh that the proof needs to be verified under the block metadata information. Fourth thing uh fourth condition is uh a special one because it's not cryptography. It is more of a policy woke up chain version is permitted by this by the active policy is effectively the way to discard and forbid uh certain algorithms for later use. We will see how this happens later in the presentation as well.
Now uh the fair question is what's new? uh there are already chains that uh change algorithms. Uh so let's see what's the difference here. On the screen you can see five four approaches. Uh first two are relatively well well known and old.
Uh the algorithm is embedded directly into the client source code. The second option is uh the client algorithm the algorithm changes at a certain block height. Uh both of these has some weaknesses and they need uh code change and uh coordinated cut over or a hard fork uh before you can change the algorithm the signature algorithm. Uh third and fourth work well together. uh you can implement uh a per account key record or something like this on top of polymorphic blocks.
We will see how this happens as an example a bit later. Uh so this chain has three properties uh that needs to be stated precisely and we can see what deres from there. First one is algorithm identity need to be uh need to stay in the signed pre-image otherwise uh the chain is uh vulnerable to attacks because some attacker might replace the we uh the the signature algorithm with a weaker one and still keep the block valid. Uh another important thing that we want to mention is signing key are independent and needs to be different per algorithm. So this means that in the hybrid blocks you have to break both signatures to to be able to forge the block otherwise it won't work.
Of course if you write the correct verifier. Uh and one more important one other important thing is the verification is part is partial and reportable. This property uh gives us the ability to uh upgrade the chain without a synchron synchronized cut over or a hard fork because basically every client can update when it when it needs to be updated. Now let's explain uh what exactly is built and how we build it with a high level code examples. First one is uh how the play image block looks like.
There are four four proper uh four fields four important fields uh here index time stamp uh previous uh previous h and the suit all of them needs to be in the pre-image and needs to be signed uh for different reasons. Uh I already mentioned that uh the algorithm suit uh needs to be in the pre-signed image and explained why. Uh the time stamp is also very useful for later audit trails if you need to know when a certain event happens. Uh if it is outside it can be easily forged. Uh let's explain how we can implement a hybrid suit uh as well because I mentioned a hybrid suit is just another entry in a table.
I will explain how uh there is a suggest the suggest approach is relatively easy. You can generate two keys uh for two separate keys one for each uh signature scheme that you need. You can concatenate them together and prefix them with a big Indian four byte notation length of the first key. From there when you have this key uh you can pass it to verify and sign function and they can decode it back. From chain perspective key is still uh just several bytes packed together in an array.
So how we can retire a suit a suit uh securely? Retiring a suit uh should be not should not be a configuration. It's a good way to be in the chain and can be replayed and verified and audited later. Four practical things uh that I can state here is uniqueness. First of it uh you should not be allowed to change uh default algorithm suit more than once in a given chain version.
Uh authorization is the fact that you don't need uh it's not a good idea to allow single person to change the algorithm suits in a chain because you need governance and in most cases you need consensus. You can make it using a quorum or multi- signature or other techniques. Two important implementation notes here are that forward forward consistency and uh roll back. They're basically saying if you discard if you retire suit no other no clients should be verifying blocks against the retired suit later. they need to remember the suit is retired and need to discard every book that came later with this suit.
Uh so as I mentioned earlier uh per key uh per account keys and polymorphic blockchain works well together. On the right side of the left side of the screen, sorry. Uh you can see a very simple implementation, very simplified implementation of uh something similar to Ethereum per account uh key proposal AI EIP 8141. Uh you can see that from chain perspective it is just get the key and start using it wherever you need it. So the important thing from development perspective are in this chapter.
I will try to state them very quickly. First one uh as it is supposed to you as you are supposed to implement uh a quant in different languages and different runtimes use canonical encodings. Cabore or isn or whatever you feel uh useful in your case but please do not use JSON dumps and ordered keys because there are a lot of issues with this. Uh second use uris and or ids to identify suits. There are standard ways to name a suit.
Don't use uh just strings because they're they can be misleading. And last thing, put H version in the pre-image. So it needs to be signed and secure. Second thing that you need to think about is the cost. Basically, uh according to Piku Fabric, the main cost came from the additional hashes that came with the wonker keys.
uh for postquantum uh secure algorithms. As you can see on the screen uh postquantum secure algorithms are order of magnitudes higher uh bigger than the classical ones. You have to pay uh to the uh you have to pay this on every node with disk usage and network usage and hashing functionality. So when you size the chain, think about the biggest that you're going to support and don't size for the classical ones. It will fail.
Uh the other thing that you need to think about is the failure behavior. I already mentioned that partial validation is important otherwise you need to synchronize client updates. The second thing is monotonic policy. If you uh retire a suit, every client needs to remember this. Of course, later you can re rain in it the suit, but every client needs to remember and the chain needs to follow through.
[clears throat] And please use constant time primitives when you compare otherwise for a lot of the cryptography it leaks too much data and it is just not secure. I'll skip the sign policy object and we are here at the at the last uh chapter. What we have right now in the repository that was on the screen earlier, we have three implementations. One Python for reference and respectively C++ and Rust ports that you can see. Everything under this repository is GPL 3+.
So you're free to use it pretty much however you want. And this is what the test coverage is. The whole purpose of this test is to test some real life scenarios that you can use to check uh the constru uh to verify that the construct works and do whatever you want. And as a wrap-up, if you have to think about something and remember something from this presentation, think that once a block declares a cryptography that protects it, replacing a primitive stop being a fork. You can make it just like an register entry.
That's it. Thank you everyone. [music]
Automatic transcript — names and jargon may be misspelled.