mirror of
https://github.com/corda/corda.git
synced 2025-01-29 15:43:55 +00:00
DEVREL-1297 Ledger - Doc Site Lessonly Conformance (#5128)
* DEVREL-1297 Ledger - Doc Site Lessonly Conformance Rewrite to bring Doc Site and Lessonly into conformance. Assumption is that Doc Site is more up to date. * DEVREL-1297 Ledger - Doc Site Lessonly Conformance * DEVREL-1297 Ledger - Doc Site Lessonly Conformance Home page describes sections that link from it to enable easier navigation. * Removed comment
This commit is contained in:
ChrissyAtWork
Roger Willis
parent
860ef5833a
commit
79616536d4
@ -3,15 +3,14 @@ The network
|
||||
|
||||
.. topic:: Summary
|
||||
|
||||
* *A Corda network is made up of nodes running Corda and CorDapps*
|
||||
* *Communication between nodes is point-to-point, instead of relying on global broadcasts*
|
||||
* *Each node has a certificate mapping their network identity to a real-world legal identity*
|
||||
* *A Corda network is made up of nodes, each of which runs an instance of Corda and one or more CorDapps*
|
||||
* *Communication between nodes is point-to-point, and does not rely on global broadcasts*
|
||||
* *Each node has a certificate that maps its network identity to a real-world legal identity*
|
||||
* *The network is permissioned, with access requiring a certificate from the network operator*
|
||||
|
||||
Network structure
|
||||
-----------------
|
||||
A Corda network is a peer-to-peer network of **nodes**. Each node runs the Corda software as well as Corda applications
|
||||
known as **CorDapps**.
|
||||
A Corda network is a peer-to-peer network of **nodes**. Each node represents a legal entity, and each runs the Corda software (an instance of Corda and one or more Corda applications, known as **CorDapps**).
|
||||
|
||||
.. image:: resources/network.png
|
||||
:scale: 25%
|
||||
@ -20,28 +19,38 @@ known as **CorDapps**.
|
||||
All communication between nodes is point-to-point and encrypted using transport-layer security. This means that data is
|
||||
shared only on a need-to-know basis. There are **no global broadcasts**.
|
||||
|
||||
Identity
|
||||
--------
|
||||
Each node has a single well-known identity. The node's identity is used to represent the node in transactions, such as
|
||||
when purchasing an asset.
|
||||
All of the nodes in the network have the *potential* to communicate with other nodes.
|
||||
|
||||
.. note:: These identities are distinct from the RPC user logins that are able to connect to the node via RPC.
|
||||
**Why do we say "potential" to communicate?**
|
||||
|
||||
Each network has a **network map service** that maps each well-known node identity to an IP address. These IP
|
||||
Because the connections on the graph do not have to be persistent. On the networking level, Corda uses persistent queues, but, as with email, if your recipient is offline, your messages will wait on an outbound queue until the recipient comes online.
|
||||
|
||||
Identities and Discovery
|
||||
------------------------
|
||||
Each node has a single well-known identity. The node's identity is used to represent the node in transactions; for example, if the node were involved in a transaction to purchase an asset.
|
||||
|
||||
The network map service maps each well-known node identity to an IP address. These IP
|
||||
addresses are used for messaging between nodes.
|
||||
|
||||
Nodes can also generate confidential identities for individual transactions. The certificate chain linking a
|
||||
confidential identity to a well-known node identity or real-world legal identity is only distributed on a need-to-know
|
||||
basis. This ensures that even if an attacker gets access to an unencrypted transaction, they cannot identify the
|
||||
transaction's participants without additional information if confidential identities are being used.
|
||||
basis. If confidential identities are being used, this ensures that even if an attacker gets access to an unencrypted transaction, they cannot identify the
|
||||
transaction's participants without additional information.
|
||||
|
||||
**How do Corda nodes Discover each other?**
|
||||
|
||||
Corda nodes discover each other via a **network map service**. You can think of this service as a phone book, which publishes a list of peer nodes that includes metadata about who they are and what services they can offer.
|
||||
|
||||
Admission to the network
|
||||
------------------------
|
||||
Corda networks are semi-private. To join a network, a node must obtain a certificate from the network operator. This
|
||||
Unlike traditional blockchain, Corda networks are semi-private. To join a network, a node must obtain a certificate from the network operator. This
|
||||
certificate maps a well-known node identity to:
|
||||
|
||||
* A real-world legal identity
|
||||
* A public key
|
||||
|
||||
The network operator enforces rules regarding the information that nodes must provide and the know-your-customer
|
||||
processes they must undergo before being granted this certificate.
|
||||
The network operator enforces rules regarding the information that nodes must provide and the know-your-customer (KYC) processes they must undergo before being granted this certificate.
|
||||
|
||||
**What makes Corda different to other networks?**
|
||||
|
||||
Other Distributed Ledger Technology (DLT) platforms use global broadcast and gossip networks to propagate data. Corda uses point-to-point messages, and sends them only on a need to know basis (lazy propagation).
|
||||
|
||||
@ -16,25 +16,52 @@ The ledger
|
||||
<p></p>
|
||||
|
||||
|
||||
Overview
|
||||
The Ledger Data
|
||||
--------
|
||||
In Corda, there is **no single central store of data**. Instead, each node maintains a separate database of known
|
||||
facts. As a result, each peer only sees a subset of facts on the ledger, and no peer is aware of the ledger in its
|
||||
entirety.
|
||||
In Corda, there is **no single central store of data**. Instead, each node maintains its own database of those facts that it is aware of.
|
||||
|
||||
For example, imagine a network with five nodes, where each coloured circle represents a shared fact:
|
||||
The facts that a node knows about are those that it is involved with. For example, if there are nodes representing Alice and Bob on the network and Alice loans Bob some money, both Alice and Bob will store an identical record of the facts about that loan. If the only parties involved with the loan are Alice and Bob, then they will be the only nodes that ever see or store this data.
|
||||
|
||||
**Important:** The result of this design is that each peer only sees a subset of facts on the ledger, and no peer is aware of the ledger in its entirety.
|
||||
|
||||
Example: A network with five nodes, where each numbered circle on an intersection represents a fact shared between two or more nodes.
|
||||
|
||||
.. image:: resources/ledger-venn.png
|
||||
:scale: 25%
|
||||
:align: center
|
||||
|
||||
The preceding Venn diagram represents 5 nodes (Alice, Bob, Carl, Demi and Ed) as sets. Where the sets overlap are shared facts, such as those known by both Alice and Bob (1 and 7).
|
||||
|
||||
We can see that although Carl, Demi and Ed are aware of shared fact 3, **Alice and Bob are not**.
|
||||
Notably, in this Venn diagram, Alice only shares facts with Bob. Alice does not share facts with any of Carl, Demi or Ed.
|
||||
|
||||
Equally importantly, Corda guarantees that whenever one of these facts is shared by multiple nodes on the network, it evolves
|
||||
in lockstep in the database of every node that is aware of it:
|
||||
**Summary**
|
||||
|
||||
The Corda Ledger is a **subjective** construct from each peer's point of view.
|
||||
|
||||
**What does that mean?**
|
||||
|
||||
* There are no omniscient peers who can see everything on the ledger.
|
||||
* Each node sees their own facts, and the facts that they share with others.
|
||||
|
||||
For example, Alice and Demi don't share any facts, so they each see a completely different set of shared facts.
|
||||
|
||||
Shared Facts
|
||||
------------
|
||||
|
||||
In the previous diagram, we could see that although Carl, Demi and Ed are aware of shared fact 3, **Alice and Bob are not**.
|
||||
|
||||
On Corda, there is no central or general ledger operating with agency on behalf of all of the nodes on the network. Instead, each node on the network maintains its own vault containing all of its known facts.
|
||||
|
||||
You can think of this vault as being a database or simple table.
|
||||
|
||||
.. image:: resources/ledger-table.png
|
||||
:scale: 25%
|
||||
:scale: 100%
|
||||
:align: center
|
||||
|
||||
For example, Alice and Bob will both see the **exact same version** of shared facts 1 and 7.
|
||||
Where the rows are shared between nodes (facts 1 and 7 in this example), these are shared facts.
|
||||
|
||||
Corda guarantees that whenever one of these facts is shared by multiple nodes on the network, it evolves in lockstep in the database of every node that is aware of it. This means that Alice and Bob will both see an **exactly identical version** of shared facts 1 and 7.
|
||||
|
||||
**Note:** Not all on-ledger facts are shared between peers. For example, Alice's fact 11 is not shared with Bob. Fact 11 could, in fact, not be shared with any other node at all. If this is the case, it is deemed a unilateral fact.
|
||||
|
||||
**Note:** Although there is no central ledger, it is possible to broadcast a basic fact to all participants should you wish to. You would do this by using the network map service to loop over all parties.De
|
||||
|
||||
@ -6,26 +6,59 @@ Key concepts
|
||||
This section describes the key concepts and features of the Corda platform. It is intended for readers who are new to
|
||||
Corda, and want to understand its architecture. It does not contain any code, and is suitable for non-developers.
|
||||
|
||||
This section should be read in order:
|
||||
.. note::
|
||||
The pages in this section should be read in order.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:hidden:
|
||||
|
||||
The Network <key-concepts-ecosystem>
|
||||
The Ledger <key-concepts-ledger>
|
||||
States <key-concepts-states>
|
||||
Transactions <key-concepts-transactions>
|
||||
Contracts <key-concepts-contracts>
|
||||
Flows <key-concepts-flows>
|
||||
Consensus <key-concepts-consensus>
|
||||
Notary <key-concepts-notaries>
|
||||
Vault <key-concepts-vault>
|
||||
Time Windows <key-concepts-time-windows>
|
||||
Oracles <key-concepts-oracles>
|
||||
Nodes <key-concepts-node>
|
||||
Transaction Tear-Offs <key-concepts-tearoffs>
|
||||
Trade Offs <key-concepts-tradeoffs>
|
||||
Deterministic JVM <key-concepts-djvm>
|
||||
|
||||
|
||||
key-concepts-ecosystem
|
||||
key-concepts-ledger
|
||||
key-concepts-states
|
||||
key-concepts-transactions
|
||||
key-concepts-contracts
|
||||
key-concepts-flows
|
||||
key-concepts-consensus
|
||||
key-concepts-notaries
|
||||
key-concepts-vault
|
||||
key-concepts-time-windows
|
||||
key-concepts-oracles
|
||||
key-concepts-node
|
||||
key-concepts-tearoffs
|
||||
key-concepts-tradeoffs
|
||||
key-concepts-djvm
|
||||
The first topics in this section provide an **overview** of the Corda Distributed Ledger:
|
||||
|
||||
* :doc:`key-concepts-ecosystem` - The ecosystem that Corda exists in
|
||||
* :doc:`key-concepts-ledger` - The ledger, and how facts on the ledger are shared between nodes
|
||||
|
||||
The second set of topics describe the core **CorDapp Concepts**:
|
||||
|
||||
* :doc:`key-concepts-states` - The states represent shared facts on the ledger
|
||||
* :doc:`key-concepts-transactions` - The transactions update the ledger states
|
||||
* :doc:`key-concepts-contracts` - The contracts govern the ways in which states can evolve over time
|
||||
* :doc:`key-concepts-flows` - The flows describe the interactions that must occur between parties to achieve consensus (to satisfy some business requirement)
|
||||
|
||||
.. note::
|
||||
When you build a custom CorDapp, your CorDapp will have state, transaction, contract and flow classes.
|
||||
|
||||
The following **Adavnced Corda Concepts** describe important conceptual information:
|
||||
|
||||
* :doc:`key-concepts-consensus` - How parties on the network reach consensus about shared facts on the ledger
|
||||
* :doc:`key-concepts-notaries` - The component that assures uniqueness consensus (prevents double spends)
|
||||
* :doc:`key-concepts-vault` - The component that stores on-ledger shared facts for a node
|
||||
|
||||
Finally, some concepts that expand on other areas:
|
||||
|
||||
* :doc:`key-concepts-time-windows` - Transactions can be validated as having fallen after, before or within a particular time window
|
||||
* :doc:`key-concepts-oracles` - Transactions can include off-ledger facts retrieved using Oracles
|
||||
* :doc:`key-concepts-node` - Each node contains an instance of Corda, one or more CorDapps, and so on
|
||||
* :doc:`key-concepts-tearoffs` - Transactions can be signed by parties who have access to only a limited view of the transaction parts
|
||||
* :doc:`key-concepts-tradeoffs` - Trade-offs that have been made in designing Corda and CorDapps
|
||||
* :doc:`key-concepts-djvm` - Information about the importance and details of the deterministic JVM
|
||||
|
||||
The detailed thinking and rationale behind these concepts are presented in two white papers:
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user