Add Asynchronous Support to TransactionAuthenticator Trait Methods
Closed this issue · 3 comments
Feature description
Similar to this feature request.
Because the miden-client implements the TransactionAuthenticator trait and calls the store in its get_signature implementation, we will to add support for an asynchronous version of this trait and it's get_signature method.
The same suggested approach and reasoning apply as the issue linked.
Why is this feature needed?
No response
@dagarcia7, we understand that you have found a workaround for this issue. Is this a temporary workaround in your mind or a steady solution?
Hey, @Dominik1999! Great question. What we have currently as a workaround is pretty hacky. We're basically querying our store asynchronously before any transaction requests are made to fetch the account auth, and set it in memory in a map where the key is the pub key and the value is the auth info.
This allows get_signature to call the get_auth_by_pub_key method synchronously because we modified that method to fetch the info from the map instead of the store.
So the solution itself feels a bit like an anti-pattern and the user experience suffers a bit from the npm package side because you have to remember to call the function that stores the auth info in memory for a specific account before creating a transaction.
That being said, it should work ok as a temporary solution, but feel like it should be revisited in the future. The ideal solution might not even involve adding async support to the TransactionAuthenticator. It might involve a refactor to remove the store dependency from it in the client code implementation or a different (less hacky) workaround like we currently have.
In the meantime, I think this issue is probably good to close.
I'll close this issue for now - but would be good to figure out a less hacky solution here sooner rather than later.
One reason for this is that if we implement #401, we will probably run into the same issues with DataStore as we did with TransactionAuthenticator - i.e., the data store will need to fetch some data (probably from storage) based on some requests from the VM. And since these requests are synchronous (same as with authenticator), we may not be able to make some future methods in the DataStore async.