| Literature DB >> 35911091 |
Annegret Henninger1, Atefeh Mashatan1.
Abstract
The heterogeneous and decentralized nature of renewable energy sources is too much to handle for traditional and centralized IT grid infrastructure. Blockchain technology can address many of the associated challenges. This paper provides an overview of the state-of-the-art technology layers of grid system infrastructure, a proposed future state using blockchain technology, and gap analysis. The paper also contributes a set of architectural requirements for a blockchain-enabled future state and a proposed hybrid architecture using blockchain technology, verifiable credentials, and smart contracts. This architecture can uniquely support the technology layers critical to renewable energies, including system architecture, registries, grid management, billing, privacy, and interoperability.Entities:
Keywords: IT architecture; IT infrastructure; P2P; blockchain; decentralized IDs (DID); grid management; microgrid; renewable energy; smart grid; verifiable credentials (VC)
Year: 2022 PMID: 35911091 PMCID: PMC9195073 DOI: 10.3390/jrfm15050191
Source DB: PubMed Journal: J Risk Financ Manag ISSN: 1911-8066
Figure 1Hybrid Approach to Energy Distribution.
Figure 2Decentralized Communication in a VC-Centric System.
Architecture requirements and the VC approach.
| Architecture Requirements | VC Handling of Requirements | |
|---|---|---|
|
| ||
| 1. Framework identity requirements | ||
| a. | Supported universal DIDs for organizations, users, and digital assets. | VCs will use DIDs to identify the issuers, recipients, and payload data and use DIDs for assets, tasks, and transactions. |
| b. | Standards that map multiple blockchains and centralized system-specific identities to the DID that uniquely represents a digital asset across various systems. | VCs will have a DID method specification that identifies a DID across systems. The adapter and agent for each system will be responsible for the system-specific mapping information in the DID method-specific data. |
| 2. Framework security and privacy requirements | ||
| a. | Mechanisms for private or confidential transactions between different systems. | Using P2P communication with encrypted VC payloads ensures private transactions. |
| b. | Mechanisms for maintaining transaction privacy in cross-system transactions. | Using P2P communication with encrypted VC payloads ensures private transactions. |
| 3. Framework interoperability requirements | ||
| a. | Defined standards for connecting with external systems. | Agents are responsible for connecting with other systems. Agent code is the same for each system. |
| b. | Defined standards for integrating with IoT devices. | IoT devices can either (i) run an agent on the device, (ii) connect to an agent on another device, or (iii) connect to an agent in the cloud through its adapter. |
| c. | Defined standards for connecting with external blockchains. | Blockchains can connect to the system through their adapter and connect to other systems via the agent. The adapter can connect to the blockchain using SDK and smart contracts. |
| 4. Framework data and processes requirements | ||
| a. | A standard protocol for the exchange of data between systems. | The metadata blockchain will hold the VC schema, the data model, and data mapping information. |
| b. | A standard protocol for orchestrating tasks, actions, and logic between subsystems. | The metadata blockchain will hold the VC schema, the data model, and data mapping information. |
| c. | A standard mechanism for performing analytics or reporting on data stored across multiple subsystems while preserving applicable data privacy. | Each system is the single source of truth for the data it holds. Analytics and reporting need to contact each system using the identifiers in the metadata blockchain to build the report data. Each system already holds access rules that apply to any cross-system queries. |
| d. | Monitored external data sources, monitored for their health. | Mediators can handle situations where an object is unavailable, e.g., an IoT device using mobile communication. The mediator can store and forward the communication of VCs. |
| 5. Framework architecture requirements | ||
| a. | Support public and permissioned blockchain deployment models. | Adapters for each system will account for the specifics of the blockchain deployment model. |
| b. | Include a discovery service to discover endpoints for participating systems. | Metadata blockchain will provide discovery information that the agents can use to help the adapters correctly address the data issuer or recipient using fully qualified DIDs. |
| c. | Discovery services that implement health checks for endpoint management and failover. | Mediators can store and forward VC communication to handle situations where a system is unavailable or an endpoint changes. |
| d. | A discovery service that seamlessly facilitates adding, removing, or modifying endpoints. | Metadata blockchain will provide discovery information that agents can use to help the adapters correctly address the data issuer or recipient using fully qualified DIDs. |
| e. | Platform infrastructure that supports on-premise or cloud deployment options without vendor lock-in. | Participating system adapters will account for the specifics of the cloud deployment and can be customized to work with any cloud platform. |
| f. | A set of standard interfaces for external systems to accomplish specific business functions. | The metadata blockchain will hold the schemas that can standardize business communication. |
| g. | Supported asynchronous communication with appropriate message queuing. | Mediators can store and forward VC communication to handle situations where a system is unavailable or an endpoint changes. |
| h. | Notification capabilities across systems. | VCs can support any type of data. The agents can facilitate P2P direct messaging, enabling notifications that do not require attributions or verification. |
|
| ||
| 1. Platform identity requirements | ||
| a. | Queries that enable an organizational management service to map a DID to a specific organization. | The metadata blockchain will hold the public DIDs in a DID registry. |
| b. | Unique identifiers that are persistent on an organization’s platform. | DIDs contain a system-specific component. Even if two systems used identical representations of an object, the system identification data would enable universally unique IDs. |
| c. | Digital assets with unique identifiers that are persistent on their organization’s platform. | |
|
| ||
| a. | A standardized messaging layer that connects with IoT devices, including support for IoT events and selective data querying. | VCs can support any type of data, including messaging data. The adapter for the IoT device and the DID method-specific identity information can handle IoT events and selective querying. |
| b. | A standardized messaging layer that connects with traditional IT systems. | VCs can support any type of data, including messaging data. |
| c. | A standardized messaging layer that connects with external blockchains. | |
| 2. Platform security and privacy requirements | ||
| a. | A mechanism for enabling private transactions. | Using P2P communication with encrypted VC payloads ensures that a transaction is private. |
| b. | No exposure of user private cryptographic materials to the overarching system or individual system administrators. | Each user or organization will sign their VCs with their private keys; the system will not require private keys. |
| c. | No PII may be committed to the ledger. | The metadata blockchain only holds schemas, public endpoints, and public keys; it does not hold the PII of individuals. |
| 3. Platform governance requirements | ||
| a. | User actions that are auditable, comprehensive, and immutable. | The VC approach does not create new actions beyond the credential’s creation, delivery, and receipt; additional, auditable actions can be added by customizing the adapter. |
| b. | All actions and data traceable to the organization/user that published the data or executed the action. | DIDs will be used in all cross-system communications and traceability. |
| 4. Platform analytics requirements | ||
| a. | A standard mechanism for real-time data analysis within the blockchain without violating the data privacy controls or exposing private data to system administrators. | The VC approach does not keep a shadow copy of the data, so it does not need a duplicate set of privacy controls. |
|
| ||
| 1. Use case-specific, functional requirements | ||
| a. | A standard mechanism to define, store, and exchange asset lifecycle information in an immutable data structure. | The metadata blockchain will hold the asset standards that the adapter will use to translate those standards to the specific platform. |
| b. | Supports storing asset lifecycle events and data in real-time. | The asset stays on the original system; a copy is not maintained. There is no performance lag on a copy. |
| c. | Supports storage of asset lifecycle events and data in an immutable fashion. | The digital asset depends on the implementation of the original system that stores it. A VC does not affect the abilities of the original system. |
| d. | An identifier that is unique across systems for each asset. | The fully qualified DID gives a universally unique ID to all assets based on the asset ID generation of the underlying system and the identification of the system itself. |
| e. | Asset data that includes physical origin, digital origin, and asset composition information. This information may be gathered from and communicated to other systems. | A VC can hold the complete data on an asset and can be passed between systems. It is up to the receiving system implementation on how much of that data they wish to retain. |
| f. | Supports tracking of parent–child asset relationships, including scenarios where the parent and child assets are tracked in different systems. | The schema of the VC payload can have hierarchical representations, and a credential can also contain other credentials. The DIDs are references to data in systems, so the relationship can be represented without copying the data. |
| g. | Be configurable to allow for nuanced business requirements of specific industry verticals. Configuration must include asset attributes, asset events and event attributes, and asset and event validation rules. The configuration may consist of rules of origin and tariff rules. | The adapter and the metadata blockchain can store the industry-specific elements of the system. |
| h. | Asset division and assembly support, e.g., division of batches or runs, plates or coils, and support for assemblies, like ingredients for a batch or a combination of products to construct a new one, like a car. | DIDs have a method-specific data element that can be configured in the metadata blockchain to help identify the origins of divisions and component assemblies. VCs can also be kept and used to verify things. |
| 2. Use case-specific privacy and security requirements | ||
| a. | Data access on a least-privilege basis. | Access to the data is specific to the system itself. The system-specific adapter controls the local data access for locally building a VC or handling a request from an external party. |
| b. | Organization registration and onboarding based on an organization’s relationship with a specific digital asset. User registration and onboarding must be based on role-based access control (RBAC). | VCs can be used to onboard users, organizations, and devices. The credential is a machine-readable way to determine if the subject fits a role. |
| 3. Use case-specific interoperability requirements | ||
| a. | Reliable, integrated external system providers. | Adapters are required for each service that participates in the entire system. |
| b. | Sanitized and validated inputs that are then committed to a network distributed ledger. | Each adapter is in charge of translating between systems using the metadata blockchain standards and data model. |
| c. | Real-time analytics that supports reporting, AI, or other analysis tools. | The handshaking required for VC communication may preclude real-time reporting. There will always be a lag, a trade-off of having verifiability. |
| 4. Use case-specific, non-functional | ||
| a. | Dependence on the platform’s identity and discovery services, but support for external shared services. | The adapter and agent of the platform will handle the discovery of external services for the underlying system. |
| b. | Compliance with NIST. | A NIST audit will be required to ensure compliance. No significant impediments to NIST compliance are foreseen. |