shareyourthinking

Зобов’язання щодо надійності залежності підтвердження смартконтрактів

Думав про це кілька днів, бо вже додавав сторонні залежності до смартконтрактів раніше, і питання завжди впирається в ту саму стіну: що станеться з моїм протоколом, якщо залежність вийде з ладу.

Newton вимагає, щоб застосунки валідовували BLS-підтвердження в їхньому смартконтракті перед виконанням. Немає дійсного підтвердження — немає виконання.

Це механізм примусу й водночас жорстка залежність.

Коли протокол розгортає цю вимогу в незмінному (immutable) контракті, він фактично зобов’язується, що операторська мережа Newton буде доступна для кожної транзакції, яку цей контракт коли-небудь оброблятиме.

Це не критика. Це вибір дизайну з реальними наслідками.

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

Він покладається на те, що кворум стейкнутих операторів оцінюватиме політики й створюватиме підтвердження для кожної транзакції безстроково. У whitepaper розглянуто цензуру через примусове включення. Але він не розкриває, що станеться під час справжнього погіршення роботи операторської мережі — не цензуру, а просто недовиконання чи частковий простій.
#newt
Я насправді вважаю, що зобов’язання щодо надійності — це питання, яке найбільше має значення для команд протоколів, які оцінюють Newton, більше ніж набір функцій відповідності. Додавання залежності до смартконтракта є постійним у тому сенсі, якого немає у випадку, коли додаєш її до вебсервісу.
#NEWT
Що я ще не з’ясував, так це чи існує режим плавної деградації — якийсь спосіб, за якого протокол міг би відступити/перемкнутися під час простою операторів, замість того щоб повністю зупинятись.
#ShareYourThinking $LAB $HMSTR
@NewtonProtocol $NEWT #Newt

Ліміти крану (Faucet) визначають, чи Testnet справді тестує щось, близьке до реального використання, чи просто підтверджує, що пайплайн працює в тривіальному масштабі.

#baby A faucet, який видає фіксовану малу суму на гаманець, підходить для підтвердження того, що механіка депозиту для запозичень працює. Але це не підходить для стрес-тестування того, що відбувається з розрахунками Health factor, тригерами ліквідацій або поведінкою пулів Aave v4 у розмірах позицій, близьких до тих, які реально публікували б користувачі mainnet. Trustless Bitcoin Vaults (TBV) testnet існує саме для перевірки дизайну перед тим, як через нього пройде реальний капітал — така перевірка настільки якісна, наскільки реально тестуються розміри позицій.$BABY

Не кажу, що лімітований faucet є дизайновим недоліком. Неконтрольовані faucets виснажують або зловживають ними, і більшість testnet’ів обмежують ліміти саме з цієї причини.

Не кажу також, що ліміт не має значення. Якщо кожен тестувальник працює з однаковою малою часткою, то певні режими відмов — каскадні ліквідації, проблеми з глибиною P00l, граничні випадки health factor у більших позиціях — просто не будуть опрацьовані до mainnet.@BabylonLabs_io

Чого я не з’ясував, так це того, чи низький ліміт заявок відображає справжній захисний захід безпеки проти зловживань faucet’ом, чи це тихо обмежує, скільки реального стрес-тестування фаза Testnet може реально дати, перш ніж опиниться під загрозою капітал на mainnet.
$AKE
$BANK #ShareYourThinking