My understanding of arrays is that the initial storage point of the array is used to find the beginning of the array, and finding specific items in the array from that point forward require even distribution of elements, as the product of the index number and the size of one element leads to the beginning of the desired element (so if I want bytes32[3], it starts at the storage point and moves ahead 2 x 32 bytes). Also, since the machine "knows" that it is 32 bytes per slot, it knows where to stop reading.

However, in remix, it seems that when creating a bytes[], it allows each element to be of arbitrary length, and even much larger than 32 bytes. Also, readthedocs.io states that bytes is cheaper and is "packed tightly in call data". This suggests that there is no fixed allocation space for each element.

So then, how does this kind of array work, since it cannot be iterated through in the manner described above? And if it is possible to iterate through an array with arbitrary-sized slots, why aren't all arrays made with this versatility?


https://programtheblockchain.com/posts/2018/03/09/understanding-ethereum-smart-contract-storage/ might help.

Specifically, recall that bytes is a dynamically-sized array:

Using reserved slots works well for fixed-size state variables, but it doesn’t work for dynamically-sized arrays and mappings because there’s no way of knowing how many slots to reserve.


Solidity instead uses a hash function to uniformly and repeatably compute locations for dynamically-sized values.

So for an example of bytes[3], find where that would be just like a bytes32[]. At that storage location, you'll find the length of the bytes, but the actual data will be at the hash of that slot.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.