Run proto-all on project

[nullpointer0x00]

Description

This PR is to submit changes after running make proto-all.

closes: #XXXX

---

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

• Targeted PR against correct branch (see CONTRIBUTING.md)
• Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
• Wrote unit and integration tests
• Updated relevant documentation (docs/) or specification (x/<module>/spec/)
• Added relevant godoc comments.
• Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
• Re-reviewed Files changed in the Github PR explorer
• Review Codecov Report in the comment section below once CI passes

Summary by CodeRabbit

• New Features
  • Added CountAuthorization for restricted method execution counts.
  • Introduced UpdateDenomMetadata RPC method for updating denom metadata.
  • Updated MsgRegisterInterchainAccount with new ordering options.
  • Enhanced transfer capabilities with allowed_packet_data in Allocation.
  • Added receive_enabled in Params to manage cross-chain transfers.
  • Expanded channel capabilities with upgrade_sequence, new states, and upgrade_timeout.
  • Introduced new RPC methods and messages for channel and Wasm light client upgrades.
  • Implemented query services for Wasm module management in IBC.

[coderabbitai]

Walkthrough

The recent updates to the protocol files introduce new functionalities and enhancements across various modules, including IBC channel upgrades, WASM light clients, and governance in the Cosmos ecosystem. Key additions include methods for channel and contract management, as well as specific authorizations and parameters to refine and secure transaction processes.

Changes

File Path	Change Summary
.../authz/v1beta1/authz.proto	Added CountAuthorization message for restricted method execution counts.
.../bank/v1beta1/tx.proto	New RPC method UpdateDenomMetadata for updating denom metadata.
.../ibc/.../controller/v1/tx.proto	Updated MsgRegisterInterchainAccount with ordering field.
.../ibc/.../transfer/v1/...	Added fields and messages for transfer controls and authorization.
.../ibc/core/channel/v1/...	Comprehensive updates for channel upgrades, including new messages, RPC methods, and state enums.
.../ibc/lightclients/wasm/v1/...	Introduced messages and services for WASM light clients in IBC, including contract management and queries.

🐇✨
In the realm of code, where data streams flow,
New paths emerge, and fresh winds blow.
Upgrades sail on channels deep,
While WASM light clients silently creep.
Across the cosmos, changes weave—
A tapestry that techies believe.
🌌🚀

---

Recent Review Details

Configuration used: CodeRabbit UI

Commits

Files that changed from the base of the PR and between ee6b992 and 4b585a1.

Files selected for processing (14)

• third_party/proto/cosmos/authz/v1beta1/authz.proto (1 hunks)
• third_party/proto/cosmos/bank/v1beta1/tx.proto (2 hunks)
• third_party/proto/ibc/applications/interchain_accounts/controller/v1/tx.proto (2 hunks)
• third_party/proto/ibc/applications/transfer/v1/authz.proto (1 hunks)
• third_party/proto/ibc/applications/transfer/v1/transfer.proto (1 hunks)
• third_party/proto/ibc/core/channel/v1/channel.proto (4 hunks)
• third_party/proto/ibc/core/channel/v1/genesis.proto (1 hunks)
• third_party/proto/ibc/core/channel/v1/query.proto (4 hunks)
• third_party/proto/ibc/core/channel/v1/tx.proto (7 hunks)
• third_party/proto/ibc/core/channel/v1/upgrade.proto (1 hunks)
• third_party/proto/ibc/lightclients/wasm/v1/genesis.proto (1 hunks)
• third_party/proto/ibc/lightclients/wasm/v1/query.proto (1 hunks)
• third_party/proto/ibc/lightclients/wasm/v1/tx.proto (1 hunks)
• third_party/proto/ibc/lightclients/wasm/v1/wasm.proto (1 hunks)

Additional comments not posted (31)

third_party/proto/ibc/lightclients/wasm/v1/genesis.proto (2)

9-13: The definition of GenesisState with contracts field is clear and aligns with the typical structure of genesis state messages in blockchain protocols. The use of repeated for the contracts field appropriately allows multiple contracts to be initialized at genesis.

---

16-20: The Contract message is well-defined with code_bytes as its only field. This is appropriate for storing the bytecode of wasm contracts. The decision to disable goproto getters (option (gogoproto.goproto_getters) = false;) is a good practice in this context to reduce unnecessary accessor methods, which can simplify the generated Go code.

third_party/proto/ibc/applications/transfer/v1/transfer.proto (1)

28-28: The addition of the receive_enabled field in the Params message is consistent with the description provided in the PR summary. This field is crucial for controlling cross-chain token transfers, enhancing governance capabilities. The field is correctly defined as a boolean, which is appropriate for enable/disable toggles.

third_party/proto/ibc/core/channel/v1/genesis.proto (1)

21-21: The addition of the params field to the GenesisState message is a significant enhancement, allowing for the initialization of channel parameters at genesis. The use of [(gogoproto.nullable) = false] ensures that the params must be provided, which is crucial for ensuring that all necessary configurations are set at the start.

third_party/proto/ibc/applications/transfer/v1/authz.proto (1)

24-24: The addition of the allowed_packet_data field to the Allocation message is a thoughtful update that enhances the security and specificity of IBC transfers. By allowing a list of permissible data keys, this field provides fine-grained control over what packet data can be transferred, which is crucial for maintaining the integrity and security of interchain communications.

third_party/proto/ibc/lightclients/wasm/v1/wasm.proto (4)

10-18: The definition of ClientState with fields for data, checksum, and latest_height is well-structured. The use of [(gogoproto.nullable) = false] for latest_height ensures that this critical piece of information is always provided, which is essential for the correct operation of the light client.

---

20-26: The ConsensusState message is appropriately defined with a single data field to store the consensus state of the wasm light client. The simplicity of this message is suitable given its specific purpose in the IBC architecture.

---

28-33: The ClientMessage message is correctly structured to handle either headers or misbehaviour reports. This flexibility is important for the robustness of the light client operation within the IBC framework.

---

35-43: The deprecation of the Checksums message in favor of a more scalable storage solution is a prudent decision. It's important to note the deprecation to avoid future use of this message, which aligns with best practices in maintaining clean and efficient codebases.

third_party/proto/ibc/lightclients/wasm/v1/query.proto (2)

9-19: The Query service definition with methods for retrieving checksums and wasm code is well-structured and follows standard practices for defining gRPC services in protobuf. The use of HTTP annotations for REST compatibility is a good practice, enhancing the accessibility of these methods.

---

22-35: The request and response messages for the Checksums and Code RPC methods are correctly defined with necessary fields for pagination and data retrieval. The inclusion of pagination in both requests and responses is crucial for handling potentially large datasets efficiently.

third_party/proto/ibc/core/channel/v1/upgrade.proto (3)

10-21: The Upgrade message is well-defined with fields for upgrade fields, timeout, and next sequence send. This structure provides all necessary information for handling channel upgrades, including timeout management and sequence tracking, which are critical for ensuring the reliability and consistency of channel operations.

---

23-31: The UpgradeFields message is appropriately structured to allow modifications to channel properties during an upgrade. The inclusion of fields for ordering, connection hops, and version provides flexibility in managing channel configurations during upgrades.

---

33-43: The ErrorReceipt message provides a robust mechanism for handling errors during channel upgrade attempts. Including both the sequence and a detailed error message allows for better diagnostics and recovery from upgrade failures.

third_party/proto/ibc/lightclients/wasm/v1/tx.proto (4)

8-20: The Msg service definition with methods for storing code, removing checksums, and migrating contracts is well-structured and follows standard practices for defining gRPC services in protobuf. The use of the cosmos.msg.v1.service option is appropriate for ensuring compatibility with the Cosmos SDK's message handling.

---

22-30: The MsgStoreCode message is correctly defined with fields for the signer and wasm byte code. This structure allows for secure and verifiable storage of wasm contracts, which is essential for the integrity of light client operations.

---

38-46: The MsgRemoveChecksum message provides a secure method for removing code checksums from storage. Including fields for the signer and checksum ensures that only authorized users can perform this operation, which is crucial for maintaining the security of the system.

---

51-63: The MsgMigrateContract message is well-defined with fields for the signer, client id, new checksum, and migration message. This structure provides all necessary information for securely and effectively migrating wasm contracts, which is important for managing upgrades and modifications to light client contracts.

third_party/proto/cosmos/authz/v1beta1/authz.proto (1)

24-35: The new CountAuthorization message is well-defined and follows protobuf best practices. The use of cosmos_proto.implements_interface ensures it adheres to the expected interface, and the fields are appropriately typed and named.

third_party/proto/ibc/applications/interchain_accounts/controller/v1/tx.proto (1)

31-34: The addition of the ordering field in MsgRegisterInterchainAccount is correctly implemented. It uses the appropriate type ibc.core.channel.v1.Order and is positioned logically in the message structure.

third_party/proto/cosmos/bank/v1beta1/tx.proto (1)

125-143: > 📝 NOTE

This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [37-143]

The new RPC method UpdateDenomMetadata and its corresponding message types MsgUpdateDenomMetadata and MsgUpdateDenomMetadataResponse are correctly defined. The method is clearly documented, and the message types are well-structured with appropriate fields and options.

third_party/proto/ibc/core/channel/v1/channel.proto (3)

24-32: > 📝 NOTE

This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [27-54]

The addition of the upgrade_sequence field to both Channel and IdentifiedChannel messages is correctly implemented. The field is well-documented, and its purpose is clear. It uses the appropriate data type uint64.

---

74-77: The new states STATE_FLUSHING and STATE_FLUSHCOMPLETE in the State enum are appropriately added to handle specific scenarios during channel upgrades. The names are descriptive, and the implementation follows protobuf best practices.

---

183-187: The new Params message, including the upgrade_timeout field, is correctly defined. The field uses the Timeout message type, ensuring consistency and clarity in how timeouts are specified for channel upgrades.

third_party/proto/ibc/core/channel/v1/query.proto (1)

417-459: > 📝 NOTE

This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [109-456]

The new RPC methods UpgradeError, Upgrade, and ChannelParams and their corresponding request and response message types are correctly defined. Each method is well-documented, and the message types are structured appropriately with clear fields and options.

third_party/proto/ibc/core/channel/v1/tx.proto (6)

48-73: Ensure that the newly added RPC methods for channel upgrades and other operations are properly documented. Adding comments explaining the purpose and usage of these methods can greatly improve maintainability and clarity for other developers.

---

139-141: Clarify the warning comment regarding channel upgrades. It's crucial to explain why initiating an upgrade in the same block as executing this message could cause issues, possibly leading to a better understanding and fewer errors in implementation.

---

199-204: The addition of counterparty_upgrade_sequence in MsgChannelCloseConfirm is a significant change. Ensure that all systems interacting with this message type are updated to handle this new field to avoid integration issues.

---

256-262: The addition of counterparty_upgrade_sequence in MsgTimeoutOnClose should be accompanied by validation logic to ensure that the sequence numbers are correctly managed and do not lead to state inconsistencies.

---

292-312: The MsgChannelUpgradeInit message type includes critical fields for channel upgrades. It's important to ensure that the fields are used correctly in the system and that there are adequate tests covering various scenarios of channel upgrades.

---

435-447: The MsgUpdateParams message type allows updating channel parameters. It is crucial to ensure that the authority validation is robust and prevents unauthorized modifications, which could lead to security vulnerabilities.

---

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

Share

• X
• Mastodon
• Reddit
• LinkedIn

Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai generate interesting stats about this repository and render them as a table.
  • @coderabbitai show all the console.log statements in this repository.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (invoked as PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger a review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai help to get help.

Additionally, you can add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

CodeRabbit Configration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[coderabbitai]

Actionable comments posted: 1