Batched Requests #892
Comments
|
I am going to close this one out, as the desired behavior would not necessarily execute in a batched request. A transaction cue which executes off of mined transactions is probably the solve here. thanks |
|
I've added |
|
oh, this is great! thank you very much. will report back |
|
Am I giving Not quite sure how to schedule a series of transactions |
|
No, you use it like a normal JsonRpcProvider, with the standard Provider API. There is nothing special about how you interact with it. It will implicitly batch all requests made within a single event loop for you. const provider = new JsonRpcBatchProvider();
// Begin queuing...
const promiseA = provider.getBlockNumber();
const promiseB = provider.getGasPrice();
// This line won't finish until both A and B are complete, and both A and B are sent as a batch
const [ blockNumber, gasPrice ] = await Promise.all([ promiseA, promiseB ]);
// Queue some new things...
const promises = [ ];
for (let j = 0; j < 10; j++) {
promises.push(provider.call(getTx(j)));
}
// This line won't complete until the 10 above calls are complete, all of which will be sent as a single batch
const results = await Promise.all(promises);Otherwise it won't be compatible with any existing libraries or features that use a standard ethers Provider. I am considering adding a Make sense? |
|
hmm, this line for me: seems to execute regardless of if I wait for it. I guess my experience with web3 batching, is that with their api you will add to a batch array, and then send the batched transaction with a batch send transaction. Here you are just loading them up, and whether they begin doesn't matter, you are just waiting for them to all complete? |
|
also I am sure I don't have this quite right, but would the nonce get incremented using the batch provider? |
|
Keep in mind batching is not part of the Ethereum spec or Web3, per se. It is part of the JSON-RPC specification, so Ethereum and Web3 accidentally inherited it as a result of that. It actually makes very little sense in Ethereum since the outputs from a result are required as inputs to other calls, and JSON-RPC batching doesn’t support those type of inter-dependent connections. The only real reason to use it is to reduce the number of HTTP connections. That line will execute immediately, but the call to send will buffer it internally, and if it is the first send of that event loop, if will schedule a send-request for the next event loop. Each subsequent send will not schedule additional send-requests, but will append to the pending queue. Once the current evaluation loop is complete, the next event loop triggers, which will cause that above send-request to fire off all pending requests and clear the queue, preparing it for the next evaluation loop. Now, keep in mind, as I mentioned above JSON-RPC batching does not support dependencies within the same batch, and ethers implicitly populates things like gas price, gas limit, nonce, etc. if you do not specify them. Populating these things will occur in the next event loop, which means those calls depending on those values are at least 2 event loops away, so will not get batched, unless you specify all properties that The JsonRpcBatchProvider will bundle things up as efficiently as possible and ensure dependency order is adhered to, but due to dependencies, there isn’t actually that much to gain in many cases… Does that make sense? |
|
Batches cannot increment the nonce because you must look it up, then include it. But a batch must be fully formed at send time, so it cannot know. You cannot do a batch that looks like The NonceManager should handle that for you, but (I cannot recall for sure), may not handle it synchronously, which means each will occur in the next event loop, so it would spread the calls over multiple batches. If the nonce manager does not return pending promises without an await, this is easy to adjust, but I think it should already do what you want to achieve the above dependency tree. You can use |
|
Okay, I have a successful test: updated the contract correctly. I'll play around with it. Thanks for the hard work. |
|
No problem. I think performance can improve by allowing a time-slice-based batch instead of an event-loop-based solution, but that requires some experimentation, as each time-slice will put an extra delay on each step of the dependencies. It's still a work in progress. :) |
|
I was using a websocket for this service (and use it for many others), but this doesn't need to be connected all the time. If I use the batch rpc provider to wakeup establish an rcp connection, and then go back to sleep, what is the best way to destroy the rpc provider, so I don't build up connections on every wake up? (infura often goes stale, so it would be nice to make and break the connection). |
|
so far so good, and the batching provider |
|
Will using
|
|
The JsonRpcBatchProvider will batch any requests made during the same event loop. Many operations in ethers perform lookups for you, so dependency calls will be made (and batched) as best as possible, and then the dependent calls made. If you fully describe the call (i.e. include a Future changes I will likely make to the JsonRpcBatchProvider will use a timer to decide what to batch (relaxing the event loop restriction), and enabling some sort of explicit mode, although, this could possibly cause apps to terminate in some environments, since it would allow for unresolvable Promise-Promise dependencies. In v6, the JsonRpcProvider will also more aggressively cache certain calls made during the same event loop, which will be added to the JsonRpcBatchProvider too. But try it out, and let me know if it works for you. |
Could you give an example or show in the documentation how to call multiple functions in a contract at once? That it was in one transaction. const provider = new ethers.providers.JsonRpcBatchProvider(rpc);
const signer = new ethers.Wallet(privateKey, provider);
const one = new ethers.Contract(addr1, abi1, signer);
const two = new ethers.Contract(addr2, abi2, signer);
const { wait: waitFunc1 } = await one.Func1();
await waitFunc1();
const { wait: waitFunc2 } = await two.Func2();
await waitFunc2(); |
|
@alexbakers You could use: const txs = await Promise.all([ one.Func1(), two.Func2() ]);
const receipts = await Promise.all(txs.map((t) => t.wait()));Keep in mind, that ethers will populate things like the nonce for you, so any of those async properties (which forma dependency tree) will delay the transaction to the next event loop. So, the event loop immediately after those transactions were made would look like [ getNonce, estimateGas1, estimateGas2 ] and once those came back (assuming they come back close enough to the same time) would then look like [ sendTx1, sendTx2 ]. I'm assuming you would be using the NonceManager, otherwise there would be two getNonce calls, which would likely step on each other. But if estimateGas1 comes back early and the estimateGas2 takes its sweet time, the sendTx1 will prolly go out before sendTx2. It implicitly forms a dependency tree, and will batch things as efficiently as possible. If you need more control, you can just make sure you supply the necessary overrides into the Func(overrides) calls, so ethers doesn't need to look up gas estimates or nonces for you. Does that make sense? |
|
@alexbakers were you able to make it work? I'm trying to make a multicall which should fail if one of the write functions fails. Could you please share a sample code if you made it work? Cheers! |
|
Using ethers-batch-request, you can perform some simple contract queries. |
|
Batch requests are built-in and enabled by default in Ethers v6, and can be adjusted for max batch size and max request count. If you wish to use multicall for aggregating many read operations, there is also the MulticallProvider which will use a deploy-less technique to merge many calls into a single call. |
|
Hi @ricmoo , by "Batch requests are built-in and enabled by default in Ethers v6", do you mean that when |
Does ethers have a way to do serialized batch requests?
re:
https://web3js.readthedocs.io/en/v1.2.9/web3-eth.html#batchrequest
The text was updated successfully, but these errors were encountered: