Use a declarative design to tell the ZetaClient how to observe external chains

lumtis commented 4 months ago

Describe the Issue

There is already an issue mention this idea https://github.com/zeta-chain/node/issues/2318 But I'm create a dedicated issue as this might be a larger refactoring out of the scope of the issue above.

This issue can also be focused for EVM chains at first.

The way the observer observes the different types of event for inbound/outbound/outbound reverts should be pretty generic for all.

The idea of this issue is to separate the "what" from the "how", and keeping a list of events to observe in a declarative way.

This issue would simplify adding new events for example in the context of supporting the new smart contract design.

The issue is specific for observation, but a similar design could be thought for the signing part. Separating what to sign and how to sign

Considered Outcome

Keeping on the observer package a map/list of the event with cctx type associated (to initiate the inbound/outbound vote), when then have a method to observer the event.

This example is specifically for the new smart contract design.


var map eventMap {
  "deposit": [DepositCCTXData], // allow to initiate the inbound vote for a deposit to ZetaChain
  "depositAndCall": ...,
  "call": ...,
}

...

func Observer(evmClient, eventMap) {
  // actual logic parsing the events
}

swift1337 commented 2 weeks ago

I'll take this into account when revamping the orchestrator.

Based on my experience, this is not particularly true.

The way the observer observes the different types of events for inbound/outbound/outbound reverts should be pretty generic for all.

Different chains have different flows.

We can't broadcast more than 1 BTC outbound.
We can send as many outbound as we want for EVM.
TON mixes inbounds with outbound due to how tx pagination is implemented in this chain.
Eth allows us to replace tx.
and so on ...

I think that we'd still stick with a custom per-chain approach, but (!) all common operations should go through the same pipeline, i.e. we need to figure out the common denominator and keep chain-specific implementations as thin as possible. Ideally, each chain observer&signer should work with cctx and have a certain "outcome" that would determine whether we should process the next cctx, do a retry, etc...

I also would push back on having an intermediate "inbound event", "outbound event" (link) because it introduces unnecessary intermediate abstraction that IMO should be directly a cctx (also need a revamp).

lumtis commented 2 weeks ago

Would not be a universal object used for all chains but one per specific chain type (in particular EVM)

Example: We integrate native NFT support for EVM chains with new contract interface, the ZetaClient can add support just by adding new entries:

mapping(inboundEventData -> inboundVoteData) for inbounds
mapping(outboundData -> function to call with arguments) for outbounds

zeta-chain / node

Use a declarative design to tell the ZetaClient how to observe external chains #2493