Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add level-method to represent CCTX state transition #1802

Closed
Tracked by #1799
lumtis opened this issue Feb 23, 2024 · 2 comments
Closed
Tracked by #1799

Add level-method to represent CCTX state transition #1802

lumtis opened this issue Feb 23, 2024 · 2 comments
Assignees
Labels
code-quality Code quality improvement m:crosschain

Comments

@lumtis
Copy link
Member

lumtis commented Feb 23, 2024

This is a preliminary task in preparation of #1800 and #1801, this can also be directly implemented in one of the PR above.

We have currently directly manipulate with the CCTX object in the voteInbound/voteOutbound logic when adding for example adding new outbound parameter for regular outbound or revert. We should break down the general state transition of CCTX in small low level method that can be easily tested and reused.

These methods should be ideally stateless, only interacting with the CCTX object passed as argument, for reliable testing (in the types package)

We should remove the CreateNewCCTX currently in the keeper package

Example of methods:

func InitializeCCTX(inboundParameter) CCTX
func (cctx CCTX) AddOutbound(outboundParameter) CCTX
func (cctx CCTX) AddRevertOutbound(outboundParameter) CCTX
func (cctx CCTX) Abort(outboundParameter) CCTX

The logic can also be simplified in evm-hook.go when creating new CCTX upon observed events on ZetaChain.
Right now we call we create an artificial MsgVoteOnObservedInboundTx message by calling NewMsgVoteOnObservedInboundTx to initialize the inbound, which is very dirty and confusing.

@lumtis
Copy link
Member Author

lumtis commented Mar 4, 2024

@kingpinXD did you start working on #1800 and #1801?
I think exploring this refactoring first might make more sense

@lumtis
Copy link
Member Author

lumtis commented Apr 2, 2024

Closing as resolved #1853

@lumtis lumtis closed this as completed Apr 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
code-quality Code quality improvement m:crosschain
Projects
None yet
Development

No branches or pull requests

2 participants