In previous posts, we have mentioned how Ejara is set on a mission to develop smart contracts that could potentially make the use and adoption of cryptocurrencies much easier for the average user.
Indeed we have developed and implemented some solutions
(https://medium.com/ejara/storing-retrieving-secrets-on-a-public-smart-contract-925f02178d7 and https://medium.com/ejara/tezos-secrets-store-53039256eb6a) that have the potential to make it easier to recover private keys or mnemonics of user accounts.
We use a username, password approach to encrypt and store secrets on the blockchain such that only the username and password is required to retrieve the data. This mechanism is described in our previous posts (https://medium.com/ejara/tezos-secrets-store-53039256eb6a) where we even have a working demo. In future updates of our Ejara App, we plan to use this new smart contract to backup user data and safely store on the blockchain.
The interesting thing to note is that this solution does not just work for Tezos. With some appropriate modifications to the initial smart contract, we were able to come up with a solution that makes allows us not only to store Tezos private keys or mnemonics but also that of other cryptocurrencies like Bitcoin and Ethereum.
Smart Contract to secure all different blockchain wallets private keys into a single hash on Tezos.
With our previous smart contract, we could only store one type of crypto keys on it. In our case, we stored a list of encrypted private keys or mnemonics of Tezos accounts.
In this version of the smart contract, we have modified it to be able to store private keys of different blockchain wallets on t smart contract.
In this gist, we see that the smart contract as written in SmartPy has a storage structure that allows for storing wallet keys of various cryptos. In effect, each crypto can have its own space where for storing all keys related to it for a particular user. We use the coin_type key value as depicted in https://github.com/satoshilabs/slips/blob/master/slip-0044.md to represent each crypto space. You can see for instance in the tests that we use coin types 1 (Bitcoin), 1729 (Tezos), and 60 (Ethereum).
Keep in mind that this contract is intended to be originated for a single user. In our own implementation of this approach, we store the contract address related to each user in our database. Another design would be to have a single contract that accommodates various users.
However, we use this approach for concerns of potentially bloating one smart contract. Also, storing all user secrets in one smart contract could make things easier for attackers to run brute force attacks. Although it is still possible to query the blockchain for all contracts of a specific code or type, that makes things extra uncomfortable. That being said, the brute force attack is a vulnerability of all currently dominating cryptography. The whole internet and blockchain is a potential victim and not just our smart contract. The fact that it doesn’t succeed is what we all depend on.
Next Steps
One thing we would like to expand on is the mechanism used to control write access to the smart contract without exposing the username and password.
With this approach, we could have an asset smart contract that is just username and password-based. Imagine being able to access your tokens with just a username and password. This is interesting, however, we would need to further test how fool proof our username, password mechanism is (You can read more about our approach here https://medium.com/ejara/storing-retrieving-secrets-on-a-public-smart-contract-925f02178d7).
Our next steps would be to integrate our smart contract backup solution into our product. Also, we would focus on smart contracts that make it easy to move between Tezos and Bitcoin. The community has already adopted to approaches like decentralized atomic contracts using hash time lock technologies and Tezos-Bitcoin tokens. These are all very inspiring and we are learning from them. We will develop our own versions of such approaches, and we will definitely look further into making things much easier for the average user as has always been our goal.
