Topic: Децентрализация против подбора - page 2. (Read 196 times)

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



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

- адрес майнера, который создал текущий блок. Данная величина мало и плохо прогнозируемая, т.к. определяется суммарными предыдущими данными.

Таким образом искомый адрес майнера для нового блока, это комбинация слабо и сильно меняющихся данных.


Теперь про объединение сети. Условно у нас есть временное окно в течении которого можно изменять блокчейн. В рамках этого временного окна клиент ищет блоки от майнеров, которые были оштрафованы на отсутствие от них блока, если он находит такой блок, т.е. номер штрафного блока совпадает с номером блока от майнера и его адрес совпадает с адресом в штрафном блоке, то этот блок он заменяет вместо штрафного.

Что происходит дальше, как мы только что заменили штрафной блок на найденый блок от майнера, мы начинаем перестраивать блокчейн. Т.е. представте, что мы нагенерили 20 блоков от общего блока. А изменили пусть даже первый от общего блока, таким образом остальные 19 блоков могут стать неактуальными. Поэтому пока их отложем в сторону.

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

В текущем моменте мы имеем объединенную сеть состоящую из 2-х подсетей в результате потери связи:

- первую, где был майнер на 1-ом блоке от общего и она имеет сейчас 20 блоков от общего.

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

Т.е. эти две разделенных сети синхронизировали только свои первые блоки от общего.


Далее во второй сети начинается поиск адреса майнера для следующего блока, в то время как в первой сети этот майнер получил штраф, т.к. от него не было блока.

Майнер во второй сети создает блок и рассылает сети. Что происходит:

- в первой сети приходит второй блок от общего, он заменяет собой штрафной блок и начинается переделка блокчейна.

- во второй сети, где уже прошла переделка блокчейна, он просто включается в цепочку блокчейна.


Таким образом, после потери связи и разделения сети на 2 равных сети, они по отдельности нагенерили по 20 разных блока от общего блока (место от которого пошло разделение), но при востановлении связи и соединении, они синхронизировались на 2 блока от общего, а остальные блоки у той и другой сети были удалены, транзакции в этих блоках были перемешены в мемпул.

Пожалуй для механизма согласования временное окно сутки это много и скорее это будет 1-3 часа.

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

А если блок так и не появиться от нужного адреса майнера, то создается штрафной блок и вычисляется новый адрес с которого должен прийти блок.



Так у меня он и есть объективный. Начальные блоки намертво встроены в код, поэтому он сам вычисляет адрес майнера следующего блока и принимает только эти данные и так блок за блоком.




Да у моего алгоритма идеология POS, он так и называется RndPOS, только в отличии от него не привязывается к большинству и величина денег не играет никакой роли.






А вот этого не могу понять, какую цепочку Вы хотите заменить в блокчейне, прошлую или создать будущую?

Легко! Хеш создается примерно со скоростью 100К в секунду на обычном компе на одном ядре.
Тем более нам нужен не конкретный, а просто наиболее близкий. Генерим миллиард, потом отбираем нужную цепочку адресов и первый адрес в цепочке встраиваем в генезис блок, все делов то день работы...




Дык все же зависит от адреса актуального майнера? Мне показалось что нет. Выше писали про объединение сети и там так получалось, что все адреса известны заранее.
Просто если это не так и адрес майнера меняется, то возможна атака из глубины. Я задним число переделываю все транзакции, в том числе что якобы положил давно себе деньги... В итоге все новые ноды, случайно соединившиеся со мной загрузят мою версию блокчейна и аналогично будут "заражать" остальные новые ноды, а если новых нод (например при неожиданном росте) будет больше старых, то мы заполоним сеть...


Еще раз про объективность и субъективность, дело не в плохом или хорошем PoW. Просто алгоритм консенсуса должен быть объективным (см. выше определение).


P.S.
Хотя, я тут подумал, даже если адрес предопределен я тоже самое могу сделать (сгенерить нужную цепочку адресов, переподписать ими блоки, а потом выкинуть все это в сеть). Все алгоритмы PoS этому подвержены, для защиты от таких атак применяются "чек-поинты". Но все это попахивает централизацией и не соответствует названию вашей темы



Оказывается то что вы пытаетесь придумать уже как всегда придумано


еще цитата из 2015 года:

Очень рад, что поддерживаете дискуссию.


Адрес майнера - это адрес кошелька, на который положена не большая сумма и которой нужно отстояться примерно 7 дней (это как классический POS только сумма не играет роли, только чтобы она была не меньше определенного количества. Сумма небольшая, чтобы каждый мог иметь у себя несколько кошельков). Поэтому Вам надо не только нагенерить, но и положить туда деньги. И этот кошелек активен станет только через дней 7. Поэтому не получиться создать кошелек с нужным адресом под следующий блок.





Естественно, что первые деньги и кошельки генерируются только создателем и это нормально. А теперь смотрите, я продаю Вам криптовалюту или просто раздаю. Чтобы это сделать я должен криптовалюту со своего кошелька перевести на ваш. А адрес своего кошелька генерируете только Вы, после этого эту сумму Вы допустим замораживаете для майнинга. И Вот пожалуйста уже в процессе выбора адреса майнера принимает ваш кошелек, номер которого я никак не смог бы при всем желании предугадать. А Вы такой не один будете и таким образом будет полно народа со своими адресами кошельков.

Либо Вы исходите из того, что создатель криптовалюты начиная с самого первого адреса, создает такие адреса кошельков, которые полностью совпадают по всем длине с условием. Ну тогда это сразу заметно будет, да и нагенерить конкретно заданный хеш не так легко.
Кроме того не забывайте о форс-мажорах, когда сервер создателя сгорел или прервалась связь на очень долгое время и блокчейн уже не перестроить, создадуться штрафные блоки, которые полностью поменяют порядок следующего адреса.




Как раз именно POW и несет угрозу останова криптовалюты. По началу это круто когда растет сложность и прочее, а потом Вы видите странную вещь как ньюйорское соглашение майнеров, что простой участник здесь никто, что майнеры объединившись уже сейчас могут начать цензуру транзакций.
Я уже не говорю о том, что для содержание мощностей требуется громадная энергия.

В то время как у моего алгоритма есть очень важных 2 вещи: это не требовательность к деньгам и вычислительным мощностям и невозможность атаки 51%, т.к. алгоритм просто не ориентируется на большинство.

Каюсь, отвечал на 1-й пост, а выделил для ответа последний.


Получается здесь жестко заданная предопределенность.
Здесь есть два минуса:
1. Можно заранее просчитать кто будет следующий (если известны все адреса майнеров), в итоге никто сеть поддерживать не будет  кроме избранных и то один раз...
Отступление:
А что такое адрес майнера? Если просто адрес кошелька, то все совсем плохо, т.к. они создаются ленко с огромной скоростью - соответственно всегда можно нагенерить миллионы и все соревнование которое сейчас заключается в поиске редкого хеша уйдет в сторону поиска редкого адреса.
2. Следующий минус: создатель криптовалюты может изначально нагенерить их - так как у него будет фора во времени. Он точно будет знать какой адрес будет следующий (Какой победит) и поэтому может приступить к генерации 3-го и т.д.




Почитайте плиз про объективность и субъективность в ссылке выше. Алгоритм консенсуса это как "матрица", туда почти не пробиться информации из реального мира. Почти... PoW - это единственный пока известный способ передать информацию в эту "матрицу".

Странно сами привели мою цитату и написали совершенно другое.

Начнем с пункта 2.
Вы привели цитату, где ясно сказано, что при выборе следующего майнера используются только номер блока и адрес майнера смайневшего текущий блок. Хеш всех транзакций не участвуют, Вы можете ставить любые транзакции и они никак не будут влиять на выбор следующего майнера. А манипулировать номером блока у Вас не выйдет, т.к. все точно будут знать какой номер следующий, адрес майнера им тоже известен. Как Вы собрались манипулировать этими данными.


Теперь пункт 1.
Начнем с этого момента



А Вы собственно кто, для сети. Каждая нода которая синхронизирована, ждет следующий блок данных подписанных конкретным майнером, ваши данные просто рассматривать не будут уже на входе, не говоря уже о проверке.




Здесь вообще все просто, мы просто встраиваем в сам клиент один или несколько начальных блока. А дальше этот клиент исходя из последнего встроенного блока вычисляет адрес майнера, который должен подписать этот следующий блок и начинает его запрос. Пришел блок, вначале проверка подписи и если убедился, что адрес майнера правильный, то начинаются другие проверки. И так новый клиент, исходя из данных блокчейна, что у него есть и алгоритму выбора адреса следующего майнера спокойно вычисляет адрес следующего майнера.




Давайте рассмотрим подробнее. Есть сеть, получен текущий блок и связь у многих оборвалась, получилось как бы 2 отдельных сети. Начиная с этого момента каждая сеть начинает создавать свои блоки. Эти сети начинают с одного общего блока, они вычисляют адрес майнера для следующего блока. Вот какие варианты будут:

- в одной сети этот майнер оказывается доступен и он создает блок со своей подписью. После этого будет вычислен адрес следующего майнера.

- в другой сети этот майнер оказывается не доступен, а потому майнер наказывается и создается штрафной блок. После того как штрафной блок создан, то уже на основе номера этого штрафного блока и майнера, который создал предыдущий блок находиться адрес следующего майнера.

- в одной и другой сети, майнер не создает блок или создает не валидный блок в одной из сети, за что в обоих сетях он наказывается и создается штрафной блок.

Пусть в каждой сети создалось 20 блоков. Потом через некоторое время связь востановилась.

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

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

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

Сеть будет небезопасна, а консенсус недостижим. Я уже вам писал в теме-дубле: https://bitcointalksearch.org/topic/rndpos-2715170
Но вы не дали ответ. Формально ответили, но вопросы не были решены. Повторяюсь вам нужно решить проблемы:
1. Атака из глубины
2. Вечный майнер - манипуляция текущего майнера с хешем блока для вечного своего выбора для валидации следующего блока.

Вот пример ситуации:
1. Представьте что сеть случайно на некоторое время разделилась (оборвался канал связи между Европой и Америкой). В обоеих частях сети образовалось по 20 блоков. После того как каналы связи подсоединились чьи блоки примут участники сети? А третьи лица - новые пользователи, которые только что загрузили клиент: у них две версии блокчейна... Еще хуже ситуация - атака из глубины, я практически с нулевого блока переписываю цепочку и отправляю в сеть, чем моя цепочка хуже?
2.Что мне мешает на пункте 2 такой создавать блок, чтобы хэш был всегда мне выгоден? Просто добавляя ту или иную транзакцию с суммой около нуля, пока хэши от пунктов  2-4 не станут похожи на наш адрес, чтобы опять победить в гонке за майнинг. Такая операция подбора будет выполняться очень быстро - порядка миллиона в секунду и при наличии даже миллиона адресов кошельков можно за 1 секунду подобрать нужный...


Для лучшего понимания смысла протоколов привожу цитату отсюда:
https://bits.media/images/news/290915/PoS%20vs%20PoW%201.0-ru.pdf

Именно, только очередность следующего является случайным выбором.

Более того, я также предлагаю рассмотреть такой вариант:

Для выбора следующего майнера мы не будем использовать хеш всего блока, где есть транзакции. А будем учитывать только следующие величины.

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

2. Адрес майнера смайневшего текущий блок. Данная величина является мало прогнозируемой и становиться окончательно известной, только при получении текущего блока. В случае если блок не получен, то создается штрафной хеш блок без подписи, но майнер для этого блока считается, как адрес майнера создавший предыдущий блок.

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

Таким образом практически исключается возможность подбора хеша под нужные параметры.

Говоря утрированно, Вы предлагаете не устраивать гонки PoW как в Bitcoin, а майнить поочерёдно согласно некому хешу.

Я придумал, как мне кажется интересный алгоритм консенсуса RndPOS, который  способен противостоять даже диктату большинства, т.е. атаке 51%, имеет не слишком большие требования к вычислительным ресурсам.

Но есть одна загвоздка, а именно способна ли децентрализация противостоять подбору адреса следующего майнера. Вот сам алгоритм.


Хочу поделиться с сообществом идеей нового алгоритма консенсуса RndPOS.
  
На текущий момент все криптовалюты используют в основном POW (доказательство работы) или POS (доказательство владения долей).
Огромным недостатком алгоритма POW стала его сильно возрастающая сложность и требующая все больше и больше вычислительных мощностей, а для того чтобы увеличивать эти мощности, требуется вложение средств, чтобы продолжать майнить.

Как ответ на этот недостаток был создан алгоритм POS, где нет сильной вычислительной сложности, но есть требование к наличие средств на счете и чем больше этих средств, тем выше вероятность смайнить новый блок.

Прежде чем перейти к моему алгоритму, нам нужно понять для каких основных целей используется майнинг, а то многие думают, что для ненужных вычислений и печатания денег.

Главная задача майнинга – это создание уникальности в определенном промежутке времени. Тот майнер, кто первым находит текущий хеш и получает право создания блока. Изначально данный принцип был предложен для борьбы с почтовыми спамерами, чтобы они не могли заваливать пользователей миллионами своих сообщений. Перевядя же данный принцип на биткоин получили хороший способ сдерживания, но он оказался не идеальным, так как позволяет создавать форки (это когда два и более майнеров находят хеш в одинаковый промежуток времени и каждый рассылает свою версию блока). Понятно, что в нормально работающей сети эти форки схлопываются рано или поздно, а потому чем-то плохим не считаются, тем не менее это говорит о том, что данный способ не совсем подходит для криптовалюты, т.к. майнеры могут тратить на форки свою мощность и когда она схлопывается, то получается работа произведена зря. Это не очень оптимально.

Поэтому при создании алгоритма консенсуса RndPOS я учел этот момент и он будет полностью исключать форки.
Второй недостаток POW и POS это недостаточная децентрализация. Если рассматривать в динамике роста сети и развития криптовалюты, то мы видим как происходит постепенная централизация. В алгоритме POW за счет повышения сложности и наращивания мощности, а в POS за счет концентрации крупного капитала.

Централизация любой криптовалюты несет в себе риски злоупотребления, цензура транзакций и диктат своей воли всей остальной сети, а также при высокой централизации повышаются структурные риски сети, когда хакеры или правительство оказывают то или иное влияние на основную крупную структурную единицу или на наиболее крупную группу участников сети.
Этот недостаток в своем алгоритме я устранил тем, что создал низкий барьер входа для майнинга. Низкий как в плане вычислительной мощности, а также низкий и по денежным ресурсам.




Мой алгоритм решает следующую задачу – на миллионах компьютеров он создает случайный выбор, но одинаковый для всех результат.

Казалось бы здесь есть противоречие и просто невозможность данного события, тем не менее это так и вот как это реализовано.

Алгоритм будет работать на любых криптографических хешах, мои рекомендации это выбрать SHA3 Keccak. Особенность криптографических хешев в том, что они имеют стойкость к первому и второму перебору, а также стойкость к коллизиям. Эти  особенности выходного значения хеш-функций позволяют сильно изменяться даже при незначительном изменении входа. Значение хеша не дает утечки информации даже об отдельных битах, которые поданы на вход.

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

Как вы знаете главная особенность блокчейн – это связывание текущего блока и предыдущего при помощи хеширования, если где-то в предыдущих блоках произошло даже самое незначительное изменение, то произойдет изменение всех последующих хешев, что в итоге приведет к изменению значения конечного хеша.
Именно эти хеши алгоритм и будет использовать.




Адреса криптовалюты на которых храняться деньги должны быть в форме полноценного хеша и иметь такую же форму, как и у хешей блоков.

Теперь к алгоритму, вот его суть:
 
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 блоков вперед, а остальные нагенеренные блоки будут ликвидированы из за не синхронизации сети. Все транзакции в этих потерянных блоках должны перейти в общий тразакционный пул, чтобы при перестроении блокчейна не было потери информации.

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