Infrastructure Layer

The infrastructure layer of the technology stack will be built on top of the blockchain layer and will be utilised by member entities for developing and managing applications. Using pre-built tools, or consumer-ready services on the application portal, members can easily build or integrate HydroLink solutions into their own digital infrastructure. The services within the Utility Layer are paid for with HydroLink tokens.

HydroLink Naming Service

HydroLink will utilise the Ethereum Name Service (ENS), which is a distributed, open, and extensible naming system based on the Ethereum blockchain.

ENS’s role is to map human-readable names like ‘alice.eth’ to machine-readable identifiers such as Ethereum addresses, other cryptocurrency addresses, content hashes, and metadata. ENS also supports ‘reverse resolution’, making it possible to associate metadata such as canonical names or interface descriptions with Ethereum addresses.

ENS has similar goals to DNS, the Internet’s Domain Name Service, but has significantly different architecture due to the capabilities and constraints provided by the Ethereum blockchain. Like DNS, ENS operates on a system of dot-separated hierarchical names called domains, with the owner of a domain having full control over subdomains.

Decentralised Identifiers (DIDs)

A DID is a verified digital identity used to identify any subject - such as a non-tangible asset, a person, or an entity. Unlike traditional forms of identification, DIDs are not generated by a central authority and are stored in a decentralised database. A DID for a given system resides in a decentralised DID registry or on a blockchain network, which in this instance, will be the HydroLink Ledger.

Companies or individuals, such as those producing hydrogen, operate the digital twins of various assets in private trusted networks. A digital twin represents all relevant aspects of the physical asset in a digital setting. The assets and their digital twins are unambiguously discoverable in an open digital ecosystem, and while many digital twin networks currently operate in centralised networks, our decentralised approach will negate their disadvantages. Registering a digital twin can be done via submission of a DID document, which is stored as a transaction in a common dataset and accessible via a unique asset ID. Asset operators will be able to connect to the network of nodes and find the corresponding transaction in the dataset, allowing for the DID transaction to be extracted. The DID document, processed via data parallelism, can then be accessed from outside the HydroLedger.

Identity & Access Management (IAM)

Platform access requires identity-based policy documents to be attached to an identity, such as an IAM user, group of users, or role. Policies control what actions users and roles can perform, on which resources, and under what conditions. Access control lists (ACLs) are then used to assess the user's right to perform an action.

Verified Credentials (VCs)

The main difference between traditional, non-digital credentials and verifiable credentials are the way they are verified. Traditional credentials require manual verification, such as a signature or stamp. Verifiable credentials use a digital proof mechanism, such as a digital signature. A digital cryptocurrency wallet, such as MetaMask, is used to verify ownership through a digital signature. Blockchain technology, through the embedded mechanisms of trust, negates the need for any interaction between the issuer and the verifier.

Once an authority verifies a claim, a VC can then be used as an official record to assure others of the truth of statements made. These credentials are linked back to the credential subject’s digital identity and recorded on the user's DID document. A DID document can contain a detailed set of VCs that illustrate the origin, attributes, and capabilities of a subject. For example, account registration for a hydrogen producer will require:

• A scanned copy of the application user’s business license and company registration;

• Hydrogen production equipment list and approved third party inventory audit;

• List of raw materials (pre-processing) for hydrogen production and their associated GHGs emissions; and

• Production capacity, storage, location, and other summary data points;

Cache API

HydroLink's Cache API caches responses from your endpoint for a specified time-to-live (TTL) period in seconds when you enable caching for a stage. A NodeJS server application, using the NestJS framework, caches specific smart contract data such as ENS namespaces and DID documents to improve read-query performance for applications and packages that rely on on-chain data. The IAM Cache is also utilised for the M2M Messaging Service to use credentials for role permissions.

Oracles

Smart contracts cannot directly gather data from external systems. HydroLink will obtain data from multiple input sources (e.g., monitoring distributed solar for renewable portfolio standards accounting & IPHE hydrogen emission classification standards). HydroLink is planning on developing application-specific protocols, however in the meantime utilising the Chainlink protocol, for establishing a network of independent nodes to provide event data to on-chain contracts. The decentralized oracle implementation eliminates single points of failure and can reduce friction in market transactions by accepting data from multiple sources concurrently. The dedicated nodes will execute specific processes to retrieve, interpret, and aggregate external data. This sanitized and summary data will then be recorded on the HydroLedger.

Staking

HydroLink application users must be authorised to access the decentralized application (HydroLink portal). Once granted access, they are automatically able to stake their tokens to receive rewards from fees charged from network activity. Staking is used to support master node operators. A node operator is incentivised to perform validation in a secure and timely manner - operations which the service layer relies on for efficient functioning. As such, staking rewards reflect the node operator that their staked tokens support. If a node operator is unreliable and affects the performance of HydroLink’s services, they may face penalties, with staking rewards for those supporting the node, also affected.

M2M messaging Service

M2M refers to communication between machines - ‘machine to machine’ assets, which operate at different stages of the supply chain that have no existing communication protocols. The messaging services fully decentralised and designed to be easily scalable. Further, messages can be tracked to the original sender using cryptographic signatures, adding an extra layer of security compared to convention services.

Storage

The storage of all data gathered along the supply chain, particularly during the production stage, is immense in volume and consequently impractical to store on the blockchain. A private cloud or on-premises database will be used for commercial applications. The messaging abstraction component will act as the connective layer to on-chain components. The content-addressed data must not be editable to maintain trust and security.