The problem ZK Energy Trading Platform solves

By trading energy through this platform, each actor would get the following merits:

• an energy producer ('s smart meter) can create a sell order of a specified-amount of energy without revealing a whole amount of energy-produced.
• an energy consumer ('s smart meter) can buy create a buy order of a desired-amount of energy, which is validated and a proof is attested via a ZK program (ZK circuit).

User Interaction and Data Flow

• 1/ A energy producer's smart meter would measure a whole amount of energy avaialble.

• 2/ A energy producer's smart meter create a sell order with a specified-amount of energy.

  • 2-1/ At this point, the energy producer's smart meter would generate (prove) a proof via a ZK program (ZK circuit) off-chain.

    • During the process of generating (proving) a proof in a ZK program, it would be validated whether or not the amount of energy-created with a sell order is equal to or less than the whole amount of energy-measured by the producer's smart meter. (This is called a "constraint")
    • Once the validation (constraint) would be passed in the ZK program, a proof wold be generated and a energy producer will receive it off-chain.

  • 2-2/ Then, the energy producer would call the EnergyAggregator#createSellOrder() with a proof and public inputs as the arguments.

• 3/ A energy consumer would deposit certain amount of native ETH into the EnergyAggregator contract via the EnergyAggregator#depositNativeETH()

  • By doing so, the amount of native ETH to be send would be added to the buyer's account in the EnergyAggregator contract (buyerBalances[buyer's address]).

• 4/ The energy consumer would create a buy order with a desired-amount of energy via the EnergyAggregator#createBuyOrder().

  • At this point, if this buy order would be matched with a sell order, the EnergyAggregator contract will transfer the payment to the producer's smart meter.

• NOTE:

  • In this scenario, we assume that both a producer's smart meter and a consumer's smart meter would hold a wallet (i.e. EOA /or smart contract wallet)
  • In this scenario, an energy price would be set as a fixed-price (0.00000001 ETH / kWh). In the future, a seller and a buyer should be able to specify a dynamic price (desired-price).
  • In the step 2/ above, the remained-amount of energy goes to a home battery stroage like Tesla's Powerwall

The project architecture and development process

Actors

This project would assume the "M2M" ("machine-to-machine") interaction by following actors:

• Energy Producer's (Energy Seller's) smart meter, which has a wallet.
• Energy Consumer's (Energy Buyer's) smart meter, which has a wallet.
• Energy Aggregator smart contract

Project architcture

• Diagram of userflow

Project development process

• Installation

Product Integrations

• ZK program (ZK circuit): Implemented in zkVM / Boundless powered by RISC Zero (Written in Rust)
• Smart Contract: Written in Solidity (Framework: Foundry)
• Blockchain: Ethereum Sepolia (Testnet)

Key differentiators and uniqueness of the project

Using a ZK (Zero-Knowledge) for privacy-preserving purpose.
Particularly, in this project,

• an energy producer ('s smart meter) can create a sell order of a specified-amount of energy without revealing a whole amount of energy-produced.
• meanwhile, an energy consumer ('s smart meter) can buy create a buy order of a desired-amount of energy, which is validated and a proof is attested via a ZK circuit.