Отчет о техническом состоянии: 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 подтверждать наличие транзакции Биткойн в цепочке Биткойн и подтверждать ее определенное количество раз. Без этого компонента доказательства финансирования и погашения не могут быть отправлены в 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 сложности Биткойн в 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
Перевод: kudo94#3025
