fix(events): align event processing with smart contract changes

[ezreal1997]

align event processing with smart contract changes

issue: closes #393

[edisonz0718]

I think we need to make this backward compatible since it's tricky to upgrade CL and contract together.

[jdubpark]

I think we need to make this backward compatible since it's tricky to upgrade CL and contract together.

I agree, it requires precise timing of smart contract upgrade to follow the updated CL.

Alternatively we could do this:

1. Update the smart contract to emit two logs in each operator function, ie. emit AddOperator & SetOperator and RemoveOperator & UnsetOperator.
2. Update the CL code.
3. Nodes that have not upgraded will pick old logs (Add/Remove) and nodes that have upgraded will pick new logs (Set/Unset).
4. At some point, update the smart contract to remove the AddOperator and RemoveOperator event logs. (This is the backward-incompatible step but we have both CL and contracts ready)

[ezreal1997]

I think we need to make this backward compatible since it's tricky to upgrade CL and contract together.

Anyway, we need to notify the community that we will deprecate addOperator and removeOperator func, so I prefer a simpler way:

1. Include this change in the next hardfork.
2. Then we notify the community 1) old contract funcs to be deprecated and occurrence time is the next hardfork time, 2) new contract funcs to be supported and the occurrence time is xxx blocks/hours right after hardfork.

cc @edisonz0718 @jdubpark

[edisonz0718]

I think we need to make this backward compatible since it's tricky to upgrade CL and contract together.

Anyway, we need to notify the community that we will deprecate addOperator and removeOperator func, so I prefer a simpler way:

1. Include this change in the next hardfork.
2. Then we notify the community 1) old contract funcs to be deprecated and occurrence time is the next hardfork time, 2) new contract funcs to be supported and the occurrence time is xxx blocks/hours right after hardfork.

cc @edisonz0718 @jdubpark

This will cause a service disruption if someone wants to use operator functions between CL hardfork and contract upgrade. I think a simpler approach is to just make CL backward compatible. Add the new operator functions instead of replacing. So that both types of event can be processed.

[ezreal1997]

I think we need to make this backward compatible since it's tricky to upgrade CL and contract together.

Anyway, we need to notify the community that we will deprecate addOperator and removeOperator func, so I prefer a simpler way:

1. Include this change in the next hardfork.
2. Then we notify the community 1) old contract funcs to be deprecated and occurrence time is the next hardfork time, 2) new contract funcs to be supported and the occurrence time is xxx blocks/hours right after hardfork.

cc @edisonz0718 @jdubpark

This will cause a service disruption if someone wants to use operator functions between CL hardfork and contract upgrade. I think a simpler approach is to just make CL backward compatible. Add the new operator functions instead of replacing. So that both types of event can be processed.

If we plan to keep both operator functions until Odyssey deprecated, that makes sense. @Ramarti plz add the old operator func back.

[0xHansLee]

Yeah, I also agree to @edisonz0718. We can make CL backward compatible for the contract upgrade for now, and deprecate the old events after upgrading the contract.

[ezreal1997]

My point is if we do not keep old operator functions, it's already a non-compatible change on user side, so it's equivalent if CL is backward compatible or not.

If we want to make backward compatible, we need following steps:

1. upgrade CL to handler both old and new events
2. upgrade contract to keep both old and new operator functions
3. ... one month for eco projects to make the change ...
4. upgrade the contract to remove the old operator functions
5. upgrade CL to remove the processing logic of old events

[limengformal]

As discussed with @edisonz0718 , we will not fix #393 in odyssey since it is a name change. We will apply the fix in mainnet version.