feat: support proxied contract calls #3184
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
1 Skipped Deployment
|
Torres-ssf
changed the title
CodSpeed Performance ReportMerging #3184 will degrade performances by 41.87%Comparing Summary
Benchmarks breakdown
|
|
Coverage Report:
Changed Files:
|
| entry = "main.sw" | ||
| license = "Apache-2.0" | ||
| name = "proxy-src14-contract" | ||
|
|
There was a problem hiding this comment.
Should this have the proxy flag?
There was a problem hiding this comment.
@danielbate Good catch.
There was a problem hiding this comment.
From my investigation, I actually think the flag goes on the target contract. Not the SRC14 compliant contract.
| echoValuesId, | ||
| CoverageContract.abi, | ||
| wallet, | ||
| proxyId |
There was a problem hiding this comment.
Do you think we could just read this value from the SRC14 storage? Then we could just pass some { proxy: true } config and the user only needs to be aware of one contract ID that doesn't change.
Only issue is in the contract call, we'd first need to read the value, with a function call to proxy_target using the existing contract ID. Then, we'd perform the user dictated function call against the received contract ID.
There was a problem hiding this comment.
We could then possibly use the proxy flag to modify the Interface and merge the passed ABI with an SRC14 interface ABI?
There was a problem hiding this comment.
@danielbate I was planning to solve this with Typegen. Since the flag [proxy] is available in the Forc file, then we could use it. So when connecting with the contract or deploying it, if the flag is present we can already handle things on the fly.
With that, I believe we solve the problem of having the user manually inform the proxy contract ID and avoid executing the call to read the target contract at the proxy contract, which would represent an additional dryRun since it is a read call.
About modifying the proxy contract Interface, I made a couple of tries but didn't succeed. Maybe I am missing something.
There was a problem hiding this comment.
Typegen is a good idea, will we still need a way for users to connect that haven't used a typegen factory though? Just a standard new Contract()?
Even with typegen though, how do we know the ID of the target contract without the dryRun, if it hasn't been deployed by us?
About modifying the proxy contract Interface, I made a couple of tries but didn't succeed. Maybe I am missing something.
Lets see if we can solve this later, not a massive deal as the user will ideally just want to call the target contract functions anyways.
There was a problem hiding this comment.
Even with typegen though, how do we know the ID of the target contract without the dryRun, if it hasn't been deployed by us?
@danielbate It seems the solution you idealize for this is different from the one that I am approaching. In the context described here, the user would have only in its hands the contract Proxy ID and wants to execute a contract call for the target proxy, and they do not have the ID of the deployed target contract, right?
This is why you are suggesting a way to modify the proxy contract interface using the target contract interface. Therefore the user would use just the proxy contract ID to execute the call, then, behind the scenes, we would:
1 - Instantiate the Proxy contract, using also the target contract JSON ABI to have all its existent functions.
2 - Execute a read only call to the Proxy contract to get the target contract ID
3 - Build the script for the contract with the Proxy contract ID and execute the actual contract call specified by the user.
Is that your proposal?
There was a problem hiding this comment.
Yes exactly, well summarised. What do you think?
Checklist