-
Notifications
You must be signed in to change notification settings - Fork 1
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
refactor: splitting omni-connector into multiple smaller connectors #48
Conversation
Since we can directly set path for a lib file, then there's no need to create a lib file just to import a module
I agree that the word "connector" might not even be suitable anymore. We can think of a different name and rename at some point |
Made an abstraction for init&fin transfer as well
af0a8d9
to
73be26e
Compare
820ad2f
to
3552776
Compare
a6b98eb
to
367043d
Compare
113ff69
to
d0e368d
Compare
#[clap(short, long)] | ||
source_chain_id: u8, | ||
account_id: String, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The names are unclear. Could you add comments here explaining what they mean? Also, maybe use AccountId instead of String to make it clear that this refers specifically to a NEAR account.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you add comments here explaining what they mean?
I believe that's a job for another PR
@olga24912 Almost all issues were already fixed in #54 |
* feat: finished abstraction * feat: included solana into omni abstraction * feat: made solana's fields optional This can be useful if user won't use full potential of bridge-client, but only some methods which don't require all fields like wormhole or keypair * chore: provided a bit more consistency between different bridge clients * chore: addressed some clippy warnings * chore: updated some crates
|
||
EvmDeployToken { | ||
#[clap(short, long)] | ||
source_chain_id: u8, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you add a help explaining what the arguments mean? I’m already getting confused. Also, can we combine the commands with Solana equivalent and handle what needs to be done in the function?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Arguments are used during the cli input. Example:
cr -- testnet omni-connector bind-token-wormhole --source-chain-id '<source-chain-id>' --vaa '<hex-vaa>' --config-file config.json
Source chain id can be found here:
0 => Eth
1 => Near
2 => Sol
3 => Arb
4 => Base
I don't really understand what do you mean by combining the code. I'd rather finish working on cli later, it's not a highest priority right now. I just made sure to refactor code, I wasn't improving it on the cli's part
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean that we need to add help for a command like this:
cargo run -- testnet omni-connector wormhole-bind-token --help
To explain meaning of each arg.
This should be really simple to do—probably just adding a description or something. I’m sure it can be easily googled.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#[clap(short, long)] | ||
source_chain_id: u8, | ||
#[clap(short, long)] | ||
vaa: String, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be great to have the option to use a non-Wormhole prover here. This could be a separate task in a new PR. Could you create an issue for this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
}) | ||
.to_string() | ||
.into_bytes(), | ||
300_000_000_000_000, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
make it const
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Like this a0ae2b8?
146, 2, 127, 83, 201, 149, 246, 138, 221, 29, 111, 186, 167, 150, 196, 102, 219, 89, | ||
69, 115, 114, 185, 116, 6, 233, 154, 114, 222, 142, 167, 206, 157, 39, 177, 221, 224, | ||
86, 146, 61, 226, 206, 55, 2, 119, 12, | ||
]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be great to create a function to calculate this. This can be done in a separate PR, as near_bridge_account might be different for testing purposes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@olga24912 all issues regarding bridge-cli will be fixed later. I've created an issue for this #57 |
I have a few more changes locally, but I decided to create at least a draft PR to get an initial review
TODO:
omni-connector
Probably last one is a task for another PR, since it's getting too big already and it would require to revamp whole bridge-cli as well. My current idea for abstraction is looking like this:
Questions: