decentralized-identity/sidetree-ethereum

Blockchain-specific code for the Sidetree-based DID Method implementation on Ethereum

Repo is inactive

See these repos instead:

• element
• sidetree

Sidetree Ethereum

Sidetree Ethereum is a REST API that supports anchoring of Sidetree Transactions to the Ethereum Blockchain.

Sidetree Ethereum is meant to be used with sidetree-core and sidetree-ipfs.

See the mono repo for integration tests... COMING SOON.

A Sidetree Transaction is a JSON Document of the following format:

{
  "transactionTime": 53,
  "transactionTimeHash": "0xa6dd7120730ddccf4788a082b0b5607fd1f39dbb80ebc170678551878b90b835",
  "transactionNumber": 15,
  "anchorFileHash": "QmcModh3cTgSpr8A6m7jNHnwVZRGZsepWv3uaFtD5KhL2U"
}

The anchorFileHash is a multihash content address for an anchor file of the following format:

{
  "batchFileHash": "QmcModh3cTgSpr8A6m7jNHnwVZRGZsepWv3uaFtD5KhL3U",
  "merkleRoot": "b6dd7120730ddccf4788a082b0b5607fd1f39dbb80ebc170678551878b90b836"
}

The batchFileHash is a multihash content address for a batch file of the following format:

{
  "operations": [
    "eyJzaWduaW5nS2V5SWQiOiJrZXkxIiwiY3JlYXRlUGF5bG9hZCI6ImV5SkFZMjl1ZEdWNGRDSTZJbWgwZEhCek9pOHZkek5wWkM1dmNtY3ZaR2xrTDNZeElpd2lhV1FpT2lKa2FXUTZjMmxrWlhSeVpXVTZhV2R1YjNKbFpDSXNJbkIxWW14cFkwdGxlU0k2VzNzaWFXUWlPaUpyWlhreElpd2lkSGx3WlNJNklsTmxZM0F5TlRack1WWmxjbWxtYVdOaGRHbHZia3RsZVRJd01UZ2lMQ0p3ZFdKc2FXTkxaWGxJWlhnaU9pSXdNamMyWXpJek5EZ3dNelU0TWpJeE9EZ3dPVFkwTlRWaU4yWXpaakprTlRaaE5HSmhZbVU0WkRka09UZGpZMlF5TmpnMVl6VXdZbVJpTXpVNFpHUmlOekVpZlN4N0ltbGtJam9pWkdsa09uTnBaR1YwY21WbE9tUnBaRkJ2Y25ScGIyNUpaMjV2Y21Wa0kydGxlVElpTENKMGVYQmxJam9pVW5OaFZtVnlhV1pwWTJGMGFXOXVTMlY1TWpBeE9DSXNJbTkzYm1WeUlqb2laR2xrT25OcFpHVjBjbVZsT21sbmJtOXlaV1JWYm14bGMzTlNaWE52YkhaaFlteGxJaXdpY0hWaWJHbGpTMlY1VUdWdElqb2lMUzB0TFMxQ1JVZEpUaUJRVlVKTVNVTWdTMFZaTGpJdVJVNUVJRkJWUWt4SlF5QkxSVmt0TFMwdExTSjlYU3dpYzJWeWRtbGpaU0k2VzNzaWRIbHdaU0k2SWtsa1pXNTBhWFI1U0hWaUlpd2ljSFZpYkdsalMyVjVJam9pWkdsa09uTnBaR1YwY21WbE9tbG5ibTl5WldRamEyVjVMVEVpTENKelpYSjJhV05sUlc1a2NHOXBiblFpT25zaVFHTnZiblJsZUhRaU9pSnpZMmhsYldFdWFXUmxiblJwZEhrdVptOTFibVJoZEdsdmJpOW9kV0lpTENKQWRIbHdaU0k2SWxWelpYSlRaWEoyYVdObFJXNWtjRzlwYm5RaUxDSnBibk4wWVc1alpYTWlPbHNpWkdsa09tSmhjam8wTlRZaUxDSmthV1E2ZW1GNk9qYzRPU0pkZlgxZGZRIiwic2lnbmF0dXJlIjoibnFTNDNLeTNYUjBmanRQTHFVaHpTRWhKLWlUbEJ0ZXdGdDl1dDN3YVhyMWhaRTRQSy1VcXZEYzlzVUtscTZNX0hDdHkxVkM1U1Fpa0FPVlRPN3JnRkEiLCJwcm9vZk9mV29yayI6InByb29mIG9mIHdvcmsifQ"
  ]
}

The merkleRoot is used prove that a given operation is included in a batch. See here

Development Commands

. ./env
npm run start-ganache
npm run contracts:test
npm run contracts:migrate:dev
npm run test

sidetree-ethereum's Issues

Review of the EthDIDAnchor contract

Review of the EthDIDAnchor contract

Issues

Here are some issues I found with the EthDIDAnchor contract:

Use of both anchorHash and ipfsHash

It's not clear why we need both anchorHash and ipfsHash and what the relationship between them are. The implementation spec in the sidetree-core repo specifies the use of an "anchor file hash" that represents the hash of the file containing the batch of sidetree operations. It seems that we can just use one anchorFileHash in the transactions array.

Anyone can reset the mapping from anchor hash to ipfs hash

Anyone can call the function newAnchorHash with an existing _anchorHash and an arbitrary _ipfsHash. This overwrites the previous mapping in the anchors map. I'm not sure about the functionality of the two hashes (see above) but this is probably not the intended functionality.

Blocknumber should be recorded along with anchor file hash

The sidetree-core spec requires that the anchor file hash be recorded together with a transaction number (which is included here) as well as a transactionTime, which can be a block number. To remedy this another array blocknumber can be introduced where the blocknumber can be stored indexed by the transaction number.

Possible optimization: use only Events and not on-chain storage

Since we are not expecting that the data here should be readable by smart contracts on-chain we could log the data only as an Event (like what is done with AnchorHashCreated). This will avoid some unneccessary on-chain state but will still give strong guarantees about the data.

A downside of this optimization is that it is more cumbersome to read the data since it's not all available in the latest state database. The whole blockchain will need to be traversed sequentially.

Recommendations

Remove ipfsHash and the anchors mapping

This is not needed in order to be compliant with the sidetree-core spec. Only one hash is needed.

Add an array to keep track of blocknumbers

Add an array blocknumbers to map transaction numbers to block numbers in order to be able to get block numbers along with anchor file hashes.

For event-based optimization: use only transactionNumber and Events

If we want to do this optimization we may remove all on-chain data except transactionNumber and use an Event to store the following data: anchor file hash, transaction number, block number (block number may be reconstructed later so may can probably be omitted).

. ./env file does not exit.

What does ./env file here means?

Support TypeScript Full Node with Sidetree (core)

We need a repo similar to https://github.com/decentralized-identity/ion

which uses core, ipfs and ethereum sidetree repos, and can be used to test integration.

Limit who can execute the smart contract

The smart contract containing all the anchors will live on the Ethereum main net. We want to ensure only valid actors are able to update the state of the contract. This could involve staking ether that releases back to the owner over time, to insure good behavior. There are other options too.

The purpose of this ticket is to discuss the implementation, and we can then create an issue for the implementation work required.

Add API route to fetch latest DID Doc for a given DID

Given a passed in DID, return the latest version of its corresponding DID document.

Add Pagination Support

Related to decentralized-identity/sidetree#37

We want to be able to fetch batches by their corresponding transaction numbers. Each batch added to the smart contract will have a transaction number, starting at 1 and incrementing by 1 for each added batch.

Sample response: https://github.com/decentralized-identity/sidetree-core/blob/master/docs/implementation.md#response-body-example

An open question is how many transactions in addition to this one do we want to return? The spec keeps this open. It would help to understand how this is intended to be used. If it's for paginating through all transactions, then returning 10 (or more) makes sense, or having that be another request parameter.

@thehenrytsai thoughts?

Create a service method that updates a DID

Given a passed in request body for an existing DID, update the DID's document. Example update would be to add an additional key.

The tests should cover the case where the passed in DID can not be found.

This ticket is for the service function, not the API route.

Add IPFS setup steps to README

Init the project

Create a truffle project, add the .gitignore, basic README and get the project going

ERC725 and ERC735

Specifically, how does sidetree-based DID method differ from ERC-725 and ERC-735 implementation? I am working on ERC725 and ERC 735 and am exploring how DID identifiers can be related vis-a-vis Ethereum.

Add ipfs module

We should encapsulate the IPFS interface within a module. The interface should expose methods that allow a caller to:

• fetch data for a passed in ipfs address

Create the API for writing Sidetree transactions

https://github.com/decentralized-identity/sidetree-core/blob/master/docs/implementation.md#write-a-sidetree-transaction

Since this may be the first API, this will have a lot of other subtasks including:

• installing KOA (or Express). need to research
• stub out the smart contract integration piece
• choose a test framework (or we can add this as its own issue)

Create a service method that revokes a key from a DID

Given a passed in request body, revoke a key from a given DID.

The tests should handle the case where the given DID can not be found.

This ticket is for the service function, not the API route.

Create a service method that creates a new DID

Given a passed in request body, generate a DID of the form did:side-eth:xyz where xyz is the hash of the passed in request body. This function should return the generated DID

This ticket is for the service function, not the API route.

Create the API for fetching Sidetree transactions

https://github.com/decentralized-identity/sidetree-core/blob/master/docs/implementation.md#fetch-sidetree-transactions

GET /v1.0/transaction

Add API infrastructure

Look into adding Koa or Express for the API route handling. Koa is used in sidetree-core so it may be helpful to keep in sync with that.

is this repo still active ?

I am trying to run sidetree on top of ethereum,but seems this repo is no longer used.
Where should I start for sidetree + ethereum?

which npm version

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/assert.h:93:25: note: expanded from macro 'assert'
(__builtin_expect(!(e), 0) ? __assert_rtn(func, FILE, LINE, #e) : (void)0)
^
2 warnings and 5 errors generated.
make: *** [Release/obj.target/scrypt/src/node-boilerplate/scrypt_common.o] Error 1
gyp ERR! build error
gyp ERR! stack Error: make failed with exit code: 2
gyp ERR! stack at ChildProcess.onExit (/usr/local/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:262:23)

Persist the batch transaction number in the smart contract

https://github.com/decentralized-identity/sidetree-core/blob/master/docs/protocol.md#sidetree-transaction-processing

We'll need to persist the transaction number for each batch. We'll prob need another mapping to track this, smth like:

transactions[transactionNumber - 1] = ipfsHash

// and since we're currently setting the `anchors` mapping(hash) to a boolean, we could set it to the txNumber instead
anchors[ipfsHash] = transactionNumber

Create the Smart Contract that will hold the anchor file hashes

• hold an array of the anchor file hashes (AFH)
• keep a field nextIndex that indicates where in the array to write the next AFH
• keep a mapping of bytes32 (the AFH) to uint (the index) to be able to lookup/verify an AFH has been written

Not doing yet:

• limiting who can execute these functions. We'll want to prevent just anyone from doing that, but that's out of the scope of this ticket.