Bitcoin-NGやCovenantsなどの提案をしているコーネル大学の先生方が先日Teechanというオフチェーン決済のプロトコルに関するブログとホワイトペーパーを公開していたので見てみる↓
hackingdistributed.com
https://www.cs.cornell.edu/People/egs/papers/teechan.pdf
TeechanはTrusted Execution Environment（TEE）を利用したPayment Channelの実装プロトコルで、TEEを備えた２つのエンドポイント間にPayment Channelを構築する。
Trusted Execution Environment（TEE）とは
TEE＝信頼できる実行環境で、ホワイトペーパーの中ではCPUの拡張命令セットの１つであるSoftware Guard Extensions(SGX)を利用している。SGXはアプリケーションがシステムメモリ上に保護された領域を作成できる仕組み（その他のプログラムはアクセスできない）で、重要なデータをマルウェアなどから守ることを目的に最近のCPUに追加された命令セットになる。
チップにはEnclaveと呼ばれる特別な構成があり、Enclave内のメモリデータは、オフチップでは必ず暗号化されており、特殊なEnclaveコードが実行されている間のみオンチップでのみアクセスできる。
さらに復号化キー特定のハッシュを持つコードのみに有効であるため、もし攻撃者がEnclaveをハックしてそのハッシュを書き換えるても、ハッキングされたコードは暗号化キーにアクセスできなくなるため攻撃は成功しない。そのためコードの内容を自由に書き換え可能なマシンの所有者であっても、Enclaveの内容を覗いたり実行コードを変更することはできない。
またSGXハードウェアは特定のEnclaveが特定のソフトウェアディストリビューションを実行していることをリモートコンピュータに証明する機能を持つ。つまり、そのチップは”特定のハッシュを持つコードを実行していることをリモートパーティに保証する”ことができ、これがPayment Channelを構築する上で重要なファクターになっている。
SGXの詳細については、IntelのSGXの説明のホワイトペーパー参照↓
https://eprint.iacr.org/2016/086.pdf
TEEを利用するTeechanはSegwitが無くても双方向のPayment Channelを構築でき、１取引で複数回のメッセージ往復が必要なLNと違い、１つの取引は片方から１つのメッセージを送るだけで完了するというシンプルさがある。
Teechanの決済プロセス
ホワイトペーパーの４章にTeechanの具体的な決済プロセスが記述されている。
Teechanチャネルプロトコルは３つのフェーズからなる。
- チャネルの確立
- チャネル操作
- チャネルの決済
↓で、これらの３つフェーズのそれぞれで交換されるメッセージを詳細に示している。
チャネルの確立
最初のフェーズでは、アリスとボブの間で双方向のPayment Channelを確立する。今までのPayment Channelと同様、セットアップと払い戻し用のトランザクションを使ってPayment Channelを確立する。アリスとボブは2-of-2のマルチシグにBitcoinをデポジットするセットアップトランザクションを構築する。
続いてセットアップトランザクションを入力にし、アリスとボブの資金を返却する払い戻しトランザクションを構築する。払い戻しトランザクションにはロックタイムが設けられていて、将来のある時点になると利用可能になる。必ずこのロックタイムの時間より前にチャネルを閉じる必要がある。
A1
最初にアリスとボブはそれぞれのEnclaveをセットし、セットアップ及び払い戻しトランザクションを構築する。この時必要になるのが
A2
続いて、Enclave AとEnclave Bはセキュアな通信チャネルを確立し、remote attestationを通じてお互いを認証する。この時、各Enclaveは安全な乱数生成器を使って、非対称暗号の鍵ペアとランダムな秘密鍵を生成する。
アリスのEnclaveは生成した非対称公開鍵（KA）をSGXのQUOTEにバインドし、ボブに送信する。ボブは、KAで暗号化したデータはアリスのEnclaveによってのみ復号化され、Enclaveが必要なバイナリハッシュを持つEnclaveコードを実行していることを検証する。
同じことを逆方向でも行い、アリスのEnclaveもボブの公開鍵を取得する。相互検証が成功すると、Enclave AとEnclave Bははそれぞれ、KA、KBで暗号化されたデータが相手のEnclaveでのみ復号化できる状態になり、秘匿通信チャネルを確立したことになる。
A3
ボブのEnclaveはステップA1のボブのセットアップデータ（kBTC,B、UTXOB、BTCB）と一緒にランダムな秘密鍵IDBをアリスのEnclaveに提示する。アリスのEnclaveは内部的に署名付きのセットアップ及び払い戻しトランザクションを生成し、セットアップトランザクションのハッシュ（SetupHash）と払い戻しトランザクションをアリスに明かす。この時点ではアリスのEnclaveだけがセットアップトランザクションを知っている。
続いて、アリスのEnclaveはA1のアリスのセットアップデータ（kBTC,A、UTXOA、BTCA）と一緒にランダムな秘密鍵IDAをボブのEnclaveに提示する。ボブのEnclaveは内部的にセットアップトランザクションと払い戻しトランザクションを生成し、その両方をボブに明かす。ボブはセットアップトランザクションをBitcoinネットワークにブロードキャストし、チャネルを確立する。
アリスはブロックチェーン上にSetupHashと同じTXIDのトランザクションを見つけることでチャネルの確立を検知する。
以上のステップのハンドシェイクが終わると２つのEnclave間の安全な通信チャネルが確立する。
チャネル操作
Enclave AとEnclave Bの間でチャネルが確立すると、アリスとボブは資金の交換をスタートできる。この段階ではアリスもボブもBitcoinネットワークとの接続を維持する必要は無い。
B1
ボブに資金を送るため、アリスはボブに送りたい資金の量を指定して自分のEnclaveにローカルでリクエストを送る（A1）。
B2
Enclaveはオーナー（アリス）から支払いのリクエストを受信すると、送ろうとしている量が残高内かチェックする。問題なければ残高を更新し、支払いを承認するメッセージを作成する。このメッセージには、支払いを行うEnclaveのランダムな秘密鍵IDAと、更新された支払いカウンタ（初回は１）が含まれる。メッセージは非対称公開鍵KBで暗号化され、ボブに送られる。
B3
ボブはメッセージを受信するとそれをボブのEnclaveに送る。Enclaveがメッセージを受信すると、メッセージを復号化し、正しい秘密鍵かどうかとカウンタが以前提示されたものより１つ大きいものかチェックする。問題なければ残高とカウンタを更新し、ボブに残高を通知する。
B1〜B3のステップが１つのオフチェーン決済となり、決済の都度このステップを繰り返す。
チャネルの決済
Teechanプロトコルの最終段階はチャネルの決済である。このフェーズでは、Payment Channelが閉じられ、アリスとボブ間の最終的な残高を決済するトランザクションがBitcoinネットワークにブロードキャストされる。
C1
フェーズ２のいずれかの時点で、両者のいずれかがEnclaveに対して終了リクエストを送信する。
C2
Enclaveはオーナーから終了リクエストを受信すると、セットアップトランザクションでロックされた資金を現在の残高に応じてアリス、ボブそれぞれに送る決済トランザクションを生成し、kBTC,AとkBTC,Bを使って署名する。このトランザクションはホストに返されEnclave内のメモリデータは全て破棄され、実行を停止する。
C3
Enclaveから決済トランザクションを受け取ったオーナーはそれをBitcoinネットワークにブロードキャストして決済を完了する。
まとめ＆所感
- TeechanではTEEを信頼できるサードパーティとして利用していて、両者のEnclaveが信頼できるサードパーティとして機能する前提で、お互いの秘密鍵を相手のEnclaveに送っている。
- 両者のEnclaveが相手の秘密鍵も持っているので、オフチェーンでの決済は残高が合意できれば、Enclave内に相手の鍵と自分の鍵があるので、いつでもそれでトランザクションを作って署名できる（その操作を行うのは全てTEEデバイス）。
- トラストポイントを排除してきた既存のPayment Channelと違いEnclave等のTEEをを使ったトラストポイントを利用することで、作成するトランザクションはシンプルで、二者間のメッセージ交換の手間も省いている。
- LNだと両者間でシークレットから生成したハッシュの交換や鏡像となるトランザクションの交換など１つの取引で複数のメッセージ交換を必要とするのに比べ、１つの取引が１回のメッセージで完了するというのはシンプルで良い。
- 今までのマイクロペイメントチャネルだと、トラストポイントが無い形で自分のコインを保護できるが、そのためにはBitcoinネットワークを監視し相手が不正していないか検知する必要があったが、そういった監視をする必要が無くなる。
- TEEを使ったPayment Channelを構成する上で重要なのが、SGXのremote attestation機能だけど、これ現状でどれくらい使えるものなのか気になる。
- 故障なんかでenclaveのデータが読めなくなった場合ってどうなるのかね？
- あとEnclave間のリモート通信がどういうネットワークプロトコルで行われるのか気になる。
