As many other blockchain-based projects, we faced a big challenge with Wibson data marketplace: the gas consumption. Here’s a summarized version of how we managed it.
A year and a half ago, we started Wibson, a decentralized data marketplace based on the ethereum network which allows users to sell private information in a trusting environment. Our first protocol involved three main participants: Data Sellers, Data Buyers and Notaries. You can check the details and the graphic here.
The main problem with the first version of our protocol was the cost required to operate. For each piece of data that the Buyer bought, he needed to send two transactions to the network:
- One to register the intention of the Data Seller to sell its data.
- Another one to register the data validation results provided by the Notary and to pay the corresponding players.
Let’s say that the total cost in gas units of both transactions is `G = 400,000`. Using a standard gas price of `GP = 5 Gwei`, each transaction would cost `C = 0.002 Ether`. If we deliberately settle the ETH price to $225 USD, each piece of data bought would cost $0.45 USD without even considering the cost in WIB for the data. This high transaction cost made the marketplace unattractive for Data Buyers.
Immediately after launching the first version, we challenged ourselves to find a solution that reduces the operational costs by three orders of magnitude during the final quarter of 2018. We received lots of suggestions in last year’s Blockchain Privacy Summit from our friends at RSK, Decentraland and Algorand to dig deeper into the concepts of state channels and side chains in general.
We reviewed the Loom network case to understand if having a Plasma side-chain could work for us, but we realized that this would be a risky option since we lack the experience and sufficient time to build a working prototype and validate it. Instead, we decided to stay within the already established Ethereum network. We extracted some concepts of state channels, those which better fit our case, and after hard work and help from the folks at Disarmista and the people at CoinFabrik, we came up with a solution that let us achieve our goal.
The V2 protocol is designed to reduce the costs on almost every operation of the marketplace. It does so by optimizing ERC20 transfers and moving logic and information off-chain without sacrificing any of the features of our decentralized marketplace.
The main idea behind the token transfers is to bundle together many similar operations into a single transaction to optimize gas consumption. We applied this concept in two parts of the protocol:
- The first one is where the Data Buyer registers a new payment for multiple Sellers in one single transaction.
- The second one is where the Data Seller collects many payments sending the tokens to his wallet.
Where is a payment registered?
The BatPay contract (not affiliated with any superhero or token in particular) holds information about payments and the tokens for the corresponding payees of each payment. The Data Buyer sends a transaction to this contract to register a new payment, reserving tokens for each payee.
How does a Data Seller collect their payments?
Since the BatPay contract holds the tokens of each payment, it allows Data Sellers to collect multiple payments at once with the help of a fourth player, the Delegate.
The Delegate sends a transaction on behalf of the seller to the BatPay contract specifying which payments need to be transferred to the seller’s account. The Delegate provides his service in exchange for a fee in tokens.
Let’s see it in numbers
V2 shines in the efficiency in which it registers or collects payments. If a Data Buyer registers one payment for 1,000 Data Sellers, the transaction consumes 228,255 gas (229 gas each payment.) Furthermore, the gas consumption for the payment collection does not change with the number of payments. Collecting 1,000 payments consumes 167,440 gas (168 gas each payment), making a total of 397 gas per payment including both transactions, or $0.00044 USD. Our solution improves efficiency by three orders of magnitude.
Data Sellers are encouraged to accumulate payments because of the fee in tokens charged by the Delegate. The more payments he collects in one operation, fewer tokens are charged per payment because the gas consumption of the collect operation remains independent of the number of payments.
Find out more about how BatPay performs here.
With the first version of the protocol, we proved that a decentralized data marketplace based on the Ethereum network is possible. With the second version, we achieved a scalable solution which allows Data Buyers to execute payments with an operating cost of less than $0.01 USD per Seller.
On the Seller’s side, there is still a lot to improve. For example, what other things a seller can do instead of transferring tokens to his wallet. However, we are working on that.
Last but not least, the BatPay contract is open-source and not coupled to Wibson. Anyone having a similar problem with any other ERC20 token can deploy the contract and start using it right away.
There are certain details we haven’t mentioned in this post for the sake of simplicity, for instance the logic used and the information we have moved off-chain. Stay tuned for more information regarding the mechanics of this brand new version of the protocol.
Special thanks to everyone in the Wibson team who collaborated in the correction of this blogpost.