Introducing the Notary Proxy — The Ethereum Oracle Trust Layer

One of the problems with getting external data from URLs or APIs into a dApp is trust. Getting the data in has to be achieved through what is commonly known as a “data oracle”. The purpose of a Oracle is to accept requests for data (E.g. A URL or API endpoint) and then fetch that data before passing it back onto the smart contract/dApp.

The problem is how can you trust the that in between requesting the data from the API endpoint and returning it back to your dApp the Oracle (Or any malicious actor in between) hasn’t altered the data for their own benefit?

You have to place trust in your Oracle as the only known and trusted element in the chain is the API/URL endpoint! You have to trust that the data passed back to you from the Oracle is the data it received from the URL or API endpoint. That’s a lot of trust! In theory the data could be modified by the Oracle service!

The dAppBridge service is what we believe to be the easiest and most powerful Ethereum Oracle service launched to date… and today we have enhanced the trust model by introducing a trust layer to the oracle request service.

Notary Proxy Trust Layer

With the Notary Proxy now integrated into the chain we can see that ALL requests are directed through this audit-able & trusted service. What happens next is the key to giving this trust…

A few things of note about the Notary Proxy:

1. It is hosted on a separate environment to the main dAppBridge service, to provide independence
2. The full source code is available for audit so you can clear it isn’t tampering with data (https://github.com/dAppBridge/NotaryProxy)
3. The actual running instance (AWS Lambda service) is also audit-able to confirm that it hasn’t been altered, tampered with and is running the latest release source code without any changes (See: https://github.com/dAppBridge/NotaryProxy)

So the Notary Proxy can be trusted… it is in effect a 3rd party independent service. It’s sole task is to:

1. Take requests
2. Request the data from the API or URL endpoint
3. Store a public secure hash of the returned data (For later verification)
4. Return the data back to the requestor

It does not store the full response data, or in any way tamper with it… as you can check from the source code.

So now it doesn’t matter if you don’t have full trust in the Oracle service… you can validate every piece of data you received agains the public data proof store!

Auditing a request/response

When you make a request for data using the dAppBridge service you will be given a unique request Key. When the data is returned it will be supplied with the same key…

To verify the data you have now received is a simple task — all you need to do is:

1. Create a Keccak256 hash of your returned data (We suggest using: https://emn178.github.io/online-tools/keccak_256.html).
2. Download the trusted data proof from Notary Proxy at: https://s3.amazonaws.com/notaryproxy-audit/[request_key] (Where request_key = your original request key above
3. Within the file downloaded compare the Keccak256 hash you’ve generated to the one supplied here… this confirms the data received from the URL/API endpoint is the very same data you’ve received within your smart contract!

Full, transparent accountability of data proofs!

For more information please read:

dAppBridge/NotaryProxy

And:

dAppBridge/dAppBridge-Client

Get in touch

Let us know how your using dAppBridge, if you have any questions or need any help! dapps@dappbridge.com or https://twitter.com/dappbridge