Unique Value Proposition for Dragonchain

Episode 0x38 of Super Happy Dragon Lucky saw the return of the Ask Me Anything segment of the show. Never one to shy away from an AMA Joe Roets was happy to field questions from the audience.

By the way of Jeffrey Dragon, John asks, “What's the unique value proposition for Dragonchain?”

For Joe, it is and has always been about the architecture. Designed, built, and thrown against the rocks at Disney, the architecture contains a unique set of aspects specifically designed for the protection of business data.

Prior to designing the architecture of Dragon Net, several systems tried and tested at Disney, even though fully capable, ultimately were never built. These systems were deprioritized for one reason or another, which happens frequently. Even though these systems never came to fruition every one led to a general knowledge about what works and what does not.

For an architect, the design and testing part of building any system is crucial. Questions have to be asked, capabilities have to be known. Every attempt reveals answers to the question “Did that use case break the architecture?”

A golden rule for an architect working for the biggest companies: Will your system stand the test of time against any situation under any circumstance?

Joe let us in on how he approaches design. “I would train myself to get better and better at redesigning without much information. Normally the problem with a lot of redesigns is, if you and I are on the system for a long time, that we know the system and that is all we can see, it is pretty hard to redesign from there. I would come in on day one, get on a team, and say here is the system, here is how it works, this is where the customers are, this is where the data is, this is where this part of the system is, and what it talks to. All the rest of the stuff, and you would know we need to make this scalable, it might be old or put together by people who don't know what they are doing. I would break up this and this, draw a line here, separate these pieces, and clean it up. Do what we need to do to make it work. I would try to do that immediately, and then 6 to 12 months down the road, I would look at what I thought the very first day. And the goal is that what I wrote down on the first day, still stands true, 6 to 12 months later.”

With that repeated trial and error for a multitude of business use cases, Joe got really good at finding those pressure points. When he started looking at how blockchain could be implemented with these business systems, it was all about the combination of the features and different pieces of the tech and what are the points of abstraction.

Joe further defined abstraction. “When I say an abstraction with software, it's like a hinge. If you have something that’s brutal, and can only connect one way, or politics deem it impossible to connect that way, it will crack. It’s politics, budget, or other real world things that break that. For Dragonchain, I was taking blockchain, and envisioning all the places that everyone wished you could use it, and find all of those abstractions and hinges. For example with the protection of business data, nobody in their right mind would post customer data on a public blockchain, encrypted or not. Even with advanced encryption it’s not a great move. Anywhere in software where somebody might want to implement something in a different way, a slightly different configuration. Those are things that need to be abstracted, so that anybody could write their own version of their design goal. Most developers don’t look at stuff like that, they just say oh well here is the use case, A, B, C, D, or E, and that is not the way how it should be. The very obvious things need to be looked at slightly differently. When outside forces, be it politics, or adoption, or whatever else comes your way, your design should still hold. Will some real world event break that system?”

For Dragonchain, Joe took blockchain and envisioned all the places that everyone wished that you could use it and then searched for all those abstractions. In 2014 when Dragonchain was being designed this is what he found.

Protection of business data- Private data- health, financial, top-secret, etc, even with advanced encryption should not be stored on a public blockchain. Unimaginable amounts of data- Industries like Telco had billions and billions of rows with data. Blockchain could not perform, especially at that time. Security- Every business wanted security.

They plugged all those things together to build a software centric interop system to specifically answer the issues businesses face, today.

“We aren't trying to do what a lot of the other guys are doing with developing complex standards. With the architecture, it's much cheaper to change systems at that point in the future or in advance rather than trying to plan for the unknown. You can never know what's going to always happen in the future,” said Joe.

They also realized that there needed to be a way to incentivize people to run nodes to do the verifications. Some passionate people may volunteer, but the vast majority will need to be incentivized to support the decentralized systems.

Beyond Interop one of the most unique things Dragonchain has done is scaled fees. It's one thing to scale your favorite blockchain to Visa levels. With the speed at which technology moves it's now possible for some blockchain systems to realize the transactions per second of Visa. The really hard thing to do, and for a business one of the most important, is to have an economy modeled so that when that scale happens, it doesn't create so much backlog that you can't actually get a transaction on chain. Fees remain constant and don’t go crazy through the roof. This unfortunately is still a problem for every chain.

Dragonchain solved the economic scaling issue with the patented time based scarcity instead of using hardware as scarcity. The key aspect here is number one, if the network sees significant increases the nodes can immediately handle the volume. Number two, the fees don't go up and there's no congestion.

A trip down memory lane ended the show. When Rocco asked, “What was your favorite passionate moment while trying to solve a challenge?”

“I would say at the very beginning when we were defining some of the first parts of what became Dragonchain. It was an amazing thing when I realized, OK, these are just contexts and you can add more to them. We currently have five contexts, but you can have any number of them. We are always thinking about situational circumstances so the possibility is there to add more at some point late. We already have a couple in mind that we're considering adding to the network.

Another moment is when I realized that all of our answers were always philosophically defined. Even now I tell the devs to look at the architecture document. They can always come and ask me, but the architecture document already answers, at the high level, the goal. The implementation is whatever the best implementation is at the time. We've changed a couple of implementations since inception to give the best product.

And of course, TIME. We were having trouble with how to fairly award nodes from really low, TIME to high TIME. One morning I was driving into work when TIME came to me. I had to go in and have everybody check, does this make sense from all the different angles? And it did. We got a patent shortly after that on TIME. It’s interesting because that is primarily a scaling issue. In the past, we've sometimes phrased it as a loyalty thing because we use TIME as a basis for our loyalty system. But in the end, it's loyalty is scarcity, as network power. To me that's probably one of the more important things that I'd say by and large, most people don't get still. Someday, everyone will understand.”

Someday they will know.