Applied Research and Cryptography with cryptographer Robert Annessi from Nash

Chris: 0:00

Welcome to Beyond the Chain, the podcast from Nash that takes a deep look into blockchain technology and connects the dots between decentralized finance, business and the wider world. I'm your host, Chris Fenwick. And I work at Nash as a writer. The Nash team contains experts on various areas of blockchain and decentralized finance technology. And each episode I'm joined by a Nash founder and a special guest here with me is Nash co-founder Ethan fast.

Ethan: 0:25

Hey, Chris. Yeah, it's great to be here. Glad Nash is doing this.

Chris: 0:28

And we're also here with our applied cryptographer Robert Annessi who together with Ethan makes up the Applied Research team. Hi Robert. Ethan's no stranger to followers of Nash, but I'll still allow him to introduce himself here.

Ethan: 0:43

Yeah, sure, prior to Nash, I was doing a PhD at Stanford in computer science. I broadly studied, areas of human computer interaction, which is super important for a lot of things that Nash is doing, and sort of applications there and machine learning as well. In 2017, I actually started getting into blockchain and cryptography in a deeper way, co-founded the group called COZ, with a number of other Nash co-founders before we started Nash, we were all doing that. One of our projects there that I founded called Neon Wallet, started to take off. I was working pretty well with the other co-founders and that's actually kind of how we decided to start Nash. So that's, that's where that came from. So with Nash itself I was involved in forming some of our very first designs for how the exchange, how our technology operates as well as involved in engineering over the several years this company has been running. And, now I've sort of shifted to focus more completely on kind of the future of the technologies that we want to be interacting with and developing. This is kind of the broad scope of this Applied Research team, which we can say more about in a bit but generally the idea with sort of really any sort of research team is to think about the technologies that we might need or want in the future, how might we create those technologies, benefit from those technologies? Really it's, it's a much more kind of high risk reward profile, right? So you want to be investigating a lot of things. Some of those things will work out and maybe work out phenomenally other things, maybe not, but you sort of iterate over test hypotheses, try to future proof really, where the company is going.

Chris: 2:19

Cool. And in this Applied Research team, you work together with Robert who joined the company last year. So Robert, why don't you let us know a bit about your background?

Robert: 2:29

So my educational background is computer engineering, but, I have, and have had a strong interest in security and also did my PhD in the field of network security. A few years ago I basically got hooked by the blockchain space, mostly because of the huge disruptive potential it has. And roughly one year ago was, as Chris said, I joined Nash mostly to make an impact. So that's the personal reason to join. And I'm looking forward to do that.

Chris: 2:58

Ethan already spoke about the idea of Applied Research, but why don't you continue a bit more and talk about the work that the Applied Research team is doing? How would you characterize that work?

Robert: 3:09

I would say it's mostly about improving and extending the Nash products, which since there's a lot of research involved, there's also a fair chance of failing, which to be fair, I like a lot.

Ethan: 3:24

Yeah. That's sort of, one definition of research is, if you know, what's going to work, it's not research. So I would say a lot of things that we're working on now are research more in the sense of how would I put it? Like we're not developing fundamentally new forms of cryptography, but we are looking at sort of the space of available technologies and seeing how those pieces can be put together to enable systems that have never existed before and you know, sometimes those ideas will work. Sometimes those ideas will not work. I think the element of risk is key to the idea.

Chris: 4:00

So it's more about looking at sort of state of the art research that's maybe coming from a university setting and thinking about how you can apply that to Nash's business, rather than doing kind of fundamental new mathematical research.

Ethan: 4:16

Sure. Although I would actually say, you know, putting technologies together in a new way is research in a sense, right? So again, my background, really from a research standpoint is in human computer interaction and in human computer interaction, you're studying what new kinds of experiences can technology enable for people? Do these experiences work to accomplish some goal? Do they make sense? Can we invent fundamentally new forms of user interaction with technology? Sometimes you're building the core technologies that enable those things, but sometimes you're not. So for example, if you look at how deep learning or machine learning has changed the way people interact with, you know, tons of technologies, often the research that goes into developing those new interactions isn't at the level of like core machine learning, for example. And that's very similar to what we do with blockchain technologies. So to take one really simple example, our system for storing the user private keys, such that, only the user has access to the private key, but they can log in with a username and a password to get into their account. This is a form of interaction, right? Where we didn't invent any particular form of cryptography or any particular kind of security idea. But what we did do is we took the available kind of building blocks and put them together in a way that really, before we did that didn't exist commonly. Right. So, you're taking some pieces, and putting them together in a form that has never existed and then you see, okay you know what can we do with that, that, that wasn't possible. So I still think it's research. It's just a different kind of research.

Chris: 5:58

So I suppose in a sense, like the publication of that research would actually be the open source code we published on Gitlab recently.

Ethan: 6:05

I mean, you could actually publish it, right? So this hasn't been a priority for Nash. I mean, this is maybe an interesting, broader conversation, like, you know, when do you publish and why do you publish when you're in industry? But you could have taken some of the ideas we put into our noncustodial wallet set up and publish them in some human computer interaction venue, for sure, no question about it. Usable security ideas like that, those things are very important people publish work on how can we enable new, more usable forms of security that, you know, provide more security, but that people actually use. These are real things that people do publish about. We are not speaking as Nash necessarily to that research community directly. Right? We care more about our users. And so we didn't take the time to go and publish a KY publication on the security improvements of our wallet for user, because that just wasn't a priority, but we could actually publish them.

Chris: 7:02

So that you're saying there's actually like some significant continuity between the work you do and say, research in a university setting as well.

Ethan: 7:11

Yeah.

Chris: 7:12

What are the main topics that you've been working on so far?

Ethan: 7:16

Well, I'll let Robert say something in a bit, but just to review, I guess, you know, some of the things I've contributed to really everything at the protocol and architecture level from the beginning This is all a very collaborative process so no one person is responsible for any of those things. Basically what's concerned me from the beginning is figuring out, you know, how can Nash design a system that accomplishes all of the goals that we set out to achieve. These core goals of a non-custodial trading system, a noncustodial fund management system, and very importantly, a good user experience. How can you combine all those things together? Then there's a lot of technologies that go into doing that. Everything from what kind of matching engine do we have on the backend, how is it interacting with the blockchains to what kind of client, do we have on the front end? What kind of cryptography is it using to make sure that the user is the only one that owns their private key? So really that sort of full design space is something that all of the co-founders can be proud of having contributed to, but I definitely spent a long time thinking about and iterating on. So Robert can say more about our recent work.

Robert: 8:25

Sure. Right. Until recently I've mainly worked on the threshold signatures and secure multi-party computation, which ultimately resulted in the noncustodial API keys. Which now Nash is able to provide, so this is what I've worked on until recently.

Chris: 8:42

Take us through that a bit, explain some more of the fundamental ideas behind the cryptography involved? Maybe explain things like what a homomorphic encryption scheme is, this sort of thing. I'm sure this will be interesting for our listeners

Robert: 8:57

Maybe before going into the API keys directly, we can explain this non-custodial property that Nash Exchange provides. This also explains why it makes the security a bit more challenging. So, if you think about it, the custodial centralized exchange basically acts like a bank. So as a user I move my funds into the exchange and basically trust the exchange to give me back my funds when I ask for it. So, this makes moving the funds between the accounts on the exchange straightforward, because this is just a matter of changing a database entry, basically, but it's also means that the security of the user's funds is tied to the security of the exchange. And this may be acceptable for a bank let's say, because we have legal system that protects the user's funds to a certain extent, but there is no such protection in the cryptocurrency space. And there's many people who got victims of that and who can, tell stories about their, their funds getting lost because of an exchange hack so with a non-custodial exchange, like Nash, the exchange doesn't have the custody of the user's funds. So now the security of the funds doesn't depend on the security of the exchange, but on the security of the user's device, this, this could be like, a mobile phone or a desktop device, or, maybe even a hardware wallet. Going back to the API keys so the goal of the API keys is to restrict access to an account. For example, as an account holder, want to say, I want to give this API key access to my Bitcoin funds for trading, but not for withdrawing Bitcoin or only withdrawing to a specific address.

Chris: 10:38

So instead of a user using their normal private key to log in and interact with Nash instead, they would have their seed phrase and their private key kept securely, like you do with your seed phrase from a hardware wallet and when interacting with Nash instead, you just use an API.

Robert: 10:56

Exactly. So basically what you could do, you just need your, your seed phrase or your secret key, if you like, in order to generate the API key, and then you can put it away you can either put it into a hardware wallet or put it into a paper wallet, even if you like, and just act upon this API key. A bit from a high level perspective, a bit simplified, basically Nash helps the holder of the secret key to restrict the access to his funds without Nash controlling the user's funds. This can be achieved with the user basically splitting the secret key into two secret shares and each of the share gives the holder of the share, no information about secret key, but if the holder of the shares cooperate, then they can generate signatures as if they knew the secret key. The way we do this is basically one share, goes to the API key and the other share goes to Nash. And together with the share that goes to Nash, there's also a policy involved. The policy basically describes how we can basically, as a restriction, let's say, for example, a withdrawal restriction on this or this key may only withdraw Bitcoin to a certain address, let's say so we have an API key how a user can use it is basically the user will generate something that we call a pre signature and then sends the pre signature over to Nash and if that request matches the signing policy then Nash will complete the signature. And if the request doesn't match the signing policy, for example the withdrawal request will be to a wrong address, or I've read an address that is not part of the signing policy then Nash will not complete the signature.

Chris: 12:47

So Nash is present as an enforcer, so to speak, we can enforce that they can only do certain things, but we don't have the power to move their funds around because we remain non-custodial.

Ethan: 13:01

So that actually Chris relates to something you brought up earlier, the idea of homomorphic encryption. I think actually this as a high level concept can give some flavor really for what the system is doing. Homomorphic encryption is basically giving people the ability to do computations, make transformations like on encrypted data without knowing what the data inside is. So a very simple example would have an encrypted number. And then I want to add it with another encrypted number but I want to do that without ever knowing what those numbers that I'm adding are. That's a simple example of homomorphic encryption. And so fundamentally what we're doing with something like a threshold signature scheme is using those ideas to split the creation of a scheme into two parts where the computation can be accomplished through homomorphy without the person who's doing the computation knowing the value inside. So that just gives you a little bit of high level of how does this work? Like, How are we able to generate a signature without knowing the private key? Uh it's because that, that private key has been split into parts and we can use this space stability to do math inside encrypted data to create that signature.

Chris: 14:15

And this is important because it let's Nash enforce policies like a centralized exchange might be able to enforce. However, the centralized exchange has custody of the user funds.

Ethan: 14:28

That's right. So we can, we can behave in ways that are similar and in some sense, like good for a certain definition of good on the centralized exchange, without the downside of actually holding the user funds, we can prevent someone who logs in from like withdrawing the total fund balance, for example, without controlling the funds.

Chris: 14:45

So in a way it's even more powerful than what centralized exchanges can offer when they themselves have absolute control of the funds.

Ethan: 14:54

Yup. That's right. And it's also a perfect example of kind of taking building blocks that exist, right? Threshold signatures have existed for a very long time, and applying them in a novel way that really no one has done before.

Chris: 15:06

Are there actually any other exchanges which use MPC for API keys?

Ethan: 15:12

No, there are barely any wallets that use MPC.

Chris: 15:15

Where is this technology used elsewhere? Maybe not even in blockchain.

Ethan: 15:19

That's a great question. Do you have any idea Robert where threshold signatures are used?

Robert: 15:23

Well, there's a famous historic example I think of the first well it's, not a threshold signature, but it's a multiparty computation I .think in the late two thousands where it was used in the Netherlands in, in some auction so maybe this could be an example for like where it was practically used. Threshold signatures. I mean, currently I think it is mostly. It's advertised at least in high stake customers in order to protect their secret keys with additional security let's say, but I'm not sure how much it's actually used in practice.

Ethan: 15:57

Yeah. I mean, homomorphic encryption, there, there's a lot of interesting research going on there about how that can be used. So like some other examples would be people who want to do like computation or model training on private medical data. Right. So they'll be like, can you train models without revealing information there. Secure voting would be another example. Can you sort of use those ideas to like add up and in a provable way, like verify, some number of things that have happened without actually knowing what any individual did? So there's lots of examples for homomorphic encryption, but threshold signatures are I think more kind of specific to blockchain because of the sort of connection to public private key signatures and, and the security of funds is so important. Right. I'm not sure of any other use that they have, but they're there very well could be one.

Robert: 16:44

Theoretically, it could be used anywhere where you want to protect one secret key and you want to increase the security of the secret key.

Chris: 16:52

For Nash, the way we use them at the moment is essentially for algorithmic traders. So an institution can create different accounts for different trading teams or whatever, who each have their own bot without giving them access to the entire institution's funds. And in future, we plan to extend this to user wallets in the way we described earlier so that users interact through the API rather than with their private key. What other potential does this technology have for blockchain? I mean, it's not just about protecting traders could it be used in conjunction with state channels more broadly?

Ethan: 17:32

Yeah. Robert can say more about this, but you see a lot of people taking, the, the idea of threshold signatures or various threshold signature schemes and applying it to make. More efficient, other existing kind of multisig style interactions on blockchain. So, so it really is like just a tool that you can use for any of those things. I would also just step back and point out that you can use it for very different kinds of things in algorithmic trading so for example, if you want to have shared custody of an account with, you know, friends or family, or you want to have various policies that one person wants to enforce, or if you want to do key recovery systems in specific ways that you share among friends, with a certain number of agreement, you can recover key, these are all things where you could use similar ideas.

Robert: 18:16

Maybe I should add here. Technically, this is all possible, but the main challenge comes from how to implement this efficiently. So I would say this is the main challenge.

Chris: 18:27

So what exactly do you mean by implemented efficiently?

Robert: 18:30

Well, if, if we stick to the example of threshold signatures, then they certainly exist for quite some time. Don't quote me on the, on the numbers, but let's say 20 years or even longer maybe, but just recently they became sufficiently efficient. Let's put it this way so that we could use it with some additional optimizations so that we can actually use it on a day to day basis, even for this exchange scenario. Let's say. I mean, if you look at the requirements of traders than they certainly require low latency, so this is kind of a strong requirement while before you could, you could do threshold signatures until a couple of years ago it took minutes to generate a signature even hours to generate keys. So this is certainly unacceptable for traders.

Chris: 19:15

What's changed over the last few years? Is it that's processing power is improved or people have just come up with better algorithms for implementing these?

Robert: 19:24

Well, processing power certainly has not improved. I mean, we haven't seen any improvement in the basically last 15 years when it comes to processing power when we talk about CPUs, so it's, it's definitely people coming up with smart ideas.

Ethan: 19:38

Yeah, we're using a technique that was released in 2018, for example, we, we did an analysis of a number of techniques, basically for performance and implementation, sort of simplicity, basically lower surface area, the better lower rounds of communication, the better, faster protocol, the better and you know, there was quite a bit of variance and even the recent work and we used a very recent protocol. So I think it's safe to say they've improved considerably.

Chris: 20:04

How much do you can Robert actually build? Is it that you come up with the protocol and it's passed to other developers or are you actually building these tools yourselves?

Ethan: 20:13

I mean, historically with Nash, I have done much more sort of protocol development and architecture development than actual coding myself personally. That said I am working on a few projects where I'm doing pretty extensive coding at the moment and Robert implemented MPC keys, basically by himself so, definitely he's, deepened implementation there.

Robert: 20:33

Yeah, maybe, maybe I could add it depends a bit on the, on the timeframe. Let's say like when you're researching a new topic, then it's, then you certainly don't spend a lot of time implementing stuff. But when it comes to implementing prototypes, benchmarking stuff, in the case of the MPC based API keys also to an implementation and certainly we also implemented that stuff, yeah.

Chris: 20:58

Could you talk a little bit about some of the tools you used when you did this? Like what languages did you use?

Robert: 21:04

Well, for the, API keys we basically used RUST only, I would say for the core part, there was, there was a smaller Python script involved as well. Andthere is, backend wise, there is Elixir and front-end wise, there is, TypeScript and Python client but basically the core is written in RUST and then we basically provide foreign functioning interfaces to other languages. That's a Elixir on the one end and TypeScript on the other end and of course assembly for the, for the browser part.

Chris: 21:36

So could you maybe tell us a little bit more about RUST and what makes it particularly useful for this application?

Robert: 21:42

Sure. So it's a strictly typed language, so that's, ah, let's put it this way. For prototyping in Python, you can basically go on and do, a lot within a very short time and I don't feel the same way about RUST. It basically takes more time in order to create something, but on the positive side, first of all, you have this, this, this memory safety, so that that's nice. And on the other hand you have the performance the compiled code is very fast.

Ethan: 22:08

You know, it takes a little bit longer to build something in RUST but the end product is more robust, less likely to have issues. I think that's definitely true. In general, I'm a bit of a programming language geek. I play with tons of languages. I try to experiment with as many of them as I can. And, RUST is really unique in that it really straddles this space of languages with very nice expressive type systems, but also languages in which, you can operate at a low level and sort of basically write really any kind of program you want. This is, this is pretty rare, to have a language with, with a type system that is, is so expressive and that yet still allows you to produce this super performant bytecode also, just to kind of call out to Robert's code. So he, you know, he implemented the threshold signature MPC stuff and basically we've seen no issues in production with this code, right? So, obviously we have tests and, and we tested things as we went, but it's very rare to have bug free code pushed to production. And I think one big reason for that is, the RUST type system and basically the things that's able to protect you against at compile time. One other thing is a Robert said takes a little longer to develop with this. that's true. But type systems, if you're developing sufficiently complex applications, having a strong and expressive type system can actually start speeding things up after you get to a certain point, right? If you have a really complex, system and you want to make a change, if you're in a language that doesn't enforce types or doesn't allow you to express complex types you're going to have to really just kind of search over all of the code and find the places where, you know, your change touched and manually adjust them and hope you got it right and run lots of tests and do lots of testing. Whereas if you have an expressive enough language with a good enough type system, it can help you figure out and debug all those issues at compile time. So when you have these like really complex systems and then you make a change the compiler can kind of work with you as a partner to go and sort of fix all those issues that you encountered. So the time trade off does actually kind of get a little bit better over time, depending on the complexity of the system you're building.

Robert: 24:18

I would certainly agreed with that.

Chris: 24:20

There's a lot of room for error when programming the results from things you might overlook when converting between types. So having different types, interacting with each other, is this maybe a bit like there was, I forgotten which one it was, there was a cryptocurrency wallet recently that generated user keys.

Ethan: 24:39

Oh yeah. I know which one you're talking about.

Chris: 24:41

It used like a random number generator, but because they used a particular type that it was set up so that the entire key space only had eight bytes or something like this. So because of the nature of the random number generator they used and they didn't know that it was always going to return a string of a particular length.

Ethan: 24:59

That's something a type system can protect you against. You do have to use it though. Like if you just say you're okay with whatever the default integer representation in my language is then that that's not going to be good for you because you're not thinking about and making explicit the decisions you're making. A language like RUST will actually force you to choose if you're using integers like 32 bit 64, whatever but really to do this properly with cryptography, you should use dedicated big integer, big float representations for the computations you're doing. And so, you know, that's something that you can enforce at compile time, assuming you're using those kinds of representations.

Chris: 25:35

Well, let's talk now about what you're working on at the moment and maybe the future project. So what's each of you looking into at the moment?

Robert: 25:43

What I'm currently looking into is how we could implement options and futures trading. And we touched this a bit before, so there's again, a challenge to implement this in a non-custodial fashion. So there's certainly. kind of a technological challenge there. So this is what I'm currently working on, basically.

Ethan: 26:05

So that's super important. This is something I mentioned in the last company report. So one big initiative we have is basically figuring out how we can enable any form of leveraged trading on the exchange remaining non-custodial, but safely enabling leverage. That's a big focus area for the research team.

Chris: 26:23

This would involve some sort of DeFi like products where users can lend funds that are then used as collateral.

Ethan: 26:30

Potentially. Yeah. I mean, if you could do it a lot of different ways, you don't necessarily have to use lending to do it, but that's definitely a possibility. I think the trickiest parts of this are when it gets into Bitcoin. How you can enable leveraged trading on Bitcoin in a safe way that becomes very challenging. I think we do have some good options for like Ethereum based products there for leverage, like, so that that's definitely possible. The Bitcoin thing is a bigger question mark. That's definitely in the research side of research. Just to follow up on other things we're working on. I've also been spending a fair amount of time recently looking into algorithmic trading and sort of how we can generate trading algorithms that help improve the exchange liquidity and volume. I think that will be really important as we start ramping up as well. So this is another big search problem where we're building a lot of infrastructure to help us kind of analyze the space and figure out what's going on.

Chris: 27:23

This would involve Nash deploying our own bots to do arbitrage training for example.

Ethan: 27:28

Potentially, I mean, it's at an earlier phase than that but basically, yeah, I mean, enabling our exchange to you know, do arbitrage with other exchanges, take advantage of other liquidity that exists if possible, you know, in some sense, this is like the simplest form of dogfooding your own product, right? So we have an exchange product. Can the exchange use it's own product effectively? And of course all of this would be like real trading this isn't isn't wash trading, this isn't any sort of fake stuff. This is actually using the product to generate profit. So algorithmic trading is really interesting.

Chris: 28:01

So would you say some of these topics aren't so much focused on fundamental cryptography, like the API keys, they're more generally to do with the possibilities of blockchain infrastructure?

Ethan: 28:12

I think non-custodial leverage is going to draw on cryptography probably to at least the same extent that the API key stuff did. Ideally it would be another building blocks scenario where we can take some really good, powerful ideas and combine them in the right way to make this possible but TBD whether that's actually the case.

Chris: 28:32

Well, we very much look forward to seeing the results of this work. that's all we have time for today. Thank you to Ethan and Robert for joining me.

Ethan: 28:42

Thanks, Chris. Yeah, this was super fun. Yeah.

Robert: 28:45

Thanks, Chris.

Chris: 28:47

And Thank you for listening to Beyond the Chain. Subscribe with your favorite listening stream and you won't miss an episode. You can also find the full text of this episode on podcast.nash.io.