bft區塊鏈視頻

A. cspr幣是什麼由誰發行的

Casper 網路是一個 PoS 公鏈，針對開發者快速入門、提升智能合約性能和企業集成進行了優化，支撐該網路的的共識機制是 Highway 協議，後者基於 Casper 原始的 CBC 規范 PoS 權益證明區塊鏈架構發展而來。 作為一個 BFT 概念下安全活躍的共識模型，Highway 協議做了兩項改進：使網路確定性(Finality)的閾值更高;實現典型 BFT 模型無法企及的靈活性(Flexibility)。
拓展資料：
1.CSPR 是 Casper 網路的原生通證。作為一條權益證明區塊鏈，Casper 網路利用 CSPR 來獎勵參與 PoS 共識機制的驗證者，從而達到保護和維護網路的目的。 Casper 公鏈代幣持有用戶還可利用 CSPR 代幣來為鏈上操作支付網路費用。
2.CasperLabs 有三個特點：CasperLab Highway，PoS 機制的智能合約平台，安全可行的 CBC Casper 實施方案，即以太坊 3.0 架構。
3.大多數 PoS 區塊鏈均採用拜占庭容錯（BFT）共識協議設計而成。BFT 協議是指區塊鏈網路在一組分布式自治節點之間高效重復生成共識的能力。BFT共識模型假設一個網路中的不誠實節點不超過 1/3。在存在 2/3 誠實節點的假設下，BFT 區塊鏈可以長期安全運行，並保持其交易歷史的不變性和可驗證性。
4.Casper 的 Highway 協議不僅是在 BFT 概念下安全活躍的共識模型，還做到了兩項重要改進：第一，它讓網路確定性（Finality）的閾值更高；第二，它能實現典型 BFT 模型無法企及的靈活性（Flexibility）。先進的 BFT 共識機制設計也讓 Casper 成為PoS 公鏈中較有競爭性的智能合約平台。
5.Casper本身就具備天王級項目的潛質，雖然從時間節點上來看Casper主網上線時間以及生態的起步都晚於以太坊，不過從本質上來看Casper與以太坊是同根同源的。並且從生態的角度來講，Casper與以太坊本身而言是相輔相成的。
6.我們都知道以太坊作為早期的公鏈，說他承載了行業的半壁江山並不為過，無論是生態的起步、繁榮度以及行業開發者、投資者的認可度都是能夠印證的。但是以太坊在保證安全、去中心化的特性，犧牲了效率也就是自身的可擴展性。以太坊，因為自身的效率問題，很顯然無法承承載當下的商業生態，也就難以成為企業級公鏈為傳統世界服務。

B. 區塊鏈 --- 共識演算法

PoW演算法是一種防止分布式服務資源被濫用、拒絕服務攻擊的機制。它要求節點進行適量消耗時間和資源的復雜運算，並且其運算結果能被其他節點快速驗算，以耗用時間、能源做擔保，以確保服務與資源被真正的需求所使用。

PoW演算法中最基本的技術原理是使用哈希演算法。假設求哈希值Hash(r)，若原始數據為r（raw），則運算結果為R（Result）。

R = Hash(r)

哈希函數Hash()的特性是，對於任意輸入值r，得出結果R，並且無法從R反推回r。當輸入的原始數據r變動1比特時，其結果R值完全改變。在比特幣的PoW演算法中，引入演算法難度d和隨機值n，得到以下公式：

Rd = Hash(r+n)

該公式要求在填入隨機值n的情況下，計算結果Rd的前d位元組必須為0。由於哈希函數結果的未知性，每個礦工都要做大量運算之後，才能得出正確結果，而算出結果廣播給全網之後，其他節點只需要進行一次哈希運算即可校驗。PoW演算法就是採用這種方式讓計算消耗資源，而校驗僅需一次。

 

PoS演算法要求節點驗證者必須質押一定的資金才有挖礦打包資格，並且區域鏈系統在選定打包節點時使用隨機的方式，當節點質押的資金越多時，其被選定打包區塊的概率越大。

POS模式下，每個幣每天產生1幣齡，比如你持有100個幣，總共持有了30天，那麼，此時你的幣齡就為3000。這個時候，如果你驗證了一個POS區塊，你的幣齡就會被清空為0，同時從區塊中獲得相對應的數字貨幣利息。

節點通過PoS演算法出塊的過程如下：普通的節點要成為出塊節點，首先要進行資產的質押，當輪到自己出塊時，打包區塊，然後向全網廣播，其他驗證節點將會校驗區塊的合法性。

 

DPoS演算法和PoS演算法相似，也採用股份和權益質押。

但不同的是，DPoS演算法採用委託質押的方式，類似於用全民選舉代表的方式選出N個超級節點記賬出塊。

選民把自己的選票投給某個節點，如果某個節點當選記賬節點，那麼該記賬節點往往在獲取出塊獎勵後，可以採用任意方式來回報自己的選民。

這N個記賬節點將輪流出塊，並且節點之間相互監督，如果其作惡，那麼會被扣除質押金。

通過信任少量的誠信節點，可以去除區塊簽名過程中不必要的步驟，提高了交易的速度。
 

拜占庭問題：

拜占庭是古代東羅馬帝國的首都，為了防禦在每塊封地都駐扎一支由單個將軍帶領的軍隊，將軍之間只能靠信差傳遞消息。在戰爭時，所有將軍必須達成共識，決定是否共同開戰。

但是，在軍隊內可能有叛徒，這些人將影響將軍們達成共識。拜占庭將軍問題是指在已知有將軍是叛徒的情況下，剩餘的將軍如何達成一致決策的問題。

BFT：

BFT即拜占庭容錯，拜占庭容錯技術是一類分布式計算領域的容錯技術。拜占庭假設是對現實世界的模型化，由於硬體錯誤、網路擁塞或中斷以及遭到惡意攻擊等原因，計算機和網路可能出現不可預料的行為。拜占庭容錯技術被設計用來處理這些異常行為，並滿足所要解決的問題的規范要求。

拜占庭容錯系統 ：

發生故障的節點被稱為 拜占庭節點 ，而正常的節點即為 非拜占庭節點 。

假設分布式系統擁有n台節點，並假設整個系統拜占庭節點不超過m台（n ≥ 3m + 1），拜占庭容錯系統需要滿足如下兩個條件：

另外，拜占庭容錯系統需要達成如下兩個指標：

PBFT即實用拜占庭容錯演算法，解決了原始拜占庭容錯演算法效率不高的問題，演算法的時間復雜度是O(n^2)，使得在實際系統應用中可以解決拜占庭容錯問題
 

PBFT是一種狀態機副本復制演算法，所有的副本在一個視圖（view）輪換的過程中操作，主節點通過視圖編號以及節點數集合來確定，即：主節點 p = v mod |R|。v：視圖編號，|R|節點個數，p：主節點編號。

PBFT演算法的共識過程如下：客戶端（Client）發起消息請求（request），並廣播轉發至每一個副本節點（Replica），由其中一個主節點（Leader）發起提案消息pre-prepare，並廣播。其他節點獲取原始消息，在校驗完成後發送prepare消息。每個節點收到2f+1個prepare消息，即認為已經准備完畢，並發送commit消息。當節點收到2f+1個commit消息，客戶端收到f+1個相同的reply消息時，說明客戶端發起的請求已經達成全網共識。

具體流程如下 ：

客戶端c向主節點p發送<REQUEST, o, t, c>請求。o: 請求的具體操作，t: 請求時客戶端追加的時間戳，c：客戶端標識。REQUEST: 包含消息內容m，以及消息摘要d(m)。客戶端對請求進行簽名。

主節點收到客戶端的請求，需要進行以下交驗：

a. 客戶端請求消息簽名是否正確。

非法請求丟棄。正確請求，分配一個編號n，編號n主要用於對客戶端的請求進行排序。然後廣播一條<<PRE-PREPARE, v, n, d>, m>消息給其他副本節點。v：視圖編號，d客戶端消息摘要，m消息內容。<PRE-PREPARE, v, n, d>進行主節點簽名。n是要在某一個范圍區間內的[h, H]，具體原因參見 垃圾回收 章節。

副本節點i收到主節點的PRE-PREPARE消息，需要進行以下交驗：

a. 主節點PRE-PREPARE消息簽名是否正確。

b. 當前副本節點是否已經收到了一條在同一v下並且編號也是n，但是簽名不同的PRE-PREPARE信息。

c. d與m的摘要是否一致。

d. n是否在區間[h, H]內。

非法請求丟棄。正確請求，副本節點i向其他節點包括主節點發送一條<PREPARE, v, n, d, i>消息, v, n, d, m與上述PRE-PREPARE消息內容相同，i是當前副本節點編號。<PREPARE, v, n, d, i>進行副本節點i的簽名。記錄PRE-PREPARE和PREPARE消息到log中，用於View Change過程中恢復未完成的請求操作。

主節點和副本節點收到PREPARE消息，需要進行以下交驗：

a. 副本節點PREPARE消息簽名是否正確。

b. 當前副本節點是否已經收到了同一視圖v下的n。

c. n是否在區間[h, H]內。

d. d是否和當前已收到PRE-PPREPARE中的d相同

非法請求丟棄。如果副本節點i收到了2f+1個驗證通過的PREPARE消息，則向其他節點包括主節點發送一條<COMMIT, v, n, d, i>消息，v, n, d, i與上述PREPARE消息內容相同。<COMMIT, v, n, d, i>進行副本節點i的簽名。記錄COMMIT消息到日誌中，用於View Change過程中恢復未完成的請求操作。記錄其他副本節點發送的PREPARE消息到log中。

主節點和副本節點收到COMMIT消息，需要進行以下交驗：

a. 副本節點COMMIT消息簽名是否正確。

b. 當前副本節點是否已經收到了同一視圖v下的n。

c. d與m的摘要是否一致。

d. n是否在區間[h, H]內。

非法請求丟棄。如果副本節點i收到了2f+1個驗證通過的COMMIT消息，說明當前網路中的大部分節點已經達成共識，運行客戶端的請求操作o，並返回<REPLY, v, t, c, i, r>給客戶端，r：是請求操作結果，客戶端如果收到f+1個相同的REPLY消息，說明客戶端發起的請求已經達成全網共識，否則客戶端需要判斷是否重新發送請求給主節點。記錄其他副本節點發送的COMMIT消息到log中。
 

如果主節點作惡，它可能會給不同的請求編上相同的序號，或者不去分配序號，或者讓相鄰的序號不連續。備份節點應當有職責來主動檢查這些序號的合法性。

如果主節點掉線或者作惡不廣播客戶端的請求，客戶端設置超時機制，超時的話，向所有副本節點廣播請求消息。副本節點檢測出主節點作惡或者下線，發起View Change協議。

View Change協議 ：

副本節點向其他節點廣播<VIEW-CHANGE, v+1, n, C , P , i>消息。n是最新的stable checkpoint的編號， C 是 2f+1驗證過的CheckPoint消息集合， P 是當前副本節點未完成的請求的PRE-PREPARE和PREPARE消息集合。

當主節點p = v + 1 mod |R|收到 2f 個有效的VIEW-CHANGE消息後，向其他節點廣播<NEW-VIEW, v+1, V , O >消息。 V 是有效的VIEW-CHANGE消息集合。 O 是主節點重新發起的未經完成的PRE-PREPARE消息集合。PRE-PREPARE消息集合的選取規則：

副本節點收到主節點的NEW-VIEW消息，驗證有效性，有效的話，進入v+1狀態，並且開始 O 中的PRE-PREPARE消息處理流程。
 

在上述演算法流程中，為了確保在View Change的過程中，能夠恢復先前的請求，每一個副本節點都記錄一些消息到本地的log中，當執行請求後副本節點需要把之前該請求的記錄消息清除掉。

最簡單的做法是在Reply消息後，再執行一次當前狀態的共識同步，這樣做的成本比較高，因此可以在執行完多條請求K（例如：100條）後執行一次狀態同步。這個狀態同步消息就是CheckPoint消息。

副本節點i發送<CheckPoint, n, d, i>給其他節點，n是當前節點所保留的最後一個視圖請求編號，d是對當前狀態的一個摘要，該CheckPoint消息記錄到log中。如果副本節點i收到了2f+1個驗證過的CheckPoint消息，則清除先前日誌中的消息，並以n作為當前一個stable checkpoint。

這是理想情況，實際上當副本節點i向其他節點發出CheckPoint消息後，其他節點還沒有完成K條請求，所以不會立即對i的請求作出響應，它還會按照自己的節奏，向前行進，但此時發出的CheckPoint並未形成stable。

為了防止i的處理請求過快，設置一個上文提到的 高低水位區間[h, H] 來解決這個問題。低水位h等於上一個stable checkpoint的編號，高水位H = h + L，其中L是我們指定的數值，等於checkpoint周期處理請求數K的整數倍，可以設置為L = 2K。當副本節點i處理請求超過高水位H時，此時就會停止腳步，等待stable checkpoint發生變化，再繼續前進。
 

在區塊鏈場景中，一般適合於對強一致性有要求的私有鏈和聯盟鏈場景。例如，在IBM主導的區塊鏈超級賬本項目中，PBFT是一個可選的共識協議。在Hyperledger的Fabric項目中，共識模塊被設計成可插拔的模塊，支持像PBFT、Raft等共識演算法。
 

 

Raft基於領導者驅動的共識模型，其中將選舉一位傑出的領導者(Leader)，而該Leader將完全負責管理集群，Leader負責管理Raft集群的所有節點之間的復制日誌。
 

下圖中，將在啟動過程中選擇集群的Leader（S1），並為來自客戶端的所有命令/請求提供服務。 Raft集群中的所有節點都維護一個分布式日誌（復制日誌）以存儲和提交由客戶端發出的命令（日誌條目）。 Leader接受來自客戶端的日誌條目，並在Raft集群中的所有關注者（S2，S3，S4，S5）之間復制它們。

在Raft集群中，需要滿足最少數量的節點才能提供預期的級別共識保證， 這也稱為法定人數。 在Raft集群中執行操作所需的最少投票數為 (N / 2 +1) ，其中N是組中成員總數，即 投票至少超過一半 ，這也就是為什麼集群節點通常為奇數的原因。 因此，在上面的示例中，我們至少需要3個節點才能具有共識保證。

如果法定仲裁節點由於任何原因不可用，也就是投票沒有超過半數，則此次協商沒有達成一致，並且無法提交新日誌。

 

數據存儲：Tidb/TiKV

日誌：阿里巴巴的 DLedger

服務發現：Consul& etcd

集群調度：HashiCorp Nomad
 

只能容納故障節點(CFT)，不容納作惡節點

順序投票，只能串列apply，因此高並發場景下性能差
 

Raft通過解決圍繞Leader選舉的三個主要子問題，管理分布式日誌和演算法的安全性功能來解決分布式共識問題。

當我們啟動一個新的Raft集群或某個領導者不可用時，將通過集群中所有成員節點之間協商來選舉一個新的領導者。 因此，在給定的實例中，Raft集群的節點可以處於以下任何狀態: 追隨者(Follower)，候選人(Candidate)或領導者(Leader)。

系統剛開始啟動的時候，所有節點都是follower，在一段時間內如果它們沒有收到Leader的心跳信號，follower就會轉化為Candidate；

如果某個Candidate節點收到大多數節點的票，則這個Candidate就可以轉化為Leader，其餘的Candidate節點都會回到Follower狀態；

一旦一個Leader發現系統中存在一個Leader節點比自己擁有更高的任期(Term)，它就會轉換為Follower。

Raft使用基於心跳的RPC機制來檢測何時開始新的選舉。 在正常期間， Leader 會定期向所有可用的 Follower 發送心跳消息（實際中可能把日誌和心跳一起發過去）。 因此，其他節點以 Follower 狀態啟動，只要它從當前 Leader 那裡收到周期性的心跳，就一直保持在 Follower 狀態。

當 Follower 達到其超時時間時，它將通過以下方式啟動選舉程序：

根據 Candidate 從集群中其他節點收到的響應，可以得出選舉的三個結果。

共識演算法的實現一般是基於復制狀態機（Replicated state machines），何為 復制狀態機 ：

簡單來說： 相同的初識狀態 + 相同的輸入 = 相同的結束狀態 。不同節點要以相同且確定性的函數來處理輸入，而不要引入一下不確定的值，比如本地時間等。使用replicated log是一個很不錯的注意，log具有持久化、保序的特點，是大多數分布式系統的基石。

有了Leader之後，客戶端所有並發的請求可以在Leader這邊形成一個有序的日誌（狀態）序列，以此來表示這些請求的先後處理順序。Leader然後將自己的日誌序列發送Follower，保持整個系統的全局一致性。注意並不是強一致性，而是 最終一致性 。

日誌由有序編號（log index）的日誌條目組成。每個日誌條目包含它被創建時的任期號（term），和日誌中包含的數據組成，日誌包含的數據可以為任何類型，從簡單類型到區塊鏈的區塊。每個日誌條目可以用[ term, index, data]序列對表示，其中term表示任期， index表示索引號，data表示日誌數據。

Leader 嘗試在集群中的大多數節點上執行復制命令。 如果復製成功，則將命令提交給集群，並將響應發送回客戶端。類似兩階段提交(2PC)，不過與2PC的區別在於，leader只需要超過一半節點同意（處於工作狀態）即可。

leader 、 follower 都可能crash，那麼 follower 維護的日誌與 leader 相比可能出現以下情況

當出現了leader與follower不一致的情況，leader強制follower復制自己的log， Leader會從後往前試 ，每次AppendEntries失敗後嘗試前一個日誌條目（遞減nextIndex值）， 直到成功找到每個Follower的日誌一致位置點（基於上述的兩條保證），然後向後逐條覆蓋Followers在該位置之後的條目 。所以丟失的或者多出來的條目可能會持續多個任期。
 

要求候選人的日誌至少與其他節點一樣最新。如果不是，則跟隨者節點將不投票給候選者。

意味著每個提交的條目都必須存在於這些伺服器中的至少一個中。如果候選人的日誌至少與該多數日誌中的其他日誌一樣最新，則它將保存所有已提交的條目，避免了日誌回滾事件的發生。

即任一任期內最多一個leader被選出。這一點非常重要，在一個復制集中任何時刻只能有一個leader。系統中同時有多餘一個leader，被稱之為腦裂（brain split），這是非常嚴重的問題，會導致數據的覆蓋丟失。在raft中，兩點保證了這個屬性：

因此， 某一任期內一定只有一個leader 。
 

當集群中節點的狀態發生變化（集群配置發生變化）時，系統容易受到系統故障。 因此，為防止這種情況，Raft使用了一種稱為兩階段的方法來更改集群成員身份。 因此，在這種方法中，集群在實現新的成員身份配置之前首先更改為中間狀態（稱為聯合共識）。 聯合共識使系統即使在配置之間進行轉換時也可用於響應客戶端請求，它的主要目的是提升分布式系統的可用性。

C. st和bft什麼意思

st是股票，bft是指以太坊幣。
以太幣（ETH）是以太坊（Ethereum）的一種數字代幣，被視為「比特幣2、0版」，採用與比特幣不同的區塊鏈技術「以太坊」（Ethereum），一個開源的有智能合約成果的民眾區塊鏈平台，由全球成千上萬的計算機構成的共鳴網路。
開發者們需要支付以太幣（ETH）來支撐應用的運行。
和其他數字貨幣一樣，以太幣可以在交易平台上進行買賣。

D. 如何成功發布一個區塊鏈短視頻

區塊鏈視頻一旦上鏈，就無法更改了，更改後無效的，抱品網上的視頻一旦操作上鏈就無法刪除了

E. 誰知道在區塊鏈上認證視頻和圖片的版權原理是什麼

基本上原理都一樣， 用抱品網舉例子， 抱品網視頻區塊鏈認證其實就是DApp， 先把視頻每分鍾關鍵幀的圖片截圖， 然後轉碼成一串唯一的數字 ， 然後上傳記錄到以太坊區塊鏈之中。

F. 什麼是區塊鏈短視頻

區塊鏈「高效低能」「去中心化」「..區塊鏈短視頻就是把原創短視頻放在區塊鏈上做認證，證明是原創的。

G. 共識演算法4 (BFT)

拜占庭將軍問題（Byzantine Generals Problem），由Leslie Lamport、Robert Shostak和Marshall Pease，在其同名論文中提出（1982年）。拜占庭將軍問題現在主要指分布式對等網路節點間的通信容錯問題。在分布式網路中，不同的計節點通過交換信息達成共識。但有時候，系統中的成員節點可能出錯而發送錯誤的信息，用於傳遞信息的通訊網路也可能導致信息損壞，也可能存在惡意節點或被黑客攻破的節點故意發送錯誤的信息，從而導致系統無法達成共識或者達成錯誤的共識。（參考： BFT Wikipedia ）

拜占庭將軍問題提出後，有很多的演算法被提出用於解決這個問題。這類演算法統稱拜占庭容錯演算法（BFT: Byzantine Fault Tolerance）。BFT從上世紀80年代開始被研究，目前已經是一個被研究得比較透徹的理論，具體實現都已經有現成的演算法。

BFT演算法中最典型的是PBFT（Practical BFT）。PBFT是由Miguel Castro和Barbara Liskov於1999年提出。PBFT演算法解決了之前拜占庭容錯演算法效率不高的問題，將演算法復雜度由指數級降低到多項式級，使得拜占庭容錯演算法在實際系統應用中變得可行。PBFT在保證安全性和可用性的前提下，提供了 (n-1)/3 的容錯性。（細節請參考： PBFT ）

PBFT之後，很多進一步提升性能或魯棒性的BFT演算法先後被提出，例如Zyzzyva、ABsTRACTs、Aardvark、RBFT等等。近幾年，由於區塊鏈的熱度，無數針對區塊鏈應用場景優化過的BFT演算法也不斷涌現出來。雖然目前PBFT已經不能說是最好的，或最適合區塊鏈的BFT演算法。但是PBFT已經足夠好了，而且在實際應用中已經非常成熟。

在BFT共識機制中，網路中節點的數量和身份必須是提前確定好的。BFT共識機制無法做到PoW共識機制中實現的任何人都可以隨時加入挖礦。另外，BFT演算法無法應用到大量的節點，業內普遍認為100個節點是BFT演算法的上限。所以BFT演算法無法直接用於公有鏈，BFT演算法適合的場景是私有鏈和聯盟鏈。業內大名鼎鼎的聯盟鏈Hyperledger fabric v0.6採用的是PBFT，v1.0又推出PBFT的改進版本SBFT。這里再順便提一句，在可信環境下共識演算法一般使用傳統的分布式一致演算法PAXOS或者RAFT。

公有鏈使用BFT的一個例外是NEO，NEO使用了DBFT（delegated BFT）共識機制。DBFT共識機制下投票選出7個共識節點。這些代理節點是通過靜態選出的，並完全由項目方部署。這也是NEO被外界質疑過於中心化的原因。（參考： 早期公有鏈明星項目-NEO ）

BFT演算法和公有鏈合適的結合點在於基於BFT的PoS共識演算法（BFT based PoS）。基於BFT的PoS共識演算法要點有：一，網路節點通過鎖定虛擬資產申請成為區塊鏈系統的驗證者（或礦工）。系統驗證者的數量是動態變化的。二，系統從當前驗證者中隨機選擇一個人作為區塊提案人。三，系統驗證者對區塊提案進行投票表決，投票可能要進行多輪才能達成共識。每個人的投票比重與鎖定的虛擬資產成比例。

基於BFT的PoS的典型例子是tendermint（Cosmos採用了tendermint作為共識核心）。

H. 玩區塊鏈游戲可以賺錢嗎

每當一個新的事物出現的時候，總會伴隨著各種虛假的誤導的信息出現。區塊鏈游戲的出現也不例外。

從技術角度來將，區塊鏈游戲是可以賺錢的。但是區塊鏈游戲誕生的初衷並不是讓游戲玩家賺錢。
什麼樣的游戲才能是區塊鏈游戲呢？社會上很多打著區塊鏈名義的游戲，很多根本就沒有使用區塊鏈技術。只是穿了一個馬甲來忽悠小白玩家。很多區塊鏈游戲說自己的游戲可以挖礦，那麼可以挖礦的游戲就真的是區塊鏈游戲嗎？
言歸正傳，是不是真的區塊鏈游戲，和挖不挖礦沒關系。區塊鏈是需要挖礦的，挖礦的機制有POW（比特幣和以太坊等等採用），POS（EOS等採用）和BFT（小蟻鏈等採用）等等。區塊鏈游戲不一定挖礦。所以，游戲玩家以後看到號稱可以挖礦的游戲，不要就想當然的認為是區塊鏈游戲了。
真正的區塊鏈游戲至少包括兩個因素。第一是區塊鏈錢包，第二個是游戲道具瀏覽器。
一、區塊鏈錢包
區塊鏈給了游戲玩家真正擁有道具的權力，體現在哪裡呢？就體現在區塊鏈錢包上。玩家在游戲中贏取裝備後，裝備會通過智能合約自動發送到玩家的區塊鏈錢包里（發送需要多長時間要看當時區塊鏈網路的暢通情況）。
一般情況下，區塊鏈錢包是一個獨立的APP，安裝在手機上或者電腦上。沒有在游戲界面里。所以，一個辨別是不是真假區塊鏈的簡單方法是，看它的錢包是不是一個獨立的APP或軟體。如果是嵌入在游戲內部的，那麼它就不是區塊鏈游戲。
二、游戲道具瀏覽器
區塊鏈是一個公開的分布式賬本，每個人都查看到鏈上的信息。游戲道具瀏覽器就是專門用來查鏈上的游戲道具信息的。
所以，如果一款區塊鏈游戲，玩家不能在游戲道具瀏覽器上查詢到游戲道具相關信息，那麼它也是假的區塊鏈游戲。
我是區塊鏈游戲愛好者，歡迎關注我，相互交流。嘀嘀~

I. 區塊鏈游戲究竟是什麼，能賺錢嗎

每當一個新的事物出現的時候，總會伴隨著各種虛假的誤導的信息出現。區塊鏈游戲的出現也不例外。
從技術角度來將，區塊鏈游戲是可以賺錢的。但是區塊鏈游戲誕生的初衷並不是讓游戲玩家賺錢。
什麼樣的游戲才能是區塊鏈游戲呢？社會上很多打著區塊鏈名義的游戲，很多根本就沒有使用區塊鏈技術。只是穿了一個馬甲來忽悠小白玩家。很多區塊鏈游戲說自己的游戲可以挖礦，那麼可以挖礦的游戲就真的是區塊鏈游戲嗎？
言歸正傳，是不是真的區塊鏈游戲，和挖不挖礦沒關系。區塊鏈是需要挖礦的，挖礦的機制有POW（比特幣和以太坊等等採用），POS（EOS等採用）和BFT（小蟻鏈等採用）等等。區塊鏈游戲不一定挖礦。所以，游戲玩家以後看到號稱可以挖礦的游戲，不要就想當然的認為是區塊鏈游戲了。
真正的區塊鏈游戲至少包括兩個因素。第一是區塊鏈錢包，第二個是游戲道具瀏覽器。
一、區塊鏈錢包
區塊鏈給了游戲玩家真正擁有道具的權力，體現在哪裡呢？就體現在區塊鏈錢包上。玩家在游戲中贏取裝備後，裝備會通過智能合約自動發送到玩家的區塊鏈錢包里（發送需要多長時間要看當時區塊鏈網路的暢通情況）。
一般情況下，區塊鏈錢包是一個獨立的APP，安裝在手機上或者電腦上。沒有在游戲界面里。所以，一個辨別是不是真假區塊鏈的簡單方法是，看它的錢包是不是一個獨立的APP或軟體。如果是嵌入在游戲內部的，那麼它就不是區塊鏈游戲。
二、游戲道具瀏覽器
區塊鏈是一個公開的分布式賬本，每個人都查看到鏈上的信息。游戲道具瀏覽器就是專門用來查鏈上的游戲道具信息的。
所以，如果一款區塊鏈游戲，玩家不能在游戲道具瀏覽器上查詢到游戲道具相關信息，那麼它也是假的區塊鏈游戲。
我是區塊鏈游戲愛好者，歡迎關注我，相互交流。嘀嘀~