pos機(jī)的報文格式,路由器和核心交換機(jī)之間有什么關(guān)系

新聞資訊2 | 2023-06-11 12:36 | 投稿人：pos機(jī)之家

網(wǎng)上有很多關(guān)于pos機(jī)的報文格式,路由器和核心交換機(jī)之間有什么關(guān)系的知識，也有很多人為大家解答關(guān)于pos機(jī)的報文格式的問題，今天pos機(jī)之家(www.dsth100338.com)為大家整理了關(guān)于這方面的知識，讓我們一起來看下吧!

本文目錄一覽：

1、pos機(jī)的報文格式

pos機(jī)的報文格式

免責(zé)聲明：本文旨在傳遞更多市場信息，不構(gòu)成任何投資建議。文章僅代表作者觀點(diǎn)，不代表火星財經(jīng)官方立場。

小編：記得關(guān)注哦

來源：知道創(chuàng)宇

作者：0x7F@知道創(chuàng)宇404實(shí)驗室時間：2020年01月09日

原文：https://paper.seebug.org/1110/

0x00 前言

隨著技術(shù)浪潮的涌動，國家政策的推動，區(qū)塊鏈又慢慢的進(jìn)入了我們的視野中。在 2020 年初這個時刻，不妨我們再回頭看看區(qū)塊鏈的發(fā)展，聊聊區(qū)塊鏈中的幾個技術(shù)點(diǎn)，為新的一年打打基礎(chǔ)。

2017 年是數(shù)據(jù)貨幣大爆發(fā)的一年，其標(biāo)志性事件是 2017 年 12 月比特幣價格達(dá)到歷史最高，并將區(qū)塊鏈引入公眾的視野中；也因此，2018 年被稱之為區(qū)塊鏈元年，各類數(shù)字貨幣和與區(qū)塊鏈沾邊的技術(shù)如雨后春筍般出現(xiàn)在互聯(lián)網(wǎng)上；后來隨著區(qū)塊鏈的監(jiān)管力度增大，2019 年則是區(qū)塊鏈冷寂的一年，最后經(jīng)過考驗的都是具有價值的區(qū)塊鏈項目。

那么本文，我們就拋開數(shù)字貨幣不談，僅從區(qū)塊鏈的方面來聊聊；文中使用比特幣 v0.19.x(commit: 0655c7a94cc9bf54d43eceed805e83f1b59e2409)的源碼來幫助理解。

0x01 區(qū)塊鏈的簡介

區(qū)塊鏈隨著比特幣的誕生而誕生，首次出現(xiàn)于比特幣的白皮書中(https://bitcoin.org/bitcoin.pdf)，用于存儲比特幣的交易記錄；在比特幣中，根據(jù)時序?qū)⒍鄺l交易記錄整理集中存儲以形成區(qū)塊，塊與塊之間采用哈希值的方式連接形成鏈?zhǔn)浇Y(jié)構(gòu)，我們將這種結(jié)構(gòu)稱為區(qū)塊鏈。

比特幣中，多個節(jié)點(diǎn)通過p2p網(wǎng)絡(luò)共同維護(hù)一條區(qū)塊鏈，使得這種鏈?zhǔn)浇Y(jié)構(gòu)具有去中心化、不可篡改、可追溯等特性。后續(xù)的以太坊、超級賬本等項目也都基于這種鏈?zhǔn)浇Y(jié)構(gòu)。

這里我們拋開數(shù)字貨幣，把區(qū)塊鏈作為主角來看，我們可以更加容易的來理解區(qū)塊鏈：區(qū)塊鏈就是一個基于P2P的分布式數(shù)據(jù)庫，以多個節(jié)點(diǎn)共同維護(hù)一份數(shù)據(jù)；那么從這個角度來看，比特幣的區(qū)塊鏈存儲的「交易記錄」也是數(shù)據(jù)，只是數(shù)據(jù)比較特別而已。

0x02 區(qū)塊鏈vs分布式數(shù)據(jù)庫

我們可以認(rèn)為區(qū)塊鏈就是基于P2P的分布式數(shù)據(jù)庫，是因為區(qū)塊鏈和分布式數(shù)據(jù)庫有著相似的目標(biāo)：使用多個節(jié)點(diǎn)來共同維護(hù)一份數(shù)據(jù)。

但我們僅僅以「存儲」這一個操作來理解，并且忽略掉了它們本身的應(yīng)用場景、默認(rèn)所有節(jié)點(diǎn)都是可信、可靠、無延時通信的、等等。實(shí)際環(huán)境下，我們需要去考慮如上諸多的因素，因此區(qū)塊鏈不能等同于分布式存儲數(shù)據(jù)庫。

我們使用表格來對比區(qū)塊鏈和分布式數(shù)據(jù)庫：

區(qū)塊鏈分布式數(shù)據(jù)庫

架構(gòu)分布式分布式

價值主張數(shù)字化信任系統(tǒng)高性能存儲和訪問

網(wǎng)絡(luò)通信peer-to-peerclient-server

管理方式集中管理分散管理

數(shù)據(jù)結(jié)構(gòu)鏈?zhǔn)剿饕?、等?/p>

節(jié)點(diǎn)關(guān)系懷疑 & 制約信任 & 協(xié)作

一致性共識算法主從復(fù)制

數(shù)據(jù)持久數(shù)據(jù)不可變可修改 & 非持久

性能低高

在了解區(qū)塊鏈和分布式存儲數(shù)據(jù)庫的異同點(diǎn)后，我們可以知道無論是分布式存儲數(shù)據(jù)庫還是區(qū)塊鏈，都需要去解決分布式中的問題；并且區(qū)塊鏈還需要去解決它所特有的問題。所以我們以分布式存儲數(shù)據(jù)庫為基礎(chǔ)，來幫助我們理解區(qū)塊鏈中所涉及到的技術(shù)點(diǎn)。

0x03 分布式中的挑戰(zhàn)

1.FLP不可能原理對于分布式系統(tǒng)中的不確定性，F(xiàn)ischer、Lynch和Patterson三位科學(xué)家在1985年發(fā)表論文并提出FLP不可能原理：在網(wǎng)絡(luò)可靠，但允許節(jié)點(diǎn)失效（即便只有一個）的最小化異步模型系統(tǒng)中，不存在一個可以解決一致性問題的確定性算法。

所以理論上不存在一個可以完美解決一致性問題的方法，但在工程應(yīng)用中，我們可以選擇犧牲部分特性，以換取一個可行的方案。

2.CAP原理那么我們應(yīng)該如何選擇代價，來換取這個可行的方案呢？在 2000 年由 Eric Brewer 教授在 ACM 組織的一個研討會上提出了 CAP 原理：分布式系統(tǒng)不可能同時確保以下三個特性：一致性(Consistency)、可用性(Availability)和分區(qū)容忍性(Partition)，設(shè)計中往往需要弱化對某個特性的保證。

根據(jù) CAP 原理，我們就可以根據(jù)不同的需求，對三種特性進(jìn)行抉擇。如訪問分布式的網(wǎng)站的靜態(tài)內(nèi)容，可以接受數(shù)據(jù)延遲更新，這是弱化了一致性；而在區(qū)塊鏈中，即便犧牲性能也要保證只有一份公認(rèn)的數(shù)據(jù)，這是弱化了可用性。

3.拜占庭容錯在分布式數(shù)據(jù)庫中，節(jié)點(diǎn)之間是相互信任的、是忠誠的，它們可能會離線、宕機(jī)，但它們絕不會發(fā)送錯誤的消息；所以我們可以信任任意一個節(jié)點(diǎn)，分布式數(shù)據(jù)庫常用「主從復(fù)制」實(shí)現(xiàn)一致性，也就是：從中選擇一個節(jié)點(diǎn)作為主節(jié)點(diǎn)，其他節(jié)點(diǎn)從該節(jié)點(diǎn)復(fù)制數(shù)據(jù)，如果該節(jié)點(diǎn)出現(xiàn)故障，則重新選擇新的主節(jié)點(diǎn)。

而在區(qū)塊鏈中節(jié)點(diǎn)是自由的加入和退出的，可能會出現(xiàn)惡意節(jié)點(diǎn)：該節(jié)點(diǎn)可能會離線、宕機(jī)，并且會發(fā)送錯誤的消息來擾亂數(shù)據(jù)的一致性；這就是常說的拜占庭將軍問題。

這是 20 世紀(jì) 80 年代提出的一個假想問題，描述的是：「一組拜占庭將軍分別各率領(lǐng)一支軍隊共同圍困一座城市，由于各支軍隊處于城市不同方向，所以他們只能通過信使進(jìn)行聯(lián)系；軍隊的行動策略限定為進(jìn)攻或撤離兩種，部分軍隊進(jìn)攻部分軍隊撤離都可能會造成災(zāi)難性后果，因此各位將軍必須通過投票來達(dá)成一致策略；每位將軍都將自己投票信息通過信使通知其他將軍，所以每位將軍根據(jù)自己的投票和其他所有將軍送來的信息就可以知道投票結(jié)果而決定行動策略」。

在上圖中，由叛軍發(fā)送錯誤的投票信息引起不一致的問題，稱之為「拜占庭錯誤」，能夠處理拜占庭錯誤的方法稱為「拜占庭容錯」(Byzantine Fault Tolerance)。那么區(qū)塊鏈中是如何解決的呢？

0x04 共識算法

PBFT算法PBFT(Practical Byzantine Fault Tolerance) 算法的提出主要就是為了解決拜占庭錯誤。其算法的核心為三大階段：pre-prepare階段(預(yù)準(zhǔn)備階段)，prepare階段(準(zhǔn)備階段)，commit階段(提交階段)，我們以下圖來理解該算法。

其中 C 表示發(fā)起請求客戶端，0123 表示服務(wù)節(jié)點(diǎn)，3 節(jié)點(diǎn)出現(xiàn)了故障，用 f 表示故障節(jié)點(diǎn)的個數(shù)。

C 向 0 節(jié)點(diǎn)發(fā)起請求0 節(jié)點(diǎn)廣播該請求到其他服務(wù)節(jié)點(diǎn)節(jié)點(diǎn)在收到 pre-prepare 消息后，可以選擇接受和拒絕該消息，接收該消息則廣播 prepare 消息到其他服務(wù)節(jié)點(diǎn)當(dāng)一個節(jié)點(diǎn)在 prepare 階段并收到 2f 個 prepare 消息后，進(jìn)入到 commit 階段，廣播 commit 消息到其他服務(wù)節(jié)點(diǎn)當(dāng)一個節(jié)點(diǎn)在 commit 階段并收到 2f+1 個 commit 消息后(包括它自己)，發(fā)送消息給 C 客戶端當(dāng) C 客戶端收到 f+1 個 reply 消息后，表示共識已經(jīng)完成

PBFT 中節(jié)點(diǎn)數(shù)必須滿足 N >= 3f+1 這個關(guān)系，只要節(jié)點(diǎn)中的故障節(jié)點(diǎn)不超過 1/3 時，就可以完成共識確定一致性。由于 PBFT 算法的特性以及性能問題，所以其常用于小規(guī)模聯(lián)盟鏈中。

PoW算法比特幣中使用 PoW(Proof of Work) 算法，即為工作量證明算法。其算法的核心為利用復(fù)雜的數(shù)學(xué)計算競爭一次添加區(qū)塊的機(jī)會，結(jié)合「不利原則」，并僅認(rèn)可最長的鏈為合法的鏈這一規(guī)則，完成節(jié)點(diǎn)共識。

在比特幣中，PoW 的工作方式如下：

用戶發(fā)起交易，由節(jié)點(diǎn)廣播交易至所有節(jié)點(diǎn)節(jié)點(diǎn)收到交易打包并將其放入塊中某一節(jié)點(diǎn)計算出了哈希結(jié)果，獲得添加區(qū)塊的機(jī)會，將 2 中的塊添加到區(qū)塊鏈尾部，并廣播區(qū)塊至所有節(jié)點(diǎn)節(jié)點(diǎn)收到新的區(qū)塊信息后，驗證區(qū)塊合法性，合法后將其添加到區(qū)塊鏈尾部，并進(jìn)入下一輪的競爭

通過 PoW 算法，比特幣可以允許全網(wǎng)有 50% 的節(jié)點(diǎn)錯誤的情況下，依然能夠完成共識。

PoW 算法的實(shí)現(xiàn)

PoW 算法位于區(qū)塊生成的模塊中(挖礦)。我們先看看比特幣的啟動流程，比特幣程序入口位于 bitcoind.cpp下，通過這樣的調(diào)用鏈啟動比特幣中的各項服務(wù)：

main->AppInit->AppInitMain

其中包括 RPC 服務(wù)，在比特幣中我們需要使用 bitcoin-cli通過 RPC 服務(wù)啟動挖坑，最終到rpc/mining.cpp/generateBlocks這個區(qū)塊生成主邏輯：

其中 pow.cpp/CheckProofOfWork函數(shù)進(jìn)行了 PoW 算法的驗證，主要是判斷在當(dāng)前nonce值的情況下，區(qū)塊哈希值是否小于難度值：

其他但由于 PoW 算法性能低下、而且會造成大量的算力浪費(fèi)，大家紛紛提出新的共識算法，如 PoS(股權(quán)權(quán)益證明)、DPoS(委托權(quán)益人證明機(jī)制)，等等；但以比特幣占據(jù)區(qū)塊鏈項目的半壁江山來看，PoW 仍是目前用得最多的共識算法。

0x05 存儲結(jié)構(gòu)

在了解共識算法后，我們可以保證數(shù)據(jù)的一致性了，那么這些數(shù)據(jù)是如何在區(qū)塊鏈中存儲的呢？

Merkle樹在比特幣中，使用 Merkle 樹組織和存儲一個塊內(nèi)的交易信息，它是一種基于哈希的二叉樹(或多叉樹)，其結(jié)構(gòu)如下：

葉子節(jié)點(diǎn)存儲數(shù)據(jù)非葉子節(jié)點(diǎn)存儲其子節(jié)點(diǎn)的內(nèi)容的哈希值

使用 Merkle 樹的優(yōu)勢所在：

快速比較大量數(shù)據(jù)，比較根節(jié)點(diǎn)的哈希值即可知道兩組數(shù)據(jù)是否相同

快速定位修改，任何子節(jié)點(diǎn)的變動都會傳遞至根節(jié)點(diǎn)，從根節(jié)點(diǎn)向下檢索即可找到修改的節(jié)點(diǎn)。

Merkle 樹實(shí)現(xiàn) 在比特幣中，Merkle 樹的生成是挖礦步驟中的子步驟，跟入上文中的區(qū)塊生成流程中的 miner.cpp/IncrementExtraNonce函數(shù)中，在該函數(shù)中調(diào)用consensus/merkle.cpp/BlockMerkleRoot函數(shù)以構(gòu)建 Merkle 樹：

哈希鏈在一個區(qū)塊中，除了打包成Merkle樹的交易信息，還包括塊高度、隨機(jī)數(shù)、時間等等信息，其中父塊哈希值將各個區(qū)塊聯(lián)系起來，形成鏈?zhǔn)浇Y(jié)構(gòu)，如下：

哈希鏈實(shí)現(xiàn)

在比特幣中，區(qū)塊由區(qū)塊頭和 Merkle 交易樹組成，區(qū)塊頭數(shù)據(jù)結(jié)構(gòu)定義在 primitives/block.h，如下：

0x06 網(wǎng)絡(luò)通信

那么在區(qū)塊鏈中，各個節(jié)點(diǎn)之間是如何傳遞數(shù)據(jù)的呢？相對于分布式數(shù)據(jù)庫 server-client 網(wǎng)絡(luò)結(jié)構(gòu)，采用主從復(fù)制的方式同步數(shù)據(jù)，區(qū)塊鏈則是 peer-to-peer 的網(wǎng)絡(luò)結(jié)構(gòu)，節(jié)點(diǎn)在獲取數(shù)據(jù)的同時，還需要提供數(shù)據(jù)給其他節(jié)點(diǎn)。

我們直接來看看比特幣中 p2p 協(xié)議的實(shí)現(xiàn)方式。

p2p 協(xié)議的實(shí)現(xiàn)方式

在比特幣中，默認(rèn)在 8333端口建立 tcp 監(jiān)聽，啟動 p2p 服務(wù)。在bitcoind啟動流程的init.cpp/AppInitMain中，對網(wǎng)絡(luò)進(jìn)行了初始化啟動：

[init.cpp/AppInitMain()]1.node.connman->Start 啟動節(jié)點(diǎn)入口，網(wǎng)絡(luò)初始化和建立[net.cpp/Start()]2.InitBinds 建立網(wǎng)絡(luò)監(jiān)聽3.AddOneShot 添加種子節(jié)點(diǎn)4.&TraceThread...... 啟動五個網(wǎng)絡(luò)處理線程

p2p網(wǎng)絡(luò)處理流程就由這五個線程進(jìn)行負(fù)責(zé)：

其中負(fù)責(zé) p2p 協(xié)議處理的線程就是 ThreadMessageHandler線程，我們主要來看看這一部分的流程；在該線程中嘗試對每個節(jié)點(diǎn)接收數(shù)據(jù)，接收到數(shù)據(jù)就如下的調(diào)用流程：

[net_processing.cpp]ProcessMessages->ProcessMessage

在 ProcessMessages對協(xié)議格式進(jìn)行判斷，比特幣中 p2p 協(xié)議格式如下：

隨后進(jìn)入到 ProcessMessage進(jìn)行實(shí)際的消息處理流程，在該函數(shù)中主要邏輯是多個if-else語句根據(jù)commmand進(jìn)入不同的消息的處理流程，支持的消息有：

每個命令下都有不同報文格式和處理邏輯，比特幣通過這樣的方式，打通了節(jié)點(diǎn)間的通道。

0x07 總結(jié)

通過本文我們在脫離數(shù)字貨幣的情況下，從分布式數(shù)據(jù)庫的角度，聊了些區(qū)塊鏈中的幾個技術(shù)點(diǎn)，了解到區(qū)塊鏈與傳統(tǒng)分布式的異同之處，也了解到區(qū)塊鏈中的基本概念和原理。

區(qū)塊鏈的去中心化、不可篡改性的特性，給我們提供了無限的遐想，但目前還沒有公開的、完善的區(qū)塊鏈項目出現(xiàn)，我們希望這一天能早點(diǎn)到來。

References:

1. 《區(qū)塊鏈技術(shù)指南》

2. 《白話區(qū)塊鏈》