Cronica

architecture

Version 1.4, September 2019

Product description
Cronica is a blockchain-based platform that enables banks and institutions to
securely generate and authenticate programmable documents. Each
programmable document is represented through a smart contract and is
cryptographically secured through the Quorum blockchain.

Cronica replaces an imperfect system – of physical documents and stamps,

susceptible to mishandling and misuse – with a secure and scalable platform.
Cronica provides digitized authentication through a fully integrated, modular
blockchain solution that stores documents securely and transparently, with
permissioned access.

Cronica drastically reduces the administrative burden of document generation,

authentication, and retrieval, minimizes the possibility of human error (i.e.,
Cronica documents cannot be lost or mishandled), and massively improves the
user experience.

01
Secure document storage is provided through the sophisticated Quorum
Constellation system, which guarantees that only permitted users will have
access to document data.

Cronica has three features that makes this solution unique to other
blockchain-based document verification solutions

Programmable Documents
Each document in Cronica is represented in the form of a smart
contract, which stores all document data. Smart contracts are
computer programs that, in addition to storing data, can
execute pre-programmed agreements and data transactions.

Separation of document data and representation

Cronica operates document data and separates it from
humanreadable representation (e.g., PDF). Representation is
generated via templates, on demand

Document search by text data

In addition to the smart contract, document data is also stored
on an internal database that allows for text search

User roles
Cronica users have one of three basic roles:

Issuer Admin Verifier

Can publish Admin user, which can Can validate the

documents register/remove nodes in the documents
network

Each Cronica user may be granted one or more of the roles listed above.

02
Document ID
Document IDs are used to uniquely identify each document on the Cronica
platform. When a document is sent to the Issuer’s backend for deployment, the
backend generates a long random string (40-symbol length). This string is a
nonce – a random number that can only be used once – and is incorporated into
a smart contract as a field (secureRandomToken) and deployed to the Quorum
network.

Once a smart contract has been deployed, the Quorum network returns the
smart contract address in a key hash form, e.g., 0xabcde, etc. Concatenated with
the nonce string, it then forms a Document ID.

Document ID = <smartContracAddress><secureRandomToken>

This way, each Document ID is unique and cannot be predicted or generated in

advance. It is not possible, for example, to generate a range of IDs and store
them for later use.

Documents are only recorded as immutable data sets on the blockchain and,
likewise, the nonce string is generated and immediately recorded onto the
blockchain, and cannot change or be altered.

03
Document Storage and
Security

Document hash Issuer Issue date Expiration date

All documents in Cronica are represented by smart contracts. When a document

is uploaded, a smart contract is deployed to the Quorum blockchain network,
along with the security settings (see below) and a set of parameters, including:

Document Status is a technical field that is calculated from the fields stored in
the document’s smart contract. Document status can be one of the following:

Valid – document smart contract exists within the Quorum blockchain

and expiration date is either not set or now() < Expiration Date

Revoked – document smart contract exists within the Quorum block-

chain but is revoked by Issuer (invalidated by issuer)

Expired – document smart contract exists within the Quorum blockchain

and expiration date is either not set or now() >= Expiration Date

Not Found – document smart contract does not exist on the Quorum
blockchain.

How document data is stored depends on the type of document. Generally, only
the hash of the data is stored (hence, hashed documents) due to the resource
cost of storing document data on the blockchain. For structured documents,
however, document data is stored on the blockchain.

04
Storing of hashed documents
A hashed document is a document that can be displayed to a user without any data
modification. Cronica ensures the document data is consistent, which it achieves by
keeping the hash of the document data within the smart contract, on the blockchain.
Access permissions are limited by parameters set on smart
contract deployment. A hashed document is stored as a smart contract that does not
have document data.

Cronica stores document data separately – currently, in an internal RDBMS.

Smart contracts are replicated between permitted nodes on the Quorum

blockchain. A smart contract may exist on two or more nodes, but the document data
will only be stored by the Issuer (i.e., the first) node. This means document data can only
be accessed by the Verifier by requesting access from the Issuer (who is free to deny
access). This is how hashed documents differ to structured documents.

Storing of structured
documents
A structured document is a document that requires some transformation for users to
view it (e.g., a set of financial document data in JSON format that requires conversion to
a PDF template).

Technically speaking, it makes more sense to hash and securely store the original set of
document data rather than saving its representation. Through this, only essential data is
stored until a human readable representation is required (i.e., a PDF), which can be
generated from a template.

For structured documents, Cronica stores the set of data inside a smart contract along
with its hash (for compatibility reasons). This way, document data can be accessed by all
permitted actors from within the Cronica blockchain in machine readable form, without
any need for the Issuer’s servers/resources, or for parsing data from the representation
document.

05
Document data
Document data is stored on the blockchain, while document templates are stored
separately and locally for each actor (Issuer or Verifier). This means that Verifiers
can prove document data exists and match the hash. However, to retrieve the
representation of the document in PDF, the Verifier must claim the PDF directly
from the Issuer via HTTPS protocol. Therefore, the Issuer may or may not enable
a public interface that allows for PDFs to be downloaded, and may filter these
requests on its own.

Such an approach may be necessary if a Verifier has their own template for creat-
ing document representation, which may differ from the Issuer’s template, while
keeping the same set of essential data.

06
Example Flow 1
Document data is stored on the blockchain, while document templates are stored
separately and locally for each actor (Issuer or Verifier). This means that Verifiers
can prove document data exists and match the hash.

However, to retrieve the representation of the document in PDF, the Verifier must
claim the PDF directly from the Issuer via HTTPS protocol. Therefore, the Issuer
may or may not enable a public interface that allows for PDFs to be downloaded,
and may filter these requests on its own.

Such an approach may be necessary if a Verifier has their own template for
creating document representation, which may differ from the Issuer’s template,
while keeping the same set of essential data.

Issuer.node Issuer.website Person Verifier.node Verifier.website

Request Certificate

Publish to Blockchain

Generate
PDF
Distribute Certificate Smart Contract Store a copy of
Certificate data

Validate Certificate by ID

Get Certificate Data

and Hash

Get Certificate PDF

Certificate PDF

Show Certificate PDF on

Verifier’s web site

07
PDF Templates

PDF templates are stored inside specific template smart contracts: template data
(binary) is incorporated into a permissioned smart contract, between the Issuer
and the Admin. When a document is generated, the document smart contract
references the template smart contract via a hash address. This way, document
data is bound to the specific PDF template, which may contain important legal
references.

Storing templates inside smart contracts has the benefit of making templates
unalterable. Through this approach, template binary data is stored at least once
on the blockchain and templates will always exist within the Quorum network.

A verifier will always be able to generate a PDF to the correct template, as long
as they have the corresponding reference address.

08
 <<Template>> <<StructuredDocument>>

+ bytes: issuer + bytes: issuer

+ string: templateName + string: documentName

+ bytes[]: data + uint64: issueDate

Basic structured
+ uint64:expireDate document smart
contract
+ string: hashData

+ bytes: recipientName

+ address: template

+ bytes: status

Instantiates

Extend

IncomeCertificate

+ uint64: periodStart
Sub class of basic
+ uint64: periodEnd
structured smart
Template Instance
contract representing
(for Income Certificate) + uint64: income exact certificate

+ string[]: quarterPeriods

+ uint64[]: quarterIncomes

Referencing
by address
Deploy Instantiates

Income Certificate
Deploy Instance #1
Income Certificate smart contract
instances are referencing the same
Template Smart Contract instance.
When PDF is generated, template
Issuer Deploy
data is taken out of exact Document
Smart Contract
Income Certificate
Instance #2

09
Document registration
transaction types
Each document is stored in a way that each actor can validate its authenticity
(i.e., check that the document ID is valid and that it exists on the Quorum
blockchain), but not all the actors can read the document. There are three
ways documents can be stored:

Private (document data is available for Issuer only)

Permissioned (document data is available to a limited and pre-defined set of

other actors)

Public (document data is publicly available to all actors)

Technical: These Document registration types are directly derived from

Quorum transactions types: Public and Private

Public document is a smart contract deployed by a public transaction on the

Quorum blockchain (code 27 or 28).

Private document is a smart contract deployed with a private transaction on the

Quorum blockchain (code 37 or 38) with a Limit To parameter not specified (i.e.,
issuer only).

Permissioned document is a smart contract deployed with a private transaction

on the Quorum blockchain (code 37 or 38) with a Limit To parameter set to a
predefined set of Quorum node addresses that can receive the transaction and
read the smart contract data.

10
Platform
The Cronica platform is built on the Quorum blockchain, originally developed by
JP Morgan, which is a smart contract-enabled blockchain that allows for secure
private transactions and smart contracts.

Quorum security is based on the Constellation system – a private P2P network

that allows for secure peer-to-peer data transfer and storing. Combined with
modified Ethereum nodes, it allows for secure P2P transaction payload transfer,
which enables Quorum to process private transactions and smart contracts.
More details on Quorum architecture and security can be found here.

As a document verification solution, Cronica extends Quorum with a set of APIs

and services that allow for document storage, validation, and search retrieval.

The diagram below describes the data flow during the upload of a structured
document, along with generation of its PDF representation via a template. The
search process is described both via the Issue’s interface and via the Verifier’s
interface. The difference is that the Issuer’s interface allows for searches by
multiple data fields, while the Verifier’s interface allows for searches on
Document ID only.

11
 Actor Actor Actor

Enterprise Enterprise
Internal Internal
System System

Upload Search
Search for Upload Search for
Certificate Certificate
Certificate Certificate Certificate
via API by ID

Cronica Certification Cronica Verifier Cronica Verifier

Cronica Web Site
Issuer API Authority Web Site API

Search for Store Store

Certificate ID
by Data

Database Cronica Issuer Cronica Verifier

Issuer stores Certificate Data is hashed

certificate ID and and Smart Contract Search
Data in relational deployed to Qourum Node Certificate
database to perform along with Certificate Data by ID
search operations

Secure Data Exchange

Quorum Node (playload hashes only) Quorum Node

Store Cert Data Request Cert Data

Tessera Secure Data Exchange Tessera

Node (private transaction playload)
Certificate Data is Node
transferred via secure
channel via Quorum
Constellation node

12
 Bank A Bank B

Inter-bank Inter-bank
Quorum Quorum
Quorum Network Quorum Network
Node Node

DB DB

Issuer API Verifier API Issuer API Verifier API

Issuer Client Verifier Client Issuer Client Verifier Client

Bank Employee Person Bank Employee Person

Bank Internal Bank Internal

Network Public Segment Network Public Segment

13
Cronica network
administration
Cronica is managed with a single public administration smart contract, in which
all available Issuers are listed. When Cronica is first started, the administration
API deploys the public administration smart contract from the Quorum node it is
connected to. This Quorum node is the only node allowed to make any changes
to this smart contract.

The administration API allows for adding/removing Issuers and changing their
parameters. These parameters enable other Issuers and Verifiers to generate
valid links to the PDF representations of documents, and include the Issuer
Quorum node public key (required for sharing permissioned documents) and
URLs to the Verifier API for redirecting users to PDF representations of the docu-
ments listed by particular Issuers (assuming that each Issuer also deploys a
Verifier API).

http://cronica.io
hello@cronica.io

14