bitbank techblog

LNリサーチ#2: RaidenとLightning Network

背景

前回は、OpenAssetsのようなUTXOベースのブロックチェーン上のカスタムトークンのオフチェーン利用について説明しました。

今回は引き続き、ステートチャンネルにおけるオフチェーンネットワークRaiden上のカスタムトークンについて説明したいと思います。

RaidenとLightning Networkの比較

Lightning NetworkとRaidenは、UX上は一見よく似ていますが、それぞれのプロトコルにおける裏のしくみは大きく異なります。

コイン(トークン)の状態

BitcoinなどのUTXOベースのコインは状態を持ちません(Stateless)。

あらゆるUTXOはただ一つ、unspent(未使用)状態のみを持ちます。

UTXOによって支払いが行われると、そのUTXO自体は消滅します。

しかし、Ethereumではスマートコントラクト内の状態に重きがおかれており(Stateful)、ユーザーのトークン残高はコントラクトの状態をとおして管理されています。

たとえるなら:

  • Bitcoinは大量の財布  UTXOは財布の中のお札のようなもので、それらの状態は「存在する」(unspent)、または「存在しない」(spent)だけです。 トークンやBTCの保有数量は、これらお札の合計値です。  
  • Ethereumは銀行  そこでは特定の条件下でのみ、お金の移転を許された口座群が管理されています。 トークンやETHの保有数量は、ブロックチェーンのハッシュツリーによって検証された単なる数値です。  

財布を使うときは、残高計算や会計上のルールを考慮する必要はありません。
ただ単にそこに収められているお金を守ったり、払ったりするだけの機能が存在すればよいのです。
財布からお札を取り出して別の人に渡すと、財布自体が認識していなくても財布に含まれるお札の枚数と合計金額が変わります。

一方、銀行は口座の残高を計算するために、ローンや利子などを含む取引をはじめとした金融におけるさまざまな側面を管理する必要があります。
ここにおいては、お金を物理的な「物」として管理することはできません。

チャンネルロジックの定義

Lightning-RFCリポジトリを参照すると、BitcoinベースのLightningプロトコルは、ネットワークのロジックにおいて最も低レベルなOPCODEで定義されています。

これにより、Lightning Networkで使用されているOPCODEであるOP_CHECKSEQUENCEVERIFYの意味がバージョン間で異なる場合、ハードフォークを引き起こします。
つまり、OP_CHECKSEQUENCEVERIFYの意味するところは、ハードフォークが発生しない限りは変わりません。

一方で、Raidenの仕様ではSolidityのコントラクトソースによって定義されたハイレベルなインタフェースをとおして機能を定義しています。より低レベルなEVMバイトコードではありません。

よって、SolidityコンパイラがEVMバイトコードの表現をどこかのタイミングで変更した場合、RaidenのTokenNetworkコントラクトfunction setTotalWithdrawは必ずしもハードフォークを引き起こすわけではありません。
つまり、ハードフォークが発生しなくても、Solidityコンパイラのバージョンアップ時にfunction setTotalWithdrawの実行結果が微妙に変わってしまうことがあり得ます。

トークンコントラクトの信頼性

Raidenの仕様において想定されているトークンコントラクトはERC20などの標準的なインタフェース要件を満たします。

しかし、対象のトークンがERC20のインタフェースに加えてブラックリスト機能(ex. CentreのBlacklistable)などを実装していることがあります。

このようにRaidenのTokenNetworkコントラクトの設計にて想定されていない機能が含まれている場合、正常に動作しない可能性があります。

RaidenにTokenNetworkコントラクトをデプロイする前に

  • 対象としているトークンコントラクトのソースコードを確認し、Raidenのしくみと相性の合わない機能が盛り込まれていないか確認しないといけません。
  • ソースコードが確認できないトークンはRaidenで使うべきではありません。
  • Solidityコンパイラの組み合わせの結果、TokenNetworkコントラクトは脆弱性を持つ可能性があります。この場合、新しいコントラクトをデプロイするためにすべてのチャネルを閉じる必要があります。(チャンネルを新しいコントラクトに引き継ぐための方法はあるかもしれません。)

結論

Raidenはステートチャネルを管理するための非常に興味深いシステムであり、活用例を心待ちにしています。

しかしRaidenの仕様定義は、Solidityのような動くターゲットではなく、Ethereumの根本的な部分に近付ける必要があるのではないかと思いました。

また、Raiden関連の実装に加えてTokenNetworkコントラクトの整合性を維持するため、対象のトークンコントラクトのソースコードも検証する必要があります。
そのためオープンソースかつ長期にわたって大きな脆弱性報告などがないものが好ましいと思われます。

以上となりますが、Lightning NetworkとともにRaidenの進捗も追っていきたいと思います。

先日公開された Raiden Network Specification もぜひ、併せて読んでみてください。

expand_less