dob / tap Goto Github PK

Transaction Attestation Platform for Ethereum smart contracts

License: MIT License

HTML 0.81% JavaScript 98.45% CSS 0.74%

tap's Introduction

Transaction Attestation Platform (TAP)

TAP is an Ethereum + IPFS platform that lets users attest to what will actually happen when users invoke certain functions within smart contracts. For each function in a smart contract that's attested to, users will get visibility into:

a description of what is intended to happen
are there any known exploits?
does this function invoke other external smart contract functions?
does it require ETH?
does it send you ETH?
does it transfer ownership of an asset controlled by your account?
what may cause this function to throw and lose your gas?
an overall risk assessment of signing that transaction
and more. View full working schema for an attestation.

Without social attestations, users have very little transparency into what will actually happen when they press that "Accept" button to sign a transaction. With attestations they can use DApps with confidence.

The TAP smart contract documents the full on chain functionality, however the smart contract only proves that attestations were provided by a given account, and the attestation data itself lives on IPFS. As a result, we recommend that you would use the JS interface in order to write out correct and valid attesattions.

JS Interface

To use TAPJS library please include both ipfs.js, tap.js, and browser-solc.min.js in your source.

<script src="./ipfs.js"></script>   <!-- Borrowed from the Consensys IPFS wrapper: https://github.com/ConsenSys/ipfs.js -->
<script src="./app.js"></script>
<script src="./tap.js"></script>
<script src="./browser-solc.min.js"></script>

TAP.js provides the core interface for interacting with the TAP platform. It provides the following functions.

TAPJS.verifyContract(addr, contractCode, solcVersion, optimize, name, callback)

Before you can provide attestations, the code for the contract must be verified, and the request registered with TAP. Call verifyContract if it hasn't been called yet for the contract within TAP. For solcVersion, use the string of the version number of the compiler, such as "soljson-v0.4.6+commit.2dabbdf0.js", and for optimize, just choose 1.

TAPJS.getAttestations(contractAddr, methodId)

Get the known attestations for a given contract and methodId. MethoID is the 0x prefixed 4 byte identifier constructed from sha3(function signature).

TAPJS.submitNewAttestation(att)

Add a new attestation. This will require you to sign the attestation object, and then sign the transaction on the blockchain. At the moment, the attestation object is a JS object conforming to the attestation schema example but we'd like to add a helper method to make it easier to construct this object.

TAPJS.vote(attestationId)

Coming soon...this is how you would vote on an attestation.

Project status

TAP is a work in progress project proposed by Eric Tang and Doug Petkanics. We believe that this only succeeds as a community driven project, since the major benefits of TAP will be both provided by and delivered to the community. We'd currently like feedback in the issues on attestation schemas and on the mechanisms that bounties could be provided and distributed to users for providing attestations.

Additionally, TAP will require a great frontend to display all the great attestations that users have left, and to make it easy for users to submit attestations. We have a working proof of concept frontend on a branch, but if any aspiring DApp developers would like to get involved in building out a community tool, please contact us. We'd love to help get you involved.

Local setup

Running a full decentralized version of TAP requires running Ethereum and IPFS.

The architecture of the app is that attestations are stored on IPFS, and the hashes that represent them are stored into the contract. Users can make verify any contracts code (also stored on IPFS), and then other users can attest to the contracts.

Setup Ethereum

Setup a local node on a local network to test against...

geth --identity "yournode" --datadir ~/.chaindata --networkid 1999 init configs/CustomGenesis.json
geth --identity "yournode" --rpc --rpcport "8545" --rpccorsdomain
"*" --datadir ~/.chaindata/ --port "30303" --rpcapi
"db,eth,net,web3,personal" --networkid 1999 console

Create an account, unlock it, and start mining.

personal.newAccount()
personal.unlockAccount(eth.accounts[0])
miner.setEtherbase(eth.accounts[0])
miner.start()

Setup IPFS

Since the app is served on port 8080 by default, as is IPFS, you'll want to change some IPFS config vals. I'm running on port 8082

$ ipfs config Addresses.Gateway /ip4/127.0.0.1/tcp/8082
$ ipfs config --json API.HTTPHeaders.Access-Control-Allow-Origin "[\"*\"]"
$ ipfs config --json API.HTTPHeaders.Access-Control-Allow-Credentials "[\"true\"]"
$ ipfs config --json API.HTTPHeaders.Access-Control-Allow-Origin "[\"http://localhost:8080\"]"
$ ipfs config --json API.HTTPHeaders.Access-Control-Allow-Methods "[\"PUT\", \"POST\", \"GET\"]"

Run IPFS daemon

$ ipfs daemon

Add files in the examples directly to IPFS and note the resulting hashes

cd examples
ipfs add *

Serve the DApp locally

We removed the proof of concept frontend from master, but it still lives on the ui branch. If you'd like to run the UI:

git checkout ui
truffle build
truffle migrate --reset
truffle serve

You can now access the app at http://localhost:8080 were you can register contracts and attestations. You can then access attestations at http://localhost:8080/attestations.html?contract=<contractAddress>&method=<methodId>.

tap's People

Contributors

Stargazers

Watchers

tap's Issues

Author Attestation page

Right now the homepage lets you create an attestation by pasting the IPFS hash. Instead you should fill out the form fields, which will generate the IPFS file for you. Bonus points if this file is signed by the user's Ethereum private key to prove that they were the author.

If the contract isn't verified yet, then they'll need to verify the contract first by providing it's code, which I'll file in issue #3.

Design!

Implement whatever design framework we decide on across pages. It's actually easier if this is done up front so that we can use the right patterns across subsequent pages. Should we pick a site we like and take inspiration from it's UI elements/colors/layout? Any ideas?

Unit tests for TAP.sol pairing session

Human readable method names

We had talked about using an on chain registry to map method names to hex method IDs, since users will want to use names like endAuction(uint), but the contract will need to receive 0xb3a3348a.

I think this logic should probably just remain in the frontend for now. The ABI lives on ipfs, so the frontend should just have a convenience library which parses the ABI and generates a js object with keys as the 4 byte methodId and values as function signatures (types only, comma separated, no spaces). The frontend can use this to populate human readable names where necessary, but will always submit the IDs to the contract transactions.

Is there any use in the contract itself for having the human readable names accessible? Maybe it would make for an easier interface for 3rd parties to submit or lookup attestations...however it's also error prone to typos, since on chain they're really only referenced by ID.

Feedback Requested: Attestation Schema

Before we move to alpha on the Ropsten testnet, we'd like some feedback from the community in terms of what data users can actually provide in an attestation that would be useful. The current schema example is: Attestation Example

It basically includes:

method description
method signature
boolean fields about whether it usesGas, acceptsETH, sendsETH, has known exploits, can update asset ownership, calls external contracts
overall risk level in using the function
descriptions of the cases where it throws, calls external contracts, and known exploits.
Information that lets you verify who provided the attestation.

What fields are missing? What else would you like to see in an attestation. We'll take all feedback and publish an alpha version before going live.

Homepage

The homepage should...

Link to featured contracts
Link to "verify contract" page so people can submit other contracts for attestations.
Provide a way for people to navigate to a specific contract or contract/method combination if they know it. Probably via a search bar.
Show off the consumer use case...aka metamask integration...so that consumers know how to get value from our service.
Link to the about/FAQ page that describes in detail what's going on here.

Voting

Figure out voting rules and UI to add to attestations page.

Support infura or our own IPFS node in the Dapp

When TAP becomes hosted, we'll need to make sure the initializer does the right thing. Can't expect every user to be running a local IPFS node.

Look into browser solidity for verification

Contract level page

Right now we have a contract/function level page that shows the attestations. Create the contract overview page with high level contract metadata and a list of the functions. This can be generated for a contract after it's been verified.

Feedback Requested: Bounties for attestations

TAP will be more self sustaining and useful if there is an incentive to provide attestations. This incentive can be in the form of reputation that you earn for providing valuable attestations, but it can also be economically driven, in the form of Bounties. A bounty would work as follows:

Whoever verifies and contract can optionally provide a bounty for providing attestations for that contract.
Whoever wants to use the contract can optionally add to the existing bounty.
Bounties would be distributed to attestations at certain time milestones depending on quality of the attestation as deemed by the community through voting, weighted by reputation of the voters and authors of the attestation.

The final statement is easier said than done. It's hard to come up with a scheme for reputation, voting, and distribution that isn't gameable. We welcome input on using any existing on chain contracts that handle reputation and voting protocols, or pointers to specific designs that work well. Steem protocol, actually does a good first pass job at this, however implementing all of the complexities that it has accounted for is well beyond scope for a first pass alpha of TAP.

Verification process

Right now we only store the verification result on the blockchain. Is there a way for the contract to make sure the verification JSON is valid? (For example, right now I can pass in a fake verification that points to fraudulent code)

Contract verification

Before attestations for a contract can be provided, a contract must be verified. This requires pasting it's code. And if we follow etherscan's lead, it may require choosing your compiler version so that we can do the proper verification. Perhaps to start we can just support contracts with pragma statements that list the compiler version.

We can create a verify contract page to get contracts into the system so that people can provide attestations, and we can link to it from the create attestation page described in #2

Bug with looping through multiple attestations

The latest commit that allows you to loop through multiple attestations and display them all doesn't seem to be working locally for me. This is a reminder to fix that bug, but in the meantime you can just fetch attestation(0) instead of looping through them all.