# Pre Commit & Commit
# Implementation Steps
1) Implement Pre Commit without CentID verification, store ID but don't check that sender is allowed
2) Implement Commit without CentID verification, store ID but don't check that sender is the CentID it claims to be
3) Modify Cent IDs to store signing key that is compatible with Ethereum
4) Implement check to verify merkle proof that signing_root in pre commit matches document_root in commit
5) Implement Signature validation on Pre Commit & Commit methods

# Implementation Details

## Signatures
To authenticate a request, we rely on our own signatures, not the account the tx is sent from. This adds some gas but let's DO IT!
A signature is signing all arguments of the call. E.g. for preCommit:
Payload: **(_anchorId+_signignRoot+_centId)**
Signature: **Sign(Payload)** with private key that has a public key on centId

Verification can be done by the smart contract by fetching the public key, reconstructing payload out of function arguments and checking the signature.

The specifics for Signatures still need to be documented.

## Data Store
This is a pretty good article on how to efficiently store/pack data: https://medium.com/@novablitz/storing-structs-is-costing-you-gas-774da988895e

| Description | Name | Type |
|-------------------|-----------------|---------|
| Pre Commit Root | preCommitRoot | uint256 |
| Pre Commit Sender | preCommitSender | uint256 |
| Pre Commit Expiry | expirationBlock | uint32 |
| Commit Root | commitRoot | mapping[uint256] => uint256 |

> [name=Razvan Dinicut]
> It will
For the commitment, we only need to store the commitment root. Therefore a mapping of `uint256` to `uint256` is the most efficient way to represent it. For the pre commit, we are storing the following struct:

    struct PreAnchor {
        uint256 anchorId;
        uint256 signatureRoot;
        uint128 centrifugeId;
        uint32 expirationBlock;
    }

@Razvan: Please add proper field length for expirationBlock.

## Verifying pre commit matches commit
We can ensure that anchors are only published if they got a valid pre-anchor and that the signing_root in the pre anchor is part of the document root of the final anchor. In the pre-commit the user commits to the signing root which is also sent to the other parties. Once all signatures have been gathered, the commit root is submitted along with a Merkle proof proving that the `document_root` contains `signing_root`.

## Privacy leak in pre commit
There is a privacy leak when one entity makes a pre-commit, let’s it expire and then a different entity makes a new pre commit. If the pre commit ID is the same as the commitment ID, an adversary could see that the two entities are both part of this transaction.

One possible workaround could be to use a Hash(centID+commit root) as the ID for the pre commit. Two different pre-commits on the same commit root would now not be linkable anymore however by doing so, the anchor registry loses the capability to enforce that only one valid pre commit exists at a time. The process would look as follows:

1. Alice creates pre-commit for document 1: ID: `Hash(Alice+1) -> signingRoot: sr1a`
2. Bob creates pre-commit for document 1: ID: `Hash(Bob+1) -> signingRoot: sr1b`
3. Bob creates commit for document 1: `ID 1 -> documentRoot: dr1b` To prove that Bob created a valid pre commit before, the contract can check for the pre commit by hashing `Bob+1` which returns the valid pre commit created in 2.
4. Alice creates a commit for document 1: `ID 1 -> documentRoot: dr1a`
* Even though the pre commit of Alice is still valid, Bob’s commit was accepted first.

One way to mitigate this would be to check in step 4 if Alice’s pre commit was mined before Bob and overwrite it if that was the case. However doing so makes finality much harder. Now instead of just having to make sure the commit tx got mined, you need to wait for the final expiry of all other potential anchors expired.

We chose not to address the privacy leak at this time and implement the solution as described and possibly add a mitigation to this (via an off chain way to agree on a new identifier) later on.

## Solidity Functions
### Pre Commit

**function preCommit(uint256 _anchorId, uint256 _signingRoot, uint256 _centId, uint256 _signature) external payable_**

preCommit:
* Should check that hasValidPrecommit(_anchorId)_ returns false
* Should verify that signature is valid for centId

It should store:
* _signingRoot
* _centId
* blockheight

**function hasValidPrecommit(uint256 _anchorId) public view returns (bool);**
* should return false if the precommit is not set
* should return false if the precommit is set but the precommit has expired ( expirationBlockHeight[_anchorId] < block.number)

### Commit
**function commit(uint256 _commitId, uint256 _documentRoot, uint256 _centId, uint256 _signature) external payable**

It should check:
* should verify that `msg.sender` is authorized to act on behalf on centId
* ensure that preCommit.centId == _centId
* Should verify that signature is valid for centId
* Maybe: Require a merkle proof that proves `preCommit.signingId` is in` _documentRoot`
* Maybe: call checkPreCommit() and ensure it returns true or check it's empty

It should store:
* _documentRoot

Maybe for gas refund it should empty all precommit fields (check how much gas is refunded).

## Open questions:
* Should we require a merkle proof for a matching signingId with documentRoot. Check the cost?
* Conflicting precommit: reveals other party. Do we need to care about this?