How to Democratize E-Signatures Using Blockchain Technology

There is a rather famous quote “If you want to hide something, put it in the most prominent place” — approximately the same approach we use to store private data in the public infrastructure based on blockchain technology.

We would like to explain why and most importantly why we want to store data in this way.

Digital signature — centralized vs. decentralized

In order to make life easier for a large number of people and businesses, such a wonderful thing as an e-signature was invented long ago. In fact, this tool allows you to sign documents that have the same legal force as if you had met in person and signed them. But in practice, a lot of questions arise.

Let’s say we have Alice and Bob who just want to sign some document that imposes some kind of obligation on each party, but they can’t meet offline. And that’s where the e-signature comes in. In this case, each party can just take the document, electronically sign it on each side, and send each other a public key and a digital signature.

And you can sign an electronically signed document on almost any computer; it’s free. But how to prove that this e-signature corresponds to this particular user — it is not possible at all, in fact, such a signature is not legitimate.

To simplify things completely, in this case, Alice and Bob can use some public centralized service where they enter their personal data and then this electronic signature begins to have legal value.

But, there are a number of issues:

1. Such a service requires presenting public data and storing it on a centralized server. I won’t list private data leaks through various public services, of which there are more and more every year, but it could potentially be a problem

   
   

2. If Alice or Bob regularly sign various documents with different people, they usually have to register with several services (and identify themselves with their private data everywhere) and pay each service. The problem is also that more often than not I have a mandatory payment for which I have to pay monthly or annually. I.e. if I have to sign two documents a year with a half-yearly interval, I actually have to pay for the whole year.

In other words, I have to be registered in a bunch of services — pay for them and provide private data everywhere.

Solving this problem in a decentralized infrastructure is simple enough. To do this, we democratize digital e-signatures and make them public, so that all participants can unambiguously identify the contractors with whom they do some business.

Alice and Bob can sign the same document using our infrastructure:

• To get a web electronic signature, just like in any similar centralized service. The only difference is that the private key is stored only with the user. Even if something happens to the infrastructure — no one will know the private key and private data of the user.
• Identify yourself publicly. And here is the main difference — the user does not save his personal data publicly in clear or even encrypted form. He saves a hash of this data. Thus, the only way to know what kind of data is stored publicly is if I know what kind of data it is.

In this case, if Bob or Alice want to make sure that the e-signature in question really belongs to the contractant — it is enough for them to validate each other’s private data in the decentralized repository and then quietly do business with each other. No centralized authority is needed for that. And you can sign anything, anytime, as many times as you want with this signature.

There can be a risk that the private data that each user provides may not be correct. I for serious contracts in such cases need some third party, which could validate that each of the participants provided reliable data. In centralized systems — the service itself must be such an agent, which must make sure that the submitted data is correct.

In a decentralized system, in fact, anyone can be that third party. For example, if Charlie knows Alice personally, she can easily confirm the validity of private data, and at the same time, she is authoritative enough for Bob. Then she could act as such a validator. In a broader sense, of course, virtually any KYC provider or large and respected organization can act as such a validator.

There is another fundamental difference in using a decentralized public infrastructure for digital signatures — it is the level of trust. The more I use the same e-signature, the more people I work with, the more bodies have validated my data — the more trust I have in my account. So, I don’t change and order a new digital signature every time I try to work with new contractors, I just get more and more trust from the new contractors I work with every time. That is, the problem of trust is solved by itself, but I do not spend a lot of time and money on it.

Why side-chain is needed for this infrastructure

Theoretically, it is not so important which public blockchain to take to implement this data storage model. As we wrote before — we do all public infrastructure with Lisk SDK and here we would like to look a little bit under the hood of the solution architecture and data storage structure.

• We decided not to use any of the public blockchain platforms in order not to be able to make the most convenient and specialized data storage structure. On the other hand, to ensure that this blockchain does not contain other “garbage” data.
• Delegated Proof-of-Stake — three problems are solved by this type of consensus at once: energy efficiency, speed of validation of new blocks, ability to implement changes in the product network
• A protocol that has been working for more than a year

And that’s what we got while we were developing our MVP:

• Modules — It’s very cool that when developing a blockchain application, all functionality can be broken down into different modules. This is convenient both in terms of implementing functionality and providing access to data. In fact — each module has access only to a certain section and can’t affect others if the module doesn’t provide that functionality. This approach makes it possible both to safely manage the data model, and to introduce new functionality in new modules.
• Blockchain application modules and transactions code can be written in JS or TS — this is important from the point of view that any developer can actually check the logic of the whole application and make sure the whole infrastructure works. No need to hire additional highly specialized specialists to make sure the logic works exactly as stated, which is very important in public decentralized solutions.
• Excellent documentation and SDK, which not only allows using the basic principles of blockchain, but provides a set of additional libraries — from cryptography to a out-of-the-box client for building a front end.
• Possibility to implement your own off-chain logic with plugins — for example we needed to implement our own storage for transactions (out of the box you can’t find all transactions, which were made by one account) — implementation of such module took us only one week. And at the same time, for those network members who don’t want to give such an API — such a plugin is not necessary.
• On-chain logic in the form of transactions — this is the main thing in our opinion (that’s why we choose Lisk SDK). In case we change smart contract logic (without changing data structure) — it’s enough to implement new logic at transaction level and it will immediately apply to the whole side-chain. If we did the same thing on Ethereum, for example, we would have to implement the logic of those smart contracts for each account and control versioning and integrity.

We’ll be launching our test-net in the near future to show you what we’ve got, so subscribe and stay tuned.