This repository has been archived by the owner on Oct 19, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 796
Increase Multicall Call Limit to Past 16 #900
Comments
I think the "right" way to do this would be as you said. Here's one way to implement it (and yes the user would need to decode manually, should be simple enough) pub async fn call_raw(&self) -> Result<Vec<Token>, ContractError<M>> {
let (_block_number, return_data) = contract_call.call().await?;
let tokens = self.calls.iter().zip(&return_data).map(|(call, bytes)| {
let mut tokens: Vec<Token> = call.function.decode_output(bytes.as_ref())?;
Ok(match tokens.len() {
0 => Token::Tuple(vec![]),
1 => tokens.remove(0),
_ => Token::Tuple(tokens),
})
}).collect::<Result<Vec<Token>, ContractError<M>>>()?;
Ok(tokens)
}
pub async fn call<D: Detokenize>(&self) -> Result<D, ContractError<M>> {
// (and remove it from the `add_call` method
assert!(self.calls.len() < 16, "Cannot decode more than {} calls", 16);
let tokens = self.call_raw().await?;
let tokens = vec![Token::Tuple(tokens)];
let data = D::from_tokens(tokens)?;
Ok(data)
} Wanna open a PR for that w a test? |
Yeah, I'm going to try to get one crafted and submitted today/tomorrow. Thanks! |
3 tasks
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Is your feature request related to a problem? Please describe.
Currently, the Multicall interface can only contain up to 16 calls at a time as shown here. Part of this reason is the fact that the call will need to detokenize the responses into a tuple of a known size.
Describe the solution you'd like
From my understanding, I would like to be able to make a multi call that 1) contains more than 16 calls, and 2) allows the multi call to contain an unknown number of calls (computed at runtime) which returns an uknown number of responses. I would be interested in working on this; however, I'm not sure I possess enough familiarity with the library to accomplish it on my own.
Describe alternatives you've considered
One potential solution, from my understanding, is to not attempt to detokenize the response. This could push the responsibility from recovering the responses to the user.
Additional context
From my understanding, accomplishing this would require replacing / providing alternatives for the use of both Detokenize and Token. I've included some of the relevant code below.
The text was updated successfully, but these errors were encountered: