Я думаю непонятно, потому что статья не задумывалась, как гайд по сооружению МММ. Более того, я бы не хотел, чтобы она так позиционировалась. Поэтому предлагаю смотреть на статью, как на обзор реального кредитного протокола, который реализует возможность занимать активы на базе смарт-контрактов и блокчейна. А вот то, что можно построить поверх AAVE, используя flash loans или обычный заем, все это за рамками этой статьи.
Конечно, разные проекты используют кредитные протоколы. И да, они могут быть полезными для людей, а могут быть "полезными" только для конкретного человека.
Thegraph стремиться к децентрализации, можно посмотреть список сетей, которые уже поддерживают децентрализацию. Когда они начали переводить на децентрализованную сеть свой протокол, это конечно немногим усложнило работу с ним.
Мы еще практикуем поднимать собственный узел для индексации на базе thegraph, чтобы не писать собственный индексатор, когда нужно быстро и несложно. И они вроде как опенсорсные, судя по википедии и доке, не нашел обратного)
Доводилось делать проекты для Tron? Как впечатления? У меня знакомые фронты остались не очень довольны. TronWeb библиотека для взаимодействия с блокчейном неудобна, кошелек приконнектить тоже сложно (может быть просто по-другому), плюс появляется понятие энергии.
У меня у самого был опыт только использования TronBox для написания смарт-контрактов, ну как-то тоже не особо зашло.
Можете что-нибудь сказать про Tron с точки зрения разработки, как он вам?
Стоит такую работу уносить на бекенд и пусть он там синхронизирует в фоне? А на клиента отдавать готовые данные. Или если нет бекенда в проекте, то использовать индексер, например тот же TheGraph.
Хорошо подмечено, потому что я опустил там формулы для расчета значений {r, s, v}. Добавлю сюда шаги с формулами. Приватный ключ обозначим в расчетах, как d.
Упрощенный алгоритм подписи сообщения: 1. Рассчитывается хеш сообщения e 2. Создается случайное безопасное значение k 3. Рассчитывается точка (x1, y1) на эллиптической кривой, путем умножения k на G (это константа эллиптической кривой) 4. Рассчитывается значение r сигнатуры по формуле: r = x1 mod n. Если r = 0, то вернуться на шаг 2. 5. Рассчитывается значение s сигнатуры по формуле: s = (k ** -1) * (e + r*d) mod n. Если r = 0, то вернуться на шаг 2.
Ответ: получается, что приватный ключ используется для вычисления значения s для получения подписи сообщения.
Спасибо за корректировку. Хотел бы дополнить здесь еще, что на сколько я знаю, RSA действительно подходит для подписи тоже. При этом он быстрее шифрует, но медленнее расшифровывает и подписывает, чем DSA.
Да, да, ни в коем случае, стейкинг - это не всегда про блокировку актива. То есть стейкинг может быть реализован так, что пользователь всегда может воспользоваться своим токеном.
Более того, не всегда токен меняет владельца для того, чтобы быть застейканным. То есть формально можно говорить, что токен стейкается, а фактически в коде смарт-контракта меняется флажок `isStaked = true;` Что позволяет по сути делать тоже самое: определять для токена два состояния: staked и unstaked. Но вот можно ли этот механизм с флажком назвать стейкингом? Я больше склоняюсь, к тому что нет. Потому что семантически stake подразумевает что-то куда-то поставить, отдать, а в этом случае этого не происходит.
Для меня вот долгое время, когда я начинал, была неочевидна разница между стекать актив и блокировать (lock) активы. И там и там, применяется смарт-контракт, куда пользователь отдает свои активы. Но разница в том, что stake подразумевает, что пользователь будет получать что-то взамен: вознаграждение, привилегии и так далее. Блокировка в свою очередь, ничего этого не дает. Блокировка используется для того, чтобы публично показать, что ты гарантируешь полное отсутствие движения своих активов на какой-то период времени. И это все для чего нужна блокировка. Я часто встречал это в ланчпадах, когда новые проекты, которые не вышли на листинг, блокируют активы, чтобы показать своему сообществу, что они не заинтересованы сливать активы и проект сразу после листинга.
Еще иногда можно встретить понятие заморозка (freezing) активов. На мой взгляд, этот термин нужно использовать, когда движение активов приостанавливается на какое-то время. То есть, технически, тоже самое, что блокировка, но означает это другое. Нельзя воспользоваться активами, потому что не выполнено условие при котором их можно использовать. Или например пользователь сам хочет приостановить действие активов на время. Предположим, токен имеет срок действия 1 год и это дает привилегии, по некоторой причине пользователь знает, что полгода он не сможет использовать эти привилегии, он замораживает токен и размораживает его, когда он ему снова нужен.
В общем моя мысль такая, что все три термина: стейкинг, блокировка, заморозка очень похожи. И очень похожа их реализация. Но мне нравится стараться использовать терминологию правильно.
P.S. Видел проекты, где во время заморозки тоже можно получать вознаграждение. Как-то так)
Тогда не осталось бы темы для дискуссии) Если серьезно, то я думал о том, чтобы добавить что-то подобное, но почему-то не стал, хотелось сразу перейти к части с кодом. Спасибо, что отметил, я соглашусь, что этого не хватает.
Это делается достаточно просто: на контракте Staking хранятся активы (вознаграждение), пользователь стейкает NFT, смарт-контракт должен отдать пользователю активы после выполнения условий. Например, время стейка NFT один месяц и по истечению только этого времени, пользователь получит NFT и активы.
Что касается конкретно 100$ - это всего лишь пример. Количество получаемого вознаграждения должно быть соизмеримо экономике проекта. Но при этом по теории игр должно привлекать пользователя это делать и при этом быть полезным для проекта.
Если говорить о чуть более реальном использовании. То это может работать следующим образом. Пользователь стейкает NFT, за это он получает токен протокола (это мало кому известный ERC-20 токен), через какое-то время протокол выходит на листинг и на биржах появляется ликвидность этого токена. Пользователь может обменять это актив или продолжить его хранить. Получается, что токен становится реальным активом. Проекту это дает своего рода способ распространения своего токена. А дальше этот токен ERC-20 может иметь какой-то свой вариант использования, например быть токеном для голосования. Если токен уже листится на бирже, то всегда можно использовать ораукулы внутри смарт-контрактов, чтобы сделать честное начисление вознаграждения. Это в случае, если количество вознаграждения зависит от стоимости токена вознаграждения. Пример я придумал из головы)
При чем тут шерсть?) И почему стричь?) Конечно у ERC-721 есть плохая репутация, но она связана больше с применением, в этом ключе не поспоришь. Но есть же и положительные моменты.
Например: - Игровые проекты. Часто используют стандарт для токенизации персонажей и шмоток. Очень удобно хранить информации о предмете, а для обмена между пользователями можно использовать сторонние маркетплейсы или делать собственное решение. - RWA. Здесь только токенизация для покупки активов, обмена. Здесь блокчейн и ERC-721 позволяет ассоциировать пользователя с реальным активом. Есть тут проблемы с юридической стороной вопроса, не берусь прогнозировать найдется ли решение (хотя проекты есть). Есть проблемы и стехнической стороны, как в блокчейн доставлять данные об активах, чтобы им можно было доверять. Такое решают оракулами, ну либо не решают вовсе, что не очень хорошо. - Входной билет. Наличие токена позволяет предоставить доступ пользователя к ресурсам проекта, платформы. И здесь хорошо работает свойство - non fungible. Один токен - один пользователь. Некоторые проекты строят на этом процесс авторизации. - Право владения. Тут можно сразу вспомнить Uniswap V3, там ERC-721 доказывает право владения активами для поставщиков ликвидности. На мой взгляд, в свое время это было хорошее решение.
Ну а теперь возвращаясь к статье. Зачем может понадобиться стейкать ERC-721? Возьму в пример игровой проект. Там часто делают, что токен (персонаж или предмет) должен быть застейкан, чтобы быть доступным для исопльзования в игре и анстекнут, чтобы была возможность обменивать токен. Отдать другу, продать на маркетплейсе. Этот механизм нужен для того, чтобы пользователь не могу передать токен и продолжать его использовать в игре какое-то время. Это возможно потому что технически между транзакцией и применением транзакции в игре проходит время. Чтобы избежать таких проблем использует подход со стейкингом токена.
Именно поэтому статья нацелена на разбор механизма стейкинга NFT, который может пригодится для решения множества задач в разработке. Мне очень сложно судить "дохлая ли это овца?". Поэтому я не возьмусь утверждать. Но если посмотреть на defilama, то проекты в категории Nft Marketplace на 25 месте (с ними же отождествляется в первую очередь NFT) и Combined TVL равен $208,5m. Но есть же еще категории проектов, где стейкинг NFT может тоже применяться: Lending, Dexes, RWA, Launchpad, NFT Lending, Gaming и так далее. Во всех этих предметных областях можно успешно применять стейкинг NFT для решения своих задач.
Есть несколько критически важных советов по смарт-контракту: 1. Хранить пароль пользователя на смарт-контракте большая ошибка. Любой разработчик, зная, как устроен storage смарт-контракта сможет этот пароль увести. Нашел первую попавшуюся статью на эту тему. Даже если переменные приватные, их все равно можно считать. Хранить пароли на блокчейне - табу. 2. Хранить сами твиты в блокчейне - дорого. Чем больше будет задействовано storage для хранения данных, тем дороже будут стоить транзакции. Я бы предложил посмотреть в сторону хранения данных off-chain. Например, можно использовать ipfs для хранения информации о твитах, а на блокчейне хранить только ссылки на ipfs.
И мне просто любопытно, почему truffle? Почему не hardhat или еще лучше foundry?)
Блокчейн нужен для прозрачной работы DAO (можно смотреть на это, как на базу данных, которой можно доверять) и для исполнения смарт-контрактов, смарт-контракты нужны для фиксации правил работы DAO и исполнения принимаемых решений, смарт-контракты токенов для гибкости настройки DAO (нужно проверять право участника на принятие решения, нужно учитывать его вес в принятии решения, нужно давать возможность делегировать голоса и так далее).
Я не сильно силен в сфере ЭЦП за пределами блокчейна, но на сколько я знаю, там используются центры сертификации, задача которых подтверждать валидность ключей шифрования и соотносить владельца с его ЭЦП. Это своего рода третья сторона или точка отказа, которая может быть скомпрометирована. Использование блокчейна позволяет избежать подобной проблемы. У меня получилось ответить?)
инструмент, который должен был бы упростить управление,
Я не думаю, что DAO это про упрощение. Внедрение DAO в процесс или в протокол всегда будет так или иначе увеличивать время принятия решений, потому что нужно проводить раунды голосования, будет нести в себе затраты по работе с участниками (обучение, информирование, убеждение и тому подобное). Из-за своей природы (реализации на смарт-контрактах) система будет менее гибкая, более сложная для обновлений и поддержки.
Я бы сказал, что DAO - это больше про прозрачность, коллективную ответственность, вовлеченность, честность организации перед своими участниками, возможно равенство (но тут уже зависит от реализации).
оторвался от реальности и живёт своей собственной бессмысленной жизнью
Мне кажется, что это высказывание верно отчасти. Я буду говорить про протоколы так или иначе связанные с блокчейн технологией, потому что это моя специализация. Много из протоколов говорят о DAO, часть из них стремиться построить свое комьюнити через DAO (этот процесс может быть долгим, потому что все-таки, если протокол не работает по своему первоначальному назначению, то нет смысла начинать строить DAO). Конечно есть протоколы, которые и не планируют этим заниматься. Однако, если смотреть на крупные, серьезные протоколы, например, Uniswap, Aave, MakerDao (можно посмотреть на defilama, сколько средств заблокировано в этих протоколах, чтобы понимать про их значимость) в каком то виде работают над тем, чтобы управлять своим протоколом, пытаясь задействовать свое комьюнити. Я считаю, что это большая и сложная работа, которая заслуживает уважения. Да, там не все так гладко и просто, не всегда прозрачно и децентрализовано, но работа в этом направление ведется и это здорово.
Есть ли пример успешного внедрения технологии, приносящего ощутимую пользу и доход в реальном мире
Вот тут вы правы, в реальном мире (не в блокчейне, не связанным с криптой) эта технология малоприменима. Я тоже не знаю успешных и известных компаний, которые бы смогли как-то это реализовать. Я со своей стороны сейчас вижу так, что DAO не отделимо от блокчейнов, протоколов на блокчейне, мира web3 (хотя я не очень люблю использовать этот термин), потому что как минимум, основой построения DAO выступают смарт-контракты и блокчейны, которые эти смарт-контракты исполняют.
Конечно новые технологии надо пробовать, но мне кажется, этот случай — булшит ради булшита
Я тоже за то, что нужно пробовать и кто знает, в какую форму в итоге технология может перейти) Крупные протоколы, работали и работают над этим. Возможно это окажется булшитом, а возможно и нет, время покажет)
На самом деле, отвечу за нашу компанию, у нас просто скопились материалы, которыми нам хочется поделиться. Это легко проследить по нашему репозиторию, где мы работаем над этими материалами. Для меня сейчас самого стало открытием, что первый коммит мы сделали чуть больше года назад. Изначально мы задумывали сборник статей для внутреннего использования, но наша внутренняя корпоративная культура такая, что мы стараемся делиться подобными материалами, что мы и делаем)
Нам с коллегами нравится еще Phalcon, но Tenderly тоже используем)
Я думаю, что рассчитывать на то, что старые токены начнут поддерживать permit не стоит, потому что большинство токенов не используют шаблон upgradeable в своих контрактах, а деплоить новый токен (с permit функционалом) автоматически означает смену адреса и поднимает вопрос миграции пользователей на новый токен, да и с ликвидностью в сервисах (биржах, лендинг протоколах) надо что-то тоже делать. Подобный процесс будет очень затратным)
Я думаю непонятно, потому что статья не задумывалась, как гайд по сооружению МММ. Более того, я бы не хотел, чтобы она так позиционировалась. Поэтому предлагаю смотреть на статью, как на обзор реального кредитного протокола, который реализует возможность занимать активы на базе смарт-контрактов и блокчейна. А вот то, что можно построить поверх AAVE, используя flash loans или обычный заем, все это за рамками этой статьи.
Конечно, разные проекты используют кредитные протоколы. И да, они могут быть полезными для людей, а могут быть "полезными" только для конкретного человека.
А если весь этот криптоскам приводит инвестиции в индустрию, это хорошо или плохо?)
Thegraph стремиться к децентрализации, можно посмотреть список сетей, которые уже поддерживают децентрализацию. Когда они начали переводить на децентрализованную сеть свой протокол, это конечно немногим усложнило работу с ним.
Мы еще практикуем поднимать собственный узел для индексации на базе thegraph, чтобы не писать собственный индексатор, когда нужно быстро и несложно. И они вроде как опенсорсные, судя по википедии и доке, не нашел обратного)
Доводилось делать проекты для Tron? Как впечатления? У меня знакомые фронты остались не очень довольны. TronWeb библиотека для взаимодействия с блокчейном неудобна, кошелек приконнектить тоже сложно (может быть просто по-другому), плюс появляется понятие энергии.
У меня у самого был опыт только использования TronBox для написания смарт-контрактов, ну как-то тоже не особо зашло.
Можете что-нибудь сказать про Tron с точки зрения разработки, как он вам?
Стоит такую работу уносить на бекенд и пусть он там синхронизирует в фоне? А на клиента отдавать готовые данные. Или если нет бекенда в проекте, то использовать индексер, например тот же TheGraph.
Хорошо подмечено, потому что я опустил там формулы для расчета значений {r, s, v}.
Добавлю сюда шаги с формулами.
Приватный ключ обозначим в расчетах, как
d.Упрощенный алгоритм подписи сообщения:
1. Рассчитывается хеш сообщения
e2. Создается случайное безопасное значение
k3. Рассчитывается точка
(x1, y1)на эллиптической кривой, путем умножения k на G (это константа эллиптической кривой)4. Рассчитывается значение
rсигнатуры по формуле:r = x1 mod n. Еслиr = 0, то вернуться на шаг 2.5. Рассчитывается значение
sсигнатуры по формуле:s = (k ** -1) * (e + r*d)mod n. Еслиr = 0, то вернуться на шаг 2.Ответ: получается, что приватный ключ используется для вычисления значения
sдля получения подписи сообщения.Спасибо за корректировку. Хотел бы дополнить здесь еще, что на сколько я знаю, RSA действительно подходит для подписи тоже. При этом он быстрее шифрует, но медленнее расшифровывает и подписывает, чем DSA.
Тоже интересно, а куда отнести zksync, cardano, ton, solana? Все это тоже в воздухе?
Да, да, ни в коем случае, стейкинг - это не всегда про блокировку актива. То есть стейкинг может быть реализован так, что пользователь всегда может воспользоваться своим токеном.
Более того, не всегда токен меняет владельца для того, чтобы быть застейканным. То есть формально можно говорить, что токен стейкается, а фактически в коде смарт-контракта меняется флажок `isStaked = true;` Что позволяет по сути делать тоже самое: определять для токена два состояния: staked и unstaked. Но вот можно ли этот механизм с флажком назвать стейкингом? Я больше склоняюсь, к тому что нет. Потому что семантически stake подразумевает что-то куда-то поставить, отдать, а в этом случае этого не происходит.
Для меня вот долгое время, когда я начинал, была неочевидна разница между стекать актив и блокировать (lock) активы. И там и там, применяется смарт-контракт, куда пользователь отдает свои активы. Но разница в том, что stake подразумевает, что пользователь будет получать что-то взамен: вознаграждение, привилегии и так далее. Блокировка в свою очередь, ничего этого не дает. Блокировка используется для того, чтобы публично показать, что ты гарантируешь полное отсутствие движения своих активов на какой-то период времени. И это все для чего нужна блокировка. Я часто встречал это в ланчпадах, когда новые проекты, которые не вышли на листинг, блокируют активы, чтобы показать своему сообществу, что они не заинтересованы сливать активы и проект сразу после листинга.
Еще иногда можно встретить понятие заморозка (freezing) активов. На мой взгляд, этот термин нужно использовать, когда движение активов приостанавливается на какое-то время. То есть, технически, тоже самое, что блокировка, но означает это другое. Нельзя воспользоваться активами, потому что не выполнено условие при котором их можно использовать. Или например пользователь сам хочет приостановить действие активов на время. Предположим, токен имеет срок действия 1 год и это дает привилегии, по некоторой причине пользователь знает, что полгода он не сможет использовать эти привилегии, он замораживает токен и размораживает его, когда он ему снова нужен.
В общем моя мысль такая, что все три термина: стейкинг, блокировка, заморозка очень похожи. И очень похожа их реализация. Но мне нравится стараться использовать терминологию правильно.
P.S. Видел проекты, где во время заморозки тоже можно получать вознаграждение. Как-то так)
Тогда не осталось бы темы для дискуссии)
Если серьезно, то я думал о том, чтобы добавить что-то подобное, но почему-то не стал, хотелось сразу перейти к части с кодом. Спасибо, что отметил, я соглашусь, что этого не хватает.
Это делается достаточно просто: на контракте Staking хранятся активы (вознаграждение), пользователь стейкает NFT, смарт-контракт должен отдать пользователю активы после выполнения условий. Например, время стейка NFT один месяц и по истечению только этого времени, пользователь получит NFT и активы.
Что касается конкретно 100$ - это всего лишь пример. Количество получаемого вознаграждения должно быть соизмеримо экономике проекта. Но при этом по теории игр должно привлекать пользователя это делать и при этом быть полезным для проекта.
Если говорить о чуть более реальном использовании. То это может работать следующим образом. Пользователь стейкает NFT, за это он получает токен протокола (это мало кому известный ERC-20 токен), через какое-то время протокол выходит на листинг и на биржах появляется ликвидность этого токена. Пользователь может обменять это актив или продолжить его хранить. Получается, что токен становится реальным активом. Проекту это дает своего рода способ распространения своего токена. А дальше этот токен ERC-20 может иметь какой-то свой вариант использования, например быть токеном для голосования.
Если токен уже листится на бирже, то всегда можно использовать ораукулы внутри смарт-контрактов, чтобы сделать честное начисление вознаграждения. Это в случае, если количество вознаграждения зависит от стоимости токена вознаграждения.
Пример я придумал из головы)
При чем тут шерсть?) И почему стричь?) Конечно у ERC-721 есть плохая репутация, но она связана больше с применением, в этом ключе не поспоришь. Но есть же и положительные моменты.
Например:
- Игровые проекты. Часто используют стандарт для токенизации персонажей и шмоток. Очень удобно хранить информации о предмете, а для обмена между пользователями можно использовать сторонние маркетплейсы или делать собственное решение.
- RWA. Здесь только токенизация для покупки активов, обмена. Здесь блокчейн и ERC-721 позволяет ассоциировать пользователя с реальным активом. Есть тут проблемы с юридической стороной вопроса, не берусь прогнозировать найдется ли решение (хотя проекты есть). Есть проблемы и стехнической стороны, как в блокчейн доставлять данные об активах, чтобы им можно было доверять. Такое решают оракулами, ну либо не решают вовсе, что не очень хорошо.
- Входной билет. Наличие токена позволяет предоставить доступ пользователя к ресурсам проекта, платформы. И здесь хорошо работает свойство - non fungible. Один токен - один пользователь. Некоторые проекты строят на этом процесс авторизации.
- Право владения. Тут можно сразу вспомнить Uniswap V3, там ERC-721 доказывает право владения активами для поставщиков ликвидности. На мой взгляд, в свое время это было хорошее решение.
Ну а теперь возвращаясь к статье. Зачем может понадобиться стейкать ERC-721? Возьму в пример игровой проект. Там часто делают, что токен (персонаж или предмет) должен быть застейкан, чтобы быть доступным для исопльзования в игре и анстекнут, чтобы была возможность обменивать токен. Отдать другу, продать на маркетплейсе. Этот механизм нужен для того, чтобы пользователь не могу передать токен и продолжать его использовать в игре какое-то время. Это возможно потому что технически между транзакцией и применением транзакции в игре проходит время. Чтобы избежать таких проблем использует подход со стейкингом токена.
Именно поэтому статья нацелена на разбор механизма стейкинга NFT, который может пригодится для решения множества задач в разработке. Мне очень сложно судить "дохлая ли это овца?". Поэтому я не возьмусь утверждать. Но если посмотреть на defilama, то проекты в категории Nft Marketplace на 25 месте (с ними же отождествляется в первую очередь NFT) и Combined TVL равен $208,5m. Но есть же еще категории проектов, где стейкинг NFT может тоже применяться: Lending, Dexes, RWA, Launchpad, NFT Lending, Gaming и так далее. Во всех этих предметных областях можно успешно применять стейкинг NFT для решения своих задач.
Статья была бы на час чтения (если говорить про объекты доступа к данным), получился бы темный лес 😅
Есть несколько критически важных советов по смарт-контракту:
1. Хранить пароль пользователя на смарт-контракте большая ошибка. Любой разработчик, зная, как устроен storage смарт-контракта сможет этот пароль увести. Нашел первую попавшуюся статью на эту тему. Даже если переменные приватные, их все равно можно считать. Хранить пароли на блокчейне - табу.
2. Хранить сами твиты в блокчейне - дорого. Чем больше будет задействовано storage для хранения данных, тем дороже будут стоить транзакции. Я бы предложил посмотреть в сторону хранения данных off-chain. Например, можно использовать ipfs для хранения информации о твитах, а на блокчейне хранить только ссылки на ipfs.
И мне просто любопытно, почему truffle? Почему не hardhat или еще лучше foundry?)
Блокчейн нужен для прозрачной работы DAO (можно смотреть на это, как на базу данных, которой можно доверять) и для исполнения смарт-контрактов, смарт-контракты нужны для фиксации правил работы DAO и исполнения принимаемых решений, смарт-контракты токенов для гибкости настройки DAO (нужно проверять право участника на принятие решения, нужно учитывать его вес в принятии решения, нужно давать возможность делегировать голоса и так далее).
Я не сильно силен в сфере ЭЦП за пределами блокчейна, но на сколько я знаю, там используются центры сертификации, задача которых подтверждать валидность ключей шифрования и соотносить владельца с его ЭЦП. Это своего рода третья сторона или точка отказа, которая может быть скомпрометирована. Использование блокчейна позволяет избежать подобной проблемы.
У меня получилось ответить?)
Добавлю немножко своих мыслей)
Я не думаю, что DAO это про упрощение. Внедрение DAO в процесс или в протокол всегда будет так или иначе увеличивать время принятия решений, потому что нужно проводить раунды голосования, будет нести в себе затраты по работе с участниками (обучение, информирование, убеждение и тому подобное). Из-за своей природы (реализации на смарт-контрактах) система будет менее гибкая, более сложная для обновлений и поддержки.
Я бы сказал, что DAO - это больше про прозрачность, коллективную ответственность, вовлеченность, честность организации перед своими участниками, возможно равенство (но тут уже зависит от реализации).
Мне кажется, что это высказывание верно отчасти. Я буду говорить про протоколы так или иначе связанные с блокчейн технологией, потому что это моя специализация. Много из протоколов говорят о DAO, часть из них стремиться построить свое комьюнити через DAO (этот процесс может быть долгим, потому что все-таки, если протокол не работает по своему первоначальному назначению, то нет смысла начинать строить DAO). Конечно есть протоколы, которые и не планируют этим заниматься. Однако, если смотреть на крупные, серьезные протоколы, например, Uniswap, Aave, MakerDao (можно посмотреть на defilama, сколько средств заблокировано в этих протоколах, чтобы понимать про их значимость) в каком то виде работают над тем, чтобы управлять своим протоколом, пытаясь задействовать свое комьюнити. Я считаю, что это большая и сложная работа, которая заслуживает уважения. Да, там не все так гладко и просто, не всегда прозрачно и децентрализовано, но работа в этом направление ведется и это здорово.
Вот тут вы правы, в реальном мире (не в блокчейне, не связанным с криптой) эта технология малоприменима. Я тоже не знаю успешных и известных компаний, которые бы смогли как-то это реализовать. Я со своей стороны сейчас вижу так, что DAO не отделимо от блокчейнов, протоколов на блокчейне, мира web3 (хотя я не очень люблю использовать этот термин), потому что как минимум, основой построения DAO выступают смарт-контракты и блокчейны, которые эти смарт-контракты исполняют.
Я тоже за то, что нужно пробовать и кто знает, в какую форму в итоге технология может перейти) Крупные протоколы, работали и работают над этим.
Возможно это окажется булшитом, а возможно и нет, время покажет)
На самом деле, отвечу за нашу компанию, у нас просто скопились материалы, которыми нам хочется поделиться. Это легко проследить по нашему репозиторию, где мы работаем над этими материалами. Для меня сейчас самого стало открытием, что первый коммит мы сделали чуть больше года назад. Изначально мы задумывали сборник статей для внутреннего использования, но наша внутренняя корпоративная культура такая, что мы стараемся делиться подобными материалами, что мы и делаем)
Нам с коллегами нравится еще Phalcon, но Tenderly тоже используем)
Я думаю, что рассчитывать на то, что старые токены начнут поддерживать permit не стоит, потому что большинство токенов не используют шаблон upgradeable в своих контрактах, а деплоить новый токен (с permit функционалом) автоматически означает смену адреса и поднимает вопрос миграции пользователей на новый токен, да и с ликвидностью в сервисах (биржах, лендинг протоколах) надо что-то тоже делать. Подобный процесс будет очень затратным)
Нравится эта мысль. Ни добавить, ни прибавить)
А как в этом проекте используется IPFS?