Dan Robinson

Rainbow Network – Off-Chain Synthetics Exchange or “Multicolored Lightning”

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 we discussed 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
  • 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 Ivy “smart contract” language for Bitcoin
Sponsored by
  • Cosmos: Join the most interoperable ecosystem of connected blockchains. Learn more at cosmos.network/epicenter.
  • Microsoft Azure: Deploy enterprise-ready consortium blockchain networks that scale in just a few clicks. More at aka.ms/epicenter.

Sunny Aggarwal: 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 again.

Dan Robinson: Thanks for having me on.

Sunny: Yeah, so, 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 found yourself working on many different projects throughout the entire space and so we hope to touch on a bunch of them in today’s episode but you know to start off with your Twitter bio famously says ‘lawyer, coder’ and so could you tell us a little bit about that and how you got into the crypto space and into coding in general coming in from a very different field?

Dan: Yeah. Sure. So I think it says coder/lawyer in that order and 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 as a 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 and Bitcoin, I was following Bitcoin and then when it came out at Ethereum 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.

Sunny: How did get involved with coding like, just completely self-taught.

Dan: 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 worked on sort of projects through college. While I was in law school I cross registered into a couple courses because then I kind of realized really liked engineering so I cross registered into a couple CS classes, but what I wish I’d done and there’s sort of my regret from college isn’t. I don’t really regret necessarily my I mean, I didn’t major in CS which I think caught up 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 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 those sort of the really like the fundamentals of computer science for example and 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.

Sebastien Couture: 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 sort of legal issues coming up that I would have studied law.

Dan: Although it means that everybody comes and asks you these questions and first of all, even you know, real lawyers don’t even know the answer to yet about what 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 the idea that you’re treating it as this kind of like arcane thing. It’s just I think like medicine, like I’ve no idea how to, I don’t think anyone who hasn’t been to medical school could, I wouldn’t trust them to sort of open up my heart, but for law 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.

Sunny: 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 you get started with Chain?

Dan: Yeah, so I left law very intentionally with no, sort of took a leap off a cliff without sort of a job in mind, in part because I wanted to interview for places and have them not think that I wasn’t serious about leaving my law firm job, so I did do a boot camp called Recurse Center, which is 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. Yeah, and 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 something I was thinking like just let me just do the most sort of like boring normal employable engineering skills, but funny enough there I got introduced to all this around programming language theory and functional programming that led into a lot of what I was sort of obsessed with while I was at Chain on programming language theory, and all these other sort of projects, I think I learned Rust there and it’s sort of sent me down these weird rabbit holes that as well 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.

Sebastien: So now you’re at Paradigm. Can you give us a high level overview of Paradigm and what your role is there?

Dan: 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 in investment sourcing investments following general trends in the space and the other is kind of contributing to protocol research so still working on some open source projects, working on elaborating on some ideas like paper which I came out with a couple months ago called the Rainbow Network. So that was something that you know, I think was sort of great that the Paradigm supported me on working on this kind of thing and let’s me continue this kind of open source research that I’ve been doing.

Sebastien: What is the reason why a fund would be funding like this pretty practical research into these networks. Is there like a thesis here?

Dan: This particular project just came out of my own interest and the funds interest and decentralized finance and protocols around that and then also my interest in off-chain scaling and 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 there’s sort of my attempt to actually really solidify some stuff that I was maybe guessing about and I was 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.

Sunny: Yeah, and so, based on your interest in off-chain scaling, I was telling Sebastian earlier, you’re the layer to god like, you know, you’ve worked on a lot of the layer 2 solutions that people are working on today. So, you know, just for some context so before you joined Paradigm you were there during that process when Chain was sort of merged with the Lightyear it create the Interstellar company. And so there you actually started working on a project called Stellar. Could you tell us a little bit about what that project was and what the goal there with that was?

Dan: Sure so Stellar was an adaptation of Lightning like payment channels on the Stellar network. And so originally the design was developed by Jen 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 payment channels but done on the seller protocol is 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 learned a lot about working on Ivy while I was at Chain and writing the Ivy compilers to every which platform and yes, that’s served me well I think.

Sebastien: So moving on to some other work that you’ve done tell us about the work you did in Plasma Cash and Plasma Debit.

Dan: Plasma is how I first heard of learned about Plasma where they released this white paper on it, but I sort of dug deep into it around January of 2018 and I was looking specifically at Plasma MVP which was this kind of Plasma that was a relatively interesting and secure way to do side chains, but had these sort of major flies one of which was that if the operator of a particular plasma chain can sort of denial of server attack the network 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 sidechain, so you don’t really get it as a scaling solution and so Plasma Cash comes out of thinking about well how do we pare down the feature set that this sidechain allows in order to 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 Interledger and applying it to Plasma Cash building up and putting on top of Plasma Cash.

Sunny: So what is your current involvement on the Plasma projects, 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 take it over after that.

Dan: Yep. So my modus operandi usually is not to stick around too long for all the really hard actual work. And Plasma group was 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 follow their designs and discuss it with them when we meet about research workshops, but for the most part they’re the ones carrying that forward.

Sunny: Right. Yeah, and so to listeners we actually did an episode about maybe a year ago with Karl Floersch about Plasma Cash actually. So if you’re interested in learning more about the actual technicals of how Plasma cash itself works take a look at that and then follow up with the Plasma Group to see what the latest developments are. And so I also know you’re pretty involved with the Interledger project as well, yet another second layer network you’re involved with, so you gave a great talk at the Stanford BPACE conference back in January where you kind of talked about why HTLC’s 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 Stellar. And is that what pushes you toward Interledger?

Dan: 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 originally saw it as something that actually technically looked a lot more like Lightning and had these HTLC’s sort of enforce 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 instead of having these really complicated smart contracts just to enforce atomicity across a multi-hop payment. You just send a really tiny amount over and over again. And so you can enforce atomicity 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 about Interledger was that that one design but I think there’s a lot of other really clever designs and choices that they’ve made, so yeah, I learned about that from from Ripple. Working on Stellar, originally I was planning to implement it like Lightning with HTLC’s.

Sebastien: Just for context Dan, could you just explain what an HTLC is?

Dan: Yeah. Absolutely. So a HTLC is a hashed time-lock contract. It’s a very specific smart contract, very simple one which was originally developed for cross chain atomic swaps. So the canonical example is Bitcoin and Litecoin and Satoshi had sort of a slightly more complicated version just 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 Litecoin chain, Alice locks it up on Bitcoin, Bob locks it up and Litecoin, 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 Litecoin  and that gives Bobby information he needs to get it from Alice and you need to have a timeout so that Alice caches with all this information and definitely and 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 payment channel with Bob, Bob has a payment Channel, you can put HTLC’s 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 Poon and Thaddeus Dryja had for Lightning originally, but what Interledger realized after originally designing their protocol to sort of require these enforced HTLC’s is that there’s an easier way, especially when you’re working in payment channels and 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 and if at any point someone aborts the protocol you just stop and they someone has only lost a relatively small amount.

Sebastien: Okay, so if I understand correctly here the idea is that rather than locking up money in these contracts you sort of send payments a little bit more like you send packets in internet routing.

Dan: That’s exactly right.

Sebastien: So you send smaller bits And if one piece of that gets lost in transit, well, then, you know, you might want to take action or send it again or something like that.

Dan: That’s right. So it’s a little different from packet certainly because packets are designed to be lost basically. The way that this protocol works is that you don’t lose any packets and if you do, you know exactly who was responsible for it, but otherwise, yeah, it’s basically the same kind of thing where instead of sending this whole payment is 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 vehicle only steal from their immediate counterparty small amounts, somebody who they already have a channel with and therefore some kind of trust relationship one assumes, again even if it’s for as much as a penny and also that it’s for this limited amount and only for a limited time.

Sebastien: Are there any other projects doing something similar this because I feel like we’ve talked about this on the podcast before but I can’t remember with whom.

Dan: I think you has Interledger on right?

Sebastien: Yeah. So Interledger does this as well.

Dan: Oh yeah, this was Interledger’s idea and it’s such an elegant idea and solves some problems that I don’t necessarily have to get into about HTLC’s but you can definitely see at my Stanford talk HTLC’s considered harmful, where these ledger enforced HTLC approach that Lightning takes leads to their being these denial of service attacks on the network at least if there’s multiple assets in play at least they’re being this free option problem. And this is also so much more complicated and this was the one that I really faced working on Stellar was that trying to enforce HTLCs within payment channels on a platform that wasn’t originally designed to really support that, turned out to be like a huge hassle.

Sunny: We had Christian Decker on the podcast a maybe a few months ago now but yeah, I actually asked him about this exact DoS attack and I feel he had like an okay answer not the best, kind of a kick the can down the road kind of answer to how to solve the DoS attack that comes with HTLCs. And so just to get it clear, is Stellar based on packetized payments or is it based on Atomic HTLCs

Dan: So Stellar as far as I got on it was just for payment channels. So it doesn’t have any method for sending multi-hop payments. Sunny: Does it use HTLCs though?

Dan: It doesn’t use HTLC. So it’s just payment channel. 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 I think it’s best to stick with bilateral payment channels people use these more complicated constructions, but only Lightning only uses bilateral payment channels. So you have these two parties Alice and Bob and they can make payments to each other but they can’t make payments to anyone else with that money. And what we layer on top of it is 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 at this layer is that the Interledger method of packetize payments is very different from Lightning’s method of having this enforcement of HTLC’s in the contract. So what Stellar was just a payment channel solution and 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 really do HTLC’s on Stellar, we would require 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.

Sebastien: 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 from these ideas from existing projects that you work on?

Dan: Yep. So Rainbow Network is an off-chain decentralised synthetics exchange and it really again like mostly when I come up with stuff it’s not a really original ideas it’s just me sort of synthesizing ideas from different projects that I’ve had the privilege of working on and working with much smarter people on and those projects very often 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 to the broader ecosystem and so Rainbow takes a few days to take some ideas from these on-chain synthetics like Maker and UMA it takes ideas from off-chain protocols like Lightning, Interledger and Plasma and just kind of gets some really interesting leverage no pun intended out of having combining these two ideas.

Sebastien: So could you maybe just briefly explain a synthetic asset for whom that’s unclear.

Dan: A synthetic asset is informally, it’s an asset that is backed by some collateral that isn’t that actual asset so it’s a derivative and 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 I can make that payment to you and settle that without us ever actually touching Bitcoin. And so Makers dai. So Bitcoin is an example of a synthetic. It’s a coin that is there’s no native dollars on the Ethereum blockchain. There’s no dollars back in each dai instead it’s backed by this other asset ether and the promise enforced by these smart contracts that in some way or another this dai will be redeemable. It’s not really redeemable in the Maker system but backed by the value of this ETH locked up as collateral.

Sebastien: Okay. So would you say then like US Dollars backed by gold would have been a synthetic asset?

Dan: Well, the one difference there may be 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 oil futures backed by gold or something then that would be that sort of a synthetic asset. But yes 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.

Sunny: Do synthetic assets always need over collateralization.

Dan: Not necessarily, especially if you’re willing to take credit risk, so you could imagine two parties. If one of them trust the other I can give you a synthetic exposure to this particular asset 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 you think it would need to be at least fully collateralized and the problem is if the synthetic price rises faster than the collateral price you can have an assets fully collateralized become under collateralized that’s kind of the nature of working with synthetics, but I think 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.

Sebastien: Okay. So with that context we can now go back to Rainbow. Yeah, so, please continue your explanation Rainbow.

Dan: So Rainbow Network is a combination of this idea of synthetic positions with this idea of payment channel. So a payment channel is an option 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, you know, Alice has three Bitcoin, Bob has 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 an 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 chess to exit the correct state and so Rainbow combines these two ideas and it says we can have an off-chain payment channel but it could be backed by Bitcoin if we act entirely by ETH but instead of it 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 back entirely by ETH but where they’re doing these trades off-chain, and they agree when we settle this the amount of ETH 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 ETH relative to USD. So that’s what allows them to trade basically any asset they want even with only ETH as collateral on the main chain.

Sebastien: I think most of our listeners will have some fundamental understanding of Lightning Network and how payment channels work and it’s pretty simply just a payment going for in one direction or another on a channel so it could be for a payment for something that’s done completely offline. Like a merchant 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 ether from Bob and she sends Bitcoin over Lightning Channel and then Bob agrees to send her the ether, you know on her ether wallet. In this case all of those assets are being transferred through payment channels on the Rainbow Network, correct?

Dan: Well, so how Rainbow is different is that you can trade different assets that aren’t collateralized. You don’t have any collateral locked up on a blockchain and this particular asset but parties on this network nevertheless can trade them. One benefit of this is it gives you a lot more flexibility means you can trade for example Fiat currencies in these channels is not something you can do generally 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 Rainbow channel with somebody backed entirely by ETH 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’s sort of benefit is not just that it can support any asset because you could theoretically have Lightning that work across multiple assets and that’s really what Interledger’s designed for is to be a sort of like layer 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.

Sunny: Could we maybe walk through an example where let’s say, where we both have ETH on Ethereum, and I’m trying to buy some BTC from you or some synthetic BDC. I want exposure to BDC. Could you maybe walk us through an example of how this would actually work? Like, what would be the steps of doing this?

Dan: Sure, so I should first say that you know, I’ve so far kind of alighted the question of how Rainbow channels actually do enforce at the time of exit that it settles based on this price of these assets and there’s a few ways to achieve that one of which involves a price oracle, which they don’t necessarily require one, but yeah, so I will walk you through the general idea. So let’s suppose they start out with 80 each and they want to trade 40 each for one Bitcoin. So they start out with Alice has a balance of 80 eth. Bob has a balance of 80 eth. So Bob wants to get Bitcoin because their name start with B. So what happens is Bob’s balance of ETH 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 a hundred sixty ETH, the amount that’s actually collateralized. So then on the other side Alice goes up to a hundred and twenty ETH but she goes down to negative one Bitcoin. So when we compute her balance at the time they exit we say, okay, she’s got a hundred twenty ETH but then we have to subtract that by the amount of ETH that one Bitcoin is worth. So that allows Alice ot get the short position in Bitcoin. It allows Bob to get this long position of Bitcoin in a channel that isn’t collateralized by any Bitcoin and it actually allows these parties would basically get leverage on a particular asset, note that Alice has leverage on eth. If goes up her balance goes up by significantly more then it would have when they were just sort of at at 80 ETH each.

Sunny: So this actually seems very similar, reminds me of the original bit assets system on Bitshares back in late 2014 or so where I think the financial term for this is a CFD, a contract for difference, where basically that’s what’s happening. And so, you know bit assets were actually using these CFDs in order to create synthetic assets. So if people remember the Bit USD was the most popular one, but they also had everything from like, you know bit gold to bit RMB and they were essentially doing the synthetics. And so essentially what you’ve done here is you’ve just taken this bit assets 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.

Dan: That’s right. And one thing you can do, like putting it on a payment channel, 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 mean I can explain maybe it’s worth explaining now how a Rainbow Channel 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, 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 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?

Sunny: I think it makes sense to me where so essentially, you know, so back to that example, I had a hundred, Alice had 120 ETH and  Bob had 40 ETH but Alice had negative 1 BTC and so whenever they try to close the channel it basically sends it to the on-chain oracle that says ok the price of BTC is now 50 eth. And so now, what Alice gets out is actually only 70 ETH and Bob gets out 90 eth.

Dan: Yeah, exactly. So we just sort of computes that.

Sunny: But this does require a trusted oracle, right?

Dan: 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’ve got a future or derivative you can either cash settle it or physically settle it and physical settlement literally just means 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 stable coin. If they have some synthetic position in dai and one of the parties has a position of negative a hundred dai and some ETH and the other party has position of positive 100 dai and some ETH then when they settle the channel the contract could require that Alice who anyone who’s shorter position like Alice is short dai has to actually send a hundred dai to Bob in order to close out this channel. And if she doesn’t then all of 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 inner total balance. But if Alice is positive and she’s incentivised to actually really deliver this asset the dai to Bob because then she gets the collateral out of the contract and if she doesn’t actually do that then Bob is in forfeit. So that’s 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 has 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 contracts. SPV is 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 and this case is a bit quite this is 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 is included in the Bitcoin blockchain and then reveal that to the Ethereum smart contract which is programmed to verify it.

Sunny: But so this only works with blockchain native assets, right? I can’t do this for dollars for example.

Dan: That’s right. So it only works with 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.

Sunny: When you have that and you have either these SPV proofs to other systems, what’s the benefit of using a synthetic in this case instead of just using you know, just trading on actual Bitcoin?

Dan: Well, 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, 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 that and the ETH payment channel and then do a timely payments across those. This is generally more flexible that you can do that.

Sebastien: So you mentioned this third way of settling which is to have constant stream of payments. Can you describe that?

Dan: That’s right. And people have noted that this idea is kind of inspired by the Interledger idea which I was talking before and this is just generally true that basically every idea I’ve ever had was 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 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 SPV 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 we’re now I’m going to be like slightly long USD and you’re going to be slightly short USD. So we basically created Bitcoin for dollars on this channel and then as the price of Fiat changes you every five seconds sign and 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 it as I say one Bitcoin for $8,000 became a balance of four Bitcoin and $8,000 and six Bitcoin and negative $4,000 then the current update still looks like five Bitcoins 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 be just sign a new update saying Alice has 4.9 Bitcoin and Bob has 5.1. If you do this every five seconds, then the risk of your counterparty cheating you by not signing a new update is what helps are negligible.

Sunny: What happens if there’s a flash crash or a flash rise in prices and the kind of party decides. I don’t want to play this anymore.

Dan: Yeah, so that’s the risk you take so it may not be a great idea for incredibly volatile assets, but you can look at sort of what the max price difference is and over like five seconds which is even you probably could sign an update every five seconds and in Lightning you may even be able to do it every like two seconds. I think that shouldn’t necessarily be too too much of a risk and 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. 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.

Sunny: 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 price is?

Dan: Yep. That’s true. So you can independently look at whatever price you want. You do need some way for you to know what the price is and to have one that you should agree with your counterparty on but 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 so 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 you just look at it. And if something goes wrong, if you detect these feeds have been tampered with you can just sort of halt the protocol.

Sunny: And so another thing that you mention 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.

Dan: Yep, that’s right. And so I’ve talked to a couple people who are working on Lighting applications who are kind of interested in doing something like this.

Sunny: And so there’s 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 channel or could it be a multi-hop Lightning thing, can that act as a singular Rainbow channel?

Dan: Yeah, that’s absolutely right. You can have sort of a virtual Rainbow channel that is settled in this particular way, so 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 a multi app ILP connection between them. I think you’ll probably get screwed on fees if you try to update too frequently and it’s a multi-hop payment. But yeah, that’s certainly possible.

Sunny: 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 how we take these Rainbow channels and turn them into a Rainbow network? And what is the benefit of such a network?

Dan: Yeah, absolutely. So suppose we want to use this protocol for trading right? And so someone wants actually go enter into one of these channels with the counterparty and then just trade whatever they want on that right? So they put in some ETH  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 take the exact inverse position of the trader at all. So if they’re trading with somebody, with native Rainbow channels, you need to actually have a channel with somebody who wants to take the opposite position. So 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 an actual physical exchange on Bitmix or something. So if Alice is a channel with Bob, Bob could go whenever Alice goes like extra-long Bitcoin, Bob could go short Bitcoin on Bitmax or something in order to end up staying flat across these positions. Or they could do it another Rainbow channel, they could they could have a channel with someone else when they do that. So the architecture that I sort of imagined 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 take all trades and then they just have so many trades with so many people and 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 they’d be sort of users who are just connecting and they can just trade in whatever they want and their counterparties taking a spread for free either and that counterparty either hedges directly with a market maker themselves or they connect to another through a market maker and hedge with them.

Sunny: So these market makers turn into sort of the hubs in this Rainbow network.

Dan: That’s right.

Sunny: But so question though, you know, this is kind of I guess a similar question that a lot of people are concerned when it comes to Lightning as well is this requires a lot of liquidity lock up for the hubs here,in Lightening it requires the hubs to have a lot of lock up with all the people that they’re serving and here it seems that in order to connect to people in 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.

Dan: That’s absolutely right and something I’ve been talking about with some of the Plasma people. So Plasma in part is, especially Plasma Cash and Plasma Debit, I consider them a particular problem with Lightning which is this extra capital lock up, which is absolutely also a problem in Rainbow, 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 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 hob having to lock up their own liquidity in order to maintain this fully collateralized hedge trade, so that’s something that we’re actively working on. I think some techniques from Plasma will help. I think possibly some sort of like novel ones. So I talked to some Plasma people’s when I was thinking about this.

Sunny: So a lot of people to become brokers instead of dealers.

Dan: Yes, I definitely would not use any legal terms about what anyone is doing here again, I make no representations about what the legal status of anyone actually implementing and operating these nodes would be but yeah, that analogy does seem about right.

Sebastien: So what’s the application here? Where do you see this being used in the future? And I guess my follow-up question is if and when it gets implemented, which I think you’ve spoken about in your paper.

Dan: Yes, so the basic idea I think for it is off-chain exchange is decentralized exchange. And so it’s blueprint efficient not necessarily a capital efficient yet way to do trustless trading and you know, we know that trading cryptocurrencies is 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 asset just like as if it’s over in Interledger as if it’s like a Lightning network, so that’s sort of another possibility there. As for who’s gonna implement it, I’m not going to implement it, I have a full-time job working ding research here at Paradigm and I think you know, there’s gonna be a lot of challenges I think to really getting a Rainbow launching at bootstrapping at that aren’t necessarily as, really sort of like big problems but aren’t necessarily as technically interesting to me. And so yes, I think anyone is welcome to the ideas. Like I said, 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 similar things and it may end up getting implemented and I definitely chatted with people who I think it’d be great if they do implement it.

Sunny: One last question about Rainbow channels before we move on is in the paper you mentioned that it’s called Rainbow channels because rainbows are just multicolored lightning. Have you talked to any meteorologists about this claim and I didn’t see a source on that one.

Dan: Yeah, I mean I was thinking of looking it up but I just knew in my gut that that’s how rainbows work. So the basic idea of Rainbow is because in one channel you can have many assets so it’s kind of a multicolored thing. I like it because I really like the rainbow theme I have my rainbow shoes here. I think it’s fun branding for it sort of matches generally the Ethereum thing and because sort of by analogy in some way so that the Lightning network certainly was the other thinking there.

Sebastien: I mean isn’t a rainbow light refraction in raindrops. It has nothing to do with lightning.

Dan: That’s your opinion man. I’m a blockchain engineer not a meteorologist.

Sebastien: Okay. Well, let’s move on to our last and final topic which is the Ivy smart contracts and language which is something I discovered doing the research for this episode and is actually quite interesting. I tried it out and I mean it’s kind of like fiddled around with the tool that you have you built, can you talk to us about Ivy and what were your goals here?

Dan: Sure. So Ivy was a programming language developed at Chain where I used to work and when I come 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 then I worked on relatively as soon as I started working on it and really focusing on that language was also compiling it to Bitcoin script and the reason is that it’s pretty hard right now to write a smart contract in Bitcoin, so Bitcoin has the scripting language. It’s a low-level stack-based language, but it’s just kind of awkward and unwieldy to use, and even more like think about, when you read a Bitcoin script contract it’s just a bunch of like opcodes and you kind of have to work out in your head what it means and I think that was holding back the space in some ways maybe conceptually just people having to actually, when you look at the Lightning docs there’s these really long Bitcoin script programs that don’t even really explain what they do and how the logic works and so Ivy is kind of a simpler way 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 I was trying to sort of help people understand like the functionality of Bitcoin script and how with these important Bitcoin script programs actually do. So I worked on this tool on Chain was various support, generally everyone there really likes Bitcoin so they were supportive of me working on it. So with one of my other colleagues we released this playground for Ivy and compiler for it. I found that really enjoyable and I think it helped me think about smart contract programming language design, but really 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 stack based languages.

Sunny: I’ve played around with it a little bit as well and I really like it as a contracting language for if you’re talking about a real financial use case, it seems like it’s a very declarative language and I like to phrase that I haven’t tried this yet but I have a feeling I could maybe teach an accountant to write using Ivy because it’s very simple. It’s just like a set of very English readable and just saying, oh this is the constraints that like this money is spendable if these constraints are met so if this much time elapsed or whatnot. I think it’s a really cool language, but you know, it never really saw a much wider adoption, right? And so people have played around the playground and stuff but do you know of anyone actually using this to like deploy real Bitcoin scripts in the real world?

Dan: Yes. I mean first I really hope nobody is using it to deploy a real  Bitcoin when scripts on mainnet because while we work as hard as we could to kind of get rid of a bunch of the bugs in it it hasn’t been fully audited and there may very well be bugs, so I hope nobody is and there’s a lot of warnings on it that this for educational purposes, please don’t use it on mainnet. 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 Bitcoin community and I really like them but also in Ethereum and then I’ve got friends in Ripple, with Interledger and Bitcoin Cash, 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 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 show the limitations and you know, I appreciate that you like the language, 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. But you can’t because at least in the Bitcoin version the limitations of Bitcoin script you don’t have covenants, you don’t have a string concatenation opcode, 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 as an educational tool that I could say okay here you go, here is the cool thing that we could do if we had more expensive opcodes, but for the most part I still hear people referring to it as. look see we can do smart contracts on Bitcoin with Ivy but you can’t do anything more if it doesn’t add any features because it’s entirely compiled in Bitcoin script but look at how limited it is, you can do a few things with it, but so as far as people deploying actual applications, the only two smart contracts that are used on the Bitcoin main chain are multisigs which are generally very simple constructions and Lightning. That’s basically it. I’m not actually surprised that people aren’t using Ivy production because I wouldn’t suggest that they do. I wouldn’t want them to write it in Ivy and not actually figure it all out by hand and test it, because it’s something that you write once and then use over and over again. What I would really like to see and this is a blog post I was meant to write for a while is trying to explain the Lightning scripts using Ivy. And that’s something that I think I just would have to do and havent had the time to.

Sunny: Any plans having Ivy compiled to more expressive systems for example Bitcoin Cash does have the check data sig or even something like EVM where it’s much more expressive VM but it’s still nice to have this easy to use language.

Dan: Yeah I’ve talked to a couple of people who are actually adapting every once in a while someone will come to me and say they want to adapt Ivy for Bitcoin Cash.

Sebastien: That’s like coffee script for blockchain.

Dan: Yeap. And I wrote Ivy compilers, I wrote on to the EVM, and one to Chain VM and TxVM, which were the VMs that we worked on at Chain. I wrote one to Michelson which is Tesoz’s smart contract language and for a while I was just implementing IV compilers for fun. Honestly I think it doesn’t have enough features even when you add these other opcodes to really be fully useful as a smart contract language, so again I wrote test one to networks on Ethereum and you can do some cool stuff with it but you couldn’t implement Plasma. I do think there’s room for a declarative programming language for Ethereum but I’ve moved on mostly from programming language design for better or worse, so I hope someone comes out to do that.

Sebastien: Okay so where can people find you and learn more about what you’re working on.

Dan: Sure so if you want to learn more about Ivy you can go to Ivy-lang.org and that’s the Ivy playground that I mentioned. You can find more about the Rainbow Network by going to rainbownet.work and that’s where the Rainbow network paper is hosted. And generally you can find me on twitter and my DMs are open and I love to hear from people who are interested in these topics.

Sebastien: Great thanks for coming on.

Dan: Thanks for having me.