Как операторы пула выполняют хеширование?

Для каждой «сетки», обслуживаемой пулом, для блока должен быть рассчитан корень Merkle. Время работы SHA-256 пропорционально количеству «кусков» из 256 бит, а в типичном блоке будут тысячи этих фрагментов (заголовок блока имеет три, после предварительной обработки). Таким образом, оператору пула потребуется примерно хеширование в диапазоне Mhash /sec. До сих пор я прав?

Индивидуальные шахтеры нуждаются в гораздо большей мощности хэширования, но в более простой форме: вот заголовок блока с тремя блоками, предварительно обработанный; хэш его с каждым из 0000_0000x через FFFF_FFFFx в поле nonce. Если хеширующие двигатели специализируются на этой простоте, чтобы сделать их более дешевыми и /или быстрее, то они не работают так хорошо для операторов пула.

Итак, если я оператор пула или соло-шахтер, и мне нужно генерировать миллионы корней Merkle, каковы мои варианты? Имеют ли хеширующие двигатели (CPU /GPU /FPGA /ASIC) API, который я могу использовать?

6 голосов | спросил George Kangas 28 PMpSun, 28 Apr 2013 23:45:39 +040045Sunday 2013, 23:45:39

2 ответа


1

Пул обычно создает уникальный корень merkle для каждого запроса сети шахтером. Если он принимает трудности с 1 долей, шахтер может потратить в среднем около 4000 мегабайт на этот блок (и будет зарабатывать в среднем 1 акцию на каждую сетку).

Чтобы создать заголовок блока для каждого шахтера, оператор пула изменяет некоторую уникальную информацию в первой (поколение) транзакции блока, а затем перефразирует блок для создания корня merkle. Если это делается наивно, это займет хеширование O (N log N) sha256 (где N - количество транзакций в добываемом блоке). Сохраняя некоторую информацию при вычислении последнего корня merkle, вы можете пересчитать изменение в транзакции генерации только с помощью хэшей O (log N).

С сотнями транзакций на блок отношение хэшей, выполняемых оператором пула и шахтерами, превышает 100 миллионов к 1.

Для еще большей экономии пулы могут принимать запрос getblocktemplate api вместо запроса на сетку. Этот режим позволяет шахтеру генерировать свои собственные заголовки блоков и шахты в среднем за 10 минут, прежде чем их нужно обновить пулом.

ответил mckoss 29 AMpMon, 29 Apr 2013 02:39:49 +040039Monday 2013, 02:39:49
1

Одной вычислительной частью работы сервера является создание новых корней merkle. Как упоминает mckoss, это становится намного быстрее, если вы только пересчитываете ветвь merkle, которая изменяется транзакцией нового поколения вместо пересчета всего дерева merkle.

Другая вычислительная часть работы сервера проверяет доказательства работы, которые затем отправляются. В общем, это означает хеширование двух блоков SHA-256 и проверка результата в отношении сложности. Но если есть несколько доказательств работы с одним и тем же корнем merkle, тогда вы можете рассчитать середину штата один раз, а затем просто хеш один SHA-256 кусок для каждого доказательства работы, которую вы хотите проверить. Так же, как клиенты делают с rollntime.

Таким образом, каждый новый корень merkle - это работа для генерации, а также создает больше работы позже, требуя вычисления новой середины.

BitMinter использует возможность прокатки поля ntime как на сервере, так и на клиенте. Каждый раз, когда настенные часы нажимают вперед одну секунду, вы обновляете поле ntime данных блока новой меткой времени. Затем вы можете повторно использовать все корни merkle и midstates, которые у вас есть с предыдущей секунды.

Это экономит огромное количество работы на сервере, и именно так BitMinter может работать с низкой нагрузкой на одном сервере с 2-3 TH /s hashpower, в то время как некоторым (недостаточно оптимизированным) пулам нужен новый сервер для каждые 300 ГГц /с мощности.

С тех пор такие оптимизации стали менее важными. Больше клиентов начали поддерживать rollntime. Серверы и клиенты начали использовать труд сложности выше 1, что означает, что на сервере должно было быть проверено гораздо меньше работы. А затем появятся новые протоколы для замены getwork: Stratum и GBT (getblocktemplate). С помощью этих протоколов сервер просто генерирует шаблон, который очень дешево для генерации, тогда клиенты выполняют более тяжелую часть создания работы на основе шаблона.

Я по-прежнему считаю, что для клиентов рекомендуется использовать трюк ntime для повторного использования корней merkle и midstates, что позволяет использовать повторное использование midstate на стороне сервера, хотя это уже не большая проблема.

ответил Dr.Haribo 2 Maypm13 2013, 19:26:50

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132