Minimum Requirements for Ram for Validator and Sentry

Hi most appriciated guidance on what is minimum Ram requirements for a Validator and Node, looked around and did not seem to be noted or i missed.
Most appreciate any guidance.
Shad

hihi :3 have you tried to check this? Join the Cosmos Hub Mainnet | Cosmos Hub

well, you doesn’t need much. For minimum:

1. RAM 4GB
2. Ubuntu server 20 LTS
3. 1TB SSD (a lot of data needs to be saved by a node)

now add cosmwasm

it goes up rather dramatically

What’s the overhead of cosmwasm? AFAICT it runs with RAM, but I don’t know about production recommendation.

Hey Robert I’m sorry that I missed your question. It varies wildly and that’s one of the reasons that I opposed proposal 69. So what I can say is that osmosis has pretty much doubled its memory consumption since CW was enabled on it even though there aren’t any contracts to the best of my knowledge currently deployed on osmosis. I’ve seen this doubling pretty consistently. We also saw it with the recent dig upgrade. Also and I apologize this gets a little bit hand wavy. I did make a post recently however where I posted some screenshots from our actual servers. Spot the CosmWasm enabled chain Research Here is a screenshot of one of our servers: [Screen Shot 2022-05-19 at 7.26.19 PM] Which of these chains uses cosmwasm? how can you tell? Another server, another screenshot: [Screen Shot 2022-05-19 at 8.05.30 PM] Which two chains support cosmwasm? how can you tell? Is there an observable pattern? Please note that these are our relay machines and they buy necessity are much higher capacity than what’s actually necessary to validate. We do have a standardized validation spec, and I can share that with you as well: These machines perform…

Excerpt (1193 of 2065 characters). Read the whole post on the forum ↗

jacobgadikian:

e run in the most restricted configuration possible, so we turn off indexing, we run either from state sync or a snapshot image that has been truncated using state sync, and we turn off every single port other than p2p.

Thanks. What kind of relayers are you talking about? CW doesn’t need extra relayers.

Cw needs differently configured relayers unless doing connection-based relaying. It used to be quite a bit of work but I think that time has passed. Where tokens use the transfer port, CW uses the wasm port.

But I actually wasn’t talking about that.

The restricted configuration is how we run validators.

Our relay machines (we run several for each chain) are configured basically opposite to the validators. To summarize it’s like:

On validators we turn off everything possible.

On relayers (blockchain nodes that we run the actual relay software against), we turn on everything possible.

“Spot the cosmwasm enabled chain” is actual screenshots of the blockchain nodes that Notional uses in relaying

The full relay setup we’re operating is massive, about 30 128gb 16 core machines (ax-101) at hetzner in a docker swarm with minimum 3x replicas per chain because the relayer software does so many queries against it.

Oh, so cosmwasm chain needs special IBC relayers? I thought the relayer are generic and responsible just for transferring IBC packets, without doing any check what’s in there.

Little bit of column A, and a little of column B. If you are configuring the go relayer or hermes on a per-channel basis, then for cw relaying, you’d specify the wasm port instead of the transfer port. iirc, at one point full and clear support for cw relaying only existed in the ts-relayer by confio. When we began to relay wasm (the neta channel on osmosis) the configuration was really complicated. clients → many connections if desired → many channels if desired after wasm grew, connection-based relaying was added to at least the go relayer, but I think hermes, also: ``` 2022-02-04T07:01:38.530597Z DEBUG ThreadId(983) packet_cmd{src_chain=osmosis-1 src_port=transfer src_channel=channel-169 dst_chain=juno-1}:generate{id=XuZl6E7XNm}: /ibc.core.channel.v1.MsgRecvPacket from SendPacketEv(SendPacket - h:1-3073290, seq:5, path:channel-169/transfer->channel-47/wasm.juno1v4887y83d6g28puzvt8cl0f3cdhd3y6y9mpysnsp3k8krdm7l6jqgm0rkn, toh:1-1753037, tos:Timestamp(NoTimestamp))) ``` That above is literally one of the first cosmwasm (I guess the 5th) packets to go between Juno and Osmosis. tl;dr: if you configure on a per-channel basis, then you’ll use wasm as the “channel” and…

Excerpt (1199 of 3905 characters). Read the whole post on the forum ↗