├── .gitignore ├── CurrentProjects ├── burrow.tex ├── cello.tex ├── composer.tex ├── current_projects.tex ├── explorer.tex ├── fabric.tex ├── indy.tex ├── iroha.tex └── sawtooth.tex ├── GGEdit ├── CurrentProjects │ ├── burrow.tex │ ├── cello.tex │ ├── composer.tex │ ├── current_projects.tex │ ├── explorer.tex │ ├── fabric.tex │ ├── indy.tex │ ├── iroha.tex │ ├── quilt.tex │ ├── sawtooth.tex │ ├── summary_of_hyperledger_projects_page1.pdf │ └── summary_of_hyperledger_projects_page2.pdf ├── RelevantUseCases │ ├── applying_for_a_loan.tex │ ├── credentialing_doctors.tex │ ├── graphic_seafood_supply_chain.png │ ├── managing_identities.tex │ ├── post_trade_processing.tex │ ├── relevant_use_cases.tex │ └── tracking_fish_from_ocean_to_table.tex ├── conclusions.tex ├── design_philosophy.tex ├── front_matter.tex ├── hyperledger_paper_GG.tex ├── introduction.tex ├── the_umbrella_organization.tex ├── vision.tex └── why_open_source.tex ├── HighlightedFeatures ├── highlighted_features.tex └── identity.tex ├── LICENSE ├── Makefile ├── README.md ├── RelevantUseCases ├── HealthCredentialing.tex ├── applying_for_a_loan.tex ├── financial_services.tex ├── identity.tex ├── relevant_use_cases.tex └── supply_chain.tex ├── authors.tex ├── breakcites.sty ├── conclusion.tex ├── design_philosophy.tex ├── figures └── FishSupplyChain.png ├── hyperledger.bib ├── introduction.tex ├── latexdefs.tex ├── llncs.cls ├── paper.pdf ├── paper.tex ├── the_umbrella_organization.tex ├── vision.tex └── why_open_source.tex /.gitignore: -------------------------------------------------------------------------------- 1 | ## Core latex/pdflatex auxiliary files: 2 | *.aux 3 | *.lof 4 | *.log 5 | *.lot 6 | *.fls 7 | *.out 8 | *.toc 9 | *.fmt 10 | *.fot 11 | *.cb 12 | *.cb2 13 | 14 | ## Intermediate documents: 15 | *.dvi 16 | *-converted-to.* 17 | # these rules might exclude image files for figures etc. 18 | # we don't want these because it will be a pain 19 | *.ps 20 | *.eps 21 | *.pdf 22 | 23 | ## Bibliography auxiliary files (bibtex/biblatex/biber): 24 | *.bbl 25 | *.bcf 26 | *.blg 27 | *-blx.aux 28 | *-blx.bib 29 | *.brf 30 | *.run.xml 31 | 32 | ## Build tool auxiliary files: 33 | *.fdb_latexmk 34 | *.synctex 35 | *.synctex.gz 36 | *.synctex.gz(busy) 37 | *.pdfsync 38 | 39 | ## Auxiliary and intermediate files from other packages: 40 | # algorithms 41 | *.alg 42 | *.loa 43 | 44 | # achemso 45 | acs-*.bib 46 | 47 | # amsthm 48 | *.thm 49 | 50 | # beamer 51 | *.nav 52 | *.snm 53 | *.vrb 54 | 55 | # cprotect 56 | *.cpt 57 | 58 | # fixme 59 | *.lox 60 | 61 | #(r)(e)ledmac/(r)(e)ledpar 62 | *.end 63 | *.?end 64 | *.[1-9] 65 | *.[1-9][0-9] 66 | *.[1-9][0-9][0-9] 67 | *.[1-9]R 68 | *.[1-9][0-9]R 69 | *.[1-9][0-9][0-9]R 70 | *.eledsec[1-9] 71 | *.eledsec[1-9]R 72 | *.eledsec[1-9][0-9] 73 | *.eledsec[1-9][0-9]R 74 | *.eledsec[1-9][0-9][0-9] 75 | *.eledsec[1-9][0-9][0-9]R 76 | 77 | # glossaries 78 | *.acn 79 | *.acr 80 | *.glg 81 | *.glo 82 | *.gls 83 | *.glsdefs 84 | 85 | # gnuplottex 86 | *-gnuplottex-* 87 | 88 | # hyperref 89 | *.brf 90 | 91 | # knitr 92 | *-concordance.tex 93 | # TODO Comment the next line if you want to keep your tikz graphics files 94 | *.tikz 95 | *-tikzDictionary 96 | 97 | # listings 98 | *.lol 99 | 100 | # makeidx 101 | *.idx 102 | *.ilg 103 | *.ind 104 | *.ist 105 | 106 | # minitoc 107 | *.maf 108 | *.mlf 109 | *.mlt 110 | *.mtc 111 | *.mtc[0-9] 112 | *.mtc[1-9][0-9] 113 | 114 | # minted 115 | _minted* 116 | *.pyg 117 | 118 | # morewrites 119 | *.mw 120 | 121 | # mylatexformat 122 | *.fmt 123 | 124 | # nomencl 125 | *.nlo 126 | 127 | # sagetex 128 | *.sagetex.sage 129 | *.sagetex.py 130 | *.sagetex.scmd 131 | 132 | # sympy 133 | *.sout 134 | *.sympy 135 | sympy-plots-for-*.tex/ 136 | 137 | # pdfcomment 138 | *.upa 139 | *.upb 140 | 141 | # pythontex 142 | *.pytxcode 143 | pythontex-files-*/ 144 | 145 | # thmtools 146 | *.loe 147 | 148 | # TikZ & PGF 149 | *.dpth 150 | *.md5 151 | *.auxlock 152 | 153 | # todonotes 154 | *.tdo 155 | 156 | # xindy 157 | *.xdy 158 | 159 | # xypic precompiled matrices 160 | *.xyc 161 | 162 | # endfloat 163 | *.ttt 164 | *.fff 165 | 166 | # Latexian 167 | TSWLatexianTemp* 168 | 169 | ## Editors: 170 | # WinEdt 171 | *.bak 172 | *.sav 173 | 174 | # Texpad 175 | .texpadtmp 176 | 177 | # Kile 178 | *.backup 179 | 180 | # KBibTeX 181 | *~[0-9]* 182 | -------------------------------------------------------------------------------- /CurrentProjects/burrow.tex: -------------------------------------------------------------------------------- 1 | Hyperledger Burrow (\url{https://github.com/hyperledger/burrow}) is a permissionable smart contract machine; it became the fourth distributed ledger platform under the Hyperledger umbrella in April, 2017. It was originally developed and proposed to Hyperledger by Monax. 2 | 3 | Burrow provides a modular blockchain client with a permissioned smart contract interpreter built to the specification of the Ethereum Virtual Machine (EVM). Burrow provides a strongly deterministic, smart contract focused, blockchain design to Hyperledger's overall effort. Users of Burrow are able to benefit from having an access control layer through the use of smart contracts and “secure natives” based permission layer. 4 | 5 | The major components of Burrow are as follows: 6 | \begin{itemize} 7 | \item Consensus engine which is responsible for maintaining the networking stack between nodes and ordering transactions to be utilized by the application engine. 8 | \item Application Blockchain Interface (“ABCI”) provides the interface specification for the consensus engine and application engine to connect. 9 | \item Smart contract application engine provides application builders with a strongly deterministic smart contract engine for operating complex industrial processes. 10 | \item Gateway provides programmatic interfaces for systems integrations and user interfaces. 11 | \end{itemize} 12 | -------------------------------------------------------------------------------- /CurrentProjects/cello.tex: -------------------------------------------------------------------------------- 1 | Hyperledger Cello (\url{https://github.com/hyperledger/cello}) is an open framework to help people adopt blockchain technologies efficiently and easily, by providing automatic ways in blockchain provision and operational management. 2 | 3 | It brings the on-demand "as-a-service" deployment model to the blockchain ecosystem to reduce the effort required for maintaining the lifecycle of the Hyperledger blockchain frameworks. It provides a multi-tenant chain service efficiently and automatically on top of various infrastructures, including baremetal, virtual machine, Cloud platforms like AWS, and container platforms like Docker Swarm and Kubernetes, overall helping provide "Blockchain as a Service" efficiently. It also helps with maintainance through a dashboard where users can watch the statistics/status of the blockchain system (e.g., system utilization, blockchain events, chaincode performance), and manage the blockchains (e.g., create, config and delete) and chaincode (e.g., deploy and upload private chaincode) in real-time. 4 | 5 | Hyperledger Cello currently has supported Hyperledger Fabric 1.0 as the main blockchain implementation, while it has plans to support more blockchain types like Sawtooth. The architecture follows the micro-service style, with pluggable implementations for most components. The main programing languages are Python and JavaScript. -------------------------------------------------------------------------------- /CurrentProjects/composer.tex: -------------------------------------------------------------------------------- 1 | Hyperledger Composer (\url{https://github.com/hyperledger/composer}) is an extensive, open development toolset and framework to make developing blockchain applications easier. Its primary goal is to accelerate time to value and make it easier to integrate your blockchain applications with the existing business systems. You can use Hyperledger Composer to rapidly develop use cases and deploy a blockchain solution in weeks rather than months. It also allows you to model your business network and integrate existing systems and data with your blockchain applications. 2 | 3 | You can use Hyperledger Composer to quickly model your current business network, containing your existing assets, such as tangible or intangible goods, services, or property, and the transactions related to them. As part of your business network model, you define the transactions which can interact with assets. Business networks also include the participants who interact with them, each of which can be associated with a unique identity across multiple business networks. 4 | 5 | Hyperledger Composer supports the existing Hyperledger Fabric blockchain infrastructure and runtime, which supports pluggable blockchain consensus protocols to ensure that transactions are validated according to policy by the designated business network participants. 6 | -------------------------------------------------------------------------------- /CurrentProjects/current_projects.tex: -------------------------------------------------------------------------------- 1 | \subsection{Fabric} 2 | \input{CurrentProjects/fabric.tex} 3 | 4 | \subsection{Sawtooth} 5 | \input{CurrentProjects/sawtooth.tex} 6 | 7 | \subsection{Iroha} 8 | \input{CurrentProjects/iroha.tex} 9 | 10 | \subsection{Burrow} 11 | \input{CurrentProjects/burrow.tex} 12 | 13 | \subsection{Indy} 14 | \input{CurrentProjects/indy.tex} 15 | 16 | \subsection{Cello} 17 | \input{CurrentProjects/cello.tex} 18 | 19 | \subsection{Composer} 20 | \input{CurrentProjects/composer.tex} 21 | 22 | \subsection{Explorer} 23 | \input{CurrentProjects/explorer.tex} -------------------------------------------------------------------------------- /CurrentProjects/explorer.tex: -------------------------------------------------------------------------------- 1 | Hyperledger Explorer (\url{https://github.com/hyperledger/blockchain-explorer}) provides a dashboard for viewing information about transactions, blocks, node logs, statistics, and smart contracts available on the network. Users will be able to query for specific blocks or transactions and view the complete details. Blockchain explorer can also be integrated with any authentication/authorization platforms (commercial/open source) and will provided appropriate functionality based on the privileges available to the user. 2 | Goals of the project are listed below. 3 | To implement a generic Blockchain explorer web application which is easy to install and can be used with different Blockchain platforms. 4 | Use latest tools and technologies that make the explorer easy to implement, maintain and extend. 5 | Easily installable package available through standard package managers for most popular platforms. 6 | 7 | 8 | -------------------------------------------------------------------------------- /CurrentProjects/fabric.tex: -------------------------------------------------------------------------------- 1 | Hyperledger Fabric (\url{https://github.com/hyperledger/fabric} and further repositories named like \url{fabric-*}) is a platform for distributed ledger solutions, underpinned by a modular architecture delivering high degrees of confidentiality, resiliency, flexibility and scalability. It is designed to support pluggable implementations of different components, and to accommodate the complexity and intricacies that exist across the economic ecosystem. 2 | 3 | Starting from the premise that there are no ``one-size-fits-all'' solutions, Fabric is an extensible blockchain platform for running distributed applications. It supports modular consensus protocols, which allows the system to be tailored to particular use cases and trust models. Fabric runs distributed applications written in general-purpose programming languages, without systemic dependency on a native cryptocurrency. This stands in sharp contrast to most other blockchain platforms for running smart contracts that require code to be written in domain-specific languages or rely on a cryptocurrency. Furthermore, it uses a portable notion of membership for realizing the permissioned model, which may be integrated with industry-standard identity management. To support such flexibility, Fabric takes a novel architectural approach and revamps the way blockchains cope with non-determinism, resource exhaustion, and performance attacks. 4 | 5 | %Where Hyperledger Fabric breaks from some other blockchain systems is that it is private and permissioned. Rather than allowing anyone to be part of the network by either participating in the Proof-of-Work consensus or receiving transferrable forms of data such as tokens over the blockchain, the members of a Hyperledger Fabric network enroll through a membership services provider. 6 | 7 | Fabric also offers the ability to create channels, allowing a group of participants to create a separate ledger of transactions. This is an especially important option for networks where some participants might be competitors and not want every transaction they make, such as a special price they’re offering to some participants and not others, known to every participant in the network. If a group of participants form a channel, then only those participants, and no others, have copies of the ledger for that channel. 8 | 9 | -------------------------------------------------------------------------------- /CurrentProjects/indy.tex: -------------------------------------------------------------------------------- 1 | Hyperledger Indy (\url{https://github.com/hyperledger/indy-node} and further repositories named like \url{indy-*}) uses distributed ledger technology to make identity independent of organizational silos; friends, competitors, and even antagonists can all rely on a shared source of truth that answers fundamental questions such as, “Who am I dealing with?” and “How can I verify data about the other party in this interaction?” Solid answers to these questions enable the sort of trusted interactions demanded everywhere. 2 | 3 | Because Indy stores identity artifacts (public keys, proofs of existence, cryptographic accumulators that enable revocation) on a ledger with distributed ownership, identities can be self-sovereign--nobody external to the identity owner can manipulate them or take them away. Identity in Indy is also privacy-preserving by default, meaning that an identity owner can operate without creating correlation risk or breadcrumbs. 4 | 5 | A core technology for Indy is verifiable claims. These attestations of an identity's attributes resemble credentials familiar to all of us: passports, driver’s licenses, birth certificates, and so forth. But they can be combined and transformed in powerful ways, using zero-knowledge proofs to enable selective disclosure of just those pieces of data that a particular context demands. 6 | 7 | This combination of self-sovereignty, privacy, and verifiable claims is synergistic. Bulk troves of sensitive data vanish or become useless. The economics of hacking transform. The competing demands of privacy-preserving and strongly identifying regulations are satisfied. Individuals and organizations are free to seek mutual benefit from rich interaction; the identity ecosystem gains the innovation and dynamism of a free market. 8 | 9 | Despite the advanced crypto under the hood, Indy’s API is simple and straightforward. It consists of about 50 C-callable functions, with idomatic wrappers for many mainstream programming languages. 10 | 11 | -------------------------------------------------------------------------------- /CurrentProjects/iroha.tex: -------------------------------------------------------------------------------- 1 | Hyperledger Iroha (\url{https://github.com/hyperledger/iroha}) joined Fabric and Sawtooth Lake to become the third distributed ledger platform under the Hyperledger umbrella in October, 2016. It was originally developed by Soramitsu in Japan and was proposed to Hyperledger by Soramitsu, Hitachi, NTT Data, and Colu. 2 | 3 | Hyperledger Iroha is designed to be simple and easy to incorporate into infrastructural projects requires distributed ledger technology. Hyperledger Iroha features a simple construction; modern, domain-driven C++ design, emphasis on mobile application development and a new, chain-based Byzantine Fault Tolerant consensus algorithm, called Sumeragi. 4 | 5 | Iroha takes a very different design philosophy from Fabric and Sawtooth Lake, in that it focuses on providing features that are helpful for creating applications for end-users. 6 | -------------------------------------------------------------------------------- /CurrentProjects/sawtooth.tex: -------------------------------------------------------------------------------- 1 | Hyperledger Sawtooth (\url{https://github.com/hyperledger/sawtooth-core} and further repositories named like \url{sawtooth-*}) is a modular platform for building, deploying, and running distributed ledgers. The Sawtooth design philosophy targets keeping distributed ledgers distributed and making smart contracts safe - particularly for enterprise use. 2 | 3 | In fitting with this enterprise focus, Sawtooth is also highly modular. This enables enterprises and consortia to make policy decisions that they are best equipped to make. 4 | 5 | At the time of this writing Sawtooth contains several technical innovations. Among these are: 6 | \begin{itemize} 7 | \item Unpluggable consensus - which goes beyond compile time pluggable consensus to allow a consortium to change consensus algorithms on a running blockchain simply by issuing a transaction. 8 | \item PoET consensus - a new consensus algorithm with the scale benefits of Proof of Work but without its power drawbacks. 9 | \item Transaction Families - a smart contract abstraction that allows users to write contract logic in the language of their choosing. 10 | \item Ethereum contract compatibility - Transaction families also allow the integration of other contract interpreters including Hyperledger Burrow's Ethereum Virtual Machine. Permissioning, un-pluggable, consensus and other Sawtooth features allow an enterprise Ethereum configuration. 11 | \item Parallel Transaction Execution - most blockchains require serial transaction execution in order to guarantee consistent ordering at each peer. Sawtooth includes an advanced parallel scheduler that splits blocks into parallel flows. Parallelism allows for faster block processing in order to partially address the performance drawback of blockchains compared to traditional databases. 12 | \item Private Transactions - Clusters of Sawtooth nodes can be easily deployed with separate permissioning. This provides privacy and confidentiality among participants of that distinct chain. No centralized service leaks transaction patterns or other confidential information, however an intermediary such as Hyperledger Quilt would be required to connect disjoint chains. In the future Sawtooth plans to provide additional privacy and confidentiality features on top of Trusted Execution Environments and/or zero knowledge primitives. 13 | \end{itemize} 14 | 15 | Originally, Sawtooth was designed to explore scalability, security, and privacy questions prompted by the original distributed ledgers. That mandated a certain modularity that was lacking at the time. Starting from scratch allowed to employ lessons from those pioneering systems and branch into usages that the original currency ledgers weren't intended to address. PoET, the new consensus hits scalability, while Transaction Families, its contract logic, narrow the attack surface for contracts while simultaneously broadening the functionality. Its designers also have a keen interest in trusted execution environments and what role that can play in private transactions. 16 | 17 | In branching into new business cases, it was felt important that the system preserve certain tenants of a distributed ledger. That is, in an enterprise deployment, the concept of a distributed ledger shouldn't collapse into a replicated database. Enterprise participants need autonomy and they have the right to run their own nodes. The set of participants will also be dynamic and the system – particularly consensus – must accommodate that volatility. It is not clear, for example, whether an O(n2) protocol with fixed membership like PBFT can support the scale or volatility of a distributed ledger at production levels. Further it seems inadvisable to sidestep the challenges of providing Byzantine Fault Tolerance and operate on only a Crash Fault Tolerant consensus. Finally, it is worth noting that, “public” and “private” define a spectrum of authorization policies – not a binary option for a distributed ledger. 18 | -------------------------------------------------------------------------------- /GGEdit/CurrentProjects/burrow.tex: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/hyperledger-archives/hyperledgerwp/e0165f4bbb55b00d1bc0a14d3882d7d37f653ebc/GGEdit/CurrentProjects/burrow.tex -------------------------------------------------------------------------------- /GGEdit/CurrentProjects/cello.tex: -------------------------------------------------------------------------------- 1 | \textbf{Hyperledger Cello} is a blockchain module toolkit that aims to bring the on-demand ``as-a-service" deployment model to the blockchain ecosystem. 2 | The goal is to help enterprises quickly and easily adopt blockchain technologies, by providing automated ways to create, manage, and terminate blockchains. 3 | 4 | Cello provides an efficient and automated multi-tenant chain service on top of various infrastructures, including bare metal, virtual machine, cloud platforms like Amazon Web Services (AWS), and container platforms like Docker Swarm and Kubernetes. 5 | All in all, this helps boost the efficiency of ``Blockchain as a Service (BaaS)." 6 | 7 | Cello also provides a real-time dashboard where users can: 8 | \begin{itemize} 9 | \item View the status of the blockchain system and see statistics such as blockchain events, chaincode performance, and system utilization 10 | \item Manage blockchains (create, configure, and delete) and chaincode (deploy and upload private chaincode) 11 | \end{itemize} 12 | 13 | Hyperledger Cello currently supports \textbf{Hyperledger Fabric 1.0} as the main blockchain implementation. 14 | The project plans to support \textbf{Sawtooth} and other types of blockchains. 15 | 16 | The architecture follows the micro-service style, with pluggable implementations for most components. 17 | The main programming languages used are Python and JavaScript. 18 | 19 | To find out more about Cello, see \url{https://github.com/hyperledger/cello} and further repositories named like \url{cello-*}. 20 | -------------------------------------------------------------------------------- /GGEdit/CurrentProjects/composer.tex: -------------------------------------------------------------------------------- 1 | \textbf{Hyperledger Composer} is an open development toolset to make it simple and fast to create smart contracts and blockchain applications to solve business problems. 2 | The main goal is to make it easier to integrate blockchain applications with existing business systems, and thus accelerate time-to-value. 3 | 4 | Composer can help develop use cases and deploy a blockchain solution in weeks, rather than months. 5 | 6 | With Composer, users can quickly model an existing business network, and integrate existing systems and data with blockchain applications. 7 | A network can contain assets---such as tangible or intangible goods, services, or property---and transactions related to them. 8 | As part of the model, users can define how transactions can interact wit assets. 9 | 10 | Business networks include the participants who interact with them. And each participant can be associated with a unique identity across several different business networks. 11 | 12 | Hyperledger Composer supports the existing \textbf{Hyperledger Fabric} blockchain infrastructure and runtime. 13 | Since Fabric supports pluggable consensus protocols, this ensures that transactions can be validated according to the policy of the appropriate network participants. 14 | 15 | To find out more about Hyperledger Composer, see \url{https://github.com/hyperledger/composer} and further repositories named like \url{composer-*}. -------------------------------------------------------------------------------- /GGEdit/CurrentProjects/current_projects.tex: -------------------------------------------------------------------------------- 1 | Hyperledger incubates and promotes a range of business blockchain technologies. These technologies include: \begin{itemize} 2 | \item Distributed ledger frameworks 3 | \item Smart contract engines 4 | \item Client libraries 5 | \item Graphical interfaces 6 | \item Utility libraries 7 | \item Sample applications 8 | \end{itemize} 9 | 10 | The Hyperledger umbrella strategy encourages the re-use of common building blocks, enables rapid innovation of components, and promotes interoperability between projects. 11 | 12 | Table X sums up all the current projects, in chronological order from the date they were accepted by Hyperledger. The rest of this section sums up each project briefly, and shows where to find more information. 13 | 14 | \includepdf{CurrentProjects/summary_of_hyperledger_projects_page1.pdf} 15 | 16 | \includepdf{CurrentProjects/summary_of_hyperledger_projects_page2.pdf} 17 | 18 | \subsection{Fabric} 19 | \input{CurrentProjects/fabric.tex} 20 | 21 | \subsection{Sawtooth} 22 | \input{CurrentProjects/sawtooth.tex} 23 | 24 | \subsection{Iroha} 25 | \input{CurrentProjects/iroha.tex} 26 | 27 | \subsection{Burrow} 28 | \input{CurrentProjects/burrow.tex} 29 | 30 | \subsection{Indy} 31 | \input{CurrentProjects/indy.tex} 32 | 33 | \subsection{Cello} 34 | \input{CurrentProjects/cello.tex} 35 | 36 | \subsection{Composer} 37 | \input{CurrentProjects/composer.tex} 38 | 39 | \subsection{Explorer} 40 | \input{CurrentProjects/explorer.tex} 41 | 42 | \subsection{Quilt: coming soon} 43 | \input{CurrentProjects/quilt.tex} 44 | 45 | \end{document} -------------------------------------------------------------------------------- /GGEdit/CurrentProjects/explorer.tex: -------------------------------------------------------------------------------- 1 | \textbf{Hyperledger Explorer} provides a dashboard for viewing information about blocks, node logs, statistics, smart contracts, transactions, and any other information stored in the blockchain. 2 | Users can query for specific blocks or transactions to view the complete details. 3 | 4 | Explorer can be integrated with any authentication or authorization platforms, either commercial or open source, to provide the functions appropriate to the user's privileges. 5 | 6 | The goals of the Explorer project include: 7 | \begin{itemize} 8 | \item To create a web application for a generic blockchain explorer that's easy to install and can be used with different blockchain platforms 9 | \item To use the latest tools and technologies to make Explorer easy to implement, maintain, and extend 10 | \item To support the standard package managers available on most popular platforms to ensure the Explorer is quick and easy to install 11 | \end{itemize} 12 | 13 | To find out more about Hyperledger Explorer, see \url{https://github.com/hyperledger/blockchain-explorer} and further repositories named like \url{explorer-*}. 14 | 15 | -------------------------------------------------------------------------------- /GGEdit/CurrentProjects/fabric.tex: -------------------------------------------------------------------------------- 1 | \textbf{Hyperledger Fabric} is a platform for building distributed ledger solutions, with a modular architecture that delivers high degrees of confidentiality, flexibility, resiliency, and scalability. 2 | This enables solutions developed with Fabric to be adapted for any industry. 3 | 4 | Fabric allows components, such as consensus and membership services, to be plug-and-play. 5 | It leverages container technology to host smart contracts called ``chaincode" that contain the business rules of the system. 6 | And it's designed to support various pluggable components, and to accommodate the complexity that exist across the entire economy. 7 | 8 | Starting from the premise that there are no ``one-size-fits-all'' solutions, Fabric is an extensible blockchain platform for running distributed applications. 9 | It supports various consensus protocols, so it can be tailored to different use cases and trust models. 10 | 11 | Fabric runs distributed applications written in general-purpose programming languages (such as C, C++, Go, Java, Perl, PHP, Ruby, and so on?? are these examples accurate??) without depending on any native cryptocurrency. 12 | 13 | This stands in sharp contrast to most other blockchain platforms for running smart contracts, which either require code to be written in a domain-specific language or else rely on a cryptocurrency. 14 | 15 | Furthermore, Fabric uses a portable notion of membership for the permissioned model, which can be integrated with industry-standard identity management. 16 | To support such flexibility, Fabric takes a novel architectural approach and revamps the way blockchains cope with non-determinism, resource exhaustion, and performance attacks. 17 | 18 | %Where Hyperledger Fabric breaks from some other blockchain systems is that it is private and permissioned. Rather than allowing anyone to be part of the network by either participating in the Proof-of-Work consensus or receiving transferrable forms of data such as tokens over the blockchain, the members of a Hyperledger Fabric network enroll through a membership services provider. 19 | 20 | Fabric also supports channels, which enable a group of participants to create a separate ledger of transactions. This is especially important for networks where some participants might be competitors who don't want every transaction---such as a special price offer only to selected participants---known to every participant in the network. 21 | If a group of participants form a channel, only those participants and no others have copies of the ledger for that channel. 22 | 23 | To find out more about Hyperledger Fabric, see \url{https://github.com/hyperledger/fabric} and further repositories named like \url{fabric-*}. 24 | 25 | -------------------------------------------------------------------------------- /GGEdit/CurrentProjects/indy.tex: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/hyperledger-archives/hyperledgerwp/e0165f4bbb55b00d1bc0a14d3882d7d37f653ebc/GGEdit/CurrentProjects/indy.tex -------------------------------------------------------------------------------- /GGEdit/CurrentProjects/iroha.tex: -------------------------------------------------------------------------------- 1 | \textbf{Hyperledger Iroha} is a blockchain framework designed to be simple and easy to incorporate into infrastructure projects that require distributed ledger technology. 2 | 3 | Iroha joined Fabric and Sawtooth Lake to become the third distributed ledger platform under the Hyperledger umbrella in October, 2016. It was originally developed by Soramitsu in Japan and was proposed to Hyperledger by Soramitsu, Hitachi, NTT Data, and Colu. 4 | 5 | Hyperledger Iroha features: 6 | \begin{itemize} 7 | \item A simple structure 8 | \item Modern, domain-driven C++ design 9 | \item Emphasis on mobile application development 10 | \item A new, chain-based Byzantine Fault Tolerant consensus algorithm, called Sumeragi 11 | \end{itemize} 12 | 13 | Iroha takes a different approach from Fabric and Sawtooth (Lake---?? GG) by providing features that are helpful for creating applications for end users. 14 | 15 | To find out more about Hyperledger Iroha, see \url{https://github.com/hyperledger/iroha} and further repositories named like \url{iroha-*}. 16 | -------------------------------------------------------------------------------- /GGEdit/CurrentProjects/quilt.tex: -------------------------------------------------------------------------------- 1 | \textbf{Hyperledger Quilt} offers interoperability between ledger systems by implementing Interledger Protocol (ILP), a payments protocol designed to transfer value across both distributed and non-distributed ledgers. 2 | 3 | At publication date, Hyperledger Quilt was coming soon. 4 | 5 | \subsubsection{About the ILP} 6 | Payment networks today are siloed and disconnected. 7 | Payments are relatively easy within one country, or if both the sender and recipient have accounts on the same network or ledger. 8 | But sending from one ledger to another is often impossible. 9 | Where connections do exist, they are manual, slow, or expensive. 10 | 11 | The Interledger Protocol provides for routing payments across different digital asset ledgers, while isolating senders and receivers from the risk of intermediary failures. 12 | Secure multi-hop payments and automatic routing enable a global network of networks for different types of value that can connect any sender with any receiver. 13 | 14 | \subsubsection{For more information} 15 | To find out more about ILP, visit \url{https://interledger.org/rfcs/0003-interledger-protocol/}. 16 | 17 | To see more about Hyperledger Quilt, visit the Projects webpage at \url{https://www.hyperledger.org/projects#}. 18 | 19 | %\Or see \url{https://github.com/hyperledger/quilt} and further repositories named like \url{quilt-*}. 20 | 21 | 22 | 23 | 24 | 25 | 26 | -------------------------------------------------------------------------------- /GGEdit/CurrentProjects/sawtooth.tex: -------------------------------------------------------------------------------- 1 | \textbf{Hyperledger Sawtooth} is a modular platform for building, deploying, and running distributed ledgers. 2 | Distributed ledgers provide a digital record (such as asset ownership) that is maintained without a central authority or implementation. 3 | Sawtooth aims to keep distributed ledgers distributed, and to make smart contracts safe for enterprise use. 4 | In fitting with this focus, Sawtooth is highly modular. 5 | This enables enterprises and consortiums to make decisions about their blockchain applications for themselves. 6 | 7 | \subsubsection{Technical innovations in Sawtooth} 8 | Sawtooth contains several technical innovations, including: 9 | \begin{itemize} 10 | \item \textbf{Unpluggable consensus}---Going beyond compile-time pluggable consensus, this allows a consortium to change consensus algorithms on a running blockchain simply by issuing a transaction. 11 | \item \textbf{Proof of Elapsed Time (PoET)}---A consensus algorithm with the scalability of Proof of Work but without the drawback of high power consumption. 12 | \item \textbf{Transaction families}---A smart contract abstraction that allows users to write smart contract logic in the language of their choosing. 13 | \item \textbf{Compatability with Ethereum contracts}---Transaction families can also integrate other smart contract interpreters including Hyperledger Burrow's Ethereum Virtual Machine. 14 | Sawtooth features like permissioning and un-pluggable consensus enable Ethereum to be configured appropriately for an enterprise. 15 | \item \textbf{Parallel transaction execution}---Most blockchains require transactions to be executed in series to guarantee consistent ordering at each peer. 16 | Sawtooth includes an advanced parallel scheduler that splits blocks into parallel flows. 17 | Parallelism allows for faster block processing to partially address the performance drawback of blockchains compared to traditional databases. 18 | \item \textbf{Private transactions}---Clusters of Sawtooth nodes can be easily deployed with separate permissioning. 19 | This provides privacy and confidentiality among participants of that distinct chain. 20 | No centralized service leak transaction patterns or other confidential information. 21 | However, an intermediary such as \textbf{Hyperledger Quilt} is required to connect separate chains. 22 | In the future, Sawtooth plans to provide additional privacy and confidentiality features on top of trusted execution environments and/or zero knowledge primitives. 23 | \end{itemize} 24 | 25 | \subsubsection{Sawtooth extends the earlier distributed ledgers} 26 | Originally, Sawtooth was designed to explore scalability, security, and privacy questions prompted by the earliest distributed ledgers. 27 | That required a modularity that was lacking at the time. 28 | Starting from scratch enabled the project to draw lessons from those pioneering systems, and then extend into further use cases that the original currency ledgers weren't intended to address. 29 | 30 | The consensus model PoET boosts scalability. 31 | Transaction families broaden the scope of smart contracts, while narrowing the potential attack surface. 32 | The Sawtooth designers are also exploring trusted execution environments and the role those can play in private transactions. 33 | 34 | Even when branching into new business cases, certain key features of a distributed ledger must be preserved. 35 | In an enterprise deployment, the distributed ledger must not devolve into nothing more than a replicated database. 36 | Enterprise participants need autonomy and have the right to run their own nodes. 37 | 38 | Since the set of participants will be dynamic, the system---particularly the consensus model---must accommodate that volatility. 39 | 40 | \subsubsection{Over-complex and under-explained technical details} 41 | It is not clear, for example, whether an O(n2) protocol (should we say this, when many readers won't have a clue what this means?---GG) with fixed membership like Practical Byzantine Fault Tolerance (PBFT) can support the scale or volatility of a distributed ledger at production levels. 42 | It seems unwise to sidestep the challenges of providing Byzantine Fault Tolerance to operate with only a Crash Fault Tolerant consensus. 43 | Finally, both public and private distributed ledgers define a spectrum of authorization policies---not a binary either/or option. 44 | 45 | To find out more about Hyperledger Sawtooth, see \url{https://github.com/hyperledger/sawtooth-core} and further repositories named like \url{sawtooth-*}. 46 | 47 | -------------------------------------------------------------------------------- /GGEdit/CurrentProjects/summary_of_hyperledger_projects_page1.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/hyperledger-archives/hyperledgerwp/e0165f4bbb55b00d1bc0a14d3882d7d37f653ebc/GGEdit/CurrentProjects/summary_of_hyperledger_projects_page1.pdf -------------------------------------------------------------------------------- /GGEdit/CurrentProjects/summary_of_hyperledger_projects_page2.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/hyperledger-archives/hyperledgerwp/e0165f4bbb55b00d1bc0a14d3882d7d37f653ebc/GGEdit/CurrentProjects/summary_of_hyperledger_projects_page2.pdf -------------------------------------------------------------------------------- /GGEdit/RelevantUseCases/applying_for_a_loan.tex: -------------------------------------------------------------------------------- 1 | Banks want to lend, but only to borrowers who are good risks. 2 | This motivates the banks to gather detailed, personally identifiable information (PII) from everyone who applies for a loan, such as date of birth, annual income, government ID or passport number, and so on. 3 | 4 | Ultimately, the banks use this PII to access an applicant's credit rating. 5 | Regulations may demand that certain PII is shared with authorities, for example, to prevent money laundering. 6 | But retaining so much PII makes every bank a juicy target for hackers. 7 | 8 | Seeking a loan isn't much fun for borrowers, either. 9 | The application process is intrusive, and it's hard to ``shop around" for the best rates. 10 | Every new application multiplies the effort, and increases the risk that the applicant's PII will be abused. 11 | 12 | \subsubsection{Hyperledger Indy can streamline this process} 13 | \textbf{Hyperledger Indy} offers a transformative identity solution for this use case. 14 | 15 | With Indy, applicants can share only the information the banks need to make a decision, in a way that guarantees truth, builds confidence in the lender, and satisfies pressures from regulators. 16 | 17 | Anyone seeking a loan can apply to 100 different lenders in milliseconds, without placing any sensitive personal data into a hackable database. 18 | 19 | Instead of disclosing any PII, loan applicants can generate zero-knowledge proofs that they are over 21, that their income on last year's taxes passed a certain threshold, that they hold a valid government ID number, and that their credit score met a certain threshold within the past week. 20 | 21 | Strong, distributed ledger-based identity establishes a global source of truth, which delivers value to many parties. 22 | Applicants can give consent, and everyone can agree on when and how it was given. 23 | Lenders can conform with regulations and show an immutable audit trail. 24 | 25 | As a result, the market can operate more efficiently: Banks can offer loans with confidence, while applicants can effectively safeguard their PII. 26 | 27 | \subsubsection{Other Hyperledger projects add further strengths} 28 | This use case becomes even more compelling when you consider the added strengths of other Hyperledger projects. 29 | 30 | For example, \textbf{Hyperledger Burrow} can turn loan applications into smart contracts, and attach them to strong identities as a seamless next step. 31 | And \textbf{Hyperledger Fabric} can drive a membership system by linking to the pre-existing, self-sovereign identity on the loan application. 32 | -------------------------------------------------------------------------------- /GGEdit/RelevantUseCases/credentialing_doctors.tex: -------------------------------------------------------------------------------- 1 | Blockchain technologies promise to reduce one of the great annoyances of modern medical practice: ``credentialing''. Hospitals use the credentialing process to make sure that its physicians are competent and trustworthy. In a sense, credentialing is the hospital's way of performing ``due diligence'' on a physician. 2 | 3 | But today this process imposes a huge burden, both on the physician applying for affiliation and the hospital that must vet the applications. 4 | 5 | \subsubsection{The physician gathers credentials, many on paper} 6 | Any physician who wishes to become affiliated with a hospital begins the process by gathering 7 | copies of all their professional credentials, such as: 8 | 9 | \begin{itemize} 10 | \item Medical school diploma 11 | \item Certificates of any residencies and fellowships completed 12 | \item Certificates from any specialty medical boards 13 | \item All state medical licenses 14 | \item Evaluations from peers 15 | \item Proof of meeting requirements for continuing medical education 16 | \item Letters from hospitals where the physician was previously affiliated, explaining how and why the affiliation ended 17 | \item Details of any malpractice suits 18 | \end{itemize} 19 | 20 | Many of these documents were originally provided on paper, so the physician may need to scan in paper copies, and manage a set of scanned images or PDFs. 21 | 22 | \subsubsection{The hospital checks credentials and calls a meeting} 23 | On the hospital's side, the Credentialing Office checks the physician's documentation for completeness, accuracy, and authenticity. 24 | This is an exacting task. 25 | Almost inevitably, they find shortfalls and go back to the doctor for missing documents. 26 | 27 | Then the Credentialing Office verifies some or all of the physician's documentation. 28 | For example, they may phone a medical school to confirm that the physician did indeed graduate from there. 29 | This is clearly a time-intensive process. 30 | 31 | Once the documentation is determined to be complete, accurate, and authentic, the hospital's 32 | Credentialing Committee---which typically includes physicians and administrators---meets to decide whether the physician can begin practicing in affiliation with the hospital. 33 | 34 | The entire credentialing process is paper-bound, time-consuming, and low-trust. And it can take weeks or even months until any physician is cleared to affiliate with a hospital. 35 | 36 | \subsubsection{Three key questions for any blockchain solution} 37 | An effective blockchain solution for medical credentialing must answer three key questions about content, identities, and resources. 38 | 39 | 1. Will actual content or only pointers to content be placed on the blockchain? 40 | Credentialing solutions might place public information (such as state medical licensing) on the blockchain itself. 41 | However, private information (such as peer reviews) might be better stored off the chain; this would guard against any loss of keys, and enable users to remove---but not change---private information. 42 | 43 | 2. What's the best way to manage the identities of many participants? 44 | An ambitious credentialing solution might include every hospital, every physician, every source of continuing medical education, and so on. 45 | This could eventually number thousands of participants. 46 | How will so many identities be efficiently and securely managed? 47 | 48 | 3. What resources are required, especially for storage? 49 | Credentialing solutions may be in service for decades, requiring significant resources for processing, communication, and storage. 50 | For example, what if at some point credentialing organizations want video testimony from peers? Storage requirements could skyrocket---and who would cover that added cost? 51 | 52 | \subsubsection{Hyperledger can help streamline credentialing} 53 | Credentialing provides a good use case for blockchain technologies, which can simplify and streamline every step of the process. 54 | 55 | \textbf{Hyperledger Indy} provides off-the-shelf solutions that would otherwise require architecting and developing new software. 56 | One significant feature: Indy implements the proposed W3C standard for verifiable claims, supporting the pairwise exchange of selected credentials. In practice, this can work as follows: 57 | \begin{enumerate} 58 | \item A physician requests proof of graduation from their medical school. 59 | \item The physician places a digital credential on the blockchain, where it's considered irrefutable and tamper-proof. 60 | \item A hospital can access the blockchain to verify the physician's credential, with no need to contact the medical school directly. 61 | \item The physician can expose only the specific credentials the hospital requires, and nothing more. 62 | \end{enumerate} 63 | 64 | This implementation of verifiable claims safeguards the physician's privacy, saves time and effort for everyone involved, and streamlines the entire process. At last: a better way to handle medical credentialing. 65 | -------------------------------------------------------------------------------- /GGEdit/RelevantUseCases/graphic_seafood_supply_chain.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/hyperledger-archives/hyperledgerwp/e0165f4bbb55b00d1bc0a14d3882d7d37f653ebc/GGEdit/RelevantUseCases/graphic_seafood_supply_chain.png -------------------------------------------------------------------------------- /GGEdit/RelevantUseCases/managing_identities.tex: -------------------------------------------------------------------------------- 1 | One of the most exciting applications of blockchain is for self-sovereign identity: the idea that an individual owns their own ``identity'' and controls the data around it. 2 | This has profound implications for enterprise IT. 3 | 4 | \subsubsection{Indy extends traditional identity systems} 5 | \textbf{Hyperledger Indy} is a distributed ledger with a primary focus on self-sovereign identity. 6 | Indy shares some features with traditional enterprise identity systems such as 2FA, IDPs, LDAP, OAuth, and so on, namely: 7 | \begin{itemize} 8 | \item Industrial-strength cryptography 9 | \item Rich metadata about identities 10 | \item Sophisticated access control and policy 11 | \end{itemize} 12 | 13 | But there is a profound difference: Indy identities are shared, not siloed and federated. 14 | An Indy identity is portable, so you can bring it with you wherever the distributed ledger is accepted. 15 | 16 | This means that 10 systems that support Indy identities don't create 10 separate identities for John Q. Public. 17 | Instead, all 10 systems access John's pre-existing identity on the blockchain. 18 | John can simply show up and use his identity. 19 | An organization can cancel John's access, but never his identity, because John owns it himself. 20 | And John---not the places that accept John's identity---controls access to his data. 21 | 22 | \subsubsection{Indy fits enterprise IT better} 23 | Indy also shares some features with blockchain-based identity solutions such as Blockstack (\url{https://blockstack.org/}) and Uport (\url{https://www.uport.me/}). 24 | All these technologies store identity on a distributed ledger to promote security and personal freedom. 25 | 26 | However, Blockstack depends on Bitcoin and and Uport on Ethereum. These proof-of-work (PoW) ecosystems impose a non-trivial cost on transactions, so that every new persona, public key rotation, published attribute, or pairwise relationship becomes a tangible expense. This creates a disincentive to pairwise relationships, which undermines privacy. 27 | 28 | Also, these ecosystems are global and public. They can't be special-purposed for a less-than-fully-global context. 29 | 30 | Indy, on the other hand, does not use PoW, so that transactions are free. 31 | And different instances of Indy can scale to fit whatever context is convenient. 32 | That makes Indy more flexible, more cost-effective, and more practical for managing identities through an enterprise blockchain. 33 | -------------------------------------------------------------------------------- /GGEdit/RelevantUseCases/post_trade_processing.tex: -------------------------------------------------------------------------------- 1 | The primary drivers for blockchain in today's financial services are privacy, confidentiality, and accountability. 2 | 3 | Compliance guidelines like ``Anti-Money Laundering” and ``Know Your Customer” require that a bank or service provider can vouch for a customer. These requirements drive the adoption of permissioned and private blockchains, since public blockchains can risk compromising a participant's privacy and confidentiality. 4 | 5 | Together with a large volume of transactions, these considerations are helping consortium blockchains gain momentum in financial services. Among many possible use cases in this industry---especially in capital markets---post-trade processing can benefit from blockchain. 6 | 7 | \subsubsection{The many steps in post-trade processing} 8 | Post-trade processing includes all the activities after the completion of a trade. 9 | This covers transactions done over-the-counter (OTC), through a brokerage, or at an exchange. 10 | 11 | On a high level, post-trade processing includes these steps: 12 | \begin{enumerate} 13 | \item \textbf{Trade validation}---Confirming and validating the transaction. 14 | \item \textbf{Clearing}---Matching the trade instructions and confirmations across the counterparties and handling any netting activities. Note that the risk period between concluding and settling a trade, typically two or three days, can be reduced by using bilateral margining or a clearing house. 15 | \item \textbf{Settlement}---Realizing all contractual obligations to finalize the transaction legally. This includes support processes such as notifying all entities affected by the transaction. 16 | \item \textbf{Custody}---Adjusting and safekeeping securities by custodians on behalf of the counterparties. 17 | \item \textbf{Reporting}---Reporting the trade to satisfy any internal risk analysis or regulations. 18 | \end{enumerate} 19 | 20 | \subsubsection{Today's post-trade processing is inefficient} 21 | Today, all these steps are typically done through a fragmented workflow that spans numerous departments across different entities: brokers, central security depositories, clearing houses, exchanges, settlement agents, and so on. 22 | Every trade involves many different interfaces, processes, and reconciliation efforts. 23 | 24 | For example, today both parties send separate settlement instructions to a trusted third party---the settlement agent---which matches both data sets and instructions. Any mismatches trigger prolonged reconciliation efforts or even a failed trade. 25 | 26 | All this duplication of effort introduces inefficiency and delays into post-trade processing. 27 | 28 | \subsubsection{Blockchain can streamline post-trade processing} 29 | Compared to the current model, doing post-trade processing on blockchain can be far more efficient. 30 | 31 | This can exploit the peer-to-peer strength of a blockchain, so that one party can insert transaction details for the other party to verify. 32 | Doing both processes on the same system can significantly streamline the process. The network itself can act as a trusted third party, due to the immutable and irrefutable nature of transactions on the blockchain. 33 | 34 | The complexity can be further reduced, since all data from all steps and all actors can reside on the blockchain, accessible on a need-to-know basis. 35 | Any further reconciliation becomes unnecessary. And the blockchain system can also serve as an efficient basis for regulatory and trade reporting. 36 | 37 | This means four of the five steps listed above---validation, clearing, settlement, and reporting---can be streamlined by using a blockchain for post-trade processing.\footnote{The usefulness of blockchain for post-trade settlement may be limited, since near real-time settlement may eliminate the netting (or position offsetting) benefits of end-of-day processing.} 38 | 39 | \subsubsection{Special features required for post-trade processing} 40 | Any permissioned distributed ledger can provide a tamper-proof, irrefutable transaction log. But to be effective for post-trade processing, a blockchain requires several added features, such as immediate finality, rock-solid confidentiality, and streamlined performance. 41 | 42 | \textbf{Immediate finality}: Any distributed ledger used for capital markets must offer immediate finality, so that the receiver can be assured that the funds are good. 43 | Consensus algorithms such as proof of work (PoW), proof of stake (PoS), or proof of elapsed time (PoET) can cause temporary forks and even transaction rollbacks. 44 | These are unacceptable in post-trade processing. 45 | Any blockchain for this use case must deploy a consensus algorithm that provides immediate finality. 46 | 47 | \textbf{Rock-solid confidentiality}: Participants in any trade expect their transactions to remain private and confidential. 48 | The clearing house recording the transaction must ensure that parties can't see each other's position or trading information. 49 | Even with anonymized data, the existence of trades must not be revealed, since this can make transactions susceptible to traffic analysis. 50 | Correlated to public market information, this can compromise both a participant's identity and their trading patterns. 51 | 52 | \textbf{Streamlined performance}: Today, all post-trade activities happen at the end of the business day, which presents different requirements than most other use cases. 53 | When using a blockchain, it will not be necessary to transmit the entire day's set of trade records to be reconciled. 54 | All trades will be reconciled in near real-time. 55 | 56 | Yet the total number of transactions will likely increase, since participants can learn their position with the clearing house in near real-time. 57 | This means while the average number of transactions per second will likely increase, the peak performance requirements will decrease significantly. 58 | Overall, system performance will be faster. 59 | 60 | \subsubsection{Hyperledger projects can help} 61 | Several projects from Hyperledger provide features and functions that can help build effective blockchain solutions for post-trade processing. 62 | 63 | The channels supported by \textbf{Hyperledger Fabric} can be deployed as fully disjoint networks with separate endorser sets and ordering nodes to provide privacy and confidentiality. 64 | Restricting data replication only to permissioned parties delivers the benefits of the blockchain for data integrity and non-repudiation of transactions, without compromising data security. 65 | Reporting requirements---both internal and external---can be satisfied by including a regulatory agency and other oversight entities as members of the channel. 66 | And the network segmentation enabled by Fabric's channels can support multiple jurisdictions and regulatory regimes. 67 | 68 | The transaction families in \textbf{Hyperledger Sawtooth} provide a reliable and powerful way to support post-trade activities. 69 | Building complex rules using a preferred language, and exposing only the functions appropriate to the context, enables safer smart contracts. 70 | And the option to prohibit deployment of ad-hoc smart contracts further reduces risks for financial institutions. 71 | 72 | \textbf{Hyperledger Indy's} unlinkable verifiable claims can be leveraged to report outstanding risk on a shared ledger without compromising privacy. This still enables a regulatory body to take a holistic view of the market, and to help prevent potential market crashes and major defaults. This feature can also strengthen privacy, by putting participants in control of their network identities and any attributes they choose to disclose. 73 | 74 | -------------------------------------------------------------------------------- /GGEdit/RelevantUseCases/relevant_use_cases.tex: -------------------------------------------------------------------------------- 1 | This section describes five concrete examples where blockchain has a clear and compelling use case. 2 | These use cases are drawn from different domains and arranged in alphabetical order: 3 | \begin{itemize} 4 | \item Banking---applying for a loan 5 | \item Financial services---post-trade processing 6 | \item Healthcare---credentialing physicians 7 | \item IT---managing portable identities 8 | \item Supply chain management---tracking fish from ocean to table 9 | \end{itemize} 10 | 11 | In each case, Hyperledger has useful tools available; in some cases, a proof-of-concept has already been developed. 12 | 13 | \section{Banking: Applying for a Loan} 14 | %\label{sec:BankingApplyingforaLoan} 15 | \input{applying_for_a_loan.tex} 16 | \newpage 17 | 18 | \section{Financial Service: Post-Trade Processing} 19 | %\label{sec:FinancialServicesPost-TradeProcessing} 20 | \input{post_trade_processing.tex} 21 | \newpage 22 | 23 | \section{Healthcare: Credentialing physicians} 24 | %\label{sec:HealthcareCredentialingPhysicians} 25 | \input{credentialing_doctors.tex} 26 | \newpage 27 | 28 | \section{IT: Managing Portable Identities} 29 | %\label{sec:ITManagingPortableIdentities} 30 | \input{managing_identities.tex} 31 | \newpage 32 | 33 | \section{Supply Chain Management: Tracking Fish from Ocean to Table} 34 | %\label{sec:SupplyChainManagementTrackingFishfromOceantoTable} 35 | \input{tracking_fish_from_ocean_to_table.tex} 36 | -------------------------------------------------------------------------------- /GGEdit/RelevantUseCases/tracking_fish_from_ocean_to_table.tex: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/hyperledger-archives/hyperledgerwp/e0165f4bbb55b00d1bc0a14d3882d7d37f653ebc/GGEdit/RelevantUseCases/tracking_fish_from_ocean_to_table.tex -------------------------------------------------------------------------------- /GGEdit/conclusions.tex: -------------------------------------------------------------------------------- 1 | In this paper, we explained the rationale behind the creation of Hyperledger and our goals for the project. 2 | We outlined why we think an open source umbrella organization seems to be the optimal governing arrangement for a general blockchain consortium. 3 | We showcased some of the many use cases that inspired our members to join and work on Hyperledger. 4 | We described some of the features required to build effective blockchains for some of these use cases. 5 | And we briefly summed up all the Hyperledger projects and where they stand at publication date. 6 | 7 | We hope reading this paper is just the beginning of the Hyperledger experience for you. 8 | 9 | We know there's a lot of work left to be done. 10 | We realize that Hyperledger will probably always be a work-in-progress. 11 | But---perhaps with your help--we can all work together to build secure, efficient, and reliable blockchain solutions that make a difference to everyone's future. 12 | 13 | \subsection{Introductory Sources on Blockchain} 14 | ~\newline 15 | \emph{Blockchain Technology Overview}. National Institute of Standards and Technology, U.S. Department of Commerce. January 2018. One of the best introductions to blockchain we have seen, written in plain English while maintaining nuances. Includes glossary of terms and acronyms. 16 | ~\newline 17 | ~\newline 18 | \emph{Blockchain Basics: Glossary and use cases}. IBM developer-Works. Updated August 21, 2017. A solid explanation of blockchain terms aimed at developers new to the space. 19 | ~\newline 20 | ~\newline 21 | \emph{Blockchain Basics: A Non-Technical Introduction in 25 Steps}. Daniel Drescher. Apress. March 2017. Explains blockchain concepts with analogies, metaphors, and pictures, not mathematical formulas or program code. (\emph{GG ordered but hasn't received it yet, supposed to be good explanations in plain English...}) 22 | ~\newline 23 | ~\newline 24 | \emph{Blockchain Revolution: How the Technology Behind Bitcoin Is Changing Money, Business, and the World}. Don Tapscott and Alan Tapscott. Portfolio--Penguin. May 2016. Less about the technology and more about the implications of blockchain for business. The authors also have basic videos available on YouTube. 25 | 26 | \subsection{Further Resources from Hyperledger} 27 | We encourage you to use the Hyperledger resources to find more information on any blockchain-related topics you find interesting. Here are some further resources to get you started. 28 | 29 | \emph{The Hyperledger Vision} is a slide deck that sums up some blockchain 101-type information and the founding vision for Hyperledger, available at \url{https://www.hyperledger.org/resources/publications}. 30 | 31 | \emph{The Hyperledger Wiki} contains a wealth of technical information, available at \url{https://wiki.hyperledger.org/start}. 32 | 33 | Each of the main projects under Hyperledger is working on a \emph{Getting Started} guide and has further information available at these links: 34 | \begin{itemize} 35 | \item Fabric---\url{https://www.hyperledger.org/projects/fabric} 36 | \item Sawtooth---\url{https://www.hyperledger.org/projects/sawtooth} 37 | \item Iroha---\url{https://www.hyperledger.org/projects/iroha} 38 | \item Burrow---\url{https://www.hyperledger.org/projects/hyperledger-burrow} 39 | \item Indy---\url{https://www.hyperledger.org/projects/hyperledger-indy} 40 | \item Cello---\url{https://www.hyperledger.org/projects/cello} 41 | \item Composer---\url{https://www.hyperledger.org/projects/composer} 42 | \item Explorer---\url{https://www.hyperledger.org/projects/explorer} 43 | \item Quilt---coming soon \url{} 44 | \end{itemize} 45 | 46 | The Hyperledger Working Groups have many great technical resources, and are open to anyone with an interest in their subjects. For example, the Architecture Working Group has substantial documentation on the fundamentals of permissioned blockchain. If you're looking to explore technical details, that group is a great resource. 47 | 48 | The application-specific working groups are also great places to learn. For instance, the Identity Working Group has spent a lot of time discussing and documenting how blockchain can enable identity solutions. 49 | -------------------------------------------------------------------------------- /GGEdit/design_philosophy.tex: -------------------------------------------------------------------------------- 1 | Distributed ledgers can have vastly different requirements for different use cases. 2 | For instance, when participants share high trust---such as between financial institutions---blockchains can add blocks to the chain using rapid consensus with short confirmation times. 3 | On the other hand, when there is minimal trust between participants, they must tolerate slower processing. 4 | 5 | Hyperledger embraces the full spectrum of use cases. 6 | We recognize that different enterprise scenarios have different requirements for confirmation times, decentralization, trust, and other issues. 7 | And each issue represents a potential ``optimization point" for the technology. 8 | 9 | To address this diversity, all Hyperledger projects follow the same design philosophy. All our projects must be: 10 | \begin{itemize} 11 | \item Modular 12 | \item Highly secure 13 | \item Interoperable 14 | \item Token-agnostic 15 | \item Complete with APIs 16 | \end{itemize} 17 | 18 | \subsection{Modular} 19 | Hyperledger is developing modular, extensible frameworks with common building blocks that can be reused. 20 | This modular approach enables developers to experiment with different types of components as they evolve, and to change individual components without affecting the rest of the system. 21 | And this helps developers to create components that can be combined to build distributed ledger solutions well-suited to different requirements. 22 | 23 | This modular approach means a diverse community of developers can work independently on different modules, and re-use common modules across multiple projects. 24 | 25 | The Hyperledger Architecture Working Group defines functional modules and interfaces for issues such as communication, consensus, cryptography, identity, ledger storage, smart contract, and policy.\footnote{insert link to relevant webpage or doc} 26 | 27 | \subsection{Highly secure} 28 | Security is a key consideration for distributed ledgers, since many use cases involve high-value transactions or sensitive data. 29 | With large codebases, many networked nodes, and valuable data flows, distributed ledgers have become prime targets for online attackers. 30 | Securing a blockchain is quite a difficult task: Distributed ledgers must provide a large set of features and functions, while resisting persistent adversaries. 31 | 32 | Security and robustness are the keys to enable enterprise-class blockchains to evolve, and provide the critical infrastructure for next-generation business networks. 33 | Hyperledger projects embrace security by design and follow the best practices specified by the Linux Foundation's Core Infrastructure Initiative\footnote{insert link to relevant webpage or doc}. 34 | And all Hyperledger algorithms, protocols, and cryptography are reviewed and audited by security experts. 35 | 36 | \subsection{Interoperable} 37 | In the future, many different blockchain networks will need to communicate and exchange data to form more complex and powerful networks. 38 | At Hyperledger, we believe that all smart contracts and applications must be portable across many different blockchain networks. 39 | This high degree of interoperability will help meet the promise of blockchain technologies. 40 | 41 | \subsection{Token-agnostic} 42 | Hyperledger projects are independent and agnostic of all alt-coins, crypto-currencies, and tokens. 43 | Hyperledger will never issue its own crypto-currency; this is decidedly not our purpose. 44 | And no Hyperledger project will require a native token to provide incentives to operate the network or to manage resources. 45 | The design philosophy includes an explicit focus on managing digital objects, which may represent currencies. 46 | This removes any need for crypto-currencies or native tokens. 47 | 48 | \subsection{Complete with APIs} 49 | All Hyperledger projects provide rich and easy-to-use APIs. 50 | A well-defined set of APIs and SDKs enable external clients and applications to interface quickly and easily with core DLT infrastructure. 51 | These APIs support the growth of a rich developer ecosystem, and help blockchain and distributed ledger technologies proliferate across a wide range of industries and use cases. 52 | -------------------------------------------------------------------------------- /GGEdit/front_matter.tex: -------------------------------------------------------------------------------- 1 | \subsection{About Hyperledger} 2 | Hyperledger is an open source collaborative effort, created to advance blockchain technology by addressing important features for a cross-industry open standard for distributed ledgers. 3 | It is a global collaboration that includes leaders in banking, finance, Internet of Things, manufacturing, supply chains, and technology. 4 | 5 | The Linux Foundation hosts Hyperledger as a Collaborative Project under the foundation. 6 | Hyperledger does not promote a single blockchain codebase or a single blockchain project. 7 | Rather, it enables a worldwide developer community to work together and share ideas, infrastructure, and code. 8 | 9 | \subsection{Purpose of this Paper} 10 | This paper provides a high-level overview of the Hyperledger project: Why it was created, how it is governed, and what it hopes to achieve. 11 | The core of this paper presents five compelling uses for enterprise blockchain in different industries. 12 | It also describes the open source frameworks that Hyperledger is developing to help enterprises around the world deliver on the promise of blockchain for more secure, more reliable, and more streamlined interactions. 13 | 14 | This is not intended as a deep technical white paper, but an introduction to Hyperledger for a general business reader. 15 | 16 | \subsection{Intended Audience} 17 | We expect this paper will be read by business people from different backgrounds, including entrepreneurs, executives, IT managers, and software developers. 18 | Since the blockchain is so new, we expect different readers will be more or less familiar with certain blockchain terms and concepts. 19 | And since Hyperledger is a worldwide project, we expect this paper will be read by people around the world, many of whom do not have English as their first language. 20 | 21 | Therefore, we tried to make this paper as clear and readable as possible. 22 | The Further Resources section at the end points to more introductory and more advanced materials you may want to explore. 23 | 24 | \subsection{Outline} 25 | This paper covers the following material: 26 | \begin{itemize} 27 | \item Section 1 introduces the growing need for distributed ledgers in enterprises of today and tomorrow. 28 | \item Section 2 shows why open source is a good fit for enterprise blockchain development. 29 | \item Section 3 describes the umbrella structure of the Hyperledger project and how that leads to good governance. 30 | \item Section 4 defines the key elements of the design philosophy that all Hyperledger projects must follow. 31 | \item Section 5 presents five compelling uses cases for blockchain from different industries: banking, financial services, healthcare, IT, and supply chains. For many readers, this will be the most intriguing part of this document. 32 | \item Section 6 outlines each of the current top-level projects in Hyperledger. 33 | \item Section 7 explains the long-term vision for the Hyperledger project. 34 | \item Section 8 offers some final thoughts. 35 | \end{itemize} 36 | 37 | \subsection{Acknowledgements} 38 | The Hyperledger White Paper Working Group would like to thank all the following people for contributing to this paper: 39 | 40 | Tamas Blummer, Sean Bohan, Mic Bowman, Christian Cachin, Nick Gaski, Nathan George, Gordon Graham, Daniel Hardman, Ram Jagadeesan, Travin Keith, Renat Khasanshyn, Murali Krishna, Tracy Kuhrt, Arnaud Le Hors, Stanislav Liberman, Esther Mendez, Dan Middleton, Hart Montgomery, Dan O'Prey, Drummond Reed, Stefan Teis, Dave Voell, Greg Wallace, Baohua Yang. 41 | 42 | We would also like to thank the Hyperledger Technical Steering and Marketing Committees for their valuable feedback throughout the writing of this paper. 43 | 44 | -------------------------------------------------------------------------------- /GGEdit/hyperledger_paper_GG.tex: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/hyperledger-archives/hyperledgerwp/e0165f4bbb55b00d1bc0a14d3882d7d37f653ebc/GGEdit/hyperledger_paper_GG.tex -------------------------------------------------------------------------------- /GGEdit/introduction.tex: -------------------------------------------------------------------------------- 1 | \textbf{Please note}: I'd like this document to start off with a clear introduction. 2 | But I'm very concerned that the current Introduction will turn off many business readers. 3 | If we lose them on the first page, we've lost them for good. 4 | I found this section hard to read, for these reasons: 5 | \begin{itemize} 6 | \item This is supposed to be ``the introduction to the introduction" to Hyperledger---but it's not clear why we start in talking about databases. 7 | \item It doesn't move from the familiar to the unfamiliar. 8 | \item It jumps right into a technical discussion, without defining any terms. 9 | \item This seems too complex for a business reader, but perhaps not deep enough for a technical reader. 10 | \end{itemize} 11 | 12 | I propose revising this section to spell out the following step-by-step logic. 13 | Please let me know what you think. 14 | Once we agree on a direction, I can write up a draft in a couple of days. 15 | And ideally, we can come up with some diagrams to make this more visual and inviting. 16 | Thank you.---GG\\ 17 | 18 | \textbf{Databases are everywhere} 19 | \begin{itemize} 20 | \item Familiar example: contacts on a cell phone, electronic version of paper address book 21 | \item Define database 22 | \item Very brief sketch of early history of databases (2 or 3 sentences) 23 | \item Q: Do we need to define hierarchical and relational databases and SQL? (I think not) 24 | \end{itemize} 25 | 26 | \textbf{Many databases today are shared} 27 | \begin{itemize} 28 | \item Familiar example: shared calendars, electronic version of paper calendar 29 | \item More elaborate shared databases are used in business 30 | \item Business example: list of inventory by SKU, shared by order desk at home office and by account rep with laptop in the field, both can take orders and allocate stock-on-hand to customers 31 | \end{itemize} 32 | 33 | \textbf{But shared databases raise questions} 34 | \begin{itemize} 35 | \item Who can do what, when and how? 36 | \item Who do you trust? 37 | \item Who settles any conflicts or disputes? 38 | \item What happens if both the home office and a field rep want to sell the same item? 39 | \item What happens if both an account rep and an e-commerce shopper want the same item? 40 | \item Familiar example for the double-spend problem 41 | \item Conclusion: we need clear rules to share a database effectively 42 | \item Touch on replicated and federated databases very briefly 43 | \item Any other definitions here? 44 | \end{itemize} 45 | 46 | \textbf{Blockchain is a new form of shared database} 47 | \begin{itemize} 48 | \item Define blockchain 49 | \item Very brief sketch of history of blockchain (2 or 3 sentences) 50 | \item Define consensus 51 | \item Define trust and trustless 52 | \item Define permissionless and permissioned 53 | \end{itemize} 54 | 55 | \textbf{There's more to blockchain than Bitcoin} 56 | \begin{itemize} 57 | \item The media is full of stories on Bitcoin and other crypto-currencies 58 | \item Most businesses don't care about crypto-currencies, and they never will 59 | \item The underlying technology---blockchain---is far more significant for enterprises 60 | \item Quote Don Tapscott: Blockchain = internet of value, not just information 61 | \item Of course, businesses are interested in value 62 | \end{itemize} 63 | 64 | \textbf{Blockchain solves the problems of shared databases} 65 | \begin{itemize} 66 | \item How blockchain solves trust 67 | \item How blockchain solves the double-spend problem 68 | \item With blockchain, many existing business processes can be streamlined 69 | \item And many new processed can be invented 70 | \end{itemize} 71 | 72 | \textbf{Hyperledger was created to further blockchain for enterprises} 73 | \begin{itemize} 74 | \item Very brief sketch of history of Hyperledger (2 to 3 sentences) 75 | \item Stirring conclusion and invitation to read on... 76 | \end{itemize} 77 | \newpage 78 | 79 | 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. 80 | 81 | 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. 82 | 83 | 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. 84 | 85 | 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. 86 | 87 | 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. 88 | 89 | The most popular existing blockchains like Bitcoin and Ethereum 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. 90 | 91 | 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. 92 | \newpage 93 | 94 | -------------------------------------------------------------------------------- /GGEdit/the_umbrella_organization.tex: -------------------------------------------------------------------------------- 1 | Hyperledger serves as an umbrella organization that brings together users, developers, and vendors from many different sectors and market spaces. 2 | All these participants have one thing in common: Everyone is interested in learning about, developing, and using enterprise blockchains. 3 | 4 | ~\newline 5 | \emph{Here's a great place for an org chart drawn somewhat like an umbrella.---GG} 6 | ~\newline 7 | 8 | While blockchain is a powerful technology, it is not one-size-fits-all. 9 | Every enterprise needs special features and modifications to help a blockchain achieve its intended purpose. 10 | Since different organizations have different needs, there will never be one single, standard blockchain. 11 | Instead, we expect to see many blockchains customized with different features that provide a wide range of solutions across many industries. 12 | 13 | Because enterprises need to understand, develop, and use many different blockchains, an umbrella organization like Hyperledger can help reduce the resources consumed by these efforts. 14 | 15 | As the umbrella organization for open source blockchain development, Hyperledger provides these benefits: 16 | \begin{itemize} 17 | \item Help keeping up with developments 18 | \item Better productivity through specialization 19 | \item Collaboration to avoid duplicate efforts 20 | \item Better quality control of code 21 | \item Easier handling of intellectual property 22 | \end{itemize} 23 | 24 | \subsection{Help keeping up with developments} 25 | Navigating through all the developments in an open source environment can be daunting. 26 | Due to the cost and complexity involved, some organizations may give up, or never get started at all. 27 | 28 | Hyperledger reduces this research burden by creating a collaborative environment that streamlines communication. 29 | Better communication helps new participants to catch up, by gaining faster access to necessary information. 30 | As newer participants quickly join the collaborative effort, this speeds up development, for the benefit of the entire community. 31 | 32 | \emph{Question: Sounds good, but how? Any concrete details we can offer?---GG} 33 | 34 | \subsection{Better productivity through specialization} 35 | A basic premise of economics ever since Adam Smith is that \emph{specialization}---also known as division of labor---leads to higher productivity. 36 | Instead of everyone doing a little bit of everything, specialization enables people to focus their energies on fewer tasks and become more expert at them. 37 | The benefits of specialization include more expertise, more value added, and ultimately more wealth created. 38 | This is why specialization has proven to be a driving factor in global economic development. 39 | 40 | Participants can gain the same benefits---more expertise, more value added, and better all-around productivity---by specializing in certain areas of a new technology like blockchain. 41 | In an open source environment that lacks any umbrella organization, this would be far more difficult. 42 | 43 | Hyperledger's umbrella structure encourages specialization, which yields better productivity. 44 | And participants who happen to specialize in similar areas aren't competing against each other. 45 | In an umbrella organization, specialists are encouraged to join forces to accelerate their research and development. 46 | 47 | \subsection{Collaboration to avoid duplicate efforts} 48 | In a siloed environment, many people can unwittingly duplicate each another's efforts. Duplication of effort is especially negative in a new industry like blockchain, where the talent pool of seasoned developers is not yet deep. 49 | 50 | In an umbrella organization, collaboration between participants is highly encouraged. 51 | This can avoid duplication, streamline the development of new projects, and encourage the creation of common components that benefit the entire community. 52 | 53 | Interoperability between various distributed ledgers is also enhanced by a better understanding of other projects. 54 | And the governing structure provided by Hyperledger can help solve any interoperability disputes that could potentially arise. 55 | 56 | \subsection{Better quality control of code} 57 | Open source software is recognized for its high quality, achieved through careful code reviews and significant debugging. 58 | Hyperledger promotes quality control by having a technical governing committee review all projects throughout their life cycles. 59 | This gives new projects a chance to be critiqued, so their developers can gain knowledge from all the existing projects. 60 | For their part, long-time project members may discover innovations in new projects which can enhance their own projects. 61 | This umbrella structure also fosters interoperability between new and existing projects. 62 | 63 | \subsection{Easier handling of intellectual property} 64 | Another benefit provided by the umbrella organization is easier, more consistent handling of intellectual property. 65 | Hyperledger operates under an Apache 2.0 license for code (see \url{https://www.apache.org/licenses/LICENSE-2.0}) and Creative Commons Attribution 4.0 International license for content (see \url{https://creativecommons.org/licenses/by/4.0/}). 66 | Both these licenses are known to be particularly enterprise-friendly. 67 | 68 | A single, consistent approach to intellectual property removes the need for complex and expensive contractual relationships among members. 69 | Since all participants have clearly communicated their expectations, anyone building and using Hyperledger technologies can participate without fear of running into hidden legal encumbrances. 70 | 71 | -------------------------------------------------------------------------------- /GGEdit/vision.tex: -------------------------------------------------------------------------------- 1 | We live in a highly interconnected world. 2 | In the future, the world will no doubt become even more closely tied together. 3 | In both our business and personal lives, more data, more digital content, more communication, and more sharing will be the norm. 4 | All this will require careful management of our security, privacy, and trust. 5 | 6 | \subsection{A common problem, and a sensible solution} 7 | We expect to see a common problem: Many people will want to share data in a distributed database, but no single owner will be trusted by every user. 8 | 9 | The solution is distributed ledger technology (DLT). 10 | As data sharing increases, we expect blockchain technology and DLT to become more and more common. 11 | 12 | But reaching widespread use of distributed ledgers will not be simple. 13 | For instance, gaining security and privacy with a blockchain often means sacrificing performance. 14 | This suggests that we'll need a variety of different blockchains that can all communicate and interact seamlessly. 15 | No one blockchain will work best for all applications. 16 | 17 | The long-term vision for Hyperledger is driven by two main concerns: that the architecture must be modular and interoperable. 18 | 19 | \subsection{Interchangeable modules} 20 | We hope that eventually Hyperledger consists of many modules that can be assembled into a cohesive, functional, and secure distributed ledger. 21 | All these modules must be interchangeable with other modules of the same type. 22 | All modules must be able to communicate with other modules of the same or different types. 23 | And ideally, even a non-expert will be able to use them to set up a secure, interoperable blockchain quickly, easily, and efficiently. 24 | 25 | \subsection{Many blockchains that work together} 26 | We want to specifically point out that we do not believe any Hyperledger blockchain should be the ``one distributed ledger to rule them all.'' 27 | The Hyperledger community sees merit in many different blockchains. 28 | We hope that other developers consider interoperability with Hyperledger projects. 29 | 30 | \subsection{Not a single stack, but a collection of tools} 31 | The goal for Hyperledger is not to become a single software stack. 32 | Instead, we want to create a collection of tools built with modularity and interoperability in mind. 33 | Then, any individual can use one, some, or all of the Hyperledger projects to create a distributed ledger to suit their needs. 34 | 35 | In the future, we hope that Hyperledger can solve most of the common problems in the distributed ledger space. 36 | This will require a good community of developers, strong support from business and industry, and solid design principles. 37 | As shown in this paper, we have structured Hyperledger with all these in mind. 38 | 39 | -------------------------------------------------------------------------------- /GGEdit/why_open_source.tex: -------------------------------------------------------------------------------- 1 | "Proprietary software" refers to a commercial product licensed by a vendor, normally for a fee. It's usually sold ``as is," giving buyers no way to add unique customizations or fix bugs. Proprietary software publishers carefully guard their ``source code"---the version that a programmer can read and edit---and distribute only the run-time version that's simply a long string of numbers. 2 | 3 | Open source is different. This is ``software that comes with permission to use, copy, and distribute, either as is or with modifications."\footnote{ Gartner. IT Glossary. Retrieved from \url{https://www.gartner.com/it-glossary/open-source}} Open source is usually free. Since the source code is provided, developers are free to inspect, tweak, and improve the code---and to submit enhancements back. 4 | 5 | \subsection{Open source is popular and reliable} 6 | When properly designed, coded, and deployed, open source is a proven and effective choice. 7 | 8 | For example, the Linux operating system runs 90 percent of the public cloud workload, has 62 percent of the embedded market share, and 99 percent of the supercomputer market share. \footnote{ 2017 State of Linux Kernel Development {https://www.linuxfoundation.org/2017-linux-kernel-report-landing-page/}} 9 | 10 | The open source \textbf{Apache web server} has been the world's most popular web server for more than 20 years, and today supports more than 40\% of all active websites. \footnote{ February 2018 Web Server Survey. Netcraft. Retrieved from \url{https://news.netcraft.com/archives/2018/02/13/february-2018-web-server-survey.html}} 11 | 12 | Other well-known open source software includes \textbf{mySQL}---the world's most popular database server--- and the \textbf{Firefox} browser. 13 | 14 | \subsection{Open source has some clear benefits} 15 | According to 2015 and 2016 annual surveys of executives and developers,\footnote{ The 10th Annual Future of Open Source Survey. North Bridge and Black Duck Software. 2016. Retrieved from \url{https://www.blackducksoftware.com/2016-future-of-open-source}} these are the key reasons why enterprises choose open source software: 16 | \begin{itemize} 17 | \item Competitive features and capabilities 18 | \item No vendor lock-in, so customers can easily switch 19 | \item High-quality solutions 20 | \item The ability to customize and fix bugs, through access to source code 21 | \item Lower total cost of ownership 22 | \end{itemize} 23 | 24 | Some years ago, the main attraction of open source was that it was ``free." 25 | Today, enterprises choose open source to reduce risk, gain speed-to-market, and get a competitive edge. 26 | Organizations want their programmers to focus on strategic projects that add significant value---such as adding industry-specific enhancements on top of a proven platform---rather than re-inventing the wheel. 27 | 28 | All these benefits are heightened when an enterprise confronts any profoundly new or challenging concept---like the web in years past---and like blockchain today. 29 | Rather than develop an entire infrastructure and engineer all of its own solutions, enterprises can ``stand on the shoulders" of others who already did pioneering work and freely shared it with the world. 30 | 31 | \subsection{Open source builds trust} 32 | Blockchain represents a perfect opportunity to benefit from open source, since the concept of trust is woven deeply into all blockchain technologies. 33 | 34 | Blockchain systems are engineered to enable direct, peer-to-peer transactions between parties who don't fully trust one another, or don't trust any central authority to validate transactions or mediate disputes. 35 | Therefore, it's essential for these parties to trust in blockchain technologies. 36 | 37 | We believe that an open, collaborative approach that invites participation from all stakeholders is the most effective way to build trust for enterprises---enough trust for them to widely and rapidly adopt blockchain technologies. 38 | 39 | \subsection{Open governance}: 40 | Open Governance means that technical decisions -– which features to add, how to add them and when, among others – are made by a group of community-elected developers drawn from a pool of active participants. Participation in Hyperledger through becoming a Contributor and/or Maintainer is open to anyone. 41 | 42 | As a developer or maintainer, this translates into one thing: trust. You know how decisions will be made and the process by which people will be selected to make these decisions. Hyperledger is vendor-neutral and technical contributions are based on meritocracy. 43 | 44 | Companies deploying blockchain internally, and those building products and services based on Hyperledger projects, tell us they trust Hyperledger because our technologies are built in the open by a broad community. 45 | 46 | \subsection{Open source promotes interoperability} 47 | ``Interoperable" means that a program can talk to programs from other organizations quickly and easily. In today's connected world, this is a must-have. 48 | And in the future, we believe that many different blockchains will support many business processes for many organizations. 49 | 50 | Hyperledger eases interaction across numerous blockchains. The open source Hyperledger technologies are designed from the start to support interoperability across various blockchains. 51 | 52 | Hyperledger Quilt is expressly focused on facilitating cross-chain transactions. 53 | 54 | \subsection{Open source makes sense for blockchain} 55 | Both economics and common sense are on the side of a collaborative effort like Hyperledger. 56 | 57 | Enterprises need robust, feature-rich, modular blockchain platforms they can tailor to meet their requirements. 58 | Businesses as diverse as banks, car and airplane makers, and healthcare companies make a broad ecosystem of enterprises, all cooperating with the global Hyperledger developer community. 59 | 60 | When many different users and vendors collaborate to co-create common technologies, everyone can enjoy the proven benefits including lower risk, higher quality, and faster time-to-market. 61 | We believe we can do more to advance blockchain technologies by working together than by working in isolation. 62 | -------------------------------------------------------------------------------- /HighlightedFeatures/highlighted_features.tex: -------------------------------------------------------------------------------- 1 | \subsection{Identity} 2 | \input{HighlightedFeatures/identity.tex} -------------------------------------------------------------------------------- /HighlightedFeatures/identity.tex: -------------------------------------------------------------------------------- 1 | Indy shares some features with traditional enterprise identity solutions--the world of LDAP, OAuth, 2FA, IDPs, and similar tech. Both approaches use industrial-strength crypto. Both enable capturing and sharing rich metadata about an identity. Both facilitate sophisticated access control and policy. But there is a profound difference: Indy identities are shared instead of siloed and federated. An Indy identity is portable--you can bring it with you wherever the distributed ledger is accepted. Ten orgs or systems that each support Indy identities don't create ten separate identities for John Q. Public; John simply shows up with his pre-existing identity and uses it. Organizations can cancel John's access, but never his identity, because John owns it. John, not the places that accept John's identity, controls access to his data. 2 | 3 | Indy also shares some features with blockchain-based identity solutions such as Blockstack and Uport. All of these technologies store identity on a distributed ledger and thus promote security and personal freedom. However, Blockstack and Uport depend on Bitcoin and Ethereum, respectively. These are proof-of-work ecosystems that impose a non-trivial cost on transactions; every new persona, public key rotation, published attribute, or pairwise relationship is a tangible expense. This creates a disincentive to pairwise relationships, which undermines privacy. Also, these ecosystems are global and public; they cannot be special-purposed for a less-than-fully-global context. Indy, on the other hand, does not use proof-of-work. Transactions are free. And different instances of Indy can be used in whatever context is convenient. 4 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | 2 | Apache License 3 | Version 2.0, January 2004 4 | http://www.apache.org/licenses/ 5 | 6 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 7 | 8 | 1. Definitions. 9 | 10 | "License" shall mean the terms and conditions for use, reproduction, 11 | and distribution as defined by Sections 1 through 9 of this document. 12 | 13 | "Licensor" shall mean the copyright owner or entity authorized by 14 | the copyright owner that is granting the License. 15 | 16 | "Legal Entity" shall mean the union of the acting entity and all 17 | other entities that control, are controlled by, or are under common 18 | control with that entity. For the purposes of this definition, 19 | "control" means (i) the power, direct or indirect, to cause the 20 | direction or management of such entity, whether by contract or 21 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 22 | outstanding shares, or (iii) beneficial ownership of such entity. 23 | 24 | "You" (or "Your") shall mean an individual or Legal Entity 25 | exercising permissions granted by this License. 26 | 27 | "Source" form shall mean the preferred form for making modifications, 28 | including but not limited to software source code, documentation 29 | source, and configuration files. 30 | 31 | "Object" form shall mean any form resulting from mechanical 32 | transformation or translation of a Source form, including but 33 | not limited to compiled object code, generated documentation, 34 | and conversions to other media types. 35 | 36 | "Work" shall mean the work of authorship, whether in Source or 37 | Object form, made available under the License, as indicated by a 38 | copyright notice that is included in or attached to the work 39 | (an example is provided in the Appendix below). 40 | 41 | "Derivative Works" shall mean any work, whether in Source or Object 42 | form, that is based on (or derived from) the Work and for which the 43 | editorial revisions, annotations, elaborations, or other modifications 44 | represent, as a whole, an original work of authorship. For the purposes 45 | of this License, Derivative Works shall not include works that remain 46 | separable from, or merely link (or bind by name) to the interfaces of, 47 | the Work and Derivative Works thereof. 48 | 49 | "Contribution" shall mean any work of authorship, including 50 | the original version of the Work and any modifications or additions 51 | to that Work or Derivative Works thereof, that is intentionally 52 | submitted to Licensor for inclusion in the Work by the copyright owner 53 | or by an individual or Legal Entity authorized to submit on behalf of 54 | the copyright owner. For the purposes of this definition, "submitted" 55 | means any form of electronic, verbal, or written communication sent 56 | to the Licensor or its representatives, including but not limited to 57 | communication on electronic mailing lists, source code control systems, 58 | and issue tracking systems that are managed by, or on behalf of, the 59 | Licensor for the purpose of discussing and improving the Work, but 60 | excluding communication that is conspicuously marked or otherwise 61 | designated in writing by the copyright owner as "Not a Contribution." 62 | 63 | "Contributor" shall mean Licensor and any individual or Legal Entity 64 | on behalf of whom a Contribution has been received by Licensor and 65 | subsequently incorporated within the Work. 66 | 67 | 2. Grant of Copyright License. Subject to the terms and conditions of 68 | this License, each Contributor hereby grants to You a perpetual, 69 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 70 | copyright license to reproduce, prepare Derivative Works of, 71 | publicly display, publicly perform, sublicense, and distribute the 72 | Work and such Derivative Works in Source or Object form. 73 | 74 | 3. Grant of Patent License. Subject to the terms and conditions of 75 | this License, each Contributor hereby grants to You a perpetual, 76 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 77 | (except as stated in this section) patent license to make, have made, 78 | use, offer to sell, sell, import, and otherwise transfer the Work, 79 | where such license applies only to those patent claims licensable 80 | by such Contributor that are necessarily infringed by their 81 | Contribution(s) alone or by combination of their Contribution(s) 82 | with the Work to which such Contribution(s) was submitted. If You 83 | institute patent litigation against any entity (including a 84 | cross-claim or counterclaim in a lawsuit) alleging that the Work 85 | or a Contribution incorporated within the Work constitutes direct 86 | or contributory patent infringement, then any patent licenses 87 | granted to You under this License for that Work shall terminate 88 | as of the date such litigation is filed. 89 | 90 | 4. Redistribution. You may reproduce and distribute copies of the 91 | Work or Derivative Works thereof in any medium, with or without 92 | modifications, and in Source or Object form, provided that You 93 | meet the following conditions: 94 | 95 | (a) You must give any other recipients of the Work or 96 | Derivative Works a copy of this License; and 97 | 98 | (b) You must cause any modified files to carry prominent notices 99 | stating that You changed the files; and 100 | 101 | (c) You must retain, in the Source form of any Derivative Works 102 | that You distribute, all copyright, patent, trademark, and 103 | attribution notices from the Source form of the Work, 104 | excluding those notices that do not pertain to any part of 105 | the Derivative Works; and 106 | 107 | (d) If the Work includes a "NOTICE" text file as part of its 108 | distribution, then any Derivative Works that You distribute must 109 | include a readable copy of the attribution notices contained 110 | within such NOTICE file, excluding those notices that do not 111 | pertain to any part of the Derivative Works, in at least one 112 | of the following places: within a NOTICE text file distributed 113 | as part of the Derivative Works; within the Source form or 114 | documentation, if provided along with the Derivative Works; or, 115 | within a display generated by the Derivative Works, if and 116 | wherever such third-party notices normally appear. The contents 117 | of the NOTICE file are for informational purposes only and 118 | do not modify the License. You may add Your own attribution 119 | notices within Derivative Works that You distribute, alongside 120 | or as an addendum to the NOTICE text from the Work, provided 121 | that such additional attribution notices cannot be construed 122 | as modifying the License. 123 | 124 | You may add Your own copyright statement to Your modifications and 125 | may provide additional or different license terms and conditions 126 | for use, reproduction, or distribution of Your modifications, or 127 | for any such Derivative Works as a whole, provided Your use, 128 | reproduction, and distribution of the Work otherwise complies with 129 | the conditions stated in this License. 130 | 131 | 5. Submission of Contributions. Unless You explicitly state otherwise, 132 | any Contribution intentionally submitted for inclusion in the Work 133 | by You to the Licensor shall be under the terms and conditions of 134 | this License, without any additional terms or conditions. 135 | Notwithstanding the above, nothing herein shall supersede or modify 136 | the terms of any separate license agreement you may have executed 137 | with Licensor regarding such Contributions. 138 | 139 | 6. Trademarks. This License does not grant permission to use the trade 140 | names, trademarks, service marks, or product names of the Licensor, 141 | except as required for reasonable and customary use in describing the 142 | origin of the Work and reproducing the content of the NOTICE file. 143 | 144 | 7. Disclaimer of Warranty. Unless required by applicable law or 145 | agreed to in writing, Licensor provides the Work (and each 146 | Contributor provides its Contributions) on an "AS IS" BASIS, 147 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 148 | implied, including, without limitation, any warranties or conditions 149 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 150 | PARTICULAR PURPOSE. You are solely responsible for determining the 151 | appropriateness of using or redistributing the Work and assume any 152 | risks associated with Your exercise of permissions under this License. 153 | 154 | 8. Limitation of Liability. In no event and under no legal theory, 155 | whether in tort (including negligence), contract, or otherwise, 156 | unless required by applicable law (such as deliberate and grossly 157 | negligent acts) or agreed to in writing, shall any Contributor be 158 | liable to You for damages, including any direct, indirect, special, 159 | incidental, or consequential damages of any character arising as a 160 | result of this License or out of the use or inability to use the 161 | Work (including but not limited to damages for loss of goodwill, 162 | work stoppage, computer failure or malfunction, or any and all 163 | other commercial damages or losses), even if such Contributor 164 | has been advised of the possibility of such damages. 165 | 166 | 9. Accepting Warranty or Additional Liability. While redistributing 167 | the Work or Derivative Works thereof, You may choose to offer, 168 | and charge a fee for, acceptance of support, warranty, indemnity, 169 | or other liability obligations and/or rights consistent with this 170 | License. However, in accepting such obligations, You may act only 171 | on Your own behalf and on Your sole responsibility, not on behalf 172 | of any other Contributor, and only if You agree to indemnify, 173 | defend, and hold each Contributor harmless for any liability 174 | incurred by, or claims asserted against, such Contributor by reason 175 | of your accepting any such warranty or additional liability. 176 | 177 | END OF TERMS AND CONDITIONS 178 | 179 | APPENDIX: How to apply the Apache License to your work. 180 | 181 | To apply the Apache License to your work, attach the following 182 | boilerplate notice, with the fields enclosed by brackets "[]" 183 | replaced with your own identifying information. (Don't include 184 | the brackets!) The text should be enclosed in the appropriate 185 | comment syntax for the file format. We also recommend that a 186 | file or class name and description of purpose be included on the 187 | same "printed page" as the copyright notice for easier 188 | identification within third-party archives. 189 | 190 | Copyright [yyyy] [name of copyright owner] 191 | 192 | Licensed under the Apache License, Version 2.0 (the "License"); 193 | you may not use this file except in compliance with the License. 194 | You may obtain a copy of the License at 195 | 196 | http://www.apache.org/licenses/LICENSE-2.0 197 | 198 | Unless required by applicable law or agreed to in writing, software 199 | distributed under the License is distributed on an "AS IS" BASIS, 200 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 201 | See the License for the specific language governing permissions and 202 | limitations under the License. 203 | -------------------------------------------------------------------------------- /Makefile: -------------------------------------------------------------------------------- 1 | TEX = pdflatex -interaction nonstopmode 2 | BIB = bibtex 3 | 4 | PAPER = paper 5 | BIBFILE = hyperledger.bib 6 | BUNDLE = paper.pdf 7 | 8 | all: $(PAPER).pdf 9 | 10 | spell:: 11 | ispell *.tex 12 | 13 | clean:: 14 | rm -fv *.aux *.log *.bbl *.blg *.toc *.out *.lot *.lof 15 | 16 | $(PAPER).pdf: $(wildcard *.tex) $(wildcard */*.tex) $(PAPER).bbl 17 | $(TEX) $(PAPER) 18 | $(TEX) $(PAPER) 19 | 20 | $(PAPER).bbl: $(PAPER).tex $(BIBFILE) 21 | $(TEX) $(PAPER) 22 | $(BIB) $(PAPER) 23 | 24 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # hyperledgerwp 2 | Hyperledger LaTeX documents 3 | -------------------------------------------------------------------------------- /RelevantUseCases/HealthCredentialing.tex: -------------------------------------------------------------------------------- 1 | \subsection{Health Records: Credentialing} 2 | 3 | Blockchain technologies promise to reduce one of the great annoyances of 4 | modern medical practice: ``credentialing''. Hospitals use the 5 | credentialing process to make sure that its physicians are competent and 6 | trustworthy. In a sense, credentialing is the hospital's way of 7 | performing ``due diligence'' on a physician. 8 | 9 | But today this process imposes a huge burden, both on the physician 10 | applying for affiliation and the hospital that must vet the 11 | applications. 12 | 13 | \subsubsection{The physician gathers credentials, many on paper} 14 | 15 | Any physician who wishes to become affiliated with a hospital begins the 16 | process by gathering copies of all their professional credentials, such 17 | as: 18 | 19 | \begin{itemize} 20 | \item Medical school diploma 21 | \item Certificates of any residencies and fellowships completed 22 | \item Certificates from any specialty medical boards 23 | \item All state medical licenses 24 | \item Evaluations from peers 25 | \item Proof of meeting requirements for continuing medical education 26 | \item Letters from hospitals where the physician was previously 27 | affiliated, explaining how and why the affiliation ended 28 | \item Details of any malpractice suits 29 | \end{itemize} 30 | 31 | \Mic{This paragraph is rather simplistic. Many of the required documents 32 | are electronic, but simply not available. Some are paper hand must be 33 | converted though often physical artifacts are used. My recommendation is 34 | that we just get rid of this.} 35 | Many of these documents were originally provided on paper, so the 36 | physician may need to scan in paper copies, and manage a set of scanned 37 | images or PDFs. 38 | 39 | \subsubsection{The hospital checks credentials and calls a meeting} 40 | 41 | On the hospital's side, the credentialing office checks the physician's 42 | documentation for completeness, accuracy, and authenticity. This is an 43 | exacting task. Almost inevitably, they find shortfalls and go back to 44 | the doctor for missing documents. 45 | 46 | Then the credentialing office verifies some or all of the physician's 47 | documentation. For example, they may phone a medical school to confirm 48 | that the physician did indeed graduate from there. This is clearly a 49 | time-intensive process that is prone to errors. 50 | 51 | Once the documentation is determined to be complete, accurate, and 52 | authentic, the hospital's credentialing committee---which typically 53 | includes physicians and administrators---meets to decide whether the 54 | physician can begin practicing in affiliation with the hospital. 55 | 56 | \Mic{Again, I'm not sure if calling out paper bound is either helpful or 57 | accurate. I would prefer to simply leave it as ``complex''.} 58 | The entire credentialing process is paper-bound, time-consuming, and 59 | low-trust. And it can take weeks or even months until any physician is 60 | cleared to affiliate with a hospital. 61 | 62 | \subsubsection{Three key questions for any blockchain solution} 63 | 64 | An effective blockchain solution for medical credentialing must answer 65 | three key questions about content, identities, and resources. 66 | 67 | \begin{enumerate} 68 | \item Will actual content or only pointers to content be placed on the 69 | blockchain? Credentialing solutions might place public information 70 | (such as state medical licensing) on the blockchain itself. However, 71 | private information (such as peer reviews) might be better stored off 72 | the chain; this would guard against any loss of keys, and enable users 73 | to remove---but not change---private information. 74 | 75 | \item What's the best way to manage the identities of many participants? 76 | An ambitious credentialing solution might include every hospital, every 77 | physician, every source of continuing medical education, and so on. 78 | This could eventually number thousands of participants. How will so 79 | many identities be efficiently and securely managed? 80 | 81 | \item What resources are required, especially for storage? 82 | Credentialing solutions may be in service for decades, requiring 83 | significant resources for processing, communication, and storage. For 84 | example, what if at some point credentialing organizations want video 85 | testimony from peers? Storage requirements could skyrocket---and who 86 | would cover that added cost? 87 | \end{enumerate} 88 | 89 | \subsubsection{Hyperledger can help streamline credentialing} 90 | 91 | Credentialing provides a good use case for blockchain technologies, 92 | which can simplify and streamline every step of the process. 93 | 94 | \textbf{Hyperledger Indy} provides off-the-shelf solutions that would 95 | otherwise require architecting and developing new software. One 96 | significant feature: Indy implements the proposed W3C standard for 97 | verifiable claims, supporting the pairwise exchange of selected 98 | credentials. In practice, this can work as follows: 99 | 100 | \begin{enumerate} 101 | \item A physician requests proof of graduation from their medical school. 102 | 103 | \item The medical school places a digital credential on the blockchain 104 | on behalf of the physician, where it's considered irrefutable and 105 | tamper-proof. 106 | 107 | \item A hospital can access the blockchain to verify the physician's 108 | credential, with no need to contact the medical school directly. 109 | 110 | \item The physician can expose only the specific credentials the 111 | hospital requires, and nothing more. 112 | \end{enumerate} 113 | 114 | This implementation of verifiable claims safeguards the physician's 115 | privacy, saves time and effort for everyone involved, and streamlines 116 | the entire process. At last: a better way to handle medical 117 | credentialing. 118 | -------------------------------------------------------------------------------- /RelevantUseCases/applying_for_a_loan.tex: -------------------------------------------------------------------------------- 1 | Financial institutions want to lend, but only if a borrower is a good risk. This motivates them to gather detailed, personally-identifying information (PII) from each applicant. Regulation may demand that certain PII be shared (e.g., to prevent money laundering); on the other hand, holding too much information exposes them to risks from privacy regulation and hacking. 2 | 3 | Loans aren't fun for the borrowers, either. They'd like to know which financial institution offers the best terms, but the application process is arduous and intrusive, and each new application they submit multiplies the effort and the risk that their data will be abused. 4 | 5 | The identity solution offered by Hyperledger Indy is transformative here. Applicants can share just the information that the financial institution needs to make a proposal, and they can do it in a way that guarantees truth, builds lender confidence, and satisfies regulatory pressures. They can do this with a hundred different potential lenders at a time, in milliseconds, all without creating correlation risk or placing sensitive personal info in a hackable database with custodians of uncertain reputation. Instead of disclosing their birthdate, annual income, and government ID number to enable a credit score, they can generate zero-knowledge proofs that they are over 21, that their gross income on last year’s taxes exceeded a certain threshold, that they possess a valid government ID number, and that their credit score exceeded a certain threshold within the past week. 6 | 7 | Strong, distributed ledger-based identity establishes a global source of truth in this use case, and this delivers value to many parties. Applicants can give consent, and everyone can agree on when and with what conditions it was given; lenders can demonstrate equal opportunity conformance with an immutable audit trail; the marketplace operates more efficiently. 8 | 9 | This use case only gets more compelling when the goodness of other Hyperledger projects is added. Hyperledger Burrow could turn loan applications into contracts, and attach them to strong identities as a seamless next step. A membership system based on Hyperledger Fabric could link to the pre-existing and self-sovereign identity of the application, allowing them to service loans and be a responsible customer of the lender without painful onboarding. And so forth. 10 | -------------------------------------------------------------------------------- /RelevantUseCases/financial_services.tex: -------------------------------------------------------------------------------- 1 | The primary drivers for adoption of blockchain in financial services industry are privacy, confidentiality, and accountability. 2 | 3 | Compliance guidelines like “Anti Money Laundering” and “Know Your Customer” require that banks and service providers verify their customers' legal identity and give them clearance to transact. These requirements drive the adoption of permissioned and private blockchains, since public blockchains can risk compromising a participant's privacy and confidentiality. 4 | 5 | Together with large volumes of transactions, these considerations are the primary reasons that consortium blockchains are gaining momentum in financial services. Among many possible use cases in this industry---especially in capital markets---post-trade processing can benefit from blockchain. 6 | 7 | \subsubsection{Post trade processing overview} 8 | 9 | Post-trade processing includes all the activities after the completion of a trade. This covers transactions done over-the-counter (OTC), through a brokerage, or at an exchange. 10 | 11 | On a high level, post-trade processing includes these steps: 12 | \begin{description} 13 | \item [Trade validation] - Validation and confirmation of the transactions following the trade execution. 14 | \item [Clearing] - Matching of the trade instructions and confirmations across the different counterparties as well as potential netting activities\footnote{The counterparty risk arising between the time of concluding the trade and the time of settlement, typically 2 - 3 days, is mitigated if the counterparties have agreed on bilateral margining or in case if the transactions are cleared through a clearing house.}. 15 | \item [Settlement] - The legal realization of the contractual obligations to reach the finality of the transaction. This includes support processes such as notification of all entities affected by the transaction. 16 | \item [Custody activities] - Adjustment of the positions held with the custodians on behalf of the counterpaties. 17 | \item [Reporting] - Satisfying reporting requirements for regulatory and internal counterparty risk\footnote{The contribution of the transaction to the market and credit risk of the respective counterparts.}. 18 | \end{description} 19 | 20 | \subsubsection{Issues with today's post trade processing} 21 | 22 | Today, all these steps are typically done through a fragmented workflow that spans numerous departments across different entities: brokers, central security depositories, clearing houses, exchanges, settlement agents, and so on. Every trade involves many different interfaces, processes, and reconciliation efforts. 23 | 24 | For example, today both parties send separate settlement instructions to a trusted third party---the settlement agent---which matches both data sets and instructions. Any mismatches trigger prolonged reconciliation efforts or may even result in a failed trade. 25 | 26 | All this duplication of effort introduces inefficiency and delays into post-trade processing. 27 | 28 | \subsubsection{Blockchain can streamline post trade processing} 29 | 30 | Compared to the current model, doing post-trade processing on blockchain can be far more efficient. 31 | 32 | This can exploit the peer-to-peer strength of a blockchain, so that one party can insert transaction details for the other party to verify. Doing both processes on the same system can significantly streamline the process. The network itself can act as a trusted third party, due to the immutable and irrefutable nature of transactions on the blockchain. 33 | 34 | The complexity can be further reduced, since all data from all steps and all actors can reside on the blockchain, accessible on a need-to-know basis. Any further reconciliation becomes unnecessary. And the blockchain system can also serve as an efficient basis for regulatory and trade reporting. 35 | 36 | This means four of the five steps listed above---validation, clearing, settlement, and reporting---can be streamlined by using a blockchain for post-trade processing.\footnote{The usefulness of blockchain for post-trade settlement may be limited, since near real-time settlement may eliminate the netting (or position offsetting) benefits of end-of-day processing.} 37 | 38 | \subsubsection{Special features required for post trade processing} 39 | 40 | Any permissioned distributed ledger can provide a tamper-proof, irrefutable transaction log. But to be effective for post-trade processing, a blockchain requires several added features, such as immediate finality, future-proof confidentiality, and streamlined performance. 41 | 42 | \textbf{Immediate finality}: Any distributed ledger used for capital markets must offer immediate finality, so that the receiver can be assured that the transactions are valid and committed. Consensus algorithms such as proof of work (PoW), proof of stake (PoS), or proof of elapsed time (PoET) can cause temporary forks and even transaction rollbacks. These are unacceptable in post-trade processing. Any blockchain for this use case must use a consensus algorithm, which provides immediate finality. 43 | 44 | \textbf{Future-proof confidentiality}: Participants in any trade expect their transactions to remain private and confidential. The clearing house recording the transaction must ensure that parties can't see each other's position or trading information. Even with anonymized data, the existence of trades must not be revealed, since this can make transactions susceptible to traffic analysis. Correlated to public market information, this can compromise both a participant's identity and their trading patterns. 45 | 46 | Additionally, more stringent requirements for ensuring confidentiality of the ledger data in the future. In a typical blockchain, where all of the data is stored on each of the participating computers, any compromise of the private key, or, even worse, cryptographic hash or encryption algorithm may lead to complete revealing of all historic data for all participants. Distributed ledger used for financial services must ensure future-proof confidentiality of the transactions. 47 | 48 | \textbf{Streamlined performance}: Today, all post-trade activities happen at the end of the business day, which presents different requirements than most other use cases. When using a blockchain, it will not be necessary to transmit the entire day's set of trade records to be reconciled. All trades will be reconciled in near real-time. 49 | 50 | Yet the total number of transactions will likely increase, since participants can learn their position with the clearing house in near real-time. This means while the average number of transactions per second will likely increase, the peak performance requirements will decrease significantly. Overall, system throughput will increase. 51 | 52 | \subsubsection{Hyperledger projects can help} 53 | 54 | Several projects from Hyperledger provide features and functions that can help build effective blockchain solutions for post-trade processing. 55 | 56 | The channels supported by \textbf{Hyperledger Fabric} can be deployed as fully disjoint networks with separate endorser sets and ordering nodes to provide privacy and confidentiality. Restricting data replication only to permissioned parties delivers the benefits of the blockchain for data integrity and non-repudiation of transactions, without compromising data security. Reporting requirements---both internal and external---can be satisfied by including a regulatory agency and other oversight entities as members of the channel. Network segmentation enabled by Fabric's channels can support multiple jurisdictions and regulatory regimes. 57 | 58 | The transaction families in \textbf{Hyperledger Sawtooth} provide a reliable and powerful way to support post-trade activities. Building complex rules using a preferred language, and exposing only the functions appropriate to the context, enables safer smart contracts. The option to prohibit deployment of ad-hoc smart contracts further reduces risks for financial institutions. 59 | 60 | \textbf{Hyperledger Indy's} unlinkable verifiable claims can be leveraged to report outstanding risk on a shared ledger without compromising privacy. This still enables a regulatory body to take a holistic view of the market, and to help prevent potential market crashes and major defaults. This feature can also strengthen privacy, by putting participants in control of their network identities and any attributes they choose to disclose. -------------------------------------------------------------------------------- /RelevantUseCases/identity.tex: -------------------------------------------------------------------------------- 1 | One of the most exciting potential applications of blockchain is self-sovereign identity. The main idea of self-sovereign identity is that an individual owns and controls their own `identity' and all of the data around it. \textbf{Hyperledger Indy} is a distributed ledger with a primary focus on this sort of identity. 2 | 3 | Indy shares some features with traditional enterprise identity solutions--the world of LDAP, OAuth, 2FA, IDPs, and similar tech. Both approaches use industrial-strength crypto. Both enable capturing and sharing rich metadata about an identity. Both facilitate sophisticated access control and policy. But there is a profound difference: Indy identities are shared instead of siloed and federated. An Indy identity is portable--you can bring it with you wherever the distributed ledger is accepted. Ten orgs or systems that each support Indy identities don't create ten separate identities for John Q. Public; John simply shows up with his pre-existing identity and uses it. Organizations can cancel John's access, but never his identity, because John owns it. John, not the places that accept John's identity, controls access to his data. 4 | 5 | Indy also shares some features with blockchain-based identity solutions such as Blockstack and Uport. All of these technologies store identity on a distributed ledger and thus promote security and personal freedom. However, Blockstack and Uport depend on Bitcoin and Ethereum, respectively. These are proof-of-work ecosystems that impose a non-trivial cost on transactions; every new persona, public key rotation, published attribute, or pairwise relationship is a tangible expense. This creates a disincentive to pairwise relationships, which undermines privacy. Also, these ecosystems are global and public; they cannot be special-purposed for a less-than-fully-global context. Indy, on the other hand, does not use proof-of-work. Transactions are free. And different instances of Indy can be used in whatever context is convenient. 6 | -------------------------------------------------------------------------------- /RelevantUseCases/relevant_use_cases.tex: -------------------------------------------------------------------------------- 1 | \subsection{Applying for a Loan} 2 | \input{RelevantUseCases/applying_for_a_loan.tex} 3 | 4 | % section name in the file 5 | \input{RelevantUseCases/supply_chain.tex} 6 | 7 | \subsection{Financial Services: Post Trade Activities} 8 | \input{RelevantUseCases/financial_services.tex} 9 | 10 | % section name in the file 11 | \input{RelevantUseCases/HealthCredentialing.tex} 12 | 13 | \subsection{Identity} 14 | \input{RelevantUseCases/identity.tex} -------------------------------------------------------------------------------- /RelevantUseCases/supply_chain.tex: -------------------------------------------------------------------------------- 1 | \subsection{Supply Chain: Tracking Fish from Ocean to Table} 2 | 3 | Ocean fishing represents more than \$70B in worldwide trade.\footnote{ 4 | Food and Agriculture Organization, United Nations. 2016. The State of 5 | World Fisheries and Aquaculture 6 | 2016. \url{http://www.fao.org/3/a-i5555e.pdf}} But the industry faces 7 | many problems. 8 | 9 | For example, estimates suggest at least 20\% of all fish are caught 10 | illegally---yet only a tiny fraction are ever inspected.~\footnote{ 11 | Stolen Seafood: The Impact of Pirate Fishing on Our 12 | Oceans. Oceana. 2013. \url{http://oceana.org/sites/default/files/reports/Oceana_StolenSeafood.pdf}} 13 | 14 | A recent study based on DNA testing found that nearly one in three fish 15 | were mislabeled by sellers.\footnote{ Miguel Angel Pardo, Elisa 16 | Jimenez, Begona Perez-Villarreal. Misdescription incidents in 17 | seafood sector. 2016. Food Control 62 pages 277--283. These names need 18 | proper accents.} And a detailed sampling from 674 outlets across the 19 | United States found that 87\% of snapper and 59\% of tuna were 20 | mislabelled---and worse, 95\% of all sushi restaurants were serving 21 | mislabeled fish.~\footnote{ Oceana Study Reveals Seafood Fraud 22 | Nationwide. 2013. \url{http://oceana.org/sites/default/files/reports/National_Seafood_Fraud_Testing_Results_FINAL.pdf}} 23 | 24 | These issues create health risks for consumers, hurt vulnerable fish 25 | stocks, rob nations of taxes, and damage the integrity of the whole 26 | industry. 27 | 28 | \subsubsection{Many challenges in seafood traceability} 29 | 30 | Traceability and provenance are well-managed for certain local catches 31 | such as Maine lobster and Maryland crab. But as shown in Figure X, the 32 | complexity of the ecosystem makes it challenging to achieve better 33 | traceability. 34 | 35 | A recent study by the non-profit sustainable seafood organization FishWise identified these key problems: 36 | \begin{itemize} 37 | \item Many different paths from ocean to table 38 | \item Lack of global authority for tracing 39 | \item Proprietary tracing systems do not scale 40 | \item Most existing processes are paper-based\footnote { FishWise. 2017. Advancing Traceability in the Seafood Industry: Assessing Challenges and Opportunities. \url{https://www.fishwise.org/traceability/traceability-white-paper/}} 41 | \end{itemize} 42 | 43 | The supply chain that delivers fish from ocean to table is extremely 44 | complex and opaque. It includes many participants from different 45 | industries, and regulatory controls that cross national boundaries. 46 | That makes this supply chain a perfect opportunity for blockchain 47 | technologies. 48 | 49 | Oceana, an NGO devoted to protecting the oceans, postulated that a 50 | shared platform for traceability would help to improve the accuracy of 51 | labeling and reduce pirate fishing: ``Despite formidable challenges, 52 | seafood traceability is well within reach. Simply by keeping track of 53 | where our seafood comes from at every step of the supply chain, we can 54 | make progress against pirate fishing.''\footnote{ Oceana. 2014 Annual 55 | Report. \url{http://oceana.org/sites/default/files/2014_annual_report.pdf}} 56 | 57 | \newpage 58 | \begin{figure} 59 | \includegraphics[height=22cm]{graphic_seafood_supply_chain.png} 60 | \caption{\textbf{The Complexity of the Seafood Supply Chain}} 61 | \emph{Source: Advancing Traceability in the Seafood Industry, FishWise} 62 | \end{figure} 63 | \newpage 64 | 65 | \subsubsection{A seafood supply chain prototype} 66 | 67 | A team at Intel is using \textbf{Hyperledger Sawtooth} to build a 68 | traceability prototype that combines the distributed ledger, IoT 69 | sensors, and advanced communications to track telemetry parameters 70 | throughout capture, processing, and transit. 71 | 72 | Sensors attached to the fish when it is caught record data such as 73 | location, temperature, and humidity. This data is recorded in the 74 | ledger, along with further events in the processing of the fish: 75 | ownership changes, transport company, storage temperature range, and so 76 | on. The ledger can also provide analytics for regulatory enforcement 77 | and scientific analysis of fish harvesting and consumption. 78 | 79 | This prototype highlights the benefits of Hyperledger Sawtooth as a 80 | platform for tracing assets. The lightweight, highly decentralized 81 | consensus protocol in Sawtooth (proof of elapsed time) is particularly 82 | well-suited to a diverse, distributed ecosystem where thousands of 83 | validating nodes may be required. Broad participation in the ledger 84 | reflects the cross-industry nature of the seafood supply chain. 85 | 86 | \subsubsection{Asset tracking touches on different issues} 87 | 88 | Asset tracking touches on several issues not generally seen in ledgers 89 | for financial products. For example, asset tracking requires handling 90 | diverse data types, such as the composite format required for telemetry 91 | and environmental sensing. Sawtooth accommodates both domain-specific 92 | data and the transaction families that operate on it, including data 93 | constraints such as verifying the calibration of a sensor. 94 | 95 | Blockchain promises a number of benefits for cross-industry 96 | traceability. Most of all, these technologies can help establish a 97 | community of participants and an authoritative record of provenance. 98 | The blockchain's decentralized fault-tolerance enable updates from a 99 | wide range of nodes, including fishing boats, trucks, cold-storage 100 | facilities, retail stores, and restaurants. 101 | 102 | Beyond traceability, digitizing assets opens the door for completely new 103 | markets such as, for example, monetization of provenance. 104 | -------------------------------------------------------------------------------- /authors.tex: -------------------------------------------------------------------------------- 1 | We as the Hyperledger Whitepaper Working Group would like to thank the following people for contributing to the writing of this paper: 2 | 3 | Tamas Blummer, Sean Bohan, Mic Bowman, Christian Cachin, Nick Gaski, Nathan George, Daniel Hardman, Ram Jagadeesan, Travin Keith, Renat Khasanshyn, Murali Krishna, Tracy Kuhrt, Arnaud Le Hors, Stanislav Liberman, Esther Mendez, Dan Middleton, Hart Montgomery, Dan O'Prey, Drummond Reed, Stefan Teis, Dave Voell, Greg Wallace, Baohua Yang. 4 | 5 | 6 | In addition, we would like to thank the Hyperledger Technical Steering and Marketing Committees for providing valuable feedback throughout the process of writing this paper. 7 | 8 | -------------------------------------------------------------------------------- /breakcites.sty: -------------------------------------------------------------------------------- 1 | % breakcites.sty 2 | % Style file to allow citations to be broken across lines. 3 | % -Don Hosek 3/14/89 4 | % 5 | \def\@citex[#1]#2{\if@filesw\immediate\write\@auxout{\string\citation{#2}}\fi 6 | \def\@citea{}\@cite{\@for\@citeb:=#2\do 7 | {\@citea\def\@citea{,\penalty\@m\ }\@ifundefined 8 | {b@\@citeb}{{\bf ?}\@warning 9 | {Citation `\@citeb' on page \thepage \space undefined}}% 10 | {\csname b@\@citeb\endcsname}}}{#1}} 11 | -------------------------------------------------------------------------------- /conclusion.tex: -------------------------------------------------------------------------------- 1 | In this paper, we have explained the rationale behind the creation of Hyperledger and what our goals were, and still are, for the project. We outlined why we think an open source umbrella organization seems to be the optimal governing arrangement for a general blockchain consortium and showcased some of the use cases that inspired our members to join and work on Hyperledger as well as delineated some of the features that result from building blockchains for some of these interesting use cases. In addition, we briefly summarized all of the main Hyperledger projects and their statuses. 2 | 3 | We hope that this is just the beginning for many readers. While this paper is not intended to be technical, we note that there is a wealth of technical information on the Hyperledger wiki. Each of the main projects has quite a bit of documentation, getting-started guides, and help available there\footnote{If this isn't true, it should be!}. In addition, some of the working groups have great technical resources. The architecture working group has a substantial amount of documentation on permissioned blockchain fundamentals and is a great resource for those looking to explore technical details. There are also application-specific working groups that are great places to learn. For instance, he identity working group has spent a lot of time discussing and documenting how blockchain can enable identity solutions. We encourage readers to look to these places for more information on topics that they find interesting. 4 | 5 | We hope that this paper is just the beginning of the Hyperledger experience for many. We acknowledge that there is a lot of work left to be done, and that Hyperledger will almost always be a work-in-progress. But, we think our organization is solid and believe that, maybe with your help, we can build secure, efficient, and reliable blockchain solutions. 6 | -------------------------------------------------------------------------------- /design_philosophy.tex: -------------------------------------------------------------------------------- 1 | At Hyperledger, all projects follow a design philosophy that includes a modular extensible approach, interoperability, emphasis on highly secure solutions, a token agnostic approach with no native cryptocurrency and the development of a rich and easy-to-use Application Program Interface (API). 2 | 3 | Distributed ledgers for different use cases can have vastly different requirements. For instance, in use cases where participants have high trust between one another, such as many financial applications, blockchains can use rapid network consensus systems and short block confirmation times before being added to the chain. However, other applications where there is minimal trust between participants may tolerate slower processing times. 4 | 5 | Hyperledger embraces the full spectrum of these uses cases, especially enterprise scenarios with widely varied requirements for decentralization, trust, continuity, confirmation times, etc. Each represents a potentially unique “optimization point” for the technology. To address this, Hyperledger is developing modular, extensible frameworks that allow the re-use of common building blocks, while enabling experimentation and evolution with DLT components. This modular approach enables extensibility and flexibility by defining common functional modules and the interfaces between them. This allows components to be changed independently without affecting the rest of the system. We are in the early stages in the evolution of DLT systems, and by taking a modular approach we will be able to experiment with different approaches to functional components. A modular approach allows us to develop optimal components which may be combined to compose DLT solutions that are best suited to different sets of requirements. Another advantage of the modular approach is that it allows a diverse community of developers to work independently on different modules, and allows the re-use of common modules across multiple projects. We define modules and interfaces for consensus, ledger storage, smart contract, communication, identity and policy and crypto functions\footnote{The architecture working group rocks!}. 6 | 7 | Security is a key consideration for distributed ledgers, as many use cases may involve high value transactions or otherwise sensitive data. Securing a blockchain is quite a difficult task: distributed ledger components must be secure against online, persistent adversaries while still containing a large, feature-rich set of functionalities. The large codebase and open, networked nature of distributed ledgers make them prime targets for attackers. 8 | 9 | In Hyperledger we view security and robustness as key aspects of Enterprise class blockchains and DLTs, which will evolve into critical infrastructure for next generation business networks. This includes embracing security by design and following best practices as specified by the Linux Foundation’s Core Infrastructure Initiative, and ensuring that the algorithms, protocols and crypto are reviewed and audited by security experts. 10 | 11 | Interoperability and portability are key aspects for the work done under the Hyperledger umbrella. We envision that there will be many interconnected blockchain networks which will need to communicate and interact with each other to form potentially complicated networks. It is also highly desirable that smart contracts and applications be portable across different instances of blockchain/DLT networks in order to make development easier. 12 | 13 | Hyperledger is independent and agnostic of currency and tokens. In Hyperledger we do not require a native token either as a means to provide incentives to operate the network or for resource management.The explicit focus on managing digital objects (which may represent currencies) removes the requirement for intrinsic crypto-currencies and native tokens. 14 | 15 | Hyperledger projects will also support a well defined set of API’s and SDK’s that allow external clients and applications to interface with core DLT infrastructure. These API’s will enable a rich developer ecosystem that is needed to be successful in proliferating blockchain and DLT solutions across a diverse set of markets and use cases. 16 | -------------------------------------------------------------------------------- /figures/FishSupplyChain.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/hyperledger-archives/hyperledgerwp/e0165f4bbb55b00d1bc0a14d3882d7d37f653ebc/figures/FishSupplyChain.png -------------------------------------------------------------------------------- /hyperledger.bib: -------------------------------------------------------------------------------- 1 | @incollection{Nak08, 2 | title={Bitcoin: A Peer-to-Peer Electronic Cash System}, 3 | author={Nakamoto, Satoshi}, 4 | note = {\url{http://bitcoin.org/bitcoin.pdf}}, 5 | year={2008} 6 | } 7 | 8 | @article{But13, 9 | title={Ethereum White Paper: A Next-Generation Smart Contract 10 | and Decentralized Application Platform}, 11 | author={Vitalik Buterin and others}, 12 | note = {\url{https://github.com/ethereum/wiki/wiki/White-Paper}}, 13 | year={2013} 14 | } 15 | 16 | -------------------------------------------------------------------------------- /introduction.tex: -------------------------------------------------------------------------------- 1 | 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. 2 | 3 | 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. 4 | 5 | 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. 6 | 7 | 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. 8 | 9 | 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. 10 | 11 | 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. 12 | 13 | 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. 14 | 15 | In the remaining sections of the paper, we will explain what Hyperledger is and many of the design decisions and principles of the effort. 16 | 17 | \subsection{Outline} 18 | 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}. 19 | 20 | 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. 21 | -------------------------------------------------------------------------------- /latexdefs.tex: -------------------------------------------------------------------------------- 1 | \usepackage[pdfstartview=FitH,colorlinks,urlcolor=black,linkcolor=black,citecolor=black,pdfpagelabels]{hyperref} 2 | \usepackage[usenames,dvipsnames]{color} 3 | %\usepackage{times} 4 | \usepackage{microtype,pdfsync} 5 | \usepackage{graphicx} 6 | \iftoggle{fullversion}{ 7 | \usepackage{amsthm}}{} 8 | \usepackage{amsmath,amsfonts,amssymb} 9 | \usepackage{tabu} % detect if table is in math mode 10 | \usepackage{url} \usepackage{graphicx} 11 | \iftoggle{fullversion}{ 12 | \usepackage{fullpage}}{} 13 | \usepackage{mathtools} 14 | \usepackage{footnote} 15 | 16 | \newcommand{\Theorem}[1]{\hyperref[#1]{Theorem~\ref*{#1}}} 17 | \newcommand{\Lemma}[1]{\hyperref[#1]{Lemma~\ref*{#1}}} 18 | \newcommand{\Corollary}[1]{\hyperref[#1]{Corollary~\ref*{#1}}} 19 | \newcommand{\Definition}[1]{\hyperref[#1]{Definition~\ref*{#1}}} 20 | \newcommand{\Conjecture}[1]{\hyperref[#1]{Conjecture~\ref*{#1}}} 21 | \newcommand{\Section}[1]{\hyperref[#1]{Section~\ref*{#1}}} 22 | \newcommand{\Appendix}[1]{\hyperref[#1]{Appendix~\ref*{#1}}} 23 | 24 | %\usepackage{natbib} 25 | %\setlength{\bibsep}{0.3em} 26 | 27 | \usepackage{xspace} 28 | \usepackage{multirow} 29 | \usepackage{enumitem} 30 | 31 | \usepackage[hang,flushmargin]{footmisc} 32 | 33 | \usepackage{tikz} 34 | \usetikzlibrary{calc,positioning,shapes,shadows,arrows,fit} 35 | 36 | \newcommand{\ignore}[1]{} 37 | 38 | \usepackage{caption} 39 | \captionsetup[figure]{width=.86\textwidth} 40 | \captionsetup[table]{width=.86\textwidth} 41 | \setlength{\abovecaptionskip}{0pt} 42 | \setlength{\belowcaptionskip}{3pt} 43 | 44 | \newenvironment{vbx}{\vbox\bgroup}{\egroup} 45 | 46 | \numberwithin{equation}{section} 47 | 48 | %fields and groups 49 | \newcommand{\F}{\mathbb{F}} 50 | \newcommand{\Q}{\mathbb{Q}} 51 | \newcommand{\N}{\mathbb{N}} 52 | \newcommand{\Z}{\mathbb{Z}} 53 | \newcommand{\R}{\mathbb{R}} 54 | \newcommand{\C}{\mathbb{C}} 55 | \newcommand{\Qbar}{\overline{\Q}} 56 | \newcommand{\G}{\mathbb{G}} 57 | \newcommand{\Vs}{\mathbb{V}} 58 | \newcommand{\Fbar}{\overline{\mathbb{F}}} 59 | 60 | %vectors, etc. 61 | \newcommand{\av}{\mathbf{a}} \newcommand{\cv}{\mathbf{c}} 62 | \newcommand{\dv}{\mathbf{d}} \newcommand{\ev}{\mathbf{e}} 63 | \newcommand{\rv}{\mathbf{r}} \newcommand{\sv}{\mathbf{s}} 64 | \newcommand{\tv}{\mathbf{t}} \newcommand{\uv}{\mathbf{u}} 65 | \newcommand{\vv}{\mathbf{v}} \newcommand{\wv}{\mathbf{w}} 66 | \newcommand{\xv}{\mathbf{x}} \newcommand{\yv}{\mathbf{y}} 67 | \newcommand{\zv}{\mathbf{z}} \newcommand{\zerov}{\mathbf{0}} 68 | \renewcommand{\AA}{\mathbf{A}} \newcommand{\BB}{\mathbf{B}} 69 | \newcommand{\CC}{\mathbf{C}} \newcommand{\FF}{\mathbf{F}} 70 | \newcommand{\MM}{\mathbf{M}} \newcommand{\RR}{\mathbf{R}} 71 | \renewcommand{\SS}{\mathbf{S}} \newcommand{\TT}{\mathbf{T}} 72 | \newcommand{\UU}{\mathbf{U}} \newcommand{\XX}{\mathcal{X}} 73 | \newcommand{\YY}{\mathcal{Y}} \newcommand{\KK}{\mathcal{K}} 74 | \newcommand{\A}{\mathcal{A}} \newcommand{\B}{\mathcal{B}} 75 | \newcommand{\dash}{\mbox{---}} 76 | \renewcommand{\O}{\mathcal{O}} 77 | \newcommand{\qq}{\mathfrak{q}} 78 | \newcommand{\QQ}{\mathfrak{Q}} 79 | \newcommand{\ZQ}{\Z_{q}} 80 | 81 | \newcommand{\vtbl}[2]{\begin{array}{c} 82 | \hspace*{-3pt} #1 \hspace*{-4pt} \vspace*{5pt} \\ 83 | \hspace*{-3pt} #2 \hspace*{-4pt} 84 | \end{array}} 85 | 86 | %\newcommand{\vk}{\mathbf{k}} 87 | \newcommand{\vu}{\mathbf{u}} 88 | 89 | \newcommand{\todo}[1]{{\color{red} {\bf TODO}:~{#1}}} 90 | \newcommand{\btodo}[1]{{\color{blue} {\bf TODO}:~{#1}}} 91 | \newcommand{\ltodo}[2]{{\color{blue} {\bf TODO (locked by {#1})}:~{#2}}} 92 | \newcommand{\lbtodo}[2]{{\color{blue} {\bf TODO (locked by {#1}}:~{#2}}} 93 | 94 | \newcommand{\mr}[1]{\ensuremath{\mathrm{{#1}}}} 95 | \newcommand{\la}{\ensuremath{\leftarrow}} 96 | \newcommand{\ra}{\ensuremath{\rightarrow}} 97 | \newcommand{\ala}{\ensuremath{\ \la\ }} 98 | \newcommand{\ara}{\ensuremath{\ \ra\ }} 99 | \newcommand{\rf}{\ensuremath{\overset{\$}{\la}}} 100 | 101 | \newcommand{\dist}[1]{\esm{\left\langle{#1}\right\rangle}} 102 | 103 | \newcommand{\parh}[1]{{\bf {#1}}\ \ } 104 | \renewcommand{\paragraph}[1]{\medskip\noindent {\bf {#1}}} 105 | 106 | 107 | \newcommand{\calA}{\ensuremath{\mathcal{A}}} 108 | \newcommand{\calB}{\ensuremath{\mathcal{B}}} 109 | \newcommand{\calC}{\ensuremath{\mathcal{C}}} 110 | \newcommand{\calD}{\ensuremath{\mathcal{D}}} 111 | \newcommand{\calE}{\ensuremath{\mathcal{E}}} 112 | \newcommand{\calF}{\ensuremath{\mathcal{F}}} 113 | \newcommand{\calG}{\ensuremath{\mathcal{G}}} 114 | \newcommand{\calH}{\ensuremath{\mathcal{H}}} 115 | \newcommand{\calI}{\ensuremath{\mathcal{I}}} 116 | \newcommand{\calJ}{\ensuremath{\mathcal{J}}} 117 | \newcommand{\calK}{\ensuremath{\mathcal{K}}} 118 | \newcommand{\calL}{\ensuremath{\mathcal{L}}} 119 | \newcommand{\calM}{\ensuremath{\mathcal{M}}} 120 | \newcommand{\calN}{\ensuremath{\mathcal{N}}} 121 | \newcommand{\calO}{\ensuremath{\mathcal{O}}} 122 | \newcommand{\calP}{\ensuremath{\mathcal{P}}} 123 | \newcommand{\calQ}{\ensuremath{\mathcal{Q}}} 124 | \newcommand{\calR}{\ensuremath{\mathcal{R}}} 125 | \newcommand{\calS}{\ensuremath{\mathcal{S}}} 126 | \newcommand{\calT}{\ensuremath{\mathcal{T}}} 127 | \newcommand{\calU}{\ensuremath{\mathcal{U}}} 128 | \newcommand{\calV}{\ensuremath{\mathcal{V}}} 129 | \newcommand{\calW}{\ensuremath{\mathcal{W}}} 130 | \newcommand{\calX}{\ensuremath{\mathcal{X}}} 131 | \newcommand{\calY}{\ensuremath{\mathcal{Y}}} 132 | \newcommand{\calZ}{\ensuremath{\mathcal{Z}}} 133 | 134 | % -- bold math symbols, for some reason -- 135 | \newcommand{\boldalpha}{\ensuremath{\boldsymbol{\alpha}}} 136 | \newcommand{\boldchi}{\ensuremath{\boldsymbol{\chi}}} 137 | \newcommand{\boldtau}{\ensuremath{{\boldsymbol{\tau}}}} 138 | \newcommand{\boldstar}{\ensuremath{\mathbf{*}}} 139 | \newcommand{\bolda}{\ensuremath{\mathbf{a}}} 140 | \newcommand{\boldb}{\ensuremath{\mathbf{b}}} 141 | \newcommand{\boldc}{\ensuremath{\mathbf{c}}} 142 | \newcommand{\boldd}{\ensuremath{\mathbf{d}}} 143 | \newcommand{\bolde}{\ensuremath{\mathbf{e}}} 144 | \newcommand{\boldf}{\ensuremath{\mathbf{f}}} 145 | \newcommand{\boldg}{\ensuremath{\mathbf{g}}} 146 | \newcommand{\boldh}{\ensuremath{\mathbf{h}}} 147 | \newcommand{\boldi}{\ensuremath{\mathbf{i}}} 148 | \newcommand{\boldj}{\ensuremath{\mathbf{j}}} 149 | \newcommand{\boldk}{\ensuremath{\mathbf{k}}} 150 | \newcommand{\boldl}{\ensuremath{\mathbf{l}}} 151 | \newcommand{\boldm}{\ensuremath{\mathbf{m}}} 152 | \newcommand{\boldn}{\ensuremath{\mathbf{n}}} 153 | \newcommand{\boldo}{\ensuremath{\mathbf{o}}} 154 | \newcommand{\boldp}{\ensuremath{\mathbf{p}}} 155 | \newcommand{\boldq}{\ensuremath{\mathbf{q}}} 156 | \newcommand{\boldr}{\ensuremath{\mathbf{r}}} 157 | \newcommand{\bolds}{\ensuremath{\mathbf{s}}} 158 | \newcommand{\boldt}{\ensuremath{\mathbf{t}}} 159 | \newcommand{\boldu}{\ensuremath{\mathbf{u}}} 160 | \newcommand{\boldv}{\ensuremath{\mathbf{v}}} 161 | \newcommand{\boldw}{\ensuremath{\mathbf{w}}} 162 | \newcommand{\boldx}{{\ensuremath{\mathbf{x}}}} 163 | \newcommand{\boldy}{\ensuremath{\mathbf{y}}} 164 | \newcommand{\boldz}{\ensuremath{\mathbf{z}}} 165 | \newcommand{\boldzero}{\ensuremath{\boldsymbol{0}}} 166 | \newcommand{\boldone}{\ensuremath{\boldsymbol{1}}} 167 | 168 | % -- bold italic math symbols, for some reason -- 169 | \newcommand{\boldia}{\ensuremath{\boldsymbol{a}}} 170 | \newcommand{\boldib}{\ensuremath{\boldsymbol{b}}} 171 | \newcommand{\boldic}{\ensuremath{\boldsymbol{c}}} 172 | \newcommand{\boldid}{\ensuremath{\boldsymbol{d}}} 173 | \newcommand{\boldie}{\ensuremath{\boldsymbol{e}}} 174 | \newcommand{\boldif}{\ensuremath{\boldsymbol{f}}} 175 | \newcommand{\boldig}{\ensuremath{\boldsymbol{g}}} 176 | \newcommand{\boldih}{\ensuremath{\boldsymbol{h}}} 177 | \newcommand{\boldii}{\ensuremath{\boldsymbol{i}}} 178 | \newcommand{\boldij}{\ensuremath{\boldsymbol{j}}} 179 | \newcommand{\boldik}{\ensuremath{\boldsymbol{k}}} 180 | \newcommand{\boldil}{\ensuremath{\boldsymbol{l}}} 181 | \newcommand{\boldim}{\ensuremath{\boldsymbol{m}}} 182 | \newcommand{\boldin}{\ensuremath{\boldsymbol{n}}} 183 | \newcommand{\boldio}{\ensuremath{\boldsymbol{o}}} 184 | \newcommand{\boldip}{\ensuremath{\boldsymbol{p}}} 185 | \newcommand{\boldiq}{\ensuremath{\boldsymbol{q}}} 186 | \newcommand{\boldir}{\ensuremath{\boldsymbol{r}}} 187 | \newcommand{\boldis}{\ensuremath{\boldsymbol{s}}} 188 | \newcommand{\boldit}{\ensuremath{\boldsymbol{t}}} 189 | \newcommand{\boldiu}{\ensuremath{\boldsymbol{u}}} 190 | \newcommand{\boldiv}{\ensuremath{\boldsymbol{v}}} 191 | \newcommand{\boldiw}{\ensuremath{\boldsymbol{w}}} 192 | \newcommand{\boldix}{\ensuremath{\boldsymbol{x}}} 193 | \newcommand{\boldiy}{\ensuremath{\boldsymbol{y}}} 194 | \newcommand{\boldiz}{\ensuremath{\boldsymbol{z}}} 195 | 196 | \newcommand{\transpose}[1]{\ensuremath{{#1}^{\intercal}}} 197 | 198 | \newcommand{\boldA}{\ensuremath{\mathbf{A}}} 199 | \newcommand{\boldB}{\ensuremath{\mathbf{B}}} 200 | \newcommand{\boldC}{\ensuremath{\mathbf{C}}} 201 | \newcommand{\boldD}{\ensuremath{\mathbf{D}}} 202 | \newcommand{\boldE}{\ensuremath{\mathbf{E}}} 203 | \newcommand{\boldF}{\ensuremath{\mathbf{F}}} 204 | \newcommand{\boldG}{\ensuremath{\mathbf{G}}} 205 | \newcommand{\boldH}{\ensuremath{\mathbf{H}}} 206 | \newcommand{\boldI}{\ensuremath{\mathbf{I}}} 207 | \newcommand{\boldJ}{\ensuremath{\mathbf{J}}} 208 | \newcommand{\boldK}{\ensuremath{\mathbf{K}}} 209 | \newcommand{\boldL}{\ensuremath{\mathbf{L}}} 210 | \newcommand{\boldM}{\ensuremath{\mathbf{M}}} 211 | \newcommand{\boldN}{\ensuremath{\mathbf{N}}} 212 | \newcommand{\boldO}{\ensuremath{\mathbf{O}}} 213 | \newcommand{\boldP}{\ensuremath{\mathbf{P}}} 214 | \newcommand{\boldQ}{\ensuremath{\mathbf{Q}}} 215 | \newcommand{\boldR}{\ensuremath{\mathbf{R}}} 216 | \newcommand{\boldS}{\ensuremath{\mathbf{S}}} 217 | \newcommand{\boldT}{\ensuremath{\mathbf{T}}} 218 | \newcommand{\boldU}{\ensuremath{\mathbf{U}}} 219 | \newcommand{\boldV}{\ensuremath{\mathbf{V}}} 220 | \newcommand{\boldW}{\ensuremath{\mathbf{W}}} 221 | \newcommand{\boldX}{\ensuremath{\mathbf{X}}} 222 | \newcommand{\boldY}{\ensuremath{\mathbf{Y}}} 223 | \newcommand{\boldZ}{\ensuremath{\mathbf{Z}}} 224 | 225 | \newcommand{\bbA}{\ensuremath{\mathbb{A}}} 226 | \newcommand{\bbB}{\ensuremath{\mathbb{B}}} 227 | \newcommand{\bbC}{\ensuremath{\mathbb{C}}} 228 | \newcommand{\bbD}{\ensuremath{\mathbb{D}}} 229 | \newcommand{\bbE}{\ensuremath{\mathbb{E}}} 230 | \newcommand{\bbF}{\ensuremath{\mathbb{F}}} 231 | \newcommand{\bbG}{\ensuremath{\mathbb{G}}} 232 | \newcommand{\bbH}{\ensuremath{\mathbb{H}}} 233 | \newcommand{\bbI}{\ensuremath{\mathbb{I}}} 234 | \newcommand{\bbJ}{\ensuremath{\mathbb{J}}} 235 | \newcommand{\bbK}{\ensuremath{\mathbb{K}}} 236 | \newcommand{\bbL}{\ensuremath{\mathbb{L}}} 237 | \newcommand{\bbM}{\ensuremath{\mathbb{M}}} 238 | \newcommand{\bbN}{\ensuremath{\mathbb{N}}} 239 | \newcommand{\bbO}{\ensuremath{\mathbb{O}}} 240 | \newcommand{\bbP}{\ensuremath{\mathbb{P}}} 241 | \newcommand{\bbQ}{\ensuremath{\mathbb{Q}}} 242 | \newcommand{\bbR}{\ensuremath{\mathbb{R}}} 243 | \newcommand{\bbS}{\ensuremath{\mathbb{S}}} 244 | \newcommand{\bbT}{\ensuremath{\mathbb{T}}} 245 | \newcommand{\bbU}{\ensuremath{\mathbb{U}}} 246 | \newcommand{\bbV}{\ensuremath{\mathbb{V}}} 247 | \newcommand{\bbW}{\ensuremath{\mathbb{W}}} 248 | \newcommand{\bbX}{\ensuremath{\mathbb{X}}} 249 | \newcommand{\bbY}{\ensuremath{\mathbb{Y}}} 250 | \newcommand{\bbZ}{\ensuremath{\mathbb{Z}}} 251 | 252 | \newcommand{\deq}{\mathrel{\mathop:}=} 253 | %\newcommand{\deq}{\ensuremath{\stackrel{\sf def}{=}}} % defined as equal to 254 | \newcommand{\zo}{\ensuremath{\{0,1\}}} % bits 255 | 256 | 257 | % THEOREMS %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 258 | % 259 | % Theorem definitions 260 | 261 | \iftoggle{fullversion}{ 262 | \theoremstyle{plain} \newtheorem{theorem}{Theorem}[section] 263 | \newtheorem{lemma}[theorem]{Lemma} 264 | \newtheorem{claim}[theorem]{Claim} 265 | \newtheorem{remark}[theorem]{Remark} 266 | \newtheorem{proposition}[theorem]{Proposition} 267 | \newtheorem{corollary}[theorem]{Corollary} 268 | 269 | \theoremstyle{definition} \newtheorem{defn}[theorem]{Definition} 270 | \newtheorem{definition}[theorem]{Definition} \newtheorem{rem}[theorem]{Remark} 271 | %\newtheorem{alg}[theorem]{Algorithm} 272 | \newtheorem{fact}[theorem]{Fact} 273 | %\newtheorem{construction}[theorem]{Construction} 274 | }{} 275 | 276 | 277 | %% custom macros 278 | 279 | 280 | \newcommand{\esm}[1]{\ensuremath{#1}} 281 | \newcommand{\ms}[1]{\esm{\mathsf{#1}}} 282 | 283 | \newcommand{\Am}{\mathbf{A}} 284 | \newcommand{\Um}{\mathbf{U}} 285 | 286 | \newcommand{\LWE}{\ms{LWE}} 287 | 288 | \newcommand{\perplattice}{\Lambda_q^{\bot}} 289 | \newcommand{\cosetlattice}[1]{\Lambda_q^{#1}} 290 | 291 | \newcommand{\set}[1]{\{ #1 \}} 292 | \newcommand{\getsdollar}{\overset{\$}{\gets}} 293 | \newcommand{\poly}{\ms{poly}} 294 | \newcommand{\negl}{\ms{negl}} 295 | 296 | 297 | \newcommand{\PiFHE}{\Pi_{\ms{FHE}}} 298 | \newcommand{\FHEKeyGen}{\ms{FHE.KeyGen}} 299 | \newcommand{\FHEEnc}{\ms{FHE.Enc}} 300 | \newcommand{\FHEEval}{\ms{FHE.Eval}} 301 | \newcommand{\FHEDec}{\ms{FHE.Dec}} 302 | 303 | \newcommand{\sk}{\ms{sk}} 304 | \newcommand{\ct}{\ms{ct}} 305 | \newcommand{\msk}{\ms{msk}} 306 | \newcommand{\pp}{\ms{pp}} 307 | \newcommand{\state}{\ms{state}} 308 | 309 | \newcommand{\PiPRF}{\Pi_\ms{pPRF}} 310 | \newcommand{\PRFSetup}{\ms{pPRF.Setup}} 311 | \newcommand{\PRFPuncture}{\ms{pPRF.Puncture}} 312 | \newcommand{\PRFPunctureEval}{\ms{pPRF.PunctureEval}} 313 | \newcommand{\PRFEval}{\ms{pPRF.Eval}} 314 | 315 | \newcommand{\Bm}{\mathbf{B}} 316 | \newcommand{\Cm}{\mathbf{C}} 317 | \newcommand{\Dm}{\mathbf{D}} 318 | \newcommand{\Identity}{\mathbf{I}} 319 | 320 | \newcommand{\Rm}{\mathbf{R}} 321 | \newcommand{\Gm}{\mathbf{G}} 322 | \newcommand{\mv}{\mathbf{m}} 323 | \newcommand{\bv}{\mathbf{b}} 324 | \newcommand{\kv}{\mathbf{k}} 325 | \newcommand{\Mm}{\mathbf{M}} 326 | \newcommand{\kS}{k_{\scriptscriptstyle S}} 327 | 328 | \newcommand{\gv}{\mathbf{g}} 329 | 330 | \newcommand{\noise}{\ms{noise}} 331 | 332 | \newcommand{\FHEpp}{\ms{fhe.pp}} 333 | \newcommand{\FHEsk}{\ms{fhe.sk}} 334 | \newcommand{\FHEct}{\ms{fhe.ct}} 335 | 336 | \newcommand{\iprod}[2]{\left\langle #1, #2 \right\rangle} 337 | 338 | 339 | \newcommand{\evalcomp}{\ms{Eval}_{\ms{comp},j}} 340 | \newcommand{\comp}{\ms{comp}} 341 | \newcommand{\roundp}[1]{\lfloor #1 \rceil_p} 342 | 343 | \newcommand{\evalpk}{\ms{Eval}_{\ms{pk}}} 344 | \newcommand{\evalct}{\ms{Eval}_{\ms{ct}}} 345 | 346 | \newcommand{\SampleD}{\ms{SampleD}} 347 | \newcommand{\compip}{\ms{comp \circ \ms{IP}}} 348 | \newcommand{\Ctilde}{{\tilde{C}}} 349 | \newcommand{\Ginv}{\Gm^{-1}} 350 | 351 | \newcommand{\tab}{\hspace{4mm}} 352 | 353 | \newcommand{\Hybrid}[1]{\ms{H}_{#1}} 354 | 355 | \newcommand{\Borderline}[1]{\ms{Borderline}_{#1}} 356 | 357 | \newcommand{\norm}[1]{\left\| #1 \right\|} 358 | 359 | \newcommand{\xstar}{x^*} 360 | \newcommand{\xvstar}{\xv^*} 361 | 362 | \newcommand{\cstar}{\cv^*} 363 | \newcommand{\ystar}{\yv^*} 364 | \newcommand{\Setup}{\ms{Setup}} 365 | \newcommand{\Puncture}{\ms{Puncture}} 366 | \newcommand{\Eval}{\ms{Eval}} 367 | 368 | \newcommand{\CgEval}{\FHEEval(\eq_\gamma, \cdot) \circ \ms{IP}} 369 | 370 | \newcommand{\Bfhe}{B_{\ms{fhe}}} 371 | \newcommand{\Babe}{B_{\ms{abe}}} 372 | 373 | 374 | \newcommand{\PicPRF}{\Pi_{\ms{cPRF}}} 375 | \newcommand{\cPRFSetup}{\ms{cPRF.Setup}} 376 | \newcommand{\cPRFConstrain}{\ms{cPRF.Constrain}} 377 | \newcommand{\cPRFConstrainEval}{\ms{cPRF.ConstrainEval}} 378 | \newcommand{\cPRFEval}{\ms{cPRF.Eval}} 379 | 380 | \newcommand{\SSetup}{\calS_{\ms{Setup}}} 381 | \newcommand{\SEval}{\calS_{\ms{Eval}}} 382 | \newcommand{\SConstrain}{\calS_{\ms{Constrain}}} 383 | \newcommand{\SKeyGen}{\calS_{\ms{KeyGen}}} 384 | \newcommand{\SEncrypt}{\calS_{\ms{Encrypt}}} 385 | 386 | \newcommand{\Expt}{\ms{Expt}} 387 | \newcommand{\enc}{\ms{enc}} 388 | 389 | \newcommand{\bvtilde}{\tilde{\bv}} 390 | \newcommand{\Bmtilde}{\tilde{\Bm}} 391 | 392 | \newcommand{\ppstar}{\pp^*} 393 | \newcommand{\mskstar}{\msk^*} 394 | \newcommand{\FHEctstar}{\FHEct^*} 395 | \newcommand{\skxstar}{\sk_{\xvstar}} 396 | \newcommand{\yvstar}{\yv^*} 397 | 398 | \newcommand{\qfhe}{q_{\ms{fhe}}} 399 | 400 | \newcommand{\eq}{\ms{eq}} 401 | \newcommand{\iO}{\ensuremath{i\mathcal{O}}} 402 | 403 | % SET TO FALSE TO DISABLE COMMENTS 404 | \newif\ifcomments 405 | \commentstrue 406 | 407 | \ifcomments 408 | \newcommand{\Hart}[1] 409 | {\begin{center} \framebox{ \parbox{ 15cm } 410 | {\textcolor[rgb]{0.8,0.0,0.7}{{\bf Hart:} #1}}} \end{center}} 411 | 412 | \else 413 | \newcommand{\Hart}[1]{} 414 | \fi 415 | 416 | \ifdefined\bolddelta 417 | \else 418 | \def\bolddelta{\boldsymbol{\delta}} 419 | \fi 420 | -------------------------------------------------------------------------------- /llncs.cls: -------------------------------------------------------------------------------- 1 | % LLNCS DOCUMENT CLASS -- version 2.10 2 | % for LaTeX2e 3 | % 4 | \NeedsTeXFormat{LaTeX2e}[1995/12/01] 5 | \ProvidesClass{llncs}[2001/08/14 v2.10 6 | ^^Jexperimental LaTeX document class for Lecture Notes in Computer Science] 7 | % Options 8 | \let\if@envcntreset\iffalse 9 | \DeclareOption{envcountreset}{\let\if@envcntreset\iftrue} 10 | \DeclareOption{citeauthoryear}{\let\citeauthoryear=Y} 11 | \DeclareOption{oribibl}{\let\oribibl=Y} 12 | \let\if@custvec\iftrue 13 | \DeclareOption{orivec}{\let\if@custvec\iffalse} 14 | \let\if@envcntsame\iffalse 15 | \DeclareOption{envcountsame}{\let\if@envcntsame\iftrue} 16 | \let\if@envcntsect\iffalse 17 | \DeclareOption{envcountsect}{\let\if@envcntsect\iftrue} 18 | \let\if@runhead\iffalse 19 | \DeclareOption{runningheads}{\let\if@runhead\iftrue} 20 | 21 | \let\if@openbib\iffalse 22 | \DeclareOption{openbib}{\let\if@openbib\iftrue} 23 | 24 | % languages 25 | \let\switcht@@therlang\relax 26 | \def\ds@deutsch{\def\switcht@@therlang{\switcht@deutsch}} 27 | \def\ds@francais{\def\switcht@@therlang{\switcht@francais}} 28 | 29 | \DeclareOption*{\PassOptionsToClass{\CurrentOption}{article}} 30 | 31 | \ProcessOptions 32 | 33 | \LoadClass[twoside]{article} 34 | \RequirePackage{multicol} % needed for the list of participants, index 35 | 36 | \setlength{\textwidth}{12.2cm} 37 | \setlength{\textheight}{19.3cm} 38 | \renewcommand\@pnumwidth{2em} 39 | \renewcommand\@tocrmarg{3.5em} 40 | % 41 | \def\@dottedtocline#1#2#3#4#5{% 42 | \ifnum #1>\c@tocdepth \else 43 | \vskip \z@ \@plus.2\p@ 44 | {\leftskip #2\relax \rightskip \@tocrmarg \advance\rightskip by 0pt plus 45 | 2cm 46 | \parfillskip -\rightskip \pretolerance=10000 47 | \parindent #2\relax\@afterindenttrue 48 | \interlinepenalty\@M 49 | \leavevmode 50 | \@tempdima #3\relax 51 | \advance\leftskip \@tempdima \null\nobreak\hskip -\leftskip 52 | {#4}\nobreak 53 | \leaders\hbox{$\m@th 54 | \mkern \@dotsep mu\hbox{.}\mkern \@dotsep 55 | mu$}\hfill 56 | \nobreak 57 | \hb@xt@\@pnumwidth{\hfil\normalfont \normalcolor #5}% 58 | \par}% 59 | \fi} 60 | % 61 | \def\switcht@albion{% 62 | \def\abstractname{Abstract.} 63 | \def\ackname{Acknowledgement.} 64 | \def\andname{and} 65 | \def\lastandname{\unskip, and} 66 | \def\appendixname{Appendix} 67 | \def\chaptername{Chapter} 68 | \def\claimname{Claim} 69 | \def\conjecturename{Conjecture} 70 | \def\contentsname{Table of Contents} 71 | \def\corollaryname{Corollary} 72 | \def\definitionname{Definition} 73 | \def\examplename{Example} 74 | \def\exercisename{Exercise} 75 | \def\figurename{Fig.} 76 | \def\keywordname{{\bf Key words:}} 77 | \def\indexname{Index} 78 | \def\lemmaname{Lemma} 79 | \def\contriblistname{List of Contributors} 80 | \def\listfigurename{List of Figures} 81 | \def\listtablename{List of Tables} 82 | \def\mailname{{\it Correspondence to\/}:} 83 | \def\noteaddname{Note added in proof} 84 | \def\notename{Note} 85 | \def\partname{Part} 86 | \def\problemname{Problem} 87 | \def\proofname{Proof} 88 | \def\propertyname{Property} 89 | \def\propositionname{Proposition} 90 | \def\questionname{Question} 91 | \def\remarkname{Remark} 92 | \def\seename{see} 93 | \def\solutionname{Solution} 94 | \def\subclassname{{\it Subject Classifications\/}:} 95 | \def\tablename{Table} 96 | \def\theoremname{Theorem}} 97 | \switcht@albion 98 | % Names of theorem like environments are already defined 99 | % but must be translated if another language is chosen 100 | % 101 | % French section 102 | \def\switcht@francais{%\typeout{On parle francais.}% 103 | \def\abstractname{R\'esum\'e.}% 104 | \def\ackname{Remerciements.}% 105 | \def\andname{et}% 106 | \def\lastandname{ et}% 107 | \def\appendixname{Appendice} 108 | \def\chaptername{Chapitre}% 109 | \def\claimname{Pr\'etention}% 110 | \def\conjecturename{Hypoth\`ese}% 111 | \def\contentsname{Table des mati\`eres}% 112 | \def\corollaryname{Corollaire}% 113 | \def\definitionname{D\'efinition}% 114 | \def\examplename{Exemple}% 115 | \def\exercisename{Exercice}% 116 | \def\figurename{Fig.}% 117 | \def\keywordname{{\bf Mots-cl\'e:}} 118 | \def\indexname{Index} 119 | \def\lemmaname{Lemme}% 120 | \def\contriblistname{Liste des contributeurs} 121 | \def\listfigurename{Liste des figures}% 122 | \def\listtablename{Liste des tables}% 123 | \def\mailname{{\it Correspondence to\/}:} 124 | \def\noteaddname{Note ajout\'ee \`a l'\'epreuve}% 125 | \def\notename{Remarque}% 126 | \def\partname{Partie}% 127 | \def\problemname{Probl\`eme}% 128 | \def\proofname{Preuve}% 129 | \def\propertyname{Caract\'eristique}% 130 | %\def\propositionname{Proposition}% 131 | \def\questionname{Question}% 132 | \def\remarkname{Remarque}% 133 | \def\seename{voir} 134 | \def\solutionname{Solution}% 135 | \def\subclassname{{\it Subject Classifications\/}:} 136 | \def\tablename{Tableau}% 137 | \def\theoremname{Th\'eor\`eme}% 138 | } 139 | % 140 | % German section 141 | \def\switcht@deutsch{%\typeout{Man spricht deutsch.}% 142 | \def\abstractname{Zusammenfassung.}% 143 | \def\ackname{Danksagung.}% 144 | \def\andname{und}% 145 | \def\lastandname{ und}% 146 | \def\appendixname{Anhang}% 147 | \def\chaptername{Kapitel}% 148 | \def\claimname{Behauptung}% 149 | \def\conjecturename{Hypothese}% 150 | \def\contentsname{Inhaltsverzeichnis}% 151 | \def\corollaryname{Korollar}% 152 | %\def\definitionname{Definition}% 153 | \def\examplename{Beispiel}% 154 | \def\exercisename{\"Ubung}% 155 | \def\figurename{Abb.}% 156 | \def\keywordname{{\bf Schl\"usselw\"orter:}} 157 | \def\indexname{Index} 158 | %\def\lemmaname{Lemma}% 159 | \def\contriblistname{Mitarbeiter} 160 | \def\listfigurename{Abbildungsverzeichnis}% 161 | \def\listtablename{Tabellenverzeichnis}% 162 | \def\mailname{{\it Correspondence to\/}:} 163 | \def\noteaddname{Nachtrag}% 164 | \def\notename{Anmerkung}% 165 | \def\partname{Teil}% 166 | %\def\problemname{Problem}% 167 | \def\proofname{Beweis}% 168 | \def\propertyname{Eigenschaft}% 169 | %\def\propositionname{Proposition}% 170 | \def\questionname{Frage}% 171 | \def\remarkname{Anmerkung}% 172 | \def\seename{siehe} 173 | \def\solutionname{L\"osung}% 174 | \def\subclassname{{\it Subject Classifications\/}:} 175 | \def\tablename{Tabelle}% 176 | %\def\theoremname{Theorem}% 177 | } 178 | 179 | % Ragged bottom for the actual page 180 | \def\thisbottomragged{\def\@textbottom{\vskip\z@ plus.0001fil 181 | \global\let\@textbottom\relax}} 182 | 183 | \renewcommand\small{% 184 | \@setfontsize\small\@ixpt{11}% 185 | \abovedisplayskip 8.5\p@ \@plus3\p@ \@minus4\p@ 186 | \abovedisplayshortskip \z@ \@plus2\p@ 187 | \belowdisplayshortskip 4\p@ \@plus2\p@ \@minus2\p@ 188 | \def\@listi{\leftmargin\leftmargini 189 | \parsep 0\p@ \@plus1\p@ \@minus\p@ 190 | \topsep 8\p@ \@plus2\p@ \@minus4\p@ 191 | \itemsep0\p@}% 192 | \belowdisplayskip \abovedisplayskip 193 | } 194 | 195 | \frenchspacing 196 | \widowpenalty=10000 197 | \clubpenalty=10000 198 | 199 | \setlength\oddsidemargin {63\p@} 200 | \setlength\evensidemargin {63\p@} 201 | \setlength\marginparwidth {90\p@} 202 | 203 | \setlength\headsep {16\p@} 204 | 205 | \setlength\footnotesep{7.7\p@} 206 | \setlength\textfloatsep{8mm\@plus 2\p@ \@minus 4\p@} 207 | \setlength\intextsep {8mm\@plus 2\p@ \@minus 2\p@} 208 | 209 | \setcounter{secnumdepth}{2} 210 | 211 | \newcounter {chapter} 212 | \renewcommand\thechapter {\@arabic\c@chapter} 213 | 214 | \newif\if@mainmatter \@mainmattertrue 215 | \newcommand\frontmatter{\cleardoublepage 216 | \@mainmatterfalse\pagenumbering{Roman}} 217 | \newcommand\mainmatter{\cleardoublepage 218 | \@mainmattertrue\pagenumbering{arabic}} 219 | \newcommand\backmatter{\if@openright\cleardoublepage\else\clearpage\fi 220 | \@mainmatterfalse} 221 | 222 | \renewcommand\part{\cleardoublepage 223 | \thispagestyle{empty}% 224 | \if@twocolumn 225 | \onecolumn 226 | \@tempswatrue 227 | \else 228 | \@tempswafalse 229 | \fi 230 | \null\vfil 231 | \secdef\@part\@spart} 232 | 233 | \def\@part[#1]#2{% 234 | \ifnum \c@secnumdepth >-2\relax 235 | \refstepcounter{part}% 236 | \addcontentsline{toc}{part}{\thepart\hspace{1em}#1}% 237 | \else 238 | \addcontentsline{toc}{part}{#1}% 239 | \fi 240 | \markboth{}{}% 241 | {\centering 242 | \interlinepenalty \@M 243 | \normalfont 244 | \ifnum \c@secnumdepth >-2\relax 245 | \huge\bfseries \partname~\thepart 246 | \par 247 | \vskip 20\p@ 248 | \fi 249 | \Huge \bfseries #2\par}% 250 | \@endpart} 251 | \def\@spart#1{% 252 | {\centering 253 | \interlinepenalty \@M 254 | \normalfont 255 | \Huge \bfseries #1\par}% 256 | \@endpart} 257 | \def\@endpart{\vfil\newpage 258 | \if@twoside 259 | \null 260 | \thispagestyle{empty}% 261 | \newpage 262 | \fi 263 | \if@tempswa 264 | \twocolumn 265 | \fi} 266 | 267 | \newcommand\chapter{\clearpage 268 | \thispagestyle{empty}% 269 | \global\@topnum\z@ 270 | \@afterindentfalse 271 | \secdef\@chapter\@schapter} 272 | \def\@chapter[#1]#2{\ifnum \c@secnumdepth >\m@ne 273 | \if@mainmatter 274 | \refstepcounter{chapter}% 275 | \typeout{\@chapapp\space\thechapter.}% 276 | \addcontentsline{toc}{chapter}% 277 | {\protect\numberline{\thechapter}#1}% 278 | \else 279 | \addcontentsline{toc}{chapter}{#1}% 280 | \fi 281 | \else 282 | \addcontentsline{toc}{chapter}{#1}% 283 | \fi 284 | \chaptermark{#1}% 285 | \addtocontents{lof}{\protect\addvspace{10\p@}}% 286 | \addtocontents{lot}{\protect\addvspace{10\p@}}% 287 | \if@twocolumn 288 | \@topnewpage[\@makechapterhead{#2}]% 289 | \else 290 | \@makechapterhead{#2}% 291 | \@afterheading 292 | \fi} 293 | \def\@makechapterhead#1{% 294 | % \vspace*{50\p@}% 295 | {\centering 296 | \ifnum \c@secnumdepth >\m@ne 297 | \if@mainmatter 298 | \large\bfseries \@chapapp{} \thechapter 299 | \par\nobreak 300 | \vskip 20\p@ 301 | \fi 302 | \fi 303 | \interlinepenalty\@M 304 | \Large \bfseries #1\par\nobreak 305 | \vskip 40\p@ 306 | }} 307 | \def\@schapter#1{\if@twocolumn 308 | \@topnewpage[\@makeschapterhead{#1}]% 309 | \else 310 | \@makeschapterhead{#1}% 311 | \@afterheading 312 | \fi} 313 | \def\@makeschapterhead#1{% 314 | % \vspace*{50\p@}% 315 | {\centering 316 | \normalfont 317 | \interlinepenalty\@M 318 | \Large \bfseries #1\par\nobreak 319 | \vskip 40\p@ 320 | }} 321 | 322 | \renewcommand\section{\@startsection{section}{1}{\z@}% 323 | {-18\p@ \@plus -4\p@ \@minus -4\p@}% 324 | {12\p@ \@plus 4\p@ \@minus 4\p@}% 325 | {\normalfont\large\bfseries\boldmath 326 | \rightskip=\z@ \@plus 8em\pretolerance=10000 }} 327 | \renewcommand\subsection{\@startsection{subsection}{2}{\z@}% 328 | {-18\p@ \@plus -4\p@ \@minus -4\p@}% 329 | {8\p@ \@plus 4\p@ \@minus 4\p@}% 330 | {\normalfont\normalsize\bfseries\boldmath 331 | \rightskip=\z@ \@plus 8em\pretolerance=10000 }} 332 | \renewcommand\subsubsection{\@startsection{subsubsection}{3}{\z@}% 333 | {-18\p@ \@plus -4\p@ \@minus -4\p@}% 334 | {-0.5em \@plus -0.22em \@minus -0.1em}% 335 | {\normalfont\normalsize\bfseries\boldmath}} 336 | \renewcommand\paragraph{\@startsection{paragraph}{4}{\z@}% 337 | {-12\p@ \@plus -4\p@ \@minus -4\p@}% 338 | {-0.5em \@plus -0.22em \@minus -0.1em}% 339 | {\normalfont\normalsize\itshape}} 340 | \renewcommand\subparagraph[1]{\typeout{LLNCS warning: You should not use 341 | \string\subparagraph\space with this class}\vskip0.5cm 342 | You should not use \verb|\subparagraph| with this class.\vskip0.5cm} 343 | 344 | \DeclareMathSymbol{\Gamma}{\mathalpha}{letters}{"00} 345 | \DeclareMathSymbol{\Delta}{\mathalpha}{letters}{"01} 346 | \DeclareMathSymbol{\Theta}{\mathalpha}{letters}{"02} 347 | \DeclareMathSymbol{\Lambda}{\mathalpha}{letters}{"03} 348 | \DeclareMathSymbol{\Xi}{\mathalpha}{letters}{"04} 349 | \DeclareMathSymbol{\Pi}{\mathalpha}{letters}{"05} 350 | \DeclareMathSymbol{\Sigma}{\mathalpha}{letters}{"06} 351 | \DeclareMathSymbol{\Upsilon}{\mathalpha}{letters}{"07} 352 | \DeclareMathSymbol{\Phi}{\mathalpha}{letters}{"08} 353 | \DeclareMathSymbol{\Psi}{\mathalpha}{letters}{"09} 354 | \DeclareMathSymbol{\Omega}{\mathalpha}{letters}{"0A} 355 | 356 | \let\footnotesize\small 357 | 358 | \if@custvec 359 | \def\vec#1{\mathchoice{\mbox{\boldmath$\displaystyle#1$}} 360 | {\mbox{\boldmath$\textstyle#1$}} 361 | {\mbox{\boldmath$\scriptstyle#1$}} 362 | {\mbox{\boldmath$\scriptscriptstyle#1$}}} 363 | \fi 364 | 365 | \def\squareforqed{\hbox{\rlap{$\sqcap$}$\sqcup$}} 366 | \def\qed{\ifmmode\squareforqed\else{\unskip\nobreak\hfil 367 | \penalty50\hskip1em\null\nobreak\hfil\squareforqed 368 | \parfillskip=0pt\finalhyphendemerits=0\endgraf}\fi} 369 | 370 | \def\getsto{\mathrel{\mathchoice {\vcenter{\offinterlineskip 371 | \halign{\hfil 372 | $\displaystyle##$\hfil\cr\gets\cr\to\cr}}} 373 | {\vcenter{\offinterlineskip\halign{\hfil$\textstyle##$\hfil\cr\gets 374 | \cr\to\cr}}} 375 | {\vcenter{\offinterlineskip\halign{\hfil$\scriptstyle##$\hfil\cr\gets 376 | \cr\to\cr}}} 377 | {\vcenter{\offinterlineskip\halign{\hfil$\scriptscriptstyle##$\hfil\cr 378 | \gets\cr\to\cr}}}}} 379 | \def\lid{\mathrel{\mathchoice {\vcenter{\offinterlineskip\halign{\hfil 380 | $\displaystyle##$\hfil\cr<\cr\noalign{\vskip1.2pt}=\cr}}} 381 | {\vcenter{\offinterlineskip\halign{\hfil$\textstyle##$\hfil\cr<\cr 382 | \noalign{\vskip1.2pt}=\cr}}} 383 | {\vcenter{\offinterlineskip\halign{\hfil$\scriptstyle##$\hfil\cr<\cr 384 | \noalign{\vskip1pt}=\cr}}} 385 | {\vcenter{\offinterlineskip\halign{\hfil$\scriptscriptstyle##$\hfil\cr 386 | <\cr 387 | \noalign{\vskip0.9pt}=\cr}}}}} 388 | \def\gid{\mathrel{\mathchoice {\vcenter{\offinterlineskip\halign{\hfil 389 | $\displaystyle##$\hfil\cr>\cr\noalign{\vskip1.2pt}=\cr}}} 390 | {\vcenter{\offinterlineskip\halign{\hfil$\textstyle##$\hfil\cr>\cr 391 | \noalign{\vskip1.2pt}=\cr}}} 392 | {\vcenter{\offinterlineskip\halign{\hfil$\scriptstyle##$\hfil\cr>\cr 393 | \noalign{\vskip1pt}=\cr}}} 394 | {\vcenter{\offinterlineskip\halign{\hfil$\scriptscriptstyle##$\hfil\cr 395 | >\cr 396 | \noalign{\vskip0.9pt}=\cr}}}}} 397 | \def\grole{\mathrel{\mathchoice {\vcenter{\offinterlineskip 398 | \halign{\hfil 399 | $\displaystyle##$\hfil\cr>\cr\noalign{\vskip-1pt}<\cr}}} 400 | {\vcenter{\offinterlineskip\halign{\hfil$\textstyle##$\hfil\cr 401 | >\cr\noalign{\vskip-1pt}<\cr}}} 402 | {\vcenter{\offinterlineskip\halign{\hfil$\scriptstyle##$\hfil\cr 403 | >\cr\noalign{\vskip-0.8pt}<\cr}}} 404 | {\vcenter{\offinterlineskip\halign{\hfil$\scriptscriptstyle##$\hfil\cr 405 | >\cr\noalign{\vskip-0.3pt}<\cr}}}}} 406 | \def\bbbr{{\rm I\!R}} %reelle Zahlen 407 | \def\bbbm{{\rm I\!M}} 408 | \def\bbbn{{\rm I\!N}} %natuerliche Zahlen 409 | \def\bbbf{{\rm I\!F}} 410 | \def\bbbh{{\rm I\!H}} 411 | \def\bbbk{{\rm I\!K}} 412 | \def\bbbp{{\rm I\!P}} 413 | \def\bbbone{{\mathchoice {\rm 1\mskip-4mu l} {\rm 1\mskip-4mu l} 414 | {\rm 1\mskip-4.5mu l} {\rm 1\mskip-5mu l}}} 415 | \def\bbbc{{\mathchoice {\setbox0=\hbox{$\displaystyle\rm C$}\hbox{\hbox 416 | to0pt{\kern0.4\wd0\vrule height0.9\ht0\hss}\box0}} 417 | {\setbox0=\hbox{$\textstyle\rm C$}\hbox{\hbox 418 | to0pt{\kern0.4\wd0\vrule height0.9\ht0\hss}\box0}} 419 | {\setbox0=\hbox{$\scriptstyle\rm C$}\hbox{\hbox 420 | to0pt{\kern0.4\wd0\vrule height0.9\ht0\hss}\box0}} 421 | {\setbox0=\hbox{$\scriptscriptstyle\rm C$}\hbox{\hbox 422 | to0pt{\kern0.4\wd0\vrule height0.9\ht0\hss}\box0}}}} 423 | \def\bbbq{{\mathchoice {\setbox0=\hbox{$\displaystyle\rm 424 | Q$}\hbox{\raise 425 | 0.15\ht0\hbox to0pt{\kern0.4\wd0\vrule height0.8\ht0\hss}\box0}} 426 | {\setbox0=\hbox{$\textstyle\rm Q$}\hbox{\raise 427 | 0.15\ht0\hbox to0pt{\kern0.4\wd0\vrule height0.8\ht0\hss}\box0}} 428 | {\setbox0=\hbox{$\scriptstyle\rm Q$}\hbox{\raise 429 | 0.15\ht0\hbox to0pt{\kern0.4\wd0\vrule height0.7\ht0\hss}\box0}} 430 | {\setbox0=\hbox{$\scriptscriptstyle\rm Q$}\hbox{\raise 431 | 0.15\ht0\hbox to0pt{\kern0.4\wd0\vrule height0.7\ht0\hss}\box0}}}} 432 | \def\bbbt{{\mathchoice {\setbox0=\hbox{$\displaystyle\rm 433 | T$}\hbox{\hbox to0pt{\kern0.3\wd0\vrule height0.9\ht0\hss}\box0}} 434 | {\setbox0=\hbox{$\textstyle\rm T$}\hbox{\hbox 435 | to0pt{\kern0.3\wd0\vrule height0.9\ht0\hss}\box0}} 436 | {\setbox0=\hbox{$\scriptstyle\rm T$}\hbox{\hbox 437 | to0pt{\kern0.3\wd0\vrule height0.9\ht0\hss}\box0}} 438 | {\setbox0=\hbox{$\scriptscriptstyle\rm T$}\hbox{\hbox 439 | to0pt{\kern0.3\wd0\vrule height0.9\ht0\hss}\box0}}}} 440 | \def\bbbs{{\mathchoice 441 | {\setbox0=\hbox{$\displaystyle \rm S$}\hbox{\raise0.5\ht0\hbox 442 | to0pt{\kern0.35\wd0\vrule height0.45\ht0\hss}\hbox 443 | to0pt{\kern0.55\wd0\vrule height0.5\ht0\hss}\box0}} 444 | {\setbox0=\hbox{$\textstyle \rm S$}\hbox{\raise0.5\ht0\hbox 445 | to0pt{\kern0.35\wd0\vrule height0.45\ht0\hss}\hbox 446 | to0pt{\kern0.55\wd0\vrule height0.5\ht0\hss}\box0}} 447 | {\setbox0=\hbox{$\scriptstyle \rm S$}\hbox{\raise0.5\ht0\hbox 448 | to0pt{\kern0.35\wd0\vrule height0.45\ht0\hss}\raise0.05\ht0\hbox 449 | to0pt{\kern0.5\wd0\vrule height0.45\ht0\hss}\box0}} 450 | {\setbox0=\hbox{$\scriptscriptstyle\rm S$}\hbox{\raise0.5\ht0\hbox 451 | to0pt{\kern0.4\wd0\vrule height0.45\ht0\hss}\raise0.05\ht0\hbox 452 | to0pt{\kern0.55\wd0\vrule height0.45\ht0\hss}\box0}}}} 453 | \def\bbbz{{\mathchoice {\hbox{$\mathsf\textstyle Z\kern-0.4em Z$}} 454 | {\hbox{$\mathsf\textstyle Z\kern-0.4em Z$}} 455 | {\hbox{$\mathsf\scriptstyle Z\kern-0.3em Z$}} 456 | {\hbox{$\mathsf\scriptscriptstyle Z\kern-0.2em Z$}}}} 457 | 458 | \let\ts\, 459 | 460 | \setlength\leftmargini {17\p@} 461 | \setlength\leftmargin {\leftmargini} 462 | \setlength\leftmarginii {\leftmargini} 463 | \setlength\leftmarginiii {\leftmargini} 464 | \setlength\leftmarginiv {\leftmargini} 465 | \setlength \labelsep {.5em} 466 | \setlength \labelwidth{\leftmargini} 467 | \addtolength\labelwidth{-\labelsep} 468 | 469 | \def\@listI{\leftmargin\leftmargini 470 | \parsep 0\p@ \@plus1\p@ \@minus\p@ 471 | \topsep 8\p@ \@plus2\p@ \@minus4\p@ 472 | \itemsep0\p@} 473 | \let\@listi\@listI 474 | \@listi 475 | \def\@listii {\leftmargin\leftmarginii 476 | \labelwidth\leftmarginii 477 | \advance\labelwidth-\labelsep 478 | \topsep 0\p@ \@plus2\p@ \@minus\p@} 479 | \def\@listiii{\leftmargin\leftmarginiii 480 | \labelwidth\leftmarginiii 481 | \advance\labelwidth-\labelsep 482 | \topsep 0\p@ \@plus\p@\@minus\p@ 483 | \parsep \z@ 484 | \partopsep \p@ \@plus\z@ \@minus\p@} 485 | 486 | \renewcommand\labelitemi{\normalfont\bfseries --} 487 | \renewcommand\labelitemii{$\m@th\bullet$} 488 | 489 | \setlength\arraycolsep{1.4\p@} 490 | \setlength\tabcolsep{1.4\p@} 491 | 492 | \def\tableofcontents{\chapter*{\contentsname\@mkboth{{\contentsname}}% 493 | {{\contentsname}}} 494 | \def\authcount##1{\setcounter{auco}{##1}\setcounter{@auth}{1}} 495 | \def\lastand{\ifnum\value{auco}=2\relax 496 | \unskip{} \andname\ 497 | \else 498 | \unskip \lastandname\ 499 | \fi}% 500 | \def\and{\stepcounter{@auth}\relax 501 | \ifnum\value{@auth}=\value{auco}% 502 | \lastand 503 | \else 504 | \unskip, 505 | \fi}% 506 | \@starttoc{toc}\if@restonecol\twocolumn\fi} 507 | 508 | \def\l@part#1#2{\addpenalty{\@secpenalty}% 509 | \addvspace{2em plus\p@}% % space above part line 510 | \begingroup 511 | \parindent \z@ 512 | \rightskip \z@ plus 5em 513 | \hrule\vskip5pt 514 | \large % same size as for a contribution heading 515 | \bfseries\boldmath % set line in boldface 516 | \leavevmode % TeX command to enter horizontal mode. 517 | #1\par 518 | \vskip5pt 519 | \hrule 520 | \vskip1pt 521 | \nobreak % Never break after part entry 522 | \endgroup} 523 | 524 | \def\@dotsep{2} 525 | 526 | \def\hyperhrefextend{\ifx\hyper@anchor\@undefined\else 527 | {chapter.\thechapter}\fi} 528 | 529 | \def\addnumcontentsmark#1#2#3{% 530 | \addtocontents{#1}{\protect\contentsline{#2}{\protect\numberline 531 | {\thechapter}#3}{\thepage}\hyperhrefextend}} 532 | \def\addcontentsmark#1#2#3{% 533 | \addtocontents{#1}{\protect\contentsline{#2}{#3}{\thepage}\hyperhrefextend}} 534 | \def\addcontentsmarkwop#1#2#3{% 535 | \addtocontents{#1}{\protect\contentsline{#2}{#3}{0}\hyperhrefextend}} 536 | 537 | \def\@adcmk[#1]{\ifcase #1 \or 538 | \def\@gtempa{\addnumcontentsmark}% 539 | \or \def\@gtempa{\addcontentsmark}% 540 | \or \def\@gtempa{\addcontentsmarkwop}% 541 | \fi\@gtempa{toc}{chapter}} 542 | \def\addtocmark{\@ifnextchar[{\@adcmk}{\@adcmk[3]}} 543 | 544 | \def\l@chapter#1#2{\addpenalty{-\@highpenalty} 545 | \vskip 1.0em plus 1pt \@tempdima 1.5em \begingroup 546 | \parindent \z@ \rightskip \@tocrmarg 547 | \advance\rightskip by 0pt plus 2cm 548 | \parfillskip -\rightskip \pretolerance=10000 549 | \leavevmode \advance\leftskip\@tempdima \hskip -\leftskip 550 | {\large\bfseries\boldmath#1}\ifx0#2\hfil\null 551 | \else 552 | \nobreak 553 | \leaders\hbox{$\m@th \mkern \@dotsep mu.\mkern 554 | \@dotsep mu$}\hfill 555 | \nobreak\hbox to\@pnumwidth{\hss #2}% 556 | \fi\par 557 | \penalty\@highpenalty \endgroup} 558 | 559 | \def\l@title#1#2{\addpenalty{-\@highpenalty} 560 | \addvspace{8pt plus 1pt} 561 | \@tempdima \z@ 562 | \begingroup 563 | \parindent \z@ \rightskip \@tocrmarg 564 | \advance\rightskip by 0pt plus 2cm 565 | \parfillskip -\rightskip \pretolerance=10000 566 | \leavevmode \advance\leftskip\@tempdima \hskip -\leftskip 567 | #1\nobreak 568 | \leaders\hbox{$\m@th \mkern \@dotsep mu.\mkern 569 | \@dotsep mu$}\hfill 570 | \nobreak\hbox to\@pnumwidth{\hss #2}\par 571 | \penalty\@highpenalty \endgroup} 572 | 573 | \def\l@author#1#2{\addpenalty{\@highpenalty} 574 | \@tempdima=\z@ %15\p@ 575 | \begingroup 576 | \parindent \z@ \rightskip \@tocrmarg 577 | \advance\rightskip by 0pt plus 2cm 578 | \pretolerance=10000 579 | \leavevmode \advance\leftskip\@tempdima %\hskip -\leftskip 580 | \textit{#1}\par 581 | \penalty\@highpenalty \endgroup} 582 | 583 | \setcounter{tocdepth}{0} 584 | \newdimen\tocchpnum 585 | \newdimen\tocsecnum 586 | \newdimen\tocsectotal 587 | \newdimen\tocsubsecnum 588 | \newdimen\tocsubsectotal 589 | \newdimen\tocsubsubsecnum 590 | \newdimen\tocsubsubsectotal 591 | \newdimen\tocparanum 592 | \newdimen\tocparatotal 593 | \newdimen\tocsubparanum 594 | \tocchpnum=\z@ % no chapter numbers 595 | \tocsecnum=15\p@ % section 88. plus 2.222pt 596 | \tocsubsecnum=23\p@ % subsection 88.8 plus 2.222pt 597 | \tocsubsubsecnum=27\p@ % subsubsection 88.8.8 plus 1.444pt 598 | \tocparanum=35\p@ % paragraph 88.8.8.8 plus 1.666pt 599 | \tocsubparanum=43\p@ % subparagraph 88.8.8.8.8 plus 1.888pt 600 | \def\calctocindent{% 601 | \tocsectotal=\tocchpnum 602 | \advance\tocsectotal by\tocsecnum 603 | \tocsubsectotal=\tocsectotal 604 | \advance\tocsubsectotal by\tocsubsecnum 605 | \tocsubsubsectotal=\tocsubsectotal 606 | \advance\tocsubsubsectotal by\tocsubsubsecnum 607 | \tocparatotal=\tocsubsubsectotal 608 | \advance\tocparatotal by\tocparanum} 609 | \calctocindent 610 | 611 | \def\l@section{\@dottedtocline{1}{\tocchpnum}{\tocsecnum}} 612 | \def\l@subsection{\@dottedtocline{2}{\tocsectotal}{\tocsubsecnum}} 613 | \def\l@subsubsection{\@dottedtocline{3}{\tocsubsectotal}{\tocsubsubsecnum}} 614 | \def\l@paragraph{\@dottedtocline{4}{\tocsubsubsectotal}{\tocparanum}} 615 | \def\l@subparagraph{\@dottedtocline{5}{\tocparatotal}{\tocsubparanum}} 616 | 617 | \def\listoffigures{\@restonecolfalse\if@twocolumn\@restonecoltrue\onecolumn 618 | \fi\section*{\listfigurename\@mkboth{{\listfigurename}}{{\listfigurename}}} 619 | \@starttoc{lof}\if@restonecol\twocolumn\fi} 620 | \def\l@figure{\@dottedtocline{1}{0em}{1.5em}} 621 | 622 | \def\listoftables{\@restonecolfalse\if@twocolumn\@restonecoltrue\onecolumn 623 | \fi\section*{\listtablename\@mkboth{{\listtablename}}{{\listtablename}}} 624 | \@starttoc{lot}\if@restonecol\twocolumn\fi} 625 | \let\l@table\l@figure 626 | 627 | \renewcommand\listoffigures{% 628 | \section*{\listfigurename 629 | \@mkboth{\listfigurename}{\listfigurename}}% 630 | \@starttoc{lof}% 631 | } 632 | 633 | \renewcommand\listoftables{% 634 | \section*{\listtablename 635 | \@mkboth{\listtablename}{\listtablename}}% 636 | \@starttoc{lot}% 637 | } 638 | 639 | \ifx\oribibl\undefined 640 | \ifx\citeauthoryear\undefined 641 | \renewenvironment{thebibliography}[1] 642 | {\section*{\refname} 643 | \def\@biblabel##1{##1.} 644 | \small 645 | \list{\@biblabel{\@arabic\c@enumiv}}% 646 | {\settowidth\labelwidth{\@biblabel{#1}}% 647 | \leftmargin\labelwidth 648 | \advance\leftmargin\labelsep 649 | \if@openbib 650 | \advance\leftmargin\bibindent 651 | \itemindent -\bibindent 652 | \listparindent \itemindent 653 | \parsep \z@ 654 | \fi 655 | \usecounter{enumiv}% 656 | \let\p@enumiv\@empty 657 | \renewcommand\theenumiv{\@arabic\c@enumiv}}% 658 | \if@openbib 659 | \renewcommand\newblock{\par}% 660 | \else 661 | \renewcommand\newblock{\hskip .11em \@plus.33em \@minus.07em}% 662 | \fi 663 | \sloppy\clubpenalty4000\widowpenalty4000% 664 | \sfcode`\.=\@m} 665 | {\def\@noitemerr 666 | {\@latex@warning{Empty `thebibliography' environment}}% 667 | \endlist} 668 | \def\@lbibitem[#1]#2{\item[{[#1]}\hfill]\if@filesw 669 | {\let\protect\noexpand\immediate 670 | \write\@auxout{\string\bibcite{#2}{#1}}}\fi\ignorespaces} 671 | \newcount\@tempcntc 672 | \def\@citex[#1]#2{\if@filesw\immediate\write\@auxout{\string\citation{#2}}\fi 673 | \@tempcnta\z@\@tempcntb\m@ne\def\@citea{}\@cite{\@for\@citeb:=#2\do 674 | {\@ifundefined 675 | {b@\@citeb}{\@citeo\@tempcntb\m@ne\@citea\def\@citea{,}{\bfseries 676 | ?}\@warning 677 | {Citation `\@citeb' on page \thepage \space undefined}}% 678 | {\setbox\z@\hbox{\global\@tempcntc0\csname b@\@citeb\endcsname\relax}% 679 | \ifnum\@tempcntc=\z@ \@citeo\@tempcntb\m@ne 680 | \@citea\def\@citea{,}\hbox{\csname b@\@citeb\endcsname}% 681 | \else 682 | \advance\@tempcntb\@ne 683 | \ifnum\@tempcntb=\@tempcntc 684 | \else\advance\@tempcntb\m@ne\@citeo 685 | \@tempcnta\@tempcntc\@tempcntb\@tempcntc\fi\fi}}\@citeo}{#1}} 686 | \def\@citeo{\ifnum\@tempcnta>\@tempcntb\else 687 | \@citea\def\@citea{,\,\hskip\z@skip}% 688 | \ifnum\@tempcnta=\@tempcntb\the\@tempcnta\else 689 | {\advance\@tempcnta\@ne\ifnum\@tempcnta=\@tempcntb \else 690 | \def\@citea{--}\fi 691 | \advance\@tempcnta\m@ne\the\@tempcnta\@citea\the\@tempcntb}\fi\fi} 692 | \else 693 | \renewenvironment{thebibliography}[1] 694 | {\section*{\refname} 695 | \small 696 | \list{}% 697 | {\settowidth\labelwidth{}% 698 | \leftmargin\parindent 699 | \itemindent=-\parindent 700 | \labelsep=\z@ 701 | \if@openbib 702 | \advance\leftmargin\bibindent 703 | \itemindent -\bibindent 704 | \listparindent \itemindent 705 | \parsep \z@ 706 | \fi 707 | \usecounter{enumiv}% 708 | \let\p@enumiv\@empty 709 | \renewcommand\theenumiv{}}% 710 | \if@openbib 711 | \renewcommand\newblock{\par}% 712 | \else 713 | \renewcommand\newblock{\hskip .11em \@plus.33em \@minus.07em}% 714 | \fi 715 | \sloppy\clubpenalty4000\widowpenalty4000% 716 | \sfcode`\.=\@m} 717 | {\def\@noitemerr 718 | {\@latex@warning{Empty `thebibliography' environment}}% 719 | \endlist} 720 | \def\@cite#1{#1}% 721 | \def\@lbibitem[#1]#2{\item[]\if@filesw 722 | {\def\protect##1{\string ##1\space}\immediate 723 | \write\@auxout{\string\bibcite{#2}{#1}}}\fi\ignorespaces} 724 | \fi 725 | \else 726 | \@cons\@openbib@code{\noexpand\small} 727 | \fi 728 | 729 | \def\idxquad{\hskip 10\p@}% space that divides entry from number 730 | 731 | \def\@idxitem{\par\hangindent 10\p@} 732 | 733 | \def\subitem{\par\setbox0=\hbox{--\enspace}% second order 734 | \noindent\hangindent\wd0\box0}% index entry 735 | 736 | \def\subsubitem{\par\setbox0=\hbox{--\,--\enspace}% third 737 | \noindent\hangindent\wd0\box0}% order index entry 738 | 739 | \def\indexspace{\par \vskip 10\p@ plus5\p@ minus3\p@\relax} 740 | 741 | \renewenvironment{theindex} 742 | {\@mkboth{\indexname}{\indexname}% 743 | \thispagestyle{empty}\parindent\z@ 744 | \parskip\z@ \@plus .3\p@\relax 745 | \let\item\par 746 | \def\,{\relax\ifmmode\mskip\thinmuskip 747 | \else\hskip0.2em\ignorespaces\fi}% 748 | \normalfont\small 749 | \begin{multicols}{2}[\@makeschapterhead{\indexname}]% 750 | } 751 | {\end{multicols}} 752 | 753 | \renewcommand\footnoterule{% 754 | \kern-3\p@ 755 | \hrule\@width 2truecm 756 | \kern2.6\p@} 757 | \newdimen\fnindent 758 | \fnindent1em 759 | \long\def\@makefntext#1{% 760 | \parindent \fnindent% 761 | \leftskip \fnindent% 762 | \noindent 763 | \llap{\hb@xt@1em{\hss\@makefnmark\ }}\ignorespaces#1} 764 | 765 | \long\def\@makecaption#1#2{% 766 | \vskip\abovecaptionskip 767 | \sbox\@tempboxa{{\bfseries #1.} #2}% 768 | \ifdim \wd\@tempboxa >\hsize 769 | {\bfseries #1.} #2\par 770 | \else 771 | \global \@minipagefalse 772 | \hb@xt@\hsize{\hfil\box\@tempboxa\hfil}% 773 | \fi 774 | \vskip\belowcaptionskip} 775 | 776 | \def\fps@figure{htbp} 777 | \def\fnum@figure{\figurename\thinspace\thefigure} 778 | \def \@floatboxreset {% 779 | \reset@font 780 | \small 781 | \@setnobreak 782 | \@setminipage 783 | } 784 | \def\fps@table{htbp} 785 | \def\fnum@table{\tablename~\thetable} 786 | \renewenvironment{table} 787 | {\setlength\abovecaptionskip{0\p@}% 788 | \setlength\belowcaptionskip{10\p@}% 789 | \@float{table}} 790 | {\end@float} 791 | \renewenvironment{table*} 792 | {\setlength\abovecaptionskip{0\p@}% 793 | \setlength\belowcaptionskip{10\p@}% 794 | \@dblfloat{table}} 795 | {\end@dblfloat} 796 | 797 | \long\def\@caption#1[#2]#3{\par\addcontentsline{\csname 798 | ext@#1\endcsname}{#1}{\protect\numberline{\csname 799 | the#1\endcsname}{\ignorespaces #2}}\begingroup 800 | \@parboxrestore 801 | \@makecaption{\csname fnum@#1\endcsname}{\ignorespaces #3}\par 802 | \endgroup} 803 | 804 | % LaTeX does not provide a command to enter the authors institute 805 | % addresses. The \institute command is defined here. 806 | 807 | \newcounter{@inst} 808 | \newcounter{@auth} 809 | \newcounter{auco} 810 | \newdimen\instindent 811 | \newbox\authrun 812 | \newtoks\authorrunning 813 | \newtoks\tocauthor 814 | \newbox\titrun 815 | \newtoks\titlerunning 816 | \newtoks\toctitle 817 | 818 | \def\clearheadinfo{\gdef\@author{No Author Given}% 819 | \gdef\@title{No Title Given}% 820 | \gdef\@subtitle{}% 821 | \gdef\@institute{No Institute Given}% 822 | \gdef\@thanks{}% 823 | \global\titlerunning={}\global\authorrunning={}% 824 | \global\toctitle={}\global\tocauthor={}} 825 | 826 | \def\institute#1{\gdef\@institute{#1}} 827 | 828 | \def\institutename{\par 829 | \begingroup 830 | \parskip=\z@ 831 | \parindent=\z@ 832 | \setcounter{@inst}{1}% 833 | \def\and{\par\stepcounter{@inst}% 834 | \noindent$^{\the@inst}$\enspace\ignorespaces}% 835 | \setbox0=\vbox{\def\thanks##1{}\@institute}% 836 | \ifnum\c@@inst=1\relax 837 | \else 838 | \setcounter{footnote}{\c@@inst}% 839 | \setcounter{@inst}{1}% 840 | \noindent$^{\the@inst}$\enspace 841 | \fi 842 | \ignorespaces 843 | \@institute\par 844 | \endgroup} 845 | 846 | \def\@fnsymbol#1{\ensuremath{\ifcase#1\or\star\or{\star\star}\or 847 | {\star\star\star}\or \dagger\or \ddagger\or 848 | \mathchar "278\or \mathchar "27B\or \|\or **\or \dagger\dagger 849 | \or \ddagger\ddagger \else\@ctrerr\fi}} 850 | 851 | \def\inst#1{\unskip$^{#1}$} 852 | \def\fnmsep{\unskip$^,$} 853 | \def\email#1{{\tt#1}} 854 | \AtBeginDocument{\@ifundefined{url}{\def\url#1{#1}}{}% 855 | \@ifpackageloaded{babel}{% 856 | \@ifundefined{extrasenglish}{}{\addto\extrasenglish{\switcht@albion}}% 857 | \@ifundefined{extrasfrenchb}{}{\addto\extrasfrenchb{\switcht@francais}}% 858 | \@ifundefined{extrasgerman}{}{\addto\extrasgerman{\switcht@deutsch}}% 859 | }{\switcht@@therlang}% 860 | } 861 | \def\homedir{\~{ }} 862 | 863 | \def\subtitle#1{\gdef\@subtitle{#1}} 864 | \clearheadinfo 865 | 866 | \renewcommand\maketitle{\newpage 867 | \refstepcounter{chapter}% 868 | \stepcounter{section}% 869 | \setcounter{section}{0}% 870 | \setcounter{subsection}{0}% 871 | \setcounter{figure}{0} 872 | \setcounter{table}{0} 873 | \setcounter{equation}{0} 874 | \setcounter{footnote}{0}% 875 | \begingroup 876 | \parindent=\z@ 877 | \renewcommand\thefootnote{\@fnsymbol\c@footnote}% 878 | \if@twocolumn 879 | \ifnum \col@number=\@ne 880 | \@maketitle 881 | \else 882 | \twocolumn[\@maketitle]% 883 | \fi 884 | \else 885 | \newpage 886 | \global\@topnum\z@ % Prevents figures from going at top of page. 887 | \@maketitle 888 | \fi 889 | \thispagestyle{empty}\@thanks 890 | % 891 | \def\\{\unskip\ \ignorespaces}\def\inst##1{\unskip{}}% 892 | \def\thanks##1{\unskip{}}\def\fnmsep{\unskip}% 893 | \instindent=\hsize 894 | \advance\instindent by-\headlineindent 895 | \if!\the\toctitle!\addcontentsline{toc}{title}{\@title}\else 896 | \addcontentsline{toc}{title}{\the\toctitle}\fi 897 | \if@runhead 898 | \if!\the\titlerunning!\else 899 | \edef\@title{\the\titlerunning}% 900 | \fi 901 | 902 | \global\setbox\titrun=\hbox{\small\rm\unboldmath\ignorespaces\@title}% 903 | \ifdim\wd\titrun>\instindent 904 | \typeout{Title too long for running head. Please supply}% 905 | \typeout{a shorter form with \string\titlerunning\space prior to 906 | \string\maketitle}% 907 | \global\setbox\titrun=\hbox{\small\rm 908 | Title Suppressed Due to Excessive Length}% 909 | \fi 910 | \xdef\@title{\copy\titrun}% 911 | \fi 912 | % 913 | \if!\the\tocauthor!\relax 914 | {\def\and{\noexpand\protect\noexpand\and}% 915 | \protected@xdef\toc@uthor{\@author}}% 916 | \else 917 | \def\\{\noexpand\protect\noexpand\newline}% 918 | \protected@xdef\scratch{\the\tocauthor}% 919 | \protected@xdef\toc@uthor{\scratch}% 920 | \fi 921 | \addcontentsline{toc}{author}{\toc@uthor}% 922 | \if@runhead 923 | \if!\the\authorrunning! 924 | \value{@inst}=\value{@auth}% 925 | \setcounter{@auth}{1}% 926 | \else 927 | \edef\@author{\the\authorrunning}% 928 | \fi 929 | \global\setbox\authrun=\hbox{\small\unboldmath\@author\unskip}% 930 | \ifdim\wd\authrun>\instindent 931 | \typeout{Names of authors too long for running head. Please 932 | supply}% 933 | \typeout{a shorter form with \string\authorrunning\space prior to 934 | \string\maketitle}% 935 | \global\setbox\authrun=\hbox{\small\rm 936 | Authors Suppressed Due to Excessive Length}% 937 | \fi 938 | \xdef\@author{\copy\authrun}% 939 | \markboth{\@author}{\@title}% 940 | \fi 941 | \endgroup 942 | \setcounter{footnote}{0}% 943 | \clearheadinfo} 944 | % 945 | \def\@maketitle{\newpage 946 | \markboth{}{}% 947 | \def\lastand{\ifnum\value{@inst}=2\relax 948 | \unskip{} \andname\ 949 | \else 950 | \unskip \lastandname\ 951 | \fi}% 952 | \def\and{\stepcounter{@auth}\relax 953 | \ifnum\value{@auth}=\value{@inst}% 954 | \lastand 955 | \else 956 | \unskip, 957 | \fi}% 958 | \begin{center}% 959 | \let\newline\\ 960 | {\Large \bfseries\boldmath 961 | \pretolerance=10000 962 | \@title \par}\vskip .8cm 963 | \if!\@subtitle!\else {\large \bfseries\boldmath 964 | \vskip -.65cm 965 | \pretolerance=10000 966 | \@subtitle \par}\vskip .8cm\fi 967 | \setbox0=\vbox{\setcounter{@auth}{1}\def\and{\stepcounter{@auth}}% 968 | \def\thanks##1{}\@author}% 969 | \global\value{@inst}=\value{@auth}% 970 | \global\value{auco}=\value{@auth}% 971 | \setcounter{@auth}{1}% 972 | {\lineskip .5em 973 | \noindent\ignorespaces 974 | \@author\vskip.35cm} 975 | {\small\institutename} 976 | \end{center}% 977 | } 978 | 979 | % definition of the "\spnewtheorem" command. 980 | % 981 | % Usage: 982 | % 983 | % \spnewtheorem{env_nam}{caption}[within]{cap_font}{body_font} 984 | % or \spnewtheorem{env_nam}[numbered_like]{caption}{cap_font}{body_font} 985 | % or \spnewtheorem*{env_nam}{caption}{cap_font}{body_font} 986 | % 987 | % New is "cap_font" and "body_font". It stands for 988 | % fontdefinition of the caption and the text itself. 989 | % 990 | % "\spnewtheorem*" gives a theorem without number. 991 | % 992 | % A defined spnewthoerem environment is used as described 993 | % by Lamport. 994 | % 995 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 996 | 997 | \def\@thmcountersep{} 998 | \def\@thmcounterend{.} 999 | 1000 | \def\spnewtheorem{\@ifstar{\@sthm}{\@Sthm}} 1001 | 1002 | % definition of \spnewtheorem with number 1003 | 1004 | \def\@spnthm#1#2{% 1005 | \@ifnextchar[{\@spxnthm{#1}{#2}}{\@spynthm{#1}{#2}}} 1006 | \def\@Sthm#1{\@ifnextchar[{\@spothm{#1}}{\@spnthm{#1}}} 1007 | 1008 | \def\@spxnthm#1#2[#3]#4#5{\expandafter\@ifdefinable\csname #1\endcsname 1009 | {\@definecounter{#1}\@addtoreset{#1}{#3}% 1010 | \expandafter\xdef\csname the#1\endcsname{\expandafter\noexpand 1011 | \csname the#3\endcsname \noexpand\@thmcountersep \@thmcounter{#1}}% 1012 | \expandafter\xdef\csname #1name\endcsname{#2}% 1013 | \global\@namedef{#1}{\@spthm{#1}{\csname #1name\endcsname}{#4}{#5}}% 1014 | \global\@namedef{end#1}{\@endtheorem}}} 1015 | 1016 | \def\@spynthm#1#2#3#4{\expandafter\@ifdefinable\csname #1\endcsname 1017 | {\@definecounter{#1}% 1018 | \expandafter\xdef\csname the#1\endcsname{\@thmcounter{#1}}% 1019 | \expandafter\xdef\csname #1name\endcsname{#2}% 1020 | \global\@namedef{#1}{\@spthm{#1}{\csname #1name\endcsname}{#3}{#4}}% 1021 | \global\@namedef{end#1}{\@endtheorem}}} 1022 | 1023 | \def\@spothm#1[#2]#3#4#5{% 1024 | \@ifundefined{c@#2}{\@latexerr{No theorem environment `#2' defined}\@eha}% 1025 | {\expandafter\@ifdefinable\csname #1\endcsname 1026 | {\global\@namedef{the#1}{\@nameuse{the#2}}% 1027 | \expandafter\xdef\csname #1name\endcsname{#3}% 1028 | \global\@namedef{#1}{\@spthm{#2}{\csname #1name\endcsname}{#4}{#5}}% 1029 | \global\@namedef{end#1}{\@endtheorem}}}} 1030 | 1031 | \def\@spthm#1#2#3#4{\topsep 7\p@ \@plus2\p@ \@minus4\p@ 1032 | \refstepcounter{#1}% 1033 | \@ifnextchar[{\@spythm{#1}{#2}{#3}{#4}}{\@spxthm{#1}{#2}{#3}{#4}}} 1034 | 1035 | \def\@spxthm#1#2#3#4{\@spbegintheorem{#2}{\csname the#1\endcsname}{#3}{#4}% 1036 | \ignorespaces} 1037 | 1038 | \def\@spythm#1#2#3#4[#5]{\@spopargbegintheorem{#2}{\csname 1039 | the#1\endcsname}{#5}{#3}{#4}\ignorespaces} 1040 | 1041 | \def\@spbegintheorem#1#2#3#4{\trivlist 1042 | \item[\hskip\labelsep{#3#1\ #2\@thmcounterend}]#4} 1043 | 1044 | \def\@spopargbegintheorem#1#2#3#4#5{\trivlist 1045 | \item[\hskip\labelsep{#4#1\ #2}]{#4(#3)\@thmcounterend\ }#5} 1046 | 1047 | % definition of \spnewtheorem* without number 1048 | 1049 | \def\@sthm#1#2{\@Ynthm{#1}{#2}} 1050 | 1051 | \def\@Ynthm#1#2#3#4{\expandafter\@ifdefinable\csname #1\endcsname 1052 | {\global\@namedef{#1}{\@Thm{\csname #1name\endcsname}{#3}{#4}}% 1053 | \expandafter\xdef\csname #1name\endcsname{#2}% 1054 | \global\@namedef{end#1}{\@endtheorem}}} 1055 | 1056 | \def\@Thm#1#2#3{\topsep 7\p@ \@plus2\p@ \@minus4\p@ 1057 | \@ifnextchar[{\@Ythm{#1}{#2}{#3}}{\@Xthm{#1}{#2}{#3}}} 1058 | 1059 | \def\@Xthm#1#2#3{\@Begintheorem{#1}{#2}{#3}\ignorespaces} 1060 | 1061 | \def\@Ythm#1#2#3[#4]{\@Opargbegintheorem{#1} 1062 | {#4}{#2}{#3}\ignorespaces} 1063 | 1064 | \def\@Begintheorem#1#2#3{#3\trivlist 1065 | \item[\hskip\labelsep{#2#1\@thmcounterend}]} 1066 | 1067 | \def\@Opargbegintheorem#1#2#3#4{#4\trivlist 1068 | \item[\hskip\labelsep{#3#1}]{#3(#2)\@thmcounterend\ }} 1069 | 1070 | \if@envcntsect 1071 | \def\@thmcountersep{.} 1072 | \spnewtheorem{theorem}{Theorem}[section]{\bfseries}{\itshape} 1073 | \else 1074 | \spnewtheorem{theorem}{Theorem}{\bfseries}{\itshape} 1075 | \if@envcntreset 1076 | \@addtoreset{theorem}{section} 1077 | \else 1078 | \@addtoreset{theorem}{chapter} 1079 | \fi 1080 | \fi 1081 | 1082 | %definition of divers theorem environments 1083 | \spnewtheorem*{claim}{Claim}{\itshape}{\rmfamily} 1084 | \spnewtheorem*{proof}{Proof}{\itshape}{\rmfamily} 1085 | \if@envcntsame % alle Umgebungen wie Theorem. 1086 | \def\spn@wtheorem#1#2#3#4{\@spothm{#1}[theorem]{#2}{#3}{#4}} 1087 | \else % alle Umgebungen mit eigenem Zaehler 1088 | \if@envcntsect % mit section numeriert 1089 | \def\spn@wtheorem#1#2#3#4{\@spxnthm{#1}{#2}[section]{#3}{#4}} 1090 | \else % nicht mit section numeriert 1091 | \if@envcntreset 1092 | \def\spn@wtheorem#1#2#3#4{\@spynthm{#1}{#2}{#3}{#4} 1093 | \@addtoreset{#1}{section}} 1094 | \else 1095 | \def\spn@wtheorem#1#2#3#4{\@spynthm{#1}{#2}{#3}{#4} 1096 | \@addtoreset{#1}{chapter}}% 1097 | \fi 1098 | \fi 1099 | \fi 1100 | \spn@wtheorem{case}{Case}{\itshape}{\rmfamily} 1101 | \spn@wtheorem{conjecture}{Conjecture}{\itshape}{\rmfamily} 1102 | \spn@wtheorem{corollary}{Corollary}{\bfseries}{\itshape} 1103 | \spn@wtheorem{definition}{Definition}{\bfseries}{\itshape} 1104 | \spn@wtheorem{example}{Example}{\itshape}{\rmfamily} 1105 | \spn@wtheorem{exercise}{Exercise}{\itshape}{\rmfamily} 1106 | \spn@wtheorem{lemma}{Lemma}{\bfseries}{\itshape} 1107 | \spn@wtheorem{note}{Note}{\itshape}{\rmfamily} 1108 | \spn@wtheorem{problem}{Problem}{\itshape}{\rmfamily} 1109 | \spn@wtheorem{property}{Property}{\itshape}{\rmfamily} 1110 | \spn@wtheorem{proposition}{Proposition}{\bfseries}{\itshape} 1111 | \spn@wtheorem{question}{Question}{\itshape}{\rmfamily} 1112 | \spn@wtheorem{solution}{Solution}{\itshape}{\rmfamily} 1113 | \spn@wtheorem{remark}{Remark}{\itshape}{\rmfamily} 1114 | 1115 | \def\@takefromreset#1#2{% 1116 | \def\@tempa{#1}% 1117 | \let\@tempd\@elt 1118 | \def\@elt##1{% 1119 | \def\@tempb{##1}% 1120 | \ifx\@tempa\@tempb\else 1121 | \@addtoreset{##1}{#2}% 1122 | \fi}% 1123 | \expandafter\expandafter\let\expandafter\@tempc\csname cl@#2\endcsname 1124 | \expandafter\def\csname cl@#2\endcsname{}% 1125 | \@tempc 1126 | \let\@elt\@tempd} 1127 | 1128 | \def\theopargself{\def\@spopargbegintheorem##1##2##3##4##5{\trivlist 1129 | \item[\hskip\labelsep{##4##1\ ##2}]{##4##3\@thmcounterend\ }##5} 1130 | \def\@Opargbegintheorem##1##2##3##4{##4\trivlist 1131 | \item[\hskip\labelsep{##3##1}]{##3##2\@thmcounterend\ }} 1132 | } 1133 | 1134 | \renewenvironment{abstract}{% 1135 | \list{}{\advance\topsep by0.35cm\relax\small 1136 | \leftmargin=1cm 1137 | \labelwidth=\z@ 1138 | \listparindent=\z@ 1139 | \itemindent\listparindent 1140 | \rightmargin\leftmargin}\item[\hskip\labelsep 1141 | \bfseries\abstractname]} 1142 | {\endlist} 1143 | 1144 | \newdimen\headlineindent % dimension for space between 1145 | \headlineindent=1.166cm % number and text of headings. 1146 | 1147 | \def\ps@headings{\let\@mkboth\@gobbletwo 1148 | \let\@oddfoot\@empty\let\@evenfoot\@empty 1149 | \def\@evenhead{\normalfont\small\rlap{\thepage}\hspace{\headlineindent}% 1150 | \leftmark\hfil} 1151 | \def\@oddhead{\normalfont\small\hfil\rightmark\hspace{\headlineindent}% 1152 | \llap{\thepage}} 1153 | \def\chaptermark##1{}% 1154 | \def\sectionmark##1{}% 1155 | \def\subsectionmark##1{}} 1156 | 1157 | \def\ps@titlepage{\let\@mkboth\@gobbletwo 1158 | \let\@oddfoot\@empty\let\@evenfoot\@empty 1159 | \def\@evenhead{\normalfont\small\rlap{\thepage}\hspace{\headlineindent}% 1160 | \hfil} 1161 | \def\@oddhead{\normalfont\small\hfil\hspace{\headlineindent}% 1162 | \llap{\thepage}} 1163 | \def\chaptermark##1{}% 1164 | \def\sectionmark##1{}% 1165 | \def\subsectionmark##1{}} 1166 | 1167 | \if@runhead\ps@headings\else 1168 | \ps@empty\fi 1169 | 1170 | \setlength\arraycolsep{1.4\p@} 1171 | \setlength\tabcolsep{1.4\p@} 1172 | 1173 | \endinput 1174 | 1175 | -------------------------------------------------------------------------------- /paper.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/hyperledger-archives/hyperledgerwp/e0165f4bbb55b00d1bc0a14d3882d7d37f653ebc/paper.pdf -------------------------------------------------------------------------------- /paper.tex: -------------------------------------------------------------------------------- 1 | \def\fullversionflag{1} 2 | 3 | \ifodd\fullversionflag 4 | \documentclass[letterpaper,11pt]{article} 5 | \else 6 | \documentclass{llncs} 7 | \fi 8 | 9 | \usepackage{etoolbox} 10 | \newtoggle{fullversion} 11 | \ifodd\fullversionflag 12 | \toggletrue{fullversion} 13 | \else 14 | \togglefalse{fullversion} 15 | \fi 16 | 17 | \input{latexdefs} 18 | 19 | \iftoggle{fullversion}{ 20 | \usepackage{authblk} 21 | }{} 22 | 23 | \pagestyle{plain} 24 | 25 | \usepackage{breakcites} 26 | 27 | \begin{document} 28 | 29 | \title{An Introduction to Hyperledger} 30 | \date{} 31 | \author{Hyperledger Whitepaper Working Group} 32 | \iftoggle{fullversion}{ 33 | }{ 34 | \institute{} 35 | } 36 | 37 | \maketitle 38 | 39 | 40 | \begin{abstract} 41 | Hyperledger is a Linux Foundation sponsored initiative with the goal of building secure enterprise blockchain implementations. Hyperledger does not have a single blockchain codebase or a single blockchain project, but rather functions as an organization where projects that are accepted by the community can collaborate and share ideas, infrastructure, and code. In this paper we explain the reasons behind the existence of Hyperledger and some of the governance choices we made and the design philosophy we bring to projects. We list some of the use cases and features that motivated our members to participate in Hyperledger. Additionally we outline the current state of Hyperledger in terms of the projects and development efforts that are currently ongoing, and provide directions for those looking to learn more about Hyperledger. This paper is not intended as a technical whitepaper but rather as an introduction to Hyperledger. However, we provide appropriate references for those interested in the technical details of various aspects of Hyperledger. 42 | \end{abstract} 43 | 44 | \section{Introduction} 45 | \label{sec:Introduction} 46 | \input{introduction.tex} 47 | 48 | \section{Why Open Source} 49 | \label{sec:WhyOpenSource} 50 | \input{why_open_source.tex} 51 | 52 | \section{The Umbrella Organization} 53 | \label{sec:TheUmbrellaOrganization} 54 | \input{the_umbrella_organization.tex} 55 | 56 | \section{Design Philosophy} 57 | \label{sec:DesignPhilosophy} 58 | \input{design_philosophy.tex} 59 | 60 | \section{Relevant Use Cases} 61 | \label{sec:RelevantUseCases} 62 | \input{RelevantUseCases/relevant_use_cases.tex} 63 | 64 | \section{Current Projects} 65 | \label{sec:CurrentProjects} 66 | \input{CurrentProjects/current_projects.tex} 67 | 68 | %\section{Highlighted Features} 69 | %\label{sec:HighlightedFeatures} 70 | %\input{HighlightedFeatures/highlighted_features.tex} 71 | 72 | \section{Long-Term Vision} 73 | \label{sec:LongTermVision} 74 | \input{vision.tex} 75 | 76 | \section{Conclusion} 77 | \label{sec:Conclusion} 78 | \input{conclusion.tex} 79 | 80 | \iftoggle{fullversion}{ 81 | \bibliographystyle{alpha} 82 | }{ 83 | \bibliographystyle{alpha} 84 | } 85 | \bibliography{hyperledger} 86 | 87 | \appendix 88 | \section{Authors and Acknowledgements} 89 | \input{authors.tex} 90 | \end{document} 91 | -------------------------------------------------------------------------------- /the_umbrella_organization.tex: -------------------------------------------------------------------------------- 1 | While blockchain is a powerful piece of technology, it is not a one-size-fits-all solution. Modifications and special features are needed in order for it to operate at an optimal level, or even operate at all for its intended purpose. Customized functionality and features are essential to making blockchain technology the appropriate solution for the organization that uses it. Since organizations have varying needs, it can be assumed that there will be multiple blockchains customized with different features for a wide-range of solutions instead of a single standard blockchain. 2 | 3 | Because of this development of multiple systems, collaboration plays a larger role in order to help reduce the overall resources consumed with these efforts. For example, navigating through various developments in an open source environment can be daunting and subsequently cause organizations to forego keeping up with the changes or starting at all due to significant costs. Hyperledger fills this organizational need and makes the coordination process more effective by creating a collaborative environment that streamlines project development and communication. With this environment, keeping up with the various developments in the blockchain industry is simplified. This also makes it easier for newer participants that join the umbrella organization to catch up with the latest developments as information is properly structured to ensure that new participants have an easy way of joining the collaborative effort. 4 | 5 | The umbrella organization structure also allows for specialization among the participants. Specialization has historically proven to be a driving factor in global economic development and the same benefits can be realized with participants specializing in various areas of the technology. Outside an umbrella organization, such would still be possible in an open source environment, but would be much more difficult. As communication and collaboration is streamlined, implementation of these developments and access to necessary information can be done with ease across various projects for the benefit of the entire ecosystem. However, unlike most cases, participants that specialize in similar areas won’t be competing against each other. With an umbrella organization, joint research efforts are not only possible, but also encouraged in order to prevent duplicate efforts, which have a stronger negative effect in a relatively new industry where the development pool is not yet deep.. 6 | 7 | The umbrella organization facilitates more collaboration between industry participants than would otherwise occur. This can streamline the development of newer projects and avoid duplicative efforts by allowing for the creation of common components that benefit the entire community. Interoperability between ledgers, similar or not, also becomes much more of a possibility, not just because of a better understanding of the other ledger projects, but also because of the collaborative environment. The governing structure provided by Hyperledger also helps solve potential interoperability disputes that may arise. 8 | 9 | The structure enforces quality control by having a technical governing committee review all projects throughout their life cycles. For new projects, this provides a chance to be critiqued and gain knowledge from members of all existing projects. Cross-project exposure increases the likelihood of collaboration, which can potentially mitigate duplicated efforts. Additionally, existing project members may discover innovations and developments introduced by the new projects, and implement them in their own projects. This structure also fosters potential interoperability between new and old projects. 10 | 11 | Consistency of licenses and handling of intellectual property is another value provided by the umbrella organization. In particular, Hyperledger operates under an Apache 2.0 license for code and Creative Commons Attribution 4.0 International license for content. These licenses are known to be particularly enterprise friendly. A single, consistent approach to intellectual property removes the need for expensive and complex development relationships amongst the members. Expectations for participants are clearly communicated and those building and using Hyperledger technologies can participate without fear of hidden legal encumbrances. 12 | -------------------------------------------------------------------------------- /vision.tex: -------------------------------------------------------------------------------- 1 | We already live in a highly interconnected world. In the future, we believe that the world will become even more closely tied together: more data sharing, more communication, and more digital content, will become the norm in both our business and personal lives. This will necessitate careful management of security, privacy, and trust. We view distributed ledger technology as the solution to the problem where someone needs a distributed database for which there is no single owner that is trusted by all of the users. Thus, as interconnection increases, we believe that blockchain technology and DLT as a whole will become quite prevalent in society as distributed ledgers replace some, but not all, traditional databases where viable. 2 | 3 | This prevalence of distributed ledgers will not come about without difficulty, however. Nothing in this space is "for free". For instance, if you want a great deal of security and privacy features in a blockchain, you will often pay the price in terms of performance. This implies that we will need to have a large variety of different blockchains--no one blockchain will work for all applications--that can communicate and interact seamlessly. 4 | 5 | Thus, our long-term vision for Hyperledger is driven by two main architectural concerns: modularity and interoperability. We hope that, eventually, Hyperledger consists of lots of modules for various different blockchain components that can be put together by a non-expert into a cohesive, functional, and secure distributed ledger. All of these modules would be interchangeable with other modules of the same time, and able to communicate with other modules of different types (or the same type if involved in communication between separate blockchains). This would ideally enable a non-expert to set up an interoperable and secure blockchain quickly, easily, and efficiently. 6 | 7 | We want to specifically point out that we do not believe any Hyperledger blockchain should be the `one distributed ledger to rule them all'. The Hyperledger community sees merit in many diverse blockchains and we hope that other developers consider interoperability with Hyperledger projects. We do not intend for Hyperledger to be a single stack. Instead, we hope that it becomes a collection of tools purpose built with interoperability and modularity in mind. Any individual can use one, some, or all of the Hyperledger projects to to create a distributed ledger to suit their needs. 8 | 9 | In the future, we hope that Hyperledger can solve most of the common problems in the distributed ledger space. This will necessitate a good community, strong industrial support, and solid design principles. As we have hopefully illustrated in this paper, we have structured Hyperledger with these tenets in mind. It is now up to us to go out and accomplish this. 10 | -------------------------------------------------------------------------------- /why_open_source.tex: -------------------------------------------------------------------------------- 1 | The concept of trust is indelibly woven into the very essence of blockchain technologies. It must be for the reason discussed above - blockchain technologies are used to enable direct, peer-to-peer transactions between parties that don't fully trust one another or have a trusted central authority. Consequently, trust in the blockchain technologies themselves is an essential prerequisite to their adoption. 2 | 3 | We believe that an open source, collaborative approach that invites participation from all stakeholders is the most effective way to produce the necessary degree of trust in blockchain technologies for businesses to broadly and rapidly adopt them. The transparency of open source development facilitates audit and review from a diverse community of experts. This practice of open development and review is standard within the security and cryptography communities to ensure correctness of concept and implementation. 4 | 5 | An effective open source project must have an open governance model, an open development model and an open review model. Hyperledger fully embraces the transparency and openness common to Linux Foundation Projects, which provides the legal, governance, technical, logistical and promotional structure that all software initiatives need. Anyone can download the codebase and start contributing, and the positions of authority are determined in an open and democratic manner. 6 | 7 | The open source structure has been the driving force of the growing number of distinct software projects, contributors, meet-up groups, hackfests, and corporate members, all under the Hyperledger umbrella. Companies deploying blockchain internally, and those building products and services based on Hyperledger projects tell us that their trust and confidence comes from knowing that Hyperledger technologies are built in the open, with and by an extremely broad consortium of users and vendors regularly reviewing and checking the code to ensure that it is of the highest standard. 8 | 9 | The open source nature of Hyperledger technologies also ensures no surprises when it comes to integration and interoperability between various blockchains - something we believe will be very common in the poly-chain future we expect. We expect that achieving needed interaction across proprietary chains would otherwise be much more difficult. In addition to interoperability between different chains, the open source nature of Hyperledger will enable more application portability between various blockchain implementations, hopefully leading to easier application creation for developers. 10 | 11 | Economics is also powerfully on the side of a collaborative development effort like Hyperledger. Businesses as diverse as banks, car and plane makers, healthcare companies and a broad ecosystem of vendors, all need robust, feature-rich, modular blockchain platforms that they can tailor to meet their exact needs. When all these different users and vendors collaborate to co-create common platform technologies, the investment required from each is a fraction of what it would be if each created their own. 12 | --------------------------------------------------------------------------------