Dragonchain Chief Technology Officer Paul Sonier.

While attending Blockchain Seattle 2018 you could attend various workshops presented by Dragonchain. 'Reimagine consensus' by Dragonchain CTO Paul Sonier was one of them. This recap is limited to just this single presentation and does not include everything that has been covered by Paul Sonier. To learn even more after readin this post, there are at least 4 different other sources to continue learning about Dragonchain.

Prior to joining Dragonchain Paul Sonier gained over 20 years of experience desgining and developing software for various companies. Amazon, Microsoft, Disney, you name it.

What is DragonNet?

Dragonchain CMO Jonel Cordero explains: ''DragonNet is a scaled approach to consensus that utilizes independent network verification nodes that are provisioned by the Dragonchain Community. The verification nodes verify blocks from business nodes (Level 1 / L1 Nodes) in a marketplace based on scarcity of DDSS (Time). The approach is consensus based on verification from different contexts through our Spectrum of Trust (5 Levels) Each node at each level has it’s own blockchain and is non-homogenous, meaning all nodes do not contain the same information''.

DragonNet architecture by Dragonchain. During Blockchain Seattle 2018.

Scaled consensus.

DragonNet is build on the Dragonchain platform and achieves unlimited scaled consensus. But what does that mean? If you look at other public blockchains, like Ethereum and crypto games like CryptoKitties. They achieve consensus, but don’t scale well. By having independent network verification nodes, Dragonchain achieves scaled consensus. The business nodes ( L1 nodes) are private. Dragonchain is a hybrid public/private blockchain by definition. On Dragonchain, you can run an L1 node, that is it’s own blockchain. And the data on that blockchain remains private. External partners — or we as community members — can run network verification nodes and verify the L1 nodes by taking the hash, and recording that on our own L2 nodes. Every L2 node in DragonNet is it’s own public blockchain as well. There is no mainnet in DragonNet. L2 nodes verify the blocks on their own blockchain from any random L1 node existing in DragonNet. Without making private business logic from L1 nodes public. Very important to know.

''There is no mainnet. No mainnet. I've been waiting to present this slide for a long time. There is no mainnet, we have a different approach. Please stop asking,'' — Paul Sonier.

''The other main functionality is that we are using the scarcity of time to basically make the economics of DragonNet work. We're looking at this incapsulated in the DDSS, Dragon Days of Slumber Score'', Dragonchain CTO Paul Sonier explaining this unique economic loyalty reward system.

We will get back to the DDSS later in this post. Because the matchmaking pool will show how ingenious the reward system Dragonchain created for DragonNet works. How it works for the community, the holders of the tokenized microlicenses, running publicly provisioned nodes. First let's have a look at the use for all the various levels of nodes. Again, all credit for this information goes to Dragonchain.

Level 1 — Business (Approval) Verification

Approval functionality is implemented and configured by the business integrator. This is the placement for integration of “real world” value. Business logic defined by an organization or blockchain platform user is configured to be executed by a blockchain node.

Here also is where the transaction payload is defined by the business to be what is needed for their purposes.

Transactions are arranged and passed to the provided business logic which will determine approval or denial. Approved transactions will be assembled into a “block” generically referred to as a “verification record”.

The payload field of every transaction may be stripped before or after assembling the final block in order to maintain control of the distribution of actual business data. That is, no business payload data will be disbursed as part of the consensus process, and data will remain local on a Level 1 node unless the business owner explicitly pushes the data to another node (e.g. for backup/DR), or explicitly allows an authorized node to pull the data via a subscription feed.

Level 2 / L2 Node — Enterprise Verification (Validation)

Level 2 nodes are a trusted check of validity for blocks and individual transactions which can be done without seeing the actual data. Rules for L2 Nodes are defined at the enterprise level.

Overview

A Level 2 Nodes provide “Real-Time Enterprise Governance” with rules defined at the enterprise level, and checks for block and individual transaction validity in form, signature, and required data elements. This can be considered as providing “Real-time Enterprise Governance” with rules defined at the Enterprise level for validation of all transactions regardless of the local business data.

Verified elements:

Block (verification record) construction and signature

Individual transaction signatures

Individual transaction header elements (that all required header fields are present)

A Level 2 will assemble a new verification record which will contain:

A list of valid transactions and a list of invalid transaction, and in this manner vote on the validity of individual transactions.

The hash of the prior Level 2 record created by this proof for the same origin (Level 1) proof (thus creating a Level 2 blockchain)

The hash of the Level 1 block which was validated (thus providing a second dimension to the blockchain)

Proof owner identity information

Proof deploy location (data center)

Proof key management authority information

Level 3 / L3 Node — Network Diversity Verification

Level 3 Nodes verify diversity of validation (Level 2) verifications. This verification context will ensure that validations of transactions are coming from a sufficiently diverse set of distributed sources.

Overview

A Level 3 Node will verify diversity of validation (Level 2) verifications. This contextual verification will ensure that validations are coming from a sufficiently diverse set of distributed sources. It also provides control and measurement of network effect and provides distributed security as an attacker would be required to attack multiple organizations and data centers in order to tamper with transactions.

Level 3 Nodes will check the following criteria:

Count of Level 2 verification records have been received

That those records have come from (configurable count) of unique business units

That those records have come from (configurable count) of unique deployment locations

That those records have come from (configurable count) of unique key management authorities

A Level 3 Node will assemble a new verification record containing:

Remnants of criteria met (e.g. Level 2 verification record count, set of business units, set of data centers).

The hash of the prior Level 3 record created by this node for the same origin (Level 1) node (thus creating a Level 3 blockchain)

The hash of the Level 2 verification records which passed the criteria (thus providing a second dimension to the blockchain)

Level 4 Node — ​ ​External​ ​Partner​ ​Verification​ ​(Notary)

A Level 4 node provides a notary functionality to the consensus process.

Overview

Defined network wide (Enterprise+), a Level 4 node provides a notary functionality to the consensus process. Hosted by an external partner, a level 4 node cryptographically signs any level 3 verification record that it receives. This function allows the Level 4 node to act as an independent witness to level 3 verifications.

Level X — Proprietary context verification

It should be possible for a business, Enterprise, or the entire network to define a custom verification context and have it executed to meet business needs.

A node may be configured to run an arbitrary verification context which would be triggered in the following manners:

By the receipt of a broadcast from another node (in sequential or non-sequential phase)

By a timed or periodic trigger (e.g. cron)

By notification via observer pattern

You can read here about the creation of an L2, L3 or L4 node. And read here about the costs to spin them up. If you can't wait to get started and build on the Dragonchain platform, go ahead and just click here.

DragonNet Matchmaking Pool Diagram by Dragonchain.

Now we get to the interesting part which is called the Matchmaking Pool, for L2 and above nodes. Friendly reminder, a lot of more in-depth details are still missing here. Dragonchain will have their own post(s) about all of this later on. They might even have recorded this presentation but I'm not sure about that. So just as important as the fact that there is no mainnet. This is not a 100% complete guide on the matchmaking pool. Please don’t shoot the messenger. :-)

L1 nodes connect to L2, L3, L4 and L5 nodes through a global matchmaker process. L1 is the gatekeeper or mediatior in the process and finds the higher level nodes thanks to the matchmaking algorithms. All the nodes go to a matchmaking pool and they have a different size. It's given a weighted size or score to a node that is directly proportional to the DDSS score of the operator of that node. And the price they are charging. By increasing DDSS or decreasing the price you set, you can increase the chance of being selected during the matchmaking process. There is a lot more to it though, which will be explained by Dragonchain. It is not just the price or DDSS from L2 nodes and above that determines the likelyhood of getting selected. To prevent some issues and problems, they come up with a solution.

The private L1 nodes have their own matchmaking requests system, also based on the scarcity of time (DDSS). The lower the DDSS that goes along with the owner of the node, the less retries they get per block. Just one to be precise. If you have a super low DDSS, you won't get any retries in a block, it will have to wait untill the block is completed. And can make a new retry in the new block. (Every 5 seconds a block is created) With a medium DDSS the L1 node will get multiple retries in the same block, about 30% of the weight in the matchmaking requests. And with a high DDSS you will get many retries in a block. The effect of that is that L1 nodes with a high DDSS get a high matchmaking retry account.

They are however not gauranteed to get a compatible L2 or higher on matchmaking. It will be a completely random selection. If you try to set a low price on the transacations you want to pay, you may only be able to get 10% of the pool. On average you would have to make 10 requests to get the number of nodes for validation. That means, as your DDSS goes up, you can make the 10 requests within the same time period. In the same block. With a higher DDSS they will be able to pay less because they get more frequent retries per block. I hope this makes sense for you reading this, because this is all I can make of it right now.

On the requester side (L1 nodes), the clear economic encentive is to allow them to define the costs. They can pay more or increase their DDSS score. On the L2 nodes and higher, the price and DDSS both put together is your weighted number, which determines the likelyhood to be selected. You can increase the likelyhood by decreasing the price. Or increasing the DDSS, the amount of incapsulated time.

''This is the solution to mining and transactional cost problem in Dragonchain. L2 through L5 nodes are basically the version of mining that exist on Dragonchain. These allow network consensus to occur. At the same time the ability to set the price for the number of retries is very much equivalent to mining. For example the GAS price on Ethereum and the ability to alter your GAS price. I see some confused faces. It's a little tricky, but it works. It works nicely. Scarcity is one other important thing to mention. Without scarcity there are no economics possible. Scarcity must exist in some sense. It is effectively low in the cloud. Pretty much whatever your top is, AWS can handle it. They have the resources. They can scale out effectively. What we're using for scarcity is DDSS. You can add resources to a system and effectively decrease the scarcity. But you can't add time to a system. You can't falsify time. DDSS is a way of us defining exactly that scarcity of time. The accumulation of time'', Paul Sonier.

One other benefit of Dragonchain is scalability. Scaling on Dragonchain is infinitely. Most other existing public blockchains are not designed this way. They will scale slowly, like Ethereum and Bitcoin. Dragonchain is capable of achieving internet scalability. Issues like scalability with CryptoKitties will not happen on Dragonchain. They scale very quickly.

A note from Dragonchain CEO Joe Roets from the official Dragonchain Telegram:

- lack of scarcity in cloud resources therefore DragonNet uses scarcity of time as captured with DDSS to make marketplace incentives work

- within DragonNet, there is still no scarcity of resources, therefore network marketplace has _theoretically_ unlimited scalability.

- for example, an orders of magnitude increase in traffic can be handled by existing network nodes which will earn directly proportional to the increase

Once again, all credit for the content in this post goes to Dragonchain and CTO Paul Sonier. Unless I made some mistakes anywhere in this post, I'll take credit for that. ;)