Operation-based Merkle-CRDTの課題

1. データサイズ（DAGサイズ）が永続的に増加し続ける

永続的な履歴: 通常のCRDTは、更新情報（オブジェクト）をマージ・適用した後に破棄できます。しかし、Merkle-CRDTは過去の全てのイベント（操作履歴）をMerkle-DAGという不変のデータ構造として永続的に構築・保存し続けます

構造が薄いdagのせいで不要なリーフノードが量産してしまう，pullしてしまう

計算してみる

差分100LOC = 12KB

(半角60文字 × 1バイト) + (日本語20文字 × 3バイト) + 改行(2バイト) = 122 バイト/行

122バイト × 100行 = 12,200バイト = 約12.2 KB

100回差分を持ったら，最小で1200KB

ストレージコストの増大: イベントが発生するたびに因果情報を含むDAGが成長するため、レプリカは潜在的に非常に大きな履歴を保存し続ける必要があり、ストレージを圧迫します

同期時間の悪化: 新しいレプリカが参加する際、完全な履歴を同期する必要があります。履歴が非常に大きくなっている場合、この同期に時間がかかり、システムへの参加が困難になります。

再処理のコスト: DAGのサイズが大きくなると、過去のデータを再処理する際の計算コストも増加します。

2. 同期とマージのパフォーマンス問題

マージコスト (Merkle-Clock ソート): 2つのレプリカの状態をマージするには、それぞれのMerkle-Clock（DAGで表現された因果履歴）を比較し、どちらが新しいか、あるいは並行しているかを判断する必要があります。この比較操作は、2つのDAGが大きく分岐している（＝長期間同期されていなかった）場合、非常にコストの高い操作になる可能性があります。

同期遅延 (DAG-Syncer レイテンシ): Merkle-CRDTは、DAG-Syncerというコンポーネントを介して他のレプリカから不足しているDAGノードを取得します。このプロセスには当然ながらネットワーク遅延が発生し、リアルタイム性が求められるアプリケーションでは問題となる可能性があります。

3. 通信の非効率性

重複したデータ伝播: Merkle-DAGの仕組みにより、必要なデータ（欠けている部分）だけをpullできますが、その手前のデータ伝播にPubSubのようなゴシッププロトコルを使用すると、既に持っている情報が再度送られてくるなど、無駄な通信が発生する可能性がある

署名や証明書も使えるところがある