Мне хотелось понять, что происходит в промежутке между тем, когда фактическое обеспечение провайдера финальности меняется, и тем, когда протокол признаёт, что оно изменилось. Поэтому я проследил, как модуль x/epoching в Babylon на самом деле обрабатывает новую делегацию.

Сообщения о стейкинге и анстейкинге не выполняются немедленно. Они ставятся в очередь на длину целого эпохального периода, а затем обрабатываются единым пакетом на границе. Пока эта граница не наступит, итоговая (finality) голосующая мощность сети отражает старый снимок, а не текущий. Провайдер финальности мог в реальном времени терять делегации, мог экономически «высасываться» в середине эпохи, и при этом голосовать тем весом, который был у него до того, как кто-либо отозвал средства.

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

Я продолжал сравнивать это с тем, как на самом деле работает кредитная линия. Ваш лимит не обновляется мгновенно, как только меняется ваш доход. Он обновляется в рамках цикла, а между тем банк расширяет доверие на основе цифры, которая уже чуть-чуть неверна. Babylon делает то же самое с «весом» биткоина — просто с более хорошей криптографией, завернутой вокруг этой неверности.

Я не думаю, что это ломает модель. Быстрое анбандлингование (unbonding) примерно за два дня делает это окно коротким по сравнению с типичными PoS-цепочками. Но короткое — не равно нулю, и за тем, что действительно стоит наблюдать, — не цена токена. Важно, насколько широко растягивается это эпохальное окно по мере масштабирования набора валидаторов.

$BABY @BabylonLabs_io #baby $ON $BTC