diff --git a/public/content/translations/ru/developers/docs/consensus-mechanisms/pos/attestations/index.md b/public/content/translations/ru/developers/docs/consensus-mechanisms/pos/attestations/index.md new file mode 100644 index 00000000000..7d43f9b6a2e --- /dev/null +++ b/public/content/translations/ru/developers/docs/consensus-mechanisms/pos/attestations/index.md @@ -0,0 +1,92 @@ +--- +title: "Аттестации" +description: "Описание аттестаций на Эфириуме с доказательством работы." +lang: ru +--- + +Ожидается, что валидатор будет создавать, подписывать и транслировать аттестацию в течение каждой эпохи. На этой странице описано, как выглядят эти аттестации и как они обрабатываются и передаются между клиентами консенсуса. + +## Что такое аттестация? {#what-is-an-attestation} + +Каждую [эпоху](/glossary/#epoch) (6,4 минуты) валидатор предлагает аттестацию в сеть. Аттестация проводится для определенной ячейки в эпохе. Цель аттестации — проголосовать в пользу представления валидатором цепочки, в частности, за самый последний обоснованный блок и первый блок в текущей эпохе (известные как контрольные точки `source` и `target`). Эта информация объединяется для всех участвующих валидаторов, позволяя сети достичь консенсуса относительно состояния блокчейна. + +Аттестация содержит следующие компоненты: + +- `aggregation_bits`: битовый список валидаторов, в котором позиция сопоставляется с индексом валидатора в их комитете; значение (0/1) указывает, подписал ли валидатор `data` (т. е. активен ли он и согласен ли с создателем блока) +- `data`: сведения, относящиеся к аттестации, как определено ниже +- `signature`: подпись BLS, которая объединяет подписи отдельных валидаторов + +Первая задача для аттестующего валидатора — собрать `data`. `data` содержит следующую информацию: + +- `slot`: номер слота, к которому относится аттестация +- `index`: номер, который определяет, к какому комитету принадлежит валидатор в данном слоте +- `beacon_block_root`: корневой хэш блока, который валидатор видит во главе цепочки (результат применения алгоритма выбора форка) +- `source`: часть голосования за окончательность, указывающая, какой блок валидаторы считают последним обоснованным блоком +- `target`: часть голосования за окончательность, указывающая, какой блок валидаторы считают первым блоком в текущей эпохе + +Как только `data` собраны, валидатор может изменить бит в `aggregation_bits`, соответствующий индексу своего валидатора, с 0 на 1, чтобы показать, что он участвовал. + +Наконец, валидатор подписывает аттестацию и транслирует её в сеть. + +### Агрегированная аттестация {#aggregated-attestation} + +Существуют значительные трудности с передачей этих данных по сети для каждого валидатора. Поэтому аттестации от отдельных валидаторов агрегируются внутри подсетей, прежде чем передаваться более широко. Это включает в себя агрегирование подписей, чтобы транслируемая аттестация содержала данные консенсуса (`data`) и одну подпись, сформированную путем объединения подписей всех валидаторов, которые согласны с этими `data`. Это можно проверить с помощью `aggregation_bits`, поскольку они предоставляют индекс каждого валидатора в его комитете (идентификатор которого указан в `data`), который можно использовать для запроса отдельных подписей. + +В каждую эпоху 16 валидаторов в каждой подсети выбираются в качестве `агрегаторов`. Агрегаторы собирают все аттестации, о которых они узнают по gossip-сети и которые содержат `data`, эквивалентные их собственным. Отправитель каждой совпадающей аттестации записывается в `aggregation_bits`. Затем агрегаторы транслируют аттестационную совокупность в более широкую сеть. + +Когда валидатор выбирается в качестве предлагающего блок, он упаковывает совокупные аттестации из подсетей вплоть до последней ячейки в новом блоке. + +### Жизненный цикл включения аттестации {#attestation-inclusion-lifecycle} + +1. Генерация +2. Распространение +3. Объединение в совокупность +4. Распространение +5. Включение + +Жизненный цикл аттестации представлен на схеме ниже: + +![жизненный цикл аттестации](./attestation_schematic.png) + +## Вознаграждения {#rewards} + +Валидаторы получают вознаграждение за отправку аттестаций. Вознаграждение за аттестацию зависит от флагов участия (источник, цель и голова), базового вознаграждения и коэффициента участия. + +Каждый из флагов участия может быть истинным или ложным, в зависимости от предоставленной аттестации и задержки ее включения. + +Наилучший сценарий возникает, когда все три флага истинны, и в этом случае валидатор получает (за каждый правильный флаг): + +`reward += base reward * flag weight * flag attesting rate / 64` + +Коэффициент аттестации флага измеряется как сумма эффективных балансов всех аттестующих валидаторов для данного флага в сравнении с общим активным эффективным балансом. + +### Базовое вознаграждение {#base-reward} + +Базовое вознаграждение рассчитывается в соответствии с количеством аттестующих валидаторов и их эффективными балансами застейканного эфира: + +`base reward = validator effective balance x 2^6 / SQRT(Effective balance of all active validators)` + +#### Задержка включения {#inclusion-delay} + +В тот момент, когда валидаторы голосовали за голову цепи (`блок n`), `блок n+1` еще не был предложен. Поэтому аттестации естественным образом включаются **на один блок позже**, так что все аттестации, в которых `блок n` был выбран головой цепи, включаются в `блок n+1`, а **задержка включения** составляет 1. Если задержка вхождения удваивается до двух ячеек, вознаграждение за аттестацию уменьшается вдвое, поскольку для расчета вознаграждения за аттестацию базовое вознаграждение умножается на величину, обратную задержке вхождения. + +### Сценарии аттестации {#attestation-scenarios} + +#### Отсутствующий голосующий валидатор {#missing-voting-validator} + +У валидаторов есть максимум 1 эпоха для предоставления своей аттестации. Если аттестация была пропущена в эпоху 0, они могут отправить ее с задержкой вхождения в эпоху 1. + +#### Отсутствующий агрегатор {#missing-aggregator} + +Всего на каждую эпоху приходится 16 агрегаторов. Кроме того, случайные валидаторы подписываются на **две подсети на 256 эпох** и служат резервной копией на случай отсутствия агрегаторов. + +#### Отсутствующий создатель блока {#missing-block-proposer} + +Обратите внимание, что в некоторых случаях удачливый агрегатор также может стать предлагающим блок. Если аттестация не была включена из-за того, что предлагающий блок пропал, следующий предлагающий блок валидатор подберет агрегированную аттестацию и включит ее в следующий блок. Однако **задержка включения** увеличится на единицу. + +## Дополнительные материалы {#further-reading} + +- [Аттестации в аннотированной спецификации консенсуса от Виталика](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#attestationdata) +- [Аттестации на eth2book.info](https://eth2book.info/capella/part3/containers/dependencies/#attestationdata) + +_Знаете ресурс сообщества, который вам пригодился? Измените эту страницу и добавьте его!_ diff --git a/public/content/translations/ru/developers/docs/consensus-mechanisms/pos/block-proposal/index.md b/public/content/translations/ru/developers/docs/consensus-mechanisms/pos/block-proposal/index.md new file mode 100644 index 00000000000..80370191d42 --- /dev/null +++ b/public/content/translations/ru/developers/docs/consensus-mechanisms/pos/block-proposal/index.md @@ -0,0 +1,69 @@ +--- +title: "Предложение блока" +description: "Объяснение того, как предлагаются блоки в Эфириуме с доказательством владения." +lang: ru +--- + +Блоки являются фундаментальными единицами блокчейна. Блоки — это отдельные единицы информации, которые передаются между узлами, согласовываются и добавляются в базу данных каждого узла. На этой странице объясняется, как они производятся. + +## Предварительные условия {#prerequisites} + +Предложение блока — часть протокола доказательства владения. Чтобы лучше понять эту страницу, мы рекомендуем вам прочитать о [доказательстве владения (proof-of-stake)](/developers/docs/consensus-mechanisms/pos/) и [архитектуре блоков](/developers/docs/blocks/). + +## Кто предлагает блоки? Кто создает блоки? {#who-produces-blocks} + +Аккаунты валидаторов предлагают блоки. Аккаунты валидаторов управляются операторами узлов, которые запускают программы валидаторов в рамках своих клиентов исполнения и консенсуса. Также для этого операторы узлов должны иметь не менее 32 ETH, внесённых в депозитный контракт. Однако каждый валидатор лишь периодически предлагает блок. Эфириум измеряет время в ячейках и эпохах. Каждая ячейка длится 12 секунд, а 32 ячейки (6,4 минуты) составляют одну эпоху. Каждая ячейка является возможностью добавить новый блок в сеть. + +### Случайный выбор {#random-selection} + +В каждой ячейке псевдослучайно выбирается один валидатор, чтобы предложить блок. В блокчейне нет такого понятия, как истинная случайность, так как если бы каждый из узлов сети сам генерировал по-настоящему случайные числа, узлы не могли бы прийти к консенсусу. Вместо этого, цель — сделать процесс выбора валидатора непредсказуемым. Случайность в Эфириуме достигается при помощи алгоритма RANDAO, который смешивает хеш от инициатора блока с некоторым семенем (seed), обновляющимся каждый блок. Это значение используется для выбора определённого валидатора из общего их набора. Выбор валидатора фиксируется за две эпохи для защиты от определенных видов манипуляций с семенами. + +Хотя валидаторы и делают дополнения к значению RANDAO в каждой ячейке, глобальное значение RANDAO обновляется лишь раз за эпоху. Чтобы вычислить индекс следующего инициатора блока, значение RANDAO смешивается с номерами ячеек для получения уникального значения в каждой из них. Вероятность того, что будет выбран отдельный валидатор, не равна `1/N` (где `N` = общее количество активных валидаторов). Вместо этого, она является взвешенной для каждого валидатора в соответствии с его эффективным балансом ETH. Максимальный эффективный баланс составляет 32 ETH (это означает, что `balance < 32 ETH` приводит к меньшему весу, чем `balance == 32 ETH`, но `balance > 32 ETH` не приводит к большему весу, чем `balance == 32 ETH`). + +Только один инициатор блока выбирается в каждой ячейке. При нормальных условиях, один производитель блока создаёт и выпускает один блок в свою выделенную ячейку. Создание двух блоков для одной и той же ячейки является нарушением, известным как "неоднозначность", из-за которого может пройти наказание валидатора. + +## Как создаётся блок? {#how-is-a-block-created} + +Инициатор блока должен передать подписанный блок beacon, который строится поверх самого последнего заголовка цепочки в соответствии с представлением его собственного локально запущенного алгоритма выбора форка. Алгоритм выбора форка применяет все стоящие в очереди подтверждения, оставшиеся от предыдущей ячейки, а затем находит блок с наибольшим накопленным весом подтверждений за всю его историю. Этот блок становится родителем нового блока, созданного инициатором. + +Инициатор блока создаёт блок, собирая данные из своей локальной базы данных и просматривая сеть. Содержимое блока показано во фрагменте ниже: + +```rust +class BeaconBlockBody(Container): + randao_reveal: BLSSignature + eth1_data: Eth1Data + graffiti: Bytes32 + proposer_slashings: List[ProposerSlashing, MAX_PROPOSER_SLASHINGS] + attester_slashings: List[AttesterSlashing, MAX_ATTESTER_SLASHINGS] + attestations: List[Attestation, MAX_ATTESTATIONS] + deposits: List[Deposit, MAX_DEPOSITS] + voluntary_exits: List[SignedVoluntaryExit, MAX_VOLUNTARY_EXITS] + sync_aggregate: SyncAggregate + execution_payload: ExecutionPayload +``` + +Поле `randao_reveal` принимает проверяемое случайное значение, которое инициатор блока получает, подписывая номер текущей эпохи. `eth1_data` — это голос за представление инициатора блока о депозитном контракте, включающий корень дерева Меркла депозитов и общее количество депозитов, которое позволяет проверять новые депозиты. `graffiti` — это необязательное поле, которое можно использовать для добавления сообщения в блок. `proposer_slashings` и `attester_slashings` — это поля, содержащие доказательство того, что определённые валидаторы совершили наказуемые нарушения, в соответствии с представлением инициатора о цепочке. `deposits` — это список новых депозитов валидаторов, о которых известно инициатору блока, а `voluntary_exits` — это список валидаторов, желающих выйти, о чём инициатор блока узнал в gossip-сети уровня консенсуса. `sync_aggregate` — это вектор, показывающий, какие валидаторы были ранее назначены в комитет синхронизации (подмножество валидаторов, обслуживающее данные легких клиентов) и участвовали в подписи данных. + +`execution_payload` позволяет передавать информацию о транзакциях между клиентом исполнения и клиентом консенсуса. `execution_payload` — это блок данных исполнения, который вкладывается в Beacon-блок. Поля внутри `execution_payload` отражают структуру блоков, описанную в Жёлтой книге Ethereum, за исключением того, что в ней нет оммеров и `prev_randao` существует вместо `difficulty`. Клиент-исполнитель имеет доступ к локальному пулу транзакций, о которых он узнал из собственной сети gossip. Эти транзакции выполняются локально для генерации обновленного состояния, известного как post-state. Транзакции включены в `execution_payload` в виде списка с названием `transactions`, а пострезультативное состояние предоставляется в поле `state-root`. + +Все эти данные собираются в блоке beacon, подписываются и передаются узлам-соседям инициатора, которые распространяют их своим соседям и т. д. + +Узнайте больше об [анатомии блоков](/developers/docs/blocks/). + +## Что происходит с блоком? {#what-happens-to-blocks} + +Блок добавляется на локальную базу данных инициатора и передаётся соседним узлам через gossip сеть консенсус-леера. Когда валидатор получает блок, он проверяет данные внутри него, включая проверку правильности родителя блока, принадлежности к правильной ячейке, корректности индекса инициатора, правильности раскрытия RANDAO и того, что инициатор не наказан сокращением. `execution_payload` распаковывается, и клиент исполнения валидатора повторно выполняет транзакции из списка, чтобы проверить предложенное изменение состояния. Если блок проходит все эти проверки, каждый валидатор добавляет его в свою собственную каноническую цепочку. Затем процесс начинается снова в следующей ячейке. + +## Награды за блок {#block-rewards} + +Инициатор блока получает плату за свою работу. Существует `base_reward`, рассчитываемая как функция от количества активных валидаторов и их эффективных балансов. Затем инициатор блока получает долю от `base_reward` за каждую действительную аттестацию, включенную в блок; чем больше валидаторов подтверждают блок, тем больше вознаграждение инициатора блока. Также существует вознаграждение за сообщение о валидаторах, подлежащих слэшингу, равное `1/512 * effective balance` за каждого валидатора, подвергнутого слэшингу. + +[Подробнее о вознаграждениях и штрафах](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties) + +## Дополнительные материалы {#further-reading} + +- [Введение в блоки](/developers/docs/blocks/) +- [Введение в доказательство доли владения](/developers/docs/consensus-mechanisms/pos/) +- [Спецификации консенсуса Ethereum](https://github.com/ethereum/consensus-specs) +- [Введение в Gasper](/developers/docs/consensus-mechanisms/pos/gasper/) +- [Обновление Ethereum](https://eth2book.info/) diff --git a/public/content/translations/ru/developers/docs/consensus-mechanisms/pos/faqs/index.md b/public/content/translations/ru/developers/docs/consensus-mechanisms/pos/faqs/index.md new file mode 100644 index 00000000000..a44208380ee --- /dev/null +++ b/public/content/translations/ru/developers/docs/consensus-mechanisms/pos/faqs/index.md @@ -0,0 +1,172 @@ +--- +title: "Часто задаваемые вопросы" +description: "Часто задаваемые вопросы о доказательстве доли владения Ethereum." +lang: ru +--- + +## Что такое доказательство доли владения {#what-is-proof-of-stake} + +Proof-of-stake - это класс алгоритма, который обеспечивает безопасность блокчейна, гарантируя, что активы не будут потеряны из-за действий злоумышленников, действующих недобросовестно. Системы Proof-of-stake требуют, чтобы набор валидаторов предоставил некоторый актив, который будет уничтожен, если валидатор совершит какое-то нечестное действие. Ethereum использует механизм proof-of-stake для защиты блокчейна. + +## Чем proof-of-stake отличается от proof-of-work? {#comparison-to-proof-of-work} + +И доказательство работы, и доказательство доли владения — это механизмы, которые экономически препятствуют злоумышленникам рассылать спам или обманывать сеть. В обоих случаях узлы, активно участвующие в консенсусе, вносят в сеть некий актив, который они потеряют, если будут плохо себя вести. + +В механизме доказательства работы этим активом является энергия. Узел, известный как майнер, запускает алгоритм, цель которого - вычислить значение быстрее, чем любой другой узел. Самый быстрый узел имеет право предложить блок для добавления в цепь. Чтобы изменить историю цепи или доминировать в предложении блоков, майнер должен обладать такой большой вычислительной мощностью, чтобы всегда побеждать в гонке. Это непомерно дорого и трудновыполнимо, что защищает цепь от атак. Энергия, необходимая для «майнинга» с использованием доказательства работы, — это реальный актив, за который платят майнеры. + +Доказательство доли владения требует, чтобы узлы, известные как валидаторы, явно отправляли криптоактив в смарт-контракт. Если валидатор поведет себя ненадлежащим образом, этот криптоактив может быть уничтожен, потому что он «ставит» свои активы непосредственно в цепь, а не косвенно через затраты энергии. + +Доказательство работы намного более энергозатратно, потому что в процессе майнинга сжигается электричество. Доказательство доли владения, с другой стороны, требует очень малого количества энергии — валидаторы Ethereum могут работать даже на маломощных устройствах, таких как Raspberry Pi. Считается, что механизм доказательства доли владения Ethereum более безопасен, чем доказательство работы, потому что стоимость атаки выше, а последствия для атакующего более серьезны. + +Доказательство работы в сравнении с доказательством доли владения — это спорная тема. [Блог Виталика Бутерина](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-are-the-benefits-of-proof-of-stake-as-opposed-to-proof-of-work) и дебаты между Джастином Дрейком и Лин Олден дают хорошее резюме аргументов. + + + +## Является ли доказательство доли владения энергоэффективным? {#is-pos-energy-efficient} + +Да. Узлы в сети с доказательством доли владения используют незначительное количество энергии. Стороннее исследование пришло к выводу, что вся сеть Ethereum с доказательством доли владения потребляет около 0,0026 ТВтч/год, что примерно в 13 000 раз меньше, чем потребляют видеоигры только в США. + +[Подробнее об энергопотреблении Ethereum](/energy-consumption/). + +## Безопасно ли доказательство доли владения? {#is-pos-secure} + +Доказательство доли владения Ethereum очень безопасно. Механизм тщательно исследовался, разрабатывался и тестировался на протяжении восьми лет, прежде чем был запущен в работу. Гарантии безопасности отличаются от блокчейнов на основе доказательства работы. В механизме доказательства доли владения злонамеренные валидаторы могут быть активно наказаны («подвергнуты слэшингу») и исключены из набора валидаторов, что будет стоить им значительной суммы ETH. В рамках доказательства работы атакующий может повторять свою атаку, пока у него достаточно хэш-мощности. Также дороже проводить эквивалентные атаки на Ethereum с доказательством доли владения, чем на Ethereum с доказательством работы. Чтобы повлиять на жизнеспособность цепи, требуется не менее 33% от общего количества поставленного эфира в сети (за исключением случаев очень сложных атак с чрезвычайно низкой вероятностью успеха). Для контроля над содержимым будущих блоков требуется не менее 51 % от общего количества поставленных ETH, а для переписывания истории — более 66 % от общей доли. Протокол Ethereum уничтожит эти активы в сценариях атаки 33% или 51% и по социальному консенсусу в сценарии атаки 66%. + +- [Подробнее о защите Ethereum с доказательством доли владения от злоумышленников](/developers/docs/consensus-mechanisms/pos/attack-and-defense) +- [Подробнее о дизайне доказательства доли владения](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) + +## Делает ли доказательство доли владения Ethereum дешевле? {#does-pos-make-ethereum-cheaper} + +Нет. Стоимость отправки транзакции (комиссия за газ) определяется динамическим рынком комиссий, который растет с увеличением спроса в сети. Механизм консенсуса не оказывает на это прямого влияния. + +[Подробнее о газе](/developers/docs/gas). + +## Кто такие узлы, клиенты и валидаторы? {#what-are-nodes-clients-and-validators} + +Узлы - это компьютеры, подключенные к сети Ethereum. Клиенты - это программное обеспечение, которое они запускают, чтобы превратить свой компьютер в узел. Существует два типа клиентов: клиенты исполнения и клиенты консенсуса. Оба необходимы, чтобы создать узел. Валидатор — это дополнительный компонент клиента консенсуса, который позволяет узлу участвовать в консенсусе на основе доказательства доли владения. Это означает создание и предложение блоков при выборе, а также аттестацию блоков, о которых они узнают в сети. Чтобы запустить валидатор, оператор узла должен внести 32 ETH в депозитный контракт. + +- [Подробнее об узлах и клиентах](/developers/docs/nodes-and-clients) +- [Подробнее о стейкинге](/staking) + +## Является ли доказательство доли владения новой идеей? {#is-pos-new} + +Нет. В 2011 году пользователь на форуме BitcoinTalk [предложил базовую идею доказательства доли владения](https://bitcointalk.org/index.php?topic=27787.0) в качестве обновления для Bitcoin. Прошло одиннадцать лет, прежде чем он был готов к внедрению в основной сети Ethereum. Некоторые другие цепи внедрили доказательство доли владения раньше, чем Ethereum, но не специфичный механизм Ethereum (известный как Gasper). + +## В чем особенность доказательства доли владения в Ethereum? {#why-is-ethereum-pos-special} + +Механизм доказательства доли владения Ethereum уникален по своей конструкции. Это был не первый механизм доказательства доли владения, который был разработан и внедрен, но он является самым надежным. Механизм доказательства доли владения известен как «Casper». Casper определяет, как выбираются валидаторы для предложения блоков, как и когда делаются аттестации, как подсчитываются аттестации, вознаграждения и штрафы для валидаторов, условия слэшинга, отказоустойчивые механизмы, такие как утечка из-за неактивности, и условия для «финальности». Финальность — это условие, согласно которому для того, чтобы блок считался постоянной частью канонической цепи, за него должны проголосовать не менее 66% от общего количества поставленных ETH в сети. Исследователи разработали Casper специально для Ethereum, и Ethereum — это первый и единственный блокчейн, который его внедрил. + +В дополнение к Casper, доказательство доли владения Ethereum использует алгоритм выбора форка под названием LMD-GHOST. Это необходимо на случай возникновения ситуации, когда для одного и того же слота существуют два блока. Это создает два форка блокчейна. LMD-GHOST выбирает тот, у которого наибольший «вес» аттестаций. Вес — это количество аттестаций, взвешенное по эффективному балансу валидаторов. LMD-GHOST уникален для Ethereum. + +Сочетание Casper и LMD_GHOST известно как Gasper. + +[Подробнее о Gasper](/developers/docs/consensus-mechanisms/pos/gasper/) + +## Что такое слэшинг? {#what-is-slashing} + +Слэшинг — это термин, обозначающий уничтожение части доли валидатора и его исключение из сети. Сумма ETH, теряемая при слэшинге, масштабируется в зависимости от количества подвергшихся слэшингу валидаторов — это означает, что вступившие в сговор валидаторы наказываются строже, чем отдельные лица. + +[Подробнее о слэшинге](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties#slashing) + +## Зачем валидаторам 32 ETH? {#why-32-eth} + +Валидаторы должны ставить ETH в стейкинг, чтобы им было что терять в случае неправомерных действий. Причина, по которой они должны ставить в стейкинг именно 32 ETH, заключается в том, чтобы позволить узлам работать на скромном оборудовании. Если бы минимальное количество ETH на валидатора было ниже, то количество валидаторов и, следовательно, количество сообщений, которые необходимо обрабатывать в каждом слоте, увеличилось бы, что означало бы, что для запуска узла потребовалось бы более мощное оборудование. + +## Как выбирают валидаторов? {#how-are-validators-selected} + +Единственный валидатор выбирается псевдослучайно для предложения блока в каждом слоте с помощью алгоритма под названием RANDAO, который смешивает хэш от предлагающего блок с начальным числом, которое обновляется каждый блок. Это значение используется для выбора определённого валидатора из общего их набора. Выбор валидатора фиксируется за две эпохи вперед. + +[Подробнее о выборе валидаторов](/developers/docs/consensus-mechanisms/pos/block-proposal) + +## Что такое стейк-грайндинг? {#what-is-stake-grinding} + +Стейк-грайндинг — это категория атаки на сети с доказательством доли владения, при которой злоумышленник пытается повлиять на алгоритм выбора валидаторов в пользу своих собственных валидаторов. Атаки стейк-грайндинга на RANDAO требуют около половины от общего количества поставленных ETH. + +[Подробнее о стейк-грайндинге](https://eth2book.info/altair/part2/building_blocks/randomness/#randao-biasability) + +## Что такое социальный слэшинг? {#what-is-social-slashing} + +Социальный слэшинг — это способность сообщества координировать форк блокчейна в ответ на атаку. Это позволяет сообществу восстановиться после того, как злоумышленник финализировал нечестную цепь. Социальный слэшинг также может использоваться против атак цензуры. + +- [Подробнее о социальном слэшинге](https://ercwl.medium.com/the-case-for-social-slashing-59277ff4d9c7) +- [Виталик Бутерин о социальном слэшинге](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake) + +## Подвергнусь ли я слэшингу? {#will-i-get-slashed} + +Как валидатору, очень трудно подвергнуться слэшингу, если вы намеренно не совершаете злонамеренных действий. Слэшинг применяется только в очень специфических сценариях, когда валидаторы предлагают несколько блоков для одного и того же слота или противоречат сами себе в своих аттестациях — возникновение таких ситуаций случайно очень маловероятно. + +[Подробнее об условиях слэшинга](https://eth2book.info/altair/part2/incentives/slashing) + +## Что такое проблема отсутствия доли? {#what-is-nothing-at-stake-problem} + +Проблема отсутствия доли — это концептуальная проблема некоторых механизмов доказательства доли владения, где есть только вознаграждения и нет штрафов. Если на кону ничего не стоит, прагматичный валидатор с одинаковым удовольствием будет аттестовать любой или даже несколько форков блокчейна, так как это увеличивает его вознаграждения. Ethereum обходит эту проблему, используя условия финальности и слэшинг для обеспечения одной канонической цепи. + +[Подробнее о проблеме отсутствия доли](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-the-nothing-at-stake-problem-and-how-can-it-be-fixed) + +## Что такое алгоритм выбора форка? {#what-is-a-fork-choice-algorithm} + +Алгоритм выбора форка реализует правила, определяющие, какая цепь является канонической. В оптимальных условиях нет необходимости в правиле выбора форка, потому что на каждый слот приходится только один предлагающий блок и один блок для выбора. Однако иногда несколько блоков для одного и того же слота или поздно поступившая информация приводят к нескольким вариантам организации блоков в начале цепи. В этих случаях все клиенты должны одинаково реализовывать некоторые правила, чтобы убедиться, что все они выбирают правильную последовательность блоков. Алгоритм выбора форка кодирует эти правила. + +Алгоритм выбора форка Ethereum называется LMD-GHOST. Он выбирает форк с наибольшим весом аттестаций, то есть тот, за который проголосовало большинство поставленных ETH. + +[Подробнее о LMD-GHOST](/developers/docs/consensus-mechanisms/pos/gasper/#fork-choice) + +## Что такое финальность в доказательстве доли владения? {#what-is-finality} + +Финальность в доказательстве доли владения — это гарантия того, что данный блок является постоянной частью канонической цепи и не может быть отменен, если не произойдет сбой консенсуса, при котором злоумышленник сожжет 33% от общего количества поставленного эфира. Это «криптоэкономическая» финальность, в отличие от «вероятностной финальности», которая актуальна для блокчейнов с доказательством работы. При вероятностной финальности для блоков нет явных финализированных/нефинализированных состояний — просто становится все менее и менее вероятным, что блок может быть удален из цепи по мере его старения, и пользователи сами определяют, когда они достаточно уверены, что блок «безопасен». При криптоэкономической финальности за пары контрольных блоков должны проголосовать 66% поставленного эфира. Если это условие выполнено, блоки между этими контрольными точками явно «финализируются». + +[Подробнее о финальности](/developers/docs/consensus-mechanisms/pos/#finality) + +## Что такое «слабая субъективность»? {#what-is-weak-subjectivity} + +Слабая субъективность — это особенность сетей с доказательством доли владения, где социальная информация используется для подтверждения текущего состояния блокчейна. Новым узлам или узлам, возвращающимся в сеть после длительного отсутствия, может быть предоставлено недавнее состояние, чтобы узел мог немедленно увидеть, находится ли он на правильной цепи. Эти состояния известны как «контрольные точки слабой субъективности», и их можно получить от других операторов узлов по внешним каналам, из обозревателей блоков или из нескольких общедоступных конечных точек. + +[Подробнее о слабой субъективности](/developers/docs/consensus-mechanisms/pos/weak-subjectivity) + +## Устойчиво ли доказательство доли владения к цензуре? {#is-pos-censorship-resistant} + +Устойчивость к цензуре в настоящее время трудно доказать. Однако, в отличие от доказательства работы, доказательство доли владения предлагает возможность координировать слэшинги для наказания валидаторов, применяющих цензуру. Грядут изменения в протоколе, которые разделяют создателей блоков и предлагающих блоки и вводят списки транзакций, которые создатели должны включать в каждый блок. Это предложение известно как разделение предлагающего и создателя и помогает предотвратить цензуру транзакций со стороны валидаторов. + +[Подробнее о разделении предлагающего и создателя](https://notes.ethereum.org/@fradamt/H1TsYRfJc#Original-basic-scheme) + +## Может ли система доказательства доли владения Ethereum подвергнуться атаке 51%? {#pos-51-attack} + +Да. Доказательство доли владения уязвимо для атак 51%, так же как и доказательство работы. Вместо того чтобы требовать 51% хэш-мощности сети, злоумышленнику требуется 51% от общего количества поставленных ETH. Злоумышленник, накопивший 51% от общей доли, получает контроль над алгоритмом выбора форка. Это позволяет злоумышленнику цензурировать определенные транзакции, проводить краткосрочные реорганизации и извлекать MEV, переупорядочивая блоки в свою пользу. + +[Подробнее об атаках на доказательство доли владения](/developers/docs/consensus-mechanisms/pos/attack-and-defense) + +## Что такое социальная координация и зачем она нужна? {#what-is-social-coordination} + +Социальная координация — это последняя линия защиты для Ethereum, которая позволила бы восстановить честную цепь после атаки, финализировавшей нечестные блоки. В этом случае сообществу Ethereum пришлось бы координироваться «по внешним каналам» и договориться об использовании честного миноритарного форка, подвергнув при этом слэшингу валидаторов злоумышленника. Это также потребует от приложений и бирж признания честного форка. + +[Подробнее о социальной координации](/developers/docs/consensus-mechanisms/pos/attack-and-defense#people-the-last-line-of-defense) + +## Становятся ли богатые богаче при доказательстве доли владения? {#do-rich-get-richer} + +Чем больше ETH кто-то может поставить в стейкинг, тем больше валидаторов он может запустить и тем больше вознаграждений может получить. Вознаграждения масштабируются линейно с суммой поставленных ETH, и каждый получает одинаковый процентный доход. Доказательство работы обогащает богатых больше, чем доказательство доли владения, потому что более богатые майнеры, покупающие оборудование в больших масштабах, выигрывают от экономии на масштабе, что означает, что связь между богатством и вознаграждением нелинейна. + +## Является ли доказательство доли владения более централизованным, чем доказательство работы? {#is-pos-decentralized} + +Нет, доказательство работы стремится к централизации, потому что затраты на майнинг растут и вытесняют сначала отдельных лиц, затем небольшие компании и так далее. Текущая проблема с доказательством доли владения — это влияние деривативов ликвидного стейкинга (LSD). Это токены, представляющие ETH, поставленные некоторым провайдером, которые любой может обменять на вторичных рынках без фактического вывода ETH из стейкинга. LSD позволяют пользователям делать ставки менее чем на 32 ETH, но они также создают риск централизации, когда несколько крупных организаций могут в конечном итоге контролировать большую часть доли. Вот почему [соло-стейкинг](/staking/solo) — лучший вариант для Ethereum. + +[Подробнее о централизации долей в LSD](https://notes.ethereum.org/@djrtwo/risks-of-lsd) + +## Почему я могу ставить в стейкинг только ETH? {#why-can-i-only-stake-eth} + +ETH – это внутренняя валюта Ethereum. Крайне важно иметь единую валюту, в которой номинированы все доли, как для учета эффективных балансов для взвешивания голосов, так и для безопасности. Сам ETH является фундаментальным компонентом Ethereum, а не смарт-контрактом. Включение других валют значительно увеличило бы сложность и снизило бы безопасность стейкинга. + +## Является ли Ethereum единственным блокчейном с доказательством доли владения? {#is-ethereum-the-only-pos-blockchain} + +Нет, существует несколько блокчейнов с доказательством доли владения. Ни один из них не идентичен Ethereum; механизм доказательства доли владения Ethereum уникален. + +## Что такое слияние? {#what-is-the-merge} + +Слияние — это момент, когда Ethereum отключил свой механизм консенсуса на основе доказательства работы и включил механизм консенсуса на основе доказательства доли владения. Слияние произошло 15 сентября 2022 года. + +[Подробнее о Слиянии](/roadmap/merge) + +## Что такое жизнеспособность и безопасность? {#what-are-liveness-and-safety} + +Жизнеспособность и безопасность — это две фундаментальные проблемы безопасности для блокчейна. Жизнеспособность — это доступность финализирующей цепи. Если цепь перестает финализироваться или пользователи не могут легко получить к ней доступ, это сбои жизнеспособности. Чрезвычайно высокая стоимость доступа также может считаться сбоем жизнеспособности. Безопасность относится к тому, насколько сложно атаковать цепь, т. е. финализировать конфликтующие контрольные точки. + +[Читайте подробнее в документе Casper](https://arxiv.org/pdf/1710.09437.pdf) diff --git a/public/content/translations/ru/developers/docs/consensus-mechanisms/pos/gasper/index.md b/public/content/translations/ru/developers/docs/consensus-mechanisms/pos/gasper/index.md new file mode 100644 index 00000000000..fa2d2928168 --- /dev/null +++ b/public/content/translations/ru/developers/docs/consensus-mechanisms/pos/gasper/index.md @@ -0,0 +1,52 @@ +--- +title: Gasper +description: "Объяснение механизма доказательства владения Gasper." +lang: ru +--- + +Gasper — это комбинация гаджета Casper the Friendly Finality (Casper-FFG) и алгоритма выбора форка LMD-GHOST. Вместе эти компоненты формируют механизм консенсуса, обеспечивающий безопасность Ethereum с использованием доказательства владения. Casper — это механизм, который обновляет определенные блоки до "завершенных", чтобы новые участники сети могли быть уверены, что они синхронизируются с канонической цепочкой. Алгоритм выбора форка использует накопленные голоса, чтобы гарантировать, что узлы могут легко выбрать правильную цепочку, когда в блокчейне возникают форки. + +**Обратите внимание**, что первоначальное определение Casper-FFG было немного обновлено для включения в Gasper. На этой странице мы рассмотрим обновленную версию. + +## Прежде чем начать + +Чтобы понять этот материал, необходимо прочитать вводную страницу о [доказательстве владения](/developers/docs/consensus-mechanisms/pos/). + +## Роль Gasper {#role-of-gasper} + +Gasper находится на вершине блокчейна с доказательством владения, где узлы предоставляют эфир в качестве залога, который может быть уничтожен, если они бездействуют или действуют нечестно при предложении или проверке блоков. Gasper — это механизм, определяющий, как валидаторы получают вознаграждение или наказание, решают, какие блоки принимать или отклонять и на какой форк блокчейна опираться. + +## Что такое окончательность? {#what-is-finality} + +Окончательность — это свойство определенных блоков, которое означает, что эти блоки не могут быть отменены, если только не произошел критический сбой консенсуса и злоумышленник не уничтожил по крайней мере 1/3 от общего количества застейканного эфира. Завершенные блоки можно рассматривать как информацию, в отношении которой блокчейн уверен. Чтобы блок был признан окончательным, он должен пройти двухэтапную процедуру обновления: + +1. Валидаторы по крайней мере чем с двумя третями от общего количества застейканного эфира должны проголосовать за включение этого блока в каноническую цепочку. Это условие обновляет блок до "справедливого". Маловероятно, что справедливые блоки могут быть отменены, но при определенных условиях это возможно. +2. Когда другой блок становится справедливым поверх этого справедливого блока, последний обновляется до "окончательного". Обновление блока до окончательного — это обязательство включить блок в каноническую цепочку. Он не может быть отменен, если только злоумышленник не уничтожит миллионы эфиров (миллиарды $USD). + +Эти обновления блоков происходят не в каждой ячейке. Вместо этого справедливыми и окончательными могут быть только блоки, находящиеся на границе эпох. Эти блоки известны как "контрольные точки". При обновлении учитываются пары контрольных точек. Между двумя последовательными контрольными точками должна существовать «связь подавляющего большинства» (т. е. две трети от общего количества эфира в стейкинге проголосовали за то, что контрольная точка Б является правильным потомком контрольной точки А), чтобы обновить менее свежую контрольную точку до финализированной, а более свежий блок — до обоснованного. + +Поскольку для окончательности требуется согласие двух третей всего застейканного эфира о том, что блок является каноническим, злоумышленник не сможет создать альтернативную завершенную цепочку без: + +1. Владения двумя третями всего застейканного эфира или манипулирования ими. +2. Уничтожения по меньшей мере трети всего застейканного эфира. + +Первое условие возникает потому, что для завершения цепочки требуется две трети всего застейканного эфира. Второе условие возникает потому, что бы две трети от общего застейканного эфира проголосовали за два форка, то как минимум одна его треть должна была проголосовать сразу за оба. Двойное голосование — это наказуемое урезанием условие, от которого одна треть от общего количества застейканного эфира была бы уничтожена. На момент мая 2022 года для этого злоумышленнику потребуется сжечь эфира на сумму около 10 миллиардов долларов. Алгоритм, который обосновывает и финализирует блоки в Gasper, представляет собой немного измененную форму [Casper the Friendly Finality Gadget (Casper-FFG)](https://arxiv.org/pdf/1710.09437.pdf). + +### Стимулы и Tallant {#incentives-and-slashing} + +Валидаторы получают вознаграждение за честные предложение и проверку блоков. Они получают эфир, который добавляется к сумме их стейкинга. С другой стороны, валидаторы, которые отсутствуют и не действуют по требованию сети, пропускают эти вознаграждения и иногда теряют небольшую часть своих застейканных эфиров. Однако штрафы за пребывание в автономном режиме невелики и в большинстве случаев равны потерям от отсутствия вознаграждений. Однако некоторые действия валидатора очень трудно выполнить случайно и они указывают на какой-либо злой умысел, например, предложение нескольких блоков для одного в одной и той же ячейке, подтверждение нескольких блоков в одной и той же ячейке или противоречие предыдущим голосованиям за контрольные точки. Это "урезаемое" поведение, которое наказывается более сурово — наказание урезанием приводит к уничтожению некоторой части эфира в стейкинге валидатора и удалению валидатора из сети. Этот процесс занимает 36 дней. В первый день взимается первоначальный штраф в размере до 1 ETH. Затем эфир урезанного валидатора медленно расходуется в течение периода выхода, а на 18-й день он получает "штраф за корреляцию", который увеличивается, когда примерно в одно и то же время урезаются другие валидаторы. Максимальный штраф — это вся сумма валидатора в стейкинге. Эти вознаграждения и штрафы предназначены для стимулирования честных валидаторов и предотвращения атак на сеть. + +### Утечка из-за неактивности {#inactivity-leak} + +Помимо безопасности, Gasper также обеспечивает "убеждаемую живучесть". Это условие заключается в том, что до тех пор, пока две трети от общего количества застейканного эфира голосуют честно и следуют протоколу, цепочка сможет становиться окончательной независимо от любой другой активности (например, атак, проблем с задержкой или урезаний). Иными словами, одна треть от общего объема застейканного эфира должна быть каким-то образом скомпрометирована, чтобы предотвратить завершение становление цепочки окончательной. В Gasper существует дополнительная защита от сбоев в работе, известная как "утечка неактивности". Этот механизм активируется всякий раз, когда цепочка не становится окончательной в течение более, чем более четырех эпох. У валидаторов, которые активно не подтверждают цепочку большинства, постепенно уменьшается количество их застейканного эфира до тех пор, пока большинство не вернет себе две трети от общей доли, гарантируя, что сбои в работе будут лишь временными. + +### Выбор форка {#fork-choice} + +Первоначальное определение Casper-FFG включало алгоритм выбора форка, который устанавливал правило: `следовать за цепочкой, содержащей обоснованную контрольную точку с наибольшей высотой`, где высота определяется как наибольшее расстояние от генезис-блока. В Gasper оригинальное правило выбора форка устарело в пользу более сложного алгоритма под названием LMD-GHOST. Важно понимать, что при обычных условиях правило выбора форка не требуется: для каждой ячейки существует один предлагающий блок валидатор, а другие честные валидаторы подтверждают это. Только в случаях большой асинхронности сети или когда недобросовестный валидатор, предлагающий блок, дал двусмысленные показания, требуется алгоритм выбора форка. Однако, когда такие случаи действительно возникают, алгоритм выбора форка является критической защитой, которая гарантирует правильность цепочки. + +LMD-GHOST расшифровывается и дословно переводится как "движимое последним сообщением жадное самое тяжелое наблюдаемое поддерево". Это перегруженный жаргоном способ определения алгоритма, который выбирает ответвление с наибольшим накопленным весом подтверждений валидаторов в качестве канонического (жадное поддерево с наибольшим весом) и, если от валидатора получено несколько сообщений, учитывает только самое последнее (движимое последними сообщениями). Прежде чем добавить блок с наибольшим весом в свою каноническую цепочку, каждый валидатор оценивает каждый блок, используя это правило. + +## Дополнительные материалы {#further-reading} + +- [Gasper: Объединение GHOST и Casper](https://arxiv.org/pdf/2003.03052.pdf) +- [Casper the Friendly Finality Gadget](https://arxiv.org/pdf/1710.09437.pdf) diff --git a/public/content/translations/ru/developers/docs/consensus-mechanisms/pos/index.md b/public/content/translations/ru/developers/docs/consensus-mechanisms/pos/index.md index 874a35ef4ec..aca501e2e24 100644 --- a/public/content/translations/ru/developers/docs/consensus-mechanisms/pos/index.md +++ b/public/content/translations/ru/developers/docs/consensus-mechanisms/pos/index.md @@ -1,97 +1,99 @@ --- -title: Доказательство владения (PoS) -description: Объяснение протокола доказательства владения и его роли в Ethereum. +title: "Доказательство владения (PoS)" +description: "Пояснення протоколу консенсусу proof-of-work та його ролі в Ethereum." lang: ru -incomplete: true --- -Ethereum переходит к механизму консенсуса, называемому доказательством владения (Proof-of-Stake, PoS), с консенсуса [доказательства работы (Proof-of-Work, PoW)](/developers/docs/consensus-mechanisms/pow/). Этот переход планировался, поскольку он — ключевая часть стратегии сообщества по масштабированию Ethereum с помощью [обновлений](/roadmap/). Однако переход к PoS является более сложной технической задачей, чем использование относительного простого PoW для достижения консенсуса в сети. +Доказательство владения (PoS) лежит в основе [механизма консенсуса](/developers/docs/consensus-mechanisms/) Ethereum. В 2022 году Ethereum перешел на механизм доказательства владения, потому что он более безопасен, менее энергоемок и лучше подходит для реализации новых решений для масштабирования по сравнению с предыдущей архитектурой [доказательства работы](/developers/docs/consensus-mechanisms/pow). -## Прежде чем начать {#prerequisites} +## Предварительные условия {#prerequisites} -Чтобы лучше понять эту страницу, мы рекомендуем сначала ознакомиться с [механизмами консенсуса](/developers/docs/consensus-mechanisms/). +Чтобы лучше понять эту страницу, мы рекомендуем вам сначала ознакомиться с [механизмами консенсуса](/developers/docs/consensus-mechanisms/). ## Что такое доказательство владения (PoS)? {#what-is-pos} -Доказательство владения (proof-of-stake, PoS) — это [механизм консенсуса](/developers/docs/consensus-mechanisms/), используемый блокчейн-сетями для достижения консенсуса в распределенной системе. +Доказательство доли — это способ подтвердить, что валидаторы поставили на кон некоторую ценность, и сеть сможет уничтожить её, если они поведут себя нечестно. В доказательстве доли Ethereum валидаторы открыто замораживают в смарт-контракт свой ETH капитал. После этого валидатор является ответственным за проверку того, что новые блоки, распространяющиеся по сети, являются действительными, и время от времени создает и распространяет новые блоки сам. Если они попытаются обмануть сеть (например: предлагая несколько блоков, когда должны были отправить один, чтобы создать конфликты), некоторая часть их ETH из стейка может быть уничтожена. -PoS требует от пользователей вкладывать свои ETH, чтобы стать валидаторами в сети. Валидаторы несут ту же ответственность, что и майнеры в случае с [доказательством работы](/developers/docs/consensus-mechanisms/pow/): упорядочение транзакций и создание новых блоков, чтобы все узлы могли согласовать состояние сети. +## Валидаторы {#validators} -У доказательства владения есть много преимуществ по сравнению с доказательством работы: +Для участия в качестве валидатора пользователь должен вложить 32 ETH на депозитный контракт и запустить три отдельных компонента программного обеспечения: клиента выполнения, клиента консенсуса и клиента валидатора. При внесении своих ETH, пользователь присоединяется к очереди активации, которая ограничивает скорость присоединения новых валидаторов к сети. После активации валидаторы получают новые блоки от собратьев сети Ethereum. Транзакции в поступающем блоке выполняются повторно, чтобы проверить и убедиться, что предложенные изменения в текущее состояние Ethereum реальны, и подпись, принадлежащая блоку — проверена. Затем валидатор отправляет голос (называемый аттестацией) в пользу этого блока по всей сети. -- Выше энергоэффективность: не нужно использовать много энергии для майнинга блоков -- Ниже порог для входа, уменьшение требований к оборудованию: нет необходимости в дорогом оборудовании, чтобы иметь возможность создавать новые блоки -- Больше защита от централизации: доказательство владения должно увеличить количество узлов в сети -- Больше поддержка [цепей-осколков](/roadmap/danksharding/): ключевое улучшение для масштабирования сети Ethereum +В то время как в proof-of-work время создания блоков определяется сложностью майнинга, в proof-of-stake темп фиксирован. Время в Ethereum с протоколом proof-of-stake разделено на слоты (12 секунд) и эпохи (32 слота). В каждом слоте случайным образом выбирается один валидатор, предлагающий блок. Этот валидатор отвечает за создание нового блока и отправку его другим узлам сети. Также в каждом слоте случайно выбирается комитет валидаторов, чьи голоса используются для определения правильности предложенного блока. Разделение валидаторов на подгруппы (комитеты) важно, чтобы нагрузка на сеть была распределённой и легко управляемой. Комитеты разделяют валидаторов так, чтобы каждый активный валидатор поучаствовал в верификации каждой эпохи, но не каждого слота. -## Доказательство владения, стейкинг и валидаторы {#pos-staking-validators} +## Как выполняется транзакция в Ethereum PoS {#transaction-execution-ethereum-pos} -Доказательство владения является базовым механизмом, который дает возможность стать валидатором при достаточном залоге. В Ethereum пользователи должны заложить 32 ETH, чтобы стать валидаторами. Валидаторы выбираются случайным образом для создания блоков и отвечают за проверку и подтверждение блоков, которые они не создавали. В качестве стимула для правильной проверки также используется залог пользователей. Например, пользователь может потерять часть своего залога, если будет вне сети (поскольку не сможет выполнять свою функцию — подтверждение блоков), или даже весь залог из-за преднамеренного сговора. +Ниже приводится подробное объяснение того, как выполняется транзакция в Ethereum proof-of-stake. -## Как работает доказательство владения в сети Ethereum? {#how-does-pos-work} +1. Пользователь создает и подписывает [транзакцию](/developers/docs/transactions/) своим закрытым ключом. Обычно это обрабатывается кошельком или библиотекой, такой как [ethers.js](https://docs.ethers.org/v6/), [web3js](https://docs.web3js.org/), [web3py](https://web3py.readthedocs.io/en/v5/) и т. д., но под капотом пользователь делает запрос к узлу, используя Ethereum [JSON-RPC API](/developers/docs/apis/json-rpc/). Пользователь определяет сумму газа, которую он готов заплатить, как чаевые контролёру для поощрения его за включение транзакции в блок. [Чаевые](/developers/docs/gas/#priority-fee) выплачиваются валидатору, а [базовая комиссия](/developers/docs/gas/#base-fee) сжигается. +2. Транзакция отправляется [клиенту-исполнителю](/developers/docs/nodes-and-clients/#execution-client) Ethereum, который проверяет ее действительность. Это означает, что отправитель имеет достаточно ETH для выполнения транзакции, и он подписал ее правильным ключом. +3. Если транзакция достоверна, клиент-исполнитель добавляет ее в свой локальный пул памяти (список ожидающих транзакций) и передает ее другим узлам через сеть сплетен уровня выполнения. Когда другие узлы слышат о транзакции, они также добавляют ее в свои локальные пулы памяти. Продвинутые пользователи могут воздержаться от трансляции своей транзакции и вместо этого направить ее специализированным сборщикам блоков, таким как [Flashbots Auction](https://docs.flashbots.net/flashbots-auction/overview). Это позволяет им организовывать транзакции в предстоящих блоках для получения максимальной прибыли ([MEV](/developers/docs/mev/#mev-extraction)). +4. . Этот узел отвечает за построение и трансляцию следующего блока, который должен быть добавлен в блокчейн Ethereum, и обновление глобального состояния. Узел состоит из трех частей: клиент-исполнитель, консенсус-клиент и клиент-валидатор. Клиент-исполнитель объединяет транзакции из локального пула памяти в "полезную нагрузку для выполнения" и выполняет их локально, чтобы сгенерировать изменение состояния. Эта информация передается клиенту соглашения, где полезная нагрузка для исполнения упаковывается, как часть "блока маяка", который также содержит информацию о вознаграждениях, штрафах, сокращениях, аттестации и так далее, что позволяет сети согласовывать последовательность блоков в начале цепи. Связь между клиентами-исполнителями и клиентами консенсуса более подробно описана в разделе [Подключение клиентов консенсуса и клиентов-исполнителей](/developers/docs/networking-layer/#connecting-clients). +5. Другие узлы получают новые блоки маяков в сети сплетен на уровне консенсуса. Они передают его клиенту исполнения, где транзакции повторно выполняются локально, чтобы убедиться, что предлагаемое изменение состояния является действительным. Затем клиент-валидатор подтверждает, что блок действителен и является логическим следующим блоком в его представлении цепочки (это означает, что он построен на цепочке с наибольшим весом аттестаций, как определено в [правилах выбора форка](/developers/docs/consensus-mechanisms/pos/#fork-choice)). Блок добавляется в локальную базу данных каждого узла, который это подтверждает. +6. Транзакция считается «финализированной», если она становится частью сети в «связи с супербольшинством» между двумя чекпоинтами. Чекпоинты появляются в начале каждой эпохи и существуют для учёта того, что: только часть активных валидаторов утверждает каждый слот, и что все активные валидаторы поучаствовали в утверждении каждой эпохи. «Связь супербольшинства» раскрывается только между эпохами, чтобы убедиться, что 66% всех застейканных ETH в сети согласились с состоянием двух чекпоинтов. -В отличие от доказательства работы валидатору в системе с доказательством владения не нужны большие вычислительные мощности, поскольку валидаторы, проверяющие очередной блок, выбираются случайно и между собой не конкурируют. Валидатор не добывает блок, а просто создает его, если он (случайно) был выбран проверяющим, в противном случае он проверяет созданный другим валидатором блок. Данная проверка называется аттестацией. Аттестация означает, что валидатор подтверждает правильность блока. Валидаторы получают вознаграждение за предложение новых блоков и за аттестацию прошлых. +Более подробную информацию о завершенности можно найти ниже. -За аттестацию неправильных, злонамеренных блоков вы будете терять свой залог. +## Финальность {#finality} -### Beacon Chain {#the-beacon-chain} +В распределённых сетях транзакция считается «финализированной», когда она становится частью блока, который не может быть изменён без сжигания большого количества ETH. В Ethereum proof-of-stake управляется с использованием "контрольных точек" блоков. Первый блок в кажой эпохе является контрольной точкой. Валидаторы голосуют за пары контрольных точек, которые они считают действительными. Если пара контрольных точек набирает голоса, представляющие по крайней мере две трети всего поставленного ETH, контрольные точки обновлены. Более новые из двух (целевого назначения) становятся "оправданными". Ранние две уже оправданы, потому что они были целью в предыдущей эпохе. Теперь он обновлен до "завершено". Этот процесс обновления контрольных точек обрабатывается **[Casper the Friendly Finality Gadget (Casper-FFG)](https://arxiv.org/pdf/1710.09437)**. Casper-FFG — это инструмент консенсуса для финализации блоков. После финализации блок не может быть отменен или изменен без слэшинга большинства дольщиков, что делает это экономически невыгодным. -При замене доказательства работы на доказательство владения возникнет дополнительная сложность с [цепочками осколков](/roadmap/danksharding/). Это отдельные блокчейны, которым тоже нужны валидаторы для обработки транзакций и создания новых блоков. План состоит в том, чтоб будет 64 цепочки осколков, и у них у всех должно быть единое понимание состояния сети. В результате необходима дополнительная координация, которую будет выполнять [Beacon Chain](/roadmap/beacon-chain/). +Для отмены завершенного блока, атакующий должен взять на себя обязательство лишиться как минимум одной трети от всего общего объема поставленного ETH. Точная причина этого объясняется в этой [статье блога Ethereum Foundation](https://blog.ethereum.org/2016/05/09/on-settlement-finality/). Поскольку завершение требует большинства в две трети, злоумышленник может помешать сети достичь завершенности путем голосования за одну треть общей доли. Для защиты от этого существует механизм: [утечка неактивности](https://eth2book.info/bellatrix/part2/incentives/inactivity). Он включается всякий раз, когда цепочка терпит неудачу в завершении в течение более, чем четырех эпох. Бездействие постепенно расходует заложенный ETH валидаторов, которые голосуют против большинства голосов, в результате чего большинство валидаторов восстанавливают большинство в две трети голосов и завершают цепочку. -Сеть Beacon Chain получает информацию о состоянии осколков и делает ее доступной для других цепочек осколков, чтобы сеть могла оставаться синхронизированной. Сеть Beacon также будет управлять валидаторами, начиная с регистрации поставленных ими депозитов до выдачи наград и штрафных санкций. +## Криптоэкономическая безопасность {#crypto-economic-security} -Вот как это все работает. +Запуск валидатора является обязательством. Ожидается, что валидатор будет поддерживать достаточное оборудование и возможность подключения для участия в проверке блоков и предложения. Взамен валидатору выплачивается ETH (их поставленный баланс увеличивается). С другой стороны, участие в качестве валидатора также открывает для пользователей новые возможности для атаки сети ради личной выгоды или саботажа. Для предотвращения этого валидаторы пренебрегают ETH вознаграждениями, если они не участвуют, когда их вызывают, и их существующая ставка может быть ликвидирована, если они ведут себя нечестно. Два основных поступка могут считаться нечестными: предложение нескольких блоков в одном слоте (раздвоение) и подтверждение противоречивых доказательств. -### Как происходит проверка {#how-does-validation-work} +Количество ETH сокращается, в зависимости от того, как много валидаторов также сокращается примерно в то же время. Это известно как [«штраф за корреляцию»](https://eth2book.info/bellatrix/part2/incentives/slashing#the-correlation-penalty), и он может быть незначительным (~1 % доли для одного валидатора, подвергшегося слэшингу в одиночку) или может привести к уничтожению 100 % доли валидатора (событие массового слэшинга). Он навязывается в середине периода принудительного выхода, который начинается с немедленного штрафа (до 1 ETH) в первый день, и заканчивается изгнанием из сети на тридцать шестой день. Они получают незначительные штрафные санкции каждый день, потому что находятся в сети, но не голосуют. Все это означает, что скоординированная атака обойдется злоумышленнику очень дорого. -Когда вы отправляете транзакцию в осколок, за добавление вашей транзакции в блок осколка будет отвечать валидатор. Валидаторы для предложения новых блоков выбираются алгоритмически сетью Beacon. +## Выбор форка {#fork-choice} -#### Аттестация {#attestation} +Когда сеть работает оптимально и честно, во главе цепочки всегда находится только один новый блок, и все валидаторы подтверждают это. Однако, возможно, что валидаторы имеют разные взгляды на главу цепочки из-за задержки в сети или потому, что предложивший блок был двусмысленен. Таким образом, консенсусным клиентам нужен алгоритм, чтобы решить, кому из них отдать предпочтение. Алгоритм, используемый в Ethereum с доказательством владения, называется [LMD-GHOST](https://arxiv.org/pdf/2003.03052.pdf) и работает путем определения форка, который имеет наибольший вес аттестаций в своей истории. -Если валидатор не выбран для предложения нового блока осколка, он должен аттестовать предложение другого валидатора. Это аттестация, записанная в сети Beacon, а не в самой транзакции. - -Для аттестации каждого блока осколка требуется не менее 128 валидаторов. Это называется «комитетом». - -У комитета есть срок, в который он должен предложить и утвердить блок осколка. Это называется «ячейкой». На одну ячейку создается только один действителньй блок, а 32 ячейки составляют «эпоху». После каждой эпохи, комитет распускается и пересоздается с участием различных случайных участников. Это помогает сохранить осколки в безопасности от комитетов из недобросовестных пользователей. - -#### Кросс-ссылки {#rewards-and-penalties} - -Как только предложение о новом блоке осколка получит достаточно аттестаций, создается «кросс-ссылка», которая подтверждает включение блока и вашей транзакции в сеть Beacon Chain. - -Как только появится перекрестная ссылка, валидатор, предложивший блок, получает свою награду. +## Доказательство владения и безопасность {#pos-and-security} -#### Финальность {#finality} +Угроза [атаки 51 %](https://www.investopedia.com/terms/1/51-attack.asp) по-прежнему существует при использовании доказательства владения, как и при доказательстве работы, но для злоумышленников она еще более рискованна. Атакующему потребуется 51% поставленного ETH. Затем они могут использовать свое собственное одобрение, чтобы убедиться, что их предпочтительная вилка имеет наибольшее количество накопленных утверждений. 'Вес' накопленных подтверждений - это то, что консенсусные клиенты используют для определения правильной цепочки, итак, этот злоумышленник сможет сделать свою вилку канонической. Однако, сила proof-of-stake над proof-of-work в том, что сообщество имеет гибкие возможности в организации контратаки. Например, честные валидаторы могли бы принять решение о продолжении стройки по меньшей цепочке и игнорировать ветку злоумышленника, пока поощряющие приложения, биржи, и пулы выполняют то же самое. Они могут также решить принудительно удалить атакующего из сети и ликвидировать поставленный им ETH. Это сильная экономическая защита от атаки 51%. -В распределенных сетях транзакция, которая является частью блока, является «финальной», потому что блок уже не может измениться. +: -Чтобы добиться этого в системе с доказательством владения, Casper, протокол финальности, заставляет валидаторов согласовывать стоятояние блока в определенных точках. Как только 2/3 валидаторов придут к согласию, блок становится окончательным и завершенным. Валидаторы потеряют все свои залоги, если попробуют это исправить позже с помощью атаки 51 %. +- атаки на дальние дистанции (хотя гаджет финальности нейтрализует этот вектор атаки) +- «короткие реорганизации (риорги)»\*\* (хотя механизмы proposer boosting и дедлайны аттестаций смягчают эту проблему). +- russian +- лавинные атаки (нейтрализуются правилом алгоритмов выбора вилки, рассматривающих только последнее сообщение) -Как сказал Влад Замфир, это работает так же, как в случае с майнером, участвовавшим в атаке 51 %: его добыча немедленно сгорает. +В целом, доказательство доли, как оно реализовано в Ethereum, было продемонстрировано как более экономически безопасное, чем доказательство работы. -## Доказательство владения и безопасность {#pos-and-security} +## Преимущества и недостатки {#pros-and-cons} -Угроза [атаки 51 %](https://www.investopedia.com/terms/1/51-attack.asp) в системе с доказательством владения остается, но для злоумышленников она несет еще больше рисков. Чтобы сделать это, вам нужно контролировать 51 % заложенных ETH. Это очень большая сумма денег, и ее контроль мог бы вызвать падение стоимости ETH. Существует мало причин, по которым вы захотите обвалить стоимость валюты, на большое количество которой вы претендуете. Есть куда более весомые стимулы для обеспечения безопасности сети и ее рабочего состояния. +| Преимущества | Недостатки | +| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | +| Стакинг облегчает участие отдельных лиц в обеспечении безопасности сети, способствуя децентрализации. узел валидатора может быть запущен на обычном ноутбуке. Ставочные пулы позволяют пользователям делать ставки, не имея 32 ETH. | Proof-of-stake является более молодым и менее испытанным в боях по сравнению с proof-of-work | +| Стейкинг более децентрализован. Экономия от масштаба не действует так же, как при добыче PoW. | Proof-of-stake сложнее в реализации, чем proof-of-work | +| Proof-of-stake обеспечивает большую крипто-экономическую безопасность, чем proof-of-work | Для участия в доказательстве доли Ethereum пользователям необходимо запустить три части программного обеспечения. | +| Для стимулирования участников сети требуется уменьшить выпуск нового ETH | | -Разделение доли, «выбрасывание» и другие санкции, координируемые сетью Beacon, призваны предотвращать недобросовестное поведение. Валидаторы также будут отвечать за помечание таких инцидентов. +### Сравнение с доказательством работы {#comparison-to-proof-of-work} -## Преимущества и недостатки {#pros-and-cons} +Ethereum изначально использовал доказательство работоспособности, но переключился на доказательство доли владения в Сентябре 2022. PoS обладает некоторыми преимуществами над PoW, такими как: -| Преимущества | Минусы | -| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | -| Стейкинг облегчает запуск узла. Это не требует крупных инвестиций в оборудование или электроэнергию, и вы можете присоединиться к стейкинговым пулам, если у вас недостаточно ETH для стейкинга. | Доказательство владения все еще находится на стадии развития и прошло гораздо меньше испытаний, чем доказательство работы. | -| Стейкинг более децентрализован. Он позволяет увеличивать количество узлов без процентного увеличения прибыли, как в случае с майнингом. | | -| Стейкинг обеспечивает безопасный шардинг. Цепочки осколков позволяют Ethereum создавать одновременно несколько блоков, что увеличивает пропускную способность транзакций. Шардинг сети в системе с доказательством работы просто уменьшил бы мощность, необходимую для взлома части сети. | | +- повышение энергоэффективности - нет необходимости использовать много энергии на вычисления proof-of-work +- ниже порог для входа, уменьшение требований к оборудованию - нет необходимости в дорогом оборудовании, чтобы иметь шанс на создание новых блоков +- снижение риска централизации - proof-of-stake должен привести к увеличению числа узлов, обеспечивающих безопасность сети +- в связи со снижением энергопотребления необходимо выпускать меньше ETH для стимулирования участия +- штрафы за нечестное поведение делают атаки 51% более дорогостоящими для атакующего, в сравнении с доказательством работы +- сообщество может обратиться к социальному восстановлению честной цепочки, если атака 51% преодолеет криптоэкономическую защиту. -## Дополнительные ресурсы {#further-reading} +## Дополнительные материалы {#further-reading} -- [Доказательство владения: часто задаваемые вопросы](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html) — _Виталик Бутерин_ -- [Что такое доказательство владения](https://consensys.net/blog/blockchain-explained/what-is-proof-of-stake/) — _ConsenSys_ -- [Что такое доказательство владения и почему это важно](https://bitcoinmagazine.com/culture/what-proof-of-stake-is-and-why-it-matters-1377531463) — _Виталик Бутерин_ -- [Объяснение сети Beacon Chain Ethereum 2.0, которое вам нужно прочитать в первую очередь](https://ethos.dev/beacon-chain/) — _Ethos.dev_ -- [Почему именно доказательство владения (ноябрь 2020 г.)](https://vitalik.eth.limo/general/2020/11/06/pos2020.html) — _Виталик Бутерин_ -- [Доказательство владения: как я научился любить слабую субъективность (Weak Subjectivity)](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) — _Виталик Бутерин_ -- [Философия дизайна доказательства владения](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) — _Виталик Бутерин_ +- [FAQ по доказательству владения](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html) _Виталик Бутерин_ +- [Что такое доказательство владения](https://consensys.net/blog/blockchain-explained/what-is-proof-of-stake/) _ConsenSys_ +- [Что такое доказательство владения и почему это важно](https://bitcoinmagazine.com/culture/what-proof-of-stake-is-and-why-it-matters-1377531463) _Виталик Бутерин_ +- [Почему доказательство владения (ноябрь 2020 г.)](https://vitalik.eth.limo/general/2020/11/06/pos2020.html) _Виталик Бутерин_ +- [Доказательство владения: как я полюбил слабую субъективность](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) _Виталик Бутерин_ +- [Атака и защита Ethereum на основе доказательства владения](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs) +- [Философия дизайна доказательства владения](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) _Виталик Бутерин_ +- [Видео: Виталик Бутерин объясняет Лексу Фридману, что такое доказательство владения](https://www.youtube.com/watch?v=3yrqBG-7EVE) -## Похожие темы {#related-topics} +## Смежные темы {#related-topics} -- [Доказательство работы (PoW)](/developers/docs/consensus-mechanisms/pow/) +- [Доказательство работы](/developers/docs/consensus-mechanisms/pow/) +- [Доказательство полномочий](/developers/docs/consensus-mechanisms/poa/) diff --git a/public/content/translations/ru/developers/docs/consensus-mechanisms/pos/keys/index.md b/public/content/translations/ru/developers/docs/consensus-mechanisms/pos/keys/index.md new file mode 100644 index 00000000000..b47de59fbf6 --- /dev/null +++ b/public/content/translations/ru/developers/docs/consensus-mechanisms/pos/keys/index.md @@ -0,0 +1,100 @@ +--- +title: "Ключи в Эфириум с доказательством владения" +description: "Объяснение ключей, используемых в механизме консенсуса доказательстве владения в Эфириум" +lang: ru +--- + +Ethereum защищает пользовательские активы с помощью криптографии с открытым и закрытым ключами. Публичный ключ используется в качестве основы для адреса Эфириум, то есть он виден широкой публике и используется в качестве уникального идентификатора. Приватный (или "секретный") ключ должен быть доступен только владельцу аккаунта. Приватный ключ используется для "подписи" транзакций и данных, чтобы криптографически можно было доказать, что владелец аккаунта одобряет какое-либо действие определенного приватного ключа. + +Ключи Ethereum генерируются с использованием [криптографии на эллиптических кривых](https://en.wikipedia.org/wiki/Elliptic-curve_cryptography). + +Однако когда Ethereum перешел с [доказательства работы](/developers/docs/consensus-mechanisms/pow) на [доказательство владения](/developers/docs/consensus-mechanisms/pos), в Ethereum был добавлен новый тип ключа. Первоначальные ключи по-прежнему работают точно так же, как и раньше — не было никаких изменений для ключей на основе эллиптических кривых, защищающих аккаунты. Однако пользователям требовался ключ нового типа для участия в доказательстве владения путем стейкинга ETH и запуска валидаторов. Эта потребность возникла из-за проблем с масштабируемостью, связанных с передачей большого количества сообщений между большим числом валидаторов, что требовало криптографического метода, который можно было бы легко агрегировать, чтобы уменьшить объем обмена данными, необходимый сети для достижения консенсуса. + +Этот новый тип ключа использует схему подписи [**Boneh-Lynn-Shacham (BLS)**](https://wikipedia.org/wiki/BLS_digital_signature). BLS обеспечивает очень эффективную агрегацию подписей, но также допускает извлечение отдельных агрегированных ключей валидаторов и идеально подходит для управления действиями между валидаторами. + +## Два типа ключей валидатора {#two-types-of-keys} + +До перехода на доказательство владения у пользователей Эфириум был только один закрытый ключ на основе эллиптической кривой для доступа к своим средствам. С введением доказательства владения пользователям, которые хотели стать соло-стейкерами, также требовались **ключ валидатора** и **ключ для вывода средств**. + +### Ключ валидатора {#validator-key} + +Ключ подписи валидатора состоит из двух элементов: + +- **Приватный** ключ валидатора +- **Публичный** ключ валидатора + +Назначение приватного ключа валидатора — подписывать он-чейн операции, такие как предложения блоков и аттестации. В связи с этим эти ключи должны храниться в горячем кошельке. + +Преимущество такой гибкости заключается в том, что ключи подписи валидатора можно очень быстро перемещать с одного устройства на другое, однако, если они потеряны или украдены, вор может **действовать злонамеренно** несколькими способами: + +- Добиться урезания валидатора: + - Будучи предлагающим блок, подписать два разных блока beacon для одной и той же ячейки + - Будучи аттестатором, подписать аттестацию, которая "окружает" другую + - Будучи аттестатором, подписать две разные аттестации, имеющие одну и ту же цель +- Сделать добровольный выход, который выводит валидатора из стейкинга и предоставляет доступ к его балансу ETH владельцу ключа вывода средств + +**Публичный ключ валидатора** включается в данные транзакции, когда пользователь вносит ETH в депозитный контракт стейкинга. Эти данные известны как _данные о депозите_ и позволяют Ethereum идентифицировать валидатора. + +### Учетные данные для вывода средств {#withdrawal-credentials} + +Каждый валидатор имеет свойство, известное как _учетные данные для вывода средств_. Это 32-байтное поле начинается либо с `0x00`, представляющего учетные данные для вывода средств BLS, либо с `0x01`, представляющего учетные данные, указывающие на адрес исполнения. + +Валидаторы с `0x00` BLS-ключами должны обновить эти учетные данные, чтобы они указывали на адрес исполнения, для активации выплат избыточного баланса или полного вывода средств из стейкинга. Это можно сделать, указав адрес исполнения в данных депозита во время первоначальной генерации ключа, _ИЛИ_ использовав ключ для вывода средств позже для подписи и трансляции сообщения `BLSToExecutionChange`. + +### Ключ для вывода средств {#withdrawal-key} + +Ключ вывода средств потребуется для обновления данных для вывода средств, чтобы указать адрес для выполнения, если он не был задан при первоначальном депозите. Это позволит начать обработку платежей с избыточным балансом, а также позволит пользователям полностью вывести свои зайстейканные ETH. + +Как и ключи валидаторов, ключи для вывода средств также состоят из двух компонентов: + +- **Приватный** ключ для вывода средств +- **Публичный** ключ для вывода средств + +Потеря этого ключа до обновления учетных данных для вывода средств до типа `0x01` означает потерю доступа к балансу валидатора. Валидатор по-прежнему может подписывать аттестации и блоки, поскольку для этих действий требуется закрытый ключ валидатора, однако в случае утери ключей для снятия средств стимул к этому отсутствует. + +Отделение ключей валидатора от ключей аккаунта Эфириум позволяет одному пользователю запускать несколько валидаторов. + +![схема ключей валидатора](validator-key-schematic.png) + +**Примечание**: Выход из стейкинга и вывод баланса валидатора в настоящее время требуют подписания [сообщения о добровольном выходе (VEM)](https://mirror.xyz/ladislaus.eth/wmoBbUBes2Wp1_6DvP6slPabkyujSU7MZOFOC3QpErs&1) с помощью ключа валидатора. Однако [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002) — это предложение, которое в будущем позволит пользователю инициировать выход валидатора и вывести его баланс путем подписания сообщений о выходе с помощью ключа для вывода средств. Это снизит требования к доверию, позволив стейкерам, делегирующим ETH [поставщикам услуг стейкинга](/staking/saas/#what-is-staking-as-a-service), сохранять контроль над своими средствами. + +## Получение ключей из кодовой фразы {#deriving-keys-from-seed} + +Если бы для каждых застейканных 32 ETH требовался новый набор из 2 полностью независимых ключей, управление ключами быстро стало бы громоздким, особенно для пользователей, у которых запущено несколько валидаторов. Вместо этого несколько ключей валидатора могут быть получены из одной общей сид-фразы, и хранение этой единственной сид-фразы обеспечивает доступ к нескольким ключам валидатора. + +[Мнемоники](https://en.bitcoinwiki.org/wiki/Mnemonic_phrase) и пути — это важные функции, с которыми пользователи часто сталкиваются при [доступе](https://ethereum.stackexchange.com/questions/19055/what-is-the-difference-between-m-44-60-0-0-and-m-44-60-0) к своим кошелькам. Мнемоническая фраза — это последовательность слов, которые действуют как сид для закрытого ключа. В сочетании с дополнительными данными мнемоническая фраза генерирует хэш, известный как "мастер-ключ". Это можно рассматривать как корень дерева. Ветви от этого корня затем могут быть получены с использованием иерархического пути, так что дочерние узлы могут существовать как комбинации хеша их родительского узла и их индекса в дереве. Прочтите о стандартах [BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) и [BIP-19](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) для генерации ключей на основе мнемоники. + +Эти пути имеют следующую структуру, которая будет знакома пользователям, взаимодействовавшим с аппаратными кошельками: + +``` +m/44'/60'/0'/0` +``` + +Косые черты в этом пути разделяют компоненты приватного ключа следующим образом: + +``` +master_key / purpose / coin_type / account / change / address_index +``` + +Эта логика позволяет пользователям присоединять как можно больше валидаторов к одной **мнемонической фразе**, поскольку корень дерева может быть общим, а различие может происходить на уровне ветвей. Пользователь может **получить любое количество ключей** из мнемонической фразы. + +``` + [m / 0] + / + / +[m] - [m / 1] + \ + \ + [m / 2] +``` + +Каждая ветвь разделена символом `/`, поэтому `m/2` означает, что нужно начать с мастер-ключа и следовать по ветви 2. На приведенной ниже схеме одна мнемоническая фраза используется для хранения трех ключей вывода средств, каждый из которых имеет два связанных валидатора. + +![логика ключей валидатора](multiple-keys.png) + +## Дополнительные материалы {#further-reading} + +- [Запись в блоге Ethereum Foundation от Карла Бекхейзена](https://blog.ethereum.org/2020/05/21/keys/) +- [EIP-2333: генерация ключей BLS12-381](https://eips.ethereum.org/EIPS/eip-2333) +- [EIP-7002: выходы, инициируемые на уровне исполнения](https://web.archive.org/web/20250125035123/https://research.2077.xyz/eip-7002-unpacking-improvements-to-staking-ux-post-merge) +- [Масштабное управление ключами](https://docs.ethstaker.cc/ethstaker-knowledge-base/scaled-node-operators/key-management-at-scale) diff --git a/public/content/translations/ru/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md b/public/content/translations/ru/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md new file mode 100644 index 00000000000..078e6611964 --- /dev/null +++ b/public/content/translations/ru/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md @@ -0,0 +1,69 @@ +--- +title: "Proof-of-stake против proof-of-work" +description: "Сравнение между механизмом консенсуса proof-of-stake и proof-of-work в сети Ethereum" +lang: ru +--- + +Когда Ethereum был запущен, механизм доказательства владения (proof-of-stake) все еще требовал большого количества исследований и разработок, прежде чем ему можно было доверить обеспечение безопасности Ethereum. Механизм доказательства работы (proof-of-work) был более простым механизмом, который уже был проверен биткоином. Это означало, что основные разработчики могли немедленно реализовать его для запуска Ethereum. Потребовалось еще восемь лет, чтобы довести механизм доказательства владения (proof-of-stake) до такого состояния, чтобы его можно было реализовать. + +На этой странице объясняются причины перехода Ethereum с механизма доказательства работы (proof-of-work) на механизм доказательства владения (proof-of-stake), а также связанные с этим компромиссы. + +## Безопасность {#security} + +Исследователи Ethereum считают механизм proof-of-stake более безопасным, чем proof-of-work. Однако, он совсем недавно был внедрён в основную сеть Ethereum и не прошел достаточную проверку временем, как proof-of-work. В этом разделе рассматриваются плюсы и минусы модели безопасности механизма proof-of-stake по сравнению с proof-of-work. + +### Стоимость атаки {#cost-to-attack} + +При proof-of-stake, валидаторы обязаны задепонировать ("застейкать") как минимум 32 ETH в смарт-контракте. Сеть Ethereum оставляет за собой право уничтожить застейканый эфир, чтобы наказать валидаторов за несоблюдение правил. Чтобы добиться консенсуса, как минимум 66% от всего застейканого эфира должны проголосовать за определённый набор блоков. Блоки, за которые проголосовали >=66% от общей доли, становятся "финализированными", то есть их нельзя удалить или реорганизовать. + +Атака на сеть может означать предотвращение финализации цепочки или обеспечение определенной организации блоков в канонической цепи, что каким-то образом выгодно атакующему. Для этого злоумышленнику необходимо отклонить путь честного консенсуса либо путем накопления большого количества эфира и прямого голосования с его помощью, либо обманом заставить честных валидаторов проголосовать определенным образом. Помимо сложных, маловероятных атак, которые обманывают честных валидаторов, стоимость атаки на Ethereum — это стоимость доли, которую злоумышленник должен накопить, чтобы повлиять на консенсус в свою пользу. + +Минимальная стоимость атаки составляет >33% от общей доли. Злоумышленник, владеющий >33% от общей доли, может вызвать задержку финализации, просто отключившись от сети. Это относительно незначительная проблема для сети, поскольку существует механизм, известный как "утечка из-за неактивности", который выводит долю из оффлайн-валидаторов до тех пор, пока онлайн-большинство не будет составлять 66% доли и не сможет снова финализировать цепочку. Теоретически также возможно, что злоумышленник вызовет двойную финализацию, имея чуть более 33% от общей доли, создав два блока вместо одного, когда его попросят стать производителем блока, а затем дважды проголосовав всеми своими валидаторами. Каждый форк требует, чтобы 50% оставшихся честных валидаторов сначала увидели каждый блок, поэтому, если им удастся правильно рассчитать время отправки своих сообщений, они смогут финализировать оба форка. Вероятность успеха этого мала, но если бы злоумышленник смог вызвать двойную финализацию, сообществу Ethereum пришлось бы решить, какому форку следовать, и в этом случае валидаторы злоумышленника обязательно были бы подвергнуты слэшингу на другом форке. + +Имея >33% от общей доли, злоумышленник имеет шанс оказать незначительное (задержка финализации) или более серьезное (двойная финализация) влияние на сеть Ethereum. При наличии более 14 000 000 ETH в стейкинге в сети и репрезентативной цене 1000 долларов США за ETH минимальная стоимость проведения этих атак составляет `1000 x 14 000 000 x 0,33 = 4 620 000 000 долларов США`. Злоумышленник потеряет эти деньги в результате слэшинга и будет исключен из сети. Чтобы атаковать снова, им придется (снова) накопить >33% доли и (снова) сжечь ее. Каждая попытка атаки на сеть будет стоить >4,6 миллиарда долларов (при цене 1000 долларов за ETH и 14 млн ETH в стейкинге). Злоумышленник также исключается из сети, когда его валидаторы подвергаются слэшингу, и для повторного присоединения он должен встать в очередь активации. Это означает, что скорость повторной атаки ограничивается не только скоростью, с которой злоумышленник может накопить >33% от общей доли, но и временем, которое требуется для подключения всех его валидаторов к сети. Каждый раз, когда злоумышленник атакует, он становится намного беднее, а остальная часть сообщества становится богаче благодаря возникающему шоку предложения. + +Другие атаки, такие как атаки 51% или отмена финализации с 66% общей доли, требуют значительно больше ETH и являются гораздо более дорогостоящими для злоумышленника. + +Сравните это с механизмом доказательства работы. Стоимость атаки на Ethereum с механизмом доказательства работы (proof-of-work) была равна стоимости постоянного владения >50% общего хешрейта сети. Это сводилось к затратам на оборудование и эксплуатационным расходам на достаточную вычислительную мощность, чтобы постоянно опережать других майнеров в вычислении решений для доказательства работы. Ethereum в основном майнился с использованием GPU, а не ASIC, что снижало затраты (хотя, если бы Ethereum остался на механизме доказательства работы, майнинг на ASIC мог бы стать более популярным). Злоумышленнику пришлось бы приобрести много оборудования и оплатить электроэнергию для его работы, чтобы атаковать сеть Ethereum на основе механизма доказательства работы, но общая стоимость была бы меньше, чем стоимость, необходимая для накопления достаточного количества ETH для начала атаки. Атака 51% на ~[20 раз дешевле](https://youtu.be/1m12zgJ42dI?t=1562) при использовании механизма доказательства работы (proof-of-work), чем при использовании механизма доказательства владения (proof-of-stake). Если бы атака была обнаружена, а в цепи был проведен хардфорк для удаления внесенных изменений, злоумышленник мог бы многократно использовать то же самое оборудование для атаки на новый форк. + +### Сложность {#complexity} + +Механизм доказательства владения (proof-of-stake) намного сложнее, чем механизм доказательства работы (proof-of-work). Это можно считать аргументом в пользу механизма доказательства работы (proof-of-work), поскольку в более простые протоколы сложнее случайно внести ошибки или непреднамеренные эффекты. Однако сложность была преодолена благодаря многолетним исследованиям и разработкам, симуляциям и внедрениям в тестовых сетях. Протокол доказательства владения (proof-of-stake) был независимо реализован пятью отдельными командами (на каждом из уровней исполнения и консенсуса) на пяти языках программирования, что обеспечивает устойчивость к ошибкам клиентов. + +Для безопасной разработки и тестирования логики консенсуса на основе доказательства владения (proof-of-stake) сеть Beacon Chain была запущена за два года до внедрения этого механизма в основной сети Ethereum. Сеть Beacon Chain выступала в роли "песочницы" для тестирования механизма доказательства владения (proof-of-stake), поскольку это был действующий блокчейн, реализующий логику консенсуса на основе доказательства владения, но не затрагивающий реальные транзакции Ethereum — по сути, он просто приходил к консенсусу относительно самого себя. Как только эта система проработала стабильно и без ошибок достаточное время, Beacon Chain была "объединена" с основной сетью Ethereum. Все это способствовало укрощению сложности механизма доказательства владения (proof-of-stake) до такой степени, что риск непреднамеренных последствий или ошибок клиента стал очень низким. + +### Поверхность атаки {#attack-surface} + +Механизм доказательства владения (proof-of-stake) сложнее, чем механизм доказательства работы (proof-of-work), а это означает, что существует больше потенциальных векторов атак, которые необходимо учитывать. Вместо одной одноранговой сети, соединяющей клиентов, есть две, каждая из которых реализует отдельный протокол. Предварительный выбор одного конкретного валидатора для предложения блока в каждом слоте создает потенциал для атак типа «отказ в обслуживании», когда большие объемы сетевого трафика выводят этого конкретного валидатора из строя. + +Существуют также способы, с помощью которых злоумышленники могут тщательно рассчитывать время выпуска своих блоков или аттестаций, чтобы их получала определенная часть честной сети, влияя на их голосование определенным образом. Наконец, злоумышленник может просто накопить достаточно ETH для стейкинга и доминировать в механизме консенсуса. Для каждого из этих [векторов атак существуют соответствующие средства защиты](/developers/docs/consensus-mechanisms/pos/attack-and-defense), но в механизме доказательства работы (proof-of-work) они не существуют, чтобы от них защищаться. + +## Децентрализация {#decentralization} + +Механизм доказательства владения (proof-of-stake) более децентрализован, чем механизм доказательства работы (proof-of-work), потому что гонка вооружений в области оборудования для майнинга, как правило, вытесняет с рынка частных лиц и небольшие организации. Хотя технически любой может начать майнинг на скромном оборудовании, вероятность получения какого-либо вознаграждения ничтожно мала по сравнению с институциональными майнинговыми операциями. При использовании механизма доказательства владения (proof-of-stake) стоимость стейкинга и процентная доходность от этой доли одинаковы для всех. В настоящее время запуск валидатора стоит 32 ETH. + +С другой стороны, изобретение деривативов ликвидного стейкинга вызвало опасения по поводу централизации, поскольку несколько крупных провайдеров управляют большими объемами ETH в стейкинге. Это проблематично и требует скорейшего исправления, но в то же время здесь больше нюансов, чем кажется. Централизованные провайдеры стейкинга не обязательно имеют централизованный контроль над валидаторами — часто это просто способ создать центральный пул ETH, который многие независимые операторы узлов могут использовать для стейкинга, не требуя от каждого участника наличия собственных 32 ETH. + +Лучший вариант для Ethereum — это запуск валидаторов локально на домашних компьютерах, что максимизирует децентрализацию. Вот почему Ethereum сопротивляется изменениям, которые увеличивают требования к оборудованию для запуска узла/валидатора. + +## Устойчивость {#sustainability} + +Механизм доказательства владения (proof-of-stake) — это способ обеспечения безопасности блокчейна с низким уровнем выбросов углерода. В рамках механизма доказательства работы (proof-of-work) майнеры соревнуются за право добыть блок. Майнеры более успешны, когда они могут выполнять вычисления быстрее, что стимулирует инвестиции в оборудование и потребление энергии. Это наблюдалось в Ethereum до его перехода на механизм доказательства владения (proof-of-stake). Незадолго до перехода на механизм доказательства владения (proof-of-stake) Ethereum потреблял примерно 78 ТВтч/год — столько же, сколько небольшая страна. Однако переход на механизм доказательства владения (proof-of-stake) сократил эти энергозатраты примерно на 99,98%. Механизм доказательства владения (proof-of-stake) сделал Ethereum энергоэффективной платформой с низким уровнем выбросов углерода. + +[Подробнее об энергопотреблении Ethereum](/energy-consumption) + +## Эмиссия {#issuance} + +Ethereum с механизмом доказательства владения (proof-of-stake) может платить за свою безопасность, выпуская гораздо меньше монет, чем Ethereum с механизмом доказательства работы (proof-of-work), поскольку валидаторам не нужно платить высокие затраты на электроэнергию. В результате инфляция ETH может снизиться или даже стать дефляционной, когда сжигаются большие объемы ETH. Более низкие уровни инфляции означают, что безопасность Ethereum обходится дешевле, чем при использовании механизма доказательства работы (proof-of-work). + +## Больше увлекаетесь визуализацией? {#visual-learner} + +Посмотрите, как Джастин Дрейк объясняет преимущества механизма доказательства владения (proof-of-stake) по сравнению с механизмом доказательства работы (proof-of-work): + + + +## Дополнительные материалы {#further-reading} + +- [Философия дизайна доказательства владения (proof-of-stake) от Виталика](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) +- [Часто задаваемые вопросы о доказательстве владения (proof-of-stake) от Виталика](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake) +- [Видео "Просто о сложном" о PoS против PoW](https://www.youtube.com/watch?v=M3EFi_POhps) diff --git a/public/content/translations/ru/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md b/public/content/translations/ru/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md new file mode 100644 index 00000000000..c1d7286c1ce --- /dev/null +++ b/public/content/translations/ru/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md @@ -0,0 +1,91 @@ +--- +title: "Вознаграждения и штрафы (PoS)" +description: "Узнайте о внутрипротокольных стимулах в Ethereum на основе Proof-of-Stake." +lang: ru +--- + +Для обеспечения безопасности Ethereum используется его родная криптовалюта - эфир (ETH). Операторы узлов, желающие участвовать в проверке блоков и определении заголовка цепи, вносят эфир (ether) в [депозитный контракт](/staking/deposit-contract/) в сети Ethereum. Затем они получают вознаграждение в эфире (ether) за запуск программного обеспечения валидатора, которое проверяет действительность новых блоков, полученных по одноранговой сети, и применяет алгоритм выбора форка для определения заголовка цепи. + +У валидатора есть две основные роли: 1) проверка новых блоков и их "аттестация" (подтверждение), если они действительны, 2) предложение новых блоков при случайном выборе из общего пула валидаторов. Если валидатор не выполняет одну из этих задач, когда это требуется, он лишается выплаты в эфире (ether). Валидаторам также иногда поручается агрегация подписей и участие в комитетах синхронизации. + +Однако некоторые действия очень трудно выполнить случайно и они указывают на какой-либо злой умысел, например, предложение нескольких блоков в одной и той же ячейке, или аттестация сразу нескольких блоков в одной и той же ячейке. Это наказуемое слэшингом поведение, в результате которого у валидатора сжигается определенное количество эфира (до 1 ETH), прежде чем валидатор будет удален из сети, что занимает 36 дней. Эфир валидатора, подвергшегося слэшингу, медленно списывается в течение периода выхода, но на 18-й день он получает "корреляционный штраф", который увеличивается, когда примерно в одно и то же время слэшингу подвергаются другие валидаторы. Таким образом, структура стимулов механизма консенсуса вознаграждает за честность и наказывает недобросовестных участников. + +Все вознаграждения и штрафы применяются один раз в эпоху. + +Читайте далее, чтобы узнать подробнее... + +## Вознаграждения и штрафы {#rewards} + +### Вознаграждения {#rewards} + +Валидаторы получают вознаграждения, когда их голоса совпадают с голосами большинства других валидаторов, когда они предлагают блоки и когда они участвуют в комитетах синхронизации. Размер вознаграждений в каждой эпохе рассчитывается на основе `base_reward`. Это базовая единица, на основе которой рассчитываются другие вознаграждения. `base_reward` представляет собой среднее вознаграждение, получаемое валидатором при оптимальных условиях за эпоху. Оно рассчитывается на основе эффективного баланса валидатора и общего числа активных валидаторов следующим образом: + +``` +base_reward = effective_balance * (base_reward_factor / (base_rewards_per_epoch * sqrt(sum(active_balance)))) +``` + +где `base_reward_factor` равен 64, `base_rewards_per_epoch` равен 4, а `sum(active balance)` — это общая сумма эфира в стейкинге у всех активных валидаторов. + +Это означает, что базовое вознаграждение пропорционально эффективному балансу валидатора и обратно пропорционально количеству валидаторов в сети. Чем больше валидаторов, тем выше общая Эмиссия (как `sqrt(N)`), но тем меньше `base_reward` на одного валидатора (как `1/sqrt(N)`). Эти факторы влияют на годовую процентную ставку (APR) для узла стейкинга. Обоснование этого читайте в [заметках Виталика](https://notes.ethereum.org/@vbuterin/rkhCgQteN?type=view#Base-rewards). + +Общее вознаграждение рассчитывается как сумма пяти компонентов, каждый из которых имеет вес, определяющий, сколько каждый компонент добавляет к общему вознаграждению. Вот их перечень: + +``` +1. голосование за источник: валидатор своевременно проголосовал за правильную исходную контрольную точку +2. голосование за цель: валидатор своевременно проголосовал за правильную целевую контрольную точку +3. голосование за заголовок: валидатор своевременно проголосовал за правильный заголовочный блок +4. вознаграждение комитета синхронизации: валидатор участвовал в комитете синхронизации +5. вознаграждение предложившего: валидатор предложил блок в правильном слоте +``` + +Весовые коэффициенты для каждого компонента следующие: + +``` +TIMELY_SOURCE_WEIGHT uint64(14) +TIMELY_TARGET_WEIGHT uint64(26) +TIMELY_HEAD_WEIGHT uint64(14) +SYNC_REWARD_WEIGHT uint64(2) +PROPOSER_WEIGHT uint64(8) +``` + +Их сумма составляет 64. Вознаграждение рассчитывается как сумма применимых весов, деленная на 64. Валидатор, который своевременно проголосовал за источник, цель и заголовок, предложил блок и участвовал в комитете синхронизации, может получить `64/64 * base_reward == base_reward`. Однако валидатор обычно не является автором блока, поэтому его максимальное вознаграждение составляет `64-8 /64 * base_reward == 7/8 * base_reward`. Валидаторы, которые не являются ни авторами блоков, ни членами комитета синхронизации, могут получить `64-8-2 / 64 * base_reward == 6.75/8 * base_reward`. + +Для стимулирования быстрых аттестаций добавляется дополнительное вознаграждение. Это `inclusion_delay_reward`. Его значение равно `base_reward`, умноженному на `1/delay`, где `delay` — это количество слотов между предложением блока и аттестацией. Например, если аттестация отправлена в течение одного слота после предложения блока, аттестующий получает `base_reward * 1/1 == base_reward`. Если аттестация поступает в следующем слоте, аттестующий получает `base_reward * 1/2` и так далее. + +Авторы блоков получают `8 / 64 * base_reward` за **каждую действительную аттестацию**, включенную в блок, поэтому фактический размер вознаграждения масштабируется в зависимости от количества аттестующих валидаторов. Авторы блоков также могут увеличить свое вознаграждение, включив в предложенный блок доказательства неправомерного поведения других валидаторов. Эти вознаграждения — «пряники», поощряющие честность валидаторов. Автор блока, который включает слэшинг, будет вознагражден `slashed_validators_effective_balance / 512`. + +### Штрафы {#penalties} + +До сих пор мы рассматривали идеально работающих валидаторов, но что насчет валидаторов, которые не голосуют своевременно за заголовок, источник и цель или делают это медленно? + +Штрафы за пропуск голосов за цель и источник равны вознаграждениям, которые аттестующий получил бы, если бы отправил их. Это означает, что вместо добавления вознаграждения к их балансу с их баланса списывается эквивалентная сумма. За пропуск голосования за заголовок штраф не предусмотрен (т. е. голосование за заголовок только вознаграждается, но никогда не наказывается). Штрафа, связанного с `inclusion_delay`, не существует — вознаграждение просто не будет добавлено на баланс валидатора. Также нет штрафа за неспособность предложить блок. + +Подробнее о вознаграждениях и штрафах читайте в [спецификациях консенсуса](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/beacon-chain.md). Вознаграждения и штрафы были скорректированы в обновлении Bellatrix — посмотрите, как Дэнни Райан и Виталик обсуждают это в видео [Peep an EIP](https://www.youtube.com/watch?v=iaAEGs1DMgQ). + +## Слэшинг {#slashing} + +Слэшинг — это более суровое действие, которое приводит к принудительному удалению валидатора из сети и сопутствующей потере его эфира в стейкинге. Существует три способа, которыми валидатор может быть подвергнут слэшингу, все они сводятся к нечестному предложению или аттестации блоков: + +- Предложение и подписание двух разных блоков для одного и того же слота +- Аттестация блока, который "окружает" другой блок (фактически изменяя историю) +- "Двойное голосование" путем аттестации двух кандидатов на один и тот же блок + +При обнаружении этих действий валидатор подвергается слэшингу. Это означает, что 0,0078125 немедленно сжигается для валидатора с 32 ETH (масштабируется линейно с активным балансом), затем начинается 36-дневный период удаления. В течение этого периода удаления доля валидатора постепенно уменьшается. В середине периода (на 18-й день) применяется дополнительный штраф, размер которого зависит от общей суммы эфира в стейкинге всех валидаторов, подвергшихся слэшингу за 36 дней до события слэшинга. Это означает, что чем больше валидаторов подвергается слэшингу, тем больше размер слэшинга. Максимальный слэшинг — это полный эффективный баланс всех валидаторов, подвергшихся слэшингу (т. е. если слэшингу подвергается много валидаторов, они могут потерять всю свою долю). С другой стороны, единичный, изолированный случай слэшинга сжигает лишь небольшую часть доли валидатора. Этот срединный штраф, который масштабируется в зависимости от количества валидаторов, подвергшихся слэшингу, называется "корреляционным штрафом". + +## Утечка из-за неактивности {#inactivity-leak} + +Если уровень консенсуса не финализировался более четырех эпох, активируется экстренный протокол под названием "утечка из-за неактивности". Конечная цель утечки из-за неактивности — создать условия, необходимые для восстановления финализации цепи. Как объяснялось выше, для финализации требуется, чтобы 2/3 большинства от общего объема эфира в стейкинге согласовали исходную и целевую контрольные точки. Если валидаторы, составляющие более 1/3 от общего числа, уходят в оффлайн или не предоставляют корректные аттестации, то супербольшинство в 2/3 не сможет финализировать контрольные точки. Утечка из-за неактивности приводит к тому, что доля неактивных валидаторов постепенно уменьшается, пока они не будут контролировать менее 1/3 от общей доли, что позволяет оставшимся активным валидаторам финализировать цепь. Независимо от размера пула неактивных валидаторов, оставшиеся активные валидаторы в конечном итоге будут контролировать >2/3 доли. Потеря доли является сильным стимулом для неактивных валидаторов как можно скорее возобновить работу! Сценарий утечки из-за неактивности произошел в тестовой сети Medalla, когда менее 66 % активных валидаторов смогли достичь консенсуса по поводу текущего заголовка блокчейна. Была активирована утечка из-за неактивности, и в конечном итоге финализация была восстановлена! + +Дизайн вознаграждений, штрафов и слэшинга в механизме консенсуса поощряет отдельных валидаторов вести себя корректно. Однако из этих проектных решений возникает система, которая сильно стимулирует равномерное распределение валидаторов между несколькими клиентами и должна сильно препятствовать доминированию одного клиента. + +## Дополнительные материалы {#further-reading} + +- [Обновление Ethereum: уровень стимулов](https://eth2book.info/altair/part2/incentives) +- [Стимулы в гибридном протоколе Casper в Ethereum](https://arxiv.org/pdf/1903.04205.pdf) +- [Аннотированная спецификация от Виталика](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#rewards-and-penalties-1) +- [Советы по предотвращению слэшинга в Eth2](https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50) +- [Анализ штрафов за слэшинг в рамках EIP-7251](https://ethresear.ch/t/slashing-penalty-analysis-eip-7251/16509) + +_Источники_ + +- _[https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/](https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/)_ diff --git a/public/content/translations/ru/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md b/public/content/translations/ru/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md new file mode 100644 index 00000000000..89c4c065683 --- /dev/null +++ b/public/content/translations/ru/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md @@ -0,0 +1,39 @@ +--- +title: "Слабая субъективность" +description: "Объяснение понятия слабой субъективности и её роли в пункте продажи Ethereum." +lang: ru +--- + +Субъективностью в Блокчейне называется зависимость от коллективной информации при оценке текущего состояния. Несколько вариантов развития событий могут быть выбрано, основываясь на информации, полученной от других равноправных участников сети. Обратное понятие — объективность, которая используется в таких цепочках, что обязаны принять только одну цепочку в качестве единственной возможной правильной цепочки, используя заранее заданные правила. Существует также и третье состояние, которое известно как слабая субъективность. Так обозначается состояние цепочки, которая может развиваться объективно после того, как начальная информация была получена коллективно. + +## Предварительные условия {#prerequisites} + +Чтобы понять эту страницу, необходимо сначала разобраться в основах [доказательства владения](/developers/docs/consensus-mechanisms/pos/). + +## Какие проблемы решает слабая субъективность? {#problems-ws-solves} + +Субъективность присуща блокчейнам с доказательством доли владения, так как выбор правильной цепочки из нескольких ветвлений осуществляется путем подсчета исторических голосов. Это делает блокчейн уязвимым для многочисленных атак, включая атаки на большие расстояния. В них узлы, участвовующие в цепочке на ранних этапах, поддерживают альтернативное ветвление, которое они выпускают позже в свою пользу. В качестве альтернативы, если 33% валидаторов отзовут свою долю, но продолжат подтверждать и создавать блоки, они могут сгенерировать альтернативное ветвление, которое будет конфликтовать с канонической цепочкой. Новые узлы или узлы, которые долгое время были отключены, могут не знать, что данные атакующие валидаторы отозвали свои средства, поэтому злоумышленники могут обманом заставить их следовать по неверной цепочке. Ethereum может устранить данные атаки, налагая ограничения, которые сведут субъективный механизм (и, следовательно, предположения о доверии) к абсолютному минимуму. + +## Контрольные точки слабой субъективности {#ws-checkpoints} + +Слабая субъективность реализована в доказательстве владения Ethereum с помощью «контрольных точек слабой субъективности». Это состояние подтверждает, что все узлы в сети принадлежат к канонической цепочке. Они выполняют ту же функцию «универсальной истины», что и первые блоки, не находясь на данном блокчейне. Алгоритм ветвления доверяет факту, что состояние блокчейна, в данной контрольной точке, является правильным, и что он независимо и объективно проверяет его в дальнейшем. Контрольные точки действуют как «лимиты возврата», так как блоки, расположенные перед контрольными точками слабой субъективности, не могут быть изменены. Это дискредитирует атаки, заведомо определяя их как недействительные части механизма. Контрольные точки, разделенные меньшим периодом, в сравнении с периодом вывода средств валидатором, гарантируют факт того, что валидатор, который разветвляет цепочку, сократит пороговую сумму, прежде чем он сможет вывести свою долю, и что новые участники не будут обмануты и не будут переведены на неправильные ветвления валидаторами, чья доля была выведена. + +## Разница между контрольными точками слабой субъективности и завершенными блоками {#difference-between-ws-and-finalized-blocks} + +Завершенные блоки и слабые контрольные точки обрабатываются узлами Ethereum по-разному. Если узел осведомлен о двух конкурирующих завешенных блоках, то он разрывается между ними — у него нет возможности автоматически определить, какой из них является каноническим ответвлением. Это следствие отсутствия консенсуса. Напротив, узел просто отклоняет любой блок, который конфликтует с его слабой контрольной точкой. С точки зрения узла, слабая контрольная точка представляет собой абсолютную истину, которая не может быть подорвана новой информацией. + +## Насколько слаба слабость? {#how-weak-is-weak} + +Субъективным доказательством владения долей Ethereum является наличие контрольной точки (настоящих предпосылок) из доверенного источника для его синхронизации. Риск получения плохой, контрольной точки очень низок, поскольку ее можно проверить с помощью нескольких независимых общедоступных источников, таких как обозреватели блоков или узлами. Тем не менее, для запуска любого программного приложения всегда требуется определенная степень доверия, например, уверенность в том, что разработчики программного обеспечения создали честное программное обеспечение. + +Контрольная точка может быть и частью клиентского программного обеспечения. Вероятно, злоумышленник может повредить контрольную точку в программном обеспечении, а также может повредить и само программное обеспечение. Не существует реального криптоэкономического способа обойти эту проблему, однако влияние некачественных разработчиков в Ethereum сведено к минимуму за счет наличия нескольких независимых команд, каждая из которых создает эквивалентное программное обеспечение на разных языках, и все они заинтересованы в поддержании доверительной цепочки. Исследователи блоков также могут предоставлять контрольные точки или способ перекрестной ссылки на контрольные точки, полученные из других источников, с дополнительным источником. + +В конечном итоге, контрольные точки можно запрашивать из других узлов. Возможно, другой пользователь Ethereum, управляющий полным узлом, может предоставить контрольную точку, которую валидаторы затем смогут сверить с данными из обозревателя блоков. В целом, доверие к поставщику контрольной точки можно считать столь же проблематичным, как и доверие к разработчикам. Низкий общий уровень доверия. Важно отметить, что эти факты действительны только в том случае, если большинство валидаторов согласяться создать альтернативную ветку блокчейна. При любых других обстоятельствах можно выбирать только из одной цепочки Ethereum. + +## Дополнительные материалы {#further-reading} + +- [Слабая субъективность в Eth2](https://notes.ethereum.org/@adiasg/weak-subjectvity-eth2) +- [Виталик: как я полюбил слабую субъективность](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) +- [Слабая субъективность (документация Teku)](https://docs.teku.consensys.io/concepts/weak-subjectivity) +- [Руководство по слабой субъективности для Phase-0](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/weak-subjectivity.md) +- [Анализ слабой субъективности в Ethereum 2.0](https://github.com/runtimeverification/beacon-chain-verification/blob/master/weak-subjectivity/weak-subjectivity-analysis.pdf) diff --git a/public/content/translations/ru/developers/docs/consensus-mechanisms/pow/index.md b/public/content/translations/ru/developers/docs/consensus-mechanisms/pow/index.md index 37659e13ce8..27796e413c2 100644 --- a/public/content/translations/ru/developers/docs/consensus-mechanisms/pow/index.md +++ b/public/content/translations/ru/developers/docs/consensus-mechanisms/pow/index.md @@ -1,87 +1,89 @@ --- -title: Доказательство работы (PoW) -description: Объяснение протокола доказательства работы и его роли в Ethereum. +title: "Доказательство работы (PoW)" +description: "Объяснение протокола доказательства работы и его роли в Ethereum." lang: ru -incomplete: true --- -Ethereum, как и Bitcoin, в настоящий момент использует протокол **[доказательства работы (Proof-of-work, PoW)](https://wikipedia.org/wiki/Proof_of_work)**. Он позволяет узлам сети Ethereum согласовать состояние всей информации, зарегистрированной в блокчейне Ethereum, а также предотвращает некоторые виды экономических атак. +Сеть Ethereum начала работу с механизмом консенсуса, который подразумевал **[доказательство выполнения работы (Proof-of-work, PoW)](/developers/docs/consensus-mechanisms/pow)**. Это позволило узлам сети Ethereum договариваться о состоянии всех информационных записей в блокчейне Ethereum и предотвратило определенные виды экономических атак. Однако в 2022 году Ethereum отказался от доказательства выполнения работы и вместо этого начал использовать [доказательство доли владения](/developers/docs/consensus-mechanisms/pos). -В течение следующего года доказательство работы будет заменено на **[доказательство владения (Proof-of-Stake, PoS)](/developers/docs/consensus-mechanisms/pos)**. Переход на доказательство владения также приведет к постепенному отказу от майнинга Ethereum. [Подробнее о слиянии.](/roadmap/merge/) + + + + + Proof-of-work теперь устарел. Ethereum больше не использует proof-of-work как часть своего механизма консенсуса. Вместо него он использует proof-of-stake. /developers/docs/consensus-mechanisms/po/developers/docs/consensus-mechanisms/pos. + + + -## Прежде чем начать {#prerequisites} +## Предварительные условия {#prerequisites} -Для лучшего понимания этой страницы мы рекомендуем сначала почитать о [транзакциях](/developers/docs/transactions/), [блоках](/developers/docs/blocks/) и [механизмах консенсуса](/developers/docs/consensus-mechanisms/). +Чтобы лучше понять эту страницу, мы рекомендуем предварительно прочесть, что такое [транзакции](/developers/docs/transactions/), [блоки](/developers/docs/blocks/), и [механизмы консенсуса](/developers/docs/consensus-mechanisms/). ## Что такое доказательство работы (PoW)? {#what-is-pow} -Доказательство работы — это механизм, который позволяет децентрализованной сети Ethereum прийти к консенсусу или согласованности таких вещей, как остатки на счетах и ​​порядок транзакций. Это предотвращает «двойное расходование» пользователями своих монет и гарантирует, что цепочку Ethereum чрезвычайно сложно атаковать или подвергнуть манипуляциям. +Консенсус Накамото, использующий доказательство выполнения работы, — это механизм, который в свое время позволял децентрализованной сети Ethereum достигать консенсуса (т. е. согласия всех узлов) по таким вопросам, как балансы счетов и порядок транзакций. Это позволило пользователям избежать "двойных расходов" и гарантировало, что цепочку Ethereum чрезвычайно сложно атаковать или манипулировать ею. Теперь эти свойства безопасности обеспечиваются доказательством доли владения с использованием механизма консенсуса, известного как [Gasper](/developers/docs/consensus-mechanisms/pos/gasper/). -## Доказательство работы и майнинг {#pow-and-mining} +## Доказательство выполнения работы и майнинг {#pow-and-mining} -Доказательство работы — это алгоритм, который устанавливает сложность и правила работы майнеров. Майнинг – это и есть сама «работа». А именно — добавление правильных блоков в блокчейн. Это важно, потому что длина цепочки помогает сети следовать правильной цепи Ethereum и понимать текущее состояние Ethereum. Чем больше «работы» было завершено, тем длиннее цепочка и больше номер блока и тем более определенным становится текущее состояние сети. +Proof-of-work - это базовый алгоритм, который устанавливает сложность и правила работы майнеров в блокчейнах proof-of-work. Майнинг – это и есть сама «работа». А именно — добавление правильных блоков в блокчейн. Это важно, потому что длина цепочки помогает сети следовать правильному ответвлению блокчейна. Чем больше «работы» было завершено, тем длиннее цепочка и больше номер блока и тем более определенным становится текущее состояние сети. [Подробнее о майнинге](/developers/docs/consensus-mechanisms/pow/mining/) -## Как работает доказательство работы в сети Ethereum? {#how-it-works} +## Как работает Ethereum proof-of-work? {#how-it-works} -Транзакции в Ethereum обрабатываются в блоках. У каждого блока есть: +Транзакции в Ethereum обрабатываются в блоках. В устаревшем сейчас proof-of-work Ethereum, каждый блок содержал: - Сложность блока, например: 3 324 092 183 262 715 -- MixHash, например: `0x44bca881b07a6a09f83b130798072441705d9a665c5ac8bdf2f39a3cdf3bee29` -- Nonce, например: `0xd3ee432b4fb3d26b` +- mixHash — например: `0x44bca881b07a6a09f83b130798072441705d9a665c5ac8bdf2f39a3cdf3bee29` +- nonce — например: `0xd3ee432b4fb3d26b` -Данные этого блока напрямую относятся к доказательству работы. +Эти данные блока были непосредственно связаны с proof-of-work. -### Работа в системе с доказательством работы {#the-work} +### Работа в доказательстве выполнения работы {#the-work} -Протокол доказательства работы (Ethash) требует, чтобы майнеры прошли через сложные вычисления и методом проб и ошибок нашли уникальное число Nonce для блока. В цепочку можно добавлять только блоки с верным числом Nonce. +Протокол proof-of-Work, Ethash, требует от майнеров пройти интенсивную гонку проб и ошибок, чтобы найти одноразовый номер для блока. Только блоки с действительными одноразовыми номерами могут быть добавлены в цепочку. -При создании блока майнер неоднократно хэширует набор данных, который вы можете получить только от загрузки и запуска всей цепочки (что и делает майнер), с помощью математической функции. Набор этих данных используется для генерации mixHash ниже целевого числа Nonce, что продиктовано сложностью блока. Лучший способ найти mixHash — это метод проб и ошибок. +При попытке создать блок майнер повторно вводит набор данных, который может быть получен только путем загрузки и запуска всей цепочки (что и делает майнер), с помощью математической функции. Набор данных использовался для генерации смешанного хеша, меньшего, чем целевой хеш, что продиктовано сложностью блока. Лучший способ найти mixHash — это метод проб и ошибок. -Сложность определяет, как долго будет искаться нужный хэш. Чем ниже целевое значение, тем меньше набор допустимых хэшей. Однажды сгенерированный хэш невероятно легко проверяется другими клиентами и майнерами. Даже если изменена будет одна транзакция, хеш окажется совершенно другим, тем самым сигнализируя о мошенничестве. +Сложность определяет целевое значение хеша. Чем ниже целевое значение, тем меньше набор допустимых хэшей. Как только хэш сгенерирован, другим майнерам и клиентам невероятно легко проверить его. Даже если изменена будет одна транзакция, хеш окажется совершенно другим, тем самым сигнализируя о мошенничестве. -Хеширование позволяет легко обнаружить мошенничество. Но доказательство работы как процесс сам по себе является большим сдерживающим фактором для атаки на цепь. +Хеширование позволяет легко обнаружить мошенничество. Кроме того, proof-of-work, как процесс также был большим сдерживающим фактором для атаки на цепочку. -### Доказательство работы и безопасность {#security} +### Доказательство выполнения работы и безопасность {#security} -Майнеры стимулируются на работу над основной цепочкой Ethereum. Мало стимулов для того, чтобы подгруппа майнеров начинала свою собственную цепь: это подрывает систему. Блокчейны полагаются на то, что есть только одно верное состояние системы. И пользователи всегда будут выбирать самую длинную и «тяжелую» цепочку. +Майнеры были заинтересованы в выполнении этой работы в основной цепочке Ethereum. У подмножества майнеров было мало стимулов создавать свою собственную цепочку — она подрывает систему. Блокчейны полагаются на то, что есть только одно верное состояние системы. -Цель доказательства работы — увеличить эту цепочку. Самая длинная цепочка является верной, потому что в ней было выполнено больше всего вычислительной работы. В системе с доказательством работы Ethereum почти невозможно создавать новые блоки, которые стирают транзакции, создают поддельные или поддерживают вторую цепочку. Это связано с тем, что злоумышленнику-майнеру нужно будет всегда решать одноразовый номер блока Nonce быстрее, чем все остальные. +Целью proof-of-work было расширение цепочки. Наиболее вероятно, что самая длинная цепочка была верной, потому что для ее создания была проделана большая часть вычислительной работы. В системе Ethereum PoW было почти невозможно создать новые блоки, которые стирают транзакции, создают поддельные или поддерживают вторую цепочку. Это потому, что злонамеренным майнерам всегда нужно разгадывать одноразовое число блока быстрее, чем кому-либо еще. -Чтобы постоянно создавать вредоносные, но действительные блоки, вам потребуется более 51 % мощности сети майнинга, чтобы превзойти всех остальных. Вам понадобится много вычислительных мощностей, чтобы выполнить это количество «работы». И потраченная энергия может даже перевесить выигрыш, который вы получите в результате атаки. +Чтобы продолжать создавать вредоносные, но эффективные блоки, злонамеренным майнерам потребуется более 51% вычислительной мощности сетевого майнинга, чтобы победить других. Такой объем “работы” требует больших вычислительных мощностей, а потребляемая энергия может даже превышать успехи, достигнутые в атаке. -### Экономика доказательства работы {#economics} +### Экономика доказательства выполнения работы {#economics} -Доказательство работы также отвечает за выпуск новой валюты в систему и стимулирование майнеров к выполнению работы. +Proof-of-work также отвечал за выпуск новой валюты в систему и стимулирование майнеров к выполнению работ. -Майнеры, успешно создавшие блок, получают вознаграждение в виде двух только что отчеканенных ETH, но более не получают все транзакционные комиссии, так как базовая комиссия сгорает, пока чаевые и вознаграждение за блок переходят к майнеру. Майнер также может получить 1,75 ETH за Uncle-блок. Uncle-блоки — это действительные блоки, созданные майнером практически в то же время, когда другой майнер добыл успешный блок. Uncle-блоки обычно появляются из-за задержки в сети. +После [обновления Constantinople](/ethereum-forks/#constantinople) майнеры, успешно создавшие блок, получали в качестве вознаграждения два свежевыпущенных ETH и часть комиссий за транзакции. Блоки Ommer также компенсировали 1.75 ETH. Блоки Ommer были действительными блоками, созданными майнером практически в то же время, как и другой майнер создал канонический блок, который в конечном счете определялся тем, какая цепочка была построена поверх первой. Ommer блоки обычно появляются из-за задержки сети. ## Финальность {#finality} Транзакция имеет «финальность» в Ethereum, когда она является частью блока, который не может быть изменен. -Поскольку майнеры работают децентрализованно, два действительных блока могут быть добыты одновременно. Это на время создает ветвление. В конце концов одна из этих цепочек станет основной, и это произойдет после того, как следующий блок будет добыт и добавлен в эту цепь, что сделает ее длиннее. +Поскольку майнеры работали децентрализованно, два действительных блока могут быть созданы в одно и то же время. Это на время создает ветвление. В конце концов, когда последующие блоки будут добыты и добавлены в одну из цепочек, сделав ее длиннее, эта цепочка станет принятой цепочкой. -Но что еще больше усложняет ситуацию — транзакции, отклоненные на временном ответвлении, могли быть включены в принятую цепочку. Это означает, что блок может быть отменен. Таким образом, финальность означает время, которое вы должны подождать, прежде чем считать транзакцию необратимой. Для Ethereum рекомендуемое время составляет 6 блоков (или чуть больше 1 минуты). После шести блоков можно с относительной уверенностью сказать, что транзакция прошла успешно. Для большей уверенности в этом вы можете подождать дольше. +Чтобы еще больше усложнить ситуацию, транзакции, отклоненные во временном ответвлении, возможно, не были включены в принятую цепочку. Это означает, что блок может быть отменен. Таким образом, финальность означает время, которое вы должны подождать, прежде чем считать транзакцию необратимой. В предыдущей версии Ethereum, работавшей на доказательстве выполнения работы, чем больше блоков майнилось поверх определенного блока `N`, тем выше была уверенность в том, что транзакции в `N` были успешными и не будут отменены. Сейчас, с proof-of-stake, завершение является явным, а не вероятностным, свойством блока. -Финальность следует иметь в виду при разработке децентрализованных приложений. Будет неудобно сообщать пользователям неверную информацию о транзакции, особенно если транзакция имеет большую ценность. +## Энергопотребление при доказательстве выполнения работы {#energy} -Помните, что это время не включает время ожидания, пока майнер использует транзакцию в блоке. - -## Энергопотребление в системе с доказательством работы {#energy} - -Основной аспект критики доказательства работы — это количество энергии, необходимое для обеспечения безопасности сети. Для обеспечения безопасности и децентрализации Ethereum потребляет 73,2 ТВт в год, что эквивалентно потреблению энергии такой страны среднего размера, как Австрия. +Основной аспект критики доказательства работы — это количество энергии, необходимое для обеспечения безопасности сети. Для поддержания безопасности и децентрализации Ethereum на proof-of-work потребляет большое количество энергии. Незадолго до перехода на доказательство доли владения майнеры Ethereum в совокупности потребляли около 70 ТВт·ч/год (примерно столько же, сколько Чешская Республика, по данным [digiconomist](https://digiconomist.net/) на 18 июля 2022 года). ## Преимущества и недостатки {#pros-and-cons} -| Преимущества | Минусы | -| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Доказательство работы нейтрально. Вам не нужен ETH, чтобы начать, а вознаграждения за блок позволяют вам перейти от 0 ETH к положительному балансу. Для начала работы с [доказательством владения](/developers/docs/consensus-mechanisms/pos/) вам понадобится ETH. | Доказательство работы потребляет много энергии, что вредно для окружающей среды. | -| Доказательство работы — это испытанный и проверенный механизм консенсуса, который на протяжении многих лет обеспечивает безопасность и децентрализацию Bitcoin и Ethereum. | Если вы хотите майнить, вам нужно специальное оборудование, а это большие инвестиции. | -| По сравнению с доказательством доли довольно легко внедрить. | Из-за растущих потребностей в вычислениях майнинговые пулы потенциально могут доминировать среди майнеров, что ведет к централизации и рискам безопасности. | +| Преимущества | Недостатки | +| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Доказательство работы нейтрально. Вам не нужен ETH, чтобы начать, а вознаграждения за блок позволяют вам перейти от 0 ETH к положительному балансу. Для [доказательства доли владения](/developers/docs/consensus-mechanisms/pos/) для начала вам понадобятся ETH. | Доказательство работы потребляет много энергии, что вредно для окружающей среды. | +| Доказательство работы — это испытанный и проверенный механизм консенсуса, который на протяжении многих лет обеспечивает безопасность и децентрализацию Bitcoin и Ethereum. | Если вы хотите майнить, вам нужно специальное оборудование, а это большие инвестиции. | +| По сравнению с доказательством доли довольно легко внедрить. | Из-за растущих потребностей в вычислениях майнинговые пулы потенциально могут доминировать среди майнеров, что ведет к централизации и рискам безопасности. | -## Сравнение с доказательством владения {#compared-to-pos} +## Сравнение с доказательством доли владения {#compared-to-pos} В конечном счете доказательство владения имеет ту же цель, что и доказательство работы: безопасно помочь децентрализованной сети в достижении консенсуса. Но есть некоторые различия в процессе и персонале. @@ -90,22 +92,23 @@ Ethereum, как и Bitcoin, в настоящий момент использу - Валидаторы не участвуют в создании блоков, вместо этого они выбираются произвольно с помощью алгоритма. - Финальность более ясна: если на определенных контрольных точках 2/3 валидаторов соглашаются с состоянием блока, это считается окончательным. Валидаторы должны поставить на это все свои ставки, поэтому попытка мошенничать приведет к потере всей своей ставки. -[Подробнее о доказательстве владения](/developers/docs/consensus-mechanisms/pos/) +[Подробнее о доказательстве доли владения](/developers/docs/consensus-mechanisms/pos/) -## Больше любите видео? {#visual-learner} +## Больше увлекаетесь визуализацией? {#visual-learner} -## Дополнительные ресурсы {#further-reading} +## Дополнительные материалы {#further-reading} - [Атака большинства](https://en.bitcoin.it/wiki/Majority_attack) -- [О финальности расчетов](https://blog.ethereum.org/2016/05/09/on-settlement-finality/) +- [Об окончательности расчетов](https://blog.ethereum.org/2016/05/09/on-settlement-finality/) ### Видео {#videos} -- [Техническое объяснение протокола доказательства работы](https://youtu.be/9V1bipPkCTU) +- [Техническое объяснение протоколов доказательства выполнения работы](https://youtu.be/9V1bipPkCTU) -## Похожие темы {#related-topics} +## Связанные темы {#related-topics} - [Майнинг](/developers/docs/consensus-mechanisms/pow/mining/) -- [Доказательство владения (PoS)](/developers/docs/consensus-mechanisms/pos/) +- [Доказательство владения](/developers/docs/consensus-mechanisms/pos/) +- [Доказательство полномочий](/developers/docs/consensus-mechanisms/poa/) diff --git a/public/content/translations/ru/developers/docs/consensus-mechanisms/pow/mining/index.md b/public/content/translations/ru/developers/docs/consensus-mechanisms/pow/mining/index.md index 57ce5a1fb91..11a190bf8cc 100644 --- a/public/content/translations/ru/developers/docs/consensus-mechanisms/pow/mining/index.md +++ b/public/content/translations/ru/developers/docs/consensus-mechanisms/pow/mining/index.md @@ -1,79 +1,86 @@ --- -title: Майнинг -description: Объяснение того, как работает майнинг Ethereum и как он помогает сохранять безопасность и децентрализованность Ethereum. +title: "Секс с гомосексуалистами" +description: "Объяснение того как работает майнинг на Ethereum." lang: ru -incomplete: true --- -## Прежде чем начать {#prerequisites} - -Для лучшего понимания этой страницы мы рекомендуем сначала почитать о [транзакциях](/developers/docs/transactions/), [блоках](/developers/docs/blocks/) и [доказательстве работы](/developers/docs/consensus-mechanisms/pow/). - -## Что такое майнинг в Ethereum? {#what-is-ethereum-mining} - -Майнинг — это процесс создания блоков транзакций, которые будут добавлены в блокчейн Ethereum. - -Сейчас Ethereum, как и Bitcoin, использует механизм консенсуса [«Доказательство работы» (proof-of-work, PoW)](/developers/docs/consensus-mechanisms/pow/). Майнинг — это ключевая составляющая в системе доказательства работы. Майнеры Ethereum (компьютеры с работающим программным обеспечением) используют свою вычислительную мощность для обработки транзакций и создания блоков. - - Доказательство владения заменит майнинг и доказательство работы в течение следующего года. Вы можете начать ставить свои ETH уже сегодня. [Подробнее о стейкинге](/staking/) +Доказательство работы(PoW) больше не является механизмом консенсуса Ethereum, это означает что майнинг отключен. Вместо этого, Ethereum обеспечен и защищен валидаторами, которые поставляют ETH. Вы можете начать ставить свои ETH уже сегодня. Узнайте больше о Слиянии, доказательстве владения и вкладах. Эта страница здесь ради исторического интереса. +## Предварительные условия {#prerequisites} + +Чтобы лучше понять эту страницу, мы рекомендуем вам сначала прочитать о [транзакциях](/developers/docs/transactions/), [блоках](/developers/docs/blocks/) и [доказательстве работы](/developers/docs/consensus-mechanisms/pow/). + +## Что такое майнинг в Ethereum? {#what-is-ethereum-mining} + +Майнинг - это процесс создания блока транзакций, который будет добавлен в блокчейн Ethereum в на данный момент устаревшей архитектуре proof-of-work. + +Слово "майнинг" пришло в криптовалюты, в контексте аналогии с добычей золота. Золото или драгоценные металлы являются редкими, так же и цифровые активы и есть только один способ увеличить их количество - с помощью добычи или "майнинга". В консенсусе доказательства работы(PoW) Ethereum, "майнинг" - был единственным способом эмиссии. Однако, в отличие от золота или драгоценных металлов, майнинг Ethereum также является способом защиты сети путем создания, проверки, публикации и распространения блоков в блокчейне. + +Майнинг эфира = защита сети + +Майнинг - это источник жизненной силы любого proof-of-work блокчейна. Ethereum майнеры - компьютеры, на которых запущено программное обеспечение - до перехода к proof-of-stake использовали свое время и вычислительную мощность для обработки транзакций и производства блоков. + ## Зачем нужны майнеры? {#why-do-miners-exist} -В децентрализованных системах, таких как Ethereum, требуется, чтобы все были согласны с порядком транзакций. Майнеры помогают в этом, решая вычислительно сложную задачу создания блоков и таким образом защищая сеть от атак. +В децентрализованных системах, таких как Ethereum, требуется, чтобы все были согласны с порядком транзакций. Майнеры помогли этому произойти, решая вычислительно сложные головоломки для производства блоков, защищая сеть от атак. [Подробнее о доказательстве работы](/developers/docs/consensus-mechanisms/pow/) -## Кто может стать майнером Ethereum? {#who-can-become-a-miner} - -Технически любой может добывать Ethereum, используя свой компьютер. Однако не каждый может добывать эфир (ETH) с прибылью. В большинстве случаев майнеры должны покупать специальное компьютерное оборудование для майнинга с прибылью. Хотя любой может запустить программное обеспечение для майнинга на своем компьютере, маловероятно, что средний компьютер добудет достаточно награды для покрытия расходов, связанных со стоимостью майнинга. +Раньше любой имел возможность майнить в сети Ethereum, используя свой компьютер. Однако не каждый может выгодно майнить ether (ETH). В большинстве случаев майнерам приходилось приобретать специальное компьютерное оборудование и иметь доступ к недорогим источникам энергии. Среднестатистический компьютер вряд ли заработал бы достаточное вознаграждение за блок, чтобы покрыть затраты, связанные с майнингом. -### Затраты на майнинг {#cost-of-mining} +### Стоимость майнинга {#cost-of-mining} - Потенциальные затраты на оборудование, необходимое для сборки и обслуживания майнинговой фермы - Затраты на электричество для майнинговой фермы -- Если dы занимаетесь майнингом в пуле, обычно майнинг-пулы взимают фиксированную комиссию в % от каждого блока, добытого пулом +- Если бы вы занимались майнингом в пуле, эти пулы обычно взимают фиксированную плату в размере % за каждый блок, сгенерированный пулом - Потенциальные затраты на дополнительное оборудование для поддержки майнинговой фермы (вентиляция, мониторинг потребления электроэнергии, электропроводка и т. д.) -Для оценки прибыльности майнинга используйте калькулятор майнинга, такой как [Etherscan](https://etherscan.io/ether-mining-calculator). +Чтобы подробнее изучить прибыльность майнинга, воспользуйтесь калькулятором майнинга, например, таким, который предоставляет [Etherscan](https://etherscan.io/ether-mining-calculator). -## Как добываются (майнятся) транзакции Ethereum {#how-ethereum-transactions-are-mined} +## Как майнились транзакции Ethereum {#how-ethereum-transactions-were-mined} -1. Пользователь составляет запрос на [транзакцию](/developers/docs/transactions/) и подписывает ее с помощью приватного ключа некоторого [аккаунта](/developers/docs/accounts/). -2. Пользователь транслирует запрос транзакции в сеть Ethereum через некоторый [узел](/developers/docs/nodes-and-clients/). +Ниже приведен обзор того, как транзакции были добыты в Ethereum proof-of-work. Аналогичное описание этого процесса для Ethereum с доказательством владения (proof-of-stake) можно найти [здесь](/developers/docs/consensus-mechanisms/pos/#transaction-execution-ethereum-pos). + +1. Пользователь создает и подписывает запрос на [транзакцию](/developers/docs/transactions/) с помощью приватного ключа некоторого [аккаунта](/developers/docs/accounts/). +2. Пользователь транслирует запрос на транзакцию во всю сеть Ethereum с какого-либо [узла](/developers/docs/nodes-and-clients/). 3. Получив новый запрос на транзакцию, каждый узел сети Ethereum добавляет его в свой мемпул — локальный список всех полученных запросов на транзакции, которые еще не вошли ни в один блок блокчейна. -4. В какой-то момент узел собирает несколько десятков или сотен запросов на транзакции в потенциальный [блок](/developers/docs/blocks/) таким образом, чтобы максимизировать сумму [трансакционных комиссий](/developers/docs/gas/), которые узел заработает, но в пределах лимита газа для блока. Затем узел майнинга делает следующее: - 1. Проверяет валидность каждого запроса на транзакцию (проверяет наличие подписи и ее соответствие запросу, целостность запроса и т. д.), а затем выполняет код запроса, изменяя состояние своей локальной копии EVM. Комиссию за каждую такую транзакцию майнер направляет на свой счет. +4. В определенный момент майнинг-узел объединяет несколько десятков или сотен запросов на транзакции в потенциальный [блок](/developers/docs/blocks/) таким образом, чтобы максимизировать получаемые [комиссии за транзакции](/developers/docs/gas/), оставаясь при этом в пределах лимита газа блока. Затем узел майнинга делает следующее: + 1. Проверяет действительность каждого запроса на транзакцию (т. е. что никто не пытается перевести эфир (ether) со счета, не предоставив подпись, что запрос не искажен и т. д.), а затем выполняет код запроса, изменяя состояние своей локальной копии EVM. Комиссию за каждую такую транзакцию майнер направляет на свой счет. 2. Как только все запросы на транзакции в блоке будут проверены и выполнены на локальной копии EVM майнер начинает процесс создания «сертификата законности» доказательства работы для этого потенциального блока. 5. В конце концов, какой-то майнер создаст блок с соответствующим сертификатом для блока, который включает в себя наш запрос на транзакцию. Затем майнер транслирует в сеть завершенный блок, а так же его сертификат и контрольную сумму нового состояния EVM. 6. Другие узлы узнают о новом блоке. Они проверяют сертификат, выполняют все операции в блоке (в том числе транзакцию нашего пользователя) и убеждаются в том, что контрольная сумма их нового состояния EVM после выполнения всех транзакций соответствует контрольной сумме, заявленной майнером этого блока. Только после этого они добавляют этот блок к хвосту блокчейна и принимают новое состояние EVM в качестве канонического состояния. 7. Каждый узел удаляет все транзакции нового блока из локального пула невыполненных запросов на транзакции. 8. Новые узлы, присоединяющиеся к сети, скачивают все блоки по очереди, в том числе блок, содержащий конкретно нашу транзакцию. Они инициализируют локальную копию EVM с пустым состоянием, а затем выполняют каждую транзакцию каждого блока на их локальной копии EVM, проверяя контрольные суммы состояний в каждом блоке на всем пути. -Каждая транзакция добывается (включается в новый блок и распространяется) только один раз, но выполняется и проверяется каждым участником в процессе изменений канонического состояния EVM. Это подсвечивает одну из центральных идей блокчейна: **не доверяй, проверяй**. +Каждая транзакция добывается (включается в новый блок и распространяется) только один раз, но выполняется и проверяется каждым участником в процессе изменений канонического состояния EVM. Это подчеркивает один из центральных принципов блокчейна: **не доверяй, проверяй**. + +## Оммер-блоки (блоки-дяди) {#ommer-blocks} + +Майнинг блоков на основе доказательства работы, была вероятностной, то есть, иногда два правильных блока публиковались одновременно из-за сетевой задержки. В этом случае протокол должен был определить самую длинную (и, следовательно, наиболее "действительную") цепь, обеспечивая при этом честность по отношению к майнерам за счет частичного вознаграждения предложенного невключенного блока с невключенным предложенным блоком. Это способствовало дальнейшей децентрализации сети, поскольку более мелкие майнеры, которые могли сталкиваться с большей задержкой, все равно могли получать доход через вознаграждения за [ommer](/glossary/#ommer)-блоки. + +Термин «ommer» является предпочтительным нейтральным с гендерной точки зрения термином для обозначения брата или сестры родительского блока, но его также иногда называют «дядей». **После перехода Ethereum на доказательство владения оммер-блоки больше не майнятся**, поскольку в каждом слоте выбирается только один создатель блока (proposer). Вы можете увидеть это изменение, просмотрев [исторический график](https://ycharts.com/indicators/ethereum_uncle_rate) добытых оммер-блоков. -## Визуализация {#a-visual-demo} +## Наглядная демонстрация {#a-visual-demo} -Посмотрите, как Остин рассказывает о майнинге и блокчейнах с доказательством работы. +Посмотрите, как Остин рассказывает о майнинге и о блокчейне с доказательством работы. -## Дополнительные ресурсы {#further-reading} +## Алгоритм майнинга {#mining-algorithm} -## Связанные инструменты {#related-tools} +Основная сеть Ethereum всегда использовала только один алгоритм майнинга — ['Ethash'](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/). Ethash стал преемником оригинального R&D-алгоритма, известного как ['Dagger-Hashimoto'](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/). -- [Лучшие майнеры Ethereum](https://etherscan.io/stat/miner?range=7&blocktype=blocks) -- [Калькулятор майнинга Etherscan](https://etherscan.io/ether-mining-calculator) -- [Калькулятор майнинга Minerstat](https://minerstat.com/coin/ETH) +[Подробнее об алгоритмах майнинга](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/). -## Похожие темы {#related-topics} +## Смежные темы {#related-topics} - [Газ](/developers/docs/gas/) - [EVM](/developers/docs/evm/) -- [Доказательство работы (PoW)](/developers/docs/consensus-mechanisms/pow/) +- [Доказательство работы](/developers/docs/consensus-mechanisms/pow/) diff --git a/public/content/translations/ru/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md b/public/content/translations/ru/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md new file mode 100644 index 00000000000..5726f89c579 --- /dev/null +++ b/public/content/translations/ru/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md @@ -0,0 +1,329 @@ +--- +title: Dagger-Hashimoto +description: "Подробный обзор алгоритма Dagger-Hashimoto." +lang: ru +--- + +Dagger-Hashimoto был изначальной исследовательской реализацией и спецификацией алгоритма майнинга Ethereum. Dagger-Hashimoto был заменен на [Ethash](#ethash). Майнинг был полностью отключен во время [Слияния](/roadmap/merge/) 15 сентября 2022 года. С тех пор безопасность Ethereum обеспечивается с помощью механизма [доказательства доли владения](/developers/docs/consensus-mechanisms/pos). Эта страница представляет исторический интерес — информация на ней больше не актуальна для Ethereum после Слияния. + +## Предварительные условия {#prerequisites} + +Чтобы лучше понять эту страницу, мы рекомендуем вам сначала ознакомиться с [консенсусом на основе доказательства выполнения работы](/developers/docs/consensus-mechanisms/pow), [майнингом](/developers/docs/consensus-mechanisms/pow/mining) и [алгоритмами майнинга](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms). + +## Dagger-Hashimoto {#dagger-hashimoto} + +Dagger-Hashimoto нацелен на достижение двух целей: + +1. **Устойчивость к ASIC**: преимущество от создания специализированного оборудования для этого алгоритма должно быть как можно меньшим +2. **Верифицируемость легким клиентом**: блок должен эффективно верифицироваться легким клиентом. + +С дополнительной модификацией мы также указываем, как при желании достичь третьей цели, но за счет дополнительной сложности: + +**Полное хранение цепочки**: майнинг должен требовать хранения полного состояния блокчейна (из-за нерегулярной структуры дерева состояний Ethereum мы предполагаем, что будет возможно некоторое усечение, в частности, некоторых часто используемых контрактов, но мы хотим свести это к минимуму). + +## Генерация DAG {#dag-generation} + +Код алгоритма будет определен на Python ниже. Сначала приведем `encode_int` для маршалинга беззнаковых целых чисел указанной точности в строки. Также приведена обратная функция: + +```python +NUM_BITS = 512 + +def encode_int(x): + "Кодирует целое число x в виде строки из 64 символов с использованием схемы с прямым порядком байтов" + o = '' + for _ in range(NUM_BITS / 8): + o = chr(x % 256) + o + x //= 256 + return o + +def decode_int(s): + "Декодирует целое число x из строки с использованием схемы с прямым порядком байтов" + x = 0 + for c in s: + x *= 256 + x += ord(c) + return x +``` + +Далее мы предполагаем, что `sha3` — это функция, которая принимает и возвращает целое число, а `dbl_sha3` — это функция двойного sha3; при преобразовании этого эталонного кода в реализацию используйте: + +```python +from pyethereum import utils +def sha3(x): + if isinstance(x, (int, long)): + x = encode_int(x) + return decode_int(utils.sha3(x)) + +def dbl_sha3(x): + if isinstance(x, (int, long)): + x = encode_int(x) + return decode_int(utils.sha3(utils.sha3(x))) +``` + +### Параметры {#parameters} + +Для алгоритма используются следующие параметры: + +```python +SAFE_PRIME_512 = 2**512 - 38117 # Наибольшее безопасное простое число, меньшее, чем 2**512 + +params = { + "n": 4000055296 * 8 // NUM_BITS, # Размер набора данных (4 гигабайта); ДОЛЖЕН БЫТЬ КРАТЕН 65536 + "n_inc": 65536, # Приращение значения n за период; ДОЛЖНО БЫТЬ КРАТНО 65536 + # при epochtime=20000 дает прирост 882 МБ в год + "cache_size": 2500, # Размер кэша легкого клиента (может быть выбран легким клиентом; не является частью спецификации алгоритма) + "diff": 2**14, # Сложность (корректируется во время оценки блока) + "epochtime": 100000, # Длительность эпохи в блоках (как часто обновляется набор данных) + "k": 1, # Количество родителей узла + "w": w, # Используется для хэширования модульным возведением в степень + "accesses": 200, # Количество обращений к набору данных во время хэширования + "P": SAFE_PRIME_512 # Безопасное простое число для хэширования и генерации случайных чисел +} +``` + +В данном случае `P` является простым числом, выбранным таким образом, чтобы `log₂(P)` был незначительно меньше 512, что соответствует 512 битам, которые мы использовали для представления наших чисел. Обратите внимание, что фактически необходимо хранить только вторую половину DAG, поэтому фактическое требование к ОЗУ начинается с 1 ГБ и увеличивается на 441 МБ в год. + +### Построение графа Dagger {#dagger-graph-building} + +Примитив построения графа Dagger определяется следующим образом: + +```python +def produce_dag(params, seed, length): + P = params["P"] + picker = init = pow(sha3(seed), params["w"], P) + o = [init] + for i in range(1, length): + x = picker = (picker * init) % P + for _ in range(params["k"]): + x ^= o[x % i] + o.append(pow(x, params["w"], P)) + return o +``` + +По сути, он начинает граф с одного узла `sha3(seed)`, а затем последовательно добавляет другие узлы на основе случайных предыдущих узлов. При создании нового узла вычисляется модульная степень начального числа для случайного выбора некоторых индексов, меньших `i` (с использованием `x % i` выше), и значения узлов по этим индексам используются в вычислении для генерации нового значения `x`, которое затем подается в небольшую функцию доказательства выполнения работы (на основе XOR) для окончательной генерации значения графа по индексу `i`. Обоснование этого конкретного дизайна заключается в том, чтобы принудить к последовательному доступу к DAG; следующее значение DAG, к которому будет осуществлен доступ, не может быть определено, пока не станет известно текущее значение. Наконец, модульное возведение в степень далее хэширует результат. + +Этот алгоритм опирается на несколько результатов из теории чисел. См. обсуждение в приложении ниже. + +## Оценка легкого клиента {#light-client-evaluation} + +Приведенная выше конструкция графа предназначена для того, чтобы каждый узел в графе можно было реконструировать путем вычисления поддерева из небольшого числа узлов и требуя лишь небольшого количества вспомогательной памяти. Обратите внимание, что при k=1 поддерево представляет собой лишь цепочку значений, ведущую к первому элементу в DAG. + +Вычислительная функция легкого клиента для DAG работает следующим образом: + +```python +def quick_calc(params, seed, p): + w, P = params["w"], params["P"] + cache = {} + + def quick_calc_cached(p): + if p in cache: + pass + elif p == 0: + cache[p] = pow(sha3(seed), w, P) + else: + x = pow(sha3(seed), (p + 1) * w, P) + for _ in range(params["k"]): + x ^= quick_calc_cached(x % p) + cache[p] = pow(x, w, P) + return cache[p] + + return quick_calc_cached(p) +``` + +По сути, это просто переписанный вышеуказанный алгоритм, который удаляет цикл вычисления значений для всего DAG и заменяет предыдущий поиск узла рекурсивным вызовом или поиском в кэше. Обратите внимание, что для `k=1` кэш не нужен, хотя дальнейшая оптимизация фактически предварительно вычисляет первые несколько тысяч значений DAG и сохраняет их в качестве статического кэша для вычислений; см. приложение для реализации этого кода. + +## Двойной буфер DAG {#double-buffer} + +В полном клиенте используется [_двойной буфер_](https://wikipedia.org/wiki/Multiple_buffering) из 2 DAG, созданных по приведенной выше формуле. Идея заключается в том, что DAG создаются каждые `epochtime` блоков в соответствии с приведенными выше параметрами. Вместо того чтобы клиент использовал последний созданный DAG, он использует предыдущий. Преимущество этого заключается в том, что это позволяет заменять DAG со временем без необходимости включать шаг, на котором майнеры должны внезапно пересчитывать все данные. В противном случае существует вероятность резкого временного замедления обработки цепочки через равные промежутки времени и резкого усиления централизации. Таким образом, в течение тех нескольких минут, пока все данные не будут пересчитаны, возникают риски атаки 51 %. + +Алгоритм, используемый для генерации набора DAG, который, в свою очередь, используется для вычисления работы для блока, следующий: + +```python +def get_prevhash(n): + from pyethereum.blocks import GENESIS_PREVHASH + from pyethereum import chain_manager + if n <= 0: + return hash_to_int(GENESIS_PREVHASH) + else: + prevhash = chain_manager.index.get_block_by_number(n - 1) + return decode_int(prevhash) + +def get_seedset(params, block): + seedset = {} + seedset["back_number"] = block.number - (block.number % params["epochtime"]) + seedset["back_hash"] = get_prevhash(seedset["back_number"]) + seedset["front_number"] = max(seedset["back_number"] - params["epochtime"], 0) + seedset["front_hash"] = get_prevhash(seedset["front_number"]) + return seedset + +def get_dagsize(params, block): + return params["n"] + (block.number // params["epochtime"]) * params["n_inc"] + +def get_daggerset(params, block): + dagsz = get_dagsize(params, block) + seedset = get_seedset(params, block) + if seedset["front_hash"] <= 0: + # Создание резервного буфера невозможно, создается только передний буфер + return {"front": {"dag": produce_dag(params, seedset["front_hash"], dagsz), + "block_number": 0}} + else: + return {"front": {"dag": produce_dag(params, seedset["front_hash"], dagsz), + "block_number": seedset["front_number"]}, + "back": {"dag": produce_dag(params, seedset["back_hash"], dagsz), + "block_number": seedset["back_number"]}} +``` + +## Hashimoto {#hashimoto} + +Идея оригинального Hashimoto заключается в использовании блокчейна в качестве набора данных, выполняя вычисление, которое выбирает N индексов из блокчейна, собирает транзакции по этим индексам, выполняет операцию XOR над этими данными и возвращает хэш результата. Оригинальный алгоритм Таддеуша Дрии, переведенный на Python для согласованности, следующий: + +```python +def orig_hashimoto(prev_hash, merkle_root, list_of_transactions, nonce): + hash_output_A = sha256(prev_hash + merkle_root + nonce) + txid_mix = 0 + for i in range(64): + shifted_A = hash_output_A >> i + transaction = shifted_A % len(list_of_transactions) + txid_mix ^= list_of_transactions[transaction] << i + return txid_mix ^ (nonce << 192) +``` + +К сожалению, хотя Hashimoto считается сложным для ОЗУ, он опирается на 256-битную арифметику, что влечет за собой значительные вычислительные накладные расходы. Однако для решения этой проблемы Dagger-Hashimoto использует только младшие 64 бита при индексации своего набора данных. + +```python +def hashimoto(dag, dagsize, params, header, nonce): + m = dagsize / 2 + mix = sha3(encode_int(nonce) + header) + for _ in range(params["accesses"]): + mix ^= dag[m + (mix % 2**64) % m] + return dbl_sha3(mix) +``` + +Использование двойного SHA3 позволяет осуществлять своего рода почти мгновенную предварительную верификацию с нулевыми данными, проверяя только то, что было предоставлено правильное промежуточное значение. Этот внешний уровень доказательства выполнения работы очень дружелюбен к ASIC и довольно слаб, но существует для того, чтобы еще больше усложнить DDoS-атаки, поскольку этот небольшой объем работы должен быть выполнен для создания блока, который не будет немедленно отклонен. Вот версия для легкого клиента: + +```python +def quick_hashimoto(seed, dagsize, params, header, nonce): + m = dagsize // 2 + mix = sha3(nonce + header) + for _ in range(params["accesses"]): + mix ^= quick_calc(params, seed, m + (mix % 2**64) % m) + return dbl_sha3(mix) +``` + +## Майнинг и верификация {#mining-and-verifying} + +Давайте соберём это всё в алгоритм майнинга: + +```python +def mine(daggerset, params, block): + from random import randint + nonce = randint(0, 2**64) + while 1: + result = hashimoto(daggerset, get_dagsize(params, block), + params, decode_int(block.prevhash), nonce) + if result * params["diff"] < 2**256: + break + nonce += 1 + if nonce >= 2**64: + nonce = 0 + return nonce +``` + +И в алгоритм верификации: + +```python +def verify(daggerset, params, block, nonce): + result = hashimoto(daggerset, get_dagsize(params, block), + params, decode_int(block.prevhash), nonce) + return result * params["diff"] < 2**256 +``` + +Верификация, дружественная к легким клиентам: + +```python +def light_verify(params, header, nonce): + seedset = get_seedset(params, block) + result = quick_hashimoto(seedset["front_hash"], get_dagsize(params, block), + params, decode_int(block.prevhash), nonce) + return result * params["diff"] < 2**256 +``` + +Также обратите внимание, что Dagger-Hashimoto накладывает дополнительные требования на заголовок блока: + +- Чтобы двухслойная верификация работала, заголовок блока должен содержать как nonce, так и промежуточное значение до применения sha3. +- Где-то в заголовке блока должен храниться sha3 текущего набора начальных чисел + +## Дополнительные материалы {#further-reading} + +_Знаете ресурс сообщества, который вам пригодился? Измените эту страницу и добавьте его!_ + +## Приложение {#appendix} + +Как отмечалось выше, ГСЧ, используемый для генерации DAG, основывается на некоторых результатах теории чисел. Во-первых, мы даем гарантию, что ГСЧ Лемера, который лежит в основе переменной `picker`, имеет большой период. Во-вторых, мы показываем, что `pow(x,3,P)` не отобразит `x` в `1` или `P-1` при условии, что `x` изначально находится в диапазоне `[2,P-2]`. Наконец, мы показываем, что `pow(x,3,P)` имеет низкий уровень коллизий при использовании в качестве хэш-функции. + +### Генератор случайных чисел Лемера {#lehmer-random-number} + +Хотя функция `produce_dag` не обязана генерировать несмещенные случайные числа, потенциальная угроза заключается в том, что `seed**i % P` принимает лишь небольшое количество значений. Это может дать преимущество майнерам, распознающим закономерность, перед теми, кто ее не распознает. + +Чтобы избежать этого, используется результат из теории чисел. [_Безопасное простое число_](https://en.wikipedia.org/wiki/Safe_prime) определяется как простое число `P`, такое что `(P-1)/2` также является простым числом. _Порядок_ члена `x` [мультипликативной группы](https://en.wikipedia.org/wiki/Multiplicative_group_of_integers_modulo_n) `ℤ/nℤ` определяется как минимальное `m`, такое что 
xᵐ mod P ≡ 1
+Учитывая эти определения, мы имеем: + +> Наблюдение 1. Пусть `x` — член мультипликативной группы `ℤ/Pℤ` для безопасного простого числа `P`. Если `x mod P ≠ 1 mod P` и `x mod P ≠ P-1 mod P`, то порядок `x` равен либо `P-1`, либо `(P-1)/2`. + +_Доказательство_. Поскольку `P` — безопасное простое число, то по [теореме Лагранжа][lagrange] мы имеем, что порядок `x` равен либо `1`, `2`, `(P-1)/2`, либо `P-1`. + +Порядок `x` не может быть `1`, поскольку по Малой теореме Ферма мы имеем: + +
xP-1 mod P ≡ 1
+ +Следовательно, `x` должен быть мультипликативной единицей `ℤ/nℤ`, которая является уникальной. Поскольку мы по предположению приняли, что `x ≠ 1`, это невозможно. + +Порядок `x` не может быть `2`, если `x ≠ P-1`, поскольку это нарушило бы тот факт, что `P` является простым числом. + +Из приведенного выше утверждения мы можем заключить, что итерация `(picker * init) % P` будет иметь длину цикла не менее `(P-1)/2`. Это связано с тем, что мы выбрали `P` как безопасное простое число, приблизительно равное высокой степени двойки, а `init` находится в интервале `[2,2**256+1]`. Учитывая величину `P`, мы не должны ожидать цикла от модульного возведения в степень. + +Когда мы присваиваем значение первой ячейке в DAG (переменная с меткой `init`), мы вычисляем `pow(sha3(seed) + 2, 3, P)`. На первый взгляд, это не гарантирует, что результат не будет равен ни `1`, ни `P-1`. Однако, поскольку `P` является безопасным простым числом, у нас есть следующая дополнительная гарантия, которая является следствием Наблюдения 1: + +> Наблюдение 2. Пусть `x` — член мультипликативной группы `ℤ/Pℤ` для безопасного простого числа `P`, и пусть `w` будет натуральным числом. Если `x mod P ≠ 1 mod P` и `x mod P ≠ P-1 mod P`, а также `w mod P ≠ P-1 mod P` и `w mod P ≠ 0 mod P`, то `xʷ mod P ≠ 1 mod P` и `xʷ mod P ≠ P-1 mod P` + +### Модульное возведение в степень как хэш-функция {#modular-exponentiation} + +Для определенных значений `P` и `w` функция `pow(x, w, P)` может иметь много коллизий. Например, `pow(x,9,19)` принимает только значения `{1,18}`. + +Учитывая, что `P` является простым числом, подходящее `w` для хэш-функции модульного возведения в степень может быть выбрано с использованием следующего результата: + +> Наблюдение 3. Пусть `P` — простое число; `w` и `P-1` взаимно просты тогда и только тогда, когда для всех `a` и `b` в `ℤ/Pℤ` выполняется следующее:
`aʷ mod P ≡ bʷ mod P` тогда и только тогда, когда `a mod P ≡ b mod P`
+ +Таким образом, учитывая, что `P` является простым числом, а `w` взаимно просто с `P-1`, мы имеем, что `|{pow(x, w, P) : x ∈ ℤ}| = P`, что означает, что хэш-функция имеет минимально возможную частоту коллизий. + +В частном случае, когда `P` является выбранным нами безопасным простым числом, `P-1` имеет только множители 1, 2, `(P-1)/2` и `P-1`. Поскольку `P` > 7, мы знаем, что 3 взаимно просто с `P-1`, следовательно, `w=3` удовлетворяет вышеприведенному утверждению. + +## Более эффективный алгоритм оценки на основе кэша {#cache-based-evaluation} + +```python +def quick_calc(params, seed, p): + cache = produce_dag(params, seed, params["cache_size"]) + return quick_calc_cached(cache, params, p) + +def quick_calc_cached(cache, params, p): + P = params["P"] + if p < len(cache): + return cache[p] + else: + x = pow(cache[0], p + 1, P) + for _ in range(params["k"]): + x ^= quick_calc_cached(cache, params, x % p) + return pow(x, params["w"], P) + +def quick_hashimoto(seed, dagsize, params, header, nonce): + cache = produce_dag(params, seed, params["cache_size"]) + return quick_hashimoto_cached(cache, dagsize, params, header, nonce) + +def quick_hashimoto_cached(cache, dagsize, params, header, nonce): + m = dagsize // 2 + mask = 2**64 - 1 + mix = sha3(encode_int(nonce) + header) + for _ in range(params["accesses"]): + mix ^= quick_calc_cached(cache, params, m + (mix & mask) % m) + return dbl_sha3(mix) +``` diff --git a/public/content/translations/ru/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md b/public/content/translations/ru/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md new file mode 100644 index 00000000000..9c8466a2586 --- /dev/null +++ b/public/content/translations/ru/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md @@ -0,0 +1,1021 @@ +--- +title: Ethash +description: "Подробный обзор алгоритма Ethash." +lang: ru +--- + + + + + + Ethash был алгоритмом майнинга Ethereum с доказательством работы. Доказательство работы теперь **полностью отключено**, и Ethereum теперь защищен с помощью [доказательства владения](/developers/docs/consensus-mechanisms/pos/) . Подробнее о [Слиянии](/roadmap/merge/), [доказательстве владения](/developers/docs/consensus-mechanisms/pos/) и [стейкинге](/staking/). В этой статье много чего интересного! + + + + +Ethash — это модифицированная версия алгоритма [Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto). Алгоритм доказательства работы Ethash [требователен к памяти](https://wikipedia.org/wiki/Memory-hard_function), что, как считалось, делает его устойчивым к ASIC. В конечном итоге были разработаны Ethash ASIC, но майнинг на графическом процессоре все еще оставался жизнеспособным вариантом, пока не было отключено доказательство работы. Ethash по-прежнему используется для майнинга других монет в других не-Ethereum сетях доказательства работы. + +## Как работает Ethash? {#how-does-ethash-work} + +Требовательность к памяти достигается с помощью алгоритма доказательства работы, который требует выбора подмножеств фиксированного ресурса в зависимости от нонса и заголовка блока. Этот ресурс (размером в несколько гигабайт) называется DAG. DAG изменяется каждые 30 000 блоков, то есть в ~125-часовое окно, называемое эпохой (примерно 5,2 дня), и для его генерации требуется некоторое время. Поскольку DAG зависит только от высоты блока, его можно сгенерировать заранее, но если этого не сделать, клиенту придется дождаться окончания этого процесса, чтобы создать блок. Если клиенты не генерируют и не кэшируют DAG заранее, в сети может возникнуть значительная задержка блоков при каждом переходе между эпохами. Обратите внимание, что DAG не нужно генерировать для проверки доказательства работы, что по сути позволяет проводить проверку при низкой загрузке ЦП и небольшом объеме памяти. + +Общая схема работы алгоритма следующая: + +1. Существует **начальное значение (сид)**, которое можно вычислить для каждого блока путем сканирования заголовков блоков до этого момента. +2. Из сида можно вычислить **псевдослучайный кэш размером 16 МБ**. Легкие клиенты хранят кэш. +3. Из кэша мы можем сгенерировать **набор данных размером 1 ГБ** со свойством, что каждый элемент в наборе данных зависит только от небольшого числа элементов из кэша. Полные клиенты и майнеры хранят набор данных. Набор данных растет линейно со временем. +4. Майнинг включает в себя получение случайных срезов набора данных и их совместное хэширование. Проверку можно выполнить с небольшим объемом памяти, используя кэш для восстановления необходимых частей набора данных, поэтому вам нужно хранить только кэш. + +Большой набор данных обновляется каждые 30 000 блоков, поэтому подавляющее большинство усилий майнера будет направлено на чтение набора данных, а не на внесение в него изменений. + +## Определения {#definitions} + +Мы используем следующие определения: + +``` +WORD_BYTES = 4 # байт в слове +DATASET_BYTES_INIT = 2**30 # байт в наборе данных при генезисе +DATASET_BYTES_GROWTH = 2**23 # прирост набора данных за эпоху +CACHE_BYTES_INIT = 2**24 # байт в кэше при генезисе +CACHE_BYTES_GROWTH = 2**17 # прирост кэша за эпоху +CACHE_MULTIPLIER=1024 # Размер DAG относительно кэша +EPOCH_LENGTH = 30000 # блоков за эпоху +MIX_BYTES = 128 # ширина mix +HASH_BYTES = 64 # длина хэша в байтах +DATASET_PARENTS = 256 # количество родителей каждого элемента набора данных +CACHE_ROUNDS = 3 # количество раундов при создании кэша +ACCESSES = 64 # количество обращений в цикле hashimoto +``` + +### Использование SHA3 {#sha3} + +Разработка Ethereum совпала с разработкой стандарта SHA3, и в процессе стандартизации в последний момент было внесено изменение в дополнение (padding) финального алгоритма хэширования, так что хэши Ethereum +«sha3_256» и «sha3_512» не являются стандартными хэшами SHA3, а вариантом, который в других контекстах часто называют +«Keccak-256» и «Keccak-512». См. обсуждение, например, [здесь](https://eips.ethereum.org/EIPS/eip-1803), [здесь](http://ethereum.stackexchange.com/questions/550/which-cryptographic-hash-function-does-ethereum-use) или [здесь](http://bitcoin.stackexchange.com/questions/42055/what-is-the-approach-to-calculate-an-ethereum-address-from-a-256-bit-private-key/42057#42057). + +Пожалуйста, имейте это в виду, поскольку хэши "sha3" упоминаются в описании алгоритма ниже. + +## Параметры {#parameters} + +Параметры кэша и набора данных Ethash зависят от номера блока. Размеры кэша и набора данных растут линейно; однако мы всегда берем наибольшее простое число ниже линейно растущего порога, чтобы снизить риск случайных закономерностей, ведущих к циклическому поведению. + +```python +def get_cache_size(block_number): + sz = CACHE_BYTES_INIT + CACHE_BYTES_GROWTH * (block_number // EPOCH_LENGTH) + sz -= HASH_BYTES + while not isprime(sz / HASH_BYTES): + sz -= 2 * HASH_BYTES + return sz + +def get_full_size(block_number): + sz = DATASET_BYTES_INIT + DATASET_BYTES_GROWTH * (block_number // EPOCH_LENGTH) + sz -= MIX_BYTES + while not isprime(sz / MIX_BYTES): + sz -= 2 * MIX_BYTES + return sz +``` + +Таблицы со значениями размеров набора данных и кэша приведены в приложении. + +## Генерация кэша {#cache-generation} + +Теперь мы определим функцию для создания кэша: + +```python +def mkcache(cache_size, seed): + n = cache_size // HASH_BYTES + + # Последовательно создаем начальный набор данных + o = [sha3_512(seed)] + for i in range(1, n): + o.append(sha3_512(o[-1])) + + # Используем версию randmemohash с малым количеством раундов + for _ in range(CACHE_ROUNDS): + for i in range(n): + v = o[i][0] % n + o[i] = sha3_512(map(xor, o[(i-1+n) % n], o[v])) + + return o +``` + +Процесс создания кэша включает в себя сначала последовательное заполнение 32 МБ памяти, а затем выполнение двух проходов алгоритма _RandMemoHash_ Серджио Демиана Лернера из [_«Strict Memory Hard Hashing Functions»_ (2014)](http://www.hashcash.org/papers/memohash.pdf). Результатом является набор из 524 288 64-байтовых значений. + +## Функция агрегирования данных {#date-aggregation-function} + +В некоторых случаях мы используем алгоритм, вдохновленный [хэшем FNV](https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function), в качестве неассоциативной замены для XOR. Обратите внимание, что мы умножаем простое число на полный 32-битный ввод, в отличие от спецификации FNV-1, которая поочередно умножает простое число на один байт (октет). + +```python +FNV_PRIME = 0x01000193 + +def fnv(v1, v2): + return ((v1 * FNV_PRIME) ^ v2) % 2**32 +``` + +Обратите внимание, что, хотя в Yellow Paper для fnv указано v1\*(FNV_PRIME ^ v2), все текущие реализации последовательно используют приведенное выше определение. + +## Вычисление полного набора данных {#full-dataset-calculation} + +Каждый 64-байтовый элемент в полном наборе данных размером 1 ГБ вычисляется следующим образом: + +```python +def calc_dataset_item(cache, i): + n = len(cache) + r = HASH_BYTES // WORD_BYTES + # инициализируем mix + mix = copy.copy(cache[i % n]) + mix[0] ^= i + mix = sha3_512(mix) + # применяем к нему fnv с большим количеством случайных узлов кэша на основе i + for j in range(DATASET_PARENTS): + cache_index = fnv(i ^ j, mix[j % r]) + mix = map(fnv, mix, cache[cache_index % n]) + return sha3_512(mix) +``` + +По сути, мы объединяем данные из 256 псевдослучайно выбранных узлов кэша и хэшируем их для вычисления узла набора данных. Затем весь набор данных генерируется с помощью: + +```python +def calc_dataset(full_size, cache): + return [calc_dataset_item(cache, i) for i in range(full_size // HASH_BYTES)] +``` + +## Основной цикл {#main-loop} + +Теперь мы опишем основной цикл, подобный «hashimoto», в котором мы агрегируем данные из полного набора данных, чтобы получить конечное значение для определенного заголовка и нонса. В приведенном ниже коде `header` представляет собой _хэш_ SHA3-256 от RLP-представления _усеченного_ заголовка блока, то есть заголовка, исключающего поля **mixHash** и **nonce**. `nonce` — это восемь байт 64-битного беззнакового целого числа в порядке от старшего к младшему (big-endian). Таким образом, `nonce[::-1]` — это восьмибайтовое представление этого значения в порядке от младшего к старшему (little-endian): + +```python +def hashimoto(header, nonce, full_size, dataset_lookup): + n = full_size / HASH_BYTES + w = MIX_BYTES // WORD_BYTES + mixhashes = MIX_BYTES / HASH_BYTES + # объединяем header+nonce в 64-байтовый сид + s = sha3_512(header + nonce[::-1]) + # начинаем mix с реплицированного s + mix = [] + for _ in range(MIX_BYTES / HASH_BYTES): + mix.extend(s) + # подмешиваем случайные узлы набора данных + for i in range(ACCESSES): + p = fnv(i ^ s[0], mix[i % w]) % (n // mixhashes) * mixhashes + newdata = [] + for j in range(MIX_BYTES / HASH_BYTES): + newdata.extend(dataset_lookup(p + j)) + mix = map(fnv, mix, newdata) + # сжимаем mix + cmix = [] + for i in range(0, len(mix), 4): + cmix.append(fnv(fnv(fnv(mix[i], mix[i+1]), mix[i+2]), mix[i+3])) + return { + "mix digest": serialize_hash(cmix), + "result": serialize_hash(sha3_256(s+cmix)) + } + +def hashimoto_light(full_size, cache, header, nonce): + return hashimoto(header, nonce, full_size, lambda x: calc_dataset_item(cache, x)) + +def hashimoto_full(full_size, dataset, header, nonce): + return hashimoto(header, nonce, full_size, lambda x: dataset[x]) +``` + +По сути, мы поддерживаем «mix» шириной 128 байт, и многократно последовательно извлекаем 128 байт из полного набора данных и используем функцию `fnv` для их объединения с mix. 128 байт последовательного доступа используются для того, чтобы каждый раунд алгоритма всегда извлекал полную страницу из ОЗУ, минимизируя промахи буфера ассоциативной трансляции (TLB), которых теоретически могли бы избежать ASIC. + +Если результат работы этого алгоритма ниже желаемого целевого значения, то нонс считается действительным. Обратите внимание, что дополнительное применение `sha3_256` в конце гарантирует существование промежуточного нонса, который можно предоставить для доказательства того, что была проделана хотя бы небольшая работа; эта быстрая внешняя проверка PoW может использоваться для защиты от DDoS-атак. Это также служит для статистической гарантии того, что результат является несмещенным 256-битным числом. + +## Майнинг {#mining} + +Алгоритм майнинга определяется следующим образом: + +```python +def mine(full_size, dataset, header, difficulty): + # дополняем нулями target, чтобы сравнивать с хэшем одинаковой длины + target = zpad(encode_int(2**256 // difficulty), 64)[::-1] + from random import randint + nonce = randint(0, 2**64) + while hashimoto_full(full_size, dataset, header, nonce) > target: + nonce = (nonce + 1) % 2**64 + return nonce +``` + +## Определение хэша сида {#seed-hash} + +Чтобы вычислить хэш сида, который будет использоваться для майнинга поверх данного блока, мы используем следующий алгоритм: + +```python + def get_seedhash(block): + s = '\x00' * 32 + for i in range(block.number // EPOCH_LENGTH): + s = serialize_hash(sha3_256(s)) + return s +``` + +Обратите внимание, что для бесперебойного майнинга и проверки мы рекомендуем предварительно вычислять будущие хэши сидов и наборы данных в отдельном потоке. + +## Дополнительные материалы {#further-reading} + +_Знаете ресурс сообщества, который вам пригодился? Измените эту страницу и добавьте его!_ + +## Приложение {#appendix} + +Следующий код следует добавить в начало, если вы хотите запустить приведенную выше спецификацию на Python как код. + +```python +import sha3, copy + +# Предполагается порядок битов от младшего к старшему (little-endian), как в архитектурах Intel +def decode_int(s): + return int(s[::-1].encode('hex'), 16) if s else 0 + +def encode_int(s): + a = "%x" % s + return '' if s == 0 else ('0' * (len(a) % 2) + a).decode('hex')[::-1] + +def zpad(s, length): + return s + '\x00' * max(0, length - len(s)) + +def serialize_hash(h): + return ''.join([zpad(encode_int(x), 4) for x in h]) + +def deserialize_hash(h): + return [decode_int(h[i:i+WORD_BYTES]) for i in range(0, len(h), WORD_BYTES)] + +def hash_words(h, sz, x): + if isinstance(x, list): + x = serialize_hash(x) + y = h(x) + return deserialize_hash(y) + +def serialize_cache(ds): + return ''.join([serialize_hash(h) for h in ds]) + +serialize_dataset = serialize_cache + +# хэш-функция sha3, выводит 64 байта +def sha3_512(x): + return hash_words(lambda v: sha3.sha3_512(v).digest(), 64, x) + +def sha3_256(x): + return hash_words(lambda v: sha3.sha3_256(v).digest(), 32, x) + +def xor(a, b): + return a ^ b + +def isprime(x): + for i in range(2, int(x**0.5)): + if x % i == 0: + return False + return True +``` + +### Размеры данных {#data-sizes} + +Следующие справочные таблицы содержат примерно 2048 табличных эпох с размерами данных и кэша. + +```python +def get_datasize(block_number): + return data_sizes[block_number // EPOCH_LENGTH] + +def get_cachesize(block_number): + return cache_sizes[block_number // EPOCH_LENGTH] + +data_sizes = [ +1073739904, 1082130304, 1090514816, 1098906752, 1107293056, +1115684224, 1124070016, 1132461952, 1140849536, 1149232768, +1157627776, 1166013824, 1174404736, 1182786944, 1191180416, +1199568512, 1207958912, 1216345216, 1224732032, 1233124736, +1241513344, 1249902464, 1258290304, 1266673792, 1275067264, +1283453312, 1291844992, 1300234112, 1308619904, 1317010048, +1325397376, 1333787776, 1342176128, 1350561664, 1358954368, +1367339392, 1375731584, 1384118144, 1392507008, 1400897408, +1409284736, 1417673344, 1426062464, 1434451072, 1442839168, +1451229056, 1459615616, 1468006016, 1476394112, 1484782976, +1493171584, 1501559168, 1509948032, 1518337664, 1526726528, +1535114624, 1543503488, 1551892096, 1560278656, 1568669056, +1577056384, 1585446272, 1593831296, 1602219392, 1610610304, +1619000192, 1627386752, 1635773824, 1644164224, 1652555648, +1660943488, 1669332608, 1677721216, 1686109312, 1694497664, +1702886272, 1711274624, 1719661184, 1728047744, 1736434816, +1744829056, 1753218944, 1761606272, 1769995904, 1778382464, +1786772864, 1795157888, 1803550592, 1811937664, 1820327552, +1828711552, 1837102976, 1845488768, 1853879936, 1862269312, +1870656896, 1879048064, 1887431552, 1895825024, 1904212096, +1912601216, 1920988544, 1929379456, 1937765504, 1946156672, +1954543232, 1962932096, 1971321728, 1979707264, 1988093056, +1996487552, 2004874624, 2013262208, 2021653888, 2030039936, +2038430848, 2046819968, 2055208576, 2063596672, 2071981952, +2080373632, 2088762752, 2097149056, 2105539712, 2113928576, +2122315136, 2130700672, 2139092608, 2147483264, 2155872128, +2164257664, 2172642176, 2181035392, 2189426048, 2197814912, +2206203008, 2214587264, 2222979712, 2231367808, 2239758208, +2248145024, 2256527744, 2264922752, 2273312128, 2281701248, +2290086272, 2298476672, 2306867072, 2315251072, 2323639168, +2332032128, 2340420224, 2348808064, 2357196416, 2365580416, +2373966976, 2382363008, 2390748544, 2399139968, 2407530368, +2415918976, 2424307328, 2432695424, 2441084288, 2449472384, +2457861248, 2466247808, 2474637184, 2483026816, 2491414144, +2499803776, 2508191872, 2516582272, 2524970368, 2533359232, +2541743488, 2550134144, 2558525056, 2566913408, 2575301504, +2583686528, 2592073856, 2600467328, 2608856192, 2617240448, +2625631616, 2634022016, 2642407552, 2650796416, 2659188352, +2667574912, 2675965312, 2684352896, 2692738688, 2701130624, +2709518464, 2717907328, 2726293376, 2734685056, 2743073152, +2751462016, 2759851648, 2768232832, 2776625536, 2785017728, +2793401984, 2801794432, 2810182016, 2818571648, 2826959488, +2835349376, 2843734144, 2852121472, 2860514432, 2868900992, +2877286784, 2885676928, 2894069632, 2902451584, 2910843008, +2919234688, 2927622784, 2936011648, 2944400768, 2952789376, +2961177728, 2969565568, 2977951616, 2986338944, 2994731392, +3003120256, 3011508352, 3019895936, 3028287104, 3036675968, +3045063808, 3053452928, 3061837696, 3070228352, 3078615424, +3087003776, 3095394944, 3103782272, 3112173184, 3120562048, +3128944768, 3137339264, 3145725056, 3154109312, 3162505088, +3170893184, 3179280256, 3187669376, 3196056704, 3204445568, +3212836736, 3221224064, 3229612928, 3238002304, 3246391168, +3254778496, 3263165824, 3271556224, 3279944576, 3288332416, +3296719232, 3305110912, 3313500032, 3321887104, 3330273152, +3338658944, 3347053184, 3355440512, 3363827072, 3372220288, +3380608384, 3388997504, 3397384576, 3405774208, 3414163072, +3422551936, 3430937984, 3439328384, 3447714176, 3456104576, +3464493952, 3472883584, 3481268864, 3489655168, 3498048896, +3506434432, 3514826368, 3523213952, 3531603584, 3539987072, +3548380288, 3556763264, 3565157248, 3573545344, 3581934464, +3590324096, 3598712704, 3607098752, 3615488384, 3623877248, +3632265856, 3640646528, 3649043584, 3657430144, 3665821568, +3674207872, 3682597504, 3690984832, 3699367808, 3707764352, +3716152448, 3724541056, 3732925568, 3741318016, 3749706368, +3758091136, 3766481536, 3774872704, 3783260032, 3791650432, +3800036224, 3808427648, 3816815488, 3825204608, 3833592704, +3841981568, 3850370432, 3858755968, 3867147904, 3875536256, +3883920512, 3892313728, 3900702592, 3909087872, 3917478784, +3925868416, 3934256512, 3942645376, 3951032192, 3959422336, +3967809152, 3976200064, 3984588416, 3992974976, 4001363584, +4009751168, 4018141312, 4026530432, 4034911616, 4043308928, +4051695488, 4060084352, 4068472448, 4076862848, 4085249408, +4093640576, 4102028416, 4110413696, 4118805632, 4127194496, +4135583104, 4143971968, 4152360832, 4160746112, 4169135744, +4177525888, 4185912704, 4194303616, 4202691968, 4211076736, +4219463552, 4227855488, 4236246656, 4244633728, 4253022848, +4261412224, 4269799808, 4278184832, 4286578048, 4294962304, +4303349632, 4311743104, 4320130432, 4328521088, 4336909184, +4345295488, 4353687424, 4362073472, 4370458496, 4378852736, +4387238528, 4395630208, 4404019072, 4412407424, 4420790656, +4429182848, 4437571456, 4445962112, 4454344064, 4462738048, +4471119232, 4479516544, 4487904128, 4496289664, 4504682368, +4513068416, 4521459584, 4529846144, 4538232704, 4546619776, +4555010176, 4563402112, 4571790208, 4580174464, 4588567936, +4596957056, 4605344896, 4613734016, 4622119808, 4630511488, +4638898816, 4647287936, 4655675264, 4664065664, 4672451968, +4680842624, 4689231488, 4697620352, 4706007424, 4714397056, +4722786176, 4731173248, 4739562368, 4747951744, 4756340608, +4764727936, 4773114496, 4781504384, 4789894784, 4798283648, +4806667648, 4815059584, 4823449472, 4831835776, 4840226176, +4848612224, 4857003392, 4865391488, 4873780096, 4882169728, +4890557312, 4898946944, 4907333248, 4915722368, 4924110976, +4932499328, 4940889728, 4949276032, 4957666432, 4966054784, +4974438016, 4982831488, 4991221376, 4999607168, 5007998848, +5016386432, 5024763776, 5033164672, 5041544576, 5049941888, +5058329728, 5066717056, 5075107456, 5083494272, 5091883904, +5100273536, 5108662144, 5117048192, 5125436032, 5133827456, +5142215296, 5150605184, 5158993024, 5167382144, 5175769472, +5184157568, 5192543872, 5200936064, 5209324928, 5217711232, +5226102656, 5234490496, 5242877312, 5251263872, 5259654016, +5268040832, 5276434304, 5284819328, 5293209728, 5301598592, +5309986688, 5318374784, 5326764416, 5335151488, 5343542144, +5351929472, 5360319872, 5368706944, 5377096576, 5385484928, +5393871232, 5402263424, 5410650496, 5419040384, 5427426944, +5435816576, 5444205952, 5452594816, 5460981376, 5469367936, +5477760896, 5486148736, 5494536832, 5502925952, 5511315328, +5519703424, 5528089984, 5536481152, 5544869504, 5553256064, +5561645696, 5570032768, 5578423936, 5586811264, 5595193216, +5603585408, 5611972736, 5620366208, 5628750464, 5637143936, +5645528192, 5653921408, 5662310272, 5670694784, 5679082624, +5687474048, 5695864448, 5704251008, 5712641408, 5721030272, +5729416832, 5737806208, 5746194304, 5754583936, 5762969984, +5771358592, 5779748224, 5788137856, 5796527488, 5804911232, +5813300608, 5821692544, 5830082176, 5838468992, 5846855552, +5855247488, 5863636096, 5872024448, 5880411008, 5888799872, +5897186432, 5905576832, 5913966976, 5922352768, 5930744704, +5939132288, 5947522432, 5955911296, 5964299392, 5972688256, +5981074304, 5989465472, 5997851008, 6006241408, 6014627968, +6023015552, 6031408256, 6039796096, 6048185216, 6056574848, +6064963456, 6073351808, 6081736064, 6090128768, 6098517632, +6106906496, 6115289216, 6123680896, 6132070016, 6140459648, +6148849024, 6157237376, 6165624704, 6174009728, 6182403712, +6190792064, 6199176064, 6207569792, 6215952256, 6224345216, +6232732544, 6241124224, 6249510272, 6257899136, 6266287744, +6274676864, 6283065728, 6291454336, 6299843456, 6308232064, +6316620928, 6325006208, 6333395584, 6341784704, 6350174848, +6358562176, 6366951296, 6375337856, 6383729536, 6392119168, +6400504192, 6408895616, 6417283456, 6425673344, 6434059136, +6442444672, 6450837376, 6459223424, 6467613056, 6476004224, +6484393088, 6492781952, 6501170048, 6509555072, 6517947008, +6526336384, 6534725504, 6543112832, 6551500672, 6559888768, +6568278656, 6576662912, 6585055616, 6593443456, 6601834112, +6610219648, 6618610304, 6626999168, 6635385472, 6643777408, +6652164224, 6660552832, 6668941952, 6677330048, 6685719424, +6694107776, 6702493568, 6710882176, 6719274112, 6727662976, +6736052096, 6744437632, 6752825984, 6761213824, 6769604224, +6777993856, 6786383488, 6794770816, 6803158144, 6811549312, +6819937664, 6828326528, 6836706176, 6845101696, 6853491328, +6861880448, 6870269312, 6878655104, 6887046272, 6895433344, +6903822208, 6912212864, 6920596864, 6928988288, 6937377152, +6945764992, 6954149248, 6962544256, 6970928768, 6979317376, +6987709312, 6996093824, 7004487296, 7012875392, 7021258624, +7029652352, 7038038912, 7046427776, 7054818944, 7063207808, +7071595136, 7079980928, 7088372608, 7096759424, 7105149824, +7113536896, 7121928064, 7130315392, 7138699648, 7147092352, +7155479168, 7163865728, 7172249984, 7180648064, 7189036672, +7197424768, 7205810816, 7214196608, 7222589824, 7230975104, +7239367552, 7247755904, 7256145536, 7264533376, 7272921472, +7281308032, 7289694848, 7298088832, 7306471808, 7314864512, +7323253888, 7331643008, 7340029568, 7348419712, 7356808832, +7365196672, 7373585792, 7381973888, 7390362752, 7398750592, +7407138944, 7415528576, 7423915648, 7432302208, 7440690304, +7449080192, 7457472128, 7465860992, 7474249088, 7482635648, +7491023744, 7499412608, 7507803008, 7516192384, 7524579968, +7532967296, 7541358464, 7549745792, 7558134656, 7566524032, +7574912896, 7583300992, 7591690112, 7600075136, 7608466816, +7616854912, 7625244544, 7633629824, 7642020992, 7650410368, +7658794112, 7667187328, 7675574912, 7683961984, 7692349568, +7700739712, 7709130368, 7717519232, 7725905536, 7734295424, +7742683264, 7751069056, 7759457408, 7767849088, 7776238208, +7784626816, 7793014912, 7801405312, 7809792128, 7818179968, +7826571136, 7834957184, 7843347328, 7851732352, 7860124544, +7868512384, 7876902016, 7885287808, 7893679744, 7902067072, +7910455936, 7918844288, 7927230848, 7935622784, 7944009344, +7952400256, 7960786048, 7969176704, 7977565312, 7985953408, +7994339968, 8002730368, 8011119488, 8019508096, 8027896192, +8036285056, 8044674688, 8053062272, 8061448832, 8069838464, +8078227328, 8086616704, 8095006592, 8103393664, 8111783552, +8120171392, 8128560256, 8136949376, 8145336704, 8153726848, +8162114944, 8170503296, 8178891904, 8187280768, 8195669632, +8204058496, 8212444544, 8220834176, 8229222272, 8237612672, +8246000768, 8254389376, 8262775168, 8271167104, 8279553664, +8287944064, 8296333184, 8304715136, 8313108352, 8321497984, +8329885568, 8338274432, 8346663296, 8355052928, 8363441536, +8371828352, 8380217984, 8388606592, 8396996224, 8405384576, +8413772672, 8422161536, 8430549376, 8438939008, 8447326592, +8455715456, 8464104832, 8472492928, 8480882048, 8489270656, +8497659776, 8506045312, 8514434944, 8522823808, 8531208832, +8539602304, 8547990656, 8556378752, 8564768384, 8573154176, +8581542784, 8589933952, 8598322816, 8606705024, 8615099264, +8623487872, 8631876992, 8640264064, 8648653952, 8657040256, +8665430656, 8673820544, 8682209152, 8690592128, 8698977152, +8707374464, 8715763328, 8724151424, 8732540032, 8740928384, +8749315712, 8757704576, 8766089344, 8774480768, 8782871936, +8791260032, 8799645824, 8808034432, 8816426368, 8824812928, +8833199488, 8841591424, 8849976448, 8858366336, 8866757248, +8875147136, 8883532928, 8891923328, 8900306816, 8908700288, +8917088384, 8925478784, 8933867392, 8942250368, 8950644608, +8959032704, 8967420544, 8975809664, 8984197504, 8992584064, +9000976256, 9009362048, 9017752448, 9026141312, 9034530688, +9042917504, 9051307904, 9059694208, 9068084864, 9076471424, +9084861824, 9093250688, 9101638528, 9110027648, 9118416512, +9126803584, 9135188096, 9143581312, 9151969664, 9160356224, +9168747136, 9177134464, 9185525632, 9193910144, 9202302848, +9210690688, 9219079552, 9227465344, 9235854464, 9244244864, +9252633472, 9261021824, 9269411456, 9277799296, 9286188928, +9294574208, 9302965888, 9311351936, 9319740032, 9328131968, +9336516736, 9344907392, 9353296768, 9361685888, 9370074752, +9378463616, 9386849408, 9395239808, 9403629184, 9412016512, +9420405376, 9428795008, 9437181568, 9445570688, 9453960832, +9462346624, 9470738048, 9479121536, 9487515008, 9495903616, +9504289664, 9512678528, 9521067904, 9529456256, 9537843584, +9546233728, 9554621312, 9563011456, 9571398784, 9579788672, +9588178304, 9596567168, 9604954496, 9613343104, 9621732992, +9630121856, 9638508416, 9646898816, 9655283584, 9663675776, +9672061312, 9680449664, 9688840064, 9697230464, 9705617536, +9714003584, 9722393984, 9730772608, 9739172224, 9747561088, +9755945344, 9764338816, 9772726144, 9781116544, 9789503872, +9797892992, 9806282624, 9814670464, 9823056512, 9831439232, +9839833984, 9848224384, 9856613504, 9865000576, 9873391232, +9881772416, 9890162816, 9898556288, 9906940544, 9915333248, +9923721088, 9932108672, 9940496512, 9948888448, 9957276544, +9965666176, 9974048384, 9982441088, 9990830464, 9999219584, +10007602816, 10015996544, 10024385152, 10032774016, 10041163648, +10049548928, 10057940096, 10066329472, 10074717824, 10083105152, +10091495296, 10099878784, 10108272256, 10116660608, 10125049216, +10133437312, 10141825664, 10150213504, 10158601088, 10166991232, +10175378816, 10183766144, 10192157312, 10200545408, 10208935552, +10217322112, 10225712768, 10234099328, 10242489472, 10250876032, +10259264896, 10267656064, 10276042624, 10284429184, 10292820352, +10301209472, 10309598848, 10317987712, 10326375296, 10334763392, +10343153536, 10351541632, 10359930752, 10368318592, 10376707456, +10385096576, 10393484672, 10401867136, 10410262144, 10418647424, +10427039104, 10435425664, 10443810176, 10452203648, 10460589952, +10468982144, 10477369472, 10485759104, 10494147712, 10502533504, +10510923392, 10519313536, 10527702656, 10536091264, 10544478592, +10552867712, 10561255808, 10569642368, 10578032768, 10586423168, +10594805632, 10603200128, 10611588992, 10619976064, 10628361344, +10636754048, 10645143424, 10653531776, 10661920384, 10670307968, +10678696832, 10687086464, 10695475072, 10703863168, 10712246144, +10720639616, 10729026688, 10737414784, 10745806208, 10754190976, +10762581376, 10770971264, 10779356288, 10787747456, 10796135552, +10804525184, 10812915584, 10821301888, 10829692288, 10838078336, +10846469248, 10854858368, 10863247232, 10871631488, 10880023424, +10888412032, 10896799616, 10905188992, 10913574016, 10921964672, +10930352768, 10938742912, 10947132544, 10955518592, 10963909504, +10972298368, 10980687488, 10989074816, 10997462912, 11005851776, +11014241152, 11022627712, 11031017344, 11039403904, 11047793024, +11056184704, 11064570752, 11072960896, 11081343872, 11089737856, +11098128256, 11106514816, 11114904448, 11123293568, 11131680128, +11140065152, 11148458368, 11156845696, 11165236864, 11173624192, +11182013824, 11190402688, 11198790784, 11207179136, 11215568768, +11223957376, 11232345728, 11240734592, 11249122688, 11257511296, +11265899648, 11274285952, 11282675584, 11291065472, 11299452544, +11307842432, 11316231296, 11324616832, 11333009024, 11341395584, +11349782656, 11358172288, 11366560384, 11374950016, 11383339648, +11391721856, 11400117376, 11408504192, 11416893568, 11425283456, +11433671552, 11442061184, 11450444672, 11458837888, 11467226752, +11475611776, 11484003968, 11492392064, 11500780672, 11509169024, +11517550976, 11525944448, 11534335616, 11542724224, 11551111808, +11559500672, 11567890304, 11576277376, 11584667008, 11593056128, +11601443456, 11609830016, 11618221952, 11626607488, 11634995072, +11643387776, 11651775104, 11660161664, 11668552576, 11676940928, +11685330304, 11693718656, 11702106496, 11710496128, 11718882688, +11727273088, 11735660416, 11744050048, 11752437376, 11760824704, +11769216128, 11777604736, 11785991296, 11794381952, 11802770048, +11811157888, 11819548544, 11827932544, 11836324736, 11844713344, +11853100928, 11861486464, 11869879936, 11878268032, 11886656896, +11895044992, 11903433088, 11911822976, 11920210816, 11928600448, +11936987264, 11945375872, 11953761152, 11962151296, 11970543488, +11978928512, 11987320448, 11995708288, 12004095104, 12012486272, +12020875136, 12029255552, 12037652096, 12046039168, 12054429568, +12062813824, 12071206528, 12079594624, 12087983744, 12096371072, +12104759936, 12113147264, 12121534592, 12129924992, 12138314624, +12146703232, 12155091584, 12163481216, 12171864704, 12180255872, +12188643968, 12197034112, 12205424512, 12213811328, 12222199424, +12230590336, 12238977664, 12247365248, 12255755392, 12264143488, +12272531584, 12280920448, 12289309568, 12297694592, 12306086528, +12314475392, 12322865024, 12331253632, 12339640448, 12348029312, +12356418944, 12364805248, 12373196672, 12381580928, 12389969024, +12398357632, 12406750592, 12415138432, 12423527552, 12431916416, +12440304512, 12448692352, 12457081216, 12465467776, 12473859968, +12482245504, 12490636672, 12499025536, 12507411584, 12515801728, +12524190592, 12532577152, 12540966272, 12549354368, 12557743232, +12566129536, 12574523264, 12582911872, 12591299456, 12599688064, +12608074624, 12616463488, 12624845696, 12633239936, 12641631616, +12650019968, 12658407296, 12666795136, 12675183232, 12683574656, +12691960192, 12700350592, 12708740224, 12717128576, 12725515904, +12733906816, 12742295168, 12750680192, 12759071872, 12767460736, +12775848832, 12784236928, 12792626816, 12801014656, 12809404288, +12817789312, 12826181504, 12834568832, 12842954624, 12851345792, +12859732352, 12868122496, 12876512128, 12884901248, 12893289088, +12901672832, 12910067584, 12918455168, 12926842496, 12935232896, +12943620736, 12952009856, 12960396928, 12968786816, 12977176192, +12985563776, 12993951104, 13002341504, 13010730368, 13019115392, +13027506304, 13035895168, 13044272512, 13052673152, 13061062528, +13069446272, 13077838976, 13086227072, 13094613632, 13103000192, +13111393664, 13119782528, 13128157568, 13136559232, 13144945024, +13153329536, 13161724288, 13170111872, 13178502784, 13186884736, +13195279744, 13203667072, 13212057472, 13220445824, 13228832128, +13237221248, 13245610624, 13254000512, 13262388352, 13270777472, +13279166336, 13287553408, 13295943296, 13304331904, 13312719488, +13321108096, 13329494656, 13337885824, 13346274944, 13354663808, +13363051136, 13371439232, 13379825024, 13388210816, 13396605056, +13404995456, 13413380224, 13421771392, 13430159744, 13438546048, +13446937216, 13455326848, 13463708288, 13472103808, 13480492672, +13488875648, 13497269888, 13505657728, 13514045312, 13522435712, +13530824576, 13539210112, 13547599232, 13555989376, 13564379008, +13572766336, 13581154432, 13589544832, 13597932928, 13606320512, +13614710656, 13623097472, 13631477632, 13639874944, 13648264064, +13656652928, 13665041792, 13673430656, 13681818496, 13690207616, +13698595712, 13706982272, 13715373184, 13723762048, 13732150144, +13740536704, 13748926592, 13757316224, 13765700992, 13774090112, +13782477952, 13790869376, 13799259008, 13807647872, 13816036736, +13824425344, 13832814208, 13841202304, 13849591424, 13857978752, +13866368896, 13874754688, 13883145344, 13891533184, 13899919232, +13908311168, 13916692096, 13925085056, 13933473152, 13941866368, +13950253696, 13958643584, 13967032192, 13975417216, 13983807616, +13992197504, 14000582272, 14008973696, 14017363072, 14025752192, +14034137984, 14042528384, 14050918016, 14059301504, 14067691648, +14076083584, 14084470144, 14092852352, 14101249664, 14109635968, +14118024832, 14126407552, 14134804352, 14143188608, 14151577984, +14159968384, 14168357248, 14176741504, 14185127296, 14193521024, +14201911424, 14210301824, 14218685056, 14227067264, 14235467392, +14243855488, 14252243072, 14260630144, 14269021568, 14277409408, +14285799296, 14294187904, 14302571392, 14310961792, 14319353728, +14327738752, 14336130944, 14344518784, 14352906368, 14361296512, +14369685376, 14378071424, 14386462592, 14394848128, 14403230848, +14411627392, 14420013952, 14428402304, 14436793472, 14445181568, +14453569664, 14461959808, 14470347904, 14478737024, 14487122816, +14495511424, 14503901824, 14512291712, 14520677504, 14529064832, +14537456768, 14545845632, 14554234496, 14562618496, 14571011456, +14579398784, 14587789184, 14596172672, 14604564608, 14612953984, +14621341312, 14629724288, 14638120832, 14646503296, 14654897536, +14663284864, 14671675264, 14680061056, 14688447616, 14696835968, +14705228416, 14713616768, 14722003328, 14730392192, 14738784128, +14747172736, 14755561088, 14763947648, 14772336512, 14780725376, +14789110144, 14797499776, 14805892736, 14814276992, 14822670208, +14831056256, 14839444352, 14847836032, 14856222848, 14864612992, +14872997504, 14881388672, 14889775744, 14898165376, 14906553472, +14914944896, 14923329664, 14931721856, 14940109696, 14948497024, +14956887424, 14965276544, 14973663616, 14982053248, 14990439808, +14998830976, 15007216768, 15015605888, 15023995264, 15032385152, +15040768384, 15049154944, 15057549184, 15065939072, 15074328448, +15082715008, 15091104128, 15099493504, 15107879296, 15116269184, +15124659584, 15133042304, 15141431936, 15149824384, 15158214272, +15166602368, 15174991232, 15183378304, 15191760512, 15200154496, +15208542592, 15216931712, 15225323392, 15233708416, 15242098048, +15250489216, 15258875264, 15267265408, 15275654528, 15284043136, +15292431488, 15300819584, 15309208192, 15317596544, 15325986176, +15334374784, 15342763648, 15351151744, 15359540608, 15367929728, +15376318336, 15384706432, 15393092992, 15401481856, 15409869952, +15418258816, 15426649984, 15435037568, 15443425664, 15451815296, +15460203392, 15468589184, 15476979328, 15485369216, 15493755776, +15502146944, 15510534272, 15518924416, 15527311232, 15535699072, +15544089472, 15552478336, 15560866688, 15569254528, 15577642624, +15586031488, 15594419072, 15602809472, 15611199104, 15619586432, +15627975296, 15636364928, 15644753792, 15653141888, 15661529216, +15669918848, 15678305152, 15686696576, 15695083136, 15703474048, +15711861632, 15720251264, 15728636288, 15737027456, 15745417088, +15753804928, 15762194048, 15770582656, 15778971008, 15787358336, +15795747712, 15804132224, 15812523392, 15820909696, 15829300096, +15837691264, 15846071936, 15854466944, 15862855808, 15871244672, +15879634816, 15888020608, 15896409728, 15904799104, 15913185152, +15921577088, 15929966464, 15938354816, 15946743424, 15955129472, +15963519872, 15971907968, 15980296064, 15988684928, 15997073024, +16005460864, 16013851264, 16022241152, 16030629248, 16039012736, +16047406976, 16055794816, 16064181376, 16072571264, 16080957824, +16089346688, 16097737856, 16106125184, 16114514816, 16122904192, +16131292544, 16139678848, 16148066944, 16156453504, 16164839552, +16173236096, 16181623424, 16190012032, 16198401152, 16206790528, +16215177344, 16223567744, 16231956352, 16240344704, 16248731008, +16257117824, 16265504384, 16273898624, 16282281856, 16290668672, +16299064192, 16307449216, 16315842176, 16324230016, 16332613504, +16341006464, 16349394304, 16357783168, 16366172288, 16374561664, +16382951296, 16391337856, 16399726208, 16408116352, 16416505472, +16424892032, 16433282176, 16441668224, 16450058624, 16458448768, +16466836864, 16475224448, 16483613056, 16492001408, 16500391808, +16508779648, 16517166976, 16525555328, 16533944192, 16542330752, +16550719616, 16559110528, 16567497088, 16575888512, 16584274816, +16592665472, 16601051008, 16609442944, 16617832064, 16626218624, +16634607488, 16642996096, 16651385728, 16659773824, 16668163712, +16676552576, 16684938112, 16693328768, 16701718144, 16710095488, +16718492288, 16726883968, 16735272832, 16743661184, 16752049792, +16760436608, 16768827008, 16777214336, 16785599104, 16793992832, +16802381696, 16810768768, 16819151744, 16827542656, 16835934848, +16844323712, 16852711552, 16861101952, 16869489536, 16877876864, +16886265728, 16894653056, 16903044736, 16911431296, 16919821696, +16928207488, 16936592768, 16944987776, 16953375616, 16961763968, +16970152832, 16978540928, 16986929536, 16995319168, 17003704448, +17012096896, 17020481152, 17028870784, 17037262208, 17045649536, +17054039936, 17062426496, 17070814336, 17079205504, 17087592064, +17095978112, 17104369024, 17112759424, 17121147776, 17129536384, +17137926016, 17146314368, 17154700928, 17163089792, 17171480192, +17179864192, 17188256896, 17196644992, 17205033856, 17213423488, +17221811072, 17230198912, 17238588032, 17246976896, 17255360384, +17263754624, 17272143232, 17280530048, 17288918912, 17297309312, +17305696384, 17314085504, 17322475136, 17330863744, 17339252096, +17347640192, 17356026496, 17364413824, 17372796544, 17381190016, +17389583488, 17397972608, 17406360704, 17414748544, 17423135872, +17431527296, 17439915904, 17448303232, 17456691584, 17465081728, +17473468288, 17481857408, 17490247552, 17498635904, 17507022464, +17515409024, 17523801728, 17532189824, 17540577664, 17548966016, +17557353344, 17565741184, 17574131584, 17582519168, 17590907008, +17599296128, 17607687808, 17616076672, 17624455808, 17632852352, +17641238656, 17649630848, 17658018944, 17666403968, 17674794112, +17683178368, 17691573376, 17699962496, 17708350592, 17716739968, +17725126528, 17733517184, 17741898112, 17750293888, 17758673024, +17767070336, 17775458432, 17783848832, 17792236928, 17800625536, +17809012352, 17817402752, 17825785984, 17834178944, 17842563968, +17850955648, 17859344512, 17867732864, 17876119424, 17884511872, +17892900224, 17901287296, 17909677696, 17918058112, 17926451072, +17934843776, 17943230848, 17951609216, 17960008576, 17968397696, +17976784256, 17985175424, 17993564032, 18001952128, 18010339712, +18018728576, 18027116672, 18035503232, 18043894144, 18052283264, +18060672128, 18069056384, 18077449856, 18085837184, 18094225792, +18102613376, 18111004544, 18119388544, 18127781248, 18136170368, +18144558976, 18152947328, 18161336192, 18169724288, 18178108544, +18186498944, 18194886784, 18203275648, 18211666048, 18220048768, +18228444544, 18236833408, 18245220736] + +cache_sizes = [ +16776896, 16907456, 17039296, 17170112, 17301056, 17432512, 17563072, +17693888, 17824192, 17955904, 18087488, 18218176, 18349504, 18481088, +18611392, 18742336, 18874304, 19004224, 19135936, 19267264, 19398208, +19529408, 19660096, 19791424, 19922752, 20053952, 20184896, 20315968, +20446912, 20576576, 20709184, 20840384, 20971072, 21102272, 21233216, +21364544, 21494848, 21626816, 21757376, 21887552, 22019392, 22151104, +22281536, 22412224, 22543936, 22675264, 22806464, 22935872, 23068096, +23198272, 23330752, 23459008, 23592512, 23723968, 23854912, 23986112, +24116672, 24247616, 24378688, 24509504, 24640832, 24772544, 24903488, +25034432, 25165376, 25296704, 25427392, 25558592, 25690048, 25820096, +25951936, 26081728, 26214208, 26345024, 26476096, 26606656, 26737472, +26869184, 26998208, 27131584, 27262528, 27393728, 27523904, 27655744, +27786688, 27917888, 28049344, 28179904, 28311488, 28441792, 28573504, +28700864, 28835648, 28966208, 29096768, 29228608, 29359808, 29490752, +29621824, 29752256, 29882816, 30014912, 30144448, 30273728, 30406976, +30538432, 30670784, 30799936, 30932672, 31063744, 31195072, 31325248, +31456192, 31588288, 31719232, 31850432, 31981504, 32110784, 32243392, +32372672, 32505664, 32636608, 32767808, 32897344, 33029824, 33160768, +33289664, 33423296, 33554368, 33683648, 33816512, 33947456, 34076992, +34208704, 34340032, 34471744, 34600256, 34734016, 34864576, 34993984, +35127104, 35258176, 35386688, 35518528, 35650624, 35782336, 35910976, +36044608, 36175808, 36305728, 36436672, 36568384, 36699968, 36830656, +36961984, 37093312, 37223488, 37355072, 37486528, 37617472, 37747904, +37879232, 38009792, 38141888, 38272448, 38403392, 38535104, 38660672, +38795584, 38925632, 39059264, 39190336, 39320768, 39452096, 39581632, +39713984, 39844928, 39974848, 40107968, 40238144, 40367168, 40500032, +40631744, 40762816, 40894144, 41023552, 41155904, 41286208, 41418304, +41547712, 41680448, 41811904, 41942848, 42073792, 42204992, 42334912, +42467008, 42597824, 42729152, 42860096, 42991552, 43122368, 43253696, +43382848, 43515712, 43646912, 43777088, 43907648, 44039104, 44170432, +44302144, 44433344, 44564288, 44694976, 44825152, 44956864, 45088448, +45219008, 45350464, 45481024, 45612608, 45744064, 45874496, 46006208, +46136768, 46267712, 46399424, 46529344, 46660672, 46791488, 46923328, +47053504, 47185856, 47316928, 47447872, 47579072, 47710144, 47839936, +47971648, 48103232, 48234176, 48365248, 48496192, 48627136, 48757312, +48889664, 49020736, 49149248, 49283008, 49413824, 49545152, 49675712, +49807168, 49938368, 50069056, 50200256, 50331584, 50462656, 50593472, +50724032, 50853952, 50986048, 51117632, 51248576, 51379904, 51510848, +51641792, 51773248, 51903296, 52035136, 52164032, 52297664, 52427968, +52557376, 52690112, 52821952, 52952896, 53081536, 53213504, 53344576, +53475776, 53608384, 53738816, 53870528, 54000832, 54131776, 54263744, +54394688, 54525248, 54655936, 54787904, 54918592, 55049152, 55181248, +55312064, 55442752, 55574336, 55705024, 55836224, 55967168, 56097856, +56228672, 56358592, 56490176, 56621888, 56753728, 56884928, 57015488, +57146816, 57278272, 57409216, 57540416, 57671104, 57802432, 57933632, +58064576, 58195264, 58326976, 58457408, 58588864, 58720192, 58849984, +58981696, 59113024, 59243456, 59375552, 59506624, 59637568, 59768512, +59897792, 60030016, 60161984, 60293056, 60423872, 60554432, 60683968, +60817216, 60948032, 61079488, 61209664, 61341376, 61471936, 61602752, +61733696, 61865792, 61996736, 62127808, 62259136, 62389568, 62520512, +62651584, 62781632, 62910784, 63045056, 63176128, 63307072, 63438656, +63569216, 63700928, 63831616, 63960896, 64093888, 64225088, 64355392, +64486976, 64617664, 64748608, 64879424, 65009216, 65142464, 65273792, +65402816, 65535424, 65666752, 65797696, 65927744, 66060224, 66191296, +66321344, 66453056, 66584384, 66715328, 66846656, 66977728, 67108672, +67239104, 67370432, 67501888, 67631296, 67763776, 67895104, 68026304, +68157248, 68287936, 68419264, 68548288, 68681408, 68811968, 68942912, +69074624, 69205568, 69337024, 69467584, 69599168, 69729472, 69861184, +69989824, 70122944, 70253888, 70385344, 70515904, 70647232, 70778816, +70907968, 71040832, 71171648, 71303104, 71432512, 71564992, 71695168, +71826368, 71958464, 72089536, 72219712, 72350144, 72482624, 72613568, +72744512, 72875584, 73006144, 73138112, 73268672, 73400128, 73530944, +73662272, 73793344, 73924544, 74055104, 74185792, 74316992, 74448832, +74579392, 74710976, 74841664, 74972864, 75102784, 75233344, 75364544, +75497024, 75627584, 75759296, 75890624, 76021696, 76152256, 76283072, +76414144, 76545856, 76676672, 76806976, 76937792, 77070016, 77200832, +77331392, 77462464, 77593664, 77725376, 77856448, 77987776, 78118336, +78249664, 78380992, 78511424, 78642496, 78773056, 78905152, 79033664, +79166656, 79297472, 79429568, 79560512, 79690816, 79822784, 79953472, +80084672, 80214208, 80346944, 80477632, 80608576, 80740288, 80870848, +81002048, 81133504, 81264448, 81395648, 81525952, 81657536, 81786304, +81919808, 82050112, 82181312, 82311616, 82443968, 82573376, 82705984, +82835776, 82967744, 83096768, 83230528, 83359552, 83491264, 83622464, +83753536, 83886016, 84015296, 84147776, 84277184, 84409792, 84540608, +84672064, 84803008, 84934336, 85065152, 85193792, 85326784, 85458496, +85589312, 85721024, 85851968, 85982656, 86112448, 86244416, 86370112, +86506688, 86637632, 86769344, 86900672, 87031744, 87162304, 87293632, +87424576, 87555392, 87687104, 87816896, 87947968, 88079168, 88211264, +88341824, 88473152, 88603712, 88735424, 88862912, 88996672, 89128384, +89259712, 89390272, 89521984, 89652544, 89783872, 89914816, 90045376, +90177088, 90307904, 90438848, 90569152, 90700096, 90832832, 90963776, +91093696, 91223744, 91356992, 91486784, 91618496, 91749824, 91880384, +92012224, 92143552, 92273344, 92405696, 92536768, 92666432, 92798912, +92926016, 93060544, 93192128, 93322816, 93453632, 93583936, 93715136, +93845056, 93977792, 94109504, 94240448, 94371776, 94501184, 94632896, +94764224, 94895552, 95023424, 95158208, 95287744, 95420224, 95550016, +95681216, 95811904, 95943872, 96075328, 96203584, 96337856, 96468544, +96599744, 96731072, 96860992, 96992576, 97124288, 97254848, 97385536, +97517248, 97647808, 97779392, 97910464, 98041408, 98172608, 98303168, +98434496, 98565568, 98696768, 98827328, 98958784, 99089728, 99220928, +99352384, 99482816, 99614272, 99745472, 99876416, 100007104, +100138048, 100267072, 100401088, 100529984, 100662592, 100791872, +100925248, 101056064, 101187392, 101317952, 101449408, 101580608, +101711296, 101841728, 101973824, 102104896, 102235712, 102366016, +102498112, 102628672, 102760384, 102890432, 103021888, 103153472, +103284032, 103415744, 103545152, 103677248, 103808576, 103939648, +104070976, 104201792, 104332736, 104462528, 104594752, 104725952, +104854592, 104988608, 105118912, 105247808, 105381184, 105511232, +105643072, 105774784, 105903296, 106037056, 106167872, 106298944, +106429504, 106561472, 106691392, 106822592, 106954304, 107085376, +107216576, 107346368, 107478464, 107609792, 107739712, 107872192, +108003136, 108131392, 108265408, 108396224, 108527168, 108657344, +108789568, 108920384, 109049792, 109182272, 109312576, 109444928, +109572928, 109706944, 109837888, 109969088, 110099648, 110230976, +110362432, 110492992, 110624704, 110755264, 110886208, 111017408, +111148864, 111279296, 111410752, 111541952, 111673024, 111803456, +111933632, 112066496, 112196416, 112328512, 112457792, 112590784, +112715968, 112852672, 112983616, 113114944, 113244224, 113376448, +113505472, 113639104, 113770304, 113901376, 114031552, 114163264, +114294592, 114425536, 114556864, 114687424, 114818624, 114948544, +115080512, 115212224, 115343296, 115473472, 115605184, 115736128, +115867072, 115997248, 116128576, 116260288, 116391488, 116522944, +116652992, 116784704, 116915648, 117046208, 117178304, 117308608, +117440192, 117569728, 117701824, 117833024, 117964096, 118094656, +118225984, 118357312, 118489024, 118617536, 118749632, 118882112, +119012416, 119144384, 119275328, 119406016, 119537344, 119668672, +119798464, 119928896, 120061376, 120192832, 120321728, 120454336, +120584512, 120716608, 120848192, 120979136, 121109056, 121241408, +121372352, 121502912, 121634752, 121764416, 121895744, 122027072, +122157632, 122289088, 122421184, 122550592, 122682944, 122813888, +122945344, 123075776, 123207488, 123338048, 123468736, 123600704, +123731264, 123861952, 123993664, 124124608, 124256192, 124386368, +124518208, 124649024, 124778048, 124911296, 125041088, 125173696, +125303744, 125432896, 125566912, 125696576, 125829056, 125958592, +126090304, 126221248, 126352832, 126483776, 126615232, 126746432, +126876608, 127008704, 127139392, 127270336, 127401152, 127532224, +127663552, 127794752, 127925696, 128055232, 128188096, 128319424, +128449856, 128581312, 128712256, 128843584, 128973632, 129103808, +129236288, 129365696, 129498944, 129629888, 129760832, 129892288, +130023104, 130154048, 130283968, 130416448, 130547008, 130678336, +130807616, 130939456, 131071552, 131202112, 131331776, 131464384, +131594048, 131727296, 131858368, 131987392, 132120256, 132250816, +132382528, 132513728, 132644672, 132774976, 132905792, 133038016, +133168832, 133299392, 133429312, 133562048, 133692992, 133823296, +133954624, 134086336, 134217152, 134348608, 134479808, 134607296, +134741056, 134872384, 135002944, 135134144, 135265472, 135396544, +135527872, 135659072, 135787712, 135921472, 136052416, 136182848, +136313792, 136444864, 136576448, 136707904, 136837952, 136970048, +137099584, 137232064, 137363392, 137494208, 137625536, 137755712, +137887424, 138018368, 138149824, 138280256, 138411584, 138539584, +138672832, 138804928, 138936128, 139066688, 139196864, 139328704, +139460032, 139590208, 139721024, 139852864, 139984576, 140115776, +140245696, 140376512, 140508352, 140640064, 140769856, 140902336, +141032768, 141162688, 141294016, 141426496, 141556544, 141687488, +141819584, 141949888, 142080448, 142212544, 142342336, 142474432, +142606144, 142736192, 142868288, 142997824, 143129408, 143258944, +143392448, 143523136, 143653696, 143785024, 143916992, 144045632, +144177856, 144309184, 144440768, 144570688, 144701888, 144832448, +144965056, 145096384, 145227584, 145358656, 145489856, 145620928, +145751488, 145883072, 146011456, 146144704, 146275264, 146407232, +146538176, 146668736, 146800448, 146931392, 147062336, 147193664, +147324224, 147455936, 147586624, 147717056, 147848768, 147979456, +148110784, 148242368, 148373312, 148503232, 148635584, 148766144, +148897088, 149028416, 149159488, 149290688, 149420224, 149551552, +149683136, 149814976, 149943616, 150076352, 150208064, 150338624, +150470464, 150600256, 150732224, 150862784, 150993088, 151125952, +151254976, 151388096, 151519168, 151649728, 151778752, 151911104, +152042944, 152174144, 152304704, 152435648, 152567488, 152698816, +152828992, 152960576, 153091648, 153222976, 153353792, 153484096, +153616192, 153747008, 153878336, 154008256, 154139968, 154270912, +154402624, 154533824, 154663616, 154795712, 154926272, 155057984, +155188928, 155319872, 155450816, 155580608, 155712064, 155843392, +155971136, 156106688, 156237376, 156367424, 156499264, 156630976, +156761536, 156892352, 157024064, 157155008, 157284416, 157415872, +157545536, 157677248, 157810496, 157938112, 158071744, 158203328, +158334656, 158464832, 158596288, 158727616, 158858048, 158988992, +159121216, 159252416, 159381568, 159513152, 159645632, 159776192, +159906496, 160038464, 160169536, 160300352, 160430656, 160563008, +160693952, 160822208, 160956352, 161086784, 161217344, 161349184, +161480512, 161611456, 161742272, 161873216, 162002752, 162135872, +162266432, 162397888, 162529216, 162660032, 162790976, 162922048, +163052096, 163184576, 163314752, 163446592, 163577408, 163707968, +163839296, 163969984, 164100928, 164233024, 164364224, 164494912, +164625856, 164756672, 164887616, 165019072, 165150016, 165280064, +165412672, 165543104, 165674944, 165805888, 165936832, 166067648, +166198336, 166330048, 166461248, 166591552, 166722496, 166854208, +166985408, 167116736, 167246656, 167378368, 167508416, 167641024, +167771584, 167903168, 168034112, 168164032, 168295744, 168427456, +168557632, 168688448, 168819136, 168951616, 169082176, 169213504, +169344832, 169475648, 169605952, 169738048, 169866304, 16999552, +170131264, 170262464, 170393536, 170524352, 170655424, 170782016, +170917696, 171048896, 171179072, 171310784, 171439936, 171573184, +171702976, 171835072, 171966272, 172097216, 172228288, 172359232, +172489664, 172621376, 172747712, 172883264, 173014208, 173144512, +173275072, 173407424, 173539136, 173669696, 173800768, 173931712, +174063424, 174193472, 174325696, 174455744, 174586816, 174718912, +174849728, 174977728, 175109696, 175242688, 175374272, 175504832, +175636288, 175765696, 175898432, 176028992, 176159936, 176291264, +176422592, 176552512, 176684864, 176815424, 176946496, 177076544, +177209152, 177340096, 177470528, 177600704, 177731648, 177864256, +177994816, 178126528, 178257472, 178387648, 178518464, 178650176, +178781888, 178912064, 179044288, 179174848, 179305024, 179436736, +179568448, 179698496, 179830208, 179960512, 180092608, 180223808, +180354752, 180485696, 180617152, 180748096, 180877504, 181009984, +181139264, 181272512, 181402688, 181532608, 181663168, 181795136, +181926592, 182057536, 182190016, 182320192, 182451904, 182582336, +182713792, 182843072, 182976064, 183107264, 183237056, 183368384, +183494848, 183631424, 183762752, 183893824, 184024768, 184154816, +184286656, 184417984, 184548928, 184680128, 184810816, 184941248, +185072704, 185203904, 185335616, 185465408, 185596352, 185727296, +185859904, 185989696, 186121664, 186252992, 186383552, 186514112, +186645952, 186777152, 186907328, 187037504, 187170112, 187301824, +187429184, 187562048, 187693504, 187825472, 187957184, 188087104, +188218304, 188349376, 188481344, 188609728, 188743616, 188874304, +189005248, 189136448, 189265088, 189396544, 189528128, 189660992, +189791936, 189923264, 190054208, 190182848, 190315072, 190447424, +190577984, 190709312, 190840768, 190971328, 191102656, 191233472, +191364032, 191495872, 191626816, 191758016, 191888192, 192020288, +192148928, 192282176, 192413504, 192542528, 192674752, 192805952, +192937792, 193068608, 193198912, 193330496, 193462208, 193592384, +193723456, 193854272, 193985984, 194116672, 194247232, 194379712, +194508352, 194641856, 194772544, 194900672, 195035072, 195166016, +195296704, 195428032, 195558592, 195690304, 195818176, 195952576, +196083392, 196214336, 196345792, 196476736, 196607552, 196739008, +196869952, 197000768, 197130688, 197262784, 197394368, 197523904, +197656384, 197787584, 197916608, 198049472, 198180544, 198310208, +198442432, 198573632, 198705088, 198834368, 198967232, 199097792, +199228352, 199360192, 199491392, 199621696, 199751744, 199883968, +200014016, 200146624, 200276672, 200408128, 200540096, 200671168, +200801984, 200933312, 201062464, 201194944, 201326144, 201457472, +201588544, 201719744, 201850816, 201981632, 202111552, 202244032, +202374464, 202505152, 202636352, 202767808, 202898368, 203030336, +203159872, 203292608, 203423296, 203553472, 203685824, 203816896, +203947712, 204078272, 204208192, 204341056, 204472256, 204603328, +204733888, 204864448, 204996544, 205125568, 205258304, 205388864, +205517632, 205650112, 205782208, 205913536, 206044736, 206176192, +206307008, 206434496, 206569024, 206700224, 206831168, 206961856, +207093056, 207223616, 207355328, 207486784, 207616832, 207749056, +207879104, 208010048, 208141888, 208273216, 208404032, 208534336, +208666048, 208796864, 208927424, 209059264, 209189824, 209321792, +209451584, 209582656, 209715136, 209845568, 209976896, 210106432, +210239296, 210370112, 210501568, 210630976, 210763712, 210894272, +211024832, 211156672, 211287616, 211418176, 211549376, 211679296, +211812032, 211942592, 212074432, 212204864, 212334016, 212467648, +212597824, 212727616, 212860352, 212991424, 213120832, 213253952, +213385024, 213515584, 213645632, 213777728, 213909184, 214040128, +214170688, 214302656, 214433728, 214564544, 214695232, 214826048, +214956992, 215089088, 215219776, 215350592, 215482304, 215613248, +215743552, 215874752, 216005312, 216137024, 216267328, 216399296, +216530752, 216661696, 216790592, 216923968, 217054528, 217183168, +217316672, 217448128, 217579072, 217709504, 217838912, 217972672, +218102848, 218233024, 218364736, 218496832, 218627776, 218759104, +218888896, 219021248, 219151936, 219281728, 219413056, 219545024, +219675968, 219807296, 219938624, 220069312, 220200128, 220331456, +220461632, 220592704, 220725184, 220855744, 220987072, 221117888, +221249216, 221378368, 221510336, 221642048, 221772736, 221904832, +222031808, 222166976, 222297536, 222428992, 222559936, 222690368, +222820672, 222953152, 223083968, 223213376, 223345984, 223476928, +223608512, 223738688, 223869376, 224001472, 224132672, 224262848, +224394944, 224524864, 224657344, 224788288, 224919488, 225050432, +225181504, 225312704, 225443776, 225574592, 225704768, 225834176, +225966784, 226097216, 226229824, 226360384, 226491712, 226623424, +226754368, 226885312, 227015104, 227147456, 227278528, 227409472, +227539904, 227669696, 227802944, 227932352, 228065216, 228196288, +228326464, 228457792, 228588736, 228720064, 228850112, 228981056, +229113152, 229243328, 229375936, 229505344, 229636928, 229769152, +229894976, 230030272, 230162368, 230292416, 230424512, 230553152, +230684864, 230816704, 230948416, 231079616, 231210944, 231342016, +231472448, 231603776, 231733952, 231866176, 231996736, 232127296, +232259392, 232388672, 232521664, 232652608, 232782272, 232914496, +233043904, 233175616, 233306816, 233438528, 233569984, 233699776, +233830592, 233962688, 234092224, 234221888, 234353984, 234485312, +234618304, 234749888, 234880832, 235011776, 235142464, 235274048, +235403456, 235535936, 235667392, 235797568, 235928768, 236057152, +236190272, 236322752, 236453312, 236583616, 236715712, 236846528, +236976448, 237108544, 237239104, 237371072, 237501632, 237630784, +237764416, 237895232, 238026688, 238157632, 238286912, 238419392, +238548032, 238681024, 238812608, 238941632, 239075008, 239206336, +239335232, 239466944, 239599168, 239730496, 239861312, 239992384, +240122816, 240254656, 240385856, 240516928, 240647872, 240779072, +240909632, 241040704, 241171904, 241302848, 241433408, 241565248, +241696192, 241825984, 241958848, 242088256, 242220224, 242352064, +242481856, 242611648, 242744896, 242876224, 243005632, 243138496, +243268672, 243400384, 243531712, 243662656, 243793856, 243924544, +244054592, 244187072, 244316608, 244448704, 244580032, 244710976, +244841536, 244972864, 245104448, 245233984, 245365312, 245497792, +245628736, 245759936, 245889856, 246021056, 246152512, 246284224, +246415168, 246545344, 246675904, 246808384, 246939584, 247070144, +247199552, 247331648, 247463872, 247593536, 247726016, 247857088, +247987648, 248116928, 248249536, 248380736, 248512064, 248643008, +248773312, 248901056, 249036608, 249167552, 249298624, 249429184, +249560512, 249692096, 249822784, 249954112, 250085312, 250215488, +250345792, 250478528, 250608704, 250739264, 250870976, 251002816, +251133632, 251263552, 251395136, 251523904, 251657792, 251789248, +251919424, 252051392, 252182464, 252313408, 252444224, 252575552, +252706624, 252836032, 252968512, 253099712, 253227584, 253361728, +253493056, 253623488, 253754432, 253885504, 254017216, 254148032, +254279488, 254410432, 254541376, 254672576, 254803264, 254933824, +255065792, 255196736, 255326528, 255458752, 255589952, 255721408, +255851072, 255983296, 256114624, 256244416, 256374208, 256507712, +256636096, 256768832, 256900544, 257031616, 257162176, 257294272, +257424448, 257555776, 257686976, 257818432, 257949632, 258079552, +258211136, 258342464, 258473408, 258603712, 258734656, 258867008, +258996544, 259127744, 259260224, 259391296, 259522112, 259651904, +259784384, 259915328, 260045888, 260175424, 260308544, 260438336, +260570944, 260700992, 260832448, 260963776, 261092672, 261226304, +261356864, 261487936, 261619648, 261750592, 261879872, 262011968, +262143424, 262274752, 262404416, 262537024, 262667968, 262799296, +262928704, 263061184, 263191744, 263322944, 263454656, 263585216, +263716672, 263847872, 263978944, 264108608, 264241088, 264371648, +264501184, 264632768, 264764096, 264895936, 265024576, 265158464, +265287488, 265418432, 265550528, 265681216, 265813312, 265943488, +266075968, 266206144, 266337728, 266468032, 266600384, 266731072, +266862272, 266993344, 267124288, 267255616, 267386432, 267516992, +267648704, 267777728, 267910592, 268040512, 268172096, 268302784, +268435264, 268566208, 268696256, 268828096, 268959296, 269090368, +269221312, 269352256, 269482688, 269614784, 269745856, 269876416, +270007616, 270139328, 270270272, 270401216, 270531904, 270663616, +270791744, 270924736, 271056832, 271186112, 271317184, 271449536, +271580992, 271711936, 271843136, 271973056, 272105408, 272236352, +272367296, 272498368, 272629568, 272759488, 272891456, 273022784, +273153856, 273284672, 273415616, 273547072, 273677632, 273808448, +273937088, 274071488, 274200896, 274332992, 274463296, 274595392, +274726208, 274857536, 274988992, 275118656, 275250496, 275382208, +275513024, 275643968, 275775296, 275906368, 276037184, 276167872, +276297664, 276429376, 276560576, 276692672, 276822976, 276955072, +277085632, 277216832, 277347008, 277478848, 277609664, 277740992, +277868608, 278002624, 278134336, 278265536, 278395328, 278526784, +278657728, 278789824, 278921152, 279052096, 279182912, 279313088, +279443776, 279576256, 279706048, 279838528, 279969728, 280099648, +280230976, 280361408, 280493632, 280622528, 280755392, 280887104, +281018176, 281147968, 281278912, 281411392, 281542592, 281673152, +281803712, 281935552, 282066496, 282197312, 282329024, 282458816, +282590272, 282720832, 282853184, 282983744, 283115072, 283246144, +283377344, 283508416, 283639744, 283770304, 283901504, 284032576, +284163136, 284294848, 284426176, 284556992, 284687296, 284819264, +284950208, 285081536] +``` diff --git a/public/content/translations/ru/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md b/public/content/translations/ru/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md new file mode 100644 index 00000000000..23a34de6a03 --- /dev/null +++ b/public/content/translations/ru/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md @@ -0,0 +1,42 @@ +--- +title: "Алгоритмы майнинга" +description: "Детальный обзор алгоритмов майнинга Ethereum." +lang: ru +--- + + + + + +Доказательство работы(PoW) больше не является механизмом консенсуса Ethereum, это означает что майнинг отключен. Вместо этого, Ethereum обеспечен и защищен валидаторами, которые поставляют ETH. Вы можете начать ставить свои ETH уже сегодня. Узнайте больше о Слиянии, доказательстве владения и вкладах. Эта страница здесь ради исторического интереса. + + + + +Для майнинга Ethereum использовался алгоритм, известный как Ethash. Основная идея алгоритма заключается в том, что майнер пытается найти ввод nonce с помощью грубой силы, чтобы полученный хэш был меньше порога, определяемого вычисленной сложностью. Этот уровень сложности можно динамически регулировать, что позволяет производить блоки через регулярные промежутки времени. + +## Предварительные условия {#prerequisites} + +Чтобы лучше понять эту страницу, мы рекомендуем вам сначала ознакомиться с [консенсусом на основе доказательства работы](/developers/docs/consensus-mechanisms/pow) и [майнингом](/developers/docs/consensus-mechanisms/pow/mining). + +## Dagger Hashimoto {#dagger-hashimoto} + +Dagger Hashimoto был предшественником исследовательского алгоритма добычи Ethereum, который заменил Ethash. Это было объединение двух разных алгоритмов: Dagger и Hashimoto. Это была всего лишь исследовательская реализация, и к моменту запуска основной сети Ethereum его заменил Ethash. + +[Dagger](http://www.hashcash.org/papers/dagger.html) предполагает создание [направленного ациклического графа](https://en.wikipedia.org/wiki/Directed_acyclic_graph), случайные фрагменты которого затем хешируются вместе. Основной принцип заключается в том, что для каждого nonce требуется лишь небольшая часть большого общего дерева данных. Перерасчет поддерева для каждого одноразового номера в майнинге невозможен — следовательно, необходимо хранить дерево — но это нормально для проверки ценности одного одноразового номера. Dagger был разработан как альтернатива существующим алгоритмам, таким как Scrypt, которые требовательны к памяти, но их трудно проверить, когда их жесткость памяти увеличивается до действительно безопасного уровня. Однако Dagger был уязвим для аппаратного ускорения общей памяти, и поэтому ему пришлось отказаться от других направлений исследований. + +[Hashimoto](http://diyhpl.us/%7Ebryan/papers2/bitcoin/meh/hashimoto.pdf) — это алгоритм, обеспечивающий устойчивость к ASIC за счет привязки к операциям ввода-вывода (т. е. чтение из памяти является ограничивающим фактором в процессе майнинга). Теория состоит в том, что оперативная память более доступна, чем вычисления; исследования стоимостью в миллиарды долларов уже направлены на оптимизацию оперативной памяти для различных вариантов использования, которые часто включают шаблоны почти произвольного доступа (отсюда и «оперативная память»). В результате существующая оперативная память, вероятно, будет умеренно близка к оптимальной для оценки алгоритма. Hashimoto использует блокчейн в качестве источника данных, одновременно удовлетворяя (1) и (3) выше. + +Dagger-Hashimoto использовал измененные версии алгоритмов Dagger и Hashimoto. Разница между Dagger Hashimoto и Hashimoto заключается в том, что вместо использования блокчейна в качестве источника данных Dagger Hashimoto использует специально созданный набор данных, который обновляется на основе данных блока каждые N блоков. Набор данных генерируется с помощью алгоритма Dagger, что позволяет эффективно вычислять подмножество, специфичное для каждого nonce, для алгоритма верификации легкого клиента. Разница между Dagger Hashimoto и Dagger заключается в том, что, в отличие от оригинального Dagger, набор данных, используемый для запроса блока, является полупостоянным, обновляясь лишь время от времени (например, раз в неделю). Это означает, что доля усилий по созданию набора данных близка к нулю, поэтому аргументы Серджио Лернера относительно ускорения за счет общей памяти становятся незначительными. + +Подробнее о [Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto). + +## Ethash {#ethash} + +Ethash — это алгоритм майнинга, который фактически использовался в основной сети Ethereum в рамках ныне устаревшей архитектуры доказательства выполнения работы. Ethash — это, по сути, новое название, данное определенной версии Dagger-Hashimoto после того, как алгоритм был значительно обновлен, при этом он унаследовал основные принципы своего предшественника. В основной сети Ethereum всегда использовался только Ethash — Dagger Hashimoto был версией алгоритма майнинга для исследований и разработок (R&D), которая была заменена до начала майнинга в основной сети Ethereum. + +[Подробнее об Ethash](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash). + +## Дополнительные материалы {#further-reading} + +_Знаете ресурс сообщества, который вам пригодился? Измените эту страницу и добавьте его!_ diff --git a/public/content/translations/ru/developers/docs/dapps/index.md b/public/content/translations/ru/developers/docs/dapps/index.md index 1622dc9a40e..2151da8efac 100644 --- a/public/content/translations/ru/developers/docs/dapps/index.md +++ b/public/content/translations/ru/developers/docs/dapps/index.md @@ -1,96 +1,96 @@ --- -title: Введение в децентрализованные приложения +title: "Техническое введение в децентрализованные приложения" description: lang: ru --- -Децентрализованное приложение (dapp) — это приложение, построенное на децентрализованной сети, сочетающей в себе [умный контракт](/developers/docs/smart-contracts/) и клиентскую сторону пользовательского интерфейса. Отметим, что в Ethereum умные контракты общедоступны и прозрачны (как открытые API), поэтому ваше приложение может содержать в себе умные контракты, которые были написаны другими людьми. +Децентрализованное приложение (dapp) — это приложение, созданное в децентрализованной сети, которое сочетает в себе [смарт-контракт](/developers/docs/smart-contracts/) и клиентский пользовательский интерфейс. Отметим, что в Ethereum умные контракты общедоступны и прозрачны (как открытые API), поэтому ваше приложение может содержать в себе умные контракты, которые были написаны другими людьми. -## Прежде чем начать {#prerequisites} +## Предварительные условия {#prerequisites} -Перед изучением децентрализованных приложений вам следует прочитать об [основах блокчейна](/developers/docs/intro-to-ethereum/), а также о сети Ethereum и о том, как она децентрализована. +Прежде чем изучать децентрализованные приложения, вам следует ознакомиться с [основами блокчейна](/developers/docs/intro-to-ethereum/) и прочитать о сети Ethereum и о том, как она децентрализована. -## Что такое децентрализованное приложение {#definition-of-a-dapp} +## Определение децентрализованного приложения {#definition-of-a-dapp} У децентрализованного приложения есть бэкенд-код, который работает в децентрализованной одноранговой сети. Сравните это с приложением, бэкенд-код которого работает на централизованных серверах. -Децентрализованное приложение может иметь фронтенд-код и пользовательский интерфейс на любом языке (как и обычное приложение) для запросов к бэкенду. Более того, фронтенд может быть размещен в децентрализованном хранилище, таком как [IPFS](https://ipfs.io/). +Децентрализованное приложение может иметь фронтенд-код и пользовательский интерфейс на любом языке (как и обычное приложение) для запросов к бэкенду. Кроме того, его фронтенд можно разместить в децентрализованном хранилище, таком как [IPFS](https://ipfs.io/). -- **Децентрализованные**: децентрализованные приложения работают в Ethereum — на открытой публичной децентрализованной платформе, над которой ни одно лицо или группа не имеет контроля -- **Детерминированные**: децентрализованные приложения выполняют ту же функцию независимо от среды, в которой они выполняются -- **Полные по Тьюрингу**: децентрализованные приложения могут выполнять любые действия при наличии необходимых ресурсов -- **Изолированные**: децентрализованные приложения выполняются в виртуальной среде, известной как Ethereum Virtual Machine, и ошибка в умном контракте не помешает нормальному функционированию блокчейн-сети +- **Децентрализованные**: децентрализованные приложения работают на Ethereum, открытой публичной децентрализованной платформе, где ни один человек или группа не имеют контроля +- **Детерминированные**: децентрализованные приложения выполняют одну и ту же функцию независимо от среды, в которой они выполняются. +- **Полные по Тьюрингу**: децентрализованные приложения могут выполнять любое действие при наличии необходимых ресурсов. +- **Изолированные**: децентрализованные приложения выполняются в виртуальной среде, известной как виртуальная машина Ethereum, так что, если в смарт-контракте есть ошибка, это не помешает нормальной работе сети блокчейна. -### Умные контракты {#on-smart-contracts} +### О смарт-контрактах {#on-smart-contracts} -Чтобы внедрить децентрализованные приложения, нам нужно ввести умные контракты (можно сказать, что это бэкенд децентрализованного приложения). Чтобы получить подробный обзор, перейдите в наш раздел, посвященный [умным контрактам](/developers/docs/smart-contracts/). +Чтобы внедрить децентрализованные приложения, нам нужно ввести умные контракты (можно сказать, что это бэкенд децентрализованного приложения). Для получения подробного обзора перейдите в наш раздел о [смарт-контрактах](/developers/docs/smart-contracts/). Умный контракт — это код, который существует в блокчейне Ethereum и работает в точности так, как он был запрограммирован. После того, как умные контракты развернуты в сети, вы не сможете их изменить. Приложения dapp являются децентрализованными, так как они контролируются алгоритмом, записанным в контракте, а не частным лицом или компанией. Это также означает, что необходимо крайне осторожно разрабатывать контракты и тщательно их тестировать. -## Преимущества разработки dapp {#benefits-of-dapp-development} +## Преимущества разработки децентрализованных приложений {#benefits-of-dapp-development} -- **Нулевое время простоя**. После развертывания умного контракта в блокчейне сеть в целом всегда сможет обслуживать клиентов, желающих взаимодействовать с контрактом. Следовательно, злоумышленники не смогут запускать атаки типа «отказ в обслуживании», направленные на отдельные децентрализованные приложения. -- **Конфиденциальность**. Вам не нужно предоставлять свой реальные личные данные для использования или взаимодействия с dapp. -- **Устойчивость к цензуре**. Абсолютно никто в сети не может блокировать отправку транзакций пользователями, написание ими децентрализованных приложений или чтение данных из блокчейна. -- **Обеспечение неприкосновенности данных**. Данные, хранящиеся в блокчейне, неизменны и неоспоримы благодаря криптографическим примитивам. Злоумышленники не могут подделывать транзакции или другие данные, которые уже были опубликованы. -- **Вычисления, не требующие доверия, и проверяемое поведение**. Умные контракты можно анализировать, и они гарантированно будут выполняться предсказуемым образом без необходимости доверять центральному органу. В традиционных моделях все обстоит иначе: например, при использовании системы онлайн-банкинга мы за неимением выбора должны доверять тому, что финансовые учреждения не будут злоупотреблять нашими финансовыми данными, изменять записи или взламывать наши аккаунты. +- **Отсутствие простоев** — как только смарт-контракт развернут в блокчейне, сеть в целом всегда сможет обслуживать клиентов, желающих взаимодействовать с контрактом. Следовательно, злоумышленники не смогут запускать атаки типа «отказ в обслуживании», направленные на отдельные децентрализованные приложения. +- **Конфиденциальность** — вам не нужно предоставлять реальные личные данные для развертывания децентрализованного приложения или взаимодействия с ним. +- **Устойчивость к цензуре** — ни одна сущность в сети не может заблокировать пользователей от отправки транзакций, развертывания децентрализованных приложений или чтения данных из блокчейна. +- **Полная целостность данных** — данные, хранящиеся в блокчейне, неизменны и неоспоримы благодаря криптографическим примитивам. Злоумышленники не могут подделывать транзакции или другие данные, которые уже были опубликованы. +- **Вычисления без доверия/проверяемое поведение** — смарт-контракты можно анализировать, и они гарантированно будут выполняться предсказуемым образом без необходимости доверять центральному органу. В традиционных моделях все обстоит иначе: например, при использовании системы онлайн-банкинга мы за неимением выбора должны доверять тому, что финансовые учреждения не будут злоупотреблять нашими финансовыми данными, изменять записи или взламывать наши аккаунты. -## Недостатки разработки dapp {#drawbacks-of-dapp-development} +## Недостатки разработки децентрализованных приложений {#drawbacks-of-dapp-development} -- **Обслуживание**. Могут возникать трудности с поддержкой и обслуживанием децентрализованных приложений, так как код и данные, опубликованные в блокчейне, сложнее изменить. Разработчикам сложно обновлять свои децентрализованные приложения (или базовые данные, хранящиеся в децентрализованном приложении) после их развертывания, даже если в старой версии обнаружены ошибки или угрозы безопасности. -- **Расходы на производительность**. Накладные расходы на производительность огромны, и масштабирование действительно затруднено. Чтобы достичь уровня безопасности, честности, прозрачности и надежности, к которому стремится Ethereum, каждый узел запускает и хранит каждую транзакцию. Кроме того, консенсус с доказательством владения также требует времени. -- **Перегрузка сети**. Когда одно децентрализованное приложение использует слишком много вычислительных ресурсов, создается резервная копия всей сети. На текущий момент сеть может обрабатывать только около 10-15 транзакций в секунду; если транзакции отправляются быстрее, чем может обработать сеть, пул неподтвержденных транзакций может быстро увеличиться. -- **Удобство пользователя**. Может быть сложнее добиться удобства пользователя, потому что среднестатическому пользователю может быть слишком сложно настроить стек инструментов, необходимый для действительно безопасного взаимодействия с блокчейном. -- **Централизация**. Удобные для пользователя и разработчика решения, построенные на основе базового уровня Ethereum, в любом случае могут оказаться похожими на централизованные службы. Например, такие службы могут хранить ключи или другую важную информацию на стороне сервера, обслуживать интерфейс с использованием централизованного сервера или запускать важную бизнес-логику на централизованном сервере перед записью в блокчейн. Централизация сводит на нет многие (если не все) преимущества блокчейна в сравнении с традиционной моделью. +- **Обслуживание** — децентрализованные приложения может быть сложнее обслуживать, потому что код и данные, опубликованные в блокчейне, сложнее изменить. Разработчикам сложно обновлять свои децентрализованные приложения (или базовые данные, хранящиеся в децентрализованном приложении) после их развертывания, даже если в старой версии обнаружены ошибки или угрозы безопасности. +- **Накладные расходы на производительность** — существуют огромные накладные расходы на производительность, а масштабирование очень затруднено. Чтобы достичь уровня безопасности, честности, прозрачности и надежности, к которому стремится Ethereum, каждый узел запускает и хранит каждую транзакцию. Кроме того, консенсус с доказательством владения также требует времени. +- **Перегрузка сети** — когда одно децентрализованное приложение использует слишком много вычислительных ресурсов, вся сеть перегружается. На текущий момент сеть может обрабатывать только около 10-15 транзакций в секунду; если транзакции отправляются быстрее, чем может обработать сеть, пул неподтвержденных транзакций может быстро увеличиться. +- **Пользовательский опыт** — может быть сложнее создать удобный для пользователя интерфейс, поскольку среднестатистическому конечному пользователю может показаться слишком сложным настроить набор инструментов, необходимый для взаимодействия с блокчейном действительно безопасным способом. +- **Централизация** — удобные для пользователя и разработчика решения, построенные поверх базового уровня Ethereum, в конечном итоге все равно могут выглядеть как централизованные сервисы. Например, такие службы могут хранить ключи или другую важную информацию на стороне сервера, обслуживать интерфейс с использованием централизованного сервера или запускать важную бизнес-логику на централизованном сервере перед записью в блокчейн. Централизация сводит на нет многие (если не все) преимущества блокчейна в сравнении с традиционной моделью. -## Больше любите видео? {#visual-learner} +## Больше увлекаетесь визуализацией? {#visual-learner} ## Инструменты для создания децентрализованных приложений {#dapp-tools} -**Scaffold-ETH — _быстрый опыт использования Solidity с помощью интерфейса, который адаптируется к вашему умному контракту._** +**Scaffold-ETH _- Быстро экспериментируйте с Solidity, используя фронтенд, который адаптируется к вашему смарт-контракту._** - [GitHub](https://github.com/scaffold-eth/scaffold-eth-2) -- [Пример dapp](https://punkwallet.io/) +- [Пример децентрализованного приложения](https://punkwallet.io/) -**Создание приложения Eth — _создавайте приложения на базе Ethereum с помощью одной команды._** +**Create Eth App _- Создавайте приложения на базе Ethereum с помощью одной команды._** - [GitHub](https://github.com/paulrberg/create-eth-app) -**One Click Dapp _— FOSS-инструмент для создания интерфейсов dapp с [ABI](/glossary/#abi)._** +**One Click Dapp _- Инструмент FOSS для создания фронтендов децентрализованных приложений из [ABI](/glossary/#abi)._** - [oneclickdapp.com](https://oneclickdapp.com) - [GitHub](https://github.com/oneclickdapp/oneclickdapp-v1) -**Etherflow — _FOSS-инструмент для разработчиков Ethereum, позволяющий тестировать свои узлы, а также составлять и отлаживать RPC-вызовы из браузера._** +**Etherflow _- Инструмент FOSS для разработчиков Ethereum, позволяющий тестировать их узел, а также составлять и отлаживать RPC-вызовы из браузера._** - [etherflow.quiknode.io](https://etherflow.quiknode.io/) - [GitHub](https://github.com/abunsen/etherflow) -**thirdweb _– SDK на каждом языке, смарт-контракты, инструменты и инфраструктура для разработки Web3._** +**thirdweb _- SDK для всех языков, смарт-контракты, инструменты и инфраструктура для разработки web3._** -- [Официальный веб-сайт](https://thirdweb.com/) +- [Домашняя страница](https://thirdweb.com/) - [Документация](https://portal.thirdweb.com/) - [GitHub](https://github.com/thirdweb-dev/) -**Crossmint _— платформа разработки Web3 корпоративного уровня для развертывания смарт-контрактов, платежей по кредитным картам и кроссчейн-платежей, а также создания, распространения, продажи, хранения и редактирования NFT посредством API._** +**Crossmint _- Платформа для разработки web3 корпоративного уровня для развертывания смарт-контрактов, приема платежей по кредитным картам и кроссчейн-платежей, а также использования API для создания, распространения, продажи, хранения и редактирования NFT._** - [crossmint.com](https://www.crossmint.com) - [Документация](https://docs.crossmint.com) - [Discord](https://discord.com/invite/crossmint) -## Дополнительные ресурсы {#further-reading} +## Дополнительные материалы {#further-reading} -- [Просмотреть децентрализованные приложения](/apps) -- [Архитектура приложения Web 3.0](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) — _Прити Касиредди_ -- [Руководство 2021 года по децентрализованным приложениям](https://limechain.tech/blog/what-are-dapps-the-2021-guide/) — _LimeChain_ +- [Изучить децентрализованные приложения](/apps) +- [Архитектура Web 3.0-приложения](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) — _Preethi Kasireddy_ +- [Руководство по децентрализованным приложениям 2021 года](https://limechain.tech/blog/what-are-dapps-the-2021-guide/) — _LimeChain_ - [Что такое децентрализованные приложения?](https://www.gemini.com/cryptopedia/decentralized-applications-defi-dapps) — _Gemini_ - [Популярные децентрализованные приложения](https://www.alchemy.com/dapps) — _Alchemy_ _Знаете ресурс сообщества, который вам пригодился? Измените эту страницу и добавьте его!_ -## Похожие темы {#related-topics} +## Связанные темы {#related-topics} - [Введение в стек Ethereum](/developers/docs/ethereum-stack/) -- [Среды разработки](/developers/docs/frameworks/) +- [Фреймворки для разработки](/developers/docs/frameworks/) diff --git a/public/content/translations/ru/developers/docs/data-and-analytics/block-explorers/index.md b/public/content/translations/ru/developers/docs/data-and-analytics/block-explorers/index.md new file mode 100644 index 00000000000..9807829ac9c --- /dev/null +++ b/public/content/translations/ru/developers/docs/data-and-analytics/block-explorers/index.md @@ -0,0 +1,254 @@ +--- +title: "Обозреватели блоков" +description: "Введение в обозреватели блоков, ваш портал в мир данных блокчейна, где вы можете запрашивать информацию о транзакциях, счетах, контрактах и многое другое." +lang: ru +sidebarDepth: 3 +--- + +Обозреватели блоков это ваш портал к данным Ethereum. Вы можете использовать их для просмотра данных о блоках, транзакциях, валидаторах, аккаунтах и другой ончейн-активности в режиме реального времени. + +## Предварительные условия {#prerequisites} + +Вы должны понимать основные понятия Ethereum, чтобы вы могли понять данные, которые вам дают обозреватели блоков. Начните со [введения в Ethereum](/developers/docs/intro-to-ethereum/). + +## Сервисы {#services} + +- [Etherscan](https://etherscan.io/) – _также доступен на китайском, корейском, русском и японском языках_ +- [3xpl](https://3xpl.com/ethereum) +- [Beaconcha.in](https://beaconcha.in/) +- [Blockchair](https://blockchair.com/ethereum) – _также доступен на испанском, французском, итальянском, голландском, португальском, русском, китайском и фарси_ +- [Blockscout](https://eth.blockscout.com/) +- [Chainlens](https://www.chainlens.com/) +- [Обозреватель блоков DexGuru](https://ethereum.dex.guru/) +- [Etherchain](https://www.etherchain.org/) +- [Ethplorer](https://ethplorer.io/) – _также доступен на китайском, испанском, французском, турецком, русском, корейском и вьетнамском языках_ +- [EthVM](https://www.ethvm.com/) +- [OKLink](https://www.oklink.com/eth) +- [Ethseer](https://ethseer.io) + +## Инструменты с открытым исходным кодом {#open-source-tools} + +- [Otterscan](https://otterscan.io/) +- [lazy-etherscan](https://github.com/woxjro/lazy-etherscan) + +## Данные {#data} + +Ethereum прозрачен по своей конструкции, поэтому все поддается проверке. Обозреватели блоков предоставляют интерфейс для получения этой информации. И это касается как основной сети Ethereum, так и тестовых сетей, если вам нужны эти данные. Данные делятся на данные о выполнении и данные о консенсусе. Данные о выполнении относятся к транзакциям, которые были выполнены в конкретном блоке. Данные о консенсусе относятся к самим блокам и предложившим их валидаторам. + +Вот сводка типов данных, которые вы можете получить из обозревателя блоков. + +### Данные уровня исполнения {#execution-data} + +Новые блоки добавляются в сети Ethereum каждые 12 секунд (за исключением случаев, когда инициаторы блока пропускают свою очередь), так что поток данных, получаемых обозревателями блоков, практически непрерывен. Блоки содержат много важных данных, которые могут оказаться полезными: + +**Стандартные данные** + +- Высота блока - номер блока и длина блокчейна (в блоках) на момент создания текущего блока +- Временная метка - время, когда был предложен блок +- Транзакции - количество транзакций, включенных в блок +- Получатель комиссии - адрес, на который поступила плата за газ в результате транзакций +- Вознаграждение за блок - количество ETH, начисленное валидатору, предложившему блок +- Размер - размер данных в блоке (измеряется в байтах) +- Количество использованного газ - общее количество единиц газа, использованного всем и транзакциями в блоке +- Лимит газа - максимальный суммарный лимит газа, установленный для всех транзакций в блоке +- Базовая комиссия за газ - минимальная комиссия за газ, необходимая для включения транзакции в блок +- Сгоревшая комиссия - сколько ETH сгорело в блоке +- Дополнительные данные - любые дополнительные данные, которые создатель включил в блок + +**Дополнительные данные** + +- Хеш - криптографический хеш заголовка блока (уникального идентификатора блока) +- Хеш родительского блока - хеш блока, предшествующего текущему блоку +- StateRoot - корневой хеш дерева Меркла, в котором хранится все состояние системы + +### Газ {#gas} + +Обозреватели блоков не только предоставят вам данные об использовании газа в транзакциях и блоках, но и некоторые из них предоставят вам информацию о текущих ценах на газ в сети. Это поможет вам понять расходы сети в данный момент, отправить безопасные транзакции и не перерасходовать газ. Ознакомьтесь с API, которые могут помочь вам получить эту информацию в интерфейсе вашего продукта. Данные о газе: + +- Расчетные единицы газа, необходимые для безопасной, но медленной транзакции (+ расчетная цена и продолжительность) +- Расчетные единицы потребляемого газа для средней сделки (+ расчетная цена и продолжительность) +- Расчетные единицы газа, необходимые для быстрой сделки (+ расчетная цена и продолжительность) +- Среднее время подтверждения, основанное на цене газа +- Контракты, потребляющие газ, другими словами, популярные продукты на сети, которыми активно пользуются +- Аккаунты, тратящие газ, или, иначе говоря, наиболее активные пользователи сети + +### Транзакции {#transactions} + +Обозреватели блоков стали общим местом для отслеживания прогресса их транзакций. Это потому, что уровень детализации позволяет получить дополнительную уверенность. Данные транзакции включают: + +**Стандартные данные** + +- Хеш транзакции - хеш, сгенерированный при отправке транзакции +- Статус - индикатор состояния транзакции, указывающий ожидает ли она обработки, прошла успешно или нет +- Блок - номер блока, в который была включена транзакция +- Временная отметка – время, когда транзакция была включена в блок, предложенный валидатором. +- От кого - адрес кошелька, отправившего транзакцию +- Кому - адрес получателя или смарт-контракта, с которым происходит взаимодействие +- Отправленные токены - список токенов, которые были отправлены в рамках транзакции +- Стоимость - суммарное количество ETH, которое было отправлено +- Комиссия за транзакцию — это сумма уплачиваемая валидатору за обработку транзакции (рассчитывается как цена газа\*количество использованного газа) + +**Дополнительные данные** + +- Лимит газа - максимальное количество газа, которое может быть потреблено транзакцией +- Количество использованного газа - реальное количество газа, использованного транзакцией +- Цена газа - цена за единицу газа +- Нонс – номер транзакции для адреса `from` (помните, что нумерация начинается с 0, поэтому нонс `100` на самом деле будет 101-й транзакцией, отправленной этим аккаунтом). +- Входные данные - любая дополнительная информация, требуемая транзакцией + +### Аккаунты {#accounts} + +Существует множество данных об аккаунте, к которым вы можете получить доступ. Поэтому часто рекомендуется использовать несколько аккаунтов, чтобы было сложнее отслеживать ваши активы и их стоимость. Существуют также решения, позволяющие сделать транзакции и данные об активностях аккаунта более конфиденциальными. Но вот данные, которые доступны для аккаунтов: + +**Аккаунты пользователей** + +- Адрес аккаунта - публичный адрес, на который можно отправлять средства +- Баланс ETH - количество ETH, привязанное к данному аккаунту +- Общая стоимость ETH - стоимость ETH +- Токены - токены привязанные к аккаунту и их стоимость +- История транзакций - список всех транзакций, в которых данный аккаунт выступал в качестве отправителя или получателя + +**Умные контракты** + +Аккаунты смарт-контрактов содержат все те же данные, что и пользовательские аккаунты, но некоторые обозреватели блоков могут даже показать немного информации о коде контракта. В качестве примеров можно привести: + +- Создатель контракта - адрес, с которого контракт был отправлен в сеть +- Транзакция создания контракта - транзакция, при помощи которой контракт был опубликован в сети +- Исходный код - solidity или vyper код смарт-контракта +- ABI контракта или Application Binary Interface контракта - обращения контракта к сети и получаемые данные +- Код создания контракта - скомпилированный байткод смарт-контракта, созданный при компиляции смарт-контракта, написанного на Solidity, Vyper и т. д. +- Действия контракта - история функций, вызванных в смарт-контракте, или по сути, способ увидеть, как и как часто используется контракт. + +### Токены {#tokens} + +Токены являются разновидностью контрактов, поэтому они будут иметь данные, схожие с данными смарт-контрактов. Но поскольку они имеют ценность и могут торговаться, они располагают дополнительными данными, а именно: + +- Тип - будь то ERC-20, ERC-721 или какой-то другой стандарт токенов +- Цена - в случае ERC-20 токенов, будет указана текущая рыночная стоимость +- Рыночная капитализация - в случае ERC-20 токенов, будет указана текущая рыночная капитализация (рассчитанная как цена \* общее предложение) +- Общее предложение - количество токенов, находящихся в обращении +- Владельцы - количество адресов, на которых находится токен +- Переводы - количество раз, когда токен был переведен между аккаунтами +- История транзакций - история всех транзакций, включавших токен +- Адрес контракта - адрес контракта выпуска токена на сети +- Десятичные знаки - токены ERC-20 являются делимыми и могут иметь какое-то количество знаков после запятой + +### Сеть {#network} + +Некоторые данные отражают состояние сети Ethereum в целом. + +- Общее количество транзакций - число транзакций с момента запуска Ethereum +- Количество транзакций в секунду - число транзакций, обрабатываемых в течение одной секунды +- Цена ETH - текущая стоимость 1 ETH +- Общее количество ETH - число ETH в обращении, но помните, дополнительное количество ETH появляется с каждым блоком в качестве вознаграждения +- Рыночная капитализация - рассчитывается как цена \* общее количество ETH + +## Данные уровня консенсуса {#consensus-layer-data} + +### Эпоха {#epoch} + +В целях безопасности в конце каждой эпохи (каждые 6,4 минуты) создаются рандомизированные комитеты валидаторов. Данные по эпохе включают: + +- Номер эпохи +- Статус завершенности - завершена ли эпоха (Да/Нет) +- Время - время окончания эпохи +- Аттестации - количество аттестаций в эпохе (голоса за блоки в определенной ячейке) +- Депозиты - количество депозитов ETH в эпохе (валидаторы должны застейкать ETH, чтобы быть валидаторами) +- Слэшинг – количество штрафов, наложенных на предлагающих блоки или аттестаторов. +- Участие в голосовании – количество ETH в стейкинге, используемое для аттестации блоков. +- Валидаторы - количество валидаторов, активных в каждой эпохе +- Средний баланс валидатора – средний баланс для активных валидаторов +- Ячейки - количество ячеек, включенных в эпоху (ячейки включают по одному валидированному блоку) + +### Слот {#slot} + +Ячейки - это возможности для создания блоков, данные, относящиеся к каждой ячейки, включают: + +- Эпоха - эпоха, в которой ячейка действительна +- Номер ячейки +- Статус - статус ячейки (Предложено/Пропущено) +- Время - временная метка ячейки +- Инициатор - валидатор, который предлагает блок в ячейке +- Корень блока – хэш-корень BeaconBlock. +- Родительский корень – хэш предыдущего блока. +- Корень состояния – хэш-корень BeaconState. +- Подпись +- Выявление RanDAO +- Графити - инициатор блока может добавить к нему сообщение длиной до 32 байтов +- Исполнительные данные + - Хеш блока + - Количество депозитов + - Корень депозита +- Аттестации - количество аттестаций блока в ячейке +- Депозиты - количество депозитов в этой ячейке +- Добровольные выходы - количество валидаторов, покинувших ячейку +- Слэшинг – количество штрафов, наложенных на предлагающих блоки или аттестаторов. +- Голоса - валидаторы, которые проголосовали за блок в ячейке + +### Блоки {#blocks-1} + +Доказательство владения разделяет время на ячейки и эпохи. Значит будут новые данные! + +- Претендент – валидатор, который был алгоритмически выбран для предложения нового блока +- Эпоха – эпоха, в которой был предложен блок +- Ячейка – ячейка, в которой был предложен блок +- Аттестации – количество аттестаций, включенных в слот. Аттестации подобны голосам, указывающим, что блок готов для добавления в сеть Beacon. + +### Валидаторы {#validators} + +Валидаторы отвечают за предложение блоков и их аттестацию в ячейках. + +- Номер валидатора – уникальный номер, представляющий валидатора +- Текущий баланс – баланс валидатора, включая награды +- Действующий баланс – баланс валидатора, который используется для стейкинга +- Доход – награды или штрафы, полученные валидатором +- Статус – является ли валидатор в настоящее время активным или нет +- Эффективность аттестации – среднее время, необходимое для включения аттестаций валидатора в цепочку +- Право на активацию – дата (и эпоха), когда валидатор стал доступен для проверки +- Действует с – дата (и эпоха), когда валидатор стал активным +- Предложенные блоки – предлагаемый валидатором блок +- Аттестации – аттестации, предоставленные валидатором +- Депозиты – адрес отправителя, хэш транзакции, номер блока, время и статус размещения депозита, сделанного валидатором + +### Аттестации {#attestations} + +Аттестации - это голоса «да», чтобы включить блоки в цепочку. Их данные касаются записи аттестации и валидаторов, которые подтвердили ее + +- Ячейка – ячейка, в которой проходила аттестация +- Индекс комитета – индекс комитета в данной ячейке +- Биты объединения – представляет объединенную аттестацию всех участвующих в аттестации валидаторов +- Валидаторы – валидаторы, обеспечившие аттестацию +- Корень Beacon block – указывает на блок, на который аттестуют валидаторы +- Исходник – указывает на последнюю истинную эпоху +- Цель – указывает на границу последней эпохи +- Подпись + +### Сеть {#network-1} + +Данные верхнего уровня консенсуса включают следующее: + +- Текущая эпоха +- Текущая ячейка +- Активные валидаторы - количество активных валидаторов +- Ожидающие валидаторы - количество валидаторов, ожидающих стать активными +- Застейканый ETH - количество ETH застейканного на сети +- Средний баланс - средний баланс ETH валидаторов + +## Обозреватели блоков {#block-explorers} + +- [Etherscan](https://etherscan.io/) – обозреватель блоков, который можно использовать для получения данных из основной сети Ethereum и тестовой сети. +- [3xpl](https://3xpl.com/ethereum) – обозреватель Ethereum с открытым исходным кодом без рекламы, который позволяет загружать наборы данных. +- [Beaconcha.in](https://beaconcha.in/) – обозреватель блоков с открытым исходным кодом для основной сети Ethereum и тестовой сети. +- [Blockchair](https://blockchair.com/ethereum) – самый конфиденциальный обозреватель Ethereum. Также для сортировки и фильтрации (mempool) данных +- [Etherchain](https://www.etherchain.org/) – обозреватель блоков для основной сети Ethereum. +- [Ethplorer](https://ethplorer.io/) – обозреватель блоков с фокусом на токенах для основной сети Ethereum и тестовой сети Kovan. + +## Дополнительные материалы {#further-reading} + +_Знаете ресурс сообщества, который вам пригодился? Измените эту страницу и добавьте его!_ + +## Смежные темы {#related-topics} + +- [Транзакции](/developers/docs/transactions/) +- [Аккаунты](/developers/docs/accounts/) +- [Сети](/developers/docs/networks/) diff --git a/public/content/translations/ru/developers/docs/data-and-analytics/index.md b/public/content/translations/ru/developers/docs/data-and-analytics/index.md new file mode 100644 index 00000000000..f1f876753a9 --- /dev/null +++ b/public/content/translations/ru/developers/docs/data-and-analytics/index.md @@ -0,0 +1,72 @@ +--- +title: "Данные и аналитика" +description: "Как получить ончейн-аналитику и данные для использования в ваших децентрализованных приложениях" +lang: ru +--- + +## Введение {#Introduction} + +По мере роста использования сети все больший объем ценной информации будет содержаться в ончейн-данных. Поскольку объем данных быстро увеличивается, вычисление и агрегирование этой информации для составления отчетов или управления приложением может стать трудоемкой задачей. + +Использование существующих поставщиков данных может ускорить разработку, обеспечить более точные результаты и сократить текущие расходы на обслуживание. Это позволит команде сконцентрироваться на основных функциях, которые пытается предоставить их проект. + +## Предварительные условия {#prerequisites} + +Вам следует ознакомиться с основной концепцией [обозревателей блоков](/developers/docs/data-and-analytics/block-explorers/), чтобы лучше понять их использование в контексте анализа данных. Кроме того, ознакомьтесь с понятием [индекса](/glossary/#index), чтобы понять преимущества, которые он дает при проектировании системы. + +С точки зрения основ архитектуры, необходимо хотя бы в теории понимать, что такое [API](https://www.wikipedia.org/wiki/API) и [REST](https://www.wikipedia.org/wiki/Representational_state_transfer). + +## Обозреватели блоков {#block-explorers} + +Многие [обозреватели блоков](/developers/docs/data-and-analytics/block-explorers/) предлагают шлюзы [RESTful](https://www.wikipedia.org/wiki/Representational_state_transfer) [API](https://www.wikipedia.org/wiki/API), которые предоставляют разработчикам доступ к данным о блоках, транзакциях, валидаторах, аккаунтах и другой ончейн-активности в режиме реального времени. + +Затем разработчики могут обрабатывать и преобразовывать эти данные, чтобы предоставить своим пользователям уникальные аналитические сведения и возможности взаимодействия с [блокчейном](/glossary/#blockchain). Например, [Etherscan](https://etherscan.io) и [Blockscout](https://eth.blockscout.com) предоставляют данные исполнения и консенсуса для каждого 12-секундного слота. + +## The Graph {#the-graph} + +[The Graph](https://thegraph.com/) — это протокол индексирования, который предоставляет простой способ запрашивать данные из блокчейна через открытые API, известные как подграфы. + +С The Graph разработчики получают следующие преимущества: + +- Децентрализованное индексирование: позволяет индексировать данные блокчейна с помощью нескольких индексаторов, что устраняет любую единую точку отказа +- Запросы GraphQL: предоставляет мощный интерфейс GraphQL для запроса индексированных данных, что делает их извлечение очень простым +- Настройка: определяйте собственную логику для преобразования и хранения данных блокчейна и повторно используйте подграфы, опубликованные другими разработчиками в сети The Graph + +Следуйте этому [руководству по быстрому запуску](https://thegraph.com/docs/en/quick-start/), чтобы создать, развернуть и отправить запрос к подграфу в течение 5 минут. + +## Разнообразие клиентов {#client-diversity} + +[Разнообразие клиентов](/developers/docs/nodes-and-clients/client-diversity/) важно для общего состояния сети Ethereum, поскольку оно обеспечивает устойчивость к ошибкам и эксплойтам. Сейчас существует несколько панелей мониторинга разнообразия клиентов, включая [clientdiversity.org](https://clientdiversity.org/), [rated.network](https://www.rated.network), [supermajority.info](https://supermajority.info//) и [Ethernodes](https://ethernodes.org/). + +## Dune Analytics {#dune-analytics} + +[Dune Analytics](https://dune.com/) предварительно обрабатывает данные блокчейна в таблицы реляционной базы данных (DuneSQL), позволяет пользователям запрашивать данные блокчейна с помощью SQL и создавать панели мониторинга на основе результатов запросов. Ончейн-данные организованы в 4 таблицы с необработанными данными: `blocks`, `transactions`, `logs` (журналы событий) и `traces` (трассировки вызовов). Популярные контракты и протоколы были декодированы, и каждый имеет свой собственный набор таблиц событий и вызовов. Эти таблицы событий и вызовов подвергаются дальнейшей обработке и организуются в абстрактные таблицы по типу протоколов, например, dex, кредитование, стейблкоины и т.д. + +## SQD {#sqd} + +[SQD](https://sqd.dev/) — это децентрализованная, гипермасштабируемая платформа данных, оптимизированная для обеспечения эффективного и не требующего разрешений доступа к большим объемам данных. В настоящее время она предоставляет исторические ончейн-данные, включая журналы событий, квитанции о транзакциях, трассировки и изменения состояния для каждой транзакции. SQD предлагает мощный набор инструментов для создания пользовательских конвейеров извлечения и обработки данных, достигающий скорости индексации до 150 тыс. блоков в секунду. + +Чтобы начать, посетите [документацию](https://docs.sqd.dev/) или посмотрите [примеры для EVM](https://github.com/subsquid-labs/squid-evm-examples), чтобы узнать, что можно создать с помощью SQD. + +## SubQuery Network {#subquery-network} + +[SubQuery](https://subquery.network/) — это ведущий индексатор данных, который предоставляет разработчикам быстрые, надежные, децентрализованные и настраиваемые API для их Web3-проектов. SubQuery предоставляет разработчикам из более чем 165 экосистем (включая Ethereum) доступ к обширным индексированным данным для создания интуитивно понятного и иммерсивного пользовательского опыта. Сеть SubQuery обеспечивает работу ваших неостанавливаемых приложений с помощью устойчивой и децентрализованной инфраструктурной сети. Используйте набор инструментов для разработчиков блокчейн-приложений от SubQuery для создания Web3-приложений будущего, не тратя время на создание пользовательского бэкенда для обработки данных. + +Для начала ознакомьтесь с [руководством по быстрому запуску для Ethereum](https://academy.subquery.network/quickstart/quickstart_chains/ethereum-gravatar.html), чтобы за считанные минуты начать индексировать данные блокчейна Ethereum в локальной среде Docker для тестирования, прежде чем запустить в [управляемом сервисе SubQuery](https://managedservice.subquery.network/) или в [децентрализованной сети SubQuery](https://app.subquery.network/dashboard). + +## Язык запросов EVM {#evm-query-language} + +Язык запросов EVM (EQL) — это SQL-подобный язык, предназначенный для отправки запросов к сетям на основе EVM (виртуальной машины Ethereum). Конечная цель EQL — поддержка сложных реляционных запросов к объектам первого класса сетей на базе EVM (блокам, аккаунтам и транзакциям) и предоставление разработчикам и исследователям эргономичного синтаксиса для повседневного использования. С помощью EQL разработчики могут извлекать данные блокчейна, используя знакомый SQL-подобный синтаксис, и избавиться от необходимости в сложном шаблонном коде. EQL поддерживает стандартные запросы данных блокчейна (например, получение нонса и баланса аккаунта в Ethereum или получение размера и временной отметки текущего блока) и постоянно добавляет поддержку более сложных запросов и наборов функций. + +## Дополнительные материалы {#further-reading} + +- [Изучение криптоданных, часть I: архитектуры потоков данных](https://web.archive.org/web/20250125012042/https://research.2077.xyz/exploring-crypto-data-1-data-flow-architectures) +- [Обзор сети The Graph](https://thegraph.com/docs/en/about/) +- [Песочница для запросов The Graph](https://thegraph.com/explorer/subgraph/graphprotocol/graph-network-mainnet?version=current) +- [Примеры кода API на EtherScan](https://etherscan.io/apis#contracts) +- [Документация по API на Blockscout](https://docs.blockscout.com/devs/apis) +- [Beaconcha.in — обозреватель Beacon Chain](https://beaconcha.in) +- [Основы Dune](https://docs.dune.com/#dune-basics) +- [Руководство по быстрому запуску SubQuery для Ethereum](https://academy.subquery.network/indexer/quickstart/quickstart_chains/ethereum-gravatar.html) +- [Обзор сети SQD](https://docs.sqd.dev/) +- [Язык запросов EVM](https://eql.sh/blog/alpha-release-notes) diff --git a/public/content/translations/ru/developers/docs/data-availability/blockchain-data-storage-strategies/index.md b/public/content/translations/ru/developers/docs/data-availability/blockchain-data-storage-strategies/index.md new file mode 100644 index 00000000000..ade6c0018ad --- /dev/null +++ b/public/content/translations/ru/developers/docs/data-availability/blockchain-data-storage-strategies/index.md @@ -0,0 +1,118 @@ +--- +title: "Стратегии хранения данных в блокчейне" +description: "Существует несколько способов хранения данных с помощью блокчейна. В этой статье мы сравним различные стратегии, их стоимость и преимущества, а также требования к безопасному использованию." +lang: ru +--- + +Существует множество способов хранить информацию либо непосредственно на блокчейне, либо защитив её с помощью блокчейна: + +- Блобы EIP-4844 +- Calldata +- Офчейн с механизмами L1 +- «Код» контракта +- Мероприятия +- Хранилище EVM + +Выбор метода основывается на нескольких критериях: + +- Источник информации. Информация в calldata не может поступать напрямую из самого блокчейна. +- Назначение информации. Calldata доступна только в транзакции, которая ее включает. События совершенно недоступны ончейн. +- Какой уровень сложности является приемлемым? Компьютеры, на которых запущен полный узел, могут выполнять больше обработки, чем легкий клиент в приложении, работающем в браузере. +- Необходимо ли обеспечивать легкий доступ к информации с каждого узла? +- Требования к безопасности. + +## Требования к безопасности {#security-requirements} + +В целом информационная безопасность состоит из трех атрибутов: + +- _Конфиденциальность_: неавторизованные субъекты не могут читать информацию. Это важно во многих случаях, но не в этом. _В блокчейне не существует секретов_. Блокчейны работают, потому что любой может проверить переходы состояний, поэтому их невозможно использовать для прямого хранения секретов. Существуют способы хранения конфиденциальной информации в блокчейне, но все они используют какой-либо офф-чейн-компонент для хранения как минимум одного ключа. + +- _Целостность_: информация корректна, она не может быть изменена неавторизованными субъектами или неавторизованными способами (например, передача [токенов ERC-20](https://eips.ethereum.org/EIPS/eip-20#events) без события `Transfer`). В блокчейне каждый узел проверяет каждое изменение состояния, что обеспечивает целостность. + +- _Доступность_, информация доступна любому уполномоченному лицу. В блокчейне это обычно достигается за счет того, что информация доступна в каждом [полном узле](https://ethereum.org/developers/docs/nodes-and-clients#full-node). + +Все представленные здесь решения обладают превосходной целостностью, поскольку хэши публикуются на L1. Однако у них разные гарантии доступности. + +## Предварительные условия {#prerequisites} + +Вы должны хорошо понимать [основы блокчейна](/developers/docs/intro-to-ethereum/). Эта страница также предполагает, что читатель знаком с [блоками](/developers/docs/blocks/), [транзакциями](/developers/docs/transactions/) и другими соответствующими темами. + +## Блобы EIP-4844 {#eip-4844-blobs} + +Начиная с [хардфорка Dencun](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/beacon-chain.md), блокчейн Ethereum включает [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844), который добавляет в Ethereum блобы данных с ограниченным сроком хранения (изначально около [18 дней](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/p2p-interface.md#configuration)). Стоимость этих блобов рассчитывается отдельно от [газа за исполнение](/developers/docs/gas), хотя и с использованием похожего механизма. Это дешевый способ публикации временных данных. + +Основной вариант использования блобов EIP-4844 — это публикация транзакций роллапами. [Оптимистические ролл-апы](/developers/docs/scaling/optimistic-rollups) должны публиковать транзакции в своих блокчейнах. Эти транзакции должны быть доступны любому в течение [периода оспаривания](https://docs.optimism.io/connect/resources/glossary#challenge-period), чтобы [валидаторы](https://docs.optimism.io/connect/resources/glossary#validator) могли исправить ошибку, если [секвенсор](https://docs.optimism.io/connect/resources/glossary#sequencer) ролл-апа публикует некорректный корень состояния. + +Однако, как только период оспаривания пройдет и корень состояния будет финализирован, оставшаяся цель хранения этих транзакций заключается в воспроизведении текущего состояния сети. Это состояние также доступно на узлах сети и требует гораздо меньшей обработки. Поэтому информация о транзакциях все равно должна сохраняться в нескольких местах, таких как [обозреватели блоков](/developers/docs/data-and-analytics/block-explorers), но нет необходимости платить за тот уровень устойчивости к цензуре, который предоставляет Ethereum. + +[Ролл-апы с нулевым разглашением](/developers/docs/scaling/zk-rollups/#data-availability) также публикуют данные своих транзакций, чтобы другие узлы могли воспроизводить существующее состояние и проверять доказательства достоверности, но это опять же краткосрочное требование. + +На момент написания статьи публикация в EIP-4844 стоит один wei (10-18 ETH) за байт, что ничтожно мало по сравнению со [стоимостью в 21 000 единиц газа за исполнение, которые требуются для любой транзакции, включая ту, что публикует блобы](https://eth.blockscout.com/tx/0xf6cfaf0431c73dd1d96369a5e6707d64f463ccf477a4131265397f1d81466929?tab=index). Вы можете увидеть текущую цену EIP-4844 на [blobscan.com](https://blobscan.com/blocks). + +Вот адреса, по которым можно увидеть блобы, опубликованные некоторыми известными роллапами. + +| Накопительные пакеты - это общий подход к масштабированию открытых контрактов, то есть контрактов, которые каждый может видеть и с которыми может взаимодействовать. При накоплении транзакции записываются в Ethereum (как calldata), но фактические вычисления и хранение контракта выполняются вне сети. Кто-то (валидатор) публикует в цепочке утверждение (также известное как блок Rollup) о том, что будет делать контракт - список действий, предпринятых контрактом, таких как произведенные платежи, и криптографический хеш его состояния после контракта. выполнил вызовы, которые уже были размещены в сети. Мы можем думать об утверждении как о «объединении» всех вызовов и их результатов в одну транзакцию в цепочке.Системы объединения отличаются тем, как они обеспечивают правильность утверждений | Адрес почтового ящика | +| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | +| [Optimism](https://www.optimism.io/) | [`0xFF00000000000000000000000000000000000010`](https://blobscan.com/address/0xFF00000000000000000000000000000000000010) | +| [Arbitrum](https://arbitrum.io/) | [`0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6`](https://blobscan.com/address/0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6) | +| [Base](https://base.org/) | [`0xFF00000000000000000000000000000000008453`](https://blobscan.com/address/0xFF00000000000000000000000000000000008453) | + +## Calldata {#calldata} + +Calldata — это байты, отправляемые в составе транзакции. Она хранится как часть постоянной записи блокчейна в блоке, который включает эту транзакцию. + +Это самый дешевый метод для постоянного размещения данных в блокчейне. Стоимость за байт составляет либо 4 единицы газа за исполнение (если байт нулевой), либо 16 единиц газа (любое другое значение). Если данные сжаты, что является стандартной практикой, то каждое значение байта равновероятно, поэтому средняя стоимость составляет примерно 15,95 единиц газа за байт. + +На момент написания статьи цены составляют 12 gwei за газ и 2300 $ за ETH, что означает стоимость примерно 45 центов за килобайт. Поскольку это был самый дешевый метод до EIP-4844, роллапы использовали его для хранения информации о транзакциях, которая должна быть доступна для [оспаривания ошибок](https://docs.optimism.io/stack/protocol/overview#fault-proofs), но не требует прямого доступа ончейн. + +Вот адреса, по которым можно увидеть транзакции, опубликованные некоторыми известными роллапами. + +| Накопительные пакеты - это общий подход к масштабированию открытых контрактов, то есть контрактов, которые каждый может видеть и с которыми может взаимодействовать. При накоплении транзакции записываются в Ethereum (как calldata), но фактические вычисления и хранение контракта выполняются вне сети. Кто-то (валидатор) публикует в цепочке утверждение (также известное как блок Rollup) о том, что будет делать контракт - список действий, предпринятых контрактом, таких как произведенные платежи, и криптографический хеш его состояния после контракта. выполнил вызовы, которые уже были размещены в сети. Мы можем думать об утверждении как о «объединении» всех вызовов и их результатов в одну транзакцию в цепочке.Системы объединения отличаются тем, как они обеспечивают правильность утверждений | Адрес почтового ящика | +| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | +| [Optimism](https://www.optimism.io/) | [`0xFF00000000000000000000000000000000000010`](https://eth.blockscout.com/address/0xFF00000000000000000000000000000000000010) | +| [Arbitrum](https://arbitrum.io/) | [`0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6`](https://eth.blockscout.com/address/0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6) | +| [Base](https://base.org/) | [`0xFF00000000000000000000000000000000008453`](https://eth.blockscout.com/address/0xFF00000000000000000000000000000000008453) | + +## Офчейн с механизмами L1 {#offchain-with-l1-mechs} + +В зависимости от ваших компромиссов в области безопасности, может быть приемлемо размещать информацию в другом месте и использовать механизм, который обеспечивает доступность данных при необходимости. Для этого необходимо выполнить два требования: + +1. Опубликовать [хэш](https://en.wikipedia.org/wiki/Cryptographic_hash_function) данных в блокчейне, называемый _обязательством по входным данным_. Это может быть одно 32-байтное слово, поэтому это недорого. Пока доступно обязательство по входным данным, целостность гарантирована, потому что невозможно найти другие данные, которые бы хэшировались в то же значение. Поэтому если будут предоставлены неверные данные, это можно будет обнаружить. + +2. Иметь механизм, обеспечивающий доступность. Например, в [Redstone](https://redstone.xyz/docs/what-is-redstone) любой узел может подать запрос на проверку доступности. Если секвенсор не ответит ончейн до установленного срока, обязательство по входным данным отбрасывается, и информация считается никогда не опубликованной. + +Это приемлемо для оптимистического ролл-апа, потому что мы уже полагаемся на наличие хотя бы одного честного верификатора для корня состояния. Такой честный верификатор также убедится, что у него есть данные для обработки блоков, и отправит запрос на проверку доступности, если информация недоступна офф-чейн. Этот тип оптимистического ролл-апа называется [plasma](/developers/docs/scaling/plasma/). + +## Код контракта {#contract-code} + +Информация, которая должна быть записана только один раз, никогда не перезаписывается и должна быть доступна на блокчейне, может храниться в виде кода контракта. Это означает, что мы создаем «смарт-контракт» с данными, а затем используем [`EXTCODECOPY`](https://www.evm.codes/#3c?fork=shanghai) для чтения информации. Преимущество в том, что копирование кода относительно дешево. + +Помимо стоимости расширения памяти, `EXTCODECOPY` стоит 2600 единиц газа за первый доступ к контракту (когда он «холодный») и 100 единиц газа за последующие копирования из того же контракта плюс 3 единицы газа за 32-байтовое слово. По сравнению с calldata, которая стоит 15,95 за байт, это дешевле, начиная примерно с 200 байт. Согласно [формуле стоимости расширения памяти](https://www.evm.codes/about#memoryexpansion), пока вам не нужно более 4 МБ памяти, стоимость расширения памяти меньше стоимости добавления calldata. + +Конечно, это только стоимость _чтения_ данных. Создание контракта стоит примерно 32 000 единиц газа + 200 единиц газа/байт. Этот метод экономичен только тогда, когда одна и та же информация должна быть прочитана много раз в разных транзакциях. + +Код контракта может быть бессмысленным, пока он не начинается с `0xEF`. Контракты, начинающиеся с `0xEF`, интерпретируются как [формат объектов Ethereum](https://notes.ethereum.org/@ipsilon/evm-object-format-overview), который имеет гораздо более строгие требования. + +## События {#events} + +[События](https://docs.alchemy.com/docs/solidity-events) генерируются смарт-контрактами и считываются офф-чейн программным обеспечением. +Их преимущество в том, что офф-чейн код может прослушивать события. Стоимость составляет [газ](https://www.evm.codes/#a0?fork=cancun): 375 плюс 8 единиц газа за байт данных. При цене 12 gwei за газ и 2300 $ за ETH это составляет один цент плюс 22 цента за килобайт. + +## Хранилища {#storage} + +Смарт-контракты имеют доступ к [постоянному хранилищу](https://docs.alchemy.com/docs/smart-contract-storage-layout#what-is-storage-memory). Однако его использование очень дорого. Запись 32-байтного слова в ранее пустую ячейку хранилища может [стоить 22 100 единиц газа](https://www.evm.codes/#55?fork=cancun). При цене 12 gwei за газ и 2300 $ за ETH это составляет около 61 цента за операцию записи, или 19,5 $ за килобайт. + +Это самая дорогая форма хранения в Ethereum. + +## Сводка {#summary} + +В этой таблице кратко изложены различные варианты, их преимущества и недостатки. + +| Тип хранилища | Источник данных | Гарантия доступности | Доступность ончейн | Дополнительные ограничения | +| ----------------------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------- | -------------------------------------------------------------------------- | +| Блобы EIP-4844 | Офф-чейн | Гарантия Ethereum на [~18 дней](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/p2p-interface.md#configuration) | Доступен только хэш | | +| Calldata | Офф-чейн | Гарантия Ethereum навсегда (часть блокчейна) | Доступно только при записи в контракт и в рамках этой транзакции | | +| Офчейн с механизмами L1 | Офф-чейн | Гарантия «одного честного верификатора» в течение периода оспаривания | Только хэш | Гарантируется механизмом оспаривания, только в течение периода оспаривания | +| Код контракта | Ончейн или офф-чейн | Гарантия Ethereum навсегда (часть блокчейна) | Да | Записывается на «случайный» адрес, не может начинаться с `0xEF` | +| Мероприятия | Ончейн | Гарантия Ethereum навсегда (часть блокчейна) | Нет | | +| Хранилище | Ончейн | Гарантия Ethereum навсегда (часть блокчейна и текущего состояния до перезаписи) | Да | | diff --git a/public/content/translations/ru/developers/docs/data-availability/index.md b/public/content/translations/ru/developers/docs/data-availability/index.md new file mode 100644 index 00000000000..005b06a3073 --- /dev/null +++ b/public/content/translations/ru/developers/docs/data-availability/index.md @@ -0,0 +1,84 @@ +--- +title: "Доступность данных" +description: "Обзор проблем и решений, связанных с доступностью данных в Ethereum" +lang: ru +--- + +«Не доверяй, проверяй» — довольно распространенный принцип Ethereum. Идея состоит в том, что ваш узел в любом случае проверяет правильность получаемой информации, выполняя все транзакции в блоках, которые он получает от узлов, чтобы гарантировать, что предлагаемые изменения точно соответствуют изменениям, вычисленным узлом независимо. Это означает, что узлам не нужно верить в честность отправителей блока. Это невозможно при отсутствии данных. + +**Доступность данных** означает уверенность пользователя в том, что данные, необходимые для проверки блока, действительно доступны всем участникам сети. Для полных узлов на уровне 1 Ethereum это относительно просто: полный узел загружает копию всех данных в каждом блоке — данные _должны_ быть доступны, чтобы их можно было загрузить. Блок с отсутствующими данными будет отброшен, а не добавлен в блокчейн. Это «ончейн-доступность данных», и это особенность монолитных блокчейнов. Полные узлы невозможно обманом заставить принять недействительные транзакции, поскольку они загружают и выполняют каждую транзакцию самостоятельно. Однако для модульных блокчейнов, накопительных пакетов уровня 2 и легких клиентов ситуация с доступностью данных более сложна и требует более сложных процедур проверки. + +## Предварительные условия {#prerequisites} + +Вы должны хорошо понимать [основы блокчейна](/developers/docs/intro-to-ethereum/), особенно [механизмы консенсуса](/developers/docs/consensus-mechanisms/). Эта страница также предполагает, что читатель знаком с [блоками](/developers/docs/blocks/), [транзакциями](/developers/docs/transactions/), [узлами](/developers/docs/nodes-and-clients/), [решениями для масштабирования](/developers/docs/scaling/) и другими соответствующими темами. + +## Проблема доступности данных {#the-data-availability-problem} + +Проблема доступности данных заключается в необходимости доказать всей сети, что обобщенная форма некоторых данных транзакций, добавляемых в блокчейн, действительно представляет собой набор действительных транзакций, но при этом не требуется, чтобы все узлы загружали все данные. Полные данные транзакций необходимы для независимой проверки блоков, но требование ко всем узлам загружать все данные транзакций является препятствием для масштабирования. Решения проблемы доступности данных призваны гарантировать, что полные данные транзакций были доступны для проверки участникам сети, которые не загружают и не хранят данные для себя. + +[Легкие узлы](/developers/docs/nodes-and-clients/light-clients) и [ролл-апы уровня 2](/developers/docs/scaling/) являются важными примерами участников сети, которым требуются надежные гарантии доступности данных, но которые не могут самостоятельно загружать и обрабатывать данные транзакций. Избегание загрузки данных транзакций — вот что делает легкие узлы легкими и позволяет объединениям быть эффективными решениями для масштабирования. + +Доступность данных также является критически важной проблемой для будущих [«несохраняющих состояние»](/roadmap/statelessness) клиентов Ethereum, которым не нужно загружать и хранить данные о состоянии для проверки блоков. Несохраняющие состояние клиенты все равно должны быть уверены, что данные доступны _где-то_ и что они были правильно обработаны. + +## Решения для обеспечения доступности данных {#data-availability-solutions} + +### Сэмплирование доступности данных (DAS) {#data-availability-sampling} + +Выборка доступности данных (DAS) — это способ проверки доступности данных в сети без слишком большой нагрузки на какой-либо отдельный узел. Каждый узел (включая узлы, не участвующие в стейкинге) загружает небольшое, случайно выбранное подмножество общих данных. Успешная загрузка выборки с высокой степенью уверенности подтверждает доступность всех данных. Это основано на кодировании со стиранием данных, которое расширяет заданный набор данных избыточной информацией (это делается путем подбора к данным функции, известной как _полином_, и вычисления этого полинома в дополнительных точках). Это позволяет при необходимости восстановить исходные данные из избыточных данных. Следствием такого создания данных является то, что если _любая часть_ исходных данных недоступна, _половина_ расширенных данных также будет отсутствовать! Количество выборок данных, загружаемых каждым узлом, можно настроить так, чтобы было _чрезвычайно_ вероятно, что хотя бы один из фрагментов данных, выбранных каждым клиентом, будет отсутствовать, _если_ в действительности доступно менее половины данных. + +DAS будет использоваться, чтобы операторы ролл-апов обеспечивали доступность данных своих транзакций после внедрения [полного Danksharding](/roadmap/danksharding/#what-is-danksharding). Узлы Ethereum будут случайным образом выбирать данные транзакций, предоставленные в виде больших двоичных объектов, используя описанную выше схему избыточности, чтобы гарантировать существование всех данных. Тот же метод можно также использовать, чтобы гарантировать, что производители блоков делают все свои данные доступными для защиты легких клиентов. Аналогично, при [разделении предлагающего и сборщика](/roadmap/pbs) только сборщик блока должен будет обработать весь блок, а другие валидаторы будут выполнять проверку с помощью сэмплирования доступности данных. + +### Комитеты по доступности данных {#data-availability-committees} + +Комитеты доступности данных (DAC) — это доверенные стороны, которые обеспечивают или подтверждают доступность данных. DAC могут использоваться вместо DAS [или в сочетании с ним](https://hackmd.io/@vbuterin/sharding_proposal#Why-not-use-just-committees-and-not-DAS). Гарантии безопасности, предоставляемые комитетам, зависят от конкретной структуры. Например, Ethereum использует случайно выбранные подмножества валидаторов для подтверждения доступности данных для легких узлов. + +DAC также используются некоторыми валидиумами. DAC — это доверенный набор узлов, который хранит копии данных в автономном режиме. DAC обязан предоставлять доступ данных в случае возникновения спора. Члены DAC также публикуют ончейн-аттестации, чтобы доказать, что указанные данные действительно доступны. Некоторые валидиумы заменяют DAC системой валидации «доказательство владения» (PoS). Здесь любой желающий может стать валидатором и хранить данные оффчейн. Однако они должны предоставить «связь», заложенную в смарт-контракте. В случае злонамеренного поведения, например, сокрытия данных валидатором, связь может быть сокращена. Комитеты по доступности данных на основе доказательства владенния значительно более безопасны, чем обычные DAC, поскольку они стимулируют честное поведение напрямую. + +## Доступность данных и легкие узлы {#data-availability-and-light-nodes} + +[Легкие узлы](/developers/docs/nodes-and-clients/light-clients) должны проверять правильность заголовков блоков, которые они получают, не загружая данные блока. Платой за эту легкость является невозможность независимо проверять заголовки блоков путем локального повторного выполнения транзакций, как это делают полные узлы. + +Легкие узлы Ethereum доверяют случайным наборам из 512 валидаторов, которые были назначены в _комитет синхронизации_. Комитет синхронизации выступает как DAC, который с помощью криптографической подписи сигнализирует легким клиентам о том, что данные в заголовке верны. Каждый день комитет синхронизации обновляется. Каждый заголовок блока оповещает легкие узлы о том, какие валидаторы должны подписать _следующий_ блок, поэтому их нельзя обманом заставить доверять злонамеренной группе, выдающей себя за настоящий комитет синхронизации. + +Однако что произойдет, если злоумышленнику каким-то образом _все-таки_ удастся передать вредоносный заголовок блока легким клиентам и убедить их, что он был подписан честным комитетом синхронизации? В этом случае злоумышленник может включить недействительные транзакции, и легкий клиент будет слепо их принимать, поскольку он не проверяет отдельно все изменения состояния, суммированные в заголовке блока. Чтобы защититься от этого, легкий клиент может использовать доказательства мошенничества. + +Принцип работы этих доказательств мошенничества заключается в том, что полный узел, видя, что по сети распространяются слухи о недопустимом переходе состояния, может быстро сгенерировать небольшой фрагмент данных, демонстрирующий, что предлагаемый переход состояния не может возникнуть в результате заданного набора транзакций, и передать эти данные одноранговым узлам. Легкие узлы могут собирать эти доказательства мошенничества и использовать их для удаления заголовков плохих блоков, гарантируя, что они останутся в той же честной цепочке, что и полные узлы. + +Процесс зависит от того, что полные узлы имеют доступ ко всем данным транзакций. Злоумышленник, который передает плохой заголовок блока, а также не предоставляет доступ к данным транзакции, сможет помешать полным узлам генерировать доказательства мошенничества. Полные узлы могли бы подать сигнал предупреждения о плохом блоке, но они не смогли бы подкрепить свое предупреждение доказательством, потому что у них нет доступа к этим данным! + +Решением этой проблемы доступности данных является DAS. Легкие узлы загружают очень небольшие случайные фрагменты полных данных о состоянии и используют образцы для проверки доступности полного набора данных. Фактическую вероятность неверного предположения о полной доступности данных после загрузки N случайных фрагментов можно рассчитать ([для 100 фрагментов шанс составляет 10^-30](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html), т. е. это невероятно маловероятно). + +Даже в этом сценарии атаки, которые удерживают всего несколько байтов, могут остаться незамеченными для клиентов, выполняющих случайные запросы данных. Стирающая кодировка исправляет это, восстанавливая небольшие недостающие фрагменты данных, которые можно использовать для проверки предполагаемых изменений состояния. Затем можно построить доказательство мошенничества с использованием реконструированных данных, предотвращая принятие легкими узлами неверных заголовков. + +**Примечание:** DAS и доказательства мошенничества еще не реализованы для легких клиентов Ethereum с доказательством владения (proof-of-stake), но они есть в дорожной карте и, скорее всего, будут реализованы в форме доказательств на основе ZK-SNARK. Сегодняшние легкие клиенты полагаются на своего рода DAC: они проверяют личность комитета синхронизации, а затем доверяют полученным подписанным заголовкам блоков. + +## Доступность данных и ролл-апы уровня 2 {#data-availability-and-layer-2-rollups} + +[Решения для масштабирования уровня 2](/layer-2/), такие как [ролл-апы](/glossary/#rollups), снижают стоимость транзакций и увеличивают пропускную способность Ethereum за счет обработки транзакций оффчейн. Транзакции ролл-апов сжимаются и публикуются в Ethereum пакетами. Пакеты представляют собой тысячи отдельных оффчейн-транзакций в рамках одной транзакции в Ethereum. Это уменьшает перегрузку на базовом уровне и снижает плату для пользователей. + +Однако доверять «сводным» транзакциям, опубликованным в Ethereum, можно только в том случае, если предлагаемое изменение состояния может быть независимо проверено и подтверждено как результат применения всех отдельных оффчейн-транзакций. Если операторы ролл-апов не предоставляют данные транзакций для этой проверки, они могут отправить неверные данные в Ethereum. + +[Оптимистические ролл-апы](/developers/docs/scaling/optimistic-rollups/) публикуют сжатые данные транзакций в Ethereum и ожидают некоторое время (обычно 7 дней), чтобы независимые верификаторы могли проверить данные. Если кто-либо обнаружит проблему, он может создать доказательство мошенничества и использовать его для оспаривания ролл-апа. Это приведет к откату цепочки и пропуску недопустимого блока. Это возможно только при наличии данных. В настоящее время существует два способа, которыми оптимистические ролл-апы публикуют данные транзакций на уровень 1. Некоторые ролл-апы делают данные постоянно доступными как `CALLDATA`, которые постоянно хранятся ончейн. С внедрением EIP-4844 некоторые ролл-апы вместо этого публикуют данные своих транзакций в более дешевое blob-хранилище. Это не постоянное хранилище. Независимые верификаторы должны запрашивать blob-объекты и выдвигать свои оспаривания в течение ~18 дней, прежде чем данные будут удалены с уровня 1 Ethereum. Доступность данных гарантируется протоколом Ethereum только в течение этого короткого фиксированного окна. После этого ответственность за него переходят к другим субъектам экосистемы Ethereum. Любой узел может проверить доступность данных с помощью DAS, т. е. путем загрузки небольших случайных выборок blob-данных. + +[Ролл-апам с 0-знанием (ZK)](/developers/docs/scaling/zk-rollups) не нужно публиковать данные транзакций, поскольку [доказательства действительности с 0-знанием](/glossary/#zk-proof) гарантируют правильность переходов состояния. Однако доступность данных по-прежнему остается проблемой, поскольку мы не можем гарантировать функциональность ролл-апа ZK (или взаимодействовать с ним) без доступа к данным о его состоянии. Например, пользователи не смогут узнать свои балансы, если оператор скрывает информацию о состоянии ролл-апа. Кроме того, они не могут выполнять обновления состояния, используя информацию, содержащуюся в недавно добавленном блоке. + +## Доступность данных в сравнении с возможностью их извлечения {#data-availability-vs-data-retrievability} + +Доступность данных отличается от возможности их извлечения. Доступность данных — это гарантия того, что полные узлы смогут получить доступ и проверить полный набор транзакций, связанных с конкретным блоком. Из этого не обязательно следует, что данные доступны навсегда. + +Возможность извлечения данных — это способность узлов извлекать _историческую информацию_ из блокчейна. Эти исторические данные не нужны для проверки новых блоков, они необходимы только для синхронизации полных узлов из исходного блока или обслуживания определенных исторических запросов. + +Основной протокол Ethereum в первую очередь касается доступности данных, а не возможности их извлечения. Возможность извлечения данных может обеспечиваться небольшой группой архивных узлов, управляемых третьими лицами, или она может быть распределена по сети с использованием децентрализованного файлового хранилища, такого как [Portal Network](https://www.ethportal.net/). + +## Дополнительные материалы {#further-reading} + +- [WTF is Data Availability?](https://medium.com/blockchain-capital-blog/wtf-is-data-availability-80c2c95ded0f) +- [Что такое доступность данных?](https://coinmarketcap.com/academy/article/what-is-data-availability) +- [Краткое руководство по проверкам доступности данных](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html) +- [Объяснение предложения по шардингу и DAS](https://hackmd.io/@vbuterin/sharding_proposal#ELI5-data-availability-sampling) +- [Заметка о доступности данных и кодировании со стиранием](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding#can-an-attacker-not-circumvent-this-scheme-by-releasing-a-full-unavailable-block-but-then-only-releasing-individual-bits-of-data-as-clients-query-for-them) +- [Комитеты по доступности данных.](https://medium.com/starkware/data-availability-e5564c416424) +- [Комитеты по доступности данных на основе доказательства владения (proof-of-stake).](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf) +- [Решения проблемы извлечения данных](https://notes.ethereum.org/@vbuterin/data_sharding_roadmap#Who-would-store-historical-data-under-sharding) +- [Доступность данных, или: как ролл-апы научились не волноваться и полюбили Ethereum](https://web.archive.org/web/20250515194659/https://web.archive.org/web/20241108192208/https/research.2077.xyz/data-availability-or-how-rollups-learned-to-stop-worrying-and-love-ethereum) +- [EIP-7623: увеличение стоимости Calldata](https://web.archive.org/web/20250515194659/https://research.2077.xyz/eip-7623-increase-calldata-cost) diff --git a/public/content/translations/ru/developers/docs/data-structures-and-encoding/index.md b/public/content/translations/ru/developers/docs/data-structures-and-encoding/index.md new file mode 100644 index 00000000000..b5d3ef8ff75 --- /dev/null +++ b/public/content/translations/ru/developers/docs/data-structures-and-encoding/index.md @@ -0,0 +1,32 @@ +--- +title: "Структуры данных и кодирование" +description: "Обзор фундаментальных структур данных Ethereum." +lang: ru +sidebarDepth: 2 +--- + +Ethereum создает, хранит и передает большие объемы данных. Эти данные должны быть отформатированы стандартизированным и экономящим память способом, чтобы позволить любому человеку [запустить узел](/run-a-node/) на относительно скромном оборудовании потребительского класса. Для этого на стэке Ethereum используются несколько определенных структур данных. + +## Предварительные условия {#prerequisites} + +Вы должны понимать основы Ethereum и [клиентского программного обеспечения](/developers/docs/nodes-and-clients/). Рекомендуется ознакомиться с сетевым уровнем и [«Белой книгой» Ethereum](/whitepaper/). + +## Структуры данных {#data-structures} + +### Деревья Меркла-Патриции {#patricia-merkle-tries} + +Деревья Меркла-Патриции — это структуры, которые кодируют пары «ключ-значение» в детерминированное и криптографически заверенное префиксное дерево. Они широко используются на уровне исполнения Ethereum. + +[Подробнее о деревьях Меркла-Патриции](/developers/docs/data-structures-and-encoding/patricia-merkle-trie) + +### Рекурсивный префикс длины {#recursive-length-prefix} + +Рекурсивный префикс длины (RLP) — это метод сериализации, который широко используется на уровне исполнения Ethereum. + +[Подробнее о RLP](/developers/docs/data-structures-and-encoding/rlp) + +### Простая сериализация {#simple-serialize} + +Простая сериализация (SSZ) — это доминирующий формат сериализации на уровне консенсуса Ethereum из-за его совместимости с меркелизацией. + +[Подробнее о SSZ](/developers/docs/data-structures-and-encoding/ssz) diff --git a/public/content/translations/ru/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md b/public/content/translations/ru/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md new file mode 100644 index 00000000000..59939c484bb --- /dev/null +++ b/public/content/translations/ru/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md @@ -0,0 +1,266 @@ +--- +title: "Дерево Меркла-Патрисии" +description: "Введение в дерево Меркла-Патрисии." +lang: ru +sidebarDepth: 2 +--- + +Состояние Ethereum (совокупность всех аккаунтов, балансов и смарт-контрактов) кодируется в специальную версию структуры данных, известной в информатике как дерево Меркла. Эта структура полезна для многих приложений в криптографии, поскольку она создает проверяемую связь между всеми отдельными фрагментами данных, объединенными в дереве, в результате чего получается одно **корневое** значение, которое можно использовать для доказательства утверждений о данных. + +Структура данных Ethereum — это «модифицированное дерево Меркла-Патрисии», названное так потому, что оно заимствует некоторые функции PATRICIA (практического алгоритма для извлечения информации, закодированной в буквенно-цифровом виде), а также потому, что оно предназначено для эффективного извлечения (re**trie**val) элементов, составляющих состояние Ethereum. + +Дерево Меркла-Патрисии является детерминированным и криптографически верифицируемым: единственный способ сгенерировать корень состояния — это вычислить его из каждой отдельной части состояния, а идентичность двух состояний можно легко доказать, сравнив корневой хэш и хэши, которые к нему привели (_доказательство Меркла_). И наоборот, невозможно создать два разных состояния с одним и тем же корневым хэшем, и любая попытка изменить состояние с другими значениями приведет к другому корневому хэшу. Теоретически, эта структура обеспечивает «святой Грааль» эффективности `O(log(n))` для вставок, поиска и удалений. + +В ближайшем будущем Ethereum планирует перейти на структуру [дерева Веркла](/roadmap/verkle-trees), что откроет много новых возможностей для будущих улучшений протокола. + +## Предварительные условия {#prerequisites} + +Чтобы лучше понять эту страницу, было бы полезно иметь базовые знания о [хэшах](https://en.wikipedia.org/wiki/Hash_function), [деревьях Меркла](https://en.wikipedia.org/wiki/Merkle_tree), [префиксных деревьях (tries)](https://en.wikipedia.org/wiki/Trie) и [сериализации](https://en.wikipedia.org/wiki/Serialization). Эта статья начинается с описания базового [radix-дерева](https://en.wikipedia.org/wiki/Radix_tree), а затем постепенно вводит модификации, необходимые для более оптимизированной структуры данных Ethereum. + +## Базовые radix-деревья {#basic-radix-tries} + +В базовом radix-дереве каждый узел выглядит следующим образом: + +``` + [i_0, i_1 ... i_n, value] +``` + +Где `i_0 ...` `i_n` представляют собой символы алфавита (часто двоичные или шестнадцатеричные), `value` — это конечное значение в узле, а значения в `i_0, i_1 ...` ячейках `i_n` — это либо `NULL`, либо указатели на (в нашем случае, хэши) другие узлы. Это формирует базовое хранилище `(ключ, значение)`. + +Допустим, вы хотите использовать структуру данных radix-дерева для сохранения порядка в наборе пар «ключ-значение». Чтобы найти значение, сопоставленное в данный момент с ключом `dog` в дереве, сначала нужно преобразовать `dog` в буквы алфавита (получив `64 6f 67`), а затем спускаться по дереву по этому пути, пока не найдете значение. То есть вы начинаете с поиска корневого хэша в плоской базе данных «ключ/значение», чтобы найти корневой узел дерева. Он представлен в виде массива ключей, указывающих на другие узлы. Вы бы использовали значение по индексу `6` в качестве ключа и искали бы его в плоской базе данных «ключ/значение», чтобы получить узел на один уровень ниже. Затем выберите индекс `4` для поиска следующего значения, затем выберите индекс `6` и так далее, пока, пройдя по пути: `корень -> 6 -> 4 -> 6 -> 15 -> 6 -> 7`, вы не найдете значение узла и не вернете результат. + +Существует разница между поиском чего-либо в «дереве» (trie) и в базовой плоской «БД» (DB) «ключ/значение». Оба они определяют сопоставления «ключ/значение», но базовая БД может выполнять традиционный одношаговый поиск ключа. Поиск ключа в дереве требует нескольких обращений к базовой БД для получения конечного значения, как описано выше. Чтобы устранить двусмысленность, будем называть последнее `путем` (path). + +Операции обновления и удаления для radix-деревьев можно определить следующим образом: + +```python + def update(node_hash, path, value): + curnode = db.get(node_hash) if node_hash else [NULL] * 17 + newnode = curnode.copy() + if path == "": + newnode[-1] = value + else: + newindex = update(curnode[path[0]], path[1:], value) + newnode[path[0]] = newindex + db.put(hash(newnode), newnode) + return hash(newnode) + + def delete(node_hash, path): + if node_hash is NULL: + return NULL + else: + curnode = db.get(node_hash) + newnode = curnode.copy() + if path == "": + newnode[-1] = NULL + else: + newindex = delete(curnode[path[0]], path[1:]) + newnode[path[0]] = newindex + + if all(x is NULL for x in newnode): + return NULL + else: + db.put(hash(newnode), newnode) + return hash(newnode) +``` + +Radix-дерево Меркла строится путем связывания узлов с помощью детерминированно сгенерированных криптографических хэш-дайджестов. Эта адресация по содержимому (в БД «ключ/значение» `key == keccak256(rlp(value))`) обеспечивает криптографическую гарантию целостности хранимых данных. Если корневой хэш данного дерева общеизвестен, то любой, у кого есть доступ к базовым листовым данным, может построить доказательство того, что дерево включает данное значение по определенному пути, предоставив хэши каждого узла, соединяющего конкретное значение с корнем дерева. + +Злоумышленник не может предоставить доказательство для пары `(путь, значение)`, которой не существует, поскольку корневой хэш в конечном счете основан на всех хэшах, находящихся под ним. Любое базовое изменение изменило бы корневой хэш. Вы можете думать о хэше как о сжатом представлении структурной информации о данных, защищенном устойчивостью хэш-функции к нахождению прообраза. + +Атомарную единицу radix-дерева (например, один шестнадцатеричный символ или 4-битное двоичное число) мы будем называть «ниббл» (полубайт). При обходе пути по одному нибблу за раз, как описано выше, узлы могут ссылаться максимум на 16 дочерних элементов, но при этом включают элемент `value`. Следовательно, мы представляем их в виде массива длиной 17. Мы называем эти 17-элементные массивы «ветвящимися узлами». + +## Дерево Меркла-Патрисии {#merkle-patricia-trees} + +У radix-деревьев есть одно серьезное ограничение: они неэффективны. Если вы хотите сохранить одну привязку `(путь, значение)`, где путь, как в Ethereum, имеет длину 64 символа (количество нибблов в `bytes32`), нам потребуется более килобайта дополнительного пространства для хранения одного уровня на символ, и каждый поиск или удаление займет все 64 шага. Дерево Патрисии, представленное далее, решает эту проблему. + +### Оптимизация {#optimization} + +Узел в дереве Меркла-Патрисии является одним из следующих: + +1. `NULL` (представленный в виде пустой строки) +2. `branch` (ветвь) — узел из 17 элементов `[ v0 ...` v15, vt ]` +3. `leaf` (лист) — узел из 2 элементов `[ encodedPath, value ]` +4. `extension` (расширение) — узел из 2 элементов `[ encodedPath, key ]` + +При 64-символьных путях неизбежно, что после прохождения первых нескольких уровней дерева вы достигнете узла, в котором не существует расходящегося пути, по крайней мере, на части оставшегося спуска. Чтобы избежать необходимости создавать до 15 разреженных `NULL` узлов на пути, мы сокращаем спуск, устанавливая узел `extension` (расширение) вида `[ encodedPath, key ]`, где `encodedPath` содержит «частичный путь» для пропуска вперед (с использованием компактного кодирования, описанного ниже), а `key` — для следующего поиска в БД. + +Для `листового` узла, который может быть помечен флагом в первом ниббле `encodedPath`, путь кодирует все фрагменты пути предыдущих узлов, и мы можем напрямую найти `значение`. + +Однако описанная выше оптимизация вносит неоднозначность. + +При обходе путей по нибблам мы можем получить нечетное количество нибблов для обхода, но поскольку все данные хранятся в формате `байтов` (bytes). Невозможно различить, например, ниббл `1` и нибблы `01` (оба должны храниться как `<01>`). Чтобы указать нечетную длину, частичный путь снабжается префиксом-флагом. + +### Спецификация: компактное кодирование шестнадцатеричной последовательности с необязательным терминатором {#specification} + +Маркировка как _нечетной/четной длины оставшегося частичного пути_, так и _листового/расширяющего узла_, как описано выше, находится в первом ниббле частичного пути любого узла из 2 элементов. Это приводит к следующему: + +| шестн. символ | биты | тип узла/частичный | длина пути | +| ----------------------------- | ---- | ---------------------------------- | ---------- | +| 0 | 0000 | расширение | четная | +| 1 | 0001 | расширение | нечетная | +| 2 | 0010 | конечный (лист) | четная | +| 3 | 0011 | конечный (лист) | нечетная | + +Для четной оставшейся длины пути (`0` или `2`) всегда будет следовать еще один «заполняющий» ниббл `0`. + +```python + def compact_encode(hexarray): + term = 1 if hexarray[-1] == 16 else 0 + if term: + hexarray = hexarray[:-1] + oddlen = len(hexarray) % 2 + flags = 2 * term + oddlen + if oddlen: + hexarray = [flags] + hexarray + else: + hexarray = [flags] + [0] + hexarray + # hexarray now has an even length whose first nibble is the flags. + o = "" + for i in range(0, len(hexarray), 2): + o += chr(16 * hexarray[i] + hexarray[i + 1]) + return o +``` + +Примеры: + +```python + > [1, 2, 3, 4, 5, ...] + '11 23 45' + > [0, 1, 2, 3, 4, 5, ...] + '00 01 23 45' + > [0, f, 1, c, b, 8, 10] + '20 0f 1c b8' + > [f, 1, c, b, 8, 10] + '3f 1c b8' +``` + +Вот расширенный код для получения узла в дереве Меркла-Патрисии: + +```python + def get_helper(node_hash, path): + if path == []: + return node_hash + if node_hash == "": + return "" + curnode = rlp.decode(node_hash if len(node_hash) < 32 else db.get(node_hash)) + if len(curnode) == 2: + (k2, v2) = curnode + k2 = compact_decode(k2) + if k2 == path[: len(k2)]: + return get(v2, path[len(k2) :]) + else: + return "" + elif len(curnode) == 17: + return get_helper(curnode[path[0]], path[1:]) + + def get(node_hash, path): + path2 = [] + for i in range(len(path)): + path2.push(int(ord(path[i]) / 16)) + path2.push(ord(path[i]) % 16) + path2.push(16) + return get_helper(node_hash, path2) +``` + +### Пример дерева {#example-trie} + +Предположим, мы хотим создать дерево, содержащее четыре пары «путь/значение»: `('do', 'глагол')`, `('dog', 'щенок')`, `('doge', 'монеты')`, `('horse', 'жеребец')`. + +Сначала мы преобразуем и пути, и значения в `байты`. Ниже фактические байтовые представления для _путей_ обозначаются через `<>`, хотя _значения_ все еще показаны как строки, обозначаемые `''`, для облегчения понимания (они тоже на самом деле были бы `байтами`): + +``` + <64 6f> : 'глагол' + <64 6f 67> : 'щенок' + <64 6f 67 65> : 'монеты' + <68 6f 72 73 65> : 'жеребец' +``` + +Теперь мы строим такое дерево со следующими парами «ключ/значение» в базовой БД: + +``` + rootHash: [ <16>, hashA ] + hashA: [ <>, <>, <>, <>, hashB, <>, <>, <>, [ <20 6f 72 73 65>, 'жеребец' ], <>, <>, <>, <>, <>, <>, <>, <> ] + hashB: [ <00 6f>, hashC ] + hashC: [ <>, <>, <>, <>, <>, <>, hashD, <>, <>, <>, <>, <>, <>, <>, <>, <>, 'глагол' ] + hashD: [ <17>, [ <>, <>, <>, <>, <>, <>, [ <35>, 'монеты' ], <>, <>, <>, <>, <>, <>, <>, <>, <>, 'щенок' ] ] +``` + +Когда один узел ссылается на другой, включается `keccak256(rlp.encode(node))`, если `len(rlp.encode(node)) >= 32`, иначе `node`, где `rlp.encode` — это функция кодирования [RLP](/developers/docs/data-structures-and-encoding/rlp). + +Обратите внимание, что при обновлении дерева необходимо сохранять пару «ключ/значение» `(keccak256(x), x)` в постоянной таблице поиска, _если_ вновь созданный узел имеет длину >= 32. Однако, если узел короче, ничего хранить не нужно, так как функция f(x) = x обратима. + +## Деревья в Ethereum {#tries-in-ethereum} + +Все деревья Меркла на уровне исполнения Ethereum используют дерево Меркла-Патрисии. + +В заголовке блока есть 3 корня от 3 из этих деревьев. + +1. stateRoot +2. transactionsRoot +3. receiptsRoot + +### Дерево состояний {#state-trie} + +Существует одно глобальное дерево состояний, и оно обновляется каждый раз, когда клиент обрабатывает блок. В нем `path` всегда равен `keccak256(ethereumAddress)`, а `value` всегда равен `rlp(ethereumAccount)`. Более конкретно, `аккаунт` Ethereum — это массив из 4 элементов: `[nonce, balance, storageRoot, codeHash]`. Здесь стоит отметить, что этот `storageRoot` является корнем другого дерева Патрисии: + +### Дерево хранилища {#storage-trie} + +В дереве хранилища находятся _все_ данные контракта. Для каждого аккаунта существует отдельное дерево хранилища. Для извлечения значений в определенных позициях хранилища по заданному адресу требуются адрес хранилища, целочисленная позиция хранимых данных в хранилище и ID блока. Затем они могут быть переданы в качестве аргументов в `eth_getStorageAt`, определенный в JSON-RPC API, например, для извлечения данных в слоте хранилища 0 для адреса `0x295a70b2de5e3953354a6a8344e616ed314d7251`: + +```bash +curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x0", "latest"], "id": 1}' localhost:8545 + +{"jsonrpc":"2.0","id":1,"result":"0x00000000000000000000000000000000000000000000000000000000000004d2"} + +``` + +Извлечение других элементов в хранилище немного сложнее, потому что сначала необходимо вычислить позицию в дереве хранилища. Позиция вычисляется как хэш `keccak256` от адреса и позиции в хранилище, причем оба значения дополняются нулями слева до длины 32 байта. Например, позиция для данных в слоте хранилища 1 для адреса `0x391694e7e0b0cce554cb130d723a9d27458f9298` такова: + +```python +keccak256(decodeHex("000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001")) +``` + +В консоли Geth это можно рассчитать следующим образом: + +``` +> var key = "000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001" +undefined +> web3.sha3(key, {"encoding": "hex"}) +"0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9" +``` + +`path` (путь) поэтому равен `keccak256(<6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9>)`. Теперь это можно использовать для извлечения данных из дерева хранилища, как и раньше: + +```bash +curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9", "latest"], "id": 1}' localhost:8545 + +{"jsonrpc":"2.0","id":1,"result":"0x000000000000000000000000000000000000000000000000000000000000162e"} +``` + +Примечание: `storageRoot` для аккаунта Ethereum по умолчанию пуст, если это не аккаунт контракта. + +### Дерево транзакций {#transaction-trie} + +Для каждого блока существует отдельное дерево транзакций, снова хранящее пары `(ключ, значение)`. Здесь путь — это `rlp(transactionIndex)`, который представляет ключ, соответствующий значению, определяемому следующим образом: + +```python +if legacyTx: + value = rlp(tx) +else: + value = TxType | encode(tx) +``` + +Более подробную информацию об этом можно найти в документации [EIP 2718](https://eips.ethereum.org/EIPS/eip-2718). + +### Дерево квитанций {#receipts-trie} + +У каждого блока есть свое дерево квитанций. Здесь `path` (путь) — это `rlp(transactionIndex)`. `transactionIndex` — это его индекс в блоке, в который он был включен. Дерево квитанций никогда не обновляется. Подобно дереву транзакций, существуют текущие и устаревшие квитанции. Для запроса конкретной квитанции в дереве квитанций требуются индекс транзакции в ее блоке, полезная нагрузка квитанции и тип транзакции. Возвращенная квитанция может быть типа `Receipt`, который определяется как конкатенация `TransactionType` и `ReceiptPayload`, или типа `LegacyReceipt`, который определяется как `rlp([status, cumulativeGasUsed, logsBloom, logs])`. + +Более подробную информацию об этом можно найти в документации [EIP 2718](https://eips.ethereum.org/EIPS/eip-2718). + +## Дополнительные материалы {#further-reading} + +- [Модифицированное дерево Меркла-Патрисии — как Ethereum сохраняет состояние](https://medium.com/codechain/modified-merkle-patricia-trie-how-ethereum-saves-a-state-e6d7555078dd) +- [Мерклизация в Ethereum](https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/) +- [Понимание дерева Ethereum](https://easythereentropy.wordpress.com/2014/06/04/understanding-the-ethereum-trie/) diff --git a/public/content/translations/ru/developers/docs/data-structures-and-encoding/rlp/index.md b/public/content/translations/ru/developers/docs/data-structures-and-encoding/rlp/index.md new file mode 100644 index 00000000000..12d730daa3c --- /dev/null +++ b/public/content/translations/ru/developers/docs/data-structures-and-encoding/rlp/index.md @@ -0,0 +1,163 @@ +--- +title: "Recursive-length prefix (RLP) кодирование" +description: "Описание кодирования RLP в слое выполнения Ethereum." +lang: ru +sidebarDepth: 2 +--- + +Сериализация с помощью рекурсивной длинны префикса (RLP) обширно используется в клиентах сети Ethereum. RLP стандартизирует передачу данных между узлами в пространственно эффективном формате. Цель RLP - кодировать произвольное количество вложенных массивов двоичных данных. RLP - это метод первичной кодировки, используемый для сериализации объектов в исполнительном слое Ethereum. Основное предназначение RLP — кодировать структуру; за исключением положительных целых чисел, RLP делегирует кодирование определенных типов данных (например, строк, чисел с плавающей запятой) протоколам более высокого порядка. Положительные целые числа должны быть представлены в двоичном виде с прямым порядком байтов без ведущих нулей (таким образом, целочисленное значение ноль эквивалентно пустому байтовому массиву). Десериализованные положительные целые числа с ведущими нулями должны рассматриваться как недействительные любым протоколом более высокого порядка, использующим RLP. + +Больше информации в [Желтой книге Ethereum (Приложение B)](https://ethereum.github.io/yellowpaper/paper.pdf#page=19). + +Для использования RLP при кодировании словаря предлагаются следующие две канонические формы: + +- используйте `[[k1,v1],[k2,v2]...]` с ключами в лексикографическом порядке +- использовать более высокоуровневую кодировку Patricia Tree как Ethereum + +## Определение {#definition} + +Функция кодирования RLP принимает один из элементов. Элемент определяется следующим образом： + +- строка (т. е. массив байтов) является элементом +- список элементов - элемент +- положительное целое число является элементом + +Например, все следующие пункты - элементы: + +- пустая строка; +- строка, содержащая слово "cat"; +- список, содержащий любое количество строк; +- и более сложные структуры данных, такие как `["cat", ["puppy", "cow"], "horse", [[]], "pig", [""], "sheep"]`. +- число `100` + +Обратите внимание, что в контексте остальной части этой страницы «строка» означает «определенное количество байтов двоичных данных»; никакие специальные кодировки не используются и никакие сведения о содержании строк не подразумеваются (за исключением случаев, когда это требуется правилом, запрещающим неминимальные положительные целые числа). + +Кодирование RLP определяется следующим образом: + +- Для положительного целого числа оно преобразуется в кратчайший байтовый массив, интерпретация которого с прямым порядком байтов (big-endian) является целым числом, а затем кодируется как строка в соответствии с приведенными ниже правилами. +- Для одного байта, значение которого находится в диапазоне `[0x00, 0x7f]` (десятичное `[0, 127]`), этот байт является своей собственной RLP-кодировкой. +- В противном случае, если строка имеет длину 0–55 байтов, кодировка RLP состоит из одного байта со значением **0x80** (десятичное 128) плюс длина строки, за которой следует сама строка. Таким образом, диапазон первого байта: `[0x80, 0xb7]` (десятичное `[128, 183]`). +- Если строка длиннее 55 байтов, кодировка RLP состоит из одного байта со значением **0xb7** (десятичное 183) плюс длина в байтах длины строки в двоичной форме, за которой следует длина строки, а затем сама строка. Например, строка длиной 1024 байта будет закодирована как `\xb9\x04\x00` (десятичное `185, 4, 0`), за которой следует сама строка. Здесь `0xb9` (183 + 2 = 185) — это первый байт, за которым следуют 2 байта `0x0400` (десятичное 1024), которые обозначают длину фактической строки. Таким образом, диапазон первого байта: `[0xb8, 0xbf]` (десятичное `[184, 191]`). +- Если строка имеет длину 2^64 байтов или больше, ее нельзя закодировать. +- Если общая полезная нагрузка списка (т. е. общая длина всех его RLP-кодированных элементов) составляет 0–55 байт, кодировка RLP состоит из одного байта со значением **0xc0** плюс длина полезной нагрузки, за которой следует конкатенация RLP-кодировок элементов. Таким образом, диапазон первого байта: `[0xc0, 0xf7]` (десятичное `[192, 247]`). +- Если общая полезная нагрузка списка превышает 55 байт, кодировка RLP состоит из одного байта со значением **0xf7** плюс длина в байтах длины полезной нагрузки в двоичной форме, за которой следует длина полезной нагрузки, а затем — конкатенация RLP-кодировок элементов. Таким образом, диапазон первого байта: `[0xf8, 0xff]` (десятичное `[248, 255]`). + +В коде это выражается как: + +```python +def rlp_encode(input): + if isinstance(input,str): + if len(input) == 1 and ord(input) < 0x80: + return input + return encode_length(len(input), 0x80) + input + elif isinstance(input, list): + output = '' + for item in input: + output += rlp_encode(item) + return encode_length(len(output), 0xc0) + output + +def encode_length(L, offset): + if L < 56: + return chr(L + offset) + elif L < 256**8: + BL = to_binary(L) + return chr(len(BL) + offset + 55) + BL + raise Exception("слишком длинные входные данные") + +def to_binary(x): + if x == 0: + return '' + return to_binary(int(x / 256)) + chr(x % 256) +``` + +## Примеры: {#examples} + +- строка "dog" = [ 0x83, 'd', 'o', 'g' ] +- список [ "cat", "dog" ] = `[ 0xc8, 0x83, 'c', 'a', 't', 0x83, 'd', 'o', 'g' ]` +- пустая строка ('null') = `[ 0x80 ]` +- пустой список = `[ 0xc0 ]` +- целое число 0 = `[ 0x80 ]` +- байт '\\x00' = `[ 0x00 ]` +- байт '\\x0f' = `[ 0x0f ]` +- байты '\\x04\\x00' = `[ 0x82, 0x04, 0x00 ]` +- [теоретико-множественное представление](http://en.wikipedia.org/wiki/Set-theoretic_definition_of_natural_numbers) числа три, `[ [], [[]], [ [], [[]] ] ] = [ 0xc7, 0xc0, 0xc1, 0xc0, 0xc3, 0xc0, 0xc1, 0xc0 ]` +- строка "Lorem ipsum dolor sit amet, consectetur adipisicing elit" = `[ 0xb8, 0x38, 'L', 'o', 'r', 'e', 'm', ' ', ...` , 'e', 'l', 'i', 't' ]` + +## Декодирование RLP {#rlp-decoding} + +В соответствии с правилами и процессами RLP кодирования, входными данными RLP декодирования является массив с бинарными данными. Процесс декодирования RLP следующий: + +1. в соответствии с первым байтом (т. е. префиксом) входных данных и декодирования типа данных, длины фактических данных и смещения; + +2. в соответствии с типом и смещением данных соответствующим образом декодируйте данные, соблюдая правило минимального кодирования для положительных целых чисел; + +3. продолжить декодирование остальных входных данных; + +Правила декодирования типов данных и смещения следующие: + +1. данные являются строкой, если диапазон первого байта (т. е. префикса) — [0x00, 0x7f], и строка — это в точности сам первый байт; + +2. данные являются строкой если значение первого байта (т.е. префикса) находится в промежутке [0x80, 0xb7] и последующей строкой, длина которой равно значению первого байта минус 0x80; + +3. данные являются строкой, если значение первого байта (т.е. префикса) находится в промежутке [0xb8, 0xbf] и длина строки чья длина в байтах равна значению первого байта минус 0xb7 после первого байта и последующая строка; + +4. данные являются списком, если значение первого байта находится в промежутке [0xc0, 0xf7], и конкатенация RLP кодирований всех элементов списка, следующего за первым байтом, равна значению первого байта минус 0xc0; + +5. данные являются списком, если диапазон первого байта — [0xf8, 0xff], и общая полезная нагрузка списка, длина которого равна значению первого байта минус 0xf7, следует за первым байтом, и конкатенация RLP-кодировок всех элементов списка следует за общей полезной нагрузкой списка; + +В коде это выражается как: + +```python +def rlp_decode(input): + if len(input) == 0: + return + output = '' + (offset, dataLen, type) = decode_length(input) + if type is str: + output = instantiate_str(substr(input, offset, dataLen)) + elif type is list: + output = instantiate_list(substr(input, offset, dataLen)) + output += rlp_decode(substr(input, offset + dataLen)) + return output + +def decode_length(input): + length = len(input) + if length == 0: + raise Exception("входные данные — null") + prefix = ord(input[0]) + if prefix <= 0x7f: + return (0, 1, str) + elif prefix <= 0xb7 and length > prefix - 0x80: + strLen = prefix - 0x80 + return (1, strLen, str) + elif prefix <= 0xbf and length > prefix - 0xb7 and length > prefix - 0xb7 + to_integer(substr(input, 1, prefix - 0xb7)): + lenOfStrLen = prefix - 0xb7 + strLen = to_integer(substr(input, 1, lenOfStrLen)) + return (1 + lenOfStrLen, strLen, str) + elif prefix <= 0xf7 and length > prefix - 0xc0: + listLen = prefix - 0xc0; + return (1, listLen, list) + elif prefix <= 0xff and length > prefix - 0xf7 and length > prefix - 0xf7 + to_integer(substr(input, 1, prefix - 0xf7)): + lenOfListLen = prefix - 0xf7 + listLen = to_integer(substr(input, 1, lenOfListLen)) + return (1 + lenOfListLen, listLen, list) + raise Exception("входные данные не соответствуют формату кодировки RLP") + +def to_integer(b): + length = len(b) + if length == 0: + raise Exception("входные данные — null") + elif length == 1: + return ord(b[0]) + return ord(substr(b, -1)) + to_integer(substr(b, 0, -1)) * 256 +``` + +## Дополнительные материалы {#further-reading} + +- [RLP в Ethereum](https://medium.com/coinmonks/data-structure-in-ethereum-episode-1-recursive-length-prefix-rlp-encoding-decoding-d1016832f919) +- [Ethereum изнутри: RLP](https://medium.com/coinmonks/ethereum-under-the-hood-part-3-rlp-decoding-df236dc13e58) +- [Coglio, A. (2020). Ethereum's Recursive Length Prefix in ACL2. arXiv preprint arXiv:2009.13769.](https://arxiv.org/abs/2009.13769) + +## Смежные темы {#related-topics} + +- [Дерево Меркла — Патриции](/developers/docs/data-structures-and-encoding/patricia-merkle-trie) diff --git a/public/content/translations/ru/developers/docs/data-structures-and-encoding/ssz/index.md b/public/content/translations/ru/developers/docs/data-structures-and-encoding/ssz/index.md new file mode 100644 index 00000000000..bec07335190 --- /dev/null +++ b/public/content/translations/ru/developers/docs/data-structures-and-encoding/ssz/index.md @@ -0,0 +1,150 @@ +--- +title: "Простая сериализация" +description: "Объяснение формата SSZ в Ethereum." +lang: ru +sidebarDepth: 2 +--- + +**Простая сериализация (SSZ)** — это метод сериализации, используемый в сети Beacon. Она заменяет сериализацию RLP, используемую на уровне исполнения, везде на уровне консенсуса, за исключением протокола обнаружения пиров. Чтобы узнать больше о сериализации RLP, см. [Префикс рекурсивной длины (RLP)](/developers/docs/data-structures-and-encoding/rlp/). SSZ разработан, чтобы быть детерминированным, а также эффективно мерклизировать данные. SSZ можно рассматривать как состоящий из двух компонентов: схемы сериализации и схемы мерклизации, которая предназначена для эффективной работы с сериализованной структурой данных. + +## Как работает SSZ? {#how-does-ssz-work} + +### Сериализация {#serialization} + +SSZ — это схема сериализации, которая не является самоописываемой, а полагается на схему, которая должна быть известна заранее. Цель сериализации SSZ — представить объекты произвольной сложности в виде строк байтов. Для "базовых типов" это очень простой процесс. Элемент просто преобразуется в шестнадцатеричные байты. К базовым типам относятся: + +- целые числа без знака +- логические значения + +Для сложных "составных" типов сериализация сложнее, поскольку составной тип содержит несколько элементов, которые могут иметь разные типы, разные размеры или и то, и другое. Если все эти объекты имеют фиксированную длину (т. е. размер элементов всегда будет постоянным независимо от их фактических значений), сериализация — это просто преобразование каждого элемента составного типа, упорядоченного в байтовые строки little-endian. Эти байтовые строки соединяются вместе. Сериализованный объект имеет представление в виде списка байтов элементов фиксированной длины в том же порядке, в котором они появляются в десериализованном объекте. + +Для типов с переменной длиной фактические данные заменяются значением "смещения" в позиции этого элемента в сериализованном объекте. Фактические данные добавляются в «кучу» (heap) в конце сериализованного объекта. Значение смещения — это индекс начала фактических данных в куче, действующий как указатель на соответствующие байты. + +Приведенный ниже пример иллюстрирует, как работает смещение для контейнера с элементами как фиксированной, так и переменной длины: + +```Rust + + struct Dummy { + + number1: u64, + number2: u64, + vector: Vec, + number3: u64 + } + + dummy = Dummy{ + + number1: 37, + number2: 55, + vector: vec![1,2,3,4], + number3: 22, + } + + serialized = ssz.serialize(dummy) + +``` + +`serialized` будет иметь следующую структуру (здесь дополнено до 4 бит, в реальности дополняется до 32 бит, а для ясности сохранено представление `int`): + +``` +[37, 0, 0, 0, 55, 0, 0, 0, 16, 0, 0, 0, 22, 0, 0, 0, 1, 2, 3, 4] +------------ ----------- ----------- ----------- ---------- + | | | | | + число1 число2 смещение для число3 значение для + вектора вектора + +``` + +для ясности разделено по строкам: + +``` +[ + 37, 0, 0, 0, # кодирование `number1` в формате little-endian. + 55, 0, 0, 0, # кодирование `number2` в формате little-endian. + 16, 0, 0, 0, # "Смещение", которое указывает, где начинается значение `vector` (16 в формате little-endian). + 22, 0, 0, 0, # кодирование `number3` в формате little-endian. + 1, 2, 3, 4, # Фактические значения в `vector`. +] +``` + +Это все еще упрощение: целые числа и нули в приведенных выше схемах на самом деле будут храниться в виде списков байтов, вот так: + +``` +[ + 10100101000000000000000000000000 # кодирование `number1` в формате little-endian + 10110111000000000000000000000000 # кодирование `number2` в формате little-endian. + 10010000000000000000000000000000 # "Смещение", которое указывает, где начинается значение `vector` (16 в формате little-endian). + 10010110000000000000000000000000 # кодирование `number3` в формате little-endian. + 10000001100000101000001110000100 # Фактическое значение поля `bytes`. +] +``` + +Таким образом, фактические значения для типов переменной длины хранятся в куче в конце сериализованного объекта, а их смещения хранятся на своих правильных позициях в упорядоченном списке полей. + +Существуют также некоторые особые случаи, требующие специальной обработки, например, тип `BitList`, который требует добавления ограничения длины во время сериализации и удаления во время десериализации. Полная информация доступна в [спецификации SSZ](https://github.com/ethereum/consensus-specs/blob/dev/ssz/simple-serialize.md). + +### Десериализация {#deserialization} + +Для десериализации этого объекта требуется схема. Схема определяет точную компоновку сериализованных данных, так что каждый конкретный элемент может быть десериализован из большого двоичного объекта (blob) байтов в некий осмысленный объект с элементами, имеющими правильный тип, значение, размер и положение. Именно схема сообщает десериализатору, какие значения являются фактическими, а какие — смещениями. Все имена полей исчезают при сериализации объекта, но восстанавливаются при десериализации в соответствии со схемой. + +Смотрите [ssz.dev](https://www.ssz.dev/overview) для интерактивного объяснения этого. + +## Мерклизация {#merkleization} + +Затем этот сериализованный объект SSZ может быть мерклизирован, то есть преобразован в представление тех же данных в виде дерева Меркла. Сначала определяется количество 32-байтовых фрагментов в сериализованном объекте. Это "листья" дерева. Общее количество листьев должно быть степенью двойки, чтобы хеширование листьев в конечном итоге дало один корневой хэш дерева. Если это не так, добавляются дополнительные листья, содержащие 32 байта нулей. Схематично: + +``` + корневой хэш дерева + / \ + / \ + / \ + / \ + хэш листьев хэш листьев + 1 и 2 3 и 4 + / \ / \ + / \ / \ + / \ / \ + лист1 лист2 лист3 лист4 +``` + +Также бывают случаи, когда листья дерева естественным образом распределяются не так равномерно, как в примере выше. Например, лист 4 может быть контейнером с несколькими элементами, которые требуют добавления дополнительной "глубины" в дерево Меркла, создавая неровное дерево. + +Вместо того, чтобы называть эти элементы дерева «лист X», «узел X» и т. д., мы можем дать им обобщенные индексы, начиная с корня = 1 и считая слева направо на каждом уровне. Это обобщенный индекс, объясненный выше. Каждый элемент в сериализованном списке имеет обобщенный индекс, равный `2**depth + idx`, где idx — это его позиция с нулевым индексом в сериализованном объекте, а глубина — это количество уровней в дереве Меркла, которое можно определить как двоичный логарифм количества элементов (листьев). + +## Обобщенные индексы {#generalized-indices} + +Обобщенный индекс — это целое число, которое представляет узел в двоичном дереве Меркла, где каждый узел имеет обобщенный индекс `2 ** depth + index in row`. + +``` + 1 --глубина = 0 2**0 + 0 = 1 + 2 3 --глубина = 1 2**1 + 0 = 2, 2**1+1 = 3 + 4 5 6 7 --глубина = 2 2**2 + 0 = 4, 2**2 + 1 = 5... + +``` + +Это представление дает индекс узла для каждого фрагмента данных в дереве Меркла. + +## Мультидоказательства {#multiproofs} + +Предоставление списка обобщенных индексов, представляющих конкретный элемент, позволяет нам проверить его по корневому хэшу дерева. Этот корень является нашей принятой версией реальности. Любые предоставленные нам данные могут быть проверены на соответствие этой реальности путем вставки их в нужное место в дереве Меркла (определяемое его обобщенным индексом) и наблюдения за тем, что корень остается постоянным. В спецификации [здесь](https://github.com/ethereum/consensus-specs/blob/dev/ssz/merkle-proofs.md#merkle-multiproofs) есть функции, которые показывают, как вычислить минимальный набор узлов, необходимый для проверки содержимого определенного набора обобщенных индексов. + +Например, чтобы проверить данные в индексе 9 в дереве ниже, нам нужен хэш данных в индексах 8, 9, 5, 3, 1. +Хэш (8,9) должен быть равен хэшу (4), который хешируется с 5 для получения 2, который хешируется с 3 для получения корня дерева 1. Если для 9 были предоставлены неверные данные, корень изменится — мы обнаружим это, и проверка ветви не удастся. + +``` +* = данные, необходимые для генерации доказательства + + 1* + 2 3* + 4 5* 6 7 +8* 9* 10 11 12 13 14 15 + +``` + +## Дополнительные материалы {#further-reading} + +- [Обновление Ethereum: SSZ](https://eth2book.info/altair/part2/building_blocks/ssz) +- [Обновление Ethereum: мерклизация](https://eth2book.info/altair/part2/building_blocks/merkleization) +- [Реализации SSZ](https://github.com/ethereum/consensus-specs/issues/2138) +- [Калькулятор SSZ](https://simpleserialize.com/) +- [SSZ.dev](https://www.ssz.dev/)