以太坊网络在区块链开发者的狭窄圈子中广为人知，已经将其自身确立为开发智能合约的便捷稳定的平台。 我们试图通过提供简单但实用的合同使智能合同可供未准备好的用户使用。 我们最近开发了一项Bet Me争议智能合约。 合同基于两个对手之间的下注（争议）。 他们通过金钱来加强自以为是。 失败者亏钱，胜利者承担一切。 我将在本文中向您详细介绍。
为什么区块链在这里？
首先，很少有人问有关区块链的文章的作者的问题是：在这种情况下是否需要区块链？ 用口头协议或法律合同很难解决什么任务，而仅用区块链就很难解决？
如果两个人口头辩论，这通常会转化为新的审判。 “我不是故意的”，“外部环境会影响结果，否则我本来是对的”，“是的，我没有认真地与您争论，但您认为这是对自己的看法”，还有其他可能的借口使许多知名人士口头辩论。相当低的费率。 有了严肃的赌注和相距较远的相识，签订书面协议并详细写下争端的实质，赌注，决定标准以及各方认为重要的任何其他条件，就更有希望了。
这种方法有几个缺点。
- 大多数情况下，有必要吸引一位律师，甚至两边各雇用一名律师，否则您可能会忘记一个要点，这将导致财务损失。
- 通常，合同中只规定了当事方的义务，但没有规定违反这些义务的责任。 结果，事实证明，一方面不支付就太容易了，而另一方面，要想通过法院获得金钱是极其困难和昂贵的。
- 也可能是双方都坚持自己的无罪，甚至上庭也不能保证获胜者会获得金钱。
- 可能的结果是，失败者一方根本没有钱，即使有所有义务，即使是法院的判决也不会强迫它偿还债务。
区块链（特别是以太坊网络）使您可以用钱工作（我们将其称为以太币;这并不完全正确，但是它很方便并且足以反映事物的真实状态，因为以太币很容易兑换成法定货币，反之亦然）。 同时，在以太坊中，您可以将协议简化为一系列特定规则，这是不可能不履行的。 因此，我们的智能合约从各个方面接受资金并封锁它，直到发生特定事件为止。 一组预定义的计划规则将允许获胜者提款。 这正是您所需要的。
实作
可以通过多种方式来实施一套管理争议的规则。 下面我们将讨论我们为Smartz平台用户所做的事情。
争端涉及两方。 在以太坊网络上创建合同副本的人称为合同所有者（Owner），而其对手称为对手（Opponent）。 合同所有者设置了他认为是真实的文字说明。 对手押注该陈述是错误的。 由独立仲裁员（Arbiter）决定争端的结果，其候选人资格由所有人和反对者共同批准。 仲裁员以争议金额的一定百分比形式收取佣金。
合同的工作分为几个连续的阶段。
- 谈判中 。 所有者和对手甚至可以在订立合同之前以任何方便的方式进行谈判。 在共同决定由谁担任仲裁员之后，他们向候选人发出邀请以评判他们的争议。 收到邀请后，仲裁员将看到所有条件和相应的国家。 下文会详细介绍，但现在重要的是要了解，未来的仲裁员必须将此号码转移到合同中，以表明他准备在什么条件下判断辩论者。 如果所有者建立了非零金额的保证金（ArbiterPenaltyAmount），则根据条款，仲裁员必须将指定的广播时间转移到合同中，此后将其锁定，直到仲裁员决定辩论者或解决争端的最后期限为止。 在后一种情况下，仲裁员失去了提取保证金的机会，并且这笔款项在争端各方之间平均分配。
- 初始化 。 合同的所有者创建合同的一个实例并设置其参数。 仲裁员必须决定的日期（截止日期）； 仲裁佣金百分比（分数≥0且<100）； 保释金的金额（可能为零），作为保证，仲裁员必须保证在适当的时机以现有措辞解决争议。 所有者还设置他信任的仲裁者的以太坊地址。 以后只有该地址的所有者才能成为仲裁员。
- 拥有率 设置后，合同持有人下注。 为此，他向合同发送了任意数量的以太。 此金额是费率，已在合同地址处冻结。
- 仲裁员的同意 。 所有者的出价确定了争议的条款。 现在，仲裁员可以看到交易的全部条款：争端的用语，需要做出决定的时间，最重要的是，他可以理解他将获得多少以太币作为奖励。 如果仲裁员对所有事情都感到满意，他将确认他的参与并同时转移保险金。
- 寻找对手 。 在仲裁员同意后，开始寻找对手。 如果所有者只准备与特定的人争吵，或者将地址留空，则所有者预先设置对手的地址，然后网络上任何地址的所有者（仲裁者和所有者除外）都可以成为对手。 反对者通过调用合同的另一种方法来确认是否参与了争端，他将数据的当前版本号发送到该协议并进行广播-达到所有者所设置的数量。 从这一刻起，该赌注被认为已经结束。 现在，合同正在等待仲裁员的决定或截止日期。
- 争端的结果 。 仲裁员可以通过三种方式来裁决争议。
-确认陈述为真。 在这种情况下，合同的所有者可以提取全部以太币，除了仲裁员的佣金和保证金（如果有的话）：仲裁员提取了钱，而对手没有得到任何东西。
-确认该陈述为假。 在这种情况下，仲裁员可以提取以其应得的佣金和抵押额中的以太币。 对手得到其余的，但所有者什么也得不到。
-宣布争议解决。 例如，所有者提出了一个争议，声明“计划在下周日进行的A和B队之间的足球比赛将以2：1的比分结束，而对A的支持则结束”。 如果取消比赛，裁判将不会解决争议，但他应能够兑现其承诺，因为问题并非源于他的过错。 在这种情况下，每一方都可以要求将其投标书中标价的空气从合同地址转移到其钱包。 - 提取资金 。 当仲裁员作出决定或截止日期到来时，各方均可要求广播结论。 合同本身将计算出多少以太币，重点放在争端的结果上。
- 破坏合同 。 所有者可以向合同发送自毁命令。 可以在交易完成之前（如果找不到仲裁员），也可以在交易完成之后（如果各方撤回了欠他们的资金）来完成。 如果以一种神奇的方式，比在合同地址收到的空运多的飞机，这样的机会将是有用的。 发生这种事件的可能性非常低，但是在以太坊中，仍然不可能完全阻止广播到任意合约地址的传输，并且将冻结资金扔出去是愚蠢的。
现在介绍为什么需要州版本号。 这是随着争议的重大条件（例如，争议的措辞，佣金规模或仲裁员的罚款）的每次更改而增加的数字。 当某人同意争议条款时，他1）看到数据的当前状态； 2）向合同方法发送调用，该方法记录对条款的接受。 如果在这两个事件之间，如果一方（最有可能是所有者）更改了合同的参数，则您将同意另一版本的数据。 例如，一名裁判候选人在smartz.io上进入合同界面，并看到他被提议就10枚以太币（今天约为3,000美元）做出争议，收取1％的佣金（约30美元）。 候选人高兴地同意并将确认交易发送到网络。 不诚实的所有者在采矿池中看到仲裁员的原始交易，然后发送自己的交易：将仲裁员的薪酬更改0％。 欺诈者使天然气价格高于平均水平，矿工很有可能更早地处理其交易。 这种攻击称为“前奔跑攻击”。 州版本号可以防止这种情况。 如果所有者-虫害交易较早处理，合同中数据的版本号将更改。 仲裁员在其交易中发送的数据版本号少了一个。 因此，合同将拒绝完成交易，将发生回滚。 仲裁员将审查新条件，并通过发送数据的当前版本号拒绝参与或同意。
在开发以太合约时，您必须考虑很多糟糕的情况。 如果合同的所有人决定剥夺仲裁员的资格，将会怎样？ 如果仲裁员不诚实怎么办？ 如果对手实际上是黑客怎么办？ 还是因为争执的赌注足够高，这三个人都渴望互相愚弄？ 此外，有必要考虑到任何可能违反争端正常过程的情况，当广播将在合同中被阻止，甚至所有者也无法访问时。 例如，在实施过程中已经出现了宣布争议不可解决的选择。 出于同样的原因，争议的阶段顺序如下：所有者费率->仲裁人的选择->对手的费率。 对手可能不确定自己是否参加比赛，并且截止时间已定在未来很长时间。 为了不成为长期投资者，仲裁员可以拒绝参加，但只能在对手下注之前。 合同中有许多细微差别。 好消息是，这需要编程一次并使用。 如果将争端正式化为纸质合同，那么在发生这种边界情况时，许多人将不得不一遍又一遍地进入每个项目，并在彼此之间商定如何解释它。 区块链允许您像合同中那样固定条件，但是将条件的解释分配给虚拟机，并且始终只有一个执行结果。
人们不能忽略感兴趣的仲裁员的问题。 在我们的合同中，仲裁员独自做出决定。 对于简单的情况，这已经足够了，但是有时仲裁员的个人利益风险是不可接受的。 一种解决方法是将合同中增加几个仲裁员并通过投票做出决定的能力引入合同逻辑中。 这是一个相当复杂的逻辑，特别是如果您想使其对所有可能的争议及其参与者具有普遍性。 但是，好消息是，可以将复杂的集体仲裁的整个逻辑移到单独的智能合约中。 争议拥有者的合同地址将注册为仲裁员。 从界面的角度来看，这样的合同应该能够从争议合同中调用几种方法：同意对争议进行判断，拒绝这种同意，三种版本的决定和一种广播方法。 在仲裁合同中，可以使用大多数仲裁程序的决策逻辑，类似于在Multisignature Wallet合同中进行的操作，该方法也可以在Smartz.io中作为构造函数使用。
对于部分争议，可以使用一个或多个预告片将一组仲裁员替换为合同。 或提出另一种方法，例如，使用随机解决方案将参数转换为轮盘赌。 而这一切-无需更改争议合同的代码，也不会使其工作逻辑复杂化。
测试中
我想谈谈测试。 每个人都知道测试自动化是好的。 许多人实际上为他们的代码编写测试。 有些人在开发中使用TDD方法-长期而著名的测试驱动开发。 TDD与简单测试之间的主要区别在于测试的编写要早于代码。 这使您可以从外部查看合同代码，感觉可能的问题并提前解决。 此外，如果使用得当，TDD可使您在突然需要的情况下大大改变工作逻辑。 正确使用会带来经验。 您可能会想到，TDD并不是万灵药，您可以阅读有关该主题的大量材料。 同时，令人担忧的是，Truffle和Node.js中的开发指南根本没有演示TDD在Solidity开发中的使用。 新手开发人员会养成不良习惯，最终会遭受很多痛苦。
TDD表示项目中有许多测试。 例如，争议合同代码长325行，而该合同的测试代码长2144行。 在某个时候，测试变得足够大，以至于松露测试需要一分钟以上的时间。 TDD的开发周期涉及在较小的代码更改后进行频繁的测试运行。 为了使开发不会变成麻烦，我不得不教Truffle仅运行与传递的正则表达式匹配的部分测试。
在底层，Truffle使用Mocha框架进行测试。 Mocha可以按固定的时间间隔对测试的启动进行过滤，但是Truffle无法直接从命令行传递相应的--grep参数。 利用Truffle配置是普通的JavaScript代码这一事实，我在其中输入了命令行参数解析和Mocha参数的格式。 结果得到的配置可以在GitHub项目中找到。 实现不是很漂亮，但是它可以工作并且节省大量时间。
总结
争议合同在功能上被认为非常简单，但是由于TDD以及对可能的攻击媒介的分析，它演变成了对限制的更丰富的实现。 合同的明显缺陷与仲裁员的唯一决定有关，但是，如果在单独的智能合同中实施多个仲裁员的投票系统，则可以在不修改争议合同代码的情况下消除这些缺陷。 对于可能发生的争议，使用甲骨文的方式也是如此。
可以使用Smartz平台上的预定义模板来测试和运行BetMe争议合同。 这将需要针对桌面浏览器的Metamask扩展或针对移动设备的Trust Wallet。 此外，合同本身的源代码发布在GitHub上。
值得认识到的是，如今区块链技术的使用主要归结为加密货币和ICO代币的发行。 权力下放的自治组织（DAO）尚未成为现实。 但是，如果您想象争议合同系统将如何进一步发展，那么您可以想象一个具有评级的仲裁员列表，例如，基于Token Curated Registry的评级。 争端解决后，其参加者可以投票或反对所处理的仲裁员，从而改变其在排名中的位置。
一方面，BetMe争议合同是切实可行的自给自足要素。 但另一方面，随着时间的流逝，它很可能成为形成分散组织的生态系统的障碍之一。
友情链接