Часть 1 из нашей серии о конфиденциальностирассмотрели, что включает в себя "конфиденциальность", в чем различие конфиденциальности в блокчейн-сетях от конфиденциальности веб2 и почему ее сложно достичь в блокчейнах.

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

Мы все строим одно и то же? Продолжайте чтение, чтобы узнать.

БлагодаряАвишай (SodaLabs), Лукас (Taceo) Майкл ( Equilibrium), и Nico (Арциум) за обсуждения, которые помогли сформировать этот пост.

Что может быть, не обремененное тем, что было

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

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

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

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

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

Три гипотезы, которые формируют наши взгляды

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

1. Шифрование будет скрыто от разработчиков приложений: Большинство разработчиков приложений не хотят (или не знают, как) заниматься шифрованием, необходимым для конфиденциальности. Неразумно ожидать, что они будут реализовывать свое собственное шифрование и строить частные цепочки приложений (например, Gate.io).ZcashилиНамада) или частные приложения поверх публичной цепочки (например, Tornado Cash). Это просто слишком много сложности и накладных расходов, что в настоящее время ограничивает пространство проектирования для большинства разработчиков (невозможно создавать приложения, которые требуют некоторых гарантий конфиденциальности). Из-за этого мы считаем, что сложность управления криптографической частью должна быть абстрагирована от разработчиков приложений. Два подхода здесь - программируемая конфиденциальная инфраструктура (общая частная L1/L2) или «конфиденциальность как сервис», который позволяет аутсорсинг конфиденциальных вычислений.
2. Во многих случаях использования (возможно, в большей степени, чем мы думаем) требуется общее частное состояние: Как упоминалось ранее, многим приложениям требуется некое скрытое состояние и/или логика для правильной работы. Общее частное состояние — это подмножество этого, в котором несколько сторон выполняют вычисления над одним и тем же фрагментом частного состояния. В то время как мы можем доверить централизованную партию сделать это за нас и покончить с этим, в идеале мы хотим сделать это с минимальным доверием, чтобы избежать единых точек отказа. Доказательство с нулевым разглашением (ZKP) само по себе не может достичь этого - нам необходимо использовать дополнительные инструменты, такие как доверенные среды выполнения (TEE), полностью гомоморфное шифрование (FHE) и/или многосторонние вычисления (MPC).
3. Большие защищенные наборы максимизируют конфиденциальность: большая часть информации раскрывается при вход или выходнабор заслоненных данных, поэтому мы должны стараться минимизировать его. Наличие нескольких частных приложений, построенных на одной и той же блокчейн, может усилить гарантии конфиденциальности, увеличив количество пользователей и транзакций в одном и том же наборе заслоненных данных.

Конечная игра инфраструктуры конфиденциальности

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

Не совсем. У всех них есть различные компромиссы, и мы уже видим, как они комбинируются различными способами. Всего мы выявили 11 различных подходов (см. приложение).

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

• Протоколы конфиденциальности на основе ZK с доказательством со стороны клиента могут предоставить надежные гарантии конфиденциальности, но не позволяют нескольким сторонам выполнять вычисления над одним и тем же приватным состоянием. Это ограничивает выразительность, то есть типы приложений, которые могут создавать разработчики.
• FHE позволяет вычислять зашифрованные данные и совместное частное состояние, но возникает вопрос, кто владеет этим состоянием, т.е. кто удерживает ключ расшифровки. Это ограничивает степень гарантий конфиденциальности и насколько мы можем доверять тому, что сегодняшнее частное остается таковым и завтра.

Если желаемым конечным состоянием является наличие программной инфраструктуры конфиденциальности, способной обрабатывать общее частное состояние без единой точки отказа, то оба подхода приводят к MPC.

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

• Сети ZKP: MPC используется для добавления выразительности, позволяя вычисление над общим приватным состоянием.
• FHE сети: MPC используется для повышения безопасности и обеспечения сильных гарантий конфиденциальности путем распределения ключа дешифровки комитету MPC (а не единственному стороннему лицу).

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

1. Насколько надежны гарантии конфиденциальности, которые могут обеспечить протоколы MPC в блокчейнах?
2. Технология достаточно зрела? Если нет, то в чем узкие места?
3. Учитывая силу гарантий и накладные расходы, имеет ли это смысл по сравнению с альтернативными подходами?

Давайте рассмотрим эти вопросы более подробно.

Анализ рисков и слабых мест с использованием MPC

Всегда следует спрашивать, когда решение использует FHE: «Кто удерживает ключ расшифровки?». Если ответ такой: «сеть», то следующий вопрос будет: «Какие реальные сущности составляют эту сеть?». Последний вопрос важен для всех случаев использования MPC в какой-либо форме.

Источник: Доклад Zama на ETH CC

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

• Какой порог вредоносных сторон может выдержать протокол?
• Из каких партий состоит сеть и насколько можно доверять им?
• Количество различных сторон, которые участвуют в сети, и их распределение - есть ли общие векторы атаки?
• Сеть разрешает ли отсутствие разрешения или разрешение (экономический стейк против основанного на репутации/законе)?
• Каково наказание за злонамеренное поведение? Является ли сговор в игре теоретически оптимальным исходом?

1. Насколько надежны гарантии конфиденциальности, которые могут предоставить MPC-протоколы в блокчейнах?

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

Для расшифровки требуемый порог зависит от выбранной схемы MPC - в значительной степени компромисс между активностью ("гарантированная доставка результата") и безопасностью. Можно использовать схему N/N, которая очень надежна, но ломается, если выходит из строя только один узел. С другой стороны, схемы N/2 или N/3 более надежны, но имеют более высокий риск коллузии.

Два условия для равновесия:

1. Секретная информация никогда не раскрывается (например, ключ дешифрования)
2. Секретная информация никогда не исчезает (даже если, скажем, 1/3 сторон внезапно уходят).

Выбранная схема различается в различных реализациях. Например, Zama нацеливается на N/3в то время как Arcium в настоящее время реализуетСхема N/Nно впоследствии также планируется поддерживать схемы с более высокими гарантиями активности (и более крупными доверительными предположениями).

Один компромисс вдоль этой торговой границы был бы в том, чтобы иметь смешанное решение:

• Комитет высокого доверия, который обрабатывает ключи с порогом, например, N/3.
• Вычислительные комитеты, которые являются вращающимися, и имеют, например, порог N-1 (или несколько различных вычислительных комитетов с различными характеристиками, из которых пользователи могут выбирать).

Хотя это звучит привлекательно в теории, это также вводит дополнительную сложность, такую как то, как комитет вычислений будет взаимодействовать с высокодоверенным комитетом.

Еще один способ усилить гарантии безопасности - запускать MPC внутри доверенного аппаратного обеспечения, чтобы ключевые доли хранились внутри защищенной ограды. Это делает более сложным извлечение или использование ключевых долей для чего-либо, кроме того, что определено протоколом. По крайней мере ZamaиArciumисследуют угол TEE.

Более тонкие риски включают граничные случаи, связанные, например, с социальной инженерией, когда, например, старший инженер работает во всех компаниях, включенных в кластер MPC, в течение 10-15 лет.

2. Технология достаточно зрела? Если нет, то каковы узкие места?

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

1. Малый набор операторов: Чтобы управлять нагрузкой на коммуникацию, большинство существующих протоколов в настоящее время ограничены малым набором операторов. Например, дешифраторная сеть Zama в настоящее время позволяет использовать максимум 4 узла (хотя они планируют расширить до 16). Основываясь на начальных показателях, опубликованных Zama для их дешифраторной сети (TKMS), для расшифровки даже с помощью всего 4-узлового кластера требуется 0,5-1 секунды (полный поток занимает гораздо больше времени). Другим примером является Taceo's.Реализация MPC для базы данных iris Worldcoin, который имеет 3 стороны (с предположением о 2/3 честной стороне).

1. Источник: Zama talk на ETH CC
2. Набор операторов с разрешениями: в большинстве случаев набор операторов имеет разрешения. Это означает, что мы полагаемся на репутацию и юридические контракты, а не на экономическую или криптографическую безопасность. Основная проблема с набором операторов без разрешений заключается в том, что нет никакого способа узнать, вступают ли люди в сговор вне сети. Кроме того, это потребовало бы регулярной начальной загрузки или перераспределения общего ресурса ключа, чтобы узлы могли динамически входить/выходить из сети. Несмотря на то, что конечная цель является конечным назначением операторов без разрешений, и в настоящее время ведутся исследования о том, как расширить механизм PoS для порогового MPC (например, Zama), разрешенный маршрут кажется лучшим способом продвижения вперед на данный момент.

Альтернативные подходы

Полноценный коктейль конфиденциальности состоит из:

• FHE для делегированного частного вычисления
• ZKP для проверки того, что вычисление FHE было выполнено правильно
• MPC для порогового расшифрования
• Каждый узел MPC работает в рамках TEE для дополнительной безопасности

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

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

1. Использование MPC напрямую для общих вычислений

Если как ZK, так и FHE в конечном итоге возвращаются к доверительным предположениям MPC, почему бы не использовать MPC для вычисления напрямую? Это вполне обоснованный вопрос и что-то, над чем работают команды, такие как Gate.io.Арциум, SodaLabs (используется Cotiv2),Тасео, и Nillionпытаются сделать. Обратите внимание, что MPC принимает множество форм, но из трех основных подходов мы здесь имеем в виду протоколы на основе секретного разделения и зашифрованных цепей (GC), а не протоколы на основе FHE, использующие MPC для дешифровки.

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

Есть несколько способов уменьшить накладные расходы, например, выполняя предварительную обработку (т.е. самые дорогие части протокола) заранее и в автономном режиме АрциумиSodaLabsисследуют. Вычисление затем выполняется в онлайн-фазе, что потребляет некоторые из данных, полученных в оффлайн-фазе. Это значительно снижает общую коммуникационную нагрузку.

Таблица ниже от SodaLabs показывает начальные результаты тестирования времени выполнения различных опкодов 1000 раз в их gcEVM (отмечено в микросекундах). Хотя это шаг в правильном направлении, остается много работы по улучшению эффективности и расширению набора операторов за пределами нескольких узлов.

Источник: SodaLabs

Преимущество подхода, основанного на ZK, заключается в том, что вы используете MPC только для случаев использования, которые требуют вычислений над общим закрытым состоянием. FHE более прямо конкурирует с MPC и сильно полагается на аппаратное ускорение.

2. Доверенные среды выполнения

В последнее время возродился интерес к TEE, которые можно использовать либо изолированно (частные блокчейны на основе TEE или сопроцессоры), либо в сочетании с другими PET, такими как решения на основе ZK (используйте TEE только для вычислений над общим частным состоянием).

В то время как TEE в некотором смысле более зрелы и не создают такую ​​большую нагрузку на производительность, они не обходятся без недостатков. Во-первых, TEE имеют разные доверительные предположения (1/N) и предлагают аппаратное решение, а не программное. Одна из часто слышимых критик обращается к прошломууязвимости SGX, но стоит отметить, что TEE ≠ Intel SGX. Также ТИЗ требует доверия поставщику оборудования, а оборудование дорогое (недоступное для большинства). Одним из решений проблемы физических атак может быть запускайте TEE в космоседля критически важных вещей.

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

3. Частный DAC и другие подходы, основанные на доверенных сторонних лицах в области конфиденциальности

Промежуточная конфиденциальность может обеспечить конфиденциальность от других пользователей, но гарантии конфиденциальности исходят исключительно от доверия третьей стороне (единой точке отказа). Хотя это напоминает «конфиденциальность web2» (конфиденциальность от других пользователей), ее можно укрепить дополнительными гарантиями (криптографическими или экономическими) и позволить проверку правильного выполнения.

Частные комитеты доступности данных (DAC) являются одним из примеров этого; Участники DAC хранят данные вне цепи блоков, и пользователи доверяют им правильно хранить данные и обновлять состояние перехода. Еще один вариант - это Франчайзед Сиквенсер предложено Томом Уолпо.

Хотя такой подход сопряжен с большими уступками в гарантии конфиденциальности, это может быть единственной реальной альтернативой для приложений с низкой стоимостью и высокой производительностью (по крайней мере, пока). Примером является Протокол Lens, который планирует использовать частный DAC для достижения частных данных. Для таких случаев, как ончейн-социальные сети, компромисс между конфиденциальностью и стоимостью/производительностью вероятно вполне разумен на данный момент (учитывая затраты и накладные расходы на альтернативы).

4. Скрытые адреса

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

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

Кроме того, гарантии конфиденциальности, которые обеспечивают скрытые адреса, не настолько надёжны, как альтернативы. Анонимность может быть нарушена спростой анализ кластеризации, особенно если входящие и исходящие трансферы не находятся в похожем диапазоне (например, получение $10 000, но траты в среднем составляют $10-100 на повседневные операции). Еще одна проблема со скрытыми адресами - это обновление ключей, которое сегодня требует индивидуального выполнения для каждого кошелька (решение с массовым обновлением ключей может помочь с этой проблемой). С точки зрения пользовательского опыта протоколы скрытых адресов также требуют абстрагирования учетной записи или платежного агента для оплаты комиссий, если учетная запись не имеет токена для оплаты комиссии (например, ETH).

Риски для нашей тезиса

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

1. Общее частное состояние не настолько важно, как мы его представляем: в этом случае инфраструктура на основе ZK имеет больше шансов победить, так как она обеспечивает более надежные гарантии конфиденциальности и меньшие накладные расходы по сравнению с FHE. Уже существуют случаи использования, когда системы на основе ZK хорошо работают для изолированных случаев использования, таких как протоколы приватных платежей.Payy.
2. Компромисс в производительности не стоит выгоды в гарантии конфиденциальности: Можно утверждать, что доверительные предположения сети MPC с 2-3 разрешенными участниками не существенно отличаются от единственного централизованного игрока и что значительный рост стоимости / накладных расходов не стоит этого. Это может быть правдой для многих приложений, особенно для низкостоимостных и чувствительных к затратам (например, социальных или игровых). Однако существует также много высокоценных случаев использования, где сотрудничество в настоящее время является очень дорогим (или невозможным) из-за юридических вопросов или большого трения координации. В последнем случае решения на основе MPC и FHE могут блеснуть.
3. Специализация превосходит универсальный дизайн: Создание новой цепи и запуск сообщества пользователей и разработчиков трудны. Из-за этого универсальная конфиденциальная инфраструктура (L1/L2s) может испытывать трудности с привлечением внимания. Еще один вопрос касается специализации; очень сложно, чтобы один дизайн протокола охватывал все пространство компромиссов. В этом мире преобладают решения, обеспечивающие конфиденциальность для существующих экосистем (конфиденциальность как услуга) или специализированные случаи использования (например, для платежей). Однако мы скептически относимся к последнему из-за сложности, которую он вносит в разработчиков приложений, которым пришлось бы сами реализовывать некоторую криптографию (вместо того чтобы это было абстрагировано).
4. Регулирование продолжает мешать экспериментам в области решений для конфиденциальности: это риск для тех, кто создает как инфраструктуру конфиденциальности, так и приложения с некоторыми гарантиями конфиденциальности. Нефинансовые случаи использования сталкиваются с меньшим регуляторным риском, но трудно (почти невозможно) контролировать, что строится на основе инфраструктуры конфиденциальности с открытым доступом. Мы можем хорошо решить технические проблемы до регуляторных.
5. Накладные расходы MPC и схем на основе FHE остаются слишком высокими для большинства случаев использования: в то время как MPC страдает в основном от накладных расходов на связь, команды FHE тяжело полагаются на аппаратное ускорение для улучшения своей производительности. Однако, если мы можем экстраполировать эволюцию специализированного оборудования на стороне ZK, это займет гораздо больше времени, чем хотелось бы большинству, прежде чем мы получим готовое к производству аппаратное обеспечение FHE. Примеры команд, работающих над ускорением аппаратного обеспечения FHE, включаютOptalysys, fhelaи Niobium.

Сводка

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

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

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

Даже если у вас лучший молоток в мире, не все является гвоздем.

Приложение 1: Различные подходы к конфиденциальности в блокчейнах

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

Существует множество различных PET для выбора, но наиболее актуальными для отрасли блокчейна являются трехбуквенные аббревиатуры - ZKP, MPC, FHE и TEE - наряду с дополнительными методами, такими как скрытые адреса:

Эти ПЭТ можно комбинировать различными способами для достижения различных компромиссов и предположений о доверии. У нас также есть решения, которые полагаются на доверенную третью сторону (посредническая конфиденциальность), например, комитеты по обеспечению доступности конфиденциальных данных (DAC). Они могут обеспечить конфиденциальность от других пользователей, но гарантии конфиденциальности исходят исключительно из доверия третьей стороне. В этом смысле она напоминает «web2 privacy» (конфиденциальность от других пользователей), но может быть усилена дополнительными гарантиями (криптографическими или экономическими).

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

• Доверенность и конфиденциальность с минимальным доверием (существует ли единая точка отказа?)
• Аппаратный и программный подход
• Изолированные случаи против комбинации нескольких PET
• L1 против L2
• Новая цепочка против дополнительной конфиденциальности существующих цепочек ("конфиденциальность как услуга")
• Размер защищенного набора (Multi-chain > Single-chain > Application > Single asset)

Приложение 2: Обзор отрасли

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

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

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