Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: support proxied contract calls #3184

Closed
wants to merge 9 commits into from

Conversation

Torres-ssf
Copy link
Contributor

@Torres-ssf Torres-ssf commented Sep 19, 2024

Closes TS-644

Checklist

  • All changes are covered by tests (or not applicable)
  • All changes are documented (or not applicable)
  • I reviewed the entire PR myself (preferably, on GH UI)
  • I described all Breaking Changes (or there's none)

@Torres-ssf Torres-ssf added the feat Issue is a feature label Sep 19, 2024
@Torres-ssf Torres-ssf self-assigned this Sep 19, 2024
Copy link

vercel bot commented Sep 19, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
create-fuels-template ✅ Ready (Inspect) Visit Preview 💬 Add feedback Sep 19, 2024 2:36am
ts-docs ✅ Ready (Inspect) Visit Preview 💬 Add feedback Sep 19, 2024 2:36am
1 Skipped Deployment
Name Status Preview Comments Updated (UTC)
create-fuels-counter-example ⬜️ Ignored (Inspect) Sep 19, 2024 2:36am

Copy link

codspeed-hq bot commented Sep 19, 2024

CodSpeed Performance Report

Merging #3184 will degrade performances by 41.87%

Comparing st/feat/support-proxied-contract-calls (420a5c2) with master (20d2ac2)

Summary

❌ 1 regressions
✅ 20 untouched benchmarks

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

Benchmark master st/feat/support-proxied-contract-calls Change
Instantiate a new Unlocked wallet 61.4 ms 105.6 ms -41.87%

Copy link
Contributor

Coverage Report:

Lines Branches Functions Statements
77.12%(-0.04%) 71.64%(-0.17%) 75.77%(+0%) 77.23%(-0.04%)
Changed Files:
Ok File (✨=New File) Lines Branches Functions Statements
🔴 packages/program/src/contract-call-script.ts 10.84%
(-0.13%)
0%
(+0%)
0%
(+0%)
10.46%
(-0.12%)
🔴 packages/program/src/contract.ts 76.19%
(-2.75%)
75%
(-8.33%)
50%
(+0%)
76.19%
(-2.75%)
🔴 packages/program/src/response.ts 9.67%
(-0.33%)
0%
(+0%)
0%
(+0%)
9.67%
(-0.33%)

entry = "main.sw"
license = "Apache-2.0"
name = "proxy-src14-contract"

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this have the proxy flag?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@danielbate Good catch.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From my investigation, I actually think the flag goes on the target contract. Not the SRC14 compliant contract.

echoValuesId,
CoverageContract.abi,
wallet,
proxyId
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@danielbate danielbate Sep 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could then possibly use the proxy flag to modify the Interface and merge the passed ABI with an SRC14 interface ABI?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

@danielbate danielbate Sep 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes exactly, well summarised. What do you think?

@Torres-ssf
Copy link
Contributor Author

Torres-ssf commented Sep 20, 2024

Closing in favor of #3190

@Torres-ssf Torres-ssf closed this Sep 20, 2024
@arboleya arboleya deleted the st/feat/support-proxied-contract-calls branch September 20, 2024 17:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feat Issue is a feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Provide better ergonomics for proxied contract calls
2 participants