@liwi 19 December 2021 more from that month

在繼續了解 BCH 交易格式的過程裡發現了這篇 阿姆斯特丹大學的碩士論文 Rosco Kalis, CashScript: A high-level language for Bitcoin Cash Script https://staff.fnwi.uva.nl/a.s.z.belloum/MSctheses/MScthesis_Rosco_Kalis.pdf 大意就是雖然並非圖靈完備，BTC / BCH 也都具有實現（簡易）智能合約的架構。但要直接用 Script 打 code 實在很痛苦（作者類比為組合語言；可是我覺得寫 ASM 並不會很痛苦阿），所以有高階轉換語言的存在。而因為這些既有高階轉換語言有所缺陷，所以作者弄了一個 CashScript，設計理念包括盡量貼近 ETH 的 workflow，並找了六個碼農來實作測試。從碼農背景介紹那邊可以看出來，ETH / JavaScript 幾乎是部屬智能合約同時需要的技能。 結語的部分作者認為 BCH 比 BTC 更適合部屬智能合約。 那你大概也注意到了，作者在論文裡也留了 bitcoin.com 的 email。 作者在網路上看來也是蠻公開活躍的， 個人網站 https://kalis.me/about/ CashScript https://cashscript.org/ 雖然這一來並沒有直接打中我現在卡關的（落後）問題，二來現在也有了 EVM 相容的 SmartBCH，所以 CashScript 的重要性尚待價而沽，但總之是蠻有趣的，而在學術界邊際條件下寫下來的論文整理也應有較為嚴謹的參考價值。 交易格式的部分我已知用火的注意到現在同時有 0x01 跟 0x02 版本併行在區塊鏈上。而之前分享過了，V3 的計畫書已經出來了，倡議希望在 2022 五月採行。 https://github.com/bitjson/pmv3 大家會覺得過橋走 EVM 的 SmartBCH 路線比較好呢，還是鐵桿子 BCH native 智能合約比較好？這兩者不見得是互斥的，而作為一個去中心化的存在，在既有共識的框架下大家想怎麼玩都可以，雖然歷史告訴我們，硬分叉也是會（不斷）發生的... 兩者並行也或許反而是好的。有些應用需要較高的嚴謹度魯棒性，而有些應用則想要較高的自由度與圖靈完備性，而工程學上魚與熊掌往往不可兼得，所以就各取所需了。當然經歷這回的手作探討，也會覺得社群分化除了導致開發力量分散以外也導致了技術文件規格混亂，後人想追起來變得更是困難重重。去中心化與效率，也是另一對魚與熊掌。