nChain Event enables you to employ both encoded and unencoded* records.
Records can be either independent or linked when they are on the blockchain.
Records can be written to, read from, and verified with the blockchain.
Note: * Unencoded records available by prior arrangement with nChain
To enable your applications to use nChain Event, you can add an interface in whatever language you use. Store the URL and API key for nChain Event there and provide access to the REST API endpoints, which are described here and here. Example code is provided throughout this user guide, and pseudocode is provided in tutorials here and here.
An input record is any packet of data supplied by you that you want to register on the blockchain. You can choose whether the input record is binary or text, or a private reference to data in your own system. The input record can be a single data item or a mixture of data fields. The input record can contain whatever you need to assist and support your use case.
See the "Model" encoder in the diagram above: You supply the input record to nChain Event as the encoder input. nChain Event encodes it using the encoder you specify, producing the encoder output. The encoder output is written to the blockchain inside a transaction.
This is generally called a record in this document. See the diagram above.
Note: Only nChain Event blockchain records can be processed by nChain Event.
Please note that for nChain Event, the process of translating records from one format to another is defined as "encoding", even though this may comprise a one-way summary of data that cannot be reversed, or secure encoding of data, as well as potential reversible transformations of data.
See the "None" encoder in the diagram above: Where you do not select an encoder, the encoder output will be same as the encoder input, and it will be this unencoded record that is written to and read from the blockchain. Unencoded records are also known as "raw data".
See the "SHA256" encoder in the diagram above: Where you do select an encoder (for instance, SHA256), the encoder output will be the fingerprint of the unencoded input, and it will this fingerprint that is written to and read from the blockchain.
A fingerprint is a few bytes which uniquely refer to the original record. It is not practical to recreate the original record from the fingerprint. Fingerprints are produced using complex mathematical transformations on the input record. These obfuscate the output record. They are so effective that inverting just 1 bit of the input record changes approximately 50% of the bits in the output record.
Several standard encoders are provided by nChain Event. Please contact us if you need alternative encoders.
For unencoded records, the SSoT is the record that has been written to the blockchain. We recommend that you can keep a secure copy locally, but it should be checked with the blockchain which should be considered the principal truth.
For encoded records, the SSoT comprises the SSoData which must be securely stored by you, and the SSoProof which is the fingerprint on the blockchain. You need both data items to ensure that the SSoT is valid:
SSoData = your original data
SSoProof = fingerprint of SSoData, from the blockchain at the stored location
if encoding(SSoData) equals SSoProof then SSoData can be used as the SSoT
otherwise SSoData cannot be used as the SSoT and it may be impossible to recreate it
When a record is written to the blockchain, a unique record location (just called a location in this document) is returned. See the diagram above. This can be stored and used for subsequent operations.
The locations can also be distributed for use by data users, data verifiers, data auditors, and any other interested parties.
Locations are the transaction hash (often called the TXID by the blockchain community) of the record transaction that has been written to the blockchain.
Locations are vendor-neutral.
