Let’s Talk About Ethereum Transaction Transparency

In this post I present why I believe that the current decentralized app interaction process for your normal, everyday user introduces a tremendous amount of security risk for those users, and I propose a solution called TAP, that can be used to reduce the risk. TAP aims to:

• Make Ethereum transactions transparent for users.
• Be community driven, with potential economic incentives for users to participate.
• Run completely decentralized, eliminating any reliance on a central party.

You can think of TAP as a decentralized Norton AntiVirus for the Ethereum blockchain, that adds a lot more information about what’s happening when users execute Ethereum transactions.

Transaction transparency is increased with TAP.

DApp Interaction Process Today
The Ethereum community is anxiously looking forward to the launch of many of the upcoming DApps and the decentralized economic opportunities they will bring. As long as people understand the smart contracts running behind the DApp, they get all the benefits of decentralization without the risks of trusting a central third party. However it is big leap to assume that the average consumer using a DApp, actually understands the smart contract, and even if they do, it is a big leap to assume that they have gone through all the steps to connect the action they are taking in the interface of a particular DApp, to the smart contract code that they believe will be invoked. To see this weakness in action, let’s take a look a DApp that we recently developed, AuctionHouse, and analyze what the problem is with consumer interaction.

AuctionHouse is an application for auctioning and bidding on assets on the blockchain. Users can take the actions you’d normally take on eBay, like list an item for sale, place a bid, and end an auction. Here’s what it looks like to place a bid in the AuctionHouse web interface.

Placing a bid on AuctionHouse

Each interaction that writes data to the blockchain, requires that the user signs the transaction with their Ethereum private key, so when a user hits that “Place Bid” button, they have to confirm their transaction. In many cases they’ll do this using a wallet/signer like Metamask, uPort, Mist, Parity Signer, or other options. Here’s what the experience looks like if they use Metamask.

Metamask Popup

This popup gives the user the valuable information of how much ETH they are sending as part of their transaction, and what the gas costs may be. But in reality, when they hit that “ACCEPT” button, they are really risking everything controlled by their account, other than ETH, to the DApp. This includes any Assets that the account controls (virtual goods, shares in DAO’s, etc), as well as any tokens the account controls like REP, DGD, or MKR. This is the case because:

• The user may not have reviewed the contract code.
• The user may not have the right background/experience to review the contract code correctly.
• The user may not have reviewed the frontend code to ensure it’s actually invoking the intended contract code.
• The contract code may invoke other contracts, for which the code isn’t even verified.

It’s unreasonable to assume that most users using a DApp are going to take any of these steps. It goes without saying that you shouldn’t use smart contracts that you don’t understand and trust, but I believe that this will be a huge blocker for mainstream consumers beginning to use DApps without suffering unexpected consequences. So how can we do better?

Presenting TAP

One project that Eric Tang and I have been working on is TAP, which stands for Transaction Attestation Protocol. It’s aimed at providing more metadata and transparency around the transactions that users are about to sign, before they sign them. Here’s the same example from above, with a demonstration of what Metamask could look like with integrated TAP data:

In this case the user is presented with the name of the function that’s being called, a description of what it intends to do, a big green “Safe” indicator, and some metadata about the number of attestations or audits that have been given to this function. In the case of an unsafe function, they may see something that looks more like:

TAP with personal reputation

Here the user sees a description of a known exploit, and the user who provided this attestation along with their reputation. Both examples link to a full attestation report, which can contain many attestations from many different users, each with the following data:

• Description of the function being called
• Does the function use gas?
• Does the function accept ETH?
• Does the function send you ETH?
• Does the function update ownership of an asset?
• Are there known exploits? What are they? How severe are they?
• Does the function call external contracts? Do we know which ones?
• In what scenarios does the function throw and risk losing your gas?
• What is the overall risk level of using this function?

These attestations are provided by the community including, hopefully, the author of the smart contract and any auditors who verified the smart contract before launch. The community can vote attestations up or down if they find them useful or inaccurate, and the user’s reputation is derived from their activity in TAP and users’ curations of their attestations. By optionally linking your address to Github, you can establish further reputation through your identity in order to have your attestations carry more weight with users. The full report, may look something like this wireframe:

Full TAP report for one contract method

Why would users do this and spend their time giving attestations? Of course for high value contracts, benevolence to the community is one reason people may participate, but further incentives can come in two forms:

1. Reputational incentives — a user with a high reputation on TAP gets the benefit of being recognized as knowledgable in the community, and gets associated benefits in their career or projects. This is similar to having a high rating on StackOverflow.
2. Economic incentives — bounties can be provided by contract authors in order to ensure that their contract is safe and trusted before going live, or bounties can be provided by community members for high value contracts that they want to have trust in before investing money. Designing an effective and ungameable bounty distribution system will be a challenge, but there are models out there that indicate it should be possible. We’re open to suggestions from the community on the best models.

Attestations live on IPFS and references to them are written to the blockchain, so the system is meant to be fully decentralized and community driven. The data is available to everyone, and we think the best places to embed TAP data are:

1. In wallets/transaction signers. Present the data to the user immediately prior to signing transactions so that they can dig in and review the details.
2. On block explorers, where people looking at the status of a given contract can dig in to attestations for specific functions.
3. On DApps themselves. When you are asking your user to sign a transaction, link to the TAP report for that transaction to give them full transparency.

TAP Project Status

TAP is under development but isn’t launched yet. It’s code, and open issues for discussion, are on Github.

This project is an idea that we want to see exist within the community, but since we have no intention to run it as a business, we’ll need community support to let it realize it’s full potential. We’ve currently developed the basis for the smart contracts, the example schemas for attestations, and the beginnings of the JS libraries to glue the IPFS pieces of the protocol to the Ethereum blockchain pieces of the protocol. We haven’t finalized the schemas for what gets included in attestations so we invite you to take a look at the code on Github, and to weigh in on the following issues:

• What data would you like to see included in an individual attestation? (Current one here for reference).
• How do you think Bounties should be distributed? Reputation is hard, so if it’s just based on votes it is easily gameable. Currently there are no bounties and the only benefit is reputation which is just the history of what you’ve done on the platform.

We have the framework for the JS library that would let any developer build a web solution that includes TAP data or submits TAP attestations, but we are also working on a sample front end that serves as the main TAP hub. If anyone would like to get involved in this process, it would definitely accelerate getting TAP out there for the community. This could be a good project for a frontend web developer who wants to learn how to build a DApp. Let us know if you want to get involved.

In order to get TAP out the door we’d like to:

1. Finalize the attestation schema.
2. Finish TAP.js interface that handles integration between IPFS and Ethereum.
3. Launch a sample frontend that allows users to easily submit and view attestations.
4. Deploy contracts to the Ethereum mainnet after testing on the Ropsten testnet.
5. Eventually upgrade the protocol to support bounties.

If you’re interested in integrating TAP data into your project, or have any ideas for how this protocol can be self sustaining and benefit the community, don’t hesitate to reach out on Github, Twitter, or Email.