免責聲明：本文旨在傳遞市場信息，不構成任何投資建議，不代表火星財經立場。
小編：記得關注哦
投資區塊鏈，猛戳：火星財經App下載
文章來源：鏈向財經
序
眾所周知，因為BCH腳本的限制（其他特比特系分支也一樣），開發者只能在BCH主鏈上實現無狀態的智能合約，這就使得BCH智能合約可以做的事情變得很有限。但是近期BCH的資深開發者Chris Pacia發現，BCH可以通過升級實現有狀態的智能合約，就像ETH那樣。
------以下是譯文-----
Malfix是BCH的一個涉及到共識變更的提案，旨在解決交易延展性BUG。這是一個相當有爭議性的提案，部分原因是它將成為BCH最重大的硬分叉變化，還有個原因是很多人認為這是不必要的。在本文中，我會介紹一個我們以前從來沒考慮過的Malfix的用例 – 給予BCH以太坊式的完整的智能合約編程能力。
乍看之下，這有點瘋狂。一個用來修復交易延展性BUG的的提案，怎麼可能會讓BCH成為以太坊的競爭對手？讓我們深入研究下去吧。
以太坊（ETH）
ETH的核心功能是可以讓用戶在鏈上創建合約。有了這些合約，用戶就可以保存數據。合約定義了許多功能，當用戶通過一個新的交易連接到合約時，用戶可以讀取數據，以某種方式操作它，並且將其保存到合約裡面。
這是在區塊鏈上保存數據的核心功能（我們現在開始稱其為“狀態”），比特幣一直缺乏這種向合約讀寫數據的能力。在比特幣中，我們有一種腳本語言，但是它僅能允許我們從一個地址釋放幣時設置一些條件。絕大多數人會告訴你，這些腳本無法把狀態保存到區塊鏈上，並且腳本也無法像ETH那樣從任何其他交易中讀取狀態。
或許，他們其實是可以的？
OP_CHECKDATASIG
2018年11月，BCH新增了一個操作碼OP_CHECKDATASIG，當時BSV粉想盡辦法阻止這個操作碼添加到協議裡面，但是最終失敗了。
這個操作碼看上去非常基礎，它所能做的事情只是接受任意簽名，公鑰和消息，並且驗證簽名。
<signature><public_key> <message> OP_CHECKDATASIG
這個類型的功能對於加密貨幣非常重要，但是它竟然沒有在一開始就包含在比特幣裡面，這令人相當驚訝。
雖然這個操作碼看上去相當缺乏想象力，但它實際上非常有用，每天我們都從中學習到越來越強大的能力。
合約
OP_CHECKDATASIG啟用的第一個主要功能是一個叫做合約的東西。在OP_CHECKDATASIG出現之前，比特幣腳本只能在釋放幣的時候設置一些條件，僅此而已。舉個例子，某個腳本可以說“如果A向這個腳本提供一個有效輸入，那麼他就可以解鎖並花費這個地址上的幣。但是一旦幣被解鎖，他就可以把幣發送到任意地址。”
而合約可以限制A只能把幣發送到某個地址。OP_CHECKDATASIG 如何實現這個限制呢？請思考以下腳本
<signature> <public_key> OP_CHECKSIG
這是一個典型的比特幣交易的花費腳本。OP_CHECKSIG操作碼對交易數據進行哈希，並且檢查簽名相對於給定的公鑰和交易哈希值是否有效。
現在假設我們使用和上述完全相同的簽名和公鑰，如果通過OP_CHECKDATASIG操作碼進行哈希運算和校驗。
<signature> <public_key> <message> OP_CHECKDATASIG
如果這個消息（message）和這個交易的原始交易數據一致，那麼腳本運行結果為真（true）。由於OP_CHECKDATASIG會對這個消息進行哈希，並且根據公鑰和哈希值進行簽名驗證，如果相同的簽名和公鑰都通過了OP_CHECKSIG和OP_CHECKDATASIG的檢查，那麼我們就知道堆棧上留下的消息就必定是這個交易的原始數據。
這非常聰明。我們現在已經獲得了原始數據的訪問權限，並且可以使用腳本對其進行解析，確保交易中的輸出把幣發送到我們希望送達的地址。換句話說，我們可以使用腳本語言限制某個交易只能把幣發送到某個特定的地址。
那我們可以用來做什麼呢？我們可以做很多有趣的事情。舉個例子，有個叫last will的智能合約使用熱私鑰和冷私鑰實現了一個死人開關（注: dead manswitch，不知道如何翻譯恰當），讓偷幣變得極其困難。
我們還可以創建循環交易。請注意，比特幣腳本自身是無法循環的，它就是這麼設計的。但是我們可以在腳本上放一個合約，強制幣返回到它發出的地址。基本上，一旦幣進入了那個地址，它就會永遠在那裡，並且沒法出來。我將這種腳本稱為“循環”，因為每當有人從此地址開始花費，相同的腳本就會再次執行。只要一直有人願意發出交易（當然這是需要支付手續費的），這個腳本就會一直運行。
但是這看上去似乎毫無用處，我們為什麼要這麼做？
創建ETH式的智能合約
一旦堆棧上有原始交易數據，我們就可以做更多事情。我們可以把前一個交易壓入堆棧，通過對前一個交易進行哈希，並且比對當前交易的輸出端的哈希值，我們就可以驗證這是否是前一個交易。
但是等一下，還有更多！
通常，當腳本執行任何腳本自身一部分計算的數據時，所有意圖和目的都會丟失。計算結果（如果有的話）不會保存在區塊鏈中的任何地方，當然也不能被其他交易訪問。但是，使用合約，我們可以把計算結果保存在交易的OP_RETURN輸出中。這要求資金的花費者在他的本地計算機上運行大部分腳本，以確定計算結果。計算完成後，合約會將結果保存在OP_RETURN裡面。
現在請注意我們擁有了什麼？這個腳本運行並且完成了一大堆計算，計算結果保存在交易裡面，並且這筆交易數據可以被下一筆交易訪問。換句話說，現在比特幣腳本可以以這樣的方式在區塊鏈中保存狀態，以後的交易可以讀取這個狀態，執行某些計算並且以某種方式改變它，並將其保存到區塊鏈上。基本上，我們在BCH上實現了ETH的功能！
比特幣命名系統
這只是一個例子。ETH上有一個叫ENS的東西 – 以太坊命名系統（Ethereum Naming System）。這是一個智能合約，允許人們在鏈上註冊名字（或域名），並且映射到特定的數據，比如IP地址，或者ETH錢包地址。
使用上面的方案，我設計了一個叫BNS（比特幣命名系統）的智能合約，基本上做和ENS一樣的事情，是如前文所說的那種任何人都可以花費的循環合約。當有人想註冊名稱時，他們會把當前交易，先前交易，要註冊的名稱，和一個merklix排除證明壓入堆棧。合約會從前一個交易載入合約狀態樹的根哈希，驗證先前所說的merklix根的排除證明，證明之前沒有人註冊過該名稱，然後更新根哈希並在交易中保存新的狀態。就像以太坊上的ENS智能合約一樣，BNS管理名稱的狀態數據庫並防止雙重註冊。名稱可以轉換為SLP token，並且用來交易。
幾乎完成了
在遇到大問題之前，我們已經把這個方法完成了99%。當你把數據壓入堆棧，BCH的共識規則要求數據體積必須小於520字節。當你把上一個交易壓入堆棧，如果數據大於520字節，交易就會失敗。
可以想象單個交易的體積可以在520字節以下，但是這個體積會隨著新的交易不斷增長。看下這個：
交易B把前一個交易A壓入堆棧。
交易C把包含交易A的交易B壓入堆棧。
交易D把包含交易A&B的交易C壓入堆棧。
在1，2次交易之後，我們就超過了520字節的限制。我們已經和ETH式的智能合約如此接近了，但是因為空間不足，我們失敗了。
Malfix
Malfix引入了新的交易版本V3。這種版本的交易具有兩個交易ID。一個是普通的大家所熟知的TXID；另外一個是UTXID，是去除了輸入腳本的交易的哈希值。在大多數地方，你可以像以往那樣使用TXID。唯一的區別是，在交易的輸入端的前一個輸出端引入V3版本的交易時，你應該使用UTXID代替。
這個起到的作用是，當我們把上一個交易壓入堆棧時，我們就不需要把輸入腳本壓入堆棧。這將使我們的數據永遠保持在520字節以下（他們不會再像之前那樣隨著每個交易增長）
這個相對較小的變化就是我們所需要的全部。
Malfix的問題
從全節點的角度來看，Malfix實現起來相對簡單。它的主要是問題是不像之前每次BCH的硬分叉升級，這個相當具有侵略性。所有的錢包都需要升級，才能處理V3版本的交易。
如果一個未升級的錢包收到了一筆V3版本的交易，它就不能花費裡面的幣。
我們可以通過以比特幣現金地址格式碰撞版本字節（或保留位）來緩解這種情況。
已升級的錢包可以編程為: 當發送幣到舊版本字節時，只能構造V1或V2版本的交易（可選）；當發送幣到新版本字節時，就使用V3版本的交易。這主要是為了防止未升級的錢包接收V3版本的交易，並且允許它們按照自己的節奏升級。
可能有其他類型的服務會因為Malfix而中斷，我們必須長時間的深入思考可能會是哪些服務以及如何簡化升級。
與以太坊的比較
所以這是否意味著BCH具有ETH的全部功能了呢？並不完全是的。記住，ETH是從一開始就設計成按照這種方式運行的。比特幣在設計時顯然沒有考慮到這種類型的功能，我們只能使用更加聰明的方式來打破比特幣的天然限制。我認為ETH這樣的智能合約總是更加容易進行開發，儘管像Spden這樣的高級語言在某種程度上也可以幫助BCH開發者體驗智能合約。
BCH保存狀態的方式和ETH也是不同的。在ETH裡面，只要你願意支付gas，你可以在合約中保存任何類型的數據。
在BCH裡面，我們最多隻能在op_return裡面保存220字節數據，這隻夠用來保存一些哈希值。這意味著我們的狀態需要成為數據樹的根，而不是數據本身，就像之前BNS（比特幣命名系統）那個例子。使用合約的人將自己負責存儲實際數據（儘管可以通過掃描合約的所有交易來重建狀態）
最後一點，ETH上的合約可以對其他ETH合約進行函數調用。我不確定這在BCH上是否可行，因為我還沒有深入思考過。
如果Malfix提案最終可以通過，那麼在BCH上創建ETH式的智能合約是切實可行的。我們或許無法實現ETH的所有功能，但這依舊是一次腳本語言的大規模升級。
原文作者: Chris Pacia （BCHD全節點開發者）
原文鏈接:
https://honest.cash/cpacia/a-case-for-malfix-4436/
------譯文結束-----
結束語
我是懷著非常激動的心情看完這篇文章的，並且前後看了好多遍。我覺得非常有必要讓國內BCH社區瞭解這個具有革命性意義的技術，因此特意花幾個小時翻譯了這篇文章。文中難免有些錯漏之處，請諒解。
智能合約的重要性不言而喻，像前幾天上線的比特耶穌的那個OTC平臺，核心功能就是一個利用OP_CHECKDATASIG操作碼構建的智能合約。
Malfix這個提案如果真的實現，BCH能做的事情就會變得非常非常多。按照我的理解，在BCH上實現這種ETH式的智能合約，不會出現像目前ETH那樣的性能瓶頸。而且這是BCH主鏈上的智能合約，因此這些合約都是可以支持0確認交易的，到時候BCH就會變得極其具有競爭力。畫面太美，簡直都不敢想啊。希望11月份的升級可以通過這個提案。
聲明：本文為入駐“火星號”作者作品，不代表火星財經官方立場。轉載請註明出處、作者和本文鏈接
提示：加密資產為高風險投資標的，請謹慎選擇。