5 ms·
If readers are curious how to get up-and-running with a (non-mining) full node (ETH1) at home, it's quite simple. This is how I did/do it on my Intel NUC runni
by michaelsbradley 5y ago
If readers are curious how to get up-and-running with a (non-mining) full node (ETH1) at home, it's quite simple.
This is how I did/do it on my Intel NUC running Ubuntu Server 20.04:
1. Download a prebuilt binary from https://geth.ethereum.org/downloads/ https://geth.ethereum.org/downloads/.
2. Unpack it. Optionally make it (or a symlink) available in your PATH.
3. Create a service definition, enable it, and start it:
[Unit]
Description=Go Ethereum
[Service]
Type=simple
WorkingDirectory=/home/user
ExecStartPre=/usr/bin/bash -c "/usr/bin/systemctl set-environment GETH_EXT_IP=$$(/home/user/.local/bin/ext-ip.sh)"
ExecStart=/home/user/.local/bin/geth \
--nat extip:${GETH_EXT_IP} \
--ws
StandardError=append:/home/user/.ethereum/geth.log
PermissionsStartOnly=true
User=user
Group=user
Restart=always
RestartSec=5
[Install]
WantedBy=default.target
The script ~/.local/bin/ext-ip.sh consists of:
#!/usr/bin/env bash
dig TXT +short o-o.myaddr.l.google.com @ns1.google.com | awk -F'"' '{print $2}'
And that's it. geth will start syncing mainnet and will likely finish in under 12 hours (depending on your Internet connection, of course).
Note: the initial sync is intensive in both network and disk IO, you'll need an SSD. Also, running a full node long-term (without pruning) currently eats quite a bit of disk space:
$ du -sh ~/.ethereum/geth
598G /home/user/.ethereum/geth
- nubb 5y agoI’ve found not all ssd can handle a full node. If anyone is considering this just go w the nvme.
- michaelsbradley 5y agoThat's a great point. I went with nvme when building my NUC and don't regret it.
- aaaaaaab 5y agoThat is the price you have to pay to participate in a less secure, more centralized system. In what reality is it OK that you can't run a full node because the SSD cannot keep up? Should it be OK that a large segment of users who could have otherwise ran a full node, thus securing the network further, are unable to participate right out of the gate? enjoy your dogshit.
- tomc1985 5y agoI don't understand, why is spinning metal not good enough? For the large amount of storage required it seems like it would be a good idea.
- vvpan 5y agoSometime in 2017/18 it has been found that one of the biggest bottlenecks for the network were propagation speeds and that those were largely weighed down by disk writes. Thus pretty much the whole network switched to SSDs and things improved tremendously. Some other networks have implemented stateless clients and Ethereum has been working on going in that direction for a while with a lot of effort being dedicated to it this year specifically.
- eminence32 5y agoDoes the node need bulk write speeds? or does it need fast IO ops per second?
- trianglesphere 5y agoIt needs low latency. There is a huge amount of inherently sequential lookups in the state (~9 leveldb lookups per 1 state acess in a smart contract) and you can't store the state in RAM on most consumer hardware.
- jlokier 5y agoIt's read as well as write IOPS and seek time. The Ethereum state database uses hashes as keys and is larger than anyone's reasonable amount of RAM. So most accesses are all over the database in terms of physical location, and it can't be cached in RAM effectively. There is various work to improve this, but the basic architecture does depend on random access storage to a great extent.
- nly 5y agoDoesn't make sense. Most people have faster spinning rust write speeds than they do internet bandwidth. Unless the client is generating a lot of data client side, how can writes ever be a problem? Just buffer appropriately