Registration & Discovery
Last updated
Last updated
Accounts are registered on a distributed ledger, ensuring that they can handle monetary transactions. Both parent and device accounts must be present on the ledger and capable of holding funds. Device accounts are then recorded on a smart contract, which functions as a directory. This directory specifies the service license agreements each device engages in (SLA), the monetary value of the service and also lists the three topics each device listens to and can communicate with.
Service License Agreements (SLAs) need to be stored either verbatim on the ledger or as a hash, depending on the application's requirements. Storing SLAs ensures authenticity and immutability of the agreements between devices and service providers or consumers. In smart contracts, the reference to these SLAs is used to determine which device and service provider or consumer is associated with a particular SLA. This approach enables transparent and efficient tracking and management of SLAs across various devices and services. Importantly, these SLAs are written in natural language to ensure clarity and ease of understanding for all parties involved.
Each SLA comprises a portion that is common to all agreements, specifically focusing on connectivity and availability, which is managed by the SDK. This section ensures that basic service standards are maintained across different applications. The remainder of the SLA is tailored to specific business and decentralized application (dApp) requirements. For instance, in an aviation dApp, the SLA might specify what constitutes good quality sensor data or the required frequency of data transmission. This customization allows for precise and effective service delivery aligned with distinct business goals.
To ensure SLAs are adhered to, they must detail the nature of public messages exchanged on the Distributed Ledger Technology (DLT). This allows validators to examine the public record and verify compliance with service agreements. Validators may perform checks on a continuous basis or in specific instances, such as when a complaint is raised. In scenarios where validators function as escrow agents, they will assess these public messages to determine whether funds should be released or refunded, ensuring fair and transparent financial accountability.
The smart contract serves as a registry for device accounts, detailing their associated communication topics and subscribed Service License Agreements (SLAs) along with the monetary values tied to these SLAs. It provides functionality to:
Look up devices by ID to retrieve their topics SLAs and associated rates.
Insert new devices along with their associated data.
SLAs are created and inserted by a Decentralized Autonomous Organization (DAO), and devices can choose from the offered SLAs when registering.
Discovery is consequently predicated on examining the public ledger, initiating with the enumeration of identities maintained within the smart contract, and proceeding with the analysis of the attributes from the stdout message stream.
DApp developers may execute this independently or may engage third-party entities, e.g. explorers, with proficiency in this particular function. For example, an external explorer can continually monitor the ledger and build an internal, queryable database, which provides functionalities such as "identify all devices in proximity that offer an SLA of category X."
Explorers can be publicly facing services, enabling more accessible interactions with the network data for various stakeholders. Alternatively, the explorer and discovery logic can be entirely implemented within a peer itself, thereby eliminating third-party dependencies and enhancing both autonomy and security.
