Sparkプロトコル徹底解説｜ステートチェーンとFROSTで実現するL2

押川拓夢 • 2026年06月20日

本記事ではSparkの仕様について、ステートチェーンや閾値署名（FROST）などの要素技術を元に徹底的に解説します。

Sparkについては2026年3月12日に開催された「ビットコインL2技術最新トレンド勉強会」で解説させていただきました。

イベント資料はこちらで公開しています。

本記事では、イベントで説明しきれなかったSparkの仕様について徹底的に解説したいと思います。

1. Sparkの超概要

Sparkでは、Spark Service Provider（SSP） と呼ばれる運営者が高速決済のためのサービス基盤を運営します。ユーザーは、自分のビットコインをオフチェーンのSpark上に移すことで、オンチェーン取引を毎回発生させることなく、高速な決済を行えるようになります。

さらに、SSPが運用するLightning Network（LN）ノードを介することで、Sparkを利用していない通常のLNユーザーに対しても送金できます。つまり、Sparkは独自のオフチェーン決済基盤でありながら、LNとの相互運用性も備えています。

また、Sparkには強制退出と呼ばれる仕組みがあります。これは、SSPがサービスを停止した場合や、不正な振る舞いをした場合でも、ユーザーがあらかじめ用意された退出用トランザクションをオンチェーンに公開することで、自分の資産をオンチェーン上に戻せるようにする仕組みです。これにより、SSPに依存しすぎることなく、ユーザーが自分の資産を守るための最終手段が確保されています。

つまり、ユーザーはLNノードを自分で運用しなくても、Spark上の秘密鍵と退出手段を保持することで、LNへの送金を利用できるようになります。

2. Sparkのトランザクションツリーの構成

Sparkはオフチェーンプロトコルですが、ビットコインオンチェーンのプロトコル・仕組みに則った設計がされています。ユーザーのトランザクション公開による強制退出や取引のアトミック性を担保するためです。

そのため、Sparkサービスは、ユーザーの資産をトランザクションツリー形式で管理しています。

2-1. ツリーの構成と各トランザクションの役割

Sparkではルートとなるトランザクション(TX)をオンチェーンに公開し、オフチェーンにトランザクションツリーを構成します。

ツリー構造を作ることで、ツリーの末端にあるトランザクションが他の末端トランザクションに与える影響を抑えることができます。

ルートトランザクション(ルートTX)
Sparkオペレーターがオンチェーン上に公開し、Sparkサービス上でオフチェーン取引を行う証拠金となるTXです。Taprootトランザクションであり、Spark参加者全員とSSPのそれぞれの鍵を合成した集約鍵でロックされています。（鍵合成の仕組みについては後述します。）
Arkと異なるのは、Sparkオペレーターの承認さえあればいつでも送金できるためSparkではラウンドの概念がなく、オンチェーン公開するトランザクションも1Sparkツリーにつき一つで済みます。

ブランチトランザクション(ブランチTX)
ルートTXとリーフTXを繋ぐための中間トランザクションです。
図2ではリーフTXが4つなので、ブランチTXの数は少ないですが、実際に運用されているSparkではリーフが膨大な数あり、それに比例しブランチTXの数も増加します。
ルートTXと同様に、そのブランチの下に連なるリーフTXの所有者達とSSPの集約鍵でロックされています。

リーフトランザクション(リーフ TX)
Sparkサービス上でそれぞれユーザーに対して資金として割り当てられるのがリーフTXとExit TXです。リーフTXはSparkサービス上でユーザー資金として割り当てられ、SSPに管理されているTXです。リーフTXをやり取りすることで、Sparkサービス上で送金を行います。リーフTXは所有者ユーザーとSparkオペレーターの鍵によってロックされています。

Exitトランザクション(Exit TX)
Exit TXは所有者ユーザーによるSparkサービスからの強制退出を実現するためのTXです。リーフTXの子トランザクションです。所有者ユーザーとSparkオペレーターによる協力で作成され、そのユーザーが退出用に保管しておきます。
ビットコインスクリプトによるロックがかかっており、その解除条件は「相対タイムロック経過後、リーフTXの所有者であるユーザーに送金」です。

3. Sparkを支える背景技術: ステートチェーン/ 楕円曲線暗号

このセクションでは、Sparkを理解する上で重要な背景技術である、ステートチェーンの仕組みや楕円曲線暗号における鍵合成や分割の仕組みについて解説します。

Sparkはステートチェーンと呼ばれる仕組みで送金を実現しています。ステートチェーンはSpark登場以前から議論されていたLayer 2技術ですが、送金の安全性や自由度に課題がありました。Sparkでは、ステートチェーンに楕円曲線暗号の特性を用いることで、それら課題の対策をしています。

本セクションでは、楕円曲線暗号の特徴について細かい部分を省いて、Sparkに関わる重要なところだけ抜き出して説明します。

3-1. (背景技術1) ステートチェーンとは？

ステートチェーンとは、特定のUTXOを使用する権利を別のユーザーに譲渡することで、オフチェーンでの送金を実現する送金方法です。最も簡単な「UTXOを使用する権利の譲渡」方法は秘密鍵の受け渡しを行うことです。

✏️

筆者はステートチェーンという名前を初めて聞いた時、新たなブロックチェーン技術か何かのような印象を受けました。しかしステートチェーンという名称は「所有状態(State)遷移の連鎖(Chain)」が元になっています。

単なる秘密鍵の譲渡では、譲渡後も前の秘密鍵所有者が秘密鍵を削除したことを保証できないため送金できてしまいます。そこで、2-of-2マルチシグを用いたステートチェーンを例に考えてみます。

2-of-2マルチシグを用いたステートチェーンの例

このステートチェーンによるオフチェーン決済サービスでは、サービス運営であるオペレーター(O)が送金の仲介者になります。

オペレーターとユーザーBで2-of-2マルチシグを作成し資金をロックする。
ユーザーBは別のユーザーCに対してマルチシグの秘密鍵を譲渡することで送金を行います。
ユーザーCはさらに別のユーザーに秘密鍵を譲渡して送金することも、オペレータの協力によりマルチシグのロックを解除し、オンチェーンで送金を行うことも可能です。

このようにオペレーターの協力によりシンプルなステートチェーンを実現することはできましたが、この方法は以下の二つの課題があります。

課題1: 前の秘密鍵所有者と運営者の共謀リスク
2-of-2マルチシグのステートチェーンにしたことにより、前の秘密鍵所有者が単独で不正な送金を行うことはできなくなりました。しかし、図3の右下のように前の秘密鍵所有者とオペレーターが共謀することで、前の秘密鍵所有者による不正なオンチェーン出金が可能になってしまいます。オンチェーン出金がされてしまった場合、現在の秘密鍵所有者であるユーザーCはオフチェーン上の資金を喪失することになります。

つまり、このステートチェーンではオペレーターが不正を行わないということを前提とする、オペレーターへのトラストが発生します。

課題2: 送金金額の柔軟性の欠如
マルチシグトランザクションの所有権をそのまま渡すためマルチシグでロックされている金額をそのまま送ることしかできません。任意の金額を送ることはできません。

ステートチェーンの実装例: Mercury Layer

Sparkはこのステートチェーンの仕組みを使った送金を行なっていますが、Sparkよりも前にステートチェーンを実装していたのがMercury Layerです。Mercury Layerについては以前に加藤さんが解説されています。

Mercury Layerではシステムとは隔離されたプログラム実行環境であるTrusted Execution Environment(TEE)の一種を用いて、共謀リスクを抑えています。しかし、任意の送金金額に調整した送金を行うことはできませんでした。そのため、記事にもあるようにLNチャネルを譲渡する用途として用いることが検討されていました。

残念ながら2026年4月時点でMercury Layerはサービスを終了しています。しかし、Mercury Layerの挑戦と失敗はSparkに受け継がれています。

3-2. (背景技術2)楕円曲線暗号の加算の特性

あまり専門性の高い数学的な内容は扱いたくないのですが、Sparkを理解するにあたって「鍵同士を足し引きする」という処理が重要になってくるため、楕円曲線の特性についてなるべく簡単に説明します。最初に要約しておくと、楕円曲線暗号において、楕円曲線上の点が公開鍵や署名になり、”点をたどる処理の回数”が秘密鍵となります。”点をたどる処理の回数”を足し引きすることで、秘密鍵同士を合成したり、複数に分けることができます。

✏️

読んでいて頭がぼーっとしてきた人、そもそもこういう数学の話が苦手な人は読み飛ばしていただくのがいいかと思います。
また、簡単にするためかなり簡略化・抽象化しているため、厳密には数学的に正しくない表現がありますがご了承ください。

楕円曲線における足し算

図4のように点P, Qを足した点であるRを求めるとします。点PQ間で直線をひき、その先で楕円曲線とぶつかる点を-Rとします。X軸中心に点-Rと線対象な点Rが点P, Qを足した点となります。

では次に、足し算を複数回繰り返した場合について説明します。

楕円曲線ごとに暗号化処理を開始する決められたスタート地点となる点Gをベースポイントと呼びます。上で説明した「楕円曲線における加算」を1回すると点2Gに辿り着きます。同様に、2回加算すると点3G、3回すると4Gに到着します。

まずは上記の図5で、点Gから点4Gに辿り着くまでの過程を追ってみてください。楕円曲線暗号ではベースポイント点Gから何回加算するかが秘密鍵になり、　たどり着いた点が公開鍵になります。つまり、上の図では”3回”が秘密鍵で、”点4G”が公開鍵です。

鍵の合成と分割
楕円曲線上の点や足し算回数を鍵として扱うと、その鍵を足し合わせたり、複数個に分けることも可能になります。

例えば、図5の楕円曲線では”3回足し算”という秘密鍵と”点4G”の公開鍵以外にも、”1回”の足し算した点である”点2G”も、”2(回)”の点である”点3G”も公開鍵ペアになり得ます。

つまり、

1回加算した点 + さらに2回加算した点 = 3回加算した点4G

のように加算する回数を足し合わせて新たに点を求めることが可能です。

それと同様の仕組みに基づき減算して点と点を分けることもできます

3回加算した点4G - 1回分の加算を戻した点 = 2回加算した点3G

Sparkではこの楕円曲線の特性を用いて鍵の合成や分割を行い、送金を実現しています。

4. Sparkにおける送金の方法

本セクションでは、Sparkにおける送金の実現方法を解説します。

Sparkにおいて、ステートチェーンと楕円曲線暗号の鍵加算・分割の仕組みがどのように利用されることで、共謀の対策と任意の金額の送金が実現されているかを説明します。

4-1. 共謀リスク対策をした送金

ステートチェーンの説明で「課題1: 前の秘密鍵所有者と運営者の共謀リスク」について説明しました。SparkではリーフTXの秘密鍵を譲渡することで送金を行います。この時、上述した楕円曲線暗号における鍵の加算と分割の仕組みを用いてこの共謀リスクを抑えています。

図7を用いて、ユーザーAからユーザーBへリーフTX（図においてTXと書かれた金庫のアイコン）を送金する手順を説明します。図7には”50”, ”100”, ”150”の数字が振られた鍵のアイコンがあります。鍵アイコンに割り振られた数字Nが「ベースポイント点GからN回加算する」つまり秘密鍵の値です。（鍵の値は送金するBTCの数量とは全く関係がなく、秘密鍵の値であるということに注意してください。）

Step1. ユーザーとオペレーターによる集約秘密鍵の生成
SparkツリーにおけるリーフTXは、そのTXの所有者ユーザーとオペレーターが協力して作成した集約秘密鍵によってロックされています。集約秘密鍵の生成にあたって、ユーザーAとオペレーターはそれぞれ秘密鍵を作ります。

例えばユーザーAが”50”という秘密鍵を作り、オペレーターは”100”という秘密鍵を作ったとします。上述した鍵の合成の仕組みにより、”50 + 100 = 150”で”150”という秘密鍵が新たに生まれます。これがユーザーAとオペレーターが生成した集約秘密鍵になります。ユーザーのリーフTXは”150”という集約秘密鍵で資金をロックされています。

Step2. ユーザーAからBへの送金処理の開始
ユーザーAからBへの送金を行う場合で送金処理を説明します。ユーザーAはユーザーBに秘密鍵”50”を渡します。また、受け取り手であるユーザーBは、自身で受金用の新たな秘密鍵”10”を生成します。ユーザーBはユーザーAの秘密鍵との差を求め、”40”の差があることを把握します。

Step3. オペレーターによる鍵調整と旧鍵の破棄
ユーザーBは差である”40”をオペレーターに対して伝えることでオペレーターはその値を元に鍵を調整し、”100 + 40 = 140”することで新たに”140”の秘密鍵を作り直します。また同時に、オペレーターは古い秘密鍵である”100”は削除してしまいます。

Step4. 鍵調整後の共謀の対策
もし、ユーザーBに対して送金が完了した後に、ユーザーAがオペレーターと共謀して出金や送金を試みたとしてもユーザーAとオペレーターが生成できる集約秘密鍵は”50 + 140 = 190”であり、”150”の秘密鍵によってロックされた資金はアンロックできません。一方で、ユーザーBとオペレーターは”10 + 140 = 150”で”150”の集約秘密鍵を作れるため、ロックされた資金を使うことができます。

✏️

鍵合成や鍵調整などの複雑な手続きを用いていますが、結局はオペレーターが鍵を削除しているという前提に対するトラストが発生します。鍵を削除していなかった場合、ユーザーAとオペレーターの共謀は可能です。

4-2. ステートチェーンにおける任意の金額送金

ステートチェーンであるMercury Layerでは、任意の金額の送金ができませんでしたが、SparkではSSPの協力によりそれを可能にしています。

Sparkユーザーは送金したい額より大きな額のリーフTXをSSPに渡すことで、SSPは「送金額のリーフTX ＋お釣りリーフTX」の2つのTXを生成し、それをSparkユーザーに渡します。

この際、SparkユーザーとSSPはアダプター署名を用いてアトミックにリーフTXの交換を行います。アダプター署名の詳細は省きますが、SparkユーザーがSSPに渡すリーフTXと、SSPがユーザーに渡す2つのリーフTXを秘密の値でロックし、秘密の値が公開されないと3つ全てのトランザクションの署名が完成しないという仕組みで実現されています。

Sparkユーザーは「送金額のリーフTX」を手にした後、上述したSparkにおける送金方法を用いて送金します。

4-3. 送受金後のSparkツリーの構成

送受金後のSparkツリー構造はどのように変わるのかが気になる人もいるかもしれません。Arkでは送金のたびにリーフにTXが連なっていく形で、ツリーの構造にも変化が起きます。しかしSparkはステートチェーンであり、あくまでツリーのリーフTXの所有権を譲渡し合っているだけです。そのため、ツリーの構造には変化は起きません。（Exit TXは例外です。詳細は後述します。）

上述した任意の金額送金のためのスワップも、SSPが所有する「送金額のリーフTX ＋お釣りリーフTX」の所有権とSparkユーザーのリーフTXの所有権を同時に交換するだけです。

5. 退出の実現方法

Sparkサービス上のユーザー資産をオンチェーンに戻すことを退出と呼びます。退出方法にはSSPの協力のもと退出する協調的退出と、SparkユーザーがSparkサービスからの避難などを目的として自分の意思のみで行う強制退出があります。

5-1. 協調的退出の方法

協調的退出はSSPと協力することで、Exit TXを用いないで退出します。強制退出と比較して早くSpark上の資金をオンチェーン上の資金に変換することが可能です。

ユーザーは引き出すリーフTX群と引き出し先オンチェーンアドレスをSSPに送信します。SSPはその情報を元にオンチェーン公開用TXを作成し、Spark上でユーザーが所有するリーフTXと交換することで、ユーザーはSpark上の資金をオンチェーン上に戻すことができます。

協調的退出の際、ユーザーがリーフTXとオンチェーンBTCの両方を取得できないような仕組みが用意されていますが、詳細は割愛します。

5-2. 強制退出の方法

強制退出とは、SSPが機能を停止した場合や、不正な振る舞いをした場合など、SparkユーザーがSSPを信頼できない状況になった際に、Spark上のユーザー資産をオンチェーン上に退避させるための最終手段です。これは、Sparkにおける最小限のセルフカストディ性を支える重要な機能です。

Sparkユーザーは、送金によってリーフTXの所有権を受け取るたびに、そのリーフTXから連なる形で、オンチェーン上に公開するためのExit TXを作成します。その後、SSPがこのExit TXに署名を加えることで、Exit TXは有効なトランザクションとなります。ユーザーは、この署名済みのExit TXを自身で保管しておきます。

強制退出を行う際、ユーザーはExit TXをオンチェーン上に公開します。ただし、Exit TXを有効にするためには、その親となるリーフTXやブランチTXもあわせてオンチェーン上に公開する必要があります。 Sparkでは、Arkとは異なり、ユーザーが別々のブランチに存在する複数のリーフTXを保有することがあるため、強制退出時に公開が必要となるトランザクション数は多くなる傾向があります。

また、Exit TXには、後述する不正リスクへの対策としてタイムロックが設定されています。そのため、Exit TXをオンチェーン上に公開した後も、タイムロックが解除されるまで、ユーザーは資金を自由に利用できません。

これらのトランザクションをオンチェーン上に公開する際の手数料は、基本的にはユーザーが負担する想定です。そのため、強制退出は手数料負担が大きく、資金を取り戻すまでにも時間がかかります。したがって、強制退出は日常的に利用する機能ではなく、SSPを信頼できなくなった場合に備えた最終的な安全装置といえます。

5-3. 相対タイムロックの減少によるユーザーによる不正リスク対策

SparkではリーフTXの所有権の移転を行うこと、Exit TXで強制退出を行うことを説明してきました。ここで問題なのは、送金によってリーフTXの所有権を移転したとして、前のユーザーがExit TXを持ち続けることができるという点です。つまり、リーフTXの前の所有ユーザーが、Exit TXをオンチェーンに公開し、資金を盗もうとする可能性があります。

その対策方法としてSparkでは、送金のたびに新たなExit TXを生成し、そのExit TXに割り当てられた相対タイムロックの値を減少させます。つまり、最新のExit TXの相対タイムロックが常に最も短い値となるため、ブロックに最も早く取り込まれるのは最新のExit TXのみです。

🤔

この仕組みを成り立たせるにはオンチェーン上に古いExit TXが公開されないかを常時監視しておく必要があります。Sparkユーザーはノードを持っていないという前提なため、それもSpark Watchtowerという機能をSparkが運用しており、Sparkが常にオンチェーンを監視し、古いExit TXを見つけた場合、Sparkが代わりに最新のExit TXを公開するという機能を用意しています。

Sparkの参照実装では、相対タイムロックが2000ブロックで、送金のたびに100ブロック減るように設定されています。しかし最大19回で減少幅がなくなるため、SSPの協力のもとリーフTXとExit TXの間に新しい中間TXを追加挿入した上で、タイムロックの巻き戻しを行います。中間TXは相対タイムロックによる待ち時間が設定されていないため、常に古いExit TXより中間TXが先にブロックに取り込まれ、古いExit TXは無効になります。この中間TXの挿入操作は所有者ユーザーとSparkオペレーターの協力により実行されます。

6.複数のSparkオペレータによる送金・TX生成の承認作業

「共謀リスク対策をした送金」や「ステートチェーンにおける任意の金額送金」でSSPによる署名の生成が行われることで送金やTXの生成が実行されると説明しました。それらのSSPによる作業は単一のSparkオペレータによって実行されるわけではなく、複数のオペレータによって承認される場合のみ実行されます。

6-1. (背景技術3) 閾値署名FROSTとは？

SparkオペレーターはFROSTと呼ばれる閾値署名技術を用いて、閾値を越える承認があった場合のみ署名が生成されるという暗号技術に基づく制約を掛けています。本記事でFROSTについて詳しくは説明しませんが、簡単に説明すると、オペレータ同士は承認用の鍵を用いてオペーレーター間で一定数の承認が得られた場合のみ署名生成が可能という暗号技術に基づいた送金可否の投票プロセスを行います。

FROSTについては以前ビットコイン研究所に記事を寄稿していただ安土さんがGBECのYoutube動画の解説がわかりやすいです。

6-2. 複数Sparkオペレータ構成の目的：カストディ回避

上述した様な複雑な仕組みを用いて複数のSparkオペレーターによる承認を行う目的は、セキュリティ対策的な意味合いもあるはずですが、カストディを回避するという理由が大きいと考えられます。

ステートチェーンではオペレーターの権限が強く、単一のオペレーターしか存在しない場合、共謀などによる悪意のある行動をオペレーターがとる可能性を拭えないため、「他者の資金を動かせてはいけない」というカストディ規制に引っかかってしまう可能性があります。そこで、複数人のオペレーターによる承認作業を暗号学的な閾値設定を行うことで、不正の難易度を上げてカストディ回避を行なっています。

ただし、複数人のオペレーターの分散性については考慮が必要となります。Sparkオペレーター同士が利害関係で結びついていた場合など、実質的には単一のオペレーター構成に近くなってしまいます。

7. SparkとLightning Networkとの関係

SparkはLightning Networkと同じLayer 2プロトコルですが、LNを代替するようなものではありません。むしろ、 LNの存在を前提として、LNを補強するようなプロトコルです。

7-1. SSPによる流動性管理の負担

送金先の相手がSparkユーザーでない場合、SparkユーザーはLNを通して相手に送金することができます。

SparkユーザーによるLN送金は、以下の手順で行われます。

LNユーザーが秘密の値である preimage を作成し、秘密の値のハッシュ値である payment_hash を含むインボイスを発行。
SparkユーザーはLN上の送金相手からインボイスを受け取る。
Sparkユーザーは payment_hash でロックしたリーフTXとインボイスをSSPに渡す。
SSPが自前のLNノードでインボイスに対する送金を行い秘密の値である preimage を取得
SSPは preimage によりロックされたリーフTXを解除し、SSPの資金になる。

反対に、Spark外部のユーザーから、LN送金で資金を受け取ることも可能です。

このように、 Spark/LN間送金のロジックは、アトミックに設計されているため、Sparkユーザーかオペレーターのどちらかが資金を受け取ることはできないようになっています。しかし、ユーザーはSSPが管理するLN上の流動性をトラストする前提が必要となります。

8. Sparkのソースコードとプロトコル標準

SparkはSparkサーバーの実装がGitHub上でオープンな実装として公開しています。これが参照実装にあたります。lightspark社以外でもSparkを利用することができ、ローカル環境やサービスとして自身で運用することも可能です。

SparkではSIP（Spark Improvement Proposals）という、BIPのようなオープンなプロトコルであるという”スタンス”をとっています。

今の所SIP-1しかなく、issueやPull Requestで提案されている新たなSIPは議論がほぼ進んでいないのが実情です。

9. Arkとの共通点とその違い

Arkとは、以下のように多くの共通点があります。

サービスプロバイダーが存在する。
ユーザーはサービスに対して資金を預け入れる。
サービスはユーザーの資金（トランザクション）をツリー構造で管理する。
ユーザーはオンチェーン上にトランザクションを公開することで、サービスから強制的に退出できる。
サービスプロバイダーを介してLN送金ができる。

これらが共通点が多くあることからも、ArkとSparkが実現しようとしているビジョンが同じであることが伺えます。できることは似ていますが、ArkとSparkは構成する技術が大きく異なります。また、SparkはArkと比較するとサービスプロバイダーに対して発生するトラスト前提が大きくなります。

以下の記事でArkに関する解説をしています。

10. まとめ

Arkが目指している様なカストディにならないLayer2での送金方法を今ある技術だけでどうにか実現したのがSparkです。一方で、Arkと比べて複雑な仕様になっており、送金にあたってサービスプロバイダーに対するトラストの発生や、SSPによるユーザー間送金内容の監視は避けられません。

特にlightspark社が提供するSparkサービスはトラストアサンプションが大きいと批判されることが多いです。lightspark社のSpark決済サービスの問題についてはまた別の記事にまとめます。

参考文献

1.Spark. TL;DR: Spark Overview. https://docs.spark.money/learn/tldr
2.Lightspark. Spark Protocol Source Code. GitHub. https://github.com/buildonspark/spark
3.Spark. Spark: Bitcoin Layer-2 Payments Infrastructure. https://www.spark.money/
4.Spark. Spark Network Status. https://www.spark.money/status
5.Lightspark. Lightspark Official Website. https://www.lightspark.com/
6.加藤規新. 「Lightsparkが発明した新しいレイヤー2：Spark」,ビットコイン研究所. https://bitcoin-research.jp/spark-statechains-evolution/
7.加藤規新. 「SparkとXverseの提携で浮かび上がる、新種のビットコインエコシステム」,ビットコイン研究所. https://bitcoin-research.jp/xverse-spark/
8.Bitcoin Magazine. Bitcoin Layer-2 Statechains. https://bitcoinmagazine.com/technical/bitcoin-layer-2-statechains

押川拓夢

慶應義塾大学院政策・メディア研究科で修士号を取得。主な研究分野はBitcoin/Lightning Network、デジタルアイデンティティー関連。また学生時代から様々なブロックチェーン・暗号資産関連企業でエンジニアとして勤務。現在は日本ビットコイン産業株式会社でリサーチャー & エンジニアとして活動中。