稳固性，如何等待第二个函数或其他解决方案

Question

我正在使用区块链为p2p能源交易项目工作。我正在自己做一个实验，为我的硕士论文演示这个概念。

对于这个项目，我有两个python脚本，一个用于prosumer (向系统提供能量的用户)，另一个用于使用者(消耗系统能量的用户)。

每个脚本都是从监视电力系统读取一个值，该值同时更新。

每当一个新的值被读取，一个新的“循环”就开始了。

它们都使用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);
        }
    }

所述附加条件是在用户从预测者切换到消费者或逆用户时作出的。

它正常工作，但我需要实现延迟(或者其他解决方案？)就在我的智能契约中的prosumer函数和使用者函数调用之前，允许变量AvailableEnergy和DemandEnergy更新为相同的“周期”，然后继续进行事务处理。大概2到3秒就够了。

解决方案是实现一个等待函数(或者其他什么？)我有任何想法)，但从我所读到的来看，这并不是通常在以太所做的事情。我读到也许我可以用“虚幻闹钟”，是否适合做我想做的事？我如何在我的智能合同中使用它？

非常感谢，阿尔班

我在使用Renix和solidity ^0.5.10。我在执行加纳奇区块链的合同。

Answer 1

在坚固的我可以在实体函数中做‘等待n秒’语句吗？中等待是不可能的。

正如您所提到的，一种解决方案是有一个离链组件，该组件将等待数据准备就绪，然后发送事务。

如果变量AvailableEnergy/DemandEnergy是通过契约中的方法更新的。另一种选择是保持请求队列，并在更新变量时处理它们。

Answer 2

等待是不可能的，而且无论复杂程度如何，您都可以将执行(在挖掘之后)看作是瞬时的。

脱链过程可能是也可能不是可以接受的，因为它意味着重新引入集中化。

要维护分散的设计，您需要设计强制调用的序列化和步调的流。例如，一个调用结束了前一个时间段，启动了一个新的时间段，并且在调用之间或可能需要等待一个或多个预定义期间的报告之间需要一定的时间间隔。

容量限制和延迟问题意味着块链可能不是像订单匹配这样的大容量角色的最佳选择，而终结性属性表明它可能是执行和解决问题的理想解决方案。

考虑会议地点(市场)、达成协议的P2P体系结构和结算合同。

1. 艾丽斯和鲍勃找到了对方，仔细研究了对方的提议。
2. 爱丽丝把资源交给鲍勃和符号。Bob向Alice提交了资源并进行了签名。他们交换承诺，签署和返回。每个人都有对方承诺的证据。他们可以相互生成一个唯一的ID，他们已经达成协议。也许还没有必要将这一点提交给链条。
3. 他们提交他们的报告与协议身份证和其他人的签字。合同可以核实对方的签字.如果协议未知，则可能使用第一个报告为其创建数据结构。

最终，该合同将拥有处理边缘案件所需的一切，比如未能在截止日期前提交报告。

这类应用程序的最大挑战之一是确保报告的真实性，因为消费和生成都是由消费者和生产者自行报告的。这等于信任记者，信任记者的测量设备。

解决这一问题的一个可能办法是在合同一级实行问责制。考虑一种在数据上签名并被授权(并负责)注册为“值得信赖”的仪表。这是经典系统的大致工作方式，因为它确实是用户站点上的一个表，报告输入/输出，并且每个人都同意信任该过程以实现计费目的。

如果多项协议和交易能够致力于一个由做市商而不是单个参与者承诺的数据结构，则可以通过散装结算进一步扩大规模，可能是在市场一级。

总的来说，这是可行的，但不是微不足道的。

希望能帮上忙。