Джереми Рубин две недели назад выпустил предложение под названием Un’FE’d Covenants (FE = Functional Encryption). Учитывая продолжающиеся дебаты по предложениям о ковенантах для Bitcoin в течение последних года или двух, его предложение знаменует собой новый практический вариант. Все предложения о ковенантах до сих пор требуют софт-форка (фактические коды операций), разработки и внедрения непроверенной криптографии (функциональное шифрование) или абсурдно высокой денежной стоимости использования (ColliderScript).
Предложение Джереми не требует софтфорков и не налагает обременительных и непрактичных расходов на пользователей. Компромиссом для этой возможности является радикально иная модель безопасности. Используя систему оракулов и основанные на BitVM облигации, способные к сокращению, ковенанты можно эмулировать на Bitcoin прямо сейчас.
Оракулы
Первая часть схемы — это, очевидно, оракулы, которые обеспечивают выполнение различных условий ковенанта. Это относительно простая установка и первый строительный блок, необходимый для предложения Джереми. Оракул хранит средства в этой схеме и отвечает за выполнение условий ковенанта. Вы хотите, чтобы оракул не должен был локально отслеживать условия ковенанта, которые выполняются для каждой монеты, которую он хранит. Это вводит риск состояния, при котором, если база данных оракула повреждена или потеряна, он не знает, как обеспечить честное выполнение для монет всех пользователей. Чтобы обойти эту проблему, Джереми использует Taproot.
Ключи на основе Шнорра могут быть "подстроены" с помощью хеша данных для изменения публичного ключа. Это позволяет подстроить соответствующий приватный ключ для подписания модифицированного ключа, а также доказать, что любые данные, использованные для изменения публичного ключа, фиксируются этим ключом. Генерация ключа оракулом, а затем модификация этого ключа пользователем с помощью их программы ковенанта позволяет зафиксировать то, что оракул должен обеспечивать, сохраняя при этом бремя хранения этой информации на пользователе.
Оракулы также могут быть федеративными, чтобы минимизировать доверие к одной стороне для обеспечения выполнения условий. Отсюда пользователи могут просто загрузить полученный адрес, и когда они захотят обеспечить условие, обратиться к оракулу(ам) с транзакцией расхода, программой оракула и данными свидетелей, необходимыми для доказательства того, что транзакция, переданная оракулу, соответствует условиям ковенанта. Если транзакция действительна в соответствии с правилами ковенанта, оракул подписывает её.
Для любого простого ковенанта, где исходы известны заранее, такого как CHECKTEMPLATEVERIFY (CTV), пользователи могут немедленно попросить оракула предварительно подписать транзакции, обеспечивающие ковенант, и просто отложить их использование до необходимости.
Важно учитывать сценарий, требующий дополнительного функционала, это основанные на состоянии ковенанты, такие как роллапы, которые прогрессируют регулярно и имеют фактическое состояние (текущий баланс пользователей), за которым нужно следить. В случае таких ковенантов транзакции, которые подписывает оракул, должны фиксировать текущее состояние ковенанта с использованием OP_RETURN, чтобы оракул мог эффективно проверить каждую транзакцию, обновляющую роллап или другую систему, не загружая данные свидетелей для всей истории. Это необходимо, чтобы оракул не хранил состояние локально, что, как упоминалось выше, создает риски.
В долгосрочной перспективе требования к данным оракулов могут быть оптимизированы с использованием доказательств с нулевым разглашением, чтобы оракул мог просто проверить доказательство того, что транзакция, которую его просят подписать, соответствует правилам ковенанта, не проверяя сырые данные свидетелей для более крупных и сложных ковенантов. Однако, в случае таких систем, как роллапы, необходимо соблюдать осторожность при их проектировании, чтобы гарантировать, что данные, необходимые для выхода из системы, были доступны пользователям, чтобы они имели их в своем распоряжении, если им нужно будет напрямую связаться с оракулом для возврата своих средств.
БитVM Облигация
Пока схема полностью доверительная. Вы по сути просто отдаете свои деньги кому-то другому и надеетесь, что ему можно доверять в обеспечении условий произвольных ковенантов. Небольшая модификация вышеуказанной схемы может обеспечить безопасность с помощью криптоэкономического стимула, а не чистого доверия.
Выше было описано, как OP_RETURN необходимо использовать для отслеживания состояния для состоящих ковенантов. OP_RETURN также можно использовать для публикации данных свидетелей любых транзакций ковенанта, чтобы доказать, что условия были правильно выполнены.
Цепь BitVM может быть построена для проверки, соответствует ли транзакция, подписанная оракулом, успешно условиям ковенанта, который он обеспечивает. Помните, что ключ сам по себе, который генерируется, и средства, отправленные для фиксации условий любого ковенанта, который обеспечивается. Это означает, что данные, а также транзакция, расходующаяся с адреса, могут быть переданы в экземпляр BitVM.
Оракулы также могут быть обязаны разместить залоговую облигацию с оператором BitVM (который также должен разместить залог для оракула, чтобы он мог заявить, если его неправомерно обвинят). Таким образом, пока стоимость облигации больше, чем стоимость, обеспеченная в ковенантах оракулом, система может быть безопасно использована. Не будет способа для оракула нарушить условия ковенанта, который он обеспечивает, не потеряв деньги в целом.
Компромиссы
Здесь есть явные компромиссы, которые существенно хуже, чем просто внедрение ковенантов в правила консенсуса. Во-первых, оракул должен быть в сети и доступен, чтобы использовать ковенанты, обеспечиваемые оракулом. За исключением предварительно подписанных ковенантов, таких как CTV, если оракул оффлайн, когда пользователи нуждаются в обеспечении ковенанта, они не могут это сделать. Оракул должен быть присутствовать для подписи.
Во-вторых, требования к ликвидности для облигаций оракула могут стать огромными, если система когда-либо будет широко принята. Это делает её невероятно неэффективной по сравнению с нативной реализацией опкодов ковенанта на уровне консенсуса.
Наконец, дополнительные данные, которые необходимо разместить в блокчейне, чтобы схема облигации BitVM работала, значительно менее эффективны в использовании блокпробелов, чем нативные реализации ковенантов.
В целом, предложение далеко не так эффективно и безопасно, как нативные ковенанты. С другой стороны, если мы окажемся в наихудшем сценарии преждевременной окаменелости, это очень рабочий способ внедрить ковенанты в Bitcoin, не полагаясь на непроверенную криптографию или совершенно непрактичные затраты, накладываемые на конечных пользователей.
Джереми дал нам вариант наихудшего сценария, чтобы расширить проектное пространство того, что можно построить на Bitcoin.
Источник: Bitcoin Magazine
Пост 'Последний Ресурс: Un'FE'd Ковенанты для Bitcoin' появился первым на Crypto Breaking News.
