Звіт про технічний стан: 1 місяць tBTC rc.1
15 вересня 2020 року контракти tBTC rc.1 були розгорнуті в основній мережі Ethereum. 48 годин після початкового розгортання була призначена для їх тестування і налаштування команда розробників з установленою межею поставки в 2 TBTC. Після закінчення цього терміну 17 вересня обмеження на поставку піднялося до свого першого рівня використання в 100 TBTC, і ми оголосили про доступність tBTC в обмеженому режимі в Keep Discord.
22 вересня обмеження пропозиції автоматично збільшився до 250 TBTC, і ми широко оголосили про tBTC rc.1 через сайт tBTC і інші канали. Цей звіт про стан охоплює час з моменту розгортання контракту 15 вересня по 13 жовтня ~ 17:00 за всесвітнім координованим часом, хоча велика частина активності до 22-го числа все ще була досить обмеженою (всього 7,02 TBTC було випущено до 22-го ), і система ще не була широко анонсована.
Розуміння системи
Наше співтовариство — одне з найважливіших складових майбутнього Keep і tBTC: децентралізована система з централізованою командою розробників, в кінці кінців, не особо децентралізована. Як ми любимо говорити, система децентралізована рівно настільки, наскільки децентралізований її найбільш централізований компонент. Спільнота Keep виконало неймовірну роботу для створення безліч корисних інструментів для спостереження за екосистемами Keep і tBTC в рамках програми Playing for Keeps, яка нагороджує токенами KEEP за відмінну роботу, що просуває проект і саму спільноту.
Деякі з цих інструментів були використані для складання цього звіту. З цією метою, якщо ви хочете відслідковувати поточний і історичний стан системи tBTC, ви можете знайти інформацію на цих сайтах:
Обсяг і активність
По-перше, швидкий погляд на обсяг і активність в системі протягом перших тижнів після релізу:
З моменту розгортання було випущено 3,287.91 TBTC.
Було погашено 2,774.91 TBTC, що означає, що відповідний BTC був переведений з адрес, контрольованих підписантами tBTC, і назад на інші адреси в ланцюжку Bitcoin.
За цей час було зроблено 841 депозит.
Депозити tBTC підтримуються групами підписантів, які надають заставу в ETH, щоб гарантувати їх доступність. Це означає, що працездатність системи залежить не тільки від кількості відкритих вкладів, але і від того, скільки облігацій є для забезпечення нових вкладів. В даний час в системі доступно ~ 58 680 ETH, з яких 29 830 ETH прив’язані до існуючих депозитів. Поточна межа пропозиції становить 750 BTC, а поточна випущена сума — 513 TBTC, тому доступного ETH більш ніж достатньо для розміщення доступної вартості.
Дії управління
Команда зробила тільки одну річ, щоб змінити характеристики мережі: незабаром після того, як обмеження пропозиції збільшилася до 250 TBTC, ми додали два додаткових розміри лоту, 5 BTC і 10 BTC, для депозитів. Це збільшення розміру лота було зроблено для того, щоб врахувати відносно високі ціни на газ, які діяли в той час, оскільки відкриття депозиту має фіксовану ставку. Відкриття більшого розміру лота дозволяє більш рентабельно переміщати BTC в систему, одночасно збільшуючи ризик вартості разових депозитів (оскільки кожна підписувальна група тепер несе відповідальність за велику кількість BTC і відповідно збільшує суму облігацій).
372 депозитів, відкритих з тих пір (не всі з яких були профінансовані), були з цими більш високими розмірами лотів — всього 55% депозитів, відкритих з моменту випуску rc.1.
Спостереження ліквідацій
Ми спостерігали 4 ліквідації в перший місяць роботи системи, майже все в перший тиждень. Зверніть увагу, що для цих цілей збій вважається подією, яке призвело до ліквідації чи здавалося б втрати BTC. Кожен з них докладно описаний нижче за відповідною причиною.
Система tBTC, навіть в стані RC, унікальна тим, що вона децентралізована, при цьому гарантуючи, що кожен TBTC відповідає доступним для погашення BTC. Він також унікальний тим, що розроблений для забезпечення того, щоб власник TBTC міг повернути еквівалентну кількість BTC в разі більшості збоїв системи за рахунок підвищеного ризику для підписувальних сторін.
Це проектне рішення було підтверджено у випуску-кандидаті: хоча було 4 депозиту (0,5% всіх депозитів, що становлять ~ 0,5% від загальної вартості випуску в системі), які зіткнулися з проблемами, у всіх випадках вкладник міг отримати їх вартість в BTC. Більш того, тільки одна емісія підписувальної сторони привела до втрати облігацій. Хоча ми, очевидно, вважали за краще б, щоб не було проблем і втрат по облігаціях, основна мережа ніколи не буває такою ж, як тестова, і використання будь-якої системи пов’язане з певним ризиком.
Переходи між станами депозиту
Два депозиту, один 7 жовтня (0,1 BTC) і один 27 вересня (0,2 BTC), були ліквідовані через відсутність переходу між станами.
За допомогою спільноти команда допомагає перевести вклади, які знаходяться в певних становищах, які можуть привести до ліквідації, в їх «наступні» становища. Хоча dApp зазвичай робить це, користувачі можуть іноді відмовлятися від проміжного потоку dApp, і підписувальний клієнт, який обробляє головний матеріал, на даний час не просуває депозит через ці становища автоматично. Ці обидва депозити виникли через неможливість здійснити такий перехід стану — перший стався за кілька годин до того, як рішення для їх проштовхування було включено, а друге — через помилку в цьому рішенні.
Планується робота, щоб клієнти ECDSA подбали про це в короткостроковій перспективі.
Відсутні резервні копії підпису особи
25 вересня депозит в розмірі 10 BTC був ліквідований через те, що підписанти не змогли вчасно надати підпис для підтвердження викупу, що використовувався для переміщення BTC назад з системи tBTC в ланцюжок BTC. Один з розглянутих операторів зв’язався з нами під час підпису для погашення, щоб вказати, що вони спостерігають відсутність активності у свого клієнта.
Після дослідження ситуації в мережі ми визначили, що у одного з операторів в групі підпису сталася безповоротна втрата даних їхніх спільних ключів через комбінації недостатньої кількості резервних копій і зміни сервера (не пов’язаної з клієнтським програмним забезпеченням). Ми координували ліквідацію фондів, в результаті чого всі підписувальні облігації були повернуті підписувальним сторонам, які забезпечували депозит. Початковий вкладник зміг отримати 10 TBTC за допомогою цієї ліквідації для майбутнього погашення іншого депозиту, підтримуючи основну гарантію системи, що власники TBTC будуть в безпеці.
В результаті ми також зробили кілька додаткових дій, щоб знизити ймовірність повторення цієї проблеми:
Ми переконали відповідного оператора передати свої операції одному з постачальників ставок, щоб домогтися більшої надійності.
Ми звернулися до решти операторів в системі, щоб нагадати їм, що вони повинні мати постійне резервне копіювання ключових матеріалів в якості регулярної частини їх оперативного плану.
Ми додали в нашу документацію ще кілька закликів до дії, щоб підкреслити, що резервне копіювання ключового матеріалу — це базове очікування для операторів в системі.
Стан гонки в клієнті ECDSA
26 вересня депозит в розмірі 10 BTC був ліквідований через стан гонки в клієнті ECDSA, викликаного комбінацією подій:
Така ж подія BondedECDSAKeepCreated була отримана клієнтом ECDSA від трьох операторів, всі через ~ 30 секунд після першої події. Ми підозрюємо, що причиною стала короткострокова реорганізація мережі.
За час, що минув з моменту отримання першої події, всі 3 підписали завершили процедуру генерації розподіленого ключа, згенерували приватні загальні ключі і відкритий ключ для групи, що відповідає цій події.
У той ж час всі три підписанта також представили транзакції для публікації відкритого ключа до контракту BondedECDSAKeep.
Жодна з трьох транзакцій не була підтверджена в мережі.
Через те, як клієнт керував уявленнями пов’язаних сховищ ECDSA в пам’яті, після завершення генерації ключа і до підтвердження транзакції публікації відкритого ключа існувало тимчасове вікно, коли повторювальна подія могла викликати нормальне спрацьовування генерації другого ключа. В результаті в наведеному вище сценарії всі три підписувальні особи виконали генерацію другого ключа і відправили другий ключ в ланцюжок. Он-чейн контракт
справедливо відхилив другий ключ; однак через збіг обставин на клієнті другий ключ перезаписав перший ключ в постійному сховищі системи, і обидва циклу генерації ключів були визнані успішними.
Після завершення генерації ключа клієнт запускає моніторинг подій для запитів підпису з ланцюжка ー це механізм, який використовується для відповіді на запити погашення. У цьому випадку кожен з 3 підписантів депозиту створив двох спостерігачів за подіями, по одному для кожного ключа. Коли з’явився запит на підпис погашення, обидва спостерігача побачили його і спробували брати участь в обміні підписом в мережі. Через природу протоколу наявність 6 підписують осіб з двома різними наборами загальних ключів, які намагаються виконати єдиний підпис, призводило до повторюваних збоїв протоколу підпису. Таким чином, підпис погашення не може бути наданий.
Після закриття депозиту їм було повернуто приблизно 1/3 застави кожного підписанта. Вкладник був об’єднаний в TBTC, як і в попередньому випадку, зі збереженням гарантій системи перед вкладниками. Команда підтвердила, що ключові загальні ресурси, які досягли постійного сховища, були для ключа, який не отримав BTC, таким чином, базовий BTC був втрачений. Це робить неможливим для підписантів отримати більше, ніж вже повернуті облігації.
В результаті цього інциденту було внесено кілька змін:
В той самий день, що і відповідь на інцидент, був об’єднаний PR, що фіксує основну умову гонки, і випуск був позначений і побудований з цими змінами. Всі оператори були повідомлені про підвищення категорії клієнта та про можливі втрати по облігаціях.
Протягом тижня був готовий інструмент для дослідження основних ключових акцій. Хоча результату було недостатньо для відновлення BTC, інструментальні засоби складають основу майбутніх потреб у відновленні ключів. Намір полягає в тому, щоб відновлення ключа було незвичайною, але добре підтримуваною частиною клієнтських операцій, оскільки це механізм, за допомогою якого оператори зазвичай можуть відновити будь-яку вартість, втрачену в результаті ліквідації.
Незабаром на цьому тижні був випущений клієнтський випуск 1.4.0, в якому були додані додаткові моментальні знімки ключового матеріалу, тож навіть якщо є інша можливість перезапису ключового матеріалу, всі ключові загальні ресурси всіх поколінь ключів будуть збережені в окремому каталозі без можливості перезапису.
Інші типи збоїв
В основній мережі спостерігалося кілька інших типів збоїв, жоден з яких не привів до ліквідації. Коротко про них нижче:
Вкладники, які не зуміли поповнити відкриті ними вклади. Це призводить до втрати вкладниками плати за відкриття вкладу. Облігації підписантів утримуються протягом короткого періоду часу (3 години) і потім можуть бути випущені підписантами. Деякі з них були помічені на ланцюжку.
Вкладники некоректно фінансують депозити (відправляючи підписувальній групі менше необхідної суми BTC). Нічого з цього не спостерігалося в мережі протягом першого місяця; проте в цих випадках базовий BTC може бути відновлений при деякій координації за умови спільної роботи підписувальних сторін. Триває робота по автоматизації цієї координації.
Вкладники не змогли вчасно довести факт фінансування. Транзакція фінансування BTC повинна мати 6 підтверджень протягом 3 годин після того, як депозит отримав відкритий ключ, або депозит може бути закритий підписавшими особами. Доказ може не бути представлено вчасно, якщо транзакція BTC добувається надто повільно, і вкладник не збільшує свій гонорар, або якщо транзакція має свої підтвердження, але вкладник ніколи не представляє доказ в ланцюжок. Один з них спостерігався протягом першого місяця; як і при неправильному фінансуванні, базовий BTC в цих випадках може бути відновлений за допомогою координації. Як і у випадку з неправильним фінансуванням, в даний час ведеться робота по автоматизації цієї координації в разі дефолту.
У обслуговуючого пристрою Relay закінчується газ. Крос-ланцюговий характер tBTC вимагає наявності Relay SPV, яке дозволяє контрактами Ethereum підтверджувати наявність транзакції BTC в ланцюжку Біткоїнів і підтверджувати її певну кількість разів. Без цього компонента докази фінансування та погашення не можуть бути відправлені в tBTC, що призведе до зупинки процесу внесення / погашення в систему. Будь-які недоведені кошти як і раніше можуть бути повернуті, як і в більшості інших станів, в які може увійти система, але, очевидно, це не ідеально. Основні причини цієї конкретної проблеми все ще досліджуються — не вдалося запустити повідомлення про перевірку балансу і сторінку про недостатність коштів у супроводжуючого. На щастя, команда Strudel.finance помітила цю проблему
невдовзі після того, як вона виникла, і почала завантажувати оновлення Relay — спочатку вручну, а потім автоматично. Система tBTC (і система Strudel.finance, яка також покладається на Relay) в цей час працювали нормально. Ви також можете прочитати їх повідомлення в блозі про інцидент.
Як правило, спільнота діє як «повідомник останньої інстанції» для команди, і в результаті велика частина команди уважно стежить за згадками Keep Discord. Завдяки тому, що Strudel.finance розпочав естафету, ніхто не звернувся до команди, поки це не зробила команда Strudel. На жаль, вони звернулися до сервера Discord tBTC, а не до сервера Keep, який є новим і за яким команда не так уважно стежить. Ми самостійно виявили проблему з нашого боку і виправили її, але в результаті ми також почали більш уважно стежити за tBTC Discord.
Участь спільноти
Як згадувалося вище, спільнота відіграє велику роль в успішній і правильній експлуатації системи tBTC ー команда в основному не випускає TBTC, в основному не керує вузлами в мережі і в значній мірі не пов’язує ETH. Таким чином, TBTC, що знаходяться в обігу і діючі підписувальні вузли в значній мірі знаходяться поза нашим контролем, і ми покладаємося і заохочуємо зворотний зв’язок, а також спілкування з спільнотою, щоб допомогти направляти як розробку проекту, так і виявлення малоймовірних або незвичайних проблем.
Ми хотіли відзначити конкретні вклади, що надійшли від різних частин спільноти, нагородою, за допомогою програми Playing for Keeps:
Запуск сценаріїв: кілька членів спільноти запускають додаткові сценарії для відстеження та переміщення стану системи між депозитами, де це доцільно. У цих випадках добре підходить резервування, яке захищає від одиничних точок відмови.
Дослідження: як зазначено на початку цього звіту, кілька членів спільноти зібрали різні погляди на різні аспекти систем Keep і tBTC. В результаті з’явилися відмінні інструменти, які працюють швидко і надають величезну кількість корисної інформації про мережу. Команда сама використовує деякі з цих інструментів в тих випадках, коли вони забезпечують уявлення, відмінне від інструментів, які ми створили.
Оновлення Relay SPV: співпрацівники з Strudel.finance підтримували Relay в робочому стані в ситуації, коли баланс нашого власного облікового запису супроводжуючого був недостатнім (докладніше див. Інші типи збоїв). Зараз ми працюємо над співпрацею з ними, щоб спонукати більше людей підтримувати Relay в актуальному стані, оскільки це, по суті, суспільне благо, і наша основна підтримка його була обумовлена обставинами, а не наміром.
Висновок і наступні кроки
У перший місяць існування tBTC виникло відносно небагато серйозних проблем. Дві виявлені проблеми, що впливають на користувача, були помічені в перший тиждень роботи системи і привели до підвищення стійкості клієнта ECDSA і кращому інформуванню спільноти про вихідні очікування щодо роботи клієнта в мережі. Ми не чули ні про які збої в клієнтському програмному забезпеченні, і кілька команд звернулися до нас, щоб відзначити загальну стабільність клієнта.
В проекті є кілька короткострокових і середньострокових поліпшень клієнтів, які вже були в дорожній карті і допомогли в перший місяць, або які є прямим результатом спостережуваної поведінки в перший місяць. Ось кілька прикладів:
Автоматизація повернення коштів для автоматичної координації у разі проблем з фінансуванням.
Специфічне для tBTC поведінка в клієнті ECDSA щодо запобігання проблем, пов’язаних з переходом між станами. В даний час це обробляється за допомогою позасмугових сценаріїв, але його внутрішня інтеграція в клієнт ECDSA зробить це прямою відповідальністю підписувальних сторін.
Підтримка постійного сховища, не заснованого на диску, щоб дозволити зберігання загальних ключів, наприклад зашифровані сегменти S3 або інші форми надійного керованого постійного сховища, які вимагають менших витрат на постійне резервне копіювання.
Розгляд зменшення розмірів лота для зниження ризику за депозитом. Рішення про розмір лота врівноважують ризик кожного депозиту з ефективністю добутку (оскільки депозити мають фіксовані накладні витрати на відкриття нових лотів) і іншими компонентами стимулювання (такими як механізм винагороди за розміщення ставок).
Децентралізація обслуговування Relay складності BTC в Ethereum шляхом стимулювання обслуговування Relay. Складності у співпраці з іншими командами, які використовують його, наприклад Strudel.finance.
Градуйована межа поставки tBTC rc.1, схоже, ясно дав зрозуміти підписантам і користувачам, що довіра до системи з часом має зрости, як і було підтверджено на практиці. Ми як і раніше переконані в тому, що ніякі заощадження користувачів ніколи не піддавалися ризику і що механізми відновлення засобів користувачів в разі несподіваних збоїв працювали в точності так, як задумано.
Попереду ще багато місяців і років децентралізованого заробітку BTC на DeFi!
Дякую за увагу!
Оригінальна стаття: https://github.com/keep-network/keep-core/blob/master/docs/status-reports/tbtc-2020-09-15-to-2020-10-13.adoc
Приєднуйтесь до Discord Keep та Discord tBTC.
Переклад: DenisKrivilev#5773
