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

Messaging general #494

Open
wants to merge 15 commits into
base: messaging-base
Choose a base branch
from
Open

Conversation

f-gate
Copy link
Collaborator

@f-gate f-gate commented Mar 6, 2025

This goes over most of the General section of the messaging pallet's tasks.

Losing ones deposit

Previously, in the extrinsics that take a message deposit, there was a possibility that the extrinsic would error before the message is stored and therefore when one tried to removed the message, it did not exist and therefore, the deposit could not be claimed. This has been fixed by moving much of the validation code before taking the deposit and then handling the fallible code after taking deposit more appropriately. (NOTE: this is now irrelevant since transactional is default)

Remove extrinsic

Notably the remove extrinsic has had a makeover so that it can be more comfortably unit tested.
I have moved much of the logic into the impl of Message, encapsulating the logic like this allowed me to cut down the complexity of the tests and the code.
Many tests have been written and cover all bases as far as im concerned.

The extrinsic has also been made transactional this is because we deposit an event at the end of the extrinsic that emits the messages removed, The previous implementation would remove messages without emitting an event which will be a pain for app devs . We could build it so it ignores erroneous messages and emits only the ones that pass but i thought this was a quick fix and i have lots to do thats of higher priority.

MessageStatus

The MessageStatus has been introduced and ive moved away from combination of message status and message type.

Previously a message would be of type IsmpTimedOut now it is an IsmpMessage with the status of TimedOut.
This was done to differentiate between what a message is and what status it is in. I think this will allow more flexibility for messages in the future. The downside is that one must handle all message statuses for a message and the previous version uses Rust's type system to enforce a messages status. This is the change im least confident about.

Storage Deposits

Previously the deposit implementations were scattered around the codebase and there was a trait called CalculateDeposits. Following this code was more difficult than it had to be. I have made deposits.rs to contain all the deposit calculation code, and used a blanket implementation instead of the specific impls of the CalculateDeposits. This has improved readability nicely.
The IsmpByteFee is intended for Offchain storage costs hence it has been replaced with OffchainByteFee.
ByteFee has subsequently been changed to OnChainByteFee.

Other

CallbackT has been renamed to CallbackExecutor for better semantics.
MessageId has been changed to a [u8; 32] from an unsigned integer.

Todo:

  • storage deposit tests
  • defensive programming for deposits

[sc-3066]

@f-gate f-gate requested a review from peterwht March 6, 2025 19:12
@f-gate f-gate marked this pull request as ready for review March 6, 2025 19:14
Copy link
Collaborator

@peterwht peterwht left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice refactor! And thanks for the great PR description.

I haven't reviewed the tests yet.

I've left some comments. I would love some clarity on why a few dispatchables don't rollback and return the error to the contract in case of failure.

type AccountIdOf<T> = <T as frame_system::Config>::AccountId;
type BlockNumberOf<T> = BlockNumberFor<T>;
type BalanceOf<T> = <<T as Config>::Deposit as Inspect<AccountIdOf<T>>>::Balance;
pub type MessageId = u64;
pub type MessageId = [u8; 32];
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason for this change? Seems a little large for the message id.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So that one can pass a 32 byte hash as an id (Blake2/3, sha256)


// Calculate deposit and place on hold.
let deposit = Self::calculate_deposit(
message.calculate_deposit() +
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This message.calculate_deposit() is missing in the newest calculation. Is it no longer needed?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This has been replaced with calculate_message_deposit


#[benchmark]
// x: The number of removals required.
fn remove(x: Linear<1, 255>) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is it possible to use T::MaxRemovals here? (instead of 255)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No but im tempted to increase the limit, what do you think?

}

#[derive(Clone, Debug, Encode, Eq, Decode, MaxEncodedLen, PartialEq, TypeInfo)]
pub enum MessageStatus {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! This feels better and keeps the Message struct a little cleaner. Also makes sense as it's easier to track what the original request was.

@f-gate f-gate requested a review from peterwht March 7, 2025 13:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants