Объявление о zkSharding для Ethereum

Продвинутый1/29/2024, 2:34:45 PM
zkSharding стремится предоставить альтернативное решение масштабирования, интегрируя несколько осколков в унифицированный исполнительный уровень Layer2. В этой статье рассматриваются его особенности, архитектура и планы на будущее.

Слишком длинный; не читал

  • =nil; - это разделенный zkRollup - новая концепция L2 для динамического и безопасного масштабирования Ethereum через параллельное выполнение транзакций на уровне протокола по всем шардам.
  • Оборудованный zkSharding, =nil; предлагает горизонтальное масштабирование без ущерба для преимуществ одного исполнительного слоя, а именно объединенной ликвидности и экономической безопасности.
  • =nil; обеспечивает приложения полную компоновку с Ethereum через прозрачный и подтверждаемый доступ к данным Ethereum.
  • =nil; introduces a Type-1 zkEVM compiled with zkLLVM.
  • Быстрая генерация доказательств обеспечивается открытым рыночным соперничеством через Proof Market - рынок генерации доказательств без разрешения.

Введение в zkSharding

Сегодня решения уровня-2 жертвуют масштабируемостью в обмен на фрагментацию состояния. Мы представляем дизайн уровня-2 (L2), =nil;, который выталкивает пределы масштабируемости Ethereum, не жертвуя преимуществами объединенной среды выполнения. Решение объединяет динамический механизм шардинга с проверяемым доступом к данным Ethereum, обеспеченным технологиями нулевого доказательства. Ключевые элементы включают:

  • zkRollup с Шардингом: Основа =nil; - это доказуемый протокол шардинга, обеспечивающий горизонтальную масштабируемость без ущерба для безопасности или эффективности. Этот подход решает некоторые текущие ограничения вертикального масштабирования (L3, L4 и т. д.), а именно фрагментацию данных и ликвидности.
  • Прямой доступ к данным Ethereum: Возможность вызывать исходные данные Ethereum из приложений L2 позволяет нам повторно использовать уже развернутые приложения. Прямой доступ к данным L1 из L2 обеспечивает более унифицированную и безшовную среду.

Через zkSharding =nil; вы получаете преимущества как монолитного, так и модульного дизайнов, включая:

  • Масштабируемость

    • Нет ограничений по масштабируемости, так как выполнение выполняется параллельно. Пропускная способность оценивается примерно в 60 тыс. передач ERC-20 в секунду с использованием примерно 400 узлов.
    • Конкурентное создание доказательств через Рынок доказательств обеспечивает самую быструю окончательность L1 и самые низкие затраты на создание доказательств.
  • Единая среда выполнения

    • Объединенная среда выполнения гарантирует отсутствие фрагментации безопасности/ликвидности, поскольку каждый шар является частью целого кластера.
    • Снижение необходимости миграции ликвидности с Ethereum как =nil; обеспечивает прозрачный доступ к его данным для приложений путем обязания каждого валидатора поддерживать полное состояние Ethereum как часть развертывания, позволяя приложениям получать доступ к данным прямо из zkEVM =nil;.
  • Безопасность

    • Переходы состояний обеспечиваются с помощью zkEVM, скомпилированных через zkLLVM. Он обеспечивает проверяемую безопасность (например, безопасность ограничений), поскольку код легко проверяем, поскольку цепи zkEVM компилируются из использованной в производстве реализации EVM на языке высокого уровня, а не написаны вручную.
    • Децентрализован с самого начала благодаря децентрализованному поколению доказательств, возможному благодаря =nil; Рынок доказательств.
  • Функциональность

    • Тип-1 zkEVM, полностью эквивалентный байт-код EVM, скомпилированный через zkLLVM.
    • Среда, специально созданная для приложений с высокими требованиями к времени, памяти и алгоритмической сложности, путем повышения однозарядной согласованности и введения принудительного расположения приложений на заряд для уменьшения задержки. Примеры включают децентрализованные биржи, рынки доказательств, децентрализованные последователи/строители, приложения с общим состоянием (так называемые автономные миры и т. д.).

Динамическое компонуемое масштабирование

На нижнем уровне состояние =nil; разделено на основной шард и несколько вторичных шардов. Основная роль основного шарда - синхронизация и консолидация данных из вторичных шардов. Он использует Ethereum как свой уровень доступности данных и в качестве проверяющего для доказательств перехода состояния, аналогично типичным операциям zkRollups.

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

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

Для иллюстрации потока транзакций от инициирования пользователем до подтверждения на Ethereum рассмотрите следующие шаги:

  • Пользователь подписывает транзакцию (tx) и отправляет ее в сеть.
  • Валидаторы в шарде S, где находится кошелек пользователя, помещают транзакции в пул памяти.
  • Эти валидаторы затем создают новый блок B(1/S)
  • Хэш B(1/S) записан на основной обработке в блоке B(1/M)
  • Доказательство перехода состояния для B(1/S) производится и проверяется основным шаром в блоке B(2/M)
  • Доказательство перехода состояния для B(2/M) отправляется в Ethereum для проверки и сопровождается необходимыми данными для обеспечения доступности данных.
  • После завершения этого процесса tx подтверждается Ethereum.

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

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

Чтобы гарантировать безопасность каждого вторичного шарда, его комитет валидаторов обязан доказать переход его состояния на первичный, чтобы убедиться, что в меньшей группе валидаторов не произошло мошенничества. У каждого комитета валидаторов шардов есть дополнительные задачи, помимо обслуживания шардов. Валидаторы отвечают за отслеживание определенных типов событий, а именно межшардовых сообщений, в рамках «ближайших шардов». Ближайшие осколки определяются на основе расстояния Хэмминга в идентификаторах сегментов.

zkEVM через zkLLVM: Тип-1 Безопасный, Проверяемый и Производительный zkEVM

=nil;s zkEVM - это zkEVM типа 1, скомпилированный с zkLLVM. Чтобы понять различия между более традиционными zkEVM и zkEVM =nil;, нам необходимо обсудить ограничения, связанные с процессом определения цепи, лежащей в основе zkEVM. Цепь zkEVM является критической частью, отвечающей за правильность доказательства перехода состояния, обычно определяемого с помощью некоторого пользовательского zkDSL или просто библиотеки. Такой способ определения цепи вызывает проблемы, связанные с:

  • Безопасность: Проблемыиз-за размера схемы и ручного копирования логики EVM.
  • Проверяемость: Ограниченнаяпроверяемость и inspectabilityиз-за сложности и неявности используемых zkDSLs.
  • Возможность обновления: Сложность обслуживания и обновления из-за требований к определению ограничений вручную. В случае любого изменения в EVM - большинство цепей zkEVM потребуется пересмотреть и перепроверить с нуля.
  • Совместимость: Сложность реализации фактически совместимой с байт-кодом (так называемой типа 1) цепи zkEVM часто приводит к ограничениям для приложений из-за различий в поведении zkEVM и фактическом поведении EVM.

=nil; zkEVM эффективно решает все эти проблемы, будучи:

  • Безопасность: Схема должна быть автоматически создана из того же высокоуровневого кода, используемого в фактически работающих узлах Ethereum, чтобы гарантировать отсутствие различий в алгоритмах.
  • Проверяемый: Схема должна быть представлена на языке программирования высокого уровня (таком как C++ или Rust), который должен быть написан таким образом, чтобы его легко можно было прочитать обычному разработчику.
  • Upgradeable: Цепь должна быть определена таким образом, чтобы любое изменение в EVM можно было легко перевести/скомпилировать в цепь zkEVM, доказывающую/определяющую точно такое же поведение. Никакой необходимости в полной перекомпиляции или повторной проверке не должно возникать при таком обновлении.
  • Совместимый с байткодом (также известный как тип-1): Компиляция схем из языков высокого уровня обеспечивает полную совместимость с байткодом и поведением EVM, что значительно сокращает время выхода на рынок для приложений EVM и время/усилия, необходимые для достижения такой совместимости.

zkEVM, скомпилированный через zkLLVM, обеспечивает безопасность по конструкции, используя evmone для обеспечения полной согласованности с использованным в производстве EVM Ethereum. zkLLVM (C++ или Rust) автоматически компилируется в цепь, что означает, что человеческая ошибка исключается из процесса определения цепи.

Более того, поскольку =nil; zkEVM компилируется через zkLLVM, он естественно более гибок (и, следовательно, более будущеустойчив), чем вручную определенные схемы, поскольку их легко настраивать, и генерация схемы происходит автоматически. Он также более аудируем, что означает, что его безопасность не идет в ущерб включению последних EIP, добавленных в Ethereum.

zkRollup с безопасностью и доступностью данных Ethereum

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

  • Основной шард использует Ethereum в качестве своего DA.
  • Вторичные осколки имеют возможность использовать Ethereum или не иметь отдельной DA.

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

Кроме того, эту структуру можно расширить, чтобы включить другие типы DA.

Прозрачный доступ к данным Ethereum

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

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

Что дальше:

=nil; и zkSharding являются результатом продуктов, которые =nil; Foundation разработала за последние 4 года. Ее целью является быть первым компонуемым, масштабируемым и универсальным решением Ethereum L2 zkRollup. Мы с нетерпением ждем возможности поделиться более подробными сведениями о реализации в ближайшие несколько месяцев. Обязательно следите за нашим Twitter, чтобы быть в курсе нашего прогресса!

Для технически подкованных мы разработали отдельный, всеобъемлющий вводный курскоторый углубляется в детали =nil; и zkSharding. Этот вводный курс является вашим путеводителем в понимание тонкостей этого подхода, оснащенного всеми техническими деталями и предварительными условиями, которые вам нужны.

Ознакомьтесь с нашим техническим введением прямо сейчас и присоединяйтесь к разговору на DiscordиTelegram. Давайте вместе исследуем беспредельные возможности zkSharding!

Disclaimer:

  1. Эта статья перепечатана из [nil.foundation]. Все авторские права принадлежат оригинальному автору [nil.foundation]. Если есть возражения против этого перепечатывания, пожалуйста, свяжитесь с Gate Learnкоманда, и они незамедлительно разберутся с этим.
  2. Отказ от ответственности: Взгляды и мнения, выраженные в этой статье, принадлежат исключительно автору и не являются какими-либо инвестиционными рекомендациями.
  3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.

Объявление о zkSharding для Ethereum

Продвинутый1/29/2024, 2:34:45 PM
zkSharding стремится предоставить альтернативное решение масштабирования, интегрируя несколько осколков в унифицированный исполнительный уровень Layer2. В этой статье рассматриваются его особенности, архитектура и планы на будущее.

Слишком длинный; не читал

  • =nil; - это разделенный zkRollup - новая концепция L2 для динамического и безопасного масштабирования Ethereum через параллельное выполнение транзакций на уровне протокола по всем шардам.
  • Оборудованный zkSharding, =nil; предлагает горизонтальное масштабирование без ущерба для преимуществ одного исполнительного слоя, а именно объединенной ликвидности и экономической безопасности.
  • =nil; обеспечивает приложения полную компоновку с Ethereum через прозрачный и подтверждаемый доступ к данным Ethereum.
  • =nil; introduces a Type-1 zkEVM compiled with zkLLVM.
  • Быстрая генерация доказательств обеспечивается открытым рыночным соперничеством через Proof Market - рынок генерации доказательств без разрешения.

Введение в zkSharding

Сегодня решения уровня-2 жертвуют масштабируемостью в обмен на фрагментацию состояния. Мы представляем дизайн уровня-2 (L2), =nil;, который выталкивает пределы масштабируемости Ethereum, не жертвуя преимуществами объединенной среды выполнения. Решение объединяет динамический механизм шардинга с проверяемым доступом к данным Ethereum, обеспеченным технологиями нулевого доказательства. Ключевые элементы включают:

  • zkRollup с Шардингом: Основа =nil; - это доказуемый протокол шардинга, обеспечивающий горизонтальную масштабируемость без ущерба для безопасности или эффективности. Этот подход решает некоторые текущие ограничения вертикального масштабирования (L3, L4 и т. д.), а именно фрагментацию данных и ликвидности.
  • Прямой доступ к данным Ethereum: Возможность вызывать исходные данные Ethereum из приложений L2 позволяет нам повторно использовать уже развернутые приложения. Прямой доступ к данным L1 из L2 обеспечивает более унифицированную и безшовную среду.

Через zkSharding =nil; вы получаете преимущества как монолитного, так и модульного дизайнов, включая:

  • Масштабируемость

    • Нет ограничений по масштабируемости, так как выполнение выполняется параллельно. Пропускная способность оценивается примерно в 60 тыс. передач ERC-20 в секунду с использованием примерно 400 узлов.
    • Конкурентное создание доказательств через Рынок доказательств обеспечивает самую быструю окончательность L1 и самые низкие затраты на создание доказательств.
  • Единая среда выполнения

    • Объединенная среда выполнения гарантирует отсутствие фрагментации безопасности/ликвидности, поскольку каждый шар является частью целого кластера.
    • Снижение необходимости миграции ликвидности с Ethereum как =nil; обеспечивает прозрачный доступ к его данным для приложений путем обязания каждого валидатора поддерживать полное состояние Ethereum как часть развертывания, позволяя приложениям получать доступ к данным прямо из zkEVM =nil;.
  • Безопасность

    • Переходы состояний обеспечиваются с помощью zkEVM, скомпилированных через zkLLVM. Он обеспечивает проверяемую безопасность (например, безопасность ограничений), поскольку код легко проверяем, поскольку цепи zkEVM компилируются из использованной в производстве реализации EVM на языке высокого уровня, а не написаны вручную.
    • Децентрализован с самого начала благодаря децентрализованному поколению доказательств, возможному благодаря =nil; Рынок доказательств.
  • Функциональность

    • Тип-1 zkEVM, полностью эквивалентный байт-код EVM, скомпилированный через zkLLVM.
    • Среда, специально созданная для приложений с высокими требованиями к времени, памяти и алгоритмической сложности, путем повышения однозарядной согласованности и введения принудительного расположения приложений на заряд для уменьшения задержки. Примеры включают децентрализованные биржи, рынки доказательств, децентрализованные последователи/строители, приложения с общим состоянием (так называемые автономные миры и т. д.).

Динамическое компонуемое масштабирование

На нижнем уровне состояние =nil; разделено на основной шард и несколько вторичных шардов. Основная роль основного шарда - синхронизация и консолидация данных из вторичных шардов. Он использует Ethereum как свой уровень доступности данных и в качестве проверяющего для доказательств перехода состояния, аналогично типичным операциям zkRollups.

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

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

Для иллюстрации потока транзакций от инициирования пользователем до подтверждения на Ethereum рассмотрите следующие шаги:

  • Пользователь подписывает транзакцию (tx) и отправляет ее в сеть.
  • Валидаторы в шарде S, где находится кошелек пользователя, помещают транзакции в пул памяти.
  • Эти валидаторы затем создают новый блок B(1/S)
  • Хэш B(1/S) записан на основной обработке в блоке B(1/M)
  • Доказательство перехода состояния для B(1/S) производится и проверяется основным шаром в блоке B(2/M)
  • Доказательство перехода состояния для B(2/M) отправляется в Ethereum для проверки и сопровождается необходимыми данными для обеспечения доступности данных.
  • После завершения этого процесса tx подтверждается Ethereum.

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

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

Чтобы гарантировать безопасность каждого вторичного шарда, его комитет валидаторов обязан доказать переход его состояния на первичный, чтобы убедиться, что в меньшей группе валидаторов не произошло мошенничества. У каждого комитета валидаторов шардов есть дополнительные задачи, помимо обслуживания шардов. Валидаторы отвечают за отслеживание определенных типов событий, а именно межшардовых сообщений, в рамках «ближайших шардов». Ближайшие осколки определяются на основе расстояния Хэмминга в идентификаторах сегментов.

zkEVM через zkLLVM: Тип-1 Безопасный, Проверяемый и Производительный zkEVM

=nil;s zkEVM - это zkEVM типа 1, скомпилированный с zkLLVM. Чтобы понять различия между более традиционными zkEVM и zkEVM =nil;, нам необходимо обсудить ограничения, связанные с процессом определения цепи, лежащей в основе zkEVM. Цепь zkEVM является критической частью, отвечающей за правильность доказательства перехода состояния, обычно определяемого с помощью некоторого пользовательского zkDSL или просто библиотеки. Такой способ определения цепи вызывает проблемы, связанные с:

  • Безопасность: Проблемыиз-за размера схемы и ручного копирования логики EVM.
  • Проверяемость: Ограниченнаяпроверяемость и inspectabilityиз-за сложности и неявности используемых zkDSLs.
  • Возможность обновления: Сложность обслуживания и обновления из-за требований к определению ограничений вручную. В случае любого изменения в EVM - большинство цепей zkEVM потребуется пересмотреть и перепроверить с нуля.
  • Совместимость: Сложность реализации фактически совместимой с байт-кодом (так называемой типа 1) цепи zkEVM часто приводит к ограничениям для приложений из-за различий в поведении zkEVM и фактическом поведении EVM.

=nil; zkEVM эффективно решает все эти проблемы, будучи:

  • Безопасность: Схема должна быть автоматически создана из того же высокоуровневого кода, используемого в фактически работающих узлах Ethereum, чтобы гарантировать отсутствие различий в алгоритмах.
  • Проверяемый: Схема должна быть представлена на языке программирования высокого уровня (таком как C++ или Rust), который должен быть написан таким образом, чтобы его легко можно было прочитать обычному разработчику.
  • Upgradeable: Цепь должна быть определена таким образом, чтобы любое изменение в EVM можно было легко перевести/скомпилировать в цепь zkEVM, доказывающую/определяющую точно такое же поведение. Никакой необходимости в полной перекомпиляции или повторной проверке не должно возникать при таком обновлении.
  • Совместимый с байткодом (также известный как тип-1): Компиляция схем из языков высокого уровня обеспечивает полную совместимость с байткодом и поведением EVM, что значительно сокращает время выхода на рынок для приложений EVM и время/усилия, необходимые для достижения такой совместимости.

zkEVM, скомпилированный через zkLLVM, обеспечивает безопасность по конструкции, используя evmone для обеспечения полной согласованности с использованным в производстве EVM Ethereum. zkLLVM (C++ или Rust) автоматически компилируется в цепь, что означает, что человеческая ошибка исключается из процесса определения цепи.

Более того, поскольку =nil; zkEVM компилируется через zkLLVM, он естественно более гибок (и, следовательно, более будущеустойчив), чем вручную определенные схемы, поскольку их легко настраивать, и генерация схемы происходит автоматически. Он также более аудируем, что означает, что его безопасность не идет в ущерб включению последних EIP, добавленных в Ethereum.

zkRollup с безопасностью и доступностью данных Ethereum

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

  • Основной шард использует Ethereum в качестве своего DA.
  • Вторичные осколки имеют возможность использовать Ethereum или не иметь отдельной DA.

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

Кроме того, эту структуру можно расширить, чтобы включить другие типы DA.

Прозрачный доступ к данным Ethereum

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

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

Что дальше:

=nil; и zkSharding являются результатом продуктов, которые =nil; Foundation разработала за последние 4 года. Ее целью является быть первым компонуемым, масштабируемым и универсальным решением Ethereum L2 zkRollup. Мы с нетерпением ждем возможности поделиться более подробными сведениями о реализации в ближайшие несколько месяцев. Обязательно следите за нашим Twitter, чтобы быть в курсе нашего прогресса!

Для технически подкованных мы разработали отдельный, всеобъемлющий вводный курскоторый углубляется в детали =nil; и zkSharding. Этот вводный курс является вашим путеводителем в понимание тонкостей этого подхода, оснащенного всеми техническими деталями и предварительными условиями, которые вам нужны.

Ознакомьтесь с нашим техническим введением прямо сейчас и присоединяйтесь к разговору на DiscordиTelegram. Давайте вместе исследуем беспредельные возможности zkSharding!

Disclaimer:

  1. Эта статья перепечатана из [nil.foundation]. Все авторские права принадлежат оригинальному автору [nil.foundation]. Если есть возражения против этого перепечатывания, пожалуйста, свяжитесь с Gate Learnкоманда, и они незамедлительно разберутся с этим.
  2. Отказ от ответственности: Взгляды и мнения, выраженные в этой статье, принадлежат исключительно автору и не являются какими-либо инвестиционными рекомендациями.
  3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.
今すぐ始める
登録して、
$100
のボーナスを獲得しよう!