<div class="pull-right">https://steemitimages.com/0x0/https://steemitimages.com/DQmbA4wvwzeu4s6YELBpkJQGvhMRJZFqb6x8U58fBMwKfvZ/image.png</div>

Недавно я просматривал [последнюю версию исследовательской работы по Casper](https://github.com/ethereum/research/tree/master/casper4/papers) в свете продолжающейся дискуссии с Виталиком Бутериным о механизмах консенсуса. Я хочу быть максимально объективным и практичным и в то же время стремлюсь учесть все факторы общей картины.

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

## Две части проблемы

Протокол Casper состоит из двух частей — **механизма предложения** и **механизма консенсуса**. Механизм предложения производит последовательность связанных между собой блоков, а механизм консенсуса создает контрольную точку (чекпойнт) через каждые 100 блоков.

Согласно гибридной модели доказательства выполненной работы, Ethereum использует POW блоки как **механизм предложения**, а алгоритм Casper – для достижения консенсуса в контрольных точках.

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

Поскольку система предложения абстрактна, ее легко заменить на алгоритм DPOS. Другими словами, там, где Ethereum использует POW, мы можем использовать DPOS. Обратите внимание на то, что использование POW с Casper [требует замены Правила Выбора Форка](https://medium.com/@VitalikButerin/minimal-slashing-conditions-20f0b500fc6c) с преимуществом “самой длинной цепи” на новое правило, которое в первую очередь учитывает Casper, а правило самой длинной цепи использует только для разрешения ничьих.

## Сообщения протокола Casper

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

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

Протокол Casper строится на наборе валидаторов, каждый из которых посылает два сообщения в течение одной эпохи – о ПОДГОТОВКЕ и ЗАВЕРШЕНИИ — предпочитаемым последним блокам в цепи этой эпохи. Предлагаемая эпоха включает 100 блоков; в Ethereum эпоха длится 1500 секунд, в протоколе DPOS — 300 секунд.

С ростом количества участвующих в процессе валидаторов потребность в пропускной способности канала передачи данных растет в порядке N, и делает она это за счет потенциальной пропускной способности для других транзакций. Именно поэтому эпоха – это 100 блоков, а не 1 блок.

## Casper как приложение для EOS

Ознакомившись с описанным выше базовым уровнем представлений о Casper, сообщество EOS может прийти к решению об использовании Casper в виде контракта с целью повышения субъективного уровня безопасности своего блокчейна. Вознаграждение за участие в адаптации может быть получено от одного из 3 полезных для сообщества приложений, которое могут выбрать сами владельцы долей. Протокол Делегированного Доказательства владения Долей в данный момент использует правило самой длинной цепи.

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

## Важность механизма предложений

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

Механизм предложений контролирует следующие аспекты протокола:

1. Когда должен быть произведен блок
2. Кто его должен произвести
3. Какие транзакции необходимо в него включить
4. Потенциальный получатель комиссионного вознаграждения
5. Когда активируется хардфорк
6. Какие софтфорки необходимо провести
7. Скорость подтверждения транзакций в краткосрочной перспективе
8. Вероятность форков в краткосрочной перспективе

Это означает, что централизацию производства и цензуры определяет именно процесс предложения. Отключение процесса предложения отключает и саму сеть, так как процесс консенсуса Casper зависит от исправного функционирования источника производимых блоков. Всё, что дает Casper, сводится к экономической оценке необратимости, производимой каждые 30 минут (POW гибрид Ethereum) или 5 минут (гибрид DPOS). 

Это позволяет нам заключить, что большая часть проблем консенсуса возникает в области механизма предложения. Кроме того, мы видим, что использование Casper не приводит к повышению эффективности. И наконец, к тому моменту, когда блок Ethereum уже погребен под  30 минутами POW, вероятность отката уже настолько мала, что относительная стоимость “страховки Casper” скорее всего значительно превышает фактические риски. 

## Предлагаемый мной механизм предложения

Если мы позволим любому предлагать что угодно и когда угодно, валидаторы Casper придут в тупик из-за того, что не смогут понять, для каких блоков им нужно отправлять сообщения ПОДГОТОВКИ. Поэтому в интересах валидаторов кооперироваться для достижения консенсуса.

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

Следовательно, мы можем смоделировать Casper в виде протокола, согласно которому N валидаторов, отправляющих сообщения о ПОДГОТОВКЕ, делают это в назначаемые строго индивидуально  промежутки времени, скажем, раз в 3 секунды. Это означает, что с эпохой, равной 100 блокам, и 3-х секундным интервалом на блок вы можете иметь более 100 валидаторов. Вы сможете поддерживать больше валидаторов, если снизите интервал и в определенный момент разрешите параллельную рассылку сообщений о ПОДГОТОВКЕ. Это подобно лавине, вызванной единственной снежинкой ПОДГОТОВКИ.

До тех пор, пока будет возможно любое количество валидаторов, протоколу лучше ограничивать их абсолютное число. В моем понимании, минимальный необходимый залог должен расти по мере увеличения количества валидаторов. Для сохранения возможности масштабирования Casper предполагает, что валидаторы будут объединять залоги и потенциально применять к сообщениям ПОДГОТОВКИ и ЗАВЕРШЕНИЯ мультиподпись. 

## DPOS как потоковый Casper

Для оптимизации пропускной способности и производительности Casper на данный момент выполняет один круг (так называемую эпоху) каждые 100 блоков. Это можно оптимизировать путем реализации потоков эпох таким образом, чтобы было возможно обрабатывать 100 эпох параллельно, завершая одну эпоху в каждом блоке. Если предположить, что валидаторы получают место в очереди сначала для ПРОИЗВОДСТВА и ПОДГОТОВКИ, то мы можем рассматривать каждый блок DPOS как сообщение ПОДГОТОВКИ для всех предыдущих блоков 99 предшествующих эпох и как сообщение ПОДГОТОВКИ для следующей эпохи. В рамках этого же потока мы можем рассматривать ПОДГОТОВКУ как ЗАВЕРШЕНИЕ для предыдущей ПОДГОТОВКИ.

Если снабдить Casper возможностью поточной обработки и сделать каждый Предлагаемый блок ПОДГОТОВКОЙ для текущего раунда (эпоха 0) и ЗАВЕРШЕНИЕМ для предыдущего (эпоха -100), то станет возможным применение схожих ограничительных условий при заметном увеличении производительности.

## Две фазы DPOS

Алгоритм DPOS состоит из двух независимых частей:

1. Выбор производителей
2. Достижение консенсуса

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

## Выбор Валидатора и Предлагающего

Согласно модели гибридного POW, предлагающие выбираются путем доказательства работы, а валидаторы выбираются согласно размеру доли. Гибридная модель никак не препятствует созданию пустых блоков или цензуре со стороны майнинговых пулов. Это гибридное состояние со временем будет заменено на какие-то другие системы предложения, поэтому давайте рассмотрим возможные варианты.

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

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

Мы можем предположить, что производители (предлагающие производство) блоков вознаграждаются посредством комиссий за транзакцию и/или награды за производство блока. Это вознаграждение может быть либо коллективным, либо индивидуальным. Для поддержания достаточной мотивации валидаторов предпочтительнее все же будет модель коллективного поощрения, т.к. она будет усиливать тенденцию к кооперации, а не к конкуренции; тем не менее, в гибридной модели POW, принятой в Ethereum, для майнеров (т.н. производителей, предлагающих) всё же будет применяться индивидуальный подход.

## Склонность к централизации

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

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

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

## Управление

На данном этапе уже должно быть понятно, что Casper является протоколом прикладного уровня, который может быть реализован поверх любого существующего алгоритма консенсуса для создания контрольных точек. Чего не может решить Casper, так это проблемы управления. Управление, реализованное на POW, будет сводиться к сигналам в заголовках блоков, реализованное на POS - к прямой демократии на основе размера долей среди валидаторов. Управление на DPOS строится на многоуровневом делегировании полномочий равным по силе производителям.

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

Ясно одно: до тех пор, пока технически неподготовленные индивиды не могут легко принимать участие в управлении, не будут соблюдены интересы всех участников. А значит, индивидам придется вкладывать (рискуя) свои доли в пул валидаторов. Риск, связанный с участием в одном пуле, значителен, особенно если он ничем не компенсируется. Оператор пула возьмет на себя значительную ответственность, при этом не имея никакого стимула разделять 100% вознаграждения с участниками. Это в свою очередь приведет к получению оператором большого процента от общего вознаграждения.

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

# Выводы

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

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

Несмотря на это, я считаю, что стоит поэкспериментировать с реализацией протокола Casper в качестве смарт-контракта EOS. Используя нашу концепцию Общественно Полезного Контракта (Community Benefit Contracts - CBC), мы можем предложить владеющим долей EOS акционерам проголосовать за то, какой объем из инфляции можно выделить на реализацию контракта Casper, и за то, выделять ли вообще.



---

**Свежие новости в Телеграм: [t.me/EOS_RU](https://t.me/EOS_RU)**

---

***<div class="pull-right">Переведено @rusteemitblog</div>***

**Оригинал поста: [ЗДЕСЬ](https://steemit.com/eos/@dan/casper-as-an-eos-contract)**


---

#### Если вам нравится то, что мы делаем - поддержите witness [blockchained](https://steemit.com/~witnesses) на Steem!

---

<center>https://s20.postimg.org/70i7lsqkd/futer.png</center>