Every smart contract deployed into Ethereum blockchain has its own personal database, known as smart contract storage. This database is able to store 32-byte values addressed by 32-byte keys. Smart contract may write into its storage via
SSTORE opcode and read from it via
Each Ethereum node, excluding so called "light" nodes, maintains a large database holding blockchain data. Basically, this data consists of two parts: block data, and blockchain state.
First part, i.e. block data, is basically a collection of all live blocks ever mined. Live block is a block that is part of a blockchain, i.e. that wasn't dropped during chain reorganization. Nodes download blocks from each other, so this information is easily available to everyone. Each block contains an ordered list of transactions, and, as long as blocks are ordered themselves, block data could be considered as one big log of all transactions every executed in Ethereum.
Second part, i.e. blockchain state, is basically a result of applying all the transaction in proper order to the well-known initial state. Blockchain state contains information such as account balances, byte code of deployed smart contracts, and, among other things, storage of all live smart contracts.
Each block includes hash of blockchain state as it should be after applying all the transactions from this block. Thus, each node may validate new block by applying block's transaction to the blockchain state corresponding to the previous block, calculating hash of the resulting blockchain state, and comparing to the hash included into the new block. This guarantees that all nodes execute all transactions in the same way, even if they use different software.
Usually, nodes do not directly exchange blockchain state, but in "fast" synchronization mode node is able to download snapshot of blockchain state from other nodes. Though, this happens only once, when "fast" node initializes its database.
So for your questions:
- Smart contract stores data in its own private part of blockchain state, every non-light node has a copy of this state, and, while usually not directly exchanging blockchain states, nodes use hashes to make sure their copies of blockchain state are in sync.
- When smart contract accesses its state variable, node, that executes corresponding transaction, reads value of this variable from local copy of blockchain state.
- Blockchain state is organized as a so called Merkle Patricia tree, where path from root to the leaf defines Ethereum address, and leaf data contains address state. For smart contract addresses, leaf data contains current balance, nonce, smart contract byte code, and a reference to a separate Merkle Patricia tree holding storage of this smart contract. In this another Merke Patricia tree, path from root to leaf defines 32-byte key, and leaf data is a 32-bit value.