Adding support for eth chain

[Inkvi]

Eth can't be run within the current setup because there is an inherent assumption of a chain being cosmos-based. To overcome this, I introduce a concept of a virtual chain with subtypes. It might not be the perfect abstraction but that's how we've been thinking about this at Polymer. Let me know what you think of that approach.

Here is the config file I used for polymer version:

chains:
  - name: ethereum
    type: virtual
    subtype: eth
    numValidators: 1
    prysmCtl:
      image: ghcr.io/polymerdao/prysm-prysmctl:v4.0.3-light-client-1
    geth:
      image: ethereum/client-go:v1.10.26
    beaconChain:
      image: ghcr.io/polymerdao/prysm-beacon-chain:v4.0.3-light-client-1
      args:
        - --datadir=/ethereum/consensus/beacon
        - --min-sync-peers=0
        - --no-discovery
        - --interop-genesis-state=/ethereum/consensus/genesis.ssz
        - --interop-eth1data-votes
        - --bootstrap-node=
        - --chain-config-file=/etc/config/config.yml
        - --chain-id=32382
        - --execution-endpoint=http://localhost:8551
        - --accept-terms-of-use
        - --rpc-host=0.0.0.0
        - --grpc-gateway-host=0.0.0.0
        - --suggested-fee-recipient=0x123463a4B065722E99115D6c222f267d9cABb524
        - --jwt-secret=/etc/secrets/jwt.hex
        - --enable-polymer-devnet-mode
    validator:
      image: ghcr.io/polymerdao/prysm-validator:v4.0.3-light-client-1
      args:
        - --beacon-rpc-provider=localhost:4000
        - --datadir=/ethereum/consensus/validator
        - --accept-terms-of-use
        - --interop-num-validators=36
        - --interop-start-index=0
        - --force-clear-db
        - --chain-config-file=/etc/config/config.yml
        - --config-file=/etc/config/config.yml
        - --suggested-fee-recipient=0x0C46c2cAFE097b4f7e1BB868B89e5697eE65f934
        - --enable-polymer-devnet-mode

[Anmol1696]

What is a virtual chain? and what other kinds of chains can be part of virtual chain?
Can we just not call it eth directly?

[Inkvi]

What is a virtual chain? and what other kinds of chains can be part of virtual chain? Can we just not call it eth directly?

In polymer's terminology, a virtual chain is any non-ibc chain that can be represented as an ibc chain.
The reason I don't want to call it eth directly is because as more non-ibc chains added, the bigger if statements will become in the templates. Additionally, I was thinking of adding a cosmos type to what already exists but it looks like a big structural changes and I wasn't sure if you want to go that way.

[Anmol1696]

I think we can do some refactor for this, but this is a good start for getting eth working in Starship. Lets just merge this first and get you unblocked. I can do the refactor as part of backlog.

Only thing needed for this to work is to have a test case for this, so that we are atleast spining this up in as part of the tests. We would have to ignore the actual test cases to run against this. We might also have to change our testing paradigm for this to work, but we can actually make it part of the refactor itself.

[Anmol1696]

Any reasons to use this instead of just empty dir? Are you deploying this somewhere where you were having issues with empty dir?

We would have to change the resource request, or make this part of the config where one can specify the volume, else this template wont be able to run well locally.

[Inkvi]

I am using a volume claim template to allocate disk space so the eth nodes in case of a restart or any issues won't lose any blockchain data they've accumulated/created so far. I am not a k8s expert, let me know if emptyDir can be used in this case.

Also we plan to use starship to run polymer alpha testnet in GKE and I am not sure how emptyDir behaves in a cloud environment.

We would have to change the resource request, or make this part of the config where one can specify the volume, else this template wont be able to run well locally.
Can you explain what is the problem with running well locally?

[Anmol1696]

In cloud environment this makes sense, but not in other environments (if someone wants to spinup eth chains locally). Our goal should be, ability to run this helm chart basically in any environment. Maybe we need a redesign of sorts, so that this helm chart is better used in a cloud setting.

Oh so you are using this helm chart directly for your testnets?

[Anmol1696]

I guess currently we are not able to support multiple nodes for eth. Lets leave a todo here to make sure we are able to make this scalable down the line.

[Inkvi]

Only thing needed for this to work is to have a test case for this, so that we are atleast spining this up in as part of the tests. We would have to ignore the actual test cases to run against this. We might also have to change our testing paradigm for this to work, but we can actually make it part of the refactor itself.

How can I make a test case for this? When I look at the test cases, they are all tailored for a cosmos chain. So I can't really use the existing machinery and probably need to set up a new one even if it's just a stub.

[Anmol1696]

How can I make a test case for this? When I look at the test cases, they are all tailored for a cosmos chain. So I can't really use the existing machinery and probably need to set up a new one even if it's just a stub.

Ok, lets just go ahead with this without tests, but I would need to understand your requirements to be able to refactor this properly. I think we need a way to be able to write tests for new types of chains as well. Redesign to be able to have different kind of chains (cosmos, eth, polkadot etc), would have a set of tests that are specific to them.

Usally we can just use something like helm tests to be able to just spin up the infra without errors. We might just have to comeup with a new testing system ourselves

[Anmol1696]

We can go ahead with this