Main Menu Button
Login

Introducing the Prasaga Ecosystem White Paper

This White Paper describes the different parts of the ecosystem including the Blockchain (not specific on patent pending hybrid PoW/PoS or Extensible Blockchain Object Model), the Distributed Single Transaction Ledger technology, the IoT/Smart City open standard message bus integration, the DataGrid Marketplace for buy/sell of real-time data from physical world devices.

The Prasaga DataGrid

A decentralized distributed ecosystem for IoT (Internet of Things) and ETD (Exchange-Traded Data)

By David Beberman, Ossip Kaehr, Yuan Wang, Michael Holdmann and Branden Laske


Abstract

Prasaga DataGrid is a decentralized network and platform for routing data streams dynamically between distributed message servers and clients. It enables collaborate and help one another become more operationally efficient, sustainable, and cost effective, bycoalitions of businesses and others to sharing data and analytics of operations and system functions while retaining a high level of security and privacy.

The wealth of data held by every digitally literate entity enables a vast amount of potential influence on the world that creates a duty to take on critical responsibilities. By creating an emergent interoperable messaging network to share information and data, Prasaga DataGrid enables the ability to improve the environment and infrastructure of the world through a crypto-economic incentive system that is embedded with the tenets for regenerative ecosystems and alignment with the triple bottom line — people, planet, and profit.

By growing this ecosystem of cooperation, IoT can expand influence beyond the enterprise and into the world we live in today, our cities and infrastructure. For example, optimizing traffic flows — controlling traffic lights based on road usage — reduces vehicle emissions by 30% due to reduced congestion and idling time.* Other examples include, accurately calculating energy and water consumption needs for homes and businesses, fixing excessive food waste, and more accurate reads on current and future weather patterns and conditions. Much of these extend beyond the Prasaga DataGrid, but these ideas only become possible and real with the existence of a foundational decentralized ecosystem of IoT devices.

Prasaga DataGrid will create a trustworthy, cooperative, IoT peer network by implementing trustworthiness for device verification with an integrated blockchain and Smart Contract platform. With the introduction of Smart Contracts and trustworthiness to validate the integrity of devices and data, the Prasaga DataGrid supports bid/ask exchanges for device data, i.e., the Chicago Board Options Exchange (Cboe; www.cboe.com) of IoT data. Anyone can build exchanges using the Prasaga DataGrid. These exchanges will consist of many ETD’s, (Exchange-Traded Data). Prasaga will pioneer and lead this revolutionary movement to globally expand the trade and sharing of data streams, benefiting all users of
the DataGrid.


Preface

DataGrid

The mission statement of Prasaga conglomerate is the creation of the global “data grid.” At Prasaga, we believe that the DataGrid has the potential for far reaching social and business benefits.

Data Currency

The operating goal of the Prasaga Foundation is the asset value growth of the Data Grid Token (DGT) which represents data as a currency, thus termed Data Currency.

Non-Profit Entities

The Prasaga conglomerate includes several non-profit entities operated under the Prasaga Foundation managed by the Prasaga Board of Trustees. This includes the Prasaga Foundation itself, the International Smart City Research Institute (ISCRI), and is expected to include additional non-profit entities over time.

The Prasaga Foundation realizes the mission and operating goals, the Data Grid and Data Currency, through providing software and hardware components to the IoT global community to attain the necessary functionality and interoperability, enabling exponential growth in the Data Grid, and the associated value of the DGT.

For-Profit Entities

The Prasaga conglomerate includes several for-profit entities operating under the Prasaga Board of Directors. This includes, Maltese Inc., Prasaga Systems Integrator, and is expected to include additional for-profit entities over time. The goal of these for-profit entities is to facilitate network usage, growth, and provide a blueprint for other businesses aspiring to join the Prasaga economy. As some of the Prasaga controlled for-profit entities may conflict with the Prasaga conglomerate’s mission by creating potential anti-competitive pressures, the Prasaga Board expects to divest and exit such entities if and when such situations arise.

Prasaga DataGrid System Architecture Guiding Principles

The goal of all systems architecture decisions shall be to meet one of the following objectives in the order presented:

  • Decentralized architecture
  • Distributed architecture
  • Centralized architecture

The ideal architecture is primarily decentralized, followed by distributed, and with no centralization. This ideal has primarily been achieved with the architecture of the Prasaga DataGrid.

Internet of Things (IoT)

The Internet of Things (IoT) is the network of devices, electronics, vehicles and other physical entities that are embedded with some connection, sensor, actuator, and software. IoT enables recording and tracking data, real time device state, device safety, device control, etc. IoT creates the opportunity to create a more direct integration of the physical world with our computer-based systems. Doing so will provide economic benefits and efficiencies, such as, human & environment safety, and energy & waste reduction.

There is a track record and history of IoT projects being internally ‘created’ within large corporate entities. Unfortunately, according to Cisco Research, nearly three quarters of IoT initiatives are considered a failure, while a third of the projects being completed, are still not considered a success. These failures are a result of the complexity of such systems and the length of time to fully roll-out projects. Many projects take as long as five years until they are killed off and considered a failure, which is a significant industry problem: 60% of IoT initiatives stall at the Proof of Concept stage.** This statistic should come as no surprise because most corporate development and deployment teams are not addressing the IoT problem with the right approach. They fail to address the following issues:

  1. Ecosystem for Exchange of Data for Value – As an accumulation of the prior four problems listed, the end goal is getting data from a publisher (content creator) to a subscriber (content consumer), data which likely may be sourced from several different servers. Not only is it difficult to manage the exchange of the data, but managing value transactions which may represent hundreds or more of data transactions at any given time for multiple customers in a scalable manner is completely unaddressed by proprietary IoT systems.
  2. Real Time Data on Local Networks – Many solutions for data collection of IoT devices attempt to use the cloud over the Internet exclusively. The Internet does not provide latency or jitter guarantees, or service continuity. This makes it unsuitable for use-cases that have strict real time requirements. Further, a significant portion of data generated by IoT devices can be redundant. Transferring large amounts of redundant data in a cloud IoT solution can incur significant bandwidth usage costs without any additional derived value.
  3. Multiple Device Support – Many IoT systems are built to satisfy only a specific system’s “brand” of devices. Corporations are not incentivized to build their devices to adapt and contribute to other IoT systems because their only incentive is to keep the data and users to exclusively use their own devices, not a competitor’s. The integration of multiple devices into one application platform is usually very narrow and focused at the corporate level of IoT implementation. For numerous reasons, including the perceived need to create a walled garden around their application data, this inhibits its’ ability to be shared with outside users, unless those users adopt the proprietary approach. This in turn limits the growth of any IoT system by making them exclusive and not able to easily share data.
  4. Data Distribution & Data Integrity – A significant issue to address is how an IoT system discourages bad actors from sharing “bad” data in order to “game” other users for their own gains. This is only a small part of the data distribution and integrity problem, as the distribution of the data itself is a difficult problem to solve. This is already pointed out in (II.) and the risks implied with data distribution using data storage pulling from and pushing to the cloud, for example.
  5. Ecosystem for Exchange of Data for Value – As an accumulation of the prior four problems listed, the end goal is getting data from a publisher (content creator) to a subscriber (content consumer), data which likely may be sourced from several different servers. Not only is it difficult to manage the exchange of the data, but managing value transactions which may represent hundreds or more of data transactions at any given time for multiple customers in a scalable manner is completely unaddressed by proprietary IoT systems.

    ** https://newsroom.cisco.com/press-release-content?articleId=1847422

General IoT Framework Background

The IoT framework of a typical system utilizes a three-tier architecture pattern of an Edge Tier, Platform Tier, and Enterprise Tier. Each tier plays a specific role in data and control flows involved in the activity of the IoT system. The following is based on material from the Industrial Internet Consortium Reference Architecture (IIRA). The complete document is available for public download at https://www.iiconsortium.org/IIRA.htm

Figure 1 Multi-Tiered IoT Architecture

Edge Tier

The edge tier collects data from the edge nodes (devices), using a proximity network. Edge Nodes are the collection of different sensors, actuators, devices, control systems and assets collectively. The characteristics of this tier include breadth of distribution, location, governance scope and nature of proximity networks, depending on specific use cases.

Proximity Network

IoT devices typically connect through an IP network to the global Internet through the access network. If devices are local to the systems message bus, a variety of network transports are used, e.g., fieldbuses, such as MODbus. The collection of devices create this “proximity network” where all information is transferred to the next tier thru the Edge Gateway, also termed the IoT Gateway. Within the proximity network, data and information can be controlled from the Enterprise Tier, such as, frequency of data snapshots, time windowing, data transfer frequency, data filters and data controls. Device aggregation occurs at this level, and device management acts as a mediator between the proximity and access networks for identifying device level operating issues and/or authenticity checks.

Access Network

The access network enables connectivity of data and controls from the proximity network into the platform tier, the second tier of IoT framework. This could be a corporate network, an overlay private network utilizing the public Internet, or other network transport. The access network is the bridge that communicates with the local proximity network and service platform, where data and information is stored and utilized. Keep in mind that some functions within the system will vary depending on the specific use cases, for instance, the controls of data flow may be closer to the Edge Tier, where data is captured and consolidated, while other systems may place controls more on the service platform end, where data is stored.

Platform Tier

Receiving, processing and forwarding control messages and queries, the platform tier handles all data and messaging consolidations for analysis, management and services. This can incorporate both domain and non-domain specific services within the entire system.

The platform is typically living in the cloud, a unified object storage from live applications to archive storage of data and information. The cloud allows for a distribution of the data to other networks outside of the local domain. The IoT operators can also collect all data onto a local database that does not touch the Internet, completely skipping the access network but this makes the system private and not distributed. Some connection to the Internet, to another domain, or transfer of data to another DB needs to be established in order to be distributed to another controller. The Platform Tier is a ‘bridge’ from the IoT devices into the Enterprise Tier where the data and information is interfaced and shared for human or network consumption and analysis.

This tier applies many forms of data querying such as algorithmic integration for data consumption, data filtering to capture a specific array of data for a specific pull of information into Enterprise use.

Enterprise Tier

The Enterprise Tier consists of user interfaces that implement domain-specific applications, decision support systems and end-user operations that operational specialists and/or other users will utilize in providing flow controls of data from edge tier through the platform and into the enterprise. This would provide control panel features, all control commands / filters, are typically implemented for flow of data from device into functional data utilized by analytics engine.

Prasaga DataGrid Architecture

The Prasaga DataGrid Architecture combines the concepts of the architecture patterns defined in the IIRA with the concepts of blockchain and distributed ledger technology to create a new paradigm for IoT.

Figure 2 – depicts architecture with logical location of Marketplace Blockchain
Figure 3 – depicts architecture with logical location of Device DLT

The DataGrid architecture consists of several entity types. These are depicted above in the figures 2 and 3. Each of the entities in the DataGrid architecture follow the precepts of decentralization and distribution described earlier. The following describes the individual entity types. It should be noted that the DataGrid architecture is designed to be an open architecture. New entity types are directly accommodated without disruption of the existing architecture, thereby enabling an incremental evolution.

Marketplace Blockchain

The Marketplace Blockchain forms one of the two pivot points for the DataGrid architecture, the other being the Device Distributed Ledger described below.

The Marketplace Blockchain supports two blockchain transaction types: specialized “trustworthiness transactions”; and general Smart Contract transactions. The latter follows the model of messages to account addresses enabling coin transfers and Smart Contract execution. The former defines the method of ensuring trustworthiness of the various entities in the DataGrid architecture and thus the core value creation concept. The details of trustworthiness are described in the section on certification and trustworthiness.

DataGrid Token (DGT)

The DataGrid Token (DGT) is the cryptocurrency used on the Marketplace Blockchain for transaction fees, for validator rewards, and for DataGrid data transactions. It is the “data currency” for the DataGrid architecture. It is not explicitly depicted in the above figures but is implied by the Marketplace Blockchain. All transactions between all entities in the DataGrid architecture are in denominations of DGT.

Device Distributed Ledger

The Device Distributed Ledger (Device DLT, where DLT stands for Distributed Ledger Technology) forms the second pivot point for the DataGrid architecture; a specialized decentralized distributed ledger providing a means for double entry logging of data transfers between devices and message servers in the DataGrid. The Device DLT does not use a cryptocurrency and thus does not have any associated transaction fees or rewards, but it does use the trustworthiness transaction format.

Devices

Devices in the above figures are logically represented by several icons indicating appliances, industrial automation equipment, and similar. In addition, devices are not limited to physical equipment and include virtual entities such as artificial intelligence engines and analytics systems. With the DataGrid architecture, devices are connected to message servers, are the data producers, and optionally are also control endpoints. There is no limit to the type of devices that can be connected to the DataGrid architecture: Realizing the value of the data created by each type of device requires publishing the definition of the data and interfaces supported by the device type.

DataGrid Message Server

The DataGrid Message Server provides the distributed, scalable platform for Internet-of-Things (IoT) messaging. IoT data is communicated between the entities of the DataGrid via Message Servers. It is important to note that the IoT data is not communicated on either the Marketplace Blockchain or the Device DLT directly. The quantity and rate of data is many orders of magnitude too large for any blockchain design, regardless of blockchain technology scalability. The Marketplace Blockchain is used to store “metadata” information about the data transferred such as logging of the amount of data transferred for commerce purposes between DataGrid data sellers and buyers. As depicted, a Data Seller operates one or more DataGrid Message Servers. The group of DataGrid Message Servers operated by a Data Seller forms an autonomous message bus for transferring data between devices, data buyers, other Data Seller autonomous message busses, and to any other entity.

DataGrid Blockchain Listener

The DataGrid Blockchain Listener monitors the Marketplace Blockchain to interact with Smart Contracts for establishing connections with data buyers, logging of data and commerce transaction with data buyers. The DataGrid Blockchain Listener is logically depicted as a client of a DataGrid Message Server and connected to the Marketplace Blockchain as a peer operated by a Data Seller. Alternative implementation structures are possible and supported by this logical architecture.

DataGrid Seller

The DataGrid Seller is the owner or operator of a group of DataGrid Message Servers and DataGrid Blockchain Listeners as logically depicted. The DataGrid Seller creates various data flows and offers them for sale to Data Buyers. Although the devices are depicted logically as separate from the DataGrid Seller, the relationship between devices and DataGrid Sellers is a local issue and not prescribed by the DataGrid Architecture. An example of a DataGrid Seller offering data for sale and execution of the sale is described later in this paper. The terms DataGrid Seller and DataGrid Vendor are used interchangeably.

Data Buyer

The Data Buyer is any entity that engages with one or more Data Sellers to purchase and receive data. The Data Buyer logically connects to one or more of a Data Seller’s DataGrid Message Servers, and receives IoT data from the DataGrid Message Servers. The Data Buyer and the Data Seller interact with one or more Smart Contracts on the Marketplace Blockchain to log meta information about the IoT data and for commerce transactions.

Data Exchange Marketplace

The Data Exchange Marketplace is any entity that serves as a meeting place between DataGrid Sellers and Data Buyers defined by Smart Contracts on the Marketplace Blockchain. The Data Exchange Marketplace provides listing, searching, sorting and related services for data offered from DataGrid Sellers and offers for data purchase from Data Buyers. The Data Exchange Marketplace can be thought of as a combination of an online bazaar and a commodities or futures exchange.


Exchange-Traded Data

Prasaga Data Exchange Marketplace (DEX)

Smart Contracts enable capability to define and manage the availability of offers to buy and sell data streams on the DataGrid. Prasaga utilizes this information from the Smart Contracts blockchain and creates the first example of a decentralized data exchange marketplace. Following the goals of decentralization and distribution, the creation of other Data Exchange Marketplaces is fully supported within the architecture. With the ability to instantiate Smart Contracts, DataGrid Vendors will be able to list and sell their data on the DEX. Prasaga’s DEX will have constructs in place for various types of data models (XML Schema), providing a searchable “bid board” user interface for Data Buyers.

Figure 4 Data Exchange Marketplace Mockup

An example of the order book incorporates the Bid-Ask style board for the buying and selling of data from IoT devices. Boards will consist of a specific data type with permutations and filters of given data, such as; Geo-location of data, date range of historical data, verified vs. unverified, etc. The board, by default, lists “Item”, data description, “QTY,” the number of devices that are contributing to data set, “Bid” or “Ask,” being the sell or buy price, in DGT, for the order.

The DEX scans the Marketplace Blockchain for Smart Contracts to read the data models and establish user interface filters for displaying the exchange listings. The DataGrid Message Server, Marketplace Blockchain, Data Buyer, and DEX exchanges are depicted in an example sequence diagram below:

DataGrid Vendor Offering Example:

Figure 5 – Example: DataGrid Vendor data offered Data Exchange
Marketplace transaction sequence diagram

Figure 5 depicts a sequence diagram of an example transaction [1] between a DataGrid Vendor offering data for sale on the Data Exchange Marketplace and a Data Buyer. The sequence steps are described in more detail below.

  1. The DataGrid Vendor posts an offer of data on the Marketplace Blockchain. The offer includes a data model describing the data with relevant information used by the DEX for display listing purposes.
  2. The DEX scans the Marketplace Blockchain recognizing new offers and incorporates such into its offer listings.
  3. Data Buyers perform searches using filter tools created by the DEX.
  4. A Data Buyer makes a buying decision and accepts a Smart Contract data offer and funds it with an amount of DGT.
  5. The DEX enters the acceptance on the Marketplace Blockchain.
  6. The DataGrid Vendor confirms acceptance of the offer. (This is intended to be an automated step but could include a human interaction.)
  7. DataGrid Vendor provides encrypted credentials to the Smart Contract for the Data Buyer to connect to a DataGrid Message Server.
  8. Data Buyer retrieves the credentials from the Smart Contract, and performs the connection with a suitable client. Upon a successful connection, the client receives a session ID from the DataGrid Message Server.
  9. Data Buyer logs the session ID with the Smart Contract providing proof of the connection.
  10. DataGrid Message Server logs the same session ID providing completed proof of the connection.
  11. DataGrid Message Server logs meta data (recording the agreed upon metrics of the data transferred) and receives DGT from the Smart-contract.
  12. The DataGrid Message Server or the Data Buyer client terminates the session by sending a termination message to the Smart-contract.

Possible reasons for termination in #12

  • If amount of data transferred has reached a defined maximum, all remaining funds are returned to buyer.
  • If some given time limit has reached, all remaining funds are returned to buyer.
  • If buyers funds are exhausted.
  • If buyer terminates contract, all remaining funds are returned to buyer.
  • If buyer terminates session with DataGrid vendor, all remaining funds are returned to buyer.

Data Exchange Marketplace Offerings

The example above described a single type of offering that the Data Exchange Marketplace can support. The number of types of offerings on the Data Exchange Marketplace are potentially unlimited. It is expected to operate somewhat similar to a conventional commodities exchange. As such, data futures contracts will be supported, enabling various funding models for DataGrid vendors to take advantage of, as well as derivative offerings.

Although Prasaga will create the Data Exchange Marketplace, the Marketplace Blockchain, the DataGrid vendors, the Data Buyers and the Data Exchange Marketplace are completely independent of each other. Data Buyers and DataGrid vendors may make use of other marketplaces, created independently of the Prasaga. The Marketplace Blockchain enables a fully decentralized approach to marketplaces: Innovation in marketplace implementations are expected as a result.

Data Modeling

Data modeling refers to modeling data related to all entities in the DataGrid Architecture which includes all IoT data communicated across it. Data models will be defined in XML Schema [2] supported by the XMPP implementation of the DataGrid Message Servers.

Data models for the following shall be defined by the DataGrid Architecture:

  • Trustworthiness Metrics
  • Adoption of Open Connectivity Foundation (OCF) IoT device data models
  • Device type description
  • Message Server type description
  • Message Server control interfaces description
  • Message Server data stream parameters
  • IoT Gateway device control interface description
  • Other DataGrid Architecture entity descriptions
  • Other data stream descriptions

XMPP is an extensible message server protocol. As such it supports an evolutionary approach to messaging constructs as well as the content of the messages. This matches up well with the DataGrid Architecture’s evolutionary approach to the entity types.

The Prasaga Foundation will encourage creation of open standard data models on an ongoing basis. The DataGrid Architecture will support both open standard data models and commercial entity data models, provided that all data models are published. Because all of the entities in the DataGrid Architecture depend on the use of data models as a common “language” between them, the use of proprietary closed, unpublished data models prohibits data commerce: Market forces enabled by the DataGrid Architecture coupled with the Foundation activities will provide incentive pressures to create and maintain open standards and commercial published standards. The resulting body of data models and entities developed to work with said data models will achieve a fundamental goal of IoT interoperability.

Open and published data models enable the DataGrid Seller, Data Buyer, and Data Exchange Marketplace to negotiate over well-defined offerings of data streams. This, in turn, will stimulate innovation and create secondary or derivative markets.

Trustworthiness

Trustworthiness as defined by the Industrial Internet Consortium Security Framework Technical Document (https://www.iiconsortium.org/IISF.htm) combines the following aspects: Safety, Security, Reliability, Resilience, and Privacy. These aspects attempt to capture the complexity of describing what is meant by trustworthy.

The DataGrid main concern is facilitating communication of data from data providers to data consumers. The value of any communicated data is directly proportional to the integrity of the data. The integrity of the data is directly related to the trustworthiness of the sources of the data, and all the entities that touch the data on its journey to the data consumers. Trustworthiness is thus an intrinsic metric of the entities involved in an instance of data communication.

In order for Data Buyers to determine the integrity of the data that they wish to purchase, they have to be able to determine the trustworthiness of the communication path from the source of the data (e.g. a sensor), across the DataGrid to the Data Buyer’s connection with the DataGrid. Although the final determination of the acceptance of the level of trustworthiness is subjective according to the Data Buyer’s needs, various metrics describing the level of trustworthiness must be available to the Data Buyer as part of a DataGrid Seller’s data for sale offering.

The trustworthiness of each entity in such a communication path must be modeled with a data model that becomes part of a DataGrid Seller’s Smart Contract offering on the Marketplace Blockchain, and further made available on a Data Exchange Marketplace. Similarly, if a Data Buyer has a Smart Contract offer to buy a given type of data, the acceptable trustworthiness of the data must be modeled with a data model.

Certification and Trustworthiness Flows

[image deleted]

Figure 6

Certification and Trustworthiness are two separate processes. Certification takes place “offline” and is completed with a registration of the certification on the Marketplace Blockchain. Trustworthiness takes place “online” for each blockchain transaction whether on the Marketplace Blockchain or the Device DLT.

The following describes each of these processes:

DataGrid Certification

Figure 7

The logical certification flow as shown above starts with some combination of device hardware and software:

This must constitute a functioning system and must make trustworthiness claims to the certification body as input for review.

As depicted the certification body makes a trustworthiness assessment:

  • Not shown, but supported, there may be multiple trustworthiness assessments as determined locally between the certification body and the entity requesting certification.
  • Output from the certification body is a multi-parameter trustworthiness rating captured in hardware and software certificates.
  • Software certificates and the software image that was evaluated by the certification body become the software “golden image.” This is distributed and made available to all Marketplace Blockchain and Device DLT validators via an IPFS. The certificate provides verification of the software image for future use.
  • The software certificate, reference to the software golden image, the hardware certificate, and any other reference material are registered on the Marketplace Blockchain, as hardware and software category (i.e. type) information.

Instances of devices may now be deployed and registered on the Marketplace Blockchain with reference to the registered category information.

Certification pertains to the category or type of device and software, as opposed to a single specific device and software instance. Certification and issuance of a certificate are performed by independent certification bodies. Certification is a distributed function leveraging market forces as opposed to a decentralized function. As such, multiple certification bodies services are accommodated. The certification body that certified a device category is a parameter available to data consumers (buyers), and the Data Exchange Marketplace. This is analogous to a certification mark that is common place for home, business, and industrial appliances. A well known example of a certification bodies is Underwriter Laboratories (UL). Thus the certification is analogous to the UL mark in the USA and the CE mark in the EU.

Additional Comments

The hardware and software certificates issued by the certification body may or may not be perpetual. The Marketplace Blockchain and the DataGrid do not make any determination on the duration of any registered certificates. Each certification body makes their own independent determination of duration in terms of their relationship with the entity requesting certification.

Software over-the-air (OTA) updates and forms of over-the-air silicon updates occur periodically. Logically any such updates follow the same certification path as described above. The OTA update is a function of the IoT portion of the DataGrid and will vary from device type to device type. It is important that the OTA update and the new registration occur logically simultaneously to avoid spurious rejections of data due to unordered changes between OTA updates and the associated registered certificates.

Trustworthiness

[image deleted]

Figure 8

The logical trustworthiness flow, as shown above, starts with the recording of the block ID of a specific block of the Marketplace Blockchain. This flow is described below:

[description deleted]

Additional Comments

[text deleted]

Anonymity

The Marketplace Blockchain and Device DLT uses public pseudonyms for accounts providing untrusted transactions and a certain level of anonymity. Because DataGrid Message Servers necessarily know the TCP/IP source address for all connected clients, anonymity at the message server level is more difficult. Since the DataGrid Architecture does not depend on the TCP/IP addresses using techniques such as the TOR network, TCP/IP addresses can be masked enabling client to message server anonymity. Although a message server may be located behind a Network Address Translation Demilitarized Zone (NAT DMZ), at least one TCP/IP address is publicly known to establish a data stream. However, during the DataGrid Seller and Data Buyer negotiation with the Marketplace Blockchain and a Data Exchange Marketplace, all entities may be untrusted to the level enabled by public pseudonyms. Further, the connection credentials provided to a Data Buyer by a Data Seller are encrypted, and thus are a local matter.

Permutations of Anonymity

Permutations of anonymity from the viewpoint of the data consumer:
8 permutations – Entities:

  • Devices / Sources (DVC)
  • DataGrid providers (DGP)
  • Data consumers / Sinks (DCS)
Use
Case
DVC DGPDCS
1 – XAnon Anon Anon
2 – NAIDAnon Anon
3 – XAnon ID Anon
4 – XAnon Anon ID
5 – XID ID Anon
6 – XAnon ID ID
7 – NAID Anon ID
8 – XIDIDID

Use-case 1: Anonymous data from anonymous DataGrid providers to anonymous data consumer with end-to-end trustworthiness.

Perhaps counter-intuitive, a core goal of the DataGrid is to provide trustworthy data in a completely “untrusted” manner. Specifically, from the data consumers viewpoint, the DataGrid source is anonymous, as is the devices the DataGrid source accumulates the data from. Further, the data consumer is anonymous to the DataGrid source. Although all parties are anonymous and “untrusted”, the trustworthiness of the data and thus value of the data remains throughout the transfer from the source devices to the data consumer sink.

Identifying the trustworthiness characteristics of the data sourcing entities does not require unanonymizing the data sourcing entities. This is perhaps one of the more profound aspects of the Prasaga DataGrid architecture, but follows directly from, and leverages the decentralized nature of blockchain technology. Enabling end-to-end anonymity with end-to-end trustworthiness defines the highest technical challenge for any IoT architecture, which the Prasaga DataGrid architecture fully accomplishes.

For details on how trustworthiness is established, refer to the Trustworthiness section of this paper.

Use-cases 2 & 7: Although technically possible do not appear to represent a viable business case. Use-case 2 implies that the source devices are identified, but the DataGrid provider and the data consumer are not. Thus an untrusted data consumer purchases data from an untrusted DataGrid provider, but is provided with identification of the source devices. At a minimum, once the devices are identified, it is believed that identifying the DataGrid provider would be possible, rendering use-case 2 not applicable. Use-case 7 has a similar issue with the data consumer added to the data sources, and is also not applicable.

Use-cases remaining: The remaining use-cases are expected to have varying business value given the specific circumstances. All of the remaining use-cases involve a “reveal” from an anonymous party to an identified party, i.e. unanonymizing and are implicitly supported by the blockchain immutability features.

DataGrid Token (DGT) Flows

The following DGT flows are predefined as part of the DataGrid Architecture. Since the Marketplace Blockchain supports Smart Contracts, the number and types of token flows is not limited.

A pre-mining event shall create XXX billion DGT. These shall be distributed according to the tokenomics defined in the [cite reference here].

The DataGrid vendor, operating DataGrid Message Servers, earns DGT through the normal operations of buying data from data producers and selling data to data consumers (i.e. Data Buyers). Although Prasaga encourages DataGrid vendors to incentivize data producers by paying for the data generated from the data producers’ devices the DataGrid vendors are completely independent entities and determine their own price structures based solely on market forces.

The Prasaga Foundation’s primary mission is to encourage the growth of, and support the DataGrid globally. As such, the treasury is pre-funded according to the tokenomics. Subsequently, as a self- sustaining entity, the Prasaga Foundation Treasury earns additional DGT based on production of blocks containing trustworthiness transactions. Since trustworthiness transactions are generated solely by DataGrid entities (i.e. DataGrid Message Servers), the foundation is directly incentivized to encourage and support the creation of multiple DataGrid vendors, Data Buyers, and by Data Exchange Marketplaces. The treasury shall earn DGT at the rate of an additional 3% of the token reward for each block containing trustworthiness transactions added to the Marketplace Blockchain.

Blockchain Validator Incentives and Market Forces

Incentives for the Marketplace Blockchain Validators are described below. The DataGrid Architecture uses the term ‘Validators’ in place of ‘Miners’ to distinguish the consensus algorithm from that of a ‘Proof-of- Work’ consensus. Market forces for the Device DLT as well as market forces creating pressure for certification and trustworthiness of entities are described in the following paragraphs.

Marketplace Blockchain Validators

The Marketplace Blockchain shall use a “staking” consensus model as opposed to a “Proof-of-Work” consensus model to validate blocks. The Marketplace Blockchain will leverage current scaling algorithms and techniques from the blockchain technology community to address throughput with increased adoption.

The Marketplace Blockchain accepts both general Smart Contract transactions and DataGrid Smart Contract transactions which include one or more trustworthiness. Validating a general Smart Contract transaction is logically equivalent to validating transactions on any other blockchain. Similar to other blockchains, block producing validators receive a reward under the staking consensus model.

Validating an trustworthiness requires [text deleted]

To incentivize the validators to accept trustworthiness transactions, the block producer reward is increased by a percentage of the number of trustworthiness transactions in a given block out of the total number of transactions said block. The percentage increase reflects the added compute resource cost for performing the trustworthiness on each of the included transactions.

Transaction fees earned by validators follow the “gas price” model. Gas costs are discussed in the Smart Contracts and Non-gas Intrinsics section.

Device DLT Validators

The Device DLT is a non-cryptocurrency distributed ledger technology. There are no transaction fees or block producer rewards, and it does not support a cryptocurrency. All transactions on the Device DLT are trustworthiness transactions. All transactions are limited to recording meta data information from the entities in the DataGrid, specifically devices, IoT Gateways, Message Servers and any other types of entities participate in the DataGrid.

The validators for the Device DLT are run by the DataGrid vendors. The use of the Device DLT to log metadata information between the devices, message servers and other entities with trustworthiness is voluntary by the DataGrid vendors. Market forces are expected to provide strong incentives for DataGrid vendors to fully utilize the Device DLT to receive maximum valuation for the data they are providing.

Trustworthiness Market Forces

The incentive for encouraging an increase in trustworthiness of the DataGrid is directly driven by market forces enabled by reflecting trustworthiness metrics to Data Buyers. The market will drive through the need for increasing trustworthiness with competitive pressures.

DataGrid Business Models

The DataGrid Architecture is intended to foster multiple business models. The following are some of the business models that Prasaga has identified: DataGrid Vendor; Data Exchange Marketplace; Device Data Producer; and Validator.

The DataGrid Vendors are expected to provide the main flow of IoT data. An example of a DataGrid Vendor is an industrial automation systems integrator (IA-SI). The DataGrid Architecture enables the IA- SI to offer new business models to their customers leveraging unrealized value in the data they produce. Such business models shall give IA-SI’s that adopt the DataGrid vendor model significant competitive advantages over more traditional business models, helping to grow the DataGrid globally.

Data Exchange Marketplaces business models may include subscription fees, transaction fees and/or other models. The Data Exchange Marketplace portion of the DataGrid Architecture represents a new business entity type with respect to IoT. It is expected that there will be multiple innovative business solutions created.

Device Data Producers as a business model are a new concept enabled by the DataGrid Architecture. Device Data Producers can expect to earn DGT directly from DataGrid Vendors as an incentive to connect with them and provide data sources. Device Data Producers may also act as DataGrid Vendors offering their data on Data Exchange Marketplaces to other DataGrid Vendors for data aggregation. An example of a Device Data Producer might be an automotive vendor wishing to monetize unrealized but economically feasible data sources. The Validator business model is straightforward. Validators earn transaction fees and block producer rewards.

Prasaga Marketplace Blockchain

The following discusses some of the details of the Marketplace Blockchain focusing on the use of specialized Smart Contract features with respect to the DataGrid Architecture:

Smart Contracts

Smart Contracts enable the exchange of money, property, shares, or anything of value in a transparent and simple way without needing a middleman to help assist the exchange. The trust is distributed among the the network participants, who are “staked” and/or social proofed, and the code itself, which cannot be altered. Ethereum introduced the idea of utilizing a standard Virtual Machine(VM) for executing these Smart Contracts on the blockchain.

The DataGrid Architecture introduces the concept of “Non-Gas” Intrinsic functions. These functions are necessary to implement the trustworthiness feature of a DataGrid transaction without incurring excessive gas transaction fees. Non-gas Intrinsic functions are expected to be implemented efficiently directly in CPU machine instructions or hardware acceleration offloading.

Non-DataGrid Smart Contracts

Non-DataGrid Smart Contracts operate as, and are identical to, the existing Smart Contract model. They are powered by the DataGrid Token used as “gas”. Supporting Non-DataGrid Smart ccontracts positions the Marketplace Blockchain as a “first class” blockchain able to support all forms of crypto-transactions, in addition to DataGrid specific transactions. As such it is expected to be attractive to validators operating independently of DataGrid Vendors, which in turn will increase overall security.

DataGrid Smart Contracts

DataGrid Smart Contracts have two additional criteria beyond a Non-DataGrid Smart Contract; enabling automated data trading dApps (e.g. a Data Exchange Marketplace); and built-in “Non-Gas Intrinsics”, defined below.

The DataGrid Smart Contracts enable a distributed Dapp architecture consisting of Data Exchange Marketplaces, DataGrid Vendors and Data Buyers. When a DataGrid Smart Contract gets “executed”, associated message servers enable/disable the flow of the data defined in the contract. The Data Exchange Marketplaces part of the Dapp lists the type, units and related parameters of the available data, defined in the contract.

Non-gas Intrinsics

Existing Turing incomplete machines using “gas limits” as a halting criteria, such as Ethereum’s EVM, measure the gas cost of Smart Contract execution in terms of number of bytes of execution, and amount of text and data involved.

The gas price of executing specific byte code types can vary. The model for the DataGrid Smart Contract includes the equivalent of non-gas cost byte codes. These are termed “Intrinsics”. All interactions related to functions needed for the DataGrid message servers to operate are considered Intrinsics and have no associated gas charge. An example of an Intrinsic is the trustworthiness verification function.

Implementing an trustworthiness transaction using a gas cost on a VM would be cost prohibitive and act as a disincentive to validate trustworthiness transactions. By creating an Intrinsic, this disincentive is eliminated. Note that validators earn an additional reward for verifying trustworthiness transactions as a further incentive.

Non-gas Intrinsics intentionally violate the Turing incompleteness of the decentralized VM. Therefore Intrinsics must be inspected and verified using standard software quality assurance mechanisms such as static analysis tools, code inspection/walkthroughs, unit and system testing. As stated above, Intrinsics are not necessarily implemented in the bytecodes for the VM, but may instead by implemented as binary machine code for performance, and can take advantage of hardware acceleration offload features of specific systems. Regardless of the implementation of an Intrinsic, it is available for use in any Smart Contract as though it is implemented as a Smart Contract function. The transfer of execution control from bytecodes to Intrinsics and back is transparent to the Smart Contract developer.


Implementation Details

XMPP

Extensible Messaging and Presence Protocol is an open standards based communication protocol, communicating messages to the message servers from devices and vice versa in the case of controls on the device(s). The DataGrid Architecture utilized XMPP as a core technology for the DataGrid Message Server. XMPP enables real-time exchange of data, based on XML Schema. Built on a client-server architecture, it creates a loosely-coupled indirect relationship between publishers and producers. This relationship is both decentralized and supports anonymity, by function of its design. One of the strengths of the XMPP protocol is the support for federation of multiple servers providing scalability messaging, which the DataGrid Architecture leverages.

DataGrid Message Server access behind Firewall and Network Address Translation Layers

A common problem with IoT deployments into existing networks is connecting through the Firewall and NAT layers, of which there may be several layers. Both Firewalls and NATs are primarily intended to enable connection to the public Internet from local private neworks, as opposed from the public Internet to the local private networks. As such, configurations often need to be changed to leave ports open to the public Internet, which in turn create additional potential cyberattack surfaces. Because XMPP uses an outbound client connection model, the DataGrid Message Servers are able to connect through Firewalls and NATs without opening ports to the public Internet.


Trustworthiness Transaction Type Details

Non-Interactive Trustworthiness

[text deleted]

A logical description of the entries of a trustworthiness portion of a transaction is described below:

  • Code identifier
  • Code Version identifier
  • Message Server hardware identifier
  • Previous block in blockchain identifier (has as the nonce)
  • Trustworthiness signature
  • Current public key
  • Next public key
  • Message server instance identifier
  • Private key encrypted hash of 1-8
  • Rest of Transaction (account, message, data, etc.)

Definitions:

  1. Code identifier: Identifies the specific application code running the message server. This allows for multiple implementations that may not be related to each other. For example, there may be a full version and a light version of the message server code, or multiple implementations in different programming languages or targeting specific hardware platforms.
  2. Code version identifier: Specific version of the code, based on the code identifier.
  3. Message server hardware identifier: Identifies the type of hardware. This identifier is registered on the blockchain as valid hardware in a Smart Contract. The validator source must be a certified certifier.
  4. Previous block in blockchain identifier:
  5. Trustworthiness Signature:
  6. Current public key: This is the public key that was previously specified as the next public-key in a previous transaction.
  7. Next public key: This is the next public key part of a public/private key pair provided by the message server. By enabling new public/private key pairs, attackers do not gain any information to find the private key, since new key pairs are generated continuously. Assuming the randomization function for the private key is sufficient, then attackers are prevented from masquerading as a message server. Verification of the chain is required. However, a Smart Contract need only store the next expected key after the message server transaction has been validated. It is not necessary for the public key to be replaced on every message server transaction. It should only be replaced when a new nonce (using a more recent blockchain block hash) is chosen. This reduces the processing burden on the message servers, without significantly reducing the security.
  8. Message server instance identifier: Each message server has its own unique account identifier. This account is in the Smart Contract that maintains the chain of publickeys used to verify the message server transaction and thus the trustworthiness.
  9. Public key encrypted hash of values 1-8: To verify the message server transaction values including the current public key and the next public key, the values are hashed, and the hash value is encrypted with the current private key by the message server. The transaction can then be verified by performing the hash, and encrypting with the current public key. The resulting encrypted hash must match the encrypted hash value. The current public key must also match the stored “next public key” in the Smart Contract for the message server identification. Once verified, the value of the new next public key is the newly stored next public key in the Smart Contract for the message server identification.
  10. Rest of the message transaction: the rest of the transaction is identical in function to any other blockchain message to an account or Smart Contract.

Conclusion

Prasaga’s approach of a decentralized global messaging layer combined with multiple attributes of Distributed Ledger Technology (DLT) enables a democratized, trustworthy IoT DataGrid with global reach. Valuing DGT to the market prescribed value of information creates a reserve currency with an infinite underlying asset – Data. Prasaga will change the way data is communicated, sold and consumed. DGT will transform the way Smart Contracts are handled, and how IoT transactions are secured, validated and recorded, all whilst creating new markets and enabling a plethora of uncharted opportunities.

  • [1] The word “transaction” as used in this context represents the entire relationship between a buyer and seller, as opposed to a specific blockchain transaction.
  • [2] XMPP with XML Schema supports embedding alternative formats in the message contents. All initial data models defined by Prasaga shall be defined in XML, but other entities may use data models of their choice.

For more information, please contact Michael Holdmann (CEO) on [email protected] or visit our Team page for other members of the leadership team.