Supporting parsed data

[linuskendall]

There are a few corners of the current RPC spec that requires knowledge about onchain programs and the ability to interpret them (or rely on some kind of indexed data store) - in particular to support the jsonParsed encoding.

There has also been requests from developers for having higher level interfaces for both filter (getPA style) and for getting more parsed account data (a la jsonParsed). Currently jsonParsed supports only a limited set of programs (https://github.com/solana-labs/solana/tree/master/transaction-status/src) and has no easy way to extend.

Suggestions that have been floated:

• Have RPC server support anchor IDLs a way to expand the set of programs that can be used
• Have graph QL support for more rich querying (a la Solana FM?) (this would probably rely on an indexed store)

[grooviegermanikus]

are you looking at this to have preprocesses (pre-parsed) data or to parser on query?

pre-parsed:

• PRO: faster access, indexing
• PRO: data issues will be detected early
• CON: parsing needs to be defined prematurely
• CON: migration/extending is hard

[grooviegermanikus]

could you clarify - we need it parse account data as well as instructions? @linuskendall

[vovkman]

Referencing this thread here - https://x.com/redacted_noah/status/1723031204180398374?s=20

Using runtime parsing would probably work for such a usecase, but we could also consider a separate table, or additional field for JSON data if we wanted to make use of DB to seek over specific values in a JSON from IDL. Obv scanning over rows in mem would be nasty for large scans

[vovkman]

are you looking at this to have preprocesses (pre-parsed) data or to parser on query?

pre-parsed:

• PRO: faster access, indexing
• PRO: data issues will be detected early
• CON: parsing needs to be defined prematurely
• CON: migration/extending is hard

IMO any parsing that ends up in a data store should be based on IDL, then you eliminate the two CON's

Anything additional should be computed on query