shareyourthinking

Зависимость надежности в удостоверении смарт-контрактов

Думал об этом несколько дней, потому что раньше я добавлял сторонние зависимости в смарт-контракты, и вопрос всегда упирается в ту же стену: что произойдет с моим протоколом, если зависимость выйдет из строя.

Newton требует, чтобы приложения валидировали BLS-удостоверение в своем смарт-контракте перед выполнением. Без действительного удостоверения нет исполнения.

Это механизм принуждения, и также это жесткая зависимость.

Как только протокол развертывает это требование в неизменяемом контракте, он берет на себя обязательство, что операторская сеть Newton будет доступна для каждой транзакции, которую тот контракт когда-либо обработает.

Это не критика. Это выбор дизайна с реальными последствиями.

Протокол, интегрирующий Newton, больше не просто полагается на собственный код.

Он полагается на то, что кворум застейканных операторов будет оценивать политики и выпускать удостоверения для каждой транзакции бесконечно.
В whitepaper рассматривается обход цензуры через форс-инклюзию. Но в нем не описано, что происходит при реальном ухудшении работы операторской сети — не цензура, а недовыполнение или частичный простой.
#newt
Я на самом деле думаю, что обязательство по надежности — это вопрос, который больше всего важен для команд протокола, оценивающих Newton, а не набор функций соответствия. Добавление зависимости в смарт-контракт — навсегда, в том смысле, в котором добавление ее в веб-сервис — нет.
#NEWT
Что я еще не выяснил: есть ли режим управляемого деградирования — какой-то способ, чтобы протокол мог перейти к резервному варианту во время простоев операторов, а не останавливать работу полностью.
#ShareYourThinking $LAB $HMSTR
@NewtonProtocol $NEWT #Newt

Пределы выдачи с крана (faucet) определяют, действительно ли Testnet что-то тестирует близкое к реальному использованию или лишь подтверждает, что пайплайн работает на тривиальном масштабе.

#baby A кран, который раздаёт фиксированную небольшую сумму на каждый кошелёк, подходит, чтобы подтвердить, что механика депозита и заимствования функционирует. Но это не подходит для стресс-тестирования того, что происходит с расчётами health factor, триггерами ликвидаций или поведением пула Aave v4 на позициях, сопоставимых с тем, что пользователи мейннета реально будут вносить. Testnet «Trustless Bitcoin Vaults» (TBV) существует именно для проверки дизайна до того, как через него пройдёт реальный капитал — и такая валидация хороша ровно настолько, насколько реально проверяются позиции по их размеру.$BABY

Не утверждаю, что ограниченный кран — это недостаток дизайна. Ограниченные краны не дают их разорять или злоупотреблять, и большинство тестнетов делают кап именно по этой причине.

И не утверждаю, что лимит не важен. Если каждый тестировщик работает с одинаковой небольшой суммой, то определённые сценарии сбоев — каскадные ликвидации, проблемы с глубиной пула, edge-cases для health factor на более крупных позициях — просто не будут задействованы до мейннета.@BabylonLabs_io

То, что я пока не проработал, — отражает ли низкий лимит заявок (claim limit) реальную меру безопасности против злоупотреблений с краном или же он тихо ограничивает то, сколько реального стресс-тестирования фаза Testnet может произвести до того, как под угрозой окажется капитал мейннета.
$AKE
$BANK #ShareYourThinking