Using Escrow Smart Contracts to Secure ETH Transactions with Eth2
Eth2 offers a solution that allows users to send Ether to anyone through a phone number. After clicking a link from a confirmation text message, the receiver will be automatically guided through a series of simple steps to collect transferred funds.
To learn more about our solution, take a look at the “Eth2— Send and Receive Ether Using Just your Phone Number” article.
Eth2 App currently supports Ethereum Main and Ropsten Test networks. Here is how our technology works:
- User-sender types in receiver’s phone number and amount of ether to send. Sender-device deposits Ether to Escrow Smart Contract, generates transit private-public key pair and assigns it to the deposit on the Escrow. (Note: This pair is “operational” and going to be used for the current transaction only. It has nothing to do with a private key of the receiver. It will be used later to validate receivers credentials.)
- Sender-device encrypts the transit private key with a random secret code and sends the encrypted transit private key with the receiver’s phone number (in a hashed form) to a verification server.
- User-sender passes the secret code to the user-receiver over voice, sms, e-mail or any other methods.
- User-receiver types in his phone number and the secret code on the App web page. Phone verification request is sent to the Eth2 server. (Note: At no point in time verification server has access to the transit private key.)
- Server sends a verification code via SMS to the phone number entered.
- User-receiver gets the code from SMS message and types it in. If the code is correct, server returns the encrypted transit private key to the receiver-device.
- Receiver-device decrypts the transit private key with the secret code provided by the user-sender and acquires the transit private key. Receiver-user signs an address of his choosing with the transit private key. Receiver-device sends the signed address to the verification server.
- Verification server tries to withdraw Ether from Escrow Smart Contract to the signed address using the signature to confirm its identity. If the signature is correct, the transaction is executed.
Decentralization VS UX trade-off
Even though we are big fans of decentralization, our solution is not fully decentralized. We have to rely on a centralized entity to perform SMS-authentication. However, we are exploring ways to go around that limitation.
Despite the fact that centralized server is used for phone verification and keystore transferring, never Eth2 server has control over Ether locked in the Escrow Smart Contract. Which means that in the worst case scenario — if our server is compromised, the transaction will simply fail and Ether will remain on the Escrow. To receive Ether back, sender will be able to cancel the transfer with a call to the Escrow Smart Contract.
If the share link is compromised, attacker will not be able to complete withdrawal process without the Transit Keystore file from the Verification Server (which is done through a phone number verification step).
Phone numbers and privacy
We understand the importance of securing phone number data and the Ethereum address associated with it. That’s why, our priority is to make Ether transfers as private as possible. Having that in mind, here are a couple of rules we follow:
- We don’t store phone numbers. Instead we hash them with generated on the client salt. That way, in an event of our servers being hacked, the attacker won’t be able to link phone numbers to ETH addresses.
- We don’t store any phone data on blockchain, not even metadata (hashes, etc). Luckily, we don’t have to — phone verification is done off-chain.
Our technology stack
- React app served from GitHub Pages
- The Escrow Smart Contract handling Ether transfers — https://etherscan.io/address/eth2phone.eth
- NodeJS server providing phone verification and Transit Keystore transferring