世界太新，用手去指。 ～～賈西亞•馬奎茲
我一直希望對於區塊鏈的某些技術細節，能有更深一層的了解，多於看百科層級的解說，而止於非技術人能夠理解的程度。Anton是一個蠻認真吸收技術新知的年輕人，於是我找了他一起合作，希望能一起找出有助於更多人理解這個區塊鏈新世界基礎的題目，主要由他來執筆，帶大家一起學習，一起用手去指。
State - 從宏觀到微觀：以太坊如何將智能合約帶入區塊鏈世界
前言 by 
前幾天劉美女發表的一篇文章 Art of STATE討論「狀態」的意義，今天這裡我們用一個比較不同的角度再來看看State，從比特幣UTXO模型以及以太幣Account-based模型對於宏觀State的紀錄，到智能合約的執行環境討論。
區塊鏈與宏觀的State
區塊鏈想做的，便是一個分散式的系統，這個系統紀錄了一個Global State，並且透過一個共識協議不斷更新，而這個State是全世界節點都能夠達成共識的。
如同劉美女所說的，可以將State看成一個對時間的函數：S(t) 指的是在t時間點區塊鏈的狀態，而S(t+1)就是下一秒的區塊鏈狀態。在許多討論中，也常常是以「每一筆交易」為單位在描述State：一個狀態S[i]在發生了任一個交易TX[i]之後，整個區塊鏈的狀態也會有些改變，成為S[i+1]：S[i+1] = APPLY(S[i],TX[i])，會這麼表示是為了要表達一個節點在驗證一個區塊時，需要一筆交易一筆交易去改變State。
UTXO模型中的State
比特幣所使用的UTXO模型其實不是一種直觀的紀錄方式；在比特幣的世界裡，它只紀錄了所有的歷史交易條目：在確認一筆交易是否合法前，一個節點需要要驗證每一個Input來源Unspent Transaction Output是否真的存在，也就是要回頭看從創世到現在以來的每一筆交易，找到確實有這一筆可以拿來花費的Output。在這樣的模型中並沒有所謂「帳戶」概念，並不能像銀行一樣，直接從一個帳戶檢查餘額，然後輕易判斷交易有效性。
在比特幣的世界中，如果你要說他也有個「狀態」的話，沒錯，它的State就是從創世區塊到現在所有交易的集合。但是由於沒有一個物件隨時紀錄這個區塊鏈整體狀態的物件，而且一個UTXO交易只有Spent 和 Upspent兩種狀態，無法表達其他任何其他狀態資訊，因此有許多人稱UTXO為Stateless。所以對於State的討論也是宏觀微觀之分的，大家可別搞混了呀！（我就是一直被這個搞混Orz）
以太坊的變革
以太坊的問世最重要的特點就是帶來了「帳戶」。它對每一個帳戶有了持續的紀錄，因次被稱為Account-based區塊鏈，也是一個較好描述區塊鏈狀態的模型。以太坊的State就是由滿滿的帳戶所組成，State的轉變其實也就只是帳戶之間訊息、轉帳的傳遞罷了。
帳戶 (Account) 與交易(Transaction)
為了進一步了解ETH帳戶模型的運作，我們要先了解帳戶以及交易(Transaction)的意義。在ETH中，帳戶又分為了個人帳戶(externally owned accounts)以及合約帳戶(contract accounts)：
- 個人帳戶：簡單的說，就是每個人透過私鑰控制，能夠存錢、送錢的私人錢包。
- 合約帳戶：不同於個人帳戶，合約帳戶是受到智能合約(Smart Contract)控制。實質上他就是擁有
Contract Code(合約程式)以及Storage(儲存空間)的帳戶，如果一個帳戶含有Contract Code，它就是一個智能合約地址，可以透過交易(transaction)來trigger，並且每次被啟動時按照合約內容執行。
其中「交易」特別指的是由個人帳戶所送出的簽名封包，可以是純粹的轉帳，也可以是拿來啟動智能合約的Function call。
State Transition Function
接著我們來看看，當一個Transaction發生時，整個State的變動過程。
(Image Source: Ethereum Whitepaper)
如果我們把左邊的State稱做S，經過交易TX之後變成S'，這個過程可以想像成一個APPLY函數：APPLY(S, TX) -> S'，而APPLY的運作流程如下：
- 檢查交易資訊是否完整:簽名是否有效、
nonce(交易計數器)是否與帳戶紀錄相符。 - 計算所需要的transaction fee =
GASPRICE * STARTGAS，從發送者帳下扣除該比fee費用。 - 初始化參數
GAS=STARTGAS，再隨者交易每一步扣除GAS數量。 - 如果是一般交易，將發送者帳下的ETH轉到接收者帳下；若目標帳戶不存在，就創造一個新的帳戶。如果是合約交易，則運行智能合約的內容，直到合約結束或是GAS用完。如果發送交易者沒有足夠餘額或是GAS用完，則回傳
ERROR，並且回溯剛剛的State改變，但是已經付出的交易手續費將一樣付給礦工。 - 如果交易成功且有剩餘GAS則還給發送者。
區塊驗證
在我們了解一筆交易對State的改變過程之後，區塊驗證的過程也變得較容易理解：在整個節點要驗證一個區塊時，需要驗證許多筆的交易，所以State的改變就會如下圖一樣，在每一個block的驗證過程都是一系列的交易驗證以及狀態改變。
因此在ETH的每一個block中，除了包含的交易列表外，還有一個Global State紀錄所有帳戶的餘額狀態。乍看之下，這個方法似乎很沒效率，因為State是一筆很大的資料，每次紀錄時其實有絕大部分的帳號餘額是沒有變動的。但是實際上在一個節點的運作中，它只要保留最新的State，而State是透過Patricia tree這種易於增加、修改、刪除的樹狀結構來儲存的，因此在實際執行上並不是很大的負擔。
Account Based 的優勢
驗證程序簡化
儘管一個Full-Node會記下每一個區塊的交易紀錄，但是在驗證一個新的區塊時，它只需要觀察最新的State並從中獲取所需的資料即可，存下的交易細目只是為了查詢而已，並不會參與驗證，因此驗證是比較單純的，不像UTXO模型中需要「溯及既往」。
智能合約變得可行
透過帳戶的方式管理合約，讓開發以及應用上都變得直觀。一個「合約帳戶」可以擁有自己的變數、Storage並透過智能合約來管理。如果沒有Account這個東西，我們連合約要放在哪裡都想像不出來了。如果沒有一個State存下了每個時刻「合約」的內容物以及狀態，那麼每次執行合約都要從頭跑過一遍才知道現在的狀態，顯然是不合理的，智能合約都變智障合約了。
圖靈完備(Turing-Completeness)
其實在比特幣的區塊鏈中也是有Scripting的，每一個交易的驗證都牽扯了簽名的驗證，這其實就是一個簡單的程式碼運行。但我們不會說比特幣是一個能夠運行智能合約的平台，因為比特幣的運算也不具有圖靈完備(Turing-Completeness)的性質。
圖靈完備指的是一台電腦或是狀態機(State Machine)擁有模擬圖靈機(Turing Machine)的運算規則或是程式語言；簡而言之就是擁有成為電腦的運算能力（這裡的運算能力只的並不是運算速度效能，而是能夠在有限時間內達成一台電腦能做的所有操作）。但在UTXO的Script當中，是不會允許迴圈(loop)存在的，因為迴圈的存在代表著有行程無限迴圈的風險，也就是一個永遠不會停下的合約。
那麼在ETH中為什麼可以避免無限迴圈呢？這就是GAS被設計出來的目的。當一筆交易要發起時，發送者需要先付出fee來付給幫忙運算的礦工，而每一步運算都要花費一定量的GAS，如果你的GAS用完了，那麼合約就會終止，不完整的State變化也會回溯。這麼做的好處顯而易見：避免惡意的攻擊以及落實使用者付費原則，讓所有人願意節省網路共同用算資源。有了GAS的限制後，ETH上的智能合約開發變可以支援一個圖零完備的執行環境了。
UTXO: Value Blindness
UTXO模型另一個缺點是他沒辦法有效的處理「Value」。在Account Based的世界中，只要我們錢夠多，我們可以轉任意數量的ETH給另一個帳戶。但在UTXO中我們不能只指定轉帳數量，我們需要找到足夠的Input，並且「湊」出我們的Output，這使任何牽扯到值變化的步驟都大大的複雜化。
State 的重要性
如同上面提過的，這是最重要的性質之一。在UTXO中沒有State紀錄每個帳戶的狀態，除了每次執行合約前都要從頭來過執行所有歷史紀錄以獲得初始狀態以外，在每次執行合約過程中，因為UTXO只有Spent和Unspent兩種狀態，因此沒有辦法紀錄任何複雜的合約執行過程。
所以看到這裡，知道帳戶模型的厲害了吧！
利用Account Based的方式紀錄區塊鏈的State訊息，不但一石二鳥地有效紀錄了「宏觀區塊狀態」到「微觀合約執行內容」等等資訊，也更有效率地儲存了整個區塊鏈資訊、也簡化驗證過程。
其實UTXO仍然有這一些不錯的性質，例如可以平行處理多筆交易，使得有些新興區塊鏈底層仍然選擇使用UTXO，例如Qtum就是利用新的Value Transfer Protocal來在UTXO上面實踐智能合約(至於細節嘛...我還不是很了解)。所以，雖然說Account Based是將區塊鏈帶入智能合約時代不可否認的大功臣，但究竟哪個model會在未來的戰場上勝出，還是不好說的呀！是創新的UTXO厲害還是Account Based厲害就只能說見仁見智了！
無論如何，對於把這重大變革帶進區塊鏈世界的小神童Vitalik，還是受我一拜吧！
(Image Source: 香港矽谷網站)
最後，謝謝各位囉～
這是我與劉美女第一次合作，文章可能會被更多人看很緊張阿 ><。如果有任何要批評指教或是內容錯誤，或是希望未來我們討論什麼比較技術面的話題，還請不吝指教與提出喔！謝謝收看，下次再見！