Amoveo的智能合约

by Tallak Tveide | Read in English Amoveo的智能合约

2018年10月29日 - 6分钟阅读

Amoveo是一个新的区块链项目，具有可编程的状态通道，链上预言机(oracle)，金融衍生品等。在这篇文章中，我将看一下通道中的智能合约的实现方式，这是很不同的。因此，首先要忘记你对其他区块链的智能合约编程的所有了解。本文试图从广义上描述Amoveo状态通道智能合约。我们不会讨论为什么你要使用状态通道。我们也不会讨论名为Chalang的Amoveo智能合约语言，这是一种功能语言，在虚拟机中没有goto操作码，使其更容易分析。正如你将在后面看到的，Amoveo合约，就其性质而言，很容易推理，因为它们在代码之外没有状态。

由于Amoveo中的状态通道是加密经济安全的，所以双方参与者都值得合作。双方都签署了交易[TX]，把钱放进通道并随后从通道中提取。在加密经济上是安全的，这意味着双方都必须把钱放进通道，只有通过合作才能赎回。当双方合作时，没有代码被存储在链上。相反，双方都证明通道中的钱在关闭通道时是以某种方式分配的。这涉及到一个channel_new TX，参与者将钱插入通道，以及一个channel_team_close TX，在参与者之间分配通道余额。这两个TX都是由两个参与者签署的。这是简单的情况，可能也是最常见的情况，没有任何代码会进入链上。

如果双方不能就资金分割达成一致，我们就会遇到这样的情况：channel_new TX仍然存在，但我们需要一个channel_solo_close TX来启动只有一方的关闭。在这个TX之后，可以添加额外的channel_slash TX，为状态通道提供一个更新的代码。将会有一段时期，通道资金被冻结，以允许其他参与者做出反应。通道可以用channel_timeout TX关闭，之后资金会从通道转入两个参与者的账户。在这种情况下，channel_solo_close和channel_slash将包含通道的最新商定的代码。所有Amoveo服务器可以独立验证代码的结果，作为处理区块链的一部分。这就是状态通道与区块链互动的机制。现在让我们看看代码是如何在状态通道中实际执行和实例化的，以及状态是如何在通道中维护的。

使用伪代码，我将制定一个简单的合约，对链上预言机(oracle)的结果进行打赌。请注意，这个严重简化的代码不会起作用，而是为了说明这些合约是如何运作的。该合约在没有任何输入的情况下运行，并返回三个值：单边关闭的延迟，一个nonce和资金从一个参与者到另一个参与者的移动（参与者是投注者和服务器，这里没有假设有市场）。

# contract for betting on an oracle result
# returns {<delay period>, <nonce>, <amount to transfer>}
oracle = “jjFZnjADflb4FzocON+Kboh5T+UHHfiw”
case oracle_result(oracle) do
 “unfinished” ->
   nonce = 1
   return {1 year, nonce, 0}
 “bad question” ->
   nonce = 1
   return {0 days, nonce, 0}
 “statement true” ->
   nonce = 2
   return {0 days, nonce, 1.0 VEO}
 “statement false” ->
   nonce = 2
   return {0 days, nonce, -2.0 VEO}
end

首先，注意到通道中只有代码，没有状态（我觉得这很有趣，因为它们被称为状态通道）。对于这个特定的合同，有三个项目将这个代码与一般的代码区分开来：预言机(oracle)ID，如果预言机(oracle)为真，要转移的VEO数量，以及假的数量（后两项定义了赌注的赔率）。通用代码可能看起来像这样。

# contract for betting on an oracle result
# returns {<delay period>, <nonce>, <amount to transfer>}
oracle = <oracle-id>
case oracle_result(oracle) do
 “unfinished” ->
   nonce = 1
   return {1 year, nonce, 0}
 “bad question” ->
   nonce = 2
   return {0 days, nonce, 0}
 “statement true” ->
   nonce = 2
   return {0 days, nonce, <amount-if-true> VEO}
 “statement false” ->
   nonce = 2
   return {0 days, nonce, -<amount-if-false> VEO}
end

双方如何就签署哪种代码达成一致？他们都必须能够想出完全相同的代码，这样他们就可以同时签署合同的哈希值。这意味着，一旦双方就<oracle_id>、<amount-if-true>和<amount-if-false>达成一致，他们都必须能够访问通用合同并生成一个特定的合同来签署。

如果一方是Amoveo节点，另一方是使用网络钱包的用户，用例将是这样的。

用户在一个表格中输入oracle id和两个金额
网络钱包将表格的值放入通用代码中，并对其进行签名（提供签名和代码的哈希值）。
网络钱包向服务器提交数值和签名代码
服务器使用这些值和它自己的通用代码，并验证哈希值是否匹配。
服务器也对代码进行签名，并将签名返回给网络钱包。

因为任何一方都不应该相信另一方能够为通道智能合约产生正确的代码，服务器和网络钱包都必须包含通用合约和替换参数值的方法。

因此，如果状态通道不包含状态，它仍然可以非常有用吗？

我想再做一个可以支持小额支付的例子代码。这里的目的是让用户把钱放在一个通道里，以获得一个服务，例如玩游戏。VEO是按使用秒数收费的，但你不希望把所有这些TX放在区块链上。通过将状态（玩游戏的秒数）注入到合约中是可以做到的，就像这样。

# contract for micropayments
# returns {<delay period>, <nonce>, <amount to transfer>}
nonce = 1
usage = 100
return {0 days, nonce, usage}

游戏服务器和游戏客户端每隔几秒钟就会生成一个新的代码，包含新的累积使用量。随着时间的推移，服务器和客户端都会签署这些。游戏玩家控制并信任他的游戏客户端软件。游戏服务器不可能拿任何没有被玩家签名的钱。插入通道的具体代码将看起来像。

# contract for micropayments, at t = 10:00:00
# returns {<delay period>, <nonce>, <amount to transfer>}
nonce = 1
usage = 0
return {0 days, nonce, usage}
# contract for micropayments, at t = 10:00:10
# returns {<delay period>, <nonce>, <amount to transfer>}
nonce = 2
usage = 100
return {0 days, nonce, usage}
# contract for micropayments, at t = 10:00:20
# returns {<delay period>, <nonce>, <amount to transfer>}
nonce = 3
usage = 200
return {0 days, nonce, usage}

以此类推。只有最新的代码需要被存储，因为只有具有最高nonce的代码才会被用来关闭通道。一旦游戏者玩完了，通道就可以关闭，资金也可以分配，结果链上总共有两个交易，都不包含任何代码。