P2P disputes on the blockchain


    The Ethereum network, widely known in a narrow circle of blockchain developers, has already established itself as a convenient and stable platform for developing smart contracts. We try to make smart contracts accessible to untrained users by offering simple but practically useful contracts. We recently developed a smart contract dispute Bet Me. At the heart of the contract is the bet (dispute) of two opponents. They reinforce self-righteousness with a monetary rate. The loser loses money, and the winner takes it all. In more detail about it I will tell in this article.


    Why is there a blockchain?


    For a start, the question that the authors of articles about the blockchain rarely ask is: is a blockchain needed in this situation? Which tasks are difficult to solve with the help of a verbal agreement or a legal contract, but simply with the help of the blockchain?


    If two people argue verbally, this often results in a new trial. “I didn’t mean it”, “External circumstances influenced the result, otherwise I would be right”, “Yes, I didn’t seriously argue with you, but you thought it out for yourself” and other possible excuses make oral dispute with well-known people when fairly low rates. With serious bets and a relatively distant acquaintance, it is more promising to conclude a written agreement and set out in detail the essence of the dispute, the rates, decision criteria and any other conditions that the parties consider important.


    This approach has several disadvantages.


    • Most often it is necessary to involve a lawyer, or even two, one from each side, otherwise you can forget an important point, and this will lead to financial losses.
    • Often, only the obligations of the parties are prescribed in the contract, and responsibility for the violation of these obligations is not. As a result, it is too easy for one side not to pay, and the other is extremely difficult and expensive to get your money through the courts.
    • And it may be that both sides insist on being right, and even going to court does not guarantee that the winner will get the money.
    • It may also be that the losing side simply does not have money, and even a court decision will not force it to pay its debts, despite all the obligations.

    The blockchain (and the Ethereum network in particular) allows you to work with money (we will call broadcast money; this is not entirely correct, but it is convenient and sufficiently reflects the true state of things, since broadcast is fairly easy to exchange for fiat money, and vice versa). At the same time, in Ethereum, you can reduce the agreement to a set of specific rules, do not just follow them. So, our smart contract accepts money from each side and blocks them until specific events occur. A set of defined policy rules will allow the winner to withdraw money. This is exactly what you need.


    Implementation


    A set of rules governing a dispute can be implemented in a variety of ways. Below we will talk about what we have done for users of the Smartz platform.


    The dispute involved two parties. The one who creates a copy of the contract in the Ethereum network is called the owner of the contract (Owner), and his opponent - the opponent (Opponent). The contract owner specifies a textual statement that he considers true. The opponent is betting that the statement is false. The decision on the outcome of the dispute is taken by an independent arbitrator (Arbiter), whose candidacy is claimed by both the owner and the opponent. The arbitrator receives a commission as a percentage of the amount of the dispute.


    The work of the contract is divided into several successive stages.


    1. Conversation. The owner and opponent, even before creating a contract, can negotiate in any convenient way. Together, deciding who will be the arbiter, they send an invitation to the candidate to judge their dispute. Upon receiving the invitation, the arbitrator will see all the conditions and the corresponding State. More on this below, but for now it is important to understand that the future arbitrator must transfer this number to the contract in order to show the conditions under which he is ready to judge the disputants. If the owner has established a non-zero amount of the pledge (ArbiterPenaltyAmount), agreeing to the conditions, the arbitrator must transfer the specified amount of the broadcast to the contract, after which it is blocked until the arbitrator judges the disputants or the deadline for resolving the dispute. In the latter case, the arbitrator loses the opportunity to withdraw the pledge, and this amount is distributed equally between the parties to the dispute.
    2. Initialization . The contract owner creates a copy of the contract and adjusts its parameters: the subject of the dispute; the date by which the arbitrator must make a decision (Deadline); the percentage of the arbitrator's commission (fractional number ≥ 0 and <100); the amount of bail (may be zero), which the arbitrator must make as a guarantee that he takes to judge the dispute in the existing wording by the right time. The owner also sets the Ethereum address of the arbitrator he trusts. Only the owner of this address will be able to become an arbitrator later.
    3. Bid owner . After setting the contract owner bets. To do this, he sends any amount of air in the contract. This amount is the rate, it is blocked at the address of the contract.
    4. Consent of the arbitrator . The owner's rate fixes the terms of the dispute. Now the arbitrator sees the full terms of the transaction: the wording of the dispute, the time before which a decision needs to be made, and most importantly, can understand how much broadcast it will receive as a reward. If the arbitrator is satisfied with everything, he confirms his participation and at the same time transfers the security deposit.
    5. Search for an opponent . After the consent of the arbitrator begins the search for an opponent. The owner pre-sets the address of the opponent, if he is ready to argue only with someone specific, or leaves the address empty, and then the opponent can be the owner of any address on the network (except the arbitrator and the owner). The opponent confirms participation in the dispute by calling a separate method of the contract to which he transmits the current version number of the data and the broadcast - as much as the owner has set. From this point on, betting is considered to be concluded. Now the contract is waiting for either the decision of the arbitrator or the deadline date.
    6. The outcome of the dispute . An arbitrator can judge a dispute in three ways.
      - Recognize the statement true. In this case, the owner of the contract can withdraw the entire amount of the broadcast, except for the commission of the arbitrator and the pledge amount (if it was): the arbitrator withdraws this money, and the opponent does not get anything.
      - To recognize a statement as false. In this case, the arbitrator may withdraw the broadcast in the amount of the commission due to him and the amount of bail. The opponent takes the rest, and the owner does not get anything.
      - Recognize the dispute as intractable. For example, the owner created a dispute with the statement “The football match between teams A and B, scheduled for the nearest Sunday, will end with a score of 2: 1 in favor of A.” If the match is canceled, the arbitrator will not resolve the dispute, but he should be able to pick up his pledge, because the problem arose not through his fault. In this case, each of the parties may request a transfer of the air in the amount of its own rate from the contract address to its wallet.
    7. Withdrawal . When the arbitrator made the decision or Deadline date came, each of the parties may request the withdrawal of the broadcast. How much air to output, calculate the contract itself, focusing on the results of the dispute.
    8. The destruction of the contract . The owner can send a self-destruct command to the contract. This can be done either before the conclusion of the transaction (if the arbitrator was not found), or after its completion (if all parties withdrew the funds due to them). Such an opportunity would be useful if, in a magical way, more air was sent to the contract address than planned. The probability of such an event is very low, but still in Ethereum it is impossible to completely block the transfer of air to the address of an arbitrary contract, and throwing frozen money is stupid.

    Now a little about why the State Version Number is needed. This is the number that increases with each change in significant terms of a dispute, such as the wording of a dispute, the size of commissions or the arbitrator’s penalties. When someone agrees to the terms of the dispute, he 1) sees the current state of the data; 2) sends a call to the contract method that registers acceptance of the terms. If between these two events one of the parties (most likely, the owner) changes the contract parameter, it will be agreed with the other version of the data. For example, the candidate for arbitrators enters the contract interface on smartz.io and sees that he is offered to judge the dispute over 10 Ether (today it is about $ 3,000) for a commission of 1% (approximately $ 30). The candidate happily agrees and sends a transaction with confirmation to the network. The dishonest owner sees in the mining pool an unprocessed arbitrator transaction and sends his own: changes the arbitrator's fee to 0%. The fraudster puts the price of gas above the average, and with some degree of probability miners can process his transaction earlier. Such an attack is called Front running attack. State Version Number protects against it. If the pest owner transaction is processed earlier, the version number of the data in the contract will change. The arbitrator in his transaction sent the version number of the data one less. Therefore, the contract will refuse to perform the transaction, rollback will occur. The arbitrator will review the new conditions and either refuse to participate or agree by sending the current version number of the data. and with some probability miners can process his transaction earlier. Such an attack is called Front running attack. State Version Number protects against it. If the pest owner transaction is processed earlier, the version number of the data in the contract will change. The arbitrator in his transaction sent the version number of the data one less. Therefore, the contract will refuse to perform the transaction, rollback will occur. The arbitrator will review the new conditions and either refuse to participate or agree by sending the current version number of the data. and with some probability miners can process his transaction earlier. Such an attack is called Front running attack. State Version Number protects against it. If the pest owner transaction is processed earlier, the version number of the data in the contract will change. The arbitrator in his transaction sent the version number of the data one less. Therefore, the contract will refuse to perform the transaction, rollback will occur. The arbitrator will review the new conditions and either refuse to participate or agree by sending the current version number of the data. there will be a rollback. The arbitrator will review the new conditions and either refuse to participate or agree by sending the current version number of the data. there will be a rollback. The arbitrator will review the new conditions and either refuse to participate or agree by sending the current version number of the data.


    When developing a contract operating with air, you have to think a lot about bad scenarios. What happens if the owner of the contract has decided to deprive the arbitrator? And if the arbitrator was dishonest? And if the opponent is actually a hacker? Or are all three eager to fool each other, because the stakes in the dispute are high enough? In addition, it is necessary to take into account any possibility of disrupting the normal course of the dispute, when the broadcast will be blocked in the contract and even the owner will not get access to it. For example, the option of recognizing a dispute as intractable arose already in the course of implementation. For the same reason, the sequence of stages of the dispute is precisely this: the owner’s bid -> the choice of the arbitrator -> the opponent’s bid. It may happen that the opponent did not confirm his participation, and the Deadline time is set far in the future. In order not to become a long-term investor, the arbitrator may refuse to participate, but only until the opponent has made a bet. And there are a lot of such nuances in the contract. The good news is that it needs to be programmed once and used. If the dispute were formalized as a paper contract, in the case of such border situations many people over and over again would have to go into each item and agree among themselves on how to interpret it. The blockchain allows you to fix the conditions, as in the contract, but entrust the interpretation of the conditions to the virtual machine and always have one and only one result of their execution. in the case of such borderline situations, many people over and over again would have to go into each point and agree among themselves on how to interpret it. The blockchain allows you to fix the conditions, as in the contract, but entrust the interpretation of the conditions to the virtual machine and always have one and only one result of their execution. in the case of such borderline situations, many people over and over again would have to go into each point and agree among themselves on how to interpret it. The blockchain allows you to fix the conditions, as in the contract, but entrust the interpretation of the conditions to the virtual machine and always have one and only one result of their execution.


    It is impossible to ignore the problem of the interested arbitrator. In our contract, the arbitrator makes the decision alone. For simple situations, this is sufficient, but sometimes the risk of the personal interest of the arbitrator is unacceptable. One of the ways out is to introduce into the contract logic the ability to add several arbitrators and make a decision by voting. This is a rather complicated logic, especially if you want to make it universal for all possible disputes and their participants. However, the good news is that all the logic of complex collective arbitration can be put in a separate smart contract. The address of the contract the owner of the dispute will register as an arbitrator. From the point of view of the interface, such a contract should be able to call several methods from the dispute contract: consent to judge the dispute, refusal of such consent, three versions of the decision and one method of broadcasting.


    For part of the disputes, you can replace the group of arbitrators with a contract using one or more oracles. Or come up with another way out, for example, turn a dispute into a roulette with a random decision. And all this without changing the contract code of the dispute and without complicating the logic of its work.


    Testing


    I want to say a few words about testing. Everyone knows that test automation is good. Many actually write tests for their code. Some people use the TDD approach in development - a long-time and well-known Test Driven Development. The key difference between TDD and simple testing is that tests are written before code. This allows you to look at the contract code outside, to feel possible problems and to solve them in advance. In addition, TDD, if used properly, allows you to change the logic of operation much faster if it is needed suddenly. Proper use comes with experience. TDD is not a silver bullet, as you might think, reading numerous materials on this topic. At the same time, it is disturbing that the development manuals for Truffle and Node.js do not demonstrate the use of TDD for Solidity development at all.


    TDD implies that there are a lot of tests in the project. For example, the contract code of a dispute takes 325 lines, and the test code for this contract consists of 2,144 lines. At some point, the test was enough for the truffle test run to take more than a minute. The development cycle in TDD implies frequent test runs after small code changes. To prevent development from becoming a torment, I had to teach Truffle to run only a fraction of the tests that matched the regular expression that was passed.


    Under the hood, Truffle uses the Mocha framework to work with tests. Mocha can filter test runs on a regular basis, but Truffle out of the box does not know how to pass the corresponding parameter --grep from the command line. Taking advantage of the fact that the Truffle config is a regular JavaScript code, I entered into it the analysis of command line arguments and the formation of parameters for Mocha. The config that I got in the end is available in the project's GitHub. The implementation is not very beautiful, but it works and saves a lot of time.


    Summary


    The contract of the dispute was conceived as very simple in functionality, but thanks to TDD and the analysis of possible attack vectors, it evolved into a slightly richer in constraints implementation. The apparent shortcomings of the contract are related to the sole decision of the arbitrator, however, they can be eliminated without modifying the contract code of the dispute, if you implement a multi-arbitrator voting system in a separate smart contract. The use of oracles for disputes in which this is possible is realized in the same way.


    The BetMe dispute contract can be tested and launched using a pre -built template on the Smartz platform . This will require the Metamask extension for the desktop browser or Trust Wallet for mobile devices. Also, the source code of the contract itself is posted on GitHub.


    We have to admit that today the use of blockchain technologies comes down mainly to cryptocurrencies and the production of tokens for ICO. Decentralized autonomous organizations (DAO) have not yet become a reality. But if you fantasize how the dispute contracting systems will continue to develop, then you can submit a registry of arbitrators with a rating, for example, based on the Token Curated Registry. After the completion of the disputes, their participants could vote for or against the arbitrators with whom they dealt, changing their position in the ranking.


    On the one hand, the BetMe dispute contract is a practically applicable self-sufficient element. But on the other hand, it may well become one of the bricks from which an ecosystem of decentralized organizations will form over time.


    Links



    Also popular now: