【比特币】P2P网络
The Bitcoin network uses simple methods to perform peer discovery and communicate between nodes. The following section applies to both full nodes and SPV clients, with the exception that SPV’s Bloom filters take the role of block discovery.
Peer Discovery
Bitcoin Core maintains a list of peers to connect to on startup. When a full node is started for the first time, it must be bootstrapped to the network. This is done automatically today in Bitcoin Core by a short list of trusted DNS seeds. The option-dnsseed can be set to define this behavior, though the default is 1. DNS requests return a list of IP addresses that can be connected to. From there, the client can start connecting the Bitcoin network.
Alternatively, bootstrapping can be done by using the option -seednode=, allowing the user to predefine what seed server to connect to, then disconnect after building apeer list. Another method is starting Bitcoin Core with -connect= which disallows the node from connecting to any peers except those specified. Lastly, the argument-addnode= simply allows the user to add a single node to his peer list.
After bootstrapping, nodes send out a addr message containing their own IP to peers. Each peer of that node then forwards this message to a couple of their own peers to expand the pool of possible connections.
To see which peers one is connected with (and associated data), use thegetpeerinfo RPC.
Connecting To Peers
Connecting to a peer is done by sending a version message, which contains your version number, block, and current time to the remote node. Once the message is received by the remote node, it must respond with a verack message, which may be followed by its own version message if the node desires to peer.
Once connected, the client can send to the remote node getaddr and addrmessages to gather additional peers.
In order to maintain a connection with a peer, nodes by default will send a message topeers before 30 minutes of inactivity. If 90 minutes pass without a message being received by a peer, the client will assume that connection has closed.
Block Broadcasting
At the start of a connection with a peer, both nodes send getblocks messages containing the hash of the latest known block. If a peer believes they have newer blocksor a longer chain, that peer will send an inv message which includes a list of up to 500 hashes of newer blocks, stating that it has the longer chain. The receiving node would then request these blocks using the command getdata, and the remote peerwould reply via block messages. After all 500 blocks have been processed, the node can request another set with getblocks, until the node is caught up with the network.Blocks are only accepted when validated by the receiving node.
New blocks are also discovered as miners publish their found blocks, and these messages are propagated in a similar manner. Through previously established connections, an inv message is sent with the new block hashed, and the receiving node requests the block via the getdata message.
Transaction Broadcasting
In order to send a transaction to a peer, an inv message is sent. If a getdataresponse message is received, the transaction is sent using tx. The peer receiving this transaction also forwards the transaction in the same manner, given that it is a valid transaction.
Memory Pool
Full peers may keep track of unconfirmed transactions which are eligible to be included in the next block. This is essential for miners who will actually mine some or all of those transactions, but it’s also useful for any peer who wants to keep track of unconfirmed transactions, such as peers serving unconfirmed transaction information to SPV clients.
Because unconfirmed transactions have no permanent status in Bitcoin, Bitcoin Core stores them in non-persistent memory, calling them a memory pool or mempool. When a peer shuts down, its memory pool is lost except for any transactions stored by itswallet. This means that never-mined unconfirmed transactions tend to slowly disappear from the network as peers restart or as they purge some transactions to make room in memory for others.
Transactions which are mined into blocks that are later orphaned may be added back into the memory pool. These re-added transactions may be re-removed from the pool almost immediately if the replacement blocks include them. This is the case in Bitcoin Core, which removes orphaned blocks from the chain one by one, starting with the tip (highest block). As each block is removed, its transactions are added back to the memory pool. After all of the orphaned blocks are removed, the replacement blocks are added to the chain one by one, ending with the new tip. As each block is added, any transactions it confirms are removed from the memory pool.
SPV clients don’t have a memory pool for the same reason they don’t relay transactions. They can’t independently verify that a transaction hasn’t yet been included in a block and that it only spends UTXOs, so they can’t know which transactions are eligible to be included in the next block.
Misbehaving Nodes
Take note that for both types of broadcasting, mechanisms are in place to punish misbehaving peers who take up bandwidth and computing resources by sending false information. If a peer gets a banscore above the -banscore= threshold, he will be banned for the number of seconds defined by -bantime=, which is 86,400 by default (24 hours).
Alerts
In case of a bug or attack, the Bitcoin Core developers provide a Bitcoin alert servicewith an RSS feed and users of Bitcoin Core can check the error field of the getinfoRPC results to get currently active alerts for their specific version of Bitcoin Core.
These messages are aggressively broadcast using the alert message, being sent to each peer upon connect for the duration of the alert.
These messages are signed by a specific ECDSA private key that only a small number of developers control.
Resource: More details about the structure of messages and a complete list of message types can be found at the Protocol Specification page of the Bitcoin Wiki.