You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: chapters/chapter-04-how-cardano-works/network-protocols.adoc
+12-12Lines changed: 12 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -44,18 +44,18 @@ The _networking layer_ of the Cardano node consists of smaller building-blocks c
44
44
* *Ping pong protocol:* A simple protocol used between a client and server to check responsiveness. A ping is sent to the server at regular intervals, and if the server is connected and responsive it will reply with a pong message.
45
45
* *Request response protocol:* Functions similar to the ping pong protocol, but further allows data exchange between server and client.
46
46
* *Handshake mini protocol:* Used to negotiate protocol version and parameters between client and server. It runs once upon connection initiation and consists of a single request from the client and a single response from the server.
47
-
* *Keep alive mini protocol(keep-alive):* A member of the Node-to-Node(NtN) protocol suite, this protocol provides keep alive messages and measures the round trip times of these messages.
48
-
* *Chain synchronization protocol(chain-sync):* Allows for local synchronization of the blockchain via communication with several upstream and downstream nodes. This protocol is responsible for the transfer of full blocks when used as part of the Node to Client(NtC) protocol, whereas instances used as part of the Node to Node(NtN) protocol only transfers block headers.
49
-
* *Block fetch protocol(block-fetch):* Enables a node to request and download blocks from other nodes.
50
-
* *Node-to-node transaction submission protocol(tx-submission):* A protocol used to transfer transactions between nodes, where the initiator requests new transactions and the responder returns them. In this protocol, the server acts as the initiator while the client acts as the responder, making it well suited for a trustless setting.
51
-
* *Local transaction submission protocol(local-tx-submission):* Used by local clients (typically wallets or CLI tools) for the purpose of submitting transactions to the local node. The client sends a request with a single transaction and the server either accepts the transaction (returning a confirmation) or rejects it (returning the reason).
52
-
* *Local state query protocol(local-state-query):* As part of the NtC protocol suite, the local state query mini-protocol allows querying of the consensus and ledger state. Queries depend on the era (Byron, Shelley, etc.) and basic operations include acquiring and releasing the ledger state or running queries against the acquired ledger state.
47
+
* *Keep alive mini protocol(keep-alive):* A member of the Node-to-Node(NtN) protocol suite, this protocol provides keep alive messages and measures the round trip times of these messages.
48
+
* *Chain synchronization protocol(chain-sync):* Allows for local synchronization of the blockchain via communication with several upstream and downstream nodes. This protocol is responsible for the transfer of full blocks when used as part of the Node to Client(NtC) protocol, whereas instances used as part of the Node to Node(NtN) protocol only transfers block headers.
49
+
* *Block fetch protocol(block-fetch):* Enables a node to request and download blocks from other nodes.
50
+
* *Node-to-node transaction submission protocol(tx-submission):* A protocol used to transfer transactions between nodes, where the initiator requests new transactions and the responder returns them. In this protocol, the server acts as the initiator while the client acts as the responder, making it well suited for a trustless setting.
51
+
* *Local transaction submission protocol(local-tx-submission):* Used by local clients (typically wallets or CLI tools) for the purpose of submitting transactions to the local node. The client sends a request with a single transaction and the server either accepts the transaction (returning a confirmation) or rejects it (returning the reason).
52
+
* *Local state query protocol(local-state-query):* As part of the NtC protocol suite, the local state query mini-protocol allows querying of the consensus and ledger state. Queries depend on the era (Byron, Shelley, etc.) and basic operations include acquiring and releasing the ledger state or running queries against the acquired ledger state.
53
53
54
-
==== Inter-process communication(IPC) protocols
54
+
==== Inter-process communication(IPC) protocols
55
55
56
-
The Cardano node IPC protocols are best described as protocol suites(((protocol, suites))) containing a number of mini protocols that allow communication between Cardano node processes. These protocol suites(((protocol, suites))) come in two flavors: Node-to-Node (NtN) and Node-to-Client (NtC).
56
+
The Cardano node IPC protocols are best described as protocol suites(((protocol, suites))) containing a number of mini protocols that allow communication between Cardano node processes. These protocol suites come in two flavors: Node-to-Node (NtN) and Node-to-Client (NtC).
57
57
58
-
===== Node-to-node(NtN) IPC
58
+
===== Node-to-node(NtN) IPC
59
59
60
60
The NtN IPC is responsible for transferring transactions, block header transfers, and fetching blocks between TCP connected nodes. This IPC uses the following mini protocols(((mini, protocols))):
61
61
@@ -66,7 +66,7 @@ The NtN IPC is responsible for transferring transactions, block header transfers
66
66
67
67
image::network_ntn.png[title="Node-to-Node"]
68
68
69
-
===== Node-to-client(NtC) IPC
69
+
===== Node-to-client(NtC) IPC
70
70
71
71
The NtC IPC facilitates the connection between a local full node and a local client that consumes data but does not actively participate in consensus, such as a wallet. The NtC allows local applications(((local, applications))) to interact with the blockchain through the connected full node. Much like the NtN IPC, the NtC IPC uses a similar design but rather than using TCP to connect to other nodes over a public network, the NtC uses local pipes. This IPC uses the following mini protocols:
72
72
@@ -82,7 +82,7 @@ Within the _network layer_ of the Cardano node is a _multiplexing layer_, which
82
82
83
83
image::network_mux.png[title="mux"]
84
84
85
-
==== Peer to peer(P2P) networking
85
+
==== Peer to peer(P2P) networking
86
86
87
87
The Cardano network benefits from the capabilities of a dynamic P2P system where nodes may automatically search for, connect with, and actively manage connections with other nodes allowing the network to be robust, decentralized, and flexible. The P2P stack is under continual development with regular increases in functionality. Through active peer selection and policy based exclusively on local information of the node, Cardano’s P2P system significantly reduces data diffusion times(((data diffusion, times))) across the network.
88
88
@@ -126,7 +126,7 @@ Research found 2-20 to be ideal for hot peers since block headers(((block, heade
126
126
127
127
Warm peers can be quickly promoted to hot peers as candidates during the hot peer churn. The promotions and demotions between warm and hot rely on upstream measurements(((upstream, measurements))), while the churn between warm and cold is intended to discover network distances with the purpose of continually searching for better peers in a constantly changing network, where nodes may join and leave the network at any time.
128
128
129
-
For those wishing to further research the mechanisms behind Cardnao networking protocols, please refer to the following sources:
129
+
For those wishing to further research the mechanisms behind Cardano networking protocols, please refer to the following sources:
0 commit comments