When a program provides a client — whether written manually or generated with Codama — it usually includes a helper for each instruction to make it easier for users to add them to their transactions.
This means, the user is responsible for constructing its own transactions — e.g. by configuring compute unit limits, setting lifetimes, using lookup tables, etc. — as well as sending them — e.g. by selecting a confirmation strategy, a retry strategy, etc.
Let’s distinguish these two responsibility areas as the Program Layer and the Application Layer.
Offering granular instruction helpers is great but what if we had a program whose typical operations required carefully orchestrated sets of instructions to be executed in a particular way.
For instance, consider the Program Metadata program that attaches PDAs to programs to simplify access to custom data like their IDLs.
In order to update an existing account, a buffer must first be funded, allocated, initialised and written to multiples times before it can be used to update a metadata account and then closed. As you can imagine, updating a metadata account is a pretty common operation and it isn’t unreasonable for users to expect the program client to offer helpers for this kind of operations.
However, by entering the world of multi-instruction-helpers, program clients must now also take on some of the Application Layer’s responsibility.
For instance, in order to provide a function that updates a metadata account, it needs to know how to build and send transactions. Unfortunately, these concerns may vary from application to application and our little updateMetadata helper must now accept many options that have nothing to do with the operation itself.
Note: these instructions don’t match exactly what is in the Program Metadata program. They have been renamed and simplified to better illustrate the problem we’re trying to solve.
Therefore, what we need is a way for the Program Layer to offer a set of instructions with some execution constraints but without having to worry about how they will end up being transformed into transactions.
