(Запрещено создание своих обучающих материалов на основе этого без разрешения автора)
Распределённое программирование
Как же выживают контракты и программисты в ES? :-) А они не пишут контракты, где стейт может бесконечно расти, а пишут распределенные системы смарт-контрактов. И в этом им помогают концепции, реализованные в ES. Например, tip-3 токен (местная распределенная альтрельнатива erc20) создаёт отдельный контракт на каждого владельца токена (такой wallet для токена), и можно пересылать токены напрямую между контрактами без центрального узла. Ниже мы рассмотрим пример, чтобы понять как это работает.
Важный концепт
В ES адрес контракта - однозначно вычисляемое значение. Адрес контракта - это хеш от кода контракта и начальных данных. (Начальные данные - это значения static переменных, а не то, что Вы передаете в конструктор, так как в ES конструктор - это функция которую Вы вызываете уже после деплоя контракта, но в одну транзакцию).
Это очень важный паттерн распределенного программирования (как его понимают в ES). Точно зная, какой код у контракта, и зная его начальные данные, Вы,например, можете проверить, что Вас вызывает контракт такой же, как Вы, задеплоенный одним и тем же родителем. Или, зная код контракта, и какие у него должны быть начальные данные, Вы можете на лету вычислять адрес контракта и посылать ему сообщения.
Рассмотрим максимально упрощённую реализацию tip-3 токена.
Наш токен состоит из двух контрактов:
Root.sol управляется тем кто выпустил токены, позволяет их допечатывать и деплоить Кошельки отдельных пользователей.
Wallet.sol это контракт кошелька отдельного пользователя. Да, у каждого пользователя есть свой маленький контракт где хранится его баланс этого токена.
Создавая отдельный контракт - кошелек мы решаем сразу несколько проблем:
Все кошельки попадают в разные шарды, и тем самым нагрузка на сеть от переводов равномерно распределяется по всей сети.
Контракты - кошельки очень маленькие и с маленьким стейтам. Валидаторы могут очень быстро загружать их с диска.
Плата за хранение. Если бы у нас был один контракт, с огромной хеш мапой, то он бы должен был бы платить большую плату за свое хранение, и не понятно кто и как должен оплачивать это хранение. Если там много балансов со сдачей, которая уже не нужна своим владельцам, то они естественно не будут платить за ее хранение, и оплачивать их “остатки” придется остальным держателям этого токена.
Чтобы программистам смарт контрактов не думать о том, как заставлять пользователей оплачивать хранение(чтобы весь контракт не был заморожен) или чистить старые данные внутри контракта, мы просто деплоим каждому пользователю его отдельный контракт.
Каждый пользователь сам решает на какой срок оплачивать его хранение, и всегда может пополнить его.