問題タブ [js-ipfs]

CID (関連) データをオンチェーンで処理する必要があり、次のワークフローに従っているプロジェクトで使用するレポをセットアップしています。

1.) CID データの確立。2.) 当該データの取引。3.) トランザクションが成功した後の IPFS へのデータの公開/インポート。

リポジトリの主な目的は、IPFS にデータをインポートせずに CID を確実に決定することです (ステップ 1)。このワークフローは、トランザクション sub 2 が完了する (または開始される) 前にデータが公開されることに基づいて、フロントランニングのリスクを回避することを目的としています。この認識されたリスクに関する私の考えは、基本的に次のようになります。

オンチェーン トランザクションの目的は、コンテンツ (NFT 素材など) を一意に識別することだけでなく、その出所を確立/決定すること、またはその作成者/(元の) 所有者と何らかの形でつながりを作成することでもあります。そのようなコンテンツを一般に公開することは明らかに、そのような取引の中心的な目的を損なうものです。追加されたデータに関するアナウンスのために、NFT（素材のようなもの）をIPFSネットワークに公開することに一般的に関与するネットワーク/特定のノードを監視し、言及された接続を自分で主張することができます.

質問:この「問題」は、私が認識しているほど実際的ですか? このリスクを軽減するための非常に限られた情報しか見つけることができませんが、1.) ガスを使用しない NFT を作成する慣行はますます一般的になり、2.) ほとんどのデータはピン留めサービスを介して IPFS に入力される可能性があります (おそらく短い発表間隔で)。ますます人気が高まっています (追加 (トランザクション前) とピン留め/アナウンス (トランザクション後) をプログラムで切り離すことができる自己管理ノードを介する代わりに)。

問題 (このエントリの主な理由): ブロック サイズを超えるコンテンツの CID を確立するのに苦労しています。

DAG ノードを作成し、それに子を追加します。

作成された DAG の Links プロパティは、ローカルの ipfs ノードから取得した DAG のプロパティと Infura から取得した DAG のプロパティに一致します (もちろん同じ内容に基づいています)。問題は、取得された DAG ノードとは異なり、作成された DAGNode のデータ フィールドが空であることです (したがって、差分 CID が生成されます)。

DAGNode が取得されました: データを含むデータ プロパティ

DAGNode が作成されました: データ プロパティが空です

私は次のようにIPFSに追加しています:

その後、(ローカル ノードと Infura ノードの両方から) DAG を so(, 作成された DAG と比較する) のように取得します。

ブロックの作業の問題に関する IPFS ドキュメントには、「特定のファイルの「ハッシュ」は、実際には DAG のルート (最上位) ノードのハッシュである」と記載されています。

DAG ノードのデータ フィールドがこれに関与していると思われるかもしれません。一方、「データ」の長さを見ると、dag.put の js-ipfs の例 (「一部のデータ」) とIPLD DAG-PB 仕様(「データが省略されているか、長さがゼロ以上")、このプロパティはより恣意的なようです。(infura とローカル ipfs ノードの両方からのデータ配列/バッファーの内容は同じです)

同じ Links プロパティだけでなく、同じコンテンツ バッファを ipfs インスタンスに追加した後に取得する DAG ルートと同じ Data プロパティを使用して、(コンテンツ バッファと CID オプションを使用して) ルート DAG ノードを作成するにはどうすればよいですか? ?

nodejsでIPFSアップローダーを構築しようとしています。ただし、同じファイルを複数回アップロードできます。デスクトップ IPFS クライアントのように重複をブロックするにはどうすればよいですか?