article: ERC-721-C #101
article: ERC-721-C #101
Conversation
There was a problem hiding this comment.
Я думаю в целом материал полезный, хотя стандарт ну прям спорный. Не зря столько времени считалось плохим решением добавлять подобную логику в трансферы. Мало того, так еще и такой простор для централизации. В общем попахивает стандарт)
Что касается статьи. На мой взгляд многовато деталей, но при этом нет "скилета" или структуры, т.е. минимального набора информации, которую можно вынести, но при этом это будет самая полезная инфа.
То есть мои предложения такие:
- Сократить техническую часть. Все же если нет необходимости со стандартом работать, но хочется о нем узнать - разбираться в каждой функции нет смысла. Все равно не отложится, а времени много уйдет.
- Убрать огромное количество пунктов на каждый раздел.
- В коде показывать только самые важные части, все остальные отправлять смотреть по ссылкам (кстати ссылок кое-где не хватает).
- Добавить бизнесовой части.
- Точно ли нужен такой стандарт?
- OpenSea поддерживает его только для галочки или он правда нужен?
- В конце концов кому это выгодно? Я не верю, что кто-то прям заботится о создателях контента.
- Почему нет нормального стандарта? Например ERC721A глобально не предлагает нового, а улучшает старое, а тут непонятно зачем присоседились к названию ERC721.
И еще по мелочам:
- названия функций лучше выделять скобками, например
beforeTransfer; - прийти к одному формату упоминания стандартов: например ERC721 или ERC-721. Сейчас встречаются оба, плюс субъективное мнение: ERC721C выглядит лучше, чем ERC-721-C.
Переписал статью, учел все замечания и рекомендации. Если что еще нужно поправить или дописать, дай знать пожалуйста |
There was a problem hiding this comment.
У меня неоднозначное впечатление. Как-будто оверинжениринг какой-то. Я бы не хотел где-то это использовать или ковыряться в этом пожалуй.
Читалось тяжеловато, я еще пытался найти код, но постоянно не мог найти функции, видимо пока я добрался до статьи, они уже что-то в main выкатили совсем другое. Нужно это проверить.
@bimkon144, не хочешь сделать пост рассуждение в телеграм канал про свое ощущение ERC721C? Если бы я бы писал, я бы порассуждал на тему, что как не решили проблему роялти, так и не решили, вот из последнего вот такой стандарт появился никем не утвержденный, очень и очень спорный, который привносит к простой нфтишке кучу бойлерплейта
|
|
||
| [ERC721C](https://github.com/limitbreakinc/creator-token-standards/blob/main/src/erc721c/ERC721C.sol) — это экспериментальный подход к созданию новых возможностей для работы с NFT, направленный на решение проблемы выплаты роялти авторам NFT. Несмотря на то, что этот стандарт ещё не включён в реестр Ethereum Improvement Proposals (EIPs), он предлагает механизмы для усиления защиты интересов создателей цифрового контента. Будет ли в будущем подаваться в EIPs или пойдут по пути [ERC721A](https://www.erc721a.org/) остается вопросом. | ||
|
|
||
| ERC721C предлагает решение выплаты роялти через введение дополнительных возможностей управления трансфером токенов в комплексе с использованием контракта совершения сделок - payment processor. Этот подход позволяет создателям устанавливать строгие правила, обеспечивая выполнение роялти при каждой транзакции. Основная идея заключается в предоставлении разработчикам возможности настраивать политики передачи токенов ([transfer policies](https://erc721c.com/docs/integration-guide/creator-token-standards/v4/for-creators/transfer-security)) через переопределение хуков `_beforeTokenTransfer` и `_afterTokenTransfer` в контракте токенов, с интеграцией проверки условий в процессе транзакции с использованием внешних контрактов валидаторов. |
There was a problem hiding this comment.
ERC721C предлагает решение выплаты роялти через введение дополнительных возможностей управления трансфером токенов в комплексе с использованием контракта совершения сделок - payment processor. Этот подход позволяет создателям устанавливать строгие правила, обеспечивая выполнение роялти при каждой транзакции. Основная идея заключается в предоставлении разработчикам возможности настраивать политики передачи токенов (transfer policies) через переопределение хуков _beforeTokenTransfer и _afterTokenTransfer в контракте токенов, с интеграцией проверки условий в процессе транзакции с использованием внешних контрактов валидаторов.
Мне кажется сложное предложение. Можно попроще
ERC721C предлагает перенести механизм роялти в отдельный контракт payment processor, который будет вызваться в хуках
_beforeTokenTransferи_afterTokenTransferсамого токена. Разработчики смогут настраивать политики передачи токенов.
P.S. По ссылке там это не политики, а restiction. Мне кажется нужно проверить терминологию и поменять на более корректную
|
|
||
| Несмотря на инновационность ERC721C, возникает логичный вопрос: почему существует необходимость в новом стандарте? | ||
|
|
||
| Одна из ключевых проблем текущих стандартов, таких как [ERC721](https://eips.ethereum.org/EIPS/eip-721) и [ERC1155](https://eips.ethereum.org/EIPS/eip-1155), заключается в отсутствии строгого механизма соблюдения роялти. Выплата роялти в этих стандартах зависит от платформы или конкретной реализации, а в некоторых случаях полностью игнорируется. Это приводит к тому, что создатели контента не получают справедливого вознаграждения за перепродажу их произведений на вторичном рынке. |
There was a problem hiding this comment.
Одна из ключевых проблем текущих стандартов, таких как ERC721 и ERC1155, заключается в отсутствии строгого механизма соблюдения роялти. Выплата роялти в этих стандартах зависит от платформы или конкретной реализации, а в некоторых случаях полностью игнорируется. Это приводит к тому, что создатели контента не получают справедливого вознаграждения за перепродажу их произведений на вторичном рынке.
Не совсем так. У самих ERC-721 и ERC-1155 вообще нет механизма роялти. Стандарты его вообще не регламентируют. Поэтому то маркетплейсы и реализуют роялти как хотят, а это не гарантирует совместимость роялти между маркетплейсами. Есть известный стандарт ERC-2981 о роялти, но он всего лишь описывает как передавать информацию о роялти, но не обязательно его изъятие. Само изъятие, как и использование этого стандарта опять таки на усмотрение маркетплейсов.
There was a problem hiding this comment.
Спасибо что поправил
|
|
||
| ## Архитектура и модули ERC721C | ||
|
|
||
| Creator Advanced Protection Suite (CAPS) — это набор open-source смарт-контрактов, разработанный для предоставления создателям цифрового контента полного контроля над их цифровыми активами и взаимодействиями в экосистеме Web3. CAPS включает три независимых, но взаимодополняющих продукта: [Creator Token Standards](https://github.com/limitbreakinc/creator-token-standards), Payment [Processor](https://github.com/limitbreakinc/payment-processor-v2) и [Trusted Forwarder](https://github.com/limitbreakinc/TrustedForwarder). Эти модули работают вместе, чтобы обеспечить защиту токенов, контроль над торговыми процессами. |
There was a problem hiding this comment.
Интересно, что вторая версия Payment Processor уже заархивирована, а первая нет. Может быть актуальная сейчас первая?
There was a problem hiding this comment.
Они уже задеплоили 3ю версию https://apptokens.com/docs/category/v30
Думаю просто в какой-то момент они решили вести приватную репу с новыми контрактами, не знаю зачем...
|
|
||
| На схеме ниже показана архитектура CAPS и взаимосвязь между её модулями. | ||
|
|
||
|  |
There was a problem hiding this comment.
Я по схеме не понял кто такие Trusted Forwarder, может кратко пояснить про четыре блока схемы? И для чего они.
There was a problem hiding this comment.
Согласен, добавлю
|
|
||
| Контракт предоставляет функции для создания и управления списками адресов (черные и белые списки). Создатели могут создавать новые списки и добавлять/удалять адреса или хэши контрактов: | ||
|
|
||
| - `createList(string name)` — создает новый список (черный или белый). |
There was a problem hiding this comment.
Я не нашел этих функций контракта по ссылке выше https://github.com/limitbreakinc/creator-token-contracts/blob/main/contracts/utils/CreatorTokenTransferValidator.sol
There was a problem hiding this comment.
Похоже описаны смарты не из самой последней версии. Я только поиском нашел их в каком-то коммите
There was a problem hiding this comment.
Перепроверю. У них недавно сайт обновился, может и в репе тоже
Скорее всего выкатили не только новый сайт и обновленную доку, а еще и репы успели обновить. Я перепроверю этот момент и все ссылки. Да, мне кажется что даже после урезания тех части получилось тяжело к прочтению, буду облегчать. Пост сделаю как закончу со статьей, чтобы была легка к прочтению) |
No description provided.