ipfs - より大きな (> 256KB) ファイルの CID の決定

Question

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

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

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

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

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

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

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

# parts of the test file cid-from-scratch.js

describe("Create DAG-PB root from scratch", function() {
    let dagNode;
    it("Creates root DAG NODE", async function() {
        this.timeout(6000);
        dagNode = await sliceAddLink(buffer, new DAGNode())
            // Comparing the length Links property of the created root node, with that retrieved from local node
            // using the same content 
        assert.equal(dagNode.Links.length, localDag.value.Links.length,
            "Expected same amount of children in created, as in retrieved DAG ")
        for (i = 0; i < dagNode.Links.length; i++) {
            console.log("Children Strings: ", dagNode.Links[i].Hash.toString())
                // Comparing the strings of the children
            assert.equal(dagNode.Links[i].Hash.toString(), localDag.value.Links[i].Hash.toString(), "Children's CID should be same")
        }
        console.log(dagNode)
    })

})

/**
 * 
 * @param {Buffer} buffer2Slice The full content Buffer
 * @param {Object} dagNode new DAGNode()
 */
function sliceAddLink(buffer2Slice, dagNode) {
    return new Promise(async function(resolve, reject) {
        try {
            while (buffer2Slice.length > 0) {
                let slice = buffer2Slice.slice(0, 262144);
                buffer2Slice = buffer2Slice.slice(262144);
                sliceAddResult = await createCid(slice, ...[, , ], 85);
                let link = { Tsize: slice.length, Hash: sliceAddResult };
                dagNode.addLink(link);
            }
            resolve(dagNode)
        } catch (err) {  reject(err) }
    })
}

/**
 * 
 * @param {Buffer} content 
 * @param {string} [hashAlg] // optional 
 * @param {number} [cidVersion] // optional 
 * @param {number} [cidCode] // optional - should be set to 85 in creating DAG-LINK
 */
async function createCid(content, hashAlg, cidVersion, cidCode) {
    hashAlg = hashAlg || cidOptions.hashAlg;
    cidVersion = cidVersion || cidOptions.cidVersion
    cidCode = cidCode || cidOptions.code
    let fileHash = await multiHashing(content, hashAlg)
    return new CID(cidVersion, cidCode, fileHash)
}

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

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

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

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

/**
 * @note ipfs.add with the preset options
 * @param {*} content Buffer (of File) to be published 
 * @param {*} ipfs The ipfs instance involved
 */
async function assetToIPFS(content, ipfs) {
    let result = await ipfs.add(content, cidOptions)
    return result;
}

// Using the following ADD options
const cidOptions = {
    cidVersion: 1, // ipfs.add default = 0 
    hashAlg: 'sha2-256',
    code: 112
}

it("Adding publicly yields the same CID result", async function() {
        // longer then standard time out because of interaction with public IPFS gateway 
        this.timeout(6000);
        _ipfsInfura = await ipfsInfura;
        let addResult = await assetToIPFS(buffer, _ipfsInfura)
        assert.equal(localAddResult.cid.toString(), addResult.cid.toString(), "Different CIDS! (expected same)")
        assert.equal(localAddResult.size, addResult.size, "Expected same size!")
    })

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

  // Differences in DAG-PB object representation in Infura and Local node!
    it("dag_get local and dag_get infura yield the same Data and Links array", async function() {
        this.timeout(6000);
        let cid = localAddResult.cid
        localDag = await dagGet(cid, _ipfsLocal);
        let infuraDag = await dagGet(cid, _ipfsInfura);
        console.log("Local DAG: ", localDag.value);
        console.log("Infura DAG: ", infuraDag.value);
        // Differences in DAG-PB object representation in Infura and Local node
        // Data is Buffer in localDag and uint8array in infuraDag  
        assert.equalBytes(await dagData(localDag.value), await dagData(infuraDag.value), 'Expected Equal Data')
        assert.equal(infuraDag.value.Links.length, localDag.value.Links.length, "Expected same amount of children")
        assert(localDag.value.Links.length > 0, "Should have children (DAG-LINK objects)")
        for (i = 0; i < localDag.value.Links.length; i++) {
            assert.equal(infuraDag.value.Links[i].Hash.toString(), localDag.value.Links[i].Hash.toString())
        }
    })

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

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

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

ipfs - より大きな (> 256KB) ファイルの CID の決定

0 に答える 0

Related

Reference