Currently, inspecting an on-chain transaction requires depending on a client-side, language-specific decoding library to parse the instruction. If rpc methods could return decoded instruction details, these custom solutions would be unnecessary.
We can deserialize instruction data using a program's Instruction enum, but decoding the account-key list into human-readable identifiers requires manual parsing. Our current Instruction enums have that account information, but only in variant docs.
Similarly, we have instruction constructor functions that duplicate nearly all the information in the enum, but we can't generate that constructor from the enum definition because the list of account references is in code comments.
Also, Instruction docs can vary between implementations, as there is no mechanism to ensure consistency.
Move the data from code comments to attributes, such that the constructors can be generated, and include all the documentation from the enum definition.
Here is an example of an Instruction enum using the new accounts format:
An example of the generated TestInstruction with docs:
Generated TestInstructionVerbose enum:
- Named fields - Since the resulting Verbose enum constructs variants with named fields, any unnamed fields in the original Instruction variant will need to have names generated. As such, it would be considerably more straightforward if all Instruction enum fields are converted to named types, instead of unnamed tuples. This seems worth doing anyway, adding more precision to the variants and enabling real documentation (so developers don't have to do this This will cause a little churn in our current code base, but not a lot.
- Variable account lists - This approach offers a couple options for
variable account lists. First, optional accounts may be added and tagged with
optionalkeyword. However, currently only one optional account is supported per instruction. Additional data will need to be added to the instruction to support multiples, enabling identification of which accounts are present when some but not all are included. Second, accounts that share the same features may be added as a set, tagged with the
multiplekeyword. Like optional accounts, only one multiple account set is supported per instruction (and optional and multiple may not coexist). More complex instructions that cannot be accommodated by
multiple, requiring logic to figure out account order/representation, should probably be made into separate instructions.