First I’m going to try running through everything on a testnet:
Here are the steps https://launchpad.ethereum.org/en/checklist#section-one
There is a general request out for “fewer people to use Prysm” so that there is a diversity of clients on the network. Since ultimately I’m going to be a one man institution I’m going to try Teku which is built to meet institutional needs
https://launchpad.ethereum.org/en/teku
-> https://docs.teku.consensys.net/en/latest/
https://docs.teku.pegasys.tech/en/latest/HowTo/Get-Started/Installation-Options/Build-From-Source/
Ok, it looks like they can do this via docker, I’m going to fire up a little instance and see what I can get working.
I’m going to start by spinning up a T2.xlarge (16gb ram)
I set storage to 1000 GiB
Made Security group Testnet_EthValidator
Used normal security Keys
Aaaand… no public IP
ok set up, elastic ip address 44.238.236.88
Pulled up: https://medium.com/coinmonks/how-to-run-an-eth-2-0-node-on-aws-cloud-infrastructure-df55101e670b (leads back to launchnodes youtube channel. Probably should be actually run this at some point.
ok , we are just going to try to get ethereum installed…
Lets try this: https://www.quicknode.com/guides/infrastructure/how-to-install-and-run-a-geth-node
And of course AWS isn’t Ubuntu and we have to do all the YUM nonsense
https://ethereum.stackexchange.com/questions/1537/how-can-i-install-go-ethereum-on-centos
Sudo yum intall golang
ok , bailing out to try this:
https://geth.ethereum.org/docs/install-and-build/installing-geth
Done building.
Run "./build/bin/geth" to launch geth.
Yay, looks good
Let’s get it started on the goerli testnet
Cd build/bin
./geth --goerli --syncmode "light" --http
And it looks like it’s synching
Ok I just had the bright idea to stop it and try running it in screen in case (when) I log out. I did it, and (screen is named “Geth” creatively) and now for some reason synching is running super slow.
ok , I’m relaunching. I think I have CPU to spare on this rig, so I’m going to run “snap” instead of light (by just removing the synchmode) and see if it goes faster (no reason it should, maybe I just connected to some lame peers)
./geth --goerli --http
Hmm, that seems to have worked, ticking along plenty fast now.
ok, I hopped in on another terminal and created an account with
./geth account new
**I used the password that I share with lots of people, since this is testnet**
Your new key was generated
Public address of the key: 0x6C1e2AaB44774c7d332325dF57a1316Fe6841a44
Path of the secret key file: /home/ec2-user/.ethereum/keystore/UTC--2021-11-03T23-49-47.617960797Z--6c1e2aab44774c7d332325df57a1316fe6841a44
- You can share your public address with anyone. Others need it to interact with you.
- You must NEVER share the secret key with anyone! The key controls access to your funds!
- You must BACKUP your key file! Without the key, it's impossible to access account funds!
- You must REMEMBER your password! Without the password, it's impossible to decrypt the key!
ok , great I have a key, now I guess I need to get some testnet ether. The first few roads seemed to point at MyCrypto, which looks like they want money. Fuck those guys
Ok, I got some GoEth from twitter via https://faucet.goerli.mudit.blog/
That was a good point for a break. I let Geth synch overnight and it looks like it was all caught up in the morning
Ok, picking up where I left off, lets grab Teku. I’m just going to do things from binaries on this run thru… This was the link I’m working off:
https://docs.teku.pegasys.tech/en/latest/HowTo/Get-Started/Installation-Options/Build-From-Source/
I pulled the link to the binary, got it and unpacked it:
Ok, looks like we need to stall java 11: following along with this:
https://stackoverflow.com/questions/59430965/aws-how-to-install-java11-on-an-ec2-linux-machine
sudo amazon-linux-extras install java-openjdk11
Great, that worked, now able to run
[ec2-user@ip-10-0-0-110 ~]$ ./teku-21.10.1/bin/teku --help
This is really relevant for me: The beacon node and the validator don’t have to run on the same machine. The beacon node is what talks to the internet, the validator is where the keys are stored… so I will probably want to keep them separate to maximize security.
Started a new screen session called “Beacon_teku” that I’m going to fire up the teku beacon process in. I’m going to use this as a scratchpad for sorting out the command to launch that.
teku --network=pyrmont --eth1-endpoint=http://localhost:8545 \
--metrics-enabled --rest-api-enabled
Becomes
teku --network=goerli --eth1-endpoint=http://localhost:8545 \
--metrics-enabled --rest-api-enabled
I want to check to make sure I understand what port geth is running on
netstat -tulpn
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:8545 0.0.0.0:* LISTEN 4610/./geth
tcp6 0 0 :::111 :::* LISTEN -
tcp6 0 0 :::22 :::* LISTEN -
tcp6 0 0 :::30303 :::* LISTEN 4610/./geth
udp 0 0 0.0.0.0:68 0.0.0.0:* -
udp 0 0 0.0.0.0:111 0.0.0.0:* -
udp 0 0 127.0.0.1:323 0.0.0.0:* -
udp 0 0 0.0.0.0:882 0.0.0.0:* -
udp6 0 0 :::111 :::* -
udp6 0 0 ::1:323 :::* -
udp6 0 0 fe80::29:e5ff:fea2::546 :::* -
udp6 0 0 :::882 :::* -
udp6 0 0 :::30303 :::* 4610/./geth
Looks legit, so localhost 8585 will probably work fine.
[ec2-user@ip-10-0-0-110 ~]$ ./teku --network=goerli --eth1-endpoint=http://localhost:8545 --metrics-enabled --rest-api-enabled
Failed to load spec config: goerli
To display full help:
teku [COMMAND] --help
Ok, looks like I have to understand something new here. Pyrmont is the test beacon chain, and my own ignorance of how this works is showing. Time to find some good docs on this.
./teku --network=pyrmont --eth1-endpoint=http://localhost:8545 \
--metrics-enabled --rest-api-enabled
This seems to be synching, pretty slowly actually. It’s running in a screen
Went to https://pyrmont.launchpad.ethereum.org/ and got started with all that stuff. Had to be sure to click “geth” and “teku” at the right points, as well as linux…
This linked me over to https://github.com/ethereum/eth2.0-deposit-cli/releases/
So I went ahead and ran:
wget https://github.com/ethereum/eth2.0-deposit-cli/releases/download/v1.2.0/eth2deposit-cli-256ea21-linux-amd64.tar.gz
Unzipped the thing, and then ran:
./deposit new-mnemonic
I again used the password I frequently share for my validator key.
My mnemonic (for my testnet validator people) I’m just writing down here. It’s:
DELETED SOME WORDS FOR SECURITY prevent napkin master twelve inmate piece shadow update salad release copper drink wing duck local vote visit august beach
And got the response:
Your keys can be found at: /home/ec2-user/eth2deposit-cli-256ea21-linux-amd64/validator_keys
Clicking through a little further, it seems like the idea is that you don’t need to, and maybe are not supposed to, generate the keys on the same machine your going to run the validator on. This make sense and in retrospect I should have gotten it. As I continue to click through the website I’m now being asked to upload my deposit_data file at:
https://pyrmont.launchpad.ethereum.org/en/upload-deposit-data
Ok, so I pulled my deposit file down to my laptop, and uploaded it via the website.
Now for a bit I’m a little more surprised about. Apparently I need to connect with Metamask (or similar) to put my staking ETH in. I was sort of expecting to be given (or generate) a receiving address.
Ok, so I installed metamask, and set up a wallet. And I went ahead and set myself to goelri network.
Then I logged back over to attache to my geth testnet node.
My first try running “./geth attach ipc:./.ethereum/geth.ipc” didn’t work, so I had to find the geth.ipc file.
I went ahead and ran
Find . -name geth.ipc
And got my answer. I was able to attach with:
./geth attach ipc:./.ethereum/goerli/geth.ipc
hmm , now when I run “eth.accounts” I get an empty set. This is disturbing, as I thought I had a key… just looked through my notes and I totally do. I will likely just have to load the keyfile in the worst case scenario. That’s ok, I just don’t feel like dealing with it right now.
ok , lets see if we can get that GoEth off here…
./geth account list
Got back:
INFO [11-08|23:29:05.183] Maximum peer count ETH=50 LES=0 total=50
INFO [11-08|23:29:05.183] Smartcard socket not found, disabling err="stat /run/pcscd/pcscd.comm: no such file or directory"
INFO [11-08|23:29:05.184] Set global gas cap cap=50,000,000
Account #0: {6c1e2aab44774c7d332325df57a1316fe6841a44} keystore:///home/ec2-user/.ethereum/keystore/UTC--2021-11-03T23-49-47.617960797Z--6c1e2aab44774c7d332325df57a1316fe6841a44
Ok, fuck it… I’m just going to request more GoEth instead of trying to recover…
And nevermind I’m switching back to trying to recover because the faucet seems to be tightend up..
Ok, so I chased this around a while, and never really solved it on geth, but I decided to try using metamask and loading the keyfile, which apparently it can do.
I SCPed down the keyfile and tried to do it on the Firefox metamask install that I have going, that seemed to crash out metamask in a soft/UI sort of way, but I have been noticing that a ton of stuff is janky on FF. So I decided to install chrome, install MM on it, and try again there…
Low an behold, success!
So, once again I clicked through:
https://pyrmont.launchpad.ethereum.org/en/upload-deposit-data
Selecting Geth / Teku and this time noticing that the OS you select is supposed to be for the computer you are running, not for the computer you are going to run your node on.
I popped over and noticed that teku seems to have finished synching, which is good
Downloaded the darwin version of eth depositor thing at:
https://github.com/ethereum/eth2.0-deposit-cli/releases/
Went ahead and ran ./deposit new-mnemonic
This is your seed phrase. Write it down and store it safely, it is the ONLY way to retrieve your deposit.
HALF OF PHRASE DELETED FOR SECURITY effort easily bronze check illness
Press any key when you have written down your mnemonic.
Your keys can be found at: /Users/giblfiz/Downloads/eth2deposit-cli-256ea21-darwin-amd64/validator_keys
Continuing to click through the launchpad, seeing what I see. I feel like I don’t sufficiently understand what I am doing with the linked site:
https://ethereum.org/en/eth2/deposit-contract/
I do feel like I understand it well enough to use it for GoEth though,
I went ahead and did the transfer.
Going through the next checklist, I’m noticing this one:
I don’t think I have more than 20 peers, gonna need to figure that out
Ok, now I’m going to copy my validator keys over to the validator server
scp -r validator_keys [email protected]:
And we are going to try to launch the validator:
https://docs.teku.pegasys.tech/en/latest/HowTo/Get-Started/Run-Teku/
Suggested command is:
teku validator-client --network=pyrmont --beacon-node-api-endpoint=http://192.10.10.101:5051 \
--validator-keys=validator/keys:validator/passwords
I looked this up by running ./teku --help | less
--validator-keys=<KEY_DIR>:<PASS_DIR> | <KEY_FILE>:<PASS_FILE>[,<KEY_DIR>:
<PASS_DIR> | <KEY_FILE>:<PASS_FILE>...]...
<KEY_DIR>:<PASS_DIR> will find <KEY_DIR>/**.json,
and expect to find <PASS_DIR>/**.txt.
<KEY_FILE>:<PASS_FILE> will expect that the file
<KEY_FILE> exists, and the file containing the
password for it is <PASS_FILE>.
So it looks like I probably need to create a password file with my validator password in it. This seems strange. I created password.txt with my validator password in it.
I think that since for this runthru I’m _not_ going to be running the validator on a different box from the beacon node, I’m changing the endpoint to localhost.
Lets give this a shot:
teku validator-client --network=pyrmont --beacon-node-api-endpoint=http://127.0.0.1:5051 \
--validator-keys=~/validator_keys/keystore-m_12381_3600_0_0_0-1636487272.json:~/validator_keys/password.txt
Ok, maybe there was a Type-o in that, but it worked when I re-entered it on the command line (copy paste complained about path)
[ec2-user@ip-10-0-0-110 ~]$ ./teku validator-client --network=pyrmont --beacon-node-api-endpoint=http://127.0.0.1:5051 --validator-keys=validator_keys/keystore-m_12381_3600_0_0_0-1636487272.json:validator_keys/password.txt
DEPRECATION WARNING: The '--network=pyrmont' option is deprecated. Use '--network=auto' instead, which fetches network configuration from the beacon node endpoint.
2021-11-09 20:28:09,531 main INFO Configuring logging for destination: console and file
2021-11-09 20:28:09,534 main INFO Logging file location: /home/ec2-user/.local/share/teku/logs/teku-validator.log
2021-11-09 20:28:09,534 main INFO Logging includes events: true
2021-11-09 20:28:09,535 main INFO Logging includes validator duties: true
2021-11-09 20:28:09,535 main INFO Logging includes color: true
2021-11-09 20:28:09,625 main INFO Include P2P warnings set to: false
20:28:09.627 INFO - Teku version: teku/v21.10.1/linux-x86_64/-redhatinc-openjdk64bitservervm-java-11
20:28:09.632 INFO - This software is licensed under the Apache License, Version 2.0 (the "License"); you may not use this software except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0
20:28:09.946 INFO - Storing validator data in: /home/ec2-user/.local/share/teku/validator
20:28:10.069 INFO - Loading 1 validator keys...
20:28:11.639 INFO - Loaded 1 Validators: b331783
20:28:11.846 INFO - Validator *** Successfully connected to beacon chain event stream
20:28:11.889 WARN - Unable to retrieve status for validator b331783.
Later I got :
21:08:55.394 ERROR - Validator *** Error while connecting to beacon node event stream java.net.SocketTimeoutException: timeout (See log file for full stack trace)
Followed by:
21:08:56.499 INFO - Validator *** Successfully connected to beacon chain event stream
Ok
This doesn’t feel like it’s working right… I dug up the logs which were, incidentally, at
~/.local/share/teku/logs
OK, a lot of this got cleared up on the discord:
Marcos97
Pyrmont is deprecated. You'll want to use the Prater testnet
Harry
Ok, fair enough
Adrian Sutton
This tends to happen a bunch of pyrmont because there are so many empty slots now. The validator client expects to receive an event from the beacon node every few slots at worst and reconnects if not because sometimes HTTP streams get disconnected by proxies in a way that doesn't notify the client so you wind up getting no new data forever. We're hoping to be able to add keep alive messages in the relatively near future to fix this.
@Marcos97
Pyrmont is deprecated. You'll want to use the Prater testnet
Harry
Ahh,
That helps a ton.
Harry
20:48:58.196 WARN - Unable to retrieve status for validator b331783.
Adrian Sutton
This one is because the deposit hasn't been added to the beacon chain yet - takes about 16 hours or so from the initial deposit because of the follow distance.
Harry
Fabulous, this is so helpful.
Adrian Sutton
Until that deposit turns up on the beacon chain the validator is unknown to the beacon node and validator client. So initially you can ignore that warning but if you didn't just deposit that warning is a sign that you've loaded the wrong keys (or are on the wrong network or something like that)
Harry
Thanks. I did just do the deposit like an hour before I spun up the validator.
@Adrian Sutton, I'm also typing up my install and boot process as "yet more docs" to put online. Is it ok if I quote you?
Adrian Sutton
You'll definitely want to deposit on prater rather than pyrmont. We're exiting all our pyrmont validators and the network will disappear pretty soon. We'll likely remove pyrmont support from Teku in the 21.10.0 release.
@Adrian Sutton, I'm also typing up my install and boot process as "yet more docs" to put online. Is it ok if I quote you?
Adrian Sutton
Yep certainly.
Harry
I will get it moved for sure.
Does prater also connect to Goerli?
Adrian Sutton
Yep
Harry
le sigh... might I trouble you for 32 GoEth
Adrian Sutton
Sure, what's your address?
Harry
0x6C1e2AaB44774c7d332325dF57a1316Fe6841a44
Adrian Sutton
https://goerli.etherscan.io/tx/0xed6abe0962bedd5f726c0bb6de523470be203bdf22838d12b1366910df5b0d65
Ethereum (ETH) Blockchain Explorer
Goerli Transaction Hash (Txhash) Details | Etherscan
Goerli (GTH) detailed transaction info for txhash 0xed6abe0962bedd5f726c0bb6de523470be203bdf22838d12b1366910df5b0d65. The transaction status, block confirmation, gas fee, Ether (ETH), and token transfer are shown.
Harry
Thank you.
ok, I think I'm going to take a break for now, and when I come back to this try to figure out how to do the "fast beacon sync" thing that I missed the last time
@Adrian Sutton You rock, thank you!
ok , so I guess I’m going to try to do a fast sync now on prater
We are going to try rebuilding the beacon node on prater. To avoid the super slow synching we are going to try using a “weak subjectivity” synch as not really outlined here:
https://docs.teku.consensys.net/en/latest/Concepts/Weak-Subjectivity/
Ok, so I went and signed up at infura.io
And set up a new project teku_prater_1
Putting together:
./teku --network=pyrmont --eth1-endpoint=http://localhost:8545 --metrics-enabled \ --rest-api-enabled --initial-state=https://20hnEaYQHhe2sZefVuOkthiAJQt:[email protected]/eth/v1/debug/beacon/states/finalized --data_path /teku_data/prater
And now it’s time to do the launchpad thing again, only to do it on prater
This is your seed phrase. Write it down and store it safely, it is the ONLY way to retrieve your deposit.
HALF OF PHRASE DELETED FOR SECURITY rely image acid focus engine panda blame dinosaur input identify topic antenna celery
Press any key when you have written down your mnemonic.
Created the new keys, and kicked them up via SCP to folder prater_validator_keys
And fired the teku validator up again with:
./teku validator-client --network=auto --beacon-node-api-endpoint=http://127.0.0.1:5051 --validator-keys=prater_validator_keys/keystore-m_12381_3600_0_0_0-1636487272.json:prater_validator_keys/password.txt
Hmm, got back a
Failed to retrieve network spec from beacon node endpoint 'http://127.0.0.1:5051/'.
Details: Error communicating with Beacon Node API: Failed to connect to /127.0.0.1:5051
It looks like the teku validator isn’t listening on 5051, which netstat confirms.
That has to be either the --initial-state or the --rest-api-docs-enabled
Yep, it was the --rest-api-docs-enabled
Relaunched the beacon with that, and then was able to connect with the validator again no problem.
After waiting until next day and running again I got this:
23:02:59.864 INFO - Validator b9b66c5 status is pending_queued.
Explained over here:
https://kb.beaconcha.in/ethereum-2.0-depositing
Started reading:
https://www.symphonious.net/2021/01/10/exploring-eth2-attestation-rewards-and-validator-performance/
Which lead to:
https://www.attestant.io/posts/defining-attestation-effectiveness/
This is key for “tuning” https://www.symphonious.net/2020/09/08/exploring-eth2-attestation-inclusion/
Ohh… this is helpful:
https://consensys.net/blog/developers/how-to-monitor-your-eth2-validator-and-analyze-your-pl/
Teku has the “--metrics-enabled” flag
Haha, looks like the ease answer is: Beaconcha.in
I poked around a little to find my public key, it was in the “deposit_data” file that got generated when I made the deposit. This is good.
https://prater.beaconcha.in/validator/b9b66c53f72d53af08c0e187cfeb6c663a17612e2d4b70ca8bff009d2eb02e87b5ac8fb2623f39839a45b4e2c8809bde
Regarding rolling profits for tax reasons:
http://eth2.tax is great, https://beaconcha.in/rewards is similar of you want to compare.
From my own thread: https://www.reddit.com/r/ethstaker/comments/qvme4i/tax_accounting_software_for_staking_yields/
I should also reach out and chat with AltcoinXP done
Ok, looks like core of monitoring is prometheus and grafana
I’m going to start with trying to prometheus up
Bouncing over to Teku docs: https://docs.teku.pegasys.tech/en/latest/HowTo/Monitor/Metrics/
Ok that seems to want me to install prometheus on MacOs I’m hoping to keep it on my server.
https://www.fosslinux.com/10398/how-to-install-and-configure-prometheus-on-centos-7.htm
Ok, looks like “selinux” is set to disabled by default on AWS box
Ohh, created a user for prometheus.
Honestly, this is some nice setup instructions. Gets it all configured with a systemctl demon and such. I should dig into this more with TEKU and friends instead of using the sloppy hacky version that I’m doing.
Ok, so I’m sort of wobbling a little bit about if I want to use prometheus on my validator server. On live deployment I am _definitly_ going to have a separate server for the validators, and for the beacon node & geth.
I’m actually waffling at this point between using AWS or standing up two boxes that live in the office. If I go the office route, the appeal is that validator can be entirely inaccessible from the internet. It just needs to be networked over to the beacon node.
Now, that said: It looks like If I put prometheus on it, I will be opening up another port. It also looks like I can do some passible monitoring from the chain itself. I’m not really sure what prometheus is going to be showing me, so I’m not really sure that the extra attack surface is worth the trouble. Maybe it’s worth putting it up only on the beacon/geth server?
Let’s keep installing on test and see where we end up.
Oh fuckmonkeys. So it’s
firewall-cmd --zone=public --add-port=9090/tcp --permanent
Which means that I’m going to need to go faf about with the AWS firewall tools, which I always hate. Particularly as I don’t really understand what I’m going to be opening it up to.
Ok, to try log into EC2 > Security Groups> and add an
Inbound rule for port 9090 on source 0.0.0.0/0
Now I tried visiting my box at:
http://44.238.236.88:9090/graph
And it worked!
Another EC2 firewall patch for:
firewall-cmd --zone=public --add-port=9100/tcp --permanent
In the install instructions, they seem to have placed a specific IP: 10.94.10.209 where I think that there should just be a localhost. I just tried it and it looked like it wasn’t working, trying again with “localhost”.
Hmm, didn’t work great with “localhost” either. I’m getting no targets.
Maybe I use my IP. Hmm, that didn’t work either.
ok , after some faffing about there was a type-o and that needed to be my own IP
ok , back to these docs:
https://docs.teku.pegasys.tech/en/latest/HowTo/Monitor/Metrics/
So I’m pretty sure that I have Teku running with metrics enabled. I think that was on the beacon node.
To specify the host and port on which Prometheus accesses Teku, use the --metrics-interface and --metrics-port options. The default host and port are 127.0.0.1 and 8008
So I’m going to try to add a new prometheus look in:
sudo vim /etc/prometheus/prometheus.yml
That will look like the following:
- job_name: 'teku Beacon'
scrape_interval: 5s
static_configs:
- targets: ['127.0.0.1:8008']
Ok, that seemed to work great!
I’m able to see some stuff here:
For some reason “valoidator_local_validator_count” is showing up as zero. But um, fine I guess.
I’m guessing that it’s because I’m running as a separate process and connected only to the beacon, not the validator.
Ok, I’m going to try moving my validator over to an adjacent box, and leaving my beacon node where it is.
I’m also going to see if I can faucet up some more Eth
Hmm, faucet is a lot more stingy…
anyway , here we go. I spun up a new mini instance to run the validator on and labled it.
Followed my earlier instructions for installing Java and Teku
Now I shut down teku on the Beacon server. I’m going to wait until I see a missed attestation before I launch it on the new on to avoid slashing. (I’m also going to try copying over the Anti-slashing file that I read about: https://docs.teku.pegasys.tech/en/latest/Concepts/Slashing-Protection/
“To protect validators from slashable offenses, Teku stores a record of the most recently signed blocks for each validator in the <data-path>/validator/slashprotection/ directory. One YAML file is stored per validator in the format <validator-pubkey>.yml (with no 0x prefix).”
I think I found it by running:
$ find . -name slashprotection
./.local/share/teku/validator/slashprotection
Ok now grab that, and also push it and the keys up to the new server.
That’s done
Ok, now I’m going to try basically this:
./teku validator-client --network=prater --beacon-node-api-endpoint=http://127.0.0.1:5051 --validator-keys=validator_keys/keystore-m_12381_3600_0_0_0-1636487272.json:validator_keys/password.txt
But I need to fix the beacon endpoint, and make sure that works in AWS , and add the slashing protection.
So I hopped over to AWS and added to the security group access to a 5051, but ONLY for the teku validator box. Hopefully that will work
Ok
./teku slashing-protection
Brings up a import option.
Just gave ./teku slashing-protection import b9b66c53f72d53af08c0e187cfeb6c663a17612e2d4b70ca8bff009d2eb02e87b5ac8fb2623f39839a45b4e2c8809bde.yml
A try, and got “need --from=filename”
Got back:
$ ./teku slashing-protection import --from=b9b66c53f72d53af08c0e187cfeb6c663a17612e2d4b70ca8bff009d2eb02e87b5ac8fb2623f39839a45b4e2c8809bde.yml
Reading slashing protection data from: b9b66c53f72d53af08c0e187cfeb6c663a17612e2d4b70ca8bff009d2eb02e87b5ac8fb2623f39839a45b4e2c8809bde.yml
Json does not appear valid in file b9b66c53f72d53af08c0e187cfeb6c663a17612e2d4b70ca8bff009d2eb02e87b5ac8fb2623f39839a45b4e2c8809bde.yml. Unexpected character ('-' (code 45)) in numeric value: expected digit (0-9) to follow minus sign, for valid numeric value
at [Source: (File); line: 1, column: 3]
So lets try exporting, and then using this process with an exported file
./teku slashing-protection import --from=slashprot_2021_11_23.yml
Reading slashing protection data from: slashprot_2021_11_23.yml
Writing slashing protection data to: /home/ec2-user/.local/share/teku/validator/slashprotection
Importing b9b66c53f72d53af08c0e187cfeb6c663a17612e2d4b70ca8bff009d2eb02e87b5ac8fb2623f39839a45b4e2c8809bde
Updated 1 validator slashing protection records
Ok Looks like that worked. Let’s fire this badboy up!
./teku validator-client --network=prater --beacon-node-api-endpoint=http://44.238.236.88:5051 --validator-keys=validator_keys/keystore-m_12381_3600_0_0_0-1636487272.json:validator_keys/password.txt
Invalid configuration. Could not find the key file (~/validator_keys/keystore-m_12381_3600_0_0_0-1637341982.json).
Ok, why can’t it see the keystore file?
Hmm, odd. Ok, looks like somehow I didn’t get the password file on there, but….
Ah crap, ok I got the wrong validator keys. Well, no shit it’s not working, let’s try again
Ok, fixed all of that, and still no go:
./teku validator-client --validator-keys=prater_validator_keys/keystore-m_12381_3600_0_0_0-1636506792.json:prater_validator_keys/password.txt --beacon-node-api-endpoint=http://44.238.236.88:5051
DEPRECATION WARNING: The '--network=mainnet' option is deprecated. Use '--network=auto' instead, which fetches network configuration from the beacon node endpoint.
2021-11-24 00:37:03,024 main INFO Configuring logging for destination: console and file
2021-11-24 00:37:03,035 main INFO Logging file location: /home/ec2-user/.local/share/teku/logs/teku-validator.log
2021-11-24 00:37:03,036 main INFO Logging includes events: true
2021-11-24 00:37:03,042 main INFO Logging includes validator duties: true
2021-11-24 00:37:03,042 main INFO Logging includes color: true
2021-11-24 00:37:03,275 main INFO Include P2P warnings set to: false
00:37:03.278 INFO - Teku version: teku/v21.10.1/linux-x86_64/-redhatinc-openjdk64bitservervm-java-11
00:37:03.293 INFO - This software is licensed under the Apache License, Version 2.0 (the "License"); you may not use this software except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0
00:37:04.002 INFO - Storing validator data in: /home/ec2-user/.local/share/teku/validator
00:37:04.271 INFO - Loading 1 validator keys...
Teku failed to start: java.lang.RuntimeException: Unable to load validator key files
Just tried the network auto thing, on a lark, and it’s giving:
Failed to retrieve network spec from beacon node endpoint 'http://44.238.236.88:5051/'.
Details: Error communicating with Beacon Node API: connect timed out
Checking for read permission on these files. They don’t have global read, I don’t think that should be the problem, but I opened that up….
Still stalled out, I’m going to call this a day for now, and fire up the old one.
Not sure what’s up with that.
