熱點欄目
按：2008年10月31日，中本聰（Satoshi Nakamoto）在P2P foundation網站發布比特幣白皮書《比特幣：一種點對點的電子現金系統》。
作者：中本聰；譯者：李笑來
概要：一個純粹的點對點版本的電子現金系統，將允許在线支付直接從一方發送到另一方，而無需通過金融機構。數字籤名雖然提供了部分解決方案，但，若是仍然需要被信任的第三方來防止雙重支出的話，那么電子支付的主要優勢就被抵消了。我們提出一個方案，使用點對點網絡去解決雙重支出問題。點對點網絡將爲每筆交易標記時間戳，方法是：把交易的散列數據錄入一個不斷延展的、以散列爲基礎的工作證明鏈上，形成一個如非完全重做就不可能改變的記錄。最長鏈，一方面用來證明已被見證的事件及其順序，與此同時，也用來證明它來自於最大的 CPU 算力池。只要絕大多數 CPU 算力被良性節點控制 —— 即，它們不與那些嘗試攻擊網絡的節點合作 —— 那么，良性節點將會生成最長鏈，並且在速度上超過攻擊者。這個網絡本身需要最小化的結構。信息將以最大努力爲基本去傳播，節點來去自由；但，加入之時總是需要接受最長的工作證明鏈作爲它們未參與期間所發生之一切的證明。
互聯網商業幾乎完全依賴金融機構作爲可信第三方去處理電子支付。雖然針對大多數交易來說，這個系統還算不錯，但，它仍然被基於信任的模型所固有的缺陷所拖累。完全不可逆轉的交易實際上並不可能，因爲金融機構不能避免仲裁爭議。仲裁成本增加了交易成本，進而限制了最小可能交易的規模，且幹脆阻止了很多小額支付交易。除此之外，還有更大的成本：系統無法爲那些不可逆的服務提供不可逆的支付。逆轉的可能性，造成了對於信任的需求無所不在。商家必須提防着他們的顧客，麻煩顧客提供若非如此（如若信任）就並不必要的更多信息。一定比例的欺詐，被認爲是不可避免的。這些成本和支付不確定性，雖然在人與人之間直接使用物理貨幣支付的時候是可以避免的；但，沒有任何一個機制能在雙方在其中一方不被信任的情況下通過溝通渠道進行支付。
我們真正需要的是一種基於加密證明而非基於信任的電子支付系統，允許任意雙方在不需要信任第三方的情況下直接交易。算力保障的不可逆轉交易能幫助賣家不被欺詐，而保護买家的日常擔保機制也很容易實現。在本論文中，我們將提出一種針對雙重支出的解決方案，使用點對點的、分布式的時間戳服務器去生成基於算力的證明，按照時間順序記錄每條交易。此系統是安全的，只要誠實節點總體上相對於相互合作的攻擊者掌握更多的 CPU 算力。
我們將一枚電子硬幣定義爲一個數字籤名鏈。一位所有者將一枚硬幣交給另一個人的時候，要通過在這個數字籤名鏈的末尾附加上以下數字籤名：上一筆交易的哈希（hash，音譯，亦翻譯爲“散列值”），以及新所有者的公鑰。收款人可以通過驗證籤名去驗證數字籤名鏈的所屬權。
這個路徑的問題在於收款人無法驗證曾經的所有者之中沒有人雙重支付過。常見的解決方案是引入一個可信的中心化權威方，或稱“鑄幣廠”，讓它去檢查每一筆交易是否存在雙重支付。每一次發生交易之後，硬幣必須返回到鑄幣廠，鑄幣廠再發行一枚新的硬幣。進而，只有鑄幣廠直接發行的硬幣才是可信的、未被雙重支付過的。這個解決方案的問題在於，整個貨幣系統的命運被拴在運營鑄幣廠的那個公司（就好像銀行那樣）身上，每一筆交易必須通過它。
我們需要一種方式，可以讓收款人確認之前的所有者並沒有在任何之前的交易上籤名。就我們的目的而言，只有最早的交易是算數的，所以，我們並不關心其後的雙重支付企圖。確認一筆交易不存在的唯一方法是獲悉所有的交易。在鑄幣廠模型之中，鑄幣廠已然知悉所有的交易，並且能夠確認這些交易的順序。爲了能在沒有“被信任的一方”參與的情況下完成以上任務，交易記錄必須被公开宣布1，進而我們需要一個系統能讓參與者們認同它們所接收到的同一個唯一的交易歷史。收款人需要證明在每筆交易發生之時，大多數節點能夠認同它是第一個被接收的。
本解決方案起步於一種時間戳服務器。時間戳服務器是這樣工作的：爲一組（block）記錄（items）的哈希打上時間戳，而後把哈希廣播出去，就好像一份報紙所做的那樣，或者像是在新聞組（Usenet）裏的一個帖子那樣2345。顯然，時間戳能夠證明那數據在那個時間點之前已然存在，否則那哈希也就無法生成。每個時間戳在其哈希中包含着之前的時間戳，因此構成了一個鏈；每一個新的時間戳被添加到之前的時間戳之後。
爲了實現一個基於點對點的分布式時間戳服務器，我們需要使用類似亞當·伯克的哈希現金6那樣的一個工作證明系統，而不是報紙或者新聞組帖子那樣的東西。所謂的工作證明，就是去尋找一個數值；這個數值要滿足以下條件：爲它提取散列數值之後 —— 例如使用 SHA-256 計算散列數值 —— 這個散列數值必須以一定數量的 0 开頭。每增加一個 0 的要求，將使得工作量指數級增加，並且，這個工作量的驗證卻只需通過計算一個哈希。
在我們的時間戳網絡中，我們是這樣實現工作證明的：不斷在區塊之中增加一個隨機數（Nonce），直到一個滿足條件的數值被找到；這個條件就是，這個區塊的哈希以指定數量的 0 开頭。一旦 CPU 的耗費算力所獲的的結果滿足工作證明，那么這個區塊將不再能被更改，除非重新完成之前的所有工作量。隨着新的區塊不斷被添加進來，改變當前區塊即意味着說要重新完成所有其後區塊的工作。
工作證明同時解決了如何決定誰能代表大多數做決定的問題。如果所謂的“大多數”是基於“一個IP地址一票”的方式決定的話，那么任何一個可以搞定很多 IP 地址的人就可以被認爲是“大多數”。工作證明本質上來看，是“一個CPU一票”。所謂的“大多數決定”是由最長鏈所代表的，因爲被投入最多工作的鏈就是它。如果大多數 CPU 算力被誠實的節點所控制，那么誠實鏈成長最爲迅速，其速度會遠超其他競爭鏈。爲了更改一個已經產生的區塊，攻擊者將不得不重新完成那個區塊以及所有其後區塊的的工作證明，而後還要追上並超過誠實節點的工作。後文展示爲什么一個被拖延了的攻擊者能夠追上的可能性將隨着區塊的不斷增加而指數級降低。
爲了應對硬件算力綜合的不斷增加，以及隨着時間推進可能產生的節點參與數量變化，工作證明難度由此決定：基於平均每小時產生的區塊數量的一個移動平均值。如果區塊生成得過快，那么難度將會增加。
運行網絡的步驟如下：
節點始終認爲最長鏈是正確的那個，且會不斷向其添加新數據。若是有兩個節點同時向網絡廣播了兩個不同版本的“下一個區塊”，有些節點會先接收到其中一個，而另外一些節點會先接收到另外一個。這種情況下，節點將在它們先接收到的那個區塊上繼續工作，但也會把另外一個分支保存下來，以防後者成爲最長鏈。當下一個工作證明被找到，而其中的一個分支成爲更長的鏈之後，這個暫時的分歧會被打消，在另外一個分支上工作的節點們會切換到更長的鏈上。
新的交易不見得一定要廣播到達所有的節點。只要到達足夠多的節點，那么沒多久這些交易就會被打包進一個區塊。區塊廣播也容許一些消息被丟棄。如果一個節點並未接收到某個區塊，那么這個節點會在它接收到下一個區塊的時候意識到自己錯失了之前的區塊，因此會發出補充那個遺失區塊的請求。
按照約定，每個區塊的第一筆交易是一個特殊的交易，它會生成一枚新的硬幣，所屬權是這個區塊的生成者。這么做，使得節點支持網絡有所獎勵，也提供了一種將硬幣發行到流通之中的方式 —— 在這個系統中，反正也沒有一個中心化的權威方去發行那些硬幣。如此這般穩定地增加一定數量的新硬幣進入流通，就好像是黃金开採者不斷耗用他們的資源往流通之中增加黃金一樣。在我們的系統中，被耗用的資源是 CPU 工作時間和它們所用的電力。
獎勵還可以來自交易費用。如果一筆交易的輸出值小於它的輸入值，那么其中的差額就是交易費；而該交易費就是用來獎勵節點把該交易打包進此區塊的。一旦既定數量的硬幣已經進入流通，那么獎勵將全面交由交易手續費來完成，且絕對不會有通貨膨脹。
獎勵機制也可能會鼓勵節點保持誠實。如果一個貪婪的攻擊者能夠網羅比所有誠實節點都更多的 CPU 算力，他必須做出一個選擇：是用這些算力通過把自己花出去的錢偷回來去欺騙別人呢？還是用這些算力去生成新的硬幣？他應該能夠發現按照規則行事是更劃算的，當前規則使得他能夠獲得比所有其他人加起來都更多的硬幣，這顯然比暗中摧毀系統並使自己的財富化爲虛無更劃算。
如果一枚硬幣最近發生的交易發生在足夠多的區塊之前，那么，這筆交易之前該硬幣的花銷交易記錄可以被丟棄 —— 目的是爲了節省磁盤空間。爲了在不破壞該區塊的哈希的前提下實現此功能，交易記錄的哈希將被納入一個 Merkle 樹之中，而只有樹根被納入該區塊的哈希之中。通過砍掉樹枝方法，老區塊即可被壓縮。內部的哈希並不需要被保存。
一個沒有任何交易記錄的區塊頭大約是 80 個字節。假設每十分鐘產生一個區塊，80 字節乘以 6 乘以 24 乘以 365，等於每年 4.2M。截止 2008 年，大多數在售的計算機配有 2GB 內存，而按照摩爾定律的預測，每年會增加 1.2 GB，即便是區塊頭必須存儲在內存之中也不會是什么問題。
即便不用運行一個完整網絡節點也有可能確認支付。用戶只需要有一份擁有工作證明的最長鏈的區塊頭拷貝 —— 他可以通過查詢在线節點確認自己擁有的確實來自最長鏈 —— 而後獲取 Merkle 樹的樹枝節點，進而連接到這個區塊被打上時間戳時的交易。用戶並不能自己檢查交易，但，通過連接到鏈上的某個地方，他可以看到某個網絡節點已經接受了這個交易，而此後加進來的區塊進一步確認了網絡已經接受了此筆交易。
只要誠實節點依然在掌控網絡，如此這般，驗證即爲可靠的。然而，如果網絡被攻擊者所控制的時候，驗證就沒那么可靠了。盡管網絡節點可以自己驗證交易記錄，但是，只要攻擊者能夠繼續控制網絡的話，那么簡化版驗證方式可能會被攻擊者僞造的交易記錄所欺騙。應對策略之一是，客戶端軟件要接受來自網絡節點的警告。當網絡節點發現無效區塊的時候，即發出警報，在用戶的軟件上彈出通知，告知用戶下載完整區塊，警告用戶確認交易一致性。那些有高頻收付發生的商家應該仍然希望運行屬於自己的完整節點，以此保證更獨立的安全性和更快的交易確認。
盡管逐個地處理硬幣是可能的，但爲每分錢設置一個單獨的記錄是很笨拙的。爲了允許價值的分割與合並，交易記錄包含多個輸入和輸出。一般情況下，要么是一個單獨的來自於一個相對大的之前的交易的輸入，要么是很多個輸入來自於更小金額的組合；與此同時，最多有兩個輸出：一個是支付（指向收款方），如果必要的話，另外一個是找零（指向發款方）。
值得注意的是，“扇出”在這裏並不是問題 —— 所謂“扇出”，就是指一筆交易依賴於數筆交易，且這些交易又依賴於更多筆交易。從來就沒有必要去提取任何一筆交易的完整獨立的歷史拷貝。
傳統的銀行模型通過限制他人獲取交易者和可信第三方的信息而達成一定程度的隱私保護。出於對將所有交易記錄公开的需求否決了這種方法。但是，維持隱私可通過於另一處的切斷信息流來實現——公鑰匿名。公衆可以看到某某向某某轉账了一定的金額，但是，沒有任何信息指向某個確定的人。這種水平的信息發布有點像股市交易，只有時間和各個交易的金額被公布，但是，沒有人知道交易雙方都是誰。
還有另外一層防火牆。交易者應該針對每一筆交易啓用一對新的公私鑰，以便他人無法將這些交易追溯到同一個所有者身上。有些多輸入的交易依然難免被追溯，因爲那些輸入必然會被識別出來自於同一個所有者。危險在於，如果一個公鑰的所有者被曝光之後，與之相關的所有其他交易都會被曝光。
假設一個場景，某個攻擊者正在試圖生成一個比誠實鏈更快的替代鏈。就算他成功了，也不能對系統做任意的修改，即，他不可能憑空制造出價值，也無法獲取從未屬於他的錢。網絡節點不會把一筆無效交易當作支付，而誠實節點也永遠不會接受一個包含這種支付的區塊。攻擊者最多只能修改屬於他自己的交易，進而試圖取回他已經花出去的錢。
誠實鏈和攻擊者之間的競爭可以用二項式隨機漫步來描述。成功事件是誠實鏈剛剛被添加了一個新的區塊，使得它的優勢增加了 1；而失敗事件是攻擊者的鏈剛剛被增加了一個新的區塊，使得誠實鏈的優勢減少了 1。
攻擊者能夠從落後局面追平的概率類似於賭徒破產問題。假設，一個拿着無限籌碼的賭徒，從虧空开始，允許他賭無限次，目標是填補上已有的虧空。我們能算出他最終能填補虧空的概率，也就是攻擊者能夠趕上誠實鏈的概率，如下：
既然我們已經假定p>，q 既然攻擊者需要趕超的區塊數量越來越多，那么其成功概率就會指數級下降。於贏面不利時，如果攻擊者沒有在起初就能幸運地向前猛跨一步，那么他的勝率將在他進一步落後的同時消弭殆盡。
現在考慮一下一筆新交易的收款人需要等多久才能充分確定發款人不能更改這筆交易。我們假定發款人是個攻擊者，妄圖讓收款人在一段時間裏相信他已經支付對付款項，隨後將這筆錢再轉回給自己。發生這種情況時，收款人當然會收到警告，但發款人希望那時木已成舟。
收款人生成了一對新的公私鑰，而後在籤署之前不久將公鑰告知發款人。這樣可以防止一種情形：發款人提前通過連續運算去准備一條鏈上的區塊，並且只要有足夠的運氣就會足夠領先，直到那時再執行交易。一旦款項已被發出，那個不誠實的發款人开始祕密地在另一條平行鏈上开工，試圖在其中加入一個反向版本的交易。
收款人等到此筆交易被打包進區塊，並已經有z個區塊隨後被加入。他並不知道攻擊者的工作進展究竟如何，但是可以假定誠實區塊在每個區塊生成過程中耗費的平均時間；攻擊者的潛在進展符合泊松分布，其期望值爲：
爲了算出攻擊者依然可以趕上的概率，我們要把攻擊者需要追趕的區塊數目的帕松分布概率密度，乘以在落後該區塊數目下能夠追上來的概率：
轉換爲 C 語言程序……
獲取部分結果，我們可以看到概率隨着z的增加指數級下降：
若是 P 小於 0.1%……
我們提出了一個不必依賴信任的電子交易系統；起點是一個普通的使用數字籤名的硬幣框架开始，雖然它提供了健壯的所有權控制，卻無法避免雙重支付。爲了解決這個問題，我們提出一個使用工作證明機制的點對點網絡去記錄一個公开的交易記錄歷史，只要誠實節點能夠控制大多數 CPU 算力，那么攻擊者就僅從算力方面就不可能成功篡改系統。這個網絡的健壯在於它的無結構的簡單。節點們可以在很少協同的情況下瞬間同時工作。它們甚至不需要被辨認，因爲消息的路徑並非取決於特定的終點；消息只需要被以最大努力爲基本去傳播即可。節點來去自由，重新加入時，只需要接受工作證明鏈，作爲它們離线之時所發生之一切的證明。它們通過它們的 CPU 算力投票，通過不斷爲鏈添加新的有效區塊、拒絕無效區塊，去表示它們對有效交易的接受與否。任何必要的規則和獎勵都可以通過這個共識機制來強制實施。
海量資訊、精准解讀，盡在新浪財經APP
責任編輯：張靖笛
標題：16周年經典重讀：比特幣白皮書中文版全文
地址：https://www.utechfun.com/post/439619.html