The Easiest Way of Turning your Relational Database into a Blockchain and the Cost of Doing So

2025-05-06 0 0 620.38KB 23 页 10玖币

侵权投诉

cba

The Easiest Way of Turning your Relational Database into a

Blockchain — and the Cost of Doing So

Felix Schuhknecht1

, Simon Jörz2

Abstract: Blockchain systems essentially consist of two levels: The network level has the responsibility

of distributing an ordered stream of transactions to all nodes of the network in exactly the same way,

even in the presence of a certain amount of malicious parties (byzantine fault tolerance). On the

node level, each node then receives this ordered stream of transactions and executes it within some

sort of transaction processing system, typically to alter some kind of state. This clear separation into

two levels as well as drastically diﬀerent application requirements have led to the materialization of

the network level in form of so-called blockchain frameworks. While providing all the “blockchain

features”, these frameworks leave the node level backend ﬂexible or even left to be implemented

depending on the speciﬁc needs of the application.

In the following paper, we present how to integrate a highly versatile transaction processing system,

namely a relational DBMS, into such a blockchain framework. As framework, we use the popular

Tendermint Core, now part of the Ignite/Cosmos eco-system, which can run both public and

permissioned networks and combine it with relational DBMSs as the backend. This results in a

“relational blockchain”, which is able to run deterministic SQL on a fully replicated relational database.

Apart from presenting the integration and its pitfalls, we will carefully evaluate the performance

implications of such combinations, in particular, the throughput and latency overhead caused by the

blockchain layer on top of the DBMS. As a result, we give recommendations on how to run such a

systems combination eﬃciently in practice.

Keywords: Blockchain; Relational Databases; Distributed Query Processing; Tendermint

1 Introduction

In recent years, blockchain systems gained interest in various contexts, as they provide dis-

tributed transaction processing in potentially untrusted environments. Whereas the original

applications mainly targeted public environments such as crypto currencies [

Na09

Et22

blockchain systems have also gained interest in permissioned setups, where independent

and potentially distrusting organizations, such as for instance companies trading with each

other, want to perform some sort of mutual transaction processing [IB22a, IB22b, Te22a].

Johannes Gutenberg University Mainz, Institute of Computer Science, Staudingerweg 9, 55128 Mainz, Germany

schuhknecht@uni-mainz.de

Johannes Gutenberg University Mainz, Institute of Computer Science, Staudingerweg 9, 55128 Mainz, Germany

sjoerz@students.uni-mainz.de

arXiv:2210.04484v1 [cs.DB] 10 Oct 2022

While the needs and environments for blockchain systems exist, a major downforce for the

application of this technology has always been its hard entry level. Existing blockchain

systems are often tailored towards a speciﬁc use-case or application domain and therefore

are hard to apply for new application types. To deal with this challenge, one of the three

following strategies is typically applied: (1) To reinvent the wheel and to engineer a new

blockchain system from scratch, ﬁtting to the speciﬁc needs. (2) To carefully adapt an

existing blockchain system to the new requirements. (3) To not install a blockchain solution

at all. Of course, often, consequence (3) is picked as (1) and (2) are cumbersome and

therefore costly.

A step towards solving this problem is the observation that all blockchain systems essentially

consist only of two major components. The ﬁrst component manages the network level. It

receives input transactions, orders them globally, and distributes the transaction sequence to

each node of the network in exactly the same way. The challenge here lies in performing

this in an untrusted environment, where a certain amount of participants might behave

maliciously or at least arbitrarily. To guarantee safety and liveness in such an environment,

network levels implement sophisticated consensus mechanisms, secure message passing, and

tamper-proof transaction logging. Despite various diﬀerent implementations, the network

level is rather independent from the actual application, as the semantics of the transactions

are not relevant for this part. The second component manages the node level and centers

around the processing of transactions within each node. Naturally, the requirements here

are highly application dependent. For instance, to implement a currency, a simple key-

value-store backend managing account balances with a put()/get()/delete() interface

is suﬃcient. However, to power complex sales operations, a relational database system

oﬀering full-ﬂedged SQL support is certainly the better choice.

As a consequence of these observations, blockchain frameworks have emerged that try

to strictly separate their components by design. For example, the popular permissioned

blockchain framework Hyperledger Fabric [

An18

] provides exchangeable default imple-

mentations for its individual components. While this is a step in the right direction, Fabric

unfortunately still forces the user to stick to the key-value model. This limitation is overcome

by the framework Tendermint Core [

Te22b

], which leaves the node level backend fully

unimplemented. It is up the application to provide a backend which receives and processes

the transactions that are distributed by the framework to each node.

As this is a promising design for tackling the initial problem, in this work, we investigate

how challenging and how practical it is to connect a transaction processing backend to

the blockchain framework Tendermint Core. To cover a wide range of applications, we

integrate a highly-versatile transaction processing system, namely a relational DBMS.

We show how to create a “relational blockchain” with minimal eﬀort and are especially

interested in the overhead that is caused by this combination. We will investigate the latency

and throughput of the relational blockchain under the drastically diﬀerent synchronous,

pseudo-synchronous, and asynchronous communication, each appropriate for diﬀerent types

of applications. Further, we will look at the scaling behavior of the system and discuss

important conﬁguration parameters. In summary, we will provide recommendations on how

to use such a relational blockchain eﬃciently in practice.

1.1 Contributions

We present how to integrate a stand-alone single-node relational DBMS into the

blockchain framework Tendermint. Our current implementation supports PostgreSQL

and MySQL and can easily be extended for further systems. As a result of this

combination, we produce a relational blockchain that can execute (deterministic)

SQL transactions equally across a set of potentially untrusted nodes to modify a fully

replicated database.

We evaluate latency and throughput/end-to-end runtime of the relational blockchain

under Smallbank [

Sm13

] and TPC-C [

TP22

] transactions. We compare its perfor-

mance with a standalone execution of the workloads in PostgreSQL to identify the

overhead that is caused by the blockchain framework on top of the relational backend.

We evaluate the impact of three diﬀerent communication methods, namely syn-

chronous, pseudo-synchronous, and asynchronous communication. We show that the

choice of the communication method has a drastic impact on the performance of the

system.

We evaluate the impact of the relational backends, namely PostgreSQL and MySQL,

under synchronous and asynchronous communication.

We evaluate the scaling capabilities of the relational blockchain. Here, we ﬁrst scale

the number of virtual nodes within a physical node, which factors out network latency

and resembles the Blockchain-as-a-Service (BaaS) setup. Then, we scale number of

physical nodes within and across data-centers, resembling the classical distributed

setup, facing network/internet latency.

We provide practical recommendations in which situations a relational blockchain

yields a good performance – and in which situations it does not. To allow and easy

application of our ﬁndings, we will release all code, results, scripts and auxiliary

material of this paper in the repository: https://gitlab.rlp.net/fschuhkn/relational-

blockchain

The paper is structured as follows: In Section 2, we start with a discussion of the related

work in the ﬁeld. In Section 3, we present how to integrate the support for relational DBMSs

into Tendermint Core. Therein, we also describe the diﬀerences between the diﬀerent types

of communication. In Section 4, we discuss the precise setup and empirically determined

conﬁguration used for the evaluation. In Section 5, we perform an extensive experimental

evaluation of the relational blockchain with a focus on the generated overhead and scaling

capabilities. Finally, in Section 6, we conclude with recommendations on whether and how

to use such a systems combination in practice.

2 Related Work

Before presenting our relational blockchain, let us discuss other work that sits at the

intersection of blockchains and database systems.

There exists other interesting work that analyzes and/or builds upon the Tendermint

framework. In [

Ca21

Bu22

], the authors perform an interesting performance analysis of the

internal behavior of the framework. In [

Am18

], the authors analyze correctness and fairness

of the system. The ﬁndings in these works justify our use and setup of Tendermint: The

framework powers hundreds of applications of the Cosmos network, where most networks

are tightly coupled with only few nodes. Latency and throughput decreases gracefully with

the number of nodes participating in the consensus. Tendermint has also been used before

to connect DBMSs as the backend. A prominent example is BigchainDB [

Bi22

], which uses

the document store MongoDB [Mo22] as backend.

Apart from Tendermint, there exist other blockchain frameworks. The most prominent

representative is clearly Hyperledger Fabric [

An18

], designed to power permissioned

blockchain networks. The modular design is composed of interchangeable components that

allow a tuning of the network to the speciﬁc needs of the application up to a certain degree.

Unfortunately, the system is hardcoded against a key-value model, such that the integration of

a relational backend is not possible without deep changes of the system. Another blockchain

framework is ChainifyDB [

Sc21b

], that allows the creation of heterogeneous blockchain

networks. Here, heterogeneous means that diﬀerent relational systems can be used across

a single network. The applied processing model still ensures correctness of transaction

processing.

Apart from frameworks, many research papers discuss the interconnection and rela-

tion of classical DBMSs and blockchain systems and how to combine both worlds. In

BlockchainDB [

El19b

El19a

], a database layer is placed on top of a blockchain layer to

combine the proper query interface of a database systems with the replication guarantees

of a blockchain. In [

Na19

], the authors take the other route and extend a relational system,

namely PostgreSQL, with a blockchain layer in order to create a blockchain network between

multiple PostgreSQL instances. Unfortunately, this project requires a deep modiﬁcation of

PostgreSQL. Another interesting project is Veritas [

Ge19

]. Therein, the authors propose to

extend existing DBMSs with blockchain features in a cloud environment.

Apart from architectural works, many projects try to improve the performance of blockchain

systems in order to converge towards the performance of traditional (distributed) DBMSs. In

Fabric++ [

Sh19

], several optimization techniques from the database domain are transferred to

Fabric in order to speed up processing. Other works try to improve blockchain performance

via sharding [

Da19

] and various low-level optimizations in the transaction processing

ﬂow [Go19].

3 Setting up a Relational Blockchain

In the following section, we will discuss how to integrate a relational DBMS into the

Tendermint framework, which we believe is a good template for how blockchain frameworks

are reasonably engineered. On the backend side, we will focus on relational DBMSs in this

work. However, the general process is applicable to non-relational transaction processing

backends in a similar fashion.

3.1 The Blockchain Framework: Tendermint Core

The design goal of the blockchain framework Tendermint Core [

Te22b

] is to provide

essentially all those components that are shared in typical blockchain environments [

Di18

Sc21a], but nothing more than that. Precisely, the entire transaction processing backend is

left unimplemented and must be provided by the application side. There are two requirements

for the backend: (1) The same backend must be used within all nodes of the network. (2) This

backend must be deterministic, i.e., it executes a block of transactions in the same way on

all nodes. Overall, this design has pleasant advantages: On one hand, such a framework

approach removes the need to reinvent the wheel by reimplementing essential components

of blockchain systems. On the other hand, it grants the framework ﬂexibility to support a

large variety of applications.

The most essential components that are already provided by Tendermint Core are:

Atransaction pool which has the responsibility to receive and hold transactions that

are pending for ordering and execution. All submitted input transactions ﬁrst go into

this pool, where they can be rejected already, if they do not match user-speciﬁed

criteria, by implementing the function CheckTx(). The pool itself is lazily replicated

across the nodes, i.e., nodes share pending transactions with other nodes via gossip

broadcasting.

Aconsensus mechanism called Polka, which is a variation of the well-known

PBFT [

CL99

] consensus. It can tolerate up to

𝑓

maliciously behaving parties in a set

of 3

𝑓+

1parties in total. While the mechanism is tailored towards a permissioned

setup, where all participants are known at all times, it can be extended to work in a

public environment as well by using a Proof-of-Stake-like approach. As this requires

the integration of a currency, in this work, we run the default version of the consensus

mechanism in a permissioned environment.

The ledger, which stores the observed sequence of committed transactions at the

granularity of blocks within each node in a tamper-resistant way.

Amessage passing system that ensures a secure communication between individual

parties of the network.

文档加载中……请稍候！
如果长时间未打开，您也可以点击刷新试试。

下载文档到电脑，查找使用更方便

10 玖币 0人已下载

立即下载

摘要：

TheEasiestWayofTurningyourRelationalDatabaseintoaBlockchain—andtheCostofDoingSoFelixSchuhknecht1,SimonJörz2Abstract:Blockchainsystemsessentiallyconsistoftwolevels:Thenetworklevelhastheresponsibilityofdistributinganorderedstreamoftransactionstoallnodesofthenetworkinexactlythesameway,eveninthepresen...

展开>> 收起<<

The Easiest Way of Turning your Relational Database into a Blockchain and the Cost of Doing So.pdf

共23页,预览5页

还剩页未读，继续阅读

声明：本站为文档C2C交易模式，即用户上传的文档直接被用户下载，本站只是中间服务平台，本站所有文档下载所得的收益归上传人(含作者)所有。玖贝云文库仅提供信息存储空间，仅对用户上传内容的表现方式做保护处理，对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私，请立即通知玖贝云文库，我们立即给予删除！

The Easiest Way of Turning your Relational Database into a Blockchain and the Cost of Doing So

相关推荐

开通VIP享超值会员特权

作者详情

相关内容

热门标签

举报选择: