-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Changes from all commits
8afee53
c48b482
b39bf16
eca3d31
14906a3
b4a02e9
1cb83f9
4892026
420a5c2
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,8 @@ | ||
[project] | ||
authors = ["Fuel Labs <contact@fuel.sh>"] | ||
entry = "main.sw" | ||
license = "Apache-2.0" | ||
name = "proxy-src14-contract" | ||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should this have the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @danielbate Good catch. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. |
||
[dependencies] | ||
standards = { git = "https://github.com/FuelLabs/sway-standards", tag = "v0.6.1" } |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,38 @@ | ||
contract; | ||
|
||
use std::execution::run_external; | ||
use standards::{src14::SRC14}; | ||
|
||
pub enum ProxyErrors { | ||
TargetNotSet: (), | ||
} | ||
|
||
configurable { | ||
INITIAL_TARGET: ContractId = ContractId::zero(), | ||
} | ||
|
||
storage { | ||
SRC14 { | ||
target: Option<ContractId> = None, | ||
}, | ||
} | ||
|
||
impl SRC14 for Contract { | ||
#[storage(read, write)] | ||
fn set_proxy_target(new_target: ContractId) { | ||
storage::SRC14.target.write(Some(new_target)); | ||
} | ||
|
||
#[storage(read)] | ||
fn proxy_target() -> Option<ContractId> { | ||
Some(storage::SRC14.target.read().unwrap_or(INITIAL_TARGET)) | ||
} | ||
} | ||
|
||
#[fallback] | ||
#[storage(read)] | ||
fn fallback() { | ||
let target = storage::SRC14.target.read().unwrap_or(INITIAL_TARGET); | ||
require(target.bits() != b256::zero(), ProxyErrors::TargetNotSet); | ||
run_external(target) | ||
} |
There was a problem hiding this comment.
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.There was a problem hiding this comment.
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 theInterface
and merge the passed ABI with anSRC14
interface ABI?There was a problem hiding this comment.
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 theForc
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.
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?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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
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?