Да. Но не для вопросов "справедливость", А для вопросов, присущих требованиям криптографической безопасности (которые очень плохо!) Из ПР. PoW безопасности основана на нападавший необходимости тратить по крайней мере, столько экономичную усилий, чем "хороший парень" (В крипто ПР, хороший парень, по определению, шахтер, который добавляет блок, потому что он один определение последнего консенсуса). "плохой парень" это один пытается изменить прежний консенсус по другим причинам, чем "осиротение по ошибке"Для того, чтобы отменить транзакцию (и двойной расходы); цензор сделки (DoS), .... Если методы известны плохой парень, что хороший парень не должен использовать, то экономическая стоимость атаки становится меньше, чем стоимость изготовления оригинального консенсуса!


Ну, я не изучал эту часть, но у меня есть твердая часть воображая, что asicboost не может быть применена к любым изменениям в протоколе. Может быть, расчеты должны быть реорганизованы или так, но, не посмотрев на него в деталях, я не вижу, на первый взгляд, как вы не можете использовать ASIC BOOST, потому что, как я понимаю, это просто умнее повторно -организация расчетов, которые должны быть сделано * в любом случае *. Таким образом, по существу, вместо того, чтобы делать их более в случайных заказов, организовать их лучше, так что вы можете повторно использовать расчеты вы бы просто сделать более, не задумываясь. Но возможно, что * способ * организации это отличается с новым протоколом, и, возможно, что это щурит так, как это * в настоящее время * реализованы. (*)

Я хотел бы отметить также, что уже сейчас, стандартный способ сделать хэш вычислений, делает очень похожую вещь, организуя вычисления таким образом, что многие из них не должны быть тупо переделаны: первый вызов функции сжатия повторно не сделан, когда цикл по нонсу, что происходит только во втором блоке. Так "организуя свои вычисления так, что вы не делаете все явные полные хэши всех протестированных блоков, но результаты повторного использования" уже стандартная практика. Asic импульс просто толкает это несколько дальше.

(*) Причина, почему я думаю, что это просто следующий, но, как я сказал, может быть формальности, которые избегают меня, так как я не смотрел на нее.

То, что происходит сейчас, что есть в заголовке два поля, которые могут быть настроены для того, чтобы удовлетворить трудности: есть одноразовое значение, 32 бит, во второй части заголовка, и есть корень Merkle дерева (32 байта в общей сложности, 256 бит), из которых 28 байт в первой части, и 4 байта (32 бит) находятся во второй части.
Трюк ASIC повышения является то, что вместо того, чтобы использовать Merkle корни деревьев, которые нужно попробовать в произвольном порядке, можно организовать их на куски, где последние 4 байта являются одинаковыми (что случается один раз за каждые 65000 Merkle корней деревьев пытались, так что если вы собираетесь попробовать миллиард Merkle корни деревьев, вы используете их в пакетах около 15000 корней с одинаковыми последними 32 битами, а затем попытаться для каждого Нонс значения, в 15000 корни первого, и вы должны повторно вычислить "расписание ключей" второго блока только один раз в 15000).

Я не вижу, как это изменится, если мы сохраним ту же самую структуру заголовка. Может быть, как дерево Merkle придется рассчитываться будет отличаться, но это единственная ручка одна имеет, рядом с одноразовым номером, который слишком мал. Так что я не вижу, как Основныеоперации импульс в той или иной форме, уйдет.