Linking Ethereum accounts with traditional communication channels

I’ve always been passionate about blockchain tech, but now that I started using it in my everyday job, the enthusiasm has reached an all-time high (no pun intended).

I’m using Ethereum and smart contracts to develop a super top-secret project (that might or might not get explained in a series of subsequent posts), and one of the challenges I have to face is right at the start: the onboarding process.

The logic behind it is simple in theory… I only once need to verify if a given Ethereum account is owned by a person which is part of my company, and if it is, I need to issue some special tokens to that account (the issuing has to be done only once, at the first successful verification).

It doesn’t sound that hard, right? Except… how can I verify if a given account is part of the organization in a decentralized manner, or at least by having the highest grade of transparency and security? Turns out it is pretty hard. After some thinking and research, I think I found a decent solution, although not completely trustless and decentralized.

A bit of context

Before starting to explain the actual thought process, I need to point out something. Before the top-secret project goes live, Mondora is going to buy a hardware wallet for each of my colleagues, to enable them to get full access to the dapp’s features. So everyone in the company is 100% guaranteed to have their own Ethereum account before launching the project.

The thought process

Right off the bat, two pretty straight-forward solutions to the problems came to my mind:

• Since, as I said before, the company gives out the hardware wallets, I could ask each of the receiving colleagues to initialize theirs and immediately send me the account they intend to use to start tinkering with the dapp. I could then manually issue the tokens to each of the accounts, mark them as enrolled in the top-secret project and call it a day.
• Another option would be to get the user to prove they own an email address under the company’s jurisdiction. By proving this, you can inherently prove you’re part of that organization (unless the organization issues email addresses to external entities, which is not my case). That could, for example, be done by asking the user to authenticate one-shot to a special dapp using OAuth2 with the company’s email address. The dapp could then issue the tokens to the Ethereum account used to access itself in the first place.

Both of the solutions mentioned here are probably going to work, but we can do better. Even after leaving out the centralization factor, the first one is just not sustainable in the long run, since every new colleague would require a manual onboarding procedure to be done, while the second one is centralized and not that secure (a malicious actor could take control of the user’s e-mail address and immediately claim the tokens for themselves).

It is pretty clear by now that we need a different approach, right?

Not everything stated above is necessarily invalid though. We can extract a very good principle from the second solution listed above: in theory, the belonging to an organization of a particular Ethereum account can be determined by demonstrating that the account is owned by a person which also has ownership over an email address which was issued by the organization itself.

That’s some good progress!

Now, what if we took a step back? We might be onto something very interesting… what if we generalized the principle above and we tried to develop a solution that can associate in a verifiable manner an email address (or really, any digital communication channel’s address) with an Ethereum account, on-chain? Some interesting side use cases could be found, while at the same time maintaining the ability to fulfill the original requirement.

Blockchain to the rescue

To greatly increase decentralization, trustlessness, and transparency, why don’t we imagine what a process like the one described above would look like on-chain?

We need to prove that a given Ethereum account and a given email address are owned by the same entity: how could we do that?

Well for the account that’s pretty simple. Since you need the private key linked to the account to interact with the blockchain using it and since the private key ownership and the account ownership are formally the same thing, every time you are interacting with the blockchain using that account you are inherently proving that you own it.

As far as the email is concerned, things are more complex.

Generalizing, every time a party is claiming to have ownership over a given communication channel and you want to verify it, the most straightforward way to do so is by generating a secret, sending it through the communication channel, and then asking the party to tell you the secret back. If the party is effectively able to tell you the secret back correctly, they must be owning the communication channel (since they were able to read from it).

That’s cool and all, but how can we combine the two things and have proof of ownership for both the account and the e-mail? I thought about it for a while, and I came up with a pretty satisfying solution, summarized in the sequence diagram below.

It might seem complex, but it’s rather simple to explain, and we’re going to go through it step by step right now. But first, let’s explain what are the various entities taking part in the process.

The entities

• User: the user is the entity that wants to prove they’re the owner of both a given Ethereum account and a digital communication channel.
• Verifying dapp: by verifying dapp we mean any form of frontend to which the user caters to get verified. It could be a web app, a mobile app or even a CLI interface as far as I’m concerned. The dapp communicates directly with the verifying contract by forcing the user to plug in a hardware wallet before doing anything else. The user can then interact with the dapp using the Ethereum account which they want to be linked with the given communication channel.
• Verifying contract: a verifying contract is a smart contract running on the Ethereum blockchain which can formally verify the ownership of a given communication channel by a given Ethereum account with the help of a…
• Verifying oracle: a part of the process needs to be performed off-chain for it to be effective. The oracle is indirectly invoked by the smart contract as needed by emitting some special events on-chain and helps in securing the overall process.

The interactions and the process

After having explained what the various entities taking part in the process are, let’s get down to business and explain how they come together shaping the overall functionality.

First things first, the user which wants to prove they’re owner of both a given communication channel and Ethereum account must get to the verifying dapp in some way.

Right from the get-go, the app would ask him to plug in their hardware wallet and select the address they want to use while going through the verification process.

Once selected, the app will then finally ask him to input the address he wants to get verified and linked to the Ethereum account. The address could theoretically be an e-mail, a phone number, or a Telegram chat id (basically any valid address for a digital communication channel).

At this point, the address itself is sent to the verifying smart contract, which saves it in its internal state (i.e. the blockchain itself) initiating a new “verification flow” (a fancy term to say that the contract remembers it is verifying the ownership of the communication channel x by the account y over time), and then contacts the off-chain oracle sending it the address of the communication channel which wants to be verified through an on-chain event emission.

At this point, the oracle steals the show. It is his responsibility to generate a secret, communicating it back to the verifying contract in hashed form, and then sending it in clear-text to the user claiming ownership over the communication channel, through the communication channel itself.

It is very important to hash the communication code before sending it back to the verifying contract since every data sent or saved to the blockchain is public. If the secret wasn’t hashed, a malicious actor could easily read it, making the whole system completely pointless.

Another very important thing is registering the allowed oracles that can intercept the contract requests and act upon them. Otherwise, since blockchain events are public, anyone could develop their oracle implementation (helped by the fact that the oracle’s job is very simple), intercept the events, generate the secret code, communicating it to the smart contract and then simply steal it).

At this point, the ball goes back to the user. Once they receive the secret code through the communication channel, they must input it in the verification dapp, which will then proceed to communicate it to the verifying contract in clear form.

The verifying contract now just has to check if the hash of the given clear text code is the same compared to the hashed value previously communicated by the oracle (for this to work, both the oracle and the contract need to use same hashing algorithm), and if it is, we have successfully proved that the communication channel belongs to the same entity that is currently communicating with the verifying contract.

We can then go on and save the association on-chain, asserting that a given communication channel’s address belongs to a given Ehtereum account.

It seems like we’ve reached our initial goal too since with the method described above we can issue some tokens to those addresses which can prove ownership of an e-mail address over which the company has jurisdiction (please note that some minor tweaks are needed to fully reach the initial goal, since we need to avoid a user associating the same e-mail address to multiple Ethereum accounts, effectively having access to an infinite amount of tokens).

Some downsides of this approach and some counterarguments

Yeah, that’s pretty cool and all, but what about the downsides? Let’s have a look at them along with some possible counterarguments.

The solution is not fully decentralized

Well yes… the use of an oracle inherently makes this solution partially centralized. If we divide the process into two subtasks, the secret creation and communication to the user, and the secret communication from the user to the smart contract and its subsequent verification, we can see how the first one is centralized, since it’s the oracle’s responsibility to make it work. I really couldn’t find a more intelligent way to make the process fully decentralized though, since the secret cannot be generated on-chain due to the publicity of all the data persisted in it.

The solution is not trustless

That’s an oracle side effect too. Since the code generation is obscure to the end-user, some degree of trust would inevitably have to be put in the process by them. It’s not that bad if you think about it though. The oracle’s logic is just really simple, plus, the implementation itself could be FOSS, limiting the trust factor by a hypothetical user.

The solution requires paying for verification

Yes. Every transaction which changes a smart contract’s state is bound to cost some real-world money. That’s the price to pay to have a completely transparent and decentralized code verification flow though, it’s up to you to decide to use it or not. Also, the process would have to be done just once per communication channel.

The communication channels addresses would be public, and the association with your address too

To me, this is the real weakness of the proposed solution, at the same time opening a really interesting use case though.

By saving the account/address association on-chain, the data would automatically be made public to the world. Anyone knowing your public Ethereum address would be able to potentially read some of your contact information, whether it would be an e-mail address, a phone number or anything else saved there.

The good news is that it could be made hard (but never impossible) by making the association private in the contract and implementing an allowance mechanism similar to the one used by ERC20 tokens.

ERC20 uses this mechanism to let a user voluntarily allow third-party Ethereum accounts to spend a specific amount of their tokens as if they were owned by the third party accounts themselves (a sort of spending power delegation).

We could use this kind of mechanism and apply it to contact information too.

The data would be made private at contract-level, and every user could give read permission on their chunk of data only to a specific, trusted subset of Ethereum accounts.

This would make the solution similar to a public ledger containing associations from Ethereum accounts to digital communication channels owned by the same end-user to which dapps could get read permissions by users themselves.

That would potentially let any dapp notify a user of a specific on-chain event using a traditional communication channel, and due to the blockchain’s public nature, users would have to go through the verification process only once to have a verified communication address valid for all the possible dapps or accounts on the Ethereum crypto space which want to communicate to the user.

That’s rather interesting… even though an Ethereum account cannot directly send messages through conventional communication channels. The notification itself would have to be sent by an off-chain oracle acting like an Ethereum account, putting the decentralization and trustlessness at risk again (not a big risk, but a risk nonetheless).

Use cases

Let’s imagine a dex with on-chain limit orders capabilities.

A user placing a limit order could give the dex platform access to its verified e-mail address associated on-chain (in particular to that part of the platform that would be used to notify events to the users), and the dex would then be able to use it to notify the user about the order’s fulfillment, greatly improving the overall UX, and making it similar to the one currently present in centralized exchanges.

Then imagine the implications of this flow applied to MakerDAO, for example.

Any user would be potentially able to be notified about a vault approaching the liquidation limit due to a sudden collateral price drop, permitting them to feed some more collateral to the vault itself and avoiding liquidation. This would save money.

The conclusion

Well, summarizing, we started with a requirement (prove that a given address is part of a given organization), and we then proceeded to design a general model through which Ethereum accounts can be mapped to digital communication channel addresses on-chain, making a public permissioned registry readable from dapps and other users, that would then make the reader able to notify the contact’s owner of on-chain events using a traditional communication channel, improving dapps UX.

That caught my interest, and as a result, I immediately started working on a proof of concept. Stay tuned for new developments, which I shall possibly share in another post!