OpenZeppelin Upgradeable contracts

OpenZeppelin related: So i have been implementing our contract to be proxiable/upgradable but just found out that even the view methods require a transaction apparently (if we want contract to be upgradeable/proxiable) which would kill our UI. Has anybody run into similar issue? We are implementing it via openzeppelin proxy/upgrade contracts of course

It will be for the UI because of constant user prompts for transaction even for for view methods.

17 Likes

You don’t need a transaction for view methods. Just perform a call.

11 Likes

per documentation

As with most StarkNet contracts, interacting with a proxy contract requires an account abstraction. One notable difference with proxy contracts versus other contract implementations is that calling @view methods also requires an account abstraction. As of now, direct calls to default entrypoints are only supported by StarkNet’s syscalls from other contracts i.e. account contracts. The differences in getter methods written in Python, for example, are as follows:

standard ERC20 call

result = await erc20.totalSupply().call()

upgradeable ERC20 call

result = await signer.send_transaction(
account, PROXY.contract_address, ‘totalSupply’,
)

12 Likes

That’s very weird. I’ve just checked on my account’s contract which is behind a proxy and you can call methods directly with no problems. Here’s fetch that I used (copied from network’s tab).

fetch("https://alpha4.starknet.io/feeder_gateway/call_contract?blockNumber=pending", {
  "headers": {
    "accept": "*/*",
    "accept-language": "en-GB,en-US;q=0.9,en;q=0.8",
    "content-type": "application/json",
  },
  "referrer": "https://goerli.voyager.online/contract/0x049a584df7f8f960ba7ac845b76fa2e86726f3e05e869faf5c0f628b7b1e1cf2",
  "referrerPolicy": "unsafe-url",
  "body": "{\"signature\":[],\"contract_address\":\"0x049a584df7f8f960ba7ac845b76fa2e86726f3e05e869faf5c0f628b7b1e1cf2\",\"entry_point_selector\":\"0x1ac47721ee58ba2813c2a816bca188512839a00d3970f67c05eab986b14006d\",\"calldata\":[]}",
  "method": "POST",
  "mode": "cors",
  "credentials": "omit"
}).then(r => r.json() ).then(console.log)

As you can see it is just a regular call with no signature. Turing view calls into transactions doesn’t make sense for me.

14 Likes

Yep confirming your response but the open zeppelin doc should clarified more I think, its a little confusing. I was able to call view methods without account abstraction and invoke transactions

10 Likes

I agree, I created an issue there: Confusing proxy documentation · Issue #414 · OpenZeppelin/cairo-contracts · GitHub.

14 Likes

How to deploy the contract in remix