區塊鏈技術漫談

自2008年Satoshi Nakamoto發表比特幣技術論文至今，區塊鏈也走了十年之久，暫且拋開加密貨幣等區塊鏈應用是否真能落實不談，區塊鏈在技術上累積的生態，確實頗有可觀之處。

走入區塊鏈的技術應用

任何一門技術能走過十年之久，必然充滿著許多名詞，對於從未接觸過區塊鏈的開發者來說，嘗試觀摩、實作個基本微鏈，就會遇上區塊定義、交易、共識演算、挖礦等名詞，之後，還有支持區塊鏈2.0、3.0概念的各種技術與工具鏈必須認識。單從網路上零散的文件中，試圖釐清這諸多名詞之間的關係，往往只會更令人感到困惑。

若想歷史演進的順序來認識相關的名詞與原理，可以參考《白話區塊鏈》，其中也有關於區塊鏈基本原理的介紹，像是區塊雜湊、加密演算等，可以讓我們認識到，何以區塊鏈具有去中心化、難以竄改、匿名等特性，亦可從加密貨幣的分岔等事件上，認識到區塊鏈的限制等問題。

在認識比特幣的基本原理後，作為一名開發者，可以自行實作個簡單的區塊鏈，這有助於進一步驗證與應用相關原理。關於這部份，我們可參考〈Python Blockchain App〉（https://bit.ly/2I74Evz）或〈Learn Blockchains by Building One〉（https://bit.ly/2fOQsqt），如果你也需要Java方面的實例，可以參考〈Creating Your First Blockchain with Java〉系列（https://bit.ly/2Jazn7x）。

下一步，你也許會想要嘗試挖礦。別想用個人電腦挖掘那些主流的加密貨幣，因為幾乎不可能搶到區塊打包權（加入礦池嘗不到什麼甜頭，就技術學習而言，也無意義），不如試著建個私鏈。

相對來說，以太坊是個不錯的開始。例如，我們可以透過Go語言實作的Geth，來建立私鏈、進行挖礦，然後，試著用Ethereum Wallet做轉帳交易，從中認識一下區塊鏈、挖礦、錢包之間的關係。

然後，可以認識一下Solidity這門合約導向語言，在以太坊上，試著撰寫、部署合約，做些函式呼叫交易之類，甚至進一步基於以太坊ERC-20協議，自己造個ERC-20相容加密貨，或者在瀏覽器試著裝個MetaMask，試著連上自架的私鏈，在自造的加密貨幣上，做些交易。

接下來，要不要繼續玩TestRPC、Truffle，或者更進一步地試試Fabric之類的Hyperledger框架，就是看個人興趣了。不得不說的是，「2019 iT 邦幫忙鐵人賽」下，有不少區塊鏈的文件，可以輔助大家認識區塊鏈的相關主題。

區塊鏈與演算法

就開發者而言，研究區塊鏈技術最大的收穫，應該是接觸到加密、共識等演算法之運用，建議大家不妨深入研究一下實際的演算原理。

以加密演算來說，雖然概念上主要是公開金鑰加密（非對稱式加密），需要有成對的私鑰與公鑰，然而，透過其中一把金鑰加密，必須透過對應的另一金鑰解密，不過，像比特幣使用的SECP256k1是怎麼回事呢？為什麼不是使用RSA演算？

就像在《改變世界的九大演算法》中第4章〈公鑰加密〉，是從混漆法開始談起，說明如何在可聽到對話的第三者存在下，令其無法得知配方又能混出相同的油漆。實際運用於電腦加密時，則是需要有個像是混漆方式，易於計算、但又幾乎不可能還原的演算，而九大演算法介紹了鐘算法，進一步談到了「迪菲-赫爾曼金鑰交換」，但比特幣使用的不是鐘算法，而是基於橢圓曲線數學的橢圓曲線密碼學，相關參數定義為SECP256k1。

這時，私鑰用來產生公鑰，公鑰用來產生比特幣位址，因此，遺失了私鑰就幾乎不可能解密區塊鏈上的資料，這也就是為什麼明明區塊鏈資料存在於各個節點，卻偶有新聞報導，有人因為遺失了私鑰，而使得鉅額的加密貨幣就此鎖死。

此外，參與區塊鏈的各節點，可能出錯或失效，對於最後要由哪個節點來打包交易、寫入區塊的這個問題，正如拜占庭帝國的將軍們共同圍困一座城市，在可能存在反叛者的情況下，對於要進攻或撤離的決策，將軍間如何取得共識。而面對這類拜占庭將軍問題，主要是由共識演算法來解決。

比特幣採用工作量證明（Proof-of-Work），然而對區塊鏈應用來說，耗費大量運算能力並非必要（發幣獎勵也不是必須）。例如，以太坊採用不需耗費大量運算的股份證明（Proof of Stake），Fabric提供solo（單節點排序，用於開發測試）、kafka（多數決）和PBFT（開發中，採三階段協議）等模式。若能認識這些共識演算，就等同於認識了不同的應用情境，這也會是研究區塊鏈的收穫之一。

區塊鏈與時間軸

談到區塊鏈真正的落實應用，各方人馬總有不同想像，例如，基於去中心化（權利解放）、點對點（流程簡化）、匿名性（估且不論法幣兌換、投票時往往還是需要有個身分）等，構築出未來。

然而，在我的想法中，區塊鏈在應用時，主要必須考慮到與時間軸結合的優缺點，也就是如同時間是不停地前進，發生的事情就發生了，你改變不了，而以太坊上的#metoo交易（https://bit.ly/2qUu842）就是成功的應用案例之一（這世界不再有404）。

對於回到時間軸的過去，科學界存在著平行世界之說，而對於區塊鏈來說，試圖回溯曾經發生的交易，則會令區塊鏈產生分岔。

關於區塊鏈的分岔，最著名的案例，就是以太坊上的TheDAO漏洞事件（https://bit.ly/2SsOzVP）。為了奪回被攻擊者轉移的以太幣，在2016年7月，以太幣官方強行分出一條被盜前狀態的區塊鏈，也造成了今日有ETC、ETH兩個分岔，而分岔之後，原鏈依舊是存在的，至於選擇原鏈或新錄，變成了是否堅持「區塊鏈不可竄改（就算有了違法之類的交易）」的價值觀問題。

不可竄改這件事，對部署至區塊鏈的合約也是相同，區塊鏈上無法更新既有合約來修正臭蟲或新增功能。至於一些談及可更新（Upgradable）合約的文件，基本上，是從分離邏輯與資料、代理等技巧（或說是模式），適當地拆分合約元件，若真的有修正臭蟲等需求之時，可透過儘量只部署小部份的「新」合約元件來達成。

這意謂著雖然有著EOS這類合約平臺，但在設計、測試、部署、更新等各方面，區塊鏈上的分散式應用程式（DApp），從一開始就與開發者過往習慣的平臺應用程式不同。而關於這方面的經驗，實際上還處於模索階段，可更新合約的技巧，也是各有利弊，有興趣的話，可以參考〈Contract upgrade anti-patterns〉（https://bit.ly/2N1eaiz）。

開發工具鏈

就幾個區塊鏈工具生態來說，圍繞著以太坊的工具鏈，相對來說是比較建全的。而在合約開發上，也有著Remix這個Solidity前端整合開發環境。雖說如此，在試著將相關工具結合在一起時，還是需要不少功夫與一定的經驗來摸索，這突顯了工具之間的整合，還是處於較為陽春的階段。

在大廠支援的部份，IBM、Google、Amazon、微軟、甲骨文等，都提出或多或少的開發套件，一整個看來十分熱鬧，就像在為區塊鏈背書一樣。從這點來看，無論區塊鏈本身的落地應用是否能真正到來，就技術層面來說，其相關技術在區塊鏈之外，也應當會有其應用的時機與場合。