Pages:
Author

Topic: Другой способ проверки PoW блока - page 2. (Read 1164 times)

newbie
Activity: 13
Merit: 0
Предлагаю такой вариант проверки качества блоков вместо перебора хэшей и увеличения сложности. Критика (конструктивная) приветствуется.

Сначала о том, что это дает:
- уменьшает вероятность ситуации, когда 51% мощности захватывается одной группой майнеров. Для этого им надо захватить сразу несколько разных параметров. Если майнеры захватывают один из параметров, вес этого параметра уменьшается
- майнерам выгоднее заниматься не подбором хэшей, а сбором транзакций. Что в принципе и является их основной задачей, а не подбор хэшей. Подбор хэшей - это очень сложная и бесполезная работа (типа "копайте от забора и до обеда").
- уменьшается выгодность майнинга на видеокартах. Почти бесполезен майнинг на асиках.
- расширяет возможность программирования процесса формирования блоков на языки, не имеющие доступ к видеокартам.

Недостатков пока не нашел. Возможно, они есть. Для этого и выкладываю эту тему на форум Smiley



Порядок такой:

1. На каждом блоке ставится таймштамп в заголовке. Майнер принимает этот блок только при соблюдении двух условий: первое - время по UTC в данный момент больше хотя бы на секунду, чем таймштамп блока; второе - между таймштампом полученного блока и предыдущего блока прошло как минимум 1200 секунд (ну или другое установленное время).

2. Естественно проверяется валидность всех транзакций, проверка правильности подсчета хэшей и т.п. Если где то найдена ошибка - блок просто отклоняется.

3. Если блок не отклоняется, то проверяется не "прилипился" ли ранее к предыдущему блоку другой блок. Если не прилипился, то блок ставится следующим. Если к предыдущему блоку уже прилипился какой то другой блок, то эти два конкурирующих блока проверяются на качество.

Далее описание того, как проверяется качество конкурирующих блоков:

4. У блока "А" и у блока "Б" подсчитывается 1 - количество транзакций в них (далее А1 и Б1); 2 - сумма передаваемых в транзакциях токенов (далее А2 и Б2); 3 - время в секундах между таймштампом каждого из них и таймштампом предыдущего блока (далее А3 и Б3); 4 - хэш каждого блока (А и Б), выполненный последовательно столько раз, сколько в нем разница между таймштампами (далее А4 и Б4).

Немного о том, почему хэширование последовательное. Во первых что такое последовательное хэширование. Думаю, такой упрощенный скрипт лучше тысячи слов  Wink :
result = this_block;
while (i  result = hash(result);
  i++;
}
return result;
А теперь о том, зачем оно последовательное. Большинство ALU видеокарт будут сидеть-курить, ждать когда посчитается предыдущая итерация. А это позволит уравнять скорость расчета хэша на видеокарте и на процессоре. Что в свою очередь немного сбавит спрос на китайские видюхи Smiley, а также позволит программировать процесс формирования блоков на языках программирования, у которых нет доступа к видеокарте (например PHP). Ну и конечно же, это очень усложнит расчет на АСИКах.


Возвращаемся к алгоритму проверки качества конкурирующих блоков.

5. Сравниваем А1 и Б1 (количество транзакций в блоке) по логарифмической шкале. Например: пусть А1 = 8, Б1 = 4. Тогда по первому параметру у блока А количество баллов log("8")=0,90309. А у блока Б1 log("4")=0,60206.
Почему параметры сравниваются по логарифмической шкале - чтобы явное преимущество блока по одному из параметров не давало гарантии к его принятию всеми майнерами независимо от значений других блоков. Для еще более качественного уравнивания силы вклада отдельного параметра, можно увеличивать/уменьшать основание логарифма для этого параметра или умножать результат на корректирующий коэффициент. Все зависит от конкретного проекта и требований. Здесь рассмотрим общий вариант.

6. Аналогично по логарифмической шкале сравниваем А2 и Б2 (суммы передаваемых токенов). Пусть А2 = 0,456, Б2 = 12,3. Тогда количество баллов получится: -0,341 и 1,09 соответственно.

7. Сравниваем А3 и Б3 (разницу таймштампов блоков). Количество баллов определяется таким образом: минимально допустимая разница (выше в пример была приведена цифра 1200) делится на разницу между указанной в таймштампе сравниваемого блока и ей самой. От результата берется логарифм. Делится на корректирующий коэффициент (константу).
Приведу пример, чтобы через 20 минут (1200 секунд) блок получил чуть больше 1 балла, а через 30 минут (1800 секунд) блок получил чуть меньше 0,1 балла: result = log(timestamp/(1199-timestamp))/7. Где 7 - корректирующий коэффициент; 1199 - на секунду меньше 1200, чтобы избежать деления на 0.
Ну а для нашего случая пусть А1 = 1300, а Б1 = 1600. Тогда у блока А получится 0,3534 балла, у блока Б получится 0,1565 баллов.

8. Сравниваем хэши (естественно предварительно проверив их в п.2. на правильность). Переводим значения обоих хэшей в десятичную систему. Большее значение делим на меньшее, от результата берем логарифм (это если надо найти не меньший хэш, а больший; если хочется именно меньший, то можно делить не хэши а разницу между хэшем и максимально возможным его значением ну или еще какой-нибудь вариант, эти детали зависят от того, в каком проекте проверяются блоки). От полученного логарифма еще раз берем логарифм (или увеличиваем основание логарифма - кому как больше нравится). Логарифм от логарифма надо брать, чтобы значимость этого параметра не была намного больше других трех, так как отношение большего хэша к меньшему может быть очень велико. Тогда блоку с меньшим хэшем достанется 0 баллов, а блоку с большим хэшем достанется какое то положительное число.

Для нашего примера: пусть А4 дал нам 0 баллов, а Б4 дал нам 1,051 балл.

9. Можно тупо сложить эти параметры для каждого блока и выбрать большее. Но, чтобы еще уменьшить вероятность атаки 51%, можно каждый параметр каждого блока умножить на коэффициент, который прописан в предыдущем блоке. Это позволит уменьшить силу отдельного параметра, если он в предыдущих блоках показывал все большую и большую монополизацию майнеров. Эти коэффициенты могут меняться в пределах от 20% до 40%. То есть, например, если в нескольких блоках подряд большое влияние на выигрыш блока в соревнованиях с конкурентами оказывает параметр суммы передаваемых токенов, то сила этого параметра уменьшается в пользу других параметров. По каким алгоритмам определяется сила этих коэффициентов не буду расписывать, а то слишком "многабукф" получается Smiley . Если кому интересно, отдельно опишу.

Ну и для окончания расчетов для нашего примера (дабы все-таки определить победителя Smiley ). Пусть, предыдущим блоком заданы коэффициенты К1, К2, К3 и К4 для соответствующих параметров такие: 23%, 25%, 28%, 24%.
Тогда для блока А получится суммарный балл: 0,90309*23%+(-0,341)*25%+0,3534*28%+0*24% = 0,22141
Для блока Б получится суммарный балл: 0,60206*23%+1,09*25%+0,1565*28%+1,051*24% = 0,70703
В итоге блок Б принимаем, а блок А - отвергаем.

Если сравниваются не одиночные блоки, а цепочки блоков, то сравнивается сумма баллов всех блоков в каждой из цепочек.
Pages:
Jump to: