diff --git a/docusaurus.config.js b/docusaurus.config.js index 3dc6380445..91663bc475 100644 --- a/docusaurus.config.js +++ b/docusaurus.config.js @@ -39,7 +39,10 @@ const config = { }), ], ], - + i18n: { + defaultLocale: 'en', + locales: ['en', 'ru'], + }, themeConfig: /** @type {import('@docusaurus/preset-classic').ThemeConfig} */ ({ @@ -72,6 +75,9 @@ const config = { type: 'docsVersionDropdown', position: 'right' }, + { + type: 'localeDropdown', + }, ], }, footer: { diff --git a/i18n/ru/docusaurus-plugin-content-docs/current/dv/01_introducing-charon.md b/i18n/ru/docusaurus-plugin-content-docs/current/dv/01_introducing-charon.md new file mode 100644 index 0000000000..6d40906743 --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/current/dv/01_introducing-charon.md @@ -0,0 +1,28 @@ +--- +description: Charon — клиент распределенного валидатора +--- + +# Представляем Charon + +В этом разделе представлено промежуточное ПО Charon. Дополнительный контекст, касающийся технологии распределенного валидатора, см. в [этом разделе](../int/key-concepts#distributed-validator) на странице ключевых концепций. + +### Что такое Charon? + +Charon — это промежуточное программное обеспечение HTTP на основе GoLang, созданное Obol для того, чтобы любые существующие клиенты валидатора Ethereum могли работать вместе как часть распределенного валидатора. + +Charon является промежуточным программным обеспечением между обычным проверяющим клиентом и подключенным к нему узлом-маяком, перехватывая и проксируя трафик API. Несколько клиентов Charon настроены на совместное общение, чтобы прийти к консенсусу в отношении обязанностей валидатора и вести себя как единый унифицированный валидатор Proof-of-Stake. Узлы образуют кластер, который является _устойчивым к byzantine-fault_ и продолжает развиваться при условии, что встречается подавляющее большинство рабочих/честных узлов. + +### Архитектура Charon +На приведенном ниже рисунке визуально показаны внутренние функции Charon. + +![Слайд внутренних компонентов Charon](/img/CharonInternals.png) + +### Как начать + +Клиент `charon` находится в ранней альфа-версии и не готов к основной сети, см. [здесь](https://github.com/ObolNetwork/charon#supported-consensus-layer-clients) последнюю информацию о готовности charon. + +``` +docker run ghcr.io/obolnetwork/charon:v0.8.1 --help +``` + +Для получения дополнительной информации о запуске charon обратитесь к нашему [краткому руководству](../int/quickstart/index.md). \ No newline at end of file diff --git a/i18n/ru/docusaurus-plugin-content-docs/current/dv/02_validator-creation.md b/i18n/ru/docusaurus-plugin-content-docs/current/dv/02_validator-creation.md new file mode 100644 index 0000000000..b8d7de0805 --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/current/dv/02_validator-creation.md @@ -0,0 +1,31 @@ +--- +description: Создание кластера Distributed Validator с нуля +--- + +# Создание распределенного валидатора + +![Пример кластера Distributed Validator](/img/ObolCluster.png) + +### Этапы создания распределенного валидатора + +Чтобы создать распределенный кластер валидаторов, вам и вашей группе операторов необходимо выполнить следующие шаги: + +1. Один оператор начинает установку кластера [Distributed Validator Launchpad](../dvk/02_distributed_validator_launchpad.md). + - Это включает в себя настройку всех условий для кластера, в том числе; адрес вывода средств, получатель комиссии, количество валидаторов, адреса операторов и т. д. Эта информация известна как *конфигурация кластера*. + - Этот оператор также устанавливает запись узла Ethereum своего клиента charon. ([ENR](../int/faq.md#what-is-an-enr)). + - Этот оператор подписывает как хэш конфигурации кластера, так и ENR, чтобы подтвердить право собственности на свой адрес. + - Эти данные хранятся на уровне данных DV Launchpad, и создается общий URL-адрес. Это ссылка для других операторов, чтобы присоединиться и завершить церемонию. +2. Другие операторы в кластере следуют этому URL-адресу на панель запуска. + - Они рассматривают условия конфигурации кластера. + - Они представляют ENR своего клиента charon. + - Они подписывают как хэш конфигурации кластера, так и свой charon ENR, чтобы принять условия. +3. После того как все операторы представили подписи для конфигурации кластера и ENR, все они могут загрузить файл определения кластера. +4. Каждый оператор передает этот файл определения кластера команде `charon dkg`. Определение предоставляет процессу charon информацию, необходимую для поиска и завершения церемонии DKG с другими вовлеченными клиентами charon. +5. Как только все клиенты charon смогут общаться друг с другом, процесс DKG завершается. Все операторы в итоге имеют: + - Файл `cluster-lock.json`, который содержит исходные данные конфигурации кластера в сочетании с недавно сгенерированными открытыми ключами группы и связанными с ними общими общими ключами. Этот файл необходим команде `charon run`. + - Данные депозита валидатора + - Приватный ключ валидатора +6. Теперь операторы могут создавать резервные копии сгенерированных общих ключей, своего закрытого ключа ENR, если они еще этого не сделали, и файла `cluster-lock.json`. +7. Все операторы загружают ключи и файлы блокировки кластера, сгенерированные на церемонии, в свое окружение. +8. Операторы могут запустить тест производительности настроенного кластера, чтобы убедиться, что связь между всеми операторами наблюдается с разумной задержкой. +9. После того, как все тесты на готовность пройдены, один оператор активирует распределенный валидатор(ы) с депозитом в цепочке. diff --git a/i18n/ru/docusaurus-plugin-content-docs/current/dv/04_middleware-daemon.md b/i18n/ru/docusaurus-plugin-content-docs/current/dv/04_middleware-daemon.md new file mode 100644 index 0000000000..b3fff9cd4e --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/current/dv/04_middleware-daemon.md @@ -0,0 +1,15 @@ +--- +description: Архитектура развертывания для клиента распределенного валидатора +--- + +# Архитектура промежуточного программного обеспечения + +

+ +Демон Charon является промежуточным программным обеспечением между [API узла маяка](https://ethereum.github.io/beacon-APIs/) уровня консенсуса и любыми нижестоящими клиентами валидатора. + +### Цель + +Промежуточное программное обеспечение стремится быть без состояния (stateless) и статически настроенным через файловые системы 777. Отсутствие API-интерфейса уровня управления для онлайн-реконфигурации преднамеренно сделано для того, чтобы по умолчанию операции были простыми и безопасными. + +Первоначально пакет `charon` будет доступен в виде образа Docker и в виде бинарных сборок. Планируется пакет APT с интеграцией systemd. diff --git a/i18n/ru/docusaurus-plugin-content-docs/current/dv/06_peer-discovery.md b/i18n/ru/docusaurus-plugin-content-docs/current/dv/06_peer-discovery.md new file mode 100644 index 0000000000..b9f8acd99c --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/current/dv/06_peer-discovery.md @@ -0,0 +1,37 @@ +--- +description: Как распределенные клиенты валидатора безопасно взаимодействуют друг с другом? +--- + +# Взаимодействие клиентов валидатора + +Чтобы поддерживать безопасность и устойчивость к sybil (sybil-resistance), клиенты charon должны иметь возможность аутентифицировать друг друга. Мы достигаем этого, предоставляя каждому клиенту charon пару открытого/закрытого ключа, которую они могут подписывать таким образом, чтобы другие клиенты в кластере могли распознавать их как законных, независимо от того, с какого IP-адреса они общаются. + +В конце [церемонии DKG](./02_validator-creation.md#stages-of-creating-a-distributed-validator) каждый оператор будет иметь количество файлов, полученных их клиентом charon, в зависимости от того, сколько распределенных валидаторов группа решила генерировать вместе. + +О файлах: + +- **Validator keystore(s):** Эти файлы будут загружены в клиент валидатора оператора, и каждый файл представляет одну долю распределенного валидатора. +- **A distributed validator cluster lock file:** Этот файл `cluster-lock.json` содержит конфигурацию, необходимую клиенту распределенного валидатора, такому как charon, для присоединения к кластеру, способному работать с несколькими распределенными валидаторами. +- **Validator deposit data:** Этот файл используется для активации одного или нескольких распределенных валидаторов в сети Ethereum. + +### Аутентификация клиента распределенного валидатора + +Прежде чем начнется процесс DKG, все операторы должны запустить «charon create enr» или просто «charon enr», чтобы создать или получить запись узла Ethereum для своего клиента. Эти ENR включены в конфигурацию церемонии генерации распределенного ключа. + +Файл, описывающий церемонию DKG, известен как файл [`cluster-definition`](./08_distributed-validator-cluster-manifest.md). Этот файл передается `charon dkg`, который использует его для создания закрытых ключей, файла блокировки кластера и хранения данных для настроенного количества распределенных валидаторов. Файл блокировки кластера будет доступен для `charon run`, а хранилища ключей валидатора будут доступны настроенному клиенту валидатора. + +Когда `charon run` запускается и получает свою конфигурацию из файла `cluster-lock.json`, он проверяет, отличается ли наблюдаемый/настроенный общедоступный IP-адрес от того, что указано в файле блокировки. Если он другой; он обновляет IP-адрес, увеличивает одноразовый номер ENR и повторно выдает его, прежде чем начать устанавливать соединения с другими операторами в кластере. + +#### База данных узла + +Распределенные кластеры валидаторов — это разрешенные сети с полносвязной топологией. Каждый узел будет постоянно хранить ENR всех других известных узлов Obol в своей базе данных узлов. + +В отличие от баз данных узлов общедоступных сетей без разрешения (таких как [Go-Ethereum](https://pkg.go.dev/github.com/ethereum/go-ethereum@v1.10.13/p2p/enode#DB)), здесь нет встроенной логики вытеснения — база данных будет расти бесконечно. Это приемлемо, поскольку ожидается, что количество операторов в кластере останется постоянным. Изменяемые кластерные операторы будут введены в будущем. + +#### Поиск узла + +При загрузке клиент charon загрузит настроенный файл `cluster-lock.json`. Этот файл содержит список ENR пиров клиента. Клиент попытается установить соединение с этими одноранговыми узлами и выполнит рукопожатие, если они подключатся, чтобы установить сквозной зашифрованный канал связи между клиентами. + +Однако IP-адреса в ENR могут устареть. Это может привести к тому, что кластер не сможет установить соединение со всеми узлами. Чтобы быть терпимым к изменению IP-адресов операторов, charon также поддерживает протокол обнаружения [discv5](https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md). Это позволяет клиенту charon найти другого оператора, который мог изменить IP-адрес, но при этом сохранил тот же закрытый ключ ENR. + + diff --git a/i18n/ru/docusaurus-plugin-content-docs/current/dv/07_p2p-interface.md b/i18n/ru/docusaurus-plugin-content-docs/current/dv/07_p2p-interface.md new file mode 100644 index 0000000000..1fff526bff --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/current/dv/07_p2p-interface.md @@ -0,0 +1,13 @@ +--- +description: Связь между экземплярами Charon +--- + +# P2P интерфейс + +P2P-интерфейс Charon примерно соответствует [Eth2 beacon P2P interface](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md). + +- Метод общения: TCP over IPv4/IPv6. +- Идентификация: [Ethereum Node Records](https://eips.ethereum.org/EIPS/eip-778). +- Рукопожатие: [noise-libp2p](https://github.com/libp2p/specs/tree/master/noise) с `secp256k1` ключами. + - Каждый клиент charon должен иметь открытый ключ ENR, авторизованный в [cluster-lock.json](./08_distributed-validator-cluster-manifest.md) файл, чтобы рукопожатие клиента прошло успешно. +- Протокол обнаружения: [Discv5](https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md). diff --git a/i18n/ru/docusaurus-plugin-content-docs/current/dv/08_distributed-validator-cluster-manifest.md b/i18n/ru/docusaurus-plugin-content-docs/current/dv/08_distributed-validator-cluster-manifest.md new file mode 100644 index 0000000000..f18010e88b --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/current/dv/08_distributed-validator-cluster-manifest.md @@ -0,0 +1,66 @@ +--- +description: Документирование распределенного кластера валидатора в стандартизированном формате файла +--- + +# Конфигурация кластера + +:::caution +Эти файлы определения кластера и блокировки кластера находятся в стадии разработки. Цель состоит в том, чтобы файлы были стандартизированы для работы распределенных валидаторов через [процесс EIP](https://eips.ethereum.org/), когда это необходимо.. +::: + +В этом документе описываются параметры конфигурации для запуска клиента charon (или кластера) локально или в рабочей среде. + +## Файлы конфигурации кластера + +Кластер charon настраивается в два этапа: +- `cluster-definition.json` который определяет предполагаемую конфигурацию кластера до того, как ключи будут созданы на церемонии распределенного генерирования ключей. +- `cluster-lock.json` который включает в себя и расширяет `cluster-definition.json` с распределенными общими ключами BLS валидатора. + +Команда `charon create dkg` используется для создания файла `cluster-definition.json`, который используется в качестве входных данных для «charon dkg». + +Команда `charon create cluster` объединяет оба шага в один и просто выводит окончательный файл `cluster-lock.json` без шага DKG. + +Схема `cluster-definition.json` определяется как: +```json +{ + "name": "best cluster", // Опционально, косметический идентификатор + "operators": [ + { + "address": "0x123..abfc", // ETH1 адрес оператора + "enr": "enr://abcdef...12345", // ENR Charon узла + "nonce": 1, // Nonce (увеличивается каждый раз, когда ENR добавляется/подписывается) + "config_signature": "123456...abcdef", // EIP712 Подпись config_hash по приватному ключу адреса ETH1 + "enr_signature": "123654...abcedf" // EIP712 Подпись ENR по приватному ключу адреса ETH1 + } + ], + "uuid": "1234-abcdef-1234-abcdef", // Случайный уникальный идентификатор. + "version": "v1.0.0", // Версия схемы + "num_validators": 100, // Количество распределенных валидаторов кластера, которые будут созданы в cluster.lock + "threshold": 3, // Опционально, порог необходимый для восстановления подписи + "fee_recipient_address":"0x123..abfc", // ETH1 адрес получателя вознаграждения + "withdrawal_address": "0x123..abfc", // ETH1 адрес вывода + "dkg_algorithm": "foo_dkg_v1" , // Опционально, алгоритм DKG для генерации ключей + "fork_version": "0x00112233", // Идентификатор цепи/сети + "config_hash": "abcfde...acbfed", // Хэш статических (неизменяемых) полей + "definition_hash": "abcdef...abcedef" // Окончательный хэш всех полей +} +``` + +Приведенный выше файл `cluster-definition.json` предоставляется в качестве входных данных для DKG, который генерирует ключи и файл `cluster-lock.json`. + + +Файл `cluster-lock.json` имеет схему: +```json +{ + "cluster_definition": {...}, // Определение кластера json, схема идентична приведенной выше., + "distributed_validators": [ // Длина равная num_validators. + { + "distributed_public_key": "0x123..abfc", // Корневой открытый ключ DV + "public_shares": [ "oA8Z...2XyT", "g1q...icu"], // Совместно используемые открытые ключи + "fee_recipient": "0x123..abfc" // Адрес по умолчанию для вывода средств, если он не установлен, может быть отредактирован вручную + } + ], + "lock_hash": "abcdef...abcedef", // Config_hash + distributed_validators + "signature_aggregate": "abcdef...abcedef" // Совокупная подпись BLS хэша блокировки, подписанного каждым открытым ключом DV. +} +``` diff --git a/i18n/ru/docusaurus-plugin-content-docs/current/dv/09_charon_cli_reference.md b/i18n/ru/docusaurus-plugin-content-docs/current/dv/09_charon_cli_reference.md new file mode 100644 index 0000000000..8794e552d6 --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/current/dv/09_charon_cli_reference.md @@ -0,0 +1,201 @@ +--- +description: Клиент промежуточного программного обеспечения на основе go для участия в кластерах Distributed Validator. +--- + +# CLI интерфейс Charon + +:::caution + +Клиент `charon` находится в стадии интенсивной разработки, интерфейсы могут быть изменены, пока не будет опубликована первая основная версия. + +::: + +Ниже приведена ссылка на версию charon [`v0.8.1`](https://github.com/ObolNetwork/charon/releases/tag/v0.8.1). Найдите последнюю версию в [нашем Github](https://github.com/ObolNetwork/charon/releases). + +### Доступные команды + +Ниже приведены команды верхнего уровня, доступные для использования. + +```markdown +charon help +Charon обеспечивает отказоустойчивую работу валидаторов Ethereum, разделяя ключи проверки на группу доверенных сторон с использованием пороговой криптографии. + +Usage: + charon [command] + +Available Commands: + bootnode Запуск загрузочного сервера diskv5 + completion Сгенерировать скрипт автозаполнения для указанной оболочки + create Создание артефактов для кластера распределенного валидатора + dkg Принять участие в церемонии генерации распределенного ключа + enr Вывести запись узла Ethereum этого клиента (ENR) + help Справка по любой команде + run Запуск промежуточного клиента программного обеспечения charon + version Вывести версию клиента + +Flags: + -h, --help Справка по командам Charon + +Используйте "charon [command] --help" для получения дополнительной информации о команде. +``` + +### Вспомогательная команда `create` + +Вспомогательная команда `create` управляет созданием артефактов, необходимых charon для работы. + +```markdown +charon create --help +Создайте артефакты для кластера распределенного валидатора. Эти команды можно использовать для облегчения создания распределенного кластера валидатора между группой операторов путем выполнения церемонии генерации распределенного ключа, или их можно использовать для создания локального кластера для случаев использования одного оператора. + +Usage: + charon create [command] + +Available Commands: + cluster Создать закрытые ключи и файлы конфигурации, необходимые для локального запуска кластера распределенного валидатора + dkg Создать конфигурацию для новой церемонии генерации распределенного ключа, используя charon dkg + enr Создать закрытый ключ Ethereum Node Record (ENR), чтобы идентифицировать этого клиента charon. + +Flags: + -h, --help Дополнительная информация о команде + +Используйте `charon create [command] --help` для получения дополнительной информации о команде. + +``` + +#### Создание ENR в charon + +`enr` — это запись узла Ethereum. Он используется для идентификации этого клиента charon для других клиентов-контрагентов charon через Интернет. + +```markdown +charon create enr --help +Создать закрытый ключ Ethereum Node Record (ENR) для идентификации этого клиента charon + +Usage: + charon create enr [flags] + +Flags: + --data-dir string Каталог, в котором charon будет хранить все свои внутренние данные (default ".charon") + -h, --help Дополнительная информация о команде enr + --p2p-allowlist string Разделенный запятыми список подсетей CIDR для разрешения только определенных одноранговых соединений. Пример: 192.168.0.0/16 разрешает подключения к одноранговым узлам только в вашей локальной сети. По умолчанию принимаются все соединения. + --p2p-bootnode-relay Позволяет использовать загрузочные узлы в качестве реле цепи libp2p. Полезно, если некоторые узлы charon недоступны публично. + --p2p-bootnodes strings Разделенный запятыми список URL-адресов или ENR загрузочных узлов diskv5. (по умолчанию [http://bootnode.gcp.obol.tech:3640/enr]) + --p2p-bootnodes-from-lockfile Позволяет использовать ENR блокировки кластера в качестве загрузочных узлов diskv5. Позволяет пропускать явные загрузочные узлы, если церемония генерации ключей включала правильные IP-адреса. + --p2p-denylist string Разделенный запятыми список подсетей CIDR для запрета определенных одноранговых соединений. Пример: 192.168.0.0/16 запретит соединения с одноранговыми узлами в вашей локальной сети. По умолчанию принимаются все соединения. + --p2p-external-hostname string DNS-имя хоста, объявленное libp2p. Может использоваться для объявления внешнего DNS. + --p2p-external-ip string IP-адрес, объявленный libp2p. Может использоваться для внешнего IP-адреса. + --p2p-tcp-address strings Разделенный запятыми список прослушиваемых TCP-адресов (ip и порт) для трафика libP2P. (по умолчанию [127.0.0.1:3610]) + --p2p-udp-address string Прослушивание UDP-адреса (ip и порт) для обнаружения diskv5. (по умолчанию "127.0.0.1:3630") +``` + +#### Создание полный кластер локально + +`charon create cluster` локально создает набор распределенных валидаторов, включая закрытые ключи, файл `cluster.lock`, а также данные депозита и выхода. Однако эту команду следует использовать только для одиночного использования распределенных валидаторов. Для запуска распределенного валидатора с группой операторов предпочтительно создавать эти артефакты с помощью команды charon dkg. Таким образом, ни один оператор не хранит все закрытые ключи в распределенном валидаторе. + +```markdown +charon create cluster --help +Создает локальную конфигурацию кластера charon, включая ключи валидатора, p2p-ключи charon, cluster-lock.json и Deposit-data.json. Смотрите флаги для поддерживаемых функций. + +Usage: + charon create cluster [flags] + +Flags: + --clean Удалить каталог кластера перед его созданием. + --cluster-dir string Целевая папка для создания кластера (по умолчанию ".charon/cluster") + -h, --help Дополнитальная информация о команде + --network string Сеть Ethereum для создания валидаторов. Варинты: mainnet, prater, kintsugi, kiln, gnosis. (default: "prater") + -n, --nodes int Количество узлов charon в кластере. (default 4) + --split-existing-keys Разделить существующий закрытый ключ валидатора на набор распределенных общих ключей валидатора. Не создает повторно данные депозита для этого ключа. + --split-keys-dir string Каталог, содержащий ключи для разделения. Ожидает ключи в keystore-*.json and passwords in keystore-*.txt. Требует --split-existing-keys. + -t, --threshold int Порог, необходимый для восстановления подписи. Минимум это n-(ceil(n/3)-1). (default 3) + --withdrawal-address string Адрес Ethereum для получения возвращенной ставки и начисленных вознаграждений. (default "0x0000000000000000000000000000000000000000") +``` + +#### Создание конфигурации для DKG Ceremony + +Эта команда `charon create dkg` создает файл cluster_definition, используемый для команды `charon dkg`. + +```markdown +charon create dkg --help +Создайте файл определения кластера, который будет использоваться всеми участниками DKG. + +Usage: + charon create dkg [flags] + +Flags: + --dkg-algorithm string Используемый алгоритм DKG; default, keycast, frost (default "default") + --fee-recipient-address string Необязательный адрес Ethereum получателя комиссии + -h, --help Дополнитальная информация о команде + --name string Необязательное имя косметического кластера + --network string Сеть Ethereum для создания валидаторов. Options: mainnet, prater, kintsugi, kiln, gnosis. (default "prater") + --num-validators int Количество распределенных валидаторов, которыми будет управлять кластер (по 32ETH на каждого). (по умолчанию 1) + --operator-enrs strings Разделенный запятыми список адресов Charon ENR каждого оператора + --output-dir string Папка, в которую будет записан выходной файл cluster-definition.json. (по умолчанию ".charon") + -t, --threshold int Порог, необходимый для восстановления подписи. Минимум n-(ceil(n/3)-1). (по умолчанию 3) + --withdrawal-address string Адрес для вывода Ethereum (default "0x0000000000000000000000000000000000000000") +``` + +### Проведение церемонии DKG + +Команда `charon dkg` использует файл `cluster_definition.json`, который указывает charon условия создания нового кластера распределенного валидатора. Charon устанавливает связь с другими узлами, указанными в файле, выполняет церемонию генерации распределенного ключа для создания необходимых пороговых закрытых ключей и подписывает данные депозита и выхода для каждого нового распределенного валидатора. Команда выводит файл `cluster.lock` и общий ключ для каждого созданного распределенного валидатора. + +```markdown +charon dkg --help +Примите участие в церемонии создания распределенного ключа для определенного определения кластера, в ходе которой создаются распределенные общие ключи валидатора и окончательная конфигурация блокировки кластера. Обратите внимание, что все остальные операторы кластера должны запускать эту команду одновременно. + +Usage: + charon dkg [flags] + +Flags: + --data-dir string Каталог, в котором charon будет хранить все свои внутренние данные (по умолчанию ".charon") + --definition-file string Путь к файлу определения кластера. (по умолчанию ".charon/cluster-definition.json") + -h, --help Дополнительная информация о dgk + --log-format string Формат журнала; console, logfmt или json (по умолчанию "console") + --log-level string Уровень журнала; debug, info, warn or error (по умолчанию "info") + --p2p-allowlist string Разделенный запятыми список подсетей CIDR для разрешения только определенных одноранговых соединений. Пример: 192.168.0.0/16 разрешает подключения к одноранговым узлам только в вашей локальной сети. По умолчанию принимаются все соединения. + --p2p-bootnode-relay Позволяет использовать загрузочные узлы в качестве реле цепи libp2p. Полезно, если некоторые узлы харона недоступны публично. + --p2p-bootnodes strings Разделенный запятыми список URL-адресов или ENR загрузочных узлов diskv5. (по умолчанию [http://bootnode.gcp.obol.tech:3640/enr]) + --p2p-bootnodes-from-lockfile Позволяет использовать ENR блокировки кластера в качестве загрузочных узлов diskv5. Позволяет пропускать явные загрузочные узлы, если церемония генерации ключей включала правильные IP-адреса. + --p2p-denylist string Разделенный запятыми список подсетей CIDR для запрета определенных одноранговых соединений. Пример: 192.168.0.0/16 запретит соединения с одноранговыми узлами в вашей локальной сети. По умолчанию принимаются все соединения. + --p2p-external-hostname string DNS-имя хоста, объявленное libp2p. Можно использовать для объявления внешнего DNS. + --p2p-external-ip string IP-адрес, объявленный libp2p. Можно использовать для внешнего IP-адреса. + --p2p-tcp-address strings Разделенный запятыми список прослушиваемых TCP-адресов (ip и порт) для трафика libP2P. (по умолчанию [127.0.0.1:3610]) + --p2p-udp-address string Прослушивание UDP-адреса (ip и порт) для обнаружения diskv5. (по умолчанию "127.0.0.1:3630") +``` + +### Запуск промежуточного ПО Charon + +Эта команда `run` принимает файл `cluster.lock`, который был создан с помощью команды `charon create cluster` или `charon dkg`. Этот файл блокировки описывает узлы в кластере и распределенные валидаторы, от имени которых они работают. + +```markdown +charon run --help +Запускает продолжительный процесс промежуточного программного обеспечения Charon для выполнения функций распределенного валидатора. + +Usage: + charon run [flags] + +Flags: + --beacon-node-endpoint string URL-адрес конечной точки узла маяка (по умолчанию "http://localhost/") + --data-dir string Каталог, в котором charon будет хранить все свои внутренние данные (по умолчанию ".charon") + --feature-set string Минимальный набор функций для включения по умолчанию: alpha, beta, или stable. Предупреждение: меняйте на свой страх и риск. (default "stable") + --feature-set-disable strings Разделенный запятыми список функций, которые нужно отключить, переопределяя минимальный набор функций по умолчанию. + --feature-set-enable strings Разделенный запятыми список функций для включения, переопределяющий минимальный набор функций по умолчанию. + -h, --help Дополнительная информация по команде run + --jaeger-address string Адрес прослушивания для трассировки jaeger + --jaeger-service string Имя службы, используемое для трассировки jaeger (по умолчанию "charon") + --lock-file string Путь к файлу блокировки кластера, определяющему кластер распределенного валидатора (по умолчанию «.charon/cluster-lock.json») + --log-format string Формат логов; console, logfmt или json (по умолчанию "console") + --log-level string Формат логов; debug, info, warn or error (по умолчанию "info") + --monitoring-address string Адрес прослушивания (ip и порт) для API мониторинга (prometheus, pprof) (по умолчанию "127.0.0.1:3620") + --p2p-allowlist string Разделенный запятыми список подсетей CIDR для разрешения только определенных одноранговых соединений. Пример: 192.168.0.0/16 разрешает подключения к одноранговым узлам только в вашей локальной сети. По умолчанию принимаются все соединения. + --p2p-bootnode-relay Позволяет использовать загрузочные узлы в качестве реле цепи libp2p. Полезно, если некоторые узлы charon недоступны публично. + --p2p-bootnodes strings Разделенный запятыми список URL-адресов или ENR загрузочных узлов diskv5. (по умолчанию [http://bootnode.gcp.obol.tech:3640/enr]) + --p2p-bootnodes-from-lockfile Позволяет использовать ENR блокировки кластера в качестве загрузочных узлов diskv5. Позволяет пропускать явные загрузочные узлы, если церемония генерации ключей включала правильные IP-адреса. + --p2p-denylist string Разделенный запятыми список подсетей CIDR для запрета определенных одноранговых соединений. Пример: 192.168.0.0/16 запретит соединения с одноранговыми узлами в вашей локальной сети. По умолчанию принимаются все соединения. + --p2p-external-hostname string DNS-имя хоста, объявленное libp2p. Можно использовать для объявления внешнего DNS. + --p2p-external-ip string IP-адрес, объявленный libp2p. Можно использовать для внешнего IP-адреса. + --p2p-tcp-address strings Разделенный запятыми список прослушиваемых TCP-адресов (ip и порт) для трафика libP2P. (по умолчанию [127.0.0.1:3610]) + --p2p-udp-address string Прослушивание UDP-адреса (ip и порт) для обнаружения diskv5. (по умолчанию "127.0.0.1:3630") + --simnet-beacon-mock Включает внутренний фиктивный узел-маяк для запуска simnet. + --simnet-validator-mock Включает внутренний фиктивный клиент валидатора при запуске simnet. Требуется simnet-beacon-mock. + --validator-api-address string Адрес прослушивания (IP-адрес и порт) для трафика, обращенного к валидатору, проксирующего API-узла-маяка (по умолчанию «127.0.0.1:3600») +``` diff --git a/i18n/ru/docusaurus-plugin-content-docs/current/dv/_category_.json b/i18n/ru/docusaurus-plugin-content-docs/current/dv/_category_.json new file mode 100644 index 0000000000..2d1677c65f --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/current/dv/_category_.json @@ -0,0 +1,5 @@ +{ + "label": "Распределенные валидаторы", + "position": 3, + "collapsed": false +} diff --git a/i18n/ru/docusaurus-plugin-content-docs/current/dvk/01_distributed-validator-keys.md b/i18n/ru/docusaurus-plugin-content-docs/current/dvk/01_distributed-validator-keys.md new file mode 100644 index 0000000000..dfd3fd61d7 --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/current/dvk/01_distributed-validator-keys.md @@ -0,0 +1,121 @@ +--- +description: Для создания закрытых ключей для распределенного валидатора требуется церемония генерации распределенного ключа (DKG). +--- + +# Генерация ключей распределенного валидатора + +## Содержание + +- [Overview](#overview) +- [Actors involved](#actors-involved) +- [Cluster Definition creation](#cluster-definition-creation) +- [Carrying out the DKG ceremony](#carrying-out-the-dkg-ceremony) +- [Backing up ceremony artifacts](#backing-up-the-ceremony-artifacts) +- [Preparing for validator activation](#preparing-for-validator-activation) +- [DKG verification](#dkg-verification) +- [Appendix](#appendix) + +## Обзор + +Распределенный ключ валидатора — это группа закрытых ключей BLS, которые вместе действуют как пороговый ключ для участия в консенсусе Proof-of-Stake. +Чтобы сделать распределенный валидатор без отказоустойчивости (т. е. все узлы должны быть подключены к сети, чтобы подписать каждое сообщение), из-за схемы подписи BLS, используемой Proof of Stake Ethereum, каждый общий ключ может быть выбран операторами независимо. Однако для создания распределенного валидатора, который может оставаться в сети, несмотря на то, что подмножество его узлов отключается, общие ресурсы ключей необходимо генерировать вместе. (Не все 4 случайно выбранные точки на графике находятся на одной и той же кривой третьего порядка.) Чтобы сделать это безопасным способом, когда ни одна из сторон не доверяет распространение ключей, требуется так называемая церемония генерации распределенного ключа. + +Клиент charon несет ответственность за безопасное завершение церемонии генерации распределенного ключа со своими узлами-контрагентами. Конфигурация церемонии описана в [определении кластера](https://docs.obol.tech/docs/dv/distributed-validator-cluster-manifest). + +## Участники + +В церемонии генерации распределённых ключей участвуют `Операторы` и их `клиенты Charon`. + +- `Оператор` идентифицируется по адресу Ethereum. Они подпишутся закрытым ключом этого адреса, чтобы аутентифицировать своего клиента charon перед церемонией. Подпись будет; хэш открытого ключа ENR клиентов charon, `cluster_definition_hash` и увеличивающийся `nonce`, позволяющий установить прямую связь между пользователем, его клиентом charon и кластером, который этот клиент предназначен обслуживать, сохраняя при этом возможность обновить клиент charon, увеличив значение одноразового номера и переподписав его, как в стандартной спецификации ENR. + +`Клиент Charon` также идентифицируется парой открытого/закрытого ключа, в данном случае открытый ключ представлен как [Запись узла Ethereum](https://eips.ethereum.org/EIPS/eip-778) (ENR). Это стандартный формат идентификации как для клиентов EL, так и для клиентов CL. Эти ENR используются каждым узлом charon для идентификации одноранговых узлов кластера через Интернет и для связи друг с другом [сквозным шифрованием](https://github.com/libp2p/go-libp2p-noise). Эти ключи должны быть созданы каждым оператором, прежде чем они смогут участвовать в создании кластера. + +## Создание кластера + +Этот файл определения создается с помощью [панели запуска распределенного валидатора](https://docs.obol.tech/docs/dvk/distributed_validator_launchpad). Процесс создания включает в себя несколько шагов. + +- Оператор-лидер, желающий координировать создание нового кластера распределенных валидаторов, перейти на стартовую панель и выбрать "Create new Cluster" +- `Лидер` использует пользовательский интерфейс для настройки всех важных деталей кластера, включает: + - `Адрес вывода` для созданных валидаторов + - `feeRecipient` для предложений блокировки, если он отличается от адреса вывода. + - Количество распределенных валидаторов для создания + - Список участников кластера, указанный адресом Ethereum(/ENS) + - Требуемый порог отказоустойчивости (если не выбрано безопасное значение по умолчанию) + - Сеть (fork_version/chainId), в которой этот кластер будет проверяться +- Эти ключевые элементы информации составляют основу конфигурации кластера. Эти поля (и некоторые технические поля, такие как алгоритм DKG для использования) сериализуются для создания `cluster_definition_hash`. Этот корень merkle будет использоваться для подтверждения отсутствия двусмысленности или отклонения между определениями, когда они предоставляются узлам charon. +- Как только лидер удовлетворен в конфигурации, он публикует ее на уровне доступности данных панели запуска, чтобы другие участники могли получить к ней доступ. (На ранних стадиях разработки панель запуска будет использовать централизованную серверную базу данных для хранения конфигурации кластера. Вблизи производства такие решения, как IPFS или arweave, могут быть более подходящими для долгосрочной децентрализации панели запуска.) + +- Затем лидер поделится URL-адресом этой церемонии со своими предполагаемыми участниками. +- Любой, кто откроет URL-адрес церемонии или введет `cluster_definition_hash` при появлении запроса на целевой странице, будет перенаправлен на страницу статуса церемонии. (После заполнения всех заявлений об отказе от ответственности и рекомендаций) +- Кнопка "Connect Wallet" будет видна под контейнером статуса церемонии, участник может нажать на нее, чтобы подключить свой кошелек к сайту + - Если участник подключает кошелек, которого нет в списке участников, кнопка отключится. + - Если участник подключает кошелек, который находится в списке участников, ему предлагается ввести ENR своего узла charon. + - Если поле ENR заполнено и проверено, участник теперь может увидеть кнопку «Confirm Cluster Configuration». Эта кнопка запускает одну/две подписи. + - Участник подписывает `cluster_definition_hash`, чтобы доказать, что он согласен с этой конфигурацией. + - Участник подписывает ENR своего узла charon, чтобы аутентифицировать и авторизовать этот конкретный узел charon для участия от его имени в кластере распределенного валидатора. + - Эти/эта подпись отправляется на уровень доступности данных, где он проверяет правильность подписи для данного адреса участника в эфире. Если подписи проходят проверку, подпись хэша определения ENR + подпись сохраняются в объекте определения. +- Все участники в списке должны подписать хэш определения и отправить подписанный ENR до начала церемонии DKG. Неподтвержденные подписи можно легко отобразить на странице статуса. +- Наконец, после того, как все участники подписали свое одобрение и представили ENR узла charon, чтобы действовать от их имени, данные определения могут быть загружены в виде файла, если пользователи нажимают вновь отображаемую кнопку `Download Manifest`. +- На этом этапе каждый участник должен загрузить это определение в свой клиент charon, и клиент попытается выполнить DKG. + +## Проведение церемонии DKG + +Как только участник подготовит свой файл определения, он передаст файл команде charon `dkg`. Charon прочитает ENR, подтвердит наличие своего ENR, а затем обратится к развернутым загрузочным узлам, чтобы найти другие ENR в сети. (Свежие ENR просто имеют открытый ключ и IP-адрес 0.0.0.0 до тех пор, пока они не будут загружены в работающий клиент charon, который обновит IP-адрес, увеличит одноразовый номер ENR и подпишется с закрытым ключом клиента. Если ENR с более высоким одноразовым номером считается клиентом charon, они обновят IP-адрес этого ENR в своей адресной книге.) + +Как только все клиенты в кластере смогут установить соединение друг с другом и каждый из них завершит рукопожатие (подтвердите, что у всех есть соответствующий `cluster_definition_hash`), далее начинается церемония. + +Ввод данных пользователем не требуется, charon выполняет всю работу и выводит следующие файлы на каждую машину, а затем завершает работу. + +```sh +# Common data +.charon/cluster-definition.json # Исходный файл определения из панели запуска DV или `charon create dkg` +.charon/cluster-lock.json # Новый файл блокировки на основе cluster-definition.json с открытыми ключами группы валидаторов и пороговыми верификаторами BLS, включенными в первоначальную конфигурацию кластера +.charon/deposit-data.json # JSON файл данных депозита для распределенных валидаторов + +# Конфиденциальные данные оператора +.charon/charon-enr-private-key # Создается до церемонии [Скопируйте и сохраните ключ] +.charon/validator_keys/ # Папка с общими ключами для резервного копирования и перемещения в клиент валидатора [Скопируйте и сохраните это] +``` + +## Создайте резервную копию артефактов церемонии + +После завершения церемонии все участники должны сделать резервную копию созданных файлов. В будущих версиях charon, если участник потеряет доступ к этим общим ресурсам ключей, можно будет использовать протокол повторного обмена ключами, чтобы заменить старые ключи участников из распределенного валидатора на новые ключи, что позволит остальной части кластер для восстановления после набора потерянных ключевых общих ресурсов. Однако на данный момент, без резервной копии, самым безопасным было бы выйти из валидатора. + +## Подготовка к активации валидатора + +После завершения церемонии каждый оператор сделал безопасное резервное копирование общих ключей. Теперь они должны загрузить эти общие ресурсы в свои клиенты-валидаторы и запустить команду `charon run`, чтобы перевести их в рабочий режим. + +Все операторы должны подтвердить, что в их журналах клиентов charon указано, что все узлы находятся в сети и подключены. Они также должны проверить готовность своих клиентов-маяков и клиентов-валидаторов. Панель Charon Grafana — это хороший способ увидеть готовность всего кластера с его точки зрения. + +Once all operators are satisfied with network connectivity, one member can use the Obol Distributed Validator deposit flow to send the required ether and deposit data to the deposit contract, beginning the process of a distributed validator activation. Good luck. +После того, как все операторы будут удовлетворены сетевым подключением, один участник может использовать deposit flow Obol Distributed Validator для отправки необходимых данных эфира и депозита в депозитный контракт, начиная процесс активации распределенного валидатора. Удачи. + +## Верификация DKG + +Во многих случаях использования распределенных валидаторов спонсор/депонент валидатора может не совпадать с создателями ключей/операторами узлов, поскольку (за пределами базового протокола) делегирование доли является распространенным явлением. Эта передача информации вводит точку доверия. Как кто-то проверяет, что предлагаемые `депозитные данные` валидатора соответствуют реальным, честным DKG с участниками, которых ожидает вкладчик? + +Существует ряд аспектов этой поверхности доверия, которые можно смягчить с помощью модели "Не доверяй, проверяй" ("Don't trust, verify"). В настоящее время проверка вне сети проще, пока в EVM не будут добавлены такие вещи, как [прекомпиляция BLS](https://eips.ethereum.org/EIPS/eip-2537), наряду с дешевой проверкой ZKP в цепочке. Некоторые из вопросов, которые можно задать на церемониях генерации ключей распределенного валидатора, включают: + +- Объединяются ли доли открытого ключа в общий открытый ключ группы? + - Это можно проверить в цепочке, поскольку для этого не требуется операция сопряжения. + - Это может дать уверенность в том, что открытый ключ BLS представляет собой распределенный валидатор, но ничего не говорит о хранении ключей. (например, была ли атака sibyl на церемонии, был ли они в сговоре, чтобы восстановить закрытый ключ группы и т. д.) +- Подтверждают ли созданные открытые ключи BLS об их `cluster_definition_hash`? + - Это делается для создания обратной связи между вновь созданными публичными ключами BLS и адресами eth1 оператора, которые принимали участие в их создании. + - Если предложенный открытый групповой ключ распределенного валидатора BLS может создать подпись `cluster_definition_hash`, можно сделать вывод, что по крайней мере пороговое число операторов подписало эти данные. + - Поскольку `cluster_definition_hash` один и тот же для всех распределенных валидаторов, созданных на церемонии, подписи могут быть объединены в групповую подпись, которая одновременно проверяет все созданные групповые ключи. Это удешевляет одновременную проверку нескольких валидаторов в цепочке. +- Есть ли доказательства VSS или PVSS честной церемонии DKG? + - VSS (Verifiable Secret Sharing) означает, что только операторы могут проверить справедливость, поскольку для доказательства требуется знание одного из секретов. + - PVSS (Publicly Verifiable Secret Sharing) означает, что любой может проверить справедливость, поскольку доказательство обычно является доказательством с нулевым разглашением (Zero Knowledge Proof). + - PVSS справедливого DKG затруднит сговор операторов и подорвет безопасность распределенного валидатора. + - Проверка с нулевым разглашением (Zero Knowledge Proof) в цепочке в настоящее время стоит дорого, но становится достижимой благодаря напряженной работе и исследованиям многих команд в отрасли, основанных на ZK. + +## Дополнительно + +### Использование DKG без панели запуска + +Клиенты Charon могут выполнить DKG с файлом определения, который не содержит сигнатур оператора, если вы передадите флаг `--no-verify` в `charon dkg`. Это можно использовать в целях тестирования, когда строгая проверка подписи не имеет первостепенного значения. + +### Примеры файлов конфигурации и файла блокировки + +Подробности смотрите [здесь](../dv/08_distributed-validator-cluster-manifest.md#cluster-configuration-files). + diff --git a/i18n/ru/docusaurus-plugin-content-docs/current/dvk/02_distributed_validator_launchpad.md b/i18n/ru/docusaurus-plugin-content-docs/current/dvk/02_distributed_validator_launchpad.md new file mode 100644 index 0000000000..db831fbc39 --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/current/dvk/02_distributed_validator_launchpad.md @@ -0,0 +1,15 @@ +--- +description: Децентрализованное приложение для безопасного создания распределенных валидаторов в одиночку или в группе. +--- + +# Панель запуска распределенного валидатора (Distributed Validator launchpad) + +![DV Launchpad Promo Image](/img/DistributeYourValidators.svg) + +Чтобы активировать валидатор Ethereum, необходимо внести 32 ETH в официальный депозитный контракт. + +Подавляющее большинство пользователей, ставшие валидаторами на сегодняшний день, использовали **[~~Eth2~~ Staking Launchpad](https://launchpad.ethereum.org/)**, общедоступный веб-сайт с открытым исходным кодом, созданный Ethereum Foundation. Вместе с участниками, которые позже основали Obol. Этот инструмент оказался чрезвычайно успешным в безопасном и образовательном создании значительного количества валидаторов в основной сети Ethereum. + +Чтобы облегчить создание распределенных ключей проверки среди удаленных пользователей с высоким уровнем доверия, Obol Network намерена разработать и поддерживать веб-сайт, который позволит группе пользователей собраться вместе и создать эти ключи. + +Панель запуска DV разрабатывается в несколько этапов, координируемых нашей [рабочей группой панели запуска DV](../int/working-groups). Чтобы принять участие в этой работе, прочитайте страницу и зарегистрируйтесь по соответствующей ссылке. diff --git a/i18n/ru/docusaurus-plugin-content-docs/current/dvk/_category_.json b/i18n/ru/docusaurus-plugin-content-docs/current/dvk/_category_.json new file mode 100644 index 0000000000..1d6ce83445 --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/current/dvk/_category_.json @@ -0,0 +1,5 @@ +{ + "label": "Генерация ключа", + "position": 4, + "collapsed": false +} diff --git a/i18n/ru/docusaurus-plugin-content-docs/current/glossary.md b/i18n/ru/docusaurus-plugin-content-docs/current/glossary.md new file mode 100644 index 0000000000..81d75be7da --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/current/glossary.md @@ -0,0 +1,8 @@ +# Глоссарий +На этой странице подробно рассматриваются различные технические термины, встречающиеся в данном руководстве. Видите слово или фразу, которые нужно добавить? Дайте нам знать! + +### Консенсус (Consensus) +Коллекция узлов, которые приходят к соглашению о том, что подписывать вместе + +### Пороговые подписи (Threshold signing) +Пороговые подписи — это цифровые подписи, в которых подписавшие могут создавать группы таким образом, что только определенные подмножества группы могут создавать подписи от имени группы, что дает набору машин должный уровень отказоустойчивости. diff --git a/i18n/ru/docusaurus-plugin-content-docs/current/int/Overview.md b/i18n/ru/docusaurus-plugin-content-docs/current/int/Overview.md new file mode 100644 index 0000000000..15ec3d1546 --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/current/int/Overview.md @@ -0,0 +1,49 @@ +--- +sidebar_position: 2 +description: Обзор сети Obol +--- + + +## Сеть + +Сеть лучше всего визуализировать как рабочий уровень, который находится непосредственно над консенсусом базового уровня. Этот рабочий уровень предназначен для обеспечения большей устойчивости базового уровня и содействия децентрализации по мере его масштабирования. По мере того, как текущее состояние Ethereum будет развиваться в ближайшие годы, сообщество перейдет к следующей серьезной задаче масштабирования, а именно к централизации доли. Чтобы эффективно снизить эти риски, создание сообщества и заслуживающий доверия нейтралитет должны использоваться в качестве основных принципов проектирования. + +Obol как слой ориентирован на масштабирование консенсуса за счет предоставления доступа без разрешений к распределенным валидаторам (DV). Мы считаем, что DV будут и должны составлять большую часть конфигураций валидаторов основной сети. При подготовке к первой волне внедрения в сети в настоящее время используется промежуточное программное обеспечение технологии распределенных валидаторов (DVT), чтобы обеспечить работу кластеров распределенных валидаторов, которые могут сохранять валидаторов в текущем клиенте и конфигурациях удаленной подписи. + +Подобно тому, как технология свертывания заложила основу для реализации масштабирования L2, мы считаем, что DVT сделает то же самое для масштабирования консенсуса при сохранении децентрализации. Инфраструктура стейкинга вступает в фазу эволюции своего протокола, которая должна включать в себя сети стейкинга с минимальным доверием, которые можно подключать в любом масштабе. Уровни, такие как Obol, имеют решающее значение для долгосрочной жизнеспособности и отказоустойчивости общедоступных сетей, особенно таких сетей, как Ethereum. Мы считаем, что DVT превратится в широко используемый примитив и обеспечит безопасность, отказоустойчивость и децентрализацию общедоступных сетей блокчейнов, которые его используют. + +Сеть Obol состоит из четырех основных составляющих: + +- [Distributed Validator Launchpad](../dvk/01_distributed-validator-keys.md), инструмент CLI и dApp для запуска распределенных валидаторов +- [Charon](../dv/01_introducing-charon.md), клиент промежуточного программного обеспечения, который позволяет валидаторам быть отказоустойчивыми, распределенным образом +- [Obol Managers](../sc/01_introducing-obol-managers.md), набор смарт-контрактов Solidity для формирования распределенных валидаторов +- [Obol Testnets](../testnet.md), набор текущих публичных поощрительных тестовых сетей, которые позволяют оператору любого размера протестировать свое развертывание перед обслуживанием в основной сети Obol Network. + +### Вклад в доступность экосистемы стейкинга + +Экосистема Obol вдохновлена ​​предыдущей работой над экосистемой Ethereum и экспериментами с экономикой. Мы считаем, что для раскрытия инноваций в сценариях использования стекинга должен существовать заслуживающий доверия нейтральный слой, чтобы инновации могли течь и развиваться по вертикали. Без этого уровня время безотказной работы будет по-прежнему оставаться плохим, а ставка будет аккумулироваться среди нескольких продуктов. + +В ближайшие месяцы и годы сеть Obol станет открытым самодостаточным проектом, управляемым сообществом. Вместе мы будем стимулировать, создавать и поддерживать технологию распределенных валидаторов, которая делает общедоступные сети более безопасной и отказоустойчивой основой для дальнейшего развития. + +![](/img/DVT4.png) + +## Наше виденье + +Путь к децентрализации ставок не быстрый процесс. В Obol мы разделили наше видение на две ключевые версии распределенных валидаторов. + +### V1 - Доверенные Распределенные Валидаторы (Trusted Distributed Validators) + +Первая версия распределенных валидаторов будет иметь внеплановое разрешение споров. Это означает, что вам нужно знать и связываться с вашими операторами-контрагентами, если есть проблема с вашим общим кластером. + +A DV without in-band dispute resolution/incentivisation is still extremely valuable. Individuals and staking as a service providers can deploy DVs on their own to make their validators fault tolerant. Groups can run DVs together, but need to bring their own dispute resolution to the table, whether that be a smart contract of their own, a traditional legal service agreement, or simply high trust between the group. +DV без внутреннего разрешения/поощрения споров по-прежнему чрезвычайно ценен. Частные лица и поставщики услуг могут развертывать DV самостоятельно, чтобы сделать свои валидаторы отказоустойчивыми. Группы могут запускать DV вместе, но им необходимо вынести на обсуждение свое собственное разрешение споров, будь то собственный смарт-контракт, традиционное соглашение о юридических услугах или просто высокое доверие между группой. + +Obol V1 будет использовать ретроактивные принципы общественных благ, чтобы заложить основу своей экономической экосистемы. Сообщество Obol будет ответственно распределять собранные ETH в качестве грантов для проектов в экосистеме ставок на протяжении всей версии V1. + +### V2 - Распределенные валидаторы без доверия (Trustless Distributed Validators) + +V1 Charon'а обслуживает небольшую по количеству, но большую по весу группу лиц. Большое количество мелких стейкеров и стейкеров в домашних условиях, также заслуживают доступа к отказоустойчивой проверке, но они могут не знать большинство других операторов лично, чтобы иметь достаточный уровень доверия для совместной работы кластера DV. + +Вторая версия Сharon будет включать в себя схему поощрения, чтобы гарантировать, что любой оператор, не подключенный к сети и участвующий в проверке, не получает никаких вознаграждений. Дальнейшее согласование поощрений может быть достигнуто с помощью требований к связям с оператором, которые могут быть сокращены из-за неприемлемой производительности. + +Чтобы добавить уровень стимулирования вне игры, к пороговой проверке, требуются сложные интерактивные криптографические схемы, безопасное разрешение споров вне сети и поддержка EVM для доказательств состояния уровня консенсуса, в результате это будет дольше и сложнее, чем V1. , отсюда и разграничение между ними. diff --git a/i18n/ru/docusaurus-plugin-content-docs/current/int/_category_.json b/i18n/ru/docusaurus-plugin-content-docs/current/int/_category_.json new file mode 100644 index 0000000000..c78dcfdb76 --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/current/int/_category_.json @@ -0,0 +1,5 @@ +{ + "label": "Введение", + "position": 2, + "collapsed": false +} diff --git a/i18n/ru/docusaurus-plugin-content-docs/current/int/faq.md b/i18n/ru/docusaurus-plugin-content-docs/current/int/faq.md new file mode 100644 index 0000000000..7c6f1d471a --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/current/int/faq.md @@ -0,0 +1,39 @@ +--- +sidebar_position: 10 +description: Часто задаваемые вопросы +--- + +# Часто задаваемые вопросы + +### У Obol есть токен? + +Нет. Распределенные валидаторы используют только эфир. + +### Могу ли я сохранить существующий клиент валидатора? + +Да. Charon является промежуточным программным обеспечением между клиентом валидатора и его узлом-маяком. Будут поддерживаться все валидаторы, реализующие стандартный REST API, а также все популярные программы доставки клиентов, такие как DAppNode [packages](https://dappnode.github.io/explorer/#/), Rocket Pool's [smart node](https://github.com/rocket-pool/smartnode), StakeHouse's [wagyu](https://github.com/stake-house/wagyu), and Stereum's [node launcher](https://stereum.net/development/#roadmap). + +### Могу ли я перенести свой существующий валидатор в распределенный валидатор? + +Можно будет разделить существующее хранилище ключей валидатора на набор общих ключей, подходящих для распределенного валидатора, но это доверенный процесс распространения, и если старая система ставок не будет безопасно отключена, это может создать риск двойной подписи. вместе с новым распределенным валидатором. + +В идеальном сценарии закрытый ключ распределенного валидатора никогда не должен полностью храниться в одном месте. + +Вы можете разделить существующее хранилище ключей EIP-2335 для валидатора, чтобы перенести его на распределенную архитектуру валидатора с помощью задокументированной команды charon create cluster --split-existing-keys [информация](../dv/09_charon_cli_reference.md#create-a-full-cluster-locally). + +### Что такое ENR? + +ENR это сокращение для [Ethereum Node Record](https://eips.ethereum.org/EIPS/eip-778). Это способ представить узел в общедоступной сети с надежным механизмом обновления его информации. В Obol мы используем ENR для идентификации узлов Charon друг с другом, чтобы они могли образовывать кластеры с правильными узлами Charon, а не с самозванцами. + +У ENR есть закрытые ключи, которые они используют для подписи обновлений [содержание данных](https://enr-viewer.com/) в своих ENR. Этот закрытый ключ по умолчанию находится в `.charon/charon-enr-private-key`, и его следует хранить в безопасности и не хранить в системе контроля версий. ENR выглядит примерно так: +``` +enr:-JG4QAgAOXjGFcTIkXBO30aUMzg2YSo1CYV0OH8Sf2s7zA2kFjVC9ZQ_jZZItdE8gA-tUXW-rWGDqEcoQkeJ98Pw7GaGAYFI7eoegmlkgnY0gmlwhCKNyGGJc2VjcDI1NmsxoQI6SQlzw3WGZ_VxFHLhawQFhCK8Aw7Z0zq8IABksuJEJIN0Y3CCPoODdWRwgj6E +``` + +### Где я могу узнать больше о распределенных валидаторах? + +Можете посмотреть в [нашем блоге](https://blog.obol.tech) и в [твиттере](https://twitter.com/ObolNetwork) Также можно найти информации в [discord](https://discord.gg/obol). + +### значение слова Charon? + +[Charon](https://www.theoi.com/Khthonios/Kharon.html) это древнегреческий перевозчик мертвых. Ему было поручено переправить людей через реку Ахерон в подземный мир. Его гонорар составлял одну оболскую монету, которую клали в рот умершему. Эта традиция класть монету или обол в рот умершего продолжается и по сей день во всем греческом мире. \ No newline at end of file diff --git a/i18n/ru/docusaurus-plugin-content-docs/current/int/key-concepts.md b/i18n/ru/docusaurus-plugin-content-docs/current/int/key-concepts.md new file mode 100644 index 0000000000..12470292ad --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/current/int/key-concepts.md @@ -0,0 +1,86 @@ +--- +sidebar_position: 3 +description: Некоторые из ключевых терминов в области технологии распределенных валидаторов +--- + +# Ключевые понятия +На этой странице представлен ряд ключевых понятий, лежащих в основе различных технологий, которые разрабатывает Obol. + +## Распределенный валидатор (Distributed validator) + +![Распределенный валидатор](/img/WhatIsADistributedValidator.png) + +Распределенный валидатор — это валидатор Proof-of-Stake Ethereum, который работает более чем на одном узле/машине. Эта функциональность обеспечивается **Distributed Validator Technology** (DVT). + +​Технология распределенного валидатора устраняет проблему единичного отказа. Если <33% участвующих узлов в кластере DVT отключатся, оставшиеся активные узлы по-прежнему смогут прийти к консенсусу в отношении того, что подписывать, и создавать действительные подписи для выполнения своих обязанностей по стейкингу. Это известно как избыточность «активный/активный», распространенный шаблон для минимизации времени простоя в критически важных системах. + +## Узел распределенного валидатора (Distributed Validator Node) + +![Узел распределенного валидатора](/img/WhatIsADistributedValidatorNode.png) + +Узел распределенного валидатора — это набор клиентов, которые необходимо настроить и запустить оператору для выполнения обязанностей оператора распределенного валидатора. Оператор также может запускать резервные клиенты выполнения и консенсуса, ретранслятор полезной нагрузки выполнения, такой как [mev-boost](https://github.com/flashbots/mev-boost), или другие службы мониторинга или телеметрии на том же оборудовании для обеспечения оптимальной производительности. + +In the above example, the stack includes geth, lighthouse, charon and lodestar. +В приведенном выше примере технологический стек включает в себя geth, lighthouse, charon and lodestar. + +### Клиент исполнения + +Клиент выполнения (ранее известный как клиент Eth1) специализируется на запуске EVM и управлении пулом транзакций для сети Ethereum. Эти клиенты предоставляют исполняемую полезную нагрузку согласованным клиентам для включения в блоки. + +Примеры исполняемых клиентов включают: + +- [Go-Ethereum](https://geth.ethereum.org/) +- [Nethermind](https://docs.nethermind.io/nethermind/) +- [Erigon](https://github.com/ledgerwatch/erigon) + +### Клиент консенсуса + +Обязанностью клиента консенсуса является запуск уровня консенсуса Proof-of-Stake в Ethereum, который часто называют цепочкой маяков (beacon chain). + +Примеры клиентов консенсуса включают: + +- [Prysm](https://docs.prylabs.network/docs/how-prysm-works/beacon-node) +- [Teku](https://docs.teku.consensys.net/en/stable/) +- [Lighthouse](https://lighthouse-book.sigmaprime.io/api-bn.html) +- [Nimbus](https://nimbus.guide/) +- [Lodestar](https://github.com/ChainSafe/lodestar) + +### Клиент распределенного валидатора + +Распределенный клиент валидатора перехватывает поток связи между клиентом валидатора и согласованным клиентом через [стандартизированный REST API](https://ethereum.github.io/beacon-APIs/#/ValidatorRequiredApi) и фокусируется на двух основных задачах. + +- Приводит к консенсусу относительно обязанности кандидата, которую должны подписать все валидаторы. +- Объединение подписей всех валидаторов в распределенную подпись валидатора + +На сегодняшний день единственным примером распределенного клиента валидатора, построенного с архитектурой промежуточного программного обеспечения, не связанной с хранением, является [charon](../dv/01_introducing-charon.md). + +### Клиент валидатора + +Клиент валидатора — это фрагмент кода, который управляет одним или несколькими валидаторами Ethereum. + +Примеры клиентов валидатора включают: + +- [Vouch](https://www.attestant.io/posts/introducing-vouch/) +- [Prysm](https://docs.prylabs.network/docs/how-prysm-works/prysm-validator-client/) +- [Teku](https://docs.teku.consensys.net/en/stable/) +- [Lighthouse](https://lighthouse-book.sigmaprime.io/api-bn.html) + +## Кластер распределенных валидаторов (A Distributed Validator Cluster) + +![Кластер распределенных валидаторов](/img/WhatIsADistributedValidatorCluster.png) + +Кластер распределенных валидаторов — это набор узлов распределенных валидаторов, соединенных вместе для обслуживания набора распределенных валидаторов, сгенерированных во время церемонии DVK. + +### Ключ распределенного валидатора (Distributed Validator Key) + +Распределенный ключ валидатора — это группа закрытых ключей BLS, которые вместе действуют как пороговый ключ для участия в консенсусе Proof-of-Stake. + +### Общий ключ распределенного валидатора (Distributed Validator Key Share) + +Одна часть распределенного закрытого ключа валидатора. + +### Церемония генерации ключа распределенного валидатора (Distributed Validator Key Generation Ceremony) + +Чтобы добиться отказоустойчивости в распределенном валидаторе, отдельные общие секретные ключи должны генерироваться вместе. Вместо того, чтобы доверенный дилер создавал закрытый ключ, разделял его и распространял, предпочтительный подход состоит в том, чтобы никогда не создавал полный закрытый ключ в любой момент, когда каждый оператор в распределенном кластере валидатора участвует в так называемом распределенном ключе. Церемония генерации. + +Церемония генерации распределенного ключа валидатора является разновидностью церемонии DKG. Церемония DVK создает подписанные данные о депозите и выходе валидатора, а также все доли ключей валидатора и связанные с ними метаданные. diff --git a/i18n/ru/docusaurus-plugin-content-docs/current/int/quickstart/_category_.json b/i18n/ru/docusaurus-plugin-content-docs/current/int/quickstart/_category_.json new file mode 100644 index 0000000000..c7a09cfbd7 --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/current/int/quickstart/_category_.json @@ -0,0 +1,5 @@ +{ + "label": "С чего начать", + "position": 3, + "collapsed": false +} diff --git a/i18n/ru/docusaurus-plugin-content-docs/current/int/quickstart/index.md b/i18n/ru/docusaurus-plugin-content-docs/current/int/quickstart/index.md new file mode 100644 index 0000000000..6722bbbb51 --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/current/int/quickstart/index.md @@ -0,0 +1,12 @@ +# С чего начать + +:::caution +Charon находится в ранней альфа-версии и не готов к запуску в основной сети +::: + +Есть два способа протестировать распределенный валидатор; самостоятельно, запустив все необходимое программное обеспечение в docker контейнерах, или вы можете запустить распределенный валидатор с группой других операторов узлов, где каждый из вас запускает только один клиент валидатора и клиент charon, а клиенты charon взаимодействуют друг с другом через Интернет для управления распределенным валидатором. Второй способ требует, чтобы каждый оператор открыл порт в Интернете, чтобы все узлы charon могли оптимально общаться друг с другом. + +Ниже приведены руководства по началу работы с нашими репозиториями. Идея состоит в том, чтобы поддерживать каждую комбинацию сборок: клиентов-маяков, клиентов-валидаторов. + +- [Запуск всего кластера в одиночку.](./quickstart-alone.md) +- [Запуск одного узла в кластере с группой других операторов узлов.](./quickstart-group.md) \ No newline at end of file diff --git a/i18n/ru/docusaurus-plugin-content-docs/current/int/quickstart/quickstart-alone.md b/i18n/ru/docusaurus-plugin-content-docs/current/int/quickstart/quickstart-alone.md new file mode 100644 index 0000000000..0a8c11260b --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/current/int/quickstart/quickstart-alone.md @@ -0,0 +1,64 @@ +--- +sidebar_position: 4 +description: Запуск всех узлов в распределенном кластере валидатора +--- + +# Запуск кластера в одиночку + +:::caution +Charon находится в ранней альфа-версии и не готов к запуску в основной сети +::: + +1. Склонируйте репозиторий [charon-distributed-validator-cluster](https://github.com/ObolNetwork/charon-distributed-validator-cluster) и перейдите в директорию `cd`. + + ```sh + # Склонируйте репозиторий + git clone https://github.com/ObolNetwork/charon-distributed-validator-cluster.git + + # Смените директорию + cd charon-distributed-validator-cluster/ + ``` + +1. Подготовка окружения + + ```sh + # Скопируйте файл с переменными среды + cp .env.sample .env + ``` + + Для простоты этот репозиторий настроен для работы с удаленным узлом Beacon, например, из + [Infura](https://infura.io/). + + Создайте проект Eth2 и скопируйте URL-адрес `https`, убедитесь, что Prater выбран в раскрывающемся списке ENDPOINTS: + + ![Пример Infura API Endpoint](/img/example-infura-details.png) + + Замените значение `CHARON_BEACON_NODE_ENDPOINT` во вновь созданном файле `.env` этим URL-адресом. + +1. Сгенерируйте файлы, необходимые для запуска кластера распределенного валидатора тестовой сети + + ```sh + # Создайте кластер распределенного валидатора тестовой сети + docker run --rm -v "$(pwd):/opt/charon" ghcr.io/obolnetwork/charon:v0.8.1 create cluster --withdrawal-address="0x000000000000000000000000000000000000dead" + ``` + +1. Запуск кластера + ```sh + # Запустите кластер распределенного валидатора + docker-compose up + ``` +1. Проверьте панель мониторинга и посмотрите, все ли в порядке + + ```sh + # Откройте Grafana + open http://localhost:3000/d/laEp8vupp + ``` + +1. Активируйте валидатор в тестовой сети, используя оригинальный [staking launchpad](https://prater.launchpad.ethereum.org/en/overview) сайт с данными депозита созданными в `.charon/cluster/deposit-data.json`. + - Если вы используете Mac OS, `.charon`, выходная папка по умолчанию, не отображается в средстве выбора файлов найдите "Upload Deposit Data" на панели запуска. Rectify this by pressing `Command + Shift + . ` . Это должно отображать скрытые папки, позволяя вам выбрать файл депозита. + +Поздравляем, если всё сработало корректно, теперь вы запускаете кластер распределенного валидатора в тестовой сети. Попробуйте отключить один из четырех узлов с помощью `docker stop` и посмотрите, остается ли валидатор в сети или начинает пропускать свои обязанности, чтобы убедиться в отказоустойчивости, которую можно добавить к проверке подтверждения доли с помощью этой новой Технологии Распределенного Валидатора (Distributed Validator Technology). + +:::tip +Не забудьте быть хорошим распорядителем тестовой сети и выйти из валидатора, когда закончите тестирование. +::: diff --git a/i18n/ru/docusaurus-plugin-content-docs/current/int/quickstart/quickstart-group.md b/i18n/ru/docusaurus-plugin-content-docs/current/int/quickstart/quickstart-group.md new file mode 100644 index 0000000000..c124983146 --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/current/int/quickstart/quickstart-group.md @@ -0,0 +1,134 @@ +--- +sidebar_position: 5 +description: Запуск одного узза в распределенном кластере валидатора с несколькими операторами +--- + +# Совместный запуск кластера + +:::caution +Charon находится в ранней альфа-версии и не готов к запуску в основной сети +::: + +Для создания распределенного кластера валидаторов с группой других операторов узлов требуется пять ключевых шагов: + +- Каждый оператор подготавливает свое программное обеспечение и получает свой клиентский charon. [ENR](../faq.md#what-is-an-enr) +- Один оператор подготавливает условия генерации ключей распределенного валидатора для запуска + - Они выбирают сеть, адрес вывода средств, количество 32 распределенных валидаторов эфира для создания и ENR каждого оператора, принимающего участие в запуске. + - В будущем панель запуска DV будет упрощать этот процесс, с согласия на условиях, предоставленных всеми участвующими операторами. +- Каждый оператор участвует в запуске DKG, и в случае успеха создается ряд сгенерированных файлов кластера, в том числе: + - Общий закрытый ключ для каждого распределенного валидатора + - Файл данных депозита, содержащий детали депозита для каждого распределенного валидатора + - Файл `cluster-lock.json`, который содержит окончательный конфиг этого кластера, необходимый для работы charon. + +- Каждый оператор запускает свой узел с помощью «charon run» и использует свой мониторинг для определения работоспособности кластера и подключения +- После подтверждения работоспособности кластера файлы данных депозита, созданные в ходе этого процесса, активируются на [staking launchpad](https://launchpad.ethereum.org/). + +## Начало работы с Charon + +1. Склонируйте репозиторий [charon-distributed-validator-node](https://github.com/ObolNetwork/charon-distributed-validator-node) с Github, и перейдите в директорию `cd`. + + ```sh + # Склонируйте репозиторий + git clone https://github.com/ObolNetwork/charon-distributed-validator-node.git + + # Смените директорию + cd charon-distributed-validator-node/ + ``` +1. Затем создайте закрытый ключ для charon, чтобы использовать его для ENR. + + ```sh + # Создайте закрытый ключ ENR (private key) + docker run --rm -v "$(pwd):/opt/charon" ghcr.io/obolnetwork/charon:v0.8.1 create enr + ``` + + Эта команда выведет ENR вашего клиента charon в консоль. Это должно выглядеть примерно так: + + ``` + Created ENR private key: .charon/charon-enr-private-key + enr:-JG4QAgAOXjGFcTIkXBO30aUMzg2YSo1CYV0OH8Sf2s7zA2kFjVC9ZQ_jZZItdE8gA-tUXW-rWGDqEcoQkeJ98Pw7GaGAYFI7eoegmlkgnY0gmlwhCKNyGGJc2VjcDI1NmsxoQI6SQlzw3WGZ_VxFHLhawQFhCK8Aw7Z0zq8IABksuJEJIN0Y3CCPoODdWRwgj6E + ``` + + :::caution + На данный момент возможность замены удаленного или скомпрометированного закрытого ключа ограничена. Пожалуйста, сделайте безопасную резервную копию этого закрытого ключа, если этот распределенный валидатор важен для вас. + ::: + + Эта запись идентифицирует ваш клиент charon независимо от того, откуда он общается через Интернет. Это необходимо для следующего шага создания набора распределенных общих ключей валидатора среди операторов кластера. + + Обязательно сделайте резервную копию закрытого ключа по адресу .charon/charon-enr-private-key. Будьте осторожны, чтобы не закоммитить его в git! Если вы потеряете этот файл, вы не сможете принять участие в запуске DKG. + + Если вы принимаете участие в организованной тестовой сети Obol, отправьте созданный публичный адрес ENR (вывод консоли, начинающийся с `enr:-` (отправить вместе с enr:-), а не содержимое файла закрытого ключа) в соответствующую форму для участия. + + +## Генерация ключа распределенного валидатора + +Чтобы безопасно создать закрытые ключи для распределенного валидатора, необходимо выполнить процесс генерации распределенного ключа (DKG). + +1. После сбора всех операторов ENR и установки их в файле `.env`, один оператор должен подготовить церемонию с помощью `charon create dkg` + + ```sh + + # Сначала установите ENR всех операторов, участвующих в церемонии DKG, в файле .env как CHARON_OPERATOR_ENRS + + # Создайте .charon/cluster-definition.json для участия в церемонии DKG + docker run --rm -v "$(pwd):/opt/charon" --env-file .env ghcr.io/obolnetwork/charon:v0.8.1 create dkg + ``` + +1. Оператор, выполнивший эту команду, должен передать результирующий файл `cluster-definition.json` каждому оператору. + +1. В заранее оговоренное время все операторы запускают программу церемонии с помощью команды `charon dkg`. + + ```sh + # Скопируйте cluster-definition.json файл в .charon + cp cluster-definition.json .charon/ + + # Участие в церемонии DKG, создаст .charon/cluster-lock.json, .charon/deposit-data.json и .charon/validator_keys/ + docker run --rm -v "$(pwd):/opt/charon" ghcr.io/obolnetwork/charon:v0.8.1 dkg + ``` + +## Проверка работоспособности кластера + +После завершения церемонии генерации ключей узлы charon получают данные, необходимые для объединения в кластер. + +1. Сначала вы должны подготовить необходимые переменные среды, в частности, вам нужно установить переменную `CHARON_BEACON_NODE_ENDPOINT`, чтобы она указывала либо на локальную, либо на удаленную конечную точку API узла маяка. + + ```sh + # Скопируйте шаблон переменных среды + cp .env.sample .env + ``` + + Для простоты этот репозиторий настроен для работы с удаленным узлом Beacon, например, из + [Infura](https://infura.io/). + + Создайте проект Eth2 и скопируйте URL-адрес `https`, убедитесь, что Prater выбран в раскрывающемся списке ENDPOINTS: + + ![Пример Infura API Endpoint](/img/example-infura-details.png) + + Замените значение `CHARON_BEACON_NODE_ENDPOINT` во вновь созданном файле `.env` этим URL-адресом. + +1. Запустите узел распределенного валидатора с помощью docker-compose. + ```sh + # Запустите клиент charon, клиент vc и клиенты prom+grafana в контейнерах + docker-compose up + ``` +1. Используйте предварительно подготовленную информационную панель [grafana](http://localhost:3000/) чтобы убедиться, что состояние кластера в порядке. Вы должны увидеть соединения со всеми другими операторами в кластере как работоспособные, а наблюдаемое время проверки связи для всех соединений составляет менее 1 секунды. + + ```sh + # Откройте Grafana + open http://localhost:3000/d/singlenode + ``` + Если Grafana не загружает данные при первом открытии, попробуйте [этот метод](https://github.com/ObolNetwork/charon-distributed-validator-node#grafana-doesnt-load-any-data) для решения проблемы. + +## Активация распределенного валидатора + +Когда кластер исправен и полностью подключен, пришло время внести необходимые 32 (тестовых) эфира, чтобы активировать недавно созданный распределенный валидатор. + +1. Активируйте валидатор в тестовой сети, используя оригинальный [staking launchpad](https://prater.launchpad.ethereum.org/en/overview) сайт с данными о депозите, созданный на `.charon/deposit-data.json`. + - Если вы используете Mac OS, `.charon`, выходная папка по умолчанию, не отображается в средстве выбора файлов найдите "Upload Deposit Data" на панели запуска. Rectify this by pressing `Command + Shift + . ` . Это должно отображать скрытые папки, позволяя вам выбрать файл депозита. + - Более удобный интерфейс депозита для валидатора, находится в разработке для предстоящего выпуска. +1. Этот процесс занимает около 16 часов, прежде чем депозит будет зарегистрирован в цепочке маяков. Будущие обновления протокола направлены на сокращение этого времени. +1. Как только депозит валидатора распознается в цепочке маяков, валидатору присваивается индекс, и начинается ожидание активации. +1. Наконец, после активации валидатора его следует контролировать, чтобы убедиться, что он достигает расстояния включения, близкого к 0, для обеспечения оптимального вознаграждения. Вы также должны твитнуть ссылку на ваш недавно активированный валидатор с хэштегом. [#RunDVT](https://twitter.com/search?q=%2523RunDVT) 🙃 + +:::tip +Не забудьте быть хорошим распорядителем тестовой сети и выйти из валидатора, когда закончите тестирование. +::: diff --git a/i18n/ru/docusaurus-plugin-content-docs/current/int/working-groups.md b/i18n/ru/docusaurus-plugin-content-docs/current/int/working-groups.md new file mode 100644 index 0000000000..843b3263a2 --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/current/int/working-groups.md @@ -0,0 +1,145 @@ +--- +sidebar_position: 5 +description: Структура рабочей группы Obol Network. +--- + +# Рабочая группа + +Сеть Obol — это распределенный согласованный протокол и экосистема, задача которых — устранить риски технических сбоев в Ethereum с помощью технологии распределенного валидатора (DVT). Проект достиг точки, когда усиление координации, участия и ответственности сообщества окажет значительное влияние на рост базовой технологии. В результате команда Obol Labs откроет рабочие потоки и поощрения для сообщества, при этом первая рабочая группа будет заниматься процессом создания распределенных валидаторов. + +Этот документ призван описать, что такое Obol, как устроена экосистема, как она планирует развиваться и из чего будет состоять первая рабочая группа. + +## Экосистема Obol + +Сеть Obol состоит из четырех основных продуктов: + +- **The DVK Launchpad** - инструмент CLI и пользовательский интерфейс для запуска распределенных валидаторов. + +- **Charon** - клиент промежуточного программного обеспечения, который позволяет валидаторам оставаться отказоустойчивыми, распределенным образом + +- **Obol Managers** - набор смарт-контрактов Solidity для формирования распределенных валидаторов + +- **Obol Testnets** - набор текущих публичных поощрительных тестовых сетей, которые позволяют оператору любого размера протестировать свое развертывание перед обслуживанием в основной сети Obol Network. + +## Формирование рабочих групп + +Obol Labs стремится обеспечить разнообразие участников, открывая проект для внешнего участия. Затем участники на раннем этапе сортируются в структурированные рабочие группы, что позволяет многим голосам сотрудничать в области стандартизации и создания компонентов с открытым исходным кодом. + +Для каждого отдела продукта будет создана специальная рабочая группа, открытая для участия членов общества Obol. Первая рабочая группа занимается разработкой распределенных ключей валидатора и панели запуска DV. Это позволит участникам поэкспериментировать с экосистемой Obol и найти взаимовыгодное долгосрочное сотрудничество с проектом. + +Вторая рабочая группа будет заниматься тестовыми сетями после того, как первая будет завершена. + +## Рабочая группа DVK + +Первая рабочая группа, которую Obol запустит для участия, сосредоточена на компоненте генерации распределенного валидатора технологического стека Obol. Это попытка стандартизировать создание распределенного валидатора с помощью EIP и создать панель запуска сообщества, аналогичную сегодняшней панели запуска Eth2 (ранее созданной членами основной команды Obol). + +Генерация распределенного ключа валидации (DVK) является важнейшей базовой возможностью протокола и, в более широком смысле, важной частью разработки для различных расширенных вариантов использования. В результате цель рабочей группы состоит в том, чтобы использовать подход сообщества к определению, разработке и стандартизации инструмента генерации ключей распределенного валидатора с открытым исходным кодом и панели запуска сообщества. + +Эту задачу можно условно разделить на три этапа: +- Этап 0: тестирование POC, обратная связь по POC, реализация DKG, спецификация и отправка EIP +- Этап 1: Спецификация Launchpad и отзывы пользователей +- Этап 1.5: Дополнительные исследования (проверка несколькими операторами) + +## Стадии +Члены рабочей группы DVK будут иметь разные обязанности в зависимости от этапа их участия. + +### Участие в нулевой стадии + +Нулевой этап ориентирован на прикладную криптографию и безопасность. Ожидаемый результат этого этапа — CLI-программа для участия в церемониях DVK. + +Obol опишет и создаст интерактивный инструмент CLI, способный генерировать распределенные ключи валидатора с учетом стандартизированного файла конфигурации и доступа к сети для координации с другими узлами-участниками. Этот инструмент может использоваться одним объектом (синхронно) или группой участников (полуасинхронно). + +Группа нулевого этапа находится в процессе отправки EIP для схемы кодирования распределенного ключа проверки в соответствии с EIP-2335, а также нового EIP для кодирования конфигурации и приватных данных, необходимых для процесса DKG, как указано в рабочей группе. + +**Обязанности участников:** +- Тестирование реализации и обратная связь +- Обратная связь о алгоритме DKG +- Обратная связь о защищенности Церемонии +- Опыт работы с Go, Rust, Solidity или прикладной криптографией + +### Участие в 1 этапе + +Этап 1 сосредоточен на разработке DV LaunchPad, веб-интерфейса SPA с открытым исходным кодом для облегчения церемоний DVK с аутентифицированными контрагентами. + +Чтобы облегчить генерацию распределенных ключей валидатора среди удаленных пользователей с высоким уровнем доверия, Obol Labs намерена разработать и поддерживать веб-сайт, который позволит группе пользователей генерировать конфигурацию, необходимую для церемонии генерации DVK. + +Команда Obol Labs сотрудничает с Deep Work Studio в рамках многонедельного сеанса дизайна и обратной связи с пользователями, который начался 1 апреля. В совместных сеансах проектирования и прототипирования участвуют основная команда Obol и члены сообщества Genesis. Все занятия будут записываться и публиковаться в открытом доступе. + +**Обязанности участников:** +- Фидбек о архитектуре DV LaunchPad +- Принять участие в 2 раундах синхронного пользовательского тестирования с командой Deep Work (6–10 апреля и 18–22 апреля). +- Создание валидатора тестовой сети + +### Участие в этапе 1.5 + +Этап 1.5 сосредоточен на формальном исследовании спроса и понимания мультиоператорной проверки. Это будет отдельная исследовательская работа, которую проведет Джорджия Ракусен. Это исследование будет оформлено в виде официального отчета и бесплатно распространено среди сообщества Эфириума. Участие в этапе 1.5 основано на опросе пользователей и психологическом тестировании. Эта работа началась в начале апреля. + +**Обязанности участников:** +- Полный асинхронный опрос +- Передать опрос пользователям профиля, чтобы повысить глубину исследования. +- Создание проектных ресурсов для финального исследовательского артефакта + +## Прогресс этапов + +Основная команда Obol начала работу над всеми тремя этапами работы и представит черновые версии, а также запустит каналы Discord для каждого этапа, когда это необходимо. Ниже приведено обновление статуса основной команды по каждому этапу на сегодняшний день. + +**Прогресс:** + +- Этап 0: 70% +- Этап 1: 65% +- Этап 1.5: 30% + +Основная команда планирует выпустить различные этапы для получения отзывов от сообщества по мере того, как они приближаются к 75% завершению. + +## Ключевые задачи рабочей группы + +Результатами работы этой рабочей группы являются: + +### 1. Стандартизировать формат DVKs через EIPs + +Одним из многих успехов сообщества разработчиков Ethereum является высокий уровень поддержки стандартизированных форматов файлов со стороны всех групп клиентов. Крайне важно, чтобы мы все работали вместе как рабочая группа в этом ключе. + +Два примера таких стандартов в клиентском пространстве консенсуса включают: + +- EIP-2335: Формат JSON для хранения и обмена закрытыми ключами BLS12-381. +- EIP-3076: Распределенная схема кодирования ключа проверки Slashing Protection Interchange Format в соответствии с EIP-2335 и новый EIP для кодирования конфигурации и приватных данных, необходимых для кластера DV, который имеет выходные данные, основанные на отзывах рабочих групп. Выходы церемонии ДВК могут включать: + +- Подписанные файлы данных депозита валидатора +- Подписанные сообщения валидатора о выходе +- Закрытые общие ключи для клиента валидатора каждого оператора +- Манифесты распределенного кластера валидаторов для связывания каждого узла вместе + +### 2. Программа CLI для церемоний распределенного валидатора (DVK) + +Одним из ключевых успехов запуска Proof of Stake Ethereum стала доступность высококачественных инструментов CLI для генерации ключей валидатора Ethereum, включая eth2.0-deposit-cli и ethdo. + +Рабочая группа выпустит аналогичный инструмент командной строки, способный генерировать распределенные ключи валидатора при стандартной конфигурации и сетевом доступе для координации с другими узлами-участниками. + +As of March 1st, the WG is testing a POC DKG CLI based on Kobi Gurkan's previous work. In the coming weeks we will submit EIPs and begin to implement our DKG CLI in line with our V0.5 specs and the WG's feedback. +По состоянию на 1 марта рабочая группа тестирует интерфейс командной строки POC DKG на основе предыдущей работы Коби Гуркана. В ближайшие недели мы представим EIP и начнем внедрять интерфейс командной строки DKG в соответствии с нашими спецификациями версии 0.5 и отзывами рабочей группы. + +### 3. Панель запуска распределенного валидатора + +Чтобы активировать валидатор Ethereum, вам необходимо внести 32 эфира в официальный депозитный контракт. Подавляющее большинство пользователей, создавших валидаторы на сегодняшний день, использовали **[~~Eth2~~ Staking Launchpad](https://launchpad.ethereum.org/)**, общедоступный веб-сайт с открытым исходным кодом, созданный Ethereum Foundation. и участники, которые позже основали Obol. Этот инструмент оказался чрезвычайно успешным в безопасном и образовательном создании значительного количества валидаторов в основной сети Ethereum. + +Чтобы облегчить генерацию распределенных ключей валидатора среди удаленных пользователей с высоким уровнем доверия, Obol Labs разместит и будет поддерживать веб-сайт, который позволит группе пользователей совместно генерировать распределенные ключи валидатора, используя церемонию DKG в браузере. + +Со временем функции DV LaunchPad в первую очередь расширят спектр генерации ключей без доверия. Функции панели запуска V1 могут быть протестированы пользователем и прокомментированы любым участником сообщества Obol Proto! + +## Участники рабочей группы + +Членами рабочей группы 0го этапа являются: + +- The Obol genesis community +- Ethereum Foundation (Carl, Dankrad, Aditya) +- Ben Edgington +- Jim McDonald +- Prysmatic Labs +- Sourav Das +- Mamy Ratsimbazafy +- Kobi Gurkan +- Coinbase Cloud + +Предполагаемая инфраструктура этапа 1 и этапа 1.5 будет запущена без первоначальных участников, хотя они сразу же будут доступны для отправки участникам, которые присоединились к сообществу Obol Proto прямо [здесь](https://pwxy2mff03w.typeform.com/to/Kk0TfaYF). Каждый может присоединиться к прото-сообществу; однако участие в рабочей группе будет основываться на релевантности и наборе навыков. + + diff --git a/i18n/ru/docusaurus-plugin-content-docs/current/intro.md b/i18n/ru/docusaurus-plugin-content-docs/current/intro.md new file mode 100644 index 0000000000..c0bc5a6742 --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/current/intro.md @@ -0,0 +1,20 @@ +--- +sidebar_position: 1 +description: Добро пожаловать в сеть валидаторов с несколькими операторами +--- + +# Введение + +## Что такое Obol? + +Obol Labs — команда исследователей и разработчиков программного обеспечения, специализирующаяся на инфраструктуре проверки доли владения для общедоступных сетей блокчейна. Особое внимание уделяется таким темам, как интернет-облигации, технология распределенных валидаторов и мультиоператорная валидация. В настоящее время команда состоит из 10 человек, разбросанных по всему миру. + +Основная команда создает сеть Obol Network, протокол, способствующий минимизации доверительных ставок за счет проверки несколькими операторами. Это обеспечит доступ с низким уровнем доверия к доходности стейкинга Ethereum, который можно использовать в качестве основного строительного блока в различных продуктах Web3. + +## О этой документации + +Это руководство предназначено для разработчиков и стейкеров, желающих использовать сеть Obol для многостороннего стейкинга. Чтобы внести свой вклад в эту документацию, перейдите в наш [Github repository](https://github.com/ObolNetwork/obol-docs) и отправьте запрос на вытягивание. + +## Нужна помощь? + +Если у вас есть какие-либо вопросы об этой документации или у вас возникли технические проблемы с любыми проектами, связанными с Оболом, зайдите в наш [Discord](https://discord.gg/n6ebKsX46w), где будет присутствовать член нашей команды или сообщества. рады помочь вам. diff --git a/i18n/ru/docusaurus-plugin-content-docs/current/sc/01_introducing-obol-managers.md b/i18n/ru/docusaurus-plugin-content-docs/current/sc/01_introducing-obol-managers.md new file mode 100644 index 0000000000..956da14a97 --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/current/sc/01_introducing-obol-managers.md @@ -0,0 +1,61 @@ +--- +description: Как сеть Obol выглядит в сети? +--- + +# Смарт-контракты Obol + +Obol разрабатывает и поддерживает набор смарт-контрактов для использования с распределенными валидаторами. + +## Участники вывода средств + +Ключом к распределенному валидатору является понимание того, как обрабатывается вывод средств. Самый распространенный способ обработки вывода валидатора, управляемого несколькими разными людьми, — это использовать неизменяемый контракт получателя вывода с жестко закодированными в нем правилами распределения. + +For the time being Obol uses `0x01` withdrawal credentials, and intends to upgrade to [0x03 withdrawal credentials](https://ethresear.ch/t/0x03-withdrawal-credentials-simple-eth1-triggerable-withdrawals/10021) when smart contract initiated exits are enabled. +В настоящее время Obol использует учетные данные для вывода `0x01` и намеревается перейти на [учетные данные для вывода 0x03](https://ethresear.ch/t/0x03-withdrawal-credentials-simple-eth1-triggerable-withdrawals/10021), будут включены смарт-контрактом. + +### Собственный получатель вывода средств + +```solidity title="WithdrawalRecipientOwnable.sol" +// SPDX-License-Identifier: MIT + +pragma solidity ^0.8.0; + +import "@openzeppelin/contracts/access/Ownable.sol"; + +contract WithdrawalRecipientOwnable is Ownable { + receive() external payable {} + + function withdraw(address payable recipient) public onlyOwner { + recipient.transfer(address(this).balance); + } +} + +``` + +Собственный получатель вывода средств — это самый простой тип контракта с получателем вывода средств. Он реализует интерфейс Open Zeppelin `Ownable` и позволяет одному адресу вызывать функцию `withdraw()`, которая вытягивает весь эфир с адреса на адрес владельца (или другой указанный адрес). Вызов вывода также может финансировать разделение платы на сеть Obol и / или протокол, который развернул и создал этот DV. + +### Неизменяемый получатель вывода средств + +Неизменный получатель вывода аналогичен получателю, которым можно владеть, за исключением того, что владелец жестко запрограммирован во время создания, а возможность смены владельца удалена. Этот контракт следует использовать только как часть более крупной системы смарт-контрактов, например, стратегия хранилища yearn может использовать неизменяемый контракт получателя, поскольку его адрес хранилища никогда не должен меняться. + +## Реестры + +### Реестр депозитов + +Депозитный реестр позволяет сделать депозит и активацию распределенных валидаторов двумя отдельными процессами. В простом случае для DV регистр депозитов не требуется. Однако, когда лицо, вносящее эфир, не является той же организацией, что и операторы, производящие депозиты, необходим механизм координации, чтобы убедиться, что на каждый DV отправляется только один депозит в 32 eth. Реестр депозитов может предотвратить двойные депозиты, отдав распоряжение о выделении эфира депозитам валидаторов. + +### Реестр операторов + +Если подача депозитов в реестр депозитов должна ограничиваться только адресами из белого списка, простой реестр операторов может служить способом контроля того, кто может подавать депозиты в реестр депозитов. + + +### Реестр валидаторов + +Если необходимо управлять валидаторами в цепочке программно, а не вручную, когда люди инициируют выход, можно использовать реестр валидаторов. Депозиты, которые активируются, получают запись в реестре валидаторов, а валидаторы, использующие выходы 0x03, готовятся к удалению из реестра. Этот реестр можно использовать для координации множества валидаторов с похожими операторами и конфигурацией. + +:::note + +Реестры валидаторов зависят от еще не реализованной фичи выхода валидатора `0x03`. + +::: + diff --git a/i18n/ru/docusaurus-plugin-content-docs/current/sc/_category_.json b/i18n/ru/docusaurus-plugin-content-docs/current/sc/_category_.json new file mode 100644 index 0000000000..035b376e43 --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/current/sc/_category_.json @@ -0,0 +1,5 @@ +{ + "label": "Смарт-контракты", + "position": 5, + "collapsed": true +} diff --git a/i18n/ru/docusaurus-plugin-content-docs/current/testnet.md b/i18n/ru/docusaurus-plugin-content-docs/current/testnet.md new file mode 100644 index 0000000000..ed5d5709f6 --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/current/testnet.md @@ -0,0 +1,188 @@ +--- +sidebar_position: 13 +--- + +# Тестовые сети + +![Карта развития тестовых сетей](/img/ObolTestnetRoadmap.png) + +В ближайшие кварталы Obol Labs будет координировать и будет продолжать координировать и размещать ряд все более крупных тестовых сетей, чтобы помочь укрепить клиент charon и отрабатывать инструменты генерации ключей. + +Ниже приводится представление намеченной дорожной карты тестовой сети, функций, которые должны быть реализованы каждой тестовой сетью, а также их дата начала и продолжительность. + +# Тестовые сети + +- [x] [Dev Net 1](#devnet-1) +- [x] [Dev Net 2](#devnet-2) +- [ ] [Athena Public Testnet 1](#athena-public-testnet-1) +- [ ] [Bia Attack net](#bia-attack-net) +- [ ] [Circe Public Testnet 2](#cerce-public-testnet-ii) +- [ ] [Demeter Red/Blue net](#demeter-redblue-net) + +## Devnet 1 + +Первая тестовая сеть была нацелена на то, чтобы несколько доверенных операторов протестировали наши самые ранние обучающие руководства. Цель состояла в том, чтобы один пользователь выполнил эти руководства в одиночку, используя docker compose для запуска 4 клиентов charon и 4 разных клиентов валидатора (lighthouse, teku, lodestar и vouch) на одной машине с удаленным клиентом консенсуса. Ключи были созданы локально в charon и активированы с помощью существующей панели запуска. + + +**Участники:** Obol Dev Team, Client team advisors. + +**Состояние продукта:** Предварительный продукт + +**Сеть:** Kiln + +**Дата завершения:** Июнь 2022 + +**Продолжительность:** 1 неделя + +**Цели:** + +- Пользователь протестировал первое руководство на работоспособность. Devnet 2 будет групповым, поэтому нам нужно сначала правильно настроить одиночный запуск +- Подтвердить парадигму распределенного валидатора с 4 отдельными реализациями VC, работающими вместе, как один логический валидатор +- Получить основы мониторинга для следующей тестовой сети, где точный мониторинг будет важен при работе по сети. + +**Собранные данные с операторов:** + +- Заполняя форму, оператор перечисляет: + - Открытый ключ распределенного валидатора + - Любые трудности, с которыми он столкнулся при создании экземпляра кластера + - Любые варианты развертывания, для которых они хотели бы увидеть раннюю поддержку (например, Windows, cloud, dappnode и т.д.) + + +## Devnet 2 + +Вторая сеть разработчиков была нацелена на то, чтобы несколько доверенных операторов впервые протестировали наши самые ранние руководства _вместе_. + +Цель состояла в том, чтобы группы из 4 тестировщиков завершили групповое руководство, используя docker compose для запуска 4 клиентов charon и 4 различных клиентов валидаторов (lighthouse, teku, lodestar и vouch), каждый на своей домашней машине или на той которую они выбрали, запускает хотя бы консенсус клиента Kiln. + +В рамках этой тестовой сети операторы избегали использование charon в Интернет сети со статическим IP-адресом за счет использования узлов ретрансляции, размещенных на Obol. + +Этот devnet также впервые был протестирован с пользователями `charon dkg`. Панель запуска не использовалась, и этот dkg был вызван конфигурационным файлом манифеста, созданным локально одним оператором с помощью команды `charon create dkg`. + +Основной задачей этой сети разработчиков был сбор данных о производительности сети. Это был первый раз, когда charon запускался в невиртуальных сетях (то есть в реальном Интернете). Основное внимание было сосредоточено на эффективном сборе данных, на производительности в этой сети разработчиков, чтобы обеспечить сбор еще более глубоких данных о производительности сигнала при масштабировании в общедоступных тестовых сетях. + +**Участники:** Obol Dev Team, Client team advisors. + +**Состояние продукта:** Предварительный продукт + +**Сеть:** Kiln + +**Дата завершения:** Июль 2022 + +**Duration:** 2 недели + +**Цели:** + +- Пользовательское тестирование метода dkg +- Пользовательское тестирование сложности предоставления доступа к charon в общедоступном Интернете +- Размещение предложений по блокам +- Создание аналитической системы для внедрения сетевых трассировок из файлов дампа или конечных точек распределенной трассировки + + +## Athena Public Testnet 1 + +С учебными пособиями для соло и групповых вариантов, которые были разработаны и усовершенствованы. Цель первой общедоступной тестовой сети — впервые передать распределенные валидаторы в руки более широкого сообщества Proto. + +Основное внимание в этой тестовой сети уделяется опыту адаптации. Это первый раз, когда нам нужно предоставить исчерпывающие инструкции для максимально возможного количества платформ (Unix, Mac, Windows) на максимально возможном количестве языков (необходимо привлекать языковых модераторов в Discord). + +Основным результатом этой тестовой сети является большое количество принятых форм обратной связи, которую мы усовершенствовали со времен devnets 1 и 2. + +Это будет нестимулированная тестовая сеть, и она послужит основой для выяснения механизма сопротивления Sybil для более поздних стимулированных тестовых сетей. + +**Участники:** Obol Proto Community + +**Состояние продукта:** Абсолютный минимум + +**Сеть:** Görli + +**Намеченная дата запуска:** Август 2022 + +**Продолжительность:** 2 недели настройка кластера, 4 недели эксплуатации + +**Цели:** + +- Задействовать сообщество Obol Proto +- Сделать развертывание узлов валидатора Ethereum доступным +- Собрать большой бэклог ошибок, предложения по улучшению, добавлению, интеграции для платформы. + +**Форма регистрации:** [Перейти](https://obol.typeform.com/AthenaTestnet) + +## Bia Attack Net + +На данный момент мы максимально протестировали валидацию и подобрали правильный путь с поддерживающими участниками. Следующий шаг к клиенту, готовому к основной сети, — начать разрушать и подрывать его, насколько это возможно. + +Эта тестовая сеть нуждается в согласованной реализации в качестве жесткого требования, тогда как для Athena это могло быть необязательным. Намерение состоит в том, чтобы создать ряд инструментов тестирования, чтобы облегчить разрушение charon, включая выпуск нарушителя сети p2p, клиента фазз-тестирования, скриптов k6 для нагрузочного тестирования / взлома конечных точек RPC и многое другое. + +Цель состоит в том, чтобы найти как можно больше утечек памяти, уязвимых конечных точек и операций DoS, отсутствующих проверок подписи и многого другого. Эта тестовая сеть может быть сосредоточена вокруг хакатона, если это уместно. + +**Участники:** Obol Proto Community, Immunefi Bug Bounty searchers + +**Состояние продукта:** Улучшение клиентов сети + +**Намеченная дата запуска:** Сентябрь 2022 + +**Продолжительность:** 2-4 недели эксплуатации, в зависимости от того, насколько устойчивы клиенты + +**Сеть:** Merged Test Network (e.g. Görli) + +**Цели:** + +- Найти уязвимости Charon несколькими путями +- Улучшить защиту от DoS атак + +## Cerce Public Testnet II + +После работы над уязвимостями, которые, как мы надеемся, всплыли во время атаки сети, настало время поднять ставки на ступеньку выше. Вторая публичная тестовая сеть для Obol будет создана в партнерстве с Gnosis Chain и будет использовать реальных действующих валидаторов. + +Предполагается, что это будет первый раз, когда токенизация распределенного валидатора вступит в игру. Obol намеревается позволить операторам-кандидатам формировать группы, создавать ключи, указывающие на предварительно определенные адреса вывода средств, контролируемые Obol, и отправлять фидбек в виде формы нашей команде тестовой сети, включая созданные данные депозита, файл блокировки манифеста и данные выхода. (Таким образом, мы можем проверить, что публичный ключ валидатора, который они отправляют, является DV) + +Как только команда тестовой сети подтвердит, что операторы являются реальными людьми, а не сибилами (Sybil), атакующими тестовую сеть, которая создала законные ключи DV, их валидатор будет активирован с помощью Obol GNO. + +В конце периода тестовой сети все валидаторы будут отключены, и их производительность будет оцениваться для определения поощрения, которое они получат. + +**Участники:** Obol Proto Community, Gnosis Community, Ethereum Staking Community + +**Состояние продукта:** MVP ( стадия разработки минимума для работы продукт ) + +**Сеть:** Merged Gnosis Chain + +**Намеченная дата запуска:** Q4 2022 + +**Продолжительность:** 6 недель + +**Network:** Merged Gnosis Chain + +**Цели:** + +- Широкое участие сообщества +- Первая поощраемая тестовая сеть Obol +- Распределенный валидатор возвращает конкурентные клиенты по сравнению с одиночными валидаторами. +- Запустить неоправданно большой процент поощраемой тестовой сети, чтобы увидеть производительность сети в масштабе, если большинство валидаторов перейдут на архитектуру DV. + +## Demeter Red/Blue Net + +Последняя запланированная тестовая сеть перед предполагаемым развертыванием основной сети — это тестовая сеть, которая черпает вдохновение в индустрии кибербезопасности и использует Red Teams и Blue Teams. + +В кибербезопасности красная команда находится в нападении, а синяя команда в защите. В случае Obol, Операторы будут сгруппированы в кластеры в зависимости от приложения и тайно назначены либо в красную, либо в синюю команду. После того, как валидаторы активны, целью красных команд будет разрушение кластера в меру своих возможностей, а их вознаграждение будет зависеть от того, насколько кластер работает хуже оптимального. + +Члены синей команды будут стремиться поддерживать свой кластер в сети и подписываться. Если они смогут держать свой распределенный валидатор в сети большую часть времени, несмотря на все усилия красной команды, они получат слишком большую награду по сравнению с наградой красной команды. + +Цель этой тестовой сети — показать, что даже при наличии прямого стимулирования византийских участников клиент распределенного валидатора может оставаться в сети и своевременно проходить проверку, что еще больше укрепляет доверие к готовности основной сети клиентов. + +**Участники:** Obol Proto Community, Gnosis Community, Ethereum Staking Community, Immunefi Bug Bounty searchers + +**Состояние продукта:** Основная сеть готова + +**Network:** Merged Gnosis Chain + +**Target start date:** Q4 2022 + +**Duration:** 4 недели + +**Сеть:** Merged Gnosis Chain + +**Цели:** + +- Даже при наличии мотивированных византийских участниках распределенные валидаторы могут надежно оставаться в сети. +- Узлы Charon не могут быть атакованы DoS'ом. +- Продемонстрировать, что отказоустойчивая проверка реальна, безопасна и конкурентоспособна по стоимости. +- Функция Charon завершена и готова к аудиту diff --git a/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/dv/01_introducing-charon.md b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/dv/01_introducing-charon.md new file mode 100644 index 0000000000..6d40906743 --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/dv/01_introducing-charon.md @@ -0,0 +1,28 @@ +--- +description: Charon — клиент распределенного валидатора +--- + +# Представляем Charon + +В этом разделе представлено промежуточное ПО Charon. Дополнительный контекст, касающийся технологии распределенного валидатора, см. в [этом разделе](../int/key-concepts#distributed-validator) на странице ключевых концепций. + +### Что такое Charon? + +Charon — это промежуточное программное обеспечение HTTP на основе GoLang, созданное Obol для того, чтобы любые существующие клиенты валидатора Ethereum могли работать вместе как часть распределенного валидатора. + +Charon является промежуточным программным обеспечением между обычным проверяющим клиентом и подключенным к нему узлом-маяком, перехватывая и проксируя трафик API. Несколько клиентов Charon настроены на совместное общение, чтобы прийти к консенсусу в отношении обязанностей валидатора и вести себя как единый унифицированный валидатор Proof-of-Stake. Узлы образуют кластер, который является _устойчивым к byzantine-fault_ и продолжает развиваться при условии, что встречается подавляющее большинство рабочих/честных узлов. + +### Архитектура Charon +На приведенном ниже рисунке визуально показаны внутренние функции Charon. + +![Слайд внутренних компонентов Charon](/img/CharonInternals.png) + +### Как начать + +Клиент `charon` находится в ранней альфа-версии и не готов к основной сети, см. [здесь](https://github.com/ObolNetwork/charon#supported-consensus-layer-clients) последнюю информацию о готовности charon. + +``` +docker run ghcr.io/obolnetwork/charon:v0.8.1 --help +``` + +Для получения дополнительной информации о запуске charon обратитесь к нашему [краткому руководству](../int/quickstart/index.md). \ No newline at end of file diff --git a/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/dv/02_validator-creation.md b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/dv/02_validator-creation.md new file mode 100644 index 0000000000..b8d7de0805 --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/dv/02_validator-creation.md @@ -0,0 +1,31 @@ +--- +description: Создание кластера Distributed Validator с нуля +--- + +# Создание распределенного валидатора + +![Пример кластера Distributed Validator](/img/ObolCluster.png) + +### Этапы создания распределенного валидатора + +Чтобы создать распределенный кластер валидаторов, вам и вашей группе операторов необходимо выполнить следующие шаги: + +1. Один оператор начинает установку кластера [Distributed Validator Launchpad](../dvk/02_distributed_validator_launchpad.md). + - Это включает в себя настройку всех условий для кластера, в том числе; адрес вывода средств, получатель комиссии, количество валидаторов, адреса операторов и т. д. Эта информация известна как *конфигурация кластера*. + - Этот оператор также устанавливает запись узла Ethereum своего клиента charon. ([ENR](../int/faq.md#what-is-an-enr)). + - Этот оператор подписывает как хэш конфигурации кластера, так и ENR, чтобы подтвердить право собственности на свой адрес. + - Эти данные хранятся на уровне данных DV Launchpad, и создается общий URL-адрес. Это ссылка для других операторов, чтобы присоединиться и завершить церемонию. +2. Другие операторы в кластере следуют этому URL-адресу на панель запуска. + - Они рассматривают условия конфигурации кластера. + - Они представляют ENR своего клиента charon. + - Они подписывают как хэш конфигурации кластера, так и свой charon ENR, чтобы принять условия. +3. После того как все операторы представили подписи для конфигурации кластера и ENR, все они могут загрузить файл определения кластера. +4. Каждый оператор передает этот файл определения кластера команде `charon dkg`. Определение предоставляет процессу charon информацию, необходимую для поиска и завершения церемонии DKG с другими вовлеченными клиентами charon. +5. Как только все клиенты charon смогут общаться друг с другом, процесс DKG завершается. Все операторы в итоге имеют: + - Файл `cluster-lock.json`, который содержит исходные данные конфигурации кластера в сочетании с недавно сгенерированными открытыми ключами группы и связанными с ними общими общими ключами. Этот файл необходим команде `charon run`. + - Данные депозита валидатора + - Приватный ключ валидатора +6. Теперь операторы могут создавать резервные копии сгенерированных общих ключей, своего закрытого ключа ENR, если они еще этого не сделали, и файла `cluster-lock.json`. +7. Все операторы загружают ключи и файлы блокировки кластера, сгенерированные на церемонии, в свое окружение. +8. Операторы могут запустить тест производительности настроенного кластера, чтобы убедиться, что связь между всеми операторами наблюдается с разумной задержкой. +9. После того, как все тесты на готовность пройдены, один оператор активирует распределенный валидатор(ы) с депозитом в цепочке. diff --git a/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/dv/04_middleware-daemon.md b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/dv/04_middleware-daemon.md new file mode 100644 index 0000000000..b3fff9cd4e --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/dv/04_middleware-daemon.md @@ -0,0 +1,15 @@ +--- +description: Архитектура развертывания для клиента распределенного валидатора +--- + +# Архитектура промежуточного программного обеспечения + +

+ +Демон Charon является промежуточным программным обеспечением между [API узла маяка](https://ethereum.github.io/beacon-APIs/) уровня консенсуса и любыми нижестоящими клиентами валидатора. + +### Цель + +Промежуточное программное обеспечение стремится быть без состояния (stateless) и статически настроенным через файловые системы 777. Отсутствие API-интерфейса уровня управления для онлайн-реконфигурации преднамеренно сделано для того, чтобы по умолчанию операции были простыми и безопасными. + +Первоначально пакет `charon` будет доступен в виде образа Docker и в виде бинарных сборок. Планируется пакет APT с интеграцией systemd. diff --git a/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/dv/06_peer-discovery.md b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/dv/06_peer-discovery.md new file mode 100644 index 0000000000..b9f8acd99c --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/dv/06_peer-discovery.md @@ -0,0 +1,37 @@ +--- +description: Как распределенные клиенты валидатора безопасно взаимодействуют друг с другом? +--- + +# Взаимодействие клиентов валидатора + +Чтобы поддерживать безопасность и устойчивость к sybil (sybil-resistance), клиенты charon должны иметь возможность аутентифицировать друг друга. Мы достигаем этого, предоставляя каждому клиенту charon пару открытого/закрытого ключа, которую они могут подписывать таким образом, чтобы другие клиенты в кластере могли распознавать их как законных, независимо от того, с какого IP-адреса они общаются. + +В конце [церемонии DKG](./02_validator-creation.md#stages-of-creating-a-distributed-validator) каждый оператор будет иметь количество файлов, полученных их клиентом charon, в зависимости от того, сколько распределенных валидаторов группа решила генерировать вместе. + +О файлах: + +- **Validator keystore(s):** Эти файлы будут загружены в клиент валидатора оператора, и каждый файл представляет одну долю распределенного валидатора. +- **A distributed validator cluster lock file:** Этот файл `cluster-lock.json` содержит конфигурацию, необходимую клиенту распределенного валидатора, такому как charon, для присоединения к кластеру, способному работать с несколькими распределенными валидаторами. +- **Validator deposit data:** Этот файл используется для активации одного или нескольких распределенных валидаторов в сети Ethereum. + +### Аутентификация клиента распределенного валидатора + +Прежде чем начнется процесс DKG, все операторы должны запустить «charon create enr» или просто «charon enr», чтобы создать или получить запись узла Ethereum для своего клиента. Эти ENR включены в конфигурацию церемонии генерации распределенного ключа. + +Файл, описывающий церемонию DKG, известен как файл [`cluster-definition`](./08_distributed-validator-cluster-manifest.md). Этот файл передается `charon dkg`, который использует его для создания закрытых ключей, файла блокировки кластера и хранения данных для настроенного количества распределенных валидаторов. Файл блокировки кластера будет доступен для `charon run`, а хранилища ключей валидатора будут доступны настроенному клиенту валидатора. + +Когда `charon run` запускается и получает свою конфигурацию из файла `cluster-lock.json`, он проверяет, отличается ли наблюдаемый/настроенный общедоступный IP-адрес от того, что указано в файле блокировки. Если он другой; он обновляет IP-адрес, увеличивает одноразовый номер ENR и повторно выдает его, прежде чем начать устанавливать соединения с другими операторами в кластере. + +#### База данных узла + +Распределенные кластеры валидаторов — это разрешенные сети с полносвязной топологией. Каждый узел будет постоянно хранить ENR всех других известных узлов Obol в своей базе данных узлов. + +В отличие от баз данных узлов общедоступных сетей без разрешения (таких как [Go-Ethereum](https://pkg.go.dev/github.com/ethereum/go-ethereum@v1.10.13/p2p/enode#DB)), здесь нет встроенной логики вытеснения — база данных будет расти бесконечно. Это приемлемо, поскольку ожидается, что количество операторов в кластере останется постоянным. Изменяемые кластерные операторы будут введены в будущем. + +#### Поиск узла + +При загрузке клиент charon загрузит настроенный файл `cluster-lock.json`. Этот файл содержит список ENR пиров клиента. Клиент попытается установить соединение с этими одноранговыми узлами и выполнит рукопожатие, если они подключатся, чтобы установить сквозной зашифрованный канал связи между клиентами. + +Однако IP-адреса в ENR могут устареть. Это может привести к тому, что кластер не сможет установить соединение со всеми узлами. Чтобы быть терпимым к изменению IP-адресов операторов, charon также поддерживает протокол обнаружения [discv5](https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md). Это позволяет клиенту charon найти другого оператора, который мог изменить IP-адрес, но при этом сохранил тот же закрытый ключ ENR. + + diff --git a/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/dv/07_p2p-interface.md b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/dv/07_p2p-interface.md new file mode 100644 index 0000000000..1fff526bff --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/dv/07_p2p-interface.md @@ -0,0 +1,13 @@ +--- +description: Связь между экземплярами Charon +--- + +# P2P интерфейс + +P2P-интерфейс Charon примерно соответствует [Eth2 beacon P2P interface](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md). + +- Метод общения: TCP over IPv4/IPv6. +- Идентификация: [Ethereum Node Records](https://eips.ethereum.org/EIPS/eip-778). +- Рукопожатие: [noise-libp2p](https://github.com/libp2p/specs/tree/master/noise) с `secp256k1` ключами. + - Каждый клиент charon должен иметь открытый ключ ENR, авторизованный в [cluster-lock.json](./08_distributed-validator-cluster-manifest.md) файл, чтобы рукопожатие клиента прошло успешно. +- Протокол обнаружения: [Discv5](https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md). diff --git a/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/dv/08_distributed-validator-cluster-manifest.md b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/dv/08_distributed-validator-cluster-manifest.md new file mode 100644 index 0000000000..f18010e88b --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/dv/08_distributed-validator-cluster-manifest.md @@ -0,0 +1,66 @@ +--- +description: Документирование распределенного кластера валидатора в стандартизированном формате файла +--- + +# Конфигурация кластера + +:::caution +Эти файлы определения кластера и блокировки кластера находятся в стадии разработки. Цель состоит в том, чтобы файлы были стандартизированы для работы распределенных валидаторов через [процесс EIP](https://eips.ethereum.org/), когда это необходимо.. +::: + +В этом документе описываются параметры конфигурации для запуска клиента charon (или кластера) локально или в рабочей среде. + +## Файлы конфигурации кластера + +Кластер charon настраивается в два этапа: +- `cluster-definition.json` который определяет предполагаемую конфигурацию кластера до того, как ключи будут созданы на церемонии распределенного генерирования ключей. +- `cluster-lock.json` который включает в себя и расширяет `cluster-definition.json` с распределенными общими ключами BLS валидатора. + +Команда `charon create dkg` используется для создания файла `cluster-definition.json`, который используется в качестве входных данных для «charon dkg». + +Команда `charon create cluster` объединяет оба шага в один и просто выводит окончательный файл `cluster-lock.json` без шага DKG. + +Схема `cluster-definition.json` определяется как: +```json +{ + "name": "best cluster", // Опционально, косметический идентификатор + "operators": [ + { + "address": "0x123..abfc", // ETH1 адрес оператора + "enr": "enr://abcdef...12345", // ENR Charon узла + "nonce": 1, // Nonce (увеличивается каждый раз, когда ENR добавляется/подписывается) + "config_signature": "123456...abcdef", // EIP712 Подпись config_hash по приватному ключу адреса ETH1 + "enr_signature": "123654...abcedf" // EIP712 Подпись ENR по приватному ключу адреса ETH1 + } + ], + "uuid": "1234-abcdef-1234-abcdef", // Случайный уникальный идентификатор. + "version": "v1.0.0", // Версия схемы + "num_validators": 100, // Количество распределенных валидаторов кластера, которые будут созданы в cluster.lock + "threshold": 3, // Опционально, порог необходимый для восстановления подписи + "fee_recipient_address":"0x123..abfc", // ETH1 адрес получателя вознаграждения + "withdrawal_address": "0x123..abfc", // ETH1 адрес вывода + "dkg_algorithm": "foo_dkg_v1" , // Опционально, алгоритм DKG для генерации ключей + "fork_version": "0x00112233", // Идентификатор цепи/сети + "config_hash": "abcfde...acbfed", // Хэш статических (неизменяемых) полей + "definition_hash": "abcdef...abcedef" // Окончательный хэш всех полей +} +``` + +Приведенный выше файл `cluster-definition.json` предоставляется в качестве входных данных для DKG, который генерирует ключи и файл `cluster-lock.json`. + + +Файл `cluster-lock.json` имеет схему: +```json +{ + "cluster_definition": {...}, // Определение кластера json, схема идентична приведенной выше., + "distributed_validators": [ // Длина равная num_validators. + { + "distributed_public_key": "0x123..abfc", // Корневой открытый ключ DV + "public_shares": [ "oA8Z...2XyT", "g1q...icu"], // Совместно используемые открытые ключи + "fee_recipient": "0x123..abfc" // Адрес по умолчанию для вывода средств, если он не установлен, может быть отредактирован вручную + } + ], + "lock_hash": "abcdef...abcedef", // Config_hash + distributed_validators + "signature_aggregate": "abcdef...abcedef" // Совокупная подпись BLS хэша блокировки, подписанного каждым открытым ключом DV. +} +``` diff --git a/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/dv/09_charon_cli_reference.md b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/dv/09_charon_cli_reference.md new file mode 100644 index 0000000000..8794e552d6 --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/dv/09_charon_cli_reference.md @@ -0,0 +1,201 @@ +--- +description: Клиент промежуточного программного обеспечения на основе go для участия в кластерах Distributed Validator. +--- + +# CLI интерфейс Charon + +:::caution + +Клиент `charon` находится в стадии интенсивной разработки, интерфейсы могут быть изменены, пока не будет опубликована первая основная версия. + +::: + +Ниже приведена ссылка на версию charon [`v0.8.1`](https://github.com/ObolNetwork/charon/releases/tag/v0.8.1). Найдите последнюю версию в [нашем Github](https://github.com/ObolNetwork/charon/releases). + +### Доступные команды + +Ниже приведены команды верхнего уровня, доступные для использования. + +```markdown +charon help +Charon обеспечивает отказоустойчивую работу валидаторов Ethereum, разделяя ключи проверки на группу доверенных сторон с использованием пороговой криптографии. + +Usage: + charon [command] + +Available Commands: + bootnode Запуск загрузочного сервера diskv5 + completion Сгенерировать скрипт автозаполнения для указанной оболочки + create Создание артефактов для кластера распределенного валидатора + dkg Принять участие в церемонии генерации распределенного ключа + enr Вывести запись узла Ethereum этого клиента (ENR) + help Справка по любой команде + run Запуск промежуточного клиента программного обеспечения charon + version Вывести версию клиента + +Flags: + -h, --help Справка по командам Charon + +Используйте "charon [command] --help" для получения дополнительной информации о команде. +``` + +### Вспомогательная команда `create` + +Вспомогательная команда `create` управляет созданием артефактов, необходимых charon для работы. + +```markdown +charon create --help +Создайте артефакты для кластера распределенного валидатора. Эти команды можно использовать для облегчения создания распределенного кластера валидатора между группой операторов путем выполнения церемонии генерации распределенного ключа, или их можно использовать для создания локального кластера для случаев использования одного оператора. + +Usage: + charon create [command] + +Available Commands: + cluster Создать закрытые ключи и файлы конфигурации, необходимые для локального запуска кластера распределенного валидатора + dkg Создать конфигурацию для новой церемонии генерации распределенного ключа, используя charon dkg + enr Создать закрытый ключ Ethereum Node Record (ENR), чтобы идентифицировать этого клиента charon. + +Flags: + -h, --help Дополнительная информация о команде + +Используйте `charon create [command] --help` для получения дополнительной информации о команде. + +``` + +#### Создание ENR в charon + +`enr` — это запись узла Ethereum. Он используется для идентификации этого клиента charon для других клиентов-контрагентов charon через Интернет. + +```markdown +charon create enr --help +Создать закрытый ключ Ethereum Node Record (ENR) для идентификации этого клиента charon + +Usage: + charon create enr [flags] + +Flags: + --data-dir string Каталог, в котором charon будет хранить все свои внутренние данные (default ".charon") + -h, --help Дополнительная информация о команде enr + --p2p-allowlist string Разделенный запятыми список подсетей CIDR для разрешения только определенных одноранговых соединений. Пример: 192.168.0.0/16 разрешает подключения к одноранговым узлам только в вашей локальной сети. По умолчанию принимаются все соединения. + --p2p-bootnode-relay Позволяет использовать загрузочные узлы в качестве реле цепи libp2p. Полезно, если некоторые узлы charon недоступны публично. + --p2p-bootnodes strings Разделенный запятыми список URL-адресов или ENR загрузочных узлов diskv5. (по умолчанию [http://bootnode.gcp.obol.tech:3640/enr]) + --p2p-bootnodes-from-lockfile Позволяет использовать ENR блокировки кластера в качестве загрузочных узлов diskv5. Позволяет пропускать явные загрузочные узлы, если церемония генерации ключей включала правильные IP-адреса. + --p2p-denylist string Разделенный запятыми список подсетей CIDR для запрета определенных одноранговых соединений. Пример: 192.168.0.0/16 запретит соединения с одноранговыми узлами в вашей локальной сети. По умолчанию принимаются все соединения. + --p2p-external-hostname string DNS-имя хоста, объявленное libp2p. Может использоваться для объявления внешнего DNS. + --p2p-external-ip string IP-адрес, объявленный libp2p. Может использоваться для внешнего IP-адреса. + --p2p-tcp-address strings Разделенный запятыми список прослушиваемых TCP-адресов (ip и порт) для трафика libP2P. (по умолчанию [127.0.0.1:3610]) + --p2p-udp-address string Прослушивание UDP-адреса (ip и порт) для обнаружения diskv5. (по умолчанию "127.0.0.1:3630") +``` + +#### Создание полный кластер локально + +`charon create cluster` локально создает набор распределенных валидаторов, включая закрытые ключи, файл `cluster.lock`, а также данные депозита и выхода. Однако эту команду следует использовать только для одиночного использования распределенных валидаторов. Для запуска распределенного валидатора с группой операторов предпочтительно создавать эти артефакты с помощью команды charon dkg. Таким образом, ни один оператор не хранит все закрытые ключи в распределенном валидаторе. + +```markdown +charon create cluster --help +Создает локальную конфигурацию кластера charon, включая ключи валидатора, p2p-ключи charon, cluster-lock.json и Deposit-data.json. Смотрите флаги для поддерживаемых функций. + +Usage: + charon create cluster [flags] + +Flags: + --clean Удалить каталог кластера перед его созданием. + --cluster-dir string Целевая папка для создания кластера (по умолчанию ".charon/cluster") + -h, --help Дополнитальная информация о команде + --network string Сеть Ethereum для создания валидаторов. Варинты: mainnet, prater, kintsugi, kiln, gnosis. (default: "prater") + -n, --nodes int Количество узлов charon в кластере. (default 4) + --split-existing-keys Разделить существующий закрытый ключ валидатора на набор распределенных общих ключей валидатора. Не создает повторно данные депозита для этого ключа. + --split-keys-dir string Каталог, содержащий ключи для разделения. Ожидает ключи в keystore-*.json and passwords in keystore-*.txt. Требует --split-existing-keys. + -t, --threshold int Порог, необходимый для восстановления подписи. Минимум это n-(ceil(n/3)-1). (default 3) + --withdrawal-address string Адрес Ethereum для получения возвращенной ставки и начисленных вознаграждений. (default "0x0000000000000000000000000000000000000000") +``` + +#### Создание конфигурации для DKG Ceremony + +Эта команда `charon create dkg` создает файл cluster_definition, используемый для команды `charon dkg`. + +```markdown +charon create dkg --help +Создайте файл определения кластера, который будет использоваться всеми участниками DKG. + +Usage: + charon create dkg [flags] + +Flags: + --dkg-algorithm string Используемый алгоритм DKG; default, keycast, frost (default "default") + --fee-recipient-address string Необязательный адрес Ethereum получателя комиссии + -h, --help Дополнитальная информация о команде + --name string Необязательное имя косметического кластера + --network string Сеть Ethereum для создания валидаторов. Options: mainnet, prater, kintsugi, kiln, gnosis. (default "prater") + --num-validators int Количество распределенных валидаторов, которыми будет управлять кластер (по 32ETH на каждого). (по умолчанию 1) + --operator-enrs strings Разделенный запятыми список адресов Charon ENR каждого оператора + --output-dir string Папка, в которую будет записан выходной файл cluster-definition.json. (по умолчанию ".charon") + -t, --threshold int Порог, необходимый для восстановления подписи. Минимум n-(ceil(n/3)-1). (по умолчанию 3) + --withdrawal-address string Адрес для вывода Ethereum (default "0x0000000000000000000000000000000000000000") +``` + +### Проведение церемонии DKG + +Команда `charon dkg` использует файл `cluster_definition.json`, который указывает charon условия создания нового кластера распределенного валидатора. Charon устанавливает связь с другими узлами, указанными в файле, выполняет церемонию генерации распределенного ключа для создания необходимых пороговых закрытых ключей и подписывает данные депозита и выхода для каждого нового распределенного валидатора. Команда выводит файл `cluster.lock` и общий ключ для каждого созданного распределенного валидатора. + +```markdown +charon dkg --help +Примите участие в церемонии создания распределенного ключа для определенного определения кластера, в ходе которой создаются распределенные общие ключи валидатора и окончательная конфигурация блокировки кластера. Обратите внимание, что все остальные операторы кластера должны запускать эту команду одновременно. + +Usage: + charon dkg [flags] + +Flags: + --data-dir string Каталог, в котором charon будет хранить все свои внутренние данные (по умолчанию ".charon") + --definition-file string Путь к файлу определения кластера. (по умолчанию ".charon/cluster-definition.json") + -h, --help Дополнительная информация о dgk + --log-format string Формат журнала; console, logfmt или json (по умолчанию "console") + --log-level string Уровень журнала; debug, info, warn or error (по умолчанию "info") + --p2p-allowlist string Разделенный запятыми список подсетей CIDR для разрешения только определенных одноранговых соединений. Пример: 192.168.0.0/16 разрешает подключения к одноранговым узлам только в вашей локальной сети. По умолчанию принимаются все соединения. + --p2p-bootnode-relay Позволяет использовать загрузочные узлы в качестве реле цепи libp2p. Полезно, если некоторые узлы харона недоступны публично. + --p2p-bootnodes strings Разделенный запятыми список URL-адресов или ENR загрузочных узлов diskv5. (по умолчанию [http://bootnode.gcp.obol.tech:3640/enr]) + --p2p-bootnodes-from-lockfile Позволяет использовать ENR блокировки кластера в качестве загрузочных узлов diskv5. Позволяет пропускать явные загрузочные узлы, если церемония генерации ключей включала правильные IP-адреса. + --p2p-denylist string Разделенный запятыми список подсетей CIDR для запрета определенных одноранговых соединений. Пример: 192.168.0.0/16 запретит соединения с одноранговыми узлами в вашей локальной сети. По умолчанию принимаются все соединения. + --p2p-external-hostname string DNS-имя хоста, объявленное libp2p. Можно использовать для объявления внешнего DNS. + --p2p-external-ip string IP-адрес, объявленный libp2p. Можно использовать для внешнего IP-адреса. + --p2p-tcp-address strings Разделенный запятыми список прослушиваемых TCP-адресов (ip и порт) для трафика libP2P. (по умолчанию [127.0.0.1:3610]) + --p2p-udp-address string Прослушивание UDP-адреса (ip и порт) для обнаружения diskv5. (по умолчанию "127.0.0.1:3630") +``` + +### Запуск промежуточного ПО Charon + +Эта команда `run` принимает файл `cluster.lock`, который был создан с помощью команды `charon create cluster` или `charon dkg`. Этот файл блокировки описывает узлы в кластере и распределенные валидаторы, от имени которых они работают. + +```markdown +charon run --help +Запускает продолжительный процесс промежуточного программного обеспечения Charon для выполнения функций распределенного валидатора. + +Usage: + charon run [flags] + +Flags: + --beacon-node-endpoint string URL-адрес конечной точки узла маяка (по умолчанию "http://localhost/") + --data-dir string Каталог, в котором charon будет хранить все свои внутренние данные (по умолчанию ".charon") + --feature-set string Минимальный набор функций для включения по умолчанию: alpha, beta, или stable. Предупреждение: меняйте на свой страх и риск. (default "stable") + --feature-set-disable strings Разделенный запятыми список функций, которые нужно отключить, переопределяя минимальный набор функций по умолчанию. + --feature-set-enable strings Разделенный запятыми список функций для включения, переопределяющий минимальный набор функций по умолчанию. + -h, --help Дополнительная информация по команде run + --jaeger-address string Адрес прослушивания для трассировки jaeger + --jaeger-service string Имя службы, используемое для трассировки jaeger (по умолчанию "charon") + --lock-file string Путь к файлу блокировки кластера, определяющему кластер распределенного валидатора (по умолчанию «.charon/cluster-lock.json») + --log-format string Формат логов; console, logfmt или json (по умолчанию "console") + --log-level string Формат логов; debug, info, warn or error (по умолчанию "info") + --monitoring-address string Адрес прослушивания (ip и порт) для API мониторинга (prometheus, pprof) (по умолчанию "127.0.0.1:3620") + --p2p-allowlist string Разделенный запятыми список подсетей CIDR для разрешения только определенных одноранговых соединений. Пример: 192.168.0.0/16 разрешает подключения к одноранговым узлам только в вашей локальной сети. По умолчанию принимаются все соединения. + --p2p-bootnode-relay Позволяет использовать загрузочные узлы в качестве реле цепи libp2p. Полезно, если некоторые узлы charon недоступны публично. + --p2p-bootnodes strings Разделенный запятыми список URL-адресов или ENR загрузочных узлов diskv5. (по умолчанию [http://bootnode.gcp.obol.tech:3640/enr]) + --p2p-bootnodes-from-lockfile Позволяет использовать ENR блокировки кластера в качестве загрузочных узлов diskv5. Позволяет пропускать явные загрузочные узлы, если церемония генерации ключей включала правильные IP-адреса. + --p2p-denylist string Разделенный запятыми список подсетей CIDR для запрета определенных одноранговых соединений. Пример: 192.168.0.0/16 запретит соединения с одноранговыми узлами в вашей локальной сети. По умолчанию принимаются все соединения. + --p2p-external-hostname string DNS-имя хоста, объявленное libp2p. Можно использовать для объявления внешнего DNS. + --p2p-external-ip string IP-адрес, объявленный libp2p. Можно использовать для внешнего IP-адреса. + --p2p-tcp-address strings Разделенный запятыми список прослушиваемых TCP-адресов (ip и порт) для трафика libP2P. (по умолчанию [127.0.0.1:3610]) + --p2p-udp-address string Прослушивание UDP-адреса (ip и порт) для обнаружения diskv5. (по умолчанию "127.0.0.1:3630") + --simnet-beacon-mock Включает внутренний фиктивный узел-маяк для запуска simnet. + --simnet-validator-mock Включает внутренний фиктивный клиент валидатора при запуске simnet. Требуется simnet-beacon-mock. + --validator-api-address string Адрес прослушивания (IP-адрес и порт) для трафика, обращенного к валидатору, проксирующего API-узла-маяка (по умолчанию «127.0.0.1:3600») +``` diff --git a/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/dv/_category_.json b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/dv/_category_.json new file mode 100644 index 0000000000..2d1677c65f --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/dv/_category_.json @@ -0,0 +1,5 @@ +{ + "label": "Распределенные валидаторы", + "position": 3, + "collapsed": false +} diff --git a/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/dvk/01_distributed-validator-keys.md b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/dvk/01_distributed-validator-keys.md new file mode 100644 index 0000000000..e6cb337fe3 --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/dvk/01_distributed-validator-keys.md @@ -0,0 +1,122 @@ +--- +Description: >- + Для создания закрытых ключей для распределенного валидатора требуется церемония генерации распределенного ключа (DKG). +--- + +# Генерация ключей распределенного валидатора + +## Содержание + +- [Overview](#overview) +- [Actors involved](#actors-involved) +- [Cluster Definition creation](#cluster-definition-creation) +- [Carrying out the DKG ceremony](#carrying-out-the-dkg-ceremony) +- [Backing up ceremony artifacts](#backing-up-the-ceremony-artifacts) +- [Preparing for validator activation](#preparing-for-validator-activation) +- [DKG verification](#dkg-verification) +- [Appendix](#appendix) + +## Обзор + +Распределенный ключ валидатора — это группа закрытых ключей BLS, которые вместе действуют как пороговый ключ для участия в консенсусе Proof-of-Stake. +Чтобы сделать распределенный валидатор без отказоустойчивости (т. е. все узлы должны быть подключены к сети, чтобы подписать каждое сообщение), из-за схемы подписи BLS, используемой Proof of Stake Ethereum, каждый общий ключ может быть выбран операторами независимо. Однако для создания распределенного валидатора, который может оставаться в сети, несмотря на то, что подмножество его узлов отключается, общие ресурсы ключей необходимо генерировать вместе. (Не все 4 случайно выбранные точки на графике находятся на одной и той же кривой третьего порядка.) Чтобы сделать это безопасным способом, когда ни одна из сторон не доверяет распространение ключей, требуется так называемая церемония генерации распределенного ключа. + +Клиент charon несет ответственность за безопасное завершение церемонии генерации распределенного ключа со своими узлами-контрагентами. Конфигурация церемонии описана в [определении кластера](https://docs.obol.tech/docs/dv/distributed-validator-cluster-manifest). + +## Участники + +В церемонии генерации распределённых ключей участвуют `Операторы` и их `клиенты Charon`. + +- `Оператор` идентифицируется по адресу Ethereum. Они подпишутся закрытым ключом этого адреса, чтобы аутентифицировать своего клиента charon перед церемонией. Подпись будет; хэш открытого ключа ENR клиентов charon, `cluster_definition_hash` и увеличивающийся `nonce`, позволяющий установить прямую связь между пользователем, его клиентом charon и кластером, который этот клиент предназначен обслуживать, сохраняя при этом возможность обновить клиент charon, увеличив значение одноразового номера и переподписав его, как в стандартной спецификации ENR. + +`Клиент Charon` также идентифицируется парой открытого/закрытого ключа, в данном случае открытый ключ представлен как [Запись узла Ethereum](https://eips.ethereum.org/EIPS/eip-778) (ENR). Это стандартный формат идентификации как для клиентов EL, так и для клиентов CL. Эти ENR используются каждым узлом charon для идентификации одноранговых узлов кластера через Интернет и для связи друг с другом [сквозным шифрованием](https://github.com/libp2p/go-libp2p-noise). Эти ключи должны быть созданы каждым оператором, прежде чем они смогут участвовать в создании кластера. + +## Создание кластера + +Этот файл определения создается с помощью [панели запуска распределенного валидатора](https://docs.obol.tech/docs/dvk/distributed_validator_launchpad). Процесс создания включает в себя несколько шагов. + +- Оператор-лидер, желающий координировать создание нового кластера распределенных валидаторов, перейти на стартовую панель и выбрать "Create new Cluster" +- `Лидер` использует пользовательский интерфейс для настройки всех важных деталей кластера, включает: + - `Адрес вывода` для созданных валидаторов + - `feeRecipient` для предложений блокировки, если он отличается от адреса вывода. + - Количество распределенных валидаторов для создания + - Список участников кластера, указанный адресом Ethereum(/ENS) + - Требуемый порог отказоустойчивости (если не выбрано безопасное значение по умолчанию) + - Сеть (fork_version/chainId), в которой этот кластер будет проверяться +- Эти ключевые элементы информации составляют основу конфигурации кластера. Эти поля (и некоторые технические поля, такие как алгоритм DKG для использования) сериализуются для создания `cluster_definition_hash`. Этот корень merkle будет использоваться для подтверждения отсутствия двусмысленности или отклонения между определениями, когда они предоставляются узлам charon. +- Как только лидер удовлетворен в конфигурации, он публикует ее на уровне доступности данных панели запуска, чтобы другие участники могли получить к ней доступ. (На ранних стадиях разработки панель запуска будет использовать централизованную серверную базу данных для хранения конфигурации кластера. Вблизи производства такие решения, как IPFS или arweave, могут быть более подходящими для долгосрочной децентрализации панели запуска.) + +- Затем лидер поделится URL-адресом этой церемонии со своими предполагаемыми участниками. +- Любой, кто откроет URL-адрес церемонии или введет `cluster_definition_hash` при появлении запроса на целевой странице, будет перенаправлен на страницу статуса церемонии. (После заполнения всех заявлений об отказе от ответственности и рекомендаций) +- Кнопка "Connect Wallet" будет видна под контейнером статуса церемонии, участник может нажать на нее, чтобы подключить свой кошелек к сайту + - Если участник подключает кошелек, которого нет в списке участников, кнопка отключится. + - Если участник подключает кошелек, который находится в списке участников, ему предлагается ввести ENR своего узла charon. + - Если поле ENR заполнено и проверено, участник теперь может увидеть кнопку «Confirm Cluster Configuration». Эта кнопка запускает одну/две подписи. + - Участник подписывает `cluster_definition_hash`, чтобы доказать, что он согласен с этой конфигурацией. + - Участник подписывает ENR своего узла charon, чтобы аутентифицировать и авторизовать этот конкретный узел charon для участия от его имени в кластере распределенного валидатора. + - Эти/эта подпись отправляется на уровень доступности данных, где он проверяет правильность подписи для данного адреса участника в эфире. Если подписи проходят проверку, подпись хэша определения ENR + подпись сохраняются в объекте определения. +- Все участники в списке должны подписать хэш определения и отправить подписанный ENR до начала церемонии DKG. Неподтвержденные подписи можно легко отобразить на странице статуса. +- Наконец, после того, как все участники подписали свое одобрение и представили ENR узла charon, чтобы действовать от их имени, данные определения могут быть загружены в виде файла, если пользователи нажимают вновь отображаемую кнопку `Download Manifest`. +- На этом этапе каждый участник должен загрузить это определение в свой клиент charon, и клиент попытается выполнить DKG. + +## Проведение церемонии DKG + +Как только участник подготовит свой файл определения, он передаст файл команде charon `dkg`. Charon прочитает ENR, подтвердит наличие своего ENR, а затем обратится к развернутым загрузочным узлам, чтобы найти другие ENR в сети. (Свежие ENR просто имеют открытый ключ и IP-адрес 0.0.0.0 до тех пор, пока они не будут загружены в работающий клиент charon, который обновит IP-адрес, увеличит одноразовый номер ENR и подпишется с закрытым ключом клиента. Если ENR с более высоким одноразовым номером считается клиентом charon, они обновят IP-адрес этого ENR в своей адресной книге.) + +Как только все клиенты в кластере смогут установить соединение друг с другом и каждый из них завершит рукопожатие (подтвердите, что у всех есть соответствующий `cluster_definition_hash`), далее начинается церемония. + +Ввод данных пользователем не требуется, charon выполняет всю работу и выводит следующие файлы на каждую машину, а затем завершает работу. + +```sh +# Common data +.charon/cluster-definition.json # Исходный файл определения из панели запуска DV или `charon create dkg` +.charon/cluster-lock.json # Новый файл блокировки на основе cluster-definition.json с открытыми ключами группы валидаторов и пороговыми верификаторами BLS, включенными в первоначальную конфигурацию кластера +.charon/deposit-data.json # JSON файл данных депозита для распределенных валидаторов + +# Конфиденциальные данные оператора +.charon/charon-enr-private-key # Создается до церемонии [Скопируйте и сохраните ключ] +.charon/validator_keys/ # Папка с общими ключами для резервного копирования и перемещения в клиент валидатора [Скопируйте и сохраните это] +``` + +## Создайте резервную копию артефактов церемонии + +После завершения церемонии все участники должны сделать резервную копию созданных файлов. В будущих версиях charon, если участник потеряет доступ к этим общим ресурсам ключей, можно будет использовать протокол повторного обмена ключами, чтобы заменить старые ключи участников из распределенного валидатора на новые ключи, что позволит остальной части кластер для восстановления после набора потерянных ключевых общих ресурсов. Однако на данный момент, без резервной копии, самым безопасным было бы выйти из валидатора. + +## Подготовка к активации валидатора + +После завершения церемонии каждый оператор сделал безопасное резервное копирование общих ключей. Теперь они должны загрузить эти общие ресурсы в свои клиенты-валидаторы и запустить команду `charon run`, чтобы перевести их в рабочий режим. + +Все операторы должны подтвердить, что в их журналах клиентов charon указано, что все узлы находятся в сети и подключены. Они также должны проверить готовность своих клиентов-маяков и клиентов-валидаторов. Панель Charon Grafana — это хороший способ увидеть готовность всего кластера с его точки зрения. + +Once all operators are satisfied with network connectivity, one member can use the Obol Distributed Validator deposit flow to send the required ether and deposit data to the deposit contract, beginning the process of a distributed validator activation. Good luck. +После того, как все операторы будут удовлетворены сетевым подключением, один участник может использовать deposit flow Obol Distributed Validator для отправки необходимых данных эфира и депозита в депозитный контракт, начиная процесс активации распределенного валидатора. Удачи. + +## Верификация DKG + +Во многих случаях использования распределенных валидаторов спонсор/депонент валидатора может не совпадать с создателями ключей/операторами узлов, поскольку (за пределами базового протокола) делегирование доли является распространенным явлением. Эта передача информации вводит точку доверия. Как кто-то проверяет, что предлагаемые `депозитные данные` валидатора соответствуют реальным, честным DKG с участниками, которых ожидает вкладчик? + +Существует ряд аспектов этой поверхности доверия, которые можно смягчить с помощью модели "Не доверяй, проверяй" ("Don't trust, verify"). В настоящее время проверка вне сети проще, пока в EVM не будут добавлены такие вещи, как [прекомпиляция BLS](https://eips.ethereum.org/EIPS/eip-2537), наряду с дешевой проверкой ZKP в цепочке. Некоторые из вопросов, которые можно задать на церемониях генерации ключей распределенного валидатора, включают: + +- Объединяются ли доли открытого ключа в общий открытый ключ группы? + - Это можно проверить в цепочке, поскольку для этого не требуется операция сопряжения. + - Это может дать уверенность в том, что открытый ключ BLS представляет собой распределенный валидатор, но ничего не говорит о хранении ключей. (например, была ли атака sibyl на церемонии, был ли они в сговоре, чтобы восстановить закрытый ключ группы и т. д.) +- Подтверждают ли созданные открытые ключи BLS об их `cluster_definition_hash`? + - Это делается для создания обратной связи между вновь созданными публичными ключами BLS и адресами eth1 оператора, которые принимали участие в их создании. + - Если предложенный открытый групповой ключ распределенного валидатора BLS может создать подпись `cluster_definition_hash`, можно сделать вывод, что по крайней мере пороговое число операторов подписало эти данные. + - Поскольку `cluster_definition_hash` один и тот же для всех распределенных валидаторов, созданных на церемонии, подписи могут быть объединены в групповую подпись, которая одновременно проверяет все созданные групповые ключи. Это удешевляет одновременную проверку нескольких валидаторов в цепочке. +- Есть ли доказательства VSS или PVSS честной церемонии DKG? + - VSS (Verifiable Secret Sharing) означает, что только операторы могут проверить справедливость, поскольку для доказательства требуется знание одного из секретов. + - PVSS (Publicly Verifiable Secret Sharing) означает, что любой может проверить справедливость, поскольку доказательство обычно является доказательством с нулевым разглашением (Zero Knowledge Proof). + - PVSS справедливого DKG затруднит сговор операторов и подорвет безопасность распределенного валидатора. + - Проверка с нулевым разглашением (Zero Knowledge Proof) в цепочке в настоящее время стоит дорого, но становится достижимой благодаря напряженной работе и исследованиям многих команд в отрасли, основанных на ZK. + +## Дополнительно + +### Использование DKG без панели запуска + +Клиенты Charon могут выполнить DKG с файлом определения, который не содержит сигнатур оператора, если вы передадите флаг `--no-verify` в `charon dkg`. Это можно использовать в целях тестирования, когда строгая проверка подписи не имеет первостепенного значения. + +### Примеры файлов конфигурации и файла блокировки + +Подробности смотрите [здесь](../dv/08_distributed-validator-cluster-manifest.md#cluster-configuration-files). + diff --git a/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/dvk/02_distributed_validator_launchpad.md b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/dvk/02_distributed_validator_launchpad.md new file mode 100644 index 0000000000..69ac73131f --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/dvk/02_distributed_validator_launchpad.md @@ -0,0 +1,16 @@ +--- +Description: >- + Децентрализованное приложение для безопасного создания распределенных валидаторов в одиночку или в группе. +--- + +# Панель запуска распределенного валидатора (Distributed Validator launchpad) + +![DV Launchpad Promo Image](/img/DistributeYourValidators.svg) + +Чтобы активировать валидатор Ethereum, необходимо внести 32 ETH в официальный депозитный контракт. + +Подавляющее большинство пользователей, ставшие валидаторами на сегодняшний день, использовали **[~~Eth2~~ Staking Launchpad](https://launchpad.ethereum.org/)**, общедоступный веб-сайт с открытым исходным кодом, созданный Ethereum Foundation. Вместе с участниками, которые позже основали Obol. Этот инструмент оказался чрезвычайно успешным в безопасном и образовательном создании значительного количества валидаторов в основной сети Ethereum. + +Чтобы облегчить создание распределенных ключей проверки среди удаленных пользователей с высоким уровнем доверия, Obol Network намерена разработать и поддерживать веб-сайт, который позволит группе пользователей собраться вместе и создать эти ключи. + +Панель запуска DV разрабатывается в несколько этапов, координируемых нашей [рабочей группой панели запуска DV](../int/working-groups). Чтобы принять участие в этой работе, прочитайте страницу и зарегистрируйтесь по соответствующей ссылке. diff --git a/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/dvk/_category_.json b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/dvk/_category_.json new file mode 100644 index 0000000000..1d6ce83445 --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/dvk/_category_.json @@ -0,0 +1,5 @@ +{ + "label": "Генерация ключа", + "position": 4, + "collapsed": false +} diff --git a/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/glossary.md b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/glossary.md new file mode 100644 index 0000000000..81d75be7da --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/glossary.md @@ -0,0 +1,8 @@ +# Глоссарий +На этой странице подробно рассматриваются различные технические термины, встречающиеся в данном руководстве. Видите слово или фразу, которые нужно добавить? Дайте нам знать! + +### Консенсус (Consensus) +Коллекция узлов, которые приходят к соглашению о том, что подписывать вместе + +### Пороговые подписи (Threshold signing) +Пороговые подписи — это цифровые подписи, в которых подписавшие могут создавать группы таким образом, что только определенные подмножества группы могут создавать подписи от имени группы, что дает набору машин должный уровень отказоустойчивости. diff --git a/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/int/Overview.md b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/int/Overview.md new file mode 100644 index 0000000000..15ec3d1546 --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/int/Overview.md @@ -0,0 +1,49 @@ +--- +sidebar_position: 2 +description: Обзор сети Obol +--- + + +## Сеть + +Сеть лучше всего визуализировать как рабочий уровень, который находится непосредственно над консенсусом базового уровня. Этот рабочий уровень предназначен для обеспечения большей устойчивости базового уровня и содействия децентрализации по мере его масштабирования. По мере того, как текущее состояние Ethereum будет развиваться в ближайшие годы, сообщество перейдет к следующей серьезной задаче масштабирования, а именно к централизации доли. Чтобы эффективно снизить эти риски, создание сообщества и заслуживающий доверия нейтралитет должны использоваться в качестве основных принципов проектирования. + +Obol как слой ориентирован на масштабирование консенсуса за счет предоставления доступа без разрешений к распределенным валидаторам (DV). Мы считаем, что DV будут и должны составлять большую часть конфигураций валидаторов основной сети. При подготовке к первой волне внедрения в сети в настоящее время используется промежуточное программное обеспечение технологии распределенных валидаторов (DVT), чтобы обеспечить работу кластеров распределенных валидаторов, которые могут сохранять валидаторов в текущем клиенте и конфигурациях удаленной подписи. + +Подобно тому, как технология свертывания заложила основу для реализации масштабирования L2, мы считаем, что DVT сделает то же самое для масштабирования консенсуса при сохранении децентрализации. Инфраструктура стейкинга вступает в фазу эволюции своего протокола, которая должна включать в себя сети стейкинга с минимальным доверием, которые можно подключать в любом масштабе. Уровни, такие как Obol, имеют решающее значение для долгосрочной жизнеспособности и отказоустойчивости общедоступных сетей, особенно таких сетей, как Ethereum. Мы считаем, что DVT превратится в широко используемый примитив и обеспечит безопасность, отказоустойчивость и децентрализацию общедоступных сетей блокчейнов, которые его используют. + +Сеть Obol состоит из четырех основных составляющих: + +- [Distributed Validator Launchpad](../dvk/01_distributed-validator-keys.md), инструмент CLI и dApp для запуска распределенных валидаторов +- [Charon](../dv/01_introducing-charon.md), клиент промежуточного программного обеспечения, который позволяет валидаторам быть отказоустойчивыми, распределенным образом +- [Obol Managers](../sc/01_introducing-obol-managers.md), набор смарт-контрактов Solidity для формирования распределенных валидаторов +- [Obol Testnets](../testnet.md), набор текущих публичных поощрительных тестовых сетей, которые позволяют оператору любого размера протестировать свое развертывание перед обслуживанием в основной сети Obol Network. + +### Вклад в доступность экосистемы стейкинга + +Экосистема Obol вдохновлена ​​предыдущей работой над экосистемой Ethereum и экспериментами с экономикой. Мы считаем, что для раскрытия инноваций в сценариях использования стекинга должен существовать заслуживающий доверия нейтральный слой, чтобы инновации могли течь и развиваться по вертикали. Без этого уровня время безотказной работы будет по-прежнему оставаться плохим, а ставка будет аккумулироваться среди нескольких продуктов. + +В ближайшие месяцы и годы сеть Obol станет открытым самодостаточным проектом, управляемым сообществом. Вместе мы будем стимулировать, создавать и поддерживать технологию распределенных валидаторов, которая делает общедоступные сети более безопасной и отказоустойчивой основой для дальнейшего развития. + +![](/img/DVT4.png) + +## Наше виденье + +Путь к децентрализации ставок не быстрый процесс. В Obol мы разделили наше видение на две ключевые версии распределенных валидаторов. + +### V1 - Доверенные Распределенные Валидаторы (Trusted Distributed Validators) + +Первая версия распределенных валидаторов будет иметь внеплановое разрешение споров. Это означает, что вам нужно знать и связываться с вашими операторами-контрагентами, если есть проблема с вашим общим кластером. + +A DV without in-band dispute resolution/incentivisation is still extremely valuable. Individuals and staking as a service providers can deploy DVs on their own to make their validators fault tolerant. Groups can run DVs together, but need to bring their own dispute resolution to the table, whether that be a smart contract of their own, a traditional legal service agreement, or simply high trust between the group. +DV без внутреннего разрешения/поощрения споров по-прежнему чрезвычайно ценен. Частные лица и поставщики услуг могут развертывать DV самостоятельно, чтобы сделать свои валидаторы отказоустойчивыми. Группы могут запускать DV вместе, но им необходимо вынести на обсуждение свое собственное разрешение споров, будь то собственный смарт-контракт, традиционное соглашение о юридических услугах или просто высокое доверие между группой. + +Obol V1 будет использовать ретроактивные принципы общественных благ, чтобы заложить основу своей экономической экосистемы. Сообщество Obol будет ответственно распределять собранные ETH в качестве грантов для проектов в экосистеме ставок на протяжении всей версии V1. + +### V2 - Распределенные валидаторы без доверия (Trustless Distributed Validators) + +V1 Charon'а обслуживает небольшую по количеству, но большую по весу группу лиц. Большое количество мелких стейкеров и стейкеров в домашних условиях, также заслуживают доступа к отказоустойчивой проверке, но они могут не знать большинство других операторов лично, чтобы иметь достаточный уровень доверия для совместной работы кластера DV. + +Вторая версия Сharon будет включать в себя схему поощрения, чтобы гарантировать, что любой оператор, не подключенный к сети и участвующий в проверке, не получает никаких вознаграждений. Дальнейшее согласование поощрений может быть достигнуто с помощью требований к связям с оператором, которые могут быть сокращены из-за неприемлемой производительности. + +Чтобы добавить уровень стимулирования вне игры, к пороговой проверке, требуются сложные интерактивные криптографические схемы, безопасное разрешение споров вне сети и поддержка EVM для доказательств состояния уровня консенсуса, в результате это будет дольше и сложнее, чем V1. , отсюда и разграничение между ними. diff --git a/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/int/_category_.json b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/int/_category_.json new file mode 100644 index 0000000000..c78dcfdb76 --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/int/_category_.json @@ -0,0 +1,5 @@ +{ + "label": "Введение", + "position": 2, + "collapsed": false +} diff --git a/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/int/faq.md b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/int/faq.md new file mode 100644 index 0000000000..7c6f1d471a --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/int/faq.md @@ -0,0 +1,39 @@ +--- +sidebar_position: 10 +description: Часто задаваемые вопросы +--- + +# Часто задаваемые вопросы + +### У Obol есть токен? + +Нет. Распределенные валидаторы используют только эфир. + +### Могу ли я сохранить существующий клиент валидатора? + +Да. Charon является промежуточным программным обеспечением между клиентом валидатора и его узлом-маяком. Будут поддерживаться все валидаторы, реализующие стандартный REST API, а также все популярные программы доставки клиентов, такие как DAppNode [packages](https://dappnode.github.io/explorer/#/), Rocket Pool's [smart node](https://github.com/rocket-pool/smartnode), StakeHouse's [wagyu](https://github.com/stake-house/wagyu), and Stereum's [node launcher](https://stereum.net/development/#roadmap). + +### Могу ли я перенести свой существующий валидатор в распределенный валидатор? + +Можно будет разделить существующее хранилище ключей валидатора на набор общих ключей, подходящих для распределенного валидатора, но это доверенный процесс распространения, и если старая система ставок не будет безопасно отключена, это может создать риск двойной подписи. вместе с новым распределенным валидатором. + +В идеальном сценарии закрытый ключ распределенного валидатора никогда не должен полностью храниться в одном месте. + +Вы можете разделить существующее хранилище ключей EIP-2335 для валидатора, чтобы перенести его на распределенную архитектуру валидатора с помощью задокументированной команды charon create cluster --split-existing-keys [информация](../dv/09_charon_cli_reference.md#create-a-full-cluster-locally). + +### Что такое ENR? + +ENR это сокращение для [Ethereum Node Record](https://eips.ethereum.org/EIPS/eip-778). Это способ представить узел в общедоступной сети с надежным механизмом обновления его информации. В Obol мы используем ENR для идентификации узлов Charon друг с другом, чтобы они могли образовывать кластеры с правильными узлами Charon, а не с самозванцами. + +У ENR есть закрытые ключи, которые они используют для подписи обновлений [содержание данных](https://enr-viewer.com/) в своих ENR. Этот закрытый ключ по умолчанию находится в `.charon/charon-enr-private-key`, и его следует хранить в безопасности и не хранить в системе контроля версий. ENR выглядит примерно так: +``` +enr:-JG4QAgAOXjGFcTIkXBO30aUMzg2YSo1CYV0OH8Sf2s7zA2kFjVC9ZQ_jZZItdE8gA-tUXW-rWGDqEcoQkeJ98Pw7GaGAYFI7eoegmlkgnY0gmlwhCKNyGGJc2VjcDI1NmsxoQI6SQlzw3WGZ_VxFHLhawQFhCK8Aw7Z0zq8IABksuJEJIN0Y3CCPoODdWRwgj6E +``` + +### Где я могу узнать больше о распределенных валидаторах? + +Можете посмотреть в [нашем блоге](https://blog.obol.tech) и в [твиттере](https://twitter.com/ObolNetwork) Также можно найти информации в [discord](https://discord.gg/obol). + +### значение слова Charon? + +[Charon](https://www.theoi.com/Khthonios/Kharon.html) это древнегреческий перевозчик мертвых. Ему было поручено переправить людей через реку Ахерон в подземный мир. Его гонорар составлял одну оболскую монету, которую клали в рот умершему. Эта традиция класть монету или обол в рот умершего продолжается и по сей день во всем греческом мире. \ No newline at end of file diff --git a/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/int/key-concepts.md b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/int/key-concepts.md new file mode 100644 index 0000000000..12470292ad --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/int/key-concepts.md @@ -0,0 +1,86 @@ +--- +sidebar_position: 3 +description: Некоторые из ключевых терминов в области технологии распределенных валидаторов +--- + +# Ключевые понятия +На этой странице представлен ряд ключевых понятий, лежащих в основе различных технологий, которые разрабатывает Obol. + +## Распределенный валидатор (Distributed validator) + +![Распределенный валидатор](/img/WhatIsADistributedValidator.png) + +Распределенный валидатор — это валидатор Proof-of-Stake Ethereum, который работает более чем на одном узле/машине. Эта функциональность обеспечивается **Distributed Validator Technology** (DVT). + +​Технология распределенного валидатора устраняет проблему единичного отказа. Если <33% участвующих узлов в кластере DVT отключатся, оставшиеся активные узлы по-прежнему смогут прийти к консенсусу в отношении того, что подписывать, и создавать действительные подписи для выполнения своих обязанностей по стейкингу. Это известно как избыточность «активный/активный», распространенный шаблон для минимизации времени простоя в критически важных системах. + +## Узел распределенного валидатора (Distributed Validator Node) + +![Узел распределенного валидатора](/img/WhatIsADistributedValidatorNode.png) + +Узел распределенного валидатора — это набор клиентов, которые необходимо настроить и запустить оператору для выполнения обязанностей оператора распределенного валидатора. Оператор также может запускать резервные клиенты выполнения и консенсуса, ретранслятор полезной нагрузки выполнения, такой как [mev-boost](https://github.com/flashbots/mev-boost), или другие службы мониторинга или телеметрии на том же оборудовании для обеспечения оптимальной производительности. + +In the above example, the stack includes geth, lighthouse, charon and lodestar. +В приведенном выше примере технологический стек включает в себя geth, lighthouse, charon and lodestar. + +### Клиент исполнения + +Клиент выполнения (ранее известный как клиент Eth1) специализируется на запуске EVM и управлении пулом транзакций для сети Ethereum. Эти клиенты предоставляют исполняемую полезную нагрузку согласованным клиентам для включения в блоки. + +Примеры исполняемых клиентов включают: + +- [Go-Ethereum](https://geth.ethereum.org/) +- [Nethermind](https://docs.nethermind.io/nethermind/) +- [Erigon](https://github.com/ledgerwatch/erigon) + +### Клиент консенсуса + +Обязанностью клиента консенсуса является запуск уровня консенсуса Proof-of-Stake в Ethereum, который часто называют цепочкой маяков (beacon chain). + +Примеры клиентов консенсуса включают: + +- [Prysm](https://docs.prylabs.network/docs/how-prysm-works/beacon-node) +- [Teku](https://docs.teku.consensys.net/en/stable/) +- [Lighthouse](https://lighthouse-book.sigmaprime.io/api-bn.html) +- [Nimbus](https://nimbus.guide/) +- [Lodestar](https://github.com/ChainSafe/lodestar) + +### Клиент распределенного валидатора + +Распределенный клиент валидатора перехватывает поток связи между клиентом валидатора и согласованным клиентом через [стандартизированный REST API](https://ethereum.github.io/beacon-APIs/#/ValidatorRequiredApi) и фокусируется на двух основных задачах. + +- Приводит к консенсусу относительно обязанности кандидата, которую должны подписать все валидаторы. +- Объединение подписей всех валидаторов в распределенную подпись валидатора + +На сегодняшний день единственным примером распределенного клиента валидатора, построенного с архитектурой промежуточного программного обеспечения, не связанной с хранением, является [charon](../dv/01_introducing-charon.md). + +### Клиент валидатора + +Клиент валидатора — это фрагмент кода, который управляет одним или несколькими валидаторами Ethereum. + +Примеры клиентов валидатора включают: + +- [Vouch](https://www.attestant.io/posts/introducing-vouch/) +- [Prysm](https://docs.prylabs.network/docs/how-prysm-works/prysm-validator-client/) +- [Teku](https://docs.teku.consensys.net/en/stable/) +- [Lighthouse](https://lighthouse-book.sigmaprime.io/api-bn.html) + +## Кластер распределенных валидаторов (A Distributed Validator Cluster) + +![Кластер распределенных валидаторов](/img/WhatIsADistributedValidatorCluster.png) + +Кластер распределенных валидаторов — это набор узлов распределенных валидаторов, соединенных вместе для обслуживания набора распределенных валидаторов, сгенерированных во время церемонии DVK. + +### Ключ распределенного валидатора (Distributed Validator Key) + +Распределенный ключ валидатора — это группа закрытых ключей BLS, которые вместе действуют как пороговый ключ для участия в консенсусе Proof-of-Stake. + +### Общий ключ распределенного валидатора (Distributed Validator Key Share) + +Одна часть распределенного закрытого ключа валидатора. + +### Церемония генерации ключа распределенного валидатора (Distributed Validator Key Generation Ceremony) + +Чтобы добиться отказоустойчивости в распределенном валидаторе, отдельные общие секретные ключи должны генерироваться вместе. Вместо того, чтобы доверенный дилер создавал закрытый ключ, разделял его и распространял, предпочтительный подход состоит в том, чтобы никогда не создавал полный закрытый ключ в любой момент, когда каждый оператор в распределенном кластере валидатора участвует в так называемом распределенном ключе. Церемония генерации. + +Церемония генерации распределенного ключа валидатора является разновидностью церемонии DKG. Церемония DVK создает подписанные данные о депозите и выходе валидатора, а также все доли ключей валидатора и связанные с ними метаданные. diff --git a/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/int/quickstart/_category_.json b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/int/quickstart/_category_.json new file mode 100644 index 0000000000..c7a09cfbd7 --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/int/quickstart/_category_.json @@ -0,0 +1,5 @@ +{ + "label": "С чего начать", + "position": 3, + "collapsed": false +} diff --git a/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/int/quickstart/index.md b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/int/quickstart/index.md new file mode 100644 index 0000000000..6722bbbb51 --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/int/quickstart/index.md @@ -0,0 +1,12 @@ +# С чего начать + +:::caution +Charon находится в ранней альфа-версии и не готов к запуску в основной сети +::: + +Есть два способа протестировать распределенный валидатор; самостоятельно, запустив все необходимое программное обеспечение в docker контейнерах, или вы можете запустить распределенный валидатор с группой других операторов узлов, где каждый из вас запускает только один клиент валидатора и клиент charon, а клиенты charon взаимодействуют друг с другом через Интернет для управления распределенным валидатором. Второй способ требует, чтобы каждый оператор открыл порт в Интернете, чтобы все узлы charon могли оптимально общаться друг с другом. + +Ниже приведены руководства по началу работы с нашими репозиториями. Идея состоит в том, чтобы поддерживать каждую комбинацию сборок: клиентов-маяков, клиентов-валидаторов. + +- [Запуск всего кластера в одиночку.](./quickstart-alone.md) +- [Запуск одного узла в кластере с группой других операторов узлов.](./quickstart-group.md) \ No newline at end of file diff --git a/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/int/quickstart/quickstart-alone.md b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/int/quickstart/quickstart-alone.md new file mode 100644 index 0000000000..0a8c11260b --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/int/quickstart/quickstart-alone.md @@ -0,0 +1,64 @@ +--- +sidebar_position: 4 +description: Запуск всех узлов в распределенном кластере валидатора +--- + +# Запуск кластера в одиночку + +:::caution +Charon находится в ранней альфа-версии и не готов к запуску в основной сети +::: + +1. Склонируйте репозиторий [charon-distributed-validator-cluster](https://github.com/ObolNetwork/charon-distributed-validator-cluster) и перейдите в директорию `cd`. + + ```sh + # Склонируйте репозиторий + git clone https://github.com/ObolNetwork/charon-distributed-validator-cluster.git + + # Смените директорию + cd charon-distributed-validator-cluster/ + ``` + +1. Подготовка окружения + + ```sh + # Скопируйте файл с переменными среды + cp .env.sample .env + ``` + + Для простоты этот репозиторий настроен для работы с удаленным узлом Beacon, например, из + [Infura](https://infura.io/). + + Создайте проект Eth2 и скопируйте URL-адрес `https`, убедитесь, что Prater выбран в раскрывающемся списке ENDPOINTS: + + ![Пример Infura API Endpoint](/img/example-infura-details.png) + + Замените значение `CHARON_BEACON_NODE_ENDPOINT` во вновь созданном файле `.env` этим URL-адресом. + +1. Сгенерируйте файлы, необходимые для запуска кластера распределенного валидатора тестовой сети + + ```sh + # Создайте кластер распределенного валидатора тестовой сети + docker run --rm -v "$(pwd):/opt/charon" ghcr.io/obolnetwork/charon:v0.8.1 create cluster --withdrawal-address="0x000000000000000000000000000000000000dead" + ``` + +1. Запуск кластера + ```sh + # Запустите кластер распределенного валидатора + docker-compose up + ``` +1. Проверьте панель мониторинга и посмотрите, все ли в порядке + + ```sh + # Откройте Grafana + open http://localhost:3000/d/laEp8vupp + ``` + +1. Активируйте валидатор в тестовой сети, используя оригинальный [staking launchpad](https://prater.launchpad.ethereum.org/en/overview) сайт с данными депозита созданными в `.charon/cluster/deposit-data.json`. + - Если вы используете Mac OS, `.charon`, выходная папка по умолчанию, не отображается в средстве выбора файлов найдите "Upload Deposit Data" на панели запуска. Rectify this by pressing `Command + Shift + . ` . Это должно отображать скрытые папки, позволяя вам выбрать файл депозита. + +Поздравляем, если всё сработало корректно, теперь вы запускаете кластер распределенного валидатора в тестовой сети. Попробуйте отключить один из четырех узлов с помощью `docker stop` и посмотрите, остается ли валидатор в сети или начинает пропускать свои обязанности, чтобы убедиться в отказоустойчивости, которую можно добавить к проверке подтверждения доли с помощью этой новой Технологии Распределенного Валидатора (Distributed Validator Technology). + +:::tip +Не забудьте быть хорошим распорядителем тестовой сети и выйти из валидатора, когда закончите тестирование. +::: diff --git a/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/int/quickstart/quickstart-group.md b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/int/quickstart/quickstart-group.md new file mode 100644 index 0000000000..c124983146 --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/int/quickstart/quickstart-group.md @@ -0,0 +1,134 @@ +--- +sidebar_position: 5 +description: Запуск одного узза в распределенном кластере валидатора с несколькими операторами +--- + +# Совместный запуск кластера + +:::caution +Charon находится в ранней альфа-версии и не готов к запуску в основной сети +::: + +Для создания распределенного кластера валидаторов с группой других операторов узлов требуется пять ключевых шагов: + +- Каждый оператор подготавливает свое программное обеспечение и получает свой клиентский charon. [ENR](../faq.md#what-is-an-enr) +- Один оператор подготавливает условия генерации ключей распределенного валидатора для запуска + - Они выбирают сеть, адрес вывода средств, количество 32 распределенных валидаторов эфира для создания и ENR каждого оператора, принимающего участие в запуске. + - В будущем панель запуска DV будет упрощать этот процесс, с согласия на условиях, предоставленных всеми участвующими операторами. +- Каждый оператор участвует в запуске DKG, и в случае успеха создается ряд сгенерированных файлов кластера, в том числе: + - Общий закрытый ключ для каждого распределенного валидатора + - Файл данных депозита, содержащий детали депозита для каждого распределенного валидатора + - Файл `cluster-lock.json`, который содержит окончательный конфиг этого кластера, необходимый для работы charon. + +- Каждый оператор запускает свой узел с помощью «charon run» и использует свой мониторинг для определения работоспособности кластера и подключения +- После подтверждения работоспособности кластера файлы данных депозита, созданные в ходе этого процесса, активируются на [staking launchpad](https://launchpad.ethereum.org/). + +## Начало работы с Charon + +1. Склонируйте репозиторий [charon-distributed-validator-node](https://github.com/ObolNetwork/charon-distributed-validator-node) с Github, и перейдите в директорию `cd`. + + ```sh + # Склонируйте репозиторий + git clone https://github.com/ObolNetwork/charon-distributed-validator-node.git + + # Смените директорию + cd charon-distributed-validator-node/ + ``` +1. Затем создайте закрытый ключ для charon, чтобы использовать его для ENR. + + ```sh + # Создайте закрытый ключ ENR (private key) + docker run --rm -v "$(pwd):/opt/charon" ghcr.io/obolnetwork/charon:v0.8.1 create enr + ``` + + Эта команда выведет ENR вашего клиента charon в консоль. Это должно выглядеть примерно так: + + ``` + Created ENR private key: .charon/charon-enr-private-key + enr:-JG4QAgAOXjGFcTIkXBO30aUMzg2YSo1CYV0OH8Sf2s7zA2kFjVC9ZQ_jZZItdE8gA-tUXW-rWGDqEcoQkeJ98Pw7GaGAYFI7eoegmlkgnY0gmlwhCKNyGGJc2VjcDI1NmsxoQI6SQlzw3WGZ_VxFHLhawQFhCK8Aw7Z0zq8IABksuJEJIN0Y3CCPoODdWRwgj6E + ``` + + :::caution + На данный момент возможность замены удаленного или скомпрометированного закрытого ключа ограничена. Пожалуйста, сделайте безопасную резервную копию этого закрытого ключа, если этот распределенный валидатор важен для вас. + ::: + + Эта запись идентифицирует ваш клиент charon независимо от того, откуда он общается через Интернет. Это необходимо для следующего шага создания набора распределенных общих ключей валидатора среди операторов кластера. + + Обязательно сделайте резервную копию закрытого ключа по адресу .charon/charon-enr-private-key. Будьте осторожны, чтобы не закоммитить его в git! Если вы потеряете этот файл, вы не сможете принять участие в запуске DKG. + + Если вы принимаете участие в организованной тестовой сети Obol, отправьте созданный публичный адрес ENR (вывод консоли, начинающийся с `enr:-` (отправить вместе с enr:-), а не содержимое файла закрытого ключа) в соответствующую форму для участия. + + +## Генерация ключа распределенного валидатора + +Чтобы безопасно создать закрытые ключи для распределенного валидатора, необходимо выполнить процесс генерации распределенного ключа (DKG). + +1. После сбора всех операторов ENR и установки их в файле `.env`, один оператор должен подготовить церемонию с помощью `charon create dkg` + + ```sh + + # Сначала установите ENR всех операторов, участвующих в церемонии DKG, в файле .env как CHARON_OPERATOR_ENRS + + # Создайте .charon/cluster-definition.json для участия в церемонии DKG + docker run --rm -v "$(pwd):/opt/charon" --env-file .env ghcr.io/obolnetwork/charon:v0.8.1 create dkg + ``` + +1. Оператор, выполнивший эту команду, должен передать результирующий файл `cluster-definition.json` каждому оператору. + +1. В заранее оговоренное время все операторы запускают программу церемонии с помощью команды `charon dkg`. + + ```sh + # Скопируйте cluster-definition.json файл в .charon + cp cluster-definition.json .charon/ + + # Участие в церемонии DKG, создаст .charon/cluster-lock.json, .charon/deposit-data.json и .charon/validator_keys/ + docker run --rm -v "$(pwd):/opt/charon" ghcr.io/obolnetwork/charon:v0.8.1 dkg + ``` + +## Проверка работоспособности кластера + +После завершения церемонии генерации ключей узлы charon получают данные, необходимые для объединения в кластер. + +1. Сначала вы должны подготовить необходимые переменные среды, в частности, вам нужно установить переменную `CHARON_BEACON_NODE_ENDPOINT`, чтобы она указывала либо на локальную, либо на удаленную конечную точку API узла маяка. + + ```sh + # Скопируйте шаблон переменных среды + cp .env.sample .env + ``` + + Для простоты этот репозиторий настроен для работы с удаленным узлом Beacon, например, из + [Infura](https://infura.io/). + + Создайте проект Eth2 и скопируйте URL-адрес `https`, убедитесь, что Prater выбран в раскрывающемся списке ENDPOINTS: + + ![Пример Infura API Endpoint](/img/example-infura-details.png) + + Замените значение `CHARON_BEACON_NODE_ENDPOINT` во вновь созданном файле `.env` этим URL-адресом. + +1. Запустите узел распределенного валидатора с помощью docker-compose. + ```sh + # Запустите клиент charon, клиент vc и клиенты prom+grafana в контейнерах + docker-compose up + ``` +1. Используйте предварительно подготовленную информационную панель [grafana](http://localhost:3000/) чтобы убедиться, что состояние кластера в порядке. Вы должны увидеть соединения со всеми другими операторами в кластере как работоспособные, а наблюдаемое время проверки связи для всех соединений составляет менее 1 секунды. + + ```sh + # Откройте Grafana + open http://localhost:3000/d/singlenode + ``` + Если Grafana не загружает данные при первом открытии, попробуйте [этот метод](https://github.com/ObolNetwork/charon-distributed-validator-node#grafana-doesnt-load-any-data) для решения проблемы. + +## Активация распределенного валидатора + +Когда кластер исправен и полностью подключен, пришло время внести необходимые 32 (тестовых) эфира, чтобы активировать недавно созданный распределенный валидатор. + +1. Активируйте валидатор в тестовой сети, используя оригинальный [staking launchpad](https://prater.launchpad.ethereum.org/en/overview) сайт с данными о депозите, созданный на `.charon/deposit-data.json`. + - Если вы используете Mac OS, `.charon`, выходная папка по умолчанию, не отображается в средстве выбора файлов найдите "Upload Deposit Data" на панели запуска. Rectify this by pressing `Command + Shift + . ` . Это должно отображать скрытые папки, позволяя вам выбрать файл депозита. + - Более удобный интерфейс депозита для валидатора, находится в разработке для предстоящего выпуска. +1. Этот процесс занимает около 16 часов, прежде чем депозит будет зарегистрирован в цепочке маяков. Будущие обновления протокола направлены на сокращение этого времени. +1. Как только депозит валидатора распознается в цепочке маяков, валидатору присваивается индекс, и начинается ожидание активации. +1. Наконец, после активации валидатора его следует контролировать, чтобы убедиться, что он достигает расстояния включения, близкого к 0, для обеспечения оптимального вознаграждения. Вы также должны твитнуть ссылку на ваш недавно активированный валидатор с хэштегом. [#RunDVT](https://twitter.com/search?q=%2523RunDVT) 🙃 + +:::tip +Не забудьте быть хорошим распорядителем тестовой сети и выйти из валидатора, когда закончите тестирование. +::: diff --git a/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/int/working-groups.md b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/int/working-groups.md new file mode 100644 index 0000000000..843b3263a2 --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/int/working-groups.md @@ -0,0 +1,145 @@ +--- +sidebar_position: 5 +description: Структура рабочей группы Obol Network. +--- + +# Рабочая группа + +Сеть Obol — это распределенный согласованный протокол и экосистема, задача которых — устранить риски технических сбоев в Ethereum с помощью технологии распределенного валидатора (DVT). Проект достиг точки, когда усиление координации, участия и ответственности сообщества окажет значительное влияние на рост базовой технологии. В результате команда Obol Labs откроет рабочие потоки и поощрения для сообщества, при этом первая рабочая группа будет заниматься процессом создания распределенных валидаторов. + +Этот документ призван описать, что такое Obol, как устроена экосистема, как она планирует развиваться и из чего будет состоять первая рабочая группа. + +## Экосистема Obol + +Сеть Obol состоит из четырех основных продуктов: + +- **The DVK Launchpad** - инструмент CLI и пользовательский интерфейс для запуска распределенных валидаторов. + +- **Charon** - клиент промежуточного программного обеспечения, который позволяет валидаторам оставаться отказоустойчивыми, распределенным образом + +- **Obol Managers** - набор смарт-контрактов Solidity для формирования распределенных валидаторов + +- **Obol Testnets** - набор текущих публичных поощрительных тестовых сетей, которые позволяют оператору любого размера протестировать свое развертывание перед обслуживанием в основной сети Obol Network. + +## Формирование рабочих групп + +Obol Labs стремится обеспечить разнообразие участников, открывая проект для внешнего участия. Затем участники на раннем этапе сортируются в структурированные рабочие группы, что позволяет многим голосам сотрудничать в области стандартизации и создания компонентов с открытым исходным кодом. + +Для каждого отдела продукта будет создана специальная рабочая группа, открытая для участия членов общества Obol. Первая рабочая группа занимается разработкой распределенных ключей валидатора и панели запуска DV. Это позволит участникам поэкспериментировать с экосистемой Obol и найти взаимовыгодное долгосрочное сотрудничество с проектом. + +Вторая рабочая группа будет заниматься тестовыми сетями после того, как первая будет завершена. + +## Рабочая группа DVK + +Первая рабочая группа, которую Obol запустит для участия, сосредоточена на компоненте генерации распределенного валидатора технологического стека Obol. Это попытка стандартизировать создание распределенного валидатора с помощью EIP и создать панель запуска сообщества, аналогичную сегодняшней панели запуска Eth2 (ранее созданной членами основной команды Obol). + +Генерация распределенного ключа валидации (DVK) является важнейшей базовой возможностью протокола и, в более широком смысле, важной частью разработки для различных расширенных вариантов использования. В результате цель рабочей группы состоит в том, чтобы использовать подход сообщества к определению, разработке и стандартизации инструмента генерации ключей распределенного валидатора с открытым исходным кодом и панели запуска сообщества. + +Эту задачу можно условно разделить на три этапа: +- Этап 0: тестирование POC, обратная связь по POC, реализация DKG, спецификация и отправка EIP +- Этап 1: Спецификация Launchpad и отзывы пользователей +- Этап 1.5: Дополнительные исследования (проверка несколькими операторами) + +## Стадии +Члены рабочей группы DVK будут иметь разные обязанности в зависимости от этапа их участия. + +### Участие в нулевой стадии + +Нулевой этап ориентирован на прикладную криптографию и безопасность. Ожидаемый результат этого этапа — CLI-программа для участия в церемониях DVK. + +Obol опишет и создаст интерактивный инструмент CLI, способный генерировать распределенные ключи валидатора с учетом стандартизированного файла конфигурации и доступа к сети для координации с другими узлами-участниками. Этот инструмент может использоваться одним объектом (синхронно) или группой участников (полуасинхронно). + +Группа нулевого этапа находится в процессе отправки EIP для схемы кодирования распределенного ключа проверки в соответствии с EIP-2335, а также нового EIP для кодирования конфигурации и приватных данных, необходимых для процесса DKG, как указано в рабочей группе. + +**Обязанности участников:** +- Тестирование реализации и обратная связь +- Обратная связь о алгоритме DKG +- Обратная связь о защищенности Церемонии +- Опыт работы с Go, Rust, Solidity или прикладной криптографией + +### Участие в 1 этапе + +Этап 1 сосредоточен на разработке DV LaunchPad, веб-интерфейса SPA с открытым исходным кодом для облегчения церемоний DVK с аутентифицированными контрагентами. + +Чтобы облегчить генерацию распределенных ключей валидатора среди удаленных пользователей с высоким уровнем доверия, Obol Labs намерена разработать и поддерживать веб-сайт, который позволит группе пользователей генерировать конфигурацию, необходимую для церемонии генерации DVK. + +Команда Obol Labs сотрудничает с Deep Work Studio в рамках многонедельного сеанса дизайна и обратной связи с пользователями, который начался 1 апреля. В совместных сеансах проектирования и прототипирования участвуют основная команда Obol и члены сообщества Genesis. Все занятия будут записываться и публиковаться в открытом доступе. + +**Обязанности участников:** +- Фидбек о архитектуре DV LaunchPad +- Принять участие в 2 раундах синхронного пользовательского тестирования с командой Deep Work (6–10 апреля и 18–22 апреля). +- Создание валидатора тестовой сети + +### Участие в этапе 1.5 + +Этап 1.5 сосредоточен на формальном исследовании спроса и понимания мультиоператорной проверки. Это будет отдельная исследовательская работа, которую проведет Джорджия Ракусен. Это исследование будет оформлено в виде официального отчета и бесплатно распространено среди сообщества Эфириума. Участие в этапе 1.5 основано на опросе пользователей и психологическом тестировании. Эта работа началась в начале апреля. + +**Обязанности участников:** +- Полный асинхронный опрос +- Передать опрос пользователям профиля, чтобы повысить глубину исследования. +- Создание проектных ресурсов для финального исследовательского артефакта + +## Прогресс этапов + +Основная команда Obol начала работу над всеми тремя этапами работы и представит черновые версии, а также запустит каналы Discord для каждого этапа, когда это необходимо. Ниже приведено обновление статуса основной команды по каждому этапу на сегодняшний день. + +**Прогресс:** + +- Этап 0: 70% +- Этап 1: 65% +- Этап 1.5: 30% + +Основная команда планирует выпустить различные этапы для получения отзывов от сообщества по мере того, как они приближаются к 75% завершению. + +## Ключевые задачи рабочей группы + +Результатами работы этой рабочей группы являются: + +### 1. Стандартизировать формат DVKs через EIPs + +Одним из многих успехов сообщества разработчиков Ethereum является высокий уровень поддержки стандартизированных форматов файлов со стороны всех групп клиентов. Крайне важно, чтобы мы все работали вместе как рабочая группа в этом ключе. + +Два примера таких стандартов в клиентском пространстве консенсуса включают: + +- EIP-2335: Формат JSON для хранения и обмена закрытыми ключами BLS12-381. +- EIP-3076: Распределенная схема кодирования ключа проверки Slashing Protection Interchange Format в соответствии с EIP-2335 и новый EIP для кодирования конфигурации и приватных данных, необходимых для кластера DV, который имеет выходные данные, основанные на отзывах рабочих групп. Выходы церемонии ДВК могут включать: + +- Подписанные файлы данных депозита валидатора +- Подписанные сообщения валидатора о выходе +- Закрытые общие ключи для клиента валидатора каждого оператора +- Манифесты распределенного кластера валидаторов для связывания каждого узла вместе + +### 2. Программа CLI для церемоний распределенного валидатора (DVK) + +Одним из ключевых успехов запуска Proof of Stake Ethereum стала доступность высококачественных инструментов CLI для генерации ключей валидатора Ethereum, включая eth2.0-deposit-cli и ethdo. + +Рабочая группа выпустит аналогичный инструмент командной строки, способный генерировать распределенные ключи валидатора при стандартной конфигурации и сетевом доступе для координации с другими узлами-участниками. + +As of March 1st, the WG is testing a POC DKG CLI based on Kobi Gurkan's previous work. In the coming weeks we will submit EIPs and begin to implement our DKG CLI in line with our V0.5 specs and the WG's feedback. +По состоянию на 1 марта рабочая группа тестирует интерфейс командной строки POC DKG на основе предыдущей работы Коби Гуркана. В ближайшие недели мы представим EIP и начнем внедрять интерфейс командной строки DKG в соответствии с нашими спецификациями версии 0.5 и отзывами рабочей группы. + +### 3. Панель запуска распределенного валидатора + +Чтобы активировать валидатор Ethereum, вам необходимо внести 32 эфира в официальный депозитный контракт. Подавляющее большинство пользователей, создавших валидаторы на сегодняшний день, использовали **[~~Eth2~~ Staking Launchpad](https://launchpad.ethereum.org/)**, общедоступный веб-сайт с открытым исходным кодом, созданный Ethereum Foundation. и участники, которые позже основали Obol. Этот инструмент оказался чрезвычайно успешным в безопасном и образовательном создании значительного количества валидаторов в основной сети Ethereum. + +Чтобы облегчить генерацию распределенных ключей валидатора среди удаленных пользователей с высоким уровнем доверия, Obol Labs разместит и будет поддерживать веб-сайт, который позволит группе пользователей совместно генерировать распределенные ключи валидатора, используя церемонию DKG в браузере. + +Со временем функции DV LaunchPad в первую очередь расширят спектр генерации ключей без доверия. Функции панели запуска V1 могут быть протестированы пользователем и прокомментированы любым участником сообщества Obol Proto! + +## Участники рабочей группы + +Членами рабочей группы 0го этапа являются: + +- The Obol genesis community +- Ethereum Foundation (Carl, Dankrad, Aditya) +- Ben Edgington +- Jim McDonald +- Prysmatic Labs +- Sourav Das +- Mamy Ratsimbazafy +- Kobi Gurkan +- Coinbase Cloud + +Предполагаемая инфраструктура этапа 1 и этапа 1.5 будет запущена без первоначальных участников, хотя они сразу же будут доступны для отправки участникам, которые присоединились к сообществу Obol Proto прямо [здесь](https://pwxy2mff03w.typeform.com/to/Kk0TfaYF). Каждый может присоединиться к прото-сообществу; однако участие в рабочей группе будет основываться на релевантности и наборе навыков. + + diff --git a/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/intro.md b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/intro.md new file mode 100644 index 0000000000..c0bc5a6742 --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/intro.md @@ -0,0 +1,20 @@ +--- +sidebar_position: 1 +description: Добро пожаловать в сеть валидаторов с несколькими операторами +--- + +# Введение + +## Что такое Obol? + +Obol Labs — команда исследователей и разработчиков программного обеспечения, специализирующаяся на инфраструктуре проверки доли владения для общедоступных сетей блокчейна. Особое внимание уделяется таким темам, как интернет-облигации, технология распределенных валидаторов и мультиоператорная валидация. В настоящее время команда состоит из 10 человек, разбросанных по всему миру. + +Основная команда создает сеть Obol Network, протокол, способствующий минимизации доверительных ставок за счет проверки несколькими операторами. Это обеспечит доступ с низким уровнем доверия к доходности стейкинга Ethereum, который можно использовать в качестве основного строительного блока в различных продуктах Web3. + +## О этой документации + +Это руководство предназначено для разработчиков и стейкеров, желающих использовать сеть Obol для многостороннего стейкинга. Чтобы внести свой вклад в эту документацию, перейдите в наш [Github repository](https://github.com/ObolNetwork/obol-docs) и отправьте запрос на вытягивание. + +## Нужна помощь? + +Если у вас есть какие-либо вопросы об этой документации или у вас возникли технические проблемы с любыми проектами, связанными с Оболом, зайдите в наш [Discord](https://discord.gg/n6ebKsX46w), где будет присутствовать член нашей команды или сообщества. рады помочь вам. diff --git a/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/sc/01_introducing-obol-managers.md b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/sc/01_introducing-obol-managers.md new file mode 100644 index 0000000000..956da14a97 --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/sc/01_introducing-obol-managers.md @@ -0,0 +1,61 @@ +--- +description: Как сеть Obol выглядит в сети? +--- + +# Смарт-контракты Obol + +Obol разрабатывает и поддерживает набор смарт-контрактов для использования с распределенными валидаторами. + +## Участники вывода средств + +Ключом к распределенному валидатору является понимание того, как обрабатывается вывод средств. Самый распространенный способ обработки вывода валидатора, управляемого несколькими разными людьми, — это использовать неизменяемый контракт получателя вывода с жестко закодированными в нем правилами распределения. + +For the time being Obol uses `0x01` withdrawal credentials, and intends to upgrade to [0x03 withdrawal credentials](https://ethresear.ch/t/0x03-withdrawal-credentials-simple-eth1-triggerable-withdrawals/10021) when smart contract initiated exits are enabled. +В настоящее время Obol использует учетные данные для вывода `0x01` и намеревается перейти на [учетные данные для вывода 0x03](https://ethresear.ch/t/0x03-withdrawal-credentials-simple-eth1-triggerable-withdrawals/10021), будут включены смарт-контрактом. + +### Собственный получатель вывода средств + +```solidity title="WithdrawalRecipientOwnable.sol" +// SPDX-License-Identifier: MIT + +pragma solidity ^0.8.0; + +import "@openzeppelin/contracts/access/Ownable.sol"; + +contract WithdrawalRecipientOwnable is Ownable { + receive() external payable {} + + function withdraw(address payable recipient) public onlyOwner { + recipient.transfer(address(this).balance); + } +} + +``` + +Собственный получатель вывода средств — это самый простой тип контракта с получателем вывода средств. Он реализует интерфейс Open Zeppelin `Ownable` и позволяет одному адресу вызывать функцию `withdraw()`, которая вытягивает весь эфир с адреса на адрес владельца (или другой указанный адрес). Вызов вывода также может финансировать разделение платы на сеть Obol и / или протокол, который развернул и создал этот DV. + +### Неизменяемый получатель вывода средств + +Неизменный получатель вывода аналогичен получателю, которым можно владеть, за исключением того, что владелец жестко запрограммирован во время создания, а возможность смены владельца удалена. Этот контракт следует использовать только как часть более крупной системы смарт-контрактов, например, стратегия хранилища yearn может использовать неизменяемый контракт получателя, поскольку его адрес хранилища никогда не должен меняться. + +## Реестры + +### Реестр депозитов + +Депозитный реестр позволяет сделать депозит и активацию распределенных валидаторов двумя отдельными процессами. В простом случае для DV регистр депозитов не требуется. Однако, когда лицо, вносящее эфир, не является той же организацией, что и операторы, производящие депозиты, необходим механизм координации, чтобы убедиться, что на каждый DV отправляется только один депозит в 32 eth. Реестр депозитов может предотвратить двойные депозиты, отдав распоряжение о выделении эфира депозитам валидаторов. + +### Реестр операторов + +Если подача депозитов в реестр депозитов должна ограничиваться только адресами из белого списка, простой реестр операторов может служить способом контроля того, кто может подавать депозиты в реестр депозитов. + + +### Реестр валидаторов + +Если необходимо управлять валидаторами в цепочке программно, а не вручную, когда люди инициируют выход, можно использовать реестр валидаторов. Депозиты, которые активируются, получают запись в реестре валидаторов, а валидаторы, использующие выходы 0x03, готовятся к удалению из реестра. Этот реестр можно использовать для координации множества валидаторов с похожими операторами и конфигурацией. + +:::note + +Реестры валидаторов зависят от еще не реализованной фичи выхода валидатора `0x03`. + +::: + diff --git a/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/sc/_category_.json b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/sc/_category_.json new file mode 100644 index 0000000000..035b376e43 --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/sc/_category_.json @@ -0,0 +1,5 @@ +{ + "label": "Смарт-контракты", + "position": 5, + "collapsed": true +} diff --git a/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/testnet.md b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/testnet.md new file mode 100644 index 0000000000..ed5d5709f6 --- /dev/null +++ b/i18n/ru/docusaurus-plugin-content-docs/version-v0.8.1/testnet.md @@ -0,0 +1,188 @@ +--- +sidebar_position: 13 +--- + +# Тестовые сети + +![Карта развития тестовых сетей](/img/ObolTestnetRoadmap.png) + +В ближайшие кварталы Obol Labs будет координировать и будет продолжать координировать и размещать ряд все более крупных тестовых сетей, чтобы помочь укрепить клиент charon и отрабатывать инструменты генерации ключей. + +Ниже приводится представление намеченной дорожной карты тестовой сети, функций, которые должны быть реализованы каждой тестовой сетью, а также их дата начала и продолжительность. + +# Тестовые сети + +- [x] [Dev Net 1](#devnet-1) +- [x] [Dev Net 2](#devnet-2) +- [ ] [Athena Public Testnet 1](#athena-public-testnet-1) +- [ ] [Bia Attack net](#bia-attack-net) +- [ ] [Circe Public Testnet 2](#cerce-public-testnet-ii) +- [ ] [Demeter Red/Blue net](#demeter-redblue-net) + +## Devnet 1 + +Первая тестовая сеть была нацелена на то, чтобы несколько доверенных операторов протестировали наши самые ранние обучающие руководства. Цель состояла в том, чтобы один пользователь выполнил эти руководства в одиночку, используя docker compose для запуска 4 клиентов charon и 4 разных клиентов валидатора (lighthouse, teku, lodestar и vouch) на одной машине с удаленным клиентом консенсуса. Ключи были созданы локально в charon и активированы с помощью существующей панели запуска. + + +**Участники:** Obol Dev Team, Client team advisors. + +**Состояние продукта:** Предварительный продукт + +**Сеть:** Kiln + +**Дата завершения:** Июнь 2022 + +**Продолжительность:** 1 неделя + +**Цели:** + +- Пользователь протестировал первое руководство на работоспособность. Devnet 2 будет групповым, поэтому нам нужно сначала правильно настроить одиночный запуск +- Подтвердить парадигму распределенного валидатора с 4 отдельными реализациями VC, работающими вместе, как один логический валидатор +- Получить основы мониторинга для следующей тестовой сети, где точный мониторинг будет важен при работе по сети. + +**Собранные данные с операторов:** + +- Заполняя форму, оператор перечисляет: + - Открытый ключ распределенного валидатора + - Любые трудности, с которыми он столкнулся при создании экземпляра кластера + - Любые варианты развертывания, для которых они хотели бы увидеть раннюю поддержку (например, Windows, cloud, dappnode и т.д.) + + +## Devnet 2 + +Вторая сеть разработчиков была нацелена на то, чтобы несколько доверенных операторов впервые протестировали наши самые ранние руководства _вместе_. + +Цель состояла в том, чтобы группы из 4 тестировщиков завершили групповое руководство, используя docker compose для запуска 4 клиентов charon и 4 различных клиентов валидаторов (lighthouse, teku, lodestar и vouch), каждый на своей домашней машине или на той которую они выбрали, запускает хотя бы консенсус клиента Kiln. + +В рамках этой тестовой сети операторы избегали использование charon в Интернет сети со статическим IP-адресом за счет использования узлов ретрансляции, размещенных на Obol. + +Этот devnet также впервые был протестирован с пользователями `charon dkg`. Панель запуска не использовалась, и этот dkg был вызван конфигурационным файлом манифеста, созданным локально одним оператором с помощью команды `charon create dkg`. + +Основной задачей этой сети разработчиков был сбор данных о производительности сети. Это был первый раз, когда charon запускался в невиртуальных сетях (то есть в реальном Интернете). Основное внимание было сосредоточено на эффективном сборе данных, на производительности в этой сети разработчиков, чтобы обеспечить сбор еще более глубоких данных о производительности сигнала при масштабировании в общедоступных тестовых сетях. + +**Участники:** Obol Dev Team, Client team advisors. + +**Состояние продукта:** Предварительный продукт + +**Сеть:** Kiln + +**Дата завершения:** Июль 2022 + +**Duration:** 2 недели + +**Цели:** + +- Пользовательское тестирование метода dkg +- Пользовательское тестирование сложности предоставления доступа к charon в общедоступном Интернете +- Размещение предложений по блокам +- Создание аналитической системы для внедрения сетевых трассировок из файлов дампа или конечных точек распределенной трассировки + + +## Athena Public Testnet 1 + +С учебными пособиями для соло и групповых вариантов, которые были разработаны и усовершенствованы. Цель первой общедоступной тестовой сети — впервые передать распределенные валидаторы в руки более широкого сообщества Proto. + +Основное внимание в этой тестовой сети уделяется опыту адаптации. Это первый раз, когда нам нужно предоставить исчерпывающие инструкции для максимально возможного количества платформ (Unix, Mac, Windows) на максимально возможном количестве языков (необходимо привлекать языковых модераторов в Discord). + +Основным результатом этой тестовой сети является большое количество принятых форм обратной связи, которую мы усовершенствовали со времен devnets 1 и 2. + +Это будет нестимулированная тестовая сеть, и она послужит основой для выяснения механизма сопротивления Sybil для более поздних стимулированных тестовых сетей. + +**Участники:** Obol Proto Community + +**Состояние продукта:** Абсолютный минимум + +**Сеть:** Görli + +**Намеченная дата запуска:** Август 2022 + +**Продолжительность:** 2 недели настройка кластера, 4 недели эксплуатации + +**Цели:** + +- Задействовать сообщество Obol Proto +- Сделать развертывание узлов валидатора Ethereum доступным +- Собрать большой бэклог ошибок, предложения по улучшению, добавлению, интеграции для платформы. + +**Форма регистрации:** [Перейти](https://obol.typeform.com/AthenaTestnet) + +## Bia Attack Net + +На данный момент мы максимально протестировали валидацию и подобрали правильный путь с поддерживающими участниками. Следующий шаг к клиенту, готовому к основной сети, — начать разрушать и подрывать его, насколько это возможно. + +Эта тестовая сеть нуждается в согласованной реализации в качестве жесткого требования, тогда как для Athena это могло быть необязательным. Намерение состоит в том, чтобы создать ряд инструментов тестирования, чтобы облегчить разрушение charon, включая выпуск нарушителя сети p2p, клиента фазз-тестирования, скриптов k6 для нагрузочного тестирования / взлома конечных точек RPC и многое другое. + +Цель состоит в том, чтобы найти как можно больше утечек памяти, уязвимых конечных точек и операций DoS, отсутствующих проверок подписи и многого другого. Эта тестовая сеть может быть сосредоточена вокруг хакатона, если это уместно. + +**Участники:** Obol Proto Community, Immunefi Bug Bounty searchers + +**Состояние продукта:** Улучшение клиентов сети + +**Намеченная дата запуска:** Сентябрь 2022 + +**Продолжительность:** 2-4 недели эксплуатации, в зависимости от того, насколько устойчивы клиенты + +**Сеть:** Merged Test Network (e.g. Görli) + +**Цели:** + +- Найти уязвимости Charon несколькими путями +- Улучшить защиту от DoS атак + +## Cerce Public Testnet II + +После работы над уязвимостями, которые, как мы надеемся, всплыли во время атаки сети, настало время поднять ставки на ступеньку выше. Вторая публичная тестовая сеть для Obol будет создана в партнерстве с Gnosis Chain и будет использовать реальных действующих валидаторов. + +Предполагается, что это будет первый раз, когда токенизация распределенного валидатора вступит в игру. Obol намеревается позволить операторам-кандидатам формировать группы, создавать ключи, указывающие на предварительно определенные адреса вывода средств, контролируемые Obol, и отправлять фидбек в виде формы нашей команде тестовой сети, включая созданные данные депозита, файл блокировки манифеста и данные выхода. (Таким образом, мы можем проверить, что публичный ключ валидатора, который они отправляют, является DV) + +Как только команда тестовой сети подтвердит, что операторы являются реальными людьми, а не сибилами (Sybil), атакующими тестовую сеть, которая создала законные ключи DV, их валидатор будет активирован с помощью Obol GNO. + +В конце периода тестовой сети все валидаторы будут отключены, и их производительность будет оцениваться для определения поощрения, которое они получат. + +**Участники:** Obol Proto Community, Gnosis Community, Ethereum Staking Community + +**Состояние продукта:** MVP ( стадия разработки минимума для работы продукт ) + +**Сеть:** Merged Gnosis Chain + +**Намеченная дата запуска:** Q4 2022 + +**Продолжительность:** 6 недель + +**Network:** Merged Gnosis Chain + +**Цели:** + +- Широкое участие сообщества +- Первая поощраемая тестовая сеть Obol +- Распределенный валидатор возвращает конкурентные клиенты по сравнению с одиночными валидаторами. +- Запустить неоправданно большой процент поощраемой тестовой сети, чтобы увидеть производительность сети в масштабе, если большинство валидаторов перейдут на архитектуру DV. + +## Demeter Red/Blue Net + +Последняя запланированная тестовая сеть перед предполагаемым развертыванием основной сети — это тестовая сеть, которая черпает вдохновение в индустрии кибербезопасности и использует Red Teams и Blue Teams. + +В кибербезопасности красная команда находится в нападении, а синяя команда в защите. В случае Obol, Операторы будут сгруппированы в кластеры в зависимости от приложения и тайно назначены либо в красную, либо в синюю команду. После того, как валидаторы активны, целью красных команд будет разрушение кластера в меру своих возможностей, а их вознаграждение будет зависеть от того, насколько кластер работает хуже оптимального. + +Члены синей команды будут стремиться поддерживать свой кластер в сети и подписываться. Если они смогут держать свой распределенный валидатор в сети большую часть времени, несмотря на все усилия красной команды, они получат слишком большую награду по сравнению с наградой красной команды. + +Цель этой тестовой сети — показать, что даже при наличии прямого стимулирования византийских участников клиент распределенного валидатора может оставаться в сети и своевременно проходить проверку, что еще больше укрепляет доверие к готовности основной сети клиентов. + +**Участники:** Obol Proto Community, Gnosis Community, Ethereum Staking Community, Immunefi Bug Bounty searchers + +**Состояние продукта:** Основная сеть готова + +**Network:** Merged Gnosis Chain + +**Target start date:** Q4 2022 + +**Duration:** 4 недели + +**Сеть:** Merged Gnosis Chain + +**Цели:** + +- Даже при наличии мотивированных византийских участниках распределенные валидаторы могут надежно оставаться в сети. +- Узлы Charon не могут быть атакованы DoS'ом. +- Продемонстрировать, что отказоустойчивая проверка реальна, безопасна и конкурентоспособна по стоимости. +- Функция Charon завершена и готова к аудиту