Offchain Verifiable Data Notary
Trusted actors such as public notaries have legal liability and responsibilities to dutifully conduct the verification process of data during the notary process.
As part of digital transformation of business processes in the last decades, many of the processes have become digital with equivalent legal value. This has created the basis for many self-containing verifiable data.
For example, the process of identifying the physical person and witnessing a physical signature can be done with Qualified Electronic Signatures (QES) that are identifying and legally binding across Europe.
By carefully selecting the verification mechanism for the types of data to process, a decentralised application can use [notary] module with deterministic programmable verification process to onramp data the D-Chain.
This module does not provide or constrains to any trust framework, it simply routes input data and transaction details to the verification mechanism, waits for the results and call the post verification actions if passed.
An example:
- Given the verifiable data is in the form of a verifiable presentation with given disclose attributes: payment date, amount, from, to
- verify the presentation and instantiate a smart contract to represent this contract onchain.
In this case, the verification mechanism is a verifiable presentation verifier, and the post verification actions include instructions tocreate the instantiation message required and instantiates a smart contract with the registered code identifier.
Types of Verification Mechanism
The nature of the data is important in order to fully utilise this module as valid part of business processes that would otherwise be conducted offchain.
Publicly & onchain verifiable data
Publicly and onchain verifiable data is defined as data that can be submitted and verified onchain (typically cryptographically verifiable), they are:
- concise / succinct: size of the data can be process in a blocks
- public: does not contain private or confidential data
- onchain verifiable: given chain state and transaction information, there is a verifier on chain to process the data
- data source agnostic: given the above conditions are satisfied, the submission of such data does not necessarily have to come from any defined source (unless defined by the verifier in point 3).
Example: suitable size zk-proofs, snarks, verifiable credentials presentations
Cryptographically verifiable data
Although data can be cryptographically verifiable, not all data can be public or suitable to be submitted onchain.
The verification mechanism perform offchain in this case is auditable. It is therefore feasible to delegated to perform pre-processing of the data (verification) in a sidecar process.e.g. Verification of digital signatures on documents / contracts and extract essentially and pubic data. The onboarded validators can perform such tasks, through extension data provided by validators on D-Chain when performing consensus voting on blocks, the extracted onramped data is also BFT.
It is important to note that in this case, validators are not attesting to the data themselves but to the verification processes - which are auditable.
Example: Digital signature for XML documents
Trusted Sender Attestation
If decentralised applications' trust framework does not require data verification onchain (or delegated), then they can assign trusted parties who are effectively the appointed verifiers of the data to submit data onchain.
In this case, the registered verification mechanism is simply a allow list matching program.
Example: data submitted by certain sender address(es) / includes certain verifiable presentation
Post Verification Actions
The post verification action is a message call within D-Chain. This includes certain smart contract instantiation / executions - support a wild range of application needs.
In the case where smart contract instances are created as the result of the post verification actions, the contracts can include credential role base access control for state transition.