Обзор технической системы tBTC

Денис Кривилев
5 min readNov 16, 2020

--

tBTC включает новые конструктивные особенности, которые несут важные последствия для пользователей. Эта статья объясняет четыре из них: TDT, несколько размеров лотов, случайный маяк Keep и пороговые подписи.

Депозитный токен TBTC (TDT)

Токен депозита TBTC (TDT) — это незаменимый маркер, который минтится, когда пользователь делает депозит. TDT — это не изменяемый токен ERC-721, который служит аналогом TBTC. Он представляет собой требование к базовому депозиту UTXO на BTC-блокчейне.

Депозиты TBTC могут быть заблокированы или разблокированы. Заблокированный депозит может вернуть владелец депозита только с помощью соответствующей TDT. Каждый TDT уникальный для депозита, который его минтит и имеет эксклюзивное право на погашение депозита на срок до 6 месяцев.

После того, как депозит будет полностью квалифицированный через подтверждение транзакции с финансированием биткоинов (что называется реле SPV), владелец может подать запрос на погашение и после уплаты любых непогашенных комиссий за подписание гарантировать тот самый UTXO, который финансировал депозит в сети биткоинов.

TDT и TBTC взаимозаменяемы из-за контракта, который называется торговым автоматом, управляющий обменом TDT на TBTC и наоборот.

• Учитывая TDT, он будет минтить TBTC.

• Учитывая TBTC, он сожжет его и вернет определенные TDT.

TDT требует погасить заблокированный депозит BTC. Без него вы не сможете вернуть свой BTC.

TDT можно передавать. Владельцы могут выбирать, торговать ими, или использовать в качестве залога в другом месте.

В случае мошенничества или проблем обеспечения, владельцу TDT гарантируется компенсация в TBTC через залог подписывающей группы. Если депозит погашен другим счетом после того, как он достиг срока, тогда владельцу TDT гарантируется компенсация в TBTC (за вычетом комиссии за подписание). Обратите внимание, что владелец TDT может выкупить свой депозит за BTC даже после того, как прошел 6-месячный срок, если ни один пользователь не воспользовался им.

Поскольку кража депозита в 1 BTC имеет большее значение, чем депозит в 0,001 BTC, первый, скорее всего, более восприимчив к таким атакам, как реорганизация. Как NFT, TDT позволяют оценить этот риск, что очень важно для приложений, использующих BTC в качестве обеспечения. Любому получателю TDT нужно будет самостоятельно оценить все факторы риска данного токена. TDT предназначены для получения чистой выгоды путем изоляции риска, поскольку атаки на депозит, поддерживающий TDT, должны влиять только на владельца TDT, а не на всю валюту, привязанную к предложению.

Лоты и размеры тех самых лотов

Депозиты на tBTC управляются лотами. Чтобы сделать систему рациональной и управляемой, лоты — это один из набора фиксированных размеров, которыми управляет система. Если вкладчик хочет внести большую сумму BTC, чем поддерживается существующими размерами лотов, они должны создать несколько запросов на депозит и сделать несколько депозитов. Это позволяет поддерживать каждый депозит другой группой подписантов, упрощает связывание групп подписи и изолирует широкую систему от изолированных отказов группы подписей, вредоносных или других происшествий.

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

Каждый депозит должен соответствовать одному из стандартных размеров партии.

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

В случае недоплаты — когда пользователь вкладывает сумму, меньше выбранный размер партии BTC — система не создаст подтверждение, можно погасить за TBTC. Пользователь теряет BTC, заблокированный в депозите, который можно разделить между подписантами.

Пользователи должны это хорошо понимать. Например, в ситуации, когда единственным доступным размером партии является 1 BTC, нетрудно представить, как пользователь пытается требовать 1 TBTC, сделав два депозита по 0,5 BTC каждый. Пользователь, который сделает это, потеряет все свои BTC, поскольку система просто распознает два отдельных случая недоплаты. Короче говоря, размер партии депозита фиксируется при создании депозита, и депозит должен финансироваться именно такой суммой.

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

В примере размера лота 1 BTC пользователь, который вложит 1,4 BTC, получит подтверждение, что позволяет установить ровно 1 TBTC (сумма соответствует размеру партии). Сейчас в системе есть депозит негабаритных размеров, который можно было бы ожидать, чтобы его быстро выкупили, предоставив возможность обменять 1 TBTC на 1,4 BTC. Пользователь, который внес дополнительный BTC, сможет, как и все остальные пользователи, выкупить свой 1 TBTC за 1 BTC, но дополнительные 0,4 BTC теряются (если пользователь не осознал свою ошибку и быстро погасит свой TBTC за первоначальный депозит 1,4 BTC) .

Система принимает только первый UTXO, который превышает размер депозитного лота. Все остальные BTC, присланные группе подписантов, теряют свою силу. Поэтому чрезвычайно важно, чтобы вкладчики направляли только одну UTXO. Принятие нескольких UTXO от вкладчиков приведет к значительной сложности сети и платы за газ, поскольку каждый UTXO должен быть подтвержден с помощью SPV, а подпись на нем четко уполномоченная. Подписантов следует стимулировать для подписания каждой транзакции, несмотря на то, что общая стоимость UTXO не известна.

Случайный маяк для выбора подписанта

Сеть Keep требует надежного источника случайности для выбора подписантов tBTC. Это принимает форму порогового реле BLS.

Когда поступает запрос на создание группы подписантов, система tBTC использует случайный маяк из защищенного децентрализованного случайного маячка для случайного выбора членов группы подписантов из соответствующего пула. Эти подписанты координируют распределенный протокол генерации ключей, что приводит к открытому ключу ECDSA для группы, который используется для создания адреса кошелька, который затем публикуется в цепочке хостов. Этим завершается этап выбора подписантов.

Пороговые подписи

tBTC использует пороговые подписи для генерации ключей. Пороговые подписи позволяют группе подписантов генерировать единственный открытый ключ из набора частных ключей “совместных ресурсов”. Этот метод позволяет подписантам создавать подписи от имени большей группы. Пользователи могут проверить группы подписантов с помощью одного открытого ключа, он соответствует множеству частных ключей. Это обеспечивает безопасность без требований к работе стандартных многозначных конструкций.

Пороговые подписи обеспечивают ряд преимуществ:

• Для группы нужно мало координаций

• Ни одному члену группы не надо доверять

• Маленький шанс, что половина группы злонамеренная или не может вовремя работать

Для tBTC v1 группы подписи составляют 3 из 3, то есть это группы из 3 подписантов, которые требуют сотрудничества всех 3 подписантов для создания подписей от имени группы.

Вы можете найти дополнительную информацию о пороговых подписях здесь.

Посетите наш GitHub, чтобы получить дополнительную информацию, инструменты и документацию. Присоединяйтесь в список рассылки tBTC. Чтобы узнать больше о техническом дизайне tBTC, прочитайте техническую спецификацию. Присоединяйтесь к каналу Keep #tbtc на Discord, чтобы получить технические ответы на вопросы по tBTC и tbtc.js, а также следите за новостями и возможностями участия в Twitter.

Присоединяйтесь к Discord tBTC.

Спасибо за внимание!

Оригинал статьи: https://tbtc.network/developers/tbtc-technical-system-overview/

Перевод: Discord @ DenisKrivilev#5773

--

--

No responses yet