Содержание статьи:
- Proof of Believability: SERVI
- Как работает алгоритм Proof of Belivability?
Мы уже писали о том, что такое Proof of Stake, Proof of Work, Proof Of Capacity и о многих других механизмах консенсуса. К ним относятся малоизвестный консенсус Proof of Believability, который является алгоритмом консенсуса, используемым IOST.
Хотя этот алгоритм не очень известен, он представляет собой очень интересный консенсусный алгоритм, учитывая технологические проблемы, которые он стремится решить.
Итак, вот как это работает и какие характеристики Proof of Believability.
Proof of Believability: SERVI
Одной из основных проблем, стоящих перед традиционным механизмом консенсуса «Proof of Stake», является тенденция к централизации. Чтобы снизить этот риск, IOST ввел концепцию SERVI для измерения вклада пользователей в поддержку сообщества, а также для стимулирования дальнейшего развития IOSChain.
SERVI имеет следующие характеристики:
- Не подлежит обмену: SERVI не рассматривается как средство обмена, поэтому им нельзя торговать каким-либо образом
- Самоуничтожающийся: после проверки блока система автоматически удалит баланс SERVI, принадлежащий валидатору. Таким образом, узлы с высокими показателями достоверности могут проверять блоки альтернативным способом, чтобы обеспечить справедливый процесс генерации блоков и избежать появления валидаторов над другими;
- Выпуск: SERVI автоматически генерируется и размещается на учетных записях пользователей в зависимости от вклада сообщества. Эти вклады заключаются в предоставлении услуг сообществу или в контроле и оценке услуг, предоставляемых другими организациями.
SERVI вносит свой вклад в оценку доверия, которая будет проиллюстрирована в ближайшее время. Они также позволяют поддерживать определенный уровень энтропии при выборе валидаторов, отвечающих за обработку транзакции.
Как работает алгоритм Proof of Belivability?
Классические системы на основе цепочки блоков имеют определенный компромисс между безопасностью и пропускной способностью. Это зависит от требований и размера шард, а также от блоков.
Система с большим количеством шард обеспечивает лучшую производительность, но гораздо более уязвима для атак. Чтобы преодолеть этот компромисс, поддерживать определенный уровень безопасности и производительности, IOST разработал новый согласованный алгоритм.
Proof of Believability (PoB) - используется на IOSChain - гарантирует, что узлы имеют незначительную вероятность ошибки, тем самым значительно увеличивая объем сделок, которые могут быть выполнены благодаря изменению в размерах шард.
В протоколе, основанном на PoB, используется внутри-осколочный подход, основанный на правдоподобности. Это означает, что протокол делит все валидаторы на две группы: с одной стороны, надежные валидаторы, а с другой-нормальные.
В результате надежные валидаторы очень быстро обрабатывают транзакции на первом этапе. Затем обычные валидаторы отбирают и проверяют транзакции на втором этапе, чтобы завершить операцию и гарантировать легитимность транзакций.
Вероятность того, что узел выбран как заслуживающий доверия другими заслуживающими доверия валидаторами, определяется оценкой достоверности узла. Это рассчитывается с использованием нескольких параметров, включая баланс токенов, вклады сообщества и т. д. Чем выше оценка, тем больше вероятность, что узел будет выбран.
Это означает, что существуют надежные валидаторы, которые управляют необходимыми процедурами для принятия решения о наборе транзакций, подлежащих обработке, и порядке их обработки.
Эти валидаторы могут агрегироваться, формируя свои собственные группы проверки. Однако эти группы также могут быть очень маленькими, так что они состоят только из одного валидатора для каждой группы.
Это приведет к случайному распределению транзакций, подлежащих обработке, между различными заслуживающими доверия валидаторами. Следовательно, производятся меньшие блоки с чрезвычайно низкой задержкой.
Однако могут быть некоторые проблемы безопасности, поскольку проверка выполняется только одним узлом. Следовательно, некоторые вредоносные транзакции могут выполняться надежными вредоносными валидаторами.
Чтобы решить эту проблему, выбран определенный интервал выборки, который будет определять, как часто обычные валидаторы должны будут проверять транзакции на втором этапе, таким образом обнаруживая любые несоответствия. Если валидатор обнаружен как вредоносный, он потеряет все свои токены и репутацию в рамках системы.
