img_20160920_162338

Ethereum devcon two: Mauve paper, Casper, PoS и BFT.

Данный пост посвящен разбору презентации «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 в сторону валидаторов позволяет доверять блоку без необходимости хранения всей цепочки, так как блок будут гарантировать валидаторы,  а не результат выполнения работы майнерами. Это существенно снизит требования к участникам сети и тем самым позволит запускать клиент на портативных и малопроизводительных устройствах. При этом следует понимать, что если вы считаете недостаточным для работы своего приложения, использующего сеть Ethereum данных о текущем блоке, то нет никаких сложностей получить полную цепочку блоков и использовать полный клиент сети.

Консенсус в Ethereum 2.0

img_20160919_174726

Виталик указал, что консенсус будет достигаться с помощью 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