when a user sends a transaction
to define the access control of a resource to a device s1,then it will be executed by smart contract and the result of the transaction is stored in the storage file of the smart contract (i.e. access control to the resource s1 is r, x, w), and the transaction input (i.e. from, to, data, sign, etc) will be included in the blockchain after mining.
I struck out parts of the question that are just too confusing to unpack.
The transaction goes
from: user and
to: contractAddress with
data: functionAndArguments. The contract does what it is programmed to do with that input. This can include mutations of data stored in the contract state.
What I would like to know for example: when a device s2
wants to know the access of the control to the resource of s1, is s1 will contact the nearest miner and the miner looks in the blockchain (contains the transaction inputs) and sends the answer to s1 or s1 can directly contact the smart contract which has the result of the transaction execution in its storage file?
None of that.
You need to avoid phrases like "access the control of the resource" because it's impossible to know what you mean.
If s2 is curious about the data in the contract, it will consult its own copy of the blockchain and inspect a contract function to read it. This is regardless of who/what wrote to the contract before because all copies of the blockchain are the same for all nodes. It is reliably replicated across all nodes, so s2 doesn't need any help.
Blockchain is a data structure and everyone has the same data. Ethereum is a protocol that strictly constrains permissible changes to the structure, while also permitting deterministic programs to run.
There are deployment and topology options that add variance. For example, light clients that depend on others because they are incapable of running a node themselves. You should clarify your question so we know if you want a focus on the logical data flow, contract design, a specific use-case or implementation topology.
Where I can find the response in the blockchain (transaction inputs) or storage
file in smart contract (result of the transaction)?
Most smart contracts will emit events for important state changes. Interested observers can subscribe to those event logs which is, itself, a very good reason to include them in smart contract code.
An observer can also inspect read-only functions that will return values. This is, itself, a good reason to include functions in the code that make the state completely discoverable.
Both of these methods depend on the contract code. The code prescribes the methods of interacting with the contract, e.g. functions to set and get.
Hope it helps.