Architecture
Chainscript
Chainscript is an open JSON Standard for Proof of Process. By extension, digital records of cryptographic audit trails are referred to as chainscripts. Chainscript describes how each step of a process should be formatted so that:
- It is unique
- It is immutable
- It has only one parent
- It can have multiple children
Agent
The agent
runs multiple processes. Each process is responsible for transforming data into
Chainscript. It knows how to initiate a new map
, how to add
a step to an existing map
, how to notarize and save steps, how to find and
filter existing steps.
A process can be configured by declaring the different transitions that may
happen to each steps and by implementing in JavaScript the mutations that these
transitions imply. These transitions are called actions
.
The agent exposes an HTTP API that provides read and write access to the underlying processes.
Agent Clients
An Agent client wraps the HTTP API so that it’s easy to use in your language of choice.
Implementations currently exist in JavaScript and Ruby.
Agent UI
The Agent UI provides a simple generic graphical user interface that allows anyone to get information about agents and to read and write new steps in a process.
It leverages the JavaScript Agent Client and the Map Explorer.
Map Explorer(s)
This generic component can be used to display a specific map
in a process.
It is configurable and extensible.
It is available for different frameworks (React, Angular, Angular2, Ember, Rails).
Store and fossilizer
Once a new step (called segment
in Chainscript) has been
created by the Agent, it needs to be stored and (eventually) fossilized.
It can be stored in a regular (centralized) database. In that case, to reduce
the trust put in the database owner/administrator, the segment
needs to be
timestamped. We can use any timestamping service but a public blockchain such as
Bitcoin provides a secured, decentralized, powerful,
cheap and fast timestamping service.
This fossilization, as we call it, provides a strong proof of existence.
This architecture is already pretty solid but:
- The Agent is centralized. It cannot be trusted (with private data for instance).
- There is no warranty a piece of data won’t ever be removed.
- The Agent/owner of the database has to be trusted to enforce business rules.
- It is dependent on a public blockchain on which the user has no control.
To address these issues, segments can be stored in a permissioned blockchain.
With this kind of architecture:
- Each stakeholder can have his own agent that can be trusted with private data. It can encrypt data, sign data, generate zero-knowledge proofs, etc.
- Fossilization becomes optional. The blockchain already provides a timeline and a proof of existence.
- Business rules can be agreed on, and enforced at the storage level. Consensus can be reached on a single version of the truth (this kind of feature is not yet available and currently being researched and developed at Stratumn).