腾讯十年老兵：区块链本质上是一个异地多活的分布式数据库
區塊鏈前哨導讀：本文整理自 9 月 8 日“騰訊技術工程—區塊鏈技術沙龍”上的演講。
講師介紹：潘安群，騰訊 TEG 計費平臺部賬戶中心總監，專家工程師；中國計算機學會 CCF 區塊鏈專業委員會委員；有近 10 年分布式存儲研發經驗，目前負責分布式 Cache 系統厚德（Hold）、分布式數據庫 TDSQL，以及騰訊云區塊鏈 TBaaS 平臺的技術研發工作。
本文主要有四個部分的內容：
\\- 從分布式數據庫角度看區塊鏈\\t
- 騰訊云區塊鏈服務 TBaaS 技術介紹\\t
- 智能合約開發及示例\\t
- 快速部署及運營配套\
1. 從分布式數據庫角度看區塊鏈
\\區塊鏈是源于比特幣中的底層技術，用于實現一個無中心的點對點現金系統，因為沒有權威中心機構的參與，比特幣以區塊鏈的形式來組織交易數據，防止“雙花”，達成交易共識。
\\傳統意義上的數字資產，比如游戲幣，是以集中式的方式管理的，僅能在單個系統中流轉，由某個中心化機構負責協調，通常以數據庫的方式來存儲。宏觀上看，區塊鏈和數據庫一樣，都是用來保存數據，只是數據存取的形式有所不同。
\\區塊鏈本質上是一個異地多活的分布式數據庫。異地多活的提出，原本是為了在解決系統的容災問題，多年來也一直是分布式數據庫領域在探索的方向，但鮮有成效，因為異地多活需要解決數據沖突的問題，這個問題其實不好解決。然而誕生于比特幣的區塊鏈以一種全新的方式實現了全球最大的異地多活數據庫，它完全開放，沒有邊界，支持上萬節點并可隨機的加入和退出。
\\\\在區塊鏈中數據沖突問題就更加突出了，區塊鏈里每個節點是完全對等的多活架構，上萬個節點要達成一致，數據以誰為準呢？比特幣采用的方式是 POW，大家來算一個謎題，誰先算出來，就擁有記賬權，在這個周期，就以他所記的賬為準，下一個周期大家重新計算。爭奪記賬權的節點決定將哪些交易打包進區塊，并將區塊同步給其他節點，其他節點仍然需要基于本地數據對區塊中的交易做驗證，并不像數據庫的主從節點間那樣無條件接受，這就是區塊鏈里的共識算法。POW 雖然消耗大量算力，好處是在爭奪記賬權的過程中 POW 只要在自身節點中計算 hash，不需要經過網絡投票來選舉，網絡通信的代價小，適合大規模節點之間共識。POW 是目前公有鏈里最完備最簡單最粗暴做法，最經得起考驗，但問題是效率太低。
\\\\所以后面發展出了 PoS、DPoS，誰擁有資產最多，誰就擁有記賬權，或者大家投票，但這樣又引入了經濟學方面的問題，比如所謂的賄選的問題，這就不太好控制了。在傳統分布式數據庫里，不叫共識算法，而叫一致性算法，本質上也是一回事。但分布式數據庫里一般節點數都很少，而且網絡是可信的，通常節點都是安全可靠的，我們基本上可以相信每一個節點，即使它出現故障，不給應答，但絕對不會給出假應答。所以在傳統公司分布式數據里，都用 Raft 或 Paxos 協議去做這種一致性算法。
\\后來產生了聯盟鏈，若干企業組成一個聯盟，加入聯盟的組織或機構需要進行身份認證，基本上能夠確認它們的身份是可信的。所以聯盟鏈跟公有鏈的共識算法是不太一樣的，聯盟鏈主要采用 PBFT 或更簡單的 Raft。
\\以太坊提出了智能合約的概念，可以實現各種邏輯, 而在分布式數據庫中可以利用存儲過程來實現類似功能。
\\區塊鏈在解決橫向擴展問題上，可以采取分片 / 跨鏈等方式，和分布式數據庫里中的 Auto-Sharding 技術類似, 在處理過程中，都需要保證事務的完整性。
\\\\整體從純技術角度來看，本質上區塊鏈跟分布式數據庫沒什么太大的區別。但他們的路線，或者要解決的問題是不一樣的，區塊鏈側重于抵御審查和安全性，而分布式數據庫側重于用戶體驗和性能效率。
\\產品上來看二者的側重點有著顯著的不同。抵御審查是以比特幣為代表的區塊鏈最重要的特性，也是比特幣賴以生存的基礎，因為比特幣不屬于任何人或組織，沒有誰能代表比特幣，比特幣沒有主體，所以各國政府或權威部門都無法關停比特幣。然后是安全性，區塊鏈賬本有成千上萬份副本分散在全球各地，數據幾乎永不丟失，同時利用所有節點的相互制約，沒人能夠惡意篡改數據。這兩者是區塊鏈的重心，表現出來就是大家常說的去中心化。
\\用戶體驗和性能相對于前兩個核心目標來說，不是區塊鏈最側重的，比特幣動用巨大的算力來運行秒只有幾個 TPS 的系統，數據冗余了上萬份副本，一筆交易可能需要數十分鐘才能提交，提交后的交易還可能因為被判定為“雙花”而取消，而這些問題在數據庫上都是不能接受的。二者產品上的側重點不同，從而導致技術實現上的差異.
\\2. 騰訊云區塊鏈服務 TBaaS 技術介紹
\\\\該架構有以下幾個主要模塊：
\\- 成員管理，要對成員有準入的控制，提供身份保證、內容保密、交易審計等功能\\t
- 區塊的服務，要有一些底層基礎的服務、共識算法和 P2P 的通訊協議，用于維護分布式賬本\\t
- 頁面封裝，提供 RESTFul API 來訪問各種服務，提供 CLI 客戶端工具，使開發人員能夠快速測試賬鏈代碼\\t
- 賬鏈代碼，用于構成智能合同，它嵌在交易中，所有確認節點確認交易前都必須執行它\
在 Fabric 架構中拆分了幾個模塊，最重要的是 Peer 和 Orderer， Order 主要處理共識過程，而其他所有業務邏輯是在 peer 執行。
\\\\在部署方面的話，是按照不同的組織部署自己的環境，然后通過共識網絡組合成聯盟鏈。Fabric 支持共識算法、身份認證和加密算法的插件化，背書和驗證程序的插件化，以及可配置 state 數據庫。
\\\\不同場景不同行業對區塊鏈的需求不同，側重點不同，如共識算法、安全級別、加密算法、賬戶模型等，作為一個 BaaS 平臺，需要支持模塊插件式的架構設計以應對行業的不同需求，TBaaS 基于 fabric 開發。
\\共識算法: 基于 kafka-zookeeper, raft，pbft。
\\身份認證 是聯盟鏈重要的部分，用來區分不同的聯盟成員，實現不同類型的權限控制（channel 的創建，修改，chaincode 的讀寫權限等）。
\\通用的 編程語言 可以方便區塊鏈與鏈外系統的交互（有限制，鏈外數據經常變化，會導致不同 peer 讀到不同的結果）。智能合約語言方面，我們支持通用的 golang、JS、Java。私有數據隔離保護：私有數據不公開在鏈上賬本中，僅公開私有數據的 hash，私有數據通過 gossip 協議點對點傳遞到指定節點。安全隱私方面，支持硬件加密機，支持國密算法，在多鏈設計上做了數據的物理隔離，私有數據也做了隔離保護。
\\\\TBaaS 邏輯上分成三個組件：背書節點，共識節點，驗證節點，其中背書節點是驗證節點的一個子集。
\\交易依次在三個組件上執行，采用三階段的交易流程：執行合約—打包區塊—交易驗證。
\\Execute：背書節點模擬合約執行，執行成功后對結果簽名背書， 背書策略就是定義什么樣背書節點的組合是有效的背書。
\\Order：共識節點對背書后的交易打包成區塊，生成全局交易序列。
\\Validate: 驗證節點驗證區塊生成者的簽名，驗證交易發起者的簽名，驗證背書策略是否符合，驗證數據版本號等，驗證通過后最終提交到賬本。
\\把背書節點從驗證節點中分離，方便設置靈活的背書策略，不需要每個節點都參與背書，聯盟中有權威的機構可參與背書，只有背書節點才需要查看合約，便于保護合約的隱私。
\\把共識節點從驗證節點中分離，是為了更好的可擴展性，不需要全部節點都參與共識，否則聯盟中節點數過多，會導致共識代價過大（pbft 需要大量的節點間通信來達成共識）。
\\如果全節點參與智能合約的執行，全節點參與共識，就類似以太坊等公有鏈行為，采用三階段方式是出于靈活性、可擴展性、隱私等方面考慮。
\\\\在最后的驗證階段, 有大量的加解密計算和 IO 操作，容易形成性能瓶頸。區塊的計算是有順序的，是串行的過程。所以我們把驗證與提交階段拆成了五個階段，像流水線的方式去執行。
\\Pipeline 方案保證交易順序全局一致的情況下，可以將區塊提交分成 N 個階段，每階段可并行執行，區塊間的處理順序不變，但同一時刻最多有 N 個區塊并行，交易吞吐量最高可提升 N 倍并發必然引入數據競爭，比如某一數據在相鄰兩個區塊中執行先讀后寫，在不同節點的執行環境中，多線程的執行時序存在差異，有可能部分節點讀到新版本，部分讀到舊版本（mvcc 沖突），同時還有幻讀等一系列數據庫常見問題。
\\通過預處理方式，可以讓每個節點在執行到 pipeline 的同一階段時能看到同樣的數據視圖
\\3. 智能合約開發及示例
\\\\這是我們跟合作伙伴做的一個通兌積分的產品。現在很多機構都有自己的積分，但數量少的話沒什么用，我們想把這些積分能夠整合起來，做到通兌積分，解決積分的出口問題。
\\4. 快速部署及運營配套
\\\\做聯盟鏈，配套設施很重要。因為面對的是銀行客戶，或者是企業級客戶，需要給他們提供完整的配套設施, 比如說 IDE、監控, 這些技術難度雖然不是特別大，但是必須要做到配套完善。
\\5. 答疑：
\\問：我看到一組數據，比特幣弱中心化趨勢越來越明顯。比如，全球有 77% 的算力都掌握在中國，從某種意義上來說的話，看上去好像比 dpos 更集中化了。您是怎么看的？
\\答：就目前來看，整體雖然越來越集中，但還算可控，因為 POW 是一個純粹的計算問題。它的設計初衷假定人是獨立的。如果你控制整個計算，損害了其他人的利益的，別人就會逃離這個平臺，你也不會獲得收益。
《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀總結
以上是生活随笔為你收集整理的腾讯十年老兵：区块链本质上是一个异地多活的分布式数据库的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 在Python-dataframe中如何
- 下一篇： onsubmit校验表单时利用ajax的