Advanced ChainPoint in CircuitBuilder

In our ChainPoint in CircuitBuilder post, we covered a pretty basic example of hashing data and storing a stamp of it on the blockchain. It eases new users into the concepts of hashing, proof-of-existence, and verification.

Most processes, especially once we start looking at use in a production level environment, won't be quite so simple. So let's take a look at a more advanced case.

FIND THE ADVANCED CIRCUIT HERE (same notes as last time apply, download CB (GET IT HERE!!!) and open it once to register the protocol)

(and if you are running Windows, be sure that you don't already have CB open. This is a known bug, and we will fix it soon, but we wanted to be able to share circuits with you as soon as we could!!)

This is 2 separate workflows, contained in the same circuit.

The first one (top), labeled "Download-Hash-Anchor", does the following:

• Downloads the file from a remote server, using HTTP Downloader. This then does 2 things in parallel:

1. Saves the file locally, which terminates that branch. Once it is done, it's done. In the case of CircuitBuilder, the file will be saved in the "public" folder, relative to the directory the app is running from. This is an electron app, so it will be within the .app directory structure on a macOS and in the installed folder on Windows. On my mac, it's "/Applications/CircuitBuilder.app/Contents/Resources/app/public/".
2. Sends the file on to the SHA-256  component to generate a hash from it (like in the simple one). 

• From there, we are calling to ChainPoint to store the hash on the blockchain. The next step is also 2 things in parallel:

1. Showing the response in the Debug Console (Debug component), and
2. Saving the response (proofs) to a file, also stored locally in this case in the "public" folder.

The next workflow is a pretty straight line. This one is doing something a little more advanced, but more "real life". It is RE-hashing the original file to be compared against the hashed data that was stored on the blockchain. Since we (effectively) can't reverse-engineer hashed data, we have to start from the original data again.

• Read a local file- the one you want to confirm proof-of-existence of on the blockchain. In this exact case, it is going to read the same .png that you stored locally in the top workflow, because that is the file we want to verify, and it should not have changed.
• Create a hash from that file using SHA-256. This is your starting point for the confirmation.
• Then, read in the proof data that was stored the first time you hashed this file and stamped it on the blockchain. (For the sake of focus, we assume that you have associated original data with its resulting proofs somewhere.)
• Send that proof data to ChainPoint to verify it. This request will respond with an object with several properties, including the hash that was stamped originally.
• Finally, we are using the Transform Object component to map the upstream hash data with certain pieces of the the data returned from the Verify Proofs component. The result is a simplified response of verification, or not.
• Okay, this is really finally. Debug to show that to the Debug Console.

In your production environment, you may want to store the verification in a database or file somewhere, and/or possibly send some kind of alert on a verification failure. This may be an email, SMS, or http request to POST data to a web server, for example.

We are looking forward to seeing what circuits YOU build, and also to continue sharing circuits with you that we have built.

What do YOU want to see us build next?? Join the CircuitBuilder Chat Telegram channel and join in the discussion!