-
Notifications
You must be signed in to change notification settings - Fork 115
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
Runtime: Argo Bridge #5155
Runtime: Argo Bridge #5155
Conversation
abd17d2
to
37f3d91
Compare
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 pallet looks solid, the only issues that I have found are:
- remote chain address formatting : 12 most significant bytes should be zero IMHO
- If you can provide a case where the operator account is
None
The tests needs some touching
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 pallet looks solid, the only issues that I have found are:
- remote chain address formatting : 12 most significant bytes should be zero IMHO
- If you can provide a case where the operator account is
None
The tests needs some touching, especially in the happy path assertions (especially on event production)
Also: wouldn't it be easier for you to have multiple commits 😅 , instead of a single huge one ?
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.
Ignore this, I accidentally re requested a review
@@ -0,0 +1,21 @@ | |||
use node_runtime::{argo_bridge::types::BridgeStatus, ArgoBridgeConfig}; | |||
|
|||
pub fn production_config() -> ArgoBridgeConfig { |
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 also think that you can set the mint allowance storage variable to be 0
by default since I don't think any other initial value is plausible
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.
Did another quick review round
pub PauserAccounts get(fn pauser_accounts): BoundedVec<T::AccountId, T::MaxPauserAccounts>; | ||
|
||
/// Number of tokens that the bridge pallet is able to mint | ||
pub MintAllowance get(fn mint_allowance) config(): BalanceOf<T>; |
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 believe you can set default value of this to 0
if I correctly understood the bridging accounting logic, as there shouldn't be any other possible initial value
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.
in the tests is handy to be able to set a value for the mint allowance in the config
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.
or were you really just suggesting a default value and not removing it from the genesis config?
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 storage value mint_allowance is increased during Outbound transfer and decreased during Inbound transfer and it represent the total amount of JOY we have outside of the Joystream mainnet network.
If so my observation was: since the only plausible initial value is zero, we can set the default value when declearing the storage variable inside the decl_storage macro instead of manually setting the value in the chainspec config. (Even though I remember with confidence that in case a storage variable is not initialised it will be set to the fault value when accessed for the first time, so 0 for mint allowance which in production will be a u128)
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.
this is a minor comment however, I am fine even with the existing solution
Thanks for the review 👍 |
All my previous comments have been addressed. So for now LGTM |
@ignazio-bovo and @kdembler I have added the benchmark tests please take a look.
|
@ignazio-bovo @freakstatic I think the discussion on storage initialization is still not resolved. @ignazio-bovo could you expand on what you had in mind? |
I think you need to add the argo bridge pallet to the diff --git a/runtime/src/runtime_api.rs b/runtime/src/runtime_api.rs
index 8d3a06316a..c57e968e51 100644
--- a/runtime/src/runtime_api.rs
+++ b/runtime/src/runtime_api.rs
@@ -127,6 +127,7 @@ mod benches {
[content, Content]
[project_token, ProjectToken]
[pallet_proxy, Proxy]
+ [argo_bridge, ArgoBridge]
);
} |
thanks very much 🙏 |
@ignazio-bovo and @kdembler can you please review the benchmarking tests? |
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.
Benchmarks looks ok in terms of worst case scenario accounting
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.
There are some errors that needs to be fixed (see CI).
You can test the benchmarking code with cargo test -p "pallet-argo-bridge" --features "runtime-benchmarks" (you can also use clippy with the same feature enabled)
I opened a PR with fixes for clippy issues that we should merge into this PR: freakstatic#2 I have also opened a new PR based on this to add a revert extrinsic: #5158 Please check |
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.
LGTM pending benchmark&weights approval from @ignazio-bovo
We also need to add overflow protection in some extrinsics but will do in a subsequent PR
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.
LGTM, the mac osx checks will be fixed in my PR here: #5157
Still missing the benchmark tests