обзор

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

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

на данный момент поддерживают интроспекцию только три основных операционных кода в скриптовании биткойна: checklocktimeverify, checksequenceverify и checksig, а также их варианты checksigverify, checksigadd, checkmultisig и checkmultisigverify.

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

bitcoin в настоящее время имеет два ковенанта, csv (checksequenceverify) и cltv (checklocktimeverify), оба из которых основаны на времени и являются основополагающими для многих масштабируемых решений, таких как молниеносная сеть. Это показывает, как масштабируемые решения Bitcoin сильно полагаются на внутреннюю оценку и ковенанты.

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

ниже мы опишем широко обсуждаемое предложение по операции кода ковенанта.

ctv (checktemplateverify) bip-119

ctv (checktemplateverify) - это предложение по обновлению биткойна, содержащееся в bip-119, которое вызвало значительное внимание со стороны сообщества. ctv позволяет выходному скрипту указывать шаблон для расходования средств в транзакции, включая поля, такие как nversion, nlocktime, scriptsig hash, input count, sequences hash, output count, outputs hash, input index. Эти ограничения шаблона реализуются с помощью хэш-коммита, и при расходовании средств скрипт проверяет, совпадают ли хэш-значения указанных полей в транзакции расходования с хэш-значениями во входном скрипте. Это эффективно ограничивает время, метод и сумму будущих транзакций этого UTXO.

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

ctv реализует интроспекцию, путем непосредственного извлечения указанной информации о транзакции для хеширования и сравнения ее с фиксацией в стеке. Этот метод интроспекции менее требователен к месту на цепочке, но лишен некоторой гибкости.

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

ctv была изначально предложена для смягчения перегрузки в биткойне, которая также может называться контролем перегрузки. Во время высокой перегрузки ctv может обязаться к нескольким будущим транзакциям в рамках одной транзакции, избегая необходимости трансляции нескольких транзакций в период пиковой нагрузки и завершая фактические транзакции, когда перегрузка снижается. Это может быть особенно полезно во время банковских ран. Кроме того, шаблон также может использоваться для реализации сейфов для защиты от хакерских атак. Поскольку направление средств заранее определено, хакеры не могут направлять utxo, используя ctv-скрипты, на свои собственные адреса.

ctv может значительно улучшить сети второго уровня. Например, в сети Lightning ctv может позволить создание деревьев таймаутов и фабрик каналов, преобразовав один utxo в дерево ctv, открывая несколько состояний каналов всего одной транзакцией и одним подтверждением. Более того, ctv также поддерживает атомарные сделки в протоколе ark через atlc.

apo (sighash_anyprevout) bip-118

bip-118 представляет новый тип флага хеш-подписи для tapscript, направленный на облегчение более гибкой логики расходования, известной как sighash_anyprevout. apo и ctv имеют много общего. При решении циклической проблемы между scriptpubkeys и txids подход apo заключается в исключении соответствующей информации об исходных данных и подписи только выходов, что позволяет транзакциям динамически привязываться к различным utxo.

логически, операция проверки подписи op_checksig (и его варианты) выполняет три функции:

1. сборка частей тратящейся транзакции.
2. хеширование их.
3. проверка того, что хеш был подписан заданным ключом.

специфика подписи имеет много гибкости, принимая решение о том, какие поля транзакции подписывать, определяется флагом sighash. в соответствии с определением опкодов подписи в bip 342 флаги sighash разделены на sighash_all, sighash_none, sighash_single и sighash_anyonecanpay. sighash_anyonecanpay управляет входами, а остальные управляют выходами.

sighash_all - это флаг по умолчанию для sighash, который подписывает все выходы; sighash_none не подписывает ни одного выхода; sighash_single подписывает конкретный выход. sighash_anyonecanpay может быть установлен с помощью первых трех флагов sighash. Если установлен флаг sighash_anyonecanpay, будет подписан только указанный вход; в противном случае должны быть подписаны все входы.

Ясно, эти флаги sighash не устраняют влияние входов, даже sighash_anyonecanpay, который требует привязки к одному входу.

Таким образом, bip 118 предлагает sighash_anyprevout. Подпись apo не должна фиксироваться на потраченном входе utxo (известном как prevout), а только должна подписывать выходы, обеспечивая большую гибкость в управлении биткойн. Предварительное построение транзакций и создание соответствующих одноразовых подписей и открытых ключей позволяет отправлять активы на этот адрес открытого ключа только через предварительно построенную транзакцию, таким образом реализуя договор. Гибкость apo также может использоваться для ремонта транзакций; если транзакция застряла в цепочке из-за низких комиссий, можно легко создать другую транзакцию для увеличения комиссии без необходимости новой подписи. Кроме того, для мультиподписных кошельков операции становятся более удобными, так как они не зависят от потраченных входов.

поскольку это устраняет цикл между scriptpubkeys и input txids, apo может выполнять интроспекцию, добавляя выходные данные в witness, хотя это все равно требует дополнительного расхода места для witness.

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

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

op_vault bip-345

BIP-345 предлагает добавление двух новых опкодов, op_vault и op_vault_recover, которые в сочетании с ctv реализуют специализированный ковенант, позволяющий пользователям наложить задержку на расход конкретных монет. В течение этой задержки ранее выполненная транзакция может быть «отменена» через путь восстановления.

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

как реализует op_vault прерываемые временные блокировки вывода? op_vault достигает этого путем замены использованного сценария op_vault на указанный сценарий, эффективно обновляя один лист маст, оставляя остальные узлы листьев taproot неизменными. этот дизайн аналогичен tluv, за исключением того, что op_vault не поддерживает обновления внутреннего ключа.

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

bip-345 специально разработан для хранилищ, используя op_vault и op_vault_recover, чтобы предоставить пользователям безопасный кастодиальный метод, который использует высоконадежный ключ (такой как бумажный кошелек или распределенная мультисигнатура) в качестве пути восстановления, при этом настраивается определенная задержка для регулярных платежей. Устройства пользователей непрерывно отслеживают траты из хранилища, и если происходит неожиданный перевод, пользователи могут инициировать восстановление.

внедрение хранилища через bip-345 требует учета вопросов стоимости, особенно для операций восстановления. Возможные решения включают cpfp (child pays for parent), временные якоря и новые флаги хеш-подписей sighash_group.

tluv (tapleafupdateverify)

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

Концепция схемы tluv состоит в создании нового адреса taproot на основе текущего входа расходов за счет введения новой операции tapleaf_update_verify. Это можно достичь, выполнив одно или несколько из следующих действий:

1. обновить внутренний открытый ключ
2. обрезать путь Меркла
3. удалить текущий выполняемый скрипт
4. добавить новый шаг в конце пути Меркля

конкретно, tluv принимает три входа:

1. один, который определяет, как обновить внутренний открытый ключ.
2. тех, что определяет новый шаг для дерева Меркля.
3. то, что указывает, нужно ли удалить текущий скрипт и/или сколько шагов пути Меркля следует обрезать.

опкод tluv вычисляет обновленный scriptpubkey и проверяет, что вывод, соответствующий текущему вводу, тратится на этот scriptpubkey.

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

опкод tluv достигает ограничений на частичное использование путем обновления исходного дерева taproot, однако он не реализует интроспекцию суммы вывода. Поэтому требуется новый опкод in_out_amount. Этот опкод помещает два элемента в стек: сумму utxo для этого входа и сумму для соответствующего вывода, затем те, кто используют tluv, должны использовать математические операторы, чтобы проверить, что средства соответствующим образом сохраняются в обновленном scriptpubkey.

Внутренний анализ сумм вывода добавляет сложность, поскольку суммы в сатоши требуют до 51 бит для представления, но сценарии позволяют только 32-битные математические операции. Это требует переопределения поведения операции для обновления операторов в сценариях или использования sighash_group для замены in_out_amount.

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

матт

Мэтт (мерклизовать все вещи) стремится достичь трех целей: мерклизация состояния, мерклизация скрипта и мерклизация выполнения, тем самым обеспечивая универсальные смарт-контракты.

1. Мерклеизация состояния: это включает построение Меркле-дерева, где каждый листовой узел представляет хеш состояния, а корень Меркла олицетворяет общее состояние контракта.
2. Мерклезация скрипта: это относится к формированию мастер-узла с использованием тапскрипта, где каждый листовой узел представляет собой возможный путь перехода состояния.
3. мерклеизация выполнения: выполнение подвергается мерклеизации через криптографические обязательства и механизм оспаривания мошенничества. для любой вычислительной функции участники могут вычислять вне цепи, а затем публиковать обязательство, f(x)=y. если другие участники обнаруживают ошибочный результат, f(x)=z, они могут инициировать вызов. арбитраж проводится через бинарный поиск, аналогично принципу оптимистического роллапа.

мерклизация выполнения

для реализации мэтта язык сценариев биткойн должен иметь следующие функциональности:

1. заставить выход иметь определенный скрипт (и их суммы)
2. прикрепить к выходу кусок данных
3. прочитать данные из текущего ввода (или другого)

Второй пункт крайне важен: динамические данные означают, что состояние может быть вычислено через входные данные, предоставленные тратильщиком, поскольку это позволяет симулировать конечный автомат, способный определить следующее состояние и дополнительные данные. Схема Мэтта реализует это с помощью опкода op_checkcontractverify (op_ccv), объединяющего ранее предложенные опкоды op_checkoutputcontractverify и op_checkinputcontractverify с использованием дополнительного параметра флагов для указания цели операции.

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

Учитывая универсальность доказательств мошенничества, некоторые варианты контракта Matt должны иметь возможность реализации всех типов смарт-контрактов или конструкций уровня 2, хотя дополнительные требования (такие как блокировка капитала и задержка периода оспаривания) должны быть точно оценены; для оценки того, какие приложения допустимы для транзакций, требуется дополнительное исследование. Например, используя криптографические обязательства и механизмы оспаривания мошенничества для имитации функции op_zk_verify, можно достичь доверительных роллапов на биткоине.

На практике это уже происходит. Йохан Торос Халсет (Johan Torås Halseth) использовал op_checkcontractverify код операции из предложения Matt Soft Fork для реализации elftrace, что позволяет проверять любую программу, поддерживающую компиляцию RISC-V, на биткойн-блокчейне, позволяя стороне в рамках протокола контракта получать доступ к средствам через проверку контракта, таким образом, обеспечивая связь с биткойн-проверкой.

csfs (op_checksigfromstack)

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

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

Гибкость csfs позволяет реализовывать механизмы, такие как подписи платежей, делегирование авторизации, контракты оракулов, облигации защиты от двойных расходов и, что более важно, внутренний осмотр транзакций. Принцип использования csfs для внутреннего осмотра транзакций довольно прост: если содержимое транзакции, используемое op_checksig, помещается в стек через витрины, и одинаковый открытый ключ и подпись используются для верификации как op_csfs, так и op_checksig, и если обе проверки проходят успешно, то произвольное сообщение, переданное в op_csfs, совпадает с сериализованной тратой транзакции (и другими данными), неявно используемой op_checksig. Затем мы получаем проверенные данные транзакции в стеке, которые могут быть использованы для наложения ограничений на траты транзакций с другими опкодами.

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

csfs может реализовывать операции, такие как cltv, csv, ctv, apo и т. д., что делает его универсальным операционным кодом для интроспекции. Таким образом, он также способствует решениям масштабируемости для второго уровня биткойна. Недостатком является то, что требуется добавление полной копии подписанной транзакции в стек, что может значительно увеличить размер транзакций, предназначенных для интроспекции с использованием csfs. В отличие от одноцелевых операционных кодов для интроспекции, таких как cltv и csv, у которых минимальные накладные расходы, каждое новое специальное интроспекционное операционное кодирование требует изменений консенсуса.

txhash (op_txhash)

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

из-за сходств между txhash и ctv в сообществе возникло значительное количество обсуждений двух технологий.

txhash можно рассматривать как универсальное обновление ctv, предлагающее более продвинутый шаблон транзакции, который позволяет пользователям явно указывать части тратящей транзакции, решая множество проблем, связанных с комиссией за транзакцию. В отличие от других кодовых операций ковенанта, txhash не требует копирования необходимых данных в свидетельстве, дополнительно снижая требования к хранению; в отличие от ctv, txhash не совместим с NOP и может быть реализован только в tapscript; комбинация txhash и csfs может служить альтернативой ctv и apo.

с точки зрения создания контрактов, txhash более удобен для создания «дополнительных контрактов», где все части данных транзакции, которые вы хотите закрепить, помещаются в стек, хешируются вместе и полученный хеш проверяется на соответствие фиксированному значению; ctv более подходит для создания «вычитающих контрактов», где все части данных транзакции, которые вы хотите оставить свободными, помещаются в стек. затем, используя операцию rolling sha256, хеширование начинается с фиксированного промежуточного состояния, которое фиксирует префикс данных хеша транзакции. свободные части хешируются в это промежуточное состояние.

поле txfieldselector, определенное в спецификации txhash, ожидается расширение до других операций, таких как op_tx.

bip, связанный с txhash, в настоящее время находится в состоянии черновика на github и ему еще не присвоен номер.

op_cat

op_cat — это окутанный тайной опкод, от которого Сатоши Накамото отказался из соображений безопасности, но недавно он вызвал интенсивную дискуссию среди основных разработчиков биткоина и даже подстегнул культуру мемов в Интернете. В конечном счете, op_cat был одобрен в соответствии с BIP-347 и был назван наиболее вероятным предложением BIP в последнее время.

на самом деле, поведение op_cat довольно простое: он конкатенирует два элемента из стека. как он активирует функциональность ковенанта?

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

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

В подписях Шнорра сообщение, которое необходимо подписать, состоит из следующих полей:

эти поля содержат основные элементы транзакции. помещая их в scriptpubkey или witness и используя op_cat в сочетании с op_sha256, мы можем создать подпись Шнорра и проверить ее, используя op_checksig. если проверка проходит успешно, стек сохраняет проверенные данные транзакции, достигая транзакционной интроспекции. это позволяет извлекать и «проверять» различные части транзакции, такие как ее входы, выходы, целевые адреса или связанные суммы биткоинов.

для конкретных криптографических принципов можно обратиться к статье Эндрю Поэлстры «Кошка и трюки Шнорра».

в итоге многофункциональность op_cat позволяет ему эмулировать практически любую операцию кода ковенанта. множество операций кода ковенанта полагается на функциональность op_cat, что значительно продвигает его позицию в списке слияний. теоретически, полагаясь исключительно на op_cat и существующие операции кода биткойна, мы надеемся создать доверительный минимизированный btc zk rollup. starknet, chakra и другие партнеры экосистемы активно работают над этим.

заключение

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

без гибкого базового слоя невозможно построить более гибкий второй слой.

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

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

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

apo, op_vault и tluv склонны к прямым применениям, и их выбор может обеспечить конкретные применения более дешевым и эффективным способом. Поклонники молнии предпочли бы apo для достижения ln-симметрии; те, кто хочет реализовать хранилище, лучше всего обслужатся op_vault; для создания coinpool tluv предлагает большую конфиденциальность и эффективность. op_cat и txhash более универсальны, с меньшей вероятностью уязвимости безопасности, и могут реализовать больше случаев использования в сочетании с другими операциями, возможно, за счет сложности сценария. ctv и csfs изменили обработку блокчейна, ctv реализует отложенные выводы, а csfs - отложенные подписи. Matt выделяется своей стратегией оптимистичного выполнения и доказательств мошенничества, используя структуру мерклевого дерева для реализации универсальных умных контрактов, хотя для этого все еще требуются новые операции для внутренних возможностей.

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

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

1. эта статья взята из [Зеркало]. все авторские права принадлежат оригинальному автору [ чакра]. если есть возражения к этой публикации, пожалуйста, свяжитесь сGate учитькоманда и они быстро разберутся с этим.
2. отказ от ответственности: мнения и взгляды, выраженные в этой статье, являются исключительно мнениями автора и не являются инвестиционными советами.
3. переводы статьи на другие языки выполняются командой Gate.io learn. Если не указано иное, запрещено копирование, распространение или плагиат переведенных статей.