Added new language to docs [ru]

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: {

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). 

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. После того, как все тесты на готовность пройдены, один оператор активирует распределенный валидатор(ы) с депозитом в цепочке.

i18n/ru/docusaurus-plugin-content-docs/current/dv/04_middleware-daemon.md

@@ -0,0 +1,15 @@
+---
+description: Архитектура развертывания для клиента распределенного валидатора
+---
+
+# Архитектура промежуточного программного обеспечения
+
+<p align="center"><img src="/img/DistributedValidatorCluster.svg" /></p>
+
+Демон Charon является промежуточным программным обеспечением между [API узла маяка](https://ethereum.github.io/beacon-APIs/) уровня консенсуса и любыми нижестоящими клиентами валидатора. 
+
+### Цель
+
+Промежуточное программное обеспечение стремится быть без состояния (stateless) и статически настроенным через файловые системы 777. Отсутствие API-интерфейса уровня управления для онлайн-реконфигурации преднамеренно сделано для того, чтобы по умолчанию операции были простыми и безопасными.
+
+Первоначально пакет `charon` будет доступен в виде образа Docker и в виде бинарных сборок. Планируется пакет APT с интеграцией systemd.

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/[email protected]/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.
+
+

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).