鏈上治理

鏈上治理指的是人們直接在區塊鏈發起社區提案，並進行決策的過程。這裡首先要求的是鏈上支持基本治理協議，這套協議可以規定或強制執行提案，鏈上治理直接決定了區塊鏈本身的發展方向。

鏈上治理的參與方包括了投資者、使用者、開發者、礦工四類人群。

鏈上治理與鏈下治理的區別在於，區塊鏈本身是否提供強制執行的機制讓少數服從多數。在鏈上治理協議中，參與者需要可以通過投票參與治理，而鏈下治理中，多數通過提案、社區見面開會等多種線下線上互動方式，讓整個社區達成一致，擴容之爭中的三次共識就是典型的鏈下治理。

各種類型的鏈上治理

比特幣 BIP 和區塊投票雖然比特幣沒有提供完整的鏈上治理機制，但是比特幣也支持簡單的投票機制，例如在區塊中寫入共識信息表示支持某項提案，例如礦工可以在區塊中填寫 NYA 表示支持紐約共識。但這一切都是基於比特幣的 BIP，首先得有 BIP，才能發起投票。BIP 的組織架構比較社區化，主要由 Github 上的一些開發者和核心社區成員組成。礦工的所有行為也是非強制性的，當真正發生主網升級時，礦工仍可以選擇不升級，這將帶來分叉，也是所有人都不願看到的。
以太坊 Gas limit 投票以太坊上提供了對 Gas 消耗的上限參數 ——Gas limit，礦工通過投票選擇增加或減少 Gas limit，Gas limit 決定了單個區塊上可以處理的智能合約數量，但這僅針對這一項細分功能，並不能決定整個區塊鏈的發展。實際上，以太坊的發展受 Vatalik 本身影響比較大，核心成員和早期資本的推動是以太坊治理的主要源動力。
比特股 BTS 和柚子 EOS 的鏈上治理我們在前面的文章介紹過 EOS 區塊鏈鏈上治理結構 —— 區塊鏈憲法。實際上憲法也沒有強制約束力，但是它成為了一種社區強制約束力，類似宣誓過程。EOS 和比特股的治理結構來自於 DPoS 算法提供的投票過程，投票是根據幣的數量作為權重的，使用者、投資者、開發者、礦工這四種角色中，其中把礦工和投資者進行了合併，受資本的要脅，風險比較大。

以上治理結構，我們把比特幣和以太坊歸為一類，這類傾向於鏈下治理，EOS 和比特股傾向於鏈上治理。

鏈上治理的幾個問題無論鏈上治理還是鏈下治理方式都存在一些問題。升級的實際執行者礦工總是理性的，也就是追求自身利益最大化。惰性投票，只有很少一部分人會真正地去投票。投票權過度集中，大戶持有者往往話語權更重。

鏈下治理相比鏈上治理，更接近我們現實社會的方式。鏈上治理不是一個設計問題，它是社區制度問題，“如何讓區塊鏈更好地發展” 相比 “區塊鏈項目應當設定什麼樣的發展目標”，是排在第二位的。社區在自身追求目標的過程中，會自發地找到最佳治理結構，人為設計可能會有諸多漏洞和缺陷，也限制了可開發性。

例如鏈上治理至少存在以下幾個問題。

公地悲劇當所有人都覺得別人會投票的時候，也就沒有人投票了，這個典型案例是英國脫歐公投。區塊鏈上進行鏈上投票可能也會遇到類似的問題。
女巫攻擊目前區塊鏈很難映射現實中人的身份，鏈上治理指的是人們直接在區塊鏈發起社區提案，並進行決策的過程。這裡首先要求的是鏈上支持基本治理協議，這套協議可以規定或強制執行提案，鏈上治理直接決定了區塊鏈本身的發展方向。

鏈上治理的參與方包括了投資者、使用者、開發者、礦工四類人群。

各種類型的鏈上治理

比特幣 BIP 和區塊投票雖然比特幣沒有提供完整的鏈上治理機制，但是比特幣也支持簡單的投票機制，例如在區塊中寫入共識信息表示支持某項提案，例如礦工可以在區塊中填寫 NYA 表示支持紐約共識。但這一切都是基於比特幣的 BIP，首先得有 BIP，才能發起投票。BIP 的組織架構比較社區化，主要由 Github 上的一些開發者和核心社區成員組成。礦工的所有行為也是非強制性的，當真正發生主網升級時，礦工仍可以選擇不升級，這將帶來分叉，也是所有人都不願看到的。
以太坊 Gas limit 投票以太坊上提供了對 Gas 消耗的上限參數 ——Gas limit，礦工通過投票選擇增加或減少 Gas limit，Gas limit 決定了單個區塊上可以處理的智能合約數量，但這僅針對這一項細分功能，並不能決定整個區塊鏈的發展。實際上，以太坊的發展受 Vatalik 本身影響比較大，核心成員和早期資本的推動是以太坊治理的主要源動力。
比特股 BTS 和柚子 EOS 的鏈上治理我們在前面的文章介紹過 EOS 區塊鏈鏈上治理結構 —— 區塊鏈憲法。實際上憲法也沒有強制約束力，但是它成為了一種社區強制約束力，類似宣誓過程。EOS 和比特股的治理結構來自於 DPoS 算法提供的投票過程，投票是根據幣的數量作為權重的，使用者、投資者、開發者、礦工這四種角色中，其中把礦工和投資者進行了合併，受資本的要脅，風險比較大。

以上治理結構，我們把比特幣和以太坊歸為一類，這類傾向於鏈下治理，EOS 和比特股傾向於鏈上治理。

例如鏈上治理至少存在以下幾個問題。

公地悲劇當所有人都覺得別人會投票的時候，也就沒有人投票了，這個典型案例是英國脫歐公投。區塊鏈上進行鏈上投票可能也會遇到類似的問題。
女巫攻擊目前區塊鏈很難映射現實中人的身份，如果按照身份去投，大戶是可以扮演多個偽造身份進行投票的，在產生區塊鏈數字身份之前，鏈上治理只能依托於幣的數量進行權重投票。這便造成一代幣一票，持幣多的選民有更大的話語權。
賄選這其實是女巫攻擊的延伸，鏈上治理節點可以承諾將獲得的收益與其他節點進行分享，這種拉票方式其實就是賄選，如果惡意節點可以通過賄賂成為記帳節點，進而左右區塊鏈的升級過程，後果非常可怕。目前創始團隊進行控制式治理是最常見的，在社區強大後，創始團隊再退出，讓社區自己運作，是比較典型的 “中本聰模式”。鏈上治理其實是一個很熱門的話題，它關注的是區塊鏈自身的發展，很可能會是區塊鏈的一個重要研究方法，但是這並不是技術所能解決的，所以並不太樂觀。

區塊鏈在各行業的快速發展，帶來了全新的機遇。從數字貨幣到數字資產數字貨幣是數字資產的清算底層，數字資產的經濟活動依賴數字貨幣。數字貨幣一般只能是公鏈項目，數字資產依靠公鏈生態提供，這種支撐型結構決定了數字貨幣的種類不會很多，而數字資產會非常多。目前數量繁多的數字貨幣最終會消亡一大半，只剩下幾個生態豐富的數字貨幣，通過這幾個數字貨幣來支持數量繁多的數字資產，而這些公鏈會通過一些大型的中心化交易平台完成互通互兑，小型的交易平台多為垂直類的數字資產服務。

比特幣本身是最成功的數字貨幣項目，同時也是最成功的區塊鏈項目。比特幣的應用生態主要集中在全球無國界支付結算上，由於比特幣本身是一種原生資產，它沒有與任何其他資產錨定，所以比特幣的應用生態取決於人們的共識，這點比特幣已經做到了。只要比特幣的社區不發生大的動亂，那麼比特幣的地位是很難超越的，儘管有諸多嶄新的區塊鏈技術冒出來，如提升共識效率、提升網絡容量等等。

但是比特幣的共識經過了近十年的歷史開創，形成成熟穩定的生態結構，這一點在技術上是無法取代的。所以比特幣依然會作為互聯網領域的第一支付手段，並且延伸到線下場合。除了比特幣還有 Tether 和 bitCNY 等錨定型數字貨幣，這些數字貨幣最大的特性是與法幣錨定。其實也可以與實體資產錨定，只不過我們還沒有走到那一步。綜上，我們可以總結出兩大類數字貨幣：原生數字貨幣和錨定型數字貨幣。

原生型數字貨幣具有如下特點：

非營利性社區自治；

依賴社會共識承認；

超級結算工具；

可用於支持數字資產。

錨定型數字貨幣具有如下特點：

商業性自治；
依賴廣泛的承兌商；
穩定的支付結算工具；
可用於支持數字資產。

我對數字資產進行一個分類，數字資產所產生的金融我們稱為數字金融，國內又稱為通證和通證經濟，涵義上差不多。 Token 是數字資產最直接的表現形式，Token 的生態結構具有自發和原生性，大致可以分成這幾種類型。

一種是基礎設施型生態，一種是金融型生態，還有一種是商業垂直應用生態，這三種生態都非常有潛力。

基礎設施型 Token 基礎設施一般就是指公鏈的權益代幣，很多公鏈都在做這個領域的研究，當然這也是最迫切需要被突破的，有了成熟的基礎設施，區塊鏈應用才得以廣泛普及。這類的 Token 的典型是以太坊上的以太幣 Ether，除了以太坊，還有 EOS、NEO 等，可以說能夠支持發行 Token 的公鏈都具有較高的潛在價值，它們目前處於軍閥混戰時期，後期是垂直細分還是一統江山很難判斷。另外基礎設施型 Token 本身也具備數字貨幣的功能。

金融型 Token 這類 Token 的典型是 Tether 、bitCNY 等錨定型數字貨幣，以及交易平台的 Token，例如火幣的 HT、OKEX 的 OKB 和幣安的 BNB。這類 Token 的典型特點是在為原生數字資產創造流動性，它是數字金融發展的必然結果。

金融型 Token 有點接近證券，只能在流動性高的地方產生，例如數字資產交易所、承兌平台。商業垂直生態型 Token 這一類 Token 具有非常大的商業潛力，釋放的能量也是最大的，這裡當然不是指單個 Token，而是某個商業生態形成的一類 Token。例如遊戲直播平台可以打通形成一類 Token，

這類 Token 的設計者，也面臨了兩個挑戰。首先從業者需要理解區塊鏈，理解區塊鏈不單指理解區塊鏈的技術原理，而是區塊鏈本身蘊含的思維，這裡的思維我歸納為兩類，第一類是開放的產品形態，第二類是社區共同治理。其次從業者容易拘泥於傳統互聯網時代的商業模式，例如做內容或做流量的 App，表現方式無非廣告和會員，思維很難跳出來。要知道，未來商業垂直型的 Token 幾乎肯定都是原生數字資產，所以按照阿里或者騰訊的模式可能找不到區塊鏈的方向，這類 Token 的未來一定是新的阿里和騰訊。

我預測這類 Token 會極大地改變互聯網產品的運營模式，Token 模式下的產品運營會拉近用戶與運營商的距離，他們不再是對立關係，而是區塊鏈式的共生社區自治的關係，區塊鏈的治理模式也會影響產品的運營模式。最後我們總結一下，以上三類 Token 依賴關係是：

商業垂直生態型 Token 依賴基礎設施型 Token；
金融型 Token 依賴基礎設施型 Token；
商業垂直生態型 Token 可能依賴金融型 Token。

Token 的流動性大小依次是：基礎設施型 Token > 金融型 Token > 商業垂直生態型 Token

Token 的種類數量分布依次是：商業垂直生態型 Token > 金融型 Token > 基礎設施型 Token

那麼 Token 從這個角度來看，只有兩類。普通 Token

積分型。這種 Token 可能比較常見，因為我們經常遇到，例如超市積分，產品積分等等，這種在產品運營上可能換了一種形式，相較於原來的積分體系，流動性可能有所提升。
會員型。大多數會員制的營銷方式，相當於是使用權預售，例如蘋果手機預售發行，不必局限在某個渠道商，可以以發行 Token 的方式進行預售。這種類型的 Token 也可以映射到當下現實場景中去。
分紅型。這種類型的 Token 典型是幣安的 BNB，利潤回購是分紅型 Token 常見的手段，但由於操作不夠透明，很可能會遇到問題。

價值型的 Token，一定會觸及改變了原有的生產關係。就如一個人剛接觸股權概念的時候，很難解釋清楚股權對應什麼，Token 也是類似的處境，Token 具有可編程屬性，它可以帶來多種屬性合一。

使用權，表示 Token 可交付產品或服務；

可交易，流動性是數字資產的基本需求；

可升值，這是由第二條帶來的附加屬性，也就是升值。

Token 技術棧比較 Token 的實現已經有 ERC20 為主的以太坊生態、比特股 SmartCoin 生態、NEO 的 NEP-5 生態、

量子鏈的 QRC20 生態，還有元界的 MST 生態。

於中心化交易所是主流應用，所以今天我主要介紹的是中心化模式下的數字貨幣交易平台。兩套帳本

數字貨幣交易平台的技術基本沿用了金融交易技術中的系統架構，只是把原來針對法幣和證券（或平台代幣）的部分，也就是我們通常稱作資金管理系統的部分，完全替換為針對數字貨幣的數字貨幣管理系統，換句話說，就是換了一套內部帳本。然而我們知道，區塊鏈本身也是用來記帳的，也算作一種金融帳本，所以一套內部帳本，一套區塊鏈本身的帳本，這裡就出現了兩套帳本，如何管理這兩套帳本，就是資金管理系統的首要任務。

圖示數字貨幣交易所) 解釋一下這張圖，圖的左邊表示了多個區塊鏈帳本，右邊的數字貨幣交易所有自己的內部帳本，這兩套帳本是獨立的。交易所內部的帳本記錄的是交易 Trade，這個交易是由用戶掛單，接著被撮合引擎撮合成交而產生的，而區塊鏈帳本上的交易 Transaction，是當且僅當用戶發起充幣提幣請求並被執行時，才會產生的。

這兩種交易都用了中文 “交易” 來表示，但是它們所屬的語境不同，前者的交易表示的是金融交易語境下的資產交換，也就是 Deal；後者表示的是區塊鏈上的技術概念，表示資產轉移的一次記帳過程，上述特意用英文以表區別，希望你能夠區分。

數字貨幣交易所包含哪些系統模塊一個數字貨幣交易所的後端其實至少有四部分構成：Web 業務邏輯系統、交易撮合系統、運營後台管理系統、資金管理系統。資金管理系統其實就是剛才說到的內部帳本。

Web 業務邏輯系統：這個模塊通常包含了用戶賬戶模塊、登錄網關、賬戶安全管理、KYC 認證、行情推送等等，這個模塊更偏向用戶，也與通常的電商賬戶系統十分相似。

交易撮合系統：這個模塊是一個交易所的核心模塊，為所有的用戶提供訂單撮合。

運營後台管理：這個模塊是一個交易所運營人員使用的系統，交易所內部人員才能訪問。

資金管理系統：這裡的資金管理其實包含了三部分，第一部分是法幣的支付網關，可能需要對接銀行或第三方支付機構；第二部分就是數字貨幣錢包管理，它提供了大部分主流數字貨幣的支付功能；第三部分是用戶持倉信息，所謂持倉就是用戶持有多少數字貨幣，這個是記錄在數據庫中的，不需要與區塊鏈保持一致，但是要求交易所的總賬是平的。

各自模塊的特徵 Web 業務系統與我們常見的電商系統無異，主要是用戶賬戶以及簡單的業務邏輯，重點是可擴展性，業務要求比較彈性。交易撮合系統本質上是一個高並發的計算系統，特點是系統性能高和穩定性好，其中訂單隊列可以是編程語言中的數據容器，也可以是內存數據庫。

運營後台系統在整個交易所生命周期的早期並不凸顯重要性，但是運營後台系統恰恰是交易所中後期發展的核心系統，重點在數據準確，要求網絡安全性高和可擴展性好。資金管理系統包含用戶持倉狀態，以及數字貨幣錢包服務，它是一個交易平台中安全性要求最高的系統，資金管理系統往往要搭配一個內存數據庫，其中數字貨幣錢包服務也可以拆出來做成獨立子系統，甚至可以改造成整個公司的內部區塊瀏覽器，因為錢包服務需要設計成多個錢包實例，並統一所有的幣種錢包接口。

上圖中，MatchingGroup 相當於是交易撮合系統；Web-Group 相當於 Web 業務邏輯系統；Backoffce 相當於後台管理系統；AssetsManagement 相當於資金管理系統。

涉及的技術棧如果我們再將剛才提到的各個模塊細分，會看到以下的功能。

按照上圖的細分功能，我們可以得到哪些技術支持一目了然。首先是 Server 需要數據庫作為支撐，其次是 Restful API 作為基礎通訊協議，並且集成錢包相關的技術，撮合引擎為 Sever 提供撮合服務。在這裡面，例如需要 SMS 系統，所以可以使用雲服務中的 SMS 組件，這些都可以是成熟的通用組件技術。我們可以發現中心化交易使用的技術與互聯網技術並無不同。把這些通用組件塞到下圖中各個層次和大模塊當中，所以最終一個交易所的詳細架構可能是下圖的樣子。

首先是存儲，持久存儲通常可以選擇 MySQL，撮合相關的模塊由於要避免接觸磁碟 IO，所以需要為撮合模塊提供 Redis 類型的內存存儲，二者需要保證最終一致性。撮合和行情部分，幾乎與傳統技術無異，行情推送可以類比到其他推送系統，只是頻率更高，一般首選 Websocket 技術。這與傳統互聯網應用的最大區別里主要是數字貨幣錢包管理，這塊完全是新的內容，對安全性、易用性提出了相當高難度的挑戰，這裡也是交易所資金托管的根本，所以如何管理好大量數字貨幣，往往要結合運營、內部管理制度、冷熱錢包技術一起才能做好交易所的資金管理。

那麼用戶是如何掛單的，又是如何產生區塊鏈交易的呢？我們來看一看。

交易過程那麼說，用戶 A 拿 0.01BTC 換取了 B 的 10 個 ETP 的過程究竟是什麼樣的呢，我來舉一個例子。#

用戶 A 掛 10 ETP 買單，出價 0.01BTC 經過 Web 業務系統進入撮合系統訂單簿 ETP-BTC 買單隊列，等待撮合成交，同時資金管理系統凍結 0.01BTC。
用戶 B 掛 10 ETP 賣單，出價 0.01BTC 經過 Web 業務系統進入撮合系統訂單簿 ETP-BTC 賣單隊列，與步驟 1 中 A 的訂單撮合匹配成功，生成 Trade，同時資金管理系統結算對應資產，B 的資產變化為增加 0.01BTC 並減少 10 ETP，A 增加 10 ETP 並減少 0.01BTC。
成交 Trade 以及資產變化通過資金管理系統寫 RDB 數據庫，形成成交記錄，同時更新行情數據庫記錄可供用戶和運營後台管理系統查詢。要注意的是這一步並不是登記到區塊鏈上。
用戶 B 經過 Web 業務系統發起提幣請求，請求提取 10 ETP 進入自己的數字貨幣錢包，這個請求進入資金管理系統，交易所運營人員可通過運營後台觀察到這筆請求，運營人員審核用戶 B 的信息，比如實名認證是否正常等。
提幣請求進入運營系統後，如果通過審核，則資金管理系統會凍結用戶 B 的 10 ETP，同時將提幣請求發起給數字貨幣錢包服務系統，也就是 WalletGroup，子系統發起區塊鏈上的交易 x（Transaction），等待交易被打包，並根據更新提幣審核狀態，供用戶查看。
數字貨幣錢包服務根據區塊信息查詢交易 x 是否被打包，如果已經打包，則資金管理系統將完全把用戶 B 被凍結的 10 ETP 直接抹成 0，更新提幣狀態最終為完成，提供區塊交易 ID 以供用戶和運營後台系統進行查詢。

在步驟 3 中，我們可以看到用戶所持有的資產，相當於是交易所對用戶的負債，但這也只是數據庫，並不是真正的鏈上資產。

在步驟 6 中，我們看到區塊鏈上的 “交易” 與步驟 3 中的 “交易” 完全不是一個概念，同時用戶的資產是否安全，完全取決於交易平台的技術是否安全，對交易所是否信任。

再來看看充值階段。簡單來說，充值是與提幣相反的過程，不同的是，充值不需要審核，一般數字貨幣交易所的原則都是 “寬進嚴出”，在充值過程中，交易平台通常不直接使用數字貨幣錢包檢測用戶是否充值到賬，而是使用 “掃塊”(block_scan) 這一方法檢測用戶的充值。

數字貨幣錢包的分類#

目前市面上的數字貨幣錢包有很多種，看起來似乎有些眼花繚亂，不過，我們可以將它們進行分類後，再快速了解。下圖展示了按照不同屬性區分的區塊鏈錢包。

左一是按照用戶端平台劃分的錢包，這種錢包實際是在服務端運行的，用戶端的錢包實際上只是個代理，所以用戶不需要關心錢包的細節，使用起來十分方便，典型的例子是各種在線錢包。左二是按照貨幣類型分類的錢包，主要是指這款錢包到底是否支持多幣種，這裡的多幣種可以是基於以太坊 ERC20 Token 的同一區塊鏈上的多幣種，也可以是集成了比特幣和以太坊等不同區塊鏈的多幣種。

右二是按照私鑰存儲的方式來區分的錢包，實際上這裡主要涉及了用戶私鑰是否被平台托管，如果不托管直接存儲在用戶端，也就是硬件、終端設備、紙質記錄，這些都可以被稱為 On-chain 的錢包；如果用戶無法接觸到私鑰，私鑰被托管在平台，那麼這種錢包也被稱為 Off-chain 的錢包。右一是按照訪問方式進行分類的錢包，例如可以多個人共同管理，同時它也是需要多重簽名支持的錢包，否則就變成了個人私有的錢包。

上的分類並不是絕對的，一個錢包可以兼具以上不同的屬性，例如某個 Mobile 錢包是提供 Onchain 的，也提供多重簽名、提供多幣種的錢包，這種錢包通常就是業界比較流行的錢包類型。但是，對於平台方來說，上述錢包類型可能不足以支持自己平台的需求，並發揮出最佳的功效。畢竟作為平台來說，對高可用、分叉檢測、區塊確認的要求是遠遠高於普通錢包的，這樣的問題又是如何解決的呢？這就引入了一項新的技術。掃描區塊技術 Block scan

我們之前在深入區塊鏈技術部分介紹過，構成區塊鏈的四個核心技術是：P2P 網絡協議、分佈式一致性算法、加密簽名算法、賬戶與交易模型。這四個技術對應到數字貨幣錢包中就是，P2P 網絡、持久化存儲、賬戶以及私鑰管理、共識與交易驗證四大模塊。

其中，持久化存儲模塊是由全節點錢包自帶的嵌入式數據庫提供的，這裡有 LevelDB、BerkerlyDB、SQLite3 等多種選擇。但是無論選擇哪種嵌入式數據庫，都面臨了一個嚴峻問題，精細化的交易查詢驗證與性能不可兼具。換句話說，任何全節點的嵌入式數據庫都無法和伺服器級別的數據庫相媲美。對於平台開發來說，顯然選擇伺服器級別的數據庫是更為合適的選擇。那麼這裡就涉及了一個問題，如何把全節點錢包中的數據轉換成為數據庫伺服器中的數據，這就需要用到一種掃描區塊技術，簡稱掃塊。掃塊，顧名思義，就是指掃描全節點錢包中的所有區塊，然後將其解析後存儲到數據庫伺服器的過程，這些數據庫可以是 MongoDB，也可以是 MySQL，取決於你的業務需要。我們可以舉元界區塊鏈掃塊的例子，元界上的區塊結構與比特幣接近，你可以將其類比成比特幣區塊鏈。以下是 Python 代碼，展示了基於 MySQL 的關係型表結構，目的是從元界的嵌入式數據庫中掃描區塊，然後存儲到 MySQL 中。

def init_table(conn):
    tables = []
    tb_block = '''
    create table if not EXISTS block (
        number bigint primary KEY,
        hash char(64) not null,
        bits bigint,
        transaction_count INTEGER,
        mixhash VARCHAR (128),
        version char(8),
        merkle_tree_hash char(64),
        previous_block_hash CHAR (64),
        nonce varchar(128),
        time_samp bigint
    ) DEFAULT charset=utf8;
    '''
    tb_tx = '''
    create table if not EXISTS tx (
        id bigint PRIMARY KEY,
        block_height bigint REFERENCES block(id),
        hash char(64) not null
    )DEFAULT charset=utf8;
    '''
    tb_address = '''
    create table if not EXISTS address(
        id int PRIMARY KEY,
        address VARCHAR (64) UNIQUE
    )DEFAULT charset=utf8;
    '''
    tb_output = '''
    create table if not EXISTS tx_output(
        id bigint PRIMARY key,
        hash char(64) NOT NULL,
        tx_id bigint REFERENCES tx(id),
        output_index bigint not null,
        output_value bigint,
        address_id bigint REFERENCES address(id),
        script varchar(1024),
        asset varchar(64),
        decimal_number varchar(8)
    )DEFAULT charset=ascii;
    '''
    tb_output_fork = '''
    create table if not EXISTS tx_output_fork(
        id bigint PRIMARY key,
        hash char(64) NOT NULL,
        tx_id bigint,
        output_index bigint not null,
        output_value bigint,
        address_id bigint,
        script varchar(1024),
        asset varchar(64),
        decimal_number varchar(8)
    )DEFAULT charset=ascii;
    '''
    tb_tx_fork = '''
    create table if not EXISTS tx_fork (
        id bigint PRIMARY KEY,
        block_height bigint,
        hash char(64) not null
    )DEFAULT charset=ascii;
    '''
    tb_input_fork = '''
    create table if not EXISTS tx_input_fork(
        id bigint PRIMARY key,
        tx_id bigint,
        belong_tx_id bigint,
        tx_index bigint,
        tx_value bigint not null,
        script varchar(1024),
        address_id bigint,
        asset varchar(64),
        decimal_number varchar(8)
    )DEFAULT charset=ascii;
    '''
    tb_block_fork = '''
    create table if not EXISTS block_fork (
        number bigint primary KEY,
        hash char(64) not null,
        bits bigint,
        transaction_count INTEGER,
        mixhash VARCHAR (128),
        version char(8),
        merkle_tree_hash char(64),
        previous_block_hash CHAR (64),
        nonce varchar(128),
        time_samp bigint
    ) DEFAULT charset=ascii;
    '''
    tb_output_asset = '''
    create table if not EXISTS tx_output_asset(
        id bigint PRIMARY key,
        hash char(64) NOT NULL,
        tx_id bigint REFERENCES tx(id),
        output_index bigint not null,
        output_value bigint,
        address_id bigint REFERENCES address(id),
        asset_name varchar(64),
        issuer varchar(64),
        asset_type varchar(8),
        description varchar(64)
    )DEFAULT charset=utf8;
    '''
    tb_input = '''
    create table if not EXISTS tx_input(
        id bigint PRIMARY key,
        tx_id bigint REFERENCES tx(id),
        belong_tx_id bigint REFERENCES tx(id),
        tx_index bigint REFERENCES tx_output(output_index),
        tx_value bigint not null,
        script varchar(1024),
        address_id bigint REFERENCES address(id),
        asset varchar(64),
        decimal_number varchar(8)
    )DEFAULT charset=ascii;

我們按照元界區塊鏈的結構，可以把表分為四大類：第一類是區塊 block；第二類是交易 Tx；第三類是交易輸入輸出：tb_input，tb_output；第四類是分叉處理。下面我貼一個普通的以 JSON 格式展示的區塊和交易，你可以對比一下和上述表的關係：

從交易平台開發歸納出來的數字貨幣錢包服務。

數字貨幣錢包服務可以為交易平台其他模塊提供接口統一的 API，同時將不同的數據結構化到數據庫服務中，最後可以通過傳統高可用手段完成交易查詢和驗證。當然，這也和交易所的規模有關，如果是一個小型交易所，掃塊可能不是必需的，但是統一接口的 API 卻是必須的。我認為數字貨幣錢包服務應當有一套標準的錢包服務框架，支持主流數字貨幣，從而降低大家的使用和部署門檻，這也和我們上一篇聊到的 “區塊鏈即服務” 的概念不謀而合。可以說區塊鏈的配套設施和技術還很原始，還有很大的發展和提升的餘地。

在 Back-end 部分，元界區塊鏈承擔了貨物追蹤和訂單撮合的職能，而所有參與方可以通過搭建屬於自己的元界區塊鏈節點服務，獲得鏈上的訂單信息。在 Front-end 部分，工作人員可以通過移動設備獲得訂單數據，工作人員也可以像以前一樣，通過 IoT 藍牙傳感器獲得貨物的數據，接著通過移動設備上傳至伺服器，由伺服器挑選並計算後登記到元界區塊鏈上。兩者的比較公鏈方案與 DLT 技術相比，具備以下優勢。

透明度高：對於可公開的信息，零售環節的普通購買者也能夠通過區塊瀏覽器查詢到產品來源。
不可篡改性：由於公鏈的共識算法的不可篡改性比 DTL 技術更強，且參與的節點更多，所以數據的真實和可靠性更好。
Token 轉移：由於區塊鏈本身支持 Token 登記，所以物流提單可以做成 Token，變成有價證券進行轉移。
參與性強：任何客戶、政府或是監管機構都可以參與到供應鏈流程整個或某個特定環節，並跟蹤與瀏覽者相關的某些公開或非公開信息。
共享公鏈的基礎設施，例如參與方不需要再搭建可視化 Web 服務，直接使用區塊瀏覽器即可，貨物 Token 也可以參與到交易平台進行二級交易。 DLT 技術與公鏈方案相比，具備以下優勢。
可控性高：DLT 技術一般嚴格控制參與方，核心企業的權益可以得到保障。
可快速落地：方案和思路延續傳統技術，實施起來方便，對參與方的認知門檻要求低。
匿名性較好：一般公鏈並沒有提供清晰的權限管理和匿名技術，所以企業的數據必須脫敏才可以明文上鏈，而 DLT 技術不存在這個問題。
那麼行業現狀與實際的人才需求是怎樣的呢？我們一起來看看。目前區塊鏈領域的人才需求大致可以分為以下幾種。
根據客戶的需求，搭建基於 DLT 技術的分佈式賬本應用，在 DLT 上實現客戶要求的業務需求，這類與傳統解決方案型的人才十分接近。
公司已經具有了某些行業的資深經驗，目標是通過技術選型選擇某個公鏈，在此公鏈上開發基於區塊鏈的應用。目前遊戲與社交類的項目比較成熟，遊戲類有以太養貓、LeBloc 等，內容社區類有 Steemit、幣問、幣乎等項目。這一類的特點是可以很好地與現有技術結合，在業務層面利用區塊鏈的資產數字化特性，商業潛力大，技術發展空間也很大，進入門檻較低，風險較低。
公司獲得融資或者在海外發起 ICO，目標是研發新一代公鏈，這一類是為了通過改進現有的區塊鏈技術不足而創建的項目，技術發展空間最大，進入門檻最高，風險也最高。
區塊鏈生態基礎設施類。數字資產交易平台、數字資產管理、移動錢包、硬件冷錢包、數字金融媒體、區塊鏈諮詢、礦池運營等都屬於此類，這些都是目前商業利潤最高的區塊鏈產業，技術發展空間較大，進入門檻較低，風險也較低。目前區塊鏈的人才供應需求遠遠不足以支撐如此龐大的市場。換句話說就是人才極度稀缺，人才的稀缺與過高的估值形成鮮明對比，這也就是泡沫的形成。
與上面的分類相關的，是行業相應需求的編程語言。
第 1 類是 DLT 技術，由於超級賬本的流行，DLT 基本以 Golang 為主，但也會涉及應用可視化交互的問題，畢竟交付給客戶的時候，指望客戶使用命令行是不現實的，所以不可避免地需要具備一些前端技術。
第 2 類是公鏈應用，由於智能合約的存在，使用區塊鏈的門檻大大降低，最流行的以太坊智能合約是以類 JavaScript 的語言 Solidity 編寫的，目前也出現了不限定編程語言的智能合約區塊鏈。實際上，我認為 Solidity 比其他完全開放式的智能合約要安全許多，所以建議你如果打算學習智能合約，還是最好從以太坊入手。
第 3 類是研發自己的公鏈。目前主流的是靜態編譯型語言，以 C++ 和 Golang 最為常見，也有用 Rust、Java、C# 實現的公鏈，SPV 輕錢包型多使用 Java、Python、JavaScript 實現。可以說公鏈研發幾乎都涉及了主流編程語言。
第 4 類是在商業上與區塊鏈最為緊密，但是技術上卻是最不緊密的，整體技術棧與傳統互聯網網絡技術差別不大，例如搭建一個區塊鏈財經類網站，甚至不需要任何區塊鏈技術，但是對內容運營有較高要求。

交易過程 那麼說，用戶 A 拿 0.01BTC 換取了 B 的 10 個 ETP 的過程究竟是什麼樣的呢，我來舉一個例子。#

數字貨幣錢包的分類#

交易過程那麼說，用戶 A 拿 0.01BTC 換取了 B 的 10 個 ETP 的過程究竟是什麼樣的呢，我來舉一個例子。#