Подтверждение блокировки

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

Текущий дизайн

Чтобы начать голосование, валидатор сначала регистрирует учетную запись, на которую он будет отправлять свои голоса. Затем он отправляет голоса на этот счет. Голосование содержит высоту тика блока, по которому оно голосует. Учетная запись хранит 32 самые высокие высоты.

Проблемы

Предлагаемый дизайн

Изначально нет кросс-блочного состояния

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

Время подтверждения регистрации

Банку необходимо знать о программе голосования. После каждой транзакции он должен проверять, является ли это транзакцией голосования, и если да, то проверять состояние этой учетной записи. Если транзакция привела к достижению квалифицированного большинства, она должна регистрировать время, прошедшее с момента отправки транзакции NewBlock.

Завершение и выплаты

Tower BFT — это предлагаемый алгоритм выбора форка. Предлагается отложить выплаты майнерам до тех пор, пока стек голосов валидатора не достигнет определенной глубины, после чего откат становится экономически нецелесообразным. Таким образом, программа голосования может реализовать Tower BFT. Инструкции по голосованию должны ссылаться на глобальную учетную запись Tower, чтобы она могла отслеживать состояние перекрестной блокировки.

Проблемы

Ончейн-голосование

Использование программ и учетных записей для реализации этого немного утомительно. Самое сложное — выяснить, сколько места выделить в NewBlock. Двумя переменными являются активный набор и доли этих валидаторов. Если мы посчитаем активный набор на момент отправки NewBlock, количество валидаторов, для которых нужно выделить место, известно заранее. Однако если мы позволим новым валидаторам голосовать за старые блоки, нам понадобится способ динамического распределения пространства.

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

Влияние голосования на предыдущие блоки

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