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
In #5366 we enable using simulate to call a contract without populating the reference arrays. The simulate response then includes a list of all "touched" resources.
Given this list, it should be possible to optimally populate foreign reference arrays for the transactions to be accepted by the network. This will allow dapps (if they choose to) to mostly stop managing foreign references themselves.
There will be some complexity in the logic to populate the arrays, because:
some resources are implicitly available based on the transaction itself (e.g. the sender account is accessible).
the group resource sharing rules are not straightforward when it comes to cross-products. e.g. it may in some situations be necessary to include the same reference in multiple transactions' arrays.
It is not a requirement to find a truly optimal packing of the arrays if it proves algorithmically difficult.
The output may include additional new app call transactions to the group (using a null app of some kind that just approves).
This issue is to create a function populate_reference_arrays(transaction group, list of necessary resources) -> suggested arrays for each txn.
We could add this to simulate, as a new flag called pack-my-arrays or something. If they already packed some refs in their arrays, we don't touch those, we just add what's needed.
note: if you need to pack an address that is the hash of an app that you are calling, you should notice that (because you already have access to it)
The text was updated successfully, but these errors were encountered:
In #5366 we enable using simulate to call a contract without populating the reference arrays. The simulate response then includes a list of all "touched" resources.
Given this list, it should be possible to optimally populate foreign reference arrays for the transactions to be accepted by the network. This will allow dapps (if they choose to) to mostly stop managing foreign references themselves.
There will be some complexity in the logic to populate the arrays, because:
It is not a requirement to find a truly optimal packing of the arrays if it proves algorithmically difficult.
The output may include additional new app call transactions to the group (using a null app of some kind that just approves).
This issue is to create a function
populate_reference_arrays(transaction group, list of necessary resources) -> suggested arrays for each txn
.We could add this to simulate, as a new flag called pack-my-arrays or something. If they already packed some refs in their arrays, we don't touch those, we just add what's needed.
note: if you need to pack an address that is the hash of an app that you are calling, you should notice that (because you already have access to it)
The text was updated successfully, but these errors were encountered: