# 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がある。
Last changed by  
 
IntMax
Intmax zkRollUp
263

Read more

intmax operator 旧仕様 (PlonK 版)

intmax の operator 側の仕様について, account や transaction の表現方法などを記載しています. Notation $\mathbb{N}$ は 0 以上の整数全体からなる集合, $\mathbb{N}{m} := [0, 2^m - 1]$ $(m > 1)$ は $m$ bits で表せる数値全体からなる集合, $\mathbb{B}{n}$ $(n \geq 1)$ はちょうど $n$ bytes のバイト列全体からなる集合, $\mathbb{B} = \bigcup_{n = 0}^{\infty} \mathbb{B}_{n}$ は任意の長さのバイト列全体からなる集合とする. $\mathbb{F}_r$ は位数 $r$ の有限体とする. $E$ は楕円曲線, $E(\mathbb{F}_r)$ は $E$ の $\mathbb{F}_r$ 有理点全体からなる集合とする. $E(\mathbb{F}r)$ 上の二項演算 $+$ をうまく定めることにより, $E$ の無限遠点 $\mathcal{O}{E}$ を単位元とする可換群の構造が入る. 楕円曲線 $E(\mathbb{F}r)$ には素数位数 $s$ の元 $B$ が存在するとし, $B$ が生成する巡回群を $\langle B \rangle := { B, 2B, \ldots, (s-1)B, sB = \mathcal{O}{E} }$ で表す. その任意の元 $G \in \langle B \rangle$ は,

9/8/2022
Dfinity まとめ

単一障害点を作らないということでDfinityを利用。 メモリは4GBで十分そう。 Dfinity上のオペレータをチューニングする。最大限パフォーマンスを引き出せるような設計とプログラムにすること。 Reply Edit Delete

8/21/2022
Dfinity benchmarkとcanisterについて

概要 benchmark A. 10回PUT(更新)処理とGET(取得)処理を行う B. 100回PUT(更新)処理とGET(取得)処理を行う 総評 スケール canisterの呼び出し canisterとコスト Reference 概要

8/21/2022
Dfinity メモリとChain key

メモリとストレージ メモリについて Chain key コスト Reference メモリとストレージ IC = canisterのメモリについて記載する。 ex. $ dfx canister --network ic status --all

8/21/2022
Read more from IntMax
Published on HackMD