Со стремительным развитием концепции NFT, большинство публичных сетей разработали свои собственные протоколы NFT. Nervos работает на протоколе mNFT, а Ethereum на протоколах ERC721 и ERC1155.
У этих протоколов нет проблем при создании, использовании и отображении NFT, но если вы захотите разработать более сложные, универсальные и разнообразные функции на основе этих протоколов, вы столкнетесь с проблемой их реализации.
Существует три типичные функции:
-пользовательская доля транзакций NFT;
-возможность использовать токены sUDT или ERC20 для торговли NFT;
- возможность собрать несколько NFT, чтобы синтезировать определенные NFT.
Причина сложной реализации заключается в том, что эти протоколы изначально не были разработаны для крупной масштабируемости. Когда функции, которые реализовывает протокол, не могут охватывать сценарии использования, требуемые стороной проекта, могут возникнуть указанные выше проблемы. Хотя эти функции могут быть выполнены стороной проекта независимо, это также означает, что трудно достичь совместимости между различными проектами с точки зрения этих функций.
Есть ли более общий протокол NFT для включения этих (или даже большего количества) функций? Прежде всего, необходимо прояснить, что такой протокол ограничен свободой разработки контрактов, которую могут поддерживать Nervos и Ethereum, поэтому это приводит к другой более общей проблеме: публичные сети с разными моделями программирования разрабатывают NFT.
В сети CKB Cell может выражать NFT через TypeScript, поэтому более функциональные расширения в основном размещаются на LockScript. Помимо демонстрации владения NFT, LockScript также будет нести больше функций связанных с транзакциями NFT. Конечно, и LockScript, и TypeScript можно снова расширить с помощью Witness и CellDep, но данные, помещенные в Witness, могут использоваться только на этапе разблокировки и хранения.
Основываясь на вышеизложенной теории, протокол mNFT расширен для выполнения следующих трех функций:
1. Пользовательская доля транзакции NFT
Предполагается, что реализованный с помощью LockScript, NFT торгуется с CKB, и вы можете установить соотношение долей для создателя, покупателя и продавца в LockScript_Args. Покупатель может установить новое соотношение долей в транзакции, которая получает право собственности на NFT. Модерация, независимо от того, требует ли сценарий соразмерной транзакции, участия покупателей и продавцов с несколькими подписями или следует непосредственно логике ACP, полностью свободно задается кодом LockScript.
2. Торговля NFT с токеном sUDT
Он по-прежнему реализуется LockScript, вам нужно просто ввести ячейку, к которой sUDT принадлежит, остальная функциональная логика в основном такая же, как «Custom NFT Transaction Sharing».
3. Использование нескольких NFT для синтеза определенного NFT
Синтез нескольких NFT в один NFT, по сути, состоит в том, что существует несколько NFT на входной стороне транзакции и только один NFT на выходе. Чтобы настроить такую структуру ввода и вывода, необходимо следовать некоторым правилам:
1) Реализация с помощью LockScript, то есть в коде LockScript четко указано, что NFT, выраженные в TypeScript, могут быть размещены на стороне ввода, а затем какой NFT нужно разместить на выходе;
2) Ввод ячейки правила, которую можно разместить на входе и выходе транзакции одновременно, а затем проверить логику правила с помощью LockScript или TypeScript, так что LockScript из NFT- Cell может быть обычным скриптом Sighash.
3) Ячейка правила также может быть представлена в форме CellDep, а конкретная логика проверки правила сохраняется в Data или ScriptArgs ячейки правила, и читается LockScript ячейки NFT.
Мы обнаружили, что при разработке этих трех функций логика протокола mNFT вообще не изменялась. Написав специальный LockScript для Cell или комбинируя Cell, или CellDep с конкретными функциями, можно добиться расширения функции без изменения исходного протокола.
Мы также можем обнаружить, что для трех вышеупомянутых функций, даже если все сценарии NFT LockScripts являются стандартными контрактами Sighash, эти функции могут быть реализованы путем непосредственного введения правила Cell на концах ввода и вывода транзакции, и может быть достигнуто еще больше функций.
Существует практическая проблема в изменении существующего протокола на Ethereum. Новый протокол трудно распространить, чтобы заменить исходный протокол, когда исходный протокол был полностью популяризирован. Если мы предположим, что существующий протокол не изменен, расширение функций может быть достигнуто только путем использования нового контракта для объединения существующего контракта ERC721 или ERC1155, и этот новый контракт обычно сильно связан с логикой самого проекта, что также является дизайном, принятым в большинстве проектов в настоящее время.
Однако у этого метода есть очевидный недостаток: трудно добиться совместимости между разными проектами в отношении одного и того же типа функции. Например, все они реализуют одну и ту же функцию пользовательского разделения транзакций. Возможно, каждый проект имеет свой собственный набор логики реализации. И они обычно несовместимы, поэтому, если один и тот же набор функциональной логики должен быть совместим между разными проектами, это может быть только для интеграции функций, которые необходимо расширить в существующий протокол NFT.
Основываясь на вышеизложенной теории, без учета сложности фактической работы, а только сложности теоретического проектирования, мы реализуем следующие три функции в рамках существующей структуры протокола ERC721:
1. Пользовательская доля транзакции NFT
Добаление атрибута в структуру NFT соглашения. Этот атрибут является адресом контракта. Адрес контракта заполняется при создании определенного NFT. Внешний контракт описывает, как входящий ETH должен быть разделен на контракт. Бенефициары, переданные через интерфейс, являются покупателями, продавцами, создателями NFT. В функции transferFrom протокола ERC721 передача права собственности на NFT завершается, и интерфейс внешнего контракта, связанный с NFT, вызывается для реализации логики разделения транзакции этой транзакции.
2. Торговля NFT с токенами ERC20
Добавление атрибут в структуру NFT. Этот атрибут представляет собой список адресов контракта ERC20, указывающий, какие транзакции с токенами ERC20 поддерживает этот NFT, а затем к протоколу ERC721 добавляется функция transferFromErc20 для поддержки функции использования токенов ERC20 для торговли NFT.
3. Использование нескольких NFT для синтеза определенного NFT
В протокол ERC721 добавляется новая функция transferFromCompose для получения массива NFT, а затем прямое преобразование нового NFT для вызывающего путем уничтожения NFT в массиве, и проверка этого процесса преобразования по-прежнему требует вызова контракта внешнего правила для завершения. Адрес контракта правила можно напрямую записать в переменную, добавленную в протокол ERC721, независимо от конкретного экземпляра NFT.
Мы обнаружили, что в трех вышеупомянутых функциях каждая реализация функции требует модификации протокола ERC721, и эти модификации почти трудно обобщить до определенной формы, то есть каждую новую функцию необходимо модифицировать и интегрировать. Каждая функциональная интеграция также означает создание нового соглашения.
Хотя до сих пор мы использовали только три функции для расширения существующего протокола NFT на Nervos и Ethereum, с точки зрения философии дизайна и парадигмы Nervos и Ethereum, разница между двумя цепочками на самом деле очень очевидна: Nervos, очевидно, склоняется больше в сторону комбинированного типа, в то время как Ethereum больше подходит к типу интеграции.
Комбинированный тип означает, что вы можете разработать функцию, которая будет достаточно фрагментированной и детализированной для достижения разнообразия функциональных эффектов за счет комбинирования, в то время как интегрированный тип означает, что дизайн функции трудно фрагментировать, и вы должны учитывать это при разработке функции. Можно заранее включить в соглашение достаточное количество факторов и продумайть план. Я думаю, что это во многом отражает существенное различие между моделью UTXO и моделью Account.
Используя метод индукции, мы можем узнать, что после реализации трех вышеупомянутых типичных функций, мы можем сделать вывод: теоретическая граница Nervos и Ethereum в дизайне протокола NFT полностью ограничена моделью программирования двух цепочек, а именно моделью программирования UTXO и моделью программирования учетной записи.
Используя дедуктивный метод, мы можем узнать:
При разработке протокола на основе модели программирования UTXO больше внимания уделяется тому, как разделить процесс протокола на независимые или неделимые функциональные единицы и реализовать конкретные выражения протокола посредством комбинации различных функциональных единиц.
При разработке протокола, основанного на модели программирования учетной записи, больше внимания уделяется тому, как максимально учесть существующие и потенциальные функциональные требования, а затем преобразовать эти требования в конкретные функции и интегрировать их для достижения окончательного выражения.Согласно протоколу, если требования к новому функционалу должны быть введены позже, может случиться так, что существующая абстракция архитектуры будет реорганизована, чтобы быть совместимой с большим количеством требований.
Таким образом, теоретические границы протокола Nervos в основном ограничиваются дробной детализацией и комбинаторной логикой протокольных единиц, в то время как теоретические границы протокола Ethereum в основном ограничиваются абстракцией архитектуры протокола. Напротив, теоретические границы Nervos значительно шире, чем у Ethereum, потому что сложность проектирования модулей значительно меньше, чем сложность проектирования архитектуры.
Теперь, когда мы знаем теоретические границы Nervos и Ethereum при разработке протокола NFT, мы пытаемся разработать протокол для обеих цепочек, который может максимально достичь их теоретических границ, и посмотрим.
На Nervos протокол NFT с наибольшей универсальностью может иметь следующие две идеи дизайна:
Пусть LockScript и TypeScript поддерживают принцип минимизации. LockScript просто обрабатывает функцию разблокировки NFT, в то время как TypeScript просто обрабатывает функцию отображения NFT. Все функции циркуляции передаются независимой ячейке правила, которую нужно достичь, помещая одну и ту же функцию в конец ввода и конец вывода. Ячейка правила используется для того, чтобы дать всем NFT в этой транзакции правила обращения, которые эта ячейка может выразить. Преимущество состоит в том, что атрибуты отображения и атрибуты распространения NFT полностью разделены, а атрибуты распространения можно переключать по желанию. Недостаток состоит в том, что существует проблема конкуренции с обычными ячейками.
Пусть LockScript и TypeScript обладают наибольшей масштабируемостью. Сценарий контракта, на который указывают LockScript и TypeScript, должен встраивать виртуальную машину JS или Lua, а затем помещать логику кода, которую виртуальная машина должна выполнять, в соответствующую ячейку правила, что может быть достигнуто путем введения этих ячеек правил в CellDep. Атрибут циркуляции NFT, соответствующий LockScript, и атрибут отображения NFT, соответствующий TypeScript, полностью настраиваются. Преимущество состоит в том, что атрибуты отображения и атрибуты распространения NFT по-прежнему полностью разделены и могут быть объединены по желанию, и не возникает проблемы конкуренции ячейки правил.
В Ethereum протокол NFT с наибольшей универсальностью в основном имеет только одну конструктивную идею:
Разработайте процесс протокола NFT, который охватывает как можно больше ситуаций, а затем поставьте "перехватчики" там, где наиболее необходима настройка. Протокол позволяет заказчику или стороне проекта устанавливать различные функции обратного вызова контракта в "перехватчиках"для создания экземпляров различных дисплеев. Логика обращения, а также отображение и поведение NFT не имеют ничего общего с самим проектом и могут свободно распространяться между различными проектами. Преимущество заключается в том, что по сравнению с существующим протоколом NFT, он имеет больше настраиваемых функций, которые отделены от конкретных проектов. Недостатком является то, что границы проекта все еще очевидны, и он может не соответствовать определенным конкретным функциональным требованиям в будущем.
Модель UTXO дает Nervos комбинированную модель программирования. Когда подходящая плотность разделения логического блока является соответствующей, теоретически возможно комбинировать неограниченное разнообразие логики проверки ячеек. Разделение сети проверки CKB и вычислительной сети уровня 2 в сети Nervos также отражает эту важную идею комбинированного разделения. Модель учетной записи дает Ethereum интегрированную модель программирования. Хотя эта модель ближе к традиционным привычкам программирования и имеет низкий порог для начала работы, она, естественно, не может преодолеть границы, которые могут коснуться традиционной парадигмы программирования.
Таким образом, по сравнению с Ethereum, Nervos, который имеет комбинированную концепцию разделения, будет больше ориентирован на "неопределенное" будущее.