🤑 Казалось бы, что сложного в ставке на событие?

За более чем три года коммерческой разработки под TON у меня накопилось достаточно проектов, чтобы уже довольно быстро понимать, где будет настоящая сложность.

Но иногда открываешь задачу, смотришь на нее и думаешь: «Ну, здесь вроде ничего сверхъестественного».

Так было с одним из проектов, где нужно было сделать смарт-контракт с механикой, похожей на Polymarket.

Есть событие. Пользователи выбирают исход и вносят деньги. Событие заканчивается — определяется победивший исход, после чего участники получают свой выигрыш.

На бумаге – несколько понятных действий.

А потом начинаешь проектировать это в TON.

И вот здесь начинается самое интересное.

TON работает на акторной модели, поэтому привычная логика «есть один контракт, у него есть общее состояние, сейчас мы его изменим, потом посчитаем всё остальное» уже не работает так, как привыкли многие разработчики.

Состояние распределено. Контракты взаимодействуют сообщениями. Операции становятся асинхронными. Нужно заранее думать не только о том, что должно произойти, но и о том, какие сообщения, в какой последовательности и между какими контрактами должны пройти, чтобы система пришла в нужное состояние.

А теперь добавим сюда ставки нескольких пользователей, разные исходы, расчёт долей, завершение события и распределение выигрышей.

И в какой-то момент становится понятно, что самая сложная часть здесь вообще не формула выигрыша.

Самая сложная часть — правильно разложить саму бизнес-логику на взаимодействия между акторами.

Это хороший пример того, почему опыт в блокчейне — это не только знание языка или умение написать очередной smart contract.

Иногда ты приходишь к задаче с уже знакомой бизнес-моделью, но сама архитектура сети заставляет тебя полностью переосмыслить способ её реализации.

И, пожалуй, именно такие проекты я больше всего ценю в своем опыте работы с TON.

Потому что после них ты уже не просто знаешь, как написать контракт.

Ты лучше понимаешь, как думать о системе целиком.

@dnevnik_ton