這裡將詳細地對示例性實施例進行說明，其示例表示在圖式中。下面的描述涉及圖式時，除非另有表示，不同圖式中的相同數字表示相同或相似的要素。以下示例性實施例中所描述的實施方式並不代表與本說明書一個或多個實施例相一致的所有實施方式。相反，它們僅是與如所附申請專利範圍中所詳述的、本說明書一個或多個實施例的一些方面相一致的裝置和方法的例子。
需要說明的是：在其他實施例中並不一定按照本說明書示出和描述的順序來執行相應方法的步驟。在一些其他實施例中，其方法所包括的步驟可以比本說明書所描述的更多或更少。此外，本說明書中所描述的單個步驟，在其他實施例中可能被分解為多個步驟進行描述；而本說明書中所描述的多個步驟，在其他實施例中也可能被合併為單個步驟進行描述。
圖1是一示例性實施例提供的一種基於區塊鏈的事件處理方法的流程圖。如圖1所示，該方法應用於參與方，可以包括以下步驟：
步驟102，根據所述參與方所參與的事件，向所述參與方維護的等待佇列中添加對應的備選子交易。
在一實施例中，事件存在多個參與方，每一參與方對應於參與物件，該參與物件可以為個人、企業、組織等，本說明書並不對此進行限制。參與物件存在對應的數位身份，使得承載該數位身份的電子設備相當於被配置為該參與物件所對應的參與方。
在一實施例中，本說明書的事件可以包括任意類型、覆蓋任意場景，比如投票、簽訂協定、流量分配、轉帳、跨境匯款等，本說明書並不對此進行限制。以投票為例，描述資訊可以包括投票事由和投票選項等資訊，而各個參與方向區塊鏈中提交的觸發資訊可以包括對投票選項的選擇結果，從而觸發完成投票操作。
在一實施例中，備選子交易中包含事件的描述資訊，該描述資訊用於描述相關事件的情況，使得該備選子交易被處理時，可以根據該描述資訊實施相應的事件。例如，描述資訊可以表徵相關事件的執行邏輯、所涉及的參與方、對參與方的狀態參數的改變方式(如增大或減小狀態參數的取值)、變化量等，本說明書並不對此進行限制。實際上，事件的相關內容可由各個參與方之間預先通過任意方式進行溝通，然後由所述任一參與方進行起草該事件的描述資訊，使得事件的其他參與方可以根據預先的溝通結果對該描述資訊的內容進行查看和確認；當然，所述任一參與方也可以在並未預先溝通的情況下，自行判定事件的其他參與方以及描述資訊中的其他內容，本說明書並不對此進行限制。
在一實施例中，事件的描述資訊可由該事件的任一參與方產生，並添加為該任一參與方維護的等待佇列中的備選子交易。以及，該任一參與方還將產生的描述資訊分享至其他參與方，使得其他參與方對描述資訊進行確認。
在一實施例中，任一參與方可以將描述資訊通過鏈外通道發送至事件的其他參與方。通過鏈外通道將描述資訊發送至事件的其他參與方，可以實現對描述資訊的高效傳輸。其中，鏈外通道可以為事件的各個參與方之間建立的加密通道或其他形式的秘密頻道，以避免發生資訊洩露。
在一實施例中，任一參與方可以通過向區塊鏈提交一筆交易，並將上述的描述資訊包含於該交易中，使得該交易在經過共識後可以被發送至區塊鏈中的所有區塊鏈節點；而事件的每一參與方均可以被配置為區塊鏈中的區塊鏈節點，或者每一參與方可以在區塊鏈中存在對應的區塊鏈節點，使得每一參與方可以通過自身或對應的區塊鏈節點所維護的區塊鏈帳本(區塊鏈帳本包含區塊鏈的全量交易資料)，獲得上述交易及其包含的描述資訊，從而使得上述的描述資訊被同步至事件的其他參與方。
步驟104，根據從所述等待佇列中選取的若干備選子交易，產生相應的集合交易。
在一實施例中，集合交易中可以包含多個備選子交易，每一備選子交易分別對應於上述參與方所參與的一個事件，使得該集合交易被提交至區塊鏈後，所包含的多個備選子交易均可以在區塊鏈中被處理，從而使得這些備選子交易對應的多個事件被實施。可見，通過在集合交易中包含多個備選子交易，使得這些備選子交易被批量提交至區塊鏈，可以減少向區塊鏈提交的交易數量，無需針對每一備選子交易均產生一筆區塊鏈交易，有助於降低資源消耗、提升處理效率。
在一實施例中，可以在所述等待佇列中的備選子交易達到預設數量時，選取所述等待佇列中已存在的備選子交易(即預設數量的備選子交易)，以產生相應的集合交易。在另一實施例中，可以按照預設時長週期性地選取所述等待佇列中已存在的備選子交易，以產生相應的集合交易；當然，每一集合交易的容量可以存在最大限制，使得同一週期內選取的備選子交易的數量存在相應的最大值，超出的部分可以延期至下一週期進行選取。當然，還可以通過其他的預設規則來選取備選子交易，本說明書並不對此進行限制。
在一實施例中，等待佇列中的備選子交易可以按照添加時刻進行依次排列，而每次可以從前向後依次選取各個備選子交易，使得在先產生的備選子交易可以被優先選取。當然，參與方也可以根據實際需求，比如事件的緊急程度、事件的優先順序等，對等待佇列中的備選子交易實施與順序無關的選取操作；或者，等待佇列本身就可以按照上述的緊急程度、優先順序等進行排列，這樣依然可以視為依次選取。
在一實施例中，參與方可以按照產生順序為各個合併交易添加編號，使各個合併交易在區塊鏈中被按照對應編號的大小進行依次處理。換言之，區塊鏈交易在收到參與方提交的合併交易後，需要讀取合併交易所包含的編號；如果編號與先前處理的合併交易的編號連續，比如最新處理的合併交易的編號為99、當前收到的合併交易的編號為100，則可以對該編號為100的合併交易進行處理；如果編號之間並不連續，比如最新處理的合併交易的編號為99、當前收到的合併交易的編號為101，則區塊鏈節點需要等待並優先處理編號為100的合併交易，然後才能處理編號為101的合併交易。由於每條交易被執行後都可能導致該參與方的狀態參數發生變化，而在後交易的執行需要依賴於先前交易執行後的狀態參數的取值，因而需要確保各個合併交易被按照對應編號的大小進行依次處理，以使得各個合併交易均能夠正確執行。
步驟106，將所述集合交易提交至區塊鏈，使所述集合交易中的備選子交易被分別予以處理。
在一實施例中，在所述事件對應的備選子交易中，包含所述事件的所有參與方對所述事件的多方觸發資訊；其中，當所述多方觸發資訊通過驗證時，所述事件對應的備選子交易在區塊鏈中被觸發執行。多方觸發資訊代表了事件的所有參與方對於描述資訊的認可，並希望觸發事件的執行。例如，事件的任一參與方產生描述資訊並發送至其他參與方後，其他參與方可以確認描述資訊的內容、通過自身的身份金鑰對描述資訊產生簽名並將該簽名返回至該任一參與方，而多方觸發資訊中可以包含描述資訊和事件的各個參與方分別產生的簽名；每一簽名屬於相應的參與方提供的確認資訊，而如果採用密文數值，該確認資訊還將包含對密文數值的證明資訊，這在下文中將詳細描述。總之，本實施例中由事件的任一參與方組織形成多方觸發資訊後，只需要將任一參與方向自身維護的等待佇列中添加相應的備選子交易，並向區塊鏈提交包含該備選子交易的集合交易，而其他參與方則不需要實施類似處理；相應地，區塊鏈節點可以在多方觸發資訊通過驗證後，針對該任一參與方提交的備選子交易進行處理。
在一實施例中，在事件對應的備選子交易中，包含所述參與方對所述事件的單方觸發資訊；其中，當所述事件的所有參與方分別向區塊鏈提交的針對所述事件的單方觸發資訊均通過驗證時，所述事件對應的備選子交易在區塊鏈中被觸發執行。單方觸發資訊表明相應的參與方對事件的描述資訊予以確認，希望觸發事件的執行；而事件的每一參與方都需要分別向區塊鏈提交單方觸發資訊，使得區塊鏈節點基於所有參與方分別提交的單方觸發資訊，判定是否應當執行相應的備選子交易所指示的事件。例如，事件的任一參與方產生描述資訊並提供至其他參與方後，不僅該任一參與方需要向自身維護的等待佇列中添加相應的備選子交易，每一其他參與方在對描述資訊予以確認後，也分別向自身維護的等待佇列中添加相應的備選子交易；以及，每一參與方分別基於自身維護的等待佇列產生集合交易，從而通過將集合交易提交至區塊鏈，使得上述的單方觸發資訊被提交至區塊鏈，以供區塊鏈節點進行驗證。單方觸發資訊中可以包含描述資訊和相應參與方對描述資訊產生的簽名；簽名屬於相應參與方提供的確認資訊，而如果採用密文數值，確認資訊還包含證明資訊，這在下文中將詳細描述。通過由各個參與方分別向區塊鏈提交單方觸發資訊，而非某一參與方提交多方觸發資訊，不僅可以對處理壓力進行分擔、防止單個參與方的處理壓力過大，還可使各個參與方根據自身的實際情況(如處理壓力、優先順序管理等)對所參與的各個事件進行選擇性地處理甚至批量處理。
在一實施例中，事件的描述資訊可以包括變化量，而所述事件可以用於使各個參與方在區塊鏈上對應記錄的狀態參數按照所述變化量發生取值變化，比如增大取值、減小取值等。其中，根據事件的類型或場景差異，相應的狀態參數也可能不同，比如轉帳或跨境匯款場景下的狀態參數可以為參與方的帳戶餘額，再比如流量分配場景下的狀態參數可以為參與方持有的剩餘流量的數額，本說明書並不對此進行限制。
在一實施例中，各個參與方對應的狀態參數的取值、所述變化量可以為明文數值。區塊鏈中的區塊鏈節點分別維護有區塊鏈帳本，該區塊鏈帳本中記錄有全量交易資料，使得區塊鏈節點可以獲知各個參與方對應的狀態參數的取值；進一步地，所述任一參與方可以向區塊鏈提交一筆交易，該交易包含上述的觸發資訊，使得該交易經過共識後可以被基於所述任一參與方對應的狀態參數的取值、上述的變化量而執行，使得該任一參與方對應的狀態參數可以基於該變化量而實現取值變化。
在一實施例中，各個參與方對應的狀態參數的取值、所述變化量分別為基於同態加密演算法或同態承諾演算法計算得到的密文數值。對於同態加密演算法而言，可以採用任意類型的同態加密演算法，只要確保該同態加密演算法能夠滿足加法同態，使得即便處於密文狀態下，仍然能夠使得狀態參數的取值增加或減少該變化量；對於該同態加密演算法為加法同態加密演算法或全同態加密演算法，本說明書並不對此進行限制。對於同態承諾演算法而言，當採用相關技術中的Pedersen承諾機制時，可以為未加密資料判定一亂數，並基於該亂數與未加密資料進行計算得到相應的承諾資料，該承諾資料可以被作為上述的密文數值。
在一實施例中，當狀態參數的取值、變化量為密文數值時，參與方需要提供相關的證明資訊，以使得區塊鏈節點在執行相關交易時，能夠判定交易的合法有效性。例如，參與方需要給出對變化量的證明，以表明該變化量處於正確數值區間，譬如[0,2
64)。再例如，當事件用於使得某一參與方對應的狀態參數按照該變化量發生取值減小時，即交易目的是使得該某一參與方的狀態參數的取值減小該變化量，該某一參與方需要給出對狀態參數的取值與變化量的證明，以表明狀態參數的取值不小於取值減小量(該取值減小量與上述的變化量等值)。
在一實施例中，可以採用相關技術中的區間證明(Range Proof)技術，譬如Bulletproofs方案或Borromean環簽名方案等，產生上述的證明資訊，本說明書並不對此進行限制。
在一實施例中，任一參與方在產生描述資訊時，該描述資訊中的變化量可以為密文數值。比如當變化量的明文數值為t1時，若採用Pedersen承諾機制，可以根據該明文數值t1與亂數r1產生相應的密文承諾T1，而描述資訊中可以包含該T1、t1和r1，使得事件的其他參與方可以驗證密文承諾T1與明文數值t1、亂數r1之間的對應關係。其中，描述資訊中可以對明文數值t1和亂數r1進行加密保護，比如當描述資訊需要被發送至參與方X時，可以採用該參與方X的數位身份對應的身份公鑰進行加密，分別得到加密後的Enc_X(t1)、Enc_X(r1)並添加至描述資訊中，因而只有參與方X能夠通過自身的身份私鑰對Enc_X(t1)、Enc_X(r1)進行解密得到上述的明文數值t1和亂數r1，顯著提升了資料安全性。當然，除了採用公鑰加密方式之外，還可以採用相關技術中的其他任意加密方式，比如數位信封等，本說明書並不對此進行限制。
在一實施例中，當存在多個其他參與方時，描述資訊可以分別包含對應於各個其他參與方的加密後資料。例如，當其他參數方包括參與方X和參與方Y時，可以根據參與方X的身份公鑰對明文數值t1、亂數r1分別加密得到Enc_X(t1)、Enc_X(r1)，以及根據參與方Y的身份公鑰對明文數值t1、亂數r1分別加密得到Enc_Y(t1)、Enc_Y(r1)，並將Enc_X(t1)、Enc_X(r1)、Enc_Y(t1)和Enc_Y(r1)均添加至描述資訊中，使得所述任一參與方只需要準備一份描述資訊並分別發送至各個其他參與方，而無需針對每一其他參與方準備不同的描述資訊。當然，所述任一參與方可以針對每一其他參與方準備不同的描述資訊，比如在發送至參與方X的描述資訊中包含Enc_X(t1)和Enc_X(r1)，而在發送至參與方Y的描述資訊中包含Enc_Y(t1)和Enc_Y(r1)，本說明書並不對此進行限制。
在一實施例中，針對描述資訊中包含的密文狀態的變化量，集合交易中可以包括第一證明資訊，該第一證明資訊用於證明所述變化量處於正確數值區間。當任一參與方產生事件的描述資訊時，該任一參與方還可以產生第一證明資訊，使得無論是產生多方觸發資訊或單方觸發資訊，均不需要其他參與方針對該變化量的取值而產生其他的證明資訊。當然，每一參與方也可以分別為對應的變化量(各個參與方對應的變化量可能不同；例如在跨境匯款場景中，可能基於不同貨幣類型而導致變化量的取值存在差異)產生第一證明資訊，本說明書並不對此進行限制。
在一實施例中，如果所述事件用於使事件的某一參與方(可能存在多個類似的參與方)對應的狀態參數按照所述變化量發生取值減小，那麼集合交易中需要包含第二證明資訊，該第二證明資訊用於證明該某一參與方對應的狀態參數的取值不小於取值減小量。對於多方觸發資訊而言，事件的每一參與方可以在判定自身的狀態參數會按照所述變化量發生取值減小的情況下，分別產生相應的第二證明資訊並提供至上述的任一參與方，由該任一參與方組織形成多方觸發資訊；或者，可以統一由該任一參與方產生第二證明資訊，無需各個參與方單獨產生。對於單方觸發資訊而言，可由產生該單方觸發資訊的參與方為自身產生第二證明資訊。
在一實施例中，當某一參與方為自身產生第二證明資訊時，該參與方首先根據自身參與的其他事件，對自身對應的狀態參數進行取值更新，然後根據取值更新後的狀態參數產生第二證明資訊。例如，當狀態參數的取值、變化量為密文數值，且所述事件用於使得該參與方對應的狀態參數按照該變化量發生取值減小時，該參與方需要根據先前已處理的交易，判定自身對應的狀態參數的取值，從而產生正確的第二證明資訊，以確保相關事件能夠被順利執行。
例如，區塊鏈節點在收到各個參與方提交的集合交易後，提取集合交易中包含的備選子交易，並針對備選子交易包含的觸發資訊(多方觸發資訊或單方觸發資訊)進行確認和驗證。當多方觸發資訊包含事件的所有參與方分別對應的確認資訊，或者該事件的所有參與方均已提交了相應的單方觸發資訊(每一單方觸發資訊分別包含相應參與方的確認資訊)時，如果該多方觸發資訊或所有的單方觸發資訊均已通過驗證，那麼可以將該事件標記為成功狀態；類似地，可以將未通過驗證的事件標記為失敗狀態，將未在有效時間段內收到所有參與方對應的確認資訊的事件標記為超時狀態等，然後將各個事件的狀態提交至區塊鏈中。以事件的某一參與方為例，該參與方在提交集合交易之前，可以通過查詢區塊鏈帳本上的交易記錄，判定自身參與的各個事件的狀態，比如對於失敗狀態或超時狀態的交易，需要對狀態參數的取值進行相應的恢復(比如該參與方為匯款方時，需要對相應的帳戶餘額進行回滾)，對於成功狀態的交易需要更新狀態參數(比如該參與方為收款方時，需要對相應的轉帳金額進行收款、增加至帳戶餘額中)，然後根據狀態參數的更新後取值，產生相關事件的第二證明資訊(確保第二證明資訊是基於狀態參數的最新取值而產生)，然後產生並提交上述集合交易。
在一實施例中，當所述事件包括轉帳事件時，所述事件的參與方包括：匯款方和收款方，所述變化量包括：轉帳額，所述狀態參數包括：帳戶餘額；換言之，相當於從匯款方向收款方實施轉帳操作，使得匯款方的帳戶餘額減少相應的轉帳額、收款方的帳戶餘額增加相應的轉帳額。例如，描述資訊中可以包含匯款方的帳戶位址、收款方的帳戶地址、轉帳額(承諾值)、轉帳額明文(加密狀態)、亂數(加密狀態)等，以表明從匯款方的帳戶地址向收款方的帳戶地址轉移該轉帳額。
在一實施例中，當所述事件包括第一匯款事件時，所述事件的參與方包括：匯款方、中繼方、收款方，所述變化量包括：所述匯款方與所述中繼方之間基於第一類型資產的第一轉帳額、所述中繼方與所述收款方之間基於第二類型資產的第二轉帳額，所述狀態參數包括：帳戶餘額；換言之，相當於在匯款方與中繼方之間轉移第一類型的資產(如港幣)、資產額為第一轉帳額，並且在中繼方與收款方之間轉移第二類型的資產(如美元)、資產額為第二轉帳額，且根據第一類型與第二類型的資產之間的匯率，使得第一轉帳額與第二轉帳額對應的資產價值基本一致，那麼最終相當於匯款方的帳戶餘額減少了第一轉帳額(第一類型的資產)、收款方的帳戶餘額增加了第二轉帳額(第二類型的資產)，而中繼方的帳戶餘額增加了第一轉帳額(第一類型的資產)且減少了第二轉帳額(第二類型的資產)、在資產價值上相當於未發生變化。
在一實施例中，當所述事件包括第二匯款事件時，所述事件的參與方包括：匯款方、n個中繼方、收款方，所述變化量包括：所述匯款方與第1個中繼方之間基於第一類型資產的轉帳額、第i-1個中繼方與第i個中繼方之間基於第i類型資產的轉帳額、第n個中繼方與所述收款方之間基於第n+1類型資產的轉帳額，所述狀態參數包括：帳戶餘額；其中，1＜i≤n。當n=1時，本實施例的第二匯款事件相當於上述實施例的第一匯款事件，此處不再贅述。當n＞1時，由於存在多個中繼方，因而相比於上述實施例的第一匯款事件而言，還包含多個中繼方之間的資產轉移過程；以n=2為例，事件的參與方包括匯款方、中繼方1、中繼方2、收款方，其中：在匯款方與中繼方1之間轉移第一類型的資產(如港幣)、資產額為第一轉帳額，在中繼方1與中繼方2之間轉移第二類型的資產(如歐元)、資產額為第二轉帳額，在中繼方2與收款方之間轉移第三類型的資產(如美元)、資產額為第三轉帳額，且根據第一類型與第二類型的資產之間的匯率1、第二類型與第三類型的資產之間的匯率2，使得第一轉帳額、第二轉帳額與第三轉帳額對應的資產價值基本一致，那麼最終相當於匯款方的帳戶餘額減少了第一轉帳額(第一類型的資產)、收款方的帳戶餘額增加了第三轉帳額(第三類型的資產)，而中繼方1的帳戶餘額增加了第一轉帳額(第一類型的資產)且減少了第二轉帳額(第二類型的資產)、在資產價值上相當於未發生變化，中繼方2的帳戶餘額增加了第二轉帳額(第二類型的資產)且減少了第三轉帳額(第三類型的資產)、在資產價值上相當於未發生變化。
在一實施例中，當狀態參數的取值、變化量採用密文數值時，所述集合交易中包含的備選子交易還設定有變化前狀態值、變化後狀態值，使得所述備選子交易被處理後，所述參與方的狀態參數由所述變化前狀態值經由所述狀態變化量而變化至所述變化後狀態值；其中，所述狀態變化量、所述變化前狀態值和所述變化後狀態值分別為基於同態加密演算法或同態承諾演算法計算得到的密文數值。相應地，當區塊鏈節點對集合交易中包含的各個備選子交易進行驗證時，需要確保相鄰的備選子交易滿足：前一備選子交易對應的變化後狀態值與後一備選子交易對應的變化前狀態值相同，否則將判定為驗證失敗。
與圖1所示實施例相對應地，圖2是一示例性實施例提供的另一種基於區塊鏈的事件處理方法的流程圖。如圖2所示，該方法應用於區塊鏈節點，可以包括以下步驟：
步驟202，接收參與方提交至區塊鏈的集合交易，所述集合交易中包含從所述參與方維護的等待佇列中選取的若干備選子交易，所述備選子交易對應於所述參與方所參與的事件。
在一實施例中，事件存在多個參與方，每一參與方對應於參與物件，該參與物件可以為個人、企業、組織等，本說明書並不對此進行限制。參與物件存在對應的數位身份，使得承載該數位身份的電子設備相當於被配置為該參與物件所對應的參與方。
在一實施例中，本說明書的事件可以包括任意類型、覆蓋任意場景，比如投票、簽訂協定、流量分配、轉帳、跨境匯款等，本說明書並不對此進行限制。以投票為例，描述資訊可以包括投票事由和投票選項等資訊，而各個參與方向區塊鏈中提交的觸發資訊可以包括對投票選項的選擇結果，從而觸發完成投票操作。
在一實施例中，備選子交易中包含事件的描述資訊，該描述資訊用於描述相關事件的情況，使得該備選子交易被處理時，可以根據該描述資訊實施相應的事件。例如，描述資訊可以表徵相關事件的執行邏輯、所涉及的參與方、對參與方的狀態參數的改變方式(如增大或減小狀態參數的取值)、變化量等，本說明書並不對此進行限制。實際上，事件的相關內容可由各個參與方之間預先通過任意方式進行溝通，然後由所述任一參與方進行起草該事件的描述資訊，使得事件的其他參與方可以根據預先的溝通結果對該描述資訊的內容進行查看和確認；當然，所述任一參與方也可以在並未預先溝通的情況下，自行判定事件的其他參與方以及描述資訊中的其他內容，本說明書並不對此進行限制。
在一實施例中，事件的描述資訊可由該事件的任一參與方產生，並添加為該任一參與方維護的等待佇列中的備選子交易。以及，該任一參與方還將產生的描述資訊分享至其他參與方，使得其他參與方對描述資訊進行確認。
在一實施例中，任一參與方可以將描述資訊通過鏈外通道發送至事件的其他參與方。通過鏈外通道將描述資訊發送至事件的其他參與方，可以實現對描述資訊的高效傳輸。其中，鏈外通道可以為事件的各個參與方之間建立的加密通道或其他形式的秘密頻道，以避免發生資訊洩露。
在一實施例中，任一參與方可以通過向區塊鏈提交一筆交易，並將上述的描述資訊包含於該交易中，使得該交易在經過共識後可以被發送至區塊鏈中的所有區塊鏈節點；而事件的每一參與方均可以被配置為區塊鏈中的區塊鏈節點，或者每一參與方可以在區塊鏈中存在對應的區塊鏈節點，使得每一參與方可以通過自身或對應的區塊鏈節點所維護的區塊鏈帳本(區塊鏈帳本包含區塊鏈的全量交易資料)，獲得上述交易及其包含的描述資訊，從而使得上述的描述資訊被同步至事件的其他參與方。
在一實施例中，集合交易中可以包含多個備選子交易，每一備選子交易分別對應於上述參與方所參與的一個事件，使得該集合交易被提交至區塊鏈後，所包含的多個備選子交易均可以在區塊鏈中被處理，從而使得這些備選子交易對應的多個事件被實施。可見，通過在集合交易中包含多個備選子交易，使得這些備選子交易被批量提交至區塊鏈，可以減少向區塊鏈提交的交易數量，無需針對每一備選子交易均產生一筆區塊鏈交易，有助於降低資源消耗、提升處理效率。
在一實施例中，可以在所述等待佇列中的備選子交易達到預設數量時，選取所述等待佇列中已存在的備選子交易(即預設數量的備選子交易)，以產生相應的集合交易。在另一實施例中，可以按照預設時長週期性地選取所述等待佇列中已存在的備選子交易，以產生相應的集合交易；當然，每一集合交易的容量可以存在最大限制，使得同一週期內選取的備選子交易的數量存在相應的最大值，超出的部分可以延期至下一週期進行選取。當然，還可以通過其他的預設規則來選取備選子交易，本說明書並不對此進行限制。
在一實施例中，等待佇列中的備選子交易可以按照添加時刻進行依次排列，而每次可以從前向後依次選取各個備選子交易，使得在先產生的備選子交易可以被優先選取。當然，參與方也可以根據實際需求，比如事件的緊急程度、事件的優先順序等，對等待佇列中的備選子交易實施與順序無關的選取操作；或者，等待佇列本身就可以按照上述的緊急程度、優先順序等進行排列，這樣依然可以視為依次選取。
在一實施例中，參與方可以按照產生順序為各個合併交易添加編號，使各個合併交易在區塊鏈中被按照對應編號的大小進行依次處理。換言之，區塊鏈交易在收到參與方提交的合併交易後，需要讀取合併交易所包含的編號；如果編號與先前處理的合併交易的編號連續，比如最新處理的合併交易的編號為99、當前收到的合併交易的編號為100，則可以對該編號為100的合併交易進行處理；如果編號之間並不連續，比如最新處理的合併交易的編號為99、當前收到的合併交易的編號為101，則區塊鏈節點需要等待並優先處理編號為100的合併交易，然後才能處理編號為101的合併交易。由於每條交易被執行後都可能導致該參與方的狀態參數發生變化，而在後交易的執行需要依賴於先前交易執行後的狀態參數的取值，因而需要確保各個合併交易被按照對應編號的大小進行依次處理，以使得各個合併交易均能夠正確執行。
步驟204，執行所述集合交易，以對所述集合交易中的備選子交易分別予以處理。
在一實施例中，在所述事件對應的備選子交易中，包含所述事件的所有參與方對所述事件的多方觸發資訊；其中，當所述多方觸發資訊通過驗證時，所述事件對應的備選子交易在區塊鏈中被觸發執行。多方觸發資訊代表了事件的所有參與方對於描述資訊的認可，並希望觸發事件的執行。例如，事件的任一參與方產生描述資訊並發送至其他參與方後，其他參與方可以確認描述資訊的內容、通過自身的身份金鑰對描述資訊產生簽名並將該簽名返回至該任一參與方，而多方觸發資訊中可以包含描述資訊和事件的各個參與方分別產生的簽名；每一簽名屬於相應的參與方提供的確認資訊，而如果採用密文數值，該確認資訊還將包含對密文數值的證明資訊，這在下文中將詳細描述。總之，本實施例中由事件的任一參與方組織形成多方觸發資訊後，只需要將任一參與方向自身維護的等待佇列中添加相應的備選子交易，並向區塊鏈提交包含該備選子交易的集合交易，而其他參與方則不需要實施類似處理；相應地，區塊鏈節點可以在多方觸發資訊通過驗證後，針對該任一參與方提交的備選子交易進行處理。
在一實施例中，在事件對應的備選子交易中，包含所述參與方對所述事件的單方觸發資訊；其中，當所述事件的所有參與方分別向區塊鏈提交的針對所述事件的單方觸發資訊均通過驗證時，所述事件對應的備選子交易在區塊鏈中被觸發執行。單方觸發資訊表明相應的參與方對事件的描述資訊予以確認，希望觸發事件的執行；而事件的每一參與方都需要分別向區塊鏈提交單方觸發資訊，使得區塊鏈節點基於所有參與方分別提交的單方觸發資訊，判定是否應當執行相應的備選子交易所指示的事件。例如，事件的任一參與方產生描述資訊並提供至其他參與方後，不僅該任一參與方需要向自身維護的等待佇列中添加相應的備選子交易，每一其他參與方在對描述資訊予以確認後，也分別向自身維護的等待佇列中添加相應的備選子交易；以及，每一參與方分別基於自身維護的等待佇列產生集合交易，從而通過將集合交易提交至區塊鏈，使得上述的單方觸發資訊被提交至區塊鏈，以供區塊鏈節點進行驗證。單方觸發資訊中可以包含描述資訊和相應參與方對描述資訊產生的簽名；簽名屬於相應參與方提供的確認資訊，而如果採用密文數值，確認資訊還包含證明資訊，這在下文中將詳細描述。通過由各個參與方分別向區塊鏈提交單方觸發資訊，而非某一參與方提交多方觸發資訊，不僅可以對處理壓力進行分擔、防止單個參與方的處理壓力過大，還可使各個參與方根據自身的實際情況(如處理壓力、優先順序管理等)對所參與的各個事件進行選擇性地處理甚至批量處理。
在一實施例中，事件的描述資訊可以包括變化量，而所述事件可以用於使各個參與方在區塊鏈上對應記錄的狀態參數按照所述變化量發生取值變化，比如增大取值、減小取值等。其中，根據事件的類型或場景差異，相應的狀態參數也可能不同，比如轉帳或跨境匯款場景下的狀態參數可以為參與方的帳戶餘額，再比如流量分配場景下的狀態參數可以為參與方持有的剩餘流量的數額，本說明書並不對此進行限制。
在一實施例中，各個參與方對應的狀態參數的取值、所述變化量可以為明文數值。區塊鏈中的區塊鏈節點分別維護有區塊鏈帳本，該區塊鏈帳本中記錄有全量交易資料，使得區塊鏈節點可以獲知各個參與方對應的狀態參數的取值；進一步地，所述任一參與方可以向區塊鏈提交一筆交易，該交易包含上述的觸發資訊，使得該交易經過共識後可以被基於所述任一參與方對應的狀態參數的取值、上述的變化量而執行，使得該任一參與方對應的狀態參數可以基於該變化量而實現取值變化。
在一實施例中，各個參與方對應的狀態參數的取值、所述變化量分別為基於同態加密演算法或同態承諾演算法計算得到的密文數值。對於同態加密演算法而言，可以採用任意類型的同態加密演算法，只要確保該同態加密演算法能夠滿足加法同態，使得即便處於密文狀態下，仍然能夠使得狀態參數的取值增加或減少該變化量；對於該同態加密演算法為加法同態加密演算法或全同態加密演算法，本說明書並不對此進行限制。對於同態承諾演算法而言，當採用相關技術中的Pedersen承諾機制時，可以為未加密資料判定一亂數，並基於該亂數與未加密資料進行計算得到相應的承諾資料，該承諾資料可以被作為上述的密文數值。
在一實施例中，當狀態參數的取值、變化量為密文數值時，參與方需要提供相關的證明資訊，以使得區塊鏈節點在執行相關交易時，能夠判定交易的合法有效性。例如，參與方需要給出對變化量的證明，以表明該變化量處於正確數值區間，譬如[0,2
64)。再例如，當事件用於使得某一參與方對應的狀態參數按照該變化量發生取值減小時，即交易目的是使得該某一參與方的狀態參數的取值減小該變化量，該某一參與方需要給出對狀態參數的取值與變化量的證明，以表明狀態參數的取值不小於取值減小量(該取值減小量與上述的變化量等值)。
在一實施例中，可以採用相關技術中的區間證明(Range Proof)技術，譬如Bulletproofs方案或Borromean環簽名方案等，產生上述的證明資訊，本說明書並不對此進行限制。
在一實施例中，任一參與方在產生描述資訊時，該描述資訊中的變化量可以為密文數值。比如當變化量的明文數值為t1時，若採用Pedersen承諾機制，可以根據該明文數值t1與亂數r1產生相應的密文承諾T1，而描述資訊中可以包含該T1、t1和r1，使得事件的其他參與方可以驗證密文承諾T1與明文數值t1、亂數r1之間的對應關係。其中，描述資訊中可以對明文數值t1和亂數r1進行加密保護，比如當描述資訊需要被發送至參與方X時，可以採用該參與方X的數位身份對應的身份公鑰進行加密，分別得到加密後的Enc_X(t1)、Enc_X(r1)並添加至描述資訊中，因而只有參與方X能夠通過自身的身份私鑰對Enc_X(t1)、Enc_X(r1)進行解密得到上述的明文數值t1和亂數r1，顯著提升了資料安全性。當然，除了採用公鑰加密方式之外，還可以採用相關技術中的其他任意加密方式，比如數位信封等，本說明書並不對此進行限制。
在一實施例中，當存在多個其他參與方時，描述資訊可以分別包含對應於各個其他參與方的加密後資料。例如，當其他參數方包括參與方X和參與方Y時，可以根據參與方X的身份公鑰對明文數值t1、亂數r1分別加密得到Enc_X(t1)、Enc_X(r1)，以及根據參與方Y的身份公鑰對明文數值t1、亂數r1分別加密得到Enc_Y(t1)、Enc_Y(r1)，並將Enc_X(t1)、Enc_X(r1)、Enc_Y(t1)和Enc_Y(r1)均添加至描述資訊中，使得所述任一參與方只需要準備一份描述資訊並分別發送至各個其他參與方，而無需針對每一其他參與方準備不同的描述資訊。當然，所述任一參與方可以針對每一其他參與方準備不同的描述資訊，比如在發送至參與方X的描述資訊中包含Enc_X(t1)和Enc_X(r1)，而在發送至參與方Y的描述資訊中包含Enc_Y(t1)和Enc_Y(r1)，本說明書並不對此進行限制。
在一實施例中，針對描述資訊中包含的密文狀態的變化量，集合交易中可以包括第一證明資訊，該第一證明資訊用於證明所述變化量處於正確數值區間。當任一參與方產生事件的描述資訊時，該任一參與方還可以產生第一證明資訊，使得無論是產生多方觸發資訊或單方觸發資訊，均不需要其他參與方針對該變化量的取值而產生其他的證明資訊。當然，每一參與方也可以分別為對應的變化量(各個參與方對應的變化量可能不同；例如在跨境匯款場景中，可能基於不同貨幣類型而導致變化量的取值存在差異)產生第一證明資訊，本說明書並不對此進行限制。
在一實施例中，如果所述事件用於使事件的某一參與方(可能存在多個類似的參與方)對應的狀態參數按照所述變化量發生取值減小，那麼集合交易中需要包含第二證明資訊，該第二證明資訊用於證明該某一參與方對應的狀態參數的取值不小於取值減小量。對於多方觸發資訊而言，事件的每一參與方可以在判定自身的狀態參數會按照所述變化量發生取值減小的情況下，分別產生相應的第二證明資訊並提供至上述的任一參與方，由該任一參與方組織形成多方觸發資訊；或者，可以統一由該任一參與方產生第二證明資訊，無需各個參與方單獨產生。對於單方觸發資訊而言，可由產生該單方觸發資訊的參與方為自身產生第二證明資訊。
在一實施例中，當某一參與方為自身產生第二證明資訊時，該參與方首先根據自身參與的其他事件，對自身對應的狀態參數進行取值更新，然後根據取值更新後的狀態參數產生第二證明資訊。例如，當狀態參數的取值、變化量為密文數值，且所述事件用於使得該參與方對應的狀態參數按照該變化量發生取值減小時，該參與方需要根據先前已處理的交易，判定自身對應的狀態參數的取值，從而產生正確的第二證明資訊，以確保相關事件能夠被順利執行。
例如，區塊鏈節點在收到各個參與方提交的集合交易後，提取集合交易中包含的備選子交易，並針對備選子交易包含的觸發資訊(多方觸發資訊或單方觸發資訊)進行確認和驗證。當多方觸發資訊包含事件的所有參與方分別對應的確認資訊，或者該事件的所有參與方均已提交了相應的單方觸發資訊(每一單方觸發資訊分別包含相應參與方的確認資訊)時，如果該多方觸發資訊或所有的單方觸發資訊均已通過驗證，那麼可以將該事件標記為成功狀態；類似地，可以將未通過驗證的事件標記為失敗狀態，將未在有效時間段內收到所有參與方對應的確認資訊的事件標記為超時狀態等，然後將各個事件的狀態提交至區塊鏈中。以事件的某一參與方為例，該參與方在提交集合交易之前，可以通過查詢區塊鏈帳本上的交易記錄，判定自身參與的各個事件的狀態，比如對於失敗狀態或超時狀態的交易，需要對狀態參數的取值進行相應的恢復(比如該參與方為匯款方時，需要對相應的帳戶餘額進行回滾)，對於成功狀態的交易需要更新狀態參數(比如該參與方為收款方時，需要對相應的轉帳金額進行收款、增加至帳戶餘額中)，然後根據狀態參數的更新後取值，產生相關事件的第二證明資訊(確保第二證明資訊是基於狀態參數的最新取值而產生)，然後產生並提交上述集合交易。
在一實施例中，當所述事件包括轉帳事件時，所述事件的參與方包括：匯款方和收款方，所述變化量包括：轉帳額，所述狀態參數包括：帳戶餘額；換言之，相當於從匯款方向收款方實施轉帳操作，使得匯款方的帳戶餘額減少相應的轉帳額、收款方的帳戶餘額增加相應的轉帳額。例如，描述資訊中可以包含匯款方的帳戶位址、收款方的帳戶地址、轉帳額(承諾值)、轉帳額明文(加密狀態)、亂數(加密狀態)等，以表明從匯款方的帳戶地址向收款方的帳戶地址轉移該轉帳額。
在一實施例中，當所述事件包括第一匯款事件時，所述事件的參與方包括：匯款方、中繼方、收款方，所述變化量包括：所述匯款方與所述中繼方之間基於第一類型資產的第一轉帳額、所述中繼方與所述收款方之間基於第二類型資產的第二轉帳額，所述狀態參數包括：帳戶餘額；換言之，相當於在匯款方與中繼方之間轉移第一類型的資產(如港幣)、資產額為第一轉帳額，並且在中繼方與收款方之間轉移第二類型的資產(如美元)、資產額為第二轉帳額，且根據第一類型與第二類型的資產之間的匯率，使得第一轉帳額與第二轉帳額對應的資產價值基本一致，那麼最終相當於匯款方的帳戶餘額減少了第一轉帳額(第一類型的資產)、收款方的帳戶餘額增加了第二轉帳額(第二類型的資產)，而中繼方的帳戶餘額增加了第一轉帳額(第一類型的資產)且減少了第二轉帳額(第二類型的資產)、在資產價值上相當於未發生變化。
在一實施例中，當所述事件包括第二匯款事件時，所述事件的參與方包括：匯款方、n個中繼方、收款方，所述變化量包括：所述匯款方與第1個中繼方之間基於第一類型資產的轉帳額、第i-1個中繼方與第i個中繼方之間基於第i類型資產的轉帳額、第n個中繼方與所述收款方之間基於第n+1類型資產的轉帳額，所述狀態參數包括：帳戶餘額；其中，1＜i≤n。當n=1時，本實施例的第二匯款事件相當於上述實施例的第一匯款事件，此處不再贅述。當n＞1時，由於存在多個中繼方，因而相比於上述實施例的第一匯款事件而言，還包含多個中繼方之間的資產轉移過程；以n=2為例，事件的參與方包括匯款方、中繼方1、中繼方2、收款方，其中：在匯款方與中繼方1之間轉移第一類型的資產(如港幣)、資產額為第一轉帳額，在中繼方1與中繼方2之間轉移第二類型的資產(如歐元)、資產額為第二轉帳額，在中繼方2與收款方之間轉移第三類型的資產(如美元)、資產額為第三轉帳額，且根據第一類型與第二類型的資產之間的匯率1、第二類型與第三類型的資產之間的匯率2，使得第一轉帳額、第二轉帳額與第三轉帳額對應的資產價值基本一致，那麼最終相當於匯款方的帳戶餘額減少了第一轉帳額(第一類型的資產)、收款方的帳戶餘額增加了第三轉帳額(第三類型的資產)，而中繼方1的帳戶餘額增加了第一轉帳額(第一類型的資產)且減少了第二轉帳額(第二類型的資產)、在資產價值上相當於未發生變化，中繼方2的帳戶餘額增加了第二轉帳額(第二類型的資產)且減少了第三轉帳額(第三類型的資產)、在資產價值上相當於未發生變化。
在一實施例中，當狀態參數的取值、變化量採用密文數值時，所述集合交易中包含的備選子交易還設定有變化前狀態值、變化後狀態值，使得所述備選子交易被處理後，所述參與方的狀態參數由所述變化前狀態值經由所述狀態變化量而變化至所述變化後狀態值；其中，所述狀態變化量、所述變化前狀態值和所述變化後狀態值分別為基於同態加密演算法或同態承諾演算法計算得到的密文數值。相應地，當區塊鏈節點對集合交易中包含的各個備選子交易進行驗證時，需要確保相鄰的備選子交易滿足：前一備選子交易對應的變化後狀態值與後一備選子交易對應的變化前狀態值相同，否則將判定為驗證失敗。
為了便於理解，下面以跨境匯款場景為例，對本說明書一個或多個實施例的技術方案進行說明。基於本說明書的技術方案，每一機構可以分別對自身所參與的若干匯款交易(相當於上述的備選子交易)合併為一筆區塊鏈交易(相當於上述的集合交易)，並通過向區塊鏈提交該區塊鏈交易，實現對若干匯款交易的批量提交和處理。下面將首先對單筆匯款交易的產生與處理過程進行描述，然後擴展至多筆匯款交易的批量處理。
圖3是一示例性實施例提供的一種跨境匯款的場景示意圖。如圖3所示，假定由用戶1向用戶2進行區塊鏈匯款；其中，本說明書中的“用戶”可以表現為所登錄的用戶帳號，而該用戶帳號實際可以歸屬於個人或組織，本說明書並不對此進行限制。假定用戶1在國家A的機構1處開設有客戶資金帳戶1、用戶2在國家B的機構4處開設有客戶資金帳戶2，本說明書可以在機構1與機構4之間無法直接實施跨境匯款的情況下，通過機構2與機構3的協助而在區塊鏈上實現該跨境匯款的操作。
機構1、機構2、機構3和機構4分別存在對應的設備1、設備2、設備3和設備4，並通過在設備1~4上運行區塊鏈的用戶端程式，使得設備1~4被配置為相應的區塊鏈節點；相應地，機構1~4可以通過設備1~4實現與區塊鏈相關的操作。例如，機構1~4可以分別通過設備1~4向區塊鏈提交相應的區塊鏈交易；再例如，設備1~4分別維護有區塊鏈上的全量交易資料，即區塊鏈帳本，使得機構1~4可以分別據此查詢和維護各個區塊鏈帳戶的餘額資料，比如機構1對應的區塊鏈帳戶Y1持有1000港幣，機構2對應的區塊鏈帳戶Y2持有2500港幣和4200歐元，機構3對應的區塊鏈帳戶Y3持有3000歐元和2000美元，機構4對應的區塊鏈帳戶Y4持有1500美元等。
出於隱私保護等方面的考慮，區塊鏈帳戶Y1~Y4的餘額資料往往並非以明文形式進行維護，而是採用對應的密文資料。以區塊鏈帳戶Y1為例，在區塊鏈帳本中可以被記錄為(currency_1, PC(a, r_a), Enc_A(a), Enc_A(r_a))，其中：currency_1表示貨幣類型為港幣，a表示港幣數額為1000，r_a為a對應的亂數，PC(a, r_a)是通過Pedersen承諾機制對a和r_a進行計算得到的密文形式的承諾值，Enc_A(a)、Enc_A(r_a)分別為a和r_a的密文取值(比如可以採用機構1的身份公鑰進行加密，或者可以採用其他任意形式的加密演算法)。區塊鏈帳戶Y2可以被記錄為(currency_1, PC(b1, r_b1), Enc_B(b1), Enc_B(r_b1))、(currency_2, PC(b2, r_b2), Enc_B(b2), Enc_B(r_b2))，其中：b1表示港幣數額為2500、r_b1為b1對應的亂數，currency_2表示貨幣類型為歐元，b2表示歐元數額為4200、r_b2為b2對應的亂數。區塊鏈帳戶Y3可以被記錄為(currency_2, PC(c1, r_c1), Enc_C(c1), Enc_C(r_c1))、(currency_3, PC(c2, r_c2), Enc_C(c2), Enc_C(r_c2))，其中：c1表示港幣歐元為3000、r_c1為c1對應的亂數，currency_3表示貨幣類型為美元，c2表示美元數額為2000、r_c2為c2對應的亂數。區塊鏈帳戶Y4可以被記錄為(currency_3, PC(d, r_d), Enc_D(d), Enc_D(r_d))，其中d表示美元數額為1500、r_d為d對應的亂數。
基於圖3所示的匯款場景，圖4是一示例性實施例的一種跨境匯款過程中的互動示意圖。如圖4所示，跨境匯款的互動過程可以包括以下步驟：
步驟401，設備1起草匯款交易tx_i。
在一實施例中，假定用戶1希望向用戶2匯款500港幣，該用戶1可以通過在機構1處的客戶資金帳戶1提供該500港幣，而用戶2可以通過在機構4處的客戶資金帳戶2收取按一定匯率計算後的美元。
在一實施例中，機構1可以從用戶1對應的客戶資金帳戶1中扣取500港幣；以及，機構1需要在自身與機構4之間判定出匯款路由，比如圖4中的匯款路由為“機構1→機構2→機構3→機構4”，使得機構1可以向機構2轉入500港幣、機構2可以向機構3轉入56歐元(相當於500港幣)、機構3可以向機構4轉入64美元(相當於56歐元、500港幣)，並最終由機構4向用戶2對應的客戶資金帳戶2轉入64美元，從而完成匯款操作。其中，機構1從客戶資金帳戶1扣取500港幣、機構4向客戶資金帳戶2轉入64美元屬於鏈外操作，而機構1~機構4之間則通過區塊鏈實現鏈上資金轉移。
在一實施例中，在上述的匯款路由“機構1→機構2→機構3→機構4”中，機構1與機構4之間存在2個中繼方為機構3和機構4；而在其他實施例中，中繼方的數量可以為1個、3個或3個以上，本說明書並不對此進行限制。
針對已經判定的上述匯款路由，以及各個機構之間的匯款金額，設備1起草的匯款交易tx_i可以包括以下匯款交易詳情：交易id為tx_i，區塊鏈帳戶Y1的地址Z1、區塊鏈帳戶Y2的地址Z2、區塊鏈帳戶Y3的地址Z3、區塊鏈帳戶Y4的位址Z4，與交易金額相關的密文資訊{(currency_1，PC(t1, r_t1), Enc_B(t1), Enc_B(r_t1), Enc_C(t1), Enc_C (r_t1), Enc_D(t1), Enc_D(r_t1)), (currency_2, PC(t2,r_t2), Enc_B(t2), Enc_B(r_t2), Enc_C(t2), Enc_C(r_t2), Enc_D (t2), Enc_D(r_t2)),(currency_3, PC(t3,r_t3), Enc_B(t3), Enc_B(r_t3), Enc_C(t3), Enc_C(r_t3), Enc_D(t3), Enc_D (r_t3)), rate1, rate2, time, …}，針對交易金額t1、t2、t3的區間證明RP_t1、RP_t2、RP_t3等。
其中，位址Z1~Z4用於表明本次匯款事件的參與方，以使得後續從該位址Z1~Z4對應的區塊鏈帳戶Y1~Y4實施轉帳匯款。
在(currency_1，PC(t1, r_t1), Enc_B(t1), Enc_B(r_t1), Enc_C(t1), Enc_C(r_t1), Enc_D(t1), Enc_D(r_t1))中，t1表示從位址Z1向位址Z2的轉帳金額(如上述的500港幣)，r_t1為該金額t1對應的亂數，PC(t1,r_t1)為基於金額t1和亂數r_t1計算得到的承諾值，Enc_B(t1)表示用機構2的身份公鑰對金額t1進行加密後的密文數值、Enc_C(t1)表示用機構3的身份公鑰對金額t1進行加密後的密文數值、Enc_D(t1)表示用機構4的身份公鑰對金額t1進行加密後的密文數值；類似地，Enc_B(r_t1)、Enc_C(r_t1)、Enc_D(r_t1)分別為通過機構2、機構3、機構4的身份公鑰對金額t1進行加密後的密文數值。(currency_2, PC(t2,r_t2), Enc_B(t2), Enc_B(r_t2), Enc_C(t2), Enc_C(r_t2), Enc_D(t2), Enc_D (r_t2))和(currency_3, PC(t3,r_t3), Enc_B(t3), Enc_B(r_t3), Enc_C(t3), Enc_C(r_t3), Enc_D(t3), Enc_D(r_t3))的情況類似，此處不再贅述。rate1、rate2分別為currency_1與currency_2的匯率、currency_2與currency_3的匯率。time為交易時刻。以及，還可能存在一些其他的交易所需資料，這可以參考相關技術中的方案，此處不再一一列舉。
RP_t1、RP_t2、RP_t3分別為對應於交易金額t1、t2、t3的區間證明，以分別用於證明交易金額t1、t2、t3處於正確數值區間，比如1≤t1＜2
64、1≤t2＜2
64、1≤t3＜2
64。其中，設備1可以通過相關技術中的零知識證明技術產生上述的區間證明，本說明書並不對此進行限制。
而如果採用明文數值，那麼在匯款交易tx_i的匯款交易詳情中，上述與交易金額相關的密文資訊可以被替換為與交易金額相關的明文資訊，比如{(currency_1, t1), (currency_2, t2), (currency_3, t3), rate1, rate2, time, …}，且無需包含上述的區間證明RP_t1、RP_t2、RP_t3等內容。
步驟402a~402c，設備1將匯款交易詳情分別同步至設備2、設備3和設備4。
在一實施例中，設備1可以通過機構1的身份私鑰對匯款交易詳情進行簽名後，通過鏈外(或稱為，鏈下)通道分別發送至設備2~設備4，以實現資料同步。
在一實施例中，設備1~設備4分別運行有區塊鏈的用戶端程式，使得設備1~設備4分別被配置為區塊鏈中的區塊鏈節點；或者，設備1~設備4在區塊鏈中分別存在對應的區塊鏈節點，本說明書並不對此進行限制。其中，區塊鏈中的每一區塊鏈節點分別維護有內容統一的區塊鏈帳本，區塊鏈帳本中記錄有全量的區塊鏈資料。因此，設備1可以產生一筆交易，該交易的內容包含上述匯款交易tx_i的匯款交易詳情，並將該交易提交至區塊鏈中；相應地，當該交易通過共識後，可以被發送至區塊鏈中的各個區塊鏈節點，以供各個區塊鏈節點更新自身維護的區塊鏈帳本。因此，設備1、設備2、設備3和設備4可以分別通過自身對應的區塊鏈節點所維護的區塊鏈帳本，獲知設備1提交的上述交易，從而獲取該交易中包含的上述匯款交易tx_i的匯款交易詳情。
當然，設備1還可能通過其他方式將匯款交易資料同步至設備2~設備4，本說明書並不對此進行限制。
步驟403a，設備1將匯款交易詳情對應的匯款交易tx_i添加至自身的本地佇列1。
在一實施例中，當設備1通過鏈外通道發送匯款交易詳情時，設備1可以直接向本地佇列1添加匯款交易tx_i；當然，設備1可以等待設備2~設備4對匯款交易詳情確認完畢並返回相應的確認回應後，才向本地佇列1添加匯款交易tx_i，以確保設備2~設備4均參與至該匯款交易tx_i。
在一實施例中，當設備1通過區塊鏈將匯款交易詳情同步至設備2~設備4時，設備1同樣會收到區塊鏈上同步的該匯款交易詳情，那麼設備1既可以對該匯款交易詳情進行驗證(驗證過程可參考步驟403b)，並在通過驗證後將匯款交易tx_i添加至本地佇列1，也可以在判定該匯款交易詳情對應於匯款交易tx_i、該匯款交易tx_i由該設備1自身起草並提交至區塊鏈時，略去對匯款交易詳情的驗證過程，而直接添加至本地佇列1。
步驟403b，設備2對收到的匯款交易詳情進行驗證後，將其添加至自身的本地佇列2。
在一實施例中，設備2在收到匯款交易詳情後，需要實施驗證操作，包括：設備2通過自身的身份私鑰對匯款交易詳情包含的Enc_B(t1)、Enc_B(r_t1)、Enc_B(t2)、Enc_B(r_t2)、Enc_B(t3)、Enc_B(r_t3)進行解密，得到相應的金額t1與亂數r_t1、金額t2與亂數r_t2、金額t3與亂數r_t3，並分別驗證PC(t1, r_t1)= r_t1G+t1H、PC(t2, r_t2)= r_t2G+t2H、PC(t3, r_t3)= r_t3G+t3H是否成立，其中G、H為系統參數；設備2驗證currency_1與currency_2之間的匯率是否為rate1、currency_2與currency_3之間的匯率是否為rate2；設備2驗證區間證明RP_t1、RP_t2、RP_t3是否正確等。在判定匯款交易詳情通過驗證後，設備2可以向自身維護的本地佇列2添加相應的匯款交易tx_i，並且向設備1返回確認回應、以表明接受相應的匯款交易。
當然，如果採用明文數值，那麼可以省略上述的解密、承諾值驗證、區間證明驗證等操作，比如僅對各個參與方的區塊鏈帳戶的地址、t1、t2、t3、rate1、rate2的取值進行核對。
步驟403c-403d，設備3-4分別對收到的匯款交易詳情進行驗證後，將其添加至自身的本地佇列3-4。
在一實施例中，設備3、設備4所實施的操作與設備2相類似，此處不再一一贅述。
至此，匯款交易tx_i已經被設備1~設備4分別添加至各自維護的本地佇列1~4中。類似地，當設備1~設備4分別參與到其他的匯款交易(並不一定為設備1~設備4同時參與的匯款交易)時，同樣可以採用類似於對上述匯款交易tx_i的處理方式，向相應的本地佇列中添加匯款交易，以用於下述步驟中的交易聚合與批量處理。
步驟404a，設備1根據本地佇列1中的匯款交易，聚合產生交易TX_a，並在簽名後提交至區塊鏈。
如上文所述，與匯款交易tx_i相類似的，機構1還可以參與其他的匯款交易，比如當某一用戶需要通過機構1向另一用戶進行匯款時，設備1可以通過類似於上述步驟的方式，起草相應的匯款交易、將匯款交易詳情發送至其他各個機構進行驗證、向本地佇列1中添加相應的匯款交易tx_i。同時，機構1還可以作為一些匯款交易的中繼方(類似於機構2-3在上述實施例中的角色)或收款方(類似於機構4在上述實施例中的角色)，使得該機構1可以通過設備1接收這些匯款交易的匯款方(類似於機構1在上述實施例中的角色)發送的匯款交易詳情，並在驗證通過後向本地佇列1中添加相應的匯款交易。
因此，設備1維護的本地佇列1中包含機構1所參與的諸多匯款交易。而設備1可以按照預定義的交易選擇規則，每次從本地佇列1中選取一個或多個匯款交易，並對被選取的匯款交易進行聚合，產生一筆區塊鏈交易。
例如，圖5是一示例性實施例提供的一種基於密文數值的區塊鏈交易內容的示意圖。如圖5所示，假定設備1每次選取4個匯款交易並聚合為一筆區塊鏈交易，比如匯款交易tx_11、tx_12、tx_13、tx_14被聚合為區塊鏈交易TX_1，匯款交易tx_21、tx_22、tx_23、tx_24被聚合為區塊鏈交易TX_2，匯款交易tx_31、tx_32、tx_33、tx_34被聚合為區塊鏈交易TX_3。在設備1產生的每一區塊鏈交易中，分別包含設備1設定的順序編號seq和與各個匯款交易相關的資訊。
順序編號seq與各個區塊鏈交易的產生順序相關。比如區塊鏈交易TX_1的seq取值為99、區塊鏈交易TX_2的seq取值為100、區塊鏈交易TX_3的seq取值為101，表明區塊鏈交易TX_1早於區塊鏈交易TX_2產生、區塊鏈交易TX_2早於區塊鏈交易TX_3產生。相應的，區塊鏈節點在收到設備1提交的各個區塊鏈交易後，會按照seq取值從小到大的順序依次對各個區塊鏈交易進行處理，比如先處理區塊鏈交易TX_1、再處理區塊鏈交易TX_2、然後處理區塊鏈交易TX_3。
與各個匯款交易相關的資訊可以包括：區塊鏈交易的起始狀態餘額、區塊鏈交易的結束狀態餘額、每一匯款交易的起始狀態餘額、每一匯款交易的交易額、每一匯款交易的結束狀態(即臨時狀態)餘額、每一匯款交易的證明資訊等。
以區塊鏈交易TX_1為例。區塊鏈交易TX_1的起始狀態餘額為PC(100)、區塊鏈交易TX_1結束狀態餘額為PC(80)、匯款交易tx_11的起始狀態餘額為PC(100)、匯款交易tx_11的交易額為待匯入的PC(10)、匯款交易tx_11的結束狀態餘額為PC(110)、匯款交易tx_11的證明資訊包括PC(10)、PC(110)分別屬於正確數值區間的區間證明，匯款交易tx_12~tx_14的相關內容可以參考圖5，此處不再一一例舉。
需要指出的是：當機構1在該區塊鏈交易中包含的若干匯款交易中作為匯款方或中繼方時，機構1會將自身對應的區塊鏈帳戶Y1的帳戶餘額減去對應的轉帳金額(匯款方僅轉出資金；中繼方既可接收轉入資金又需要轉出資金，這裡是針對轉出資金的操作而描述)，並基於更新後的匯款金額繼續參與後續的匯款交易。當該區塊鏈交易被提交至區塊鏈後，如果機構1作為匯款方或中繼方的某一匯款交易成功執行，機構1無需調整區塊鏈帳戶Y1；如果機構1作為匯款方或中繼方的某一匯款交易未成功執行，機構1需要對區塊鏈帳戶Y1的帳戶餘額進行回滾調節。而當上述的區塊鏈交易中包含機構1作為收款方或中繼方(收款方僅轉入資金；中繼方既可接收轉入資金又需要轉出資金，這裡是針對轉入資金的操作而描述)的匯款交易時，如果該匯款交易成功執行，機構1需要向區塊鏈帳戶Y1中增加相應資金、實現收款，如果匯款交易未成功執行，機構1無需調整區塊鏈帳戶Y1。相應地，區塊鏈節點在收到並處理設備1提交的區塊鏈交易時，可以針對區塊鏈交易所包含的匯款交易是否能夠成功執行，對各個匯款交易進行狀態標記，比如交易為成功狀態、失敗狀態、超時狀態等。
因此，對於上述“區塊鏈交易TX_1的起始狀態餘額為PC(100)”而言，設備1在聚合產生區塊鏈交易TX_1時，並不直接將區塊鏈帳戶Y1的餘額取值設定為區塊鏈交易TX_1的起始狀態餘額，而是需要先判定出設備1先前提交的區塊鏈交易中可能造成金額變化的匯款交易，包括：機構1作為中繼方或收款方的匯款交易被標記為成功狀態時產生的金額增加(收款)、機構1作為匯款方或中繼方的匯款交易被標記為失敗狀態或超時狀態時產生的金額增加(對已扣除的轉帳金額進行回滾)等。以及，設備1進一步根據區塊鏈帳戶Y1的餘額取值(已扣除先前提交的匯款交易的轉帳金額、尚未收款)與上述可能造成金額變化的匯款交易實際產生的金額變化值，計算得到相應的起始狀態餘額為PC(100)；同樣，設備1應當基於該起始狀態餘額PC(100)，分別為區塊鏈交易TX_1包含的各個匯款交易產生相應的區間證明。
再例如，圖6是一示例性實施例提供的一種基於明文數值的區塊鏈交易內容的示意圖。如圖6所示，假定設備1每次選取4個匯款交易並聚合為一筆區塊鏈交易，比如匯款交易tx_11、tx_12、tx_13、tx_14被聚合為區塊鏈交易TX_1，匯款交易tx_21、tx_22、tx_23、tx_24被聚合為區塊鏈交易TX_2，匯款交易tx_31、tx_32、tx_33、tx_34被聚合為區塊鏈交易TX_3。在設備1產生的每一區塊鏈交易中，分別包含設備1設定的順序編號seq和與各個匯款交易相關的資訊。
其中，順序編號seq的作用與圖5所示實施例相同，此處不再贅述。與各個匯款交易相關的資訊可以包括：區塊鏈交易的起始狀態餘額、區塊鏈交易的結束狀態餘額、每一匯款交易的交易額；而由於採用明文資料的原因，因此不再需要圖5所示實施例中的每一匯款交易的起始狀態餘額、每一匯款交易的結束狀態(即臨時狀態)餘額、每一匯款交易的證明資訊等內容，區塊鏈節點直接根據各個明文數值進行比較或計算即可。
步驟404b-c，設備2-3根據本地佇列2-3中的匯款交易，分別聚合產生交易TX_b、TX_c，並在簽名後分別提交至區塊鏈。
在一實施例中，與設備1相類似的，設備2可以從本地佇列2中選取一個或多個匯款交易，以聚合產生相應的區塊鏈交易。假定設備2在某一次選取的匯款交易中包含上述的匯款交易tx_i，並據此產生了相應的區塊鏈交易TX_b。
在一實施例中，與設備1相類似的，設備3可以從本地佇列3中選取一個或多個匯款交易，以聚合產生相應的區塊鏈交易。假定設備3在某一次選取的匯款交易中包含上述的匯款交易tx_i，並據此產生了相應的區塊鏈交易TX_c。
步驟404d，設備4根據本地佇列4中的匯款交易，分別聚合產生交易TX_d，並在簽名後提交至區塊鏈。
在一實施例中，與設備1相類似的，設備4可以從本地佇列4中選取一個或多個匯款交易，以聚合產生相應的區塊鏈交易。假定設備4在某一次選取的匯款交易中包含上述的匯款交易tx_i，並據此產生了相應的區塊鏈交易TX_d。
需要指出的是：設備1~設備4可以根據實際情況選擇產生相應的區塊鏈交易，而並不一定立即對匯款交易tx_i進行處理；換言之，設備1~設備4實際上是非同步地向區塊鏈提交匯款交易tx_i(被包含於相應的區塊鏈交易中)，使得該匯款交易tx_i的執行被分配至由設備1~設備4分別進行觸發，促使設備1~設備4在參與大量匯款交易的情況下，可以對所參與的匯款交易進行批量產生區塊鏈交易，從而減少區塊鏈交易的產生和提交數量，有助於降低處理負擔、提升處理效率。
步驟405，區塊鏈節點對收到的區塊鏈交易進行處理，以驗證區塊鏈交易中包含的各筆匯款交易。
步驟406，標記匯款交易tx_i。
在一實施例中，由於每一機構會不斷向區塊鏈提交區塊鏈交易，而在先提交的區塊鏈交易所包含的匯款交易，會影響在後提交的區塊鏈交易所包含的匯款交易，因而區塊鏈節點在接收每一機構提交的區塊鏈交易後，需要讀取所接收到的區塊鏈交易中包含的順序編號seq，並按照順序編號seq的大小，依次處理來自相應機構的區塊鏈交易。例如，當區塊鏈節點接收到設備1提交的區塊鏈交易TX_a時，讀取其中包含的順序編號seq為100；而如果區塊鏈節點已處理的最近一筆區塊鏈交易的順序編號seq為98，那麼區塊鏈節點需要等待設備1提交的順序編號seq為99的區塊鏈交易，並在該順序編號為99的區塊鏈交易被處理後，才對上述順序編號為100的區塊鏈交易進行處理。
在一實施例中，區塊鏈節點在收到設備1~4分別提交的區塊鏈交易後，可以分別提取每一區塊鏈交易中包含的匯款交易，並分別針對每一匯款交易實施單獨驗證。驗證操作可以包括：驗證簽名是否正確；驗證匯款交易中對於上述“可能造成金額變化的匯款交易”實際產生的金額變化值的計算是否正確、區間證明是否正確；資金轉移的轉出額與轉入額是否一致等，此處不再一一贅述。
在一實施例中，除了對每一區塊鏈交易中包含的匯款交易單獨實施驗證之外，如果匯款交易的執行由匯款方、中繼方、收款方等參與方同時參與觸發，因而區塊鏈節點還需要驗證匯款交易的各個參與方是否都實施了觸發(即提交了包含該匯款交易的區塊鏈交易)。例如，圖7是一示例性實施例提供的一種統計觸發情況的示意圖。如圖7所示，基於區塊鏈的原生功能或智慧合約所提供的擴展功能，區塊鏈節點可以分別記錄機構1~機構4所提交的區塊鏈交易，比如機構1提交的區塊鏈交易TX_a、TX_*，機構2提交的區塊鏈交易TX_*、TX_b、TX_#，機構3提交的區塊鏈交易TX_*、TX_c，機構4提交的區塊鏈交易TX_d等；以及，區塊鏈節點可以提取出各個區塊鏈交易中包含的匯款交易，並分別針對各個匯款交易的參與方(匯款交易詳情中包含匯款方、中繼方、收款方的資訊)進行統計：當收到相應參與方提交的區塊鏈交易中包含該匯款交易，且該匯款交易通過了上述的單獨驗證時，可以將該參與方標記為“OK”。
比如，由於設備1提交的區塊鏈交易TX_a中包含匯款交易tx_i，如果區塊鏈交易TX_a中對應於匯款交易tx_i的內容通過驗證，那麼區塊鏈節點可以標記為如圖6所示的“Y1:OK”；類似地，如果區塊鏈節點還分別針對機構2~機構4標記為“Y2:OK”、“Y3:OK”、“Y4:OK”等，那麼區塊鏈節點可以判定該匯款交易tx_i已經得到所有參與方的確認，可以將該匯款交易tx_i標記為成功狀態。
再比如，由於僅設備1、設備2和設備3提交的區塊鏈交易中包含匯款交易tx_*的相關資訊，因而即便這些資訊都已經通過單獨驗證，區塊鏈節點仍然僅能夠為該匯款交易tx_*添加標記“Y1:OK”、“Y2:OK”、“Y3:OK”，而需要繼續等待設備4提交的區塊鏈交易。
又比如，由於僅設備2提交的區塊鏈交易中包含匯款交易tx_#的相關資訊，因而即便相關資訊已經通過單獨驗證，區塊鏈節點仍然僅能夠為該匯款交易tx_#添加標記“Y2:OK”，而需要繼續等待設備1、設備3和設備4提交的區塊鏈交易。
仍以匯款交易tx_i為例，如果機構1~機構4中的任一參與方未能夠在交易時刻到達之前提交包含該匯款交易tx_i的區塊鏈交易，那麼區塊鏈節點會將該匯款交易tx_i標記為超時狀態，使其無法被成功執行。如果機構1~機構4中的任一參與方雖然提及了包含該匯款交易tx_i的區塊鏈交易，但由於金額累加詳情出錯或區間證明出錯等原因而未通過單獨驗證，那麼區塊鏈節點會將該匯款交易tx_i標記為失敗狀態，使其無法被成功執行。
當匯款交易tx_i或其他匯款交易被區塊鏈節點添加了成功狀態、失敗狀態或超時狀態等標記時，機構1~機構4在後續產生區塊鏈交易時，可以參考這些狀態產生相應的金額累加詳情、產生餘額充足的區間證明等，這與上文中在步驟404a~404d中描述的過程相類似，此處不再贅述。
在確認匯款交易tx_i被成功執行後，機構1在鏈外收取用戶1的500港幣、向機構2轉出500港幣，機構2收取機構1轉入的500港幣、向機構3轉出56歐元，機構3收取機構2轉入的56歐元、向機構4轉出64美元，機構4收取機構3轉入的64美元、在鏈外向用戶1轉入64美元，相當於機構1~4收支平衡、由用戶1向用戶2完成了500港幣的匯款操作。
而表現在區塊鏈帳本上的資料變化為：機構1對應的區塊鏈帳戶Y1更新為(currency_1, PC(a-t1, r_a-r_t1), Enc_A(a-t1), Enc_A(r_a-r_t1))、減少了500港幣；機構2對應的區塊鏈帳戶Y2更新為：(currency_1, PC(b1+t1, r_b1+r_t1), Enc_B(b1+t1), Enc_B(r_b1+r_t1))、
(currency_2, PC(b2-t2, r_b2-r_t2), Enc_B(b2-t2), Enc_B (r_b2-r_t2))，增加了500港幣、減少了56歐元；機構3對應的區塊鏈帳戶Y3更新為：(currency_2, PC(c1+t2, r_c1+r_t2), Enc_C(c1+t2), Enc_C(r_c1+r_t2))、
(currency_3, PC(c2-t3, r_c2-r_t3), Enc_C(c2-t3), Enc_C (r_c2-r_t3))，增加了56歐元、減少了64美元；機構4對應的區塊鏈帳戶Y4更新為：(currency_3, PC(d+t3, r_d+r_t3), Enc_D(d+t3), Enc_D(r_d+r_t3))、增加了64美元。
需要指出的是：設備1~設備4所提交的區塊鏈交易中，並不一定每條匯款交易都由所有參與方共同實施觸發操作；譬如，至少一條匯款交易可以採用相關技術中的技術方案，即由某一參與方收集所有參與方對匯款交易的交易詳情資訊的確認資訊、產生交易所需的區間證明等(即產生上述實施例中所述的多方觸發資訊)，並僅由該某一參與方提交包含該匯款交易的區塊鏈交易。
圖8是一示例性實施例提供的一種設備的示意結構圖。請參考圖8，在硬體層面，該設備包括處理器802、內部匯流排804、網路介面806、記憶體808以及非揮發性記憶體810，當然還可能包括其他業務所需要的硬體。處理器802從非揮發性記憶體810中讀取對應的電腦程式到記憶體808中然後運行，在邏輯層面上形成基於區塊鏈的事件處理裝置。當然，除了軟體實現方式之外，本說明書一個或多個實施例並不排除其他實現方式，比如邏輯裝置抑或軟硬體結合的方式等等，也就是說以下處理流程的執行主體並不限定於各個邏輯單元，也可以是硬體或邏輯裝置。
請參考圖9，在軟體實施方式中，該基於區塊鏈的事件處理裝置應用於參與方，可以包括：
添加單元901，根據所述參與方所參與的事件，向所述參與方維護的等待佇列中添加對應的備選子交易；
產生單元902，根據從所述等待佇列中選取的若干備選子交易，產生相應的集合交易；
提交單元903，將所述集合交易提交至區塊鏈，使所述集合交易中的備選子交易被分別予以處理。
可選的，所述產生單元902具體用於：
當所述等待佇列中的備選子交易達到預設數量時，選取所述等待佇列中已存在的備選子交易，以產生相應的集合交易；
或者，按照預設時長週期性地選取所述等待佇列中已存在的備選子交易，以產生相應的集合交易。
可選的，還包括：
添加單元904，按照產生順序為各個集合交易添加相應的編號，以使各個集合交易在區塊鏈中被按照對應的編號大小進行依次處理。
可選的，所述集合交易中包含的備選子交易設定有對應的狀態變化量，使得所述備選子交易被處理後，所述參與方的狀態參數基於所述狀態變化量而發生相應的數值變化。
可選的，所述狀態變化量為明文數值。
可選的，所述集合交易中包含的備選子交易還設定有變化前狀態值、變化後狀態值，使得所述備選子交易被處理後，所述參與方的狀態參數由所述變化前狀態值經由所述狀態變化量而變化至所述變化後狀態值；
其中，所述狀態變化量、所述變化前狀態值和所述變化後狀態值分別為基於同態加密演算法或同態承諾演算法計算得到的密文數值。
可選的，
當被選取的備選子交易用於使所述參與方的狀態值增大時，所述集合交易還包含：第一證明資訊，所述第一證明資訊用於證明狀態值增大量處於正確數值區間；
當被選取的備選子交易用於使所述參與方的狀態值減小時，所述集合交易還包含：第二證明資訊，所述第二證明資訊用於證明狀態值減小量、所述被選取的備選子交易對應的變化後狀態值均處於所述正確數值區間。
可選的，當所述集合交易包含多個備選子交易時，相鄰的備選子交易滿足：前一備選子交易對應的變化後狀態值與後一備選子交易對應的變化前狀態值相同。
可選的，在所述事件對應的備選子交易中，包含所述參與方對所述事件的單方觸發資訊；其中，當所述事件的所有參與方分別向區塊鏈提交的針對所述事件的單方觸發資訊均通過驗證時，所述事件對應的備選子交易在區塊鏈中被觸發執行。
可選的，在所述事件對應的備選子交易中，包含所述事件的所有參與方對所述事件的多方觸發資訊；其中，當所述多方觸發資訊通過驗證時，所述事件對應的備選子交易在區塊鏈中被觸發執行。
圖10是一示例性實施例提供的一種設備的示意結構圖。請參考圖10，在硬體層面，該設備包括處理器1002、內部匯流排1004、網路介面1006、記憶體1008以及非揮發性記憶體1010，當然還可能包括其他業務所需要的硬體。處理器1002從非揮發性記憶體1010中讀取對應的電腦程式到記憶體1008中然後運行，在邏輯層面上形成基於區塊鏈的事件處理裝置。當然，除了軟體實現方式之外，本說明書一個或多個實施例並不排除其他實現方式，比如邏輯裝置抑或軟硬體結合的方式等等，也就是說以下處理流程的執行主體並不限定於各個邏輯單元，也可以是硬體或邏輯裝置。
請參考圖11，在軟體實施方式中，該基於區塊鏈的事件處理裝置應用於區塊鏈節點，可以包括：
接收單元1101，接收參與方提交至區塊鏈的集合交易，所述集合交易中包含從所述參與方維護的等待佇列中選取的若干備選子交易，所述備選子交易對應於所述參與方所參與的事件；
執行單元1102，執行所述集合交易，以對所述集合交易中的備選子交易分別予以處理。
可選的，還包括：
提取單元1103，提取所述集合交易中包含的編號，所述編號由所述參與方按照產生順序而添加；
處理單元1104，按照對應的編號大小對所述參與方提交的各個集合交易進行依次處理。
可選的，所述集合交易中包含的備選子交易設定有對應的狀態變化量，使得所述備選子交易被處理後，所述參與方的狀態參數基於所述狀態變化量而發生相應的數值變化。
可選的，所述狀態變化量為明文數值。
可選的，所述集合交易中包含的備選子交易還設定有變化前狀態值、變化後狀態值，使得所述備選子交易被處理後，所述參與方的狀態參數由所述變化前狀態值經由所述狀態變化量而變化至所述變化後狀態值；
其中，所述狀態變化量、所述變化前狀態值和所述變化後狀態值分別為基於同態加密演算法或同態承諾演算法計算得到的密文數值。
可選的，
當被選取的備選子交易用於使所述參與方的狀態值增大時，所述集合交易還包含：第一證明資訊，所述第一證明資訊用於證明狀態值增大量處於正確數值區間；
當被選取的備選子交易用於使所述參與方的狀態值減小時，所述集合交易還包含：第二證明資訊，所述第二證明資訊用於證明狀態值減小量、所述被選取的備選子交易對應的變化後狀態值均處於所述正確數值區間。
可選的，當所述集合交易包含多個備選子交易時，相鄰的備選子交易滿足：前一備選子交易對應的變化後狀態值與後一備選子交易對應的變化前狀態值相同。
可選的，在所述事件對應的備選子交易中，包含所述參與方對所述事件的單方觸發資訊；其中，當所述事件的所有參與方分別向區塊鏈提交的針對所述事件的單方觸發資訊均通過驗證時，所述事件對應的備選子交易在區塊鏈中被觸發執行。
可選的，在所述事件對應的備選子交易中，包含所述事件的所有參與方對所述事件的多方觸發資訊；其中，當所述多方觸發資訊通過驗證時，所述事件對應的備選子交易在區塊鏈中被觸發執行。
上述實施例闡明的系統、裝置、模組或單元，具體可以由電腦晶片或實體實現，或者由具有某種功能的產品來實現。一種典型的實現設備為電腦，電腦的具體形式可以是個人電腦、膝上型電腦、蜂巢式電話、相機電話、智慧型電話、個人數位助理、媒體播放機、導航設備、電子郵件收發設備、遊戲控制台、平板電腦、可穿戴設備或者這些設備中的任意幾種設備的組合。
本說明書提出了一種電腦可讀媒體，其上儲存有電腦指令，該指令被處理器執行時實現本說明書的技術方案，比如上述任一實施例的基於區塊鏈的事件處理方法，此處不再一一贅述。
在一個典型的配置中，電腦包括一個或多個處理器(CPU)、輸入/輸出介面、網路介面和記憶體。
記憶體可能包括電腦可讀媒體中的非永久性記憶體，隨機存取記憶體(RAM)和/或非揮發性記憶體等形式，如唯讀記憶體(ROM)或快閃記憶體(flash RAM)。記憶體是電腦可讀媒體的示例。
電腦可讀媒體包括永久性和非永久性、可移動和非可移動媒體可以由任何方法或技術來實現資訊儲存。資訊可以是電腦可讀指令、資料結構、程式的模組或其他資料。電腦的儲存媒體的例子包括，但不限於相變記憶體(PRAM)、靜態隨機存取記憶體(SRAM)、動態隨機存取記憶體(DRAM)、其他類型的隨機存取記憶體(RAM)、唯讀記憶體(ROM)、電可擦除可程式設計唯讀記憶體(EEPROM)、快閃記憶體或其他記憶體技術、唯讀光碟唯讀記憶體(CD-ROM)、數位多功能光碟(DVD)或其他光學儲存、磁盒式磁帶、磁片儲存、量子記憶體、基於石墨烯的儲存媒體或其他磁性儲存設備或任何其他非傳輸媒體，可用於儲存可以被計算設備存取的資訊。按照本文中的界定，電腦可讀媒體不包括暫存電腦可讀媒體(transitory media)，如調變的資料信號和載波。
還需要說明的是，術語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、商品或者設備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、商品或者設備所固有的要素。在沒有更多限制的情況下，由語句“包括一個……”限定的要素，並不排除在包括所述要素的過程、方法、商品或者設備中還存在另外的相同要素。
上述對本說明書特定實施例進行了描述。其它實施例在所附申請專利範圍的範圍內。在一些情況下，在申請專利範圍中記載的動作或步驟可以按照不同於實施例中的順序來執行並且仍然可以實現期望的結果。另外，在圖式中描繪的過程不一定要求示出的特定順序或者連續順序才能實現期望的結果。在某些實施方式中，多工處理和並行處理也是可以的或者可能是有利的。
在本說明書一個或多個實施例使用的術語是僅僅出於描述特定實施例的目的，而非旨在限制本說明書一個或多個實施例。在本說明書一個或多個實施例和所附申請專利範圍中所使用的單數形式的“一種”、“所述”和“該”也旨在包括多數形式，除非上下文清楚地表示其他含義。還應當理解，本文中使用的術語“和/或”是指並包含一個或多個相關聯的列出專案的任何或所有可能組合。
應當理解，儘管在本說明書一個或多個實施例可能採用術語第一、第二、第三等來描述各種資訊，但這些資訊不應限於這些術語。這些術語僅用來將同一類型的資訊彼此區分開。例如，在不脫離本說明書一個或多個實施例範圍的情況下，第一資訊也可以被稱為第二資訊，類似地，第二資訊也可以被稱為第一資訊。取決於語境，如在此所使用的詞語“如果”可以被解釋成為“在……時”或“當……時”或“回應於判定”。
以上所述僅為本說明書一個或多個實施例的較佳實施例而已，並不用以限制本說明書一個或多個實施例，凡在本說明書一個或多個實施例的精神和原則之內，所做的任何修改、等同替換、改進等，均應包含在本說明書一個或多個實施例保護的範圍之內。
The exemplary embodiments will be described in detail here, and examples thereof 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 implementation manners described in the following exemplary embodiments do not represent all implementation manners consistent with one or more embodiments of this specification. On the contrary, they are only examples of devices and methods consistent with some aspects of one or more embodiments of this specification as detailed in the scope of the appended application. It should be noted that in other embodiments, the steps of the corresponding method may not be executed in the order shown and described in this specification. In some other embodiments, the method includes 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 event processing method provided by an exemplary embodiment. As shown in FIG. 1, the method is applied to participants and may include the following steps: Step 102, according to the events in which the participants participate, add corresponding candidate sub-transactions to the waiting queue maintained by the participants. In one embodiment, there are multiple participants in the event, and each participant corresponds to a participating object. The participating object may be an individual, an enterprise, an organization, etc., and this specification does not limit this. The participating object has a corresponding digital identity, so that the electronic device carrying the digital identity is equivalent to being configured as a participant corresponding to the participating object. In an embodiment, the events in this specification may include any type and cover any scene, such as voting, signing of an agreement, traffic distribution, transfer, cross-border remittance, etc. This specification does not limit this. Taking voting as an example, the description information can include information such as the reason for voting and voting options, and the trigger information submitted by each participant to the blockchain can include the results of the selection of the voting options, thereby triggering the completion of the voting operation. In one embodiment, the candidate sub-transaction includes event description information, and the description information is used to describe the situation of the related event, so that when the candidate sub-transaction is processed, the corresponding event can be implemented based on the description information. For example, the description information can characterize the execution logic of the relevant event, the involved parties, the way of changing the state parameters of the participants (such as increasing or decreasing the value of the state parameter), the amount of change, etc. This specification does not refer to this Make restrictions. In fact, the relevant content of the event can be communicated in advance through any means between the participating parties, and then any one of the participating parties drafts the description of the event, so that other parties to the event can communicate with each other based on the results of the prior communication. The content of the description information can be viewed and confirmed; of course, any of the participants can also determine the other participants of the event and other content in the description information without communicating in advance. This manual does not limit this . In one embodiment, the description information of the event can be generated by any participant of the event and added as a candidate sub-transaction in the waiting queue maintained by the any participant. And, any participant will also share the generated description information to other participants, so that other participants can confirm the description information. In one embodiment, any participant can send the description information to other participants of the event through an off-chain channel. The description information is sent to other participants of the event through the off-chain channel, which can realize the efficient transmission of the description information. Among them, the off-chain channel can be an encrypted channel or other form of secret channel established between various participants in the event to avoid information leakage. In an embodiment, any participant can submit a transaction to the blockchain and include the above description information in the transaction, so that the transaction can be sent to all areas in the blockchain after consensus. Blockchain node; and each participant of the event can be configured as a blockchain node in the blockchain, or each participant can have a corresponding blockchain node in the blockchain, so that each participant The above-mentioned transactions and the description information contained therein can be obtained through the blockchain ledger maintained by itself or by the corresponding blockchain node (the blockchain ledger contains the full transaction data of the blockchain), so as to make the above-mentioned description information The other parties that are synchronized to the event. Step 104: Generate a corresponding collective transaction based on several candidate sub-transactions selected from the waiting queue. In one embodiment, the collective transaction may include multiple candidate sub-transactions, and each candidate sub-transaction corresponds to an event in which the above-mentioned participant participates, so that after the collective transaction is submitted to the blockchain, it contains Multiple alternative sub-transactions of can be processed in the blockchain, so that multiple events corresponding to these alternative sub-transactions are implemented. It can be seen that by including multiple candidate sub-transactions in the collective transaction, these candidate sub-transactions are submitted to the blockchain in batches, which can reduce the number of transactions submitted to the blockchain, without generating for each candidate sub-transaction A blockchain transaction can help reduce resource consumption and improve processing efficiency. In an embodiment, when the candidate sub-transactions in the waiting queue reach a preset number, the candidate sub-transactions that already exist in the waiting queue (that is, the preset number of candidate sub-transactions) may be selected , To generate the corresponding collective transaction. In another embodiment, the existing candidate sub-transactions in the waiting queue can be periodically selected according to the preset duration to generate corresponding collective transactions; of course, the capacity of each collective transaction may have a maximum limit , So that the number of candidate subtransactions selected in the same period has a corresponding maximum value, and the excess part can be postponed to the next period for selection. Of course, alternative sub-transactions can also be selected through other preset rules, which are not restricted in this manual. In an embodiment, the candidate sub-transactions in the waiting queue can be arranged in sequence according to the time of addition, and each candidate sub-transaction can be selected from front to back each time, so that the candidate sub-transactions generated earlier can be selected first . Of course, the participants can also select the candidate sub-transactions in the waiting queue regardless of the order according to actual needs, such as the urgency of the event, the priority of the event, etc.; or, the waiting queue itself can follow the above The urgency, priority, etc. are arranged so that it can still be regarded as sequential selection. In an embodiment, the participant may add a number to each merged transaction in the order of generation, so that each merged transaction is processed in the blockchain according to the size of the corresponding number. In other words, after receiving the merged transaction submitted by the participants, the blockchain transaction needs to read the serial number contained in the merged transaction; if the serial number is continuous with the serial number of the previously processed merged transaction, for example, the serial number of the newly processed merged transaction is 99, The number of the currently received consolidated transaction is 100, then the consolidated transaction numbered 100 can be processed; if the numbers are not consecutive, for example, the number of the newly processed consolidated transaction is 99, and the number of the currently received consolidated transaction If the number is 101, the blockchain node needs to wait and process the merged transaction numbered 100 first, and then process the merged transaction numbered 101. Since the execution of each transaction may cause the state parameters of the participant to change, and the execution of subsequent transactions needs to depend on the value of the state parameters after the execution of the previous transaction, it is necessary to ensure that each combined transaction is numbered according to the corresponding number. The sizes are processed in sequence so that each combined transaction can be executed correctly. Step 106: Submit the collective transaction to the blockchain, so that the candidate sub-transactions in the collective transaction are processed separately. In one embodiment, the candidate sub-transaction corresponding to the event includes multi-party trigger information of all participants of the event; wherein, when the multi-party trigger information is verified, the event The corresponding candidate sub-transaction is triggered and executed in the blockchain. Multi-party trigger information represents the recognition of all participants in the event for the description information and hope to trigger the execution of the event. For example, after any participant in an event generates description information and sends it to other participants, the other participants can confirm the content of the description information, generate a signature on the description information with their own identity key, and return the signature to any participant The multi-party trigger information can include the signatures generated by each participant describing the information and the event; each signature belongs to the confirmation information provided by the corresponding participant, and if the cipher text value is used, the confirmation information will also include the encryption The proof information of the text value, which will be described in detail below. In short, in this embodiment, after any participant of the event organizes the formation of multi-party trigger information, it only needs to add the corresponding candidate sub-transaction to the waiting queue maintained by any participant, and submit it to the blockchain containing this A collective transaction of alternative sub-transactions, and other participants do not need to implement similar processing; accordingly, the blockchain node can process the alternative sub-transaction submitted by any one of the participants after the multi-party trigger information is verified. In one embodiment, the candidate sub-transaction corresponding to the event includes the unilateral trigger information of the participant on the event; wherein, when all the participants of the event submit to the blockchain the information for the When the unilateral trigger information of the event is verified, the candidate sub-transaction corresponding to the event is triggered to be executed in the blockchain. The unilateral trigger information indicates that the corresponding participant confirms the description information of the event and hopes to trigger the execution of the event; and each participant of the event needs to submit the unilateral trigger information to the blockchain separately, so that the blockchain node is based on all participants The separately submitted unilateral trigger information determines whether the event specified by the corresponding alternative sub-exchange should be executed. For example, after any participant of an event generates description information and provides it to other participants, not only does any participant need to add corresponding candidate sub-transactions to the waiting queue maintained by itself, each other participant is After the information is confirmed, the corresponding candidate sub-transactions are added to the waiting queue maintained by itself; and each participant generates a collective transaction based on the waiting queue maintained by itself, thereby submitting the collective transaction to the block Chain, so that the above-mentioned unilateral trigger information is submitted to the blockchain for verification by the blockchain nodes. The unilateral trigger information can include the description information and the signature generated by the corresponding participant on the description information; the signature belongs to the confirmation information provided by the corresponding participant, and if the cipher text value is used, the confirmation information also contains the certification information, which will be described in detail below. By submitting single-party trigger information to the blockchain by each participant separately, instead of submitting multi-party trigger information by a single participant, not only can the processing pressure be shared, and the processing pressure of a single participant can be prevented from being excessive, but also each participant can be based on The actual situation of its own (such as processing pressure, priority management, etc.) selectively handles or even batches each event involved. In an embodiment, the description information of the event may include the amount of change, and the event may be used to make the state parameters correspondingly recorded on the blockchain by each participant change according to the amount of change, such as increasing the value Value, decrease the value, etc. Among them, the corresponding state parameters may be different according to the type of the event or the difference in the scene. For example, the state parameter in the transfer or cross-border remittance scenario can be the account balance of the participant, and the state parameter in the traffic distribution scenario can be the participant. This manual does not limit the amount of remaining flow held. In an embodiment, the value of the state parameter corresponding to each participant and the change amount may be a plain text value. Each blockchain node in the blockchain maintains a blockchain ledger, which records all transaction data, so that the blockchain node can learn the value of the state parameter corresponding to each participant; further Ground, any one of the participants can submit a transaction to the blockchain, and the transaction includes the trigger information mentioned above, so that the transaction can be based on the value of the state parameter corresponding to any one of the participants, the above The change amount is executed, so that the state parameter corresponding to any participant can realize a value change based on the change amount. In an embodiment, the value of the state parameter corresponding to each participant and the change amount are respectively a ciphertext value calculated based on a homomorphic encryption algorithm or a homomorphic commitment algorithm. For the homomorphic encryption algorithm, any type of homomorphic encryption algorithm can be used, as long as the homomorphic encryption algorithm can meet the additive homomorphism, so that even in the ciphertext state, the value of the state parameter can still be obtained Increase or decrease the amount of change; for the homomorphic encryption algorithm being additive homomorphic encryption algorithm or fully homomorphic encryption algorithm, this specification does not limit this. For the homomorphic commitment algorithm, when the Pedersen commitment mechanism in related technologies is used, a random number can be determined for unencrypted data, and the corresponding commitment data can be calculated based on the random number and the unencrypted data. The commitment data Can be used as the above-mentioned ciphertext value. In one embodiment, when the value and change of the state parameter are ciphertext values, the participants need to provide relevant proof information so that the blockchain node can determine the legality of the transaction when executing the relevant transaction. For example, the participant needs to provide a proof of the change to show that the change is in the correct numerical range, such as [0, 2 64 ). For another example, when an event is used to reduce the value of the state parameter corresponding to a certain participant according to the amount of change, that is, the purpose of the transaction is to reduce the value of the state parameter of the certain party by the amount of change. A participant needs to provide proof of the value and change of the state parameter to show that the value of the state parameter is not less than the value reduction (the value reduction is equivalent to the above-mentioned change). In one embodiment, a range proof technique in related technologies, such as the Bulletproofs scheme or the Borromean ring signature scheme, can be used to generate the above-mentioned proof information, which is not limited in this specification. In one embodiment, when any participant generates description information, the amount of change in the description information may be a cipher text value. For example, when the plaintext value of the change is t1, if the Pedersen commitment mechanism is adopted, the corresponding ciphertext promise T1 can be generated based on the plaintext value t1 and the random number r1, and the description information can include the T1, t1, and r1, so that the event Other participants in can verify the correspondence between the ciphertext commitment T1 and the plaintext value t1 and the random number r1. Among them, the plaintext value t1 and random number r1 can be encrypted and protected in the description information. For example, when the description information needs to be sent to the participant X, the identity public key corresponding to the digital identity of the participant X can be used for encryption, respectively. The encrypted Enc_X(t1) and Enc_X(r1) are added to the description information, so only the participant X can decrypt Enc_X(t1) and Enc_X(r1) with their own identity private key to obtain the above-mentioned plaintext values t1 and Random number r1 significantly improves data security. Of course, in addition to the public key encryption method, any other encryption methods in related technologies, such as digital envelopes, can also be used, and this specification does not limit this. In one embodiment, when there are multiple other participants, the description information may respectively include encrypted data corresponding to each of the other participants. For example, when the other parameter parties include participant X and participant Y, the plaintext value t1 and random number r1 can be respectively encrypted according to the identity public key of the participant X to obtain Enc_X(t1), Enc_X(r1), and according to the participants Y’s identity public key encrypts the plaintext value t1 and the random number r1 to obtain Enc_Y(t1), Enc_Y(r1), and adds Enc_X(t1), Enc_X(r1), Enc_Y(t1) and Enc_Y(r1) to In the description information, any one participant only needs to prepare one description information and send it to each other participant separately, instead of preparing different description information for each other participant. Of course, any one of the participants can prepare different description information for each other participant. For example, the description information sent to participant X includes Enc_X(t1) and Enc_X(r1), and it is sent to participant Y. The description information of contains Enc_Y(t1) and Enc_Y(r1), which are not restricted in this manual. In an embodiment, for the change amount of the ciphertext state included in the description information, the collective transaction may include first proof information, which is used to prove that the change amount is in the correct numerical range. When any participant generates the description information of the event, the any participant can also generate the first proof information, so that no matter whether it is generating multi-party trigger information or single-party trigger information, it does not require other participation policies to value the change amount And generate other certification information. Of course, each participant can also generate the corresponding amount of change (the amount of change corresponding to each participant may be different; for example, in a cross-border remittance scenario, the value of the amount of change may differ based on different currency types). One proof information, this manual does not limit it. In an embodiment, if the event is used to reduce the value of the state parameter corresponding to a certain participant of the event (there may be multiple similar participants) according to the change amount, then the collective transaction needs to include The second proof information is used to prove that the value of the state parameter corresponding to the certain participant is not less than the value decrease. For multi-party trigger information, each participant in the event can respectively generate corresponding second proof information and provide it to any of the above when determining that its own state parameter will decrease in value according to the change amount. Participants are organized by any participant to form multi-party trigger information; or, any participant can generate the second proof information in a unified manner, without the need for each participant to generate it separately. For unilateral trigger information, the participant that generates the unilateral trigger information can generate second proof information for itself. In one embodiment, when a participant generates the second proof information for itself, the participant first updates the value of its corresponding state parameter according to other events it participated in, and then updates the state according to the value. The parameter generates the second proof information. For example, when the value and change amount of the state parameter are cipher text values, and the event is used to make the state parameter corresponding to the participant decrease in value according to the change amount, the participant needs to be based on the previously processed transaction , To determine the value of the state parameter corresponding to itself, so as to generate the correct second proof information to ensure that the related event can be executed smoothly. For example, after receiving the collective transaction submitted by each participant, the blockchain node extracts the candidate sub-transactions included in the collective transaction, and confirms the trigger information (multi-party trigger information or single-party trigger information) contained in the candidate sub-transaction And verification. When the multi-party trigger information contains the confirmation information corresponding to all the participants of the event, or all the participants of the event have submitted the corresponding one-party trigger information (each one-party trigger information contains the confirmation information of the corresponding participant), if If the multi-party trigger information or all the single-party trigger information have passed the verification, the event can be marked as a success state; similarly, the event that fails the verification can be marked as a failure state, and all events that have not been received within the valid time period The event of the confirmation information corresponding to the participant is marked as a timeout status, etc., and then the status of each event is submitted to the blockchain. Take a participant of an event as an example. Before submitting a collective transaction, the participant can check the transaction records on the blockchain ledger to determine the status of each event that it participated in, such as failure status or timeout status. For transactions, the value of the status parameter needs to be restored accordingly (for example, when the participant is the remittance party, the corresponding account balance needs to be rolled back), and the status parameter needs to be updated for the successful transaction (for example, the participant is the receiver At the time of payment, the corresponding transfer amount needs to be collected and added to the account balance), and then based on the updated value of the status parameter, the second proof information of the relevant event is generated (to ensure that the second proof information is based on the status parameter The latest value is generated), and then the above collective transaction is generated and submitted. In an embodiment, when the event includes a transfer event, the participants in the event include: the remittance party and the receiver, the change amount includes: the transfer amount, and the state parameter includes: the account balance; in other words, It is equivalent to the transfer operation from the remittance to the recipient, so that the remittance's account balance decreases by the corresponding transfer amount, and the recipient's account balance increases the corresponding transfer amount. For example, the description information can include the account address of the sender, the account address of the recipient, the transfer amount (commitment value), the transfer amount in plain text (encrypted state), random numbers (encrypted state), etc., to indicate The account address transfers the transfer amount to the payee's account address. In an embodiment, when the event includes the first remittance event, participants in the event include: a remittance party, a relay party, and a remittance party, and the amount of change includes: the remittance party and the middle party. The first transfer amount based on the first type of assets between the relay parties, and the second transfer amount based on the second type of assets between the relay party and the payee, the state parameters include: account balance; in other words, It is equivalent to transferring the first type of assets (such as Hong Kong dollars) between the sender and the relay party, the asset amount is the first transfer amount, and the second type of assets (such as US dollars) is transferred between the relay party and the recipient ), the asset amount is the second transfer amount, and according to the exchange rate between the first and second types of assets, the asset value corresponding to the first transfer amount and the second transfer amount is basically the same, then it is ultimately equivalent to the remittance party’s The account balance decreases by the first transfer amount (the first type of assets), the recipient's account balance increases by the second transfer amount (the second type of assets), and the relay party’s account balance increases by the first transfer amount ( The first type of assets) and the reduction of the second transfer amount (the second type of assets), the asset value is equivalent to unchanged. In an embodiment, when the event includes the second remittance event, the participants of the event include: the remittance party, n relay parties, and the remittance party, and the change amount includes: the remittance party and the first remittance party. The transfer amount between 1 relay party based on the first type of asset, the transfer amount between the i-1th relay party and the i-th relay party based on the i-th type asset, the nth relay party and all The transfer amount between the payees based on the n+1 type asset, the state parameter includes: account balance; where 1<i≤n. When n=1, the second remittance event in this embodiment is equivalent to the first remittance event in the foregoing embodiment, and will not be repeated here. When n>1, because there are multiple relay parties, compared with the first remittance event in the above embodiment, it also includes the asset transfer process between multiple relay parties; taking n=2 as an example, The participants in the event include the remitter, the relay party 1, the relay party 2, and the recipient. Among them, the first type of assets (such as Hong Kong dollars) is transferred between the remitter and the relay party 1, and the amount of assets is the first Transfer amount, transfer the second type of assets (such as Euro) between relay party 1 and relay party 2, the asset amount is the second transfer amount, transfer the third type of asset between relay party 2 and the payee Assets (such as US dollars) and the amount of assets are the third transfer amount, and the first transfer is based on the exchange rate between the first and second types of assets 1, the exchange rate between the second and third types of assets 2 The asset value corresponding to the amount, the second transfer amount and the third transfer amount are basically the same, so in the end, the account balance of the remitter is reduced by the first transfer amount (the first type of assets), and the account balance of the recipient increases by the first transfer amount. Three transfer amount (the third type of assets), and the account balance of the relay party 1 increases the first transfer amount (the first type of assets) and reduces the second transfer amount (the second type of assets), and the value of the assets The above is equivalent to no change. The account balance of relay party 2 has increased by the second transfer amount (the second type of assets) and decreased the third transfer amount (the third type of assets), which is equivalent to no change in asset value Variety. In an embodiment, when the value of the state parameter and the amount of change are cipher text values, the candidate subtransactions included in the collective transaction are also set with the state value before the change and the state value after the change, so that the candidate After the sub-transaction is processed, the state parameter of the participant changes from the state value before the change via the state change amount to the state value after the change; wherein, the state change amount and the state value before the change And the state value after the change are respectively the ciphertext value calculated based on the homomorphic encryption algorithm or the homomorphic commitment algorithm. Correspondingly, when the blockchain node verifies each candidate sub-transaction contained in the collective transaction, it is necessary to ensure that the adjacent candidate sub-transactions satisfy: the changed state value corresponding to the previous candidate sub-transaction and the subsequent backup The selected sub-transaction corresponds to the same state value before the change, otherwise it will be judged as a verification failure. Corresponding to the embodiment shown in FIG. 1, FIG. 2 is a flowchart of another blockchain-based event processing method provided by an exemplary embodiment. As shown in Figure 2, the method is applied to a blockchain node and may include the following steps: Step 202: Receive a collective transaction submitted by a participant to the blockchain, and the collective transaction includes a waiting queue maintained from the participant A number of candidate sub-transactions selected in the column, and the candidate sub-transactions correspond to the event in which the participant participates. In one embodiment, there are multiple participants in the event, and each participant corresponds to a participating object. The participating object may be an individual, an enterprise, an organization, etc., and this specification does not limit this. The participating object has a corresponding digital identity, so that the electronic device carrying the digital identity is equivalent to being configured as a participant corresponding to the participating object. In an embodiment, the events in this specification may include any type and cover any scene, such as voting, signing of an agreement, traffic distribution, transfer, cross-border remittance, etc. This specification does not limit this. Taking voting as an example, the description information can include information such as the reason for voting and voting options, and the trigger information submitted by each participant to the blockchain can include the results of the selection of the voting options, thereby triggering the completion of the voting operation. In one embodiment, the candidate sub-transaction includes event description information, and the description information is used to describe the situation of the related event, so that when the candidate sub-transaction is processed, the corresponding event can be implemented based on the description information. For example, the description information can characterize the execution logic of the relevant event, the involved parties, the way of changing the state parameters of the participants (such as increasing or decreasing the value of the state parameter), the amount of change, etc. This specification does not refer to this Make restrictions. In fact, the relevant content of the event can be communicated in advance through any means between the participating parties, and then any one of the participating parties drafts the description of the event, so that other parties to the event can communicate with each other based on the results of the prior communication. The content of the description information can be viewed and confirmed; of course, any of the participants can also determine the other participants of the event and other content in the description information without communicating in advance. This manual does not limit this . In one embodiment, the description information of the event can be generated by any participant of the event and added as a candidate sub-transaction in the waiting queue maintained by the any participant. And, any participant will also share the generated description information to other participants, so that other participants can confirm the description information. In one embodiment, any participant can send the description information to other participants of the event through an off-chain channel. The description information is sent to other participants of the event through the off-chain channel, which can realize the efficient transmission of the description information. Among them, the off-chain channel can be an encrypted channel or other form of secret channel established between various participants in the event to avoid information leakage. In an embodiment, any participant can submit a transaction to the blockchain and include the above description information in the transaction, so that the transaction can be sent to all areas in the blockchain after consensus. Blockchain node; and each participant of the event can be configured as a blockchain node in the blockchain, or each participant can have a corresponding blockchain node in the blockchain, so that each participant The above-mentioned transactions and the description information contained therein can be obtained through the blockchain ledger maintained by itself or by the corresponding blockchain node (the blockchain ledger contains the full transaction data of the blockchain), so as to make the above-mentioned description information The other parties that are synchronized to the event. In one embodiment, the collective transaction may include multiple candidate sub-transactions, and each candidate sub-transaction corresponds to an event in which the above-mentioned participant participates, so that after the collective transaction is submitted to the blockchain, it contains Multiple alternative sub-transactions of can be processed in the blockchain, so that multiple events corresponding to these alternative sub-transactions are implemented. It can be seen that by including multiple candidate sub-transactions in the collective transaction, these candidate sub-transactions are submitted to the blockchain in batches, which can reduce the number of transactions submitted to the blockchain, without generating for each candidate sub-transaction A blockchain transaction can help reduce resource consumption and improve processing efficiency. In an embodiment, when the candidate sub-transactions in the waiting queue reach a preset number, the candidate sub-transactions that already exist in the waiting queue (that is, the preset number of candidate sub-transactions) may be selected , To generate the corresponding collective transaction. In another embodiment, the existing candidate sub-transactions in the waiting queue can be periodically selected according to the preset duration to generate corresponding collective transactions; of course, the capacity of each collective transaction may have a maximum limit , So that the number of candidate subtransactions selected in the same period has a corresponding maximum value, and the excess part can be postponed to the next period for selection. Of course, alternative sub-transactions can also be selected through other preset rules, which are not restricted in this manual. In an embodiment, the candidate sub-transactions in the waiting queue can be arranged in sequence according to the time of addition, and each candidate sub-transaction can be selected from front to back each time, so that the candidate sub-transactions generated earlier can be selected first . Of course, the participants can also select the candidate sub-transactions in the waiting queue regardless of the order according to actual needs, such as the urgency of the event, the priority of the event, etc.; or, the waiting queue itself can follow the above The urgency, priority, etc. are arranged so that it can still be regarded as sequential selection. In an embodiment, the participant may add a number to each merged transaction in the order of generation, so that each merged transaction is processed in the blockchain according to the size of the corresponding number. In other words, after receiving the merged transaction submitted by the participants, the blockchain transaction needs to read the serial number contained in the merged transaction; if the serial number is continuous with the serial number of the previously processed merged transaction, for example, the serial number of the newly processed merged transaction is 99, The number of the currently received consolidated transaction is 100, then the consolidated transaction numbered 100 can be processed; if the numbers are not consecutive, for example, the number of the newly processed consolidated transaction is 99, and the number of the currently received consolidated transaction If the number is 101, the blockchain node needs to wait and process the merged transaction numbered 100 first, and then process the merged transaction numbered 101. Since the execution of each transaction may cause the state parameters of the participant to change, and the execution of subsequent transactions needs to depend on the value of the state parameters after the execution of the previous transaction, it is necessary to ensure that each combined transaction is numbered according to the corresponding number. The sizes are processed in sequence so that each combined transaction can be executed correctly. Step 204: Execute the collective transaction to process the candidate sub-transactions in the collective transaction respectively. In one embodiment, the candidate sub-transaction corresponding to the event includes multi-party trigger information of all participants of the event; wherein, when the multi-party trigger information is verified, the event The corresponding candidate sub-transaction is triggered and executed in the blockchain. Multi-party trigger information represents the recognition of all participants in the event for the description information and hope to trigger the execution of the event. For example, after any participant in an event generates description information and sends it to other participants, the other participants can confirm the content of the description information, generate a signature on the description information with their own identity key, and return the signature to any participant The multi-party trigger information can include the signatures generated by each participant describing the information and the event; each signature belongs to the confirmation information provided by the corresponding participant, and if the cipher text value is used, the confirmation information will also include the encryption The proof information of the text value, which will be described in detail below. In short, in this embodiment, after any participant of the event organizes the formation of multi-party trigger information, it only needs to add the corresponding candidate sub-transaction to the waiting queue maintained by any participant, and submit it to the blockchain containing this A collective transaction of alternative sub-transactions, and other participants do not need to implement similar processing; accordingly, the blockchain node can process the alternative sub-transaction submitted by any one of the participants after the multi-party trigger information is verified. In one embodiment, the candidate sub-transaction corresponding to the event includes the unilateral trigger information of the participant on the event; wherein, when all the participants of the event submit to the blockchain the information for the When the unilateral trigger information of the event is verified, the candidate sub-transaction corresponding to the event is triggered to be executed in the blockchain. The unilateral trigger information indicates that the corresponding participant confirms the description information of the event and hopes to trigger the execution of the event; and each participant of the event needs to submit the unilateral trigger information to the blockchain separately, so that the blockchain node is based on all participants The separately submitted unilateral trigger information determines whether the event specified by the corresponding alternative sub-exchange should be executed. For example, after any participant of an event generates description information and provides it to other participants, not only does any participant need to add corresponding candidate sub-transactions to the waiting queue maintained by itself, each other participant is After the information is confirmed, the corresponding candidate sub-transactions are added to the waiting queue maintained by itself; and each participant generates a collective transaction based on the waiting queue maintained by itself, thereby submitting the collective transaction to the block Chain, so that the above-mentioned unilateral trigger information is submitted to the blockchain for verification by the blockchain nodes. The unilateral trigger information can include the description information and the signature generated by the corresponding participant on the description information; the signature belongs to the confirmation information provided by the corresponding participant, and if the cipher text value is used, the confirmation information also contains the certification information, which will be described in detail below. By submitting single-party trigger information to the blockchain by each participant separately, instead of submitting multi-party trigger information by a single participant, not only can the processing pressure be shared, and the processing pressure of a single participant can be prevented from being excessive, but also each participant can be based on The actual situation of its own (such as processing pressure, priority management, etc.) selectively handles or even batches each event involved. In an embodiment, the description information of the event may include the amount of change, and the event may be used to make the state parameters correspondingly recorded on the blockchain by each participant change according to the amount of change, such as increasing the value Value, decrease the value, etc. Among them, the corresponding state parameters may be different according to the type of the event or the difference in the scene. For example, the state parameter in the transfer or cross-border remittance scenario can be the account balance of the participant, and the state parameter in the traffic distribution scenario can be the participant. This manual does not limit the amount of remaining flow held. In an embodiment, the value of the state parameter corresponding to each participant and the change amount may be a plain text value. Each blockchain node in the blockchain maintains a blockchain ledger, which records all transaction data, so that the blockchain node can learn the value of the state parameter corresponding to each participant; further Ground, any one of the participants can submit a transaction to the blockchain, and the transaction includes the trigger information mentioned above, so that the transaction can be based on the value of the state parameter corresponding to any one of the participants, the above The change amount is executed, so that the state parameter corresponding to any participant can realize a value change based on the change amount. In an embodiment, the value of the state parameter corresponding to each participant and the change amount are respectively a ciphertext value calculated based on a homomorphic encryption algorithm or a homomorphic commitment algorithm. For the homomorphic encryption algorithm, any type of homomorphic encryption algorithm can be used, as long as the homomorphic encryption algorithm can meet the additive homomorphism, so that even in the ciphertext state, the value of the state parameter can still be obtained Increase or decrease the amount of change; for the homomorphic encryption algorithm being additive homomorphic encryption algorithm or fully homomorphic encryption algorithm, this specification does not limit this. For the homomorphic commitment algorithm, when the Pedersen commitment mechanism in related technologies is used, a random number can be determined for unencrypted data, and the corresponding commitment data can be calculated based on the random number and the unencrypted data. The commitment data Can be used as the above-mentioned ciphertext value. In one embodiment, when the value and change of the state parameter are ciphertext values, the participants need to provide relevant proof information so that the blockchain node can determine the legality of the transaction when executing the relevant transaction. For example, the participant needs to provide a proof of the change to show that the change is in the correct numerical range, such as [0, 2 64 ). For another example, when an event is used to reduce the value of the state parameter corresponding to a certain participant according to the amount of change, that is, the purpose of the transaction is to reduce the value of the state parameter of the certain party by the amount of change. A participant needs to provide proof of the value and change of the state parameter to show that the value of the state parameter is not less than the value reduction (the value reduction is equivalent to the above-mentioned change). In one embodiment, a range proof technique in related technologies, such as the Bulletproofs scheme or the Borromean ring signature scheme, can be used to generate the above-mentioned proof information, which is not limited in this specification. In one embodiment, when any participant generates description information, the amount of change in the description information may be a cipher text value. For example, when the plaintext value of the change is t1, if the Pedersen commitment mechanism is adopted, the corresponding ciphertext promise T1 can be generated based on the plaintext value t1 and the random number r1, and the description information can include the T1, t1, and r1, so that the event Other participants in can verify the correspondence between the ciphertext commitment T1 and the plaintext value t1 and the random number r1. Among them, the plaintext value t1 and random number r1 can be encrypted and protected in the description information. For example, when the description information needs to be sent to the participant X, the identity public key corresponding to the digital identity of the participant X can be used for encryption, respectively. The encrypted Enc_X(t1) and Enc_X(r1) are added to the description information, so only the participant X can decrypt Enc_X(t1) and Enc_X(r1) with their own identity private key to obtain the above-mentioned plaintext values t1 and Random number r1 significantly improves data security. Of course, in addition to the public key encryption method, any other encryption methods in related technologies, such as digital envelopes, can also be used, and this specification does not limit this. In one embodiment, when there are multiple other participants, the description information may respectively include encrypted data corresponding to each of the other participants. For example, when the other parameter parties include participant X and participant Y, the plaintext value t1 and random number r1 can be respectively encrypted according to the identity public key of the participant X to obtain Enc_X(t1), Enc_X(r1), and according to the participants Y’s identity public key encrypts the plaintext value t1 and the random number r1 to obtain Enc_Y(t1), Enc_Y(r1), and adds Enc_X(t1), Enc_X(r1), Enc_Y(t1) and Enc_Y(r1) to In the description information, any one participant only needs to prepare one description information and send it to each other participant separately, instead of preparing different description information for each other participant. Of course, any one of the participants can prepare different description information for each other participant. For example, the description information sent to participant X includes Enc_X(t1) and Enc_X(r1), and it is sent to participant Y. The description information of contains Enc_Y(t1) and Enc_Y(r1), which are not restricted in this manual. In an embodiment, for the change amount of the ciphertext state included in the description information, the collective transaction may include first proof information, which is used to prove that the change amount is in the correct numerical range. When any participant generates the description information of the event, the any participant can also generate the first proof information, so that no matter whether it is generating multi-party trigger information or single-party trigger information, it does not require other participation policies to value the change amount And generate other certification information. Of course, each participant can also generate the corresponding amount of change (the amount of change corresponding to each participant may be different; for example, in a cross-border remittance scenario, the value of the amount of change may differ based on different currency types). One proof information, this manual does not limit it. In an embodiment, if the event is used to reduce the value of the state parameter corresponding to a certain participant of the event (there may be multiple similar participants) according to the change amount, then the collective transaction needs to include The second proof information is used to prove that the value of the state parameter corresponding to the certain participant is not less than the value decrease. For multi-party trigger information, each participant in the event can respectively generate corresponding second proof information and provide it to any of the above when determining that its own state parameter will decrease in value according to the change amount. Participants are organized by any participant to form multi-party trigger information; or, any participant can generate the second proof information in a unified manner, without the need for each participant to generate it separately. For unilateral trigger information, the participant that generates the unilateral trigger information can generate second proof information for itself. In one embodiment, when a participant generates the second proof information for itself, the participant first updates the value of its corresponding state parameter according to other events it participated in, and then updates the state according to the value. The parameter generates the second proof information. For example, when the value and change amount of the state parameter are cipher text values, and the event is used to make the state parameter corresponding to the participant decrease in value according to the change amount, the participant needs to be based on the previously processed transaction , To determine the value of the state parameter corresponding to itself, so as to generate the correct second proof information to ensure that the related event can be executed smoothly. For example, after receiving the collective transaction submitted by each participant, the blockchain node extracts the candidate sub-transactions included in the collective transaction, and confirms the trigger information (multi-party trigger information or single-party trigger information) contained in the candidate sub-transaction And verification. When the multi-party trigger information contains the confirmation information corresponding to all the participants of the event, or all the participants of the event have submitted the corresponding one-party trigger information (each one-party trigger information contains the confirmation information of the corresponding participant), if If the multi-party trigger information or all the single-party trigger information have passed the verification, the event can be marked as a success state; similarly, the event that fails the verification can be marked as a failure state, and all events that have not been received within the valid time period The event of the confirmation information corresponding to the participant is marked as a timeout status, etc., and then the status of each event is submitted to the blockchain. Take a participant of an event as an example. Before submitting a collective transaction, the participant can check the transaction records on the blockchain ledger to determine the status of each event that it participated in, such as failure status or timeout status. For transactions, the value of the status parameter needs to be restored accordingly (for example, when the participant is the remittance party, the corresponding account balance needs to be rolled back), and the status parameter needs to be updated for the successful transaction (for example, the participant is the receiver At the time of payment, the corresponding transfer amount needs to be collected and added to the account balance), and then based on the updated value of the status parameter, the second proof information of the relevant event is generated (to ensure that the second proof information is based on the status parameter The latest value is generated), and then the above collective transaction is generated and submitted. In an embodiment, when the event includes a transfer event, the participants in the event include: the remittance party and the receiver, the change amount includes: the transfer amount, and the state parameter includes: the account balance; in other words, It is equivalent to the transfer operation from the remittance to the recipient, so that the remittance's account balance decreases by the corresponding transfer amount, and the recipient's account balance increases the corresponding transfer amount. For example, the description information can include the account address of the sender, the account address of the recipient, the transfer amount (commitment value), the transfer amount in plain text (encrypted state), random numbers (encrypted state), etc., to indicate The account address transfers the transfer amount to the payee's account address. In an embodiment, when the event includes the first remittance event, participants in the event include: a remittance party, a relay party, and a remittance party, and the amount of change includes: the remittance party and the middle party. The first transfer amount based on the first type of assets between the relay parties, and the second transfer amount based on the second type of assets between the relay party and the payee, the state parameters include: account balance; in other words, It is equivalent to transferring the first type of assets (such as Hong Kong dollars) between the sender and the relay party, the asset amount is the first transfer amount, and the second type of assets (such as US dollars) is transferred between the relay party and the recipient ), the asset amount is the second transfer amount, and according to the exchange rate between the first and second types of assets, the asset value corresponding to the first transfer amount and the second transfer amount is basically the same, then it is ultimately equivalent to the remittance party’s The account balance decreases by the first transfer amount (the first type of assets), the recipient's account balance increases by the second transfer amount (the second type of assets), and the relay party’s account balance increases by the first transfer amount ( The first type of assets) and the reduction of the second transfer amount (the second type of assets), the asset value is equivalent to unchanged. In an embodiment, when the event includes the second remittance event, the participants of the event include: the remittance party, n relay parties, and the remittance party, and the change amount includes: the remittance party and the first remittance party. The transfer amount between 1 relay party based on the first type of asset, the transfer amount between the i-1th relay party and the i-th relay party based on the i-th type asset, the nth relay party and all The transfer amount between the payees based on the n+1 type asset, the state parameter includes: account balance; where 1<i≤n. When n=1, the second remittance event in this embodiment is equivalent to the first remittance event in the foregoing embodiment, and will not be repeated here. When n>1, because there are multiple relay parties, compared with the first remittance event in the above embodiment, it also includes the asset transfer process between multiple relay parties; taking n=2 as an example, The participants in the event include the remitter, the relay party 1, the relay party 2, and the recipient. Among them, the first type of assets (such as Hong Kong dollars) is transferred between the remitter and the relay party 1, and the amount of assets is the first Transfer amount, transfer the second type of assets (such as Euro) between relay party 1 and relay party 2, the asset amount is the second transfer amount, transfer the third type of asset between relay party 2 and the payee Assets (such as US dollars) and the amount of assets are the third transfer amount, and the first transfer is based on the exchange rate between the first and second types of assets 1, the exchange rate between the second and third types of assets 2 The asset value corresponding to the amount, the second transfer amount and the third transfer amount are basically the same, so in the end, the account balance of the remitter is reduced by the first transfer amount (the first type of assets), and the account balance of the recipient increases by the first transfer amount. Three transfer amount (the third type of assets), and the account balance of the relay party 1 increases the first transfer amount (the first type of assets) and reduces the second transfer amount (the second type of assets), and the value of the assets The above is equivalent to no change. The account balance of relay party 2 has increased by the second transfer amount (the second type of assets) and decreased the third transfer amount (the third type of assets), which is equivalent to no change in asset value Variety. In an embodiment, when the value of the state parameter and the amount of change are cipher text values, the candidate subtransactions included in the collective transaction are also set with the state value before the change and the state value after the change, so that the candidate After the sub-transaction is processed, the state parameter of the participant changes from the state value before the change via the state change amount to the state value after the change; wherein, the state change amount and the state value before the change And the state value after the change are respectively the ciphertext value calculated based on the homomorphic encryption algorithm or the homomorphic commitment algorithm. Correspondingly, when the blockchain node verifies each candidate sub-transaction contained in the collective transaction, it is necessary to ensure that the adjacent candidate sub-transactions satisfy: the changed state value corresponding to the previous candidate sub-transaction and the subsequent backup The selected sub-transaction corresponds to the same state value before the change, otherwise it will be judged as a verification failure. For ease of understanding, the following uses a cross-border remittance scenario as an example to describe the technical solutions of one or more embodiments of this specification. Based on the technical solution in this manual, each institution can merge several remittance transactions (equivalent to the above-mentioned alternative sub-transactions) that it has participated in into a block chain transaction (equivalent to the above-mentioned collective transaction). The blockchain submits the blockchain transaction to realize batch submission and processing of several remittance transactions. The following will first describe the generation and processing of a single remittance transaction, and then expand to batch processing of multiple remittance transactions. Fig. 3 is a schematic diagram of a cross-border remittance scenario provided by an exemplary embodiment. As shown in Figure 3, it is assumed that user 1 transfers money to user 2 on the blockchain; among them, the "user" in this manual can be expressed as the logged-in user account, and the user account can actually belong to an individual or organization. The instructions do not limit this. Assuming that user 1 has a client fund account at institution 1 in country A and user 2 has a client fund account at institution 4 in country B, this manual can not directly implement cross-border remittances between institution 1 and institution 4 In the case of, the cross-border remittance operation is realized on the blockchain through the assistance of institution 2 and institution 3. Institution 1, Institution 2, Institution 3, and Institution 4 respectively have corresponding equipment 1, equipment 2, equipment 3, and equipment 4, and by running the blockchain client program on equipment 1 to 4, equipment 1 to 4 are Configured as the corresponding blockchain node; accordingly, institutions 1~4 can implement blockchain-related operations through devices 1~4. For example, institutions 1~4 can submit corresponding blockchain transactions to the blockchain through devices 1~4; for another example, devices 1~4 maintain all transaction data on the blockchain, namely, the blockchain ledger. , So that institutions 1~4 can respectively query and maintain the balance data of each blockchain account. For example, the blockchain account Y1 corresponding to institution 1 holds 1,000 Hong Kong dollars, and the blockchain account Y2 corresponding to institution 2 holds 2500 Hong Kong dollars. And 4200 euros, the blockchain account Y3 corresponding to institution 3 holds 3000 euros and 2000 US dollars, and the blockchain account Y4 corresponding to institution 4 holds 1500 US dollars. For privacy protection and other considerations, the balance data of blockchain accounts Y1~Y4 are often not maintained in plain text, but corresponding cipher text data. Taking the blockchain account Y1 as an example, it can be recorded as (currency_1, PC(a, r_a), Enc_A(a), Enc_A(r_a)) in the blockchain ledger, where: currency_1 means that the currency type is Hong Kong dollars, a means that the amount of Hong Kong dollars is 1000, r_a is the random number corresponding to a, PC(a, r_a) is the commitment value in ciphertext form calculated by Pedersen commitment mechanism on a and r_a, Enc_A(a), Enc_A(r_a) These are the ciphertext values of a and r_a (for example, the identity public key of organization 1 can be used for encryption, or any other encryption algorithm can be used). Blockchain account Y2 can be recorded as (currency_1, PC(b1, r_b1), Enc_B(b1), Enc_B(r_b1)), (currency_2, PC(b2, r_b2), Enc_B(b2), Enc_B(r_b2)) , Where: b1 means the amount of Hong Kong dollars is 2500, r_b1 is the random number corresponding to b1, currency_2 means the currency type is Euro, b2 means the amount of Euro is 4200, r_b2 is the random number corresponding to b2. Blockchain account Y3 can be recorded as (currency_2, PC(c1, r_c1), Enc_C(c1), Enc_C(r_c1)), (currency_3, PC(c2, r_c2), Enc_C(c2), Enc_C(r_c2)) , Where: c1 means that the Hong Kong dollar and Euro are 3000, r_c1 is the random number corresponding to c1, currency_3 means that the currency type is USD, c2 means that the dollar amount is 2000, and r_c2 is the random number corresponding to c2. Blockchain account Y4 can be recorded as (currency_3, PC(d, r_d), Enc_D(d), Enc_D(r_d)), where d represents the dollar amount of 1500 and r_d is the random number corresponding to d. Based on the remittance scenario shown in FIG. 3, FIG. 4 is a schematic diagram of interaction in a cross-border remittance process according to an exemplary embodiment. As shown in Figure 4, the interactive process of cross-border remittance may include the following steps: Step 401: Device 1 drafts a remittance transaction tx_i. In one embodiment, suppose that user 1 wants to send 500 Hong Kong dollars to user 2, and user 1 can provide the 500 Hong Kong dollars through customer funds account 1 at institution 1, and user 2 can use customer funds account 2 at institution 4. Collect US dollars calculated at a certain exchange rate. In one embodiment, institution 1 can deduct 500 Hong Kong dollars from the customer fund account 1 corresponding to user 1; and, institution 1 needs to determine the remittance route between itself and institution 4. For example, the remittance route in Figure 4 is " Institution 1→Institution 2→Institution 3→Institution 4", so that Institution 1 can transfer 500 HKD to Institution 2, Institution 2 can transfer 56 Euros (equivalent to 500 HKD) to Institution 3, and Institution 3 can transfer to Institution 4 64 US dollars (equivalent to 56 Euros and 500 Hong Kong dollars), and finally the institution 4 transfers 64 US dollars to the customer fund account 2 corresponding to the user 2 to complete the remittance operation. Among them, institution 1 deducts 500 Hong Kong dollars from customer fund account 1 and institution 4 transfers $64 to customer fund account 2 are off-chain operations, while institution 1 ~ institution 4 realize on-chain fund transfer through blockchain. In one embodiment, in the remittance route "Institution 1→Institution 2→Institution 3→Institution 4", there are two relay parties between institution 1 and institution 4, namely institution 3 and institution 4; while in other implementations In the example, the number of relay parties can be 1, 3, or more than 3, which is not limited in this specification. Regarding the determined remittance route and the amount of remittance between various institutions, the remittance transaction tx_i drafted by device 1 can include the following remittance transaction details: transaction id is tx_i, blockchain account Y1 address Z1, blockchain account Y2 The address Z2, the address Z3 of the blockchain account Y3, the address Z4 of the blockchain account Y4, the ciphertext information related to the transaction amount {(currency_1, PC(t1, r_t1), Enc_B(t1), Enc_B(r_t1) ), Enc_C(t1), Enc_C (r_t1), Enc_D(t1), Enc_D(r_t1)), (currency_2, PC(t2,r_t2), Enc_B(t2), Enc_B(r_t2), Enc_C(t2), Enc_C( r_t2), Enc_D (t2), Enc_D(r_t2)),(currency_3, PC(t3,r_t3), Enc_B(t3), Enc_B(r_t3), Enc_C(t3), Enc_C(r_t3), Enc_D(t3), Enc_D (r_t3)), rate1, rate2, time, …}, to prove RP_t1, RP_t2, RP_t3, etc. for the interval of transaction amounts t1, t2, and t3. Among them, the addresses Z1~Z4 are used to indicate the participants in this remittance event, so that subsequent transfers and remittances can be implemented from the blockchain accounts Y1~Y4 corresponding to the addresses Z1~Z4. In (currency_1, PC(t1, r_t1), Enc_B(t1), Enc_B(r_t1), Enc_C(t1), Enc_C(r_t1), Enc_D(t1), Enc_D(r_t1)), t1 means from address Z1 to The transfer amount of address Z2 (such as the above 500 HKD), r_t1 is the random number corresponding to the amount t1, PC(t1, r_t1) is the commitment value calculated based on the amount t1 and the random number r_t1, Enc_B(t1) represents The ciphertext value of the amount t1 encrypted by the identity public key of institution 2, Enc_C(t1) represents the ciphertext value of the amount t1 encrypted with the identity public key of institution 3, Enc_D(t1) represents the identity of institution 4 The ciphertext value of the amount t1 encrypted by the public key; similarly, Enc_B(r_t1), Enc_C(r_t1), Enc_D(r_t1) are respectively used to encrypt the amount t1 with the identity public keys of the institution 2, institution 3, and institution 4 The following ciphertext value. (currency_2, PC(t2,r_t2), Enc_B(t2), Enc_B(r_t2), Enc_C(t2), Enc_C(r_t2), Enc_D(t2), Enc_D (r_t2)) and (currency_3, PC(t3,r_t3) , Enc_B(t3), Enc_B(r_t3), Enc_C(t3), Enc_C(r_t3), Enc_D(t3), Enc_D(r_t3)) are similar, so I won’t repeat them here. rate1 and rate2 are the exchange rates of currency_1 and currency_2, and the exchange rates of currency_2 and currency_3, respectively. time is the trading moment. And, there may also be some other materials required for transactions, which can refer to the solutions in related technologies, which will not be listed here. RP_t1, RP_t2, and RP_t3 are interval proofs corresponding to transaction amounts t1, t2, and t3, respectively, to prove that the transaction amounts t1, t2, and t3 are in the correct numerical range, such as 1≤t1<2 64 , 1≤t2<2 64 , 1≤t3＜2 64 . Among them, the device 1 can generate the above-mentioned interval proof through the zero-knowledge proof technology in the related technology, which is not limited in this specification. And if the clear text value is used, then in the remittance transaction details of the remittance transaction tx_i, the above cipher text information related to the transaction amount can be replaced with the clear text information related to the transaction amount, such as {(currency_1, t1), (currency_2, t2 ), (currency_3, t3), rate1, rate2, time, …}, and there is no need to include the above interval proofs RP_t1, RP_t2, RP_t3, etc. In steps 402a to 402c, device 1 synchronizes the details of the remittance transaction to device 2, device 3, and device 4, respectively. In one embodiment, device 1 can sign the remittance transaction details with the identity private key of institution 1, and then send them to devices 2 to 4 through off-chain (or off-chain) channels to realize data synchronization. In one embodiment, device 1~device 4 run the client program of the blockchain, so that device 1~device 4 are respectively configured as blockchain nodes in the blockchain; or, device 1~device 4 are in There are corresponding blockchain nodes in the blockchain, and this manual does not limit this. Among them, each block chain node in the block chain maintains a block chain ledger with a unified content, and the block chain ledger records the full amount of block chain data. Therefore, the device 1 can generate a transaction that contains the remittance transaction details of the above remittance transaction tx_i, and submit the transaction to the blockchain; accordingly, when the transaction passes the consensus, it can be sent to the block Each blockchain node in the chain allows each blockchain node to update its own blockchain ledger. Therefore, device 1, device 2, device 3, and device 4 can respectively learn the above-mentioned transaction submitted by device 1 through the blockchain ledger maintained by its corresponding blockchain node, so as to obtain the above-mentioned remittance transaction included in the transaction. tx_i's remittance transaction details. Of course, device 1 may also synchronize the remittance transaction data to devices 2 to 4 through other methods, which are not restricted in this manual. In step 403a, the device 1 adds the remittance transaction tx_i corresponding to the remittance transaction details to its local queue 1. In one embodiment, when device 1 sends the remittance transaction details through the off-chain channel, device 1 can directly add the remittance transaction tx_i to local queue 1; of course, device 1 can wait for devices 2 to 4 to confirm the remittance transaction details. After the corresponding confirmation response is returned, the remittance transaction tx_i is added to the local queue 1 to ensure that all devices 2 to 4 participate in the remittance transaction tx_i. In one embodiment, when device 1 synchronizes the remittance transaction details to devices 2 to 4 through the blockchain, device 1 will also receive the remittance transaction details synchronized on the blockchain, and device 1 can either The remittance transaction details are verified (refer to step 403b for the verification process), and the remittance transaction tx_i is added to the local queue 1 after the verification is passed. It can also be determined that the remittance transaction details correspond to the remittance transaction tx_i, and the remittance transaction tx_i is determined by the When the device 1 drafts and submits it to the blockchain, the verification process for the details of the remittance transaction is omitted and directly added to the local queue 1. In step 403b, after the device 2 verifies the received remittance transaction details, it adds it to its local queue 2. In one embodiment, device 2 needs to perform verification operations after receiving the details of the remittance transaction, including: device 2 uses its own identity private key to pair the details of the remittance transaction including Enc_B(t1), Enc_B(r_t1), Enc_B(t2) ), Enc_B(r_t2), Enc_B(t3), Enc_B(r_t3) to decrypt, get the corresponding amount t1 and random number r_t1, amount t2 and random number r_t2, amount t3 and random number r_t3, and verify PC(t1, r_t1)= r_t1G+t1H, PC(t2, r_t2)= r_t2G+t2H, PC(t3, r_t3)= r_t3G+t3H is it true, where G and H are system parameters; device 2 verifies whether the exchange rate between currency_1 and currency_2 Whether the exchange rate between rate1, currency_2, and currency_3 is rate2; the device 2 verification interval proves whether RP_t1, RP_t2, RP_t3 are correct, etc. After determining that the remittance transaction details are verified, the device 2 can add the corresponding remittance transaction tx_i to the local queue 2 maintained by itself, and return a confirmation response to the device 1 to indicate that the corresponding remittance transaction is accepted. Of course, if you use plaintext values, you can omit the above operations such as decryption, commitment value verification, interval proof verification, etc., such as only the address of each participant's blockchain account, t1, t2, t3, rate1, rate2 Check it. In steps 403c-403d, the device 3-4 respectively verifies the details of the received remittance transaction and adds it to its local queue 3-4. In an embodiment, the operations performed by the device 3 and the device 4 are similar to those of the device 2, and will not be repeated here. At this point, the remittance transaction tx_i has been added to the local queues 1~4 maintained by devices 1~4 respectively. Similarly, when devices 1~4 participate in other remittance transactions (not necessarily the remittance transactions in which devices 1~4 participate at the same time), they can also use a similar processing method to the above remittance transaction tx_i to send the corresponding Add remittance transactions to the local queue of for use in transaction aggregation and batch processing in the following steps. In step 404a, the device 1 aggregates and generates a transaction TX_a according to the remittance transaction in the local queue 1, and submits it to the blockchain after signing. As mentioned above, similar to the remittance transaction tx_i, Institution 1 can also participate in other remittance transactions. For example, when a user needs to remit money to another user through Institution 1, Device 1 can use a method similar to the above steps. , Draft the corresponding remittance transaction, send the details of the remittance transaction to other institutions for verification, and add the corresponding remittance transaction tx_i to the local queue 1. At the same time, institution 1 can also act as a relay party for some remittance transactions (similar to the role of institution 2-3 in the above embodiment) or payee (similar to the role of institution 4 in the above embodiment), so that the institution 1 can receive the remittance transaction details sent by the remittance party of these remittance transactions (similar to the role of institution 1 in the above embodiment) through the device 1, and add the corresponding remittance transaction to the local queue 1 after verification. Therefore, the local queue 1 maintained by the device 1 contains many remittance transactions in which the institution 1 participates. The device 1 can select one or more remittance transactions from the local queue 1 each time according to a predefined transaction selection rule, and aggregate the selected remittance transactions to generate a blockchain transaction. For example, FIG. 5 is a schematic diagram of a block chain transaction content based on a ciphertext value provided by an exemplary embodiment. As shown in Figure 5, suppose that device 1 selects 4 remittance transactions at a time and aggregates them into a blockchain transaction. For example, remittance transactions tx_11, tx_12, tx_13, and tx_14 are aggregated into blockchain transactions TX_1, and remittance transactions tx_21, tx_22, tx_23 and tx_24 are aggregated into blockchain transaction TX_2, and remittance transactions tx_31, tx_32, tx_33, and tx_34 are aggregated into blockchain transaction TX_3. Each blockchain transaction generated by the device 1 includes the sequence number seq set by the device 1 and information related to each remittance transaction. The sequence number seq is related to the generation sequence of each blockchain transaction. For example, the seq value of the blockchain transaction TX_1 is 99, the seq value of the blockchain transaction TX_2 is 100, and the seq value of the blockchain transaction TX_3 is 101, indicating that the blockchain transaction TX_1 is earlier than the blockchain transaction TX_2 Generation, blockchain transaction TX_2 is generated earlier than blockchain transaction TX_3. Correspondingly, after receiving each block chain transaction submitted by device 1, the block chain node will process each block chain transaction in the order of seq value from small to large, such as processing block chain transaction TX_1, Then process the blockchain transaction TX_2, and then process the blockchain transaction TX_3. Information related to each remittance transaction can include: the initial state balance of the blockchain transaction, the end state balance of the blockchain transaction, the initial state balance of each remittance transaction, the transaction amount of each remittance transaction, and each remittance The ending status (ie, temporary status) balance of the transaction, the proof information of each remittance transaction, etc. Take the blockchain transaction TX_1 as an example. The initial state balance of the blockchain transaction TX_1 is PC (100), the end state balance of the blockchain transaction TX_1 is PC (80), the initial state balance of the remittance transaction tx_11 is PC (100), and the transaction amount of the remittance transaction tx_11 The proof information for the PC(10) to be remitted, the end state balance of the remittance transaction tx_11 is PC(110), and the proof information of the remittance transaction tx_11 includes the interval proof that PC(10) and PC(110) belong to the correct value range, the remittance transaction For the relevant content of tx_12~tx_14, please refer to Figure 5, which will not be listed here. What needs to be pointed out is: when institution 1 acts as the remittance party or relay party in several remittance transactions included in the blockchain transaction, institution 1 will subtract the corresponding transfer from the account balance of its corresponding blockchain account Y1 Amount (the sender only transfers out funds; the relay party can receive the transferred funds and need to transfer out funds, here is the description of the transfer of funds), and continue to participate in subsequent remittance transactions based on the updated remittance amount. After the blockchain transaction is submitted to the blockchain, if institution 1 is successfully executed as a remittance party or relay party, institution 1 does not need to adjust the blockchain account Y1; if institution 1 acts as the remittance party or China If a certain remittance transaction of the following party is not successfully executed, Institution 1 needs to roll back the account balance of the blockchain account Y1. And when the above blockchain transaction includes institution 1 as the payee or relay party (the payee only transfers funds; the relay party can receive the transferred funds and need to transfer the funds, here is for the transferred funds If the remittance transaction is successfully executed, Institution 1 needs to add the corresponding funds to the blockchain account Y1 to realize the collection. If the remittance transaction is not successfully executed, Institution 1 does not need to adjust the blockchain account Y1. Correspondingly, when the blockchain node receives and processes the blockchain transaction submitted by the device 1, it can mark whether the remittance transaction included in the blockchain exchange can be successfully executed, and mark the status of each remittance transaction, for example, the transaction is successful Status, failure status, timeout status, etc. Therefore, for the above “the initial state balance of the blockchain transaction TX_1 is PC(100)”, when the device 1 aggregates and generates the blockchain transaction TX_1, it does not directly set the balance of the blockchain account Y1 It is the initial state balance of the blockchain transaction TX_1, but it is necessary to determine the remittance transaction that may cause the amount of change in the blockchain transaction previously submitted by the device 1, including: the remittance of the institution 1 as the relay party or the recipient The increase in the amount generated when the transaction is marked as a successful state (receiving), and the increase in the amount generated when the remittance transaction of Institution 1 as the remittance or relay party is marked as a failed state or a timeout state (the deducted transfer amount is performed Rollback) etc. And, device 1 further calculates the corresponding value based on the value of the balance of the blockchain account Y1 (the transfer amount of the previously submitted remittance transaction has been deducted, and the amount that has not been received) and the actual amount change value of the remittance transaction that may cause the amount change. The initial state balance of is PC(100); Similarly, device 1 should generate corresponding interval proofs for each remittance transaction included in the blockchain transaction TX_1 based on the initial state balance PC(100). For another example, FIG. 6 is a schematic diagram of a block chain transaction content based on a plaintext value provided by an exemplary embodiment. As shown in Figure 6, suppose that device 1 selects 4 remittance transactions at a time and aggregates them into a blockchain transaction. For example, remittance transactions tx_11, tx_12, tx_13, and tx_14 are aggregated into blockchain transactions TX_1, and remittance transactions tx_21, tx_22, tx_23 and tx_24 are aggregated into blockchain transaction TX_2, and remittance transactions tx_31, tx_32, tx_33, and tx_34 are aggregated into blockchain transaction TX_3. Each blockchain transaction generated by the device 1 includes the sequence number seq set by the device 1 and information related to each remittance transaction. The function of the sequence number seq is the same as that of the embodiment shown in FIG. 5, and will not be repeated here. Information related to each remittance transaction can include: the initial state balance of the blockchain transaction, the end state balance of the blockchain transaction, and the transaction amount of each remittance transaction; and due to the use of clear text data, the graph is no longer needed In the embodiment shown in 5, the initial state balance of each remittance transaction, the ending state (i.e. temporary state) balance of each remittance transaction, the proof information of each remittance transaction, etc., the blockchain node directly bases on each plaintext value Just compare or calculate. In step 404b-c, the device 2-3 aggregates and generates transactions TX_b and TX_c according to the remittance transactions in the local queue 2-3, and submits them to the blockchain after signing. In an embodiment, similar to the device 1, the device 2 can select one or more remittance transactions from the local queue 2 to aggregate and generate corresponding blockchain transactions. Assume that the device 2 includes the aforementioned remittance transaction tx_i in a certain selected remittance transaction, and accordingly generates the corresponding blockchain transaction TX_b. In an embodiment, similar to the device 1, the device 3 can select one or more remittance transactions from the local queue 3 to aggregate and generate corresponding blockchain transactions. Assume that the device 3 includes the above-mentioned remittance transaction tx_i in a certain selected remittance transaction, and accordingly generates the corresponding blockchain transaction TX_c. In step 404d, the device 4 aggregates and generates the transaction TX_d according to the remittance transactions in the local queue 4, and submits the transaction TX_d to the blockchain after signing. In an embodiment, similar to the device 1, the device 4 can select one or more remittance transactions from the local queue 4 to aggregate and generate corresponding blockchain transactions. Assume that the device 4 includes the above-mentioned remittance transaction tx_i in a certain selected remittance transaction, and accordingly generates the corresponding blockchain transaction TX_d. It should be pointed out that: Device 1~Device 4 can choose to generate the corresponding blockchain transaction according to the actual situation, instead of processing the remittance transaction tx_i immediately; in other words, Device 1~Device 4 actually send the block asynchronously The chain submits the remittance transaction tx_i (which is included in the corresponding blockchain transaction), so that the execution of the remittance transaction tx_i is allocated to be triggered by devices 1 to 4 respectively, prompting devices 1 to 4 to participate in a large number of remittance transactions In this case, blockchain transactions can be generated in batches for participating remittance transactions, thereby reducing the number of blockchain transactions generated and submitted, which helps reduce processing burden and improve processing efficiency. In step 405, the blockchain node processes the received blockchain transaction to verify each remittance transaction included in the blockchain transaction. Step 406: Mark the remittance transaction tx_i. In one embodiment, since each institution will continue to submit blockchain transactions to the blockchain, the remittance transactions included in the blockchain exchange submitted earlier will affect the remittance transactions included in the blockchain exchange submitted later. Remittance transactions. Therefore, after receiving the blockchain transaction submitted by each institution, the blockchain node needs to read the sequence number seq contained in the received blockchain transaction, and process the sequence number seq according to the size of the sequence number seq. Blockchain transactions of corresponding institutions. For example, when the blockchain node receives the blockchain transaction TX_a submitted by device 1, the sequence number seq contained in it is read as 100; and if the sequence number seq of the most recent blockchain transaction processed by the blockchain node Is 98, then the blockchain node needs to wait for the blockchain transaction with the sequence number seq of 99 submitted by the device 1, and only after the blockchain transaction with the sequence number 99 is processed, can the above sequence number 100 area be processed. Block chain transactions are processed. In one embodiment, after receiving the blockchain transactions submitted by the devices 1 to 4, the blockchain node can extract the remittance transactions included in each blockchain transaction, and implement a separate implementation for each remittance transaction. verification. Verification operations can include: verifying whether the signature is correct; verifying whether the calculation of the actual amount change value of the above "remittance transaction that may cause a change in the amount" in the remittance transaction is correct and whether the interval proof is correct; the transfer amount and transfer of funds Whether the amounts are the same, etc., I will not repeat them here. In one embodiment, in addition to the separate verification of the remittance transaction included in each blockchain transaction, if the execution of the remittance transaction is triggered by participants such as the remittance party, the relay party, and the remittance party at the same time. The blockchain node also needs to verify whether each participant in the remittance transaction has implemented the trigger (that is, the blockchain transaction containing the remittance transaction is submitted). For example, FIG. 7 is a schematic diagram of a statistical trigger situation provided by an exemplary embodiment. As shown in Figure 7, based on the native function of the blockchain or the extended function provided by the smart contract, the blockchain nodes can record the blockchain transactions submitted by the institution 1 to the institution 4, such as the blockchain submitted by the institution 1. Transaction TX_a, TX_*, blockchain transaction TX_*, TX_b, TX_# submitted by institution 2, blockchain transaction TX_*, TX_c submitted by institution 3, blockchain transaction TX_d submitted by institution 4, etc.; and, block The chain node can extract the remittance transactions contained in each blockchain transaction, and perform statistics on the participants of each remittance transaction (the remittance transaction details include the information of the sender, relay party, and recipient): When the blockchain transaction submitted by the corresponding participant includes the remittance transaction, and the remittance transaction passes the above-mentioned individual verification, the participant can be marked as "OK". For example, since the blockchain transaction TX_a submitted by the device 1 contains the remittance transaction tx_i, if the content corresponding to the remittance transaction tx_i in the blockchain transaction TX_a is verified, the blockchain node can be marked as shown in Figure 6. Y1:OK"; similarly, if the blockchain nodes are also marked as “Y2:OK”, “Y3:OK”, “Y4:OK”, etc. for institutions 2~4, then the blockchain node can determine the The remittance transaction tx_i has been confirmed by all participants, and the remittance transaction tx_i can be marked as successful. For another example, since only the blockchain transactions submitted by device 1, device 2 and device 3 contain the relevant information of the remittance transaction tx_*, even if these information have been independently verified, the blockchain node can still only perform the remittance transaction tx_* adds the tags "Y1:OK", "Y2:OK", and "Y3:OK", and it needs to continue to wait for the blockchain transaction submitted by device 4. For another example, since only the blockchain transaction submitted by device 2 contains the relevant information of the remittance transaction tx_#, even if the relevant information has been independently verified, the blockchain node can still only add the tag "Y2:" to the remittance transaction tx_# OK", and need to continue to wait for the blockchain transaction submitted by Device 1, Device 3 and Device 4. Still taking the remittance transaction tx_i as an example, if any participant in Institution 1 to Institution 4 fails to submit a blockchain transaction containing the remittance transaction tx_i before the transaction time arrives, then the blockchain node will make the remittance transaction tx_i Mark it as a timeout state so that it cannot be successfully executed. If any participant in Institution 1~Institution 4 mentions the blockchain transaction containing the remittance transaction tx_i, but fails the individual verification due to errors in the amount accumulation details or error in the interval proof, then the blockchain node The remittance transaction tx_i will be marked as failed, so that it cannot be successfully executed. When the remittance transaction tx_i or other remittance transactions are marked with success status, failure status, or timeout status by the blockchain node, institution 1~institution 4 can refer to these statuses to generate the corresponding amount when subsequent blockchain transactions are generated Accumulating details, generating interval proofs with sufficient balances, etc. are similar to the process described in steps 404a to 404d above, and will not be repeated here. After confirming that the remittance transaction tx_i has been successfully executed, Institution 1 will receive 500 HKD from User 1 and transfer 500 HKD to Institution 2 outside the chain, Institution 2 will receive 500 HKD transferred in from Institution 1 and 56 Euros transferred to Institution 3. 3 Receiving 56 Euros transferred in by institution 2 and 64 US dollars transferred to institution 4, institution 4 receives 64 US dollars transferred in by institution 3, and transfers 64 US dollars to user 1 outside the chain, which is equivalent to the balance of institution 1~4. User 1 completes a 500 HKD remittance operation to user 2. The changes in the information shown on the blockchain ledger are: the blockchain account Y1 corresponding to institution 1 is updated to (currency_1, PC(a-t1, r_a-r_t1), Enc_A(a-t1), Enc_A(r_a- r_t1)), 500 Hong Kong dollars has been reduced; the corresponding blockchain account Y2 of Institution 2 is updated to: (currency_1, PC(b1+t1, r_b1+r_t1), Enc_B(b1+t1), Enc_B(r_b1+r_t1)), (currency_2, PC(b2-t2, r_b2-r_t2), Enc_B(b2-t2), Enc_B (r_b2-r_t2)), increased by 500 Hong Kong dollars and decreased by 56 Euros; the blockchain account Y3 corresponding to institution 3 is updated to : (Currency_2, PC(c1+t2, r_c1+r_t2), Enc_C(c1+t2), Enc_C(r_c1+r_t2)), (currency_3, PC(c2-t3, r_c2-r_t3), Enc_C(c2-t3) , Enc_C (r_c2-r_t3)), increased by 56 Euros and decreased by 64 US dollars; the corresponding blockchain account Y4 of Institution 4 is updated to: (currency_3, PC(d+t3, r_d+r_t3), Enc_D(d+t3 ), Enc_D(r_d+r_t3)), an increase of 64 USD. It should be pointed out that in the blockchain transactions submitted by device 1~device 4, not every remittance transaction is triggered by all participants; for example, at least one remittance transaction can use technical solutions in related technologies , That is, a certain participant collects the confirmation information of all participants on the transaction details of the remittance transaction, and generates the interval proof required for the transaction (that is, the multi-party trigger information described in the above embodiment is generated), and only the certain A participant submits a blockchain transaction including the remittance transaction. Fig. 8 is a schematic structural diagram of a device provided by an exemplary embodiment. Please refer to FIG. 8. At the hardware level, the device includes a processor 802, an internal bus 804, a network interface 806, a memory 808, and a non-volatile memory 810. Of course, it may also include hardware required for other services. The processor 802 reads the corresponding computer program from the non-volatile memory 810 to the memory 808 and then runs it to form a blockchain-based event processing device at the 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 FIG. 9, in the software implementation, the blockchain-based event processing device is applied to the participants, and may include: an adding unit 901, which maintains a wait for the participant according to the event participated by the participant The corresponding candidate sub-transaction is added to the queue; the generating unit 902 generates a corresponding collective transaction according to several candidate sub-transactions selected from the waiting queue; the submission unit 903 submits the collective transaction to the block Chain so that the candidate sub-transactions in the collective transaction are processed separately. Optionally, the generating unit 902 is specifically configured to: when the candidate sub-transactions in the waiting queue reach a preset number, select the candidate sub-transactions that already exist in the waiting queue to generate corresponding Collective transaction; or, periodically select the candidate sub-transactions that already exist in the waiting queue according to a preset duration to generate a corresponding collective transaction. Optionally, it further includes: an adding unit 904, which adds a corresponding number to each collective transaction in the order of generation, so that each collective transaction is processed sequentially in the blockchain according to the size of the corresponding number. Optionally, the candidate sub-transactions included in the collective transaction are set with a corresponding state change amount, so that after the candidate sub-transaction is processed, the state parameters of the participants respond accordingly based on the state change amount. The value changes. Optionally, the state change amount is a plain text value. Optionally, the candidate sub-transactions included in the collective transaction are further set with a pre-change state value and a post-change state value, so that after the candidate sub-transaction is processed, the state parameters of the participants are changed from the change The previous state value changes to the post-change state value via the state change amount; wherein the state change amount, the state value before the change, and the state value after the change are based on a homomorphic encryption algorithm or the same The ciphertext value calculated by the state commitment algorithm. Optionally, when the selected candidate subtransaction is used to increase the state value of the participant, the collective transaction further includes: first proof information, which is used to prove the state value increase A large number of them are in the correct value range; when the selected candidate subtransaction is used to reduce the state value of the participant, the collective transaction further includes: second proof information, which is used to prove the state value The reduced amount and the changed state value corresponding to the selected candidate sub-transaction are all within the correct value range. Optionally, when the collective transaction includes multiple candidate sub-transactions, adjacent candidate sub-transactions satisfy: the changed state value corresponding to the previous candidate sub-transaction and the previous candidate sub-transaction corresponding to the change before The status value is the same. Optionally, the candidate sub-transaction corresponding to the event includes the unilateral trigger information of the participant to the event; wherein, when all the participants of the event submit to the blockchain for the When the unilateral trigger information of the event is verified, the candidate sub-transaction corresponding to the event is triggered to be executed in the blockchain. Optionally, in the candidate sub-transaction corresponding to the event, all parties involved in the event include multi-party trigger information on the event; wherein, when the multi-party trigger information is verified, the event corresponding Alternative sub-transactions are triggered for execution in the blockchain. Fig. 10 is a schematic structural diagram of a device according to an exemplary embodiment. Please refer to FIG. 10, at the hardware level, the device includes a processor 1002, an internal bus 1004, a network interface 1006, a memory 1008, and a non-volatile memory 1010. Of course, it may also include hardware required for other services. The processor 1002 reads the corresponding computer program from the non-volatile memory 1010 to the memory 1008 and then runs it to form an event processing device based on the blockchain at the 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 11, in the software implementation, the blockchain-based event processing device is applied to a blockchain node, and may include: a receiving unit 1101, which receives a collective transaction submitted by a participant to the blockchain, the collective transaction Contains a number of candidate subtransactions selected from the waiting queue maintained by the participant, and the candidate subtransaction corresponds to the event in which the participant participates; the execution unit 1102 executes the collective transaction to The candidate sub-transactions in the collective transaction are processed separately. Optionally, it further includes: an extracting unit 1103, which extracts the serial number contained in the collective transaction, the serial number is added by the participant in the order of generation; the processing unit 1104, which submits to the participant according to the corresponding serial number The various collective transactions are processed in sequence. Optionally, the candidate sub-transactions included in the collective transaction are set with a corresponding state change amount, so that after the candidate sub-transaction is processed, the state parameters of the participants respond accordingly based on the state change amount. The value changes. Optionally, the state change amount is a plain text value. Optionally, the candidate sub-transactions included in the collective transaction are further set with a pre-change state value and a post-change state value, so that after the candidate sub-transaction is processed, the state parameters of the participants are changed from the change The previous state value changes to the post-change state value via the state change amount; wherein the state change amount, the state value before the change, and the state value after the change are based on a homomorphic encryption algorithm or the same The ciphertext value calculated by the state commitment algorithm. Optionally, when the selected candidate subtransaction is used to increase the state value of the participant, the collective transaction further includes: first proof information, which is used to prove the state value increase A large number of them are in the correct value range; when the selected candidate subtransaction is used to reduce the state value of the participant, the collective transaction further includes: second proof information, which is used to prove the state value The reduced amount and the changed state value corresponding to the selected candidate sub-transaction are all within the correct value range. Optionally, when the collective transaction includes multiple candidate sub-transactions, adjacent candidate sub-transactions satisfy: the changed state value corresponding to the previous candidate sub-transaction and the previous candidate sub-transaction corresponding to the change before The status value is the same. Optionally, the candidate sub-transaction corresponding to the event includes the unilateral trigger information of the participant to the event; wherein, when all the participants of the event submit to the blockchain for the When the unilateral trigger information of the event is verified, the candidate sub-transaction corresponding to the event is triggered to be executed in the blockchain. Optionally, in the candidate sub-transaction corresponding to the event, all parties involved in the event include multi-party trigger information on the event; wherein, when the multi-party trigger information is verified, the event corresponding Alternative sub-transactions are triggered for execution in the blockchain. 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. Console, tablet, wearable device, or a combination of any of these devices. This specification proposes a computer-readable medium on which computer instructions are stored. When the instructions are executed by a processor, the technical solutions of this specification are implemented, such as the blockchain-based event processing method in any of the above embodiments. Let me repeat them one by one. In a typical configuration, a computer includes one or more processors (CPU), input/output interfaces, network interfaces, and memory. Memory may include non-permanent memory in computer readable media, random access memory (RAM) and/or non-volatile memory, 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. Information can be computer-readable instructions, data structures, program modules, 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, read-only CD-ROM (CD-ROM), digital multi-function Optical disc (DVD) or other optical storage, magnetic cassette tape, magnetic sheet storage, quantum memory, graphene-based storage media or other magnetic storage devices or any other non-transmission media, which can be used to store data that can be accessed by computing devices Information. According to the definition in this article, computer-readable media does not include transitory media, such as modulated data signals and carrier waves. It should also be noted that the terms "include", "include" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, product or equipment including a series of elements not only includes those elements, but also includes Other elements that are not explicitly listed, or include elements inherent to this process, method, commodity, or equipment. If there are no more restrictions, the element defined by the sentence "including a..." does not exclude the existence of other identical elements in the process, method, commodity, or equipment that includes the element. The foregoing describes specific embodiments of this 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 from the embodiment and still achieve desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or sequential order shown in order to achieve the desired result. In some embodiments, multiplexing and parallel processing are also possible or may be advantageous. The terms used in one or more embodiments of this specification are only for the purpose of describing specific embodiments, and are not intended to limit one or more embodiments of this specification. The singular forms "a", "the" and "the" used in one or more embodiments of this specification and the scope of the appended patent application are also intended to include plural forms, unless the context clearly indicates other meanings. It should also be understood that the term "and/or" as used herein refers to and includes any or all possible combinations of one or more associated listed items. It should be understood that although the terms first, second, third, etc. may be used to describe various information in one or more embodiments of this specification, 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 can also be referred to as second information, and similarly, the second information can 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 a judgment". 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. Anything within the spirit and principle of one or more embodiments of this specification, Any modification, equivalent replacement, improvement, etc. made should be included in the protection scope of one or more embodiments of this specification.
