為了更好的理解上述技術方案，下面通過圖式以及具體實施例對本說明書實施例的技術方案做詳細的說明，應當理解本說明書實施例以及實施例中的具體特徵是對本說明書實施例技術方案的詳細的說明，而不是對本說明書技術方案的限定，在不衝突的情況下，本說明書實施例以及實施例中的技術特徵可以相互組合。
參見圖1，為本說明書實施例資料儲存的控制方法應用場景示意圖。客戶端10與區塊鏈系統20通訊，區塊鏈系統20從客戶端10接收資料並進行資料上鏈的操作。
區塊鏈是一種由多方共同維護，使用密碼學保證傳輸和存取安全，能夠實現資料一致儲存、防篡改、防抵賴的技術體系。典型的區塊鏈是以塊鏈結構實現資料儲存的。
區塊鏈上鏈的資料對即時性的要求程度不同，可區分為即時資料和非即時資料。即時資料一般是指業務資料，例如包括交易處理實時性要求較高的資料；非即時資料可以包括存證資料以及狀態描述資料，其中，存證資料是指用於索引業務資料或標記業務資料位置的資料，例如key/value（kv）資料；狀態描述資料是指描述業務資料狀態資訊的資料。
資料上鏈的過程包括三個階段：受理階段、共識階段和儲存階段。受理階段可以理解為待上鏈的資料被區塊鏈網路中的某一區塊鏈節點接收到，並由該區塊鏈節點受理該資料；共識階段可以理解為區塊鏈節點在受理該資料之後，需要由區塊鏈網路中的其他區塊鏈節點參與對該資料進行共識處理，資料通過共識後，可以進入儲存階段；儲存節點可以理解為區塊鏈節點將共識通過的資料進行上鏈處理。
本說明書實施例提供的資料儲存的控制方法，用於針對區塊鏈系統對非即時資料的儲存進行控制。
第一態樣，本說明書實施例提供一種資料儲存的控制方法，用於針對區塊鏈系統對非即時資料的儲存進行控制。請參考圖2，該資料儲存的控制方法包括S201-S205。
S201：接收非即時資料。
如前所述，非即時資料是指對即時性要求不高的資料，包括存證資料和狀態描述資料。
以存證資料為例，接收存證資料的具體過程，例如，區塊鏈系統從客戶端接收區塊鏈業務資料的存證資料。存證資料可以理解為是用於索引業務資料或標記業務資料位置的資料，例如包括key/value（kv）資料。區塊鏈存證業務是區塊鏈技術中重要的業務形式，旨在對於提交的某類交易資料進行資料歸檔，後續根據交易雜湊提供存在性證明。
S202：對非即時性資料進行驗證。
為了保證兩個區塊鏈節點之間傳輸資料的正確性及未更改，需要對資料進行驗證。交易雜湊（塊雜湊）是區塊鏈技術中利用特定的雜湊算法對交易或區塊頭進行雜湊運算所得的雜湊值，常用於檢索和驗證相關資訊。
驗證的過程例如包括：
在記錄交易的節點（記為：節點001），得到交易資訊（包括存證資料，或者還包括其他資料，例如交易資料），計算交易相關資訊的雜湊值001；“雜湊值001+私鑰”進行簽名運算產生一個簽名，對外廣播內容為“交易資訊+簽名”；
在驗證交易的節點（記為：節點002），由廣播得到上述“交易資訊+簽名”；通過節點001公鑰對簽名進行解密得到雜湊值001；對交易資訊進行雜湊計算得到雜湊值002；比對雜湊值001和雜湊值001是否一致，如果一致，則驗證通過，如果不一致，則驗證不通過。
本說明書實施例中，不論是針對記錄交易的節點或驗證交易的節點都適用，即，不論哪個節點，只要在驗證通過後，即執行步驟S203，立即啟動將非即時資料進行儲存的操作。
S203：在驗證通過後，將非即時資料儲存至區塊鏈系統的資料庫中。
區塊鏈技術中很核心的一部分是它的帳本資料庫。傳統資料庫使用CS（client-server）網路結構。這樣，用戶可以修改資料。同時，資料庫的控制權也在一個中心機構，比如公司或機構，它們對客戶端身份驗證之後，就會提供對資料庫的存取權限，傳統的資料庫有明顯的中心化服務的痕跡。區塊鏈資料庫則不同，它由多個分散式去中心化的節點組成。所有節點都參與資料管理，在帳本資料庫增加任何資料，都得到節點確認，這些帳本對於所有節點都是公開和透明的。就像比特幣的帳本中要增加交易資料，必須取得共識，在節點們確認後才能進入區塊。這種共識算法保證了網路的安全，也讓它不可篡改。共識的機制除了算力競爭的POW，還是授權證明POS和委託授權證明DPOS等。
在一種可選的實現方式中，可通過如下步驟實現對非即時資料的即時儲存：
（1）創建異步提交執行緒；
（2）當驗證通過後，立即啟動異步提交執行緒，將非即時資料插入至區塊鏈系統的資料庫中。
S204：對非即時資料進行共識處理。
S205：根據共識處理結果確定異常資料，並針對異常資料在資料庫的儲存進行管理。
由於本說明書實施例沒有考慮共識結果而將所有非即時資料儲存至資料庫，因此，為了保證資料的有效性，可根據共識結果對資料庫所儲存的共識失敗的資料進行管理。
在一種可選方式中，在驗證後，在進行非即時資料儲存的同時，進行共識處理。後續，根據共識結果，確定異常資料，並對異常資料在資料庫的儲存進行管理。
共識機制是區塊鏈技術中的一個核心機制。在區塊鏈裡，“共識”的意思是參與者就某一區塊鏈狀態達成共同的認識。由於區塊鏈是去中心化的，因此任何“決策/狀態/改變等”都要所有節點（參與者）一起使用某種機制來達成相同的認識，這就是區塊鏈的共識機制。共識機制也稱為共識算法。本說明書實施例中共識算法包括但不限於：工作量證明（PoW）、權益證明（POS）、股份授權證明（DPoS）、實用拜占庭容錯（PBFT）、授權拜占庭容錯（DBFT）等。
為了去除共識失敗的異常資料，首先需要根據共識結果確定出異常資料，並將異常資料對應的異常標記資訊插入到資料庫中；然後，在合適時機（例如資料庫空閒時），通過異常標記資訊，確定出異常資料並進行刪除等操作。
在一種可選方式中，根據共識處理結果確定異常資料，包括：
（1）將共識失敗或上鏈失敗的失敗區塊的非即時資料對應的異常標記資訊插入到資料庫；
（2）在資料庫中，通過異常標記資訊確定對應的異常資料。
其中，異常標記資訊是指用於標記異常的非即時資料的標誌資訊，例如包括異常雜湊值，或者，異常標記資訊除了包括異常雜湊值之外，還可以包括失敗區塊的塊高度資訊，附加上失敗區塊的塊高度資訊的目的在於，可以根據塊高度資訊來避免廣泛域上的雜湊碰撞。
在一種可選方式中，對異常資料在資料庫的儲存進行管理的過程可以是：在區塊鏈系統空閒時，或者在預定時間段內，或者在預定事件觸發下，對異常資料進行刪除。
例如，可以通過統計系統記憶體狀態確定系統是否儲於空閒狀態，並預先配置在空閒狀態對異常資料進行刪除操作；也可以預置異常資料刪除時間段，例如，設置一個固定時間段（例如淩晨一段時間）每週清理一次異常資料；或者，在某些特定事件（例如資料庫儲存能力不足）時，啟動對異常資料的刪除。
在一種可選方式中，可控制由不同節點分別執行S203（將非即時資料儲存至資料庫的步驟）和S204（對非即時資料進行共識處理的步驟），這樣處理的好處在於，通過將儲存及共識的操作分別在不同節點（實體設備）上處理，從而提高處理效率，例如，在節點A進行儲存控制的操作，在節點B進行共識處理的操作，由於儲存控制與電腦的輸入/輸出(I/O)性能緊密相關，而共識處理效率與電腦的CPU吞吐量緊密相關，因此可以選擇更適合上述兩個步驟的實體設備分別進行專門處理，互不影響，提高處理效率。當然，將上述兩個步驟放置在同一個實體設備上執行也是可行的。
可見，本說明書實施例中，為了保證達到高效儲存、提升系統吞吐量的目的，在資料驗證通過之後，立即啟動將非即時資料儲存至資料庫的操作，而不是等待其他操作（例如共識處理、虛擬機處理等）完成後才進行儲存，這種打破原有的從共識排序到資料落盤寫入順序的方式，可達成高效的集群系統邏輯並行，從而顯著提升系統吞吐量，尤其適用於分散式架構的聯盟鏈。
參見圖3，為本說明書實施例第一態樣的資料儲存控制方法實例示意圖。
在該實例中，以區塊鏈系統的分散式kv資料庫為例，對存證資料的儲存進行說明。分散式kv（key/value）亦稱為分散式鍵值對儲存，是指集群式多機維護的kv資料庫系統，資料存放在網路各節點上，而非單機kv儲存。
首先，在步驟301，區塊鏈系統從客戶端接收到存證資料；然後，在步驟302，對存證資料進行驗證；在步驟303，將存證資料插入至kv資料庫；在步驟303的執行過程中，可同時執行步驟304：對存證資料進行共識處理；步驟305：將共識處理後的資料經過虛擬機進行計算；步驟306：根據異常標記資訊更新kv資料庫；步驟307：kv資料庫根據異常標記資訊對異常存證資料進行異步清理，例如，系統空閒時，根據本地異常標記資訊，通過實用程式將無效的Tx-hash鍵值對資料從交易資料庫中異步進行刪除清理。
可見，在該實例中，針對存證業務型交易雜湊鍵值對資料，通過打破正常從共識排序到資料落盤寫入順序的相應技術和方式，在雜湊計算後立即異步提交給分散式kv系統進行資料寫入，使得本地共識過程和分散式kv資料寫入過程同步並行，達成高效的集群系統邏輯並行從而顯著提升系統吞吐量性能，對於共識失敗的交易存本地文件，後序異步實用程式在系統閒時集中清理資料庫；本說明書實施例適用於聯盟鏈區塊鏈系統（Permissioned），尤其實用分散式架構的聯盟鏈、區塊鏈系統。
第二態樣，基於同一發明構思，本說明書實施例提供一種資料儲存的控制裝置，用於針對區塊鏈系統對非即時資料的儲存進行控制，請參考圖4，所述裝置包括：
資料接收單元401，用於接收非即時資料；
驗證單元402，用於對非即時資料進行驗證；
儲存控制單元403，用於在所述驗證通過後，將所述非即時資料儲存至所述區塊鏈系統的資料庫中；
共識單元404，用於對非即時資料進行共識處理；
異常資料確定單元405，用於根據共識處理結果確定異常資料；
異常管理單元406，用於對所述異常資料在所述資料庫的儲存進行管理。在一種可選方式中，還包括：
異步提交執行緒創建單元407，用於創建異步提交執行緒；
儲存控制單元403通過啟動所述異步提交執行緒，將所述非即時資料插入至所述區塊鏈系統的資料庫中。
在一種可選方式中，所述異常資料確定單元405具體用於：將共識失敗或上鏈失敗的失敗區塊的非即時資料對應的異常標記資訊插入到所述資料庫；以及，在所述資料庫中，通過所述異常標記資訊確定對應的異常資料。
在一種可選方式中，所述異常標記資訊包括異常雜湊值，或者，所述異常標記資訊包括異常雜湊值及失敗區塊的塊高度資訊。
在一種可選方式中，所述對異常管理單元406具體用於：在所述區塊鏈系統空閒時，或者在預定時間段內或根據預定事件觸發下，對所述異常資料進行刪除。
在一種可選方式中，所述儲存控制單元403和所述共識單元404分別由不同節點執行。
在一種可選方式中，所述非即時資料封包括存證資料或狀態描述資料。
第三態樣，基於與前述實施例中資料儲存控制方法同樣的發明構思，本發明還提供一種伺服器，如圖5所示，包括儲存器504、處理器502及儲存在儲存器504上並可在處理器502上運行的電腦程式，所述處理器502執行所述程式時實現前文所述資料儲存的控制方法的任一方法的步驟。
其中，在圖5中，匯流排架構（用匯流排500來代表），匯流排500可以包括任意數量的互聯的匯流排和橋，匯流排500將包括由處理器502代表的一個或多個處理器和儲存器504代表的儲存器的各種電路鏈接在一起。匯流排500還可以將諸如外圍設備、穩壓器和功率管理電路等之類的各種其他電路鏈接在一起，這些都是本領域所公知的，因此，本文不再對其進行進一步描述。匯流排介面506在匯流排500和接收器501和發送器503之間提供介面。接收器501和發送器503可以是同一個元件，即收發機，提供用於在傳輸媒體上與各種其他裝置通訊的單元。處理器502負責管理匯流排500和通常的處理，而儲存器504可以被用於儲存處理器502在執行操作時所使用的資料。
第四態樣，基於與前述實施例中資料儲存控制方法的發明構思，本發明還提供一種電腦可讀儲存媒體，其上儲存有電腦程式，該程式被處理器執行時實現前文所述資料儲存的控制方法的任一方法的步驟。
本說明書是參照根據本說明書實施例的方法、設備（系統）、和電腦程式產品的流程圖和／或方框圖來描述的。應理解可由電腦程式指令實現流程圖和／或方框圖中的每一流程和／或方框、以及流程圖和／或方框圖中的流程和／或方框的結合。可提供這些電腦程式指令到通用電腦、專用電腦、嵌入式處理機或其他可程式化資料處理設備的處理器以產生一個機器，使得通過電腦或其他可程式化資料處理設備的處理器執行的指令產生用於實現在流程圖一個流程或多個流程和／或方框圖一個方框或多個方框中指定的功能的設備。
這些電腦程式指令也可儲存在能引導電腦或其他可程式化資料處理設備以特定方式工作的電腦可讀儲存器中，使得儲存在該電腦可讀儲存器中的指令產生包括指令設備的製造品，該指令設備實現在流程圖一個流程或多個流程和／或方框圖一個方框或多個方框中指定的功能。
這些電腦程式指令也可裝載到電腦或其他可程式化資料處理設備上，使得在電腦或其他可程式化設備上執行一系列操作步驟以產生電腦實現的處理，從而在電腦或其他可程式化設備上執行的指令提供用於實現在流程圖一個流程或多個流程和／或方框圖一個方框或多個方框中指定的功能的步驟。
儘管已描述了本說明書的較佳實施例，但所屬技術領域中具有通常知識者一旦得知了基本創造性概念，則可對這些實施例作出另外的變更和修改。所以，所附請求項意欲解釋為包括較佳實施例以及落入本說明書範圍的所有變更和修改。
顯然，所屬技術領域中具有通常知識者可以對本說明書進行各種改動和變型而不脫離本說明書的精神和範圍。這樣，倘若本說明書的這些修改和變型屬於本說明書請求項及其等同技術的範圍之內，則本說明書也意圖包含這些改動和變型在內。
In order to better understand the above technical solutions, the technical solutions of the embodiments of this specification are described in detail below through the drawings and specific embodiments. It should be understood that the embodiments of this specification and the specific features in the embodiments are of the technical solutions of the embodiments of this specification. The detailed description is not a limitation on the technical solutions of this specification. The embodiments of this specification and the technical features in the embodiments can be combined with each other if there is no conflict.
Refer to Fig. 1, which is a schematic diagram of an application scenario of the control method for data storage in the embodiment of this specification. The client 10 communicates with the blockchain system 20, and the blockchain system 20 receives data from the client 10 and performs the operation of uploading the data to the chain.
Blockchain is a technology system that is jointly maintained by multiple parties, uses cryptography to ensure the security of transmission and access, and can achieve consistent data storage, tamper-proof, and non-repudiation. A typical blockchain implements data storage in a blockchain structure.
The data on the blockchain has different requirements for real-time, which can be divided into real-time data and non-real-time data. Real-time data generally refers to business data, such as data with high real-time requirements for transaction processing; non-real-time data can include certificate data and status description data, among which, certificate data refers to indexing business data or marking the location of business data Data, such as key/value (kv) data; state description data refers to data describing the state information of business data.
The process of data on-chain includes three stages: acceptance stage, consensus stage and storage stage. The acceptance phase can be understood as the data to be chained is received by a blockchain node in the blockchain network, and the blockchain node accepts the data; the consensus phase can be understood as the blockchain node is accepting the data After the data, other blockchain nodes in the blockchain network need to participate in the consensus processing of the data. After the data has passed the consensus, it can enter the storage stage; the storage node can be understood as the blockchain node to process the consensus data On-chain processing.
The data storage control method provided in the embodiments of this specification is used to control the storage of non-real-time data for the blockchain system.
In the first aspect, the embodiment of this specification provides a data storage control method for controlling the storage of non-real-time data for the blockchain system. Please refer to FIG. 2, the control method of the data storage includes S201-S205.
S201: Receive non-real-time data.
As mentioned earlier, non-real-time data refers to data that does not require high real-timeness, including evidence data and status description data.
Take the certificate data as an example, the specific process of receiving the certificate data, for example, the blockchain system receives the certificate data of the blockchain business data from the client. Attestation data can be understood as data used to index business data or mark the location of business data, such as key/value (kv) data. Blockchain deposit certificate business is an important form of business in blockchain technology, which aims to archive certain types of transaction materials submitted, and subsequently provide proof of existence based on transaction hashes.
S202: Verify non-real-time data.
In order to ensure that the data transmitted between the two blockchain nodes is correct and unchanged, the data needs to be verified. Transaction hash (block hash) is a hash value obtained by hashing transactions or block headers using a specific hash algorithm in blockchain technology, and is often used to retrieve and verify relevant information.
The verification process includes, for example:
At the node that records the transaction (denoted as: node 001), obtain transaction information (including certificate data, or other data, such as transaction data), and calculate the hash value of transaction-related information 001; "Hash value 001 + private key" Perform a signature calculation to generate a signature, and the external broadcast content is "transaction information + signature";
At the node verifying the transaction (denoted as: node 002), the above "transaction information + signature" is obtained by broadcasting; the signature is decrypted by the node 001 public key to obtain the hash value 001; the hash value 002 is obtained by hash calculation on the transaction information; Whether the hash value 001 and the hash value 001 are consistent, if they are consistent, the verification is passed; if they are inconsistent, the verification is not passed.
In the embodiment of this specification, it is applicable to nodes that record transactions or nodes that verify transactions, that is, no matter which node, as long as the verification is passed, step S203 is executed to immediately start the operation of storing non-real-time data.
S203: After the verification is passed, store the non-real-time data in the database of the blockchain system.
A core part of blockchain technology is its ledger database. The traditional database uses CS (client-server) network structure. In this way, the user can modify the information. At the same time, the control of the database is also in a central organization, such as a company or organization. After they authenticate the client's identity, they will provide access to the database. The traditional database has obvious traces of centralized services. The blockchain database is different, it consists of multiple decentralized nodes. All nodes participate in data management. Any data added to the ledger database is confirmed by the node. These ledger books are open and transparent to all nodes. Just like the addition of transaction data to the Bitcoin ledger, a consensus must be obtained, and the block can be entered after the nodes confirm it. This consensus algorithm guarantees the security of the network and makes it immutable. The consensus mechanism is not only the POW of computing power competition, but also the authorization certification POS and the entrusted authorization certification DPOS.
In an optional implementation manner, real-time storage of non-real-time data can be realized through the following steps:
(1) Create asynchronous submission thread;
(2) After the verification is passed, the asynchronous submission thread is immediately started, and the non-real-time data is inserted into the database of the blockchain system.
S204: Perform consensus processing on non-real-time data.
S205: Determine the abnormal data according to the consensus processing result, and manage the storage of the abnormal data in the database.
Since the embodiments of this specification do not consider the consensus result and store all non-real-time data in the database, in order to ensure the validity of the data, the consensus failure data stored in the database can be managed according to the consensus result.
In an optional method, after verification, consensus processing is performed while storing non-real-time data. Later, according to the consensus results, the abnormal data is determined, and the storage of the abnormal data in the database is managed.
The consensus mechanism is a core mechanism in blockchain technology. In the blockchain, "consensus" means that participants reach a common understanding of the state of a certain blockchain. Since the blockchain is decentralized, any "decision/state/change, etc." requires all nodes (participants) to use a certain mechanism to reach the same understanding. This is the consensus mechanism of the blockchain. Consensus mechanism is also called consensus algorithm. The consensus algorithms in the embodiments of this specification include but are not limited to: Proof of Work (PoW), Proof of Rights (POS), Proof of Share Authorization (DPoS), Practical Byzantine Fault Tolerance (PBFT), Authorized Byzantine Fault Tolerance (DBFT), etc.
In order to remove the abnormal data from the consensus failure, first determine the abnormal data according to the consensus result, and insert the abnormal mark information corresponding to the abnormal data into the database; then, at the right time (for example, when the database is idle), pass the abnormal mark information , Determine the abnormal data and delete it.
In an optional way, the abnormal data is determined based on the consensus processing result, including:
(1) Insert the abnormal mark information corresponding to the non-real-time data of the failed block that failed consensus or failed to upload into the database;
(2) In the database, determine the corresponding abnormal data through the abnormal mark information.
Among them, the abnormal mark information refers to the mark information used to mark abnormal non-real-time data, such as including abnormal hash value, or, in addition to abnormal hash value, abnormal mark information may also include block height information of failed blocks, and The purpose of the block height information of the failed block is to avoid hash collisions in a wide range based on the block height information.
In an optional manner, the process of managing the storage of the abnormal data in the database may be: deleting the abnormal data when the blockchain system is idle, or within a predetermined time period, or triggered by a predetermined event.
For example, you can determine whether the system is stored in the idle state by counting the system memory status, and pre-configure the abnormal data to delete the abnormal data in the idle state; you can also preset the abnormal data deletion time period, for example, set a fixed time period (such as early morning). A period of time) The abnormal data is cleaned up once a week; or, when certain events (such as insufficient database storage capacity), the deletion of abnormal data is initiated.
In an optional method, different nodes can be controlled to execute S203 (the step of storing non-real-time data in the database) and S204 (the step of consensus processing on non-real-time data). The advantage of this processing is that by storing And consensus operations are processed on different nodes (physical devices) to improve processing efficiency. For example, the storage control operation at node A, the consensus processing operation at node B, due to storage control and computer input/output ( I/O) performance is closely related, and the consensus processing efficiency is closely related to the computer's CPU throughput. Therefore, physical devices that are more suitable for the above two steps can be selected for special processing without affecting each other and improving processing efficiency. Of course, it is also feasible to place the above two steps on the same physical device.
It can be seen that in the embodiments of this specification, in order to ensure efficient storage and improve system throughput, after data verification is passed, the operation of storing non-real-time data in the database is started immediately, instead of waiting for other operations (such as consensus processing, Storage is performed after the completion of virtual machine processing, etc. This method of breaking the original sequence from consensus sorting to data placement and writing can achieve efficient cluster system logic parallelism, thereby significantly improving system throughput, especially suitable for distributed systems Architecture of the alliance chain.
Refer to FIG. 3, which is a schematic diagram of an example of a data storage control method in the first aspect of the embodiment of this specification.
In this example, the distributed kv database of the blockchain system is taken as an example to illustrate the storage of evidence data. Distributed kv (key/value) is also known as distributed key-value pair storage. It refers to a clustered multi-machine maintenance kv database system. Data is stored on each node of the network instead of a stand-alone kv storage.
First, in step 301, the blockchain system receives the certificate data from the client; then, in step 302, the certificate data is verified; in step 303, the certificate data is inserted into the kv database; in step 303 During the execution process, step 304: perform consensus processing on the evidence data; step 305: calculate the data after the consensus processing through the virtual machine; step 306: update the kv database according to the abnormal flag information; step 307: kv data The library asynchronously cleans the abnormal deposit data based on the abnormal tag information. For example, when the system is idle, according to the local abnormal tag information, the invalid Tx-hash key pair data is asynchronously deleted from the transaction database through the utility program.
It can be seen that in this example, for the hash key-value pair data of the deposit certificate business transaction, through the corresponding technology and method from the normal order from the consensus to the data placement and writing sequence, the hash calculation is immediately submitted to the distributed kv system asynchronously. Data writing makes the local consensus process and the distributed kv data writing process synchronously parallel, and achieves efficient cluster system logic parallelism, which significantly improves system throughput performance. Local files are stored for transactions that fail consensus, and the subsequent asynchronous utility program is in the system Centrally clean up the database at leisure; the embodiments of this specification are suitable for the alliance chain blockchain system (Permissioned), especially the alliance chain and blockchain system with a distributed architecture.
In the second aspect, based on the same inventive concept, an embodiment of this specification provides a data storage control device for controlling the storage of non-real-time data in a blockchain system. Please refer to FIG. 4, the device includes:
The data receiving unit 401 is used to receive non-real-time data;
The verification unit 402 is used to verify non-real-time data;
The storage control unit 403 is configured to store the non-real-time data in the database of the blockchain system after the verification is passed;
The consensus unit 404 is used to perform consensus processing on non-real-time data;
The abnormal data determining unit 405 is used to determine abnormal data according to the consensus processing result;
The abnormality management unit 406 is used to manage the storage of the abnormal data in the database. In an optional way, it also includes:
The asynchronous submission thread creation unit 407 is used to create an asynchronous submission thread;
The storage control unit 403 inserts the non-real-time data into the database of the blockchain system by activating the asynchronous submission thread.
In an optional manner, the abnormal data determining unit 405 is specifically configured to: insert the abnormal mark information corresponding to the non-real-time data of the failed block that fails the consensus or the uploading failure into the database; and In the database, the corresponding abnormal data is determined by the abnormal mark information.
In an optional manner, the abnormal mark information includes an abnormal hash value, or the abnormal mark information includes an abnormal hash value and block height information of a failed block.
In an optional manner, the abnormality management unit 406 is specifically configured to delete the abnormal data when the blockchain system is idle, or within a predetermined time period or triggered by a predetermined event.
In an optional manner, the storage control unit 403 and the consensus unit 404 are respectively executed by different nodes.
In an optional manner, the non-real-time data seal includes certificate data or status description data.
In the third aspect, based on the same inventive concept as the data storage control method in the previous embodiment, the present invention also provides a server, as shown in FIG. 5, including a storage 504, a processor 502, and a storage device 504 A computer program that can run on the processor 502, and when the processor 502 executes the program, the steps of any method of the data storage control method described above are realized.
Among them, in Figure 5, the bus architecture (represented by the bus 500), the bus 500 may include any number of interconnected bus bars and bridges, the bus 500 will include one or more processing represented by the processor 502 The various circuits of the storage represented by the storage and storage 504 are linked together. The bus bar 500 may also link various other circuits such as peripheral devices, voltage regulators, and power management circuits, etc., which are all known in the art, and therefore, will not be further described herein. The bus interface 506 provides an interface between the bus 500 and the receiver 501 and transmitter 503. The receiver 501 and the transmitter 503 may be the same element, namely a transceiver, which provides a unit for communicating with various other devices on the transmission medium. The processor 502 is responsible for managing the bus 500 and general processing, and the storage 504 can be used to store data used by the processor 502 when performing operations.
In a fourth aspect, based on the inventive concept of the data storage control method in the foregoing embodiment, the present invention also provides a computer-readable storage medium on which a computer program is stored, and when the program is executed by a processor, the data storage described above is realized The steps of any method of the control method.
This specification is described with reference to flowcharts and/or block diagrams of methods, equipment (systems), and computer program products according to the embodiments of this specification. It should be understood that each process and/or block in the flowchart and/or block diagram, and the combination of processes and/or blocks in the flowchart and/or block diagram can be realized by computer program instructions. These computer program instructions can be provided to the processors of general-purpose computers, dedicated computers, embedded processors, or other programmable data processing equipment to generate a machine that can be executed by the processors of the computer or other programmable data processing equipment Produce equipment for realizing the functions specified in one or more processes in the flowchart and/or one block or more in the block diagram.
These computer program instructions can also be stored in a computer-readable storage that can guide a computer or other programmable data processing equipment to work in a specific manner, so that the instructions stored in the computer-readable storage produce a manufactured product including the instruction device , The instruction device realizes the functions specified in one process or multiple processes in the flowchart and/or one block or multiple blocks in the block diagram.
These computer program instructions can also be loaded on a computer or other programmable data processing equipment, so that a series of operation steps are executed on the computer or other programmable equipment to produce computer-implemented processing, so that the computer or other programmable equipment The instructions executed above provide steps for implementing functions specified in a flow or multiple flows in the flowchart and/or a block or multiple blocks in the block diagram.
Although the preferred embodiments of this specification have been described, those skilled in the art can make additional changes and modifications to these embodiments once they learn the basic creative concepts. Therefore, the appended claims are intended to be interpreted as including preferred embodiments and all changes and modifications falling within the scope of this specification.
Obviously, a person with ordinary knowledge in the technical field can make various changes and modifications to this specification without departing from the spirit and scope of this specification. In this way, if these modifications and variations of this specification fall within the scope of the claims of this specification and their equivalent technologies, this specification is also intended to include these modifications and variations.