Published in


ScalingNOW! Interview 6: Loredana Cirstea on µRaiden’s (ready NOW!) Micropayment Solution

There are a lot of projects focusing on building a scaling solution for Ethereum NOW! Each of these projects has their head down plowing forward with their solution and most don’t have time to communicate their solutions. We are pulling them out of their dark dev caves so that we can all understand our options for launching the DApps ASAP.

In our sixth Scaling NOW! interview, Griff Green from Giveth talks to Loredana Cirstea from Brainbot Labs Est. to get the deets on µRaiden’s solution to process micropayments.

Summary, related links, and transcript below.

Use cases:

µRaiden is a good fit for free, fast, and frequent ERC20 or ERC223 micropayments where only unidirectional channels are required. The users can be human or other applications.

Solution Issues:

Not a fit for one-time payments, bidirectional, or one-to-many payments.

Solution Summary (taken from µRaiden’s site):

µRaiden (read: Micro Raiden) is a payment channel framework for frequent, fast and free ERC20 token based micropayments between two parties. It comes as a set of open source libraries, documentation, and code examples for multiple use cases, ready to implement on the Ethereum mainnet. Whereas its big brother the Raiden Network aims to allow for multihop transfers via a network of bidirectional payment channels, µRaiden already enables to make micropayments through unidirectional payment channels.

Solution costs:

Opening a channel: ~90,000 gas. In ERC223, you open the channel and close the channel in the same transaction. If you use the ERC20, it costs a little bit more, ~120,000 gas.

Topping up: ~60,000 gas.

Cooperative close: The best case scenario because you only have one transaction, ~86,000 gas. The first withdrawal is a little bit higher, ~70,000 because you also need to store on-chain how many tokens you have already withdrawn. But then subsequent closes are ~50,000 gas.

Support ScalingNOW!

We are funding the ScalingNOW! interviews transparently on the Giveth Platform. If you want to support the cause, please go here send some ETH or Token love. Any leftover funds will be split between the Web3 Foundation and Giveth.

ScalingNOW! Summit:

In March 2018, Web3 Foundation and Giveth hosted a summit of the top devs working on scaling solutions, as well as the DApp developers that rely on these solutions. See the ScalingNOW! Summit transcript.

The insights and momentum gathered from this small gathering will feed into a larger public conference on Scaling initiatives that the Web3 Foundation will organize. The initial details of this conference are still being determined but will likely take place in Berlin in late 2018. For more details, follow Web3 on Twitter, join the Web3 Riot channel, and join the ScalingNOW! Channel.


Griff: I’m here representing Giveth. My name’s Griff Green. I’m doing all the scaling research and pushing the scaling agenda.

Loredana: I’m Loredana Cirstea, I’m from Brainbot, I’ve been working on µRaiden and Raiden Network.

Griff: Obviously you’re one of the big names in scaling. Raiden Network is the one that’s really doing it and pushing for the agenda and has been for a while, so I’m really excited to start the state channel discussion with you guys. You guys in general have some big dreams with Raiden. I know you’re deployed it to Ropstein, it’s ready to be tested. I encourage all the DApps that want to go with Raiden’s full implementation to start playing with it. But I want to start by talking about µRaiden, as it’s ready to be used today. So if we can stay mostly on that topic, that would be cool. And a little bit about our audience, we are — in this discussion, if you want background information, on how state channels work, there’s great information out there. That’s not what this is. This is more discussion focused providing information for DApp developers that have a solution that they want to scale ASAP and maybe of course they don’t understand all the details about this solution, but they’re not rookies and they can go look it up. So let’s stay really technical and dive deep. So let’s start with what DApps are likely candidates to use state channels in general, and what subsection of those DApps are actually good candidates for µRaiden.

Loredana: Just a disclaimer. I’m new on Raiden Network. My colleagues have done all the work, so just for people to know. I’ve been working mostly on µRaiden and some other projects. So state channels. With state channels, the idea is you can have an unlimited number of off-chain transactions among a defined set of participants. So use cases would be, for example, any application where you know exactly how many participants and who they are, and you have some predefined set of rules. So for example you can build a chess game, because participants can agree upon the final state of the chess table, and sign on that state after each off-chain transaction. Now with payment channels, the state changes are actually digital currency balance changes, very specific. With µRaiden, these payment channels are unidirectional. So you have defined and unchangeable roles for each channel participant. You have a sender and you have a receiver. The sender is the one that actually does the off-chain micropayments to the receiver. The receiver is responsible for actually running the µRaiden proxy server. The sender only needs something like Metamask to interact.

Griff: Nice.

Loredana: The general use case is the need for free, fast, and frequent micropayments without many-to-one setup because you have this unidirectional channel. So specifically, any application, not only decentralized applications, but also regular, non-crypto applications that offer a service to users that want to accept payments in tokens, they can use µRaiden. And the users can be human or even other applications, but ideally there should be this need for them to make frequent payments. It’s not efficient to use µRaiden for one-time payments, for example.

Griff: So like you go to a website and someone is constantly paying small transactions as it goes, that’s the perfect use case.

Loredana: Yes, you can think of paywall services like news articles or research articles, or for machine-to-machine where you want to query a table API like knowing the price per kilowatt for energy for calculating the energy cost on the fly, or doing some prepaid payments for using a WIFI bandwidth.

Griff: Can you explain the basics of how a many-to-one µRaiden payment channel would work, especially with deposit requirements and using RDN tokens — do you call them RDN tokens?

Loredana: Yes, that’s correct. So the unidirectional payment channel that µRaiden uses is quite simple. You have a sender and a receiver, the sender is the one who opens the channel, does the deposit of the tokens, and then can do the micropayment to the receiver. And we keep track of the last balance proof from the sender, which contains the total amount of tokens that the sender owes the receiver, and we use that to close the channel. Or the receiver can use that to actually withdraw tokens and leave the channel open for a future use.

Now about the tokens, µRaiden can be currently used with any ERC20 or ERC223 token, in the sense that decentralized application developers will have to deploy their own µRaiden smart contract themselves with the token address that they want as the constructor argument. However, if they do not want to worry about contract deployment on the mainnet, or they want their users to feel secure that they are actually using the same contract that everyone else is using, and they know that contract has been audited, then we provide this off-the-shelf solution that uses the Raiden Network token, or RDN.

Griff: Interesting. So if someone doesn’t want to deal with creating their own currency, some already established normal company, they can just use Raiden Network off the shelves as their payment solution and people can even use PayPal or something to put money in and they just handle that whole thing and buy RDN tokens off the market.

Loredana: Yes, that’s the idea. The idea is to provide something off-the-shelf that’s very easy to use, and it’s customizable and flexible, if you want it to be.

Griff: So if I have my own DApp and currency that I want to use, I can fork your code, change one argument and BOOM I have µRaiden working ready to use with micro, Swarm City tokens, whatever.

Loredana: Yes, you can do that, you just have to take care of deployment.

Griff: That’s very useful and interesting. Do you offer hands-on support for early adopters? How do you integrate with people that are starting to use this service?

Loredana: We are currently working on providing good documentation and tutorials and developers can use our µRaiden Gitter chat to ask questions any time. And we actually encourage developers that want to use µRaiden to get in contact with us because we want to build a good framework alongside the community. So yes, we offer support.

Griff: Do you have many people who are starting to use it?

Loredana: Yes, we know a few projects who have started to use µRaiden and even some who have started to port it to Java, for example. We are in contact with them and keep them updated.

Griff: That’s very cool. I know there’s an active bug bounty going on, can you talk about that a little bit?

Loredana: First we would like to thank all the people who have reviewed the contract during the bug bounty. The bug bounty has ended for now and there were no serious bugs found, but it did trigger some code changes. You can find more about that on our blog post and github issues because we tried to document everything. We are currently waiting for the sign type data EIP 712. It’s a signature standard proposal and we are waiting for it to be finalized because it will require minimal smart contract changes. After that we will have another bug bounty period, and only after that we can make sure that we have a stable production ready for release. And we want to make sure that what we’re offering is secure and we also want a good user experience for the senders, because this signature standard, you can see exactly what you’re signing, and the risks of using a malicious decentralized application are much lower.

Griff: That’s really good. Are you guys pushing the standard or another group?

Loredana: For now there’s another group that’s pushing the standard, but we are watching it closely and if we see anything that we would need and it’s not there, we’ll contribute.

Griff: So someone starts using this and all of a sudden you guys find a decent bug in the system through this next bug bounty, what would happen if you need to upgrade to a new contract, how would a DApp deal with that?

Loredana: At this point if we upgrade the contract, we don’t actually migrate the channel laid out automatically. So the participants would have to close their channels on the old contract and open new ones on the new contract. In terms of gas costs, this is not actually that bad, it would be like 86,000 gas units per channel close. But we have thought about this and we actually have the process documented in an issue. It usually boils down to do you open an immutable contract for people to use where they know what to expect in the future, or offer a contract that might change? So in the second option you also have to think about whether you force an upgrade for your users, or allow them to choose, or allowing them to choose or implement some sort consensus system. These are the landlines. But for now we have decided to stick with the simple, clearer path of having an immutable contract.

Griff: Good, I mean keeping it simple is always the way.

Loredana: The regular updates for the µRaiden update package can be made without any issues.

Griff: Can you go into more of the details about what a DApp would need to use for both scenarios? So actually if I’m Newsweek and I want people to pay in Raiden tokens to start viewing my website, then what would they actually need to do to implement this? Step 1, step 2?

Loredana: I’ll actually show you some good examples to understand it better. First, let me give you a bit of details about what components we actually have. µRaiden has a Python proxy server, has a smart contract, and we also build two client libraries — one for Javascript and one for Python. The proxy server is the core that actually handles the off-chain payment logic. And the receiver needs to run this in order to be able to receive micropayments. We’ve made it in a formal PyPI Python package so it’s very easy to install and use and run. And with just a couple of lines of code, you can already bridge your API with µRaiden, so you can make it payable. The proxos goes with some tools that helps the receive close all the channels in case it needs to, or to withdraw all the tokens that he has in the channels.

Then we have the smart contract, the one that stores the transactions information on-chain, and we have an interface for opening tokens out, closing the channels, withdrawing tokens. What’s nice about the smart contract is that you can use a delegate for using these things — for opening, topping up, and for cooperative closing. So this kind of opens up more features that can be built on top of µRaiden.

So you have the two client libraries, these are to provide a good interface for the sender to use the system. The Javascript client library, we have this as an MPM package, so it’s also very easy to install and use. So it contains all the µRaiden-related logic. So if you actually want to customize the y, you can customize everything in this library. And then you have the Python client. This can be used for machine-to-machine scenarios, because the other one, the Javascript one is like a paywall, you manually open and top-up channels, but the Python client can be used for machine-to-machine. So you just give it some configurations, some limits to the tokens, it opens, it tops up channels automatically for you, but it needs to be run on the sender’s machine and it needs an Ethereum live client. We have used this for a demo with acquiring ether price in USD and I have also used it for a drone demo that I made used recently for a Berlin Ethereum meetup.

Griff: Can you talk about the cooperative close? And also, what would someone need to do to fork µRaiden if they want to use their own currency? Because they have to do all those services still that you just explained, what extra piece do they need to do if they want to fork it?

Loredana: Aside from handling the token code and deployment the µRaiden smart contract with the token address, they wouldn’t need to do anything else. If it’s the same interface as we use now. If it’s another interface for transferring the tokens, they need to change a little bit of code. Mainly the smart contract, for example, because we use ERC20, ERC223. If the interface of the token is different than this, you need to modify a bit from the smart contract where exactly you do the token transfers, and then probably the client code that also handles this. But the proxy server remains totally unchanged.

Griff: Nice, well that’s really cool. You guys have made a very modular system. Okay so cooperative close.

Loredana: (Opens the API documentation.) You can see the smart contract, and you can see how you can open a channel, top up, I’m not going to show you this now because anyone can look at it, but here we have a nice diagram to show what happens. So for example, you open a channel, the channel is created, you have some off-chain transfers. And then what happens when you need to close the channel. We have the cooperative close and the uncooperative close. What this cooperative close means is that aside from the balance book, which is signed by the sender already with the last balance, you also need the receivers’ closing signature on the same data. So if you have this, you can close the channel immediately and you don’t go through a challenge period. So this can be called by the sender directly, by the receiver, and by any delegate that you want. If you want a bit of details about the uncooperative close, in very short words, the sender can pull close, let’s say the receiver is not online, he can close with his balance proof, and then you just have a period where the receiver, in case the sender didn’t send the correct balance proof, the receiver can come in and say, “This is the last balance proof that I received,” and then the channel is automatically closed. Or if the receiver is still applying after the challenge period has ended, then also the sender can call settle channel.

Griff: In application, the receiver is going to be some large company that can probably maintain a node’s uptime, right? Is that kind of the assumed idea?

Loredana: Yes.

Griff: So this is really just if they decide to close their business and run away—

Loreadana: Then there’s no problem, nobody loses his tokens.

Griff: Okay, that’s pretty cool. So on the UI side, what about the wallet for managing off-chain balances within the channel? I assume that’s also pretty easy to fork and customize.

Loredana: We provide that Javascript NPM package with all the logic, you just need to customize the UI a little bit.

Griff: Is there anything that people should be careful about, any potential common failure mechanisms that you might see?

Loredana: Not µRaiden-specific. The usual decentralized application issues that you can have. Token decimals.

Griff: Of course. And how much gas does it cost to open and close a channel? Depositing is just transferring an event, but then withdrawing?

Loredana: For opening a channel, you have about 90,000 gas costs. If you use the ERC223, you open the channel and close the channel in the same transaction. If you use the ERC20, it costs a little bit more, like 120,000 gas. Topping up is around 60,000 gas.

Griff: And that’s just because that’s how much it costs to transfer a Raiden token?

Loredana: Yes and you also need to modify the deposit variable. The actual channel data that we store is how many tokens you have as a deposit. And then the block number when the channel was open, this was part of the channel ID. Then you have the cooperative close case which is the best case scenario because you only have one transaction, 86,000. The first withdrawal is a little bit higher, around 70,000 because you also need to store on-chain how many tokens you have already withdrawn. But then the subsequent ones are 50,000 gas.

Griff: These are all very reasonable gas prices. That’s pretty efficient. My next question was about the dispute resolution process, but you pretty much already covered that. Any other details you think are relevant to people?

Loredana: No, not really.

Griff: When Raiden is implemented, DApp tokens will be able to be used directly in state channels through Raiden, is that correct?

Loredana: Yes.

Griff: So if a DApp wants to start using µRaiden but then wants to transition to a native token, how would that transition end up?

Loredana: Currently there’s no way to migrate users from µRaiden to Raiden, other than just closing the channel on µRaiden and opening if necessary new ones on the Raiden Network. They’re just different systems, but I think the µRaiden channel is efficient enough to not matter in terms of cost.

Griff: And when Raiden is developed, do you imagine people still using µRaiden and then Raiden being a seperate project?

Loredana: Yes, if the use case remains the same, micropayments, they might continue using µRaiden, at least at first.

Griff: Can you dive briefly into the Raiden solution and how it differs from µRaiden?

Loredana: µRaiden has unidirectional channels, like I said. Raiden Network channels are bidirectional, but what’s actually nice about Raiden Network is you can use the whole network of channels. So you don’t necessarily need to have an open channel with the person you want to send tokens to, the person or token or company or service, whatever you want. It can route the payment through the network. As I said, with µRaiden, one-time payments are not very efficient, you have to do frequent ones. With Raiden Network this doesn’t matter. Another difference would be that with µRaiden, these off-chain payments are free, just because you don’t need intermediaries. With Raiden Network, it would also depend on some fees to actually use other people’s channels. These are some of the differences between the systems.

Griff: Very cool. Well thank you so much, sounds like it’s ready to use now which is really exciting for people who are looking to scale their DApp. The ecosystem has grown to a point where there’s real DApps that need to get going. Thank you guys so much for your work.

Loredana: What I wanted to say that the complete class of micropayments for APIs can be built on Ethereum-based micropayments now. So check out the project, give us feedback, and you don’t have to look any further than µRaiden for fast, free, and frequent payments. We’re here.

Griff: What a tagline, that’s good. I like that.

Loredana: Thank you very much.

See more ScalingNOW! interviews on YouTube or more ScalingNOW! Medium posts.

Found this helpful?

Please send some ETH to support ScalingNOW! and enable us to continue reviewing scaling solutions! 💙

Still want more?

Join our community: by tackling interesting problems like this one you can help us make the world a better place!

Help us Build the Future of Giving: 🚀 Donate directly 🚀 or buy a Ledger with our affiliate link



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store