Factom(公證通)--基於區塊鏈的存證系統

 

 

　　Factom這個Solution在2014年的時候就已經推出了，如今已經2018年了，我纔來寫這一篇分析文章可能有些遲了，可是它是十分具備參考價值的。由於現階段來開區塊鏈雖然炒得火熱--養貓、養狗、草泥馬之類的，可是真正成熟的應用比較少，有不少連基本的鏈平臺都沒有開發徹底。而bitcoin做爲區塊鏈的1.0時代的表明，也是區塊鏈行業的標杆存在，它的生態是最完整的--礦池、錢包、交易所。可是相對於區塊鏈2.0Ethereum來說功能就比較單一了，它的智能合約--公鑰腳本功能單一，不是圖靈完備的。基於bitcoin開發的應用就比較少，而ethereum上面的應用就多達800多個（養貓應該是最火的了）。

　　但bitcoin不是說不能基於它去作一些事情，它也有一些擴展協議可讓bitcoin Blockchain來發揮更大的做用，好比說 OP_RETRUN 擴展交易。而Factom就是基於這個協議，若是換作此時此刻的話，Factom的創始人可能會選擇更加方便的Ethereum，而不是Bitcoin，但在14年的時候以太坊還不是很成熟，而Bitcoin則更加的穩定可靠，時至今日Bitcoin不多會由於自己的漏洞而形成財產損失，大多數都是由於交易所遭受攻擊而致使大量的Bitcoin被黑客盜取。這一點一要歸功於 pow這個被人‘詬病’的協議，2、它沒有支持圖靈完備的智能合約，功能單一也有好處，有時越簡單粗暴的越可靠，像以太坊就由於智能合約sdk的漏洞形成過兩次大規模的ether泄露。

1、Bitcoin的 OP_RETRUN協議介紹

　　OP_RETURN是一個腳本操做碼，用於將事務輸出標記爲無效。因爲任何帶有OP_RETURN的輸出可證實是不可靠的，OP_RETURN輸出能夠用來燒燬比特幣。

　　比特幣社區的許多成員認爲使用OP_RETURN是不負責任的，部分緣由是比特幣旨在爲金融交易提供記錄，而不是任意數據的記錄。此外，對於外部大規模複製數據存儲的需求本質上是無限的，這一點顯而易見。儘管如此，與在區塊鏈中存儲數據的一些其餘方式相比，OP_RETURN具備不會建立虛假UTXO條目的優點。 從比特幣核心版本0.9.0： 這種變化並不意味着將數據存儲在區塊鏈中。 OP_RETURN類型的交易請求建立了一個可證實的可修剪txo，以免數據存儲方案（其中一些已經部署）將諸如圖像之類的任意數據存儲爲永遠不可用的TX輸出，從而膨脹了比特幣的UTXO數據庫。 在區塊鏈中存儲任意數據仍然是一個壞主意，在其餘地方存儲非貨幣數​​據的成本更低，效率更高。

2、Factom的基本原理

在闡述基本原理以前，我先說幾個有關於Factom的關鍵詞：

Factoids ： factom發行的代幣，使用factom的服務時要消耗代幣，並且不能夠交易。

Entry Credits：提交Entry時要消耗 Credits，而Credits是用Factoids換取的，能夠交易。

Entry：提交到Factom上存儲的文件

Entry Block：記錄Entry完整性（Hash值）證實的區塊

Directory Block：記錄Entry Block塊完整性（Hash值）證實的區塊

ChainID：APPlication的帳本ID

APPlication：基於Factom服務開發的應用

Federated Servers：用來管理運行Factom的分佈式服務集羣

Auditing Servers：審查節點，這些審查節點負責審查Federated Servers的生成的帳本是否合法

看到這，你想必應該猜想到了，Factom是有本身的帳本--chain的，不光Factom有每個App都有本身對應的chain。

factom存證充分的利用了Merkle Hash tree，它的最基本原理就是： 首先將一段時間內上傳的數據都歸入到Merkle Hash tree（間接或者直接）；而後每隔10min中Root Hash加入到OP_RETRUN交易中，錨定到bitcoin區塊鏈。

　　稍微瞭解過bitcoin原理的老鐵應該都知道Merkle tree的精妙之處--假定root hash是正確的，則在不知道其餘葉子節點的狀況下，仍然能證實單個葉子結點的完整性。這樣作的好處就是你能夠不須要關心其餘葉子結點（在Bitcoin中是Utxo，在factom中是Entry數據），也能證實本身的完整性，有老鐵可能就問了這麼費勁幹啥？咋不直接把Entry的Hash錨定到Bitcoin上？貴啊！如今一個Bitcoin市值$14,000左右，礦工費最低要0.0009(不一樣礦池收費標註不一樣)，並且十分鐘才能添加一塊，還要等待6個塊確認，不說礦工費開銷大，效率也低啊。利用Merkle tree能夠上傳最少的數據 32bytes（上面說過一個OP_RETURN最多40），同時又能證實大量的數據完整性，何樂而不爲？

 

 本圖將Factom大體的邏輯關係已經呈現的很清楚了：

1.APP的運營者先去Factom上買Factoids，而後將Factoids兌換成Entry Credit

2.APP將數據提交到Factom Servers，加入該APP對應的Entry Chain

3.將 當前週期內上傳 Entry 打包成 EntryBlocks（白皮書上顯示 1min鍾生成一個塊）；

4.將 當前週期內生成的EntryBlocks 打包成 Directory Blocks；

5.間隔一段時間（白皮書顯示是10min，正好是比特幣生成區塊的平均時間）將未錨定的Diretory Blocks加入到一個Merkle tree中（按照白皮書說法應該是10塊）；

6.將root hash 錨定到Bitcoin中

APP參照了中本聰在bitcoin白皮書中提到的SPV原理，只要關心和本身相關的數據就行了。

3、Factom的組織架構

Factom整個架構體系中有三層，以下：

APPLication

---------------------------------------

FACTOM Server| Audis Server

---------------------------------------

BItcoin Miners

Factom 的帳本有四層，以下：

APP Entry Chains | FactorId Chain | Credit Chain

------------------------------------------------------

Entry Blocks

------------------------------------------------------

Directory Blocks

-----------------------------------------------------

Bitcoin Blocks

3.1 咱們先按照架構體系來講：

• APPlication ：由開發者開發面向用戶的應用，它們都使用了Factom的服務來作數據存儲證實。咱們下面描述一下APP加入Factom的過程：

setup 0： 一個APP在初始化加入Factom體系時候作的第一件事就是充錢（不充錢你怎麼能變強？），你將公鑰發送給Factom Server，Factom Server會分配給你一筆 Factoids，這筆交易會記錄在FactorId Chain中。

setup 1 ： 服務器 會向你反饋一個Entry 確認信息， 同時會向外廣播這個確認信息（咱們前面說過factom 是有一個分佈式服務集羣的）

setup2：APP用Factoids換取Entry Credit， 服務器會將這筆交易記錄在Credit Chain中，同時向外廣播。

setup3：APP上傳第一個實體Entry（初始化，裏面包含着你本身定義的Entry校驗規則的Hash值，或其餘細則），服務器會幫你建立一個對應ChainId的帳本，同時扣除相應的Credit，向外廣播消息。

ps： ChainId ID是由APP本身定義的ChainName的Hash值。

　　　建立後提交一個Entry的過程就是setup 1~3的過程，固然客戶端看起來就這麼簡單，在服務端就複雜多了。同時這裏面咱們要重點強調的是，Factom服務器不負責校驗Entry 數據的合法性，數據的合法性是在APP這一端校驗的。咱們能夠在建立帳本的時候將校驗規則（好比一個審計程序）的Hash加入到第一個Entry中，這個審計程序在APP運行，這樣就能屏蔽掉那些無效的Entry。

• Factom Servers： factom有一個分佈式的服務集羣，每個服務器都會負責一維護部分APP的帳本，同時將更新同步到其餘服務器中。Factom中服務器有兩種類型，一種是記帳服務器，一種是審查服務器。

 　　咱們來說一下servers的工做過程，首先介紹幾個關鍵詞：

　　　　process list： 每個服務器都要維護一個list，這個列表裏面存儲着本服務器和其餘服務器負責的chain。　　

　　　　Weighted Number of Entry Credits： 根據消費的Credits計算出投票權重用於選擇Factom Server

              Weighted Number of Entries：根據Entry計算出投票權重用於選擇Factom Server。

　　Factom  Servers一個記錄週期以下：

1. 1.  全部服務器重設其進程列表（Process List）爲空。
   2. 用戶通與其Entry信用的積分（Entry Credit）相關的公鑰提交付款
   3. 根據用於支付的公鑰，輪值服務器接受該付款。
   4. 該服務器向網絡廣播該支付被接受。
   5. 用戶看到支付被接受， 而後提交Entry。
   6. 根據Entry的ChainID，其中一臺服務器把Entry加入其進程列表，並添加進入到相應鏈的區塊中（若是這是該鏈的第一個Entry, 那就建立這個新鏈）。
   7. 服務器對網絡廣播該Entry的確認，內容含有Entry在Process list 中的位置（Index) + Hash(Entry)（連接到Entry付款）+ Hash(process list)。
   8. 全部其餘服務器更新該服務器的process list，驗證該列表，並更新該鏈的區塊。
   9. 只要用戶能夠驗證到相關的 process list 中包含本身的提交的數據Entry，那麼他們就能夠有至關的信心相信它會被成功地被錄入到Factom上。
   10. 在一分鐘結束時，全部服務器確認process list 的 高度，揭示一個肯定性的祕密數值（該值爲一個Reverse Hash 值，即一條較長的，連續的區塊鏈哈希值的原像值），還有被處理區塊的一系列哈希值（將與 process list 中的最後一項相匹配）。
   11. 那一分鐘的目錄區塊（Directory Block）是由全部服務器中定義的全部Entry區塊（Entry Block）組合到一塊兒建造而生成的。所以，每一個服務器都擁有全部的Entry區塊（Entry Block），全部的目錄區塊（Directory Block），和全部Entry（all Entries）。
   12. 使用Reverse Hash值的集合來創造一個種子，爲下一輪的ChainIDs從新分配服務器。
   13. 在完成10個目錄區塊後，請執行如下操做：
       1. 對最後一分鐘的Entry塊建立梅克爾根（Merkle Root），按ChainID排序。
       2. 建立最後一分鐘的目錄區塊，並計算其梅克爾根（Merkle Root）。
       3. 用10個目錄區塊的梅克爾根（Merkle Root）建立一個錨定。
       4. 用服務器的反向哈希值集合來建立一個種子，再用其選擇下一個服務器來把錨定寫到比特幣區塊鏈
   14. .重複。 （又從第1部開始循環）

 　　Factom 爲了防止腐敗發生，因此它的Servers集羣中記帳的服務器是會不斷變化的，每隔4個小時進行一次選舉，由user投票來決定哪些服務器可以成爲Factom的記帳服務器，用戶投票的權重是根據Weighted Number of Entry Credits和Weighted Number of Entries計算出來的，全部的服務器都會參選最後進行一個排名，而後選擇前n名成爲Federated Servers 其他的爲Auditing Servers。 爲了防止被選擇的服務器發生故障，每隔四秒就要廣播心跳包（Entry 確認信息），若是一臺服務器沒有收到 X 的心跳包就會發送一個SFM信息認爲X是故障的，若是大多數（沒有給出閾值）認爲X服務器是故障的，那麼X服務器就會降級，由第n+1名服務器升級爲Federated Servers，X 降級爲Auditing Servers。

ps0：你們可能會困惑既然合法性校驗放在了client side，那麼Auditing Servers有個卵用？Auditing Servers 有兩個做用： 1、審查Federated Servers生成塊是否符合規則；2、爲Entry 提供存在性證實（Proof of existence）（這是從Factom社區裏面獲得的回覆）。

ps1：Weighted Number of Entry Credits： 加權最近六個月購入的入場券數量（每個月購買金額，當月加權6次，前5次加權等） ；Weighted Number of Entries： 加權最近六個月使用的條目數量（每個月使用的條目數量，當前月份加權6個，前一個加權5個）。

• bitcoin miner：這一層我就很少說了。

　　上面就是按照體系架構來說述一下它工做的基本流程，Factom的實現比較複雜。

3.2 咱們再按照帳本層次來講：

• Directory Blocks

　　目錄塊中引用的每一個Entry塊佔用64個字節（兩個32字節散列，Entry Block的ChainID和Merkle根）。一百萬個這樣的條目將致使一組目錄塊大小約爲64MB。若是平均的每一個Entry Block有5個Entry，64 MB的Directory Blocks將提供500萬個不一樣Entry的高級管理。Factom服務器收集Entry Block的Merkle根並將它們打包到目錄塊中。十個連續的目錄塊經過Merkle樹散列，Merkle根被記錄在比特幣區塊鏈中。這容許區塊鏈的最小擴展，而且仍然容許經過比特幣散列權限保護分類帳。將Merkle根加入比特幣區塊鏈的過程稱爲「錨定」。有關更多詳細信息，請參閱「附錄：比特幣時間戳」部分。從帶寬和存儲的角度來看，輸入到目錄塊中的數據是最昂貴的。若是Factom用戶但願在鏈中找到數據，那麼他們須要從帳本建立時開始的全部目錄塊。會增長目錄塊大小的Active 包括 APP chain 的建立和首次更新。這些Active將 APP 程序細化帳本規則的 花費 進行了公示。相比記錄一個Entry，APP必需要花費更多的Entry積分來執行這些特殊的Active，這樣能夠阻止目錄塊的膨脹。也就是說實際上Directory block中記錄的是一個map<chainId, Entry Block Merkle Root Hash>的表。

• Entry Blocks

　　Entry Block Later 是系統中的第二層級。APP 將擁有各自的ChainID。在 Entry Blocks 裏，APP能夠ChainID爲線索擴展搜索全部相關的條目。每一個目錄塊中包含的chainId 都會有一個更新的Entry Block。Entry Block包含上傳的Entry的散列值。Entry的哈希證實了數據的存在，同時也充當在分佈式哈希表（DHT）網絡中查找Entry的Key。 （更多細節參見「Factom點對點網絡Entry Block 有意不包含 Entry 自己。這使得Entry Block 很小。從Entry Block 中分離 Entry 還可使審計人員更容易審計。審覈員能夠在一個單獨的鏈中，這個鏈用來記錄那些來自普通鏈中的被批准或被拒絕的Entry。審覈員能夠在其Entry中增長拒絕的理由。若是應用程序信任審覈員，他們能夠交叉引用審覈員批准或拒絕每一個Entry，而不須要知道Entry是什麼。而後應用程序將只嘗試下載經過審計的Entry。多個審計人員能夠引用相同的Entry，而且條目將只在分佈式散列表（DHT）上存在一次。預計條目將比散列佔用的僅僅32個字節大得多。要忽略的事物列表不必定要讓應用程序忽略完整的對象。輸入塊包含與ChainID相關的全部可能的輸入項。若是一個Entry沒有在Entry Block中被引用，那麼能夠假定它不存在，這容許應用程序證實是否認的。

ps：如今Factom並未構建起DHT存儲，他們準備和IPFS進行合做來存儲文件。

 

• Entrys

　　記錄是被用戶建立並提交到Factom的。經過散列和編碼信息，用戶能夠確保記錄的隱私性。若是編碼或隱藏數據是沒必要要的話，那麼記錄能夠替換成爲純文本。經過記錄一份文檔的一段哈希值，Factom能夠提供基本的發佈證實(proof of publication)。稍後, 人們能夠生成文檔的哈希值, 並和以前鏈塊記錄的哈希值進行比對, 來判斷文檔是不是當初發佈的那個版本。這在數據的處理能夠有很大的靈活性，能夠出現相似超連接的東西。數據還能夠更龐大，但不能過於龐大.，由於數據越大須要付的費用也越多。這和比特幣比較類似，超過100兆字節的比特幣轉帳數據是可能發生的，但須要支付更多的轉帳費用。Factom能夠處理比比特幣網絡裏大得多的數據，因爲比特幣的完整節點需掃描完整的區塊鏈數據，因此區塊鏈體積不能太大。在Factom中完整節點只須要掃描最高級的目錄區塊(Directory Block), 並不須要掃描所有的鏈塊數據。若是人不對鏈數據感興趣的話，徹底能夠忽略它。

ps:Factom實際上到底有沒有存儲這些Entry 連接的文件還沒有得知，我在社區中詢問可是沒有獲得解答。

最後給你們上一個整體的帳本結構圖，以下：

參考網址：

5. https://www.factom.com/devs/docs/guide/factom-white-paper-1-0
6. http://www.8btc.com/factombaipishu
7. https://en.bitcoin.it/wiki/OP_RETURN
8. https://www.cnblogs.com/fengzhiwu/p/5524324.html

---------------------------------------------------分割線-----------------------------------------------------

 

　　以上的內容一部分來自我本身從白皮書中的翻譯，一部分引用於上面的網址，其中還有一些不肯定性，我在註釋中已經指出，若是哪位老鐵知道答案的話請在評論區留言，我會及時改正。下面我闡述一個本身並不成熟的觀點，就是基於pow鏈的存證系統有多大價值？咱們知道如今數據存證經常使用的是數字簽名，既能夠保證數據的完整性，又能保證數據的合法性。最多我再多雲備份幾份，你這個存證系統到底有什麼存在的必要？　　

　　從密碼學破解的角度來看，篡改Factom中的Hash證實要比篡改簽名難度等級要高。由於Factom錨定到了bitcoin上，這是一種信任的傳遞，你若是要想篡改出來一個合法的Hash證實首先要從bitcoin區塊下手。並且隨着時間的推移，後續塊的增多篡改的難度越大，這相比從公鑰推導出私鑰的難度要更大！（固然這是在私鑰沒有被竊取的條件下，若是你的用戶私鑰被竊取，或者說你的Factom帳號被竊取，你仍然能夠去篡改Entry的Hash證實。）　　

　　可是，從現階段來看，這二者都是基本「零」可能。然而當量子計算機出現的時候狀況就不同了，量子計算理論上能夠暴力破解非對稱加密，雖然格密碼理論上可以抵禦量子計算，但現有的PKI體系仍是不免會收到衝擊。而這個時候Factom的做用就體現出來了，你能夠去破解ecc和rsa的證書去僞造證實，可是你依然很難篡改Bitcoin帳本。由於區塊鏈帳本是靠強大的hash算力保護的，而量子計算機在破解hash算法上並無什麼優點，因此僞造區塊依舊很難，只要是已經存在的帳本正確性依舊難以動搖。

 

附，量子計算機維基百科：

歷史

　　隨着 計算機科學的發展， 史蒂芬·威斯納在1969年最先提出「基於量子力學的計算設備」。而關於「基於量子力學的信息處理」的最先文章則是由 亞歷山大·豪勒夫（1973）、帕帕拉維斯基（1975）、 羅馬·印戈登（1976）和 尤里·馬尼（1980）年發表 [2] [3] [4] [5]。史蒂芬·威斯納的文章發表於1983年 [6]。1980年代一系列的研究使得量子 計算機的理論變得豐富起來。1982年， 理查德·費曼在一個著名的演講中提出利用量子體系實現通用計算的想法。緊接着1985年 大衛·杜斯提出了 量子圖靈機模型 [7]。人們研究量子計算機最初很重要的一個出發點是探索通用計算機的計算極限。當使用計算機模擬 量子現象時，由於龐大的 希爾伯特空間而數據量也變得龐大。一個無缺的模擬所需的運算時間則變得至關長，甚至是不切實際的天文數字。理查德·費曼當時就想到若是用量子系統所構成的 計算機來模擬量子現象則運算時間可大幅度減小，從而量子計算機的概念誕生。半導體靠控制 集成電路來記錄及運算信息，量子計算機則但願控制原子或小分子的狀態，記錄和運算信息。

　　量子計算機在1980年代多處於理論推導狀態。1994年 彼得·秀爾（Peter Shor）提出 量子質因數分解算法後 [8]，證實量子計算機能作出 離散對數運算 [9]，並且速度遠勝傳統電腦。由於量子不像 半導體只能記錄0與1，能夠同時表示多種狀態。若是把半導體比喻成單一樂器，量子計算機就像交響樂團，一次運算能夠處理多種不一樣情況，所以，一個40比特的量子計算機，就能在很短期內解開1024位電腦花上數十年解決的問題。因其對於如今通行於銀行及網絡等處的 RSA加密算法能夠破解而構成威脅以後，量子計算機變成了熱門的話題，除了理論以外，也有很多學者着力於利用各類量子系統來實現量子計算機。

基本概念

傳統計算機即對輸入信號序列按必定算法進行變換的機器，其算法由計算機的內部邏輯電路實現。

3. 輸入態和輸出態都是傳統信號，用量子力學的語言來描述，也便是：其輸入態和輸出態都是某一力學量的本徵態。如輸入二進制序列用量子記號 0110110，用量子記號則爲| 0110110> 。全部的輸入態均相互正交。對傳統計算機不可能輸入以下疊加態：c1 |0110110> + c2|1001001>
4. 傳統計算機內部的每一步變換都演化爲正交態，而通常的量子變換沒有這個性質，所以，傳統計算機中的變換（或計算）只對應一類特殊集。

量子計算機分別對傳統計算機的限制做了推廣。量子計算機的輸入用一個具備有限 能級的量子系統來描述，如二能級系統（稱爲 量子比特（qubits）），量子計算機的變換（即量子計算）包括全部可能的正變換。

3. 量子計算機的輸入態和輸出態爲通常的疊加態，其相互之間一般不正交；
4. 量子計算機中的變換爲全部可能的正變換。得出輸出態以後，量子計算機對輸出態進行必定的測量，給出計算結果;

傳統計算是一類特殊的量子計算，量子計算對傳統計算做了極大的擴充，其最本質的特徵爲 量子疊加性和 量子相干性。量子計算機對每個疊加份量實現的變換至關於一種經典計算，全部這些傳統計算同時完成，並按必定的機率振幅疊加起來，給出量子計算機的輸出結果。這種計算稱爲量子並行計算