比特币是一种基于P2P网络的加密数字货币，本文将从P2P技术的角度来讲解比特币的架构和实现，通过跟传统P2P应用的对比，分析比特币的不同之处，以及这些差异点如何影响比特币的设计。
P2P技术
Peer-to-Peer技术可以在客户端节点之间直接建立联系，进行数据的分发，从而减少Client-Server模式下的服务器和带宽的消耗。这样不仅可以用更少的服务器资源为更大规模的用户提供服务，甚至还可以完全不用服务器的介入，纯粹通过用户节点的互联来进行资源的发布和分享，进而衍生出各种有趣的应用。
传统的P2P应用最常见的有三个领域：文件下载、视频播放、VoIP通信。文件下载领域有BitTorrent、eMule、迅雷等，视频播放领域有pplive、ppstream等，VoIP领域有Skype、YY语音等。
P2P应用主要包含两个层面，一是P2P网络的建立和维护，二是在P2P网络上分发数据。前者包括peer的发现、peer地址池管理、peer连接的建立和管理、peer之间的通信机制。后者包括数据的性质（用途、来源、格式等）、索引方式、校验、数据在内存、磁盘上的存储和在网络上的传输等。如果说前者是P2P应用的基础，那么后者就是P2P应用的核心。对不同的应用来说，P2P网络部分的架构差别较小，只在实现细节上会有一些不同的选择，而数据上的差别则往往决定着架构设计和实现方案上的不同。
因为我对VoIP了解有限，下面就以文件下载和视频播放为例来做对比分析。
P2P网络的搭建和维护
1 peer发现
文件下载和视频播放应用一般都是通过tracker之类的服务器来获取初始的peer地址列表，比特币也是类似，通过查询dns seeds来获取初始节点地址。另外，由于比特币的很多节点会长时间不间断运行，所以还会把这些节点地址保存在本地，下次启动时直接尝试连接。
2 peer连接建立和管理
P2P应用都会监听网络端口，接收其它peer的连接请求，同时也会向其它peer发起连接。连接建立后，会交换peer信息，进入P2P协议层的握手阶段。握手成功后，就可以跟这个peer正常通信，包括分发数据等。
对正在握手的peer和已经握手成功的peer，需要进行监控管理，检查通信超时和各种状态异常，踢掉一些状态较差的节点，尝试连接一些新的节点，从而保持足够数量的状态较好的peer连接，以进行高效的数据分发。
3 地址交换
握手成功的peer之间可以交换peer地址信息，以获取更多可连接的peer。
4 地址池
从tracker或dns seeds查询到的和通过地址交换得到的peer地址都会加入地址池来管理。peer连接管理模块会不断从地址池选择peer发起连接。地址池还会记录peer的通信历史，对状态较差或有问题的peer，降低其重连的优先级。
数据分发
前面的网络部分是P2P应用的共同之处，这一节的数据部分则是它们的差异之所在，也是这篇文章讲述的重点。
数据的用途和来源
比特币特殊之处在于数据的用途和来源。比特币的数据是交易信息，因为涉及到货币和资产，所以对数据的安全性要求很高，需要做比较强的校验。而交易数据由各个节点自行生成，是完全去中心化的，这导致交易数据无法保持顺序性，使得数据的索引方式变得更复杂，后面会进一步分析这一点。
文件下载和视频播放等应用对安全性的要求就没那么高，而且它们的数据要么事先生成好，并通过可信渠道发布（例如BT中torrent文件的生成和发布），要么由单个特殊的节点来生成和发布（例如视频播放里的发布节点或源节点），这样更容易保证数据的权威性和顺序性，所以对数据进行签名校验和顺序编号就可以使系统正常运转。
数据格式
对BT文件下载来说，数据就是一个文件或目录，目录也会被视为由各个子目录和文件拼接成的单个虚拟文件，所以BT的数据可以被抽象成单个的有限长度的字节数组。对于单个文件的视频点播来说，数据性质跟文件下载一样；对于某些格式的直播和HLS的点播来说，情况要复杂一些，因为受限于媒体格式的帧划分的边界，一般可以抽象成顺序的不定长的小文件列表。
比特币的数据格式比较不一样，它既不像BT里纯粹的字节数组，也不像视频点播和直播里附带媒体信息的字节数组和字节流，而是结构化的交易数据。
数据标识和索引方式
就像网页需要以URL（Uniform Resource Locator）为指引才能访问一样，P2P里的数据也需要先被标识和索引，然后才能进行分发。
文件下载和视频播放采用的是3个级别的索引。首先，一个文件下载任务和一个视频节目都是一个独立的资源，分发这个资源的peer独立成网，跟其它资源的peer一般不需要发生关联。其次，资源内部再进一步做切片和索引，例如BT里的文件会被切分成定长的piece，从0开始顺序编号，作为传输和存储的基本单位。最后piece内部还会进一步划分成更小的block，作为下载调度的单位。视频播放里的单文件点播也跟BT一样，直播（包括HLS直播）和HLS点播里则可以把每个不定长的小文件视为一个piece，进行顺序编号，piece内部一样做定长切片，作为下载调度的单位。有了这3级索引，就可以唯一的标识P2P网络上传输的一个数据片。
比特币里采用的是2级索引。比特币不像前面那样按任务和节目划分网络，而是所有的peer都属于同一个网络。在这个网络里分发的数据有第一级的Block和第二级的Transaction。
由于比特币交易数据的生成是完全去中心化的，所以无法像文件下载和视频播放应用里那样对切片数据做顺序的编号和顺序的存储，只能以数据的hash作为唯一标识，并以链表而非数组的方式建立顺序的关联。这样就得到了区块链这种特殊的数据结构。
区块链并不是简单的把索引方式从数值变为hash，把数据结构从数组/字典变成链表，而是由于链表分叉的存在，导致区块链实际上变成了区块“树”，所以比特币的实现变得更复杂，例如在数据储方面，不仅要以hash为key存储所有的BlockIndex，还需要选择和记录最长（累积工作量最大）的已验证区块链表，并按区块高度做顺序存储；还有，下载Header时，需要提供已有Header的区块链路径采样做参考，也就是代码里的BlockLocator。但另一方面，基于分叉和侧链，也可以产生很多新的应用。
数据同步
在P2P网络中，peer一般需要广播自己有哪些(新)数据，以方便别的peer来下载。例如BT里会发送bitfield和have报文，视频播放应用里一般也有类似报文。比特币由于有大量的历史数据，所以历史数据不用广播，通过直接先下载BlockHeader数据的方式来探测，对最新的交易数据，用inv报文来广播。
知道别的peer有哪些数据后，就可以开始下载。BT一般采用分散化的下载调度，以促进全网数据分布的健康度。视频播放在采取顺序下载调度，从用户观看位置点开始做预下载。
比特币的数据下载过程就要麻烦一些，因为它的数据格式更复杂，既有Block又有Transaction。而且由于Block尺寸大，数量多，不适合放在内存中做处理，所以引入了BlockHeader和BlockIndex这些索引数据。在较新版bitcoin core中，一般先下载所有的BlockHeader，然后再开始下载Block，这个过程被称为Initial Block Download。
BlockHeader是区块的头信息，包括前向区块的哈希、merkle根哈希、时间戳和其它验证PoW需要用到的数据。BlockIndex是在BlockHeader基础上，根据区块链状态计算出的区块索引信息，包括区块的高度和前向BlockIndex的指针等。BlockHeader用于在P2P网络中传播，BlockIndex则用于节点内部做索引和各种处理。因为BlockIndex比较小，可以全部放在内存里，同时，它还会被写到磁盘的block/index数据库中，供程序下次启动后加载使用。
BlockHeader下载完后，就可以开始下载Block。根据已有的BlockIndex信息，寻找合适的几个peer，以Block的哈希值为索引来下载Block数据。对下载到的Block数据进行各种校验，包括验证Double-Spending和交易脚本签名等，校验通过的Block可以从中提取Coin(UTXO)信息，记录到chainstate数据库中，供以后校验新的交易。
没有被纳入Block的交易也可以通过广播后被下载，然后一边在通过验证后继续转发，一边存入交易池中等待做其它处理。
总结
比特币和其它P2P应用相比，在P2P网络方面并没有明显的差别，但由于比特币交易数据的生成是完全去中心化的和无序的，所以不能像文件下载和视频播放应用里那样做顺序的编号处理，只能简单的以链表的形式关联起来，这样就形成了区块链这种数据结构。
