Comments 3
Красивая конечно теория!
Что касается массивов
> вы можете совершенно безопасно располагать не менее
элементов данных размером слот в каждом таком массиве
Мне просто стало интересно, сколько будут занимать такие данные, жпт говорит, что это. примерно ~10⁷⁰ гигабайт. Это просто физически невозможно провернуть в Ethereum. Это огромное число.
Что касается маппингов
На сколько я понимаю коллизии могут возникнуть в использовании keccak256, но не mapping, потому что mapping использует хеш(key, slot). Так как для получения коллизии нужен один mapping, в котором два ключа дадут одинаковый хеш.
Но тут у меня вопрос, на сколько симуляция на урезанном адресном пространстве валидно? Симуляция keccak256 на K < 256 битах не отражает реальность, потому что в EVM хеш всегда 256-битный на сколько я понимаю.
На мой взгляд бояться наступления коллизий надо при использовании assembly вставок. Вот там, когда ручками по слотам ходишь легко допустить ошибку.
Мне просто стало интересно, сколько будут занимать такие данные, жпт говорит, что это. примерно ~10⁷⁰ гигабайт.
Разумеется, это огромное число, и это позволяет считать размер этих массивов на практике бесконечным.
коллизии могут возникнуть в использовании keccak256, но не mapping, потому что mapping использует хеш(key, slot)
Так хеш и есть keccak256. Он именно так вычисляется, берется побайтное представление пары (key, slot) и для этого представления вычисляется keccak256.
на сколько симуляция на урезанном адресном пространстве валидна?
Не только на урезанном пространстве, но и на соответственно урезанном keccak. Я рассуждал так: если keccak256 доказанно приводит к максимальной энтропии на своем пространстве значений (то есть иначе говоря, он является в этом смысле хорошей хеш-функцией), то и любая выборка бит из его значения будет также приводить к максимальной энтропии на соответствующем урезанном пространстве значений.
Кстати, использование урезанной выборки бит значения keccak256 является распространенной практикой и в самой EVM. Например, адреса контрактов и индивидуальных счетов тоже являются результатом сходной операции. Вот что мне сообщил MS Copilot:
Адреса индивидуальных счетов (EOA - Externally Owned Accounts) создаются на основе приватного ключа, который затем хешируется с помощью keccak256 для получения публичного ключа. Далее, публичный ключ проходит через keccak256, и берутся его последние 20 байт для формирования адреса.
Адреса контрактов генерируются по другому принципу:address = keccak256(RLP_encoding([sender_address, sender_nonce]))[12:]
Таким образом, любой адрес в Ethereum - это результат выборки последних 20 байт из результата применения keccak256 к какой-то последовательности байт.
Продолжнаем эксперименты, теперь с самим storage https://habr.com/ru/posts/911224/
Надежное программирование в Solidity