-## Requirements +## Требования - git - npm -## Run the Codex Installer +## Запуск Codex Installer -To start the Codex Installer, simply run the following command in your terminal : +Чтобы запустить Codex Installer, просто выполните следующую команду в вашем терминале: ```bash npx codexstorage ``` -## Download and install Codex +## Скачивание и установка Codex -Once you run the above command, you will be seeing a command line interface with various options as below : +После выполнения вышеуказанной команды вы увидите интерфейс командной строки с различными опциями, как показано ниже:  -On selecting the `Download and install Codex` option, you will be asked to agree to the privacy disclaimer and provide an installation path to finish your installation. If you do not wish to agree to the data collection disclaimer, you can select the `Exit` option and follow the instructions [Manual setup](/learn/quick-start.md) to install Codex without using the Installer. +При выборе опции `Download and install Codex` вам будет предложено согласиться с отказом от ответственности за конфиденциальность и указать путь установки для завершения установки. Если вы не хотите соглашаться с отказом от ответственности за сбор данных, вы можете выбрать опцию `Exit` и следовать инструкциям [Ручной настройки](/learn/quick-start.md) для установки Codex без использования Installer. -## Run the Codex node +## Запуск узла Codex -Upon selecting the `Run Codex node` option, you will be asked for your Listening port (default is 8070) and discovery port (default is 8090). You can optionally provide your ERC20 public address to associate your testnet node with your wallet (Please note that Codex does not promise any incentives for running a node yet). +При выборе опции `Run Codex node` вам будет предложено указать порт прослушивания (по умолчанию 8070) и порт обнаружения (по умолчанию 8090). Вы можете дополнительно указать ваш публичный адрес ERC20 для привязки вашего тестового узла к вашему кошельку (Обратите внимание, что Codex пока не обещает никаких стимулов за запуск узла).  -Keep this terminal window open as closing this will terminate your node. +Держите это окно терминала открытым, так как его закрытие приведет к завершению работы вашего узла. -## Get the *ALTRUISTIC MODE* role on Codex discord +## Получение роли *ALTRUISTIC MODE* в Discord Codex -With that, your Codex node should be up and running. You can check the information and status of your node by proceeding to the third option. +После этого ваш узел Codex должен быть запущен и работать. Вы можете проверить информацию и статус вашего узла, выбрав третью опцию.  -To claim the *ALTRUISTIC MODE* role, join the [Codex Discord](https://discord.gg/codex-storage) and go to the #bot channel. Run the `/node
-To make sure that your Codex node is running smoothly, you will need to make sure that your machine has the following requirements : +Чтобы обеспечить бесперебойную работу вашего узла Codex, необходимо убедиться, что ваша машина соответствует следующим требованиям: -## Dependencies +## Зависимости - git - npm -## Port Forwarding +## Проброс портов -Codex requires two ports to be open on your machine in order to function properly. However, please note that the **ports provided below are configurable** based on your preference : +Для правильной работы Codex требуется, чтобы на вашей машине были открыты два порта. Обратите внимание, что **порты, указанные ниже, настраиваются** в соответствии с вашими предпочтениями: - | Protocol | Service | Port | - | -------- | --------- | ------ | - | UDP | Discovery | Default : `8090` | - | TCP | Transport | Default : `8070` | + | Протокол | Сервис | Порт | + | -------- | ---------- | ------ | + | UDP | Discovery | По умолчанию: `8090` | + | TCP | Transport | По умолчанию: `8070` | -If you are not familiar with port forwarding, you can follow the instructions [here](https://www.noip.com/support/knowledgebase/general-port-forwarding-guide/). \ No newline at end of file +Если вы не знакомы с пробросом портов, вы можете следовать инструкциям [здесь](https://www.noip.com/support/knowledgebase/general-port-forwarding-guide/). \ No newline at end of file diff --git a/learn/installer/upload-and-download.md b/learn/installer/upload-and-download.md index 04f36ff..690d78d 100644 --- a/learn/installer/upload-and-download.md +++ b/learn/installer/upload-and-download.md @@ -1,27 +1,27 @@ -# Upload/Download Files in the Testnet +# Загрузка/Скачивание файлов в тестовой сети -You can either upload or download files by using the Upload / Download option in the Codex Installer or by using the Codex GUI app (recommended). +Вы можете загружать или скачивать файлы, используя опцию Upload / Download в Codex Installer или с помощью приложения Codex GUI (рекомендуется). ## Codex Vault -Codex Vault is a GUI web application that can help you interact with the Codex testnet by uploading and downloading files. Once you have your Codex node running using the installer, you can access the Codex Vault by going to https://app.codex.storage +Codex Vault - это веб-приложение с графическим интерфейсом, которое помогает вам взаимодействовать с тестовой сетью Codex путем загрузки и скачивания файлов. После запуска вашего узла Codex с помощью установщика, вы можете получить доступ к Codex Vault, перейдя по адресу https://app.codex.storage  -Ensure that you have all the necessary conditions checked in the 'health check' section before you try uploading or downloading files. +Убедитесь, что все необходимые условия отмечены в разделе 'health check' перед попыткой загрузки или скачивания файлов. -### Uploading and Downloading Files +### Загрузка и скачивание файлов -To upload a file, you can either drag and drop the file to the upload area or click on the 'upload' button. You will be able to find a unique CID for the file once it has been uploaded. +Чтобы загрузить файл, вы можете либо перетащить файл в область загрузки, либо нажать кнопку 'upload'. После загрузки вы сможете найти уникальный CID для файла. -To download a file, enter the CID of the file in the 'download' section and click on the 'download' button. +Чтобы скачать файл, введите CID файла в разделе 'download' и нажмите кнопку 'download'.  -## What's next? +## Что дальше? -Now that you know how to upload and download files in the testnet, you can try to explore some experimental features and build your own applications on top of Codex : +Теперь, когда вы знаете, как загружать и скачивать файлы в тестовой сети, вы можете попробовать изучить некоторые экспериментальные функции и создать свои собственные приложения на основе Codex: -- [Use Codex REST API](/learn/using) -- [Running Codex with Local Marketplace support](/learn/local-marketplace) -- [Build applications using codex-js Library](https://github.com/codex-storage/codex-js) \ No newline at end of file +- [Использование REST API Codex](/learn/using) +- [Запуск Codex с поддержкой локального маркетплейса](/learn/local-marketplace) +- [Создание приложений с использованием библиотеки codex-js](https://github.com/codex-storage/codex-js) \ No newline at end of file diff --git a/learn/local-marketplace.md b/learn/local-marketplace.md index 352f665..5950591 100644 --- a/learn/local-marketplace.md +++ b/learn/local-marketplace.md @@ -1,56 +1,56 @@ --- outline: [2, 3] --- -# Running a Local Codex Network with Marketplace Support +# Запуск локальной сети Codex с поддержкой маркетплейса -This tutorial will teach you how to run a small Codex network with the -_storage marketplace_ enabled; i.e., the functionality in Codex which -allows participants to offer and buy storage in a market, ensuring that -storage providers honor their part of the deal by means of cryptographic proofs. +Это руководство научит вас, как запустить небольшую сеть Codex с включенным +_маркетплейсом хранения_; т.е. функциональностью в Codex, которая +позволяет участникам предлагать и покупать хранилище на рынке, обеспечивая +честное выполнение обязательств поставщиками хранилища с помощью криптографических доказательств. -In this tutorial, you will: +В этом руководстве вы: -1. [Set Up a Geth PoA network](#_1-set-up-a-geth-poa-network); -2. [Set up The Marketplace](#_2-set-up-the-marketplace); -3. [Run Codex](#_3-run-codex); -4. [Buy and Sell Storage in the Marketplace](#_4-buy-and-sell-storage-on-the-marketplace). +1. [Настроите сеть Geth PoA](#_1-set-up-a-geth-poa-network); +2. [Настроите маркетплейс](#_2-set-up-the-marketplace); +3. [Запустите Codex](#_3-run-codex); +4. [Купите и продайте хранилище на маркетплейсе](#_4-buy-and-sell-storage-on-the-marketplace). -## Prerequisites +## Предварительные требования -To complete this tutorial, you will need: +Для прохождения этого руководства вам понадобится: -* the [geth](https://github.com/ethereum/go-ethereum) Ethereum client; - You need version `1.13.x` of geth as newer versions no longer support - Proof of Authority (PoA). This tutorial was tested using geth version `1.13.15`. -* a Codex binary, which [you can compile from source](https://github.com/codex-storage/nim-codex?tab=readme-ov-file#build-and-run). +* клиент Ethereum [geth](https://github.com/ethereum/go-ethereum); + Вам нужна версия `1.13.x` geth, так как более новые версии больше не поддерживают + Proof of Authority (PoA). Это руководство было протестировано с версией geth `1.13.15`. +* бинарный файл Codex, который [можно собрать из исходного кода](https://github.com/codex-storage/nim-codex?tab=readme-ov-file#build-and-run). -We will also be using [bash](https://en.wikipedia.org/wiki/Bash_(Unix_shell)) -syntax throughout. If you use a different shell, you may need to adapt -things to your platform. +Мы также будем использовать синтаксис [bash](https://en.wikipedia.org/wiki/Bash_(Unix_shell)) +на протяжении всего руководства. Если вы используете другую оболочку, вам может потребоваться адаптировать +команды под вашу платформу. -To get started, create a new folder where we will keep the tutorial-related -files so that we can keep them separate from the codex repository. -We assume the name of the folder to be `marketplace-tutorial`. +Для начала создайте новую папку, где мы будем хранить файлы, связанные с руководством, +чтобы держать их отдельно от репозитория codex. +Предположим, что имя папки будет `marketplace-tutorial`. -## 1. Set Up a Geth PoA Network +## 1. Настройка сети Geth PoA -For this tutorial, we will use a simple -[Proof-of-Authority](https://github.com/ethereum/EIPs/issues/225) network -with geth. The first step is creating a _signer account_: an account which -will be used by geth to sign the blocks in the network. -Any block signed by a signer is accepted as valid. +Для этого руководства мы будем использовать простую +[Proof-of-Authority](https://github.com/ethereum/EIPs/issues/225) сеть +с geth. Первым шагом является создание _учетной записи подписанта_: учетной записи, которая +будет использоваться geth для подписи блоков в сети. +Любой блок, подписанный подписантом, принимается как действительный. -### 1.1. Create a Signer Account +### 1.1. Создание учетной записи подписанта -To create a signer account, from the `marketplace-tutorial` directory run: +Чтобы создать учетную запись подписанта, из директории `marketplace-tutorial` выполните: ```bash geth account new --datadir geth-data ``` -The account generator will ask you to input a password, which you can -leave blank. It will then print some information, -including the account's public address: +Генератор учетных записей попросит вас ввести пароль, который вы можете +оставить пустым. Затем он выведет некоторую информацию, +включая публичный адрес учетной записи: ```bash INFO [09-29|16:49:24.244] Maximum peer count ETH=50 total=50 @@ -69,37 +69,37 @@ Path of the secret key file: geth-data/keystore/UTC--2024-09-29T14-49-31.6552720 - You must REMEMBER your password! Without the password, it's impossible to decrypt the key! ``` -In this example, the public address of the signer account is +В этом примере публичный адрес учетной записи подписанта - `0x33A904Ad57D0E2CB8ffe347D3C0E83C2e875E7dB`. -Yours will print a different address. Save it for later usage. +У вас будет выведен другой адрес. Сохраните его для дальнейшего использования. -Next set an environment variable for later usage: +Затем установите переменную окружения для дальнейшего использования: ```bash export GETH_SIGNER_ADDR="0x0000000000000000000000000000000000000000" echo ${GETH_SIGNER_ADDR} > geth_signer_address.txt ``` -> Here make sure you replace `0x0000000000000000000000000000000000000000` -> with your public address of the signer account -> (`0x33A904Ad57D0E2CB8ffe347D3C0E83C2e875E7dB` in our example). +> Здесь убедитесь, что вы заменили `0x0000000000000000000000000000000000000000` +> на ваш публичный адрес учетной записи подписанта +> (`0x33A904Ad57D0E2CB8ffe347D3C0E83C2e875E7dB` в нашем примере). -### 1.2. Configure The Network and Create the Genesis Block +### 1.2. Настройка сети и создание генезис-блока -The next step is telling geth what kind of network you want to run. -We will be running a [pre-merge](https://ethereum.org/en/roadmap/merge/) -network with Proof-of-Authority consensus. -To get that working, create a `network.json` file. +Следующий шаг - указать geth, какую сеть вы хотите запустить. +Мы будем запускать [pre-merge](https://ethereum.org/en/roadmap/merge/) +сеть с консенсусом Proof-of-Authority. +Чтобы это работало, создайте файл `network.json`. -If you set the `GETH_SIGNER_ADDR` variable above you can run the following -command to create the `network.json` file: +Если вы установили переменную `GETH_SIGNER_ADDR` выше, вы можете выполнить следующую +команду для создания файла `network.json`: ```bash echo "{\"config\": { \"chainId\": 12345, \"homesteadBlock\": 0, \"eip150Block\": 0, \"eip155Block\": 0, \"eip158Block\": 0, \"byzantiumBlock\": 0, \"constantinopleBlock\": 0, \"petersburgBlock\": 0, \"istanbulBlock\": 0, \"berlinBlock\": 0, \"londonBlock\": 0, \"arrowGlacierBlock\": 0, \"grayGlacierBlock\": 0, \"clique\": { \"period\": 1, \"epoch\": 30000 } }, \"difficulty\": \"1\", \"gasLimit\": \"8000000\", \"extradata\": \"0x0000000000000000000000000000000000000000000000000000000000000000${GETH_SIGNER_ADDR:2}0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000\", \"alloc\": { \"${GETH_SIGNER_ADDR}\": { \"balance\": \"10000000000000000000000\"}}}" > network.json ``` -You can also manually create the file remembering update it with your -signer public address: +Вы также можете создать файл вручную, не забыв обновить его своим +публичным адресом подписанта: ```json { @@ -133,49 +133,48 @@ signer public address: } ``` -Note that the signer account address is embedded in two different places: -* inside of the `"extradata"` string, surrounded by zeroes and stripped of - its `0x` prefix; -* as an entry key in the `alloc` session. - Make sure to replace that ID with the account ID that you wrote down in - [Step 1.1](#_1-1-create-a-signer-account). +Обратите внимание, что адрес учетной записи подписанта встроен в два разных места: +* внутри строки `"extradata"`, окруженный нулями и без префикса `0x`; +* как ключ записи в секции `alloc`. + Убедитесь, что вы заменили этот ID на ID учетной записи, который вы записали в + [Шаге 1.1](#_1-1-create-a-signer-account). -Once `network.json` is created, you can initialize the network with: +После создания `network.json` вы можете инициализировать сеть с помощью: ```bash geth init --datadir geth-data network.json ``` -The output of the above command you may include some warnings, like: +В выводе этой команды могут быть предупреждения, например: ```bash WARN [08-21|14:48:12.305] Unknown config environment variable envvar=GETH_SIGNER_ADDR ``` -or even errors when running the command for the first time: +или даже ошибки при первом запуске команды: ```bash ERROR[08-21|14:48:12.399] Head block is not reachable ``` -The important part is that at the end you should see something similar to: +Важно, что в конце вы должны увидеть что-то похожее на: ```bash INFO [08-21|14:48:12.639] Successfully wrote genesis state database=lightchaindata hash=768bf1..42d06a ``` -### 1.3. Start your PoA Node +### 1.3. Запуск вашего PoA узла -We are now ready to start our $1$-node, private blockchain. -To launch the signer node, open a separate terminal in the same working -directory and make sure you have the `GETH_SIGNER_ADDR` set. -For convenience use the `geth_signer_address.txt`: +Теперь мы готовы запустить нашу $1$-узловую приватную блокчейн-сеть. +Чтобы запустить узел подписанта, откройте отдельный терминал в той же рабочей +директории и убедитесь, что у вас установлена переменная `GETH_SIGNER_ADDR`. +Для удобства используйте `geth_signer_address.txt`: ```bash export GETH_SIGNER_ADDR=$(cat geth_signer_address.txt) ``` -Having the `GETH_SIGNER_ADDR` variable set, run: +Имея установленную переменную `GETH_SIGNER_ADDR`, выполните: ```bash geth\ @@ -190,14 +189,14 @@ geth\ --allow-insecure-unlock ``` -Note that, once again, the signer account created in -[Step 1.1](#_1-1-create-a-signer-account) appears both in -`--unlock` and `--allow-insecure-unlock`. +Обратите внимание, что учетная запись подписанта, созданная в +[Шаге 1.1](#_1-1-create-a-signer-account), снова появляется как в +`--unlock`, так и в `--allow-insecure-unlock`. -Geth will prompt you to insert the account's password as it starts up. -Once you do that, it should be able to start up and begin "mining" blocks. +Geth попросит вас ввести пароль учетной записи при запуске. +После этого он должен запуститься и начать "майнить" блоки. -Also here, you may encounter errors like: +Здесь также могут возникнуть ошибки, например: ```bash ERROR[08-21|15:00:27.625] Bootstrap node filtered by netrestrict id=c845e51a5e470e44 ip=18.138.108.67 @@ -206,41 +205,41 @@ ERROR[08-21|15:00:27.625] Bootstrap node filtered by netrestrict id=ef2d7ab886 ERROR[08-21|15:00:27.625] Bootstrap node filtered by netrestrict id=6b36f791352f15eb ip=157.90.35.166 ``` -You can safely ignore them. +Их можно безопасно игнорировать. -If the command above fails with: +Если команда выше завершается с ошибкой: ```bash Fatal: Failed to register the Ethereum service: only PoS networks are supported, please transition old ones with Geth v1.13.x ``` -make sure, you are running the correct Geth version -(see Section [Prerequisites](#prerequisites)) +убедитесь, что вы используете правильную версию Geth +(см. раздел [Предварительные требования](#prerequisites)) -## 2. Set Up The Marketplace +## 2. Настройка маркетплейса -You will need to open new terminal for this section and geth needs to be -running already. Setting up the Codex marketplace entails: +Для этого раздела вам нужно открыть новый терминал, и geth должен быть уже запущен. +Настройка маркетплейса Codex включает: -1. Deploying the Codex Marketplace contracts to our private blockchain -2. Setup Ethereum accounts we will use to buy and sell storage in - the Codex marketplace -3. Provisioning those accounts with the required token balances +1. Развертывание контрактов маркетплейса Codex в нашу приватную блокчейн-сеть +2. Настройку учетных записей Ethereum, которые мы будем использовать для покупки и продажи хранилища в + маркетплейсе Codex +3. Обеспечение этих учетных записей необходимыми балансами токенов -### 2.1. Deploy the Codex Marketplace Contracts +### 2.1. Развертывание контрактов маркетплейса Codex -Make sure you leave the `marketplace-tutorial` directory, and clone -the `codex-storage/nim-codex.git`: +Убедитесь, что вы вышли из директории `marketplace-tutorial` и клонируйте +`codex-storage/nim-codex.git`: ```bash git clone https://github.com/codex-storage/nim-codex.git ``` -> If you just want to clone the repo to run the tutorial, you can -> skip the history and just download the head of the master branch by using -> `--depth 1` option: `git clone --depth 1 https://github.com/codex-storage/nim-codex.git` +> Если вы хотите просто клонировать репозиторий для прохождения руководства, вы можете +> пропустить историю и просто скачать голову ветки master, используя +> опцию `--depth 1`: `git clone --depth 1 https://github.com/codex-storage/nim-codex.git` -Thus, our directory structure for the purpose of this tutorial looks like this: +Таким образом, структура директорий для целей этого руководства выглядит так: ```bash | @@ -248,190 +247,188 @@ Thus, our directory structure for the purpose of this tutorial looks like this: └-- marketplace-tutorial ``` -> You could clone the `codex-storage/nim-codex.git` to some other location. -> Just to keeps things nicely separated it is best to make sure that -> `nim-codex` is not under `marketplace-tutorial` directory. +> Вы можете клонировать `codex-storage/nim-codex.git` в другое место. -Now, from the `nim-codex` folder run: +Теперь из папки `nim-codex` выполните: ```bash make update && make ``` -> This may take a moment as it will also build the `nim` compiler. Be patient. +> Это может занять некоторое время, так как это также соберет компилятор `nim`. Будьте терпеливы. -Now, in order to start a local Ethereum network run: +Теперь, чтобы запустить локальную сеть Ethereum, выполните: ```bash cd vendor/codex-contracts-eth npm install ``` -> While writing the document we used `node` version `v20.17.0` and -> `npm` version `11.0.0`. +> При написании документа мы использовали `node` версии `v20.17.0` и +> `npm` версии `10.8.2`. -Before continuing you now must **wait until $256$ blocks are mined** -**in your PoAnetwork**, or deploy will fail. This should take about -$4$ minutes and $30$ seconds. You can check which block height you are -currently at by running the following command -**from the `marketplace-tutorial` folder**: +Прежде чем продолжить, вы должны **дождаться, пока будет добыто $256$ блоков** +**в вашей PoA сети**, иначе развертывание завершится неудачей. Это должно занять около +$4$ минут и $30$ секунд. Вы можете проверить, на какой высоте блока вы находитесь, +выполнив следующую команду +**из папки `marketplace-tutorial`**: ```bash geth attach --exec web3.eth.blockNumber ./geth-data/geth.ipc ``` -once that gets past $256$, you are ready to go. +как только это превысит $256$, вы готовы к работе. -To deploy contracts, from the `codex-contracts-eth` directory run: +Чтобы развернуть контракты, из директории `codex-contracts-eth` выполните: ```bash export DISTTEST_NETWORK_URL=http://localhost:8545 npx hardhat --network codexdisttestnetwork deploy ``` -If the command completes successfully, you will see the output similar -to this one: +Если команда завершится успешно, вы увидите вывод, похожий на этот: ```bash Deployed Marketplace with Groth16 Verifier at: 0xCf0df6C52B02201F78E8490B6D6fFf5A82fC7BCd ``` -> of course your address will be different. +> конечно, ваш адрес будет другим. -You are now ready to prepare the accounts. +Теперь вы готовы подготовить учетные записи. -### 2.2. Generate the Required Accounts +### 2.2. Генерация необходимых учетных записей -We will run $2$ Codex nodes: a **storage provider**, which will sell storage -on the network, and a **client**, which will buy and use such storage; -we therefore need two valid Ethereum accounts. We could create random -accounts by using one of the many tools available to that end but, since -this is a tutorial running on a local private network, we will simply -provide you with two pre-made accounts along with their private keys, -which you can copy and paste instead: +Мы будем запускать $2$ узла Codex: **поставщик хранилища**, который будет продавать хранилище +в сети, и **клиент**, который будет покупать и использовать такое хранилище; +поэтому нам нужны две действительные учетные записи Ethereum. Мы могли бы создать случайные +учетные записи, используя один из многих доступных инструментов, но, поскольку +это руководство работает в локальной приватной сети, мы просто предоставим вам +две предварительно созданные учетные записи вместе с их приватными ключами, +которые вы можете скопировать и вставить: -First make sure you're back in the `marketplace-tutorial` folder and -not the `codex-contracts-eth` subfolder. Then set these variables: +Сначала убедитесь, что вы вернулись в папку `marketplace-tutorial` и +не находитесь в подпапке `codex-contracts-eth`. Затем установите эти переменные: -**Storage:** +**Хранилище:** ```bash export ETH_STORAGE_ADDR=0x45BC5ca0fbdD9F920Edd12B90908448C30F32a37 export ETH_STORAGE_PK=0x06c7ac11d4ee1d0ccb53811b71802fa92d40a5a174afad9f2cb44f93498322c3 echo $ETH_STORAGE_PK > storage.pkey && chmod 0600 storage.pkey ``` -**Client:** +**Клиент:** ```bash export ETH_CLIENT_ADDR=0x9F0C62Fe60b22301751d6cDe1175526b9280b965 export ETH_CLIENT_PK=0x5538ec03c956cb9d0bee02a25b600b0225f1347da4071d0fd70c521fdc63c2fc echo $ETH_CLIENT_PK > client.pkey && chmod 0600 client.pkey ``` -### 2.3. Provision Accounts with Tokens +### 2.3. Обеспечение учетных записей токенами -We now need to transfer some ETH to each of the accounts, as well as provide -them with some Codex tokens for the storage node to use as collateral and -for the client node to buy actual storage. +Теперь нам нужно перевести немного ETH на каждую из учетных записей, а также предоставить +им некоторые токены Codex для использования узлом хранилища в качестве залога и +для клиентского узла для покупки фактического хранилища. -Although the process is not particularly complicated, I suggest you use -[the script we prepared](https://github.com/gmega/local-codex-bare/blob/main/scripts/mint-tokens.js) -for that. This script, essentially: +Хотя процесс не особенно сложен, я предлагаю вам использовать +[скрипт, который мы подготовили](https://github.com/gmega/local-codex-bare/blob/main/scripts/mint-tokens.js) +для этого. Этот скрипт, по сути: -1. reads the Marketplace contract address and its ABI from the deployment data; -2. transfers $1$ ETH from the signer account to a target account if the target - account has no ETH balance; -3. mints $n$ Codex tokens and adds it into the target account's balance. +1. читает адрес контракта маркетплейса и его ABI из данных развертывания; +2. переводит $1$ ETH с учетной записи подписанта на целевую учетную запись, если целевая + учетная запись не имеет баланса ETH; +3. чеканит $n$ токенов Codex и добавляет их в баланс целевой учетной записи. -To use the script, just download it into a local file named `mint-tokens.js`, -for instance using `curl` (make sure you are in -the `marketplace-tutorial` directory): +Чтобы использовать скрипт, просто скачайте его в локальный файл с именем `mint-tokens.js`, +например, используя `curl` (убедитесь, что вы находитесь в +директории `marketplace-tutorial`): ```bash -# download script +# скачать скрипт curl https://raw.githubusercontent.com/gmega/codex-local-bare/main/scripts/mint-tokens.js -o mint-tokens.js ``` -Then run: +Затем выполните: ```bash -# set the contract file location (we assume you are in the marketplace-tutorial directory) +# установить расположение файла контракта (мы предполагаем, что вы находитесь в директории marketplace-tutorial) export CONTRACT_DEPLOY_FULL="../nim-codex/vendor/codex-contracts-eth/deployments/codexdisttestnetwork" export GETH_SIGNER_ADDR=$(cat geth_signer_address.txt) -# Installs Web3-js +# Устанавливает Web3-js npm install web3 -# Provides tokens to the storage account. -node ./mint-tokens.js $CONTRACT_DEPLOY_FULL/TestToken.json $GETH_SIGNER_ADDR 0x45BC5ca0fbdD9F920Edd12B90908448C30F32a37 1000000000000000000 -# Provides tokens to the client account. -node ./mint-tokens.js $CONTRACT_DEPLOY_FULL/TestToken.json $GETH_SIGNER_ADDR 0x9F0C62Fe60b22301751d6cDe1175526b9280b965 1000000000000000000 +# Предоставляет токены учетной записи хранилища. +node ./mint-tokens.js $CONTRACT_DEPLOY_FULL/TestToken.json $GETH_SIGNER_ADDR 0x45BC5ca0fbdD9F920Edd12B90908448C30F32a37 10000000000 +# Предоставляет токены клиентской учетной записи. +node ./mint-tokens.js $CONTRACT_DEPLOY_FULL/TestToken.json $GETH_SIGNER_ADDR 0x9F0C62Fe60b22301751d6cDe1175526b9280b965 10000000000 ``` -If you get a message like +Если вы получите сообщение типа ```bash Usage: mint-tokens.js
-
```batch
- :: Run Codex
+ :: Запустить Codex
codex ^
--data-dir=datadir ^
--disc-port=8090 ^
@@ -122,26 +122,26 @@ We may [run Codex in different modes](/learn/run#run), and for a quick start we
```
> [!TIP]
- > In the example above we use [Codex Testnet](/networks/testnet#bootstrap-nodes) bootstrap nodes and thus we join Testnet. If you would like to join a different network, please use [appropriate value](/networks/networks).
+ > В примере выше мы используем [узлы начальной загрузки тестовой сети Codex](/networks/testnet#bootstrap-nodes) и, таким образом, присоединяемся к тестовой сети. Если вы хотите присоединиться к другой сети, пожалуйста, используйте [соответствующее значение](/networks/networks).
-2. Configure port-forwarding for the TCP/UDP ports on your Internet router
- | Protocol | Service | Port |
- | -------- | --------- | ------ |
- | UDP | Discovery | `8090` |
- | TCP | Transport | `8070` |
+2. Настройте проброс портов TCP/UDP на вашем интернет-маршрутизаторе
+ | Протокол | Сервис | Порт |
+ | -------- | ---------- | ------ |
+ | UDP | Discovery | `8090` |
+ | TCP | Transport | `8070` |
-If you would like to purchase or sell storage, please consider to run [Codex node with marketplace support](/learn/run#codex-node-with-marketplace-support) or [Codex storage node](/learn/run#codex-storage-node).
+Если вы хотите покупать или продавать хранилище, рассмотрите возможность запуска [узла Codex с поддержкой маркетплейса](/learn/run#codex-node-with-marketplace-support) или [узла хранения Codex](/learn/run#codex-storage-node).
-## Interact with Codex
+## Взаимодействие с Codex
-When your Codex node is up and running you can interact with it using [Codex App UI](https://app.codex.storage) for files sharing.
+Когда ваш узел Codex запущен и работает, вы можете взаимодействовать с ним, используя [Пользовательский интерфейс приложения Codex](https://app.codex.storage) для обмена файлами.
-Also, you can interact with Codex using [Codex API](/developers/api) and for a walk-through of the API, consider following the [Using Codex](/learn/using) guide.
+Также вы можете взаимодействовать с Codex, используя [API Codex](/developers/api), и для ознакомления с API рассмотрите возможность следования руководству [Использование Codex](/learn/using).
-## Stay in touch
+## Оставайтесь на связи
-Want to stay up-date, or looking for further assistance? Try our [discord-server](https://discord.gg/codex-storage).
+Хотите быть в курсе или ищете дополнительную помощь? Попробуйте наш [дискорд-сервер](https://discord.gg/codex-storage).
-Ready to explore Codex functionality? Please [Join Codex Testnet](/networks/testnet).
+Готовы исследовать функциональность Codex? Пожалуйста, [Присоединитесь к тестовой сети Codex](/networks/testnet).
-If you want to run Codex locally without joining the Testnet, consider trying the [Codex Two-Client Test](/learn/local-two-client-test) or the [Running a Local Codex Network with Marketplace Support](/learn/local-marketplace).
+Если вы хотите запустить Codex локально без присоединения к тестовой сети, рассмотрите возможность попробовать [Тест с двумя клиентами Codex](/learn/local-two-client-test) или [Запуск локальной сети Codex с поддержкой маркетплейса](/learn/local-marketplace).
diff --git a/learn/run.md b/learn/run.md
index d0175e0..302470b 100644
--- a/learn/run.md
+++ b/learn/run.md
@@ -1,35 +1,35 @@
---
outline: [2, 4]
---
-# Run Codex
+# Запуск Codex
-As for now, Codex is implemented only in [Nim](https://nim-lang.org) and can be found in [nim-codex](https://github.com/codex-storage/nim-codex) repository.
+На данный момент Codex реализован только на [Nim](https://nim-lang.org) и находится в репозитории [nim-codex](https://github.com/codex-storage/nim-codex).
-It is a command-line application which may be run in a different ways:
- - [Using binary](#using-binary)
- - [Run as a service in Linux](#run-as-a-service-in-linux)
- - [Run as a service in Windows](#run-as-a-service-in-windows) (not supported yet)
- - [Using Docker](#using-docker)
- - [Using Docker Compose](#using-docker-compose)
- - [On Kubernetes](#on-kubernetes)
+Это консольное приложение, которое может быть запущено разными способами:
+ - [Использование бинарного файла](#using-binary)
+ - [Запуск как сервис в Linux](#run-as-a-service-in-linux)
+ - [Запуск как сервис в Windows](#run-as-a-service-in-windows) (пока не поддерживается)
+ - [Использование Docker](#using-docker)
+ - [Использование Docker Compose](#using-docker-compose)
+ - [На Kubernetes](#on-kubernetes)
-During the run, it is required to pass [configuration](#configuration) option to the application, which can be done in a different ways.
+При запуске необходимо передать [параметры конфигурации](#configuration) приложению, что можно сделать разными способами.
-## Configuration
+## Конфигурация
-It is possible to configure Codex node in several ways:
- 1. [CLI options](#cli-options)
- 2. [Environment variables](#environment-variables)
- 3. [Configuration file](#configuration-file)
+Настроить узел Codex можно несколькими способами:
+ 1. [Параметры командной строки](#cli-options)
+ 2. [Переменные окружения](#environment-variables)
+ 3. [Файл конфигурации](#configuration-file)
-The order of priority is the same as above:
-[CLI options](#cli-options) --> [Environment variables](#environment-variables) --> [Configuration file](#configuration-file).
+Приоритет следующий:
+[Параметры командной строки](#cli-options) --> [Переменные окружения](#environment-variables) --> [Файл конфигурации](#configuration-file).
-### Common information
+### Общая информация
-#### Units
+#### Единицы измерения
-For some configuration options, we can pass values in common units like following:
+Для некоторых параметров конфигурации мы можем передавать значения в общепринятых единицах измерения:
```shell
--cache-size=1m/1M/1mb/1MB
--storage-quota=2m/2M/2mb/2MB
@@ -38,117 +38,117 @@ For some configuration options, we can pass values in common units like followin
--block-ttl=2s/2S/2m/2M/2h/2H/2d/2D/2w/2W
```
-#### Logging
+#### Логирование
-Codex uses [Chronicles](https://github.com/status-im/nim-chronicles) logging library, which allows great flexibility in working with logs.
-Chronicles has the concept of topics, which categorize log entries into semantic groups.
+Codex использует библиотеку логирования [Chronicles](https://github.com/status-im/nim-chronicles), которая обеспечивает большую гибкость в работе с логами.
+Chronicles использует концепцию тем, которые группируют записи логов по семантическим группам.
-Using the `log-level` parameter, you can set the top-level log level like `--log-level="trace"`, but more importantly,
-you can set log levels for specific topics like `--log-level="info; trace: marketplace,node; error: blockexchange"`,
-which sets the top-level log level to `info` and then for topics `marketplace` and `node` sets the level to `trace` and so on.
+Используя параметр `log-level`, вы можете установить общий уровень логирования, например `--log-level="trace"`, но что более важно,
+вы можете установить уровни логирования для конкретных тем, например `--log-level="info; trace: marketplace,node; error: blockexchange"`,
+что устанавливает общий уровень логирования в `info`, а для тем `marketplace` и `node` устанавливает уровень `trace` и так далее.
-### CLI options
+### Параметры командной строки
```shell
codex --help
-Usage:
+Использование:
-codex [OPTIONS]... command
+codex [ПАРАМЕТРЫ]... команда
-The following options are available:
+Доступны следующие параметры:
- --config-file Loads the configuration from a TOML file [=none].
- --log-level Sets the log level [=info].
- --metrics Enable the metrics server [=false].
- --metrics-address Listening address of the metrics server [=127.0.0.1].
- --metrics-port Listening HTTP port of the metrics server [=8008].
- -d, --data-dir The directory where codex will store configuration and data
+ --config-file Загружает конфигурацию из TOML файла [=none].
+ --log-level Устанавливает уровень логирования [=info].
+ --metrics Включает сервер метрик [=false].
+ --metrics-address Адрес прослушивания сервера метрик [=127.0.0.1].
+ --metrics-port HTTP порт прослушивания сервера метрик [=8008].
+ -d, --data-dir Директория, где codex будет хранить конфигурацию и данные
[=/root/.cache/codex].
- -i, --listen-addrs Multi Addresses to listen on [=/ip4/0.0.0.0/tcp/0].
- -a, --nat NAT traversal method for determining the public address.
- Options: any, none, upnp, pmp, extip:add firewall rules using netsh
+добавить правила брандмауэра с помощью netsh
```batch - :: Add rules + :: Добавить правила netsh advfirewall firewall add rule name="Allow Codex (TCP-In)" protocol=TCP dir=in localport=8070 action=allow netsh advfirewall firewall add rule name="Allow Codex (UDP-In)" protocol=UDP dir=in localport=8090 action=allow - :: List rules + :: Показать правила netsh advfirewall firewall show rule name=all | find /I "Codex" - :: Delete rules + :: Удалить правила netsh advfirewall firewall delete rule name="Allow Codex (TCP-In)" netsh advfirewall firewall delete rule name="Allow Codex (UDP-In)" ```
-
-
-2. To download circuit files, we should pass directory, RPC endpoint and marketplace address to the circuit downloader:
- ```shell
- # Create circuit files folder
- mkdir -p datadir/circuits
- chmod 700 datadir/circuits
-
- # Download circuit files
- cirdl \
- datadir/circuits \
- https://rpc.testnet.codex.storage \
- 0xfFaF679D5Cbfdd5Dbc9Be61C616ed115DFb597ed
- ```
-
-2. Start Codex storage node
- ```shell
- codex \
- --data-dir=datadir \
- --bootstrap-node=spr:CiUIAhIhAiJvIcA_ZwPZ9ugVKDbmqwhJZaig5zKyLiuaicRcCGqLEgIDARo8CicAJQgCEiECIm8hwD9nA9n26BUoNuarCEllqKDnMrIuK5qJxFwIaosQ3d6esAYaCwoJBJ_f8zKRAnU6KkYwRAIgM0MvWNJL296kJ9gWvfatfmVvT-A7O2s8Mxp8l9c8EW0CIC-h-H-jBVSgFjg3Eny2u33qF7BDnWFzo7fGfZ7_qc9P \
- --nat=any \
- --disc-port=8090 \
- --listen-addrs=/ip4/0.0.0.0/tcp/8070 \
- persistence \
- --eth-provider=https://rpc.testnet.codex.storage \
- --eth-private-key=eth.key \
- --marketplace-address=0xfFaF679D5Cbfdd5Dbc9Be61C616ed115DFb597ed \
- prover \
- --circuit-dir=datadir/circuits
- ```
+```shell
+codex \
+ --data-dir=datadir \
+ --bootstrap-node=spr:CiUIAhIhAiJvIcA_ZwPZ9ugVKDbmqwhJZaig5zKyLiuaicRcCGqLEgIDARo8CicAJQgCEiECIm8hwD9nA9n26BUoNuarCEllqKDnMrIuK5qJxFwIaosQ3d6esAYaCwoJBJ_f8zKRAnU6KkYwRAIgM0MvWNJL296kJ9gWvfatfmVvT-A7O2s8Mxp8l9c8EW0CIC-h-H-jBVSgFjg3Eny2u33qF7BDnWFzo7fGfZ7_qc9P \
+ --nat=any \
+ --disc-port=8090 \
+ --listen-addrs=/ip4/0.0.0.0/tcp/8070 \
+ --api-cors-origin="*" \
+ --eth-provider=ws://localhost:8545 \
+ --eth-account=0x45BC5ca0fbdD9F920Edd12B90908448C30F32a37 \
+ --eth-private-key=0x06c7ac11d4ee1d0ccb53811b71802fa92d40a5a174afad9f2cb44f93498322c3 \
+ --marketplace-address=0x1234567890123456789012345678901234567890
+```
> [!NOTE]
-> You would need to pass a bootstrap nodes, blockchain RPC endpoint and marketplace address based on the [network](/networks/networks) you would like to join.
-
+> Для работы с маркетплейсом необходимо иметь запущенный узел Ethereum и развернутый контракт Marketplace.
-After node is up and running, and your address has founds, you should be able to [sell the storage](/learn/using#create-storage-availability) using [API](/developers/api).
+#### Узел хранения Codex
-You also can use [Codex App UI](https://app.codex.storage) to sell the storage.
+Узел хранения Codex - это специальный тип узла, который предоставляет хранилище для других участников сети. Для его запуска необходимо добавить параметр `--validator`:
-#### Codex bootstrap node
-
-Bootstrap nodes are used just to help peers with the initial nodes discovery and we need to run Codex with just some basic options:
```shell
codex \
--data-dir=datadir \
+ --bootstrap-node=spr:CiUIAhIhAiJvIcA_ZwPZ9ugVKDbmqwhJZaig5zKyLiuaicRcCGqLEgIDARo8CicAJQgCEiECIm8hwD9nA9n26BUoNuarCEllqKDnMrIuK5qJxFwIaosQ3d6esAYaCwoJBJ_f8zKRAnU6KkYwRAIgM0MvWNJL296kJ9gWvfatfmVvT-A7O2s8Mxp8l9c8EW0CIC-h-H-jBVSgFjg3Eny2u33qF7BDnWFzo7fGfZ7_qc9P \
--nat=any \
- --disc-port=8090
+ --disc-port=8090 \
+ --listen-addrs=/ip4/0.0.0.0/tcp/8070 \
+ --api-cors-origin="*" \
+ --eth-provider=ws://localhost:8545 \
+ --eth-account=0x45BC5ca0fbdD9F920Edd12B90908448C30F32a37 \
+ --eth-private-key=0x06c7ac11d4ee1d0ccb53811b71802fa92d40a5a174afad9f2cb44f93498322c3 \
+ --marketplace-address=0x1234567890123456789012345678901234567890 \
+ --validator=true \
+ --validator-max-slots=1000 \
+ --reward-recipient=0x45BC5ca0fbdD9F920Edd12B90908448C30F32a37
```
-To get bootstrap node SPR we can use [API](https://api.codex.storage/#tag/Debug/operation/getDebugInfo) call:
-```shell
-curl -s localhost:8080/api/codex/v1/debug/info | jq -r '.spr'
-```
-```shell
-spr:CiUIAhIhApd79-AxPqwRDmu7Pk-berTDtoIoMz0ovKjo85Tz8CUdEgIDARo8CicAJQgCEiECl3v34DE-rBEOa7s-T5t6tMO2gigzPSi8qOjzlPPwJR0Qjv_WtwYaCwoJBFxzjbKRAh-aKkYwRAIgCiTq5jBTaJJb6lUxN-0uNCj8lkV9AGY682D21kIAMiICIE1yxrjbDdiSCiARnS7I2zqJpXC2hOvjB4JoL9SAAk67
-```
+> [!NOTE]
+> Узел хранения требует больше ресурсов, чем обычный узел, так как он должен хранить и обслуживать данные для других участников сети.
-That SPR record then can be used then by other peers for initial nodes discovery.
-
-We should keep in mind some important things about SPR record (see [ENR](https://eips.ethereum.org/EIPS/eip-778)):
-- It uses nodes public IP, discovery port (`--disc-port`) and private key (`--net-privkey`) for record creation
-- Specified data is signed on each run and will be changed but still contain specified node data when decoded
-- You can decode it by passing to the Codex node at run and with `--log-level=trace`
-
-For bootstrap node, it is required to forward just discovery port on your Internet router.
-
-### Run as a service in Linux
-
-We can run Codex as a service via [systemd](https://systemd.io) using following steps
-
- 1. Create an user for Codex
- ```shell
- sudo useradd \
- --system \
- --home-dir /opt/codex \
- --shell /usr/sbin/nologin \
- codex
- ```
- In case you would like to run commands using a created user, you could do it like following `sudo -u codex ls -la /opt/codex`.
-
- 2. Install Codex [using a script](https://github.com/codex-storage/get-codex) or [build from sources](/learn/build)
- ```shell
- # codex with cirdl
- curl -s https://get.codex.storage/install.sh | INSTALL_DIR=/usr/local/bin CIRDL=true bash
- ```
-
- 3. Create directories
- ```shell
- sudo mkdir -p /opt/codex/data
- ```
-
- 4. Create a configuration file
- ```shell
- sudo vi /opt/codex/codex.conf
- ```
- ```toml
- data-dir = "/opt/codex/data"
- listen-addrs = ["/ip4/0.0.0.0/tcp/8070"]
- nat = "extip:example
- - > [!CAUTION] - > Please use key generation service for demo purpose only. - - ```shell - response=$(curl -s https://key.codex.storage) - awk -F ': ' '/private/ {print $2}' <<<"${response}" > eth.key - awk -F ': ' '/address/ {print $2}' <<<"${response}" > eth.address - chmod 600 eth.key - ``` - Show your ethereum address: - ```shell - cat eth.address - ``` - ``` - 0x412665aFAb17768cd9aACE6E00537Cc6D5524Da9 - ``` -
-
+Для запуска Codex в Docker можно использовать официальный образ:
-2. Run Codex:
```shell
-docker run \
- --rm \
- -v $PWD/datadir:/datadir \
- -v $PWD/eth.key:/opt/eth.key \
+docker run -d \
+ --name codex \
-p 8070:8070 \
- -p 8080:8080 \
-p 8090:8090/udp \
- codexstorage/nim-codex:latest \
- codex \
- --data-dir=/datadir \
- --bootstrap-node=spr:CiUIAhIhAiJvIcA_ZwPZ9ugVKDbmqwhJZaig5zKyLiuaicRcCGqLEgIDARo8CicAJQgCEiECIm8hwD9nA9n26BUoNuarCEllqKDnMrIuK5qJxFwIaosQ3d6esAYaCwoJBJ_f8zKRAnU6KkYwRAIgM0MvWNJL296kJ9gWvfatfmVvT-A7O2s8Mxp8l9c8EW0CIC-h-H-jBVSgFjg3Eny2u33qF7BDnWFzo7fGfZ7_qc9P \
- --nat=any \
- --disc-port=8090 \
- --listen-addrs=/ip4/0.0.0.0/tcp/8070 \
- --api-cors-origin="*" \
- --api-bindaddr=0.0.0.0 \
- --api-port=8080 \
- persistence \
- --eth-provider=https://rpc.testnet.codex.storage \
- --eth-private-key=/opt/eth.key \
- --marketplace-address=0xfFaF679D5Cbfdd5Dbc9Be61C616ed115DFb597ed \
- prover \
- --circuit-dir=/datadir/circuits
+ -p 8080:8080 \
+ -v /path/to/data:/root/.codex \
+ codexstorage/codex:latest \
+ --data-dir=/root/.codex \
+ --bootstrap-node=spr:CiUIAhIhAiJvIcA_ZwPZ9ugVKDbmqwhJZaig5zKyLiuaicRcCGqLEgIDARo8CicAJQgCEiECIm8hwD9nA9n26BUoNuarCEllqKDnMrIuK5qJxFwIaosQ3d6esAYaCwoJBJ_f8zKRAnU6KkYwRAIgM0MvWNJL296kJ9gWvfatfmVvT-A7O2s8Mxp8l9c8EW0CIC-h-H-jBVSgFjg3Eny2u33qF7BDnWFzo7fGfZ7_qc9P \
+ --nat=any \
+ --disc-port=8090 \
+ --listen-addrs=/ip4/0.0.0.0/tcp/8070 \
+ --api-cors-origin="*"
```
-> [!NOTE]
-> You would need to pass a bootstrap nodes, blockchain RPC endpoint and marketplace address based on the [network](/networks/networks) you would like to join.
-
-### Using Docker Compose
-
-For Docker Compose, it is more suitable to use [environment variables](#environment-variables) for Codex configuration and we can reuse commands from example above, for Docker.
-
-[Codex storage node](#codex-storage-node)
-
-1. Create ethereum key file
- example
+This functionality is not supported yet :construction: - > [!CAUTION] - > Please use key generation service for demo purpose only. +### Использование Docker - ```shell - response=$(curl -s https://key.codex.storage) - awk -F ': ' '/private/ {print $2}' <<<"${response}" > eth.key - awk -F ': ' '/address/ {print $2}' <<<"${response}" > eth.address - chmod 600 eth.key - ``` - Show your ethereum address: - ```shell - cat eth.address - ``` - ``` - 0x412665aFAb17768cd9aACE6E00537Cc6D5524Da9 - ``` -
-
-
-2. Create `docker-compose.yaml` file:
- ```yaml
- services:
- codex:
- image: codexstorage/nim-codex:latest
- container_name: codex
- command:
- - codex
- - persistence
- - prover
- - --bootstrap-node=spr:CiUIAhIhAiJvIcA_ZwPZ9ugVKDbmqwhJZaig5zKyLiuaicRcCGqLEgIDARo8CicAJQgCEiECIm8hwD9nA9n26BUoNuarCEllqKDnMrIuK5qJxFwIaosQ3d6esAYaCwoJBJ_f8zKRAnU6KkYwRAIgM0MvWNJL296kJ9gWvfatfmVvT-A7O2s8Mxp8l9c8EW0CIC-h-H-jBVSgFjg3Eny2u33qF7BDnWFzo7fGfZ7_qc9P
- - --bootstrap-node=spr:CiUIAhIhAyUvcPkKoGE7-gh84RmKIPHJPdsX5Ugm_IHVJgF-Mmu_EgIDARo8CicAJQgCEiEDJS9w-QqgYTv6CHzhGYog8ck92xflSCb8gdUmAX4ya78QoemesAYaCwoJBES39Q2RAnVOKkYwRAIgLi3rouyaZFS_Uilx8k99ySdQCP1tsmLR21tDb9p8LcgCIG30o5YnEooQ1n6tgm9fCT7s53k6XlxyeSkD_uIO9mb3
- - --bootstrap-node=spr:CiUIAhIhA6_j28xa--PvvOUxH10wKEm9feXEKJIK3Z9JQ5xXgSD9EgIDARo8CicAJQgCEiEDr-PbzFr74--85TEfXTAoSb195cQokgrdn0lDnFeBIP0QzOGesAYaCwoJBK6Kf1-RAnVEKkcwRQIhAPUH5nQrqG4OW86JQWphdSdnPA98ErQ0hL9OZH9a4e5kAiBBZmUl9KnhSOiDgU3_hvjXrXZXoMxhGuZ92_rk30sNDA
- - --bootstrap-node=spr:CiUIAhIhA7E4DEMer8nUOIUSaNPA4z6x0n9Xaknd28Cfw9S2-cCeEgIDARo8CicAJQgCEiEDsTgMQx6vydQ4hRJo08DjPrHSf1dqSd3bwJ_D1Lb5wJ4Qt_CesAYaCwoJBEDhWZORAnVYKkYwRAIgFNzhnftocLlVHJl1onuhbSUM7MysXPV6dawHAA0DZNsCIDRVu9gnPTH5UkcRXLtt7MLHCo4-DL-RCMyTcMxYBXL0
- - --bootstrap-node=spr:CiUIAhIhAzZn3JmJab46BNjadVnLNQKbhnN3eYxwqpteKYY32SbOEgIDARo8CicAJQgCEiEDNmfcmYlpvjoE2Np1Wcs1ApuGc3d5jHCqm14phjfZJs4QrvWesAYaCwoJBKpA-TaRAnViKkcwRQIhANuMmZDD2c25xzTbKSirEpkZYoxbq-FU_lpI0K0e4mIVAiBfQX4yR47h1LCnHznXgDs6xx5DLO5q3lUcicqUeaqGeg
- - --bootstrap-node=spr:CiUIAhIhAuN-P1D0HrJdwBmrRlZZzg6dqllRNNcQyMDUMuRtg3paEgIDARpJCicAJQgCEiEC434_UPQesl3AGatGVlnODp2qWVE01xDIwNQy5G2DeloQm_L2vQYaCwoJBI_0zSiRAnVsGgsKCQSP9M0okQJ1bCpHMEUCIQDgEVjUp1RJGb59eRPs7RPYMSGAI_fo1yv70iBtnTqefQIgVoXszc87EGFVO3aaqorEYZ21OGRko5ho_Pybdyqa6AI
- - --bootstrap-node=spr:CiUIAhIhAsi_hgxFppWjHiKRwnYPX_qkB28dLtwK9c7apnlBanFuEgIDARpJCicAJQgCEiECyL-GDEWmlaMeIpHCdg9f-qQHbx0u3Ar1ztqmeUFqcW4Q2O32vQYaCwoJBNEmoCiRAnV2GgsKCQTRJqAokQJ1dipHMEUCIQDpC1isFfdRqNmZBfz9IGoEq7etlypB6N1-9Z5zhvmRMAIgIOsleOPr5Ra_Nk7BXmXGhe-YlLosH9jo83JtfWCy3-o
- environment:
- - CODEX_DATA_DIR=/datadir
- - NAT_PUBLIC_IP_AUTO=https://ip.codex.storage
- - CODEX_DISC_PORT=8090
- - CODEX_LISTEN_ADDRS=/ip4/0.0.0.0/tcp/8070
- - CODEX_API_CORS_ORIGIN="*"
- - CODEX_API_PORT=8080
- - CODEX_API_BINDADDR=0.0.0.0
- - CODEX_ETH_PROVIDER=https://rpc.testnet.codex.storage
- - CODEX_ETH_PRIVATE_KEY=/opt/eth.key
- - CODEX_MARKETPLACE_ADDRESS=0xfFaF679D5Cbfdd5Dbc9Be61C616ed115DFb597ed
- - CODEX_CIRCUIT_DIR=/datadir/circuits
- ports:
- - 8080:8080/tcp # API
- - 8090:8090/udp # Discovery
- - 8070:8070/tcp # Transport
- volumes:
- - ./datadir:/datadir
- - ./eth.key:/opt/eth.key
- logging:
- driver: json-file
- options:
- max-size: 100m
- max-file: 5
- ```
-
-3. Run Codex:
- ```shell
- docker compose up
- ```
+### Использование Docker Compose
+
+Для более сложных конфигураций можно использовать Docker Compose. Создайте файл `docker-compose.yml`:
+
+```yaml
+version: '3'
+services:
+ codex:
+ image: codexstorage/codex:latest
+ container_name: codex
+ ports:
+ - "8070:8070"
+ - "8090:8090/udp"
+ - "8080:8080"
+ volumes:
+ - /path/to/data:/root/.codex
+ command: >
+ --data-dir=/root/.codex
+ --bootstrap-node=spr:CiUIAhIhAiJvIcA_ZwPZ9ugVKDbmqwhJZaig5zKyLiuaicRcCGqLEgIDARo8CicAJQgCEiECIm8hwD9nA9n26BUoNuarCEllqKDnMrIuK5qJxFwIaosQ3d6esAYaCwoJBJ_f8zKRAnU6KkYwRAIgM0MvWNJL296kJ9gWvfatfmVvT-A7O2s8Mxp8l9c8EW0CIC-h-H-jBVSgFjg3Eny2u33qF7BDnWFzo7fGfZ7_qc9P
+ --nat=any
+ --disc-port=8090
+ --listen-addrs=/ip4/0.0.0.0/tcp/8070
+ --api-cors-origin="*"
+```
-> [!NOTE]
-> You would need to pass a bootstrap nodes, blockchain RPC endpoint and marketplace address based on the [network](/networks/networks) you would like to join.
+Затем выполните:
-### On Kubernetes
+```shell
+docker-compose up -d
+```
-Helm chart code is available in [helm-charts](https://github.com/codex-storage/helm-charts) repository, but chart was not published yet.
+### На Kubernetes
+
+Для запуска Codex в Kubernetes создайте файл `codex-deployment.yaml`:
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+ name: codex
+spec:
+ replicas: 1
+ selector:
+ matchLabels:
+ app: codex
+ template:
+ metadata:
+ labels:
+ app: codex
+ spec:
+ containers:
+ - name: codex
+ image: codexstorage/codex:latest
+ ports:
+ - containerPort: 8070
+ name: tcp
+ - containerPort: 8090
+ name: udp
+ protocol: UDP
+ - containerPort: 8080
+ name: api
+ volumeMounts:
+ - name: codex-data
+ mountPath: /root/.codex
+ command:
+ - codex
+ - --data-dir=/root/.codex
+ - --bootstrap-node=spr:CiUIAhIhAiJvIcA_ZwPZ9ugVKDbmqwhJZaig5zKyLiuaicRcCGqLEgIDARo8CicAJQgCEiECIm8hwD9nA9n26BUoNuarCEllqKDnMrIuK5qJxFwIaosQ3d6esAYaCwoJBJ_f8zKRAnU6KkYwRAIgM0MvWNJL296kJ9gWvfatfmVvT-A7O2s8Mxp8l9c8EW0CIC-h-H-jBVSgFjg3Eny2u33qF7BDnWFzo7fGfZ7_qc9P
+ - --nat=any
+ - --disc-port=8090
+ - --listen-addrs=/ip4/0.0.0.0/tcp/8070
+ - --api-cors-origin="*"
+ volumes:
+ - name: codex-data
+ persistentVolumeClaim:
+ claimName: codex-pvc
+```
+
+И примените его:
+
+```shell
+kubectl apply -f codex-deployment.yaml
+```
## How-tos
@@ -729,8 +526,6 @@ ipconfig | findstr /i "IPv4 Address"
ifconfig | grep "inet " | grep -v 127.0.0.1
```
-
-
## Known issues
[^multivalue-env-var]: Environment variables like `CODEX_BOOTSTRAP_NODE` and `CODEX_LISTEN_ADDRS` does not support multiple values. Please check [[Feature request] Support multiple SPR records via environment variable #525](https://github.com/codex-storage/nim-codex/issues/525), for more information.
diff --git a/learn/tokenomics-litepaper.md b/learn/tokenomics-litepaper.md
index 1c6973a..4fed2ec 100644
--- a/learn/tokenomics-litepaper.md
+++ b/learn/tokenomics-litepaper.md
@@ -1,276 +1,276 @@
---
outline: [1, 3]
---
-# Codex Tokenomics Litepaper - Testnet Version
+# Лайтбук по токеномике Codex - Версия для тестовой сети
-**Codex: A Decentralized Storage Protocol for Durable Information**
+**Codex: Децентрализованный протокол хранения для долговременной информации**
-# Legal Notices
+# Юридические уведомления
-*The information contained in this document is intended to be made available for informational purposes only and does not constitute a prospectus, nor an offer to buy, a solicitation or an invitation to buy, or a recommendation for any token or any security. Neither this document nor any of its content should be considered as creating any expectations or forming the basis of any contract, commitment or binding obligation. No information herein should be considered to contain or be relied upon as a promise, representation, warranty or guarantee, whether express or implied and whether as to the past, present or the future in relation to the projects and matters described herein. The information presented is a summary and does not purport to be accurate, reliable or complete. This document is under continuous legal review and may be amended or supplemented at any time without prior notice. No responsibility will be borne for the accuracy, reliability or completeness of information contained herein. Because of the high degree of risk and uncertainty described above, undue reliance should not be placed by anyone on any matters described in this document. Any tokens referenced in this document have not been registered under any securities laws and may not be offered or sold in any jurisdiction where such offer or sale would be prohibited.*
+*Информация, содержащаяся в этом документе, предназначена только для информационных целей и не является проспектом, предложением о покупке, приглашением к покупке или рекомендацией для любого токена или ценной бумаги. Ни этот документ, ни какое-либо его содержание не должны рассматриваться как создание каких-либо ожиданий или формирование основы любого контракта, обязательства или обязательства. Никакая информация здесь не должна рассматриваться как содержащая или полагаться на обещание, представление, гарантию или гарантию, будь то явная или подразумеваемая и будь то в отношении прошлого, настоящего или будущего в отношении проектов и вопросов, описанных здесь. Представленная информация является кратким изложением и не претендует на точность, надежность или полноту. Этот документ находится в постоянном юридическом рассмотрении и может быть изменен или дополнен в любое время без предварительного уведомления. Никакая ответственность не будет нести за точность, надежность или полноту информации, содержащейся здесь. Из-за высокой степени риска и неопределенности, описанных выше, никто не должен полагаться на какие-либо вопросы, описанные в этом документе. Любые токены, упомянутые в этом документе, не были зарегистрированы в соответствии с какими-либо законами о ценных бумагах и не могут быть предложены или проданы в любой юрисдикции, где такое предложение или продажа были бы запрещены.*
-*This document may contain forward-looking statements that are based only on current expectations, estimates, forecasts, assumptions and projections about the technology, industry and markets in general. The forward looking statements, projects, content and any other matters described in this document are subject to a high degree of risk and uncertainty. The roadmap, results, project descriptions, technical details, functionalities, and other features are subject to change based on, among other things, market conditions, technical developments, and regulatory environment. The actual development and results, including the order and the timeline, might differ materially from those anticipated in these forward-looking statements.*
+*Этот документ может содержать прогнозные заявления, которые основаны только на текущих ожиданиях, оценках, прогнозах, предположениях и проекциях о технологии, отрасли и рынках в целом. Прогнозные заявления, проекты, содержание и любые другие вопросы, описанные в этом документе, подвержены высокой степени риска и неопределенности. Дорожная карта, результаты, описания проектов, технические детали, функциональность и другие функции могут быть изменены на основе, среди прочего, рыночных условий, технических разработок и нормативной среды. Фактическая разработка и результаты, включая порядок и сроки, могут существенно отличаться от тех, которые ожидаются в этих прогнозных заявлениях.*
-*The information contained in this document does not constitute financial, legal, tax, investment, professional or other advice and should not be treated as such.*
+*Информация, содержащаяся в этом документе, не является финансовой, юридической, налоговой, инвестиционной, профессиональной или иной консультацией и не должна рассматриваться как таковая.*
-# Overview
+# Обзор
-## Scope
+## Область применения
-This document describes the Codex Tokenomics with elements that reflect the Testnet deployment of the Codex Protocol.
+Этот документ описывает токеномику Codex с элементами, отражающими развертывание тестовой сети протокола Codex.
-## What Codex Does
+## Что делает Codex
-Codex is a state-of-the-art decentralized storage platform that offers a novel solution that enhances data durability guarantees for storing vast amounts of data while eliminating any reliance on centralized institutions that could lead to a single point of failure.
+Codex - это современная децентрализованная платформа хранения, которая предлагает новое решение, повышающее гарантии долговечности данных для хранения огромных объемов данных, устраняя при этом любую зависимость от централизованных учреждений, которые могут привести к единой точке отказа.
-While centralized storage systems such as Google Cloud tout eleven nines of durability, durable file storage in distributed systems that provide censorship resistance and privacy are a vital prerequisite to use cases such as preserving factual records of history in network states.
+В то время как централизованные системы хранения, такие как Google Cloud, заявляют о одиннадцати девятках долговечности, долговременное хранение файлов в распределенных системах, обеспечивающих устойчивость к цензуре и конфиденциальность, является жизненно важным предварительным условием для использования, такого как сохранение фактических записей истории в сетевых состояниях.
-While no system can guarantee absolute protection against data loss, through its technical architecture, economic incentives, and algorithmic encoding, Codex is designed to provide highly decentralized data storage with high durability, resiliency to cloud failures, and resistance to censorship.
+Хотя ни одна система не может гарантировать абсолютную защиту от потери данных, благодаря своей технической архитектуре, экономическим стимулам и алгоритмическому кодированию, Codex разработан для обеспечения высоко децентрализованного хранения данных с высокой долговечностью, устойчивостью к сбоям облака и устойчивостью к цензуре.
-## How Codex Works
+## Как работает Codex
-Codex operates as a network of storage nodes, referred to herein as **Storage Providers** (SP), that store user data for the duration of a contract entered into by SPs and storage users, referred to herein simply as **Clients**.
+Codex работает как сеть узлов хранения, называемых здесь **Поставщиками Хранения** (SP), которые хранят пользовательские данные в течение срока контракта, заключенного между SP и пользователями хранения, называемыми здесь просто **Клиентами**.
-Storage contracts are initiated by a **Client** requesting to store a specified amount of data, for a specified amount of time, and at a specific price per the full contract. **Storage Providers** commit to slots to store redundant fragments of this data.
+Контракты на хранение инициируются **Клиентом**, запрашивающим хранение определенного объема данных на определенный срок и по определенной цене за весь контракт. **Поставщики Хранения** берут на себя обязательства по слотам для хранения избыточных фрагментов этих данных.
-The fact that **SPs** must post collateral (stake) in order to fill a slot helps protect against Sybil attacks, promoting diversity in storage nodes fulfilling each contract. Additionally, this collateral acts as an economic incentive to ensure that **SPs** fulfill their obligations to periodically prove that they are still in possession of the data in question.
+Тот факт, что **SP** должны размещать залог (стейкать) для заполнения слота, помогает защититься от атак Сибил, способствуя разнообразию узлов хранения, выполняющих каждый контракт. Кроме того, этот залог действует как экономический стимул для обеспечения того, чтобы **SP** выполняли свои обязательства по периодическому доказательству того, что они все еще владеют рассматриваемыми данными.
-This is achieved by periodic challenges to **SPs** to provide cryptographic proofs that demonstrate the data they have contracted to store can be retrieved. Codex incorporates Zero Knowledge (ZK) and Data Availability Sampling (DAS) to achieve low-cost, highly efficient, and reliable data loss detection.
+Это достигается путем периодических вызовов **SP** для предоставления криптографических доказательств, демонстрирующих, что данные, которые они обязались хранить, могут быть извлечены. Codex включает Zero Knowledge (ZK) и Data Availability Sampling (DAS) для достижения недорогого, высокоэффективного и надежного обнаружения потери данных.
-**SPs** are required to respond to these challenges, sending their proofs to **Validators,** who verify the validity of the proofs and posts to the blockchain only the absence of a proof. This reduces costs of validating proofs, while not affecting the **Protocol**’s security.
+**SP** должны отвечать на эти вызовы, отправляя свои доказательства **Валидаторам**, которые проверяют действительность доказательств и публикуют в блокчейне только отсутствие доказательства. Это снижает затраты на проверку доказательств, не влияя на безопасность **Протокола**.
-Should SPs fail to prove a fixed number of times they still have the data in question, or send an invalid proof, their collateral is partially slashed. The slash penalty is a fixed percentage of the total collateral. This slashing continues until a certain number of slashings is reached, at which point the entire collateral is slashed. At this moment, the SP slot is considered “abandoned”. The slashed collateral is used as an incentive for a new **SP** to take over the failed slot through the “slot recovery mechanism” (discussed further later). This ensures the collateral provides an economic incentive to ensure the durability of the data.
+Если SP не докажут фиксированное количество раз, что они все еще владеют рассматриваемыми данными, или отправят недействительное доказательство, их залог частично сокращается. Штраф за сокращение - это фиксированный процент от общего залога. Это сокращение продолжается до тех пор, пока не будет достигнуто определенное количество сокращений, после чего весь залог сокращается. В этот момент слот SP считается "оставленным". Сокращенный залог используется как стимул для нового **SP** взять на себя неудачный слот через "механизм восстановления слота" (обсуждается далее). Это гарантирует, что залог обеспечивает экономический стимул для обеспечения долговечности данных.
-Codex is thus designed such that rational behavior for **SPs** consists of storing the data in the most space-efficient manner to minimize excess storage costs, while balancing the need for enough redundancy to recover from the possibility of data loss/corruption by the penalty of forfeiture of their collateral (slashing).
+Таким образом, Codex разработан таким образом, что рациональное поведение для **SP** состоит в хранении данных наиболее эффективным с точки зрения пространства способом для минимизации избыточных затрат на хранение, при этом балансируя необходимость достаточной избыточности для восстановления от возможности потери/повреждения данных штрафом за конфискацию их залога (сокращение).
-While Codex’s tech maximizes recoverability and durability in the event of partial data loss, Codex’s economic incentives coordinate rational actors to provide a stable and predictable environment for data storage users. At the heart of these economic incentives is the Codex utility token (CDX), which serves as the collateral to protect file durability and facilitate slot repair, and the means of payment to coordinate successful storage contracts.
+Хотя технология Codex максимизирует восстанавливаемость и долговечность в случае частичной потери данных, экономические стимулы Codex координируют рациональных участников для обеспечения стабильной и предсказуемой среды для пользователей хранения данных. В основе этих экономических стимулов лежит утилитарный токен Codex (CDX), который служит залогом для защиты долговечности файлов и облегчения восстановления слотов, а также средством платежа для координации успешных контрактов на хранение.
-# Contract Lifecycle
+# Жизненный цикл контракта
-The marketplace coordinates matching **Clients** who want to pay for storing files with **Storage Providers** who are offering storage space and posting collateral in order to earn payments for the contract.
+Рынок координирует сопоставление **Клиентов**, которые хотят платить за хранение файлов, с **Поставщиками Хранения**, которые предлагают пространство для хранения и размещают залог для получения платежей по контракту.
-## Contract Request Initiation
+## Инициация запроса контракта
-As a design principle, **Clients** should post the deal terms they are looking for, and Storage Providers prioritize which deals meet their criteria and pose the best deals to take.
+Как принцип проектирования, **Клиенты** должны публиковать условия сделки, которые они ищут, а Поставщики Хранения определяют приоритеты, какие сделки соответствуют их критериям и представляют лучшие сделки для принятия.
-When the contract request is created, the **Client** deposits the full price of the length of the contract at that time. This deposit acts as a spam prevention mechanism and ensures that **SP** time and resources are not wasted filling slots for deals that a **Client** does not complete payment for.
+Когда создается запрос на контракт, **Клиент** вносит полную цену за длительность контракта на тот момент. Этот депозит действует как механизм предотвращения спама и гарантирует, что время и ресурсы **SP** не тратятся на заполнение слотов для сделок, за которые **Клиент** не завершает оплату.
-## Storage Providers Fill Requests
+## Поставщики Хранения заполняют запросы
-Ahead of matching with storage contracts, **Storage Providers** specify their aggregate availabilities for new contracts.
+Перед сопоставлением с контрактами на хранение **Поставщики Хранения** указывают свою совокупную доступность для новых контрактов.
-Based on each **SPs’** availabilities, a queue is created for each **SP**, ranking the open **Client** request for contract deals with the most favorable deals at the top. Over time, this queue resolves by pairing **SPs** with contracts that are compatible with their availabilities, starting with the highest ranked deals first.
+На основе доступности каждого **SP** создается очередь для каждого **SP**, ранжирующая открытые запросы **Клиента** на контрактные сделки с наиболее благоприятными сделками наверху. Со временем эта очередь разрешается путем сопоставления **SP** с контрактами, совместимыми с их доступностью, начиная с сделок с самым высоким рейтингом.
-At launch, **SPs** will not be able to customize the queue creation algorithm, which means **SPs** with the same availabilities will have identical queues (other than differences due to a randomness function that increases **SP** diversity per each contract). In the future, **SPs** are expected to be able to customize their queue ranking algorithm.
+При запуске **SP** не смогут настраивать алгоритм создания очереди, что означает, что **SP** с одинаковой доступностью будут иметь идентичные очереди (за исключением различий из-за функции случайности, которая увеличивает разнообразие **SP** для каждого контракта). В будущем ожидается, что **SP** смогут настраивать свой алгоритм ранжирования очереди.
-If a **SP** matches with a storage contract and they're eligible to reserve a slot in the contract, they reserve an open slot, download the slot data from the **Client** or existing **SPs** whose data can be used to reconstruct the slot’s contents, create an initial storage proof, and submit this proof, along with collateral, to the **Protocol**.
+Если **SP** сопоставляется с контрактом на хранение и они имеют право зарезервировать слот в контракте, они резервируют открытый слот, загружают данные слота от **Клиента** или существующих **SP**, чьи данные могут быть использованы для восстановления содержимого слота, создают начальное доказательство хранения и отправляют это доказательство вместе с залогом в **Протокол**.
-Note that a slot is not considered confirmed as filled until after an **SP** both posts associated collateral and produces a proof for the slot.
+Обратите внимание, что слот не считается подтвержденным как заполненный до тех пор, пока **SP** не разместит связанный залог и не создаст доказательство для слота.
-## Contract Expires Before Beginning
+## Контракт истекает до начала
-If there are still empty slots when the timeout/expiry for the contract request expires, the deal is terminated.
+Если все еще есть пустые слоты, когда истекает таймаут/срок действия запроса на контракт, сделка прекращается.
-The **Storage Providers** who did fill slots, if any, are compensated for the amount of time which they did store the slot data, at the contract requests specified price per TB per Month. The remainder of the **Client**’s deposit is returned.
+**Поставщики Хранения**, которые заполнили слоты, если таковые имеются, получают компенсацию за время, в течение которого они хранили данные слота, по указанной в запросе на контракт цене за ТБ в месяц. Остаток депозита **Клиента** возвращается.
-As there is a high probability of having at least a few slots occupied, there should be no need for further penalties on the **Client** to prevent spam requests and incentivise **Clients** to submit attractive deals.
+Поскольку существует высокая вероятность наличия хотя бы нескольких занятых слотов, не должно быть необходимости в дополнительных штрафах для **Клиента** для предотвращения спам-запросов и стимулирования **Клиентов** к подаче привлекательных сделок.
-## Contract Begins
+## Контракт начинается
-The contract begins if *all* slots are occupied, that is, **SPs** have downloaded the data, posted collateral, and posted proofs before the timeout/expiry for the contract request is reached.
+Контракт начинается, если *все* слоты заняты, то есть **SP** загрузили данные, разместили залог и опубликовали доказательства до достижения таймаута/срока действия запроса на контракт.
-At this moment, a *protocol fee* is applied on the user’s deposit. The proceedings are burned.
+В этот момент применяется *комиссия протокола* к депозиту пользователя. Поступления сжигаются.
-The remaining of the client’s deposit is held by the protocol and will be used to pay **SPs** at the end of the contract.
+Остаток депозита клиента удерживается протоколом и будет использоваться для оплаты **SP** в конце контракта.
-## Contract is Running
+## Контракт выполняется
-**Storage Providers** must submit proofs to **Validators** according to the storage request’s proof frequency, a parameter set by the Client in the request.
+**Поставщики Хранения** должны отправлять доказательства **Валидаторам** в соответствии с частотой доказательств запроса на хранение, параметром, установленным Клиентом в запросе.
-### Missing Proofs
+### Отсутствующие доказательства
-If an **SP** fails to submit proofs within the rolling last periods, they are partially slashed. The penalty is a fixed percentage of the collateral. Upon provision of a proof after being partially slashed, the SP should top up the missing collateral.
+Если **SP** не отправляет доказательства в течение последних периодов, они частично сокращаются. Штраф - это фиксированный процент от залога. После предоставления доказательства после частичного сокращения SP должен пополнить недостающий залог.
-Should the SP be slashed enough times, their entire collateral will be slashed and confiscated, and the SP is considered to have abandoned its slot. The provision of a correct proof at this moment will not revert the start of the slot recovery mechanism.
+Если SP будет сокращен достаточное количество раз, весь их залог будет сокращен и конфискован, и SP считается оставившим свой слот. Предоставление правильного доказательства в этот момент не отменит начало механизма восстановления слота.
-## A Slot in the Contract is Abandoned
+## Слот в контракте оставлен
-When an **SP** fails to submit enough proofs such that they are slashed enough times, their slot is considered abandoned. In order to incentivize a new **SP** to come in and takeover the abandoned slot (slot recovery), 50% of the collateral confiscated from the **SP** which has abandoned the slot is used as an incentive to the new **SP**. The remaining confiscated collateral is burned.
+Когда **SP** не отправляет достаточное количество доказательств, так что они сокращаются достаточное количество раз, их слот считается оставленным. Для стимулирования нового **SP** прийти и взять на себя оставленный слот (восстановление слота), 50% залога, конфискованного у **SP**, который оставил слот, используется как стимул для нового **SP**. Оставшийся конфискованный залог сжигается.
-This helps align the economic incentive for **SPs** to take over abandoned slots before filling new deals, since they can effectively earn forfeited collateral for taking over and fulfilling abandoned slots.
+Это помогает согласовать экономический стимул для **SP** взять на себя оставленные слоты перед заполнением новых сделок, поскольку они могут эффективно заработать конфискованный залог за взятие на себя и выполнение оставленных слотов.
-## Contract Defaults
+## Контракт не выполняется
-If, at any time during the life of the storage contract, the number of slots currently in an abandoned state (not yet recovered), meets or exceeds the maximum number of storage slots that can be lost before the data is unrecoverable, then the entire storage deal is considered to be in a *failed* state.
+Если в любой момент в течение срока действия контракта на хранение количество слотов, находящихся в оставленном состоянии (еще не восстановленных), достигает или превышает максимальное количество слотов хранения, которые могут быть потеряны до того, как данные станут невосстановимыми, то вся сделка хранения считается находящейся в состоянии *сбоя*.
-Each **Storage Providers** posted collateral is burned. This incentivizes **SPs** not to let storage deals to be at risk of defaulting. **SPs** are incentivized to *proactively* avoid this by diversifying their infrastructure and the storage contracts they enter, and *reactively* by backing up their own slot data, or even backing up data from other slots so they can better assist slot recovery, as the deal approaches a failed state.
+Каждый залог, размещенный **Поставщиками Хранения**, сжигается. Это стимулирует **SP** не допускать, чтобы сделки хранения подвергались риску невыполнения обязательств. **SP** стимулируются *проактивно* избегать этого путем диверсификации своей инфраструктуры и контрактов на хранение, в которые они вступают, и *реактивно* путем резервного копирования своих собственных данных слота или даже резервного копирования данных из других слотов, чтобы они могли лучше помочь восстановлению слота, когда сделка приближается к состоянию сбоя.
-Clients also receive back any leftover from their original payment.
+Клиенты также получают обратно любой остаток от их первоначального платежа.
-## Contract Ends Its Full Duration
+## Контракт завершает свой полный срок
-When a started contract reaches its pre-specified duration without having previously defaulted, the contract completes.
+Когда начатый контракт достигает своего предварительно указанного срока без предварительного невыполнения обязательств, контракт завершается.
-All collateral is returned to **SPs t**hat currently fill the slots (note due to slot recovery these are not necessarily the same **SPs** that filled the slots at contract inception), and all remaining payment is returned to the client.
+Весь залог возвращается **SP**, которые в настоящее время заполняют слоты (обратите внимание, что из-за восстановления слота это не обязательно те же **SP**, которые заполняли слоты при начале контракта), и весь оставшийся платеж возвращается клиенту.
-Deals can not be automatically rolled forward or extended. If a **Client** desires to continue a deal, they must create a new storage contract request. Otherwise, Clients can retrieve their data.
+Сделки не могут быть автоматически продлены или продлены. Если **Клиент** желает продолжить сделку, он должен создать новый запрос на контракт хранения. В противном случае Клиенты могут получить свои данные.
-# CDX Testnet Tokenomics
+# Токеномика CDX в тестовой сети
-The CDX token does not exist in the Testnet Phase. The description below refers to the mechanics of a Testnet token and not CDX itself and will be referred to as *CDX (Testnet token)* for this purpose.
+Токен CDX не существует в фазе тестовой сети. Описание ниже относится к механике тестового токена, а не к самому CDX, и для этой цели будет называться *CDX (тестовый токен)*.
-For the avoidance of doubt, the *CDX (Testnet token)* are virtual items with no value of any kind and they are not convertible to any other currency, token, or any other form of property. They are solely intended to be utilised for the purposes of enabling the tokenomics and facilitating the different roles in this Testnet Phase.
+Для избежания сомнений, *CDX (тестовый токен)* являются виртуальными предметами без какой-либо ценности и не конвертируются в какую-либо другую валюту, токен или любую другую форму собственности. Они предназначены исключительно для использования в целях включения токеномики и облегчения различных ролей в этой фазе тестовой сети.
-## Roles
+## Роли
-The Codex protocol has two primary roles fulfilled by network participants.
+Протокол Codex имеет две основные роли, выполняемые участниками сети.
-- **Clients**: pay Storage Providers in *CDX (Testnet token)* to securely store their data on the Codex network for an agreed upon amount of time.
-- **Storage Providers**: post *CDX (Testnet token)* collateral to enter into storage contracts with Clients in exchange for a *CDX (Testnet token)* denominated payment.
-- **Validators**: post *CDX (Testnet token)* collateral to validate storage proofs in exchange for a *CDX (Testnet token)* denominated payment.
+- **Клиенты**: платят Поставщикам Хранения в *CDX (тестовый токен)* за безопасное хранение своих данных в сети Codex на согласованный срок.
+- **Поставщики Хранения**: размещают залог в *CDX (тестовый токен)* для вступления в контракты на хранение с Клиентами в обмен на платеж, номинированный в *CDX (тестовый токен)*.
+- **Валидаторы**: размещают залог в *CDX (тестовый токен)* для проверки доказательств хранения в обмен на платеж, номинированный в *CDX (тестовый токен)*.
-## Token Utility
+## Утилита токена
-The *CDX (Testnet token)* is used as both a form of posted collateral and a means of payment in order to secure the network and access its services.
+*CDX (тестовый токен)* используется как форма размещенного залога и средство платежа для защиты сети и доступа к ее услугам.
-Collateral is primarily used as a spam and sybil-attack prevention mechanism, liability insurance (e.g. compensating Clients in case of catastrophic loss of data), and to enforce rational behavior.
+Залог в основном используется как механизм предотвращения спама и атак Сибил, страхование ответственности (например, компенсация Клиентам в случае катастрофической потери данных) и для обеспечения рационального поведения.
-Payments are made by Clients to Providers for services rendered, such as for storing data for a certain amount of time or retrieving data. This is implemented through the Marketplace contract, which serves as an escrow. Data in a storage contract is distributed into slots where each is, ideally, hosted by a different Storage Provider.
+Платежи производятся Клиентами Поставщикам за оказанные услуги, такие как хранение данных в течение определенного времени или извлечение данных. Это реализуется через контракт Marketplace, который служит эскроу. Данные в контракте хранения распределяются по слотам, где каждый, в идеале, размещается на разных Поставщиках Хранения.
-### **For Clients**
+### **Для Клиентов**
-- Pay storage costs and fees in *CDX (Testnet token)* for storing files.
+- Оплата затрат на хранение и комиссий в *CDX (тестовый токен)* за хранение файлов.
-### **For Storage Providers**
+### **Для Поставщиков Хранения**
-- Post collateral in *CDX (Testnet token)* when committing to new storage contracts. This collateral is slashed if they do not fulfill their agreed upon services.
-- Earn *CDX (Testnet token)* from the collateral of slashed Storage Providers by participating in the slot recovery mechanism.
-- Earn *CDX (Testnet token)* from Clients when successfully completing the storage service.
+- Размещение залога в *CDX (тестовый токен)* при принятии обязательств по новым контрактам хранения. Этот залог сокращается, если они не выполняют свои согласованные услуги.
+- Заработок *CDX (тестовый токен)* от залога сокращенных Поставщиков Хранения путем участия в механизме восстановления слота.
+- Заработок *CDX (тестовый токен)* от Клиентов при успешном завершении услуги хранения.
-### For Validators
+### Для Валидаторов
-- Post collateral in *CDX (Testnet token)* to operate the validation service. This collateral is slashed if they do not mark a proof as missing within a predetermined period.
-- Earn *CDX (Testnet token)* from the collateral of slashed Storage Providers by marking proofs as missed
+- Размещение залога в *CDX (тестовый токен)* для работы службы валидации. Этот залог сокращается, если они не отмечают доказательство как отсутствующее в течение предопределенного периода.
+- Заработок *CDX (тестовый токен)* от залога сокращенных Поставщиков Хранения путем отметки доказательств как пропущенных
-Figure below depicts the flow of the *CDX (Testnet token)* token within the system.
+На рисунке ниже показан поток *CDX (тестовый токен)* в системе.
-
+
-## Value Capture and Accrual Mechanisms
+## Механизмы захвата и накопления стоимости
-Codex creates *value* to participants:
+Codex создает *ценность* для участников:
-- Clients can benefit from storing data with strong durability guarantees;
-- Storage Providers can earn yield from their spare resources or capital by providing a service.
-- Validators earn payouts for marking proofs as missing.
+- Клиенты могут получить выгоду от хранения данных с сильными гарантиями долговечности;
+- Поставщики Хранения могут получать доход от своих свободных ресурсов или капитала, предоставляя услугу.
+- Валидаторы получают выплаты за отметку доказательств как отсутствующих.
-Clients need *CDX (Testnet token)* tokens to request storage deals. *CDX (Testnet token)* captures the value created to Clients by being a *Value Transfer Token* to them.
+Клиентам нужны токены *CDX (тестовый токен)* для запроса сделок хранения. *CDX (тестовый токен)* захватывает ценность, созданную для Клиентов, будучи для них *Токеном Передачи Ценности*.
-Storage Providers and Validators are rewarded in *CDX (Testnet token)* token and also need it as a proof of commitment to the Protocol. They risk being slashed in exchange for rewards. *CDX (Testnet token)* captures the value created to Providers by being a *Work Token* to them.
+Поставщики Хранения и Валидаторы вознаграждаются токеном *CDX (тестовый токен)* и также нуждаются в нем как в доказательстве приверженности Протоколу. Они рискуют быть сокращенными в обмен на вознаграждения. *CDX (тестовый токен)* захватывает ценность, созданную для Поставщиков, будучи для них *Токеном Работы*.
-The following mechanisms describe how the value accrues to the *CDX (Testnet token)* token.
+Следующие механизмы описывают, как ценность накапливается в токене *CDX (тестовый токен)*.
-### Protocol Fee over Contracts
+### Комиссия протокола за контракты
-If the contract is canceled before it starts, Client's deposited amount is charged a small penalty and returned, aiding to prevent low quality spam deal requests.
+Если контракт отменяется до его начала, с депонированной суммы Клиента взимается небольшой штраф и возвращается, что помогает предотвратить запросы сделок низкого качества спама.
-If the contract successfully initiates, the protocol collects a fee for facilitating the transaction. The remaining amount is made available for payments to Storage Providers.
+Если контракт успешно инициируется, протокол взимает комиссию за облегчение транзакции. Оставшаяся сумма становится доступной для платежей Поставщикам Хранения.
-The collected fees are burned in both cases. This creates a small but constant deflationary force on the token supply, which is proportional to the product demand.
+Собранные комиссии сжигаются в обоих случаях. Это создает небольшую, но постоянную дефляционную силу на предложение токена, которая пропорциональна спросу на продукт.
-## Behavior & Motivations
+## Поведение и мотивации
-### Clients
+### Клиенты
-Clients have the following rational behavior:
+Клиенты имеют следующее рациональное поведение:
-- Requesting storage from the network with a fee at fair market rates
-- Providing data to storage nodes that meet their criteria
+- Запрос хранения от сети с комиссией по справедливым рыночным ставкам
+- Предоставление данных узлам хранения, которые соответствуют их критериям
-They may also exhibit the following adversarial behavior, whether for profit driven, malicious, or censorship motivations:
+Они также могут демонстрировать следующее враждебное поведение, будь то по мотивам прибыли, злонамеренности или цензуры:
-- Requesting storage from the network but never making the data available for any or all slots
-- Requesting storage from the network but not releasing the data within required time period to begin the contract successfully
-- Requesting storage from the network but not releasing the data to specific Providers
-- Attacking SPs that host their data to attempt to relieve their payment obligations at the end of the contract.
+- Запрос хранения от сети, но никогда не предоставление данных доступными для любых или всех слотов
+- Запрос хранения от сети, но не предоставление данных в течение требуемого периода времени для успешного начала контракта
+- Запрос хранения от сети, но не предоставление данных конкретным Поставщикам
+- Атака на SP, которые размещают их данные, чтобы попытаться освободить свои платежные обязательства в конце контракта.
-### **Storage Providers**
+### **Поставщики Хранения**
-Storage Providers have the following rational behavior:
+Поставщики Хранения имеют следующее рациональное поведение:
-- Committing to slots of storage contracts to earn a fee.
-- Providing proofs of storage for their committed slots to avoid collateral slashing penalties.
-- Releasing the data to anyone who requests it.
-- Committing to failed slots of storage contracts to maintain the integrity of the data
+- Принятие обязательств по слотам контрактов хранения для получения комиссии.
+- Предоставление доказательств хранения для их обязательных слотов для избежания штрафов за сокращение залога.
+- Предоставление данных любому, кто их запрашивает.
+- Принятие обязательств по неудачным слотам контрактов хранения для поддержания целостности данных
-They may also exhibit the following adversarial behavior, whether for profit driven, malicious, or censorship motivations:
+Они также могут демонстрировать следующее враждебное поведение, будь то по мотивам прибыли, злонамеренности или цензуры:
-- Reserving a contract slot but never filling it (attempt to prevent contract from starting)
-- Ceasing to provide proofs mid the lifespan of a contract
-- Producing proofs, but not making data available for other nodes to retrieve
+- Резервирование слота контракта, но никогда его заполнение (попытка предотвратить начало контракта)
+- Прекращение предоставления доказательств в середине срока действия контракта
+- Создание доказательств, но не предоставление данных доступными для других узлов для извлечения
-### Validators
+### Валидаторы
-Validators have the following rational behavior:
+Валидаторы имеют следующее рациональное поведение:
-- Marking a proof as missing to earn a fee
-- Tracking the history of missed proofs of a **SP**
-- Triggering the Slot Recovery Mechanism when an **SP** reaches the maximum allowed number of missed proofs
+- Отметка доказательства как отсутствующего для получения комиссии
+- Отслеживание истории пропущенных доказательств **SP**
+- Запуск механизма восстановления слота, когда **SP** достигает максимально допустимого количества пропущенных доказательств
-They may also exhibit the following adversarial behavior, whether for profit driven, malicious, or censorship motivations:
+Они также могут демонстрировать следующее враждебное поведение, будь то по мотивам прибыли, злонамеренности или цензуры:
-- Colluding with SPs to ignore missed proofs
-- Observing a missed proof but do not post it onchain
+- Сговор с SP для игнорирования пропущенных доказательств
+- Наблюдение пропущенного доказательства, но не публикация его в блокчейне
-## Incentive Mechanisms
+## Механизмы стимулирования
-The following mechanisms help incentivize the expected behavior of each role and mitigate the detrimental ones.
+Следующие механизмы помогают стимулировать ожидаемое поведение каждой роли и смягчать вредные.
-### Clients Provide Full Payment Upfront
+### Клиенты предоставляют полную оплату заранее
-Clients must deposit the full amount in *CDX (Testnet token)* that covers the entirety of the storage contract duration upfront. This indicates their pledge to pay a certain amount for the storage contract, though the contract only begins when and if all data slots are filled by Storage Providers.
+Клиенты должны внести полную сумму в *CDX (тестовый токен)*, которая покрывает весь срок действия контракта хранения заранее. Это указывает на их обязательство заплатить определенную сумму за контракт хранения, хотя контракт начинается только тогда и если все слоты данных заполнены Поставщиками Хранения.
-### Delayed Payment to Storage Providers
+### Отложенный платеж Поставщикам Хранения
-Storage Providers only receive payment related to the provision of services at the end of the contract duration.
+Поставщики Хранения получают платеж, связанный с предоставлением услуг, только в конце срока действия контракта.
-### Collateral Requirement
+### Требование залога
-In order to fill a data slot, Storage Providers first stake and commit the required collateral in the form of the *CDX (Testnet token)* for that slot which is then subject to slashing if they do not post a proof to confirm the slot.
+Для заполнения слота данных Поставщики Хранения сначала размещают и обязуются предоставить требуемый залог в форме *CDX (тестовый токен)* для этого слота, который затем подлежит сокращению, если они не публикуют доказательство для подтверждения слота.
-Validators also need to post collateral to participate in the validation service.
+Валидаторы также должны размещать залог для участия в службе валидации.
-### Proof of Storage
+### Доказательство хранения
-Contracts only start when all data slots are filled. Slots are only considered filled after a Storage Provider has posted collateral and the associated proof for its slot.
+Контракты начинаются только тогда, когда все слоты данных заполнены. Слоты считаются заполненными только после того, как Поставщик Хранения разместил залог и связанное с ним доказательство для своего слота.
-Once the contract begins, Storage Providers regularly provide proof of storage.
+После начала контракта Поставщики Хранения регулярно предоставляют доказательство хранения.
-### **Slashing for Missed Proofs of Storage**
+### **Сокращение за пропущенные доказательства хранения**
-At any point during the duration of the storage contract, the storage provider is slashed if it fails to provide a certain number of proof of storage in a row. Should the SP resume providing proof of storage, it needs to top up the slashed collateral. The penalty is a fixed percentage of the total collateral.
+В любой момент в течение срока действия контракта на хранение поставщик хранения сокращается, если он не предоставляет определенное количество доказательств хранения подряд. Если SP возобновляет предоставление доказательств хранения, он должен пополнить сокращенный залог. Штраф представляет собой фиксированный процент от общего залога.
-### Slot Recovery Mechanism
+### Механизм восстановления слота
-If a Storage Provider does not submit the required storage proofs when required, after a number of slashings their entire collateral will be seized. A portion of the confiscated collateral is used as an incentive for the new Storage Provider who recovers and starts serving the abandoned slot. The remainder of the confiscated collateral in *CDX (Testnet token)* is burned.
+Если поставщик хранения не отправляет требуемые доказательства хранения, когда это необходимо, после определенного количества сокращений весь его залог будет конфискован. Часть конфискованного залога используется как стимул для нового поставщика хранения, который восстанавливает и начинает обслуживать оставленный слот. Оставшаяся часть конфискованного залога в *CDX (тестовый токен)* сжигается.
-### Slashing Defaulted Contract
+### Сокращение невыполненного контракта
-If, at any point during the duration of the storage contract, the number of data slots currently abandoned (and not yet recovered) reaches or surpasses the maximum allowable lost slots (meaning the data becomes irretrievable), then the entire storage contract is deemed to be *failed*.
+Если в любой момент в течение срока действия контракта на хранение количество оставленных (и еще не восстановленных) слотов данных достигает или превышает максимально допустимое количество потерянных слотов (что означает, что данные становятся невосстанавливаемыми), то весь контракт на хранение считается *невыполненным*.
-At this stage, collaterals of all Storage Providers serving data slots in the contract are entirely slashed.
+На этом этапе залоги всех поставщиков хранения, обслуживающих слоты данных в контракте, полностью сокращаются.
-### Client Reimbursement
+### Возмещение клиентам
-If at any point during the contract, sufficient slots are abandoned such that the data is not fully recoverable, Clients receive back any leftover from their original payment.
+Если в любой момент в течение контракта достаточное количество слотов оставлено, так что данные не могут быть полностью восстановлены, клиенты получают обратно любой остаток от их первоначального платежа.
-## Token Lifecycle
+## Жизненный цикл токена
-### Burning
+### Сжигание
-*CDX (Testnet token)* tokens are burned in these instances:
+*CDX (тестовый токен)* сжигаются в следующих случаях:
-- When a storage deal contract fails to initiate, a small portion of the Client's payment for the storage deal is burned. This serves primarily as a mechanism to deter spam and ensure that deal requests are submitted at market-appropriate prices for storage.
-- When a storage deal contract successfully initiates, the protocol applies a fee for facilitating the transaction.
-- Whenever a Storage Provider misses a certain number of storage proofs, a portion of the collateral is slashed and burned.
-- Once the slot recovery mechanism resolves, the remaining of the abandoning Storage Provider’s collateral is burned.
+- Когда контракт на хранение не может быть инициирован, небольшая часть платежа клиента за сделку хранения сжигается. Это служит в первую очередь механизмом для предотвращения спама и обеспечения того, чтобы запросы сделок подавались по рыночным ценам для хранения.
+- Когда контракт на хранение успешно инициируется, протокол взимает комиссию за облегчение транзакции.
+- Когда поставщик хранения пропускает определенное количество доказательств хранения, часть залога сокращается и сжигается.
+- После разрешения механизма восстановления слота оставшаяся часть залога оставившего поставщика хранения сжигается.
diff --git a/learn/troubleshoot.md b/learn/troubleshoot.md
index a9e0eee..5841f4c 100644
--- a/learn/troubleshoot.md
+++ b/learn/troubleshoot.md
@@ -1,30 +1,30 @@
---
outline: [2, 3]
---
-# Troubleshoot
+# Устранение неполадок
-Having trouble getting your Codex node connected to the testnet? Here's a list of common Codex connection conundrums and steps to diagnose and solve them. If your troubles are not addressed here, check our open issues on Github or reach out via our Discord server.
+Проблемы с подключением вашего узла Codex к тестовой сети? Вот список распространенных проблем подключения Codex и шаги для их диагностики и решения. Если ваши проблемы не рассматриваются здесь, проверьте наши открытые проблемы на Github или свяжитесь с нами через наш Discord-сервер.
-## Some basics
+## Основы
-You've probably already considered these. But just in case:
+Вы, вероятно, уже рассмотрели это. Но на всякий случай:
-1. Are you using a VPN? Make sure it's configured correctly to forward the right ports, and make sure you announce your node by the public IP address where you can be reached.
-1. Are you using a firewall or other security software? Make sure it's configured to allow incoming connections to Codex's discovery and peer-to-peer ports.
+1. Используете ли вы VPN? Убедитесь, что он правильно настроен для переадресации нужных портов, и убедитесь, что вы объявляете свой узел по публичному IP-адресу, по которому к вам можно обратиться.
+1. Используете ли вы брандмауэр или другое программное обеспечение безопасности? Убедитесь, что он настроен на разрешение входящих подключений к портам обнаружения и одноранговой сети Codex.
-## Check your announce address
+## Проверьте ваш объявляемый адрес
-Your node announces your public address to the network, so other nodes can connect to you. A common issue is connection failure due to incorrect announce addresses. Follow these steps to check your announce address.
+Ваш узел объявляет ваш публичный адрес в сети, чтобы другие узлы могли подключиться к вам. Распространенной проблемой является сбой подключения из-за неправильных объявляемых адресов. Следуйте этим шагам, чтобы проверить ваш объявляемый адрес.
-1. Go to a whats-my-ip site, or `ip.codex.storage` and note the IP address.
-1. Go into your router/modem WAN settings and find the public IP address.
-1. These two addresses should match.
-1. If they do not, it's possible that A) you're behind a VPN. In this case, it's up to you to disable the VPN or make sure all forwarding is configured correctly. or B) Your internet-service-provider has placed your uplink behind a secondary NAT. ISPs do this to save public IP addresses. The address assigned to your router/moderm is not a 'true' public internet address. Usually this issue can be solved by your ISP. Contact customer support and ask them to give you a public address (sometimes also called Dynamic IP address).
-1. Call Codex's debug/info endpoint. See the [Using Codex](/learn/using) for the details.
-1. In the JSON response, you'll find "announceAddresses".
-1. The IP address listed there should match your public IP.
-1. If the announce address in the JSON is incorrect, you can adjust it manually by changing Codex's CLI argument `--nat` or setting the environment variable `CODEX_NAT`. After you've changed your announce address and restarted your node, please allow some time (20-30mins) for the network to disseminate the updated address.
+1. Перейдите на сайт whats-my-ip или `ip.codex.storage` и запишите IP-адрес.
+1. Перейдите в настройки WAN вашего маршрутизатора/модема и найдите публичный IP-адрес.
+1. Эти два адреса должны совпадать.
+1. Если они не совпадают, возможно, что A) вы находитесь за VPN. В этом случае вам нужно отключить VPN или убедиться, что вся переадресация настроена правильно. или B) Ваш интернет-провайдер поместил ваше восходящее соединение за вторичным NAT. Интернет-провайдеры делают это для экономии публичных IP-адресов. Адрес, назначенный вашему маршрутизатору/модему, не является "истинным" публичным интернет-адресом. Обычно эту проблему может решить ваш интернет-провайдер. Свяжитесь со службой поддержки и попросите их предоставить вам публичный адрес (иногда также называемый динамическим IP-адресом).
+1. Вызовите конечную точку отладки/информации Codex. Смотрите [Использование Codex](/learn/using) для подробностей.
+1. В JSON-ответе вы найдете "announceAddresses".
+1. IP-адрес, указанный там, должен соответствовать вашему публичному IP.
+1. Если объявляемый адрес в JSON неверен, вы можете настроить его вручную, изменив аргумент командной строки Codex `--nat` или установив переменную окружения `CODEX_NAT`. После того, как вы изменили свой объявляемый адрес и перезапустили узел, пожалуйста, дайте некоторое время (20-30 минут) для распространения обновленного адреса в сети.
-If you've performed these steps and haven't found any issues, your announce address is probably not the problem.
+Если вы выполнили эти шаги и не нашли никаких проблем, ваш объявляемый адрес, вероятно, не является проблемой.
diff --git a/learn/using.md b/learn/using.md
index 5ad8044..3078dd8 100644
--- a/learn/using.md
+++ b/learn/using.md
@@ -1,38 +1,38 @@
---
outline: [2, 3]
---
-# Using Codex
+# Использование Codex
-We can interact with Codex using [REST API](/developers/api). This document will show you several useful examples.
+Мы можем взаимодействовать с Codex, используя [REST API](/developers/api). В этом документе показаны несколько полезных примеров.
-Also, we can check [Codex App UI](https://app.codex.storage).
+Также мы можем использовать [Пользовательский интерфейс приложения Codex](https://app.codex.storage).
-Command line interpreter on [Linux/macOS](#linux-macos) and [Windows](#windows) works slightly different, so please use steps for your OS.
+Интерпретатор командной строки работает немного по-разному на [Linux/macOS](#linux-macos) и [Windows](#windows), поэтому используйте инструкции для вашей ОС.
## Linux/macOS
-### Overview
-1. [Debug](#debug)
-2. [Upload a file](#upload-a-file)
-3. [Download a file](#download-a-file)
-4. [Local data](#local-data)
-5. [Create storage availability](#create-storage-availability)
-6. [Purchase storage](#purchase-storage)
-7. [View purchase status](#view-purchase-status)
+### Обзор
+1. [Отладка](#debug)
+2. [Загрузка файла](#upload-a-file)
+3. [Скачивание файла](#download-a-file)
+4. [Локальные данные](#local-data)
+5. [Создание доступности хранилища](#create-storage-availability)
+6. [Покупка хранилища](#purchase-storage)
+7. [Просмотр статуса покупки](#view-purchase-status)
-### Debug
-An easy way to check that your node is up and running is:
+### Отладка
+Простой способ проверить, что ваш узел запущен и работает:
```shell
curl http://localhost:8080/api/codex/v1/debug/info \
-w '\n'
```
-This will return a JSON structure with plenty of information about your local node. It contains peer information that may be useful when troubleshooting connection issues.
+Это вернет JSON-структуру с множеством информации о вашем локальном узле. Она содержит информацию о пирах, которая может быть полезна при устранении проблем с подключением.
-### Upload a file
+### Загрузка файла
> [!Warning]
-> Once you upload a file to Codex, other nodes in the network can download it. Please do not upload anything you don't want others to access, or, properly encrypt your data *first*.
+> После загрузки файла в Codex другие узлы в сети могут его скачать. Пожалуйста, не загружайте ничего, что вы не хотите, чтобы другие видели, или правильно зашифруйте ваши данные *перед загрузкой*.
```shell
curl -X POST \
@@ -42,16 +42,16 @@ curl -X POST \
-T example
- - > [!CAUTION] - > Please use key generation service for demo purpose only. - - ```shell - response=$(curl -s https://key.codex.storage) - awk -F ': ' '/private/ {print $2}' <<<"${response}" > eth.key - awk -F ': ' '/address/ {print $2}' <<<"${response}" > eth.address - chmod 600 eth.key - ``` - Show your ethereum address: - ```shell - cat eth.address - ``` - ``` - 0x412665aFAb17768cd9aACE6E00537Cc6D5524Da9 - ``` --### Motive +### Мотивация -The remote storage landscape is dominated by an increasingly small number of internet powerhouses—Google, Microsoft, Amazon, etc. While these services score highly in terms of user experience and convenience, centralised cloud data storage suffers from the following drawbacks: +Ландшафт удаленного хранения данных доминируется все меньшим числом интернет-гигантов - Google, Microsoft, Amazon и т.д. Хотя эти сервисы получают высокие оценки с точки зрения пользовательского опыта и удобства, централизованное облачное хранение данных страдает от следующих недостатков: -- Censorship +- Цензура -- Lack of data ownership +- Отсутствие владения данными -- Breaches and outages +- Утечки и простои -- High cost +- Высокая стоимость -Centralised cloud storage providers have an established history of censoring data and, as de facto owners of said data, have the power to do so according to their own standards. Furthermore, centralised platforms have fallen victim to major data breaches and service outages on numerous occasions. +Централизованные провайдеры облачного хранения имеют устоявшуюся историю цензурирования данных и, как де-факто владельцы этих данных, имеют право делать это согласно своим собственным стандартам. Более того, централизованные платформы неоднократно становились жертвами крупных утечек данных и простоев сервисов. -Such incidents have created a gap in the market for a decentralised, censorship-resistant alternative. Existing peer-to-peer storage and file-sharing networks address some of these issues—such as robustness in the face of network disruptions, and desirable resistance to censorship. Yet without adequate incentives and strong data durability guarantees, they make for unsuitable foundations upon which to build truly unstoppable applications. +Такие инциденты создали пробел на рынке для децентрализованной, устойчивой к цензуре альтернативы. Существующие одноранговые сети хранения и обмена файлами решают некоторые из этих проблем - такие как устойчивость к сбоям сети и желаемая устойчивость к цензуре. Однако без адекватных стимулов и сильных гарантий долговечности данных они не подходят в качестве основы для создания действительно неостановимых приложений. -Existing decentralised storage solutions purport to improve upon early P2P file-sharing platforms like eDonkey and Gnutella. However, the market still lacks a decentralised storage solution that is efficient in terms of storage and bandwidth usage, while offering performance and durability guarantees comparable to incumbents. +Существующие децентрализованные решения для хранения данных претендуют на улучшение ранних P2P-платформ обмена файлами, таких как eDonkey и Gnutella. Однако рынку все еще не хватает децентрализованного решения для хранения, которое было бы эффективным с точки зрения использования хранилища и пропускной способности, при этом предлагая гарантии производительности и долговечности, сопоставимые с существующими решениями.
-### Decentralising data storage +### Децентрализация хранения данных -Codex began in 2021 to address a need for a durable, decentralised storage layer for the web3 tech stack. +Codex был создан в 2021 году для удовлетворения потребности в долговечном, децентрализованном уровне хранения для стека технологий web3. -The name "Codex" refers to an ancient form of book—an allusion to the data storage engine's extremely robust—99.99%—durability guarantees. +Название "Codex" отсылает к древней форме книги - намек на чрезвычайно надежные - 99,99% - гарантии долговечности механизма хранения данных. -Codex was announced as a core Logos Collective protocol in June 2023. +Codex был объявлен как основной протокол Logos Collective в июне 2023 года. -### Testnet +### Тестовая сеть -Codex is currently in the testnet phase. The client implementation is free and open software. If you're interested, we encourage you to try Codex, connect to the testnet and experiment with its features. [Get started here](./quick-start.md) +Codex в настоящее время находится в фазе тестовой сети. Клиентская реализация является свободным и открытым программным обеспечением. Если вы заинтересованы, мы призываем вас попробовать Codex, подключиться к тестовой сети и поэкспериментировать с его функциями. [Начните здесь](./quick-start.md) diff --git a/learn/whitepaper.md b/learn/whitepaper.md index 7ee3688..8b5958b 100644 --- a/learn/whitepaper.md +++ b/learn/whitepaper.md @@ -1,536 +1,236 @@
-The internet is becoming more and more centralized. As companies and individuals increasingly rely on centralized cloud providers for storage, critical concerns on privacy, censorship, and user control, as well as on the concentration of economic power in the hands of few entities become more pronounced.
+Интернет становится все более централизованным. По мере того как компании и частные лица все больше полагаются на централизованных облачных провайдеров для хранения данных, возрастает озабоченность по поводу конфиденциальности, цензуры и контроля пользователей, а также концентрации экономической власти в руках небольшого числа субъектов.
-While there have been several attempts at providing alternatives, modern decentralized storage networks (DSNs) often fall short on basic aspects like having strong durability guarantees, being efficient to operate, or providing scalable proofs of storage. This in turn leads to solutions that are either: _i)_ not useful, as they can lose data; _ii)_ not friendly to decentralization, as they require specialized or expensive hardware, or; _iii)_ economically unfeasible, as they burden providers with too many costs beyond those of the storage hardware itself.
+Хотя было несколько попыток предоставить альтернативы, современные децентрализованные сети хранения данных (DSN) часто не соответствуют базовым аспектам, таким как наличие надежных гарантий долговечности, эффективность работы или возможность масштабируемых доказательств хранения. Это, в свою очередь, приводит к решениям, которые либо: _i)_ бесполезны, так как могут потерять данные; _ii)_ не дружелюбны к децентрализации, так как требуют специализированного или дорогого оборудования, либо; _iii)_ экономически нецелесообразны, так как обременяют провайдеров слишком большими затратами помимо затрат на само оборудование для хранения.
-In this paper, we introduce Codex, a novel Erasure Coded Decentralized Storage Network that attempts to tackle those issues. Codex leverages erasure coding as part of both redundancy and storage proofs, coupling it with zero-knowledge proofs and lazy repair to achieve tunable durability guarantees while being modest on hardware and energy requirements. Central to Codex is the concept of the Decentralized Durability Engine (DDE), a framework we formalize to systematically address data redundancy, remote auditing, repair, incentives, and data dispersal in decentralized storage systems.
+В этой статье мы представляем Codex, новую децентрализованную сеть хранения данных с кодированием стирания, которая пытается решить эти проблемы. Codex использует кодирование стирания как часть механизмов избыточности и доказательств хранения, сочетая его с доказательствами с нулевым разглашением и ленивым восстановлением для достижения настраиваемых гарантий долговечности при скромных требованиях к оборудованию и энергии. Центральным элементом Codex является концепция Движка Децентрализованной Долговечности (DDE), формализованная нами структура для систематического решения вопросов избыточности данных, удаленного аудита, восстановления, стимулов и распределения данных в децентрализованных системах хранения.
-We describe the architecture and mechanisms of Codex, including its marketplace and proof systems, and provide a preliminary reliability analysis using a Continuous Time Markov-Chain (CTMC) model to evaluate durability guarantees. Codex represents a step toward creating a decentralized, resilient, and economically viable storage layer critical for the broader decentralized ecosystem.
+Мы описываем архитектуру и механизмы Codex, включая его маркетплейс и системы доказательств, и предоставляем предварительный анализ надежности с использованием модели Непрерывной Временной Цепи Маркова (CTMC) для оценки гарантий долговечности. Codex представляет собой шаг к созданию децентрализованного, устойчивого и экономически жизнеспособного уровня хранения, критически важного для более широкой децентрализованной экосистемы.
-
-
-
- 
-
+4. **Масштабируемость**: DDE может масштабироваться для хранения больших объемов данных, превышающих размер любого отдельного узла в сети.
-**Figure 4.** CIDs for Codex datasets.
-
-Nodes that hold either part or the entirety of $D_e$ will periodically advertise a _Signed Peer Record_ (SPR) under $D_e$'s CID in the DHT to inform other peers that they are available to provide blocks for $D_e$. An SPR is a signed record[^signed_envelope_spec] which contains the peer's ID, its public key, and its supported network addresses as a list of multiaddresses[^multiaddress_spec].
-
-This structure affords a great deal of flexibility in how peers choose to communicate and encode datasets, and is key in creating a p2p network which can support multiple concurrent p2p client versions and can therefore be upgraded seamlessly.
-
-**Metadata.** Codex stores dataset metadata in descriptors called **manifests**. Those are currently kept separate from the dataset itself, in a manner similar to BitTorrent's _torrent files_. They contain metadata on a number of attributes required to describe and properly process the dataset, such as the Merkle roots for both the content (SHA256) and proof ($\text{Poseidon2}$) trees, the number of blocks contained in the dataset, the block size, erasure coding parameters, and the datasets' MIME-type. Although the CID of a dataset is largely independent of its manifest, a dataset can neither be decoded nor properly verified without it.
-
-Manifests are currently stored as content-addressable blocks in Codex and treated similarly to datasets: nodes holding the manifest of a given dataset will advertise its CID onto the DHT, which is computed by taking a SHA256 hash of the manifest's contents. Since manifests are stored separate from the dataset, however, they can also be exchanged out-of-band, like torrent files can.
+### 3.3 Реализация DDE в Codex
+Codex реализует DDE через следующие механизмы:
-Other systems choose tighter coupling between the metadata and the dataset. IPFS and Swarm use cryptographic structures such as Merkle DAG and a Merkle Tree, where intermediate nodes are placed on the network and queried iteratively to retrieve the respective vertexes and leaves. Such design decisions have their own tradeoffs and advantages, for example an advantage of storing the metadata in a single addressable unit is that it eliminates intermediary network round trips, as opposed to a distributed cryptographic structure such as a tree or a DAG.
+1. **Кодирование стирания**: Codex использует кодирование стирания для создания избыточности данных. Это позволяет системе восстанавливать данные даже при потере некоторых фрагментов.
-**Retrieving data.** Data retrieval in Codex follows a process similar to BitTorrent: a peer wishing to download a dataset $D_e$ must first acquire its manifest, either through Codex itself by looking up the manifest's CID on the DHT and downloading it from peers providing it, or out-of-band. Once in posession of the manifest, the peer can learn the dataset's CID (constructed from its SHA256 Merkle root) and look that up over the DHT. This is depicted Figure 5a **(1)**.
+2. **Доказательства хранения**: Codex использует доказательства с нулевым разглашением для проверки того, что провайдеры хранения действительно хранят данные.
-
-
-
+3. **Ленивое восстановление**: Codex использует ленивое восстановление для минимизации накладных расходов на восстановление данных.
-**Figure 5.** (a) DHT lookup and (b) download swarm.
+4. **Маркетплейс**: Codex включает в себя маркетплейс для сопоставления провайдеров хранения с клиентами и управления экономикой хранения.
-The nodes responsible for that CID will reply with a (randomized) subset of the providers for that CID (Figure 5a **(2)**). The peer can then contact these nodes to bootstrap itself into a download swarm (Figure 5b). Once part of the swarm, the peer will engage in an exchange protocol similar to BitSwap[^bitswap_spec] by advertising the blocks it wishes to download to neighbors, and receiving requests from neighbors in return. Dropped peers are replaced by querying the DHT again. Note that SPs always participate in the swarms for the datasets they host, acting as seeders. Since the mechanism is so similar to BitTorrent, we expect Codex to scale at least as well.
-
-Codex right now relies on simple incentive mechanisms to ensure that peers share blocks. There is current ongoing work on _bandwidth incentives_ and, in future versions, peers will be able to purchase block transfers from each other.
-
-### 4.5. Codex Marketplace
+5. **Распределение данных**: Codex использует стратегии для распределения данных по сети, чтобы минимизировать риск потери данных и максимизировать доступность.
-The Codex marketplace is the set of components that run both on-chain, as smart contracts, and off-chain, as part of both SCs and SPs. Its main goal is to define and enforce the set of rules which together enable: _i)_ orderly selling and purchasing of storage; _ii)_ verification of storage proofs; _iii)_ rules for penalizing faulty actors (slashing) and compensating SP repairs and SC data loss; and _iv)_ various other aspects of the system's economics, which will be discussed as part of an upcoming Codex tokenomics litepaper.
+## 4. Codex: Движок Децентрализованной Долговечности
+В этом разделе мы описываем, как Codex реализует концепцию DDE, представленную в предыдущем разделе. Мы начинаем с обзора архитектуры Codex, а затем переходим к более подробному описанию его механизмов.
-Codex implements an ask/bid market in which SCs post **storage requests** on chain, and SPs can then act on those if they turn out to be profitable. This means that the request side; i.e., how much an SC is willing to pay, is always visible, whereas the bid side; i.e., at what price an SP is willing to sell, is not.
-
-An SC that wishes Codex to store a dataset $D_e$ needs to provide $5$ main parameters. Those are:
-
-1. **Size in bytes.** Specifies how many storage bytes the SC wishes to purchase.
-2. **Duration.** Specifies for how long the SC wishes to purchase the storage bytes in (1); e.g. one year.
-3. **Number of slots.** Contains the number of slots in $D_e$. This is derived from the erasure coding parameters $k$ and $m$ discussed in Sec. 4.3.
-4. **Price.** The price this SC is willing to pay for storage, expressed as a fractional amount of Codex tokens per byte, per second. For instance, if this is set to $1$ and the SC wants to buy $1\text{MB}$ of storage for $10$ seconds, then this means the SC is willing to disburse $10$ million Codex tokens for this request.
-5. **Collateral per slot.** Dictates the amount of Codex tokens that the SP is expected to put as collateral if they decide to fulfill a slot in this request (staking). Failure to provide timely proofs may result in loss of this collateral (slashing).
+### 4.1 Архитектура Codex
+Codex состоит из следующих основных компонентов:
-As discussed in Sec. 5, these parameters may impact durability guarantees directly, and the system offers complete flexibility so that applications can tailor spending and parameters to specific needs. Applications built on Codex will need to provide guidance to their users so they can pick the correct parameters for their needs, not unlike Ethereum wallets help users determine gas fees.
+1. **Узлы хранения**: Узлы хранения отвечают за хранение данных и предоставление доказательств хранения. Они участвуют в маркетплейсе, предлагая свои услуги хранения клиентам.
-
- 
-
-
- (a)
-
- 
-
-
- (b)
-
-
- 
-
-
-**Figure 7.** Slots placed at random in a $z$-bit space.
-
-We then allow only hosts whose blockchain IDs are within a certain "distance" of a slot to compete in filling it (Figure 8).
+### 4.2 Механизмы Codex
+Codex реализует следующие механизмы для обеспечения надежного хранения данных:
-
-
- 
-
+1. **Кодирование стирания**: Codex использует кодирование стирания для создания избыточности данных. Это позволяет системе восстанавливать данные даже при потере некоторых фрагментов.
-**Figure 8.** SP eligibility as a function of time and its distance to a slot.
-
-This distance expands over time according to a _dispersal parameter_ $\mu$. Let $d: \{0,1\}^z \times \{0,1\}^z \longrightarrow [0, 2^z)$ be our distance function - we could for instance take the XOR of $a$ and $b$. A host with blockchain ID $b$ will only be allowed to fill a slot at position $a$ at time $t$ if:
-
-$$
-\begin{equation}
- d(a, b) \leq \mu t
-\end{equation}\tag{1}
-$$
+2. **Доказательства хранения**: Codex использует доказательства с нулевым разглашением для проверки того, что провайдеры хранения действительно хранят данные. Это включает в себя:
+ - **Доказательства извлекаемости**: Доказательства того, что данные могут быть извлечены из хранилища.
+ - **Доказательства хранения**: Доказательства того, что данные действительно хранятся в хранилище.
-where $t = 0$ at the moment in which the storage request for $a$ is published. In the example in Figure 8, host $b$ will be allowed to fill slot $a$ when $t \geq 2$, whereas host $c$ will only be allowed to try once $t \geq 3$. We will not attempt to formally prove this but, under relatively weak assumptions, this guarantees that the assignments of slots to SPs happens approximately uniformly at random.
+3. **Ленивое восстановление**: Codex использует ленивое восстановление для минимизации накладных расходов на восстановление данных. Восстановление происходит только при необходимости, когда данные находятся под угрозой потери.
-## 5. Reliability Analysis
+4. **Маркетплейс**: Маркетплейс Codex включает в себя следующие компоненты:
+ - **Запросы на хранение**: Клиенты могут создавать запросы на хранение, указывая параметры, такие как размер данных, продолжительность хранения и награда.
+ - **Предложения хранения**: Провайдеры хранения могут создавать предложения, указывая параметры, такие как доступное пространство, цена и условия.
+ - **Сопоставление**: Маркетплейс сопоставляет запросы с предложениями на основе параметров и условий.
+ - **Управление**: Маркетплейс управляет жизненным циклом запросов и предложений, включая создание, выполнение и завершение.
-In this section, we provide an initial analysis of durability for Codex. The main goal is investigating the values for $p_{\text{loss}}$, our probability of losing data over a 1-year period. In particular, we are interested in understanding what sorts of parameters are required for us to obtain very high levels of reliability (e.g. $p_{\text{loss}} = 10^{-9}$, or nine nines of availability).
-
-Codex, as a system, stores a large amount of datasets, each encoded, distributed, verified, and repaired according to the specific parameters set up in the respective storage contract. Since datasets are set up independently and operate (mostly) independently, we can model the system at the level of the dataset. We will later discuss correlation between various datasets stored in the system.
+5. **Распределение данных**: Codex использует стратегии для распределения данных по сети, чтобы минимизировать риск потери данных и максимизировать доступность. Это включает в себя:
+ - **Распределение фрагментов**: Фрагменты данных распределяются по узлам хранения для минимизации корреляции отказов.
+ - **Балансировка нагрузки**: Нагрузка распределяется по узлам хранения для предотвращения перегрузки.
-In our first model, we use a Continuous Time Markov-Chain (CTMC) model to describe the state of the dataset at any time instance. The model considers the following aspects of Codex:
-- dataset encoding;
-- node failures;
-- the proving process;
-- dataset repair.
+### 4.3 Гарантии долговечности
+Codex предоставляет следующие гарантии долговечности:
-Before discussing the state space and the rate matix of the CTMC model, lets describe these aspects of the system.
-
-As before, we assume a dataset $D$ split into $k$ disjoint partitions, and encoded into a new dataset $D_e$ with $n=k+m$ slots $\{S_1, \cdots, S_k , \cdots, S_{k+m}\}$. This encoding is often characterized by it's code expansion factor $e = n/k =1+m/k$, expressing the storage overhead due to code redundancy.
-
-### 5.1. Failure Model
+1. **Настраиваемые гарантии**: Пользователи могут настраивать параметры хранения, такие как уровень избыточности и продолжительность хранения, для достижения желаемых гарантий долговечности.
-When discussing failures, we should differentiate between transient and permanent failures, as well as between catastrophic node failures (the slot data is entirely lost) and partial failures.
+2. **Формальные гарантии**: Codex предоставляет формальные гарантии долговечности через анализ надежности, который учитывает параметры системы и вероятность отказов.
-In our first model, we focus on permanent node failures. From the perspective of Codex, a node is considered lost if it cannot provide proofs. Permanent node failure can be due to disk failure, to other hardware or software failures leading to data corruption, but also due to operational risks, including hardware failures, network failures, or operational decisions.
+3. **Экономические гарантии**: Codex использует криптоэкономические механизмы для обеспечения того, что провайдеры хранения имеют стимулы для правильного поведения и поддержания данных.
-Unrepairable hardware failures are typically characterized with their **MTTF** (Mean Time To Failure) metric, assuming an exponential distribution of the time to failure. There are various MTTF statistics available about disk failures[^schroeder_07].
+## 5. Анализ надежности
+В этом разделе мы представляем предварительный анализ надежности Codex, используя модель Непрерывной Временной Цепи Маркова (CTMC) для оценки гарантий долговечности. Мы начинаем с описания модели, а затем переходим к результатам анализа.
-As a first approximation, one could start from the above disk MTTF numbers, and try to factor in other reasons of permanent node failures. Disk MTTF is specified in the range of 1e+6 hours, however, we have good reasons to be more pessimistic, or at least err on the more unreliable side, and assume MTTF in the 1e+4 hour range, i.e. around a year.
+### 5.1 Модель надежности
+Мы моделируем надежность Codex с помощью CTMC, где состояния представляют собой различные конфигурации системы, а переходы между состояниями представляют собой события, такие как отказы узлов и восстановление данных. Модель учитывает следующие параметры:
-For the sake of modeling, we also assume i.i.d. (independent and identically distributed) failures among the set of nodes storing a given dataset. This is an optimistic model compared to cases where some storage providers might fail together e.g. because of being on shared hardware, in the same data center, or being under the same administrative authority. We will model these correlated events in a separate document.
+1. **Параметры узлов**:
+ - $\lambda$: Интенсивность отказов узлов (количество отказов в единицу времени).
+ - $\mu$: Интенсивность восстановления узлов (количество восстановлений в единицу времени).
-There might also be malicious nodes in the set of storage providers, e.g. withholding data when reconstruction would be required. Again, we will extend the model to these in a separate document.
+2. **Параметры данных**:
+ - $k$: Количество исходных фрагментов данных.
+ - $n$: Общее количество фрагментов после кодирования стирания.
+ - $m$: Минимальное количество фрагментов, необходимых для восстановления данных.
-### 5.2. Reconstruction Model
+3. **Параметры сети**:
+ - $N$: Общее количество узлов в сети.
+ - $S$: Количество узлов хранения.
-The next important time related parameter of the model is **MTTR** (Mean Time To Reconstruct). While we model events at the level of a single dataset, it is important to note here that a failure event most probably involves entire disks or entire nodes with multiple disks, with many datasets and a large amount of data. Therefore, in the case of reconstruction, the stochastic processes of individual datasets are not independent of each other, leading to higher and uncertain reconstruction times.
+### 5.2 Результаты анализа
+Наш анализ показывает, что Codex может обеспечить высокие гарантии долговечности при разумных параметрах системы. Вот некоторые из ключевых результатов:
-The actual repair time depends on a number of factors:
-- time to start repairing the dataset,
-- data transmission for the purposes of Erasure Code decoding,
-- EC decoding itself,
-- allocating the new nodes to hold the repaired blocks,
-- distributing repaired data to the allocated nodes.
+1. **Вероятность потери данных**: Вероятность потери данных уменьшается с увеличением уровня избыточности ($n/k$) и количества узлов хранения ($S$).
-Overall, it is clearly not easy to come up with a reasonable distribution for the time of repair, not even the mean time of repair. While time to repair is most probably not an exponential distribution, we model it as such in a first approximation to allow Markov Chain based modeling.
-
-### 5.3. Triggering Reconstruction
+2. **Время до потери данных**: Среднее время до потери данных увеличивается с увеличением уровня избыточности и количества узлов хранения.
-Reconstruction and re-allocation of slots can be triggered by the observed state, and our system "observes" state through the proving process. In our model, we assume that nodes are providing proofs according to a random process with an exponential distribution between proving times, with **MTBF** (Mean Time Between Proofs) mean, i.i.d. between nodes. Other distributions are also possible, but for the sake of modelling we start with an exponential distribution, which is also simple to implement in practice.
+3. **Влияние параметров**: На надежность системы влияют следующие параметры:
+ - **Уровень избыточности**: Более высокий уровень избыточности приводит к более высокой надежности.
+ - **Количество узлов хранения**: Большее количество узлов хранения приводит к более высокой надежности.
+ - **Интенсивность отказов**: Более низкая интенсивность отказов приводит к более высокой надежности.
+ - **Интенсивность восстановления**: Более высокая интенсивность восстановления приводит к более высокой надежности.
-Reconstruction can be triggered based on the observed state in various ways:
-- if an individual node is missing a slot proof (or more generally, a series of proofs), reconstruction can start. The advantage of this option is that the consequences of failing a proof only depend on the node itself, and not on other nodes.
-- reconstruction can also be triggered by the observed system state, i.e. the number of nodes that have missed the last proof (or more in general some of the last proofs). In fact, thanks to the properties of RS codes, whenever a slot is being repaired, all slot's data are regenerated. As a consequence, the cost of repair is independent of the number of slots being repaired, and by triggering repair only after multiple slots are observed lost (the so called "lazy repair"), we can drastically reduce the cost of repair.
+### 5.3 Практические последствия
+Наш анализ имеет следующие практические последствия для проектирования и эксплуатации систем на основе Codex:
-In our model, we assume reconstruction that uses a combination of the above too triggers.
-- Reconstruction is triggered based on the observed system state, allowing for lazy repair, by triggering it when $l_0$ of the slots is considered lost.
-- A single slot is considered lost if it was missing the last $l_1$ proofs.
+1. **Выбор параметров**: Пользователи могут выбирать параметры системы, такие как уровень избыточности и количество узлов хранения, для достижения желаемых гарантий долговечности.
-Other reconstruction strategies, such as considering all the proofs from all the slots in a time window, are also possible, but we leave these for further study.
+2. **Мониторинг и обслуживание**: Системы на основе Codex должны регулярно контролироваться и обслуживаться для поддержания надежности.
-### 5.4. CTMC Model
+3. **Масштабирование**: Системы на основе Codex могут масштабироваться для хранения больших объемов данных при сохранении высоких гарантий долговечности.
-We model the system using a CTMC with a multi-dimensional state space representing slot status and proof progress. To keep the description simple, we introduce the model for the case of $l_1 = 1$ here. An extension to $l_1 > 1$ is possible by increasing the dimensions of the state space to $1+l_1$.
+## 6. Выводы и будущая работа
+В этой статье мы представили Codex, новую децентрализованную сеть хранения данных с кодированием стирания, которая пытается решить проблемы централизованного облачного хранения. Мы ввели концепцию Движка Децентрализованной Долговечности (DDE) как структуру для систематического решения вопросов долговечности в децентрализованных системах хранения.
-**State space.** We model the system with a multi-dimensional state space $S_{l,f}$ with the following dimensions:
-- losses: $l \in [0, \cdots, m+1]$: the number of lost slots. Practical values of $l$ go from $0$ to $m$. As soon as $l$ reaches $m+1$, the dataset can be considered lost.
-- observations: $f \in [0, \cdots, l]$ is the number of slots with the last test failed, or in other words, observed losses. Repair is triggered when $l \ge l_0$. Since repair reallocates slots to new nodes, we can assume that repaired slots are all available after the process. Hence, $f \le l$ in all reachable states.
+### 6.1 Основные выводы
+Наши основные выводы включают:
-**State transition rates.** From a given state $S_{l,f}$ we can get to the following states:
-- slot loss, $S_{l+1,f}$: slot loss is driven by MTTF, assuming i.i.d slot losses. Obviously, only available slots can be lost, so the transition probability also depends on $n-l$.
-- missing proofs, $S_{l,f+1}$: we are only interested in the event of observing the loss of a slot that we haven't seen before. Thus, the state transition probability depends on $f-l$.
-- repair, $S_{0,0}$: repair is only triggered once the number of observed losses reaches the lazy repair threshold $l_0$. In case of a successful repair, all slots are fully restored (even if the actual set of nodes storing the slots are changing).
-
-States $S_{M+1,f}$ for each $f$ are absorbing states. By calculating the expected time of absorption, we can quantify the reliability of the system.
-
-
-
-
-### Linux/macOS {#basic-linux-macos} -1. Download the master tarball from the Codex testnet starter repository, and untar its contents: +1. Скачайте мастер-архив из репозитория Codex testnet starter и распакуйте его содержимое: ```shell curl -LO https://github.com/codex-storage/codex-testnet-starter/archive/master.tar.gz tar xzvf master.tar.gz rm master.tar.gz ``` -2. Navigate to the scripts folder: +2. Перейдите в папку со скриптами: ```shell cd codex-testnet-starter-master/scripts ``` -3. Install dependencies when required: +3. Установите зависимости при необходимости: ```shell # Debian-based Linux sudo apt update && sudo apt install libgomp1 ``` -4. Download Codex binaries from GitHub releases: +4. Скачайте бинарные файлы Codex из релизов GitHub: ```shell ./download_online.sh ``` -5. Generate an ethereum keypair: +5. Сгенерируйте пару ключей ethereum: ```shell ./generate.sh ``` - Your private key will be saved to `eth.key` and address to `eth.address` file. + Ваш приватный ключ будет сохранен в файле `eth.key`, а адрес - в файле `eth.address`. -6. Fill-up your address shown on the screen with the tokens: - - Use the web faucets to mint some [ETH](https://faucet-eth.testnet.codex.storage) and [TST](https://faucet-tst.testnet.codex.storage) tokens. - - We can also do this using Discord [# bot](https://discord.com/channels/895609329053474826/1230785221553819669) channel - - Use `/set ethaddress` command to enter your generated address - - Use `/mint` command to receive ETH and TST tokens - - Use `/balance` command to check if you have received test tokens successfully +6. Пополните ваш адрес, показанный на экране, токенами: + - Используйте веб-краны для получения [ETH](https://faucet-eth.testnet.codex.storage) и [TST](https://faucet-tst.testnet.codex.storage) токенов. + - Мы также можем сделать это с помощью канала Discord [# bot](https://discord.com/channels/895609329053474826/1230785221553819669) + - Используйте команду `/set ethaddress` для ввода вашего сгенерированного адреса + - Используйте команду `/mint` для получения ETH и TST токенов + - Используйте команду `/balance` для проверки успешного получения тестовых токенов -7. Run Codex node: +7. Запустите узел Codex: ```shell ./run_client.sh ``` -8. Configure [port forwarding](#basic-common) and we are ready go to. +8. Настройте [проброс портов](#basic-common), и мы готовы к работе. ### Windows {#basic-windows} -1. Download the master tarball from the Codex testnet starter repository, and untar its contents: +1. Скачайте мастер-архив из репозитория Codex testnet starter и распакуйте его содержимое: > [!WARNING] - > Windows antivirus software and built-in firewalls may cause steps to fail. We will cover some possible errors here, but always consider checking your setup if requests fail - in particular, if temporarily disabling your antivirus fixes it, then it is likely to be the culprit. + > Антивирусное ПО Windows и встроенные брандмауэры могут вызвать сбой шагов. Мы рассмотрим некоторые возможные ошибки здесь, но всегда учитывайте проверку вашей настройки, если запросы не выполняются - в частности, если временное отключение антивируса решает проблему, то, вероятно, он является причиной. ```batch curl -LO https://github.com/codex-storage/codex-testnet-starter/archive/master.tar.gz ``` - If you see an error like: + Если вы видите ошибку: ```batch curl: (35) schannel: next InitializeSecurityContext failed: CRYPT_E_NO_REVOCATION_CHECK (0x80092012) - The revocation function was unable to check revocation for the certificate. ``` - You may need to add the `--ssl-no-revoke` option to your curl call, e.g.: + Возможно, вам нужно добавить опцию `--ssl-no-revoke` к вашему вызову curl, например: ```batch curl -LO --ssl-no-revoke https://github.com/codex-storage/codex-testnet-starter/archive/master.tar.gz ``` -1. Extract the contents of the tar file, and then delete it: +1. Распакуйте содержимое tar-файла и затем удалите его: ```batch tar xzvf master.tar.gz del master.tar.gz ``` -2. Navigate to the scripts folder: +2. Перейдите в папку со скриптами: ```batch cd codex-testnet-starter-master\scripts\windows ``` -3. Download Codex binaries from GitHub releases: +3. Скачайте бинарные файлы Codex из релизов GitHub: ```batch download-online.bat ``` -4. Generate an ethereum keypair: +4. Сгенерируйте пару ключей ethereum: ```batch generate.bat ``` - Your private key will be saved to `eth.key` and address to `eth.address` file. + Ваш приватный ключ будет сохранен в файле `eth.key`, а адрес - в файле `eth.address`. -5. Fill-up your address shown on the screen with the tokens: - - Use the web faucets to mint some [ETH](https://faucet-eth.testnet.codex.storage) and [TST](https://faucet-tst.testnet.codex.storage) tokens. - - We can also do this using Discord [# bot](https://discord.com/channels/895609329053474826/1230785221553819669) channel - - Use `/set ethaddress` command to enter your generated address - - Use `/mint` command to receive ETH and TST tokens - - Use `/balance` command to check if you have received test tokens successfully +5. Пополните ваш адрес, показанный на экране, токенами: + - Используйте веб-краны для получения [ETH](https://faucet-eth.testnet.codex.storage) и [TST](https://faucet-tst.testnet.codex.storage) токенов. + - Мы также можем сделать это с помощью канала Discord [# bot](https://discord.com/channels/895609329053474826/1230785221553819669) + - Используйте команду `/set ethaddress` для ввода вашего сгенерированного адреса + - Используйте команду `/mint` для получения ETH и TST токенов + - Используйте команду `/balance` для проверки успешного получения тестовых токенов -6. Run Codex node: +6. Запустите узел Codex: ```batch run-client.bat ``` - 7. Configure [port forwarding](#basic-common) and we are ready go to. + 7. Настройте [проброс портов](#basic-common), и мы готовы к работе. -### All OS {#basic-common} +### Все ОС {#basic-common} -Configure [port forwarding](https://en.wikipedia.org/wiki/Port_forwarding) on your Internet router -| # | Protocol | Port | Description | -| - | -------- | ------ | ----------------- | +Настройте [проброс портов](https://en.wikipedia.org/wiki/Port_forwarding) на вашем интернет-маршрутизаторе +| # | Протокол | Порт | Описание | +| - | -------- | ------ | -------------- | | 1 | `UDP` | `8090` | `Codex Discovery` | | 2 | `TCP` | `8070` | `Codex Transport` | -After your node is up and running, you can use the [Codex API](/developers/api) to be able to interact with your Codex node, please check our [API walk-through](/learn/using) for more details. +После того как ваш узел запущен и работает, вы можете использовать [Codex API](/developers/api) для взаимодействия с вашим узлом Codex, пожалуйста, ознакомьтесь с нашим [пошаговым руководством по API](/learn/using) для получения более подробной информации. -You also can use [Codex App UI](https://app.codex.storage) to interact with your local Codex node. +Вы также можете использовать [Codex App UI](https://app.codex.storage) для взаимодействия с вашим локальным узлом Codex. -Need help? Reach out to us in [#:sos:|node-help](https://discord.com/channels/895609329053474826/1286205545837105224) channel or check [troubleshooting guide](/learn/troubleshoot.md). +Нужна помощь? Обратитесь к нам в канале [#:sos:|node-help](https://discord.com/channels/895609329053474826/1286205545837105224) или проверьте [руководство по устранению неполадок](/learn/troubleshoot.md). -## Running a Storage Provider (Web Version) {#sp-guide-web} +## Запуск Storage Provider (Веб-версия) {#sp-guide-web} -Work in progress :construction: +В процессе разработки :construction: -## Testnet Data +## Данные Testnet -### Bootstrap Nodes +### Bootstrap-узлы **Codex** ```shell spr:CiUIAhIhAiJvIcA_ZwPZ9ugVKDbmqwhJZaig5zKyLiuaicRcCGqLEgIDARo8CicAJQgCEiECIm8hwD9nA9n26BUoNuarCEllqKDnMrIuK5qJxFwIaosQ3d6esAYaCwoJBJ_f8zKRAnU6KkYwRAIgM0MvWNJL296kJ9gWvfatfmVvT-A7O2s8Mxp8l9c8EW0CIC-h-H-jBVSgFjg3Eny2u33qF7BDnWFzo7fGfZ7_qc9P @@ -184,20 +184,20 @@ enode://6eeb3b3af8bef5634b47b573a17477ea2c4129ab3964210afe3b93774ce57da832eb110f enode://6ba0e8b5d968ca8eb2650dd984cdcf50acc01e4ea182350e990191aadd79897801b79455a1186060aa3818a6bc4496af07f0912f7af53995a5ddb1e53d6f31b5@209.38.160.40:40070 ``` -### Smart contracts +### Смарт-контракты -| Contract | Address | -| ----------- | ----------------------------------------------------------------------------------------------------------------------------------------- | -| Token | [`0x34a22f3911De437307c6f4485931779670f78764`](https://explorer.testnet.codex.storage/address/0x34a22f3911De437307c6f4485931779670f78764) | -| Verifier | [`0x02dd582726F7507D7d0F8bD8bf8053d3006F9092`](https://explorer.testnet.codex.storage/address/0x02dd582726F7507D7d0F8bD8bf8053d3006F9092) | -| Marketplace | [`0xfFaF679D5Cbfdd5Dbc9Be61C616ed115DFb597ed`](https://explorer.testnet.codex.storage/address/0xfFaF679D5Cbfdd5Dbc9Be61C616ed115DFb597ed) | +| Контракт | Адрес | +| ----------- | --------------------------------------------------------------------------------------------------------------------------------------- | +| Токен | [`0x34a22f3911De437307c6f4485931779670f78764`](https://explorer.testnet.codex.storage/address/0x34a22f3911De437307c6f4485931779670f78764) | +| Верификатор | [`0x02dd582726F7507D7d0F8bD8bf8053d3006F9092`](https://explorer.testnet.codex.storage/address/0x02dd582726F7507D7d0F8bD8bf8053d3006F9092) | +| Маркетплейс | [`0xfFaF679D5Cbfdd5Dbc9Be61C616ed115DFb597ed`](https://explorer.testnet.codex.storage/address/0xfFaF679D5Cbfdd5Dbc9Be61C616ed115DFb597ed) | -### Endpoints +### Эндпоинты -| # | Service | URL | -| - | --------------- | ---------------------------------------------------------------------------- | +| # | Сервис | URL | +| - | -------------- | ---------------------------------------------------------------------------- | | 1 | Geth Public RPC | [rpc.testnet.codex.storage](https://rpc.testnet.codex.storage) | -| 2 | Block explorer | [explorer.testnet.codex.storage](https://explorer.testnet.codex.storage) | -| 3 | Faucet ETH | [faucet-eth.testnet.codex.storage](https://faucet-eth.testnet.codex.storage) | -| 4 | Faucet TST | [faucet-tst.testnet.codex.storage](https://faucet-tst.testnet.codex.storage) | -| 5 | Status page | [status.testnet.codex.storage](https://status.testnet.codex.storage) | +| 2 | Обозреватель блоков | [explorer.testnet.codex.storage](https://explorer.testnet.codex.storage) | +| 3 | Кран ETH | [faucet-eth.testnet.codex.storage](https://faucet-eth.testnet.codex.storage) | +| 4 | Кран TST | [faucet-tst.testnet.codex.storage](https://faucet-tst.testnet.codex.storage) | +| 5 | Страница статуса | [status.testnet.codex.storage](https://status.testnet.codex.storage) |