There is no support for logging binary data in Solidity.
In Solidity, events can be reported. These look like structures with zero or more fields, and can be emitted with specific values. For example:
Events are write-only from a Solidity/VM perspective and are written to the blocks in the tx records.
Some of these fields can be marked
indexed, which affects how the data is
encoded. All non-indexed fields are eth abi encoded into a variable length
byte array. All indexed fields go into so-called topics.
Topics are fixed length fields of 32 bytes. There are a maximum of 4 topics; if a type does not always fit into 32 bytes (e.g. string types), then the topic is keccak256 hashed.
The first topic is a keccak256 hash of the event signature, in this case
keccak256('PaymentReceived(address,uint)'). The four remaining are available
indexed fields. The event may be declared
anonymous, in which case
the first field is not a hash of the signature, and it is permitted to have
4 indexed fields.
The reason for the distinction between topics/indexed and regular fields is that it easier to filter on topics.
In order to decode the non-indexed fields (the data), the abi of the contract is needed. So, the topic is first used to discover what event was used, and then the data can be decoded.
The transaction calls event logs. Here is a tx with a single event, with 3 topics and some data.
In Ethereum, events are stored in blocks. Events mark certain state changes in smart contracts. This serves two purposes:
- Listen to events (i.e. state changes) as they happen by reading new blocks as they are published
- Re-read historical events by reading old blocks
So for example, smart contracts may emit changes as they happen but never the complete state, so the only way to recover the entire state of the contract is by re-reading all events from the chain. So an application will read events from block 1 or whatever block the application was deployed at and then use that state for local processing. This is a local cache and may re-populated from the chain at any point.
Binary logging should be added to the program log. The program log should include the base64 encoded data (zero or more one permitted).
So if we encoding the topics first, followed by the data then the event in the tx above would look like:
This requires a new system call:
- Should there be text field in the program log so we can have a little bit of metadata on the binary data, to make it more human readable