Prasaga Ecosystem Technical overview

Prasaga, Proprietary & Confidential 1

The Prasaga DataGrid
A decentralized distributed ecosystem for IoT (Internet of Things)
and ETD (Exchange-Traded Data)
Version 1.0
David Beberman, Ossip Kaehr, Yuan Wang, Michael Holdmann, Branden Laske
Abstract
Prasaga DataGrid is a decentralized network and platform for routing data streams dynamically
between distributed message servers and clients. It enables coalitions of businesses and others to
collaborate and help one another become more operationally efficient, sustainable, and cost effective, by
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.
* https://www.nrel.gov/docs/fy12osti/53864.pdf
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. Interoperability & Security – The creation of a message server peer network that is both
distributed & decentralized. Many entities working on IoT are discouraged to aim for a
distributed system due to attempting (and failing) to protect their “competitive edge” by keeping
data private. This causes a greater dependency on support of singular, proprietary systems with
little integration and third party application capabilities. Security is usually an “afterthought”,
and implemented in an ad hoc manner at best.
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
** https://newsroom.cisco.com/press-release-content?articleId=1847422

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.
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:
Entities: Devices (sources), DataGrid providers, Data consumers (sinks)
8 permutations
Device DG provider Data consumer Use-case
1 Anon Anon Anon X
2 Unanon Anon Anon NA
3 Anon Unanon Anon X
4 Anon Anon Unanon X
5 Unanon Unanon Anon X
6 Anon Unanon Unanon X
7 Unanon Anon Unanon NA

8 Unanon Unanon Unanon X
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:
1. Code identifier
2. Code Version identifier
3. Message Server hardware identifier
4. Previous block in blockchain identifier (has as the nonce)
5. Trustworthiness signature
6. Current public key
7. Next public key
8. Message server instance identifier
9. Private key encrypted hash of 1-8
10. 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.

Prasaga Ecosystem Technical overview

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Prasaga Ecosystem Technical overview

Similaire à Prasaga Ecosystem Technical overview (20)

Dernier

Dernier (20)

Prasaga Ecosystem Technical overview