From 1c7ecee062333186e9d013015b2dd0342f8b0766 Mon Sep 17 00:00:00 2001 From: Joshua <62268199+minimalsm@users.noreply.github.com> Date: Sat, 14 Feb 2026 00:00:18 +0000 Subject: [PATCH] i18n(ru): translation import part 11 of 13 (23 files) --- .../translations/ru/roadmap/pbs/index.md | 29 +- .../ru/roadmap/pectra/7702/index.md | 149 ++++++++++ .../translations/ru/roadmap/pectra/index.md | 127 +++++++++ .../ru/roadmap/pectra/maxeb/index.md | 204 ++++++++++++++ .../translations/ru/roadmap/scaling/index.md | 26 +- .../roadmap/secret-leader-election/index.md | 16 +- .../translations/ru/roadmap/security/index.md | 28 +- .../ru/roadmap/single-slot-finality/index.md | 34 +-- .../ru/roadmap/statelessness/index.md | 68 ++--- .../ru/roadmap/user-experience/index.md | 20 +- .../ru/roadmap/verkle-trees/index.md | 44 ++- .../content/translations/ru/security/index.md | 123 ++++---- .../translations/ru/smart-contracts/index.md | 44 +-- .../translations/ru/social-networks/index.md | 112 +++++--- .../translations/ru/staking/dvt/index.md | 54 ++-- .../translations/ru/staking/pools/index.md | 38 +-- .../translations/ru/staking/saas/index.md | 38 +-- .../translations/ru/staking/solo/index.md | 150 +++++----- .../ru/staking/withdrawals/index.md | 105 ++++--- public/content/translations/ru/web3/index.md | 78 ++--- .../translations/ru/what-are-apps/index.md | 80 ++++++ .../translations/ru/whitepaper/index.md | 266 +++++++++--------- .../translations/ru/wrapped-eth/index.md | 66 +++++ 23 files changed, 1292 insertions(+), 607 deletions(-) create mode 100644 public/content/translations/ru/roadmap/pectra/7702/index.md create mode 100644 public/content/translations/ru/roadmap/pectra/index.md create mode 100644 public/content/translations/ru/roadmap/pectra/maxeb/index.md create mode 100644 public/content/translations/ru/what-are-apps/index.md create mode 100644 public/content/translations/ru/wrapped-eth/index.md diff --git a/public/content/translations/ru/roadmap/pbs/index.md b/public/content/translations/ru/roadmap/pbs/index.md index 628055b7bf2..2e303e32020 100644 --- a/public/content/translations/ru/roadmap/pbs/index.md +++ b/public/content/translations/ru/roadmap/pbs/index.md @@ -1,12 +1,12 @@ --- -title: Разделение предлагающих и строителей -description: Узнайте, как и почему обязанности валидаторов Ethereum по строительству и трансляции блоков будут разделены. +title: "Разделение предлагающих и строителей" +description: "Узнайте, как и почему обязанности валидаторов Ethereum по строительству и трансляции блоков будут разделены." lang: ru --- -# Разделение предлагающих и строителей {#proposer-builder-separation} +# Разделение предлагающих и сборщиков {#proposer-builder-separation} -Современные валидаторы Ethereum как создают, _так и_ транслируют блоки. Они соединяют транзакции, о которых узнали через сеть сплетен, и упаковывают их в блок, который отправляется одноранговым пользователям по сети Ethereum. **Разделение предлагающих и строителей (PBS)** разбивает эти задачи между несколькими валидаторами. Роль строителей заключается в создании блоков и предоставлении их предлагающему в каждом слоте. Предлагающий блоков не может видеть их содержимое, он просто выбирает наиболее выгодный из них, заплатив комиссию за строительство блока перед его отправкой коллегам. +Современные валидаторы Ethereum как создают, так и транслируют блоки. Они соединяют транзакции, о которых узнали через сеть сплетен, и упаковывают их в блок, который отправляется одноранговым пользователям по сети Ethereum. **Разделение предлагающих и сборщиков (PBS)** распределяет эти задачи между несколькими валидаторами. Роль строителей заключается в создании блоков и предоставлении их предлагающему в каждом слоте. Предлагающий блоков не может видеть их содержимое, он просто выбирает наиболее выгодный из них, заплатив комиссию за строительство блока перед его отправкой коллегам. Это важное обновление по ряду причин. Во-первых, оно создает возможности для предотвращения цензуры транзакций на уровне протокола. Во-вторых, оно не позволяет организованным игрокам, способным лучше оптимизировать доходность своего строительства блоков, выбивать с рынка валидаторов-любителей. В-третьих, оно помогает с масштабированием Ethereum, создавая возможность для обновлений данкшардинга. @@ -16,36 +16,35 @@ lang: ru Например, списки включения могут быть введены таким образом, чтобы, когда валидаторы знают о транзакциях, но не видят их включенными в блоки, они могли бы навязать их обязательное включение в следующий блок. Список включения формируется из местного мемпула предлагающих блоки (список транзакций, о которых ему известно) и отправляется их коллегам непосредственно перед предложением блока. Если какая-либо из транзакций из списка включения отсутствует, предлагающий может либо отклонить этот блок и добавить отсутствующие операции, прежде чем предлагать его, либо предложить его и позволить отклонить его другим валидаторам после получения. Существует также потенциально более эффективная версия этой идеи, которая предполагает, что строители должны полностью использовать доступное блочное пространство, а если они не делают этого, то транзакции добавляются из списка включения у предлагающего. Этот вопрос по-прежнему находится в фазе активного изучения, и оптимальная конфигурация списков включения еще не определена. -[Зашифрованные мемпулы](https://www.youtube.com/watch?v=fHDjgFcha0M&list=PLpktWkixc1gUqkyc1-iE6TT0RWQTBJELe&index=3) могут также сделать невозможным для строителей и предлагающих знать, какие транзакции они включают в блок, до тех пор, пока блок уже не будет транслирован. +[Зашифрованные мемпулы](https://www.youtube.com/watch?v=fHDjgFcha0M&list=PLpktWkixc1gUqkyc1-iE6TT0RWQTBJELe&index=3) также могут сделать невозможным для сборщиков и предлагающих узнать, какие транзакции они включают в блок, до тех пор, пока блок не будет транслирован. - + Влиятельные организации могут оказывать давление на валидаторов, чтобы цензурировать входящие и исходящие транзакции, связанные с определенными адресами. Валидаторы выявляют адреса из черного списка в своем пуле транзакций и исключают их из предлагаемых блоков. После PBS это будет невозможно, так как предлагающие блоки не будут знать, какие транзакции они транслируют в своих блоках. Может быть важно, чтобы определенные лица или приложения соблюдали правила цензуры (например, когда такие правила становится законом в их регионе). В таких случаях соблюдение правил происходит на уровне приложения, в то время как протокол остается лишенным разрешений и цензуры. - ## PBS и MEV {#pbs-and-mev} -**Максимальное извлекаемое значение (MEV)** относится к валидаторам которые максимизируют свою прибыльность за счет выгодного упорядочивания сделок. Типичными примерами являются арбитражные обмены на децентрализованных биржах (например, в случаях крупных сделок купли-продажи) и выявление возможностей для ликвидации позиций на рынке DeFi. Для максимизации MEV требуются современные технические ноу-хау и специализированное программное обеспечение, добавляемое к обычным валидаторам. Это значительно повышает вероятность того, что организованные операторы превзойдут отдельных лиц и любителей-валидаторов при извлечении MEV. Это означает, что выгодность стейкинга, вероятно, будут выше у централизованных операторов, что создаст централизирующую силу, которая лишает стимула заниматься домашним стейкингом. +**Максимальная извлекаемая ценность (MEV)** — это максимизация валидаторами своей прибыльности путем выгодного упорядочивания транзакций. Распространенные примеры включают арбитраж свопов на децентрализованных биржах (например, фронтраннинг крупной продажи или покупки) или выявление возможностей для ликвидации позиций DeFi. Для максимизации MEV требуются современные технические ноу-хау и специализированное программное обеспечение, добавляемое к обычным валидаторам. Это значительно повышает вероятность того, что организованные операторы превзойдут отдельных лиц и любителей-валидаторов при извлечении MEV. Это означает, что выгодность стейкинга, вероятно, будут выше у централизованных операторов, что создаст централизирующую силу, которая лишает стимула заниматься домашним стейкингом. PBS решает эту проблему, перенастраивая экономику MEV. Вместо того, чтобы делать предлагающий выполнял собственный поиск MEV, он просто подбирает блок из большого количества выставленных на выбор строителями блоков. Строители блоков могли бы сделать сложное извлечение MEV, но награда за это достанется предлагающему. Таким образом, даже если небольшой пул специализированных строителей блоков будет доминировать в извлечении MEV, награда за это сможет пойти любому валидатору в сети, в том числе — отдельным домашним дольщикам. - + Отдельные лица могут быть заинтересованы в том, чтобы участвовать в стейкинге с помощью пулов, а не самостоятельно, так как сложные стратегии в области MEV дают им улучшенные награды. Отделение постройки блока от предложения означает, что извлеченное MEV будет распределено среди большего числа валидаторов, а не централизовано у того, кто будет эффективнее всех искать MEV. В то же время возможность существования специализированных строителей снимает с отдельных лиц бремя по созданию блоков, а также не позволяет им красть MEV для себя. При этом максимизируется число отдельных и независимых валидаторов, которые могут проверять блоки и являются честными. Важной концепцией является «асимметрия проверяющих-верификаторов». Она предполагает, что централизованное производство блоков приемлемо, пока существует надежная и максимально децентрализованная сеть валидаторов, способных доказать, что блоки честны. Децентрализация — это лишь средство, а конечная цель — честные блоки. -## PBS и данкшардинг {#pbs-and-danksharding} +## PBS и Danksharding {#pbs-and-danksharding} -Данкшардинг — это способ масштабирования Ethereum до > 100 000 транзакций в секунду и минимизации комиссий для пользователей свертков. Данкшардинг опирается на PBS, поскольку он увеличивает рабочую нагрузку на строителей блоков, которым придется вычислить доказательства для данных свертков размером до 64 МБ менее чем за 1 секунду. Это, скорее всего, потребует специализированных строителей, которые смогут выделить довольно существенное аппаратное обеспечение под такую задачу. Однако в нынешней ситуации процесс создания блоков может стать все более централизованным вокруг более продвинутых и мощных операторов в любом случае в связи с извлечением MEV. Разделение создающего и предлагающего — это способ принять эту реальность и не позволить ей стать централизующей силой, действующей на валидацию блоков (важная часть) или распределение вознаграждений за стейкинг. Большим побочным преимуществом является то, что специализированные строители блоков также готовы и способны вычислить необходимые доказательства данных для данкшардинга. +Danksharding — это способ масштабирования Ethereum до >100 000 транзакций в секунду и минимизации комиссий для пользователей свертков. Данкшардинг опирается на PBS, поскольку он увеличивает рабочую нагрузку на строителей блоков, которым придется вычислить доказательства для данных свертков размером до 64 МБ менее чем за 1 секунду. Это, скорее всего, потребует специализированных строителей, которые смогут выделить довольно существенное аппаратное обеспечение под такую задачу. Однако в нынешней ситуации процесс создания блоков может стать все более централизованным вокруг более продвинутых и мощных операторов в любом случае в связи с извлечением MEV. Разделение создающего и предлагающего — это способ принять эту реальность и не позволить ей стать централизующей силой, действующей на валидацию блоков (важная часть) или распределение вознаграждений за стейкинг. Большим побочным преимуществом является то, что специализированные строители блоков также готовы и способны вычислить необходимые доказательства данных для данкшардинга. ## Текущий прогресс {#current-progress} -PBS находится на продвинутой стадии исследований, но есть еще некоторые важные вопросы проектирования, которые должны быть решены, прежде чем прототип сможет быть реализован в клиентах Ethereum. Окончательных спецификаций пока нет. Это означает, что до реализации PBS остается не меньше года. Ознакомьтесь с актуальным [ходом исследований](https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance). +PBS находится на продвинутой стадии исследований, но есть еще некоторые важные вопросы проектирования, которые должны быть решены, прежде чем прототип сможет быть реализован в клиентах Ethereum. Окончательных спецификаций пока нет. Это означает, что до реализации PBS остается не меньше года. Ознакомьтесь с последним [состоянием исследований](https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance). -## Дополнительные ресурсы {#further-reading} +## Дополнительные материалы {#further-reading} -- [Состояние исследований: сопротивление цензуре при PBS](https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance) -- [Дизайны рынка комиссий, благоприятные для PBS](https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725) +- [Состояние исследований: устойчивость к цензуре в условиях PBS](https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance) +- [Модели рынка комиссий, совместимые с PBS](https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725) - [PBS и устойчивость к цензуре](https://notes.ethereum.org/@fradamt/H1TsYRfJc#Secondary-auctions) - [Списки включения](https://notes.ethereum.org/@fradamt/H1ZqdtrBF) diff --git a/public/content/translations/ru/roadmap/pectra/7702/index.md b/public/content/translations/ru/roadmap/pectra/7702/index.md new file mode 100644 index 00000000000..2560070fd99 --- /dev/null +++ b/public/content/translations/ru/roadmap/pectra/7702/index.md @@ -0,0 +1,149 @@ +--- +title: "Руководство по Pectra 7702" +description: "Узнайте больше о 7702 в выпуске Pectra" +lang: ru +--- + +# Pectra 7702 + +## Аннотация {#abstract} + +EIP 7702 определяет механизм добавления кода в EOA. Это предложение позволяет EOA, устаревшим аккаунтам Ethereum, получать краткосрочные функциональные улучшения, повышая удобство использования приложений. Это делается путем установки указателя на уже развернутый код с использованием нового типа транзакции: 4. + +Этот новый тип транзакции вводит список авторизации. Каждый кортеж авторизации в списке определяется как + +``` +[ chain_id, address, nonce, y_parity, r, s ] +``` + +**address** — это делегирование (уже развернутый байт-код, который будет использоваться EOA) +**chain_id** привязывает авторизацию к определенной сети (или 0 для всех сетей) +**nonce** привязывает авторизацию к определенному nonce аккаунта +(**y_parity, r, s**) — это подпись кортежа авторизации, определяемая как keccak(0x05 || rlp ([chain_id, address, nonce])) закрытым ключом EOA, к которому применяется авторизация (также называемого полномочием) + +Делегирование можно сбросить, делегировав на нулевой адрес. + +Закрытый ключ EOA сохраняет полный контроль над аккаунтом после делегирования. Например, делегирование в Safe не делает аккаунт мультиподписным, потому что все еще существует один ключ, который может обойти любую политику подписи. В дальнейшем разработчики должны проектировать с учетом того, что любой участник системы может быть смарт-контрактом. Для разработчиков смарт-контрактов больше небезопасно предполагать, что `tx.origin` относится к EOA. + +## Лучшие практики {#best-practices} + +**Абстракция аккаунта**: контракт делегирования должен соответствовать более широким стандартам абстракции аккаунта (AA) Ethereum для максимальной совместимости. В частности, он должен в идеале быть совместимым с ERC-4337. + +**Безразрешительный и устойчивый к цензуре дизайн**: Ethereum ценит безразрешительное участие. Контракт делегирования НЕ ДОЛЖЕН жестко кодировать или полагаться на какой-либо один «доверенный» ретранслятор или сервис. Это заблокирует аккаунт, если ретранслятор отключится. Такие функции, как пакетирование (например, approve+transferFrom), могут использоваться самим EOA без ретранслятора. Разработчикам приложений, которые хотят использовать расширенные функции, предоставляемые 7702 (абстракция газа, вывод средств с сохранением конфиденциальности), понадобится ретранслятор. Хотя существуют различные архитектуры ретрансляторов, мы рекомендуем использовать [сборщики 4337](https://www.erc4337.io/bundlers), указывающие как минимум на [точку входа 0.8](https://github.com/eth-infinitism/account-abstraction/releases/tag/v0.8.0), потому что: + +- Они предоставляют стандартизированные интерфейсы для ретрансляции +- Включают встроенные системы paymaster +- Обеспечивают прямую совместимость +- Могут поддерживать устойчивость к цензуре через [публичный мемпул](https://notes.ethereum.org/@yoav/unified-erc-4337-mempool) +- Могут требовать, чтобы функция init вызывалась только из [EntryPoint](https://github.com/eth-infinitism/account-abstraction/releases/tag/v0.8.0) + +Другими словами, любой может выступать в качестве спонсора/ретранслятора транзакции, если он предоставляет требуемую действительную подпись или UserOperation от аккаунта. Это обеспечивает устойчивость к цензуре: если не требуется специальная инфраструктура, транзакции пользователя не могут быть произвольно заблокированы контролирующим ретранслятором. Например, [Инструментарий делегирования MetaMask](https://github.com/MetaMask/delegation-framework/releases/tag/v1.3.0) явно работает с любым сборщиком или paymaster ERC-4337 в любой сети, а не требует специального сервера MetaMask. + +**Интеграция децентрализованных приложений через интерфейсы кошельков**: + +Учитывая, что кошельки будут добавлять в белый список определенные контракты делегирования для EIP-7702, децентрализованные приложения не должны ожидать прямого запроса авторизаций 7702. Вместо этого интеграция должна происходить через стандартизированные интерфейсы кошельков: + +- **ERC-5792 (`wallet_sendCalls`)**: позволяет децентрализованным приложениям запрашивать у кошельков выполнение пакетных вызовов, облегчая такие функции, как пакетирование транзакций и абстракция газа. + +- **ERC-6900**: позволяет децентрализованным приложениям использовать возможности модульных смарт-аккаунтов, такие как сессионные ключи и восстановление аккаунта, через модули, управляемые кошельком. + +Используя эти интерфейсы, децентрализованные приложения могут получать доступ к функциям смарт-аккаунтов, предоставляемым EIP-7702, без прямого управления делегированиями, обеспечивая совместимость и безопасность в различных реализациях кошельков. + +> Примечание: не существует стандартизированного метода для децентрализованных приложений для прямого запроса подписей авторизации 7702. Децентрализованные приложения должны полагаться на определенные интерфейсы кошельков, такие как ERC-6900, чтобы использовать функции EIP-7702. + +Для получения дополнительной информации: + +- [Спецификация ERC-5792](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-5792.md) +- [Спецификация ERC-6900](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-6900.md) + +**Избегание привязки к поставщику**: в соответствии с вышеизложенным, хорошая реализация является независимой от поставщика и совместимой. Это часто означает соблюдение появляющихся стандартов для смарт-аккаунтов. Например, [модульный аккаунт Alchemy](https://github.com/alchemyplatform/modular-account) использует стандарт ERC-6900 для модульных смарт-аккаунтов и разработан с учетом «безразрешительного совместимого использования». + +**Сохранение конфиденциальности**: хотя конфиденциальность в сети ограничена, контракт делегирования должен стремиться к минимизации раскрытия данных и возможности их связывания. Этого можно достичь, поддерживая такие функции, как оплата газа в токенах ERC-20 (чтобы пользователям не нужно было поддерживать публичный баланс ETH, что улучшает конфиденциальность и UX) и одноразовые сессионные ключи (что снижает зависимость от одного долгосрочного ключа). Например, EIP-7702 позволяет оплачивать газ в токенах через спонсируемые транзакции, и хорошая реализация облегчит интеграцию таких paymaster-ов, не раскрывая больше информации, чем необходимо. Кроме того, офчейн-делегирование определенных одобрений (с использованием подписей, которые проверяются ончейн) означает меньшее количество ончейн-транзакций с основным ключом пользователя, что способствует конфиденциальности. Аккаунты, требующие использования ретранслятора, заставляют пользователей раскрывать свои IP-адреса. PublicMempools улучшает это: когда транзакция/UserOp распространяется через мемпул, вы не можете определить, исходит ли она от IP-адреса, который ее отправил, или просто была ретранслирована через него по протоколу p2p. + +**Расширяемость и модульная безопасность**: реализации аккаунтов должны быть расширяемыми, чтобы они могли развиваться с новыми функциями и улучшениями безопасности. Возможность обновления изначально заложена в EIP-7702 (поскольку EOA всегда может делегировать новому контракту в будущем для обновления своей логики). Помимо возможности обновления, хороший дизайн обеспечивает модульность — например, подключаемые модули для различных схем подписей или политик расходования — без необходимости полной переразвертки. Набор для аккаунтов от Alchemy — яркий пример, позволяющий разработчикам устанавливать модули валидации (для различных типов подписей, таких как ECDSA, BLS и т. д.) и модули исполнения для пользовательской логики. Для достижения большей гибкости и безопасности в аккаунтах с поддержкой EIP-7702 разработчикам рекомендуется делегировать прокси-контракту, а не напрямую конкретной реализации. Такой подход позволяет беспрепятственно обновлять и обеспечивать модульность без необходимости дополнительных авторизаций EIP-7702 для каждого изменения. + +Преимущества паттерна прокси: + +- **Возможность обновления**: обновите логику контракта, указав прокси на новый контракт реализации. + +- **Пользовательская логика инициализации**: встройте функции инициализации в прокси для безопасной настройки необходимых переменных состояния. + +Например, [SafeEIP7702Proxy](https://docs.safe.global/advanced/eip-7702/7702-safe) демонстрирует, как прокси можно использовать для безопасной инициализации и управления делегированиями в аккаунтах, совместимых с EIP-7702. + +Недостатки паттерна прокси: + +- **Зависимость от внешних участников**: вам приходится полагаться на внешнюю команду, чтобы она не обновила контракт до небезопасной версии. + +## Вопросы безопасности {#security-considerations} + +**Защита от повторного входа**: с введением делегирования по EIP-7702 аккаунт пользователя может динамически переключаться между внешним аккаунтом (EOA) и смарт-контрактом (SC). Эта гибкость позволяет аккаунту как инициировать транзакции, так и быть целью вызовов. В результате в сценариях, когда аккаунт вызывает сам себя и совершает внешние вызовы, `msg.sender` будет равен `tx.origin`, что подрывает определенные предположения о безопасности, которые ранее основывались на том, что `tx.origin` всегда является EOA. + +Для разработчиков смарт-контрактов больше небезопасно предполагать, что `tx.origin` относится к EOA. Аналогично, использование `msg.sender == tx.origin` в качестве защиты от атак повторного входа больше не является надежной стратегией. + +В дальнейшем разработчики должны проектировать с учетом того, что любой участник системы может быть смарт-контрактом. В качестве альтернативы они могут реализовать явную защиту от повторного входа, используя охранные механизмы с модификатором `nonReentrant`. Мы рекомендуем использовать проверенный модификатор, например [Reentrancy Guard от OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/ReentrancyGuard.sol). Они также могут использовать [переменную временного хранилища](https://docs.soliditylang.org/en/latest/internals/layout_in_storage.html). + +**Вопросы безопасности инициализации** + +Реализация контрактов делегирования EIP-7702 создает специфические проблемы безопасности, особенно в отношении процесса инициализации. Критическая уязвимость возникает, когда функция инициализации (`init`) атомарно связана с процессом делегирования. В таких случаях опережающий участник может перехватить подпись делегирования и выполнить функцию `init` с измененными параметрами, потенциально получив контроль над аккаунтом. + +Этот риск особенно актуален при попытке использовать существующие реализации аккаунтов смарт-контрактов (SCA) с EIP-7702 без изменения их механизмов инициализации. + +**Решения для смягчения уязвимостей инициализации** + +- Реализуйте `initWithSig` + Замените стандартную функцию `init` на функцию `initWithSig`, которая требует от пользователя подписи параметров инициализации. Этот подход гарантирует, что инициализация может быть продолжена только с явного согласия пользователя, тем самым снижая риски несанкционированной инициализации. + +- Используйте EntryPoint из ERC-4337 + Требуйте, чтобы функция инициализации вызывалась исключительно из контракта EntryPoint ERC-4337. Этот метод использует стандартизированную структуру валидации и исполнения, предоставляемую ERC-4337, добавляя дополнительный уровень безопасности к процессу инициализации. + _(См.: [документация Safe](https://docs.safe.global/advanced/eip-7702/7702-safe))_ + +Применяя эти решения, разработчики могут повысить безопасность контрактов делегирования EIP-7702, защищаясь от потенциальных атак опережения на этапе инициализации. + +**Коллизии хранилища** Делегирование кода не очищает существующее хранилище. При миграции с одного контракта делегирования на другой остаточные данные от предыдущего контракта сохраняются. Если новый контракт использует те же слоты хранилища, но интерпретирует их по-другому, это может вызвать непреднамеренное поведение. Например, если начальное делегирование было контракту, где слот хранилища представляет собой `bool`, а последующее делегирование — контракту, где тот же слот представляет собой `uint`, несоответствие может привести к непредсказуемым результатам. + +**Риски фишинга** С внедрением делегирования по EIP-7702 активы на аккаунте пользователя могут полностью контролироваться смарт-контрактами. Если пользователь неосознанно делегирует свой аккаунт вредоносному контракту, злоумышленник может легко получить контроль и украсть средства. При использовании `chain_id=0` делегирование применяется ко всем идентификаторам сетей. Делегируйте только неизменяемому контракту (никогда не делегируйте прокси) и только контрактам, которые были развернуты с использованием CREATE2 (со стандартным initcode — без метаморфических контрактов), чтобы развертывающий не мог развернуть что-то другое по тому же адресу в другом месте. В противном случае ваше делегирование подвергает ваш аккаунт риску во всех других EVM-сетях. + +Когда пользователи выполняют делегированные подписи, целевой контракт, получающий делегирование, должен быть четко и заметно отображен, чтобы помочь снизить риски фишинга. + +**Минимальная доверенная поверхность и безопасность**: предлагая гибкость, контракт делегирования должен сохранять свою основную логику минимальной и поддающейся аудиту. Контракт фактически является расширением EOA пользователя, поэтому любой недостаток может быть катастрофическим. Реализации должны следовать лучшим практикам сообщества по безопасности смарт-контрактов. Например, функции конструктора или инициализатора должны быть тщательно защищены — как подчеркивает Alchemy, при использовании паттерна прокси в рамках 7702 незащищенный инициализатор может позволить злоумышленнику захватить аккаунт. Команды должны стремиться сохранять ончейн-код простым: контракт 7702 от Ambire содержит всего ~200 строк на Solidity, намеренно минимизируя сложность для уменьшения ошибок. Необходимо найти баланс между многофункциональной логикой и простотой, облегчающей аудит. + +### Известные реализации {#known-implementations} + +Из-за природы EIP 7702 кошелькам рекомендуется проявлять осторожность, помогая пользователям делегировать стороннему контракту. Ниже приведен список известных реализаций, прошедших аудит: + +| Адрес контракта | Источник | Аудиты | +| ------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| 0x000000009B1D0aF20D8C6d0A44e162d11F9b8f00 | [Uniswap/calibur](https://github.com/Uniswap/calibur) | [аудиты](https://github.com/Uniswap/calibur/tree/main/audits) | +| 0x69007702764179f14F51cdce752f4f775d74E139 | [alchemyplatform/modular-account](https://github.com/alchemyplatform/modular-account) | [аудиты](https://github.com/alchemyplatform/modular-account/tree/develop/audits) | +| 0x5A7FC11397E9a8AD41BF10bf13F22B0a63f96f6d | [AmbireTech/ambire-common](https://github.com/AmbireTech/ambire-common/blob/feature/eip-7702/contracts/AmbireAccount7702.sol) | [аудиты](https://github.com/AmbireTech/ambire-common/tree/feature/eip-7702/audits) | +| 0x63c0c19a282a1b52b07dd5a65b58948a07dae32b | [MetaMask/delegation-framework](https://github.com/MetaMask/delegation-framework) | [аудиты](https://github.com/MetaMask/delegation-framework/tree/main/audits) | +| 0x4Cd241E8d1510e30b2076397afc7508Ae59C66c9 | [Команда AA Ethereum Foundation](https://github.com/eth-infinitism/account-abstraction/blob/develop/contracts/accounts/Simple7702Account.sol) | [аудиты](https://github.com/eth-infinitism/account-abstraction/blob/develop/audits/SpearBit%20Account%20Abstraction%20Security%20Review%20-%20Mar%202025.pdf) | +| 0x17c11FDdADac2b341F2455aFe988fec4c3ba26e3 | [Luganodes/Pectra-Batch-Contract](https://github.com/Luganodes/Pectra-Batch-Contract) | [аудиты](https://certificate.quantstamp.com/full/luganodes-pectra-batch-contract/23f0765f-969a-4798-9edd-188d276c4a2b/index.html) | + +## Руководство для аппаратных кошельков {#hardware-wallet-guidelines} + +Аппаратные кошельки не должны предоставлять возможность произвольного делегирования. Консенсус в сообществе аппаратных кошельков заключается в использовании списка доверенных контрактов-делегаторов. Мы предлагаем разрешить известные реализации, перечисленные выше, и рассматривать другие в индивидуальном порядке. Поскольку делегирование вашего EOA контракту дает контроль над всеми активами, аппаратные кошельки должны быть осторожны со способом реализации 7702. + +### Сценарии интеграции для приложений-компаньонов {#integration-scenarios-for-companion-apps} + +#### Пассивный {#lazy} + +Поскольку EOA по-прежнему работает как обычно, ничего делать не нужно. + +Примечание: некоторые активы могут быть автоматически отклонены кодом делегирования, например NFT стандарта ERC-1155, и служба поддержки должна быть об этом осведомлена. + +#### Информированный {#aware} + +Уведомите пользователя о наличии делегирования для EOA, проверив его код, и, по желанию, предложите удалить делегирование. + +#### Общее делегирование {#common-delegation} + +Поставщик оборудования добавляет в белый список известные контракты делегирования и реализует их поддержку в программном обеспечении-компаньоне. Рекомендуется выбирать контракт с полной поддержкой ERC-4337. + +EOA, делегированные другому контракту, будут обрабатываться как стандартные EOA. + +#### Пользовательское делегирование {#custom-delegation} + +Поставщик оборудования реализует свой собственный контракт делегирования, добавляет его в списки и реализует его поддержку в программном обеспечении-компаньоне. Рекомендуется создавать контракт с полной поддержкой ERC-4337. + +EOA, делегированные другому контракту, будут обрабатываться как стандартные EOA. diff --git a/public/content/translations/ru/roadmap/pectra/index.md b/public/content/translations/ru/roadmap/pectra/index.md new file mode 100644 index 00000000000..c553b770575 --- /dev/null +++ b/public/content/translations/ru/roadmap/pectra/index.md @@ -0,0 +1,127 @@ +--- +title: Prague-Electra (Pectra) +description: "Узнайте об апгрейде протокола Pectra" +lang: ru +--- + +# Pectra {#pectra} + +Апгрейд сети Pectra последовал за [Dencun](/roadmap/dencun/) и внес изменения как в уровень исполнения, так и в уровень консенсуса Ethereum. Сокращенное название Pectra — это сочетание названий Prague и Electra, которые являются соответствующими названиями для изменений в спецификациях уровня исполнения и уровня консенсуса. В совокупности эти изменения вносят ряд улучшений для пользователей, разработчиков и валидаторов Ethereum. + +Этот апгрейд был успешно активирован в основной сети Ethereum в эпоху `364032`, **7 мая 2025 года в 10:05 (UTC)**. + + + + +Апгрейд Pectra — это лишь один шаг на пути к достижению долгосрочных целей развития Ethereum. Узнайте больше о [дорожной карте протокола](/roadmap/) и [предыдущих апгрейдах](/ethereum-forks/). + + + + +## Улучшения в Pectra {#new-improvements} + +Pectra содержит самое большое количество предложений по улучшению Ethereum ([EIP](https://eips.ethereum.org/)) из всех предыдущих апгрейдов! В нем много незначительных изменений, а также несколько значительных новых функций. Полный список изменений и технических подробностей можно найти в отдельных включенных EIP. + +### Код аккаунта EOA {#7702} + +[EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) представляет собой важный шаг на пути к широкому распространению [абстракции аккаунта](/roadmap/account-abstraction/). С помощью этой функции пользователи могут настроить расширение своего адреса ([EOA](/glossary/#eoa)) с помощью смарт-контракта. EIP вводит новый тип транзакции с определенной функцией — позволить владельцам адресов подписывать авторизацию, которая настраивает их адрес на имитацию выбранного смарт-контракта. + +С помощью этого EIP пользователи могут выбрать программируемые кошельки, которые поддерживают новые функции, такие как объединение транзакций, транзакции без газа и настраиваемый доступ к активам для альтернативных схем восстановления. Этот гибридный подход сочетает в себе простоту EOA с программируемостью аккаунтов на основе контрактов. + +Подробнее о EIP-7702 читайте [здесь](/roadmap/pectra/7702/) + +### Увеличение максимального эффективного баланса {#7251} + +Текущий эффективный баланс валидатора составляет ровно 32 ETH. Это минимальная необходимая сумма для участия в консенсусе, но в то же время и максимальная сумма, которую может внести в стейкинг один валидатор. + +[EIP-7251](https://eips.ethereum.org/EIPS/eip-7251) повышает максимально возможный эффективный баланс до 2048 ETH. Это означает, что один валидатор теперь может вносить в стейкинг от 32 до 2048 ETH. Вместо сумм, кратных 32, участники стейкинга теперь могут выбрать произвольное количество ETH для стейкинга и получать вознаграждение за каждый 1 ETH сверх минимума. Например, если баланс валидатора благодаря вознаграждениям вырастает до 33 ETH, дополнительный 1 ETH также считается частью эффективного баланса и приносит вознаграждение. + +Но преимущество улучшенной системы вознаграждений для валидаторов — это лишь часть данного улучшения. Участники стейкинга ([Stakers](/staking/)), управляющие несколькими валидаторами, теперь могут объединить их в одного, что упрощает работу и снижает нагрузку на сеть. Поскольку каждый валидатор в сети Beacon отправляет подпись в каждую эпоху, требования к пропускной способности растут с увеличением числа валидаторов и большого количества подписей для распространения. Объединение валидаторов снизит нагрузку на сеть и откроет новые возможности масштабирования при сохранении того же уровня экономической безопасности. + +Подробнее о maxEB читайте [здесь](/roadmap/pectra/maxeb/) + +### Увеличение пропускной способности blob-объектов {#7691} + +Blob-объекты обеспечивают [доступность данных](/developers/docs/data-availability/#data-availability-and-layer-2-rollups) для L2-решений. Они были введены в [предыдущем апгрейде сети](/roadmap/dencun/). + +В настоящее время сеть нацелена на среднее значение в 3 blob-объекта на блок с максимумом в 6 blob-объектов. С [EIP-7691](https://eips.ethereum.org/EIPS/eip-7691) среднее количество blob-объектов будет увеличено до 6, с максимумом в 9 на блок, что приведет к увеличению пропускной способности для ролл-апов Ethereum. Этот EIP помогает сократить разрыв до тех пор, пока [PeerDAS](https://eips.ethereum.org/EIPS/eip-7594) не обеспечит еще большее количество blob-объектов. + +### Увеличение стоимости calldata {#7623} + +До введения [blob-объектов в апгрейде Dencun](/roadmap/danksharding) L2-решения использовали [calldata](/developers/docs/data-availability/blockchain-data-storage-strategies/#calldata) для хранения своих данных в Ethereum. И blob-объекты, и calldata влияют на использование пропускной способности Ethereum. Хотя большинство блоков используют лишь минимальное количество calldata, блоки с большим объемом данных, которые также содержат много blob-объектов, могут нанести вред p2p-сети Ethereum. + +Для решения этой проблемы [EIP-7623](https://eips.ethereum.org/EIPS/eip-7623) увеличивает стоимость calldata, но только для транзакций с большим объемом данных. Это ограничивает размер блока в худшем случае, стимулирует L2-решения использовать только blob-объекты и не затрагивает более 99% транзакций. + +### Запускаемые выходы на уровне исполнения {#7002} + +В настоящее время выход валидатора и [вывод ETH из стейкинга](/staking/withdrawals/) — это операция на уровне консенсуса, которая требует активного ключа валидатора, того же ключа BLS, который валидатор использует для выполнения активных обязанностей, таких как аттестации. Учетные данные для вывода — это отдельный «холодный» ключ, который получает выведенную долю, но не может инициировать выход. Единственный способ для участников стейкинга выйти — это отправить специальное сообщение в сеть Beacon, подписанное с использованием активного ключа валидатора. Это создает ограничения в сценариях, когда учетные данные для вывода и ключ валидатора принадлежат разным сущностям или когда ключ валидатора утерян. + +[EIP-7002](https://eips.ethereum.org/EIPS/eip-7002) вводит новый контракт, который можно использовать для запуска выхода с помощью учетных данных для вывода на уровне исполнения. Участники стейкинга смогут вывести своего валидатора, вызвав функцию в этом специальном контракте, без необходимости иметь ключ подписи валидатора или доступ к сети Beacon. Важно отметить, что включение вывода валидаторов в сети (onchain) позволяет создавать протоколы стейкинга с меньшими требованиями к доверию по отношению к операторам узлов. + +### Депозиты валидаторов в сети {#6110} + +Депозиты валидаторов в настоящее время обрабатываются с помощью [опроса eth1data](https://eth2book.info/capella/part2/deposits-withdrawals/deposit-processing/) — это функция в сети Beacon, которая извлекает данные с уровня исполнения. Это своего рода технический долг со времен до Слияния (The Merge), когда сеть Beacon была отдельной сетью и должна была учитывать реорганизации на основе доказательства выполнения работы (proof-of-work). + +[EIP-6110](https://eips.ethereum.org/EIPS/eip-6110) — это новый способ доставки депозитов с уровня исполнения на уровень консенсуса, который позволяет мгновенно обрабатывать их с меньшей сложностью реализации. Это более безопасный способ обработки депозитов, встроенный в объединенный Ethereum. Это также помогает обеспечить перспективность протокола, поскольку для начальной загрузки узла не требуются исторические депозиты, что необходимо для истечения срока хранения истории. + +### Предварительная компиляция для BLS12-381 {#2537} + +Предварительно скомпилированные контракты (precompiles) — это особый набор смарт-контрактов, встроенных непосредственно в виртуальную машину Ethereum ([EVM](/developers/docs/evm/)). В отличие от обычных контрактов, предварительно скомпилированные контракты не развертываются пользователями, а являются частью самой реализации клиента, написанной на его собственном языке (например, Go, Java и т. д., а не Solidity). Предварительно скомпилированные контракты служат для широко используемых и стандартизированных функций, таких как криптографические операции. Разработчики смарт-контрактов могут вызывать предварительно скомпилированные контракты как обычные контракты, но с большей безопасностью и эффективностью. + +[EIP-2537](https://eips.ethereum.org/EIPS/eip-2537) добавляет новые предварительно скомпилированные контракты для операций с кривой [BLS12-381](https://hackmd.io/@benjaminion/bls12-381). Эта эллиптическая кривая стала широко использоваться в криптовалютных экосистемах благодаря своим практическим свойствам. В частности, она была принята на уровне консенсуса Ethereum, где ее используют валидаторы. + +Новый предварительно скомпилированный контракт дает каждому разработчику возможность легко, эффективно и безопасно выполнять криптографические операции с использованием этой кривой, например, проверять подписи. Onchain-приложения, зависящие от этой кривой, могут стать более эффективными с точки зрения расхода газа и более безопасными, полагаясь на предварительно скомпилированный контракт вместо какого-либо пользовательского контракта. В основном это относится к приложениям, которые должны работать с валидаторами внутри EVM, например, пулы для стейкинга, [рестейкинг](/restaking/), легкие клиенты, мосты, а также приложения с 0-знанием. + +### Предоставление исторических хэшей блоков из состояния {#2935} + +В настоящее время EVM предоставляет опкод `BLOCKHASH`, который позволяет разработчикам контрактов получать хэш блока непосредственно на уровне исполнения. Однако это ограничение распространяется только на последние 256 блоков и в будущем может стать проблемой для клиентов без сохранения состояния (stateless clients). + +[EIP-2935](https://eips.ethereum.org/EIPS/eip-2935) создает новый системный контракт, который может предоставлять хэши последних 8192 блоков в качестве ячеек хранения. Это помогает обеспечить перспективность протокола для выполнения без сохранения состояния и становится более эффективным при внедрении деревьев Verkle. Однако, помимо этого, ролл-апы могут извлечь выгоду из этого уже сейчас, поскольку они могут запрашивать контракт напрямую с более длинным историческим окном. + +### Перемещение индекса комитета за пределы аттестации {#7549} + +Консенсус сети Beacon основан на голосовании валидаторов за последний блок и финализированную эпоху. Аттестация включает 3 элемента: 2 из них — голоса, а третий — значение индекса комитета. + +[EIP-7549](https://eips.ethereum.org/EIPS/eip-7549) выносит этот индекс за пределы подписанного сообщения об аттестации, что упрощает проверку и агрегацию голосов консенсуса. Это повысит эффективность каждого клиента консенсуса и может значительно улучшить производительность схем с 0-знанием для доказательства консенсуса Ethereum. + +### Добавление расписания blob-объектов в файлы конфигурации EL {#7840} + +[EIP-7840](https://eips.ethereum.org/EIPS/eip-7840) — это простое изменение, которое добавляет новое поле в конфигурацию клиента уровня исполнения. Оно настраивает количество блоков, позволяя динамически устанавливать целевое и максимальное количество blob-объектов на блок, а также корректировать комиссию за blob-объекты. При наличии непосредственно определенной конфигурации клиенты могут избежать сложности обмена этой информацией через Engine API. + + + + +Чтобы узнать больше о том, как Pectra повлияет именно на вас как на пользователя, разработчика или валидатора Ethereum, ознакомьтесь с Pectra FAQ. + + + + +## Повлияет ли этот апгрейд на все узлы и валидаторы Ethereum? {#client-impact} + +Да, апгрейд Pectra требует обновлений как [клиентов исполнения, так и клиентов консенсуса](/developers/docs/nodes-and-clients/). Все основные клиенты Ethereum выпустят версии, поддерживающие хард-форк, помеченные как высокоприоритетные. Чтобы обеспечить синхронизацию с сетью Ethereum после обновления, операторы узлов должны убедиться, что используют поддерживаемую версию клиента. Обратите внимание, что со временем информация о выпусках клиентов теряет актуальность, поэтому пользователям рекомендуется ознакомиться с последним обновлениям, чтобы оставаться в курсе. + +## Как конвертировать ETH после хард-форка? {#scam-alert} + +- **Никаких действий с вашими ETH не требуется**: после апгрейда Pectra в сети Ethereum не нужно конвертировать или обновлять ваши ETH. Балансы ваших счетов останутся прежними, а ETH, который вы сейчас держите, останется доступным в существующей форме после хард-форка. +- **Остерегайтесь мошенничества!** **Любой, кто поручает вам «обновить» ваш ETH, пытается вас обмануть.** Вам не нужно ничего делать в связи с этим апгрейдом. Он никак не затронет ваши активы. Помните, что оставаться в курсе новостей — лучшая защита от мошенничества. + +[Подробнее о распознавании и предотвращении мошенничества](/security/) + +## Больше увлекаетесь визуализацией? {#visual-learner} + + + +_Что войдет в апгрейд Pectra?_ – _Кристин Ким_ + + + +_Апгрейд Pectra в Ethereum: что нужно знать участникам стейкинга — Blockdaemon_ + +## Дополнительные материалы {#further-reading} + +- [Дорожная карта Ethereum](/roadmap/) +- [Pectra: часто задаваемые вопросы](https://epf.wiki/#/wiki/pectra-faq) +- [Информационная страница Pectra.wtf](https://pectra.wtf) +- [Как Pectra улучшает опыт участников стейкинга](https://www.kiln.fi/post/next-ethereum-upgrade-how-pectra-will-enhance-the-staking-experience) +- [Информационная страница EIP7702](https://eip7702.io/) +- [Девнеты Pectra](https://github.com/ethereum/pm/blob/master/Pectra/pectra-pm.md) diff --git a/public/content/translations/ru/roadmap/pectra/maxeb/index.md b/public/content/translations/ru/roadmap/pectra/maxeb/index.md new file mode 100644 index 00000000000..a99e9abe1c6 --- /dev/null +++ b/public/content/translations/ru/roadmap/pectra/maxeb/index.md @@ -0,0 +1,204 @@ +--- +title: Pectra MaxEB +description: "Узнайте больше о MaxEB в релизе Pectra" +lang: ru +--- + +# MaxEB {#maxeb} + +_Вкратце:_ хард-форк Pectra позволяет валидаторам Ethereum выбрать более высокий максимальный эффективный баланс и компаундинг путем преобразования учетных данных для вывода средств с **Типа 1** на **Тип 2**. Официальный инструмент для этого — Лаунчпад. Эта операция необратима. + +## Обзор {#overview} + +### Кого это затрагивает? {#who-is-affected} + +Любой, кто запускает валидатор, — это, скорее всего, тот, кто знает индекс (например, [Валидатор № 12345](https://beaconcha.in/validator/12345)) валидатора, которым он управляет. Если вы используете протокол для запуска валидатора (например, Lido CSM или Rocket Pool), вам нужно будет уточнить у них, поддерживают ли они maxEB и когда. + +Если вы занимаетесь стейкингом с использованием ликвидного токена стейкинга (например, rETH или stETH), никаких действий не требуется и не рекомендуется. + +### Что такое «maxEB»? {#what-is-maxeb} + +maxEB = МАКСимальный эффективный баланс валидатора. До хард-форка Pectra каждый валидатор зарабатывает на максимальном балансе в 32 ETH. После Pectra у валидаторов появится возможность зарабатывать на любом балансе от 32 до 2048 ETH с шагом в 1 ETH, согласившись на это изменение. + +### Как валидатор может принять участие? {#how-does-a-validator-opt-in} + +Валидатор принимает участие в изменении maxEB, преобразуя учетные данные для вывода средств с **типа 1** на **тип 2**. Это можно будет сделать на [Лаунчпад (Действия валидатора)](https://launchpad.ethereum.org/validator-actions) после активации хард-форка Pectra. Как и в случае с переходом **Тип 0** → **Тип 1**, переход **Тип 1** → **Тип 2** является необратимым процессом. + +### Что такое учетные данные для вывода средств? {#whats-a-withdrawal-credential} + +Когда вы запускаете валидатор, у вас есть набор учетных данных для вывода средств. Их можно найти в вашем файле JSON с данными о депозите, или вы можете просмотреть их на beaconcha.in во [вкладке депозитов](https://beaconcha.in/validator/12345#deposits) вашего валидатора. + +1. **Учетные данные для вывода средств типа 0**: если учетные данные для вывода средств вашего валидатора начинаются с `0x00...`, вы внесли депозит до хард-форка Shapella и у вас еще не установлен адрес для вывода средств. + +![Учетные данные для вывода средств типа 0](./0x00-wd.png) + +2. **Учетные данные для вывода средств типа 1**: если учетные данные для вывода средств вашего валидатора начинаются с `0x01...`, вы внесли депозит после хард-форка Shapella или уже преобразовали свои учетные данные **типа 0** в учетные данные **типа 1**. + +![Учетные данные для вывода средств типа 1](./0x01-wd.png) + +3. **Учетные данные для вывода средств типа 2**: этот новый тип учетных данных для вывода средств будет начинаться с `0x02...` и будет включен после Pectra. Валидаторы с учетными данными для вывода средств **типа 2** иногда называют «**компаундинговыми валидаторами**» + +| **Разрешено** | **Не разрешено** | +| ---------------- | ---------------- | +| ✅  Тип 0 → Тип 1 | ❌  Тип 0 → Тип 2 | +| ✅  Тип 1 → Тип 2 | ❌  Тип 1 → Тип 0 | +| | ❌  Тип 2 → Тип 1 | +| | ❌  Тип 2 → Тип 0 | + +### Риски {#risks} + +MaxEB позволяет валидатору отправлять весь свой баланс другому валидатору. Пользователи, отправляющие запрос на консолидацию, должны проверять источник и содержимое транзакции, которую они подписывают. Официальным инструментом для использования функций maxEB является Лаунчпад. Если вы решите использовать сторонний инструмент, вам следует убедиться, что: + +- Публичный ключ и адрес для вывода средств исходного валидатора соответствуют валидатору, которым они управляют +- Публичный ключ целевого валидатора правильный и принадлежит им +- Запрос является преобразованием, а не консолидацией, если они не намерены отправлять средства другому валидатору +- Транзакция подписывается правильным адресом для вывода средств + +Мы **настоятельно рекомендуем** обсуждать любой сторонний инструмент, который вы планируете использовать, с [сообществом EthStaker](https://ethstaker.org/about). Это полезное место, чтобы проверить правильность вашего подхода и избежать ошибок. Если вы используете вредоносный или неправильно настроенный инструмент, **весь баланс вашего валидатора может быть отправлен валидатору, которого вы не контролируете**, — без возможности вернуть его. + +## Технические детали {#technical-details} + +### Процесс {#the-flow} + +Будет два варианта использования операции `ConsolidationRequest`: + +1. Преобразование существующего валидатора из валидатора **типа 1** в валидатор **типа 2** +2. Консолидация других валидаторов в существующий валидатор **типа 2** + +При преобразовании валидатора **типа 1** в валидатор **типа 2** и _источник_, и _цель_ будут соответствовать преобразуемому вами валидатору. Операция потребует газа и будет поставлена в очередь за другими запросами на консолидацию. Эта очередь **отделена** от очереди депозитов, на нее не влияют новые депозиты валидаторов, и ее можно посмотреть на [pectrified.com](https://pectrified.com/). + +Для консолидации валидаторов у вас должен быть _целевой валидатор_, у которого есть учетные данные для вывода средств **типа 2**. Это место назначения для всех консолидируемых балансов валидаторов и индекс, который сохраняется. + +### Требования для преобразования в Тип 2 {#requirements-for-converting-to-type-2} + +Это потребуется для первого валидатора, которого вы преобразуете в **Тип 2**. Индекс этого валидатора сохраняется и остается активным. Для преобразования _исходный валидатор_ == _целевой валидатор_. + +Валидатор должен... + +- быть активным +- иметь учетные данные для вывода средств **Типа 1** +- не находиться в состоянии выхода (или быть перечеркнутым) +- не иметь ожидающих вывода средств, запущенных вручную (не относится к автоматическому выводу) + +![иллюстрация преобразования](./conversion.png) + +### Требования для консолидации {#requirements-for-consolidating} + +Это _та же операция_, что и преобразование, но _исходный валидатор_ отличается от _целевого валидатора_. Индекс целевого валидатора сохраняется, и он принимает баланс от исходного валидатора. Индекс исходного валидатора переводится в состояние `EXITED`. + +В этом случае к исходному валидатору применяются все те же требования, что и выше, плюс: + +- активен не менее ~27,3 часов (один `SHARD_COMMITTEE_PERIOD`) + +Целевой валидатор должен + +- иметь учетные данные для вывода средств **Типа 2** +- не находиться в состоянии выхода. + +![иллюстрация консолидации](./consolidation.png) + +### Запрос на консолидацию {#the-consolidation-request} + +Запрос на консолидацию будет подписан адресом вывода средств, связанным с исходным валидатором, и содержать: + +1. Адрес исходного валидатора (например, `0x15F4B914A0cCd14333D850ff311d6DafbFbAa32b`) +2. Публичный ключ исходного валидатора (например, `0xa1d1ad0714035353258038e964ae9675dc0252ee22cea896825c01458e1807bfad2f9969338798548d9858a571f7425c`) +3. Публичный ключ этого целевого валидатора + +При преобразовании 2 и 3 будут одинаковыми. Эту операцию можно выполнить на [Лаунчпад](https://launchpad.ethereum.org/). + +### Требования к подписи {#signing-requirements} + +Чтобы отправить `ConsolidationRequest`, **адрес вывода средств исходного валидатора** должен подписать запрос. Это доказывает контроль над средствами валидатора. + +### Что подписывается? {#what-is-signed} + +Используется [корень подписи](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/beacon-chain.md#compute_signing_root) с разделением доменов объекта `ConsolidationRequest`. + +- **Домен:** `DOMAIN_CONSOLIDATION_REQUEST` +- **Поля корня подписи:** + - `source_pubkey`: `BLSPubkey` + - `target_pubkey`: `BLSPubkey` + - `source_address`: `ExecutionAddress` + +Полученная **BLS-подпись** отправляется вместе с запросом. + +Примечание: подпись выполняется адресом для вывода средств, а не ключом валидатора. + +### Частичный вывод средств {#partial-withdrawals} + +Валидаторы с учетными данными **типа 1** получают автоматический вывод избыточного баланса (всего, что превышает 32 ETH) на свой адрес для вывода средств без уплаты газа. Поскольку **тип 2** позволяет валидатору накапливать (компаундировать) баланс с шагом в 1 ETH, он не будет автоматически выводить баланс, пока тот не достигнет 2048 ETH. Частичный вывод средств на валидаторах **типа 2** должен запускаться вручную и потребует газа. + +## Инструменты для консолидации {#consolidation-tooling} + +Существует несколько доступных инструментов для управления консолидациями. Официальный инструмент, созданный Ethereum Foundation, — это [Лаунчпад](https://launchpad.ethereum.org/en/validator-actions). Также существуют сторонние инструменты, созданные участниками стейкинг-сообщества, которые могут предлагать функции, не предоставляемые Лаунчпадом. Хотя представленные здесь инструменты не были проверены или одобрены Ethereum Foundation, ниже перечислены инструменты с открытым исходным кодом от известных членов сообщества. + +| Инструмент | Сайт | Открытый исходный код | Создатель | Проверено | Интерфейс | Примечательные особенности | +| ------------------------------- | --------------------------------------------------------------------------------------------------------- | ------------------------------ | ---------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- | ------------------------------------------------------------------------- | +| Pectra Staking Manager | pectrastaking.com | Да, Apache 2.0 | [Pier Two](https://piertwo.com/) | Нет | Веб-интерфейс | Wallet Connect, работает с SAFE | +| Pectra Validator Ops CLI Tool | [GitHub](https://github.com/Luganodes/Pectra-Batch-Contract) | Да, MIT | [Luganodes](https://www.luganodes.com/) | Да, Quantstamp [май 2025](https://certificate.quantstamp.com/full/luganodes-pectra-batch-contract/23f0765f-969a-4798-9edd-188d276c4a2b/index.html) | Командная строка | Пакетная обработка, для многих валидаторов одновременно | +| Ethereal | [GitHub](https://github.com/wealdtech/ethereal) | Да, Apache 2.0 | [Jim McDonald](https://www.attestant.io/team/) | Нет | Командная строка | Полный набор функций для управления валидаторами и узлами | +| Siren | [GitHub](https://github.com/sigp/siren) | Да, Apache 2.0 | [Sigma Prime](https://sigmaprime.io/) | Нет | Частично командная строка, но в основном веб-интерфейс | Работает только, если вы используете клиент консенсуса Lighthouse | +| Consolideth.app | https://consolideth.app/ [GitHub](https://github.com/Stakely/consolideth) | Да, лицензии MIT | [Stakely](https://stakely.io/) | Нет | Веб-интерфейс, размещенный на Stakely и готовый к бесплатному самостоятельному хостингу | Поддерживает основные подключения кошельков, включая Safe с WalletConnect | + +## Часто задаваемые вопросы {#faq} + +### Изменит ли мое участие шансы на создание блока или вознаграждения? {#change-luck-or-rewards} + +Нет. Участие не уменьшает ваши шансы на создание блока — ваши обязанности и выбор для создания блока остаются прежними. Например, если у вас два валидатора по 32 ETH против одного валидатора на 64 ETH, у вас будут одинаковые общие шансы быть выбранным для предложения блока и получения вознаграждений. + +### Изменяет ли мое участие риск слэшинга? {#change-slashing-risk} + +Для небольших или непрофессиональных операторов короткий ответ — нет. Более развернутый ответ заключается в том, что для профессиональных операторов, запускающих много валидаторов на узел с быстрыми оповещениями, консолидация в меньшее количество валидаторов может снизить их способность реагировать на слэшинг и предотвращать каскадные события. Начальный _штраф_ за слэшинг для всех валидаторов был значительно снижен с 1 ETH (за 32 ETH) до 0,0078125 ETH (за 32 ETH), чтобы компенсировать этот риск. + +### Нужно ли мне выходить из валидатора для преобразования? {#exit-validator} + +Нет. Вы можете выполнить преобразование на месте, без выхода. + +### Сколько времени займет преобразование/консолидация? {#how-long} + +Минимум 27,3 часа, но консолидации также подлежат очереди. Эта очередь не зависит от очередей на пополнение и вывод средств и не подвержена их влиянию. + +### Могу ли я сохранить свой индекс валидатора? {#keep-validator-index} + +Да. Преобразование на месте сохраняет тот же индекс валидатора. Если вы консолидируете несколько валидаторов, вы сможете сохранить только индекс _целевого валидатора_. + +### Пропущу ли я аттестации? {#miss-attestations} + +Во время консолидации в другой валидатор исходный валидатор выходит, и существует ~27-часовой период ожидания, прежде чем баланс станет активным на целевом валидаторе. Этот период **не влияет на показатели производительности**. + +### Будут ли мне начислены штрафы? {#incur-penalties} + +Нет. Пока ваш валидатор находится в сети, вы не будете подвергаться штрафам. + +### Должны ли совпадать адреса вывода средств консолидируемых валидаторов? {#withdrawal-addresses-match} + +Нет. Но _источник_ должен авторизовать запрос со своего собственного адреса. + +### Будут ли мои вознаграждения накапливаться после преобразования? {#rewards-compound} + +Да. С учетными данными **типа 2** вознаграждения свыше 32 ETH автоматически рестейкаются, но не мгновенно. Из-за небольшого буфера (называемого [_гистерезисом_](https://eth2book.info/capella/part2/incentives/balances/#hysteresis)) ваш баланс должен достичь **примерно на 1,25 ETH больше**, прежде чем излишек будет рестейкнут. Так что вместо компаундинга при 33,0 ETH это происходит при 33,25 (эффективный баланс = 33 ETH), затем при 34,25 (эффективный баланс = 34 ETH) и так далее. + +### Смогу ли я по-прежнему получать автоматический вывод средств после преобразования? {#automatic-sweep} + +Автоматический вывод средств будет происходить только с избыточным балансом свыше 2048. Для всех остальных частичных выводов средств вам потребуется запускать их вручную. + +### Могу ли я передумать и вернуться с Типа 2 на Тип 1? {#go-back-to-type1} + +Нет. Переход на **Тип 2** необратим. + +### Если я хочу консолидировать несколько валидаторов, нужно ли мне сначала преобразовать каждый из них в Тип 2? {#consolidate-multiple-validators} + +Нет! Преобразуйте один валидатор в Тип 2, а затем используйте его в качестве цели. Все остальные валидаторы, консолидируемые в этот целевой валидатор типа 2, могут быть типа 1 или типа 2 + +### Мой валидатор не в сети или его баланс ниже 32 ETH — могу ли я все равно его преобразовать? {#offline-or-below-32eth} + +Да. Пока он активен (не вышел) и вы можете подписывать транзакции с его адреса вывода средств, вы можете его преобразовать. + +## Ресурсы {#resources} + +- [Спецификации консенсуса Electra](https://github.com/ethereum/consensus-specs/blob/dev/specs/electra/beacon-chain.md): это «самая верная» версия, на которую вам следует полагаться. Если сомневаетесь, читайте спецификации +- Не всем удобно разбираться в коде, поэтому [этот maxEB-GPT](https://chatgpt.com/g/g-67f1650fb48081918f555e0c8d1c2ae9-maxeb-gpt) может помочь в интерпретации спецификаций. _Отказ от ответственности: спецификации, а не ИИ, должны считаться истиной, поскольку ИИ может неверно истолковать информацию или сгенерировать вымышленные ответы_ +- [pectrified.com](https://pectrified.com/): просмотр состояния консолидаций, депозитов и времени ожидания в очереди +- [Ethereal](https://github.com/wealdtech/ethereal): созданный сообществом инструмент командной строки для управления общими задачами валидатора +- [batch-validator-depositor](https://github.com/attestantio/batch-validator-depositor): созданный сообществом контракт, который позволяет вносить депозиты для нескольких валидаторов Ethereum в одной транзакции diff --git a/public/content/translations/ru/roadmap/scaling/index.md b/public/content/translations/ru/roadmap/scaling/index.md index de03b4ba0a3..ddc8a14de68 100644 --- a/public/content/translations/ru/roadmap/scaling/index.md +++ b/public/content/translations/ru/roadmap/scaling/index.md @@ -1,18 +1,18 @@ --- -title: Масштабирования Ethereum -description: Свертки объединяют транзакции вместе вне цепи, уменьшая расходы пользователя. Однако сейчас свертки используют данные слишком дорогим способом, ограничивая удешевление транзакций. Прото-данкшардинг исправляет это. +title: "Масштабирования Ethereum" +description: "Свертки объединяют транзакции вместе вне цепи, уменьшая расходы пользователя. Однако сейчас свертки используют данные слишком дорогим способом, ограничивая удешевление транзакций. Прото-данкшардинг исправляет это." lang: ru image: /images/roadmap/roadmap-transactions.png alt: "Дорожная карта Ethereum" template: roadmap --- -Ethereum масштабируется с помощью сетей [уровня 2](/layer-2/#rollups) (также известными как свертки), которые собирают транзакции вместе и отправляют результат на Ethereum. Свертки до 8 раз дешевле основной сети Ethereum, но их можно оптимизировать еще лучше, чтобы снизить расходы для конечных пользователей. Они также полагаются на некоторые централизованные компоненты, которые разработчики могут удалять по мере развития свертков. +Ethereum масштабируется с помощью [сетей уровня 2](/layer-2/#rollups) (также известных как свертки), которые объединяют транзакции в пакеты и отправляют результат в Ethereum. Свертки до 8 раз дешевле основной сети Ethereum, но их можно оптимизировать еще лучше, чтобы снизить расходы для конечных пользователей. Они также полагаются на некоторые централизованные компоненты, которые разработчики могут удалять по мере развития свертков. - Расходы на транзакции + Стоимость транзакций
  • Сейчас свертки в 5–20 раз дешевле уровня 1 Ethereum.
    • @@ -27,30 +27,32 @@ Ethereum масштабируется с помощью сетей [уровня Свертки собирают большое количество транзакций, исполняют их и отправляют результаты в Ethereum. Это генерирует много данных, которые должны быть в открытом доступе, чтобы любой мог выполнить транзакции у себя и убедиться, что оператор свертка был честным. Если кто-то найдет несоответствие, он сможет начать оспаривание. -### Прото данкшардинг {#proto-danksharding} +### Протоданкшардинг {#proto-danksharding} Данные свертков хранятся на Ethereum на постоянной основе, что удорожает транзакции. Свыше 90 % расходов на транзакции, которые пользователи платят за свертки, идет на хранение этих данных. Для снижения стоимости транзакций мы можем перенести данные в новое временное хранилище BLOB-объектов. BLOB-объекты дешевле, потому что они непостоянные. Они удаляются из Ethereum, как только становятся ненужными. Длительное хранение данных свертков становится обязанностью операторов свертков, бирж, служб индексирования и прочих заинтересованных лиц. Добавление в Ethereum транзакций с BLOB-объектами — часть обновления под названием "протоданкшардинг". -Протоданкшардинг позволил добавлять в блоки Ethereum большое количество BLOB-объектов. Это позволило в очередной раз существенно (более чем в 100 раз) масштабировать пропускную способность Ethereum и сократить стоимость транзакций. +Протоданкшардинг позволил добавлять в блоки Ethereum большое количество BLOB-объектов. Это обеспечивает еще одно существенное (более чем в 100 раз) увеличение пропускной способности Ethereum и снижение стоимости транзакций. ### Данкшардинг {#danksharding} -Второй этап расширения данных BLOB-объектов сложен, поскольку он требует новых методов проверки того, доступны ли данные свертков в сети, и полагается на разделение обязанностей [валидаторов](/glossary/#validator) по созданию и предложению [блоков](/glossary/#block). Это также требует способ криптографически доказать, что валидаторы проверили небольшие подмножества данных BLOB-объектов. +Второй этап расширения данных в блобах сложен, так как требует новых методов для проверки доступности данных свертки в сети и зависит от разделения [валидаторами](/glossary/#validator) их обязанностей по созданию и предложению [блоков](/glossary/#block). Это также требует способ криптографически доказать, что валидаторы проверили небольшие подмножества данных BLOB-объектов. -Этот второй шаг называется [данкшардингом](/roadmap/danksharding/). Скорее всего, его полная реализация **займет несколько лет**. Данкшардинг опирается на другие разработки, такие как: [разделение создания и предложения блоков](/roadmap/pbs), и новые дизайны сети, позволяющие ей эффективно подтверждать, что данные доступны, путем случайного отбора нескольких килобайт. Это называется [выборкой доступности данных (DAS)](/developers/docs/data-availability). +Этот второй шаг известен как [«данкшардинг»](/roadmap/danksharding/). Работа над внедрением продолжается: есть прогресс по таким предварительным требованиям, как [разделение создания и предложения блоков](/roadmap/pbs) и новые архитектуры сети, которые позволяют сети эффективно подтверждать доступность данных путем случайной выборки нескольких килобайт за раз, известной как [выборка доступности данных (DAS)](/developers/docs/data-availability). Подробнее о данкшардинге -## Децентрализованные свертки {#decentralizing-rollups} +## Децентрализация сверток {#decentralizing-rollups} -[Свертки](/layer-2) уже масштабируют Ethereum. [Богатая экосистема проектов по сверткам](https://l2beat.com/scaling/tvl) позволяет пользователям быстро и дешево осуществлять транзакции с целым рядом гарантий безопасности. Тем не менее свертки были инициализированы с помощью централизованных секвенсоров (компьютеров, которые выполняют всю обработку и объединение транзакций перед их отправкой в Ethereum). Это создает уязвимость для цензуры, поскольку операторы-секвенсоры могут подпасть под санкции, быть подкупленными или иным образом скомпрометированными. В то же время [свертки отличаются](https://l2beat.com) по способу утверждения входящих данных. Лучше всего, когда проверяющие отправляют [доказательства мошенничества](/glossary/#fraud-proof) или достоверности, но еще не все свертки это поддерживают. Даже те свертки, что используют доказательства достоверности или мошенничества, полагаются на малый пул известных проверяющих. Поэтому следующим важным шагом в масштабировании Ethereum станет распределение ответственности за запуск секвенсоров и проверяющих среди большего числа людей. +[Свертки](/layer-2) уже масштабируют Ethereum. [Богатая экосистема проектов по сверткам](https://l2beat.com/scaling/tvs) позволяет пользователям быстро и дешево осуществлять транзакции с целым рядом гарантий безопасности. Тем не менее свертки были инициализированы с помощью централизованных секвенсоров (компьютеров, которые выполняют всю обработку и объединение транзакций перед их отправкой в Ethereum). Это создает уязвимость для цензуры, поскольку операторы-секвенсоры могут подпасть под санкции, быть подкупленными или иным образом скомпрометированными. В то же время [свертки различаются](https://l2beat.com/scaling/summary) по способу проверки входящих данных. Лучший способ для «пруверов» — отправлять [доказательства мошенничества](/glossary/#fraud-proof) или доказательства действительности, но пока не все свертки это реализовали. Даже те свертки, что используют доказательства достоверности или мошенничества, полагаются на малый пул известных проверяющих. Поэтому следующим важным шагом в масштабировании Ethereum станет распределение ответственности за запуск секвенсоров и проверяющих среди большего числа людей. Подробнее о свертках ## Текущий прогресс {#current-progress} -Протоданкшардинг является первым из этих пунктов дорожной карты, который будет реализован в рамках обновления сети Cancun-Deneb (Dencun) в марте 2024 года. **Полный данкшардинг, вероятно, будет реализован через несколько лет**, поскольку перед этим необходимо реализовать несколько других пунктов дорожной карты. Децентрализация инфраструктуры свертков, скорее всего, будет проходить поэтапно: существует множество разных свертков, которые создают немного разные системы, и они с разной скоростью станут полностью децентрализованными. +Протоданкшардинг был успешно реализован в рамках обновления сети Cancun-Deneb (Dencun) в марте 2024 года. С момента внедрения свертки начали использовать хранилище блобов, что привело к снижению стоимости транзакций для пользователей и обработке миллионов транзакций в блобах. -[Подробнее об обновлении сети Dencun](/roadmap/dencun/) +Продолжается работа над полным данкшардингом, и есть прогресс в его предварительных требованиях, таких как PBS (разделение создания и предложения блоков) и DAS (выборка доступности данных). Децентрализация инфраструктуры свертков проходит поэтапно: существует множество разных свертков, которые разрабатывают немного разные системы, и они с разной скоростью станут полностью децентрализованными. + +[Подробнее об обновлении сети Dencun и его влиянии](/roadmap/dencun/) diff --git a/public/content/translations/ru/roadmap/secret-leader-election/index.md b/public/content/translations/ru/roadmap/secret-leader-election/index.md index 1ba862d5745..31701a3c034 100644 --- a/public/content/translations/ru/roadmap/secret-leader-election/index.md +++ b/public/content/translations/ru/roadmap/secret-leader-election/index.md @@ -1,6 +1,6 @@ --- -title: Выборы тайного лидера -description: Объяснение того, как выбор тайного лидера может помочь защитать валидаторы от атак +title: "Выборы тайного лидера" +description: "Объяснение того, как выбор тайного лидера может помочь защитать валидаторы от атак" lang: ru summaryPoints: - IP-адрес предлагающих блоки можно узнать заранее, что делает их уязвимыми для атак. @@ -8,13 +8,13 @@ summaryPoints: - Развитие этой идеи — сделать выбор валидатора случайным в каждой ячейке. --- -# Выборы тайного лидера {#single-secret-leader-election} +# Выбор тайного лидера {#single-secret-leader-election} -В сегодняшнем механизме консенсуса, основанном на [доказательстве владения](/developers/docs/consensus-mechanisms/pos), список ближайших предлагающих блоки является общедоступным, можно составить карту их IP-адресов. Это означает, что злоумышленники могут определить, какие валидаторы должны предложить блок, и нацелить на них атаку типа «отказ в обслуживании» (DOS-атаку), которая не позволяет им предложить свой блок вовремя. +В сегодняшнем механизме консенсуса, основанном на [доказательстве владения (proof-of-stake)](/developers/docs/consensus-mechanisms/pos), список следующих предлагающих блоки является общедоступным, и можно определить их IP-адреса. Это означает, что злоумышленники могут определить, какие валидаторы должны предложить блок, и нацелить на них атаку типа «отказ в обслуживании» (DOS-атаку), которая не позволяет им предложить свой блок вовремя. Это может дать злоумышленнику возможность получить прибыль. Например, предлагающий блок, выбранный для слота `n+1`, может провести DOS-атаку на предлагающего в слоте `n`, чтобы тот упустил возможность предложить блок. Это позволило бы предлагающему блок, совершающему атаку, извлечь MEV обоих слотов или захватить все транзакции, которые должны были быть разделены на два блока, и вместо этого включить их все в один, получая все связанные комиссии. Скорее всего, это больше влияет на домашних валидаторов, чем на опытных институциональных, которые могут использовать более передовые методы для защиты от DOS-атак и, таким образом, стать централизирующей силой. -Существуют несколько решений этой проблемы. Одно из них — [технология распределенного валидатора](https://github.com/ethereum/distributed-validator-specs), которая направлена на распределение различных задач, связанных с выполнением кода валидатора, по нескольким машинам с избыточностью, так что злоумышленнику гораздо труднее будет предотвратить предложение блока в конкретную ячейку. Однако самым надежным решением является **выбор одного тайного лидера (SSLE)**. +Существуют несколько решений этой проблемы. Одним из них является [технология распределенного валидатора (Distributed Validator Technology)](https://github.com/ethereum/distributed-validator-specs), цель которой — распределить различные задачи, связанные с работой валидатора, по нескольким машинам с избыточностью, чтобы злоумышленнику было гораздо сложнее предотвратить предложение блока в определенном слоте. Однако самым надежным решением является **выбор одного тайного лидера (SSLE)**. ## Выбор одного тайного лидера {#secret-leader-election} @@ -31,14 +31,14 @@ summaryPoints: Это мешает злоумышленникам заранее узнать, какой конкретный валидатор предложит следующий блок, предотвращая возможность DOS-атак. -## Выбор не единственного тайного лидера (SnSLE) {#secret-non-single-leader-election} +## Выбор нескольких тайных лидеров (SnSLE) {#secret-non-single-leader-election} -Существует также отдельное предложение, направленное на создание сценария, при котором каждый из валидаторов имеет случайный шанс предложить блок в каждом слоте, подобно тому, как предложение блока определялось при доказательстве работы. Это называется **выбором нескольких тайных лидеров (SnSLE)**. Один из простых способов реализовать это — использовать функцию RANDAO, применяемую для случайного выбора валидаторов в действующем сейчас протоколе. Идея с RANDAO заключается в том, что достаточно случайное число генерируется путем смешивания хэшей, представленных многими независимыми валидаторами. При SnSLE эти хэши можно использовать для выбора следующего предлагающего блок, например выбрав хэш с самым низким значением. Диапазон допустимых хэшей может быть ограничен для настройки вероятности выбора отдельных валидаторов в каждом слоте. Предполагая, что хэш должен быть меньше, чем `2^256 * 5 / N`, где `N` = число активных валидаторов, шанс любого отдельного валидатора быть выбранным в каждом слоте будет равен `5/N`. В этом примере есть вероятность 99,3 %, что по крайней мере один предлагающий сгенерирует действительный хэш в каждой ячейке. +Существует также отдельное предложение, направленное на создание сценария, при котором у каждого валидатора есть случайный шанс предложить блок в каждом слоте, подобно тому как предложение блока определялось при доказательстве работы (proof-of-work), что известно как **выбор нескольких тайных лидеров (SnSLE)**. Один из простых способов реализовать это — использовать функцию RANDAO, применяемую для случайного выбора валидаторов в действующем сейчас протоколе. Идея с RANDAO заключается в том, что достаточно случайное число генерируется путем смешивания хэшей, представленных многими независимыми валидаторами. При SnSLE эти хэши можно использовать для выбора следующего предлагающего блок, например выбрав хэш с самым низким значением. Диапазон допустимых хэшей может быть ограничен для настройки вероятности выбора отдельных валидаторов в каждом слоте. Утверждая, что хэш должен быть меньше `2^256 * 5 / N`, где `N` = количество активных валидаторов, шанс любого отдельного валидатора быть выбранным в каждом слоте будет равен `5/N`. В этом примере есть вероятность 99,3 %, что по крайней мере один предлагающий сгенерирует действительный хэш в каждой ячейке. ## Текущий прогресс {#current-progress} SSLE и SnSLE находятся в стадии исследования. Окончательных спецификаций ни для одной из этих идей пока нет. SSLE и SnSLE — конкурирующие предложения, которые не могут быть реализованы вместе. Перед внедрением они нуждаются в дополнительных исследованиях и разработках, прототипировании и реализации в общедоступных тестовых сетях. -## Дополнительная литература {#further-reading} +## Дополнительные материалы {#further-reading} - [SnSLE](https://ethresear.ch/t/secret-non-single-leader-election/11789) diff --git a/public/content/translations/ru/roadmap/security/index.md b/public/content/translations/ru/roadmap/security/index.md index f66e0ed1b8d..573e2ba02e6 100644 --- a/public/content/translations/ru/roadmap/security/index.md +++ b/public/content/translations/ru/roadmap/security/index.md @@ -1,48 +1,48 @@ --- -title: Более безопасный Ethereum -description: Ethereum — самая безопасная и децентрализованная платформа для смарт-контрактов из существующих. Однако потребуется еще ряд улучшений, чтобы в будущем Ethereum оставался устойчивым к любому уровню атак. +title: "Более безопасный Ethereum" +description: "Ethereum — самая безопасная и децентрализованная платформа для смарт-контрактов из существующих. Однако потребуется еще ряд улучшений, чтобы в будущем Ethereum оставался устойчивым к любому уровню атак." lang: ru image: /images/roadmap/roadmap-security.png alt: "Дорожная карта Ethereum" template: roadmap --- -**Ethereum уже является очень безопасной** и децентрализованной платформой для [смарт-контрактов](/glossary/#smart-contract). Однако потребуется еще ряд улучшений, чтобы в будущем Ethereum оставался устойчивым ко всем типам атак. Это мелкие изменения работы [клиентов Ethereum](/glossary/#consensus-client) с конкурирующими [блоками](/glossary/#block), а также увеличение скорости [финализации](/developers/docs/consensus-mechanisms/pos/#finality) блоков (после которой их нельзя изменить без значительных экономических потерь для злоумышленника). +**Ethereum уже является очень безопасной**, децентрализованной платформой для [смарт-контрактов](/glossary/#smart-contract). Однако потребуется еще ряд улучшений, чтобы в будущем Ethereum оставался устойчивым ко всем типам атак. Сюда относятся незначительные изменения в том, как [клиенты Ethereum](/glossary/#consensus-client) обрабатывают конкурирующие [блоки](/glossary/#block), а также увеличение скорости, с которой сеть считает блоки [«завершенными»](/developers/docs/consensus-mechanisms/pos/#finality) (то есть они не могут быть изменены без значительных экономических потерь для атакующего). -Есть также улучшения, которые значительно затрудняют цензурирование транзакций, не позволяя предлагающим блоки видеть их содержимое, и новые способы выявления случаев, когда клиент занимается цензурой. Вместе эти улучшения модернизируют протокол [доказательства доли владения](/glossary/#pos) таким образом, что пользователи — от физических лиц до корпораций — сразу были уверенными в своих приложениях, данных и активах на Ethereum. +Есть также улучшения, которые значительно затрудняют цензурирование транзакций, не позволяя предлагающим блоки видеть их содержимое, и новые способы выявления случаев, когда клиент занимается цензурой. В совокупности эти улучшения обновят протокол [доказательства доли владения](/glossary/#pos), чтобы пользователи — от частных лиц до корпораций — могли быть мгновенно уверены в своих приложениях, данных и активах на Ethereum. -## Вывод средств, использованных в стейкинге {#staking-withdrawals} +## Вывод средств из стейкинга {#staking-withdrawals} -Переход от [доказательства выполнения работы](/glossary/#pow) к доказательству доли владения начался со стейкинга ETH в депозитном контракте. Этот ЕТН используется для защиты сети. Второе обновление, выпущенное 12 апреля 2023 года, позволило выводить ETH из стейкинга. С того времени валидаторы могут свободно размещать и выводить ETH из стейкинга. +Переход с [доказательства работы](/glossary/#pow) на доказательство доли владения начался, когда первопроходцы Ethereum начали размещать («стейкать») свои ETH в депозитном контракте. Этот ЕТН используется для защиты сети. Второе обновление, выпущенное 12 апреля 2023 года, позволило выводить ETH из стейкинга. С того времени валидаторы могут свободно размещать и выводить ETH из стейкинга. Подробнее о выводе средств ## Защита от атак {#defending-against-attacks} -Протокол доказательства доли владения Ethereum можно улучшить. Одним из таких улучшений является [view-merge](https://ethresear.ch/t/view-merge-as-a-replacement-for-proposer-boost/13739) — более безопасный алгоритм выбора [ответвления](/glossary/#fork), который усложняет некоторые сложные типы атак. +Протокол доказательства доли владения Ethereum можно улучшить. Один из них известен как [view-merge](https://ethresear.ch/t/view-merge-as-a-replacement-for-proposer-boost/13739) — более безопасный алгоритм выбора [форка](/glossary/#fork), который усложняет определенные изощренные типы атак. -Ускорение [финализации](/glossary/#finality) блоков в Ethereum повысит удобство для пользователей и предотвратит сложные атаки reorg, когда злоумышленники пытаются перемешать самые последние блоки для извлечения прибыли или цензурирования определенных транзакций. Для этого нужно реализовать [**финализацию в одном слоте (SSF)**](/roadmap/single-slot-finality/) ****. Сейчас атакующий в теории может убедить других валидаторов переконфигурировать все блоки, которые были созданы за последние 15 минут. С использованием SSF это окно было бы сведено к 0. Пользователи, начиная от физических лиц и заканчивая приложениями и биржами, выигрывают от быстрой гарантии того, что их транзакции не будут возвращены. Выиграет и сеть, избавляясь от целого класса атак. +Сокращение времени, необходимого Ethereum для [завершения](/glossary/#finality) блоков, улучшит пользовательский опыт и предотвратит сложные атаки «реорганизации», когда злоумышленники пытаются перетасовать самые последние блоки для извлечения прибыли или цензуры определенных транзакций. [**Завершенность одного слота (SSF)**](/roadmap/single-slot-finality/) — это **способ минимизировать задержку завершения**. Сейчас атакующий в теории может убедить других валидаторов переконфигурировать все блоки, которые были созданы за последние 15 минут. С использованием SSF это окно было бы сведено к 0. Пользователи, начиная от физических лиц и заканчивая приложениями и биржами, выигрывают от быстрой гарантии того, что их транзакции не будут возвращены. Выиграет и сеть, избавляясь от целого класса атак. Подробнее о завершенности одного слота ## Защита от цензуры {#defending-against-censorship} -Децентрализация не позволяет отдельным лицам или небольшим группам [валидаторов](/glossary/#validator) стать слишком влиятельными. Новые технологии стейкинга могут помочь обеспечивать максимально возможную децентрализацию валидаторов в Ethereum, одновременно защищая их от аппаратных, программных и сетевых сбоев. Сюда относится программное обеспечение, которое распределяет обязанности валидатора между несколькими [узлами](/glossary/#node). Это известно как **технология распределенного валидатора (DVT)**. [Пулы стейкинга](/glossary/#staking-pool) заинтересованы в использовании DVT, поскольку это позволяет нескольким компьютерам коллективно участвовать в валидации, добавляя избыточности и отказоустойчивости. Она также распределяет ключи валидатора между несколькими системами вместо того, чтобы один оператор запускал несколько валидаторов. Благодаря этому нечестным операторам труднее проводить скоординированные атаки на Ethereum. В целом идея заключается в получении преимуществ для безопасности за счет запуска валидаторов как _сообществ_, а не как отдельных лиц. +Децентрализация не позволяет отдельным лицам или небольшим группам [валидаторов](/glossary/#validator) становиться слишком влиятельными. Новые технологии стейкинга могут помочь обеспечивать максимально возможную децентрализацию валидаторов в Ethereum, одновременно защищая их от аппаратных, программных и сетевых сбоев. Это включает в себя программное обеспечение, которое распределяет обязанности валидатора между несколькими [узлами](/glossary/#node). Это известно как **технология распределенного валидатора (DVT)**. [Стейкинг-пулы](/glossary/#staking-pool) заинтересованы в использовании DVT, поскольку это позволяет нескольким компьютерам коллективно участвовать в валидации, добавляя избыточность и отказоустойчивость. Она также распределяет ключи валидатора между несколькими системами вместо того, чтобы один оператор запускал несколько валидаторов. Благодаря этому нечестным операторам труднее проводить скоординированные атаки на Ethereum. В целом идея заключается в получении преимуществ для безопасности за счет запуска валидаторов как _сообществ_, а не как отдельных лиц. Подробнее о технологии распределенного валидатора -Внедрение **разделения между инициаторами и строителями блоков (PBS)** значительно улучшит защиту Ethereum от цензуры. PBS позволяет одному валидатору создать блок, а другому — передать его в сеть Ethereum. Это гарантирует, что прибыль от профессиональных алгоритмов построения блоков, максимизирующих прибыль, более справедливо распределяется по всей сети, **предотвращая концентрацию ставок** у наиболее эффективных институциональных игроков. Предлагающий выбирает самый прибыльный блок, предложенный ему рынком строителей блоков. Чтобы подвергнуть содержание блока цензуре, предлагающему будет необходимо выбрать менее прибыльный блок, что будет **экономически нерационально и очевидно для остальных валидаторов** в сети. +Внедрение **разделения предлагающего и сборщика (PBS)** значительно улучшит встроенную защиту Ethereum от цензуры. PBS позволяет одному валидатору создать блок, а другому — передать его в сеть Ethereum. Это гарантирует, что доходы от профессиональных алгоритмов создания блоков, нацеленных на максимизацию прибыли, будут более справедливо распределяться по сети, **предотвращая концентрацию долей** у самых эффективных институциональных стейкеров с течением времени. Предлагающий выбирает самый прибыльный блок, предложенный ему рынком строителей блоков. Чтобы прибегнуть к цензуре, предлагающему блок часто приходится выбирать менее прибыльный блок, что было бы **экономически нерационально, а также очевидно для остальных валидаторов** в сети. Существуют возможные дополнения к PBS, такие как зашифрованные транзакции и списки вхождений, которые могут еще больше повысить устойчивость Ethereum к цензуре. Благодаря им предлагающие и строители блоков не смогут увидеть содержание транзакций, включаемых в блок. -Подробнее о разделении предлагающих и строителей +Подробнее о разделении предлагающего и сборщика ## Защита валидаторов {#protecting-validators} -Возможно, что опытный злоумышленник мог бы идентифицировать будущих валидаторов и заваливать их спамом, чтобы помешать им предлагать блоки. Такой вид атаки называется **«отказом в обслуживании»‎ (DoS-атакой)**. Внедрение [**тайного выбора лидера (SLE)**](/roadmap/secret-leader-election) сможет защитить от таких атак, не позволяя заранее получать информацию о том, кто будет предлагать следующие блоки. Такой результат получается путем постоянного перетасовывания набора криптографических обязательств, которые представляют предлагающих блоки, и использования их порядка для определения того, какой валидатор выбран, таким образом, что только сами валидаторы заранее знают свой порядок. +Возможно, что изощренный злоумышленник сможет определить будущих валидаторов и заспамить их, чтобы помешать им предлагать блоки; это известно как атака **типа «отказ в обслуживании» (DoS)**. Внедрение [**тайного выбора лидера (SLE)**](/roadmap/secret-leader-election) защитит от этого типа атак, не позволяя заранее узнать, кто будет предлагать блоки. Такой результат получается путем постоянного перетасовывания набора криптографических обязательств, которые представляют предлагающих блоки, и использования их порядка для определения того, какой валидатор выбран, таким образом, что только сами валидаторы заранее знают свой порядок. -Подробнее о выборе тайного лидера +Подробнее о тайном выборе лидера ## Текущий прогресс {#current-progress} -**Обновления безопасности, предусмотренные дорожной картой, находятся на поздних стадиях исследования**, но их внедрение займет некоторое время. Следующими шагами для слияния мнений, PBS, SSF и SLE являются завершение разработки спецификации и начало создания прототипов. +**Обновления безопасности, предусмотренные дорожной картой, находятся на поздних стадиях исследования, но их внедрение займет некоторое время.** Следующие шаги для view-merge, PBS, SSF и SLE — это завершение разработки спецификации и начало создания прототипов. diff --git a/public/content/translations/ru/roadmap/single-slot-finality/index.md b/public/content/translations/ru/roadmap/single-slot-finality/index.md index 6cbb86b11b1..b10b686a1bb 100644 --- a/public/content/translations/ru/roadmap/single-slot-finality/index.md +++ b/public/content/translations/ru/roadmap/single-slot-finality/index.md @@ -1,12 +1,12 @@ --- -title: Завершенность одного слота -description: Объяснение завершенности одного слота +title: "Завершенность одного слота" +description: "Объяснение завершенности одного слота" lang: ru --- -# Завершенность одного слота {#single-slot-finality} +# Финальность одного слота {#single-slot-finality} -Для завершения блока Ethereum требуется около 15 минут. Однако мы можем сделать валидацию блоков механизмом консенсуса Ethereum более эффективной и радикально сократить время на завершение. Вместо ожидания по пятнадцать минут блоки могут предлагаться и завершаться в одном слоте. Этот концепт называют **завершенностью одного слота (SSF)**. +Для завершения блока Ethereum требуется около 15 минут. Однако мы можем сделать валидацию блоков механизмом консенсуса Ethereum более эффективной и радикально сократить время на завершение. Вместо ожидания по пятнадцать минут блоки могут предлагаться и завершаться в одном слоте. Эта концепция известна как **финальность одного слота (SSF)**. ## Что такое окончательность? {#what-is-finality} @@ -16,9 +16,9 @@ lang: ru Сейчас завершение занимает слишком много времени. Большинство пользователей не хотят ждать 15 минут для завершения, и это неудобно для приложений и обменников, которые хотели бы ускорить пропускную способность транзакций, а не ждать так долго из утверждения. Задержка между предложением блока и завершением также создает возможность для быстрых реорганизаций, которые атакующий может использовать для цензурирования некоторых блоков или экстракции MEV. Механизм, который используется для обновления блоков по этапам, также довольно сложный и несколько раз исправлялся для закрытия уязвимостей. Это делает его той частью кода Ethereum, где сопутствующих ошибок, вероятно, будет становиться только больше. Эти недостатки могут быть устранены, если время на завершение будет сокращено до одного слота. -## Компромисс между децентрализацией, временем и расходами {#the-decentralization-time-overhead-tradeoff} +## Компромисс между децентрализацией, временем и дополнительными издержками {#the-decentralization-time-overhead-tradeoff} -Гарантия завершенности — это не мгновенно возникающее качество нового блока. Требуется время, чтобы новый блок был завершен. Причина в том, что валидаторы, представляющие по крайней мере 2/3 суммарно поставленных ETH в сети, должны голосовать за блок («подтверждать») по порядку, чтобы завершить его. Каждый узел валидатора в сети должен обработать подтверждения от других узлов по порядку, чтобы узнать, достиг блок или нет порога в 2/3. +Гарантия завершенности — это не мгновенно возникающее качество нового блока. Требуется время, чтобы новый блок был завершен. Причина в том, что валидаторы, представляющие не менее 2/3 от общего количества ETH в стейкинге в сети, должны проголосовать за блок ("аттестовать"), чтобы он считался финализированным. Каждый узел валидатора в сети должен обработать подтверждения от других узлов по порядку, чтобы узнать, достиг блок или нет порога в 2/3. Чем меньше времени доступно на достижение завершенности, тем больше вычислительных мощностей необходимо каждому узлу, потому что процесс подтверждения тогда должен выполняться быстрее. Кроме того, чем больше узлов валидаторов присутствуют в сети, тем больше подтверждений должно быть обработано в каждом блоке, что дополнительно увеличивает требования к вычислительным мощностям. Чем больше нужно вычислений, тем меньше людей могут участвовать, потому что для запуска каждого узла валидатора требуется все более дорогостоящее оборудование. Увеличение времени между блоками уменьшает требования к вычислительным мощностям каждого узла, но также удлиняет время на завершение, потому что подтверждения обрабатываются медленнее. @@ -31,36 +31,36 @@ lang: ru При текущем механизме для сокращения времени на финализацию важно снизить количество валидаторов в сети или повысить требования к оборудованию для каждого узла. Так или иначе, способ обработки подтверждений можно улучшить, что позволит подсчитывать больше подтверждений без добавления стоимости к обслуживанию каждого узла. Более эффективная обработка позволит осуществлять завершение в пределах одного слота, а не за две эпохи. -## Пути к завершенности одного слота {#routes-to-ssf} +## Пути к SSF {#routes-to-ssf} - + Текущий механизм консенсуса объединяет подтверждения от нескольких валидаторов, известных как «комитеты», чтобы снизить количество сообщений, которые каждый валидатор должен обработать для валидации блока. У каждого валидатора есть возможность подтверждать блоки в каждой эпохе (32 слота), но в каждом слоте утверждает блоки только набор валидаторов, известный как «комитет». Это реализуется путем разделения на подгруппы, где в каждой несколько валидаторов избираются на роль «агрегаторов». Агрегаторы могут объединять все подписи, которые они видят исходящими от других валидаторов, в свою подсеть и единую аггрегированную подпись. Агрегатор, который включил наибольшее количество частных записей, отправляет свою подпись агрегатора предлагающему блок, который включает ее в блок вместе с агрегированными подписями от других комитетов. -Этот процесс обеспечивает достаточную пропускную способность, чтобы каждый валидатор мог голосовать в каждой эпохе, потому что 32 слота * 64 комитета * 256 валидаторов в комитете = 524 288 валидаторов на эпоху. На момент написания (февраль 2023 г.) всего есть ~513 000 активных валидаторов. +Этот процесс обеспечивает достаточную пропускную способность, чтобы каждый валидатор мог голосовать в каждой эпохе, потому что 32 слота \* 64 комитета \* 256 валидаторов в комитете = 524 288 валидаторов на эпоху. На момент написания (февраль 2023 г.) всего есть ~513 000 активных валидаторов. При таком сценарии каждый валидатор может голосовать за блок, только если он распространяет свои подтверждения на протяжении всей эпохи. Однако есть потенциальные способы улучшить этот механизм, так что каждый валидатор получит шанс подтверждать в каждом слоте. С тех пор, как был разработан механизм консенсуса Ethereum, схема агрегации подписей (BLS) была признана более масштабируемой, чем предполагалось изначально. Возможности клиентов по обработке и верификации подписей также были расширены. Это приводит к тому, что обработка подтверждений от огромного количества валидаторов реально возможна в одном слоте. Например, если один миллион валидаторов голосует дважды в каждом слоте, а время слота установлено на 16 секунд, узлам потребуется верифицировать подписи со скоростью как минимум 125 000 агрегаций в секунду, чтобы обработать весь миллион подтверждений в рамках слота. В реальности обычному компьютеру нужно около 500 наносекунд, чтобы произвести одну верификацию подписи. Следовательно, 125 000 могут быть выполнены примерно за 62,5 мс, что сильно меньше порога в одну секунду. -Дальнейший прирост эффективности может быть достигнут за счет создания суперкомитетов, например состоящих из 125 000 случайно выбранных валидаторов на слот. Только эти валидаторы должны голосовать за блок, и потому только этот набор валидаторов решает, будет ли блок завершен. Хороша эта идея или нет, зависит от того, насколько дорогой по мнению сообщества Ethereum должна быть успешная атака на сеть. Все потому, что вместо требуемых 2/3 от всего эфира в стейкинге атакующий мог бы завершить нечестный блок с 2/3 поставленного эфира _в своем суперкомитете_. Это все еще активная область для исследований, но решение кажется приемлемым, ведь для такого огромного количества валидаторов, находящихся в суперкомитете, атака будет стоить слишком дорого (например, в пересчете на ETH стоимость атаки составит `2/3 * 125 000 * 32 = ~2,6 миллиона ETH`). Увеличивая количество валидаторов в наборе, можно регулировать стоимость атаки (например, задать такое количество валидаторов, чтобы атака стоила 1, 4, 10 миллионов эфиров и так далее). [Предвраительные опросы](https://youtu.be/ojBgyFl6-v4?t=755) сообщества показывают, что 1–2 миллиона эфиров считаются приемлемой стоимостью атаки, что означает примерно от 65 536 до 97 152 валидаторов на суперкомитет. +Дальнейший прирост эффективности может быть достигнут за счет создания суперкомитетов, например состоящих из 125 000 случайно выбранных валидаторов на слот. Только эти валидаторы должны голосовать за блок, и потому только этот набор валидаторов решает, будет ли блок завершен. Хороша эта идея или нет, зависит от того, насколько дорогой по мнению сообщества Ethereum должна быть успешная атака на сеть. Это происходит потому, что вместо требуемых 2/3 от общего количества эфира в стейкинге, злоумышленник мог бы финализировать нечестный блок с 2/3 эфира в стейкинге _в этом суперкомитете_. Это по-прежнему активная область исследований, но кажется правдоподобным, что для набора валидаторов, достаточно большого, чтобы требовались суперкомитеты, стоимость атаки на один из этих подкомитетов будет чрезвычайно высокой (например, стоимость атаки в ETH составит `2/3 * 125,000 * 32 = ~2,6 млн ETH`). Стоимость атаки можно регулировать, увеличивая размер набора валидаторов (например, можно настроить размер набора так, чтобы стоимость атаки равнялась 1, 4, 10 миллионам эфира и т. д.). [Предварительные опросы](https://youtu.be/ojBgyFl6-v4?t=755) сообщества показывают, что 1–2 миллиона эфира — это приемлемая стоимость атаки, что подразумевает ~65 536 – 97 152 валидаторов на суперкомитет. -Однако, верификация — это не главная сложность. Реальный вызов для узлов валидаторов — агрегация сигнатур. Чтобы масштабировать агрегацию сигнатур, вероятно, потребуется увеличить количество валидаторов в каждой подсети, увеличить количество подсетей или добавить дополнительные уровни аггрегации (то есть ввести комитеты комитетов). Частично решением может стать допуск специализированных агрегаторов — подобно тому, как строительство блоков и генерация подтверждений для данных свертков будут переданы специализированным строителям блоков в рамках разделения предлагающих и строящих (PBS) и данкшардинга. +Однако, верификация — это не главная сложность. Реальный вызов для узлов валидаторов — агрегация сигнатур. Чтобы масштабировать агрегацию сигнатур, вероятно, потребуется увеличить количество валидаторов в каждой подсети, увеличить количество подсетей или добавить дополнительные уровни агрегации (то есть ввести комитеты комитетов). Частично решением может стать допуск специализированных агрегаторов — подобно тому, как строительство блоков и генерация подтверждений для данных свертков будут переданы специализированным строителям блоков в рамках разделения предлагающих и строящих (PBS) и данкшардинга. ## Какова роль у правила выбора ответвления в SSF? {#role-of-the-fork-choice-rule} -Сегодня механизм консенсуса зависит от тесного сопряжения между устройством завершенности (алгоритм, который определяет, подтвердили ли 2/3 валидаторов определенную цепочку) и правилом выбора ответвления (алгоритм, который решает, какая цепочка верна, когда есть несколько вариантов на выбор). Алгоритм выбора ответвления учитывает только блоки _после_ последнего завершенного блока. При применении SSF правилу выбора ответвления будет не из чего выбирать, потому что завершение происходит в том же слоте, где был предложен блок. Это значит, что при SSF в любой момент будет активен _или_ алгоритм выбора ответвления, _или_ устройство завершения. Устройство завершения будет заверщать блоки, когда 2/3 валидаторов будут онлайн и честно выполнят подтверждение. Если блок не сможет преодолеть порог в 2/3, правило выбора ответвления сработает, чтобы определить, какой цепочке следовать. Это также создает возможность поддерживать механизм утечки неактивности, который восстанавливает сеть, когда более 1/3 валидаторов уходят в офлайн, хотя и с некоторыми дополнительными нюансами. +Сегодня механизм консенсуса зависит от тесного сопряжения между устройством завершенности (алгоритм, который определяет, подтвердили ли 2/3 валидаторов определенную цепочку) и правилом выбора ответвления (алгоритм, который решает, какая цепочка верна, когда есть несколько вариантов на выбор). Алгоритм выбора форка учитывает только блоки, созданные _после_ последнего финализированного блока. При применении SSF правилу выбора ответвления будет не из чего выбирать, потому что завершение происходит в том же слоте, где был предложен блок. Это означает, что при использовании SSF в любой момент времени будет активен _либо_ алгоритм выбора форка, _либо_ гаджет финальности. Устройство завершения будет заверщать блоки, когда 2/3 валидаторов будут онлайн и честно выполнят подтверждение. Если блок не сможет преодолеть порог в 2/3, правило выбора ответвления сработает, чтобы определить, какой цепочке следовать. Это также создает возможность поддерживать механизм утечки неактивности, который восстанавливает сеть, когда более 1/3 валидаторов уходят в офлайн, хотя и с некоторыми дополнительными нюансами. -## Нерешенные вопросы {#outstanding-issues} +## Нерешенные проблемы {#outstanding-issues} Проблема масштабирования агрегации за счет увеличения количества валидаторов в подсети заключается в том, что при этом увеличивается нагрузка на одноранговую сеть. Проблема с добавлением уровней агрегации в том, что это сложно реализуется в инженерном плане и добавляет задержку (то есть требуется больше времени, чтобы предлагающий блок мог получить данные от всех агрегаторов подсетей). Также непонятно, как справиться с ситуацией, когда активных валидаторов доступно больше, чем сеть может обработать в каждом слоте даже при наличии агрегации подписей BLS. Одно из потенциальных решений: поскольку все валидаторы участвуют в подтверждении в каждом слоте и нет комитетов, а при SSF нет комитетов, ограничение эффективного баланса в 32 ETH может быть полностью снято, позволяя операторам, управляющим несколькими валидаторами, объединять их стейк и запускать меньше узлов, снижая количество сообщений, которые узлы валидаторов должны обработать и учесть во всем наборе валидаторов. Это потребует от крупных дольщиков согласия объединить свои валидаторы. Также возможно установить фиксированный лимит на количество валидаторов и сумму ETH в стейкинге в каждый момент времени. Тем не менее, это требует создания механизма, который будет решать, какие валидаторы могут быть допущены к участию, а какие — нет, что может привести к нежелательным побочным эффектам. ## Текущий прогресс {#current-progress} -SSF находится на стадии исследования. Это нововведение вряд ли выйдет в течение следующих лет. Вероятно, оно станет возможным только после других существенных обновлений, таких как [деревья Веркла](/roadmap/verkle-trees/) и [данкшардинг](/roadmap/danksharding/). +SSF находится на стадии исследования. Ожидается, что это обновление будет выпущено лишь через несколько лет, вероятно, после других существенных обновлений, таких как [деревья Веркла](/roadmap/verkle-trees/) и [данкшардинг](/roadmap/danksharding/). -## Дополнительная литература {#further-reading} +## Дополнительные материалы {#further-reading} -- [Виталик об SSF на EDCON 2022](https://www.youtube.com/watch?v=nPgUKNPWXNI) -- [Заметки Виталика: пути к завершенности одного слота](https://notes.ethereum.org/@vbuterin/single_slot_finality) +- [Виталик о SSF на EDCON 2022](https://www.youtube.com/watch?v=nPgUKNPWXNI) +- [Заметки Виталика: пути к финальности одного слота](https://notes.ethereum.org/@vbuterin/single_slot_finality) diff --git a/public/content/translations/ru/roadmap/statelessness/index.md b/public/content/translations/ru/roadmap/statelessness/index.md index b3bddae1d6c..ebb8f14c87a 100644 --- a/public/content/translations/ru/roadmap/statelessness/index.md +++ b/public/content/translations/ru/roadmap/statelessness/index.md @@ -1,10 +1,10 @@ --- -title: Клиенты без состояния, экспирация состояний и истории -description: Что такое экспирация истории и Ethereum с клиентами без состояния +title: "Клиенты без состояния, экспирация состояний и истории" +description: "Что такое экспирация истории и Ethereum с клиентами без состояния" lang: ru --- -# Клиенты без состояния, экспирация состояний и истории {#statelessness} +# Безсостоятельность, истечение срока действия состояния и истории {#statelessness} Возможность запускать узлы Ethereum на недорогом оборудовании важна для настоящей децентрализации. Причина в том, что активный узел дает пользователям возможность верифицировать информацию, выполняя криптографические проверки независимо, без использования для этого источников третьих лиц, которым нужно было бы доверять. Поддерживание работы узла позволяет всем публиковать транзакции напрямую в одноранговой сети Ethereum без необходимости доверять посредникам. Децентрализации не будет, если эти преимущества будут доступны только пользователям с дорогостоящим оборудованием. Узлы должны иметь возможность работать с самыми скромными вычислительными мощностями и размерами памяти, чтобы запускать их можно было даже с мобильных телефонов, микрокомпьютеров и, разумеется, домашних ПК. @@ -12,18 +12,18 @@ lang: ru Дешевые жесткое диски могут быть использованы для хранения старых данных, но они слишком медленны, чтобы справляться с записью поступающих новых блоков. Оставить текущие модели хранения в клиентах, но сделать хранение данных дешевле и проще — это единственное компромиссное и временное решение проблемы безгранично растущего состояния Ethereum. Объем занимаемой памяти будет только расти, а технологические усовершенствования будут всегда должны успевать за непрерывным ростом состояния. Клиенты должны найти новые способы верификации блоков и транзакций, которые не зависят от обращений к старым данным в локальных базах. -## Уменьшение размеров хранилища для узлов {#reducing-storage-for-nodes} +## Уменьшение объема хранилища для узлов {#reducing-storage-for-nodes} Существует несколько способов уменьшить объем данных, которые должен хранить каждый узел, и все они требуют обновления основного протокола Ethereum в разной степени. -- **Экспирация (истечение срока действия) истории**: позволяет узлам избавляться от данных о состоянии более чем на Х блоков назад. При этом то, как клиент Ethereum обрабатывает данные о состоянии, не меняется. -- **Экспирация состояния**: позволяет деактивировать данные о состоянии, которые используются редко. Неактивные данные могут игнорироваться клиентами, пока не будут восстановлены. -- **Слабое отсутствие состояния**: только производители блоков нуждаются в доступе ко всем данным о состоянии, остальные узлы могут верифицировать блоки без локальной базы данных о нем. -- **Сильное отсутствие состояния**: никаким узлам не требуется доступ ко всем данным о состоянии. +- **Истечение срока действия истории**: позволяет узлам отбрасывать данные состояния, которые старше X блоков, но не меняет то, как клиент Ethereum обрабатывает данные состояния. +- **Истечение срока действия состояния**: позволяет деактивировать редко используемые данные о состоянии. Неактивные данные могут игнорироваться клиентами, пока не будут восстановлены. +- **Слабая безсостоятельность**: только производители блоков нуждаются в доступе ко всем данным о состоянии, остальные узлы могут верифицировать блоки без локальной базы данных о состоянии. +- **Сильная безсостоятельность**: ни одному узлу не требуется доступ ко всем данным о состоянии. -## Экспирация данных {#data-expiry} +## Истечение срока действия данных {#data-expiry} -### Экспирация истории {#history-expiry} +### Истечение срока действия истории {#history-expiry} Под экспирацией истории понимается «обрезка» клиентами старых данных, которые им вряд ли понадобятся, так что они смогут хранить лишь небольшой объем исторических данных, отбрасывая старые данные при поступлении новых. Клиентам нужны исторические данные по двум причинам: синхронизация и обслуживание запросов данных. Изначально клиенты должны были синхронизироваться с начальным блоком, убеждаясь, что каждый последующий блок верен вплоть до самой вершины цепочки. Сегодня клиенты используют «контрольные точки слабой субъективности», чтобы упростить себе путь к вершине цепи. Это доверенные начальные точки, как бы делающие начальный блок ближе к текущим без необходимости проходить всю цепь Ethereum от начала. Это значит, что клиенты могут отбрасывать всю информацию, ведущую к самой недавней контрольной точке слабой субъективности, не теряя возможности синхронизироваться с вершиной цепочки. Сейчас клиенты выполняют запросы исторических данных (поступающие через JSON-RPC), получая их из собственных локальных баз данных. Но экспирация истории сделает это невозможным, если запрашиваемые данные окажутся обрезаны. Обработка исторических данных — это область, требующая инновационных решений. @@ -35,40 +35,40 @@ lang: ru Это обновление фундаментально не меняет подход узлов Ethereum к хранению данных состояния, а лишь меняет способы доступа к историческим данным. -### Экспирация состояния {#state-expiry} +### Истечение срока действия состояния {#state-expiry} Экспирация состояния — это устранение данных о состоянии из отдельных узлов, если к ним никто не обращался в последнее время. Есть несколько способов реализации, включая: -- **Экспирация по аренде**: взимание «арендной платы» с акканутов и окончание их срока действия, когда арендная плата достигнет нуля. -- **Экспирация по времени**: аккаунты становятся неактивными, если не было операций чтения/записи с аккаунта на протяжении определенного периода времени. +- **Истечение срока по аренде**: взимание "арендной платы" с аккаунтов и истечение их срока действия, когда их арендная плата достигает нуля +- **Истечение срока по времени**: аккаунты становятся неактивными, если с этого аккаунта не производилось операций чтения/записи в течение некоторого времени -Экспирация по аренде может иметь вид прямой арендной платы, взимаемой с аккаунтов за удержание их в базе данных активного состояния. Экспирация по времени может иметь вид обратного отсчета с последнего действия аккаунта или периодического окончания действия всех аккаунтов. Также могут быть разработаны механизмы, сочетающие в себе модели с арендой и временем. Например, отдельные аккаунты могут оставаться в активном состоянии, если они платят небольшую комиссию, прежде чем произойдет экспирация по времени. Говоря об экспирации состояния, важно отметить, что неактивное состояние **не удаляется**, а просто переходит на хранение отдельно от активного состояния. Неактивное состояние можно восстановить и снова сделать активным. +Экспирация по аренде может иметь вид прямой арендной платы, взимаемой с аккаунтов за удержание их в базе данных активного состояния. Экспирация по времени может иметь вид обратного отсчета с последнего действия аккаунта или периодического окончания действия всех аккаунтов. Также могут быть разработаны механизмы, сочетающие в себе модели с арендой и временем. Например, отдельные аккаунты могут оставаться в активном состоянии, если они платят небольшую комиссию, прежде чем произойдет экспирация по времени. Что касается истечения срока действия состояния, важно отметить, что неактивное состояние **не удаляется**, а просто хранится отдельно от активного состояния. Неактивное состояние можно восстановить и снова сделать активным. -Чтобы это заработало, вероятно, потребуется создать дерево состояний с определенными периодами времени (возможно, около 1 года). При начале каждого нового периода создается полностью новое дерево состояний. Только текущее дерево состояний может меняться, все остальные неизменны. Ожидается, что узлы Ethereum будут хранить только текущее дерево состояния и ближайшее следующее. Для этого потребуется способ создавать метку времени в адресе, указываая период, в котором она существует. Есть [несколько возможных способов](https://ethereum-magicians.org/t/types-of-resurrection-metadata-in-state-expiry/6607) сделать это, но приоритетный требует [удлинения адресов](https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485), чтобы включить в них дополнительную информацию, так как длинные адреса более безопасны. Этот пункт в дорожной карте называется [расширением места для адресов](https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485). +Чтобы это заработало, вероятно, потребуется создать дерево состояний с определенными периодами времени (возможно, около 1 года). При начале каждого нового периода создается полностью новое дерево состояний. Только текущее дерево состояний может меняться, все остальные неизменны. Ожидается, что узлы Ethereum будут хранить только текущее дерево состояния и ближайшее следующее. Для этого потребуется способ создавать метку времени в адресе, указываая период, в котором она существует. Для этого существует [несколько возможных способов](https://ethereum-magicians.org/t/types-of-resurrection-metadata-in-state-expiry/6607), но основной вариант требует [удлинения адресов](https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485) для размещения дополнительной информации, при этом дополнительным преимуществом является то, что более длинные адреса гораздо безопаснее. Соответствующий пункт дорожной карты называется [расширением адресного пространства](https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485). Как и при экспирации истории, при экспирации состояния ответственность за хранение старых данных о состоянии снимается с отдельных пользователей и передается другим субъектам, таким как централизованные поставщики услуг, альтруистичные члены сообщества или более футуристичные децентрализованные решения, например Portal Network. Экспирация состояния еще на стадии исследования и не готова к запуску. Возможно реализация экспирации состояния случится позже, чем появятся клиенты без отслеживания всего состояния и экспирация истории, поскольку эти обновления сделают управление большими размерами состояний намного проще для большинства валидаторов. -## Клиенты не использующие состояние {#statelessness} +## Безсостоятельность {#statelessness} Клиенты без состояния — это немного неточная формулировка, потому что она не предполагает, что все «состояние» перестанет отслеживаться. Но при этом предусматривается изменение того, как узлы Ethereum обрабатывают данные о состоянии. Отсутствие состояния само по себе может быть двух видов: слабым и сильным. Слабое отсутствие состояния позволяет большинству узлов обходиться без состояния, передав ответственность за его хранение меньшинству. Сильное отсутствие состояния полностью избавляет все узлы от необходимости хранить полную версию данных о состоянии. И сильное, и слабое отсутствие состояния имеет следующие преимущества для обычных валидаторов: - Почти мгновенная синхронизация. - Возможность валидировать блоки не по порядку. -- Очень низкие аппаратные требования для запуска узлов (например, возможность делать это на телефоне). +- узлы, способные работать с очень низкими аппаратными требованиями (например, на телефонах) - Возможность узлов работать на дешевых жестких дисках, поскольку необходимости в постоянном чтении и записи не будет. - Совместимость с будущими обновлениями криптографии Ethereum. -### Частичное отсутствие фиксации {#weak-statelessness} +### Слабая безсостоятельность {#weak-statelessness} Слабое отсутствие состояния действительно меняет способ, которым узлы Ethereum проверяют изменения в состоянии, но не исключает целиком необходимость хранилища для данных состояния у всех узлов в сети. Вместо этого ответственность за хранение состояний ложится на предлагающих блоки, в то время как все остальные узлы сети проверяют блоки, не храня все данные состояния. -**При слабом отсутствии состояния предложение новых блоков требует доступа к данным всего состояния, но верификация не требует никаких данных о состоянии.** +**При слабой безсостоятельности предложение блоков требует доступа ко всем данным состояния, а их проверка не требует никаких данных о состоянии** -Для этого [деревья Веркла](/roadmap/verkle-trees/) должны быть уже реализованы в клиентах Ethereum. Деревья Веркла — это изменение структуры хранения данных в Ethereum, позволяющее узлам обмениваться между собой маленькими «свидетельствами» фиксированного размера и использовать их для верификации блоков, вместо того чтобы верифицировать блоки на основе локальных баз данных. [Разделение предлагающих и строителей](/roadmap/pbs/) также необходимо, поскольку это позволит строителям блоков выступать в роли специализированных узлов с более мощным оборудованием, и именно им потребуется доступ ко всем данным состояния. +Для этого [деревья Веркла](/roadmap/verkle-trees/) уже должны быть реализованы в клиентах Ethereum. Деревья Веркла — это изменение структуры хранения данных в Ethereum, позволяющее узлам обмениваться между собой маленькими «свидетельствами» фиксированного размера и использовать их для верификации блоков, вместо того чтобы верифицировать блоки на основе локальных баз данных. Также требуется [разделение предлагающих и сборщиков](/roadmap/pbs/), поскольку это позволяет сборщикам блоков быть специализированными узлами с более мощным оборудованием, и именно им требуется доступ ко всем данным состояния. - + Слабое отсутствие состояния полагается на строителей блоков, обслуживающих полную копию данных всего состояния, так что они смогут создавать доказательства, используемые при верификации блока. Другие узлы не нуждаются в доступе к данным состояния — вся информация, нужная для верификации блока, доступна в доказательстве. Это создает условия, в которых предложение блока обходится дорого, но верификация — дешево, что приводит к тому, что меньшее количество операторов будут обслуживать узлы, предлагающие блоки. Тем не менее, децентрализация предлагающих блоки не критична, поскольку любое количество участников могут независимо верифицировать валидность предлагаемых блоков. @@ -79,7 +79,7 @@ lang: ru Слабое отсутствие состояния еще находится на стадии углубленного исследования, но известно, что оно строится на разделении на предлагающих и строящих блоки, а также деревьях Веркла, которые необходимо внедрить, чтобы маленькие свидетельства могли передаваться между одноранговыми пользователями. Это значит, что до реализации слабого отсутствия состояния в основной сети Ethereum остается, скорее всего, еще несколько лет. -### Полное отсутствие фиксации {#strong-statelessness} +### Сильная безсостоятельность {#strong-statelessness} При полном отсутствии фиксации узлам не нужно хранить данные о состоянии. Вместо этого транзакции отправляются со свидетельствами, которые собираются производителями блоков. Производители блоков затем отвечают за хранение только состояния, которое нужно для генерации свидетельств для соответствующих аккаунтов. Ответственность за состояние почти полностью переходит в руки пользователей, поскольку они отправляют свидетельства и «списки доступа», чтобы заявить о том, с какими аккаунтами и ключами в хранилище они взаимодействуют. Это значительно снизит размер узлов, но может усложнить выполнение транзакций с использованием смарт-контрактов. @@ -87,17 +87,19 @@ lang: ru ## Текущий прогресс {#current-progress} -Слабое отсутствие состояния, экспирация истории и экспирация состояния находятся на этапе исследований, их запуск планируется через несколько лет. Нет никаких гарантий, что все предложения будут внедрены. Например, если экспирация состояний будет реализована в первую очередь, реализовывать экспирацию истории может не потребоваться. В дорожной карте также присутствуют другие элементы, такие как [деревья Веркла](/roadmap/verkle-trees) и [разделение предлагающих и строящих](/roadmap/pbs), которые должны быть выполнены в первую очередь. +Слабое отсутствие состояния, экспирация истории и экспирация состояния находятся на этапе исследований, их запуск планируется через несколько лет. Нет никаких гарантий, что все предложения будут внедрены. Например, если экспирация состояний будет реализована в первую очередь, реализовывать экспирацию истории может не потребоваться. Есть также и другие пункты дорожной карты, такие как [деревья Веркла](/roadmap/verkle-trees) и [разделение предлагающих и сборщиков](/roadmap/pbs), которые необходимо выполнить в первую очередь. -## Дополнительная литература {#further-reading} +## Дополнительные материалы {#further-reading} -- [Виталик отвечает на вопросы о клиентах без состояния](https://www.reddit.com/r/ethereum/comments/o9s15i/impromptu_technical_ama_on_statelessness_and/) -- [Теория управления размерами состояния](https://hackmd.io/@vbuterin/state_size_management) -- [Ограничение состояния с минимизацией конфликта восстановления](https://ethresear.ch/t/resurrection-conflict-minimized-state-bounding-take-2/8739) -- [Пути к клиентам без состояния и экспирации состояний](https://hackmd.io/@vbuterin/state_expiry_paths) +- [Что такое безсостоятельный Ethereum?](https://stateless.fyi/) +- [AMA Виталика о безсостоятельности](https://www.reddit.com/r/ethereum/comments/o9s15i/impromptu_technical_ama_on_statelessness_and/) +- [Теория управления размером состояния](https://hackmd.io/@vbuterin/state_size_management) +- [Ограничение состояния с минимизацией конфликтов при восстановлении](https://ethresear.ch/t/resurrection-conflict-minimized-state-bounding-take-2/8739) +- [Пути к безсостоятельности и истечению срока действия состояния](https://hackmd.io/@vbuterin/state_expiry_paths) - [Спецификация EIP-4444](https://eips.ethereum.org/EIPS/eip-4444) -- [Алекс Стоукс о EIP-4444](https://youtu.be/SfDC_qUZaos) -- [Почему важно перейти на клиенты без состояния](https://dankradfeist.de/ethereum/2021/02/14/why-stateless.html) -- [Оригинальные заметки о концепции клиента без состояния](https://ethresear.ch/t/the-stateless-client-concept/172) -- [Подробнее об экспирации состояний](https://hackmd.io/@vbuterin/state_size_management#A-more-moderate-solution-state-expiry) -- [Еще больше об экспирации состояний](https://hackmd.io/@vbuterin/state_expiry_paths#Option-2-per-epoch-state-expiry) +- [Алекс Стоукс об EIP-4444](https://youtu.be/SfDC_qUZaos) +- [Почему так важно перейти к безсостоятельности](https://dankradfeist.de/ethereum/2021/02/14/why-stateless.html) +- [Заметки об оригинальной концепции безсостоятельного клиента](https://ethresear.ch/t/the-stateless-client-concept/172) +- [Подробнее об истечении срока действия состояния](https://hackmd.io/@vbuterin/state_size_management#A-more-moderate-solution-state-expiry) +- [Еще больше об истечении срока действия состояния](https://hackmd.io/@vbuterin/state_expiry_paths#Option-2-per-epoch-state-expiry) +- [Информационная страница о безсостоятельном Ethereum](https://stateless.fyi) diff --git a/public/content/translations/ru/roadmap/user-experience/index.md b/public/content/translations/ru/roadmap/user-experience/index.md index 0a9ddb80cb5..ffb05b9833a 100644 --- a/public/content/translations/ru/roadmap/user-experience/index.md +++ b/public/content/translations/ru/roadmap/user-experience/index.md @@ -1,27 +1,27 @@ --- -title: Улучшение опыта пользователей -description: До сих пор использование Ethereum слишком сложно для большинства людей. Чтобы поощрять массовое распространение, системе Ethereum необходимо значительно снизить порог входа. Пользователи должны получать преимущества от децентрализованного, общедоступного и устойчивого к цензуре доступа к Ethereum, но он должен быть таким же удобным, как использование традиционного приложения web2. +title: "Улучшение опыта пользователей" +description: "До сих пор использование Ethereum слишком сложно для большинства людей. Чтобы поощрять массовое распространение, системе Ethereum необходимо значительно снизить порог входа. Пользователи должны получать преимущества от децентрализованного, общедоступного и устойчивого к цензуре доступа к Ethereum, но он должен быть таким же удобным, как использование традиционного приложения web2." lang: ru image: /images/roadmap/roadmap-ux.png alt: "Дорожная карта Ethereum" template: roadmap --- -**Использование Ethereum необходимо упростить**: от управления [ключами](/glossary/#key) и [кошельками](/glossary/#wallet) до инициации транзакций. Для ускорения массового внедрения Ethereum должен стать радикально проще в использовании, что позволит пользователям получать беспрепятственный и устойчивый к цензуре доступ к Ethereum с той же легкостью, что и при использовании приложений [web2](/glossary/#web2). +**Использование Ethereum необходимо упростить**: от управления [ключами](/glossary/#key) и [кошельками](/glossary/#wallet) до инициирования транзакций. Чтобы облегчить массовое внедрение, Ethereum должен стать радикально проще в использовании, что позволит пользователям получить не требующий разрешений и устойчивый к цензуре доступ к Ethereum с той же легкостью, как при использовании приложений [Web2](/glossary/#web2). -## После кодовых фраз {#no-more-seed-phrases} +## Больше никаких сид-фраз {#no-more-seed-phrases} Аккаунты Ethereum защищены парой ключей, используемых для идентификации аккаунтов (публичный ключ) и подписи сообщений (приватный ключ). Приватный ключ похож на главный пароль: он позволяет получить полный доступ к аккаунту Ethereum. Этот подход отличается от привычного людям, более знакомым с банками и приложениями Web2 для управления аккаунтами от имени пользователя. Чтобы Ethereum достиг массового распространения, не полагаясь на централизованные третьи стороны, у пользователя должен быть понятный и простой способ получить контроль над своими активами и данными без необходимости понимания криптографии публичных и приватных ключей и управления ими. -Решение этого вопроса заключается в использовании кошельков с [смарт-контрактами](/glossary/#smart-contract) для взаимодействия с Ethereum. Кошельки смарт-контрактов создают способы для защиты аккаунта (если ключи были потеряны или украдены), возможности для лучшего выявления мошенничества и для защиты от него. Они позволяют оснастить кошельки новыми функциями. Хотя кошельки смарт-контрактов и существуют сегодня, они неудобны для создания, потому что протокол Ethereum должен поддерживать их лучше. Эта дополнительная поддержка называется абстрагированием аккаунта. +Решение этой проблемы заключается в использовании кошельков на основе [смарт-контрактов](/glossary/#smart-contract) для взаимодействия с Ethereum. Кошельки смарт-контрактов создают способы для защиты аккаунта (если ключи были потеряны или украдены), возможности для лучшего выявления мошенничества и для защиты от него. Они позволяют оснастить кошельки новыми функциями. Хотя кошельки смарт-контрактов и существуют сегодня, они неудобны для создания, потому что протокол Ethereum должен поддерживать их лучше. Эта дополнительная поддержка называется абстрагированием аккаунта. -Подробнее об абстрагировании аккаунта +Подробнее об абстракции учетных записей ## Узлы для каждого -Пользователям, запускающим [узлы](/glossary/#node), нет необходимости доверять посредникам, чтобы предоставлять им данные. Они могут взаимодействовать с [блокчейном](/glossary/#blockchain) Ethereum быстро, конфиденциально и без необходимости получать чье-то разрешение. Однако сейчас запуск узла требует технической грамотности, а также значительного места на диске, поэтому люди вынуждены доверять посредникам. +Пользователям, запускающим [узлы](/glossary/#node), не нужно доверять третьим сторонам в предоставлении данных, и они могут быстро, конфиденциально и без разрешений взаимодействовать с [блокчейном](/glossary/#blockchain) Ethereum. Однако сейчас запуск узла требует технической грамотности, а также значительного места на диске, поэтому люди вынуждены доверять посредникам. -Существует несколько обновлений, которые могут сделать запуск и поддержание узла не таким сложным и ресурсоемким. Способ хранения данных будет изменен для использования более компактной структуры, известной как **дерево Веркла**. Кроме того, с клиентами [без состояния](/roadmap/statelessness) или [экспирацией данных](/roadmap/statelessness/#data-expiry) узлам Ethereum не нужно будет хранить копию всех данных о состоянии, что резко снизит потребности в пространстве на жестком диске. [Легкие узлы](/developers/docs/nodes-and-clients/light-clients/) в будущем позволят сохранить преимущества полных узлов, но станут легко запускаемыми на мобильных устройствах или в простом веб-приложении в браузере. +Существует несколько обновлений, которые могут сделать запуск и поддержание узла не таким сложным и ресурсоемким. Способ хранения данных будет изменен для использования более компактной структуры, известной как **дерево Веркла**. Кроме того, благодаря [отсутствию состояния](/roadmap/statelessness) или [истечению срока хранения данных](/roadmap/statelessness/#data-expiry) узлам Ethereum не потребуется хранить копию всех данных о состоянии Ethereum, что резко сократит требования к месту на жестком диске. [Легкие узлы](/developers/docs/nodes-and-clients/light-clients/) предложат многие преимущества запуска полного узла, но смогут легко работать на мобильных телефонах или в простых браузерных приложениях. Подробнее о деревьях Веркла @@ -29,8 +29,8 @@ template: roadmap ## Текущий прогресс {#current-progress} -Кошельки смарт-контрактов уже доступны, но требуется больше обновлений, чтобы сделать их как можно более децентрализованными и избавленными от разрешений. EIP-4337 — это зрелое предложение, которое не требует никаких изменений в протоколе Ethereum. Основной смарт-контракт, необходимый для EIP-4337, **был развернут в марте 2023 года**. +Кошельки смарт-контрактов уже доступны, но требуется больше обновлений, чтобы сделать их как можно более децентрализованными и избавленными от разрешений. EIP-4337 — это зрелое предложение, которое не требует никаких изменений в протоколе Ethereum. Основной смарт-контракт, необходимый для EIP-4337, был **развернут в марте 2023 года**. -**Клиенты без фиксации состояния находятся на стадии исследования**, на их реализацию, скорее всего, уйдут годы. На пути к клиентам без состояния есть несколько контрольных точек, включая экспирацию данных, которая может быть реализована быстрее. Другие элементы дорожной карты, такие как [деревья Веркла](/roadmap/verkle-trees/) и [разделение предлагающих и строящих](/roadmap/pbs/), должны быть завершены в первую очередь. +**Полное отсутствие состояния все еще находится на стадии исследования**, и до его внедрения, вероятно, пройдет несколько лет. На пути к клиентам без состояния есть несколько контрольных точек, включая экспирацию данных, которая может быть реализована быстрее. Другие элементы дорожной карты, такие как [деревья Веркла](/roadmap/verkle-trees/) и [разделение предлагающего и сборщика](/roadmap/pbs/), должны быть завершены в первую очередь. Тестовые сети с деревьями Веркла уже работают, а следующим шагом будет запуск клиентов, основанных на деревьях Веркла: сначала в приватных, а потом и в общедоступных тестовых сетях. Вы можете помочь ускорить прогресс, развертывая смарт-контракты или клиенты в тестовых сетях. diff --git a/public/content/translations/ru/roadmap/verkle-trees/index.md b/public/content/translations/ru/roadmap/verkle-trees/index.md index 2671dd25867..28d88491dc1 100644 --- a/public/content/translations/ru/roadmap/verkle-trees/index.md +++ b/public/content/translations/ru/roadmap/verkle-trees/index.md @@ -1,6 +1,6 @@ --- -title: Деревья Веркла -description: Высокоуровневое описание деревьев Веркла и того, как они будут использоваться для обновления Ethereum +title: "Деревья Веркла" +description: "Высокоуровневое описание деревьев Веркла и того, как они будут использоваться для обновления Ethereum" lang: ru summaryPoints: - Узнайте, что такое деревья Веркла @@ -11,19 +11,18 @@ summaryPoints: Деревья Веркла («векторное обязательство» + «деревья Меркла») — это структура данных, которая может быть использована для обновления узлов Ethereum, чтобы они могли прекратить хранение больших объемов данных о состоянии, не теряя возможность валидировать блоки. -## Клиенты не использующие состояние {#statelessness} +## Безсостоятельность {#statelessness} Деревья Веркла являются важным шагом на пути к клиентам без состояния. Клиенты без состояния — это клиенты, которым не нужно хранить всю базу данных о состоянии Ethereum для проверки входящих блоков. Вместо использования собственной локальной копии состояния Ethereum для проверки блоков клиенты без состояния используют «свидетельство» данных состояния, которое приходит вместе с блоком. Свидетельство — это коллекция отдельных частей данных о состоянии, необходимых для выполнения определенного набора транзакций, и криптографическое доказательство того, что свидетельство действительно является частью полных данных. Свидетельство используется _вместо_ базы данных состояния. Для этого свидетельства должны быть очень маленькими, чтобы их можно было безопасно и вовремя транслировать по сети, а проверяющие могли обработать их в течение слота в 12 секунд. Нынешняя структура данных о состоянии не подходит, поскольку свидетельства слишком велики. Деревья Веркла решают эту проблему, допуская маленькие свидетельства и устраняя один из главных барьеров на пути к клиентам без состояния. - + Клиенты Ethereum в настоящее время используют структуру данных хэш-дерево Меркла вида Patricia для хранения данных о состоянии. Информация об отдельных аккаунтах хранится в виде «листьев» на дереве хэшей, а пары «листьев» постоянно хэшируются до тех пор, пока не останется только один хэш. Этот последний хэш называют «корнем». Для проверки блоков клиенты Ethereum выполняют все транзакции в блоке и обновляют свои локальные деревья состояния. Блок считается действительным, если корень локального дерева идентичен тому, который предоставил предлагающий блок, поскольку любые различия в вычислениях, выполняемых предлагающим и узлом валидатора, приведут к тому, что корневой хэш будет совершенно другим. Проблема здесь в том, что для проверки блокчейна нужно, чтобы каждый клиент хранил все дерево хэшей для головного блока и для нескольких исторических блоков (в Geth стоит по умолчанию удержание данных о состоянии 128 блоков за головным блоком). Это требует, чтобы клиенты имели доступ к большому дисковому пространству, что является барьером для работы полных узлов на дешевом и маломощном оборудовании. Решением этого является обновление дерева состояния до более эффективной структуры (дерева Веркла), которая может быть обобщена с помощью небольшого «свидетельства» данных, используемого вместо полных данных о состоянии. Переформатирование данных о состоянии в дерево Веркла является отправной точкой для перехода к клиентам без состояния. - ## Что такое свидетельство и зачем оно нам нужно? {#what-is-a-witness} -Проверка блока означает повторное выполнение транзакций, содержащихся в блоке, применение изменений к дереву состояния Ethereum и вычисление нового корневого хэша. Проверенный блок — это блок, чей вычисленный корневой хэш состояния совпадает с тем, который предоставлен вместе с блоком (поскольку это означает, что тот, кто предложил блок, действительно выполнил вычисления, о которых он заявил). В сегодняшних клиентах Ethereum обновление состояния требует доступа ко всему дереву состояния — большой структуре данных, которые должны храниться локально. Свидетельство содержит только фрагменты данных о состоянии, которые необходимы для выполнения транзакций в блоке. Валидатор сможет использовать только эти фрагменты, чтобы удостовериться, что предложивший блок выполнил транзакции и обновил состояние правильно. Однако это означает, что свидетельство необходимо передавать между одноранговыми пользователями по сети Ethereum достаточно быстро, чтобы оно было принято и обработано каждым узлом безопасно в 12-секундном слоте. Если свидетельство слишком велико, некоторым узлам может потребоваться слишком много времени, чтобы загрузить его, не отставая от цепи. Это централизующая сила, потому что это означает, что только узлы с быстрым интернет-соединением смогут участвовать в проверке блоков. С деревьями Веркла нет необходимости хранить состояние на жестком диске. _Все_, что нужно для проверки блока, находится в самом блоке. К сожалению, свидетельства, которые могут быть получены с помощью деревьев Меркла, слишком велики, чтобы поддерживать клиенты без состояния. +Проверка блока означает повторное выполнение транзакций, содержащихся в блоке, применение изменений к дереву состояния Ethereum и вычисление нового корневого хэша. Проверенный блок — это блок, чей вычисленный корневой хэш состояния совпадает с тем, который предоставлен вместе с блоком (поскольку это означает, что тот, кто предложил блок, действительно выполнил вычисления, о которых он заявил). В сегодняшних клиентах Ethereum обновление состояния требует доступа ко всему дереву состояния — большой структуре данных, которые должны храниться локально. Свидетельство содержит только фрагменты данных о состоянии, которые необходимы для выполнения транзакций в блоке. Валидатор сможет использовать только эти фрагменты, чтобы удостовериться, что предложивший блок выполнил транзакции и обновил состояние правильно. Однако это означает, что свидетельство необходимо передавать между одноранговыми пользователями по сети Ethereum достаточно быстро, чтобы оно было принято и обработано каждым узлом безопасно в 12-секундном слоте. Если свидетельство слишком велико, некоторым узлам может потребоваться слишком много времени, чтобы загрузить его, не отставая от цепи. Это централизующая сила, потому что это означает, что только узлы с быстрым интернет-соединением смогут участвовать в проверке блоков. С деревьями Веркла нет необходимости хранить состояние на жестком диске; _все_, что нужно для проверки блока, содержится в самом блоке. К сожалению, свидетельства, которые могут быть получены с помощью деревьев Меркла, слишком велики, чтобы поддерживать клиенты без состояния. ## Почему деревья Веркла дают нам свидетельства меньшего размера? {#why-do-verkle-trees-enable-smaller-witnesses} @@ -31,36 +30,35 @@ summaryPoints: При схеме обязательств с использованием многочленов свидетельства получают приемлемый размер, который можно легко передавать в одноранговой сети. Это позволяет клиентам проверять изменение состояния в каждом блоке, используя минимальное количество данных. - - -Размер свидетельства зависит от количества листьев, которые оно включает. Если принять, что свидетельство покрывает 1000 листьев, свидетельство для дерева Меркла будет весить около 3,5 МБ (предполагая 7 уровней дерева). Свидетельство для тех же данных в дереве Веркла (предполагая 4 уровня дерева) будет весить около 150 КБ — **примерно в 23 раза меньше**. Такое сокращение размера свидетельства позволит клиентам без состояния быть приемлемо малыми. Размер полиномиальных свидетельств составляет от 0,128 до 1 КБ (в зависимости от конкретного используемого полиномиального обязательства). + +Размер свидетельства зависит от количества листьев, которые оно включает. Если принять, что свидетельство покрывает 1000 листьев, свидетельство для дерева Меркла будет весить около 3,5 МБ (предполагая 7 уровней дерева). Свидетельство для тех же данных в дереве Веркла (предполагая 4 уровня дерева) будет весить около 150 КБ — **примерно в 23 раза меньше**. Такое сокращение размера свидетеля позволит клиентам без состояния быть достаточно малыми. Размер полиномиальных свидетельств составляет от 0,128 до 1 КБ (в зависимости от конкретного используемого полиномиального обязательства). ## Какова структура дерева Веркла? {#what-is-the-structure-of-a-verkle-tree} -Деревья Веркла — это пары `(key,value)`, в которых ключи состоят из 32-байтовых элементов, включающих 31-байтовый _stem_ и 1-байтовый _suffix_. Эти ключи организованы в узлы _расширения_ и _внутренние_ узлы. Узлы расширения представляют собой единую основу с 256 потомками и разными суффиксами. Внутренние узлы тоже имеют 256 потомков, но они могут в то же время являться другими узлами расширения. Основное различие между структурами дерева Веркла и дерева Меркла заключается в том, что дерево Веркла гораздо более плоское. Это значит, что существует меньше промежуточных узлов, связывающих лист с корнем, и, следовательно, меньше данных, необходимых для создания доказательства. +Деревья Веркла — это пары `(key,value)`, где ключи — это 32-байтовые элементы, состоящие из 31-байтового _stem_ и однобайтового _suffix_. Эти ключи организованы в _узлы расширения_ и _внутренние узлы_. Узлы расширения представляют собой единую основу с 256 потомками и разными суффиксами. Внутренние узлы тоже имеют 256 потомков, но они могут в то же время являться другими узлами расширения. Основное различие между структурами дерева Веркла и дерева Меркла заключается в том, что дерево Веркла гораздо более плоское. Это значит, что существует меньше промежуточных узлов, связывающих лист с корнем, и, следовательно, меньше данных, необходимых для создания доказательства. ![](./verkle.png) -[Подробнее о структуре деревьев Веркла](https://blog.ethereum.org/2021/12/02/verkle-tree-structure) +[Узнайте больше о структуре деревьев Веркла](https://blog.ethereum.org/2021/12/02/verkle-tree-structure) ## Текущий прогресс {#current-progress} Тестовые сети деревьев Веркла уже запущены, но все еще есть существенные обновления для клиентов, которые необходимы для поддержки деревьев Веркла. Вы можете помочь ускорить прогресс, развертывая смарт-контракты или клиенты в тестовых сетях. -[Узнайте о тестовой сети Verkle Gen Devnet 2](https://verkle-gen-devnet-2.ethpandaops.io/) - -[Посмотрите объяснение Гийома Балле о тестовой сети Condrieu Verkle](https://www.youtube.com/watch?v=cPLHFBeC0Vg) (обратите внимание: тестовая сеть Condrieu была основана на доказательстве выполнения работы, она заменена на тестовую сеть Verkle Gen Devnet 2). +[Посмотрите объяснение Гийома Балле о тестовой сети Condrieu Verkle](https://www.youtube.com/watch?v=cPLHFBeC0Vg) (обратите внимание, что тестовая сеть Condrieu использовала proof-of-work и теперь заменена тестовой сетью Verkle Gen Devnet 6). -## Дополнительная литература {#further-reading} +## Дополнительные материалы {#further-reading} -- [Деревья Веркла для клиентов без фиксации состояния](https://verkle.info/) -- [Данкрад Фейст объясняет деревья Веркла на PEEPanEIP](https://www.youtube.com/watch?v=RGJOQHzg3UQ) -- [Гийом Балле объясняет деревья Веркла на ETHGlobal](https://www.youtube.com/watch?v=f7bEtX3Z57o) -- [«Как деревья Меркла делают Ethereum эффективным и готовым к работе» — Гийом Балле, Devcon 6](https://www.youtube.com/watch?v=Q7rStTKwuYs) -- [Пайпер Мерриам о клиентах без состояния на ETHDenver 2020](https://www.youtube.com/watch?v=0yiZJNciIJ4) -- [Данкрад Фиест объясняет, что такое деревья Веркла и клиенты без фиксации состояния, в подкасте Zero Knowledge](https://zeroknowledge.fm/podcast/202/) +- [Деревья Веркла для работы без сохранения состояния](https://verkle.info/) +- [Данкрад Файст (Dankrad Feist) объясняет деревья Веркла на PEEPanEIP](https://www.youtube.com/watch?v=RGJOQHzg3UQ) +- [Деревья Веркла для всех остальных](https://web.archive.org/web/20250124132255/https://research.2077.xyz/verkle-trees) +- [Анатомия доказательства Веркла](https://ihagopian.com/posts/anatomy-of-a-verkle-proof) +- [Гийом Балле объясняет, что такое деревья Веркла, на ETHGlobal](https://www.youtube.com/watch?v=f7bEtX3Z57o) +- [«Как деревья Веркла делают Ethereum эффективным и производительным», Гийом Балле на Devcon 6](https://www.youtube.com/watch?v=Q7rStTKwuYs) +- [Пайпер Мерриам о клиентах без сохранения состояния, ETHDenver 2020](https://www.youtube.com/watch?v=0yiZJNciIJ4) +- [Данкрад Файст объясняет, что такое деревья Веркла и работа без сохранения состояния, в подкасте «Zero Knowledge»](https://zeroknowledge.fm/podcast/202/) - [Виталик Бутерин о деревьях Веркла](https://vitalik.eth.limo/general/2021/06/18/verkle.html) -- [Данкрад Фейст о деревьях Веркла](https://dankradfeist.de/ethereum/2021/06/18/verkle-trie-for-eth1.html) -- [Документация EIP деревьев Веркла](https://notes.ethereum.org/@vbuterin/verkle_tree_eip#Illustration) +- [Данкрад Файст о деревьях Веркла](https://dankradfeist.de/ethereum/2021/06/18/verkle-trie-for-eth1.html) +- [Документация EIP по деревьям Веркла](https://notes.ethereum.org/@vbuterin/verkle_tree_eip#Illustration) diff --git a/public/content/translations/ru/security/index.md b/public/content/translations/ru/security/index.md index 916d72b7cd3..14042cba427 100644 --- a/public/content/translations/ru/security/index.md +++ b/public/content/translations/ru/security/index.md @@ -1,6 +1,6 @@ --- -title: Безопасность Ethereum и предотвращение мошенничества -description: Безопасность в Ethereum +title: "Безопасность Ethereum и предотвращение мошенничества" +description: "Безопасность в Ethereum" lang: ru --- @@ -8,11 +8,13 @@ lang: ru Растущий интерес к криптовалюте влечет за собой риск стать жертвой мошенников и хакеров. В этой статье приведены рекомендации по снижению этих рисков. +**Помните: никто из ethereum.org никогда не будет связываться с вами. Не отвечайте на электронные письма, утверждающие, что они отправлены официальной службой поддержки Ethereum.** + -## Введение в криптобезопасность {#crypto-security} +## Основы криптобезопасности {#crypto-security} -### Повысьте уровень своих знаний {#level-up-your-knowledge} +### Повысьте свой уровень знаний {#level-up-your-knowledge} Непонимание того, как работают криптовалюты, может привести к дорогостоящим ошибкам. Например, если кто-то притворяется агентом по обслуживанию клиентов, который может вернуть потерянные ЕТН в обмен на ваши секретные ключи, то они охотятся на людей, не понимающих, что Ethereum является децентрализованной сетью, лишенной такого рода функциональности. Узнайте об устройстве системы Ethereum, это вам обязательно пригодится и поможет избежать неприятных ситуаций. @@ -27,7 +29,7 @@ lang: ru ## Безопасность кошелька {#wallet-security} -### Не раздавайте свои секретные ключи {#protect-private-keys} +### Не сообщайте свои приватные ключи {#protect-private-keys} **Никогда и ни за что не делитесь своими секретными ключами!** @@ -37,7 +39,7 @@ lang: ru Что такое кошелек Ethereum? -#### Не делайте снимки экрана с кодовыми фразами и секретными ключами {#screenshot-private-keys} +#### Не делайте снимки экрана с вашими сид-фразами/приватными ключами {#screenshot-private-keys} Делая снимки экрана с кодовыми фразами или секретными ключами, вы рискуете синхронизировать их с облаком и потенциально сделать их доступными для хакеров. Получение секретных ключей из облака — распространенный способ атаки хакеров. @@ -56,15 +58,16 @@ lang: ru Случайная отправка криптовалюты на ошибочный адрес является распространенной ошибкой. **Транзакция, отправленная в Ethereum, необратима.** Если вы не знаете владельца адреса и не сможете убедить его отправить вам ваши средства обратно, то вернуть их не удастся. -Прежде чем отправлять транзакцию, убедитесь, что указанный адрес точно совпадает с адресом целевого получателя. Взаимодействуя со смарт-контрактом, рекомендуем прочитать сообщение транзакции перед подписанием. +Прежде чем отправлять транзакцию, убедитесь, что указанный адрес точно совпадает с адресом целевого получателя. +Взаимодействуя со смарт-контрактом, рекомендуем прочитать сообщение транзакции перед подписанием. -### Установите лимиты расходов по смарт-контракту {#spend-limits} +### Установите лимиты расходов для смарт-контрактов {#spend-limits} Взаимодействуя со смарт-контрактами, не допускайте неограниченных лимитов на расходы. Неограниченные расходы могут привести к тому, что смарт-контракт опустошит ваш кошелек. Вместо этого установите лимиты расходов на сумму, необходимую только для транзакции. Многие кошельки Ethereum предлагают защитные лимиты для предотвращения опустошения аккаунтов. -[Как отозвать доступ умного контракта к вашим средствам в криптовалюте](/guides/how-to-revoke-token-access/) +[Как отозвать доступ смарт-контракта к вашим крипто-средствам](/guides/how-to-revoke-token-access/) @@ -76,29 +79,29 @@ lang: ru - Никто не собирается давать вам ETH бесплатно или продавать со скидкой - Никому, кроме мошенников, не нужен доступ к вашим закрытым ключам или личной информации! -### Фишинг в рекламе Twitter {#ad-phishing} +### Фишинг через рекламу в Twitter {#ad-phishing} -![Фишинг в ссылках Twitter](./twitterPhishingScam.png) +![Фишинг по ссылке в Twitter](./twitterPhishingScam.png) -Есть метод подделки функции предварительного просмотра ссылок Twitter (также известного как X), с помощью которого можно ввести пользователей в заблуждение, заставляя их думать, что они посещают настоящий веб-сайт. Этот метод эксплуатирует механизм предпросмотра URL-адресов, размещенных в твитах, и показывает, например, _с ethereum.org_ (как показано выше), когда на самом деле пользователи перенаправляются на вредоносный сайт. +Есть метод подделки функции предварительного просмотра ссылок Twitter (также известного как X), с помощью которого можно ввести пользователей в заблуждение, заставляя их думать, что они посещают настоящий веб-сайт. Этот метод использует механизм Twitter для создания предварительных просмотров URL-адресов, публикуемых в твитах, и показывает, например, _from ethereum.org_ (как показано выше), хотя на самом деле они перенаправляют на вредоносный сайт. Всегда проверяйте подлинность домена, особенно после перехода по ссылке. -[Подробнее…](https://harrydenley.com/faking-twitter-unfurling) +[Подробнее здесь](https://harrydenley.com/faking-twitter-unfurling). -### Мошенничество с бесплатной раздачей средств {#giveaway} +### Мошенничество с раздачами {#giveaway} -Один из наиболее распространенных видов мошенничества — обман с бесплатной криптовалютой. Это мошенничество может принимать различные формы, но суть в следующем: если вы отправите ETH на указанный адрес, то получите вдвое больше ETH. *Поэтому такую схему называют «удвоение».* +Один из наиболее распространенных видов мошенничества — обман с бесплатной криптовалютой. Это мошенничество может принимать различные формы, но суть в следующем: если вы отправите ETH на указанный адрес, то получите вдвое больше ETH._Поэтому такую схему называют «удвоение»._ Мошенники, работающие по этой схеме, обычно давят на вас тем, что срок действия предложения ограничен, чтобы создать ощущение мнимой срочности. -### Взлом социальных сетей {#social-media-hacks} +### Взломы в социальных сетях {#social-media-hacks} Хорошим примером будет событие, произошедшее в июле 2020 года, когда были взломаны аккаунты в Twitter у известных людей и организаций. Хакеры в постах разместили информацию о раздаче биткоинов со взломанных аккаунтов. Хотя взлом быстро обнаружили и устранили, хакерам все же удалось украсть 11 биткоинов (около 500 000 долларов США по курсу на сентябрь 2021 г.). ![Мошенничество в Twitter](./appleTwitterScam.png) -### Раздача от знаменитости {#celebrity-giveaway} +### Раздача от знаменитостей {#celebrity-giveaway} Раздача от знаменитостей — еще одна распространенная форма мошенничества с раздачами. Мошенники берут записанное видеоинтервью или выступление на конференции со знаменитостью и транслируют его в прямом эфире на YouTube, создавая впечатление, что знаменитость дает видеоинтервью в прямом эфире, поддерживая раздачу криптовалюты. @@ -108,13 +111,13 @@ lang: ru ![Мошенничество на YouTube](./youtubeScam.png) -### Мошенническая служба поддержи {#support-scams} +### Мошенничество под видом техподдержки {#support-scams} Криптовалюта — это относительно молодая и непонятная технология. Распространенной аферой, использующей это непонимание, является мошенничество с поддержкой, когда мошенники выдают себя за сотрудников службы поддержки популярных кошельков, бирж или блокчейнов. Большая часть дискуссий об Ethereum происходит в Discord. Мошенники из «службы поддержки» обычно находят свою цель, ища вопросы к поддержке в общедоступных каналах Discord, а затем отправляют спрашивающему личное сообщение с предложением помочь. Завоевав доверие, мошенники, выдающие себя за службы поддержки, пытаются обманом заставить вас раскрыть ваши приватные ключи или отправить средства на их кошельки. -![Мошенничество с поддержкой в ​​Discord](./discordScam.png) +![Мошенничество под видом техподдержки в Discord](./discordScam.png) Как правило, персонал никогда не будет общаться с вами по частным, неофициальным каналам. Несколько простых вещей, о которых следует помнить при работе с поддержкой: @@ -126,20 +129,20 @@ lang: ru - Будьте осторожны: хотя мошенничество под видом поддержки обычно происходит в Discord, оно также может быть в любых чатах приложений, где обсуждаются криптовалюты, а так же по электронной почте. + Осторожно: хотя мошенничество под видом техподдержки часто происходит в Discord, оно также может быть распространено в любых чат-приложениях, где обсуждается криптовалюта, включая электронную почту. -### Мошенничество с токенами Eth2 {#eth2-token-scam} +### Мошенничество с токеном 'Eth2' {#eth2-token-scam} -В преддверии [слияния](/roadmap/merge/) мошенники воспользовались путаницей вокруг термина Eth2, чтобы попытаться заставить пользователей выкупить токены ETH2 за свои ETH. Токенов ETH2 не существует, и никаких новых настоящих токенов при слиянии не появилось. ЕТН, которыми вы владели до слияния, остаются теми же ЕТН. **От вас не требуется никаких действий в связи с переходом от доказательства выполнения работы к доказательству доли владения**. +В преддверии [Слияния](/roadmap/merge/), мошенники воспользовались путаницей вокруг термина 'Eth2', чтобы попытаться заставить пользователей обменять свои ETH на токен 'ETH2'. Токенов ETH2 не существует, и никаких новых настоящих токенов при слиянии не появилось. ЕТН, которыми вы владели до слияния, остаются теми же ЕТН. **Не нужно предпринимать никаких действий с вашими ETH в связи с переходом от доказательства работы к доказательству владения**. -Мошенники могут представиться «службой поддержки» и сказать, что при внесении ETH вы получите обратно «ETH2». [Официальной службы поддержки Ethereum нет](/community/support/), как нет и никаких новых токенов. Никогда и никому не сообщайте кодовую фразу своего кошелька. +Мошенники могут представиться «службой поддержки» и сказать, что при внесении ETH вы получите обратно «ETH2». Официальной службы поддержки Ethereum нет, как нет и никаких новых токенов. Никогда и никому не сообщайте кодовую фразу своего кошелька. -_Примечание. Существуют производные токены и тикеры, которые могут представлять ETH, использованные в стейкинге (например, rETH от Rocket Pool, stETH от Lido, ETH2 от Coinbase), но это что-то, на что необходимо «перейти»._ +_Примечание: существуют производные токены/тикеры, которые могут представлять собой ETH в стейкинге (т. е. rETH от Rocket Pool, stETH от Lido, ETH2 от Coinbase), но вам не нужно на них "переходить"._ -### Фишинг {#phishing-scams} +### Фишинговые мошенничества {#phishing-scams} Фишинг — еще один все более распространенный способ, который мошенники будут использовать, чтобы украсть ваши средства. @@ -151,9 +154,9 @@ _Примечание. Существуют производные токены - Никогда не разглашайте личную информацию или пароли кому-либо. - Удаляйте сообщения от неизвестных отправителей. -[Подробнее о предотвращении фишинговых атак](https://support.mycrypto.com/staying-safe/mycrypto-protips-how-not-to-get-scammed-during-ico) +[Подробнее о том, как избежать фишинговых мошенничеств](https://support.mycrypto.com/staying-safe/mycrypto-protips-how-not-to-get-scammed-during-ico) -### Мошенничество под видом криптоброкера {#broker-scams} +### Мошенничество с брокерами для криптотрейдинга {#broker-scams} Мошенники, выдающие себя за специализированных криптоброкеров, предлагают взять ваши деньги и инвестировать их от вашего имени. Получив ваши средства, мошенники могут ввести вас в заблуждение, попросив вас отправить больше средств, чтобы не упустить дополнительную прибыль от инвестиций, или могут полностью исчезнуть. @@ -161,9 +164,9 @@ _Примечание. Существуют производные токены **Не доверяйте незнакомцам из Интернета инвестировать от вашего имени. Вы потеряете свою криптовалюту.** -![Брокерское мошенничество на YouTube](./brokerScam.png) +![Мошенничество с брокером на YouTube](./brokerScam.png) -### Мошенничество с пулом для майнинга криптовалюты {#mining-pool-scams} +### Мошенничество с пулами для майнинга криптовалют {#mining-pool-scams} По состоянию на сентябрь 2022 года добыча на Ethereum более не возможна. Тем не менее жульничество с пулами майнеров по-прежнему существует. Мошенничество с пулом для майнинга используется теми, кто связывается с вами и утверждает, что вы можете получить большую прибыль, присоединившись к пулу для майнинга Ethereum. Мошенник будет утверждать это и оставаться с вами на связи столько времени, сколько потребуется. По сути, он попытается убедить вас, что когда вы присоединитесь к пулу для майнинга Ethereum, ваша криптовалюта будет использоваться для создания ETH, а вам будут выплачиваться дивиденды в ETH. Затем вы увидите, что ваша криптовалюта приносит небольшой доход. Это сделано для того, чтобы заставить вас инвестировать больше. В конце концов все ваши средства будут отправлены на неизвестный адрес, а мошенник либо исчезнет, ​​либо, в некоторых случаях, продолжит оставаться на связи, как в последнем примере. @@ -175,33 +178,33 @@ _Примечание. Существуют производные токены - Изучите информацию о стекинге, пулах ликвидности или других способах инвестирования вашей криптовалюты. - Если такие схемы и бывают безобидными, то крайне редко. Если бы это было так, то о них бы говорили все и вы бы уже о них знали. -[Жертва потеряла 200 тысяч долларов из-за мошенничества с пулом для майнинга](https://www.reddit.com/r/CoinBase/comments/r0qe0e/scam_or_possible_incredible_payout/) +[Мужчина потерял 200 тысяч долларов из-за мошенничества с майнинг-пулом](https://www.reddit.com/r/CoinBase/comments/r0qe0e/scam_or_possible_incredible_payout/) -### Мошенничество с раздачей (Airdrop) {#airdrop-scams} +### Мошенничество с аирдропами {#airdrop-scams} Мошеннический проект выполняет эйрдроп NFT или токена на ваш кошелек и отправляет вас на мошеннический сайт, где вы якобы можете получить этот актив. При попытке предъявления претензий вам будет предложено войти в систему с помощью кошелька Ethereum и "одобрить" транзакцию. Эта операция компрометирует ваш аккаунт, отправляя мошеннику ваши открытые и приватные ключи. В альтернативной форме этого мошенничества от вас могут требовать подтвердить транзакцию, которая отправляет средства на счет мошенника. -[Подробнее о мошенничестве c раздачами](https://www.youtube.com/watch?v=LLL_nQp1lGk) +[Подробнее о мошенничестве с аирдропами](https://www.youtube.com/watch?v=LLL_nQp1lGk) -## Веб-безопасность 101 {#web-security} +## Основы веб-безопасности {#web-security} ### Используйте надежные пароли {#use-strong-passwords} -[Более 80 % взломов учетных записей происходит из-за ненадежных или украденных паролей](https://cloudnine.com/ediscoverydaily/electronic-discovery/80-percent-hacking-related-breaches-related-password-issues-cybersecurity-trends/). Длинная комбинация знаков, цифр и символов поможет защитить ваши аккаунты. +[Более 80% взломов аккаунтов происходят в результате использования слабых или украденных паролей](https://cloudnine.com/ediscoverydaily/electronic-discovery/80-percent-hacking-related-breaches-related-password-issues-cybersecurity-trends/). Длинная комбинация знаков, цифр и символов поможет защитить ваши аккаунты. Распространенная ошибка — использование комбинации нескольких распространенных слов, связанных друг с другом. Подобные пароли ненадежны, потому что они подвержены методу взлома, называемому "перебор по словарю". ```md -Пример ненадежного пароля: CuteFluffyKittens! +Пример слабого пароля: CuteFluffyKittens! -Пример надежного пароля: ymv\*azu.EAC8eyp8umf +Пример надежного пароля: ymv\\*azu.EAC8eyp8umf ``` -Еще одна распространенная ошибка — использование паролей, которые можно легко угадать или узнать с помощью [социальной инженерии](https://wikipedia.org/wiki/Social_engineering_(security)). Включение в ваш пароль девичьей фамилии вашей матери, имен ваших детей или домашних животных и дат рождения увеличивает риск взлома. +Еще одна распространенная ошибка — использование паролей, которые можно легко угадать или узнать с помощью [социальной инженерии](https://wikipedia.org/wiki/Social_engineering_\(security\)). Включение в ваш пароль девичьей фамилии вашей матери, имен ваших детей или домашних животных и дат рождения увеличивает риск взлома. -#### Создание правильных паролей {#good-password-practices} +#### Рекомендации по созданию надежных паролей: {#good-password-practices} - Создавайте пароли такой максимальной длины, разрешенной вашим генератором паролей или формой, которую вы заполняете - Используйте комбинацию прописных и строчных букв, цифр и символов @@ -210,9 +213,9 @@ _Примечание. Существуют производные токены [Подробнее о создании надежных паролей](https://terranovasecurity.com/how-to-create-a-strong-password-in-7-easy-steps/) -### Всегда используйте уникальные пароли {#use-unique-passwords} +### Используйте уникальные пароли для всего {#use-unique-passwords} -Надежный пароль, раскрытый при утечке данных, больше не является надежным паролем. Сайт [Have I Been Pwned](https://haveibeenpwned.com) позволяет проверить, затронуты ли ваши аккаунты какими-либо утечками данных. Если да, **немедленно измените эти пароли**. Использование уникальных паролей для каждого аккаунта снижает риск того, что хакеры получат доступ ко всем вашим аккаунтам, если один из паролей будет взломан. +Надежный пароль, раскрытый при утечке данных, больше не является надежным паролем. Веб-сайт [Have I Been Pwned](https://haveibeenpwned.com) позволяет проверить, не были ли ваши аккаунты затронуты публичными утечками данных. Если да, то **немедленно смените эти пароли**. Использование уникальных паролей для каждого аккаунта снижает риск того, что хакеры получат доступ ко всем вашим аккаунтам, если один из паролей будет взломан. ### Используйте менеджер паролей {#use-password-manager} @@ -220,7 +223,7 @@ _Примечание. Существуют производные токены - Используя менеджер паролей, вы сможете избавиться от хлопот с созданием надежных и уникальных паролей и их запоминанием! Мы настоятельно рекомендуем использовать один из них, и большинство из них бесплатны! + Менеджер паролей позаботится о создании надежных, уникальных паролей и их запоминании! Мы настоятельно рекомендуем использовать один из них, и большинство из них бесплатны! @@ -234,7 +237,7 @@ _Примечание. Существуют производные токены - [Bitwarden](https://bitwarden.com/) - [KeePass](https://keepass.info/) - [1Password](https://1password.com/) -- Или попробуйте другие [рекомендуемые менеджеры паролей](https://www.privacytools.io/secure-password-manager) +- Или ознакомьтесь с другими [рекомендуемыми менеджерами паролей](https://www.privacytools.io/secure-password-manager) ### Используйте двухфакторную аутентификацию {#two-factor-authentication} @@ -244,59 +247,59 @@ _Примечание. Существуют производные токены - Что-то, чем вы являетесь (например, отпечаток пальца, скан радужной оболочки или лица) - Что-то, что у вас есть (ключ безопасности или приложение для аутентификации на вашем телефоне) -Использование **двухфакторной аутентификации (2FA)** обеспечивает дополнительный *фактор безопасности* ваших онлайн-аккаунтов. 2FA гарантирует, что одного только пароля будет недостаточно для доступа к аккаунту. Чаще всего второй фактор представляет собой рандомизированный 6-значный код, известный как **одноразовый временный пароль (TOTP)**, к которому вы можете получить доступ через приложение для аутентификации, такое как Google Authenticator или Authy. Они работают как фактор «что-то, что у вас есть», потому что начальное число, генерирующее временный код, хранится на вашем устройстве. +Использование **двухфакторной аутентификации (2FA)** обеспечивает дополнительный _фактор безопасности_ для ваших онлайн-аккаунтов. 2FA гарантирует, что одного только пароля будет недостаточно для доступа к аккаунту. Чаще всего второй фактор представляет собой случайный 6-значный код, известный как **одноразовый пароль на основе времени (TOTP)**, к которому вы можете получить доступ через приложение для аутентификации, такое как Google Authenticator или Authy. Они работают как фактор «что-то, что у вас есть», потому что начальное число, генерирующее временный код, хранится на вашем устройстве. - Примечание. Двухфакторная аутентификация на основе SMS уязвима к переносу номера телефона на SIM-карту злоумышленника и небезопасна. Для обеспечения максимальной безопасности используйте такой сервис, как Google Authenticator или Authy. + Примечание: двухфакторная аутентификация на основе SMS уязвима для подмены SIM-карты и не является безопасной. Для наилучшей безопасности используйте такие сервисы, как Google Authenticator или Authy. #### Ключи безопасности {#security-keys} -Ключ безопасности — более современный и безопасный тип 2FA. Ключи безопасности — это физические устройства, которые работают как приложения для аутентификации. Использование ключа безопасности — наиболее надежный тип 2FA. Многие из этих ключей используют стандарт FIDO Universal 2nd Factor (U2F). [Подробнее о FIDO U2F](https://www.yubico.com/authentication-standards/fido-u2f/). +Ключ безопасности — более современный и безопасный тип 2FA. Ключи безопасности — это физические устройства, которые работают как приложения для аутентификации. Использование ключа безопасности — наиболее надежный тип 2FA. Многие из этих ключей используют стандарт FIDO Universal 2nd Factor (U2F). [Узнайте больше о FIDO U2F](https://www.yubico.com/resources/glossary/fido-u2f/). Подробнее о 2FA: -### Удалите расширения браузера {#uninstall-browser-extensions} +### Удаляйте расширения для браузера {#uninstall-browser-extensions} Расширения браузера, например Chrome или Firefox, могут расширить функциональность, но они также сопряжены с рисками. По умолчанию большинство расширений браузера запрашивают доступ к «чтению и изменению данных сайта», что позволяет им делать с вашими данными практически все, что угодно. Расширения Chrome всегда автоматически обновляются, поэтому ранее безопасное расширение позже может обновиться, чтобы внести в код вредоносные изменения. Большинство расширений браузера не пытаются украсть ваши данные, но вы должны знать, что они могут это сделать. -#### Будьте в безопасности: {#browser-extension-safety} +#### Оставайтесь в безопасности: {#browser-extension-safety} - Устанавливайте расширения браузера только из надежных источников - Удаляйте неиспользуемые расширения браузера - Устанавливайте расширения Chrome локально, чтобы не допускать автоматическое обновление (дополнительно) -[Подробнее о рисках, связанных с браузерными расширениями](https://www.kaspersky.co.uk/blog/browser-extensions-security/12750/) +[Подробнее о рисках, связанных с расширениями для браузера](https://www.kaspersky.co.uk/blog/browser-extensions-security/12750/) -## Дополнительные ресурсы {#further-reading} +## Дополнительные материалы {#further-reading} ### Веб-безопасность {#reading-web-security} -- [До 3 миллионов устройств заражено вредоносными дополнениями для Chrome и Edge](https://arstechnica.com/information-technology/2020/12/up-to-3-million-devices-infected-by-malware-laced-chrome-and-edge-add-ons/) — _Ден Гудин_ +- [До 3 миллионов устройств заражено вредоносным ПО через дополнения для Chrome и Edge](https://arstechnica.com/information-technology/2020/12/up-to-3-million-devices-infected-by-malware-laced-chrome-and-edge-add-ons/) — _Дэн Гудин_ - [Как создать надежный пароль, который вы не забудете](https://www.avg.com/en/signal/how-to-create-a-strong-password-that-you-wont-forget) — _AVG_ -- [Что такое ключ безопасности?](https://help.coinbase.com/en/coinbase/getting-started/verify-my-account/security-keys-faq) _Coinbase_ +- [Что такое ключ безопасности?](https://help.coinbase.com/en/coinbase/getting-started/verify-my-account/security-keys-faq) — _Coinbase_ -### Безопасность криптовалюты {#reading-crypto-security} +### Криптобезопасность {#reading-crypto-security} -- [Защита себя и свои средства](https://support.mycrypto.com/staying-safe/protecting-yourself-and-your-funds) _MyCrypto_ -- [Проблемы безопасности распространенного программного обеспечения для криптокоммуникаций](https://docs.salusec.io/untitled/web3-penetration-test/risks-in-social-media) — _Salus_ -- [Руководство по безопасности: для чайников и продвинутых](https://medium.com/mycrypto/mycryptos-security-guide-for-dummies-and-smart-people-too-ab178299c82e) _MyCrypto_ -- [Безопасность криптовалют: пароли и аутентификация](https://www.youtube.com/watch?v=m8jlnZuV1i4) _Андреас М. Антонопулос_ +- [Защита себя и своих средств](https://support.mycrypto.com/staying-safe/protecting-yourself-and-your-funds) — _MyCrypto_ +- [Проблемы безопасности в распространенном ПО для общения в криптосфере](https://docs.salusec.io/untitled/web3-penetration-test/risks-in-social-media) — _Salus_ +- [Руководство по безопасности для чайников и умных людей](https://medium.com/mycrypto/mycryptos-security-guide-for-dummies-and-smart-people-too-ab178299c82e) — _MyCrypto_ +- [Криптобезопасность: пароли и аутентификация](https://www.youtube.com/watch?v=m8jlnZuV1i4) — _Андреас М. Антонопулос_ -### Обучение борьбе с мошенничеством {#reading-scam-education} +### Обучение по вопросам мошенничества {#reading-scam-education} -- [Руководство: как определить мошеннические токены](/guides/how-to-id-scam-tokens/) -- [Обеспечение своей безопасности: распространенные виды мошенничества](https://support.mycrypto.com/staying-safe/common-scams) — _MyCrypto_ +- [Руководство: как распознать мошеннические токены](/guides/how-to-id-scam-tokens/) +- [Как оставаться в безопасности: распространенные виды мошенничества](https://support.mycrypto.com/staying-safe/common-scams) — _MyCrypto_ - [Как избежать мошенничества](https://bitcoin.org/en/scams) — _Bitcoin.org_ -- [Тред в Twitter о распространенных криптографических фишинговых письмах и сообщениях](https://twitter.com/tayvano_/status/1516225457640787969) — _Тейлор Монахан_ +- [Тред в Twitter о распространенных фишинговых письмах и сообщениях в криптосфере](https://twitter.com/tayvano_/status/1516225457640787969) — _Тейлор Монахан_ diff --git a/public/content/translations/ru/smart-contracts/index.md b/public/content/translations/ru/smart-contracts/index.md index e151ceac840..117e2102ce9 100644 --- a/public/content/translations/ru/smart-contracts/index.md +++ b/public/content/translations/ru/smart-contracts/index.md @@ -1,14 +1,19 @@ --- -title: Умные контракты -description: Нетехническое введение в умные контракты +title: "Умные контракты" +metaTitle: "Умные контракты: что это такое и в чем их преимущества" +description: "Нетехническое введение в умные контракты" lang: ru --- # Введение в умные контракты {#introduction-to-smart-contracts} -Умные контракты — это основные кирпичи для создания слоя приложений Ethereum. Это компьютерные программы, хранящиеся в [блокчейне](/glossary/#blockchain), которые следуют логике «если это, тогда то» и гарантированно исполняются в соответствии с правилами, определенными кодом, который невозможно изменить после создания. +
    + +
    -Термин «умный контракт» придумал Ник Сабо. В 1994 г. он написал [введение в концепцию](https://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart.contracts.html), а в 1996 г. — [исследование того, что умные контракты могли бы сделать](https://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart_contracts_2.html). +Умные контракты — это основные кирпичи для создания слоя приложений Ethereum. Это компьютерные программы, хранящиеся в [блокчейне](/glossary/#blockchain), которые следуют логике «если это, тогда то», и гарантированно исполняются в соответствии с правилами, определенными в их коде, который невозможно изменить после создания. + +Термин «умный контракт» придумал Ник Сабо. В 1994 году он написал [введение в концепцию](https://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart.contracts.html), а в 1996 году — [исследование о том, на что способны умные контракты](https://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart_contracts_2.html). Сабо предвидел создание цифрового рынка, на котором автоматические [криптографически защищенные](/glossary/#cryptography) процессы позволяют осуществлять транзакции и бизнес-функции без доверенных посредников. Умные контракты в Ethereum претворили это в жизнь. @@ -16,7 +21,7 @@ lang: ru -## Доверие при заключении традиционных контрактов {#trust-and-contracts} +## Доверие в традиционных контрактах {#trust-and-contracts} Одна из главных проблем традиционных контрактов — это необходимость привлекать доверенных третьих лиц, чтобы обеспечить выполнение условий. @@ -24,7 +29,7 @@ lang: ru Алиса и Боб устраивают велогонку. Допустим, Алиса ставит 10 долларов на то, что она выиграет гонку. Боб же уверен в себе, считает, что победит он, и принимает ставку. В результате Алиса обгоняет Боба, заканчивает гонку первой и становится очевидным победителем. Но Боб отказывается платить и обвиняет Алису в жульничестве. -Этот простой мысленный эксперимент обнаруживает проблему с любым «не умным» контрактом. Даже если все условия выполнены (например, вы выиграли гонку), вам по прежнему остается верить, что другая сторона выполнит свою часть соглашения (например, заплатит то, что поставила). +Этот простой мысленный эксперимент обнаруживает проблему с любым «не умным» контрактом. Даже если условия соглашения соблюдены (т. е. вы выиграли гонку), вам все равно приходится доверять другому человеку, что он выполнит соглашение (т. е. выплатит выигрыш по ставке). ## Цифровой торговый автомат {#vending-machine} @@ -38,7 +43,7 @@ lang: ru Торговый автомат отдаст оплаченный товар, только когда все требования будут удовлетворены. Если товар не выбран или внесено недостаточно денег, торговый автомат не выдаст ничего. -## Автоматическое выполнение {#automation} +## Автоматическое исполнение {#automation} Главное преимущество умного контракта в том, что он однозначно выполняет недвусмысленный код при соблюдении определенных условий. Нет нужды ждать человека для выполнения любых требуемых операций. Это устраняет необходимость в доверенных посредниках. @@ -48,7 +53,7 @@ lang: ru Традиционные контракты неоднозначны, потому что они полагаются на людей в их интерпретации и реализации. Например, двое судей могут по-разному толковать контракт, что может привести к непоследовательным решениям и неравным результатам. Умные контракты исключают такую возможность. Вместо этого умные контракты выполняются точно так, как написан их код. «Точность» означает, что при одинаковых обстоятельствах результат всегда будет одинаковым. -## Публичный характер информации {#public-record} +## Публичная запись {#public-record} Умные контракты хорошо поддаются проверке и отслеживанию. Так как умные контракты Ethereum находятся в публичном блокчейне, кто угодно и в любой момент может отследить перемещение активов и связанную с ним информацию. Например, вы можете проверить, отправил ли кто-то деньги на ваш адрес. @@ -56,27 +61,30 @@ lang: ru Смарт-контракты также защищают вашу конфиденциальность. Так как Ethereum — это псевдонимная сеть (транзакции публично отображаются от имени уникального криптографического адреса, но личность, стоящая за адресом, неизвестна), вы можете защищать свою конфиденциальность. -## Понятные условия {#visible-terms} +## Видимые условия {#visible-terms} Наконец, как и в случае с обычными контрактами, вы можете проверить, что находится в умном контракте, прежде чем подписать его (или взаимодействовать с ним другим способом). Прозрачность смарт-контракта гарантирует, что любой может тщательно изучить его. -## Варианты использования смарт-контрактов {#use-cases} +## Варианты использования умных контрактов {#use-cases} В целом умные контракты могут делать практически все то же самое, что и другие компьютерные программы. Они могут выполнять вычисления, создавать валюту, хранить данные, выпускать [NFT](/glossary/#nft), отправлять сообщения и даже генерировать графику. Вот несколько реальных примеров: -- [Стейблкойны](/stablecoins/) +- [Стейблкоины](/stablecoins/) - [Создание и распространение уникальных цифровых активов](/nft/) -- [Автоматический и открытый обмен валюты](/get-eth/#dex) +- [Автоматический, открытый обмен валюты](/get-eth/#dex) - [Децентрализованные игры](/apps/categories/gaming) -- [Страховой полис с автоматической оплатой](https://etherisc.com/) -- [Стандарт, который позволяет людям создавать индивидуальные и совместимые валюты](/developers/docs/standards/tokens/) +- [Страховой полис с автоматическими выплатами](https://etherisc.com/) +- [Стандарт, который позволяет людям создавать настраиваемые, совместимые валюты](/developers/docs/standards/tokens/) -## Дополнительная литература {#further-reading} +## Дополнительные материалы {#further-reading} - [Как умные контракты изменят мир](https://www.youtube.com/watch?v=pA6CGuXEKtQ) -- [Умные контракты: блокчейн-технология, которая заменит юристов](https://blockgeeks.com/guides/smart-contracts/) - [Умные контракты для разработчиков](/developers/docs/smart-contracts/) -- [Научитесь создавать Умные контракты](/developers/learning-tools/) -- [Освоение Ethereum: что такое умный контракт?](https://github.com/ethereumbook/ethereumbook/blob/openedition/07smart-contracts-solidity.asciidoc#what-is-a-smart-contract) +- [Научитесь писать умные контракты](/developers/learning-tools/) +- [Mastering Ethereum — Что такое умный контракт?](https://github.com/ethereumbook/ethereumbook/blob/openedition/07smart-contracts-solidity.asciidoc#what-is-a-smart-contract) + + + + diff --git a/public/content/translations/ru/social-networks/index.md b/public/content/translations/ru/social-networks/index.md index 25da81b6526..f0e3a50122a 100644 --- a/public/content/translations/ru/social-networks/index.md +++ b/public/content/translations/ru/social-networks/index.md @@ -1,21 +1,21 @@ --- -title: Децентрализованные социальные сети -description: Обзор децентрализованных социальных сетей на Ethereum +title: "Децентрализованные социальные сети" +description: "Обзор децентрализованных социальных сетей на Ethereum" lang: ru template: use-cases emoji: ":mega:" sidebarDepth: 2 image: /images/ethereum-learn.png -summaryPoint1: Платформы на основе блокчейна для социального взаимодействия, создания и распространения контента. -summaryPoint2: Децентрализованные социальные сети защищают конфиденциальность пользователей и повышают безопасность данных. -summaryPoint3: Токены и NFT создают новые способы монетизации контента. +summaryPoint1: "Платформы на основе блокчейна для социального взаимодействия, создания и распространения контента." +summaryPoint2: "Децентрализованные социальные сети защищают конфиденциальность пользователей и повышают безопасность данных." +summaryPoint3: "Токены и NFT создают новые способы монетизации контента." --- Социальные сети играют огромную роль в нашем повседневном общении и взаимодействии. Однако централизованный контроль над этими платформами создал множество проблем: утечки данных, перебои в работе серверов, деплатформирование, цензура и нарушение конфиденциальности — некоторые из компромиссов, на которые часто идут социальные сети. Для борьбы с этими проблемами разработчики создают социальные сети на Ethereum. Децентрализованные социальные сети могут решить многие проблемы традиционных социальных сетей и улучшить общий опыт пользователей. ## Что такое децентрализованные социальные сети? {#what-are-decentralized-social-networks} -Децентрализованные социальные сети — это платформы [на основе блокчейна](/glossary/#blockchain), которые позволяют пользователям обмениваться информацией, а также публиковать и распространять контент. Поскольку эти приложения работают на блокчейне, они могут быть децентрализованными и устойчивыми к цензуре и неправомерному контролю. +Децентрализованные социальные сети — это платформы на основе [блокчейна](/glossary/#blockchain), которые позволяют пользователям обмениваться информацией, а также публиковать и распространять контент среди аудитории. Поскольку эти приложения работают на блокчейне, они могут быть децентрализованными и устойчивыми к цензуре и неправомерному контролю. Многие децентрализованные социальные сети существуют в качестве альтернативы существующим социальным сетям, таким как Facebook, LinkedIn, Twitter и Medium. Но в социальных сетях блокчейн существует целый ряд особенностей, которые выгодно отличают их от традиционных социальных платформ. @@ -23,29 +23,29 @@ summaryPoint3: Токены и NFT создают новые способы мо ### Как работают децентрализованные социальные сети? {#decentralized-social-networks-overview} -Децентрализованные социальные сети представляют собой класс [децентрализованных приложений](/apps/) — приложений на базе [смарт-контрактов](/glossary/#smart-contract), развернутых на блокчейне. Код контракта служит серверной частью этих приложений и определяет их бизнес-логику. +Децентрализованные социальные сети — это класс [децентрализованных приложений (dapps)](/apps/), работающих на [смарт-контрактах](/glossary/#smart-contract), которые развернуты на блокчейне. Код контракта служит серверной частью этих приложений и определяет их бизнес-логику. -Традиционные социальные сети используют базы данных для хранения информации о пользователе, программного кода и других форм данных. Но это создает единые точки отказа и вносит значительный риск. Например, в октябре 2021 года серверы Facebook [перешли в офлайн-режим на несколько часов](https://www.npr.org/2021/10/05/1043211171/facebook-instagram-whatsapp-outage-business-impact), отрезав пользователей от платформы. +Традиционные социальные сети используют базы данных для хранения информации о пользователе, программного кода и других форм данных. Но это создает единые точки отказа и вносит значительный риск. Например, в октябре 2021 года серверы Facebook, как печально известно, [отключались на несколько часов](https://www.npr.org/2021/10/05/1043211171/facebook-instagram-whatsapp-outage-business-impact), отрезав пользователей от платформы. -Децентрализованные социальные сети существуют в [сети](/glossary/#peer-to-peer-network), состоящей из тысяч узлов по всему миру. Даже если некоторые узлы откажут, сеть будет работать непрерывно, а приложения будут устойчивыми к сбоям и отключениям электричества. +Децентрализованные социальные сети существуют в [одноранговой сети](/glossary/#peer-to-peer-network), состоящей из тысяч узлов по всему миру. Даже если некоторые узлы откажут, сеть будет работать непрерывно, а приложения будут устойчивыми к сбоям и отключениям электричества. -С помощью децентрализованных систем хранения, таких как [InterPlanetary File System (IPFS)](https://ipfs.io/), социальные сети на основе Ethereum могут защитить информацию пользователей от злоумышленного использования. Никто не будет продавать вашу личную информацию рекламодателям, а хакеры не смогут украсть ваши конфиденциальные данные. +Используя децентрализованные системы хранения, такие как [InterPlanetary File System (IPFS)](https://ipfs.io/), социальные сети, построенные на Ethereum, могут защитить информацию пользователей от эксплуатации и злонамеренного использования. Никто не будет продавать вашу личную информацию рекламодателям, а хакеры не смогут украсть ваши конфиденциальные данные. Многие социальные платформы на основе блокчейна имеют собственные токены, которые обеспечивают монетизацию при отсутствии доходов от рекламы. Пользователи могут покупать эти токены, чтобы получить доступ к определенным функциям, совершать покупки в приложении или отправлять чаевые своим любимым создателям контента. ## Преимущества децентрализованных социальных сетей {#benefits} -1. Децентрализованные социальные сети устойчивы к цензуре и открыты для всех. Это означает, что **пользователей нельзя безосновательно заблокировать**, убрать с платформы или ограничить. +1. Децентрализованные социальные сети устойчивы к цензуре и открыты для всех. Это означает, что **пользователей нельзя забанить**, деплатформировать или произвольно ограничить. -2. Децентрализованные социальные сети **основаны на принципах открытого исходного кода** и делают исходный код приложений доступным для публичного контроля. Устраняя реализацию непрозрачных алгоритмов, распространенных в традиционных социальных сетях, социальные сети на основе блокчейна могут уравнивать интересы пользователей и создателей платформы. +2. Децентрализованные социальные сети **построены на идеалах открытого исходного кода** и делают исходный код приложений доступным для всеобщего обозрения. Устраняя реализацию непрозрачных алгоритмов, распространенных в традиционных социальных сетях, социальные сети на основе блокчейна могут уравнивать интересы пользователей и создателей платформы. -3. Децентрализованные социальные сети исключают «посредников». **Создатели контента имеют прямое право собственности на свой контент** и напрямую взаимодействуют с подписчиками, поклонниками, покупателями и другими сторонами. Их не связывает ничего, кроме смарт-контракта. +3. Децентрализованные социальные сети исключают «посредников». **Создатели контента имеют прямое право собственности на свой контент**, и они напрямую взаимодействуют с подписчиками, поклонниками, покупателями и другими сторонами, не имея ничего, кроме смарт-контракта между ними. -4. Как и децентрализованные приложения в сети Ethereum, работа которой поддерживается глобальной сетью с равноправными узлами, децентрализованные социальные сети **менее подвержены отказу серверов** и отключениям электричества. +4. Являясь децентрализованными приложениями, работающими в сети Ethereum, которая поддерживается глобальной одноранговой сетью узлов, децентрализованные социальные сети **менее подвержены простоям** и отключениям серверов. -5. Децентрализованные социальные сети предлагают **улучшенную структуру монетизации** для создателей контента с помощью [невзаимозаменяемых токенов (NFT)](/glossary/#nft), криптовалютных платежей в приложениях и т. д. +5. Децентрализованные социальные платформы предлагают **улучшенную систему монетизации** для создателей контента с помощью [невзаимозаменяемых токенов (NFT)](/glossary/#nft), криптовалютных платежей в приложении и многого другого. -6. Децентрализованные социальные сети предоставляют пользователям **высокий уровень конфиденциальности и анонимности**. Например, человек может войти в социальную сеть на основе Ethereum, используя профиль или [кошелек](/glossary/#wallet) [ENS](/glossary/#ens), не указывая личную информацию, такую как имя, адрес электронной почты и т. д. +6. Децентрализованные социальные сети предоставляют пользователям **высокий уровень конфиденциальности и анонимности**. Например, человек может войти в социальную сеть на базе Ethereum, используя [профиль ENS](/glossary/#ens) или [кошелек](/glossary/#wallet), без необходимости делиться личной идентифицирующей информацией (PII), такой как имена, адреса электронной почты и т. д. 7. Децентрализованные социальные сети полагаются не на централизованные базы данных, а на децентрализованные хранилища, которые значительно лучше защищают пользовательские данные. @@ -55,51 +55,85 @@ summaryPoint3: Токены и NFT создают новые способы мо ### Mirror {#mirror} -[Mirror](https://mirror.xyz/) — это платформа для писателей с поддержкой web3, которая должна быть децентрализованной и принадлежать пользователям. Пользователи могут бесплатно читать и писать на Mirror, просто подключив свои кошельки. Пользователи также могут коллекционировать записи и подписываться на своих любимых писателей. +[Mirror](https://mirror.xyz/) — это писательская платформа с поддержкой Web3, которая стремится быть децентрализованной и принадлежать пользователям. Пользователи могут бесплатно читать и писать на Mirror, просто подключив свои кошельки. Пользователи также могут коллекционировать записи и подписываться на своих любимых писателей. -Сообщения, опубликованные на Mirror, постоянно хранятся в Arweave, децентрализованном хранилище, и могут быть выпущены в виде коллекционных [невзаимозаменяемых токенов (NFT)](/nft/), известных как Writing NFT. Создание Writing NFT совершенно бесплатно для авторов, а сбор происходит на [втором уровне](/glossary/#layer-2) Ethereum, что делает транзакции недорогими, быстрыми и экологичными. +Публикации на Mirror навсегда сохраняются в Arweave, децентрализованной платформе хранения, и могут быть отчеканены в виде коллекционных [невзаимозаменяемых токенов (NFT)](/nft/), известных как Writing NFT. Создание Writing NFT совершенно бесплатно для писателей, а их сбор происходит на [L2](/glossary/#layer-2) Ethereum, что делает транзакции недорогими, быстрыми и экологически безопасными. ### MINDS {#minds} -[MINDS](https://www.minds.com/) — одна из самых популярных децентрализованных социальных сетей. Она работает как Facebook и уже набрала миллионы пользователей. +[MINDS](https://www.minds.com/) — одна из самых используемых децентрализованных социальных сетей. Она работает как Facebook и уже набрала миллионы пользователей. -Пользователи используют нативный токен [ERC-20](/glossary/#erc-20) $MIND для оплаты товаров. Пользователи также могут зарабатывать токены $MIND, публикуя популярный контент, содействуя работе экосистемы и приводя других на платформу. +Пользователи используют собственный токен платформы стандарта [ERC-20](/glossary/#erc-20) $MIND для оплаты товаров. Пользователи также могут зарабатывать токены $MIND, публикуя популярный контент, содействуя работе экосистемы и приводя других на платформу. -## Используйте децентрализованные социальные сети {#use-decentralized-social-networks} +### Farcaster {#farcaster} -- **[Status.im](https://status.im/)**. _Status — это безопасное приложение для обмена сообщениями, в котором используется протокол одноранговой связи с открытым исходным кодом и сквозное шифрование для защиты ваших сообщений от третьих лиц._ -- **[Mirror.xyz](https://mirror.xyz/)**. _Mirror — это децентрализованная издательская платформа, которая принадлежит только пользователям. Она построена на Ethereum и позволяет пользователям собирать идеи, монетизировать контент и создавать ценные сообщества._ -- **[Lens Protocol](https://lens.xyz/)**. _Lens Protocol — это составной и децентрализованный социальный граф, помогающий создателям владеть своим контентом, где бы они ни находились в цифровом саду децентрализованного Интернета._ -- **[Farcaster](https://farcaster.xyz/)**. _Farcaster — это децентрализованная социальная сеть. Это открытый протокол, который может поддерживать множество клиентов, как и электронная почта._ +[Farcaster](https://farcaster.xyz/) — это «достаточно децентрализованная» социальная сеть, похожая на X и Reddit, которая позволяет пользователям делиться «кастами» и находить их. Она построена на сети второго уровня (L2) Optimism, чтобы транзакции оставались относительно дешевыми. + +## Использование децентрализованных социальных сетей {#use-decentralized-social-networks} + +- **[Status.app](https://status.app/)** — _Status — это безопасное приложение для обмена сообщениями, использующее протокол с открытым исходным кодом, одноранговую связь и сквозное шифрование для защиты ваших сообщений от третьих лиц._ +- **[Mirror.xyz](https://mirror.xyz/)** — _Mirror — это децентрализованная издательская платформа на Ethereum, принадлежащая пользователям и позволяющая им проводить краудфандинг идей, монетизировать контент и создавать ценные сообщества._ +- **[Lens Protocol](https://lens.xyz/)** — _Lens Protocol — это компонуемый и децентрализованный социальный граф, который помогает создателям контента сохранять право собственности на него, где бы они ни находились в «цифровом саду» децентрализованного интернета._ +- **[Farcaster](https://farcaster.xyz/)** — _Farcaster — это достаточно децентрализованная социальная сеть._ Это открытый протокол, который может поддерживать множество клиентов, как и электронная почта._ +- **[Ethereum Follow Protocol](https://efp.app/)** — _Ethereum Follow Protocol — это полностью децентрализованный ончейн-социальный граф для учетных записей Ethereum, продвигающий концепцию модульного стека идентификации Ethereum и дополняющий ENS и SIWE._ +- **[Ethereum Comments Protocol](https://www.ethcomments.xyz/)** — _Новый программируемый примитив для социального контента на Ethereum, чтобы публиковать свои мысли ончейн._ ## Социальные сети Web2 на Ethereum {#web2-social-networks-and-ethereum} -Нативные социальные платформы [Web3](/glossary/#web3) не единственные пытаются внедрить технологию блокчейна в социальные сети. Многие централизованные платформы также планируют интегрировать Ethereum в свою инфраструктуру: +Нативные социальные платформы [Web3](/glossary/#web3) — не единственные, кто пытается внедрить технологию блокчейна в социальные сети. Многие централизованные платформы также изучают возможность или уже экспериментировали с интеграцией Ethereum в свою инфраструктуру: + +### Браузер Brave {#brave} + +- Brave интегрировал в экосистему своего браузера **[Basic Attention Token (BAT)](https://basicattentiontoken.org/)**, токен стандарта ERC-20, созданный на Ethereum, чтобы произвести революцию в цифровой рекламе и поддержке создателей контента. + +- Программа **[Brave Rewards](https://brave.com/brave-rewards/)** позволяет пользователям зарабатывать BAT за просмотр рекламы, не нарушающей конфиденциальность, а затем автоматически перечислять их веб-сайтам и создателям контента на различных платформах, таких как YouTube, Twitter и GitHub, в зависимости от времени уделенного внимания. + +- Создатели контента могут зарегистрироваться как **[проверенные авторы Brave](https://creators.brave.com/)**, чтобы получать эти взносы прямо на свои кошельки Ethereum, создавая мост между традиционными веб-платформами и монетизацией на основе блокчейна. + +- Токены BAT существуют независимо в блокчейне Ethereum, что позволяет пользователям после заработка переводить их на личные кошельки или биржи. + +### Музыкальная платформа Audius {#audius} + +- **[Audius](https://audius.co/)** — это музыкальная стриминговая платформа, которая использует технологию блокчейна Ethereum для прямого соединения артистов с поклонниками. + +- Платформа имеет гибридную децентрализованную архитектуру, где контент хранится на IPFS, а блокчейн используется для прав собственности и **[токена AUDIO](https://eth.blockscout.com/token/0x18aaa7115705e8be94bffebde57af9bfc265b998)**. + +- Audius установила **[партнерство с TikTok](https://audius.co/tiktok)**, предоставляя функциональность Web3 широкой аудитории и позволяя артистам монетизировать свой контент с помощью технологии блокчейна. + +- Технические детали платформы доступны в их **[вайтпейпере](https://whitepaper.audius.co/)**, где показано, как они использовали инфраструктуру Ethereum. + +### Фэнтези-спорт Sorare {#sorare} + +- **[Sorare](https://sorare.com/)** — это **[платформа для фэнтези-спорта, построенная на Ethereum](https://sorare.com/help/a/4402888626577/what-is-a-sorare-wallet)**, которая позволяет пользователям собирать, обменивать и играть с официальными карточками игроков в виде NFT. + +- Карточки игроков являются проверяемыми NFT в блокчейне Ethereum, а смарт-контракты платформы можно просмотреть на **[Etherscan](https://eth.blockscout.com/address/0x629a673a8242c2ac4b7b8c5d8735fbeac21a6205?tab=contract)**. + +- Sorare сочетает традиционный игровой процесс фэнтези-спорта с владением цифровыми активами на блокчейне, предоставляя **[функцию пополнения счета через Ethereum](https://sorare.com/help/a/10969733392797/what-network-should-i-use-to-fund-my-eth-wallet)** для широкой аудитории любителей спорта. -### Reddit {#reddit} +### Twitter/X (криптовалютные чаевые) {#twitter} -Reddit [запустил баллы Community Points](https://cointelegraph.com/news/reddit-to-reportedly-tokenize-karma-points-and-onboard-500m-new-users), представляющие собой токены ERC-20, которые пользователи могут заработать, публикуя качественный контент и участвуя в жизни онлайн-сообществ (субреддитов). Вы можете обменять эти токены в субреддите на эксклюзивные привилегии и преимущества. Для реализации этого проекта Reddit сотрудничает с Arbitrum, сетью [уровня 2](/glossary/#layer-2), предназначенной для масштабирования транзакций Ethereum. +**[Twitter](https://x.com)** (теперь X) внедрил технологию блокчейна несколькими способами для улучшения монетизации авторов и проверки цифровой личности: -Программа уже запущена, и субреддит r/CryptoCurrency [запустил свою версию Community Points под названием «Moons»](https://www.reddit.com/r/CryptoCurrency/wiki/moons_wiki). Согласно официальному описанию, Moons "поощряет авторов, комментаторов и модераторов за их вклад в сабреддит". Поскольку эти токены находятся в блокчейне (пользователи получают их в свой кошелек), они не зависят от Reddit и не могут быть отобраны. +- **Криптовалютные чаевые**: платформа интегрировала **[чаевые в Ethereum](https://help.x.com/en/using-x/tips)**, что позволяет пользователям отправлять платежи через кошельки на базе Ethereum, такие как Strike. -Помимо использования Community Points для разблокировки специальных возможностей, пользователи могут обменивать их на биржах на фиатные деньги. Кроме того, количество Community Points, которыми владеет пользователь, определяет его влияние на процесс принятия решений в сообществе. +Интегрируя функции блокчейна, X наводит мост между социальным опытом Web2 и децентрализованным владением цифровыми активами. -## Дополнительные ресурсы {#further-reading} +## Дополнительные материалы {#further-reading} ### Статьи {#articles} -- [Децентрализация социальных сетей: руководство по социальному стеку web3](https://www.coinbase.com/blog/decentralizing-social-media-a-guide-to-the-web3-social-stack) — _Coinbase Ventures_ -- [Социальные сети — новая возможность для масштабной децентрализации](https://www.coindesk.com/tech/2021/01/22/social-networks-are-the-next-big-decentralization-opportunity/) — _Бен Герцль_ -- [Web3 выполняет обещание о децентрализованных, управляемых сообществом социальных сетях](https://venturebeat.com/2022/02/26/web3-holds-the-promise-of-decentralized-community-powered-social-networks/) — _Сумит Гош_ -- [Обзор ландшафта социальных сетей на блокчейне](https://www.gemini.com/cryptopedia/blockchain-social-media-decentralized-social-media) — _Криптопедия Gemini_ -- [Как блокчейн может решить проблему с конфиденциальностью социальных сетей](https://www.investopedia.com/news/ethereum-blockchain-social-media-privacy-problem-linkedin-indorse/) — _Праблин Баджпай_ -- [Достаточная децентрализация для социальных сетей](https://www.varunsrinivasan.com/2022/01/11/sufficient-decentralization-for-social-networks) — _Варун Сринивасан_ +- [Децентрализация социальных сетей: руководство по социальному стеку Web3](https://www.coinbase.com/blog/decentralizing-social-media-a-guide-to-the-web3-social-stack) — _Coinbase Ventures_ +- [Социальные сети — следующая большая возможность для децентрализации](https://www.coindesk.com/tech/2021/01/22/social-networks-are-the-next-big-decentralization-opportunity/) — _Бен Герцель_ +- [Web3 несет в себе перспективу децентрализованных социальных сетей, управляемых сообществом](https://venturebeat.com/2022/02/26/web3-holds-the-promise-of-decentralized-community-powered-social-networks/) — _Сумит Гхош_ +- [Обзор ландшафта социальных сетей на блокчейне](https://www.gemini.com/cryptopedia/blockchain-social-media-decentralized-social-media) — _Gemini Cryptopedia_ +- [Как блокчейн может решить проблему конфиденциальности в социальных сетях](https://www.investopedia.com/news/ethereum-blockchain-social-media-privacy-problem-linkedin-indorse/) — _Праблин Баджпай_ +- [Достаточная децентрализация для социальных сетей](https://www.varunsrinivasan.com/2022/01/11/sufficient-decentralization-for-social-networks) — _Варун Шринивасан_ ### Видео {#videos} -- [Объяснение децентрализованной социальной сети](https://www.youtube.com/watch?v=UdT2lpcGvcQ) — _Coinmarketcap_ +- [Объяснение децентрализованных социальных сетей](https://www.youtube.com/watch?v=UdT2lpcGvcQ) — _Coinmarketcap_ - [Блокчейн DeSo хочет децентрализовать социальные сети](https://www.youtube.com/watch?v=SG2HUiVp0rE) — _Bloomberg Technology_ -- [Будущее децентрализованных социальных сетей: объясняют Баладжи Сринивасан, Виталик Бутерин, Хуан Бенет](https://www.youtube.com/watch?v=DTxE9KV3YrE) — _ETHGlobal_ +- [Будущее децентрализованных социальных сетей с участием Баладжи Шринивасана, Виталика Бутерина и Хуана Бенета](https://www.youtube.com/watch?v=DTxE9KV3YrE) — _ETHGlobal_ ### Сообщества {#communities} diff --git a/public/content/translations/ru/staking/dvt/index.md b/public/content/translations/ru/staking/dvt/index.md index 0e421ea7cf9..98484a313cf 100644 --- a/public/content/translations/ru/staking/dvt/index.md +++ b/public/content/translations/ru/staking/dvt/index.md @@ -1,16 +1,16 @@ --- -title: Технология распределенного валидатора -description: Технология распределенного валидатора обеспечивает распределенную работу валидатора Ethereum у нескольких сторон. +title: "Технология распределенного валидатора" +description: "Технология распределенного валидатора обеспечивает распределенную работу валидатора Ethereum у нескольких сторон." lang: ru --- -# Технология распределенного валидатора {#distributed-validator-technology} +# Технология распределенных валидаторов {#distributed-validator-technology} Технология распределенного валидатора (DVT) — это подход к безопасности валидатора, который распределяет обязанности по управлению ключами и подписанию между несколькими сторонами, чтобы уменьшить количество единых точек отказа и повысить отказоустойчивость валидатора. Это происходит за счет **разделения приватного ключа**, используемого для защиты валидатора, **между несколькими компьютерами**, организованными в «кластер». Преимущество этого заключается в том, что это затрудняет доступ злоумышленников к ключу, поскольку он не хранится полностью на одной машине. Это также позволяет некоторым узлам выходить из сети, так как необходимую подпись можно получить от подмножества машин в каждом кластере. Это уменьшает количество единичных точек отказа в сети и делает всю группу валидаторов более надежной. -![Диаграмма, показывающая, как один ключ валидатора разбивается на части ключа и распределяется по нескольким узлам с разными компонентами.](./dvt-cluster.png) +![Диаграмма, показывающая, как один ключ валидатора разбивается на доли ключа и распределяется по нескольким узлам с различными компонентами.](./dvt-cluster.png) ## Зачем нужна технология распределенного валидатора (DVT)? {#why-do-we-need-dvt} @@ -20,7 +20,7 @@ lang: ru С помощью DVT валидаторы могут участвовать в стейкинге, одновременно храня приватный ключ валидатора в холодном хранилище. Это достигается путем шифрования исходного полного ключа валидатора, а затем разделения его на части ключа. Части ключа находятся в сети и распределены по нескольким узлам, что позволяет децентрализованно управлять валидатором. Это возможно благодаря использованию валидаторами Ethereum BLS-подписей, которые являются аддитивными. Это означает, что полный ключ может быть восстановлен путем сложения его компонентных частей. Это позволяет валидатору безопасно хранить полный исходный «мастер-ключ» валидатора в автономном режиме. -### Без единичных точек отказа {#no-single-point-of-failure} +### Отсутствие единой точки отказа {#no-single-point-of-failure} Когда валидатор делится между несколькими операторами и несколькими компьютерами, он может выдерживать отказы отдельных аппаратных и программных компонентов, не прекращая свою работу. Риск сбоев также может быть снижен путем использования различных аппаратных и программных конфигураций на узлах в кластере. Эта устойчивость недоступна для конфигураций валидатора с одним узлом — она обеспечивается слоем DVT. @@ -34,31 +34,31 @@ lang: ru **DVT предлагает следующие преимущества для Ethereum:** -1. **Децентрализация** консенсуса доказательства доли владения Ethereum. -2. Обеспечение **жизнестойкость** сети. -3. Обеспечение **отказоустойчивости** валидатора. -4. Работа валидатора с **минимальным уровнем необходимого доверия**. -5. **Сведение к минимуму рисков сокращения** и простоев. -6. **Увеличение разнообразия** (клиент, дата-центр, местоположение, законы и т. д.). -7. **Повышенная безопасность** управления ключом валидатора. +1. **Децентрализация** консенсуса доказательства владения Ethereum +2. Обеспечение **живучести** сети +3. Обеспечение **отказоустойчивости** валидатора +4. Работа валидатора с **минимальным уровнем доверия** +5. **Минимизация рисков слэшинга** и простоя +6. **Улучшение разнообразия** (клиент, дата-центр, местоположение, регулирование и т. д.) +7. **Повышенная безопасность** управления ключом валидатора ## Как работает DVT? {#how-does-dvt-work} Решение DVT содержит следующие компоненты: -- **[Деление секрета по протоколу Шамира](https://medium.com/@keylesstech/a-beginners-guide-to-shamir-s-secret-sharing-e864efbf3648)**: валидаторы используют [BLS ключи](https://en.wikipedia.org/wiki/BLS_digital_signature). Отдельные «части ключей» BLS могут быть объединены в единый агрегированный ключ (подпись). В DVT приватным ключом для валидатора является комбинированная подпись BLS каждого оператора в кластере. -- **[Пороговая схема подписи](https://medium.com/nethermind-eth/threshold-signature-schemes-36f40bc42aca)**: определяет количество отдельных частей ключа, которые необходимы для обязанностей в связи с подписанием (пример: З из 4). -- **[Генерация распределенного ключа (DKG)](https://medium.com/toruslabs/what-distributed-key-generation-is-866adc79620)**: криптографический процесс, который генерирует части ключа и используется для распределения частей существующего или нового ключа валидатора по узлам кластера. -- **[Многостороннее вычисление (MPC)](https://messari.io/report/applying-multiparty-computation-to-the-world-of-blockchains)**: полный ключ валидатора генерируется в тайне с помощью многосторонних вычислений. Полный ключ никогда не известен индивидуальному оператору: он всегда знает только свою часть (свою «долю»). -- **Протокол консенсуса**: консенсусный протокол выбирает один узел в качестве предлагающего блок. Они делят блок с другими узлами кластера, которые добавляют свои части ключа в агрегированную подпись. Когда собрано достаточное количество частей ключа, предлагается блок на Ethereum. +- **[Схема разделения секрета Шамира](https://medium.com/@keylesstech/a-beginners-guide-to-shamir-s-secret-sharing-e864efbf3648)** — валидаторы используют [ключи BLS](https://en.wikipedia.org/wiki/BLS_digital_signature). Отдельные «части ключей» BLS могут быть объединены в единый агрегированный ключ (подпись). В DVT приватным ключом для валидатора является комбинированная подпись BLS каждого оператора в кластере. +- **[Пороговая схема подписи](https://medium.com/nethermind-eth/threshold-signature-schemes-36f40bc42aca)** — определяет количество отдельных долей ключа, необходимых для выполнения обязанностей по подписанию, например 3 из 4. +- **[Распределенная генерация ключей (DKG)](https://medium.com/toruslabs/what-distributed-key-generation-is-866adc79620)** — криптографический процесс, который генерирует доли ключа и используется для распределения долей существующего или нового ключа валидатора по узлам в кластере. +- **[Многосторонние вычисления (MPC)](https://messari.io/report/applying-multiparty-computation-to-the-world-of-blockchains)** — полный ключ валидатора генерируется тайно с использованием многосторонних вычислений. Полный ключ никогда не известен индивидуальному оператору: он всегда знает только свою часть (свою «долю»). +- **Протокол консенсуса** — протокол консенсуса выбирает один узел, который будет предлагать блок. Они делят блок с другими узлами кластера, которые добавляют свои части ключа в агрегированную подпись. Когда собрано достаточное количество частей ключа, предлагается блок на Ethereum. Распределенные валидаторы имеют встроенную отказоустойчивость и могут продолжать работать, даже если некоторые отдельные узлы отключаются. Это означает, что кластер устойчив, даже если некоторые из его узлов оказываются вредоносными или ленивыми. -## Варианты использования DVT {#dvt-use-cases} +## Случаи использования DVT {#dvt-use-cases} DVT имеет большое значение для более широкой отрасли стейкинга. -### Одиночный стейкинг {#solo-stakers} +### Соло-стейкеры {#solo-stakers} DVT также дает возможность выполнять стейкинг без внешнего контроля, позволяя распределять ключ валидатора по удаленным узлам, при этом сохраняя целый ключ полностью вне сети. Это означает, что домашним дольщикам необязательно тратить деньги на аппаратные средства, в то время как распределение частей ключа может помочь защитить их от потенциальных хакеров. @@ -68,24 +68,24 @@ DVT также дает возможность выполнять стейкин DVT разделяет ответственность за управление ключами между несколькими узлами, что означает, что некоторые операционные расходы также могут быть разделены. DVT может также снизить операционные риски и страховые расходы для поставщиков стейкинга. -### Staking pools {#staking-pools} +### Пулы для стейкинга {#staking-pools} Из-за стандартных настроек валидаторов стейкинг-пулы и поставщики ликвидного стейкинга вынуждены иметь различные уровни доверия одному оператору, так как прибыли и убытки разделяются по всему пулу. Они также полагаются на операторов для защиты ключей подписи, потому что до сих пор для них не существовало другого выбора. Хотя традиционно прилагаются усилия для распределения рисков путем распределения долей между несколькими операторами, каждый оператор по-прежнему самостоятельно управляет значительной долей. Опора на одного оператора сопряжена с огромными рисками в случаях, когда он не справляется со своими обязанностями, сталкивается с простоями, подвергается взлому или действует злонамеренно. -Использование DVT значительно снижает уровень доверия, требуемый от операторов. **Пулы позволяют операторам удерживать доли без необходимости хранения ключей валидатора** (поскольку используются только части ключа). Это также позволяет распределять управляемые доли между большим числом операторов (например, вместо того, чтобы один оператор управлял 1000 валидаторов, DVT позволяет этим валидаторам совместно управляться несколькими операторами). Разнообразие конфигураций операторов гарантирует, что если один оператор выйдет из строя, другие все еще смогут выполнять подтверждение. Это приводит к избыточности и диверсификации, что повышает производительность и устойчивость при максимальном вознаграждении. +Использование DVT значительно снижает уровень доверия, требуемый от операторов. **Пулы могут позволить операторам держать доли без необходимости хранения ключей валидатора** (поскольку используются только доли ключа). Это также позволяет распределять управляемые доли между большим числом операторов (например, вместо того, чтобы один оператор управлял 1000 валидаторов, DVT позволяет этим валидаторам совместно управляться несколькими операторами). Разнообразие конфигураций операторов гарантирует, что если один оператор выйдет из строя, другие все еще смогут выполнять подтверждение. Это приводит к избыточности и диверсификации, что повышает производительность и устойчивость при максимальном вознаграждении. Еще одно преимущество минимизации доверия к одному оператору заключается в том, что размещение стейкинг-пулов может позволить более открытое и избавленное от разрешений участие оператора. Таким образом службы могут уменьшить свой риск и поддержать децентрализацию Ethereum, используя как кураторские, так и избавленные от разрешений наборы операторов, например путем объединения домашних или более мелких дольщиков с более крупными. ## Потенциальные недостатки использования DVT {#potential-drawbacks-of-using-dvt} -- **Дополнительный компонент**: введение DVT-узла добавляет еще один компонент, который может быть неисправным или уязвимым. Чтобы смягчить это, нужно стремиться к нескольким реализациям DVT-узла, то есть к нескольким DVT-клиентам (аналогично тому, как существует несколько клиентов для уровней консенсуса и выполнения). -- **Операционные затраты**: поскольку DVT распределяет валидатор между несколькими сторонами, для работы требуется больше узлов, а не только один узел, что приводит к увеличению операционных затрат. -- **Потенциально повышенная задержка**: так как DVT использует протокол консенсуса для достижения консенсуса между несколькими узлами, работающими с валидатором, это потенциально может привести к увеличению задержки. +- **Дополнительный компонент** — добавление узла DVT вводит еще одну часть, которая может быть неисправной или уязвимой. Чтобы смягчить это, нужно стремиться к нескольким реализациям DVT-узла, то есть к нескольким DVT-клиентам (аналогично тому, как существует несколько клиентов для уровней консенсуса и выполнения). +- **Операционные расходы** — поскольку DVT распределяет валидатор между несколькими сторонами, для работы требуется больше узлов, а не один, что приводит к увеличению операционных расходов. +- **Потенциально повышенная задержка** — поскольку DVT использует протокол консенсуса для достижения консенсуса между несколькими узлами, управляющими валидатором, это может привести к увеличению задержки. -## Дополнительные ресурсы {#further-reading} +## Дополнительные материалы {#further-reading} -- [Спецификации распределенного валидатора Ethereum (высокий уровень)](https://github.com/ethereum/distributed-validator-specs) +- [Спецификации распределенного валидатора Ethereum (высокоуровневые)](https://github.com/ethereum/distributed-validator-specs) - [Технические спецификации распределенного валидатора Ethereum](https://github.com/ethereum/distributed-validator-specs/tree/dev/src/dvspec) -- [Приложение для демонстрации разделения секрета по протоколу Шамира](https://iancoleman.io/shamir/) +- [Демонстрационное приложение схемы разделения секрета Шамира](https://iancoleman.io/shamir/) diff --git a/public/content/translations/ru/staking/pools/index.md b/public/content/translations/ru/staking/pools/index.md index fa221cf113e..1f7158e52e9 100644 --- a/public/content/translations/ru/staking/pools/index.md +++ b/public/content/translations/ru/staking/pools/index.md @@ -1,11 +1,11 @@ --- -title: Объединенный стейкинг -description: 'Как начать совместный стейкинг ETH: краткий обзор' +title: "Объединенный стейкинг" +description: "Узнайте о стейкинг-пулах" lang: ru template: staking emoji: ":money_with_wings:" image: /images/staking/leslie-pool.png -alt: Носорог Лесли плавает в бассейне. +alt: "Носорог Лесли плавает в бассейне." sidebarDepth: 2 summaryPoints: - Становитесь дольщиком и зарабатывайте награды при любом количестве ETH, объединяя силы с другими. @@ -17,21 +17,21 @@ summaryPoints: Стейкинг-пулы — это совместный подход, который позволяет многим пользователям с малым количеством ETH вместе набирать32 ETH, необходимых для активации набора ключей валидатора. Функционал пулов изначально не поддерживался в рамках протокола, так что эти решения были созданы отдельно. -Некоторые пулы управляются с помощью умных контрактов, где средства могут быть внесены на этот контракт, который без необходимости доверия управляет вашей ставкой и отслеживает ее, а также выдает вам токен с той же ценностью. Другие пулы могут не использовать смарт-контракты, а посредничество происходит вне цепочки. +Некоторые пулы управляются с помощью умных контрактов, где средства могут быть внесены на этот контракт, который без необходимости доверия управляет вашей ставкой и отслеживает ее, а также выдает вам токен с той же ценностью. Другие пулы могут не использовать умные контракты, а посредничество происходит вне цепочки. -## Зачем делать ставки в пуле? {#why-stake-with-a-pool} +## Зачем делать ставки в пуле? Почему стоит участвовать в стейкинге через пул? {#why-stake-with-a-pool} -В дополнение к преимуществам, которые мы описали в нашем [введении в стейкинг](/staking/), ставки в пуле предлагают еще несколько преимуществ. +В дополнение к преимуществам, которые мы описали в нашем [введении в стейкинг](/staking/), стейкинг в пуле имеет ряд особых преимуществ. - - - + + + -## Что следует принять во внимание {#what-to-consider} +## Что следует учесть {#what-to-consider} Протокол Ethereum нативно не поддерживает пулы и делегированный стейкинг, но с учетом спроса от пользователей на возможность ставить менее 32 ETH создается все больше решений, чтобы удовлетворить этот запрос. @@ -39,13 +39,13 @@ summaryPoints: Однако такие ETH в ставке способствуют образованию своего рода картелей: большое количество поставленных ETH оказываются под контролем нескольких централизованных организаций, а не распространяется среди большого количества независимых лиц. Это создает условия для цензуры или извлечения ценности. Золотым стандартом стейкинга всегда должны быть отдельные люди, запускающие валидаторы на своем оборудовании, когда это возможно. -[Подробнее о рисках токенов стейкинга](https://notes.ethereum.org/@djrtwo/risks-of-lsd). +[Подробнее о рисках, связанных со стейкингом токенов](https://notes.ethereum.org/@djrtwo/risks-of-lsd). Индикаторы атрибутов ниже используются для указания на сильные и слабые стороны, которые могут быть у указанного стейкинг-пула. Используйте этот раздел в качестве справки о том, как мы определяем эти атрибуты, когда будете выбирать пул для участия. -## Исследуйте стейкинг-пулы {#explore-staking-pools} +## Изучите стейкинг-пулы {#explore-staking-pools} Есть множество вариантов, которые помогут вам с установкой. Используйте индикаторы выше как руководство по инструментам, приведенным ниже. @@ -53,9 +53,9 @@ summaryPoints: -Обратите внимание на важность выбора службы, которая серьезно подходит к [разнообразию клиентов](/developers/docs/nodes-and-clients/client-diversity/), так как это повышет безопасность сети и ограничивает ваши риски. Сервисы, у которых есть доказательства ограничения для мажоритарных клиентов, имеют отметки разнообразие клиентов-исполнителей и разнообразие консенсус-клиентов. +Обратите внимание на важность выбора сервиса, который серьезно относится к [разнообразию клиентов](/developers/docs/nodes-and-clients/client-diversity/), поскольку это повышает безопасность сети и ограничивает ваши риски. Службы, у которых есть доказательства ограничения для мажоритарных клиентов, имеют отметки разнообразие клиентов-исполнителей и разнообразие консенсус-клиентов. -Есть предложение насчет инструмента для стейкинга, которого не хватает? Ознакомьтесь с нашей [политикой списка продуктов](/contributing/adding-staking-products/), убедитесь, что оно подойдет, и отправьте на рассмотрение. +Есть предложение насчет инструмента для стейкинга, которого не хватает? Ознакомьтесь с нашей [политикой размещения продуктов](/contributing/adding-staking-products/), чтобы понять, подходит ли он, и отправить его на рассмотрение. ## Часто задаваемые вопросы {#faq} @@ -63,7 +63,7 @@ summaryPoints: Как правило, дольщикам выдаются токены стейкинга ERC-20, которые представляют собой сумму их вклада ETH и вознаграждения. Имейте в виду, что разные пулы могут разными способами распределять награды среди вкладчиков, но в целом все обычно устроено так.     - + Прямо сейчас! Обновление сети Shanghai/Capellа произошло в апреле 2023 года и ввело вывод средств из стейкинга. Аккаунты валидаторов, которые поддерживают стейкинг-пулы, теперь имеют возможность вывести ЕТН на их назначенный адрес вывода. Это дает возможность вернуть свою долю ставки за базовые ЕТН. Свяжитесь с вашим поставщиком, чтобы узнать, как он поддерживает эту функцию. В качестве альтернативы пулы, использующие токены стейкинга ERC-20, позволяют пользователям торговать этими токенами на открытом рынке. Это дает возможность продать находящуюся в стейкинге позицию без фактического вывода ETH из контракта стейкинга. @@ -71,16 +71,16 @@ summaryPoints: Подробнее о выводе средств из стейкинга - -Существует много сходств между вариантами стейкинг-пулов и централизованными биржами. Например, возможность вклада небольшого количества ETH и объединения для активации валидатора. + +Между этими вариантами стейкинга в пулах и централизованными биржами много общего, например, возможность вносить в стейкинг небольшие суммы ETH и объединять их для активации валидаторов. В отличие от централизованных бирж, многие другие варианты стейкинг-пулов используют умные контракты и/или стейкинговые токены ERC-20, которые хранятся в вашем кошельке и могут быть куплены или проданы, как и любой другой токен. Это обеспечивает определенный уровень суверенитета и безопасности, давая вам контроль над своими токенами, но не оставляя прямого контроля над клиентом валидатора, подтверждающего от вашего имени в фоновом режиме. Некоторые пулы более децентрализованы по сравнению с другими, когда речь идет об узлах, которые поддерживают их. Для укрепления здоровья и децентрализации сети вкладчиков всегда поощряют выбирать пул, обеспечивающий децентрализованный набор операторов узлов и не требующий разрешений. -## Дополнительные ресурсы {#further-reading} +## Дополнительные материалы {#further-reading} - [Каталог стейкинга Ethereum](https://www.staking.directory/) — _Eridian и Spacesider_ -- [Стейкинг с помощью Rocket Pool: обзор стейкинга](https://docs.rocketpool.net/guides/staking/overview.html) — _документы RocketPool_ +- [Стейкинг с помощью Rocket Pool — Обзор стейкинга](https://docs.rocketpool.net/guides/staking/overview.html) — _документация RocketPool_ - [Стейкинг Ethereum с помощью Lido](https://help.lido.fi/en/collections/2947324-staking-ethereum-with-lido) — _справочная документация Lido_ diff --git a/public/content/translations/ru/staking/saas/index.md b/public/content/translations/ru/staking/saas/index.md index 4117f7e6e65..5179df1c881 100644 --- a/public/content/translations/ru/staking/saas/index.md +++ b/public/content/translations/ru/staking/saas/index.md @@ -1,11 +1,11 @@ --- -title: Стейкинг как услуга -description: Обзор того, как разместить ETH в пуле +title: "Стейкинг как услуга" +description: "Узнайте о стейкинге как услуге" lang: ru template: staking emoji: ":money_with_wings:" image: /images/staking/leslie-saas.png -alt: Носорог Лесли плавает в облаках. +alt: "Носорог Лесли плавает в облаках." sidebarDepth: 2 summaryPoints: - Операторы сторонних узлов управляют работой вашего клиента валидатора @@ -22,14 +22,14 @@ summaryPoints: Протокол Ethereum нативно не поддерживает делегирование ставок, поэтому эти услуги предлагаются для удовлетворения существующего спроса. Если у вас есть 32 ETH для стейкинга, но вы не чувствуете себя комфортно при работе с оборудованием, службы SaaS позволяют делегировать сложную часть, пока вы зарабатываете собственные вознаграждения за блоки. - - - + + + -## На что необходимо обратить внимание {#what-to-consider} +## Что следует учесть {#what-to-consider} Чтобы помочь вам ставить свои ETH, появляется все больше поставщиков SaaS, но у каждого есть свои преимущества и риски. Все варианты SaaS требуют дополнительного доверия по сравнению с домашним стейкингом. Параметры SaaS могут содержать дополнительный код, который вносит клиенты Ethereum в свертки и не является открытым или проверяемым. SaaS также имеет пагубное влияние на децентрализацию сети. В зависимости от настроек вы можете не контролировать свой валидатор: оператор может действовать нечестно, используя ваши ETH. @@ -47,41 +47,41 @@ summaryPoints: -Обратите внимание на важность поддержки [разнообразия клиентов](/developers/docs/nodes-and-clients/client-diversity/), так как это повышет безопасность сети и ограничивает ваши риски. Сервисы, у которых есть доказательства ограничения для мажоритарных клиентов, имеют отметки разнообразие клиентов-исполнителей и разнообразие консенсус-клиентов. +Обратите внимание на важность поддержки [разнообразия клиентов](/developers/docs/nodes-and-clients/client-diversity/), так как это повышает безопасность сети и ограничивает ваши риски. Службы, у которых есть доказательства ограничения для мажоритарных клиентов, имеют отметки разнообразие клиентов-исполнителей и разнообразие консенсус-клиентов. ### Генераторы ключей -У вас есть предложение относительно поставщика услуг по стейкингу, которое мы пропустили? Ознакомьтесь с нашей [политикой списка продуктов](/contributing/adding-staking-products/), убедитесь, что оно подойдет, и отправьте на рассмотрение. +У вас есть предложение относительно поставщика услуг по стейкингу, которое мы пропустили? Ознакомьтесь с нашей [политикой размещения продуктов](/contributing/adding-staking-products/), чтобы понять, подходит ли он, и отправить его на рассмотрение. ## Часто задаваемые вопросы {#faq} - + Договоренности будут отличаться от поставщика к поставщику, но обычно вам понадобится настроить с помощью подсказок все необходимые ключи для подписи (один на 32 ETH) и отправить их поставщику, чтобы позволить ему выполнять валидацию от вашего имени. Сами по себе ключи для подписи не дают возможности вывести, перевести или потратить ваши средства. Тем не менее, они дают возможность голосовать в пользу консенсуса. Если не делается должным образом, это может привести к офлайн-штрафам или сокращению. - + Да. Каждая учетная запись состоит как из ключей BLS для подписи, так и из BLS для вывода средств. Чтобы валидатор мог подтвердить состояние цепочки, учавствовать в комитетах синхронизации и предлагать блоки, ключи подписи должны быть легко доступны клиенту-валидатору. Они должны быть подключены к Интернету в той или иной форме и, таким образом, по своей сути считаются «горячими» клавишами. Это обязательное требование к валидатору для возможности подтверждения. Поэтому ключи, используемые для пердачи или вывода средств, разделены по соображениям безопасности. Ключи для вывода средств BLS используются для подписи одноразового сообщения, в котором указывается, на какую учетную запись уровня выполнения должны быть начислены вознаграждения за стейкинг и выведены средства. Как только это сообщение будет транслировано, ключи BLS для вывода средств больше не понадобятся. Вместо этого контроль над выведенными средствами навсегда передается указанному вами адресу. Это позволяет вам установить адрес вывода средств, защищенный через ваше собственное холодное хранилище, минимизируя риск для ваших средств валидатора, даже если кто-то другой контролирует ваши ключи подписи валидатора. Обновление учетных данных для вывода является необходимым шагом, чтобы активировать вывод средств\*. Этот процесс включает в себя генерацию ключей вывода с помощью вашей мнемонической кодовой фразы. -Следите за безопасным хранением этой кодовой фразы. В противном случае вы не сможете генерировать ключи для вывода, когда придет время. +Убедитесь, что вы надежно сохранили резервную копию этой кодовой фразы, иначе вы не сможете сгенерировать ключи для вывода, когда придет время. -\* Дольщикам, которые предоставили адрес вывода с начальным депозитом, не нужно настраивать это. Обратитесь к своему поставщику SaaS за помощью по подготовке валидатора. +\*Стейкерам, которые указали адрес для вывода средств при первоначальном депозите, не нужно его устанавливать. Обратитесь к своему поставщику SaaS за помощью по подготовке валидатора. - -Вывод средств стейкинга введен с обновлением Shanghai/Capella в апреле 2023 года. Стейкеры должны предоставить адрес для вывода (если он не был указан при первоначальном депозите). Выплаты вознаграждений начнут распределяться автоматически на периодической основе каждые несколько дней. + +Стейкеры должны предоставить адрес для вывода (если он не был указан при первоначальном депозите), и выплаты вознаграждений начнут распределяться автоматически на периодической основе каждые несколько дней. Валидаторы также могут полностью выйти из роли валидатора, что разблокирует остаток ЕТН для вывода. Учетные записи, указавшие адрес вывода средств и завершившие процесс выхода, получат весь остаток на адрес вывода, указанный во время следующего перебора валидаторов. -More on staking withdrawals +Подробнее о выводе средств из стейкинга - + Используя поставщика SaaS, вы поручаете управление вашим узлом кому-то другому. Это связано с риском плохой производительности узла, которая находится вне вашего контроля. Если ваш валидатор будет сокращен, баланс вашего валидатора будет оштрафован и принудительно удален из пула валидаторов. После завершения процесса сокращения/выхода эти средства будут переведены на адрес для вывода средств, присвоенный валидатору. Для этого потребуется указать адрес вывода. Возможно, он был указан при первоначальном внесении депозита. Если нет, то для подписи сообщения, объявляющего адрес вывода средств, потребуется использовать ключи вывода средств валидатора. Если адрес для вывода средств не указан, средства остаются заблокированными до тех пор, пока его не укажут. @@ -89,7 +89,7 @@ summaryPoints: Свяжитесь с конкретным поставщиком услуг SaaS для получения более подробной информации обо всех гарантиях и вариантах страхования, а также инструкций о том, как предоставить адрес для вывода средств. Если вы предпочитаете полностью контролировать настройки вашего валидатора, [узнайте больше об одиночном стейкинге](/staking/solo/). -## Дополнительные ресурсы {#further-reading} +## Дополнительные материалы {#further-reading} - [Каталог стейкинга Ethereum](https://www.staking.directory/) — _Eridian и Spacesider_ -- [Оценка услуг стейкинга](https://www.attestant.io/posts/evaluating-staking-services/) — _Джим Макдональд, 2020г._ +- [Оценка услуг стейкинга](https://www.attestant.io/posts/evaluating-staking-services/) - _Jim McDonald 2020_ diff --git a/public/content/translations/ru/staking/solo/index.md b/public/content/translations/ru/staking/solo/index.md index f66e83fb8e5..a4979ab978e 100644 --- a/public/content/translations/ru/staking/solo/index.md +++ b/public/content/translations/ru/staking/solo/index.md @@ -1,11 +1,11 @@ --- -title: Одиночный стейкинг со своими ETH -description: Обзор того, как начать одиночный стекинг ETH +title: "Стейкинг в домашних условиях со своими ETH" +description: "Обзор того, как начать стейкинг ETH в домашних условиях" lang: ru template: staking emoji: ":money_with_wings:" image: /images/staking/leslie-solo.png -alt: Носорог Лесли на собственном компьютерном чипе. +alt: "Носорог Лесли на собственном компьютерном чипе." sidebarDepth: 2 summaryPoints: - Получайте максимальное вознаграждение непосредственно от протокола за поддержание вашего валидатора в исправном состоянии и в режиме онлайн @@ -13,64 +13,65 @@ summaryPoints: - Избавьтесь от необходимости доверия и никогда не передавайте контроль над ключами к своим средствам --- -## Что такое одиночный стейкинг? {#what-is-solo-staking} +## Что такое домашний стейкинг? {#what-is-solo-staking} -Одиночный стейкинг — это [запуск узла Ethereum](/run-a-node/), подключенного к Интернету, и внесение 32 ETH для активации [валидатора](#faq), дающего вам возможность участвовать непосредственно в сетевом консенсусе. +Домашний стейкинг — это [запуск узла Ethereum](/run-a-node/), подключенного к Интернету, и внесение 32 ETH для активации [валидатора](#faq), что дает вам возможность непосредственно участвовать в консенсусе сети. -**Одиночный стейкинг увеличивает децентрализацию сети Ethereum**, делая Ethereum устойчивее к цензуре и атакам. Другие методы стейкинга не могут помочь сети в похожих случаях. Одиночный стейкинг — это лучший вариант стейкинга для обеспечения безопасности Ethereum. +**Домашний стейкинг повышает децентрализацию сети Ethereum**, делая Ethereum более устойчивым к цензуре и атакам. Другие методы стейкинга могут не так же помогать сети. Домашний стейкинг — лучший вариант для обеспечения безопасности Ethereum. -Узел Ethereum состоит из двух клиентов — на слое исполнения (EL) и слое консенсуса (CL). Эти клиенты — это программное обеспечение, которое работает вместе с действительным набором ключей для подписи, чтобы проверять транзакции и блоки, подтверждать правильность главы цепочки, агрегировать подтверждения и предлагать блоки. +Узел Ethereum состоит как из клиента уровня исполнения (EL), так и из клиента уровня консенсуса (CL). Эти клиенты — это программное обеспечение, которое работает совместно с действительным набором ключей для подписи, чтобы проверять транзакции и блоки, подтверждать правильность заголовка цепи, агрегировать аттестации и предлагать блоки. -Одиночные дольщики отвечают за работу оборудования, необходимого для функционирования этих клиентов. Для этого настоятельно рекомендуется использовать специальную машину, которая работает на дому: это чрезвычайно полезно для здоровья сети. +Домашние стейкеры несут ответственность за эксплуатацию оборудования, необходимого для запуска этих клиентов. Настоятельно рекомендуется использовать для этого выделенную машину, которой вы управляете из дома, — это чрезвычайно полезно для здоровья сети. -Одиночный дольщик получает вознаграждения непосредственно от протокола за поддержание правильной работы своего валидатора и постоянное подключение к Интернету. +Домашний стейкер получает вознаграждения непосредственно от протокола за поддержание надлежащей работы и онлайн-статуса своего валидатора. -## Зачем становиться одиночным дольщиком? {#why-stake-solo} +## Зачем заниматься стейкингом из дома? {#why-stake-solo} -Одиночный стейкинг предполагает больше ответственности, но предагает вам максимальный контроль над вашими средствами и конфигурацией для стейкинга. +Домашний стейкинг предполагает больше ответственности, но предлагает вам максимальный контроль над вашими средствами и конфигурацией для стейкинга. - - - + + + -## Важно знать перед одиночным стейкингом {#considerations-before-staking-solo} +## Что следует учесть перед домашним стейкингом {#considerations-before-staking-solo} -Как бы мы ни хотели, чтобы одиночный стейкинг был доступен и безопасен для всех, это не так. Есть несколько практических и серьезных соображений, о которых следует помнить, прежде чем делать одиночную ставку ETH. +Как бы нам ни хотелось, чтобы домашний стейкинг был доступен и безрисков для всех, в реальности это не так. Прежде чем выбрать домашний стейкинг ваших ETH, необходимо учесть некоторые практические и серьезные моменты. -Запуская собственный узел, вы должны потратить некоторое время на обучение использованию выбранного вами программного обеспечения. Это включает чтение связанной документации и отслеживание каналов связи соответствующих команд разработчиков. +При эксплуатации собственного узла вам следует потратить некоторое время, чтобы научиться использовать выбранное программное обеспечение. Это включает в себя чтение соответствующей документации и отслеживание каналов связи команд разработчиков. -Чем больше вы будете понимать программное обеспечение, которое запускаете, и чем лучше разберетесь в том, как работает доказательство владения, тем меньше рисков будет при стейкинге и тем легче будет устранять проблемы, возникающие в роли оператора узла. +Чем лучше вы понимаете программное обеспечение, которое вы используете, и как работает proof-of-stake, тем меньше будет риск для вас как для стейкера и тем легче будет устранять любые проблемы, которые могут возникнуть на вашем пути как оператора узла. - -Настройка узлов требует довольно уверенного владения компьютером, хотя новые инструменты со временем делают все проще. Понимание интерфейса командной строки полезно, но это уже не обязательное требование. + +Настройка узла требует определенного уровня уверенности при работе с компьютерами, хотя со временем новые инструменты упрощают этот процесс. Понимание интерфейса командной строки полезно, но больше не является обязательным требованием. -Также требуется настройка оборудования на самом базовом уровне и некоторое понимание минимальной рекомендуемой спецификации. +Также требуется базовая настройка оборудования и некоторое понимание минимальных рекомендуемых характеристик. -Приватные ключи обеспечивают безопасность вашего адреса Ethereum, и вам тоже нужно будет сгенерировать ключи специально для вашего валидатора. Вы должны понимать, как держать все кодовые фразы и приватные ключи в безопасности. {' '} +Подобно тому, как приватные ключи защищают ваш адрес Ethereum, вам нужно будет сгенерировать ключи специально для вашего валидатора. Вы должны понимать, как хранить любые сид-фразы или приватные ключи в безопасности.{' '} [Безопасность Ethereum и предотвращение мошенничества](/security/) - -Оборудование время от времени выходят из строя, сетевые подключения тоже, а программное обеспечение клиента иногда нуждается в обновлении. Обслуживание узлов неизбежно и иногда потребует вашего внимания. Советуем оставаться в курсе всех ожидаемых обновлений сети или других важных обновлений клиентов. + +Оборудование иногда выходит из строя, в сетевых подключениях возникают ошибки, а клиентское программное обеспечение время от времени нуждается в обновлении. Обслуживание узла неизбежно и время от времени будет требовать вашего внимания. Вам нужно быть в курсе любых ожидаемых обновлений сети или других критически важных обновлений клиента. - -Ваши награды пропорциональны времени, когда ваш валидатор находится в сети и должным образом выполняет процесс подтверждения. Простой влечет за собой штрафы, пропорциональные количеству других валидаторов офлайн в то же время, но не приводит к сокращению. Также важна пропускная способность, так как снижается вознаграждение за подтверждения, которые не получены вовремя. Требования будут варьироваться, но рекомендуется скорость не менее 10 Мб/с в обоих направлениях. + +Ваши вознаграждения пропорциональны времени, в течение которого ваш валидатор находится в сети и правильно проводит аттестацию. Простои влекут за собой штрафы, пропорциональные количеству других валидаторов, находящихся в это же время не в сети, но не приводят к сокращению. Пропускная способность также имеет значение, поскольку вознаграждения за аттестации, не полученные вовремя, уменьшаются. Требования могут различаться, но рекомендуется скорость не менее 10 Мбит/с на приём и отдачу. - -В отличие от наказаний за бездействие в офлайн-режиме, сокращение является гораздо более серьезным наказанием, предназначенным для злонамеренных нарушений. Запуская миноритарный клиент с помощью своих ключей, загруженных только на одну машину за раз, вы минимизируете риск попасть под сокращение. С учетом вышесказанного все дольщики должны осознавать риски сокращения. + +В отличие от штрафов за неактивность в офлайн-режиме, сокращение — это гораздо более серьезное наказание, применяемое за злонамеренные нарушения. Используя миноритарный клиент и загружая ключи только на одно устройство, вы сводите к минимуму риск сокращения. При этом все стейкеры должны осознавать риски сокращения. Подробнее о сокращении и жизненном цикле валидатора + @@ -81,27 +82,27 @@ summaryPoints: За время активности вы будете зарабатывать вознаграждения в ЕТН, которые будут периодически вноситься на ваш адрес для вывода средств. -При желании вы можете выйти из роли валидатора, что устраняет требование быть онлайн и останавливает все дальнейшие вознаграждения. Оставшийся баланс будет выведен на адрес вывода, указанный вами во время установки. +При желании вы можете выйти из роли валидатора, что устраняет требование быть онлайн и останавливает все дальнейшие вознаграждения. Оставшийся баланс будет выведен на адрес для вывода средств, который вы укажете при настройке. -[More on staking withdrawals](/staking/withdrawals/) +[Подробнее о выводе средств из стейкинга](/staking/withdrawals/) -## Начните с панели запуска стейкинга {#get-started-on-the-staking-launchpad} +## Начало работы с Панелью запуска для стейкинга {#get-started-on-the-staking-launchpad} -Панель запуска стейкинга — это приложение с открытым исходным кодом, которое поможет вам стать стейкером. Оно поможет вам пройти через выбор клиентов, генерирование ваших ключей и внесение депозита ЕТН в контракт депозита стейкинга. Чтобы убедиться, что сделано все необходимое для безопасной настройки валидатора, используйте предоставленный контрольный список. +Панель запуска стейкинга — это приложение с открытым исходным кодом, которое поможет вам стать стейкером. Оно поможет вам выбрать клиенты, сгенерировать ключи и внести ETH на депозитный контракт для стейкинга. Чтобы убедиться, что сделано все необходимое для безопасной настройки валидатора, используйте предоставленный контрольный список. -## На что необходимо обратить внимание при работе с инструментами для настройки клиента и узлов {#node-tool-considerations} +## На что следует обратить внимание при работе с инструментами для настройки узла и клиента {#node-tool-considerations} -Количество инструментов для помощи с одиночным стейкингом ваших ETH все время растет, но каждый из них имеет различные риски и выгоды. +Количество инструментов для помощи с домашним стейкингом ваших ETH все время растет, но каждый из них имеет различные риски и выгоды. Индикаторы атрибутов, приведенные ниже, используются для предупреждения о сильных и слабых сторонах, которые могут иметь перечисленные инструменты для стейкинга. Используйте этот раздел в качестве справочного материала о том, как мы определяем эти атрибуты, пока вы выбираете, какие инструменты помогут вам на вашем пути к стейкингу. -## Изучите инструменты для настройки узлов и клиентов {#node-and-client-tools} +## Изучите инструменты для настройки узла и клиента {#node-and-client-tools} -Есть множество опций, которые помогут вам с установкой. Используйте индикаторы описанные выше, в этом руководстве, с помощью инструментов, которые находятся ниже. +Есть множество вариантов, которые помогут вам с установкой. Используйте индикаторы выше как руководство по инструментам, приведенным ниже. @@ -109,17 +110,17 @@ summaryPoints: -Обратите внимание на важность выбора [миноритарного клиента](/developers/docs/nodes-and-clients/client-diversity/), так как это повышает безопасность сети и ограничивает ваши риски. Инструменты, позволяющие настраивать миноритарный клиент, обозначаются как мультиклиент. +Обратите внимание на важность выбора [миноритарного клиента](/developers/docs/nodes-and-clients/client-diversity/), так как это повышает безопасность сети и ограничивает ваши риски. Инструменты, позволяющие настраивать миноритарный клиент, обозначаются как «мультиклиент». ### Генераторы ключей -Эти инструменты могут быть использованы в качестве альтернативы к [CLI депозита на стейкинг](https://github.com/ethereum/staking-deposit-cli/), чтобы помочь с генерацией ключей. +Эти инструменты можно использовать как альтернативу [Staking Deposit CLI](https://github.com/ethereum/staking-deposit-cli/) для помощи в генерации ключей. -Есть предложение насчет инструмента для стейкинга, которого не хватает? Ознакомьтесь с нашей [политикой списка продуктов](/contributing/adding-staking-products/), убедитесь, что оно подойдет, и отправьте на рассмотрение. +Есть предложение насчет инструмента для стейкинга, которого не хватает? Ознакомьтесь с нашей [политикой размещения продуктов](/contributing/adding-staking-products/), чтобы понять, подходит ли он, и отправить его на рассмотрение. -## Изучите руководства по одиночному стейкингу {#staking-guides} +## Изучите руководства по домашнему стейкингу {#staking-guides} @@ -129,77 +130,80 @@ summaryPoints: -Валидатор — это виртаульный обьект, который живет на Ethereum и участвует в консенсусе протокола Ethereum. Валидаторы представлены балансом, публичным ключом и другими свойствами. Клиент валидатора — это программное обеспечение, которое действует от имени валидатора путем держания и использования его приватного ключа. Один клиент валидатора может содержать много пар ключей, контролируя многие валидаторы. - +Валидатор — это виртуальный объект, который существует в Ethereum и участвует в консенсусе протокола Ethereum. Валидаторы представлены балансом, публичным ключом и другими свойствами. Клиент валидатора — это программное обеспечение, которое действует от имени валидатора, храня и используя его приватный ключ. Один клиент валидатора может хранить много пар ключей, контролируя множество валидаторов. - -Каждая пара ключей, связанная с валидатором, требует для активации ровно 32 ETH. Больше ЕТН, внесенных в депозит на один набор ключей, не увеличивает потенциал вознаграждений, так как каждый валидатор ограничен эффективным балансом в 32 ETH. Это означает, что стейкинг выполняется с шагом в 32 ETH, каждый с собственным набором ключей и баланса. + +Да, современные аккаунты валидаторов способны хранить до 2048 ETH. Дополнительные ETH свыше 32 будут начисляться поэтапно, увеличиваясь целочисленно по мере увеличения вашего истинного баланса. Это называется вашим эффективным балансом. + +Чтобы увеличить эффективный баланс аккаунта и, следовательно, увеличить вознаграждение, необходимо преодолеть буфер в 0,25 ETH сверх любого целочисленного количества ETH. К примеру, для аккаунта с истинным балансом 32,9 и эффективным балансом 32 потребуется заработать еще 0,35 ETH, чтобы его истинный баланс превысил 33,25 — и только тогда произойдет увеличение эффективного баланса. + +Этот буфер также предотвращает уменьшение эффективного баланса, пока он не станет на 0,25 ETH ниже текущего эффективного баланса. -Не вносите более 32 ЕТН для одного валидатора. Это не увеличит ваши вознаграждения. Если для валидатора был установлен адрес вывода средств, избыточные средства более 32 ETH будут автоматически выведены на этот адрес в течение следующего [перебора валидаторов](/staking/withdrawals/#validator-sweeping). +Каждая пара ключей, связанная с валидатором, требует для активации минимум 32 ETH. Любой баланс сверх этой суммы может быть выведен на привязанный адрес для вывода средств в любое время посредством транзакции, подписанной этим адресом. Любые средства сверх максимального эффективного баланса будут автоматически выводиться на периодической основе. -Если одиночный стейкинг кажется слишком требовательным для вас, подумайте об обращении к поставщику [стейкинга как услуги](/staking/saas/). Если вы работаете с менее чем 32 ETH, обратите внимание на [стейкинг-пулы](/staking/pools/). +Если домашний стейкинг кажется слишком требовательным для вас, подумайте об обращении к поставщику [стейкинга как услуги](/staking/saas/). Если вы работаете с менее чем 32 ETH, обратите внимание на [стейкинг-пулы](/staking/pools/). - -Переход в офлайн-режим при завершении работы сети должным образом НЕ приведет к сокращению. Небольшие штрафы за бездействие применяются, если ваш валидатор недоступен для подтверждения данной эпохи (каждые 6,4 минуты), но это сильно отличается от сокращения. Эти штрафы немного меньше, чем вознаграждение, которое вы заработали бы, если бы валидатор был доступен для подтверждения, и потери могут быть возвращены за счет отрабатывания примерно равного количества времени. + +Переход в офлайн-режим, когда сеть финализирует блоки должным образом, НЕ приведет к сокращению. Небольшие штрафы за бездействие применяются, если ваш валидатор недоступен для аттестации в течение эпохи (каждая длится 6,4 минуты), но это сильно отличается от сокращения. Эти штрафы немного меньше, чем вознаграждение, которое вы бы заработали, если бы валидатор был доступен для аттестации, и потери можно вернуть, пробыв в сети примерно такое же время. -Обратите внимание, что штрафы за бездействие (неактивность) пропорциональны тому, сколько валидаторов отключено одновременно. В тех случаях, когда значительная часть сети одновременно отключена, штрафы для каждого из этих валидаторов будут больше, чем когда недоступен один валидатор. +Обратите внимание, что штрафы за бездействие пропорциональны тому, сколько валидаторов отключено одновременно. В тех случаях, когда значительная часть сети одновременно отключена, штрафы для каждого из этих валидаторов будут больше, чем когда недоступен один валидатор. -В крайних случаях, если сеть перестает завершаться в результате того, что более трети валидаторов находятся в автономном режиме, эти пользователи будут страдать от так называемой утечки квадратичной неактивности, которая является экспоненциальным стоком ETH из счетов офлайн-валидаторов. Это позволяет сети в конечном итоге самовосстанавливаться путем сжигания ЕТН неактивных валидаторов, пока их баланс не достигнет 16 ЕТН, после чего они будут автоматически выброшены из пула валидаторов. Оставшиеся онлайн-валидаторы в конечном итоге снова составят более 2/3 сети, удовлетворяя требования сверхбольшинства, необходимого для завершения цепочки. +В крайних случаях, если сеть перестает финализировать блоки в результате того, что более трети валидаторов находятся в офлайн-режиме, эти пользователи пострадают от так называемой квадратичной утечки из-за неактивности — экспоненциального списания ETH с аккаунтов офлайн-валидаторов. Это позволяет сети в конечном итоге самовосстанавливаться путем сжигания ETH неактивных валидаторов, пока их баланс не достигнет 16 ETH, после чего они будут автоматически исключены из пула валидаторов. Оставшиеся онлайн-валидаторы в конечном итоге снова составят более 2/3 сети, удовлетворяя требования сверхбольшинства, необходимого для финализации цепи. - -Короче говоря, абсолютной гарантии здесь быть не может, но если вы действуете добросовестно, управляете миноритарным клиентом и держите свои ключи для подписи только на одной машине за раз, риск быть скоращенным почти нулевой. + +Короче говоря, это невозможно гарантировать на 100 %, но если вы действуете добросовестно, используете миноритарный клиент и храните ключи для подписи только на одном устройстве, риск сокращения практически равен нулю. -Есть лишь несколько конкретных путей действия, которые могут привести к тому, что валидатор будет сокращен и выброшен из сети. На момент написания имевшие место сокращения были исключительно результатом избыточных аппаратных настроек, где ключи для подписи хранились на двух отдельных машинах одновременно. Это может непреднамеренно привести к двойному голосу с помощью ваших ключей, что является нарушением, подпадающим под сокращение. +Есть лишь несколько конкретных способов, которые могут привести к сокращению валидатора и его исключению из сети. На момент написания имевшие место сокращения были исключительно результатом избыточных аппаратных настроек, где ключи для подписи хранились на двух отдельных машинах одновременно. Это может непреднамеренно привести к двойному голосованию с ваших ключей, что является нарушением, влекущим за собой сокращение. -Запуск клиента сверхбольшинства (любого клиента, используемого более чем 2/3 в сети) также несет риск потенциального сокращения в случае, если у этого клиента возникнет ошибка, приводящая к ветвлению цепи. Это может привести к неисправному ветвлению, которое будет завершено. Чтобы вернуться к запланированной цепочке, потребуется провести окружающее голосование путем применения усилий, чтобы отменить оконченный блок. Этого нарушения, подпадающего под сокращение, также можно избежать, просто запустив вместо этого миноритарный клиент. +Запуск клиента, который использует сверхбольшинство валидаторов (любой клиент, используемый более чем 2/3 сети), также несет риск потенциального сокращения в случае, если у этого клиента возникнет ошибка, приводящая к форку цепи. Это может привести к ошибочному форку, который будет финализирован. Чтобы вернуться к запланированной цепи, потребуется отправить окружающее голосование, пытаясь отменить финализированный блок. Этого нарушения, влекущего за собой сокращение, можно избежать, просто запустив миноритарный клиент. Эквивалентные ошибки в миноритарном клиенте никогда не будут окончательными и, таким образом, никогда не приведут к окружающему голосованию, а просто повлекут штрафы за бездействие, (не сокращение). - -Индивидуальные клиенты могут немного отличаться по производительности и пользовательскому интерфейсу, поскольку все они разрабатываются разными командами с использованием различных языков программирования. Стоит отметить, что «лучшего» среди них нет. Все производственные клиенты являются отличными образцами программного обеспечения, все выполняют те же основные функции для синхронизации и взаимодействия с блокчейном. + +Отдельные клиенты могут немного отличаться по производительности и пользовательскому интерфейсу, поскольку все они разрабатываются разными командами с использованием различных языков программирования. Стоит отметить, что «лучшего» среди них нет. Все клиенты в рабочей среде являются отличными образцами программного обеспечения и выполняют те же основные функции для синхронизации и взаимодействия с блокчейном. -Поскольку все производственные клиенты предоставляют одинаковые базовые функции, на самом деле очень важно, чтобы вы выбрали миноритарный клиент, то есть любой, который в настоящее время НЕ используется большинством валидаторов в сети. Это может показаться нелогичным, но работа с мажоритарным или надмажоритарным клиентом повышает риск сокращения в случае ошибки в клиенте. Работа с миноритарным клиентом резко ограничивает эти риски. +Поскольку все клиенты в рабочей среде предоставляют одинаковые базовые функции, на самом деле очень важно, чтобы вы выбрали миноритарный клиент, то есть любой, который в настоящее время НЕ используется большинством валидаторов в сети. Это может показаться нелогичным, но работа с клиентом, который использует большинство или сверхбольшинство валидаторов, повышает риск сокращения в случае ошибки в этом клиенте. Работа с миноритарным клиентом резко ограничивает эти риски. -Подробнее о том, почему разнообразие клиентов имеет ключевое значение +Подробнее о том, почему разнообразие клиентов имеет решающее значение - -Хотя виртуальный частный сервер (VPS) может использоваться в качестве замены домашнего оборудования, физический доступ и расположение клиента-валидатора имеет значение. Централизованные облачные решения, такие как Amazon Web Services или Digital Ocean, позволяют избежать необходимости приобретения и эксплуатации оборудования ценой централизации сети. + +Хотя виртуальный частный сервер (VPS) можно использовать вместо домашнего оборудования, физический доступ к клиенту валидатора и его местоположение имеют значение. Централизованные облачные решения, такие как Amazon Web Services или Digital Ocean, обеспечивают удобство, избавляя от необходимости приобретать и эксплуатировать оборудование, но ценой этого является централизация сети. -Чем больше клиентов-валидаторов работает на одном централизованном решении облачного хранилища, тем более опасным это становится для этих пользователей. Любое событие, при котором эти поставщики будут отключены от сети, будь то атака, нормативные требования или просто отключение питания лии Интернета, приведет к тому, что каждый клиент-валидатор, который полагается на этот сервер, одновременно перейдет в автономный режим. +Чем больше клиентов-валидаторов работает на одном централизованном облачном решении для хранения данных, тем опаснее это становится для пользователей. Любое событие, которое отключает этих провайдеров, будь то атака, требования регуляторов или просто сбои в электросети/Интернете, приведет к одновременному отключению всех клиентов-валидаторов, использующих этот сервер. -Штрафы за офлайн пропорциональны тому, сколько других одновременно находятся в офлайн-режиме. Использование VPS значительно увеличивает риск того, что штрафы за офлайн будут более серьезными, и увеличивает риск квадратичной утечки или сокращения в случае достаточно большого отключения. Чтобы минимизировать свой собственный риск и риск для сети, пользователям настоятельно рекомендуется приобретать и эксплуатировать свое собственное оборудование. +Штрафы за офлайн пропорциональны тому, сколько других валидаторов одновременно находятся в офлайн-режиме. Использование VPS значительно увеличивает риск того, что штрафы за офлайн будут более суровыми, и повышает риск квадратичной утечки или сокращения в случае достаточно масштабного сбоя. Чтобы минимизировать собственный риск и риск для сети, пользователям настоятельно рекомендуется приобретать и эксплуатировать собственное оборудование. - + Для снятия любого вида средств из сети Beacon требуется задать учетные данные для вывода. -Новые дольщики устанавливают их во время генерации ключа и депозита. Существующие дольщики, которые еще не настраивали этого, могут обновить свои ключи для поддержки этой функциональности. +Новые стейкеры устанавливают это во время генерации ключа и внесения депозита. Существующие стейкеры, которые еще не установили это, могут обновить свои ключи для поддержки этой функциональности. Когда будут установлены полномочия на вывод средств, выплаты вознаграждений (накопленные ЕТН после первых 32) будут периодически автоматически распределяться на адрес для вывода средств. Чтобы разблокировать и получить весь баланс обратно, вы также должны завершить процесс выхода вашего валидатора. -More on staking withdrawals +Подробнее о выводе средств из стейкинга -## Дополнительные ресурсы {#further-reading} +## Дополнительные материалы {#further-reading} - [Каталог стейкинга Ethereum](https://www.staking.directory/) — _Eridian и Spacesider_ -- [Проблема разнообразия клиентов Ethereum](https://hackernoon.com/ethereums-client-diversity-problem) — _@emmanuelawosika, 2022 г._ -- [Помощь с разнообразием клиентов](https://www.attestant.io/posts/helping-client-diversity/) — _Джим Макдональд, 2022 г._ -- [Разнообразие клиентов на консенсусном уровне Ethereum](https://mirror.xyz/jmcook.eth/S7ONEka_0RgtKTZ3-dakPmAHQNPvuj15nh0YGKPFriA) — _jmcook.eth, 2022 г._ -- [Как покупать оборудование для валидатора Ethereum](https://www.youtube.com/watch?v=C2wwu1IlhDc) — _EthStaker, 2022 г._ -- [Советы по предотвращению сокращения Eth2](https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50) — _Рауль Джордан, 2020 г._ +- [Проблема разнообразия клиентов Ethereum](https://hackernoon.com/ethereums-client-diversity-problem) – _@emmanuelawosika, 2022_ +- [Содействие разнообразию клиентов](https://www.attestant.io/posts/helping-client-diversity/) – _Джим Макдональд, 2022_ +- [Разнообразие клиентов на уровне консенсуса Ethereum](https://mirror.xyz/jmcook.eth/S7ONEka_0RgtKTZ3-dakPmAHQNPvuj15nh0YGKPFriA) – _jmcook.eth, 2022_ +- [Руководство: как выбрать оборудование для валидатора Ethereum](https://www.youtube.com/watch?v=C2wwu1IlhDc) – _EthStaker, 2022_ +- [Советы по предотвращению сокращения в Eth2](https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50) – _Рауль Джордан, 2020_ diff --git a/public/content/translations/ru/staking/withdrawals/index.md b/public/content/translations/ru/staking/withdrawals/index.md index 9a3f749397a..e5a30515f6c 100644 --- a/public/content/translations/ru/staking/withdrawals/index.md +++ b/public/content/translations/ru/staking/withdrawals/index.md @@ -1,10 +1,10 @@ --- -title: Вывод средств, использованных в стейкинге -description: Страница с общим описанием того, что такое вывод средств из стейкинга, как он работает и что нужно сделать дольщику, чтобы получить свои вознаграждения +title: "Вывод средств, использованных в стейкинге" +description: "Страница с общим описанием того, что такое вывод средств из стейкинга, как он работает и что нужно сделать дольщику, чтобы получить свои вознаграждения" lang: ru template: staking image: /images/staking/leslie-withdrawal.png -alt: Носорог Лесли со своими вознаграждениями за стейкинг +alt: "Носорог Лесли со своими вознаграждениями за стейкинг" sidebarDepth: 2 summaryPoints: - Обновление Shanghai/Capella ввело возможность выводить средства из стейкинга в Ethereum. @@ -13,13 +13,9 @@ summaryPoints: - Валидаторы, которые полностью выйдут из стейкинга, получат свой остаток баланса. --- - -Вывод средств из стейкинга стал возможен с обновлением Shanghai/Capella, которое произошло 12 апреля 2023 года. Подробнее об обновлении Shanghai/Capella - +**Вывод средств из стейкинга** — это перевод ETH с учетной записи валидатора на уровне консенсуса Ethereum (Beacon Chain) на уровень исполнения, где с ним можно проводить транзакции. -**Вывод средств из стейкинга** — это передача ЕТН из учетной записи валидатора на консенсусном уровне Ethereum (сеть Beacon) на уровень выполнения, где с ними могут проводиться транзакции. - -**Выплаты возгаграждений за остаток** свыше 32 ETH будут автоматически и регулярно отправляться на адрес для вывода средств, связанный с каждым валидатором, после его указания пользователем. Пользователи могут также **выйти из стейкинга полностью**, разблокировав свой полный баланс валидатора. +\*\*Выплаты вознаграждений за баланс, превышающий 32 ETH, будут автоматически и регулярно отправляться на адрес для вывода средств, связанный с каждым валидатором, после его предоставления пользователем. Пользователи также могут **полностью выйти из стейкинга**, разблокировав весь баланс своего валидатора. ## Вознаграждения за стейкинг {#staking-rewards} @@ -39,7 +35,7 @@ summaryPoints: -### Важные уведомления {#important-notices} +### Важные примечания {#important-notices} Предоставление адреса вывода является необходимым шагом для любой учетной записи валидатора, прежде чем она получит право на вывод ЕТН со своего баланса. @@ -47,7 +43,7 @@ summaryPoints: - Каждой учетной записи валидатора можно назначить только один адрес вывода, один раз. Как только адрес выбран и передан на уровень консенсуса, его нельзя отменить или изменить. Дважды проверьте принадлежность и точность указанного адреса, прежде чем его отправлять. +Каждой учетной записи валидатора можно назначить только один адрес для вывода средств, и только один раз. После выбора адреса и его отправки на уровень консенсуса это действие нельзя будет отменить или изменить. Дважды проверьте принадлежность и точность указанного адреса, прежде чем его отправлять. @@ -56,17 +52,17 @@ summaryPoints: ## Полный выход из стейкинга {#exiting-staking-entirely} -Предоставление адреса вывода средств требуется до того, как _любые_ средства смогут быть переведены с баланса учетной записи валидатора. +Предоставление адреса для вывода средств требуется, прежде чем _любые_ средства можно будет перевести с баланса учетной записи валидатора. Пользователи, желающие выйти из стейкинга полностью и вывести обратно свой полный баланс, должны также подписать и транслировать сообщение о «добровольном выходе» с использованием ключей валидатора, что запустит процесс выхода из стейкинга. Это делается с клиентом-валидатором и передается на ваш консенсусный узел, газ не требуется. Процесс выхода валидатора занимает различные промежутки времени в зависимости от того, сколько других выходят одновременно. После завершения эта учетная запись больше не будет нести ответственность за выполнение сетевых обязанностей валидатора, иметь права на вознаграждения и иметь ЕТН «в доле» стейкинга. При этом учетная запись будет отмечена как имеющая возможность полного вывода средств. -Когда учетная запись помечается как подходящая для вывода средств и предоставляются учетные данные для вывода, пользователю остается только подождать, делать ничего не нужно. Учетные записи автоматически и постоянно перебираются предлагающими блоки и проверяются на наличие подходящих средств после выхода. Остаток на вашем балансе будет переведен в полном объеме («полный вывод») во время следующего перебора. +Когда учетная запись помечается как подходящая для вывода средств и предоставляются учетные данные для вывода, пользователю остается только подождать, делать ничего не нужно. Создатели блоков автоматически и непрерывно проверяют учетные записи на наличие средств, доступных для вывода, и баланс вашей учетной записи будет полностью переведен (что также известно как «полный вывод») во время следующей проверки. -## Когда можно будет выводить средства из стейкинга? {#when} +## Когда был включен вывод средств из стейкинга? {#when} -Выводить средства из стейкинга можно уже сейчас! Функция вывода была включена в рамках обновления Shanghai/Capella, которое вышло 12 апреля 2023 года. +Функция вывода средств была включена в рамках обновления Shanghai/Capella, которое состоялось **12 апреля 2023 года**. Обновление Shanghai/Capella позволило возвращать ранее внесенные ETH на обычные учетные записи Ethereum. Это замкнуло цикл ликвидности в стейкинге и на шаг приблизило Ethereum к построению устойчивой, масштабируемой, безопасной децентрализованной экосистемы. @@ -77,13 +73,13 @@ summaryPoints: Наличие у конкретного валидатора права на вывод средств определяется состоянием самой учетной записи валидатора. Участие пользователя не требуется, чтобы определять, нужно ли инициировать вывод средств с учетной записи. Весь процесс выполняется автоматически консенсусным уровнем в рамках непрерывного цикла. -### Больше визуализации? {#visual-learner} +### Больше увлекаетесь визуализацией? {#visual-learner} Посмотрите объяснение выводов средств из стейкинга в Ethereum от Finematics: -### «Перебор» валидаторов {#validator-sweeping} +### Проверка валидаторов {#validator-sweeping} Когда для валидатор запланировано предложение следующего блока, он должен построить очередь вывода до 16 правомочных снятий. При этом все начинается с индекса валидатора 0, определяется наличие возможных выводов для данной учетной записи по правилам протокола, а при таком наличии запись добавляется в очередь. Валидатор, предлагающий следующий блок, будет продолжать работу там, где остановился предыдущий, и продвижение по порядку происходит бесконечно. @@ -91,20 +87,20 @@ summaryPoints: -Представьте себе аналоговые часы. Срелка на часах указывает на час, движется в одном направлении, не пропускает ни одного часа, а в конце концов снова поворачивается к началу после того, как достигнут последний номер.

    -Теперь вместо 1 до 12 представьте, что часы имеют от 0 до N (общее число счетов валидаторов, которые когда-либо были зарегистрированы на консенсусном уровне, более 500 000 по состоянию на январь 2023 г.).

    -Стрелка на часах указывает на следующего валидатора, который должен быть проверен на подходящий вывод средств. Это все начинается с 0 и продвигается до конца, не пропуская ни одной учетной записи. Когда достигается последний валидатор, цикл продолжается с начала. +Представьте себе аналоговые часы. Стрелка на часах указывает на час, движется в одном направлении, не пропуская ни одного часа, и в конечном итоге возвращается к началу после достижения последнего числа.

    +Теперь представьте, что вместо цифр от 1 до 12 на часах есть цифры от 0 до N (общее количество учетных записей валидаторов, когда-либо зарегистрированных на уровне консенсуса, — более 500 000 по состоянию на январь 2023 г.).

    +Стрелка на часах указывает на следующего валидатора, которого необходимо проверить на предмет вывода средств. Она начинается с 0 и проходит по всему кругу, не пропуская ни одной учетной записи. Когда достигается последний валидатор, цикл продолжается с начала.     -#### Проверка учетной записи для снятия средств {#checking-an-account-for-withdrawals} +#### Проверка учетной записи на предмет вывода средств {#checking-an-account-for-withdrawals} Когда инициатор перебирает валидаторы и проверяет наличие у них возможного вывода средств, каждый проверяемый валидатор оценивается по короткому ряду вопросов, чтобы определить, нужно ли инициировать вывод, а если да, то сколько ЕТН должно быть снято. -1. **Указан ли адрес вывода?** Если адрес для вывода средств не указан, то учетная запись будет пропущена, а вывод средств не начнется. -2. **Валидатор вышел из системы и подходит для полного вывода средств?** Если валидатор полностью вышел, а мы достигли той эпохи, когда его учетная запись считается подходящей для вывода средств, будет обработан полный вывод. При этом весь оставшийся баланс будет переведен на адрес для вывода. -3. **Равен ли максимальный эффективный баланс 32?** Если в учетной записи есть учетные данные для вывода, она не вышла полностью из системы и имеет вознаграждения сверх 32 в состоянии ожидания, будет обработан частичный вывод средств, который переведет только вознаграждения сверх 32 на адрес вывода пользователя. +1. **Указан ли адрес для вывода средств?** Если адрес для вывода средств не указан, учетная запись пропускается, а вывод средств не инициируется. +2. **Валидатор вышел из стейкинга и средства доступны для вывода?** Если валидатор полностью вышел из стейкинга и наступила эпоха, когда его учетная запись считается «доступной для вывода», будет обработан полный вывод средств. При этом весь оставшийся баланс будет переведен на адрес для вывода. +3. **Достиг ли эффективный баланс максимума в 32?** Если у учетной записи есть учетные данные для вывода, она не вышла из стейкинга полностью и имеет вознаграждения сверх 32, будет обработан частичный вывод средств, в ходе которого на адрес для вывода пользователя будут переведены только вознаграждения сверх 32. Операторы валидаторов в течение жизненного цикла валидатора предпринимают только два действия, которые непосредственно влияют на этот поток: @@ -113,7 +109,7 @@ summaryPoints: ### Без газа {#gas-free} -Такой подход к выводу средств из стейкинга позволяет избежать необходимости дольщикам вручную отправлять транзакцию с просьбой о выводе определенной суммы ЕТН. Это означает, что **газ (плата за транзакцию)** не требуется, а выводы средств не конкурируют за существующее пространство блока уровня исполнения. +Такой подход к выводу средств из стейкинга позволяет избежать необходимости дольщикам вручную отправлять транзакцию с просьбой о выводе определенной суммы ЕТН. Это означает, что **не требуется газ (комиссия за транзакцию)**, а вывод средств не конкурирует за существующее пространство в блоках на уровне исполнения. ### Как часто я буду получать вознаграждения за стейкинг? {#how-soon} @@ -123,13 +119,13 @@ summaryPoints: -| Количество выводов | Время для завершения | -| :-------------------: | :--------------: | -| 400 000 | 3,5 дня | -| 500 000 | 4,3 дня | -| 600 000 | 5,2 дня | -| 700 000 | 6,1 дня | -| 800 000 | 7,0 дня | +| Количество выводов средств | Время выполнения | +| :------------------------: | :--------------: | +| 400 000 | 3,5 дня | +| 500 000 | 4,3 дня | +| 600 000 | 5,2 дня | +| 700 000 | 6,1 дня | +| 800 000 | 7,0 дней | @@ -138,15 +134,15 @@ summaryPoints: ## Часто задаваемые вопросы {#faq} -Нет, предоставление учетных данных для вывода средств — однократное действие, после отправки их нельзя изменить. +Нет, процесс предоставления учетных данных для вывода средств является одноразовым и не может быть изменен после отправки. @@ -158,27 +154,26 @@ eventName="read more"> -Если вы являетесь частью [стейкинг-пула](/staking/pools/) или удерживаете стейкинг-токены, то вы должны спросить у вашего поставщика более подробную информацию о том, как обрабатывается вывод из стейкинга, так как каждая служба работает по-своему. - -Как правило, пользователи должны иметь возможность свободно вернуть свои основные использованные в стейкинге ЕТН или изменить поставщика услуг стейкинга, которого они используют. Если конкретный пул становится слишком большим, средства могут быть выведены, выкуплены и повторно использованы в стейкинге у меньшего поставщика. А при наличии достаточного количества накопленных ЕТН вы можете [заниматься стейкингом дома](/staking/solo/). +Если вы являетесь участником [стейкинг-пула](/staking/pools/) или владеете токенами для стейкинга, вам следует обратиться к вашему провайдеру за более подробной информацией о том, как обрабатывается вывод средств из стейкинга, поскольку каждый сервис работает по-своему. +Как правило, пользователи должны иметь возможность свободно вернуть свои основные использованные в стейкинге ЕТН или изменить поставщика услуг стейкинга, которого они используют. Если конкретный пул становится слишком большим, средства могут быть выведены, выкуплены и повторно использованы в стейкинге у меньшего поставщика. Или, если вы накопили достаточно ETH, вы можете [заниматься стейкингом из дома](/staking/solo/). -Да, если у вашего валидатора указан адрес вывода средств. Его необходимо указать один раз, чтобы активировать возможность вывода средств. Затем выплаты вознаграждений будут автоматически срабатывать каждые несколько дней при каждом переборе валидаторов. +Да, если для вашего валидатора предоставлен адрес для вывода средств. Его необходимо указать один раз, чтобы активировать возможность вывода средств. Затем выплаты вознаграждений будут автоматически срабатывать каждые несколько дней при каждом переборе валидаторов. @@ -186,42 +181,40 @@ eventName="read more"> Нет. Если ваш валидатор все еще активен в сети, полный вывод не произойдет автоматически. Для этого необходимо вручную инициировать добровольный выход. Как только валидатор завершит процесс выхода (и если у учетной записи есть учетные данные для вывода средств), лишь тогда остаток будет выведен во время следующего перебора валидаторов. - - -Вывод средств производится автоматически, передавая все ЕТН, которые не вносят активного вклада в стейкинг. Это включает весь баланс на учетных записях, которые завершили процесс выхода. +Вывод средств разработан так, чтобы он происходил автоматически, переводя любые ETH, которые не вносят активного вклада в стейк. Это включает весь баланс на учетных записях, которые завершили процесс выхода. Запросить вывод конкретной желаемой суммы ETH вручную невозможно. Операторам валидаторов рекомендуется посетить страницу Вывод средств с панели запуска стейкинга, на которой можно найти более подробную информацию о том, как подготовить валидатор к выводу средств и сколько времени может понадобиться, а также более подробную информацию о том, как работает вывод средств. -Чтобы сначала опробовать свою конфигурацию в тестовой сети, посетите стартовую площадку для стейкинга в тестовой сети Holesky. - +Чтобы сначала опробовать свою настройку в тестовой сети, посетите Лаунчпад для стейкинга в тестовой сети Hoodi, чтобы начать. Нет. После выхода валидатора и вывода всего его баланса все дополнительные средства, размещаемые на этом валидаторе, будут автоматически переводиться на адрес для снятия средств во время следующего перебора валидаторов. Чтобы внести в стейкинг ETH заново, потребуется активировать новый валидатор. -## Дополнительная литература {#further-reading} +## Дополнительные материалы {#further-reading} -- [Вывод средств с панели запуска стейкинга](https://launchpad.ethereum.org/withdrawals) -- [EIP-4895: вывод средств в сети Beacon в виде операций](https://eips.ethereum.org/EIPS/eip-4895) -- [PEEPanEIP #94: вывод ETH из стейкинга (тестирование), Potuz и Сяо-Вэй Ван](https://www.youtube.com/watch?v=G8UstwmGtyE) -- [PEEPanEIP#68: EIP-4895: вывод средств в сети Beacon как операция (Алекс Стокс)](https://www.youtube.com/watch?v=CcL9RJBljUs) -- [Понимание эффективного баланса валидатора](https://www.attestant.io/posts/understanding-validator-effective-balance/) +- [Вывод средств на Лаунчпаде для стейкинга](https://launchpad.ethereum.org/withdrawals) +- [EIP-4895: Push-вывод средств из Beacon Chain в виде операций](https://eips.ethereum.org/EIPS/eip-4895) +- [PEEPanEIP #94: Вывод застейканных ETH (тестирование) с Potuz и Hsiao-Wei Wang](https://www.youtube.com/watch?v=G8UstwmGtyE) +- [PEEPanEIP#68: EIP-4895: Push-вывод средств из Beacon Chain в виде операций с Alex Stokes](https://www.youtube.com/watch?v=CcL9RJBljUs) +- [Объяснение эффективного баланса валидатора](https://www.attestant.io/posts/understanding-validator-effective-balance/) diff --git a/public/content/translations/ru/web3/index.md b/public/content/translations/ru/web3/index.md index 8b276ddeb9a..7261f009a89 100644 --- a/public/content/translations/ru/web3/index.md +++ b/public/content/translations/ru/web3/index.md @@ -1,65 +1,70 @@ --- -title: Что такое Web3 и почему это важно? -description: Введение в Web3, новый этап эволюции всемирной сети, и его важность. +title: "Что такое Web3 и почему это важно?" +description: "Введение в Web3, новый этап эволюции всемирной сети, и его важность." lang: ru --- # Введение в Web3 {#introduction} +
    + +
    + Централизация помогла миллиардам людей подключиться к всемирной сети и создать устойчивую инфраструктуру, благодаря которой она существует. В то же время горстка централизованных организаций контролирует целые сегменты всемирной сети и пользуются своим влиянием, чтобы решать, чему быть, а чему — нет. -Web3 — ответ на такое положение вещей. Вместо монополизированной сети крупных технологических компаний Web3 использует децентрализацию, принадлежит своим пользователям, создается и управляется ими. Web3 дает власть в руки личностям, а не корпорациям. Прежде чем говорить о Web3, давайте поймем, как мы оказались там, где мы есть. +Web3 — ответ на такое положение вещей. Вместо монополизированной сети крупных технологических компаний Web3 использует децентрализацию, принадлежит своим пользователям, создается и управляется ими. Web3 дает власть в руки личностям, а не корпорациям. +Прежде чем говорить о Web3, давайте поймем, как мы оказались там, где мы есть. -## Сеть на ранних этапах {#early-internet} +## Ранний Web {#early-internet} Большинство представляет всемирную сеть неизменной основой современной жизни: она была изобретена и с тех пор просто существует. Однако сеть, которую большинство из нас знают сегодня, сильно отличается от первоначально представляемой. Чтобы лучше в этом разобраться, полезно разбить краткую историю Интернета на ориентировочные периоды: Web 1.0 и Web 2.0. -### Web 1.0: только чтение (1990–2004 гг.) {#web1} +### Web 1.0: только для чтения (1990–2004) {#web1} В 1989 году в ЦЕРН (Женева) Тим Бернерс-Ли был занят разработкой протоколов, которые станут всемирной сетью. В чем идея? В том, чтобы создать открытые, децентрализованные протоколы, которые позволяют распространять информацию из любой точки земного шара. Первая версия творения Бернерса-Ли, сейчас известная как Web 1.0, существовала примерно между с 1990 по 2004 год. Сеть Web 1.0 представляла собой в основном статичные сайты, принадлежащие компаниям, и взаимодействие между пользователями было практически нулевым. Отдельные люди редко создавали контент, поэтому эта версия стала известен как «Интернет только для чтения». -![Клиент-серверная архитектура Web 1.0](./web1.png) +![Клиент-серверная архитектура, представляющая Web 1.0](./web1.png) -### Web 2.0: чтение и запись (с 2004 г. по сей день) {#web2} +### Web 2.0: чтение и запись (2004 — настоящее время) {#web2} Период Web 2.0 начался в 2004 г. с появлением социальных сетей. От модели «только для чтения» перешли к модели «чтение и запись». Компании начали предоставлять платформы для распространения контента, сгенерированного самими пользователями, и вовлекать пользователей в прямое взаимодействие друг с другом. По мере того как больше человек приходило в онлайн, горстка самых могущественных компаний начала контролировать непропорциональное количество трафика и прибыли, возникающей в сети. Модель Web 2.0 также породила модель доходов, основанную на рекламе. Несмотря на то, что пользователи могут создавать контент, они напрямую не владеют ни контентом, ни доходами от его монетизации. -![Клиент-серверная архитектура Web 2.0](./web2.png) +![Клиент-серверная архитектура, представляющая Web 2.0](./web2.png) -## Web 3.0: чтение, запись и владение {#web3} +## Web 3.0: чтение, запись, владение {#web3} -Концепт Web 3.0 был придуман сооснователем [Ethereum](/what-is-ethereum/) Гэвином Вудом вскоре после запуска Ethereum в 2014 г. Гэвин сформулировал решение проблемы, с которой сталкивались многие ранние криптоэнтузиасты: Интернет требовал слишком большого доверия. Иными словами, чтобы иметь возможность действовать в интересах общества, большая часть сети, которую люди знают и используют сегодня, опирается на доверие к горстке крупных частных кампаний. +Термин «Web 3.0» был введен сооснователем [Ethereum](/what-is-ethereum/) Гэвином Вудом вскоре после запуска Ethereum в 2014 году. Гэвин сформулировал решение проблемы, с которой сталкивались многие ранние криптоэнтузиасты: Интернет требовал слишком большого доверия. Иными словами, чтобы иметь возможность действовать в интересах общества, большая часть сети, которую люди знают и используют сегодня, опирается на доверие к горстке крупных частных кампаний. -![Децентрализованная архитектура Web3](./web3.png) +![Децентрализованная архитектура узлов, представляющая Web3](./web3.png) ### Что такое Web3? {#what-is-web3} -Web3 — это концепция нового, лучшего Интернета. Web3 основан на блокчейнах, криптовалютах и NFT, чтобы отдать власть обратно пользователям в форме владения. [Пост в Твиттере от 2021 года](https://twitter.com/j1mmyeth/status/1459003044067258370) объяснил все это лучше всего: модель Web1 была только для чтения, Web2 — для чтения и записи, а Web3 будет для чтения, записи и владения. +Web3 — это концепция нового, лучшего Интернета. Web3 основан на блокчейнах, криптовалютах и NFT, чтобы отдать власть обратно пользователям в форме владения. [В посте в Твиттере за 2020 год](https://twitter.com/himgajria/status/1266415636789334016) это было сказано лучше всего: Web1 был только для чтения, Web2 — для чтения и записи, а Web3 будет для чтения, записи и владения. -#### Ключевые идеи Web3 {#core-ideas} +#### Основные идеи Web3 {#core-ideas} Тяжело дать четкое определение для Web3, но есть несколько ключевых принципов. -- **Сеть Web3 децентрализована:** вместо больших сегментов Интернета, контролируемых и управляемых централизованными организациями, владение будет распределено между создателями и пользователями. -- **Web3 не регулируется:** все принимают участие на равных правах, и никто не исключается. -- **Платежи встроены в Web3:** для оплаты и переводов здесь используется криптовалюта, нет необходимости в устаревшей инфраструктуре банков и платежных систем. -- **Web3 не требует доверия:** все работает через экономические механизмы и не требует доверять какой-либо третьей стороне. +- **Web3 децентрализован:** вместо того чтобы большие сегменты интернета контролировались и принадлежали централизованным структурам, право собственности распределяется между его создателями и пользователями. +- **Web3 не требует разрешений:** каждый имеет равный доступ для участия в Web3, и никто не может быть исключен. +- **В Web3 есть встроенные платежи:** он использует криптовалюту для расходования и отправки денег в сети, не полагаясь на устаревшую инфраструктуру банков и платежных систем. +- **Web3 не требует доверия:** он работает с использованием стимулов и экономических механизмов, а не с опорой на доверенных третьих лиц. ### Почему Web3 — это важно? {#why-is-web3-important} Ключевые функции Web3 не изолированы и не вмещаются в четкие категории, но для простоты мы попытались разделить их и таким образом сделать проще для понимания. -#### Владение {#ownership} +#### Право собственности {#ownership} Web3 дает вам беспрецедентное владение вашими цифровыми активами. Например, вы хотите поиграть в web2-игру. Если вы покупаете внутриигровой предмет, он привязывается напрямую к вашему аккаунту. Если создатели игры удалят ваш аккаунт, вы потеряете ваши предметы. И если вы прекратите играть, то потеряете все, что вложено во внутриигровые предметы. -Web3 позволяет непосредственно владеть активами благодаря [невзаимозаменяемым токенам (NFT)](/glossary/#nft). Никто, даже создатели игры, не могут забрать у вас вашу собственность. Если вы прекратите играть, то сможете продать ваши предметы на открытых рынках и окупить их стоимость. +Web3 обеспечивает прямое владение через [невзаимозаменяемые токены (NFT)](/glossary/#nft). Никто, даже создатели игры, не могут забрать у вас вашу собственность. Если вы прекратите играть, то сможете продать ваши предметы на открытых рынках и окупить их стоимость. Изучите [ончейн-игры](/gaming/), чтобы увидеть это в действии. @@ -85,7 +90,7 @@ Web 2.0 требует от создателей контента верить Помимо владения своими данными в Web3, вы можете владеть платформой как коллектив, используя токены, которые действуют как акции компании. DAO позволяют вам координировать децентрализованное право собственности на платформу и принимать решения о ее будущем. -С технической точки зрения, DAO — это согласованные [смарт-контракты](/glossary/#smart-contract), которые автоматизируют децентрализованное принятие решений по пулу ресурсов (токенов). Пользователи с токенами голосуют за то, как ресурсы будут расходоваться, а код автоматически выполняет результаты голосования. +С технической точки зрения DAO — это согласованные [смарт-контракты](/glossary/#smart-contract), которые автоматизируют децентрализованное принятие решений по пулу ресурсов (токенов). Пользователи с токенами голосуют за то, как ресурсы будут расходоваться, а код автоматически выполняет результаты голосования. Однако многие сообщества Web3 считаются организациями DAO. Все эти сообщества имеют разные уровни децентрализации и автоматизации по коду. В настоящее время мы изучаем, что такое DAO и как они могут развиваться в будущем. @@ -94,7 +99,7 @@ Web 2.0 требует от создателей контента верить
    Подробнее о DAO
    - Больше о DAO + Подробнее о DAO     @@ -103,11 +108,12 @@ Web 2.0 требует от создателей контента верить Обычно вы создаете учетную запись на каждой платформе, которой пользуетесь. Например, у вас могут быть аккаунты Twitter, YouTube и Reddit. Хотите поменять отображаемое имя или картинку профиля? Нужно зайти в каждый аккаунт и сделать это. В некоторых случаях можно регистрироваться на платформах с помощью аккаунтов в соцсетях, но здесь есть та же самая проблема — цензура. Эти платформы могут одним щелчком перекрыть доступ ко всей вашей онлайн-жизни. Хуже того, многие платформы требуют чтобы им доверяли персональную информацию, и без этого не создают учетные записи. -Web3 решает эти проблемы, позволяя вам контролировать свой цифровой профиль с помощью адреса Ethereum и профиля [Ethereum Name Service (ENS)](/glossary/#ens). Использование адреса Ethereum предоставляет единый вход на многих платформах: безопасный, устойчивый к цензуре и анонимный. +Web3 решает эти проблемы, позволяя вам контролировать свою цифровую идентичность с помощью адреса Ethereum и профиля [Службы имен Ethereum (ENS)](/glossary/#ens). Использование адреса Ethereum предоставляет единый вход на многих платформах: безопасный, устойчивый к цензуре и анонимный. ### Встроенные платежи {#native-payments} -Платежная инфраструктура Web2 зависит от банков и платежных систем, исключая из экономики людей без банковских счетов и тех, кто живет в некой неугодной стране. Web3 использует такие токены, как [ETH](/glossary/#ether), чтобы отправлять деньги напрямую из браузера, и не требует доверенного посредника. +Платежная инфраструктура Web2 зависит от банков и платежных систем, исключая из экономики людей без банковских счетов и тех, кто живет в некой неугодной стране. +Web3 использует такие токены, как [ETH](/glossary/#ether), для отправки денег непосредственно в браузере и не требует доверенной третьей стороны. Подробнее об ETH @@ -119,17 +125,17 @@ Web3 решает эти проблемы, позволяя вам контро ### Доступность {#accessibility} -Важные преимущества Web3, такие как вход через Ethereum, уже доступны любому бесплатно. Но относительная цена транзакций остается помехой для многих. Web3 вряд ли будет активно использоваться в развивающихся странах из-за больших комиссий. В Ethereum эти проблемы решаются с помощью [дорожной карты](/roadmap/) и [решений Layer 2](/glossary/#layer-2). Технология готова, но необходимо более широкое внедрение решений слоя 2, чтобы сделать модель Web3 доступной для каждого. +Важные преимущества Web3, такие как вход через Ethereum, уже доступны любому бесплатно. Но относительная цена транзакций остается помехой для многих. Web3 вряд ли будет активно использоваться в развивающихся странах из-за больших комиссий. В Ethereum эти проблемы решаются с помощью [дорожной карты](/roadmap/) и [решений для масштабирования 2-го уровня](/glossary/#layer-2). Технология готова, но необходимо более широкое внедрение решений слоя 2, чтобы сделать модель Web3 доступной для каждого. ### Пользовательский опыт {#user-experience} -Технический барьер входа в Web3 на данный момент слишком высок. Пользователи должны быть компетентны в компьютерной безопасности, понимать сложную техническую документацию и использовать неинтуитивные интерфейсы. [Поставщики кошельков](/wallets/find-wallet/), в частности, работают над решением, но предстоит еще многое сделать для того, чтобы модель Web3 стала доступна массам. +Технический барьер входа в Web3 на данный момент слишком высок. Пользователи должны быть компетентны в компьютерной безопасности, понимать сложную техническую документацию и использовать неинтуитивные интерфейсы. [Поставщики кошельков](/wallets/find-wallet/), в частности, работают над решением этой проблемы, но необходим больший прогресс, прежде чем Web3 получит массовое распространение. -### Обучение {#education} +### Образование {#education} -Web3 вводит новые парадигмы, которые требуют учиться новым ментальным моделям, отличающимся от Web 2.0. Подобный процесс обучения уже происходил в конце 1990-х, когда сеть Web 1.0 набирала популярность. Тогда сторонники всемирной сети использовали множество образовательных методов для просвещения общественности, от простых метафор (информационная магистраль, обозреватели, веб-серфинг) до [телевизионных передач](https://www.youtube.com/watch?v=SzQLI7BxfYI). Сеть Web3 не сложна, просто она другая. Образовательные инициативы, направленные на разъяснение концепций Web3 пользователям Web2, жизненно важны для ее успеха. +Web3 вводит новые парадигмы, которые требуют учиться новым ментальным моделям, отличающимся от Web 2.0. Подобная образовательная кампания уже проходила в конце 1990-х, когда Web1.0 набирал популярность; сторонники всемирной паутины использовали множество образовательных техник для просвещения общественности, от простых метафор (информационная магистраль, браузеры, веб-серфинг) до [телевизионных передач](https://www.youtube.com/watch?v=SzQLI7BxfYI). Сеть Web3 не сложна, просто она другая. Образовательные инициативы, направленные на разъяснение концепций Web3 пользователям Web2, жизненно важны для ее успеха. -Ethereum.org вносит свой вклад в обучение использованию сети Web3 с помощью нашей [Программы перевода](/contributing/translation-program/), нацеленной на перевод важного контента об Ethereum на максимально возможное количество языков. +Ethereum.org вносит свой вклад в образование по Web3 с помощью нашей [Программы переводов](/contributing/translation-program/), цель которой — перевести важный контент об Ethereum на максимально возможное количество языков. ### Централизованная инфраструктура {#centralized-infrastructure} @@ -143,21 +149,21 @@ Web3 — это молодая и развивающаяся экосистем ## Как принять участие {#get-involved} -- [Создать кошелек](/wallets/) +- [Получить кошелек](/wallets/) - [Найти сообщество](/community/) - [Изучить приложения Web3](/apps/) - [Присоединиться к DAO](/dao/) - [Создавать в Web3](/developers/) -## Дополнительные ресурсы {#further-reading} +## Дополнительные материалы {#further-reading} У Web3 нет строгого определения. Разные участники сообщества смотрят на эту модель по-разному. Вот некоторые из них: -- [ Что такое Web3? Объяснение децентрализованного Интернета будущего](https://www.freecodecamp.org/news/what-is-web3) — _Nader Dabit_ -- [Разбираемся в Web 3](https://medium.com/l4-media/making-sense-of-web-3-c1a9e74dcae) — _Josh Stark_ -- [Почему Web3 — это важно](https://future.a16z.com/why-web3-matters/) — _Chris Dixon_ -- [Почему важна децентрализация](https://onezero.medium.com/why-decentralization-matters-5e3f79f7638e) — _Chris Dixon_ -- [Ландшафт Web3](https://a16z.com/wp-content/uploads/2021/10/The-web3-Readlng-List.pdf) — _a16z_ -- [Дебаты о Web3](https://www.notboring.co/p/the-web3-debate) — _Packy McCormick_ +- [Что такое Web3? [The Decentralized Internet of the Future Explained](https://www.freecodecamp.org/news/what-is-web3) – _Nader Dabit_ +- [Making Sense of Web 3](https://medium.com/l4-media/making-sense-of-web-3-c1a9e74dcae) – _Josh Stark_ +- [Why Web3 Matters](https://a16zcrypto.com/posts/article/why-web3-matters/) — _Chris Dixon_ +- [Why Decentralization Matters](https://onezero.medium.com/why-decentralization-matters-5e3f79f7638e) - _Chris Dixon_ +- [The Web3 Landscape](https://a16z.com/wp-content/uploads/2021/10/The-web3-Readlng-List.pdf) – _a16z_ +- [The Web3 Debate](https://www.notboring.co/p/the-web3-debate) – _Packy McCormick_ diff --git a/public/content/translations/ru/what-are-apps/index.md b/public/content/translations/ru/what-are-apps/index.md new file mode 100644 index 00000000000..470fefb392a --- /dev/null +++ b/public/content/translations/ru/what-are-apps/index.md @@ -0,0 +1,80 @@ +--- +title: "Ethereum приложения" +metaTitle: "Приложения Ethereum | Децентрализованные приложения на Ethereum" +description: "Приложения на Ethereum бесплатные, глобальные и используют публичный блокчейн вместо частных серверов компании. Это означает, что вы можете использовать один и тот же аккаунт в каждом проекте и сохранять свою конфиденциальность." +lang: ru +template: use-cases +emoji: ":handshake:" +sidebarDepth: 2 +showDropdown: false +image: /images/doge-computer.png +summary: "Приложения на Ethereum бесплатные, глобальные и используют публичный блокчейн вместо частных серверов компании. Это означает, что вы можете использовать один и тот же аккаунт в каждом проекте и сохранять свою конфиденциальность." +--- + +## Приложения с суперспособностями {#apps-with-superpowers} + +Ethereum приложения могут ощущаться как обычные приложения. Но за кулисами у них есть некоторые особые качества. + +Как только приложение опубликовано на блокчейне Ethereum, его уже невозможно остановить. Это связано с тем, что сеть Ethereum децентрализована среди тысяч компьютеров по всему миру. Никто не может остановить работающие на Ethereum приложения, потому что нет единого сервера для цели. Ethereum также является нейтральным, поэтому любой человек в мире может использовать его или даже подключаться к нему и создавать на его основе свои модификации. + +## Что такое децентрализованное приложение? {#what-is-a-dapp} + +Логика Ethereum приложений выполняется на блокчейне Ethereum вместо централизованных серверов. Вот почему их часто называют децентрализованными приложениями или сокращенно на англ. — dapps. + + + + + + + +## Почему это важно {#why-does-this-matter} + +Ethereum приложения могут делать вещи, которые просто невозможны с помощью традиционных приложений. Например, дать денег в долг совершенно незнакомому человеку с гарантией, что вы получите свои деньги обратно вместе с процентами. Без платы «надежному» посреднику, например юристу, для оформления сделки. + +Существуют приложения для всех нужд: игр, финансов, работы, обмена сообщениями, хранения данных и многого другого. В большинстве приложений вы не столкнетесь с рекламой или ограничением доступа. + +Все, что вам нужно, — это Ethereum кошелек и немного ETH, чтобы начать пользоваться любым приложением Ethereum. + +## Как это работает {#how-does-it-work} + +Приложения работают на основе умных контрактов — фрагментов кода, которые находятся в блокчейне Ethereum. В отличие от традиционных приложений, им не нужна компания для их работы. + +| Особенность | Традиционные приложения | Ethereum приложения | +| ---------------------------------- | ------------------------- | ---------------------------- | +| **Кто контролирует их?** | Компания | Никто | +| **Работают на** | Частных серверах компании | Публичном блокчейне Ethereum | +| **Могут ли подвергаться цензуре?** | Да | Нет | +| **Кто владеет вашими данными?** | Обычно не вы | Вы владеете вашими данными | + + + +
    + +![](./developers-eth-blocks.png) +
    + +## Ethereum приложения похожи на лего {#ethereum-apps-are-like-legos} + +Если все приложения созданы на Ethereum, они все совместимы. Токен для одного приложения будет работать и в совершенно другом. Это как возможность публиковать твиты на своей стене в Facebook. На самом деле зачастую вы можете повторно использовать один и тот же профиль в ряде различных Ethereum приложений без необходимости регистрироваться везде отдельно. + + + +## Дополнительные материалы {#further-reading} + +- [Ethereum для начинающих](/what-is-ethereum) +- [Что такое умный контракт?](/developers/docs/smart-contracts/) +- [Техническая документация децентрализованных приложений](/developers/docs/dapps/) + +## Часто задаваемые вопросы {#faq} + + +

    Англ. dapp означает децентрализованные приложения. Это приложения, созданные на блокчейн сетях, таких как Ethereum. Они называются децентрализованными, т. к. лежащая в их основе сеть децентрализована.

    +     + + +

    Некоторые приложения позволяют вам торговать или покупать криптовалюту, но не все приложения предназначены для этого. Если вы хотите купить свои первые токены, посетите страницу [Получить ETH](/get-eth).

    +     + + +

    Криптокошелек позволяет вам хранить ваши токены и управлять вашим аккаунтом Ethereum. Существует множество замечательных кошельков, каждый из которых выполняет своё предназначение. Чтобы узнать, какой кошелек подходит именно вам, посетите наш [список кошельков](/wallets/find-wallet).

    +     \ No newline at end of file diff --git a/public/content/translations/ru/whitepaper/index.md b/public/content/translations/ru/whitepaper/index.md index eb40f2bb156..423e7c22a35 100644 --- a/public/content/translations/ru/whitepaper/index.md +++ b/public/content/translations/ru/whitepaper/index.md @@ -1,34 +1,34 @@ --- -title: Техническая документация Ethereum -description: Вводная статья об Ethereum, опубликованная до его запуска в 2013 году. +title: "Белая книга Ethereum" +description: "Вводная статья об Ethereum, опубликованная до его запуска в 2013 году." lang: ru sidebarDepth: 2 hideEditButton: true --- -# Техническая документация об Ethereum {#ethereum-whitepaper} +# Вайтпейпер Ethereum {#ethereum-whitepaper} -_Эта вводная статья была опубликована в 2014 году основателем [Ethereum](/what-is-ethereum/) Виталиком Бутериным, до запуска проекта в 2015 году. Стоит отметить, что Ethereum, как и многие проекты с открытым исходным кодом, со временем эволюционировал._ +_Эта вступительная статья была первоначально опубликована в 2014 году Виталиком Бутериным, основателем [Ethereum](/what-is-ethereum/), до запуска проекта в 2015 году. Стоит отметить, что Ethereum, как и многие проекты с открытым исходным кодом, со временем эволюционировал._ -_Несмотря на то что этой статье уже несколько лет, мы не удаляем ее, потому что она продолжает служить полезным источником, содержащим точную информацию об Ethereum и его видении. Чтобы узнать о нововведениях в Ethereum и о внесении изменений в протокол, рекомендуем ознакомиться с [этим руководством](/learn/)._ +_Несмотря на то что этой статье уже несколько лет, мы не удаляем ее, потому что она продолжает служить полезным источником, содержащим точную информацию об Ethereum и его видении. Чтобы узнать о последних разработках Ethereum и о том, как вносятся изменения в протокол, мы рекомендуем [это руководство](/learn/)._ -[Этот PDF предназначен для исследователей и ученых, которым нужна историческая или каноническая версия проектного документа [от декабря 2014 года].](./whitepaper-pdf/Ethereum_Whitepaper_-_Buterin_2014.pdf) +[Исследователям и ученым, которым нужна историческая или каноническая версия вайтпейпера [от декабря 2014 года], следует использовать этот PDF-файл.](./whitepaper-pdf/Ethereum_Whitepaper_-_Buterin_2014.pdf) -## Платформа следующего поколения для смарт-контрактов и децентрализованных приложений {#a-next-generation-smart-contract-and-decentralized-application-platform} +## Платформа нового поколения для смарт-контрактов и децентрализованных приложений {#a-next-generation-smart-contract-and-decentralized-application-platform} -Создание биткоина в 2009 году Сатоши Накамото часто называется радикальной разработкой в деньгах и валюте, являясь первым примером цифрового актива, который одновременно не имеет основы или [внутренней ценности](http://bitcoinmagazine.com/8640/an-exploration-of-intrinsic-value-what-it-is-why-bitcoin-doesnt-have-it-and-why-bitcoin-does-have-it/) и не имеет централизованного эмитента или контроллера. Тем не менее другой, возможно, более важной, частью эксперимента является базовая технология блокчейн как инструмент распределенного консенсуса, и внимание быстро начинает смещаться к этому аспекту биткоина. Часто упоминаемые альтернативные приложения технологии блокчейн включают использование цифровых активов на блокчейне для представления пользовательских валют и финансовых инструментов ([цветных монет](https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit)), право собственности на лежащее в основе физическое устройство ([смарт-объект](https://en.bitcoin.it/wiki/Smart_Property)), невзаимозаменяемые активы, такие как доменные имена ([Namecoin](http://namecoin.org)), а также более сложные приложения, в которых цифровые активы напрямую контролируются частью кода, реализующей произвольные правила ([смарт-контракты](http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/idea.html)) или даже основанные на блокчейне [децентрализованные автономные организации](http://bitcoinmagazine.com/7050/bootstrapping-a-decentralized-autonomous-corporation-part-i/) (DAO). То, что Ethereum планирует предоставить — это блокчейн со встроенным полным по Тьюрингу языком программирования, который может быть использован для создания контрактов, которые можно использовать для кодирования произвольных функций перехода состояния, позволяя пользователям создавать любые из систем, описанных выше, как и многие другие, которые мы еще даже не придумали, просто записав логику в нескольких строках кода. +Разработка Bitcoin Сатоши Накамото в 2009 году часто преподносилась как радикальное событие в мире денег и валюты, став первым примером цифрового актива, который одновременно не имеет обеспечения или «[внутренней ценности](https://bitcoinmagazine.com/culture/an-exploration-of-intrinsic-value-what-it-is-why-bitcoin-doesnt-have-it-and-why-bitcoin-does-have-it)» и не имеет централизованного эмитента или контролера. Тем не менее другой, возможно, более важной, частью эксперимента является базовая технология блокчейн как инструмент распределенного консенсуса, и внимание быстро начинает смещаться к этому аспекту биткоина. Часто цитируемые альтернативные варианты применения технологии блокчейн включают использование внутрисетевых цифровых активов для представления пользовательских валют и финансовых инструментов («[цветные монеты](https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit)»), права собственности на базовое физическое устройство («[умная собственность](https://en.bitcoin.it/wiki/Smart_Property)»), невзаимозаменяемые активы, такие как доменные имена («[Namecoin](http://namecoin.org)»), а также более сложные приложения, в которых цифровые активы напрямую контролируются фрагментом кода, реализующим произвольные правила («[смарт-контракты](http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/idea.html)») или даже «[децентрализованные автономные организации](http://bitcoinmagazine.com/7050/bootstrapping-a-decentralized-autonomous-corporation-part-i/)» (ДАО) на основе блокчейна. То, что Ethereum планирует предоставить — это блокчейн со встроенным полным по Тьюрингу языком программирования, который может быть использован для создания контрактов, которые можно использовать для кодирования произвольных функций перехода состояния, позволяя пользователям создавать любые из систем, описанных выше, как и многие другие, которые мы еще даже не придумали, просто записав логику в нескольких строках кода. ## Введение в Bitcoin и существующие концепции {#introduction-to-bitcoin-and-existing-concepts} ### История {#history} -Концепция децентрализованной цифровой валюты, как и альтернативные приложения, такие как реестры собственности, существует уже несколько десятилетий. Протоколы анонимных электронных платежей 1980-х и 1990-х годов, в основном опирающиеся на криптографический примитив, известный как ослепление Чаума, обеспечивали высокую степень конфиденциальности валюты, но протоколы в значительной степени не смогли завоевать популярность из-за их зависимости от централизованного посредника. В 1998 году [b-money](http://www.weidai.com/bmoney.txt) Вэя Дая стали первым предложением, вводящим идею создания денег путем решения вычислительных головоломок, а также децентрализованного консенсуса, но в предложении было недостаточно информации о том, как реализовать децентрализованный консенсус. В 2005 году Хэл Финни представил концепцию [многоразовых доказательств выполнения работы](https://nakamotoinstitute.org/finney/rpow/), систему, которая использовала идеи b-money и вычислительно сложные Hashcash головоломки Адама Бэка для создания концепции криптовалюты, но в очередной раз не дотянула до идеала, положившись на доверенные вычисления в качестве бэкенда. В 2009 году децентрализованная валюта была впервые реализована на практике Сатоши Накамото, сочетающая сложившиеся примитивы для управления правом собственности (криптография с открытым ключом) с алгоритмом консенсуса для отслеживания владельцев монет, известным как «доказательство выполнения работы». +Концепция децентрализованной цифровой валюты, как и альтернативные приложения, такие как реестры собственности, существует уже несколько десятилетий. Протоколы анонимных электронных платежей 1980-х и 1990-х годов, в основном опирающиеся на криптографический примитив, известный как ослепление Чаума, обеспечивали высокую степень конфиденциальности валюты, но протоколы в значительной степени не смогли завоевать популярность из-за их зависимости от централизованного посредника. В 1998 году [b-money](http://www.weidai.com/bmoney.txt) Вэй Дая стало первым предложением, в котором была представлена идея создания денег путем решения вычислительных головоломок и децентрализованного консенсуса, но в предложении было мало подробностей о том, как на самом деле можно реализовать децентрализованный консенсус. В 2005 году Хэл Финни представил концепцию «[многоразовых доказательств выполнения работы](https://nakamotoinstitute.org/finney/rpow/)» — систему, которая использует идеи из b-money вместе с вычислительно сложными головоломками Hashcash Адама Бэка для создания концепции криптовалюты, но снова не достигла идеала, полагаясь на доверенные вычисления в качестве серверной части. В 2009 году децентрализованная валюта была впервые реализована на практике Сатоши Накамото, сочетающая сложившиеся примитивы для управления правом собственности (криптография с открытым ключом) с алгоритмом консенсуса для отслеживания владельцев монет, известным как «доказательство выполнения работы». -Механизм, лежавший в основе доказательства выполнения работы был значительным прорывом, так как он одновременно решил две проблемы. Во-первых, он обеспечил простой и умеренно эффективный алгоритм консенсуса, позволяя узлам в сети коллективно согласовать набор канонических обновлений к состоянию реестра биткоина. Во-вторых, он обеспечил механизм, позволяющий свободно вмешиваться в процесс консенсуса, решая политическую задачу о том, кто получит возможность влиять на консенсус, одновременно предотвращая атаки Сивиллы. Это достигается путем замены формального барьера для участия, такого как требование быть зарегистрированным как уникальная организация в конкретном списке, экономическим барьером — вес отдельного узла в процессе консенсусного голосования прямо пропорционален вычислительной мощности, которой располагает узел. С тех пор был предложен альтернативный подход, называемый _доказательством доли владения_, вычисляющий вес узла пропорционально его валютным резервам, а не вычислительным ресурсам; обсуждение относительных достоинств двух подходов выходит за рамки данной статьи, но следует отметить, что оба подхода могут быть использованы как основа для криптовалюты. +Механизм, лежавший в основе доказательства выполнения работы был значительным прорывом, так как он одновременно решил две проблемы. Во-первых, он обеспечил простой и умеренно эффективный алгоритм консенсуса, позволяя узлам в сети коллективно согласовать набор канонических обновлений к состоянию реестра биткоина. Во-вторых, он обеспечил механизм, позволяющий свободно вмешиваться в процесс консенсуса, решая политическую задачу о том, кто получит возможность влиять на консенсус, одновременно предотвращая атаки Сивиллы. Это достигается путем замены формального барьера для участия, такого как требование быть зарегистрированным как уникальная организация в конкретном списке, экономическим барьером — вес отдельного узла в процессе консенсусного голосования прямо пропорционален вычислительной мощности, которой располагает узел. С тех пор был предложен альтернативный подход под названием _доказательство владения_, при котором вес узла рассчитывается пропорционально его валютным активам, а не вычислительным ресурсам; обсуждение относительных достоинств этих двух подходов выходит за рамки данной статьи, но следует отметить, что оба подхода могут служить основой для криптовалюты. -### Биткоин как система с изменяющимися состояниями {#bitcoin-as-a-state-transition-system} +### Bitcoin как система смены состояний {#bitcoin-as-a-state-transition-system} -![Смена состояния Ethereum](./ethereum-state-transition.png) +![Смена состояния в Ethereum](./ethereum-state-transition.png) С технической точки зрения, реестр криптовалюты, такой как биткоин, можно рассматривать как систему с изменяющимися состояниями, где есть «состояние», состоящее из статуса принадлежности всех существующих биткоинов, и «функция смены состояния», которая берет состояние и транзакцию и выводит новое результирующее состояние. В стандартной банковской системе, например, состояние является балансом, транзакция — запросом на перемещение $X от A к B, а функция смены состояния уменьшает значение в аккаунте A на $X и увеличивает значение в аккаунте B на $X. Если счет А имеет менее $X, то функция смены состояния возвращает ошибку. Таким образом, формально можно определить: @@ -50,25 +50,25 @@ APPLY({ Alice: $50, Bob: $50 },"отправить $70 от Alice к Bob") = ERR «Состояние» в биткоине — это все монеты (технически, «неизрасходованные выводы транзакции» или UTXO), которые были произведены и еще не израсходованы, причем каждый UTXO имеет номинал и владельца (определяется 20-байтовым адресом, который по сути является криптографическим открытым ключом[fn1](#notes)). Транзакция содержит один или более вводов, где каждый ввод содержит ссылку на существующий UTXO и криптографическую подпись, созданную с помощью закрытого ключа, связанного с адресом владельца, и один или более выводов, каждый из которых содержит новый UTXO для добавления к состоянию. -Функцию смены состояния `APPLY(S, TX) -> S'` можно определить примерно следующим образом: +Функцию смены состояния `APPLY(S,TX) -> S'` можно определить примерно следующим образом:
    1. Для каждого входного значения в TX:
      • - Если упомянутый UTXO отсутствует в S, вернуть сообщение об ошибке. + Если указанный UTXO отсутствует в S, вернуть ошибку.
      • - Если предоставленная подпись не соответствует владельцу UTXO, вернуть сообщение об ошибке. + Если предоставленная подпись не соответствует владельцу UTXO, вернуть ошибку.
    2. - Если сумма номиналов всех вводимых UTXO меньше суммы номиналов всех выводимых UTXO, вернуть сообщение об ошибке. + Если сумма номиналов всех входных UTXO меньше суммы номиналов всех выходных UTXO, вернуть ошибку.
    3. - Вернуть S, где удалены все UTXO ввода и добавлены все UTXO вывода. + Вернуть S со всеми удаленными входными UTXO и добавленными выходными UTXO.
    @@ -78,35 +78,38 @@ APPLY({ Alice: $50, Bob: $50 },"отправить $70 от Alice к Bob") = ERR ![Блоки Ethereum](./ethereum-blocks.png) -Если бы у нас был доступ к надежному централизованному сервису, реализовать эту систему было бы просто. Ее можно было бы просто написать с помощью кода точно так, как описано, используя жесткий диск централизованного сервера для отслеживания состояния. Однако с биткоином мы пытаемся построить децентрализованную валютную систему, поэтому нам нужно будет объединить систему смены состояния с системой консенсуса, чтобы гарантировать, что все согласны с порядком транзакций. Децентрализованный консенсусный процесс биткоина требует наличия узлов в сети, чтобы постоянно пытаться создавать пакеты из транзакций, называемые «блоками». Сеть рассчитана на создание примерно одного блока каждые десять минут, где каждый блок, содержит метку времени, называемую «nonce», ссылку на предыдущий блок (т. е. его хэш) и список всех транзакций, которые произошли после предыдущего блока. Со временем это создает неизменную, постоянно растущую цепочку блоков (так называемый «блокчейн»), которая постоянно обновляется, чтобы представлять последнее состояние реестра биткоина. +Если бы у нас был доступ к надежному централизованному сервису, реализовать эту систему было бы просто. Ее можно было бы просто написать с помощью кода точно так, как описано, используя жесткий диск централизованного сервера для отслеживания состояния. Однако с биткоином мы пытаемся построить децентрализованную валютную систему, поэтому нам нужно будет объединить систему смены состояния с системой консенсуса, чтобы гарантировать, что все согласны с порядком транзакций. Децентрализованный консенсусный процесс биткоина требует наличия узлов в сети, чтобы постоянно пытаться создавать пакеты из транзакций, называемые «блоками». Сеть предназначена для создания примерно одного блока каждые десять минут, при этом каждый блок содержит временную метку, nonce, ссылку (т. е. хэш) на предыдущий блок и список всех транзакций, которые произошли с момента создания предыдущего блока. Со временем это создает неизменную, постоянно растущую цепочку блоков (так называемый «блокчейн»), которая постоянно обновляется, чтобы представлять последнее состояние реестра биткоина. Алгоритм проверки достоверности блока в этой модели следующий: 1. Проверить, что прошлый блок ссылается на существующий достоверный блок. 2. Проверить, что временная метка блока больше, чем временная метка предыдущего блока[fn2](#notes) и прошло менее 2 часов с момента создания предыдущего блока 3. Проверить, что доказательство выполнения работы над блоком является действительным. -4. Пусть `S[0]` будет состоянием в конце предыдущего блока. -5. Предположим, что `TX` является списком транзакций блока с `n` транзакциями. Для всех `i` в диапазоне `0...n-1`, задать `S[i+1] = APPLY(S[i], X[i])` Если какое-либо приложение возвращает ошибку, выйти и вернуть false. -6. Вернуть значение true и установить `S[n]` в качестве состояния в конце этого блока. +4. Пусть `S[0]` — это состояние в конце предыдущего блока. +5. Предположим, `TX` — это список транзакций блока с `n` транзакциями. Для всех `i` в `0...n-1`, установить `S[i+1] = APPLY(S[i],TX[i])`. Если какое-либо приложение вернет ошибку, выйти и вернуть false. +6. Вернуть true и зарегистрировать `S[n]` как состояние в конце этого блока. -По сути, каждая транзакция в блоке должна обеспечивать достоверный переход от канонического состояния до выполнения транзакции к новому состоянию. Обратите внимание, что состояние никак не закодировано в блоке. Это чисто абстракция, которая запоминается проверяющим узлом и может быть (безопасно) вычислена для любого блока только начиная с состояния генезиса и последовательно применяя каждую транзакцию в каждом блоке. Кроме того, обратите внимание, что важен порядок, в котором майнер включает транзакции в блок. Если две транзакции A и B в блоке такие, что B тратит UTXO, созданный A, тогда блок будет действителен, если A располагается раньше B, но не иначе. +По сути, каждая транзакция в блоке должна обеспечивать достоверный переход от канонического состояния до выполнения транзакции к новому состоянию. Обратите внимание, что состояние никак не закодировано в блоке. Это чисто абстракция, которая запоминается проверяющим узлом и может быть (безопасно) вычислена для любого блока только начиная с состояния генезиса и последовательно применяя каждую транзакцию в каждом блоке. Кроме того, обратите внимание, что важен порядок, в котором +майнер включает транзакции в блок. Если две транзакции A и B в блоке такие, что B тратит UTXO, созданный A, тогда блок будет действителен, если A располагается раньше B, но не иначе. -Одно из условий действительности, приведенное в списке выше, которое не встречается в других системах, является требованием «доказательства выполнения работы». Точное условие состоит в том, что двойной SHA256 хэш каждого блока, рассматриваемый как 256-битное число, должен быть меньше динамически настраиваемого целевого значения, которое на время этой записи составляет приблизительно 2187. Цель этого состоит в том, чтобы сделать создание блоков вычислительно «сложным», тем самым не позволяя злоумышленникам с помощью атаки Сивиллы переделать весь блокчейн в свою пользу. Поскольку алгоритм SHA256 разработан как полностью непредсказуемая псевдослучайная функция, то единственный способ создать действительный блок — методом проб и ошибок, постоянно увеличивая число nonce и проверяя, соответствует ли новый хэш условию. +Одно из условий действительности, приведенное в списке выше, которое не встречается в других системах, является требованием «доказательства выполнения работы». Точное условие состоит в том, что двойной SHA256 хэш каждого блока, рассматриваемый как 256-битное число, должен быть меньше динамически настраиваемого целевого значения, которое на время этой записи составляет приблизительно 2187. Цель этого состоит в том, чтобы сделать создание блоков вычислительно «сложным», тем самым не позволяя злоумышленникам с помощью атаки +Сивиллы переделать весь блокчейн в свою пользу. Поскольку алгоритм SHA256 разработан как полностью непредсказуемая псевдослучайная функция, то единственный способ создать действительный блок — методом проб и ошибок, постоянно увеличивая число nonce и проверяя, соответствует ли новый хэш условию. При текущем целевом значении ~2187 сеть должна сделать в среднем ~269 попыток, прежде чем будет найден допустимый блок. Как правило, цель пересчитывается сетью каждые 2016 блоков, так что в среднем новый блок создается каким-либо узлом в сети каждые десять минут. В качестве вознаграждения за эту вычислительную работу майнер каждого блока имеет право включить транзакцию, дающую ему 25 BTC. Кроме того, если общая сумма вводов транзакции превышает сумму выводов, разница также достается майнеру в качестве комиссии. Кстати, это также единственный механизм выпуска BTC. Состояние генезиса вообще не содержало монет. -Чтобы лучше понять цель майнинга, рассмотрим, что происходит в случае злонамеренной атаки. Поскольку базовая криптография биткоина безопасна, злоумышленник будет атаковать ту часть системы, которая не защищена криптографией напрямую: порядок транзакций. Стратегия злоумышленника проста: +Чтобы лучше понять цель майнинга, рассмотрим, что +происходит в случае злонамеренной атаки. Поскольку базовая криптография биткоина безопасна, злоумышленник будет атаковать ту часть системы, которая не защищена криптографией напрямую: порядок транзакций. Стратегия злоумышленника проста: 1. Отправить 100 BTC продавцу в обмен на некоторый продукт (желательно цифровой товар с быстрой доставкой) 2. Дождаться доставки товара 3. Создать еще одну транзакцию, отправляя те же самые 100 BTC самому себе 4. Постараться убедить сеть в том, что его транзакция самому себе была первой. -Как только первый шаг произойдет, через несколько минут какой-нибудь майнер включит транзакцию в блок, допустим в блок номер 270000. Примерно через час еще пять блоков будут добавлены в цепочку после этого блока, каждый из которых косвенно указывает на транзакцию и таким образом подтверждает ее. На этом этапе продавец примет платеж как завершенный и доставит продукт; так как мы предполагаем, что это цифровой товар, то доставка мгновенна. Теперь злоумышленник создает еще одну транзакцию, отправляя 100 BTC себе. Если злоумышленник просто создаст ее, транзакция не будет обработана; майнеры попытаются запустить `APPLY(S,TX)` и заметят, что `TX` расходует UTXO, которого больше нет в состоянии. Поэтому вместо этого злоумышленник создает ответвление блокчейна. Для начала он добывает другую версию блока 270000, указывающего на тот самый блок 269999 в качестве родительского, но с новой транзакцией вместо старой. Поскольку данные блока отличаются, потребуется повторное доказательство выполнения работы. Кроме того, новая версия блока 270000 злоумышленника имеет другой хэш, поэтому исходные блоки с 270001 по 270005 не указывают на него; таким образом, исходная цепочка и новая цепочка злоумышленника полностью разделены. Правило таково, что в ответвлении самый длинный блокчейн считается истинным, поэтому майнеры будут работать над цепочкой с последним блоком 270005, в то время как атакующий работает в одиночку над блоком 270000. Чтобы злоумышленник сделал свой блокчейн самым длинным, ему потребуется больше вычислительной мощности, чем у остальной сети вместе взятой (отсюда и название «атака 51%»). +Как только первый шаг произойдет, через несколько минут какой-нибудь майнер включит транзакцию в блок, допустим в блок номер 270000. Примерно через час еще пять блоков будут добавлены в цепочку после этого блока, каждый из которых косвенно указывает на транзакцию и таким образом подтверждает ее. На этом этапе продавец примет платеж как завершенный и доставит продукт; так как мы предполагаем, что это цифровой товар, то доставка мгновенна. Теперь злоумышленник создает еще одну транзакцию, отправляя 100 BTC себе. Если злоумышленник просто отправит ее, транзакция не будет обработана; майнеры попытаются запустить `APPLY(S,TX)` и заметят, что `TX` использует UTXO, которого больше нет в данном состоянии. Поэтому вместо этого злоумышленник создает ответвление блокчейна. Для начала он добывает другую версию блока 270000, указывающего на тот самый блок 269999 в качестве родительского, но с новой транзакцией вместо старой. Поскольку данные блока отличаются, потребуется повторное доказательство выполнения работы. Кроме того, новая версия блока 270000 злоумышленника имеет другой хэш, поэтому исходные блоки с 270001 по 270005 не указывают на него; таким образом, исходная цепочка и новая цепочка злоумышленника полностью разделены. Правило таково, что в ответвлении самый длинный блокчейн считается истинным, поэтому майнеры будут работать над цепочкой с последним блоком 270005, в то время как атакующий работает в одиночку над блоком 270000. Чтобы злоумышленник сделал свой блокчейн самым длинным, ему потребуется больше вычислительной мощности, чем у остальной сети вместе взятой (отсюда и название «атака 51%»). ### Деревья Меркла {#merkle-trees} -![SPV в биткоине](./spv-bitcoin.png) +![SPV в Bitcoin](./spv-bitcoin.png) _Слева: достаточно представить только небольшое количество узлов в дереве Меркла, чтобы подтвердить правильность ветки._ @@ -116,28 +119,28 @@ _Справа: любая попытка изменить любую часть Пожалуй, протокол дерева Меркла необходим для долгосрочной устойчивости. Полный узел в сети биткоина, который хранит и обрабатывает полностью каждый блок, занимает около 15 ГБ дискового пространства по состоянию на апрель 2014 года и растет более чем на гигабайт каждый месяц. В настоящее время это приемлемо для некоторых настольных компьютеров, но не телефонов, и в будущем участвовать смогут только компании и любители. Протокол SPV позволяет существовать другому классу узлов, называемому «легкие узлы», которые загружают заголовки блоков, проверяют доказательство выполнения работы в заголовках блоков, а затем загружают только ветви, связанные с транзакциями, имеющими к ним отношение. Это позволяет легким узлам с надежной гарантией безопасности определять статус любой транзакции с биткоином и их текущий баланс при загрузке только очень небольшой части всего блокчейна. -### Альтернативные применения блокчейна {#alternative-blockchain-applications} +### Альтернативные блокчейн-приложения {#alternative-blockchain-applications} -Идея взять лежащую в основе блокчейна идею и применить ее к другим концепциям также имеет длинную историю. В 2005 году Ник Сабо выступил с концепцией «[безопасных прав на имущество с полномочиями владельца](https://nakamotoinstitute.org/secure-property-titles/)», документом, описывающим, как «новые достижения в технологии реплицирования баз данных» позволят создать основанную на блокчейне систему для хранения реестра владельцев земли, создавая тщательно продуманную структуру, включающую такие понятия, как гомстединг, незаконное владение и земельный налог Генри Джорджа. Однако, к сожалению, в то время не было эффективной реплицируемой системы баз данных, и поэтому протокол не был реализован на практике. Но после 2009 года, когда был разработан децентрализованный консенсус биткоина, быстро начали появляться альтернативные приложения. +Идея взять лежащую в основе блокчейна идею и применить ее к другим концепциям также имеет длинную историю. В 2005 году Ник Сабо выступил с концепцией «[защищенных прав собственности с полномочиями владельца](https://nakamotoinstitute.org/library/secure-property-titles/)», документом, описывающим, как «новые достижения в технологии реплицируемых баз данных» позволят создать систему на основе блокчейна для хранения реестра о том, кто какой землей владеет, создав сложную структуру, включающую такие концепции, как гомстединг, незаконное владение и налог на землю по системе Джорджа. Однако, к сожалению, в то время не было эффективной реплицируемой системы баз данных, и поэтому протокол не был реализован на практике. Но после 2009 года, когда был разработан децентрализованный консенсус биткоина, быстро начали появляться альтернативные приложения. -- **Namecoin**. [Namecoin](https://namecoin.org/), созданный в 2010 году, — это децентрализованная база данных регистрации имен. В децентрализованных протоколах, таких как Tor, Bitcoin и BitMessage, должен быть какой-то способ идентификации аккаунтов, чтобы другие люди могли взаимодействовать с ними, но во всех существующих решениях единственным доступным идентификатором является псевдослучайный хеш, вроде `1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy`. В идеале хотелось бы иметь возможность иметь аккаунт с именем, например george. Однако, проблема в том, что если один человек может создать аккаунт с именем george, затем кто-то другой также может зарегистрироваться как george и выдать себя за него. Единственное решение — парадигма первой регистрации, когда второй пользователь, регистрирующий аккаунт, терпит неудачу, — проблема, идеально подходящая для консенсуса протокола биткоина. Namecoin — старейшая и наиболее успешная реализация системы регистрации имен, использующая такую идею. -- **Цветные монеты** — цель [цветных монет](https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit) — служить протоколом, позволяющим людям создавать собственные цифровые валюты или, в важном тривиальном случае валюты с одной единицей, цифровые токены на блокчейне биткоина. В протоколе цветных монет кто-то выпускает новую валюту, публично назначая цвет определенному UTXO биткоина, и протокол рекурсивно определяет цвет других UTXO таким образом, чтобы он совпадал с цветом вводов, на которые была потрачена создавшая их транзакция (в случае вводов смешанного цвета применяются специальные правила). Это позволяет пользователям иметь кошельки, содержащие только UTXO определенного цвета и отправлять их так же, как обычные биткоины, просматривая блокчейн для определения цвета UTXO, который они получают. -- **Метакоины**. Идея метакоина заключается в том, чтобы иметь протокол, который использует транзакции биткоина для хранения транзакций метакоина, но имеет другую функцию смены состояния, `APPLY'`. Так как протокол метакоина не может предотвратить появления недействительных транзакций метакоинов в блокчейне биткоина, добавляется правило, согласно которому если `APPLY'(S,TX)` возвращает ошибку, то протокол по умолчанию имеет значение `APPLY'(S,TX) = S`. Это обеспечивает простой механизм для создания произвольного протокола криптовалюты, потенциально с расширенными функциями, которые нельзя реализовать внутри самого биткоина, но с очень низкой стоимостью разработки, поскольку сложности майнинга и сетевого взаимодействия уже реализованы в протоколе биткоина. Метакоины использовались для реализации некоторых классов финансовых контрактов, регистрации имени и децентрализованной биржи. +- **Namecoin**. Созданный в 2010 году, [Namecoin](https://namecoin.org/) лучше всего можно описать как децентрализованную базу данных для регистрации имен. В децентрализованных протоколах, таких как Tor, Bitcoin и BitMessage, должен быть способ идентификации аккаунтов, чтобы другие люди могли с ними взаимодействовать, но во всех существующих решениях единственным доступным идентификатором является псевдослучайный хэш, например `1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy`. В идеале хотелось бы иметь возможность иметь аккаунт с именем, например george. Однако, проблема в том, что если один человек может создать аккаунт с именем george, затем кто-то другой также может зарегистрироваться как george и выдать себя за него. Единственное решение — парадигма первой регистрации, когда второй пользователь, регистрирующий аккаунт, терпит неудачу, — проблема, идеально подходящая для консенсуса протокола биткоина. Namecoin — старейшая и наиболее успешная реализация системы регистрации имен, использующая такую идею. +- **Цветные монеты**. Цель [цветных монет](https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit) — служить протоколом, позволяющим людям создавать свои собственные цифровые валюты или, в важном тривиальном случае валюты с одной единицей, цифровые токены в блокчейне Bitcoin. В протоколе цветных монет кто-то выпускает новую валюту, публично назначая цвет определенному UTXO биткоина, и протокол рекурсивно определяет цвет других UTXO таким образом, чтобы он совпадал с цветом вводов, на которые была потрачена создавшая их транзакция (в случае вводов смешанного цвета применяются специальные правила). Это позволяет пользователям иметь кошельки, содержащие только UTXO определенного цвета и отправлять их так же, как обычные биткоины, просматривая блокчейн для определения цвета UTXO, который они получают. +- **Метамонеты**. Идея метамонеты заключается в том, чтобы иметь протокол, который работает поверх Bitcoin, используя транзакции Bitcoin для хранения транзакций метамонет, но имея другую функцию смены состояний, `APPLY'`. Поскольку протокол метамонеты не может предотвратить появление недействительных транзакций метамонет в блокчейне Bitcoin, добавлено правило, согласно которому, если `APPLY'(S,TX)` возвращает ошибку, протокол по умолчанию принимает значение `APPLY'(S,TX) = S`. Это обеспечивает простой механизм для создания произвольного протокола криптовалюты, потенциально с расширенными функциями, которые нельзя реализовать внутри самого биткоина, но с очень низкой стоимостью разработки, поскольку сложности майнинга и сетевого взаимодействия уже реализованы в протоколе биткоина. Метакоины использовались для реализации некоторых классов финансовых контрактов, регистрации имени и децентрализованной биржи. Таким образом, в целом существуют два подхода к созданию протокола консенсуса: создание независимой сети и создание протокола на базе биткоина. Первый подход, хотя и достаточно успешный в случае таких приложений, как Namecoin, трудно реализуем; каждая отдельная реализация требует запуска отдельного блокчейна, а также создания и тестирования всего необходимого кода смены состояния и кода сетевого взаимодействия. Кроме того, мы прогнозируем, что набор приложений для децентрализованных технологий, основывающихся на консенсусе, будут соответствовать закону степенного распределения, где в свою очередь подавляющее большинство приложений будут слишком маленькими, чтобы оправдать их собственный блокчейн, и мы отмечаем, что существуют большое количество классов децентрализованных приложений, а конкретнее, децентрализованных автономных организаций, которые нуждаются во взаимодействии друг с другом. С другой же стороны, подход, основанный на биткоине, имеет недостаток, так как он не наследует упрощенные функции проверки платежей биткоина. SPV подходит для биткоина, поскольку он может использовать глубину блокчейна в качестве индикатора действительности; в какой-то момент, когда предшественники транзакции уходят достаточно далеко в прошлое, можно смело сказать, что они являются частью состояния. С другой стороны, мета-протоколы, основанные на блокчейне, не могут заставить блокчейн не исключать транзакции, которые не являются действительными в контексте своих собственных протоколов. Следовательно, внедрение полностью безопасного мета-протокола SPV потребует полного сканирования с самого начала блокчейна биткоина, дабы определить действительность определенных транзакций. В настоящее же время, все легкие реализации основанных на биткоине мета-протоколов полагаются на доверенный сервер для предоставления данных, бесспорно весьма неоптимальный результат, особенно учитывая то, что одной из первостепенных предназначений криптовалюты является устранение потребности в доверии. -### Сценарии {#scripting} +### Написание скриптов {#scripting} Даже без каких-либо расширений протокол биткоина обеспечивает простую версию концепции смарт-контрактов. UTXO в биткоине может принадлежать не только открытому ключу, но и более сложному сценарию, выраженному на простом языке программирования на основе стека. В этой модели транзакция, которая тратит данный UTXO, должна предоставлять удовлетворяющие сценарию данные. Действительно, даже самый базовый механизм владения открытым ключом реализован через сценарий: он принимает основанную на эллиптической кривой подпись в качестве входных данных, проверяет ее на соответствие транзакции и адресу, которому принадлежит UTXO и, в случае успешной проверки, возвращает 1, а в противном случае 0. Существуют и другие, более сложные сценарии для различных дополнительных вариантов использования. Например, можно создать сценарий, для проверки которого требуются подписи двух из трех заданных закрытых ключей (мультиподпись), настройка, полезная для корпоративных счетов, безопасных сберегательных счетов и некоторых ситуаций с условным депонированием. Сценарии также можно использовать для выплаты вознаграждений за решения вычислительных задач, и можно даже составить сценарий, который говорит что-то вроде «этот UTXO биткоина будет ваш, если вы сможете предоставить SPV-доказательство того, что вы отправили мне транзакцию с такой-то суммой Dogecoin», по сути, позволяя осуществлять децентрализованный обмен криптовалютами. Однако язык сценариев, реализованный в Биткоин, имеет несколько важных ограничений: -- **Отсутствие полноты по Тьюрингу**. То есть, хотя существует огромная подгруппа вычислений, которые поддерживает язык сценариев биткоина, он поддерживает далеко не все. Основная категория, которая отсутствует, — это циклы. Это делается, чтобы избежать бесконечных циклов во время проверки транзакций; теоретически, это препятствие преодолимо для программистов сценариев, поскольку любой цикл можна смоделировать простым повторением базового кода с помощью оператора if, но это приводит к сценариям, которые очень неэффективны с точки зрения использования пространства. Например, реализация альтернативного алгоритма для основанной на эллиптической кривой подписи потребует около 256 повторяющихся этапов умножения, отдельно включенных в код. -- **Ценностная слепота**. В сценариях UTXO нет метода для обеспечения точного контроля над суммой, которую можно вывести. Например, одним из эффективных вариантов использования контракта оракула может быть контракт хеджирования, где А и В вкладывают BTC на сумму 1000 долларов и после 30 дней сценарий отправляет BTC на сумму 1000 долларов A, а остальное — B. Для этого потребовался бы оракул, определяющий стоимость 1 BTC в USD, но даже в этом случае это значительное улучшение с точки зрения доверия и требований инфраструктуры по сравнению с централизованными решениями, доступными сейчас. Однако, так как UTXO работает по принципу «все или ничего», единственный метод достижения этого — с помощью очень неэффективного костыля — наличия большого количества UTXO разных номиналов (например, один UTXO со значением 2k для каждого k до 30) и оракула, выбирающего, какой UTXO отправить A, а какой — B. -- **Отсутствие состояния**. UTXO может быть как израсходованным, так и неизрасходованным; нет возможности для использования многошаговых контрактов или сценариев, которые сохраняют любое другое внутреннее состояние, кроме этого. Это затрудняет создание многоэтапных опционных контрактов, предложений децентрализованного обмена или двухэтапных протоколов криптографических обязательств (необходимых для безопасных вычислительных наград). Это также значит, что UTXO можно использовать только для создания простых, одноразовых контрактов, а не более сложных контрактов с сохранением состояния, таких как децентрализованные организации, и затрудняет реализацию метапротоколов. Бинарное состояние в сочетании с ценностной слепотой также означает, что невозможно применять лимиты на вывод. -- **Блокчейн-слепота**. UTXO слеп к данным блокчейна, таким как nonce, временная метка и хеш предыдущего блока. Это серьезно ограничивает применение в азартных играх и некоторых других категориях, лишая язык сценариев потенциально ценного источника случайности. +- **Отсутствие полноты по Тьюрингу**. То есть, хотя язык скриптов Bitcoin поддерживает большое подмножество вычислений, он поддерживает далеко не все. Основная категория, которая отсутствует, — это циклы. Это делается, чтобы избежать бесконечных циклов во время проверки транзакций; теоретически, это препятствие преодолимо для программистов сценариев, поскольку любой цикл можна смоделировать простым повторением базового кода с помощью оператора if, но это приводит к сценариям, которые очень неэффективны с точки зрения использования пространства. Например, реализация альтернативного алгоритма для основанной на эллиптической кривой подписи потребует около 256 повторяющихся этапов умножения, отдельно включенных в код. +- **Слепота к значению**. Скрипт UTXO не может обеспечить точный контроль над суммой, которую можно вывести. Например, одним из эффективных вариантов использования контракта оракула может быть контракт хеджирования, где А и В вкладывают BTC на сумму 1000 долларов и после 30 дней сценарий отправляет BTC на сумму 1000 долларов A, а остальное — B. Для этого потребовался бы оракул, определяющий стоимость 1 BTC в USD, но даже в этом случае это значительное улучшение с точки зрения доверия и требований инфраструктуры по сравнению с централизованными решениями, доступными сейчас. Однако, поскольку UTXO работают по принципу «все или ничего», единственный способ достичь этого — это очень неэффективный обходной путь, заключающийся в наличии множества UTXO разного номинала (например, один UTXO достоинством 2k для каждого k до 30) и наличии оракула, который выбирает, какой UTXO отправить A, а какой — B. +- **Отсутствие состояния**. UTXO может быть либо потрачен, либо не потрачен; нет возможности для многоэтапных контрактов или скриптов, которые хранят какое-либо другое внутреннее состояние, кроме этого. Это затрудняет создание многоэтапных опционных контрактов, предложений децентрализованного обмена или двухэтапных протоколов криптографических обязательств (необходимых для безопасных вычислительных наград). Это также значит, что UTXO можно использовать только для создания простых, одноразовых контрактов, а не более сложных контрактов с сохранением состояния, таких как децентрализованные организации, и затрудняет реализацию метапротоколов. Бинарное состояние в сочетании с ценностной слепотой также означает, что невозможно применять лимиты на вывод. +- **Слепота к блокчейну**. UTXO «слепы» к данным блокчейна, таким как nonce, временная метка и хэш предыдущего блока. Это серьезно ограничивает применение в азартных играх и некоторых других категориях, лишая язык сценариев потенциально ценного источника случайности. Таким образом, мы видим три подхода к созданию современных приложений на основе криптовалюты: создание нового блокчейна, использование сценариев на основе биткоина и создание метапротокола на основе биткоина. Создание нового блокчейна дает неограниченную свободу в создании набора функций, но в убыток времени на разработку, безопасности и усилий по запуску. Использование сценариев легко реализовать и стандартизировать, но их возможности весьма ограничены, а метапротоколы, хотя и просты, страдают от недостатков масштабируемости. С помощью Ethereum мы намерены создать альтернативную платформу, которая упростит разработку, а также укрепит легкий клиент, в то же время позволяя приложениям совместно использовать экономическую среду и безопасность блокчейна. @@ -145,16 +148,16 @@ _Справа: любая попытка изменить любую часть Целью Ethereum является создание альтернативного протокола для создания децентрализованных приложений, обеспечивающего другой набор компромиссов, которые, по нашему мнению, будут очень полезны для большого класса децентрализованных приложений, с особым акцентом на ситуациях, когда важны быстрое время разработки, безопасность для небольших и редко используемых приложений и способность различных приложений очень эффективно взаимодействовать. Ethereum делает это, создавая то, что по сути является высшим абстрактным базовым уровнем: блокчейн со встроенным языком программирования, полным по Тьюрингу, позволяющим любому человеку писать умные контракты и децентрализованные приложения, где они могут создавать свои собственные произвольные правила владения, форматы транзакций и функции смены состояния. Простую версию Namecoin можно написать с помощью двух строк кода, а другие протоколы, такие как валюты и системы репутации, можно создать с помощью двадцати или менее строк. Смарт-контракты — криптографические «коробки», содержащие ценность и разблокирующие ее только при соблюдении определенных условий, — также можно создавать на основе платформы, что предоставляет гораздо больше возможностей, чем сценарии биткоина, благодаря полноте по Тьюрингу,, осведомленности о ценности, осведомленности о блокчейне и состоянии. -### Счета Ethereum {#ethereum-accounts} +### Аккаунты Ethereum {#ethereum-accounts} В Ethereum состояние состоит из объектов, называемых «счетами», каждый счет имеет 20-байтный адрес и смены состояний представляют собой прямые переводы сумм и информации между счетами. Счет в Ethereum содержит четыре поля: -- Счетчик **nonce**, используемый для того, чтобы каждую транзакцию можно было обработать только один раз -- Текущий баланс **эфира на счете** -- **Код контракта** счета, если есть -- **Хранилище** счета (по умолчанию пусто) +- **Nonce** — счетчик, используемый для того, чтобы каждая транзакция могла быть обработана только один раз +- Текущий **баланс ether** на аккаунте +- **Код контракта** аккаунта, если он есть +- **Хранилище** аккаунта (по умолчанию пустое) -Эфир является основным внутренним криптотопливом Ethereum и используется для оплаты комиссий за транзакции. В общем, есть два типа счетов: **внешние счета**, контролируемые закрытыми ключами, и **счета контрактов**, контролируемые кодом их контракта. Внешний счет не имеет кода, с него можно отправлять сообщения, создавая и подписывая транзакцию; в счете контракта при получении сообщения его код активируется, что позволяет ему читать и записывать во внутреннюю память и отправлять другие сообщения или создавать контракты в ответ. +Эфир является основным внутренним криптотопливом Ethereum и используется для оплаты комиссий за транзакции. В целом, существует два типа аккаунтов: **внешние аккаунты**, контролируемые приватными ключами, и **аккаунты контрактов**, контролируемые их кодом контракта. Внешний счет не имеет кода, с него можно отправлять сообщения, создавая и подписывая транзакцию; в счете контракта при получении сообщения его код активируется, что позволяет ему читать и записывать во внутреннюю память и отправлять другие сообщения или создавать контракты в ответ. Обратите внимание, что контракты в Ethereum не должны выглядеть как что-то, что должно быть «выполнено» или «соблюдено»; скорее они более похожи на «автономных агентов», которые живут внутри среды исполнения Ethereum, всегда выполняя определенный фрагмент кода, в ответ на сообщение или транзакцию, и имеют прямой контроль над принадлежащим им балансом эфира и их собственным хранилищем ключей и значений для отслеживания постоянных переменных. @@ -166,12 +169,12 @@ _Справа: любая попытка изменить любую часть - Подпись, идентифицирующая отправителя - Количество эфира, который нужно перевести получателю - Необязательное поле данных -- Значение `STARTGAS`, представляющее максимальное количество разрешенных вычислительных шагов для выполнения транзакции -- Значение `GASPRICE`, представляющее собой комиссию, которую отправитель платит за вычислительный шаг +- Значение `STARTGAS`, представляющее максимальное количество вычислительных шагов, которые может выполнить транзакция +- Значение `GASPRICE`, представляющее комиссию, которую отправитель платит за каждый вычислительный шаг Первые три поля стандартны в любой криптовалюте. Поле данных не имеет функции по умолчанию, но виртуальная машина имеет код операции, используя который контракт может иметь доступ к данным; например, когда контракт функционирует как служба регистрации доменов в блокчейне, то он, возможно, пожелает интерпретировать полученные им данные, как содержащие два поля, первое поле — домен для регистрации и второе поле — IP-адрес для его регистрации. Контракт будет считывать эти значения из данных сообщения и соответствующим образом размещать их в хранилище. -Поля `STARTGAS` и `GASPRICE` имеют решающее значение в Ethereum для предотвращения отказа в обслуживании. Чтобы предотвратить случайные или враждебные бесконечные циклы или другие вычислительные потери в коде, каждая транзакция должна устанавливать ограничение на количество вычислительных шагов выполнения кода, которое она может использовать. Фундаментальная единица вычисления — это газ; обычно, вычислительный шаг стоит 1 газ, но некоторые операции стоят большее количество газа, потому что они являются вычислительно более дорогими или увеличивают объем данных, которые необходимо хранить как часть состояния. Также существует комиссия в размере 5 единиц газа за каждый байт данных транзакции. Цель системы комиссий — требовать злоумышленников платить пропорционально за каждый ресурс, который они потребляют, включая вычисления, пропускную способность и хранение; следовательно, любая транзакция, которая ведет к потреблению сетью большего количества этих ресурсов, должна иметь примерно пропорциональную приросту плату за газ. +Поля `STARTGAS` и `GASPRICE` имеют решающее значение для модели защиты от DDoS-атак в Ethereum. Чтобы предотвратить случайные или враждебные бесконечные циклы или другие вычислительные потери в коде, каждая транзакция должна устанавливать ограничение на количество вычислительных шагов выполнения кода, которое она может использовать. Фундаментальная единица вычисления — это газ; обычно, вычислительный шаг стоит 1 газ, но некоторые операции стоят большее количество газа, потому что они являются вычислительно более дорогими или увеличивают объем данных, которые необходимо хранить как часть состояния. Также существует комиссия в размере 5 единиц газа за каждый байт данных транзакции. Цель системы комиссий — требовать злоумышленников платить пропорционально за каждый ресурс, который они потребляют, включая вычисления, пропускную способность и хранение; следовательно, любая транзакция, которая ведет к потреблению сетью большего количества этих ресурсов, должна иметь примерно пропорциональную приросту плату за газ. ### Сообщения {#messages} @@ -183,19 +186,19 @@ _Справа: любая попытка изменить любую часть - Необязательное поле данных - Значение `STARTGAS` -По существу, сообщение похоже на транзакцию, за исключением того, что оно создается контрактом, а не внешним субъектом. Сообщение создается, когда контракт, выполняющий в настоящее время код, выполняет код операции `CALL`, которая создает и выполняет сообщение. Как и транзакция, сообщение ведет к счету получателя, запустившего этот код. Таким образом, контракты могут взаимодействовать с другими контрактами, точно таким же образом, как это могут делать внешние субъекты. +По существу, сообщение похоже на транзакцию, за исключением того, что оно создается контрактом, а не внешним субъектом. Сообщение создается, когда контракт, выполняющий код, исполняет опкод `CALL`, который создает и исполняет сообщение. Как и транзакция, сообщение ведет к счету получателя, запустившего этот код. Таким образом, контракты могут взаимодействовать с другими контрактами, точно таким же образом, как это могут делать внешние субъекты. Заметьте, что расход газа, назначенный транзакцией или контрактом, используется к общему количеству потребляемого газа по этой транзакции и всем вспомогательным исполнениям. Например, внешний субъект А посылает транзакции субъекту B с 1000 газа, и B потребляет 600 газа перед отправкой сообщения С, а внутреннее выполнение C потребляет 300 газа перед возвратом, то B может потратить ещё 100 газа, прежде чем он закончится. -### Функция смены состояния Ethereum {#ethereum-state-transition-function} +### Функция смены состояния в Ethereum {#ethereum-state-transition-function} -![Смена состояния эфира](./ether-state-transition.png) +![Смена состояния Ether](./ether-state-transition.png) -Функцию смены состояния Ethereum `APPLY(S,TX) -> S'` можно определить следующим образом: +Функцию смены состояния в Ethereum `APPLY(S,TX) -> S'` можно определить следующим образом: -1. Проверяет, хорошо ли сформирована транзакция (т. е. имеет нужное количество значений), действительна ли подпись, и совпадает ли nonce с nonce в счете отправителя. В противном случае возвращает ошибку. -2. Вычисляет комиссию за транзакцию как `STARTGAS * GASPRICE` и определяет адрес отправителя исходя из подписи. Взимает комиссию с баланса счета отправителя и увеличивает nonce отправителя. Если баланса недостаточно, возвращает ошибку. -3. Инициализирует `GAS = STARTGAS` и отнимает определенное количество газа за байт для оплаты байтов транзакции. +1. Проверьте, правильно ли сформирована транзакция (т. е. имеет ли она правильное количество значений), действительна ли подпись и соответствует ли nonce значению nonce в аккаунте отправителя. В противном случае возвращает ошибку. +2. Рассчитайте комиссию за транзакцию как `STARTGAS * GASPRICE` и определите адрес отправки по подписи. Взимает комиссию с баланса счета отправителя и увеличивает nonce отправителя. Если баланса недостаточно, возвращает ошибку. +3. Инициализируйте `GAS = STARTGAS` и вычтите определенное количество газа за каждый байт для оплаты байтов в транзакции. 4. Переводит сумму транзакции со счета отправителя на счет получателя. Если счет получателя еще не существует, то создает его. Если счет получателя является контрактом, запускает код контракта либо до его завершения, либо до тех пор, пока не закончится газ. 5. Если перевод суммы не удался, из-за того, что отправитель не имеет достаточной суммы денег, или при выполнении кода закончился газ, то отменяются все изменения состояния, кроме оплаты комиссии и ее зачисления на счет майнера. 6. Иначе возвращает отправителю весь оставшийся газ и отправляет комиссию за израсходованный газ майнеру. @@ -207,51 +210,51 @@ if !self.storage[calldataload(0)]: self.storage[calldataload(0)] = calldataload(32) ``` -Обратите внимание, что код контракта на самом деле написан на низкоуровневом языке EVM; для ясности этот пример написан на языке Serpent, одном из наших высокоуровневых языков, который можно скомпилировать в код EVM. Предположим, что хранилище контракта изначально пустое, и транзакция отправляется с 10 эфирами, 2000 газа, с ценой GASPRICE в 0,001 эфира и 64 байтами данных, с байтами 0-31, представляющими число `2` и байтами 32-63, представляющими строку `CHARLIE`. Процесс функции смены состояния в этом случае выглядит следующим образом: +Обратите внимание, что код контракта на самом деле написан на низкоуровневом языке EVM; для ясности этот пример написан на языке Serpent, одном из наших высокоуровневых языков, который можно скомпилировать в код EVM. Предположим, что хранилище контракта изначально пусто, и отправляется транзакция со значением 10 ether, 2000 газа, ценой газа 0,001 ether и 64 байтами данных, где байты с 0 по 31 представляют число `2`, а байты с 32 по 63 — строку `CHARLIE`. Процесс функции смены состояния в этом случае выглядит следующим образом: 1. Проверьте, что транзакция действительна и правильно оформлена. 2. Проверяет, что отправитель транзакции имеет как минимум 2000 \* 0.001 = 2 эфира. Если это так, то вычитает 2 эфира со счета отправителя. 3. Инициализирует газ = 2000; предположим, что длина транзакции составляет 170 байт, а плата за байт составляет 5, вычитает 850, чтобы осталось 1150 газа. 4. Вычитает еще 10 эфиров со счета отправителя и добавляет их на счет контракта. -5. Запускает код. В этом случае он простой: проверяет, используется ли хранилище контракта по индексу `2`, замечает, что это не так, и устанавливает в значение хранилища по индексу `2` значение `CHARLIE`. Предположим, что для этого требуется 187 газа, так что оставшееся количество газа 1150 – 187 = 963 -6. Переводит 963 * 0,001 = 0,963 эфира обратно на счет отправителя и возвращает результирующее состояние. +5. Запускает код. В этом случае все просто: он проверяет, используется ли хранилище контракта по индексу `2`, замечает, что нет, и устанавливает в хранилище по индексу `2` значение `CHARLIE`. Предположим, что для этого требуется 187 газа, так что оставшееся количество газа 1150 – 187 = 963 +6. Переводит 963 \* 0,001 = 0,963 эфира обратно на счет отправителя и возвращает результирующее состояние. -Если бы в приемном конце транзакции не было бы контракта, то общая сумма комиссии просто равнялась бы предоставленной сумме `GASPRICE`, умноженной на величину транзакции в байтах, и данные, отправляемые вместе с транзакцией, не имели бы значения. +Если бы на принимающей стороне транзакции не было контракта, то общая комиссия за транзакцию была бы просто равна предоставленному `GASPRICE`, умноженному на длину транзакции в байтах, а данные, отправленные вместе с транзакцией, были бы неактуальны. -Обратите внимание, что сообщения работают эквивалентно транзакциям с точки зрения отмен: если для исполнения сообщения недостаточно газа, тогда исполнение этого сообщения и все другие исполнения, вызванные этим исполнением, отменяются, но родительским исполнениям не нужно отменяться. Это означает, что контракту безопасно вызывать другой контракт, так как если А вызывает B, используя G газа, то исполнение A гарантированно теряет максимум G газа. Наконец, обратите внимание, что существует операционный код `CREATE`, который создает контракт; его механика выполнения, как правило, похожа на `CALL`, за исключением того, что результат выполнения определяет код созданного нового контракта. +Обратите внимание, что сообщения работают эквивалентно транзакциям с точки зрения отмен: если для исполнения сообщения недостаточно газа, тогда исполнение этого сообщения и все другие исполнения, вызванные этим исполнением, отменяются, но родительским исполнениям не нужно отменяться. Это означает, что контракту безопасно вызывать другой контракт, так как если А вызывает B, используя G газа, то исполнение A гарантированно теряет максимум G газа. Наконец, обратите внимание, что существует опкод `CREATE`, который создает контракт; его механика выполнения в целом похожа на `CALL`, за исключением того, что результат выполнения определяет код вновь созданного контракта. -### Исполнение кода {#code-execution} +### Выполнение кода {#code-execution} -Код в контрактах Ethereum написан на низкоуровневом языке байт-кода на основе стека, называемом «кодом виртуальной машины Ethereum» или «кодом EVM». Код состоит из набора байтов, где каждый байт представляет операцию. В общем случае, выполнение кода — это бесконечный цикл, состоящий из многократного выполнения операции на текущем счетчике программы (который начинается с нуля) и затем увеличения счетчика программы на единицу, пока не будет достигнут конец кода, обнаружена ошибка или инструкция `STOP` или `RETURN`. Операции имеют доступ к трем типам пространства для хранения данных: +Код в контрактах Ethereum написан на низкоуровневом языке байт-кода на основе стека, называемом «кодом виртуальной машины Ethereum» или «кодом EVM». Код состоит из набора байтов, где каждый байт представляет операцию. В общем, выполнение кода — это бесконечный цикл, который состоит из многократного выполнения операции на текущем счетчике программы (который начинается с нуля), а затем увеличения счетчика программы на единицу, пока не будет достигнут конец кода или не будет обнаружена ошибка или инструкция `STOP` или `RETURN`. Операции имеют доступ к трем типам пространства для хранения данных: -- **Стек**, контейнер, работающий по принципу «последним пришел — первым ушел», с операциями push и pop -- **Память**, бесконечно расширяемый массив байтов -- Долгосрочное **хранилище** контракта, что хранит ключи и их значения. В отличие от стека и памяти, которые сбрасываются после завершения вычислений, хранилище сохраняется на длительное время. +- **Стек** — контейнер, работающий по принципу «последним пришел — первым ушел» (LIFO), в который можно помещать и из которого можно извлекать значения +- **Память** — бесконечно расширяемый массив байтов +- Долгосрочное **хранилище** контракта, хранилище типа «ключ/значение». В отличие от стека и памяти, которые сбрасываются после завершения вычислений, хранилище сохраняется на длительное время. Код также может получить доступ к значению, отправителю и данным входящего сообщения, а также к данным заголовка блока, код также может возвращать массив байтов данных. -Формальная модель исполнения кода EVM удивительно проста. Во время работы виртуальной машины Ethereum ее полное вычислительное состояние может быть определено кортежом `(block_state, transaction, message, code, memory, stack, pc, gas)`, где `block_state` является глобальным состоянием, содержащим все счета, балансы и хранилище. В начале каждого раунда исполнения текущая инструкция определяется путем взятия `pc` байта из `code` (или 0 если `pc >= len(code)`), и каждая инструкция имеет свое собственное определение в плане того, как она влияет на кортеж. Например, `ADD` извлекает два элемента из стека и помещает их сумму, уменьшает `gas` на 1 и увеличивает `pc` на 1, а `SSTORE` извлекает два верхних элемента из стека и вставляет второй элемент в хранилище контракта по индексу, указанному первым элементом. Хотя существует множество способов оптимизировать выполнение виртуальной машины Ethereum с помощью JIT-компиляции, базовый вариант Ethereum можно реализовать с помощью нескольких сотен строк кода. +Формальная модель исполнения кода EVM удивительно проста. Пока работает виртуальная машина Ethereum, ее полное вычислительное состояние можно определить кортежем `(block_state, transaction, message, code, memory, stack, pc, gas)`, где `block_state` — это глобальное состояние, содержащее все аккаунты, включая балансы и хранилище. В начале каждого раунда выполнения текущая инструкция находится путем взятия `pc`-го байта `кода` (или 0, если `pc >= len(code)`), и каждая инструкция имеет свое собственное определение с точки зрения того, как она влияет на кортеж. Например, `ADD` извлекает два элемента из стека и помещает их сумму, уменьшает `газ` на 1 и увеличивает `pc` на 1, а `SSTORE` извлекает два верхних элемента из стека и вставляет второй элемент в хранилище контракта по индексу, указанному первым элементом. Хотя существует множество способов оптимизировать выполнение виртуальной машины Ethereum с помощью JIT-компиляции, базовый вариант Ethereum можно реализовать с помощью нескольких сотен строк кода. ### Блокчейн и майнинг {#blockchain-and-mining} -![Диаграмма применения блоков в Ethereum](./ethereum-apply-block-diagram.png) +![Диаграмма применения блока Ethereum](./ethereum-apply-block-diagram.png) Блокчейн Ethereum во многом похож на блокчейн биткоина, хотя и имеет некоторые отличия. Главное отличие между Ethereum и биткоином в отношении архитектуры блокчейна в том, что, в отличие от биткоина, блоки Ethereum содержат копию как списка транзакций, так и копию самого последнего состояния. Помимо этого, два других значения, номер блока и сложность его получения, также хранятся в блоке. Основной алгоритм валидации блока в Ethereum следующий: 1. Проверить, существует ли и действителен ли предыдущий указанный блок. 2. Проверить, что временная метка блока больше, чем у предыдущего указанного блока и прошло менее чем 15 минут с момента создания предыдущего блока 3. Проверить, что номер блока, сложность, корень транзакции, корень брата родителя и лимит на газ (различные низкоуровневые специфические для Ethereum концепции) являются действительными. -4. Проверьте, что proof-of-work на блоке является действительным. -5. Пусть `S[0]` будет состоянием в конце предыдущего блока. -6. Пусть `TX` будет списком транзакций блока с `n` транзакциями. Для всех `i` в `0...n-1` задать `S[i+1] = APPLY(S[i], TX[i])`. Если какие-либо приложения возвращают ошибку или если общий объем газа, потребленного в блоке до этой точки, превышает `GASLIMIT`, вернуть ошибку. -7. Пусть `S_FINAL` будет `S[n]`, но с добавлением вознаграждения за блок, выплачиваемого майнеру. -8. Проверить, равен ли корень дерева Меркла состояния `S_FINAL` корню конечного состояния, указанному в заголовке блока. Если это так, то блок действителен, в противном же случае — нет. +4. Проверить, что доказательство выполнения работы над блоком является действительным. +5. Пусть `S[0]` — это состояние в конце предыдущего блока. +6. Пусть `TX` будет списком транзакций блока, с `n` транзакциями. Для всех `i` в `0...n-1`, установить `S[i+1] = APPLY(S[i],TX[i])`. Если какое-либо приложение возвращает ошибку или если общий объем газа, потребленного в блоке до этого момента, превышает `GASLIMIT`, вернуть ошибку. +7. Пусть `S_FINAL` будет `S[n]`, но с добавлением награды за блок, выплачиваемой майнеру. +8. Проверьте, равен ли корневой хэш дерева Меркла состояния `S_FINAL` корневому хэшу конечного состояния, указанному в заголовке блока. Если это так, то блок действителен, в противном же случае — нет. -На первый взгляд такой подход может показаться крайне неэффективным, потому что он должен хранить все состояние с каждым блоком, но в действительности эффективность должна быть сравнима с эффективностью биткоина. Причина в том, что состояние хранится в структуре дерева, и после каждого блока нужно изменить лишь небольшую часть дерева. Таким образом, в общем случае, между двумя соседними блоками подавляющее большинство дерева должно быть одинаковым, и поэтому данные могут быть сохранены один раз и ссылаться дважды с помощью указателей (т. е. хешей поддеревьев). Для этого используется специальный вид дерева, известный как дерево Патриции, включающий модификацию концепции дерева Меркла, которая позволяет эффективно вставлять и удалять узлы, а не только изменять их. Кроме того, поскольку вся информация о состоянии является частью последнего блока, нет необходимости хранить всю историю блокчейна — это стратегия могла обеспечить 5-20-кратную экономию пространства, если бы ее можно было применить к биткоину. +На первый взгляд такой подход может показаться крайне неэффективным, потому что он должен хранить все состояние с каждым блоком, но в действительности эффективность должна быть сравнима с эффективностью биткоина. Причина в том, что состояние хранится в структуре дерева, и после каждого блока нужно изменить лишь небольшую часть дерева. Таким образом, в целом, между двумя соседними блоками подавляющее большинство дерева должно быть одинаковым, и поэтому данные могут храниться один раз и ссылаться на них дважды с помощью указателей (т. е. хэшей поддеревьев). Для этого используется специальный вид дерева, известный как дерево Патриции, включающий модификацию концепции дерева Меркла, которая позволяет эффективно вставлять и удалять узлы, а не только изменять их. Кроме того, поскольку вся информация о состоянии является частью последнего блока, нет необходимости хранить всю историю блокчейна — это стратегия могла обеспечить 5-20-кратную экономию пространства, если бы ее можно было применить к биткоину. -Часто задается вопрос «где» выполняется код контракта, в терминах физического оборудования. Ответ прост: процесс выполнения кода контракта является частью определения функции смены состояния, которая является частью алгоритма проверки блоков. Таким образом, если транзакция добавляется в блок `B`, то выполнение кода, сгенерированного этой транзакцией, будет выполняться всеми узлами, сейчас и в будущем, которые загружают и проверяют блок `B`. +Часто задается вопрос «где» выполняется код контракта, в терминах физического оборудования. Ответ прост: процесс выполнения кода контракта является частью определения функции смены состояния, которая является частью алгоритма проверки блока, поэтому, если транзакция добавляется в блок `B`, выполнение кода, вызванное этой транзакцией, будет исполнено всеми узлами (сейчас и в будущем), которые загружают и проверяют блок `B`. -## Применения {#applications} +## Приложения {#applications} В общем есть три типа применений на основе Ethereum. Первая категория — это финансовое применение, предоставление пользователям более эффективных способов управления и заключения контрактов с использованием своих денег. Сюда входят субвалюты, производные финансовые инструменты, контракты хеджирования, сберегательные кошельки, завещания и, в конечном итоге, даже некоторые виды полноценных трудовых договоров. Вторая категория — это полуфинансовое применение, в котором задействованы деньги, но в остальном есть и серьезная неденежная сторона; прекрасным примером являются самореализующиеся вознаграждения за решение вычислительных задач. И наконец, есть абсолютно нефинансовое применение, такое как онлайн-голосование и децентрализованное управление. @@ -270,9 +273,9 @@ def send(to, value): Это, по сути, буквальное воплощение функции смены состояния «банковской системы», описанной выше в этом документе. Нужно добавить несколько дополнительных строк кода, чтобы обеспечить начальный этап распределения денежных единиц в первую очередь и несколько других пограничных случаев, и в идеале добавить бы функцию, позволяющую другим контрактам запрашивать баланс адреса. Это всё, что требуется! Теоретически, основанные на Ethereum системы токенов, действующие в качестве субвалюты, могут потенциально включать еще одну важную функцию, которая отсутствует у метавалют на блокчейне Bitcoin: возможность платить за транзакцию непосредственно в этой валюте. Это будет осуществляться так, что в контракте будет поддерживаться баланс ether, с помощью которого контракт будет отправлять ether, нужный для оплаты комиссии, отправителю. Контракт пополнял бы этот баланс, собирая внутренние валютные единицы, которые он берет в качестве комиссии, и перепродавая их на постоянном аукционе. Таким образом, пользователям нужно будет «активировать» свои счета с эфиром, но как только эфир будет там, он будет повторно использоваться, потому что контракт будет возмещать его каждый раз. -### Производные финансовые инструменты и валюты со стабильной стоимостью {#financial-derivatives-and-stable-value-currencies} +### Финансовые деривативы и валюты со стабильной стоимостью {#financial-derivatives-and-stable-value-currencies} -Финансовые деривативы — наиболее распространенное применение смарт-контракта, и одно из самых простых для реализации в коде. Главная проблема при реализации финансовых контрактов заключается в том, что большинству из них требуется связь с внешним трекером цены; например, очень желаемое приложение — это смарт-контракт, который хеджирует волатильность эфира (или другой криптовалюты) по отношению к доллару США, но для этого контракт должен знать, какова стоимость ETH/USD. Самый простой способ решить это — с помощью контракта котировок, поддерживаемого определенной стороной (например, NASDAQ), разработанного таким образом, чтобы эта сторона имела возможность обновлять контракт по мере необходимости и предоставляла интерфейс, позволяющий другим контрактам отправлять сообщение этому контракту и получать ответ, который предоставляет цену. +Финансовые деривативы — наиболее распространенное применение смарт-контракта, и одно из самых простых для реализации в коде. Главная проблема при реализации финансовых контрактов заключается в том, что большинству из них требуется связь с внешним трекером цены; например, очень желаемое приложение — это смарт-контракт, который хеджирует волатильность эфира (или другой криптовалюты) по отношению к доллару США, но для этого контракт должен знать, какова стоимость ETH/USD. Самый простой способ сделать это — с помощью контракта «канала данных», поддерживаемого определенной стороной (например, NASDAQ), который разработан таким образом, чтобы эта сторона могла обновлять контракт по мере необходимости, и который предоставляет интерфейс, позволяющий другим контрактам отправлять сообщение этому контракту и получать ответ с ценой. С учетом этого важного нюанса контракт хеджирования будет выглядеть следующим образом: @@ -281,13 +284,13 @@ def send(to, value): 3. Записать в хранилище стоимость 1000 эфиров в долларах США, рассчитанную путем запроса к контракту котировок, скажем, это $x. 4. Через 30 дней позволить A или B повторно активировать контракт, чтобы отправить эфир на сумму $x (рассчитанную путем повторного запроса к контракту котировок для получения новой цены) стороне A, а остальное — стороне B. -Такой контракт имел бы значительный потенциал в криптокоммерции. Одна из основных проблем, связанных с криптовалютой, заключается в ее волатильности; хотя многим пользователям и продавцам может потребоваться безопасность и удобство, которые дает работа с криптографическими активами, они могут не захотеть столкнуться с такой перспективой, как потеря 23% стоимости своих средств за один день. До сих пор наиболее часто предлагаемым решением были активы, обеспеченные эмитентом; идея состоит в том, что эмитент создает субвалюту, в которой он имеет право выпускать и отзывать единицы этой самой валюты, и предоставлять их любому, кто предоставит им (вживую) одну единицу указанного базового актива (например, золото или доллар США). Затем эмитент обещает предоставить одну единицу базового актива любому, кто отправит обратно одну единицу криптоактива. Этот механизм позволяет преобразовать любой некриптографический актив в криптографический при условии, что эмитенту можно доверять. +Такой контракт имел бы значительный потенциал в криптокоммерции. Одна из основных проблем, связанных с криптовалютой, заключается в ее волатильности; хотя многим пользователям и продавцам может потребоваться безопасность и удобство, которые дает работа с криптографическими активами, они могут не захотеть столкнуться с такой перспективой, как потеря 23% стоимости своих средств за один день. До сих пор наиболее часто предлагаемым решением были активы, обеспеченные эмитентом; идея заключается в том, что эмитент создает субвалюту, в которой он имеет право выпускать и отзывать единицы, и предоставляет одну единицу валюты любому, кто предоставит ему (офлайн) одну единицу указанного базового актива (например, золото, доллары США). Затем эмитент обещает предоставить одну единицу базового актива любому, кто отправит обратно одну единицу криптоактива. Этот механизм позволяет преобразовать любой некриптографический актив в криптографический при условии, что эмитенту можно доверять. -Однако на практике эмитенты не всегда заслуживают доверия, а в некоторых случаях банковская инфраструктура слишком слабая или слишком враждебная к существованию таких услуг. Альтернативой являются финансовые деривативы. Здесь, вместо одного эмитента, предоставляющего средства для обеспечения актива, играет роль децентрализованный рынок спекулянтов, делающих ставки на то, что цена указанного криптографического актива (например, ETH) будет расти. По сравнению с эмитентами, спекулянты не имеют возможности не выполнить свою часть сделки, потому что контракт хеджирования держит их средства в условном депонировании. Обратите внимание, что этот подход не является полностью децентрализованным, потому что для предоставления тикера цены по-прежнему необходим надежный источник, хотя, возможно, даже это все же значительное улучшение с точки зрения снижения требований к инфраструктуре (в отличие от случая с эмитентом, проблема передачи ценового потока данных не требует лицензий и, вероятно, может быть квалифицирована как свободная речь) и снижает вероятность мошенничества. +Однако на практике эмитенты не всегда заслуживают доверия, а в некоторых случаях банковская инфраструктура слишком слабая или слишком враждебная к существованию таких услуг. Альтернативой являются финансовые деривативы. Здесь роль обеспечения актива выполняет не один эмитент, предоставляющий средства, а децентрализованный рынок спекулянтов, делающих ставки на то, что цена криптографического эталонного актива (например, ETH) вырастет. По сравнению с эмитентами, спекулянты не имеют возможности не выполнить свою часть сделки, потому что контракт хеджирования держит их средства в условном депонировании. Обратите внимание, что этот подход не является полностью децентрализованным, потому что для предоставления тикера цены по-прежнему необходим надежный источник, хотя, возможно, даже это все же значительное улучшение с точки зрения снижения требований к инфраструктуре (в отличие от случая с эмитентом, проблема передачи ценового потока данных не требует лицензий и, вероятно, может быть квалифицирована как свободная речь) и снижает вероятность мошенничества. ### Системы идентификации и репутации {#identity-and-reputation-systems} -Самая первая альтернативная криптовалюта из всех, [Namecoin](http://namecoin.org/), попыталась использовать биткоин-подобный блокчейн для обеспечения системы регистрации имен, в которой пользователи могут зарегистрировать свои имена в общедоступной базе данных вместе с другими данными. В основном упоминается вариант использования системы [DNS](https://wikipedia.org/wiki/Domain_Name_System), сопоставляющей доменные имена, такие как bitcoin.org (или, в случае с Namecoin, bitcoin.bit) с IP-адресом. Другие варианты использования включают аутентификацию по электронной почте и потенциально более продвинутые системы репутации. Вот простой контракт для обеспечения системы регистрации имен, подобной Namecoin, на Ethereum: +Самая ранняя альтернативная криптовалюта из всех, [Namecoin](http://namecoin.org/), пыталась использовать блокчейн, подобный Bitcoin, для создания системы регистрации имен, где пользователи могут регистрировать свои имена в общедоступной базе данных вместе с другими данными. Основной упоминаемый вариант использования — это система [DNS](https://wikipedia.org/wiki/Domain_Name_System), сопоставляющая доменные имена, такие как «bitcoin.org» (или, в случае Namecoin, «bitcoin.bit»), с IP-адресом. Другие варианты использования включают аутентификацию по электронной почте и потенциально более продвинутые системы репутации. Вот простой контракт для обеспечения системы регистрации имен, подобной Namecoin, на Ethereum: ```py def register(name, value): @@ -295,13 +298,13 @@ def register(name, value): self.storage[name] = value ``` -Контракт очень прост; по сути, это просто база данных внутри сети Ethereum, в которую можно добавлять, но нельзя изменять или удалять элементы. Любой может зарегистрировать определенное имя, и эта регистрация останется навсегда. Более сложный контракт регистрации имен также будет иметь функцию условия, позволяя другим контрактам запрашивать ее, а также механизм для владельца (т. е. первого зарегистрировавшего) имени, чтобы он мог изменять данные или передавать права собственности. Можно даже добавить функции репутации и функциональность web-of-trust. +Контракт очень прост; по сути, это просто база данных внутри сети Ethereum, в которую можно добавлять, но нельзя изменять или удалять элементы. Любой может зарегистрировать определенное имя, и эта регистрация останется навсегда. Более сложный контракт для регистрации имен также будет иметь «оговорку о функции», позволяющую другим контрактам запрашивать его, а также механизм, с помощью которого «владелец» (т. е. первый регистрант) имени может изменять данные или передавать право собственности. Можно даже добавить функции репутации и функциональность web-of-trust. -### Децентрализованное хранилище файлов {#decentralized-file-storage} +### Децентрализованное хранение файлов {#decentralized-file-storage} За последние несколько лет появилось несколько популярных онлайн-стартапов по хранению файлов, наиболее известным из которых является Dropbox, стремящихся дать пользователям возможность загружать резервную копию своего жесткого диска и получить услугу хранения резервной копии, а так же предоставить пользователю доступ к ней в обмен на ежемесячную оплату. Однако на данный момент рынок файловых хранилищ относительно неэффективен; беглый взгляд на различные существующие решения показывает, что, особенно на уровне «зловещей долины» в 20-200 ГБ, на который не действуют ни бесплатные квоты, ни скидки для компаний, ежемесячные цены за хранение файлов таковы, что вы платите больше, чем стоимость целого жесткого диска в месяц. Контракты Ethereum могут позволить разработать децентрализованную экосистему хранения файлов, где отдельные пользователи могут зарабатывать небольшие суммы денег, сдавая в аренду собственные жесткие диски и неиспользуемое пространство, что может быть использовано для дальнейшего снижения стоимости хранения файлов. -Ключевой элемент такого устройства — это то, что мы назвали «децентрализованный контракт Dropbox». Этот контракт работает следующим образом. Сначала разделяет нужные данные на блоки, зашифровав каждый блок для конфиденциальности, и строит из них дерево Меркла. Затем он создает контракт с правилом, что каждые N блоков, этот контракт будет выбирать случайный индекс в дереве Меркла (используя хеш предыдущего блока, доступный из кода контракта, как источник случайности), и давать Х эфира первому объекту, который предоставит транзакцию с упрощенной проверкой платежа — как доказательство владения блоком на том конкретном индексе в дереве. Когда пользователь хочет перезагрузить свой файл, он может использовать протокол канала микроплатежа (например, платить 1 сабо за 32 килобайта) для восстановления файла; наиболее эффективным с точки зрения платы подходом является то, что плательщик не публикует транзакцию до конца, вместо этого заменяя транзакцию чуть более выгодной с тем же nonce после каждых 32 килобайт. +Ключевой элемент такого устройства — это то, что мы назвали «децентрализованный контракт Dropbox». Этот контракт работает следующим образом. Сначала разделяет нужные данные на блоки, зашифровав каждый блок для конфиденциальности, и строит из них дерево Меркла. Затем он создает контракт с правилом, что каждые N блоков, этот контракт будет выбирать случайный индекс в дереве Меркла (используя хеш предыдущего блока, доступный из кода контракта, как источник случайности), и давать Х эфира первому объекту, который предоставит транзакцию с упрощенной проверкой платежа — как доказательство владения блоком на том конкретном индексе в дереве. Когда пользователь хочет повторно загрузить свой файл, он может использовать протокол канала микроплатежей (например, платить 1 сабо за 32 килобайта) для восстановления файла; наиболее эффективный с точки зрения комиссии подход для плательщика заключается в том, чтобы не публиковать транзакцию до самого конца, а вместо этого заменять ее на немного более выгодную с тем же nonce после каждых 32 килобайт. Важной особенностью протокола является то, что, хотя может показаться, что приходится доверять множеству случайных узлов, риск можно снизить практически до нуля, разделив файл на множество частей путем разделения секрета между несколькими узлами и следя за контрактами и хранением частей. Если контракт продолжает выплачивать деньги, это служит криптографическим доказательством того, что кто-то все еще хранит файл. @@ -311,15 +314,15 @@ def register(name, value): Общие наброски о том, как запрограммировать DAO, следующие. Самая простая конструкция — это просто кусок самоизменяющегося кода, который меняется, если две трети членов согласны с изменением. Хотя код теоретически неизменяемый, это можно легко обойти и иметь де-факто его изменяемость, имея фрагменты кода в отдельных контрактах, и имея адрес для вызова определенного контракта, хранящийся в модифицируемом хранилище. При простой реализации такого контракта DAO, будет три типа транзакций, отличающихся по данным, предоставленным в транзакции: -- `[0,i,K,V]` для регистрации предложения с индексом `i` для изменения адреса в хранилище с индексом `K` на значение `V` +- `[0,i,K,V]` для регистрации предложения с индексом `i` об изменении адреса в хранилище с индексом `K` на значение `V` - `[1,i]` для регистрации голоса в пользу предложения `i` -- `[2,i]` для завершения предложения `i` при получении достаточного количества голосов +- `[2,i]` для завершения предложения `i`, если было подано достаточное количество голосов -Контракт будет содержать положения для каждого из этих типов. Он будет вести учет всех общедоступных изменений хранилища, вместе со списком тех, кто за них голосовал. Он также будет иметь список всех членов. Когда любое изменение хранилища получает голоса двух третей членов, завершающая транзакция может осуществить это изменение. Более сложная конструкция также имела бы встроенную возможность голосования для таких функций, как отправка транзакции, добавление членов и удаление членов, и могла бы даже обеспечить делегирование голосов в стиле [Ликвидной Демократии](https://wikipedia.org/wiki/Liquid_democracy) (т.е. когда любой может назначить кого-то голосовать вместо него, и назначение является транзитивным, поэтому если А назначает В, а В назначает С, тогда С определяет голос А). Такой дизайн позволил бы DAO органично расти как децентрализованное сообщество, позволяя людям в конечном итоге делегировать задачу проверки членов специалистам, хотя в отличие от «текущей системы» специалисты могут легко появляться и исчезать со временем, по мере того, как отдельные члены сообщества меняют свои позиции. +Контракт будет содержать положения для каждого из этих типов. Он будет вести учет всех общедоступных изменений хранилища, вместе со списком тех, кто за них голосовал. Он также будет иметь список всех членов. Когда любое изменение хранилища получает голоса двух третей членов, завершающая транзакция может осуществить это изменение. Более сложная структура также будет иметь встроенную возможность голосования для таких функций, как отправка транзакций, добавление и удаление участников, и может даже предусматривать делегирование голосов в стиле [ликвидной демократии](https://wikipedia.org/wiki/Liquid_democracy) (т. е. любой может поручить кому-то голосовать за себя, и это поручение транзитивно, поэтому если A поручает B, а B поручает C, то C определяет голос A). Такой дизайн позволил бы DAO органично расти как децентрализованное сообщество, позволяя людям в конечном итоге делегировать задачу проверки членов специалистам, хотя в отличие от «текущей системы» специалисты могут легко появляться и исчезать со временем, по мере того, как отдельные члены сообщества меняют свои позиции. Альтернативная модель — это децентрализованная корпорация, где любой аккаунт может иметь ноль или более акций, и держатели двух третьих акций должны принимать решение. Полная конструкция будет включать функциональность управления активами, возможность делать предложение о покупке или продаже акций и возможность принимать предложения (предпочтительно с механизмом сопоставления ордеров внутри контракта). Также будет существовать делегация в стиле ликвидной демократии, обобщая концепцию «совета директоров». -### Дополнительные применения {#further-applications} +### Дальнейшие применения {#further-applications} **1. Сберегательные кошельки**. Предположим, Алиса хочет сохранить свои средства в безопасности, но беспокоится о том, что она потеряет или кто-то взломает её приватный ключ. Она ставит эфир в контракт, заключенный с Бобом, банком, следующим образом: @@ -331,23 +334,23 @@ def register(name, value): **2. Страхование урожая**. Можно легко сделать финансовый производный контракт с использованием источника данных о погоде вместо цены индекса. Если фермер из Айовы покупает производный инструмент, который приносит доход, исходя из количества осадков в Айове, то при засухе фермер автоматически получит деньги, а если дождей достаточно, фермер будет счастлив, потому что его урожай будет хорошо расти. Это может быть распространено на страхование от стихийных бедствий в целом. -**3. Децентрализованный канал данных**. Для финансовых контрактов на разницу цены, на самом деле можно децентрализовать канал данных через протокол под названием [SchellingCoin](https://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/). SchellingCoin в основном работает следующим образом: все N сторон вносят в систему значение заданного элемента данных (например, цены ETH/USD), значения сортируются, и каждый между 25-м и 75-м процентилем получает один токен в качестве награды. У каждого есть стимул дать ответ, который дадут все остальные, и единственное значение, с которым может реально согласиться большое количество игроков, — это правда. Это создает децентрализованный протокол, который теоретически может предоставить сколько угодно значений, включая цену ETH/USD, температуру в Берлине или даже результат конкретного сложного вычисления. +**3. Децентрализованный канал данных**. Для финансовых контрактов на разницу цен, возможно, удастся децентрализовать канал данных с помощью протокола под названием «[SchellingCoin](https://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/)». SchellingCoin в основном работает следующим образом: N сторон вводят в систему значение заданного показателя (например, цену ETH/USD), значения сортируются, и все, кто находится между 25-м и 75-м процентилями, получают один токен в качестве награды. У каждого есть стимул дать ответ, который дадут все остальные, и единственное значение, с которым может реально согласиться большое количество игроков, — это правда. Это создает децентрализованный протокол, который теоретически может предоставить сколько угодно значений, включая цену ETH/USD, температуру в Берлине или даже результат конкретного сложного вычисления. -**4. Умное депонирование с мультиподписью**. Биткоин допускает существование контрактов с мультиподписью для транзакций, где, к примеру, трех из пяти ключей достаточно для траты средств. У Ethereum же возможностей детализировать больше: например, четыре из пяти могут потратить все, три из пяти могут тратить до 10% в день, а два из пяти могут потратить до 0,5% в день. Кроме того, мультиводпись в Ethereum асинхронна — две стороны могут зарегистрировать свои подписи на блокчейне в разное время, а последняя подпись автоматически отправит транзакцию. +**4.** Умное депонирование с мультиподписью\*\*. Биткоин допускает существование контрактов с мультиподписью для транзакций, где, к примеру, трех из пяти ключей достаточно для траты средств. У Ethereum же возможностей детализировать больше: например, четыре из пяти могут потратить все, три из пяти могут тратить до 10% в день, а два из пяти могут потратить до 0,5% в день. Кроме того, мультиводпись в Ethereum асинхронна — две стороны могут зарегистрировать свои подписи на блокчейне в разное время, а последняя подпись автоматически отправит транзакцию. -**5. Облачные вычисления**. Технология EVM также может быть использована для создания проверяемой вычислительной среды, позволяющей пользователям просить других выполнять вычисления, а затем при необходимости запрашивать доказательства того, что вычисления на определенных случайно выбранных контрольных точках были выполнены правильно. Это позволяет создать рынок облачных вычислений, в котором может участвовать любой пользователь со своим настольным компьютером, ноутбуком или специализированным сервером, а выборочная проверка вместе с залоговыми депозитами может использоваться для обеспечения надежности системы (т. е. узлы не могут обманывать с выгодой для себя). Хотя такая система может подойти не для всех задач; например, задачи, требующие высокого уровня межпроцессного взаимодействия не легко реализовать на большом облаке узлов. Однако другие задачи параллелизировать гораздо проще; такие проекты, как SETI@home, folding@home и генетические алгоритмы, могут быть легко реализованы на основе такой платформы. +**5.** Облачные вычисления\*\*. Технология EVM также может быть использована для создания проверяемой вычислительной среды, позволяющей пользователям просить других выполнять вычисления, а затем при необходимости запрашивать доказательства того, что вычисления на определенных случайно выбранных контрольных точках были выполнены правильно. Это позволяет создать рынок облачных вычислений, на котором любой пользователь может участвовать со своего настольного компьютера, ноутбука или специализированного сервера, а выборочные проверки вместе с залоговыми депозитами могут использоваться для обеспечения надежности системы (т. е. узлы не могут обманывать с выгодой для себя). Хотя такая система может подойти не для всех задач; например, задачи, требующие высокого уровня межпроцессного взаимодействия не легко реализовать на большом облаке узлов. Однако другие задачи параллелизировать гораздо проще; такие проекты, как SETI@home, folding@home и генетические алгоритмы, могут быть легко реализованы на основе такой платформы. -**6. Одноранговые азартные игры**. Любое количество одноранговых игровых протоколов, таких как [Cyberdice](http://www.cl.cam.ac.uk/~fms27/papers/2008-StajanoCla-cyberdice.pdf) Фрэнка Стахано и Ричарда Клейтона, может быть реализовано на блокчейне Ethereum. Самый простой игровой протокол на самом деле представляет собой просто контракт на разницу в следующем хеше блока, и на этом принципе можно создавать более продвинутые протоколы, например игровые сервисы с почти нулевой комиссией и без возможности обмана. +**6.** Одноранговые азартные игры\*\*. Любое количество одноранговых протоколов для азартных игр, таких как [Cyberdice](http://www.cl.cam.ac.uk/~fms27/papers/2008-StajanoCla-cyberdice.pdf) Фрэнка Стаджано и Ричарда Клейтона, может быть реализовано в блокчейне Ethereum. Самый простой игровой протокол на самом деле представляет собой просто контракт на разницу в следующем хеше блока, и на этом принципе можно создавать более продвинутые протоколы, например игровые сервисы с почти нулевой комиссией и без возможности обмана. -**7. Рынки прогнозов**. При наличии оракула или SchellingCoin рынки прогнозов также легко реализовать, и рынки прогнозов вместе с SchellingCoin могут оказаться первым массовым применением [футархии](http://hanson.gmu.edu/futarchy.html) в качестве протокола управления для децентрализованных организаций. +**7.** Рынки прогнозов\*\*. При наличии оракула или SchellingCoin, рынки предсказаний также легко реализовать, а рынки предсказаний вместе с SchellingCoin могут оказаться первым массовым применением [футархии](https://mason.gmu.edu/~rhanson/futarchy.html) в качестве протокола управления для децентрализованных организаций. -**8. Ончейн децентрализованные торговые площадки**, использующие в качестве основы систему идентификации и репутации. +**8.** Ончейн-децентрализованные торговые площадки\*\*, использующие систему идентификации и репутации в качестве основы. -## Прочие вопросы и проблемы {#miscellanea-and-concerns} +## Разное и проблемы {#miscellanea-and-concerns} ### Модифицированная реализация GHOST {#modified-ghost-implementation} -Протокол Greedy Heaviest Observed Subtree (GHOST) — это инновация, впервые введенная Йонатаном Сомполински и Авивом Зохаром в [Декабре 2013](https://eprint.iacr.org/2013/881.pdf). Мотивация, стоящая за GHOST: блокчейны с быстрым временем подтверждения в данный момент недостаточно безопасны из-за высокой скорости устаревания: поскольку распространение блоков по сети занимает определенное время, если майнер A добудет блок, а затем майнер B добудет другой блок до того, как блок майнера A распространится на B, блок майнера B будет бесполезным и не повысит безопасность сети. Кроме того, существует проблема централизации: если майнер A — это майнинговый пул, суммарная мощность которого составляет 30% мощности всей сети, а у майнера B эта цифра составляет 10%, в 70% случаев A может создать устаревший блок (поскольку в остальные 30% случаев A создавал последний блок и, таким образом, немедленно получал данные о майнинге), а B будет подвержен этому риску в 90% случаев. Таким образом, если интервал между блоками достаточно короток для того, чтобы скорость устаревания была высокой, A будет существенно эффективнее просто в силу своего размера. Обе этих проблемы приводят к тому, что блокчейны, которые производят блоки слишком быстро, влекут за этим ситуацию, когда один майнинг-пул набирает достаточное количество мощности в сети, чтобы де-факто контролировать процесс майнинга. +Протокол «Greedy Heaviest Observed Subtree» (GHOST) — это инновация, впервые представленная Йонатаном Сомполинским и Авивом Зоаром в [декабре 2013 года](https://eprint.iacr.org/2013/881.pdf). Мотивация, стоящая за GHOST: блокчейны с быстрым временем подтверждения в данный момент недостаточно безопасны из-за высокой скорости устаревания: поскольку распространение блоков по сети занимает определенное время, если майнер A добудет блок, а затем майнер B добудет другой блок до того, как блок майнера A распространится на B, блок майнера B будет бесполезным и не повысит безопасность сети. Кроме того, существует проблема централизации: если майнер A — это майнинговый пул, суммарная мощность которого составляет 30% мощности всей сети, а у майнера B эта цифра составляет 10%, в 70% случаев A может создать устаревший блок (поскольку в остальные 30% случаев A создавал последний блок и, таким образом, немедленно получал данные о майнинге), а B будет подвержен этому риску в 90% случаев. Таким образом, если интервал между блоками достаточно короток для того, чтобы скорость устаревания была высокой, A будет существенно эффективнее просто в силу своего размера. Обе этих проблемы приводят к тому, что блокчейны, которые производят блоки слишком быстро, влекут за этим ситуацию, когда один майнинг-пул набирает достаточное количество мощности в сети, чтобы де-факто контролировать процесс майнинга. Как описано Сомполински и Зохар, GHOST решает первую проблему потери безопасности сети, включив устаревшие блоки в расчет того, какая цепь является самой длинной; то есть не только родительские и дальнейшие предки блока, но также и устаревшие потомки предка блока (на жаргоне Ethereum — «дяди») добавляются к вычислению того, какой блок имеет наибольшее общее доказательство работы, поддерживающее этот блок. Чтобы решить вторую проблему предвзятости централизации, мы выходим за рамки протокола, описанного Сомполински и Зохар, а также предоставляем вознаграждение за блок устаревшим блокам: устаревший блок получает 87,5% своего базового вознаграждения, а племянник, включающий устаревший блок, получает оставшуюся часть — 12,5%. Однако комиссия за транзакции не начисляется «дядям». @@ -355,7 +358,7 @@ Ethereum реализует упрощенную версию GHOST, котор - Блок должен указывать на родительский, и он должен указывать на 0 или более дядей - Дядя, включенный в блок В, должен иметь следующие свойства: - - Он должен быть прямым дочерним предком B k-го поколения, где `2 <= k <= 7`. + - Он должен быть прямым потомком предка B k-го поколения, где `2 <= k <= 7`. - Он не может быть предком B - У него должен быть допустимый блочный заголовок, но дядя необязательно должен быть ранее проверенным или даже действительным блоком - Дядя должен отличаться от всех дядей, включенных в предыдущие блоки, и всех других дядей, включенных в этот же блок (т.е. без двойного включения) @@ -369,12 +372,12 @@ Ethereum реализует упрощенную версию GHOST, котор Однако этот недостаток рыночного механизма при некоторых допущениях магически исчезает. Аргумент следующий. Предположим, что: -1. Транзакция состоит из `k` операций и предлагает комиссию в `kR` майнеру, который включит её в блокчейн, где `R` задаётся отправителем; и `k` и `R` (приблизительно) известны майнеру заранее. -2. Себестоимость проведения операций каждого узла равна `C` (у каждого узла одинаковая эффективность) -3. Всего в сети `N` узлов с идентичной мощностью (`1/N` общей суммы) +1. Транзакция приводит к `k` операциям, предлагая награду `kR` любому майнеру, который ее включит, где `R` устанавливается отправителем, а `k` и `R` (примерно) видны майнеру заранее. +2. Операция имеет стоимость обработки `C` для любого узла (т. е. все узлы имеют одинаковую эффективность) +3. Существует `N` майнинговых узлов, каждый из которых имеет одинаковую вычислительную мощность (т. е. `1/N` от общей) 4. Нет полных узлов, не занятых в майнинге. -Майнер захочет включить в блок только те транзакции, полученная комиссия с которых превысит себестоимость операций. Следовательно, ожидаемый доход равен `kR/N`, поскольку майнер имеет `1/N` шанс нахождения следующего блока, а себестоимость майнинга — `kC`. Таким образом, майнеры будут включать только те транзакции в блок, где `kR/N > kC`, or `R > NC`. Заметим, что `R` — устанавливаемая отправителем комиссия за одну операцию, и потому R — нижняя граница «пользы» от этой транзакции для отправителя. При этом `NC` — себестоимость проведения операции для всей сети. Исходя из этого, майнерам выгодно включать в блок только такие транзакции, польза от которых больше, чем себестоимость её проведения. +Майнер захочет включить в блок только те транзакции, полученная комиссия с которых превысит себестоимость операций. Таким образом, ожидаемая награда составляет `kR/N`, поскольку у майнера есть шанс `1/N` обработать следующий блок, а стоимость обработки для майнера составляет просто `kC`. Следовательно, майнеры будут включать транзакции, где `kR/N > kC` или `R > NC`. Обратите внимание, что `R` — это комиссия за операцию, предоставляемая отправителем, и, таким образом, является нижней границей выгоды, которую отправитель получает от транзакции, а `NC` — это общая стоимость обработки операции для всей сети. Исходя из этого, майнерам выгодно включать в блок только такие транзакции, польза от которых больше, чем себестоимость её проведения. Однако в реальности существует несколько важных отклонений от этих предположений: @@ -383,29 +386,36 @@ Ethereum реализует упрощенную версию GHOST, котор 3. Распределение мощности майнинга на практике может оказаться крайне неравномерным. 4. Спекулянты, политические враги и сумасшедшие, чья функция включает в себя нанесение вреда сети, действительно существуют, и они могут продуманно создавать контракты, в которых стоимость намного ниже стоимости, уплачиваемой другими проверяющими узлами. -(1) обеспечивает тенденцию для майнера включать меньше транзакций (2) увеличивает `NC`; следовательно, эти два эффекта по крайней мере частично покрывают друг друга.[Как?](https://web.archive.org/web/20250427212319/https://github.com/ethereum/wiki/issues/447#issuecomment-316972260#issuecomment-316972260) (3) и (4) являются основными проблемами; чтобы решить их, мы просто устанавливаем плавающий ограничение: ни один блок не может иметь больше операций, чем `BLK_LIMIT_FACTOR` умноженный на долгосрочную экспоненциальную скользящую среднюю. В частности: +(1) создает тенденцию для майнера включать меньше транзакций, и +(2) увеличивает `NC`; следовательно, эти два эффекта по крайней мере частично +нейтрализуют друг друга +.[Как?](https://web.archive.org/web/20250427212319/https://github.com/ethereum/wiki/issues/447#issuecomment-316972260#issuecomment-316972260) +(3) и (4) являются основной проблемой; чтобы решить их, мы просто вводим +плавающее ограничение: ни один блок не может иметь больше операций, чем +`BLK_LIMIT_FACTOR`, умноженный на долгосрочную экспоненциальную скользящую среднюю. +В частности: ```js blk.oplimit = floor((blk.parent.oplimit \* (EMAFACTOR - 1) + floor(parent.opcount \* BLK\_LIMIT\_FACTOR)) / EMA\_FACTOR) ``` -`BLK_LIMIT_FACTOR` и `EMA_FACTOR` — это константы, которые на данный момент будут установлены на значения 65536 и 1,5, но, вероятнее всего, будут изменены после дальнейшего анализа. +`BLK_LIMIT_FACTOR` и `EMA_FACTOR` — это константы, которые на данный момент будут установлены в 65536 и 1,5, но, скорее всего, будут изменены после дальнейшего анализа. Есть еще один фактор, препятствующий созданию больших блоков в Bitcoin: бóльшие блоки будут дольше распространяться, и, следовательно, у них выше вероятность устареть. В Ethereum распространение блоков с высоким потреблением газа также может занять больше времени, поскольку они физически больше и им требуется больше времени на обработку проверки переходов состояний транзакций. Этот сдерживающий фактор задержки имеет важное значение в Bitcoin, но в Ethereum он менее важен из-за протокола GHOST; следовательно, опора на регулируемые ограничения блоков обеспечивает более стабильную основу. -### Вычисление и полнота по Тьюрингу {#computation-and-turing-completeness} +### Вычисления и полнота по Тьюрингу {#computation-and-turing-completeness} -Важно отметить, что виртуальная машина Ethereum является полной по Тьюрингу; это означает, что код EVM может закодировать любое вычисление, которое можно предположительно выполнить, включая бесконечные циклы. Код EVM позволяет делать циклы двумя способами. Первый — это инструкция `JUMP`, которая позволяет программе вернуться к предыдущему месту в коде, и инструкция `JUMPI` для выполнения условных переходов, позволяющая использовать такие инструкции, как `while x < 27: x = x * 2`. Второй — контракты могут вызывать другие контракты, потенциально позволяя зацикливаться через рекурсию. Это естественным образом приводит к проблеме: могут ли злоумышленники по сути отключить майнеров и полные узлы, заставив их войти в бесконечный цикл? Проблема возникает из-за проблемы в компьютерной науке, известной как проблема остановки: в общем случае невозможно сказать, остановится ли данная программа когда-либо. +Важно отметить, что виртуальная машина Ethereum является полной по Тьюрингу; это означает, что код EVM может закодировать любое вычисление, которое можно предположительно выполнить, включая бесконечные циклы. Код EVM позволяет делать циклы двумя способами. Во-первых, есть инструкция `JUMP`, которая позволяет программе вернуться к предыдущему месту в коде, и инструкция `JUMPI` для условного перехода, что позволяет использовать операторы типа `while x < 27: x = x * 2`. Второй — контракты могут вызывать другие контракты, потенциально позволяя зацикливаться через рекурсию. Это естественным образом приводит к проблеме: могут ли злоумышленники по сути отключить майнеров и полные узлы, заставив их войти в бесконечный цикл? Проблема возникает из-за проблемы в компьютерной науке, известной как проблема остановки: в общем случае невозможно сказать, остановится ли данная программа когда-либо. Как описано в разделе перехода состояния, наше решение работает, требуя от транзакции установить максимальное количество вычислительных шагов, которые ей разрешено выполнить, и если выполнение требует больше шагов, вычисления отменяются, но комиссия все равно платится. Сообщения работают также. Чтобы показать мотив, стоящий за нашим решением, рассмотрим следующие примеры: - Злоумышленник создает контракт, запускающий бесконечный цикл, а затем отправляет майнеру транзакцию, активирующую этот цикл. Майнер обработает транзакцию, запустив бесконечный цикл, и будет ждать, пока в ней не закончится газ. Даже если при выполнении заканчивается газ и оно останавливается на полпути, транзакция все еще действительна, и майнер по-прежнему возьмет у атакующего комиссию за каждый вычислительный шаг. -- Злоумышленник создает очень длинный бесконечный цикл с целью заставить майнера продолжать вычисления в течение столь длительного времени, что к моменту завершения вычислений будет создано еще несколько блоков, и майнер не сможет включить транзакцию в блок, чтобы получить комиссию. Однако злоумышленнику потребуется предоставить значение для `STARTGAS`, ограничивающее количество вычислительных шагов, которые можно выполнить, поэтому майнер будет заранее знать, что вычисление займет чрезмерно большое количество шагов. -- Злоумышленник видит контракт с кодом в некоторой форме, например `send(A,contract.storage[A]); contract.storage[A] = 0`, и отправляет транзакцию с достаточным количеством газа только для выполнения первого шага, но не второго (т. е. сделать вывод, но не дать балансу уменьшиться). Автору контракта не нужно беспокоиться о защите от подобных атак, поскольку если выполнение транзакции останавливается на полпути, то изменения отменяются. +- Злоумышленник создает очень длинный бесконечный цикл с целью заставить майнера продолжать вычисления в течение столь длительного времени, что к моменту завершения вычислений будет создано еще несколько блоков, и майнер не сможет включить транзакцию в блок, чтобы получить комиссию. Однако злоумышленник должен будет отправить значение `STARTGAS`, ограничивающее количество вычислительных шагов, которые может выполнить исполнение, поэтому майнер будет заранее знать, что вычисление займет чрезмерно большое количество шагов. +- Злоумышленник видит контракт с кодом вида `send(A,contract.storage[A]); contract.storage[A] = 0` и отправляет транзакцию с количеством газа, достаточным для выполнения первого шага, но не второго (т. е. совершает вывод средств, но не позволяет балансу уменьшиться). Автору контракта не нужно беспокоиться о защите от подобных атак, поскольку если выполнение транзакции останавливается на полпути, то изменения отменяются. - Финансовый контракт работает используя медианное значения девяти собственных каналов данных с целью минимизации риска. Злоумышленник захватывает один из каналов данных, который разработан с возможностью изменения с помощью механизма вызова с переменным адресом, описанного в разделе о DAO, и преобразует его в запуск бесконечного цикла, тем самым пытаясь заставить любые попытки получить средства из финансового контракта исчерпывать газ. Однако финансовый контракт может установить лимит газа в сообщении, чтобы избежать этой проблемы. -Альтернативой полноте по Тьюрингу является неполнота по Тьюрингу, в которой `JUMP` и `JUMPI` не существуют, и только одна копия каждого контракта может существовать в стеке вызовов в любой момент времени. В этой системе описанная выше система комиссий и неопределенности относительно эффективности нашего решения могут оказаться излишними, поскольку стоимость исполнения контракта будет ограничена его размером. Кроме того, неполнота по Тьюрингу не является таким уж большим ограничением: из всех примеров контрактов, которые мы задумали внутри, только один требовал цикла, и даже этот цикл можно было бы удалить, выполнив 26 повторений однострочного фрагмента кода. Учитывая серьезные последствия полноты по Тьюрингу и ограниченные преимущества, почему бы просто не использовать неполный по Тьюрингу язык? Однако на самом деле неполнота по Тьюрингу далеко не идеальное решение проблемы. Чтобы понять почему, рассмотрите следующие контракты: +Альтернативой полноте по Тьюрингу является неполнота по Тьюрингу, где `JUMP` и `JUMPI` не существуют, и в стеке вызовов в любой момент времени может находиться только одна копия каждого контракта. В этой системе описанная выше система комиссий и неопределенности относительно эффективности нашего решения могут оказаться излишними, поскольку стоимость исполнения контракта будет ограничена его размером. Кроме того, неполнота по Тьюрингу не является таким уж большим ограничением: из всех примеров контрактов, которые мы задумали внутри, только один требовал цикла, и даже этот цикл можно было бы удалить, выполнив 26 повторений однострочного фрагмента кода. Учитывая серьезные последствия полноты по Тьюрингу и ограниченные преимущества, почему бы просто не использовать неполный по Тьюрингу язык? Однако на самом деле неполнота по Тьюрингу далеко не идеальное решение проблемы. Чтобы понять почему, рассмотрите следующие контракты: ```sh C0: call(C1); call(C1); @@ -413,12 +423,12 @@ C1: call(C2); call(C2); C2: call(C3); call(C3); ... C49: call(C50); call(C50); -C50: (запустить один шаг программы и записать изменение в хранилище) +C50: (выполнить один шаг программы и записать изменение в хранилище) ``` Теперь отправьте транзакцию пользователю A. Таким образом, в 51 транзакции мы имеем контракт, который занимает 250 вычислительных шагов. Майнеры могли бы попытаться обнаружить такие логические бомбы заранее, сохраняя значение рядом с каждым контрактом, указывающее максимальное количество вычислительных шагов, которые он может выполнить, и вычисляя его для контрактов, рекурсивно вызывающих другие контракты, но это потребовало бы от майнеров запретить контракты, создающие другие контракты (поскольку создание и выполнение всех 26 контрактов выше можно было бы легко объединить в один контракт). Еще одной проблемой является то, что поле адреса у сообщения является переменной, поэтому в общем случае невозможно заранее сказать, какие другие контракты вызовет данный контракт. Таким образом, в целом, мы приходим к удивительному выводу: с полнотой по Тьюрингу справиться на удивление легко, а с отсутствием полноты по Тьюрингу справиться также на удивление сложно, если только не будут реализованы точно такие же элементы управления. Но в таком случае почему бы просто не позволить протоколу быть полным по Тьюрингу? -### Валюта и выпуск {#currency-and-issuance} +### Валюта и эмиссия {#currency-and-issuance} Сеть Ethereum включает собственную встроенную валюту, эфир, которая служит для двух целей: обеспечения первичного слоя ликвидности, чтобы позволить эффективно обмениваться различными видами цифровых активов, и, что более важно, создания механизма оплаты комиссии за транзакции. Для удобства и чтобы избежать споров в будущем (см. текущие дебаты mBTC/uBTC/сатоши в биткоине), номиналы будут предварительно помечены: @@ -441,7 +451,7 @@ C50: (запустить один шаг программы и записать | Денежные единицы | 1,198X | 1,458X | 2,498X | | Покупатели | 83,5% | 68,6% | 40,0% | | Резерв, потраченный до продажи | 8,26% | 6,79% | 3,96% | -| Резерв, использованный после продажи | 8.26% | 6.79% | 3.96% | +| Резерв, использованный после продажи | 8,26% | 6,79% | 3,96% | | Майнеры | 0% | 17,8% | 52,0% | #### Долгосрочный рост предложения (в процентах) @@ -450,17 +460,17 @@ C50: (запустить один шаг программы и записать _Несмотря на линейную эмиссию валюты, как и в случае с биткоином со временем темпы роста предложения стремятся к нулю._ -Двумя основными вариантами в вышеуказанной модели являются (1) существование и размер пула пожертвований, и (2) существование постоянно линейно растущего предложения, в отличие от ограниченного количества биткоина. Обоснование пула пожертвований следующее. Если бы пула пожертвований не существовало, а линейная эмиссия была бы уменьшена до 0,217x для обеспечения того же уровня инфляции, то общее количество эфира было бы на 16,5% меньше, а каждая единица была бы на 19,8% ценнее. Поэтому, для уравновешивания, на 19,8% больше эфира было бы отведено на продажу, чтобы каждая единица была снова так же ценной, как и раньше. Тогда у организации также будет в 1,198 больше BTC, которые можно считать разделенными на две части: исходные BTC и дополнительные 0,198x. Хоть эта ситуация и _полностью эквивалентна_ пожертвованию, но с одним важным отличием: организация хранит исключительно BTC и поэтому не заинтересована в поддержке стоимости единицы эфира. +Двумя основными вариантами в вышеуказанной модели являются (1) существование и размер пула пожертвований, и (2) существование постоянно линейно растущего предложения, в отличие от ограниченного количества биткоина. Обоснование пула пожертвований следующее. Если бы пула пожертвований не существовало, а линейная эмиссия была бы уменьшена до 0,217x для обеспечения того же уровня инфляции, то общее количество эфира было бы на 16,5% меньше, а каждая единица была бы на 19,8% ценнее. Поэтому, для уравновешивания, на 19,8% больше эфира было бы отведено на продажу, чтобы каждая единица была снова так же ценной, как и раньше. Тогда у организации также будет в 1,198 больше BTC, которые можно считать разделенными на две части: исходные BTC и дополнительные 0,198x. Следовательно, эта ситуация _в точности эквивалентна_ пожертвованию, но с одним важным отличием: организация владеет исключительно BTC и поэтому не заинтересована в поддержке стоимости единицы ether. -Модель постоянного линейного роста предложения снижает риск того, что некоторые считают чрезмерной сосредоточения богатства в биткоинах, и дает людям, живущим в настоящем и будущем, справедливый шанс приобретать денежные единицы, в то же время сохраняя сильный стимул получать и хранить эфир, поскольку темп роста предложения в процентном отношении по-прежнему стремится к нулю с течением времени. Мы также предполагаем, что поскольку монеты со временем всегда теряются из-за беспечности, смерти и т. д., а потерю монет можно смоделировать как процент от общего объема выпуска в год, то общий объем выпуска валюты в обращение в конечном итоге стабилизируется на уровне, равном годовому выпуску, деленному на уровень потерь (например, при уровне потерь 1%, как только объем выпуска достигнет 26 единиц, то 0,26 единиц будет добываться и 0,26 единиц теряться каждый год, что создаст равновесие). +Модель постоянного линейного роста предложения снижает риск того, что некоторые считают чрезмерной сосредоточения богатства в биткоинах, и дает людям, живущим в настоящем и будущем, справедливый шанс приобретать денежные единицы, в то же время сохраняя сильный стимул получать и хранить эфир, поскольку темп роста предложения в процентном отношении по-прежнему стремится к нулю с течением времени. Мы также предполагаем, что, поскольку монеты со временем всегда теряются из-за неосторожности, смерти и т. д., а потерю монет можно смоделировать как процент от общего предложения в год, общее количество валюты в обращении в конечном итоге стабилизируется на значении, равном годовой эмиссии, деленной на коэффициент потерь (например, при коэффициенте потерь 1%, как только предложение достигнет 26X, то 0,26X будет добываться и 0,26X теряться каждый год, создавая равновесие). -Обратите внимание, что в будущем Ethereum, скорее всего, в целях безопасности перейдет на модель доказательства владения, снизив требования к выпуску до уровня 0–0,05X в год. В случае, если организация Ethereum потеряет финансирование или по какой-либо другой причине исчезнет, ​​мы оставляем открытым «социальный контракт»: любой имеет право создать будущую версию-кандидата Ethereum, с одним только условием, что количество эфира должно быть не более `60102216 * (1,198 + 0,26 * n)`, где `n` — количество лет после первого блока. Создатели для оплаты разработки могут свободно продавать или иным образом передавать часть или всю разницу между максимально допустимым расширением предложения и расширением предложения, полученным при переходе к доказательству владения. Обновления-кандидаты, не соответствующие социальному контракту, могут быть законно ответвлены в совместимые версии. +Обратите внимание, что в будущем Ethereum, скорее всего, в целях безопасности перейдет на модель доказательства владения, снизив требования к выпуску до уровня 0–0,05X в год. В случае, если организация Ethereum потеряет финансирование или исчезнет по какой-либо другой причине, мы оставляем открытым «социальный контракт»: любой имеет право создать будущую версию-кандидата Ethereum с единственным условием, что количество ether должно быть не более `60102216 * (1,198 + 0,26 * n)`, где `n` — количество лет после генезис-блока. Создатели для оплаты разработки могут свободно продавать или иным образом передавать часть или всю разницу между максимально допустимым расширением предложения и расширением предложения, полученным при переходе к доказательству владения. Обновления-кандидаты, не соответствующие социальному контракту, могут быть законно ответвлены в совместимые версии. ### Централизация майнинга {#mining-centralization} Алгоритм майнинга Bitcoin работает за счет того, что майнеры вычисляют SHA256 на слегка измененных версиях заголовка блока миллионы раз снова и снова, пока в конечном итоге один узел не предложит версию, хеш которой меньше целевого (в настоящее время около 2192). Однако, алгоритм майнинга уязвим к двум формам централизации. Во-первых, в экосистеме майнинга стали доминировать ASIC (специализированные интегральные схемы) — компьютерные чипы, разработанные, и следовательно, в тысячи раз эффективнее для данной задачи, майнинга Bitcoin. Это означает, что майнинг биткоина больше не является высоко децентрализованным и эгалитарным занятием, а также требует миллионы долларов для эффективного участия в обеспечении безопасности сети. Во-вторых, большинство биткоин-майнеров на самом деле не выполняют проверку блоков локально; для предоставления заголовков блока они полагаются на централизованный майнинг-пул. Эта проблема, возможно, ещё хуже первой: на момент написания этой статьи три ведущих майнинг-пула косвенно контролируют примерно 50% мощности в сети биткоина. Хотя нужно учитывать тот факт, что майнеры могут переключиться на другие майнинг-пулы, если пул или коалиция пулов попытается провести атаку 51%. -Текущая цель Ethereum — использовать алгоритм майнинга, в котором майнерам необходимо извлекать случайные данные из состояния, вычислять некоторые случайно выбранные транзакции из последних N блоков блокчейна и возвращать хеш результата. В этом два важных преимущества. Во-первых, контракты Ethereum могут включать в себя любые виды вычислений, поэтому Ethereum ASIC по сути будет ASIC-ом для вычислений в общем, т. е. лучшим процессором. Во-вторых, майнингу необходим доступ ко всему блокчейну, что вынуждает майнеров хранить весь блокчейн и, по крайней мере, иметь возможность проверять каждую транзакцию. Это устраняет необходимость в централизованных пулах для майнинга; хотя пулы для майнинга по-прежнему могут выполнять законную роль уравнивания случайность распределения вознаграждения, эту функцию могут с равным успехом выполнять и одноранговые пулы без централизованного контроля. +Текущая цель Ethereum — использовать алгоритм майнинга, в котором майнерам необходимо извлекать случайные данные из состояния, вычислять некоторые случайно выбранные транзакции из последних N блоков блокчейна и возвращать хеш результата. В этом два важных преимущества. Во-первых, контракты Ethereum могут включать любые вычисления, поэтому Ethereum ASIC по сути был бы ASIC для общих вычислений, т. е. более совершенным процессором. Во-вторых, майнингу необходим доступ ко всему блокчейну, что вынуждает майнеров хранить весь блокчейн и, по крайней мере, иметь возможность проверять каждую транзакцию. Это устраняет необходимость в централизованных пулах для майнинга; хотя пулы для майнинга по-прежнему могут выполнять законную роль уравнивания случайность распределения вознаграждения, эту функцию могут с равным успехом выполнять и одноранговые пулы без централизованного контроля. Подобная модель ещё не тестировалась, и могут появиться сложности с обходом некоторых умных оптимизаций при использовании контрактов как алгоритма для майнинга. Одна интересная особенность этого алгоритма заключается в том, что она разрешает кому угодно «отравить колодец» путём введения контрактов в блокчейн, которые способны сделать непригодными для их вычисления тот или иной ASIC. Производители ASIC, в теории, имеют финансовый стимул использовать эту особенность для атаки друг друга. Таким образом, решение, которое мы разрабатываем — скорее адаптивное экономически-социальное, нежели сугубо техническое. @@ -468,9 +478,9 @@ _Несмотря на линейную эмиссию валюты, как и Одной из распространенных проблем с Ethereum является проблема масштабируемости. Как и биткоин, Ethereum страдает от недостатка, заключающегося в том, что каждая транзакция должна обрабатываться каждым узлом в сети. У биткоина текущий размер блокчейна составляет около 15 ГБ, увеличиваясь примерно на 1 МБ в час. Если бы сеть биткоина обрабатывала в секунду столько же транзакций, сколько обрабатывает Visa — 2000 транзакций Visa в секунду — она увеличивалась бы на 1 МБ каждые три секунды (1 ГБ в час, 8 ТБ в год). Ethereum, скорее всего, столкнется с похожей моделью роста, усугубляемой тем фактом, что поверх блокчейна Ethereum будет создано множество приложений, а не только валюта, как в случае с биткоином, но смягчаемой фактом, что полные узлы Ethereum должны хранить только состояние, а не всю историю блокчейна. -Проблема с таким большим блокчейном — риск централизации. Если размер блокчейна увеличится, скажем, до 100 ТБ, то вероятным сценарием будет то, что только очень небольшое количество крупных бизнесов будут запускать полные узлы, а все обычные пользователи будут использовать легкие узлы с простой проверкой платежей. В такой ситуации возникает потенциальная опасность того, что полные узлы могут объединяться и договариваться о мошенничестве каким-либо прибыльным способом (например, изменять вознаграждение за блок, выдавать себе BTC). Легкие узлы не смогут обнаружить это сразу же. Конечно, по крайней мере один честный полный узел, скорее всего, будет существовать, и через несколько часов информация о мошенничестве будет на таких платформах, как Reddit, но уже будет слишком поздно: обычным пользователям придется организовать усилия по внесению указанных блоков в черный список, что представляет собой огромную и, вероятно, невыполнимую координационную проблему такого же масштаба, как и проведение успешной атаки 51%. В случае с Bitcoin это в настоящее время является проблемой, но существует модификация блокчейна, [предложенная Питером Тоддом](https://web.archive.org/web/20140623061815/http://sourceforge.net/p/bitcoin/mailman/message/31709140/), которая решит эту проблему. +Проблема с таким большим блокчейном — риск централизации. Если размер блокчейна увеличится, скажем, до 100 ТБ, то вероятным сценарием будет то, что только очень небольшое количество крупных бизнесов будут запускать полные узлы, а все обычные пользователи будут использовать легкие узлы с простой проверкой платежей. В такой ситуации возникает потенциальная обеспокоенность, что полные узлы могут объединиться и договориться о мошенничестве каким-либо выгодным способом (например, изменить награду за блок, выдать себе BTC). Легкие узлы не смогут обнаружить это сразу же. Конечно, по крайней мере один честный полный узел, скорее всего, будет существовать, и через несколько часов информация о мошенничестве будет на таких платформах, как Reddit, но уже будет слишком поздно: обычным пользователям придется организовать усилия по внесению указанных блоков в черный список, что представляет собой огромную и, вероятно, невыполнимую координационную проблему такого же масштаба, как и проведение успешной атаки 51%. В случае с Bitcoin это в настоящее время является проблемой, но существует модификация блокчейна, [предложенная Питером Тоддом](https://web.archive.org/web/20140623061815/http://sourceforge.net/p/bitcoin/mailman/message/31709140/), которая облегчит эту проблему. -В ближайшем будущем Ethereum будет использовать две дополнительные стратегии против этой проблемы. Первая — из-за алгоритмов майнинга на основе блокчейна, по крайней мере каждый майнер будет вынужден стать полным узлом, что создает нижнюю границу количества полных узлов. Вторая и более важная — это то, что мы включим промежуточный корень дерева состояния в блокчейн после обработки каждой транзакции. Даже если проверка блоков централизована, пока существует хотя бы один честный проверяющий узел, то проблему централизации можно обойти с помощью протокола проверки. Если майнер публикует недействительный блок, этот блок либо плохо отформатирован, либо состояние `S[n]` неправильное. Поскольку известно, что `S[0]` является правильным, то должно быть некоторое первое состояние `S[i]`, которое является неправильным, а `S[i-1]` правильным. Проверяющий узел предоставит индекс `i` вместе с «доказательством недействительности», состоящим из подмножества узлов дерева Патриции, которым необходимо обработать `APPLY(S[i-1],TX[i]) > S[i]`. Узлы смогут использовать эти узлы дерева для выполнения этой части вычислений и увидеть, что сгенерированное `S[i]` не соответствует предоставленному `S[i]`. +В ближайшем будущем Ethereum будет использовать две дополнительные стратегии против этой проблемы. Первая — из-за алгоритмов майнинга на основе блокчейна, по крайней мере каждый майнер будет вынужден стать полным узлом, что создает нижнюю границу количества полных узлов. Вторая и более важная — это то, что мы включим промежуточный корень дерева состояния в блокчейн после обработки каждой транзакции. Даже если проверка блоков централизована, пока существует хотя бы один честный проверяющий узел, то проблему централизации можно обойти с помощью протокола проверки. Если майнер публикует недействительный блок, этот блок должен быть либо плохо отформатирован, либо состояние `S[n]` является неверным. Поскольку известно, что `S[0]` является верным, должно существовать некоторое первое состояние `S[i]`, которое является неверным, в то время как `S[i-1]` является верным. Проверяющий узел предоставит индекс `i` вместе с «доказательством недействительности», состоящим из подмножества узлов дерева Патриции, необходимых для обработки `APPLY(S[i-1],TX[i]) -> S[i]`. Узлы смогут использовать эти узлы для выполнения этой части вычислений и увидят, что сгенерированное `S[i]` не соответствует предоставленному `S[i]`. Другая, более сложная атака предполагает публикацию майнерами-злоумышленниками неполных блоков, поэтому даже не существует полной информации, позволяющей определить, являются ли блоки действительными. Решением этой проблемы является протокол вызова и ответа: проверяющие узлы отправляют «вызовы» в форме индексов целевых транзакций, и после получения узла дерева легкий узел рассматривает блок как ненадежный до тех пор, пока другой узел, будь то майнер или другой проверяющий, не предоставит подмножество узлов Патриции в качестве доказательства действительности. @@ -488,30 +498,30 @@ Ethereum как протокол изначально рассчитан на т 2. Технически, медиана 11 предыдущих блоков. 3. Внутренне 2 и CHARLIE являются числами[fn3](#notes), причем последнее имеет представление с порядком байтов от старшего к младшему по основанию 256. Числа могут быть от 0 до 2256-1. -### Дальнейшее изучение {#further-reading} +### Дополнительные материалы {#further-reading} -1. [Внутренняя ценность](http://bitcoinmagazine.com/8640/an-exploration-of-intrinsic-value-what-it-is-why-bitcoin-doesnt-have-it-and-why-bitcoin-does-have-it/) -2. [Умное имущество](https://en.bitcoin.it/wiki/Smart_Property) -3. [Умные контракты](https://en.bitcoin.it/wiki/Contracts) +1. [Внутренняя ценность](https://bitcoinmagazine.com/culture/an-exploration-of-intrinsic-value-what-it-is-why-bitcoin-doesnt-have-it-and-why-bitcoin-does-have-it) +2. [Умная собственность](https://en.bitcoin.it/wiki/Smart_Property) +3. [Смарт-контракты](https://en.bitcoin.it/wiki/Contracts) 4. [B-money](http://www.weidai.com/bmoney.txt) 5. [Многоразовые доказательства выполнения работы](https://nakamotoinstitute.org/finney/rpow/) -6. [Безопасные права на имущество с полномочиями владельца](https://nakamotoinstitute.org/secure-property-titles/) -7. [Проектный документ биткоина](http://bitcoin.org/bitcoin.pdf) +6. [Защищенные права собственности с полномочиями владельца](https://nakamotoinstitute.org/library/secure-property-titles/) +7. [Вайтпейпер Bitcoin](http://bitcoin.org/bitcoin.pdf) 8. [Namecoin](https://namecoin.org/) -9. [Треугольник Zooko](https://wikipedia.org/wiki/Zooko's_triangle) -10. [Проектный документ цветных монет](https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit) -11. [Проектный документ Mastercoin](https://github.com/mastercoin-MSC/spec) +9. [Треугольник Зуко](https://wikipedia.org/wiki/Zooko's_triangle) +10. [Вайтпейпер о цветных монетах](https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit) +11. [Вайтпейпер Mastercoin](https://github.com/mastercoin-MSC/spec) 12. [Децентрализованные автономные корпорации, Bitcoin Magazine](http://bitcoinmagazine.com/7050/bootstrapping-a-decentralized-autonomous-corporation-part-i/) 13. [Упрощенная проверка платежей](https://en.bitcoin.it/wiki/Scalability#Simplified_payment_verification) 14. [Деревья Меркла](https://wikipedia.org/wiki/Merkle_tree) 15. [Деревья Патриции](https://wikipedia.org/wiki/Patricia_tree) 16. [GHOST](https://eprint.iacr.org/2013/881.pdf) 17. [StorJ и автономные агенты, Джефф Гарзик](http://garzikrants.blogspot.ca/2013/01/storj-and-bitcoin-autonomous-agents.html) -18. [Майк Херн об умном имуществе на фестивале Тьюринга](https://www.youtube.com/watch?v=MVyv4t0OKe4) -19. [Ethereum RLP](https://web.archive.org/web/20250427212320/https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-RLP) -20. [Деревья Меркла-Патриции в Ethereum](https://web.archive.org/web/20250427212320/https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-Patricia-Tree) -21. [Питер Тодд о суммируемых деревьях Меркла](https://web.archive.org/web/20140623061815/http://sourceforge.net/p/bitcoin/mailman/message/31709140/) +18. [Майк Хирн об умной собственности на Turing Festival](https://www.youtube.com/watch?v=MVyv4t0OKe4) +19. [Ethereum RLP](/developers/docs/data-structures-and-encoding/rlp/) +20. [Деревья Меркла — Патриции в Ethereum](/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) +21. [Питер Тодд о суммирующих деревьях Меркла](https://web.archive.org/web/20140623061815/http://sourceforge.net/p/bitcoin/mailman/message/31709140/) -_Историю проектного документа смотрите в [этой статье](https://web.archive.org/web/20250427212319/https://github.com/ethereum/wiki/blob/old-before-deleting-all-files-go-to-wiki-wiki-instead/old-whitepaper-for-historical-reference.md)._ +_Историю вайтпейпера см. в [этой вики](https://web.archive.org/web/20250427212319/https://github.com/ethereum/wiki/blob/old-before-deleting-all-files-go-to-wiki-wiki-instead/old-whitepaper-for-historical-reference.md)._ -_Ethereum, как и многие проекты с открытым исходным кодом, управляемые сообществом, эволюционировал с момента своего создания. Чтобы узнать о последних событиях в Ethereum, и как внесены изменения в протокол, мы рекомендуем [это руководство](/learn/)._ +_Ethereum, как и многие проекты с открытым исходным кодом, управляемые сообществом, эволюционировал с момента своего создания. Чтобы узнать о последних разработках Ethereum и о том, как вносятся изменения в протокол, мы рекомендуем [это руководство](/learn/)._ diff --git a/public/content/translations/ru/wrapped-eth/index.md b/public/content/translations/ru/wrapped-eth/index.md new file mode 100644 index 00000000000..31409954d63 --- /dev/null +++ b/public/content/translations/ru/wrapped-eth/index.md @@ -0,0 +1,66 @@ +--- +title: "Что такое обернутый эфир (WETH)" +description: "Введение в обернутый эфир (WETH) — ERC20-совместимую оболочку для эфира (ETH)." +lang: ru +--- + +# Обернутый эфир (WETH) {#intro-to-weth} + + + +
    Подключите ваш кошелек, чтобы обернуть или развернуть ETH в любой сети на [WrapETH.com](https://www.wrapeth.com/)
    +     + +Ether (ETH) — основная валюта Ethereum. Он используется для нескольких целей, таких как стейкинг, в качестве валюты и оплаты комиссии за газ для вычислений. **WETH по сути является обновленной формой ETH с некоторыми дополнительными функциями, необходимыми для многих приложений, и [токенами ERC-20](/glossary/#erc-20)**, которые являются другими типами цифровых активов на Ethereum. Чтобы работать с этими токенами, ETH должен следовать тем же правилам, что и они, известным как стандарт ERC-20. + +Чтобы восполнить этот пробел, был создан Wrapped ETH (WETH). **Wrapped ETH — это смарт-контракт, который позволяет вам внести в контракт любое количество ETH и получить ту же сумму в виде отчеканенных WETH**, соответствующих стандарту токенов ERC-20. WETH — это представление ETH, которое позволяет вам взаимодействовать с ним как с токеном ERC-20, а не как с собственным активом ETH. Вам по-прежнему понадобится собственный ETH для оплаты комиссий за газ, поэтому не забудьте оставить немного при внесении депозита. + +Вы можете развернуть WETH на ETH, используя смарт-контракт WETH. Вы можете выкупить любую сумму WETH с помощью смарт-контракта WETH и получить ту же сумму в ETH. Депонированный WETH затем сжигается и выводится из оборотного запаса WETH. + +**Примерно 3 % обращающегося количества ETH зафиксировано в контракте токена WETH**, что делает его одним из наиболее используемых [смарт-контрактов](/glossary/#smart-contract). WETH особенно важен для пользователей, взаимодействующих с приложениями децентрализованных финансов (DeFi). + +## Зачем оборачивать ETH по стандарту ERC-20? {#why-do-we-need-to-wrap-eth} + +[ERC-20](/developers/docs/standards/tokens/erc-20/) определяет стандартный интерфейс для передаваемых токенов, поэтому каждый может создавать токены, которые беспрепятственно взаимодействуют с приложениями, и токены, использующие этот стандарт в экосистеме Ethereum. Поскольку **ETH появился раньше стандарта ERC-20**, он не соответствует этой спецификации. Это означает, что **вы не можете легко** обменять ETH на другие токены ERC-20 или **использовать ETH в приложениях, работающих по стандарту ERC-20**. Обертывание ETH дает вам возможность сделать следующее: + +- **Обменивать ETH на токены ERC-20**. Вы не можете напрямую обменять ETH на другие токены ERC-20. WETH — это представление эфира, которое соответствует стандарту взаимозаменяемых токенов ERC-20 и может быть обменяно с другими токенами ERC-20. + +- **Использовать ETH в децентрализованных приложениях**. Поскольку ETH несовместим с ERC20, разработчикам придется создавать отдельные интерфейсы (один для ETH, а другой для токенов ERC-20) в децентрализованных приложениях. Обертывание ETH устраняет это препятствие и позволяет разработчикам обрабатывать ETH и другие токены в одном децентрализованном приложении. Многие приложения децентрализованного финансирования используют этот стандарт и создают рынки для обмена этими токенами. + +## Обернутый эфир (WETH) и эфир (ETH): в чем разница? {#weth-vs-eth-differences} + +| | **Эфир (ETH)** | **Обернутый эфир (WETH)** | +| -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Запас | Запас ETH регулируется протоколом Ethereum. [Выпуск](/roadmap/merge/issuance) ETH регулируется валидаторами Ethereum при обработке транзакций и создании блоков. | WETH — это токен ERC-20, запас которого управляется смарт-контрактом. Новые единицы WETH выпускаются контрактом после поступления депозитов ETH от пользователей или после того, как WETH сжигаются, когда пользователь обменивает WETH на ETH. | +| Владение | Право собственности регулируется протоколом Ethereum через баланс вашего аккаунта. | Право собственности на WETH регулируется смарт-контрактом токена WETH, защищенным протоколом Ethereum. | +| Газ | Эфир (ETH) — это принятая единица оплаты для вычислений в сети Ethereum. Плата за газ выражена в гвей (единица эфира). | Оплата газа токенами WETH нативно не поддерживается. | + +## Часто задаваемые вопросы {#faq} + + + +Вы платите комиссию за газ для обертывания или развертывания ETH с использованием контракта WETH. + + + + +WETH обычно считается безопасным, поскольку он основан на простом и проверенном смарт-контракте. Контракт WETH также официально проверен, что является высшим стандартом безопасности для смарт-контрактов на Ethereum. + + + + +Помимо [канонической реализации WETH](https://etherscan.io/token/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2), описанной на этой странице, существуют и другие варианты. Это могут быть специальные токены, созданные разработчиками приложений, или версии, выпущенные в других блокчейнах, которые могут вести себя по-разному или иметь другие параметры безопасности. **Всегда дважды проверяйте информацию о токене, чтобы знать, с какой реализацией WETH вы взаимодействуете.** + + + + +- [Основная сеть Ethereum](https://etherscan.io/token/0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2) +- [Arbitrum](https://arbiscan.io/token/0x82af49447d8a07e3bd95bd0d56f35241523fbab1) +- [Optimism](https://optimistic.etherscan.io/token/0x4200000000000000000000000000000000000006) + + +## Дополнительные материалы {#further-reading} + +- [Что такое WETH?](https://weth.tkn.eth.limo/) +- [Информация о токене WETH на Blockscout](https://eth.blockscout.com/token/0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2) +- [Формальная проверка WETH](https://zellic.io/blog/formal-verification-weth)