Energy Web Documentation
  • Energy Web Ecosystem
  • Launchpad by Energy Web
  • EWC Validator Documentation
  • Community Ressources
  • Legacy documentation
  • Welcome to Energy Web
  • Glossary
  • Solutions 2023
    • ↔️Data Exchange
      • Data Exchange Overview
      • Data Exchange Architecture
      • Use Cases and Refrence Implementations
        • Digital Spine for Electricity Markets
          • Digital Spine Integration Client Deployment Guide - from Azure marketplace
        • E-Mobility Management
    • 🔌Open Charging Network
      • Create and Manage an OCN Identity
      • Connect an OCPI/OCN Party to a Node
        • 1. Make your backend service OCN-ready
        • 2. Select an OCN Node and register in OCN Registry
        • 3. Manage your Whitelist and Blacklist
        • 4. Connect your service to an OCN Node
      • Run an OCN Node
      • Use the OCN Service Interface
        • Offer an OCN Service
        • Sign up for an OCN Service
      • Develop on the Test Network
      • Develop on the Production Network
      • Open Source Development
        • Maturity Model, Feature Roadmap and Releases
        • Developer Community Calls
      • E-Mobility Dashboard v0.1
  • EW-DOS Technology Components 2023
    • EW-DOS Overview
    • Worker Nodes
      • Worker Node Process Diagrams
      • Worker Node Architecture
      • Worker Node Guides
        • Deploy Worker Nodes
        • Customize Worker Logic
    • Identity and Access Management (IAM)
      • IAM Guides
        • Implement an SSI Hub instance
        • Verifiable Credential API
        • Sign-In with Ethereum
        • Using Switchboard
          • Switchboard Transaction Cost Estimates
      • IAM Patterns
        • Assets as Ownable Smart Contracts
        • Credential Lifecycle
        • Credential Metadata
        • SSI Credential Governance using ENS Domains
      • IAM Libraries
      • SSI Hub
      • Switchboard Application
    • Decentralized Data Hub (DDHub)
      • DDHub Message Broker
      • DDHub Client Gateway
      • DDHub Patterns
        • Channels and Topics
      • DDHub Guides
    • Green Proofs Contracts
    • Energy Web X
    • The Energy Web Chain
      • EWC Overview
      • System Architecture
        • Proof-of-Authority Consensus Mechanism
        • System Contracts
          • Name Registry
          • Holding Contract
          • Block Reward Contract
          • Validator-Set Contracts
        • Validator Node Architecture
      • Energy Web Block Explorer
      • Validator Node Installation Specifications
        • Volta Test Network: Validator Node Installation
      • Energy Web Chain Governance
      • EWC Guides and Tutorials
        • Getting started with Energy Web Chain
        • Developing on the Volta Test Network and Main Network (Energy Web Chain)
        • Run a Local RPC Node
          • Run RPC Node using Nethermind client
        • Deploy a Smart Contract on Volta with Remix
        • Interacting with Smart Contracts in EW-DOS
        • Set up MetaMask to interact with Energy Web Chain
        • Using the Ethereum Name Service
        • Using Oracles
      • Energy Web Token (EWT)
  • 🧠Foundational Concepts
    • Open-Source Software
    • Scaling Access to Grid Flexibility
    • Facilitating Clean Energy Purchases
    • Ethereum
      • Transactions and Transaction Costs
    • Self-Sovereign-Identity
      • Self-Sovereign Use Case Interaction
    • Cryptocurrency Wallets
      • Software cryptocurrency wallets
        • Metamask
        • Mycrypto wallet
      • Hardware cryptocurrency wallets
      • Hierarchical Deterministic (HD) Wallets
Powered by GitBook
On this page
  • GreenProof Diamond Implementation
  • Estimating Green Proofs Contract Gas Costs
  • Deployment costs
  • Certificate Management
  • How to optimize gas ?
Export as PDF
  1. EW-DOS Technology Components 2023

Green Proofs Contracts

PreviousDDHub GuidesNextEnergy Web X

Last updated 2 years ago

The GreenProof project by the Energy Web Foundation aims to provide a robust and flexible platform for issuing, managing, and verifying digital proofs representing clean energy certificates. To achieve this, the project employs the Diamond pattern, an innovative smart contract architecture based on the . This document presents an overview of the Diamond pattern, its benefits for the GreenProof project, and .

A modular and upgradable smart contract architecture

The Diamond pattern allows one main contract (called the diamond) to have an unlimited number of functions by separating the contract's functions into several smaller contracts called "facets." The diamond acts as a proxy contract that routes function calls to the appropriate facets (i.e., the actual subcontracts implementing the desired logic). This architecture enables a higher degree of modularity and upgradability for smart contracts by allowing users to trigger any on-chain function of any component using a single, stable smart contract address.

By implementing the EIP-2535 standard, the GreenProof core module provides an upgradable proxied system, wherein organized groups of smart contracts (facets and libraries) encapsulate different sets of functionalities into modules that can be plugged into the main GreenProof Diamond. This architecture unlocks the ability to efficiently and granularly compose the smart contract system based on the use case, allowing for seamless integration and updating of various components, enhancing the overall flexibility and adaptability of the system.

Benefits of the Diamond Pattern for GreenProof This smart contract architecture aims to achieve the following strategic objectives :

  1. Scalability: The modular nature of the Diamond pattern allows GreenProof to easily scale as more components and features are added or updated.

  2. Flexibility: Facets can be added, replaced, or removed granularly, enabling GreenProof to adapt to changing requirements in the green energy certification landscape.

  3. Maintainability: The Diamond pattern promotes a clean separation of concerns, making it easier to maintain, troubleshoot, and update the GreenProof smart contracts system.

GreenProof Diamond Implementation

To implement the Diamond pattern, the modules are composed of the following components:

contract/facets :

contracts/libraries :

contracts/interfaces :

Below is the detailed Github repository structure:

  • The DiamondCutFacet.sol contract is a facet handling all the upgrading logic. (A cut, in the diamond’s industrie, is an action resulting in new facets creation, removal. This facet will be used to add, replace or remove granularly logic to the greenProof Diamond)

Estimating Green Proofs Contract Gas Costs

We want to estimate, for each action taking place on smart contract, the cost estimation. Smart contract transaction costs can be measured on two different metrics:

  • a predictable, static computation gas consumption, which measures the computational effort required on the Ethereum Virtual Machine to execute the transaction logic

  • a dynamic cost associated to the base fee + priority transaction fees, provided to the validator nodes. This dynamic metric is related to the offer/supply balance on the network; the more traffic occurs, the highest are the required fees to have the transaction processed in priority.

A separate set of unit tests has been implemented to target each function and report the gas consumption. Below are the result of this estimation.

Deployment costs

  • Contracts deployed once (those contracts will be deployed only once by EnergyWeb and will act as on-chain libraries/modules for each new green proof instance)

E.g. for SAF and 24/7 app, we would deploy the facets for each of them once. We deploy all facets once, and any new projects which require those logic/feature will just have to connect to those deployed smart-contracts. For that purpose we need to keep track of the addresses of those facets in our backend system I guess, since we will have to reuse them.

Contract to deploy

Avg unit of gas consumption txfees = (amount of gas) * gasPrice)

AVG cost (in USD)

Cost percentage

VotingFacet

2080202

0.16

6.9 %

IssuerFacet

3259338

0.25

10.9 %

ProofManagerFacet

1537946

0.12

5.1 %

GreenproofInit

173707

0.01

0.6 %

  • Contracts deployed each time we want to set a new greenProof instance

This greeproof contract will be deployed only once for each project (i.e Quintrace). This is the main contract which will never be upgraded, and which purpose is, among others, to forward / redirect each transaction to the right sub-smartcontract (i.e facet) implementing the required logic. This greenproof contract has an internal registry mapping each function to the address of the contract which should be reached to execute this function.

So anytime we want to make an upgrade, we will send a transaction to that greenproof contract in order to change the address of the logic-contract inside the mapping / registry

At the end of the day, the greenproof contract won’t be redeployed.

(Note that we may need to deploy a new logic-contract in order to get the new address to store into the greenproof main contract. But the main one is not redeployed)

Contract to deploy

Avg unit of gas consumption

AVG cost (in USD)

Cost percentage

Greenproof (main proxy)

3993308

0.31

13.3 %

Certificate Management

The below methods will be called to perform actions on certificates.

Methods

Avg unit of gas consumption

AVG cost (in USD)

requestProofIssuance

518491

0.04

discloseData

107834

0.01

safeTransferFrom

182209

0.01

claimProof

68582

0.01

claimProofFor

81530

0.01

revokeProof

95339

0.01

Voting component

The below methods will be called to perform vote related actions.

Methods

Gas consumption

AVG cost (in USD)

addWorker

105305

0.01

removeWorker

65767

0.01

Vote

404279

0.03

How to optimize gas ?

On the smart contract level we are seeking for patterns which:

  • minimize readings and writings operation from and to the EVM storage, especially in loops

  • when possible, tightly pack data in structures

  • when possible convert external function calls into internal functions since calling external functions raises costs.

On the compiler level, the optimizer option can be enabled on the configuration file (hardhat.config or truffle.config). This option requires to set a runs parameter. From the solidity documentation:

The number of runs specifies roughly how often each opcode of the deployed code will be executed across the life-time of the contract. This means it is a trade-off parameter between code size (deploy cost) and code execution cost (cost after deployment).

Voting component : implements the voting logic, allowing the worker nodes to achieve consensus on data to be certified.

Issuer component : encapsulates the issuance logic, allowing the verification and creation of green certificates. Each certificate is represented by an ERC1155 token bound to the proof of green, resulting from the workers' decentralized consensus.

Certificate Manager component: handles certificate management features, such as claiming, revocation, inspection, and verification.

Additionally, the GreenProof core module uses the library, which offers utility contracts implementing the EIP-2535 standard specification. The following are particularly useful:

A dedicated facet is provided with the OwnershipFacet contract, which handles the implementation of the standard for the Diamond ownership.

A DiamondLoupeFacet.sol contract provides all standard for showing what facets and functions the diamond has.

The current document provides the average gas consumption for greenProof smart contracts. It uses the on the hardhat development environment. This plugin is useful in estimating how much our contracts will cost to deploy to production, and how much each transaction will cost once deployed. It can be enabled during unit testing.

Note about cost percentage: (For each transaction, the user provides into the parameter the maximum amount of gas allowed to execute this transaction. So here the % is out of this gasLimit parameter.)

Since we are using a highly modularized smart contract system (Diamond Proxy Pattern), our contracts bytecode is very reduced, which allows a high runs setting on the optimizer. (More infos on ).

VotingFacet.sol
IssuerFacet.sol
ProofManagerFacet.sol
solidState
contract libraries
IEP-173
loupe functions
Gas Reporter plugin
gasLimit
how the EIP 2535 pattern helps in code optimization
EIP-2535 standard
its implementation within the core module
GreenProof smart contracts