ノンカストディアルなライトニングをエンドユーザー向けにスケールさせることの難しさはウォレット事業者が一番痛感しています。これが最近の記事でも取り上げた「Nodeless Lightning（Liquid Networkを使わせるライトニングウォレットのバックエンド実装）」のようなアイデアにつながっています。
加藤 規新
加藤 規新
ライトニングウォレットのバックエンドを提供している事業者の中でもLightsparkは取引所などに対してサービスを提供しており、開発者にライトニングの発明者であるTadge Dryjaを擁していたなど特徴的な企業です。そんなLightsparkもエンドユーザー向けのライトニングセルフカストディに課題を感じていて、アンサーとして独自設計のビットコインレイヤー２を発表しました。Sparkです。
今日はSparkがどのような設計になっているか見ていきましょう。
・SparkはStatechainsが源流。Statechainsの課題をおさらい
・ArkにもインスパイアされたトランザクションツリーSpark Tree
・Sparkの今後
SparkはStatechainsが源流。Statechainsの課題をおさらい
Sparkは構造的にはStatechainsを改善していったものと見なせるので、Statechainsを復習してみましょう。Statechainsに関する過去記事を2つ貼っておきます。
加藤 規新
加藤 規新
Statechainsとは、ユーザーとStatechain Entity(SE)のマルチシグアドレスに最初に入金されたコインを、オンチェーントランザクションで新しいアドレスに送金することなく、そのアドレスを使って送金できる主体を新しいユーザーとSEの2-of-2マルチシグに移転していく技術です。ある意味、Opendimeに似ています。
btc_dakara
このとき、マルチシグといっても使用するマルチシグはシュノア署名の導入で利用可能になった、鍵を加算するタイプのマルチシグです。
これによって、最初は（ユーザーAの秘密鍵＋SEの秘密鍵①）でアンロックできたコインを、ユーザーA、ユーザーB、SEが協力することで（ユーザーBの秘密鍵＋SEの秘密鍵②）に付け替えることができるようになります。これを繰り返していくことで、最初に入金した金額の所有を移転していくことができます。
コンセプト的には比較的シンプルなStatechainsですが、欠点は主に2つあります。
1つ目はそれぞれのStatechain自体に寿命があることです。これは、過去のユーザーがSEと結託して過去の所有権を主張（オフチェーントランザクションをビットコインネットワークに配信）したときに、より最近の所有者が自身が持つRefund Transactionをネットワークに配信（異議の申し立て）できる期間を設けるためのものです。しかもこの寿命はStatechainの作成時に「作成者＝最初の保有者が出金できるまでの待ち時間」として決まってしまうため、そのStatechainがあまり使われなかったら勿体ないです。
2つ目の問題はStatechain内の処理は直列的で、コインの分割などが行えないことです（つまり、1BTCのStatechainはその1BTCを丸ごとやりとりする使い方になる）。これまでの解決策はLNなどと併用しておつりを扱ったり、複数のサイズのStatechainを扱うもので、煩雑でした。
SparkはSpark Treeという概念の導入によってStatechainsのこれらの課題を解決しています。
ArkにもインスパイアされたトランザクションツリーSpark Tree
Sparkという名称にはArk系のプロトコルに共通する「～ark」という語尾がついています。Spark自体はコベナンツを使うものではありませんが、オフチェーンのアウトプット、つまりVTXOをツリー状にして管理する構造がArkに類似しており、多少はインスピレーションを受けたと思われます。（Spark＝火花、Lightsparkという社名との共通点など、ネーミングはめちゃくちゃ上手いなと感心しました）
簡単に見ていきましょう。
さっきの図ではStatechainの寿命であるタイムロックはオンチェーンTxn0にかかっていたため、Statechain作成時点で決定してしまい時限爆弾となっていました。一方、Spark TreeにおいてはタイムロックはオフチェーンTxn1において規定されているため、Statechainが強制決済されるまでカウントダウンが始まりません。これによってStatechain強制決済時の処理を効率的に詰めることができ、1つのSparkで処理できるトランザクション数が大きくなります。
（例：従来のStatechain→寿命は作成から10000ブロック、トランザクションあたり異議申し立て期間は144ブロックに設定しているが、実際はトランザクションが不定期に発生するため、Statechainの寿命までに20トランザクションほどしか処理できなかった。一方、Sparkにおいてはこの期間を効率的に詰めることができるため、20トランザクション発生した時点でまだ{10000-(21*144)}/144＝48トランザクション詰め込める）
ただし、各ユーザーが盗難のリスクを負わずに単独で異議を申し立てられる期間は十分に取る必要があるため、「最初から決まっているStatechainの寿命」はなくなっても「強制決済時に資金を回収できるまでのユーザーあたり期間」は現実の制約を受けます。例えば資金拘束を最大100日に抑えたくてユーザーあたり異議申し立て期間を1日とした場合、そのSparkは100個のトランザクションしか処理できません。（この制約は作成時に寿命が決まる従来のStatechainにもあるので、新しい制約ではありませんが）
また、この木構造を採用することで並列処理が行えるようになり、1つのSparkの中でコインの分割、つまりおつりが扱えるようになります。処理できるトランザクション数も倍々に増えます。なので、さっきのStatechainとの比較例は正確ではなく、もっと差が開きます。
逆に、Sparkを強制決済した際にオンチェーンに放たれるトランザクション数はStatechainと比べるとかなり多くなるため、強制決済時のコスト面では不利と言えます。前述の資金拘束等の側面も踏まえると、なんとしても協調決済したいですね。
Sparkの今後
Lightsparkは今後SparkをOSSにしていくとしており、現時点では一部の顧客とクローズドアルファで試運転しているようです。これが完成したプロダクトとして世に出てくるとしても数年後かもしれません。
しかし、ライトニングのラストワンマイル問題やカストディアルなウォレットの規制対応コストを強く実感しているであるLightsparkがリソースを割いて開発していること自体には大きなコミットメントを感じます。
個人的にはそこまでしてノンカストディアルなレイヤー2として解決すべき課題なのか（そして少額をオンチェーンに戻す経済合理性はあるのか）は疑問ですが、もし仮に使いやすいものになればトランザクションの集約技術として一定の利用が見込めるかもしれません。Lightsparkは、Taproot Assetsなどのプロトコルにも対応できることに強みがあると主張しています。何より、コベナンツを必要とするArkなどとは違い、Taprootで導入されたシュノア署名のおかげで今すぐに使えるプロトコルなのが秀逸です。
これまでそれほど脚光を浴びてこなかったStatechains系の技術ですが、ひょっとすると見直されるタイミングが来ているかもしれません。
