zeta-chain / node

ZetaChain’s blockchain node and an observer validator client
https://zetachain.com
MIT License
167 stars 109 forks source link

`zetacore` : clean up finalized cctxs #2781

Open kingpinXD opened 3 months ago

kingpinXD commented 3 months ago

Finalized CCTX can exist in three states OutboundMined : Can be removed Reverted : can be removed Aborted : we support refunding a aborted TX , these should not be removed

Considering the above information, we should remove CCTXs finalized from our state.

We keep track of finalized inbounds separately, so this would not affect the security of the system, making sure already processed cctxs cannot be submitted again. https://github.com/zeta-chain/zeta-node/blob/c3d19297b4d345e9d7ff746f510a0e3e25eb6355/x/crosschain/keeper/msg_server_vote_inbound_tx.go#L121-L124

gartnera commented 3 months ago

We'd need to keep them around long enough for the indexer to see them though right?

lumtis commented 3 months ago

Not sure about this one tbh. CCTXs are the pillar of ZetaChain, would make sense to me to keep indexed and keep a tamperproof and uncensorable way to fetch these through node even if it brings more overhead on state.

Cleaning ballots are different for example, as used more internally in the protocol.

kingpinXD commented 3 months ago

If we just need the information regarding the cctx , we can add as much as we need to an event which is stored as part of the tx result. @gartnera We can use the events for indexing as as well.

Keeping long-lived data as part of events might be beneficial because some nodes can choose not to store it by just setting tx_index to null , or even setting it to psql for richer searching. Keeping it in application storage mandates every node to store it.

With that said , the CCTX data does not seem to be an immediate concern , and can be added to the backlog for now