Контракты управления
Эта страница переведена сообществом на русский язык, но нуждается в улучшениях. Если вы хотите принять участие в переводе свяжитесь с @alexgton.
В TON параметры консенсуса работы узла, связанные с TVM, catchain, комиссиями и топологией цепи (а также то, как эти параметры хранятся и обновляются), контролируются набором специальных смарт-контрактов – в отличие от устаревших и негибких способов хардкода этих параметров, принятых в блокчейнах предыдущих поколений. Таким образом, TON реализует всеобъемлющее и прозрачное on-chain управление. Сам набор специальных смарт-контрактов регулируется параметрами, и в настоящее время включает в себя контракты Избирателя, Конфигурации, и DNS, а в будущем будет расширен за счет extra-currency Minter и др.
Избиратель
Смарт-контракт Elector (Избиратель) управляет тем, как раунды валидации сменяют друг друга, кто получает обязанность валидировать блокчейн и как будет распределяться вознаграждение за валидацию. Если вы хотите стать валидатором и взаимодействовать с избирателем, ознакомьтесь с инструкциями валидатора.
Избиратель хранит данные о невыведенных Toncoin в хешмапе credits
, новые заявки – в хешмапе elect
, а информацию о предыдущих выборах – в хешмапе past*elections, последняя хранится внутри complaints (жалоб на неправильную работу валидатора) и frozen-stakes* (замороженных ставок валидатора за уже завершенные раунды, которые удерживаются stake_held_for
(ConfigParam 15)). Контракт Избирателя выполняет следующие задачи:
- Обработка заявок для проведения выборов валидаторов
- Проведение выборов
- Обработка отчетов о неправильной работе валидатора
- Распределение вознаграждений за валидацию
Обработка заявок
Чтобы создать заявку, будущий валидатор должен сформировать специальное сообщение, содержащее соответствующие параметры (адрес ADNL, публичный ключ, max_factor
и т.д.), прикрепить его к некоторой сумме TON (называемой ставкой) и отправить Избирателю. Избиратель, в свою очередь, проверяет эти параметры и либо регистрирует заявку, либо сразу же возвращает ставку обратно отправителю. Обратите внимание, что заявки принимаются только с адресов на мастерчейне.
Проведение выборов
Избиратель – это специальный смарт-контракт, который имеет возможность принудительно вызываться в начале и в конце каждого блока (так называемые Tick и Tock транзакции). Избиратель, действительно, вызывается на каждом блоке и проверяет, не пора ли провести новые выборы.
Общая концепция процесса выборов состоит в том, чтобы рассмотреть все заявки, в частности, их сумму TON и max_factor
(максимальное соотношение работы по проверке, которую этот заявитель согласен выполнить, по сравнению с самым слабым валидатором), и установить веса для каждого валидатора пропорционально сумме TON, но таким образом, чтобы все условия max_factor
были выполнены.
Технически это реализовано следующим образом:
- Избиратель принимает все заявки с суммой ставки, превышающей текущий сетевой минимум
min_stake
(ConfigParam 17). - Происходит сортировка заявок по ставке в порядке убывания.
- Если участников больше, чем максимальное количество валидаторов (
max_validators
ConfigParam 16), список сокращается с конца. - Выполняется цикл
i
от1
доN
(среди оставшихся участников):
- Берется первый
i
-элемент из списка (отсортированного в порядке убывания), - Исходя из того, что i-ый кандидат будет принят последним (и, следовательно, имеет наименьший вес), рассчитывается эффективная ставка (
true_stake
) относительноmax_factor
. Другими словами, эффективная ставка j-го заявителя (j<i
) рассчитывается какmin(stake[i]*max_factor[j], stake[j])
, - Вычисляется общая эффективная ставка (TES – total effective stake) участников с 1-го по i-й. Если данная TES выше, чем предыдущая известная максимальная TES, то она считается наилучшей текущей весовой конфигурацией.
- Получение текущей наилучшей конфигурации, т.е. весовой конфигурации, которая использует максимальную ставку, и ее отправка в контракт конфигурации (Config contract), чтобы она стала новым набором валидаторов.
- Внесение всех неиспользованных ставок, например, ставок от заявителей, которые не стали валидаторами, и излишков, если таковые имеются
stake[j]-min(stake[i]*max_factor[j], stake[j])
в таблицуcredits
, откуда они могут быть запрошены заявителями.
Таким образом, если у нас есть девять кандидатов со 100 000 TON и коэффициентом 2,7 и один участник с 10 000 TON, то последний участник не будет избран: без него эффективная ставка составит 900 000 TON, а с ним – только 9 * 27 000 + 10 000 = 253 000 TON. Напротив, если у нас есть один кандидат со 100 000 TON и коэффициентом 2,7 и девять участников с 10 000 TON, все они станут валидаторами. Однако первый кандидат может поставить только 10 000 *2,7 = 27 000 TON, а излишек в 73 000 TON пойдет в credits
.
Обратите внимание, что существуют некоторые ограничения (очевидно, контролируемые параметрами конфигурации TON) на результирующий набор валидации, в частности, min_validators
, max_validators
(ConfigParam 16), min_stake
, max_stake
, min_total_stake
, max_stake_factor
(ConfigParam 17). Если выполнить эти условия с помощью текущих заявок нет возможности, проведение выборов будет отложено.