TL;DR

• Плата теперь обязательна в тестовой сети, скоро в основной сети
• Контрактная фабрика теперь возможна!
• StarkNet вводит контрактные классы
• Вызов делегата заменен вызовом библиотеки

Вступление

Мы рады представить StarkNet Alpha 0.9.0! Это важная версия, в которой StarkNet делает значительные шаги на пути к зрелости, внося существенные дополнения как в функциональность, так и в структуру протокола.

Сборы являются обязательными (в настоящее время только в тестовой сети, пока версия 0.9.0 не будет запущена в основной сети) — любой процветающий L2 должен иметь свою собственную независимую систему сборов. После введения сборов в качестве дополнительной функции в версии 0.8.0 мы теперь уверены, что включим их в качестве основного компонента протокола и сделаем их обязательными. Подробнее ниже.

Еще одним значительным изменением на уровне протокола является введение классов контрактов и разделения класса/экземпляра. Это позволяет более просто использовать функциональность `delegate_call` и развертывания из существующих контрактов, позволяя использовать фабричный шаблон в StarkNet.

Классы контрактов

Черпая вдохновение из объектно-ориентированного программирования, мы различаем код контракта и его реализацию. Мы делаем это, разделяя контракты на классы и экземпляры.

Класс контракта — это определение контракта: его байт-код Cairo, информация о подсказках, имена точек входа и все необходимое для однозначного определения его семантики. Каждый класс идентифицируется своим хешем класса (аналогично имени класса в языках ООП).

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

«Объявить» транзакцию

Мы представляем в StarkNet новый тип транзакций: транзакцию «объявления» , которая позволяет объявлять класс контракта . В отличие от транзакции `deploy`, эта транзакция не развертывает экземпляр этого класса. Состояние StarkNet будет включать в себя список объявленных классов. Новые классы могут быть добавлены через новую транзакцию `declare`.

Фабрики системных вызовов и контрактов «Развертывание».

Как только класс объявлен, то есть принята соответствующая транзакция `declare`, мы можем развернуть новые экземпляры этого класса. С этой целью мы используем новый системный вызов `deploy`, который принимает следующие аргументы:

• Хэш класса
• Соль
• Аргументы конструктора

Затем системный вызов «развертывание» развернет новый экземпляр этого класса контракта, адрес которого будет определяться тремя указанными выше параметрами и адресом развертывается (контракт, вызвавший системный вызов).

Включение развертываний в транзакцию вызова позволяет нам оценивать и взимать плату за развертывание без необходимости по-разному относиться к развертыванию и вызову. Дополнительные сведения о сборах за развертывание см . в документации .

Эта функция вводит фабрики контрактов в StarkNet, поскольку любой контракт может вызывать системный вызов «развернуть», создавая новые контракты.

Переход от «вызова делегата» к «вызову библиотеки»

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

Старый системный вызов `delegate_call` теперь устарел (старые контракты, которые уже развернуты, будут продолжать функционировать, но контракты, использующие `delegate_call`, больше не будут компилироваться ) и заменяется новым системным вызовом library_call, который получает хэш класса (из ранее объявленный класс) вместо адреса экземпляра контракта. Обратите внимание, что в библиотечном вызове участвует только один фактический контракт, поэтому мы избегаем двусмысленности между вызывающим контрактом и контрактом реализации.

Новые конечные точки API

Мы добавили в API две новые конечные точки, позволяющие извлекать данные, относящиеся к классам:

• `get_class_by_hash`: возвращает определение класса с учетом хэша класса.
• `get_class_hash_at`: возвращает хэш класса развернутого контракта с учетом адреса контракта.

Обратите внимание, что для получения класса развернутого контракта напрямую, а не через два описанных выше метода, вы можете использовать старую конечную точку `get_full_contract`, которая будет переименована в будущих версиях. Все упомянутые выше конечные точки также можно использовать из StarkNet CLI .

Сборы

Мы продолжаем вводить сборы в StarkNet, делая их обязательными (сначала в Testnet, а затем и в Mainnet) для транзакций ` invoke` . На этом этапе транзакция «декларировать» не требует комиссий. Точно так же транзакции «развертывания» также не требуют платы, однако обратите внимание, что этот тип транзакции, скорее всего, будет объявлен устаревшим в будущих версиях.

В этой области остается несколько открытых вопросов, наиболее важными из которых являются способы взимания платы за объявления контрактов и развертывание учетных записей StarkNet. Мы решим эти проблемы в будущих версиях.

Что дальше?

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

Следующая основная версия StarkNet будет сосредоточена на структуре учетных записей StarkNet, аналогично ERC-4337 . Таким образом, мы доработали поведение учетных записей StarkNet, сделав еще один важный шаг к массовому внедрению!