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的代碼纔會被用來關閉通道。一旦遊戲者玩完了，通道就可以關閉，資金也可以分配，結果鏈上總共有兩個交易，都不包含任何代碼。