During the time of the ancient Greeks, it was a common occurrence for traders to sacrifice to the god of trade, Hermes because they believed it would increase the likelihood their good would make it to buyers. In a sense, they were putting their trust in Hermes. While traders no longer sacrifice to Hermes, distributed ledger technology has provided a medium in which two mutually untrusting parties can engage in non-repudiable transactions. These decentralized applications can achieve stronger security by trusting in the majority of users instead of a single centralized party. Unfortunately, this exposes these systems to disasters caused by unexpected situations. Unlike centralized systems that can rely on an administrator to handle unexpected events, decentralized applications can do little to stem the bleeding. Due to Hermes also being the god of trickery, we only thought it would be right to name our account recovery protocol after him.
For our research, we have designed and implemented an asset recovery protocol for the Ethereum blockchain network. To start our protocol the owner of a lost account must create a new account and an asset recovery proposal. After paying for the proposal, the new account will indicate accounts that they remember traded with their lost account. Our system then goes through and makes sure that each of these accounts is, in fact, trade partners with the lost account. After checking these trade partners, our system randomly selects several other trade partners from public records. For both the indicated trade partners and the randomly selected trade partners the new account must provide transaction data from at least one transaction they had with them. These trade partners will then get to weigh in on the genuineness of the provided transaction data by comparing it to their recollection of the transaction. After a majority of voters have responded and a designated amount of time has passed, the votes will then be tallied, and if the vote was successful the balance of the lost account will be transferred to the new account. No matter the outcome of the vote, the original price of the asset recover procedure will be broken up and given to the voters as a reward.
To encourage users to vote, we reward voters for participating and for voting correctly (a.k.a. voting the same as the majority). On top of these two factors, voters will also be rewarded based on how long they took to vote compared to the average voter. In the end, we are looking to promote genuine votes that are placed promptly.
When designing our new system, we focused mainly on defending against different attack vectors that could abuse the weaknesses of other asset recovery systems. Most notably we worked to limit our protocol's vulnerability to bribery and spam. To clamp down on bribery, our system selects extra voters at random to offset the number of indicated voters. Without enough randomly selected voters, a majority of indicated voters could be bribed by an attacker. To limit spam proposals we made the asset recovery processes more tedious to complete for attackers than for genuine owners. By fact-checking all public data provided by the new account we can make the process tedious enough to discourage spam attempts while not making it too tedious that it is agitating to complete for a genuine owner.
For our research, we developed and tested on the Ethereum network. Due to Ethereum's smart contracts, we were able to make our new system much easier to use for our users. Given smart contracts' greater scalability, privacy, and programmability, Ethereum was the best network for our research and future iterations of this research. For our implementation, we used a hierarchy of smart contracts and libraries. At the top of the hierarchy, 3 manager smart contracts handle the overall network: UserManager.sol, TransactionManager.sol, and ProposalManager.sol. UserManager.sol manages the users on the network while TransactionManager.sol manages the making and recording of transactions and ProposalManager.sol manages all active asset recovery proposals. To create and manage asset recovery proposals these 3 manager contracts call functions from the ProposalCreator.sol and Proposal.sol files. ProposalCreator.sol is used to create and add voters to the proposals while Proposal.sol represents the actual proposal. On the lowest level of the hierarchy, there are 2 smart contracts (Person.sol, Transaction.sol) and 2 libraries (VotingToken.sol, TransactionDataSet.sol). Person.sol and Transaction.sol are used to represent users and transactions on the network respectively. VotingToken.sol is used to keep track of votes while TransactionDataSet.sol is used to keep track of provided public and private transaction data.
To test our protocol you must first install Truffle and Ganache. After uploading our project into Ganache you can test our protocol by using the $ truffle test command from a command line. This will run through three test files that simulate the successful usage of our protocol and one test file that simulates the misusage of our protocol.