dApp設計和安全問題

我正在設計一個 dApp，使用者可以在其中將他們完成的工作（文件）送出到 ipfs/swarm。為了獲得這項工作的榮譽，他們在呼叫智能合約時會參考文件的雜湊值。有哪些方法可以避免搶先攻擊（即有人為送出的工作拖釣待處理的事務、讀取文件雜湊、使用更多的氣體跳到行的最前面，並為其他人的工作獲得榮譽）？

我對狀態通道不是很熟悉，但根據我的理解，這是一種可能的解決方案（儘管那時我不得不通過協調交易來犧牲去中心化）。

該應用程序有一個聲譽組件，因此可能存在某種共識機制，如果他們被認為是欺詐性的，就會燒毀使用者的聲譽/資金。儘管這需要另一層批准/共識才能被視為“完成”工作，但我不確定如何才能檢測到欺詐行為。

有沒有我沒有看到的更簡單的解決方案？歡迎任何想法。

謝謝

編輯：我可以想像一個兩筆交易序列，其中有人送出一個整數，該整數是他們的地址（或其他東西）模數的雜湊值，然後是（一旦結算）另一個具有實際雜湊值的交易，現在可以驗證。不知道有沒有更好的。

這不是一個比您建議的更簡單的方案，但其中一些細節已經散列。您可以使用的一件事是兩步過程中的送出揭示方案（我們可以稍後通過狀態通道或批量零知識證明來改進這一點，正如您所建議的）。

您不能使用 IPFS 雜湊模發件人的地址作為承諾，b/c 領先者將可以訪問兩者並可以偽造它。

但是，您可以使用諸如內置 keccak 函式之類的單向硬度來對 IPFS 雜湊進行雜湊處理。

第一步：送出你工作的 IPFS 雜湊的密碼

mapping(uint256 => address) committedHashes;

function submitWork(uint256 _ipfsHashCommit) {
   require(committedHashes[_ipfsHashCommit] == 0, 'IPFS hash commit already submitted.');
   committedHashes[_ipfsHashCommit] = msg.sender;  
}

第二步：揭示真正的 IPFS 鏈上雜湊，但前提是你是唯一可以這樣做的人

function revealWork(uint256 _ipfsHashCommit, uint256 _ipfsHash) {
   require(committedHashes[_ipfsHashCommit] == msg.sender, 'Only original sender can reveal');
   require(keccak(_ipfsHash) == _ipfsHashCommit, 'IPFS hash does not match commit');
   // mark work as submitted here, or ready for human review, or payout occurs, etc.
}

正如您所指出的，這不是理想的 b/c，它需要為每個單獨的使用者進行兩次鏈上交易。相反，如果您是集體的一員，您可能會批量處理許多使用者的送出和揭示（作為需要驗證者的狀態通道，或獎勵工作的受信任組織），並讓他們在鏈上送出一次。

引用自：https://ethereum.stackexchange.com/questions/76409