  Within the last few years, a countless number of blockchain systems have
emerged on the market, each one claiming to revolutionize the way of
distributed transaction processing in one way or the other. Many blockchain
features, such as byzantine fault tolerance (BFT), are indeed valuable
additions in modern environments. However, despite all the hype around the
technology, many of the challenges that blockchain systems have to face are
fundamental transaction management problems. These are largely shared with
traditional database systems, which have been around for decades already.
  These similarities become especially visible for systems, that blur the lines
between blockchain systems and classical database systems. A great example of
this is Hyperledger Fabric, an open-source permissioned blockchain system under
development by IBM. By having a relaxed view on BFT, the transaction pipeline
of Fabric highly resembles the workflow of classical distributed databases
systems.
  This raises two questions: (1) Which conceptual similarities and differences
do actually exist between a system such as Fabric and a classical distributed
database system? (2) Is it possible to improve on the performance of Fabric by
transitioning technology from the database world to blockchains and thus
blurring the lines between these two types of systems even further? To tackle
these questions, we first explore Fabric from the perspective of database
research, where we observe weaknesses in the transaction pipeline. We then
solve these issues by transitioning well-understood database concepts to
Fabric, namely transaction reordering as well as early transaction abort. Our
experimental evaluation shows that our improved version Fabric++ significantly
increases the throughput of successful transactions over the vanilla version by
up to a factor of 3x.
