By: Shivhari Shankar, Product Manager, SpringRole
What is verification?
At the simplest level, verification is about validating the information that one entity (user, company, etc.) makes, which is then agreed upon by the other party that that the information pertains to. For example, employee-employer verification relies on the whether or not the employer agrees that a employee is working or has worked for him.
Why advisor verification is necessary
We are seeing a lot of ICOs putting false information on their websites, and since the blockchain space is all about promoting trust and transparency, it seems to our damning that ICOs, particularly, could get away with fake information. Our idea is that making advisory verification a standard process for ICOs to do, would be the first step in trusting the information that we read online. Blockchain, of all industries, should not have to deal with problems of verification and trust – after all, blockchain is made to ensure trust.
One of the ways ICOs try to benefit from fake information is by writing names of people that they claim to be advisors for their company, when in reality they are not. They believe that their brand value will go up, from being associated with big-name advisors – and many get away with it because there’s no way to check! When a potential investor checks an ICO’s website, there is no way for him/her to check whether the claimed information is true or not.
This causes many problems for individuals who are legitimate advisors for other companies – the most important of them being that their name is joined with the fake ICO who claims they are associated with them. If the ICO tanks, or is uncovered to be a fraud, the advisor’s name suffers. Along with that, the companies who take advisory from them also suffer – from being associated. Clearly, this is not leading to an ideal situation.
How the blockchain can help in this case
Blockchain based solutions essentially act as a facilitator between the two parties who are making or verifying a claim. This role of an enabler is played both by the blockchain dApp that lets ICOs list their advisors and showcase them and also by the smart contracts through which we decide the format and the architecture of the solutions, while still keeping the end users in charge of the process. The same technology or framework can then be used to perform all sorts of professional verifications.
The verification system architecture
Here’s how a verification system architecture can be built: User comes in and registers their company on the dApp. The registration of the company requires the user’s (personal) ETH address that is used to identify him as the owner of the company. An ETH address is generated for the company that the user downloads as a keystore file (encrypted with a password). The company owner adds advisors – their name and their email address are needed. The owner also pays a fee for the verification. The company owner then interacts with the blockchain to put his advisory claims up on the blockchain. He has two options: Sign the message that claims his advisors. The dApp writes the transaction to the blockchain and the company owner signs and writes to the blockchain. The advisor gets an email about an advisory requests. He comes to the dApp and either logs in or signs up. Once he accepts the advisory, he also has an option to either sign the transaction or sign and write the transaction to the blockchain. One the transaction is confirmed, anyone can see it as confirmed on the company profile page.
The advantage of this method
The obvious advantage here, is that now, using the blockchain, one can easily identify a verified advisor. This provides investors with the peace of mind that the ICO they are investing in, has legitimate advisors, and is not lying. In the world of fake ICOs and frauds, this is invaluable.
How can the end user be able to do this easily?
Not all company representatives want to learn the technicalities of the blockchain in order to use the system – particularly individuals from a non-tech background. The solution to this would be to enable the user to sign a message on their ETH address, and let the dApp write the transaction on the blockchain.
This way, it becomes easy for the end user to access and utilize technology like the blockchain to their benefit. This is another reason why it’s important for a dApp to play middleman between the users.
But what is ‘signing’?
What the user signs, is a formatted json string that mentions that the company is claiming a certain person as an advisor. This string is signed with their (the company’s) ETH address and is then saved on the blockchain along with the clear text.
This way, anyone can verify whether the string actually was signed by the address that is claimed in the transactions. Any time the status of the advisor verification is updated, a new transaction is written with the string signed by the party that is making the change (it could be the company or the advisor). The previous transaction address is also mentioned, so that it is known that the previous transaction is not to be read, and that the current transaction has the latest up-to-date information. This way one only has to see the latest transaction to see the complete picture, and not traverse the previous transactions.
What follows from the above is that we have a ‘stateless contract’ that by itself does not hold any information and only plays the role of a facilitator of transactions. The contract only writes the information to the blockchain, and helps define the format of the string that resides in the transaction.
What is important to note, is that since the contract doesn’t check for the format of the data in the transaction, a lot of the work for validation and standardization of the format inside the json is on the client side of things.
The advantages of having a stateless contract is the speed at which the transaction can be done, plus that the contracts don’t increase in size of the data they store and so can perform reliably over time.
When the advisor-company relationship changes
What happens when the relationship changes? Editing information in this given paradigm is trivial. All that has to be done, is to have a new transaction with the updated details.
Since the last block is held to be true, editing of information is simple. An advisory post can be deleted, for example, by just setting a flag that marks that the previous transaction is invalidated.
The only missing piece
One aspect of the solution mentioned above that is out of the scope of the blockchain ecosystem is that the blockchain, by itself, does not have any identity management system. This means that while a particular message can be checked that it was signed by the address that it is claimed to be, we cannot check whether that address is tied to the identity that is claims to be.
Of course, this can be done outside the blockchain and that is what companies like SpringRole also do.
There is no doubt that a verification system is required in today’s online world. With the volume of information on the Internet increasing exponentially, the amount of fake information is also increasing, and it is becoming increasingly difficult to discern the real from the fake.
The blockchain has a very high potential to disrupt this, and completely turn this problem on its head. At the same time, just the blockchain isn’t enough – there need to be efficient and effective platforms, i.e. dApps that play as middlemen in order to bring this technology to the masses.