Harbour-MVP: Update 1

Decentralizing the execution of meta-txs

Peter ‘pet3rpan’

Published in

MetaCartel DAO

5 min readOct 4, 2018

// This post requires an understanding of what meta-txs are and how they work.

Community wide need for meta-txs

During late August and early September, the community experience a large uptake of expressed interest surrounding meta-txs. A number of demos and PoCs that were released drove community wide awareness for its applied use.

Some examples include…

On-boarding experience: Giving users the ability to execute onchain transactions without having gas or to pay for transactions using tokens. This allows the controlled pace of necessary education to be introduced eg. From the concept of cryptocurrencies, gas and key recovery etc. Teams exploring this use case includes Golem, Tenzorum, ENS…

Wallet key management: Giving users the ability to use permissioned keys to sign messages of intent in order to utilise funds that would otherwise require uses to use seed phrases and send funds around from account to account. Teams exploring the use of this includes Gnosis Safe, Tenzorum, Argent…

Transaction gas abstraction: Giving users the ability to make onchain transactions without them having gas on their account. Users will be able to pay for transactions and relay cost using only tokens. This allows web3 products to enable user onchain transactions for a ‘fee’ and in turn abstract the concept of gas out from the details of a transaction. Teams exploring the use of this includes Status.im, Tenzorum, Tokensubscriptions…

Further discussion surrounding the design of the relay architecture revealed concerns around the centralised meta-tx execution relay server as a central point of failure.

The need for p2p decentralisation

There was rough consensus around the need for the decentralisation of this relay server into a p2p meta-tx execution network due to the need for p2p resiliency. Soon after the realised need for such a network, the community began to organise an effort to build this decentralised network.

Sept. 14th — A telegram chat was started. Smaller discussions and calls were had around how to execute this decentralised network. Earlier discussion talked about needing to create standards around contract interfaces, execution functions, meta-tx formats and message signing.
Sept. 27th — The first community call around this project was held with over 16 teams representative attending. We discussed how to proceed with coordinating the design of this network, standards we needed as well as further discussion surrounding the cryptoeconomics of the network. The first step forward were establish: Share our code before hand to be analysed & design a draft standard during a offline meeting in DevCon + the github org was also created. With rough consensus, the community organisation was named: MetaCartel

https://www.youtube.com/watch?v=tKOtWPopl8Q&t

Requirements of an initial MVP

Previous demos and contractions of meta-txs mainly featured a single server for relaying meta-txs. A collection of these projects can be found here: LINK. There was rough consensus that we need to deliver a basic MVP to validate engineering assumptions and provide a buffer for research to lead ahead.

MVP Design Goals

Decentralised p2p resiliency

Delegated execution of meta-txs enables onchain execution without gas. This relies on a server and if the server were to go down for any reason then it would be mean that if a user depended on delegated execution then they would be unable to execute on the Ethereum Network. If it does happen, then for dapps or wallets with hundreds and thousands of users, it would mean hundreds of thousands of people being denied the ability to execute transactions.

Built for trusted parties

The MVP is named ‘Harbour’ because in this initial version of the network, it will be designed for trusted parties. That means that for th first version, we can focus more on how to achieve interoperability and how to design the executing contracts as well as the p2p network. The most basic cryptoeconomic designs will be applied for the MVP. It is agreed that we focus on hostile network actors, game theorics, economics and p2p security after the MVP.

Development: Standardisation & interloperability

The first and more immediate focus of development is to set and standardise the following…

meta-tx format and messaging signing
execution contract interface and functions
interactions with other standards

In the first community call, we agreed to share our code and produce a video demo of what we have been working on and then come together at DevCon to finalise a draft of the standards. The code and demo are due to be collected online asynchronously before hand to allow everyone to properly compare and contrast the shared code to produce a standard.

There will be a focus on understanding why we have designed our standards the way they are to prevent re-coordination and ensure rapid alterations later on in case cryptoeconomic design alters the architecture of the network.

We have begun work on this in the github.

Roadmap

Sept. 27th — First community call
Oct. 14th — Shared code & demo due for analysis
Oct. 31st — DevCon Meta-tx Standards Roundtable

Research: Collision and incentive design

The focus of the research is on cryptoeconomic research with the current most immediate goal of producing a minimum viable counter-collision algorithm.

Roadmap

Oct. 31st — Present various MVP counter-collision algorithm designs
Nov. Onwards ~ Further research across cryptoeconomics and p2p incentives

Aside producing a design for the Harbour-MVP, most of the work around this will be on the cryptoeconomic design of game theoric incentives, economics and security. Current research problems include:

Propagation of meta-txs through the network (collision problem)

When a user publishes a meta transaction to a decentralized relay network, there’ll be a competition among the relayers to submit the transaction first, and thus get the reward. As only the first submitter gets a reward, everyone else’s transaction reverts and they lose gas. This not only an inefficiency but an attack.

Discussion:

Service node reward economics

As gas prices change and rewards remain constant it will be hard to balance the crypto-economics of incentivizing relayers to submit meta transactions.

https://github.com/Meta-tx/Harbour-MVP/issues/4

How to enforce conditional execution

Conditions could allow “automating” actions like revealing votes and bids, or claiming rewards. However how do you enforce this conditional execution and is this out of the scope of the meta-tx standard?