ICOs getting their advisors verified on the blockchain was an important first feature for us to do — the challenges and uncertainties of building on the blockchain and the absence of relevant best practices in building a feature like this made it a great learning tool for both the product and the engineering teams.
Building on the blockchain entails a lot of choices that you need to evaluate and assess — the learning that we had gotten from this was something that we thought would be worth sharing to the community in general and might help answer questions for anyone building similar things.
Why Advisor verification?
It was important for us to build a feature that we thought would be for the crypto community. Since SpringRole is centered around our online professional identity it made sense for us to have a verification feature that relies on a person’s professional identity — on the other hand, we were also seeing a lot of ICOs putting false information on their website and since the blockchain space is all about promoting trust and transparency it seems to our damning that ICOs could get away with fake information. Our idea was that making this a standard process for ICOs to do would be the first step in trusting the information that we read online.
Equally importantly, we were figuring out how to do verifications on the blockchain. Once done, we could use the same for a wide variety of use cases, whether that be for ICO advisory or for a company to check a potential hire.
What is verification?
As the simplest level verification is about validating information that one entity (user, company etc.) makes and is then agreed upon by the other party that that 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. Even third party verification services essentially do the same thing.
Keeping this as the model in mind, we wanted SpringRole to essentially act as a facilitator between the two parties who are making or verifying a claim. This role of being an enabler is done both through the SpringRole beta that lets ICOs list their advisors and showcase them but also through the smart contracts where we decide the format and the architecture of the solution while still keeping the end users in charge of the process.
The verification system architecture.
Here’s how we built our verification system architecture:
1. User comes in and registers their company on SpringRole.
2. The registration of the company requires the user’s (personal) ETH address that is used to identify him as the owner of the company.
3. We generate a ETH address for the company that the user downloads as a keystore file (encrypted with a password)
4. The company owner adds advisors — their name and their email address are needed. The owner also pays a fee for the verification.
5. The company owner then interacts with the blockchain to put his advisory claims up on the blockchain. He has two options:
a. Sign the message that claims his advisors. SpringRole writes the transaction to the blockchain.
b. The company owner signs and writes to the blockchain.
6. The advisor gets an email about an advisory requests. He comes to SpringRole and either logs in or signs up.
7. Once he accepts the advisory, he also has an option to either sign the transaction or sign and write the transaction to the blockchain.
8. One the transaction is confirmed, you can see it as confirmed on the company profile page.
We used the ethereum PoA blockchain. While we would have loved to use the public ethereum blockchain, it didn’t make sense, neither from a technical standpoint nor from a usability standpoint. The transaction speed is slow and gas wars can often clog the network to a standstill. Moreover, asking users to use ETH to do transactions is a known point where user engagement will drop off.
PoA on the other hands gives us a lot more options, there is no concept of gas on the PoA chain and transactions can happen almost immediately. Of course, the downside of this is that we have to maintain the blockchain and handle things like security by ourselves.
Signing messages via ETH addresses.
Signing a message through your ETH address is an essential part of how the verification system works. Check out this link if you don’t know how signing messages works on Ethereum.
We took a stand on signing against doing transactions on the blockchain as signing has a much better user experience and is just as secure. (Power) users who might not want SpringRole to write transactions to the blockchain are given an option to write the transactions by themselves. If they choose not to, we write the transaction to the blockchain. This is also where signing becomes important — even if we write the transactions, we cannot forge the signatures and the user can be assured of trustworthiness of the system.
What gets signed and written to the blockchain
What the company signs is basically a formatted json string that mentions that the company is claiming a certain person as an advisor. This string is signed with their ETH address and then saved on the blockchain along with the clear text. This way anyone can verifiy whether the string actually was signed by the address that is claimed in the transactions. Any time we update the status of the advisor verification, a new transaction is written with the string signed by the party that is making the change (could be the company or the advisor). We also mention the previous transaction address so that we know 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 know the complete picture and not traverse the previous transactions.
State less contract
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 in defining the format of the string that is there in the transaction. What is important to note is that since the contract doesn’t check for the format of the data of 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 we can do the transaction, plus the contracts don’t increase in size of the data they store and so can perform reliably over time.
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. We can also delete an advisory post by just setting a flag that marks that the previous transaction is invalidated.
Identity and what it means
One part of the solution that is out of the scope of the blockchain ecosystem is that the blockchain by itself doesn’t have any identity management system. This means that while we can check that a particular message 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 SpringRole does. We plan to tie it up to the identity of the person by making sure that the email address is actually of the person that it claims to be. We are also planning to do KYCs and write that to the blockchain so that we can say with certainty that the person is a verified profile.
You can checkout the product here>> https://beta.springrole.com/company-advisory-verification