0

I am working on a project for p2p energy trading using blockchain. I am building an experiment on my own to demonstrate the concept for my master thesis.

For this project I have two python scripts, one for a prosumer (user that provide energy to the system) and one for a consumer (user that consume the system energy).

Each script is reading a value from a monitoring electricity system, that are updated at the same time.

Every time a new value is read a new "cycle" begin.

They are both calling the same smart contract using web3.py library, and when a new value is read from the monitoring system, they are updating two variables in the smart contract: Available Energy and Demand Energy. I have no problem doing that.

Considering that for a prosumer the value parsing into the smart contract call is positive and negative for a consumer, the smart contract know if we have a prosumer or consumer and can run the right function corresponding to it.

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);
        }
    }

The additional conditions are made in case an user switch from a prosumer to a consumer or the inverse.

It's working like it should be but I need to implement a delay (or other solution?) just before the call of the prosumer and consumer functions in my smart contract to let the variables AvailableEnergy and DemandEnergy be updated for the same "cycle" and proceed to transaction. Like 2 or 3 seconds should be enough.

The solution would be to implement a wait function (or something else? I'm up for any ideas) but from what I read this is not really something that usualy done in ethereum. I read that maybe I could use "Ethereum Alarm Clock", is suitable to do what I want to do? How can I use it in my smart contract?

Many thanks, Alban

I'm using Renix and solidity ^0.5.10. I'm doploying the contract on Ganache blockchain.

0

It is not possible to wait in solidity Can I make 'wait n seconds' statement in solidity function?.

As you mention one solution is to have an off-chain component that will wait until the data is ready and then send the transaction.

If the variables AvailableEnergy/DemandEnergy are updated by a method in the contract. Another option is to keep a queue of requests and process them when the variables are updated.

3
  • Thanks for your answer, I can't really do the queue of requests solution because there is case where the variable are not updated, for example if there is no consumer for a specific cycle there is no demand so there is no need to update the variable. – GimliA Jul 11 '20 at 6:48
  • "It is not possible to wait in solidity", is it possible with other smart contract language? – GimliA Jul 11 '20 at 6:59
  • @GimliA No, it is not possible to wait in any language compiled to run in Ethereum blockchain.The virtual machine that runs the smart contracts (EVM) lacks the required opcodes. – Ismael Jul 11 '20 at 23:08
0

It is not possible to wait and you can think of execution (after mining) as instantaneous regardless of complexity.

An off-chain process may or may not be acceptable because it implies re-introducing centralization.

To maintain a decentralized design, you need to design flows that force serialization and pacing of the calls. For example, a call that finalizes a previous time-period, starts a new one and requires a certain amount of time elapses between calls or possibly a contract waiting for reports about one or more pre-defined periods.

The capacity limitations and latency issues imply that a blockchain might not be the best choice for high-volume roles like order matching, while the finality properties suggest it might be the ideal solution for enforcement and settlement.

Consider meeting places (markets), P2P architectures for reaching agreements, and contracts for settlement.

  1. Alice and Bob find each other and peruse each other's offers.
  2. Alice commits resources to Bob and signs. Bob commits resources to Alice and signs. They trade commitments, sign and return. Each has proof of the other's commitment. They can mutually generate a unique ID the agreement they have struck. It might not be necessary to commit this to the chain yet.
  3. They submit their reports with the agreement ID and the other's signature. The contract can verify the counter-party's signature. If the agreement is unknown, then possibly create the data structure for it with the first report.

Eventually, the contract would have everything it needs to deal with edge cases like failure to report before a deadline.

One of the big challenges for this sort of application is ensuring the authenticity of the reports since both consumption and generation are self-reported by the consumer and the producer. This amounts to trusting the reporter and trusting the reporter's measuring device.

A possible solution to that problem is a system of accountability enforced at the level of the contract. Consider a meter that signs the data and is registered as "trustworthy" by someone authorized (and accountable). This is roughly how the classical system works given that it is indeed a meter on the consumers' site that reports inputs/outputs and everyone agrees to trust the process for billing purposes.

Further scaling can be achieved with bulk settlements, possibly at the level of a market, if multiple agreements and transactions can be committed to a data structure that will be committed by the market maker instead of the individual participants.

Overall, it's feasible but not trivial.

Hope it helps.

1
  • Thanks for your answer, is there somewhere to start looking for implementing an off chain process like the one I need? – GimliA Jul 11 '20 at 7:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.