Preface
Last time I spoke about using fungible tokens via UTXO based on-chain protocols like OpenAssets. This time I would like to continue looking at token based channels with the state channel network "RAIDEN."
About RAIDEN
While the end user will most likely see Lightning and RAIDEN as being very similar UX-wise, the inner workings of the two protocols are vastly different.
State
UTXO based coins like Bitcoin are stateless. Each UTXO only has one state, unspent. Once the UTXO is spent, it has no state and ceases to exist. However, with Ethereum there is a large emphasis on state within the smart contracts and user balances for tokens are managed through the state of the contract.
Here's a simple analogy:
- Bitcoin is like a bunch of wallets Each UTXO (coin) is like a dollar bill inside a certain wallet. It can only exist (unspent) or not-exist (spent)
- Ethereum is like a bank that holds accounts, conditions, features, checks and balances if you wish. Tokens and ETH itself is all just numbers sitting on everyone's computer and verified by hash trees in the blockchain.
Physical wallets don't need to worry about accounting rules or even balance calculation. The wallet only has to physically protect the dollar bills contained within. If you take out a bill and hand it to another person, the total number of bills and the total value contained in the wallet changes without the wallet itself knowing or caring. (I know that everyone says "it's recorded in the blockchain" so saying it's not recorded anywhere might seem antithetical to that. However, I am merely looking at the wallet balance control mechanisms, as those are the more pertinent to the topic of payment channels.)
Banks, on the other hand, have to calculate various transactions including loans, interest, etc. and manage various different aspects of finance in order to arrive at the final balance of any given account. They can not just count some physical "thing" and be done with it.
Definition of channel Logic
If you look at the Lightning-RFC repository, Bitcoin based lightning protocol is defined at the lowest possible level of the network's logic, the OP codes.
However, in contrast to this, the RAIDEN specification is defining its function through high level interfaces defined in terms of the Solidity contract source, and not the more low-level EVM bytecode.
For example, OP_CHECKSEQUENCEVERIFY, which is used in the Lightning Specification, will cause a hard fork if the meaning of the OPCODE changes between versions. However, function setTotalWithdraw will not necessarily cause a hard fork if the Solidity compiler changes its representation in EVM bytecode over time.
Trusting the Underlying Token
The Token Contract defined in the RAIDEN spec will be a contract that fulfills the interface, such as ERC20. However, if the contract added additional functionality that is not forseen by the RAIDEN specification, there is a chance that the TokenNetwork will not work as planned.
Before Deploying a TokenNetwork on RAIDEN
- One must confirm the source code of the Token Contract that will be utilized and make sure there are no additional functions that would interfere with RAIDEN usage.
- Any Token that does not open its source code is not fit for use as a TokenNetwork on RAIDEN.
- If the combination of TokenNetwork Contract and Solidity compiler creates a contract that has a vulnerability, all channels should be closed so that a new contract can be deployed. (Though there may be a way to carry over channels to the new contract.)
Conclusion
RAIDEN is an extremely intriguing system for managing state channels, and I look forward to all the applications it can be used for. However, I think that the specification needs to be a little bit closer to the "metal" of Ethereum rather than being defined in a moving target such as Solidity.
Also, in addition to RAIDEN related code, one must also ensure the token contract code is also verified to maintain integrity of the TokenNetwork contract. (So tokens should be open source, used for an extended period without any major vulnerabilities etc.)
I will be keeping a close eye on RAIDEN and Lightning moving forward.
You can read the Raiden Network Specification that was released the other day, here.
