After browser through the docs of Plutus, I don’t find any Plutus API introduce, just some samples project.
I want to find the ability Plutus has, especially the ablitiy to query info from ledger/blockchain. For example, does it provide API to retrieve transaction detail by txHash? Can I get UTXOs list of specified address? Or able to read metadata of UTXO? …
By 'Or able to read metadata of UTXO? ' maybe incorrect. I don’t know if UTXO has metadata, but NFT token bundled inside an UTXO does have metadata.
I actually means is Plutus on-chain code able to get metadata of NFT token?
The plutus code can only see the UTxOs you provide to it when you call it. It is not able to read from information the blockchain.
Would it be worth making a CIP to extend Plutus to read data from the chain?
As a contract developer, absolutely welcome this proposal. But I think it too early to talk about it before reach agreements of most Plutus users.
At the present stage, I just want to find out what it can do and make good use of it.
I was thinking somthing like this I have a draft on it.
Is this what you would like or do you require something different? I want to know if there is a separate CIP that needs writing.
I don’t think it’s feasible to build something like that into Plutus itself.
That would require every node (or at least every block producer) to have cardano-db-sync or something similar running. (And I’d rather think that the requirement to have the whole history of the chain on every node should/will go at some point, because it just becomes too large.)
And they all have to execute it redundantly, which is quite a waste of resources if we do something like database queries in there.
Alternative: Use an oracle that does your query off-chain and puts only the result into your contract.
The main problem I see here is that the off-chain query may be made prior to the contract execution. Let the difference in time be dt, then it follows that if dt is sufficiently large (strictly greater then a) then the data in the contract may be outdated and ensure either the failure of the contract or the wrong result upon execution. Note that such contracts are a subset of the set of all possible contracts C, henceforth known as E.
Here I make the point that dt is a function of the load on the chain and a is dependent upon the nature of the contract such that it varies with each contract which is a member of set E.
All contracts in set E will then fail given a sufficient load on the chain (a superbound on dt known as T). If we did the onchain query we could force the contract to execute right after the query avoiding this. This would have the effect of : E → 0.