堅固性，如何等待第二個功能或其他解決方案

我正在開發一個使用區塊鏈進行 p2p 能源交易的項目。我正在自己建立一個實驗來展示我的碩士論文的概念。

對於這個項目，我有兩個 python 腳本，一個用於產消者（為系統提供能量的使用者），一個用於消費者（消耗系統能量的使用者）。

每個腳本都從監控電力系統中讀取一個值，這些值同時更新。

每次讀取一個新值時，都會開始一個新的“循環”。

他們都使用 web3.py 庫呼叫相同的智能合約，當從監控系統讀取新值時，他們會更新智能合約中的兩個變數：可用能量和需求能量。我這樣做沒有問題。

考慮到對於產消者來說，解析為智能合約呼叫的值對消費者來說是正的和負的，智能合約知道我們是否有產消者或消費者，並且可以執行與其對應的正確函式。

function checkProsumerOrConsumer(address payable _user, int _newEnergy, int _pastEnergy) public payable {
       if(_newEnergy < 0){ //Consumer case
           if(_pastEnergy < 0){
               updateDemandEnergy(-_newEnergy, -_pastEnergy);
           }
           else if(_pastEnergy>0){
               updateAvailableEnergy(0, _pastEnergy);
               updateDemandEnergy(-_newEnergy,0);
           }
           else{
               updateDemandEnergy(-_newEnergy,0);
           }
           //Wait 3 seconds function
           consumer(_user, -_newEnergy);
       }
       else{ //Prosumer case
           if(_pastEnergy > 0){
               updateAvailableEnergy(_newEnergy, _pastEnergy);
           }
           else if(_pastEnergy < 0){
               updateDemandEnergy(0, -_pastEnergy);
               updateAvailableEnergy(_newEnergy,0);
           }
           else{
               updateAvailableEnergy(_newEnergy,0);  
           }
           //Wait 3 seconds function
           prosumer(_user, _newEnergy);
       }
   }

附加條件是在使用者從產消者切換到消費者或相反的情況下制定的。

它工作正常，但我需要在我的智能合約中呼叫產消者和消費者函式之前實施延遲（或其他解決方案？），以讓變數 AvailableEnergy 和 DemandEnergy 更新為相同的“週期”並繼續進行交易。像 2 或 3 秒應該就足夠了。

解決方案是實現一個等待功能（或其他什麼？我有任何想法），但從我讀到的內容來看，這並不是乙太坊中通常所做的事情。我讀到也許我可以使用“乙太坊鬧鐘”，適合做我想做的事嗎？如何在我的智能合約中使用它？

非常感謝， 阿爾班

我正在使用 Renix 和solidity ^0.5.10。我在 Ganache 區塊鏈上部署合約。

無法在solidity 中等待我可以在solidity 函式中聲明“等待n 秒”嗎？.

正如您所提到的，一種解決方案是擁有一個鏈下組件，該組件將等到數據準備好然後發送交易。

如果變數 AvailableEnergy/DemandEnergy 由合約中的方法更新。另一種選擇是保留請求隊列並在變數更新時處理它們。

不可能等待，您可以將執行（在探勘之後）視為即時執行，而不管複雜性如何。

鏈下流程可能會或可能不會被接受，因為它意味著重新引入中心化。

要維護分散式設計，您需要設計強制序列化和調步呼叫的流程。例如，一個結束前一個時間段的呼叫，開始一個新的時間段，並且需要在呼叫之間經過一定的時間，或者可能是一個契約等待關於一個或多個預定義時間段的報告。

容量限制和延遲問題意味著區塊鏈可能不是訂單匹配等大容量角色的最佳選擇，而最終屬性表明它可能是執行和結算的理想解決方案。

考慮會面場所（市場）、用於達成協議的 P2P 架構和用於結算的契約。

1. 愛麗絲和鮑勃找到對方並仔細閱讀對方的報價。
2. Alice 將資源送出給 Bob 並簽名。Bob 向 Alice 送出資源並簽名。他們交換承諾，簽署並返回。每個人都有對方承諾的證據。他們可以相互生成他們達成的協議的唯一 ID。可能還沒有必要將其送出給鏈。
3. 他們送出帶有協議 ID 和對方簽名的報告。合約可以驗證對方的簽名。如果協議未知，則可能使用第一個報告為其創建資料結構。

最終，契約將擁有處理邊緣情況所需的一切，例如未能在截止日期前報告。

此類應用程序的一大挑戰是確保報告的真實性，因為消費和生成都是由消費者和生產者自行報告的。這等於信任記者，信任記者的測量設備。

該問題的一個可能解決方案是在契約層面實施問責制。考慮一個對數據進行簽名並被授權（和負責）的人註冊為“可信賴”的儀表。這大致是經典系統的工作方式，因為它確實是消費者網站上的一個儀表，用於報告輸入/輸出，並且每個人都同意信任該過程以用於計費目的。

如果可以將多個協議和交易送出到將由做市商而不是單個參與者送出的資料結構，則可以通過批量結算實現進一步的擴展，可能在市場層面。

總的來說，這是可行的，但並非微不足道。

希望能幫助到你。

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