Будет ли сеть Ethereum более надежной с несколькими реализациями?

%d0%b7%d0%b0%d0%b3%d1%80%d1%83%d0%b6%d0%b5%d0%bd%d0%be_26-9-2016_%d0%b2_18_22_40

Когда я думаю о надежности Bitcoin, то рассматриваю два основных момента:

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

Неудача в достижении второй цели обычно¹ создает лишь временное неудобство. А неудача с первой может привести к большим потерям из-за возможности «двойного расходования».

Поэтому я не удивлен, что биржа криптовалют Kraken отреагировала на недавнюю проблему с консенсусом в сети Ethereum и приостановила ввод и вывод эфира:

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

Но этот твит вызвал споры:

Я расскажу более подробно, почему несколько реализаций необязательно делают систему более надежной. Мы также рассмотрим важный вопрос: «Как определяется протокол Ethereum?».

Что вообще такое надежность?

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

Конечно, нет! «Надежность» заключается не в том, чтобы в здании постоянно было доступно электричество. Есть как минимум четыре пункта, которые я бы учел в проекте системы, чтобы она считалась надежной:

  1. Надежная система не убивает людей.
  2. Надежная система не поджигает здания.
  3. Надежная система не выходит из строя надолго из-за неисправностей.
  4. Надежная система обеспечивает бесперебойную подачу электроэнергии.

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

Оптимизация для надежности

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

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

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

Оптимизация для доступности

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

vertturbdslfirepump

CC-BY-2.5 Todd A Stephens

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

Резервирование: высокая степень надежности и доступности

Что если я хочу и то и другое? Я мог бы установить два пожарных насоса, защищенных предохранителями. Получилась бы система, где неисправности можно устранять до порчи оборудования и (возможно!) при выходе из строя одного насоса во время пожара, меня защищал бы другой.

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

Системы согласования и резервирование

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

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

Системы согласования доводят эту проблему до крайностей. Сложно использовать резервирование, чтобы сделать эту систему более надежной. Если у нас есть две разные реализации одной системы и одна из них считает, что Элис заплатила Бобу, а другая полагает, что Элис заплатила Чарли, у нас возникает большая проблема, которую необходимо исправить. Пока эта проблема не решена, систему небезопасно использовать: ни Чарли, ни Боб не могут быть уверены, что они получат оплату. И если Боб и Чарли потеряют крупные суммы в такой противоречивой ситуации… будет забавно посмотреть на попытки прийти к единому мнению по поводу того, кто же должен смириться с потерей.

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

Голосование

Почему же не сделать три реализации и не использовать модель голосования «два из трех»?

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

Но использовать голосование в децентрализованных системах не получится и по другой едва уловимой причине: доля желания иметь независимые реализации основывается на ощущении, что так они будут «децентрализовывать разработку». В таком случае резервирование по-прежнему ничего не дает: решение с моделью «два из трех» — тоже реализация, которая определяет, какие три реализации будут служить реализацией!

Как определяется «протокол Ethereum»?

Если мы собираемся использовать резервирование, нам нужна спецификация. Для чего-то простого, например, насоса, не требуется подробная спецификация для работы:

d0b7d0b0d0b3d180d183d0b6d0b5d0bdd0be_26-9-2016_d0b2_18_22_40

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

Для сравнения взглянем на отрывок из документации (Yellow Paper) Ethereum Homestead:

eth-paper-extract

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

Это может считаться подходящей спецификацией для протокола? Очевидно, нет! О многом говорит тот факт, что спасательный хард-форк после случая с DAO не указывается в Yellow Paper, на странице Ethereum в Википедии нет правил проведения спасательных мер, и не было предложения по улучшению Ethereum, составленного для решения вопроса с DAO. Я посмотрел кодовые базы Geth и Parity: в обеих реализован хард-форк, но ни в одной² не указана удобочитаемая спецификация, которая описывает, что именно представлял из себя хард-форк.

«Я не верю, что вторая совместимая реализация Bitcoin когда-либо будет хорошей идеей. Многое в дизайне сети основано на том, что все ноды синхронно получают идентичные результаты. Поэтому вторая реализация была бы угрозой для сети», —Сатоши Накамото.

Насколько я могу судить, как и в случае с Bitcoin, на практике, пока протокол Ethereum документируют в удобочитаемом тексте, его определяет выполняемый код. По крайней мере так часто утверждают:

Я попросил Эмина и Виталика указать мне на эту спецификацию. Пока я не получил ответа, но было бы очень интересно его услышать.

Upd: Ответ автор статьи в итоге получил. Виталик сослался на этот документ. На резонное замечание о том, что в документе отсутствует спецификация кода, по спасению ДАО, Виталик ответил довольно невнятно, что в приведенном им же документе есть спецификация лишь текущего протокола, а хард-форк ДАО в настоящее время является историческим событием, и очень хорошо везде освещен. На что Питер Тодд ответил: «Давайте будем называть вещи своими именами: спецификация не полная».

Примечания

  1. В протоколах с тайм-аутами, например, Lightning, ситуация изменилась, так как используемые тайм-ауты составляют (должны составлять!) около недели или двух; решение о каждом форке Bitcoin до настоящего времени принималось не более, чем за несколько часов.
  2. Запрос на включение для реализации спасательных мер в Parity ссылается на эту спецификацию, но для Geth этот документ не упоминается. Тем не менее ссылаться на случайный документ на GitHub в запросе на включение — довольно сомнительный ход; есть много источников разной степени надежности, которых может быть недостаточно, и из-за них спецификация будет непонятной.

Источник: petertodd.org



Рубрики:Мнение, Теория, Ethereum, эфир

Метки: , ,

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s