Secure Replication for Client-centric Data Stores
問題
ローカルコンピュータではなく、クラウドに保存されるようになってから、少数の大手テック企業や政府が膨大なデータにアクセスが可能である
これによりデータを悪用し、プライバシーを侵害して利益を得たり、政治的反対派を害したりする可能性がある
解決策
より分散化されたクライアント中心のアプローチ。データの主要なレプリケートはユーザーの管理下でローカルデバイスに保存される。
=> 耐久性や可用性に乏しい
結局のところ何かしらの集中型サーバーが存在することが有益である
常にオンライン状態を維持し、クライアントがこのサーバーを介して相互にデータを複製可能である
結局のところサードパーティ企業や政府が提供するpodに依存する 提案:
集中型サーバーにはデータの可溶性維持を委ねるが実際のデータへの読み取り、改変は許可しない
このシステムは「最終的な一貫性(Eventual Consistency)」が最も現実的で唯一可能な選択肢である
Strong Consistencyを追求する場合、オフラインデバイスでの更新は不可能となり、遅延が悪化する
一方Eventual consistencyを選択する場合、全操作を受信後に同一状態に収束する手段が必要
System model
プロトコルは以下の性質を満たす
Confidentiality(機密性)
アクセスを許可されたユーザーのみが読める
Integrity(完全性)
アクセスを許可されたユーザーのみが内容を変更できる
Attributability(責任追跡性)
全ての編集は誰が行なったか追跡可能
Eventual delivery(最終的配送)
正しいレプリカで受け取られた更新は最終的に全てのレプリカに届く
Stong convergence(強収束性)
同じ更新を受け取った正しいレプリカは必ず同じ状態に到達する
Termination(終了性)
全ての操作は必ず有限時間で終了する
Encrypted CRDT
単一の値を保持するデータ型
値更新時にはタイムスタンプが付与される
コンフリクト時は以下のルールで解決
タイムスタンプが大きい方を採用
タイムスタンプが同じなら値のハッシュの辞書順で大きい方
値そのものはマージされないため暗号化されたままで良い
キーと値のマッピングを保持するCRDT
実体は2つの集合からなる
観測集合(observed-set)
削除集合(removed-set)
キーに一意なidを割り当てることで、削除と再挿入を正しく扱える