如何用ABAP代碼實現(xiàn)一個最簡單的區(qū)塊鏈原型

今天就跟大家聊聊有關(guān)如何用ABAP代碼實現(xiàn)一個最簡單的區(qū)塊鏈原型，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

ABAP代碼實現(xiàn)一個最簡單的區(qū)塊鏈原型。

我個人覺得，同區(qū)塊鏈本身的實現(xiàn)技術(shù)相比，更難的事情是如何找到一個合適的業(yè)務(wù)場景，把區(qū)塊鏈集成到SAP產(chǎn)品中去，讓它發(fā)揮出作用。

版本1：區(qū)塊和鏈這兩個數(shù)據(jù)結(jié)構(gòu)的實現(xiàn)

區(qū)塊鏈，顧名思義，由區(qū)塊組成的一條鏈。

下圖和我們在大學(xué)計算機專業(yè)課《數(shù)據(jù)結(jié)構(gòu)》里學(xué)到的單鏈表很像。在這個版本里，每個區(qū)塊包含了最基本的字段：塊索引，塊的創(chuàng)建時間戳，當(dāng)前塊的哈希值(hash)和前一塊的哈希值。每個區(qū)塊的pHash字段存儲了前一塊的哈希值，這樣就構(gòu)成了一個鏈表。鏈表的第一個節(jié)點，就是下圖最左邊紅色抬頭的區(qū)塊為創(chuàng)世塊，其索引為0，pHash字段為空。

區(qū)塊的ABAP實現(xiàn)：ZCL_BLOCK。上圖所示的字段都建模在這個類里，出于簡單起見，大部分字段設(shè)置為public。

每個區(qū)塊的哈希值是由該區(qū)塊所有其他字段的值作為輸入，通過SHA1算法計算出來，存儲到字段mv_hash里。

鏈的實現(xiàn)：ZCL_BLOCKCHAIN

• ADD_BLOCK: 接受一個區(qū)塊的實例作為輸入?yún)?shù)，將該實例的pHash指向當(dāng)前鏈表尾部的區(qū)塊，這樣該實例成為鏈表新的尾部區(qū)塊。

• CONSTRUCTOR: 構(gòu)造函數(shù)，執(zhí)行鏈的初始化操作，創(chuàng)建創(chuàng)世塊區(qū)塊。

• GET_BLOCK_BY_INDEX: 根據(jù)索引訪問指定的區(qū)塊。

• GET_SIZE: 返回鏈里包含的區(qū)塊數(shù)量。

• IS_VALID: 檢查該區(qū)塊鏈?zhǔn)欠裼行?。具體檢查邏輯在后續(xù)介紹。

第一版的所有代碼在我的github上。

執(zhí)行測試程序ZBLOCKCHAIN_V1，輸入您想創(chuàng)建的區(qū)塊個數(shù)，會看到如下輸出：（我選擇的個數(shù)是5）

因為SAP GUI沒有鏈表的UI控件，因此我用樹控件模擬。

下圖第21行，我把區(qū)塊鏈里索引為1的區(qū)塊內(nèi)容篡改為"Change by Jerry", 然后再執(zhí)行第23行的is_valid方法進(jìn)行檢查:

因為第21行set_data方法修改了第一個區(qū)塊的內(nèi)容后，會觸發(fā)其哈希值的重新計算。這樣第一個區(qū)塊的哈希發(fā)生了變化（假設(shè)從YYY變到了CCC），而第二個區(qū)塊的pHash仍然指向第一個區(qū)塊變化之前的舊哈希值YYY，因此這個區(qū)塊鏈被判定為無效。

上圖的輸出來自校驗方法is_valid: 遍歷鏈里每個區(qū)塊，比較區(qū)塊里存儲前一區(qū)塊哈希值的字段pHash和位于該區(qū)塊前一個位置的區(qū)塊的哈希值是否一致。

版本2：增加挖礦成本，增加對工作量證明(Proof of Work，縮寫為POW)的支持

第二版代碼的地址在我的github上。

這一版的鏈實現(xiàn)類ZCL_BLOCKCHAIN_V2的構(gòu)造函數(shù)增加了一個輸入?yún)?shù)：iv_difficulty。這個參數(shù)有什么用？

仔細(xì)觀察第一版測試程序的樹狀輸出，可以看到每個區(qū)塊的哈希值沒有任何規(guī)律。而第二版的這個輸入?yún)?shù)就是為了提高哈希值的計算成本，即只有當(dāng)計算出來的哈希值滿足一定規(guī)則時，該哈希值才能被區(qū)塊鏈所接受。參數(shù)iv_difficulty定義了能夠被接受的哈希值的前導(dǎo)零個數(shù)。

例如我指定前導(dǎo)零個數(shù)為3：

執(zhí)行結(jié)果：能看到所有的哈希值的前三位都為零。

這里有兩個問題：

• 下圖最后一列Nonce的含義是什么？

• iv_difficulty這個參數(shù)是如何參與哈希值計算的呢？

首先在區(qū)塊的實現(xiàn)類ZCL_BLOCK里增加了一個新的成員字段mv_nonce:

在將一個區(qū)塊實例添加到鏈里的方法add_block里，增加了一個方法mine。

這個方法里是一個循環(huán)，在循環(huán)體內(nèi)計算出一個哈希值，然后檢查其是否包含指定位數(shù)的前導(dǎo)零。如果沒有，將mv_nonce加1，然后繼續(xù)循環(huán)。mv_nonce也會作為輸入的一部分參與哈希計算。也就是說，最終區(qū)塊字段mv_nonce的值代表了代表了在得到符合前導(dǎo)零位數(shù)要求的合法哈希值之前，一共經(jīng)過了多少次計算。而通過在循環(huán)里不斷嘗試最終得到一個合法的哈希值的這一過程，就是區(qū)塊鏈圈內(nèi)俗稱的“挖礦”。

在我的測試系統(tǒng)里，創(chuàng)建10個區(qū)塊，前導(dǎo)零個數(shù)為4，總共花費了10秒鐘。

從這個花費的時間能體會出，POW其實是一種機制，通過引入需要一定工作量的哈希計算來避免區(qū)塊鏈被垃圾填充或者區(qū)塊內(nèi)容被篡改。

版本3：使用區(qū)塊鏈記錄交易明細(xì)，增加挖礦獎勵

這一版的源代碼：

https://github.com/i042416/KnowlegeRepository/tree/master/ABAP/blockchain/v3

使用ZCL_TRANSACTION來代表一筆交易，包含三個字段：mv_from_address（支付方），mv_to_address（收款方）和mv_amount（交易金額）。

在這一版本里，首先被增強的是ZCL_BLOCK3: 去掉了前兩個版本使用的mv_index和mv_data字段，增加了一個字段mt_transaction, 存儲的是交易的集合。

在計算哈希值時，交易類的每一個字段也要參與計算：

類ZCL_BLOCKCHAIN_V3增加了一個新的成員變量mt_pending_trans。每次調(diào)用方法create_transaction，并不會創(chuàng)建一個新的區(qū)塊用于記錄該條交易，只是簡單地把該條交易添加到待處理任務(wù)隊列mt_pending_trans里。

字段mv_mine_reward存儲了挖礦的獎勵，硬編碼成100。

這個待處理任務(wù)隊列僅當(dāng)方法mine_pending_trans被調(diào)用時才會得到處理。

第6行的區(qū)塊實例的mine方法調(diào)用之后，計算出一個符合前導(dǎo)零規(guī)范的哈希值。接著待處理任務(wù)隊列被清空，然后一個新的交易記錄在第13行被創(chuàng)建出來，作為挖礦的獎勵，獎勵方的賬號信息由輸入?yún)?shù)iv_award_address定義。

既然現(xiàn)在交易信息存儲在了每個區(qū)塊里，那么簡單遍歷這些區(qū)塊，就能得出某個賬號最后的余額是多少。采用的邏輯是，遍歷每個區(qū)塊記錄的每筆交易，如果某帳號出現(xiàn)在交易記錄的支付方，則余額減去當(dāng)前這筆交易的交易金額(第5行), 反之賬號如果出現(xiàn)在發(fā)送方，則余額加上交易金額(第9行)。

測試程序如下。因為Tom轉(zhuǎn)了100元給Jerry，Jerry又轉(zhuǎn)了10元給Tom，然后第15行挖礦設(shè)置的獎勵賬號是Jerry，故最后Jerry的余額是100-10+100 = 190元。

看完上述內(nèi)容，你們對如何用ABAP代碼實現(xiàn)一個最簡單的區(qū)塊鏈原型有進(jìn)一步的了解嗎？如果還想了解更多知識或者相關(guān)內(nèi)容，請關(guān)注億速云行業(yè)資訊頻道，感謝大家的支持。