In this post we'll try to compare Blockchain and Event Sourcing main principles. Usually Blockchain usages are proposed for certain purposes and application areas that can be usually provided by traditional data storage and architectural patterns. However, We wanted to compare these principles with something more specific like Event Sourcing given both approaches explicitly share some common principles.
There is a passionate debate in the social media about this topic and perhaps is a good idea to compare our approach in the FEXCO API with Blockchain.
Well, this is the opinion of Mr. Vinton Cerf, not ours. These beginners always pretending they know everything....
According to Wikipedia: [Blockchain] is a growing list of records, called blocks, which are linked using cryptography.[1][6] Blockchains which are readable by the public are widely used by cryptocurrencies. Private blockchains have been proposed for business use. [...] Each block contains a cryptographic hash of the previous block,a timestamp, and transaction data (generally represented as a merkle tree root hash). By design, a blockchain is resistant to modification of the data. It is "an open, distributed ledger that can record transactions between two parties efficiently and in a verifiable and permanent way". For use as a distributed ledger, a blockchain is typically managed by a peer-to-peer network collectively adhering to a protocol for inter-node communication and validating new blocks. Once recorded, the data in any given block cannot be altered retroactively without alteration of all subsequent blocks, which requires consensus of the network majority.
So, a Blockchain is a data structure consisting of a growing number of blocks that are cryptographically-linked through hashes. Because of these links, it's very hard to modify data in the previous blocks since it would require re-calculating the hashes in all subsequent blocks. This data structure can be shared between a group of participants, private or public. These participants agree on certain rules and establish a consensus algorithm. This data structure can be used to keep a reliable distributed ledger, where no participant has the ability to change it (assuming they do not control a majority of nodes that would allow them to impose a consensus). Importantly, this takes place without the need of a central trusted third party.
According to Wikipedia: Ops, there is not an entry for Event Sourcing. This guy, Martin Fowler wrote something about this and we'll assume he knows he is talking about: Event Sourcing ensures that all changes to application state are stored as a sequence of events. Not just can we query these events, we can also use the event log to reconstruct past states, and as a foundation to automatically adjust the state to cope with retroactive changes.
Event sourcing is the practice of capturing all changes as domain events, which are immutable facts of things that have happened. It is also also an architectural pattern that can be used when designing the persistence logic of an application. In traditional, non-event-sourced systems, applications would store the current state to the database, updating this whenever changes occur. When data gets updated, the old data is overwritten, and history is lost. On the other side, in Event Sourcing systems the state is persisted as a series of events in a place called the event store. New events get appended, but they do not overwrite old events. As a result, all history is maintained. The business driver for event sourcing is that this history has value — it enables traceability and compliance; it delivers input for Data Analysis and it allows us to time travel to the state of the system at a given point in time, if there's ever the need to do that.
It is said that Event Sourcing is applied in small, protected environments. Typically, including a single application, which may be a group of microservices. This is not true anymore. Event Sourcing systems can be found in general scope multi-application systems covering multiple areas and regions, sharing the same policies, conventions and rules about event/transaction handling. While most of them are still private many others are publicly shared across partners and affiliates. Again, sharing the same rules. Centralization was a key concept in Event Sourcing but the evolution of architectures, distributed databases and multi-region Cloud IT based systems have strongly decentralized Event Sourcing systems.
Blockchain, on the other hand, is primarily designed to be used publicly, across many organizations and individuals (with private Blockchain systems being a relatively new thing). Does it make sense to have a private/permissioned blockchain system?
No jokes with latency. This is really important since systems MUST provide consistency and secure transactions in a fast, responsive and robust way.
Event sourcing is just one of the ways to implement persistence in fast, online transaction processing systems. Typical transaction latency time is measured in milliseconds. A number of architectural solutions is available to keep delays to a minimum, in particular, the use of snapshots and aggregate caching for data structures in High Availability mode.
On the other hand, Blockchain transaction confirmation is terribly slow because of its reliance on blocks being signed and a consensus being achieved. For instance, the Bitcoin block time is 10 minutes. With six subsequent blocks being a commonly used requirement to consider a transaction confirmed, this gives a delay of one hour on a transaction, although it may be shorter or a lot longer, depending on the circumstances.
The source of Truth in the Event Sourcing systems is multiple and is verified by consensus. The Event Store has the maximum priority in this operations that include early detection, correlation, verification, re-build and correction.
Our approach was quite sensitive to preserve the authenticity of the events in time, allowing the verification of the data in the distributed databases by comparing the generated checksums from the data in the payloads in time. The idea is to detect ASAP inconsistencies and unauthorized changes in the distributed ledgers in the system.
The automation and visualization of these operations are the core of the system insights that any Event Sourcing system should include.
This is the key concept in both systems: Immutability of events/transactions as well as the ability to trace, track, re-build and verify their authenticity. That mean, the ability to keep, protect and preserve the History of the system.
A problem shared between both Event Sourcing and Blockchain based systems is that having full, immutable history may be at odds with legal mandates to erase data, for instance, based on the EU GDPR's article 17 right to erasure. There are several ways of dealing with that. We are working on the implementation of a solution for this based on immutable event erasure.
The extension of a post in a blog is necessarily brief and we just wanted to point at a possible discussion. Both approaches are fascinating and possibly the search for actually useful use cases for Blockchain will be more helpful for this technology than trying to be applied to anything else where other architectural patterns already meet perfectly and much faster
You'll find in the web thousands of comparatives and discussions. However, we think the problem here is not about the technologies but about the problems the technologies are good to solve, the skills in the technical staff and the future maintenance and evolution.
There is a passionate debate in the social media about this topic and perhaps is a good idea to compare our approach in the FEXCO API with Blockchain.
Well, this is the opinion of Mr. Vinton Cerf, not ours. These beginners always pretending they know everything....
What is Blockchain?
According to Wikipedia: [Blockchain] is a growing list of records, called blocks, which are linked using cryptography.[1][6] Blockchains which are readable by the public are widely used by cryptocurrencies. Private blockchains have been proposed for business use. [...] Each block contains a cryptographic hash of the previous block,a timestamp, and transaction data (generally represented as a merkle tree root hash). By design, a blockchain is resistant to modification of the data. It is "an open, distributed ledger that can record transactions between two parties efficiently and in a verifiable and permanent way". For use as a distributed ledger, a blockchain is typically managed by a peer-to-peer network collectively adhering to a protocol for inter-node communication and validating new blocks. Once recorded, the data in any given block cannot be altered retroactively without alteration of all subsequent blocks, which requires consensus of the network majority.
So, a Blockchain is a data structure consisting of a growing number of blocks that are cryptographically-linked through hashes. Because of these links, it's very hard to modify data in the previous blocks since it would require re-calculating the hashes in all subsequent blocks. This data structure can be shared between a group of participants, private or public. These participants agree on certain rules and establish a consensus algorithm. This data structure can be used to keep a reliable distributed ledger, where no participant has the ability to change it (assuming they do not control a majority of nodes that would allow them to impose a consensus). Importantly, this takes place without the need of a central trusted third party.
Blockchain keywords: Immutability, Decentralization, Convention (Consensus), Event/Transaction.
What is Event Sourcing?
According to Wikipedia: Ops, there is not an entry for Event Sourcing. This guy, Martin Fowler wrote something about this and we'll assume he knows he is talking about: Event Sourcing ensures that all changes to application state are stored as a sequence of events. Not just can we query these events, we can also use the event log to reconstruct past states, and as a foundation to automatically adjust the state to cope with retroactive changes.
Event sourcing is the practice of capturing all changes as domain events, which are immutable facts of things that have happened. It is also also an architectural pattern that can be used when designing the persistence logic of an application. In traditional, non-event-sourced systems, applications would store the current state to the database, updating this whenever changes occur. When data gets updated, the old data is overwritten, and history is lost. On the other side, in Event Sourcing systems the state is persisted as a series of events in a place called the event store. New events get appended, but they do not overwrite old events. As a result, all history is maintained. The business driver for event sourcing is that this history has value — it enables traceability and compliance; it delivers input for Data Analysis and it allows us to time travel to the state of the system at a given point in time, if there's ever the need to do that.
Event Sourcing keywords: Immutability, Domain, Convention, Event/Transaction, Temporal Dimension, History.
Main Comparison Indicators
Scope
It is said that Event Sourcing is applied in small, protected environments. Typically, including a single application, which may be a group of microservices. This is not true anymore. Event Sourcing systems can be found in general scope multi-application systems covering multiple areas and regions, sharing the same policies, conventions and rules about event/transaction handling. While most of them are still private many others are publicly shared across partners and affiliates. Again, sharing the same rules. Centralization was a key concept in Event Sourcing but the evolution of architectures, distributed databases and multi-region Cloud IT based systems have strongly decentralized Event Sourcing systems.
Blockchain, on the other hand, is primarily designed to be used publicly, across many organizations and individuals (with private Blockchain systems being a relatively new thing). Does it make sense to have a private/permissioned blockchain system?
Latency
No jokes with latency. This is really important since systems MUST provide consistency and secure transactions in a fast, responsive and robust way.
Event sourcing is just one of the ways to implement persistence in fast, online transaction processing systems. Typical transaction latency time is measured in milliseconds. A number of architectural solutions is available to keep delays to a minimum, in particular, the use of snapshots and aggregate caching for data structures in High Availability mode.
On the other hand, Blockchain transaction confirmation is terribly slow because of its reliance on blocks being signed and a consensus being achieved. For instance, the Bitcoin block time is 10 minutes. With six subsequent blocks being a commonly used requirement to consider a transaction confirmed, this gives a delay of one hour on a transaction, although it may be shorter or a lot longer, depending on the circumstances.
Trust
The source of Truth in the Event Sourcing systems is multiple and is verified by consensus. The Event Store has the maximum priority in this operations that include early detection, correlation, verification, re-build and correction.
Event Immutability
Our approach was quite sensitive to preserve the authenticity of the events in time, allowing the verification of the data in the distributed databases by comparing the generated checksums from the data in the payloads in time. The idea is to detect ASAP inconsistencies and unauthorized changes in the distributed ledgers in the system.
The automation and visualization of these operations are the core of the system insights that any Event Sourcing system should include.
This is the key concept in both systems: Immutability of events/transactions as well as the ability to trace, track, re-build and verify their authenticity. That mean, the ability to keep, protect and preserve the History of the system.
What happens when we want to delete data
A problem shared between both Event Sourcing and Blockchain based systems is that having full, immutable history may be at odds with legal mandates to erase data, for instance, based on the EU GDPR's article 17 right to erasure. There are several ways of dealing with that. We are working on the implementation of a solution for this based on immutable event erasure.
Conclusions
The extension of a post in a blog is necessarily brief and we just wanted to point at a possible discussion. Both approaches are fascinating and possibly the search for actually useful use cases for Blockchain will be more helpful for this technology than trying to be applied to anything else where other architectural patterns already meet perfectly and much faster
You'll find in the web thousands of comparatives and discussions. However, we think the problem here is not about the technologies but about the problems the technologies are good to solve, the skills in the technical staff and the future maintenance and evolution.
Comments
Post a Comment