Ethetreum. Стейкинг. Запуск валидатора.

Автор: | 2 октября 2022

Поша­го­вое подроб­ное руко­вод­ство по уста­нов­ке и запус­ку:

  • ноды Эфи­ра,
  • кон­сен­сус кли­ен­та,
  • вали­да­то­ра

Ввод­ные дан­ные:

  • Ubuntu 20.04.4 LTS
  • Кли­ент ноды — Geth
  • Кли­ент кон­сен­су­са — Prysm

Пре­ду­пре­жу сра­зу — ману­ал будет длин­ный и подроб­ный.

Дисклеймер

Дан­ное руко­вод­ство носит исклю­чи­тель­но инфор­ма­ци­он­ный харак­тер и не явля­ет­ся про­фес­си­о­наль­ным сове­том. Автор не гаран­ти­ру­ет точ­ность инфор­ма­ции в этой ста­тье, и автор не несет ответ­ствен­но­сти за любой ущерб или убыт­ки, поне­сен­ные в резуль­та­те сле­до­ва­ния этой ста­тье.

Системные требования

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

Настройка сервера

Я не буду подроб­но опи­сы­вать настрой­ку сер­ве­ра, оста­нов­люсь толь­ко на син­хро­ни­за­ции вре­ме­ни. Для пра­виль­ной син­хро­ни­за­ции блок­чей­на обя­за­тель­но нуж­но настро­ить точ­ное вре­мя. В Ubuntu встро­е­на син­хро­ни­за­ция вре­ме­ни. Про­ве­ря­ем.

timedatectl

Будет при­мер­но как на скрин­шо­те, в зави­си­мо­сти от настро­ек Ваше­го часо­во­го поя­са

Нуж­но удо­сто­ве­рить­ся, что NTP service — active. Если нет — вклю­ча­ем:

sudo timedatectl set-ntp on

Создаем JWT файл

Испол­ни­тель­ный кли­ент и кли­ент кон­сен­су­са для обще­ния меж­ду собой исполь­зу­ют защи­щен­ный меха­низм аутен­ти­фи­ка­ции JSON Web Token — JWT. В реаль­но­сти это файл, кото­рый содер­жит слу­чай­но сге­не­ри­ро­ван­ную 32-бай­то­вую шест­на­дца­те­рич­ную стро­ку. Созда­дим этот файл.

Созда­ем пап­ку для хра­не­ния фай­ла:

sudo mkdir -p /var/lib/jwtsecret

Теперь созда­дим файл JWT, исполь­зуя биб­лио­те­ку openssl

openssl rand -hex 32 | sudo tee /var/lib/jwtsecret/jwt.hex > /dev/null

Про­ве­рим что полу­чи­лось

sudo cat /var/lib/jwtsecret/jwt.hex

Файл готов и чуть поз­же путь к фай­лу мы ука­жем для испол­ни­тель­но­го кли­ен­та и для кли­ен­та кон­сен­су­са.

Установка Geth

Для ноды я буду исполь­зо­вать пап­ку /home — имен­но она рас­по­ло­же­на на быст­ром NvME дис­ке. Создаю поль­зо­ва­те­ля:

sudo adduser geth

Добав­ляю его в sudo

usermod -G sudo geth

Даль­ше уже от име­ни это­го поль­зо­ва­те­ля:

su geth

Ста­вим нуж­ные паке­ты, добав­ля­ем репо­зи­то­рий и уста­нав­ли­ва­ем ethereum и geth

sudo apt install software-properties-common
sudo add-apt-repository -y ppa:ethereum/ethereum
sudo apt update
sudo apt install ethereum geth

Про­ве­ря­ем вер­сию:

geth version

Теперь сде­ла­ем кон­фиг файл для запус­ка ноды сер­ви­сом.

sudo nano /lib/systemd/system/geth.service

И доба­вим в него сле­ду­ю­щие стро­ки

[Unit]
Description=Ethereum go client
After=syslog.target network.target

[Service]
Type=simple
User=geth
Group=geth

ExecStart=/usr/bin/geth \
  --http \
  --http.addr "127.0.0.1" \
  --authrpc.addr localhost \
  --authrpc.port 8551 \
  --authrpc.vhosts localhost \
  --authrpc.jwtsecret /var/lib/jwtsecret/jwt.hex \
  --syncmode "snap" \
  --cache 4096 \

StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=geth

Restart=allways
RestartSec=5

[Install]
WantedBy=multi-user.target

Я не ука­зы­ваю пара­метр datadir — пото­му что по умол­ча­нию пап­ка создаст­ся в домаш­нем ката­ло­ге, как мне и надо.

Сохра­ня­ем, пере­чи­ты­ва­ем systemd, стар­ту­ем сер­вис и про­ве­ря­ем его ста­тус:

sudo systemctl daemon-reload
sudo systemctl start geth
sudo systemctl status geth

Нода запу­сти­лась и нач­нет син­хро­ни­зи­ро­вать­ся, как толь­ко кон­сен­сус кли­ент син­хро­ни­зи­ру­ет­ся (до merge нода син­хро­ни­зи­ро­ва­лась сама, теперь же она даже не нач­нет до тех пор, пока свою часть не выпол­нит кон­сен­сус).

Если нуж­но что бы сер­вис запус­кал­ся сам при стар­те систе­мы — выпол­ня­ем:

sudo systemctl enable geth

Выделяем лог файлы

Все логи ноды пой­дут в syslog, а их будет мно­го при син­хро­ни­за­ции. Поэто­му я выде­ляю их в отдель­ные фай­лы. Созда­ем кон­фиг для rsyslog:

sudo nano /etc/rsyslog.d/40-geth.conf

Доба­вим в него такие стро­ки:

if $programname == 'geth' then {
  if $msg contains 'error' then
    /var/log/geth/geth.err
  /var/log/geth/geth.log
 & ~
}

И сра­зу сде­ла­ем кон­фиг для рота­ции логов:

nano /etc/logrotate.d/geth

Доба­вим в него такие стро­ки:

/var/log/geth/geth.log {
        daily
        rotate 7
        missingok
        notifempty
        create 644 syslog adm
}
/var/log/geth/geth.err {
        daily
        rotate 7
        missingok
        notifempty
        create 644 syslog adm
}

Сохра­ня­ем, пере­за­пус­ка­ем rsyslog и logrotate

sudo systemctl restart rsyslog.service
sudo systemctl restart logrotate.service

В резуль­та­те это­го у нас появит­ся пап­ка /var/log/geth в ней будут лог фай­лы ноды и они будут еже­днев­но роти­ро­вать­ся.

Не забы­вай­те сле­дить за акту­аль­но­стью Geth, теку­щую ста­биль­ную вер­сию мож­но про­ве­рять здесь. Идем даль­ше.

Консенсус клиент — prysm

Идем на сайт за акту­аль­ным рели­зом. На момент напи­са­ния — v3.1.1 , ска­чи­ва­ем beacon-chain сле­ду­ю­щей коман­дой:

curl -LO https://github.com/prysmaticlabs/prysm/releases/download/v3.1.1/beacon-chain-v3.1.1-linux-amd64

Пере­име­но­вы­ва­ем файл, даем ему пра­ва на испол­не­ние и копи­ру­ем в пап­ку /usr/local/bin :

mv beacon-chain-v3.1.1-linux-amd64 beacon-chain
chmod +x beacon-chain
sudo cp beacon-chain /usr/local/bin

Уда­ля­ем ненуж­ную копию в теку­щей пап­ке

rm beacon-chain

Когда потре­бу­ет­ся обнов­ле­ние кон­сен­сус кли­ен­та — нуж­но будет про­сто повто­рить все эти дей­ствия (пред­ва­ри­тель­но оста­но­вив сер­вис), ска­чав новый релиз.

Созда­дим поль­зо­ва­те­ля, от кото­ро­го будет рабо­тать сер­вис:

sudo useradd --shell /bin/false prysmbeacon

На теку­щий момент при пол­ной син­хро­ни­за­ции объ­ем дан­ных кон­сен­сус кли­ен­та состав­ля­ет 112 Гига­байт, поэто­му учи­ты­вай­те это при ука­за­нии datadir . Я буду хра­нить эти дан­ные в домаш­ней пап­ке толь­ко что создан­но­го поль­зо­ва­те­ля. Созда­ем дере­во папок и даем пра­ва это­му поль­зо­ва­те­лю:

sudo mkdir -p /home/prysm/beacon
sudo chown -R prysmbeacon:prysmbeacon /home/prysm/beacon

Теперь созда­дим кон­фиг файл запус­ка сер­ви­са

sudo nano /etc/systemd/system/prysmbeacon.service

И доба­вим такие стро­ки:

[Unit]
Description=Prysm Consensus Client BN (Mainnet)
Wants=network-online.target
After=network-online.target

[Service]
User=prysmbeacon
Group=prysmbeacon
Type=simple
Restart=always
RestartSec=5
ExecStart=/usr/local/bin/beacon-chain \
  --mainnet \
  --datadir=/home/prysm/beacon \
  --execution-endpoint=http://127.0.0.1:8551 \
  --jwt-secret=/var/lib/jwtsecret/jwt.hex \
  --suggested-fee-recipient=FeeRecipientAddress \
#  --checkpoint-sync-url=CheckpointSyncURL \
#  --genesis-beacon-api-url=CheckpointSyncURL \
  --accept-terms-of-use

[Install]
WantedBy=multi-user.target

Немно­го пояс­не­ний.

  • FeeRecipientAddress — нуж­но ука­зать дей­стви­тель­ный Ethereum адрес для полу­че­ния комис­сии вали­да­то­ра
  • checkpoint-sync-url и genesis-beacon-api-url — у меня эти пара­мет­ры заком­мен­ти­ро­ва­ны — я о них не знал на момент уста­нов­ки и запус­ка кон­сен­сус кли­ен­та. Они пред­на­зна­че­ны для уско­ре­ния син­хро­ни­за­ции. Я не знаю насколь­ко они уско­рят — не про­бо­вал, но опи­шу как надо настро­ить. Без этих опций син­хро­ни­за­ция кон­сен­су­са у меня заня­ла немно­гим боль­ше двух дней.
  • jwt-secret — ука­зы­ва­ем путь до фай­ла JWT, как мы это дела­ли для Geth

Получение CheckpointSyncURL

  • Идем на сайт — https://infura.io/ , реги­стри­ру­ем­ся (это бес­плат­но), и созда­ем новый ключ ETH2
  • На пане­ли нажи­ма­ем кноп­ку “Manage Key”. Нам нужен HTTPS URL сети mainnet, копи­ру­ем его и встав­ля­ем его в оба пара­мет­ра checkpoint-sync-url и genesis-beacon-api-url

Долж­но полу­чить­ся при­мер­но так:

Сохра­ня­ем, пере­чи­ты­ва­ем systemd, стар­ту­ем сер­вис и про­ве­ря­ем его ста­тус:

sudo systemctl daemon-reload
sudo systemctl start prysmbeacon
sudo systemctl status prysmbeacon

Кон­сен­сус кли­ент запу­стил­ся и начал син­хро­ни­за­цию. Нуж­но подо­ждать. Для стей­кин­га нуж­но дождать­ся пол­ной син­хро­ни­за­ции и кон­сен­сус кли­ен­та и самой ноды Ethereum.

Если нуж­но что бы сер­вис запус­кал­ся сам при стар­те систе­мы — выпол­ня­ем:

sudo systemctl enable prysmbeacon

А пока выде­лим логи и настро­им их рота­цию.

Выделяем лог файлы

Дела­ем кон­фиг файл для rsyslog:

sudo nano /etc/rsyslog.d/42-prysm.conf

Доба­вим в него такие строч­ки:

if $programname == 'beacon-chain' then {
  if $msg contains 'error' then
    /var/log/prysm/beacon-chain.err
  /var/log/prysm/beacon-chain.log
 & ~
}

Дела­ем кон­фиг для logrotate:

sudo nano /etc/logrotate.d/prysm

Доба­вим в него такие строч­ки:

/var/log/prysm/beacon-chain.log {
        daily
        rotate 7
        missingok
        notifempty
        create 644 syslog adm
}
/var/log/prysm/beacon-chain.err {
        daily
        rotate 7
        missingok
        notifempty
        create 644 syslog adm
}

Сохра­ня­ем, пере­за­пус­ка­ем rsyslog и logrotate

sudo systemctl restart rsyslog.service
sudo systemctl restart logrotate.service

В резуль­та­те это­го у нас появит­ся пап­ка /var/log/prysm в ней будут лог фай­лы кон­сен­су­са и они будут еже­днев­но роти­ро­вать­ся.

Создадим данные для стейкинга

Пока идет син­хро­ни­за­ция — под­го­то­вим все дан­ные для вали­да­то­ра. Необ­хо­ди­мо создать спе­ци­аль­ные фай­лы дан­ных, кото­рые зави­сят от коли­че­ства вали­да­то­ров, кото­рые Вы хоти­те запу­стить и про­фи­нан­си­ро­вать. Сто­ит пони­мать, что для каж­до­го вали­да­то­ра необ­хо­дим депо­зит 32 ETH, кото­рые нуж­но будет пере­чис­лить на спе­ци­аль­ные адре­са. Этот депо­зит мож­но будет выве­сти позд­нее, после отдель­но­го обнов­ле­ния сети.

Staking Deposit CLI

Ска­чи­ва­ем инстру­мент — Staking Deposit CLI, кото­рый мож­но запус­кать как на Linux, так и на Windows. Поми­мо фай­лов дан­ных для вали­да­то­ра, эта про­грам­ма гене­ри­ру­ет мне­мо­ни­че­ский ключ, кото­рый пона­до­бит­ся для выво­да депо­зи­та в неда­ле­ком буду­щем. Поэто­му нуж­но быть очень акку­рат­ны­ми при гене­ра­ции, что бы Ваши дан­ные не попа­ли в чужие руки. Есть два вари­ан­та:

  • пол­но­стью чистая и изо­ли­ро­ван­ная от интер­не­та систе­ма, на кото­рую флеш­кой копи­ру­ем бинар­ник Staking Deposit CLI, выпол­ня­ем там все опе­ра­ции. И потом нуж­ные фай­лы так­же флеш­кой пере­но­сим на маши­ну с вали­да­то­ром.
  • запус­ка­ем про­грам­му на этой же машине, где мы дела­ли все до это­го. Но для это­го реко­мен­ду­ет­ся отклю­чить ее на это вре­мя от интер­не­та.

Выбор за Вами.

Идем на сайт - и ска­чи­ва­ем акту­аль­ный релиз. На момент напи­са­ния — v2.3.0. Выби­ра­ем дис­три­бу­тив для нуж­ной плат­фор­мы и ска­чи­ва­ем. Я делаю на этой же машине — качаю для Linux:

curl -LO https://github.com/ethereum/staking-deposit-cli/releases/download/v2.3.0/staking_deposit-cli-76ed782-linux-amd64.tar.gz

Рас­па­ко­вы­ва­ем архив, пере­име­но­вы­ва­ем пап­ку, уда­ля­ем ска­чан­ный архив и захо­дим в полу­чен­ную пап­ку:

tar xvf staking_deposit-cli-76ed782-linux-amd64.tar.gz
mv staking_deposit-cli-76ed782-linux-amd64 staking-deposit-cli
rm staking_deposit-cli-76ed782-linux-amd64.tar.gz
cd staking-deposit-cli
ll

В пап­ке будет один файл:

Мне нуж­но дан­ные для двух вали­да­то­ров, поэто­му моя коман­да будет выгял­деть так:

sudo ./deposit new-mnemonic --num_validators 2 --chain mainnet

Будет два вопро­са про язык само­го при­ло­же­ния и затем язык мне­мо­ни­ки. Для выбо­ра англий­ско­го язы­ка на пер­вый вопрос отве­ча­ем циф­рой 3, на вто­рой вопрос циф­рой 4. После это­го нас попро­сят создать пароль для хра­ни­ли­ща клю­чей вали­да­то­ра. Вво­дим два раза пароль и про­грам­ма выда­ет нам мне­мо­ни­че­ский ключ. Ключ нуж­но сохра­нить в надеж­ное место. После чего нажать любую кла­ви­шу и про­грам­ма попро­сит нас вве­сти мне­мо­ни­че­ский ключ, для под­твер­жде­ния что он у нас сохра­нен. Мож­но вво­дить толь­ко пер­вые 4 сим­во­ла каж­до­го сло­ва.

Если вво­дим пра­виль­но — гене­ри­ру­ют­ся клю­чи и мы уви­дим кар­тин­ку, что все полу­чи­лось.

Про­ве­рим что в пап­ке:

  • deposit_data-1664648110.json — файл содер­жит пуб­лич­ные клю­чи вали­да­то­ра и этот файл будет исполь­зо­вать­ся на сай­та уже когда нуж­но будет зачис­лять депо­зит.
  • keystore-[..].json — фай­лы содер­жат зашиф­ро­ван­ную инфор­ма­цию клю­чей вали­да­то­ра. Один файл на каж­до­го вали­да­то­ра. Я делал два вали­да­то­ра — два фай­ла. Эти фай­лы будут импор­ти­ро­ва­ны в вали­да­тор чуть поз­же.

У нас гото­вы дан­ные для вали­да­то­ра, пере­хо­дим к его настрой­ке и запус­ку.

Валидатор

Ска­чи­ва­ем акту­аль­ную вер­сию (тоже с гит­ха­ба prysmaticlabs) — на момент напи­са­ния вер­сия v3.1.1:

curl -LO https://github.com/prysmaticlabs/prysm/releases/download/v3.1.1/validator-v3.1.1-linux-amd64

Пере­име­но­вы­ва­ем файл, даем ему пра­ва на испол­не­ние и копи­ру­ем в пап­ку /usr/local/bin:

mv validator-v3.1.1-linux-amd64 validator
chmod +x validator
sudo cp validator /usr/local/bin

Уда­ля­ем ненуж­ную копию в теку­щей пап­ке

rm validator

Импорт данных в валидатор

Нам нуж­ны фай­лы, кото­рые мы под­го­то­ви­ли и чуть рань­ше. Если Вы это дела­ли на дру­гой машине — ско­пи­руй­те их сюда. У меня они уже нахо­дят­ся на этой машине:

Созда­дим пап­ку, где будут хра­нить­ся дан­ные вали­да­то­ра:

sudo mkdir -p /var/lib/prysm/validator

Выпол­ня­ем коман­ду импор­та, ука­зав путь до пап­ки, где лежат фай­лы keystore-[..].json:

sudo /usr/local/bin/validator accounts import --keys-dir=/home/sten/staking-deposit-cli/validator_keys --wallet-dir=/var/lib/prysm/validator --mainnet

Появит­ся пред­ло­же­ние при­нять согла­ше­ние, нуж­но напи­сать accept, после чего нас попро­сят создать пароль для кошель­ка. Это не тот же пароль, что мы созда­ва­ли при гене­ра­ции клю­чей. Это имен­но пароль от кошель­ка, кото­рый будет тре­бо­вать­ся для запус­ка вали­да­то­ра. Пароль дол­жен быть не менее 8 сим­во­лов. Сохра­ни­те его в надеж­ном месте. После вво­да паро­ля и его под­твер­жде­ния появ­ля­ет­ся запрос паро­ля для импор­та акка­ун­тов вали­да­то­ра. Это как раз пароль, кото­рый мы созда­ва­ли при гене­ра­ции вали­да­то­ров, вво­дим его:

Если вве­ли пра­виль­ный пароль — запус­ка­ет­ся про­цесс импор­та. После чего систе­ма сооб­щит что все полу­чи­лось, у меня импор­ти­ро­ва­лось 2 акка­ун­та:

Для того, что бы запус­кать вали­да­тор как сер­вис, потре­бу­ет­ся сохра­нить пароль от кошель­ка в тек­сто­вый файл и про­пи­сать путь к это­му фай­лу.

sudo nano /var/lib/prysm/validator/password.txt

Встав­ля­ем свой пароль от кошель­ка и сохра­ня­ем файл.

Созда­дим поль­зо­ва­те­ля, от кото­ро­го будет рабо­тать сер­вис:

sudo useradd --no-create-home --shell /bin/false prysmvalidator

При импор­те дан­ных мы ука­зы­ва­ли дирек­то­рию /var/lib/prysm/validator — дадим ново­му поль­зо­ва­те­лю пра­ва на эту дирек­то­рию.

sudo chown -R prysmvalidator:prysmvalidator /var/lib/prysm/validator

Теперь созда­дим кон­фиг файл запус­ка сер­ви­са

sudo nano /etc/systemd/system/prysmvalidator.service

И доба­вим в него сле­ду­ю­щие стро­ки:

[Unit]
Description=Prysm Consensus Client Validator (Mainnet)
Wants=network-online.target
After=network-online.target

[Service]
User=prysmvalidator
Group=prysmvalidator
Type=simple
Restart=always
RestartSec=5
ExecStart=/usr/local/bin/validator \
  --datadir=/var/lib/prysm/validator \
  --wallet-dir=/var/lib/prysm/validator \
  --wallet-password-file=/var/lib/prysm/validator/password.txt \
  --suggested-fee-recipient=FeeRecipientAddress \
  --graffiti="<yourgraffiti>" \
  --accept-terms-of-use

[Install]
WantedBy=multi-user.target
  • FeeRecipientAddress — Ethereum адрес, на кото­рый Вы буде­те полу­чать комис­сию вали­да­то­ра
  • graffiti — Ваша уни­каль­ная стро­ка. Не пиши­те сюда ника­кой кон­фи­ден­ци­аль­ной инфор­ма­ции, это некий тег для Вас, что бы отыс­кать сво­е­го вали­да­то­ра в спис­ке.

Полу­чит­ся при­мер­но сле­ду­ю­щее:

Сохра­ня­ем, пере­чи­ты­ва­ем systemd, стар­ту­ем сер­вис и про­ве­ря­ем его ста­тус:

sudo systemctl daemon-reload
sudo systemctl start prysmvalidator
sudo systemctl status prysmvalidator

Вали­да­тор запу­стил­ся. Сра­зу настро­им его логи как обыч­но.

Выделяем лог файлы

Новый кон­фиг для rsyslog не будем делать, доба­вим стро­ки в уже име­ю­щий­ся кон­фиг для кон­сен­сус кли­ен­та:

nano /etc/rsyslog.d/42-prysm.conf

Доба­вим в него стро­ки:

if $programname == 'validator' then {
  if $msg contains 'error' then
    /var/log/prysm/validator.err
  /var/log/prysm/validator.log
 & ~
}

Полу­чит­ся так:

Тоже самое для logrotate, доба­вим в име­ю­щий­ся файл два бло­ка:

/var/log/prysm/validator.log {
        daily
        rotate 7
        missingok
        notifempty
        create 644 syslog adm
}
/var/log/prysm/validator.err {
        daily
        rotate 7
        missingok
        notifempty
        create 644 syslog adm
}

Полу­чит­ся так:

Сохра­ня­ем, пере­за­пус­ка­ем rsyslog и logrotate

sudo systemctl restart rsyslog.service
sudo systemctl restart logrotate.service

Если нуж­но что бы сер­вис запус­кал­ся сам при стар­те систе­мы — выпол­ня­ем:

sudo systemctl enable prysmvalidator

Пополнение ключей валидатора

Итак, нуж­но убе­дить­ся что кон­сен­сус кли­ент и сама нода пол­но­стью син­хро­ни­зи­ро­ва­лись и в логах вали­да­то­ра появи­лось что-то типа “Waiting for deposit to be…”, и после это­го пере­хо­дить к попол­не­нию клю­чей вали­да­то­ра. Я не буду опи­сы­вать эти шаги — на сай­те всё по-рус­ски и очень подроб­но. Про­сто иде­те по поряд­ку. Пере­хо­ди­те на сайт — Панель запус­ка стей­кин­га (ethereum.org) и нажи­май­те кноп­ку “Стать вали­да­то­ром”. На 9 шаге будет спи­сок вали­да­то­ра — не поле­ни­тесь открыть его в новом окне и про­ве­рить все пунк­ты.

На одном из шагов потре­бу­ет­ся выгру­зить файл, кото­рый мы полу­чи­ли при гене­ра­ции клю­чей, фор­ма­та deposit_data-[timestamp].json , нуж­но про­сто через бра­у­зер загру­зить его.

После это­го уже нуж­но будет вно­сить депо­зит.

Посткриптум

В прин­ци­пе, ниче­го слож­но­го, глав­ное все делать спо­кой­но и акку­рат­но. Не забы­вай­те под­дер­жи­вать фай­лы ноды, кон­сен­су­са и вали­да­то­ра в акту­аль­ном состо­я­нии — сле­ди­те за обнов­ле­ни­я­ми на гит­ха­бе. Если есть вопро­сы — зада­вай­те в комен­тах, если нуж­на помощь — пиши­те, с удо­воль­стви­ем помо­гу.

Уда­чи!

Ethetreum. Стейкинг. Запуск валидатора.: 9 комментариев

  1. Александр

    Супер, спа­си­бо! Давай еще боль­ше на эту тему и подроб­нее. Что может слу­чит­ся и что делать в тех или иных слу­ча­ях.

    1. Алексей Автор записи

      Я думаю деск­топ или нет — не так прин­ци­пи­аль­но. Если желе­зо поз­во­ля­ет и комп все­гда будет в сети и запу­щен вали­да­тор — поче­му бы и нет… Там про­сто наравне с комис­си­ей пола­га­ют­ся и штра­фы за отсут­ствие вали­да­то­ра…
      Я кста­ти тут пытал­ся понять при­быль­ность дан­но­го меро­при­я­тия, остав­лю ссы­лоч­ки на сер­ви­сы, кото­ры­ми поль­зо­вал­ся.
      https://beaconscan.com/staking-calculator
      https://ethereumprice.org/staking/

      1. ДЕНИС

        Полез­ные ссыл­ки. Спа­си­бо.
        Воз­на­граж­де­ние за staking как и slushing — это понят­но, но где-то долж­но быть и воз­на­граж­де­ние (комис­сия) за обра­бот­ку тран­зак­ций. Или это еди­ный, неде­ли­мый про­цесс.
        Запу­стим, будем смот­реть.

  2. ДЕНИС

    Шикар­ная ста­тья. Боль­шое спа­си­бо за тру­ды. Обя­за­тель­но буду про­бо­вать повто­рить. Прав­да в Linux‑е не силён, но будем раз­би­рать­ся. Про­бо­вал запус­кать под Win-10, но после “сли­я­ния” ста­ло совсем ниче­го не понят­но. Ваша ста­тья немно­го про­яс­ни­ла ситу­а­цию.
    Вопрос: Если сге­не­ри­ро­ва­ны клю­чи для двух вали­да­то­ров, тогда каж­дый вали­да­тор нуж­но запус­кать на отдель­ной (пер­со­наль­ной) физи­че­ской машине, или мож­но запу­стить на одном систем­ни­ке?
    Спа­си­бо.

    1. Алексей Автор записи

      Оба вали­да­то­ра могут быть на одной машине. Я опи­сы­вал как раз эту ситу­а­цию. Мож­но гене­рить клю­чи для двух вали­да­то­ров по отдель­но­сти — для каж­до­го полу­чать свою мне­мо­ни­ку и свой пароль. Нуж­но пони­мать огра­ни­че­ние — один ключ вали­да­то­ра (или несколь­ких) может быть запу­щен толь­ко на одной машине. Эммм, мне кажет­ся я еще боль­ше запу­тал???

      1. ДЕНИС

        То есть, как я понял, на одной машине мож­но запу­стить более одно­го вали­да­то­ра.
        А по огра­ни­че­ни­ям “систе­мы”, что­бы не попасть под “сле­ши­ро­ва­ние”, нель­зя запус­кать одни и те же клю­чи на раз­ных маши­нах (аппа­рат­ное дуб­ли­ро­ва­ние).

  3. Сергей

    Спа­си­бо за ста­тью. Пока не очень понят­но, конеч­но не хва­та­ет зна­ний. Но читать было инте­рес­но.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

*