🔥 Смотрим на костыли. Часть 1.

В прошлом посте мы рассказывали про config блокчейна, какая информация там хранится. Одно из полей в конфиге отвечает за все стандартные значения, связанные с тратой газа. Gas price — стоимость 1 единицы газа в nanoTON (на данный момент это 400). Gas limit — максимальное количество газа, которое может потратить контракт (на данный момент это 1 000 000 газа или 0.4 TON).

Параметр gas limit можно поменять внутри контракта с помощью TVM опкода SETGASLIMIT (в tolk функция setGasLimit), но есть нюанс — только в меньшую сторону. Установить gas limit больше миллиона невозможно.

Но нет ничего невозможного! В ноде блокчейна есть отдельные адреса, для которых этот параметр увеличен. Для этого даже устраивали голосование валидаторов (нашлось только это), и это зафиксировано в коде ноды (обратите внимание на номер строки). Как можно заметить по коду, время этих увеличенных параметров вышло 9 месяцев назад, но код пока что остается, хоть и, вероятно, уже не работает (UPD код остаётся для валидации блоков от самого начала блокчейна).

Вот, например, контракт потратил на трансфер 20 000 000 газа (или 83 TON).

Про gas limit понятно, а что насчет gas price? Их есть у нас. В 31 параметре config TON блокчейна есть отдельные адреса, для которых gas price обнулён. Это означает, что эти контракты исполняются бесплатно. Понятно, зачем это нужно — всякие системные контракты лежат в мастерчейне, и их регулярные вызовы (например, tick-tock на Elector контракте) требуют много TON.

Многие задавались вопросом — зачем tgBTC нужно было менять что-то в config блокчейна? Ответ — они обнулили gas_price для своего адреса. Вот пример транзакции tgBTC (не трансфер жетонов), которая не потратила газ (все значения равны 0, мечта!).

Следим.
@TheOpenDevBlog

🔥 Как вообще ваше настроение, девы?

Давно не было постов, но скоро будут, писать есть о чем.
@TheOpenDevBlog

🔥 Что для вас девелоперское событие года в TON?

Устроим мини премию @TheOpenDevBlog

🔥 Подходит к концу 2025 год.

Спасибо всем, кто был тут с нами, участвовал в дискуссиях, приносил инсайды, ставил реакции. Нас почти 1000!

В новом году желаем вам самых крутых инсайтов, самых крутых профессиональных успехов, и самых крутых идей! Мы постараемся помочь.

🎄 С любовью, ваш
@TheOpenDevBlog

🔥 Nonce в каждый дом.

Практически каждый, кто когда-то писал смарт контракты, знаком с концепцией nonce. Каждый пользователь TON хоть раз, но использовал nonce, встроенный в контракт wallet w5/v4/v3.

Nonce — это (обычно) некоторая информация, которая делает уникальным каждое исполнение подписанного offchain ордера в контракте. Это нужно для того, чтобы контракт нельзя было переиспользовать — например, чтобы нельзя было взять ваш свап на @bidask, отправить его снова, и заставить ваш кошелек произвести свап заново.

Обычно все представляют nonce как одно число, которое увеличивается на 1 при исполнении ордера. Однако такая концепция обладает проблемой (вы, возможно, с ней сталкивались) — в таком случае ордера должны быть обязательно исполнены последовательно один за другим, в строго определённом порядке. На пользовательских кошельках в TON могут пропадать транзакции, если быстро исполнить два действия подряд — второе действие может попасть валидатору перед первым, или же у обоих действий будет одинаковый nonce — тогда одно исполнится, а второе пропадёт, ведь nonce в контракте и ордере не совпадут. Ходят слухи, что это хотят исправить.

Для борьбы с этой проблемой существует множество концепций nonce. Расскажем про некоторые:
⚫️В @bidask в trade account-ах реализована система с 16 параллельными nonce-ами. Кроме числа, пользователь также должен приложить к ордеру номер nonce от 0 до 15 — и именно этот nonce будет увеличен на 1 после исполнения ордера. Это позволяет отправлять в любой последовательности
⚫️В TON существует highload wallet. Он сохраняет query_id пришедшего ордера и дедлайн, когда этот ордер перестанет быть валиден. Как только этот дедлайн истекает, он чистит сохранённые query_id, разумно считая, что все ранее исполненные ордера истекли. Таким образом он поддерживает гигантское количество параллельных транзакций — им пользуются CEX и многие сервисы, централизованно взаимодействующие с блокчейном.
⚫️На EVM блокчейнах есть и более экзотические варианты nonce. Совсем недавно его предложили хранить как двойной map { address => {uint256 => uint256}}. Каждому адресу юзера здесь сопоставляется map {uint256 => uint256}. Когда на такой контракт приходит ордер с nonce, контракт берет map по адресу юзера, и извлекает из от nonce два значения:

word = nonce / X;
bitIndex = nonce % X;
// X -- это некоторое число (256 или 64)

Переменная word является ключом, а bitIndex — индекс бита в числе, который, по задумке, является нулевым битом (после исполнения ордера станет равным 1). Таким образом, nonce позволяет исполнять огромное количество параллельных ордеров, являясь bitmap-ом. Подробнее можно почитать тут.

Вариантов nonce очень много — нужно просто понять, для чего он нужен в конкретном случае.

🎄 С новым годом.
@TheOpenDevBlog