As a freelance, I worked on documents certification using the Blockchain. This is an interesting problem because it is a type of feature that we could not implement in a trustless way before. Thanks to this type of project, companies that have not yet "jumped" into decentralization are getting their first taste of the ecosystem and can implement completely new features.
Public blockchains are great for timestamping.
A public blockchain like Ethereum or Bitcoin is a database that the whole world verify at all time. No one can get around the rules of the Blockchain, not even its creators. As a result, the data stored there is exceptionally reliable.
A use case of the Blockchain is therefore timestamping. The idea is to allow an entity, for example, a company, to certify a document by publishing the information "we, Acme Inc., certify the veracity of this document as of date X."
It is very different from a centralized system: in a centralized system, an administrator, or a hacker with administrator rights, may modify the data or the program at any time. It would be possible to timestamp data a posteriori for example.
Use-case: Irrefutably prove the signing of a contract on a specific date.
A team contacted me to set up a document certification tool. They needed to generate and sign contracts with their users and have proof of each contract's existence on the date of signing. These contracts have many legal implications, and they are very binding for them and their clients: the proof must be irrefutable.
The Blockchain was an ideal solution in this case. It allows proving that the contract was signed on a verified date and with a verified content. There is no need for a third party, so the evidence is as reliable as the crypto tools used by Ethereum.
Basics of Crypto: Digital Fingerprint
In areas related to Blockchain and networks, we are very attentive to data. Storing a few bytes of data on the Blockchain involves duplicating them millions of times on all the machines on the network. This is an expensive operation: we must transmit the data, verify it, and store it indefinitely. Therefore, we have to be smart when we ship and verify data.
This is where hash functions come in. These functions allow you to calculate a file's fingerprint. This fingerprint is unique. No other file has the same fingerprint. So, just as a fingerprint identifies a human being, a file's cryptographic fingerprint uniquely identifies a file.
Here is the hash of the first chapter of The Little Prince by Antoine de Saint-Exupéry: d4b4e3e2b91edaed75b7791ced10afd53441e7f19e463a8b675619a081e3152d
By changing the first letter, the hash is completely different: 009d8d2e8fd8e5a049c148bece24f1fdf401b87d5a0483ef910e367f273c891d
(I am using the SHA256 algorithm)
If I want to prove to someone that I own a file, I can share the hash of that file with them.
These are ideal for our use-case: We calculate the hash of every contract, and we publish it. We don't need to publish the entire file, which preserves confidentiality and drastically reduces our costs.
Smart Contract
For this client, we set up a "Smart Contract" on the Ethereum Blockchain. It's a piece of software that "exists" in Ethereum. It doesn't reside on a computer on the client's network; this program resides "in" Ethereum. As a result, it benefits from all the network's properties: impossible to falsify and cannot be modified without abiding by the rules of the network.
We interact with this program by sending Ethereum transactions that contain data and instructions. That is very similar to an API but on the Blockchain.
In this case, the timestamp contract we are using is straightforward: it has an owner and a "timestamp" function which outputs a timestamp signal.
This is what our Smart Contract looks like:
A few notes:
We use OpenZeppelin, a common framework in the industry. It provides a reliable implementation for many classic features. Here we use Ownable: the contract has an owner, and he is the only one who can call the timestamp function thanks to the isOwner transformer.
The timestamp function is highly optimized. We do not store data in the SmartContract's memory because it is an expensive operation. Instead, we emit a log to keep a trace of the timestamping process. Because of that, we won't be able to modify the data later, but this is a good trade-off for our use case.
The timestamping process
The process is:
- We compute the document's hash,
- Using our "administrator" account, we send a transaction that asks the SmartContract to process the hash. This hash is recorded on the Ethereum blockchain "definitively".
- We can now send the document a link to the transaction to the end-user. They will be able to prove irrefutably that the contract was certified at a given date.
You can find the example of such a transaction on the Blockchain Here. According to today's price (September 2021), this operation would cost 15 cents.
The Off-chain Part
We have seen the relatively simple Blockchain part. However, in practice, for such a project, we must take care of other issues such as the security of the admin keys, error management, scalability, etc.
In our case, we needed to sign a large number of contracts quickly. Unfortunately, transactions on Ethereum are relatively slow. You may have to wait several minutes for a confirmation. So we set up a service that lets the rest of the application interact with the Blockchain asynchronously.
Off-Chain Infrastructure
The Blockchain's complexity is "absorbed" by the off-chain part and hidden from the rest of the application. Using this approach, the Blockchain becomes a service "like any other," which provides a particular feature to our infrastructure.
This is just the beginning.
This system processes nearly ten thousand contracts daily. But of course, it's a sketch of the final product. We still lack details about keys management, parallel transaction management, errors, etc. I will be posting more articles on the subject, so you may want to subscribe on laurentsenta.com.
If you want to know more or have any questions, please reach out on LinkedIn or Twitter.
Top comments (0)