IPFSを拡張する
関連: IPFS上に実装するとしての問題, Cryptreeの問題, データ管理プラットフォーム(draft), You are a chef,Design the Cryptree Architecuture
※これはあくまで僕の妄想の話だが可能ならば実行を試みるYudai.icon
2023/6/4
「IPFSをForkする」-> 「IPFSを拡張する」
Forkって言葉だと否定的なニュアンスな気がして、自分が行いたい事と異なる気がした
フォーク参照
下記のIPFSの関係性から拡張って言葉も違う気もしてる
もっといい言葉探すYudai.icon
前提
僕はPersonal dataとCommons dataの境界線を探っている
つまりCommons dataというのはIPFSやブロックチェーン上のデータだと考える
= Public Data
You are a chefでも書いたようにChefとしてCanned foodからBuffetにどう出すかを探る
Canned food = 暗号化と復号化が行える非公開のストレージ
Buffet = IPFSやブロックチェーン
Chef = 選択する者
上記のシステムを作る上でIPFSの問題
公開前提になっている
故に透明性がある
故にPersonal dataの管理が行えない
Personal空間が存在しない = Privacyが存在しないともいえる
ブロックチェーンに対して初めに疑問が生じた理由でもある
データの削除が行えない
故にデータが真だと証明が行える
= 検証可能性
故にデジタル空間の問題と同じで忘れられる権利が存在しない
Cryptreeの実装は分散型ストレージ上には作ることが出来ない
僕はIPFS上にPersonal空間の作成を試みた
Pipeleを開発したのはこのためである
Pipeleの問題はデータ制御に対しての柔軟性がない
アクセス許可した人を拒否するのが難しい
そこでCryptreeの論文を発見した
そこでIPFS上にCryptreeの実装を試みて問題を見つけた
IPFS上に実装するとしての問題
上記で挙げたデータの削除が行えない事はかなり大きな問題である
Xに対してデータアクセスを拒否したい場合クリーニングという元の暗号化したデータをRe-Encryptionを行う必要があるのだが、IPFSではデータそのものを更新は出来ないので、元のデータは残ることになる
つまりXはdirty keyによって元のファイルA'にアクセスが可能である
ファイルAの暗号化 => A'をRe-Encryption => A''
この仕組みはIPFSだけではなくP2Pシステムの特徴である
だからこそ改ざんや不正が行えない
どう解決するのか
IPFSを拡張する
P2Pシステムの特徴を残しつつCryptreeの実装が行えないか？
IPFSにはCIDという仕組みがある
コンテンツに対して全てIDが付与されている
IPFSのCID生成
= CIDによりコンテンツを識別可能になっている
CIDの仕組みをハックしてIPFSをフォークする
IPFS上に実装するとしての問題に少し書いてある
暗号化したコンテンツを削除することは不可能だけど、CIDが削除できればいいのではないか？
そうする事で検索不可能になり、実質削除されていると同等になるかもしれないが、どこかのNodeには残っている = Nodeに対しての攻撃で識別不可能な何かしらの実体は残っていることになる
分散すればするほどこの攻撃に対して対処することは可能 = ネットワーク効果
CIDをどう生成するのか,状態をどのように所持するのかを設計することにより実現が可能Yudai.icon
他の分散型ストレージと呼ばれるものについて調べてみよ
Areweave
状態をブロックチェーン上で管理できるようにするのは1つだ
FVMとか使える？？
独自でCIDの生成アルゴリズムを作ったとして、他とは異なるCIDが生成された場合衝突の可能性があった
IPFSのMultihashの仕組みにより衝突の回避は出来そう(CIDv1)
これでかい！Yudai.icon
ただ識別不可能性がむずすぎる
IPFSとの関係性
Commons data = IPFS,ブロックチェーン
Personal data = IPFS Fork
Personal data ->Commons data (一方向)
chatGPT.icon
私が追求しているのは、Personal dataとCommons dataの境界線です。このCommons dataとは、IPFSやブロックチェーン上のデータを指し、公開データ、すなわちパブリックデータと同義です。私が考えているのは、ある種のChefとして、Canned foodからBuffetへどのようにデータを出すかということです。ここでCanned foodは、暗号化と復号化が行える非公開のストレージを、BuffetはIPFSやブロックチェーンを指し、Chefはデータの選択者を指す。
その上で、私が作ろうとしているシステムにおけるIPFSの問題を考察しています。IPFSは公開前提であり、透明性がありますが、そのためにPersonal dataの管理が行えない問題があります。つまり、個人のプライバシー空間が存在しないという問題です。また、IPFSではデータの削除が行えないため、データの真実性を証明することはできますが、デジタル空間と同様に、忘れられる権利が存在しません。このため、分散型ストレージ上にCryptreeの実装は不可能です。
この問題を解決するために、私はIPFS上にPersonal空間の作成を試みました。そのために開発したのがPipeleです。しかし、Pipeleにはデータ制御に対する柔軟性がなく、アクセス許可した人を拒否するのが難しいという問題があります。そのため、私はCryptreeの論文を発見し、IPFS上にCryptreeの実装を試みました。
しかしながら、CryptreeをIPFSに実装しようとすると問題があることが明らかになりました。特に大きな問題は、IPFSではデータの削除が行えないことで、これは元の暗号化したデータを再暗号化する必要があるという事実から生じます。この問題を解決するために、私はIPFSをForkすることを提案します。
IPFSにはCIDという仕組みがあり、全てのコンテンツにはIDが付与され、CIDによりコンテンツを識別可能になっています。このCIDの仕組みを利用して、IPFSをフォークし、暗号化したコンテンツを削除することは不可能でも、CIDを削除することで、データを検索不可能にし、実質的に削除するというアイデアです。
私が目指すIPFSとの関係性は、Commons dataをIPFSやブロックチェーンで管理し、Personal dataをIPFS Forkで管理することです。そして、Personal dataからCommons dataへは一方向の関係性を持つようにすることです。