Я придумал, как мне кажется интересный алгоритм консенсуса RndPOS, который способен противостоять даже диктату большинства, т.е. атаке 51%, имеет не слишком большие требования к вычислительным ресурсам.
Но есть одна загвоздка, а именно способна ли децентрализация противостоять подбору адреса следующего майнера. Вот сам алгоритм.
Введение
Хочу поделиться с сообществом идеей нового алгоритма консенсуса RndPOS.
На текущий момент все криптовалюты используют в основном POW (доказательство работы) или POS (доказательство владения долей).
Огромным недостатком алгоритма POW стала его сильно возрастающая сложность и требующая все больше и больше вычислительных мощностей, а для того чтобы увеличивать эти мощности, требуется вложение средств, чтобы продолжать майнить.
Как ответ на этот недостаток был создан алгоритм POS, где нет сильной вычислительной сложности, но есть требование к наличие средств на счете и чем больше этих средств, тем выше вероятность смайнить новый блок.
Прежде чем перейти к моему алгоритму, нам нужно понять для каких основных целей используется майнинг, а то многие думают, что для ненужных вычислений и печатания денег.
Главная задача майнинга – это создание уникальности в определенном промежутке времени. Тот майнер, кто первым находит текущий хеш и получает право создания блока. Изначально данный принцип был предложен для борьбы с почтовыми спамерами, чтобы они не могли заваливать пользователей миллионами своих сообщений. Перевядя же данный принцип на биткоин получили хороший способ сдерживания, но он оказался не идеальным, так как позволяет создавать форки (это когда два и более майнеров находят хеш в одинаковый промежуток времени и каждый рассылает свою версию блока). Понятно, что в нормально работающей сети эти форки схлопываются рано или поздно, а потому чем-то плохим не считаются, тем не менее это говорит о том, что данный способ не совсем подходит для криптовалюты, т.к. майнеры могут тратить на форки свою мощность и когда она схлопывается, то получается работа произведена зря. Это не очень оптимально.
Поэтому при создании алгоритма консенсуса RndPOS я учел этот момент и он будет полностью исключать форки.
Второй недостаток POW и POS это недостаточная децентрализация. Если рассматривать в динамике роста сети и развития криптовалюты, то мы видим как происходит постепенная централизация. В алгоритме POW за счет повышения сложности и наращивания мощности, а в POS за счет концентрации крупного капитала.
Централизация любой криптовалюты несет в себе риски злоупотребления, цензура транзакций и диктат своей воли всей остальной сети, а также при высокой централизации повышаются структурные риски сети, когда хакеры или правительство оказывают то или иное влияние на основную крупную структурную единицу или на наиболее крупную группу участников сети.
Этот недостаток в своем алгоритме я устранил тем, что создал низкий барьер входа для майнинга. Низкий как в плане вычислительной мощности, а также низкий и по денежным ресурсам.
Описание
Мой алгоритм решает следующую задачу – на миллионах компьютеров он создает случайный выбор, но одинаковый для всех результат.
Казалось бы здесь есть противоречие и просто невозможность данного события, тем не менее это так и вот как это реализовано.
Алгоритм будет работать на любых криптографических хешах, мои рекомендации это выбрать SHA3 Keccak. Особенность криптографических хешев в том, что они имеют стойкость к первому и второму перебору, а также стойкость к коллизиям. Эти особенности выходного значения хеш-функций позволяют сильно изменяться даже при незначительном изменении входа. Значение хеша не дает утечки информации даже об отдельных битах, которые поданы на вход.
Все это приводит к тому, что при изменении незначительном мы получаем непросчитываемый выход, а именно это свойство и будет лежать в основе моего алгоритма.
Как вы знаете главная особенность блокчейн – это связывание текущего блока и предыдущего при помощи хеширования, если где-то в предыдущих блоках произошло даже самое незначительное изменение, то произойдет изменение всех последующих хешев, что в итоге приведет к изменению значения конечного хеша.
Именно эти хеши алгоритм и будет использовать.
Алгоритм RndPOS
Адреса криптовалюты на которых храняться деньги должны быть в форме полноценного хеша и иметь такую же форму, как и у хешей блоков.
Теперь к алгоритму, вот его суть:
1. Все кто хочет быть майнерами и получать деньги за создание блока консервируют определенную сумму денег. Данная сумма небольшая и имеет привязку к стоимости комиссии перевода, это также позволяет в дальнейшем адаптироваться к изменению цен. Пусть эта сумма будет равна стоимости 10 средним комиссиям в 10 последних блоках и срок заморозки средств будет 7 дней.
2. Вычисляем сам хеш текущего созданного нами блока.
3. Берем значение предыдущего хеша.
4. Хешируем оба этих хеша. Это то, что происходит в обычном биткоине, ничего нового.
5. Теперь мы имеем хеш и начиная с конца, беря последнее значение хеша ничинаем поиск адресов (прошедшие срок заморозки и имеющие сумму равную или больше установленной) начинающееся на это значение.
6. Когда выявили все адреса, то берем второе с конца значение конечного хеша из пункта 4 и смотрим совпадения этого значения у адресов из группы, что мы отобрали. В данном случае это значение должно совпадать со вторым значением справа у выбранных адресов.
7. Беря таким образом значения и уменьшая выбранную группу адресов мы приходит к единственному адресу.
8. Только этому единственному адресу разрешается создать следующий блок и подписать его своей подписью. Подпись блока должна однозначно показывать какой адрес подписал этот блок.
9. Ожидаем только блок с подписью от вычисленного адреса.
10. Принимаем блок от разрешенного адреса.
11. Делаем его проверку на двойную трату и прочее.
12. В случае если не получаем блок от указанного адреса в течении допустим 1 минуты или сам блок некорректен или есть двойная трата в нем, то пункт 13.
13. Создаем спецблок из одной транзакции или команды. В данном случае мы наказываем спамера либо тразакцией забирая его все деньги с адреса на спецсчет сети или просто ликвидируем этот адрес со всеми там деньгами.
14. Вычисляем хеш этого спецблока и соединяем с предыдущим хешем и получаем общий хеш.
15. Теперь повторяем процедуру поиска начиная с пункта 5.
Как видите алгоритм консенсуса RndPOS достаточно прост и понятен. Более того, он позволяет с легкостью отбивать атаки 51% и больше, т.к. здесь нет форков и четко прописано от кого будет следующий блок.
Механизм согласования
При разделении и создание ситуации, когда у одной стороны 20 блоков, а у другой тоже 20 блоков.
Давайте попробуем представить ситуацию. На каком-то блоке был выбран следующий майнер и тут произошел континентальный разрыв связи. Сеть разделилась на 2 части. Поэтому в одной части сети этот майнер создал блок со своей подписью, а в другой этот блок от него не увидели и оштрафовали. Начиная с этого момента сеть начинает развиваться каждая по своему пути. Встает вопрос как это согласовать при восстановлении связи.
В данном случае нам понадобиться механизм согласования. Он будет действовать только в определенном временном окне возможностей (наиболее вероятно это сутки), а именно во всех случаях, когда происходил штраф не по причине двойных трат или других, а по истечении времени, то он будет опрашивать сеть на предмет нахождения потерянного блока от того конкретного майнера, как только он его находит, то заменяет в блокчейне спецблок штрафа на этот потерянный блок от майнера, далее вычисляется хеш и находиться новый адрес майнера и ищется уже его блок, таким образом есть временное окно которое позволяет восстановить сети потерянные блоки и объединиться, вполне возможна такая ситуация, что восстановление всей сети произойдет от потерянного блока на 5 блоков вперед, а остальные нагенеренные блоки будут ликвидированы из за не синхронизации сети. Все транзакции в этих потерянных блоках должны перейти в общий тразакционный пул, чтобы при перестроении блокчейна не было потери информации.
В случае же отражения глубинной атаке, то достаточно вставить в сам код один или несколько начальных генезис блоков и тогда уже никакая подмена блокчейна страшна не будет.
Нужно 5 сек, а 10 минут у нас уже давно есть...