這裡將詳細地對示例性實施例進行說明，其示例表示在圖式中。下面的描述涉及圖式時，除非另有表示，不同圖式中的相同數字表示相同或相似的元件。以下示例性實施例中所描述的實施方式並不代表與本說明書一個或多個實施例相一致的所有實施方式。相反，它們僅是與如所附申請專利範圍中所詳述的、本說明書一個或多個實施例的一些方面相一致的裝置和方法的例子。
需要說明的是：在其他實施例中並不一定按照本說明書示出和描述的順序來執行相應方法的步驟。在一些其他實施例中，其方法所包括的步驟可以比本說明書所描述的更多或更少。此外，本說明書中所描述的單個步驟，在其他實施例中可能被分解為多個步驟進行描述；而本說明書中所描述的多個步驟，在其他實施例中也可能被合並為單個步驟進行描述。
圖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 herein, examples of which are illustrated in the drawings. When the following description refers to the drawings, the same numerals in different drawings refer to the same or similar elements unless otherwise indicated. The implementations described in the exemplary embodiments below are not intended to represent all implementations consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatus and methods consistent with some aspects of one or more embodiments of the present specification as detailed in the appended claims. It should be noted that: in other embodiments, the steps of the corresponding methods 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. describe. FIG. 1 is a flowchart of a blockchain-based invoice creation method provided by an exemplary embodiment. As shown in FIG. 1, the method is applied to a blockchain node, and may include the following steps: Step 102, receiving an invoice creation request submitted by a user through a client; wherein the invoice creation request includes a transaction identifier and an invoice creation input entered by the user News. In one embodiment, the client terminal may be any type of electronic device such as a mobile phone, a tablet computer, a smart watch, etc. used by the transaction participant, which is not limited in this specification. Transaction participants can interact with blockchain nodes connected to the electronic device by logging in to the registered account on the electronic device. In one embodiment, after completing a transaction, the transaction participant can send a record request to the blockchain node through the client, so that the blockchain node publishes the transaction information of the transaction to the blockchain. For example, the transaction information may include transaction identification, transaction platform, transaction amount, transaction content, transaction participants, transaction time, and the like. Of course, this manual does not limit the specific content of the 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 fully The immutability of data stored in the blockchain is used to prevent criminals from maliciously modifying transaction information, ensuring the security and transparency of recorded transaction information, and facilitating user traceability. Step 104, in response to the invoice creation request, determine whether a target transaction corresponding to the transaction identifier is stored on the blockchain; and at least one key information used to indicate that the target transaction is a valid transaction. In one embodiment, whether there is a corresponding target transaction stored on the blockchain can be searched 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 stored 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 it is determined that the target transaction is an objective transaction, it is further determined whether the target transaction is a valid transaction (it can be understood that the target transaction is a transaction that has actually occurred), which can effectively prevent users from falsely invoicing. When determining whether the target transaction is a valid transaction, at least one key information of the target transaction recorded on the blockchain can be used. After a transaction participant completes a transaction, in addition to the transaction information, at least one key information used to indicate that the transaction is a valid transaction can also be sent to the blockchain node, so that the blockchain node can publish the key information. to the blockchain. Further, the blockchain node can publish the transaction information and key information of the transaction on the blockchain in an associated relationship. Based on the above-mentioned deposit of the key information of the transaction, in one case, it can be determined whether at least one key information for indicating that the target transaction is a valid transaction is stored on the blockchain, and if so, it can be determined that the target transaction is a valid transaction . In another case, it may be first determined whether at least one key information for indicating that the target transaction is a valid transaction is stored on the blockchain. Whether various key information in at least one key information is complete, 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 is invoked. The at least one 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 the 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 performed by the blockchain node itself, or by a smart contract pre-deployed on the blockchain (declaring that there is a verification logic to determine whether any transaction is valid or not). This manual does not limit it. Step 106, if it is determined that the target transaction and the key information are stored on the blockchain, the invoice creation logic declared in the smart contract is invoked, an invoice is created for the target transaction according to the invoice creation information, and an invoice is created for the target transaction. 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 of the transaction corresponding to the transaction identifier (input by the user), and the blockchain node converts the transaction information contained in the invoice creation information after receiving the invoice creation request. Compare with the transaction information (corresponding to the transaction ID) stored in the blockchain, and when the comparison result is consistent, 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 the first hash value is combined with the transaction information stored in 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 input by the user is the transaction information of the target transaction, then it can be directly The transaction information and header information entered by the user creates an invoice for the target transaction without reading the transaction information of the target transaction on the blockchain. In another case, the invoice creation information may only include the header information of the invoice. After receiving the invoice creation request and determining that the target transaction is stored on the blockchain, the blockchain node further reads the data stored in the blockchain. The transaction information of the target transaction, and then create an invoice for the target transaction based on the read transaction information and the header information of the invoice. In one embodiment, after an invoice is created for the target transaction, the target transaction may be further marked with an invoice created status. Among them, a field can be added to the field of the target transaction for deposit to mark the status of the invoice creation, and the invoice creation status of the target transaction of the deposit certificate can be additionally associated on the blockchain, which is not limited in this specification. By recording the invoice creation status of the transaction, when an invoice creation request submitted by the user through the client is received, the invoice creation status of the transaction corresponding to the invoice creation request can be determined first; The terminal returns a prompt message that the invoice has been issued, otherwise it enters the above process of creating an invoice. In one embodiment, based on publishing the created invoice to the blockchain in association with the target transaction, a smart contract may be deployed for tax declaration of the invoice, so as to realize the blockchain-based tax declaration of the invoice. Therefore, the blockchain node can receive the tax declaration request submitted by the user through the client (the tax declaration request includes the invoice identifier), and in response to the tax declaration request, call the invoice declaration logic declared in the smart contract, based on the storage on the blockchain. Complete the tax declaration with the invoice corresponding to the invoice ID of the certificate. Similarly, after completing the tax declaration, the invoice corresponding to the invoice ID can be marked as declared. Among them, a field can be added to the field of the invoice on deposit to mark the declaration status of the invoice, and the invoice declaration status of the transaction can be additionally associated on the blockchain, which is not limited in this manual. 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 declared, it can be directly reported to the client Return to the prompt message that has been declared, otherwise enter the above tax declaration process. In one embodiment, the above-mentioned 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 the transactions, invoices and other information stored on the blockchain. FIG. 2 is a schematic diagram of the overall architecture of an invoice creation solution provided by an exemplary embodiment. As shown in FIG. 2 , after completing a transaction, the transaction participants can send a record request to the server 22 through the client 21 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 ID and the invoice creation information input 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 if there is a target transaction on the blockchain. Post the created invoice to the blockchain. For ease of understanding, the following describes the invoice creation scheme of the present specification in detail with reference to FIGS. FIG. 3 is an interactive schematic diagram of a transaction on the chain provided by an exemplary embodiment. As shown in FIG. 3 , the interaction process may include the following steps: Step 302 , establishing a binding relationship between the client 21 and the server 22 . In one embodiment, the binding relationship 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, the invoice creation request and the tax declaration request sent by the client 21 subsequently, 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 client based on the login information of the registered account on the client 21. A binding relationship is established between the terminals 21 . Step 304, the client 21 signs the transaction and key information to be recorded. In one embodiment, after completing the transaction, the transaction participants can submit a transaction record request to the server 22 through the client terminal 21, so that the server 22 publishes the transaction information to be recorded and the key information of the transaction to the district. in the blockchain. Among them, transaction participants can pre-register to obtain a unique digital identity, which is represented by a set of public and private key pairs. Correspondingly, after acquiring the transaction information entered by the transaction participant and the key information of the transaction, the client terminal 21 can generate a transaction record request (including transaction information and key information) and pass the private key corresponding to the digital identity of the transaction participant. Sign the transaction log request. 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, the server 22 runs a blockchain client, so that the server 22 is configured as a blockchain node. After receiving the transaction record request, the server 22 can determine the identity of the transaction participant based on the binding relationship established in the above step 302, so as to verify the signature through the public key corresponding to the transaction participant to determine that the transaction record request has been completed. Authorized by the transaction participant, not sent by criminals pretending to be the transaction participant. In one embodiment, when the signature verification fails, since the client is bound with the transaction participant through the registered account in advance, indicating that there may be criminals posing as the transaction participant, an alarm operation can be triggered and the client can be temporarily blocked. Permission to access blockchain nodes. Step 310, the server 22 publishes the transaction information and the key information to the blockchain in association. 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, and identity information of transaction participants. Wherein, the order information can be the contract signed between the transaction participants and the details of the transaction object (for example, commodities, technical support, etc.); the logistics record can be the logistics information of the transaction object; the payment record can be the transaction participant's logistics information. The details of the payment and receipt, the name of the opening bank, the account number of the opening bank, etc.; the identity information of the transaction participants can be the 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 , the method is applied to a blockchain node (taking the server 22 as an example), and may include the following steps: Step 402 , receiving an invoice creation request submitted by a user through the client 21 . In one embodiment, the invoice creation request includes a transaction identifier and invoice creation information entered by the user through the client. Step 404, if there is a target transaction on the blockchain, go to step 406B; otherwise, go to step 406A. Step 406A, returning to the client 21 a prompt message that the transaction does not exist. In one embodiment, whether there is a target transaction corresponding to the transaction identifier stored on the blockchain can be determined according to the transaction identifier. When the target transaction is not recorded on the blockchain, it means that the transaction corresponding to the invoice requested by the client 21 (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. Step 406B, if the target transaction on the blockchain is marked as having created an invoice, go to step 408A; otherwise, go to step 408B. Step 408A, returning to the client 21 a prompt message that the invoice has been issued. Step 408B, if the key information of the target transaction is associated and stored on the blockchain, go to step 410B; otherwise, go to step 410A. Step 410A, returning to the client 21 a prompt message that the transaction is invalid. Following step 408B, when the key information of the target transaction for deposit is not associated with the blockchain, it means that the transaction corresponding to the invoice requested by the client 21 at this time (that is, 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 certificate on the blockchain is incomplete, it means that the transaction corresponding to the invoice requested 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 the identity information of transaction participants. It is assumed that when only the order records, payment records and transaction participants' identity information are associated with the target transaction on the blockchain, and If the deposit payment record is not associated, the target transaction can be determined to be an invalid transaction. Step 410B, if the key information is complete, go to step 412; otherwise, go to step 410A. In one embodiment, the above-mentioned operations of determining whether the target transaction is a valid transaction (steps 406B-410B) can be performed by the server 22 itself, or by a smart contract pre-deployed on the blockchain (declaring that there is a verification logic, It is used to determine whether any transaction is a valid transaction), which is not limited in this manual. It can be seen that through the above process of determining whether the target transaction is a valid transaction, the user can effectively prevent false invoicing. In step 412, the invoice creation logic declared in the smart contract is invoked, and an invoice is created for the target transaction according to 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 input 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 stores the transaction information contained in the invoice creation information with the certificate on the blockchain The transaction information (corresponding to the transaction ID) is compared, and when the comparison result is the same, an invoice is created 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 server 22 reads the transaction information contained in the invoice creation information and calculates the first hash value, and the first hash value is combined with the transaction information ( Compare with the second hash value corresponding to the transaction identifier), when the first hash value is equal to the second hash value, it can be determined that the transaction information input by the user is the transaction information of the target transaction, then it can be directly The entered transaction information and header information create an invoice for the target transaction without reading the transaction information of the target transaction stored on the blockchain, thereby improving the efficiency of creating invoices. In another case, the invoice creation information input by the user may only include the header information of the invoice. After receiving the invoice creation request and confirming that the target transaction is stored on the blockchain, the server 22 further reads the data stored on the blockchain. The transaction information of the target transaction of the certificate, and then create an invoice for the target transaction according to 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 having an invoice created status. In one embodiment, the target transaction may be marked as the invoice-created state after the invoice is created, or the target transaction may be marked as the invoice-created state after the created invoice is published to the blockchain. This is restricted. In one embodiment, a field may be added to the field of the target transaction for deposit to mark the status of the invoice creation, and the invoice creation status of the target transaction may be additionally associated on the blockchain, which is not described in this specification. limit. By recording the invoice creation status of the transaction, when an invoice creation request submitted by the user through the client is received, the invoice creation status of the transaction corresponding to the invoice creation request can be determined first; The terminal returns a prompt message that the invoice has been issued, otherwise it enters the above process of creating an invoice. Please refer to FIG. 5 , which is a flowchart of a blockchain-based invoice reporting method provided by an exemplary embodiment. As shown in FIG. 5 , the method is applied to a blockchain node (taking 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 one embodiment, the tax filing request includes a transaction identification. Step 504 , if the invoice corresponding to the invoice identifier stored in the blockchain is marked as declared, then go to step 510 ; otherwise, go to step 506 . In step 506, the invoice declaration logic declared in the smart contract is invoked, and the tax declaration is completed based on the invoice corresponding to the invoice identifier stored in the blockchain. In one embodiment, the smart contract can be pre-deployed on the blockchain by payment institutions and tax authorities. Step 508, marking the invoice corresponding to the invoice identifier as a declared state. In one embodiment, a field may be added to the field for storing the invoice to mark the declaration status of the invoice, and the invoice declaration status of the invoice may be additionally associated on the blockchain, which is not limited in this specification. . 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 declared, it can be directly reported to the client Return to the prompt message that has been declared, otherwise enter the above tax declaration process. Step 510, returning to the client 21 a prompt message that the invoice has been declared. It should be noted that transactions in the blockchain can be divided into narrow transactions and broad transactions. A transaction in a narrow sense refers to a transfer of value issued by a user to the blockchain; for example, in the traditional Bitcoin blockchain network, a transaction can be a transfer initiated by a user in the blockchain. In a broad sense, a transaction refers to a piece of business data with business intent 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 other types of transactions that have nothing to do with value transfer. Online business (for example, rental business, vehicle scheduling business, insurance claim business, credit service, medical service, etc.), and in this kind of alliance chain, the transaction can be a business message with business intent published by the user in the alliance chain or business request. Fig. 6 is a schematic structural diagram of a device provided by an exemplary embodiment. Please refer to FIG. 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 , and of course may also include hardware required for other services . The processor 602 reads the corresponding computer program from the non-volatile memory 610 into the memory 608 and then executes it, forming a blockchain-based invoice creation device on a logical level. Of course, in addition to the software implementation, one or more embodiments of this specification do not exclude other implementations, such as a logic device or a combination of software and hardware, etc., that is to say, the execution subject of the following processing procedures is not limited to Each logic unit can also be a hardware or a logic device. Referring to FIG. 7, in a software implementation, the blockchain-based invoice creation device may include: a first receiving unit 71, receiving an invoice creation request submitted by a user through a client; wherein the invoice creation request includes a transaction identifier and the invoice creation information input by the user; the determination unit 72, in response to the invoice creation request, determines whether the target transaction corresponding to the transaction identifier is stored on the blockchain; and, for indicating the target transaction is at least one key information of a valid transaction; the creation unit 73, if it is determined that the target transaction and the key information are stored on the blockchain, the invoice creation logic declared in the smart contract is invoked, and the information is created according to the invoice An invoice is created for the target transaction, and the created invoice is posted 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 stored on the blockchain, further determine whether various key information in the at least one key information is Complete; if so, invokes the invoice creation logic declared in the smart contract. Optionally, the at least one 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 a participant corresponding to the target transaction. Optionally, it further includes: a second receiving unit 74, for receiving a tax declaration request submitted by a user through a client; wherein, the tax declaration request includes an invoice identifier; a declaration unit 75, in response to the tax declaration request, invoking a smart contract The invoice declaration logic declared in , completes the tax declaration based on the invoice corresponding to the invoice identifier stored on the blockchain. Optionally, it further includes: a marking unit 76, after completing the tax declaration, marking the invoice corresponding to the invoice identifier as a declared state. Optionally, the blockchain is a consortium chain; the member nodes of the consortium chain include: a payment platform and a tax authority. The systems, devices, modules or units described in the above embodiments may be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, which can be in the form of 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 sending and receiving device, a game control Tablets, Tablets, Wearables, or a combination of any of these devices. In a typical configuration, a computer includes one or more processors (CPUs), an input/output interface, a network interface, and memory. Memory may include forms of non-persistent 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 a computer-readable medium. Computer-readable media includes both permanent and non-permanent, removable and non-removable media, and can be implemented by any method or technology for storage of information. 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), other types of random access memory (RAM) , Read-Only Memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Flash Memory or Other Memory Technologies, Compact Disc Read-Only Memory (CD-ROM), Digital Versatile Disc (DVD) or other optical storage, magnetic cassette tape, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage device or any other non-transmission media that can be used to store information that can be accessed by a computing device . As defined herein, computer-readable media does not include transitory computer-readable media, such as modulated data signals and carrier waves. It should also be noted that the terms "comprising", "comprising" or any other variation thereof are intended to encompass a non-exclusive inclusion such that a process, method, article or device comprising a series of elements includes not only those elements, but also Other elements not expressly listed, or inherent to such a process, method, article of manufacture or apparatus are also included. Without further limitation, an element qualified by the phrase "comprising a..." does not preclude the presence of additional identical elements in the process, method, article of manufacture, or device that includes the element. The foregoing describes specific embodiments of the present specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in a different order than in the embodiments and still achieve desirable results. Additionally, the processes depicted in the figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some 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 a particular embodiment only and is not intended to limit the one or more embodiments of this specification. As used in this specification and in one or more embodiments and the appended claims, the singular forms "a," "the," and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. It will also be understood that the term "and/or" as used herein refers to and includes any and all possible combinations of one or more of the associated listed items. It should be understood that although the terms first, second, third, etc. may be used in this specification to describe various information, such information should not be limited by these terms. These terms are only used to distinguish information of the same type from one another. For example, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information without departing from the scope of one or more embodiments of the present specification. Depending on the context, the word "if" as used herein can be interpreted as "at the time of" or "when" or "in response to determining." The above descriptions 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. All within the spirit and principles of one or more embodiments of this specification, Any modifications, equivalent replacements, improvements, etc. made should be included within the protection scope of one or more embodiments of this specification.
