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

[bitcoinwarrior1]

ERC - Merkle Tree Attestations

Introduction

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.

Purpose

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

Copyright

Copyright and related rights waived via CC0.

[PhABC]

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.

[bitcoinwarrior1]

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.

An attestor may also have different levels of attestation with different implications, for example, a drivers license is a stronger form of identity than a school ID, but the authority might be able to issue both types.

The tree structure can also be standardized so that everyone has a consistent format while revocations/additions to a whitelist are stored elsewhere (see #1386 & #1388); similar to how cacerts are listed.

In other words, the main benefits of a merkle tree structure is linkability to the source attestation, privacy (only reveal one node) and the ability to distinguish between attestation types.

Hope this clarifies your questions!

[bitcoinwarrior1]

@PhABC this might be of help: https://www.linkedin.com/pulse/merkle-tree-forgotten-university-melbourne-blockchain-wei-wu-zhang/

[axic]

@James-Sangalli this EIP doesn't have a copyright statement. Can you please add one? EIP-1 suggests CC0 - see the eip-x.md template.

[github-actions]

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.