Пересылка оригинального заголовка 'RGB++ и изоморфное связывание: CKB, Cardano и Fuel как улучшающие экосистему Биткойна'

Суть идеи «изоморфного связывания» заключается в использовании CKB, Cardano, Fuel и других блокчейнов на основе модели программирования UTXO в качестве функционального расширения, несущего «контейнеры» RGB-активов. Это изоморфное связывание также применимо к экологическим активным протоколам Биткойна с характеристиками UTXO, таким как Atomical и Runes, что облегчает создание внебиржевого слоя смарт-контрактов для Биткойна.

· В протоколе RGB++, пользоватам не нужно запускать клиент для личной верификации данных транзакций, и можно передать задачи, такие как проверка допустимости активов и хранение данных, цепочкам UTXO, таким как CKB и Cardano. Пока вы «оптимистичны» и считаете, что безопасность вышеуказанных общедоступных цепочек довольно надежна, нет необходимости проверять это самостоятельно.

Протокол RGB++ поддерживает пользователей, чтобы переключиться обратно в режим проверки клиента. В это время вы все равно можете использовать CKB в качестве хранилища данных/слоя DA, не обязательно хранить данные самостоятельно. Протокол RGB++ не требует кросс-цепных активов и может оперировать активами на цепочке CKB через биткойн-счета, а также снизить частоту выпуска обязательств на цепочке биткойн, что также способствует поддержке сценариев Defi;

· Если это под управлением контракта EVM, многие функции RGB++ сложно поддерживать. В целом, публичная цепочка/уровень расширения функции, подходящий для реализации изоморфного связывания, должен обладать следующими характеристиками:

1. Используйте модель UTXO или аналогичную схему хранения состояния;

2. Имеет значительную программу UTXO, позволяющую разработчикам писать скрипты разблокировки;

3. Существует пространство состояний, связанных с UTXO, которое может хранить статус актива;

4. Он может поддерживать работу легких узлов Биткойна через смарт-контракты или другие средства;

· Кроме CKB, Cardano и Fuel также могут поддерживать изоморфное связывание. Однако у последних двух может быть некоторая нагрузка в терминах языка смарт-контрактов и деталей проектирования контрактов. В настоящее время кажется, что CKB более подходит, чем два последних, в качестве слоя расширения функций для изоморфно связанных протоколов активов биткоина.

В 2017 году Cipher, один из сооснователей Nervos CKB, впервые предложил идею продукта изоморфного связывания. По сравнению с другими решениями уровня 2 для биткоина, изоморфное связывание может лучше совместимо с протоколами активов, такими как RGB, Runes и Atomical, и может избежать факторов, таких как межцепочные активы, которые приносят дополнительные бремена безопасности.

Для того чтобы объяснить простыми словами, изоморфное связывание использует UTXO на цепях CKB и Cardano в качестве «контейнеров», чтобы выразить активы UTXO, такие как RGB, тем самым добавляя программирование и более сложные сценарии. Ранее Geek web3 появился в «От BTC до Sui, ADA и Nervos: модель UTXO и связанные расширения》Обобщив серию блокчейнов, поддерживающих программируемые UTXO, в этой статье мы продолжим изучение, могут ли эти блокчейны адаптироваться к изоморфной схеме привязки.

RGB++ и изоморфное связывание

Прежде чем анализировать совместимость различных цепочек UTXO с изоморфным связыванием, мы должны сначала ввести принцип изоморфного связывания. Изоморфное связывание - это концепция, предложенная командой CKB в протоколе RGB++, поэтому здесь мы используем рабочий процесс RGB++ для введения того, что такое изоморфное связывание на основе CKB.

Прежде чем вводить протокол RGB++, давайте кратко поймем протокол RGB. RGB - это протокол активов/P2P-сеть, работающая под цепочкой Биткойна, немного похожая на Сеть Молний. Кроме того, RGB также является паразитным протоколом активов на основе UTXO Биткойна. Так называемое паразитирование означает, что клиент RGB будет объявлять под цепочкой Биткойна, к каким UTXO привязаны определенные активы RGB на цепочке Биткойна. После того, как вы владеете этим UTXO, привязанные к нему активы RGB также будут в вашем распоряжении.

Протоколы активов, такие как протокол RGB и ERC-20, работают очень по-разному. Контракт ERC-20 на Ethereum записывает состояние активов всех пользователей, и клиент узла Ethereum будет синхронизировать и проверять всю информацию о передаче, и записывать обновления состояния после передачи в контракте актива. Это давно известно людям, и это ничем иным, как полагание на процесс консенсуса Ethereum, чтобы обеспечить плавные изменения статуса активов. Поскольку консенсус узлов Ethereum очень надежен, пользователи могут по умолчанию рассматривать платформу управления активами на основе контрактов ERC-20 как "без проблем", даже если они не запускают клиент.

Протокол RGB очень странный. Для увеличения конфиденциальности он просто удаляет консенсус узла/клиента, что является обычным явлением в мире блокчейна. Пользователям приходится запускать клиент RGB сами и только получать и хранить "данные об активах, относящиеся к ним". Они не могут видеть, что делают другие. В отличие от Ethereum и ERC-20, на цепи есть все видимые записи о передаче.

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

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

Таким образом, вы можете узнать, являются ли деньги, переданные вам другой стороной, «сомнительными», так что суть RGB заключается в том, чтобы позволить сторонам сделки запустить клиент для верификации. Основываясь на режиме клиентской верификации, соответствующем предположению об игре рационального лица, при условии что стороны являются рациональными и клиентское программное обеспечение в порядке, можно гарантировать, что проблемный перевод активов не вступит в силу или не будет признан другими.

Следует отметить, что протокол RGB будет сжимать данные транзакции под цепочку Биткойна в Обязательство (по сути, корень Меркля) и загружать их в цепочку Биткойна. Это позволит прямо связать записи о передаче под цепочкой с основной сетью Биткойн. Установить соединение.

(Диаграмма взаимодействия протокола RGB)

Поскольку среди клиентов RGB нет консенсуса, выпуск контракта ресурса RGB не может быть распространен на все узлы «чрезвычайно надежно». Издатели и пользователи контрактов просто спонтанно узнают детали контракта на RGB-ассет по электронной почте или в Twitter, и форма очень непринужденная.

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

Рассмотрев вышеуказанный процесс, несложно заметить, что данные, получаемые и хранимые различными клиентами RGB, часто независимы, и часто вы не знаете, какие активы есть у других и сколько они составляют. Следовательно, другие, в свою очередь, в основном не знают статус ваших активов.

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

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

Но недостатки оригинального протокола RGB все же очевидны. Во-первых, каждая транзакция требует многократного взаимодействия между двумя сторонами. Принимающая сторона должна сначала проверить источник активов отправителя, а затем отправить квитанцию для подтверждения запроса отправителя на перевод. Во время этого процесса между двумя сторонами должно быть передано не менее трех сообщений. Этот вид «интерактивного перевода» серьезно несовместим с «неинтерактивным переводом», к которому привыкло большинство людей. Можете ли вы себе представить, что когда кто-то хочет перевести вам деньги, он должен отправить вам данные транзакции для проверки. Могут ли они завершить процесс перевода только после получения вашего сообщения о получении? (Блок-схему можно увидеть в предыдущей статье)

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

Относительно вышеуказанных проблем решение RGB++ заключается в том, чтобы позволить пользователям свободно переключаться между режимом самостоятельной проверки клиента и режимом хостинга у сторонних лиц. Пользователи могут оставить бремя проверки и хранения данных, хостинга смарт-контрактов и т. д. на CKB. Конечно, пользователи должны быть оптимистичны и доверять тому, что CKB, общедоступная цепь POW, надежна; если у некоторых людей есть более высокие запросы к безопасности и конфиденциальности, например, крупные инвесторы с большими объемами активов, они также могут вернуться к исходному режиму RGB. Здесь следует подчеркнуть, что RGB++ и исходный протокол RGB теоретически совместимы друг с другом.

(Диаграмма взаимодействия протокола RGB++ [краткая версия])

в предыдущих статьях"От RGB до RGB++: Как CKB усиливает протокол экологического актива Биткойн"Мы кратко популяризировали "изоморфное связывание" RGB++. Здесь мы быстро рассмотрим:

CKB имеет свой собственный расширенный UTXO под названием Cell, который более программируем, чем UTXO в цепочке BTC. «Изоморфная привязка» заключается в том, чтобы использовать ячейку в цепочке CKB в качестве «контейнера» для данных ресурса RGB и записывать ключевые параметры ресурса RGB в ячейку.

Поскольку существует привязывающее отношение между RGB активами и Bitcoin UTXO, логическая форма актива обладает характеристиками UTXO. andCell, который также обладает характеристиками UTXO, естественно подходит в качестве «контейнера» для RGB активов. Когда происходит транзакция с RGB активом, соответствующий контейнер Cell также может показать аналогичные характеристики, как отношение между сущностями и тенями. Это суть «изоморфного связывания».

Например, если у Алисы есть 100 токенов RGB и UTXO A на цепочке Биткойн, а также есть ячейка на цепочке CKB, то эта ячейка помечена как "Баланс токенов RGB: 100", а условия разблокировки связаны с UTXO A.

Если Алиса хочет отправить 30 токенов Бобу, она может сначала создать Обязательство. Соответствующее утверждение: перевести 30 токенов RGB, связанных с UTXO A, Бобу, и перевести 70 на другие UTXO, которыми она управляет.

Позже Алиса тратит UTXO A на цепочке Биткойна, публикует вышеприведенное заявление, а затем инициирует транзакцию на цепочке CKB для потребления контейнера Cell, несущего 100 токенов RGB, и генерирует два новых контейнера, один из которых содержит 30 токенов (для Боба), а другой - 70 токенов (контролируемый Алисой). В этом процессе задача проверки действительности активов у Алисы и действительности заявления о транзакции завершается узлами сети CKB путем консенсуса, без вмешательства Боба. CKB теперь действует как уровень проверки и уровень DA под цепочкой Биткойна.

Это похоже на то, что каждый раз, когда меняется статус контракта Ethereum ERC-20, пользователю не нужно запускать верификацию клиента. Принцип аналогичен. Протокол консенсуса и сеть узлов заменяют верификацию клиента. Более того, данные об активах RGB хранятся в цепочке CKB, которая поддается глобальной проверке, что способствует реализации сценариев Defi, таких как пулы ликвидности и протоколы залога активов.

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

Конечно, если кто-то хочет самостоятельно запустить клиент RGB++ и проверить исторический источник активов других людей, он может напрямую проверить историю, связанную с контейнером активов RGB на цепи CKB. Пока вы запускаете узел CKB и получаете доказательства Merkle и заголовки блоков CKB, вы можете быть уверены, что исторические данные, которые вы получаете, не были подделаны злоумышленниками в сети. Можно сказать, что CKB действует как слой хранения исторических данных здесь.

Простыми словами, Изоморфное связывание применимо не только к RGB, но и к различным протоколам активов с характеристиками UTXO, таким как Runes и Atomic., оно передает все статусы активов, исторические данные и соответствующие смарт-контракты, хранящиеся локально на клиенте пользователя, на общедоступные цепочки UTXO, такие как CKB или Cardano для хранения и размещения. Упомянутый выше протокол активов UTXO может использовать модель UTXO CKB или Cardano в качестве «контейнера» для отображения формы и статуса актива. Это удобно сотрудничать с сценариями, такими как смарт-контракты.

По протоколу изоморфной привязки пользователи могут напрямую использовать свои учетные записи Bitcoin для управления своими контейнерами RGB-активов на цепях UTXO, таких как CKB, без пересечения цепи. Вам нужно только использовать функцию UTXO Cell, чтобы установить условия разблокировки контейнера Cell, связанного с определенным адресом Bitcoin/Bitcoin UTXO. Поскольку мы уже объяснили характеристики Cell в предыдущей популярной научной статье RGB++ от Geekweb3, мы здесь не будем вдаваться в детали.

Если обе стороны, участвующие в транзакциях с активами RGB, могут доверять безопасности CKB, им даже не придется часто выпускать обязательства на цепочке Биткойн. После того как будет совершено много переводов RGB, обязательство можно отправить на цепочку Биткойн. Это называется функцией "свертывания транзакции". Может снизить затраты на использование.

Однако следует отметить, что для «контейнера», используемого в изоморфной привязке, часто требуется публичная цепочка, поддерживающая модель UTXO, или инфра с аналогичными характеристиками в хранении состояний, а цепочка EVM явно не подходит, и возникнут проблемы с технической реализацией. Столкнулся со многими подводными камнями. Прежде всего, как упоминалось ранее, RGB++ «может оперировать контейнерами активов в цепочке CKB без кроссчейна», что в принципе невозможно реализовать на цепочке EVM; Даже если она будет реализована принудительно, стоимость может быть очень высокой;

Кроме того, в протоколе RGB++ многим людям не нужно запускать клиент или хранить данные активов локально. Если для записи баланса активов каждого человека в этом контракте используется метод ERC-20, и кто-то хочет вернуться к режиму самопроверки клиента и предлагает проверить источник активов кого-то, в этот момент ему может потребоваться сканирование всех записей транзакций, взаимодействующих с контрактами активов, что приведет к огромному давлению.

Чтобы сказать прямо, контракты активов, такие как ERC-20, связывают и хранят статус активов каждого. Если вы хотите индивидуально проверить историю изменения активов одного из них, это станет сложным. Как и в общедоступной чат-комнате, если вы хотите узнать, кто отправлял сообщения Ван Гану, вам придется перелистывать записи сообщений во всей чат-комнате. UTXO похоже на частный чат один на один, и легко проверить историю.

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

1. Используйте модель UTXO или аналогичную схему хранения состояния;
2. Имеет значительную программу UTXO, позволяющую разработчикам писать скрипты разблокировки;
3. Существует пространство состояний, связанных с UTXO, в котором можно хранить статус актива;
4. Есть мосты или легкие узлы, связанные с Биткойном;

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

В настоящее время блокировочный скрипт UTXO на CKB является программируемым, и официально также совместим с схемами подписи различных публичных цепочек. Для изоморфного привязывания сеть CKB в основном соответствует вышеуказанным характеристикам. Что касается других UTXO-основанных публичных цепочек? Мы провели предварительную проверку Fuel и Cardano и считаем, что теоретически они могут поддерживать изоморфное привязывание.

Топливо: Ethereum OP Rollup на основе UTXO

Fuel - это Ethereum OP Rollup, основанный на UTXO, и является первопроходцем во введении концепции доказательства мошенничества в экосистему Ethereum Layer 2. Для поддержки нормальной функции UTXO Fuel в основном согласуется с BTC.

Fuel делит свои внутренние UTXO на следующие три категории:

Входная монета: Стандартный UTXO, используемый для представления пользовательских активов, имеет встроенный временной замок и позволяет пользователям писать предикаты разблокировки скрипта;

Входной контракт: UTXO, используемый для вызовов контрактов, содержит данные, такие как корень состояния контракта и активы контракта;

Вводное сообщение: UTXO, используемое для передачи информации, в основном содержит поля, такие как получатель информации;

Когда пользователь тратит UTXO, производится следующий вывод:

Output Coin: Для стандартных переводов активов;

Выходной контракт: Выход, сгенерированный внутренним взаимодействием контракта, содержит корень состояния после взаимодействия с контрактом;

Созданный контракт вывода: Особый UTXO - это вывод, создаваемый при создании контракта, который содержит идентификатор и корень состояния контракта;

В отличие от ячейки CKB, которая содержит все состояния контракта внутри, UTXO Fuel фактически не несет все состояния контракта, связанные с транзакциями. Fuel несет только корень состояния контракта Stateroot в UTXO, который является корнем дерева состояний. Полное состояние контракта хранится внутри библиотеки состояний Fuel и принадлежит смарт-контракту.

Следует отметить, что в отношении обработки статуса смарт-контрактов контракт Fuel и контракт на языке Solidity идеологически согласованы и даже относительно близки по программной форме. На рисунке ниже показан контракт счетчика, написанный на языке Sway Fuel. Контракт содержит счетчик. Когда пользователь вызывает функцию increment_counter, счетчик, хранящийся в контракте, увеличивается на 1.

Мы видим, что логика написания контракта Sway похожа на логику общего контракта Solidity. Сначала мы даём ABI контракта, затем переменные состояния контракта, а затем конкретную реализацию контракта. Весь процесс написания кода не включает в себя систему UTXO Fuel.

Поэтому опыт программирования контрактов Fuel отличается от языков программирования UTXO, таких как CKB и Cardanao. Fuel предоставляет опыт, близкий к программированию и разработке умных контрактов EVM. Разработчики также могут использовать язык Sway для построения сценариев разблокировки, чтобы реализовать логику специальной верификации алгоритма подписи или сложной логики многократной разблокировки.

В принципе возможно реализовать изоморфное связывание в рамках Fuel, но всё ещё есть следующие проблемы:

Язык привязки, используемый Fuel, ближе к цепочке EVM по конструкции смарт-контрактов, чем к BTC или CKB, а также Cardano. Эмитенты UTXO-активов, таких как RGB и Atomics, должны специально создавать смарт-контракт на Fuel. CKB и другие цепочки используют другой, что довольно сложно.

Cardano: публичная цепь eUTXO на основе POS

Cardano - еще одна блокчейн-система, использующая модель UTXO, но, в отличие от Fuel, это общедоступная цепь уровня 1. Cardano использует eUTXO (расширенная UTXO) для обозначения модели программирования UTXO в своей системе. По сравнению с CKB, eUTXO в Cardano содержит следующие структуры:

Сценарий: Умные контракты используются для проверки того, может ли UTXO быть разблокирован и осуществлять переходы состояний;

Редимеры: Данные, предоставленные пользователями для разблокировки UTXO, обычно представляют собой данные подписи, аналогичные Witness Bitcoin;

Данные: Пространство состояний смарт-контрактов может хранить данные, такие как статус активов;

Контекст транзакции: Контекстуальные данные для транзакций UTXO, такие как входные параметры и результаты транзакции (Процесс вычисления транзакции цепочки UTXO выполняется непосредственно вне цепочки, и результаты вычислений представляются цепочке для верификации. Если они проходят верификацию, результаты транзакции загружаются в цепочку)

Разработчики могут использовать язык PlutusCore для программирования UTXO на цепочке Cardano. Подобно CKB, разработчики могут писать скрипты разблокировки и некоторые функции для обновления статуса.

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

Для реализации вышеуказанного процесса аукциона некоторые состояния должны быть сохранены в UTXO умного контракта аукциона, такие как самая высокая цена текущего аукциона и человек, сделавший ставку. На рисунке ниже показано состояние внутри PlutusCore. Мы видим, что bBidder и bAmount отображают ставку на аукцион и адрес кошелька, который сделал ставку. Параметры аукциона содержат базовую информацию об аукционе.

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

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

Суммировать

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

1. Используйте модель UTXO
2. Имеет значительную программу UTXO, позволяющую разработчикам писать скрипты разблокировки
3. Существует пространство состояний, связанное с UTXO, которое может хранить статус актива
4. Он может поддерживать запуск узлов Bitcoin через смарт-контракты или другие средства.

Из-за особенности своих идей программирования умных контрактов, Fuel совместим с изоморфным связыванием, но это все равно приносит некоторые неудобства; в то время как Cardano использует язык программирования Haskell для программирования контрактов, что затрудняет быстрый старт для большинства разработчиков. Исходя из вышеизложенных причин, CKB, который принимает набор инструкций RISC-V и более сбалансирован в характеристиках UTXO программирования, может быть слоем расширения функций, более подходящим для изоморфного связывания.

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

1. Эта статья перепечатана из [Web3 Гик].Пересылайте оригинальный заголовок «RGB++ и изоморфное связывание: CKB, Cardano и Fuel, как они усиливают экосистему биткойна». Все авторские права принадлежат оригинальному автору [Shew]. Если у вас есть возражения к этому повторному изданию, пожалуйста, свяжитесь с Gate Учитькоманда, и они незамедлительно разберутся с этим.
2. Отказ от ответственности: Мнения и взгляды, высказанные в этой статье, являются исключительно мнением автора и не являются инвестиционной рекомендацией.
3. Переводом статьи на другие языки занимается команда Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.