Сб. Ноя 27th, 2021
    TrueNFT, RSquad, TON Surf

    В понедельник, 16 августа, объединенная команда разработчиков Surf и RSquad представит свою концепцию True NFT перед представителями subgovernance, а 23-го августа примет участие в AMA-сессии Free TON. Для пользователей уже подготовлен tnft.surf, а мы публикуем первую часть технологического описания принципиально нового решения по созданию NFT-токенов.

    Как стать настоящим

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

    Что такое True NFT

    True NFT — это технология, созданная совместно командами Surf и RSquad, для реализации NFT токенов на базе сети Free TON.

    Технология позволяет:

    • быть уверенным, что все данные NFT хранятся в блокчейне, не полагаясь на какие-либо сторонние протоколы;
    • упростить и стандартизировать запросы для поиска NFT-коллекций и токенов пользователей;
    • пользователям взаимодействовать со своими токенами в децентрализованных браузерах и dApps, зная только собственный адрес, и передавать их, зная только адрес получателя.

    Задача

    На момент старта разработки в блокчейне Free TON уже существовали реализации NFT, например TIP-3 NFT. Также только что вышел TIP-31, развивающий идеи TIP-3 и предоставляющий новые возможности для разработки контрактов, да и вариант с реализацией аналога ERC-721 никто не отменял.

    Перед командами Surf и RSquad ставилась задача изучить существующие решения и разработать технологию NFT для Free TON, удовлетворяющую следующим требованиям:

    • сфокусироваться на максимальном удобстве использования: пользователь, знающий только свой адрес в Surf, должен иметь полный набор инструментов для работы со своими NFT-токенами;
    • дать возможность пользователю передавать токены другим пользователям или системам, зная только адрес получателя;
    • отображать токены в кошельке без указания дополнительных адресов;
    • создать универсальную и максимально кастомизируемую систему;
    • сохранять контент токенов исключительно on-chain.

    Исследование существующих решений показало, что они не подходят под вышеуказанные требования и имеют массу проблем относительно поставленной задачи. Например, классическая на сегодняшний день модель ERC-721 условно нереализуема во Free TON из-за больших маппингов, а TIP-3 заставляет пользователей деплоить дополнительные кошельки для каждой коллекции NFT.

    Более того, отправлять токены можно только между этими самыми кошельками, адреса которых нужно знать. Умножив эти проблемы на то, что нужно придумать механизм получения всех токенов пользователя, зная только его адрес, получаем вывод: нужно придумывать что-то новое.

    Как родилась и развивалась идея

    В результате мозгового штурма, команде стало очевидно, что каждый NFT-кошелек должен генерировать адрес таким образом, чтобы его можно было найти в рамках всей сети, например, “зашивая” адрес владельца в initial data.

    Решение позволило бы находить все кошельки пользователя, в которых лежат его токены. Такой подход убирал ряд абстракций из TIP-3 и привносил элементы TIP-31, но по-прежнему сохранял массу вопросов:

    • как передать токены пользователю, у которого еще нет кошелька в рамках коллекции.
    • кто должен платить за деплой кошельков.
    • как дать возможность максимальной кастомизации в рамках реализации под конкретную систему.

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

    В результате команда приняла решение, навеянное TIP-31, о создании новой функциональности — “зашить” владельца конкретного токена в initial data, тем самым делая его доступным для поиска, сохраняя адрес уникальным, и при передаче токена удалять старый контракт и деплоить новый. Более того, вынести данные в отдельный неудаляемый контракт и создать некие поисковые индексы, которые можно будет пересоздавать при изменении владельца токена. Таким образом был найден путь, который и привел команду к решению поставленной задачи.

    Само решение стало возможным благодаря представлению блокчейна Free TON, как key:value сторейджа, где key — это некое объединение из кода контракта и initial data, а value — это адрес или сам контракт.

    Во Free TON существует много способов поиска нужного контракта помимо обычного “знаю адрес — могу дергать”. В рамках сети есть огромное количество одинаковых с точки зрения функциональности контрактов (например, конкурсы или коллекции NFT), и Free TON позволяет получить их все. Достаточно понимать, что у контракта есть код, с него можно взять хэш, обратиться в GraphQL и получить все адреса, по которым расположены контракты, соответствующие заданному коду.

    Адрес во Free TON — это некоторое объединение кода контракта и его initial data. Таким образом, зная эти два параметра, использованные при деплое контракта, можно вычислить его адрес. Важно понимать, что код впоследствии может быть изменен, а адрес — нет. Потому поиск по хэшу кода и сбор адреса — кардинально разные вещи.

    Перед публикацией TIP-31 была добавлена возможность “присаливать” код контракта, т.е. добавлять в скомпилированный код набор данных (“salt”) с последующей возможностью его прочитать. Это никак не влияет на описанные выше механизмы, но позволяет “зашивать” данные не только в initial data, но и в сам код контракта, добавляя некую гибкость процессу инициализации.

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

    Решение

    Figure 1. Сonceptual system architecture

    На рисунке 1 представлена диаграмма контрактов получившейся концептуальной системы. Разработанное ядро системы и примеры можно найти в репозитории.

    IndexBasis

    IndexBasis, или просто базис, это контракт, который используется для поиска всех NFT- коллекций в сети. Из диаграммы можно увидеть, что его код ничем не “солится”, а уникальность адреса достигается путем добавления адреса контракта NftRoot и хэша кода контракта Data. Таким образом, для того чтобы считаться True NFT, каждая система должна выпускать базис для каждой NFT-коллекции.

    IndexOwner и IndexOwnerRoot

    Данные контракты объединены в одну группу, потому что в сути своей они идентичны и наследуют контракт Index. Иными словами, у них абсолютно одинаковый код, но они нужны для разных целей и по разному “солятся”.

    В обоих индексах в initial data зашивается адрес контракта Data, что является ссылкой от индекса к Data. IndexOwner “солится” только адресом владельца, что позволяет нам искать все токены конкретного пользователя, а IndexOwnerRoot солится как адресом владельца, так и адресом NftRoot, что позволяет одним запросом найти все токены пользователя в рамках конкретной коллекции. Итого: для того чтобы считаться True NFT, каждая система должна выпускать IndexOwner и IndexOwnerRoot для каждого NFT.

    NftRoot

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

    Data

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

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

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

    Мы имеем набор из трех поисковых индексов, которые обязаны быть неизменяемыми в рамках любых True NFT систем, контракты NftRoot и Data, которые содержат в себе логику отдельно взятой системы и  полностью кастомизируемые.

    Трансфер токенов

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

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

    Figure 2. Transfer ownership sequence

    Пользователь вводит в интерфейсе адрес получателя, и токен передается без дополнительных действий. Получатель может видеть в своем интерфейсе полученный токен, не совершая вообще никаких действий. Звучит просто. Под капотом пользователь вызывает метод передачи у своего контракта Data. Далее Data удаляет свои поисковые индексы, меняет владельца и деплоит новые индексы с новым владельцем в initial data.

    Целостность данных сохраняется. В любой момент времени NFT (как с точки зрения индексов, так и с точки зрения контракта Data) принадлежит одному владельцу либо никому не принадлежит.

    Дополнительная логика, например отчисление роялти автору, может быть реализована в рамках самого метода передачи владения, либо вовсе метод может отсутствовать, и передача может быть осуществлена только при покупке, это не важно. Важно то, что чтобы система могла называться True NFT, она обязана сохранить логику передачи владения с пересозданием поисковых индексов и смены владельца в контракте Data.

    Минтинг токенов

    Минтинг (чеканка) токенов работает практически также, как и трансфер.

    Figure 3. Mint sequence

    Пользователь, имеющий право выпускать токены, вызывает NftRoot, передавая при этом данные NFT. NftRoot деплоит контракт Data, который в свою очередь деплоит свои индексы. Права на минтинг, наличие/отсутствие его как такового, или, например, минтинг при покупке — это кастомизируемая часть системы. При этом, чтобы система могла называться True NFT, она обязана сохранить логику создания токенов с деплоем даты и поисковых индексов.

    Поиск и отображение

    В процессе работы были формализованы конкретные требования к поисковым возможностями. Система должна позволять найти все:

    • коллекции;
    • токены пользователя;
    • токены пользователя в рамках коллекции;
    • токены в рамках коллекции.

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

    Итого:

    • чтобы получить данные обо всех токенах пользователя, нужно взять код контракта IndexOwner, присолить адресом пользователя, хэшировать его и запросить из GraphQL API аккаунты с полученным code_hash;
    • аналогичное действие и для всех коллекций — берем код контракта IndexBasis, хэшируем, запрашиваем, получаем все коллекции сети;
    • для токенов пользователя в рамках коллекции — берем IndexOwnerRoot, солим его адресом пользователя и адресом интересующей коллекции, хэшируем, запрашиваем;
    • чтобы найти все токены одной коллекции, нужно просто взять базис этой коллекции, и в нем уже есть хэш кода даты, по нему можно найти все токены коллекции, так как Data солится адресом NftRoot.

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

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

    Заключение

    Мы вывели несколько требований для того, чтобы система считалась True NFT, она должна:

    • выпускать IndexBasis для каждого NftRoot;
    • выпускать IndexOwner и IndexOwnerRoot для каждого Data;
    • хранить все данные в контракте Data либо иметь ссылки на другие контракты в рамках сети;
    • контракты IndexBasis, IndexOwner и IndexOwnerRoot  едины и не  подвергнуты каким-либо изменениям в рамках любых TrueNFT систем;
    • сохранить логику передачи владения с пересозданием поисковых индексов и смены владельца в контракте Data.

     ________________________

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

    Surf & RSquad

    26
    0

    от RSquad