Smart contract ability to query a database

Question

I'm having some concerns while developing a smart contract. As I see, the Ethereum blockchain can be known as a distributed database, where transactions are stored as hashes in a block. A smart contract is the back-end of the DApp. In my scenario, I store data "this is my input" in a block by sending a transaction from accountA to accountB. As I see(Or I missed something)there is no option for me to get that data from the smart contract. Is it because the code for that function not supported by the solidity language, or it is the issue from the EVM, that has no opcodes to retrieve and decode the transaction? I read multiple documents but no one mentioned how smart contracts can get data that is not stored in its own storage.

Regards,

Answer 1

I'm not quite sure if I understood correctly your problem but let's see.

Smart contracts have access to two types of data:

1. Data sent to them and

2. Data they access by calling another smart contract

So a smart contract can't "read" data from a client in that sense. Contracts also can't read data sent between two accounts directly - although such transactions typically don't even contain data.

Answer 2

A smart contract functionality is limited by EVM opcodes available. If there is no opcode for an action it won't be able to directly perform that action.

In this particular case there is no opcode to access other transactions inputs. A contract can only access its own inputs. The opcodes that allow a contract to read the transaction input are: CALLDATALOAD, CALLDATASIZE and CALLDATACOPY.

For many task it is possible to use an oracle to query for additional input.

Answer 3

Contracts solve this.

Each contract has a storage name space (key value store closer to the VM). You use a contract to lay out how you will use the storage and functions to set and get.

The blockchain provides a canonical transaction order and consensus, so if foo == "bar", it's because something made it so, a.k.a. a transaction.

You don't generally need to worry about the block that set it, because the current state is usually what you want. The underlying chain ensures it isn't misrepresenting, hasn't been tampered with, etc.

contract SetGet {

  string private foo;

  function setFoo(string calldata input) public {
     foo = input;
  }

  function getFoo() public view returns (string memory) {
     return foo;
  }
}

Hope it helps.