You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After #934 how we load account code and other data into the executor as it has become somewhat inconsistent.
The current model is:
Code of foreign accounts is loaded via TransactionExecutor::load_account_code().
Code of native account, notes, and transaction script are loaded via the DataStore interface.
There are a couple of alternatives to this:
Alternative 1
Load everything through the DataStore interface. This would mean that we'd need to add a list of account IDs to TransactionArgs and the DataStore interface` will look roughly like this:
Load everything via TransactionArgs. This would basically get rid of the DataStore interface for now as TransactionArgs would basically become a superset of TransactionInputs returned from the DataStore. In this scenario, the client would first make the call to the store to build TransactionInputs manually and then pass them to the executor.
The reason I say "for now" is because eventually we'll need to implement lazy loading of account storage/vault and we'll need to have something like the DataStore interface.
Alternative 3
We merge DataStore and TransactionMastStore into a single interface. Basically, it would mean that the interface would look something like this:
That is, anything that implements DataStore would also need to implement MastForestStore interface (with its single get(&self, procedure_hash: &Digest) -> Option<Arc<MastForest>> method) .
After #934 how we load account code and other data into the executor as it has become somewhat inconsistent.
The current model is:
TransactionExecutor::load_account_code()
.DataStore
interface.There are a couple of alternatives to this:
Alternative 1
Load everything through the
DataStore
interface. This would mean that we'd need to add a list of account IDs toTransactionArgs
and theDataStore
interface` will look roughly like this:Alternative 2
Load everything via
TransactionArgs
. This would basically get rid of theDataStore
interface for now asTransactionArgs
would basically become a superset ofTransactionInputs
returned from theDataStore
. In this scenario, the client would first make the call to the store to buildTransactionInputs
manually and then pass them to the executor.The reason I say "for now" is because eventually we'll need to implement lazy loading of account storage/vault and we'll need to have something like the
DataStore
interface.Alternative 3
We merge
DataStore
andTransactionMastStore
into a single interface. Basically, it would mean that the interface would look something like this:That is, anything that implements
DataStore
would also need to implementMastForestStore
interface (with its singleget(&self, procedure_hash: &Digest) -> Option<Arc<MastForest>>
method) .Originally posted by @bobbinth in #936 (comment)
The text was updated successfully, but these errors were encountered: