search

zeta-chain / node

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

`zetacore` : clean up finalized cctxs #2781

Open kingpinXD opened 2 weeks ago

kingpinXD commented 2 weeks 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 2 weeks ago

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

lumtis commented 2 weeks 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 2 weeks 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