News

Why I Changed My Mind About Blockchain

Published

on

I studied cryptography in college around the same time that Bitcoin was emerging as a new and unconventional concept. In one of my courses we analyzed the cryptographic building blocks of a cryptocurrency very similar to Bitcoin. While I admired the brilliance of the algorithms and protocols, I wasn’t particularly thrilled with them blockchain technology. My main reservation was that, despite its innovative design, it didn’t solve any problems that I personally found significant.

My skepticism about blockchain continued until a few months ago, when I collaborated with one of Aerospike’s recent clients, the BSV Association. It uses blockchain to elegantly solve an engineering challenge that, as far as I know, has not been effectively addressed elsewhere, especially not so easily: the creation of an unlimitedly and linearly scalable core banking system.

I chose to use “mainstream banking” instead of “cryptocurrency” to avoid the various connotations associated with the latter term. For this discussion, we can think of a cryptocurrency simply as a system that allows customers to create accounts, deposit, withdraw, and transfer funds, functions that mirror those of traditional core banking systems.

In my opinion, core banking systems represent quintessential examples of complex, mission-critical, secure, and precise applications that, despite considerable effort, have consistently resisted modernization.

The Unmodernizables

Many major banking systems are unscalable or scale inefficiently, forcing financial services firms to expend significant resources and effort on only minimal increases in workload capacity. Typically, these scalability limitations arise from a reliance on relational database management systems (RDBMS), such as mainframes or Oracle, which inherently lack the necessary scalability.

Upgrading the heart and soul of major banking systems from RDBMS to scalable, faster, more convenient and efficient NoSQL databases has proven to be extremely challenging. This is largely due to the inherent characteristics of RDBMSs, which are ideal for building complex systems. However, several applications initially developed using a relational approach have managed to successfully transition to NoSQL.

During the transition from RDBMS to NoSQL, the data storage layer inevitably loses some key characteristics while gaining others. These lost features are critical to the functionality of the application and cannot be overlooked. Therefore, it is essential to address the absence of these capabilities within the application layer, which is why migrating highly complex mission-critical systems away from RDBMS is so difficult.

Additionally, RDBMS operations are supported by mathematical proofs, providing unbreakable guarantees of data integrity, even in the presence of application-level bugs. In contrast, in the NoSQL realm, the highest authority is a dude who tests databases for a living (with all due respect). The most it can say is that no bugs were found in the tested version of a technology. Clearly, this level of assurance is insufficient for critical environments such as major banking systems. Therefore, if we intend to abandon the mathematical guarantees offered by the relational model, we must implement similar guarantees within the application layer.

One method to obtain these guarantees is through formal methods. However, given the complexity of core banking systems, building one using only this approach is very challenging.

The potential of Blockchain

Getting the buzzwords out of the way, Blockchain is basically a mathematically proven method zero trust algorithm. Therefore, it can be implemented in the application layer to compensate for the lack of mathematical guarantees in the underlying storage model. Furthermore, the success of Bitcoin proves that blockchain technology can indeed be used effectively to build a central banking system.

However, Bitcoin and numerous other blockchain-based cryptocurrencies are significantly limited by their transaction volume, which is considerably lower than that of traditional non-scalable financial transaction systems. As a result, in this particular aspect, existing cryptocurrencies do not offer substantial improvements over traditional financial systems.

BSV’s Solution to Blockchain Throughput Challenges

Without going into too much detail, the limited throughput of blockchain-based cryptocurrencies mainly stems from this the size of blockchain blocks. For example, the block size of the most famous implementation of White Paper on Bitcoin, Bitcoin, is limited to 1MB, limiting it to processing just seven transactions per second, an embarrassingly low figure. On the contrary, the Bitcoin Cash the implementation managed to increase throughput to over 100 transactions per second by increasing the block size to 32 MB, although this number also remains disappointingly low.

Bitcoin Satoshi Vision, or BSV for short, is another implementation of the Bitcoin White Paper. The main design goal of BSV is to overcome throughput limitations by eliminating the block size cap, theoretically allowing unlimited throughput. However, this modification represents a substantial engineering challenge.

Cryptocurrencies created based on the Bitcoin White Paper use the Unspent transaction output (UTXO), unlike the traditional accounting model used in core banking systems. UTXO information is retrieved and updated in the UTXO store to check whether a Bitcoin transaction can be spent. Any delays in processing a UTXO would significantly reduce the performance of a Bitcoin node, resulting in a loss of revenue for miners.

To speed up this process, it is essential that UTXOs are accessible as quickly as possible. Storing UTXOs in memory would provide the speed needed for efficient operations. However, this approach comes with significant cost implications: millions of transactions per second translate into trillions of UTXOs, requiring tens of terabytes of RAM. Such high resource demands could make the solution prohibitively expensive, posing a major barrier to widespread adoption and scalability.

Aerospike: the key to BSV’s scalable future

Using commodity solid state drives instead of RAM for data storage as Aerospike significantly reduces BSV costs associated with maintaining UTXOs in fast data storage, ensuring efficiency and affordability, which in turn promotes Wider network adoption.

It is important to note that the consistency and integrity of the UTXO storage is crucial for the proper functioning of the node. If the UTXO store becomes corrupted, the node will not be able to successfully participate in revenue generation activities for several cycles, resulting in unwanted but limited damage. Therefore, BSV nodes rely on Aerospike’s Strong Consistency mode to mitigate this risk.

However, the overall correctness of the protocol, including the accuracy of balances and transfers, which could cause unlimited damage if corrupted, relies on strong mathematical guarantees provided by the blockchain at the application level.

Overcoming Barriers: Unprecedented Transaction Capabilities

In the testing phase, the BSV network demonstrated that it can do this support 1 million transactions per second for a long period (weeks). In comparison, the Visa payment system can handle up to 65,000 transactions per second.

To handle 1 million transactions per second, each BSV node, known as a Theranodeit generates about 3 million requests per second on its Aerospike cluster, a significant but modest number compared to other customers.

For example, Criteoa renowned French advertising technology company, uses Aerospike to handle 280 million requests per second, indicating that neither Aerospike nor block size would be a limiting factor in scaling the BSV network.

In a parallel universe

Over the past decade I have assisted several financial institutions in adapting their systems to new use cases, such as mobile banking and regulatory compliance initiatives such as Bank open. A recurring theme in these projects is the implementation of solutions to improve the productivity limits of the underlying systems. In a previous articleI have explained extensively why such approaches are incredibly inefficient.

Typically, these solutions use a scalable database that retrieves data from a non-scalable RDBMS through a complex extract, transform, and load (ETL) process. While these systems increase workload capacity, they require substantial investments in new infrastructure, require millions of hours of engineering work, and result in the creation of complex systems that are difficult to maintain. This is what I call inefficient scaling.

I can imagine a parallel universe in which central systems are unlimitedly and linearly scalable. In such a world, accommodating a new use case that increases demand on the core system could be handled simply by expanding existing infrastructure. There would be no need to build systems whose sole purpose is to protect the weakest link. No increasing complexity. No multi-year, billion-dollar projects just to launch an app.

It is this vision that changed my mind about blockchain.

Learn more about Aerospike’s highly scalable millisecond latency real-time database.

YOUTUBE.COM/THENEWSTACK

Technology moves fast, don’t miss an episode. Subscribe to our YouTube channel to stream all our podcasts, interviews, demos and more.

SUBSCRIBE

Group created with Sketch.

Behrad Babaee is a technology evangelist at Aerospike. He has designed several applications that you could use on a daily basis. He is interested in the non-functional attributes of data-intensive applications such as performance, scalability, availability and efficiency. Behrad uses the vast ability and experience of him…

Read more from Behrad Babaee

Fuente

Leave a Reply

Your email address will not be published. Required fields are marked *

Información básica sobre protección de datos Ver más

  • Responsable: Miguel Mamador.
  • Finalidad:  Moderar los comentarios.
  • Legitimación:  Por consentimiento del interesado.
  • Destinatarios y encargados de tratamiento:  No se ceden o comunican datos a terceros para prestar este servicio. El Titular ha contratado los servicios de alojamiento web a Banahosting que actúa como encargado de tratamiento.
  • Derechos: Acceder, rectificar y suprimir los datos.
  • Información Adicional: Puede consultar la información detallada en la Política de Privacidad.

Trending

Exit mobile version