CN113157522B - Method, system, device and storage medium for preventing loss of event based on alliance chain - Google Patents
Method, system, device and storage medium for preventing loss of event based on alliance chain Download PDFInfo
- Publication number
- CN113157522B CN113157522B CN202110430469.9A CN202110430469A CN113157522B CN 113157522 B CN113157522 B CN 113157522B CN 202110430469 A CN202110430469 A CN 202110430469A CN 113157522 B CN113157522 B CN 113157522B
- Authority
- CN
- China
- Prior art keywords
- event
- block
- eventmap
- monitoring
- lock
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
- G06F11/3006—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is distributed, e.g. networked systems, clusters, multiprocessor systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3055—Monitoring arrangements for monitoring the status of the computing system or of the computing system component, e.g. monitoring if the computing system is on, off, available, not available
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computing Systems (AREA)
- Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Mathematical Physics (AREA)
- Computer And Data Communications (AREA)
Abstract
The invention provides an event loss prevention method and system based on a alliance chain, which specifically comprise the following steps: responding to an action of triggering network restart, and acquiring block numbers from an EventMap and a database, wherein the EventMap is used for recording events in each block, each block comprises a plurality of events, and the blocks correspond to the block numbers one by one; judging whether the event is lost or not based on whether the block number is empty or not, and monitoring the blocks of the alliance chain network based on the judgment result of the block number; if the block number is empty, monitoring is started from the latest block of the alliance chain network, otherwise, monitoring is started from the block corresponding to the block number; and storing the monitored block number into an EventMap and a database. The invention solves the problem of event loss after restarting, uses the event monitoring mechanism to replace the previous round training mechanism to acquire the information on the chain in real time, uses the distributed lock to solve the problem of event repeated triggering under the condition of multiple back ends, and uses the power idempotency of breakpoint resuming and proposal execution to ensure that the event can not be lost.
Description
Technical Field
The invention relates to the technical field of block chains, in particular to an event loss prevention method, system and device based on a alliance chain and a storage medium.
Background
With the advent of digital cryptocurrency systems represented by Bitbin, blockchain technology has been developed rapidly, and many enterprises are now using alliance-link network services based on Fabric, which is one of the services provided by Fabric. Generally, an Event (Event) refers to an action or Event detected by a program. The event package supports access to channel events on the Fabric network. The event client may receive a block event, a filter block event, a chain code event, and a transaction status event. The user clicks a mouse button is an example of an event and the program must have implemented some event listener to listen to the event and take some action when the event occurs. In Fabric, there are three types of event listeners to listen for events: block listener, transaction listener, chain code listener.
However, these event monitoring are short-lived, and in a network with multiple organizations in a federation chain, a single organization stops event monitoring service due to abnormal conditions such as system downtime or service interruption, and the monitor misses the monitored events after restarting and misses the events occurring during the stop.
Disclosure of Invention
Based on the problems in the background art, the invention provides an event loss prevention method, an event loss prevention system, an event loss prevention device and a storage medium based on a federation chain.
An event loss prevention method based on a alliance chain specifically comprises the following steps:
responding to an action of triggering network restart, and acquiring block numbers from an EventMap and a database, wherein the EventMap is used for recording events in each block, each block comprises a plurality of events, and the blocks correspond to the block numbers one by one;
judging whether the event is lost or not based on whether the block number is empty or not, and monitoring the blocks of the alliance chain network based on the judgment result of the block number;
if the block is empty, monitoring is started from the newest block of the alliance chain network, otherwise, monitoring is started from the incoming block;
and storing the monitored block number into the EventMap and a database.
As one possible implementation, storing the monitored block number in EventMap includes: and taking the block number as the value of the EventMap, acquiring the txID and the block number of the event in the block in the EventMap, if the txID and the block number of the event in the block are not obtained, storing the txID and the block number of the event in the block, and if the txID and the block number of the event in the EventMap are obtained, deleting the txID and the block number of the event in the EventMap, wherein the event corresponds to the transaction one to one, and the txID of the transaction is taken as the Key of the EventMap.
As an implementable mode, the method further comprises the following steps: after the txID and the block number of the event block are deleted each time, the EventMap is traversed, and the minimum block number is stored in the database.
As an implementation manner, the method further comprises the step of filtering out unqualified events, wherein the unqualified events comprise any one of invalid transaction events, non-transaction events and unregistered transaction events; the method specifically comprises the following steps: judging whether the transaction is qualified, if so, storing the event into the EventMap; if not, the event is filtered.
As an implementation, the method further comprises the following steps: if multiple back ends and multiple events exist, a distributed lock is adopted to ensure that one back end opening event and only one back end opening event are monitored.
As one implementable way, the distributed lock includes an extended lock and a delete deadlock; at any time, the extended lock queries whether the database has a lock meeting a first condition according to the lock name and the ClientId, and if so, the extended lock updates ValidTime +10 seconds, wherein the first condition is that the current time is > CreatTime + ValidTime-5 seconds; and at any time, deleting the deadlock, inquiring whether a lock meeting a second condition exists in the database or not according to the lock name, and if so, deleting the deadlock, wherein the second condition is that the current time is > CreatTime + VaildTime.
An event loss prevention system based on a alliance chain comprises a data acquisition module, a coding judgment module, an execution monitoring module and a number storage module;
the data acquisition module is used for responding to an action of triggering network restart and acquiring block numbers from an EventMap and a database, wherein the EventMap is used for recording events in each block, each block comprises a plurality of events, and the blocks correspond to the block numbers one by one;
the coding judgment module judges whether the event is lost or not based on whether the block number is empty or not, and monitors the blocks of the alliance chain network based on the judgment result of the block number;
the execution monitoring module is configured to: if the block is empty, monitoring is started from the newest block of the alliance chain network, otherwise, monitoring is started from the incoming block;
and the number storage module is used for storing the monitored block numbers into the EventMap and the database.
As an implementable embodiment, the distributed lock execution module is further configured to:
if multiple back ends and multiple events exist, a distributed lock is adopted to ensure that one back end opening event is monitored and only one back end opening event is monitored;
the distributed lock comprises an extended lock and a delete deadlock; at any time, the extended lock queries whether the database has a lock meeting a first condition according to the lock name and the ClientId, and if so, the extended lock updates ValidTime +10 seconds, wherein the first condition is that the current time is > CreatTime + ValidTime-5 seconds; and at any time, deleting the deadlock, inquiring whether a lock meeting a second condition exists in the database or not according to the lock name, and if so, deleting the deadlock, wherein the second condition is that the current time is > CreatTime + VaildTime.
A computer-readable storage medium, in which a computer program is stored which, when being executed by a processor, carries out the method steps of:
responding to an action of triggering network restart, and acquiring block numbers from an EventMap and a database, wherein the EventMap is used for recording events in each block, each block comprises a plurality of events, and the blocks correspond to the block numbers one by one;
judging whether the event is lost or not based on whether the block number is empty or not, and monitoring the blocks of the alliance chain network based on the judgment result of the block number;
if the block is empty, monitoring is started from the newest block of the alliance chain network, otherwise, monitoring is started from the incoming block;
and storing the monitored block number into an EventMap and a database.
A federation chain-based event loss prevention apparatus comprising a memory, a processor and a computer program stored in the memory and executable on the processor, wherein the processor implements the following method steps when executing the computer program:
responding to an action of triggering network restart, and acquiring block numbers from an EventMap and a database, wherein the EventMap is used for recording events in each block, each block comprises a plurality of events, and the blocks correspond to the block numbers one by one;
judging whether the event is lost or not based on whether the block number is empty or not, and monitoring the blocks of the alliance chain network based on the judgment result of the block number;
if the block is empty, monitoring is started from the newest block of the alliance chain network, otherwise, monitoring is started from the incoming block;
and storing the monitored block number into an EventMap and a database.
In a network with a plurality of organizations in a federation chain, a single organization stops event monitoring services due to abnormal conditions such as system downtime or service interruption, and events occurring during the stop period are omitted after the single organization is restarted. The method and the system for preventing the event from being lost in the allied link network solve the problem of event loss after restarting, use an event monitoring mechanism to replace a previous round-robin training mechanism to acquire messages on the link in real time, use a distributed lock to solve the problem of event repeated triggering under the condition of multiple back ends, and use power idempotent of breakpoint repetition and proposal execution to ensure that the event cannot be lost.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings without creative efforts.
FIG. 1 is a flow diagram of event monitoring in one embodiment;
FIG. 2 is a flow diagram illustrating the filter block event and chain code event monitoring process in one embodiment;
FIG. 3 is a flow diagram of distributed lock operations in an embodiment.
Detailed Description
To make the objects, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
In the description herein, references to the description of "an embodiment," "a particular embodiment," "an embodiment," "for example," mean that a particular feature, structure, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the application. In this specification, the schematic representations of the terms used above do not necessarily refer to the same embodiment or example. Furthermore, the particular features, structures, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. The sequence of steps involved in the embodiments is for illustrative purposes to illustrate the implementation of the present application, and the sequence of steps is not limited and can be adjusted as needed.
The Event package supports access to channel events on the Fabric network. The event client may receive a block event, a filter block event, a chain code event, and a transaction status event.
The basic flow of the event monitoring service usage comprises the following steps:
A. creating an event client;
B. registering an event;
C. processing the event;
D. and logging out the event.
Before registering a chain code event, the event must be thrown by calling stub.SetEvent (evenName string, payload [ ] byte) under the corresponding chain code, wherein the registered event name is consistent with the event name of the SetEvent.
The method and the system for preventing the loss of the event based on the alliance chain solve the problem of the loss of the event after restarting, use an event monitoring mechanism to replace a previous round training mechanism to acquire the message on the chain in real time, use a distributed lock to solve the problem of repeated triggering of the event under the condition of multiple back ends, and use the idempotent of breakpoint resumption and proposal execution to ensure that the event cannot be lost.
Fig. 1 is a schematic diagram of an event monitoring process in an embodiment of the present invention, where the process specifically includes:
(1) When a new alliance-link network is started, starting an event monitor, and monitoring from the latest block;
(2) Recording the monitored block numbers in the monitoring process and storing the block numbers into an EventMap and a database;
(3) When the system is restarted, acquiring a block number from a database, judging whether the block number is empty, if so, starting monitoring from the latest block, and otherwise, starting monitoring from the transmitted block number;
(4) And recording the monitored block number and storing the monitored block number into an EventMap and a database.
EventMap: and the map is used for storing and searching the event, the txID of the transaction corresponding to the event is used as the Key of the EventMap, and the block number is used as the value of the EventMap.
A stub event method needs to be called in chain code to set an event when processing a chain code event, and the contents are as follows:
1.//SetEvent documentation canbe found in interfaces.go
2.func(stub*ChaincodeStub)SetEvent(name string,payload[]byte)error{
3.ifname＝＝""{
4.return errors.New("event name can not be nil string")
5.}
6.stub.chaincodeEvent＝&pb.ChaincodeEvent{EventName:name,Payload:payload}
7.return nil
8.}
it can be seen that the essence of the method is the assignment of stub.chaincodeevent, and only the last call of calling multiple stub.setevent in one transaction will take effect, thus obtaining that one transaction corresponds to one event. Based on the above conclusion, the txID is used as Key of the EventMap, and the block number is used as value of the EventMap, so as to ensure that the event recorded by the EventMap is unique.
The Fabric provides an interface for creating event client services, and when creating an event client, attention needs to be paid to the construction of a ClientOption option:
1.func WithBlockEvents()ClientOption
withblockevents indicate block events to receive. Note that the caller must have sufficient rights to this option.
3.func WithBlockNum(from uint64)ClientOption
Withblocknum denotes a block number for receiving an event. Only delivercient supports sub-options.
5.func WithSeekType(seek seek.Type)ClientOption
Withseektype denotes the type of search required, newest, oldest or fromb, which is supported only by deliveryclient.
As long as the block number and the search type where the reception event is configured are fromoblock, the peer node will pull from the specified block number when pulling the block, thereby preventing the occurrence of event loss due to a missed block.
Under the current conditions, consideration needs to be given to how to guarantee that the specified block number is the last block to be executed when the snoop is stopped. The solution to this is as follows:
monitoring through a filter block, searching the obtained txID and block number of the event block in the EventMap, and if the txID and the block number are not stored, deleting the event block if the txID and the block number are not stored;
after the chain code event is processed, searching the txID and the block number of the event block in the EventMap, and if the txID and the block number are not stored, deleting the event block if the txID and the block number are not stored;
and traversing the EventMap once for each deletion, and storing the minimum block number into the database.
When the filter block is monitored, invalid transactions, transactions without events and unregistered transactions are filtered, useless data can remain if EventMap is not filtered, so that the block of the database cannot be updated, because chain code event monitoring can automatically filter out invalid transactions and only process registered events. Fig. 2 is a schematic diagram illustrating a filter block event and chain code event listening flow. When a new event monitoring is started, if the event is a filter block event, judging whether the transaction is valid, whether the transaction has the event and whether the event in the transaction is registered, if so, storing the event into an eventMap, and if not, filtering the event; and if the event is the chain code event, normally processing the event, storing the event into the EventMap, and then storing the event into the database. Examples of events are shown below:
wherein:
1.type EventInstence struct{
client event client
ClosCCNotify chan pool// close event snooping
RegisterEventMap map [ string ]/record the registered chain code event
Eventmap map [ string ] uint64// record events in the run
6.}
Closscnotify is used to turn off event snooping;
the register EventMap is used for recording the registered chain code events and is used for screening the events when the filtering block is monitored, so that the event which is not used is prevented from being recorded in the EventMap;
EventMap takes txID as key and block number as volume, and because only one event is triggered by one transaction, the transaction and the event are in one-to-one relationship, and one event has a unique transaction ID.
Under the condition of multiple back ends, if each back end has one event monitor, the condition that multiple event monitors are simultaneously carried out may occur, so that a large number of events are repeatedly executed, and database data redundancy occurs. At this time, a distributed lock method is adopted to ensure that only one back end of a plurality of back ends is started to monitor, and if the monitoring is stopped, one of the back ends automatically starts the monitoring. As shown in fig. 3, which is a working flow diagram of a distributed lock, acquiring a lock before monitoring an opening event, specifically including inserting a piece of data with a lock name as a primary key into a database, and repeatedly executing the step if the lock is not successful until the locking is successful; and releasing the lock after stopping event monitoring, and deleting the data with the lock name as the primary key from the database.
1.type DBLock struct{
Name string ORm: "column (name); pk'/Lock name
ClientId string// backend id Each backend corresponds to an id
GoId uint64// locking thread id
CreateTime int64// Lock time
ValidTime int64// extension time
7.}
In order to prevent deadlock, two coroutines are created when a distributed lock is added, one coroutine is to prolong the lock, and the other coroutine is to delete deadlock; every second, the extended lock queries whether a lock meeting the condition (the current time > CreatTime + ValldTime-5 seconds) exists in the database or not according to the lock name and the ClientId, and if yes, updates the ValidTime +10 seconds; every second, a deadlock is deleted by querying the database for a lock that does not satisfy the condition (current time > CreatTime + VaildTime) according to the lock name.
Although the method can ensure that the chain code event is not lost, the method cannot prevent the chain code event from being repeatedly executed, so that the idempotent of the processing method is ensured when the chain code event is processed, namely, the final result is not changed even if the method for processing the event is executed for multiple times. The scheme adopted is that data is inquired on a chain before execution, whether the chain is executed or not is judged, and if the chain is executed, the chain is not repeatedly executed.
Other embodiments of the present disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure disclosed herein. This specification is intended to cover any variations, uses, or adaptations of the specification following, in general, the principles of the specification and including such departures from the present disclosure as come within known or customary practice within the art to which the specification pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the specification being indicated by the following claims.
It will be understood that the present description is not limited to the precise arrangements described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present description is limited only by the appended claims.
Claims (9)
1. An event loss prevention method based on a federation chain is characterized by specifically comprising the following steps:
in response to an action triggering a network restart;
in order to ensure the idempotency of event monitoring, data is inquired on a delink before execution, whether the data is executed or not is judged, and if the data is executed, the data is not repeatedly executed;
acquiring block numbers from an EventMap and a database, wherein the EventMap is used for recording events in each block, each block comprises a plurality of events, and the blocks correspond to the block numbers one by one;
judging whether the event is lost or not based on whether the block number is empty or not, and monitoring the blocks of the alliance chain network based on the judgment result of the block number;
if the block number is empty, monitoring is started from the latest block of the alliance chain network, otherwise, monitoring is started from the block corresponding to the block number;
storing the monitored block numbers into an EventMap and a database;
if multiple back ends and multiple events exist, a distributed lock is adopted to ensure that one back end opening event is monitored in the multiple back ends, and if monitoring is closed, one of the multiple back ends can automatically open monitoring.
2. A federation chain-based event loss prevention method as recited in claim 1, wherein storing the monitored block number in an EventMap comprises: and taking the block number as the value of the EventMap, acquiring the txID and the block number of the event in the block in the EventMap, if the txID and the block number of the event in the block are not obtained, storing the txID and the block number of the event in the block, and if the txID and the block number of the event in the EventMap are obtained, deleting the txID and the block number of the event in the EventMap, wherein the event corresponds to the transaction one to one, and the txID of the transaction is taken as the Key of the EventMap.
3. A federation chain-based event loss prevention method as recited in claim 2, further comprising: after the txID and block number of the event block are deleted each time, the EventMap must be traversed and the minimum block number stored in the database.
4. A federation chain-based event loss prevention method as recited in claim 1, further comprising the step of filtering out disqualified events, wherein a disqualified event comprises any one of an invalid transaction event, a no transaction event and an unregistered transaction event; the method comprises the following specific steps: judging whether the transaction is qualified, and if so, storing the event into an EventMap; if not, the event is filtered.
5. A federation chain-based event loss prevention method as recited in claim 1, wherein the distributed locks include an extended lock and a delete deadlock; at any time, the extended lock queries whether the database has a lock meeting a first condition according to the lock name and the ClientId, and if so, the extended lock updates ValidTime +10 seconds, wherein the first condition is that the current time is > CreatTime + ValidTime-5 seconds; and at any time, deleting the deadlock, inquiring whether a lock meeting a second condition exists in the database or not according to the lock name, and if so, deleting the deadlock, wherein the second condition is that the current time is > CreatTime + ValldTime, the CreatTime is locking time, and the ValldTime is extension time.
6. An event loss prevention system based on a alliance chain is characterized by comprising a data acquisition module, a coding judgment module, an execution monitoring module, a numbering storage module and a repeated monitoring prevention module;
the data acquisition module is used for responding to the action of triggering network restart and acquiring block numbers from an EventMap and a database, wherein the EventMap is used for recording events in each block, each block comprises a plurality of events, and the blocks correspond to the block numbers one by one;
the coding judgment module judges whether the event is lost or not based on whether the block number is empty or not, and monitors the blocks of the alliance chain network based on the judgment result of the block number;
the execution monitoring module is configured to: if the block is empty, monitoring is started from the newest block of the alliance chain network, otherwise, monitoring is started from the incoming block;
the number storage module is used for storing the monitored block numbers into an EventMap and a database;
the anti-repeat monitoring module is used for preventing the event from being repeatedly monitored, inquiring data on a delink before execution, judging whether the event is executed or not, and if the event is executed, not repeatedly executing; if multiple back ends and multiple events exist, a distributed lock is adopted to ensure that one back end opening event is monitored in the multiple back ends, and if monitoring is closed, one of the multiple back ends can automatically open monitoring.
7. A federation chain-based event loss prevention system as recited in claim 6, further comprising a distributed lock execution module arranged to:
if multiple back ends and multiple events exist, a distributed lock is adopted to ensure that one back end opening event is monitored and only one back end opening event is monitored;
the distributed lock comprises an extended lock and a delete deadlock; at any time, the extended lock queries whether the database has a lock meeting a first condition according to the lock name and the ClientId, and if so, the extended lock updates ValidTime +10 seconds, wherein the first condition is that the current time is > CreatTime + ValidTime-5 seconds; and at any time, deleting the deadlock, inquiring whether a database has a lock meeting a second condition according to the name of the lock, and if so, deleting the deadlock, wherein the second condition is that the current time is > CreatTime + ValldTime, the CreatTime is the locking time, and the ValidTime is the extension time.
8. A computer-readable storage medium, in which a computer program is stored which, when being executed by a processor, carries out the method steps of one of claims 1 to 5.
9. A federation chain-based event loss prevention apparatus comprising a memory, a processor and a computer program stored in the memory and executable on the processor, wherein the processor when executing the computer program implements the method steps of any one of claims 1 to 5.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110430469.9A CN113157522B (en) | 2021-04-21 | 2021-04-21 | Method, system, device and storage medium for preventing loss of event based on alliance chain |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110430469.9A CN113157522B (en) | 2021-04-21 | 2021-04-21 | Method, system, device and storage medium for preventing loss of event based on alliance chain |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113157522A CN113157522A (en) | 2021-07-23 |
| CN113157522B true CN113157522B (en) | 2022-11-04 |
Family
ID=76867664
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110430469.9A Active CN113157522B (en) | 2021-04-21 | 2021-04-21 | Method, system, device and storage medium for preventing loss of event based on alliance chain |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113157522B (en) |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CA2938754A1 (en) * | 2015-08-13 | 2017-02-13 | The Toronto-Dominion Bank | Document tracking on a distributed ledger |
| EP3477569A1 (en) * | 2017-10-30 | 2019-05-01 | NEC Laboratories Europe GmbH | Method and system for securing smart contracts in blockchains |
| CN111512333A (en) * | 2019-11-08 | 2020-08-07 | 支付宝(杭州)信息技术有限公司 | System and method for realizing decentralized application based on block chain |
| CN111865721A (en) * | 2020-07-20 | 2020-10-30 | 普华云创科技(北京)有限公司 | Method, system and storage medium for preventing transaction loss after abnormal node communication |
| CN112650735A (en) * | 2020-12-28 | 2021-04-13 | 杭州趣链科技有限公司 | Method, device, equipment and storage medium for determining lost block of alliance chain |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20190303920A1 (en) * | 2018-04-02 | 2019-10-03 | American Express Travel Related Services Company, Inc. | Transaction process using blockchain token smart contracts |
| US11017112B2 (en) * | 2018-07-03 | 2021-05-25 | Tyson York Winarski | Distributed network for storing a redundant array of independent blockchain blocks |
-
2021
- 2021-04-21 CN CN202110430469.9A patent/CN113157522B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CA2938754A1 (en) * | 2015-08-13 | 2017-02-13 | The Toronto-Dominion Bank | Document tracking on a distributed ledger |
| EP3477569A1 (en) * | 2017-10-30 | 2019-05-01 | NEC Laboratories Europe GmbH | Method and system for securing smart contracts in blockchains |
| CN111512333A (en) * | 2019-11-08 | 2020-08-07 | 支付宝(杭州)信息技术有限公司 | System and method for realizing decentralized application based on block chain |
| CN111865721A (en) * | 2020-07-20 | 2020-10-30 | 普华云创科技(北京)有限公司 | Method, system and storage medium for preventing transaction loss after abnormal node communication |
| CN112650735A (en) * | 2020-12-28 | 2021-04-13 | 杭州趣链科技有限公司 | Method, device, equipment and storage medium for determining lost block of alliance chain |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113157522A (en) | 2021-07-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8327375B2 (en) | System and method for supporting resource enlistment synchronization | |
| US7007200B2 (en) | Error analysis fed from a knowledge base | |
| US7080287B2 (en) | First failure data capture | |
| US20020161840A1 (en) | Adapter for interfacing with a workflow engine | |
| US7353495B2 (en) | Method for protection against interleaving transactions using a transaction manager | |
| JPH0576654B2 (en) | ||
| US20100042875A1 (en) | Capturing machine state of unstable java program | |
| CN108038005A (en) | Shared resource access method, client, server-side, system based on zookeeper | |
| CN101636000A (en) | Treating method and treatment device of alarm storms | |
| US8458725B2 (en) | Computer implemented method for removing an event registration within an event notification infrastructure | |
| CN110096237B (en) | Copy processing method, node, storage system, server and readable medium | |
| CN113157522B (en) | Method, system, device and storage medium for preventing loss of event based on alliance chain | |
| CN113157426B (en) | Task scheduling method, system, equipment and storage medium | |
| US20070100973A1 (en) | System and method for reliably purging a fault server | |
| CN112612635B (en) | Multi-level protection method for application program | |
| US7171410B1 (en) | Fault tolerant network element | |
| CN113238815A (en) | Interface access control method, device, equipment and storage medium | |
| CN112702437B (en) | Real-time automatic adjustment method for link data sampling rate | |
| KR101888131B1 (en) | Method for Performing Real-Time Changed Data Publish Service of DDS-DBMS Integration Tool | |
| CN112685142A (en) | Distributed data processing system | |
| CN111708802A (en) | Network request anti-reprocessing method and device | |
| CN111382022B (en) | Method, device, electronic equipment and storage medium for monitoring real-time stream computing platform | |
| CN116074384B (en) | Method and system for controlling service request quantity | |
| Rossi et al. | Data Resilience in the dCache Storage System | |
| JPS61263350A (en) | Automatic informing system for communication line failure |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |