Blockchain: El Dorado or Mirage?

Is Blockchain Really as Simple to Implement as It Seems? A Simple Showcase

<<will be continued>>

The blockchain hype subsided as quickly as it ignited. It was, more or less, like the DotCom (.com) bubble that imploded with a deafening silence, dragging many companies into the depths of IT history, swallowing hopes and assets, and making individuals and organizations more cautious in their planning. The industrial “fake-it-until-you-make-it” approach proved to be hazardous. The fast revenue potential at the beginning can create a low-pressure area on the marketing maps of a company’s future.

As history often repeats itself, the lessons learned by one generation, which eventually exits the market, are rarely retained by the next. Instead, the same mistakes are repeated. Some individuals become wealthy from these cycles—whether through foresight or luck is questionable—while the majority lose significantly. There are not many technologies that “stick” for the long run, and those that do are usually built on the stable foundations of consistent developments from the past. A few others have begun as student projects with simple technology stacks but solid theoretical groundwork and eventually became giants. Many, however, started with loud fanfare and ambitions but dwindled into exotic remnants of aspirations that were pursued too hastily by individuals too young or impatient to fully think things through.

In the north, large server farms were constructed to accommodate blockchain technology. These would enable processes to be executed autonomously by machines, allowing decisions and actions to occur without direct human intervention. New frameworks were pushed forward to standardize these processes. Companies competed and raced, as they always have, to be the first or the strongest brand leading the industry. Blockchain was envisioned as the industry of the future.

None of this was new in the way it unfolded. However, the basics and fundamentals were ignored. Blockchain itself is a simple yet brilliant concept. Everything surrounding it—servers, connections, communication protocols, project management methods, and so on—is not different or new compared to technologies that have existed for decades. The same problems remain, requiring the same resources and skills to solve them.

The cloud arrived, followed by ML and AI, and suddenly everyone was talking about billions of dollars, euros, yen, and other currencies waiting to be lavishly collected. Young managers swayed in dreams of cushioned clouds made of money. The golden rule of “there are always two sides to a coin” was forgotten, and the superficial attachment to buzzwords and idioms slammed ambitions hard against the office walls.

Experienced consultants in this domain understand what it takes to scale up later, but they also know how to skip unnecessary steps at the right time. They can accurately calculate risks and anticipate the pitfalls of discovering too late in the development process that the chosen tech stack is no longer viable. Even so, if the project is carefully planned—and careful does not necessarily mean slow—surprises that arise can still be managed with minimal loss of time and effort.

Basic Component types

There’s no need to go around in circles: these new technologies and tools do have undeniable benefits. They offer instant, visible advantages—just a few clicks, and you can see results because the “boilerplate” code is automatically generated. But what about the other aspects that are critical to companies? Isn’t this bordering on the “smoke-and-mirrors” antipattern? Flashy, fast results with piles of boilerplate code that remain unfamiliar, untested, and that still require extensive customization and refinement to be usable.

Even SPA (Single Page Applications) need careful design and thoughtful planning. The rush for rapid, visual outcomes often overlooks the deeper, structural considerations that are the foundation of sustainable, scalable solutions.

The easily accessible automation of AI, delivering impressive results like those seen in ChatGPT, creates the illusion that anyone can now "fake-it-until-you-make-it." To some extent, this is true—at least for the first part.

A young manager posts on LinkedIn, claiming that experience is unnecessary, a beginner can outperform expectations, and expertise can simply be bought. The flawed logic doesn’t seem to occur to her: who is going to sell this knowledge and the insights that come with experience? And what will it cost? If experience isn’t necessary, why even bother buying it? Does experience only refer to the number of working years, or does it also encompass the depth of understanding and lessons learned? This upfront delusional and fundamentally wrong approach exposes a lack of understanding of the complexity and skill required in such situations.

Critical factors for success—such as diligence, the will to learn, and the drive to progress with the promise of long-term benefits—are often underestimated. Just because the market is hungry and thirsty for resources doesn’t mean that expertise is endlessly exploitable. In fact, this mindset can demotivate skilled individuals. The more advanced someone’s skills are, the harder it is for others to fully grasp what they’re explaining. This is because beyond academic knowledge lies practical experience, gained in the field, which is absolutely essential.

This brings us back to blockchains. Is it possible to apply the "keep it simple" rule to blockchain-based systems in a way that increases data security and builds more reliable, safer business processes—without diving into an ocean of massive investments and risks by adopting large-scale frameworks from the start?

I believe the answer is yes. Let’s start by simply examining how a blockchain is constructed and expand the discussion from there.

Blockchain (S= Start, H-Head)

There are “massive” frameworks with steep learning curves, accompanied by significant project management risks, as previously mentioned. The investments required can be substantial. However, the greatest benefits of data security can often be achieved with minimal overhead.

The basic application will consist of the usual layers: Front End, Back End (including Business Logic and a Persistence Shadowing Layer), the Middleware (MOM) layer where necessary, and of course, the persistence layer where the data is stored.

In most cases where blockchains are a viable solution, aspects such as scalability and latency are of critical importance. While there is no “one-size-fits-all” approach, it’s highly probable that a microservices architecture will be the goal. For this discussion, even though it’s not mandatory, it will be assumed.

The blockchains will be created and maintained as encrypted data within a wallet. Each user will generate and store their private keys locally as part of the PKI (Public Key Infrastructure), while the corresponding public keys will be uploaded and securely stored in a vault. Users can maintain multiple vaults, each aligned with specific business purposes and goals.

The blockchain itself is a piece of hashed data that also stores its own calculated hash value, which includes the hash of the previous block in the chain. By design, a block cannot be modified—only the last block can be edited, and even then, only under predefined business rules. A vault can be created or deleted, but modifying an earlier block in the chain would require immense computational power, which is unnecessary and impractical in most cases.

In this context, a microservice can initially run locally on-premise during feasibility checks, POC, and prototyping phases, and then scale up as the release rolls out into production. Securing investments can be approached at multiple levels. For example, container technology is a cost-effective option, though it may quickly become expensive depending on the challenges the system encounters during operation.

Building a microservice is relatively straightforward once its purpose is clearly defined and its ports and externally attached volumes are configured. A microservice might serve as a frontend component or fulfill other roles within the system. Additionally, within a virtualized runtime environment, it is possible to integrate databases and messaging providers, which can often be exchanged later—depending on the abstraction level implemented. For instance, starting with a MySQL database and transitioning to a MongoDB NoSQL solution is feasible, provided that no non-ANSI elements are used and an abstraction layer is in place to automate the conversion process.

The idea of coding and running on one platform, ensuring it can run anywhere where the containerized execution engine is installed—in our case, Docker—is highly appealing. It is very reasonable to use frameworks that implement established standards, with trackable change management and release notes, rather than forfeiting the enormous benefits they offer.

Our microservices, as the foundational components, include the frontend, backend, databases, and messaging middleware. To automate and facilitate crash recovery during deployment, a Terraform script will be generated. For a controlled startup and shutdown of the system, a Docker Compose file will be created.

Aspects like logging and monitoring can initially be deferred until the network traffic and data capacities reach the predicted scale. Tools like the ELK Stack or Morpheus can be introduced later, as well as Hadoop and data lakes or schema-less data containers. In the early stages, these are not necessities. Instead, a small, scalable solution will suffice—for example, using SLF4J instead of a more complex framework or local caching instead of Redis instances.

Our microservice will employ a client that can be simple, such as React or Angular, while leveraging a robust and extensive backend framework like Spring and Spring Boot with Java and RESTful services.

Scaling This Blockchain Application
Scaling this blockchain application can be achieved by either scaling up or increasing the number of the smallest execution units, known as microservices—commonly referred to as containers in intermediate technical terminology. With a properly configured setup, scaling becomes straightforward, as it simply involves adjusting the number of containers, assuming sufficient resources such as memory and storage are available. For example, this could mean increasing the number of containers from three to five or from eighteen to twenty, depending on the specific requirements.

Using scripting infrastructures and cloud platforms, scaling is theoretically limitless. In this implementation, horizontal scaling is applied through two servers—or potentially a server farm—managed by a Kubernetes cluster for container orchestration.

Horizontally Scaled Servers in Kubernetes-Clustered, Containerized Microservices

The concept behind data safety in a blockchain is its ability to be validated. If the blockchain is tampered with, it becomes invalid and unusable, prompting further measures to be taken. The data is stored across multiple data centers, each holding identical copies of the blockchain. During read or write transactions, the hashes can be compared across these instances to ensure validation.

Data replication occurs during the processes of vault and blockchain creation or deletion. As mentioned, the only blockchain that can be edited is the most recent one within a vault, commonly referred to as "the head." The validation of blockchain hashes for ensuring integrity can be performed through peer-to-peer connections.

Here’s a possible, simple, self-tailored schema for implementing this approach:

Leveraged Distributed Persistence

<<will be continued>>

Glossar