In today’s market place, there are many different projects. Each project forms its own trusted ecosystem. Inside each ecosystem, all transactions are collaboratively validated by all its participants, the majority of its participants, or a subset of selected delegates. Most of the projects also provides high availability through built-in redundancies. Everything works well as long as the logics stays inside one particular project, or as we called it, a crypto island.
As we know, a closed system normally does not possess any significant value. In the real-world applications, logics inside one project will eventually want to talk to the outside world one way or another. Propagation the desired properties of the project to the outside world is a challenging problem that requires a lot of thoughts and many discussions. In this article, I would like to discuss one particular scenario where one project wants to talk to another project. This article provides one solution of implementing a secure and highly available bridge between two projects. Solutions for ad hoc network between different projects can easily be extended from the provided solution.
To harden the problem, let’s formulate a more concreate example. Suppose we have already built a backed crypto exchange. All order book and trade updates are validated by the selected delegates. A hacker who successfully broke into one or several delegates cannot manipulate any transaction since the majority of the delegates will invalidate it. Collusion are also unlikely since it requires the participation of the majority of the delegates to go rogue. As a result, the itself is considered secure and transparent, thus can be trusted. This is all good as long as the crypto exchange stands alone.
Let’s say the crypto exchange supports trades between and other . We need to support deposits and withdraws of . The deposits and withdraws can be seen as two-direction traffic between the and the crypto exchange main chain. Let’s discuss how can we build such a bridge with the properties of security and high availability.
User workflow
When a user of the crypto exchange opens an account, he/she is allocated a deposit address. The user can make a deposit to this address through any or third-party tool, and the balance should be reflected in his/her account. The user can also withdraw from the crypto exchange by providing a valid address. On the crypto exchange side, the following three operations need to be supported:
- Allocate a new bitcoin address.
- Increase user account balance when a deposit is made.
- Adjust user account balance and send bitcoin to user provided address when a withdraw request is made.
A sample service
A sample service can be built with a full node, a client. Now let’s implement the operations required:
- Allocate a new bitcoin address
Implement with getnewaddress from Original bitcoin client API calls list
- Increase user account balance when a deposit is made to the bitcoin address
Implement with getblock from Original bitcoin client API calls list and scan transactions sending bitcoin to the bitcoin address
- Adjust user account balance and send bitcoin to user provided address
Implement with sendtoaddress from Original bitcoin client API calls list and send bitcoin to user provided address
What can go WRONG!
Even without a hacker present, there are enough problems with this sample service:
- The service host can go down.
- The bitcoin full node can lag behind.
- Private key can be leaked or lost.
- The owner of the private key can take the bitcoin and run.
A hacker can also launch several other attacks:
- A hacker can redirect the traffic of
getnewaddressto a fake agent. - A hacker can act as man in the middle and replace bitcoin address with his/her address.
- A hacker can return fake a deposit and have bitcoin balance without making any deposit.
The above scenarios either degrade the availability of the service, or result in complete security breach.
A Secure and Highly Available Service
Now, let’s discuss how can we implement a secure and highly available service that solve all the problems presented above. The backbone of the proposal is to distribute the ownership of address and employ the same set of delegates to validate cross operations. The distribute of the ownership of address is fairly straightforward, we can directly adopt the multi-signature feature supported by . The cross operation validations are trickier and they are discussed below.
- Allocate a new bitcoin address
1. Randomly select one active delegate
2. The selected delegate creates an multi-signature address with the public keys of all delegates
3. The crypto exchange receives the multi-signature address
4. The crypto exchange asks each delegate to do the following:
a. Query bitcoin blockchain to get the information of the address
b. Verify the public keys of the address matches the delegates
5. If M out of N (N/2 < M < N) delegates succeed in step 4, add address to user’s account. Otherwise, go back to step 1
- Increase user account balance when a deposit is made to the bitcoin address
1. Each delegate maintains its own bitcoin full node and scan transactions in each block
2. If a deposit to the bitcoin address is found, send the information back to the crypto exchange
3. If M out of N (N/2 < M < N) notifications are collected for address with the same information, increase user account balance
- Adjust user account balance and send bitcoin to user provided address
1. Randomly select one active delegate
2. The selected participant creates a proposal to send bitcoin to the user provided address
3. The crypto exchange receives the proposal
4. The crypto exchange asks each delegate to do the following:
a. Validate the user provided address is valid
b. Validate the user account has sufficient balance
c. Validate the proposal matches the record on the blockchain
d. Sign the proposal
5. If M out of N (N/2 < M < N) participants signed the proposal in step 4, adjust user account balance. The selected delegate sends out the signed multi-signature transaction. Otherwise, go back to step 1
6. The crypto exchange asks delegate to monitor the transaction
7. If M out of N (N/2 < M < N) notifications are collected for complete of the transaction, mark the complete of the withdraw
What can go WRONG!
Let’s reinstate the failing scenarios for the simple service and see what happens:
- The service host can go down — not a problem, as long as more than M services are still up and running.
- The bitcoin full node can lag behind — not a problem, as long as more than M services are still up and running.
- Private key can be leaked or lost — not a problem, as long as M private keys are not leaked or lost.
- The owner of the private key can take the bitcoin and run — not a problem, as long as less than M delegates go rogue.
What about hackers:
- A hacker can redirect the traffic of getnewaddress to a fake agent — not a problem, as long as the traffic is redirected to less than M fake agents.
- A hacker can act as man in the middle and replace bitcoin address with his/her address — not a problem, as long as less than M man in the middle attacks succeeded.
- A hacker can return fake a deposit and have bitcoin balance without making any deposit — not a problem, as long as less than M delegates are hacked.
Hooray! That is the secure and highly available service we promised to build. With it acting as a crypto bridge between the and the crypto exchange main chain, the composite system is the secure, highly available, and can be trusted.
Published at Wed, 20 Feb 2019 22:03:21 +0000
