Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Dan Robinson: Rainbow Network – Off-Chain Synthetics Exchange or “Multicolored Lightning”

Episode Date: May 28, 2019

We’re joined by Dan Robinson, a research partner at Paradigm, and the author the “Rainbow Network” paper. The paper describes an off-chain decentralized synthetics exchange which leverages payment channels. The Rainbow Network is based on the idea that “rainbows are basically just multicolored lightning,” borrowing from the concepts used in the Lightning Network. The protocol relies on trusted oracles and allows participants to trade any type of liquid asset off-chain. All that is necessary to complete a transaction is an on-chain payment channel collateralized by a single asset. Though it is still at the idea stage and has yet to be implemented, the Rainbow Network could have applications in prediction market and as a new type of decentralized exchange. Topics covered in this episode: Dan’s background as a securities layer turned coder His trajectory from working at Chain, to spending some time at Stellar, to joining Paradigm Fund His involvement in the development of the Plasma Cash and Plasma Debit protocols Thoughts and criticisms of using HTLC’s in Lightning What is the idea behind Rainbow Network and how to understand it in the context of Lightning What are synthetics assets and the ability to trade multiple assets in a single payment channel The ability to have leverage in a Rainbow channel trade Next steps in research and implementation Dan’s contribution to the Ivey “smart contract” language for Bitcoin Episode links: Rainbow Network white paper Ivy Playground for Bitcoin Mirror project Paradigm Dan Robinson on Medium Dan Robinson on Twitter Interchain Conversations Berlin event – use code EPICENTER for discounted tickets Cosmos Hackatom Berlin Sponsors: Cosmos: Join the most interoperable ecosystem of connected blockchains - http://cosmos.network/epicenter Azure: Deploy enterprise-ready consortium blockchain networks that scale in just a few clicks - http://aka.ms/epicenter This episode is hosted by Sebastien Couture & Sunny Aggarwal. Show notes and listening options: epicenter.tv/289

This is Epicenter. Episode 289 with guest Dan Robinson. This episode of Epicenter is brought you by Cosmos. Cosmos is building the internet of blockchains, an ecosystem where thousands of blockchains can interoperate, creating the foundation for a new token economy. If you have an idea for a DAP, visit cosmos.network slash epicenter to learn more and to get in touch with the Cosmos team. And by Microsoft Azure. Do you have an idea for a blockchain app but are worried about the time and cost it will take to develop. The new Azure blockchain dev kit is a free download that brings together

the tools you need to get your first app running in less than 30 minutes. Learn more at aka.m.m.s. Hi, welcome the epicenter. My name is Sebassiigwood Ju. And my name is Sunny Agarwell. Today on the show, we interview Dan Robinson, who is currently a research partner at Paradigm. And, but, you know, he's had quite an interesting journey throughout the entire blockchain space. He spent time at chain and was there when it kind of got like acquired by Stellar and so worked on that. And then he left to work on Joint Paradigm, which is hedge fund. Dan has a lot of really interesting experiences throughout the blockchain space. And, you know, he'll mention himself, but, you know, I think what he's really good at is taking ideas from one.

section in the blockchain space and like applying it to another. So, you know, for example, like he was the one who came up with the idea of plasma cash. And I think, you know, he was able to do that because of his like intimate knowledge of, you know, the Bitcoin system, some of the interesting things about how Bitcoin does its UTXOs and was able to apply that to the development work going on at plasma. And so the main process that we actually talk about, today is his rainbow networks proposal. And I think that is like a complete great example of this where he takes a lot of ideas from, you know, plasma and interledger and lightning and kind of like combines them together into this very interesting proposal. Yeah. And it is a bit of an early project at the

moment. It's, it's a white paper and maybe like, I think there's a blog post about it or something or it's mentioned in a blog post. But yeah, reading the white paper, probably a good compliment to the show because it is kind of technical, I guess, and requires a lot of sort of like mental mathematics to understand like the payment channels and how they work. But in the white paper, there are some tables there that would at least help you to get a better understand about like how these payments and how these assets are moving from one party to another in the channels. But yeah, yeah, interesting character. And kind of the link with the previous episode of last week is that Dan actually is the person who got Jill Carlson to work at Chain, which you mentioned in the episode.

Yeah. And like you mentioned, it is a bit of an early project where he mentions in the episode that, you know, he actually has no plans of implementing it himself. But, and so, you know, normally we, at Epicenter, we've been trying to bring on projects or maybe a little bit farther along on their development cycles. But, you know, I think it's actually very interesting to also bring occasionally some of these earlier. projects because something interesting about this rainbow networks thing is that it was actually a little bit of a rediscovery where this was actually what the lightning team was originally working on. So Tadj, uh, DryJay, he actually worked on a project called Mirrors, uh, before, uh, coming up with lightning. And that was I, you know, from, from the brief, you know, like the Mirror's website is all gone and everything now, but, you know, I was digging around

archive.org, the internet archives. And, you know, I'm like, oh, wow, this is actually very similar to the mirror stuff. And so it would be like, you know, a shame if some of these ideas, like, disappeared into the night again. And so, you know, if anyone in this, after listening to this episode and reading the paper is, like, inspired to, you know, take their shot at, like, trying to implement some of this stuff. I'm sure, like, you know, Dan would love to, like, chat with you guys about this and, like, help you out as much as possible. Yeah, absolutely. So, once you tell us. about this Cosmos event coming up in a few weeks? Yeah, sure. So there is in Berlin at the full note

office in Berlin, Cosmos will be having two days of an interchain unconference where we talk about different things going on in the Cosmos community as well as just in the Cosmos development and interchain work. And then we have a two-day hackathon where people can come and hack on anything they want relating to interoperability. And so a lot of the epicenter guests, our hosts are going to be there at both of these events and even moderating some panels and stuff. And so yeah, if you guys are interested in the area in Berlin and want to come hack on some stuff, please definitely come check out the hackathon.

I think this might be even the first time all five of us are in the same place. So we're still waiting on some confirmations, but we might all be there, which would be a historic event. So when is this taking place and how can people learn more? The event is going on. The unconference is going on from the 13th to the 14th of June. And then the Cosmos hack atom is from June 15th to June 16th. And you can learn more by going to hack atom dash Berlin. dot cosmos.network.

Okay, and we'll add links to that in the show notes. Just one more thing I wanted to mention before we do this interview is that I am so happy to be back with my studio gear that has been locked up in a storage bin for the last, or storage locker for the last year and some months. So, yeah, I'm effectively hanging up my nomad shoes and have settled back in. into the Paris area and I'll be here for the foreseeable future. So traveling through Europe, going to do some events here and there. Also, you know, obviously like hanging out in Berlin a little bit.

But yeah, it's really great to have my mic again and my sound card and like my proper lighting and set up and everything. So really excited to be back. And yeah, getting back to working on the podcast and like getting back and sort of like into the Europe blockchain scene more in a more concrete manner. So we forgot to mention how you can actually register for the event that's taking place in Berlin before the Cosmos hackathon that Sonny just mentioned. So effectively there is an event happening in Berlin on June 13th and 14th. It is called Interchain Conversations. And it is a two-day event with keynotes, workshops, panel discussions and sessions on protocol design, cosmos, blockchain interoperability and blockchain intercommunication and all that's fun stuff.

If you want to register, please go to epicenter. com.com. So, that'll take you right to the Eventbrite page where you can register. The cost of registration is $165. But for the first 10 epicenter listeners who register and use the code epicenter, you'll get $65 off. So tickets will be $100. Places are limited. So if you're planning on going, I would suggest that you register sooner than later.

Links will be in the show notes. So come hang out with us at Full Note in Berlin. It would be great to see you. And with that, here is the interview. So we're here today with Dan Robinson, who is a research partner at Paradigm and the author of the Rainbow Network paper. Nice to have you on the show, Dan. Thanks for having me on. Yeah.

So, you know, I think I met you for the first time, I think two or three years ago at one of the IC3 events. And back then, you were working at Chain. but since then you've found yourself working on many different projects throughout the entire space. And so we'll hope to touch on a bunch of them in today's episode. But to start off with, you know, your Twitter bio famously says lawyer comma coder. And so, you know, could you tell us a little bit about that and like how you, you know, how you got into the crypto space and into, you know, coding in general coming in from a very different field? Yeah, sure. So I think it says coder comma lawyer, a coder slash lawyer in that order.

And primarily I don't consider myself a lawyer anymore. I'm retired from the bar. But I did go to law school and I spent a couple years of securities lawyer in New York before I got into working as an engineer full time. And then now as an investor. And, you know, I think it's sort of a common story where I went to law school without really realizing, really thinking. hard about what I wanted to do. And while I was in law school, realized with kind of a sense of growing dread that I preferred programming to working as a lawyer. And that's around the same time I got into Bitcoin. It was following Bitcoin. And then when it came out, Ethereum, yeah, you know, I just sort of knew, even before I started at the law firm, that I think it was probably a relatively

limited time, but I wanted to try it out. How did you start to, you know, get involved with coding, like, you know, just completely self-taught? Yeah, so when I was in, like, middle school, I started just sort of programming as a hobby and didn't do it too much, like, did it work on sort of projects through college. While I was in law school, I took a, I cross-registered and do a couple courses, because then I kind of realized I really liked engineering, so I cross-registered into a couple CS classes. But what I wish I'd done, and there was sort of the, my regret from college, isn't, I don't

really regret necessarily. I mean, you know, I didn't major in CS, which I think I caught up for the answer for the most part. But what I regret most is, there's a lot of kind of academic CS theory that I really do enjoy learning about and suddenly. And it's kind of, I've been lucky to have jobs where I can kind of learn and catch up on that. But if I could go back, I think some of the sort of the really, like the fundamentals of computer science, for example, in programming language theory. Those are areas that I ended up really liking and funny enough end up kind of being relevant in parts of the job. That's really interesting because as someone who is, I mean, I didn't study computer science, but I'm quite technical because I've been coding also since I was in middle

school. I often regret now that I'm in the blockchain space and there are all these like sort legal issues coming up that I would have studied law because I just find so interesting. Yeah, although it means that everybody comes and asks you these questions. and first of all, even real lawyers don't even know the answer to yet about what security securities laws apply to, what money transmitter laws apply to. And lawyers aren't really necessarily any better at thinking about those and thinking through those issues than relatively talented engineers are. They just, A, have more context and B, know when not to give an answer.

So you're less likely to get sort of a stupid answer from a lawyer probably. But ultimately, you know, I think it's the idea that treating it as this kind of kind of like arcane thing. That's how we think of like medicine. Like I have no idea how to, like anyone who hasn't been to medical school could, I wouldn't trust them to sort of open up my heart. But for law, like you can actually, you know,

when it's just like literally arguing on Twitter, I actually think lawyers kind of overrate the extent to which there's this kind of cast that you need to join in order to be able to talk about it with any kind of qualification. So last week on the podcast, we had Jill Carlson. And so she also got her start at chain. And she actually said that you're the one who introduced her to chain.

And that's how she got started there. So I guess how did that case, how did you get started with the chain? Yeah. So I left law very intentionally with no, just sort of took a leap off a cliff without sort of a job in hand or in mind. In part because I wanted to interview for places and have them not think that I wasn't serious about. about leaving my law firm job. So I did do a boot camp called Recurce Center, which is a, it was a really great program.

It's a three-month self-directed coding sort of like retreat in New York City. And you can work on whatever you want. I actually taking that right now. Yeah, yeah. And yeah, I'd recommend it to anybody who already knows how to program but wants to sort of get better at stuff.

And when I joined that, I was like, oh, I'm going to be a web developer or a data engineer or something. I was thinking like, just let me do the most sort of like boring, normal employable engineering skills. But funny enough, they kind of, there I got introduced to all this stuff around programming language theory and functional programming that led into a lot of what I was sort of obsessed with

while I was a chain on Ivy and programming language theory. And all these other sort of projects that I like learned Russ there. And it sort of sent me down these weird rabbit holes that, as well as as cryptocurrency stuff, that end up being funny enough sort of much more employable than just being a normal engineer. at least in my experience. So now you're at Paradigm. Can you give us a high-level overview of paradigm and what your role is there? Yeah.

So I'm in research at Paradigm, which has sort of two meanings. One is kind of the investment meaning of research, like diligence and investment, sourcing investments, following general trends in the space. And the other is kind of contributing to protocol research. So still working on some most. open source projects working on, sort of like elaborating on some ideas like this paper,

which I came out with a couple months ago called the Rainbow Network. So that was something that, you know, I think this was sort of great that the paradigm supported me and working on this kind of thing. And let's be sort of continue this kind of open source research that I've been doing. What is the reason why like a fund would be funding like this pretty practical research into these networks? Is there like a thesis here?

This particular project just came out of my own interest and the fund's interest in decentralized finance and protocols around that. And then also my interest in off-chain scaling. And to some extent, I think it's hard to really get a deep understanding for something unless you try to really like either implement it or innovate on it. And so it was sort of my attempt to like actually really solidify some stuff that I was maybe like guessing about. I'm saying, oh, maybe this could work. And I thought I really have to actually try to design this as a system before I can really get a good understanding of it. So it's part of the firm generally having a prepared mind around newer research. Yeah.

And so, you know, based on your interest in off-change scaling, you know, I was like kind of telling Sebastian earlier, you're like the layer to God. Like, you know, you've worked on like basically every single layer two solution that like a lot of the layer two solutions that, you know, people are working on today. So, you know, just for some context, like, so you actually, before you joined paradigm, you were there during that process when chain was sort of merged with the light year to create the interstellar company. And so there you actually started working on a project called Starlight. could you tell us a little bit about what that project was and what the goal there with that was? Sure. So Starlight was an adaptation of lightning-like payment channels on the Stellar Network. And so that was something, yeah, that had been sort of a, it was originally, the design was originally developed by Jed McCaleb and Jeremy Rubin and a couple others from Stellar. And so I was sort of product managing working on turning that into a full spec.

and implementing and releasing the demo for it. So that's just, it's just payment channels, but done on, on the stellar protocol. I sort of built on top of what was currently there. And that kind of work, trying to figure out how to apply

to sort of like hack together a smart contract system on top of a system that isn't really designed to support it. That was something that I think I'd learned a lot about working on Ivy while I was at chain. and writing Ivy compilers to like every which platform. And so, yeah, that's served me well, I think.

This episode of Epicenter is brought you by Cosmos, the internet of blockchains. Cosmos is live and we couldn't be more excited to see so many projects already building on it. Blockchain technologies are evolving fast, and development shouldn't be one-size-fits-all. As a DAP developer, you need the tools that will allow your DAP to scale, grow, and evolve over time. The Cosmos SDK is a user-friendly. Finally, modular framework which allows you to customize your DAP to best suit your needs. It's powered by tenement core, an advanced implementation of the BFT proof of state protocol. Cosmos takes care of networking and consensus and allows you to focus on building your application

in your language of choice. Ethereum smart contracts will be supported soon, and the SDK makes it simple for you to connect other blockchains in the Cosmos network. If you have an idea for ADAP and would like to learn more about the Cosmos SDK, or if you'd like to connect your existing dot to Cosmos, visitcosmo.network slash Epicenter. For Epicenter listeners, the Cosmos team will reach out to answer your questions and help you get started. We'd like to thank Cosmos for those supportive Epicenter. So moving on to some other work that you've done, tell us about the work you did in plasma cash and plasma debit. Plasma, so I first sort of like learned

about plasma. Well, they released, they release his white paper on it. But I sort of done. dug deep into it around, this is January of 2018. And I was looking specifically at plasma MVP, which was this kind of plasma that it had, it was a relatively interesting and secure way to do side chains, but had these sort of major flaws, one of which was that if you, if someone, the operator of a particular plasma chain can sort of denial of service attack the network by just by not revealing any blocks. And so there's this attack on a mass exit problem where basically everybody has to immediately take an action on the main chain to get out of that.

And the other problem with it is that you have to validate basically the entire block on the side chain so you don't really get it as a scaling solution. And so plasma cash comes out of thinking about, well, how do we parroting? down the feature set that this side chain allows in order to make it, make the burden on the user much lower and make it generally more secure. And it actually takes a lot of ideas, I think, from payment channels. And something that I worked on a little later, Plasma Debit carries that even further in terms of really drawing an analogy between these payment channels and payment channel networks like lightning or inner ledger, and applying it to plasma cache, building up, putting it on top

plasma cache. So what is your current involvement on the plasma project? Are you actively involved with development, or was it sort of you just like kind of proposed it and then kind of let other people carry it, like, you know, take it over after that? Yeah. So my modus operandi usually is not to stick around too long for all that really hard actual work. And that's what Plasma Group, Plasma Group is a fantastic team. And they've been sort of like really carrying forward both the research and the implementation

on Plasma Cash. But I'm still close with them. And I sort of like look at follow their designs and discuss it with them when we meet up at research workshops. But for the most part, they're the ones carrying that forward. Right. Yeah. And so to the listeners, we actually did an episode about maybe a year ago with Carl. flourish about plasma cash actually. So, you know, if you're interested in learning more about

the actual technicals of how plasma cache itself works, which didn't propose. And so, you know, take a look at that and then follow up with the plasma group to see what the latest developments are. And so, you know, I also know you're pretty involved with the Interledger project as well. Yet another secondary network you're involved with. And did this come out during your time? Like, so, you know, you gave a great talk at the Stanford B-PACE conference back in January, where you kind of talked about why HTLCs are harmful and some of the issues you see with the Lightning Network, and then you propose that interledger seems to be the solution to most of those issues. Were these issues you came across during your development of Starlight?

And is that what pushed you toward Interledger? Yeah, so I learned about Interledger. a couple years ago, mostly from Evan Schwartz, one of the inventors of the protocol, along with Stefan Thomas. And they, you know, I originally sort of like, they originally saw it as something

that actually technically looked a lot more like lightning and had these HTLCs sort of enforced in the protocol. And then they kind of had this realization that you can do it another way and that you can do this method that I described in that talk of instead of having these really complicated smart contracts just to enforce animosity across a multi-hop payment, you just send a really tiny amount over and over again. And so you can enforce animosity just sort of like down to

epsilon, down to a particular limit. And it's a very clever solution. That in particular is what I fell in love with Bauer-interledger was that one design. But I think there's a lot of other really clever designs that they've, and traces that they've made. So, yeah, I learned about that from Ripple. Working on Starlight, originally I was planning to implement it like Lightning, like with HGLCs, like in the Lightning Network. Just for context, Dan,

could you just explain what an HGLC is? Yeah, absolutely. So an HGLC is a hashed time lock contract. It's a very specific smart contract, a very simple one where this was originally developed for cross-chain atomic swaps. So the canonical example is Bitcoin and Lightcoin. And the basic idea, and Satoshi had sort of a slightly more complicated version,

which is simplified by like theory on the Bitcoin Wiki anyway. The basic idea is that you lock up some money on the Bitcoin chain, and then you lock up some money on, say, the Likecoin chain. Alice locks it up on Bitcoin. Bob locks it up in Lightcoin. And then there's this secret that Alice, knows that can unlock both of them. So Alice reveals the secret by unlocking Bob's locked up light coin and receiving the light

coin, and that gives Bob the information he needs to get it from Alice. And you need to have a timeout so that Alice can't just withhold this information indefinitely. But that's the, you know, you've staggered timeouts on those. So it gets a little more complicated. But that's sort of the core idea. And then Lightning had the innovation of doing this inside payment channels rather than on the main chain. If you have Alice's a payment channel with Bob, Bob is a payment channel with Charlie. You can put HCLCs in those payment channels to ensure that a payment from Alice to Charlie that goes

through Bob happens atomically. It was a very clever idea that Joseph Boone and Tadreja had for Lightning originally adding putting these HLCs in payment channels. But what Interledger realized after originally designing their protocol to sort of require these enforced HCLCs is that there's an easier way, especially when you work. in payment channels and payments are super cheap. Updates are super cheap. You can just have Alice make a small payment to Bob, and Bob makes a small payment to Charlie, and then you just do that over and over again.

If at any point someone aborts the protocol, you just stop, and someone has only lost a relatively small amount. Okay. So if I understand correctly here, the idea is that rather than locking up money in these, in these contracts, you sort of send payments. a little bit more like you send packets in internet routing. So you send smaller bits. And if one piece of that gets lost in transit,

well, then you might want to take action or, you know, send it again or something like that. That's right. So it's a little different from packets, certainly, because packets are designed to be lost, basically. The way that this protocol works is that you don't lose any packets. Like if you or if you do, you know exactly who was responsible for it. but otherwise yeah it's it's basically the same kind of thing where instead of sending this whole payment

as one giant chunk that could get stolen by one bad actor exiting the protocol you send it in tiny pieces so that if anyone misbehaves they can only steal A they can only steal from their immediate counterparty small amounts so somebody who they already have a channel with and therefore some kind of trust relationship one assumes even again just for like if it's for as much as a penny

and then two that it's for this limited amount and only for a limited amount of time. Are there any other projects doing something similar like this? Because I feel like we've talked about this on the podcast before, but I can't remember with whom. I think you had Interledger on someone from Interledger on. So Interledger does this as well. Interledger does this sort of like...

Oh, yeah. This was developed, this idea. It was Interledger's idea. Okay. And it's such an elegant idea and solve some problems that I don't necessarily have to get into about HGLCs, but you can definitely see it. My Stanford talk, HGLC is considered harmful. where HCLCs,

the sort of ledger-enforced H-GLC approach that lightning takes leads to there being these denial-of-service attacks on the network at least if there's multiple assets in play, at least there being this free option problem. And it's also just much more complicated. And this was the one that I really faced

working on Starlight was that trying to enforce HGLCs within payment channels on a platform that wasn't originally designed to really support that turned out to be a huge hassle. We had Christian Decker on the podcast a couple, maybe a few months ago now. But yeah, I actually asked him about this exact DOS attack.

And he, you know, I feel he had like an okay answer, not the, not the best. He kind of like, you know, kind of kicked the can down the road on the answer to how to solve the DOS attack that comes with HDLCs. And so just to get it clear, is so is Starlight based on packetized payments or is it based on atomic HDLCs? So Starlight, as far as I got on it, was just for just payment channels. So it doesn't have any method for sending multi-hop payments. Does it use HDLCs though? It doesn't use HDLCs. So it's just payment channels. So Alice and Bob, so the way I think about Lightning Network and these kind of protocols is these two layers, Lightning is a composition of these two different technologies. The first one is payment channels. And that's just a way for two parties. And typically really with payment channels. channels. I think it's best to stick with bilateral payment channels. People have these more complicated constructions, but lightning only uses bilateral payment channels. So you have these two parties, Alice and Bob, and they can make payments to anyone else with that money. And what we layer on top of it is some method for multi-hop payments, some method for atomic multi-hop payments

so that if Alice is a payment channel with Bob and Bob is a payment channel with Charlie, Alice can make a payment to Charlie by making a payment to Bob and then Bob atomically makes a payment to Charlie. And so where Interledger primarily differs from from Lightning is, well, at this layer, is that the Interledger method of packetized payments is very different from Lightning's method of having this enforcement of HGLC's in the contract. So what Starlight was was just a payment channel solution. And we didn't get to, before I left, at least we didn't get to implementing the second layer. I think it makes the most sense to do it with Interledger, in part because it's not possible right now to do, to really do HCLCs on, on Stellar, would have to, we would

require a protocol update as far as I could tell. And it's just so much simpler and requires you to sort of solve fewer problems, I think. So let's move on then to the Rainbow Network. So can you describe at a high level what this is? Like, what is this new protocol and maybe how it pulls some these ideas from existing projects that you works on? Yep. So the Rainbow Network is an off-chain decentralized synthetics exchange. And it really, again, like mostly when I come up with stuff, it's not a really original ideas to me. It's just me sort of synthesizing ideas from different projects that I've had sort of the privilege

of working on and working with much smarter people on. And those projects very often sort of tend to be maybe more siloed. And so they'll come up with something really clever like Interledger did, and it won't necessarily filter out to the broader ecosystem. And so Rainbow takes a few ideas. It takes some ideas from these on-chain synthetics like Maker and Uma. It takes ideas from off-chain protocols like Lightning Network, Interledger, and Plasma, and just kind of gets some really interesting leverage, no pun intended, out of having, combining these two ideas.

Okay. Could you just maybe just briefly explain a synthetic asset for those? for whom that's unclear? A synthetic asset is informally, it's an asset that is backed by some collateral that isn't that actual asset. So it's, it comes out of, it's a derivative and it basically comes out of this, on the blockchain is one that's backed by another asset. It could, in theory, be backed by credit.

The basic idea is that instead of you actually owning an asset, like me selling you an asset, I can sell you just the exposure to that asset. So I can just say, like, I owe you the price of one Bitcoin at any point in time. And a year from now, like, I can make that payment to you and settle that without us ever actually touching Bitcoin. So makers die stable coin is an example of a synthetic. It's a coin that is, there's no dollars on the Ethereum, like native dollars on the Ethereum blockchain. There's no dollars backing each die. Instead, it's backed by this other asset, Ether.

and the promise enforced by these smart contracts that in some way or another this dye will be redeemable. It's not really redeemable in the maker system, but backed by the value of this ETH that's locked up as collateral. Okay, so would you say then that like US dollars backed by gold would have been a synthetic asset?

Well, the one difference there, if it's backed by a fixed amount of it, it's not really a synthetic, it's more of just like an IOU for that particular asset. And so a synthetic usually is meant to be a synthetic version of something for which there's like a natural version. So if you had like a, you know, like oil futures backed by gold or something, then that would be that's sort of a synthetic asset. But yeah, so the basic idea being that you get the exposures to this particular asset, but you don't actually need to deal in the natural one itself, the asset itself.

Do synthetic assets always need over collateralization? Not necessarily, especially if you're willing to take credit risk. So you could imagine two parties, if one of them trusts the other, I can give you a synthetic exposure to this particular asset, yeah, without it being fully collateralized on my end. A synthetic asset on a blockchain, typically you want it to be fungible. You want it to be acceptable by anybody if it's an on-chain synthetic. And so it does, you think it needs to be at least fully collateralized. And the problem is if the synthetic price rises faster than the collateral price, you could have an asset that's fully collateralized, become under collateralized.

That's kind of the nature of working with synthetics. But I think it's, you know, so you can have someone required to deposit more collateral, basically, to fill it up. And that's what the maker system does. And it penalizes someone who doesn't buy, with this liquidation penalty. Okay, so let's go back to into, with that context, we can now go back to your rainbow. Yeah, so please continue your explanation on Rainbow. So Rainbow Network is a combination of this idea of synthetic positions with this idea of payment channels.

So a payment channel is an off-chain agreement between two parties. And again, I always use two parties where they can sign these messages off-chain in a way that these new balances can be settled on-chain. And so typically in a payment channel, it'll be. like we lock up some escrow, some asset as collateral on the main chain, five Bitcoin, and then we have these balances off chain of like Alice has three Bitcoin, Bob is two Bitcoin, and they can make payments to each other by signing updates to this. So note this parallel between payment channels and synthetics. Both have this collateral pool where you have some money locked up in escrow that in some

ways eventually can get settled between these parties. In synthetic, it's based on the price of some reference asset. And payment channels is based on these messages that have been signed off-chain in this game that people play to exit the correct state. And so the rainbow combines these two ideas. And it says, we can have an off-chain payment channel, but instead of, it could be backed by Bitcoin, it could be backed entirely by ETH, but instead of it's settling based on just the balances that people have signed here on the off chain, it's also calculated based on the price of some reference asset. So that means that two parties can enter into this payment channel where they say, it's backed entirely by ETH, but where they agree off chain, they're doing these trades off

chain and they agree when we settle this, the amount of that each of us gets, the amount of collateral that each of us gets is computed in part based on the price of USD, the price of EF relative to USD. So that's what allows them to do these, to trade basically any asset they want, even with only ethas collateral on the main chain. I think most of our listeners will have some fundamental understanding of lightning network and how payment channels work. And there it's pretty, I mean, it's like pretty simply just a payment going in one direction or another on a channel. So it could be for a payment for something that's done completely offline, like, you know, like a merchant payment. payment or for some other cryptocurrency, for example, in the case of an exchange, but in that

case, that other asset isn't being transferred necessarily on that payment channel. So, for example, you know, Alice wants to buy some Bitcoin from Bob, sorry, some ether from Bob, and she sends Bitcoin over a lightning channel, and then Bob agrees to send her the ether, you know, on her ether wallet. But in this case, all of those assets are being transferred through payment channels on the Rainbow Network, correct? Well, so how Rainbow is different is that you can trade, yeah, you can trade different assets that's right, that aren't collateralized.

You don't have any collateral locked up on a blockchain in this particular asset, but parties on this network nevertheless can trade them. One benefit of this, it gives you a lot more flexibility. it means you can trade, for example, fiat currencies in these channels, which is not something you can do generally sort of trustlessly on something like lightning unless you can have a synthetic already on chain

for that particular asset. It also means that you don't need necessarily to have these multi-hop payments. And with Rainbow Network, you can do these sort of multi-hop trades, but you don't need to do multi-hop payments across multiple channels in order to trade any asset for any other asset.

So if I have this channel, a rainbow channel with somebody back entirely by Eath, I can trade dollars with them, I can trade gold with them, I can trade really any computable number, I can turn into something that I can trade with them. And so that, yeah, so that's sort of the benefit is not just that it can support any asset,

because you could theoretically have lightning network across multiple assets. And that's really what Interledger's designed for is to be a sort of like layer two that spans across many different base layer. one chains, but that even on one single channel, it can trade any particular, any asset that you want. This episode of Epicenter is brought to by Microsoft and the Azure Blockchain Workbench. Getting your blockchain from the whiteboard to production can be a big undertaking.

And something as simple as connecting your blockchain to IoT devices or existing ERP systems is a project in itself. Well, the folks at Microsoft had you covered. You already know about the Azure blockchain workbench and how easy it makes bootstrapping your blockchain network pre-configured with all the cloud services you need for your enterprise app. Their new development kit is the IFTTT for blockchains. Suppose you want to collect data from someone in remote location via SMS and half that data packaged in a transaction for your HyperLedger Fabric blockchain. The development kit allows you to build this integration in just a few

steps in a simple drag-and-drop interface. Here's another great example. Perhaps you're an institution working with Ethereum and rely on CSV files sent by email. One click in the Devkit and you can parse these files and have the data embedded in transactions. Whatever you're working with, the Devkit can read, transform, and act on the data. To learn more and to build your first application in less than 30 minutes, visit AKA.ms slash Epicenter. And be sure to follow them on Twitter at MSFT blockchain. We'd like to thank Microsoft and Azure for their supportive Epicenter.

Could we like maybe walk through an example where, let's say, you know, where we both have ethon Ethereum and I'm trying to buy some BTC from you or some synthetic BTC. I want exposure to BTC. Could you maybe walk us through an example of how this would actually work? Like what would be the steps of doing this? Sure. So I should first say that, you know, I've so far kind of elided the question of how rainbow

channels actually do enforce at the time of exit that, that it settles based on this price, the price of these assets. And there's a few ways to achieve that, one of which involves a price oracle, but, which they don't necessarily require one. But yeah,

so I'll walk you through the general idea. So if you've, let's suppose they start out with 80th each and they want to trade 40th for one Bitcoin, that might be right. No, that's, yeah, it's about right. We'll say 40. So they start out with Alice has a balance of 80.

Bob has a balance of 80. So Bob wants to get Bitcoin because their names start with B. So what happens is Bob's balance of Eith goes down from 80 to 40 and his balance of Bitcoin goes up from 0 to 1. This all has to remain balanced within this. It all has to always add up to exactly. 160-Eth, the amount that's actually collateralized. So then on the other side, Alice, she goes up to 120-Eth, but she goes down to negative-1 Bitcoin.

So when we compute her balance at the time that they exit, we say, okay, she's got 120-Eth, but then we have to subtract that by the amount of Eth that one Bitcoin is worth. So that's kind of how you achieve, that allows you to short, allows Alice to get a short position in Bitcoin. It allows Bob to get this long position in Bitcoin in a channel that isn't

collateralized by any Bitcoin. And it actually allows people, these parties to basically get leverage on a particular assets so that they, note that Alice has leverage on ETH. If Eth goes up, her balance goes up by significantly more than it would have when they would just sort of add 80th each. So this actually seems very similar. It reminds me of the original bit assets system on bit shares back in like 2014 or so, where they actually, you know, I think the technical, the financial term for this is a CFD,

a contract for a difference where basically what's happening. Right. And so, you know, bit assets was actually using these CFDs in order to create synthetic assets. So if people remember the BitUSD was their most popular one, but they also had everything from like, you know, bit gold to like bitRMB. And like they were essentially doing the synthetics. And so essentially what you've done here is you've just taken this bit acid system, but figured out how to make it work on a second layer system on top of payment channels

rather than on a contract on the main chain. That's right. And one thing you can do, you know, like putting it on a payment channel, and part, you know, it's like we just make everything a little more efficient. But it also opens up these new possibilities. There's this nice kind of synergy between these two things that, yeah, I think there's some benefits from having it off chain. So yeah, so I can, and I explain, maybe it's worth explaining now how a rainbow channel, like, actually works, how it settles. So there's three ways to do it to sort of construct a rainbow channel.

One of them is basically using price oracles and smart contracts. The second is to have physical settlement of this asset, where the asset itself has to actually be delivered. And the third is to have this continuous cash settlement of the value of it on the channel. So the first is maybe sort of the most straightforward is if you have some price oracle, if you have some reliable price feed that can be verified on the blockchain. And if your blockchain is like Ethereum, if it's, you know, it's turned completely or sufficiently fully featured,

that it can do this kind of calculation, then people who are signing these messages off-chain, when it settles the escrow contract that is handling the settlement of this payment channel, just computes the current balances of each of the parties based on their current portfolio in the channel and just sort of allocates the collateral appropriately. So that's maybe the most straightforward.

Yeah, does that make sense? I think it makes sense to me where, so essentially, you know, whenever, so back to that example, you know, I had 100, Alice had 120, uh, Eth and Bob at 40th, but Alice had negative one BTC. And so whenever, uh, they tried to close a channel, it basically sends it to the on-chain oracle that says, okay, the price of BTC is now 50th. And so now, you know, Alice is what actually Alice gets out is actually only 70th,

and Bob gets out 90th. Yeah, exactly. So it just sort of computes that. That's, you know, And does this require a trust, but this does acquire a trusted Oracle, right? It requires some kind of price oracle, some way of determining the price. And so if you want to avoid that, you can use one of these other two approaches. So the second one is physical settlement.

And so what that means is, like traditionally when you, when you've got a future or a derivative, you can either cash settle it or physically settle it. And physical settlement literally just means, like, I'm going to actually give you the asset itself. So the idea here would be, and we can get to Bitcoin in a second, but maybe it's easier if they're trading some asset that's already on Ethereum like Dai, which is the maker's stablecoin. If they have some synthetic position in die and one of the parties has a position of negative 100 die and some ETH, and the other party has a position of positive 100 die and some ETH say, then when they settle the channel, the contract could require that. Alice, who anyone who's short a position, like Alice's short die, has to actually send a hundred die to Bob in order to close out this channel. And if she doesn't, then all the collateral goes to Bob. So here, there's still a risk that the channel becomes under

collateralized or that Alice goes negative in her total balance. But if Alice is positive, then she's incentivized to actually really deliver this asset, the die to Bob, because then she gets her collateral out of the contract, the that she's owed. And if she doesn't actually do that, then Bob, then it's forfeit. So that's this method of physical settlement.

It works relatively straightforwardly when it's another asset on the same chain and it's a smart contract platform. But it actually also works for Bitcoin. So this is a cool construction. So we could have a channel on Ethereum where Alice is short Bitcoin. She's got a balance of negative one Bitcoin.

when they settle it, the contract can require that Alice sends one Bitcoin to Bob and then provides an SPV proof that that transaction occurred that is verified by the contract. So an SPV proof simplified payment verification. It's a protocol described in the original Satoshi White Paper. Basically, you just reveal the inclusion of this transaction, a miracle proof that is included in a Bitcoin block and then say like six blocks of proof of work on top of that. And this proof can be verified by a like client. It can also be verified by the Ethereum chain, for example, itself. So, of course, Cosmos works using SPV proofs. In this case, there's a proof of work, SPV proof.

But the idea would be Alice would have to send one Bitcoin to Bob, generate an SPV proof that it was included in the Bitcoin blockchain, and then reveal that to the Ethereum smart contract, which is programmed to verify it. But so this only works with blockchain native assets, right? So I can't do this for dollars, for example. That's right. So it only works for blockchain native assets where there's either like some ERC20 or some asset whose SPV proofs are readable by the chain that you're working on.

So yeah, so it's limited in its application, certainly. When you have that and you have either these SPV proofs to other systems or, you know, yeah, what's the, benefit of using a synthetic in this case instead of just using, you know, just trading on actual Bitcoin? Well, it's, it's that we can, you can do whatever trades you want with your counterparty, and you can trade Bitcoin with them while only having, say, ETH locked up as collateral, right? So it's much more flexible. If you would do this in Lightning, you would have to have some Bitcoin locked up in a Bitcoin payment channel, have some ETH locked up in the ETH payment channel, and then do atomic payments across those. But this is generally more flexible that you can,

that you can do that. So you mentioned this third way of settling, which is to have constant stream of payments. Can you describe that? That's right. And this is, people have noted that this idea is kind of inspired by the interledger idea I was talking before.

And like this is just generally true that basically every idea I've ever had was stolen by someone else, stolen by me from someone else who had like a really clever idea. I just sort of apply it to everything I can find. So this is, the idea here is we have some particular balance on, let's say we're doing it on Bitcoin and we can't use price oracles. It can't verify SBV proofs of other chains. There's no other assets

really on Bitcoin. So we just have a Bitcoin backed payment channel on Lightning and Alice and Bob have this channel with each other. Well, they can do a rainbow channel on top of that. And the way they do it is you informally agree at a higher layer, which is not enforced by the contract, you say, you know, like where now I'm going to be like slightly long USD and you're going to be slightly short USD. So we basically traded Bitcoin for dollars on this channel. And then as the price of fiat changes, you, like every five seconds, sign an update to update the payment channel so that you can update your balances. So if it was five Bitcoin and five Bitcoin and then someone traded four Bitcoin for eight, as I was like one Bitcoin for $8,000, so it became a balances of four

Bitcoin and $8,000 and $6 Bitcoin and negative $4,000, then the current update still looks like 5 Bitcoin, 5 Bitcoin as far as the Lightning Protocol is concerned. And then if Fiat crashes, then Alice's balance goes down because part of her balance is in Fiat and Bob's goes up. What happens to they just sign a new update saying, like, now I'm with 4.9, Alice has 4.9 Bitcoin and Bob has 5.1. And if you do this every five seconds, then the risk of your counterparty cheating you by not signing a new update is what hopes are negligible. What happens if there's a flash crash or a flash like rise in prices and the counterparty decides, I don't want to play this anymore?

Yeah, so that's the risk you take. So it may not be a great idea for like for incredibly volatile assets, but you can look at sort of what the what the max price difference is. And over like five seconds, it's pretty, which is, you know, even. you probably could sign an update every five seconds. In Lightning, you may even be able to do it every, like, two seconds. I think that shouldn't necessarily be too much of a risk, and so you just have to sort of tolerate that free option that you're giving them, but it's because it's only a free option for like a couple seconds.

So this is one of the areas where you get this new benefit from doing it with payment channels from doing this protocol off-chain. This is not a protocol that you could do on-chain because it requires these updates every five seconds. So because you've gone off-chain, you can now have this new way of doing a contract for difference, a relatively trustless contract for difference, because you've just dramatically lowered the cost of a transaction,

of a payment channel update here relative to doing this protocol on chain. Here you still do need a price Oracle as well, right? Or at least some way of you and your counterparty agreeing on what the change in prices. Yep, that's true. So you can independently, you can look at whatever price you want. You need to, you do need some way yet for you to know what the price is and to have one that you sort of agree with your counterparty on. So that could be like the median of a bunch of different exchange feeds, right? But each of you can go look at those independently.

And if you lie or, you know, so A, those don't have to be signed by the exchanges, right? So unlike with Maker where you actually need this process of taking these exchange feeds, and having oracles report them to the, to the blockchain, this is something that you can just do subjectively. You just look at it. And if something goes wrong, if you, like, sort of detect these feeds have been tampered with, you can just sort of halt the protocol.

And so another thing that you mentioned in the paper that makes this third method interesting is that it can actually already be implemented on Bitcoin's Lightning Network, which, you know, you can't really do with the first two because of lack of, like, scripting capabilities. Yep, that's right. And so I've talked to a couple of people who are working on lighting applications who are kind of interested in doing something like this. And so does the channel that does the payment channel that a rainbow channel is based on, right?

Does it actually have to be a literal singular channel or could it be like an ILP connection or like an ILP channel or could it be like a multi-hap channel or could it be like a multi-hom? lightning thing, can that act as a singular rainbow channel? Yeah, that's absolutely right. You can have sort of a virtual rainbow channel that is settled in this particular way. Yeah, if you're like Alice and Charlie don't have to necessarily have a channel with each other, they just have to be able to pay each other over this method. So yeah, it could be a multi-hop lightning connection between them. It could be an ILP, multi-hop ILP connection between them.

I think you'll probably get screwed on fees if you try to do that. If you try to update too frequently and it's a multi-hop payment. But yeah, that's certainly possible. Okay, so this is great when we have me and you who want to create a rainbow channel between us. Could you tell us a little bit now, okay, how do we take these rainbow channels and turn them into a rainbow network? And what is the benefit of such a network? Yeah, absolutely. So suppose we want to use this protocol for trading, right? And so someone wants to actually go just sort of like sign up, enter into one of these channels with a counterparty and then just trade whatever they want on that. Right. So they're they put in some Eith. And then now they're trading like USD with it. They're trading Bitcoin with it. The problem here is that maybe the counterparty to that trade doesn't especially want to be, take the exact inverse position of the trader at all particular times, right? So like if they're trading with

somebody, you need to actually have with sort of just naive rainbow channels, you need to actually have a channel with somebody who wants to take the opposite position. So if you want to go leverage long eve, they have to sort of diminish their east position. If you want to like go long Bitcoin, they now have to go short Bitcoin. And that's sort of a challenging thing if it's just sort of like this immediate counterparty. So, and remember, these are bilateral agreements.

So like, if I've got money in this channel with someone, they're the only person I can directly trade with. But there's a way that they can balance out that exposure by making that person, my counterparty, can make the opposite trade with someone else. They can hedge their position.

So you can hedge this on a, like actual physical exchange. on Bitmex or something, right? So like the, like if Alice is a channel with Bob, Bob could go, whenever Alice goes like extra long Bitcoin, Bob could go short Bitcoin on Bitmex or something in order to end up saying flat across these positions. Or they could do it in another rainbow channel.

They could have a channel with someone else where they do that. So the architectures that I sort of imagine for this would be probably you have like a couple very large market makers that are responsible for just hedging people's positions. And they just sort of like take all trades. And then they just have so many trades with so many people that and that they can kind of net out a lot of their exposure and then maybe trade on some centralized exchange

to really hedge away the rest. And then there'd be sort of users who are just connecting and they can just trade in whatever they want and their counterparty is taking a spread for, for either. and that counterparty either hedges directly with sort of like a market maker themselves or they connect to a market maker and hedge with them. So these market makers turn into sort of the hubs in this rainbow network.

That's right. But so question though, you know, this is kind of, I guess, a similar question that, you know, a lot of people concern when it comes to lightning as well is this requires a lot of liquidity lockup for the hubs here. In Lightning, it requires, you know, the hubs do have a lot of lockup with all the people that they're serving. And here it seems that in order to like connect two people in a, you know,

two opposite rainbow channels with each other, I have to as the market maker lock up collateral on both these channels. And this doesn't seem a very capital efficient way to do this. That's absolutely right. And something I've been talking about with some of the plasma people. And so plasma in part is a, and especially plasma cash and plasma debit, I consider them,

they're an attempted solution to this particular problem with lightning, which is this extra capital lockup, which, yeah, with absolutely also a problem in rainbow. But so I've been talking to them, and it's still sort of in early stages of really trying to solve this problem, but to figure out how to let these parties, let these market makers basically,

maybe they facilitate, the trade initially, but then they can kind of get out of the position by matching Alice. If Alice really wants long Bitcoin exposure and Bob wants short Bitcoin exposure, matching them together rather than the hub having to lock up their own liquidity in order to maintain this fully collateralized hedge trade. So that's something that we're sort of actively working on. I think some techniques from plasma will help. I think possibly some sort of like novel ones.

So yeah, talk to some plasma people and Hart from Buma as well. I know I was thinking about this. So allow people to become brokers instead of dealers. Yes, I definitely would not use any legal terms about what anyone is doing here. And again, like, you know, I make no representations about what anyone would be, what the legal status of anyone actually implementing and operating these nodes would be. But yeah, that's, that analogy does seem about, right? So what's the application here?

What would one use this for? Where do you see this being used in the future? And I guess the follow-up question is if and when it gets implemented, which I think you've spoken about in your paper. Yeah. So the basic idea, I think, for it is off-chain exchange, is decentralized exchange. And so it's a relatively efficient. It's a throughput efficient, not necessarily a capital efficient yet way to do. trustless trading. And, you know, we know that trading cryptocurrencies is one of, right now,

one of the few applications for which there really is product market fit. People seem to be doing a lot of it. It also works as a multi-asset payment network. So you can make payments in any of these assets in any asset, just like as if it's as if it's like the over an alledger or as if it's like a lightning network. So that's that's sort of another another possibility there. As for who's can implement it. You know, I'm not going to implement it. I think, uh, in part, you know, I have a, I have a full-time job working, uh, during, during research here at the paradigm. And, um, it wouldn't necessarily, yeah, I think, I think, you know, there'd be a lot of challenges, I think, to really, uh, getting, um, a rainbow, like launching it, um, and bootstrapping

it that aren't necessarily as, uh, really, really sort of like big problems, but aren't necessarily as technically interesting to me. Um, and so, yeah, Yeah, so, you know, again, I think anyone is welcome to the ideas. Like I said, like few of the ideas are really original to me. They're mostly combinations of other people's stuff. So people are absolutely welcome to work on it. And I've had some encouraging conversations with people who have been inspired to work on at least sort of similar things.

And some people, so it may end up getting implemented. And, you know, I definitely chat with people who I think it would be great if they do implement it. But one last question about rainbow channels before we move on is in the paper, you mentioned that, you know, it's called rainbow channels because rainbows are just multicolored lightning. Have you talked to any meteorologists about this claim? I didn't see a source on that one. Yeah, I mean, I was thinking of looking it up, but I just knew in my gut that that's how rainbows work.

So it's it's it's so the basic idea of rainbow rate is that because in one channel you can have many assets so it's kind of a multicolored thing. I also I like it because like I really like the rainbow theme. I have my rainbow shoes here. I think it's it's a it's fun branding for it. It sort of matches generally the Ethereum thing. And because yeah, sort of by analogy in some ways to the lightning network certainly was the other thinking there. I mean isn't a rainbow light refraction? in raindrops. It has nothing to do with lightning, does it? Doesn't it? That's your opinion, man.

Ah, okay. I'm a blockchain engineer, not a meteorologist. Okay, well, let's move on to our last and final topic, which is the Ivy Smart Contracting Language, was something I discovered doing the research for this episode, and is actually quite interesting. I tried it out, and I mean, I was kind of like fiddled around with the tool that you have. that you've built. Do you talk to us about Ivy and what were your goals here? Sure.

So Ivy was a programming language developed a chain where I used to work. And when I came on, it was already, people sort of had the basic design for it and it was compiling to our proprietary VM, the chain VM. And so that I worked on

relatively soon as as I started, it was working on it and really focusing on that language was also compiling it to Bitcoin script. And the reason is that there's no, you know, it's pretty hard right now to write a smart contract in Bitcoin. So Bitcoin has this scripting language. It's a low level stack based language. But it's just kind of awkward and unwindy to use. And even more to like think about. people don't people when you sort of like read a bitcoin script uh contract it's just a bunch of like op codes and you kind of have to like work out in your head what it means um and i think that

was holding back the space in some ways maybe conceptually just uh people having to like actually when you look at the lightning docs there's like these these really long bitcoin script uh programs um that yeah again they don't even really explain what they do and how the how the logic works and so ivy's kind of a simpler way of uh of expressing those and reading those as well as if you want writing them. So mostly I see it as an educational tool and one that maybe was trying to sort of help people understand the functionality of Bitcoin script

and how would these important Bitcoin script programs actually do. So yeah, so I came out with this, so I worked on this tool and Chain was very supportive generally of me working on everyone there really likes Bitcoin, so they were supportive of me working on it. So with one of my other colleagues, Boymeyer, we released this playground for Ivy

and sort of a very limited SDK and compiler for it. I found that really enjoyable. And I think it helped me thinking about BitcoinScript, helped me thinking about sort of smart contract programming language design. But really, yeah, again, it was meant, I think, to mostly teach about both Bitcoin script and the limitations of Bitcoin script. So when people try it out, and I can say,

imagine if we had this op code, here's the kind of program you could write. It was a hard kind of argument to make when people are stuck in the low level of just looking at these stats. based languages. I played around with it a little bit as well. And, you know, I really like it as a contracting language for like, if you're talking about like real financial use cases, it seems like, you know, it's a very declarative language. And so, you know, I like to phrase that I haven't

tried this yet, but I have a feeling I could maybe get an account, like teach an accountant to write this, right using, using Ivy. Because it's very simple. It's just like a set of like, you know, very English readable and like just saying, oh, this is the constraint. that like this money is spendable if these constraints are met. So like, you know, if this much time elapsed or whatnot, and I think it's a really cool language. But, you know, it never really saw much wide adoption, right? And so, you know, I, you know, people have played around the playground and stuff.

But like, do you know of anyone, like, actually using this to like deploy real Bitcoin scripts in the real world? Yes. I mean, first, I really hope nobody is using it to deploy real Bitcoin scripts on Manned Nett. because, you know, it's, it's, while we work as hard as we could to kind of get rid of a bunch of the bugs in it, it's definitely not, it hasn't been fully audited. And there may very well be bugs that someone that you could do if you, you know, could find in the compiler. So I hope nobody's, and there's a lot of warnings on it. You know, this is for educational purposes. There's no, please don't use it on main net.

The reaction from the Bitcoin community, so I was somewhat worried. And as someone who I consider myself, you know, like part of the Bitcoin community and I got a foot in the, the Bitcoin community and I really like them, but also in Ethereum. And then I've got friends and, you know, like, we're going to ripple with Interledger and Bitcoin Cash. Some people, like, I was, I was a little worried that the Bitcoin community would react negatively to this and say, like, we don't want smart contracts, smart contract languages are dangerous or like sort of criticizing it. And we didn't get that reaction at all. But maybe got something worse, which was people saying,

aha, look at this. The reaction was very positive, but it was, this is great. Look at this. See, Bitcoin already has smart contracts. We don't need to change anything. And as I said before, almost my entire goal with the language was to sort of show the limitations. And, you know, I appreciate that you like the language. Like, I find it somewhat frustrating because there's a lot of features that I'd really like to add that I think would be useful that you can't.

Because, at least not in the Bitcoin version, because of the limitations of Bitcoin script, you don't have, You don't have covenants. You don't have a string concatenation op code. You don't have the ability to check a signature on data other than the transaction hash. And I was sort of hoping by showing this and using this as an educational tool that I could say, okay, here you go. And here is what the cool thing that we could do if we had more expensive op codes. But for the most part, you know, I still hear people sort of referring to it as,

look, see, we can do smart contracts on Bitcoin with Ivy. but it's like, you can't, A, you can't do anything more, you know, it doesn't add any features to Bitcoin certain it because it's entirely compiled to Bitcoin script. But also, yeah, I mean, like, look at how limited it is. Like, you can do a couple things. You can verify a few things. You can basically write a multi-sig, custom multi-sig or like HGLC or something like Lightning with it.

But yeah. Then so, so as far as people deploying actual applications, so the only two smart contracts that are used on the Bitcoin main chain are multi-sigs, which are generally very simple. constructions and lightning. That's basically yet. I guess Arwen, I think, has a different payment channel protocol. So, yeah, maybe, like, I'd say payment channels in general. For those, I'm actually not surprised, I think, that people aren't using

IV in production, because I wouldn't suggest that they do. You know, like, Lalu is able to write really efficient Bitcoin scripts, and there's only a couple scripts they have to actually write. So I wouldn't want them to, like, write it in Ivy and not actually figure out. it by hand and test it. Because it's something that you write once and then use over and over again. What I'd really like to see, I think, and this is a blog post I've meant to write for a while, is trying to explain the lightning scripts.

It's an educational purpose, trying to explain the lightning scripts using Ivy. And that's something that I think I just would have to do and haven't had the time to. Any plans of maybe having Ivy compiled to more expressive systems? Like, for example, you know, Bitcoin Cash does have the check data sig. even like something with EVM where like, you know, it's a much, much more expressive VM, but it would be still nice to have this very easy to use language. Yeah, I've talked to a couple of people who are actually adapting.

Every once in a while, someone comes to me saying they want to adapt Ivy for Bitcoin cash. It's like coffee script for blockchain. Yep, yep. And I've actually, so I wrote Ivy compilers to, I wrote one to the EVM. I wrote one to chain VM and TXVM, which were the VMs that we worked on at a chain. I wrote one to Michelson, which is Tesris's smart contract language. And for a while, I was just like implementing Ivy Compilers are fun.

I think, honestly, like, I think it's not, it doesn't have enough features, even when you sort of like add these other op codes to really be, be fully useful as a smart contract language. So I'm, you know, like I wrote a test one to that works on Ethereum. And you can do some cool stuff with it, but you couldn't, you couldn't implement Plasconflict. on it, you couldn't implement payment channels. Well, you couldn't implement payment channels in it, but not really like necessarily the right kind. I do think there's room for a declarative programming language for Ethereum. But I've sort of moved on mostly from programming language design for better or worse. So I hope someone comes out to do that, but I think there's still going to be a big left to do it. Okay. So where can people find you and where can people learn more about everything you're

working on. Sure. So if you want to learn more about Ivy, you can go to Ivy-h-L-A-N-G-O-G-org, and that's the Ivy Playground that I mentioned, which allows you to sort of an in-browser ID for writing these Bitcoin scripts using Ivy. You can find more about the more out about the Rainbow Network by going to RainbowNet. Work, and that's the that's where the Rainbow Network paper is hosted. And generally, you can find me on Twitter at Dan Robinson on Twitter. And that's, my DMs are open and I love to hear about people who are interested in these same topics. Okay, great. Thanks for coming on the show. Thanks for having me. Thank you for joining us on this week's episode. We release new episodes every week. You can find and subscribe to the show on iTunes, Spotify, YouTube, SoundCloud, or wherever you listen to podcasts.

And if you have a Google home or Alexa device, you can tell it to listen to the latest episode of the Epicenter podcast. Go to epicenter.tv slash subscribe for a full list of places where you can watch and listen. And while you're there, be sure to sign up for the newsletter, so you get new episodes in your inbox as they're released. If you want to interact with us, the guest or other podcast listeners, you can follow us on Twitter. And please leave us a review on iTunes.

It helps people find the show, and we're always happy to read them. So thanks so much, and we look forward to being back next week.