New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ERC1387 - Buy beer in a smart contract - Privacy enabled Merkle Tree Attestations #1387

James-Sangalli opened this Issue Sep 8, 2018 · 3 comments


None yet
2 participants

James-Sangalli commented Sep 8, 2018

ERC - Merkle Tree Attestations


It's often needed that an Ethereum smart contract must verify a claim (I live in Australia) attested by a valid attester.

For example, an ICO contract might require that the participant, Alice, lives in Australia before she participates. Alice's claim of residency could come from a local Justice of the Peace who could attest that "Alice is a resident of Australia in NSW".

Unlike previous attempts, we assume that the attestation is signed and issued off the blockchain in a Merkle Tree format. Only a part of the Merkle tree is revealed by Alice at each use. Therefore we avoid the privacy problem often associated with issuing attestations on chain. We also assume that Alice has multiple signed Merkle Trees for the same factual claim to avoid her transactions being linkable.


This ERC provides an interface and reference implementation for smart contracts that need users to provide an attestation and validate it.

Draft implementation

contract MerkleTreeAttestationInterface {
    struct Attestation
        bytes32[] merklePath;
        bool valid;
        uint8 v;
        bytes32 r;
        bytes32 s;
        address attester;
        address recipient;
        bytes32 salt;
        bytes32 key;
        bytes32 val;

    function validate(Attestation attestation) public returns(bool);

Relevant implementation examples

Here is an example implementation of the MerkleTreeAttestationInterface
Here is an example service which would use such a merkle tree attestation

Related ERC's

#1388 #1386

@James-Sangalli James-Sangalli changed the title from ERC - Buy beer in a smart contract - Privacy enabled Merkle Tree Identifiers to ERC1387 - Buy beer in a smart contract - Privacy enabled Merkle Tree Identifiers Sep 8, 2018

@James-Sangalli James-Sangalli changed the title from ERC1387 - Buy beer in a smart contract - Privacy enabled Merkle Tree Identifiers to ERC1387 - Buy beer in a smart contract - Privacy enabled Merkle Tree Attestations Sep 8, 2018


This comment has been minimized.


PhABC commented Sep 17, 2018

Instead of a merkle tree, why not just signed messages directly? Few arguments :

  1. Verifying a merkle proof is more expensive than just a signed message.
  2. Merkle tree are inflexible, meaning you can't update the whitelist without storing a new root and recontacting everyone to provide new merkle proofs.

I'm not sure what more privacy a Merkle tree provides, but perhaps I am misunderstanding the workflow.


This comment has been minimized.


James-Sangalli commented Sep 18, 2018

Hi @PhABC Thanks for your comment!

We choose to use merkle trees because it will allow multiple different predicates and predicate combos to be used from one root signature; e.g. above 16, above 18, isAnAustralianResident etc.

If we just sign messages directly, there could potentially be millions of different combos which would all require a signature and message to be stored inside the users mobile phone. In contrast, a merkle tree will only require a single root signature and can be used for all the predicates that are compatible with the attestation.

As for privacy, with a merkle tree you can salt it and use it for multiple predicates with proof it came from the origin. While you could keep this level of privacy with individual signatures, you cannot link them back to the origin and you have many different signatures and messages to store.

In other words, the main benefit of using a merkle tree is it allows for one signature to be used for many different predicates, rather than having a unique signature for each predicate which could become a massive overhead.

Hope this clarifies your questions!


This comment has been minimized.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment