diff --git a/public/content/translations/ru/developers/docs/nodes-and-clients/light-clients/index.md b/public/content/translations/ru/developers/docs/nodes-and-clients/light-clients/index.md new file mode 100644 index 00000000000..4686debd6fe --- /dev/null +++ b/public/content/translations/ru/developers/docs/nodes-and-clients/light-clients/index.md @@ -0,0 +1,61 @@ +--- +title: "Легкие клиенты" +description: "Введение в легковесные клиенты Ethereum." +lang: ru +--- + +Запуск полного узла это самый надёжный, приватный, децентрализованный и устойчивый к цензуре способ взаимодействия с Ethereum. С полной нодой вы храните свою собственную копию блокчейна, к которой можно обращаться мгновенно для получения прямого доступа к одноранговой сети Ethereum. Однако, запуск полной ноды требует значительное количество памяти, место на жёстком диске и мощный процессор. Это значит, что не каждый может обслуживать свой собственный узел. Есть несколько решений, изложенных в дорожной карте Эфириума, включая клиенты без отслеживания всего состояния, но ещё потребуется несколько лет, прежде чем они будут реализованы. На ближайшее время нужно найти компромисс, чтобы пожертвовать некоторыми преимуществами использования полного узла ради значительного повышения производительности, что позволит узлам работать с очень низкими требованиями к оборудованию. Узлы, которые находят этот компромисс, называются легковесными узлами. + +## Что такое легкий клиент {#what-is-a-light-client} + +Лёгкий узел — это узел, использующий софт легковесного клиента. Вместо хранения локальных копий данных блокчейна и независимой верификации всех изменений, они запрашивают необходимые данные у отдельных провайдеров. Провайдер может быть в прямой связи с полным узлом, или через централизованный RPC сервер. Затем дата верифицируется лёгким узлом, позволяя ему оставаться синхронизированным с последним блоком в цепочке. Легковесный узел обрабатывает только заголовки блоков, скачивая полное содержимое блоков лишь на некоторое время. Узлы могут быть разными по своей «лёгкости», в зависимости от того, какие комбинации лёгкого и полновесного клиента они используют. Например, самая лёгкая конфигурация — это запуск лёгкого исполнительного клиента и лёгкого консенсусного клиента. Также вероятно, что многие узлы будут обслуживать лёгкие консенсусные клиенты в связке с полными исполнительными клиентами, и наоборот. + +## Как работают легковесные клиенты? {#how-do-light-clients-work} + +Когда Ethereum начал использовать механизм консенсуса на основе доказательства владения, была представлена новая инфраструктура специально для поддержки легковесных клиентов. Принцип работы заключается в случайном выборе подгруппы из 512 валидаторов каждые 1,1 дня, которые будут действовать как **комитет синхронизации**. Синхронизирующий комитет подписывает заголовки последних блоков. Каждый заголовок блока содержит агрегированную подпись валидаторов из комитета синхронизации и «битовое поле», которое показывает, какие валидаторы подписали, а какие нет. Каждый заголовок также включает список валидаторов, которые, как ожидается, примут участие в подписании следующего блока. Это означает, что легковесный клиент может быстро увидеть, что комитет синхронизации одобрил полученные ими данные, а также проверить подлинность комитета синхронизации, сравнив текущий комитет с тем, который ему было сказано ожидать в предыдущем блоке. Таким образом, легковесный клиент может постоянно обновлять свою информацию о последнем блоке Ethereum, фактически не загружая сам блок, а только заголовок, содержащий итоговую информацию. + +На уровне исполнения не существует единой спецификации для легковесного клиента исполнения. Область применения легковесного клиента исполнения может варьироваться от «облегченного режима» полного клиента исполнения, который обладает всеми функциями EVM и сети, как полный узел, но проверяет только заголовки блоков, не загружая связанные с ними данные, или же это может быть более упрощенный клиент, который в значительной степени полагается на пересылку запросов поставщику RPC для взаимодействия с Ethereum. + +## Почему важны легковесные клиенты? {#why-are-light-clients-important} + +Легковесные клиенты важны, поскольку они позволяют пользователям проверять входящие данные, а не слепо доверять тому, что их поставщик данных корректен и честен, используя при этом лишь малую часть вычислительных ресурсов по сравнению с полным узлом. Получаемые легковесными клиентами данные можно проверить по заголовкам блоков, которые, как известно этим клиентам, подписаны как минимум 2/3 из случайного набора 512 валидаторов Ethereum. Это очень убедительное доказательство того, что данные верны. + +Легковесный клиент использует лишь небольшое количество вычислительной мощности, памяти и хранилища, поэтому его можно запускать на мобильном телефоне, встроить в приложение или использовать как часть браузера. Легковесные клиенты — это способ сделать доступ к Ethereum с минимальным уровнем доверия таким же простым, как и при доверии стороннему провайдеру. + +Давайте рассмотрим простой пример. Представьте, что вы хотите проверить баланс своего счета. Для этого вам необходимо сделать запрос узлу Ethereum. Этот узел проверит свою локальную копию состояния Ethereum, чтобы найти ваш баланс и сказать его вам. Если у вас нет прямого доступа к узлу, то существуют централизованные операторы, которые предоставляют эти данные как услугу. Вы можете отправить им запрос, они проверят свой узел и отправят вам результат. Проблема в том, что вам приходится доверять поставщику и полагаться на то, что он предоставляет вам правильную информацию. Вы никогда не сможете быть уверены в правильности информации, пока не проверите ее самостоятельно. + +Легковесный клиент решает эту проблему. Вы по-прежнему запрашиваете данные у какого-то внешнего поставщика, но когда вы получаете данные обратно, они сопровождаются доказательством, которое ваш легковесный узел может проверить на соответствие информации, полученной из заголовка блока. Это означает, что корректность ваших данных проверяет Ethereum, а не какой-то доверенный оператор. + +## Какие новшества дают легкие клиенты? Какие инновации делают возможными легкие клиенты? {#what-innovations-do-light-clients-enable} + +Основным преимуществом легковесных клиентов является то, что они позволяют большему количеству людей получать доступ к Ethereum независимо, с незначительными требованиями к оборудованию и минимальной зависимостью от третьих лиц. Это хорошо для пользователей, поскольку они могут проверять свои собственные данные, и это хорошо для сети, поскольку увеличивает количество и разнообразие узлов, проверяющих цепочку. + +Возможность запускать узлы Ethereum на устройствах с очень малым объемом памяти и вычислительной мощности — одна из основных инноваций, которую дают легковесные клиенты. Если сегодня узлы Ethereum требуют больших вычислительных ресурсов, то легковесные клиенты могли бы быть встроены в браузеры, работать на мобильных телефонах и, возможно, даже на небольших устройствах, таких как умные часы. Это означает, что кошельки Ethereum со встроенными клиентами могли бы работать и на мобильных телефонах. Это означает, что мобильные кошельки могут быть гораздо более децентрализованными, поскольку им не придется доверять свои данные централизованным поставщикам данных. + +Расширением этой концепции является поддержка устройств **Интернета вещей (IoT)**. Легкий клиент можно использовать для быстрого подтверждения владения балансом токенов или NFT со всеми гарантиями безопасности, предоставляемыми комитетами синхронизации, что инициирует определенное действие в сети IoT. Представьте себе [сервис по прокату велосипедов](https://youtu.be/ZHNrAXf3RDE?t=929), который использует приложение со встроенным легким клиентом, чтобы быстро проверить, владеете ли вы NFT этого сервиса, и если да, то разблокировать велосипед, на котором вы сможете уехать! + +Ролл-апы Ethereum также выиграют от использования легких клиентов. Одной из серьезных проблем ролл-апов были взломы мостов, которые позволяют переводить средства из основной сети Ethereum в ролл-ап. Одна из уязвимостей — это оракулы, которые ролл-апы используют для обнаружения того, что пользователь внес депозит в мост. Если оракул передает неверные данные, он может обмануть ролл-ап, заставив его думать, что в мост был внесен депозит, и некорректно высвободить средства. Легкий клиент, встроенный в ролл-ап, может использоваться для защиты от скомпрометированных оракулов, поскольку депозит в мост может сопровождаться доказательством, которое ролл-ап сможет проверить перед высвобождением токенов. Эту же концепцию можно применить и к другим межсетевым мостам. + +Легковесные клиенты также могут использоваться для того, чтобы улучшить кошельки Ethereum. Вместо того чтобы доверять данным, предоставляемым провайдером RPC, ваш кошелек может напрямую проверять представленные вам данные с помощью встроенного легкого клиента. Это добавило бы безопасности вашему кошельку. Если ваш RPC-провайдер был нечестен и предоставил вам неверные данные, встроенный легковесный клиент мог бы сообщить вам об этом! + +## Каково текущее состояние разработки легких клиентов? {#current-state-of-development} + +В разработке находится несколько легких клиентов, включая легкие клиенты уровня исполнения, консенсуса и комбинированные легкие клиенты исполнения/консенсуса. Ниже приведены реализации легких клиентов, о которых нам известно на момент написания этой страницы: + +- [Lodestar](https://github.com/ChainSafe/lodestar/tree/unstable/packages/light-client): легкий клиент консенсуса на TypeScript +- [Helios](https://github.com/a16z/helios): комбинированный легкий клиент уровня исполнения и консенсуса на Rust +- [Geth](https://github.com/ethereum/go-ethereum/tree/master/beacon/light): легкий режим для клиента исполнения (в разработке) на Go +- [Nimbus](https://nimbus.guide/el-light-client.html): легкий клиент консенсуса на Nim + +Насколько нам известно, ни один из них еще не считается готовым к использованию в производственной среде. + +Также ведется большая работа по улучшению способов доступа легких клиентов к данным Ethereum. В настоящее время легкие клиенты полагаются на RPC-запросы к полным узлам, используя модель «клиент-сервер», но в будущем данные можно будет запрашивать более децентрализованным способом с помощью выделенной сети, такой как [Portal Network](https://www.ethportal.net/), которая сможет обслуживать легкие клиенты, используя одноранговый протокол gossip. + +Другие элементы [дорожной карты](/roadmap/), такие как [деревья Веркла](/roadmap/verkle-trees/) и [бессостоятельность](/roadmap/statelessness/), в конечном итоге обеспечат гарантии безопасности легких клиентов наравне с полными клиентами. + +## Дополнительные материалы {#further-reading} + +- [Жолт Фелфолди о легких клиентах Geth](https://www.youtube.com/watch?v=EPZeFXau-RE) +- [Этан Кисслинг о сетевом взаимодействии легких клиентов](https://www.youtube.com/watch?v=85MeiMA4dD8) +- [Этан Кисслинг о легких клиентах после Слияния](https://www.youtube.com/watch?v=ZHNrAXf3RDE) +- [Пайпер Мерриам: извилистый путь к функциональным легким клиентам](https://snakecharmers.ethereum.org/the-winding-road-to-functional-light-clients/) diff --git a/public/content/translations/ru/developers/docs/nodes-and-clients/node-architecture/index.md b/public/content/translations/ru/developers/docs/nodes-and-clients/node-architecture/index.md new file mode 100644 index 00000000000..ba02338173b --- /dev/null +++ b/public/content/translations/ru/developers/docs/nodes-and-clients/node-architecture/index.md @@ -0,0 +1,59 @@ +--- +title: "Архитектура узла" +description: "Введение в устройство узлов Ethereum." +lang: ru +--- + +Узел Ethereum состоит из двух клиентов: [клиента исполнения](/developers/docs/nodes-and-clients/#execution-clients) и [клиента консенсуса](/developers/docs/nodes-and-clients/#consensus-clients). Чтобы узел мог предложить новый блок, он также должен запустить [клиент валидатора](#validators). + +Когда Ethereum использовал [доказательство работы](/developers/docs/consensus-mechanisms/pow/), для запуска полного узла Ethereum было достаточно клиента исполнения. Однако с момента внедрения [доказательства владения](/developers/docs/consensus-mechanisms/pow/) клиент исполнения должен использоваться вместе с другой программой, называемой [клиентом консенсуса](/developers/docs/nodes-and-clients/#consensus-clients). + +На диаграмме ниже показаны отношения между двумя клиентами Ethereum. Два клиента подключены к своим собственным одноранговым сетям (P2P) Отдельные P2P-сети необходимы, поскольку клиенты исполнения распространяют транзакции по своей P2P-сети, что позволяет им управлять своим локальными транзакциями, в то время как клиенты консенсуса обмениваются блоками по своей P2P-сети, что обеспечивает консенсус и рост цепочки. + +![](node-architecture-text-background.png) + +_Существует несколько вариантов клиента исполнения, включая Erigon, Nethermind и Besu_. + +Чтобы эта двухклиентская структура работала, клиенты консенсуса должны передавать пакеты транзакций клиенту исполнения. Клиент исполнения выполняет транзакции локально, чтобы убедиться, что транзакции не нарушают никаких правил Ethereum и что предлагаемое обновление состояния Ethereum является верным. Когда узел выбран в качестве производителя блока, его экземпляр клиента консенсуса запрашивает пакеты транзакций у клиента исполнения, чтобы включить их в новый блок и выполнить для обновления глобального состояния. Клиент консенсуса управляет клиентом исполнения через локальное RPC-соединение с помощью [Engine API](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md). + +## Что делает клиент исполнения? {#execution-client} + +Клиент исполнения отвечает за проверку, обработку и распространение транзакций, а также за управление состоянием и поддержку виртуальной машины Ethereum ([EVM](/developers/docs/evm/)). Он **не** несет ответственности за создание блоков, их распространение или обработку логики консенсуса. Это входит в полномочия клиента консенсуса. + +Клиент исполнения создает полезные нагрузки исполнения — список транзакций, обновленное дерево состояния и другие данные, связанные с исполнением. Клиенты консенсуса включают полезную нагрузку исполнения в каждый блок. Клиент исполнения также отвечает за повторное исполнение транзакций в новых блоках, чтобы гарантировать их действительность. Выполнение транзакций осуществляется на встроенном компьютере клиента исполнения, известном как [виртуальная машина Ethereum (EVM)](/developers/docs/evm). + +Клиент исполнения также предлагает пользовательский интерфейс для Ethereum через [методы RPC](/developers/docs/apis/json-rpc), которые позволяют пользователям запрашивать блокчейн Ethereum, отправлять транзакции и развертывать умные контракты. Вызовы RPC обычно обрабатываются библиотекой, такой как [Web3js](https://docs.web3js.org/), [Web3py](https://web3py.readthedocs.io/en/v5/), или пользовательским интерфейсом, например, браузерным кошельком. + +Подводя итог, можно сказать, что клиент исполнения это: + +- пользовательский доступ к Ethereum +- дом для виртуальной машины Ethereum, состояния Ethereum и для транзакций. + +## Что делает клиент консенсуса? {#consensus-client} + +Клиент консенсуса отвечает за всю логику, позволяющую узлу синхронизироваться с сетью Ethereum. Это включает в себя получение блоков от узлов и запуск алгоритма выбора ответвления, чтобы гарантировать, что узел всегда следует цепочке с наибольшим накоплением аттестаций (взвешенных по эффективным балансам валидатора). Подобно клиенту исполнения, клиенты консенсуса имеют собственную одноранговую сеть, через которую они обмениваются блоками и аттестациями. + +Клиент консенсуса не участвует в аттестации или предложении блоков — это делает валидатор, необязательное дополнение к клиенту консенсуса. Клиент консенсуса без валидатора поддерживает связь только с концом цепи, позволяя узлу оставаться синхронизированным. Это позволяет пользователю взаимодействовать с Ethereum, используя свой клиент исполнения, будучи уверенным, что он находится в правильной цепочке. + +## Валидаторы {#validators} + +Стейкинг и запуск программного обеспечения валидатора дают узлу право быть выбранным для предложения нового блока. Операторы узлов могут добавить валидатора к своим клиентам консенсуса, внеся 32 ETH в депозитный контракт. Клиент валидатора идет в комплекте с клиентом консенсуса и может быть добавлен к узлу в любое время. Валидатор обрабатывает аттестации и предложения блоков. Это также позволяет узлу получать вознаграждения или терять ETH из-за штрафов или урезаний. + +[Подробнее о стейкинге](/staking/). + +## Сравнение компонентов узла {#node-comparison} + +| Клиент исполнения | Клиент консенсуса | Валидатор | +| -------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------- | +| Распространяет транзакции через свою P2P-сеть | Распространяет блоки и аттестации через свою P2P-сеть | Предлагает блоки | +| Выполняет/повторно выполняет транзакции | Выполняет алгоритм выбора ветвления | Накапливает вознаграждения/штрафы | +| Проверяет поступающие изменения состояния | Отслеживает начало цепи | Делает аттестации | +| Управляет деревьями состояния и «квитанций» | Управляет состоянием Beacon (содержит информацию консенсуса и исполнения) | Требует 32 ETH для стейкинга | +| Создает полезную нагрузку исполнения | Отслеживает накопленную случайность в RANDAO (алгоритм, который обеспечивает проверяемую случайность для выбора валидатора и других операций консенсуса) | Может получить урезание | +| Предоставляет API JSON-RPC для взаимодействия с Ethereum | Следить за действительностью и финализацией | | + +## Дополнительные материалы {#further-reading} + +- [Доказательство владения](/developers/docs/consensus-mechanisms/pos) +- [Предложение блока](/developers/docs/consensus-mechanisms/pos/block-proposal) +- [Вознаграждения и штрафы валидатора](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties) diff --git a/public/content/translations/ru/developers/docs/nodes-and-clients/nodes-as-a-service/index.md b/public/content/translations/ru/developers/docs/nodes-and-clients/nodes-as-a-service/index.md index de5044fcaa7..54ec06d518f 100644 --- a/public/content/translations/ru/developers/docs/nodes-and-clients/nodes-as-a-service/index.md +++ b/public/content/translations/ru/developers/docs/nodes-and-clients/nodes-as-a-service/index.md @@ -1,59 +1,105 @@ --- -title: Узлы как услуга -description: Обзор услуг узлов на начальном уровне, плюсов и минусов, а также популярных провайдеров. +title: "Узлы как услуга" +description: "Обзор услуг узлов на начальном уровне, плюсов и минусов, а также популярных провайдеров." lang: ru sidebarDepth: 2 --- ## Введение {#Introduction} -Запуск [узла Ethereum](/developers/docs/nodes-and-clients/#what-are-nodes-and-clients) может быть сложным, особенно в самом начале или при быстром масштабировании. Существует [ряд служб](#popular-node-services), которые запускают оптимизированные инфраструктуры узлов, поэтому вы можете сосредоточиться на разработке своего приложения или продукта. Мы расскажем о том, как работают службы узлов, о плюсах и минусах для их использования и о списке провайдеров, если вы хотите начать. +Запуск собственного [узла Ethereum](/developers/docs/nodes-and-clients/#what-are-nodes-and-clients) может быть сложной задачей, особенно на начальном этапе или при быстром масштабировании. Существует [ряд сервисов](#popular-node-services), которые запускают для вас оптимизированные инфраструктуры узлов, так что вы можете сосредоточиться на разработке своего приложения или продукта. Мы расскажем о том, как работают службы узлов, о плюсах и минусах для их использования и о списке провайдеров, если вы хотите начать. -## Прежде чем начать {#prerequisites} +## Предварительные условия {#prerequisites} -Если у вас еще нет понимания того, какие есть узлы и клиенты, прочитайте раздел [Узлы и клиенты](/developers/docs/nodes-and-clients/). +Если у вас еще нет понимания, что такое узлы и клиенты, ознакомьтесь с разделом [«Узлы и клиенты»](/developers/docs/nodes-and-clients/). + +## Стейкеры {#stakoooooooooooooors} + +Одиночные стейкеры должны обслуживать собственную инфраструктуру и не полагаться на сторонние сервисы. Это значит — поддерживать соединение с исполнительным клиентом и клиентом для консенсуса. До [Слияния](/roadmap/merge) можно было запустить только клиент консенсуса и использовать централизованного провайдера для получения данных исполнения; теперь это невозможно — соло-стейкер должен запускать оба клиента. Существуют сервисы, облегчающие этот процесс. + +[Подробнее о запуске узла](/developers/docs/nodes-and-clients/run-a-node/). + +Сервисы, описанные на этой странице, предназначены для узлов без стейкинга. ## Как работают службы узлов? {#how-do-node-services-work} Поставщики услуг узлов используют для вас распределенные клиенты узлов, поэтому вам этого делать не нужно. -Эти сервисы обычно предоставляют ключ API, который вы можете использовать для записи и чтения из блокчейна. Они часто включают в себя доступ к [тестовым сетям Ethereum](/developers/docs/networks/#testnets) в дополнение к основной сети. +Эти сервисы обычно предоставляют ключ API, который вы можете использовать для записи и чтения из блокчейна. Они часто предоставляют доступ к [тестовым сетям Ethereum](/developers/docs/networks/#ethereum-testnets) в дополнение к основной сети. Некоторые службы предлагают вам свой собственный узел, которым они управляют для вас, в то время как другие используют балансировщики нагрузки для распределения активности между узлами. Почти все сервисы узлов очень легко интегрируются, одна строка изменяется в вашем коде, чтобы поменять ваш собственный узел или даже переключаться между службами. -Часто службы узлов будут запускать множество [клиентов узлов](/developers/docs/nodes-and-clients/#execution-clients) и [типов](/developers/docs/nodes-and-clients/#node-types), что позволяет получить доступ к полным и архивным узлам в дополнение к специфическим для клиента методам в одном API. +Зачастую сервисы узлов запускают различные [клиенты узлов](/developers/docs/nodes-and-clients/#execution-clients) и [типы](/developers/docs/nodes-and-clients/#node-types), что позволяет вам получать доступ к полным и архивным узлам в дополнение к специфичным для клиента методам в одном API. Важно отметить, что службы узлов не должны хранить ваши приватные ключи или информацию. -## Каковы преимущества использования службы узлов? {#benefits-of-using-a-node-service} +## Каковы преимущества использования службы узлов? Преимущества использования сервиса узлов {#benefits-of-using-a-node-service} Основное преимущество при использовании сервиса узлов заключается в том, что не приходится тратить время на техническое обслуживание и управление узлами самостоятельно. Это позволяет сосредоточиться на создании продукта, а не беспокоиться о техническом обслуживании инфраструктуры. Работающие собственные узлы могут быть очень дорогими из за хранения, пропускной способности и ценного инженерного времени. Такие вещи, как увеличение количества узлов при масштабировании, обновлении узлов до последней версии и обеспечении согласованности состояния, могут отвлечь от строительства нужного вам Web3-продукта и лишить возможности использовать на это ресурсы. -## Каковы преимущества использования службы узлов? {#cons-of-using-a-node-service} +## Каковы преимущества использования службы узлов? Недостатки использования сервиса узлов {#cons-of-using-a-node-service} Используя службу узлов, вы централизируете инфраструктуру вашего продукта. По этой причине проекты, в которых децентрализация имеет первостепенное значение, могут предпочитать узлы с собственным размещением, а не аутсорсинг у третьей стороны. -Узнайте больше о [преимуществах использования собственного узла](/developers/docs/nodes-and-clients/#benefits-to-you). +[Подробнее о преимуществах запуска собственного узла](/developers/docs/nodes-and-clients/#benefits-to-you). -## Популярные службы узлов {#popular-node-services} +## Популярные сервисы узлов {#popular-node-services} Здесь приведен список наиболее популярных поставщиков узлов Ethereum. Не стесняйтесь добавлять отсутствующие узлы! Сервис каждого узла предлагает различные преимущества и возможности в дополнение к бесплатным или платным уровням. Вам следует выяснить, какие из них лучше всего подходят вам, перед принятием решения. -- [**Alchemy**](https://www.alchemy.com/) - - [Документация](https://docs.alchemyapi.io/) +- [**Alchemy**](https://alchemy.com/) + - [Документация](https://www.alchemy.com/docs/) - Функции - - Вариант с бесплатным уровнем - - Масштабирование по мере продвижения - - Бесплатные архивные данные - - Инструменты анализа - - Панель управления - - Уникальные конечные точки API - - Веб-крючки - - Прямая поддержка + - Большой бесплатный тариф с 300 млн. вычислительными единицами в месяц (около 30 млн. запросов getLatestBlock) + - Мульти-чейн: Polygon, Skartnet, Optimism, Arbitrum + - Снабжает данными около 70% крупнейших децентрализованных приложений Ethereum и торговых сделок в DeFi + - Оповещения вебхуками в реальном времени через Alchemy Notify + - Лучшая среди конкурентов поддержка, доступность и стабильность + - NFT API от Alchemy + - Дашборд с обозревателем запросов, просмотр мемпула и компоновщик + - Интегрированный доступ к крану в тестовых сетях + - Активное сообщество разработчиков в Discord с 18 тыс. пользователей + +- [**Allnodes**](https://www.allnodes.com/) + - [Документация](https://docs.allnodes.com/) + - Функции + - Отсутствие лимитов частоты запросов при использовании токена PublicNode, созданного на странице портфолио Allnodes. + - Бесплатные RPC-эндпоинты с упором на конфиденциальность (более 100 блокчейнов) на [PublicNode](https://www.publicnode.com) + - Выделенные ноды без ограничений скорости для более чем 90 блокчейнов + - Выделенные архивные ноды для 30+ блокчейнов + - Доступны в 3 регионах (США, Европа, Азия) + - Снапшоты для более чем 100 блокчейнов на [PublicNode](https://www.publicnode.com/snapshots) + - Круглосуточная техническая поддержка с гарантией времени работы 99.90%-99.98% согласно соглашению об уровне обслуживания (SLA) в зависимости от тарифного плана. + - Почасовая оплата + - Платите кредитной картой, через PayPal или криптой + +- [**All That Node**](https://allthatnode.com/) + - [Документация](https://docs.allthatnode.com/) + - Функции + - 50 000 Запросов в день на бесплатном уровне + - Поддержка более 40 протоколов + - JSON-RPC (EVM, Tendermint), REST, и Websocket API поддерживаются + - Неограниченный доступ к дате архива + - Тех. поддержка 24/7 и 99,9% времени безотказной работы + - Кран, доступный в множестве сетей + - Неограниченный доступ к конечным точкам с безлимитным количеством API-ключей + - Поддерживаются API трассировки/отладки + - Автоматические обновления + +- [**Amazon Managed Blockchain**](https://aws.amazon.com/managed-blockchain/) + - [Документация](https://aws.amazon.com/managed-blockchain/resources/) + - Функции + - Полностью управляемые узлы Ethereum + - Доступно в шести регионах + - JSON-RPC через HTTP и защищенные WebSockets + - Поддерживает 3 цепи + - SLAs, поддержка AWS в режиме 24/7 + - Go-ethereum и Lighthouse + - [**Ankr**](https://www.ankr.com/) - [Документация](https://docs.ankr.com/) - Функции @@ -66,24 +112,78 @@ sidebarDepth: 2 - Панель управления - Конечные точки RPC, HTTPS и WSS - Прямая поддержка + +- [**Blast**](https://blastapi.io/) + - [Документация](https://docs.blastapi.io/) + - Функции + - Поддержка RPC и WSS + - Мульти-региональный хостинг узлов + - Децентрализованная инфраструктура + - Публичное API + - Расширенный бесплатный план + - Мультичейн (поддержка 17+ сетей) + - Узлы с архивированными данными + - Круглосуточная поддержка в Discord + - Круглосуточный мониторинг и оповещения + - Гарантия аптайма всех сервисов 99.9% + - Оплата криптовалютой + - [**BlockDaemon**](https://blockdaemon.com/) - [Документация](https://ubiquity.docs.blockdaemon.com/) - - Преимущество + - Преимущества - Панель управления - На основе узлов - Аналитика + +- [**BlockPI**](https://blockpi.io/) + - [Документация](https://docs.blockpi.io/) + - Функции + - Надежная и распределенная структура узлов + - До 40 эндпоинтов HTTPS и WSS + - Бесплатная регистрация и месяц в подарок + - Трассировка + Доступ к архивным данным + - Пакеты валидны до 90 дней + - Индивидуальные планы и оплата по факту использования + - Оплата криптовалютой + - Прямая и техническая поддержка + +- [**Chainbase**](https://www.chainbase.com/) + - [Документация](https://docs.chainbase.com) + - Функции + - Легкодоступный, быстрый и масштабируемый RPC-сервис + - Поддержка нескольких цепей + - Беслптные тарифы + - Удобная в использовании панель мониторинга + - Предоставляет блокчейн-сервисы передачи данных за пределами RPC + - [**Chainstack**](https://chainstack.com/) - [Документация](https://docs.chainstack.com/) - Функции - Бесплатные общие узлы - Общие архивные узлы - Поддержка GraphQL - - RPC и WSS конечные точки + - Конечные точки RPC и WSS - Выделенные полные и архивные узлы - Быстрая синхронизация для выделенных развертываний - - Добавьте своё облако + - Добавление своего облака - Почасовая оплата - Прямая поддержка 24/7 + +- [**dRPC**](https://drpc.org/) + - [Документация](https://drpc.org/docs) + - NodeCloud: готовая к использованию RPC-инфраструктура от 10 долларов США — полная скорость, без ограничений + - Возможности NodeCloud: + - Поддержка API для 185 сетей + - Распределенный пул из более чем 40 провайдеров + - Глобальное покрытие с девятью (9) геокластерами + - Система балансировки нагрузки на базе ИИ + - Фиксированные тарифы с оплатой по мере использования — без повышения цен, без срока действия, без привязки + - Неограниченное количество ключей, детальная настройка ключей, роли в команде, защита фронтенда + - Фиксированная ставка для методов: 20 вычислительных единиц (CU) за метод + - [Список общедоступных эндпоинтов](https://drpc.org/chainlist) + - [Калькулятор цен](https://drpc.org/pricing#calculator) + - NodeCore: стек с открытым исходным кодом для организаций, которым нужен полный контроль + - [**GetBlock**](https://getblock.io/) - [Документация](https://getblock.io/docs/get-started/authentication-with-api-key/) - Функции @@ -95,6 +195,7 @@ sidebarDepth: 2 - Расширенная аналитика - Автоматические обновления - Техническая поддержка + - [**InfStones**](https://infstones.com/) - Функции - Вариант с бесплатным уровнем @@ -106,7 +207,8 @@ sidebarDepth: 2 - Быстрая синхронизация для выделенных развертываний - Прямая поддержка 24/7 - Доступ к 50+ узлам блокчейна -- [**Структура**](https://infura.io/) + +- [**Infura**](https://infura.io/) - [Документация](https://infura.io/docs) - Функции - Вариант с бесплатным уровнем @@ -114,6 +216,7 @@ sidebarDepth: 2 - Платные архивные данные - Прямая поддержка - Панель управления + - [**Kaleido**](https://kaleido.io/) - [Документация](https://docs.kaleido.io/) - Функции @@ -123,74 +226,152 @@ sidebarDepth: 2 - 500+ API администрирования и обслуживания - Интерфейс RESTful для представления транзакции в Ethereum (поддерживаемый Apache Kafka) - Исходящие потоки для доставки события (поддерживаемые Apache Kafka) - - Обширная коллекция офф-чейн и вспомогательных услуг (например, двусторонняя передача зашифрованных сообщений) + - Обширная коллекция "офчейн"- и вспомогательных сервисов (например, двусторонний зашифрованный транспорт сообщений) - Простая сеть, интегрированная с управлением и контролем доступа на основе ролей - Проработанное пользовательское управление как для администраторов, так и для конечных пользователей - Высокомасштабируемая и гибкая инфраструктура корпоративного уровня - Управление приватным ключом Cloud HSM - Привязка основной сети Ethereum - Сертификаты ISO 27k и SOC 2, тип 2 - - Набор динамического времени выполнения (например: добавление облачных интеграций, изменение входов в узел и так далее) + - Динамическая конфигурация среды выполнения (например, добавление облачных интеграций, изменение входящих подключений узла и т. д.) - Поддержка мультиблочных, мультирегиональных и гибридных сочетаний инструментов развертывания - Простое почасовое ценообразование на основе SaaS - SLA и поддержка 24x7 + +- [**Lava Network**](https://www.lavanet.xyz/) + - [Документация](https://docs.lavanet.xyz/) + - Функции + - Бесплатно для тестнетов + - Децентрализованное распределение для высокого аптайма + - Открытый исходный код + - Полностью децентрализованный SDK + - Интеграция с Ethers.js + - Интуитивный интерфейс управления проектом + - Проверка валидности данных методом консенсуса + - Мульти-чейн поддержка + - [**Moralis**](https://moralis.io/) - [Документация](https://docs.moralis.io/) - Функции - Бесплатные общие узлы - Бесплатные общие архивные узлы - - Ориентирован на конфиденциальность (политика отсутствия логов) - - Кросс-чейн поддержка + - Приоритет конфиденциальности (политика отсутствия журналов) + - Поддержка разных цепей - Масштабирование по мере продвижения - Панель управления - Уникальный Ethereum SDK - Уникальные конечные точки API - - Прямая, техническая поддержка + - Прямая техническая поддержка + +- [**NodeReal MegaNode**](https://nodereal.io/) + - [Документация](https://docs.nodereal.io/docs/introduction) + - Функции + - Надежные, быстрые и масштабируемые сервисы RPC API + - Улучшенный API для Web3 разработчиков + - Поддержка нескольких цепей + - Начните бесплатно + +- [**NOWNodes**](https://nownodes.io/) + - [Документация](https://documenter.getpostman.com/view/13630829/TVmFkLwy) + - Функции + - Доступ к 50+ узлам блокчейна + - Бесплатный API ключ + - Блокировать браузер Интернет Эксплорер + - Время отклика API ⩽ 1 с + - Служба поддержки 24/7 + - Персональный аккаунт менеджер + - Общие, архивные, резервные и выделенные узлы + - [**Pocket Network**](https://www.pokt.network/) - [Документация](https://docs.pokt.network/home/) - Функции - Децентрализованный протокол RPC и торговая площадка - - Уровень бесплатного пользования 1 млн запросов в день (на конечную точку, максимум 2) - - [Публичные конечные точки](https://docs.pokt.network/developers/public-endpoints) + - Уровень бесплатного пользования — 1 млн запросов в день (на конечную точку, максимум 2) + - [Общедоступные эндпоинты](https://docs.pokt.network/developers/public-endpoints) - Программа Pre-Stake+ (если вам нужно более 1 млн запросов в день) - Поддержка 15+ блокчейнов - 6400+ узлов обслуживают приложения, зарабатывая при этом POKT - - Архивный узел, архивный узел с w/ отслеживанием, & поддержка узла тестовой сети + - Архивный узел, архивный узел с трассировкой и поддержка узлов тестовой сети - Разнообразие клиентов узла основной сети Ethereum - Нет единой точки отказа - Нулевое время простоя - - Экономически эффективная околонулевая токеномика (поставьте POKT в стекинг один раз для обеспечения пропускной способности сети) - - Никаких ежемесячных тайных затрат, превратите свою инфраструктуру в актив + - Экономически эффективная околонулевая токеномика (однократная ставка POKT для обеспечения пропускной способности сети) + - Никаких ежемесячных тайных затрат, возможность превратить инфраструктуру в актив - Балансировка нагрузки, встроенная в протокол - - Непрерывное масштабирование количества запросов в день и узлов в час по мере поступления - - Самый приватный, цензуроустойчивый вариант - - Поддержка разработчиков - - [Pocket Portal](https://bit.ly/ETHorg_POKTportal) панель управления и аналитика -- [**Узлы**](https://www.quiknode.io/) - - Функции - - 7 дней бесплатной пробной версии - - Поддержка разного типа - - Веб-крючки - - Панель управления - - Аналитика + - Бесконечное масштабирование количества запросов в день и узлов в час по мере продвижения + - Самый приватный и цензуроустойчивый вариант + - Практичная поддержка разработчиков + - [Pocket Portal](https://bit.ly/ETHorg_POKTportal): панель управления и аналитика + +- [**QuickNode**](https://www.quicknode.com) + - [Документация](https://www.quicknode.com/docs/) + - Функции + - Круглосуточная техническая поддержка и сообщество разработчиков в Discord + - Геобалансированная, мультиоблачная/металлическая сеть с низкой задержкой + - Поддержка нескольких цепочек (Optimism, Arbitrum, Polygon + 11 других) + - Промежуточные уровни для скорости и стабильности (маршрутизация вызовов, кеш, индексирование) + - Мониторинг смарт-контрактов с помощью Webhooks + - Интуитивно понятная панель инструментов, набор аналитики, RPC-компановщик + - Расширенные функции безопасности (JWT, маскирование, белый список) + - NFT данные и аналитика API + - [Сертификация SOC2](https://www.quicknode.com/security) + - Подходит для разработчиков и предприятий + - [**Rivet**](https://rivet.cloud/) - [Документация](https://rivet.readthedocs.io/en/latest/) - Функции - Вариант с бесплатным уровнем - Масштабирование по мере продвижения + +- [**SenseiNode**](https://senseinode.com) + - [Документация](https://docs.senseinode.com/) + - Функции + - Выделенные узлы и общий доступ к ним + - Панель управления + - Размещайте AWS на нескольких хостинг-провайдерах в разных регионах Латинской Америки + - Prysm и Lighthouse клиенты + - [**SettleMint**](https://console.settlemint.com/) - [Документация](https://docs.settlemint.com/) - Функции - Бесплатная пробная версия - Масштабирование по мере продвижения - Поддержка GraphQL - - RPC и WSS конечные точки + - Конечные точки RPC и WSS - Выделенные полные узлы - - Добавьте своё облако + - Добавление своего облака - Инструменты анализа - Панель управления - Почасовая оплата - Прямая поддержка + +- [**Tenderly**](https://tenderly.co/web3-gateway) + - [Документация](https://docs.tenderly.co/web3-gateway/web3-gateway) + - Функции + - Бесплатный тариф с 25 миллионами единиц Tenderly в месяц + - Бесплатный доступ к историческим данным + - Скорость чтения до 8 раз выше при больших рабочих нагрузках + - 100% согласованный доступ для чтения + - JSON-RPC конечные точки + - RPC-конструктор запросов на основе пользовательского интерфейса и предварительный просмотр запросов + - Тесно интегрирован с инструментами разработки, отладки и тестирования Tenderly + - Моделирование транзакций + - Аналитика использования и фильтрация + - Простое управление ключами доступа + - Специальная техническая поддержка через чат, электронную почту и Discord + +- [**Tokenview**](https://services.tokenview.io/) + - [Документация](https://services.tokenview.io/docs?type=nodeService) + - Функции + - Круглосуточная техническая поддержка и сообщество разработчиков в Telegram + - Поддержка нескольких цепей (Bitcoin, Ethereum, Tron, BNB SmartChain, Ethereum Classic) + - Доступны для использования как RPC, так и WSS endpoints + - Неограниченный доступ к API архивных данных + - Панель мониторинга с обозревателем запросов и наблюдателем за Mempool + - NFT data API и веб-приложения уведомляют + - Оплата криптовалютой + - Внешняя поддержка для выполнения дополнительных требований к поведению + - [**Watchdata**](https://watchdata.io/) - [Документация](https://docs.watchdata.io/) - Функции @@ -203,15 +384,35 @@ sidebarDepth: 2 - Масштабирование ресурсов - Высокие скорости обработки -## Дополнительные ресурсы {#further-reading} +- [**ZMOK**](https://zmok.io/) + - [Документация](https://docs.zmok.io/) + - Функции + - Опережение как услуга + - Глобальный пакет транзакций с методами поиска/фильтрации + - Неограниченная TX комиссия и бесконечный газ для отправки транзакций + - Самое быстрое получение нового блока и чтение блокчейна + - Гарантия лучшей цены за вызов API + +- [**Zeeve**](https://www.zeeve.io/) + - [Документация](https://www.zeeve.io/docs/) + - Функции + - Платформа автоматизации корпоративного уровня без написания кода, обеспечивающая развертывание, мониторинг и управление узлами и сетями блокчейна + - Более 30 поддерживаемых протоколов и интеграций, и их число постоянно растет + - Дополнительные инфраструктурные сервисы web 3, такие, как децентрализованное хранилище, децентрализованная идентификация и API-интерфейсы для учета данных в блокчейне, для использования в реальных условиях + - Круглосуточная поддержка и упреждающий мониторинг обеспечивают постоянную работоспособность узлов. + - Конечные точки RPC обеспечивают аутентифицированный доступ к API, удобное управление с интуитивно понятной приборной панелью и аналитикой. + - Предоставляет на выбор как управляемое облако, так и собственные облачные сервисы, а также поддерживает всех основных облачных провайдеров, таких как AWS, Azure, Google Cloud, Digital Ocean и локальные сервисы. + - Мы используем интеллектуальную маршрутизацию, чтобы каждый раз попадать на ближайший к вашему пользователю узел + +## Дополнительные материалы {#further-reading} -- [Список служб узлов Ethereum](https://ethereumnodes.com/) +- [Список сервисов узлов Ethereum](https://ethereumnodes.com/) -## Похожие темы {#related-topics} +## Смежные темы {#related-topics} - [Узлы и клиенты](/developers/docs/nodes-and-clients/) ## Связанные руководства {#related-tutorials} -- [Начало разработки Ethereum с помощью Alchemy](/developers/tutorials/getting-started-with-ethereum-development-using-alchemy/) +- [Начало работы с разработкой на Ethereum с использованием Alchemy](/developers/tutorials/getting-started-with-ethereum-development-using-alchemy/) - [Руководство по отправке транзакций с помощью web3 и Alchemy](/developers/tutorials/sending-transactions-using-web3-and-alchemy/) diff --git a/public/content/translations/ru/developers/docs/nodes-and-clients/run-a-node/index.md b/public/content/translations/ru/developers/docs/nodes-and-clients/run-a-node/index.md index 9fc34942066..9b172aed60c 100644 --- a/public/content/translations/ru/developers/docs/nodes-and-clients/run-a-node/index.md +++ b/public/content/translations/ru/developers/docs/nodes-and-clients/run-a-node/index.md @@ -1,86 +1,205 @@ --- -title: Развертывание собственного узла Ethereum -description: Общее введение в запуск собственного экземпляра клиента Ethereum. +title: "Развертывание собственного узла Ethereum" +description: "Общее введение в запуск собственного экземпляра клиента Ethereum." lang: ru sidebarDepth: 2 --- Запуск собственного узла дает вам различные преимущества, открывает новые возможности и помогает поддерживать экосистему. Эта страница поможет вам развернуть собственный узел и принять участие в проверке транзакций Ethereum. -## Прежде чем начать {#prerequisites} +Обратите внимание, что после [Слияния](/roadmap/merge) для запуска узла Ethereum требуются два клиента: клиент **уровня исполнения (EL)** и клиент **уровня консенсуса (CL)**. На этой странице вы узнаете, как установить, настроить и подключить эти два клиента для запуска узла Ethereum. -Вы должны понимать, что такое узел Ethereum и почему вам может понадобиться запустить клиент. Это описано в статье [Узлы и клиенты](/developers/docs/nodes-and-clients/). +## Предварительные условия {#prerequisites} -Если тема запуска собственного узла для вас новая или вы ищете менее «технический» способ, посмотрите наш более понятное для новичков [введение в запуск узлов Ethereum](/run-a-node). +Вы должны понимать, что такое узел Ethereum и почему вам может понадобиться запустить клиент. Это описано в разделе [«Узлы и клиенты»](/developers/docs/nodes-and-clients/). + +Если вы новичок в теме запуска узла или ищете менее технический путь, мы рекомендуем сначала ознакомиться с нашим удобным введением в [запуск узла Ethereum](/run-a-node). ## Выбор подхода {#choosing-approach} -Первый шаг в разворачивании вашего узла — выбор подхода. Вы должны выбрать клиент (программное обеспечение), среду и параметры, с которыми хотите начать. Просмотрите все доступные [клиенты основной сети](/developers/docs/nodes-and-clients/#advantages-of-different-implementations). +Первый шаг в разворачивании вашего узла — выбор подхода. На основе требований и различных возможностей необходимо выбрать реализацию клиента (как клиента исполнения, так и клиента консенсуса), среду (аппаратную или системную) и параметры для настроек клиента. + +Эта страница поможет вам в принятии этих решений и поможет найти наиболее подходящий способ запуска вашего экземпляра Ethereum. + +Чтобы выбрать из реализаций клиентов, ознакомьтесь со всеми доступными для основной сети [клиентами исполнения](/developers/docs/nodes-and-clients/#execution-clients), [клиентами консенсуса](/developers/docs/nodes-and-clients/#consensus-clients) и узнайте о [разнообразии клиентов](/developers/docs/nodes-and-clients/client-diversity). + +Решите, запускать ли программное обеспечение на собственном [оборудовании или в облаке](#local-vs-cloud), учитывая [требования](#requirements) клиентов. -### Настройки клиента {#client-settings} +После подготовки среды установите выбранные клиенты либо с помощью [удобного для начинающих интерфейса](#automatized-setup), либо [вручную](#manual-setup) с помощью терминала с расширенными параметрами. -Реализации клиента включают различные режимы синхронизации и многие другие параметры. [Режимы синхронизации](/developers/docs/nodes-and-clients/#sync-modes) представляют собой различные методы загрузки и проверки данных блокчейна. Перед запуском узла следует решить, какую сеть и режим синхронизации использовать. Наиболее важно учитывать дисковое пространство и время синхронизации, которые потребуются клиенту. +Когда узел запущен и синхронизируется, вы готовы [использовать его](#using-the-node), но не забывайте о его [обслуживании](#operating-the-node). -Все функции и опции можно найти в документации клиента. Различные конфигурации клиента можно установить, запустив клиент с соответствующими флагами. В целях тестирования вы можете запустить клиент в одной из тестовых сетей. [Обзор поддерживаемых сетей](/developers/docs/nodes-and-clients/#execution-clients). +![Настройка клиента](./diagram.png) ### Среда и оборудование {#environment-and-hardware} #### Локально или в облаке {#local-vs-cloud} -Клиенты Ethereum могут работать на компьютерах потребительского класса и не требуют специального оборудования (например, в отличие от майнинга). Таким образом, в зависимости от ваших нужд вам доступны различные способы развертывания. Для упрощения давайте рассмотрим запуск узла как на локальной физической машине, так и на облачном сервере. +Клиенты Ethereum могут работать на компьютерах потребительского класса и не требуют специального оборудования (например, в отличие от майнинга). Таким образом, в зависимости от ваших нужд вам доступны различные способы развертывания узла. +Для упрощения давайте рассмотрим запуск узла как на локальной физической машине, так и на облачном сервере. - Облако - - Провайдеры предлагают большое время безотказной работы сервера и статические общедоступные IP-адреса + - Провайдеры предлагают большое время бесперебойной работы сервера и статические публичные IP-адреса - Получение выделенного или виртуального сервера может быть более удобным, чем создание собственного - Необходимость доверяться третьей стороне — поставщику серверов - - Из-за большого размера хранилища для полного узла цена арендованного сервера может быть высока + - Из-за большого размера хранилища для полного узла цена аренды сервера может быть высока - Собственное оборудование - Более независимый подход, требующий меньшего доверия посторонним - Однократное вложение - Возможность покупки преднастроенной машины - - Необходимость подготовить и обслуживать оборудование, а также устранять возможные проблемы + - Необходимость подготовить и обслуживать оборудование, а также устранять возможные проблемы с оборудованием и сетью + +Оба варианта имеют различные преимущества, описанные выше. Если вы ищете облачное решение, помимо многих традиционных поставщиков облачных вычислений есть сервисы, ориентированные на развертывание узлов. Ознакомьтесь с [«Узлами как услугой»](/developers/docs/nodes-and-clients/nodes-as-a-service/) для получения дополнительных сведений о размещенных узлах. + +#### Оборудование {#hardware} + +Однако устойчивая к цензуре децентрализованная сеть не должна полагаться на облачных провайдеров. Вместо этого запуск узла на собственном локальном оборудовании полезнее для экосистемы. [Оценки](https://www.ethernodes.org/networkType/cl/Hosting) показывают, что большая часть узлов работает в облаке, что может стать единой точкой отказа. + +Клиенты Ethereum могут работать на вашем компьютере, ноутбуке, сервере или даже на одноплатном компьютере. Хотя запуск клиентов на вашем персональном компьютере вполне возможен, наличие выделенной машины только для вашего узла может значительно повысить его производительность и безопасность, минимизируя при этом воздействие на работоспособность вашего основного компьютера. -Оба варианта имеют различные преимущества, описанные выше. Если вы ищете облачное решение, помимо многих традиционных поставщиков облачных вычислений есть сервисы, ориентированные на развертывание узлов. Например: +Использовать собственное оборудование может быть довольно просто. Есть как простые варианты, так и продвинутые настройки для более технически подкованных людей. Так давайте рассмотрим требования и способы запуска клиентов Ethereum на вашей машине. -- [Узлы](https://www.quiknode.io/) -- [Blockdaemon](https://blockdaemon.com) -- [LunaNode](https://www.lunanode.com/) -- [Alchemy](https://www.alchemy.com/) +#### Требования {#requirements} -#### Аппаратное обеспечение {#hardware} +Требования к оборудованию различаются в зависимости от клиента, но обычно не так высоки, поскольку узел просто должен оставаться синхронизированным. Не путайте это с майнингом, который требует гораздо большей вычислительной мощности. Однако время синхронизации и производительность улучшаются с более мощным оборудованием. + +Перед установкой любого клиента убедитесь, что на вашем компьютере достаточно ресурсов для его запуска. Вы найдете минимальные и рекомендуемые требования ниже. + +Основным узким местом для вашего оборудования является дисковое пространство. Синхронизация блокчейна Ethereum очень интенсивна по операциям ввода-вывода и требует много места. Лучше всего иметь **твердотельный накопитель (SSD)** с сотнями ГБ свободного места даже после синхронизации. + +Размер базы данных и скорость начальной синхронизации зависят от выбранного клиента, его конфигурации и [стратегии синхронизации](/developers/docs/nodes-and-clients/#sync-modes). + +Также убедитесь, что ваше интернет-соединение не ограничено [лимитом пропускной способности](https://wikipedia.org/wiki/Data_cap). Рекомендуется использовать безлимитное соединение, так как первоначальная синхронизация и обмен данными с сетью могут превысить ваш лимит. + +##### Операционная система + +Все клиенты поддерживают основные операционные системы — Linux, MacOS, Windows. Это означает, что вы можете запускать узлы на обычных настольных компьютерах или серверах с операционной системой (ОС), которая подходит вам лучше всего. Убедитесь, что ваша ОС обновлена, чтобы избежать потенциальных проблем и уязвимостей. -Однако устойчивая к цензуре децентрализованная сеть не должна полагаться на облачных провайдеров. Для экосистемы будет полезнее, если вы запустите свой узел на собственном оборудовании. Самыми простыми вариантами являются преднастроенные машины, такие как: +##### Минимальные требования + +- ЦП с минимум 2 ядрами +- 8 ГБ ОЗУ +- 2TB SSD +- Пропускная способность от 10 Мбит/с + +##### Рекомендуемые характеристики + +- Быстрый процессор минимум с 4 ядрами +- Минимум 16 ГБ ОЗУ +- Быстрый SSD минимум с 2TB памяти +- Пропускная способность от 25 Мбит/с + +Выбранный вами режим синхронизации повлияет на требования к дисковому пространству, но мы оценили объем, который вам потребуется для каждого клиента. + +| Клиент | Размер диска (быстрая синхронизация) | Размер диска (полный архив) | +| ---------- | ------------------------------------------------------- | ---------------------------------------------- | +| Besu | Минимум 800GB | Минимум 12TB | +| Erigon | Н/Д | Минимум 2.5TB | +| Geth | 500GB+ | Минимум 12TB | +| Nethermind | 500GB+ | Минимум 12TB | +| Reth | Н/Д | Минимум 2.2TB | + +- Примечание: Erigon и Reth не предлагают snap-синхронизацию, но возможно полное сокращение (full pruning) (~2 ТБ для Erigon, ~1.2 ТБ для Reth). + +Для клиентов консенсуса требования к пространству также зависят от реализации клиента и включенных функций (например, слэшер валидатора), но в целом рассчитывайте еще на 200 ГБ, необходимых для данных Beacon Chain. С большим количеством валидаторов нагрузка на пропускную способность также возрастает. Вы можете найти [подробную информацию о требованиях к клиентам консенсуса в этом анализе](https://mirror.xyz/0x934e6B4D7eee305F8C9C42b46D6EEA09CcFd5EDc/b69LBy8p5UhcGJqUAmT22dpvdkU-Pulg2inrhoS9Mbc). + +#### Решения «подключи и работай» {#plug-and-play} + +Самый простой вариант запуска узла на собственном оборудовании — использование готовых устройств (plug-and-play). Предварительно настроенные машины от поставщиков предлагают самый простой опыт: заказать, подключить, запустить. Все предварительно настроено и запускается автоматически с интуитивно понятным руководством и панелью инструментов для мониторинга и управления программным обеспечением. - [DappNode](https://dappnode.io/) - [Avado](https://ava.do/) -Проверьте минимальные и рекомендуемые [требования к дисковому пространству для каждого клиента и режима синхронизации](/developers/docs/nodes-and-clients/#requirements). Обычно для этого достаточно довольно скромной вычислительной мощности. Проблема обычно заключается в скорости диска. Во время начальной синхронизации клиенты Ethereum выполняют множество операций чтения и записи. Поэтому настоятельно рекомендуется использовать SSD. Клиент может даже не иметь [возможности синхронизировать текущее состояние на HDD диске](https://github.com/ethereum/go-ethereum/issues/16796#issuecomment-391649278), застревая в нескольких блоках позади основной сети. Большинство клиентов можно запустить на [одноплатном компьютере с ARM](/developers/docs/nodes-and-clients/#ethereum-on-a-single-board-computer/). +#### Ethereum на одноплатном компьютере {#ethereum-on-a-single-board-computer} -Это позволит вам [запустить клиент с SD-карты](/developers/tutorials/run-node-raspberry-pi/). В зависимости от выбранного вами программного и аппаратного обеспечения время первоначальной синхронизации и требования к объему хранилища могут различаться. Обязательно [проверьте время синхронизации и требования к хранилищу](/developers/docs/nodes-and-clients/#recommended-specifications). Также убедитесь, что у вашего интернет-соединения нет [ограничения пропускной способности](https://wikipedia.org/wiki/Data_cap). Рекомендуется использовать безлимитное соединение, так как первоначальная синхронизация и обмен данными с сетью могут превысить ваш лимит. +Самый удобный и дешевый способ запустить узел Ethereum — использовать одноплатный компьютер с архитектурой ARM, такой как Raspberry Pi. [Ethereum on ARM](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/) предоставляет простые в запуске образы нескольких клиентов исполнения и консенсуса для Raspberry Pi и других плат ARM. -#### Операционная система {#operating-system} +Такие небольшие, доступные и эффективные устройства идеально подходят для запуска узла в домашних условиях, но не забывайте об их ограниченной производительности. -Все клиенты поддерживают основные операционные системы — Linux, MacOS, Windows. Это означает, что вы можете запускать узлы на обычных настольных компьютерах или серверах с операционной системой (ОС), которая подходит вам лучше всего. Убедитесь, что ваша ОС обновлена, чтобы избежать потенциальных проблем и уязвимостей. +## Запуск узла {#spinning-up-node} + +Фактическая настройка клиента может быть выполнена либо с помощью автоматизированных средств запуска, либо вручную, настраивая клиентское программное обеспечение напрямую. + +Менее продвинутым пользователям рекомендуется использовать программу-установщик — программное обеспечение, которое проведет вас через установку и автоматизирует процесс настройки клиента. Однако если у вас есть некоторый опыт работы с терминалом, следование шагам по ручной настройке не вызовет для вас больших затруднений. + +### Настройка с помощью мастера {#automatized-setup} + +Множество удобных для пользователя проектов направлены на улучшение опыта настройки клиента. Эти программы-установщики обеспечивают автоматическую установку и настройку клиента, а некоторые даже предлагают графический интерфейс для пошаговой настройки и мониторинга клиентов. -## Раскрутка узла {#spinning-up-node} +Ниже приведены несколько проектов, которые помогут вам установить и управлять клиентами всего в несколько кликов: -### Получение клиентского программного обеспечения {#getting-the-client} +- [DappNode](https://docs.dappnode.io/docs/user/getting-started/choose-your-path) — DappNode — это не только готовое устройство от поставщика. Программное обеспечение, то есть сам установщик узла и центр управления с множеством функций, можно использовать на любом оборудовании. +- [EthPillar](https://www.coincashew.com/coins/overview-eth/ethpillar) — самый быстрый и простой способ настроить полный узел. Инструмент для настройки в одну строку и TUI для управления узлом. Бесплатно. Открытый исходный код. Общественные блага для Ethereum от соло-стейкеров. Поддержка ARM64 и AMD64. +- [eth-docker](https://eth-docker.net/) — автоматизированная настройка с использованием Docker, ориентированная на простой и безопасный стейкинг. Требует базовых знаний терминала и Docker, рекомендуется для более продвинутых пользователей. +- [Stereum](https://stereum-dev.github.io/ethereum-node-web-docs) — программа-установщик для установки клиентов на удаленный сервер через SSH-соединение с графическим руководством по настройке, центром управления и многими другими функциями. +- [NiceNode](https://www.nicenode.xyz/) — программа-установщик с простым пользовательским интерфейсом для запуска узла на вашем компьютере. Просто выберите клиенты и запустите их в несколько кликов. Все еще в разработке. +- [Sedge](https://docs.sedge.nethermind.io/docs/intro) — инструмент настройки узла, который автоматически генерирует конфигурацию Docker с помощью мастера командной строки (CLI). Написан на Go компанией Nethermind. -Сначала скачайте [клиентское программное обеспечение](/developers/docs/nodes-and-clients/#execution-clients) +### Ручная настройка клиентов {#manual-setup} -Вы можете просто скачать исполняемое приложение или установочный пакет, который подходит вашей операционной системе и архитектуре. Всегда проверяйте подписи и контрольные суммы скачанных пакетов. Некоторые клиенты также предлагают репозитории для упрощения установки и обновления. Если хотите, можете сами собрать из исходников. Все клиенты имеют открытый исходный код, поэтому вы можете собрать их из исходного кода с помощью соответствующего компилятора. +Другой вариант — загрузить, проверить и настроить клиентское программное обеспечение вручную. Даже если некоторые клиенты предлагают графический интерфейс, ручная настройка все равно требует базовых навыков работы с терминалом, но предлагает гораздо большую гибкость. -Исполняемые файлы для стабильных реализаций клиентов основной сети можно загрузить со страниц их выпусков: +Как объяснялось ранее, для настройки собственного узла Ethereum потребуется запустить пару клиентов: клиента консенсуса и клиента исполнения. Некоторые клиенты могут включать в себя легкий клиент другого типа и синхронизироваться без необходимости в другом программном обеспечении. Однако для полной, не требующей доверия верификации, требуются обе реализации. +#### Получение клиентского ПО {#getting-the-client} + +Сначала вам необходимо получить предпочитаемое программное обеспечение [клиента исполнения](/developers/docs/nodes-and-clients/#execution-clients) и [клиента консенсуса](/developers/docs/nodes-and-clients/#consensus-clients). + +Вы можете просто скачать исполняемое приложение или установочный пакет, который подходит вашей операционной системе и архитектуре. Всегда проверяйте подписи и контрольные суммы скачанных пакетов. Некоторые клиенты также предлагают Docker образы для упрощения установки и обновления. Все клиенты имеют открытый исходный код, поэтому вы также можете собрать их из исходного кода. Это более сложный метод, но в некоторых случаях он может потребоваться. + +Инструкции по установке каждого клиента приведены в документации, ссылки на которую содержатся в списках клиентов выше. + +Ниже приведены страницы релизов клиентов, где вы можете найти их готовые бинарные файлы или инструкции по установке: + +##### Клиенты исполнения + +- [Besu](https://github.com/hyperledger/besu/releases) +- [Erigon](https://github.com/ledgerwatch/erigon/releases) - [Geth](https://geth.ethereum.org/downloads/) -- [OpenEthereum](https://github.com/openethereum/openethereum/releases) - [Nethermind](https://downloads.nethermind.io/) -- [Besu](https://besu.hyperledger.org/en/stable/) -- [Erigon](https://github.com/ledgerwatch/erigon) +- [Reth](https://reth.rs/installation/installation.html) + +Также стоит отметить, что разнообразие клиентов является [проблемой на уровне исполнения](/developers/docs/nodes-and-clients/client-diversity/#execution-layer). Читателям рекомендуется рассмотреть возможность запуска клиента исполнения из меньшинства. + +##### Клиенты консенсуса + +- [Lighthouse](https://github.com/sigp/lighthouse/releases/latest) +- [Lodestar](https://chainsafe.github.io/lodestar/run/getting-started/installation#build-from-source/) (не предоставляет готовый бинарный файл, только образ Docker или сборку из исходного кода) +- [Nimbus](https://github.com/status-im/nimbus-eth2/releases/latest) +- [Prysm](https://github.com/prysmaticlabs/prysm/releases/latest) +- [Teku](https://github.com/ConsenSys/teku/releases) + +[Разнообразие клиентов](/developers/docs/nodes-and-clients/client-diversity/) имеет решающее значение для узлов консенсуса, на которых работают валидаторы. Если большинство валидаторов используют одну и ту же реализацию клиента, безопасность сети находится под угрозой. Поэтому рекомендуется рассмотреть возможность выбора клиента из меньшинства. + +[Ознакомьтесь с последними данными об использовании сетевых клиентов](https://clientdiversity.org/) и узнайте больше о [разнообразии клиентов](/developers/docs/nodes-and-clients/client-diversity). + +##### Верификация ПО + +При загрузке программного обеспечения из Интернета рекомендуется проверять его целостность. Это необязательно, но, особенно если речь идет о таком важном элементе инфраструктуры, как клиент Ethereum, важно знать о потенциальных векторах атак и избегать их. Если вы загрузили готовый бинарный файл, вам нужно доверять ему и рисковать тем, что злоумышленник может подменить исполняемый файл на вредоносный. + +Разработчики подписывают выпускаемые бинарные файлы своими PGP-ключами, чтобы вы могли криптографически проверить, что вы запускаете именно то программное обеспечение, которое они создали. Вам просто нужно получить публичные ключи, используемые разработчиками, которые можно найти на страницах релизов клиентов или в документации. После загрузки релиза клиента и его подписи вы можете использовать реализацию PGP, например [GnuPG](https://gnupg.org/download/index.html), чтобы легко их проверить. Ознакомьтесь с руководством по проверке программного обеспечения с открытым исходным кодом с помощью `gpg` на [Linux](https://www.tecmint.com/verify-pgp-signature-downloaded-software/) или [Windows/MacOS](https://freedom.press/training/verifying-open-source-software/). -**Обратите внимение, что OpenEthereum [устарел](https://medium.com/openethereum/gnosis-joins-erigon-formerly-turbo-geth-to-release-next-gen-ethereum-client-c6708dd06dd) и больше не поддерживается.** Используйте его с осторожностью и по возможности перейдите на другую реализацию клиента. +Другой формой проверки является проверка того, что Хэш (уникальный криптографический отпечаток) загруженного вами программного обеспечения совпадает с тем, который предоставлен разработчиками. Это даже проще, чем использовать PGP, и некоторые клиенты предлагают только этот вариант. Просто запустите хэш-функцию для загруженного программного обеспечения и сравните результат с тем, что указан на странице релиза. Например: -### Запуск клиента {#starting-the-client} +```sh +sha256sum teku-22.6.1.tar.gz + +9b2f8c1f8d4dab0404ce70ea314ff4b3c77e9d27aff9d1e4c1933a5439767dde +``` + +#### Настройка клиента {#client-setup} + +После установки, загрузки или компиляции клиентского программного обеспечения, вы готовы к его запуску. Это лишь означает, что его нужно запускать с правильной конфигурацией. Клиенты предлагают широкие возможности конфигурации, которые могут включать различные функции. + +Начнем с опций, которые могут существенно повлиять на производительность клиента и использование данных. [Режимы синхронизации](/developers/docs/nodes-and-clients/#sync-modes) представляют собой различные методы загрузки и проверки данных блокчейна. Перед запуском узла следует решить, какую сеть и режим синхронизации использовать. Наиболее важно учитывать дисковое пространство и время синхронизации, которые потребуются клиенту. Обратите внимание на документацию клиента или страницу справки, чтобы узнать, какой режим синхронизации используется по умолчанию. Выберите тот, который подходит вам лучше всего, исходя из уровня безопасности, доступных данных и стоимости. Помимо алгоритма синхронизации, вы также можете настроить «обрезку» различных типов старых данных. Сокращение (pruning) позволяет удалять устаревшие данные, то есть удалять узлы дерева состояний, которые недоступны из последних блоков. + +Другие базовые параметры конфигурации — это, например, выбор сети (основная сеть или тестовые сети), включение конечной точки HTTP для RPC или WebSockets и т. д. Вы можете найти все функции и параметры в документации клиента. Различные конфигурации клиента можно установить, запустив клиент с соответствующими флагами непосредственно в интерфейсе командной строки (CLI) или в файле конфигурации. Каждый клиент немного отличается; пожалуйста, всегда обращайтесь к его официальной документации или странице справки для получения подробной информации о параметрах конфигурации. + +В целях тестирования вы можете запустить клиент в одной из тестовых сетей. [См. обзор поддерживаемых сетей](/developers/docs/nodes-and-clients/#execution-clients). + +Примеры запуска клиентов исполнения с базовой конфигурацией можно найти в следующем разделе. + +#### Запуск клиента исполнения {#starting-the-execution-client} Перед запуском клиентского программного обеспечения Ethereum убедитесь что ваша среда готова. Например, убедитесь в следующем: @@ -90,76 +209,275 @@ sidebarDepth: 2 - В системе установлены правильное время и дата. - Ваш маршрутизатор и брандмауэр принимают подключения к прослушиваемым портам. По умолчанию клиенты Ethereum используют порт слушателя (TCP) и порт обнаружения (UDP), оба по умолчанию 30303. -Сначала запустите свой клиент в тестовой сети, чтобы убедиться, что все работает правильно. Необходимо указать все настройки клиента, которые не установлены по умолчанию. Вы можете использовать конфигурационный файл, чтобы определить свой набор настроек. Конкретные настройки можно найти в документации вашего клиента Исполнение клиента запустит его базовые функции и выбранные конечные точки, а затем начнется поиск узлов одноранговой сети. Когда узел найдет одноранговые соединения, клиент начнет синхронизацию. Актуальные данные блокчейна будут доступны, как только клиент закончит синхронизацию до текущего состояния. +Сначала запустите свой клиент в тестовой сети, чтобы убедиться, что все работает правильно. + +Необходимо указать все настройки клиента, которые не установлены по умолчанию. Вы можете использовать конфигурационный файл, чтобы определить свой набор настроек. Набор функций и синтаксис конфигурации каждого клиента различаются. Для получения более подробной информации обратитесь к документации вашего клиента. + +Клиенты исполнения и клиенты консенсуса обмениваются данными через аутентифицированную конечную точку, указанную в [Engine API](https://github.com/ethereum/execution-apis/tree/main/src/engine). Чтобы подключиться к клиенту консенсуса, клиент исполнения должен сгенерировать [`jwtsecret`](https://jwt.io/) по известному пути. По соображениям безопасности и стабильности клиенты должны работать на одной машине, и оба клиента должны знать этот путь, так как он используется для аутентификации локального RPC-соединения между ними. Клиент исполнения также должен определить порт прослушивания для аутентифицированных API. + +Этот токен генерируется автоматически клиентским программным обеспечением, но в некоторых случаях вам может потребоваться сделать это самостоятельно. Вы можете сгенерировать его с помощью [OpenSSL](https://www.openssl.org/): + +```sh +openssl rand -hex 32 > jwtsecret +``` + +#### Запуск клиента исполнения {#running-an-execution-client} + +Этот раздел поможет вам запустить клиенты исполнения. Он служит лишь примером базовой конфигурации, которая запустит клиент со следующими настройками: -### Использование клиента {#using-the-client} +- Указывает сеть для подключения, в наших примерах это основная сеть + - Вместо этого вы можете выбрать [одну из тестовых сетей](/developers/docs/networks/) для предварительного тестирования вашей установки +- Определяет каталог данных, где будут храниться все данные, включая блокчейн + - Обязательно замените путь на реальный, например, указывающий на ваш внешний диск +- Включает интерфейсы для взаимодействия с клиентом + - Включая JSON-RPC и Engine API для связи с клиентом консенсуса +- Определяет путь к `jwtsecret` для аутентифицированного API + - Обязательно замените пример пути на реальный, доступный клиентам, например, `/tmp/jwtsecret` -Клиенты предоставляют конечные точки RPC API, которые можно использовать для управления клиентом и взаимодействием с сетью Ethereum различными способами: +Пожалуйста, имейте в виду, что это лишь базовый пример, все остальные настройки будут установлены по умолчанию. Обратите внимание на документацию каждого клиента, чтобы узнать о значениях по умолчанию, настройках и функциях. Для получения дополнительных функций, например для запуска валидаторов, мониторинга и т. д., обратитесь к документации конкретного клиента. -- Вызывать API вручную через наиболее подходящий протокол (например, через `curl`) -- Подсоединять предоставленную консоль (например, `geth attach`) -- Использовать в приложении +> Обратите внимание, что обратные косые черты `` в примерах используются только для форматирования; флаги конфигурации можно определить в одной строке. -У разных клиентов различаются реализации конечных точек RPC. Но существует стандарт JSON-RPC, которые можно использовать с любым клиентом. Обзор приведен в [документации JSON-RPC](https://eth.wiki/json-rpc/API). Приложения, которым требуется информация из сети Ethereum, могут использовать этот RPC. Например, популярный кошелек MetaMask позволяет вам [запустить локальный узел и присоединиться к нему](https://metamask.zendesk.com/hc/en-us/articles/360015290012-Using-a-Local-Node). +##### Запуск Besu + +Этот пример запускает Besu в основной сети, сохраняет данные блокчейна в формате по умолчанию в `/data/ethereum`, включает JSON-RPC и Engine RPC для подключения клиента консенсуса. Engine API аутентифицируется с помощью токена `jwtsecret`, и разрешены только вызовы с `localhost`. + +```sh +besu --network=mainnet \ + --data-path=/data/ethereum \ + --rpc-http-enabled=true \ + --engine-rpc-enabled=true \ + --engine-host-allowlist="*" \ + --engine-jwt-enabled=true \ + --engine-jwt-secret=/path/to/jwtsecret +``` + +Besu также поставляется с опцией запуска, которая задаст ряд вопросов и сгенерирует файл конфигурации. Запустите интерактивный установщик с помощью: + +```sh +besu --Xlauncher +``` + +[Документация Besu](https://besu.hyperledger.org/public-networks/get-started/start-node/) содержит дополнительные параметры и детали конфигурации. + +##### Запуск Erigon + +Этот пример запускает Erigon в основной сети, сохраняет данные блокчейна в `/data/ethereum`, включает JSON-RPC, определяет, какие пространства имен разрешены, и включает аутентификацию для подключения клиента консенсуса, которая определяется путем к `jwtsecret`. + +```sh +erigon --chain mainnet \ + --datadir /data/ethereum \ + --http --http.api=engine,eth,web3,net \ + --authrpc.jwtsecret=/path/to/jwtsecret +``` + +По умолчанию Erigon выполняет полную синхронизацию с жестким диском объемом 8 ГБ, что приведет к более чем 2 ТБ архивных данных. Убедитесь, что `datadir` указывает на диск с достаточным количеством свободного места, или рассмотрите флаг `--prune`, который может обрезать различные типы данных. Чтобы узнать больше, воспользуйтесь командой `--help` в Erigon. + +##### Запуск Geth + +Этот пример запускает Geth в основной сети, сохраняет данные блокчейна в `/data/ethereum`, включает JSON-RPC и определяет, какие пространства имен разрешены. Он также включает аутентификацию для подключения клиента консенсуса, что требует указания пути к `jwtsecret`, а также опции, определяющей, какие соединения разрешены; в нашем примере — только с `localhost`. + +```sh +geth --mainnet \ + --datadir "/data/ethereum" \ + --http --authrpc.addr localhost \ + --authrpc.vhosts="localhost" \ + --authrpc.port 8551 + --authrpc.jwtsecret=/path/to/jwtsecret +``` + +Ознакомьтесь с [документацией по всем параметрам конфигурации](https://geth.ethereum.org/docs/fundamentals/command-line-options) и узнайте больше о [запуске Geth с клиентом консенсуса](https://geth.ethereum.org/docs/getting-started/consensus-clients). + +##### Запуск Nethermind + +Nethermind предлагает различные [варианты установки](https://docs.nethermind.io/get-started/installing-nethermind). Пакет поставляется с различными бинарными файлами, включая установщик с пошаговой настройкой, который поможет вам создать конфигурацию в интерактивном режиме. В качестве альтернативы вы можете найти Runner, который является самим исполняемым файлом, и вы можете просто запустить его с флагами конфигурации. JSON-RPC включен по умолчанию. + +```sh +Nethermind.Runner --config mainnet \ + --datadir /data/ethereum \ + --JsonRpc.JwtSecretFile=/path/to/jwtsecret +``` + +Документация Nethermind предлагает [полное руководство](https://docs.nethermind.io/get-started/running-node/) по запуску Nethermind с клиентом консенсуса. + +Клиент исполнения инициирует свои основные функции, выбранные конечные точки и начнет поиск пиров. Когда узел найдет одноранговые соединения, клиент начнет синхронизацию. Клиент исполнения будет ожидать соединения от клиента консенсуса. Актуальные данные блокчейна будут доступны, как только клиент закончит синхронизацию до текущего состояния. + +##### Запуск Reth + +Этот пример запускает Reth в основной сети, используя расположение данных по умолчанию. Включает аутентификацию JSON-RPC и Engine RPC для подключения клиента консенсуса, которая определяется путем к `jwtsecret`, при этом разрешены только вызовы с `localhost`. + +```sh +reth node \ + --authrpc.jwtsecret /path/to/jwtsecret \ + --authrpc.addr 127.0.0.1 \ + --authrpc.port 8551 +``` + +См. [Настройка Reth](https://reth.rs/run/config.html?highlight=data%20directory#configuring-reth), чтобы узнать больше о каталогах данных по умолчанию. [Документация Reth](https://reth.rs/run/mainnet.html) содержит дополнительные опции и детали конфигурации. + +#### Запуск клиента консенсуса {#starting-the-consensus-client} + +Клиент консенсуса должен быть запущен с правильной конфигурацией порта для установления локального RPC-соединения с клиентом исполнения. Клиенты консенсуса должны быть запущены с открытым портом клиента исполнения в качестве аргумента конфигурации. + +Клиенту консенсуса также нужен путь к `jwt-secret` клиента исполнения для аутентификации RPC-соединения между ними. Аналогично приведенным выше примерам исполнения, каждый клиент консенсуса имеет флаг конфигурации, который принимает путь к файлу jwt-токена в качестве аргумента. Он должен совпадать с путем к `jwtsecret`, предоставленным клиенту исполнения. + +Если вы планируете запустить валидатор, убедитесь, что добавили флаг конфигурации, указывающий адрес Ethereum получателя комиссии. Именно здесь накапливаются вознаграждения в ETH для вашего валидатора. Каждый клиент консенсуса имеет опцию, например `--suggested-fee-recipient=0xabcd1`, которая принимает адрес Ethereum в качестве аргумента. + +При запуске узла Beacon в тестовой сети вы можете значительно сэкономить время синхронизации, используя общедоступную конечную точку для [синхронизации по контрольным точкам](https://notes.ethereum.org/@launchpad/checkpoint-sync). + +#### Запуск клиента консенсуса {#running-a-consensus-client} + +##### Запуск Lighthouse + +Перед запуском Lighthouse узнайте больше о том, как его установить и настроить, в [Lighthouse Book](https://lighthouse-book.sigmaprime.io/installation.html). + +```sh +lighthouse beacon_node \ + --network mainnet \ + --datadir /data/ethereum \ + --http \ + --execution-endpoint http://127.0.0.1:8551 \ + --execution-jwt /path/to/jwtsecret +``` + +##### Запуск Lodestar + +Установите программное обеспечение Lodestar, скомпилировав его или загрузив образ Docker. Узнайте больше в [документации](https://chainsafe.github.io/lodestar/) и в более подробном [руководстве по установке](https://hackmd.io/@philknows/rk5cDvKmK). + +```sh +lodestar beacon \ + --dataDir="/data/ethereum" \ + --network=mainnet \ + --eth1.enabled=true \ + --execution.urls="http://127.0.0.1:8551" \ + --jwt-secret="/path/to/jwtsecret" +``` + +##### Запуск Nimbus + +Nimbus поставляется как с клиентами консенсуса, так и с клиентами исполнения. Его можно запускать на различных устройствах, даже с очень скромной вычислительной мощностью. +После [установки зависимостей и самого Nimbus](https://nimbus.guide/quick-start.html) вы можете запустить его клиент консенсуса: + +```sh +nimbus_beacon_node \ + --network=mainnet \ + --web3-url=http://127.0.0.1:8551 \ + --rest \ + --jwt-secret="/path/to/jwtsecret" +``` + +##### Запуск Prysm + +Prysm поставляется со скриптом, который обеспечивает простую автоматическую установку. Подробности можно найти в [документации Prysm](https://prysm.offchainlabs.com/docs/install-prysm/install-with-script/). + +```sh +./prysm.sh beacon-chain \ + --mainnet \ + --datadir /data/ethereum \ + --execution-endpoint=http://localhost:8551 \ + --jwt-secret=/path/to/jwtsecret +``` + +##### Запуск Teku + +```sh +teku --network mainnet \ + --data-path "/data/ethereum" \ + --ee-endpoint http://localhost:8551 \ + --ee-jwt-secret-file "/path/to/jwtsecret" +``` + +Когда клиент консенсуса подключается к клиенту исполнения для чтения депозитного контракта и идентификации валидаторов, он также подключается к другим одноранговым узлам Beacon и начинает синхронизировать слоты консенсуса с самого начала. Как только узел Beacon достигнет текущей эпохи, Beacon API станет доступным для ваших валидаторов. Узнайте больше об [API узла Beacon](https://eth2docs.vercel.app/). + +### Добавление валидаторов {#adding-validators} + +Клиент консенсуса служит в качестве узла Beacon для подключения валидаторов. Каждый клиент консенсуса имеет собственное программное обеспечение для валидатора, подробно описанное в соответствующей документации. + +Запуск собственного валидатора позволяет осуществлять [соло-стейкинг](/staking/solo/), самый эффективный и не требующий доверия метод поддержки сети Ethereum. Однако для этого требуется депозит в размере 32 ETH. Чтобы запустить валидатор на собственном узле с меньшей суммой, вас может заинтересовать децентрализованный пул с операторами узлов без разрешений, такой как [Rocket Pool](https://rocketpool.net/node-operators). + +Самый простой способ начать стейкинг и генерацию ключей валидатора — использовать [панель запуска стейкинга в тестовой сети Hoodi](https://hoodi.launchpad.ethereum.org/), которая позволяет протестировать вашу установку, [запустив узлы на Hoodi](https://notes.ethereum.org/@launchpad/hoodi). Когда вы будете готовы к работе в основной сети, вы можете повторить эти шаги, используя [панель запуска стейкинга в основной сети](https://launchpad.ethereum.org/). + +Посмотрите [страницу о стейкинге](/staking) для обзора вариантов стейкинга. + +### Использование узла {#using-the-node} + +Клиенты исполнения предлагают [конечные точки API RPC](/developers/docs/apis/json-rpc/), которые вы можете использовать для отправки транзакций, взаимодействия с умными контрактами или их развертывания в сети Ethereum различными способами: + +- Вызывать их вручную с помощью подходящего протокола (например, используя `curl`) +- Присоединяя предоставленную консоль (например, `geth attach`) +- Реализуя их в приложениях с помощью библиотек web3, например [web3.py](https://web3py.readthedocs.io/en/stable/overview.html#overview), [ethers](https://github.com/ethers-io/ethers.js/) + +У разных клиентов различаются реализации конечных точек RPC. Но существует стандарт JSON-RPC, которые можно использовать с любым клиентом. Для обзора [прочтите документацию по JSON-RPC](/developers/docs/apis/json-rpc/). Приложения, которым требуется информация из сети Ethereum, могут использовать этот RPC. Например, популярный кошелек MetaMask позволяет вам [подключиться к вашей собственной конечной точке RPC](https://metamask.zendesk.com/hc/en-us/articles/360015290012-Using-a-Local-Node), что дает значительные преимущества в плане конфиденциальности и безопасности. + +Все клиенты консенсуса предоставляют [Beacon API](https://ethereum.github.io/beacon-APIs), который можно использовать для проверки статуса клиента консенсуса или загрузки блоков и данных консенсуса путем отправки запросов с помощью таких инструментов, как [Curl](https://curl.se). Более подробную информацию об этом можно найти в документации каждого клиента консенсуса. #### Доступ к RPC {#reaching-rpc} -Порт JSON-RPC по умолчанию — `8545`, но порты локальных конечных точек можно изменять в конфигурационном файле. По умолчанию интерфейс RPC доступен только с локального хоста компьютера. Чтобы сделать его доступным удаленно, можно сделать его открытым, сменив адрес на `0.0.0.0`. Это сделает ваш узел доступным для локальных и публичных IP-адресов. В большинстве случаев вам также нужно настроить переадресацию портов на маршрутизаторе. +Порт по умолчанию для JSON-RPC клиента исполнения — `8545`, но вы можете изменить порты локальных конечных точек в конфигурации. По умолчанию интерфейс RPC доступен только с локального хоста компьютера. Чтобы сделать его доступным удаленно, вы можете открыть его для общего доступа, изменив адрес на `0.0.0.0`. Это сделает его доступным через локальную сеть и публичные IP-адреса. В большинстве случаев вам также нужно настроить переадресацию портов на маршрутизаторе. -Совершать подобные манипуляции нужно с осторожностью, так как это позволит любому в Интернете управлять вашим узлом. Злонамеренные пользователи, имея доступ к вашему узлу, могут навредить системе или украсть ваши активы, если вы используете свой клиент как кошелек. +Подходите к открытию портов в Интернет с осторожностью, так как это позволит любому в Интернете управлять вашим узлом. Злонамеренные пользователи, имея доступ к вашему узлу, могут навредить системе или украсть ваши активы, если вы используете свой клиент как кошелек. -Эту проблему можно решить, предотвратив изменение потенциально опасных методов RPC. Например, в `geth` можно задать методы, которые можно будет использовать для модификации, через опцию командной строки: `--http.api web3,eth,txpool`. +Эту проблему можно решить, предотвратив изменение потенциально опасных методов RPC. Например, с помощью Geth вы можете объявить изменяемые методы с помощью флага: `--http.api web3,eth,txpool`. -Вы также можете размещать доступ к RPC интерфейсу, указывая службу веб-сервера, например Nginx, на локальный адрес и порт вашего клиента. +Доступ к интерфейсу RPC можно расширить за счет разработки пограничных API или приложений веб-сервера, таких как Nginx, и их подключения к локальному адресу и порту вашего клиента. Использование промежуточного уровня также может дать разработчикам возможность настроить сертификат для безопасных `https`-соединений с интерфейсом RPC. -Наиболее конфиденциальный и одновременно простой способ настроить публично доступную конечную точку — развернуть ее как сервис onion [Tor](https://www.torproject.org/). Это позволит вам получать доступ к RPC за пределами вашей локальной сети без статического публичного IP-адреса или открытых портов. Для этого: +Настройка веб-сервера, прокси-сервера или внешнего Rest API — не единственный способ предоставить доступ к конечной точке RPC вашего узла. Еще один способ настройки общедоступной конечной точки с сохранением конфиденциальности — разместить узел на вашем собственном onion-сервисе [Tor](https://www.torproject.org/). Это позволит вам получать доступ к RPC за пределами вашей локальной сети без статического публичного IP-адреса или открытых портов. Однако использование этой конфигурации может позволить доступ к конечной точке RPC только через сеть Tor, которая поддерживается не всеми приложениями и может привести к проблемам с подключением. -- Установите `tor` -- Отредактируйте конфигурационный файл `torrc`, чтобы настроить скрытую службу с адресом и портом вашего RPC клиента -- Перезапустите службу `tor` +Для этого вам нужно создать свой собственный [onion-сервис](https://community.torproject.org/onion-services/). Ознакомьтесь с [документацией](https://community.torproject.org/onion-services/setup/) по настройке onion-сервиса, чтобы разместить свой собственный. Вы можете направить его на веб-сервер с прокси на порт RPC или просто напрямую на RPC. -После перезапуска Tor вы получите имя хоста и ключи скрытой службы в желаемой директории. С этого момента ваш RPC будет доступен в сети Tor по своему имени хоста `.onion`. +Наконец, один из самых популярных способов предоставления доступа к внутренним сетям — через VPN-соединение. В зависимости от вашего варианта использования и количества пользователей, которым нужен доступ к вашему узлу, безопасное VPN-соединение может быть вариантом. [OpenVPN](https://openvpn.net/) — это полнофункциональный SSL VPN, который реализует безопасное расширение сети уровня 2 или 3 OSI с использованием стандартного протокола SSL/TLS, поддерживает гибкие методы аутентификации клиентов на основе сертификатов, смарт-карт и/или учетных данных имени пользователя/пароля, а также позволяет использовать политики контроля доступа для конкретных пользователей или групп с помощью правил брандмауэра, применяемых к виртуальному интерфейсу VPN. -### Управлением узлом {#operating-the-node} +### Эксплуатация узла {#operating-the-node} Вы должны регулярно проверять свой узел, чтобы убедиться, что он работает правильно. Время от времени может быть необходимо проводить техническое обслуживание. -#### Поддержание работы узла в сети {#keeping-node-online} +#### Поддержание узла в рабочем состоянии {#keeping-node-online} -Ваш узел необязательно должен быть постоянно подключен к сети, но желательно держать его в сети как можно дольше, чтобы поддерживать его синхронизацию с сетью. Вы можете отключить его для перезапуска, но имейте в виду: +Ваш узел не обязательно должен быть постоянно в сети, но вы должны поддерживать его в сети как можно дольше, чтобы он оставался синхронизированным с сетью. Вы можете выключить его для перезапуска, но имейте в виду, что: -- Завершение работы может занять несколько минут, если последнее состояние все еще записывается на диск. -- Принудительное отключение может повредить базу данных. -- Ваш клиент не будет синхронизироваться с сетью, и при перезапуске потребуется повторная синхронизация. +- Выключение может занять несколько минут, если последнее состояние все еще записывается на диск. +- Принудительное выключение может повредить базу данных, что потребует повторной синхронизации всего узла. +- Ваш клиент не будет синхронизироваться с сетью, и при перезапуске потребуется повторная синхронизация. Хотя узел может начать синхронизацию с того места, где он был в последний раз выключен, процесс может занять время в зависимости от того, как долго он был в автономном режиме. -_Это не относится к узлам-валидаторам слоя консенсуса._ Выключение вашего узла повлияет на все службы, которые от него зависят. Если вы запускаете узел для _стейкинга_, вы должны минимизировать время простоя, насколько это возможно. +_Это не относится к узлам-валидаторам уровня консенсуса._ Отключение вашего узла повлияет на все зависимые от него службы. Если вы запускаете узел для целей _стейкинга_, вы должны стараться минимизировать время простоя, насколько это возможно. -#### Создание клиентской службы {#creating-client-service} +#### Создание клиентских служб {#creating-client-services} -Рассмотрим возможность создания службы для автоматической активации клиента при запуске. Например, на серверах Linux хорошим решением будет создание службы, которая выполняет клиент с определенной конфигурацией от имени пользователя с ограниченными правами и перезапускается автоматически. +Рассмотрите возможность создания службы для автоматического запуска ваших клиентов при запуске. Например, на серверах Linux хорошей практикой будет создание службы, например с `systemd`, которая выполняет клиент с правильной конфигурацией от имени пользователя с ограниченными правами и автоматически перезапускается. -#### Обновление клиента {#updating-client} +#### Обновление клиентов {#updating-clients} -Вам необходимо постоянно обновлять клиентское программное обеспечение последними исправлениями безопасности, функциями и [EIP](/eips/). Перед [хард-форками](/ethereum-forks/) обязательно нужно убедиться, что вы используете правильную версию клиента. +Вам необходимо поддерживать ваше клиентское программное обеспечение в актуальном состоянии с последними исправлениями безопасности, функциями и [EIP](/eips/). Особенно перед [хард-форками](/ethereum-forks/) убедитесь, что вы используете правильные версии клиента. + +> Перед важными обновлениями сети Фонд Ethereum (EF) публикует пост в своем [блоге](https://blog.ethereum.org). Вы можете [подписаться на эти объявления](https://blog.ethereum.org/category/protocol#subscribe), чтобы получать уведомления на почту, когда ваш узел нуждается в обновлении. + +Обновление клиентов очень просто. У каждого клиента есть конкретные инструкции в своей документации, но процесс обычно заключается в том, чтобы просто загрузить последнюю версию и перезапустить клиент с новым исполняемым файлом. Клиент должен продолжить работу с того места, на котором он остановился, но с примененными обновлениями. Каждая реализация клиента имеет человекочитаемую строку версии, используемой в протоколе одноранговой связи, но она также доступна из командной строки. Эта строка версии позволяет пользователям убедиться, что они используют правильную версию, и использовать обозреватели блоков и другие аналитические инструменты, задействованные в количественной оценке распространения определенных клиентов в сети. Более подробную информацию о строках версии можно получить в документации к конкретному клиенту. #### Запуск дополнительных служб {#running-additional-services} -Запуск собственного узла дает возможность вашим службам использовать прямой доступ к клиентскому RPC сети Ethereum. Такие службы построены поверх Ethereum, примером чего могут быть [решения слоя 2](/developers/docs/scaling/#layer-2-scaling), [консенсус-клиенты](/developers/docs/nodes-and-clients/#consensus-clients) и другие части инфраструктуры Ethereum. +Запуск собственного узла дает возможность вашим службам использовать прямой доступ к клиентскому RPC сети Ethereum. Это сервисы, построенные на основе Ethereum, такие как [решения уровня 2](/developers/docs/scaling/#layer-2-scaling), бэкенд для кошельков, обозреватели блоков, инструменты для разработчиков и другая инфраструктура Ethereum. + +#### Мониторинг узла {#monitoring-the-node} -#### Наблюдение за узлом {#monitoring-the-node} +Чтобы правильно организовать наблюдение за узлом, представьте сбор метрик. Клиенты предоставляют конечные точки с метриками, и вы можете получить сравнительные данные о вашем узле. Используйте такие инструменты, как [InfluxDB](https://www.influxdata.com/get-influxdb/) или [Prometheus](https://prometheus.io/), для создания баз данных, которые вы можете превратить в визуализации и диаграммы в таких программах, как [Grafana](https://grafana.com/). Вы можете использовать это программное обеспечение и другие панели Graphana в различных конфигурациях, чтобы визуализировать свой узел и всю сеть в целом. Например, ознакомьтесь с [руководством по мониторингу Geth](/developers/tutorials/monitoring-geth-with-influxdb-and-grafana/). -«Чтобы правильно организовать наблюдение за узлом, представьте сбор метрик. Клиенты предоставляют конечные точки с метриками, и вы можете получить сравнительные данные о вашем узле. Используйте инструменты, подобные [InfluxDB](https://www.influxdata.com/get-influxdb/) или [Prometheus](https://prometheus.io/), для создания баз данных, которые вы можете превратить в визуализации и графики через такие инструменты, как [Grafana](https://grafana.com/). Вы можете использовать это программное обеспечение и другие панели Graphana в различных конфигурациях, чтобы визуализировать свой узел и всю сеть в целом. При отслеживании всегда обращайте внимание на производительность вашей системы. Во время первоначальной синхронизации узла клиентская программа может оказывать очень большую нагрузку на процессор и оперативную память. В дополнение к Graphana вы можете использовать инструменты, которая предлагает ваша операционная система, подобные `htop` или `uptime`. +При отслеживании всегда обращайте внимание на производительность вашей системы. Во время первоначальной синхронизации узла клиентская программа может оказывать очень большую нагрузку на процессор и оперативную память. В дополнение к Grafana вы можете использовать инструменты, которые предлагает ваша ОС, например `htop` или `uptime`. -## Дополнительные ресурсы {#further-reading} +## Дополнительные материалы {#further-reading} -- [Анализ требований к оборудованию, чтобы стать полностью проверенным узлом Ethereum](https://medium.com/coinmonks/analyzing-the-hardware-requirements-to-be-an-ethereum-full-validated-node-dc064f167902) — _Альберт Палау, 24 сентября 2018 г._ -- [Запуск полных узлов Ethereum: руководство для сомневающихся](https://medium.com/@JustinMLeroux/running-ethereum-full-nodes-a-guide-for-the-barely-motivated-a8a13e7a0d31) — _Джастин Леру, 7 ноября 2019 г._ -- [Запуск узла Hyperledger Besu в основной сети Ethereum: преимущества, требования и настройка](https://pegasys.tech/running-a-hyperledger-besu-node-on-the-ethereum-mainnet-benefits-requirements-and-setup/) — _Фелипе Фараджи, 7 мая 2020 г._ -- [Развертывание клиента Nethermind Ethereum со стеком мониторинга](https://medium.com/nethermind-eth/deploying-nethermind-ethereum-client-with-monitoring-stack-55ce1622edbd) _— Nethermind.eth, 8 июля 2020 г._ +- [Руководства по стейкингу Ethereum](https://github.com/SomerEsat/ethereum-staking-guides) – _Сомер Эсат, часто обновляется_ +- [Руководство | Как настроить валидатор для стейкинга Ethereum в основной сети](https://www.coincashew.com/coins/overview-eth/guide-or-how-to-setup-a-validator-on-eth2-mainnet) _– CoinCashew, часто обновляется_ +- [Руководства ETHStaker по запуску валидаторов в тестовых сетях](https://github.com/remyroy/ethstaker#guides) – _ETHStaker, регулярно обновляется_ +- [Пример приложения для запуска узлов блокчейна AWS для узлов Ethereum](https://aws-samples.github.io/aws-blockchain-node-runners/docs/Blueprints/Ethereum) — _AWS, часто обновляется_ +- [Часто задаваемые вопросы о слиянии для операторов узлов](https://notes.ethereum.org/@launchpad/node-faq-merge) — _июль 2022 г._ +- [Анализ требований к оборудованию для полного проверенного узла Ethereum](https://medium.com/coinmonks/analyzing-the-hardware-requirements-to-be-an-ethereum-full-validated-node-dc064f167902) _– Albert Palau, 24 сентября 2018 г._ +- [Запуск полных узлов Ethereum: руководство для слабо мотивированных](https://medium.com/@JustinMLeroux/running-ethereum-full-nodes-a-guide-for-the-barely-motivated-a8a13e7a0d31) _– Джастин Леру, 7 ноября 2019 г._ +- [Развертывание узла Hyperledger Besu в основной сети Ethereum: преимущества, требования и настройка](https://pegasys.tech/running-a-hyperledger-besu-node-on-the-ethereum-mainnet-benefits-requirements-and-setup/) _– Фелипе Фарагги, 7 мая 2020 г._ +- [Развертывание клиента Nethermind Ethereum со стеком мониторинга](https://medium.com/nethermind-eth/deploying-nethermind-ethereum-client-with-monitoring-stack-55ce1622edbd) _– Nethermind.eth, 8 июля 2020 г._ -## Похожие темы {#related-topics} +## Смежные темы {#related-topics} - [Узлы и клиенты](/developers/docs/nodes-and-clients/) - [Блоки](/developers/docs/blocks/) diff --git a/public/content/translations/ru/developers/docs/oracles/index.md b/public/content/translations/ru/developers/docs/oracles/index.md new file mode 100644 index 00000000000..02883330060 --- /dev/null +++ b/public/content/translations/ru/developers/docs/oracles/index.md @@ -0,0 +1,433 @@ +--- +title: "Оракулы" +description: "Оракулы предоставляют смарт-контрактам Ethereum доступ к реальным данным, открывая новые возможности использования и повышая ценность для пользователей." +lang: ru +--- + +Оракулы - это приложения, которые создают потоки данных, делающие внешние источники данных доступными для смарт-контрактов блокчейна. Это необходимо, поскольку смарт-контракты на базе Ethereum, по умолчанию, не могут получить доступ к информации, хранящейся за пределами сети блокчейна. + +Возможность выполнения смарт-контрактами операций с использованием данных вне сети повышает полезность и ценность децентрализованных приложений. Например, рынки прогноза на базе блокчейна полагаются на оракулов для предоставления информации о результатах, которую они используют для проверки прогнозов пользователей. Предположим, Алиса делает ставку 20 ETH на того, кого выберут следующим президентом США. Президент. В этом случае децентрализованному приложению рынка предсказаний понадобится оракул для подтверждения результатов выборов и анализа, имеет ли Алиса право на выплату. + +## Предварительные условия {#prerequisites} + +Эта страница предполагает, что читатель знаком с основами Ethereum, включая [узлы](/developers/docs/nodes-and-clients/), [механизмы консенсуса](/developers/docs/consensus-mechanisms/) и [EVM](/developers/docs/evm/). Вы также должны хорошо разбираться в [смарт-контрактах](/developers/docs/smart-contracts/) и [анатомии смарт-контрактов](/developers/docs/smart-contracts/anatomy/), особенно в [событиях](/glossary/#events). + +## Что такое блокчейн-оракул? {#what-is-a-blockchain-oracle} + +Оракулы — это приложения, которые получают, проверяют и передают внешнюю информацию (т. е. информацию, хранящуюся оффчейн) умным контрактам, работающим на блокчейне. Помимо «извлечения» данных из блокчейна и их трансляции в Ethereum, оракулы также могут «передавать» информацию из блокчейна во внешние системы, например, разблокировать умный замок, как только пользователь отправляет комиссию через транзакцию Ethereum. + +Без оракула смарт-контракт будет ограничиваться исключительно данными в цепочке. + +Оракулы различаются в зависимости от источника данных (один или несколько источников), моделей доверия (централизованные или децентрализованные) и архитектуры системы (немедленное чтение, публикация-подписка и запрос-ответ). Оракулы также различаются в зависимости от того, извлекают ли они внешние данные для использования в контрактах на цепочке (входные оракулы), отправляют ли информацию из блокчейна в приложения на цепочке (выходные оракулы) или выполняют вычислительные задачи на цепочке (вычислительные оракулы). + +## Зачем смарт-контрактам нужны оракулы? {#why-do-smart-contracts-need-oracles} + +Многие разработчики рассматривают смарт-контракты как код, работающий по определенным адресам в блокчейне. Однако более [общее представление об умных контрактах](/smart-contracts/) заключается в том, что это самоисполняющиеся программы, способные обеспечивать соблюдение соглашений между сторонами при выполнении определенных условий, — отсюда и термин «умные контракты». + +Использовать смарт-контракты для обеспечения соблюдения соглашений между людьми непросто, учитывая предопределенность Ethereum. [Детерминированная система](https://en.wikipedia.org/wiki/Deterministic_algorithm) — это система, которая всегда выдает одинаковые результаты при заданном начальном состоянии и определенных входных данных, что означает отсутствие случайности или вариативности в процессе вычисления выходных данных на основе входных. + +Для достижения детерминированного выполнения блокчейны ограничивают узлы достижением консенсуса по простым двоичным (истина/ложь) вопросам, используя _только_ данные, хранящиеся в самом блокчейне. Примеры таких вопросов: + +- «Подписал ли владелец счета (идентифицированный по открытому ключу) эту транзакцию с помощью парного закрытого ключа?» +- "Достаточно ли средств на этом счёте для оплаты комиссии за операцию?" +- «Действительна ли эта транзакция в контексте данного смарт-контракта?» и т. д. + +Если бы блокчейны получали информацию из внешних источников (т. е. из реального мира), детерминизма было бы невозможно достичь, что не позволило бы узлам договориться о достоверности изменений в состоянии блокчейна. Возьмем в пример смарт-контракт, который выполняет транзакцию на основе текущего обменного курса ETH-USD, полученного из традиционного ценового API. Эта цифра, скорее всего, будет часто меняться (не говоря уже о том, что API может устареть или быть взломан), а это означает, что узлы, выполняющие один и тот же код контракта, будут с разным результатам. + +Для общественного блокчейна, такого как Ethereum, с тысячами узлов по всему миру, обрабатывающих транзакции, предопределенность имеет решающее значение. В отсутствие центрального органа, выступающего в качестве источника истины, узлам необходимы механизмы для достижения одного и того же состояния после применения одних и тех же транзакций. Случай, когда узел A выполняет код смарт-контракта и получает в результате «3», а узел B получает «7» после выполнения той же транзакции, приведет к нарушению консенсуса и сведет на нет ценность Ethereum как децентрализованной вычислительной платформы. + +Этот сценарий также подчеркивает проблему проектирования блокчейнов для извлечения информации из внешних источников. Оракулы решают эту проблему, извлекая информацию из источников вне сети и сохраняя ее в блокчейне для использования смарт-контрактами. Поскольку информация, хранящаяся в цепочке, не может быть изменена и является общедоступной, узлы Ethereum могут безопасно использовать импортированные офчейн-данные Oracle для вычисления изменений состояния, не нарушая консенсус. + +Для этого оракул обычно состоит из смарт-контракта, работающего в блокчейне, и некоторых оффчейн-компонентов. Ончейн-контракт получает запросы на данные от других смарт-контрактов, которые он передает оффчейн-компоненту (называемому узлом оракула). Данный узел оракула может запрашивать источники данных (например, используя интерфейсы прикладного программирования (API)) и отправлять транзакции для сохранения запрошенных данных в хранилище смарт-контракта. + +Блокчейн-оракул устраняет информационный разрыв между блокчейном и внешней средой, создавая «гибридные смарт-контракты». Гибридный смарт-контракт - это контракт, функционирующий на основе комбинации кода ончейн-контракта и офчейн-инфраструктуры. Децентрализованные рынки прогнозов являются прекрасным примером гибридных смарт-контрактов. Другими примерами могут служить смарт-контракты по страхованию урожая. Выплата производится, когда набор оракулов подтверждает, что определенные погодные явления повлияли на урожай. + +## В чем проблема оракула? {#the-oracle-problem} + +Оракулы решают важную проблему, но также создают некоторые сложности, например: + +- Как мы можем проверить, что введенная информация была извлечена из правильного источника и не была подделана? + +- Какое гарантирование того, что эти данные всегда доступны и регулярно обновляются? + +Так называемая «проблема оракула» демонстрирует проблемы, возникающие при использовании оракулов блокчейна для отправки входных данных в смарт-контракты. Для корректного выполнения смарт-контракта данные оракула должны быть верными. Необходимость «доверять» операторам оракула в предоставлении точной информации подрывает «не требующую доверия» сущность смарт-контрактов. + +Разные оракулы предлагают разные решения их проблем, которые мы рассмотрим позже. Оракулы обычно оцениваются по тому, насколько хорошо они справляются со следующими задачами: + +1. **Корректность**: оракул не должен приводить к тому, что умные контракты будут инициировать изменения состояния на основе недействительных оффчейн-данных. Оракул должен гарантировать _подлинность_ и _целостность_ данных. Подлинность означает, что данные были получены из правильного источника, а целостность означает, что данные остались нетронутыми (т. е. не были изменены) до отправки в ончейн. + +2. **Доступность**: оракул не должен задерживать или мешать умным контрактам выполнять действия и инициировать изменения состояния. Это означает, что данные от оракула должны быть _доступны по запросу_ без перебоев. + +3. **Совместимость стимулов**: оракул должен стимулировать поставщиков оффчейн-данных предоставлять правильную информацию умным контрактам. Совместимость стимулов включает в себя _атрибутируемость_ и _подотчетность_. Атрибутируемость позволяет связать часть внешней информации с ее поставщиком, в то время как подотчетность привязывает поставщиков данных к информации, которую они предоставляют, чтобы их можно было вознаграждать или наказывать в зависимости от качества предоставленной информации. + +## Как работает сервис блокчейн-оракулов? {#how-does-a-blockchain-oracle-service-work} + +### Пользователи {#users} + +Пользователи — это сущности (т. е. умные контракты), которым для выполнения определенных действий требуется информация, внешняя по отношению к блокчейну. Базовый рабочий процесс службы оракула начинается с отправки пользователем запроса данных контракту оракула. Запросы данных обычно отвечают на некоторые или все из следующих вопросов: + +1. К каким источникам могут обращаться оффчейн-узлы за запрошенной информацией? + +2. Как репортеры обрабатывают информацию из источников данных и извлекают полезные данные? + +3. Сколько узлов оракула может участвовать в получении данных? + +4. Как следует управлять расхождениями в отчетах оракулов? + +5. Какой метод следует использовать для фильтрации представленных данных и агрегирования отчетов в единое значение? + +### Контракт оракула {#oracle-contract} + +Контракт оракула — это ончейн-компонент службы оракула. Он прослушивает запросы данных от других контрактов, ретранслирует запросы данных узлам оракула и передает возвращенные данные клиентским контрактам. Этот контракт также может выполнять некоторые вычисления над возвращенными точками данных для получения совокупного значения для отправки запрашивающему контракту. + +Контракт оракула предоставляет некоторые функции, которые клиентские контракты вызывают при выполнении запроса данных. При получении нового запроса умный контракт сгенерирует [событие журнала](/developers/docs/smart-contracts/anatomy/#events-and-logs) с подробностями запроса данных. Это уведомляет оффчейн-узлы, подписанные на журнал (обычно с помощью команды JSON-RPC `eth_subscribe`), которые приступают к извлечению данных, определенных в событии журнала. + +Ниже приведен [пример контракта оракула](https://medium.com/@pedrodc/implementing-a-blockchain-oracle-on-ethereum-cedc7e26b49e), написанный Педро Костой. Это простой сервис оракула, который может запрашивать оффчейн-API по запросу других умных контрактов и сохранять запрошенную информацию в блокчейне: + +```solidity +pragma solidity >=0.4.21 <0.6.0; + +contract Oracle { + Request[] requests; //список запросов, сделанных контракту + uint currentId = 0; //увеличивающийся идентификатор запроса + uint minQuorum = 2; //минимальное количество ответов, которые необходимо получить до объявления окончательного результата + uint totalOracleCount = 3; // Жестко заданное количество оракулов + + // определяет общий запрос к API + struct Request { + uint id; //id запроса + string urlToQuery; //URL-адрес API + string attributeToFetch; //атрибут json (ключ), который нужно получить в ответе + string agreedValue; //значение от ключа + mapping(uint => string) answers; //ответы, предоставленные оракулами + mapping(address => uint) quorum; //оракулы, которые будут запрашивать ответ (1 = оракул не голосовал, 2 = оракул проголосовал) + } + + //событие, которое запускает оракула за пределами блокчейна + event NewRequest ( + uint id, + string urlToQuery, + string attributeToFetch + ); + + //срабатывает при достижении консенсуса по окончательному результату + event UpdatedRequest ( + uint id, + string urlToQuery, + string attributeToFetch, + string agreedValue + ); + + function createRequest ( + string memory _urlToQuery, + string memory _attributeToFetch + ) + public + { + uint length = requests.push(Request(currentId, _urlToQuery, _attributeToFetch, "")); + Request storage r = requests[length-1]; + + // Жестко заданные адреса оракулов + r.quorum[address(0x6c2339b46F41a06f09CA0051ddAD54D1e582bA77)] = 1; + r.quorum[address(0xb5346CF224c02186606e5f89EACC21eC25398077)] = 1; + r.quorum[address(0xa2997F1CA363D11a0a35bB1Ac0Ff7849bc13e914)] = 1; + + // запустить событие, которое будет обнаружено оракулом за пределами блокчейна + emit NewRequest ( + currentId, + _urlToQuery, + _attributeToFetch + ); + + // увеличить id запроса + currentId++; + } + + //вызывается оракулом для записи своего ответа + function updateRequest ( + uint _id, + string memory _valueRetrieved + ) public { + + Request storage currRequest = requests[_id]; + + //проверить, находится ли оракул в списке доверенных оракулов + //и если оракул еще не голосовал + if(currRequest.quorum[address(msg.sender)] == 1){ + + //отметка о том, что этот адрес проголосовал + currRequest.quorum[msg.sender] = 2; + + //перебирать "массив" ответов, пока позиция не освободится, и сохранить полученное значение + uint tmpI = 0; + bool found = false; + while(!found) { + //найти первый пустой слот + if(bytes(currRequest.answers[tmpI]).length == 0){ + found = true; + currRequest.answers[tmpI] = _valueRetrieved; + } + tmpI++; + } + + uint currentQuorum = 0; + + //перебрать список оракулов и проверить, достаточно ли оракулов (минимальный кворум) + //проголосовали за тот же ответ, что и текущий + for(uint i = 0; i < totalOracleCount; i++){ + bytes memory a = bytes(currRequest.answers[i]); + bytes memory b = bytes(_valueRetrieved); + + if(keccak256(a) == keccak256(b)){ + currentQuorum++; + if(currentQuorum >= minQuorum){ + currRequest.agreedValue = _valueRetrieved; + emit UpdatedRequest ( + currRequest.id, + currRequest.urlToQuery, + currRequest.attributeToFetch, + currRequest.agreedValue + ); + } + } + } + } + } +} +``` + +### Узлы оракулов {#oracle-nodes} + +Узел оракула — это оффчейн-компонент сервиса оракулов. Он извлекает информацию из внешних источников, таких как API, размещенные на сторонних серверах, и помещает ее в ончейн для использования умными контрактами. Узлы оракулов прослушивают события от ончейн-контракта оракула и приступают к выполнению задачи, описанной в журнале. + +Распространенной задачей для узлов оракула является отправка запроса [HTTP GET](https://www.w3schools.com/tags/ref_httpmethods.asp) в службу API, анализ ответа для извлечения соответствующих данных, форматирование в читаемый для блокчейна вид и отправка в ончейн путем включения в транзакцию к контракту оракула. От узла оракула также может потребоваться подтвердить достоверность и целостность предоставленной информации с помощью «доказательств подлинности», которые мы рассмотрим позже. + +Вычислительные оракулы также полагаются на оффчейн-узлы для выполнения вычислительных задач, которые было бы непрактично выполнять в ончейне, учитывая стоимость газа и ограничения на размер блока. Например, узлу оракула может быть поручено сгенерировать проверяемое случайное число (например, для игр на основе блокчейна). + +## Шаблоны проектирования оракулов {#oracle-design-patterns} + +Оракулы бывают разных типов, включая _немедленное чтение_, _публикация-подписка_ и _запрос-ответ_, причем последние два являются наиболее популярными среди умных контрактов Ethereum. Здесь мы кратко опишем модели «публикация-подписка» и «запрос-ответ». + +### Оракулы по модели «публикация-подписка» {#publish-subscribe-oracles} + +Этот тип оракула предоставляет «поток данных», который другие контракты могут регулярно считывать для получения информации. В этом случае ожидается, что данные будут часто меняться, поэтому клиентские контракты должны отслеживать обновления данных в хранилище оракула. Примером может служить оракул, который предоставляет пользователям последнюю информацию о цене ETH-USD. + +### Оракулы по модели «запрос-ответ» {#request-response-oracles} + +Схема «запрос-ответ» позволяет клиентскому контракту запрашивать произвольные данные, отличные от тех, которые предоставляет оракул по модели «публикация-подписка». Оракулы по модели «запрос-ответ» идеальны, когда набор данных слишком велик для хранения в хранилище умного контракта и/или пользователям в любой момент времени потребуется лишь небольшая часть данных. + +Хотя оракулы «запрос-ответ» сложнее, чем модели «публикация-подписка», по сути они представляют собой то, что мы описали в предыдущем разделе. У оракула будет ончейн-компонент, который получает запрос данных и передает его на обработку оффчейн-узлу. + +Пользователи, инициирующие запросы данных, должны покрывать расходы на получение информации из оффчейн-источника. Клиентский контракт также должен предоставить средства для покрытия расходов на газ, понесенных контрактом оракула при возврате ответа через функцию обратного вызова, указанную в запросе. + +## Централизованные и децентрализованные оракулы {#types-of-oracles} + +### Централизованные оракулы {#centralized-oracles} + +Централизованный оракул контролируется одной организацией, ответственной за агрегирование оффчейн-информации и обновление данных контракта оракула в соответствии с запросом. Централизованные оракулы эффективны, поскольку они полагаются на единый источник истины. Они могут лучше работать в тех случаях, когда проприетарные наборы данных публикуются непосредственно владельцем с общепринятой подписью. Однако у них есть и недостатки: + +#### Низкие гарантии корректности {#low-correctness-guarantees} + +С централизованными оракулами нет способа подтвердить, верна ли предоставленная информация. Даже «авторитетные» поставщики могут стать мошенниками или быть взломаны. Если оракул будет скомпрометирован, умные контракты будут выполняться на основе неверных данных. + +#### Низкая доступность {#poor-availability} + +Централизованные оракулы не гарантируют постоянную доступность оффчейн-данных для других умных контрактов. Если поставщик решит отключить услугу или хакер захватит оффчейн-компонент оракула, ваш умный контракт подвергнется риску атаки типа «отказ в обслуживании» (DoS). + +#### Плохая совместимость стимулов {#poor-incentive-compatibility} + +Централизованные оракулы часто имеют плохо продуманные или несуществующие стимулы для поставщика данных отправлять точную/неизмененную информацию. Оплата оракулу за корректность не гарантирует честности. Эта проблема усугубляется по мере увеличения объема ценностей, контролируемых умными контрактами. + +### Децентрализованные оракулы {#decentralized-oracles} + +Децентрализованные оракулы предназначены для преодоления ограничений централизованных оракулов за счет устранения единых точек отказа. Децентрализованный сервис оракулов состоит из нескольких участников одноранговой сети, которые формируют консенсус по оффчейн-данным перед отправкой их в умный контракт. + +Децентрализованный оракул должен (в идеале) быть бездоверительным, не требующим разрешений и свободным от администрирования со стороны центральной стороны; в действительности децентрализация среди оракулов находится в определенном спектре. Существуют полудецентрализованные сети оракулов, в которых может участвовать любой, но с «владельцем», который утверждает и удаляет узлы на основе их прошлых показателей. Также существуют полностью децентрализованные сети оракулов: обычно они работают как автономные блокчейны и имеют определенные механизмы консенсуса для координации узлов и наказания за ненадлежащее поведение. + +Использование децентрализованных оракулов дает следующие преимущества: + +### Высокие гарантии корректности {#high-correctness-guarantees} + +Децентрализованные оракулы пытаются достичь корректности данных, используя различные подходы. Это включает использование доказательств, подтверждающих подлинность и целостность возвращенной информации, и требование, чтобы несколько субъектов коллективно соглашались с достоверностью оффчейн-данных. + +#### Доказательства подлинности {#authenticity-proofs} + +Доказательства подлинности — это криптографические механизмы, которые обеспечивают независимую проверку информации, полученной из внешних источников. Эти доказательства могут подтвердить источник информации и обнаружить возможные изменения данных после их извлечения. + +Примеры доказательств подлинности: + +**Доказательства безопасности транспортного уровня (TLS)**: узлы оракула часто извлекают данные из внешних источников, используя безопасное HTTP-соединение на основе протокола безопасности транспортного уровня (TLS). Некоторые децентрализованные оракулы используют доказательства подлинности для проверки сеансов TLS (т. е. для подтверждения обмена информацией между узлом и конкретным сервером) и подтверждения того, что содержимое сеанса не было изменено. + +**Аттестации доверенной среды выполнения (TEE)**: [доверенная среда выполнения](https://en.wikipedia.org/wiki/Trusted_execution_environment) (TEE) — это изолированная («песочница») вычислительная среда, отделенная от операционных процессов своей хост-системы. TEE гарантируют, что любой код приложения или данные, хранящиеся/используемые в вычислительной среде, сохраняют целостность, конфиденциальность и неизменность. Пользователи также могут сгенерировать аттестацию, чтобы доказать, что экземпляр приложения работает в доверенной среде выполнения. + +Некоторые классы децентрализованных оракулов требуют, чтобы операторы узлов оракулов предоставляли аттестации TEE. Это подтверждает пользователю, что оператор узла запускает экземпляр клиента оракула в доверенной среде выполнения. TEE предотвращают изменение или чтение кода и данных приложения внешними процессами, следовательно, эти аттестации доказывают, что узел оракула сохранил информацию в целости и конфиденциальности. + +#### Проверка информации на основе консенсуса {#consensus-based-validation-of-information} + +Централизованные оракулы полагаются на единый источник истины при предоставлении данных умным контрактам, что создает возможность публикации неточной информации. Децентрализованные оракулы решают эту проблему, полагаясь на несколько узлов оракулов для запроса оффчейн-информации. Сравнивая данные из нескольких источников, децентрализованные оракулы снижают риск передачи неверной информации в ончейн-контракты. + +Однако децентрализованные оракулы должны иметь дело с расхождениями в информации, полученной из нескольких оффчейн-источников. Чтобы свести к минимуму различия в информации и гарантировать, что данные, передаваемые контракту оракула, отражают коллективное мнение узлов оракула, децентрализованные оракулы используют следующие механизмы: + +##### Голосование/стейкинг за точность данных + +Некоторые децентрализованные сети оракулов требуют от участников голосования или стейкинга за точность ответов на запросы данных (например, «Кто победил на выборах в США в 2020 году?»). используя нативный токен сети. Затем протокол агрегации объединяет голоса и стейки и принимает ответ, поддержанный большинством, как действительный. + +Узлы, чьи ответы отклоняются от ответа большинства, наказываются путем распределения их токенов среди других, кто предоставляет более правильные значения. Принуждение узлов предоставлять залог перед предоставлением данных стимулирует честные ответы, поскольку предполагается, что они являются рациональными экономическими субъектами, стремящимися к максимизации прибыли. + +Стейкинг/голосование также защищает децентрализованные оракулы от [атак Сивиллы](/glossary/#sybil-attack), когда злоумышленники создают несколько удостоверений для манипулирования системой консенсуса. Однако стейкинг не может предотвратить «безбилетный проезд» (узлы оракула копируют информацию у других) и «ленивую проверку» (узлы оракула следуют за большинством, не проверяя информацию самостоятельно). + +##### Механизмы точки Шеллинга + +[Точка Шеллинга](https://en.wikipedia.org/wiki/Focal_point_\(game_theory\)) — это концепция теории игр, которая предполагает, что несколько субъектов всегда будут приходить к общему решению проблемы в отсутствие какой-либо коммуникации. Механизмы точки Шеллинга часто используются в децентрализованных сетях оракулов, чтобы позволить узлам достичь консенсуса по ответам на запросы данных. + +Ранней идеей для этого был [SchellingCoin](https://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/), предложенный канал данных, где участники предоставляют ответы на «скалярные» вопросы (вопросы, ответы на которые описываются величиной, например, «какова цена ETH?»), вместе с депозитом. Пользователи, предоставившие значения между 25-м и 75-м [процентилями](https://en.wikipedia.org/wiki/Percentile), вознаграждаются, в то время как те, чьи значения сильно отклоняются от медианного значения, наказываются. + +Хотя SchellingCoin сегодня не существует, ряд децентрализованных оракулов, в частности [оракулы протокола Maker](https://docs.makerdao.com/smart-contract-modules/oracle-module), используют механизм точки Шеллинга для повышения точности данных оракула. Каждый оракул Maker состоит из оффчейн P2P-сети узлов («ретрансляторов» и «фидов»), которые предоставляют рыночные цены на залоговые активы, и ончейн-контракта «Medianizer», который вычисляет медиану всех предоставленных значений. По истечении указанного периода задержки это медианное значение становится новой справочной ценой для соответствующего актива. + +Другие примеры оракулов, использующих механизмы точки Шеллинга, включают [Chainlink Offchain Reporting](https://docs.chain.link/architecture-overview/off-chain-reporting) и [Witnet](https://witnet.io/). В обеих системах ответы от узлов оракула в одноранговой сети агрегируются в одно совокупное значение, например, среднее или медианное. Узлы вознаграждаются или наказываются в зависимости от того, насколько их ответы соответствуют или отклоняются от совокупного значения. + +Механизмы точки Шеллинга привлекательны, поскольку они минимизируют ончейн-след (необходимо отправить только одну транзакцию), гарантируя при этом децентрализацию. Последнее возможно, потому что узлы должны подписать список представленных ответов, прежде чем он будет передан в алгоритм, который производит среднее/медианное значение. + +### Доступность {#availability} + +Децентрализованные сервисы оракулов обеспечивают высокую доступность оффчейн-данных для умных контрактов. Это достигается за счет децентрализации как источника оффчейн-информации, так и узлов, ответственных за передачу информации в ончейн. + +Это обеспечивает отказоустойчивость, поскольку контракт оракула может полагаться на несколько узлов (которые также полагаются на несколько источников данных) для выполнения запросов от других контрактов. Децентрализация на уровне источника _и_ оператора узла имеет решающее значение — сеть узлов-оракулов, обслуживающая информацию, полученную из одного и того же источника, столкнется с той же проблемой, что и централизованный оракул. + +Также возможно, что оракулы, основанные на стейкинге, будут наказывать операторов узлов, которые не могут быстро реагировать на запросы данных. Это значительно стимулирует узлы оракулов инвестировать в отказоустойчивую инфраструктуру и своевременно предоставлять данные. + +### Хорошая совместимость стимулов {#good-incentive-compatibility} + +Децентрализованные оракулы реализуют различные схемы стимулирования для предотвращения [византийского](https://en.wikipedia.org/wiki/Byzantine_fault) поведения среди узлов-оракулов. В частности, они достигают _атрибутируемости_ и _подотчетности_: + +1. От децентрализованных узлов оракулов часто требуется подписывать данные, которые они предоставляют в ответ на запросы данных. Эта информация помогает оценить историческую производительность узлов оракулов, чтобы пользователи могли отфильтровывать ненадежные узлы оракулов при выполнении запросов данных. Примером является [алгоритмическая система репутации](https://docs.witnet.io/intro/about/architecture#algorithmic-reputation-system) Witnet. + +2. Децентрализованные оракулы, как объяснялось ранее, могут требовать от узлов размещения стейка в подтверждение своей уверенности в истинности предоставляемых ими данных. Если претензия подтвердится, этот стейк может быть возвращен вместе с вознаграждением за честную службу. Но он также может быть урезан в случае, если информация неверна, что обеспечивает определенную меру подотчетности. + +## Применение оракулов в умных контрактах {#applications-of-oracles-in-smart-contracts} + +Ниже приведены распространенные варианты использования оракулов в Ethereum: + +### Получение финансовых данных {#retrieving-financial-data} + +Приложения [децентрализованных финансов](/defi/) (DeFi) позволяют осуществлять одноранговое кредитование, заимствование и торговлю активами. Для этого часто требуется получение различной финансовой информации, включая данные об обменных курсах (для расчета фиатной стоимости криптовалют или сравнения цен на токены) и данные о рынках капитала (для расчета стоимости токенизированных активов, таких как золото или доллар США). + +Например, протокол кредитования DeFi должен запрашивать текущие рыночные цены на активы (например, ETH), депонированные в качестве обеспечения. Это позволяет контракту определять стоимость залоговых активов и определять, какую сумму можно занять в системе. + +Популярные «ценовые оракулы» (как их часто называют) в DeFi включают в себя ценовые каналы Chainlink, [Open Price Feed](https://compound.finance/docs/prices) от Compound Protocol, [Time-Weighted Average Prices (TWAPs)](https://docs.uniswap.org/contracts/v2/concepts/core-concepts/oracles) от Uniswap и [Maker Oracles](https://docs.makerdao.com/smart-contract-modules/oracle-module). + +Разработчики должны понимать оговорки, связанные с этими ценовыми оракулами, прежде чем интегрировать их в свой проект. Эта [статья](https://blog.openzeppelin.com/secure-smart-contract-guidelines-the-dangers-of-price-oracles/) содержит подробный анализ того, что следует учитывать при планировании использования любого из упомянутых ценовых оракулов. + +Вот пример того, как получить последнюю цену ETH в вашем смарт-контракте, используя канал цен Chainlink: + +```solidity +pragma solidity ^0.6.7; + +import "@chainlink/contracts/src/v0.6/interfaces/AggregatorV3Interface.sol"; + +contract PriceConsumerV3 { + + AggregatorV3Interface internal priceFeed; + + /** + * Network: Kovan + * Aggregator: ETH/USD + * Address: 0x9326BFA02ADD2366b30bacB125260Af641031331 + */ + constructor() public { + priceFeed = AggregatorV3Interface(0x9326BFA02ADD2366b30bacB125260Af641031331); + } + + /** + * Returns the latest price + */ + function getLatestPrice() public view returns (int) { + ( + uint80 roundID, + int price, + uint startedAt, + uint timeStamp, + uint80 answeredInRound + ) = priceFeed.latestRoundData(); + return price; + } +} +``` + +### Генерация проверяемой случайности {#generating-verifiable-randomness} + +Некоторые блокчейн-приложения, такие как игры на основе блокчейна или лотерейные схемы, требуют высокого уровня непредсказуемости и случайности для эффективной работы. Однако детерминированное исполнение блокчейнов исключает случайность. + +Первоначальный подход заключался в использовании псевдослучайных криптографических функций, таких как `blockhash`, но они могли быть [подвержены манипуляциям со стороны майнеров](https://ethereum.stackexchange.com/questions/3140/risk-of-using-blockhash-other-miners-preventing-attack#:~:text=So%20while%20the%20miners%20can,to%20one%20of%20the%20players.) решающих алгоритм доказательства выполнения работы. Кроме того, [переход Ethereum на доказательство доли владения](/roadmap/merge/) означает, что разработчики больше не могут полагаться на `blockhash` для ончейн-случайности. Вместо этого альтернативный источник случайности предоставляет [механизм RANDAO](https://eth2book.info/altair/part2/building_blocks/randomness) Beacon Chain. + +Можно сгенерировать случайное значение вне сети и отправить его в ончейн, но это налагает на пользователей высокие требования к доверию. Они должны верить, что значение было действительно сгенерировано с помощью непредсказуемых механизмов и не было изменено при передаче. + +Оракулы, предназначенные для оффчейн-вычислений, решают эту проблему путем безопасной генерации случайных результатов оффчейн, которые они передают ончейн вместе с криптографическими доказательствами, подтверждающими непредсказуемость процесса. Примером является [Chainlink VRF](https://docs.chain.link/docs/chainlink-vrf/) (проверяемая случайная функция), который представляет собой доказуемо честный и защищенный от взлома генератор случайных чисел (RNG), полезный для создания надежных умных контрактов для приложений, которые полагаются на непредсказуемые результаты. + +### Получение результатов событий {#getting-outcomes-for-events} + +С помощью оракулов легко создавать умные контракты, которые реагируют на события реального мира. Сервисы оракулов делают это возможным, позволяя контрактам подключаться к внешним API через оффчейн-компоненты и потреблять информацию из этих источников данных. Например, упомянутое ранее децентрализованное приложение для прогнозирования может запросить у оракула результаты выборов из доверенного оффчейн-источника (например, Associated Press). + +Использование оракулов для получения данных, основанных на результатах реального мира, позволяет использовать другие новые варианты использования; например, для эффективной работы децентрализованного страхового продукта необходима точная информация о погоде, стихийных бедствиях и т. д. + +### Автоматизация умных контрактов {#automating-smart-contracts} + +Умные контракты не запускаются автоматически; вместо этого внешний счет (EOA) или другой аккаунт контракта должен вызывать нужные функции для выполнения кода контракта. В большинстве случаев основная часть функций контракта является общедоступной и может быть вызвана EOA и другими контрактами. + +Но есть и _частные функции_ в контракте, которые недоступны для других;, но которые имеют решающее значение для общей функциональности децентрализованного приложения. Примеры включают функцию `mintERC721Token()`, которая периодически выпускает новые NFT для пользователей, функцию для присуждения выплат на рынке прогнозов или функцию для разблокировки заблокированных в стейкинге токенов на DEX. + +Разработчикам потребуется вызывать такие функции через определенные промежутки времени, чтобы обеспечить бесперебойную работу приложения. Однако это может привести к тому, что разработчики будут терять больше времени на рутинные задачи, поэтому автоматизация выполнения умных контрактов является привлекательной. + +Некоторые децентрализованные сети оракулов предлагают услуги автоматизации, которые позволяют оффчейн-узлам оракулов запускать функции умных контрактов в соответствии с параметрами, определенными пользователем. Обычно для этого требуется «зарегистрировать» целевой контракт в службе оракула, предоставить средства для оплаты оператору оракула и указать условия или время для запуска контракта. + +Сеть [Keeper Network](https://chain.link/keepers) от Chainlink предоставляет умным контрактам опции для аутсорсинга регулярных задач по обслуживанию с минимизацией доверия и децентрализованным способом. Прочитайте официальную [документацию Keeper](https://docs.chain.link/docs/chainlink-keepers/introduction/) для получения информации о том, как сделать ваш контракт совместимым с Keeper и использовать сервис Upkeep. + +## Как использовать блокчейн-оракулы {#use-blockchain-oracles} + +Существует несколько приложений-оракулов, которые вы можете интегрировать в свое децентрализованное приложение Ethereum: + +**[Chainlink](https://chain.link/)** — _децентрализованные сети оракулов Chainlink предоставляют защищенные от несанкционированного доступа входные, выходные данные и вычисления для поддержки передовых умных контрактов на любом блокчейне._ + +**[RedStone Oracles](https://redstone.finance/)** — _RedStone — это децентрализованный модульный оракул, который предоставляет оптимизированные по газу потоки данных. Он специализируется на предоставлении ценовых потоков для новых активов, таких как токены ликвидного стейкинга (LST), токены ликвидного рестейкинга (LRT) и деривативы стейкинга Биткоина._ + +**[Chronicle](https://chroniclelabs.org/)** — _Chronicle преодолевает текущие ограничения передачи данных в ончейне, разрабатывая действительно масштабируемые, экономичные, децентрализованные и проверяемые оракулы._ + +**[Witnet](https://witnet.io/)** — _Witnet — это децентрализованный, не требующий разрешений и устойчивый к цензуре оракул, помогающий умным контрактам реагировать на реальные события с сильными криптоэкономическими гарантиями._ + +**[UMA Oracle](https://uma.xyz)** — _оптимистичный оракул UMA позволяет умным контрактам быстро получать любые данные для различных приложений, включая страхование, финансовые деривативы и рынки прогнозов._ + +**[Tellor](https://tellor.io/)** — _Tellor — это прозрачный и не требующий разрешений протокол оракула, который позволяет вашему умному контракту легко получать любые данные, когда это необходимо._ + +**[Band Protocol](https://bandprotocol.com/)** — _Band Protocol — это межсетевая платформа оракулов данных, которая агрегирует и подключает реальные данные и API к умным контрактам._ + +**[Pyth Network](https://pyth.network/)** — _сеть Pyth — это финансовая сеть оракулов от первого лица, предназначенная для публикации непрерывных данных из реального мира в ончейне в защищенной от несанкционированного доступа, децентрализованной и самодостаточной среде._ + +**[API3 DAO](https://www.api3.org/)** — _API3 DAO предоставляет решения оракулов от первого лица, которые обеспечивают большую прозрачность источника, безопасность и масштабируемость в децентрализованном решении для умных контрактов_ + +**[Supra](https://supra.com/)** — вертикально интегрированный инструментарий кроссчейн-решений, которые связывают все блокчейны, публичные (L1 и L2) или частные (корпоративные), предоставляя децентрализованные ценовые потоки оракулов, которые могут использоваться для ончейн- и оффчейн-приложений. + +**[Gas Network](https://gas.network/)** — распределенная платформа оракулов, предоставляющая данные о ценах на газ в реальном времени для различных блокчейнов. Перенося данные от ведущих поставщиков данных о ценах на газ в ончейн, Gas Network помогает повысить совместимость. Gas Network поддерживает данные для более чем 35 сетей, включая основную сеть Ethereum и многие ведущие L2. + +## Дополнительные материалы {#further-reading} + +**Статьи** + +- [Что такое блокчейн-оракул?](https://chain.link/education/blockchain-oracles) — _Chainlink_ +- [Что такое блокчейн-оракул?](https://medium.com/better-programming/what-is-a-blockchain-oracle-f5ccab8dbd72) — _Патрик Коллинз_ +- [Децентрализованные оракулы: всеобъемлющий обзор](https://medium.com/fabric-ventures/decentralised-oracles-a-comprehensive-overview-d3168b9a8841) — _Жюльен Тевенар_ +- [Реализация блокчейн-оракула на Ethereum](https://medium.com/@pedrodc/implementing-a-blockchain-oracle-on-ethereum-cedc7e26b49e) — _Педро Коста_ +- [Почему умные контракты не могут совершать вызовы API?](https://ethereum.stackexchange.com/questions/301/why-cant-contracts-make-api-calls) — _StackExchange_ +- [Итак, вы хотите использовать ценовой оракул](https://samczsun.com/so-you-want-to-use-a-price-oracle/) — _samczsun_ + +**Видео** + +- [Оракулы и расширение полезности блокчейна](https://youtu.be/BVUZpWa8vpw) — _Real Vision Finance_ + +**Учебники** + +- [Как получить текущую цену Ethereum в Solidity](https://blog.chain.link/fetch-current-crypto-price-data-solidity/) — _Chainlink_ +- [Использование данных оракула](https://docs.chroniclelabs.org/Developers/tutorials/Remix) — _Chronicle_ + +**Примеры проектов** + +- [Полный стартовый проект Chainlink для Ethereum на Solidity](https://github.com/hackbg/chainlink-fullstack) — _HackBG_ diff --git a/public/content/translations/ru/developers/docs/programming-languages/dart/index.md b/public/content/translations/ru/developers/docs/programming-languages/dart/index.md new file mode 100644 index 00000000000..ec2ff046b80 --- /dev/null +++ b/public/content/translations/ru/developers/docs/programming-languages/dart/index.md @@ -0,0 +1,32 @@ +--- +title: "Ethereum для разработчиков на Dart" +description: "Узнайте, как разрабатывать для Ethereum, используя язык Dart" +lang: ru +incomplete: true +--- + +## Начало работы с умными контрактами и языком Solidity {#getting-started-with-smart-contracts-and-solidity} + +## Руководства {#tutorials} + +- [Flutter и блокчейн — децентрализованное приложение Hello World](https://www.geeksforgeeks.org/flutter-and-blockchain-hello-world-dapp/) проведет вас по всем шагам для начала работы: + 1. Написание смарт-контракта на [Solidity](https://soliditylang.org/) + 2. Написание пользовательского интерфейса в Dart +- [Создание мобильного децентрализованного приложения с помощью Flutter](https://medium.com/dash-community/building-a-mobile-dapp-with-flutter-be945c80315a) намного короче и может подойти лучше, + если вы уже знакомы с основами +- Если вы предпочитаете учиться, просматривая видео, вы можете посмотреть [Создание своего первого блокчейн-приложения на Flutter](https://www.youtube.com/watch?v=3Eeh3pJ6PeA), которое длится около часа +- Если вы нетерпеливы, вы можете предпочесть [Создание децентрализованного блокчейн-приложения с Flutter и Dart на Ethereum](https://www.youtube.com/watch?v=jaMFEOCq_1s), которое длится всего около двадцати минут +- [Интеграция MetaMask в приложение Flutter с помощью Web3Modal от WalletConnect](https://www.youtube.com/watch?v=v_M2buHCpc4) — это короткое видео проведет вас по шагам интеграции MetaMask в ваши приложения Flutter с помощью библиотеки [Web3Modal](https://pub.dev/packages/web3modal_flutter) от WalletConnect +- [Курс для разработчиков мобильных блокчейн-приложений на Solidity и Flutter](https://youtube.com/playlist?list=PL4V4Unlk5luhQ26ERO6hWEbcUwHDSSmVH) — плейлист полного курса для full-stack разработчика мобильных блокчейн-приложений + +## Работа с клиентами Ethereum {#working-with-ethereum-clients} + +Вы можете использовать Ethereum для создания децентрализованных приложений (или "dapps"), использующих преимущества технологий криптовалюты и блокчейна. +Существует по крайней мере две поддерживаемые в настоящее время библиотеки для Dart, которые используют +[JSON-RPC API](/developers/docs/apis/json-rpc/) для Ethereum. + +1. [Web3dart от pwa.ir](https://pub.dev/packages/web3dart) +2. [Ethereum 5.0.0 от darticulate.com](https://pub.dev/packages/ethereum) + +Существуют также дополнительные библиотеки, которые позволяют вам оперировать конкретными адресами Ethereum, или которые позволяют вам получать цены на различные криптовалюты. +[Полный список можно посмотреть здесь](https://pub.dev/dart/packages?q=ethereum). diff --git a/public/content/translations/ru/developers/docs/programming-languages/delphi/index.md b/public/content/translations/ru/developers/docs/programming-languages/delphi/index.md new file mode 100644 index 00000000000..4f54120de45 --- /dev/null +++ b/public/content/translations/ru/developers/docs/programming-languages/delphi/index.md @@ -0,0 +1,56 @@ +--- +title: "Ethereum для разработчиков на Delphi" +description: "Узнайте, как разрабатывать для Ethereum с помощью языка программирования Delphi" +lang: ru +incomplete: true +--- + + + +Узнайте, как разрабатывать для Ethereum с помощью языка программирования Delphi + + + +Используйте Ethereum для создания децентрализованных приложений (или «dapp»), использующих преимущества криптовалют и технологии блокчейн. Эти децентрализованные приложения надежны, а это значит, что после развертывания в Ethereum они всегда будут работать в соответствии с программой. Они могут работать с цифровыми активами для создания новых видов финансовых приложений. Они могут быть децентрализованными, что означает, что ни одно юридическое лицо или лицо не контролирует их, и их практически невозможно подвергнуть цензуре. + +Создавайте децентрализованные приложения на базе Ethereum и взаимодействуйте со смарт-контрактами, используя язык программирования Delphi! + +## Начало работы с умными контрактами и языком Solidity {#getting-started-with-smart-contracts-and-the-solidity-language} + +**Сделайте первые шаги к интеграции Delphi с Ethereum** + +Нужен простой пример для начала? Посетите [ethereum.org/learn](/learn/) или [ethereum.org/developers](/developers/). + +- [Объяснение блокчейна](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [Понимание умных контрактов](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) +- [Напишите свой первый умный контракт](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Узнайте, как компилировать и развертывать код на Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) + +## Справочные материалы и ссылки для начинающих {#beginner-references-and-links} + +**Знакомство с библиотекой Delphereum** + +- [Что такое Delphereum?](https://github.com/svanas/delphereum/blob/master/README.md) +- [Подключение Delphi к локальному (in-memory) блокчейну](https://medium.com/@svanas/connecting-delphi-to-a-local-in-memory-blockchain-9a1512d6c5b0) +- [Подключение Delphi к основной сети Ethereum](https://medium.com/@svanas/connecting-delphi-to-the-ethereum-main-net-5faf1feffd83) +- [Подключение Delphi к смарт-контрактам](https://medium.com/@svanas/connecting-delphi-to-smart-contracts-3146b12803a1) + +**Хотите пока пропустить настройку и сразу перейти к примерам?** + +- [Смарт-контракт и Delphi за 3 минуты — часть 1](https://medium.com/@svanas/a-3-minute-smart-contract-and-delphi-61d998571d) +- [Смарт-контракт и Delphi за 3 минуты — часть 2](https://medium.com/@svanas/a-3-minute-smart-contract-and-delphi-part-2-446925faa47b) + +## Статьи для среднего уровня {#intermediate-articles} + +- [Создание подписи сообщения, подписанного Ethereum, в Delphi](https://medium.com/@svanas/generating-an-ethereum-signed-message-signature-in-delphi-75661ce5031b) +- [Перевод эфира с помощью Delphi](https://medium.com/@svanas/transferring-ether-with-delphi-b5f24b1a98a4) +- [Перевод токенов ERC-20 с помощью Delphi](https://medium.com/@svanas/transferring-erc-20-tokens-with-delphi-bb44c05b295d) + +## Продвинутые модели использования {#advanced-use-patterns} + +- [Delphi и Служба имен Ethereum (ENS)](https://medium.com/@svanas/delphi-and-ethereum-name-service-ens-4443cd278af7) +- [QuikNode, Ethereum и Delphi](https://medium.com/@svanas/quiknode-ethereum-and-delphi-f7bfc9671c23) +- [Delphi и темный лес Ethereum](https://svanas.medium.com/delphi-and-the-ethereum-dark-forest-5b430da3ad93) +- [Обмен одного токена на другой в Delphi](https://svanas.medium.com/swap-one-token-for-another-in-delphi-bcb999c47f7) + +Ищешь больше статей? Посетите [ethereum.org/developers](/developers/). diff --git a/public/content/translations/ru/developers/docs/programming-languages/dot-net/index.md b/public/content/translations/ru/developers/docs/programming-languages/dot-net/index.md new file mode 100644 index 00000000000..d169213baca --- /dev/null +++ b/public/content/translations/ru/developers/docs/programming-languages/dot-net/index.md @@ -0,0 +1,86 @@ +--- +title: "Ethereum для разработчиков на .NET" +description: "Узнайте, как разработать Ethereum с помощью проектов и инструментария .NET" +lang: ru +incomplete: true +--- + +Узнайте, как вести разработку для Ethereum с помощью проектов и инструментария на основе .NET + +Используйте Ethereum для создания децентрализованных приложений (или «dapp»), использующих преимущества криптовалют и технологии блокчейн. Эти децентрализованные приложения надежны, а это значит, что после развертывания в Ethereum они всегда будут работать в соответствии с программой. Они могут работать с цифровыми активами для создания новых видов финансовых приложений. Они могут быть децентрализованными, что означает, что ни одно юридическое лицо или лицо не контролирует их, и их практически невозможно подвергнуть цензуре. + +Создавайте децентрализованные приложения на основе Ethereum и взаимодействуйте со смарт-контрактами, используя инструменты и языки из технологического стека Microsoft - Поддержка C #, # Visual Basic .NET, F #, таких инструментов, как VSCode и Visual Studio, в .NET Framework / .NET Core / .NET Standard. Разверните блокчейн Ethereum в Azure с помощью блокчейна Microsoft Azure за считанные минуты. Привнесите любовь к .NET в Ethereum! + +## Начало работы с умными контрактами и языком Solidity {#getting-started-with-smart-contracts-and-the-solidity-language} + +**Сделайте свои первые шаги к интеграции .NET с Ethereum** + +Нужен простой пример для начала? Посетите [ethereum.org/learn](/learn/) или [ethereum.org/developers](/developers/). + +- [Объяснение блокчейна](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [Понимание умных контрактов](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) +- [Напишите свой первый умный контракт](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Узнайте, как компилировать и развертывать код на Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) + +## Справочные материалы и ссылки для начинающих {#beginner-references-and-links} + +**Представляем библиотеку Nethereum и VS Code Solidity** + +- [Nethereum, начало работы](https://docs.nethereum.com/en/latest/getting-started/) +- [Установка Solidity для VS Code](https://marketplace.visualstudio.com/items?itemName=JuanBlanco.solidity) +- [Рабочий процесс .NET-разработчика по созданию и вызову умных контрактов Ethereum](https://medium.com/coinmonks/a-net-developers-workflow-for-creating-and-calling-ethereum-smart-contracts-44714f191db2) +- [Интеграция умных контрактов с Nethereum](https://kauri.io/#collections/Getting%20Started/smart-contracts-integration-with-nethereum/#smart-contracts-integration-with-nethereumm) +- [Взаимодействие умных контрактов на блокчейне Ethereum и .NET с помощью Nethereum](https://medium.com/my-blockchain-development-daily-journey/interfacing-net-and-ethereum-blockchain-smart-contracts-with-nethereum-2fa3729ac933), также на [китайском языке](https://medium.com/my-blockchain-development-daily-journey/%E4%BD%BF%E7%94%A8nethereum%E9%80%A3%E6%8E%A5-net%E5%92%8C%E4%BB%A5%E5%A4%AA%E7%B6%B2%E5%8D%80%E5%A1%8A%E9%8F%88%E6%99%BA%E8%83%BD%E5%90%88%E7%B4%84-4a96d35ad1e1) +- [Nethereum — библиотека интеграции .NET с открытым исходным кодом для блокчейна](https://kauri.io/#collections/a%20hackathon%20survival%20guide/nethereum-an-open-source-.net-integration-library/) +- [Запись транзакций Ethereum в базу данных SQL с помощью Nethereum](https://medium.com/coinmonks/writing-ethereum-transactions-to-sql-database-using-nethereum-fd94e0e4fa36) +- [Узнайте, как легко развертывать умные контракты Ethereum с помощью C# и Visual Studio](https://koukia.ca/deploy-ethereum-smart-contracts-using-c-and-visualstudio-5be188ae928c) + +**Хотите пока пропустить настройку и сразу перейти к примерам?** + +- [Playground](http://playground.nethereum.com/) — взаимодействуйте с Ethereum и узнайте, как использовать Nethereum через браузер. + - Запросить баланс аккаунта [C#](http://playground.nethereum.com/csharp/id/1001) [VB.NET](http://playground.nethereum.com/vb/id/2001) + - Запросить баланс умного контракта ERC20 [C#](http://playground.nethereum.com/csharp/id/1005) [VB.NET](http://playground.nethereum.com/vb/id/2004) + - Перевод эфира на аккаунт [C#](http://playground.nethereum.com/csharp/id/1003) [VB.NET](http://playground.nethereum.com/vb/id/2003) + - ... И многое другое! + +## Статьи для среднего уровня {#intermediate-articles} + +- [Рабочая книга/список примеров Nethereum](http://docs.nethereum.com/en/latest/Nethereum.Workbooks/docs/) +- [Разверните свои собственные тестовые цепочки для разработки](https://github.com/Nethereum/Testchains) +- [Плагин генерации кода VSCode для Solidity](https://docs.nethereum.com/en/latest/nethereum-codegen-vscodesolidity/) +- [Unity и Ethereum: зачем и как](https://www.raywenderlich.com/5509-unity-and-ethereum-why-and-how) +- [Создание ASP.NET Core Web API для децентрализованных приложений Ethereum](https://tech-mint.com/blockchain/create-asp-net-core-web-api-for-ethereum-dapps/) +- [Использование Nethereum Web3 для внедрения системы отслеживания цепочек поставок](http://blog.pomiager.com/post/using-nethereum-web3-to-implement-a-supply-chain-traking-system4) +- [Обработка блоков в Nethereum](https://nethereum.readthedocs.io/en/latest/nethereum-block-processing-detail/), с [примером для C# Playground](http://playground.nethereum.com/csharp/id/1025) +- [Потоковая передача через Websocket в Nethereum](https://nethereum.readthedocs.io/en/latest/nethereum-subscriptions-streaming/) +- [Kaleido и Nethereum](https://kaleido.io/kaleido-and-nethereum/) +- [Quorum и Nethereum](https://github.com/Nethereum/Nethereum/blob/master/src/Nethereum.Quorum/README.md) + +## Продвинутые модели использования {#advanced-use-patterns} + +- [Azure Key Vault и Nethereum](https://github.com/Azure-Samples/bc-community-samples/tree/master/akv-nethereum) +- [Nethereum.DappHybrid](https://github.com/Nethereum/Nethereum.DappHybrid) +- [Эталонная архитектура бэкенда Ujo Nethereum](https://docs.nethereum.com/en/latest/nethereum-ujo-backend-sample/) + +## Проекты, инструменты и другие интересные материалы на .NET {#dot-net-projects-tools-and-other-fun-stuff} + +- [Nethereum Playground](http://playground.nethereum.com/) — _компилируйте, создавайте и запускайте фрагменты кода Nethereum в браузере_ +- [Nethereum Codegen Blazor](https://github.com/Nethereum/Nethereum.CodeGen.Blazor) — _генератор кода Nethereum с пользовательским интерфейсом в Blazor_ +- [Nethereum Blazor](https://github.com/Nethereum/NethereumBlazor) — _облегченный обозреватель блокчейна и простой кошелек .NET Wasm SPA_ +- [Wonka Business Rules Engine](https://docs.nethereum.com/en/latest/wonka/) — _система правил для бизнеса (как для платформы .NET, так и для платформы Ethereum), которая по своей сути управляется метаданными_ +- [Nethermind](https://github.com/NethermindEth/nethermind) — _клиент Ethereum на .NET Core для Linux, Windows и MacOS_ +- [eth-utils](https://github.com/ethereum/eth-utils/) – _вспомогательные функции для работы с кодовыми базами, связанными с Ethereum_ +- [TestChains](https://github.com/Nethereum/TestChains) — _предварительно настроенные цепочки разработки .NET для быстрого ответа (PoA)_ + +Ищешь больше статей? Посетите [ethereum.org/developers](/developers/). + +## Участники сообщества .NET {#dot-net-community-contributors} + +Участники проекта Nethereum в основном общаются в [Gitter](https://gitter.im/Nethereum/Nethereum), где каждый может задавать вопросы и отвечать на них, получать помощь или просто общаться. Не стесняйтесь создавать PR или открывать issue в [репозитории Nethereum на GitHub](https://github.com/Nethereum) или просто просмотрите множество наших дополнительных проектов и примеров. Вы также можете найти нас в [Discord](https://discord.gg/jQPrR58FxX)! + +Если вы новичок в Nethermind и вам нужна помощь, чтобы начать работу, присоединяйтесь к нашему [Discord](http://discord.gg/PaCMRFdvWT). Наши разработчики готовы ответить на ваши вопросы. Не стесняйтесь создавать PR или открывать issue в [репозитории Nethermind на GitHub](https://github.com/NethermindEth/nethermind). + +## Другие сводные списки {#other-aggregated-lists} + +[Официальный сайт Nethereum](https://nethereum.com/) +[Официальный сайт Nethermind](https://nethermind.io/) diff --git a/public/content/translations/ru/developers/docs/programming-languages/elixir/index.md b/public/content/translations/ru/developers/docs/programming-languages/elixir/index.md new file mode 100644 index 00000000000..ba67b25e7c7 --- /dev/null +++ b/public/content/translations/ru/developers/docs/programming-languages/elixir/index.md @@ -0,0 +1,55 @@ +--- +title: "Ethereum для разработчиков на Elixir" +description: "Узнайте, как разрабатывать для Ethereum, используя проекты и инструментарий на основе Elixir." +lang: ru +incomplete: false +--- + +Узнайте, как разрабатывать для Ethereum, используя проекты и инструментарий на основе Elixir. + +Используйте Ethereum для создания децентрализованных приложений (или «dapp»), использующих преимущества криптовалют и технологии блокчейн. Эти децентрализованные приложения могут быть недоверенными, что означает, что после их развертывания в Ethereum они всегда будут работать так, как запрограммировано. Они могут управлять цифровыми активами для создания новых видов финансовых приложений. Они могут быть децентрализованными, что означает, что ни одно юридическое лицо или лицо не контролирует их, и их практически невозможно подвергнуть цензуре. + +## Начало работы с умными контрактами и языком Solidity {#getting-started-with-smart-contracts-and-solidity} + +**Сделайте первые шаги к интеграции Elixir с Ethereum** + +Нужен простой пример для начала? Посетите [ethereum.org/learn](/learn/) или [ethereum.org/developers](/developers/). + +- [Объяснение блокчейна](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [Понимание умных контрактов](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) +- [Напишите свой первый умный контракт](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Узнайте, как компилировать и развертывать код на Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) + +## Статьи для начинающих {#beginner-articles} + +- [Наконец-то разбираемся в аккаунтах Ethereum](https://dev.to/q9/finally-understanding-ethereum-accounts-1kpe) +- [Ethers — первоклассная библиотека Web3 для Ethereum на Elixir](https://medium.com/@alisinabh/announcing-ethers-a-first-class-ethereum-web3-library-for-elixir-1d64e9409122) + +## Статьи для среднего уровня {#intermediate-articles} + +- [Как подписывать необработанные транзакции контрактов Ethereum с помощью Elixir](https://kohlerjp.medium.com/how-to-sign-raw-ethereum-contract-transactions-with-elixir-f8822bcc813b) +- [Смарт-контракты Ethereum и Elixir](https://medium.com/agile-alpha/ethereum-smart-contracts-and-elixir-c7c4b239ddb4) + +## Проекты и инструменты Elixir {#elixir-projects-and-tools} + +### Активные {#active} + +- [block_keys](https://github.com/ExWeb3/block_keys) — _реализация BIP32 и BIP44 на Elixir (иерархия нескольких аккаунтов для детерминированных кошельков)_ +- [ethereumex](https://github.com/mana-ethereum/ethereumex) — _клиент JSON-RPC на Elixir для блокчейна Ethereum_ +- [ethers](https://github.com/ExWeb3/elixir_ethers) — _комплексная библиотека Web3 для взаимодействия со смарт-контрактами в Ethereum с помощью Elixir_ +- [ethers_kms](https://github.com/ExWeb3/elixir_ethers_kms) — _библиотека подписи KMS для Ethers (подписывайте транзакции с помощью AWS KMS)_ +- [ex_abi](https://github.com/poanetwork/ex_abi) — _реализация парсера/декодера/кодировщика ABI для Ethereum на Elixir_ +- [ex_keccak](https://github.com/ExWeb3/ex_keccak) — _библиотека Elixir для вычисления хешей Keccak SHA3-256 с использованием NIF, созданного на основе крейта Rust tiny-keccak_ +- [ex_rlp](https://github.com/mana-ethereum/ex_rlp) — _реализация на Elixir кодировки RLP (Recursive Length Prefix) в Ethereum_ + +### Архивные / Больше не поддерживаются {#archived--no-longer-maintained} + +- [eth](https://hex.pm/packages/eth) — _Утилиты Ethereum для Elixir_ +- [exw3](https://github.com/hswick/exw3) — _Высокоуровневый клиент RPC для Ethereum на Elixir_ +- [mana](https://github.com/mana-ethereum/mana) — _реализация полной ноды Ethereum, написанная на Elixir_ + +Ищешь больше статей? Посетите [главную страницу для разработчиков](/developers/). + +## Участники сообщества Elixir {#elixir-community-contributors} + +[Канал #ethereum в Slack для Elixir](https://elixir-lang.slack.com/archives/C5RPZ3RJL) является местом для быстрорастущего сообщества и представляет собой выделенный ресурс для обсуждения любых вышеупомянутых проектов и связанных с ними тем. diff --git a/public/content/translations/ru/developers/docs/programming-languages/golang/index.md b/public/content/translations/ru/developers/docs/programming-languages/golang/index.md new file mode 100644 index 00000000000..e634614cd96 --- /dev/null +++ b/public/content/translations/ru/developers/docs/programming-languages/golang/index.md @@ -0,0 +1,84 @@ +--- +title: "Ethereum для разработчиков на Go" +description: "Узнайте, как разрабатывать для Ethereum с помощью Go проектов и инструментов" +lang: ru +incomplete: true +--- + +Узнайте, как разрабатывать для Ethereum, используя проекты и инструменты на основе Go + +Используйте Ethereum для создания децентрализованных приложений ("dapps"). Эти децентрализованные приложения надежны, а это значит, что после развертывания в Ethereum они всегда будут работать в соответствии с программой. Они децентрализованы, что означает, что они работают в одноранговой сети и не имеют единой точки отказа. Их не контролирует ни одно юридическое или физическое лицо, и их практически невозможно подвергнуть цензуре. Они могут управлять цифровыми активами, чтобы создавать новые виды приложений. + +## Начало работы с умными контрактами и языком Solidity {#getting-started-with-smart-contracts-and-solidity} + +**Сделайте свои первые шаги интеграции Go с Ethereum** + +Нужен простой пример для начала? Посетите [ethereum.org/learn](/learn/) или [ethereum.org/developers](/developers/). + +- [Объяснение блокчейна](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [Понимание умных контрактов](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) +- [Напишите свой первый умный контракт](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Узнайте, как компилировать и развертывать код на Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) +- [Руководство по контрактам](https://github.com/ethereum/go-ethereum/wiki/Contract-Tutorial) + +## Статьи и книги для начинающих {#beginner-articles-and-books} + +- [Начало работы с Geth](https://medium.com/@tzhenghao/getting-started-with-geth-c1a30b8d6458) +- [Использование Golang для подключения к Ethereum](https://www.youtube.com/watch?v=-7uChuO_VzM) +- [Развертывание смарт-контрактов Ethereum с помощью Golang](https://www.youtube.com/watch?v=pytGqQmDslE) +- [Пошаговое руководство по тестированию и развертыванию смарт-контрактов Ethereum на Go](https://hackernoon.com/a-step-by-step-guide-to-testing-and-deploying-ethereum-smart-contracts-in-go-9fc34b178d78) +- [Электронная книга: Разработка для Ethereum на Go](https://goethereumbook.org/) - _Разработка приложений Ethereum с помощью Go_ + +## Статьи и документация для среднего уровня {#intermediate-articles-and-docs} + +- [Документация Go Ethereum](https://geth.ethereum.org/docs/) - _Документация по официальной реализации Ethereum на Golang_ +- [Руководство программиста по Erigon](https://github.com/ledgerwatch/erigon/blob/devel/docs/programmers_guide/guide.md) - _Иллюстрированное руководство, включающее дерево состояний, множественные доказательства и обработку транзакций_ +- [Erigon и Stateless Ethereum](https://youtu.be/3-Mn7OckSus?t=394) - _Конференция сообщества Ethereum 2020 г. (EthCC 3)_ +- [Erigon: оптимизация клиентов Ethereum](https://www.youtube.com/watch?v=CSpc1vZQW2Q) - _Devcon 4, 2018 г._ +- [Документация Go Ethereum GoDoc](https://godoc.org/github.com/ethereum/go-ethereum) +- [Создание децентрализованного приложения на Go с помощью Geth](https://kauri.io/#collections/A%20Hackathon%20Survival%20Guide/creating-a-dapp-in-go-with-geth/) +- [Работа с частной сетью Ethereum на Golang и Geth](https://myhsts.org/tutorial-learn-how-to-work-with-ethereum-private-network-with-golang-with-geth.php) +- [Модульное тестирование контрактов Solidity в Ethereum с помощью Go](https://medium.com/coinmonks/unit-testing-solidity-contracts-on-ethereum-with-go-3cc924091281) +- [Краткий справочник по использованию Geth в качестве библиотеки](https://medium.com/coinmonks/web3-go-part-1-31c68c68e20e) + +## Продвинутые модели использования {#advanced-use-patterns} + +- [Симулированный бэкенд GETH](https://kauri.io/#collections/An%20ethereum%20test%20toolkit%20in%20Go/the-geth-simulated-backend/#_top) +- [Приложения «блокчейн как услуга» с использованием Ethereum и Quorum](https://blockchain.dcwebmakers.com/blockchain-as-a-service-apps-using-ethereum-and-quorum.html) +- [Распределенное хранилище IPFS и Swarm в блокчейн-приложениях Ethereum](https://blockchain.dcwebmakers.com/work-with-distributed-storage-ipfs-and-swarm-in-ethereum.html) +- [Мобильные клиенты: библиотеки и внутрипроцессные узлы Ethereum (Inproc)](https://github.com/ethereum/go-ethereum/wiki/Mobile-Clients:-Libraries-and-Inproc-Ethereum-Nodes) +- [Нативные децентрализованные приложения: привязки Go к контрактам Ethereum](https://github.com/ethereum/go-ethereum/wiki/Native-DApps:-Go-bindings-to-Ethereum-contracts) + +## Проекты и инструменты Go {#go-projects-and-tools} + +- [Geth / Go Ethereum](https://github.com/ethereum/go-ethereum) - _Официальная реализация протокола Ethereum на Go_ +- [Анализ кода Go Ethereum](https://github.com/ZtesoftCS/go-ethereum-code-analysis) - _Обзор и анализ исходного кода Go Ethereum_ +- [Erigon](https://github.com/ledgerwatch/erigon) - _Более быстрая производная от Go Ethereum с упором на архивные узлы_ +- [Golem](https://github.com/golemfactory/golem) - _Golem создает глобальный рынок вычислительных мощностей_ +- [Quorum](https://github.com/jpmorganchase/quorum) - _Реализация Ethereum с контролем доступа, обеспечивающая конфиденциальность данных_ +- [Prysm](https://github.com/prysmaticlabs/prysm) - _Реализация Ethereum 'Serenity' 2.0 на Go_ +- [Eth Tweet](https://github.com/yep/eth-tweet) - _Децентрализованный Twitter: сервис микроблогов, работающий на блокчейне Ethereum_ +- [Plasma MVP Golang](https://github.com/kyokan/plasma) — _Реализация на Golang и расширение спецификации минимально жизнеспособной Plasma (Minimum Viable Plasma)_ +- [Open Ethereum Mining Pool](https://github.com/sammy007/open-ethereum-pool) - _Пул для майнинга Ethereum с открытым исходным кодом_ +- [Ethereum HD-кошелек](https://github.com/miguelmota/go-ethereum-hdwallet) - _Производные HD-кошелька Ethereum на Go_ +- [Multi Geth](https://github.com/multi-geth/multi-geth) - _Поддержка многих разновидностей сетей Ethereum_ +- [Легкий клиент Geth](https://github.com/zsfelfoldi/go-ethereum/wiki/Geth-Light-Client) - _Реализация Geth для «легкого» подпротокола Ethereum_ +- [Ethereum Golang SDK](https://github.com/everFinance/goether) - _Простая реализация кошелька Ethereum и утилит на Golang_ +- [Covalent Golang SDK](https://github.com/covalenthq/covalent-api-sdk-go) - _Эффективный доступ к данным блокчейна через Go SDK для более чем 200 блокчейнов_ + +Ищешь больше статей? Посетите [ethereum.org/developers](/developers/) + +## Участники сообщества Go {#go-community-contributors} + +- [Geth в Discord](https://discordapp.com/invite/nthXNEv) +- [Geth в Gitter](https://gitter.im/ethereum/go-ethereum) +- [Gophers в Slack](https://invite.slack.golangbridge.org/) - [канал #ethereum](https://gophers.slack.com/messages/C9HP1S9V2) +- [StackExchange — Ethereum](https://ethereum.stackexchange.com/) +- [Multi Geth в Gitter](https://gitter.im/ethoxy/multi-geth) +- [Ethereum в Gitter](https://gitter.im/ethereum/home) +- [Легкий клиент Geth в Gitter](https://gitter.im/ethereum/light-client) + +## Другие сводные списки {#other-aggregated-lists} + +- [Отличные ресурсы по Ethereum](https://github.com/btomashvili/awesome-ethereum) +- [Consensys: полный список инструментов для разработчиков Ethereum](https://media.consensys.net/an-definitive-list-of-ethereum-developer-tools-2159ce865974) | [Источник на GitHub](https://github.com/ConsenSys/ethereum-developer-tools-list) diff --git a/public/content/translations/ru/developers/docs/programming-languages/index.md b/public/content/translations/ru/developers/docs/programming-languages/index.md new file mode 100644 index 00000000000..e218834621a --- /dev/null +++ b/public/content/translations/ru/developers/docs/programming-languages/index.md @@ -0,0 +1,32 @@ +--- +title: "Языки программирования" +description: "Ресурс Ethereum" +lang: ru +--- + +Распространенное заблуждение заключается в том, что для разработки на Ethereum необходимо писать [смарт-контракты](/developers/docs/smart-contracts/). Это неправда. +Одна из прекрасных особенностей сети Ethereum и ее сообщества заключается в том, что вы можете [участвовать](/community/), используя практически любой язык программирования. + +Ethereum и его сообщество поддерживают открытый исходный код. Вы можете найти проекты сообщества - клиентские реализации, API, фреймворки разработки, инструменты тестирования - на самых разных языках. + +## Выберите свой язык {#data} + +Выберите предпочтительный для Вас язык программирования, чтобы найти проекты, ресурсы и виртуальные сообщества: + +- [Ethereum для разработчиков на Dart](/developers/docs/programming-languages/dart/) +- [Ethereum для разработчиков на Delphi](/developers/docs/programming-languages/delphi/) +- [Ethereum для разработчиков на .NET](/developers/docs/programming-languages/dot-net/) +- [Ethereum для разработчиков на Elixir](/developers/docs/programming-languages/elixir/) +- [Ethereum для разработчиков на Go](/developers/docs/programming-languages/golang/) +- [Ethereum для разработчиков на Java](/developers/docs/programming-languages/java/) +- [Ethereum для разработчиков на JavaScript](/developers/docs/programming-languages/javascript/) +- [Ethereum для разработчиков на Python](/developers/docs/programming-languages/python/) +- [Ethereum для разработчиков на Ruby](/developers/docs/programming-languages/ruby/) +- [Ethereum для разработчиков на Rust](/developers/docs/programming-languages/rust/) + +### Что делать, если мой язык не поддерживается {#other-lang} + +Если вы хотите добавить ссылку на ресурсы или указать виртуальное сообщество для дополнительного языка программирования, вы можете запросить новую страницу, [создав issue](https://github.com/ethereum/ethereum-org-website/issues/new/choose). + +Если вы просто хотите написать код для взаимодействия с блокчейном, используя неподдерживаемый в настоящее время язык, +вы можете использовать [интерфейс JSON-RPC](/developers/docs/apis/json-rpc/) для подключения к сети Ethereum. Любой язык программирования, который может использовать TCP/IP, может использовать этот интерфейс. diff --git a/public/content/translations/ru/developers/docs/programming-languages/java/index.md b/public/content/translations/ru/developers/docs/programming-languages/java/index.md new file mode 100644 index 00000000000..131558d2542 --- /dev/null +++ b/public/content/translations/ru/developers/docs/programming-languages/java/index.md @@ -0,0 +1,64 @@ +--- +title: "Ethereum для разработчиков на Java" +description: "Узнайте, как разрабатывать для Ethereum с использованием проектов и инструментов на основе Java" +lang: ru +incomplete: true +--- + +Узнайте, как разрабатывать для Ethereum с использованием проектов и инструментов на основе Java + +Используйте Ethereum для создания децентрализованных приложений (или «dapp»), использующих преимущества криптовалют и технологии блокчейн. Эти децентрализованные приложения надежны, а это значит, что после развертывания в Ethereum они всегда будут работать в соответствии с программой. Они могут работать с цифровыми активами для создания новых видов финансовых приложений. Они могут быть децентрализованными, что означает, что ни одно юридическое лицо или лицо не контролирует их, и их практически невозможно подвергнуть цензуре. + +## Начало работы с умными контрактами и языком Solidity {#getting-started-with-smart-contracts-and-solidity} + +**Сделайте свои первые шаги к интеграции Java с Ethereum** + +Нужен простой пример для начала? Посетите [ethereum.org/learn](/learn/) или [ethereum.org/developers.](/developers/) + +- [Объяснение блокчейна](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [Понимание умных контрактов](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) +- [Напишите свой первый умный контракт](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Узнайте, как компилировать и развертывать код на Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) + +## Работа с клиентами Ethereum {#working-with-ethereum-clients} + +Узнайте, как использовать [Web3J](https://github.com/web3j/web3j) и Hyperledger Besu — два ведущих Java-клиента для Ethereum + +- [Подключение к клиенту Ethereum с помощью Java, Eclipse и Web3J](https://kauri.io/article/b9eb647c47a546bc95693acc0be72546/connecting-to-an-ethereum-client-with-java-eclipse-and-web3j) +- [Управление аккаунтом Ethereum с помощью Java и Web3j](https://kauri.io/article/925d923e12c543da9a0a3e617be963b4/manage-an-ethereum-account-with-java-and-web3j) +- [Создание Java-оболочки из вашего умного контракта](https://kauri.io/article/84475132317d4d6a84a2c42eb9348e4b/generate-a-java-wrapper-from-your-smart-contract) +- [Взаимодействие с умным контрактом Ethereum](https://kauri.io/article/14dc434d11ef4ee18bf7d57f079e246e/interacting-with-an-ethereum-smart-contract-in-java) +- [Прослушивание событий умного контракта Ethereum](https://kauri.io/article/760f495423db42f988d17b8c145b0874/listening-for-ethereum-smart-contract-events-in-java) +- [Использование Besu (Pantheon), Java-клиента Ethereum, в Linux](https://kauri.io/article/276dd27f1458443295eea58403fd6965/using-pantheon-the-java-ethereum-client-with-linux) +- [Запуск узла Hyperledger Besu (Pantheon) в интеграционных тестах Java](https://kauri.io/article/7dc3ecc391e54f7b8cbf4e5fa0caf780/running-a-pantheon-node-in-java-integration-tests) +- [Памятка по Web3j](https://kauri.io/web3j-cheat-sheet-\(java-ethereum\)/5dfa1ea941ac3d0001ce1d90/c) + +Узнайте, как использовать [ethers-kt](https://github.com/Kr1ptal/ethers-kt), асинхронную, высокопроизводительную библиотеку Kotlin для взаимодействия с блокчейнами на основе EVM. Ориентация на платформы JVM и Android. + +- [Перевод токенов ERC20](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/abi/TransferERC20.kt) +- [Обмен на UniswapV2 с прослушиванием событий](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/tokenswapwitheventlistening/TokenSwapWithEventListening.kt) +- [Трекер баланса ETH / ERC20](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/balancetracker/BalanceTracker.kt) + +## Статьи для среднего уровня {#intermediate-articles} + +- [Управление хранилищем в Java-приложении с помощью IPFS](https://kauri.io/article/3e8494f4f56f48c4bb77f1f925c6d926/managing-storage-in-a-java-application-with-ipfs) +- [Управление токенами ERC20 в Java с помощью Web3j](https://kauri.io/article/d13e911bbf624108b1d5718175a5e0a0/manage-erc20-tokens-in-java-with-web3j) +- [Менеджеры транзакций Web3j](https://kauri.io/article/4cb780bb4d0846438d11885a25b6d7e7/web3j-transaction-managers) + +## Продвинутые модели использования {#advanced-use-patterns} + +- [Использование Eventeum для создания кэша данных смарт-контракта на Java](https://kauri.io/article/fe81ee9612eb4e5a9ab72790ef24283d/using-eventeum-to-build-a-java-smart-contract-data-cache) + +## Проекты и инструменты на Java {#java-projects-and-tools} + +- [Web3J (библиотека для взаимодействия с клиентами Ethereum)](https://github.com/web3j/web3j) +- [ethers-kt (асинхронная, высокопроизводительная библиотека Kotlin/Java/Android для блокчейнов на основе EVM.)](https://github.com/Kr1ptal/ethers-kt) +- [Eventeum (прослушиватель событий)](https://github.com/ConsenSys/eventeum) +- [Mahuta (инструменты разработчика для IPFS)](https://github.com/ConsenSys/mahuta) + +Ищешь больше статей? Посетите [ethereum.org/developers.](/developers/) + +## Участники сообщества Java {#java-community-contributors} + +- [IO Builders](https://io.builders) +- [Kauri](https://kauri.io) diff --git a/public/content/translations/ru/developers/docs/programming-languages/javascript/index.md b/public/content/translations/ru/developers/docs/programming-languages/javascript/index.md new file mode 100644 index 00000000000..d56b51da0a6 --- /dev/null +++ b/public/content/translations/ru/developers/docs/programming-languages/javascript/index.md @@ -0,0 +1,72 @@ +--- +title: "Ethereum для разработчиков на JavaScript" +description: "Узнайте как зарабатывать c помощью Ethereum используя проекты и инструменты на JavaScript." +lang: ru +--- + +JavaScript - самый популярный язык в системе Ethereum. Фактически существует [команда](https://github.com/ethereumjs), которая занимается переносом как можно большего количества возможностей Ethereum в JavaScript. + +Есть возможность писать на JavaScript (или чем-то похожем) на [всех уровнях стека](/developers/docs/ethereum-stack/). + +## Взаимодействие с Ethereum {#interact-with-ethereum} + +### Библиотеки API для JavaScript {#javascript-api-libraries} + +Если вы хотите писать на JavaScript, чтобы запрашивать данные из блокчейна, отправлять транзакции и выполнять другие действия, то наиболее удобным способом для этого будет использование [библиотеки API для JavaScript](/developers/docs/apis/javascript/). Эти API позволяют разработчикам легко взаимодействовать с [узлами в сети Ethereum](/developers/docs/nodes-and-clients/). + +Вы можете использовать эти библиотеки для взаимодействия со смарт-контрактами на Ethereum, чтобы можно было создать децентрализованное приложение, где вы сможете использовать JavaScript для взаимодействия с уже существующими контрактами. + +**Ознакомьтесь** + +- [Web3.js](https://web3js.readthedocs.io) +- [Ethers.js](https://ethers.org) — _включает реализацию кошелька Ethereum и утилиты на JavaScript и TypeScript._ +- [viem](https://viem.sh) — _интерфейс TypeScript для Ethereum, предоставляющий низкоуровневые примитивы без сохранения состояния для взаимодействия с Ethereum._ +- [Drift](https://ryangoree.github.io/drift/) — _метабиблиотека TypeScript со встроенным кэшированием, хуками и тестовыми моками для упрощения разработки на Ethereum с использованием различных библиотек Web3._ + +### Умные контракты {#smart-contracts} + +Если вы JavaScript-разработчик и хотите написать собственный смарт-контракт, вам стоит ознакомиться с [Solidity](https://solidity.readthedocs.io). Это очень популярный язык смарт-контрактов, и он синтаксически похож на JavaScript, что может упростить его изучение. + +Подробнее о [смарт-контрактах](/developers/docs/smart-contracts/). + +## Понимание протокола {#understand-the-protocol} + +### Виртуальная машина Ethereum {#the-ethereum-virtual-machine} + +Существует реализация [виртуальной машины Ethereum](/developers/docs/evm/) на JavaScript. Она поддерживает последние форк-правила. Правила Fork означают изменения, появившиеся в EVM в результате запланированных улучшений. + +Он разделен на различные пакеты JavaScript, которые вы можете прочесть, чтобы лучше понять: + +- Аккаунты +- Блоки +- Сам блокчейн +- Транзакции +- И другое... + +Это поможет вам понять такие вещи как: "Какова структура данных в аккаунте?". + +Если вы пожелаете прочитать код, JavaScript сможет стать отличным вариантом для чтения наших документов. + +**Ознакомьтесь с EVM** +[`@ethereumjs/evm`](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master/packages/evm) + +### Узлы и клиенты {#nodes-and-clients} + +Клиент Ethereumjs находится в активной разработке и позволяет вам погрузиться в понимание того, как работают Ethereum клиенты на языке, который вам понятен; JavaScript! + +**Ознакомьтесь с клиентом** +[`@ethereumjs/client`](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master/packages/client) + +## Другие проекты {#other-projects} + +В мире Ethereum JavaScript происходит множество других вещей, в том числе: + +- библиотеки утилит кошелька. +- инструменты для генерации, импорта и экспорта ключей Ethereum. +- реализация `merkle-patricia-tree` — структуры данных, описанной в Желтой книге Ethereum. + +Изучите то, что вас больше всего интересует, в [репозитории EthereumJS](https://github.com/ethereumjs). + +## Дополнительные материалы {#further-reading} + +_Знаете ресурс сообщества, который вам пригодился? Измените эту страницу и добавьте его!_ diff --git a/public/content/translations/ru/developers/docs/programming-languages/python/index.md b/public/content/translations/ru/developers/docs/programming-languages/python/index.md new file mode 100644 index 00000000000..fc604e1c22d --- /dev/null +++ b/public/content/translations/ru/developers/docs/programming-languages/python/index.md @@ -0,0 +1,99 @@ +--- +title: "Ethereum для разработчиков на Python" +description: "Узнайте, как разрабатывать для Ethereum с использованием проектов и инструментов на основе Python" +lang: ru +incomplete: true +--- + +Узнайте, как разрабатывать для Ethereum, используя проекты и инструментарий на основе Python + +Используйте Ethereum для создания децентрализованных приложений (или «dapp»), использующих преимущества криптовалют и технологии блокчейн. Эти децентрализованные приложения надежны, а это значит, что после развертывания в Ethereum они всегда будут работать в соответствии с программой. Они могут работать с цифровыми активами для создания новых видов финансовых приложений. Они могут быть децентрализованными, что означает, что ни одно юридическое лицо или лицо не контролирует их, и их практически невозможно подвергнуть цензуре. + +## Начало работы с умными контрактами и языком Solidity {#getting-started-with-smart-contracts-and-solidity} + +**Начни программировать на Python вместе с Ethereum** + +Нужен простой пример для начала? Посетите [ethereum.org/learn](/learn/) или [ethereum.org/developers](/developers/). + +- [Объяснение блокчейна](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [Понимание умных контрактов](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) +- [Напишите свой первый умный контракт](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Узнайте, как компилировать и развертывать код на Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) +- [Отчет о состоянии Python в блокчейне за 2023 год](https://tradingstrategy.ai/blog/the-state-of-python-in-blockchain-in-2023) + +## Статьи для начинающих {#beginner-articles} + +- [Обзор web3.py](https://web3py.readthedocs.io/en/latest/overview.html) +- [Обзор экосистемы Python для Ethereum](https://snakecharmers.ethereum.org/python-ecosystem/) +- [Руководство по Ethereum для разработчиков (на Python)](https://snakecharmers.ethereum.org/a-developers-guide-to-ethereum-pt-1/) +- [Достойный приза: руководство по хакатону Ethereum на Python](https://snakecharmers.ethereum.org/prize-worthy/) +- [Введение в умные контракты с Vyper](https://kauri.io/#collections/Getting%20Started/an-introduction-to-smart-contracts-with-vyper/) +- [Как разработать контракт Ethereum с помощью Python Flask?](https://medium.com/coinmonks/how-to-develop-ethereum-contract-using-python-flask-9758fe65976e) +- [Введение в Web3.py · Ethereum для разработчиков на Python](https://www.dappuniversity.com/articles/web3-py-intro) +- [Как вызвать функцию умного контракта с помощью Python и web3.py](https://stackoverflow.com/questions/57580702/how-to-call-a-smart-contract-function-using-python-and-web3-py) + +## Статьи для среднего уровня {#intermediate-articles} + +- [Друзья web3.py: введение в Ape](https://snakecharmers.ethereum.org/intro-to-ape/) +- [Разработка децентрализованных приложений для программистов на Python](https://levelup.gitconnected.com/dapps-development-for-python-developers-f52b32b54f28) +- [Создание интерфейса Ethereum на Python: часть 1](https://hackernoon.com/creating-a-python-ethereum-interface-part-1-4d2e47ea0f4d) +- [Умные контракты Ethereum на Python: всеобъемлющее (почти) руководство](https://hackernoon.com/ethereum-smart-contracts-in-python-a-comprehensive-ish-guide-771b03990988) + +## Продвинутые модели использования {#advanced-use-patterns} + +- [Шаблоны web3.py: подписки на события в реальном времени](https://snakecharmers.ethereum.org/subscriptions/) +- [Шаблоны web3.py: WebSocketProvider](https://snakecharmers.ethereum.org/websocketprovider/) +- [Компиляция, развертывание и вызов умного контракта Ethereum с помощью Python](https://yohanes.gultom.id/2018/11/28/compiling-deploying-and-calling-ethereum-smartcontract-using-python/) +- [Анализ умных контрактов Solidity с помощью Slither](https://kauri.io/#collections/DevOps/analyze-solidity-smart-contracts-with-slither/#analyze-solidity-smart-contracts-with-slither) +- [Руководство по финтеху на блокчейне: кредитование и заимствование с помощью Python](https://blog.chain.link/blockchain-fintech-defi-tutorial-lending-borrowing-python/) + +## Архивные статьи + +- [Разверните свой собственный токен ERC20 с помощью Python и Brownie](https://betterprogramming.pub/python-blockchain-token-deployment-tutorial-create-an-erc20-77a5fd2e1a58) +- [Использование Brownie и Python для развертывания умных контрактов](https://dev.to/patrickalphac/using-brownie-for-to-deploy-smart-contracts-1kkp) +- [Создание NFT на OpenSea с помощью Brownie](https://www.freecodecamp.org/news/how-to-make-an-nft-and-render-on-opensea-marketplace/) + +## Проекты и инструменты на Python {#python-projects-and-tools} + +### Активные: {#active} + +- [Web3.py](https://github.com/ethereum/web3.py) – _библиотека Python для взаимодействия с Ethereum_ +- [Vyper](https://github.com/ethereum/vyper/) – _язык умных контрактов в стиле Python для EVM_ +- [Ape](https://github.com/ApeWorX/ape) – _инструмент для разработки умных контрактов для разработчиков на Python, специалистов по данным и специалистов по безопасности_ +- [py-evm](https://github.com/ethereum/py-evm) – _реализация виртуальной машины Ethereum_ +- [eth-tester](https://github.com/ethereum/eth-tester) – _инструменты для тестирования приложений на базе Ethereum_ +- [eth-utils](https://github.com/ethereum/eth-utils/) – _вспомогательные функции для работы с кодовыми базами, связанными с Ethereum_ +- [py-solc-x](https://pypi.org/project/py-solc-x/) – _оболочка на Python для компилятора Solidity solc с поддержкой версии 0.5.x_ +- [pymaker](https://github.com/makerdao/pymaker) – _Python API для контрактов Maker_ +- [siwe](https://github.com/signinwithethereum/siwe-py) – _Sign in with Ethereum (siwe) для Python_ +- [Web3 DeFi для интеграции с Ethereum](https://github.com/tradingstrategy-ai/web3-ethereum-defi) – _пакет Python с готовыми интеграциями для ERC-20, Uniswap и других популярных проектов_ +- [Wake](https://getwake.io) – _универсальный фреймворк на Python для тестирования контрактов, фаззинга, развертывания, сканирования уязвимостей и навигации по коду (языковой сервер – [Tools for Solidity](https://marketplace.visualstudio.com/items?itemName=AckeeBlockchain.tools-for-solidity))_ + +### Архивные / Больше не поддерживаются: {#archived--no-longer-maintained} + +- [Trinity](https://github.com/ethereum/trinity) – _клиент Ethereum на Python_ +- [Mamba](https://github.com/arjunaskykok/mamba) – _фреймворк для написания, компиляции и развертывания умных контрактов, написанных на языке Vyper_ +- [Brownie](https://github.com/eth-brownie/brownie) – _фреймворк на Python для развертывания, тестирования и взаимодействия с умными контрактами Ethereum_ +- [pydevp2p](https://github.com/ethereum/pydevp2p) – _реализация стека P2P Ethereum_ +- [py-wasm](https://github.com/ethereum/py-wasm) – _реализация интерпретатора WebAssembly на Python_ + +Ищешь больше статей? Посетите [ethereum.org/developers](/developers/). + +## Проекты, использующие инструментарий Python {#projects-using-python-tooling} + +Следующие проекты на основе Ethereum используют инструменты, упомянутые на этой странице. Соответствующие репозитории с открытым исходным кодом служат хорошим справочным материалом для примера кода и лучших практик. + +- [Yearn Finance](https://yearn.finance/) и [репозиторий контрактов хранилищ Yearn](https://github.com/yearn/yearn-vaults) +- [Curve](https://www.curve.finance/) и [репозиторий умных контрактов Curve](https://github.com/curvefi/curve-contract) +- [BadgerDAO](https://badger.com/) и [умные контракты, использующие инструментарий Brownie](https://github.com/Badger-Finance/badger-system) +- [Sushi](https://sushi.com/) использует [Python для управления и развертывания своих контрактов вестинга](https://github.com/sushiswap/sushi-vesting-protocols) +- [Alpha Finance](https://alphafinance.io/), известная благодаря Alpha Homora, использует [Brownie для тестирования и развертывания умных контрактов](https://github.com/AlphaFinanceLab/alpha-staking-contract) + +## Обсуждение в сообществе Python {#python-community-contributors} + +- [Discord-сервер сообщества Ethereum и Python](https://discord.gg/9zk7snTfWe) для обсуждения Web3.py и других фреймворков на Python +- [Discord-сервер Vyper](https://discord.gg/SdvKC79cJk) для обсуждения программирования умных контрактов на Vyper + +## Другие сводные списки {#other-aggregated-lists} + +На вики-странице Vyper есть [невероятный список ресурсов для Vyper](https://github.com/vyperlang/vyper/wiki/Vyper-tools-and-resources) \ No newline at end of file diff --git a/public/content/translations/ru/developers/docs/programming-languages/ruby/index.md b/public/content/translations/ru/developers/docs/programming-languages/ruby/index.md new file mode 100644 index 00000000000..ee1f24be64d --- /dev/null +++ b/public/content/translations/ru/developers/docs/programming-languages/ruby/index.md @@ -0,0 +1,60 @@ +--- +title: "Ethereum для разработчиков на Ruby" +description: "Узнайте, как разрабатывать для Ethereum, используя проекты и инструменты на основе Ruby." +lang: ru +incomplete: false +--- + +Узнайте, как разрабатывать для Ethereum, используя проекты и инструменты на основе Ruby. + +Используйте Ethereum для создания децентрализованных приложений (или «dapp»), использующих преимущества криптовалют и технологии блокчейн. Эти децентрализованные приложения могут быть недоверенными, что означает, что после их развертывания в Ethereum они всегда будут работать так, как запрограммировано. Они могут управлять цифровыми активами для создания новых видов финансовых приложений. Они могут быть децентрализованными, что означает, что ни одно юридическое лицо или лицо не контролирует их, и их практически невозможно подвергнуть цензуре. + +## Начало работы с умными контрактами и языком Solidity {#getting-started-with-smart-contracts-and-solidity} + +**Сделайте свои первые шаги по интеграции Ruby в Ethereum** + +Нужен простой пример для начала? Посетите [ethereum.org/learn](/learn/) или [ethereum.org/developers](/developers/). + +- [Объяснение блокчейна](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [Понимание умных контрактов](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) +- [Напишите свой первый умный контракт](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Узнайте, как компилировать и развертывать код на Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) + +## Статьи для начинающих {#beginner-articles} + +- [Наконец-то разбираемся в аккаунтах Ethereum](https://dev.to/q9/finally-understanding-ethereum-accounts-1kpe) +- [Наконец-то аутентификация пользователей Rails с помощью MetaMask](https://dev.to/q9/finally-authenticating-rails-users-with-metamask-3fj) +- [Как подключиться к сети Ethereum с помощью Ruby](https://www.quicknode.com/guides/web3-sdks/how-to-connect-to-the-ethereum-network-using-ruby) +- [Как сгенерировать новый адрес Ethereum в Ruby](https://www.quicknode.com/guides/web3-sdks/how-to-generate-a-new-ethereum-address-in-ruby) + +## Статьи для среднего уровня {#intermediate-articles} + +- [Приложение на блокчейне с помощью Ruby](https://www.nopio.com/blog/blockchain-app-ruby/) +- [Использование Ruby, подключенного к Ethereum, для выполнения смарт-контракта](https://titanwolf.org/Network/Articles/Article?AID=87285822-9b25-49d5-ba2a-7ad95fff7ef9) + +## Проекты и инструменты Ruby {#ruby-projects-and-tools} + +### Активные {#active} + +- [eth.rb](https://github.com/q9f/eth.rb) - _Библиотека Ruby и RPC-клиент для работы с аккаунтами, сообщениями и транзакциями Ethereum_ +- [keccak.rb](https://github.com/q9f/keccak.rb) - _Хеш Keccak (SHA3), используемый в Ethereum_ +- [siwe-ruby](https://github.com/signinwithethereum/siwe-ruby) - _Реализация на Ruby функции «Вход с помощью Ethereum»_ +- [siwe-rails](https://github.com/signinwithethereum/siwe-rails) - _Gem для Rails, который добавляет локальные маршруты входа через SIWE_ +- [siwe-rails-examples](https://github.com/signinwithethereum/siwe-rails-examples) - _Пример SIWE с использованием Ruby on Rails и пользовательского контроллера_ +- [omniauth-siwe](https://github.com/signinwithethereum/omniauth-siwe) - _Стратегия OmniAuth для входа с помощью Ethereum (SIWE)_ +- [omniauth-nft](https://github.com/valthon/omniauth-nft) - _Стратегия OmniAuth для аутентификации через владение NFT_ +- [ethereum-on-rails](https://github.com/q9f/ethereum-on-rails) - _Шаблон Ethereum on Rails, позволяющий подключить MetaMask к Ruby on Rails_ + +### Архивные / Больше не поддерживаются {#archived--no-longer-maintained} + +- [web3-eth](https://github.com/spikewilliams/vtada-ethereum) - _Вызов методов RPC узла Ethereum с помощью Ruby_ +- [ethereum_tree](https://github.com/longhoangwkm/ethereum_tree) - _Библиотека Ruby для генерации адресов ETH из иерархически детерминированного кошелька в соответствии со стандартом BIP32_ +- [etherlite](https://github.com/budacom/etherlite) - _Интеграция Ethereum для Ruby on Rails_ +- [ethereum.rb](https://github.com/EthWorks/ethereum.rb) - _Клиент Ethereum на Ruby, использующий интерфейс JSON-RPC для отправки транзакций, создания контрактов и взаимодействия с ними, а также полезный набор инструментов для работы с узлом Ethereum_ +- [omniauth-ethereum.rb](https://github.com/q9f/omniauth-ethereum.rb) - _Реализует стратегию провайдера Ethereum для OmniAuth_ + +Ищешь больше статей? Посетите [главную страницу для разработчиков](/developers/). + +## Участники сообщества Ruby {#ruby-community-contributors} + +[Telegram-группа Ethereum Ruby](https://t.me/ruby_eth) — это быстрорастущее сообщество и специальный ресурс для обсуждения любого из вышеупомянутых проектов и связанных с ними тем. diff --git a/public/content/translations/ru/developers/docs/programming-languages/rust/index.md b/public/content/translations/ru/developers/docs/programming-languages/rust/index.md new file mode 100644 index 00000000000..6bde54a902c --- /dev/null +++ b/public/content/translations/ru/developers/docs/programming-languages/rust/index.md @@ -0,0 +1,65 @@ +--- +title: "Ethereum для разработчиков на Rust" +description: "Узнайте, как разрабатывать для Ethereum, используя проекты и инструменты на основе ржавчины" +lang: ru +incomplete: true +--- + +Узнайте, как разрабатывать для Ethereum с помощью проектов и инструментов на основе Rust + +Используйте Ethereum для создания децентрализованных приложений (или «dapp»), использующих преимущества криптовалют и технологии блокчейн. Эти децентрализованные приложения надежны, а это значит, что после развертывания в Ethereum они всегда будут работать в соответствии с программой. Они могут работать с цифровыми активами для создания новых видов финансовых приложений. Они могут быть децентрализованными, что означает, что ни одно юридическое лицо или лицо не контролирует их, и их практически невозможно подвергнуть цензуре. + +## Начало работы с умными контрактами и языком Solidity {#getting-started-with-smart-contracts-and-solidity} + +**Сделайте свои первые шаги интеграции Rust с Ethereum** + +Нужен простой пример для начала? Посетите [ethereum.org/learn](/learn/) или [ethereum.org/developers](/developers/). + +- [Объяснение блокчейна](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [Понимание умных контрактов](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) +- [Напишите свой первый умный контракт](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Узнайте, как компилировать и развертывать код на Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) + +## Статьи для начинающих {#beginner-articles} + +- [Клиент Rust Ethereum](https://openethereum.github.io/) \* **Обратите внимание, что OpenEthereum [был признан устаревшим](https://medium.com/openethereum/gnosis-joins-erigon-formerly-turbo-geth-to-release-next-gen-ethereum-client-c6708dd06dd) и больше не поддерживается.** Используйте его с осторожностью и по возможности переключитесь на другую реализацию клиента. +- [Отправка транзакции в Ethereum с помощью Rust](https://kauri.io/#collections/A%20Hackathon%20Survival%20Guide/sending-ethereum-transactions-with-rust/) +- [Пошаговое руководство по написанию контрактов на Rust Wasm для Kovan](https://github.com/paritytech/pwasm-tutorial) + +## Статьи для среднего уровня {#intermediate-articles} + +## Продвинутые модели использования {#advanced-use-patterns} + +- [Библиотека pwasm_ethereum externs для взаимодействия с сетями, подобными Ethereum](https://github.com/openethereum/pwasm-ethereum) + +- [Создание децентрализованного чата с использованием JavaScript и Rust](https://medium.com/perlin-network/build-a-decentralized-chat-using-javascript-rust-webassembly-c775f8484b52) + +- [Создание децентрализованного приложения-планировщика на Vue.js и Rust](https://medium.com/@jjmace01/build-a-decentralized-todo-app-using-vue-js-rust-webassembly-5381a1895beb) + +- [Создание блокчейна на Rust](https://blog.logrocket.com/how-to-build-a-blockchain-in-rust/) + +## Проекты и инструменты на Rust {#rust-projects-and-tools} + +- [pwasm-ethereum](https://github.com/paritytech/pwasm-ethereum) - _Коллекция externs для взаимодействия с сетями, подобными Ethereum_ +- [Lighthouse](https://github.com/sigp/lighthouse) - _Быстрый клиент уровня консенсуса Ethereum_ +- [Ethereum WebAssembly](https://ewasm.readthedocs.io/en/mkdocs/) - _Предлагаемая реструктуризация уровня исполнения смарт-контрактов Ethereum с использованием детерминированного подмножества WebAssembly_ +- [oasis_std](https://docs.rs/oasis-std/latest/oasis_std/index.html) - _Справочник по API OASIS_ +- [Solaris](https://github.com/paritytech/sol-rs) - _Инструмент для модульного тестирования смарт-контрактов Solidity, использующий нативный EVM клиента Parity._ +- [SputnikVM](https://github.com/rust-blockchain/evm) - _Реализация виртуальной машины Ethereum на Rust_ +- [Wavelet](https://wavelet.perlin.net/docs/smart-contracts) - _Смарт-контракт Wavelet на Rust_ +- [Foundry](https://github.com/foundry-rs/foundry) - _Набор инструментов для разработки приложений Ethereum_ +- [Alloy](https://alloy.rs) - _Высокопроизводительные, хорошо протестированные и документированные библиотеки для взаимодействия с Ethereum и другими блокчейнами на основе EVM._ +- [Ethers_rs](https://github.com/gakonst/ethers-rs) - _Библиотека Ethereum и реализация кошелька_ +- [SewUp](https://github.com/second-state/SewUp) - _Библиотека, которая поможет вам создавать смарт-контракты Ethereum WebAssembly на Rust так же просто, как при разработке обычного бэкенда_ +- [Substreams](https://github.com/streamingfast/substreams) - _Технология параллельного индексирования данных блокчейна_ +- [Reth](https://github.com/paradigmxyz/reth) Reth (сокращение от Rust Ethereum) — это новая реализация полного узла Ethereum +- [Awesome Ethereum Rust](https://github.com/Vid201/awesome-ethereum-rust) - _Тщательно подобранная коллекция проектов в экосистеме Ethereum, написанных на Rust_ + +Ищешь больше статей? Посетите [ethereum.org/developers.](/developers/) + +## Участники сообщества Rust {#rust-community-contributors} + +- [Ethereum WebAssembly](https://gitter.im/ewasm/Lobby) +- [Oasis Gitter](https://gitter.im/Oasis-official/Lobby) +- [Parity Gitter](https://gitter.im/paritytech/parity) +- [Enigma](https://discord.gg/SJK32GY) diff --git a/public/content/translations/ru/developers/docs/scaling/index.md b/public/content/translations/ru/developers/docs/scaling/index.md new file mode 100644 index 00000000000..7eddd4b3589 --- /dev/null +++ b/public/content/translations/ru/developers/docs/scaling/index.md @@ -0,0 +1,113 @@ +--- +title: "Масштабирование" +description: "Введение в различные варианты масштабирования, которые в настоящее время разрабатывает сообщество Ethereum." +lang: ru +sidebarDepth: 3 +--- + +## Обзор масштабирования {#scaling-overview} + +По мере роста числа людей, использующих Ethereum, блокчейн достиг определенных ограничений по мощности. Это привело к увеличению стоимости использования сети, создавая потребность в «решениях для масштабирования» В настоящее время исследуются, тестируются и внедряются несколько решений, в которых используются разные подходы для достижения схожих целей. + +Основная цель масштабируемости — повысить скорость транзакций (ускорить финализацию) и пропускную способность (увеличить количество транзакций в секунду) без ущерба для децентрализации и безопасности. В блокчейне Ethereum уровня 1 высокий спрос приводит к замедлению транзакций и непомерным [ценам на газ](/developers/docs/gas/). Увеличение пропускной способности сети с точки зрения скорости и пропускной способности имеет фундаментальное значение для значимого и массового внедрения Ethereum. + +Хотя скорость и пропускная способность важны, важно, чтобы решения для масштабирования, позволяющие достичь этих целей, оставались децентрализованными и безопасными. Сохранение низкого барьера для входа для операторов узлов имеет решающее значение для предотвращения перехода к централизованным и небезопасным вычислительным мощностям. + +Концептуально мы сначала классифицируем масштабирование на ончейн-масштабирование и оффчейн-масштабирование. + +## Предварительные условия {#prerequisites} + +Вы должны хорошо понимать все основные темы. Реализация решений масштабирования продвигается вперед, поскольку технология менее проверена в боевых условиях, а ее исследования и разработки продолжаются. + +## Ончейн-масштабирование {#onchain-scaling} + +Ончейн-масштабирование требует внесения изменений в протокол Ethereum (уровень 1 [основной сети](/glossary/#mainnet)). Долгое время масштабирование Ethereum предполагалось реализовать с помощью шардинга. В результате этого блокчейн был бы разделён на частички (шарды), которые бы верифицировались набором валидаторов. Однако, масштабирование с помощью роллапов (обёрток) 2-го уровня было выбрано приоритетным методом. Этот вариант также усилился реализацией более дешевого метода прикрепления даты в блоки Ethereum, специально разработанного чтобы сделать роллапы (обёртки) дешевыми для пользователей. + +### Шардинг {#sharding} + +Шардинг — это процесс расщепления базы данных. Подряды валидаторов ответственны за индивидуальные шарды, и не нуждаются в отслеживании всего состояния сети Ethereum. Шардинг долгое время был частью [дорожной карты](/roadmap/) Ethereum, и его планировалось запустить до перехода на proof-of-stake в рамках «Слияния» (The Merge). Однако быстрое развитие [ролл-апов уровня 2](#layer-2-scaling) и изобретение [Danksharding](/roadmap/danksharding) (добавление больших двоичных объектов с данными ролл-апов в блоки Ethereum, которые могут очень эффективно проверяться валидаторами) привело к тому, что сообщество Ethereum предпочло масштабирование, ориентированное на ролл-апы, вместо масштабирования с помощью шардинга. Это также позволило оставить простую логику консенсуса Ethereum. + +## Оффчейн-масштабирование {#offchain-scaling} + +Оффчейн-решения реализуются отдельно от основной сети (Mainnet) уровня 1 — они не требуют изменений в существующем протоколе Ethereum. Некоторые решения, известные как решения «уровня 2», получают свою безопасность непосредственно от консенсуса Ethereum уровня 1. К ним относятся [оптимистические ролл-апы](/developers/docs/scaling/optimistic-rollups/), [ролл-апы с нулевым разглашением](/developers/docs/scaling/zk-rollups/) или [каналы состояния](/developers/docs/scaling/state-channels/). Другие решения подразумевают создание новых цепей в различных формах, безопасность которых обеспечивается отдельно от основной сети (Mainnet), например [сайдчейны](#sidechains), [валидиумы](#validium) или [плазменные цепи](#plasma). Эти решения взаимодействуют с основной сетью (Mainnet), но для достижения различных целей по-разному обеспечивают свою безопасность. + +### Масштабирование уровня 2 {#layer-2-scaling} + +Эта категория оффчейн-решений получает свою безопасность от основной сети Ethereum (Mainnet). + +Уровень 2 - это собирательный термин для решений, разработанных для помощи в масштабировании Вашего приложения, используя обработку транзакций вне основной сети Ethereum (уровень 1), пользуясь преимуществом высокой децентрализации модели надежности Основной сети. Скорость транзакций снижается, когда сеть занята, что ухудшает пользовательский опыт для некоторых типов dapps. По мере того, как сеть становится более загруженной, цены на газ растут, поскольку отправители транзакций стремятся перебить цену друг друга. Это может сделать использование Ethereum очень дорогим. + +Большинство решений уровня 2 сосредоточено вокруг сервера или кластера серверов, каждый из которых может называться узлом, валидатором, оператором, секвенсором, производителем блоков или аналогичным термином. В зависимости от реализации, эти узлы уровня 2 могут запускаться отдельными лицами, предприятиями или организациями, которые их используют, или сторонним оператором, или большой группой лиц (аналогично Mainnet). Вообще говоря, транзакции отправляются на эти узлы уровня 2, а не напрямую на уровень 1 (Mainnet). В некоторых решениях экземпляр уровня 2 объединяет транзакции в группы перед их закреплением на уровне 1, после чего они защищаются уровнем 1 и не могут быть изменены. Детали того, как это делается, значительно различаются между различными технологиями и реализациями уровня 2. + +Конкретный экземпляр уровня 2 может быть открытым и совместно использоваться многими приложениями или может быть развернут одним проектом и предназначен для поддержки только своего приложения. + +#### Зачем нужен слой 2? {#why-is-layer-2-needed} + +- Увеличение количества транзакций в секунду значительно улучшает пользовательский опыт и снижает перегрузку сети в Mainnet Ethereum. +- Транзакции объединяются в одну транзакцию в основной сети Ethereum (Mainnet), что снижает плату за газ для пользователей и делает Ethereum более инклюзивным и доступным для людей во всем мире. +- Любые обновления масштабируемости не должны происходить за счет децентрализации или безопасности - уровень 2 строится поверх Ethereum. +- Существуют специализированные сети уровня 2, которые обеспечивают собственный набор преимуществ при работе с активами в больших масштабах. + +[Подробнее об уровне 2](/layer-2/). + +#### Ролл-апы {#rollups} + +Свертывания выполняют транзакцию за пределами уровня 1, а затем данные отправляются на уровень 1, где достигается консенсус. Поскольку данные транзакции включены в блоки уровня 1, это позволяет защищать свертки с помощью собственной системы безопасности Ethereum. + +Есть два типа накопительных пакетов с разными моделями безопасности: + +- **Оптимистические ролл-апы**: по умолчанию предполагают, что транзакции действительны, и выполняют вычисления через [**доказательство мошенничества**](/glossary/#fraud-proof) только в случае оспаривания. [Подробнее об оптимистических ролл-апах](/developers/docs/scaling/optimistic-rollups/). +- **Ролл-апы с нулевым разглашением**: выполняют вычисления оффчейн и предоставляют в сеть [**доказательство достоверности**](/glossary/#validity-proof). [Подробнее о ролл-апах с нулевым разглашением](/developers/docs/scaling/zk-rollups/). + +#### Каналы состояния {#channels} + +State channels utilize multisig contracts to enable participants to transact quickly and freely offchain, then settle finality with Mainnet. Это сводит к минимуму перегрузку сети, сборы и задержки. В настоящее время двумя типами каналов являются каналы состояния и каналы оплаты. + +Подробнее о [каналах состояния](/developers/docs/scaling/state-channels/). + +### Сайдчейны {#sidechains} + +Сайдчейн — это независимый, совместимый с EVM блокчейн, который работает параллельно с основной сетью (Mainnet). Они совместимы с Ethereum через двусторонние мосты и работают по собственным правилам консенсуса и с собственными параметрами блоков. + +Подробнее о [сайдчейнах](/developers/docs/scaling/sidechains/). + +### Плазма {#plasma} + +Плазменная цепь — это отдельный блокчейн, который привязан к основной цепи Ethereum и использует доказательства мошенничества (как [оптимистические ролл-апы](/developers/docs/scaling/optimistic-rollups/)) для разрешения споров. + +Подробнее о [плазме](/developers/docs/scaling/plasma/). + +### Валидиум {#validium} + +Цепь Валидиум использует доказательства валидности, такие как ролл-апы с нулевым разглашением, но данные не хранятся на основном уровне 1 сети Ethereum. Это может привести к 10 тысячам транзакций в секунду на цепочку Валидиум и несколько цепочек может быть запущено параллельно. + +Подробнее о [валидиуме](/developers/docs/scaling/validium/). + +## Зачем нужно столько масштабных решений? {#why-do-we-need-these} + +- Различные решения могут помочь снизить общую перегрузку на любом участке сети, а также предотвратить появление единых точек отказа. +- Целое больше, чем сумма его частей. Различные решения могут существовать и работать в гармонии, что дает экспоненциальный эффект на скорость и пропускную способность транзакций в будущем. +- Не все решения требуют прямого использования алгоритма консенсуса Ethereum, а альтернативы могут предложить преимущества, которые иначе было бы трудно получить. + +## Больше увлекаетесь визуализацией? {#visual-learner} + + + +_Обратите внимание: в видео термин «Layer 2» используется для обозначения всех решений масштабирования вне основной цепи, тогда как мы различаем «Layer 2» как решение вне основной цепи, которое получает свою безопасность через консенсус основной сети Layer 1 Mainnet._ + + + +## Дополнительные материалы {#further-reading} + +- [Дорожная карта Ethereum, ориентированная на ролл-апы](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698) _Виталик Бутерин_ +- [Актуальная аналитика по решениям масштабирования уровня 2 для Ethereum](https://www.l2beat.com/) +- [Оценка решений масштабирования уровня 2 для Ethereum: система сравнения](https://medium.com/matter-labs/evaluating-ethereum-l2-scaling-solutions-a-comparison-framework-b6b2f410f955) +- [Неполное руководство по ролл-апам](https://vitalik.eth.limo/general/2021/01/05/rollup.html) +- [ZK-ролл-апы на базе Ethereum: покорители мира](https://hackmd.io/@canti/rkUT0BD8K) +- [Оптимистические ролл-апы или ZK-ролл-апы](https://limechain.tech/blog/optimistic-rollups-vs-zk-rollups/) +- [Почему ролл-апы и шардинг данных — единственное устойчивое решение для высокой масштабируемости](https://polynya.medium.com/why-rollups-data-shards-are-the-only-sustainable-solution-for-high-scalability-c9aabd6fbb48) +- [Какие решения уровня 3 имеют смысл?](https://vitalik.eth.limo/general/2022/09/17/layer_3.html) +- [Доступность данных, или: как ролл-апы научились не волноваться и полюбили Ethereum](https://web.archive.org/web/20250515194659/https://web.archive.org/web/20241108192208/https/research.2077.xyz/data-availability-or-how-rollups-learned-to-stop-worrying-and-love-ethereum) +- [Практическое руководство по ролл-апам Ethereum](https://web.archive.org/web/20241108192208/https://research.2077.xyz/the-practical-guide-to-ethereum-rollups) + +_Знаете ресурс сообщества, который вам пригодился? Измените эту страницу и добавьте его!_ diff --git a/public/content/translations/ru/developers/docs/scaling/optimistic-rollups/index.md b/public/content/translations/ru/developers/docs/scaling/optimistic-rollups/index.md new file mode 100644 index 00000000000..756cbb60e4a --- /dev/null +++ b/public/content/translations/ru/developers/docs/scaling/optimistic-rollups/index.md @@ -0,0 +1,265 @@ +--- +title: "Оптимистичный ролл-ап" +description: "Введение в оптимистичные роллапы — решение для масштабирования, используемое сообществом Ethereum." +lang: ru +--- + +Оптимистичные свертки — это протоколы уровня 2 (L2), предназначенные для расширения пропускной способности базового уровня Ethereum. Они сокращают объем вычислений в основной цепочке Ethereum за счет обработки транзакций вне цепочки, что обеспечивает значительное повышение скорости обработки. В отличие от других решений для масштабирования, таких как [сайдчейны](/developers/docs/scaling/sidechains/), оптимистические ролл-апы обеспечивают безопасность за счет основной сети, публикуя результаты транзакций в сети (on-chain), или [цепей Plasma](/developers/docs/scaling/plasma/), которые также проверяют транзакции в Ethereum с помощью доказательств мошенничества, но хранят данные транзакций в другом месте. + +Поскольку вычисления — это медленная и затратная часть использования Ethereum, оптимистичные накопления могут обеспечить улучшение масштабируемости в 10–100 раз. Оптимистические ролл-апы также записывают транзакции в Ethereum как `calldata` или в виде [блобов](/roadmap/danksharding/), что снижает расходы пользователей на газ. + +## Предварительные условия {#prerequisites} + +Вам следует прочитать и понять наши страницы о [масштабировании Ethereum](/developers/docs/scaling/) и [уровне 2](/layer-2/). + +## Что такое оптимистичный свертывающий прогноз? {#what-is-an-optimistic-rollup} + +Оптимистичный подход к масштабированию Ethereum подразумевает перемещение вычислений и хранения состояний за пределы блокчейна. Оптимистические ролл-апы выполняют транзакции вне Ethereum, но публикуют данные транзакций в основной сети в виде `calldata` или в [блобах](/roadmap/danksharding/). + +Оптимистичные операторы объединяют несколько офчейн-транзакций в большие пакеты перед отправкой в ​​Ethereum. Такой подход позволяет распределить фиксированные издержки по нескольким транзакциям в каждом пакете, снижая комиссию для конечных пользователей. Оптимистичные свертки также используют методы сжатия для уменьшения объема данных, размещаемых на Ethereum. + +Оптимистичные свертки считаются «оптимистичными», поскольку они предполагают, что транзакции вне сети являются действительными, и не публикуют доказательства действительности для пакетов транзакций, размещенных в сети. Это отличает оптимистические ролл-апы от [ролл-апов с 0-знанием](/developers/docs/scaling/zk-rollups), которые публикуют криптографические [доказательства действительности](/glossary/#validity-proof) для транзакций вне сети. + +Вместо этого оптимистические ролл-апы используют схему доказательства мошенничества для выявления случаев, когда транзакции рассчитываются неверно. После того как пакет ролл-апа отправлен в Ethereum, есть временное окно (называемое периодом оспаривания), в течение которого любой может оспорить результаты транзакции ролл-апа, вычислив [доказательство мошенничества](/glossary/#fraud-proof). + +Если доказательство мошенничества будет успешным, протокол ролл-апа повторно выполнит транзакцию (транзакции) и соответствующим образом обновит состояние ролл-апа. Другим следствием успешного доказательства мошенничества является то, что Секвенсор, ответственный за включение неверно выполненной транзакции в блок, получает штраф. + +Если пакет ролл-апа остается неоспоренным (т. е. все транзакции выполнены правильно) по истечении периода оспаривания, он считается действительным и принимается в Ethereum. Другие могут продолжать строить на неподтвержденном блоке ролл-апа, но с оговоркой: результаты транзакций будут отменены, если они основаны на неверно выполненной транзакции, опубликованной ранее. + +## Как оптимистические ролл-апы взаимодействуют с Ethereum? {#optimistic-rollups-and-Ethereum} + +Оптимистические ролл-апы — это [решения для масштабирования вне сети](/developers/docs/scaling/#offchain-scaling), созданные для работы поверх Ethereum. Каждый оптимистический ролл-ап управляется набором смарт-контрактов, развернутых в сети Ethereum. Оптимистические ролл-апы обрабатывают транзакции вне основной цепи Ethereum, но публикуют транзакции вне сети (пакетами) в контракте ролл-апа в сети. Как и блокчейн Ethereum, эта запись транзакций является неизменной и образует "цепь оптимистического ролл-апа". + +Архитектура оптимистического ролл-апа включает следующие части: + +**Контракты в сети**: работа оптимистического ролл-апа контролируется смарт-контрактами, работающими в Ethereum. Это включает контракты, которые хранят блоки ролл-апа, отслеживают обновления состояния в ролл-апе и отслеживают депозиты пользователей. В этом смысле Ethereum служит базовым уровнем, или "уровнем 1", для оптимистических ролл-апов. + +**Виртуальная машина вне сети (VM)**: хотя контракты, управляющие протоколом оптимистического ролл-апа, работают в Ethereum, протокол ролл-апа выполняет вычисления и хранение состояний на другой виртуальной машине, отдельной от [виртуальной машины Ethereum](/developers/docs/evm/). VM вне сети — это место, где находятся приложения и выполняются изменения состояния; она служит верхним уровнем, или "уровнем 2", для оптимистического ролл-апа. + +Поскольку оптимистические ролл-апы предназначены для запуска программ, написанных или скомпилированных для EVM, VM вне сети включает в себя многие проектные спецификации EVM. Кроме того, доказательства мошенничества, вычисленные в сети, позволяют сети Ethereum обеспечивать действительность изменений состояния, вычисленных в VM вне сети. + +Оптимистические ролл-апы описываются как 'гибридные решения для масштабирования', потому что, хотя они существуют как отдельные протоколы, их свойства безопасности унаследованы от Ethereum. Помимо прочего, Ethereum гарантирует правильность вычислений ролл-апа вне сети и доступность данных, лежащих в основе этих вычислений. Это делает оптимистические ролл-апы более безопасными, чем чисто протоколы масштабирования вне сети (например, [сайдчейны](/developers/docs/scaling/sidechains/)), которые не полагаются на Ethereum для обеспечения безопасности. + +Оптимистические ролл-апы полагаются на основной протокол Ethereum в следующих аспектах: + +### Доступность данных {#data-availability} + +Как уже упоминалось, оптимистические ролл-апы публикуют данные транзакций в Ethereum в виде `calldata` или [блобов](/roadmap/danksharding/). Поскольку выполнение цепи ролл-апа основано на отправленных транзакциях, любой может использовать эту информацию, закрепленную на базовом уровне Ethereum, для выполнения состояния ролл-апа и проверки правильности переходов состояний. + +[Доступность данных](/developers/docs/data-availability/) имеет решающее значение, поскольку без доступа к данным о состоянии оспаривающие стороны не могут создавать доказательства мошенничества для оспаривания недействительных операций ролл-апа. Благодаря тому, что Ethereum обеспечивает доступность данных, снижается риск того, что операторы ролл-апа смогут безнаказанно совершать злонамеренные действия (например, отправлять недействительные блоки). + +### Устойчивость к цензуре {#censorship-resistance} + +Оптимистические ролл-апы также полагаются на Ethereum для обеспечения устойчивости к цензуре. В оптимистическом ролл-апе централизованная сущность (оператор) отвечает за обработку транзакций и отправку блоков ролл-апа в Ethereum. Это имеет некоторые последствия: + +- Операторы ролл-апа могут подвергать пользователей цензуре, полностью отключаясь от сети или отказываясь создавать блоки, включающие в себя определенные транзакции. + +- Операторы ролл-апа могут помешать пользователям выводить средства, внесенные в контракт ролл-апа, удерживая данные о состоянии, необходимые для доказательств владения Меркла. Удержание данных о состоянии также может скрыть состояние ролл-апа от пользователей и помешать им взаимодействовать с ролл-апом. + +Оптимистические ролл-апы решают эту проблему, заставляя операторов публиковать данные, связанные с обновлениями состояния, в Ethereum. Публикация данных ролл-апа в сети имеет следующие преимущества: + +- Если оператор оптимистического ролл-апа отключается от сети или прекращает создавать пакеты транзакций, другой узел может использовать доступные данные для воспроизведения последнего состояния ролл-апа и продолжения производства блоков. + +- Пользователи могут использовать данные транзакций для создания доказательств Меркла, подтверждающих владение средствами, и выводить свои активы из ролл-апа. + +- Пользователи также могут отправлять свои транзакции на L1 вместо Секвенсора, и в этом случае Секвенсор должен включить транзакцию в течение определенного времени, чтобы продолжать создавать действительные блоки. + +### Расчет {#settlement} + +Еще одна роль, которую Ethereum играет в контексте оптимистических ролл-апов, — это роль расчетного уровня. Расчетный уровень закрепляет всю экосистему блокчейна, обеспечивает безопасность и объективную окончательность в случае возникновения спора на другой цепи (в данном случае, на оптимистических ролл-апах), требующего арбитража. + +Основная сеть Ethereum предоставляет центр для оптимистических ролл-апов для проверки доказательств мошенничества и разрешения споров. Более того, транзакции, проведенные в ролл-апе, становятся окончательными только _после_ того, как блок ролл-апа будет принят в Ethereum. Как только транзакция ролл-апа зафиксирована на базовом уровне Ethereum, ее нельзя отменить (за исключением крайне маловероятного случая реорганизации цепи). + +## Как работают оптимистические ролл-апы? {#how-optimistic-rollups-work} + +### Выполнение и агрегация транзакций {#transaction-execution-and-aggregation} + +Пользователи отправляют транзакции "операторам" — узлам, ответственным за обработку транзакций в оптимистическом ролл-апе. Также известный как "валидатор" или "агрегатор", оператор агрегирует транзакции, сжимает базовые данные и публикует блок в Ethereum. + +Хотя любой может стать валидатором, валидаторы оптимистического ролл-апа должны предоставить залог перед созданием блоков, подобно [системе proof-of-stake](/developers/docs/consensus-mechanisms/pos/). Этот залог может быть уменьшен (slashed), если валидатор публикует недействительный блок или строит на старом, но недействительном блоке (даже если его собственный блок действителен). Таким образом, оптимистические ролл-апы используют криптоэкономические стимулы для обеспечения честной работы валидаторов. + +Ожидается, что другие валидаторы в цепи оптимистического ролл-апа будут выполнять отправленные транзакции, используя свою копию состояния ролл-апа. Если конечное состояние валидатора отличается от предложенного состояния оператора, они могут начать оспаривание и вычислить доказательство мошенничества. + +Некоторые оптимистические ролл-апы могут отказаться от безразрешительной системы валидаторов и использовать одного "Секвенсора" для выполнения цепи. Подобно валидатору, Секвенсор обрабатывает транзакции, создает блоки ролл-апа и отправляет транзакции ролл-апа в цепь L1 (Ethereum). + +Секвенсор отличается от обычного оператора ролл-апа, поскольку он имеет больший контроль над порядком транзакций. Кроме того, Секвенсор имеет приоритетный доступ к цепи ролл-апа и является единственным субъектом, уполномоченным отправлять транзакции в контракт в сети. Транзакции от узлов, не являющихся Секвенсорами, или от обычных пользователей просто ставятся в очередь в отдельный почтовый ящик, пока Секвенсор не включит их в новый пакет. + +#### Отправка блоков ролл-апа в Ethereum {#submitting-blocks-to-ethereum} + +Как уже упоминалось, оператор оптимистического ролл-апа объединяет транзакции вне сети в пакет и отправляет его в Ethereum для нотариального заверения. Этот процесс включает сжатие данных, связанных с транзакциями, и их публикацию в Ethereum в виде `calldata` или в виде блобов. + +`calldata` — это немодифицируемая, непостоянная область в смарт-контракте, которая в основном ведет себя как [память](/developers/docs/smart-contracts/anatomy/#memory). Хотя `calldata` сохраняется в сети как часть [журналов истории](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html?highlight=memory#logs) блокчейна, она не хранится как часть состояния Ethereum. Поскольку `calldata` не затрагивает ни одну часть состояния Ethereum, она дешевле, чем состояние, для хранения данных в сети. + +Ключевое слово `calldata` также используется в Solidity для передачи аргументов в функцию смарт-контракта во время выполнения. `calldata` идентифицирует вызываемую функцию во время транзакции и содержит входные данные для функции в виде произвольной последовательности байтов. + +В контексте оптимистических ролл-апов `calldata` используется для отправки сжатых данных транзакций в контракт в сети. Оператор ролл-апа добавляет новый пакет, вызывая требуемую функцию в контракте ролл-апа и передавая сжатые данные в качестве аргументов функции. Использование `calldata` снижает комиссию для пользователей, поскольку большинство затрат, которые несут ролл-апы, связаны с хранением данных в сети. + +Вот [пример](https://eth.blockscout.com/tx/0x9102bfce17c58b5fc1c974c24b6bb7a924fb5fbd7c4cd2f675911c27422a5591) отправки пакета ролл-апа, чтобы показать, как работает эта концепция. Секвенсор вызвал метод `appendSequencerBatch()` и передал сжатые данные транзакции в качестве входных данных с помощью `calldata`. + +Некоторые ролл-апы теперь используют блобы для отправки пакетов транзакций в Ethereum. + +Блобы немодифицируемы и непостоянны (как и `calldata`), но удаляются из истории примерно через 18 дней. Для получения дополнительной информации о блобах см. [Danksharding](/roadmap/danksharding). + +### Обязательства по состоянию {#state-commitments} + +В любой момент времени состояние оптимистического ролл-апа (аккаунты, балансы, код контракта и т. д.) организовано в виде [дерева Меркла](/whitepaper/#merkle-trees), называемого «деревом состояний». Корень этого дерева Меркла (корень состояния), который ссылается на последнее состояние ролл-апа, хэшируется и хранится в контракте ролл-апа. Каждый переход состояния в цепи создает новое состояние ролл-апа, которое оператор фиксирует, вычисляя новый корень состояния. + +Оператор должен отправлять как старые, так и новые корни состояний при публикации пакетов. Если старый корень состояния совпадает с существующим корнем состояния в контракте в сети, последний отбрасывается и заменяется новым корнем состояния. + +Оператор ролл-апа также должен зафиксировать корень Меркла для самого пакета транзакций. Это позволяет любому доказать включение транзакции в пакет (на L1), представив [доказательство Меркла](/developers/tutorials/merkle-proofs-for-offline-data-integrity/). + +Фиксации состояний, особенно корни состояний, необходимы для доказательства правильности изменений состояний в оптимистическом ролл-апе. Контракт ролл-апа принимает новые корни состояний от операторов сразу после их публикации, но может позже удалить недействительные корни состояний, чтобы восстановить ролл-ап до его правильного состояния. + +### Доказательство мошенничества {#fraud-proving} + +Как уже объяснялось, оптимистические ролл-апы позволяют любому публиковать блоки без предоставления доказательств действительности. Однако для обеспечения безопасности цепи оптимистические ролл-апы определяют временное окно, в течение которого любой может оспорить переход состояния. Поэтому блоки ролл-апа называются «утверждениями», так как любой может оспорить их действительность. + +Если кто-то оспаривает утверждение, протокол ролл-апа инициирует вычисление доказательства мошенничества. Каждый тип доказательства мошенничества является интерактивным — кто-то должен опубликовать утверждение, прежде чем другой сможет его оспорить. Разница заключается в том, сколько раундов взаимодействия требуется для вычисления доказательства мошенничества. + +Однораундовые интерактивные схемы доказательства воспроизводят оспариваемые транзакции на L1 для выявления недействительных утверждений. Протокол ролл-апа эмулирует повторное выполнение оспариваемой транзакции на L1 (Ethereum) с использованием контракта-верификатора, при этом вычисленный корень состояния определяет, кто выигрывает оспаривание. Если утверждение оспаривающей стороны о правильном состоянии ролл-апа верно, оператор наказывается уменьшением (slashing) своего залога. + +Однако повторное выполнение транзакций на L1 для выявления мошенничества требует публикации фиксаций состояний для отдельных транзакций и увеличивает объем данных, которые ролл-апы должны публиковать в сети. Повторное воспроизведение транзакций также влечет за собой значительные затраты на газ. По этим причинам оптимистические ролл-апы переходят на многораундовое интерактивное доказательство, которое достигает той же цели (т. е. выявление недействительных операций ролл-апа) с большей эффективностью. + +#### Многораундовое интерактивное доказательство {#multi-round-interactive-proving} + +Многораундовое интерактивное доказательство включает в себя протокол взаимодействия между утверждающей и оспаривающей сторонами под контролем контракта-верификатора L1, который в конечном итоге определяет лгущую сторону. После того как узел L2 оспаривает утверждение, утверждающая сторона должна разделить оспариваемое утверждение на две равные половины. Каждое отдельное утверждение в этом случае будет содержать столько же шагов вычислений, сколько и другое. + +Затем оспаривающая сторона выберет, какое утверждение она хочет оспорить. Процесс деления (называемый «протоколом деления пополам») продолжается до тех пор, пока обе стороны не будут оспаривать утверждение об _одном_ шаге выполнения. На этом этапе контракт L1 разрешит спор, оценив инструкцию (и ее результат), чтобы поймать мошенническую сторону. + +Утверждающая сторона должна предоставить «одношаговое доказательство», подтверждающее действительность оспариваемого одношагового вычисления. Если утверждающая сторона не предоставляет одношаговое доказательство, или верификатор L1 считает доказательство недействительным, она проигрывает оспаривание. + +Некоторые замечания об этом типе доказательства мошенничества: + +1. Многораундовое интерактивное доказательство мошенничества считается эффективным, поскольку оно минимизирует работу, которую должна выполнять цепь L1 при арбитраже споров. Вместо повторного воспроизведения всей транзакции, цепи L1 нужно только повторно выполнить один шаг в выполнении ролл-апа. + +2. Протоколы деления пополам уменьшают объем данных, публикуемых в сети (нет необходимости публиковать фиксации состояний для каждой транзакции). Кроме того, транзакции оптимистического ролл-апа не ограничены лимитом газа Ethereum. И наоборот, оптимистические ролл-апы, повторно выполняющие транзакции, должны убедиться, что транзакция L2 имеет более низкий лимит газа для эмуляции ее выполнения в рамках одной транзакции Ethereum. + +3. Часть залога злонамеренного утверждающего присуждается оспаривающей стороне, а другая часть сжигается. Сжигание предотвращает сговор между валидаторами; если два валидатора вступят в сговор для инициирования фиктивных оспариваний, они все равно лишатся значительной части всей своей ставки. + +4. Многораундовое интерактивное доказательство требует, чтобы обе стороны (утверждающая и оспаривающая) делали ходы в течение указанного временного окна. Невыполнение действий до истечения срока приводит к тому, что не выполнившая обязательства сторона проигрывает оспаривание. + +#### Почему доказательства мошенничества важны для оптимистических ролл-апов {#fraud-proof-benefits} + +Доказательства мошенничества важны, поскольку они способствуют _бездоверительной окончательности_ в оптимистических ролл-апах. Бездоверительная окончательность — это качество оптимистических ролл-апов, которое гарантирует, что транзакция, если она действительна, в конечном итоге будет подтверждена. + +Злонамеренные узлы могут пытаться отсрочить подтверждение действительного блока ролл-апа, начиная ложные оспаривания. Однако доказательства мошенничества в конечном итоге докажут действительность блока ролл-апа и приведут к его подтверждению. + +Это также связано с другим свойством безопасности оптимистических ролл-апов: действительность цепи зависит от существования _одного_ честного узла. Честный узел может правильно продвигать цепь, либо публикуя действительные утверждения, либо оспаривая недействительные. В любом случае, злонамеренные узлы, вступающие в споры с честным узлом, потеряют свои ставки в процессе доказательства мошенничества. + +### Совместимость L1/L2 {#l1-l2-interoperability} + +Оптимистические ролл-апы разработаны для взаимодействия с основной сетью Ethereum и позволяют пользователям передавать сообщения и произвольные данные между L1 и L2. Они также совместимы с EVM, поэтому вы можете переносить существующие [децентрализованные приложения](/developers/docs/dapps/) на оптимистические ролл-апы или создавать новые децентрализованные приложения с помощью инструментов разработки Ethereum. + +#### 1. Перемещение активов {#asset-movement} + +##### Вход в ролл-ап + +Чтобы использовать оптимистический ролл-ап, пользователи вносят ETH, токены ERC-20 и другие принимаемые активы в контракт [Моста](/developers/docs/bridges/) ролл-апа на L1. Контракт Моста передаст транзакцию на L2, где будет выпущена эквивалентная сумма активов и отправлена на выбранный пользователем адрес в оптимистическом ролл-апе. + +Транзакции, сгенерированные пользователем (например, депозит с L1 на L2), обычно ставятся в очередь до тех пор, пока Секвенсор не отправит их повторно в контракт ролл-апа. Однако, чтобы сохранить устойчивость к цензуре, оптимистические ролл-апы позволяют пользователям отправлять транзакцию непосредственно в контракт ролл-апа в сети, если она была задержана сверх максимально допустимого времени. + +Некоторые оптимистические ролл-апы используют более простой подход для предотвращения цензуры пользователей Секвенсорами. Здесь блок определяется всеми транзакциями, отправленными в контракт L1 с момента предыдущего блока (например, депозиты), в дополнение к транзакциям, обработанным в цепи ролл-апа. Если Секвенсор игнорирует транзакцию L1, он опубликует (доказуемо) неверный корень состояния; следовательно, Секвенсоры не могут задерживать сообщения, сгенерированные пользователем, после их публикации на L1. + +##### Выход из ролл-апа + +Вывод средств из оптимистического ролл-апа в Ethereum сложнее из-за схемы доказательства мошенничества. Если пользователь инициирует транзакцию с L2 на L1 для вывода средств, зарезервированных на L1, он должен дождаться истечения периода оспаривания, который длится примерно семь дней. Тем не менее, сам процесс вывода средств довольно прост. + +После инициирования запроса на вывод средств в ролл-апе L2, транзакция включается в следующий пакет, а активы пользователя в ролл-апе сжигаются. Как только пакет будет опубликован в Ethereum, пользователь сможет вычислить доказательство Меркла, подтверждающее включение его транзакции на выход в блок. Затем остается только дождаться окончания периода задержки, чтобы завершить транзакцию на L1 и вывести средства в основную сеть. + +Чтобы не ждать неделю перед выводом средств в Ethereum, пользователи оптимистических ролл-апов могут воспользоваться услугами **поставщика ликвидности** (LP). Поставщик ликвидности принимает на себя владение ожидающим выводом средств с L2 и выплачивает пользователю на L1 (в обмен на комиссию). + +Поставщики ликвидности могут проверить действительность запроса пользователя на вывод средств (самостоятельно выполнив цепь) перед выпуском средств. Таким образом, у них есть гарантии, что транзакция в конечном итоге будет подтверждена (т. е. бездоверительная окончательность). + +#### 2. Совместимость с EVM {#evm-compatibility} + +Для разработчиков преимущество оптимистических ролл-апов заключается в их совместимости — или, что еще лучше, эквивалентности — с [виртуальной машиной Ethereum (EVM)](/developers/docs/evm/). EVM-совместимые ролл-апы соответствуют спецификациям [Желтой книги Ethereum](https://ethereum.github.io/yellowpaper/paper.pdf) и поддерживают EVM на уровне байт-кода. + +EVM-совместимость в оптимистических ролл-апах имеет следующие преимущества: + +i. Разработчики могут переносить существующие смарт-контракты из Ethereum в цепи оптимистических ролл-апов без необходимости существенного изменения кодовых баз. Это может сэкономить время командам разработчиков при развертывании смарт-контрактов Ethereum на L2. + +ii. Разработчики и проектные команды, использующие оптимистические ролл-апы, могут воспользоваться инфраструктурой Ethereum. Это включает языки программирования, библиотеки кода, инструменты тестирования, клиентское программное обеспечение, инфраструктуру развертывания и так далее. + +Использование существующих инструментов важно, потому что эти инструменты были тщательно проверены, отлажены и улучшены на протяжении многих лет. Это также избавляет разработчиков Ethereum от необходимости изучать, как создавать приложения с совершенно новым стеком разработки. + +#### 3. Вызовы контрактов между цепями {#cross-chain-contract-calls} + +Пользователи (внешние аккаунты) взаимодействуют с контрактами L2, отправляя транзакцию в контракт ролл-апа или поручая это Секвенсору или валидатору. Оптимистические ролл-апы также позволяют аккаунтам контрактов в Ethereum взаимодействовать с контрактами L2, используя контракты Мостов для ретрансляции сообщений и передачи данных между L1 и L2. Это означает, что вы можете запрограммировать контракт L1 в основной сети Ethereum для вызова функций, принадлежащих контрактам в оптимистическом ролл-апе L2. + +Вызовы контрактов между цепями происходят асинхронно, то есть вызов сначала инициируется, а затем выполняется позже. Это отличается от вызовов между двумя контрактами в Ethereum, где вызов дает результаты немедленно. + +Примером вызова контракта между цепями является описанный ранее депозит токенов. Контракт на L1 блокирует токены пользователя и отправляет сообщение парному контракту на L2 для выпуска эквивалентного количества токенов в ролл-апе. + +Поскольку вызовы сообщений между цепями приводят к выполнению контракта, отправитель обычно должен покрывать [затраты на газ](/developers/docs/gas/) для вычислений. Рекомендуется устанавливать высокий лимит газа, чтобы предотвратить сбой транзакции в целевой цепи. Сценарий моста для токенов — хороший пример; если сторона L1 транзакции (депонирование токенов) работает, а сторона L2 (выпуск новых токенов) не удается из-за низкого газа, депозит становится невозвратным. + +Наконец, следует отметить, что вызовы сообщений с L2 на L1 между контрактами должны учитывать задержки (вызовы с L1 на L2 обычно выполняются через несколько минут). Это связано с тем, что сообщения, отправленные в основную сеть из оптимистического ролл-апа, не могут быть выполнены до истечения окна оспаривания. + +## Как работают комиссии в оптимистических ролл-апах? {#how-do-optimistic-rollup-fees-work} + +Оптимистические ролл-апы используют схему комиссий за газ, подобную Ethereum, чтобы обозначить, сколько пользователи платят за транзакцию. Комиссии, взимаемые в оптимистических ролл-апах, зависят от следующих компонентов: + +1. **Запись состояния**: оптимистические ролл-апы публикуют данные транзакций и заголовки блоков (состоящие из хэша заголовка предыдущего блока, корня состояния, корня пакета) в Ethereum в виде `блоба`, или "двоичного большого объекта". [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) представил экономически эффективное решение для включения данных в сеть. `blob` — это новое поле транзакции, которое позволяет ролл-апам публиковать сжатые данные о переходе состояния в Ethereum L1. В отличие от `calldata`, которая остается в сети постоянно, блобы недолговечны и могут быть удалены из клиентов после [4096 эпох](https://github.com/ethereum/consensus-specs/blob/81f3ea8322aff6b9fb15132d050f8f98b16bdba4/configs/mainnet.yaml#L147) (примерно 18 дней). Используя блобы для публикации пакетов сжатых транзакций, оптимистические ролл-апы могут значительно снизить стоимость записи транзакций в L1. + +2. **Использованный газ для блобов**: транзакции, переносящие блобы, используют динамический механизм комиссий, аналогичный тому, что был введен [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559). Комиссия за газ для транзакций типа 3 учитывает базовую комиссию для блобов, которая определяется сетью на основе спроса на пространство для блобов и использования пространства для блобов отправляемой транзакцией. + +3. **Комиссии оператора L2**: это сумма, выплачиваемая узлам ролл-апа в качестве компенсации за вычислительные затраты, понесенные при обработке транзакций, подобно комиссиям за газ в Ethereum. Узлы ролл-апа взимают более низкие комиссии за транзакции, поскольку L2 имеют более высокие мощности обработки и не сталкиваются с перегрузками сети, которые заставляют валидаторов в Ethereum отдавать приоритет транзакциям с более высокими комиссиями. + +Оптимистические ролл-апы применяют несколько механизмов для снижения комиссий для пользователей, включая пакетирование транзакций и сжатие `calldata` для снижения затрат на публикацию данных. Вы можете проверить [трекер комиссий L2](https://l2fees.info/) для получения обзора в реальном времени о том, сколько стоит использование оптимистических ролл-апов на базе Ethereum. + +## Как оптимистические ролл-апы масштабируют Ethereum? {#scaling-ethereum-with-optimistic-rollups} + +Как уже объяснялось, оптимистические ролл-апы публикуют сжатые данные транзакций в Ethereum, чтобы гарантировать доступность данных. Возможность сжимать данные, публикуемые в сети, имеет решающее значение для масштабирования пропускной способности Ethereum с помощью оптимистических ролл-апов. + +Основная цепь Ethereum устанавливает ограничения на объем данных, которые могут содержать блоки, выраженные в единицах газа ([средний размер блока](/developers/docs/blocks/#block-size) составляет 15 миллионов газа). Хотя это ограничивает, сколько газа может использовать каждая транзакция, это также означает, что мы можем увеличить количество обрабатываемых транзакций в блоке за счет уменьшения данных, связанных с транзакциями, что напрямую улучшает масштабируемость. + +Оптимистические ролл-апы используют несколько техник для достижения сжатия данных транзакций и повышения скорости TPS. Например, в этой [статье](https://vitalik.eth.limo/general/2021/01/05/rollup.html) сравниваются данные, которые генерирует базовая пользовательская транзакция (отправка эфира) в основной сети, с объемом данных, который та же транзакция генерирует в ролл-апе: + +| Параметр | Ethereum (L1) | Ролл-ап (L2) | +| ----------- | ---------------------------------------------------- | ------------------------------------ | +| Нонс | ~3 | 0 | +| Цена газа | ~8 | 0-0.5 | +| Газ | 3 | 0-0.5 | +| Получатель | 21 | 4 | +| Значение | 9 | ~3 | +| Подпись | ~68 (2 + 33 + 33) | ~0.5 | +| Отправитель | 0 (восстановлено из подписи) | 4 | +| **Всего** | **~112 байт** | **~12 байтов** | + +Проведение некоторых грубых расчетов на основе этих цифр может помочь показать улучшения масштабируемости, предоставляемые оптимистическим ролл-апом: + +1. Целевой размер каждого блока составляет 15 миллионов газа, и проверка одного байта данных стоит 16 газа. Разделив средний размер блока на 16 газа (15 000 000 / 16), мы видим, что средний блок может вместить **937 500 байт данных**. +2. Если базовая транзакция ролл-апа использует 12 байт, то средний блок Ethereum может обработать **78 125 транзакций ролл-апа** (937 500 / 12) или **39 пакетов ролл-апа** (если каждый пакет содержит в среднем 2000 транзакций). +3. Если новый блок создается в Ethereum каждые 15 секунд, то скорость обработки ролл-апа составит примерно **5208 транзакций в секунду**. Это делается путем деления количества базовых транзакций ролл-апа, которое может вместить блок Ethereum (**78 125**), на среднее время блока (**15 секунд**). + +Это довольно оптимистичная оценка, учитывая, что транзакции оптимистического ролл-апа не могут полностью занимать весь блок в Ethereum. Однако это может дать приблизительное представление о том, насколько оптимистические ролл-апы могут повысить масштабируемость для пользователей Ethereum (текущие реализации предлагают до 2000 TPS). + +Ожидается, что введение [шардинга данных](/roadmap/danksharding/) в Ethereum улучшит масштабируемость в оптимистических ролл-апах. Поскольку транзакции ролл-апа должны делить пространство блока с другими транзакциями, не относящимися к ролл-апу, их пропускная способность ограничена пропускной способностью данных в основной цепи Ethereum. Danksharding увеличит пространство, доступное для цепей L2 для публикации данных в блоке, используя более дешевое, временное хранилище "блобов" вместо дорогого, постоянного `CALLDATA`. + +### Плюсы и минусы оптимистических ролл-апов {#optimistic-rollups-pros-and-cons} + +| Преимущества | Недостатки | +| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Предлагает значительные улучшения в масштабируемости без ущерба для безопасности или бездоверительности. | Задержки в окончательности транзакций из-за потенциальных оспариваний мошенничества. | +| Данные транзакций хранятся на цепи уровня 1, что улучшает прозрачность, безопасность, устойчивость к цензуре и децентрализацию. | Централизованные операторы ролл-апов (Секвенсоры) могут влиять на порядок транзакций. | +| Доказательство мошенничества гарантирует бездоверительную окончательность и позволяет честным меньшинствам обеспечивать безопасность цепи. | Если нет честных узлов, злонамеренный оператор может украсть средства, публикуя недействительные блоки и фиксации состояний. | +| Вычисление доказательств мошенничества открыто для обычных узлов L2, в отличие от доказательств действительности (используемых в ZK-ролл-апах), которые требуют специального оборудования. | Модель безопасности основана на том, что по крайней мере один честный узел выполняет транзакции ролл-апа и отправляет доказательства мошенничества для оспаривания недействительных переходов состояний. | +| Ролл-апы выигрывают от «бездоверительной живучести» (любой может заставить цепь продвигаться, выполняя транзакции и публикуя утверждения). | Пользователи должны ждать истечения недельного периода оспаривания, прежде чем выводить средства обратно в Ethereum. | +| Оптимистические ролл-апы полагаются на хорошо продуманные криптоэкономические стимулы для повышения безопасности цепи. | Ролл-апы должны публиковать все данные транзакций в сети, что может увеличить затраты. | +| Совместимость с EVM и Solidity позволяет разработчикам переносить нативные смарт-контракты Ethereum в ролл-апы или использовать существующие инструменты для создания новых децентрализованных приложений. | | + +### Визуальное объяснение оптимистических ролл-апов {#optimistic-video} + +Больше увлекаетесь визуализацией? Посмотрите, как Finematics объясняет оптимистические ролл-апы: + + + +## Дополнительные материалы об оптимистических ролл-апах + +- [Как работают оптимистические ролл-апы (полное руководство)](https://www.alchemy.com/overviews/optimistic-rollups) +- [Что такое ролл-ап в блокчейне? Техническое введение](https://www.ethereum-ecosystem.com/blog/what-is-a-blockchain-rollup-a-technical-introduction) +- [Основное руководство по Arbitrum](https://www.bankless.com/the-essential-guide-to-arbitrum) +- [Практическое руководство по ролл-апам Ethereum](https://web.archive.org/web/20241108192208/https://research.2077.xyz/the-practical-guide-to-ethereum-rollups) +- [Состояние доказательств мошенничества в Ethereum L2](https://web.archive.org/web/20241124154627/https://research.2077.xyz/the-state-of-fraud-proofs-in-ethereum-l2s) +- [Как на самом деле работает ролл-ап Optimism?](https://www.paradigm.xyz/2021/01/how-does-optimism-s-rollup-really-work) +- [Глубокое погружение в OVM](https://medium.com/ethereum-optimism/ovm-deep-dive-a300d1085f52) +- [Что такое Optimistic Virtual Machine?](https://www.alchemy.com/overviews/optimistic-virtual-machine) diff --git a/public/content/translations/ru/developers/docs/scaling/plasma/index.md b/public/content/translations/ru/developers/docs/scaling/plasma/index.md new file mode 100644 index 00000000000..3d1773b187f --- /dev/null +++ b/public/content/translations/ru/developers/docs/scaling/plasma/index.md @@ -0,0 +1,176 @@ +--- +title: "Плазменные цепи" +description: "Введение в плазменные цепи как решение для масштабирования, которое в настоящее время используется сообществом Ethereum." +lang: ru +incomplete: true +sidebarDepth: 3 +--- + +Плазма-цепь — это отдельный блокчейн, привязанный к основной сети Ethereum, но выполняющий транзакции вне сети (офф-чейн) с помощью собственного механизма проверки блока. Плазма-цепи иногда называют «дочерними» цепями, по сути, они являются уменьшенными копиями основной сети Ethereum. Плазма-цепи используют [доказательства мошенничества](/glossary/#fraud-proof) (как и [оптимистические ролл-апы](/developers/docs/scaling/optimistic-rollups/)) для разрешения споров. + +Деревья Меркла позволяют создавать бесконечный стек этих цепей, которые могут работать для разгрузки пропускной способности родительских цепей (включая основную сеть Ethereum). Однако, хотя эти цепи и получают определенную безопасность от Ethereum (через доказательства мошенничества), на их безопасность и эффективность влияет ряд конструктивных ограничений. + +## Предварительные условия {#prerequisites} + +Вы должны хорошо разбираться во всех основополагающих темах и иметь общее представление о [масштабировании Ethereum](/developers/docs/scaling/). + +## Что такое Plasma? + +Плазма — это фреймворк для улучшения масштабируемости в публичных блокчейнах, таких как Ethereum. Как описано в оригинальном [вайтпейпере Plasma](http://plasma.io/plasma.pdf), плазма-цепи строятся поверх другого блокчейна (называемого «корневой цепью»). Каждая «дочерняя цепь» является расширением корневой цепи и обычно управляется смарт-контрактом, развернутым в родительской цепи. + +Контракт Plasma, помимо прочего, функционирует как [мост](/developers/docs/bridges/), позволяя пользователям перемещать активы между основной сетью Ethereum и плазма-цепью. Хотя это делает их похожими на [сайдчейны](/developers/docs/scaling/sidechains/), плазма-цепи выигрывают — по крайней мере, в некоторой степени — от безопасности основной сети Ethereum. Это отличает их от сайдчейнов, которые несут полную ответственность за свою безопасность. + +## Как работает Plasma? + +Основные компоненты фреймворка Plasma: + +### Офф-чейн вычисления {#offchain-computation} + +Текущая скорость обработки транзакций Ethereum ограничена ~15–20 транзакциями в секунду, что снижает краткосрочную возможность масштабирования для обслуживания большего числа пользователей. Эта проблема существует в основном потому, что [механизм консенсуса](/developers/docs/consensus-mechanisms/) Ethereum требует, чтобы множество одноранговых узлов проверяли каждое обновление состояния блокчейна. + +Хотя механизм консенсуса Ethereum необходим для обеспечения безопасности, он может подходить не для каждого варианта использования. Например, Алисе может не потребоваться, чтобы ее ежедневные платежи Бобу за чашку кофе проверялись всей сетью Ethereum, поскольку между обеими сторонами существует определенное доверие. + +Plasma предполагает, что основной сети Ethereum не нужно проверять все транзакции. Вместо этого мы можем обрабатывать транзакции вне основной сети, освобождая узлы от необходимости проверять каждую транзакцию. + +Офф-чейн вычисления необходимы, поскольку плазма-цепи можно оптимизировать по скорости и стоимости. Например, плазма-цепь может — и чаще всего так и делает — использовать одного «оператора» для управления упорядочиванием и выполнением транзакций. Поскольку транзакции проверяет только одна организация, время обработки в плазма-цепи быстрее, чем в основной сети Ethereum. + +### Обязательства по состоянию {#state-commitments} + +Хотя Plasma выполняет транзакции офф-чейн, расчеты по ним производятся на основном уровне исполнения Ethereum — в противном случае плазма-цепи не смогут воспользоваться гарантиями безопасности Ethereum. Но завершение офф-чейн транзакций без знания состояния плазма-цепи нарушило бы модель безопасности и привело бы к распространению недействительных транзакций. Вот почему оператор, организация, ответственная за создание блоков в плазма-цепи, обязан периодически публиковать «обязательства по состоянию» в Ethereum. + +[Схема обязательств](https://en.wikipedia.org/wiki/Commitment_scheme) — это криптографический метод, позволяющий взять на себя обязательство в отношении значения или утверждения, не раскрывая его другой стороне. Обязательства являются «обязывающими» в том смысле, что вы не можете изменить значение или утверждение после того, как вы его приняли. Обязательства по состоянию в Plasma принимают форму «корней Меркла» (полученных из [дерева Меркла](/whitepaper/#merkle-trees)), которые оператор периодически отправляет в контракт Plasma в цепи Ethereum. + +Корни Меркла — это криптографические примитивы, которые позволяют сжимать большие объемы информации. Корень Меркла (в данном случае также называемый «корнем блока») может представлять все транзакции в блоке. Корни Меркла также упрощают проверку того, что небольшой фрагмент данных является частью более крупного набора данных. Например, пользователь может предоставить [доказательство Меркла](/developers/tutorials/merkle-proofs-for-offline-data-integrity/#main-content), чтобы доказать включение транзакции в определенный блок. + +Корни Меркла важны для предоставления информации о состоянии офф-чейн сети Ethereum. Вы можете думать о корнях Меркла как о «точках сохранения»: оператор говорит: «Это состояние плазма-цепи в момент времени x, и вот корень Меркла в качестве доказательства». Оператор принимает на себя обязательство по _текущему состоянию_ плазма-цепи с помощью корня Меркла, поэтому это называется «обязательством по состоянию». + +### Входы и выходы {#entries-and-exits} + +Чтобы пользователи Ethereum могли воспользоваться преимуществами Plasma, должен существовать механизм перемещения средств между основной сетью и плазма-цепями. Однако мы не можем произвольно отправлять эфир на адрес в плазма-цепи — эти цепи несовместимы, поэтому транзакция либо не удастся, либо приведет к потере средств. + +Plasma использует основной контракт, работающий на Ethereum, для обработки входов и выходов пользователей. Этот основной контракт также отвечает за отслеживание обязательств по состоянию (описанных ранее) и наказание за нечестное поведение с помощью доказательств мошенничества (подробнее об этом позже). + +#### Вход в плазма-цепь {#entering-the-plasma-chain} + +Чтобы войти в плазма-цепь, Алиса (пользователь) должна внести ETH или любой токен ERC-20 в контракт Plasma. Оператор Plasma, который следит за депозитами в контракте, воссоздает сумму, равную первоначальному депозиту Алисы, и отправляет ее на ее адрес в плазма-цепи. Алиса должна подтвердить получение средств в дочерней цепи, а затем может использовать эти средства для транзакций. + +#### Выход из плазма-цепи {#exiting-the-plasma-chain} + +Выход из плазма-цепи сложнее, чем вход, по нескольким причинам. Самая большая из них заключается в том, что, хотя Ethereum имеет информацию о состоянии плазма-цепи, он не может проверить, является ли эта информация правдивой. Злонамеренный пользователь может сделать неверное утверждение («У меня 1000 ETH») и остаться безнаказанным, предоставив поддельные доказательства в поддержку этого утверждения. + +Для предотвращения злонамеренных выводов средств вводится «период оспаривания». В течение периода оспаривания (обычно неделя) любой может оспорить запрос на вывод средств, используя доказательство мошенничества. Если оспаривание будет успешным, запрос на вывод средств будет отклонен. + +Однако обычно пользователи честны и делают правильные заявления о принадлежащих им средствах. В этом сценарии Алиса инициирует запрос на вывод средств в корневой цепи (Ethereum), отправив транзакцию в контракт Plasma. + +Она также должна предоставить доказательство Меркла, подтверждающее, что транзакция, создавшая ее средства в плазма-цепи, была включена в блок. Это необходимо для итераций Plasma, таких как [Plasma MVP](https://www.learnplasma.org/en/learn/mvp.html), которые используют модель [непотраченных выходов транзакций (UTXO)](https://en.wikipedia.org/wiki/Unspent_transaction_output). + +Другие, такие как [Plasma Cash](https://www.learnplasma.org/en/learn/cash.html), представляют средства в виде [невзаимозаменяемых токенов](/developers/docs/standards/tokens/erc-721/), а не UTXO. Вывод средств в этом случае требует доказательства владения токенами в плазма-цепи. Это делается путем отправки двух последних транзакций с участием токена и предоставления доказательства Меркла, подтверждающего включение этих транзакций в блок. + +Пользователь также должен добавить залог к запросу на вывод средств в качестве гарантии честного поведения. Если оспаривающий докажет недействительность запроса Алисы на вывод средств, ее залог будет урезан, и часть его перейдет к оспаривающему в качестве вознаграждения. + +Если период оспаривания истекает, и никто не предоставляет доказательства мошенничества, запрос Алисы на вывод средств считается действительным, что позволяет ей забрать депозиты из контракта Plasma в Ethereum. + +### Арбитраж споров {#dispute-arbitration} + +Как и любой блокчейн, плазма-цепи нуждаются в механизме для обеспечения целостности транзакций на случай злонамеренных действий участников (например, двойного расходования средств). Для этого плазма-цепи используют доказательства мошенничества для разрешения споров о действительности переходов состояний и наказания за плохое поведение. Доказательства мошенничества используются как механизм, с помощью которого дочерняя плазма-цепь подает жалобу в свою родительскую цепь или в корневую цепь. + +Доказательство мошенничества — это просто заявление о том, что определенный переход состояния является недействительным. Примером может служить ситуация, когда пользователь (Алиса) пытается дважды потратить одни и те же средства. Возможно, она потратила UTXO в транзакции с Бобом и хочет потратить тот же UTXO (который теперь принадлежит Бобу) в другой транзакции. + +Чтобы предотвратить вывод средств, Боб создаст доказательство мошенничества, предоставив доказательство того, что Алиса потратила указанный UTXO в предыдущей транзакции, и доказательство Меркла о включении транзакции в блок. Тот же процесс работает в Plasma Cash — Бобу нужно будет предоставить доказательство того, что Алиса ранее перевела токены, которые она пытается вывести. + +Если оспаривание Боба будет успешным, запрос Алисы на вывод средств будет отменен. Однако этот подход зависит от способности Боба отслеживать запросы на вывод средств в цепи. Если Боб не в сети, то Алиса может обработать злонамеренный вывод средств по истечении периода оспаривания. + +## Проблема массового выхода в Plasma {#the-mass-exit-problem-in-plasma} + +Проблема массового выхода возникает, когда большое количество пользователей пытаются одновременно вывести средства из плазма-цепи. Причина существования этой проблемы связана с одной из самых больших проблем Plasma: **недоступностью данных**. + +Доступность данных — это возможность проверить, что информация для предложенного блока действительно была опубликована в сети блокчейна. Блок считается «недоступным», если производитель публикует сам блок, но скрывает данные, использованные для его создания. + +Блоки должны быть доступны, чтобы узлы могли загрузить блок и проверить действительность транзакций. Блокчейны обеспечивают доступность данных, заставляя производителей блоков публиковать все данные транзакций он-чейн. + +Доступность данных также помогает защитить протоколы офф-чейн масштабирования, которые строятся на базовом слое Ethereum. Заставляя операторов этих цепей публиковать данные транзакций в Ethereum, любой может оспорить недействительные блоки, создав доказательства мошенничества, ссылающиеся на правильное состояние цепи. + +Плазма-цепи в основном хранят данные транзакций у оператора и **не публикуют никаких данных в основной сети** (кроме периодических обязательств по состоянию). Это означает, что пользователи должны полагаться на оператора в предоставлении данных блока, если им нужно создать доказательства мошенничества для оспаривания недействительных транзакций. Если эта система работает, то пользователи всегда могут использовать доказательства мошенничества для защиты средств. + +Проблема начинается, когда злонамеренно действует оператор, а не просто какой-либо пользователь. Поскольку оператор единолично контролирует блокчейн, у него больше стимулов для продвижения недействительных переходов состояния в более крупном масштабе, например, для кражи средств, принадлежащих пользователям в плазма-цепи. + +В этом случае использование классической системы доказательств мошенничества не работает. Оператор может легко совершить недействительную транзакцию, переведя средства Алисы и Боба на свой кошелек, и скрыть данные, необходимые для создания доказательства мошенничества. Это возможно потому, что оператор не обязан предоставлять данные пользователям или основной сети. + +Поэтому самым оптимистичным решением является попытка «массового выхода» пользователей из плазма-цепи. Массовый выход замедляет план злонамеренного оператора по краже средств и обеспечивает некоторую меру защиты для пользователей. Запросы на вывод средств упорядочиваются в зависимости от времени создания каждого UTXO (или токена), что не позволяет злонамеренным операторам опережать честных пользователей. + +Тем не менее, нам все еще нужен способ проверки действительности запросов на вывод средств во время массового выхода, чтобы предотвратить оппортунистических личностей от наживы на хаосе, обрабатывая недействительные выходы. Решение простое: требовать от пользователей публиковать последнее **действительное состояние цепи**, чтобы вывести свои деньги. + +Но у этого подхода все еще есть проблемы. Например, если всем пользователям в плазма-цепи необходимо выйти (что возможно в случае злонамеренного оператора), то все действительное состояние плазма-цепи должно быть сразу же выгружено на базовый слой Ethereum. Учитывая произвольный размер плазма-цепей (высокая пропускная способность = больше данных) и ограничения на скорость обработки Ethereum, это не идеальное решение. + +Хотя выходные игры звучат хорошо в теории, реальные массовые выходы, скорее всего, вызовут перегрузку всей сети самого Ethereum. Помимо ущерба функциональности Ethereum, плохо скоординированный массовый выход означает, что пользователи могут не успеть вывести средства до того, как оператор опустошит все аккаунты в плазма-цепи. + +## Плюсы и минусы Plasma {#pros-and-cons-of-plasma} + +| Преимущества | Недостатки | +| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Предлагает высокую пропускную способность и низкую стоимость за транзакцию. | Не поддерживает общие вычисления (не может запускать смарт-контракты). С помощью логики предикатов поддерживаются только базовые передачи токенов, свопы и несколько других типов транзакций. | +| Подходит для транзакций между произвольными пользователями (без накладных расходов на пару пользователей, если оба установлены в плазменной цепи) | Необходимо периодически следить за сетью (требование живучести) или делегировать эту ответственность кому-то другому для обеспечения безопасности ваших средств. | +| Плазма-цепи можно адаптировать к конкретным вариантам использования, не связанным с основной цепью. Любой, включая компании, может настраивать смарт-контракты Plasma для предоставления масштабируемой инфраструктуры, работающей в различных контекстах. | Полагается на одного или нескольких операторов для хранения данных и их обслуживания по запросу. | +| Снижает нагрузку на основную сеть Ethereum, перемещая вычисления и хранение офф-чейн. | Вывод средств задерживается на несколько дней из-за проблем. Для взаимозаменяемых активов это может быть смягчено поставщиками ликвидности, но это связано с соответствующими капитальными затратами. | +| | Если слишком много пользователей попытаются выйти одновременно, основная сеть Ethereum может быть перегружена. | + +## Plasma в сравнении с протоколами масштабирования уровня 2 {#plasma-vs-layer-2} + +Хотя Plasma когда-то считалась полезным решением для масштабирования Ethereum, от нее отказались в пользу [протоколов масштабирования уровня 2 (L2)](/layer-2/). Решения для масштабирования L2 решают несколько проблем Plasma: + +### Эффективность {#efficiency} + +[Ролл-апы с нулевым разглашением](/developers/docs/scaling/zk-rollups) генерируют криптографические доказательства действительности каждой партии транзакций, обработанных офф-чейн. Это не позволяет пользователям (и операторам) продвигать недействительные переходы состояний, устраняя необходимость в периодах оспаривания и выходных играх. Это также означает, что пользователям не нужно периодически следить за цепью, чтобы обезопасить свои средства. + +### Поддержка смарт-контрактов {#support-for-smart-contracts} + +Еще одна проблема с фреймворком Plasma заключалась в [невозможности поддерживать выполнение смарт-контрактов Ethereum](https://ethresear.ch/t/why-smart-contracts-are-not-feasible-on-plasma/2598/4). В результате большинство реализаций Plasma были в основном созданы для простых платежей или обмена токенами ERC-20. + +И наоборот, оптимистические ролл-апы совместимы с [виртуальной машиной Ethereum](/developers/docs/evm/) и могут запускать нативные [смарт-контракты](/developers/docs/smart-contracts/) Ethereum, что делает их полезным и _безопасным_ решением для масштабирования [децентрализованных приложений](/developers/docs/dapps/). Аналогичным образом, ведутся работы по [созданию реализации EVM с нулевым разглашением (zkEVM)](https://ethresear.ch/t/a-zk-evm-specification/11549), которая позволит ZK-ролл-апам обрабатывать произвольную логику и выполнять смарт-контракты. + +### Недоступность данных {#data-unavailability} + +Как объяснялось ранее, Plasma страдает от проблемы доступности данных. Если злонамеренный оператор продвинет недействительный переход в плазма-цепи, пользователи не смогут его оспорить, поскольку оператор может скрыть данные, необходимые для создания доказательства мошенничества. Ролл-апы решают эту проблему, заставляя операторов публиковать данные транзакций в Ethereum, что позволяет любому проверять состояние цепи и при необходимости создавать доказательства мошенничества. + +### Проблема массового выхода {#mass-exit-problem} + +ZK-ролл-апы и оптимистические ролл-апы решают проблему массового выхода Plasma различными способами. Например, ZK-ролл-ап полагается на криптографические механизмы, которые гарантируют, что операторы не смогут украсть средства пользователей ни при каких обстоятельствах. + +Аналогичным образом, оптимистические ролл-апы устанавливают период задержки на вывод средств, в течение которого любой может инициировать оспаривание и предотвратить злонамеренные запросы на вывод. Хотя это похоже на Plasma, разница в том, что верификаторы имеют доступ к данным, необходимым для создания доказательств мошенничества. Таким образом, пользователям ролл-апов не нужно участвовать в бешеной миграции «кто первый выйдет» в основную сеть Ethereum. + +## Чем Plasma отличается от сайдчейнов и шардинга? {#plasma-sidechains-sharding} + +Plasma, сайдчейны и шардинг довольно похожи, потому что все они так или иначе подключаются к основной сети Ethereum. Однако уровень и прочность этих соединений различаются, что влияет на свойства безопасности каждого решения для масштабирования. + +### Plasma в сравнении с сайдчейнами {#plasma-vs-sidechains} + +[Сайдчейн](/developers/docs/scaling/sidechains/) — это независимо работающий блокчейн, подключенный к основной сети Ethereum через двусторонний мост. [Мосты](/bridges/) позволяют пользователям обмениваться токенами между двумя блокчейнами для совершения транзакций в сайдчейне, снижая перегрузку в основной сети Ethereum и улучшая масштабируемость. +Сайдчейны используют отдельный механизм консенсуса и обычно намного меньше основной сети Ethereum. В результате перенос активов в эти цепи сопряжен с повышенным риском; учитывая отсутствие гарантий безопасности, унаследованных от основной сети Ethereum в модели сайдчейна, пользователи рискуют потерять средства в случае атаки на сайдчейн. + +И наоборот, плазма-цепи получают свою безопасность от основной сети. Это делает их заметно более безопасными, чем сайдчейны. И сайдчейны, и плазма-цепи могут иметь разные протоколы консенсуса, но разница в том, что плазма-цепи публикуют корни Меркла для каждого блока в основной сети Ethereum. Корни блоков — это небольшие фрагменты информации, которые мы можем использовать для проверки информации о транзакциях, происходящих в плазма-цепи. Если происходит атака на плазма-цепь, пользователи могут безопасно вывести свои средства обратно в основную сеть, используя соответствующие доказательства. + +### Plasma в сравнении с шардингом {#plasma-vs-sharding} + +И плазма-цепи, и шард-цепи периодически публикуют криптографические доказательства в основной сети Ethereum. Однако оба имеют разные свойства безопасности. + +Шард-цепи передают «заголовки сверки» в основную сеть, содержащие подробную информацию о каждом шарде данных. Узлы в основной сети проверяют и обеспечивают действительность шардов данных, снижая вероятность недействительных переходов шардов и защищая сеть от злонамеренных действий. + +Plasma отличается тем, что основная сеть получает лишь минимальную информацию о состоянии дочерних цепей. Это означает, что основная сеть не может эффективно проверять транзакции, проводимые в дочерних цепях, что делает их менее безопасными. + +**Примечание**: шардинг блокчейна Ethereum больше не входит в дорожную карту. Он был заменен масштабированием с помощью ролл-апов и [Danksharding](/roadmap/danksharding). + +### Используйте Plasma {#use-plasma} + +Несколько проектов предоставляют реализации Plasma, которые вы можете интегрировать в свои децентрализованные приложения: + +- [Polygon](https://polygon.technology/) (ранее Matic Network) + +## Дополнительные материалы {#further-reading} + +- [Изучите Plasma](https://www.learnplasma.org/en/) +- [Краткое напоминание о том, что означает «общая безопасность» и почему это так важно](https://old.reddit.com/r/ethereum/comments/sgd3zt/a_quick_reminder_of_what_shared_security_means/) +- [Сайдчейны в сравнении с Plasma и шардингом](https://vitalik.eth.limo/general/2019/06/12/plasma_vs_sharding.html) +- [Понимание Plasma, Часть 1: Основы](https://www.theblockcrypto.com/amp/post/10793/understanding-plasma-part-1-the-basics) +- [Жизнь и смерть Plasma](https://medium.com/dragonfly-research/the-life-and-death-of-plasma-b72c6a59c5ad#) + +_Знаете ресурс сообщества, который вам пригодился? Измените эту страницу и добавьте его!_ diff --git a/public/content/translations/ru/developers/docs/scaling/sidechains/index.md b/public/content/translations/ru/developers/docs/scaling/sidechains/index.md new file mode 100644 index 00000000000..dd93a7811ec --- /dev/null +++ b/public/content/translations/ru/developers/docs/scaling/sidechains/index.md @@ -0,0 +1,73 @@ +--- +title: "Сайдчейны" +description: "Введение в сайдчейны как решение для масштабирования, которое в настоящее время используется сообществом Ethereum." +lang: ru +sidebarDepth: 3 +--- + +Сайдчейн — это отдельный блокчейн, который работает независимо от Ethereum и соединен с основной сетью Ethereum двусторонним мостом. Сайдчейны могут иметь отдельные параметры блока и [алгоритмы консенсуса](/developers/docs/consensus-mechanisms/), которые часто предназначены для эффективной обработки транзакций. Однако использование сайдчейна сопряжено с компромиссами, поскольку он не наследует свойства безопасности Ethereum. В отличие от [решений для масштабирования 2-го уровня](/layer-2/), сайдчейны не публикуют изменения состояния и данные о транзакциях обратно в основную сеть Ethereum. + +Сайдчейны также жертвуют определенной степенью децентрализации или безопасности для достижения высокой пропускной способности ([трилемма масштабируемости](https://vitalik.eth.limo/general/2021/05/23/scaling.html)). Тем не менее, Ethereum стремится к масштабированию без ущерба для децентрализации и безопасности. + +## Как работают сайдчейны? {#how-do-sidechains-work} + +Сайдчейны — это независимые блокчейны с разной историей, планами развития и проектными решениями. Хотя сайдчейн может иметь некоторые внешние сходства с Ethereum, у него есть несколько отличительных особенностей. + +### Алгоритмы консенсуса {#consensus-algorithms} + +Одним из качеств, которые делают сайдчейны уникальными (т. е. отличными от Ethereum), является используемый алгоритм консенсуса. Сайдчейны не полагаются на Ethereum для достижения консенсуса и могут выбирать альтернативные протоколы консенсуса, которые соответствуют их потребностям. Некоторые примеры алгоритмов консенсуса, используемых в сайдчейнах: + +- [Доказательство полномочий](/developers/docs/consensus-mechanisms/poa/) +- [Делегированное доказательство доли владения](https://en.bitcoin.it/wiki/Delegated_proof_of_stake) +- [Византийская отказоустойчивость](https://decrypt.co/resources/byzantine-fault-tolerance-what-is-it-explained). + +Подобно Ethereum, сайдчейны имеют проверяющие узлы, которые верифицируют и обрабатывают транзакции, создают блоки и хранят состояние блокчейна. Валидаторы также несут ответственность за поддержание консенсуса в сети и ее защиту от злонамеренных атак. + +#### Параметры блока {#block-parameters} + +Ethereum устанавливает ограничения на [время блока](/developers/docs/blocks/#block-time) (т. е. время, необходимое для создания новых блоков) и [размер блока](/developers/docs/blocks/#block-size) (т. е. объем данных, содержащихся в блоке, выраженный в газе). И наоборот, сайдчейны часто применяют другие параметры, такие как более быстрое время блока и более высокие лимиты газа, для достижения высокой пропускной способности, быстрых транзакций и низких комиссий. + +Хотя у этого есть некоторые преимущества, это имеет критические последствия для децентрализации и безопасности сети. Параметры блока, такие как быстрое время блока и большие размеры блоков, увеличивают сложность запуска полного узла, оставляя несколько "суперузлов" ответственными за безопасность цепи. В таком сценарии возрастает вероятность сговора валидаторов или злонамеренного захвата цепи. + +Чтобы блокчейны могли масштабироваться без ущерба для децентрализации, запуск узла должен быть доступен для всех, а не только для тех, кто обладает специализированным оборудованием. Вот почему предпринимаются усилия для того, чтобы каждый мог [запустить полный узел](/developers/docs/nodes-and-clients/#why-should-i-run-an-ethereum-node) в сети Ethereum. + +### Совместимость с EVM {#evm-compatibility} + +Некоторые сайдчейны совместимы с EVM и могут выполнять контракты, разработанные для [виртуальной машины Ethereum (EVM)](/developers/docs/evm/). Совместимые с EVM сайдчейны поддерживают смарт-контракты, [написанные на Solidity](/developers/docs/smart-contracts/languages/), а также другие языки смарт-контрактов EVM, что означает, что смарт-контракты, написанные для основной сети Ethereum, также будут работать на совместимых с EVM сайдчейнах. + +Это означает, что если вы хотите использовать свое [децентрализованное приложение](/developers/docs/dapps/) в сайдчейне, вам просто нужно развернуть свой [смарт-контракт](/developers/docs/smart-contracts/) в этом сайдчейне. Он выглядит, ощущается и действует так же, как основная сеть: вы пишете контракты на Solidity и взаимодействуете с цепью через RPC сайдчейна. + +Поскольку сайдчейны совместимы с EVM, они считаются полезным [решением для масштабирования](/developers/docs/scaling/) для нативных децентрализованных приложений Ethereum. С вашим децентрализованным приложением в сайдчейне пользователи могут пользоваться более низкими комиссиями за газ и более быстрыми транзакциями, особенно если основная сеть перегружена. + +Однако, как объяснялось ранее, использование сайдчейна сопряжено со значительными компромиссами. Каждый сайдчейн отвечает за свою безопасность и не наследует свойства безопасности Ethereum. Это увеличивает вероятность злонамеренных действий, которые могут повлиять на ваших пользователей или подвергнуть риску их средства. + +### Перемещение активов {#asset-movement} + +Чтобы отдельный блокчейн стал сайдчейном для основной сети Ethereum, ему необходима возможность обеспечивать перевод активов из основной сети Ethereum и в нее. Эта совместимость с Ethereum достигается с помощью блокчейн-моста. [Мосты](/bridges/) используют смарт-контракты, развернутые в основной сети Ethereum и в сайдчейне, для контроля перевода средств между ними. + +Хотя мосты помогают пользователям перемещать средства между Ethereum и сайдчейном, активы физически не перемещаются между двумя цепями. Вместо этого для перевода ценности между цепями используются механизмы, которые обычно включают создание и сжигание активов. Подробнее о том, [как работают мосты](/developers/docs/bridges/#how-do-bridges-work). + +## Плюсы и минусы сайдчейнов {#pros-and-cons-of-sidechains} + +| Преимущества | Недостатки | +| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Технология, лежащая в основе сайдчейнов, хорошо зарекомендовала себя и выигрывает от обширных исследований и усовершенствований в дизайне. | Сайдчейны жертвуют определенной степенью децентрализации и отсутствия доверия ради масштабируемости. | +| Сайдчейны поддерживают общие вычисления и предлагают совместимость с EVM (они могут запускать нативные децентрализованные приложения Ethereum). | Сайдчейн использует отдельный механизм консенсуса и не получает преимуществ от гарантий безопасности Ethereum. | +| Сайдчейны используют различные модели консенсуса для эффективной обработки транзакций и снижения комиссий за транзакции для пользователей. | Сайдчейны требуют более высоких допущений по доверию (например, кворум злонамеренных валидаторов сайдчейна может совершить мошенничество). | +| Совместимые с EVM сайдчейны позволяют децентрализованным приложениям расширять свою экосистему. | | + +### Использование сайдчейнов {#use-sidechains} + +Несколько проектов предоставляют реализации сайдчейнов, которые вы можете интегрировать в свои децентрализованные приложения: + +- [Polygon PoS](https://polygon.technology/solutions/polygon-pos) +- [Skale](https://skale.network/) +- [Gnosis Chain (ранее xDai)](https://www.gnosischain.com/) +- [Loom Network](https://loomx.io/) +- [Metis Andromeda](https://www.metis.io/) + +## Дополнительные материалы {#further-reading} + +- [Масштабирование децентрализованных приложений Ethereum с помощью сайдчейнов](https://medium.com/loom-network/dappchains-scaling-ethereum-dapps-through-sidechains-f99e51fff447) _8 февраля 2018 г. - Георгиос Константинопулос_ + +_Знаете ресурс сообщества, который вам пригодился? Измените эту страницу и добавьте его!_ diff --git a/public/content/translations/ru/developers/docs/scaling/state-channels/index.md b/public/content/translations/ru/developers/docs/scaling/state-channels/index.md new file mode 100644 index 00000000000..e7c00060025 --- /dev/null +++ b/public/content/translations/ru/developers/docs/scaling/state-channels/index.md @@ -0,0 +1,261 @@ +--- +title: "Каналы состояния" +description: "Введение в каналы состояния и платежные каналы в качестве решения для масштабирования, которое в настоящее время используется сообществом Ethereum." +lang: ru +sidebarDepth: 3 +--- + +Каналы состояний позволяют участникам безопасно совершать транзакции вне сети, сводя взаимодействие с основной сетью Ethereum к минимуму. Участники канала могут проводить произвольное количество оффчейн-транзакций, отправляя только две ончейн-транзакции для открытия и закрытия канала. Это обеспечивает чрезвычайно высокую пропускную способность транзакций и приводит к снижению затрат для пользователей. + +## Предварительные условия {#prerequisites} + +Вам следует прочитать и понять наши страницы о [масштабировании Ethereum](/developers/docs/scaling/) и [уровне 2](/layer-2/). + +## Что такое каналы? {#what-are-channels} + +Публичные блокчейны, такие как Ethereum, сталкиваются с проблемами масштабируемости из-за своей распределенной архитектуры: ончейн-транзакции должны выполняться всеми узлами. Узлы должны иметь возможность обрабатывать объем транзакций в блоке, используя скромное оборудование, что накладывает ограничение на пропускную способность транзакций для сохранения децентрализации сети. Каналы блокчейна решают эту проблему, позволяя пользователям взаимодействовать оффчейн, при этом полагаясь на безопасность основной цепи для окончательного расчета. + +Каналы — это простые одноранговые протоколы, которые позволяют двум сторонам совершать множество транзакций между собой, а затем публиковать в блокчейне только окончательные результаты. Канал использует криптографию, чтобы доказать, что генерируемые им сводные данные действительно являются результатом действительного набора промежуточных транзакций. [Смарт-контракт с мультиподписью (multisig)](/developers/docs/smart-contracts/#multisig) гарантирует, что транзакции подписаны надлежащими сторонами. + +С помощью каналов изменения состояния выполняются и проверяются заинтересованными сторонами, что минимизирует вычисления на уровне исполнения Ethereum. Это уменьшает перегрузку в сети Ethereum, а также увеличивает скорость обработки транзакций для пользователей. + +Каждый канал управляется [смарт-контрактом с мультиподписью](/developers/docs/smart-contracts/#multisig), работающим в сети Ethereum. Чтобы открыть канал, участники развертывают его контракт ончейн и вносят в него средства. Обе стороны совместно подписывают обновление состояния для инициализации состояния канала, после чего они могут быстро и свободно совершать транзакции оффчейн. + +Чтобы закрыть канал, участники отправляют последнее согласованное состояние канала ончейн. После этого смарт-контракт распределяет заблокированные средства в соответствии с балансом каждого участника в конечном состоянии канала. + +Одноранговые каналы особенно полезны в ситуациях, когда заранее определенные участники хотят совершать транзакции с высокой частотой без видимых накладных расходов. Каналы блокчейна делятся на две категории: **платежные каналы** и **каналы состояний**. + +## Платежные каналы {#payment-channels} + +Платежный канал лучше всего можно описать как "двусторонний реестр", который совместно ведут два пользователя. Начальный баланс реестра — это сумма депозитов, заблокированных в ончейн-контракте на этапе открытия канала. Переводы в платежном канале могут выполняться мгновенно и без участия самого блокчейна, за исключением первоначального одноразового ончейн-создания и последующего закрытия канала. + +Обновления баланса реестра (т. е. состояния платежного канала) требуют одобрения всех сторон канала. Обновление канала, подписанное всеми его участниками, считается окончательным, так же как транзакция в сети Ethereum. + +Платежные каналы были одним из первых решений для масштабирования, разработанных для минимизации дорогостоящей ончейн-активности при простых взаимодействиях пользователей (например, переводах ETH, атомарных свопах, микроплатежах). Участники канала могут совершать неограниченное количество мгновенных транзакций без комиссии между собой, пока общая сумма их переводов не превышает депонированные токены. + +## Каналы состояний {#state-channels} + +Помимо поддержки оффчейн-платежей, платежные каналы оказались неэффективными для обработки общей логики перехода состояний. Каналы состояний были созданы для решения этой проблемы и использования каналов для масштабирования вычислений общего назначения. + +Каналы состояний по-прежнему имеют много общего с платежными каналами. Например, пользователи взаимодействуют путем обмена криптографически подписанными сообщениями (транзакциями), которые также должны быть подписаны другими участниками канала. Если предлагаемое обновление состояния не подписано всеми участниками, оно считается недействительным. + +Однако, помимо хранения балансов пользователей, канал также отслеживает текущее состояние хранилища контракта (т. е. значения переменных контракта). + +Это позволяет выполнять смарт-контракт оффчейн между двумя пользователями. В этом сценарии обновления внутреннего состояния смарт-контракта требуют одобрения только от участников, создавших канал. + +Хотя это решает описанную ранее проблему масштабируемости, это имеет последствия для безопасности. В сети Ethereum достоверность переходов состояния обеспечивается протоколом консенсуса сети. Это делает невозможным предложение неверного обновления состояния смарт-контракта или изменение его выполнения. + +Каналы состояний не имеют таких же гарантий безопасности. В некоторой степени канал состояния является миниатюрной версией основной сети. При ограниченном наборе участников, обеспечивающих соблюдение правил, возрастает вероятность вредоносного поведения (например, предложения недействительных обновлений состояния). Каналы состояний получают свою безопасность от системы арбитража споров, основанной на [доказательствах мошенничества](/glossary/#fraud-proof). + +## Как работают каналы состояний {#how-state-channels-work} + +По сути, активность в канале состояний — это сеанс взаимодействий с участием пользователей и системы блокчейна. Пользователи в основном общаются друг с другом оффчейн и взаимодействуют с базовым блокчейном только для открытия, закрытия канала или урегулирования потенциальных споров между участниками. + +В следующем разделе описывается основной рабочий процесс канала состояний: + +### Открытие канала {#opening-the-channel} + +Открытие канала требует от участников внесения средств в смарт-контракт в основной сети. Депозит также функционирует как виртуальная вкладка, поэтому участвующие субъекты могут свободно совершать транзакции без необходимости немедленного расчета платежей. Только когда канал финализируется ончейн, стороны рассчитываются друг с другом и выводят то, что осталось от их вклада. + +Этот депозит также служит залогом, гарантирующим честное поведение каждого участника. Если вкладчики будут признаны виновными в злонамеренных действиях на этапе разрешения спора, контракт сократит их депозит. + +Участники канала должны подписать начальное состояние, с которым они все согласны. Это служит генезисом канала состояний, после чего пользователи могут начать проводить транзакции. + +### Использование канала {#using-the-channel} + +После инициализации состояния канала участники взаимодействуют, подписывая транзакции и отправляя их друг другу на утверждение. Участники инициируют обновления состояния с помощью этих транзакций и подписывают обновления состояния от других. Каждая транзакция содержит: + +- Поле **nonce**, которое служит уникальным идентификатором транзакций и предотвращает повторные атаки. Оно также определяет порядок, в котором происходили обновления состояния (что важно для разрешения споров). + +- Старое состояние канала + +- Новое состояние канала + +- Транзакция, которая вызывает переход состояния (например, Алиса отправляет 5 ETH Бобу). + +Обновления состояния в канале не транслируются ончейн, как это обычно бывает, когда пользователи взаимодействуют в основной сети, что соответствует цели каналов состояний по минимизации ончейн-следа. Пока участники соглашаются с обновлениями состояния, они так же окончательны, как и транзакция Ethereum. Участникам нужно полагаться на консенсус основной сети только в случае возникновения спора. + +### Закрытие канала {#closing-the-channel} + +Закрытие канала состояний требует отправки окончательного, согласованного состояния канала в ончейн-смарт-контракт. Детали, указанные в обновлении состояния, включают количество ходов каждого участника и список одобренных транзакций. + +После проверки того, что обновление состояния является действительным (т. е. оно подписано всеми сторонами), смарт-контракт финализирует канал и распределяет заблокированные средства в соответствии с результатом канала. Платежи, совершенные оффчейн, применяются к состоянию Ethereum, и каждый участник получает свою оставшуюся часть заблокированных средств. + +Описанный выше сценарий представляет то, что происходит в «счастливом» случае. Иногда пользователи могут не прийти к соглашению и не завершить канал («печальный» случай). Любое из следующих утверждений может быть верным для данной ситуации: + +- Участники выходят из сети и не могут предложить переходы состояния. + +- Участники отказываются совместно подписывать действительные обновления состояния. + +- Участники пытаются завершить канал, предлагая старое обновление состояния для ончейн-контракта. + +- Участники предлагают недействительные переходы состояний для подписания другими. + +Всякий раз, когда между участниками канала нарушается консенсус, последним вариантом является опора на консенсус основной сети для принудительного установления окончательного, действительного состояния канала. В этом случае закрытие канала состояний требует разрешения споров ончейн. + +### Разрешение споров {#settling-disputes} + +Обычно стороны в канале заранее договариваются о закрытии канала и совместно подписывают последнее изменение состояния, которое они отправляют в смарт-контракт. После того как обновление будет одобрено ончейн, выполнение оффчейн-смарт-контракта завершается, и участники выходят из канала со своими деньгами. + +Однако одна из сторон может подать ончейн-запрос на прекращение выполнения смарт-контракта и завершение канала, не дожидаясь одобрения контрагента. Если возникает любая из описанных ранее ситуаций нарушения консенсуса, любая из сторон может запустить ончейн-контракт для закрытия канала и распределения средств. Это обеспечивает **недоверительность**, гарантируя, что честные стороны могут вывести свои депозиты в любой момент, независимо от действий другой стороны. + +Чтобы обработать выход из канала, пользователь должен отправить последнее действительное обновление состояния приложения в ончейн-контракт. Если это подтверждается (т. е. имеет подпись всех сторон), то средства перераспределяются в их пользу. + +Однако при выполнении запросов на выход от одного пользователя существует задержка. Если запрос на завершение канала был одобрен единогласно, то ончейн-транзакция выхода выполняется немедленно. + +Задержка вступает в игру при выходе одного пользователя из-за возможности мошеннических действий. Например, участник канала может попытаться завершить канал в Ethereum, отправив старое обновление состояния ончейн. + +В качестве контрмеры каналы состояний позволяют честным пользователям оспаривать недействительные обновления состояния, отправляя последнее действительное состояние канала ончейн. Каналы состояний спроектированы таким образом, что более новые, согласованные обновления состояния имеют приоритет над более старыми обновлениями. + +Как только один из участников запускает ончейн-систему разрешения споров, другая сторона должна ответить в течение определенного времени (называемого окном оспаривания). Это позволяет пользователям оспаривать транзакцию выхода, особенно если другая сторона применяет устаревшее обновление. + +В любом случае, у пользователей канала всегда есть сильные гарантии окончательности: если переход состояния, которым они владеют, был подписан всеми участниками и является самым последним обновлением, то он имеет такую же окончательность, как и обычная ончейн-транзакция. Им все еще приходится оспаривать другую сторону ончейн, но единственным возможным исходом является финализация последнего действительного состояния, которым они владеют. + +### Как каналы состояний взаимодействуют с Ethereum? {#how-do-state-channels-interact-with-ethereum} + +Хотя они существуют как оффчейн-протоколы, у каналов состояний есть ончейн-компонент: смарт-контракт, развернутый в Ethereum при открытии канала. Этот контракт контролирует активы, внесенные в канал, проверяет обновления состояния и разрешает споры между участниками. + +Каналы состояний не публикуют данные о транзакциях или обязательства по состоянию в основной сети, в отличие от решений для масштабирования [уровня 2](/layer-2/). Однако они более тесно связаны с основной сетью, чем, скажем, [сайдчейны](/developers/docs/scaling/sidechains/), что делает их несколько безопаснее. + +Каналы состояний полагаются на основной протокол Ethereum в следующих аспектах: + +#### 1. Живучесть {#liveness} + +Ончейн-контракт, развертываемый при открытии канала, отвечает за функциональность канала. Если контракт работает в Ethereum, то канал всегда доступен для использования. И наоборот, сайдчейн всегда может выйти из строя, даже если основная сеть работает, что подвергает риску средства пользователей. + +#### 2. Безопасность {#security} + +В некоторой степени каналы состояний полагаются на Ethereum для обеспечения безопасности и защиты пользователей от злонамеренных участников. Как обсуждается в последующих разделах, каналы используют механизм доказательства мошенничества, который позволяет пользователям оспаривать попытки завершить канал с недействительным или устаревшим обновлением. + +В этом случае честная сторона предоставляет последнее действительное состояние канала в качестве доказательства мошенничества в ончейн-контракт для проверки. Доказательства мошенничества позволяют взаимно недоверяющим сторонам проводить оффчейн-транзакции, не рискуя при этом своими средствами. + +#### 3. Финальность {#finality} + +Обновления состояния, коллективно подписанные пользователями канала, считаются равносильными ончейн-транзакциям. Тем не менее, вся деятельность внутри канала достигает истинной окончательности только тогда, когда канал закрывается в Ethereum. + +В оптимистичном случае обе стороны могут сотрудничать, подписать окончательное обновление состояния и отправить его ончейн для закрытия канала, после чего средства распределяются в соответствии с окончательным состоянием канала. В пессимистичном случае, когда кто-то пытается обмануть, публикуя неверное обновление состояния ончейн, его транзакция не будет завершена до истечения окна оспаривания. + +## Виртуальные каналы состояний {#virtual-state-channels} + +Наивной реализацией канала состояний было бы развертывание нового контракта, когда два пользователя хотят выполнить приложение оффчейн. Это не только нецелесообразно, но и сводит на нет экономическую эффективность каналов состояний (затраты на ончейн-транзакции могут быстро возрасти). + +Для решения этой проблемы были созданы «виртуальные каналы». В отличие от обычных каналов, которые требуют ончейн-транзакций для открытия и закрытия, виртуальный канал можно открыть, выполнить и завершить без взаимодействия с основной цепью. С помощью этого метода даже возможно разрешать споры оффчейн. + +Эта система опирается на существование так называемых «реестровых каналов», которые были профинансированы ончейн. Виртуальные каналы между двумя сторонами могут быть построены на основе существующего реестрового канала, при этом владелец(ы) реестрового канала выступают в качестве посредника. + +Пользователи в каждом виртуальном канале взаимодействуют через новый экземпляр контракта, при этом реестровый канал может поддерживать несколько экземпляров контрактов. Состояние реестрового канала также содержит более одного состояния хранилища контракта, что позволяет параллельно выполнять приложения оффчейн между разными пользователями. + +Как и в обычных каналах, пользователи обмениваются обновлениями состояния для продвижения конечного автомата. Если не возникает спор, к посреднику нужно обращаться только при открытии или закрытии канала. + +### Виртуальные платежные каналы {#virtual-payment-channels} + +Виртуальные платежные каналы работают по той же идее, что и виртуальные каналы состояний: участники, подключенные к одной сети, могут передавать сообщения без необходимости открывать новый канал ончейн. В виртуальных платежных каналах переводы средств маршрутизируются через одного или нескольких посредников с гарантиями того, что только предполагаемый получатель может получить переведенные средства. + +## Применения каналов состояний {#applications-of-state-channels} + +### Платежи {#payments} + +Ранние каналы блокчейна были простыми протоколами, которые позволяли двум участникам проводить быстрые, недорогие переводы оффчейн, не платя высоких комиссий за транзакции в основной сети. Сегодня платежные каналы по-прежнему полезны для приложений, предназначенных для обмена и внесения эфира и токенов. + +Платежи на основе каналов имеют следующие преимущества: + +1. **Пропускная способность**: количество оффчейн-транзакций в канале не связано с пропускной способностью Ethereum, на которую влияют различные факторы, особенно размер и время блока. Выполняя транзакции оффчейн, каналы блокчейна могут достигать более высокой пропускной способности. + +2. **Конфиденциальность**: поскольку каналы существуют оффчейн, детали взаимодействия между участниками не записываются в публичный блокчейн Ethereum. Пользователям канала нужно взаимодействовать ончейн только при финансировании и закрытии каналов или при разрешении споров. Таким образом, каналы полезны для людей, которые желают большей конфиденциальности транзакций. + +3. **Задержка**: оффчейн-транзакции, проводимые между участниками канала, могут быть урегулированы мгновенно, если обе стороны сотрудничают, что сокращает задержки. В отличие от этого, отправка транзакции в основной сети требует ожидания, пока узлы обработают транзакцию, создадут новый блок с транзакцией и достигнут консенсуса. Пользователям также может потребоваться дождаться большего количества подтверждений блока, прежде чем считать транзакцию завершенной. + +4. **Стоимость**: каналы состояний особенно полезны в ситуациях, когда набор участников будет обмениваться множеством обновлений состояния в течение длительного периода. Единственные понесенные затраты — это открытие и закрытие смарт-контракта канала состояний; каждое изменение состояния между открытием и закрытием канала будет дешевле предыдущего, поскольку стоимость расчета распределяется соответствующим образом. + +Внедрение каналов состояний в решениях уровня 2, таких как [ролл-апы](/developers/docs/scaling/#rollups), может сделать их еще более привлекательными для платежей. Хотя каналы предлагают дешевые платежи, затраты на настройку ончейн-контракта в основной сети на этапе открытия могут быть высокими, особенно когда плата за газ резко возрастает. Ролл-апы на основе Ethereum предлагают [более низкие комиссии за транзакции](https://l2fees.info/) и могут снизить накладные расходы для участников канала за счет снижения платы за установку. + +### Микротранзакции {#microtransactions} + +Микротранзакции — это платежи на небольшую сумму (например, меньше доли доллара), которые предприятия не могут обрабатывать без убытков. Эти организации должны платить поставщикам платежных услуг, что они не могут делать, если маржа по платежам клиентов слишком низка для получения прибыли. + +Платежные каналы решают эту проблему, снижая накладные расходы, связанные с микротранзакциями. Например, поставщик интернет-услуг (ISP) может открыть платежный канал с клиентом, что позволит ему осуществлять небольшие платежи каждый раз, когда он пользуется услугой. + +Помимо затрат на открытие и закрытие канала, участники не несут дополнительных расходов на микротранзакции (нет платы за газ). Это взаимовыгодная ситуация, поскольку клиенты получают больше гибкости в том, сколько они платят за услуги, а предприятия не теряют прибыльные микротранзакции. + +### Децентрализованные приложения {#decentralized-applications} + +Как и платежные каналы, каналы состояний могут производить условные платежи в соответствии с конечными состояниями конечного автомата. Каналы состояний также могут поддерживать произвольную логику перехода состояний, что делает их полезными для выполнения общих приложений оффчейн. + +Каналы состояний часто ограничиваются простыми пошаговыми приложениями, так как это упрощает управление средствами, внесенными в ончейн-контракт. Кроме того, при ограниченном количестве сторон, обновляющих состояние оффчейн-приложения с определенными интервалами, наказание нечестного поведения становится относительно простым. + +Эффективность приложения канала состояний также зависит от его конструкции. Например, разработчик может развернуть контракт канала приложения ончейн один раз и позволить другим игрокам повторно использовать приложение, не обращаясь к ончейну. В этом случае исходный канал приложения служит в качестве реестрового канала, поддерживающего несколько виртуальных каналов, каждый из которых запускает новый экземпляр смарт-контракта приложения оффчейн. + +Потенциальным вариантом использования приложений с каналами состояний являются простые игры для двух игроков, в которых средства распределяются в зависимости от исхода игры. Преимущество здесь в том, что игрокам не нужно доверять друг другу (недоверительность), а ончейн-контракт, а не игроки, контролирует распределение средств и урегулирование споров (децентрализация). + +Другие возможные варианты использования приложений с каналами состояний включают владение именами ENS, реестры NFT и многое другое. + +### Атомарные переводы {#atomic-transfers} + +Ранние платежные каналы были ограничены переводами между двумя сторонами, что ограничивало их удобство использования. Однако появление виртуальных каналов позволило людям направлять переводы через посредников (т. е. несколько p2p-каналов) без необходимости открывать новый канал ончейн. + +Часто описываемые как "многопроходные переводы", маршрутизируемые платежи являются атомарными (т. е. либо все части транзакции выполняются успешно, либо она полностью отменяется). Атомарные переводы используют [Hashed Timelock Contracts (HTLC)](https://en.bitcoin.it/wiki/Hash_Time_Locked_Contracts), чтобы гарантировать, что платеж будет выполнен только при соблюдении определенных условий, тем самым снижая риск контрагента. + +## Недостатки использования каналов состояний {#drawbacks-of-state-channels} + +### Предположения о живучести {#liveness-assumptions} + +Для обеспечения эффективности каналы состояний устанавливают временные ограничения на возможность участников канала реагировать на споры. Это правило предполагает, что участники всегда будут в сети, чтобы отслеживать активность канала и при необходимости оспаривать вызовы. + +В действительности пользователи могут отключаться от сети по независящим от них причинам (например, плохое интернет-соединение, механическая поломка и т. д.). Если честный пользователь отключается от сети, злоумышленник может воспользоваться ситуацией, представив старые промежуточные состояния в арбитражный контракт и украв вложенные средства. + +Некоторые каналы используют "сторожевые башни" — сущности, ответственные за отслеживание ончейн-событий споров от имени других и принятие необходимых мер, таких как оповещение заинтересованных сторон. Однако это может увеличить расходы на использование канала состояний. + +### Недоступность данных {#data-unavailability} + +Как объяснялось ранее, оспаривание недействительного спора требует представления последнего действительного состояния канала состояний. Это еще одно правило, основанное на предположении, что пользователи имеют доступ к последнему состоянию канала. + +Хотя ожидание того, что пользователи канала будут хранить копии состояния оффчейн-приложения, является разумным, эти данные могут быть утеряны из-за ошибки или механического сбоя. Если у пользователя нет резервной копии данных, он может только надеяться, что другая сторона не завершит недействительный запрос на выход, используя имеющиеся у нее старые переходы состояний. + +Пользователям Ethereum не приходится сталкиваться с этой проблемой, поскольку сеть обеспечивает соблюдение правил доступности данных. Данные транзакций хранятся и распространяются всеми узлами и доступны для загрузки пользователями по мере необходимости. + +### Проблемы с ликвидностью {#liquidity-issues} + +Для создания канала блокчейна участникам необходимо заблокировать средства в ончейн-смарт-контракте на время существования канала. Это снижает ликвидность пользователей канала, а также ограничивает каналы теми, кто может позволить себе держать средства заблокированными в основной сети. + +Однако реестровые каналы, управляемые оффчейн-поставщиком услуг (OSP), могут уменьшить проблемы с ликвидностью для пользователей. Два участника, подключенные к реестровому каналу, могут создать виртуальный канал, который они могут открыть и завершить полностью оффчейн в любое время. + +Оффчейн-поставщики услуг также могут открывать каналы с несколькими участниками, что делает их полезными для маршрутизации платежей. Конечно, пользователи должны платить OSP за их услуги, что для некоторых может быть нежелательно. + +### Атаки вредительства (Griefing attacks) {#griefing-attacks} + +Атаки вредительства (Griefing attacks) являются общей чертой систем, основанных на доказательствах мошенничества. Атака вредительства не приносит прямой выгоды атакующему, но причиняет вред (т. е. ущерб) жертве, отсюда и название. + +Доказательство мошенничества подвержено атакам вредительства, потому что честная сторона должна отвечать на каждый спор, даже недействительный, иначе она рискует потерять свои средства. Злоумышленник может решить многократно публиковать устаревшие переходы состояний ончейн, заставляя честную сторону отвечать действительным состоянием. Стоимость этих ончейн-транзакций может быстро возрасти, в результате чего честные стороны понесут убытки. + +### Предопределенные наборы участников {#predefined-participant-sets} + +По своей конструкции количество участников, составляющих канал состояний, остается неизменным в течение всего срока его существования. Это связано с тем, что обновление набора участников усложнит работу канала, особенно при его финансировании или урегулировании споров. Добавление или удаление участников также потребует дополнительной ончейн-активности, что увеличивает накладные расходы для пользователей. + +Хотя это упрощает рассуждения о каналах состояний, это ограничивает полезность их конструкций для разработчиков приложений. Это отчасти объясняет, почему от каналов состояний отказались в пользу других решений для масштабирования, таких как ролл-апы. + +### Параллельная обработка транзакций {#parallel-transaction-processing} + +Участники канала состояний отправляют обновления состояния по очереди, поэтому они лучше всего подходят для "пошаговых приложений" (например, шахматной партии на двоих). Это устраняет необходимость одновременной обработки обновлений состояния и сокращает работу, которую должен выполнять ончейн-контракт для наказания тех, кто публикует устаревшие обновления. Однако побочным эффектом этой конструкции является то, что транзакции зависят друг от друга, что увеличивает задержку и ухудшает общее впечатление пользователя. + +Некоторые каналы состояний решают эту проблему, используя "полнодуплексную" конструкцию, которая разделяет оффчейн-состояние на два однонаправленных "симплексных" состояния, что позволяет одновременно обновлять состояния. Такие конструкции улучшают пропускную способность оффчейн и уменьшают задержки транзакций. + +## Использование каналов состояний {#use-state-channels} + +Несколько проектов предоставляют реализации каналов состояния, которые вы можете интегрировать в свои децентрализованные приложения: + +- [Connext](https://connext.network/) +- [Kchannels](https://www.kchannels.io/) +- [Perun](https://perun.network/) +- [Raiden](https://raiden.network/) +- [Statechannels.org](https://statechannels.org/) + +## Дополнительные материалы {#further-reading} + +**Каналы состояния** + +- [Разбираемся в решениях масштабирования уровня 2 в Ethereum: каналы состояний, Plasma и Truebit](https://medium.com/l4-media/making-sense-of-ethereums-layer-2-scaling-solutions-state-channels-plasma-and-truebit-22cb40dcc2f4)_ — Джош Старк, 12 февраля 2018 г._ +- [Каналы состояний — объяснение](https://www.jeffcoleman.ca/state-channels/)_ — 6 ноября 2015 г., Джефф Коулман_ +- [Основы каналов состояний](https://education.district0x.io/general-topics/understanding-ethereum/basics-state-channels/) _District0x_ +- [Каналы состояний блокчейна: современное состояние](https://ieeexplore.ieee.org/document/9627997) + +_Знаете ресурс сообщества, который вам пригодился? Измените эту страницу и добавьте его!_ diff --git a/public/content/translations/ru/developers/docs/scaling/validium/index.md b/public/content/translations/ru/developers/docs/scaling/validium/index.md new file mode 100644 index 00000000000..e78c2d25dce --- /dev/null +++ b/public/content/translations/ru/developers/docs/scaling/validium/index.md @@ -0,0 +1,166 @@ +--- +title: "Валидиум" +description: "Введение в Validium как решение для масштабирования, которое в настоящее время используется сообществом Ethereum." +lang: ru +sidebarDepth: 3 +--- + +Валидиум — это [решение для масштабирования](/developers/docs/scaling/), которое обеспечивает целостность транзакций с помощью доказательств действительности, таких как [ZK-роллапы](/developers/docs/scaling/zk-rollups/), но не хранит данные о транзакциях в основной сети Ethereum. Несмотря на то, что доступность данных вне сети (оффчейн) сопряжена с компромиссами, она может привести к значительному улучшению масштабируемости (валидиумы могут обрабатывать [~9000 транзакций в секунду или более](https://blog.matter-labs.io/zkrollup-vs-validium-starkex-5614e38bc263)). + +## Предварительные условия {#prerequisites} + +Вам следует прочитать и понять нашу страницу о [масштабировании Ethereum](/developers/docs/scaling/) и [уровне 2](/layer-2). + +## Что такое валидиум? {#what-is-validium} + +Валидиумы — это решения для масштабирования, которые используют доступность данных и вычисления вне сети и предназначены для повышения пропускной способности за счет обработки транзакций за пределами основной сети Ethereum. Подобно роллапам с нулевым разглашением (ZK-роллапы), валидиумы публикуют [доказательства с нулевым разглашением](/glossary/#zk-proof) для проверки транзакций вне сети на Ethereum. Это предотвращает недействительные переходы состояния и повышает гарантии безопасности цепочки валидиума. + +Эти "доказательства действительности" могут быть в форме ZK-SNARK (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) или ZK-STARK (Zero-Knowledge Scalable Transparent ARgument of Knowledge). Подробнее о [доказательствах с нулевым разглашением](https://consensys.net/blog/blockchain-explained/zero-knowledge-proofs-starks-vs-snarks/). + +Средства, принадлежащие пользователям валидиума, контролируются смарт-контрактом на Ethereum. Валидиумы предлагают практически мгновенный вывод средств, как и ZK-роллапы; как только доказательство действительности запроса на вывод будет проверено в основной сети, пользователи смогут вывести средства, предоставив [доказательства Меркла](/developers/tutorials/merkle-proofs-for-offline-data-integrity/). Доказательство Меркла подтверждает включение транзакции пользователя на вывод средств в проверенный пакет транзакций, позволяя ончейн-контракту обработать вывод. + +Однако средства пользователей валидиума могут быть заморожены, а вывод средств ограничен. Это может произойти, если менеджеры по обеспечению доступности данных в цепочке валидиума скрывают от пользователей данные о состоянии вне сети. Без доступа к данным о транзакциях пользователи не могут рассчитать доказательство Меркла, необходимое для подтверждения владения средствами и выполнения вывода средств. + +Это основное различие между валидиумами и ZK-роллапами — их положение в спектре доступности данных. Оба решения по-разному подходят к хранению данных, что сказывается на безопасности и отсутствии необходимости в доверии. + +## Как валидиумы взаимодействуют с Ethereum? {#how-do-validiums-interact-with-ethereum} + +Валидиумы — это протоколы масштабирования, построенные на основе существующей цепи Ethereum. Хотя транзакции выполняются вне сети, цепочка валидиума управляется набором смарт-контрактов, развернутых в основной сети, включая: + +1. **Контракт-верификатор**: контракт-верификатор проверяет действительность доказательств, представленных оператором валидиума при внесении обновлений состояния. Сюда входят доказательства действительности, подтверждающие правильность транзакций вне сети, и доказательства доступности данных, проверяющие существование данных о транзакциях вне сети. + +2. **Основной контракт**: основной контракт хранит обязательства по состоянию (корни Меркла), представленные производителями блоков, и обновляет состояние валидиума после проверки доказательства действительности в сети. Этот контракт также обрабатывает депозиты и выводы средств из цепи валидиума. + +Валидиумы также зависят от основной сети Ethereum в следующих аспектах: + +### Расчет {#settlement} + +Транзакции, выполненные в валидиуме, не могут быть полностью подтверждены, пока родительская цепочка не проверит их действительность. Все операции, проводимые в валидиуме, в конечном итоге должны быть рассчитаны в основной сети. Блокчейн Ethereum также предоставляет "гарантии расчета" для пользователей валидиума, что означает, что транзакции вне сети не могут быть отменены или изменены после их фиксации в сети. + +### Безопасность {#security} + +Ethereum, действуя как уровень расчетов, также гарантирует действительность переходов состояния в валидиуме. Транзакции вне сети, выполненные в цепи валидиума, проверяются с помощью смарт-контракта на базовом уровне Ethereum. + +Если ончейн-контракт верификатора сочтет доказательство недействительным, транзакции будут отклонены. Это означает, что операторы должны удовлетворять условиям действительности, установленным протоколом Ethereum, перед обновлением состояния валидиума. + +## Как работает валидиум? {#how-does-validium-work} + +### Транзакции {#transactions} + +Пользователи отправляют транзакции оператору — узлу, ответственному за выполнение транзакций в цепи валидиума. Некоторые валидиумы могут использовать единственного оператора для выполнения цепочки или полагаться на механизм [доказательства доли владения (PoS)](/developers/docs/consensus-mechanisms/pos/) для ротации операторов. + +Оператор объединяет транзакции в пакет и отправляет его в схему доказательства для проведения доказательства. Схема доказательства принимает пакет транзакций (и другие соответствующие данные) в качестве входных данных и выдает доказательство действительности, подтверждающее, что операции были выполнены правильно. + +### Обязательства по состоянию {#state-commitments} + +Состояние валидиума хэшируется в виде дерева Меркла, корень которого хранится в основном контракте на Ethereum. Корень Меркла, также известный как корень состояния, действует как криптографическое обязательство по отношению к текущему состоянию аккаунтов и балансов в валидиуме. + +Чтобы выполнить обновление состояния, оператор должен вычислить новый корень состояния (после выполнения транзакций) и отправить его в ончейн-контракт. Если доказательство действительности проходит проверку, предлагаемое состояние принимается, и валидиум переключается на новый корень состояния. + +### Депозиты и выводы средств {#deposits-and-withdrawals} + +Пользователи переводят средства из Ethereum в валидиум, внося ETH (или любой ERC-совместимый токен) в ончейн-контракт. Контракт передает событие депозита в валидиум вне сети, где на адрес пользователя зачисляется сумма, равная его депозиту. Оператор также включает эту транзакцию пополнения в новый пакет. + +Чтобы вернуть средства в основную сеть, пользователь валидиума инициирует транзакцию вывода и отправляет ее оператору, который проверяет запрос на вывод и включает его в пакет. Активы пользователя в цепи валидиума также уничтожаются, прежде чем они смогут покинуть систему. После проверки доказательства действительности, связанного с пакетом, пользователь может вызвать основной контракт для вывода остатка своего первоначального депозита. + +В качестве механизма защиты от цензуры протокол валидиума позволяет пользователям выводить средства непосредственно из контракта валидиума, не обращаясь к оператору. В этом случае пользователям необходимо предоставить доказательство Меркла контракту-верификатору, показывающее включение аккаунта в корень состояния. Если доказательство принято, пользователь может вызвать функцию вывода средств основного контракта, чтобы вывести свои средства из валидиума. + +### Отправка пакетов {#batch-submission} + +После выполнения пакета транзакций оператор представляет связанное с ним доказательство действительности в контракт-верификатор и предлагает новый корень состояния основному контракту. Если доказательство действительное, основной контракт обновляет состояние валидиума и завершает результаты транзакций в пакете. + +В отличие от ZK-роллапа, производители блоков в валидиуме не обязаны публиковать данные транзакций для пакетов транзакций (только заголовки блоков). Это делает валидиум исключительно оффчейн-протоколом масштабирования, в отличие от "гибридных" протоколов масштабирования (т. е. [уровень 2](/layer-2/)), которые публикуют данные о состоянии в основной цепи Ethereum, используя данные BLOB-объектов, `calldata` или их комбинацию. + +### Доступность данных {#data-availability} + +Как уже упоминалось, валидиумы используют модель доступности данных вне сети, где операторы хранят все данные транзакций за пределами основной сети Ethereum. Небольшой объем данных в сети валидиума улучшает масштабируемость (пропускная способность не ограничена мощностью обработки данных Ethereum) и снижает комиссии для пользователей (стоимость публикации данных в сети ниже). + +Однако доступность данных вне сети создает проблему: данные, необходимые для создания или проверки доказательств Меркла, могут быть недоступны. Это означает, что пользователи могут быть не в состоянии вывести средства из ончейн-контракта, если операторы будут действовать злонамеренно. + +Различные решения на базе валидиума пытаются решить эту проблему путем децентрализации хранения данных о состоянии. Это предполагает принуждение производителей блоков к отправке базовых данных "менеджерам по доступности данных", ответственным за хранение данных вне сети и предоставление их пользователям по запросу. + +Менеджеры по доступности данных в валидиуме подтверждают доступность данных для транзакций вне сети, подписывая каждый пакет валидиума. Эти подписи представляют собой форму "доказательства доступности", которую ончейн-контракт верификатора проверяет перед утверждением обновлений состояния. + +Валидиумы различаются в своем подходе к управлению доступностью данных. Некоторые полагаются на доверенные стороны для хранения данных о состоянии, в то время как другие используют для этой задачи случайно назначенных валидаторов. + +#### Комитет по доступности данных (DAC) {#data-availability-committee} + +Чтобы гарантировать доступность данных вне сети, некоторые решения на базе валидиума назначают группу доверенных лиц, совместно именуемую комитетом по доступности данных (DAC), для хранения копий состояния и предоставления доказательства доступности данных. DAC легче реализовать, и они требуют меньшей координации, поскольку количество членов невелико. + +Однако пользователи должны доверять DAC в том, что он предоставит данные, когда это необходимо (например, для генерации доказательств Меркла). Существует возможность того, что члены комитетов по доступности данных [будут скомпрометированы злоумышленником](https://notes.ethereum.org/DD7GyItYQ02d0ax_X-UbWg?view), который затем сможет скрыть данные вне сети. + +[Подробнее о комитетах по доступности данных в валидиумах](https://medium.com/starkware/data-availability-e5564c416424). + +#### Обеспеченная залогом доступность данных {#bonded-data-availability} + +Другие валидиумы требуют, чтобы участники, ответственные за хранение данных вне сети, разместили в стейкинге (т. е. заблокировали) токены в смарт-контракте, прежде чем приступить к выполнению своих ролей. Эта ставка служит "залогом" для гарантии честного поведения среди менеджеров по доступности данных и снижает предположения о доверии. Если эти участники не смогут доказать доступность данных, их залог будет уменьшен (слешинг). + +В схеме обеспеченной залогом доступности данных любой может быть назначен для хранения данных вне сети, как только он предоставит требуемую ставку. Это расширяет пул подходящих менеджеров по доступности данных, снижая централизацию, которая характерна для комитетов по доступности данных (DAC). Что еще более важно, этот подход опирается на криптоэкономические стимулы для предотвращения злонамеренной деятельности, что значительно безопаснее, чем назначение доверенных сторон для защиты данных вне сети в валидиуме. + +[Подробнее об обеспеченной залогом доступности данных в валидиумах](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf). + +## Volitions и валидиум {#volitions-and-validium} + +Валидиумы предлагают много преимуществ, но сопряжены с компромиссами (в первую очередь, с доступностью данных). Но, как и многие решения для масштабирования, валидиумы подходят для конкретных вариантов использования — именно поэтому были созданы volitions. + +Volitions сочетают в себе ZK-роллап и цепь валидиума и позволяют пользователям переключаться между двумя решениями для масштабирования. С помощью volitions пользователи могут использовать доступность данных вне сети валидиума для определенных транзакций, сохраняя при этом свободу переключения на решение с доступностью данных в сети (ZK-роллап) при необходимости. По сути, это дает пользователям свободу выбора компромиссов в зависимости от их уникальных обстоятельств. + +Децентрализованная биржа (DEX) может предпочесть использование масштабируемой и частной инфраструктуры валидиума для сделок с высокой стоимостью. Она также может использовать ZK-роллап для пользователей, которым нужны более высокие гарантии безопасности и отсутствие необходимости в доверии, присущие ZK-роллапу. + +## Валидиумы и совместимость с EVM {#validiums-and-evm-compatibility} + +Как и ZK-роллапы, валидиумы в основном подходят для простых приложений, таких как обмен токенов и платежи. Поддержка общих вычислений и выполнения смарт-контрактов в валидиумах сложна в реализации, учитывая значительные накладные расходы на доказательство инструкций [EVM](/developers/docs/evm/) в схеме доказательства с нулевым разглашением. + +Некоторые проекты валидиумов пытаются обойти эту проблему, компилируя EVM-совместимые языки (например, Solidity, Vyper) для создания пользовательского байт-кода, оптимизированного для эффективного доказательства. Недостатком этого подхода является то, что новые, дружественные к доказательствам с нулевым разглашением, виртуальные машины могут не поддерживать важные опкоды EVM, и разработчикам приходится писать непосредственно на языке высокого уровня для оптимальной работы. Это создает еще больше проблем: заставляет разработчиков создавать децентрализованные приложения с совершенно новым стеком разработки и нарушает совместимость с существующей инфраструктурой Ethereum. + +Однако некоторые команды пытаются оптимизировать существующие опкоды EVM для схем ZK-доказательств. Это приведет к разработке виртуальной машины Ethereum с нулевым разглашением (zkEVM) — EVM-совместимой ВМ, которая производит доказательства для проверки правильности выполнения программы. С помощью zkEVM цепи валидиума могут выполнять смарт-контракты вне сети и представлять доказательства действительности для проверки вычислений вне сети (без необходимости их повторного выполнения) на Ethereum. + +[Подробнее о zkEVM](https://www.alchemy.com/overviews/zkevm). + +## Как валидиумы масштабируют Ethereum? {#scaling-ethereum-with-validiums} + +### 1. Хранение данных вне сети {#offchain-data-storage} + +Проекты масштабирования уровня 2, такие как оптимистические роллапы и ZK-роллапы, обменивают бесконечную масштабируемость чисто оффчейн-протоколов масштабирования (например, [Plasma](/developers/docs/scaling/plasma/)) на безопасность, публикуя некоторые данные о транзакциях на L1. Но это означает, что свойства масштабируемости роллапов ограничены пропускной способностью данных в основной сети Ethereum (по этой причине [шардинг данных](/roadmap/danksharding/) предлагает улучшить емкость хранения данных Ethereum). + +Валидиумы достигают масштабируемости, храня все данные транзакций вне сети и публикуя только обязательства по состоянию (и доказательства действительности) при передаче обновлений состояния в основную цепь Ethereum. Существование доказательств действительности, однако, дает валидиумам более высокие гарантии безопасности, чем другим чисто оффчейн-решениям для масштабирования, включая Plasma и [сайдчейны](/developers/docs/scaling/sidechains/). Уменьшая объем данных, которые Ethereum должен обработать перед проверкой транзакций вне сети, конструкции валидиума значительно увеличивают пропускную способность в основной сети. + +### 2. Рекурсивные доказательства {#recursive-proofs} + +Рекурсивное доказательство — это доказательство действительности, которое проверяет действительность других доказательств. Эти "доказательства доказательств" генерируются путем рекурсивного объединения нескольких доказательств до тех пор, пока не будет создано одно окончательное доказательство, проверяющее все предыдущие доказательства. Рекурсивные доказательства масштабируют скорость обработки блокчейна за счет увеличения количества транзакций, которые могут быть проверены одним доказательством действительности. + +Как правило, каждое доказательство действительности, которое оператор валидиума представляет в Ethereum для проверки, подтверждает целостность одного блока. В то время как одно рекурсивное доказательство может быть использовано для подтверждения действительности нескольких блоков валидиума одновременно — это возможно, поскольку схема доказательства может рекурсивно объединять несколько доказательств блоков в одно окончательное доказательство. Если ончейн-контракт верификатора принимает рекурсивное доказательство, все базовые блоки немедленно финализируются. + +## Плюсы и минусы валидиума {#pros-and-cons-of-validium} + +| Преимущества | Недостатки | +| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Доказательства действительности обеспечивают целостность транзакций вне сети и не позволяют операторам финализировать недействительные обновления состояния. | Создание доказательств действительности требует специального оборудования, что создает риск централизации. | +| Повышает эффективность капитала для пользователей (нет задержек при выводе средств обратно в Ethereum) | Ограниченная поддержка общих вычислений и смарт-контрактов; для разработки требуются специализированные языки. | +| Неуязвимы для определенных экономических атак, с которыми сталкиваются защищенные от мошенничества системы в важных приложениях. | Высокая вычислительная мощность, необходимая для генерации ZK-доказательств; нерентабельно для приложений с низкой пропускной способностью. | +| Снижает плату за газ для пользователей за счет отказа от публикации calldata в основной сети Ethereum. | Более медленное субъективное время финализации (10-30 минут на создание ZK-доказательства), но более быстрое до полной финализации, поскольку нет задержки на время спора. | +| Подходит для конкретных вариантов использования, таких как торговля или блокчейн-игры, где важны конфиденциальность транзакций и масштабируемость. | Пользователям может быть запрещено выводить средства, поскольку для создания доказательств Меркла о праве собственности требуется, чтобы данные вне сети были доступны в любое время. | +| Доступность данных вне сети обеспечивает более высокий уровень пропускной способности и повышает масштабируемость. | Модель безопасности основана на предположениях о доверии и криптоэкономических стимулах, в отличие от ZK-роллапов, которые полностью полагаются на криптографические механизмы безопасности. | + +### Используйте Validium/Volitions {#use-validium-and-volitions} + +Несколько проектов предоставляют реализации Validium и volitions, которые вы можете интегрировать в свои децентрализованные приложения: + +**StarkWare StarkEx** — _StarkEx — это решение для масштабирования Ethereum уровня 2 (L2), основанное на доказательствах действительности. Он может работать в режимах доступности данных ZK-Rollup или Validium._ + +- [Документация](https://docs.starkware.co/starkex-v4/starkex-deep-dive/data-availability-modes#validium) +- [Веб-сайт](https://starkware.co/starkex/) + +**Matter Labs zkPorter** — _zkPorter — это протокол масштабирования уровня 2, решающий проблему доступности данных с помощью гибридного подхода, который сочетает в себе идеи zkRollup и шардинга. Он может поддерживать произвольное количество шардов, каждый со своей собственной политикой доступности данных._ + +- [Блог](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf) +- [Документация](https://docs.zksync.io/zksync-protocol/rollup/data-availability) +- [Веб-сайт](https://zksync.io/) + +## Дополнительные материалы {#further-reading} + +- [Валидиум и матрица 2х2 для уровня 2 — выпуск № 99](https://www.buildblockchain.tech/newsletter/issues/no-99-validium-and-the-layer-2-two-by-two) +- [ZK-роллапы в сравнении с Validium](https://blog.matter-labs.io/zkrollup-vs-validium-starkex-5614e38bc263) +- [Volition и возникающий спектр доступности данных](https://medium.com/starkware/volition-and-the-emerging-data-availability-spectrum-87e8bfa09bb) +- [Роллапы, валидиумы и volitions: узнайте о самых популярных решениях для масштабирования Ethereum](https://www.defipulse.com/blog/rollups-validiums-and-volitions-learn-about-the-hottest-ethereum-scaling-solutions) +- [Практическое руководство по ролл-апам Ethereum](https://web.archive.org/web/20241108192208/https://research.2077.xyz/the-practical-guide-to-ethereum-rollups) diff --git a/public/content/translations/ru/developers/docs/scaling/zk-rollups/index.md b/public/content/translations/ru/developers/docs/scaling/zk-rollups/index.md new file mode 100644 index 00000000000..13cd3717b47 --- /dev/null +++ b/public/content/translations/ru/developers/docs/scaling/zk-rollups/index.md @@ -0,0 +1,257 @@ +--- +title: "Роллапы с нулевым разглашением" +description: "Введение в zero-knowledge rollups — решение для масштабирования, используемое сообществом Ethereum." +lang: ru +--- + +Ролл-апы с нулевым разглашением (ZK-rollups) — это решения для [масштабирования](/developers/docs/scaling/) второго уровня, которые увеличивают пропускную способность основной сети Ethereum за счет переноса вычислений и хранения состояния вне сети. ZK-Rollups могут обрабатывать тысячи транзакций в пакете, а затем публиковать только минимальные сводные данные в основной сети. Эти сводные данные определяют изменения, которые необходимо внести в состояние Ethereum, и некоторые криптографические доказательства правильности этих изменений. + +## Предварительные условия {#prerequisites} + +Вам следует прочитать и понять нашу страницу о [масштабировании Ethereum](/developers/docs/scaling/) и [уровне 2](/layer-2). + +## Что такое zero-knowledge rollups? {#what-are-zk-rollups} + +**Ролл-апы с нулевым разглашением (ZK-rollups)** объединяют (или «сворачивают») транзакции в пакеты, которые выполняются вне сети. Вычисления вне сети уменьшают объем данных, которые необходимо публиковать в блокчейне. Операторы ZK-ролл-апов отправляют сводку изменений, необходимых для представления всех транзакций в пакете, вместо того чтобы отправлять каждую транзакцию по отдельности. Они также создают [доказательства валидности](/glossary/#validity-proof), чтобы доказать правильность своих изменений. + +Состояние ZK-ролл-апа поддерживается смарт-контрактом, развернутым в сети Ethereum. Для обновления этого состояния узлы ZK-ролл-апа должны предоставить доказательство валидности для проверки. Как уже упоминалось, доказательство валидности является криптографической гарантией того, что предложенное ролл-апом изменение состояния действительно является результатом выполнения данного пакета транзакций. Это означает, что ZK-ролл-апам нужно предоставлять только доказательства валидности для финализации транзакций в Ethereum, вместо того чтобы публиковать все данные транзакций в сети, как это делают [оптимистические ролл-апы](/developers/docs/scaling/optimistic-rollups/). + +При переводе средств из ZK-ролл-апа в Ethereum нет задержек, поскольку транзакции выхода выполняются сразу после того, как контракт ZK-ролл-апа проверяет доказательство валидности. И наоборот, вывод средств из оптимистических ролл-апов происходит с задержкой, чтобы у любого была возможность оспорить транзакцию выхода с помощью [доказательства мошенничества](/glossary/#fraud-proof). + +ZK-ролл-апы записывают транзакции в Ethereum как `calldata`. `calldata` — это место, где хранятся данные, включенные во внешние вызовы функций смарт-контракта. Информация в `calldata` публикуется в блокчейне, что позволяет любому самостоятельно восстановить состояние ролл-апа. ZK-ролл-апы используют методы сжатия для уменьшения данных транзакций — например, аккаунты представляются индексом, а не адресом, что экономит 28 байт данных. Публикация данных в сети — это значительная статья расходов для ролл-апов, поэтому сжатие данных может снизить комиссии для пользователей. + +## Как ZK-ролл-апы взаимодействуют с Ethereum? {#zk-rollups-and-ethereum} + +Сеть ZK-ролл-апа — это протокол вне сети, который работает поверх блокчейна Ethereum и управляется смарт-контрактами Ethereum в основной сети. ZK-ролл-апы выполняют транзакции за пределами основной сети, но периодически фиксируют пакеты транзакций вне сети в контракте ролл-апа в основной сети. Эта запись транзакций неизменна, как и блокчейн Ethereum, и формирует сеть ZK-ролл-апа. + +Основная архитектура ZK-ролл-апа состоит из следующих компонентов: + +1. **Контракты в сети**. Как уже упоминалось, протокол ZK-ролл-апа контролируется смарт-контрактами, работающими в Ethereum. К ним относится основной контракт, который хранит блоки ролл-апа, отслеживает депозиты и наблюдает за обновлениями состояния. Другой контракт в сети (контракт-верификатор) проверяет доказательства с нулевым разглашением, представленные производителями блоков. Таким образом, Ethereum служит базовым уровнем или «уровнем 1» для ZK-ролл-апа. + +2. **Виртуальная машина вне сети (VM)**. Хотя протокол ZK-ролл-апа существует в Ethereum, выполнение транзакций и хранение состояния происходят на отдельной виртуальной машине, независимой от [EVM](/developers/docs/evm/). Эта VM вне сети является средой выполнения транзакций в ZK-ролл-апе и служит вторичным уровнем или «уровнем 2» для протокола ZK-ролл-апа. Доказательства валидности, проверяемые в основной сети Ethereum, гарантируют правильность переходов состояний в VM вне сети. + +ZK-ролл-апы — это «гибридные решения для масштабирования» — протоколы вне сети, которые работают независимо, но получают безопасность от Ethereum. В частности, сеть Ethereum обеспечивает валидность обновлений состояния в ZK-ролл-апе и гарантирует доступность данных, лежащих в основе каждого обновления состояния ролл-апа. В результате ZK-ролл-апы значительно безопаснее, чем чисто офф-чейн решения для масштабирования, такие как [сайдчейны](/developers/docs/scaling/sidechains/), которые сами отвечают за свои свойства безопасности, или [валидиумы](/developers/docs/scaling/validium/), которые также проверяют транзакции на Ethereum с помощью доказательств валидности, но хранят данные транзакций в другом месте. + +ZK-ролл-апы полагаются на основной протокол Ethereum в следующих аспектах: + +### Доступность данных {#data-availability} + +ZK-ролл-апы публикуют данные о состоянии для каждой транзакции, обработанной вне сети, в Ethereum. С помощью этих данных частные лица или компании могут воспроизвести состояние ролл-апа и самостоятельно валидировать его сеть. Ethereum делает эти данные доступными для всех участников сети в виде `calldata`. + +ZK-ролл-апам не нужно публиковать много данных о транзакциях в сети, потому что доказательства валидности уже подтверждают подлинность переходов состояния. Тем не менее хранение данных в сети по-прежнему важно, поскольку это позволяет без разрешений и независимо проверять состояние сети Уровня 2, что, в свою очередь, позволяет любому отправлять пакеты транзакций, предотвращая цензуру или замораживание сети злонамеренными операторами. + +Взаимодействие в сети необходимо пользователям для работы с ролл-апом. Без доступа к данным о состоянии пользователи не могут запрашивать баланс своего аккаунта или инициировать транзакции (например, вывод средств), которые зависят от информации о состоянии. + +### Финальность транзакций {#transaction-finality} + +Ethereum выступает в качестве уровня расчетов для ZK-ролл-апов: транзакции Уровня 2 финализируются только в том случае, если контракт Уровня 1 принимает доказательство валидности. Это устраняет риск того, что злонамеренные операторы повредят сеть (например, украдут средства ролл-апа), поскольку каждая транзакция должна быть одобрена в основной сети. Кроме того, Ethereum гарантирует, что операции пользователя не могут быть отменены после их финализации на Уровне 1. + +### Устойчивость к цензуре {#censorship-resistance} + +Большинство ZK-ролл-апов используют «суперузел» (оператора) для выполнения транзакций, создания пакетов и отправки блоков на Уровень 1. Хотя это обеспечивает эффективность, это увеличивает риск цензуры: злонамеренные операторы ZK-ролл-апов могут подвергать цензуре пользователей, отказываясь включать их транзакции в пакеты. + +В качестве меры безопасности ZK-ролл-апы позволяют пользователям отправлять транзакции непосредственно в контракт ролл-апа в основной сети, если они считают, что оператор их цензурирует. Это позволяет пользователям принудительно выйти из ZK-ролл-апа в Ethereum, не полагаясь на разрешение оператора. + +## Как работают ZK-ролл-апы? {#how-do-zk-rollups-work} + +### Транзакции {#transactions} + +Пользователи в ZK-ролл-апе подписывают транзакции и отправляют их операторам Уровня 2 для обработки и включения в следующий пакет. В некоторых случаях оператор является централизованной сущностью, называемой секвенсором, который выполняет транзакции, объединяет их в пакеты и отправляет на Уровень 1. Секвенсор в этой системе — единственная сущность, которой разрешено создавать блоки Уровня 2 и добавлять транзакции ролл-апа в контракт ZK-ролл-апа. + +Другие ZK-ролл-апы могут ротировать роль оператора, используя набор валидаторов [доказательства владения](/developers/docs/consensus-mechanisms/pos/). Потенциальные операторы вносят средства в контракт ролл-апа, при этом размер каждой доли влияет на шансы стейкера быть выбранным для создания следующего пакета ролл-апа. Доля оператора может быть подвергнута слэшингу, если он действует злонамеренно, что стимулирует их публиковать валидные блоки. + +#### Как ZK-ролл-апы публикуют данные транзакций в Ethereum {#how-zk-rollups-publish-transaction-data-on-ethereum} + +Как объяснялось ранее, данные транзакций публикуются в Ethereum как `calldata`. `calldata` — это область данных в смарт-контракте, используемая для передачи аргументов в функцию, которая ведет себя аналогично [памяти](/developers/docs/smart-contracts/anatomy/#memory). `calldata` не хранится как часть состояния Ethereum, но она сохраняется в сети как часть [журналов истории](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html?highlight=memory#logs) сети Ethereum. `calldata` не влияет на состояние Ethereum, что делает ее дешевым способом хранения данных в сети. + +Ключевое слово `calldata` часто идентифицирует метод смарт-контракта, вызываемый транзакцией, и содержит входные данные для метода в виде произвольной последовательности байтов. ZK-ролл-апы используют `calldata` для публикации сжатых данных транзакций в сети; оператор ролл-апа просто добавляет новый пакет, вызывая необходимую функцию в контракте ролл-апа и передавая сжатые данные в качестве аргументов функции. Это помогает снизить затраты для пользователей, так как большая часть комиссий ролл-апа идет на хранение данных транзакций в сети. + +### Обязательства по состоянию {#state-commitments} + +Состояние ZK-ролл-апа, которое включает аккаунты и балансы Уровня 2, представлено в виде [дерева Меркла](/whitepaper/#merkle-trees). Криптографический хэш корня дерева Меркла (корень Меркла) хранится в контракте в сети, что позволяет протоколу ролл-апа отслеживать изменения в состоянии ZK-ролл-апа. + +Ролл-ап переходит в новое состояние после выполнения нового набора транзакций. Оператор, инициировавший переход состояния, обязан вычислить новый корень состояния и отправить его в контракт в сети. Если доказательство валидности, связанное с пакетом, аутентифицировано контрактом-верификатором, новый корень Меркла становится каноническим корнем состояния ZK-ролл-апа. + +Помимо вычисления корней состояния, оператор ZK-ролл-апа также создает корень пакета — корень дерева Меркла, включающего все транзакции в пакете. Когда отправляется новый пакет, контракт ролл-апа сохраняет корень пакета, что позволяет пользователям доказать, что транзакция (например, запрос на вывод средств) была включена в пакет. Пользователям необходимо будет предоставить детали транзакции, корень пакета и [доказательство Меркла](/developers/tutorials/merkle-proofs-for-offline-data-integrity/), показывающее путь включения. + +### Доказательства валидности {#validity-proofs} + +Новый корень состояния, который оператор ZK-ролл-апа отправляет в контракт Уровня 1, является результатом обновлений состояния ролл-апа. Допустим, Алиса отправляет 10 токенов Бобу, оператор просто уменьшает баланс Алисы на 10 и увеличивает баланс Боба на 10. Затем оператор хэширует обновленные данные аккаунта, перестраивает дерево Меркла ролл-апа и отправляет новый корень Меркла в контракт в сети. + +Но контракт ролл-апа не примет автоматически предложенное обязательство по состоянию, пока оператор не докажет, что новый корень Меркла является результатом правильных обновлений состояния ролл-апа. Оператор ZK-ролл-апа делает это, создавая доказательство валидности — краткое криптографическое обязательство, подтверждающее правильность пакетных транзакций. + +Доказательства валидности позволяют сторонам доказывать правильность утверждения, не раскрывая само утверждение, — отсюда и их второе название «доказательства с нулевым разглашением». ZK-ролл-апы используют доказательства валидности для подтверждения правильности переходов состояния вне сети без необходимости повторного выполнения транзакций в Ethereum. Эти доказательства могут быть в форме [ZK-SNARK](https://arxiv.org/abs/2202.06877) (краткий неинтерактивный аргумент знания с нулевым разглашением) или [ZK-STARK](https://eprint.iacr.org/2018/046) (масштабируемый прозрачный аргумент знания с нулевым разглашением). + +И SNARK, и STARK помогают подтвердить целостность вычислений вне сети в ZK-ролл-апах, хотя каждый тип доказательства имеет свои отличительные особенности. + +**ZK-SNARKs** + +Для работы протокола ZK-SNARK необходимо создать общую эталонную строку (CRS): CRS предоставляет публичные параметры для доказывания и проверки доказательств валидности. Безопасность системы доказывания зависит от настройки CRS; если информация, используемая для создания публичных параметров, попадет в руки злоумышленников, они смогут генерировать ложные доказательства валидности. + +Некоторые ZK-ролл-апы пытаются решить эту проблему, используя [церемонию многосторонних вычислений (MPC)](https://zkproof.org/2021/06/30/setup-ceremonies/amp/) с участием доверенных лиц для генерации публичных параметров для схемы ZK-SNARK. Каждая сторона вносит некоторую случайность (называемую «токсичными отходами») для создания CRS, которую они должны немедленно уничтожить. + +Доверенные настройки используются, потому что они повышают безопасность настройки CRS. Пока хотя бы один честный участник уничтожает свои входные данные, безопасность системы ZK-SNARK гарантирована. Тем не менее, этот подход требует доверия к участникам в том, что они удалят свою выборку случайности и не подорвут гарантии безопасности системы. + +Несмотря на допущения о доверии, ZK-SNARKs популярны благодаря своим малым размерам доказательств и проверке за постоянное время. Поскольку проверка доказательств на Уровне 1 составляет большую часть затрат на эксплуатацию ZK-ролл-апа, Уровни 2 используют ZK-SNARKs для генерации доказательств, которые можно быстро и дешево проверить в основной сети. + +**ZK-STARKs** + +Как и ZK-SNARK, ZK-STARK доказывают валидность вычислений вне сети, не раскрывая входных данных. Однако ZK-STARK считаются усовершенствованием ZK-SNARK из-за их масштабируемости и прозрачности. + +ZK-STARK являются «прозрачными», поскольку они могут работать без доверенной настройки общей эталонной строки (CRS). Вместо этого ZK-STARK полагаются на публично проверяемую случайность для настройки параметров генерации и проверки доказательств. + +ZK-STARK также обеспечивают большую масштабируемость, поскольку время, необходимое для доказывания и проверки доказательств валидности, увеличивается _квазилинейно_ по отношению к сложности базового вычисления. В случае ZK-SNARK время доказывания и проверки масштабируется _линейно_ по отношению к размеру базового вычисления. Это означает, что ZK-STARK требуют меньше времени, чем ZK-SNARK, для доказывания и проверки при работе с большими наборами данных, что делает их полезными для приложений с большим объемом операций. + +ZK-STARK также устойчивы к атакам квантовых компьютеров, в то время как криптография на эллиптических кривых (ECC), используемая в ZK-SNARK, как широко считается, уязвима для атак квантовых компьютеров. Недостатком ZK-STARK является то, что они создают доказательства большего размера, проверка которых в Ethereum обходится дороже. + +#### Как работают доказательства валидности в ZK-ролл-апах? {#validity-proofs-in-zk-rollups} + +##### Генерация доказательства + +Прежде чем принять транзакции, оператор выполнит обычные проверки. Это включает в себя подтверждение того, что: + +- Аккаунты отправителя и получателя являются частью дерева состояний. +- У отправителя достаточно средств для обработки транзакции. +- Транзакция корректна и соответствует публичному ключу отправителя в ролл-апе. +- Нонс отправителя корректен и т. д. + +Как только узел ZK-ролл-апа набирает достаточное количество транзакций, он объединяет их в пакет и компилирует входные данные для схемы доказывания, чтобы скомпилировать их в краткое ZK-доказательство. Это включает: + +- Корень дерева Меркла, включающий все транзакции в пакете. +- Доказательства Меркла для транзакций, чтобы доказать их включение в пакет. +- Доказательства Меркла для каждой пары отправитель-получатель в транзакциях, чтобы доказать, что эти аккаунты являются частью дерева состояний ролл-апа. +- Набор промежуточных корней состояния, полученных путем обновления корня состояния после применения обновлений состояния для каждой транзакции (т. е. уменьшение балансов аккаунтов отправителей и увеличение балансов аккаунтов получателей). + +Схема доказывания вычисляет доказательство валидности, «проходя» по каждой транзакции и выполняя те же проверки, которые оператор завершил перед обработкой транзакции. Во-первых, она проверяет, является ли аккаунт отправителя частью существующего корня состояния, используя предоставленное доказательство Меркла. Затем она уменьшает баланс отправителя, увеличивает его нонс, хэширует обновленные данные аккаунта и объединяет их с доказательством Меркла для генерации нового корня Меркла. + +Этот корень Меркла отражает единственное изменение в состоянии ZK-ролл-апа: изменение баланса и нонса отправителя. Это возможно, потому что доказательство Меркла, используемое для подтверждения существования аккаунта, используется для получения нового корня состояния. + +Схема доказывания выполняет тот же процесс для аккаунта получателя. Она проверяет, существует ли аккаунт получателя под промежуточным корнем состояния (используя доказательство Меркла), увеличивает его баланс, повторно хэширует данные аккаунта и объединяет их с доказательством Меркла для генерации нового корня состояния. + +Процесс повторяется для каждой транзакции; каждый «цикл» создает новый корень состояния из обновления аккаунта отправителя и последующий новый корень из обновления аккаунта получателя. Как объяснялось, каждое обновление корня состояния представляет собой изменение одной части дерева состояний ролл-апа. + +Схема ZK-доказывания итерирует по всему пакету транзакций, проверяя последовательность обновлений, которые приводят к конечному корню состояния после выполнения последней транзакции. Последний вычисленный корень Меркла становится новейшим каноническим корнем состояния ZK-ролл-апа. + +##### Проверка доказательства + +После того как схема доказывания проверит правильность обновлений состояния, оператор Уровня 2 отправляет вычисленное доказательство валидности в контракт-верификатор на Уровне 1. Схема верификации контракта проверяет валидность доказательства, а также проверяет публичные входные данные, которые являются частью доказательства: + +- **Корень предыдущего состояния**: старый корень состояния ZK-ролл-апа (т. е. до выполнения пакетных транзакций), отражающий последнее известное валидное состояние сети Уровня 2. + +- **Корень последующего состояния**: новый корень состояния ZK-ролл-апа (т. е. после выполнения пакетных транзакций), отражающий новейшее состояние сети Уровня 2. Корень последующего состояния — это конечный корень, полученный после применения обновлений состояния в схеме доказывания. + +- **Корень пакета**: корень Меркла пакета, полученный путем _мерклизации_ транзакций в пакете и хэширования корня дерева. + +- **Входные данные транзакций**: данные, связанные с транзакциями, выполненными в рамках отправленного пакета. + +Если доказательство удовлетворяет схеме (т. е. является валидным), это означает, что существует последовательность валидных транзакций, которые переводят ролл-ап из предыдущего состояния (криптографически отмеченного корнем предыдущего состояния) в новое состояние (криптографически отмеченное корнем последующего состояния). Если корень предыдущего состояния совпадает с корнем, хранящимся в контракте ролл-апа, и доказательство валидно, контракт ролл-апа берет корень последующего состояния из доказательства и обновляет свое дерево состояний, чтобы отразить измененное состояние ролл-апа. + +### Входы и выходы {#entries-and-exits} + +Пользователи входят в ZK-ролл-ап, внося токены в контракт ролл-апа, развернутый в сети Уровня 1. Эта транзакция ставится в очередь, так как только операторы могут отправлять транзакции в контракт ролл-апа. + +Если очередь ожидающих депозитов начинает заполняться, оператор ZK-ролл-апа возьмет транзакции депозитов и отправит их в контракт ролл-апа. Как только средства пользователя оказываются в ролл-апе, они могут начать совершать транзакции, отправляя их оператору на обработку. Пользователи могут проверять балансы в ролл-апе, хэшируя данные своего аккаунта, отправляя хэш в контракт ролл-апа и предоставляя доказательство Меркла для проверки относительно текущего корня состояния. + +Вывод средств из ZK-ролл-апа на Уровень 1 прост. Пользователь инициирует транзакцию выхода, отправляя свои активы в ролл-апе на указанный аккаунт для сжигания. Если оператор включит транзакцию в следующий пакет, пользователь может отправить запрос на вывод средств в контракт в сети. Этот запрос на вывод средств будет включать следующее: + +- Доказательство Меркла, подтверждающее включение транзакции пользователя на аккаунт сжигания в пакет транзакций + +- Данные транзакции + +- Корень пакета + +- Адрес Уровня 1 для получения депонированных средств + +Контракт ролл-апа хэширует данные транзакции, проверяет существование корня пакета и использует доказательство Меркла, чтобы проверить, является ли хэш транзакции частью корня пакета. После этого контракт выполняет транзакцию выхода и отправляет средства на выбранный пользователем адрес на Уровне 1. + +## ZK-ролл-апы и совместимость с EVM {#zk-rollups-and-evm-compatibility} + +В отличие от оптимистических ролл-апов, ZK-ролл-апы не являются легко совместимыми с [виртуальной машиной Ethereum (EVM)](/developers/docs/evm/). Доказывание вычислений EVM общего назначения в схемах сложнее и более ресурсоемко, чем доказывание простых вычислений (например, перевод токенов, описанный ранее). + +Однако [достижения в технологии с нулевым разглашением](https://hackmd.io/@yezhang/S1_KMMbGt#Why-possible-now) вызывают возобновленный интерес к обертыванию вычислений EVM в доказательства с нулевым разглашением. Эти усилия направлены на создание реализации EVM с нулевым разглашением (zkEVM), которая может эффективно проверять правильность выполнения программы. zkEVM воссоздает существующие опкоды EVM для доказывания/проверки в схемах, что позволяет выполнять смарт-контракты. + +Как и EVM, zkEVM переходит между состояниями после выполнения вычислений над некоторыми входными данными. Разница в том, что zkEVM также создает доказательства с нулевым разглашением для проверки правильности каждого шага выполнения программы. Доказательства валидности могут проверять правильность операций, затрагивающих состояние ВМ (память, стек, хранилище), и само вычисление (т. е. вызвала ли операция правильные опкоды и выполнила ли их корректно?). + +Ожидается, что внедрение ZK-ролл-апов, совместимых с EVM, поможет разработчикам использовать масштабируемость и гарантии безопасности доказательств с нулевым разглашением. Что еще более важно, совместимость с нативной инфраструктурой Ethereum означает, что разработчики могут создавать дружественные к ZK децентрализованные приложения, используя знакомые (и проверенные в боях) инструменты и языки. + +## Как работают комиссии ZK-ролл-апов? {#how-do-zk-rollup-fees-work} + +Сколько пользователи платят за транзакции в ZK-ролл-апах, зависит от комиссии за газ, так же как и в основной сети Ethereum. Однако комиссии за газ на Уровне 2 работают по-другому и зависят от следующих затрат: + +1. **Запись состояния**: существует фиксированная стоимость записи в состояние Ethereum (т. е. отправки транзакции в блокчейн Ethereum). ZK-ролл-апы снижают эту стоимость, объединяя транзакции в пакеты и распределяя фиксированные затраты между несколькими пользователями. + +2. **Публикация данных**: ZK-ролл-апы публикуют данные о состоянии для каждой транзакции в Ethereum в виде `calldata`. Стоимость `calldata` в настоящее время регулируется [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559), который устанавливает стоимость в 16 единиц газа за ненулевые байты и 4 единицы газа за нулевые байты `calldata` соответственно. Стоимость, уплачиваемая за каждую транзакцию, зависит от того, сколько `calldata` для нее необходимо опубликовать в сети. + +3. **Комиссии оператора Уровня 2**: это сумма, выплачиваемая оператору ролл-апа в качестве компенсации за вычислительные затраты, понесенные при обработке транзакций, подобно [«приоритетным комиссиям (чаевым)» за транзакции](/developers/docs/gas/#how-are-gas-fees-calculated) в основной сети Ethereum. + +4. **Генерация и проверка доказательств**: операторы ZK-ролл-апов должны создавать доказательства валидности для пакетов транзакций, что является ресурсоемким процессом. Проверка доказательств с нулевым разглашением в основной сети также требует газа (~ 500 000 единиц газа). + +Помимо объединения транзакций в пакеты, ZK-ролл-апы снижают комиссии для пользователей за счет сжатия данных транзакций. Вы можете [увидеть обзор в реальном времени](https://l2fees.info/), сколько стоит использование ZK-ролл-апов Ethereum. + +## Как ZK-ролл-апы масштабируют Ethereum? {#scaling-ethereum-with-zk-rollups} + +### Сжатие данных транзакций {#transaction-data-compression} + +ZK-ролл-апы увеличивают пропускную способность базового уровня Ethereum, вынося вычисления за пределы сети, но настоящий прирост в масштабировании достигается за счет сжатия данных транзакций. [Размер блока](/developers/docs/blocks/#block-size) Ethereum ограничивает объем данных, который может содержать каждый блок, и, следовательно, количество транзакций, обрабатываемых в каждом блоке. Сжимая данные, связанные с транзакциями, ZK-ролл-апы значительно увеличивают количество транзакций, обрабатываемых в каждом блоке. + +ZK-ролл-апы могут сжимать данные транзакций лучше, чем оптимистические ролл-апы, поскольку им не нужно публиковать все данные, необходимые для валидации каждой транзакции. Им нужно публиковать только минимальные данные, необходимые для восстановления последнего состояния аккаунтов и балансов в ролл-апе. + +### Рекурсивные доказательства {#recursive-proofs} + +Преимущество доказательств с нулевым разглашением заключается в том, что доказательства могут проверять другие доказательства. Например, один ZK-SNARK может проверять другие ZK-SNARK. Такие «доказательства доказательств» называются рекурсивными доказательствами и значительно увеличивают пропускную способность ZK-ролл-апов. + +В настоящее время доказательства валидности генерируются для каждого блока и отправляются в контракт Уровня 1 для проверки. Однако проверка доказательств для одного блока ограничивает пропускную способность, которую могут достичь ZK-ролл-апы, поскольку только один блок может быть финализирован, когда оператор отправляет доказательство. + +Рекурсивные доказательства, однако, позволяют финализировать несколько блоков с одним доказательством валидности. Это происходит потому, что схема доказывания рекурсивно агрегирует доказательства нескольких блоков до тех пор, пока не будет создано одно окончательное доказательство. Оператор Уровня 2 отправляет это рекурсивное доказательство, и если контракт его принимает, все соответствующие блоки будут финализированы мгновенно. С рекурсивными доказательствами количество транзакций ZK-ролл-апов, которые могут быть финализированы в Ethereum за определенные интервалы, увеличивается. + +### Плюсы и минусы ZK-ролл-апов {#zk-rollups-pros-and-cons} + +| Преимущества | Недостатки | +| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Доказательства валидности обеспечивают правильность транзакций вне сети и предотвращают выполнение операторами невалидных переходов состояния. | Затраты, связанные с вычислением и проверкой доказательств валидности, значительны и могут увеличить комиссии для пользователей ролл-апа. | +| Обеспечивает более быструю финализацию транзакций, поскольку обновления состояния одобряются после проверки доказательств валидности на Уровне 1. | Создание ZK-ролл-апов, совместимых с EVM, затруднено из-за сложности технологии с нулевым разглашением. | +| Полагается на бездоверительные криптографические механизмы для обеспечения безопасности, а не на честность стимулируемых участников, как в случае с [оптимистическими ролл-апами](/developers/docs/scaling/optimistic-rollups/#optimistic-pros-and-cons). | Создание доказательств валидности требует специализированного оборудования, что может способствовать централизованному контролю над сетью со стороны нескольких сторон. | +| Хранит данные, необходимые для восстановления состояния вне сети, на Уровне 1, что гарантирует безопасность, устойчивость к цензуре и децентрализацию. | Централизованные операторы (секвенсоры) могут влиять на порядок транзакций. | +| Пользователи выигрывают от большей эффективности капитала и могут выводить средства с Уровня 2 без задержек. | Требования к оборудованию могут сократить число участников, способных заставить сеть развиваться, что увеличивает риск заморозки состояния ролл-апа и цензуры пользователей злонамеренными операторами. | +| Не зависит от предположений о живучести, и пользователям не нужно валидировать сеть для защиты своих средств. | Некоторые системы доказывания (например, ZK-SNARK) требуют доверенной настройки, которая, в случае неправильного обращения, может потенциально скомпрометировать модель безопасности ZK-ролл-апа. | +| Лучшее сжатие данных может помочь снизить затраты на публикацию `calldata` в Ethereum и минимизировать комиссии ролл-апа для пользователей. | | + +### Визуальное объяснение ZK-ролл-апов {#zk-video} + +Посмотрите объяснение ZK-ролл-апов от Finematics: + + + +## Кто работает над zkEVM? {#zkevm-projects} + +Проекты, работающие над zkEVM, включают: + +- **[zkEVM](https://github.com/privacy-scaling-explorations/zkevm-specs)** — _zkEVM — это проект, финансируемый Ethereum Foundation, для разработки ZK-ролл-апа, совместимого с EVM, и механизма для генерации доказательств валидности для блоков Ethereum._ + +- **[Polygon zkEVM](https://polygon.technology/solutions/polygon-zkevm)** — _это децентрализованный ZK-ролл-ап в основной сети Ethereum, работающий над виртуальной машиной Ethereum с нулевым разглашением (zkEVM), которая прозрачно выполняет транзакции Ethereum, включая смарт-контракты с валидацией через доказательства с нулевым разглашением._ + +- **[Scroll](https://scroll.io/blog/zkEVM)** — _Scroll — это технологическая компания, работающая над созданием нативного решения Уровня 2 zkEVM для Ethereum._ + +- **[Taiko](https://taiko.xyz)** — _Taiko — это децентрализованный, эквивалентный Ethereum ZK-ролл-ап ([Тип 1 ZK-EVM](https://vitalik.eth.limo/general/2022/08/04/zkevm.html))._ + +- **[ZKsync](https://docs.zksync.io/)** — _ZKsync Era — это ZK-ролл-ап, совместимый с EVM, созданный Matter Labs и работающий на собственном zkEVM._ + +- **[Starknet](https://starkware.co/starknet/)** — _StarkNet — это решение для масштабирования второго уровня, совместимое с EVM, созданное StarkWare._ + +- **[Morph](https://www.morphl2.io/)** — _Morph — это гибридное решение для масштабирования ролл-апов, которое использует zk-доказательства для решения проблемы с состоянием на Уровне 2._ + +- **[Linea](https://linea.build)** — _Linea — это эквивалентный Ethereum zkEVM Уровня 2, созданный Consensys и полностью согласованный с экосистемой Ethereum._ + +## Дополнительные материалы для чтения о ZK-ролл-апах {#further-reading-on-zk-rollups} + +- [Что такое ролл-апы с нулевым разглашением?](https://coinmarketcap.com/alexandria/glossary/zero-knowledge-rollups) +- [Что такое ролл-апы с нулевым разглашением?](https://alchemy.com/blog/zero-knowledge-rollups) +- [Практическое руководство по ролл-апам Ethereum](https://web.archive.org/web/20241108192208/https://research.2077.xyz/the-practical-guide-to-ethereum-rollups) +- [STARKs против SNARKs](https://consensys.net/blog/blockchain-explained/zero-knowledge-proofs-starks-vs-snarks/) +- [Что такое zkEVM?](https://www.alchemy.com/overviews/zkevm) +- [Типы ZK-EVM: эквивалентные Ethereum, эквивалентные EVM, Тип 1, Тип 4 и другие загадочные модные словечки](https://taiko.mirror.xyz/j6KgY8zbGTlTnHRFGW6ZLVPuT0IV0_KmgowgStpA0K4) +- [Введение в zkEVM](https://hackmd.io/@yezhang/S1_KMMbGt) +- [Что такое ZK-EVM Уровня 2?](https://linea.mirror.xyz/qD18IaQ4BROn_Y40EBMTUTdJHYghUtdECscSWyMvm8M) +- [Потрясающие ресурсы по zkEVM](https://github.com/LuozhuZhang/awesome-zkevm) +- [ZK-SNARKS под капотом](https://vitalik.eth.limo/general/2017/02/01/zk_snarks.html) +- [Как возможны SNARKs?](https://vitalik.eth.limo/general/2021/01/26/snarks.html)