Пересылка оригинального заголовка: разбор модели умного контракта Starknet и оригинального AA: технический гений, идущий своим путем

Оригинальные авторы: Шев и Фауст, веб-консультанты: CryptoNerdCn, разработчик ядра Starknet, основатель платформы разработки Cairo WASM Cairo

Аннотация:

Основные технологические особенности Starknet включают язык Cairo, способствующий созданию ZK-доказательств, нативный уровень AA и модель смарт-контракта, в которой бизнес-логика независима от хранения состояния. Cairo - универсальный язык ZK, который можно использовать для реализации смарт-контрактов на Starknet, а также для разработки приложений с традиционными тенденциями. В процессе компиляции используется промежуточный язык Sierra, который позволяет частые итерации Cairo без прямого изменения базового байткода. Более того, стандартная библиотека Cairo включает множество базовых структур данных, необходимых для абстрагирования учетных записей. Смарт-контракты Starknet отделяют бизнес-логику от хранения данных состояния, в отличие от цепочек EVM. Развертывание смарт-контрактов Cairo включает три этапа: компиляция, декларация и развертывание, где бизнес-логика объявляется в классе Contract. Экземпляры контрактов, содержащие данные состояния, могут быть связаны с классом и вызывать содержащийся в нем код.

Вышеупомянутая модель смарт-контракта Starknet способствует повторному использованию кода, повторному использованию состояния контракта, наличию уровней хранения и обнаружению мусорных контрактов. Она также способствует реализации аренды хранилища и параллелизации транзакций. Хотя последние два пока не реализованы, структура смарт-контрактов Cairo создала «необходимые условия» для них. На цепи Starknet есть только учетные записи смарт-контрактов, а не учетные записи EOA. С самого начала она поддерживает абстракцию учетных записей AA на уровне нативных. Ее план AA включает в себя идеи ERC-4337 в определенной степени, позволяя пользователям выбирать высококастомизированные решения обработки транзакций. Для предотвращения потенциальных сценариев атак Starknet принял множество противодействий и сделал важные исследования в экосистеме AA.

text: После выпуска токенов на Starknet STRK постепенно стал незаменимым элементом в глазах наблюдателей за Ethereum. Эта звезда Ethereum Layer 2, известная своим «независимым» и «пренебрегающим пользовательским опытом», незаметно заняла свою собственную территорию в процветающей экосистеме Layer 2, совместимой с EVM. Из-за чрезмерного пренебрежения пользователями и даже открытого создания канала «электронного попрошайки» в Discord, Starknet в свое время подвергся критике со стороны сообщества. На фоне обвинений в «бесчеловечности» его глубокая техническая экспертиза, казалось, мгновенно обесценилась, как будто только UX и создание богатства были всем. Фраза из «Храма Золотого Павильона» — «тот факт, что меня не понимают другие, был моим единственным источником гордости» — это почти автопортрет Старкнета. Тем не менее, если оставить в стороне эти тривиальные вопросы мира, основанные исключительно на техническом вкусе программистов, Starknet и StarkEx, как пионеры ZK Rollup, являются почти сокровищами в глазах каирских энтузиастов. В сознании некоторых разработчиков блокчейн-игр Starknet и Cairo — это просто все в Web3, превосходящее Solidity и Move. Самый большой разрыв между «техническими гиками» и «пользователями» сегодня в значительной степени объясняется непониманием людьми Starknet. Движимый интересом к технологии блокчейн и изучением ценности Starknet, автор этой статьи начинает с модели смарт-контрактов Starknet и нативного AA, чтобы кратко изложить его технические решения и конструкции механизмов, стремясь продемонстрировать технические особенности Starknet большему количеству людей, а также надеясь помочь людям понять этого «непонятого одинокого рейнджера». После краткого введения в язык Cairo в следующем разделе, мы сосредоточимся на обсуждении модели смарт-контрактов Starknet и абстракции нативной учетной записи, объясняя, как Starknet достигает нативного AA. Прочитав эту статью, читатели также поймут, почему мнемонические фразы из разных кошельков нельзя смешивать в Starknet. Но прежде чем вводить нативную абстракцию учетных записей, давайте сначала разберемся с инновационным языком Cairo, созданным Starknet. В процессе разработки Cairo существовали ранние версии под названием Cairo0, за которыми последовала современная версия. Общий синтаксис современной версии Cairo похож на Rust и на самом деле является универсальным языком ZK. Помимо того, что он используется для написания смарт-контрактов в Starknet, он также может быть использован для разработки общих приложений. Например, мы можем разработать систему проверки личности ZK с использованием языка Cairo, и эта программа может работать на нашем собственном сервере, не завися от сети StarkNet. Можно сказать, что любая программа, требующая верифицируемых вычислительных свойств, может быть реализована с помощью языка Cairo. И Cairo в настоящее время может быть языком программирования, наиболее подходящим для создания ZK-доказательств.

С точки зрения процесса компиляции, Каиро использует метод компиляции на основе промежуточного языка, как показано на рисунке ниже. Sierra на изображении - это промежуточное представление (IR) в процессе компиляции на языке Каиро, и Sierra будет скомпилирована в представление бинарного кода более низкого уровня, названное CASM, который запускается непосредственно на устройстве узла Starknet.

Введение Sierra в качестве промежуточного представления упрощает добавление новых функций в язык Cairo. Во многих случаях достаточно только манипулировать промежуточным языком Sierra, не изменяя напрямую базовый код CASM. Это экономит много хлопот, и клиентский узел Starknet не требует частого обновления. Таким образом, частые итерации языка Cairo могут быть достигнуты без изменения базовой логики StarkNet. Стандартная библиотека Cairo также включает множество базовых структур данных, необходимых для абстракции учетных записей. Другие инновации Cairo включают теоретическое решение под названием Cairo Native, которое планирует компилировать Cairo в машинный код низкого уровня, способный адаптироваться к различным аппаратным устройствам. Узлы Starknet не будут зависеть от виртуальной машины CairoVM при выполнении смарт-контрактов. Это может значительно улучшить скорость выполнения кода [он все еще находится на теоретическом уровне и еще не был реализован].

Модель смарт-контракта Starknet: удаление логики кода и хранение состояния

В отличие от совместимых с Ethereum цепочек, Starknet сделал революционные инновации в проектировании своей системы смарт-контрактов, в значительной степени готовясь к нативным AA и грядущим функциям, таким как параллельная обработка транзакций. Здесь важно понимать, что, в отличие от традиционных общедоступных цепочек, таких как Ethereum, развертывание смарт-контрактов на Starknet происходит по-другому. Давайте рассмотрим пример развертывания смарт-контракта Ethereum:

1. Разработчики пишут код смарт-контракта локально и компилируют программу на Solidity в байт-код EVM с помощью редактора. Этот байт-код затем может быть понят и обработан непосредственно EVM.

1. Разработчик инициирует транзакцию для развертывания смарт-контракта, развертывая скомпилированный байт-код EVM на цепочку Ethereum.

Источник: not-satoshi.com

Хотя смарт-контракты Starknet также следуют идее ​​”сначала компилировать, а затем разворачивать”, смарт-контракты разворачиваются на цепи в виде байт-кода CASM, поддерживаемого CairoVM. Однако существуют огромные различия между Starknet и совместимыми с EVM цепями в методе вызова и режиме хранения состояния смарт-контрактов. Фактически, смарт-контракт Ethereum = бизнес-логика + информация о состоянии. Например, контракт USDT не только реализует общие функции, такие как Transfer и Approval, но и хранит статус активов всех держателей USDT. Код и состояние связаны вместе, что вызывает много проблем. Прежде всего, это не способствует обновлению и миграции состояния контрактов DAPP, а также не способствует параллельной обработке транзакций. Это тяжелое техническое бремя.

В ответ на это Starknet улучшил способ хранения состояния. В своем решении по реализации смарт-контрактов логика бизнеса DApps полностью отделена от состояния активов и хранится отдельно. Преимущества такого подхода очевидны: во-первых, это позволяет системе быстро различить, есть ли дублирование или избыточные развертывания кода. Вот как это работает: в Ethereum смарт-контракт включает в себя как бизнес-логику, так и данные состояния. Если у нескольких контрактов одинаковая бизнес-логика, но разные данные состояния, их хеши также будут отличаться, что затрудняет системе определить, существуют ли «мусорные контракты». Однако в решении Starknet код и данные состояния разделены, что упрощает для системы определение того, был ли развёрнут один и тот же код несколько раз на основе хеша части кода. Это помогает предотвратить дублирование развертывания кода и экономит место хранения на узлах Starknet.

В смарт-контрактной системе Starknet развертывание и использование контрактов разделены на три этапа: «компиляция, объявление и развертывание». Если эмитент активов хочет развернуть контракт Cairo, сначала он компилирует написанный код Cairo в формы Sierra и байт-код CASM нижнего уровня на своем локальном устройстве. Затем развертывающий контракт публикует транзакцию «объявление», развертывая байт-код CASM контракта и промежуточный код Sierra на цепочке, названной как Класс Контракта.

(Источник: официальный сайт Starknet)

Позже, если вы захотите использовать функциональные возможности, определенные в контракте актива, вы можете инициировать транзакцию развертывания через интерфейс DApp для развертывания экземпляра Contract, связанного с классом контракта. Этот экземпляр будет хранить состояние актива. Впоследствии пользователи могут вызывать функции в классе Contract для изменения состояния экземпляра Contract. На самом деле, любой, кто знаком с объектно-ориентированным программированием, должен легко понять, что представляют собой Class и Instance в Starknet. Класс контракта, заявленный разработчиками, содержит только бизнес-логику смарт-контракта, включающую функции, которые может вызвать каждый, но он не имеет фактического состояния актива, таким образом, не реализуя напрямую «сущности активов», имея только «душу» без «тела». Однако, когда пользователи развертывают определенные экземпляры контракта, ресурсы «материализуются». Если вам нужно изменить состояние «сущности» актива, например, передать свои токены кому-то другому, вы можете напрямую вызвать функции, написанные в классе контракта. Описанный выше процесс чем-то похож на «инстанцирование» в традиционных объектно-ориентированных языках программирования (хотя и не совсем идентичен).

После того как смарт-контракты разделены на классы и экземпляры, бизнес-логика и данные состояния становятся разъединенными, что приносит следующие особенности в Starknet:

1. Пригодный для реализации уровней хранения и "системы аренды хранения"

Так называемое слоение хранения означает, что разработчики могут размещать данные в настраиваемых местах в соответствии со своими потребностями, например, под цепочкой Starknet. StarkNet готов к совместимости с DA-слоями, такими как Celestia, и разработчики DAPP могут хранить данные в этих сторонних DA-слоях. Например, игра может хранить свои наиболее важные данные о активах на главной сети Starknet и хранить другие данные во внешних DA-слоях, таких как Celestia. Это решение по настройке DA-слоя в соответствии с требованиями безопасности было названо «Volition» Starknet.

Так называемая система аренды хранения означает, что каждый должен продолжать платить за занимаемое им место хранения. На сколько места на цепи вы занимаете, теоретически вы должны продолжать платить за аренду.

В модели смарт-контракта Ethereum владение контрактом неясно, и трудно определить, должен ли развертывающий или держатель активов платить «арендную плату» за контракт ERC-20. Функция аренды хранилища не была запущена долгое время, и развертывающему начисляется плата только при развертывании контракта. Эта модель платы за хранение является неразумной.

Под моделями смарт-контрактов Starknet, Sui, CKB и Solana собственность смарт-контрактов более четко разделена, что делает сбор средств для хранения более простым [В настоящее время Starknet не запускает систему аренды хранения напрямую, но она будет реализована в будущем]

1. Достигните истинную повторное использование кода и сократите развертывание мусорных контрактов

Мы можем объявить общий токен-контракт для хранения на цепи в виде класса, после чего каждый может вызывать функции в этом классе для развертывания своих экземпляров токенов. Более того, контракт также может напрямую вызывать код в классе, что достигает эффекта, аналогичного функции библиотеки в Solidity. В то же время модель смарт-контрактов Starknet помогает идентифицировать «мусорные контракты». Объяснено ранее. Поддерживая повторное использование кода и обнаружение мусорных контрактов, Starknet может значительно сократить объем данных, загружаемых на цепь, и снизить давление на хранение на узлах насколько это возможно.

1. Повторное использование реального состояния контракта

Обновления контрактов на блокчейне в основном включают изменения бизнес-логики. В сценарии Starknet бизнес-логика смарт-контрактов является неотделимой от статуса активов. Если экземпляр контракта изменяет ассоциированный класс типа контракта, обновление бизнес-логики может быть завершено. Нет необходимости мигрировать статус активов в новое место. Этот вид обновления контракта более тщательный и естественный, чем у Ethereum.

Для изменения бизнес-логики контракта Ethereum часто необходимо «зафрахтовать» бизнес-логику в агентский контракт и изменить бизнес-логику основного контракта, изменив зависимый агентский контракт. Однако этот метод недостаточно лаконичен и не является «родным».

Источник: wtf Academy

В некоторых сценариях, если старый контракт Ethereum полностью заброшен, статус актива внутри не может быть напрямую перенесен на новое место, что очень проблематично; контракт Cairo не требует миграции статуса и может напрямую «переиспользовать» старый статус.

1. Способствует параллельной обработке транзакций

Для максимизации параллелизма различных торговых инструкций необходимым шагом является хранение статуса активов разных лиц в отдельных местах, как это можно видеть в Bitcoin, CKB и Sui. Предпосылкой для достижения указанной цели является разделение бизнес-логики смарт-контрактов от данных о статусе активов. Хотя Starknet еще не провела глубокой технической реализации параллельных транзакций, в будущем она будет рассматривать параллельные транзакции как важную цель.

Развертывание собственного AA и контракта учетной записи Starknet

Фактически, концепция абстракции учетной записи (AA) и EOA (внешние управляемые учетные записи) была изобретена сообществом Ethereum как уникальная концепция. На многих новых публичных цепочках нет различия между учетными записями EOA и учетными записями смарт-контрактов, избегая проблем с системой учетных записей в стиле Ethereum с самого начала. Например, в настройке Ethereum контроллер учетной записи EOA должен иметь ETH на цепочке, прежде чем он сможет инициировать транзакцию. Нет возможности непосредственно выбирать различные методы аутентификации, и добавление некоторой настраиваемой логики оплаты представляет собой крайне трудоемкий процесс. Некоторые даже считают, что дизайн учетной записи Ethereum просто античеловечен.

Если мы посмотрим на флагманские продукты, такие как Starknet или zkSyncEra «Native AA» цепочка, очевидно, что можно наблюдать различия: во-первых, у Starknet и zkSyncEra есть унифицированные типы учетных записей. На цепочке есть только умные контрактные учетные записи. С самого начала нет такого понятия, как учетная запись EOA. (zkSync Era будет размещать набор контрактных кодов по умолчанию на только что созданную учетную запись пользователя, чтобы симулировать характеристики учетной записи Ethereum EOA, чтобы она была совместима с Metamask).

Однако Starknet не рассматривает прямую совместимость с периферийными устройствами Ethereum, такими как Metamask. Когда пользователи используют кошелек Starknet впервые, автоматически разворачивается выделенный учетный контракт. Другими словами, развертывается упомянутый ранее экземпляр контракта, и этот экземпляр связан с классом контракта, развёрнутым заранее проектом кошелька. Пользователи могут напрямую вызывать некоторые функциональные возможности, написанные в классе. Теперь давайте поговорим об интересной теме: при запросе воздушных капель STRK многие люди обнаружили, что кошельки Argent и Braavos не совместимы друг с другом. Импорт мнемоники из Argent в Braavos не позволял экспортировать соответствующий счет, в основном из-за разных алгоритмов генерации счетов, используемых Argent и Braavos, что приводит к генерации разных адресов счетов из той же мнемоники. Конкретно в Starknet новый развёрнутый адрес контракта может быть получен через детерминированный алгоритм, как показано ниже:

Упомянутая выше функция ‘pedersen()’ представляет собой алгоритм хэширования, который легко использовать в системах ZK. Процесс генерации учетной записи включает предоставление нескольких специальных параметров функции pedersen для генерации соответствующего хэша, который и является сгенерированным адресом учетной записи. На изображении выше показаны параметры, используемые Starknet для генерации “нового адреса контракта”. ‘deployer_address’ представляет собой адрес “развертывателя контракта”. Этот параметр может быть пустым, что означает, что даже если у вас заранее нет учетной записи контракта Starknet, вы все равно можете развернуть новый контракт. ‘salt’ - это соль, используемое для вычисления адреса контракта, которая по сути является случайным числом, введенным для избегания дублирования адресов контрактов. ‘class_hash’ соответствует хэш-значению класса, упомянутого ранее, с которым связан экземпляр контракта. ‘constructor_calldata_hash’ представляет собой хэш параметров инициализации контракта.

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

1. Пользователи сначала определяют экземпляр контракта, который они хотят развернуть, и с каким классом контракта его связать, используя хэш класса в качестве одного из параметров инициализации, и вычисляют соль для определения сгенерированного адреса контракта.
2. После того как пользователи узнают, куда будет развертываться контракт, они сначала переводят определенное количество ETH на этот адрес в качестве платы за развертывание контракта. Как правило, этот ETH должен быть переведен с L1 на сеть Starknet через мост между цепями.
3. Пользователи инициируют запрос на транзакцию для развертывания контракта.

Фактически все учетные записи Starknet развертываются через вышеуказанный процесс, но большинство кошельков скрывают детали, и пользователи не воспринимают процесс как развертывание их контрактного счета сразу после перевода ETH.

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

1. Приватный ключ, полученный из открытого ключа, используемый кошельком, такой же, как алгоритм подписи;
2. Процесс вычисления соли кошелька такой же;
3. Классы смарт-контрактов кошелька в целом не отличаются по деталям реализации; \

В случае, упомянутом ранее, как Аргент и Браавос использовали алгоритм подписи ECDSA, но методы расчета соли были разными между ними, что привело к несогласованным адресам учетных записей, сгенерированным из одного и того же мнемонического слова.

Теперь давайте вернемся к теме абстракции учетной записи. Starknet и zkSync Era переместили ряд процессов, связанных с обработкой транзакций, таких как проверка подлинности личности (проверка цифровых подписей) и оплата комиссии за газ, за пределы «уровня цепи». Пользователи могут настраивать детали реализации вышеуказанной логики в своих учетных записях. Например, вы можете развернуть отдельную функцию проверки цифровой подписи в вашей учетной записи умного контракта Starknet. Когда узел Starknet получает транзакцию, инициированную вами, он вызовет ряд настраиваемой вами логики обработки транзакций на цепи.

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

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

По словам представителей zkSyncEra и Starknet, такой модульный подход к функциональности учетных записей вдохновлен EIP-4337. Однако то, что отличает их, заключается в том, что zkSync и Starknet объединили типы учетных записей с самого начала, унифицировали типы транзакций и использовали единую точку входа для приема и обработки всех транзакций. В отличие от этого, Ethereum, из-за исторических обременений и желания фонда избегать агрессивных стратегий итерации, таких как жесткие вилки, насколько это возможно, поддерживал EIP-4337, используя другой способ решения проблемы. Однако результатом является то, что у учетных записей EOA и решений EIP-4337 есть независимые рабочие процессы обработки транзакций, которые кажутся неуклюжими и громоздкими, в отличие от гибкости родных AA.

Источник: ArgentWallet

Однако встроенная абстракция учетной записи в Starknet пока не достигла полной зрелости. С практической точки зрения, хотя учетные записи AA Starknet реализовали собственные алгоритмы проверки подписи, в настоящее время они поддерживают только оплату комиссии за газ в ETH и STRK, и еще не поддерживают оплату газа от третьих лиц. Поэтому прогресс Starknet в отношении встроенных AA можно охарактеризовать как "теоретическая основа в значительной степени зрела, в то время как практическая реализация все еще находится в процессе". Поскольку в Starknet внутри есть только умные контрактные учетные записи, весь процесс его транзакций учитывает влияние контрактов умных аккаунтов. Во-первых, после того как транзакция получена узлом Starknet в его пуле памяти (Mempool), она проходит проверку, включающую:

1. Проверка правильности цифровой подписи транзакции, на этом этапе вызывается пользовательская проверочная функция учетной записи подписанта;
2. Проверка, может ли баланс счета инициатора покрыть комиссию за газ. \

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

1. Существует верхний предел количества транзакций, которые один пользователь может инициировать в течение определенного времени;
2. Функция проверки собственной подписи в контракте учетной записи Starknet имеет ограничения сложности, и слишком сложные функции проверки подписи не будут выполнены. Starknet ограничивает лимит расхода газа функции проверки подписи. Если количество газа, потребляемого функцией проверки подписи, слишком высоко, транзакция будет непосредственно отклонена. В то же время функции проверки подписи в контракте учетной записи не разрешается вызывать другие контракты.

Схема потока транзакций Starknet выглядит следующим образом:

Стоит отметить, что для дальнейшего ускорения процесса проверки транзакций клиент узла Starknet напрямую внедрил алгоритмы проверки подписи кошельков Braavos и Argent. Когда узел обнаруживает транзакции, сгенерированные этими двумя основными кошельками Starknet, он вызывает встроенные алгоритмы подписи Braavos/Argent в клиенте. Благодаря такому подходу, похожему на кэширование, Starknet может сократить время проверки транзакций. После того, как данные транзакции будут проверены секвенсором (шаги проверки секвенсора гораздо более тщательны, чем в пуле памяти), секвенсор упакует и отправит транзакции из пула памяти в генератор доказательств ZK. За транзакции, входящие в этот этап, будет взиматься плата за газ, даже если они не увенчаются успехом. Однако, если читатели знакомы с историей Starknet, они заметят, что более ранние версии Starknet не взимали комиссию за неудачные транзакции. Самый распространенный сценарий сбоя транзакции — когда у пользователя есть только 1 ETH, но он пытается перевести 10 ETH извне, что явно указывает на логическую ошибку и неизбежно потерпит неудачу, но никто не знает результат до выполнения. Однако в прошлом StarkNet не взимал комиссию за такие неудачные транзакции. Эти бесплатные ошибочные транзакции расходуют вычислительные ресурсы узла Starknet и могут привести к сценариям DDoS-атак. На первый взгляд, взимание комиссии за ошибочные транзакции кажется простым, но на самом деле это довольно сложно. Starknet представил новую версию языка Cairo1 в основном для решения проблемы платы за газ за неудачные транзакции. Как мы все знаем, доказательство ZK является доказательством валидности, а результат неудачной транзакции недействителен и не может оставить выходной результат в цепочке. Попытка использовать доказательство валидности для доказательства того, что выполнение определенной инструкции является недействительным и не может привести к выходным результатам, звучит странно и на самом деле неработоспособно. Таким образом, в прошлом Starknet исключал неудачные транзакции, которые не могли выдавать выходные результаты при генерации доказательств. Позже команда Starknet приняла более умное решение и создала новый язык контрактов Cairo1, который гарантирует, что «все транзакционные инструкции могут выдавать выходные результаты и быть в цепочке». На первый взгляд, тот факт, что все транзакции могут давать выходные результаты, означает, что логические ошибки никогда не возникают. Однако в большинстве случаев транзакции завершаются сбоем из-за ошибок, которые прерывают выполнение инструкций. Гарантировать, что транзакции никогда не прерываются и успешно выдают выходные результаты, сложно, но на самом деле есть простое альтернативное решение, которое заключается в том, чтобы позволить транзакциям выдавать выходные результаты при обнаружении логических ошибок, которые приводят к прерываниям, хотя и возвращая значение False, указывающее на то, что выполнение транзакции не было гладким. Важно отметить, что возврат значения False также возвращает выходной результат, а это означает, что в Cairo1, независимо от того, сталкивается ли инструкция с логической ошибкой или временно прерывается, она может выдавать выходные результаты и быть в цепочке. Этот результат вывода может быть правильным или ложным сообщением об ошибке. Например, рассмотрим следующий фрагмент кода:

На данном этапе _balances::read(from) - сумма может вызвать ошибку переполнения, что приведет к прерыванию соответствующей транзакционной инструкции и остановке без сохранения результата транзакции на цепи. Однако, если переписать в следующей форме, он все равно возвращает результат выполнения при сбое транзакции, оставляя его на цепи. Чисто с эстетической точки зрения кажется, что все транзакции могут плавно оставлять выходные результаты на цепи, что делает равномерный сбор сборов особенно разумным.

Обзор контракта StarknetAA

Учитывая, что некоторые читатели этой статьи могут иметь программистский опыт, вот краткое демонстрационное видео интерфейса абстрактного контракта учетной записи в Starknet:

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

1. Авторизация токенов в смарт-контракт DeFi в первой транзакции.
2. Активация логики контракта DeFi во второй транзакции.
3. Отзыв разрешения на смарт-контракт DeFi в третьей транзакции.

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

Сводка

Основные технологические особенности Starknet включают язык Cairo, оптимизированный для генерации ZK-доказательств, абстракцию уровня нативного аккаунта и модель смарт-контракта, разделяющую бизнес-логику и хранение состояния.

Cairo - это универсальный язык ZK, который можно использовать для смарт-контрактов на Starknet, а также для разработки более традиционных приложений. Процесс компиляции включает Sierra в качестве промежуточного языка, позволяя Cairo часто итерироваться без изменения базового байткода, только распространяя изменения на промежуточный язык. Стандартная библиотека Cairo также включает множество базовых структур данных, необходимых для абстрагирования учетной записи.

Смарт-контракты Starknet отделяют бизнес-логику от хранения данных состояния, в отличие от EVM-цепочек. Развертывание контракта в Каире включает три этапа: компиляцию, объявление и развертывание. Бизнес-логика объявляется в классах контрактов, а экземпляры контрактов, содержащие данные состояния, могут быть ассоциированы с классом и вызывать содержащийся в нем код.

Модель смарт-контракта Starknet облегчает повторное использование кода, повторное использование состояния контракта, наложение слоев хранения и обнаружение мусорных контрактов. Он также облегчает реализацию аренды хранения и параллелизации транзакций, хотя эти функции еще не были полностью реализованы. Архитектура смарт-контрактов Cairo создает необходимые условия для этих функций.

Starknet имеет только учетные записи смарт-контрактов, без учетных записей EOA, и поддерживает абстракцию учетной записи AA на уровне нативного уровня с самого начала. Его решение AA частично впитывает идеи ERC-4337, позволяя пользователям выбирать высоко настраиваемые решения обработки транзакций. Для предотвращения потенциальных сценариев атак Starknet реализовал различные противодействия, делая важные исследования для экосистемы AA.

Отказ от ответственности:

1. Эта статья перепечатана из [Geek Web3]. *Перенаправить оригинальный заголовок‘解读Starknet智能合约模型与原生AA：特立独行的技术巨匠’.Все авторские права принадлежат оригинальному автору [Shew & Faust]. Если есть возражения против этого перепечатывания, пожалуйста, свяжитесь сGate Learnкомандой, и они незамедлительно справятся с этим.
2. Отказ от ответственности: Взгляды и мнения, высказанные в этой статье, являются исключительно точкой зрения автора и не являются инвестиционными рекомендациями.
3. Перевод статьи на другие языки выполняется командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.