合約 A 的功能取決於合約 B 的狀態。這兩個合約的並發性如何工作？
我在考慮一個契約依賴於另一個契約狀態的場景。
例如，可能希望通過呼叫read 函式
contract a根據目前狀態決定其下一次狀態更新。contract b``contract b但是如果發生以下情況會發生什麼：
- Alice 在 上觸發此功能
contract a。- 同時（在同一個區塊中）Bob 觸發了一個更新狀態的函式
contract b。- 當這個函式
contract a試圖從 中獲取狀態時，可能是因為 Bob 的第 2 步中的交易在 Alice 的交易之前已經執行，或者 Bob 的交易尚未執行contract b，所以狀態已經改變。contract b因此，根據 Alice 的函式和 Bob 的函式在同一個塊中執行的順序，看起來可能有兩種不同的場景。我錯過了什麼嗎？
人們如何應對這種情況？
乙太坊虛擬機沒有並發。事務和呼叫嚴格按順序執行，一個接一個。但是，您需要擔心兩個相關的事情。
首先，在發送交易和將其放入區塊之間存在時間差。在此期間，其他人可能會發送另一筆較早開採並更改狀態的交易。當他們故意這樣做時，這被稱為“搶先交易”。這是一些去中心化訂單簿設計的問題，攻擊者可以等待你的“買入”訂單並在前面偷偷插入他們自己的“買入”訂單，然後賣給你獲利。這可以通過允許交易發送者為其交易設置標準來部分緩解，因此如果狀態以某種方式改變，使他們不再希望繼續進行交易，執行將被取消。
其次是重入。這是被呼叫合約回調呼叫合約的地方。這與並發不同，因為只有一個處理流程，但它具有相似的結果，即合約作者很難提前了解處理流程是什麼。對此有各種緩解措施，例如使用互斥鎖，在呼叫不受信任的合約之前設置一個標誌並在之後清除，如果設置了該標誌，則新函式呼叫會在呼叫時恢復。
根據執行順序，您在這兩種情況下都是正確的。這被稱為前沿攻擊，許多 ERC20 代幣的批准功能都容易受到攻擊：https ://blog.smartdec.net/erc20-approve-issue-in-simple-words-a41aaf47bca6
處理它很大程度上取決於你容易受到它的影響。對於代幣，有金錢損失。對於其他契約，可能沒有那麼嚴重。
沒有萬無一失的適用於所有情況的處理方法，除了將兩個合約的訪問限制在一個地址之外，以便隨機數保證單一的執行順序。除此之外，您還可以實現類似於 OpenZeppelin 的 increaseApproval 和 reductionApproval 函式的技術，從而減輕對 ERC20 代幣的此類攻擊。