I don't think your question is unclear (someone flagged it) but it's pretty far off from the way Ethereum works conceptually. Let's start with the big one.
Everything in Ethereum is deterministic, meaning it is possible to verify correctness. In fact, it must be possible for every node to verify every computation now, and in the future. Consider this function:
function adder(uint x, uint y) public pure return(uint sum) {
return x+y;
}
There's no problem here because we can say that for any given pair of inputs, the result will always be the same. We can even scribble down the result for later:
uint public z;
function adder(uint x, uint y) public {
z = x + y;
}
We'll have an immutable history of all transactions sent to the function and the value of z
will be the only thing it can possibly be given the transaction history (that all the nodes agree on).
In case that isn't clear, history would look something like:
- Alice deployed a contract and it got address
0x123...
- Somebody sent a transaction to
0x123...
with (2,3)
. That has a transaction hash that became part of the canonical chain. Everyone agrees it happened.
- Someone else decided to inspect
z()
at 0x123
and the response was 5
and everyone can see that this is the only possible outcome, given the history.
What's not so obvious is that it's fundamentally impossible to create to a function that inspects the outside world. If we did that, say ... to check the response from an API, how could we possibly know that a given API will always return the same value as it does right now? We can't. So that would make it impossible for another node to verify the blockchain in the future. How is that different from the (2,3)
in the earlier example? Someone signed the transaction with (2,3)
.
Hmmm ...kay, but checking the outside world is useful.
One solution to this problem is to use an Oracle pattern. Generally, this means that a trusted account will inject some information (today's weather, a stock quote, something else ...) and sign the message. Importantly, the blockchain does not (cannot) verify the accuracy of that input. The network does verify the signature. Any node (in the future) will be able to verify that the Oracle said it was 37 degrees today. The information finds its way into the contract by way of a signed transaction.
For more on Oracles: How do oracle services work under the hood?
This is a well-established pattern. In your case, the solution might be to give the custodian of the "secret" information privileges in the contract. For example, the priviledge of acting on information no one else has.
Another solution that is admittedly more experimental and not especially easy to grasp is the idea of using Zero-Knowledge Proofs. You can find a simplified description over here to consider if that might be what you're looking for: https://medium.com/@robhitchens/selective-disclosure-with-proof-f6a1ac7be978
Hope it helps.