Clemens Ley 關於 BitcoinToken 的微信問答
背景資料
閱讀本文前，建議先看完老劉整理的 《BitcoinToken的參考資料》 。本次問答的英文原文參見 ClemensLey BitcoinTokenWeChat AMA 。
AMA問答
Clemens Ley 是 BitcoinToken 的創始人。開發人員很快就能用在BCH區塊鏈上發token，並用javascript語言寫智慧合約了。Clemens 在本月早些時候的一次 聚會演講中 首次介紹了他對 token 的一些想法 。
2018年9月12日，他在一個微信群中舉行了一次“你問我答”的活動。參與的人包括來自中國的礦工和開發者。其中有來自BTC.com，BTC.top和Rawpool的代表進行了提問。為清楚起見，問答的內容有稍做調整。
來自礦工和開發者的問題
1. BitcoinToken會像編譯器一樣將Javascript編譯成比特幣的彙編指令碼嗎？
BitcoinToken可以被認為是一個編譯器，它可以將（用Javascript編寫的）智慧合約編譯成可以釋出，傳輸和交易 token 的Javascript包。生成的Javascript包將非常容易使用，即使對於對比特幣一無所知的人也是如此。例如，要發 token，使用者只需如下幾行 Javasript 程式碼：
const token = new BitcoinToken（）
token.name =’MyToken’
token.supply = 21000000
await token.create（’./ erc20.js’）
await token.send（500，myFriendsPublicKey）
檔案“./erc20.js”將包含用Javascript來編寫的智慧合約。以下是此類檔案的示例：
async function isValid (tx:Transaction): boolean{
const sumInputs = tx.inputs.reduce((a,b)=> a.data + b.data,0)
const sumOutputs = tx.outputs.reduce((a,b)=> a.data + b.data,0)
return sumInputs === sumOutputs
}
其他人可以編寫其它如“erc20.js”的合約。如果寫合約的人願意和社群分享這個合約，任何人都利用此檔案輕鬆地釋出相同型別的 token 而無需建立新的合約。
Javascript 程式碼是被翻譯成 Bitcoin Script 裡的操作碼嗎？
不，它沒有被翻譯成操作碼。比特幣指令碼中的操作碼不足以表達智慧合約。
你在哪裡放置 Javascript 檔案：在比特幣區塊鏈或其他檔案系統，如 IPFS？
我的計劃是將js檔案儲存在區塊鏈中。我將JS檔案儲存在交易輸出指令碼上。
這樣我們就可以在發行token的轉賬中建立合約規則，然後由每個使用者找到並以此規則驗證，是這樣嗎？
是的。
由於比特幣區塊鏈儲存有限，大的合約可能無法在鏈上儲存？
我們會把大的合約拆成小的，放在多個輸出腳本里。
BitcoinToken 不會把所有的 JS 程式碼儲存到鏈上，只儲存合約或是驗證程式碼對嗎？
是的，只存驗證 token 轉移的合約程式碼。在大多數情況下，它不會非常大。它也可以連結到現有檔案，這樣我們只需要儲存一次智慧合約就夠了。
你使用 P2SH 來儲存 Javascript 程式碼嗎？
是的。
2. 是否有我們可以用來編譯的 Javascript 子集？
出於安全原因考慮，我們需要使用一些沙盒技術。這就可以包含一個有合適語言行為的 Javascript 子集。細節尚未完全確定。有一家非常好的電腦保安公司在給我們提供建議。
3. BitcoinToken 的限制是什麼，例如哪個用例很難實現？
在表達能力（可以表達的智慧合約類別）上，我認為沒有限制。我認為 BitcoinToken 可以表達所有可以在以太坊中表達的智慧合約。
我現在還不確定哪些例子難以實現。像 erc20，erc721 這樣的基本合約將非常簡單，並且很容易在沙盒外用程式碼庫實現。更復雜的智慧合約，如投票、點對點打賭和拍賣，將需要更多的工作。一旦有人實現了這些智慧合約之一併願意與社群分享他們的工作，我們也可以將它們變成庫檔案。一旦發生這種情況，它們將像 erc20 token一樣易於使用。
4. 與 Solidity 或 WHC 相比，BitcoinToken 的實際成本是多少？它會為使用者和礦工節省更多成本嗎？我不是在談論手續費。
使用 BitcoinToken 一開始是免費的（礦工費除外）。之後，我可能會使用一種商業模式，開發人員可以免費建立和發行 token，但是一旦他們超過某個收入門檻就必須要付費了。他們可以用 bitcoin 或是他的自己建立的 token 來付費，因為這樣對他們來說也是最簡單的。
在 WHC 中，使用者需要為發行 token、向多個使用者傳送 token、以及其他交易付費，否則這些行為可能會有 DoS 風險。在我看來，這種方法存在兩個問題：首先，使用者哪怕想在主網上試一下，也需要付費。其次，他們必須先買 WHC 幣來付費。這會讓入門門檻變高。
與以太坊相比，BitcoinToken 將更便宜，因為 BCH 的交易費的中位數通常比以太坊的1/100。
5. BitcoinToken Javascript 是圖靈完備的嗎？
我認為目前在智慧合約裡的圖靈完備目前沒有一個明確的定義。但是，我認為（約95％的確定性）BitcoinToken 可以表達以太坊中表達的每個智慧合約。因此，如果您認為以太坊是圖靈完成的話，那麼 BitcoinToken 也是如此。
6. 我們如何優化 Javascript 編譯後的程式碼？
這是一個很寬泛的問題。可以說在過去80年左右的時間，傳統程式語言的編譯器一直在進行優化，但仍然是一個難題。我還不知道我們將如何為 BitcoinToken 做到這一點。但是我想指出，傳統的軟體已經過優化，可以實現低時間或空間複雜度。在智慧合約的情況中，我們必須為低成本而進行優化。這將在未來幾十年為電腦科學家提供許多有趣的工作。
7. 我們是否需要把編繹後的 Javascript 程式碼轉換回去，這容易實現嗎？
BitcoinToken 需要在 Web 瀏覽器中工作，因為這樣可以構建非託管應用程式。因此，最終到達使用者終端的程式碼都會是 Javascript。可以對 Javascript 程式碼進行混淆，但是某種程度上是可以解混淆的。
8. 我們如何使用比特幣的輸入來儲存區塊鏈中智慧合約的狀態？
智慧合約的狀態將儲存在輸出指令碼中。
但這不是很有限嗎？例如有一百萬持有人的代幣合約。
一種思考方式是：資料將在區塊鏈上，程式將用 JS 編寫，也儲存在區塊鏈中（類似於以太坊）。每個持有者將有一個輸出，儲存著與他相關的狀態（如他的賬戶餘額）。
9. token 轉賬是否支援零確認？
BitcoinToken 上的零確認與 BCH 的零確認一樣安全。如果您要轉移 1 美元的 token，接收方將樂意接受零確認。如果 token 價值100美元，接受方可能會選擇等待幾個確認。
BitcoinToken 的零確認足夠安全嗎？
是的，BitcoinToken 的工作方式與 BCH 相同，所以是一樣安全的。這與Omni（以及WHC）形成鮮明對比，他們的零確認不僅不安全，而且基本上不可能。這使得 WHC 在即使是中等吞吐量要求的應用中，也難以用現有形容滿足。
10. BitcoinToken 是否支援 SPV 錢包？普通使用者使用它的門檻是什麼？
支援的，因為它就像比特幣一樣。使用者的要求是客戶端要能執行 JS 程式碼。
11. 它是否設定了約束以防止無限迴圈，例如以太坊上的燃油手續費機制或其他方式？您將如何預防惡意程式碼所造成的風險？
這些都是非常重要的問題，因為它們涉及到了礦工的安全問題，從而可能是整個比特幣現金網路的安全問題。值得注意的地方是，BitcoinToken 所提供的智慧合約不會被礦工執行。只有收到該token的使用者才會執行實際的 Javascript 。如果 Javascript 包含一個（可能是隱藏的）無限迴圈，則使用者的客戶端進入無限迴圈，而不是礦工。結果將是沒有人能夠接受這樣的token，這將使它變得毫無價值。攻擊者發行使使用者進入無限迴圈的 token 得不到一點好處。
BitcoinToken 並沒有給礦工帶來新的可攻擊點。它的工作方式與比特幣完全相同，礦工甚至不會注意到它的存在。如果您是專業 BCH 礦工，您也同樣能處理好 BitcoinToken 無需任何改變。
12. 您對大量使用 op_return 並將資料放入其他節點以確定其含義的看法是什麼？你認為從長遠來看這會對比特幣造成損害嗎？
我不認為 op_return 是放置資料的正確位置。其中兩個原因：
首先，op_return 未來可能會被修剪掉。我想把資料放在區塊鏈上的原因正是因為我能保證它不會被修剪。可以被修剪的資料最好不要放在區塊鏈中。
第二個更重要的原因：op_return 中可以存 token 的轉帳資訊。但是它也可能以錯誤的方式被使用，這可能導致問題。比如說：Omni 容易受到塊重組這一事實恰恰是因為 op_returns 中的 token 流以錯誤的方式編碼。在 Omni 中修復它將非常混亂並且容易出錯並且將導致非常糟糕的效能（在某些情況下，必須在重組後重新解析 token 的整個歷史）。解決該問題的最簡單方法是更改比特幣並強制執行指定交易排序。但應用程式寫入錯誤程式碼時，不應當去改 Bitcoin。
你能解釋一下這一句嗎：“… omni容易受到塊重新排序這一事實正是因為 op_return 中的令牌流以錯誤的方式編碼。”
不好意思我不能，因為我無法很好的解釋這裡面的細節。我是根據 Mastercoin（和Omni）創始人對別人的問題回答 c 來判斷的。
我對此的唯一解釋是他們以錯誤的方式編碼了token的傳輸資訊。當我開發 BitcoinToken 時，我甚至沒有想到這一點。我只是試著讓它儘可能地與比特幣相似。這樣 BitcoinToken 不會受到塊重組的干擾，就像比特幣一樣。
13. 與其他 BCH token 方案比，BitcoinToken 的優缺點是什麼？
這是一個廣泛的問題，因為現在有這麼多新提案。我儘量長話短說。
- OP_GROUP 需要更改比特幣協議，BitcoinToken 不需要。
- RSK使用一個基於不同的挖礦網路（聯合挖礦，但仍然是不同的挖礦網路）的側鏈，這比直接在比特幣現金上構建的 token 安全性低
- Tokeda 需要一個（或多個）可信任的第三方。BitcoinToken 是無需第三方信用背書的
- 我所知道的所有其他方法（Omni，SLP，Counterparty，EPOBC，Coinspark，Colu，Open Assets）都不可程式設計。每個只支援一種小範圍的，硬編碼的智慧合約。這些智慧合約僅對極少數應用程式有用。在過去10天裡，我曾與七家公司進行了交談，都希望使用我的軟體。他們都不需要千篇一律的解決方案，他們都需要定製智慧合約。目前，只有 BitcoinToken 可以做到這一點。
14. 我們如何使用輸出指令碼儲存一些複雜狀態？持有人餘額只是一個很簡單的場景。
好問題。我們必須要解決好這個問題。我有一些初步想法，但想以後再分享。
15. BitcoinToken 是基於 UTXO 模型還是基於帳戶模型？
BitcoinToken 的構建與比特幣類似。因此它像比特幣一樣基於 UTXO 模型。
16. 再確認一下：我認為我們通過利用比特幣交易來解決雙花問題。我們不能在一個塊中發生衝突，因此傳輸 token 是零確認安全的。是這樣嗎？
它與接受比特幣的零確認一樣安全。雙花 BitcoinToken 生成的 token 的唯一方法是將包含 token 傳輸的比特幣雙花掉。
17. 您將如何支援不可交換的 token？有辦法實現嗎？
一般的token要求輸入所花費的數量等於輸出建立的數量。要做一個不可交換的 token，必須驗證比特幣交易的輸入和輸出中 token 集合相等而不是數量相等
async function isValid（tx：Transaction）：boolean {
const sumInputs = tx.inputs.reduce（（a，b）=> a.data + b.data，0）
const sumOutputs = tx.outputs.reduce（（a，b）=> a.data + b.data，0）
return sumInputs === sumOutputs
}
18. 如果錢包意外地將染色幣用於錯誤的輸出指令碼，會發生什麼情況？token 會被銷燬嗎？
在某種程度上智慧合約開發人員可以防止這種情況發生，但如果智慧合約開發人員不關心或者一些邊界情況，token 可能會丟失。有幾種解決方案。最簡單的方法是在初始化token錢包時使用新的私鑰。不要在任何其他錢包中使用該金鑰，也不能花費 token 承載交易。或者，我們可以使用特殊地址型別，如染色幣，但這不會立即可用。
你的意思是 token 可以被銷燬，但不會影響 BCH 的交易正常進行？
是。如果使用者廣播無效的 token 轉賬，那麼他會銷燬掉裡面的 token。BCH是保持不變的（因為礦工根本不知道有隻能合約這回事）。
19. 我們可以使用 BitcoinToken 控制比特幣（不僅僅是 token）的流轉嗎？如果可以，請分享一些例子。
另一個好問題。可以，但我想不出有啥好的例子需要用這種方式的。您可以編寫一份智慧合約，要求您只能傳送偶數個比特幣。如果使用者要傳送奇數的比特幣，他將使 token 無效（如果沒有 token 則不是問題）。BCH 仍然是安全的。
不是最好的例子，但我只是想說，你可以強制執行任何可以在 JS 中編碼的屬性，給定事務的 JSON 表示。
20. 您剛才說我們需要將 JS 程式碼分到多個轉賬裡。你現在如何儲存 JS 程式碼，以及錢包需要做多少工作才能正確解碼 token？
目前我只能存一個輸入指令碼可以放得下的javascript程式碼長度。使用某種機制可以很容易地在多個輸出上展開更長的檔案。我只是還沒有去實現這一點。
21. 為什麼選擇直接儲存Javascript而不是編譯操作碼？有什麼好處？
有許多 Javascript 程式無法用比特幣指令碼表達，因此我們無法編譯成比特幣指令碼。當然，我們可以將JS程式碼編譯成任何形式的彙編程式碼，這將同樣可以工作。如果使用者有需求，我將會建立這個工具。
22. BitcoinToken專案現在如何進展？產品釋出的任何時間表或路線圖？
我正努力在幾周內準備好原型，以便讓開發者把玩。如果一切順利的話，主網的釋出將計劃在年底進行。我將把我的原型提供給選定的一些想要在BItcoinToken之上構建應用的開發人員。如果您想在BitcoinToken之上構建一些東西，請傳送電子郵件至[email protected]，我會為您安排。
23. 是否需要 每個 相關使用者都來執行嵌入在轉賬中的JS程式碼？
有可能可以定製BitcoinToken，這樣就不必讓每個使用者在每個例項裡都執行程式碼。例如，token的發行方式受信任的。該發行方可以驗證所有token轉賬。如果使用者信任發行方，他們就不必驗證任何內容。這在需要低延遲或高吞吐量的應用中非常有用。在這個模型中，使用者只需檢查區塊鏈上是否存在轉賬，這會超級快。儘管一些使用者可以出於效率原因選擇信任發行方，但是其他使用者可以很容易稽核被信任的發行方。如果發行方欺詐，則會在區塊鏈上留下證據，並可以被其他使用者揭發。
24. 鑑於最近社群發生的事情，如果鏈分裂成多條，token會怎樣？在兩個鏈上都有效，還是說使用者需要選擇其中一個？
另一個好問題！BitcoinToken方案下，token就像比特幣一樣，會存在於兩個鏈上。
25. 存在一種攻擊情形：我發行一個程式碼中帶有無限迴圈的token。我將一個token傳送到一個地址。此地址的錢包服務提供商需要執行合約程式碼，因為他們希望向其使用者顯示任何收到的token。當錢包服務提供商執行程式碼時，它們會受到攻擊。錢包服務商如何避免此類攻擊？不說礦工受到攻擊，而是說錢包提供商受到攻擊。錢包服務商需要執行程式碼，是那種基於客戶端伺服器模型的輕錢包。
對於客戶端錢包，只有接收方必須執行程式碼，而不是錢包提供商。獲取令牌的使用者的計算機進入無限迴圈，生態系統的其餘部分不受影響。如果錢包在伺服器上，那麼伺服器可以設定一個時間限制並說：我們只執行在一秒鐘內終止的智慧合約。如果使用者想要執行計算成本更高的智慧合約，他將不得不使用客戶端錢包。
26. 如果在11月15日升級時比特幣現金出現拆分，那麼BitcoinToken會選擇哪種區塊鏈 ？（ 不要問你會選擇哪一方，只想從開發人員的角度知道哪個方向對比特幣更有前途）
我不認為比特幣現金足夠大，可以再次分叉並且兩個分叉都能存活下來。我會在那個倖存下來的鏈上。
如果在比特幣現金髮生分叉，我認為這將是災難性的。最大的問題是信任受到侵蝕。競爭總是存在的。
你們（指礦工，譯者注）恰恰是可以防止分叉的人。別讓他們分叉。如果我們沒有提前搞砸的話，我們可以將比特幣現金變成令人驚奇的東西。
27.oken數量如何被編碼，在轉賬輸出中的比特幣的數額裡，還是在轉賬輸出的其他部分？金額或ScriptPubKey？
token數量編碼在交易輸出中。令牌的所有者可以花費該輸出並將token傳送給另一個使用者。
那麼在輸數額裡，不在ScriptPubKey裡？
哦對不起。不是在satoshi數額裡。在ScriptPubKey裡（這裡應該是說在腳本里，譯者注）。
Clemens 對礦工的問題
Clemens Ley也對出席的礦工和開發人員提出了一些問題。個別與會者從他們自己的角度提供反饋。
1. 我可以請這個小組中的更多人評論他們對允許非標準指令碼的看法嗎？
Xiaohui ：我非常支援它，當然，必須找到一種確保安全的方法。
Edward ：我們確實需要非標準的指令碼。
linzheming ：在我看來，這將給錢包服務提供商帶來相當大的挑戰。我將密切關注這一進展。
Clemens回覆linzheming ：如果只允許我們用那一種非標指令碼，那對於錢包提供者來說會更容易實現。
2. 挖礦中的痛點/問題是什麼？
Jason ：其實現在並不太多。但是對於更大的塊，礦池需要協同工作以實現快速可靠的塊廣播。BCH的當前程式碼庫在交易事務及區塊的廣播方面無法處理壓力測試。
imcoddy ：我認為礦工們的競爭力不夠。從壓力測試來看，我認為有些礦池池可以在這部分做得更好。現在我看到Rawpool正在積極調查SV和ABC的好處，這對我來說是一個好兆頭。我們也擔心集中化，但我個人希望更多的礦工參與競爭並提供高可擴充套件性和服務，以使BCH成為真正的全球現金。
3. 採礦當前的瓶頸是什麼？也就是說，如果塊太大，軟體的哪一部分會出問題？
Jason ：我們已經設法在3月初使用比特幣ABC 0.17.1測試32MB塊。我們通過重構我們的礦池後端來為此做好準備。瓶頸是比特幣客戶端本身。它無法在測試中產生大塊。雖然有些礦池還沒有為大塊做好準備，但是修復他們的後端應該不是大問題。在壓力測試期間，通過觀察我們池中的不同節點，塊高度延遲達6分鐘。大多數節點的mempool大小差異超過10 MB。
程式只是崩潰？你是否看到一些有價值的錯誤資訊？
Jason ：沒有崩潰，但是塊的延遲很高。我想很多人都應該注意到 TX Highway 和 TxStreet 在壓力測試日的mempool大小的巨大差異 。轉賬沒有在BCH網路中順利廣播。我們所有節點都執行相同的比特幣ABC。我們需要進行更多測試和基準效能評測來形成一份精確的報告。現在，我只能通過觀察來說。
問題是驗證大塊需要太長時間嗎？
Jason ：不，驗證不是壓力測試中的瓶頸。許多節點甚至可能都沒有收到塊。在我們3月份測試32MB的過程中，我們模擬了一個300MB的mempool並挖掘了32MB的塊。區塊校驗在我們的測試中不是問題。但是，我們沒有測試驗證時的最差情況。
4. 您是否知道有人確定了塊驗證時間如何與塊大小一起縮放？也就是說，驗證大小為100kb，1mb，10mb的塊需要多長時間……
Jason ：目前，驗證時間與大小呈線性關係。由於我們每MB有sigop限制。傳送交易方面還有很大的提升空間。我們還沒有像比特幣中的 Fibre 這樣的東西。我們也願意在BCH上測試緊湊塊實現。
linzheming ：如果系統是無許可權的，我認為我們確實存在競爭，但我不知道比特幣的系統是否迫使我們更加集中化。
Lise ：Amaury之前告訴我，他們認為傳播和驗證比CTOR本身複雜得多。這就是他們試圖突破的目標。
5. 塊驗證時間與網路延遲相比如何？
Jason ：是的，現在32MB可能會有問題。但我們需要測試CTOR可以帶給我們多少收益以及是否還存在其他可能的解決方案？
6. 您對CTOR與TTOR有什麼看法？有沒有人進行實驗比較兩者？
imcoddy ：我認為Rawpool目前正在測試SV和ABC，他們已經與雙方的開發者聯絡。如果我們這次不急於推出CTOR，這次可能採取不升級策略嗎？我們現在可能不會有大於32 MB的巨大塊，但是新啟用的SV操作碼可能會導致分裂。
Jason ：我們願意進行測試。目前，SV和ABC在主鏈上完全相同。為我們提供測試用例會很有幫助。我承認我們缺乏與開發者的溝通。我們在最近的0.18公告中才知道了這一點。
Lise ：作為一個礦池，David和我都認為社群很有可能達成協議而不是分裂。雖然ABC和nChain似乎有相反的意見，但還有很多其他利益相關方在雙方支援更加實際的立場。例如，我剛剛翻譯了比特幣無限的Andrew Stone的一篇文章，他認為CTOR是一種不切實際的分片方式。一些團體表示他們支援CTOR，但也同意更大的塊。
Clemens ：我認為我們應該在兩者之間進行競爭。讓兩個團隊準備他們的解決方案，然後我們測量每個解決方案驗證不同大小的塊所需的時間。我將很樂意提供幫助。在做出類似的重要決定之前，我們至少需要一些資料。我個人認為絕對沒有必要急於求成。我們在比特幣現金中沒有擴容問題。我們知道現在的系統在目前還是有效的。如果我們要更改的話，我們應該非常確定我們在做什麼。
7. 您如何看待比特幣現金的現有token解決方案？您希望token解決方案有什麼功能？
linzheming ：我不太關注token解決方案，但我認為如果一個可信方能夠以非常低的成本發行token作為數字票證，它將會有很大幫助。
Edward ：我們需要智慧合約的token方案。BCH上已經有一些token方案了，但智慧合約方案不多。Wormhole ，Keoken和BitcoinToken是目前僅有的三種智慧合約解決方案。我們應該在這些解決方案中找到並選擇最強大，最簡單的一個。蟲洞現在已經可以發token了，智慧合約部分可能會在明年初上線。Keoken的token功能將在幾周後釋出，後續會增加智慧合約。@姜家志JZ 是蟲洞的主要開發者，我可以介紹你們認識。
8. 您是否願意擴充套件標準指令碼集或甚至允許所有指令碼？
linzheming ：我對開放所有指令碼沒有意見。我們可以看到我們可以用這些磚塊建造什麼。在此之前我甚至不知道邊界在哪裡。我認為關於比特幣指令碼的爭論最多的是無狀態的性質。
imcoddy ：我認為我們還沒有完全理解比特幣能做什麼，腳本系統是個等待著人們去挖掘的隱藏寶藏。我個人認為，作為金錢，它需要穩定，問題在於腳本系統是否足以讓人們在其上構建東西。BitcoinToken是一個很好的嘗試，但我們確實需要更友好的工具來幫助開發人員更快地製作應用程式。我並不反對在基礎層上新增更多內容，但我們需要知道協議的每次修改的優缺點，這真正需要更多的測試和良好的處理。
翻譯：Andy、linzheming
校對：老劉
AMA主持：邱少賢
英文原文采訪內容整理：老劉
歡迎關注微信公眾號：閃電HSL
歡迎打賞BTM：bm1qefc720au672awrgazgw5c3kx7etr5kejju02p7
版權宣告： 
作者保留權利。文章為作者獨立觀點，不代表巴位元立場。