August 6, 2020 • 29 mins
In episode one, host Chris Fenwick is joined by Nash co-founder Ethan Fast and our applied cryptographer, Robert Annessi, who together make up the Applied Research team. We discuss API secrets, multi-party computation (MPC) in a non-custodial environment and ongoing research.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Chris (00:00):
Welcome to Beyond the Chain, the podcast from Nash
that takes a deep look intoblockchain technology and
connects the dots betweendecentralized finance, business
and the wider world.
I'm your host, Chris Fenwick.
And I work at Nash as a writer.
The Nash team contains expertson various areas of blockchain
and decentralized financetechnology.
And each episode I'm joined by aNash founder and a special guest
(00:22):
here with me is Nash co-founderEthan fast.
Ethan (00:25):
Hey, Chris.
Yeah, it's great to be here.
Glad Nash is doing this.
Chris (00:28):
And we're also here with our applied cryptographer Robert
Annessi who together with Ethanmakes up the Applied Research
team.
Hi Robert.
Ethan's no stranger to followersof Nash, but I'll still allow
him to introduce himself here.
Ethan (00:43):
Yeah, sure, prior to Nash, I was doing a PhD at
Stanford in computer science.
I broadly studied, areas ofhuman computer interaction,
which is super important for alot of things that Nash is
doing, and sort of applicationsthere and machine learning as
well.
In 2017, I actually startedgetting into blockchain and
cryptography in a deeper way,co-founded the group called COZ,
(01:05):
with a number of other Nashco-founders before we started
Nash, we were all doing that.
One of our projects there that Ifounded called Neon Wallet,
started to take off.
I was working pretty well withthe other co-founders and that's
actually kind of how we decidedto start Nash.
So that's, that's where thatcame from.
So with Nash itself I wasinvolved in forming some of our
(01:26):
very first designs for how theexchange, how our technology
operates as well as involved inengineering over the several
years this company has beenrunning.
And, now I've sort of shifted tofocus more completely on kind of
the future of the technologiesthat we want to be interacting
with and developing.
This is kind of the broad scopeof this Applied Research team,
(01:48):
which we can say more about in abit but generally the idea with
sort of really any sort ofresearch team is to think about
the technologies that we mightneed or want in the future, how
might we create thosetechnologies, benefit from those
technologies?
Really it's, it's a much morekind of high risk reward
profile, right?
So you want to be investigatinga lot of things.
(02:09):
Some of those things will workout and maybe work out
phenomenally other things, maybenot, but you sort of iterate
over test hypotheses, try tofuture proof really, where the
company is going.
Chris (02:19):
Cool.
And in this Applied Researchteam, you work together with
Robert who joined the companylast year.
So Robert, why don't you let usknow a bit about your
background?
Robert (02:29):
So my educational background is computer
engineering, but, I have, andhave had a strong interest in
security and also did my PhD inthe field of network security.
A few years ago I basically gothooked by the blockchain space,
mostly because of the hugedisruptive potential it has.
And roughly one year ago was, asChris said, I joined Nash mostly
(02:51):
to make an impact.
So that's the personal reason tojoin.
And I'm looking forward to dothat.
Chris (02:58):
Ethan already spoke about the idea of Applied Research,
but why don't you continue a bitmore and talk about the work
that the Applied Research teamis doing?
How would you characterize thatwork?
Robert (03:09):
I would say it's mostly about improving and extending
the Nash products, which sincethere's a lot of research
involved, there's also a fairchance of failing, which to be
fair, I like a lot.
Ethan (03:24):
Yeah.
That's sort of, one definitionof research is, if you know,
what's going to work, it's notresearch.
So I would say a lot of thingsthat we're working on now are
research more in the sense ofhow would I put it?
Like we're not developingfundamentally new forms of
cryptography, but we are lookingat sort of the space of
(03:45):
available technologies andseeing how those pieces can be
put together to enable systemsthat have never existed before
and you know, sometimes thoseideas will work.
Sometimes those ideas will notwork.
I think the element of risk iskey to the idea.
Chris (04:00):
So it's more about looking at sort of state of the
art research that's maybe comingfrom a university setting and
thinking about how you can applythat to Nash's business, rather
than doing kind of fundamentalnew mathematical research.
Ethan (04:16):
Sure.
Although I would actually say,you know, putting technologies
together in a new way isresearch in a sense, right?
So again, my background, reallyfrom a research standpoint is in
human computer interaction andin human computer interaction,
you're studying what new kindsof experiences can technology
enable for people?
Do these experiences work toaccomplish some goal?
(04:38):
Do they make sense?
Can we invent fundamentally newforms of user interaction with
technology?
Sometimes you're building thecore technologies that enable
those things, but sometimesyou're not.
So for example, if you look athow deep learning or machine
learning has changed the waypeople interact with, you know,
tons of technologies, often theresearch that goes into
(05:00):
developing those newinteractions isn't at the level
of like core machine learning,for example.
And that's very similar to whatwe do with blockchain
technologies.
So to take one really simpleexample, our system for storing
the user private keys, suchthat, only the user has access
to the private key, but they canlog in with a username and a
(05:22):
password to get into theiraccount.
This is a form of interaction,right?
Where we didn't invent anyparticular form of cryptography
or any particular kind ofsecurity idea.
But what we did do is we tookthe available kind of building
blocks and put them together ina way that really, before we did
that didn't exist commonly.
(05:43):
Right.
So, you're taking some pieces,and putting them together in a
form that has never existed andthen you see, okay you know what
can we do with that, that, thatwasn't possible.
So I still think it's research.
It's just a different kind ofresearch.
Chris (05:58):
So I suppose in a sense, like the publication of that
research would actually be theopen source code we published on
Gitlab recently.
Ethan (06:05):
I mean, you could actually publish it, right?
So this hasn't been a priorityfor Nash.
I mean, this is maybe aninteresting, broader
conversation, like, you know,when do you publish and why do
you publish when you're inindustry?
But you could have taken some ofthe ideas we put into our
noncustodial wallet set up andpublish them in some human
(06:26):
computer interaction venue, forsure, no question about it.
Usable security ideas like that,those things are very important
people publish work on how canwe enable new, more usable forms
of security that, you know,provide more security, but that
people actually use.
These are real things thatpeople do publish about.
We are not speaking as Nashnecessarily to that research
(06:47):
community directly.
Right?
We care more about our users.
And so we didn't take the timeto go and publish a KY
publication on the securityimprovements of our wallet for
user, because that just wasn't apriority, but we could actually
publish them.
Chris (07:02):
So that you're saying there's actually like some
significant continuity betweenthe work you do and say,
research in a university settingas well.
Ethan (07:11):
Yeah.
Chris (07:12):
What are the main topics that you've been working on so
far?
Ethan (07:16):
Well, I'll let Robert say something in a bit, but just to
review, I guess, you know, someof the things I've contributed
to really everything at theprotocol and architecture level
from the beginning This is all avery collaborative process so no
one person is responsible forany of those things.
Basically what's concerned mefrom the beginning is figuring
out, you know, how can Nashdesign a system that
(07:37):
accomplishes all of the goalsthat we set out to achieve.
These core goals of anon-custodial trading system, a
noncustodial fund managementsystem, and very importantly, a
good user experience.
How can you combine all thosethings together?
Then there's a lot oftechnologies that go into doing
that.
Everything from what kind ofmatching engine do we have on
the backend, how is itinteracting with the blockchains
(08:00):
to what kind of client, do wehave on the front end?
What kind of cryptography is itusing to make sure that the user
is the only one that owns theirprivate key?
So really that sort of fulldesign space is something that
all of the co-founders can beproud of having contributed to,
but I definitely spent a longtime thinking about and
iterating on.
(08:20):
So Robert can say more about ourrecent work.
Robert (08:25):
Sure.
Right.
Until recently I've mainlyworked on the threshold
signatures and securemulti-party computation, which
ultimately resulted in thenoncustodial API keys.
Which now Nash is able toprovide, so this is what I've
worked on until recently.
Chris (08:42):
Take us through that a bit, explain some more of the
fundamental ideas behind thecryptography involved?
Maybe explain things like what ahomomorphic encryption scheme
is, this sort of thing.
I'm sure this will beinteresting for our listeners
Robert (08:57):
Maybe before going into the API keys directly, we can
explain this non-custodialproperty that Nash Exchange
provides.
This also explains why it makesthe security a bit more
challenging.
So, if you think about it, thecustodial centralized exchange
basically acts like a bank.
So as a user I move my fundsinto the exchange and basically
(09:21):
trust the exchange to give meback my funds when I ask for it.
So, this makes moving the fundsbetween 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'sfunds is tied to the security of
the exchange.
And this may be acceptable for abank let's say, because we have
(09:44):
legal system that protects theuser's funds to a certain
extent, but there is no suchprotection in the cryptocurrency
space.
And there's many people who gotvictims of that and who can,
tell stories about their, theirfunds getting lost because of an
exchange hack so with anon-custodial exchange, like
Nash, the exchange doesn't havethe custody of the user's funds.
(10:06):
So now the security of the fundsdoesn't depend on the security
of the exchange, but on thesecurity of the user's device,
this, this could be like, amobile phone or a desktop
device, or, maybe even ahardware wallet.
Going back to the API keys sothe goal of the API keys is to
restrict access to an account.
For example, as an accountholder, want to say, I want to
(10:28):
give this API key access to myBitcoin funds for trading, but
not for withdrawing Bitcoin oronly withdrawing to a specific
address.
Chris (10:38):
So instead of a user using their normal private key
to log in and interact with Nashinstead, they would have their
seed phrase and their privatekey kept securely, like you do
with your seed phrase from ahardware 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, ifyou like, in order to generate
the API key, and then you canput it away you can either put
it into a hardware wallet or putit into a paper wallet, even if
you like, and just act upon thisAPI key.
A bit from a high levelperspective, a bit simplified,
(11:19):
basically Nash helps the holderof the secret key to restrict
the access to his funds withoutNash controlling the user's
funds.
This can be achieved with theuser basically splitting the
secret key into two secretshares and each of the share
gives the holder of the share,no information about secret key,
(11:39):
but if the holder of the sharescooperate, then they can
generate signatures as if theyknew the secret key.
The way we do this is basicallyone share, goes to the API key
and the other share goes toNash.
And together with the share thatgoes to Nash, there's also a
policy involved.
(12:00):
The policy basically describeshow we can basically, as a
restriction, let's say, forexample, a withdrawal
restriction on this or this keymay only withdraw Bitcoin to a
certain address, let's say so wehave an API key how a user can
use it is basically the userwill generate something that we
(12:23):
call a pre signature and thensends the pre signature over to
Nash and if that request matchesthe signing policy then Nash
will complete the signature.
And if the request doesn't matchthe signing policy, for example
the withdrawal request will beto a wrong address, or I've read
an address that is not part ofthe signing policy then Nash
(12:45):
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 docertain things, but we don't
have the power to move theirfunds around because we remain
non-custodial.
Ethan (13:01):
So that actually Chris relates to something you brought
up earlier, the idea ofhomomorphic encryption.
I think actually this as a highlevel concept can give some
flavor really for what thesystem is doing.
Homomorphic encryption isbasically giving people the
ability to do computations, maketransformations like on
encrypted data without knowingwhat the data inside is.
(13:24):
So a very simple example wouldhave an encrypted number.
And then I want to add it withanother encrypted number but I
want to do that without everknowing what those numbers that
I'm adding are.
That's a simple example ofhomomorphic encryption.
And so fundamentally what we'redoing with something like a
threshold signature scheme isusing those ideas to split the
(13:46):
creation of a scheme into twoparts where the computation can
be accomplished throughhomomorphy without the person
who's doing the computationknowing the value inside.
So that just gives you a littlebit of high level of how does
this work?
Like, How are we able togenerate a signature without
knowing the private key?
Uh it's because that, thatprivate key has been split into
(14:08):
parts and we can use this spacestability to do math inside
encrypted data to create thatsignature.
Chris (14:15):
And this is important because it let's Nash enforce
policies like a centralizedexchange might be able to
enforce.
However, the centralizedexchange has custody of the user
funds.
Ethan (14:28):
That's right.
So we can, we can behave in waysthat are similar and in some
sense, like good for a certaindefinition of good on the
centralized exchange, withoutthe downside of actually holding
the user funds, we can preventsomeone who logs in from like
withdrawing the total fundbalance, for example, without
controlling the funds.
Chris (14:45):
So in a way it's even more powerful than what
centralized exchanges can offerwhen they themselves have
absolute control of the funds.
Ethan (14:54):
Yup.
That's right.
And it's also a perfect exampleof kind of taking building
blocks that exist, right?
Threshold signatures haveexisted for a very long time,
and applying them in a novel waythat 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 Robertwhere threshold signatures are
used?
Robert (15:23):
Well, there's a famous historic example I think of the
first well it's, not a thresholdsignature, but it's a multiparty
computation I.think in the latetwo thousands where it was used
in the Netherlands in, in someauction so maybe this could be
an example for like where it waspractically used.
Threshold signatures.
I mean, currently I think it ismostly.
(15:45):
It's advertised at least in highstake customers in order to
protect their secret keys withadditional security let's say,
but I'm not sure how much it'sactually used in practice.
Ethan (15:57):
Yeah.
I mean, homomorphic encryption,there, there's a lot of
interesting research going onthere about how that can be
used.
So like some other exampleswould be people who want to do
like computation or modeltraining on private medical
data.
Right.
So they'll be like, can youtrain models without revealing
information there.
Secure voting would be anotherexample.
Can you sort of use those ideasto like add up and in a provable
(16:20):
way, like verify, some number ofthings that have happened
without actually knowing whatany individual did?
So there's lots of examples forhomomorphic encryption, but
threshold signatures are I thinkmore kind of specific to
blockchain because of the sortof connection to public private
key signatures and, and thesecurity of funds is so
important.
Right.
I'm not sure of any other usethat they have, but they're
(16:42):
there very well could be one.
Robert (16:44):
Theoretically, it could be used anywhere where you want
to protect one secret key andyou 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 algorithmictraders.
So an institution can createdifferent accounts for different
trading teams or whatever, whoeach have their own bot without
giving them access to the entireinstitution's funds.
And in future, we plan to extendthis to user wallets in the way
(17:15):
we described earlier so thatusers interact through the API
rather than with their privatekey.
What other potential does thistechnology have for blockchain?
I mean, it's not just aboutprotecting traders could it be
used in conjunction with statechannels more broadly?
Ethan (17:32):
Yeah.
Robert can say more about this,but you see a lot of people
taking, the, the idea ofthreshold signatures or various
threshold signature schemes andapplying it to make.
More efficient, other existingkind of multisig style
interactions on blockchain.
So, so it really is like just atool that you can use for any of
those things.
I would also just step back andpoint out that you can use it
(17:54):
for very different kinds ofthings in algorithmic trading so
for example, if you want to haveshared custody of an account
with, you know, friends orfamily, or you want to have
various policies that one personwants to enforce, or if you want
to do key recovery systems inspecific ways that you share
among friends, with a certainnumber of agreement, you can
recover key, these are allthings where you could use
(18:15):
similar ideas.
Robert (18:16):
Maybe I should add here.
Technically, this is allpossible, but the main challenge
comes from how to implement thisefficiently.
So I would say this is the mainchallenge.
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 certainlyexist for quite some time.
Don't quote me on the, on thenumbers, but let's say 20 years
or even longer maybe, but justrecently they became
sufficiently efficient.
Let's put it this way so that wecould use it with some
additional optimizations so thatwe can actually use it on a day
(18:51):
to day basis, even for thisexchange scenario.
Let's say.
I mean, if you look at therequirements of traders than
they certainly require lowlatency, so this is kind of a
strong requirement while beforeyou could, you could do
threshold signatures until acouple of years ago it took
minutes to generate a signatureeven hours to generate keys.
(19:11):
So this is certainlyunacceptable for traders.
Chris (19:15):
What's changed over the last few years?
Is it that's processing power isimproved or people have just
come up with better algorithmsfor implementing these?
Robert (19:24):
Well, processing power certainly has not improved.
I mean, we haven't seen anyimprovement in the basically
last 15 years when it comes toprocessing power when we talk
about CPUs, so it's, it'sdefinitely 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 ananalysis of a number of
techniques, basically forperformance and implementation,
sort of simplicity, basicallylower surface area, the better
lower rounds of communication,the better, faster protocol, the
better and you know, there wasquite a bit of variance and even
(19:58):
the recent work and we used avery recent protocol.
So I think it's safe to saythey've improved considerably.
Chris (20:04):
How much do you can Robert actually build?
Is it that you come up with theprotocol and it's passed to
other developers or are youactually building these tools
yourselves?
Ethan (20:13):
I mean, historically with Nash, I have done much more sort
of protocol development andarchitecture development than
actual coding myself personally.
That said I am working on a fewprojects where I'm doing pretty
extensive coding at the momentand 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'reresearching a new topic, then
it's, then you certainly don'tspend a lot of time implementing
stuff.
But when it comes toimplementing prototypes,
benchmarking stuff, in the caseof the MPC based API keys also
(20:53):
to an implementation andcertainly 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, thereis Elixir and front-end wise,
there is, TypeScript and Pythonclient but basically the core is
written in RUST and then webasically provide foreign
(21:26):
functioning interfaces to otherlanguages.
That's a Elixir on the one endand 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 particularlyuseful for this application?
Robert (21:42):
Sure.
So it's a strictly typedlanguage, so that's, ah, let's
put it this way.
For prototyping in Python, youcan basically go on and do, a
lot within a very short time andI don't feel the same way about
RUST.
It basically takes more time inorder to create something, but
on the positive side, first ofall, you have this, this, this
(22:03):
memory safety, so that that'snice.
And on the other hand you havethe 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 endproduct is more robust, less
likely to have issues.
I think that's definitely true.
In general, I'm a bit of aprogramming language geek.
I play with tons of languages.
I try to experiment with as manyof them as I can.
And, RUST is really unique inthat it really straddles this
(22:28):
space of languages with verynice expressive type systems,
but also languages in which, youcan operate at a low level and
sort of basically write reallyany kind of program you want.
This is, this is pretty rare, tohave a language with, with a
type system that is, is soexpressive and that yet still
(22:50):
allows you to produce this superperformant bytecode also, just
to kind of call out to Robert'scode.
So he, you know, he implementedthe threshold signature MPC
stuff and basically we've seenno 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 bugfree code pushed to production.
(23:11):
And I think one big reason forthat is, the RUST type system
and basically the things that'sable to protect you against at
compile time.
One other thing is a Robert saidtakes a little longer to develop
with this.
that's true.
But type systems, if you'redeveloping sufficiently complex
applications, having a strongand expressive type system can
actually start speeding thingsup after you get to a certain
(23:32):
point, right?
If you have a really complex,system and you want to make a
change, if you're in a languagethat doesn't enforce types or
doesn't allow you to expresscomplex types you're going to
have to really just kind ofsearch over all of the code and
find the places where, you know,your change touched and manually
adjust them and hope you got itright and run lots of tests and
(23:53):
do lots of testing.
Whereas if you have anexpressive enough language with
a good enough type system, itcan help you figure out and
debug all those issues atcompile time.
So when you have these likereally complex systems and then
you make a change the compilercan kind of work with you as a
partner to go and sort of fixall those issues that you
encountered.
So the time trade off doesactually kind of get a little
(24:14):
bit better over time, dependingon 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 mightoverlook 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 cryptocurrencywallet recently that generated
user keys.
Ethan (24:39):
Oh yeah.
I know which one you're talkingabout.
Chris (24:41):
It used like a random number generator, but because
they used a particular type thatit was set up so that the entire
key space only had eight bytesor something like this.
So because of the nature of therandom number generator they
used and they didn't know thatit 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 okaywith whatever the default
integer representation in mylanguage is then that that's not
going to be good for you becauseyou're not thinking about and
making explicit the decisionsyou're making.
A language like RUST willactually force you to choose if
you're using integers like 32bit 64, whatever but really to
(25:22):
do this properly withcryptography, you should use
dedicated big integer, big floatrepresentations for the
computations you're doing.
And so, you know, that'ssomething that you can enforce
at compile time, assuming you'reusing those kinds of
representations.
Chris (25:35):
Well, let's talk now about what you're working on at
the moment and maybe the futureproject.
So what's each of you lookinginto at the moment?
Robert (25:43):
What I'm currently looking into is how we could
implement options and futurestrading.
And we touched this a bitbefore, so there's again, a
challenge to implement this in anon-custodial fashion.
So there's certainly.
kind of a technologicalchallenge there.
So this is what I'm currentlyworking on, basically.
Ethan (26:05):
So that's super important.
This is something I mentioned inthe last company report.
So one big initiative we have isbasically figuring out how we
can enable any form of leveragedtrading on the exchange
remaining non-custodial, butsafely enabling leverage.
That's a big focus area for theresearch team.
Chris (26:23):
This would involve some sort of DeFi like products where
users can lend funds that arethen used as collateral.
Ethan (26:30):
Potentially.
Yeah.
I mean, if you could do it a lotof different ways, you don't
necessarily have to use lendingto do it, but that's definitely
a possibility.
I think the trickiest parts ofthis are when it gets into
Bitcoin.
How you can enable leveragedtrading on Bitcoin in a safe way
that becomes very challenging.
I think we do have some goodoptions for like Ethereum based
(26:50):
products there for leverage,like, so that that's definitely
possible.
The Bitcoin thing is a biggerquestion mark.
That's definitely in theresearch side of research.
Just to follow up on otherthings we're working on.
I've also been spending a fairamount of time recently looking
into algorithmic trading andsort of how we can generate
trading algorithms that helpimprove the exchange liquidity
(27:11):
and volume.
I think that will be reallyimportant as we start ramping up
as well.
So this is another big searchproblem where we're building a
lot of infrastructure to help uskind 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 otherexchanges, take advantage of
other liquidity that exists ifpossible, you know, in some
sense, this is like the simplestform of dogfooding your own
product, right?
So we have an exchange product.
Can the exchange use it's ownproduct effectively?
(27:49):
And of course all of this wouldbe like real trading this isn't
isn't wash trading, this isn'tany sort of fake stuff.
This is actually using theproduct to generate profit.
So algorithmic trading is reallyinteresting.
Chris (28:01):
So would you say some of these topics aren't so much
focused on fundamentalcryptography, like the API keys,
they're more generally to dowith the possibilities of
blockchain infrastructure?
Ethan (28:12):
I think non-custodial leverage is going to draw on
cryptography probably to atleast the same extent that the
API key stuff did.
Ideally it would be anotherbuilding blocks scenario where
we can take some really good,powerful ideas and combine them
in the right way to make thispossible 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 fortoday.
Thank you to Ethan and Robertfor 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 favoritelistening stream and you won't
miss an episode.
You can also find the full textof this episode on
podcast.nash.io.
Welcome to Beyond the Chain, the podcast from Nash
that takes a deep look intoblockchain technology and
connects the dots betweendecentralized finance, business
and the wider world.
I'm your host, Chris Fenwick.
And I work at Nash as a writer.
The Nash team contains expertson various areas of blockchain
and decentralized financetechnology.
And each episode I'm joined by aNash founder and a special guest
(00:22):
here with me is Nash co-founderEthan fast.
Ethan (00:25):
Hey, Chris.
Yeah, it's great to be here.
Glad Nash is doing this.
Chris (00:28):
And we're also here with our applied cryptographer Robert
Annessi who together with Ethanmakes up the Applied Research
team.
Hi Robert.
Ethan's no stranger to followersof Nash, but I'll still allow
him to introduce himself here.
Ethan (00:43):
Yeah, sure, prior to Nash, I was doing a PhD at
Stanford in computer science.
I broadly studied, areas ofhuman computer interaction,
which is super important for alot of things that Nash is
doing, and sort of applicationsthere and machine learning as
well.
In 2017, I actually startedgetting into blockchain and
cryptography in a deeper way,co-founded the group called COZ,
(01:05):
with a number of other Nashco-founders before we started
Nash, we were all doing that.
One of our projects there that Ifounded called Neon Wallet,
started to take off.
I was working pretty well withthe other co-founders and that's
actually kind of how we decidedto start Nash.
So that's, that's where thatcame from.
So with Nash itself I wasinvolved in forming some of our
(01:26):
very first designs for how theexchange, how our technology
operates as well as involved inengineering over the several
years this company has beenrunning.
And, now I've sort of shifted tofocus more completely on kind of
the future of the technologiesthat we want to be interacting
with and developing.
This is kind of the broad scopeof this Applied Research team,
(01:48):
which we can say more about in abit but generally the idea with
sort of really any sort ofresearch team is to think about
the technologies that we mightneed or want in the future, how
might we create thosetechnologies, benefit from those
technologies?
Really it's, it's a much morekind of high risk reward
profile, right?
So you want to be investigatinga lot of things.
(02:09):
Some of those things will workout and maybe work out
phenomenally other things, maybenot, but you sort of iterate
over test hypotheses, try tofuture proof really, where the
company is going.
Chris (02:19):
Cool.
And in this Applied Researchteam, you work together with
Robert who joined the companylast year.
So Robert, why don't you let usknow a bit about your
background?
Robert (02:29):
So my educational background is computer
engineering, but, I have, andhave had a strong interest in
security and also did my PhD inthe field of network security.
A few years ago I basically gothooked by the blockchain space,
mostly because of the hugedisruptive potential it has.
And roughly one year ago was, asChris said, I joined Nash mostly
(02:51):
to make an impact.
So that's the personal reason tojoin.
And I'm looking forward to dothat.
Chris (02:58):
Ethan already spoke about the idea of Applied Research,
but why don't you continue a bitmore and talk about the work
that the Applied Research teamis doing?
How would you characterize thatwork?
Robert (03:09):
I would say it's mostly about improving and extending
the Nash products, which sincethere's a lot of research
involved, there's also a fairchance of failing, which to be
fair, I like a lot.
Ethan (03:24):
Yeah.
That's sort of, one definitionof research is, if you know,
what's going to work, it's notresearch.
So I would say a lot of thingsthat we're working on now are
research more in the sense ofhow would I put it?
Like we're not developingfundamentally new forms of
cryptography, but we are lookingat sort of the space of
(03:45):
available technologies andseeing how those pieces can be
put together to enable systemsthat have never existed before
and you know, sometimes thoseideas will work.
Sometimes those ideas will notwork.
I think the element of risk iskey to the idea.
Chris (04:00):
So it's more about looking at sort of state of the
art research that's maybe comingfrom a university setting and
thinking about how you can applythat to Nash's business, rather
than doing kind of fundamentalnew mathematical research.
Ethan (04:16):
Sure.
Although I would actually say,you know, putting technologies
together in a new way isresearch in a sense, right?
So again, my background, reallyfrom a research standpoint is in
human computer interaction andin human computer interaction,
you're studying what new kindsof experiences can technology
enable for people?
Do these experiences work toaccomplish some goal?
(04:38):
Do they make sense?
Can we invent fundamentally newforms of user interaction with
technology?
Sometimes you're building thecore technologies that enable
those things, but sometimesyou're not.
So for example, if you look athow deep learning or machine
learning has changed the waypeople interact with, you know,
tons of technologies, often theresearch that goes into
(05:00):
developing those newinteractions isn't at the level
of like core machine learning,for example.
And that's very similar to whatwe do with blockchain
technologies.
So to take one really simpleexample, our system for storing
the user private keys, suchthat, only the user has access
to the private key, but they canlog in with a username and a
(05:22):
password to get into theiraccount.
This is a form of interaction,right?
Where we didn't invent anyparticular form of cryptography
or any particular kind ofsecurity idea.
But what we did do is we tookthe available kind of building
blocks and put them together ina way that really, before we did
that didn't exist commonly.
(05:43):
Right.
So, you're taking some pieces,and putting them together in a
form that has never existed andthen you see, okay you know what
can we do with that, that, thatwasn't possible.
So I still think it's research.
It's just a different kind ofresearch.
Chris (05:58):
So I suppose in a sense, like the publication of that
research would actually be theopen source code we published on
Gitlab recently.
Ethan (06:05):
I mean, you could actually publish it, right?
So this hasn't been a priorityfor Nash.
I mean, this is maybe aninteresting, broader
conversation, like, you know,when do you publish and why do
you publish when you're inindustry?
But you could have taken some ofthe ideas we put into our
noncustodial wallet set up andpublish them in some human
(06:26):
computer interaction venue, forsure, no question about it.
Usable security ideas like that,those things are very important
people publish work on how canwe enable new, more usable forms
of security that, you know,provide more security, but that
people actually use.
These are real things thatpeople do publish about.
We are not speaking as Nashnecessarily to that research
(06:47):
community directly.
Right?
We care more about our users.
And so we didn't take the timeto go and publish a KY
publication on the securityimprovements of our wallet for
user, because that just wasn't apriority, but we could actually
publish them.
Chris (07:02):
So that you're saying there's actually like some
significant continuity betweenthe work you do and say,
research in a university settingas well.
Ethan (07:11):
Yeah.
Chris (07:12):
What are the main topics that you've been working on so
far?
Ethan (07:16):
Well, I'll let Robert say something in a bit, but just to
review, I guess, you know, someof the things I've contributed
to really everything at theprotocol and architecture level
from the beginning This is all avery collaborative process so no
one person is responsible forany of those things.
Basically what's concerned mefrom the beginning is figuring
out, you know, how can Nashdesign a system that
(07:37):
accomplishes all of the goalsthat we set out to achieve.
These core goals of anon-custodial trading system, a
noncustodial fund managementsystem, and very importantly, a
good user experience.
How can you combine all thosethings together?
Then there's a lot oftechnologies that go into doing
that.
Everything from what kind ofmatching engine do we have on
the backend, how is itinteracting with the blockchains
(08:00):
to what kind of client, do wehave on the front end?
What kind of cryptography is itusing to make sure that the user
is the only one that owns theirprivate key?
So really that sort of fulldesign space is something that
all of the co-founders can beproud of having contributed to,
but I definitely spent a longtime thinking about and
iterating on.
(08:20):
So Robert can say more about ourrecent work.
Robert (08:25):
Sure.
Right.
Until recently I've mainlyworked on the threshold
signatures and securemulti-party computation, which
ultimately resulted in thenoncustodial API keys.
Which now Nash is able toprovide, so this is what I've
worked on until recently.
Chris (08:42):
Take us through that a bit, explain some more of the
fundamental ideas behind thecryptography involved?
Maybe explain things like what ahomomorphic encryption scheme
is, this sort of thing.
I'm sure this will beinteresting for our listeners
Robert (08:57):
Maybe before going into the API keys directly, we can
explain this non-custodialproperty that Nash Exchange
provides.
This also explains why it makesthe security a bit more
challenging.
So, if you think about it, thecustodial centralized exchange
basically acts like a bank.
So as a user I move my fundsinto the exchange and basically
(09:21):
trust the exchange to give meback my funds when I ask for it.
So, this makes moving the fundsbetween 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'sfunds is tied to the security of
the exchange.
And this may be acceptable for abank let's say, because we have
(09:44):
legal system that protects theuser's funds to a certain
extent, but there is no suchprotection in the cryptocurrency
space.
And there's many people who gotvictims of that and who can,
tell stories about their, theirfunds getting lost because of an
exchange hack so with anon-custodial exchange, like
Nash, the exchange doesn't havethe custody of the user's funds.
(10:06):
So now the security of the fundsdoesn't depend on the security
of the exchange, but on thesecurity of the user's device,
this, this could be like, amobile phone or a desktop
device, or, maybe even ahardware wallet.
Going back to the API keys sothe goal of the API keys is to
restrict access to an account.
For example, as an accountholder, want to say, I want to
(10:28):
give this API key access to myBitcoin funds for trading, but
not for withdrawing Bitcoin oronly withdrawing to a specific
address.
Chris (10:38):
So instead of a user using their normal private key
to log in and interact with Nashinstead, they would have their
seed phrase and their privatekey kept securely, like you do
with your seed phrase from ahardware 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, ifyou like, in order to generate
the API key, and then you canput it away you can either put
it into a hardware wallet or putit into a paper wallet, even if
you like, and just act upon thisAPI key.
A bit from a high levelperspective, a bit simplified,
(11:19):
basically Nash helps the holderof the secret key to restrict
the access to his funds withoutNash controlling the user's
funds.
This can be achieved with theuser basically splitting the
secret key into two secretshares and each of the share
gives the holder of the share,no information about secret key,
(11:39):
but if the holder of the sharescooperate, then they can
generate signatures as if theyknew the secret key.
The way we do this is basicallyone share, goes to the API key
and the other share goes toNash.
And together with the share thatgoes to Nash, there's also a
policy involved.
(12:00):
The policy basically describeshow we can basically, as a
restriction, let's say, forexample, a withdrawal
restriction on this or this keymay only withdraw Bitcoin to a
certain address, let's say so wehave an API key how a user can
use it is basically the userwill generate something that we
(12:23):
call a pre signature and thensends the pre signature over to
Nash and if that request matchesthe signing policy then Nash
will complete the signature.
And if the request doesn't matchthe signing policy, for example
the withdrawal request will beto a wrong address, or I've read
an address that is not part ofthe signing policy then Nash
(12:45):
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 docertain things, but we don't
have the power to move theirfunds around because we remain
non-custodial.
Ethan (13:01):
So that actually Chris relates to something you brought
up earlier, the idea ofhomomorphic encryption.
I think actually this as a highlevel concept can give some
flavor really for what thesystem is doing.
Homomorphic encryption isbasically giving people the
ability to do computations, maketransformations like on
encrypted data without knowingwhat the data inside is.
(13:24):
So a very simple example wouldhave an encrypted number.
And then I want to add it withanother encrypted number but I
want to do that without everknowing what those numbers that
I'm adding are.
That's a simple example ofhomomorphic encryption.
And so fundamentally what we'redoing with something like a
threshold signature scheme isusing those ideas to split the
(13:46):
creation of a scheme into twoparts where the computation can
be accomplished throughhomomorphy without the person
who's doing the computationknowing the value inside.
So that just gives you a littlebit of high level of how does
this work?
Like, How are we able togenerate a signature without
knowing the private key?
Uh it's because that, thatprivate key has been split into
(14:08):
parts and we can use this spacestability to do math inside
encrypted data to create thatsignature.
Chris (14:15):
And this is important because it let's Nash enforce
policies like a centralizedexchange might be able to
enforce.
However, the centralizedexchange has custody of the user
funds.
Ethan (14:28):
That's right.
So we can, we can behave in waysthat are similar and in some
sense, like good for a certaindefinition of good on the
centralized exchange, withoutthe downside of actually holding
the user funds, we can preventsomeone who logs in from like
withdrawing the total fundbalance, for example, without
controlling the funds.
Chris (14:45):
So in a way it's even more powerful than what
centralized exchanges can offerwhen they themselves have
absolute control of the funds.
Ethan (14:54):
Yup.
That's right.
And it's also a perfect exampleof kind of taking building
blocks that exist, right?
Threshold signatures haveexisted for a very long time,
and applying them in a novel waythat 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 Robertwhere threshold signatures are
used?
Robert (15:23):
Well, there's a famous historic example I think of the
first well it's, not a thresholdsignature, but it's a multiparty
computation I.think in the latetwo thousands where it was used
in the Netherlands in, in someauction so maybe this could be
an example for like where it waspractically used.
Threshold signatures.
I mean, currently I think it ismostly.
(15:45):
It's advertised at least in highstake customers in order to
protect their secret keys withadditional security let's say,
but I'm not sure how much it'sactually used in practice.
Ethan (15:57):
Yeah.
I mean, homomorphic encryption,there, there's a lot of
interesting research going onthere about how that can be
used.
So like some other exampleswould be people who want to do
like computation or modeltraining on private medical
data.
Right.
So they'll be like, can youtrain models without revealing
information there.
Secure voting would be anotherexample.
Can you sort of use those ideasto like add up and in a provable
(16:20):
way, like verify, some number ofthings that have happened
without actually knowing whatany individual did?
So there's lots of examples forhomomorphic encryption, but
threshold signatures are I thinkmore kind of specific to
blockchain because of the sortof connection to public private
key signatures and, and thesecurity of funds is so
important.
Right.
I'm not sure of any other usethat they have, but they're
(16:42):
there very well could be one.
Robert (16:44):
Theoretically, it could be used anywhere where you want
to protect one secret key andyou 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 algorithmictraders.
So an institution can createdifferent accounts for different
trading teams or whatever, whoeach have their own bot without
giving them access to the entireinstitution's funds.
And in future, we plan to extendthis to user wallets in the way
(17:15):
we described earlier so thatusers interact through the API
rather than with their privatekey.
What other potential does thistechnology have for blockchain?
I mean, it's not just aboutprotecting traders could it be
used in conjunction with statechannels more broadly?
Ethan (17:32):
Yeah.
Robert can say more about this,but you see a lot of people
taking, the, the idea ofthreshold signatures or various
threshold signature schemes andapplying it to make.
More efficient, other existingkind of multisig style
interactions on blockchain.
So, so it really is like just atool that you can use for any of
those things.
I would also just step back andpoint out that you can use it
(17:54):
for very different kinds ofthings in algorithmic trading so
for example, if you want to haveshared custody of an account
with, you know, friends orfamily, or you want to have
various policies that one personwants to enforce, or if you want
to do key recovery systems inspecific ways that you share
among friends, with a certainnumber of agreement, you can
recover key, these are allthings where you could use
(18:15):
similar ideas.
Robert (18:16):
Maybe I should add here.
Technically, this is allpossible, but the main challenge
comes from how to implement thisefficiently.
So I would say this is the mainchallenge.
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 certainlyexist for quite some time.
Don't quote me on the, on thenumbers, but let's say 20 years
or even longer maybe, but justrecently they became
sufficiently efficient.
Let's put it this way so that wecould use it with some
additional optimizations so thatwe can actually use it on a day
(18:51):
to day basis, even for thisexchange scenario.
Let's say.
I mean, if you look at therequirements of traders than
they certainly require lowlatency, so this is kind of a
strong requirement while beforeyou could, you could do
threshold signatures until acouple of years ago it took
minutes to generate a signatureeven hours to generate keys.
(19:11):
So this is certainlyunacceptable for traders.
Chris (19:15):
What's changed over the last few years?
Is it that's processing power isimproved or people have just
come up with better algorithmsfor implementing these?
Robert (19:24):
Well, processing power certainly has not improved.
I mean, we haven't seen anyimprovement in the basically
last 15 years when it comes toprocessing power when we talk
about CPUs, so it's, it'sdefinitely 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 ananalysis of a number of
techniques, basically forperformance and implementation,
sort of simplicity, basicallylower surface area, the better
lower rounds of communication,the better, faster protocol, the
better and you know, there wasquite a bit of variance and even
(19:58):
the recent work and we used avery recent protocol.
So I think it's safe to saythey've improved considerably.
Chris (20:04):
How much do you can Robert actually build?
Is it that you come up with theprotocol and it's passed to
other developers or are youactually building these tools
yourselves?
Ethan (20:13):
I mean, historically with Nash, I have done much more sort
of protocol development andarchitecture development than
actual coding myself personally.
That said I am working on a fewprojects where I'm doing pretty
extensive coding at the momentand 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'reresearching a new topic, then
it's, then you certainly don'tspend a lot of time implementing
stuff.
But when it comes toimplementing prototypes,
benchmarking stuff, in the caseof the MPC based API keys also
(20:53):
to an implementation andcertainly 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, thereis Elixir and front-end wise,
there is, TypeScript and Pythonclient but basically the core is
written in RUST and then webasically provide foreign
(21:26):
functioning interfaces to otherlanguages.
That's a Elixir on the one endand 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 particularlyuseful for this application?
Robert (21:42):
Sure.
So it's a strictly typedlanguage, so that's, ah, let's
put it this way.
For prototyping in Python, youcan basically go on and do, a
lot within a very short time andI don't feel the same way about
RUST.
It basically takes more time inorder to create something, but
on the positive side, first ofall, you have this, this, this
(22:03):
memory safety, so that that'snice.
And on the other hand you havethe 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 endproduct is more robust, less
likely to have issues.
I think that's definitely true.
In general, I'm a bit of aprogramming language geek.
I play with tons of languages.
I try to experiment with as manyof them as I can.
And, RUST is really unique inthat it really straddles this
(22:28):
space of languages with verynice expressive type systems,
but also languages in which, youcan operate at a low level and
sort of basically write reallyany kind of program you want.
This is, this is pretty rare, tohave a language with, with a
type system that is, is soexpressive and that yet still
(22:50):
allows you to produce this superperformant bytecode also, just
to kind of call out to Robert'scode.
So he, you know, he implementedthe threshold signature MPC
stuff and basically we've seenno 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 bugfree code pushed to production.
(23:11):
And I think one big reason forthat is, the RUST type system
and basically the things that'sable to protect you against at
compile time.
One other thing is a Robert saidtakes a little longer to develop
with this.
that's true.
But type systems, if you'redeveloping sufficiently complex
applications, having a strongand expressive type system can
actually start speeding thingsup after you get to a certain
(23:32):
point, right?
If you have a really complex,system and you want to make a
change, if you're in a languagethat doesn't enforce types or
doesn't allow you to expresscomplex types you're going to
have to really just kind ofsearch over all of the code and
find the places where, you know,your change touched and manually
adjust them and hope you got itright and run lots of tests and
(23:53):
do lots of testing.
Whereas if you have anexpressive enough language with
a good enough type system, itcan help you figure out and
debug all those issues atcompile time.
So when you have these likereally complex systems and then
you make a change the compilercan kind of work with you as a
partner to go and sort of fixall those issues that you
encountered.
So the time trade off doesactually kind of get a little
(24:14):
bit better over time, dependingon 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 mightoverlook 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 cryptocurrencywallet recently that generated
user keys.
Ethan (24:39):
Oh yeah.
I know which one you're talkingabout.
Chris (24:41):
It used like a random number generator, but because
they used a particular type thatit was set up so that the entire
key space only had eight bytesor something like this.
So because of the nature of therandom number generator they
used and they didn't know thatit 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 okaywith whatever the default
integer representation in mylanguage is then that that's not
going to be good for you becauseyou're not thinking about and
making explicit the decisionsyou're making.
A language like RUST willactually force you to choose if
you're using integers like 32bit 64, whatever but really to
(25:22):
do this properly withcryptography, you should use
dedicated big integer, big floatrepresentations for the
computations you're doing.
And so, you know, that'ssomething that you can enforce
at compile time, assuming you'reusing those kinds of
representations.
Chris (25:35):
Well, let's talk now about what you're working on at
the moment and maybe the futureproject.
So what's each of you lookinginto at the moment?
Robert (25:43):
What I'm currently looking into is how we could
implement options and futurestrading.
And we touched this a bitbefore, so there's again, a
challenge to implement this in anon-custodial fashion.
So there's certainly.
kind of a technologicalchallenge there.
So this is what I'm currentlyworking on, basically.
Ethan (26:05):
So that's super important.
This is something I mentioned inthe last company report.
So one big initiative we have isbasically figuring out how we
can enable any form of leveragedtrading on the exchange
remaining non-custodial, butsafely enabling leverage.
That's a big focus area for theresearch team.
Chris (26:23):
This would involve some sort of DeFi like products where
users can lend funds that arethen used as collateral.
Ethan (26:30):
Potentially.
Yeah.
I mean, if you could do it a lotof different ways, you don't
necessarily have to use lendingto do it, but that's definitely
a possibility.
I think the trickiest parts ofthis are when it gets into
Bitcoin.
How you can enable leveragedtrading on Bitcoin in a safe way
that becomes very challenging.
I think we do have some goodoptions for like Ethereum based
(26:50):
products there for leverage,like, so that that's definitely
possible.
The Bitcoin thing is a biggerquestion mark.
That's definitely in theresearch side of research.
Just to follow up on otherthings we're working on.
I've also been spending a fairamount of time recently looking
into algorithmic trading andsort of how we can generate
trading algorithms that helpimprove the exchange liquidity
(27:11):
and volume.
I think that will be reallyimportant as we start ramping up
as well.
So this is another big searchproblem where we're building a
lot of infrastructure to help uskind 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 otherexchanges, take advantage of
other liquidity that exists ifpossible, you know, in some
sense, this is like the simplestform of dogfooding your own
product, right?
So we have an exchange product.
Can the exchange use it's ownproduct effectively?
(27:49):
And of course all of this wouldbe like real trading this isn't
isn't wash trading, this isn'tany sort of fake stuff.
This is actually using theproduct to generate profit.
So algorithmic trading is reallyinteresting.
Chris (28:01):
So would you say some of these topics aren't so much
focused on fundamentalcryptography, like the API keys,
they're more generally to dowith the possibilities of
blockchain infrastructure?
Ethan (28:12):
I think non-custodial leverage is going to draw on
cryptography probably to atleast the same extent that the
API key stuff did.
Ideally it would be anotherbuilding blocks scenario where
we can take some really good,powerful ideas and combine them
in the right way to make thispossible 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 fortoday.
Thank you to Ethan and Robertfor 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 favoritelistening stream and you won't
miss an episode.
You can also find the full textof this episode on
podcast.nash.io.
Popular Podcasts
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
24/7 News: The Latest
The latest news in 4 minutes updated every hour, every day.
Therapy Gecko
An unlicensed lizard psychologist travels the universe talking to strangers about absolutely nothing. TO CALL THE GECKO: follow me on https://www.twitch.tv/lyleforever to get a notification for when I am taking calls. I am usually live Mondays, Wednesdays, and Fridays but lately a lot of other times too. I am a gecko.