Delphi Digital. THORChain & Chainflip & Дорожная карта Ethereum
Развитие децентрализованного пути Биткоина набирает обороты.
1. THORChain
2. Chainflip
3. Дорожная карта Ethereum
Сейчас будет сложно, поэтому кто не знаком с THORChain рекомендую сначала прочитать статьи ниже.
THORChain
THORChain: революция в DEX сегменте
THORChain имел очень успешный 2023 год. Недавно он стал третьим по объему DEX после Uniswap и Pancakeswap и пятым крупнейшим обменником (включая CEX) для спотовой торговли BTC.
Рост объемов произошел после запуска streaming swaps (потоковых свопов). Следует отметить, что synths и savers, запущенные ранее, сыграли важную роль в эффективности потоковых свопов.
Освежим В Кратце Эволюцию THORChain
Прежде чем разбирать некоторые ключевые метрики проектов, нам сначала нужен контекст о THORChain и его недавно запущенных функциях и продуктах.
В начале своего пути бассейны THORChain полностью состояли из двойных LP, вносящих 50% Rune и 50% не-Rune активов (BTC, BNB, AVAX, ETH, USDC и т.д.). За последние 2 года THORChain сильно эволюционировал. Хотя пулы все еще сохраняют свою 50/50 формацию Rune/не-Rune, сегодня ликвидность в пулах распределяется между различными участниками с разными мотивациями. А именно, это двойные LP, держатели synth (savers и arbs), lenders и PoL (ликвидность, принадлежащая протоколу).
Кроме того, THORChain больше не ограничивается только свопами, но также поддерживает saving (счета с процентами) и лэндинг.
Хотя lending еще не доказал свою эффективность, savers и swaps широко приняты.
Synths – это мощная, уникальная разработка THORChain, которую не так-то просто понять.
Synths – это нативные активы THORChain, которые можно минтить через депозиты в пулы и сжигать через выводы из пулов. Они представляют нативные активы L1 (BTC, BNB, AVAX, ETH, USDC и т.д.).
Например, я могу сминтить 1 sBTC (синтетический BTC), внеся 1 BTC в пул BTC/RUNE. Сминченный sBTC – это нативный актив THORChain, который, при нормальных обстоятельствах, можно обменять обратно на 1 BTC (или на Rune стоимостью 1 BTC) в более поздний срок.
Коллатерал для синтов находится в пулах THORChain и, таким образом, может использоваться для свопов, savers и лэндинга. Это отличается от типичного завернутого актива, у которого коллатерал остается бездействующим.
В этом смысле синты имеют схожую функциональность с позициями dual (двойных) LP. Они способствуют ликвидности и углублению пулов.
Поскольку все пулы THORChain имеют половину Rune и половину не-Rune активов, таков и коллатерал, обеспечивающий synth. Однако, в отличие от позиций двойных LP, синты разработаны так, чтобы иметь 100% ценовую экспозицию к не-Rune активу и не подвергаться непостоянным потерям.
Этот дизайн зависит от двойных LP и держателей синтов, делающих взаимодополняющие компромиссы. Держатели синтов передают свой риск непостоянной потери двойным LP и, в свою очередь, отказываются (от части или всех) своих доходов (блоковых наград и комиссий). Двойные LP берут на себя более высокий риск непостоянных потерь и, в свою очередь, получают доходы, от которых отказались держатели синтов, что увеличивает их доходность.
Вот несколько простых, хотя и не совсем точных, интуитивных представлений о том, как двойные LP (liquidity providers) и держатели Synths влияют друг на друга.
Поскольку Synths являются долговыми обязательствами по не-Rune активу, когда Rune превосходит не-Rune актив, двойные LP захватывают часть первоначального депозита savers. Та же динамика работает и в обратном направлении. Когда Rune уступает не-Rune активу, savers захватывают часть депозита двойных LP.
Избыток или дефицит, который испытывают двойные LP, проявляется как усиленные или уменьшенные непостоянные потери (IL), в зависимости от ценовой динамики Rune по сравнению с парным активом. В пуле, загруженном Synths, двойные LP испытывают усиленные IL, когда Rune уступает, и уменьшенные IL, когда Rune превосходит. Действительно, когда Rune превосходит, двойные LP могут получить "непостоянную прибыль". Проще говоря, с Synths двойные LP получают усиленное длинное воздействие на Rune. Точные отношения можно визуализировать ниже.
Для тех, кто заинтересован в изучении больше о Synths и savers, мы рекомендуем ознакомиться c соответствующей темой в Twitter.
С PoL (ликвидность, принадлежащая протоколу) надежда заключается в том, чтобы протокол контролировал усиленное long воздействие Rune для двойных LP, поддерживая его на разумном уровне. Целевое использование Synths установлено на уровне 50% от общей глубины пула (и ограничено 60%). Если использование Synths превышает цель, сам протокол вносит двустороннюю ликвидность в пулы для снижения leverage, испытываемого двойными LP. Делается это путем изъятия Rune из Резерва, обмена половины его на не-Rune и внесения в пул. Когда использование Synths падает ниже цели, протокол делает обратное и выводит ликвидность из пулов обратно в Резерв.
Итак, для чего хороши Synths? Есть 2 способа использования Synths в сети; арбитраж и savers. Arbs приносят объем, а savers приносят ликвидность.
Arbs (то есть держатели Synths) не накапливают никаких доходов (комиссии за ликвидность + блоковые награды). Их единственная мотивация - проводить арбитраж и захватывать спред. Для этого они используют Synths, потому что Synths намного быстрее и дешевле в обращении, чем нативные активы L1, так как они существуют в блокчейне THORChain.
Например, вместо того чтобы ждать 30+ минут для арбитража пулов BTC и ETH с использованием нативных активов, arbs могут использовать Synths для свопа в эти пулы и обратно каждый блок THORChain (5-6 секунд), экономя на дорогих комиссиях Bitcoin и Ethereum. С Synths, arbs могут эффективнее корректировать цены пулов THORChain, чем раньше. Как мы увидим позже, это заложило основу для недавно запущенной функции потоковых свопов.
арбитраж с Synths (слева) против арбитража с нативными активами (справа)
Другое использование Synths - блокировать их в хранилище для дохода; то есть savers. Savers сохраняют все атрибуты Synths, а также их риски (которые будут подробно описаны в разделе о рисках), но вместо использования Synths для arbs, они блокируют их в хранилище для получения дохода. Таким образом, они вносят свой вклад в глубину пула на долгосрочной основе.
Savers и двойные LP - это два разных типа поставщиков ликвидности с разными профилями риска/вознаграждения. Цель дизайна savers - не иметь ценового воздействия на Rune и зарабатывать односторонний доход (например, BTC savers зарабатывают доход в BTC на свои депозиты BTC). Доход для savers обычно намного ниже, чем у двойных LP.
Savers привлекают новый набор поставщиков ликвидности, которые хотят получать доход на свои любимые активы (BTC, BNB, ETH, AVAX, USDC и т.д.) без потери ценовой экспозиции к ним. Этим поставщикам ликвидности не нужно думать о IL, покупать Rune или даже знать о существовании Rune.
Savers пользовались сильным спросом в 2023 году. Старейшие BTC savers уже более года держат свои BTC в пуле и заработали около 3% годового дохода на свои BTC. Недавно количество депозитов savers, а также их размеры, значительно выросли, как показано ниже. Сегодня примерно 1/4 всей ликвидности в пулах приходится на savers.
Streaming Swaps Увеличивают Объем
Подводя итог, arbs приносят объем synth, который помогает корректировать цены, а savers приносят ликвидность. Следующая часть головоломки - это потоковые свопы. Потоковые свопы увеличивают органический объем за счет увеличения размера нативных свопов.
Потоковые свопы легко понять. Они занимают больше времени на выполнение (максимум разрешено 24 часа), но выполняются по гораздо лучшему курсу. Фактически свопы делятся на несколько подсвопов, выполняемых со временем. Потоковый своп с количеством 10 подсвопов делает соотношение подсвоп/пул в 10 раз лучше, чем один большой своп - пул кажется в 10 раз больше. Потоковый своп с количеством 100 подсвопов делает пул на 100 раз больше. Здесь основной компромисс - это цена против времени.
Потоковые свопы открыли THORChain для совершенно нового рынка; то есть для китов. Сразу после их запуска THORChain стал предпочтительным обменником для сделок на 6-7 цифр. Ниже мы видим, что средний размер потоковых свопов составляет около 18 тысяч, что является вторым по величине после свопов на Curve.
Результаты в сети начались с октября. Успех потоковых свопов обусловлен двумя уникальными факторами.
- 1. Synths: Synths уже позволяли arbs эффективно корректировать цены пулов. Однако, synths становятся гораздо более эффективными, когда используются вместе с потоковыми свопами. Это потому, что с потоковыми свопами, arbs могут использовать synths для коррекции цен во время свопа (до и после каждого подсвопа), а не после свопа. Это позволяет пользователям потоковых свопов получать точную рыночную цену при выполнении своего свопа. Арбитраж настолько эффективен, что сеть может обрабатывать потоковые свопы размером больше, чем пул, с конкурентными курсами!
- 2. Slip-based fees: THORChain использует модель slip-based fee, где плата варьируется в зависимости от того, насколько большой своп по отношению к размеру пула, при этом большие свопы платят больше, и наоборот. Таким образом, совокупная плата, уплаченная за 10 маленьких подсвопов, гораздо меньше, чем плата за один большой своп, даже если они генерируют одинаковый объем.
Действительно, до внедрения потоковых свопов в сообществе существовали сомнения о том, приведет ли разбиение свопов на множество мелких подсвопов к уменьшению общей суммы комиссий, которую могла бы собрать сеть. Как оказалось, увеличение объема было более чем достаточным, чтобы компенсировать разницу. С началом регулярного превышения сборов над блоковыми наградами, THORChain становится одной из исключительных сетей/приложений на пути к росту без субсидий.
В 2023 году доходность, полученная *только за счет комиссий*, составит в среднем 6,5%. Эта цифра представляет собой совокупную доходность по всему объему закрытой стоимости (облигации + пулы).
От Спекуляции к Фундаментальным Основам
Фундаментальные показатели THORChain выглядят сильнее, чем когда-либо. Пользователи, объем и ликвидность достигли исторических максимумов. В последнем бычьем цикле Rune был в основном объектом спекуляций. Теперь он переходит к фундаментальной игре; одной, которая приносит реальную ценность криптоиндустрии.
Что Дальше для THORChain в 2024 Году?
Помимо обычного (больше интеграций с DEX, кошельками, сетями и т.д.), в планах на следующий год следующие продукты: rapid swaps (с помощью limit orders), транзакции без мемо и perps. Код для первых двух в основном готов, поэтому мы можем ожидать их скорого запуска (вероятно, в первом квартале). Трудно комментировать сроки для perps, так как они находятся на ранней стадии дизайна/исследования.
Rapid Swaps: цена потокового свопа со скоростью обычного свопа.
Ожидается, что limit orders привлекут совершенно новый тип пользователей в THORChain; то есть трейдеров. Как и другие функции THORChain, у них есть свой THORChain поворот. В отличие от традиционных limit orders, которые выполняются против заявок/предложений в ордер-буке, limit orders THORChain выполняются против AMM пулов, когда и если их желаемая целевая цена будет достигнута. Это будет включать потоковые свопы и Synths, работающие за кулисами.
Давайте рассмотрим пример, чтобы увидеть, как это работает. Предположим, я размещаю limit order на продажу 1 BTC по цене не менее 50,000 USDC. Под капотом сначала мой 1 нативный BTC обменивается на 1 sBTC и помещается в "ордер-бук", ожидая выполнения. Оттуда он потоково обменивается на sUSDC, когда и если цена пула удовлетворит мою целевую цену в 50,000 USDC.
Limit orders значительно принесут пользу THORChain способом, который может быть не сразу очевиден. Вход в "rapid swaps".
Сегодня THORChain предлагает два варианта для своперов: обычные свопы с высокой скоростью, но неоптимальными ценами, и потоковые свопы, которые выполняются медленно с оптимальной ценой. Потоковый своп на сумму $1 млн+ обычно занимает более часа на выполнение.
Rapid swaps обещают лучшее из обоих миров; цена потокового свопа с скоростью обычного свопа. С limit orders, вполне возможно, что "потоковый своп" будет выполняться в течение одного блока без ущерба для ценового исполнения. Вот хорошая модель мышления, чтобы понять, как это будет возможно.
С обычными свопами arbs корректируют цены после выполнения свопа. С потоковыми свопами коррекция цены происходит во время свопа, между подсвопами. Limit orders делают шаг дальше. Arbs могут обновлять свои limit orders каждый блок, корректируя цены даже до того, как происходят органические свопы. Как только начинают выполняться потоковые свопы, каждый подсвоп может изменять цены пула так, что ожидающие выполнения limit orders могут сработать и выполниться против пула в другом направлении. Это означает, что потоковые свопы косвенно могут выполняться против limit orders в течение одного блока.
С limit orders, вместо того чтобы arbs ждали свопа и реактивно арбитражили, арбитраж будет происходить проактивно. Мы ожидаем, что это станет самым дешевым и эффективным способом арбитража на THORChain.
Наш последний момент здесь - это недавнее важное предложение, предлагающее использовать "торговые активы" вместо Synths для арбитража, чтобы удвоить капитальную эффективность arbs. Для заинтересованных мы настоятельно рекомендуем следить за обновлениями по этому предложению, так как оно, вероятно, поднимет арбитраж на THORChain на новый уровень. Вторичный эффект здесь от "торговых активов" заключается в том, что они могут снизить использование Synths и, таким образом, уменьшить чувствительность LP к цене Rune (подробнее о рисках в следующем разделе).
THORChain Становится Независимым от Кошелька
Транзакции без мемо - это тонкое, техническое обновление, но такое, которое может значительно принести пользу протоколу, сделав THORChain независимым от кошелька.
Сегодня THORChain требует, чтобы входящие транзакции кодировали намерение пользователя (например, желаемый актив, цепочка назначения, плата аффилиата и т.д.) в поле мемо транзакции. Кошельки, поддерживающие THORChain, должны понимать это кодирование и указывать его в соответствующих полях данных (например, OP_RETURN в Bitcoin) транзакции при ее создании.
С транзакциями без мемо кошелькам больше не нужно будет делать это кодирование самостоятельно. Вместо этого любой кошелек может иметь намерение неявно закодированное в сумме транзакции самостоятельно с помощью QR-кодов или других средств. Вот пошаговый пример того, как это будет работать.
- Пользователь запрашивает котировку через интерфейс, поддерживающий THORChain (например, THORSwap).
- Интерфейс записывает намерение (например, желаемый актив, цепочка назначения, плата аффилиата и т.д.) на блокчейне THORChain, и в свою очередь, THORChain генерирует числовой детерминированный код (например, 42344), чтобы представить намерение. Как только THORChain распознает входящую транзакцию с суммой, оканчивающейся на этот код (например, входящая транзакция 1.00042344 ETH), она будет знать, как её обработать без необходимости дополнительной информации.
- Коммуникация между кошельком и интерфейсом THORChain может происходить через QR-код или другие средства.
Транзакции без мемо позволят интеграциям стать полностью независимыми от кошельков, что, возможно, значительно расширит охват THORChain.
Несмотря на высокий потенциал доходности THORChain/Rune, мы также признаем наличие у него относительно высоких рисков.
Сама природа проектов THORChain – протокол ликвидности между сетями – является признанно рискованной областью, часто становясь мишенью для хакеров-черных шляп. Исторически, хаки мостов привели к потерям более чем на $2.5 миллиарда, и большинство из них были связаны с программными ошибками. THORChain изначально был сложным протоколом только с функцией кросс-чейн свопов, а теперь с Synths, savers, потоковыми свопами, PoL и lending он имеет гораздо большую потенциальную площадь для программных ошибок.
С другой стороны, как многолетний проект, THORChain создал сильную защиту на многих уровнях. Основная команда и Ninerealms предприняли очень эффективные шаги для повышения безопасности протоколов, включая, но не ограничиваясь:
- Immunefi bug bounty (max 250k Rune): чтобы убедить черных шляп стать белыми шляпами
- Пауза ноды: любой оператор ноды может в одиночку приостановить сеть на час, если подозревает какую-либо злонамеренную деятельность.
- Ограничение транзакции: ограничивает объем, который может проходить через пулы в течение определенного периода
- Команда Thorsec: Команда безопасности, работающая 24/7, которая отслеживает здоровье сети, реагирует на инциденты и проверяет пулл-реквесты.
Больше деталей о безопасности THORChain можно найти здесь.
Synths (особенно savers) и lending делают THORChain более чувствительным к ценовой динамике Rune. Они все разработаны так, чтобы в значительной степени приносить пользу протоколу, когда Rune превосходит не-Rune активы, однако их воздействия в основном обратны, когда Rune уступает не-Rune активам и накладывает различные риски для протокола и/или его участников.
Lending – это самая последняя функция, активированная на THORChain. Она позволяет пользователям вносить нативные активы и брать под них займы. Как и другие, lending также является уникальной функцией. Основная цель lending – это обеспечение займов без ликвидации, без срока истечения. Ее вторичная цель – генерировать постоянное давление на покупку Rune, что помогает протоколу снять ограничения (ограничения пула и ограничения Synths). Мы не будем подробно рассматривать механику lending, а вместо этого дадим приблизительное представление о том, как это работает, так как это напрямую влияет на токеномику RUNE.
Допустим, я вношу BTC, чтобы взять в займы некоторые USDC. Протокол берет мой BTC в качестве залога в сети Bitcoin и дает мне USDC в сети Ethereum на основе рыночного соотношения LTV. BTC-залог используется для покупки и сжигания Rune. Если стоимость залога упадет ниже долга (всегда выраженного в TOR; не передаваемая единица учета, которая следует за ценой самого глубокого стейблкоин пула), его не ликвидируют. В более поздний срок, когда, например, стоимость залога снова повысится, я могу вернуть свой долг и получить свой BTC-залог. В результате погашения займа новый Rune будет сминчен.
Если в течение срока моего займа Rune превзойдет в цене залоговый актив (например, BTC), то чистый эффект погашения займа – это постоянное сжигание Rune, в противном случае чистый эффект – это новый Rune, входящий в оборот из Резерва.
В конечном итоге, с дизайном lending, протокол делает очень конкретную ставку на то, что Rune превзойдет залоговые активы BTC и ETH (единственные два актива, разрешенные в качестве залога). Это увеличивает чувствительность к цене Rune. Когда ситуация ухудшается, существует реальная возможность, что lending будет иметь отрицательное влияние на протокол, увеличивая общее предложение Rune и создавая нисходящее давление на цену Rune.
Учитывая эти риски, lending вызвал недовольство у некоторых давних членов сообщества и был довольно спорной функцией. В конце концов, lending был выпущен с "аварийным тормозом", который автоматически прекращает функцию lending, если запас Rune когда-либо превысит его первоначальный максимум в 500 миллионов. Lending был недавно запущен с приличным успехом и еще должен доказать свою ценность на рынке (PMF).
Точно так же, с Synths (особенно savers), пулы становятся чувствительными к цене Rune. Вспомните грубую интуицию, которую мы ранее представили о savers против двойных LP. Когда Rune уступает не-Rune активу, в пуле может оказаться больше долгов по выданным Synths, чем существует в пуле активов (обязательства > активы). Ниже мы видим это на примере BTC пула, когда цена Rune была ниже 1 доллара летом.
Важно отметить, что расчеты между savers и двойными LP осуществляются, когда кто-то из них вносит/выводит средства из пула. Другими словами, действия каждого участника влияют друг на друга.
Когда обязательства превышают активы, если saver выходит (обменивает Synth на нативный актив), обещанный не-Rune актив покрывается за счет депозитов двойных LP, что в свою очередь увеличивает IL для всех оставшихся двойных LP. Однако, как и savers, двойные LP также могут покинуть пул в любое время. Это поднимает вопрос: что произойдет в гипотетическом крайнем случае, когда пул работает с дефицитом не-Rune активов, и вдруг все захотят вывести свои средства? В этом случае последние savers, выходящие из пула, могут понести значительные потери, уплатив аномально высокие slip-based fees из-за недостаточной ликвидности пула по сравнению с обменяемыми Synths. Проще говоря, последние savers могут не суметь обменять свои активы в соотношении 1:1. Стоит отметить, что такой риск особенно высок в стейблкоин пулах, поскольку Rune может значительно уступать не-Rune активу в медвежьем рынке.
Опять же, протокол устанавливает ограничения на Synths, чтобы избежать такого сценария "банковского бегства". Однако важно признать, что эти риски существуют. Наконец, стоит отметить, что команда 9R выразила интерес к снижению ограничений до 30% пула (с текущего максимума в 60%) после сигналов от некоторых операторов нод и высказанных опасений сообщества относительно пулов AVAX/RUNE.
Вкратце; в целом, предоставление ликвидности на THORChain - это игра с высоким риском и вознаграждением, которая может быть очень чувствительна к цене Rune. Участники свопов подвергаются риску только во время свопа, однако это не относится к поставщикам ликвидности. Те, кто хочет участвовать в пулах, должны провести исследование, убедившись, что они понимают связанные риски, а также вознаграждения.
Chainflip
Chainflip недавно запустил свой кроссчейн DEX. Хотя на первый взгляд THORChain и Chainflip кажутся конкурентами, обе сообщества понимают, что их успех – это взаимовыгодное положение, которое расширяет возможности для обоих. Другими словами, THORChain и Chainflip не конкурируют друг с другом. Они конкурируют, чтобы сделать CEX (централизованные биржи) устаревшими.
Как и THORChain, Chainflip является суверенным app-chain , чьи валидаторы управляют нодами поддерживаемых сетей для коллективного управления адресами через TSS; они независимо наблюдают и принимают входящие транзакции и подписывают исходящие транзакции в поддерживаемых сетях.
Однако, если углубиться, Chainflip выглядит совсем не так, как THORChain. Все компоненты, такие как TSS vaults, торговый движок и т.д., созданы с нуля с небольшим или вообще без обмена кодом с другими проектами.
Chainflip имеет уникальный механизм AMM just-in-time (JIT), где предоставленная ликвидность находится в форме ордеров в стиле UNI V3, а также limit orders. Обе формы ликвидности активно управляются маркет мейкерами и используются для свопов. DEX действует очень похоже на открытый, прозрачный, децентрализованный OTC, с маркет мейкерами, обновляющими свои ордера на Chainflip just-in-time, наблюдая за входящими свопами. Точнее, от маркет мейкеров ожидается обновление их ордеров, пока свопы ожидают достижения финальности в поддерживаемых сетях и будут «заблокированы» на Chainflip.
Свопы группируются (по направлению, по пулу) и выполняются пакетно с едиными ценами. Например, множественные свопы продажи или покупки одного и того же актива в блоке частично компенсируют друг друга и выполняются как один большой своп покупки или продажи. Это не только предотвращает попытки фронтраннинга отдельных свопов, но и минимизирует slippage.
Цель дизайна JIT AMM – создать высококонкурентную среду между маркет мейкерами, стимулируя их предлагать лучшие цены для выполнения намерений свопа и, в свою очередь, зарабатывать комиссии. От маркет мейкеров на Chainflip ожидается, что это будет сложная роль, с конкурентоспособными маркет мейкерами, использующими свою собственную внебиржевую ликвидность и потенциально модели прогнозирования для минимизации своих ценовых рисков.
Дизайн Chainflip особенно эффективен в минимизации токсичного MEV для пользователей. Пакетные свопы с едиными ценами, в сочетании с высококонкурентной средой маркет мейкинга, переворачивают фронтраннинг с ног на голову. Вместо того чтобы своперы подвергались фронтраннингу со стороны ботов MEV, маркет мейкеры опережают друг друга для заполнения свопов и захвата комиссий. Делая это, они предлагают лучшую цену для своперов.
Тем не менее, предполагаемая игровая теория основывается на конкуренции маркет мейкеров на расстоянии вытянутой руки, и могут быть крайние случаи, когда это предположение не соблюдается.
Например, в периоды аномально высокого объема, если свопы в одном направлении ожидают потребления всей доступной ликвидности, маркет мейкеры могут больше не быть способными заполнить их по точным рыночным ценам. В таком крайнем случае доминирующей стратегией для маркет мейкеров может стать сговор для заполнения свопов по неточным ценам, выгодным для них, вместо конкуренции друг с другом с невозможностью заполнить свопы. В периоды высокого спроса будет разумно, чтобы фронтенды предупреждали пользователей о вероятности истощения ликвидности.
Как и THORChain, Chainflip принимает общую базовую пару для своих пулов, чтобы предотвратить фрагментацию ликвидности. Однако, Chainflip также существенно отличается от THORChain в своем решении использовать USDC в качестве базового актива.
С точки зрения эффективности капитала, решение по USDC является рациональным, так как маркет мейкеры могут легко хеджировать свои риски IL на внешних рынках против ордербуков стейблкоинов, которые имеют наибольшую ликвидность в целом. С USDC надежда состоит в том, чтобы сделать привлечение маркет мейкеров на DEX очень простым.
Однако, принимая это решение, Chainflip также делает явный компромисс. Это вводит внешнюю зависимость от централизованного участника в сердце их протокола, отдаляя протокол от крайнего конца спектра устойчивости к цензуре.
FLIP имеет эластичное предложение и, в зависимости от использования сети, может стать дефляционным активом. С комиссий за свопы будут покупаться и сжигаться FLIP, в то время как новые эмиссии будут использоваться для стимулирования валидаторов и маркет мейкеров. Хотя FLIP не будет использоваться в пулах как маршрутизирующий актив, валидаторам нужно будет стейкать FLIP для управления и обеспечения безопасности сети, а FLIP также будет использоваться в качестве газового токена.
Дорожная карта Ethereum
В 2024 году нас ожидает множество изменений в Ethereum, которые представляют собой как сдвиги в инфраструктурном ландшафте, так и долгосрочный план развития сети. Можно ожидать два крупных хардфорка: хардфорк Deneb-Cancun (также известный как Dencun), ожидаемый уже в феврале, и хардфорк Prague-Electra, запланированный на более поздний срок в этом году (его планирование официально начнется в январе).
Хардфорк Dencun состоит из нескольких обновлений, но мы можем разбить их на три категории для более понятного обзора:
- Основы Шардинга Данных: В протокол вводятся транзакции Blob и вся необходимая инфраструктура вокруг них.
- Обновления Beacon Chain: Обновления для повышения качества жизни, связанные с механизмом выхода из стейкинга, увеличенным окном включения аттестации, ограничением скорости активации валидаторов за эпоху (8 валидаторов/эпоху).
- Обновления EVM: Опкоды временного хранения, опкоды базовой платы за ресурсы Blob, более дешевый опкод копирования памяти, удаление SELFDESTRUCT (в некотором роде).
Второй хардфорк 2024 года будет называться Prague/Electra, и планирование этого набора обновлений официально начнется в январе. Несмотря на то, что это еще довольно рано, уже ведутся обсуждения относительно того, какие обновления будут подходящими для включения в этот хардфорк. Вот некоторые предложения, которые в настоящее время рассматриваются:
- Добавление предварительно скомпилированных BLS12-381
- Verkle Trees
- Execution Layer Triggerable Exits (Вызываемые выходы слоя исполнения)
- EOF (для развертывания смарт-контрактов – уже был отложен в течение двух последних хардфорков)
- Обновления для повышения качества жизни финального гаджета (изменение в слое консенсуса для снижения стоимости проверки Casper FFG в 64 раза)
С лучшим пониманием официальных хардфорков, предстоящих в 2024 году, и приблизительным представлением о ожидаемых обновлениях, у нас есть хорошее представление о том, над чем ожидается работа основных разработчиков в разнообразии клиентов консенсуса и исполнения, а также в спецификации основного протокола. В целом, мы ожидаем гораздо более насыщенный год по сравнению с тем, что мы наблюдали в 2023 году.
Одним из самых значительных и обсуждаемых обновлений в хардфорке Dencun является EIP-4844, и мы предвидим, что включение этого обновления и различных других меньших обновлений, вытекающих из него, будет иметь большое влияние на более широкую экосистему Ethereum, включая мир L2.
В центре внимания хардфорка Dencun несомненно находится EIP-4844 (также известный как Proto-Danksharding), который является одним из самых ожидаемых обновлений в Ethereum после EIP-1559 и The Merge.
Чтобы не путать это обновление с более долгосрочным решением по шардингу данных, известным как Danksharding, мы будем продолжать называть это обновление EIP-4844 на протяжении всего текста.
От Исполнения к Шардингу Данных
По мере развития и созревания технологии блокчейна мы начали наблюдать сдвиги в мышлении о ключевых компонентах блокчейнов и о том, где разделить заботы и оптимизировать свойства, придающие им ценность - Ethereum не исключение. Совсем недавно Ethereum все еще работал над разработкой масштабируемого дизайна для реализации шардинга исполнения, но сегодня мы видим, что Ethereum посвящает себя становлению надежной машиной для подтверждения, а не расширенным интернет-компьютером, как это было представлено ранее в плане развития, что очень очевидно по общему настроению, которое делится сообществом в отношении ориентированного на роллапы плана - что приводит нас к настоящему времени. Сегодня Ethereum позиционирует себя как слой публикации данных и арбитража, а не пытается удовлетворить требования масштабируемого слоя исполнения блокчейна для глобального принятия. Один из ключевых шагов, необходимых для реализации этой видения, заключается в внедрении шардинга данных в сеть, и EIP-4844 является одним из первых больших шагов в этом направлении.
Прецедент для Лучшего Использования Хранения в Блокчейне
EIP-4844 - это набор изменений, позволяющих использовать Ethereum в качестве недоверенного слоя публикации данных без накладывания чрезмерных нагрузок на хранение данных в сети. Ethereum достигает этого, вводя новый тип транзакции вместе с системой вокруг нее, которая позволяет дешево публиковать произвольные данные по всей сети, но не требует их постоянного, долгосрочного хранения. Таким образом, мы видим разделение хранения данных и публикации данных, где Ethereum может не всегда предоставлять средства для извлечения данных, но целостность любых ранее опубликованных данных может быть криптографически проверена в сети.
Не неся долгосрочной роли хранения данных, Ethereum может дешево ценить использование этого нового типа транзакции и количество данных, которое он может содержать, учитывая, что это не способствует росту состояния и истории (которые представляют основные внешние факторы, влияющие на ценообразование ресурсов и рынки комиссий в сети).
Вкратце, вот что Ethereum предлагает приложениям (публикаторам данных), которые стремятся использовать EIP-4844:
- Дешевая Публикация Данных: Поскольку хранение данных не является постоянной, долговременной стоимостью для сети (поскольку оно не вносит значительного вклада в рост состояния и истории), публикация данных с использованием механизма EIP-4844 может быть оценена крайне дешево по сравнению с текущим самым дешевым вариантом публикации данных с использованием Ethereum.
- Доказательство Публикации: Каноническое состояние и история Ethereum могут подтвердить признание события публикации данных.
- Доказательство Доступности: Протокол гарантирует доступность отправленного пакета данных на определенный период времени перед его удалением. Это сделано для того, чтобы предоставить достаточно возможностей любому заинтересованному участнику, желающему предоставить хранение опубликованных данных, извлечь их, после чего Ethereum отказывается от обязанностей по хранению/восстановлению данных.
- Доказательство Целостности Данных: Публикатор данных может захотеть в один день извлечь старый пакет данных, который был опубликован в Ethereum в прошлом. С предположением доверия 1 из N, этот пакет должен быть извлечен из внешнего источника, не относящегося к протоколу. Получив пакет данных, издатель может использовать Ethereum для криптографической проверки целостности данных, которые предположительно были опубликованы, что даст им неопровержимую уверенность в том, что данные, которые они получили, действительно были опубликованы в Ethereum в какой-то момент в прошлом.
EIP-4844 представляет первые основополагающие шаги к внедрению возможностей шардинга данных в Ethereum. Это обновление помогает начать этот процесс, вводя в сеть транзакции, переносящие блобы, а также все необходимые компоненты протокола, которые работают вместе с этим новым типом транзакций. Пройдя через очень упрощенное описание того, как работает эта новая система публикации данных, мы можем описать это обновление, состоящее из трех основных компонентов:
Введение Транзакций, Переносящих Блобы
EIP-4844 вводит новый тип транзакций, известный как транзакция, переносящая блобы, который позволяет приложениям прикреплять произвольные данные, предназначенные для публикации, к этой специальной транзакции.
Каждая из этих транзакций с блобами может переносить до 128 кБ произвольных данных. Транзакции, переносящие блобы, - это то, что конечный пользователь отправляет в сеть, и она содержит полезную нагрузку данных, которую желательно опубликовать в Ethereum. Существенная часть для понимания этого нового типа транзакции заключается в том, что большая часть размера транзакции (приписываемая полезной нагрузке данных) сохраняется в Ethereum только временно, после чего через определенный период времени данные удаляются - это представляет переход Ethereum от временной роли предоставления возможности извлечения данных к его будущей роли (в отношении этих данных) предоставления верификации, связанной с публикацией.
Эфемерная часть транзакции, описанная здесь, известна как боковая панель блоба (смотрите интерфейс здесь), и она состоит из сырых данных, сгенерированных обязательств и необходимых криптографических доказательств.
С учетом того, что полезная нагрузка блоба, связанная с этими транзакциями, не является постоянной отрицательной внешностью для сети, стоимость размещения такой нагрузки значительно дешевле по сравнению с текущим самым дешевым вариантом размещения данных в Ethereum. Это естественно делает транзакции, переносящие блобы, высоко привлекательным новым вариантом для стратегий пакетной публикации различными роллапами, которые осуществляют расчеты в Ethereum, учитывая, что это может значительно сократить большую часть операционных расходов, с которыми сталкиваются операторы роллапов при взаимодействии с Ethereum для использования его возможностей консенсуса и арбитража.
Two-Dimensional Resource Pricing (Двумерное Ценообразование Ресурсов)
Чтобы понять второй ключевой компонент, введенный с EIP-4844, сначала нам нужно получить простое представление о том, как в настоящее время ценятся транзакции в Ethereum. Мы выделяем два компонента, которые формируют то, что пользователи в итоге платят за транзакции:
- Ценообразование Ресурсов: компонент протокола, который присваивает вес вычислительным усилиям, налагаемым на сеть (например, общий газ, потребляемый транзакцией).
- Механизм Оплаты Транзакций: компонент протокола, который использует механизм рынка (например, некоторый вид аукциона) для назначения рыночных цен за единицу газа, которые пользователи должны предложить для стимулирования включения.
Эти два компонента выше являются довольно тонкими темами в области децентрализованного механизма проектирования, но они критически важны для понимания того, что введение новой транзакции, переносящей блобы, приносит в Ethereum. В настоящее время все типы транзакций Ethereum вносят некоторый вклад в исполнительный след Ethereum, будь то через вычислительные усилия EVM, рост истории или рост состояния. Мы будем называть газ, связанный с этими текущими транзакциями, как исполнительный газ. В основном, любая вычислительная активность, с которой мы знакомы и которая вызывается транзакциями, потребляет этот execution gas (исполнительный газ) (например, стоимость calldata, нативные переводы ETH, кумулятивные усилия выполнения кода EVM - а также рост состояния и истории, связанные с этими транзакциями).
Наблюдая за анатомией транзакций, переносящих блобы, мы можем заметить, что некоторые части транзакции потребляют "исполнительный газ" аналогичным образом текущим транзакциям - например, заголовок блока и тело транзакции способствуют росту истории, поскольку они составляют часть тела блока Ethereum и, следовательно, требуют обработки и потребления ресурсов узла при выполнении протокола.
Пока это обычное дело, но когда мы смотрим на эфемерную часть транзакции с боковой панелью блоба, мы понимаем, что она обрабатывается совершенно иначе, чем мы ожидаем от нормальной полезной нагрузки транзакции. Боковая панель блоба обрабатывается только на слое консенсуса и в конечном итоге полностью удаляется после истечения определенного периода времени. Именно на этом предпосылке в протокол вводится новый тип ресурса для измерения временных всплесков затрат, налагаемых на слой консенсуса – этот ресурс называется data gas.
Дополнительная Информация о Рынке Газа за Данные
Не вдаваясь в подробности о работе рынка газа для этого нового типа газа за данные, мы видим, что EIP-4844 позволяет устанавливать цель в 3 блоба на каждый блоб Ethereum с максимумом 6 блобов при эластичности спроса и предложения, предоставляемой механизмом рынка газа, подобного EIP-1559; мы ожидаем, что это значение в конечном итоге будет скорректировано до 16 блобов в будущем хардфорке в зависимости от того, насколько эффективным окажется это решение для пользователей. Каждая транзакция с блобом занимает фиксированный размер примерно ~125 кБ (независимо от того, использует ли транзактор весь доступный объем или нет — пространство блоба транзакции все равно использует около 125 кБ из-за того, как работает схема криптографических обязательств с элементами поля, в которые будут закодированы данные). Одно из основных отличий рынка газа за данные касается механизма оплаты транзакций, используемого им, который представляет собой модифицированную версию EIP-1559, известную как экспоненциальный EIP-1559, обладающий лучшими свойствами (что было бы слишком долго объяснять здесь, но вы можете прочитать об этом здесь).
Новые Криптографические Примитивы, Необходимые для EIP-4844 (Методы/Помощники KZG)
Окончательный ключевой компонент, составляющий EIP-4844, — это введение ключевых криптографических примитивов, необходимых для вычисления обязательств KZG и оценки доказательств KZG. Это критически важное требование для того, чтобы Ethereum мог предоставлять гарантии публикации данных, описанные ранее в этом разделе.
В интересах краткости мы опустим объяснения о том, как конкретно используются обязательства KZG и явную процедуру преобразования блобов в обязательства, но выделим некоторые ключевые результаты, которые необходимо доставить для работы службы публикации данных как предполагается. К результатам относятся:
- Два предварительно скомпилированных контракта: Для проверки блоба или доказательства KZG, принадлежащего версионированному хешу опубликованных данных.
- Логика слоя консенсуса: При работе с боковыми панелями блоба требуется выполнение различных проверок валидности. С EIP-4844 необходимо подтвердить доступность данных (которые распространяются через gossiped), (на более позднем этапе с Danksharding, выборка доступности данных будет свидетельствовать о доступности вместо требования, чтобы у всех валидаторов были все данные). Вместе с подтверждением доступности извлечения, версионированные хеши должны быть вычислены из данных блоба для проверки того, что предоставленный версионированный хеш был правильно вычислен и соответствует конкретному пакету данных блоба.
Пространство Дизайна и Протоколы Совместного Использования Блобов
Как было сказано ранее, транзакции, переносящие блобы, имеют фиксированный размер полезной нагрузки, и это означает, что тот, кто включает транзакцию с блобом, обязан платить сборы за весь блоб, независимо от того, использовал ли он только небольшую часть доступного пространства полезной нагрузки ~128 кБ. С этим связано множество проблем эффективности, и к сожалению, это не так просто, как просто изменить протокол, чтобы разрешить блобам быть любого размера, поскольку криптография требует этих ограничений. Проблемы эффективности следующие:
- Стоимость: Пользователи, которым не требуется весь объем блоба транзакции, переплачивают.
- Скорость: Если пользователей слишком много и доступных блобов ограниченно, другим пользователям может потребоваться подождать один или два блока или даже больше, чтобы опубликовать свои пакеты данных в Ethereum с использованием транзакции с блобом.
Логичным решением было бы разработать либо децентрализованный протокол, либо доверенное приложение для объединения пакетов данных в единые блобы перед их отправкой в Ethereum для участия в процессе публикации данных.
Представьте себе три роллапа (Rollup A, Rollup B, Rollup C), каждый из которых использует одну транзакцию с одним блобом для использования Ethereum для публикации данных:
Некоторые сходства действительно можно найти между протоколом совместного использования блобов и чем-то вроде общего секвенсора, однако, если присмотреться поближе, можно представить, что протокол совместного использования блобов гораздо проще в своей основе, поскольку он требует меньше обмена сообщениями с Ethereum. Это потому, что после публикации объединенной транзакции с блобом, он может оставить дальнейшие действия на усмотрение каждого отдельного роллапа в том, как они решат управлять своими требованиями к хранению данных.
Читая это, вы также можете задаться вопросом, почему Ethereum просто не внедрит какой-либо механизм для объединения полезных нагрузок блобов в единые блобы или коллекции блобов для повышения эффективности? Одна из веских причин для этого - сложность протокола, поскольку это внесло бы еще одну задачу упаковки на уровне транзакций, наряду с уже существующей NP-трудной задачей построения блоков – и в мире увеличения специализации билдеров аутсорсинга производства блоков это вносит дополнительную сложность в уже сложную задачу по внедрению механизмов PBS в Ethereum.
Мы определенно можем ожидать появления различных форм протоколов и приложений для совместного использования блобов по мере увеличения использования EIP-4844 после хардфорка Dencun. Некоторые примеры исследуемого дизайнерского пространства уже можно наблюдать здесь и здесь.
Delphi Digital. Будущее Сross-Сhain Мостов