Я просто сделал полную первоначальную синхронизацию в blockchain на низком конечную ноутбук работает Bitcoin Сердечник 0,12. Вот результаты:

Оборудование:
   Процессор: Pentium 4-жильный N3540 @ 2,16
   Диск: Seagate 5400 RPM 16MB Cache SATA 6,0 Гбит / с
   Оперативная память: 4 Гб

Программного обеспечения:
   Bitcoin Ядро v0.12 (bitcoind) / GCC 5.2.1 / Linux 4.2

Интернет-соединение:
   3,6 Мбайт / сек

Синхронизация резюме:
   Высота блока: 399811
   Синхронизация времени: 35:32
   Средняя нагрузка на процессор: 47%
   Максимальное использование оперативной памяти: 640 МБ (16%)
   Макс нетто использование: 2,4 Мбайт / с (67%)

Во-первых, я должен отметить, что 35,5 часов, чтобы загрузить и проверить blockchain (в настоящее время ≃67 ГБ) на бюджетный ноутбук является хорошим результатом, превышающий мои ожидания. В ускорениях обеспечиваемых libsecp256k1, несомненно, сыграли большую роль здесь.

Есть некоторые, которые касаются вопросов, однако: По мере протекания процесса синхронизации, использование диска и процессора увеличивается, и прогресс стал медленнее и медленнее. Это замедление находит свое отражение в кратком изложении хода ниже:

   ПРОГРЕСС ВРЕМЯ ВРЕМЯ (%)
   --------  ----   -------
   0%: 0,0% 00:00
   5%: 1:34 4,4%
   10%: 3:04 8,6%
   15%: 14,4% 5:07
   20%: 16,7% 5:55
   25%: 18,6% 6:36
   30%: 20,5% 7:17
   35%: 22,5% 7:59
   40%: 25,0% 8:53
   45%: 27,4% 9:45
   50%: 10:42 30,1%
   55%: 11:46 33,1%
   60%: 12:59 36,5%
   65%: 14:19 40,3%
   70%: 15:40 44,1%
   75%: 17:30 49,2%
   80%: 19:43 55,5%
   85%: 21:54 61,6%
   90%: 25:03 70,5%
   95%: 29:16 82,4%
   100%: 35:32 100,0%

Как видно из таблицы, потребовалось больше времени, чтобы синхронизировать последние 25% от blockchain, чем это было синхронизировать первый 75%. Еще более резко, почти 30% от общего времени синхронизации было потрачено только на последние 10% от blockchain. ОТКАЗ: Прогресс оценивается bitcoind (в функции GuessVerificationProgress) путем вычисления количества оставшихся сделок в blockchain с использованием сложной формулы. Неточности в этих оценках прогресса могут исказить данные и привести к неточным выводам.

В течение последних 10% от blockchain синхронизации, как в колонке злоумышлений "Вверх" и яростный стук головок диска показал, что активность диска становится совершенно очевидным узким местом, что приводит к CPU происходит в режиме ожидания дольше и более длительные периоды.

Когда не простые, использование процессора (который был низким в начале процесса синхронизации), достигло пика от времени около 90% в этом заключительном этапе. Большую часть времени процессора во время этих пиков потребляются сигнатурных проверки потоков (т.е. libsecp256k1), так что, вероятно, мало места для дальнейшей оптимизации здесь.

Пропускная способность сети достигла пика на уровне около 67% мощности, и поэтому никогда не является ограничивающим фактором.

Другой любопытный образец, который возник в течение более поздней стадии процесса синхронизации были длительные задержками (4-5 мин), в течение которого данные еще поступают через сеть с высокой скоростью, но оба диска и процессор были относительно холостым хода и мало или вообще не обновления цепи происходило. Это можно увидеть в следующей выдержке из данных блока опроса:

   ВРЕМЯ БЛОК НОВЫЕ БЛОКИ
   ----      -----   ----------
   22:36:25 148 триста двадцать один тысяча девятьсот семьдесят семь
   22:37:29 322112 135
   22:38:29 322212 100
   22:39:29 322345 133
   22:40:39 322467 122
   22:41:48 322599 132
   22:42:52 322740 141
   22:43:53 322885 145
   22:44:53 322979 94
   22:45:53 322979 0
   22:46:53 322979 0
   22:47:53 322979 0
   22:48:53 322979 0
   22:50:42 323125 146
   22:51:57 323324 199
   22:52:57 323467 143
   22:54:05 323631 164
   22:55:12 323791 160
   22:56:29 323996 205
   22:57:29 324045 49
   22:58:39 324085 40
   22:59:39 324107 22
   23:00:39 324112 5
   23:02:00 324193 81
   23:03:17 324342 149
   23:04:28 324491 149
   23:05:49 324671 180
   23:06:50 324835 164
   23:08:10 325037 202
   23:09:21 325185 148
   23:10:23 325287 102
   23:11:23 325376 89
   23:12:23 325402 26
   23:13:24 325402 0
   23:14:24 325402 0
   23:15:37 325439 37
   23:16:40 325600 161
   23:17:46 325727 127
   23:18:48 325904 177
   23:20:20 326114 210
   23:21:24 326236 122
   23:22:31 326349 113
   23:23:37 326441 92
   23:25:01 326502 61
   23:26:01 326503 1
   23:27:01 326503 0
   23:28:01 326503 0
   23:29:01 326504 1
   23:30:04 326598 94
   23:31:07 326756 158
   23:32:07 326917 161
   23:33:20 327087 170
   23:34:46 327259 172
   23:35:50 327378 119
   23:36:50 327506 128

Зазоры стали длиннее, как синхронизация прогрессировала (и замедлила):

   ВРЕМЯ БЛОК НОВЫЕ БЛОКИ
   ----      -----   ----------
   9:46:49 397357 59
   9:48:00 397397 40
   9:49:00 397423 26
   9:50:01 397442 19
   9:51:19 397498 56
   9:52:28 397541 43
   9:57:52 397616 75
   9:58:54 397660 44
   9:59:54 397663 3
   10:00:54 397663 0
   10:01:54 397663 0
   10:02:54 397663 0
   10:03:54 397663 0
   10:04:54 397663 0
   10:06:50 397720 57
   10:08:27 397779 59
   10:09:27 397779 0
   10:10:27 397779 0
   10:12:06 397817 38
   10:13:08 397857 40
   10:14:30 397888 31
   10:16:49 397952 64
   10:17:57 397982 30
   10:19:16 398042 60
   10:20:43 398098 56
   10:22:03 398146 48
   10:23:38 398193 47
   ...
   10:42:44 398692 23
   10:44:13 398729 37
   10:45:19 398756 27
   10:46:24 398782 26
   10:47:33 398805 23
   10:48:45 398834 29
   10:49:47 398860 26
   10:51:38 398910 50
   10:52:38 398914 4
   10:53:38 398914 0
   10:54:38 398914 0
   10:55:38 398914 0
   10:56:47 398924 10
   10:57:52 398956 32
   10:59:17 398991 35
   11:00:18 399028 37
   11:01:38 399073 45
   11:02:45 399110 37
   11:03:45 399117 7
   11:04:46 399117 0
   11:05:46 399117 0
   11:06:46 399117 0
   11:07:46 399117 0
   11:08:47 399135 18
   11:09:47 399171 36
   11:11:02 399214 43
   11:13:28 399320 106
   11:15:31 399394 74
   11:16:54 399440 46
   11:18:43 399503 63
   11:20:41 399575 72

Так как эти "мертвые зоны" могут быть отнесены ни к оборудованию, ни в сети, они должны быть результатом чего-то неоптимальным в программном обеспечении. На быстром взгляде, кажется, что 20-30% убыстрение может быть достигнуто путем исправления этой проблемы, так что есть работа для ядра дэвов, чтобы сделать здесь.

Вывод

Даже если дисконтировать возможные неточности в оценках прогресса, это видно из этих результатов, что синхронизация времени не является линейной функцией от размера блока цепи, но показательной один. Это имеет серьезные последствия для масштабируемости Bitcoin в: даже при отсутствии блока увеличения размера, синхронизировать время будет продолжать расти в геометрической прогрессии, как проходят годы. Если потребительский класс аппаратных средства не в состоянии идти в ногу с этим ростом (который не может быть исключен, теперь, когда закон Мура есть все, но официально был объявлен мертвым), может оказаться невозможным для обычных пользователей запускать полные узлы в каком-то момент не столь отдаленное будущее.