Moving Towards Scalability: Dock’s Plasma Cash POC
Overview
Dock is a data exchange protocol designed to keep users in control of their own data at all times with cryptographic guarantees about data integrity and flow. The concept is two-sided. On one side, Dock provides an option for internet users to free themselves from the centralized, monolithic, data-hungry organizations that keep user data hostage in well-guarded silos. At the same time, it provides an option for progressive companies to build services where data exchange between companies is incentivized to break the data silos. Across the board, this data exchange is always controlled by the users’ permission of their own data.
We have been working towards this mission on both the blockchain side, which is the core infrastructure layer to realize the Dock vision, as well as on the user side with a working App for users and APIs for partners to get initiated with the Dock vision.
The biggest challenge that we face, like many other projects that want to use blockchain at scale, is to architect a scalable solution to implement the Dock protocol. A lot of projects on various major blockchains are working on different approaches and we compared a few for our use case in an earlier post. Since then we have successfully developed a POC rooted in a Plasma Cash-based approach.
In this post we will discuss our goals and findings from the POC as well as discuss how it all works together to solve the scalability problem for our use case. We will also share some of the challenges and the road ahead of us.
Dock POC Goals
The main goal of the Dock protocol blockchain POC was to test the feasibility and benefits that we hypothesized a Plasma Cash based solution might bring to our use case. The ERC-721 token has unique properties so we also wanted to demonstrate how we can leverage it in our solution.
Below are the POC goals we defined:
- Substitute generic ERC-20 for DOCK tokens to purchase ERC-721 tokens.
- Demonstrate that all data exchange logic can be carried out by using ERC-721 token.
- Allow participants to exit the Plasma node and exchange the ERC-721 tokens back to ERC-20 token.
- Implement a ERC-721 UTXO handler off chain in the plasma node.
- Implement a basic Transaction validator for the settlement process pertaining to the data exchange workflow.
- Implement a scalable solution of a happy case scenario using a single trusted node.
Dock POC System Design
The Dock protocol blockchain POC consists of three main layers:
- Ethereum Mainnet Contract: The hook for the participants of the system to trust the off-chain Plasma node.
- Plasma Cash Layer: Provides the ERC-721 token manipulation in response to data exchange between participants.
- Dock Workflow Manager: The agreement between parties and user’s sign off for data exchange is recorded in this layer.
The POC design in more detail is outlined in the diagram below:
Let’s look at each layer in more detail:
1. Ethereum Mainnet Plasma Contract
This contract has the following major functions:
- Provide the entry point for participants into the system
- Ability to transfer ERC-721 tokens between participants
- Ability to withdraw Dock tokens
- Exit for participants from the Dock system
The Plasma smart contract is deployed on Ethereum Mainnet as depicted in the diagram above. Upon entry the participant has to deposit an amount of DOCK tokens, which is converted by the contract to the equivalent number of ERC-721 tokens (based on established exchange rate). In order to assign tokens to new entrants the contract has to mint new ERC-721 tokens. In that sense, the contract serves as both the ERC-721 foundry (to mint new tokens) and Vault (to hold minted tokens). The account balance of all participants is maintained by the contract and only updated in these cases:
- Whenever the proof chain for delta of off-chain transactions is submitted by the Plasma node.
- When the participants exit the Dock system after withdrawing all their Dock tokens.
Also, in the current POC there is no way for participants to reload their accounts. The dispute path on the Mainnet contract is not implemented as part of this POC and will be explored in further updates.
2. Plasma Cash Layer
The main job of the Plasma node consists of the following functions:
- Onboard new participants listening to entry events from Mainnet contract
- Serve as Transaction validator
- Maintain ERC-721 UTXO sets
- Provide ability to settle data exchange transaction payments off-chain
- Add persistent state storage
This is the layer that provides scalability to the DOCK protocol. It is here that all off-chain transactions are managed so they do not need to be recorded on the main chain. By doing so, the Plasma Cash node creates throughput at scale and also significantly decreases transaction costs.
In practice, the Plasma node receives the data exchange request signed by all parties, verifies signatures and creates a ‘transaction’, which is then sent to the UTXO manager to ‘settle’ the payments between participants.
Currently the Plasma node has been implemented as a single trusted node so there is no dispute process and all transactions are final. In the next iterations, ‘trustlessness’ elements will be added to this layer as the POC scope has now been realized.
One of the main highlights of this Plasma Cash layer is that using the characteristics of the ERC-721 token we are able to abstract the data exchange transactions from the Mainnet contract, so that the Mainnet contract only needs to deal with ERC-721 payment verifications and nothing else. That greatly reduces complexity at both layers due to separation of concerns (see ‘Why ERC-721’ section below).
We also added MySQL-based persistent state storage at the node level allowing us to begin work on node (crash) recovery and other replay scenarios.
3. Dock Workflow Manager
This layer mainly deals with coordinating the data exchange workflow required to build a valid transaction. Data exchange requests are signed by three participants in this layer — Data Producer, User, and Data Consumer — prior to being sent to the Plasma node for processing each transaction.
This layer will also provide the interface for individual users and REST APIs / SDKs for partners to interact with the system.
POC Design and the ERC 721 Token
Having some background of the overall solution above will help you understand why we chose to go with Plasma Cash and ERC 721 token.
First, the ERC 721 token is non-fungible. Every token has a serial number and an owner, and these tokens can also not be subdivided. They need a UTXO (Unspent Transaction Output) model to keep track of payments. Due to these characteristics the payments using these tokens are atomic.
We can now arbitrarily add any data as a requirement to this atomic payment and on-chain the only thing we need to check is the signature for the UTXO. It doesn’t need to interpret the additional data which reduces a lot of complexity on both Layer 1 and Layer 2. In our case, the Mainnet Ethereum contract does not need to understand the data to validate data exchange transactions as long as it can validate payments for specific ERC 721 tokens. The plasma node takes care of binding serialized atomic payments with the specific data exchange package.
Challenges Going Forward
As we plan next steps for the protocol, there are a few challenges that we are working to solve:
Data Availability
One of the core problems for any project implementing sharding, delegated execution, or off-chain execution is data availability. Specifically, all users that want to be able to verify a transaction should have access to it when they need it. But if you perform transactions off-chain and want to scale, then you don’t want every participant to store or verify every single transaction, so there is an inherent contradiction here.
However, even if everyone could verify and request a chain of transactions from other participants, like say from the Plasma Cash node, they would rely heavily on that node providing true data and there is a risk that the node can go rogue so that does not really solve this problem.
A potential way it can be solved is by user knowing that the data exists with some of the nodes and is contradictory to the data that it just received, even if the user does not have this data. It can be in IPFS, another node, or somewhere else. If the user can somehow prove that the node misbehaved by providing the wrong transaction data or even withholding data, then we can solve this problem with crypto economics.
Trustless Distributed System
In the current POC stage we expect the participants of the Dock protocol to have a lot of trust in the central node, but it can fail due to various reasons. The same problem applies to a lot of scaling and sharding solutions out there. We are one of many projects working on solving this and we are currently coming up with multiple ways to address it.
One solution can be to have multiple Plasma nodes rather than the single logical node that we currently have in the POC design. Multiple distributed nodes owned and operated by multiple owners will provide more trust in the system. In case of a single node, providing users access to bloom filters to verify transaction data integrity might be one of the ways to add trustlessness to the system.
Another method could remove data from being stored on the central node and instead the node will operate like a routing mechanism for finding the data stored on the IPFS network in an efficient manner. In this scenario, there can be multiple nodes that compete to find the data the fastest so they can earn the transaction fee. The nodes map the transaction data on the IPFS network and can point participants to them very quickly, but do not have any ability to manipulate the actual data, so participants don’t have to trust the Plasma nodes.
Censorship Resistance
Adding distributed aspects to the system as explained above can increase levels of censorship resistance as there is no single point of failure and the bad actors need to hijack the majority of the network rather than the single node.
Another thing we can do is add routes in the MainNet contract for participants to do business even in case of a total breakdown of the Plasma nodes. Such transactions can be extremely expensive for the participants, but will act as a deterrent for bad actors as they will know there is no way to shut down the entire system for a dedicated participant without hijacking Layer 1 (Ethereum network). This has not yet been achieved by anyone.
Reducing Gas Cost
The purpose of this POC is to prove feasibility of the Plasma Cash-based design. Efficiency was not a goal at this stage, but in the next stage we need to improve gas costs for entry, exit, and updates on the Mainnet contract. One approach we plan to test is to sign transaction hashes instead of whole transactions.
Dispute Process
In order to have a working dispute process, we need to devise a way for participants to send a proof chain of transactions in an efficient manner to the Mainnet contract, which might be possible using zkSnarks or ZKRP to reduce size of dispute packet. The data availability problem as described above also needs to be solved first in order to provide a history of transactions to validate a claim.
Crypto-Economic Model
The entire Dock protocol ecosystem can only work with a well designed crypto-economic model where all parties are incentivized to be honest and the interest of the participants aligns directly with the interest of the network. The transaction cost structure needs to be balanced so that it’s not prohibitively expensive to enter the system, but at the same time participants should have enough skin in the game to act fairly. The gas cost needs to be minimal with respect to transaction cost.
Coming Up Next
In the next phase of designing the blockchain architecture for the Dock data exchange protocol, we are working on solving the above problems along with firming up the code so we can open source it to share with our community for feedback and review.
We are also aiming to host the POC code on test net for our community to try it out and see the blockchain component of the protocol in action.
Stay tuned!
