From bae913368a438b2de7f3be93618feb21e155055e Mon Sep 17 00:00:00 2001 From: Steve Waldman Date: Tue, 19 Dec 2017 01:44:33 -0800 Subject: [Docs] Include explanation of how indexed dynamic-length event args are encoded --- docs/abi-spec.rst | 2 ++ 1 file changed, 2 insertions(+) (limited to 'docs') diff --git a/docs/abi-spec.rst b/docs/abi-spec.rst index e106d98b..458c4ce0 100644 --- a/docs/abi-spec.rst +++ b/docs/abi-spec.rst @@ -288,6 +288,8 @@ In effect, a log entry using this ABI is described as: - ``topics[n]``: ``EVENT_INDEXED_ARGS[n - 1]`` (``EVENT_INDEXED_ARGS`` is the series of ``EVENT_ARGS`` that are indexed); - ``data``: ``abi_serialise(EVENT_NON_INDEXED_ARGS)`` (``EVENT_NON_INDEXED_ARGS`` is the series of ``EVENT_ARGS`` that are not indexed, ``abi_serialise`` is the ABI serialisation function used for returning a series of typed values from a function, as described above). +For all fixed-length Solidity types, the ``EVENT_INDEXED_ARGS`` array contains the 32-byte encoded value directly. However, for *types of dynamic length*, which include ``string``, ``bytes``, and arrays, ``EVENT_INDEXED_ARGS`` will contain the *Keccak hash* of the encoded value, rather than the encoded value directly. This allows applications to efficiently query for values of dynamic-length types (by setting the hash of the encoded value as the topic), but leaves applications unable to decode indexed values they have not queried for. For dynamic-length types, application developers face a trade-off between fast search for predetermined values (if the argument is indexed) and legibility of arbitrary values (which requires that the arguments not be indexed). + JSON ==== -- cgit v1.2.3