這裡將詳細地對示例性實施例進行說明，其示例表示在圖式中。下面的描述涉及圖式時，除非另有表示，不同圖式中的相同數字表示相同或相似的元件。以下示例性實施例中所描述的實施方式並不代表與本說明書一個或多個實施例相一致的所有實施方式。相反，它們僅是與如所附申請專利範圍中所詳述的、本說明書一個或多個實施例的一些方面相一致的裝置和方法的例子。
需要說明的是：在其他實施例中並不一定按照本說明書示出和描述的順序來執行相應方法的步驟。在一些其他實施例中，其方法所包括的步驟可以比本說明書所描述的更多或更少。此外，本說明書中所描述的單個步驟，在其他實施例中可能被分解為多個步驟進行描述；而本說明書中所描述的多個步驟，在其他實施例中也可能被合並為單個步驟進行描述。
圖1是一示例性實施例提供的一種基於區塊鏈的***創建方法的流程圖。如圖1所示，該方法應用於區塊鏈節點，可以包括以下步驟：
步驟102，接收用戶透過客戶端提交的***創建請求；其中，所述***創建請求包括交易標識和用戶輸入的***創建資訊。
在一實施例中，客戶端可以為交易參與方使用的手機、平板電腦、智慧手錶等任意類型的電子設備，本說明書並不對此進行限制。交易參與方透過在電子設備上登錄已註冊帳號，可與接入該電子設備的區塊鏈節點進行互動。
在一實施例中，交易參與方在完成一筆交易後，可透過客戶端向區塊鏈節點發送記錄請求以使得該區塊鏈節點將該交易的交易資訊發佈至區塊鏈。例如，交易資訊可以包括交易標識、交易平臺、交易金額、交易內容、交易參與方、交易時間等。當然，本說明書並不對交易資訊的具體內容進行限制。透過將交易資訊發佈至區塊鏈，使得各個區塊鏈節點均記錄有一份完整的交易資訊，那麽即使某個節點出現資料損壞的問題，也不會影響整體的資料完整性；同時，可充分利用區塊鏈儲存資料的不可篡改性，從而防止不法分子惡意修改交易資訊，保證了所記錄交易資訊的安全和透明，便於用戶溯源。
步驟104，響應於所述***創建請求，確定所述區塊鏈上是否存證了與所述交易標識對應的目標交易；以及，用於指示所述目標交易為有效交易的至少一種關鍵資訊。
在一實施例中，可根據交易標識查找區塊鏈上是否存證有相應的目標交易。換言之，需確定與該交易標識對應的交易是否客觀存在。進一步的，如果所述區塊鏈上存證有所述目標交易，需進一步確定所述目標交易是否為有效交易；如果是，調用智慧合約中聲明的***創建邏輯。透過在確定出目標交易為一筆客觀存在的交易後，進一步確定目標交易是否為有效交易(可理解為目標交易為一筆真實發生過的交易)，可有效防止用戶虛開***。
而在確定目標交易是否為有效交易時，可利用區塊鏈上存證的目標交易的至少一種關鍵資訊。交易參與方在完成一筆交易後，除交易資訊外，還可將用於指示該交易為有效交易的至少一種關鍵資訊也發送至區塊鏈節點，以使得該區塊鏈節點將該關鍵資訊發佈至區塊鏈。進一步的，區塊鏈節點可將交易的交易資訊和關鍵資訊關聯地發佈至區塊鏈上。基於上述對交易的關鍵資訊的存證，在一種情況下，可確定區塊鏈上是否存證了用於指示目標交易為有效交易的至少一種關鍵資訊，如果是，可確定目標交易為有效交易。在另一種情況下，可先確定區塊鏈上是否存證了用於指示目標交易為有效交易的至少一種關鍵資訊，如果確定區塊鏈上存證了該至少一種關鍵資訊，可進一步確定該至少一種關鍵資訊中的各種關鍵資訊是否完整，如果是，可確定目標交易為有效交易，進而調用智慧合約中聲明的***創建邏輯。其中，該至少一種關鍵資訊可以包含以下至少之一：與目標交易對應的訂單記錄、物流記錄、支付記錄；以及，與目標交易對應的參與方的身份資訊。
需要說明的是，上述確定目標交易是否為有效交易的操作，可由區塊鏈節點自身執行，也可由預先部署於區塊鏈上的智慧合約(聲明有校驗邏輯，用於確定任一交易是否為有效交易)來執行，本說明書並不對此進行限制。
步驟106，如果確定所述區塊鏈上存證了所述目標交易和所述關鍵資訊，調用智慧合約中聲明的***創建邏輯，根據所述***創建資訊為所述目標交易創建***，並將創建的***發佈至所述區塊鏈。
在一種情況下，***創建資訊可以包括***的抬頭資訊和與交易標識對應的交易的交易資訊(由用戶輸入)，區塊鏈節點在接收到***創建請求後將***創建資訊中包含的交易資訊與區塊鏈上存證的交易資訊(與交易標識相對應)進行對比，當對比結果為兩者一致時，直接根據***創建資訊中包含的交易資訊和抬頭資訊為目標交易創建***。例如，區塊鏈節點在接收到***創建請求後，讀取***創建資訊中包含的交易資訊並計算得到第一哈希值，將該第一哈希值與區塊鏈上存證的交易資訊(與交易標識相對應)的第二哈希值進行對比，當第一哈希值與第二哈希值相等時，可確定用戶輸入的交易資訊即為目標交易的交易資訊，那麽可直接根據用戶輸入的交易資訊和抬頭資訊為目標交易創建***，而無需讀取區塊鏈上存證的目標交易的交易資訊。
在另一種情況下，***創建資訊可以僅包括***的抬頭資訊，區塊鏈節點在接收到***創建請求並確定區塊鏈上存證有目標交易後，進一步讀取區塊鏈上存證的目標交易的交易資訊，再根據讀取到的交易資訊以及***的抬頭資訊為目標交易創建***。
在一實施例中，在為目標交易創建***後，可進一步將目標交易標記為已創建***狀態。其中，可在存證目標交易的字段中添加一字段用於標記***創建狀態，也可額外在區塊鏈上關聯存證該目標交易的***創建狀態，本說明書並不對此進行限制。透過記錄交易的***創建狀態，當接收到用戶透過客戶端提交的***創建請求時，可先判定與該***創建請求對應的交易的***創建狀態；若為已創建***狀態，則可以直接向客戶端返回已開具***的提示消息，否則進入上述創建***的流程。
在一實施例中，基於將所創建的***與目標交易關聯地發佈至區塊鏈，可部署智慧合約用於對***進行納稅申報，以實現基於區塊鏈對***的納稅申報。因此，區塊鏈節點可接收用戶透過客戶端提交的納稅申報請求(納稅申報請求包括***標識)，並響應於該納稅申報請求，調用智慧合約中聲明的***申報邏輯，基於區塊鏈上存證的與該***標識對應的***完成納稅申報。類似的，在完成納稅申報後，可將與該***標識對應的***標記為已申報狀態。其中，可在存證***的字段中添加一字段用於標記***申報狀態，也可額外在區塊鏈上關聯存證該交易的***申報狀態，本說明書並不對此進行限制。透過記錄***的***申報狀態，當接收到用戶透過客戶端提交的納稅申報請求時，可先判定與該納稅申報請求對應的***的***申報狀態；若為已申報狀態，則可以直接向客戶端返回已申報的提示消息，否則進入上述納稅申報的流程。
在一實施例中，上述區塊鏈可以為聯盟鏈，聯盟鏈的成員節點可以包括支付平臺和稅務機關。其中，稅務機關可作為監管方查看區塊鏈上存證的交易、***等資訊。
圖2是一示例性實施例提供的一種***創建方案的整體架構示意圖。如圖2所示，交易參與方之間在完成一筆交易後，可透過客戶端21向伺服器22發送記錄請求以使得伺服器22將該交易的交易資訊發佈至區塊鏈。進一步的，當交易參與方存在開具***的需求時，可透過客戶端21向伺服器22發送***創建請求，伺服器22在接收到該***創建請求(包括交易標識和用戶輸入的***創建資訊)後，確定區塊鏈上是否存證有與該交易標識對應的目標交易，並在區塊鏈上存證有目標交易的情況下調用智慧合約中聲明的***創建邏輯為目標交易創建***，並將創建的***發佈至區塊鏈。
為了便於理解，下面針對客戶端21、伺服器22分別在***創建過程中實現的操作和功能，結合圖3-5對本說明書的***創建方案進行詳細說明。圖3是一示例性實施例提供的交易上鏈的互動示意圖。如圖3所示，該互動過程可以包括以下步驟：
步驟302，客戶端21與伺服器22之間實現對綁定關係的建立。
在一實施例中，所需建立的綁定關係為交易參與方的身份資訊與客戶端21的設備資訊之間的綁定關係。基於該綁定關係，使得伺服器22在接收到客戶端21後續發送的交易記錄請求、***創建請求和納稅申報請求時，可以確認這些請求對應於該交易參與方。
舉例而言，交易參與方可以預先在伺服器22處進行帳號註冊，得到與自身唯一對應的已註冊帳號。然後，交易參與方可以透過在客戶端21上登錄該已註冊帳號，而伺服器22基於該已註冊帳號在客戶端21上的登錄資訊，確定該已註冊帳號(對應於交易參與方)與客戶端21之間建立了綁定關係。
步驟304，客戶端21對待記錄的交易和關鍵資訊簽名。
在一實施例中，交易參與方之間在完成交易後，可透過客戶端21向伺服器22提交交易記錄請求，以使得伺服器22將待記錄的交易資訊和該交易的關鍵資訊發佈至區塊鏈中。其中，交易參與方可以預先註冊得到唯一對應的數位身份，該數位身份由一組公私鑰對進行表徵。相應地，客戶端21在獲取到交易參與方輸入的交易資訊和該交易的關鍵資訊後，可產生交易記錄請求(包含交易資訊和關鍵資訊)並透過對應於交易參與方的數位身份的私鑰對交易記錄請求進行簽名。
步驟306，客戶端21向伺服器22提交交易記錄請求。
步驟308，伺服器22驗證簽名。
在一實施例中，伺服器22上運行有區塊鏈的客戶端，使得該伺服器22被配置為一區塊鏈節點。伺服器22在接收到交易記錄請求後，可基於上述步驟302建立的綁定關係確定出交易參與方的身份，從而透過對應於交易參與方的公鑰進行驗簽，以確定該交易記錄請求已由該交易參與方進行授權，而並非由不法分子冒充該交易參與方的身份進行發送。
在一實施例中，當驗簽未通過時，由於客戶端預先透過已註冊帳號與交易參與方綁定，表明可能存在不法分子冒充交易參與方的身份，那麽可觸發報警操作並暫時封鎖客戶端接入區塊鏈節點的權限。
步驟310，伺服器22將交易資訊和關鍵資訊相關聯地發佈至區塊鏈。
舉例而言，交易資訊可以包括交易標識、交易平臺、交易金額、交易內容、交易參與方、交易時間等；關鍵資訊可包括訂單記錄、物流記錄、支付記錄、交易參與方的身份資訊等。其中，訂單資訊可以是交易參與方之間簽署的合約、交易的對象(比如，商品、技術支持等)的明細內容；物流記錄可以是交易的對象的物流資訊；支付記錄可以是交易參與方之間的付款和收款明細、開戶行名稱、開戶行帳號等；交易參與方的身份資訊可以是公司名稱、納稅人識別號、註冊地址等。當然，本說明書並不對交易資訊和關鍵資訊的具體內容進行限制。
請參見圖4，圖4是一示例性實施例提供的基於區塊鏈的***創建方法的流程圖。如圖4所示，該方法應用於區塊鏈節點(以伺服器22為例)，可以包括以下步驟：
步驟402，接收用戶透過客戶端21提交的***創建請求。
在一實施例中，***創建請求包括交易標識和用戶透過客戶端輸入的***創建資訊。
步驟404，若區塊鏈上存證有目標交易，則轉入步驟406B；否則，轉入步驟406A。
步驟406A，向客戶端21返回交易不存在的提示消息。
在一實施例中，可根據交易標識確定區塊鏈上是否存證有與該交易標識對應的目標交易。當區塊鏈上未存證目標交易時，說明此時客戶端21請求創建的***對應的交易(即目標交易)並非客觀存在的交易，因此可返回該提示消息以提醒用戶交易不存在。
步驟406B，若區塊鏈上存證的目標交易被標記為已創建***狀態，則轉入步驟408A；否則，轉入步驟408B。
步驟408A，向客戶端21返回***已開具的提示消息。
步驟408B，若區塊鏈上關聯存證有目標交易的關鍵資訊，則轉入步驟410B；否則，轉入步驟410A。
步驟410A，向客戶端21返回交易無效的提示消息。
承接於步驟408B，當區塊鏈上未關聯存證目標交易的關鍵資訊時，說明此時客戶端21請求創建的***對應的交易(即目標交易)並非有效交易(即目標交易並非一筆真實發生過的交易；換言之，目標交易存在虛假資訊)，因此可返回該提示消息以提醒用戶該交易為無效交易。
承接於步驟410B，當區塊鏈上關聯存證的關鍵資訊不完整時，說明此時客戶端21請求創建的***對應的交易(即目標交易)並非有效交易(即目標交易並非一筆真實發生過的交易；換言之，目標交易存在至少一部分的虛假資訊)，因此可返回該提示消息以提醒用戶該交易為無效交易。例如，關鍵資訊包括訂單記錄、物流記錄、支付記錄和交易參與方的身份資訊，假定當區塊鏈上僅關聯存證了目標交易的訂單記錄、支付記錄和交易參與方的身份資訊，而並未關聯存證支付記錄，則可判定目標交易為無效交易。
步驟410B，若關鍵資訊完整，則轉入步驟412；否則，轉入步驟410A。
在一實施例中，上述確定目標交易是否為有效交易的操作(步驟406B-410B)，可由伺服器22自身來執行，也可由預先部署於區塊鏈上的智慧合約(聲明有校驗邏輯，用於確定任一交易是否為有效交易)來執行，本說明書並不對此進行限制。可見，透過上述判定目標交易是否為有效交易的過程，可有效防止用戶虛開***。
步驟412，調用智慧合約中聲明的***創建邏輯，根據***創建資訊為目標交易創建***。
在一實施例中，該智慧合約可由支付機構和稅務機關預先部署於區塊鏈。
在一種情況下，用戶輸入的***創建資訊可以包括***的抬頭資訊和目標交易的交易資訊，伺服器22在接收到***創建請求後將***創建資訊中包含的交易資訊與區塊鏈上存證的交易資訊(與交易標識相對應)進行對比，當對比結果為兩者一致時，直接根據***創建資訊中包含的交易資訊和抬頭資訊為目標交易創建***。例如，伺服器22在接收到***創建請求後，讀取***創建資訊中包含的交易資訊並計算得到第一哈希值，將該第一哈希值與區塊鏈上存證的交易資訊(與交易標識相對應)的第二哈希值進行對比，當第一哈希值與第二哈希值相等時，可確定用戶輸入的交易資訊即為目標交易的交易資訊，那麽可直接根據用戶輸入的交易資訊和抬頭資訊為目標交易創建***，而無需讀取區塊鏈上存證的目標交易的交易資訊，從而提高創建***的效率。
在另一種情況下，用戶輸入的***創建資訊可以僅包括***的抬頭資訊，伺服器22在接收到***創建請求並確定區塊鏈上存證有目標交易後，進一步讀取區塊鏈上存證的目標交易的交易資訊，再根據讀取到的交易資訊以及***的抬頭資訊為目標交易創建***。
步驟414，將創建的***發佈至區塊鏈。
步驟416，將目標交易標記為已創建***狀態。
在一實施例中，可以在創建***後便將目標交易標記為已創建***狀態，也可以在將創建的***發佈至區塊鏈後再將目標交易標記為已創建***狀態，本說明書並不對此進行限制。
在一實施例中，可在存證目標交易的字段中添加一字段用於標記***創建狀態，也可額外在區塊鏈上關聯存證該目標交易的***創建狀態，本說明書並不對此進行限制。透過記錄交易的***創建狀態，當接收到用戶透過客戶端提交的***創建請求時，可先判定與該***創建請求對應的交易的***創建狀態；若為已創建***狀態，則可以直接向客戶端返回已開具***的提示消息，否則進入上述創建***的流程。
請參見圖5，圖5是一示例性實施例提供的基於區塊鏈的***申報方法的流程圖。如圖5所示，該方法應用於區塊鏈節點(以伺服器22為例)，可以包括以下步驟：
步驟502，接收用戶透過客戶端21提交的納稅申報請求。
在一實施例中，納稅申報請求包括交易標識。
步驟504，若區塊鏈上存證的與***標識對應的***被標記為已申報狀態，則轉入步驟510；否則，轉入步驟506。
步驟506，調用智慧合約中聲明的***申報邏輯，基於區塊鏈上存證的與***標識對應的***完成納稅申報。
在一實施例中，該智慧合約可由支付機構和稅務機關預先部署於區塊鏈。
步驟508，將與***標識對應的***標記為已申報狀態。
在一實施例中，可在存證該***的字段中添加一字段用於標記***申報狀態，也可額外在區塊鏈上關聯存證該***的***申報狀態，本說明書並不對此進行限制。透過記錄***的***申報狀態，當接收到用戶透過客戶端提交的納稅申報請求時，可先判定與該納稅申報請求對應的***的***申報狀態；若為已申報狀態，則可以直接向客戶端返回已申報的提示消息，否則進入上述納稅申報的流程。
步驟510，向客戶端21返回***已申報的提示消息。
需要說明的是，區塊鏈中的交易，存在狹義的交易以及廣義的交易之分。狹義的交易是指用戶向區塊鏈發佈的一筆價值轉移；例如，在傳統的比特幣區塊鏈網路中，交易可以是用戶在區塊鏈中發起的一筆轉帳。而廣義的交易是指用戶向區塊鏈發佈的一筆具有業務意圖的業務資料；例如，營運方可以基於實際的業務需求搭建一個聯盟鏈，依托於聯盟鏈部署一些與價值轉移無關的其它類型的線上業務(比如，租房業務、車輛調度業務、保險理賠業務、信用服務、醫療服務等)，而在這類聯盟鏈中，交易可以是用戶在聯盟鏈中發佈的一筆具有業務意圖的業務消息或者業務請求。
圖6是一示例性實施例提供的一種設備的示意結構圖。請參考圖6，在硬體層面，該設備包括處理器602、內部匯流排604、網路介面606、記憶體608以及非易失性記憶體610，當然還可能包括其他業務所需要的硬體。處理器602從非易失性記憶體610中讀取對應的電腦程式到記憶體608中然後運行，在邏輯層面上形成基於區塊鏈的***創建裝置。當然，除了軟體實現方式之外，本說明書一個或多個實施例並不排除其他實現方式，比如邏輯裝置抑或軟硬體結合的方式等等，也就是說以下處理流程的執行主體並不限定於各個邏輯單元，也可以是硬體或邏輯裝置。
請參考圖7，在軟體實施方式中，該基於區塊鏈的***創建裝置可以包括：
第一接收單元71，接收用戶透過客戶端提交的***創建請求；其中，所述***創建請求包括交易標識和用戶輸入的***創建資訊；
確定單元72，響應於所述***創建請求，確定所述區塊鏈上是否存證了與所述交易標識對應的目標交易；以及，用於指示所述目標交易為有效交易的至少一種關鍵資訊；
創建單元73，如果確定所述區塊鏈上存證了所述目標交易和所述關鍵資訊，調用智慧合約中聲明的***創建邏輯，根據所述***創建資訊為所述目標交易創建***，並將創建的***發佈至所述區塊鏈。
可選的，所述創建單元73具體用於：
如果確定所述區塊鏈上存證了所述目標交易和所述至少一種關鍵資訊，進一步確定所述至少一種關鍵資訊中的各種關鍵資訊是否完整；
如果是，調用智慧合約中聲明的***創建邏輯。
可選的，所述至少一種關鍵資訊包含以下至少之一：與所述目標交易對應的訂單記錄、物流記錄、支付記錄；以及，與所述目標交易對應的參與方的身份資訊。
可選的，還包括：
第二接收單元74，接收用戶透過客戶端提交的納稅申報請求；其中，所述納稅申報請求包括***標識；
申報單元75，響應於所述納稅申報請求，調用智慧合約中聲明的***申報邏輯，基於所述區塊鏈上存證的與所述***標識對應的***完成納稅申報。
可選的，還包括：
標記單元76，在完成納稅申報後，將與所述***標識對應的***標記為已申報狀態。
可選的，所述區塊鏈為聯盟鏈；所述聯盟鏈的成員節點包括：支付平臺、稅務機關。
上述實施例闡明的系統、裝置、模組或單元，具體可以由電腦晶片或實體實現，或者由具有某種功能的産品來實現。一種典型的實現設備為電腦，電腦的具體形式可以是個人電腦、膝上型電腦、蜂巢式電話、相機電話、智慧電話、個人數位助理、媒體播放器、導航設備、電子郵件收發設備、遊戲控制台、平板電腦、穿戴式設備或者這些設備中的任意幾種設備的組合。
在一個典型的配置中，電腦包括一個或多個處理器(CPU)、輸入/輸出介面、網路介面和記憶體。
記憶體可能包括電腦可讀媒體中的非永久性記憶體，隨機存取記憶體(RAM)和/或非易失性記憶體等形式，如唯讀記憶體(ROM)或快閃記憶體(flash RAM)。記憶體是電腦可讀媒體的示例。
電腦可讀媒體包括永久性和非永久性、可移動和非可移動媒體可以由任何方法或技術來實現資訊儲存。資訊可以是電腦可讀指令、資料結構、程式的模組或其他資料。電腦的儲存媒體的例子包括，但不限於相變記憶體(PRAM)、靜態隨機存取記憶體(SRAM)、動態隨機存取記憶體(DRAM)、其他類型的隨機存取記憶體(RAM)、唯讀記憶體(ROM)、電可抹除可程式唯讀記憶體(EEPROM)、快閃記憶體或其他記憶體技術、唯讀光碟唯讀記憶體(CD-ROM)、數位多功能光碟(DVD)或其他光學儲存、磁盒式磁帶、磁碟儲存、量子記憶體、基於石墨烯的儲存媒體或其他磁性儲存設備或任何其他非傳輸媒體，可用於儲存可以被計算設備存取的資訊。按照本文中的界定，電腦可讀媒體不包括暫存電腦可讀媒體(transitory media)，如調變的資料信號和載波。
還需要說明的是，術語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、商品或者設備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、商品或者設備所固有的要素。在沒有更多限制的情況下，由語句“包括一個……”限定的要素，並不排除在包括所述要素的過程、方法、商品或者設備中還存在另外的相同要素。
上述對本說明書特定實施例進行了描述。其它實施例在所附申請專利範圍的範圍內。在一些情況下，在申請專利範圍中記載的動作或步驟可以按照不同於實施例中的順序來執行並且仍然可以實現期望的結果。另外，在圖式中描繪的過程不一定要求示出的特定順序或者連續順序才能實現期望的結果。在某些實施方式中，多任務處理和平行處理也是可以的或者可能是有利的。
在本說明書一個或多個實施例使用的術語是僅僅出於描述特定實施例的目的，而非旨在限制本說明書一個或多個實施例。在本說明書一個或多個實施例和所附申請專利範圍中所使用的單數形式的“一種”、“所述”和“該”也旨在包括多數形式，除非上下文清楚地表示其他含義。還應當理解，本文中使用的術語“和/或”是指並包含一個或多個相關聯的列出項目的任何或所有可能組合。
應當理解，儘管在本說明書一個或多個實施例可能採用術語第一、第二、第三等來描述各種資訊，但這些資訊不應限於這些術語。這些術語僅用來將同一類型的資訊彼此區分開。例如，在不脫離本說明書一個或多個實施例範圍的情況下，第一資訊也可以被稱為第二資訊，類似地，第二資訊也可以被稱為第一資訊。取决於語境，如在此所使用的詞語“如果”可以被解釋成為“在……時”或“當……時”或“響應於確定”。
以上所述僅為本說明書一個或多個實施例的較佳實施例而已，並不用以限制本說明書一個或多個實施例，凡在本說明書一個或多個實施例的精神和原則之內，所做的任何修改、等同替換、改進等，均應包含在本說明書一個或多個實施例保護的範圍之內。Exemplary embodiments will be described in detail here, examples of which are shown in the drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings indicate the same or similar elements. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of this specification. On the contrary, they are merely examples of devices and methods consistent with some aspects of one or more embodiments of the present specification as detailed in the scope of the appended application.
It should be noted that in other embodiments, the steps of the corresponding method are not necessarily performed in the order shown and described in this specification. In some other embodiments, the method may include more or fewer steps than described in this specification. In addition, a single step described in this specification may be decomposed into multiple steps for description in other embodiments; and multiple steps described in this specification may also be combined into a single step in other embodiments. description.
Fig. 1 is a flowchart of a blockchain-based invoice creation method provided by an exemplary embodiment. As shown in Figure 1, the method is applied to blockchain nodes and can include the following steps:
Step 102: Receive an invoice creation request submitted by the user through the client; wherein the invoice creation request includes a transaction identifier and invoice creation information input by the user.
In an embodiment, the client terminal may be any type of electronic device such as a mobile phone, a tablet computer, or a smart watch used by a transaction participant, which is not limited in this specification. The transaction participant can interact with the blockchain node connected to the electronic device by logging in the registered account on the electronic device.
In one embodiment, after completing a transaction, a transaction participant can send a record request to a blockchain node through the client so that the blockchain node publishes the transaction information of the transaction to the blockchain. For example, transaction information may include transaction identification, transaction platform, transaction amount, transaction content, transaction participants, transaction time, etc. Of course, this manual does not limit the specific content of transaction information. By publishing transaction information to the blockchain, each blockchain node records a complete transaction information, so even if a node has data corruption, it will not affect the overall data integrity; at the same time, it can be fully The use of the non-tamperable modification of the data stored in the blockchain prevents criminals from maliciously modifying transaction information, ensuring the security and transparency of the recorded transaction information, and facilitating user traceability.
Step 104: In response to the invoice creation request, determine whether the target transaction corresponding to the transaction identifier is deposited on the blockchain; and at least one key information used to indicate that the target transaction is a valid transaction.
In one embodiment, it is possible to find whether there is a corresponding target transaction on the blockchain according to the transaction identifier. In other words, it is necessary to determine whether the transaction corresponding to the transaction identifier exists objectively. Further, if the target transaction is recorded on the blockchain, it is necessary to further determine whether the target transaction is a valid transaction; if so, call the invoice creation logic declared in the smart contract. After determining that the target transaction is an objective transaction, it is further determined whether the target transaction is a valid transaction (which can be understood as a transaction that actually occurred), which can effectively prevent users from falsely issuing invoices.
When determining whether the target transaction is a valid transaction, at least one key information of the target transaction deposited on the blockchain can be used. After completing a transaction, in addition to transaction information, transaction participants can also send at least one key information indicating that the transaction is a valid transaction to the blockchain node, so that the blockchain node can publish the key information To the blockchain. Further, the blockchain node can publish transaction information and key information of the transaction to the blockchain in association. Based on the deposit of key information of the transaction, in one case, it can be determined whether at least one key information indicating that the target transaction is a valid transaction is deposited on the blockchain. If so, the target transaction can be determined to be a valid transaction. . In another case, it can be determined whether at least one key information indicating that the target transaction is a valid transaction is stored on the blockchain. If it is determined that the at least one key information is stored on the blockchain, it can be further determined Whether various key information in at least one type of key information is complete, and if so, it can be determined that the target transaction is a valid transaction, and then the invoice creation logic declared in the smart contract can be called. Wherein, the at least one type of key information may include at least one of the following: order records, logistics records, and payment records corresponding to the target transaction; and identity information of participants corresponding to the target transaction.
It should be noted that the above operation of determining whether the target transaction is a valid transaction can be executed by the blockchain node itself, or by a smart contract pre-deployed on the blockchain (declared with verification logic to determine whether any transaction is For effective transactions), this manual does not limit this.
Step 106: If it is determined that the target transaction and the key information are deposited on the blockchain, call the invoice creation logic declared in the smart contract, create an invoice for the target transaction based on the invoice creation information, and add The created invoice is posted to the blockchain.
In one case, the invoice creation information may include the header information of the invoice and the transaction information (input by the user) of the transaction corresponding to the transaction identifier, and the blockchain node will add the transaction information contained in the invoice creation information after receiving the invoice creation request Compare with the transaction information (corresponding to the transaction identifier) of the deposit certificate on the blockchain. When the comparison result is the same, create an invoice for the target transaction directly based on the transaction information and header information contained in the invoice creation information. For example, after receiving the invoice creation request, the blockchain node reads the transaction information contained in the invoice creation information and calculates the first hash value, and then the first hash value is combined with the transaction information certified on the blockchain The second hash value (corresponding to the transaction identifier) is compared. When the first hash value is equal to the second hash value, it can be determined that the transaction information entered by the user is the transaction information of the target transaction. The transaction information and header information entered by the user create an invoice for the target transaction without reading the transaction information of the target transaction deposited on the blockchain.
In another case, the invoice creation information can only include the header information of the invoice. After receiving the invoice creation request and confirming that the target transaction is recorded on the blockchain, the blockchain node further reads the certificate deposit on the blockchain. Based on the transaction information of the target transaction, an invoice is created for the target transaction based on the read transaction information and the header information of the invoice.
In one embodiment, after the invoice is created for the target transaction, the target transaction may be further marked as an invoice created status. Among them, a field can be added to the field for depositing the target transaction to mark the status of the invoice creation, and the invoice creation status of the target transaction can also be associated and deposited on the blockchain. This manual does not limit this. By recording the invoice creation status of the transaction, when receiving the invoice creation request submitted by the user through the client, the invoice creation status of the transaction corresponding to the invoice creation request can be determined first; if it is the created invoice status, you can directly report to the customer The terminal returns the prompt message that the invoice has been issued, otherwise it enters the process of creating the invoice above.
In one embodiment, based on publishing the created invoice to the blockchain in association with the target transaction, a smart contract can be deployed for tax declaration of the invoice, so as to realize the tax declaration of the invoice based on the blockchain. Therefore, the blockchain node can receive the tax declaration request submitted by the user through the client (the tax declaration request includes the invoice identification), and in response to the tax declaration request, call the invoice declaration logic declared in the smart contract, based on the deposit on the blockchain. The invoice corresponding to the invoice identification of the certificate completes the tax declaration. Similarly, after completing the tax declaration, the invoice corresponding to the invoice identifier can be marked as declared. Among them, a field can be added to the field of the deposit invoice to mark the invoice declaration status, or the invoice declaration status of the transaction can be additionally associated on the blockchain. This manual does not limit this. By recording the invoice declaration status of the invoice, when a tax declaration request submitted by the user through the client is received, the invoice declaration status of the invoice corresponding to the tax declaration request can be determined first; if it is in the declared status, you can directly report to the client Return the notification message that has been declared, otherwise enter the above-mentioned tax declaration process.
In one embodiment, the aforementioned blockchain may be a consortium chain, and the member nodes of the consortium chain may include payment platforms and tax authorities. Among them, the tax authority can act as a supervisor to view information such as transactions and invoices deposited on the blockchain.
Fig. 2 is a schematic diagram of the overall structure of an invoice creation solution provided by an exemplary embodiment. As shown in FIG. 2, after completing a transaction between transaction participants, the client 21 can send a record request to the server 22 so that the server 22 publishes the transaction information of the transaction to the blockchain. Further, when a transaction participant needs to issue an invoice, the client 21 can send an invoice creation request to the server 22, and the server 22 receives the invoice creation request (including the transaction identifier and the invoice creation information entered by the user). Then, determine whether there is a target transaction corresponding to the transaction identifier on the blockchain, and call the invoice creation logic declared in the smart contract to create an invoice for the target transaction when the target transaction is certified on the blockchain, and Publish the created invoice to the blockchain.
For ease of understanding, the following is a detailed description of the invoice creation scheme of this specification for the operations and functions implemented by the client 21 and the server 22 during the invoice creation process, respectively, in conjunction with Figures 3-5. Fig. 3 is an interactive schematic diagram of transaction on-chain provided by an exemplary embodiment. As shown in Figure 3, the interactive process may include the following steps:
In step 302, a binding relationship is established between the client 21 and the server 22.
In one embodiment, the binding relationship that needs to be established is the binding relationship between the identity information of the transaction participant and the device information of the client 21. Based on the binding relationship, when the server 22 receives the transaction record request, invoice creation request, and tax declaration request subsequently sent by the client 21, it can confirm that these requests correspond to the transaction participant.
For example, a transaction participant may register an account at the server 22 in advance to obtain a registered account uniquely corresponding to itself. Then, the transaction participant can log in the registered account on the client 21, and the server 22 determines the registered account (corresponding to the transaction participant) and the customer based on the login information of the registered account on the client 21 A binding relationship is established between the terminals 21.
In step 304, the client 21 signs the transaction to be recorded and key information.
In one embodiment, after completing the transaction, the transaction participants can submit a transaction record request to the server 22 through the client 21, so that the server 22 publishes the transaction information to be recorded and the key information of the transaction to the district. Block chain. Among them, transaction participants can register in advance to obtain a unique corresponding digital identity, which is characterized by a set of public and private key pairs. Correspondingly, after the client 21 obtains the transaction information input by the transaction participant and the key information of the transaction, it can generate a transaction record request (including transaction information and key information) and use the private key corresponding to the digital identity of the transaction participant Sign the transaction record request.
In step 306, the client 21 submits a transaction record request to the server 22.
In step 308, the server 22 verifies the signature.
In one embodiment, a blockchain client runs on the server 22, so that the server 22 is configured as a blockchain node. After the server 22 receives the transaction record request, it can determine the identity of the transaction participant based on the binding relationship established in step 302, so as to verify the signature through the public key corresponding to the transaction participant to confirm that the transaction record request has been Authorized by the transaction participant, not by the criminals pretending to be the identity of the transaction participant to send.
In one embodiment, when the verification fails, because the client is bound to the transaction participant through the registered account in advance, indicating that there may be criminals impersonating the identity of the transaction participant, an alarm operation can be triggered and the client may be temporarily blocked Access to blockchain nodes.
In step 310, the server 22 publishes the transaction information and key information to the blockchain in association with each other.
For example, transaction information may include transaction identification, transaction platform, transaction amount, transaction content, transaction participants, transaction time, etc.; key information may include order records, logistics records, payment records, identity information of transaction participants, etc. Among them, the order information can be the detailed content of the contract signed between the transaction participants and the object of the transaction (for example, commodities, technical support, etc.); the logistics record can be the logistics information of the transaction object; the payment record can be of the transaction participants Payment and collection details, account opening bank name, account opening bank account number, etc.; the identity information of transaction participants can be company name, taxpayer identification number, registered address, etc. Of course, this manual does not limit the specific content of transaction information and key information.
Please refer to FIG. 4, which is a flowchart of a blockchain-based invoice creation method provided by an exemplary embodiment. As shown in Fig. 4, this method is applied to a blockchain node (take the server 22 as an example) and may include the following steps:
Step 402: Receive an invoice creation request submitted by the user through the client 21.
In one embodiment, the invoice creation request includes a transaction identification and invoice creation information input by the user through the client.
In step 404, if the target transaction is certified on the blockchain, proceed to step 406B; otherwise, proceed to step 406A.
In step 406A, a prompt message indicating that the transaction does not exist is returned to the client 21.
In one embodiment, it can be determined according to the transaction identifier whether there is a target transaction corresponding to the transaction identifier on the blockchain. When the target transaction is not documented on the blockchain, it means that the transaction corresponding to the invoice created by the client 21 at this time (ie, the target transaction) is not an objective transaction, so the prompt message can be returned to remind the user that the transaction does not exist.
In step 406B, if the target transaction deposited on the blockchain is marked as an invoice created state, then proceed to step 408A; otherwise, proceed to step 408B.
In step 408A, a prompt message indicating that the invoice has been issued is returned to the client 21.
In step 408B, if the key information of the target transaction is associated and stored on the blockchain, proceed to step 410B; otherwise, proceed to step 410A.
In step 410A, a prompt message indicating that the transaction is invalid is returned to the client 21.
Continuing in step 408B, when the key information of the target transaction is not associated on the blockchain, it means that the transaction corresponding to the invoice created by the client 21 at this time (ie the target transaction) is not a valid transaction (that is, the target transaction is not a real occurrence) In other words, the target transaction has false information), so the prompt message can be returned to remind the user that the transaction is invalid.
Following step 410B, when the key information associated with the deposit certificate on the blockchain is incomplete, it means that the transaction corresponding to the invoice created by the client 21 at this time (ie the target transaction) is not a valid transaction (that is, the target transaction is not a real transaction) In other words, the target transaction has at least a part of false information), so the prompt message can be returned to remind the user that the transaction is invalid. For example, key information includes order records, logistics records, payment records, and identity information of transaction participants. It is assumed that when only the order records, payment records, and transaction participants’ identity information of the target transaction are associated on the blockchain, and If the deposit payment record is not associated, it can be determined that the target transaction is invalid.
In step 410B, if the key information is complete, go to step 412; otherwise, go to step 410A.
In one embodiment, the above-mentioned operation of determining whether the target transaction is a valid transaction (steps 406B-410B) can be executed by the server 22 itself, or by a smart contract (declared with verification logic) pre-deployed on the blockchain. Used to determine whether any transaction is a valid transaction) to be executed, this manual does not limit this. It can be seen that the above process of determining whether the target transaction is a valid transaction can effectively prevent users from falsely issuing invoices.
Step 412: Call the invoice creation logic declared in the smart contract, and create an invoice for the target transaction based on the invoice creation information.
In one embodiment, the smart contract can be pre-deployed on the blockchain by payment institutions and tax authorities.
In one case, the invoice creation information entered by the user may include the header information of the invoice and the transaction information of the target transaction. After receiving the invoice creation request, the server 22 deposits the transaction information contained in the invoice creation information with the blockchain. Compare the transaction information (corresponding to the transaction identifier) for the target transaction. When the comparison result is the same, create an invoice for the target transaction directly based on the transaction information and header information contained in the invoice creation information. For example, after the server 22 receives the invoice creation request, it reads the transaction information contained in the invoice creation information and calculates the first hash value, and combines the first hash value with the transaction information certified on the blockchain ( The second hash value corresponding to the transaction identifier) is compared. When the first hash value is equal to the second hash value, it can be determined that the transaction information entered by the user is the transaction information of the target transaction. The entered transaction information and header information create an invoice for the target transaction without reading the transaction information of the target transaction deposited on the blockchain, thereby improving the efficiency of creating invoices.
In another case, the invoice creation information entered by the user may only include the header information of the invoice. After the server 22 receives the invoice creation request and determines that the target transaction is recorded on the blockchain, it further reads the information stored on the blockchain. According to the transaction information of the target transaction of the certificate, an invoice is created for the target transaction based on the read transaction information and the header information of the invoice.
Step 414: Publish the created invoice to the blockchain.
In step 416, the target transaction is marked as an invoice created state.
In one embodiment, the target transaction can be marked as the created invoice status after the invoice is created, or the target transaction can be marked as the created invoice status after the created invoice is published to the blockchain. This manual is not correct This is limited.
In one embodiment, a field can be added to the field for depositing the target transaction to mark the status of the invoice creation, or the invoice creation status of the target transaction can be additionally associated on the blockchain, which is not described in this specification. limit. By recording the invoice creation status of the transaction, when receiving the invoice creation request submitted by the user through the client, the invoice creation status of the transaction corresponding to the invoice creation request can be determined first; if it is the created invoice status, you can directly report to the customer The terminal returns the prompt message that the invoice has been issued, otherwise it enters the process of creating the invoice above.
Please refer to FIG. 5, which is a flowchart of a blockchain-based invoice declaration method provided by an exemplary embodiment. As shown in Fig. 5, this method is applied to a blockchain node (take the server 22 as an example) and may include the following steps:
Step 502: Receive a tax declaration request submitted by the user through the client 21.
In an embodiment, the tax declaration request includes a transaction identifier.
In step 504, if the invoice corresponding to the invoice identifier deposited on the blockchain is marked as declared state, proceed to step 510; otherwise, proceed to step 506.
In step 506, the invoice declaration logic declared in the smart contract is called, and the tax declaration is completed based on the invoice corresponding to the invoice identifier deposited on the blockchain.
In one embodiment, the smart contract can be pre-deployed on the blockchain by payment institutions and tax authorities.
Step 508: Mark the invoice corresponding to the invoice identifier as declared.
In one embodiment, a field can be added to the field for depositing the invoice to mark the invoice declaration status, or the invoice declaration status of the invoice can be additionally associated on the blockchain. This specification does not limit this . By recording the invoice declaration status of the invoice, when a tax declaration request submitted by the user through the client is received, the invoice declaration status of the invoice corresponding to the tax declaration request can be determined first; if it is in the declared status, you can directly report to the client Return the notification message that has been declared, otherwise enter the above-mentioned tax declaration process.
In step 510, a prompt message indicating that the invoice has been declared is returned to the client 21.
It should be noted that there are narrow transactions and broad transactions in transactions in the blockchain. A narrowly defined transaction refers to a transfer of value issued by a user to the blockchain; for example, in a traditional Bitcoin blockchain network, a transaction can be a transfer initiated by the user in the blockchain. In a broad sense, a transaction refers to a piece of business data with business intentions released by a user to the blockchain; for example, an operator can build a consortium chain based on actual business needs, and rely on the consortium chain to deploy some other types that are not related to value transfer. Online business (for example, renting business, vehicle dispatching business, insurance claims business, credit service, medical service, etc.), and in this kind of alliance chain, the transaction can be a business message with business intentions or Business request.
Fig. 6 is a schematic structural diagram of a device provided by an exemplary embodiment. Please refer to Figure 6, at the hardware level, the device includes a processor 602, an internal bus 604, a network interface 606, a memory 608, and a non-volatile memory 610. Of course, it may also include hardware required for other services. . The processor 602 reads the corresponding computer program from the non-volatile memory 610 to the memory 608 and then runs it to form a blockchain-based invoice creation device on a logical level. Of course, in addition to software implementation, one or more embodiments of this specification do not exclude other implementations, such as logic devices or a combination of software and hardware, etc., which means that the execution body of the following processing flow is not limited to Each logical unit can also be a hardware or a logical device.
Please refer to Figure 7. In the software implementation, the blockchain-based invoice creation device may include:
The first receiving unit 71 receives an invoice creation request submitted by a user through the client; wherein the invoice creation request includes a transaction identifier and invoice creation information input by the user;
The determining unit 72, in response to the invoice creation request, determines whether the target transaction corresponding to the transaction identifier is deposited on the blockchain; and at least one key information used to indicate that the target transaction is a valid transaction ；
The creation unit 73, if it is determined that the target transaction and the key information are deposited on the blockchain, call the invoice creation logic declared in the smart contract, create an invoice for the target transaction based on the invoice creation information, and Publish the created invoice to the blockchain.
Optionally, the creating unit 73 is specifically configured to:
If it is determined that the target transaction and the at least one key information are deposited on the blockchain, it is further determined whether various key information in the at least one key information is complete;
If it is, call the invoice creation logic declared in the smart contract.
Optionally, the at least one type of key information includes at least one of the following: order records, logistics records, and payment records corresponding to the target transaction; and identity information of the participant corresponding to the target transaction.
Optional, also includes:
The second receiving unit 74 receives a tax declaration request submitted by a user through the client; wherein, the tax declaration request includes an invoice identifier;
The declaration unit 75, in response to the tax declaration request, invokes the invoice declaration logic declared in the smart contract, and completes the tax declaration based on the invoice corresponding to the invoice identifier stored on the blockchain.
Optional, also includes:
The marking unit 76 marks the invoice corresponding to the invoice identifier as declared state after completing the tax declaration.
Optionally, the blockchain is a consortium chain; member nodes of the consortium chain include: payment platforms and tax authorities.
The systems, devices, modules, or units explained in the above embodiments may be implemented by computer chips or entities, or implemented by products with certain functions. A typical implementation device is a computer. The specific form of the computer can be a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email receiving and sending device, and a game control Desktop, tablet, wearable device, or any combination of these devices.
In a typical configuration, the computer includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
Memory may include non-permanent memory, random access memory (RAM) and/or non-volatile memory in computer-readable media, such as read-only memory (ROM) or flash memory ( flash RAM). Memory is an example of computer-readable media.
Computer-readable media includes permanent and non-permanent, removable and non-removable media, and information storage can be realized by any method or technology. The information can be computer readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), and other types of random access memory (RAM) , Read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital multi-function disc (DVD) or other optical storage, magnetic cassette tape, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by computing devices . According to the definition in this article, computer-readable media does not include temporary computer-readable media (transitory media), such as modulated data signals and carrier waves.
It should also be noted that the terms "include", "include" or any other variant thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device that includes a series of elements not only includes those elements, but also includes Other elements not explicitly listed, or include elements inherent to this process, method, commodity, or equipment. Without more restrictions, the element defined by the sentence "include one..." does not exclude that there are other identical elements in the process, method, commodity, or equipment that includes the element.
The foregoing describes specific embodiments of the present specification. Other embodiments are within the scope of the attached patent application. In some cases, the actions or steps described in the scope of the patent application may be performed in a different order than in the embodiment and still achieve the desired result. In addition, the processes depicted in the drawings do not necessarily require the particular order shown or sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.
The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only, and is not intended to limit one or more embodiments of this specification. The singular forms "a", "said" and "the" used in the scope of one or more embodiments of the present specification and the appended patent applications are also intended to include most forms unless the context clearly indicates other meanings. It should also be understood that the term "and/or" as used herein refers to and encompasses any or all possible combinations of one or more associated listed items.
It should be understood that although one or more embodiments in this specification may use the terms first, second, third, etc. to describe various information, the information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of one or more embodiments of this specification, the first information may also be referred to as second information, and similarly, the second information may also be referred to as first information. Depending on the context, the word "if" as used herein can be interpreted as "when" or "when" or "in response to determination".
The above are only preferred embodiments of one or more embodiments of this specification, and are not intended to limit one or more embodiments of this specification. Anything within the spirit and principle of one or more embodiments of this specification, Any modifications, equivalent replacements, improvements, etc. made should be included within the scope of protection of one or more embodiments of this specification.
