Безопасное выполнение не цепь для интеллектуальных контрактов в биткойнах: протокол отказоустойчивости
8 июля 2025 г.Таблица ссылок
Аннотация и 1. Введение
- В цепочке контракты
- Контракты вне цепи
- Выводы и ссылки
3. вне цепи контракты
Теперь мы пройдем через шаги, которые необходимы для выхода из цепи, выполнение лучшей из трех статей. Во -первых, Алиса и Боб генерируют слегка модифицированную копию контракта (см. Рисунок 4a), где есть новая транзакция головки, которая имеет входные данные в качестве входных данных, двухнатальных отложений, транзакция init (входной вход) и модифицированная транзакция ставки, которая теперь имеет временную транзакцию 3𝑡 относительно его ввода, init. Оттуда модифицированный контракт следует за структурой исходной. Опять же, отражение протокола, описанного для установки контракта на цепочке, Алиса и Боб отправляют друг другу неявные подписи, необходимые для каждой транзакции, оставляя последних тех, которые разблокируют два месторождения и включают голову. После того, как у них будут все необходимые подписи, они добавляют направление к блокчейну, тратя свои месторождения. Обратите внимание, что в этот момент включен инициатор транзакции (поскольку они уже обменивались подписями), но, в отличие от выполнения контракта на цепь, Алиса и Боб должны воздерживаться от добавления его к блокчейну прямо сейчас. Действительно, транзакция init будет добавлена только тогда, когда участник решит перенести выполнение обратно в цепь. Если оба честны, это произойдет только тогда, когда контракт достиг листа.
С этого момента наш пример будет следовать потенциальному следу выполнения договора, представленного на рисунке 3, предполагая, что Oracle выявит «L1», «W2» и «L3», и что ни Алиса, ни Боб не согласятся принять раннюю выплату. После того, как Oracle раскрывает «L1», в оригинальном контракте на цепь Боб добавит L ?? к блокчейну, продвигающему государство вперед. Вместо этого, в протоколе вне цепь, два участника создают трансплантат: копия поддерею, коренящегося в L ??, Модификация L ?? так что его вход теперь является транзакцией init и так, чтобы он имел относительный временный интервал 2 𝑡. После приготовления этого поддеревания к контракту вне цепи (см. Рисунок 4b), Алиса и Боб обменяются неявными подписями, необходимыми транзакциями в поддере. Если на этом этапе либо участник хочет принести выполнение контракта в цепочке, то он может сделать это, добавив транзакцию init, ожидая 2𝑡 единиц времени, а затем добавив L? Обратите внимание, что после того, как Init был добавлен к блокчейну, противник мог попытаться «отказаться» от контракта в предыдущее штат, добавив ставку вместо L ??. Тем не менее, из -за задержек, соблюдаемых TimeLocks, любой честный участник может предотвратить это, добавив L ?? (который разблокируется раньше, чем ставка), как только он будет включен.
Следующие шаги с цепочкой выполняются аналогичным образом: Алиса и Боб могут привлечь копию поддерево транзакций, конус
те, которые созданы в предыдущих шагах. После того, как трансплантат создан, они обмениваются неявными подписями, оставляя на последнее время для корня поддереи.
Предполагая, что теперь, когда Алиса и Боб продолжают выполнять нецелесообразное исполнение, они будут ждать, пока Oracle раскроет следующий результат (в данном случае «W2»), затем привнести поддерев, укорененный в LW?. Наконец, после того, как «L3» выявится, они могут привлечь поддере, состоящий только из транзакции LWL, получая полное дерево вне цепочки, показанное на рисунке 5. Теперь, когда контракт не имеет дальнейших возможных шагов, Алиса и Боб завершают выполнение, поставив и init, и LWL в цепь. Таким образом, контракт завершается только с 3 транзакциями в цепочке (Head, Init и LWL), когда протоколу встроенной цепь требовался 4 транзакции для того же пути выполнения. Следовательно, участники сэкономили одну плату, которая может быть перераспределена LWL.
ПротоколОтойдя от примера, мы представляем общий протокол выполнения не цепи для произвольного договора. Учитывая договорное дерево в ходе цепь, участники выполняют эти шаги:
Создайте Head Transactions Head (который Freemes One Depoit для каждого участника контракта), init (который обрабатывает главу) и создает модифицированную копию контракта, так что корень контракта теперь может выкупить init после ожидания нескольких временных единиц, равных глубине исходного дерева контракта. Каждая из этих транзакций потребует подписи от каждого участника контракта, чтобы быть выкупленным (так же, как и неявные подписи контракта на цепь).
Обмениваться неявными подписями на каждую транзакцию.
Потратьте депозиты, подписав голову и добавив ее на цепочку.
Повторите следующее, пока не будет достигнут лист. Если во время какого -либо из следующих шагов, любой участник не сотрудничает, то добавьте init. Как только init добавляется (любым участником) вырваться из петли.
а) Выберите возможную филиал контракта, удовлетворяя требованиям, которые были установлены краем (то есть ожидание, раскрытие хэшей, отправка подписей).
б) Создайте копию поддерева, конунного в выбранном состоянии, и приведите ее (вне цепочки) к транзакции init, с временем, который обеспечивает соблюдение ожидания нескольких временных единиц, равных глубине поддерево.
в) обмениваться всеми неявными подписями на транзакцию в поддере. Подписи для корня обмениваются последними.
Если init не был добавлен, то поместите его в цепочке.
Добавьте корень последнего трансплантата, как только истекает его TimeLock. Если трансплантат не является листом, продолжайте выполнение в цепочке, искупив транзакции поддерево.
Мы отмечаем, что подписи, сгенерированные в пункте 4C, действительно необходимы, и ранее сгенерированные подписи не могут быть использованы повторно. Это связано с тем, что транзакции в трансплантатах имеют разные входные поля из тех, кто в исходном дереве, а подписи должны быть рассчитаны по всей транзакции. Как и в протоколе контракта на цепь, мы подчеркиваем, что подписание всего трансплантата перед его корнем необходимо, чтобы избежать остановки атак. По этой причине мы подписываем транзакции шаг за шагом, когда контракт выполняется.
УгрозыСвязанные, желающие нарушить протокол, могут попытаться потратить контрактные транзакции на блокчейн, чтобы отклониться от поведения контракта, или они могут попытаться предотвратить выполнение некоторого договора.
В присутствии, по крайней мере, одного честного участника, потратить на контрактную транзакцию совершенно непреднамеренно невозможно, поскольку каждому краю дерева требуется подпись от каждого участника. Такие атаки, следовательно, ограничиваются добавлением транзакции среди тех, которые подписаны во время протокола.
Вместо этого попытки остановить выполнение контракта более тонкие, поскольку противник может просто не сотрудничать с честными участниками, как намекали на 4 -й этапе протокола. Например, вредоносные участники могут:
• Не согласен с следующей ветвью контракта в пункте 4A (или согласен, но отказывайтесь отправлять возможные подписи и хэш, требуемые краями контракта).
• Откажитесь отправлять подписи, необходимые в пункте 4C в течение разумного времени, останавливая выполнение договора.
• Несгорочно включите init в цепочке, в то время как следующий шаг контракта все еще обсуждается/выполняется.
Чтобы сорвать такие атаки, честные участники должны бдительно бдительно на выполнение контракта и соответственно отреагировать, чтобы восстановить правильное выполнение договора. После обнаружения одного из вышеупомянутых злонамеренных поведений, честный участник должен переместить выполнение в цепочке, добавив транзакцию init (если не еще в цепочке), а затем, добавивпоследнийпрохождение. Это гарантирует, что первоначальное поведение контракта сохранилось.
3.1. Оценка
Мы проводим сравнение между нашим протоколом для выполнения не цепи и стандартным выполнением контракта на цепь. Основные преимущества нашего нового протокола - следующие:
• Снижение сборов в лучшем случае. Если договор доведен до завершения через шаги вне цепи, то на блокчейн добавляется только три транзакции, независимо от размера первоначального договора. Это значительно снижает стоимость глубоких контрактов. Более того, даже если контракт выполняется только частично выполняется вне цепи, двух шагов вне цепи достаточно, чтобы обеспечить стоимость выполнения наравне с исходным контрактом на цепочке. Любой дополнительный шаг в стороне от цепочки еще больше снижает стоимость.
• Никаких откатов в государстве. Согласно предположению, что, по крайней мере, один участник контракта честен, у нас есть, что если будет выполнен шаг вне цепь, ни один противник не сможет поставить в цепь транзакцию, связанную с каким-либо предыдущим государством. Действительно, после того, как init добавлен на цепь, следующая транзакция, которая будет добавлена, будет корнем трансплантата. Поскольку в первую очередь включены последние трансплантаты, честный участник всегда сможет выкупить init с последним трансплантатом, прежде чем можно будет добавить более раннее.
• Нет дополнительного ожидания в лучшем случае. С каждым шагом с цепочкой, временный завод на следующем трансплантате уменьшается, достигая 0 при достижении листа.
С другой стороны, основные недостатки выполнения не цепь являются следующими:
• Слегка увеличили сборы в худшем случае. Если выполнение вне цепочки немедленно прекращено, то транзакция init вводится в цепочке сразу после ее включения, и единственное доступное продолжение состоит из транзакции, которая была корнем исходного контракта на цепь. Итак, у нас есть накладные расходы на две дополнительные транзакции (голова и init).
• Погашение инициировать может потребовать ожидания. За исключением лучшего случая (когда контракт завершен за пределами цепи), механизм отказоустойчивости требует, чтобы привитые поддереи имели временные рамки. Это означает, что всякий раз, когда участник вынужден двигаться в цепочке из-за попытки атаки, им придется подождать, прежде чем они смогут возобновить выполнение в цепочке. Как и в случае сборов, это более вредно в случае ранней атаки, где временные рамки больше.
• Увеличение количества подписей и сообщений. На каждом шаге контракта с цепью участники должны обмениваться подписями на каждую транзакцию в привившем поддере. Сценарий худшего случая происходит, когда оригинальное дерево контрактов представляет собой единую цепочку с 𝑛 узлами: это приводит к тому, что каждый участник отправляет 𝑂 (𝑛 2) дополнительные сообщения.
При рассмотрении сборов наш протокол обеспечивает значительные преимущества практически во всех сценариях. Основной недостаток, по -видимому, связан с временными, поскольку злонамеренный участник может отложить завершение контракта на количество времени, которое линейно растет с глубиной дерева контракта. Повышенное количество подписей не кажется слишком вредным, особенно при рассмотрении того, что для сбалансированных договорных деревьев накладные расходы составляют только 𝑂 (𝑛) сообщений.
Мы также отмечаем, что атаки не рекомендуются тем фактом, что сборы, которые сохранены из-за успешного выполнения, затем перераспределяются на участников контракта.
ОграниченияМы отмечаем несколько ограничений нашего подхода. Во -первых, участники всегда должны быть живыми и следить за блокчейном на предмет злонамеренного поведения, своевременно реагируя на них. Это предполагает, что противники не могут выполнять атаки DOS, которые могут задержать честных участников в течение значительного времени (то есть дольше, чем отказоустойчивые временные рамки). Для этого мы предполагаем, что в наших временных времени одна единица времени достаточно длинная, чтобы убедиться, что у честных участников было достаточно времени, чтобы действовать, даже в присутствии атак DOS. Обратите внимание, что это предположение широко распространено, поскольку оно применяется ко всем протоколам блокчейна на основе времени, таких как хэшированные временные контракты [6].
Наш подход вычисляет временные рамки в соответствии с высотой исходного дерева контрактов, которое должно быть конечным и статически известным. Это предположение обменивается протоколом выполнения в ходе цепь. Это неизбежно при работе с платформой Биткойн из -за ограниченной выразительности языка сценариев.
Наконец, в нашем протоколе все платы за контракты должны быть предоставлены заранее и заблокированы в рамках транзакции головы. Кроме того, мы должны заранее указать, сколько каждая транзакция в дереве будет платить в качестве платы: это происходит во время подписания, намного раньше, чем когда на самом деле плата заплачивается. Только после прекращения контракта заблокированные, но невыразимые сборы возвращаются участникам. Эта проблема также разделяется по протоколам контрактов в цепочке. В протоколе вне цепи проблема смягчается тем фактом, что сборы могут быть скорректированы после колебаний рынка при создании новых трансплантатов. Тем не менее, после того, как выполнение переносится в цепочке, снова заблокирована.
4. Выводы
Мы представили оптимистический протокол для выполнения разворота смарт-контрактов Биткойн. Наш протокол позволяет пользователю сохранять плату за транзакцию.
Безопасность нашего протокола основана на том факте, что честные участники проводят некоторые транзакции (последний трансплантат), которые могут быть помещены в цепь, когда это необходимо, чтобы совершить последнее состояние в блокчейн. Эффективность нашего протокола следует от участников, которые не должны ставить эту транзакцию на цепь до самого конца контракта (если все участники честны).
Этот механизм плавающих транзакций напоминает тот, который использовался с помощью протокола сети Lightning [8]. Несмотря на то, что это широко принятый и изученный протокол, он обеспечивает лишь ограниченное подмножество контрактов (в основном фокусируясь на каналах микроплатежа). Напротив, наш протокол может быть применен к общему дереву контракта. Другие методы эффективного выполнения контрактов биткойнов полагаются на расширение протокола биткойнов, чтобы добавить новый тип подписи [9]. Наконец, некоторые подходы обменяют более сложную инфраструктуру в обмене более гибкой смарт -контракта: например, [10] использует внешнюю доверенную среду выполнения для сертификации выполнения контракта, в то время как [11] создает новый блокчейн 2 уровня 2, который использует Биткойн в рамках своего консенсусного протокола. В отличие от этого, наш протокол может быть выполнен на биткойнах, не требуя каких -либо изменений в протокол биткойнов, увеличивая доверенную вычислительную базу или накладывая сложную инфраструктуру блокчейна.
Ссылки
[1] H. A. Kalodner, S. Goldfeder, X. Chen, S.M. Weinberg, E. W. Felten, Arbitrum: масштабируемый, частные интеллектуальные контракты, в: Usenix Security Symposium, 2018.
[2] C. Li, B. Palanisamy, R. Xu, Масштабируемая и конфиденциальная дизайн интеллектуальных контрактов внедорожных/выключенных контрактов, в: 2019 IEEE 35-я Международная конференция по технической конференции по техническим семинарам по технике данных (ICDEW), 2019, стр. 7–12. doi: 10.1109/icdew.2019.00-43.
[3] A. de Salve, L. Franceschi, A. Lisi, P. Mori, L. Ricci, L2DART: система управления доверием, интегрирующая вычисления блокчейна и не цепи, ACM Trans. Интернет -технол. 23 (2023). URL: https://doi.org/10.1145/3561386. doi: 10.1145/3561386.
[4] М. Бартолетти, Т. Симоли, Р. Зунино, Веселье с биткойнскими интеллектуальными контрактами, в: Изола, 2018, с. 432–449. doi: 10.1007/978-3-030-03427-6 \ _32.
[5] М. Бартолетти, Р. Зунино, Битмл: исчисление для биткойнских интеллектуальных контрактов, в: ACM CCS, 2018. DOI: 10.1145/3243734.3243795.
[6] N. Atzei, M. Bartoletti, T. Cimoli, S. Lande, R. Zunino, Sok: разворачивание умных контрактов биткойнов, в: Post, том 10804 Lncs, Springer, 2018, с. 217–242. doi: 10.1007/978-3-319-89722-6.
[7] М. Андричович, С. Дзимбовски, Д. Малиновский, Л. Мазурек, Безопасные многопартийные вычисления на биткойнах, в: IEEE S & P, 2014, с. 443–458. doi: 10.1109/sp.2014.35, впервые появился в архиве криптологии eprint, http://eprint.iacr.org/2013/784.
[8] J. Poon, T. Dryja, The Bitcoin Lightning Network: масштабируемые нецелесовые мгновенные платежи, 2015.
[9] C. Decker, R. Russell, Eltoo: протокол простого уровня 2 для биткойнов, 2018. URL: http://diyhpl.us/ ~ bryan/papers2/bitcoin/eltoo.pdf.
[10] P. Das, L. Eckey, T. Frassetto, D. Gens, K. Hostáková, P. Jauernig, S. Faust, A.-R. Sadeghi, Fastkitten: Практические умные контракты на Биткойн, в: Материалы 28 -й конференции Усеникс по Симпозиуму по безопасности, SEC'19, Usenix Association, USA, 2019, с. 801–818.
[11] Рабочая группа SBTC, стеки: слой биткойнов для интеллектуальных контрактов, 2023. URL: https://stx.is/ nakamoto.
Авторы:
(1) Дарио Маддалони, Università Degli Studi Di Trento (Dariomaddaloni.6@gmail.com);
(2) Riccardo Marchesin, Università Degli Studi di Trento (riccardo.marchesin@unitn.it);
(3) Роберто Зунино, Università Degli Studi Di Trento (roberto.zunino@unitn.it).
Эта статья есть
Оригинал