Ответы на вопросы о TON DNS каналу "Investment kingyru". Часть 2.

1. Почему не пофиксили ошибку в конфигурации контракта голосования? Почему перепутаны выигрыши и проигрыши?

В смарт-контракте конфигурации сети, действительно, есть минорная ошибка —в get-методе перепутаны местами переменные.

Сам функционал голосования работает верно, просто если вы вызываете этот метод извне (например, чтобы отобразить на фронтенде результаты голосования), вам надо учесть этот момент.

Смарт-контракт конфигурации еще ни разу не менялся с 04.2020, так что это нам досталось в наследство.

Смарт-контракты elector'а и конфигурации - основные системные контракты, на них строится работа всей сети TON.

Системные контракты можно обновить/поменять всеобщим голосованием валидаторов сети.

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

Со временем накопится достаточно улучшений системных контрактов, сделаем апдейт разом.

2. Почему не стали использовать контракт 2020 года выпуска (https://github.com/ton-blockchain/ton/blob/master/crypto/smartcont/dns-auto-code.fc), вместо чего релизнули новый с NFT?

В 2020 году само явление NFT еще не было достаточно распространенно, поэтому не удивительно, что команда Telegram спроектировала DNS не в виде токенов.

Однако, судьба проекта TON такова, что пришлось немного отложить запуск TON DNS 😅. В 2022 мы актуализировали TON DNS, чтобы идти в ногу со временем.

Сделать домены зоны .ton в виде NFT — это красивое и элегантное решение, особенно учитывая, что перед этим мы выпустили отличный стандарт распределенных токенов и в экосистеме очень качественный UI/UX NFT в кошельках и маркетплейсах.

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

3. Участвовал ли Skydev в разработке текущего смарт-контракта DNS?

Нет, Skydev автор ряда апдейтов компилятора FunC и апдейтов core-частей TON.

4. Вы можете сказать, кто разрабатывал контракты TON DNS? Кто проводил их аудит? 

Важные роадмаповские смарт-контракты мы делаем вдвоем: Кирилл Емельяненко и я.

Мы достаточно параноидально относимся к ревью контрактов и их тестированию. Почти во всех системообразующих контрактах очень высока цена ошибки — так что это большая работа.

Все контракты open source, действует программа Bug Bounty — аудит делает, в каком-то смысле, сообщество.

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

5. Как прокомментируете слова Николая Дурова "In most cases, the persistent data of a TON DNS Resolver smart contract contains a prefix dictionary with keys equal to the defined subdomain names (with terminating zero byte) and values equal to a (HashmapE 16 ^DNSRecord)…». Почему не сделали по этому сценарию? 

Записи так и хранятся, только размер ключа был увеличен с 16-bit до 256-bit, чтобы соответствовать Token Data Standard и чтобы различные проекты могли не согласовывать ключи друг с другом, а просто брать произвольные строки в качестве ключа.

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

6. Все пользователи экосистемы для старта аукционов в доменной зоне .ton вынуждены отправлять сообщения одному контракту. Это может быть проблемой («узким горлом») при большом спросе на создание аукционов. Не думали об этом, как о масштабировании?

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

Сейчас же контракт аукциона (он же и контракт NFT-коллекции) ничего не хранит, он только принимает сообщения от пользователей с оплатой и создает отдельные контракты доменов.

В TON'е продуманная система доставки сообщений между контрактами, в этом плане проблемы не видится. Особенно учитывая специфику — это аукцион доменных имен, а не высокочастотный трейдинг.

7. Для чего нужна настройка Resolver на странице управления доменом?

У домена могут быть субдомены. Для этого вы можете создать произвольный смарт-контракт, отвечающий стандартному интерфейсу DNS и прописать адрес этого смарт-контракта в поле resolver.

Пример: у вас есть контракт "alice.ton", вы запрашиваете "sub.alice.ton".

В процессе резолвинга очередь дойдет до смарт-контракта домена "alice.ton", у него спросят "Как мне найти sub?", тот перенаправит на смарт-контракт субдоменов, а тот уже даст ответ.

Субдомены, кстати, не обязательно должны быть сделаны в виде NFT. Смарт-контракт субдоменов может быть выполнен, например, в виде единого контракта со словарем (manual-dns). Это гораздо удобнее для менеджмента субдоменов TON-сайта.

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

8. Почему пользователи должны быть согласны с возможностью регистрировать .ton на контрактах? В теории любой может развернуть свои DNS контракты, но резолвится будут только конкретные по резолверу из конфига сети. Возможно стоило бы подумать о более распределенной системе?

Можно также спросить "Почему пользователи должны использовать Toncoin, ведь они могут создать свои альткойны, но им все равно приходится использовать Toncoin как нативную монету блокчейна". TON DNS - нативная доменная система TON. Ничто не запрещает создавать альтернативные смарт-контракты и использовать их в каких-то других локальных целях.

9. Разработчики заметили множество моментов, где контракты DNS можно было бы оптимизировать по газу, и как минимум сделать код более красивым и читабельным. Зная вас с Кириллом, вы побеждали в конкурсах именно по оптимизации. Почему вы торопитесь и не доводите код до идеала?

Код красивый, читабельный и оптимальный.

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

Одного Toncoin'a, остающегося на смарт-контракте домена после аукциона, хватит на 200 лет оплаты сетевой комиссии за хранение.

Вчера получил спам-рассылку TON-жетонов на свой кошелек. Эти жетоны создатели, кажется, стремятся разослать на все кошельки сети.

Это говорит о том, что сетевые комиссии токенов низкие, и контракты токенов сделаны оптимально.

В блокчейне не должно быть бесплатных комиссий - это влечет DDoS и спам.

10. Есть хорошие примеры оформления стандартов:

- https://eips.ethereum.org/EIPS/eip-20

- https://eips.ethereum.org/EIPS/eip-721 

Почему TF не оформляет стандарты таким образом, а используют ишью на гитхабе?

Скоро будет репозиторий https://github.com/ton-blockchain/TEPs.