Use a faster data structure!
I am not kidding. It might seem that in blockchain consensus many things that you can normally do are made difficult, but as long as your algorithm is deterministic (reproducible 100% across all nodes) any algorithm can be used.
My favorite is hash tables as they have constant time lookups even at large scale. For the dilithium CC, I wanted to support sending to handles, so that meant a hashtable of all existing names that is compared against to make sure any new handle trying to register is unique. If not, the CC validation would reject it.
This then creates a txid with the handle <-> secp pubkey (and dilithium pubkey) mapping, so the handle just needs to map to a txid. The gui can save the handles it wants to be able to use in an addressbook and map the user specified handle to a txid. The blockchain would see this txid and lookup the actual destination pubkey.
There is no reason this handle support cant be added to the normal payments, even if using the dilithium rpc calls. Of course, making a custom variant to handle just the secp pubkeys would be a lot more efficient, but these are all simple design tradeoffs to make.
Each CC by convention creates a set of CC specific rpc calls, most of them to create and manage the CC specific transactions. What this means is that with a properly designed CC, a large number of dapps can be written using just the built in CC rpc calls.
To do CC based dapps, there are therefore two different levels of difficulty. At one level you are making a new custom consensus rule and the associated rpc calls. This would take a more experienced coder than just writing interpreted smart contracts. The other level is using the existing CC rpc calls, such coding can be done in any language and is quite a lot easier (and safer!) than writing interpreted smart contracts.
As I have described in my posts, some data structures map directly to the blockchain and directly creates performant solutions. Others will need to be added on top of the existing blockchain by writing the appropriate data to the opreturn or the extra data in the CC vout.
Since any sort of data structure can be used with any sort of algorithm, that allows essentially any type of logic to be inserted into the Custom Consensus (CC) of your blockchain.
