Type 2: Proof of Existence and Ownership of a Document
In the previous type of notary service, or what we call Proof of Existence service, after verification process, we are confident to say that the given document exists since a specific time based on the transaction ID. However we cannot tell who owns this document.
Now we are introducing another type of notary service that can address this requirement. Besides the proof of existence, we also wish to know who owns this document.
Any Information about Document Owner?
Let’s revisit the transaction we showed previously.
Among all the information recorded in this transaction, the only piece of information that may be related to owner is the transaction initiator, that is, the address which made this transaction. In this transaction it is the address 1Jh65a….
However, there are some problems if we see this address as the owner.
- In case it is a transaction-based blockchain (not account-based) like Bitcoin blockchain here, wallet always generates new addresses to handle transaction. Therefore it is quite impossible to relate one address to the owner of this address.
- In account-based blockchain like Ethereum and NEM, transaction is initiated by an account which can remain the same. However, the address is usually owned by the notary service provider, rather than the actual user. Again, we cannot tell from the transaction initiator that who owns this document.
Obviously, in order to link the owner to a document, we need a system to identify who the user is before the document hash is recorded, or at least can link the record to a user.
User Account System
Without changing the mechanism at blockchain transaction level, the most straightforward way is to keep a record between a user account to the transaction record somewhere outside .
Many notary service today first requires a user account or login account creation. Once an account is setup, a map between the transaction ID and the user ID is kept in a database. With this database, the service providers can tell who owns the document based on the transaction ID.
This is the model of using external user account system.
It is almost the simplest way to associate an owner to the document. However, we may see some challenges here.
- The notary service provider takes the whole responsibility of user account management. The reputation of this service provider will determine the trust level of document ownership. My trust on the document ownership is because I trust this notary service provider.
- The user account system is usually implemented outside the blockchain system. This is no longer a decentralized way. This centralized approach is subject to a lot of threats, such as record tempering, distributed denial of service (DDoS), single point of failure, etc. This somehow reduces the overall confidence level even though part of the service is on blockchain.
More Information in Transaction Record
Another obvious solution is to add more information in the transaction.
In the proof-of-existence system we only put the hash of the document. What happens if we add some more relevant information in the transaction data?
As more data space is needed on transaction, we need blockchain that supports larger data space. For example, in Ethereum there is no limit on data size but the limitation is on maximum gas per block. In NEM, the data space is 1k Byte.
This is how this model works. Given a TX ID, the record is retrieved from the blockchain. From the data received the document hash is retrieved for document integrity check, and the user ID field is retrieved to cross-check who owns this document.
Note in this model, we still have a user account management system to maintain the user ID. Optionally we can remove the dependence of such system by public key cryptography: instead of register the user account on day one, the data written in the blockchain contains a signature signed by the owner, and can be verified when the owner’s public key is available and trustworthy.
Here is JSON for using signature instead of external user ID:
The working model looks like this and how verification works by a given Transaction ID.
Where is the key pair coming from? There are two options:
- use the native account system in blockchain: Almost user account in all blockchain implementations has private key and public key pair.
- use Public Key Infrastructure (PKI): In PKI each user is given a private key and a certificate. The certificate contains the identity of the certificate owner and the public key. And this certificate itself is issued by a Certificate Authority (CA) that provides a certain level trustworthiness.
The implementation of using the native account in blockchain is rather simple, as we don’t need to regenerate key pair for this purpose. But the association of signature is up to the private key owner, not the real individual. On the other hand, using PKI the CA provides a level of guarantee on the certificate owner as an individual. But PKI requires more process in both certificate issuing and verification, and the trust level now is moved towards the CA. Any problems happening in that particular CA will have direct impact on the owner of identification.
Using Smart Contract
All the implementations above are still relying on the data field inside the transaction. Alternatively this can also be implemented in contract if the blockchain platform provides contract capability. This adds certain flexibility when designing the overall application compared to static information recorded in a transaction record.
One common platform is Ethereum. Ethereum allows code running in an Ethereum Virtual Machine (EVM) that can execute logics defined in the code. The programming language is Solidity in Ethereum world.
Here is an example of notary contract in Solidity. In this contract code,
- a mapping data structure with hash of document as index
- the data record in this mapping includes the signature and the timestamp
- two functions are defined: getRecord() gets a record based on a hash value, and writeRecord() writes a record of signature and timestamp with hash value as index
This is how the model works and the process of verification the hash of a given document.
Note the use of contract code in Ethereum
- Contract can be considered as a layer on top of blockchain. While transaction is still handled in blockchain layer (mining) we can see contract as a separate system.
- After the contract is deployed, a contract ID is generated. The contract ID is where external application can execute functions inside the contract.
- As the data is not natively in transaction record, we do not use the transaction ID to obtain the data. Rather we are using the hash of document as index to search the stored data inside the contract.
- A timestamp field is added. It is because we are not using TX ID for the verification. The easiest way is to include the timestamp into the record directly. From the contract code it is done by using a keyword “now”.
One advantage of using contract to implement notary service is the flexibility you can process the data. This makes application development much easier. The downside is that the data is not natively on blockchain, and the verifier needs the contract ID and the appropriate interface to get the data. Also the contract owner becomes somehow a centralized point of the overall design.
This is the second type of notary service. Besides the existence of a document, this service provides a means of linking ownership to that document. As more data are required, this can be implemented in blockchains which allow larger data space in the transaction records. Alternatively this can also be implemented with contract code if the blockchain supports contract execution.
In the next article we will talk how the ownership can be transferred.
Please give me some claps if you find this article helpful.