Content pfp
Content
@
0 reply
0 recast
0 reaction

vrypan |--o--| pfp
vrypan |--o--|
@vrypan.eth
Can a hub use Helios for its Eth/OP RPC? https://github.com/a16z/helios @sanjay?
2 replies
0 recast
6 reactions

polymutex pfp
polymutex
@polymutex.eth
It should be feasible, as it can listen on a port and act as a verifying proxy. So it would just be a matter of running it that way, and pointing the Hub at it as the chain RPC endpoint. Haven't tried it in practice though.
1 reply
0 recast
1 reaction

vrypan |--o--| pfp
vrypan |--o--|
@vrypan.eth
I couldn't find the min hw specs to run Helios. Do you know what they are?
1 reply
0 recast
1 reaction

polymutex pfp
polymutex
@polymutex.eth
It's pretty modest. You can run light clients in your browser against Ethereum L1 + OP Mainnet + Base all at once in a tab using the following page. My browser measures it as using ~300 MiB for all three networks combined. Probably more efficient if run headlessly. https://helios.a16zcrypto.com/demo
1 reply
0 recast
0 reaction

vrypan |--o--| pfp
vrypan |--o--|
@vrypan.eth
Once it's synced, does it still need a third party RPC? So, it's not replacing the RPC, just provides a trusted one?
1 reply
0 recast
1 reaction

polymutex pfp
polymutex
@polymutex.eth
Correct, it still needs a persistent connection to the remote RPC provider to keep up with the chain head, or to fetch chain data when requested by the client, etc. The only thing it does is to turn an untrusted RPC endpoint into a trusted one. cc @ncitron.eth
1 reply
0 recast
1 reaction

vrypan |--o--| pfp
vrypan |--o--|
@vrypan.eth
Do you know what's the lightest possible version of a stand alone Eth client, that does not need to post transactions to the chain?
1 reply
0 recast
1 reaction

polymutex pfp
polymutex
@polymutex.eth
I believe light clients are it, so long as you want the be able to trust the RPC endpoint. Helios is the only mature implementation I know of, and for least overhead you can link against it as a library directly in your codebase. Examples here: https://github.com/a16z/helios/tree/master/examples Also noteworthy is the Portal Network. This is a separate effort from the EF to create "light nodes" which act as a sort of CDN layer for serving data to light clients. Probably heavier than light clients (haven't tried), but still meant to be relatively lightweight. https://ethereum.org/en/developers/docs/networking-layer/portal-network/ Another very lightweight but not cryptographically secure technique I've seen some client libraries do is to let the user specify a set of RPC endpoints, and to randomly sample responses from multiple of them as a way to verify the consistency of the answer across multiple sources. Lighter than a real light client, but assumes a honest minority among the configured RPC providers.
1 reply
0 recast
0 reaction

vrypan |--o--| pfp
vrypan |--o--|
@vrypan.eth
My goal is to run my own hub, without depending on external RPCs. I think that trust is not such a big issue in case of Farcaster, because a malicious tx will cause rippling effects when syncing with the rest of the network (unless of course everyone received it) and it can't stay hidden.
1 reply
0 recast
1 reaction

polymutex pfp
polymutex
@polymutex.eth
Then I'm afraid the only option is to run a full Ethereum L1 node, and an OP stack client on top of that that can reconstruct the OP Mainnet state from the L1 chain data. That means running at least op-node and op-geth; definitely resource-intensive. It is out of my depth at this point but here's a link to the docs on the OP stack components. https://docs.optimism.io/builders/chain-operators/architecture
0 reply
0 recast
1 reaction