Issuing certificates with the EW Origin SDK (Part II)
In this two-part series, we take a closer look at the decentralized issuance and management of renewable energy certificates.
For full context on the content below, make sure to read PART I: CERTIFICATES AS TOKENS.
The issuance process
Now that we know how the certificate is represented on-chain and how it can be transferred, claimed, and revoked, let’s take a look at the actual issuance process. At the end of the process is, as we know, a simple minting of a multi-token on-chain. But how do we get there?
In order to trust that a certificate is correct, all stakeholders have to be certain that the right number of certificates has been issued. They have to trust that the generator actually produced the specified amount of energy in the specified time frame. The blockchain by itself cannot solve this trust problem. Of course, once data is on-chain it can no longer be tempered with. But how do you make sure that the data put on-chain is actually correct? There are multiple solutions to this problem that involve various degrees of integration with trusted centralized systems.
The process that is used by most registries today looks as follows: when owners of renewable generators request certificates for a specific device and time frame, they have to provide evidence for the amount of produced electricity during that time. Based on this evidence, the issuing body issues the right number of certificates to the device owner. The standard defines what is admissible as evidence. This is actually one of the most important tasks of the standard. In most cases, the official document that energy producers get from their grid operator is used as evidence. It states the amount of electricity that came from the generator and was fed into the grid injection point. This document is typically provided on a monthly basis. After the document has been provided, usually in the form of a PDF, issuing bodies verify it and issue the requested certificates.
This means that in order to be compliant with any of the standards today, evidence has to be provided to an approved issuing body, which then issues certificates in their central registry. As a result, the easiest way to ensure a correct issuance in the Origin system is to integrate with the existing registries. Once a certificate is created in their system, we can be sure that the evidence fulfills the requirements and the user is authorized to own the certificates. It could be described as the Origin platform using an existing certificate registry as an external data oracle to mint certificates on-chain. The advantage of this approach is that the Origin platform is fully compliant with the standard while also offering all the advantages of a decentralized system after issuance.
How do you make sure that the data put on-chain is actually correct? Solutions involve various degrees of integration with trusted centralized systems. For example, in one approach the Origin platform uses an existing certificate registry as an external data oracle to mint certificates on-chain. This makes the Origin platform fully compliant with the standard while also offering all the advantages of a decentralized system after issuance.
How this works exactly can be best described using the example of Origin’s integration with the I-REC registry. To request certificates, device owners send an issuance request to the Origin platform and provide the required evidence. The request is stored on-chain but also forwarded to the I-REC registry by calling its public API. This triggers the approval process on the I-REC side, where the issuance request and evidence are evaluated. By integrating with the registry this way, the job of determining if the provided evidence is correct and fulfills the requirements of the standard is outsourced to the I-REC issuing body. Once verified, the certificate is created in the I-REC registry. Origin’s issuer module can then query the API and retrieve the certificate information. If everything is correct, the issuance request is approved and the certificates are minted on-chain. Users can choose in the issuance request to have the certificates minted to their own or some beneficiary’s account.
This approach works great in places where there are established registries like I-REC that are trusted to do the job of examining evidence and issuing certificates. And even in this case, the Origin SDK can be used to digitize the process which, in most cases, still heavily relies on email-based communication. And even though we believe this integration is very useful and should be used in many cases, we want the SDK to be as broadly applicable as possible and allow for different issuance processes. This is why we build the issuer module in a way that the evidence is abstracted away and can take many forms. Some possibilities are already surfacing in some of the projects we are conducting with different partners around the world but there are likely to be many more.
If a registry that issues certificates based on grid data can act as a source of evidence, directly minting certificates based on this data further simplifies the process. That could involve pulling data from transparency platforms with public APIs, SCADA systems, smart meters, or even small IoT devices.
One option is to ingest generation data from a grid operator. If a registry that issues certificates based on grid data can act as a source of evidence, directly minting certificates based on this data further simplifies the process. In many countries grid operators are obliged to publish the production data of bigger generation devices publicly. If such transparency platforms have public APIs, it is very easy to connect them to the Origin platform and directly issue certificates based on the provided data. A good example is the Origin SDK’s integration with the EPIAS transparency platform in Turkey: https://seffaflik.epias.com.tr/transparency/.
If it is not possible to get to grid operator’s data, another option is to get evidence from the device itself. Many big generators have SCADA systems that record production at any given moment. By connecting directly to these systems, the device’s production data could be used as evidence to issue certificates. Going a step further, it would even be possible to equip generators with small IoT devices that connect directly to the blockchain and write their meter reads on-chain. There already exist smart meters that have these capabilities built-in out of the box. If done correctly, certificates could be issued based on these signed meter reads, which could remove the need for any trust in a central system altogether. For small-scale devices that do not have any form of smart meter, one could even imagine production estimations based on device and weather data. Technically, the Origin issuer module can support all forms of evidence with minor integration work. In the end, it is only important that all stakeholders agree on a common process and trust the evidence that is provided.
In the end, it is only important that all stakeholders agree on a common process and trust the evidence that is provided.
Allowing for privacy
The only thing missing now of course is the one question that no blog post about blockchain can do without: What about privacy? Indeed, there is one big disadvantage that a blockchain-based system has over a central registry. All issued certificates and all certificate transfers can be seen by anyone who wants to (and is technical enough to read the data from the Energy Web’s block explorer: https://explorer.energyweb.org/). Generally, this should not be a problem and participants should actually benefit from increased transparency. But there might be cases where users want to issue and transfer certificates privately. One might be that the owner of the generation device does not want anyone to know the production amount in some specific time frame. This might not be as important if certificates are issued on a monthly basis but might become more relevant for hourly issuance. Another might be that brokers do not want everyone to see the specific trading amounts with some specific customer. No matter the exact reason, the Origin SDK should offer privacy if it is a desired feature by users.
To choose the right privacy approach, we first analyzed which data has to be kept private and only hide this information to forfeit as little transparency as possible. We came to the conclusion that most privacy concerns can be dealt with if the number of issued and owned certificates is kept hidden. By hiding this information, no conclusions about the produced energy volume are possible and trading volumes are concealed. The part that we have to hide on-chain, therefore, is the fungible part of the multi-token that holds the volume information.
The privacy approach that we chose to hide the volume information is based on precise proofs. It can be seen as a compromise between keeping the data private and still having some verifiable trace on-chain. When the device owner chooses private issuance in the issuance request, only the non-fungible part of the certificate is issued on-chain. The owner and volume information is stored in the private database of the Origin platform operator. To create a verifiable proof about the volume without revealing it on-chain, a hash of the data is created using precise proofs and stored in the certificate. The result is an on-chain certificate that holds information about the device and time frame but also the masked energy volume information. The advantage of using precise proofs to mask the data is that once the data is revealed (e.g., when claimed), it can be cryptographically verified that the data is correct.
Our privacy approach also allows for the transfer of private certificates between users. But as there is no volume information on-chain, the Origin platform operator has to approve the transfer to prevent double spending. It is also possible to make private certificates public. Private certificates, for example, have to be public in order to claim them. Claimed certificates have to be accessible to auditors and the public to ensure that sustainability reporting is done correctly.
Try out Origin’s issuer module
If you have made it this far, chances are you are eager to try out Origin’s issuer module yourself. You can add it to your project using npm: https://www.npmjs.com/package/@energyweb/issuer.
Find the documentation here: https://energyweb.atlassian.net/wiki/spaces/OD/overview
If you are interested in the source code, you are in luck because it is completely open source as part of the origin monorepo: https://github.com/energywebfoundation/origin/tree/master/packages/issuer.
If you are interested in the details of our privacy approach, check out our precise proof library: https://github.com/energywebfoundation/precise-proofs
