回复：RFC：随发布压缩包附带区块链 1-74000？
原始发布页
打开来源页面查看 1 个交叉存档
不管此前还说了什么，目前的下一步是：
引用
应该有人试验不同的 Berkeley DB 设置，看看是否有某种设置能让下载速度显著加快。如果发现了实质性的改进，我们就可以再研究具体细节。
具体来说，我怀疑增加读取缓存可能会很有帮助。
引用自：jgarzik，2010 年 11 月 28 日 02:33:29 AM
IRC 上又有一位新用户，这次用的是 Linux，下载速度是每 4 秒 1 个区块——预计总下载时间约为 4 天。
那就是某个更具体的地方出了问题。这不是正常的初始下载时间所致。没有更多细节就无法诊断。如果是因为下载速度慢，那么在 10-20 分钟后，下一个区块的广播本应使它切换到更快的来源，届时速度有没有加快？debug.log 中可能有线索。他们的互联网连接有多快？是一直很慢，还是只在某个时间点慢了下来？
引用
从创世区块到第 74000 个区块的哈希都已硬编码（编译）进 bitcoin，因此我们没有理由不能从任何地方自动下载区块数据库的压缩 zip 文件，解压、验证，然后开始运行。
第 74000 个区块的检查点不足以保护你，如果下载已经超过 74000，它更是毫无作用。-checkblocks 做得更多，但仍然很容易被绕过。你依然必须信任 zip 文件的提供者。
如果存在一个“验证”步骤，它会和目前正常的初始下载耗时一样长，因为瓶颈在于建立索引，而不是数据下载。
引用自：jgarzik，2010 年 11 月 28 日 07:33:55 AM
想必将来某个时候会有只下载区块头的轻量级客户端，但那样仍会有几十万个区块头……
每个区块头 80 字节，而且不需要建立索引。可能只要 1 分钟。
引用
使用一种并非为批量数据传输设计的协议（比特币 P2P）传输未压缩数据。
这些数据大多是无法压缩的哈希、密钥和签名。
初始下载速度并不能反映该协议的批量数据传输速率。限制因素是下载过程中建立索引的速度。
英文原文
展开英文原文
Despite everything else said, the current next step is:
Quote
Someone should experiment with different Berkeley DB settings and see if there's something that makes the download substantially faster. If something substantial is discovered, then we can work out the particulars.
In particular, I suspect that more read caching might help a lot.
Quote from: jgarzik on November 28, 2010, 02:33:29 AM
Another new user on IRC, Linux this time, was downloading at a rate of 1 block every 4 seconds -- estimated total download time around 4 days.
Then something more specific was wrong. That's not due to normal initial download time. Without more details, it can't be diagnosed. If it was due to slow download, did it speed up after 10-20 minutes when the next block broadcast should have made it switch to a faster source? debug.log might have clues. How fast is their Internet connection? Was it steadily slow, or just slow down at one point?
Quote
We have the hashes for genesis block through block 74000 hardcoded (compiled) into bitcoin, so there's no reason why we shouldn't be able to automatically download a compressed zipfile of the block database from anywhere, unpack it, verify it, and start running.
The 74000 checkpoint is not enough to protect you, and does nothing if the download is already past 74000. -checkblocks does more, but is still easily defeated. You still must trust the supplier of the zipfile.
If there was a "verify it" step, that would take as long as the current normal initial download, in which it is the indexing, not the data download, that is the bottleneck.
Quote from: jgarzik on November 28, 2010, 07:33:55 AM
Presumably at some point there will be a lightweight client that only downloads block headers, but there will still be hundreds of thousands of those...
80 bytes per header and no indexing work. Might take 1 minute.
Quote
uncompressed data using a protocol (bitcoin P2P) that wasn't designed for bulk data transfer.
The data is mostly hashes and keys and signatures that are uncompressible.
The speed of initial download is not a reflection of the bulk data transfer rate of the protocol. The gating factor is the indexing while it downloads.