分裂狀態儲存合約
這是拆分契約設計陷阱的後續問題
背景：我將我的邏輯拆分為兩個合約 A 和 B。A 保留狀態而不是 ETH。所有狀態更改功能僅允許來自其所有者，即合約 B。合約 B 功能與公共介面（並且是付費的）。
現在一切正常。然而，隨著業務邏輯的增長，狀態合約 A 在部署期間實際上處於耗盡 gas 的邊緣——即，在 8M gasLimit 時，它僅在 solc 優化器執行 <= 1000 時才會部署，任何高於此的優化都將失敗無氣部署——這意味著我什至不能在契約 A 中添加單行函式。
我的問題是：當我的狀態結構/映射/數組彼此密切相關時，有沒有辦法進一步拆分*狀態契約。*是否有一種設計模式可以實現將狀態分離為多個合約但仍允許它們相互互動？
設置器功能怎麼樣？有沒有辦法將 setter 函式分開，但允許它們設置狀態變數？
還是有其他我不知道的聰明方法？
在我看來，國家契約太忙了。永恆儲存依賴於盡可能簡單的儲存合約。在這種情況下，它們往往不會很大。因此，尺寸因素與我有關。這可能意味著不必要的複雜性。
您可以使用庫來避免重複。
範例，對鍵集的 CRUD 操作：https ://github.com/rob-Hitchens/UnorderedKeySet
相關密鑰集之間的參照完整性：https ://github.com/rob-Hitchens/LinkedSets
有序元素：https ://github.com/rob-Hitchens/OrderStatisticsTree
還有許多其他方法可以使用庫來創建可重用的概括。使用它們的合約減少了很多複雜性。字節碼是單獨部署的，因此庫是合約大小限制的可能解決方案。
這種方法通常也更適合程式碼審查，因為可以單獨考慮庫，並且可以努力建立對它們的行為是可預測的信心。從理論上講，可靠、解決得好和易於理解的組件應該更容易推理表達應用程序的邏輯合約。尤其是當應用程序增長到增加 gasLimit 的大小時，啟用程式碼審查是值得的。
希望能幫助到你。
我已經使用庫將程式碼從我的主契約中“移出”。庫有其自身的限制，它們無法直接訪問合約儲存（您需要將引用作為參數傳遞）和訪問（您必須將函式定義為外部，公共/內部函式將被內聯）。
另一種方法是將邏輯拆分到不同的合約中，讓每個合約管理自己的儲存部分。使用某種類型的白名單只允許你的合約進行一些呼叫。