EDIT: улучшился на основе предложений XertroV

Мне кажется, что основная проблема заключается в том, что весь блок вознаграждение (coinbase + сборы) собирается одного шахтера. Обратите внимание, я использую слово "шахтер" в строгом смысле этого слова, то есть, в сущности, которая решает, какие операции поместить в блок и получает распределять вознаграждение, то есть, оператор в майнинг.

Решение, следовательно, может быть несколько военнопленных и несколько наград на блок, например, три (это довольно произвольное число, возможно, пяти будет работать лучше, но ради примера я пойду с тремя военнопленными на блок).

Способ дробить военнопленные может быть следующим. Пусть PoW1, PoW2 и PoW3. Любой один PoW действителен только подмножество операций (1/3 всех сделок в случае трех военнопленных). Однако горняк не должен знать заранее, какое подмножество операций она ищет решение для. Таким образом, каждый шахтер выбирает все транзакции из mempool просто как есть, и включает в себя операции, чтобы распределить вознаграждение блока. Если шахтер находит решение (а) временное значение, то оно передается, так что другие шахтеры знают, что PoW была завершена, поэтому они могут переключиться на другие, которые военнопленных не были найдены.

Минер, который находит окончательное PoW может транслировать блок. Протокол навязывает, что первый шахтер, который транслирует решения замков в награду за этот ПР. Это как стимул для шахтера немедленно транслировать решение, как только он находит его. Если два или более шахтеров транслировать решение для ПР в то же время, протокол может случайным образом выбрать один.

Должно быть невозможно шахтер, чтобы знать, какие сделки его PoW будет действителен в течение. Поэтому, устанавливая множество сделок, одобренных каждым ПР. должно быть сделано как можно позже, так только тогда, когда блок доработан шахтером, который нашел последний недостающий POW и включает в себя все военнопленных в блоке и транслирует его. Отображение между ПР. и набором операций должно быть случайным, детерминированным и невозможно манипулировать. Поскольку точное значение одноразового номера невозможно управлять, отображение каким-то образом должны быть получены из него. Кроме того, входы и выходы транзакций не могут манипулировать комбайн, так что они также могут быть использованы. Мы могли бы взять хэш-моды 3 такого неизменного имущество сделки плюс окончательного нонса, оказывающую 0, 1 или 2 для каждой сделки. Так хэш (tx_property, final_nonce)% 3 дает 0, 1 или 2 для каждой сделки, которая, в свою очередь, диктует, если сделка относится к PoW1, 2 или 3. Таким образом, POW контроль только 1/3 всех сделок.

пример
Предположим, что шахтер нашли PoW1 включены сделки 1, 2, 3, 5, шахтер, который нашел PoW2 включен 1, 2, 3, 4, 5, 6 и шахтер, который нашел PoW3 включен 1, 2, 5. Предположим также, после применения хэш (tx_property, final_nonce)% 3 к каждой сделке, оказывается, что PoW1 справедливо для TX 1, 2, PoW2 действителен в течение 3, 4 и PoW3 действует в течение 5, 6. множество действительных операций будет потом быть 1, 2 (PoW1), 3, 4 (PoW2) и 5 ​​(PoW3). Сделка 6 не входит в блоке, как действительные, так как он принадлежит к PoW3 и PoW3 не включают сделки 6.

Эффект от этого будет то, что контроль > 50% от скорости сети хэша не достаточно, чтобы постоянно контролировать все операции. Увеличение количества военнопленных на блок от трех до пяти уменьшает количество операций под контролем одного крупного шахтера еще дальше. Конечно, для достаточно большой доли всех хеш власти, шахтер снова будет в состоянии контролировать все блоки, но это число будет 80% в течение пяти военнопленных плюса, что она никогда не может быть уверена, что он находит POW для злонамеренного себя -inserted сделки перед другим шахтером, так как он не может предсказать, какой набор сделок PoW находит справедливо для. Это снижает возможность злоупотреблений горнодобывающей власти.