建站
咨詢
售后
建站咨詢
新聞中心
true是什么意思
字面意思就是真的，真實(shí)的，一般交流時(shí)候也理解為確定的，在代碼方法里面相當(dāng)于ON的功能，表示狀態(tài)。
創(chuàng)新互聯(lián)建站堅(jiān)實(shí)的技術(shù)研發(fā)基礎(chǔ)贏得了行業(yè)內(nèi)的良好口碑，公司成立10余年來，為上千企業(yè)提供過網(wǎng)站建設(shè)、軟件開發(fā)、搜索引擎優(yōu)化技術(shù)、互聯(lián)網(wǎng)大數(shù)據(jù)整合營銷服務(wù)，多年的技術(shù)服務(wù)成功經(jīng)驗(yàn)、眾多的客戶使我們能懂得更多，做得更好。"讓您的網(wǎng)站跑起來"是我們一直追求的目標(biāo)！
區(qū)塊鏈安全問題應(yīng)該怎么解決？
區(qū)塊鏈項(xiàng)目（尤其是公有鏈）的一個(gè)特點(diǎn)是開源。通過開放源代碼，來提高項(xiàng)目的可信性，也使更多的人可以參與進(jìn)來。但源代碼的開放也使得攻擊者對(duì)于區(qū)塊鏈系統(tǒng)的攻擊變得更加容易。近兩年就發(fā)生多起黑客攻擊事件，近日就有匿名幣Verge（XVG）再次遭到攻擊，攻擊者鎖定了XVG代碼中的某個(gè)漏洞，該漏洞允許惡意礦工在區(qū)塊上添加虛假的時(shí)間戳，隨后快速挖出新塊，短短的幾個(gè)小時(shí)內(nèi)謀取了近價(jià)值175萬美元的數(shù)字貨幣。雖然隨后攻擊就被成功制止，然而沒人能夠保證未來攻擊者是否會(huì)再次出擊。
當(dāng)然，區(qū)塊鏈開發(fā)者們也可以采取一些措施
一是使用專業(yè)的代碼審計(jì)服務(wù)，
二是了解安全編碼規(guī)范，防患于未然。
密碼算法的安全性
隨著量子計(jì)算機(jī)的發(fā)展將會(huì)給現(xiàn)在使用的密碼體系帶來重大的安全威脅。區(qū)塊鏈主要依賴橢圓曲線公鑰加密算法生成數(shù)字簽名來安全地交易，目前最常用的ECDSA、RSA、DSA 等在理論上都不能承受量子攻擊，將會(huì)存在較大的風(fēng)險(xiǎn)，越來越多的研究人員開始關(guān)注能夠抵抗量子攻擊的密碼算法。
當(dāng)然，除了改變算法，還有一個(gè)方法可以提升一定的安全性：
參考比特幣對(duì)于公鑰地址的處理方式，降低公鑰泄露所帶來的潛在的風(fēng)險(xiǎn)。作為用戶，尤其是比特幣用戶，每次交易后的余額都采用新的地址進(jìn)行存儲(chǔ)，確保有比特幣資金存儲(chǔ)的地址的公鑰不外泄。
共識(shí)機(jī)制的安全性
當(dāng)前的共識(shí)機(jī)制有工作量證明（Proof of Work，PoW）、權(quán)益證明（Proof of Stake，PoS）、授權(quán)權(quán)益證明（Delegated Proof of Stake，DPoS）、實(shí)用拜占庭容錯(cuò)（Practical Byzantine Fault Tolerance，PBFT）等。
PoW 面臨51%攻擊問題。由于PoW 依賴于算力，當(dāng)攻擊者具備算力優(yōu)勢時(shí)，找到新的區(qū)塊的概率將會(huì)大于其他節(jié)點(diǎn)，這時(shí)其具備了撤銷已經(jīng)發(fā)生的交易的能力。需要說明的是，即便在這種情況下，攻擊者也只能修改自己的交易而不能修改其他用戶的交易（攻擊者沒有其他用戶的私鑰）。
在PoS 中，攻擊者在持有超過51%的Token 量時(shí)才能夠攻擊成功，這相對(duì)于PoW 中的51%算力來說，更加困難。
在PBFT 中，惡意節(jié)點(diǎn)小于總節(jié)點(diǎn)的1/3 時(shí)系統(tǒng)是安全的。總的來說，任何共識(shí)機(jī)制都有其成立的條件，作為攻擊者，還需要考慮的是，一旦攻擊成功，將會(huì)造成該系統(tǒng)的價(jià)值歸零，這時(shí)攻擊者除了破壞之外，并沒有得到其他有價(jià)值的回報(bào)。
對(duì)于區(qū)塊鏈項(xiàng)目的設(shè)計(jì)者而言，應(yīng)該了解清楚各個(gè)共識(shí)機(jī)制的優(yōu)劣，從而選擇出合適的共識(shí)機(jī)制或者根據(jù)場景需要，設(shè)計(jì)新的共識(shí)機(jī)制。
智能合約的安全性
智能合約具備運(yùn)行成本低、人為干預(yù)風(fēng)險(xiǎn)小等優(yōu)勢，但如果智能合約的設(shè)計(jì)存在問題，將有可能帶來較大的損失。2016 年6 月，以太坊最大眾籌項(xiàng)目The DAO 被攻擊，黑客獲得超過350 萬個(gè)以太幣，后來導(dǎo)致以太坊分叉為ETH 和ETC。
對(duì)此提出的措施有兩個(gè)方面：
一是對(duì)智能合約進(jìn)行安全審計(jì)，
二是遵循智能合約安全開發(fā)原則。
智能合約的安全開發(fā)原則有：對(duì)可能的錯(cuò)誤有所準(zhǔn)備，確保代碼能夠正確的處理出現(xiàn)的bug 和漏洞；謹(jǐn)慎發(fā)布智能合約，做好功能測試與安全測試，充分考慮邊界；保持智能合約的簡潔；關(guān)注區(qū)塊鏈威脅情報(bào)，并及時(shí)檢查更新；清楚區(qū)塊鏈的特性，如謹(jǐn)慎調(diào)用外部合約等。
數(shù)字錢包的安全性
數(shù)字錢包主要存在三方面的安全隱患：第一，設(shè)計(jì)缺陷。2014 年底，某簽報(bào)因一個(gè)嚴(yán)重的隨機(jī)數(shù)問題（R 值重復(fù)）造成用戶丟失數(shù)百枚數(shù)字資產(chǎn)。第二，數(shù)字錢包中包含惡意代碼。第三，電腦、手機(jī)丟失或損壞導(dǎo)致的丟失資產(chǎn)。
應(yīng)對(duì)措施主要有四個(gè)方面：
一是確保私鑰的隨機(jī)性；
二是在軟件安裝前進(jìn)行散列值校驗(yàn)，確保數(shù)字錢包軟件沒有被篡改過；
三是使用冷錢包；
四是對(duì)私鑰進(jìn)行備份。
如何辯別真正的區(qū)塊鏈數(shù)字貨幣
某個(gè)數(shù)字貨幣是否是一個(gè)有價(jià)值的幣種，在目前基本屬于“天使輪”階段而言，判定標(biāo)準(zhǔn)有三個(gè)，一是團(tuán)隊(duì)，二是經(jīng)濟(jì)模型，三是行業(yè)需求。
團(tuán)隊(duì)的隨機(jī)性太大，在此不進(jìn)行討論。本文首先對(duì)數(shù)字貨幣的經(jīng)濟(jì)模型進(jìn)行一個(gè)詳盡地分析，在隨后的文章中，筆者會(huì)根據(jù)不同行業(yè)對(duì)部分?jǐn)?shù)字貨幣進(jìn)行剖析。
嚴(yán)格來講，本文所涉及的經(jīng)濟(jì)模型，并不完全等同于經(jīng)濟(jì)學(xué)中所述概念。特指在數(shù)字貨幣中，貨幣的共識(shí)機(jī)制與激勵(lì)機(jī)制。
一、共識(shí)機(jī)制
共識(shí)機(jī)制是區(qū)塊鏈系統(tǒng)中各個(gè)節(jié)點(diǎn)達(dá)成一致的策略和方法，應(yīng)根據(jù)系統(tǒng)類型及應(yīng)用場景的不同靈活選取。
常用的共識(shí)機(jī)制主要有PoW、PoS、DPoS、PBFT（及其變種）等。另外，基于區(qū)塊鏈技術(shù)的不同應(yīng)用場景，以及各種共識(shí)機(jī)制的特性，本文按照以下維度來評(píng)價(jià)各種共識(shí)機(jī)制的技術(shù)水平：
a) 合規(guī)監(jiān)管：是否支持超級(jí)權(quán)限節(jié)點(diǎn)對(duì)全網(wǎng)節(jié)點(diǎn)、數(shù)據(jù)進(jìn)行監(jiān)管；
b) 性能效率：交易達(dá)成共識(shí)被確認(rèn)的效率；
c) 資源消耗：共識(shí)過程中耗費(fèi)的CPU、網(wǎng)絡(luò)輸入輸出、存儲(chǔ)等計(jì)算機(jī)資源；
d) 容錯(cuò)性：防攻擊、防欺詐的能力。
1、PoW(Proof of Work)工作量證明：依賴機(jī)器進(jìn)行數(shù)學(xué)運(yùn)算來獲取記賬權(quán)，資源消耗相比其他共識(shí)機(jī)制高、可監(jiān)管性弱，同時(shí)每次達(dá)成共識(shí)需要全網(wǎng)共同參與運(yùn)算，性能效率比較低，容錯(cuò)性方面允許全網(wǎng)50%節(jié)點(diǎn)出錯(cuò)。
優(yōu)點(diǎn)：（1）安全性高，系統(tǒng)穩(wěn)定性好；（2）節(jié)點(diǎn)間無需交換額外的信息即可達(dá)成共識(shí)；（3）破壞系統(tǒng)需要投入極大的成本；（4）算法簡單，容易實(shí)現(xiàn)。
缺點(diǎn)：（1）需要投入硬件成本及能源成本；（2）區(qū)塊的確認(rèn)時(shí)間較長，而且需要等待多個(gè)確認(rèn)；（3）由于比特幣的先發(fā)優(yōu)勢，新的區(qū)塊鏈必須找到一種不同的散列算法，否則就會(huì)面臨比特幣的算力攻擊；（4）容易產(chǎn)生分叉。
2、PoS（Proof of Stake）權(quán)益證明：主要思想是節(jié)點(diǎn)記賬權(quán)的獲得難度與節(jié)點(diǎn)持有的權(quán)益成反比，相對(duì)于PoW，一定程度減少了數(shù)學(xué)運(yùn)算帶來的資源消耗，性能也得到了相應(yīng)的提升，但依然是基于哈希運(yùn)算競爭獲取記賬權(quán)的方式，可監(jiān)管性弱。該共識(shí)機(jī)制容錯(cuò)性和PoW相同。
優(yōu)點(diǎn)：（1）縮短了共識(shí)達(dá)成的時(shí)間；（2）不再需要大量消耗能源挖礦。
缺點(diǎn)：（1）還是需要挖礦，存在一定的資源浪費(fèi)；（2）所有的確認(rèn)都只是一個(gè)概率上的表達(dá)，而不是一個(gè)確定性的事情，理論上有可能存在其他攻擊影響。
3、DPoS (Delegate Proof of Stake) 股份授權(quán)證明：與PoS的主要區(qū)別在于節(jié)點(diǎn)選舉若干代理人，由代理人驗(yàn)證和記賬。其合規(guī)監(jiān)管、性能、資源消耗和容錯(cuò)性與PoS相似。
優(yōu)點(diǎn)：（1）通過使用“代議制”，大幅提高達(dá)成共識(shí)的時(shí)間，為商業(yè)應(yīng)用的開發(fā)提供了客觀條件；（2）大幅度減少了資源消耗。
缺點(diǎn)：（1）存在“代表”作惡的情況，需要制定相應(yīng)的約束條件及替代方案；（2）需要在總節(jié)點(diǎn)數(shù)量與“代表”數(shù)量之間做好平衡。
4、PBFT（Practical Byzantine Fault Tolerance）實(shí)用拜占庭容錯(cuò)：一種采用許可投票、少數(shù)服從多數(shù)來選舉領(lǐng)導(dǎo)者進(jìn)行記賬的共識(shí)機(jī)制，但該共識(shí)機(jī)制允許拜占庭容錯(cuò)。該共識(shí)機(jī)制允許強(qiáng)監(jiān)管節(jié)點(diǎn)參與，具備權(quán)限分級(jí)能力，性能更高，耗能更低，該算法每輪記賬都會(huì)由全網(wǎng)節(jié)點(diǎn)共同選舉領(lǐng)導(dǎo)者，允許33%的節(jié)點(diǎn)作惡，容錯(cuò)性為33%。
優(yōu)點(diǎn)：（1）系統(tǒng)運(yùn)轉(zhuǎn)可以脫離幣的存在，PBFT算法共識(shí)各節(jié)點(diǎn)由業(yè)務(wù)的參與方或者監(jiān)管方組成，安全性與穩(wěn)定性由業(yè)務(wù)相關(guān)方保證；（2）共識(shí)的時(shí)延大約在2~5秒鐘，基本達(dá)到商用實(shí)時(shí)處理的要求；（3）共識(shí)效率高，可滿足高頻交易量的需求。
缺點(diǎn)：（1）當(dāng)有1/3或以上記賬人停止工作后，系統(tǒng)將無法提供服務(wù)；（2）當(dāng)有1/3或以上記賬人聯(lián)合作惡，且其它所有的記賬人被恰好分割為兩個(gè)網(wǎng)絡(luò)孤島時(shí)，惡意記賬人可以使系統(tǒng)出現(xiàn)分叉，但是會(huì)留下密碼學(xué)證據(jù)。
二、激勵(lì)機(jī)制
激勵(lì)機(jī)制與共識(shí)機(jī)制有強(qiáng)關(guān)聯(lián)性的，不夸張的說，在一定程度上，共識(shí)機(jī)制決定了激勵(lì)機(jī)制的設(shè)計(jì)方式，也就是說，共識(shí)機(jī)制是激勵(lì)機(jī)制的充分條件（規(guī)模極小的私有鏈除外）。就二者在區(qū)塊鏈系統(tǒng)內(nèi)的關(guān)系而言，共識(shí)機(jī)制的目的是產(chǎn)生區(qū)塊，而激勵(lì)機(jī)制則是給予區(qū)塊生產(chǎn)者的獎(jiǎng)勵(lì)。
單就激勵(lì)機(jī)制而言，即數(shù)字貨幣如何發(fā)放。其中涉及到總量是否恒定，數(shù)字貨幣總量如何分配（投資人、團(tuán)隊(duì)、礦工等），激活/解鎖/釋放/回購機(jī)制，數(shù)字貨幣權(quán)益等。
從二者關(guān)系看，數(shù)字貨幣分為兩種：一種是區(qū)塊鏈項(xiàng)目，擁有區(qū)塊鏈完整的架構(gòu)，其經(jīng)濟(jì)模型由共識(shí)機(jī)制與激勵(lì)機(jī)制組成；另一種是部署于區(qū)塊鏈上的分布式應(yīng)用所發(fā)行的數(shù)字貨幣，僅需要設(shè)計(jì)優(yōu)化后的激勵(lì)機(jī)制以維系整個(gè)應(yīng)用的良性運(yùn)轉(zhuǎn)即可。
2.1 區(qū)塊鏈項(xiàng)目的激勵(lì)機(jī)制
激勵(lì)機(jī)制的設(shè)計(jì)源于以比特幣為代表的區(qū)塊鏈1.0時(shí)代。
比特幣是一個(gè)完全開源的公鏈項(xiàng)目，沒有眾籌，沒有項(xiàng)目方，整個(gè)區(qū)塊鏈運(yùn)行的關(guān)鍵在于三點(diǎn)：
第一是底層代碼的準(zhǔn)確性（已經(jīng)經(jīng)過了時(shí)間的檢驗(yàn)）；
第二是共識(shí)算法，采用PoW機(jī)制，簡單易用，在前期運(yùn)行比特幣系統(tǒng)過程中，并無過多的資源浪費(fèi)，這為大量普通網(wǎng)絡(luò)節(jié)點(diǎn)接入比特幣系統(tǒng)提供了便捷，然而在專業(yè)的比特幣挖礦機(jī)器產(chǎn)生之后，難度系數(shù)增加，資源浪費(fèi)在所難免，是為后話（中本聰可能低估了群體的智慧）；
第三是，激勵(lì)機(jī)制的設(shè)計(jì)，基于開源的公鏈必須提供給網(wǎng)絡(luò)節(jié)點(diǎn)持續(xù)運(yùn)行所必要的動(dòng)力。比特幣約每十分鐘出一個(gè)區(qū)塊，前21萬個(gè)區(qū)塊，大概需要4年時(shí)間，第一個(gè)四年期每個(gè)區(qū)塊的激勵(lì)為：50個(gè)比特幣與該區(qū)塊內(nèi)所有的交易費(fèi)用，隨后的每21萬個(gè)區(qū)塊，獎(jiǎng)勵(lì)減半，在2140年比特幣區(qū)塊獎(jiǎng)勵(lì)將完全由區(qū)塊中的交易費(fèi)用構(gòu)成。
幾個(gè)要素構(gòu)成了比特幣的激勵(lì)機(jī)制：
（1）比特幣的發(fā)行總量為2100萬枚，不增發(fā)；
（2）PoW共識(shí)機(jī)制決定了比特幣的分配方式為算力產(chǎn)生，100%分配給礦工；
（3 ）約每十分鐘產(chǎn)生一個(gè)區(qū)塊，區(qū)塊初始獎(jiǎng)勵(lì)為50個(gè)比特幣，每21萬個(gè)區(qū)塊之后產(chǎn)量減半，具有“通縮”屬性，無回購銷毀機(jī)制；
（4） 比特幣交易需要支付給礦工一定的數(shù)據(jù)打包費(fèi)用。
以上是第一套區(qū)塊鏈的激勵(lì)機(jī)制：穩(wěn)定的數(shù)字貨幣供應(yīng)，維持整個(gè)系統(tǒng)運(yùn)轉(zhuǎn)的礦工團(tuán)體及數(shù)字貨幣分配方式，數(shù)字貨幣釋放機(jī)制，數(shù)字貨幣交易方式。這也成為區(qū)塊鏈項(xiàng)目中激勵(lì)機(jī)制設(shè)計(jì)的基礎(chǔ)框架。
隨著比特幣知名度的上升，用戶群體日益擴(kuò)大，資源浪費(fèi)，效率偏低等問題逐漸凸顯，后續(xù)區(qū)塊鏈項(xiàng)目在激勵(lì)機(jī)制設(shè)計(jì)上開始進(jìn)行改進(jìn)。
比如為了減少資源消耗而采取的PoS共識(shí)算法，在此種算法下新“挖掘”出的數(shù)字貨幣為全員共享而非礦工獨(dú)享，客觀上打壓了礦工的積極性，從而采用了數(shù)字貨幣“通脹”的形式，即增發(fā)一定數(shù)量的數(shù)字貨幣，然而數(shù)字貨幣的增發(fā)必然會(huì)造成貶值，因此，需要將新增的一部分?jǐn)?shù)字貨幣返還持幣者作以補(bǔ)償。
再比如為了提高效率而采取DPoS共識(shí)算法，設(shè)計(jì)機(jī)制與PoS類似，只不過將新增數(shù)字貨幣的分配方式從由代碼約定改為了由超級(jí)節(jié)點(diǎn)主觀分發(fā)。
總而言之，激勵(lì)機(jī)制的設(shè)計(jì)是不斷進(jìn)化中的，但是仍然未擺脫經(jīng)典模式的基本框架。
2.2 分布式應(yīng)用的激勵(lì)機(jī)制
分布式應(yīng)用是指，部署與通用公有鏈或者行業(yè)公有鏈上的應(yīng)用，如果把公鏈理解為操作系統(tǒng)，那么分布式應(yīng)用就是適配于這個(gè)系統(tǒng)的Applications。通常情況下，這些應(yīng)用都會(huì)在所部署的公鏈上發(fā)行數(shù)字貨幣，暫且稱之為應(yīng)用型數(shù)字貨幣。由于應(yīng)用基于公鏈創(chuàng)建，所有特性受制于公鏈所能提供的功能。
應(yīng)用型數(shù)字貨幣的經(jīng)濟(jì)模型中，不需要進(jìn)行共識(shí)機(jī)制的設(shè)計(jì)，只需要設(shè)計(jì)健康的激勵(lì)機(jī)制即可。
比如，頭部數(shù)字貨幣交易所Binance發(fā)布了一種數(shù)字貨幣，簡稱“BNB”，它是基于以太坊區(qū)塊鏈的ERC20標(biāo)準(zhǔn)數(shù)字貨幣。
BNB總量被限定為2億個(gè)，并承諾永不增發(fā)。50%數(shù)字貨幣對(duì)外發(fā)售，40%團(tuán)隊(duì)持有，早期的天使投資人持有10%。持有BNB的用戶，在Binance平臺(tái)上進(jìn)行交易，可享受用足額BNB抵扣并享受5年內(nèi)手續(xù)費(fèi)逐級(jí)遞減的折扣；除了享受手續(xù)費(fèi)折扣外，持有BNB的用戶可以享受眾多的空投活動(dòng)。在這些權(quán)益之外，BNB項(xiàng)目團(tuán)隊(duì)會(huì)在每季度拿出當(dāng)季凈利潤的20%用于回購BNB并銷毀，直至所有BNB總量為1億個(gè)為止，具備了“通縮”屬性。
應(yīng)用型數(shù)字貨幣的經(jīng)濟(jì)模型大體如下：數(shù)字貨幣總量一般恒定；數(shù)字貨幣分配方式為：早期投資者與項(xiàng)目團(tuán)隊(duì)持有一定比例的數(shù)字貨幣（約50%）；持有數(shù)字貨幣享受該分布式應(yīng)用的部分權(quán)益。
當(dāng)然，在數(shù)字貨幣數(shù)量（是否增發(fā)需根據(jù)所部屬平臺(tái)和項(xiàng)目需求而定）、分配方式、比例和持幣權(quán)益方面都能依據(jù)項(xiàng)目需求進(jìn)行調(diào)整。
三、如何設(shè)計(jì)數(shù)字貨幣的經(jīng)濟(jì)模型
在這里，應(yīng)該明確一個(gè)理念，價(jià)值回歸。我們可以將它延伸理解為互聯(lián)網(wǎng)下的共享經(jīng)濟(jì)模式在區(qū)塊鏈領(lǐng)域的擴(kuò)展。即區(qū)塊鏈項(xiàng)目的價(jià)值是由參與者共同創(chuàng)造的，應(yīng)該由區(qū)塊鏈參與者共享。
那么如果要為一個(gè)區(qū)塊鏈項(xiàng)目或者分布式應(yīng)用設(shè)計(jì)一個(gè)合理的經(jīng)濟(jì)模型，應(yīng)該從哪些方面加以考慮呢？
3.1 共識(shí)機(jī)制的選用
對(duì)區(qū)塊鏈項(xiàng)目而言，經(jīng)濟(jì)模型的設(shè)計(jì)比較難，即便現(xiàn)有的幾大區(qū)塊鏈項(xiàng)目，其經(jīng)濟(jì)模型的設(shè)計(jì)也并非盡善盡美的。
在共識(shí)算法的選擇上，要參照符合監(jiān)管，利于性能效率提升，盡量避免過度的資源消耗，具有一定的容錯(cuò)性四個(gè)方面加以考慮。
結(jié)合主流的共識(shí)算法如PoW、PoS、DPoS、PBFT（及其變種）等，其中DPoS、PBFT（及其變種）兩種算法在上述四方面能夠做到一個(gè)較好的平衡。目前國內(nèi)的區(qū)塊鏈項(xiàng)目多采用PBFT及其變種算法作為共識(shí)機(jī)制即是例證。
當(dāng)然，隨著未來人類科技的不斷進(jìn)步，更新的、更能夠得到有效監(jiān)管、效率更高的算法可能會(huì)逐漸被人發(fā)現(xiàn)并加以運(yùn)用。
3.2 激勵(lì)機(jī)制的設(shè)計(jì)
激勵(lì)機(jī)制的重要性無需贅言。在確定采取何種共識(shí)機(jī)制之后，下一步就需要設(shè)計(jì)合理的激勵(lì)機(jī)制以保證區(qū)塊鏈項(xiàng)目的良好運(yùn)轉(zhuǎn)和持續(xù)發(fā)展。
下面將從數(shù)字貨幣總量、分配方式、釋放/回購機(jī)制、持幣權(quán)益四個(gè)方面進(jìn)行探討。
（1）數(shù)字貨幣總量供應(yīng)
數(shù)字貨幣的總量依據(jù)所屬行業(yè)及項(xiàng)目需求而定，避免預(yù)期價(jià)格異常而導(dǎo)致與法幣兌換差額較大：例如，一個(gè)關(guān)于資產(chǎn)管理的區(qū)塊鏈項(xiàng)目，預(yù)期資產(chǎn)管理市值為50億美元，發(fā)行數(shù)字貨幣的數(shù)量應(yīng)不少于50億枚為佳。
（2） 數(shù)字貨幣分配方式
這里的分配方式是指，在所發(fā)行數(shù)字貨幣的總數(shù)中，早期投資者、團(tuán)隊(duì)、社區(qū)等分別持有的數(shù)量。
在當(dāng)前市場中，為了維持價(jià)格的穩(wěn)定，防止游子惡意做空，促進(jìn)區(qū)塊鏈項(xiàng)目生態(tài)健康，團(tuán)隊(duì)持有一定比例的數(shù)字貨幣是十分必要的。
（3） 數(shù)字貨幣釋放/回購機(jī)制
在比特幣中即“挖礦”，在非PoW共識(shí)機(jī)制的區(qū)塊鏈項(xiàng)目中，數(shù)字貨幣的有三種形式釋放：一種是前期預(yù)售；第二種就是行為（包括但不限于：交易、運(yùn)動(dòng)、內(nèi)容生產(chǎn)）釋放；最后一種為線性釋放，即固定周期內(nèi)釋放固定數(shù)量的數(shù)字貨幣，直至全部釋放完畢（三種方法也可同時(shí)使用）。
回購機(jī)制是項(xiàng)目方對(duì)持幣者的回饋措施之一，使用回購銷毀的方式對(duì)市值進(jìn)行管理，對(duì)所有持幣者進(jìn)行“分紅”。
（4） 數(shù)字貨幣權(quán)益
根據(jù)區(qū)塊鏈賦予不同的行業(yè)來看，一般具有交易、應(yīng)用中消費(fèi)、持幣享受平臺(tái)利潤分成（類似于持股）、空投等福利。
四、案例示范
項(xiàng)目名稱：X
代幣名稱：XT
核心產(chǎn)品：基于AI大數(shù)據(jù)的數(shù)字貨幣智能投顧平臺(tái)
1 行業(yè)背景
尋找行業(yè)痛點(diǎn)：資產(chǎn)管理需要專業(yè)的團(tuán)隊(duì)與知識(shí)，然而現(xiàn)在大多數(shù)數(shù)字貨幣投資者并不具備；數(shù)字貨幣市場行情波動(dòng)巨大，在行情下挫中，投資者無法對(duì)資產(chǎn)進(jìn)行保值。
2 自身優(yōu)勢
在股票、期貨市場深耕多年，有成熟、高素質(zhì)資產(chǎn)管理團(tuán)隊(duì)；AI大數(shù)據(jù)團(tuán)隊(duì)技術(shù)實(shí)力強(qiáng)勁。
3 市場調(diào)研
進(jìn)行市場調(diào)研之后，預(yù)估未來5年內(nèi)，資產(chǎn)管理的市值約為10億美元。
4 數(shù)字貨幣總量
在考慮預(yù)期資產(chǎn)管理市值、開發(fā)周期與難度后，考慮發(fā)行基于以太坊ERC20數(shù)字貨幣XT，數(shù)量20億枚，永不增發(fā)。
5 分配方式
早期投資人持有10%，團(tuán)隊(duì)持有20%，商務(wù)運(yùn)營10%，社區(qū)建設(shè)10%，投資者持有50%。
6 數(shù)字貨幣釋放/回購機(jī)制
釋放機(jī)制分為三類：
第一類：商務(wù)運(yùn)營持幣部分為全部解鎖，用途限定為商務(wù)及運(yùn)營活動(dòng)；
第二類：社區(qū)建設(shè)部分的釋放機(jī)制為，社區(qū)成員發(fā)布獨(dú)家資訊、合作平臺(tái)發(fā)布獨(dú)家項(xiàng)目進(jìn)展等行為，根據(jù)參與ID數(shù)，釋放相應(yīng)比例XT（發(fā)布者與參與者各獲得50%），直至全部釋放完成（釋放完成之后，后續(xù)獎(jiǎng)勵(lì)來源于平臺(tái)利潤池）；
第三類：投資者持主流數(shù)字貨幣，在平臺(tái)中進(jìn)行資產(chǎn)管理，根據(jù)兌換比例，釋放一定數(shù)量的XT，早期投資人與團(tuán)隊(duì)持有部分同步，按比例解鎖；
回購機(jī)制為：所得利潤（以XT計(jì)）的50%返還給持幣者；剩余進(jìn)入平臺(tái)利潤池中，按月對(duì)利潤池中的50%的XT進(jìn)行銷毀，直至XT總量為10億枚；其余作為平臺(tái)生態(tài)建設(shè)基金；
7 數(shù)字貨幣權(quán)益
利潤分成：持有XT，是為平臺(tái)用戶，可以享受平臺(tái)利潤50%的分成；
平臺(tái)治理：參與平臺(tái)活動(dòng)享受XT獎(jiǎng)勵(lì)、其他項(xiàng)目方的空投活動(dòng)；
功能定制：可基于平臺(tái)AI大數(shù)據(jù)，投資者可購買針對(duì)個(gè)人交易策略進(jìn)行優(yōu)化的服務(wù)
共識(shí)算法系列之一：私鏈的raft算法和聯(lián)盟鏈的 pbft 算法
對(duì)數(shù)據(jù)順序達(dá)成一致共識(shí)是很多共識(shí)算法要解決的本質(zhì)問題
Fabic的pbft算法實(shí)現(xiàn)
現(xiàn)階段的共識(shí)算法主要可以分成三大類：公鏈，聯(lián)盟鏈和私鏈
私鏈，所有節(jié)點(diǎn)可信
聯(lián)盟鏈，存在對(duì)等的不信任節(jié)點(diǎn)
私鏈：私鏈的共識(shí)算法即區(qū)塊鏈這個(gè)概念還沒普及時(shí)的傳統(tǒng)分布式系統(tǒng)里的共識(shí)算法，比如 zookeeper 的 zab 協(xié)議，就是類 paxos 算法的一種。私鏈的適用環(huán)境一般是不考慮集群中存在作惡節(jié)點(diǎn)，只考慮因?yàn)橄到y(tǒng)或者網(wǎng)絡(luò)原因?qū)е碌墓收瞎?jié)點(diǎn)。
聯(lián)盟鏈：聯(lián)盟鏈中，經(jīng)典的代表項(xiàng)目是 Hyperledger 組織下的 Fabric 項(xiàng)目， Fabric0.6 版本使用的就是 pbft 算法。聯(lián)盟鏈的適用環(huán)境除了需要考慮集群中存在故障節(jié)點(diǎn)，還需要考慮集群中存在作惡節(jié)點(diǎn)。對(duì)于聯(lián)盟鏈，每個(gè)新加入的節(jié)點(diǎn)都是需要驗(yàn)證和審核的。
公鏈：公鏈不僅需要考慮網(wǎng)絡(luò)中存在故障節(jié)點(diǎn)，還需要考慮作惡節(jié)點(diǎn)，這一點(diǎn)和聯(lián)盟鏈?zhǔn)穷愃频?。和?lián)盟鏈最大的區(qū)別就是，公鏈中的節(jié)點(diǎn)可以很自由的加入或者退出，不需要嚴(yán)格的驗(yàn)證和審核。
在公有鏈中用的最多的是pow算法和pos算法，這些算法都是參與者的利益直接相關(guān)，通過利益來制約節(jié)點(diǎn)誠實(shí)的工作，解決分布式系統(tǒng)中的拜占庭問題。拜占庭容錯(cuò)算法是一種狀態(tài)機(jī)副本復(fù)制算法，通過節(jié)點(diǎn)間的多輪消息傳遞，網(wǎng)絡(luò)內(nèi)的所有誠實(shí)節(jié)點(diǎn)就可以達(dá)成一致的共識(shí)。
使用拜占庭容錯(cuò)算法不需要發(fā)行加密貨幣，但是只能用于私有鏈或者聯(lián)盟鏈，需要對(duì)節(jié)點(diǎn)的加入進(jìn)行權(quán)限控制；不能用于公有鏈，因?yàn)楣墟溨兴泄?jié)點(diǎn)都可以隨意加入退出，無法抵擋女巫攻擊（sybil attack）
raft 算法包含三種角色，分別是：跟隨者（ follower ），候選人（candidate ）和領(lǐng)導(dǎo)者（ leader ）。集群中的一個(gè)節(jié)點(diǎn)在某一時(shí)刻只能是這三種狀態(tài)的其中一種，這三種角色是可以隨著時(shí)間和條件的變化而互相轉(zhuǎn)換的。
raft 算法主要有兩個(gè)過程：一個(gè)過程是領(lǐng)導(dǎo)者選舉，另一個(gè)過程是日志復(fù)制，其中日志復(fù)制過程會(huì)分記錄日志和提交數(shù)據(jù)兩個(gè)階段。raft 算法支持最大的容錯(cuò)故障節(jié)點(diǎn)是（N-1）/2，其中 N 為 集群中總的節(jié)點(diǎn)數(shù)量。
國外有一個(gè)動(dòng)畫介紹raft算法介紹的很透徹，鏈接地址為： 。這個(gè)動(dòng)畫主要包含三部分內(nèi)容，第一部分介紹簡單版的領(lǐng)導(dǎo)者選舉和日志復(fù)制的過程，第二部分內(nèi)容介紹詳細(xì)版的領(lǐng)導(dǎo)者選舉和日志復(fù)制的過程，第三部分內(nèi)容介紹的是如果遇到網(wǎng)絡(luò)分區(qū)（腦裂），raft 算法是如何恢復(fù)網(wǎng)絡(luò)一致的。
pbft 算法的提出主要是為了解決拜占庭將軍問題
要讓這個(gè)問題有解，有一個(gè) 十分重要的前提 ，那就是 信道必須是可靠的 。如果信道不能保證可靠，那么拜占庭問題無解。關(guān)于信道可靠問題，會(huì)引出兩軍問題。兩軍問題的結(jié)論是，在一個(gè)不可靠的通信鏈路上試圖通過通信以達(dá)成一致是基本不可能或者十分困難的。
拜占庭將軍問題最早是由 Leslie Lamport 與另外兩人在 1982 年發(fā)表的論文《The Byzantine Generals Problem 》提出的， 他證明了在將軍總數(shù)大于 3f ，背叛者為f 或者更少時(shí)，忠誠的將軍可以達(dá)成命令上的一致，即 3f+1=n 。算法復(fù)雜度為 o（n^(f+1)) 。而 Miguel Castro (卡斯特羅)和 Barbara Liskov （利斯科夫）在1999年發(fā)表的論文《 Practical Byzantine Fault Tolerance 》中首次提出 pbft 算法，該算法容錯(cuò)數(shù)量也滿足 3f+1=n ，算法復(fù)雜度為 o（n^2）。
首先我們先來思考一個(gè)問題，為什么 pbft 算法的最大容錯(cuò)節(jié)點(diǎn)數(shù)量是（n-1）/3，而 raft 算法的最大容錯(cuò)節(jié)點(diǎn)數(shù)量是（n-1）/2 ？
對(duì)于raft算法，raft算法的的容錯(cuò)只支持容錯(cuò)故障節(jié)點(diǎn)，不支持容錯(cuò)作惡節(jié)點(diǎn)。什么是故障節(jié)點(diǎn)呢？就是節(jié)點(diǎn)因?yàn)橄到y(tǒng)繁忙、宕機(jī)或者網(wǎng)絡(luò)問題等其它異常情況導(dǎo)致的無響應(yīng)，出現(xiàn)這種情況的節(jié)點(diǎn)就是故障節(jié)點(diǎn)。那什么是作惡節(jié)點(diǎn)呢？作惡節(jié)點(diǎn)除了可以故意對(duì)集群的其它節(jié)點(diǎn)的請求無響應(yīng)之外，還可以故意發(fā)送錯(cuò)誤的數(shù)據(jù)，或者給不同的其它節(jié)點(diǎn)發(fā)送不同的數(shù)據(jù)，使整個(gè)集群的節(jié)點(diǎn)最終無法達(dá)成共識(shí)，這種節(jié)點(diǎn)就是作惡節(jié)點(diǎn)。
raft 算法只支持容錯(cuò)故障節(jié)點(diǎn)，假設(shè)集群總節(jié)點(diǎn)數(shù)為n，故障節(jié)點(diǎn)為 f ，根據(jù)小數(shù)服從多數(shù)的原則，集群里正常節(jié)點(diǎn)只需要比 f 個(gè)節(jié)點(diǎn)再多一個(gè)節(jié)點(diǎn)，即 f+1 個(gè)節(jié)點(diǎn)，正確節(jié)點(diǎn)的數(shù)量就會(huì)比故障節(jié)點(diǎn)數(shù)量多，那么集群就能達(dá)成共識(shí)。因此 raft 算法支持的最大容錯(cuò)節(jié)點(diǎn)數(shù)量是（n-1）/2。
對(duì)于 pbft 算法，因?yàn)?pbft 算法的除了需要支持容錯(cuò)故障節(jié)點(diǎn)之外，還需要支持容錯(cuò)作惡節(jié)點(diǎn)。假設(shè)集群節(jié)點(diǎn)數(shù)為 N，有問題的節(jié)點(diǎn)為 f。有問題的節(jié)點(diǎn)中，可以既是故障節(jié)點(diǎn)，也可以是作惡節(jié)點(diǎn)，或者只是故障節(jié)點(diǎn)或者只是作惡節(jié)點(diǎn)。那么會(huì)產(chǎn)生以下兩種極端情況：
第一種情況，f 個(gè)有問題節(jié)點(diǎn)既是故障節(jié)點(diǎn)，又是作惡節(jié)點(diǎn)，那么根據(jù)小數(shù)服從多數(shù)的原則，集群里正常節(jié)點(diǎn)只需要比f個(gè)節(jié)點(diǎn)再多一個(gè)節(jié)點(diǎn)，即 f+1 個(gè)節(jié)點(diǎn)，確節(jié)點(diǎn)的數(shù)量就會(huì)比故障節(jié)點(diǎn)數(shù)量多，那么集群就能達(dá)成共識(shí)。也就是說這種情況支持的最大容錯(cuò)節(jié)點(diǎn)數(shù)量是 （n-1）/2。
第二種情況，故障節(jié)點(diǎn)和作惡節(jié)點(diǎn)都是不同的節(jié)點(diǎn)。那么就會(huì)有 f 個(gè)問題節(jié)點(diǎn)和 f 個(gè)故障節(jié)點(diǎn)，當(dāng)發(fā)現(xiàn)節(jié)點(diǎn)是問題節(jié)點(diǎn)后，會(huì)被集群排除在外，剩下 f 個(gè)故障節(jié)點(diǎn)，那么根據(jù)小數(shù)服從多數(shù)的原則，集群里正常節(jié)點(diǎn)只需要比f個(gè)節(jié)點(diǎn)再多一個(gè)節(jié)點(diǎn)，即 f+1 個(gè)節(jié)點(diǎn)，確節(jié)點(diǎn)的數(shù)量就會(huì)比故障節(jié)點(diǎn)數(shù)量多，那么集群就能達(dá)成共識(shí)。所以，所有類型的節(jié)點(diǎn)數(shù)量加起來就是 f+1 個(gè)正確節(jié)點(diǎn)，f個(gè)故障節(jié)點(diǎn)和f個(gè)問題節(jié)點(diǎn)，即 3f+1=n。
結(jié)合上述兩種情況，因此 pbft 算法支持的最大容錯(cuò)節(jié)點(diǎn)數(shù)量是（n-1）/3
pbft 算法的基本流程主要有以下四步：
客戶端發(fā)送請求給主節(jié)點(diǎn)
主節(jié)點(diǎn)廣播請求給其它節(jié)點(diǎn)，節(jié)點(diǎn)執(zhí)行 pbft 算法的三階段共識(shí)流程。
節(jié)點(diǎn)處理完三階段流程后，返回消息給客戶端。
客戶端收到來自 f+1 個(gè)節(jié)點(diǎn)的相同消息后，代表共識(shí)已經(jīng)正確完成。
為什么收到 f+1 個(gè)節(jié)點(diǎn)的相同消息后就代表共識(shí)已經(jīng)正確完成？從上一小節(jié)的推導(dǎo)里可知，無論是最好的情況還是最壞的情況，如果客戶端收到 f+1 個(gè)節(jié)點(diǎn)的相同消息，那么就代表有足夠多的正確節(jié)點(diǎn)已全部達(dá)成共識(shí)并處理完畢了。
3.算法核心三階段流程
算法的核心三個(gè)階段分別是 pre-prepare 階段（預(yù)準(zhǔn)備階段），prepare 階段（準(zhǔn)備階段）， commit 階段（提交階段）
流程的對(duì)比上，對(duì)于 leader 選舉這塊， raft 算法本質(zhì)是誰快誰當(dāng)選，而 pbft 算法是按編號(hào)依次輪流做主節(jié)點(diǎn)。對(duì)于共識(shí)過程和重選 leader 機(jī)制這塊，為了更形象的描述這兩個(gè)算法，接下來會(huì)把 raft 和 pbft 的共識(shí)過程比喻成一個(gè)團(tuán)隊(duì)是如何執(zhí)行命令的過程，從這個(gè)角度去理解 raft 算法和 pbft 的區(qū)別。
一個(gè)團(tuán)隊(duì)一定會(huì)有一個(gè)老大和普通成員。對(duì)于 raft 算法，共識(shí)過程就是：只要老大還沒掛，老大說什么，我們（團(tuán)隊(duì)普通成員）就做什么，堅(jiān)決執(zhí)行。那什么時(shí)候重新老大呢？只有當(dāng)老大掛了才重選老大，不然生是老大的人，死是老大的鬼。
對(duì)于 pbft 算法，共識(shí)過程就是：老大向我發(fā)送命令時(shí)，當(dāng)我認(rèn)為老大的命令是有問題時(shí)，我會(huì)拒絕執(zhí)行。就算我認(rèn)為老大的命令是對(duì)的，我還會(huì)問下團(tuán)隊(duì)的其它成員老大的命令是否是對(duì)的，只有大多數(shù)人 （2f+1） 都認(rèn)為老大的命令是對(duì)的時(shí)候，我才會(huì)去執(zhí)行命令。那什么時(shí)候重選老大呢？老大掛了當(dāng)然要重選，如果大多數(shù)人都認(rèn)為老大不稱職或者有問題時(shí)，我們也會(huì)重新選擇老大。
四、結(jié)語
raft 算法和 pbft 算法是私鏈和聯(lián)盟鏈中經(jīng)典的共識(shí)算法，本文主要介紹了 raft 和 pbft 算法的流程和區(qū)別。 raft 和 pbft 算法有兩點(diǎn)根本區(qū)別：
raft 算法從節(jié)點(diǎn)不會(huì)拒絕主節(jié)點(diǎn)的請求，而 pbft 算法從節(jié)點(diǎn)在某些情況下會(huì)拒絕主節(jié)點(diǎn)的請求 ;
raft 算法只能容錯(cuò)故障節(jié)點(diǎn)，并且最大容錯(cuò)節(jié)點(diǎn)數(shù)為 （n-1）/2 ，而 pbft 算法能容錯(cuò)故障節(jié)點(diǎn)和作惡節(jié)點(diǎn)，最大容錯(cuò)節(jié)點(diǎn)數(shù)為 （n-1）/3 。
pbft算法是通過投票來達(dá)成共識(shí)，可以很好的解決包括分叉等問題的同時(shí)提升效率。但僅僅比較適合于聯(lián)盟鏈私有鏈，因?yàn)閮蓛晒?jié)點(diǎn)之間通信量是O(n^2)（通過優(yōu)化可以減少通信量），一般來說不能應(yīng)用于超過100個(gè)節(jié)點(diǎn)。
pbft有解的前提是 信道必須是可靠的 ，存在的問題是 可擴(kuò)展性（scalability）差
部分來自：
區(qū)塊鏈在設(shè)計(jì)上就是為了BFT
本文名稱：pbft的java代碼,pbft算法詳解
本文來源：http://www.dlmjj.cn/article/hdpjig.html
