introduction.tex

Databases and database technology have played an important part in both business and society for decades. Databases began as simple, monolithic servers. As the need for more powerful functionalities grew, things like relational databases and query languages (i.e. SQL) were invented to deal with the growing need for improved efficiency and ease of use. As the world became more connected and global, distributed databases emerged, and things like consensus algorithms and fault tolerance became popular topics in both academia and business.

Now, the world has become so interconnected that many different people and entities need to be able to use the same database(s). Traditional distributed databases typically assumed that all users were honest, and errors were the result of poor network conditions or other faults that were not due to adversarial behavior. In today's world, however, people who have competitive or even adversarial relationships with one another, even within the same entity, may need to access or edit the same information in the same database. To solve this problem, distributed ledger technology and blockchain technology were developed. The basic idea is fairly simple: with clever applications of cryptography and distributed systems concepts to traditional databases, many more useful applications can be constructed in ways that do not require a central trusted authority or reduce the trust requirements on the participants. With this in mind, we can view both blockchain and distributed ledger technology as the emerging field at the intersection of databases, cryptography and distributed systems.

Historically, databases have focused on single party applications purely out of necessity.  Since distributed databases allow for multiparty, shared database use, distributed ledgers can be equipped with multi-party business logic, which is more commonly referred to as \emph{smart contracts}.  This allows distributed ledgers to be used for substantially more applications than traditional databases.

While there are many definitions of the terms \emph{blockchain} and \emph{distributed ledger}, we will define them here for clarity. For the purposes of this paper, we refer to a \emph{blockchain} as a shared, append-only log of transactions (nothing can ever be erased or edited--only appends are allowed). We define a \emph{distributed ledger} as a multi-party, distributed database where there is no central trusted authority. When transactions are processed in blocks according to the ordering of a blockchain, the result is a distributed ledger.  In spite of our desire to clarify these terms, we will bow to popular press and use these terms interchangeably. 

Hyperledger builds on this rich technology background to bring blockchain-based distributed ledgers into a broad class of enterprise usages.  Broadly speaking, Hyperledger is an `umbrella' for open source distributed ledger platforms and related components and modules. The community of developers who participate in Hyperledger coordinate cross-industry, open source software development for projects that meet the diverse needs of those building and deploying distributed ledgers. 

The most popular existing blockchains like Bitcoin~\cite{Nak08} and Ethereum~\cite{But13} utilize completely trustless networks.  But most enterprise applications rely upon real world trust relationships that Hyperledger projects can leverage to gain efficiency, functionality, or both.

While supporting diversity of blockchain and distributed ledger technologies (necessary to meet the unique needs of enterprise applications) the consortium structure of Hyperledger also provides a means of bringing coordination from the chaos: identifying common components, avoiding duplication of effort, promoting interoperability and portability, and providing a diverse community for feedback.

In the remaining sections of the paper, we will explain what Hyperledger is and many of the design decisions and principles of the effort.

\subsection{Outline}
The rest of the paper proceeds as follows.  We start by discussing the benefits of an open source platform in section~\ref{sec:WhyOpenSource}.  In section~\ref{sec:TheUmbrellaOrganization}, we explain the umbrella nature of Hyperledger's governance structure.  We then go on to explain our design philosophy for Hyperledger in section~\ref{sec:DesignPhilosophy}.

We then move in a more practical direction.  In section~\ref{sec:RelevantUseCases}, we explain some of the interesting use cases that we expect some (or most) of the Hyperledger projects to address.  In section~\ref{sec:CurrentProjects} we list and outline each of the current top-level Hyperledger projects, and we then follow that up in section~\ref{sec:LongTermVision} with our long-term vision for Hyperledger.  Finally, in section~\ref{sec:Conclusion} we offer our final thoughts.