ExternalVendorCode/corda
1
0
Fork 0
mirror of https://github.com/corda/corda.git synced 2025-03-21 03:25:43 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Addressing Mike's comments

Browse Source
This commit is contained in:
Richard G Brown 2018-05-04 16:35:06 +01:00
parent 426bc84882
commit f3954ad911
3 changed files with 19 additions and 58 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
docs/source/whitepaper/Ref.bib
View File

@ -1,9 +1,3 @@
@misc{IT,
title = "\emph{{IT in banks: What does it cost?}}",
author = "{{Mai}}",
howpublished = "{\url{https://www.dbresearch.com/PROD/DBR_INTERNET_ENPROD/PROD0000000000299039.pdf}}",
year = 2012
}
@misc{DTCC,
title = "\emph{{Embracing Disruption}}",

BIN
docs/source/whitepaper/corda-platform-whitepaper.pdf
View File

Binary file not shown.

71
docs/source/whitepaper/corda-platform-whitepaper.tex
View File

@ -1,6 +1,6 @@
\documentclass{article}
\author{Richard Gendal Brown}
\date{April, 2018}
\date{May, 2018}
\title{The Corda Platform: An Introduction}
\usepackage{amsfonts}
\usepackage{listings}
@ -17,11 +17,6 @@
\setlength\epigraphwidth{4.5cm}
\setlength\epigraphrule{0pt}
%\usepackage{draftwatermark}
%\SetWatermarkText{Strictly private, confidential and personal to its recipients and should not be copied, distributed or reproduced in whole or in part, nor passed to any third party}
%\SetWatermarkScale{0.5}
%\SetWatermarkFontSize{1cm}
\begin{document}
\maketitle
@ -36,9 +31,9 @@ A distributed ledger made up of mutually distrusting nodes would allow for a sin
\section{Introduction}
We envision a future where legal agreements such as business contracts are recorded and automatically managed without error, where anybody can transact seamlessly for any contractual purpose without friction. We believe markets will move towards models where parties to contracts collaborate to maintain accurate, shared records rather than maintaining their own independent and inconsistent systems which require extensive reconciliation processes to ensure consistency. Duplicates, reconciliations, failed matches and breaks will be things of the past. Isolated pools of trapped of assets will be no more.
This paper introduces the Corda platform. The Corda platform consists of an open source software project, Corda, and a set of standards, network parameters and associated governance processes, which together define the global Corda network. Collectively, they enable any organisation or individual on this open network to transact directly with any other. Uniquely, this architecture is designed to model and automate real-world transactions in a legally enforceable manner, and do so across an open network on which multiple applications can execute and seamlessly interoperate. It does so whilst placing identity, transaction finality, privacy and open governance at its core.
This paper introduces the Corda platform. The Corda platform consists of an open source software project, Corda, and a set of standards, network parameters and associated governance processes, which together define the global Corda Network. Collectively, they enable any organisation or individual on this open network to transact directly with any other. Uniquely, this architecture is designed to model and automate real-world transactions in a legally enforceable manner, and do so across an open network on which multiple applications can execute and seamlessly interoperate. It does so whilst placing identity, transaction finality, privacy and open governance at its core.
The end state vision is one where real-world entities manage legally-enforceable contracts, and transfer value without technological constraints or loss of privacy. In contrast to unpermissioned blockchain platforms, the Corda Platform is intended to manage real-world transactions between identifiable parties, with privacy and legal certainty. In contrast to other `permissioned' blockchain platforms, the Corda Platform is intended to allow multiple groups of participants (and associated applications) to co-exist and interoperate across the same open network. The network's governance model is explicitly designed to reflect the common interests of the diverse user-base of the platform.
The end state vision is one where real-world entities manage legally-enforceable contracts, and transfer value without technological constraints or loss of privacy. In contrast to unpermissioned blockchain platforms, the Corda platform is intended to manage real-world transactions between identifiable parties, with privacy and legal certainty. In contrast to other `permissioned' blockchain platforms, the Corda Platform is intended to allow multiple groups of participants (and associated applications) to co-exist and interoperate across the same open network. The network's governance model is explicitly designed to reflect the common interests of the diverse user-base of the platform.
To facilitate settlement of obligations arising from contracts managed on the platform, the Corda platform enables the issuance, transfer and redemption of cash-like liabilities denominated in real-world currencies where regulation allows. In addition, the architecture enables the issuance of native assets and tokens on the platform which can be used to incentivise adoption and participation, pay for services and can be either platform-wide or specific to particular Business Networks\footnote{See section \ref{businessnetworks} for a definition} operating on the broader Corda network.
@ -53,7 +48,7 @@ Regardless of industry or geography, we see the same inefficient pattern in toda
Until recently, this was unavoidable: except for centralised market infrastructures\footnote{Examples of this in the financial industry include the Depository Trust \& Clearing Corporation (DTCC) and Continuous Linked Settlement Group (CLS), and there are equivalents in many other industries}, there were few effective ways to consolidate technology across firms without also consolidating the firms themselves.
Centralised market infrastructure utilities have gone some way towards increasing the amount of data and business-logic sharing between firms. But this development creates unfavourable tradeoffs of its own: such as the possibility of rent-seeking and inertia. This has been evidenced by how the world of financial transactions still lags far behind that which has been achieved in the realm of consumer and web based software since the advent of the web\cite{IT}.
Centralised market infrastructure utilities have gone some way towards increasing the amount of data and business-logic sharing between firms. But this development creates unfavourable tradeoffs of its own: such as the possibility of rent-seeking and inertia. This has been evidenced by how the world of financial transactions still lags far behind that which has been achieved in the realm of consumer and web based software since the advent of the web.
We believe that the maturation of cryptographic techniques, exemplified in part by what is commonly referred to as ``blockchain technology", provides a new opportunity. This is the possibility of authoritative systems of record that are securely shared between firms, and which enable a large subset of each firm's transactions to be managed in a common way. Systems that provide a guarantee that ``I know that what I see is what you see".
@ -107,7 +102,7 @@ From our requirements analysis and assessment of existing distributed ledger pla
As a result we present the Corda platform.
\section{Corda}
Corda is distributed ledger software for recording and processing contracts such as but not only financial agreements, designed to implement the vision contained in this document.
Corda is distributed ledger software for recording and processing shared data such as contracts, designed to implement the vision contained in this document.
Corda supports smart contracts, matching the definition of Clack, Bakshi, Braine\cite{SCT}; our smart contract is an agreement whose execution is both \textit{automatable} by computer code working with human input and control, and whose rights and obligations, as expressed in legal prose, are legally \textit{enforceable}.
@ -117,8 +112,8 @@ Corda's design was initially driven by the needs of regulated financial institut
Our fundamental building block is a \textit{``state object"}, representing a specific instance of a specific agreement, which may be thought of as representing a real-world contract or section of a contract. We use the terms `agreement' and `contract' interchangeably in this paper. This stands in contrast to systems where the data over which participants must reach consensus is the state of an entire ledger or the state of an entire virtual machine. Corda provides three main tools to achieve global distributed consensus:
\begin{itemize}
\item \textit{Smart contract} logic which specifies \textit{constraints} that ensure state transitions are valid according to pre-agreed \textit{rules}, described in \textit{contract code} as part of \textit{CorDapps}.
\item Uniqueness and timestamping services known as \textit{Notary pools} to order transactions temporally and eliminate conflicts.
\item A unique component called the \textit{Flow Framework} which simplifies the process of writing complex multi-step protocols between multiple mutually distrusting parties across the internet.
\item Uniqueness and timestamping services known as \textit{notary pools} to order transactions temporally and eliminate conflicts.
\item A unique component called the \textit{flow framework} which simplifies the process of writing complex multi-step protocols between multiple mutually distrusting parties across the internet.
\end{itemize}
\subsection{Concepts}
@ -130,7 +125,7 @@ We talk and think in terms of the `state' of `agreements'. That is: not just a c
\begin{figure}[H]
\includegraphics[scale = .4, center]{partiesto}
\caption{In the diagram above, we see a State object representing a cash claim of \pounds100 against a commercial bank (commonly referred to as `a deposit'), owned by a fictional shipping company. The state object explicitly refers by hash to its governing legal prose and to the contract code that governs its transitions, which is likely to be written once and reused by huge numbers of states.}
\caption{In the diagram above, we see a state object representing a deposit of \pounds100 at a commercial bank, owned by a fictional shipping company. The state object refers to the contract code that governs its transitions, which is likely to be written once and reused by huge numbers of states, and can refer by hash to its governing legal prose and.}
\end{figure}
\subsection{Consensus}
@ -147,7 +142,7 @@ Parties can agree on transaction validity by independently running the same cont
\caption{Consensus over transaction validity is performed only by parties to the transaction in question. Therefore, data is only shared with those parties which are required to see it. Other platforms generally reach consensus at the ledger level. Thus, any given actor in a Corda system sees only a subset of the overall data managed by the system as a whole. We allow arbitrary combinations of actors to participate in the consensus process for any given piece of data.}
\end{figure}
Corda has ``pluggable" uniqueness services. This is to improve privacy, scalability, geographic availability, legal-system compatibility\cite{EUC} and algorithmic agility. A single service may be composed of many mutually untrusting nodes coordinating via a byzantine fault tolerant algorithm, or could be very simple, like a single machine. In some cases, like when evolving a state requires the signatures of all relevant parties, there may be no need for a uniqueness service at all.
Corda has ``pluggable" uniqueness services. This is to improve privacy, scalability, geographic availability, legal-system compatibility\cite{EUC} and algorithmic agility. A single service may be composed of many mutually untrusting nodes coordinating via a byzantine fault tolerant algorithm, or could be very simple, like a single machine.
It is important to note that these uniqueness services are required only to attest as to whether the states consumed by a given transaction have previously been consumed; they are not required to attest as to the validity of the transaction itself, which is a matter for the parties to the transaction. This means that the uniqueness services are not required to (and, in the general case, will not) see the full contents of any transactions, significantly improving privacy and scalability of the system compared with alternative distributed ledger and blockchain designs. This design decision represents an important choice as to the acceptable tradeoffs in shared ledger architectures and is explored more fully in the technical whitepaper.
@ -181,26 +176,16 @@ The combination of state objects (data), Contract Code (constraints on the evolu
\end{figure}
\section{The Global Corda Network}
The global Corda network consists of the set of nodes in the world that are configured with common settings such that they can locate each other, with assured identity, to transact directly. The network provides the standards needed to allow Corda nodes to transact flawlessly regardless of who operates them, which applications they run, in which trading groupings they participate, and regardless of the original reason for their deployment. The network enables the formation of an open ecosystem where services can be offered both to specific groups of nodes (``Business Networks", as distinct from the global Corda network itself), or to all nodes. The network provides an open environment for the deployment of Corda nodes with transaction legality, finality and privacy. The network is underpinned by a governance model intended to ensure it operates in the interest of its participants.
The global Corda network consists of the set of nodes in the world that are configured with common settings such that they can locate each other, with assured identity, to transact directly. The network provides the standards needed to allow Corda nodes to transact flawlessly regardless of who operates them, which applications they run, in which trading groupings they participate, and regardless of the original reason for their deployment. The network enables the formation of an open ecosystem where services can be offered both to specific groups of nodes (``business networks", as distinct from the global Corda network itself), or to all nodes. The network provides an open environment for the deployment of Corda nodes with transaction legality, finality and privacy. The network is underpinned by a governance model intended to ensure it operates in the interest of its participants.
\subsection{Business Networks} \label{businessnetworks}
We anticipate that most deployments of Corda will consist of parties coming together to automate one or more common business processes, and these deployments will be underpinned by specific business models and membership criteria. We refer to such a collection of parties as a Business Network: a group of Corda network participants who collaborate for a specific business purpose whilst nevertheless being able to participate in other Business Networks or transact directly with other nodes at the same time and with the same infrastructure. The Corda network provides the capability to form Business Networks while allowing participants to remain unconstrained in their ability to move assets or form agreements freely.
We anticipate that most deployments of Corda will consist of parties coming together to automate one or more common business processes, and these deployments will be underpinned by specific business models and membership criteria. We refer to such a collection of parties as a business network: a group of Corda network participants who collaborate for a specific business purpose whilst nevertheless being able to participate in other business networks or transact directly with other nodes at the same time and with the same infrastructure. The Corda network provides the capability to form business networks while allowing participants to remain unconstrained in their ability to move assets or form agreements freely.
Business Networks define their own membership criteria, privacy requirements, governance, business logic and asset types. Participants can be members of many Business Networks as well as transacting directly with arbitrary peers.
Business networks define their own membership criteria, privacy requirements, governance, business logic and asset types. Participants can be members of many business networks as well as transacting directly with arbitrary peers.
%The global Corda network recognises three role definitions for those involved in designing, operating and governing business networks:
%
%\begin{itemize}
% \item A \textit{Business Network Designer} is an entity that defines the technical implementation of a business network. They assist with defining the initial legal and regulatory basis for the business network, help estabish a commercial model, engage the first set of participants, and generate the specification of the associated CorDapp(s).
% \item A \textit{Business Network Governor} is an entity that owns and manages a business network. They own and manage the commercial model, if any, the legal and regulatory governance, the evolution of the CorDapp and associated State Objects, the rules and onboarding and offboarding of members, and any associated SLAs. Initially, we expect this role to be performed by traditional corporate entities but we also expect to see more distributed models becoming common over time.
% \item A \textit{Business Network Operator} manages operational issues around the use of the business network, including deployment, version management and other functions requiring coordination. They act as a liaison point for any third parties (including oracles and notary pools), monitor and assure SLA compliance, provide any necessary reporting capabilities, and provide any needed support and helpdesk.
%\end{itemize}
The global Corda network is intended to enable a large number of overlapping, competing and collaborating Business networks to form, unified by just enough commonality to facilitate interoperability of nodes, and compatibility of assets and other contracts managed by those nodes.
%Simplistically one can think of the Business Network Designer as the entity that has the idea for the business network and brings it to life, the Business Network Governor as the entity responsible for ensuring and sustaining its commercial, legal and technical success, and the Business Network Operator as the party which provides day-to-day operational support. One party can perform more than one role.
The global Corda network is intended to enable a large number of overlapping, competing and collaborating Business Networks to form, unified by just enough commonality to facilitate interoperability of nodes, and compatibility of assets and other contracts managed by those nodes.
Business Networks will play a key role in the health of the Corda network ecosystem providing the mechanism through which CorDapps are rooted in the regulatory and legal aspects of various legal jurisdictions.
Business networks will play a key role in the health of the Corda network ecosystem providing the mechanism through which CorDapps are rooted in the regulatory and legal aspects of various legal jurisdictions.
\begin{figure}[H]
\includegraphics[scale = .5, center]{corda-connect}
@ -221,7 +206,7 @@ The global Corda network:
\subsubsection{Governance}
Whilst the overwhelming majority of power lies with Corda users themselves, or their chosen Business Network Governors, some residual control unavoidably lies in the specification of the standards and operation of associated technical services upon which all participants rely. This means the success of the Corda network depends on the extent to which it is operated in the interests of its broad base of stakeholders, and is responsive to their needs.
Whilst the overwhelming majority of power lies with Corda users themselves, or the governors of their chosen business networks, some residual control unavoidably lies in the specification of the standards and operation of associated technical services upon which all participants rely. This means the success of the Corda network depends on the extent to which it is operated in the interests of its broad base of stakeholders, and is responsive to their needs.
For example, in Bitcoin, the size of the maximum permitted block is ultimately arbitrary within some boundaries. Yet it is an arbitrary figure upon which all participants in \textit{the} Bitcoin network must agree. In the absence of a well thought through and administered governance process to decide on settings such as this, operated by and for the participants in the network, gridlock or conflict can be the result. To avoid a similar outcome, the purpose of the Corda network's governance process is to ensure it is always clear how such disputes can be mediated, by whom and in whose interests.
@ -231,13 +216,13 @@ To that end, an open governance model will be established in a series of stages
\subsubsection{Network Parameters}
Corda users need to agree on certain technical parameters that must be the same for all nodes in order to communicate successfully. These range from the trivial-and-arbitrary like ``port numbers" used for firewall traversal, to the more impactful, like how quickly members agree to upgrade their nodes when a new feature is introduced and how to use privacy features like Intel SGX. Although these sound like unimportant technical points, they are configuration parameters of the Corda software precisely \textit{because} they are things upon which reasonable people could disagree, as happened with the Bitcoin block size debate. As such, the parameter-setting process could rapidly become politicised. It is, therefore, a priority to move responsibility for setting, maintaining and updating these parameters to the Corda network governing body once established.
Corda users need to agree on certain technical parameters that must be the same for all nodes in order to communicate successfully. These range from the trivial-and-arbitrary like port numbers used for firewall traversal, to the more impactful, like how quickly members agree to upgrade their nodes when a new feature is introduced and how to use privacy features like Intel SGX. Although these sound like unimportant technical points, they are configuration parameters of the Corda software precisely \textit{because} they are things upon which reasonable people could disagree, as happened with the Bitcoin block size debate. As such, the parameter-setting process could rapidly become politicised. It is, therefore, a priority to move responsibility for setting, maintaining and updating these parameters to the Corda network governing body once established.
\subsubsection{Identity}
Corda manages real contracts between real people and firms. So we need a way for users to know they really are transacting with who they think they are. This requires there to be a unique mapping from real-world identity to network identity (public key). As such, it is an unavoidable consequence that an important Network Parameter is which identity authority or authorities to rely on.
Corda manages real contracts between real people and firms. So we need a way for users to know they really are transacting with who they think they are. This requires there to be a unique mapping from real-world identity to network identity (public key). As such, it is an unavoidable consequence that an important network parameter is which identity authority or authorities to rely on.
However, it is our vision that access to the Corda network be available to as broad a range of participants as possible; restrictions driven by business model, regulation or geography can and should be implemented at the level of individual business networks, not at the level of the overall platform. Indeed, it is important to emphasise that Business Network Operators are able, and indeed are expected, to independently verify participants' identities before admitting them to their Business Networks. It is this extra layer of checking that allows the Corda network-level identity framework to be as light as possible whilst ensuring uniqueness of identity certificates.
However, it is our vision that access to the Corda network be available to as broad a range of participants as possible; restrictions driven by business model, regulation or geography can and should be implemented at the level of individual business networks, not at the level of the overall platform. Indeed, it is important to emphasise that operators of business networks are able, and indeed are expected, to independently verify participants' identities before admitting them to their business networks. It is this extra layer of checking that allows the Corda network-level identity framework to be as light as possible whilst ensuring uniqueness of identity certificates.
To this end, the Corda network will launch with a simple identity service that will subsequently be upgraded to enable a broader range of approaches. One such approach is likely to be one where participants ``bring their own identity" in the form of signed attestations from a set of trusted identity issuers/attestors. We envisage a model whereby the automatic issuance of a Corda network certificate can be triggered for any party with the requisite attestations, subject only to the constraint that any resulting identity certificate issued on the global Corda network is unique, both for the distinguished name and the public keys or any other unique identifier that may be used in the future.
@ -247,23 +232,11 @@ One of the responsibilities of the Corda network governing body will be to overs
Corda, like all blockchain platforms, works on the principle of \textit{consensus}. Parties know a transaction has been confirmed when the appointed consensus service has processed it. Uniquely, Corda is architected to support volumes in excess of billions of daily transactions across a single network. To achieve this, Corda allows for a range of consensus services (notary pools) optimised for different purposes on the same network, including on the global Corda network described in this chapter.
%As with all blockchain systems, there are two consumers of transaction confirmation information. First, there are the parties who currently depend on the confirmation of the transaction. Secondly, there are the parties who will depend \textit{in the future} on the fact that this transaction was correctly confirmed with finality \textit{today}. They will need this in order to safely validate a future transaction that depends on this one.
%This combination of personal choice for notarisation and confidence in reciprocity in transaction validation is a highly valuable prospect for users of the Corda network. It means they can use a notary pool of their own choosing to have their transactions confirmed (perhaps selected based on performance or geographic data sovereignty concerns); and another party can choose a different notary pool. And yet they can subsequently transact with each other, with full provenance and integrity.
Participants can verify the integrity of these choices through a variety of mechanisms: some notary pools will provide transparency (in a way analogous to public blockchains today). Others may remotely attest that they are running a particular algorithm in a secure enclave. To aid network participants in configuring their nodes and to maximise interoperability, a responsibility of the Corda network governing body is to establish and maintain a list of notary pools which are considered to be operated to sufficient standards of integrity. Participants are encouraged to configure their nodes to accept historical transactions that have been notarised by pools on this shared list to maximise compatibility of transactions across the network. Participants can, of course, choose any notary pool to notarise their own transactions; this shared list is to enable historic transactions to be easily combined with new transactions to enable free movement of data and assets around the network; the fundamental vision and unique characteristic of Corda.
%Latency: Corda Connect has the ability to support multiple pools of geo-proximate notary clusters. Parties can select a notary pool which has low latency relative to their location. This is likely to result in notary pools defined at a continental level at a minimum with many country specific notary pools likely although nothing in the Corda architecture mandates a specific distribution. Corda enables each notary pool to operate different consensus algorithms. The performance of each pool will depend on the consensus algorithm that has been selected and the optimal number of nodes in such configuration. End users can therefore select a notary pool based on their performance requirements trading off, for example, trust.
%Resilience: Corda Connect represents a global commercial system which operates 24x7. The notary pools therefore much be characterised by zero downtime as a functional unit. However, within the pool specific nodes may fail and rejoin the cluster and overall resilience is improved by adding nodes to the pool and selecting more resilient consensus algorithms at the cost of performance.
%Legal: Rules that dictate data privacy or data sovereignty exist in many jurisdictions. For example, Brazil does not allow the movement of any data related to transactions to leave the country. This is likely to require notary pools per jurisdiction or economic zone such as the EU to bring the technology in to line with legal reality. Transactions that would span between countries must have a common shared notary that is structured to support cross-border transactions which may not be the same notary pool that supports the rules of data sovereignty.
%Trust: Trust is one of the key issues for the network participants as there is a need to trust the set of notaries that are a part of a transaction history. The participant must be sure the notaries have not been compromised or are not acting in a malicious manner in the same way they need to trust miners are not colluding in the Bitcoin network. Notaries on Corda Connect will need to conform to a set of standards to be accepted by the governance structures of the Corda network. This includes operating a distrusting consensus configuration with a minimum set of participants and providing transparent mechanisms for adding and removing nodes to participate in the consensus. We envisage notary pools to be operated by consortia of business network operators on behalf of their participants.
\subsubsection {The Corda Network Economic Model}
The success of Corda and the global Corda network depends, in part, on there being a vibrant ecosystem of participants on the network: users; Business Network Designers, Governors and Operators; application developers; providers of notary nodes; oracle services and infrastructure providers, many of whom will need to pay and be paid.
The success of Corda and the global Corda network depends, in part, on there being a vibrant ecosystem of participants on the network: users; designers, governors and operators of business networks; application developers; providers of notary nodes; oracle services and infrastructure providers, many of whom will need to pay and be paid.
The global Corda network will support a digital representation of fiat money, the first broad-access blockchain network to do so. However, access to this facility will necessarily be subject to the thicket of regulation that attaches to the global payments system.
@ -300,10 +273,6 @@ A Bitcoin script can only be given a fixed set of byte arrays as the input. This
Corda allows arbitrarily-precise time-bounds to be specified in transactions (which must be attested to by a trusted timestamper) rather than relying on the time at which a block happens to be mined. This is important given that many contract types we envisage supporting require precision in timing and because our primary consensus implementations use block-free conflict resolution algorithms. It should be noted that Corda does not utilise Proof of Work or have a concept of ``mining".
%Bitcoin has suffered from a lack of a governance model
%Bitcoins consenus mechanism suffers from an aggregration of mining power
\subsubsection{Comparisons to Ethereum}
Like Ethereum, CorDapp code runs inside a relatively powerful virtual machine and can contain complex logic. Non-assembly based programming languages can be used for contract programming. They are both intended for the modelling of many different kinds of financial contracts.
@ -319,8 +288,6 @@ In contrast to most existing distributed ledger and blockchain platforms today,
The Corda vision, enabled by the global Corda network, enables multiple applications and services to run across a common layer of identity, consensus, business logic, data definitions, and governance. Firms can deploy one Corda node infrastructure which can then transact with multiple different groups of trading partners, for different purposes, all at the same time and whilst providing strong privacy. Multiple different competing notary consensus pools, comprised of a range of providers, will be available; data and other oracle services can be deployed once and used by multiple applications; and the entire ecosystem will be governed by and for its users through a transparent and open process. Multiple different applications, designed for completely different purposes, can be deployed today to solve specific problems and yet, in the future, contracts and other information managed by these applications could be combined in new ways for purposes unimaginable today.
%With the Corda platform, anybody will be able to transact with any other duplications, reconciliations, failed matches and breaks will soon be things of the past. Isolated islands of asset representations will be no more.
\bibliographystyle{unsrt}
\bibliography{Ref}