Пользовательский опыт кросс-транзакций между L2

Сейчас существует все более детальный план доработки пользовательского опыта межсетевого взаимодействия, который включает в себя краткосрочную и долгосрочную части. Здесь я расскажу о краткосрочной части: идеи, которые теоретически можно внедрить уже сегодня.

Основные идеи заключаются в (i) встроенных кросс-L2 отправках и (ii) специфичных для цепей адресах и запросах на оплату. Ваш кошелек должен быть в состоянии предоставить вам адрес, который (в соответствии со стилем этот черновик ERC) выглядит так:

0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045@optimism.eth

Когда кто-то (или какое-либо приложение) предоставляет вам адрес в таком формате, вы должны иметь возможность вставить его в поле «получателя» кошелька и нажать «отправить». Кошелек должен автоматически обработать эту транзакцию любым доступным способом:

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

Макет возможного интерфейса кошелька с поддержкой кросс-цепочечного адреса

Вышеуказанное предназначено для «вы копируете и вставляете адрес (или ENS, например, vitalik.eth@optimism.eth) для того, чтобы кто-то вам заплатил». Если децентрализованное приложение запрашивает депозит (например, см. этот пример Polymarket) затем идеальным решением будет расширение веб-интерфейса API и предоставление возможности dapp сделать запрос на платеж, специфичный для цепочки. Ваш кошелек сможет удовлетворить этот запрос любым необходимым способом. Чтобы обеспечить хорошую пользовательскую работу, также необходимо стандартизировать запрос getAvailableBalance, и кошельки должны внимательно подумать, на каких цепочках хранить активы пользователей по умолчанию, чтобы обеспечить максимальную безопасность и удобство переводов.

Запросы на оплату, специфичные для цепочки, также могут быть внесены в QR-коды, которые мобильные кошельки могут сканировать. В сценарии потребительских платежей лично (или в Интернете) получатель может создать QR-код или вызов веб-интерфейса 3, который говорит: "Я хочу X единиц токена Y на цепочке Z, с идентификатором ссылки или обратным вызовом W", и кошелек может свободно удовлетворить этот запрос любым доступным способом. Другой вариант - это протокол ссылки на претензии, где кошелек пользователя создает QR-код или URL, который содержит разрешение на получение определенного количества средств из их ончейн-контракта, и это задача получателя выяснить, как затем переместить эти средства в свой собственный кошелек.

Другая связанная тема — это оплата газа. Если вы получаете активы на L2, где у вас еще нет ETH, и вам нужно отправить транзакцию на этом L2, кошелек должен автоматически использовать протокол (например,RIP-7755) чтобы оплатить газ на цепочке, где у вас есть ETH. Если кошелек ожидает, что вы будете делать больше транзакций на этом L2 в будущем, он также должен просто использовать DEX, чтобы отправить, например, несколько миллионов газа в ETH, чтобы будущие транзакции могли тратить газ прямо там (так дешевле).

Безопасность учетной записи

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

Опечатка «mistakles» слева была непреднамеренной. Однако, увидев это, я понял, что она идеально подходит для контекста, поэтому решил оставить ее.

Мое предпочтенное решение этой проблемы, длязакончилсядесятьгоды, были социальное восстановление и мультиподписные кошельки, с градуированным контролем доступа. Учетная запись пользователя имеет два уровня ключей: основной ключ и N стражей (например, N = 5). Основной ключ способен выполнять операции с низкой стоимостью и неприносящие доход. Для выполнения высокоценных операций, например, отправки всей суммы на счете, или изменения основного ключа или любого из стражей, требуется большинство стражей. По желанию основному ключу можно разрешить выполнять высокоценные операции с временной блокировкой.

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

Кто или что должны быть опекуны?

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

Второй вариант — институциональные опекуны: фирмы, которые специализируются на выполнении услуги по подписанию транзакции только в том случае, если они получают какое-либо другое подтверждение того, что запрос поступает от вас: например. код подтверждения, а для особо ценных пользователей — видеозвонок. Люди пытались сделать их в течение долгого времени, например. Я профилировал CryptoCorp в 2013 году. Однако до сих пор такие фирмы не были очень успешными.

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

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

К счастью, у нас есть четвертый вариант с ZK-SNARKs: ZK-обернутые централизованные идентификаторы. Этот жанр включает в себя zk-email, Anon Aadhaar, Myna кошелек, а также многие другие. В основном, вы можете взять множество форм (корпоративных или государственных) централизованных идентификаторов и превратить их в адреса Ethereum, с которых вы можете отправлять транзакции, сгенерировав доказательство владения централизованным идентификатором ZK-SNARK.

С этим дополнением у нас теперь есть широкий набор вариантов, и централизованный идентификатор с оберткой ZK уникально «дружелюбен к новичкам».

Для того, чтобы это работало, необходимо реализовать это с совмещенным и интегрированным пользовательским интерфейсом: вы должны иметь возможность просто указать, что вы хотите "example@gmail.com« в качестве хранителя, и он должен автоматически генерировать соответствующий адрес Ethereum zk-email под капотом. Опытные пользователи должны иметь возможность ввести свой адрес электронной почты (вместе, возможно, с солью для конфиденциальности, которая будет сохранена в этой почте) в стороннее приложение с открытым исходным кодом и подтвердить, что сгенерированный адрес правильный. То же самое должно быть верно для любого другого поддерживаемого типа хранителя.

Макет возможного интерфейса Safe

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

Новые пользователи и кошельки в приложении

Новым пользователям реалистично не захочется вводить большое количество опекунов при своем первом опыте регистрации. Поэтому кошельки должны предложить им очень простой вариант. Один из естественных путей - использование 2 из 3 с использованием zk-email на их адрес электронной почты, ключ, хранящийся локально на устройстве пользователя (который может быть ключом доступа) и резервным ключом, хранимым провайдером. По мере того, как пользователь становится более опытным или накапливает больше активов, в какой-то момент ему должно быть предложено добавить больше опекунов.

Кошельки, интегрированные в приложения, неизбежны, потому что приложения, пытающиеся обратиться к пользователям, не имеющим отношения к криптовалютам, не хотят сбивать с толку, предлагая своим пользователям загрузить два новых приложения (само приложение и кошелек Ethereum) одновременно. Тем не менее, пользователь многих прикладных кошельков должен иметь возможность связать все свои кошельки вместе, чтобы у него была только одна «вещь контроля доступа», о которой нужно беспокоиться. Самый простой способ сделать это — иерархическая схема, где существует быстрый процесс «связывания», который позволяет пользователю установить свой основной кошелек на хранителя всех своих кошельков в приложении. Клиент Farcaster Warpcast уже поддерживает это:

По умолчанию восстановление вашей учетной записи Warpcast контролируется командой Warpcast. Однако вы можете «захватить суверенитет» над своей учетной записью Farcaster и изменить восстановление на свой собственный адрес.

Защита пользователей от мошенничества и других внешних угроз

Помимо безопасности учетной записи, сегодня кошельки делают многое для идентификации поддельных адресов, рыбной ловли, мошенничества и других внешних угроз, а также стараются защитить своих пользователей от таких угроз. В то же время многие противодействия все еще довольно примитивны: например, для отправки ETH или других токенов на любой новый адрес требуется клик, независимо от того, отправляете ли вы $100 или $100 000. Здесь нет единого магического решения; это серия медленных постоянных устранений и улучшений различных категорий угроз. Однако в продолжении трудной работы по улучшению здесь есть много ценности.

Конфиденциальность

Сейчас пришло время начать относиться к конфиденциальности на Ethereum гораздо серьезнее. Технология ZK-SNARK теперь очень продвинута, конфиденциальные технологии, которые смягчают регуляторные риски, не полагаясь на задние двери, такие как Пулы конфиденциальности, становятся более зрелыми, а вторичная инфраструктура, такая как Wakuи пулы памяти ERC-4337 становятся все более стабильными. Однако до сих пор для осуществления частных переводов на Ethereum пользователям требовалось явно скачивать и использовать «кошелек конфиденциальности», такой как Железная дорога (или Теньдляскрытые адреса). Это создает большие неудобства и сокращает количество людей, готовых осуществлять частные переводы. Решением является интеграция приватных переводов непосредственно в кошельки.

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

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

Одним из преимуществ этой техники является естественный путь не только к передаче активов с сохранением конфиденциальности, но и к сохранению конфиденциальности личности. Уже существует идентификация на основе blockchain: любое приложение, которое использует вход на основе доказательства личности (например, Gitcoin Grants), любой чат с токеном-входом и т.д.Ethereum Следует Протоколу, и многое другое являются идентификацией на блокчейне. Мы хотим, чтобы этот экосистема также обеспечивала конфиденциальность. Это означает, что действия пользователя на блокчейне не должны собираться в одном месте: каждый элемент должен храниться отдельно, и кошелек пользователя должен быть единственным, что видит все ваши удостоверения одновременно. Экосистема с возможностью множества аккаунтов на пользователя помогает в этом, а также протоколы аттестации вне блокчейна, такие как EASиZupass.

Это представляет собой прагматичное видение конфиденциальности Ethereum в среднесрочной перспективе. Это может быть реализовано уже сегодня, хотя существуют функции, которые могут быть внедрены на уровне L1 и L2, чтобы сделать сохранение конфиденциальности трансферов более эффективным и надежным. Некоторые сторонники конфиденциальности утверждают, что единственно приемлемым является полная конфиденциальность всего: шифрование всего EVM. Я бы возразил, что это может быть идеальным долгосрочным результатом, но для этого требуется гораздо более фундаментальное переосмысление моделей программирования, и на данный момент это не находится на том уровне зрелости, когда оно готово к использованию и развертыванию по всей сети Ethereum. Нам нужна конфиденциальность по умолчанию, чтобы получить достаточно большие наборы анонимности. Однако, сосредотачиваясь сначала на совершении (i) трансферов между счетами и (ii) использовании личности и смежных с личностью случаях использования, таких как удостоверения, как прагматичный первый шаг, который гораздо проще реализовать и с которым кошельки могут приступить уже сегодня.

Кошельки Ethereum также должны стать кошельками данных

Одним из последствий любого эффективного решения проблемы конфиденциальности, будь то для платежей, идентификации или других случаев использования, является необходимость для пользователя хранить данные вне цепочки. Это было очевидно в Tornado Cash, который требовал от пользователей сохранять каждую отдельную «заметку», представляющую депозит на 0,1-100 эфиров. Более современные протоколы конфиденциальности иногда сохраняют данные в зашифрованном виде в цепочке и используют один частный ключ для их расшифровки. Это рискованно, потому что если ключ когда-либо утекает или если квантовые компьютеры когда-либо станут выполнимыми, все данные становятся общедоступными. Внебиржевые удостоверения, такие как EAS и Zupass, имеют еще более очевидную необходимость в хранении данных вне цепочки.

Кошельки должны стать не только программными средствами для хранения разрешений доступа к onchain, но и программными средствами для хранения ваших личных данных. Это то, что не криптовалютный мир все больше признает, например, см. Тим Бернерс-Ли.последние работы в личных хранилищах данных. Все проблемы, которые нам нужно решить вокруг надежного обеспечения контроля доступа, нам также нужно решить вокруг надежного обеспечения доступности и нелегкости данных. Возможно, решения могли бы быть наложены вместе: если у вас есть N хранителей, используйте секретное разделение M-of-N между теми же N хранителями, чтобы хранить ваши данные. Данные по своей природе сложнее обеспечить, потому что вы не можете отозвать чей-то долю, но мы должны создать децентрализованные решения опеки, которые будут такими же надежными, как мы можем.

Безопасный доступ к цепочке

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

1. Провайдер RPC может попытаться украсть деньги, предоставив им ложную информацию, например, о рыночных ценах
2. Поставщик RPC может извлекать частную информацию о том, с какими приложениями и другими учетными записями взаимодействует пользователь

Идеально, мы хотим залатать оба этих дырки. Чтобы запломбировать первую, нам нужны стандартизированные легкие клиенты для L1 и L2, которые непосредственно проверяют консенсус блокчейна.Гелиосуже делает это для L1 и проделал некоторую предварительную работу по поддержке некоторых конкретных L2. Чтобы полностью охватить все L2, нам нужен стандарт, по которому контракт конфигурации, представляющий L2 (также используется для адресов, специфичных для цепочки), может объявить функцию, возможно, аналогичным образом.ERC-3668содержащий логику получения последних корней состояния и проверку доказательств состояния и квитанций по отношению к этим корням состояния. Таким образом, мы можем иметь универсального легкого клиента, позволяющего кошелькам безопасно проверять любое состояние или события на L1 и L2.

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

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

PIR очень ресурсоемкий. У этой проблемы есть несколько путей обхода:

• Brute force: improvements in algorithms, or specialized hardware, could potentially make PIR fast enough to run. These techniques may depend on pre-processing: servers could store encrypted-and-shuffled data for each client, and clients could query that data. The main challenge in the Ethereum setting is adapting these techniques to datasets that change rapidly (as the state does). This makes real-time computational costs lower, but may well make total computational and storage costs higher.
• Ослабление требования конфиденциальности: например, каждый поиск может иметь только 1 миллион "миксинов", поэтому сервер будет знать миллион возможных значений, к которым мог бы обратиться клиент, но не более точную гранулярность
• Многопользовательский PIR: алгоритмы PIR часто работают намного быстрее, если вы используете несколько серверов с предположением честности 1 из N между этими серверами.
• Анонимность вместо конфиденциальности: вместо скрытия содержимого запроса запрос может быть отправлен через микснет, скрывая отправителя запроса. Однако это эффективно неизбежно увеличивает задержку, ухудшая пользовательский опыт.

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

Идеальные кошельки для хранения ключей

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

1. Повторенные обновления: когда пользователь изменяет свою конфигурацию, сообщение, разрешающее этот изменение, повторяется на каждой цепи, где кошелек обнаруживает, что у пользователя есть активы. Потенциально формат сообщения и правила валидации могут быть сделаны независимыми от цепи, чтобы они могли автоматически повторяться на максимальном количестве цепей.
2. Keystores на L1: информация о конфигурации находится на L1, и кошелек на L2 считывает ее с помощьюL1SLOADилиREMOTESTATICCALL. Таким образом, обновление конфигурации должно быть выполнено только на L1, и конфигурация становится действительной автоматически.
3. Keystores on L2: информация о конфигурации хранится на уровне L2, а кошелек на уровне L2 считывает её с помощью ZK-SNARK. Это то же самое, что и (2), за исключением того, что обновления хранилища ключей могут быть дешевле, хотя с другой стороны чтение обходится дороже.

Решение (3) особенно мощно, потому что хорошо сочетается с конфиденциальностью. В обычном «конфиденциальном решении» пользователь имеет секрет s, на цепи публикуется «листовое значение» L, и пользователь доказывает, что L = hash(s, 1) и N = hash(s, 2) для некоторого (не раскрытого) секрета, которым он управляет. Нулевой элемент N публикуется, чтобы гарантировать, что будущие расходы с тем же листом не удастся осуществить, не раскрывая L. Это зависит от сохранения пользователем s в безопасности. Конфиденциальное решение, поддерживающее восстановление, вместо этого будет говорить: s - это местоположение (например, адрес и слот хранения) на цепи, и пользователь должен доказать запрос состояния: L = hash(sload(s), 1).

Безопасность Dapp

Самое слабое место в безопасности пользователя часто является dapp. Большую часть времени пользователь взаимодействует с приложением, переходя на веб-сайт, который неявно загружает код пользовательского интерфейса в режиме реального времени с сервера, а затем выполняет его в браузере. Если сервер взломан или DNS взломан, пользователь получит поддельную копию интерфейса, которая может обмануть пользователя и заставить делать произвольные действия. Функции кошелька, такие как симуляции транзакций, очень полезны для снижения рисков, но они далеки от совершенства.

Идеальным вариантом было бы перенести экосистему на версионирование контента on-chain: пользователь получил бы доступ к dapp через его имя ENS, которое содержало бы IPFS-хеш интерфейса. Для обновления интерфейса потребовалась бы onchain-транзакция от multisig или DAO. Кошельки показали бы пользователям, взаимодействуют ли они с более безопасным onchain-интерфейсом или менее безопасным веб-интерфейсом web2. Кошельки также могут показать пользователям, взаимодействуют ли они с безопасной цепью (например, этап 1+, множественные проверки безопасности).

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

Макет возможного интерфейса для режима паранойи

Более продвинутым подходом будет перейти за пределы HTML + Javascript и написать бизнес-логику dapps на специализированном языке, возможно, относительно тонком наложении на Solidity или Vyper. Затем браузеры могут автоматически генерировать пользовательский интерфейс для любой необходимой функциональности.OKContract уже делает это.

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

Долгосрочное будущее

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

• ИИ, который мог бы привести нас к отходу от парадигмы «нажми и введи», к парадигме «скажи, что ты хочешь сделать, и бот разберется в этом».
• Интерфейсы мозг-компьютер, как «мягкие» подходы, такие как айтрекинг, так и более прямые и даже инвазивные методы (см.: первый пациент Neuralink в этом году)
• Клиенты, занимающиеся активной защитой: браузер Braveактивно защищает пользователей от рекламы, трекеров и многих других нежелательных объектов. Многие браузеры, плагины и криптокошельки имеют целые команды, активно работающие над защитой пользователей от всех видов угроз безопасности и конфиденциальности. Такие «активные стражи» станут еще более мощными в следующем десятилетии.

Эти три тенденции вместе приведут к гораздо более глубокому переосмыслению того, как работают интерфейсы. С помощью ввода естественного языка, отслеживания глаз или, в конечном итоге, более прямого BCI, вместе со знанием вашей истории (возможно, включая текстовые сообщения, при условии, что все данные обрабатываются локально), «кошелек» может получить четкое интуитивное представление о том, что вы хотите сделать. Затем ИИ может перевести эту интуицию в конкретный «план действий»: серию ончейн- и офчейн-взаимодействий, которые достигают того, что вы хотите. Это может значительно снизить потребность в сторонних пользовательских интерфейсах. Если пользователь взаимодействует со сторонним приложением (или другим пользователем), ИИ должен действовать от имени пользователя, выявлять любые угрозы и предлагать планы действий по их предотвращению. В идеале должна существовать открытая экосистема этих ИИ, создаваемых разными группами с разными предубеждениями и структурами стимулов.

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

Отказ:

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