feat: update-erc20-class

[enitrat]

Description

Updates the ERC20 class entrypoints with snake_case equivalents.

Source cairo

// SPDX-License-Identifier: MIT
// OpenZeppelin Contracts for Cairo v0.6.0

%lang starknet

from starkware.cairo.common.cairo_builtins import HashBuiltin
from starkware.cairo.common.uint256 import Uint256

from openzeppelin.token.erc20.library import ERC20

@constructor
func constructor{syscall_ptr: felt*, pedersen_ptr: HashBuiltin*, range_check_ptr}(
    name: felt, symbol: felt, decimals: felt, initial_supply: Uint256, recipient: felt, owner: felt
) {
    ERC20.initializer(name, symbol, decimals);
    ERC20._mint(recipient, initial_supply);
    return ();
}

//
// Getters
//

@view
func name{syscall_ptr: felt*, pedersen_ptr: HashBuiltin*, range_check_ptr}() -> (name: felt) {
    return ERC20.name();
}

@view
func symbol{syscall_ptr: felt*, pedersen_ptr: HashBuiltin*, range_check_ptr}() -> (symbol: felt) {
    return ERC20.symbol();
}

@view
func totalSupply{syscall_ptr: felt*, pedersen_ptr: HashBuiltin*, range_check_ptr}() -> (
    totalSupply: Uint256
) {
    let (totalSupply: Uint256) = ERC20.total_supply();
    return (totalSupply=totalSupply);
}

@view
func total_supply{syscall_ptr: felt*, pedersen_ptr: HashBuiltin*, range_check_ptr}() -> (
    total_supply: Uint256
) {
    return ERC20.total_supply();
}

@view
func decimals{syscall_ptr: felt*, pedersen_ptr: HashBuiltin*, range_check_ptr}() -> (
    decimals: felt
) {
    return ERC20.decimals();
}

@view
func balanceOf{syscall_ptr: felt*, pedersen_ptr: HashBuiltin*, range_check_ptr}(account: felt) -> (
    balance: Uint256
) {
    return ERC20.balance_of(account);
}

@view
func balance_of{syscall_ptr: felt*, pedersen_ptr: HashBuiltin*, range_check_ptr}(account: felt) -> (
    balance: Uint256
) {
    return ERC20.balance_of(account);
}

@view
func allowance{syscall_ptr: felt*, pedersen_ptr: HashBuiltin*, range_check_ptr}(
    owner: felt, spender: felt
) -> (remaining: Uint256) {
    return ERC20.allowance(owner, spender);
}


//
// Externals
//

@external
func transfer{syscall_ptr: felt*, pedersen_ptr: HashBuiltin*, range_check_ptr}(
    recipient: felt, amount: Uint256
) -> (success: felt) {
    return ERC20.transfer(recipient, amount);
}

@external
func transferFrom{syscall_ptr: felt*, pedersen_ptr: HashBuiltin*, range_check_ptr}(
    sender: felt, recipient: felt, amount: Uint256
) -> (success: felt) {
    return ERC20.transfer_from(sender, recipient, amount);
}

@external
func transfer_from{syscall_ptr: felt*, pedersen_ptr: HashBuiltin*, range_check_ptr}(
    sender: felt, recipient: felt, amount: Uint256
) -> (success: felt) {
    return ERC20.transfer_from(sender, recipient, amount);
}

@external
func approve{syscall_ptr: felt*, pedersen_ptr: HashBuiltin*, range_check_ptr}(
    spender: felt, amount: Uint256
) -> (success: felt) {
    return ERC20.approve(spender, amount);
}

@external
func increaseAllowance{syscall_ptr: felt*, pedersen_ptr: HashBuiltin*, range_check_ptr}(
    spender: felt, added_value: Uint256
) -> (success: felt) {
    return ERC20.increase_allowance(spender, added_value);
}

@external
func increase_allowance{syscall_ptr: felt*, pedersen_ptr: HashBuiltin*, range_check_ptr}(
    spender: felt, added_value: Uint256
) -> (success: felt) {
    return ERC20.increase_allowance(spender, added_value);
}

@external
func decreaseAllowance{syscall_ptr: felt*, pedersen_ptr: HashBuiltin*, range_check_ptr}(
    spender: felt, subtracted_value: Uint256
) -> (success: felt) {
    return ERC20.decrease_allowance(spender, subtracted_value);
}

@external
func decrease_allowance{syscall_ptr: felt*, pedersen_ptr: HashBuiltin*, range_check_ptr}(
    spender: felt, subtracted_value: Uint256
) -> (success: felt) {
    return ERC20.decrease_allowance(spender, subtracted_value);
}

Related issue

Tests

• Yes
• No, because they aren't needed
• No, because I need help

Added to documentation?

• README.md
• Dojo Book
• No documentation needed

Checklist

• I've formatted my code (scripts/prettier.sh, scripts/rust_fmt.sh, scripts/cairo_fmt.sh)
• I've linted my code (scripts/clippy.sh, scripts/docs.sh)
• I've commented my code
• I've requested a review after addressing the comments

Summary by CodeRabbit

• New Features

  • Introduced an ERC20 token contract with essential functionalities such as transfer, allowance management, and token properties retrieval.
  • Added support for alternative naming conventions for compatibility with different preferences.

• Bug Fixes

  • Updated transaction count assertions to reflect accurate behavior after executing blocks.
  • Adjusted constructor arguments for deployed contracts to ensure correct address formats.

• Documentation

  • Enhanced comments in test fixtures to clarify ERC20 contract deployment details.

• Chores

  • Added a new constant for better clarity in contract deployment tests.

[kariy]

taking a look into the error

[kariy]

@enitrat do you mind recompiling this but without the owner arg ?

@constructor
func constructor{syscall_ptr: felt*, pedersen_ptr: HashBuiltin*, range_check_ptr}(
    name: felt, symbol: felt, decimals: felt, initial_supply: Uint256, recipient: felt, owner: felt
) {
    ERC20.initializer(name, symbol, decimals);
    ERC20._mint(recipient, initial_supply);
    return ();
}

considering its not being used at all. just to avoid confusion.

[enitrat]

ah yeah sorry i forgot to delete that one

[kariy]

ah yeah sorry i forgot to delete that one

ok thanks. the test should pass now

[coderabbitai]

Walkthrough

Ohayo, sensei! This pull request introduces a new ERC20 token contract implemented in Cairo for the StarkNet platform. It includes essential functionalities such as token transfers, allowance management, and various view functions to retrieve token properties. Additionally, modifications were made to the executor tests and fixtures to accommodate the new contract, including updates to transaction assertions and deployment structures.

Changes

File Path	Change Summary
crates/katana/contracts/erc20.cairo	- Implemented ERC20 token contract with constructor, view functions (name, symbol, totalSupply, decimals, balanceOf, allowance), and external functions (transfer, transferFrom, approve, increaseAllowance, decreaseAllowance). - Added alternative naming conventions for some functions.
crates/katana/executor/tests/executor.rs	- Updated assertions in test_executor_with_valid_blocks_impl for transaction count and deployed contract address. - Modified constructor arguments for the deployed contract to use a different felt value.
crates/katana/executor/tests/fixtures/mod.rs	- Added constant DEFAULT_LEGACY_ERC20_CONTRACT_CLASS_HASH. - Updated valid_blocks fixture to reflect new ERC20 contract deployment structure and modified cfg fixture to use the new constant.

Possibly related PRs

• Persistent mode for saya using mock of SNOS #2253: Updates to Cargo.toml and documentation for the saya tool, indirectly supporting the ERC20 contract implementation by ensuring dependencies are configured.
• Rename all remaining FieldElements to Felt for consistency #2433: Renaming FieldElement to Felt, relevant for consistency in data types used in the ERC20 contract.

Suggested reviewers

• neotheprogramist

---

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>, please review it.
  • 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 gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @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.
  • @coderabbitai help me debug CodeRabbit configuration file.

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 using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

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: 2

🧹 Outside diff range and nitpick comments (2)

crates/katana/executor/tests/fixtures/mod.rs (2)

189-210: Ohayo, sensei! The ERC20 deployment looks solid, but let's make it even better!

The updated calldata for deploying an ERC20 contract using UDC is well-structured and follows best practices. It's great to see realistic scenarios in our test fixtures!

However, to make this fixture more flexible, consider parameterizing the ERC20 details (name, symbol, decimals, total supply). This would allow for easier testing of different ERC20 configurations.

Here's a suggestion to make the fixture more reusable:

pub fn create_erc20_deployment_calldata(
    name: &str,
    symbol: &str,
    decimals: u8,
    total_supply: u128,
    recipient: ContractAddress,
) -> Vec<Felt> {
    vec![
        felt!("0x1"),
        felt!("0x41a78e741e5af2fec34b695679bc6891742439f7afb8484ecd7766661ad02bf"),
        felt!("0x1987cbd17808b9a23693d4de7e246a443cfe37e6e7fbaeabd7d7e6532b07c3d"),
        felt!("10"),
        DEFAULT_LEGACY_ERC20_CONTRACT_CLASS_HASH,
        felt!("0x6ea2ff5aa6f633708e69f5c61d2ac5f860d2435b46ddbd016aa065bce25100a"),
        felt!("0x1"),
        felt!("6"),
        Felt::from_string_str(name).unwrap(),
        Felt::from_string_str(symbol).unwrap(),
        Felt::from(decimals),
        Felt::from(total_supply),
        Felt::ZERO,
        recipient.into(),
    ]
}

Then, in the valid_blocks function:

calldata: create_erc20_deployment_calldata(
    "KARI",
    "KARI",
    18,
    6969,
    sender_address,
),

This approach would make our test fixtures more flexible and easier to maintain, sensei!

---

Line range hint 1-265: Ohayo, sensei! Overall structure looks good, but let's not forget our TODOs!

The changes to incorporate ERC20 contract deployment are well-integrated into the existing structure. Great job on enhancing our test scenarios!

However, I noticed we still have some TODO comments lingering around:

1. Line 30: "TODO: remove support for legacy contract declaration"
2. Line 93: "TODO: update the txs to include valid signatures"
3. Line 233: "TODO: test both with and without the flags turned on"

These TODOs suggest there might be some pending tasks or improvements. Should we create GitHub issues to track these, or are they still relevant? Let me know if you'd like me to help create these issues, sensei!

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between fd1e0f9 and 6bb0288.

📒 Files selected for processing (3)

• crates/katana/contracts/erc20.cairo (1 hunks)
• crates/katana/executor/tests/executor.rs (1 hunks)
• crates/katana/executor/tests/fixtures/mod.rs (2 hunks)

🧰 Additional context used

🔇 Additional comments (5)

crates/katana/executor/tests/fixtures/mod.rs (2)

15-16: Ohayo, sensei! LGTM on the import changes.

The addition of DEFAULT_LEGACY_ERC20_CONTRACT_CLASS_HASH suggests that we're gearing up for some exciting ERC20 contract deployment scenarios in our test fixtures. Nice touch!

---

Line range hint 220-231: Ohayo, sensei! A quick note on the cfg fixture.

While there are no visible changes to the cfg fixture, it's worth noting that it uses DEFAULT_FEE_TOKEN_ADDRESS. This constant is related to the newly imported DEFAULT_LEGACY_ERC20_CONTRACT_CLASS_HASH.

Consider if any updates are needed here to align with the new ERC20 deployment scenario we've introduced. If not, then everything looks good as is!

crates/katana/executor/tests/executor.rs (3)

179-179: Ohayo, sensei! This change looks sugoi!

The updated assertion and comment provide clearer context about the expected number of transactions. It's now explicit that we're accounting for an additional transaction from block 3.

---

184-184: Sugoi update, sensei!

Replacing the hardcoded felt value with DEFAULT_LEGACY_ERC20_CONTRACT_CLASS_HASH is a great improvement. It enhances code maintainability and readability by using a descriptive constant instead of a magic number.

---

197-197: Ohayo, sensei! Could you enlighten us about this change?

The felt value for the last constructor argument has been updated. While this change might be correct, it would be helpful to understand the reasoning behind it. Could you provide some context on why this specific value was chosen?

✅ Verification successful

Ohayo, sensei! The new felt value is used consistently, and the old value only appeared in a comment. No issues found with this change.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check if the new felt value is used consistently across the codebase

# Search for the old felt value
echo "Occurrences of the old felt value:"
rg --type rust "0x1b39" --glob '!crates/katana/executor/tests/executor.rs'

# Search for the new felt value
echo "Occurrences of the new felt value:"
rg --type rust "0x06b86e40118f29ebe393a75469b4d926c7a44c2e2681b6d319520b7c1156d114" --glob '!crates/katana/executor/tests/executor.rs'

Length of output: 620

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 68.59%. Comparing base (fd1e0f9) to head (6bb0288).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2521      +/-   ##
==========================================
- Coverage   68.59%   68.59%   -0.01%     
==========================================
  Files         387      387              
  Lines       49988    49988              
==========================================
- Hits        34291    34290       -1     
- Misses      15697    15698       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.