EvoChain: a Recovery Approach for Permissioned Blockchain Applications

David R. Matos; Francisco Faria; Miguel L. Pardal; Samih Eisa

REVIEW 5 major objections 7 minor 28 references

EvoChain: a Recovery Approach for Permissioned Blockchain Applications

T0 review · 5 major / 7 minor · reviewed 2026-08-12 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read EvoChain gives permissioned blockchains a grace-period cancel operation without touching the underlying chain.

desk verdict A plausible chaincode-level undo mechanism for Hyperledger Fabric, honestly described as 'apparent mutability' in the intro, but the abstract's 'data redaction' overstates what is actually application-layer masking of canceled transactions. read the letter →

arxiv 2411.16976 v1 pith:JOBZ3IZX submitted 2024-11-25 cs.CR cs.ET

Francisco Faria , Samih Eisa , David R. Matos , Miguel L. Pardal This is my paper · ORCID

classification cs.CRcs.ET

keywords controlledmutabilitydataredactionintrusionrecoverypermissionedblockchainsmartcontractswrite-aheadloggingviewgenerationsupplychaintraceability

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

EvoChain aims to give permissioned blockchain applications a way to undo recent transactions without forking the chain or modifying the consensus layer. It treats each application operation as a transaction with a pending phase: during a configurable grace period, an authorized participant can issue a cancellation that marks the operation canceled, and a view generator then presents the object state as if the canceled operation never happened. The original transaction remains in the ledger; what changes is the consistent view assembled from transaction logs. This matters because immutability is a barrier to adoption in settings where human error, stolen credentials, or smart-contract bugs need correction, and EvoChain claims to provide that correction while keeping the underlying blockchain's integrity and auditability intact.

What carries the argument

The load-bearing mechanism is a transaction-level world-state model plus a view generator. Each EvoChain transaction is stored in the platform's world state as a log entry with fields for submission time, permanent state time, validity, and delay, and a dependency graph encodes which MTs depend on earlier MTs through shared objects. The view generator sorts the relevant transactions by submission time, drops canceled ones, picks the last consolidated transaction not affected by a cancellation, and replays the remaining changes to compute the object an application should see.

What would settle it

After issuing a cancellation, read the object directly from the platform's raw world-state database or from a chaincode query that bypasses EvoChain's view generation; if the canceled transaction's value still appears there, then redaction is only a filtered application view, not removal from the ledger.

Watch

Extended reading notes

Core claim

The paper's central claim is that controlled mutability can be implemented entirely inside the smart-contract layer of a permissioned ledger by combining a write-ahead-logging-inspired per-transaction store with a dependency graph and a view-generation algorithm. Mutable Transactions (MTs) carry a submission time, a permanent-state time, validity, delay, and the object changes; Canceling Transactions (CTs) flip a pending MT's validity to canceled, and any dependent transactions roll back in the generated view. Consolidation happens when a delay expires or a condition is satisfied, after which cancellation is no longer allowed. Because the underlying platform's blocks are never altered, EvoChain claims to preserve integrity, authenticity, non-repudiation, and auditability while restoring the application-level state to a pre-incident point. The recovery example shows that after a CT, a query returns either an empty result or the object version issued after the cancellation, not the canceled value.

Load-bearing premise

The mechanism only hides canceled transactions if every read of the data goes through EvoChain's view generator; anyone who inspects the raw ledger or the unredacted underlying state can still see the canceled transaction and its data.

Editorial extensions

If this is right

Operators can cancel a mistaken or malicious transaction issued during the grace period without touching earlier blocks or the consensus protocol.
Dependent operations on the same object are rolled back in the application view, giving a compensation-like recovery at the transaction level.
Query operations consolidate expired transactions lazily, so reads pay an overhead only when a pending transaction's delay has elapsed.
Measurements on the supply-chain prototype indicate roughly 18% higher latency and 9% lower throughput for core operations, with cancellation-triggering queries about 9% lower in throughput.
Canceled transactions add extra ledger entries, so chain growth and storage requirements increase over time.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

Extension: the same view-filtering layer could support time-limited data correction obligations such as right-to-erasure requests in permissioned settings, since the original block data would remain but the application-facing view would stop exposing it.
Extension: the redaction guarantee is only as strong as the read path; any participant who reads the raw ledger or underlying state database bypasses the filter, so deployments would need to restrict or encrypt raw access for the cancellation to be meaningful.
Extension: the dependency-graph rollback could be reused as a general workflow primitive for multi-party processes, allowing a failed step to be undone and reissued rather than appended as a correction.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Colleague,

EvoChain is a chaincode-level framework for Hyperledger Fabric that adds a grace period during which a transaction can be canceled by a compensating "canceling transaction," with a view generator that filters canceled entries out of the object state. The architecture is the novel piece: instead of forking Fabric, using chameleon hashes, or requiring consensus-level changes, it stores transaction logs in the world state and rebuilds the current object by replaying non-canceled transactions. That is a real design option, and the authors position it clearly against the existing redaction taxonomies (consensus, chameleon hash, meta-transactions). I haven't seen this exact chaincode-only, WAL-inspired approach in the surveys they cite.

What they did well: the dependency graph and view generation logic are conceptually sound for the stated use case; the cancellation semantics (CT flips an MT's validity flag, and dependent transactions roll back in the view) are explained with a concrete sequence example; and the prototype evaluation, while limited, shows the overhead is measurable rather than catastrophic — roughly 9% throughput drop and a 2% memory increase on their WineTracker benchmark. The TC3 comparison, where queries that consolidate expired delays are slower than those that don't, is a useful sanity check.

The soft spots are real but not fatal to the framework. First, the headline claim: the abstract says "data redaction," but nothing is actually redacted. The canceled transaction payload remains in the block store and in LevelDB. EvoChain only changes the view that its own chaincode returns. The intro uses the more honest phrase "apparent transaction mutability," and Section 3.7 describes the view generator, but Section 5.5 asserts tamper-resistance and consistency without acknowledging that anyone who queries the raw ledger, uses a Fabric explorer, or reads the world state directly will see the canceled data. This is a load-bearing unstated assumption: every legitimate read path must go through the EvoChain chaincode. That needs to be stated up front, and the "redaction" language softened to "application-level masking" or the paper needs to specify a threat model that excludes raw-ledger readers.

Second, there is no formal correctness argument for Algorithm 1. The view generation is the safety-critical piece, and the paper gives a pseudocode listing and an example, but no invariant or proof that the generated view is consistent under arbitrary interleavings of MTs and CTs. Third, the performance reporting has a concrete error: Figure 4 shows latency in milliseconds (30.19 and 35.1), while Section 5.5 reports seconds and says 35.61. That is the kind of inconsistency a referee should catch. Fourth, no code or data is shipped, so the prototype is not independently verifiable.

Who this is for: people working on permissioned blockchain data lifecycle management, particularly Fabric practitioners who want an undo facility without modifying the platform. It deserves a serious referee — the architectural idea is worth engaging with, and the concerns are addressable in revision.

Recommendation: send it to peer review, but the authors need to either reframe the contribution as logical cancellation with an explicit reading-path assumption, or add real redaction at the storage layer. They should also provide the missing correctness argument and fix the unit inconsistency.

Referee Report

5 major / 7 minor

Summary. EvoChain is a chaincode-level framework for Hyperledger Fabric that augments ordinary application transactions with a 'mutable' status and cancellation transactions, and provides a view-generation algorithm (Algorithm 1) that computes object state while excluding canceled transactions. The authors implement a supply-chain prototype (EvoChainWineTracker) and compare it with a vanilla WineTracker using Hyperledger Caliper, reporting latency and throughput overhead. The paper claims controlled data redaction and recovery without changing Fabric's internals.

Significance. If properly scoped, the idea of an application-level undo buffer backed by chaincode and a view generator is a useful complement to existing rollback/compensation techniques in permissioned blockchains, and the prototype demonstrates feasibility on a real Fabric deployment. The paper's main strength is that the mechanism is implemented and measured, not just designed. However, the contribution is currently overstated: the mechanism provides logical masking of data in the query path, not data redaction, and the core algorithm has correctness gaps that need to be resolved before the claimed recovery semantics can be accepted.

major comments (5)

[Section 3.7, Algorithm 1] The algorithm does not implement the recursive cancellation claimed in Section 5.4.2. It filters out only the canceled transactions themselves (lines 23-24 and 26), but a pending transaction that depends on a canceled MT remains in the 'transactions' list and is applied at lines 27-28, thereby re-introducing the canceled effects. The dependency graph of Section 3.6 is never used by the algorithm, so the rollback of dependent transactions is not represented. Either the algorithm must remove or invalidate dependent transactions, or the paper must prove that the simple filtering suffices; as written, the recovery semantics do not follow from the pseudocode.
[Section 3.7, Algorithm 1, lines 15-20] The inner 'foreach canceledTransaction' loop breaks unconditionally after the first iteration in both the if and else branches, so the algorithm never checks more than one canceled transaction when testing whether a consolidated transaction is tainted. The comment 'check next' on line 20 is therefore not implemented, and a consolidated transaction that is invalidated by a later canceled transaction in the list could be incorrectly selected as the confirmed base.
[Abstract, Section 1, Section 5.5] The term 'data redaction' overstates what the mechanism achieves. As the paper states in Section 5.5, EvoChain does not modify Hyperledger Fabric's properties, so the canceled MT and its payload remain in the block store and in the LevelDB world state. The effect is a logical masking in the view generated by the chaincode. The paper never states the necessary reading-path assumption that all legitimate reads must go through EvoChain's chaincode and ViewGenerator; without this assumption, a peer administrator, auditor, or client reading raw blocks or the state database can still observe the canceled data. Please replace 'redaction' with 'logical masking' or 'application-level undo' and add an explicit limitation, or describe how access control enforces the reading-path assumption.
[Section 5.5 and Figure 4] The latency units and numbers are inconsistent. Figure 4 labels latency in milliseconds and shows values 30.19 and 35.1, while Section 5.5 reports the same comparison as 30.19s and 35.61s, and Section 6 summarizes the increase as 'around 15%' whereas Section 5.5 says 17.95%. The paper must correct the units and reconcile the numbers and percentages, and ideally report variance or confidence intervals for the Caliper measurements.
[Section 3.2 (Threat Model A3)] Under attack A3 (stolen private keys), the paper assumes an administrator can cancel the attacker's transactions during the grace period. However, if the attacker holds the victim's keys, the attacker can also issue CTs to cancel legitimate transactions before the administrator revokes the credentials. The paper does not analyze this race or propose a mitigation; please either extend the threat model with an explicit assumption (e.g., cancellation requires a separate key or quorum that the attacker does not possess) or state this as an open limitation.

minor comments (7)

[Algorithm 1, line 2] The initialization 'initialObject ← transactions' appears to assign a list of transactions to a variable later used as an object (line 28 applies changes to it). Please clarify the intended initialization or fix the naming.
[Table 1] The heading 'Consolation Query Operations' should be 'Consolidation Query Operations'.
[Section 4.2 and Section 5.4.3] The consolidation delay is described only as 'set in the hundreds of seconds', but the exact value used in the TC3 experiments (5000 queries before/after expiry) is not given. Please specify the delay and how it interacts with the test.
[Section 5] The paper does not provide an artifact URL for EvoChainWineTracker; making the chaincode and benchmark scripts available would support reproducibility.
[Section 5.5] The claim 'Resistance to DDoS since tests on our prototype showed that redaction operations behave, in terms of performance, similarly to core operations' is not supported; a throughput comparison does not establish DDoS resistance, so please remove or rephrase this inference.
[Algorithm 1, line 9] The comment 'There are no confirmed transactions' is unclear; the break at line 10 exits the outer loop, which seems unintended given the comment.
[Section 3.6 and Algorithm 1] Figure 1 presents dependency graphs, but Algorithm 1 takes a flat list of transactions as input; please explain how the graph is represented in the algorithm or why it is not needed.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: EvoChain's mechanism is implemented and measured, not derived from its own conclusion.

full rationale

EvoChain makes no derived 'prediction' in the sense of fitting a model and then recovering it. The recovery mechanism is constructive: CancelTransaction flips an MT validity field to CANCELED in chaincode state, and Algorithm 1 (ViewGenerator) filters CANCELED transactions when composing the current object. The paper is explicit that this is 'apparent transaction mutability,' i.e., the view is recalculated, not the ledger rewritten. No parameter is fitted to data and then called a prediction, no uniqueness result is imported from the authors' prior work, and no self-citation is load-bearing; the cited related work on mutable blockchains is background, and the implementation details and measurements are self-contained. The evaluation only compares EvoChainWineTracker to the authors' own vanilla WineTracker, which weakens external benchmarking, but that is an empirical support issue, not circular reasoning. The concern that raw Fabric block/state readers can still see canceled payloads is a real correctness/security-scope gap, but it is not an equation-to-input reduction: the paper's own algorithm defines the masking, and the claim of 'data redaction' is broader than what is implemented, which is the opposite of circularity (overclaiming, not self-justification).

Assumptions & free parameters 1 free parameters · 3 assumptions · 0 invented entities

The central design relies on two structural assumptions: chaincode-mediated reads and Fabric's inherited security. There are no fitted physical constants and no invented external entities. The only hand-set parameter is the consolidation delay, and even that is a configuration choice rather than a fitted constant.

free parameters (1)

consolidation delay = hundreds of seconds
The delay before a MT becomes consolidated is a configurable value chosen by the authors for WineTracker in Section 4.2. It determines the cancellation window and affects benchmark conditions; no analysis or external requirement fixes its value.

assumptions (3)

domain assumption All client reads go through EvoChain's chaincode view generator; direct ledger or state database access is not part of the model.
Section 3.7 describes view generation as the mechanism that hides canceled transactions. If any participant reads the raw Fabric block or state database, the canceled data remains visible, so redaction is only apparent.
domain assumption The threat model excludes flaws in Fabric, consensus algorithms, hash functions, and digital signatures.
Section 3.2 states these are out of scope. Security claims such as tamper-resistance are therefore inherited from Fabric rather than demonstrated for the EvoChain logic itself.
domain assumption Canceling a MT recursively invalidates dependent transactions as encoded by the dependency graph.
Section 3.6 and Algorithm 1 assume the dependency graph and submission-time ordering fully capture state semantics, so that skipping canceled nodes yields a consistent object state. No formal proof is given.

how reviews work

0 comments

Cite this review

Pith. "Pith review of EvoChain: a Recovery Approach for Permissioned Blockchain Applications." pith.science (2026). https://pith.science/paper/JOBZ3IZX

@misc{pith2026241116976,
  author       = {Pith},
  title        = {Pith review of: EvoChain: a Recovery Approach for Permissioned Blockchain Applications},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/JOBZ3IZX}},
  note         = {Machine review of arXiv:2411.16976}
}

read the original abstract

Blockchain technology supports decentralized, consensus-driven data storage and processing, ensuring integrity and auditability. It is increasingly adopted for use cases with multiple stakeholders with shared ownership scenarios like digital identity and supply chain management. However, real-world deployments face challenges with mistakes and intrusions. This article presents EvoChain, a chaincode framework extension introducing controlled mutability for data redaction and recovery under time-limited or specific conditions. This mechanism allows corrections during a grace period before immutability takes effect. We validated our approach using WineTracker, a Hyperledger Fabric-based supply chain application. It enables some users to cancel unwanted operations while preserving the blockchain security and maintaining data consistency. Performance evaluations showed minimal overhead with functional benefits.

Figures

Figures reproduced from arXiv: 2411.16976 by the authors.

**Figure 1.** Dependency Graphs 3.7 View Generator The EvoChain View Generator can generate a specific representation of the data within the system. This process filters and structures consistent data, using the generated dependency graph, ensuring that users see the last correct and confirmed version of the object based on the programmed and intended criteria. The view generator is responsible for retrieving the latest valid and… view at source ↗

**Figure 2.** Recovery Example 4 Use Case To test the EvoChain framework, we created a supply chain network model based on selected models from the relevant literature. The goal was to strengthen the claim that EvoChain can be applied in real-world scenarios. Our approach was influenced by the developments of Matt Dean [25], building upon the concept introduced by Biswas et al. [26]. We implemented a simplified model mirroring a … view at source ↗

**Figure 3.** Network Model Assets are submitted to the system as a serialized JSON. Each object has certain attributes inherent to the asset type. In this case, batchId, sellId, owner, and others relevant to the completion of the system. 4.2 EvoChainWineTracker The EvoChainWineTracker is a version of the WineTracker application described before, modified to use EvoChain. The implementation of the framework mainly converts the da… view at source ↗

Figures from the paper (2 more)

**Figure 4.** Figure 4: Comparison of Vanilla and EvoChain Versions of WineTracker [PITH_FULL_IMAGE:figures/full_fig_p011_4.png]

**Figure 5.** Figure 5: Throughput (TPS) by Function and Test Round for TC2 Scenario [PITH_FULL_IMAGE:figures/full_fig_p012_5.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

28 extracted references · 27 canonical work pages

[1]

Bitcoin: A peer-to-peer electronic cash system

Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system. 2008

2008
[2]

Analysis of barriers to implement blockchain in industry and service sectors

Baidyanath Biswas and Rohit Gupta. Analysis of barriers to implement blockchain in industry and service sectors. Computers & Industrial Engineering , 136:225–241, October 2019

work page 2019
[3]

Blockchain-enabled supply chain: analysis, challenges, and future directions

Sohail Jabbar, Huw Lloyd, Mohammad Hammoudeh, Bamidele Adebisi, and Umar Raza. Blockchain-enabled supply chain: analysis, challenges, and future directions. Multimedia Systems, 27(4):787–806, August 2021

work page 2021
[4]

Politou, Fran Casino, Efthimios Alepis, and Constantinos Patsakis

Eugenia A. Politou, Fran Casino, Efthimios Alepis, and Constantinos Patsakis. Blockchain mutability: Challenges and proposed solutions. IEEE Transactions on Emerging Topics in Computing, 9:1972–1986, 2021

work page 1972
[5]

Exploring the redaction mechanisms of mutable blockchains: A comprehensive survey

Di Zhang, Junqing Le, Xinyu Lei, Tao Xiang, and Xiaofeng Liao. Exploring the redaction mechanisms of mutable blockchains: A comprehensive survey. International Journal of Intelligent Systems , 36(9):5051–5084, 2021

work page 2021
[6]

Aries: A transaction recovery method supporting fine-granularity locking and partial rollbacks using write-ahead logging

Chandrasekaran Mohan, Don Haderle, Bruce Lindsay, Hamid Pirahesh, and Peter Schwarz. Aries: A transaction recovery method supporting fine-granularity locking and partial rollbacks using write-ahead logging. ACM Transactions on Database Systems (TODS), 17(1):94–162, 1992

work page 1992
[7]

Practical byzantine fault tolerance

Miguel Castro and Barbara Liskov. Practical byzantine fault tolerance. In Proceedings of the 3rd Symposium on Operating Systems Design and Implementation (OSDI) , volume 99, pages 173–186, 1999

work page 1999
[8]

Korth, Eliezer Levy, and Avi Silberschatz

Henry F. Korth, Eliezer Levy, and Avi Silberschatz. A formal approach to recovery by compensating transactions. Technical report, USA, 1990

work page 1990

Show all 28 references

[9]

Pricing via processing or combatting junk mail

Cynthia Dwork and Moni Naor. Pricing via processing or combatting junk mail. InAnnual international cryptology conference, pages 139–147. Springer, 1992

1992
[10]

Hashcash - a denial of service counter-measure

Adam Back. Hashcash - a denial of service counter-measure. 2002

2002
[11]

Blackcoin’s proof-of-stake protocol v2

Pavel Vasin. Blackcoin’s proof-of-stake protocol v2. URL: https://blackcoin. co/blackcoin-pos-protocol-v2- whitepaper . pdf, 71, 2014

2014
[12]

DPOS Consensus Algorithm - The Missing White Paper, May 2017

Danthemanin Ago. DPOS Consensus Algorithm - The Missing White Paper, May 2017

2017
[13]

Ralph C. Merkle. A digital signature based on a conventional encryption function. In Carl Pomerance, editor, Advances in Cryptology — CRYPTO ’87 , pages 369–378, Berlin, Heidelberg, 1988. Springer Berlin Heidelberg

1988
[14]

Cryptographic hash functions: Recent design trends and security notions

Saif Al-Kuwari, James H Davenport, and Russell J Bradford. Cryptographic hash functions: Recent design trends and security notions. Cryptology ePrint Archive, 2011

2011
[15]

Decentralized Autonomous Organiza- tion To Automate Governance

Christoph Jentzsch, Slock It, Christoph Jentzsch, and Slock It. Decentralized Autonomous Organiza- tion To Automate Governance. page 31. Retrived from https://lawofthelevel.lexblogplatformthree.com/wp- content/uploads/sites/187/2017/07/WhitePaper-1.pdf

2017
[16]

Giuseppe Ateniese, Bernardo Magri, Daniele Venturi, and Ewerton R. Andrade. Redactable blockchain – or – rewriting history in bitcoin and friends. 2017 IEEE European Symposium on Security and Privacy (EuroS&P) , pages 111–126, 2017

2017
[17]

µchain: How to forget without hard forks

Ivan Puddu, Alexandra Dmitrienko, and Srdjan Capkun. µchain: How to forget without hard forks. IACR Cryptol. ePrint Arch., 2017:106, 2017

2017
[18]

Hyperledger – Open Source Blockchain Technologies
[19]

Smith, Alessandro Sorniotti, Chrysoula Stathakopoulou, Marko Vukolic, Sharon Weed Cocco, and Jason Yellick

Elli Androulaki, Artem Barger, Vita Bortnikov, Christian Cachin, Konstantinos Christidis, Angelo De Caro, David Enyeart, Christopher Ferris, Gennady Laventman, Yacov Manevich, Srinivasan Muralidharan, Chet Murthy, Binh Nguyen, Manish Sethi, Gari Singh, Keith A. Smith, Alessand...

2018
[20]

Hyperledger Caliper – Hyperledger Foundation
[21]

John R. Douceur. The Sybil Attack. In Peter Druschel, Frans Kaashoek, and Antony Rowstron, editors, Peer-to- Peer Systems, Lecture Notes in Computer Science, pages 251–260, Berlin, Heidelberg, 2002. Springer

2002
[22]

Information propagation in the bitcoin network

Christian Decker and Roger Wattenhofer. Information propagation in the bitcoin network. In IEEE P2P 2013 Proceedings, pages 1–10, 2013

2013
[23]

Eclipse attacks on Bitcoin’s Peer-to-Peer network

Ethan Heilman, Alison Kendler, Aviv Zohar, and Sharon Goldberg. Eclipse attacks on Bitcoin’s Peer-to-Peer network. In 24th USENIX Security Symposium (USENIX Security 15) , pages 129–144, Washington, D.C., August
[24]

Karame, Vedran Capkun, and Srdjan Capkun

Arthur Gervais, Ghassan O. Karame, Vedran Capkun, and Srdjan Capkun. Is bitcoin a decentralized currency? IEEE Security & Privacy , 12:54–60, 2014

2014
[25]

Blockchain supply chain project

Matt Dean. Blockchain supply chain project. https://github.com/mattdean1/ blockchain-supply-chain. Accessed: September 26, 2023

2023
[26]

Blockchain Based Wine Supply Chain Traceability System

Kamanashis Biswas, Vallipuram Muthukkumarasamy, and Wee Lum. Blockchain Based Wine Supply Chain Traceability System. November 2017

2017
[27]

In search of an understandable consensus algorithm

Diego Ongaro and John Ousterhout. In search of an understandable consensus algorithm. In Proceedings of the 2014 USENIX Conference on USENIX Annual Technical Conference , USENIX ATC’14, page 305–320, USA,

2014
[28]

Security and Privacy on Blockchain, August 2019

Rui Zhang, Rui Xue, and Ling Liu. Security and Privacy on Blockchain, August 2019. arXiv:1903.07602 [cs]. 15

2019 arXiv

Pith tools

Reviewed August 12, 2026 · model on record in the stance chip above.

[1] [1]

Bitcoin: A peer-to-peer electronic cash system

Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system. 2008

2008

[2] [2]

Analysis of barriers to implement blockchain in industry and service sectors

Baidyanath Biswas and Rohit Gupta. Analysis of barriers to implement blockchain in industry and service sectors. Computers & Industrial Engineering , 136:225–241, October 2019

work page 2019

[3] [3]

Blockchain-enabled supply chain: analysis, challenges, and future directions

Sohail Jabbar, Huw Lloyd, Mohammad Hammoudeh, Bamidele Adebisi, and Umar Raza. Blockchain-enabled supply chain: analysis, challenges, and future directions. Multimedia Systems, 27(4):787–806, August 2021

work page 2021

[4] [4]

Politou, Fran Casino, Efthimios Alepis, and Constantinos Patsakis

Eugenia A. Politou, Fran Casino, Efthimios Alepis, and Constantinos Patsakis. Blockchain mutability: Challenges and proposed solutions. IEEE Transactions on Emerging Topics in Computing, 9:1972–1986, 2021

work page 1972

[5] [5]

Exploring the redaction mechanisms of mutable blockchains: A comprehensive survey

Di Zhang, Junqing Le, Xinyu Lei, Tao Xiang, and Xiaofeng Liao. Exploring the redaction mechanisms of mutable blockchains: A comprehensive survey. International Journal of Intelligent Systems , 36(9):5051–5084, 2021

work page 2021

[6] [6]

Aries: A transaction recovery method supporting fine-granularity locking and partial rollbacks using write-ahead logging

Chandrasekaran Mohan, Don Haderle, Bruce Lindsay, Hamid Pirahesh, and Peter Schwarz. Aries: A transaction recovery method supporting fine-granularity locking and partial rollbacks using write-ahead logging. ACM Transactions on Database Systems (TODS), 17(1):94–162, 1992

work page 1992

[7] [7]

Practical byzantine fault tolerance

Miguel Castro and Barbara Liskov. Practical byzantine fault tolerance. In Proceedings of the 3rd Symposium on Operating Systems Design and Implementation (OSDI) , volume 99, pages 173–186, 1999

work page 1999

[8] [8]

Korth, Eliezer Levy, and Avi Silberschatz

Henry F. Korth, Eliezer Levy, and Avi Silberschatz. A formal approach to recovery by compensating transactions. Technical report, USA, 1990

work page 1990