search

coral-xyz / anchor

⚓ Solana Sealevel Framework
https://anchor-lang.com
Apache License 2.0
3.63k stars 1.33k forks source link

IDL Program #1180

Open armaniferrante opened 2 years ago

armaniferrante commented 2 years ago

There should be a separate program that stores the IDLs as PDAs of a program id and version number, instead of embedding the IDL instructions into the program directly.

kevinaud commented 2 years ago

Adding the diagrams from the discord thread for posterity.

Go from this: Anchor Modules - Bundled approach

To this: Anchor Modules - Generic approach

armaniferrante commented 2 years ago

An additional question we should consider is how to atomically update the program binary with the IDL. This is important for explorers. There are two options

  1. Add a custom ELF section (can you do that?) to the .so file with the IDL, or append the IDL to the end of the bytecode. A custom ELF section might be tough if there are no good client side tools for this.
  2. Assume the user uses the Anchor CLI to deploy and provide a new command to do the program upgrade/deploy + IDL upgrade/deploy in the same tx.
kevinaud commented 2 years ago

I'm not sure if I fully grasp #1, I'm not familiar with the details of solana executables (and I got a C in operating systems haha) but #2 sounds reasonable to me.

A unrelated question I have is how do we manage the ownership/deployment of the IDL Program? Someone (I'm assuming you) will have to generate a keypair and be responsible for keeping the private key safe + deploying the program. We could set up a CI/CD deployment pipeline and store the encrypted private key so it can auto-deploy.

kevinaud commented 2 years ago

Someone on discord suggested using this project for key management/deployment: https://github.com/GokiProtocol/goki

I don't have experience with it but it looks interesting.

armaniferrante commented 2 years ago

Dealing with upgrading the IDL program is probably the main argument against such a program. We would need some governance (probably a DAO) around it. My instinct is that it's better to just leave that up to the governance mechanism of the associated program rather than introduce another one, which would mean not introducing a separate program for IDLs. Binary sizes aren't a problem that I know of and the IDL instructions don't meaningfully complicate the macro code, so I think I'm in favor of leaving the IDL mechanism as is--embedded into the the program.

kevinaud commented 2 years ago

I agree that is probably the main argument against this. Do you have any idea how the SPL handles this for those programs?

paul-schaaf commented 2 years ago

IDL generation is an anchor feature and the SPL programs dont use anchor so they dont have to think about it.

but given that the explorer can parse token instructions, I assume there's a js/json file somewhere for some of the programs that is being manually updated

paul-schaaf commented 2 years ago

I'm now also of the opinion that it would be better to keep it inside the programs for the reason that I think introducing any kind of dao or similiar governance structure around anchor will slow us down too much.

In the future, this could be revisited tho imo. Having a separate program has the benefit that upgrading the IDL of all anchor programs, e.g. in case there's a bug in it, can be done through upgrading a single program.

Without an IDL program, if there's a bug in the IDL generation code, each anchor program has to upgrade themselves. For some this may be easy, for others, whose upgrades are subject to governance and timelocks, it will be more difficult. In addition, upgrading to a new anchor version would also mean incorporating other new anchor code into their projects (how much of a bad thing that is, I'm not sure yet).

kevinaud commented 2 years ago

I know SPL programs don't use IDL, I just meant how do they handle governance/upgrades