• 0 Голоса
    1 Сообщения
    15 Просмотры

    Для многих приложений нецелесообразно размещать все свои данные в блокчейне. Таким образом, им нужен отдельный хостинг для таких вещей, как база данных, но они могут захотеть, чтобы этот хостинг тоже был децентрализованным. Можно ли использовать для этого хранилище TON и хорошая ли это идея?

    Этот вопрос был импортирован из чата Telegram: <***Скрыто***

    click to show

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

  • 0 Голоса
    1 Сообщения
    22 Просмотры

    Структура ячеек в TON имеет строгие ограничения, она может содержать до 1023 бит и до 4 ссылок на другие ячейки. Но откуда берется это ссылочное ограничение? Есть ли для этого какая-то конкретная причина, или это было просто случайное произвольное решение?

    Этот вопрос был импортирован из чата Telegram: <***Скрыто***

    click to show

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

  • 0 Голоса
    2 Сообщения
    10 Просмотры

    Masterchain - это цепочка "системного уровня" для материалов, которые влияют на всю сеть, а workchain - это место, где происходит "обычная жизнь", например, пользователи отправляют друг другу тонкоины. На данный момент существует только одна рабочая цепочка, но в будущем их может быть гораздо больше.

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

    Таким образом, в основном вам не нужно иметь дело с "подвалом", вы просто выполняете свои задачи, используя базовую рабочую цепочку. И если вам по какой-то причине в будущем понадобится "спуститься в подвал" (напрямую взаимодействовать с masterchain), это, вероятно, будет означать, что вы занялись какими-то низкоуровневыми вещами, и к тому времени вы поймете разницу.

  • 0 Голоса
    2 Сообщения
    218 Просмотры

    Проще говоря,:

    Все блокчейны, включая TON, группируют новые транзакции в "блок", прежде чем они будут добавлены в цепочечную структуру, состоящую из всех предыдущих блоков (отсюда и слово "блокчейн"). И создание нового блока всегда занимает некоторое заметное время из-за ряда факторов.

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

    Так что здесь нет никакого противоречия. Когда люди говорят: "TON может обрабатывать миллионы транзакций в секунду", это означает, что весь этот гигантский поток транзакций не захлестнет сеть. Но все транзакции в этом гигантском потоке имели бы одинаковое время обработки в несколько секунд.

  • 0 Голоса
    1 Сообщения
    15 Просмотры

    В настоящее время блокчейн TON состоит только из одной рабочей цепочки и мастер-цепочки. Весь код смарт-контрактов в masterchain и базовой рабочей цепочке выполняется TVM (виртуальной машиной Ton). Но TON предоставляет возможность создавать больше рабочих цепочек в будущем. И в техническом документе Николая Дурова упоминается, что эти гипотетические будущие рабочие цепочки могли бы использовать разные виртуальные машины:

    Разные рабочие цепочки могут иметь разные правила, что означает разные форматы адресов учетных записей, разные форматы транзакций, разные виртуальные машины (ВМ) для смарт-контрактов, разные базовые криптовалюты и так далее.

    Итак, я пытаюсь понять: обязательно ли эти "разные виртуальные машины" должны быть похожи на TVM, или они могут быть очень разными, как EVM? Мог бы кто-нибудь гипотетически создать рабочую цепочку TON, где код выполнялся бы EVM вместо TVM, так что код, написанный для EVM, можно было бы повторно использовать в TON?

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

  • 0 Голоса
    2 Сообщения
    25 Просмотры

    Решено

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

    ** Назначение сети **: Главная сеть - это основная сеть, в которой происходят реальные транзакции, поэтому стабильность и безопасность являются главными приоритетами.

    Тестовая сеть, с другой стороны, предназначена для целей тестирования. Это позволяет разработчикам экспериментировать и отлаживать, не опасаясь причинить серьезный вред. Таким образом, потенциальные проблемы или время простоя могут быть более вероятны в тестовой сети, поскольку это более экспериментальная среда.

    ** Инфраструктура и ресурсы **: Основная сеть обычно имеет больше узлов и ресурсов, выделенных для ее обслуживания и безотказной работы, поскольку она обрабатывает реальные активы. Тестовая сеть, хотя и децентрализована, может иметь меньше ресурсов, выделенных для нее, что потенциально делает ее менее устойчивой к проблемам.

    ** Обновления и изменения **: Изменения, апдейты и экспериментальные функции часто сначала внедряются в тестовой сети, а затем развертываются в основной сети. Это может привести к нестабильности или потенциальному простою тестовой сети.

    ** Реагирование на проблемы **: Учитывая ставки, проблемы в основной сети часто решаются немедленно, в то время как проблемы в тестовой сети могут решаться не так быстро, что потенциально приводит к более длительным периодам простоя.

    ** Стимулы **: Валидаторы или узлы в основной сети обычно стимулируются (например, за счет платы за транзакции или вознаграждения за блокировку) для поддержания целостности сети и времени безотказной работы. Такие стимулы могут отсутствовать в тестовой сети, что потенциально может повлиять на устойчивость сети.

    Важно отметить, что, хотя децентрализация в целом повышает устойчивость, она не гарантирует 100%-ную безотказную работу. Проблемы с сетью все еще могут возникать, особенно при таких обстоятельствах, как ошибки программного обеспечения, проблемы с согласованием или скоординированные атаки. В случае TON testnet, без конкретных подробностей, трудно точно сказать, почему произошел простой. Это может быть вызвано целым рядом причин - от планового технического обслуживания до тестирования новых обновлений.

  • 0 Голоса
    4 Сообщения
    116 Просмотры

    #uptheme

  • 0 Голоса
    2 Сообщения
    26 Просмотры

    Решено

    "Парадигма бесконечного сегментирования" от TON - это метод улучшения масштабируемости блокчейна.

    Сеть TON может быть разделена на несколько независимых цепочек блоков, которые параллельно обрабатывают транзакции и смарт-контракты.

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

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

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

    Но похоже, что это просто перенос части технического документа: https://docs.ton.org/learn/overviews/ton-blockchain

  • 0 Голоса
    4 Сообщения
    61 Просмотры

    #uptheme

  • 0 Голоса
    1 Сообщения
    17 Просмотры

    Трудно найти полностью сетевые сервисы. Я сталкивался с мнением, что бизнес не заинтересован в их создании, потому что гораздо проще вывести часть системы из цепочки. Но возможны ли такие сервисы технически с блокчейном TON и сайтами TON? Например, можно ли создать форум без базы данных, который требовал бы микроплатежа за добавление поста? Может ли этот форум конкурировать с обычными форумами, со всеми их функциями?

    Этот вопрос был импортирован из чата Telegram: <***Скрыто***

    click to show

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

  • 0 Голоса
    2 Сообщения
    31 Просмотры

    Как разработчик Solidity, одна из лучших статей для вас, чтобы понять различия между EVM и TVM, - это:

    https://society.ton.org/six-unique-aspects-of-ton-blockchain-that-will-неожиданность-надежность-разработчики

    Это очень хорошее введение. После этого вам нужно будет перейти к техническому документу вместе с документацией разработчика.

    https://ton.org/whitepaper.pdf https://ton.org/docs

  • 0 Голоса
    2 Сообщения
    33 Просмотры

    Решено

    Boc не ограничен по размеру, фактически все состояние блокчейна представляет собой ячейку с кучей ячеек, обернутых внутри них. Все - это клетка!

    Размер внешнего сообщения ограничен 64 Кб, что может ограничить размер boc, который вы пытаетесь создать с помощью своей логики смарт-контракта. Вы можете видеть, что это определено в клиенте lite, но оно может быть изменено:

    https://github.com/ton-blockchain/ton/blob/db3619ed310484fcfa4e3565be8e10458f9f2f5f/validator/impl/external-message.hpp#L40

  • 0 Голоса
    2 Сообщения
    43 Просмотры

    Решено

    Чтобы лучше понять роль "CRC-32" в сети TON и его связь с "пакетом ячеек" (BOCs), важно сначала ознакомиться с концепцией циклической проверки избыточности (CRC) и ее основным назначением.

    ** CRC - это широко используемый метод проверки целостности цифровых данных.** ** В качестве алгоритма обнаружения ошибок ** он проверяет наличие ошибок в цифровых данных во время передачи или хранения.

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

    CRC-32, 32-разрядная вариация алгоритма CRC, предназначена для обнаружения случайных изменений необработанных данных в цифровых сетях и устройствах хранения. Вычисляя 32-разрядную контрольную сумму для входных данных, это помогает поддерживать целостность данных во время передачи или хранения.

    **В сети TON CRC-32 используется в качестве компонента формата сериализации пакета ячеек (BOC) для обеспечения целостности данных. ** BOC - это двоичный формат, представляющий дерево ячеек, используемый для хранения и передачи данных в сети TON. Каждая ячейка в BOC содержит небольшой фрагмент данных и может содержать ссылки на другие ячейки.

    Во время сериализации или десериализации BOC для данных ячейки вычисляется контрольная сумма CRC-32, чтобы гарантировать, что они не были повреждены во время передачи или хранения. Если вычисленная контрольная сумма CRC-32 не совпадает с суммой, сохраненной в BOC, это указывает на то, что данные повреждены и их необходимо повторно передать или извлечь.

    Для получения дополнительной информации о CRC-32 и его использовании в сети TON обратитесь к следующим ресурсам:

    TON Documentation on CRC-32: https://docs.ton.org/develop/data-formats/crc32 * Online CRC-16 Calculator: https://emn178.github.io/online-tools/crc16.html
  • 0 Голоса
    2 Сообщения
    16 Просмотры

    Решено

    Адреса источника и получателя важны в сообщении по разным причинам:

    Отслеживаемость и подотчетность: Адрес источника указывает источник сообщения, т.е. учетную запись (смарт-контракт), которая создала сообщение при обработке транзакции. Наличие фиксированного, неизменяемого адреса источника гарантирует, что источник сообщения известен и не может быть изменен. Это помогает установить четкую цепочку действий внутри сети, позволяя отслеживать транзакции и проводить аудит.

    Безопасность: Тот факт, что исходный адрес не может быть произвольно изменен или установлен, добавляет уровень безопасности блокчейну TON. Смарт-контракты полагаются на неизменность исходного адреса, чтобы предотвратить подделку сообщений злоумышленниками или манипулирование ими. Это помогает поддерживать целостность транзакций и общую безопасность сети.

    "Взаимодействие между смарт-контрактами": В многоцепочечной архитектуре, такой как TON, различным смарт-контрактам в разных рабочих цепочках может потребоваться обмениваться данными и взаимодействовать друг с другом. Адреса источника и назначения в сообщении обеспечивают правильную маршрутизацию и выполнение межконтрактных взаимодействий. Гарантируя, что адрес источника является фиксированным и неизменяемым, принимающий контракт может доверять источнику сообщения и может быть обеспечено правильное выполнение намеченных действий.

    `Маршрутизация сообщений": Как упоминалось в этом отрывке, при создании сообщения может быть выбран любой правильно сформированный адрес назначения. После установки адрес назначения не может быть изменен. Такой выбор дизайна, наряду с фиксированным адресом источника, гарантирует, что маршрутизация сообщений между учетными записями и смарт-контрактами является эффективной и безопасной.

    Таким образом, наличие фиксированного и неизменяемого адреса источника в сообщении важно для поддержания отслеживаемости, безопасности и надлежащего выполнения транзакций и взаимодействий между смарт-контрактами в блокчейне TON. Комбинация фиксированных адресов источника и назначения обеспечивает эффективную и безопасную маршрутизацию сообщений внутри сети.

  • 0 Голоса
    2 Сообщения
    17 Просмотры

    Решено

    В TVM существуют ограничения по памяти, но они могут быть не такими строгими, как в EVM. Это связано с тем, что TVM разработан таким образом, чтобы быть более эффективным и гибким с точки зрения управления ресурсами. Однако разработчикам все равно следует помнить об использовании ресурсов при создании смарт-контрактов для бесплатной платформы TON.

    Некоторые соображения по использованию памяти в TVM:

    Управление памятью: TVM использует более сложную модель памяти, чем EVM, что обеспечивает более эффективное управление памятью. Однако это не означает, что разработчики могут игнорировать использование памяти, поскольку чрезмерное потребление памяти все равно может привести к проблемам с производительностью или увеличению затрат на выполнение.

    Затраты на газ: Подобно EVM, TVM также использует газовую модель для выполнения смарт-контрактов, где газ представляет собой вычислительные затраты на выполнение операций. Хотя затраты на газ в TON могут быть не такими значительными, как в Ethereum, по-прежнему важно оптимизировать код вашего смарт-контракта, чтобы минимизировать потребление газа и затраты на выполнение.

    Производительность и масштабируемость: Написание эффективного кода, оптимизирующего использование памяти, имеет решающее значение для обеспечения хорошей производительности и масштабируемости ваших смарт-контрактов в сети Free TON. Это помогает поддерживать общую работоспособность сети и позволяет ей поддерживать большее количество смарт-контрактов и транзакций.

    Хранение данных: В сети TON смарт-контракты используют постоянное хранилище, называемое "Persistent Data Storage" (PDS), для хранения своего состояния. Разработчикам следует помнить о том, какой объем данных они хранят в PDS, поскольку большие требования к хранилищу могут привести к увеличению затрат и потенциальным проблемам с производительностью.

    Таким образом, хотя виртуальная машина TON может обеспечить большую гибкость и эффективность с точки зрения использования памяти по сравнению с виртуальной машиной Ethereum, разработчикам по-прежнему важно помнить об ограничениях памяти и писать эффективный код для обеспечения оптимальной производительности, масштабируемости и экономической эффективности своих смарт-контрактов.

  • 0 Голоса
    2 Сообщения
    61 Просмотры

    Решено

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

    В отличие от некоторых других блокчейнов, таких как Ethereum, "блокчейн TON не допускает динамической корректировки платы за газ в зависимости от рыночного спроса`. Цены на газ одинаковы для всех и определяются конфигурацией сети. * ** Таким образом, невозможно "заплатить больше", чтобы заставить валидаторов отдавать приоритет вашей транзакции перед другими.** *

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

  • 0 Голоса
    2 Сообщения
    24 Просмотры

    Решено

    Универсального ответа на эти вопросы не существует, поскольку наилучший подход может варьироваться в зависимости от конкретных требований и ограничений создаваемого вами DApp. Однако существуют некоторые общие рекомендации и лучшие практики, которым можно следовать при разработке DApp на TON.

    Одним из ресурсов, который может оказаться полезным, является серия руководств, содержащих пошаговые инструкции по развертыванию контрактов и написанию функционального кода. Вы можете найти эти учебные пособия по адресу https://ton-community.github.io/tutorials/01-wallet/.

    Кроме того, веб-сайт TON (https://ton.org/) предлагает огромное количество информации и документации по всему, что связано с TON. Хотя он может быть организован не самым систематизированным образом, он может стать ценным ресурсом для разработчиков, желающих создавать на платформе.

  • 0 Голоса
    2 Сообщения
    34 Просмотры

    Решено

    Теоретически, блокчейн TON может обрабатывать "более 15 000 транзакций в секунду" и более, благодаря своей конструкции с высокой пропускной способностью транзакций и потенциалу масштабирования до миллионов транзакций в секунду благодаря поддержке нескольких цепочек для масштабируемости.

    Сеть TON естественным образом обеспечивает сегментирование на основе идентификатора цепочки ** с большим количеством рабочих цепочек, доступных для использования **, как описано в параметрах, которые запускают валидаторы. Вы можете перейти по следующей ссылке для получения более подробной информации: https://ton.org/docs/learn/overviews/addresses#workchain-id-идентификаторучетнойзаписи

    Однако текущая максимальная пропускная способность системы ограничена существующей инфраструктурой и количеством валидаторов в сети. По состоянию на дату отключения информации в сентябре 2021 года блокчейн TON, как сообщается, был способен обрабатывать до 15 000 транзакций в секунду (TPS) с целевым временем подтверждения 5 секунд.

    Важно отметить, что "это число, возможно, изменилось с тех пор и может варьироваться в зависимости от условий сети и других факторов". Более того, блокчейн TON постоянно оптимизируется и совершенствуется, поэтому вполне возможно, что максимальная пропускная способность может увеличиться в будущем, поскольку сеть продолжает расти и эволюционировать.

    Параметры конфигурации сети приведены в деталях: https://ton.org/docs/develop/howto/network-configs

  • Где узнать больше о выбросах?

    TON Overflow на русском
    0 Голоса
    1 Сообщения
    22 Просмотры

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

    Этот вопрос был импортирован из чата Telegram: <***Скрыто***

    click to show

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

  • 0 Голоса
    1 Сообщения
    21 Просмотры

    Обычно новые блоки в блокчейне TON формируются каждые новые секунды, так что нет причин беспокоиться о слишком долгом ожидании. Но я слышал, что при некоторых обстоятельствах задержки могут превышать минуту. Неужели это происходит на самом деле? К какой самой длительной задержке разумно быть готовым при разработке на TON?

    Этот вопрос был импортирован из чата Telegram: <***Скрыто***

    click to show

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