Способы мотивации в архитектуре алгоритма консенсуса Obelisk

Это старое сообщение в одной из тем на bitcointalks от 19 Июня 2014

Цитата от: yxxyun 19 июня, 2014, 02:52:38 AM

Цитата от: skycoin 19 июня, 2014, 02:31:59 AM

Цитата от: FrictionlessCoin 18 июня, 2014, 09:15:07 PM

Цитата от: skycoin 18 июня, 2014, 09:08:56 PM

Выдержка из апдейта:

Мы нашли способ предотвращения “атаки Sybil”, благодаря использованию гибридной системы “Proof of State”.

Для того, чтобы создать узел, Вы должны доказать наличие у вас монет. Для примера, 10 монет. Вы отправляете 10 монет на адрес A. Затем вы отправляете 10 монет с адреса А на адрес Б. Потом вы добавляете подпись, используя публичный ключ адреса А для подписи сообщения в вашем Obelisk блокчейне.

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

Еще одна альтернатива - “proof of burn”(доказательство сожжения). Может потребоваться, когда монеты отправлены с адреса А на адрес Б, который не имеет приватного ключа. “Proof of burn” противоречит требованию, что никто не должен скачивать блокчейн целиком для полного контроля над узлом. Таким образом использование “proof of burn” маловероятно.

Эта система ограничивает количество Obelisk узлов и снижает возможность запуска узлов для держателей монет. Ограничение на количество узлов и требования по наличию монет добавляют еще один слой защиты от “Sybil атак”.

Не уверен, что это может предотвратить “Sybil атаку”. Вы просто ставите цену за добавление узла в сеть и поэтому для “sybil атаки” потребуются финансовые затраты?

На данном этапе - это лишь идея. Найдено улучшение. Каждый Obelisk узел имеет публичный ключ. Мы хешируем этот ключ в адрес и теперь этот адрес хранит 10 монет в качестве своих выходных данных.

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

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

Когда новый Obelisk узел запущен, он будет “доверять” нескольким случайным узлам. Пользователь также может добавить вручную некоторые узлы, которым доверяет (биржи или доверенные члены сообщества). Узел идентифицируется с помощью хеша публичного ключа и может быть найден с помощью DHT. В этом отличие от Bitcoin, где узлы это пары IP:порт. Вы можете перенести свой компьютер и подлинность вашего узла не пострадает, потому что она не зависит от IP адреса.

Мы хотим, чтобы сеть была безопасна даже со случайно выбранными узлами. Мы не хотим допустить ситуацию, которая произошла у Ripple, когда 3 узла разработчиков контролировали всю сеть. Однако, мы хотели предотвратить ситуацию, когда кто-нибудь запустит 200,000 узлов и попробует установить доверительные отношения с новыми пользователями. Такие “Sybil атаки” все еще могут перерасти в “атаку 51%”, но в любом случае увеличение стоимости затрат на атаку - это всегда хорошо.

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

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

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

Obelisk это консенсус для узлов Skycoin’а? Я думал, что это skycoind…

Да.

У skycoin есть блокчейн. Он находится тут https://github.com/skycoin/skycoin/tree/develop/src/coin. Этот код анализирует блоки и производит сделки с неотправленными результатами и транзакциями.

Skywire это “демон” с серверной архитекторой. Skywire может запускать сервисы, которые синхронизируют блокчейн и делают другие полезные вещи. Ячеистая сеть в настоящее время используется как надстройка над Skywire (возможно это надо поменять).

Механизм консенсуса находится за пределами блокчейна. Obelisk узлы (которые вероятно будут реализованы как служба Skywire) содержат блокчейн. У каждого узла есть публичный ключ, который является идентификатором узла. Каждый Obelisk узел содержит свой собственный блокчейн (в этой цепи нет монет). Узел создает новый блок и подписывает его приватным ключом. The Obelisk блокчейны используются для установления консенсуса (определения главного блока в Skycoin блокчейне). Obelisk использует алгоритм “Ben-Or” для случайного консенсуса. Каждый Obelisk узел содержит список узлов, на которые он подписан. Эти узлы влияют на консенсус и “голосуют” за решение на локальном узле. Для непатологических сетевых топологий, локальный консенсус доказуемо сходится к глобальному консенсусу.

Каждый узел голосует за следующий блок в цепочке. Один из узлов номинирует блок, а остальные голосуют за него. Полученные голоса публикаются в блоках Obelisk блокчейна для каждого узла. Ваш узел случайным образом выбирает одну из альтернатив и постоянно меняет свое решение в течении некоторого времени.Когда 40% узлов (на которые вы подписаны) достигли консенсуса, вы переключаетесь на выбранного кандидата. Сеть может голосовать за несколько разветвлений сразу, это не замедлит ожидание консенсуса. Со временем разветвления обрезаются в единую цепь. Разделения в 2 или 3 - это норма, но с каждым последующим подтверждением вероятность возврата блока экспоненциально уменьшается и стремится к нулю. Если транзакция была произведена у всех кандидатов сети, то она считается выполненной, даже если текущий консенсус сети еще не был достигнут.

Так работает двоичный алгоритм “Ben-Or”, а Skycoin будет использовать что-нибудь более продвинутое, которое будет быстрее в ситуации, когда появляется много блоков-претендентов. Рандомизация важна для сохранения суб-графов сети от застревания. Процесс голосования - это форма “отжига” в которой каждый узел самостоятельно достигнет глобального консенсуса, используя только локальную информацию.

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

Если узел появляется в сети и пытается заставить сеть принять другое ответвление(атака 51%, возвращение операций), он просто будет проигнорирован. Большинство “атак 51%” предполагает наличие поврежденных узлов, поведение которых позволяет их автоматически обнаружить и как результат убрать такой узел из доверенного списка. Чем проще стратегия “атаки 51%”, тем проще такие узлы обнаружить и быть уверенным, что это была попытка вернуть транзакцию. Их выдаёт то, что для этого требуются решения потвержденные прошедшим числом. Это требует публикации двух подписанных блоков с одинаковым порядковым номером, поэтому мы просто сделали систему, которая автоматически препятствует этому преступлению.

Мы пытаемся устранить последнюю возможность на “атаку 51%”, которая возможна, когда подсеть перестаёт быть онлайн(атака с разделением сети) и потом переподключается к сети с другим консенсусом блокчейна и пытается заставить сеть вернуть транзакции. Большинство из этих атак будут провальны, потому что подсеть не будет обладать достаточным влиянием.

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

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

В Skycoin, для возврата транзакции:

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

Для доказательства, что это “атака 51%”, вам надо выписать все предположения о её осуществлении, затем описать простую математическую модель и определить условия при которых такая атака возможна в данной модели. Когда вы знаете все условия необходимые для атаки, вы пытаетесь исключить их, и если вы не можете полностью свести их на нет, вы делаете их достижение настолько сложным, насколько это возможно. Вы увеличиваете необходимые затраты на атаку и уменьшаете вероятность успешности специфических атак. Таким образом вы уменьшаете возможную награду за успешную атаку.

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