Dock’s Blockchain Protocol Evolution

Dock is making great progress on our protocol. We have been evaluating blockchain scaling solutions for the Dock protocol and are designing a hybrid Ethereum solution that gives us the benefits of the public main net while also the cost and scale advantages of a L2 solution. After evaluating 6 scaling solutions, testing multiple PoC’s, we’re currently doing heavy testing for Plasma Cash based on our scaling approach. Our blockchain protocol progress is moving rapidly while we also confront the challenges, and the constraints that have to be worked through to design a scalable blockchain architecture. The first step for any good design effort is to have well defined requirements.

Dock Protocol Requirements:

• Dock is a data exchange protocol
• User should always be in control of their data
• Data exchange should be censorship resistant
• Partners should be incentivized to open their data silos and exchange data with users and each other
• Transaction cost
• No cost to users to share data
• Should be as cheap as possible for partners
• High Transaction throughput
• Payment finalization guarantee for partners

The Problem

Blockchain technology is still evolving and there are no well proven options today that are secure, decentralized and scalable at the same time. Most private blockchains don’t give you enough decentralization, whereas public blockchains don’t give you enough scalability.

Image courtesy, from here

Dock is an open protocol and should be used on a public blockchain (Ethereum in our case). That means we have a huge scalability issue to be solved and as you’ll see later our business model of always keeping user in control and never incentivizing users with tokens for data exchange adds its technical complexities as well.

Blockchain Solution Evaluations

Solution 1: All transactions on main chain

In this approach all transactions and smart contract are executed on main chain. To achieve scalability in a reasonable timeline, we decided to pursue Ethereum’s Level 2 solutions to augment the main net with scalability and cost-efficiency. A good explanation on Layer 2 approach to solving ethereum scalability can be found here.

Image courtesy, from here

Our primary considerations for an L2 solution are:

1. Safety over liveliness
2. Minimize chatter with the main chain
3. Minimize cost and friction for benign Dock side chain participants
4. Select a solution that withstands the rapid rate of innovation and progress in the space

Dock decided to start with state channel based approaches for select initial PoCs.

Solution 2: Custom State Channel Implementation

To improve on the first solution , a design iteration was created to balance both technical and business model constraints with a feasible design. These are the considerations:

• Decrease complexity by splitting transactions into 2 channels
• User: Producer
• User: Consumer
• Finalization Incentive (how to incentivize one of the actors to finalize the transaction)
• User: Producer — Producer finalizes transaction since they will get paid
• User: Consumer — Leverage staking: consumer loses deposited stake if they don’t close the channel in a timely manner

After considering various requirements and constraints, Dock designed the following flow:

Main highlights of this approach:

• Payment guarantee: Consumer receives data upfront, but receives the key to unlock the data only after payment.
• Double encryption: Encrypt file first with the consumer’s public key and then the symmetric encryption key.

Despite satisfying a number of requirements, the design of this solution quickly became too complicated and not feasible to implement.

Solution 3: Generalized State Channels: 3 way contract

We choose to look at some generalized state channel solutions with a 3-way smart contract between the user, data producer and data consumer. The goal was to:

• Reduce custom code by using existing solutions
• Reduce code complexity

Dock evaluated Raiden and µRaiden, which still are potential secondary options for completing payments. After researching Celer network Dock discovered that Celer’s current consensus model is not in line with our requirements.

Solution 4: Generalized State channels: 2-way contract

Dock decided to split the 3-way smart contract into 2 separate smart contracts, one between the User, Data Producer and Data Consumer for data exchange only, and the other between the Data Producer & Data Consumer for payment operations. Main highlights of this approach:

• 2 separate channels (with payment dependency between them)
• Reduces number of channel combinations (which means lower cost)

This approach is shown in the diagram below:

This approach was feasible enough to proceed with code on select POCs. The results from the POCs led to the conclusion that the design would take too much control away from the individual whose data is being exchanged which violates one of our core requirements.

Solution 5: Plasma style side channel

Plasma side chains are anchored to the mainnet thereby allowing dispute resolution or even the entire side-chain to be rolled up to the main net.

Utilizing a plasma style side channel can lead to simpler smart contract designs however the technical constraints prevent it from being usable at this time.

Solution 6: Plasma Cash

Plasma Cash based design seems to be a feasible option. The most salient difference between Plasma (MP) and Cash is that Plasma cash is geared toward a subset of the application space functioning with fungible tokens. These are tokens “marked” with a serial number, just like fiat cash, hence the name Plasma Cash, making ERC721 tokens an excellent token protocol.

We are currently working on the design approach of using Plasma Cash with a validator node in a PoS model. It looks very promising due to following factors:

• Several actively supported reference implementation and strong Foundation support.
• Simpler contract design since there is no longer a scalability issue with 3 party channels.
• The same contract code should mostly work in Plasma, other EVM based L2 solutions or even on main chain if adopted in the future.
• If a validator misbehaves, parties can directly ‘exit’ to the main net for dispute resolution.

Dock has designed a flow that so far meets the requirements for the protocol and in the process of implementing PoC’s to test feasibility. .

The team also started working on initial state transition models in the context of a hierarchical finite state machine (HSM) architecture that can handle the complex technical and business requirements of the Dock data exchange protocol while keeping the gas expenditures in check.

The principle PoCs testing with Plasma Cash has been completed already on several crucial functions like deposit, send transaction, exit funds, challenge etc to validate our assumptions and test feasibility. There are some areas that need further feasibility testing before going full steam on implementing this design and they are actively being worked on.

Overall we are excited about the Plasma cash approach since it not only allows us to enable data exchange over IPFS between partners while keeping users firmly in control, but also adopt a token economics model that incentivizes all parties to participate in creating the network effect. This approach aligns with our scalability requirements while being cost effective for partners as well.

Well, it’s exciting times at Dock getting immersed at the very cutting edge of Layer 2 scalability solutions and trying to solve a very complex technical and unique business problem.

More to come, stay tuned!