sRFC 00008: IDL Standard
Summary
It’s no question that the introduction of an IDL alongside a Solana program was one of the biggest value-adds provided by Anchor.
With an IDL, indexers, explorers, and many other tools can gain insight into a deployed program that they otherwise couldn’t have gotten - especially deserialization of PDA data.
Right now, we continually run into problems when trying to develop tools or solutions that encounter two types of programs: one with an IDL published, and one without an IDL.
Immediately these projects have to essentially “skip” or “omit” programs that are deployed without an IDL, because their solution simply will not work without one.
We need a standard way to manage IDLs for programs across Solana, and it shouldn’t matter which framework or tools you use to build your program.
Questions
What should an IDL’s interface look like?
Two existing and popular tools for creating IDLs - Anchor and Shank - actually generate very similar IDLs.
Here’s part of a simple example:
{
"version": "0.1.0",
"name": "car_rental_service",
"instructions": [
...
{
"name": "BookRental",
"accounts": [
{
"name": "rentalAccount",
"isMut": true,
"isSigner": false,
"desc": "The account that will represent the actual order for the rental"
},
{
"name": "carAccount",
"isMut": false,
"isSigner": false,
"desc": "The account representing the Car being rented in this order"
},
{
"name": "payer",
"isMut": true,
"isSigner": false,
"desc": "Fee payer"
},
{
"name": "systemProgram",
"isMut": false,
"isSigner": false,
"desc": "The System Program"
}
],
"args": [
{
"name": "bookRentalArgs",
"type": {
"defined": "BookRentalArgs"
}
}
],
"discriminant": {
"type": "u8",
"value": 1
}
},
...
],
"accounts": [
...
{
"name": "RentalOrder",
"type": {
"kind": "struct",
"fields": [
{
"name": "car",
"type": "publicKey"
},
{
"name": "name",
"type": "string"
},
{
"name": "pickUpDate",
"type": "string"
},
{
"name": "returnDate",
"type": "string"
},
{
"name": "price",
"type": "u64"
},
{
"name": "status",
"type": {
"defined": "RentalOrderStatus"
}
}
]
}
}
],
"types": [
...
{
"name": "RentalOrderStatus",
"type": {
"kind": "enum",
"variants": [
{
"name": "Created"
},
{
"name": "PickedUp"
},
{
"name": "Returned"
}
]
}
}
],
"metadata": {
"origin": "shank",
"address": "8avNGHVXDwsELJaWMSoUZ44CirQd4zyU9Ez4ZmP4jNjZ",
"binaryVersion": "0.0.12",
"libVersion": "0.0.12"
}
}
Ultimately, we want to figure out if we can use this (or Anchor’s IDL) as the interface for all IDLs across Solana.
What Should be the Standard for Implementing the IDL Interface?
If we consider the IDL above - or something similar - to serve as our IDL interface, what should be the standard for implementing?
Can you just add whatever fields you want, as long as you still have the fields from the interface? For example:
"accounts": [
...
{
"name": "RentalOrder",
"type": {
"kind": "struct",
"fields": [
{
"name": "car",
"type": "publicKey"
},
{
"name": "name",
"type": "string"
},
],
"myCustomConfiguration": {
"someConfig": 1,
"someOtherConfig": "2",
}
}
}
],
Considerations:
- This would break any type-oriented IDL parsers by introducing new fields that otherwise weren’t part of the type schema
- A lack of limits might inflate the size of IDLs unexpectedly
What crate/lib/types Should be Used?
We could do something like introduce a standard crate with the interface types as the basis for all IDLs on Solana.
We then could modify these types to allow for pluggable custom configurations, or some other means for easily implementing the interface for an IDL leveraging this crate.
A great candidate for this standard library of IDL types (interface) is Iron Forge’s Solana IDL - an open-source crate containing the IDL types from Shank compatible with serde.
It would be great to hear thoughts on:
- Electing this crate as the IDL type interface
- Modifying this crate to serve as an implementable interface, with customizable type configurations
Implementations & Ideas
Here’s a PR introduced by Noah from Solana Labs to introduce the idea of an IDL program within the Solana runtime.
Here’s a crate produced by Thorsten from Iron Forge to lay down the Rust types for creating an IDL leveraging serde.
Conclusion
In short, like any other interface or standard proposal, this is a migration that could be done in a way that hurts only once, but allows for easy integrations and added support in the future.
A quick recap on the questions proposed:
- What should an IDL’s interface look like?
- What should be the standard for implementing the IDL interface?
- What crate/lib/types should be used?
