Additional Option: Get Turing result not in the same TX (async)

[wsdt]

Having a specific "use-case" in mind, which might be interesting marketing wise and from a scientific standpoint. But this would require Turing to be able to make calls which may take e.g. 600 seconds.

Nevertheless, as discussed with @InoMurko having that option could also solve future scaling problems. Some snippets for more context from our conversation:

• Ino: so now we do it inside estimateGas RPC call . it could be longer, but the implications to geth are unknown. so if you’re not in california (your API) having just 1200 latency is going to be problematic
• Kevin: true that, nevertheless it would just cover one more spectrum of the universe + the scaling issue. Just as an option, the call per tx is really useful, but having the option for greater calculations might have interesting implications.
• Ino: yeah sure it makes sense. having an RPC endpoint to request data + proof of payment and async data push

@jliphard @souradeep-das @InoMurko Opinions?

[souradeep-das]

interesting! just a thought - for implementing (or adding the option of) an async push oracle, should we be relying on Turing- (in turn l2geth changes) or should we have architecture along the lines of common l1 oracles like chainlink, band? it of course might be sensible though to add this as an option - since we already have turing

[wsdt]

Best practice/low hanging fruit probably would be to just try to onboard ChainLink on Boba, but this wouldn't drive the Boba ecosystem by definition and would weaken the Turing use-case.

Nevertheless, before we go for an own architecture like ChainLink, I think it would be from a cost-to-revenue ratio more profitable to just onboard the real ChainLink on Boba.

Doing l2geth changes for sure has the highest technical risk, but probably is the best middle way in terms of growing the Boba ecosystem, technical use case and actual amount of hours needed to add that option.

Just my 2 cents :)