CN115250277B - Method for adapting consensus mechanism to edge buffer system based on alliance chain - Google Patents
Method for adapting consensus mechanism to edge buffer system based on alliance chain Download PDFInfo
- Publication number
- CN115250277B CN115250277B CN202210949502.3A CN202210949502A CN115250277B CN 115250277 B CN115250277 B CN 115250277B CN 202210949502 A CN202210949502 A CN 202210949502A CN 115250277 B CN115250277 B CN 115250277B
- Authority
- CN
- China
- Prior art keywords
- node
- leader
- candidate
- obedient
- new
- 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
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
- H04L67/1044—Group management mechanisms
- H04L67/1051—Group master selection mechanisms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Abstract
Embodiments of the present disclosure relate to a method of adapting a consensus mechanism to a federated chain-based edge caching system. The method comprises the following steps: the node module is positioned in the edge cache system based on the alliance chain and comprises a leader node and a service follower node; the leader node is used for sending the block information in the period of the leader to the server node so as to reach consensus among the leader server nodes; the server node is used for receiving the block information sent by the leader node and uploading the block information to a block chain account book where the follower node is located according to the instruction of the leader node. The application achieves consensus by utilizing the leader node to lead each compliant node and uploading the block information to each block chain account book. The consensus mechanism is suitable for a non-Bayesian and busy family system, has higher performance efficiency and lower resource consumption, and also ensures expansibility.
Description
Technical Field
The embodiment of the disclosure relates to the field of information technology, in particular to a consensus mechanism applicable to an edge cache system based on a alliance chain.
Background
The edge caching system based on the alliance chain is used as one of important applications of the blockchain technology, and one important ring is to synchronize a caching list by utilizing a consensus mechanism, so that edge nodes established by all large operators can share the edge caching content, the resource utilization rate is improved, and the caching cost is reduced.
The related consensus mechanism is focused on the existence of malicious attack in the Bayesian system, and more resources are spent for solving the trust problem among peer nodes in the Bayesian system, and the consensus mechanism brings high security performance and causes excessive consumption of computational resources and serious deficiency of system performance efficiency. In the edge cache architecture based on the alliance chain, the members participating in consensus come from edge cache servers deployed by operators, and most of the members can be considered to be trusted non-Bayesian nodes, and only faults can occur but information cannot be forged.
The consensus mechanism cannot be well applied to the edge cache system based on the alliance chain, and in order to improve the performance efficiency of the edge cache system based on the alliance chain, a consensus mechanism suitable for a non-Bayesian system needs to be designed, which has higher performance efficiency and lower resource consumption, and simultaneously, expansibility is also ensured.
Accordingly, there is a need to improve one or more problems in the related art as described above.
It should be noted that the information disclosed in the above background section is only for enhancing understanding of the background of the present disclosure and thus may include information that does not constitute prior art known to those of ordinary skill in the art.
Disclosure of Invention
It is an object of embodiments of the present disclosure to provide a consensus mechanism for federated chain-based edge caching systems that overcomes, at least in part, one or more of the problems due to the limitations and disadvantages of the related art.
Embodiments of the present disclosure provide a consensus mechanism for a federation chain based edge cache system, the consensus mechanism comprising:
a node module located in the federation chain based edge cache system, the node module comprising a leader node and a follower node;
the leader node is used for sending the block information in the leader period to the obedient node so as to lead the obedient node to achieve consensus;
and the obedient node is used for receiving the block information sent by the leader node and uploading the block information to a block chain account book where the obedient node is located according to the instruction of the leader node.
In an exemplary embodiment of the present disclosure, the election process of the leader node is:
when the heartbeat from the leader node is not received within a first preset time, starting to elect, converting the obedient node into candidate nodes, forming a candidate node cluster by a plurality of candidate nodes, and electing the leader node according to the competition parameters of the candidate nodes in the candidate node cluster;
in the election time, one candidate node in the candidate node cluster obtains a plurality of votes, and the candidate node is successfully elected as a new leader node;
and after the new leader node serves for a second preset time, the new leader node stops sending the heartbeat, and at this time, the dominance of the new leader node is ended.
In an exemplary embodiment of the present disclosure, the consensus process is:
and the leader node packs the log corresponding to the cache content and forms a new block, and the leader node sends the new block to all the compliant nodes until at least part of the log corresponding to the new block is copied by the compliant nodes and is stored locally, and then the stored new block is uploaded to a blockchain ledger, so that the new block is successfully added to a blockchain.
In one exemplary embodiment of the present disclosure, the competition parameter of the candidate node is age.
In one exemplary embodiment of the present disclosure, after the transformation of the obedient node into the candidate node, the age of the candidate node is increased by a third preset time.
In one exemplary embodiment of the present disclosure, the compliant node responds to a user's request and adds a summary of hot content within the service scope of the compliant node as a log entry to a log before successfully electing a new leader node.
In one exemplary embodiment of the present disclosure, when a user requests target content from a node module, the obedient node may obtain a hash value of the target content and continue the hash value of the target content as a content digest in a to-be-cached directory log.
In an exemplary embodiment of the present disclosure, when the hash value of the target content is already in the to-be-cached directory log, adding one to the number of requests of the target content; and if the hash value of the target content does not exist in the to-be-cached directory log, adding the target content into the to-be-cached directory, and recording the request time as 1.
In an exemplary embodiment of the present disclosure, the number of requests for content summaries in the pending catalog log may be periodically attenuated.
In one exemplary embodiment of the present disclosure, the number of new blocks that the leader node sends to all of the compliant nodes during its tenure is 1.
The technical scheme provided by the embodiment of the disclosure can comprise the following beneficial effects:
in embodiments of the present disclosure, consensus is achieved by utilizing a leader node to leader each compliant node, uploading blockinformation onto the respective blockchain ledger. The consensus mechanism is suitable for a non-Bayesian-court system, has higher performance efficiency and lower resource consumption, and simultaneously ensures expansibility.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the disclosure and together with the description, serve to explain the principles of the disclosure. It will be apparent to those of ordinary skill in the art that the drawings in the following description are merely examples of the disclosure and that other drawings may be derived from them without undue effort.
Fig. 1 is a schematic diagram showing an election process of a leader node in this embodiment.
Detailed Description
Example embodiments will now be described more fully with reference to the accompanying drawings. However, the exemplary embodiments may be embodied in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of the example embodiments to those skilled in the art. The described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
Furthermore, the drawings are merely schematic illustrations of the present disclosure and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and thus a repetitive description thereof will be omitted. Some of the block diagrams shown in the figures are functional entities and do not necessarily correspond to physically or logically separate entities. These functional entities may be implemented in software or in one or more hardware modules or integrated circuits or in different networks and/or processor devices and/or microcontroller devices.
The present example embodiment provides a consensus mechanism for a federated chain-based edge cache system, which may include: and the node module is positioned in the edge cache system based on the alliance chain and comprises a Leader node (Leader) and a Follower node (Follower). The leader node is used for sending the block information in the leader period to the obedient node so as to lead the obedient node to achieve consensus. And the obedient node is used for receiving the block information sent by the leader node and uploading the block information to a block chain account book where the obedient node is located according to the instruction of the leader node.
The application achieves consensus by utilizing the leader node to lead each compliant node and uploading the block information to each block chain account book. The consensus mechanism is suitable for a non-Bayesian-court system, has higher performance efficiency and lower resource consumption, and simultaneously ensures expansibility.
Specifically, as shown in fig. 1, the election process of the leader node is as follows:
when the heartbeat from the leader node is not received within a first preset time, starting to elect, converting the obedient node into Candidate nodes (candidates), forming a Candidate node cluster by a plurality of Candidate nodes, and performing the election of the leader node according to the competition parameters of the Candidate nodes in the Candidate node cluster;
in the election time, one candidate node in the candidate node cluster obtains a plurality of votes, and the candidate node is successfully elected as a new leader node;
and after the new leader node serves for a second preset time, the new leader node stops sending the heartbeat, and at this time, the dominance of the new leader node is ended.
In this embodiment, the headers election is triggered by the folows after a period of time has elapsed without receiving a heartbeat from the headers. The Follower will convert the identity to Candidate and add 1 to its current term. It first publishes its age (age) and then Candidate sends its vote according to the largest member of the current Candidate cluster. The result is the following three cases: winning a plurality of votes, and successfully electing as a Leader; receiving a heartbeat from the Leader, indicating that other nodes have preemptively selected the Leader; no node wins most votes, the Leader election fails, and the next election is initiated after the time of the election is overtime. After electing the Leader, the Leader maintains its dominance by sending the heatbean information to all folows periodically.
Optionally, in one embodiment, the process of achieving consensus is:
and the leader node packs the log corresponding to the cache content and forms a new block, and the leader node sends the new block to all the compliant nodes until at least part of the log corresponding to the new block is copied by the compliant nodes and is stored locally, and then the stored new block is uploaded to a blockchain ledger, so that the new block is successfully added to a blockchain.
In this embodiment, after a new Leader is selected, the Leader starts to execute the accounting right and updates the cache content. Before becoming a Leader, the node responds to a user request and adds a hot content abstract in a service range as a log entry to a log when the node is a follow-up. When a certain content passes through a system node, the Follower obtains the hash value of the content as a content abstract and records the content abstract in a to-be-cached directory log, and if the to-be-cached directory has the content, the request number of the recorded content is increased by one; if the corresponding content record does not exist in the to-be-cached directory, adding the content to the to-be-cached directory, and recording the content for one time. The records of the content summaries in the to-be-buffered list fade with the period, namely, the request times of the content fade once at intervals, the decay times of each time is 1 at the minimum, and the content records with the times of 0 are removed from the to-be-buffered list.
After the selection of the Follower becomes the Leader successfully, packing a plurality of content summaries with earlier frequency ranking after period attenuation into a block, and sending the block to other Followers in parallel, wherein other Followers copy the block, when the block is copied to most nodes, the Leader requests all nodes in the system to upload the log to the block chain account book thereof, and returns an execution result to the Leader. After the Leader receives most of the information for confirming uploading, the corresponding cache content is cached locally. Some folows may not have a successful replication log and the Leader may retry sending indefinitely until all folows eventually store all log entries. Any Leader can only upload one chunk during its tenure, after a chunk has been successfully added to the blockchain, it ends its tenure and sets the current age to 0 over an arbitrary period of time. And triggering the Leader election again within a period of time after the tenure is finished.
It should be noted that although several modules of the system for action execution are mentioned in the detailed description above, this partitioning is not mandatory. Indeed, the features and functions of two or more modules described above may be embodied in one module in accordance with embodiments of the present application. Conversely, the features and functions of one module described above may be further divided into a plurality of modules to be embodied. The components shown as modules may or may not be physical units, may be located in one place, or may be distributed across multiple network elements. Some or all modules can be selected according to actual needs to realize the purpose of the wood application scheme. Those of ordinary skill in the art will understand and implement the present application without undue burden.
The embodiments of the present application have been described above with reference to the accompanying drawings, but the present application is not limited to the above-described embodiments, which are merely illustrative and not restrictive, and many forms may be made by those having ordinary skill in the art without departing from the spirit of the present application and the scope of the claims, which are to be protected by the present application.
Claims (5)
1. A method of adapting a consensus mechanism to a federated chain-based edge cache system, the method comprising:
a node module located in the federation chain based edge cache system, the node module comprising a leader node and a follower node;
the leader node is used for sending the block information in the leader period to the obedient node so as to lead the obedient node to achieve consensus;
the obedient node is used for receiving the block information sent by the leader node and uploading the block information to a block chain account book where the obedient node is located according to the instruction of the leader node;
when the heartbeat from the leader node is not received within a first preset time, starting to elect, converting the obedient node into candidate nodes, forming a candidate node cluster by a plurality of candidate nodes, and electing the leader node according to the competition parameters of the candidate nodes in the candidate node cluster;
in the election time, one candidate node in the candidate node cluster obtains a plurality of votes, and the candidate node is successfully elected as a new leader node;
after the new leader node serves a second preset time, the new leader node stops sending the heartbeat, and at this time, the dominance of the new leader node ends;
before a new leader node is successfully elected, the obedient node responds to a request of a user and adds a hot content abstract in the service range of the obedient node as a log entry into a log;
when a user requests target content from a node module, the obedient node acquires the hash value of the target content and records the hash value of the target content as a content abstract in a to-be-cached directory log;
when the hash value of the target content exists in the to-be-cached directory log, adding one to the request times of the target content; if the hash value of the target content does not exist in the to-be-cached directory log, adding the target content into the to-be-cached directory, and recording the request times as 1;
the number of requests for content summaries in the pending catalog log is periodically attenuated.
2. The method of claim 1, wherein the agreed upon process is:
and the leader node packs the log corresponding to the cache content and forms a new block, and the leader node sends the new block to all the compliant nodes until at least part of the log corresponding to the new block is copied by the compliant nodes and is stored locally, and then the stored new block is uploaded to a blockchain ledger, so that the new block is successfully added to a blockchain.
3. The method of claim 1, wherein the competition parameter of the candidate node is age.
4. A method according to claim 3, wherein after the conversion of the obedient node into the candidate node, the age of the candidate node is increased by a third preset time.
5. The method of claim 1, wherein the number of new blocks sent by the leader node to all of the compliant nodes during its tenure is 1.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210949502.3A CN115250277B (en) | 2022-08-09 | 2022-08-09 | Method for adapting consensus mechanism to edge buffer system based on alliance chain |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210949502.3A CN115250277B (en) | 2022-08-09 | 2022-08-09 | Method for adapting consensus mechanism to edge buffer system based on alliance chain |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN115250277A CN115250277A (en) | 2022-10-28 |
| CN115250277B true CN115250277B (en) | 2023-09-05 |
Family
ID=83699592
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210949502.3A Active CN115250277B (en) | 2022-08-09 | 2022-08-09 | Method for adapting consensus mechanism to edge buffer system based on alliance chain |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115250277B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117579633B (en) * | 2024-01-17 | 2024-04-09 | 腾讯科技（深圳）有限公司 | Block election method, device, equipment and storage medium |
Citations (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101131673A (en) * | 2006-08-22 | 2008-02-27 | 中兴通讯股份有限公司 | General caching method |
| CN106776894A (en) * | 2016-11-29 | 2017-05-31 | 北京众享比特科技有限公司 | Log database system and synchronous method |
| CN106878071A (en) * | 2017-01-25 | 2017-06-20 | 上海钜真金融信息服务有限公司 | A kind of block chain common recognition mechanism based on Raft algorithms |
| CN107948247A (en) * | 2017-11-01 | 2018-04-20 | 西安交通大学 | A kind of virtual cache passage buffer memory management method of software defined network |
| CN109325762A (en) * | 2018-08-30 | 2019-02-12 | 杭州复杂美科技有限公司 | Across the chain method of commerce of parallel chain, equipment and storage medium |
| CN109936633A (en) * | 2019-03-11 | 2019-06-25 | 重庆邮电大学 | Based on the cooperation caching strategy of content different degree in content center network |
| CN110445778A (en) * | 2019-08-01 | 2019-11-12 | 中盾云链(广州)信息科技有限公司 | A kind of common recognition algorithm applied to alliance's chain |
| CN110728513A (en) * | 2019-09-17 | 2020-01-24 | 成都四方伟业软件股份有限公司 | Block chain working method and system based on raft protocol |
| CN110855793A (en) * | 2019-11-19 | 2020-02-28 | 南昌航空大学 | Distributed system consensus method |
| CN111866156A (en) * | 2020-07-27 | 2020-10-30 | 网易（杭州）网络有限公司 | Fusing processing method and device |
| CN112968942A (en) * | 2021-01-29 | 2021-06-15 | 南京邮电大学 | Block chain data safety storage frame and method |
| KR20210087721A (en) * | 2020-01-03 | 2021-07-13 | 주식회사 블로코 | Blockchain synchronization method using Raft and blockchain system using the same |
| CN113608876A (en) * | 2021-08-12 | 2021-11-05 | 中国科学技术大学 | Distributed file system metadata load balancing method based on load type perception |
| CN113612618A (en) * | 2021-08-18 | 2021-11-05 | 东北大学 | Alliance chain consensus method and device |
| CN114745135A (en) * | 2022-04-19 | 2022-07-12 | 西南石油大学 | Block chain system for energy transaction based on V-raft consensus algorithm |
| CN114844891A (en) * | 2022-04-21 | 2022-08-02 | 浪潮云信息技术股份公司 | Block chain consensus method and system based on Raft algorithm |
| CN114866562A (en) * | 2022-05-27 | 2022-08-05 | 山东省计算中心（国家超级计算济南中心） | Block chain consensus method and system for electric power energy system |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20030145241A1 (en) * | 2002-01-30 | 2003-07-31 | Zhigang Hu | Method and apparatus for reducing leakage power in a cache memory using adaptive time-based decay |
| US10229161B2 (en) * | 2013-09-20 | 2019-03-12 | Oracle International Corporation | Automatic caching of scan and random access data in computing systems |
| CN107181637B (en) * | 2016-03-11 | 2021-01-29 | 华为技术有限公司 | Heartbeat information sending method and device and heartbeat sending node |
| US20190333033A1 (en) * | 2018-04-29 | 2019-10-31 | Keir Finlow-Bates | System and method for creating, storing and transferring unforgeable digital assets in a database |
| CN108876380B (en) * | 2018-08-07 | 2021-03-23 | 创新先进技术有限公司 | Transaction method and system based on centralized settlement and block chain deposit certificate |
-
2022
- 2022-08-09 CN CN202210949502.3A patent/CN115250277B/en active Active
Patent Citations (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101131673A (en) * | 2006-08-22 | 2008-02-27 | 中兴通讯股份有限公司 | General caching method |
| CN106776894A (en) * | 2016-11-29 | 2017-05-31 | 北京众享比特科技有限公司 | Log database system and synchronous method |
| CN106878071A (en) * | 2017-01-25 | 2017-06-20 | 上海钜真金融信息服务有限公司 | A kind of block chain common recognition mechanism based on Raft algorithms |
| CN107948247A (en) * | 2017-11-01 | 2018-04-20 | 西安交通大学 | A kind of virtual cache passage buffer memory management method of software defined network |
| CN109325762A (en) * | 2018-08-30 | 2019-02-12 | 杭州复杂美科技有限公司 | Across the chain method of commerce of parallel chain, equipment and storage medium |
| CN109936633A (en) * | 2019-03-11 | 2019-06-25 | 重庆邮电大学 | Based on the cooperation caching strategy of content different degree in content center network |
| CN110445778A (en) * | 2019-08-01 | 2019-11-12 | 中盾云链(广州)信息科技有限公司 | A kind of common recognition algorithm applied to alliance's chain |
| CN110728513A (en) * | 2019-09-17 | 2020-01-24 | 成都四方伟业软件股份有限公司 | Block chain working method and system based on raft protocol |
| CN110855793A (en) * | 2019-11-19 | 2020-02-28 | 南昌航空大学 | Distributed system consensus method |
| KR20210087721A (en) * | 2020-01-03 | 2021-07-13 | 주식회사 블로코 | Blockchain synchronization method using Raft and blockchain system using the same |
| CN111866156A (en) * | 2020-07-27 | 2020-10-30 | 网易（杭州）网络有限公司 | Fusing processing method and device |
| CN112968942A (en) * | 2021-01-29 | 2021-06-15 | 南京邮电大学 | Block chain data safety storage frame and method |
| CN113608876A (en) * | 2021-08-12 | 2021-11-05 | 中国科学技术大学 | Distributed file system metadata load balancing method based on load type perception |
| CN113612618A (en) * | 2021-08-18 | 2021-11-05 | 东北大学 | Alliance chain consensus method and device |
| CN114745135A (en) * | 2022-04-19 | 2022-07-12 | 西南石油大学 | Block chain system for energy transaction based on V-raft consensus algorithm |
| CN114844891A (en) * | 2022-04-21 | 2022-08-02 | 浪潮云信息技术股份公司 | Block chain consensus method and system based on Raft algorithm |
| CN114866562A (en) * | 2022-05-27 | 2022-08-05 | 山东省计算中心（国家超级计算济南中心） | Block chain consensus method and system for electric power energy system |
Non-Patent Citations (1)
| Title |
|---|
| 《Performance Ayalysis of the Raft Algorithm for Private Blockchains》;Huang Dongyan;IEEE;第50卷(第1期);172-181 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN115250277A (en) | 2022-10-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109189751B (en) | Data synchronization method based on block chain and terminal equipment | |
| Fu et al. | An improved blockchain consensus algorithm based on raft | |
| CN108027828B (en) | Managed file synchronization with stateless synchronization nodes | |
| US5802062A (en) | Preventing conflicts in distributed systems | |
| Ali et al. | Blockstack: A new decentralized internet | |
| US10579595B2 (en) | Method and device for calling a distributed file system | |
| EP2820531A1 (en) | Interval-controlled replication | |
| CN113168404B (en) | System and method for replicating data in a distributed database system | |
| CN101471845B (en) | Method for adjusting data block counterpart number and metadata server node | |
| CN115250277B (en) | Method for adapting consensus mechanism to edge buffer system based on alliance chain | |
| KR102314495B1 (en) | Blockchain synchronization method using Raft and blockchain system using the same | |
| US11620087B2 (en) | Implicit leader election in a distributed storage network | |
| JP2012507076A (en) | Bootstrap to gather federation | |
| Jalalzai et al. | The Hermes BFT for blockchains | |
| Ali et al. | Blockstack technical whitepaper | |
| Hwang et al. | Efficient real-time auditing and proof of violation for cloud storage systems | |
| CN116846888A (en) | Consensus processing method, device, equipment and storage medium of block chain network | |
| Hwang et al. | Fulfilling mutual nonrepudiation for cloud storage | |
| CN113742336A (en) | Data processing method and device and storage medium | |
| CN111031086B (en) | Block chain data storage method and system | |
| Ahmad et al. | Lowest data replication storage of binary vote assignment data grid | |
| Shi et al. | Distributed file system multilevel fault-tolerant high availability mechanism | |
| CN117874136A (en) | Method and device for synchronizing copies of distributed database and nonvolatile storage medium | |
| JP5107836B2 (en) | Connection server device and server system | |
| CN117811739A (en) | Block chain-based data processing method, equipment and readable storage medium |
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 |