這裏將詳細地對示例性實施例進行說明,其示例表示在圖式中。下面的描述涉及圖式時,除非另有表示,不同圖式中的相同數字表示相同或相似的要素。以下示例性實施例中所描述的實施方式並不代表與本說明書一個或多個實施例相一致的所有實施方式。相反,它們僅是與如所附申請專利範圍中所詳述的、本說明書一個或多個實施例的一些方面相一致的裝置和方法的例子。
需要說明的是:在其他實施例中並不一定按照本說明書示出和描述的順序來執行相應方法的步驟。在一些其他實施例中,其方法所包括的步驟可以比本說明書所描述的更多或更少。此外,本說明書中所描述的單個步驟,在其他實施例中可能被分解為多個步驟進行描述;而本說明書中所描述的多個步驟,在其他實施例中也可能被合併為單個步驟進行描述。
區塊鏈一般被劃分為三種類型:公有鏈(Public
Blockchain),私有鏈(Private Blockchain)和聯盟鏈(Consortium Blockchain)。此外,還可以有上述多種類型的結合,比如私有鏈+聯盟鏈、聯盟鏈+公有鏈等。
其中,去中心化程度最高的是公有鏈。公有鏈以比特幣、以太坊為代表,加入公有鏈的參與者(也可稱為區塊鏈中的節點)可以讀取鏈上的資料記錄、參與交易、以及競爭新區塊的記帳權等。而且,各節點可自由加入或者退出網路,並進行相關操作。
私有鏈則相反,該網路的寫入權限由某個組織或者機構控制,資料讀取權限受組織規定。簡單來說,私有鏈可以為一個弱中心化系統,其對節點具有嚴格限制且節點數量較少。這種類型的區塊鏈更適合於特定機構內部使用。
聯盟鏈則是介於公有鏈以及私有鏈之間的區塊鏈,可實現“部分去中心化”。聯盟鏈中各個節點通常有與之相對應的實體機構或者組織;節點透過授權加入網路並組成利益相關聯盟,共同維護區塊鏈運行。
基於區塊鏈的基本特性,區塊鏈通常是由若干個區塊構成。在這些區塊中分別記錄有與該區塊的創建時刻對應的時間戳記,所有的區塊嚴格按照區塊中記錄的時間戳記,構成一條在時間上有序的資料鏈條。
對於物理世界產生的真實資料,可以將其構建成區塊鏈所支援的標準的交易(transaction)格式,然後發布至區塊鏈,由區塊鏈中的節點設備對收到的交易進行共識處理,並在達成共識後,由區塊鏈中作為記帳節點的節點設備,將這筆交易打包進區塊,在區塊鏈中進行持久化存證。
其中,區塊鏈中支援的共識演算法可以包括:
第一類共識演算法,即節點設備需要爭奪每一輪的記帳周期的記帳權的共識演算法;例如,工作量證明(Proof of Work,POW)、股權證明(Proof of Stake,POS)、委任權益證明(Delegated Proof of Stake,DPOS)等共識演算法;
第二類共識演算法,即預先為每一輪記帳周期選舉記帳節點(不需要爭奪記帳權)的共識演算法;例如,實用拜占庭容錯(Practical Byzantine Fault Tolerance,PBFT)等共識演算法。
在採用第一類共識演算法的區塊鏈網路中,爭奪記帳權的節點設備,都可以在接收到交易後執行該筆交易。爭奪記帳權的節點設備中可能有一個節點設備在本輪爭奪記帳權的過程中勝出,成為記帳節點。記帳節點可以將收到的交易與其它交易一起打包以產生最新區塊,並將產生的最新區塊或者該最新區塊的區塊頭發送至其它節點設備進行共識。
在採用第二類共識演算法的區塊鏈網路中,具有記帳權的節點設備在本輪記帳前已經商定好。因此,節點設備在接收到交易後,如果自身不是本輪的記帳節點,則可以將該交易發送至記帳節點。對於本輪的記帳節點,在將該交易與其它交易一起打包以產生最新區塊的過程中或者之前,可以執行該交易。記帳節點在產生最新區塊後,可以將該最新區塊或者該最新區塊的區塊頭發送至其它節點設備進行共識。
如上所述,無論區塊鏈採用以上示出的哪種共識演算法,本輪的記帳節點都可以將接收到的交易打包以產生最新區塊,並將產生的最新區塊或者該最新區塊的區塊頭發送至其它節點設備進行共識驗證。如果其它節點設備接收到最新區塊或者該最新區塊的區塊頭後,經驗證沒有問題,可以將該最新區塊追加到原有的區塊鏈末尾,從而完成區塊鏈的記帳過程。其它節點驗證記帳節點發來的新的區塊或區塊頭的過程中,也可以執行該區塊中的包含的交易。
在區塊鏈領域,有一個重要的概念就是帳戶(Account);以以太坊為例,以太坊通常將帳戶劃分為外部帳戶和合約帳戶兩類;外部帳戶就是由用戶直接控制的帳戶,也稱之為用戶帳戶;而合約帳戶則是由用戶透過外部帳戶創建的,包含合約代碼的帳戶(即智慧合約)。當然,對於一些基於以太坊的架構而衍生出的區塊鏈項目(比如螞蟻區塊鏈),還可以對區塊鏈支援的帳戶類型,進行進一步的擴展,在本說明書中不進行特別限定。
對於區塊鏈中的帳戶而言,通常會透過一個結構體,來維護帳戶的帳戶狀態。當區塊中的交易被執行後,區塊鏈中與該交易相關的帳戶的狀態通常也會發生變化。
以以太坊為例,帳戶的結構體通常包括Balance,
Nonce,Code和Storage等欄位。其中:
Balance欄位,用於維護帳戶目前的帳戶餘額;
Nonce欄位,用於維護該帳戶的交易次數;它是用於保障每筆交易能且只能被處理一次的計數器,有效避免重放攻擊;
Code欄位,用於維護該帳戶的合約代碼;在實際應用中,Code欄位中通常僅維護合約代碼的hash值;因而,Code欄位通常也稱之為Codehash欄位。
Storage欄位,用於維護該帳戶的儲存內容(預設欄位值為空);對於合約帳戶而言,通常會分配一個獨立的儲存空間,用以儲存該合約帳戶的儲存內容;該獨立的儲存空間通常稱之為該合約帳戶的帳戶儲存。合約帳戶的儲存內容通常會構建成MPT(Merkle Patricia Trie)樹的資料結構儲存在上述獨立的儲存空間之中;其中,基於合約帳戶的儲存內容構建成的MPT樹,通常也稱之為Storage樹。而Storage欄位通常僅維護該Storage樹的根節點;因此,Storage欄位通常也稱之為StorageRoot欄位。
其中,對於外部帳戶而言,以上示出的Code欄位和Storage欄位的欄位值均為空值。
對於大多數區塊鏈項目,通常都會使用Merkle樹;或者,基於Merkle樹的資料結構,來儲存和維護資料。以以太坊為例,以太坊使用了MPT樹(一種Merkle樹變種),作為資料組織形式,用來組織和管理帳戶狀態、交易資訊等重要資料。
以太坊針對區塊鏈中需要儲存和維護的資料,設計了三顆MPT樹,分別是MPT狀態樹、MPT交易樹和MPT收據樹。其中,除了以上三顆MPT樹以外,實際上還存在一顆基於合約帳戶的儲存內容構建的Storage樹。
MPT狀態樹,是由區塊鏈中所有帳戶的帳戶狀態(state)資料組織成的MPT樹;MPT交易樹,是由區塊鏈中的交易(transaction)資料組織成的MPT樹;MPT收據樹,是區塊中的交易在執行完畢後產生的與每筆交易對應的交易(receipt)收據組織成的MPT樹。以上示出的MPT狀態樹、MPT交易樹和MPT收據樹的根節點的hash值,最終都會被添加至對應區塊的區塊頭中。
其中,MPT交易樹和MPT收據樹均與區塊相對應,即每一個區塊都有自己的MPT交易樹和MPT收據樹。而MPT狀態樹是一個全域的MPT樹,並不與某一個特定的區塊相對應,而是涵蓋了區塊鏈中所有帳戶的帳戶狀態資料。
對於組織成的MPT交易樹、MPT收據樹和MPT狀態樹,最終都會在採用多級資料儲存結構的Key-Value型資料庫(比如,LevelDB)中進行儲存。
而採用多級資料儲存結構的上述資料庫,通常採用多級資料儲存的結構,可以被劃分為n級資料儲存;例如,各級資料儲存可以依次設為L0,L1,L2,L3,...,L(n-1);對於上述資料庫中的各級資料儲存而言,等級編號越小通常級別越高;例如,L0儲存的是最新的若干區塊的資料,L1儲存的是次新的若干區塊的資料,以此類推。
其中,各級資料儲存對應的儲存媒體的讀寫性能,通常也可以存在性能差異;例如,級別高(即等級編號較小的)的資料儲存對應的儲存媒體的讀寫性能,可以高於級別低的資料儲存對應的儲存媒體的讀寫性能。在實際應用中,級別高的資料儲存,可以使用儲存成本較高,儲存性能較優的儲存媒體;而級別低的資料儲存,可以使用單位成本低,且容量較大的儲存媒體。
在實際應用中,隨著區塊鏈的區塊號的增長(也稱之為區塊高度),在資料庫中儲存的資料,會包含很多歷史資料;而且,區塊號越小的區塊中的資料越久遠,越不重要。因此,為了降低整體的儲存成本,通常可以對不同區塊高度的資料進行“區別對待”;例如,可以將區塊號較小的區塊中的資料,儲存至成本較低的儲存媒體上;而將區塊號較大的區塊中的資料,儲存在成本較高的儲存媒體上。
需要說明的是,區塊鏈每產生一個最新區塊,則在該最新區塊中的交易被執行之後,區塊鏈中這些被執行交易的相關帳戶(可以是外部帳戶也可以是合約帳戶)的帳戶狀態,通常也會隨之發生變化;
例如,當區塊中的一筆“轉帳交易”執行完畢後,與該“轉帳交易”相關的轉出方帳戶和轉入方帳戶的餘額(即這些帳戶的Balance欄位的欄位值),通常也會隨之發生變化。
而節點設備在區塊鏈產生的最新區塊中的交易執行完畢後,由於當前區塊鏈中的帳戶狀態發生了變化,因此節點設備需要根據區塊鏈中所有帳戶當前的帳戶狀態資料,來構建MPT狀態樹,用於維護區塊鏈中所有帳戶的最新狀態。
也即,每當區塊鏈中產生一個最新區塊,並且該最新區塊中的交易執行完畢後,導致區塊鏈中的帳戶狀態發生變化,節點設備都需要基於區塊鏈中所有帳戶最新的帳戶狀態資料,重新構建一顆MPT狀態樹。換句話說,區塊鏈中每一個區塊,都有一個與之對應的MPT狀態樹;該MPT狀態樹,維護了在該區塊中的交易在執行完畢後,區塊鏈中所有帳戶最新的帳戶狀態。
請參考圖1,圖1是本說明書示出的一種將區塊鏈的帳戶狀態資料組織成MPT狀態樹的示意圖。
MPT樹,是一種經過改良的Merkle樹變種,其融合了Merkle樹和Trie字典樹(也稱之為前綴樹)兩種樹形結構的優點。
在MPT樹中通常包括三種資料節點,分別為葉子節點(leaf node),擴展節點(extension node)和分支節點(branch node)。
葉子節點,是表示為[key,value]的一個鍵值對,其中key是種特殊的十六進制編碼字符,value是該葉子節點對應的帳戶位址的狀態資料(即以上示出的結構體)。擴展節點,也是表示為[key,value]的一個鍵值對,其中key也是種特殊的十六進制編碼字符,但是value是其他節點的hash值(hash指標),也就是說可以透過hash指標鏈接到其他節點。
分支節點,包含17個元素,前16個元素對應著key中的16個可能的十六進制字符;一個字符對應一個nibble(半位元組)。如果有一個[key,value]對在這個分支節點終止,則該分支節點可以充當葉子節點的角色,最後一個元素則代表葉子節點的value值;反之,分支節點的最後一個元素,可以為空值。
由於在MPT樹上,從根節點到一個葉子節點的搜索路徑上的字符,組成一個完整的帳戶位址;因此,對於分支節點而言,其既可以是上述搜索路徑的終止節點,也可以是上述搜索路徑的中間節點。
假設需要組織成MTP狀態樹的帳戶狀態資料如下表1所示:
帳戶位址(Key) | 帳戶狀態(Value) |
a | 7 | 1 | 1 | 3 | 5 | 5 | state1 |
a | 7 | 7 | d | 3 | 3 | 7 | state2 |
a | 7 | f | 9 | 3 | 6 | 5 | state3 |
a | 7 | 7 | d | 3 | 9 | 7 | state4 |
表1
在表1中,帳戶位址是由若干16進制的字符構成的字符串。帳戶狀態state,是由上述Balance,Nonce,Code和Storage等欄位構成的結構體。
最終按照表1中的帳戶狀態資料組織成的MPT狀態樹,參考圖1所示,該MPT狀態樹是由4個葉子節點,2個分支節點,和2個擴展節點構成。
在圖1中,prefix欄位為擴展節點和葉子節點共同具有的前綴欄位。該prefix欄位的不同欄位值可以用於表示不同的節點類型。
例如,prefix欄位的取值為0,表示包含偶數個nibbles的擴展節點;如前所述,nibble表示半位元組,由4位二進制組成,一個nibble可以對應一個組成帳戶位址的字符。prefix欄位的取值為1,表示包含奇數個nibble(s)的擴展節點;prefix欄位的取值為2,表示包含偶數個nibbles的葉子節點;prefix欄位的取值為3,表示包含奇數個nibble(s)的葉子節點。
而分支節點,由於其是並列單nibble的前綴節點,因此分支節點不具有上述prefix欄位。
擴展節點中的Shared nibble欄位,對應該擴展節點所包含的鍵值對的key值,表示帳戶位址之間的共同字符前綴;比如,上表中的所有帳戶位址均具有共同的字符前綴a7。Next Node欄位中填充下一個節點的hash值(hash指標)。
分支節點中的16進制字符0~f欄位,對應該分支節點所包含的鍵值對的key值;如果該分支節點為帳戶位址在MPT樹上的搜索路徑上的中間節點,則該分支節點的Value欄位可以為空值。0~f欄位中用於填充下一個節點的hash值。
葉子節點中的Key-end,對應該葉子節點所包含的鍵值對的key值,表示帳戶位址的最後幾個字符。從根節點搜索到葉子節點的搜索路徑上的各個節點的key值,構成了一個完整的帳戶位址。該葉子節點的Value欄位填充帳戶位址對應的帳戶狀態資料;例如,可以對上述Balance,Nonce,Code和Storage等欄位構成的結構體進行編碼後,填充至葉子節點的Value欄位。
進一步的,如圖1所示的MPT狀態樹上的node,最終也是以Key-Value鍵值對的形式儲存在資料庫中;
其中,當MPT狀態樹上的node在資料庫中進行儲存時,MPT狀態樹上的node的鍵值對中的key,為node所包含的資料內容的hash值;MPT狀態樹上的node的鍵值對中的Value,為node所包含的資料內容。
也即,在將MPT狀態樹上的node儲存至資料庫時,可以計算該node所包含的資料內容的hash值(即對node整體進行hash計算),並將計算出的hash值作為key,將該node所包含的資料內容作為value,產生Key-Value鍵值對;然後,將產生的Key-Value鍵值對儲存至資料庫中。
由於MPT狀態樹上的node,是以node所包含的資料內容的hash值為Key,node所包含的資料內容為value進行儲存;因此,在需要查詢MPT狀態樹上的node時,通常可以基於node所包含的資料內容的hash值作為key來進行內容尋址。而採用“內容尋址”,對於一些“內容重複”的node,則通常可以進行“複用”,以節約資料儲存的儲存空間。
如圖2所示,圖2是本說明書示出的一種MPT狀態樹上的node複用的示意圖。需要說明的是,在實際應用中,當區塊鏈產生的一個最新區塊中的交易執行完畢後,可能僅僅會導致部分帳戶的帳戶狀態發生變化;因此,在構建MPT狀態樹時,並不需要基於區塊鏈中所有的帳戶當前的狀態資料,重新構建一顆完整的MPT狀態樹,而只需要在該最新區塊之前的區塊對應的MPT狀態樹的基礎上,對部分帳戶狀態發生變化的帳戶對應的node進行更新即可。而對於MPT狀態樹上與帳戶狀態未發生變化的帳戶對應的node,由於這些node未發生資料更新,因此可以直接複用該最新區塊之前的區塊對應的MPT狀態樹上相應的node即可。
如圖2所示,假設表1中的帳戶狀態資料,為Block N中的交易執行完畢後,區塊鏈上所有帳戶的最新帳戶狀態;基於表1中的帳戶狀態資料組織成的MPT狀態樹,仍如圖1所示。
假設當Block N+1中的交易執行完畢後,導致上述表1中的帳戶位址為“a7f9365”的帳戶狀態,由“state3”更新為“state5”;此時,在Block N+1更新MPT狀態樹時,並不需要在Block N+1中的交易執行完畢後,基於區塊鏈中所有的帳戶當前的狀態資料重新構建一顆MPT狀態樹。
在這種情況下,可以僅將Block N對應的MPT狀態樹上(即圖1示出的MPT狀態樹),“key-end”為“9365”的葉子節點中的Value,由“state3”更新為“state5”,並繼續更新從root節點到該葉子節點的路徑上的所有節點的hash指標;
也即,當MPT狀態樹上的葉子節點發生更新,由於該葉子節點整體的hash值發生更新,那麽從根節點到該葉子節點的路徑上的所有節點的hash指標也會隨之發生更新。
例如,請繼續參考圖2,除了需要更新“key-end”為“9365”的葉子節點中的Value值以外,還需要更新該葉子節點的上一個分支節點(Branch Node)的f欄位中填充的,指向該葉子節點的hash指標;進一步的,還可以繼續向根節點追溯,繼續更新該分支節點的上一個根節點(Root Extension Node)的“Next Node”欄位中填充的,指向該分支節點的hash指標。
而除了以上發生更新的節點以外,其它未發生更新的節點,都可以直接複用Block N的MPT狀態樹上對應的節點即可;
其中,由於Block N對應的MPT樹,最終需要作為歷史資料進行保留;因此,在Block N+1更新MPT狀態樹時,對於這些發生更新的node,並不是在Block N對應的MPT狀態樹上原來的node的基礎上,直接進行修改更新,而是在Block N+1對應的MPT樹上重新創建這些發生更新的node。也即,在與Block N+1對應的MPT狀態樹上,實際上只需要重新創建少量發生更新的node,對於其它未發生更新的node,可以透過直接複用Block N對應的MPT狀態樹上對應的節點。
例如,如圖2所示,對於Block N+1對應的MPT狀態樹上,實際上只需要重新創建一個作為根節點的擴展節點、一個分支節點和一個葉子節點;對於未發生更新的node,可以透過在該MPT狀態樹上這些重新創建的node中,添加指向Block N對應的MPT狀態樹上的相應node的hash指標來完成node的“複用”。而Block N對應的MPT狀態樹上那些更新之前的node,將作為歷史帳戶狀態資料進行保存;比如,圖2示出的“key-end”為“9365”,且Value為“state3”的葉子節點,將作為歷史資料進行保留。
在以上例子中,以Block N+1的MPT狀態樹上的少量node發生內容更新,從而可以“複用”上一個區塊Block N的大多數node為例進行了說明。而在實際應用中,Block N+1的MPT狀態樹上也可能會較上一個區塊Block N新增node。在這種情況下,該新增的node雖然無法直接從上一個區塊Block N的MPT樹中進行“複用”,但有可能從更早之前的區塊的MPT狀態樹上進行“複用”;
例如,Block N+1的MPT狀態樹上新增的node,雖然沒在Block N的MPT狀態樹上出現過,但可能出現在更早的Block的MPT狀態樹上;比如,出現在Block N-1的MPT狀態樹上;因此,Block N+1的MPT狀態樹上新增的node,可以直接複用Block N-1的MPT狀態樹上對應的node即可。
在實際應用中,不論是公有鏈、私有鏈還是聯盟鏈,都可能提供智慧合約(Smart contract)的功能。區塊鏈上的智慧合約是在區塊鏈上可以被交易觸發執行的合約。智慧合約可以透過代碼的形式定義。
以以太坊為例,支援用戶在以太坊網路中創建並調用一些複雜的邏輯。以太坊作為一個可程式化區塊鏈,其核心是以太坊虛擬機(EVM),每個以太坊節點都可以運行EVM。EVM是一個圖靈完備的虛擬機,透過它可以實現各種複雜的邏輯。用戶在以太坊中發布和調用智慧合約就是在EVM上運行的。實際上,EVM直接運行的是虛擬機代碼(虛擬機位元組碼,下簡稱“位元組碼”),所以部署在區塊鏈上的智慧合約可以是位元組碼。
如圖3所示,Bob將一筆包含創建智慧合約資訊的交易(Transaction)發送到以太坊網路後,各節點均可以在EVM中執行這筆交易。其中,圖中1中交易的From欄位用於記錄發起創建智慧合約的帳戶的位址,交易的Data欄位的欄位值保存的合約代碼可以是位元組碼,交易的To欄位的欄位值為一個null(空)的帳戶。當節點間透過共識機制達成一致後,這個智慧合約成功創建,後續用戶可以調用這個智慧合約。
智慧合約創建後,區塊鏈上出現一個與該智慧合約對應的合約帳戶,並擁有一個特定的位址;比如,圖1中各節點中的“0x68e12cf284…”就代表了創建的這個合約帳戶的位址;合約代碼(Code)和帳戶儲存(Storage)將保存在該合約帳戶的帳戶儲存中。智慧合約的行為由合約代碼控制,而智慧合約的帳戶儲存則保存了合約的狀態。換句話說,智慧合約使得區塊鏈上產生包含合約代碼和帳戶儲存的虛擬帳戶。
前述提到,包含創建智慧合約的交易的Data欄位保存的可以是該智慧合約的位元組碼。位元組碼由一連串的位元組組成,每一位元組可以標識一個操作。基於開發效率、可讀性等多方面考慮,開發者可以不直接書寫位元組碼,而是選擇一門高級語言編寫智慧合約代碼。例如,高級語言可以採用諸如Solidity、Serpent、LLL語言等。對於採用高級語言編寫的智慧合約代碼,可以經過編譯器編譯,產生可以部署到區塊鏈上的位元組碼。
以Solidity語言為例,用其編寫的合約代碼與物件導向程式化語言中的類(Class)很相似,在一個合約中可以聲明多種成員,包括狀態變量、函數、函數修改器、事件等。狀態變量是永久儲存在智慧合約的帳戶儲存(Storage)欄位中的值,用於保存合約的狀態。
如圖4所示,仍以以太坊為例,Bob將一筆包含調用智慧合約資訊的交易發送到以太坊網路後,各節點均可以在EVM中執行這筆交易。其中,圖4中交易的From欄位用於記錄發起調用智慧合約的帳戶的位址,To欄位用於記錄被調用的智慧合約的位址,交易的Data欄位用於記錄調用智慧合約的方法和參數。調用智慧合約後,合約帳戶的帳戶狀態可能改變。後續,某個客戶端可以透過接入的區塊鏈節點(例如圖4中的節點1)查看合約帳戶的帳戶狀態。
智慧合約可以以規定的方式在區塊鏈網路中每個節點獨立的執行,所有執行記錄和資料都保存在區塊鏈上,所以當這樣的交易執行完畢後,區塊鏈上就保存了無法篡改、不會丟失的交易憑證。
創建智慧合約和調用智慧合約的示意圖如圖5所示。以太坊中要創建一個智慧合約,需要經過編寫智慧合約、變成位元組碼、部署到區塊鏈等過程。以太坊中調用智慧合約,是發起一筆指向智慧合約位址的交易,各個節點的EVM可以分別執行該交易,將智慧合約代碼分布式的運行在以太坊網路中每個節點的虛擬機中。
以以太坊代表的傳統的區塊鏈項目,為了在區塊鏈上實現“價值轉移”,通常都支援將現實世界的貨幣轉換為能夠在鏈上流通的虛擬代幣。
而在區塊鏈領域,對於一些基於以太坊的架構而衍生出的區塊鏈項目(比如螞蟻區塊鏈),通常不再支援將現實世界的貨幣轉換為能夠在鏈上流通的虛擬代幣的功能;取而代之的是,在這些區塊鏈項目中,可以將現實世界中的一些非貨幣屬性的實體資產,轉化成為能夠在區塊鏈上流通的虛擬資產。
其中,需要說明的是,將現實世界中的非貨幣屬性的實體資產轉化為區塊鏈上的虛擬資產,通常是指將該實體資產與區塊鏈上的虛擬資產進行“錨定”,作為這些虛擬資產的價值支撑,進而在區塊鏈上產生與實體資產的價值匹配,且能夠在區塊鏈上的區塊鏈帳戶之間進行流通的虛擬資產的過程。
在實現時,可以對區塊鏈支援的帳戶類型進行擴展,在區塊鏈支援的帳戶類型的基礎上,再擴展出一種資產帳戶(也稱之為資產對象);比如,可以在以太坊支援的外部帳戶、合約帳戶的基礎上,再擴展出一種資產帳戶;擴展出的該資產帳戶,即為可以將現實世界中的非貨幣屬性的實體資產作為價值支撑,且可以在區塊鏈帳戶之間流通的虛擬資產。
對於接入這類區塊鏈的用戶而言,除了可以在區塊鏈上完成用戶帳戶、智慧合約的創建以外,在區塊鏈上創建一筆與現實世界的非貨幣屬性的實體資產價值匹配的虛擬資產,在區塊鏈上進行流通;
例如,用戶可以將持有的房產、股票、貸款合同、票據、應收帳款等非貨幣屬性的實體資產,轉換為價值匹配的虛擬資產在區塊鏈上流通。
其中,對於上述資產帳戶而言,具體也可以透過一個結構體,來維護帳戶的帳戶狀態。上述資產帳戶的結構體所包含的內容,可以與以太坊相同,當然也可以基於實際的需求進行設計;
在一種實現方式中,以上述資產帳戶的結構體所包含的內容與以太坊相同為例,上述資產帳戶的結構體也可以包括以上描述的Balance,Nonce,Code和Storage等欄位。
需要說明的是,在以太坊中,Balance欄位通常用於維護帳戶目前的帳戶餘額;而對於基於以太坊的架構而衍生出的區塊鏈項目而言,由於其可能並不支援將現實世界的貨幣轉換為能夠在鏈上流通的虛擬代幣,因此在這類區塊鏈中,可以對Balance欄位的含義進行擴展,不再表示帳戶的“餘額”,而是用於維護帳戶持有的“虛擬資產”對應的資產帳戶的位址資訊。其中,在實際應用中,Balance欄位中可以維護多筆“虛擬資產”對應的資產帳戶的位址資訊。
在這種情況下,以上示出的外部帳戶、合約帳戶和資產帳戶,均可以透過在Balance欄位中添加需要持有的“虛擬資產”對應的資產帳戶的位址資訊,來持有這筆虛擬資產。即除了外部帳戶和合約帳戶以外,資產帳戶本身也可以持有虛擬資產。
對於資產帳戶而言,Nonce,Code欄位的欄位值可以為空值(也可以不為空);而Storage欄位的欄位值可以不再是空值;Storage欄位可以用於維護與該資產帳戶對應的“虛擬資產”的資產狀態。其中,在Storage欄位中維護與該資產帳戶對應的“虛擬資產”的資產狀態的具體方式,可以基於需求靈活的進行設計,不再贅述。
在基於以太坊的架構而衍生出的區塊鏈項目中,用戶可以透過以下示出的實現方式,在區塊鏈上創建一筆與現實世界的非貨幣屬性的實體資產價值匹配的虛擬資產:
在一種實現方式中,可以對區塊鏈支援的交易類型進行擴展,擴展出一種用於創建虛擬資產的交易;比如,以太坊支援的交易類型通常包括普通的轉帳交易、創建智慧合約的交易和調用智慧合約的交易,則可以在以上三種類型的交易的基礎上,再擴展出一種用於創建虛擬資產的交易。
在這種情況下,用戶可以透過客戶端向區塊鏈網路中發布一筆用於創建虛擬資產的交易,由區塊鏈中的節點設備在本地的EVM中執行這筆交易,來為該用戶創建虛擬資產。當各節點設備透過共識機制達成一致後,這筆虛擬資產成功創建,區塊鏈上出現一個與這筆虛擬資產對應的資產帳戶,並擁有一個特定的位址。
在另一種實現方式中,也可以在區塊鏈上部署用於創建虛擬資產的智慧合約;其中,部署用於創建虛擬資產的智慧合約的過程不再贅述。
在這種情況下,用戶可以透過客戶端向區塊鏈網路中發布一筆用於調用該智慧合約的交易,由區塊鏈中的節點設備在本地的EVM中執行這筆交易,並在EVM中運行智慧合約相關的合約代碼,來為該用戶創建虛擬資產。當各節點設備透過共識機制達成一致後,這筆虛擬資產成功創建,區塊鏈上出現一個與這筆虛擬資產對應的資產帳戶,並擁有一個特定的位址。
當然,對於一些基於以太坊的架構而衍生出的區塊鏈項目,如果其也支援將現實世界的貨幣轉換為能夠在鏈上流通的虛擬代幣的功能,那麽仍然可以將現實世界中的一些非貨幣屬性的實體資產,轉化成為能夠在區塊鏈上流通的虛擬代幣的形式,在區塊鏈上流通,在本說明書中不再贅述。
在跨鏈場景下,多個區塊鏈可以透過跨鏈中繼實現跨鏈對接。
其中,跨鏈中繼,可以透過橋接介面與多個區塊鏈分別進行對接,並基於實現的資料搬運邏輯,完成該多個區塊鏈之間的跨鏈資料同步。
在實現上述跨鏈中繼時所採用的跨鏈技術,在本說明書中不進行特別限定;例如,在實際應用中,可以透過側鏈技術、公證人技術等跨鏈機制,將多個區塊鏈連接起來。
當多個區塊鏈透過跨鏈中繼實現對接之後,區塊鏈之間就可以去讀取並認證其它區塊鏈上的資料,也可以透過跨鏈中繼去調用其它區塊鏈上部署的智慧合約。
區塊鏈上部署的智慧合約,除了可以使用區塊鏈上存證的資料以外,也可以透過Oracle預言機,來引用鏈外的資料實體上的資料,進而實現智慧合約與真實世界的資料實體之間的資料互動。鏈外的資料實體,可以包括諸如部署在鏈外的中心化的伺服器或者資料中心,等等。
其中,與跨鏈中繼不同的是,Oracle預言機的功能並不是將一個區塊鏈上的資料同步到另一個區塊鏈上,而是將鏈外的資料實體上的資料同步到區塊鏈上;
也即,跨鏈中繼用於連接兩個區塊鏈,而Oracle預言機用於連接區塊鏈與鏈外的資料實體,實現區塊鏈與真實世界的資料互動。
本說明書旨在提供一種對區塊鏈中存證的電子票據進行作廢處理的技術方案。
在具體實現時,上述區塊鏈中的節點設備在監聽到發布至該區塊鏈的與目標電子票據對應的作廢交易時,可以先確定該目標電子票據是否已完成入帳處理。
舉例來說,該區塊鏈中的節點設備可以在本地維護該區塊鏈中存證的每張電子票據的票據狀態。該區塊鏈中的節點設備可以在確定維護的該目標電子票據為已入帳狀態時,確定該目標電子票據已完成入帳處理。
如果該目標電子票據未完成入帳處理,則該區塊鏈中的節點設備可以直接將維護的該目標電子票據更新為已作廢狀態,以實現對該目標電子票據的作廢處理;
如果該目標電子票據已完成入帳處理,則該區塊鏈中的節點設備可以將創建的與該目標電子票據對應的沖紅票據發布至該區塊鏈進行存證,以實現對該目標電子票據的作廢處理。
具體地,該區塊鏈中的節點設備可以在本地創建與該目標電子票據對應的沖紅票據,並將該沖紅票據發布至該區塊鏈進行存證;或者,該區塊鏈中的節點設備可以調用部署在該區塊鏈上的智慧合約中聲明的票據創建邏輯,直接在該區塊鏈中創建與該目標電子票據對應的沖紅票據。
在實際應用中,該區塊鏈中的節點設備在將上述沖紅票據發布至該區塊鏈進行存證之後,可以將維護的上述目標電子票據更新為已開紅票狀態,以避免後續對該電子票據的誤操作。
在上述技術方案中,一方面,可以在監聽到發布至區塊鏈的與未完成入帳處理的電子票據對應的作廢交易時,將維護的該電子票據更新為已作廢狀態;另一方面,可以在監聽到發布至區塊鏈的與已完成入帳處理的電子票據對應的作廢交易時,將創建的與該電子票據對應的沖紅票據發布至該區塊鏈進行存證。採用這樣的方式,即可實現對區塊鏈中存證的電子票據的作廢處理。
請參考圖6,圖6是本說明書一示例性實施例示出的一種基於區塊鏈的電子票據作廢系統的示意圖。
在如圖6所示的基於區塊鏈的電子票據作廢系統中,區塊鏈中可以存證電子票據,例如:針對某筆帳單,該帳單的收款方可以在確認已經收到付款之後,向該帳單的付款方開具與該帳單對應的電子票據,並將該電子票據發布至區塊鏈進行存證。在這種情況下,該收款方即為該電子票據的開票方,該付款方即為該電子票據的受票方。
另一方面,該開票方可以在確認已經收到付款之後,對這筆帳單進行入帳處理,即對該電子票據進行入帳處理,例如:將該電子票據上記載的付款方、收款方以及金額重新記載在帳本上,以便於後續的財務核算,後續該開票方可以將與該電子票據對應的入帳結果發布至該區塊鏈進行存證。同樣地,該受票方也可以對該電子票據進行入帳處理,並將與該電子票據對應的入帳結果發布至該區塊鏈進行存證。
針對該區塊鏈中存證的某張電子票據,如果該電子票據的開票方發現該電子票據中的內容出現錯誤,例如:該電子票據上記載的金額錯誤,則該開票方可以直接構造與該電子票據對應的作廢交易,並將該作廢交易發布至該區塊鏈進行存證,以觸發對該區塊鏈中存證的該電子票據的作廢處理。
或者,該電子票據的受票方可以在需要對與該電子票據對應的訂單進行退款時,可以向該開票方發起針對該電子票據的退款請求,以由該開票方對該電子票據進行退款處理,例如:將該電子票據上記載的金額退還給該受票方。
具體地,該受票方可以構造與該電子票據對應的退款交易,並將該退款交易發布至該區塊鏈中進行存證,以觸發對該區塊鏈中存證的該電子票據的退款處理。
需要說明的是,上述區塊鏈中的每台節點設備都可以維護該區塊鏈中存證的每張電子票據的票據狀態。由於電子票據的票據狀態可能會發生變化,而區塊鏈中存證的資料通常無法被修改,因此該區塊鏈中的每台節點設備維護的每張電子票據的票據狀態都是儲存在該節點設備本地的,而不會被發布至該區塊鏈進行存證。
請參見圖7,圖7是本說明書一示例性實施例示出的一種電子票據的票據狀態更新流程的示意圖。
如圖7所示,在開票方開具電子票據之後,可以將該電子票據發布至區塊鏈進行存證,此時該電子票據為未報銷狀態。當用票單位等票據相關方(稱為報銷發起方)發起對該電子票據進行報銷處理時,可以將該電子票據由未報銷狀態更新為報銷鎖定狀態,以防止其他用票單位對該電子票據進行報銷處理,從而避免出現重複報銷的問題。當完成針對該電子票據的報銷處理(例如:將該電子票據上記載的金額轉帳至用票單位的指定帳戶)時,可以將該電子票據由報銷鎖定狀態更新為已報銷狀態。當完成針對該電子票據的入帳處理(例如:由開票方或受票方將該電子票據上記載的付款方、收款方以及金額重新記載在帳本上)時,可以將該電子票據由已報銷狀態更新為已入帳狀態。
在實際應用中,也可以不對電子票據進行報銷處理,而直接對該電子票據進行入帳處理,此時可以將該電子票據由未報銷狀態更新為已入帳狀態。
在將該電子票據更新為報銷鎖定狀態之後,如果在一段時間內未監聽到發布至該區塊鏈的與該電子票據對應的報銷結果,則可以將該電子票據由報銷鎖定狀態更新為未報銷狀態(即圖中的“過期”過程)。類似的,如果該電子票據未通過報銷校驗,則可以將該電子票據由報銷鎖定狀態更新為未報銷狀態(即圖中的“解除報銷”過程)。
除了對處於未報銷狀態的電子票據進行報銷處理之外,還可以對該電子票據進行沖紅、列印(例如:使用財政空白票列印)、作廢等處理,此時可以將該電子票據相應更新為已開紅票狀態、已列印狀態、已作廢狀態。
在實際應用中,可以將未報銷狀態、報銷鎖定狀態、已報銷狀態、已入帳狀態視為電子票據的有效狀態;而將已開紅票狀態、已列印狀態、已作廢狀態視為電子票據的失效狀態。對於處於失效狀態的電子票據而言,無法對該電子票據執行任何操作。
另一方面,上述票據相關方可以向上述區塊鏈中的節點設備發送票據狀態訂閱請求,例如:可以透過與該節點設備對接的客戶端向該節點設備發送票據狀態訂閱請求,以實現對該節點設備維護的電子票據的票據狀態的訂閱。
在票據相關方訂閱了上述區塊鏈中的節點設備維護的某張電子票據的票據狀態之後,如果該電子票據的票據狀態發生更新,則該節點設備可以主動向該票據相關方推送該電子票據的更新後的票據狀態。
請參考圖8,圖8是本說明書一示例性實施例示出的一種基於區塊鏈的電子票據作廢方法的流程圖。該方法可以應用於圖6所示的基於區塊鏈的電子票據作廢系統中作為節點設備加入至該區塊鏈的電子設備;其中,該電子設備可以是伺服器、電腦、手機、平板設備、筆記型電腦或掌上電腦(PDAs,Personal Digital Assistants)等,本說明書對此不作限制。該方法可以包括以下步驟:
步驟802,在監聽到發布至所述區塊鏈的與目標電子票據對應的作廢交易時,確定所述目標電子票據是否已完成入帳處理;
步驟804,如果所述目標電子票據未完成入帳處理,則將維護的所述目標電子票據更新為已作廢狀態;
步驟806,如果所述目標電子票據已完成入帳處理,則將創建的與所述目標電子票據對應的沖紅票據發布至所述區塊鏈進行存證。
以下以採用MPT樹的資料結構,將區塊鏈中的帳戶狀態資料組織成MPT狀態樹為例,對本說明書的技術方案進行詳細描述;
其中,需要强調的是,以採用MPT樹的資料結構來組織區塊鏈中的帳戶狀態資料,僅為示例性的。
在實際應用中,對於基於以太坊架構而衍生出的區塊鏈項目,除了可以採用諸如MPT樹等改良版的Merkle樹以外,也可以採用類似於MPT樹的融合了Trie字典樹的Merkle樹變種,在本說明書中不再進行一一列舉。
針對上述區塊鏈中存證的某張電子票據(稱為目標電子票據),如果該目標電子票據的開票方需要對該目標電子票據進行作廢,則該開票方可以發起針對該目標電子票據的作廢處理,即該開票方可以構建與該目標電子票據對應的作廢交易,並將該作廢交易發布至該區塊鏈進行存證;或者,如果該目標電子票據的受票方需要對與該目標電子票據對應的訂單進行退款,則該受票方可以發起針對該目標電子票據的退款處理,即該受票方可以構建與該目標電子票據對應的退款交易,並將該退款交易發布至該區塊鏈進行存證。
需要說明的是,可以將由該開票方發布至該區塊鏈的該作廢交易,以及由該受票方發布至該區塊鏈的該退款交易,統稱為發布至該區塊鏈的與該目標電子票據對應的作廢交易。其中,將與該目標電子票據對應的作廢交易發布至該區塊鏈進行存證的流程,可以參考前述將物理世界產生的真實資料在區塊鏈中進行持久化存證的流程,本說明書在此不再贅述。
該區塊鏈中的節點設備可以對在該區塊鏈中存證的資料進行監聽,從而可以監聽到發布至該區塊鏈的與上述目標電子票據對應的作廢交易。該區塊鏈中的節點設備在監聽到該作廢交易時,可以先確定該目標電子票據是否已完成入帳處理。
在實際應用中,針對上述區塊鏈中存證的某張電子票據,該電子票據的開票方或受票方在完成對該電子票據的入帳處理後,可以將與該電子票據對應的入帳結果發布至該區塊鏈進行存證。其中,將該入帳結果發布至該區塊鏈進行存證的流程,可以參考前述將物理世界產生的真實資料在區塊鏈中進行持久化存證的流程,本說明書在此不再贅述。
在示出的一種實施方式中,由於該區塊鏈中的節點設備可以對在該區塊鏈中存證的資料進行監聽,因此該區塊鏈中的節點設備可以確定是否監聽到上述入帳結果。如果該區塊鏈中的節點設備監聽到該入帳結果,則可以認為對該電子票據的入帳處理已經完成,從而可以將維護的該電子票據更新為已入帳狀態。
需要說明的是,由於該區塊鏈中的每台節點設備都可以確定是否監聽到該入帳結果,因此該區塊鏈中的每台節點設備都可以在監聽到該入帳結果時,將其維護的該電子票據更新為已入帳狀態。
在實際應用中,針對上述區塊鏈中存證的某張電子票據,該區塊鏈中的節點設備可以透過維護該電子票據的標識(例如:電子票據號碼)與狀態的對應關係,實現維護該電子票據的票據狀態。
在這種情況下,該入帳結果中的資料可以包括該電子票據的標識。該區塊鏈中的節點設備在監聽到該入帳結果時,可以基於該入帳結果中的該電子票據的標識,將維護的電子票據的標識與狀態的對應關係中,與該電子票據的標識對應的票據狀態更新為已入帳狀態。
另一方面,上述區塊鏈中的節點設備在監聽到上述作廢交易時,可以透過確定維護的上述目標電子票據是否為已入帳狀態,實現確定該目標電子票據是否已完成入帳處理。
具體地,該作廢交易中的資料可以包括該目標電子票據的標識。該區塊鏈中的節點設備在監聽到該作廢交易時,可以基於該作廢交易中的該目標電子票據的標識,在維護的電子票據的標識與狀態的對應關係中,查找到與該目標電子票據的標識對應的票據狀態,作為該目標電子票據的票據狀態。
如果確定該目標電子票據的票據狀態為已入帳狀態,即維護的該目標電子票據為已入帳狀態,則可以由此確定該目標電子票據已完成入帳處理。
相應地,如果該目標電子票據的票據狀態不為已入帳狀態,即維護的該目標電子票據不為已入帳狀態,則可以由此確定該目標電子票據未完成入帳處理。
舉例來說,該區塊鏈中的每台節點設備維護的該區塊鏈中存證的每張電子票據的票據狀態可以如下表1所示:
電子票據 | 狀態 |
電子票據1 | 已入帳 |
電子票據2 | 已作廢 |
電子票據3 | 未報銷 |
…… | …… |
表1
在本說明書中,可以將除已入帳狀態、已作廢狀態以及已開紅票狀態之外的所有狀態都視為未入帳狀態。
如表1所示,該區塊鏈中的節點設備在監聽到與電子票據1對應的作廢交易1時,可以確定電子票據1為已入帳狀態,即電子票據1已完成入帳處理;該區塊鏈中的節點設備在監聽到與電子票據2對應的作廢交易2時,可以確定電子票據2為已作廢狀態,即電子票據2不為已入帳狀態,從而可以確定電子票據2未完成入帳處理;該區塊鏈中的節點設備在監聽到與電子票據3對應的作廢交易3時,可以確定電子票據3為未報銷狀態,即電子票據3不為已入帳狀態,從而可以確定電子票據3未完成入帳處理。
在示出的另一種實施方式中,上述區塊鏈中的節點設備在監聽到上述作廢交易時,可以透過確定該區塊鏈中是否存證了與上述目標電子票據對應的入帳結果,實現確定該目標電子票據是否已完成入帳處理。
具體地,上述入帳結果中的資料可以包括與該入帳結果對應的電子票據的標識;而該作廢交易中的資料則可以包括該目標電子票據的標識。該區塊鏈中的節點設備在監聽到該作廢交易時,可以基於該作廢交易中的該目標電子票據的標識,確定該區塊鏈中是否存證了其中的電子票據標識為該目標電子票據的標識的入帳結果。
如果確定該區塊鏈中存證了其中的電子票據標識為該目標電子票據的標識的入帳結果,則可以由此確定該目標電子票據已完成入帳處理。
相應地,如果確定該區塊鏈中未存證其中的電子票據標識為該目標電子票據的標識的入帳結果,則可以由此確定該目標電子票據未完成入帳處理。
進一步地,如果上述區塊鏈中的節點設備確定上述目標電子票據未完成入帳處理,則可以直接將維護的該目標電子票據更新為已作廢狀態,以對該目標電子票據進行作廢處理。後續,由於該目標電子票據已經是已作廢狀態,因此可以不再對該目標電子票據進行任何操作,例如:可以終止對該目標電子票據的入帳處理。
如果上述區塊鏈中的節點設備確定上述目標電子票據已完成入帳處理,則可以創建與該目標電子票據對應的沖紅票據,並將該沖紅票據發布至該區塊鏈進行存證,以對目標電子票據進行作廢處理。需要說明的是,在這種情況下,由於該目標電子票據已完成入帳處理,因此還需要對該沖紅票據進行入帳處理,以保障財務上的收支平衡。其中,對該沖紅票據進行入帳處理的流程與對該目標電子票據進行入帳處理的流程是相同的,本說明書對此不再贅述。
在實際應用中,針對某張電子票據,與該電子票據對應的沖紅票據和該電子票據本身相比,其中的收款方和付款方等資料都可以是相同的,但該沖紅票據中的金額與該電子票據中的金額之和應當為0,即該沖紅票據中的金額為該電子票據中的金額的相反數。
舉例來說,假設某張電子票據中的收款方為收款方A,付款方為付款方B,金額為100元。在這種情況下,與該電子票據對應的沖紅票據中的收款方也為收款方A,付款方也為付款方B,但金額為-100元(即:-100+100=0)。
在示出的一種實施方式中,上述區塊鏈中的節點設備在確定上述目標電子票據已完成入帳處理時,可以基於預設的票據創建邏輯,在本地創建與該目標電子票據對應的沖紅票據,例如:可以對該目標電子票據進行複製,並將複製得到的電子票據中的金額修改為該目標電子票據中的金額的相反數,修改後的電子票據即可作為該目標電子票據的沖紅票據。其中,該票據創建邏輯可以由技術人員預先設置並儲存至該節點設備。
該節點設備在本地創建了與該目標電子票據對應的沖紅票據之後,可以將該沖紅票據發布至該區塊鏈進行存證。其中,將該沖紅票據發布至該區塊鏈進行存證的流程,可以參考前述將物理世界產生的真實資料在區塊鏈中進行持久化存證的流程,本說明書在此不再贅述。
在示出的另一種實施方式中,上述區塊鏈中的節點設備在確定上述目標電子票據已完成入帳處理時,可以調用部署在該區塊鏈上的智慧合約中聲明的票據創建邏輯,創建與該目標電子票據對應的沖紅票據,即直接在該區塊鏈中創建與該目標電子票據對應的沖紅票據。
其中,票據創建邏輯具體可以是聲明在該智慧合約中的,與創建與電子票據對應的沖紅票據的執行邏輯相關的程式碼(例如:一些可供調用的程式方法或者函數);創建和調用該智慧合約的流程可以參考前述智慧合約的創建和調用流程,本說明書在此不再贅述。
需要說明的是,該區塊鏈中的節點設備在將上述沖紅票據發布至該區塊鏈進行存證之後,可以將維護的上述目標電子票據更新為已開紅票狀態,以避免後續對該電子票據的誤操作。
結合對與上述目標電子票據對應的作廢交易的描述可知,該作廢交易可以是由該目標電子票據的開票方發布至上述區塊鏈的與該目標電子票據對應的作廢交易;或者,該作廢交易可以是由該目標電子票據的受票方發布至該區塊鏈的與該目標電子票據對應的退款交易。
下面對由該開票方發起針對該目標電子票據的作廢處理,以及由該受票方發起針對該目標電子票據的退款處理兩種情況分別進行描述。
當由該開票方發起針對該目標電子票據的作廢處理,即由該開票方構建與該目標電子票據對應的作廢交易,並將該作廢交易發布至該區塊鏈進行存證時,該區塊鏈中的節點設備可以接收到該作廢交易,並對接收到的該作廢交易進行共識處理。在達成共識後,該區塊鏈中的節點設備可以將該作廢交易打包進區塊,在該區塊鏈中進行持久化存證。
對於打包進區塊的該作廢交易,該區塊鏈中的節點設備可以執行該作廢交易,即回應於該作廢交易,調用部署在該區塊鏈上的智慧合約中聲明的作廢校驗邏輯,對該目標電子票據進行作廢校驗,即確定該目標電子票據是否符合作廢條件。
其中,作廢校驗邏輯具體可以是聲明在該智慧合約中的,與對電子票據進行作廢校驗的執行邏輯相關的程式碼(例如:一些可供調用的程式方法或者函數);創建和調用該智慧合約的流程可以參考前述智慧合約的創建和調用流程,本說明書在此不再贅述。
如果該目標電子票據符合作廢條件,即對該目標電子票據的作廢校驗通過,則可以由該智慧合約產生與該目標電子票據對應的校驗通過事件。該節點設備在監聽到該校驗通過事件時,即可進一步確定該目標電子票據是否已完成入帳處理,從而可以在該目標電子票據未完成入帳處理時,將維護的該目標電子票據更新為已作廢狀態,或者在該目標電子票據已完成入帳處理時,將創建的與該目標電子票據對應的沖紅票據發布至該區塊鏈進行存證。
在實際應用中,該智慧合約在產生該校驗通過事件之後,可以將該校驗通過事件儲存至與該作廢交易對應的交易日誌。該節點設備可以進行日誌監聽,從而可以監聽到與該作廢交易對應的交易日誌中儲存的該校驗通過事件。該節點設備在監聽到該校驗通過事件時,即可進一步確定該目標電子票據是否已完成入帳處理。
在示出的一種實施方式中,針對電子票據的作廢條件可以包括:作廢權限條件;作廢期限條件。
其中,針對上述目標電子票據的作廢權限條件可以是上述開票方(即發起針對該目標電子票據的作廢處理的用戶)具有該目標電子票據的作廢權限,例如:該開票方是否為該目標電子票據上記載的收款方。
舉例來說,上述作廢交易中的資料可以包括該開票方的用戶標識(例如:納稅人識別號)。該區塊鏈中的節點設備可以先確定該目標電子票據上記載的收款方的用戶標識,再比較這兩個用戶標識是否一致。如果這兩個用戶標識一致,則該區塊鏈中的節點設備可以確定該開票方為該目標電子票據上記載的收款方,從而可以確定該目標電子票據符合作廢權限條件。
針對上述目標電子票據的作廢期限條件可以是該目標電子票據上記載的開票時刻與監聽到上述作廢交易的時刻之間的時間間隔小於允許作廢的時間間隔。其中,該允許作廢的時間間隔可以由票據管理方預先設置。
舉例來說,該區塊鏈中的節點設備可以在本地維護預先設置的允許作廢的時間間隔,假設該允許作廢的時間間隔為48小時。在這種情況下,該區塊鏈中的節點設備可以確定該目標電子票據上記載的開票時刻與監聽到該作廢交易的時刻之間的時間間隔是否小於該允許作廢的時間間隔。假設該目標電子票據上記載的開票時刻為5月31日15點整,該區塊鏈中的節點設備監聽到該作廢交易的時刻為6月1日20點整,兩者之間的時間間隔為29小時,小於該允許作廢的時間間隔,因此該區塊鏈中的節點設備可以確定該目標電子票據符合作廢期限條件。
當由該受票方發起針對該目標電子票據的退款處理,即由該受票方構建與該目標電子票據對應的退款交易,並將該退款交易發布至該區塊鏈進行存證時,該區塊鏈中的節點設備可以接收到該退款交易,並對接收到的該退款交易進行共識處理。在達成共識後,該區塊鏈中的節點設備可以將該退款交易打包進區塊,在該區塊鏈中進行持久化存證。
對於打包進區塊的該退款交易,該區塊鏈中的節點設備可以執行該退款交易,即回應於該退款交易,調用部署在該區塊鏈上的智慧合約中聲明的退款校驗邏輯,對該目標電子票據進行退款校驗,即確定該目標電子票據是否符合退款條件。
其中,退款校驗邏輯具體可以是聲明在該智慧合約中的,與對電子票據進行退款校驗的執行邏輯相關的程式碼(例如:一些可供調用的程式方法或者函數);創建和調用該智慧合約的流程可以參考前述智慧合約的創建和調用流程,本說明書在此不再贅述。
如果該目標電子票據符合退款條件,即對該目標電子票據的退款校驗通過,則可以由該智慧合約產生與該目標電子票據對應的校驗通過事件。該節點設備在監聽到該校驗通過事件時,即可進一步確定該目標電子票據是否已完成入帳處理,從而可以在該目標電子票據未完成入帳處理時,將維護的該目標電子票據更新為已作廢狀態,或者在該目標電子票據已完成入帳處理時,將創建的與該目標電子票據對應的沖紅票據發布至該區塊鏈進行存證。
在實際應用中,該智慧合約在產生該校驗通過事件之後,可以將該校驗通過事件儲存至與該退款交易對應的交易日誌。該節點設備可以進行日誌監聽,從而可以監聽到與該退款交易對應的交易日誌中儲存的該校驗通過事件。該節點設備在監聽到該校驗通過事件時,即可進一步確定該目標電子票據是否已完成入帳處理。
在示出的一種實施方式中,針對電子票據的退款條件可以包括:退款權限條件;退款期限條件。
其中,針對上述目標電子票據的退款權限條件可以是上述受票方(即發起針對該目標電子票據的退款處理的用戶)具有該目標電子票據的退款權限,例如:該受票方是否為該目標電子票據上記載的付款方。
舉例來說,上述退款交易中的資料可以包括該受票方的用戶標識(例如:納稅人識別號)。該區塊鏈中的節點設備可以先確定該目標電子票據上記載的付款方的用戶標識,再比較這兩個用戶標識是否一致。如果這兩個用戶標識一致,則該區塊鏈中的節點設備可以確定該受票方為該目標電子票據上記載的付款方,從而可以確定該目標電子票據符合退款權限條件。
針對上述目標電子票據的退款額度條件可以是該受票方申請退款的金額小於該目標電子票據上記載的金額。
舉例來說,上述退款交易中的資料可以包括該受票方申請退款的金額。該區塊鏈中的節點設備可以先確定該目標電子票據上記載的金額,再確定該受票方申請退款的金額是否小於該目標電子票據上記載的金額。如果該受票方申請退款的金額小於該目標電子票據上記載的金額,則該區塊鏈中的節點設備可以確定該目標電子票據符合退款額度條件。
針對上述目標電子票據的退款期限條件可以是該目標電子票據上記載的開票時刻與監聽到上述退款交易的時刻之間的時間間隔小於允許退款的時間間隔。其中,該允許退款的時間間隔可以由票據管理方預先設置。
舉例來說,該區塊鏈中的節點設備可以在本地維護預先設置的允許退款的時間間隔,假設該允許退款的時間間隔為48小時。在這種情況下,該區塊鏈中的節點設備可以確定該目標電子票據上記載的開票時刻與監聽到該退款交易的時刻之間的時間間隔是否小於該允許退款的時間間隔。假設該目標電子票據上記載的開票時刻為5月31日15點整,該區塊鏈中的節點設備監聽到該退款交易的時刻為6月1日20點整,兩者之間的時間間隔為29小時,小於該允許退款的時間間隔,因此該區塊鏈中的節點設備可以確定該目標電子票據符合退款期限條件。
另一方面,上述區塊鏈中的節點設備在將創建的與上述目標電子票據對應的上述沖紅票據發布至該區塊鏈進行存證之後,可以指示該目標電子票據的開票方對該目標電子票據進行退款處理。
在示出的一種實施方式中,該區塊鏈中的節點設備在將上述沖紅票據發布至該區塊鏈進行存證之後,還可以將維護的上述目標電子票據更新為已開紅票狀態。該開票方則可以向該區塊鏈中的節點設備訂閱其維護的該目標電子票據的票據狀態。
在這種情況下,該節點設備在將維護的該目標電子票據更新為已開紅票狀態之後,可以將該目標電子票據的已開紅票狀態推送至訂閱了該目標電子票據的票據狀態的該開票方,以觸發該開票方對處於已開紅票狀態的該目標電子票據進行退款處理,即該開票方可以在接收到該節點設備推送的該目標電子票據的已開紅票狀態之後,對該目標電子票據進行退款處理,例如:該開票方可以透過與該節點設備對接的客戶端接收到該節點設備推送的該目標電子票據的已開紅票狀態,並透過該客戶端對該目標電子票據進行退款處理。
或者,該節點設備在將維護的該目標電子票據更新為已開紅票狀態之後,可以直接向該開票方發送用於指示對該目標電子票據進行退款處理的通知消息,以通知該開票方可以對該目標電子票據進行退款處理,即該開票方可以在接收到該節點設備發送的該通知消息之後,對該目標電子票據進行退款處理。
在上述技術方案中,一方面,可以在監聽到發布至區塊鏈的與未完成入帳處理的電子票據對應的作廢交易時,將維護的該電子票據更新為已作廢狀態;另一方面,可以在監聽到發布至區塊鏈的與已完成入帳處理的電子票據對應的作廢交易時,將創建的與該電子票據對應的沖紅票據發布至該區塊鏈進行存證。採用這樣的方式,即可實現對區塊鏈中存證的電子票據的作廢處理。
與前述基於區塊鏈的電子票據作廢方法的實施例相對應,本說明書還提供了基於區塊鏈的電子票據作廢裝置的實施例。
本說明書基於區塊鏈的電子票據作廢裝置的實施例可以應用在電子設備上。裝置實施例可以透過軟體實現,也可以透過硬體或者軟硬體結合的方式實現。以軟體實現為例,作為一個邏輯意義上的裝置,是透過其所在電子設備的處理器將非易失性記憶體中對應的電腦程式指令讀取到內部記憶體中運行形成的。
從硬體層面而言,如圖9所示,為本說明書基於區塊鏈的電子票據作廢裝置所在電子設備的一種硬體結構圖,除了圖9所示的處理器、內部記憶體、網路介面、以及非易失性記憶體之外,實施例中裝置所在的電子設備通常根據該基於區塊鏈的電子票據作廢的實際功能,還可以包括其他硬體,對此不再贅述。
請參考圖10,圖10是本說明書一示例性實施例示出的一種基於區塊鏈的電子票據作廢裝置的方塊圖。所述裝置100可以應用於圖9所示的電子設備,所述電子設備可以作為節點設備加入至所述區塊鏈;所述區塊鏈中存證了電子票據;所述裝置100可以包括:
確定模組1001,用於在監聽到發布至所述區塊鏈的與目標電子票據對應的作廢交易時,確定所述目標電子票據是否已完成入帳處理;
更新模組1002,用於在所述目標電子票據未完成入帳處理時,將維護的所述目標電子票據更新為已作廢狀態;
創建模組1003,用於在所述目標電子票據已完成入帳處理時,將創建的與所述目標電子票據對應的沖紅票據發布至所述區塊鏈進行存證。
在本實施例中,所述確定模組1001具體可以用於:
確定維護的所述目標電子票據是否為已入帳狀態;
如果所述目標電子票據為已入帳狀態,則確定所述目標電子票據已完成入帳處理;
如果所述目標電子票據不為已入帳狀態,則確定所述目標電子票據未完成入帳處理。
在本實施例中,所述創建模組1003具體可以用於:
調用部署在所述區塊鏈上的智慧合約中聲明的票據創建邏輯,創建與所述目標電子票據對應的沖紅票據。
在本實施例中,所述發布至所述區塊鏈的與目標電子票據對應的作廢交易,為所述目標電子票據的受票方發布至所述區塊鏈的與所述目標電子票據對應的退款交易;
所述裝置100還可以包括:
指示模組1004,用於在將創建的與所述目標電子票據對應的沖紅票據發布至所述區塊鏈進行存證之後,指示所述目標電子票據的開票方對所述目標電子票據進行退款處理。
在本實施例中,所述目標電子票據的開票方訂閱了所述節點設備維護的所述目標電子票據的票據狀態;
所述指示模組1004具體可以用於:
在將創建的與所述目標電子票據對應的沖紅票據發布至所述區塊鏈進行存證之後,將維護的所述目標電子票據更新為已開紅票狀態,並將所述目標電子票據的已開紅票狀態推送至所述開票方,以觸發所述開票方對所述目標電子票據進行退款處理。
在本實施例中,所述確定模組1001具體可以用於:
回應於所述退款交易,調用部署在所述區塊鏈上的智慧合約中聲明的退款校驗邏輯,確定所述目標電子票據是否符合退款條件;
回應於監聽到的由所述智慧合約產生的與所述目標電子票據對應的校驗通過事件,進一步地確定所述目標電子票據是否已完成入帳處理。
在本實施例中,所述退款條件可以包括:退款權限條件;退款金額條件;退款期限條件。
在本實施例中,所述發布至所述區塊鏈的與目標電子票據對應的作廢交易,為所述目標電子票據的開票方發布至所述區塊鏈的與所述目標電子票據對應的作廢交易;
所述確定模組1001具體可以用於:
回應於所述作廢交易,調用部署在所述區塊鏈上的智慧合約中聲明的作廢校驗邏輯,確定所述目標電子票據是否符合作廢條件;
回應於監聽到的由所述智慧合約產生的與所述目標電子票據對應的校驗通過事件,進一步地確定所述目標電子票據是否已完成入帳處理。
在本實施例中,所述作廢條件可以包括:作廢權限條件;作廢期限條件。
上述裝置中各個模組的功能和作用的實現過程具體詳見上述方法中對應步驟的實現過程,在此不再贅述。
對於裝置實施例而言,由於其基本對應於方法實施例,所以相關之處參見方法實施例的部分說明即可。以上所描述的裝置實施例僅僅是示意性的,其中所述作為分離部件說明的模組可以是或者也可以不是物理上分開的,作為模組顯示的部件可以是或者也可以不是物理模組,即可以位於一個地方,或者也可以分布到多個網路模組上。可以根據實際的需要選擇其中的部分或者全部模組來實現本說明書方案的目的。本領域普通技術人員在不付出創造性勞動的情況下,即可以理解並實施。
上述實施例闡明的系統、裝置、模組或單元,具體可以由電腦晶片或實體實現,或者由具有某種功能的產品來實現。一種典型的實現設備為電腦,電腦的具體形式可以是個人電腦、膝上型電腦、行動電話、相機電話、智慧電話、個人數位助理、媒體播放器、導航設備、電子郵件收發設備、遊戲控制台、平板電腦、可穿戴設備或者這些設備中的任意幾種設備的組合。
在一個典型的配置中,電腦包括一個或多個處理器(CPU)、輸入/輸出介面、網路介面和內部記憶體。
內部記憶體可能包括電腦可讀媒體中的非永久性記憶體,隨機存取記憶體(RAM)和/或非易失性內部記憶體等形式,如唯讀記憶體(ROM)或快閃記憶體(flash RAM)。內部記憶體是電腦可讀媒體的示例。
電腦可讀媒體包括永久性和非永久性、可移動和非可移動媒體可以由任何方法或技術來實現資訊儲存。資訊可以是電腦可讀指令、資料結構、程式的模組或其他資料。電腦的儲存媒體的例子包括,但不限於相變內部記憶體(PRAM)、靜態隨機存取記憶體(SRAM)、動態隨機存取記憶體(DRAM)、其他類型的隨機存取記憶體(RAM)、唯讀記憶體(ROM)、電可擦除可程式化唯讀記憶體(EEPROM)、快閃記憶體或其他內部記憶體技術、唯讀光碟唯讀記憶體(CD-ROM)、數位多功能光碟(DVD)或其他光學儲存、磁盒式磁帶、磁碟儲存、量子記憶體、基於石墨烯的儲存媒體或其他磁性儲存設備或任何其他非傳輸媒體,可用於儲存可以被計算設備存取的資訊。按照本文中的界定,電腦可讀媒體不包括暫存電腦可讀媒體(transitory media),如調變的資料信號和載波。
還需要說明的是,術語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含,從而使得包括一系列要素的過程、方法、商品或者設備不僅包括那些要素,而且還包括沒有明確列出的其他要素,或者是還包括為這種過程、方法、商品或者設備所固有的要素。在沒有更多限制的情況下,由語句“包括一個……”限定的要素,並不排除在包括所述要素的過程、方法、商品或者設備中還存在另外的相同要素。
上述對本說明書特定實施例進行了描述。其它實施例在所附申請專利範圍的範圍內。在一些情況下,在申請專利範圍中記載的動作或步驟可以按照不同於實施例中的順序來執行並且仍然可以實現期望的結果。另外,在圖式中描繪的過程不一定要求示出的特定順序或者連續順序才能實現期望的結果。在某些實施方式中,多任務處理和並行處理也是可以的或者可能是有利的。
在本說明書一個或多個實施例使用的術語是僅僅出於描述特定實施例的目的,而非旨在限制本說明書一個或多個實施例。在本說明書一個或多個實施例和所附申請專利範圍中所使用的單數形式的“一種”、“所述”和“該”也旨在包括多數形式,除非上下文清楚地表示其他含義。還應當理解,本文中使用的術語“和/或”是指並包含一個或多個相關聯的列出項目的任何或所有可能組合。
應當理解,儘管在本說明書一個或多個實施例可能採用術語第一、第二、第三等來描述各種資訊,但這些資訊不應限於這些術語。這些術語僅用來將同一類型的資訊彼此區分開。例如,在不脫離本說明書一個或多個實施例範圍的情況下,第一資訊也可以被稱為第二資訊,類似地,第二資訊也可以被稱為第一資訊。取決於語境,如在此所使用的詞語“如果”可以被解釋成為“在……時”或“當……時”或“回應於確定”。
以上所述僅為本說明書一個或多個實施例的較佳實施例而已,並不用以限制本說明書一個或多個實施例,凡在本說明書一個或多個實施例的精神和原則之內,所做的任何修改、等同替換、改進等,均應包含在本說明書一個或多個實施例保護的範圍之內。