Consensus clients for Ethereum

quakerdoomer

quakerdoomer

Hello does anyone know if there are any consensus clients for Ethereum available a pkg?
I tried the following:

Lighthouse, although in rust, is uncompilable due to lack of support for FreeBSD OS - hardcoded limitations and checks.
prysm just goes dumb and says nothing when I try the beacon mode.

lodestar is typescript and takes a lot of disk space - not tested and java based clients (teku) are not something anyone should run for security reasons. I still downloaded it but do not wish to install java.
I have not tried Nimbus - don't even know that lang.

Does anyone have any experience here running any consensus clients for ethereum?
 
git clone https://github.com/sigp/lighthouse.git

cd lighthouse

If you do not like git, you may directly download the zip : https://github.com/sigp/siren/archive/refs/heads/stable.zip

unzip it and then pleae try from inide that directory:


cargo build --release

I am getting compiling errors at different places - mainly non-deterministic in nature.
I read somewhere to kep a lower -j , so I tried that but earlier openssl was not getting compiled, now that works but something else fails.



I have already tried compiling nimbus and Prysm. They seem to be more difficult to tame.
I even went ahead and tried teku - using openjdk but it said some BLS native library is absent.
My last option would be Lodestar.

Can someone please try compiling lighthouse using rust?
 
yes, lighthouse seems to use cmake in the toolchain, here is an example
Code: 
error: failed to run custom build command for `leveldb-sys v2.0.9`

Caused by:
  process didn't exit successfully: `/zs/tingo/personal/projects/2024/rust/ethereum/lighthouse/target/release/build/leveldb-sys-4e961a5cd6a908bb/build-script-build` (exit status: 101)
  --- stdout
  [build] Started
  [snappy] Building
  CMAKE_TOOLCHAIN_FILE_x86_64-unknown-freebsd = None
  CMAKE_TOOLCHAIN_FILE_x86_64_unknown_freebsd = None
  HOST_CMAKE_TOOLCHAIN_FILE = None
  CMAKE_TOOLCHAIN_FILE = None
  CMAKE_GENERATOR_x86_64-unknown-freebsd = None
  CMAKE_GENERATOR_x86_64_unknown_freebsd = None
  HOST_CMAKE_GENERATOR = None
  CMAKE_GENERATOR = None
  CMAKE_PREFIX_PATH_x86_64-unknown-freebsd = None
  CMAKE_PREFIX_PATH_x86_64_unknown_freebsd = None
  HOST_CMAKE_PREFIX_PATH = None
  CMAKE_PREFIX_PATH = None
  CMAKE_x86_64-unknown-freebsd = None
  CMAKE_x86_64_unknown_freebsd = None
  HOST_CMAKE = None
  CMAKE = None
this is not the rust way of doing things.
 
I asked an LLM to list some more. Will try these now:

Trinity - developed by the Ethereum Foundation (https://github.com/ethereum/trinity)
Artemis - developed by PegaSys (https://artemis.pegasys.tech/

Eth2-cl-box - developed by the Ethereum Foundation (https://github.com/ethereum/eth2.0-cl-box)
Schlesi - developed by ChainSafe Systems (https://github.com/ChainSafe/schlesi)
Cortex - developed by the Ethereum Foundation (https://github.com/ethereum/cortex)
Aleth - developed by the Ethereum Foundation (https://github.com/ethereum/aleth)
Slasher - developed by the Ethereum Foundation (https://github.com/ethereum/slasher)

-------------
Just checked the above.. all old and obsolete. :(
 
quakerdoomer said:
Prysm is a consensus client. Sadly broken as of now.
Click to expand...
So, that port is broken because it uses an older version of Go which isn't available anymore, and there's newer versions of that port available. Try taking a copy of that Makefile into a custom directory, and editing it to see if a newer version of that port will compile.

Or compile it whichever way you can, and let others know if that works. Maybe someone can use that to see if they can make that into a Makefile.

Be sure, you try to compile a version which relies on the version of Go available in FreeBSD. psearch -c lang go: lang/go120.
 
Had tried prysm it earlier. Tried again.

go build -o=../beacon-chain ./cmd/beacon-chain

go: downloading github.com/mmcloughlin/addchain v0.4.0 # github.com/prysmaticlabs/prysm/v5/crypto/bls crypto/bls/bls.go:19:14: undefined: blst.SecretKeyFromBytes crypto/bls/bls.go:24:14: undefined: blst.PublicKeyFromBytes crypto/bls/bls.go:31:14: undefined: blst.SignatureFromBytesNoValidation crypto/bls/bls.go:36:14: undefined: blst.SignatureFromBytes crypto/bls/bls.go:41:14: undefined: blst.MultipleSignaturesFromBytes crypto/bls/bls.go:46:14: undefined: blst.AggregatePublicKeys crypto/bls/bls.go:51:14: undefined: blst.AggregateMultiplePubkeys crypto/bls/bls.go:56:14: undefined: blst.AggregateSignatures crypto/bls/bls.go:61:14: undefined: blst.AggregateCompressedSignatures crypto/bls/bls.go:66:14: undefined: blst.VerifySignature crypto/bls/bls.go:66:14: too many errors

I had tried teku (java) as well and it gave me similar error regarding BLS.
 
I realized that the message about unavailability of a consensus client is a warning, not an error. It is not essential if one just wants to test if a sync can be performed. I don't need to stake or validate anything. Although that does not solve the above issue, it is not a problem for me anymore, actually never was.

Correction:
I confirmed and a beacon IS NOW needed to run geth and sync it :(
 
Last edited:
I was trying to run lighthouse - a rust-based ethereum consensus client which needs to listen onto some ports and it cannot open up ports to listen:
Code: 
CRIT Unable to listen on libp2p address      listen_multiaddr: /ip4/0.0.0.0/udp/9001/quic-v1, error: Other(Custom { kind: Other, error: Other(Right(Custom { kind: Other, error: Transport(Custom { kind: Other, error: Right(Io(Os { code: 92, kind: Uncategorized, message: "Protocol not available" })) }) })) }), service: libp2p
Mar 17 12:18:01.270 CRIT Failed to start beacon node             reason: Failed to start network: Error(Libp2p(Msg("Libp2p was unable to listen on the given listen address.")),

I looked up the error and it might have something to do with BSD in general , since even MacOS this has been observed:
github.com

Restarting Lighthouse sometimes stalls due to in-use sockets · Issue #2254 · sigp/lighthouse

Description Some users have reported that Lighthouse cannot be restarted quickly due to TCP ports not being freed immediately after process exit. After a bit of research, it seems that this is a co...
github.com github.com
 
""Protocol not available"" seems to be the actual errno.

It would be useful to know what protocol it tried to invoke how.

Or it is a generic message and the error is something else entirely, such as port busy. Can you request a dfferent port number? Anything in `dmesg`?
 
Umm.. dmesg.. from Ubuntu compat?
RPC calls over HTTP were expected. Tried other ports, same issue. Tested both these software on windows, same command-line, worked fine.
 
You must log in or register to reply here.
Back
Top