Making uPort Smart Contracts Smarter, Part 3: Fixing User Experience with Meta Transactions

In the previous two blog posts, we explored the old uPort identity contracts, and then discussed some improvements to our smart contract architecture, introducing our IdentityManager. In this post, we will explore meta transactions — the most fundamental change to our 0n-chain architecture in a long time, and a possible leap forward for the Ethereum ecosystem.

Meta Transaction Motivation

Meta transactions are an idea conceived by Dr. Christian Lundkvist about 2 years ago. They are probably best summarized through the effect they have: users can interact with the Ethereum blockchain without holding any Ether.

This is a fundamental improvement. At its heart, uPort is both a platform for Ethereum interaction as well as a self-soverign identity platform. As a result, many of the users we onboard have little-to-no knowledge about Ethereum — and hold no Ether.

Without meta transactions, imagine the wonderful self-sovergin identity world of the future:

  1. Jim hears about uPort from his friends and decides to try it out. He wants to take back control of his identity.
  2. Jim downloads the uPort app and tries creating an identity, but realizes he has none of this “Etherium” he needs to interact with the Ethereum public chain.
  3. No worries! Jim just has to go to his favorite exchange, sign up, get KYCed, wait 3 days to hook up his bank account, buy some Ether, wait for it to arrive, then transfer it to the correct location. Simple!

Simply put, forcing all users to buy-and-then-hold Ether to be a uPort user would be a terrible experience for just about everyone. This is the problem that meta transactions attempt to solve.

Meta Transaction Inner Workings

To illustrate how meta transactions work, let’s walk through an example of them in practice.

First, let’s assume Jim has downloaded uPort and managed to set up an account (for more information about the future of account creation, see a later blog post :~)).

However, he holds no Ether and thus has no way of interacting with the public Ethereum chain. Though he can perform many of the actions possible with uPort without any interactions with the public chain (unless he wished to interact with a dapp) — he would be limited by not holding Ether.

Enter meta transactions. Jim can use his private key — that only exists on his phone — to sign some data and then send this signed data to a relayer (which he has specifically given permission to forward his data). This relayer can then pay the gas for this transaction, and send the data through Jim’s proxy contract.

Note: with meta transactions, users never relinquish control of their private keys. The worst a relayer can do is refuse to send Jim’s transaction. If so, Jim can use a different relayer :)

As for the inner workings: the data Jim signs and his signature are sent to a verification contract. After verifying his signature, the verification contract calls the IdentityManager contract, which forwards the data through Jim’s Proxy to any other contract on the public Ethereum chain.

Because Jim still interacts with the blockchain through his Proxy contract, no other smart contracts need to change to accept meta transactions. As a result, Jim can interact with any Ethereum smart contract in a normal way — something that is only possible due to the uPort smart contract abstractions. 
 
And so, with the advent of Meta Transactions, uPort gets closer to its goal of bringing self-sovereign identity to all people, everywhere. Not just us Ethereum fans :)

Conclusion

Meta transaction are a method of allowing individuals to interact with the Ethereum blockchain without holding any Ether and without ever relinquishing control of their private keys. This allows uPort to dramatically improve our users’ experiences.

The code for meta transactions is written, and real life testing will begin soon. If you are interested in checking it out, see here and here.
 
Note: Meta transactions have been heavily audited by uPort team members, but have yet to undergo an external audit. This audit will occur in the coming months. Please use with caution.

Note 2: “But what about EIP 208? Isn’t this what account abstraction solves?” Good point :). Meta transactions and account abstraction were both born out of many of the same motivations. However, it’s worth noting that meta transactions are functional today and require no changes to clients or community adoption to work. We look forward to exploring EIP 208 more in the future.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.