Данный пост посвящен разбору презентации «The Mauve Revolution» Виталика Бутерина. В своей работе/выступлениях я неоднократно обращался к задаче византийских генералов и называл данную задачу первым техническим заданием технологии Blockchain. Вчера, 19 сентября, в Шанхае в рамках второй конференции разработчиков платформы Ethereum Влад и Виталик рассуждали о переходе на Proof-of-Stake, каспере и внедрении решения задачи византийских генералов в работу сети Ethereum.
Mauve paper or Ethereum 2.0
Bloсkchain технология эволюционирует в сторону поддержки арбитражных приложений с полным отслеживанием состояния транзакций. В сиреневой бумаге Виталик Бутерин рассуждает о наиболее вероятных путях развития платформы Ethereum версии 2.0 в данном направлении, о том какие требования потенциально это накладывает на Ethereum платформу и как их предлагается решать.
Основные проблемы превращения Ethereum в глобального арбитра — это (а) Производительность. Текущий подход требует от каждого участника хранения и проверки всех транзакций, которые проходят в сети, тем самым сеть не может быть производительнее, чем один отдельно взятый участник сети. (б) Проблемы высоких затрат энергии на поддержку сетей, использующих Proof-of-Work (PoW).
Виталик видит решение данных проблем в отказе от PoW в сторону гибрида Proof-of-Stake (PoS) и сегментирования процесса проведения транзакций валидаторами для повышения возможности масштабирования сети.
Подробнее тут: vitalik.ca/files/mauve_paper.html
Casper Proof-of-Concept 3 (PoC3)
Генерация блоков производится группой валидаторов, предоставляющих залог самой сети для участия в проведении транзакций. Любой участник сети может стать валидатором, отправив виртуальному майнеру — касперу (Casper) — транзакцию с некоторым количеством эфиров. В сети должны будут появиться периоды (в слайдах Бутерина был приведен период в 12 часов), и сказано, что после отправки транзакции для участия в процессе валидации транзакций, валидатор будет ждать 2 периода.
Далее Виталик рассуждал о проблеме выбора валидатора, который создаст следующий блок. Были рассмотрены: старый алгоритмы проекта NXT, старый алгоритм PoS и деление вознаграждения между участниками. В итоге был рассмотрен свой подход, который позволяет наказать компроментирующего сеть валидатора. Ему было дано забавное название Dunkle = Darn Uncle. Если блок валидатора не будет принят сетью (сегодня это называется Uncle и никак не наказывается сетью), то Casper заберет с залога валидатора сумму эквивалентную вознаграждению за данный блок.
В конечном итоге внедрение Casper может привести к значительному увеличению производительности сети до нескольких тысяч транзакций в секунду. Добавляя в эту схему снижение затрат на поддержание сети в PoS относительно PoW, мы можем говорить и о снижении стоимости транзакций в сети.
Выбор цепочки блоков при появлении ветвления в Casper PoC3
В классическом PoW выигрывает та цепочка блоков, которая имеет наибольшую мощность. В Casper PoC3 выигрывает та цепочка блоков, которая содержит наибольшую сумму залога, которую потеряют валидаторы при выборе другой ветки.
Легкие клиенты в Ethereum 2.0
Отказ от PoW в сторону PoS позволяет доверять блоку без необходимости хранения всей цепочки, так как блок будет гарантировать консенсус валидаторов, а не результат выполнения работы майнерами. Это существенно снизит требования к участникам сети и тем самым позволит запускать клиент на портативных и малопроизводительных устройствах. При этом следует понимать, что если вы считаете недостаточным для работы своего приложения, использующего сеть Ethereum, данных о текущем блоке, то нет никаких сложностей получить полную цепочку блоков и использовать полный клиент сети.
Консенсус в Ethereum 2.0
Виталик указал, что консенсус будет достигаться с помощью BFT (Byzantine fault tolerance), но если честно, я увидел на слайдах одновременно решение и Лесли Лампорта, и Byzantine Quorum Systems. Также в своем докладе в этот же день Влад Замфиров указывал на проблемы использования BFT для достижения консенсуса в децентрализованных сетях из-за существования сети в асинхронном состоянии.
Подробнее можно почитать пост Влада Замфира: https://blog.ethereum.org/2015/08/01/introducing-casper-friendly-ghost/
А также обратиться к первоисточникам исследований: https://github.com/ethereum/research/blob/master/casper3/casper.py