Существует ли (теоретический) предел объема данных, которые может хранить контракт?

Существует ли теоретический предел объема данных, которые может хранить один контракт при работе в частной сети, в которой газ не вызывает беспокойства?

Контекст: в финансовом Dapp, который должен заменить глобальные платежные системы, пропускная способность tx/s, безусловно, является одним из широко обсуждаемых ограничивающих факторов. Но я не об этом. Может ли контракт хранить 1 ГБ, 1 ТБ, ... данных в контракте? Данные не будут записываться за один раз, а будут накапливаться с течением времени.

Пример: предположим, что в лучшем случае нам удается уместить одну транзакцию токенов, находящихся поверх смарт-контракта, в 100 байт. При пропускной способности 1000 операций в секунду это даст 100*1000*3600*24*31*12 = 3,2 ТБ/год. Не стесняйтесь гадать, если / когда это будет возможно.

Вы на 100% уверены, что вам нужно хранить все эти записи вечно? Если речь идет об общении между сторонами, использование сообщений Whisper может быть лучше. Другой вариант — сохранить 32-байтовый хеш, который указывает на реальные данные в Swarm или IPFS и т. д.
Хороший вопрос, я совершенно уверен, что они мне не нужны на всю вечность, просто пытаюсь понять основы. Я уверен, что изначально мне нужны все эти записи, но было бы здорово иметь возможность перемещать их в IPFS после N блоков, например, после типичного периода аудита в один год. Кажется сложным реализовать это в контракте без централизации прямо сейчас (перейдите из блокчейна в IPFS и убедитесь, что нужные вещи теперь в IPFS).

Ответы (2)

Хранилище контракта — это ключ размером 32 байта и значение 32 байта, поэтому максимальный объем, который может хранить один контракт, составляет около 1,46 ГБ (32^32).

ЛОЖЬ. Существует 2^256 различных ключей, и каждый ключ может хранить 32 байта, так что всего можно сохранить 2^261 байт. Тем не менее, к тому времени блокчейн Ethereum, вероятно, сломается из-за коллизии хэшей....

Спасибо, я обновил и исправлю свой комментарий здесь ethereum.stackexchange.com/questions/986/…
Что вы имеете в виду break, не выйдет ли из строя весь блокчейн? Нет ли проверки на дубликаты хэшей? Придется ли перематывать/переделывать транзакцию до тех пор, пока не произойдет коллизия?
@BlockChange Если будут обнаружены повторяющиеся хэши, возникнут гораздо более серьезные проблемы, потому что это будет означать, что алгоритм хеширования был нарушен. Для справки: для @2^261, если предположить, что вы можете вычислить 1 хеш в пикосекунду, вам все равно потребуется больше времени, чем у нас есть до тепловой смерти Вселенной, чтобы найти подобный конфликт, если только алгоритм хеширования не сломан.
2 ^ 261 = # байт, которые можно хранить с 2 ^ 256 адресами, каждый из которых хранит 2 ^ 5 (= 32) байт. Это не имеет ничего общего с алгоритмом хеширования. Используемый алгоритм хеширования — это 256-битный хэш Keccak, дающий 2^256 возможных значений хеш-функции, но вам не придется ждать до последнего, чтобы произошло столкновение. Вспомните проблему дня рождения (также известную как парадокс дня рождения). Вероятность столкновения > 99% после 2^130 значений. С 2 ^ 160 из этих значений в качестве адресов 2 ^ 160 контрактов, P (коллизия) > 99,999999.... % (не знаю, сколько 9 после запятой)
@Earlz - Дело в том, что в тысячелетии (1000 лет) около 2 ^ 35 секунд. Таким образом, при скорости создания 1 контракта в секунду потребуется 2 ^ 125 тысячелетий, чтобы создать 2 ^ 160 контрактов. Получение коллизий задолго до этого НЕ означает, что алгоритм хеширования «сломан».
это не может быть буквально 2 ^ 261 в реальной реализации, верно? Он не может представить, что это физически возможно. Разве мы не должны по модулю хешировать реальный размер хранилища? В таком случае, каков этот реальный размер хранилища?

Хранилище контракта — это ключ размером 32 байта и значение 32 байта, поэтому максимум, который может хранить один контракт, составляет около 2^261 байт (2^256 * 32b).

В частной цепочке, где газ не вызывает беспокойства, поскольку адресное пространство составляет 160 бит, при условии, что его можно использовать все, можно создать 2 ^ 160 контрактов. Таким образом, теоретически около 2 ^ 421 байт — это максимум, который могут хранить контракты.

Вы столкнетесь с коллизиями хэшей задолго до того, как создадите 2^160 контрактов; 2 ^ 80, вероятно, более разумная оценка.
Почему может возникнуть хеш-коллизия после создания 2 ^ 80 контрактов? @Ник Джонсон
Может ли значение ключа structбыть больше 32 байт? @эт♦
@Alper Ключи хранилища контрактов могут быть только 32 байта.
Существует ли (теоретический) предел объема данных, которые может хранить контракт?
СпросиСетьПолитика конфиденциальности1y, 0v