Я ожидал, что документация Babylon по стейкингу расскажет мне, как работает протокол. Вместо этого она заставила меня глубже задуматься о том, как бы я сам подходил к стейкингу.
Одна деталь снова и снова возвращалась ко мне:
Каждый стейкинг-вывод связан с одним Finality Provider.
Сначала я воспринимал это как чисто техническую реализацию. Чем больше я размышлял, тем больше понимал, что это также дизайнерское решение с практическими последствиями.
Мне нравится простота того, что каждый стейкинг-вывод остается чистым, нативным и понятным. При этом, если для меня важна диверсификация, мне придется управлять ею, создавая несколько транзакций стейкинга. Это может означать больше UTXO для отслеживания, дополнительные комиссии и больше операционных решений.
Я не рассматриваю это как критику или ограничение само по себе. Я вижу это как продуманный компромисс между простотой протокола и ответственностью пользователя. Разные пользователи могут по-разному ценить этот баланс — в зависимости от их собственного подхода и приоритетов.
Для меня самая ценная техническая документация — это не та часть, которая объясняет архитектуру, а та, которая меняет то, как я думаю о дизайнерских решениях, стоящих за ней.
Мне интересно, как другие интерпретируют этот компромисс.
@BabylonLabs_io $BABY #baby
$UAI $COTI

Вы бы распределили свой BTC между несколькими Finality Providers?