The blockchain systems architecture is very interesting subject. Despite its apparent complexity, it actually consists of fairly simple elements that are widely used not only in blockchain systems, but also in software development in the industry. Yes, everything is quite complicated and simple at the same time. Paradox? I propose to understand and try to highlight the key elements that make up all blockchain systems and distributed ledgers.
Event Store
So let’s start from the beginning. Users interact with blockchains by sending transactions. We will not go into details about signing transactions with the user’s key, and although all this cryptography is very interesting, in this case it provides only one of the validation stages. So, transactions, which are user requests to the system, are sent by the user to enter the system, are checked for validity, queued and stored in this queue forever. All of this leads to thought of using the Event Sourcing pattern. This means that it is always possible to process the entire sequence of events to obtain the actual state of the system. And since events are stored indefinitely and in strict sequence, one can come to the conclusion that the blockchain is a kind of event store. One of the event store options for traditional software development is Kafka.
Validator
The next step in processing requests (transactions) in blockchain systems is validation. The user’s signature and a number of other parameters are checked. An important function of the validator is to limit user activity to prevent network congestion and limit especially active users. How the validator will work and what exactly is checked depends on the validator itself and its configuration. There are systems with custom validators, such as Ethereum. Yes, those smart contracts allow you to configure the validator, determining which requests will be processed by the system and which will not. And of course, the validator may have a state that is affected by requests processed by the system, but storing this state is not important, since it can always be restored by reprocessing the entire request sequence again.
Consensus
Any distributed systems, and all blockchains are distributed systems, require some sort of consensus algorithm. The purpose of the consensus algorithm is to ensure data synchronization between network nodes. One of the most widely used traditional consensus algorithms is Raft. However, it is not applicable to blockchain systems due to the possible presence of dishonest nodes in the network. Instead, variations of the Byzantine Fault Tolerance (BFT) algorithms are used. And yes, of course, you will have to come up with some way to determine the trusted nodes that will be allowed to vote in the consensus process.
Consensus, although it comes third on the list, is the most important and complex part of the system, because it depends on how resilient the system will be to various types of technical failures, network problems and malicious attacks.
And Some More
Yes, the above three elements are key to the implementation of any blockchain system. Of course, it is also desirable to store the current state and add indexes for searching through transactions, but all these are just auxiliary elements that provide the convenience of working with the system. Although most of the existing blockchains do not very pamper users with convenience.