How are access lists generated for inter-dependent contracts with conditional logic?

[prberg]

Let’s take four contracts:

1. Foo
2. Bar
3. Baz
4. Qux

Foo is the master contract, having a reference to all other contracts. Bar is just a storage device, containing some state. Baz and Qux are subordinate to Foo in the sense that they let it modify their storage.

Now, suppose that Foo has some logic dependent on some state in Bar. Depending on the value of the said state, Foo might modify either Baz or Qux.

If a user interacts with Foo, how are the access lists generated by the wallet?

Will the wallet include both Baz and Qux in the write-create access lists? Or only one of them, depending upon the state in Bar?

But if only one of them is included (say Baz), doesn’t this mean that the tx will fail if, prior to the user’s tx, another tx gets submitted that modifies the state of Bar so that Foo will touch Qux instead of Baz?

[david]

It’s generally up to the client-side application to create the “access list”, specifying which contracts will be included in the transaction.

The application can call estimate_tx_dependencies, which will simulate the transaction and generate the contract list (similar to gas estimation on the EVM). But in the case you described, where the dependencies can change at execution time, the application would manually add all possible dependencies using the functions with_contracts or with_contract_ids.

This page in the docs explains dependency estimation for the Rust SDK, although the same principles apply to the TypeScript SDK.