原始文献 / 论坛帖 / Re: RFC: ship block chain 1-74000 with release tarballs?
Re: RFC: ship block chain 1-74000 with release tarballs?
Bitcointalk · 2010-11-28 17:13:01 UTC
抛开其他人说的，先说当前下一步是什么：
引用自（……）：应该有人去试试不同的 Berkeley DB 设置，看有没有能让下载明显变快的。如果发现了明显有效的，我们再敲定细节。
我尤其怀疑，多点读缓存会很有帮助。
引用自 jgarzik（2010 年 11 月 28 日 02:33:29 AM）（https://bitcointalk.org/index.php?topic=1931.msg25017#msg25017）：IRC 上又来个新用户，这次是 Linux，下载速度是 4 秒一个区块——估计总下载时间约 4 天。
那就是有更具体的问题了。这不是正常初始下载该有的速度。没有更多细节就没法诊断。如果是下载慢，10–20 分钟后下一次区块广播应该让它换到更快的源，那时有没有变快？debug.log 里可能有线索。他们的网速多快？是一直稳定地慢，还是某个点突然变慢？
引用自（……）：创世区块到区块 74000 的哈希都硬编码（编译）进了比特币，那我们完全可以从任何地方自动下载一个区块数据库的压缩包，解开、验证，然后开始跑。
74000 检查点保护不了你，下载超过 74000 后它就没用了。-checkblocks 做得更多，但也很容易被绕过。你还是得信任那个压缩包的提供者。
如果真有“验证它”这一步，那花的功夫和现在正常初始下载一样长，而瓶颈是建索引，不是数据下载。
引用自 jgarzik（2010 年 11 月 28 日 07:33:55 AM）（https://bitcointalk.org/index.php?topic=1931.msg25058#msg25058）：想必将来会有只下载区块头的轻客户端，但那也有几十万个头……
每个头 80 字节，没有建索引的工作量。可能 1 分钟就够。
引用自（……）：用一个不是为批量数据传输设计的协议（比特币 P2P）传未压缩数据。
数据主要是哈希、密钥和签名，压缩不动。
初始下载的速度反映的不是协议的批量传输速率。限速因素是下载同时在做的建索引。
英文原文
Despite everything else said, the current next step is:
QuoteSomeone 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（https://bitcointalk.org/index.php?topic=1931.msg25017#msg25017）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?
QuoteWe 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（https://bitcointalk.org/index.php?topic=1931.msg25058#msg25058）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.
Quoteuncompressed 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.