Это немного измененная версия того, что мы разместили на ethresearch.

Введение

В этом посте мы представляем шаблон проектирования для смарт-контрактов, который мы называем шаблоном контракта реестра фактов или просто контрактом реестра . Этот шаблон позволяет отделить проверку оператора от приложения, которое полагается на его достоверность.

Идея состоит в том, чтобы написать отдельный контракт, единственной целью которого является проверка и запись элементов, удовлетворяющих этому утверждению. Оператор определяется предикатом P(x, свидетелем) , который получает элемент x и некоторую вспомогательную информацию - свидетель и возвращает либо True , либо False . Мы будем ссылаться на x как на факт , если кому-то известен какой- то свидетель , такой, что P возвращает True .

Некоторые примеры заявлений включают в себя:

1. isComposite(x, свидетель) возвращает True тогда и только тогда , когда x является составным числом. Свидетель является делителем x .
2. merkleLeaf((лист, корень), свидетель) возвращает True тогда и только тогда , когда лист является листом в некотором дереве Меркла с корневым корнем . Свидетель — это соответствующий путь аутентификации в дереве.
3. signedText((текст, публичный_ключ), свидетель) возвращает значение True тогда и только тогда , когда текст появляется в каком-либо документе, подписанном публичным_ключом . Свидетель - это документ, содержащий текст вместе с его подписью.

Проверка приведенных выше утверждений может потребоваться как часть некоторого прикладного контракта. Распространенным способом работы с такими предикатами является написание функции внутри контракта приложения и передача свидетеля в calldata транзакции.

Однако в некоторых случаях лучшим подходом было бы заключение специального контракта с реестром . Контракт реестра — это контракт, который поддерживает набор ранее засвидетельствованных фактов (хранящихся в хранилище Ethereum) и имеет два метода: add() и isValid() . Метод add (факт, свидетель) добавляет факт в набор при условии, что утверждение выполняется. Метод isValid(fact) просто возвращает True , если факт находится в наборе.

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

Обратите внимание: если isValid(fact) возвращает True , это означает, что не только существует свидетель, удовлетворяющий предикату, но также и то, что такой свидетель был представлен ранее в контракте. Таким образом, метод isValid() служит доказательством знаний .

Когда использовать контракты реестра?

Использование контракта реестра приводит к некоторым накладным расходам по сравнению с монолитным решением использования функции внутри контракта приложения:

1. Одна операция хранения для каждого подтвержденного факта, полученная в результате добавления факта в набор ончейн.
2. Передача фактов несколько раз: один раз для контракта реестра и один раз для каждого контракта приложения, использующего его.
3. Взаимодействие между договорами при запросе договора реестра на фактическую достоверность.

Когда общие затраты (вычисления и данные вызовов) на проверку оператора невелики, использование контрактов реестра может добавить существенные накладные расходы на газ, и в таком случае монолитное решение предпочтительнее.

Однако, когда стоимость проверки высока, эти накладные расходы становятся незначительными, и использование предложенного шаблона проектирования дает много преимуществ:

1. Четкое разделение между контрактом приложения и контрактом реестра, включая возможность обновления одного без изменения другого.
2. Разделение стоимости газа на более чем одну транзакцию. Это полезно, когда вы сталкиваетесь с ситуацией, когда стоимость газа, необходимая для всей операции, превышает лимит блокировки.
3. Разделение стоимости газа между разными сторонами. Это полезно, когда одна сторона должна заплатить за проверку утверждения, а другая сторона должна заплатить за договор о применении со ссылкой на подтвержденный факт.
4. Многократное повторное использование факта (т. е. кэширование) разными транзакциями в одном контракте или разными контрактами.
5. Экономия от масштаба: используя краткую систему проверки, такую ​​как STARK, SNARK или BulletProofs, можно проверить набор фактов, используя значительно меньше газа, чем общее количество газа, необходимое для проверки каждого факта в отдельности. Таким образом, разные контракты, основанные на одном и том же заявлении (даже на одних и тех же данных!), могут выиграть от значительной экономии за счет масштаба.

Давайте подробнее остановимся на этом самом последнем преимуществе, которое, по нашему мнению, имеет огромный потенциал.

Пакетная обработка с краткими доказательствами знаний

В приведенных выше примерах стоимость газа для проверки фактов была аддитивной в том смысле, что стоимость газа, необходимая для проверки нескольких фактов, была (приблизительно) равна сумме затрат, необходимых для проверки фактов по отдельности. Однако существуют методы, которые уменьшают количество газа для проверки (или «верификации», на языке систем доказательства) набора фактов. Например, краткие доказательства знаний (такие как STARK) позволяют доказать, что определенное вычисление имеет заданный результат, с сублинейной стоимостью в размере вычисления. В частности, доказательство многих фактов вместе обходится дешевле, чем общая стоимость доказательства каждого факта по отдельности.

Рассмотрим контракт реестра для merkleLeaf(), упомянутый выше. Если мы расширим функцию add() , чтобы получить пакет новых фактов (т. е. список пар (конец, корень) ), мы можем проверить их достоверность, проверив краткое доказательство, подтверждающее весь пакет, вместо проверки аутентификации. путь для каждого факта. Обратите внимание, что пути аутентификации в этом случае вообще не передаются. По мере увеличения количества фактов, добавляемых в одну партию, амортизированная стоимость газа в расчете на один факт снижается (в современных системах кратких доказательств стоимость газа, необходимая для проверки доказательства, за исключением некоторых небольших линейных затрат, необходимых для обработки общедоступных входных данных, увеличивается (многократно увеличивается). ) логарифмически с размером партии).

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

Лиор Голдберг и Михаил Рябзев
StarkWare