DragonNet

Recently the community has been buzzing about setting up our nodes. Thanks to community run efforts, more and more DRGN holders are spinning up unmanaged L2 nodes. (If technically challenged this guide may help.) So, I thought now would be a good TIME to dive into the five levels of verification in DragonNet. As usual, while writing this, I had to look up some terminology and peel away the cobwebs to understand the system Dragonchain has developed. Prior to this I said to myself “Self, there are 5 levels, business is level 1 and public is level 5, there you go.” But now, I have a better understanding on how the five levels are built on top of each other and work together. Now, after taking a closer look, the security of Dragonchain’s platform is very evident. Let’s break it down so you can better understand what your node is validating, or better yet, what place your node holds in validating business data.

Level 1 Nodes: Business Logic

At this level, criteria is assigned as determined by the individual business for each transaction it wants to interact with the blockchain. (Let’s mention here that the word transaction doesn’t refer to a financial transaction, it’s simply record of the event that happened.) The business only interacts with the blockchain at this level, leaving the validation and on ramping to the public blockchain to our validation nodes. Once a transaction happens, it is arranged based on criteria the business stipulated via a smart contract. The data is put into a block, now referred to as verification record. The sensitive data, ie secure information, can be removed before or after the verification record block and no business data has to travel with the block to the next stop in the consensus process. The data remains with the L1 unless queried via specified criteria. Integration with legacy systems happens at this level. With RESTful API in common with an enterprise, Dragonchain can wrap defined data in a JSON package.

I know, me too. Let’s define the terms. RESTful API is a modeling language based on YAML. YAML is human readable data-serialization language used for configuring files in applications where data is being stored or transmitted. (Basically the systems can “talk” to each other.) A JSON package holds various metadata relevant to a project. It’s located in the npm, node package monitor. Node package monitor is an online repository for publishing open-sourced Node.js projects. It’s also a command line tool to interact with the repository to aid in installation.

Once wrapped, the package “calls” the enterprise’s Level 1 node to put the data on the blockchain. By now you have heard Dragonchain’s patented public/private hybrid platform offers enterprise the flexibility and security they need to integrate with blockchain. But what does that even look like?

Use Case:

Epic Systems is one of the largest providers of health information technology. Large U.S. hospitals and health systems use Epic to access, organize, store and share electronic medical records. Let’s say Epic wants to track allergic reactions to MRI contrast at a particular hospital and they want to allow contrast manufacturers to have access to the data. The hospital uses two different contrasts, Gadavist from Bayer and Prohance from Bracco, so we will also need to further define how many allergic reactions are occuring from each different brand of contrast as well as at what dose. When an incident report is entered into EPIC for a contrast reaction, it triggers the data (contrast name, dose, severity of reaction) to Epic’s L1 node. Epic’s L1 node can stipulate that after the transaction is confirmed by a set of criteria, then an outside entity (In this case Bayer or Bracco) can pull that information or alternately, Epic can push that information out. Bayer and Bracco can see, realtime, what affects the contrast is having on patients. An increase in reactions can trigger questions as to why the reactions are happening and decrease negative outcomes before they become catastrophic. The information obtained only contains the limited data and not individual patient information, thus complying with HIPPA regulations.

Level 2 Nodes: Validation

From the L1 node, the transaction is validated at the L2 level. The rules or guidelines for the L2 node are written at the L1 level by the business itself. The L2 will validate the transaction and can be done with or without exposing the actual data, as determined by the stipulations set up at the L1 level by the business.

L2 will first validate the following criteria:

1. L1 block (transaction) construction and signature. (that it comes from that particular L1)
2. Individual transaction signatures. (a digital signature proves you have the private and public key without having to reveal the actual private key. Every digital signature is unique to the individual transaction.)

*Math TIME: private key + transaction data= digital signature. Then the digital signature + transaction data+public key = confirmation a legitimate private key was used to create the digital signature.

3. Individual transaction header elements (a header is within every block and is basically a summary of the block contents themselves. It’s like an index of what the block will contain.)

Then the L2 assembles a new validation record, or block, containing the following:

1. List of both valid and invalid transaction, selecting the valid transaction.
2. Hash of prior L2 (valid transaction) which has the hash of the origin L1 proof resulting in a new L2 blockchain. (A hash takes in data from previous validation then releases an alphanumeric value called hash or digital fingerprint. Each hash confirms transaction on the blockchain.)
3. The hash of the validated L1.(creating yet another dimension to the blockchain)
4. Proof of owner identity.
5. Proof of deploy location. (disperse node locations)
6. Proof of key management authority information. (that it has the keys to validate)

Level 3 Nodes: Network Diversity of Level 2 Nodes

The L3 checks that the L2 validation process has been distributed across a wide array of nodes. It’s inherently secure in that if there was an attack the attackers would have to go after multiple nodes in order to alter transactions.

The L3 nodes check the following:

1. Count of L2 received. (how many L2 blocks)
2. Make sure those records are from a determined number of unique business units.
3. Make sure the records come from a determined number of unique deployment locations.
4. Make sure the record come from a determined number of unique key management authorities.

Then the L3 node creates a new block with the following:

1. Remnants of all other prior validation. (L2 verification record like unique locations of nodes, and business units.)
2. The hash of prior L3 record created by the L3 node for the same origin (L1) thus creating a L3 blockchain.
3. The hash of the L2 validation record that approved the criteria thus providing a second dimension the blockchain.

Level 4 Node: Notary

The L4 is hosted by an external approved KYC partner who cryptographically signs the validation record received from L3 node. It’s an independent witness to L3 validation.

Level 5 Node: Public Checkpoint

This is where our patented Interchain(™) comes into play. This is the gateway from Dragonchain to other blockchains such as Bitcoin, Ethereum, Ethereum Classic, etc necessary to support flexibility and adoption. Just like we can’t all agree on, well anything, we will never settle on just one blockchain. Dragonchain is the first to make it possible for all blockchains to integrate. They do this in any language a dev team could think of and with the technology to integrate with any legacy system currently running or currently being dreamt. Dragonchain is the blockchain of the future.

Hopefully, you now understand the structure of Dragonchain’s platform a little better. It’s easy to see why Dragonchain really is lifetimes ahead as no other platform offers this level of security and flexibility. Dragonchain has developed the tools to pave the way to adoption. All Blockchains Welcome. All Languages Welcome. All Legacy Welcome. All Humans Welcome.