比特币：点对点电子现金论文
原始发布页
打开来源页面查看 1 个交叉存档
哈尔·芬尼写道：
我认为，节点有必要为每条候选链分别保留一个与之关联的 待处理交易列表。 ……人们或许还会问……平均而言，一个给定节点同时必须 跟踪多少条候选链？
幸运的是，只需要为当前最佳分支保留一个待处理交易池。当最佳分支收到新区块时，ConnectBlock 会从待处理交易池中移除该区块的交易。如果另一个分支变得更长，它会在主分支上调用 DisconnectBlock，一直回退到分叉点，将区块交易放回待处理交易池，然后在新分支上调用 ConnectBlock，把同时存在于两个分支中的所有交易重新吸收回去。预计这类重组会很少发生，而且涉及的深度很浅。
经过这种优化，候选分支其实算不上任何负担。它们只需待在磁盘上，除非有朝一日成为主链，否则不需要加以关注。
或者像 James 之前提出的那样，如果网络广播 是可靠的，但依赖一种可能很慢的洪泛 算法，这会怎样影响性能？
广播很可能几乎完全可靠。如今 TCP 传输几乎从不丢失，而且广播协议带有重试机制，可以在一段时间后从其他节点获取数据。如果实践中广播速度比预期慢，可能就必须延长区块之间的目标时间，以免浪费资源。我们希望区块通常能在远少于生成所需的时间内传播完毕，否则节点会花费太多时间在已经过时的区块上工作。
我计划运行一项自动化测试，让计算机随机相互发送付款，并随机丢弃数据包。
- 比特币系统后来证明对社会有用且有价值，因此 节点运营者会觉得自己的努力正在为 世界作出有益贡献（类似于各种“@Home”计算 项目，人们自愿为公益事业贡献自己的计算资源）。
在这种情况下，我认为仅凭利他主义就足以让 网络正常运行。
如果我们能恰当地解释它，那么从自由意志主义的观点来看，它非常有吸引力。不过我更擅长代码而不是文字。
Satoshi Nakamoto
英文原文
展开英文原文
Hal Finney wrote:
I think it is necessary that nodes keep a separate pending-transaction list associated with each candidate chain. ... One might also ask ... how many candidate chains must a given node keep track of at one time, on average?
Fortunately, it's only necessary to keep a pending-transaction pool for the current best branch. When a new block arrives for the best branch, ConnectBlock removes the block's transactions from the pending-tx pool. If a different branch becomes longer, it calls DisconnectBlock on the main branch down to the fork, returning the block transactions to the pending-tx pool, and calls ConnectBlock on the new branch, sopping back up any transactions that were in both branches. It's expected that reorgs like this would be rare and shallow.
With this optimisation, candidate branches are not really any burden. They just sit on the disk and don't require attention unless they ever become the main chain.
Or as James raised earlier, if the network broadcast is reliable but depends on a potentially slow flooding algorithm, how does that impact performance?
Broadcasts will probably be almost completely reliable. TCP transmissions are rarely ever dropped these days, and the broadcast protocol has a retry mechanism to get the data from other nodes after a while. If broadcasts turn out to be slower in practice than expected, the target time between blocks may have to be increased to avoid wasting resources. We want blocks to usually propagate in much less time than it takes to generate them, otherwise nodes would spend too much time working on obsolete blocks.
I'm planning to run an automated test with computers randomly sending payments to each other and randomly dropping packets.
- The bitcoin system turns out to be socially useful and valuable, so that node operators feel that they are making a beneficial contribution to the world by their efforts (similar to the various "@Home" compute projects where people volunteer their compute resources for good causes).
In this case it seems to me that simple altruism can suffice to keep the network running properly.
It's very attractive to the libertarian viewpoint if we can explain it properly. I'm better with code than with words though.
Satoshi Nakamoto