Spartan PoC v2 на Substrate

Мы рады сообщить, что Subspace Labs выполнила вторую веху для нашего открытого гранта Web 3 Foundation, чтобы обеспечить консенсус Proof-of-Capacity (PoC) для Substrate! Для получения дополнительной информации о цели этого гранта и консенсусе PoC, пожалуйста, обратитесь к нашей предыдущей статье.

На предыдущем этапе мы продемонстрировали возможность запуcка цепочки разработки с одним узлом, используя наш новый модуль консенсуса Spartan PoC, который поддерживал только одного фермера с участком постоянного размера. На этом этапе мы обновили Spartan для поддержки нескольких фермеров с участками разного размера, которые могут совместно обрабатывать новые блоки через локальную тестовую сеть. Кроме того, Spartan также поддерживает синхронизацию с другими полными и легкими клиентскими узлами, включая приложение для браузера, которое отображает текущий объем дискового пространства, выделенного сети всеми фермерами.

Диапазон динамических решений

Ключевой технической задачей для этой вехи было внедрение алгоритма динамической корректировки диапазона решений для обеспечения постоянной скорости производства блоков, аналогичной динамической корректировке сложности работы в блокчейнах Proof-of-Work (PoW), таких как Биткойн.

Spartan, как и BABE, основан на Ouroboros Praos, который делит время на дискретные временные интервалы и более крупные эпохи. В настоящее время у нас есть односекундные временные интервалы и 32 x 6 = 216 временных интервалов на эпоху. В идеале мы хотели бы видеть один блок каждые шесть секунд, чтобы гарантировать, что (в среднем) любой блок сможет полностью распространиться по сети до того, как будет найден следующий блок, уменьшая вероятность честных разветвлений, что снижает безопасность сети.

Согласно консенсусу Spartan PoC, для каждого нового временного интервала мы создаем новое соревнование. Затем каждый фермер запрашивает свой участок, чтобы найти приверженность кодировке, которая удовлетворяет текущему диапазону решений. Любой фермер, который находит обязательство в пределах указанного диапазона (диапазона решения) задачи, может затем сгенерировать PoC и создать новый блок. Для получения более подробной информации, пожалуйста, обратитесь к проектной документации. Чтобы убедиться, что мы поддерживаем в среднем шесть секунд (шесть временных интервалов) между блоками, мы должны гарантировать, что протокол автоматически регулирует диапазон решений на основе наблюдаемой скорости производства блоков, которая будет со временем меняться по мере роста и сокращения дискового пространства, выделенного для сети.

Для этого мы дополнительно группируем временные интервалы по эпохам 6 x 2016 = 12 096 интервалов или примерно 3,4 часа. Это имитирует сброс сложности работы Биткойна, который происходит каждые 2016 блоков. Каждую эпоху мы подсчитываем количество произведенных блоков, а затем вычисляем поправочный коэффициент на основе цели в 2016 блоков. Если поправочный коэффициент меньше единицы, это означает, что заложенное пространство уменьшилось, а блоки расположены слишком далеко друг от друга, что требует увеличения диапазона решения. Если поправочный коэффициент больше единицы, это означает, что заложенное пространство увеличилось, а блоки расположены слишком близко друг к другу, что требует уменьшения диапазона решения.

Чтобы увидеть это в действии, вы можете запустить новый Spartan узел из генезиса и просто удвоить размер его графика с 1 ГБ по умолчанию до 2 ГБ, что приведет к созданию одного блока примерно каждые три секунды, пока не будет введено первое изменение эпохи. Чтобы упростить наблюдение за этим при тестировании, мы изменили настройки по умолчанию таким образом, чтобы смена эпох вступала в силу каждые 32 блока.

Примечание. В этих инструкциях предполагается, что фармер работает на одном терминале, а клиент — на другом.

Сначала установите Docker.

Инициализизация фармера (Terminal 1)

Создайте место для плота, извлеките последнее изображение и инициализируйте плот размером 2 ГиБ (должно занять несколько минут):

Примечание. Если вы ранее запускали Spartan Farmer, вам нужно будет сначала стереть участок, прежде чем создавать больший участок, или изменить имя фармера.

docker volume create spartan-farmer
docker pull subspacelabs/spartan-farmer
docker run --rm -it \
 --name spartan-farmer \
 --mount source=spartan-farmer,target=/var/spartan \
 subspacelabs/spartan-farmer plot 512000 spartan

Запуск клиента (Terminal 2)

Это создаст виртуальную сеть, вытащит последний образ из докера и запустит цепочку разработки с одним узлом (только для клиента):

docker network create spartan
docker pull subspacelabs/node-template-spartan
docker run --rm --init -it \
 --net spartan \
 --name node-template-spartan \
 --publish 127.0.0.1:30333:30333 \
 --publish 127.0.0.1:9944:9944 \
 --publish 127.0.0.1:9933:9933 \
 subspacelabs/node-template-spartan \
 --dev \
 --tmp \
 --ws-external \
 --node-key 0000000000000000000000000000000000000000000000000000000000000001

Запуск фармера (Terminal 1)

Когда клиент запущен, вы можете подключить к нему фармер, запустив в первом терминале следующее:

docker run --rm --init -it \
 --net spartan \
 --name spartan-farmer \
 --mount source=spartan-farmer,target=/var/spartan \
 subspacelabs/spartan-farmer \
 farm \
 --ws-server ws://node-template-spartan:9944

Теперь вы должны увидеть производство блоков во втором терминале. Сначала каждые три секунды, а затем, в конце концов, каждые шесть секунд (после вступления в силу смены эпохи).

Полная синхронизация клиента

Полный клиент, также известный как полный узел, поддерживает полную базу данных учетных записей или состояние блокчейна, а также последние несколько блоков. Он не участвует в консенсусе, если к нему также не присоединен фармер.

Запуск полного клиента (Terminal 3)
Теперь мы можем запустить еще один полный клиент и синхронизировать цепочку с первым клиентом, который мы запустили ранее:

BOOTSTRAP_CLIENT_IP=$(docker inspect -f "{{.NetworkSettings.Networks.spartan.IPAddress}}" node-template-spartan)
docker run --rm --init -it \
 --net spartan \
 --name node-template-spartan-full \
 subspacelabs/node-template-spartan \
 --dev \
 --tmp \
 --ws-external \
 --bootnodes /ip4/$BOOTSTRAP_CLIENT_IP/tcp/30333/p2p/12D3KooWEyoppNCUx8Yx66oV9fJnriXwCcXwDDUA2kj6vnc6iDEp

Синхронизация клиента Light
Light клиент не поддерживает базу данных учетных записей или состояние блокчейна. Вместо этого он отслеживает только заголовки блоков, чтобы быть уверенным, что он действительно находится в самой длинной цепочке или, в нашем случае, в цепочке с наибольшим пространством.

Запуск клиента Lights (Terminal 4)

Мы также можем запустить клиент Light и синхронизировать цепочку с клиентом, который мы запустили ранее:

BOOTSTRAP_CLIENT_IP=$(docker inspect -f "{{.NetworkSettings.Networks.spartan.IPAddress}}" node-template-spartan)
docker run --rm --init -it \
 --net spartan \
 --name node-template-spartan-light \
 subspacelabs/node-template-spartan \
 --dev \
 --tmp \
 --light \
 --ws-external \
 --bootnodes /ip4/$BOOTSTRAP_CLIENT_IP/tcp/30333/p2p/12D3KooWEyoppNCUx8Yx66oV9fJnriXwCcXwDDUA2kj6vnc6iDEp

Браузерный клиент

Мы также расширили интерфейс Substrate для вычисления и отображения общего пространства, выделенного сети всеми фермерами, которое может быть получено из качества самого доказательства пространства.

Установка и запуск браузерного клиента (Terminal 5)

Кодовая база устанавливается с помощью git и yarn. Этот шаг предполагает, что вы установили yarn перед установкой в репозиториях. Чтобы узнать о самой последней версии и о том, как установить yarn, обратитесь к документации yarn и руководству по установке.

git clone -b w3f-spartan-ms-2 https://github.com/subspace/substrate-front-end-template.git
cd substrate-front-end-template
yarn install
yarn start

Это должно автоматически открыть новую вкладку браузера, указывающую на:
http://localhost:8000/substrate-front-end-template

Теперь вы должны увидеть текущую статистику блокчейна, включая объем пространства, выделенного для сети, который будет обновляться при каждой смене эпохи или каждые 32 блока.

Запуск локальной тестовой сети

Теперь мы можем добавить больше фармеров для создания локальной тестовой сети, и диапазон решения будет автоматически корректироваться каждые 32 блока.

Вы можете использовать скрипт ./run-node-farmer-pair.sh test, чтобы запустить больше полноценных узлов в сети, каждый со своим фармером. Где test - это имя пары. Вы можете создать столько пар, сколько необходимо, все они будут подключаться к одной и той же локальной тестовой сети.

# You must first clone or pull down the latest from our fork of 
# substrate:

git clone -b w3f-spartan-ms-2 
https://github.com/subspace/substrate.git

# or if you have already cloned locally

cd ../substrate
git pull 
git checkout w3f-spartan-ms-2

# Now spin up as many farmers as you like (three in this example)

# Terminal 6 (second farmer)
cd substrate/bin/node-template-spartan
./run-node-farmer-pair.sh farmer-1

# Terminal 7 (third farmer)
cd substrate/bin/node-template-spartan
./run-node-farmer-pair.sh farmer-2

# Terminal 8 (fourth farmer)
cd substrate/bin/node-template-spartan
./run-node-farmer-pair.sh farmer-3

Используйте Ctrl+C для остановки каждой пары, все будет остановлено и очищено автоматически.

Следующие шаги для Spartan

Для нашей следующей и последней вехи мы расширим Spartan, чтобы он был защищен от всех известных атак против протоколов консенсуса proof-of-space, чтобы мы могли гарантировать безопасность и живучесть для любого экономически рационального противника, который контролирует менее половины всех ресурсов хранения сетии. Это включает:

1. "Двусмысленность", или построение на обеих ветвях вилки.
2. "Симуляция", более известное как атака «ничего на кону».
3. "Sybill Farming" или использование нескольких удостоверений для одного и того же участка диска.
4. "Compression Farmin2g, худший тип атаки на компромисс между пространством и временем для Spartan.
5. "Переписывание истории", также известное как дальняя атака.

Мы также готовимся к запуску начальной не стимулируемой тестовой сети, чтобы мы могли начать создание сообщества фармеров хранения и проверить надежность нашего протокола в реальных условиях. Позже, когда мы сможем расширить Spartan до Subspace с консенсусом, основанным на доказательствах полезного хранения, мы перейдем к стимулированной тестовой сети в рамках подготовки к запуску нашей основной сети.