騰訊十年老兵:區塊鏈本質上是一個異地多活的分散式資料庫
\\\區塊鏈前哨導讀:本文整理自 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. 智慧合約開發及示例
\\\\這是我們跟合作伙伴做的一個通兌積分的產品。現在很多機構都有自己的積分,但數量少的話沒什麼用,我們想把這些積分能夠整合起來,做到通兌積分,解決積分的出口問題。
\\- 銀行 1 與銀行 n 分別對使用者 a 和 b 記錄初始積分。\\t
- 呼叫智慧合約,a 給 b 轉賬 10;\\t
- 呼叫查詢合約查詢積分。\
4. 快速部署及運營配套
\\\\做聯盟鏈,配套設施很重要。因為面對的是銀行客戶,或者是企業級客戶,需要給他們提供完整的配套設施, 比如說 IDE、監控, 這些技術難度雖然不是特別大,但是必須要做到配套完善。
\\5. 答疑:
\\問:我看到一組資料,比特幣弱中心化趨勢越來越明顯。比如,全球有 77% 的算力都掌握在中國,從某種意義上來說的話,看上去好像比 dpos 更集中化了。您是怎麼看的?
\\答:就目前來看,整體雖然越來越集中,但還算可控,因為 POW 是一個純粹的計算問題。它的設計初衷假定人是獨立的。如果你控制整個計算,損害了其他人的利益的,別人就會逃離這個平臺,你也不會獲得收益。
相關文章
- 區塊鏈與分散式資料庫的比較區塊鏈分散式資料庫
- 分散式賬本-區塊鏈核心技術之一分散式區塊鏈
- 分散式系統技術難題--異地多活分散式
- 區塊鏈的工作證明其實是一個分散式時鐘區塊鏈分散式
- 一語中的:區塊鏈本質是雜湊連結串列區塊鏈
- 區塊鏈中的分散式模式區塊鏈分散式模式
- 區塊鏈vs傳統資料庫:分散式執行有何優勢?區塊鏈資料庫分散式
- 在 Laravel 上擼了一個支援多語言的國家地區資料庫Laravel資料庫
- 異地多活的資料一致性簡單設計
- 比特幣區塊鏈是一種分散式的事件流日誌比特幣區塊鏈分散式事件
- 區塊鏈和資料庫區塊鏈資料庫
- 區塊鏈分散式賬本Fabric、Corda和以太坊比較區塊鏈分散式
- 入門 | 區塊鏈vs傳統資料庫:分散式執行有何優勢?區塊鏈資料庫分散式
- 區塊鏈搭建開發公司談分散式記賬與區塊鏈區塊鏈分散式
- 區塊鏈每日一問 | 什麼是區塊鏈的“分叉”?區塊鏈
- 圖資料庫並非要取代區塊鏈,而是讓區塊鏈如虎添翼資料庫區塊鏈
- 分散式賬本技術:超越區塊鏈(附下載英文版)分散式區塊鏈
- 異地多活和同城容災
- 深入剖析資料庫核心之事務的本質 | 附下一代分散式資料庫 OceanBase 解決方案資料庫分散式
- 區塊鏈代表的資料庫和傳統資料庫有何區別區塊鏈資料庫
- EOS 區塊鏈資料實時異構到 MongoDB區塊鏈MongoDB
- EOS 區塊鏈資料實時異構到 MySQL區塊鏈MySql
- 區塊鏈會是下一個風口麼?區塊鏈
- 區塊鏈資料管理平臺開發,多節點聯盟區塊鏈搭建區塊鏈
- 塔說|區塊鏈遇到資料庫:相愛還是相殺?區塊鏈資料庫
- 微博“異地多活”部署經驗談
- 區塊鏈社交直播app開發,區塊鏈技術應用資料上鍊區塊鏈APP
- 一文讀懂區塊鏈以及一個區塊鏈的實現區塊鏈
- 一個簡單的區塊鏈區塊鏈
- 分散式資料庫系列(一)分散式資料庫
- 異質資料庫鍊資料庫
- 虢國飛:餓了麼異地雙活資料庫實戰資料庫
- 用資料視角看看區塊鏈是啥?區塊鏈
- 滴滴 Redis 異地多活的演進歷程Redis
- 一文透析騰訊區塊鏈技術區塊鏈
- Go的又一個分散式資料庫開源了Go分散式資料庫
- 架構系列---餓了麼MySQL異地多活的資料雙向複製架構MySql
- 區塊鏈應用技術資料上鍊聯盟鏈區塊鏈