@cwgoes @vveiln – doing DB research rn in a separate effort and stumbled upon this
had a brain worm I wanted to shoot y’alls way
It’s just a rough high-level idea regarding the stored data format for resources to query in the resource machine (the heirarchical index mentioned) – no idea about implementation or feasibility on any proper time horizons but nonetheless thought it might be interesting so
– at a high level (if I understand the idea correctly of what role the heirarchical tree serves), this problem sounds earily similar to the development of elasticsearch style databases that were developed in the case of small text to query large data that have any number of variable relations. These DBs work with a user provides a small amount of data and the DB should return the most relevant results ranked in the proper order from a huge amount of data. It’s similar to a document oriented DB where you have a document index and you add a bunch of data objects to it – under the hood the DB will analyze all the text in the data objects and create an index of the searchable terms
In the case of the stored data format of predicates/intents/resource machine matching/resource machine execution for efficient queries – it seems similar in nature if you just look at predicates/intents/resource machine matching query piece. A user provides a (potentially small) predicate with an intent with some resource specs and the anoma resource machine should return the most relevant intent/resource machine matching ranked in the proper order from a huge amount of various intents, resources and execution paths available. It’s similar to a document oriented DB where you have a document index – the predicate – and you add a bunch of data objects to it – the intent specs – and under the hood the DB will analyze all the text in the data objects and create an index of the most relevant predicates, intents, resources, and execution paths.
You should be able to prove a struct like this using known methods for proving VM execution traces