• Последние
  • Feed подписок
  • Категории
  • Метки
  • Популярные
  • Пользователи
  • Группы
  • Telegram chat
    • TON WIKI
    • TON Archive
    • TONpie Chats
    • ANP system
    • indicaton.io
Theme Center
  • Theme Center
  • default

  • reset theme
Collapse

tonpie.io

Подпишись на канал фаундера и разработчика экосистемы tonpie

Как правильно разобрать полный график сообщений для вызова смарт-контракта?

Запланировано Прикреплена Закрыта Перенесена TON Overflow на русском
a-ton-api-v4
2 Сообщения 1 Posters 45 Просмотры
    • Сначала старые
    • Сначала новые
    • По количеству голосов
Ответить
  • Ответить, создав новую тему
Авторизуйтесь, чтобы ответить
Эта тема была удалена. Только пользователи с правом управления темами могут её видеть.
  • AnswersA Не в сети
    AnswersA Не в сети
    Answers
    написал в отредактировано
    #1

    Привет всем

    Я пытаюсь понять логику работы API v4. В общем, у меня есть цель получить полный график сообщений для какого-нибудь вызова по смарт-контракту.

    Я использую следующий алгоритм:

    1. У меня есть TonClient4 и мой адрес; 1. Получить информацию о последнем блоке: const lastBlockInfo = ожидание клиента.getLastBlock(); 2. Получить учетную запись в этом блоке: const AccountInfo = ожидание клиента.getAccount(lastBlockInfo.last.seqno, адрес); 3. Получить транзакции по счету: const accountTransactions = ожидание клиента.getAccountTransactions(адрес, BigInt(accountInfo.account.last.lt ), Buffer.from(AccountInfo.account.last.hash, 'base64')); 4. Из списка транзакций я получаю любую транзакцию, например пример этого индекса=1: const targetTransaction = accountTransactions[1];

    Существует два поля: targetTransaction.tx и targetTransaction.блокировать. В поле targetTransaction.tx есть поле targetTransaction.tx.InMessage. Если тип этого сообщения "внутренний", я должен найти "родительское" сообщение этого сообщения. Но, похоже, у меня есть только адрес источника этого сообщения и его логическое время. Итак, мне нужно получить список транзакций исходной учетной записи и в этом списке найти транзакцию, которая имеет outMessage с тем же логическим временем. Но для этого я должен вызвать client.getAccount(???, targetTransaction.tx.InMessage.src) - здесь ??? - это номер квартала. Конечно, я могу использовать lastBlockInfo.last.seqno, но это не универсальное решение для исторических сообщений. Сначала я подумал, что могу использовать targetTransaction.block.seqno, но, как я понимаю, это номер блока в workchain=0, но для метода getAccount требуется номер блока в workchain=-1;

    Я решил проверить метод getBlockByUtime: const blockByTime = ожидание клиента.getBlockByUtime(targetTransaction.tx.InMessage.info.createdAt); В результате я вижу два сегмента: один для workchain=0 и один для workchain=-1. Кажется, что можно использовать seqno из shard с workchain=-1, но я удивлен, что для workchain=0 Я вижу номер блока, не равный targetTransaction.block.seqno, но предыдущий.

    Итак, с этого момента у меня есть вопросы:

    1. Действительно ли так сложно получить родительское сообщение, или я пропустил какой-то метод или что-то еще? 2. Насколько я могу доверять методу "getBlockByUtime"? Возможно ли, что в течение некоторого времени unix я буду (не получать блок) /(получать следующий блок)/(любые варианты)?

    Спасибо за ваше внимание. Я буду благодарен за любую помощь.


    Оригинал вопроса

    1 ответ Последний ответ
    0
  • AnswersA Не в сети
    AnswersA Не в сети
    Answers
    написал в отредактировано
    #2

    1/ Действительно ли так сложно получить родительское сообщение, или я пропустил какой-то метод или что-то еще?

    => Это выходит за рамки моих знаний.

    2/ Насколько я могу доверять методу getBlockByUtime? Возможно ли, что в течение некоторого времени unix я буду (не получать блок) /(получать следующий блок)/(любые варианты)?

    => getBlockByUtime - это метод, используемый для извлечения блока, который был создан ближе всего к заданному времени в Unix. Это не на 100% точно из-за того, что время блокировки в протоколе строго не регламентировано, а также из-за задержки в сети и других факторов.

    Таким образом, хотя вы обычно можете доверять getBlockByUtime, чтобы он выдал вам блок, близкий к указанному времени Unix, вы не должны полагаться на то, что он предоставит совершенно точный блок для точного момента времени. Всегда рекомендуется обрабатывать крайние случаи, когда вы можете не получить блок или получить последующий блок.

    ** Также обратите внимание, что этот метод может возвращать блоки из разных цепочек блоков за одно и то же время, поскольку разные цепочки блоков - это, по сути, отдельные цепочки блоков, работающие параллельно.**

    1 ответ Последний ответ
    0

  • Войти

  • Нет учётной записи? Зарегистрироваться

  • Login or register to search.
  • Первое сообщение
    Последнее сообщение
0
  • Последние
  • Feed подписок
  • Категории
  • Метки
  • Популярные
  • Пользователи
  • Группы
  • Telegram chat
    • TON WIKI
    • TON Archive
    • TONpie Chats
    • ANP system
    • indicaton.io
  • Войти

  • Нет учётной записи? Зарегистрироваться

  • Login or register to search.