---
# System prepended metadata

title: DfinityとLightning Nodeの比較表
tags: [Dfinity]

---

# DfinityとLightning Nodeの比較表

###### tags: `Dfinity`

ノードとして「Dfinity」「Lightning node」のどちらを使用すればいいかの判断材料。

比較表
早見表
評価基準: それぞれを相対的に見た大変さ・コスト

評価

◎: とてもいい

○: いい

△: 悪い

✗: とても悪い

 

カテゴリ

Dfinity

Lightning node

Dfinity詳細

Lightning node詳細

ノード

開発

◎

△

1つのDfinity上に立てるのみ。

ユーザにノードを立ててもらう。

(必要: ノードを立てるユーザへのインセンティブ設計 → Airdrop大量にする？、lightningとTotoro nodeでダブルに稼いでもらう？) 

想定HWスペック

Raspberry Pi 4 Memory 8GB

2TB SSD

(現在Lightning 550GB使用)

現在30,000のLightningのノードが立っています。以前に比べて段違いに増えています。

Umbrel OSのApplication Storeから自分達のノードが1クリックでインストールできるようにすると簡単かも。

ラズパイのスペックで自分達のノードと他のアプリが正常に動作することを担保できるか？(今のlighningのノードを立ち上げたラズパイも温度が50℃で重たくなっている。)

オペレータサーバ

開発

○

✗

単一のDfinityでオペレータサーバを運用するので、オペレータサーバ間の通信の必要はなさそう。

Dfinityが外部との通信ができないので、別途下記のオペレータは必要。

L1の情報を取ってくる

L1にコミットする

オペレータサーバを通信部分含めて設計・構築する。オペレータの情報を持ってるかどうかの同期が必要。

Lightningを一部使えそう? 

リーダ選出アルゴリズム

開発

◎

△

オペレーターサーバーがランドロビン勝手にされて規制で刺されない。

リーダ選出アルゴリズムを考える必要がある。

オフチェーンコミット

開発

◎

△

オペレータが複数のTxをまとめてブロックを作成する。

20K gasを払って 10~30分ごとにコミットする。その最に、L1Contract側でZKverifyはせず、マークルルートだけ刻む。6時間ごとに、その間に刻んだマークルルートをZKPでまとめてVerifyする。

正しいブロックを複数のノードが提案した場合や、変なマークルルートをいれた場合は、紛争を解決する。(紛争解決もContractの実装が必要)

ZKProof

開発

-

-

外部のZKProof専用のサーバを利用する。

外部のZKProof専用のサーバを利用する。

分散ストレージ

開発

△

△

データ種別ごとに、それぞれDfinityを立てて分散ストレージを利用する。

容量不足に備えて、canisterを連結する処理が必要。また分散ストレージのメモリを管理するメモリハンドラーの実装も必要。

外部の分散ストレージをいくつか取り込んだ通信プロトコルを作る(外部分散ストレージを使用する際の設計・構築)

開発コスト

開発

△

△(実装量は増えるが、相対的に見た実装難易度は普通)

Dfinityに慣れる必要がある。Dfinityの制約や内部でのルールに縛られる。外部へのアクセスもできないし、ミドルウェアも使用できないので、開発の自由度は少ない。

オペレータサーバ間の通信、リーダ選出アルゴリズム等実装が増える箇所が多々ある。その分開発の自由度は高い。

プラットフォーム上の開発のしやすさ

開発

-

-

 

 

gas代

コスト

◎

✗

gas代がICPの相場によるけど大幅に確保できる。

20K gasを払って 10~30分ごとにコミットする。

20K gasが1000円、10分ごとにコミットすると仮定する。

6000円 * 24 = 15万 / 1日。

15万 * 30 = 450万 / 1ヶ月

容量

パフォーマンス

✗

◎

8GB(canisterがアップデートしても消えないストレージとして使える部分は、実質4GB)

1TB

(ユーザが2TBのSSDを用意してくれると仮定。)

 

オペレータがglobal stateを常に持っておく必要がある。RocksDBに保存、contractのコード分の容量も占有される。

4 - 5年は、1TBで全然行けそう？最低でも4 - 5年は持つようにデータの持ち方等を設計しておく。目安ETHの3割減の容量くらい。

TPS

パフォーマンス

✗

○(△)

DfinityのStorageの取得および更新速度に依存する。

現状はかなり遅い。将来的には、storageの更新速度は、1s - 2sに落ち着くとの記載あり。

2000TPS(zksync)を超えたい。

ただユーザがクライアントサイドでZKProofを作成するので、1ユーザが行うことのできるTransaction速度は遅い。

Community

マーケティング

○

 

△(X)

現在のノードは360。

Communityと開発自体には、かなり勢いがある。

1,300ノードに達した後、ネットワークは年末までに4,300ノードを導入し、最終的には今後10年間で数百万ノードを導入する予定です。

Communityはないが、使ってる人はとても多い。

カラー

マーケティング

-

-

Dfinityが潰されると、プロジェクトも終わる。Dfinityというカラーがついてしまう。

カラーが見えない。アナーキー(無政府状態)

将来性

マーケティング

△

◎

かなりあると思う。AWSに変わるのは難しいが、Herokuくらいの立ち位置には来るのではないかという予測。

Lightning自体有望で、国家レベルでBitcoinを利用する国がどんどん出てくる可能性がある。今も含めかなり将来有望。

代償

マーケティング

○

○

Ethereum上のライバルから批判される (=> データシャード出たらそちらにデプロイするというロードマップ出してカバー。)

Lighting、Ethereumどちらからも批判される可能性がある。

総合

総合

△

○

 

 

 

別案
Dfinityでもなく、Lightningでもなく自分たちで新しくノードを立てる選択肢はありますか？

https://github.com/paritytech/substrate 等を使って開発コスト減らす等がある。

ありより。L1のネットワークに適するけれども。

https://gnunicorn.github.io/substrate-offchain-cb/  offchain workerがある。

 