📝 Теперь вы знаете:
- TON гарантирует, что он может масштабироваться до детализации отдельных контрактов.
- Монолитные кошельковые контракты от Ethereum на блокчейне TON должны реализовываться по-другому ради скорости, масштабируемости и экономии газа.
- Избегайте передачи данных переменной длины в качестве первого приоритета.
- Если у вас должен быть список, то, по крайней мере, сделайте его коротким и ограниченным, как статически определенный.
- Доменное имя TON DNS - это коллекционный невзаимозаменяемый токен, который может иметь произвольное количество связанных с ним дополнительных записей.
- Масштабируемый способ создания больших списков или словарей данных в TON заключается в использовании самого блокчейна в качестве массива.
- Токены в TON разработаны таким образом, что существует один контракт minter, но этот контракт не хранит список всех своих пользователей. Вместо этого он уполномочен чеканить и создавать токены для других пользователей, а балансы отдельных пользователей распределяются в так называемых кошельках Jettons.
📚Чтение Заметок
Давайте поговорим о масштабируемости.
💎 В TON у вас действительно есть очень конкретная гарантия масштабируемости. TON гарантирует вам, что он может уменьшиться до детализации отдельных контрактов.
ThereFore, операции по одному контракту не создадут узкого места 🍼 для операций по другому контракту. И тогда сеть TON, очевидно, позаботится обо всей маршрутизации сообщений 🚅 между ними.
❗Ваша работа - использовать преимущества всей масштабируемости блокчейна и не создавать узкие места в своих собственных контрактах!
Проблемы с монолитными контрактами.
Одна из очевидных проблем для людей, которые приходят из традиционных систем, крупномасштабных веб-баз данных или из Ethereum, заключается в том, что они проектируют свои контракты как монолитные приложения с собственным хранилищем переменной длины.
🌐 Например, в Ethereum токен реализован в виде банковской книги, где у вас есть один смарт-контракт, который содержит список счетов. А затем, если у вас есть миллион пользователей, этот список будет длиной в миллион строк. И для каждого пользователя будет запись, в которой будет указан адрес пользователя. И каков их баланс. И тогда разработка таких контрактов довольно проста и понятна. У вас есть атомные транзакции, вы вычитаете из одного баланса и добавляете к другому. И очень легко спроектировать и увидеть, как будет работать система.
Тем не менее, эта модель не будет масштабироваться в TON, потому что вы поместите этот длинный список в один контракт, и вы немедленно столкнетесь с проблемами.
- 1️⃣Во-первых, у вас будет постепенно растущая стоимость аренды за все эти данные, которые вы храните в своем контракте. 💸
- 2️⃣Во-вторых, каждый раз, когда пользователь приходит и хочет совершить операцию с этим контрактом, ему придется платить все большие и большие транзакционные сборы, потому что они будут работать с большим количеством данных в контракте. 🌄
Правила.
Чтобы помочь вам, дать вам руководство о том, как правильно проектировать многопользовательские и крупномасштабные приложения и TON, есть некоторые правила. 📰
❗ Избегайте наличия данных переменной длины.
❗ Если у вас должен быть список, то, по крайней мере, сделайте его коротким и ограниченным, как статически определенным.
❗ Если вам нужен список, и он должен динамично расти, то, по крайней мере, убедитесь, что этот контракт принадлежит одному пользователю, и они имеют исключительное право контролировать его хранение. Простым примером являются записи в элементах DNS TON.
Blockchcain как массив.
Масштабируемый способ создания больших списков или словарей данных в TON заключается в использовании самого блокчейна в качестве массива. Вот простой пример.
Вы можете представить себе систему, в которой у вас есть несколько контрактов, которые связаны 📌 друг с другом, и каждый пользователь заботится о своем индивидуальном контракте. И вам не нужно хранить весь список в центральной части приложения.
💎 Самым популярным примером реализации этой идеи является дизайн токенов в экосистеме TON. Балансы отдельных пользователей распределяются по так называемым кошелькам Jetton. 🔥 Что круто в этом, так это то, что операции между двумя кошельками Jeton в одном месте не мешают операциям двух других в другом месте, и они могут быть распределены между отдельными цепями и не создавать никаких узких мест.
