A block is a well-ordered set of transactions that are plainly readable, as well as header information containing metadata such as the previous block hash for block ordering purposes. I should mention that a single block is insufficient to confirm the authenticity of the block itself.
Transactions contain some fields (partial list) such as from
, to
, amount
and data
. from
is an address that signed the transaction and amount
is ETH sent. Those are plain to see. A single block is insufficient to interpret to
and data
in every case.
to
may be a contract. Without knowledge of what the contract does (the code), this is ambiguous, but it is sufficient to catch transactions directed to a particular address. data
is also ambiguous because it gains meaning through interpretation by the receiver. The first 4 bytes may be a function signature if the transaction is directed to a contract. The remaining n bytes correspond to a field layout defined in a contract function. This will be hard to interpret in every case without the knowledge of the to
contract. In an idealized form, that knowledge comes from interpreting a previous block that contains a deployment transaction with bytecode (roughly, to: 0x0, data: bytecode
) for the contract of interest.
If one is interested in a narrow band of contracts (say, ERC20 token transfers), then one does indeed "have knowledge of the contract" - the function signatures and field layouts.
Some contracts will deliberately obfuscate data
by encrypting client-side before data is sent to a blockchain precisely because plain data is readable by everyone.
Hope it helps.