node: Extend flow cancel by configuring allow-list of chain ID pairs ("pipes") #4229
Conversation
johnsaigle
changed the title
johnsaigle
force-pushed
the
flow-cancel-pipes
branch
from
4303203 to
35e937b
Compare
johnsaigle
requested review from
mdulin2,
pleasew8t,
bruce-riley,
evan-gray and
panoel
as code owners
johnsaigle
force-pushed
the
flow-cancel-pipes
branch
from
54d16d7 to
2c1ba16
Compare
node/pkg/governor/governor_test.go
Outdated
There was a problem hiding this comment.
Could you add a test for the flow_cancel_pipes.go file? Would be good to validate the mainnet list of pipes before deployment ideally, even though we have the runtime checks
There was a problem hiding this comment.
Thanks for adding! I was also thinking that it would be good to check every entry to make sure it's a valid pipe and that there are no duplicate pipes
- Add a concept of "pipes" which consist of a pair of chains - Add field in the Governer that enables flow cancel only for "pipes" which are explicitly enabled - Set the Eth-Sui pipe as the only flow cancel-enabled pair. Sui is the only chain with frequent governor congestion so it is the only one that really needs the Flow Cancel capabilities. Ethereum is the main chain that Sui is interacting with in terms of volume moving in and out of Sui. - Refactor calling sites for flow cancel transfer functions so that all checks are done in one place. (Should help prevent bugs where only one calling site is updated.)
- Add unit tests to ensure that the flow cancel feature works iff valid pipes are configured - Adds unit tests for the pipe type (validity, equality between two pipes) - Modifies pipe.equals() to always return false for invalid pipes
johnsaigle
force-pushed
the
flow-cancel-pipes
branch
from
037c0ad to
a24d86d
Compare
node/pkg/governor/governor.go
Outdated
| gov.logger.Warn("Error when attempting to add a flow cancel transfer", | ||
| zap.Error(err), | ||
| ) | ||
| return false, err |
There was a problem hiding this comment.
Same question for this early return, do we want this? And should the newTransferFromDbTransfer come before the StoreTransfer call?
| if gov.flowCancelEnabled { | ||
| flowCancelTokens = []tokenConfigEntry{ | ||
| {chain: 1, addr: "3b442cb3912157f13a933d0134282d032b5ffecd01a2dbf1b7790608df002ea7", symbol: "USDC", coinGeckoId: "usd-coin", decimals: 6, price: 1.001}, // Addr: 4zMMC9srt5Ri5X14GAgXhaHii3GnPAEERYPJgZJDncDU, Notional: 6780118.197035182 | ||
| } | ||
|
|
||
| flowCancelPipes = []pipe{ | ||
| {first: vaa.ChainIDEthereum, second: vaa.ChainIDSui}, |
There was a problem hiding this comment.
Just a question. Does it make sense to have Sui here when the governor is not enabled for it in the devnet config?
There was a problem hiding this comment.
Probably not, thanks for catching this.
| @@ -118,10 +119,43 @@ type ( | |||
| transfers []transfer | |||
| pending []*pendingEntry | |||
| } | |||
|
|
|||
| // Represents a pair of Governed chains. Ordering is arbitrary. | |||
| pipe struct { | |||
There was a problem hiding this comment.
This use of "pipe" confused me (with io.pipe and os.pipe. Would it make more sense to call this type corridor since you use that term down below (line 135)?
There was a problem hiding this comment.
I was hoping that "pipes" and "flow" would make it easier to understand but I guess not -- agreed that the word pipe is pretty overloaded, and that corridors is probably better.
| pipe := &pipe{emitter, target} | ||
|
|
||
| // Check whether the source and destination chain are in the allow-list for flow cancelling. | ||
| if !gov.pipeCanFlowCancel(pipe) { |
There was a problem hiding this comment.
Since this involves a for loop, would it be cheaper to do this after line 1001?
There was a problem hiding this comment.
The loop iterates over gov.flowCancelPipes which only contains one element now, and I think it's unlikely to grow much beyond that. So I don't think there will be much of a change in performance either way, unless Go has a big performance overhead for for loops that I don't know about.
No description provided.