This PR adds support for basic token_uri support and slight changes to events naming (first letter is upper case now) in order to follow as closely as possible the standard on Ethereum (bonus : transfer event was conflicting with the function).

Quick overview :

• Two new structs

struct baseURI:
    member prefix : felt
    member suffix : felt
end

struct tokenURI:
    member prefix : felt
    member suffix : felt
    member token_id : felt
end

baseURI has two fields, allowing a 62 bytes long string, to accomodate for IPFS (cid is 46 bytes long). It is set once in the constructor, possibility to change it later is left to the user.

tokenURI is only returned in the token_uri-token_id) function. Potential to eventually swap the prefix and suffix fields for a baseURI struct.

• New storage var

@storage_var
func _base_uri() -> (base_uri: baseURI):
end

• New view function

@view
func token_uri{
    syscall_ptr: felt*,
    pedersen_ptr: HashBuiltin*,
    range_check_ptr
}(token_id: felt) -> (token_uri: tokenURI):
    let (base_uri : baseURI) = _base_uri.read()
    let token_uri = tokenURI(base_uri.prefix, base_uri.suffix, token_id)
    return (token_uri)
end

Events Added

• [x] /contracts/tokens/ERC721/ERC721.cairo
• [x] /contracts/tokens/ERC721/N-ERC721.cairo
• [x] /contracts/tokens/ERC20.cairo

:x: /contracts/tokens/ERC1155.cairo (TODO in ERC-1155 PR)

Events Tested ...

An incomplete serie of tests for ERC721.cairo, because it misses tokenURI tests and all safe features.

Also small fix of uint, the upper bits were set while it should have been the lower bits.

I made the necessary adjustements to not only enforce the Uint256 type for token_id, but to also remove and replace amount occurences, since it refers to ERC20 quantities.

Implement EIP-2612

Implement the EIP-2612 as per the specifications.

Starter

#############################################
##             EIP 2612 STORE              ##
#############################################

## TODO: EIP-2612

# bytes32 public constant PERMIT_TYPEHASH =
#     keccak256("Permit(address spender,uint256 token_id,uint256 nonce,uint256 deadline)");
# bytes32 public constant PERMIT_ALL_TYPEHASH =
#     keccak256("Permit(address owner,address spender,uint256 nonce,uint256 deadline)");
# uint256 internal immutable INITIAL_CHAIN_ID;
# bytes32 internal immutable INITIAL_DOMAIN_SEPARATOR;
# mapping(uint256 => uint256) public nonces;
# mapping(address => uint256) public noncesForAll;

We assume readers will know the difference of how accounts are handled between Ethereum and Starknet (non-smart contracts vs smart-contracts).

Since we cannot rely on examining the bytecode of the recipient to determine if it's an Account or another type of contract, one way to differentiate them, in order to determine how the safe transfer and mint have to behave, is to try to call the get_public_key of the assumed Account, and then if it holds a non-zero felt, it means it's OK, otherwise we call onERC721Received.

Except it's not possible. If the target recipient doesn't implement get_public_key (because it's not an Account but it handles ERC721s), the whole transaction will be reverted naturally.