Meta-Transactions

The middle ground between decentralization and convenience

Rongxin Zhang
7 min readDec 4, 2018

Problem

Decentralized infrastructure and applications (DApps) were proposed as a solution to enable cooperation across mutually untrusting parties to work together by disrupting trust [12][13]. Even in the early days of Bitcoin, there were many attempts at creating more complex applications through Bitcoin’s scripts [1] as well as projects such as MasterCoin which aimed to provide a more generalized programming system [2]. However, they were often difficult to build and were limited in capabilities and very difficult to build on. It wasn’t until the introduction of Ethereum that decentralized applications became a more viable solution. Since the launch of the main-net in mid-2015, DApps have grown rapidly [4], especially in the token issuance space during the ICO craze where a total of over $20 Billion in USD were raised in 2017 and the first 8 months of 2018 [14].

As developers eye the consumers market, DApps’ interactions become ever more complex [18], which amplifies many fundamental problems with blockchains and cryptocurrencies such as low transaction throughput [16], high storage costs, the lack of a stable currency and smart contract security risks [17][19]. However, there are huge problems around the accessibility of decentralized applications. On Ethereum, a user must own cryptocurrencies such as Ether just to interact with smart contracts or decentralized application. To buy cryptocurrencies, users must set up accounts on specific exchanges that accept fiat currencies such as CoinBase, which already limits the type of users that can partake in the applications. They must then provide sensitive information for KYC procedures before approval which may take several days at the shortest and weeks at most. Only when they are approved can they now buy the token which could take up to an hour depending on the traffic on the network. Lastly, they must now send Ether to their MetaMask or other key management tools. Only after this can the user now interact with smart contract systems.

MetaMask: A cryptocurrency wallet in the form of a browser extension. It allows users to sign and send transactions from their browser directly without needing to run a full Ethereum Node. MetaMask does this by connecting with a node provider, specifically Infura [21] which hosts an API that allows developers to interact with their own hosted Ethereum nodes.

Solution

Currently, smart contracts allow users to interact with them directly by allowing users to sign transactions with their private keys and then send it to the Ethereum network by paying for gas with Ether. The below diagram demonstrates how fee payment interactions on a decentralized blockchain work in relation to a smart-contract application.

However, as described above, owning cryptocurrency is a major issue for first-time users. The naive solution is to abstract away the entire transaction signing and payment process from users where the application acts as the intermediary between the user and the smart contract. The application is the only user that can interact with the contract and the contract has no understanding of users. In essence, the smart contract simply becomes another infrastructure for the application. In this case, the user doesn’t need to sign or even understand how transactions work. We can see an example of this in the diagram below.

Although this method provides a high level of convenience for the user and requires minimal changes to centralized applications, it also destroys the fundamental concept of decentralized ownership and trustless execution that is at the core of the blockchain ecosystem. If the incentives of the application are misaligned, it provides a vector of attack in which the application can perform actions on behalf of the user without their permission. Even though events can be used to verify the correctness of the execution, there is nothing the user can do if they find out the application did something wrong, as there is no way to revert a transaction or challenge an application’s actions. Furthermore, in this model, users do not own or operate private keys which means that they cannot own tokens or perform more complex operations with other smart contracts. The only way to do this is for the applications to manage user’s keys. This is very complex and often leads to hacks and loss of money [20].

Gas-less or Meta transactions provide a middle-ground solution to this problem. The idea is that users will sign a raw transaction for intended for the smart contract which includes an associated data payload and sends it to the App server along with information such as which function to call and the address of the application smart-contract. The app server will then forward this transaction to the network and pay the gas price. The key difference between Meta Transactions and the solution described above is that a user never gives up control of their private key. This means that they can still own tokens and if the application relayer becomes bad, they can switch to a different relayer or send transactions to the contract directly by paying for the gas. The App Server can only censor transactions, but cannot perform transactions without the user’s approval. One of the early proponents of this design was UPort [3] and Status [5]. There are several Ethereum Improvement Proposals such as EIP191 [6], EIP865 [7], and EIP1228 [8] that are trying to develop a global standard.

The following diagram illustrates a version of a Meta-Transaction flow.

Steps:

  1. The application server sends the app files and executables to the user.
  2. User performs actions and signs a raw transaction with their private key using browser plugins like MetaMask. The user will send the following data along with the transaction:
    - sender_pubkey (address): sender’s public key to identify the user.
    - tx_data(bytes): signed transaction to be forwarded. This signed data needed to execute the transaction by app contract.
    - contract_address (address): App Contract’s address.
  3. The App server verifies the signature and sends this data to the app server based on the parameters provided by the user e.g the contract address.
  4. App Server sends the raw tx_data to a Relay Contract, which verifies the signature against a whitelist of users. If correct, it will send data to the App Contract, otherwise, it will reject the transaction.
  5. The App contract will run the function, and emit events which allow the user to verify that executions occurred correctly.

To prevent transactions replays, the relay contracts will need to keep a nonce for each user which will be incremented after every transaction.

Example Solidity code for the Relay Contract:

Contract not tested, likely have bugs

The above Meta Transaction contract is a modification of an existing implementation by Tomoaki Tsuzuki [11].

Additional Verification:

Depending on the needs of the application, we can add additional guarantees that the application did not tamper with the transaction. The level of trust and verification required will depend on the specific application and use cases. For instance, in the case of a smart contract that stores document data. We can add an additional event to the relay contract such that it emits a hash of the transaction data to be relayed back to the user. The user end application will then compare this hash with their own computed hash from the signed data. This prevents a malicious server from relaying data that did not originate from the user or by a server who was hacked and now propagates transaction to a contract controlled by an adversary. An example of this verification flow is shown in the below diagram.

Conclusion:

Meta transactions are critical to the future of DApps and bringing onboard more users. The specific implementations may change, but the key take away is that usability is not an addition to an application. It should be considered from the very beginning and baked into its core infrastructures.

Thank you to my advisor Phil Daian for helping me think through the problem and understand it’s importance.

References:

[1]Bitcoin Script: https://bitcore.io/api/lib/script
[2] MasterCoin white paper: https://e33ec872-a-62cb3a1a-s-sites.googlegroups.com/site/2ndbtcwpaper/2ndBitcoinWhitepaper.pdf?attachauth=ANoY7coaTbu5PF-HJksKim7J7LgF0HsUxyxAU0E5tXGrylRKA6UcUY_EzBrgmCA9EzdAQXV9bXKrjm7MpwJNjq-Wgn3BT6spkonVDIMbkYWHYC15l7lMHHMTuZlPXET2Ra4XFTnSVcowi-zN7rsbYpgaQEPVJjTTZJPZvxfE21n47v6MG4t5EvssomGgpWuZm6yEUmBhiRHSnyadbMxo4VewN_chLKxVdBZhzWEuXfqln0M2e97kTAo%3D&attredirects=0
[3] Meta Transactions: https://medium.com/uport/making-uport-smart-contracts-smarter-part-3-fixing-user-experience-with-meta-transactions-105209ed43e0
[4] State of DApps: https://www.stateofthedapps.com/dapps
[5] Status-IM Identity Relay: https://github.com/status-im/contracts/blob/73-economic-abstraction/contracts/identity/IdentityGasRelay.sol
[6] Original proposal to standardize Gass-Less https://github.com/ethereum/EIPs/issues/191
[7] Recently updated Meta-Transaction standrad https://github.com/ethereum/EIPs/issues/865
[8] Delegated Execution https://github.com/ethereum/EIPs/issues/1228
[9] Gass-less transaction Vitalik: https://github.com/ethereum/EIPs/pull/208
[10] uPort relay contracts: https://github.com/uport-project/uport-identity/blob/develop/contracts/TxRelay.sol#L21-L35
[11] Meta-transaction implementation reference: https://github.com/tsuzukit/meta-transaction
[12] Disrupting Trust Tech Crunch series: https://techcrunch.com/shows/trust-disrupted/
[13] Disrupting the Trust Business: https://www.economist.com/the-world-if/2017/07/15/disrupting-the-trust-business
[14] Total ICO funding since 2017 https://next.autonomous.com/crypto-utopia
[16] Scaling Discussion: https://link.springer.com/chapter/10.1007/978-3-662-53357-4_8
[17] Smart Contract Security: https://www.ideals.illinois.edu/handle/2142/97207
[18] Making Smart Contracts Smarter: https://dl.acm.org/citation.cfm?id=2978309
[19] Hawk: Blockchain Model of Cryptography: https://www.computer.org/csdl/proceedings/sp/2016/0824/00/0824a839-abs.html
[20] CryptoExchange Hacks: https://rados.io/list-of-documented-exchange-hacks/
[21] Ethereum Node Provider: https://infura.io/
[22] MetaMask: https://metamask.io/

--

--

Rongxin Zhang
Rongxin Zhang

Written by Rongxin Zhang

C.S Grad @ Cornell Tech, Previously Full-Stack Dev @ Zillow, Founding team @Retsly (acquired by Zillow). Passionate about building the infrastructures.

No responses yet