Copyright ©2018 chaintope, Inc. all rights reserved. 第31回情報伝送と信号処理ワークショップ 2ndレイヤーを中心とする ブロックチェーンの拡張と技術動向 2018/10/31 株式会社 chaintope 安土 茂亨

Copyright ©2018 chaintope, Inc. all rights reserved. 自己紹介 ● 安土 茂亨（Shigeyuki Azuchi） ● 株式会社chaintope CTO ● BitcoinプロトコルのRuby実装「bitcoinrb」 ● Open Assets ProtocolのRuby実装 「openassets-ruby」 ● Bech32のRuby実装「bech32rb」 ● 共著 「ブロックチェーン・プログラミング 仮想通貨入門」 ● ブログ「Develop with pleasure!」 https://techmedia-think.hatenablog.com/

Copyright ©2018 chaintope, Inc. all rights reserved. ブロックチェーンの課題 ● Scalability ブロックに入れられるトランザクションの容量は決まっており、現在の仕様 で処理できるトランザクションは約秒間7トランザクションと他の決済システ ムと比べて低パフォーマンス。 ● Privacy & Fungibility ブロックチェーン上に個人情報は記録されないが、どのアドレスからどのア ドレスへいくらのBitcoinを送ったということは誰もが確認できる。 法定通貨であれば、Aさんが持つ１万円もBさんが持つ１万円も等しく交換 可能だが、BitcoinではそのBitcoinがどういうアドレスを経由して送られて きたものなのか分かってしまう。 ● マイニングの寡占化 マイニングプールによるマイニングの寡占化が進み、Bitcoinの機能拡張 のコンセンサスにも影響が発生する。

Copyright ©2018 chaintope, Inc. all rights reserved. Scalabilityの課題 Block Transaction Input Output Block Block Transaction Transaction Input Output Output 約10分 約10分 トランザクションがブロックに格納されるまでに10分 1ブロックに格納可能な トランザクションのサイズは1MB ネットワークにブロードキャストされる トランザクションが増えるとなかなか ブロックに取り込まれなくなり、 手数料も高騰

Copyright ©2018 chaintope, Inc. all rights reserved. トランザクション量の推移 平均ブロックサイズの推移 メモリプール内のトランザクション数の推移 Bitcoin Cashがフォーク https://www.blockchain.com/charts より

Copyright ©2018 chaintope, Inc. all rights reserved. Lightning NetworkによるScaling

Copyright ©2018 chaintope, Inc. all rights reserved. オフチェーン決済によるスケーリング Payment Channel 資金をブロックチェーン上に固定し、固定した金額を上限として、トラストレスにオフチェー ンで決済を繰り返すためのプロトコル。 Block Block Block Block Block Block Funding Tx(on-chain) Inputs アリスの1BTC ボブの1BTC Outputs アリスとボブのマルチシグに 2 BTC Commitment Tx(off-chain) Outputs アリスに1.1BTC ボブに0.9 BTC Inputs アリスとボブのマルチシグ 2 BTC オンチェーン上にマルチシグでロックさ れたコインをインプットにし、アウトプッ トには決済時のそれぞれの残高を反 映したトランザクションを作って決済す る。 新しい決済をする場合はアウトプット の残高を更新した同様のトランザク ションを作る。

Copyright ©2018 chaintope, Inc. all rights reserved. Payment Channelのセットアップ ① アリスとボブはPayment Channelをセットアップするため チャネル決済に使用するコインをブロックチェーン上にロックす るFunding Txを作成する。 Funding Tx Inputs アリスの1BTC ボブの1BTC Outputs アリスとボブのマルチシグに 2 BTC この時点で、Funding Txは未署名で 当然ブロードキャストはできない。

Copyright ©2018 chaintope, Inc. all rights reserved. Payment Channelのセットアップ ② アリスとボブはそれぞれ秘密の値（Secret）とその値のハッシュを生成する。 　このうちハッシュだけ相手に伝える。 Secret A1 H(A1) Secret B1 H(B1) 交換 アリスが作るCommitment Tx1 Outputs アリスの鍵で入手可能な 1BTC 残り１ BTCは以下のいずれかで入手可能 ●このTxがブロックに入って 1,000ブロック経過した らボブの鍵で入手可能。 ●Secret B1が分かればアリスの鍵で入手可能。 ③ アリスとボブは相手から受け取ったハッシュを使ってFunding Txのアウト プットをインプットにしたCommitment Txをそれぞれ作り、自分の署名を付与 して相手に送る。 ボブが作るCommitment Tx1 Outputs ボブの鍵で入手可能な 1BTC 残り１ BTCは以下のいずれかで入手可能 ●このTxがブロックに入って 1,000ブロック経過し たらアリスの鍵で入手可能。 ●Secret A1が分かればボブの鍵で入手可能。 交換

Copyright ©2018 chaintope, Inc. all rights reserved. Payment Channelのセットアップ アリスが作ったCommitment Tx1 Outputs アリスの鍵で入手可能な 1BTC 残り１ BTCは以下のいずれかで入手可能 ●このTxがブロックに入って 1,000ブロック経過した らボブの鍵で入手可能。 ●Secret B1が分かればアリスの鍵で入手可能。 ボブが作ったCommitment Tx1 Outputs ボブの鍵で入手可能な 1BTC 残り１ BTCは以下のいずれかで入手可能 ●このTxがブロックに入って 1,000ブロック経過し たらアリスの鍵で入手可能。 ●Secret A1が分かればボブの鍵で入手可能。 この時点でお互いに相手が作成し相手の署名が付与されたCommitment Txを持ってい る状態になる。このTxに自分の署名を加えればTxは完成する。このTxがブロードキャス トされると、ブロードキャストしたユーザーは1,000ブロック待てばコインを入手でき、相手 はすぐにコインを入手できる。 ④ 最初のCommitment Txの交換が終わったら①で作成したFunding Txに署名してネッ トワークにブロードキャストしてチャネルをオープンする。 相手の署名済みのTxを両者 持つので、これでFunding Txを ブロードキャストした後に、 相手がいなくなってマルチシグに ロックした資金が取り戻せないと いった事態はなくなる。

Copyright ©2018 chaintope, Inc. all rights reserved. オフチェーン決済 オフチェーン決済は新しいシークレットの作成・交換し、決済の結果で残高を更 新したCommitment Txを作り自分の署名を加え相手に送る。 アリスが作るCommitment Tx2 Outputs アリスの鍵で入手可能な 1.1BTC 残り0.9BTCは以下のいずれかで入手可能 ●このTxがブロックに入って 1,000ブロック経過した らボブの鍵で入手可能。 ●Secret B2が分かればアリスの鍵で入手可能。 Secret A2 H(A2) Secret B2 H(B2) 交換 ボブが作るCommitment Tx2 Outputs ボブの鍵で入手可能な 0.9BTC 残り1.1 BTCは以下のいずれかで入手可能 ●このTxがブロックに入って 1,000ブロック経過し たらアリスの鍵で入手可能。 ●Secret A2が分かればボブの鍵で入手可能。 交換 Secret A1 Secret B1 交換 セットアップ時と違うのは前のCommitment Txを作る際に 生成した秘密の値を相手に明らかにする点

Copyright ©2018 chaintope, Inc. all rights reserved. 不正を働いた相手へのペナルティ アリスが作ったCommitment Tx1 Outputs アリスの鍵で入手可能な 1BTC 残り１ BTCは以下のいずれかで入手可能 ●このTxがブロックに入って 1,000ブロック経過した らボブの鍵で入手可能。 ●Secret B1が分かればアリスの鍵で入手可能。 この時点でアリスの残高は1.1BTCでボブの残高は0.9BTCだが、ボブが自分に有利な （ボブの残高1 BTCの）古いCommitment Tx1をブロードキャストするとどうなるか？ ボブは、Commitment Tx1がブロックに格納されて1,000ブロック経過するまで1BTCは入 手できない。ボブが1000ブロック待っている間にアリスは、もともとアリス宛の1BTCは普通 に入手でき、さらにSecret B2をこの段階では知っているので残りの1BTCも入手することが できる。つまり裏切って古いTxをブロードキャストすると相手に全資金が渡る。 ※ 但し、古いCommitment Txがブロードキャストされていないかチェーンの監視が必要。 アリスが作ったCommitment Tx2 Outputs アリスの鍵で入手可能な 1.1BTC 残り0.9 BTCは以下のいずれかで入手可能 ●このTxがブロックに入って 1,000ブロック経過した らボブの鍵で入手可能。 ●Secret B2が分かればアリスの鍵で入手可能。 Commitment Tx2のオフチェーン決 済が終わったとして、この段階でボ ブはCommitment Tx1をブロード キャストした方が自分の残高が多く 特をする。

Copyright ©2018 chaintope, Inc. all rights reserved. Payment Channelで使われるopcode 将来のある時点までBitcoinをロックするopcode ● OP_CLTV（Check Locktime Verify） 絶対時刻でロックする方法 この出力を指定ブロック高 or 指定時刻までロックする ● OP_CSV（Check Sequence Verify） 相対時間でロックする方法 この出力を持つトランザクションがBlockに含まれてから ○○ブロック経過するまでロックする

Copyright ©2018 chaintope, Inc. all rights reserved. Payment Channelのスクリプト OP_HASH160 OP_EQUAL OP_IF <アリスの公開鍵> OP_ELSE <1000> OP_CHECKSEQUENCEVERIFY OP_DROP <ボブの公開鍵> OP_ENDIF OP_CHECKSIG 残り１ BTCは以下のいずれかで入手可能 ●このTxがブロックに入って1,000ブロック経過したらボブの鍵で入手可能。 ●Secret B1が分かればアリスの鍵で入手可能。 OP_CHECKSEQUENCEVERIFY（OP_CSV）はこのアウトプットのトランザクションが ブロックに格納されてから指定時間（ block height or unix timestamp）まで、アウトプット のコインをロックする相対的なタイムロックの仕組み。

Copyright ©2018 chaintope, Inc. all rights reserved. Payment Channelのクローズ Payment Channelをクローズする方法は以下の2通り。 ● 最新のオフチェーン決済のCommitment Txをブロードキャストする。 この場合、ブロードキャストした側はコインを入手できるようになるまで 1,000ブロック待たなくてはならない。 ● 協力して最新の残高で各ユーザーのアドレスにコインを送るClosing Txを 作成し、ブロードキャストする。 Closing Tx Outputs アリスに1.1 BTC ボブに0.9 BTC

Copyright ©2018 chaintope, Inc. all rights reserved. 第三者を経由した決済 Payment Channelを使ったオフチェーン決済をするには、チャネルを開くためにコインを ロックする必要があり、たくさんの人とチャネルを開けば開くほど、たくさんのコインがロック されることになる。実際に取引に使用するより多くのコインがロックされて動かせなくなるの は問題。 HTLCs（Hashed Time Locked Contracts） シークレットの交換とタイムロックの仕組みを利用して、第三者を信頼することなく 第三者を経由した決済を可能にするプロトコル

Copyright ©2018 chaintope, Inc. all rights reserved. HTLCsを利用した決済 Secret C H(C) アリスが作るHTLC Tx Outputs １ BTCは以下のいずれかで入手可能 ●Secret Cがあればボブの鍵で入手可能 ●14日経過したらアリスの鍵で入手可能 Inputs アリスの 1 BTC ボブが作るHTLC Tx Outputs １ BTCは以下のいずれかで入手可能 ●Secret Cがあればキャロルの鍵で入手可能 ●10日経過したらボブの鍵で入手可能 Inputs ボブの 1 BTC ① キャロルがランダムなシークレットCを生成しそのハッシュをアリスに共有する。 ②アリスはH(C)を使ってボブに条件付きで コインを支払うTxをブロードキャストする。 ③ボブはH(C)を使ってキャロルに条件付きで コインを支払うTxをブロードキャストする。

Copyright ©2018 chaintope, Inc. all rights reserved. HTLCsを利用した決済 ③ キャロルはボブがブロードキャストした HTLC Txをインプットにし、シークレット Cと 　自分の署名でボブのコインを入手する Txを作成しブロードキャストする。 キャロルが作る償還 Tx Outputs キャロルのアドレスへ 1 BTC Inputs ボブのHTLC TxのUTXO 1BTCを Secret Cとキャロルの署名で入手 ボブが作る償還 Tx Outputs ボブのアドレスへ 1 BTC Inputs アリスのHTLC TxのUTXO 1BTCを Secret Cとボブの署名で入手 Secret C Secret C ④ ボブはキャロルがブロードキャストした TxからシークレットCが 　分かるので、これを使ってアリスの HTLC Txのコインを入手する。

Copyright ©2018 chaintope, Inc. all rights reserved. HTLCsを利用した決済 ● キャロルが1 BTCを受け取らないとシークレットCは明らかにならない。 ● シークレットCが明らかになれば、ボブはアリスから1 BTCもらえる。 ● キャロルがシークレットCを明らかにせず、1 BTCを受け取らなかったら、 ボブは１０日待てば自分のコインを取り戻せる。アリスも14日待てば取り戻せる。 ● アリス（14日） > ボブ（10日）のタイムロックの関係で、ボブがキャロルにコインを 支払ったが、アリスからコインをもらえないという状況が発生しない仕組みを実現。 OP_CHECKLOCKTIMEVERIFY（OP_CLTV）は このアウトプットのコインを指定時間（ block height or unix timestamp）までロックするタイムロックの仕組み。 OP_HASH160 OP_EQUAL OP_IF <ボブの公開鍵> OP_ELSE <ロック日時> OP_CLTV OP_DROP <アリスの公開鍵 > OP_ENDIF OP_CHECKSIG

Copyright ©2018 chaintope, Inc. all rights reserved. 現在のLightning Network

Copyright ©2018 chaintope, Inc. all rights reserved. Lightning Networkの課題と取り組み

Copyright ©2018 chaintope, Inc. all rights reserved. Lightning Networkの課題 Lightning Networkのコア機能であるPayment Channelは、参加者の資金をオンチェーン上で二者間のマ ルチシグにデポジットし、そのデポジットした資金を原資としてオフチェーンで高速決済をするプロトコルで ある。 またHTLC（Hashed Time-Locked Contract）でチャネル間をリンクすることで、第三者を経由したオフ チェーン決済も可能になる。このような LNのプロトコルには現在以下のような課題がある。 ● Channel上の資金の流動性 プロトコルの特性上、（１）ネットワーク上に多くのチャネルが存在し、（２）多くのユーザーと決済可能 な中継ネットワークが構成され、それが維持される必要がある。 このため1次レイヤーのプロトコルとは違い、そのスケーラビリティは LN上の状態に大きく依存する。 ○ ルーティングアルゴリズムの改善 ○ ネットワーク・トポロジーの最適化 ● ユーザーが利用するにはまだハードルが多い ○ 不正なChannel状態のブロードキャストに対する監視 ○ チャネル状態のバックアップ ○ まだβ段階でありプロトコルも複雑であることから、技術的な背景が分からないユーザーにとっ ては敷居が高い ■ チャネルとは何か？ ■ 誰といついくらのチャネルを開けば良いのか？

Copyright ©2018 chaintope, Inc. all rights reserved. 課題に対する取り組み オフチェーン決済を効率的に行うためには、チャネルのライフタイムを長くし、様々な経路を使って誰とでも 決済できる状態を維持する必要がある。 1次レイヤーのプロトコルとは違い、スケーラビリティは LN上の状 態に大きく依存する。現在これらの安定性の向上や、ユーザーの利便性向上のため以下のような改善の 取り組みが行われている。 ● Payment Channelへ資金のトップアップ（Splicing） ● 複数のPayment Channelを経由したアトミックな支払い（AMP） ● Payment Channelのコントラクトの簡易化（eltoo） ● Payment Channelの状態のバックアップとリカバリー （Data Loss Protection） ● Payment Channelのバックアップの委任（Olympus Server） ● 不正なチャネル状態のブロードキャストの監視（Watchtower） ● チャネル管理の自動化（autopilot） 上記のような新しい提案や議論は Lighting Networkの開発者ML （https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev）で行われ、仕様の標準化は BOLT （https://github.com/lightningnetwork/lightning-rfc）というGithub上のプロジェクトで行われている。

Copyright ©2018 chaintope, Inc. all rights reserved. Atomic Multi-Path Payments LNにおけるチャネル１つ１つのキャパシティはあまり大きくなく、送金額が少し大きくなると送信先のノード まで、その額を送信可能なキャパシティを持つ経路が存在しないケースが懸念される。このようなケースに おいて、複数のチャネル決済を組み合わせ、１つ１つのチャネルの決済は送金額に満たないものの、その 合計で送金額を満たし、複数チャネルの送金をアトミックに実現するプロトコルが Atomic Multi-Path Payments。 アリスからボブに２つのチャネル（ 5 BTC, 1BTC）を使って6BTCを送金する BP = s1 ^ s2 ① ベースプリイメージBPを作成し、xorを計算してBPが 得られるような値s1, s2を得る。 （秘密分散の意図） 使用チャネル数 n = 2 送金額 V = v1(5) + v2(1) アトミック決済用の一意の ID ②部分プリイメージ ri = H(BP || i) と 各チャネルで使用するペイメントハッシュ hi = H(ri) を計算する。 hop payload （ID, n, s1） hop payload （ID, n, s2） hop payload （ID, n, s2） hop payload （ID, n, s2） hop payload （ID, n, s1） ③各チャネルでhiのプリイメージが分かれば資金を入手で きるHTLC決済をスタートする。 ※必ず経路毎に異なるプリイメージを使用する。 各ホップのペイロードには、AMPの使用を 通知するfeature bitがセットされる。 BP = s1 ^ s2 ④ボブは全ての部分支払いを受信し、 そのsiを全て集めてBPを復元する。 BPを復元できたら、各チャネルの支払いを 受け取るのに必要な riを算出できる。

Copyright ©2018 chaintope, Inc. all rights reserved. チャネルへのチャージ/引出しを行うSplicing チャネルを利用したオフチェーン決済は、デポジットされたキャパシティの範囲内で行われ、キャパシティを 超える決済や残高が 0になった参加者からのそれ以上の決済はできない。このようなユースケースにおい て、チャネルへの資金のチャージ（ Splic-in）及び取り出し（Splice-out）をする仕組みがSplicing。 【Splice-in】 両者は、資金をチャージしたいユーザーのオンチェーン上の UTXOと、既存のチャネルの Funding Txのア ウトプットをインプットとした、新しい Funding Txを作成しチャネルを移行する。新チャネルの初期状態（残 高）は、旧チャネルの最終残高に、新しく追加した UTXOの資金を加えたものになる。 この新しいFunding Txは旧チャネルのセトルメントと新チャネルのファンディングを担う。 新しいFunding Txの作成中や、それがブロックで承認されるのを待つ間も、新旧両方のチャネルで（旧チャ ネルのキャパシティの範囲内で） Commitment Txを更新することで、ダウンタイムを極力減らしてオフ チェーン決済を行うことができる。

Copyright ©2018 chaintope, Inc. all rights reserved. チャネルへのチャージ/引出しを行うSplicing 【Splice-out】 両者は、既存のチャネルの Funding Txのアウトプットをインプットとした、新しい Funding Txを作成しチャネ ルを移行する。この新しい Funding Txのアウトプットにはチャネル用のマルチシグアウトプットと、引出し用 のアウトプットが存在する。新チャネルの初期状態（残高）は、旧チャネルの最終残高に対し、引出し分を 差し引いた状態になる。新しい Funding Txの作成中や、それがブロックで承認されるのを待つ間も、新旧 両方のチャネルで（旧チャネルのキャパシティの範囲内で） Commitment Txを更新することで、ダウンタイ ムを極力減らしてオフチェーン決済を行うことができる。 現状のSplicingの仕様では、チャネルクローズが発生するため、 Splicingによりチャネルは維持され、経路 も有効であることを他のノードに認識させる必要がある。 また、LNでのSplicingの仕様はまだ確定した訳ではないため、新しい仕様が提案される可能性もある。

Copyright ©2018 chaintope, Inc. all rights reserved. Watchtower LNのペイメントチャネルでは、悪意ある取引相手が古い状態（残高）の Commitment Txがブロードキャスト した場合に、予め設定された期間内に対抗する Justice Txを作成・ブロードキャストし自身資金を保護する 必要がある。スマートフォンウォレットなど電波によりオフラインになる可能性があり、チェーンの監視が難 しい場合に、Watchtowerを利用して監視および Justice Txのブロードキャストをアウトソースする。 OP_IF OP_ELSE OP_CSV OP_DROP OP_ENDIF OP_CHECKSIG Old Commitment Tx Encrypted Blob key, blob Hint TXID Encryption Key Hint Watchtower 状態が更新されると、古い Commitment TxのTXIDの先頭 16バイトをHintとし、後半16バイトを暗号鍵として使用する。 Justice Txを構成するために必要な情報 （script template,送信先アドレス、署名など）を Encryption Keyを使って暗号化。 Hintと暗号化BlobをWatchtowerに送信 Block Tx Tx Tx Block Tx Tx Tx Block Tx Tx Tx Block Tx Tx Tx チェーン上のTXIDの先頭16バイトがHintと合致するチェックする。 合致した場合、残りの 16バイトを鍵として、Encrypted Blobを復号し、 Justice Txを構成しブロードキャストする。

Copyright ©2018 chaintope, Inc. all rights reserved. Olympus Server Lightning Walletで開発されている、LNのメンテナンスを 目的としたヘルパーサーバーの実装 https://github.com/btcontract/olympus ● よく知られている取引所を定期的にポーリングし、取引価格を集計。 ● ウォレットがペイメントチャネルを開く際に利用する、公開中のLNのリストのメン テナンス。 ● LNのネットワークグラフをトラバースし、部分的なペイメントルートを提供。 →モバイルウォレットがネットワークグラフをローカルに維持する負担の軽減に。 ● 暗号化したペイメントチャネルのバックアップの保存※ ● 払い戻しトランザクションのスケジュール実行※ Commitment Txをブロードキャストし、チャネルを強制的にクローズした場合、資金を償還するまで 指定時間ロックされるが、この間にモバイルデバイスなどが利用不可能になると資金を失うため、 ロック期間経過後、払い戻しトランザクションをブロードキャストするための仕組み。 ※ これらのサービスの利用する際は、 APIコール毎にストレージトークンの支払いが必要になる。 Lightning Walletが最初にペイメントチャネルを開設すると、自動的に LNの支払いがOlympusに対して行 われ、50個のストレージトークンが得られる。

Copyright ©2018 chaintope, Inc. all rights reserved. Data Loss Protection 現在のLNのPayment Channelでは古い状態のCommitmet Txをブロードキャストすると、ブロードキャ ストした側の資金が全て没収されるペナルティの仕組みが導入されている。 Commitment Tx 1 Commitment Tx 2 Commitment Tx 3 Commitment Tx 4 Commitment Tx 5 Commitment Tx 1 Commitment Tx 2 Commitment Tx 3 Commitment Tx 4 Commitment Tx 5 各Commitment TxとRevocation Keyは各ユーザーがそれぞれ保管・ バックアップする必要がある。 悪意がなくても、最新の状態がバックアップできてない状態でリカバリーする とウォレットは古い状態の Commitment Txが最新であると認識してしまう。 ※ この状態でCommitment Txをブロードキャストすると、 　意図せず相手に全ての資金が渡ることになる。 node node channel_reestablish Data Loss Protection チャネルを再接続する際に最後に受信した相手の commitment_secretと自身の最新のcommitment poinを送信 することで、自分と相手の間の最新状態の情報を共有すること で、誤って古い状態のCommitment Txのブロードキャストを防 ぐための仕組み。 your_last_per_commitment_secret my_current_per_commitment_point 相手が自分より大きなコミットメント番号を持っている場合、 相手の状態の方が新しいので、相手に最新のCommitment Txのブロードキャストを依頼する。 ※この共有により相手が自分より低い状態であることが 分かると、それを利用して悪意ある行動をする可能性がある。 これは相手が本当に正しい状態番号を申告している保証が なく、自身の全資産を失うリスクを負って行うかという問いなる。

Copyright ©2018 chaintope, Inc. all rights reserved. チャネル管理を自動化するautopilotモード ユーザーにとっては、どのノードとチャネルを開き、いくらデポジットすべきか考え るハードルが高いが、lndで実装されているautopilotを有効にするとAgentの設 定に従ってチャネルが自動管理される（デフォルトで５つのノードとチャネルを開 く）。 Agent ? Channel Update Channel Close Channel Open チャネルの状態の更新がトリガーとなり Agentが稼 働 ● 新しいチャネルを開くべきか？ ● 開く際のキャパシティは？ Configuration ● 最小・最大チャネルサイズ ● チャネル数の制限 ● チャネルに割り当てるウォレット内の 資金の割合 ※スケールフリーなトポロジーでは、ホップ数が少なくなる反面、 一部のノードに負荷が集中する。最適なルーティングアルゴリズム およびネットワーク・トポロジーに関しては今後も研究が必要。 ネットワークグラフのノードの稼働時間、アウトバウンドチャネル容 量、チャネルの帯域幅、特定の目的地への接近性といったパラメータ からルーティングノードが尺度を算出し、安定性が高く安価に決済で きるゲートウェイノードとチャネルを開設する。

Copyright ©2018 chaintope, Inc. all rights reserved. SIGHASH_NOINPUT インプットが参照する前のトランザクションのアウトプットの情 報が全て空になる。 署名はトランザクションの OutPointにコミットしなくなり、 署名後にインプットが参照する OutPointの変更が可能にな る。 eltooなどを実装するために提案されている新しいSIGHASH_TYPE https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki （※ SIGHASH_TYPEはトランザクション署名時に署名スコープを指定するための仕組み） Txの署名対象データ【 BIP-143】 nVersion hashPrevouts（全入力のOutpointから生成したハッシュ） hashSequence（全入力のsequenceから生成したハッシュ） outpoint（署名対象の入力の Outpoint） scriptCode value（署名対象の入力が持つコインの量） nSequence（署名対象の入力の sequence） hashOutputs（全出力から生成したハッシュ） nLocktime sighash type 空（0x00） 署名済みTx Input Output TxA Input Output TxB Input Output 変更可 ※ リバインド可能なのは同じ witness要 素でアンロック可能な UTXOのみ

Copyright ©2018 chaintope, Inc. all rights reserved. eltoo 既存のLNのペイメントチャネルは両者が条件が対称となるCommitment Txを作成 しオフチェーン決済を行い、古いCommitment Txがブロードキャストされると、ブ ロードキャストしたユーザーの資金が全て没収されるタイムロック＋ペナルティ型の モデルを採用している。eltooではこのコントラクトを簡素化し、ペナルティ型ではな く、最新の状態を後から適用可能なモデルのコントラクトを構成する。 セトルメント鍵ペアAs アップデート鍵ペアAu セトルメント鍵ペアBs アップデート鍵ペアBu チャネルを開く前に各参加者はチャネル用に 2つの鍵ペアを生成する。 セトルメント鍵ペアは、チャネルを最終残高で閉じる際に使用する鍵で、アップデート鍵ペアはチャネ ルの状態を更新する際に使用する鍵。 eltooでは、チャネルオープンに使用した Funding TxのUTXOをインプットとしてペイメントチャネルを 構成するのには変わりないが、チャネルの最新状態を表した Txさえ保持しておけば、古い状態がブ ロードキャストされても、そのトランザクションを最新状態を表す Txに置換することができる。

Copyright ©2018 chaintope, Inc. all rights reserved. eltooのチャネルセットアップ

Copyright ©2018 chaintope, Inc. all rights reserved. eltooのオフチェーン決済