Duality’s innovative Blockchain Directory Access Protocol (BDAP) is a component of the platform that provides a decentralized mechanism for resource hierarchy management, data sharing, and data storage. BDAP adds a layer of resource hierarchy comparable to Lightweight Directory Access Protocol (LDAP). It provides a distributed database and account linking to the Dynamic blockchain and its sidechains. Unlike other protocols in existence today, this makes it possible to develop core information systems from a hybrid public-private blockchain. The hybrid design allows both anonymous and identified (permissionless and permissioned) nodes to connect and share data privately and securely without a third-party intermediary.
BDAP accomplishes this by managing user accounts, group accounts, links between objects, audits, certificates, sidechain parameters, checkpoints, and identity records on the Dynamic blockchain. BDAP manages accounts similar to LDAP, but also stores linkages between accounts. BDAP’s resource naming models the internet, uses fully qualified domain names (FQDNs), and will automatically create a unique object identifier (OID) for every object on the blockchain. BDAP is currently registered with ANSI and has its own root level OID which it can use to assign child OIDs.
BDAP will facilitate the creation of decentralized applications. Examples of how BDAP is utilized includes:
- Create accounts for healthcare provider organizations and link them with other organizations on the blockchain.
- Fine grained access control and authentication.
- Deploy on sidechains to support private data transactions.
- Link BDAP accounts to create another set of public keys that are used to connect disparate organizations registered on the Dynamic public blockchain.
For additional insight we refer the reader to BDAP’s stand-alone whitepaper.
Miners and Transaction Validation:
The Dynamic blockchain makes use of a special two-layered approach to securing the network. The first layer is regular full-node instances of Dynamic called Proof-of-Work Miners. Like traditional blockchains such as Bitcoin or Ethereum, Miners play a crucial part in supporting the integrity of the Dynamic blockchain. This network of computers records, audits, and verifies transactions on the blockchain in a public list that can be accessed by anyone. Another advantage of proof-of-work mining is that it creates a random hash at every block which can be used by applications as a global random number generator.
The second layer used to secure the network is Proof-of Stake Miners. In addition to proof-of-work, proof-of-stake increases scalability, lowers maintenance costs, and keeps the chain running at a fast, predictable pace.
Dynodes:
Dynodes are collateralized full-nodes running the Dynamic blockchain. Dynodes require the operator to hold 1,000 DYN as collateral as well as dedicate their public internet address, CPU, memory, storage and bandwidth to the network. Each Dynode is rewarded for its service with DYN tokens as an incentive for supporting chain integrity and services. Dynodes help to lay the groundwork for blockchain services and are needed to propagate transactions faster and perform services like decentralized network routing and storage for BDAP. Dynodes provide the blockchain users and applications with an extremely fast global network relay system that is used to send instant messages for decentralized applications. Dynodes also currently host a Distributed Hash Table (DHT) and will be further developed to support hosting distributed document, SQL, and NoSQL databases. Dynodes also currently support additional auxiliary services like PrivateSend and InstantSend. PrivateSend is intended to protect user privacy when using tokens to pay for database, network and/or storage services. PrivateSend uses the CoinJoin method to anonymize assets. InstantSend is used when immediate blockchain transaction settlement is required. InstantSend can finalize a transaction within seconds, instead of waiting for the next block which can take minutes.
KYC Nodes:
In order to ensure compliance with data sharing standards, both in the US and internationally, participants on the platform that plan to share and utilize common healthcare data sets in their applications, even if anonymized, must be credentialed and verified. In order to do this in a semi-autonomous fashion Duality’s network will have a tier of five KYC Nodes per geographic region.
KYC nodes, after a successful KYC accreditation, are responsible for issuing certificates to a Requestor, defined as the individual or organization that is requesting access to a protected data set, sidechain, or communication channel. The KYC nodes are ultimately responsible for ensuring that the network has a clean user base of verified locations, providers, and developers. It is anticipated that major healthcare oversight and innovation organizations will assume the roles of the KYC nodes as the network matures.
To initiate the KYC request, the Requestor will use Duality’s KYC interface which packages all of the requested information required for the KYC node to complete its verifications. Once the packet of information has passed through the initial screening performed by Duality’s KYC interface, which uses an artificial intelligence to check for completeness of the data packet, the five KYC nodes will be placed in a verification queue using a random number generator from the PoW mining hashes. The first KYC node is responsible for the full verification process. The second node is responsible for performing an audit of the first KYC’s work to ensure the verification work was done thoroughly and accurately. The remaining nodes serve as backups in the case the first node does not pick up the data packet for processing in a timely fashion, currently earmarked at 24 hours. If the first KYC node does not pick up the data packet for processing within the 24 hour time frame, the second node will assume the role of the primary credentialing node with the third node assuming the role of the auditor. This process would continue until the packet is picked up and the credentialing process is started.
To incentivize participation as a KYC node a payment will be made in DYN from the Requestor. To automate the payment process DYN will be wrapped in a smart contract that settles based on proof of service. Proof of service is defined as a result issued to the smart contract from the KYC node as either pass or fail. The payment will be split 80% to the primary validation KYC node and 20% to the audit node.
Distributed Hash Table:
A distributed hash table (DHT) is a class of decentralized distributed storage systems which provides lookups similar to a hash table. Key/value pairs are stored in a DHT, and any participating node can efficiently retrieve the value associated with a given key. The responsibility for maintaining the mapping from keys to values is distributed among BDAP nodes in such a way that a change in the set of participants causes a minimal amount of disruption. This allows a DHT to scale to extremely large numbers of nodes while being able to handle continual node arrivals, departures, and failures at the same time. BDAP leverages the Kademlia DHT which provides robust resistance to attacks like denial-of-service attack via its ability to recover itself. Applications can use the DHT to store encrypted application cache needed by the BDAP account running the software at runtime. Applications built on the Duality platform can also use the DHT to store encrypted account linkage cache. For example, a single sign on application can use the DHT to store the provider’s credentials. Unlike blockchain storage, DHT cache can be deleted, is mutable and doesn’t need a transaction to commit. A thin client can be used to bypass the blockchain and access data in the DHT directly with BDAP account private keys.
Initially, Duality will support MongoDB for its document database functionality. YugaByte will handle more complex database applications and supports PostgreSQL and Cassandra wire formats, providing the ability to port existing applications written for those popular data management systems. BDAP authentication will be required to authenticate and authorize access to those data stores.
Attestations and Certificates:
Certificates contain a public key and an identity (a hostname, or an organization, or an individual), and are signed by a trusted certificate authority. Once validated, someone holding that certificate can rely on the public key it contains to establish secure communications with another party, or validate documents digitally signed by the corresponding private key. Certificates are used to attest to and authorize what accounts belong to valid credentialed healthcare providers so other participants can establish trust relationships. The certificates use an industry accepted X.509 standard.
Provenance and Audits:
Duality relies on the Dynamic public blockchain for its powerful auditing capabilities. Since blockchain records are immutable over time and replicated by the public, they make the perfect timestamp and proof of existence system that applications can use to audit system events such as patient enrollment and registration.
End-to-End Encryption:
Duality has developed Very Good Privacy (VGP), an end-to-end group cryptosystem library, to provide an encryption layer which goes well beyond current Pretty Good Privacy (PGP) encryption programs to protect privacy and security. VGP is modeled after PGP cryptosystem by using public key cryptography, symmetrical encryption, Diffie-Hellman key exchange and hashing for pubkey fingerprinting. For additional insight we refer the reader to VGP’s stand-alone whitepaper [ref].
Ephemeral Token System:
An innovative ephemeral token system is used to enable just-in-time access to sensitive data so it can remain in the control of the original custodian within their systems instead of duplicate copies housed in a central repository. The temporary access token expires within minutes so that the sensitive data exchange mechanisms do not remain open to exploitation. The ephemeral access token is verified by the identity service API, discussed below, and creates an audit that records when, where, and who accessed the data.
Fluid Protocol:
Duality has developed Fluid Protocol to handle self-regulation, arbitration features, and voluntary governance without going through contentious hard forking scenarios. The Fluid Protocol is a mechanism to change the consensus rules of the Dynamic blockchain, to enforce self-regulation, change the reward amounts for Miners and Dynode operators, and respond to arbitrations (account revocation, etc). For additional insight we refer the reader to the Fluid Protocol whitepaper [ref].
Oracles:
Duality will have oracle technology built into its platform. The oracle is a way for the blockchain or its various smart contracts to interact with external data points such as exchange prices, other blockchain data sets, database sets, etc. The oracle technology builds the path between off-chain and on chain events and can be easily deployed and utilized for application development. The immediate use case of the oracle technology is within the Arbitrage Smart Contract.
In addition to the technology discussed above, the Duality platform will launch with a set of prebuilt APIs designed to simplify the integration of our identity and data sharing protocols. When combined, these APIs provide the basis for accurate patient matching and data interoperability in a way that is secure and scalable.
Identity Services API:
Duality’s identity service API, dubbed NoID, uses hashed biometrics (biohashing) and hashed demographics to facilitate highly accurate, cross organizational data matching without exposing Protected Health Information (PHI) or Personally Identifiable Information (PII) to a central authority. The hashed biometrics and demographics create tokenized identity profiles and are hosted by private permissioned sidechains. This architecture reduces the security risks usually associated with high scale biometric identity system deployments and creates an identification protocol that is fully HIPPA compliant. This API package will include an enrollment web browser plug-in that provides bimodal biometric authentications, data anonymization, artificial intelligence, FHIR messaging, and biohashing. This is a key API that sets up the Duality platform for interoperability in a way that is accurate, secure and scalable.
NoID implements cross organizational patient matching by using a novel biohashing identity service built on top of Hyperledger Fabric (HLF). Before patient data is sent to the identity service, it is hashed to remain anonymous yet maintains the ability to accurately match. The identity service uses proximity queries for the biohashes and deterministic or exact match queries to confirm the demographics is similar for a particular biometric profile. When a match is found as a result of a participating organization query, a relationship is formed with the patient so that it can return location pointers on where a particular patient’s data resides. After a successful patient identity match, the service returns a list of record locations with an ephemeral access token for each location so it can start the P2P data fetching process.
For more information, please see the technical white paper [ref].
File and Data Sharing API:
WebBridge is Duality’s P2P data sharing protocol. This network has the innovative ability to connect through firewalls and NATs using a transient WebRTC connection with signaling initiated by the Dynamic public blockchain. WebRTC uses the latest TLS protocol with AES encryption and eliminates the need for a central host and site to site VPN connections. vWebBridge is open source, has a highly-developed user interface plug-in, and will be used within the Duality platform as a means to securely share sensitive data. The vWebBridge is the key API that sets up the organizational connectivity for all applications and stakeholders on the Duality platform.
Medical Terminology Engine:
Duality will have a medical Terminology RESTful API that manages medical semantics, vocabulary, internal codes, and nomenclature curated by machine learning and rewarded experts. This is a key API that standardizes data sets among disparate sources to ensure it is digestible and meaningful.
Clinical Data Aggregation Engine:
Responsible for standardizing EMR and other healthcare data when aggregating from multiple sources. A sophisticated AI that presents relevant clinical data for the clinical support.
Patient Portal:
Patient wallet used to control data access by issuing access tokens to third parties like health insurance providers, accountable care organizations and clinical research networks. Allows the patient to view audits — who, when, and where your data was viewed.
Keep up to date by following us on our various media outlets below.
Enjoy your weekend and keep up the community marketing excitement! Thank you for your continued support. We couldn’t do it with you!
Want to catch up on what you’ve missed?
Just give https://medium.com/@duality.chain a visit and you can find all our previous blog posts.
Have some questions about Duality? Join us for a chat
Discord — https://discord.gg/3Wg7CaT
Telegram — https://t.me/DualityOfficial
Main Website — https://duality.solutions/
Contact Email — contact@duality.solutions
Github — https://github.com/duality-solutions
Facebook — https://www.facebook.com/dualitychain/
Twitter — https://twitter.com/DualityOfficial
Refer to our website for more information. https://duality.solutions
