本發(fā)明涉及一種基于區(qū)塊鏈賬戶模型的無序交易控制方法,改進(jìn)了現(xiàn)有基于賬戶模型的區(qū)塊鏈中關(guān)于有序交易的規(guī)則，添加了無序交易相關(guān)的控制規(guī)則，以及防止雙重花費(fèi)相關(guān)的策略。

背景技術(shù)：

區(qū)塊鏈?zhǔn)且环N新的分布式技術(shù)，由一個個順序排列而成的交易組成塊，再由一個個順序排列而成的塊組成鏈，每個塊包含一個自增的高度作為編號，還有一個時間戳用于記載打包時間。用戶使用私鑰簽名發(fā)出的交易，廣播后由記賬節(jié)點(diǎn)打包進(jìn)入?yún)^(qū)塊鏈存儲，記賬節(jié)點(diǎn)再廣播給其他只讀節(jié)點(diǎn)進(jìn)行驗(yàn)證。交易的合法性由用戶的簽名決定，用戶需要對不同的交易生成不同的簽名。

區(qū)塊鏈一般分為未花費(fèi)交易輸出(utxo)模型和賬戶(account)模型，為了防止雙重花費(fèi)，utxo模型的方法是：一個未花費(fèi)的貨幣或者狀態(tài)只允許被用作交易輸入一次。賬戶模型的方法是：為每個交易指定一個自增的數(shù)字編號，數(shù)字編號決定了交易的按序執(zhí)行，中間不能跳序，相同的編號不能使用多于一次。

賬戶模型的自增數(shù)字編號方法目前還只能適應(yīng)低頻的交易場景，如果用戶需要短時間內(nèi)發(fā)送多筆交易，需要在客戶端自己維護(hù)多筆交易的自增交易編號，然后發(fā)送到節(jié)點(diǎn)后等待打包入塊。但由于區(qū)塊鏈網(wǎng)絡(luò)的分布式特性，交易廣播的過程中會出現(xiàn)亂序或丟失的情況，導(dǎo)致記賬節(jié)點(diǎn)如果發(fā)現(xiàn)交易不是按序增加的，會被認(rèn)為是非法交易丟棄或暫緩打包。最嚴(yán)重的情況是中間某一個編號的交易丟失，則會導(dǎo)致后續(xù)所有交易均被丟棄或暫緩打包，客戶端又不能很快得到反饋結(jié)果，只能等待隨機(jī)的時間后重新發(fā)起丟失的交易。

技術(shù)實(shí)現(xiàn)要素：

本發(fā)明的目的在于針對現(xiàn)有技術(shù)的不足,提供一種基于區(qū)塊鏈賬戶模型的無序交易控制方法。

本發(fā)明的目的是通過以下技術(shù)方案實(shí)現(xiàn)的:一種基于區(qū)塊鏈賬戶模型的無序交易控制方法,其特征在于,包括以下步驟:

步驟1：用戶按照區(qū)塊鏈協(xié)議的賬戶規(guī)則，生成地址user。

步驟2：用戶在本地客戶端生成自身已經(jīng)上鏈存儲的交易id列表user_onchain_ids，置為空，生成發(fā)送中的交易id列表user_pending_ids，也置為空。

步驟3:記賬節(jié)點(diǎn)和同步節(jié)點(diǎn)在本地生成已上鏈存儲交易id列表node_onchain_ids,結(jié)構(gòu)為map(user＝>id列表)。記賬節(jié)點(diǎn)和同步節(jié)點(diǎn)每同步一個塊，就遍歷區(qū)塊中所有的交易，將交易對應(yīng)的user和交易id，添加入node_onchain_ids中。記賬節(jié)點(diǎn)生成入塊中交易id列表node_adding_ids,結(jié)構(gòu)為map(user＝>id列表)。

步驟4:用戶按照區(qū)塊鏈協(xié)議的交易id格式，為每一筆交易生成id，需確保該交易id不在user_onchain_ids和user_pending_ids中，并廣播交易，同時將該交易id添加入user_pending_ids中。

步驟5:記賬節(jié)點(diǎn)在出塊時，接收用戶廣播的交易，判斷交易id是否存在于node_onchain_ids或node_adding_ids中，如果都不存在，則為合法交易，并添加該交易到node_adding_ids中，繼續(xù)后續(xù)操作，否則為雙重花費(fèi)交易，做非法交易處理。

步驟6:記賬節(jié)點(diǎn)在完成區(qū)塊打包并廣播區(qū)塊后，將node_adding_ids中所有的交易id分別加入到node_onchain_ids中，并清空當(dāng)前塊的node_adding_ids。

步驟7:用戶實(shí)時同步區(qū)塊鏈，接收到新塊后，執(zhí)行其中的交易，如果存在自己的交易，則將該交易id從user_pending_ids中去除，并加入到user_onchain_ids中。

進(jìn)一步地,所述區(qū)塊鏈協(xié)議的交易id格式區(qū)塊鏈協(xié)議制定者設(shè)定，包括長度length和類型type。

進(jìn)一步地,用戶在交易丟失或希望覆蓋user_pending_ids列表中的交易時，重復(fù)使用user_pending_ids列表中的交易id，但仍然不能與user_onchain_ids列表中的id重復(fù)。

進(jìn)一步地,所述步驟7中,若區(qū)塊鏈分叉，需回退區(qū)塊?；赝藚^(qū)塊時,遍歷待回退區(qū)塊中的所有交易，將交易對應(yīng)的user和交易id，從node_onchain_ids中刪除。

本發(fā)明有益效果在于:本發(fā)明采用唯一性的id來防止雙重花費(fèi)和重放攻擊，使交易不再依賴固定順序，可以采用無序的方式直接入的鏈，滿足了客戶端單賬戶高并發(fā)交易的場景需求，避免了以往丟失交易后引起其他交易被暫緩的情況。

附圖說明

圖1為總體架構(gòu)示意圖。

具體實(shí)施方式

本發(fā)明涉及一種基于區(qū)塊鏈賬戶模型的無序交易控制方法,該方法基于賬戶模型，用戶采用具有唯一性的id(例如uuid)取代自增數(shù)字編號作為交易的唯一標(biāo)識，節(jié)點(diǎn)通過判斷新交易id是否在該用戶歷史的交易id列表中已存在來判斷是否存在雙重花費(fèi)的行為，交易id之間沒有順序依賴關(guān)系，記賬節(jié)點(diǎn)可以以任意順序?qū)⒔灰状虬雺K。另外交易之間業(yè)務(wù)層面的先后依賴關(guān)系由客戶端在發(fā)起交易時保證，不影響記賬節(jié)點(diǎn)的無序打包。具體步驟如下:

步驟1：區(qū)塊鏈協(xié)議制定者首先規(guī)定交易id格式，包括長度length和類型type。本方案并不具體規(guī)定長度和類型，可以根據(jù)不同的需求選擇不同的長度和類型，比如長度可選擇8字節(jié)、16字節(jié)、32字節(jié)，類型可選擇純數(shù)字、16進(jìn)制、任意字符等。

步驟2：用戶按照區(qū)塊鏈協(xié)議的賬戶規(guī)則，生成地址user。

步驟3：用戶在本地客戶端生成自身已經(jīng)上鏈存儲的交易id列表user_onchain_ids，置為空，生成發(fā)送中的交易id列表user_pending_ids，也置為空。

步驟4:記賬節(jié)點(diǎn)和同步節(jié)點(diǎn)在本地生成已上鏈存儲交易id列表node_onchain_ids,結(jié)構(gòu)為map(user＝>id列表)。記賬節(jié)點(diǎn)和同步節(jié)點(diǎn)每同步一個塊，就遍歷區(qū)塊中所有的交易，將交易對應(yīng)的user和交易id，添加入node_onchain_ids中。記賬節(jié)點(diǎn)生成入塊中交易id列表node_adding_ids,結(jié)構(gòu)為map(user＝>id列表)。

步驟5：用戶按照區(qū)塊鏈協(xié)議的交易id格式，為每一筆交易生成id，需確保該交易id不在user_onchain_ids和user_pending_ids中，并廣播交易，同時將該交易id添加入user_pending_ids中。

步驟6：記賬節(jié)點(diǎn)在出塊時，接收用戶廣播的交易，判斷交易id是否存在于node_onchain_ids或node_adding_ids中，如果都不存在，則為合法交易，并添加該交易到node_adding_ids中，繼續(xù)后續(xù)操作，否則為雙重花費(fèi)交易，做非法交易處理。

步驟7：記賬節(jié)點(diǎn)在完成區(qū)塊打包并廣播區(qū)塊后，將node_adding_ids中所有的交易id分別加入到node_onchain_ids中，并清空當(dāng)前塊的node_adding_ids。

步驟8：用戶實(shí)時同步區(qū)塊鏈，接收到新塊后，執(zhí)行其中的交易，如果存在自己的交易，則將該交易id從user_pending_ids中去除，并加入到user_onchain_ids中。當(dāng)區(qū)塊鏈分叉，需回退區(qū)塊?；赝藚^(qū)塊時,遍歷待回退區(qū)塊中的所有交易，將交易對應(yīng)的user和交易id，從node_onchain_ids中刪除。

用戶在交易丟失或希望覆蓋user_pending_ids列表中的交易時，重復(fù)使用user_pending_ids列表中的交易id，但仍然不能與user_onchain_ids列表中的id重復(fù)。