Как много из всех md файлов (агентов, claude.md, pipeline.md и т.д.) пишется руками? Как много нужно настраивать руками? Или это все пишется тоже с помощью клода?
Звучит так, как-будто это очень высокорисковый актив. За время существования Ethena были случаи, когда они были на грани дефолта из-за отрицательного фандинга? Или пока можно сказать, что рынок не давал долгого отрицательного фандинга?
используя обмен валют, покупал одну валюту за другую, потом менял на третью и затем третью менял на первую, получая при этом профит.
Под это определение больше подходит арбитраж. Атака на оракул - это немного другое. Есть разные виды, но задача одна: заставить оракул выдать некорректные цены.
В web3 в принципе мало придумано чего-то нового. Большинство механик взято из традиционных финансов.
Используйте для внутриигровых предметов нфтишки, которые будут хранить метаданные товаров с ссылкой на ipfs. На базе нфтишек можно легко сделать вторичный рынок предметов без участия бекенда. Логика такая: игрок покупает предмет, передает эфир на контракт и ему минтится нфт (ERC-721, ERC-1155, ERC-6909).
Продавайте предметы за фиксированную цену в долларах, то есть предмет стоит 100 условно сто долларов. То есть количество эфира, взимаемое за предмет нужно рассчитывать прямо на смарт-контракте, а стоимость эфира брать из оракула, например Chainlink. Сейчас у вас товар может резко просеть в цене следом за курсом нативной валюты. Для реального бизнеса, в вашем случае игры, предметы будут отдаваться даром.
Сделать хотя бы эти два пункта и уже проект будет чуть-чуть серьезнее.
Все так и есть. Единственно, если будет, что спасать. Потому что мейкер устанавливает виртуальный баланс для стратегии, а это, как дать апрув. Если стратегия взломана, то скорее всего мейкер потеряет активы в пределах виртуального баланса.
С другой стороны может быть это будет стимулировать мейкера реализовать собственные механизмы защиты: при перекосе реальных балансов по активам (когда из-за ошибок математики одного токена забирают больше, чем второго например) снимать виртуальные балансы. Ну и конечно не устанавливать виртуальные балансы больше, чем того требует стратегия, чтобы минимизировать потери.
А почему проекты мигрируют на Polymesh? Я так понял Polymesh - это блокчейн для RWA с контрактами на Rust, у него что-то из коробки есть для запуска RWA, что делает его выгоднее, чем EVM совместимый L2 c ERC-3643?
В общем, главный вопрос, что выбирать для реализации RWA Polymesh или EVM совместимый L2 c ERC-3643?
Это не белиберда. Я допускаю, что фраза "за место" просто вводит вас в заблуждение и вы ищите истину не ради того, чтобы докопаться до формулировки.
Имеется ввиду, что при обмене токена на токен в Uniswap v4 можно отказаться от получения токена на свой кошелек, вместо (возможно более удачное определение, чем "за место") этого получить внутренний токен ERC-6909.
> Где вы такое в стандарте нашли?
В стандарте такого нет. Это не касается стандарта. Это описание того, как стандарт ERC-6909 используется в Uniswap v4. Это их конкретный кейс. Поэтому читать нужно не стандарт, а доку Uniswap. Вот тут.
> На английском слово 'место' будет 'place', наверное. Я вот просмотрел стандарт и ничего ни про какой обмен на placе не вижу. Может это проблема перевода?
Это не проблемы перевода. Статья отображает мои собственные мысли, это не перевод. Но из документации Uniswap идеально подходит: "Instead of choosing to move tokens in/out of the PoolManager, developers can opt-in and leave the ERC-20 tokens within the PoolManager. In exchange, the PoolManager can mint them an ERC-6909 token representing their claim. In subsequent interactions requiring paying tokens, users will not need to transfer ERC-20 tokens into the PoolManager - users can simply burn some (or all) of their claim tokens they have"
Классический обмен, например USDT на USDC, работает следующим образом: 1. Пользователь отдает USDT смарт-контракту Uniswap 2. Смарт-контракт Uniswap взамен отдает USDC
В Uniswap 4 классический обмен также работает, но за место USDC можно получить эквивалент ERC-6909 в качестве доказательства того, что USDC пользователя остается на смарт-контракте. Позже можно вернуть ERC-6909 и получить свой USDC. Или вернуть ERC-6909, провести свап USDC на любой другой токен. То есть уже флоу может выглядеть следующим образом: 1. Пользователь отдает USDT смарт-контракту Uniswap 2. Смарт-контракт Uniswap взамен минтит ERC-6909 3. Пользователь хочет получить WETH. Для этого он отдает смарт-контракту ERC-6909, под капотом происходит обмен его USDC на WETH. 4. Смарт-контракт отдает WETH.
Здесь ERC-6909 позволил избежать трансфера USDC при первом обмене до пользователя и последующий трансфер при втором обмене до смарт-контракта. Вместо этого пользователь получал ERC-6909, что дешевле по газу, чем трансферы USDC.
Прорабатываются какие-то варианты абстракции аккаунта пользователя?
Предположим у меня нет друга, который может за меня подписать транзакцию, то тогда мне все равно сначала придется самому разбираться с биткоином, чтобы послать транзакцию. И это включает в себя то, что мне необходимо добыть биткоин, придется идти в цексы, это еще один новый мир для изучения. И получится, что я смогу вернуться к регистрации почты в Eppie через недельку.
Я не думаю, что была задача переиначить существующие аббревиатуры. Скорее просто так получилось органически, что появился термин Decentralized Autonomous Organization, который сокращается до DAO.
У этого термина даже авторства нет как-такого, сообщество обсуждало, Виталик его прогревал, проект The DAO популяризировал. Поэтому то что это совпало с Data Access Object - просто совпадение.
Да, хорошее замечание. Пользователи, которые общаются c Uniswap через интерфейс. Их вызовы работают через UniversalRouter.
Интеграторы могут работать с PoolManager-ом напрямую, я не вижу в этом препятствий, но нужно будет как-минимум реализовать callback логику, которая отвечает за разблокировку пула перед совершением операции.
Если смотреть доку по взаимодействию с контрактами четвертой версии, например для свопа, то там все-таки предлагается строить вызов через UniversalRouter.
Не очень качественный оригинал + не очень качественный перевод. То что это неисчерпывающее руководство - это точно. Если бы я был новичком, то сомневаюсь, что я бы понял все. Ниже поясню несколько пунктов, которые бросаются в глаза:
Смарт‑контракты — это самоисполняющиеся контракты с условиями соглашения, записанными непосредственно в коде.
Смарт‑контракт - это программа, которая хранится и запускается внутри блокчейна. Зачастую неизменяемая, но с оговоркой, потому что в том же Ethereum есть подход, который позволит изменять код смарт-контракта (upgradeable smart contracts). Абстрактно можно сказать, что смарт-контракт - это как класс из ООП по семантике.
Типы данных в Solidity:
Перечисленные в статье типы ну уж слишком упрощены. Смотрите документацию. Там выделяется аж три группы: - Value (int/uint от 8 до 256, boolean, address, string literals, в общем там много интересного), - Reference (string, bytes, различные массивы, структуры) - Mappings. Это то про что забыли в статье напрочь. Как можно про это забыть и говорить исчерпывающая дока:)
Для разработчика здесь важно не просто знать типы, а понимать как они кодируются при вызовах, чтобы уметь понимать, что происходит в транзакциях.
Solidity поддерживает традиционные структуры управления, такие как if, for и while.
Уточним, что ключевых слов чуть больше if, else, while, do, for, break, continue, return
Ошибки переполнения и недополнения возникают
Если что это классическая проблема с Overflow and Underflow, когда значение переменной, выходит за пределы своего типа. У uint8 переменной диапазон от 0 до 255.
Использование SafeMath: Арифметические переполнения/недополнения
Устаревшая информация! Начиная с версии компилятора 0.8.0 ошибки связанные с переполнением обрабатываются внутри компилятора и нет смысла использовать стороннюю библиотеку SafeMath.
----------------------------------------
Паттернов гораздо больше, чем один, уязвимостей не счесть, стандарты ERC исчисляются четырехзначными числами (и не всегда имеют прямое отношения к смарт-контрактам).
Если читателю стало интересно, то он может продолжить разбор статьи по косточкам, ставя под сомнение каждое предложение и разбираясь вглубь самостоятельно, чтобы убедиться, что информация правильная.
Чтобы качественно сравнить несколько дексов - это должна быть прям отдельная статья! Слишком много всего нужно объять. Пока даже не представляю, какой результат может быть в таком обзоре.
Сейчас у нас пока стратегия обзора отдельных протоколов: - Из Curve уже смотрели часть про StableSwap и войну за ликвидность. - Обзор Aerodrome есть, но он пока не опубликован - Balancer есть в планах - С DackieSwap если честно не доводилось сталкиваться, нужно посмотреть.
> Можно добавить раздел рисков в статью.
Я как разработчик вижу риски в новой версии в хуках. Мы тоже разберем это в отдельной статье. У нас сейчас уже почти готова статья с разбором архитектуры, хуки следующие. Там планируем статью в виде гайда по написанию своего хука.
Возможно запускать SMTChecker из под Foundry? Я знаю, что Foundry использует под капотом solc для компиляции. Это было бы более удобно, потому что в разработке смарт-контрактов вряд ли кто-то компилирует через solc.
Нет, не требует. Это работает во всех сетях, которые поддерживаются Layer Zero. А сам по себе OFT - это токен, который будет построен на базе Layer Zero, то есть будет использовать механизм обмена сообщениями между чейнами, чтобы поддерживать свой supply.
Да, есть такое! Я при чем сначала столкнулся с тем, что расширение метамаск перестал давать перейти на страничку Curve. Кто-то даже ишью успел создать на разблокировку Curve. А потом увидел новость про взлом домена.
> вы можете совершенно безопасно располагать не менееэлементов данных размером слот в каждом таком массиве
Мне просто стало интересно, сколько будут занимать такие данные, жпт говорит, что это. примерно ~10⁷⁰ гигабайт. Это просто физически невозможно провернуть в Ethereum. Это огромное число.
Что касается маппингов
На сколько я понимаю коллизии могут возникнуть в использовании keccak256, но не mapping, потому что mapping использует хеш(key, slot). Так как для получения коллизии нужен один mapping, в котором два ключа дадут одинаковый хеш.
Но тут у меня вопрос, на сколько симуляция на урезанном адресном пространстве валидно? Симуляция keccak256 на K < 256 битах не отражает реальность, потому что в EVM хеш всегда 256-битный на сколько я понимаю.
На мой взгляд бояться наступления коллизий надо при использовании assembly вставок. Вот там, когда ручками по слотам ходишь легко допустить ошибку.
Как много из всех md файлов (агентов, claude.md, pipeline.md и т.д.) пишется руками? Как много нужно настраивать руками? Или это все пишется тоже с помощью клода?
Звучит так, как-будто это очень высокорисковый актив. За время существования Ethena были случаи, когда они были на грани дефолта из-за отрицательного фандинга? Или пока можно сказать, что рынок не давал долгого отрицательного фандинга?
Под это определение больше подходит арбитраж. Атака на оракул - это немного другое. Есть разные виды, но задача одна: заставить оракул выдать некорректные цены.
В web3 в принципе мало придумано чего-то нового. Большинство механик взято из традиционных финансов.
Используйте для внутриигровых предметов нфтишки, которые будут хранить метаданные товаров с ссылкой на ipfs. На базе нфтишек можно легко сделать вторичный рынок предметов без участия бекенда. Логика такая: игрок покупает предмет, передает эфир на контракт и ему минтится нфт (ERC-721, ERC-1155, ERC-6909).
Продавайте предметы за фиксированную цену в долларах, то есть предмет стоит 100 условно сто долларов. То есть количество эфира, взимаемое за предмет нужно рассчитывать прямо на смарт-контракте, а стоимость эфира брать из оракула, например Chainlink. Сейчас у вас товар может резко просеть в цене следом за курсом нативной валюты. Для реального бизнеса, в вашем случае игры, предметы будут отдаваться даром.
Сделать хотя бы эти два пункта и уже проект будет чуть-чуть серьезнее.
Все так и есть. Единственно, если будет, что спасать. Потому что мейкер устанавливает виртуальный баланс для стратегии, а это, как дать апрув. Если стратегия взломана, то скорее всего мейкер потеряет активы в пределах виртуального баланса.
С другой стороны может быть это будет стимулировать мейкера реализовать собственные механизмы защиты: при перекосе реальных балансов по активам (когда из-за ошибок математики одного токена забирают больше, чем второго например) снимать виртуальные балансы. Ну и конечно не устанавливать виртуальные балансы больше, чем того требует стратегия, чтобы минимизировать потери.
А почему проекты мигрируют на Polymesh? Я так понял Polymesh - это блокчейн для RWA с контрактами на Rust, у него что-то из коробки есть для запуска RWA, что делает его выгоднее, чем EVM совместимый L2 c ERC-3643?
В общем, главный вопрос, что выбирать для реализации RWA Polymesh или EVM совместимый L2 c ERC-3643?
Кайф! Разобрались) Надеюсь, что белиберда только в этом и статья была полезной)
Это не белиберда. Я допускаю, что фраза "за место" просто вводит вас в заблуждение и вы ищите истину не ради того, чтобы докопаться до формулировки.
Имеется ввиду, что при обмене токена на токен в Uniswap v4 можно отказаться от получения токена на свой кошелек, вместо (возможно более удачное определение, чем "за место") этого получить внутренний токен ERC-6909.
> Где вы такое в стандарте нашли?
В стандарте такого нет. Это не касается стандарта. Это описание того, как стандарт ERC-6909 используется в Uniswap v4. Это их конкретный кейс.
Поэтому читать нужно не стандарт, а доку Uniswap. Вот тут.
> На английском слово 'место' будет 'place', наверное. Я вот просмотрел стандарт и ничего ни про какой обмен на placе не вижу. Может это проблема перевода?
Это не проблемы перевода. Статья отображает мои собственные мысли, это не перевод. Но из документации Uniswap идеально подходит:
"Instead of choosing to move tokens in/out of the
PoolManager, developers can opt-in and leave the ERC-20 tokens within thePoolManager. In exchange, thePoolManagercan mint them an ERC-6909 token representing their claim. In subsequent interactions requiring paying tokens, users will not need to transfer ERC-20 tokens into thePoolManager- users can simply burn some (or all) of their claim tokens they have"Классический обмен, например USDT на USDC, работает следующим образом:
1. Пользователь отдает USDT смарт-контракту Uniswap
2. Смарт-контракт Uniswap взамен отдает USDC
В Uniswap 4 классический обмен также работает, но за место USDC можно получить эквивалент ERC-6909 в качестве доказательства того, что USDC пользователя остается на смарт-контракте. Позже можно вернуть ERC-6909 и получить свой USDC. Или вернуть ERC-6909, провести свап USDC на любой другой токен. То есть уже флоу может выглядеть следующим образом:
1. Пользователь отдает USDT смарт-контракту Uniswap
2. Смарт-контракт Uniswap взамен минтит ERC-6909
3. Пользователь хочет получить WETH. Для этого он отдает смарт-контракту ERC-6909, под капотом происходит обмен его USDC на WETH.
4. Смарт-контракт отдает WETH.
Здесь ERC-6909 позволил избежать трансфера USDC при первом обмене до пользователя и последующий трансфер при втором обмене до смарт-контракта. Вместо этого пользователь получал ERC-6909, что дешевле по газу, чем трансферы USDC.
Какую сумму надо иметь, чтобы была необходимость так замарачиваться с пенсионными накоплениями? От такого количества сервисов, голова идет кругом)
Прорабатываются какие-то варианты абстракции аккаунта пользователя?
Предположим у меня нет друга, который может за меня подписать транзакцию, то тогда мне все равно сначала придется самому разбираться с биткоином, чтобы послать транзакцию. И это включает в себя то, что мне необходимо добыть биткоин, придется идти в цексы, это еще один новый мир для изучения. И получится, что я смогу вернуться к регистрации почты в Eppie через недельку.
Я не думаю, что была задача переиначить существующие аббревиатуры. Скорее просто так получилось органически, что появился термин Decentralized Autonomous Organization, который сокращается до DAO.
У этого термина даже авторства нет как-такого, сообщество обсуждало, Виталик его прогревал, проект The DAO популяризировал. Поэтому то что это совпало с Data Access Object - просто совпадение.
И это немного странно, учитывая, что уже подъехал EIP-7702. Все таки топовые кошельки, должны поддерживать современные решения.
Я подозреваю, что кошельки, которые стартовали с поддержкой gas station сложно перевести на другие рельсы. Это только мое предположение.
Да, хорошее замечание. Пользователи, которые общаются c Uniswap через интерфейс. Их вызовы работают через UniversalRouter.
Интеграторы могут работать с PoolManager-ом напрямую, я не вижу в этом препятствий, но нужно будет как-минимум реализовать callback логику, которая отвечает за разблокировку пула перед совершением операции.
Если смотреть доку по взаимодействию с контрактами четвертой версии, например для свопа, то там все-таки предлагается строить вызов через UniversalRouter.
Не очень качественный оригинал + не очень качественный перевод. То что это неисчерпывающее руководство - это точно. Если бы я был новичком, то сомневаюсь, что я бы понял все. Ниже поясню несколько пунктов, которые бросаются в глаза:
Смарт‑контракт - это программа, которая хранится и запускается внутри блокчейна. Зачастую неизменяемая, но с оговоркой, потому что в том же Ethereum есть подход, который позволит изменять код смарт-контракта (upgradeable smart contracts). Абстрактно можно сказать, что смарт-контракт - это как класс из ООП по семантике.
Перечисленные в статье типы ну уж слишком упрощены. Смотрите документацию. Там выделяется аж три группы:
- Value (int/uint от 8 до 256, boolean, address, string literals, в общем там много интересного),
- Reference (string, bytes, различные массивы, структуры)
- Mappings. Это то про что забыли в статье напрочь. Как можно про это забыть и говорить исчерпывающая дока:)
Для разработчика здесь важно не просто знать типы, а понимать как они кодируются при вызовах, чтобы уметь понимать, что происходит в транзакциях.
Уточним, что ключевых слов чуть больше
if,else,while,do,for,break,continue,returnЕсли что это классическая проблема с Overflow and Underflow, когда значение переменной, выходит за пределы своего типа. У uint8 переменной диапазон от 0 до 255.
Устаревшая информация! Начиная с версии компилятора 0.8.0 ошибки связанные с переполнением обрабатываются внутри компилятора и нет смысла использовать стороннюю библиотеку SafeMath.
----------------------------------------
Паттернов гораздо больше, чем один, уязвимостей не счесть, стандарты ERC исчисляются четырехзначными числами (и не всегда имеют прямое отношения к смарт-контрактам).
Если читателю стало интересно, то он может продолжить разбор статьи по косточкам, ставя под сомнение каждое предложение и разбираясь вглубь самостоятельно, чтобы убедиться, что информация правильная.
Спасибо за обратную связь! Мы стараемся!
Чтобы качественно сравнить несколько дексов - это должна быть прям отдельная статья! Слишком много всего нужно объять. Пока даже не представляю, какой результат может быть в таком обзоре.
Сейчас у нас пока стратегия обзора отдельных протоколов:
- Из Curve уже смотрели часть про StableSwap и войну за ликвидность.
- Обзор Aerodrome есть, но он пока не опубликован
- Balancer есть в планах
- С DackieSwap если честно не доводилось сталкиваться, нужно посмотреть.
> Можно добавить раздел рисков в статью.
Я как разработчик вижу риски в новой версии в хуках. Мы тоже разберем это в отдельной статье. У нас сейчас уже почти готова статья с разбором архитектуры, хуки следующие. Там планируем статью в виде гайда по написанию своего хука.
Возможно запускать SMTChecker из под Foundry? Я знаю, что Foundry использует под капотом solc для компиляции. Это было бы более удобно, потому что в разработке смарт-контрактов вряд ли кто-то компилирует через solc.
Нет, не требует. Это работает во всех сетях, которые поддерживаются Layer Zero. А сам по себе OFT - это токен, который будет построен на базе Layer Zero, то есть будет использовать механизм обмена сообщениями между чейнами, чтобы поддерживать свой supply.
Да, есть такое! Я при чем сначала столкнулся с тем, что расширение метамаск перестал давать перейти на страничку Curve. Кто-то даже ишью успел создать на разблокировку Curve. А потом увидел новость про взлом домена.
Красивая конечно теория!
элементов данных размером![]()
слот в каждом таком массиве
Что касается массивов
> вы можете совершенно безопасно располагать не менее
Мне просто стало интересно, сколько будут занимать такие данные, жпт говорит, что это. примерно ~10⁷⁰ гигабайт. Это просто физически невозможно провернуть в Ethereum. Это огромное число.
Что касается маппингов
На сколько я понимаю коллизии могут возникнуть в использовании keccak256, но не mapping, потому что mapping использует хеш(key, slot). Так как для получения коллизии нужен один mapping, в котором два ключа дадут одинаковый хеш.
Но тут у меня вопрос, на сколько симуляция на урезанном адресном пространстве валидно? Симуляция keccak256 на K < 256 битах не отражает реальность, потому что в EVM хеш всегда 256-битный на сколько я понимаю.
На мой взгляд бояться наступления коллизий надо при использовании assembly вставок. Вот там, когда ручками по слотам ходишь легко допустить ошибку.