Перевод и корректура: "Китайское сообщество StarkNet"
Краткое содержание
Встроенные функции оптимизируют процесс проверки. Однако каждое доказательство вычисляется из макета. Для некоторых пробных работ преимущества встроенных функций будут значительно снижены, если компоновка неэффективна. В настоящее время существует небольшой статический список макетов, и каждое доказательство вычисляется на основе наиболее подходящего макета из этого списка. Этот способ размещения статических списков имеет два недостатка. Во-первых, существует ограниченное разнообразие макетов. Это неэффективно для большинства доказательств и создает сложные механизмы оплаты, которые налагают ненужные расходы на пользователей. Во-вторых, вести список вручную сложно. Когда количество встроенных функций становится слишком большим, ручное обслуживание становится трудным и может фактически затруднить процесс проверки эффективности встроенных функций, поддерживающих большое количество нюансов. Чтобы решить эти проблемы, команда StarkWare разрабатывает систему динамической компоновки, в которой макеты изготавливаются индивидуально для каждого доказательства работы.
Стек Cairo облегчает доказуемые вычисления общего назначения, компилируя код Cairo в инструкции для дружественных к STARK архитектур ЦП: виртуальную машину Cairo (далее именуемую CVM). Многие преимущества ЦП общего назначения имеют свою собственную цену, а CVM не оптимизирован для некоторых распространенных операций. Хэш-функции Keccak, Pedersen, Poseidon являются общими для таких операций, как операции с эллиптическими кривыми, проверка диапазона (т. е. проверка того, находится ли конкретное число в определенном диапазоне значений) и другие.
Чтобы решить проблему относительной неэффективности CVM, в стеке Cairo введена концепция встроенных модулей для критически важных операций: подключаемых модулей, которые оптимизируют такие операции, чтобы доказать их сложность. Встроенные функции можно сравнить с ASIC: ASIC — это интегральные схемы для конкретных приложений, а встроенные функции — это алгебраические ограничения для конкретных приложений (AIR). Если вы не знаете или не помните, что такое AIR, это кратко описано далее в этой статье; прочтите эту статью для получения более подробной информации.
Короче говоря, сложность доказательства связана (примерно линейно) с ресурсами, называемыми единицами трассировки, а встроенные функции упрощают доказательства конкретных операций, используя гораздо меньше единиц трассировки, чем Cairo VM.
Теперь, когда преимущества встроенных функций объяснены, становится ясно, почему встроенные функции были разработаны для многих распространенных операций. Это легче сказать, чем сделать. Текущий процесс внедрения новых встроенных модулей в Starknet состоит из следующих шагов:
Написание AIR
Интегрируйтесь с прувером, создав новый макет (описанный ниже).
Интегрироваться в Starknet, т. е. модифицировать его кодовую базу и инструменты разработчика для использования новых встроенных функций.
Помимо проблем написания AIR, есть много возможностей для улучшения на оставшихся двух этапах. В этой расширенной статье будут более подробно описаны встроенные функции AIR для конкретных приложений, указанные выше вопросы и планы на будущее.
Встроенные функции: AIR для конкретных приложений
AIR — это аббревиатура от алгебраического промежуточного представления. В этой и других статьях StarkWare AIR — это полиномиальная система для представления виртуальных машин. Например, Cairo берет свое название от CPU AIR: полиномиальная система, представляющая определенную архитектуру ЦП. Решения этой полиномиальной системы представляют собой эффективные переходы состояний, называемые эффективными алгебраическими траекториями выполнения (AET).
STARK доказывает правильность работы виртуальной машины, доказывая, что траектория выполнения, соответствующая данному AIR, действительна. Грубо говоря, траектория выполнения — это таблица чисел, и протокол STARK доказывает, что эти числа вместе решают полиномиальную систему.
Одну и ту же операцию можно рассчитать многими способами, некоторые из которых более эффективны. В этой статье сложность доказательства в основном зависит от размера дорожки, т. е. от количества ячеек дорожки в таблице. Поскольку трассировки создаются для AIR, AIR разработан для приложений, чтобы значительно сократить трассировки выполнения для определенных вычислений. Встроенные специализированные функции AIR оптимизированы для приложения.
В таблице ниже показаны улучшения эффективности для определенных встроенных функций (все в рабочей среде).
Схема траектории: настоящее и будущее
Как упоминалось ранее, AET — это, грубо говоря, таблица чисел, представляющая порядок шагов в закодированной виртуальной машине (то есть выполнение программы). Чтобы вычислить доказательство, доказывающая сторона запускает протокол STARK на дорожке выполнения связанного AIR.
Выше мы представили встроенные функции AIR для конкретных приложений, предназначенные для минимизации сложности доказательств за счет уменьшения количества единиц трассировки, необходимых для кодирования вычислений. Однако, если встроенные функции будут случайным образом интегрированы в Starknet, многие единицы траектории могут быть потрачены впустую, а ожидаемые выгоды будут уменьшены. Объясним подробно ниже.
Короче говоря, компоновка дорожек — это назначение ячеек дорожек различным «компонентам». В этой статье такими компонентами являются CVM и встроенные функции. В частности, макет определяет относительное количество ячеек дорожки, которое получает каждый компонент. (Конструкции макета всегда используются для упрощения проверки. Чтобы узнать больше, прочитайте раздел «Простота» этого поста).
Ключевым моментом является то, что сложность доказательства зависит от общего количества ячеек дорожки, выделенных макетом, и выделение ячеек дорожки может быть больше, чем на самом деле необходимо. Например, чтобы продемонстрировать пошаговое упорядочение CVM, макет, который назначает только ячейки трассировки компонентам CVM, примерно в два раза эффективнее макета, который назначает половину ячеек трассировки встроенным функциям Poseidon. В заключение, подходящая схема может значительно уменьшить сложность доказательства конкретного вычисления.
В настоящее время существует поддерживаемый вручную список макетов, который со временем увеличивается по двум основным причинам:
Встроенные функции можно использовать только для компоновки закрепленного за ними трекового блока. Поэтому для добавления встроенных требуется как минимум новый макет.
Макет, адаптированный для выполнения кода Cairo, оптимизирует распределение ячеек. Поэтому оптимизация вариантов использования в ячейках часто требует новых макетов.
Код для прувера и валидатора (валидаторов Solidity и Cairo) настраивается согласно списку макетов.
По мере добавления встроенных модулей Keccak и Poseidon становилось все труднее поддерживать списки макетов достаточно маленькими, чтобы вместить множество встроенных модулей и обеспечить эффективное выполнение большинства блоков Starknet. Кроме того, ожидается, что эффективность значительно снизится по мере введения дополнительных встроенных функций, поскольку макет должен учитывать множество возможных комбинаций и соотношений между встроенными функциями.
В настоящее время команда StarkWare работает над улучшением системы, отказываясь от готовых списков макетов в пользу «динамических макетов», которые мгновенно настраиваются для каждого выполнения кода Cairo. Динамическая компоновка всегда будет оптимально распределять ресурсы для текущей проверки. С инженерной точки зрения поддержка динамической типизации потребует значительных изменений в кодовой базе. Тем не менее, команда StarkWare надеется упростить пробный слой Starknet, воспользовавшись преимуществами динамической компоновки, улучшенного использования блоков отслеживания и лучшего использования пруверов.
С динамическими макетами исчезает проблема ручного обслуживания многих встроенных модулей, что упрощает процесс интеграции большего количества новых встроенных модулей в Starknet.
Динамический макет и сборы
Одной из целей комиссий за транзакции является взимание с пользователей предельной стоимости протокола, понесенной транзакциями. Поскольку единицей комиссии за транзакцию является валюта, механизм комиссии включает преобразование ресурсов (например, шагов виртуальной машины, встроенных функций, данных вызовов, газа Ethereum) в токены (например, STRK, ETH).
В настоящее время, поскольку пруверы взимают плату на основе общего количества трасс, а не коэффициентов использования, трата ресурсов ложится на плечи пользователей. Динамическая компоновка улучшит использование единиц отслеживания, тем самым уменьшив взимание «ненужных» транзакционных комиссий (включая потребление ресурсов, не вызванное непосредственно транзакциями пользователей).
Интеграция встроенных функций Starknet
На данный момент интеграция встроенных функций не заканчивается последним шагом, который заключается в изменении базы кода Starknet для реализации практического использования. Степень изменения кода связана с приложением макета, и необходимо изменить код, чтобы гарантировать, что операционная система Starknet вызывает встроенные функции, когда это возможно. Например, операционная система Starknet вызывает хеш-функцию Poseidon во время выполнения кода Cairo и одновременно вызывает встроенную функцию Poseidon.
Как и в случае с макетами, встроенные функции Starknet теперь можно поддерживать вручную. Однако, в отличие от случая макета, эта ручная поддержка не является препятствием для интеграции, даже несмотря на то, что встроенных функций много. Другими словами, поддержка встроенных модулей Starknet не является препятствием для интеграции, динамическая компоновка действительно проложит путь для создания и интеграции дополнительных встроенных модулей.
Подведем итог
В этой статье мы объясним, что такое встроенные функции, их преимущества, связанные с ними проблемы и планы StarkWare. В настоящее время основное внимание уделяется динамической компоновке, которая не только повысит эффективность процесса проверки, но и облегчит интеграцию новых встроенных модулей.
Посмотреть Оригинал
Содержание носит исключительно справочный характер и не является предложением или офертой. Консультации по инвестициям, налогообложению или юридическим вопросам не предоставляются. Более подробную информацию о рисках см. в разделе «Дисклеймер».
Преимущества и проблемы встроенных функций Starknet
Оригинал: Встроенные модули и динамические макеты
Перевод и корректура: "Китайское сообщество StarkNet"
Краткое содержание
Встроенные функции оптимизируют процесс проверки. Однако каждое доказательство вычисляется из макета. Для некоторых пробных работ преимущества встроенных функций будут значительно снижены, если компоновка неэффективна. В настоящее время существует небольшой статический список макетов, и каждое доказательство вычисляется на основе наиболее подходящего макета из этого списка. Этот способ размещения статических списков имеет два недостатка. Во-первых, существует ограниченное разнообразие макетов. Это неэффективно для большинства доказательств и создает сложные механизмы оплаты, которые налагают ненужные расходы на пользователей. Во-вторых, вести список вручную сложно. Когда количество встроенных функций становится слишком большим, ручное обслуживание становится трудным и может фактически затруднить процесс проверки эффективности встроенных функций, поддерживающих большое количество нюансов. Чтобы решить эти проблемы, команда StarkWare разрабатывает систему динамической компоновки, в которой макеты изготавливаются индивидуально для каждого доказательства работы.
Стек Cairo облегчает доказуемые вычисления общего назначения, компилируя код Cairo в инструкции для дружественных к STARK архитектур ЦП: виртуальную машину Cairo (далее именуемую CVM). Многие преимущества ЦП общего назначения имеют свою собственную цену, а CVM не оптимизирован для некоторых распространенных операций. Хэш-функции Keccak, Pedersen, Poseidon являются общими для таких операций, как операции с эллиптическими кривыми, проверка диапазона (т. е. проверка того, находится ли конкретное число в определенном диапазоне значений) и другие.
Чтобы решить проблему относительной неэффективности CVM, в стеке Cairo введена концепция встроенных модулей для критически важных операций: подключаемых модулей, которые оптимизируют такие операции, чтобы доказать их сложность. Встроенные функции можно сравнить с ASIC: ASIC — это интегральные схемы для конкретных приложений, а встроенные функции — это алгебраические ограничения для конкретных приложений (AIR). Если вы не знаете или не помните, что такое AIR, это кратко описано далее в этой статье; прочтите эту статью для получения более подробной информации.
Короче говоря, сложность доказательства связана (примерно линейно) с ресурсами, называемыми единицами трассировки, а встроенные функции упрощают доказательства конкретных операций, используя гораздо меньше единиц трассировки, чем Cairo VM.
Теперь, когда преимущества встроенных функций объяснены, становится ясно, почему встроенные функции были разработаны для многих распространенных операций. Это легче сказать, чем сделать. Текущий процесс внедрения новых встроенных модулей в Starknet состоит из следующих шагов:
Написание AIR
Интегрируйтесь с прувером, создав новый макет (описанный ниже).
Интегрироваться в Starknet, т. е. модифицировать его кодовую базу и инструменты разработчика для использования новых встроенных функций.
Помимо проблем написания AIR, есть много возможностей для улучшения на оставшихся двух этапах. В этой расширенной статье будут более подробно описаны встроенные функции AIR для конкретных приложений, указанные выше вопросы и планы на будущее.
Встроенные функции: AIR для конкретных приложений
AIR — это аббревиатура от алгебраического промежуточного представления. В этой и других статьях StarkWare AIR — это полиномиальная система для представления виртуальных машин. Например, Cairo берет свое название от CPU AIR: полиномиальная система, представляющая определенную архитектуру ЦП. Решения этой полиномиальной системы представляют собой эффективные переходы состояний, называемые эффективными алгебраическими траекториями выполнения (AET).
STARK доказывает правильность работы виртуальной машины, доказывая, что траектория выполнения, соответствующая данному AIR, действительна. Грубо говоря, траектория выполнения — это таблица чисел, и протокол STARK доказывает, что эти числа вместе решают полиномиальную систему.
Одну и ту же операцию можно рассчитать многими способами, некоторые из которых более эффективны. В этой статье сложность доказательства в основном зависит от размера дорожки, т. е. от количества ячеек дорожки в таблице. Поскольку трассировки создаются для AIR, AIR разработан для приложений, чтобы значительно сократить трассировки выполнения для определенных вычислений. Встроенные специализированные функции AIR оптимизированы для приложения.
В таблице ниже показаны улучшения эффективности для определенных встроенных функций (все в рабочей среде).
Схема траектории: настоящее и будущее
Как упоминалось ранее, AET — это, грубо говоря, таблица чисел, представляющая порядок шагов в закодированной виртуальной машине (то есть выполнение программы). Чтобы вычислить доказательство, доказывающая сторона запускает протокол STARK на дорожке выполнения связанного AIR.
Выше мы представили встроенные функции AIR для конкретных приложений, предназначенные для минимизации сложности доказательств за счет уменьшения количества единиц трассировки, необходимых для кодирования вычислений. Однако, если встроенные функции будут случайным образом интегрированы в Starknet, многие единицы траектории могут быть потрачены впустую, а ожидаемые выгоды будут уменьшены. Объясним подробно ниже.
Короче говоря, компоновка дорожек — это назначение ячеек дорожек различным «компонентам». В этой статье такими компонентами являются CVM и встроенные функции. В частности, макет определяет относительное количество ячеек дорожки, которое получает каждый компонент. (Конструкции макета всегда используются для упрощения проверки. Чтобы узнать больше, прочитайте раздел «Простота» этого поста).
Ключевым моментом является то, что сложность доказательства зависит от общего количества ячеек дорожки, выделенных макетом, и выделение ячеек дорожки может быть больше, чем на самом деле необходимо. Например, чтобы продемонстрировать пошаговое упорядочение CVM, макет, который назначает только ячейки трассировки компонентам CVM, примерно в два раза эффективнее макета, который назначает половину ячеек трассировки встроенным функциям Poseidon. В заключение, подходящая схема может значительно уменьшить сложность доказательства конкретного вычисления.
В настоящее время существует поддерживаемый вручную список макетов, который со временем увеличивается по двум основным причинам:
Встроенные функции можно использовать только для компоновки закрепленного за ними трекового блока. Поэтому для добавления встроенных требуется как минимум новый макет.
Макет, адаптированный для выполнения кода Cairo, оптимизирует распределение ячеек. Поэтому оптимизация вариантов использования в ячейках часто требует новых макетов.
Код для прувера и валидатора (валидаторов Solidity и Cairo) настраивается согласно списку макетов.
По мере добавления встроенных модулей Keccak и Poseidon становилось все труднее поддерживать списки макетов достаточно маленькими, чтобы вместить множество встроенных модулей и обеспечить эффективное выполнение большинства блоков Starknet. Кроме того, ожидается, что эффективность значительно снизится по мере введения дополнительных встроенных функций, поскольку макет должен учитывать множество возможных комбинаций и соотношений между встроенными функциями.
В настоящее время команда StarkWare работает над улучшением системы, отказываясь от готовых списков макетов в пользу «динамических макетов», которые мгновенно настраиваются для каждого выполнения кода Cairo. Динамическая компоновка всегда будет оптимально распределять ресурсы для текущей проверки. С инженерной точки зрения поддержка динамической типизации потребует значительных изменений в кодовой базе. Тем не менее, команда StarkWare надеется упростить пробный слой Starknet, воспользовавшись преимуществами динамической компоновки, улучшенного использования блоков отслеживания и лучшего использования пруверов.
С динамическими макетами исчезает проблема ручного обслуживания многих встроенных модулей, что упрощает процесс интеграции большего количества новых встроенных модулей в Starknet.
Динамический макет и сборы
Одной из целей комиссий за транзакции является взимание с пользователей предельной стоимости протокола, понесенной транзакциями. Поскольку единицей комиссии за транзакцию является валюта, механизм комиссии включает преобразование ресурсов (например, шагов виртуальной машины, встроенных функций, данных вызовов, газа Ethereum) в токены (например, STRK, ETH).
В настоящее время, поскольку пруверы взимают плату на основе общего количества трасс, а не коэффициентов использования, трата ресурсов ложится на плечи пользователей. Динамическая компоновка улучшит использование единиц отслеживания, тем самым уменьшив взимание «ненужных» транзакционных комиссий (включая потребление ресурсов, не вызванное непосредственно транзакциями пользователей).
Интеграция встроенных функций Starknet
На данный момент интеграция встроенных функций не заканчивается последним шагом, который заключается в изменении базы кода Starknet для реализации практического использования. Степень изменения кода связана с приложением макета, и необходимо изменить код, чтобы гарантировать, что операционная система Starknet вызывает встроенные функции, когда это возможно. Например, операционная система Starknet вызывает хеш-функцию Poseidon во время выполнения кода Cairo и одновременно вызывает встроенную функцию Poseidon.
Как и в случае с макетами, встроенные функции Starknet теперь можно поддерживать вручную. Однако, в отличие от случая макета, эта ручная поддержка не является препятствием для интеграции, даже несмотря на то, что встроенных функций много. Другими словами, поддержка встроенных модулей Starknet не является препятствием для интеграции, динамическая компоновка действительно проложит путь для создания и интеграции дополнительных встроенных модулей.
Подведем итог
В этой статье мы объясним, что такое встроенные функции, их преимущества, связанные с ними проблемы и планы StarkWare. В настоящее время основное внимание уделяется динамической компоновке, которая не только повысит эффективность процесса проверки, но и облегчит интеграцию новых встроенных модулей.