Type 3: Transfer of Document Ownership
The notary service in the last part brings in the concept of ownership. The ownership is achieved by either an external user account system, or relying on third-party such as Certificate Authority in Public Key Infrastructure (PKI) system. In implementation we can use either larger data space in native transaction, or contract coding capability on blockchains.
In some scenarios, a transfer of ownership is desired. We will examine first the previous models and see how it can achieve the transfer of ownership. Later we will take a look on how this can be done in NEM blockchain using their built-in notary service and multi signature account.
Ownership Recorded in Database
We are referring the same model in previous article.
Here the ownership is maintained in an off-chain database. The change of ownership is surprisingly simple: we simply change the record.
Say if we are changing the hash recorded in TX ID #3 to charlie.
It seems simple. However, as notary service, user and third parties will question again the implementation using a central and external database. A decentralized solution is more desired.
Ownership Recorded on Blockchain
All the other implementations in the previous article, except the one mentioned above, are classified as on-chain approach, that is, the ownership is recorded inside the blockchain in various ways. In summary they are one of the following,
- recording user ID into data field inside the transaction, and use transaction ID for verification
- recording signature created by a user into data field inside the transaction, and use transaction ID for verification
- recording signature in a deployed contract, and use hash for verification
When the data is recorded inside the transaction (case 1 and 2), the transfer of transaction means a new transaction is initiated with the new user ID or signature. For example, if the document (hash) recorded in TX ID #2 is to be transferred from alice to charlie, it is a new transaction (say TX ID #4) recorded in a later block.
As there is a new transaction, the verification is now on TX ID #4 instead of TX ID #2 as in the past. Note that there is no mechanism to relate the same document hash between TX ID #2 and TX ID #4. An external system can help if provenance is needed per document. We need both TX ID #2 and #4 in order to understand the change of ownership on the same document (hash).
Implementation in contract code is much easier. A new function can be added to update the record. In this example, we have a new function called updateRecord() which can modify the state table with new signature.
What happens when updateRecord() is called? The table entry of index hash is updated accordingly.
Solidity supports events with index. Therefore we can add event emission to external system such that the provenance can be easily checked.
A Different Approach from NEM: Apostille
NEM blockchain is a public ledger which provides some unique features. And these features provide a different way in handling transfer of ownership in document.
Apostille
Apostille is the notary service built in NEM blockchain. Instead of simply placing a hash on to blockchain as a data, Apostille creates a sink account representing the document. This sink account is like a normal user account, has a private key and therefore a public address. We can roughly consider that this file is now represented as an account, with proper information recorded in a transaction.
Here is how to initiate an Apostille service request from the Nano Wallet.
After selecting a file (here is document.txt), we can see a Sink Address (TC4PYL…) and the file hash is computed (to be accurate, a header is added in front of the actual hash value).
After we send such a request to NEM blockchain and the block is harvested, we see a transaction recorded in blockchain, which is,
From the transaction detail we see,
- the transaction is initiated from an account Primary, which is myFirstAccount in the screenshot above.
- the transaction is sent to the sink account (TC4PYL…).
- the message contains the file hash from the screenshot above
and this transaction has a transaction ID (shown as Hash here, bb5a63…).
For verification whether a given document is the original one, we need the transaction ID and this given document. We retrieve the message from the transaction ID and compare the recorded data against the hash or the given document. If it is a match, the document is verified.
Multi Signature Account
NEM also supports natively multi signature (multisig) accounts. It is created by converting a normal account and assigning the co-signatories for this multisig account. During conversion one can specify the “approval” requirement for this account, such as m out of n co-signatories required (m <= n). For example, a multisig account can be owned by 3 co-signatories, and for a successful transaction, 2 signatures are needed.
Multisig account, like other accounts, can own XEM and Mosaics (smart assets in NEM). The only difference is that the multisig account cannot initiate transaction. It is one of the co-signatories initiating transaction on behalf, and the transaction is processed only the required number of signatures (approvals) received from the co-signatories.
The co-signatory of a multisig account can be modified in a specified rule that,
- to add one more co-signatory, approvals of all existing co-signatories are needed.
- to remove one from the co-signatory list, approvals of all except the one to be removed are needed.
As a special case, if we only define one co-signatory and one signature required, it is a 1-of-1 multisig account and equivalent to “an account is owning another (multisig) account”.
Equivalently, here myFirstAccount is owning the Sink Account on the document. myFirstAccount can perform all execution on behalf of this sink account.
When necessary, the owner (myFirstAccount) can transfer the ownership of this sink account to another. For example, myFirstAccount transfers the ownership of this document (sink account) to mySecondAccount.
From now one, myFirstAccount can no longer interact with the document (sink account) as mySecondAccount is now owning it. This is how the ownership of a document (represented by the sink account) is transferred.
Summary
We see various ways to handle transfer of ownership of a document on the blockchain. Depending on the implementation it can be simply an update on a central database, a new transaction on the same hash value, execution of a function to update the record in a contract, or a different way using special features on a blockchain.
This is the end of this series. Hope you enjoy it. You can revisit the first two parts here.
Please give me some claps if you find this article helpful.
