Slem

RISEx x TreadFi: подробный гайд по запуску MM-бота и работе с торговым терминалом

2026-04-25T18:39:10.591Z

Что такое TreadFi

TreadFi это торговый терминал и OEMS для криптотрейдеров, который объединяет в одном интерфейсе CEX, Perp DEX и on-chain swaps. Его основная идея простая: дать трейдеру не просто кнопку Buy/Sell, а набор профессиональных инструментов для алгоритмического исполнения, маркетмейкинга, управления позициями и снижения торговых издержек.

Если говорить проще: TreadFi это не биржа, а слой управления торговлей. Ты подключаешь свои аккаунты на биржах или perp DEX, а дальше можешь запускать стратегии, ботов и алгоритмические ордера из одного места.

Для нас главный фокус здесь: RISEx + TreadFi Market Maker Bot.

Почему это интересно именно для RISEx

RISEx сейчас находится в ранней invite-only фазе, поэтому рынок еще формируется. Это значит, что ликвидность может быть ниже, чем на зрелых площадках, а ордера могут исполняться медленнее. Но именно поэтому маркетмейкинг здесь выглядит особенно интересным.

MM-бот помогает:

создавать реальную ликвидность;
ставить лимитные maker-ордера;
генерировать торговый объем;
тестировать поведение рынка;
участвовать в активностях/поинтах TreadFi;
работать не руками, а через автоматизированную стратегию.

TreadFi прямо описывает свой Market Maker Bot как инструмент, который одновременно размещает buy и sell ордера вокруг текущей рыночной цены, помогает зарабатывать на спреде и предоставляет ликвидность через TWAP-логику с passive-only и active-limit исполнением.

Что делает Market Maker Bot

Market Maker Bot не пытается “угадать рынок” как обычный трейдер. Его задача другая: он постоянно стоит в стакане с обеих сторон рынка.

Условно:

ниже текущей цены он ставит buy limit;
выше текущей цены он ставит sell limit;
если рынок двигается, бот обновляет ордера;
если ордера исполняются, бот продолжает поддерживать активность;
если риск становится слишком большим, бот может поставить себя на паузу.

В документации TreadFi указано, что бот использует только limit/maker ордера, не пересекает спред и не использует market/taker ордера в рамках MM-бота. Также он периодически обновляет ордера, чтобы оставаться близко к рыночной цене, а при слишком быстром движении цены может поставить работу на паузу для защиты от перекоса экспозиции.

Главная мысль: это не wash trading, а реальное предоставление ликвидности через maker-ордера.

Перед стартом: что нужно подготовить

Перед тем как подключать RISEx к TreadFi, нужно выполнить несколько базовых условий.

Что нужно:

EVM-кошелек
Например MetaMask, Rabby или другой WalletConnect-совместимый кошелек.
Аккаунт на RISEx
Важно: регистрироваться нужно тем же EVM-кошельком, который потом будешь подключать в TreadFi.
Средства на RISEx
Депозит нужно делать не в TreadFi, а напрямую в аккаунт RISEx.
Аккаунт TreadFi
Можно зарегистрироваться через email или wallet.

Регистрация в TreadFi

Порядок простой:

Заходишь на TreadFi.
Регистрируешься через email или кошелек.

3. Если выбрал email, подтверждаешь почту.

4. Нажимаешь на иконку кошелька в правом верхнем углу.

5. Выбираешь подключение perp DEX аккаунта.

6. Подключаешь RISEx.

7. Подписываешь подтверждение тем же кошельком, который использовал при регистрации на RISEx.

Важно не перепутать обычное подключение DEX Account и Connect Perp DEX Account, потому что для RISEx нужен именно perp DEX аккаунт.

Комиссии и важный нюанс по RISEx

В документации по Market Maker Bot указано, что для ряда площадок builder fee составляет 2 bps, но в отдельном блоке по RISEx указано, что по состоянию на 23 апреля 2026 Tread не взимает дополнительных fees для RISEx. При этом Tread оставляет за собой право изменить эти условия. Поэтому перед запуском бота лучше всегда проверять актуальную информацию в интерфейсе.

Запуск Market Maker Bot: пошагово

После подключения RISEx можно запускать MM-бота.

Шаг 1. Select Account

Выбираешь аккаунт RISEx.

Если у тебя подключено несколько бирж или DEX, важно не ошибиться и выбрать именно RISEx.

Шаг 2. Select Pair

Выбираешь торговую пару.

Для первого запуска лучше брать самые ликвидные пары:

BTC-PERP
ETH-PERP

Почему именно они:

больше объем;
лучше стакан;
выше шанс исполнения ордеров;
меньше риск странных движений на тонком рынке.

TreadFi сам рекомендует для первого запуска держаться ликвидных perp-пар вроде BTC-PERP.

Шаг 3. Margin

Margin это сумма, которую ты выделяешь конкретно под работу бота.

Очень важный момент: это не значит, что нужно закидывать весь баланс в одну стратегию.

Моя логика:

для первого теста лучше использовать маленький размер;
не стоит использовать больше 50-70% доступного баланса;
всегда оставляй запас под волатильность;
чем выше плечо, тем выше риск ликвидации или сильного просадки.

Документация TreadFi прямо предупреждает, что увеличение margin и leverage повышает потенциальный volume, но также увеличивает риск ликвидации при высокой волатильности или резком движении цены против тебя.

Шаг 4. Leverage

Leverage определяет, какой объем бот сможет крутить относительно твоей маржи.

Пример:

$100 margin;
10x leverage;
бот может целиться в объем около $1000 notional.

Но это не бесплатный объем. Чем выше плечо, тем быстрее растет риск.

Для RISEx я бы не советовал начинать с максимального плеча. Более адекватный диапазон для тестов:

консервативно: 3x-5x;
умеренно: 5x-10x;
агрессивно: 10x-20x.

Выше 20x уже лучше не трогать, пока ты не понимаешь, как бот ведет себя именно на этой паре и в текущей ликвидности.

Шаг 5. Volume

Volume показывает, какой торговый объем бот примерно планирует сгенерировать на основе твоей маржи, плеча и настроек.

Важно понимать: volume это не profit. Большой объем может быть полезен для поинтов, но если настройки слишком агрессивные, ты можешь получить убыток быстрее, чем набьешь красивую статистику.

Шаг 6. Participation Rate

Participation Rate показывает, насколько активно бот участвует в рыночном объеме.

Проще говоря:

низкий participation rate = бот работает спокойнее;
высокий participation rate = бот пытается исполняться быстрее и активнее.

Для раннего RISEx я бы не начинал с слишком агрессивного режима, потому что ликвидность пока может быть неравномерной. Лучше сначала посмотреть, как бот исполняет ордера в спокойном режиме.

Шаг 7. Duration

Duration это время работы бота.

В TreadFi часть параметров может рассчитываться автоматически. Обычно для первого запуска лучше не делать слишком долгую сессию.

Нормальный старт:

15-30 минут для первого теста;
1-2 часа после того, как понял поведение;
дольше только если уже есть уверенность в стратегии.

Шаг 8. Reference Price

Reference Price определяет, от какой цены бот будет строить свои ордера.

Это важный параметр, потому что именно вокруг reference price бот размещает buy/sell лимитки.

В разных режимах reference price может учитывать:

mid price;
blend;
signal;
grid;
reverse grid;
dynamic grid.

Если не понимаешь разницу, лучше начинать с дефолтного или готового пресета.

Шаг 9. Spread

Spread это расстояние между buy и sell ордерами вокруг базовой цены.

Очень простая логика:

узкий spread = больше шанс исполнения, больше volume, но меньше прибыль с каждого цикла;
широкий spread = меньше исполнений, но потенциально лучше прибыль на сделку;
слишком широкий spread = бот может просто стоять без fills;
слишком узкий spread = можно быстро набить объем, но съесть прибыль комиссиями/движением цены.

На ранней ликвидности RISEx слишком узкий spread может быть опасен, потому что резкие движения будут быстрее выбивать бота из баланса.

Шаг 10. Stop Loss

Stop Loss это максимальный допустимый убыток, после которого бот останавливается и закрывает/сворачивает работу.

Это обязательный параметр. Запускать MM-бота без нормального Stop Loss плохая идея.

Пример:

margin $100;
stop loss 10%;
максимальный убыток около $10.

TreadFi в документации объясняет, что max loss рассчитывается из процента stop loss и введенной маржи, а бот мониторит PnL в реальном времени и отменяет ордер, если net loss достигает этого значения.

Шаг 11. Take Profit

Take Profit это цель по прибыли.

Когда бот достигает нужного PnL, он останавливает работу и фиксирует результат.

Для первого теста не нужно ставить космический TP. Лучше маленький, но реалистичный:

10% для короткого теста;
25% для более длинной сессии;
выше только если рынок спокойный и стратегия уже проверена.

Что значит Paused и почему это не всегда плохо

Если бот перешел в статус Paused, не нужно сразу паниковать.

По документации TreadFi, бот может автоматически поставить себя на паузу, когда экспозиция в одну сторону становится слишком большой. Он возобновляет торговлю, когда net exposure возвращается в безопасную зону.

Проще говоря:

бот видит, что его слишком сильно “перекосило” в long или short, и временно перестает наращивать риск.

Это не баг, а защитный механизм.

Лучшие режимы для RISEx MM-бота

1. DGrid

DGrid можно считать самым удобным режимом для большинства пользователей, потому что он пытается сам подстраиваться под рынок.

Идея:

если рынок боковой, логика ближе к Grid;
если рынок трендовый, логика ближе к Reverse Grid;
бот смотрит на волатильность и рыночные условия;
часть параметров адаптируется автоматически.

Для пользователя это удобно, потому что не нужно вручную угадывать, рынок сейчас во флэте или в тренде.

Что нужно настроить:

margin;
leverage;
stop loss;
take profit.

Для новичка это самый понятный старт.

2. Grid

Grid лучше подходит для бокового рынка.

Когда рынок ходит туда-сюда в диапазоне, Grid может хорошо собирать спред и исполнять ордера в обе стороны.

Хорошо работает, когда:

нет сильного тренда;
цена ходит в коридоре;
волатильность умеренная;
стакан не слишком пустой.

Плохо работает, когда:

рынок резко пошел в одну сторону;
цена вышла из диапазона;
начался импульс;
бот набрал перекос против движения.

3. RGrid

RGrid это логика для более трендового рынка.

Если Grid любит боковик, то RGrid лучше подходит, когда рынок движется направленно.

Но здесь нужен больший контроль, потому что тренд может резко сломаться, а бот может остаться с неправильной экспозицией.

Points Program TreadFi

TreadFi Season 1 дает points за торговлю и предоставление ликвидности. По документации, поинты начисляются за meaningful activity, включая trading и liquidity provision, а фиксированный пул 100,000 points распределяется каждую неделю между eligible users. Season 1 заканчивается в мае 2026.

Это значит, что MM-бот может быть полезен не только как торговый инструмент, но и как способ активности в points program.

Но важный момент:

не надо бездумно гнаться за volume. Если стратегия убыточная, поинты могут не перекрыть убытки.

Итог

TreadFi для RISEx это сильный инструмент, особенно на ранней стадии mainnet.

Он позволяет:

запускать MM-бота без кода;
создавать реальную ликвидность;
крутить volume;
тестировать разные рыночные режимы;
работать с maker-ордерами;
участвовать в points activity;
управлять риском через SL/TP;
не сидеть руками у терминала весь день.

Но это не кнопка “бесплатные деньги”. Это инструмент. И как любой торговый инструмент, он требует аккуратности, тестов и понимания риска.

Моя базовая рекомендация:
начинать с маленького размера, использовать DGrid, не ставить большое плечо, всегда включать Stop Loss и сначала изучить поведение бота на RISEx в реальных условиях.

5 эксклюзивных инвайт-кодов в RISEx:

1/5 AUK2ILN8
2/5 WWS81OBU
3/5 X6QSDSV6
4/5 0LHSNT83
5/5 V1O5A75G

Небольшое примечание: ранний доступ даёт тебе больше времени, чем другим, чтобы полноценно протестировать RISEx. Не упусти эту возможность! Как только начнёшь торговать, ты сможешь генерировать больше инвайт-кодов и получать больше преимуществ.

В RISEx будет программа инвайт-кодов, которая даёт пригласившему 10% от поинтов, заработанных его приглашёнными.

Инвайт-коды открываются каждую неделю по следующим условиям:

10k объёма — даёт 1 код
50k объёма — даёт 2 кода
Далее дополнительные коды выдаются за каждые последующие 50k объёма

Объём сбрасывается каждую неделю для генерации инвайт-кодов.

Инвайт-коды будут выдаваться батчами каждый четверг в 18:00 UTC на RISEx.

Если что-то сломается или будет работать странно, заходи в Discord и делись фидбеком. Команда RISEx работает круглосуточно, чтобы помочь.

Погнали!

Инфо-рекап АМА RISE SAM x HAI

2026-04-22T11:41:54.657Z

Вот что было главной мыслью всей AMA:

RISE строит не просто “быстрый чейн”, а инфраструктуру под реально чувствительные к задержке приложения, прежде всего под ончейн-ордербук и трейдинг.
То есть их тезис не в духе “сделаем еще один L2”, а в том, что в крипте до сих пор слишком много систем, где пользователь ждет, интерфейс тормозит, а продукт разваливается под нагрузкой. Поэтому их ставка на скорость это не маркетинг, а попытка убрать самую болезненную часть UX.

Если объяснять совсем просто, то RISE хочет, чтобы блокчейн ощущался не как “отправил заявку и молишься”, а как нормальная быстрая система.
Аналогия для твоей мамки (чтоб она поняла, чем ты здесь вообще занимаешься, кроме как играешь в смеш-картс) может быть примерно такая:

Обычный блокчейн это как почта, где письма складывают в мешок, потом везут, потом сортируют, потом доставляют.
RISE пытается сделать это ближе к экспресс-курьеру, где обработка идет почти сразу, а не пачками с лишними остановками.

Что реально важно из AMA

1. Они сознательно не ушли от EVM, хотя это было модно
Команда говорит, что на старте было давление: мол, чтобы стать очень быстрыми, нужно менять VM, дерево данных и вообще ломать совместимость. Но RISE уперся в идею: лучше выжать максимум из EVM, чем строить экзотическую систему, с которой потом сложнее жить проектам, стейблкоинам и разработчикам.
Это важный сигнал: они выбрали не “самый хайповый” путь, а путь, где экосистеме проще подключаться.

2. Их главный технический фокус это не просто TPS, а latency
Очень важный момент. Hai прямо говорит: производительность это не только throughput, но и пользовательское ощущение скорости. И именно для трейдинга задержка решает всё.
Переводя на простой язык: не так важно, сколько машин может проехать по трассе за день, если твоя машина все равно стоит в пробке именно тогда, когда тебе нужно ехать.

3. Их архитектурный ключ это continuous execution
Они объясняют, что в обычной block-based модели слишком много времени уходит не на выполнение пользовательских транзакций, а на сопутствующие процессы. Hai говорит, что в типичном стеке на само исполнение транзакций может уходить лишь около 12% времени блока.
Их решение: выполнять транзакции более непрерывно, а не ждать очередной “пачки”. Отсюда и идея, что пользователю результат надо возвращать максимально быстро.

4. RISE строит цепочку и биржу вместе, и это дает им огромное преимущество
Это, возможно, вообще самый ценный кусок всей AMA. Они не просто делают chain и надеются, что кто-то когда-то построит на нем хороший продукт. Они одновременно строят chain + RISEx.
Зачем это нужно? Потому что тогда можно убирать лишние слои между приложением и сетью. Меньше RPC-боли, меньше задержек, меньше риска потерь данных при индексации, быстрее фиксы и апгрейды.

Самая понятная аналогия:

Обычный Web3-стек это как ресторан, где кухня, склад, доставка и касса находятся в разных концах города и общаются по телефону.
RISE + RISEx это когда кухня, касса и выдача в одном помещении.
Заказ доходит быстрее, ошибок меньше, исправления вносятся в тот же день.

5. Они много говорят не о “магии”, а о feedback loop
Hai приводит крутой практический пример: если биржевая команда понимает, что новый IPC может ускорить индексацию в 3 раза, в обычной экосистеме надо писать proposal, убеждать всех, ждать релиза клиента и так далее. У них это может решаться буквально за дни внутри одной команды.
Это очень сильная мысль: скорость продукта это не только миллисекунды в рантайме, но и скорость, с которой команда вообще умеет улучшать систему.

6. Их инженерная культура выглядит как “думай глубоко, а не просто чини”
Hai очень жестко продвигает принцип фундаментального понимания. Не “оно вроде работает”, а “почему это работает, кто владеет данными, что будет, если пропадет байт, приведет ли это к reorg”.
То есть они продают образ не стартапа с красивыми слайдами, а инженерной команды, которая копает в корень. Это не гарантия успеха, но это очень здоровый сигнал.

7. Очень сильный блок про AI и найм
Один из самых интересных моментов всей сессии: Hai фактически говорит, что в эпоху AI главным дефицитом становится не знание синтаксиса, а самостоятельное мышление.
Ему не нужен инженер, который просто делегирует всё модели и сидит 7 минут, пока та думает. Ему нужны люди с критическим мышлением, domain knowledge и умением решать низкоуровневые проблемы, где AI пока слабее.
Это хороший маркер того, как они видят качество команды.

8. Подход к безопасности у них тоже культурный, а не только “наняли аудитора и забыли”
Hai подчеркивает, что security это ответственность всех, а не только security-отдела.
И одновременно говорит, что нельзя становиться самоуверенными. То есть подход такой: каждый думает о безопасности, но команда не строит из себя богов и все равно платит за внешние аудиты и консультации. По их словам, на аудиты уже ушли сотни тысяч долларов.

9. Из roadmap самое важное это mempool и parallelization
Они называют mempool “контроллером latency”. Если mempool плохой, пользователь проигрывает еще до исполнения.
Особенно это важно для RISEx: например, отмена ордеров должна проходить очень быстро, иначе маркетмейкеры будут ловить ненужное исполнение по устаревшим ценам.
То есть речь уже не о красивой техничке, а о конкретном качестве рынка.

10. Главный скрытый вывод AMA
Это была не сессия про “token go up”. Это была сессия про то, что RISE хочет стать инфраструктурой для приложений, где время реакции сети уже напрямую влияет на качество продукта.
И если раньше многие чейны спорили о TPS как о числе для баннера, то RISE пытается доказать, что важнее другое: как быстро пользователь получает результат, как быстро отменяется ордер, как быстро индексируются данные, как быстро команда может улучшить систему.

Вот держи еще готовый темплейт для твоего треда

Ниже сделал в формате, который можно постить по твитам или собрать в готовый пост (у кого есть премка в твитттере -- можете все собрать до кучи и дропнуть через GPT, чтоб тот вам красиво и грамотно выдал конечный результат на инглише). Я держал язык максимально понятным, без перегруза.

1/
Послушал новую AMA-сессию RISE с Sam и Hai.
Если коротко: это был не разговор про “мы самые быстрые”, а очень внятное объяснение, зачем вообще блокчейну нужна скорость и почему для RISE это не маркетинг, а основа всего продукта.

2/
Главная идея RISE простая:
блокчейн не должен ощущаться как почта XIX века, где ты отправил транзакцию и просто ждешь.
Он должен быть ближе к нормальной современной системе, где результат приходит быстро и предсказуемо.

3/
И тут важный нюанс.
RISE говорит не только про TPS.
Они много говорят именно про latency, то есть про задержку.
Для трейдинга это критично: неважно, сколько заявок система “в теории” переварит, если твоя конкретная заявка пришла слишком поздно.

4/
Один из самых сильных тейков от Hai:
во многих блокчейн-стеках на реальное исполнение транзакций уходит лишь малая часть времени блока.
Слишком много времени съедают вспомогательные процессы.
Отсюда и их ставка на continuous execution.

5/
Если объяснить совсем просто:
обычный блокчейн часто работает как автобус по расписанию.
Сначала все ждут, пока соберется “пачка”, потом автобус едет.
RISE пытается сделать систему ближе к режиму, где обработка идет почти непрерывно.

6/
Еще один важный момент: RISE сознательно не отказался от EVM.
Хотя соблазн был большой.
Их логика такая: лучше выжать максимум из знакомой экосистеме технологии, чем строить что-то экзотическое и ломать совместимость для разработчиков и проектов.

7/
По сути, их тезис звучит так:
“нам не нужен новый мотор только ради красивой истории, если мы можем сильно разогнать текущий и при этом сохранить совместимость”.
Для экосистемы это реально важно.

8/
Самая недооцененная часть AMA:
RISE строит не просто chain, а chain + RISEx вместе.
И это дает огромное преимущество.
Потому что приложение и сеть не живут как два чужих офиса, которые общаются через медленный RPC и вечные костыли.

9/
Аналогия:
обычный Web3-стек это как ресторан, где кухня, касса и доставка в разных районах города.
У RISE идея другая: держать всё как можно ближе друг к другу.
Именно так они режут задержки, ускоряют индексацию и быстрее выкатывают улучшения.

10/
Hai привел очень сильный пример.
Если exchange-команде нужен новый IPC, который ускорит индексацию в 3 раза, в обычной экосистеме это недели или месяцы согласований.
У RISE это может решиться внутри команды за дни.
Это и есть сила вертикальной интеграции.

11/
То есть скорость продукта это не только миллисекунды в рантайме.
Это еще и скорость обратной связи:
как быстро команда увидела проблему, придумала решение, внедрила его и донесла до продакшена.
В этом AMA RISE сделал на этом большой акцент.

12/
Отдельно понравился их подход к инженерии.
Hai буквально говорит: важно не просто “починить”, а понять, почему система вообще работает именно так.
Не гадать по паттернам, а разбираться до уровня владения данными, синхронизации и последствий для консенсуса.

13/
Очень в тему был и его тейк про AI.
По сути: в мире, где AI пишет код все лучше, главным преимуществом инженера становится не знание синтаксиса, а критическое мышление, domain knowledge и умение решать сложные низкоуровневые задачи.

14/
По security позиция тоже зрелая.
Не “у нас есть аудиторы, значит все ок”, и не “мы сами гении, нам никто не нужен”.
А скорее: безопасность это обязанность каждого, но самоуверенность в этой сфере смертельно опасна, поэтому внешние аудиты все равно обязательны.

15/
Из roadmap больше всего зацепил mempool.
Hai прямо называет его “контроллером latency”.
Если mempool плохой, то пользователь страдает еще до исполнения транзакции.
Для RISEx это особенно важно, потому что отмена ордера должна проходить максимально быстро.

16/
Почему это важно?
Потому что для маркетмейкера “не успел отменить ордер” это не мелочь.
Это уже прямой риск получить исполнение по устаревшей цене.
То есть тут техническая архитектура напрямую превращается в качество рынка.

17/
Еще один мощный сигнал:
они уже думают не только о throughput, но и о том, как убрать ситуацию, где твоя транзакция вынуждена ждать все предыдущие в очереди.
Отсюда разговор про parallelization между разными рынками и типами действий.

18/
Мой главный вывод после этой AMA:
RISE хочет выиграть не баннером “мы самые быстрые”, а тем, что строит инфраструктуру под приложения, где время реакции сети действительно меняет сам продукт.
И RISEx для этого не витрина, а боевой полигон.

19/
Если совсем по-простому:
большинство чейнов спорят о мощности двигателя.
RISE пытается показать, что важно еще и другое:
как быстро машина откликается на педаль, как быстро поворачивает и как быстро механики вообще могут ее улучшать.

20/
Именно поэтому эта AMA была ценной.
Она была не про шум, а про фундамент:
почему скорость важна, как она достигается, зачем chain и app строить вместе и почему без сильной инженерной культуры вся эта история просто не взлетит.

ВАЖНО!

Обязательно перечитайте свои посты перед публикацией, чтоб было от вашего лица и старайтесь заменять "ИХ/ОНИ" — на большую конкретику: RISE, RISEchain, RISEx, команда RISE/RESEx, Сем, Хаи и тд и тп. Так же старайтесь заменять: "Я, по моему мнению" и тд и тп, чтоб не выглядеть кринжово в ct. (вы все таки не эксперт, не аналитик, не инфл и не KOL)

Добавляйте тейки, хуки (примерно 3-4 хука может быть нормально, не стесняйтесь интриговать и завлекать внимание но и не перебарщивайте с этим), пишите грамотно, чтоб у вас было вступление, главная часть и финальные мысли.

Избегайте всякого дерьма по типу: "Я булишь, гуд теч, верю в рис, мне нравится/мне не нравится" — будьте более нейтральны и лишь слегка придавайте поверхностно свой нарратив, не инфоциганьте и не слопьте.

Больше анализа, больше понятных простых аналогий = больший успех вашего материала и вероятности, что его кто-то вообще прочитает

Ваши посты и материалы в них должны быть такими, чтоб их мог понять незнакомый, пьяный чувак в баре, не перегибайте с техничкой и анализами — соблюдайте золотую середину и помните, что не понятно в вашем тексте для вас — скорее всего и не будет понятно вашему читателю — поэтому GPT и гугл в помощь вам для упрощения текста и/или создания понятных аналогий!

Успехов!

RISE: высокопроизводительный ролл-ап

2024-09-09T22:39:21.939Z

Samuel Battenally Hai Nguyen Thanh Nguyen

RISE Labs

Аннотация

Мы представляем RISE, инновационную платформу второго уровня (L2), разработанную для решения насущных проблем с производительностью в ролл-ап экосистеме Ethereum. Несмотря на заметные достижения, текущие решения Ethereum L2 отстают по пропускной способности транзакций, значительно уступая конкурентам, таким как Solana. RISE использует параллельную виртуальную машину Ethereum (EVM), конвейер непрерывного выполнения и новую архитектуру обеспечения доступа к состоянию, построенную на основе инфраструктуры нод Reth на языке программирования Rust, чтобы существенно повысить пропускную способность и производительность. Основной целью RISE является достижение цели The Surge [4], 100,000 транзакций в секунду (TPS), с возможностью дальнейшего масштабирования. В этом документе подробно рассматриваются проблемы существующих L2 технологий, архитектурные инновации RISE и будущие направления оптимизации масштабируемости и эффективности блокчейна. RISE обещает соответствовать и превосходить по производительности решения первого уровня (L1), устанавливая новый стандарт в блокчейн-технологиях.

1 Вступление

1.1 Технологический ландшафт

Когда в июле 2015 года Виталик Бутерин впервые запустил блокчейн Ethereum [1], он не только развивал основополагающую технологию, представленную биткоином [2], но и стал пионером глубоко инновационной концепции: смарт-контрактов. С тех пор смарт-контракты открыли возможности для применения и глобальной координации, о которых до их появления даже не мечтали. Очевидно, что мир осознает потенциал этой невероятной технологии, однако в ходе ее внедрения были выявлены проблемы масштабирования, которые в конечном итоге привели к разработке Ethereum Endgame, предложенной Виталиком Бутериным [3], которая переросла в дорожную карту Ethereum Roadmap [4]. Основным компонентом дорожной карты является The Surge, целью которого является достижение 100,000 транзакций в секунду и выше на роллапах. Arbitrum и Optimism сыграли значительную роль в достижении этой цели, продемонстрировав EVM роллапы как неоспоримое решение для масштабирования, но их пропускная способность оставляет желать лучшего [5][6]. Технология готова к появлению второго поколения роллапов, ориентированных на производительность, чтобы устранить этот пробел. Благодаря последним инновациям The Surge становится реальностью, Виталик утверждает, что мы достигаем экспоненциальной составляющей S-кривой возможностей [7]; RISE призван раскрыть эти быстрые изменения и открыть следующую волну приложений, о которых никто еще не мечтал.

1.2 Вступление

Ролл-ап экосистема Ethereum добилась значительных успехов в повышении блокчейн-масштабируемости, безопасной поддержке различных приложений и получении значительной рыночной стоимости. Однако даже несмотря на эти успехи, совокупная пропускная способность экосистемы второго уровня (L2) обычно обрабатывает около 100 транзакций в секунду (TPS)[8], что далеко не соответствует производительности конкурентов, таких как Solana, которая стабильно достигает более 1000 TPS, что в десять раз больше, чем у всех L2 вместе взятых[9]. Solana добилась этого благодаря приоритету масштабируемости над децентрализацией, меньшему количеству валидаторов и высокой эмиссии для финансирования дорогостоящей инфраструктуры, и ее внедрение свидетельствует о том, что рынок поддерживает прагматичный подход к масштабированию. Успех Solana и различие в производительности между Solana и L2 также дает понять, что существует спрос на высокопроизводительные и недорогие EVM L2, но этот спрос не удовлетворяется существующими на сегодняшний день технологиями.

Мы представляем RISE, следующее поколение оптимистичных Ethereum Virtual Machine (EVM) ролл-ап стеков. Разработанный с нуля, RISE ориентирован на максимизацию пропускной способности транзакций для достижения амбициозной цели в 100,000 транзакций в секунду (TPS), обозначенной в дорожной карте Ethereum. Исторически доступность данных (DA) была основным узким местом для роллапов, но последние достижения, такие как EigenDA и EIP-4844, значительно сгладили эту проблему. Теперь проблема переходит к производительности выполнения. Для решения проблемы производительности RISE объединяет лучшие технологии, предлагаемые современными исследованиями, и новые инновации, включая параллельное выполнение EVM, непрерывное исполнение блоков и инновационный дизайн для доступа к состоянию. Все это интегрировано в надежную инфраструктуру Reth-нод, основанную на Rust.

Стек RISE ориентирован на вокруг роллапное будущее; для обеспечения гибкости развертывания стеки Sequencing и DA не зависят друг от друга, что позволяет деплоерам приложений на RISE чейне выбирать индивидуальные стеки Sequencing и DA. Основой стека RISE является высокопроизводительное исполнение. Не только основная сеть RISE будет поддерживать пропускную способность, соответствующую самым производительным сетям первого уровня (L1), но и любое количество сетевых приложений RISE.
В данной статье представлен стек технологий исполнения RISE и его инновационные возможности в области производительности. Однако в ней не рассматривается взаимодействие RISE с помощью совместного секвенсирования; этот вопрос будет рассмотрен в будущих работах команды RISE Labs.

1.3 Состояние роллапов

Подход Ethereum к масштабированию, как утверждается, был успешным. С февраля 2024 года в L2 хранится более 40 миллиардов долларов, а средняя скорость транзакций в секунду (TPS) превышает 100 [2]. В настоящее время запущено более 40 роллапов, и мы являемся свидетелями первых дней горизонтального масштабирования Ethereum. Этот рост не был беспрепятственным: отсутствие общего состояния приводит к фрагментации приложений, пользователей и ликвидности. Учитывая рост горизонтального масштабирования в L2, справедливо заключить, что вертикальное масштабирование столкнулось с ограничениями и антисетевыми эффектами, замедляющими принятие и активность в отдельных роллапах.

Сравнение производительности, Вторых уровней и Solana.

Это становится еще более очевидным, когда мы сравниваем внедрение и производительность L2 с самым производительным конкурентом, Solana. В марте 2024 года средний показатель Solana составил около 1000 TPS [2], что в десять раз больше, чем у всех L2 на Ethereum вместе взятых. Arbitrum и Base достигли примечательных максимумов TPS - 532 TPS и 293 TPS. Однако во время пиковой перегрузки обе сети испытывали перебои, в то время как Solana стабильно поддерживает 2000+ TPS в одиночку. Solana добилась значительных успехов в Ethereum, несмотря на попутный ветер EVM, что еще больше укрепляет вывод о неудовлетворенном спросе на производительные L2.

1.4 Выбор виртуальной машины

Попутный ветер EVM очень мощный: в EVM больше живых продуктов, больше инвестиций, больше активных талантов и больше пользователей, чем в любой другой виртуальной машине для смарт-контрактов [10]. Создание технологии для поддержки 100,000 TPS не имеет смысла без принятия разработчиками и пользователями. В EVM есть конструктивные решения, которые делают масштабирование чрезвычайно сложным; однако с попутным ветром EVM слишком трудно бороться; поэтому RISE фокусируется исключительно на EVM-совместимом L2-стеке.

1.5 Нулевые знания против оптимизма

В последнее время zkEVM L2 добились значительного прогресса, внедрение находится на рекордно высоком уровне, а скорость тестирования стремится к максимуму. Целью RISE является начало The Surge [6] и достижение цели в 100,000 TPS. В будущем это станет возможным с помощью zkEVM, хотя для этого потребуются аппаратные решения, такие как zkASIC, которые должны стать доступными [x]. Однако при оптимистичном развитии событий мы уверены, что высокая пропускная способность может быть достигнута без необходимости в собственном аппаратном ускорении. В связи с этим команда RISE первоначально сосредоточится на оптимистичном стеке и перейдет на zkEVM, как только подходящее оборудование станет доступным.

1.6 Структура документа

В этом документе мы начинаем второй раздел с определения проблем производительности, с которыми приходится сталкиваться при создании высокопроизводительного роллап-стека; в третьем разделе мы представим подробное описание технологического стека RISE, а в четвертом разделе мы расскажем о дальнейшей работе и заключительных замечаниях.

2 Проблемы, связанные с производительностью

Основной проблемой производительности, с которой до сих пор сталкивались L2, была доступность данных (ДД). Однако благодаря инновациям во внешних ДД, таким как Celestia и eigenДД, и закрепленным решениям, таким как EIP-4844 [8], это уже не так важно. Теперь мы наблюдаем появление множества других узких мест, таких как сеть, исполнение, ограничения на размер блока, ограничения на доказательство мошенничества, меркелизация и ввод-вывод из хранилища. Казалось бы, за одну ночь производительность L2 превратилась в захватывающее и сложное пространство для проектирования с различными направлениями.

2.1 EVM исполнение

Большинство реализаций EVM исполнения являются однопоточными. Из-за этого сегодня максимальный предел производительности диктуется тактовой частотой одного процессора. Переход к параллельной модели исполнения также нетривиален, поскольку транзакции в блоке по своей природе последовательны.

2.2 Доступ к Ethereum состояниям

Ethereum требует наличия аутентифицированных структур данных, закодированных в виде модифицированных триз Меркла-Патриция (МПТ), для хранения и аутентификации своих данных типа «ключ-значение».

Рисунок: Данные о ключах-значениях в Ethereum кодируются в МПТ, которые в конечном итоге хранятся в базе данных бэкенд-ключей-значений. Сама база данных бэкенда обычно реализуется в виде структуры данных B-древо или LSM-древо.

К сожалению, доступ к хранилищу в Ethereum медленный по нескольким причинам.

Данные ключ-значение не хранятся в базе данных; они кодируются в МПТ, который хранится в базе данных. Поэтому чтение/запись ключа на уровне приложения усиливается до нескольких чтений/записей в бэкэнд базы данных. Такое усиление чтения/записи приводит к низкой скорости хранения, а значит, и к низкой пропускной способности.
Операция записи требует многократного повторного вычисления хэша для всех внутренних нод на пути МПТ.
И наконец, самое главное, ввод/вывод данных из хранилища является синхронным, то есть потоки выполнения должны дождаться завершения дорогостоящих операций чтения/записи, прежде чем продолжить обработку следующей транзакции.

Последствия этого весьма значительны. Раздутие состояния приводит к антисетевому эффекту. По мере роста состояния увеличивается и средняя глубина древа, что еще больше замедляет доступ к хранилищу. Кроме того, корень МПТ должен вычисляться заново в каждом блоке, в результате чего значительная часть времени выполнения уходит на Мерклеизацию.

2.3 Хранилище IO

Хранилище состояний не является явным элементом концепции EVM; клиенты нод могут свободно применять инновационные решения для хранения данных. LevelDB, PebbledDB и MDBX - все эти хранилища ключевых значений используются в Ethereum и клиентах второго уровня, однако они не являются встроенными хранилищами аутентифицированных ключевых значений (AKVS). Нативное AKVS-решение имело бы свои преимущества, однако на сегодняшний день подходящих FOSS-решений нет.

2.4 Размер блока

Очевидным ограничением Layer 2 является ограничение по количеству газа в блоке. Эта конфигурация легко увеличивается, если система может поддерживать более высокую пропускную способность. Однако увеличение лимита блоков может повлиять на систему защиты от мошенничества. Если претенденты будут предоставлять для доказательства мошенничества целый блок, они рискуют столкнуться с ограничениями на размер блока в Ethereum.

2.5 Производство блоков Layer 2

Все клиенты L2 изначально были клиентами Ethereum и часто продолжают придерживаться концепций L1. Конвейер производства блоков для L2 по своей сути отличается от L1. Это открывает возможности для оптимизации и распараллеливания конвейера производства блоков в секвенсоре L2 и клиенте исполнения.

2.6 Интероперабельность и децентрализация

Взаимодействие через совместное секвенирование станет значительным открытием для Layer 2, а децентрализация секвенсоров также является важным шагом. Каждый из них вводит ограничения на исполнение и секвенсор, которые необходимо учитывать при создании перспективной системы.

3 Системный дизайн RISE

3.1 Сетевая архитектура RISE

Система RISE переосмысливает статус-кво архитектуры сетей L2. Сегодня клиенты нод в сетях L2 осуществляют каждую транзакцию, проходящую через сеть. Однако этап выполнения не улучшает модель безопасности сети; ноды полагаются на систему защиты от мошенничества для обеспечения надежности. Изучая опыт Solana, RISE использует преимущества разнообразия вычислительных систем; клиенты нод RISE не выполняют ненужных транзакций, что позволяет использовать высокопроизводительный и дорогой секвенсор, или «исполнитель» (см. раздел 3.1.1), сохраняя при этом приемлемую стоимость нод.

3.1.1 «Исполнитель»

Сегодня в отрасли бытует ошибочное мнение, что компании Layer 2 получают свой доход за счет секвенсирования. Это правда, что в секвенсировании есть своя ценность, но она должна быть извлечена за счет пользователя через MEV. Сегодня ни один крупный L2 не участвует в извлечении ценности из своих пользователей по очевидным причинам. Доходы, получаемые сегодня роллапами, в основном связаны с исполнением; L2 предлагают исполнение как продукт. Здесь мы вводим термин «исполнитель» - сторона, ответственная за выполнение транзакций в блоках, поддержание состояния сети, генерирование корня состояния и предоставление различий в состоянии секвенсору и более широкой сети. Спецификации исполнителя настраиваются в соответствии с требованиями конкретного развертывания сети RISE, будь то сетевое приложерние или мейннет RISE.

Упрощенная вычислительная архитектура RISE. Дорогой исполнитель, доступные ноды.

3.1.2 Высокопроизводительный исполнитель

Разблокировав высокопроизводительный исполнитель, мы не только можем масштабировать производительность с помощью более высокой тактовой частоты и большего количества ядер, но и вспомнить о влиянии ввода-вывода из хранилища на производительность, а также устранить эти накладные расходы путем кэширования наиболее важных состояний в оперативной памяти.

3.2 Непрерывный конвейер блоков

Процесс производства блока в L2 состоит из следующих последовательных шагов [13]:

Консенсус при формировании транзакций L1 и новых атрибутов блока
Выполнение производных транзакций
Получение транзакций из пула памяти и их выполнение
Подготовка заголовка и вычисление корня состояния

Как правило, эти шаги выполняются последовательно; на рисунке ниже показан типичный конвейер создания блоков для L2 с односекундным временем блокировки и большим состоянием. Лимит газа в блоке будет ограничен тем, сколько газа может быть обработано за время, отведенное на выполнение; однако в этой системе на выполнение отводится лишь малая часть конвейера построения блока. На практике C потребляет 40-80 % времени блока, а по мере роста состояния R потребляет до 60 % оставшегося времени выполнения. В худшем случае на выполнение E и FE будет отводиться только 8 % времени блока, что является эффективным, а ограничения на газ в блоках должны тщательно учитывать худший сценарий, чтобы избежать временного дрифта в блоке и реорганизации.

Последовательный конвейер блоков

RISE представляет Continuous Block Pipeline (CBP) - параллельный конвейер блоков с параллельными этапами и потоком непрерывного выполнения (CE). Поток CE отслеживает транзакции в мемпуле и выполняет их в нескольких сегментах блока, больше не ожидая консенсуса для запроса нового блока. Вспомним наихудший сценарий с 8%-ным исполнением; для сравнения, CBP выполняет транзакции почти 100% доступного времени. Вычисление корня состояния также происходит параллельно с выполнением.

Непрерывный конвейер блоков (CBP)

3.3 Параллельное EVM исполнение

Здесь мы представляем еще один уровень распараллеливания, теперь уже на уровне исполнения. EVM требует последовательного исполнения; если это требование не выполняется, недетерминированные результаты нарушают консенсус. Однако в RISE большинство транзакций выполняется параллельно. В RISE используется Block-STM, впервые представленный Аптосом [11]. Основная техника Block-STM заключается в том, чтобы взять блок и оптимистично выполнить все транзакции параллельно, при этом одним из результатов является наличие зависимостей между транзакциями. Транзакции, не имеющие зависимостей, завершаются, а транзакции с общими зависимостями выполняются последовательно. В этом есть дополнительная сложность, хотя это и есть основная техника Block-STM.

3.3.1 Предварительная обработка мемпула

В отличие от предыдущих роллапов, которые упорядочивали транзакции по принципу «первым пришел - первым обслужен» или газовых аукционов, RISE использует новую структуру мемпулов, которая балансирует между задержкой и пропускной способностью. Цель заключается в предварительном упорядочивании транзакций, чтобы минимизировать общие состояния и максимизировать параллельное выполнение. Это имеет относительно схожий эффект с локальным рынком газовых комисий на Solana, где перегруженные контракты и состояния стоят дороже в отношении газа и ожидания. Поскольку количество потоков для выполнения транзакций гораздо меньше, чем предполагаемый TPS, мы все равно можем организовать выделенные потоки для последовательного выполнения контрактов с высоким трафиком, а остальные - параллельно в других потоках.

3.4 Уровневые МПТ

Напомним, что доступ к состоянию Ethereum существенно влияет на пропускную способность; наше первоначальное решение - хранить весь МПТ в памяти, чтобы уменьшить накладные расходы на чтение/запись. К сожалению, представление состояния может вырасти чрезвычайно большим. RISE будет обрабатывать сотни тысяч транзакций в секунду, поэтому состояние, скорее всего, будет расти очень быстро. По мере роста состояния хранение всего МПТ в памяти становится нецелесообразным, хотя хранение небольшой его части вполне возможно. Например, мы можем хранить часто используемые адреса (например, Uniswap, USDT, мосты и т. д.) в памяти для более быстрого чтения/записи.

Мы проводим ряд оптимизаций для обеспечения высокоскоростного доступа к памяти, таких как разделение операций чтения/записи и кэширование МПТ. Вместо того чтобы использовать единый МПТ для состояния, мы добавляем меньшие промежуточные МПТ в памяти поверх существующего МПТ на диске, чтобы уменьшить усиление операций чтения и записи от дискового хранилища с высокой задержкой. Наш дизайн, вдохновленный [11], состоит из трех различных МПТ, действующих как кэши для доступа к данным.

Снепшот МПТ (СМПТ). СМПТ - это то же самое, что и обычный МПТ, используемый в клиенте Ethereum, за исключением того, что СМПТ хранит только снепшот блокчейн состояния высоты блока, а не наиболее свежее состояние блокчейна. СМПТ хранится на диске, поэтому доступ к СМПТ требует больших затрат.
Промежуточный МПТ (ПМПТ). ПМПТ строится поверх СМПТ и хранится в памяти.
Дельта МПТ (ДМПТ). ДМПТ строится поверх ИМПТ и также хранится в памяти. ДМПТ хранит самые последние данные блокчейна и является местом, где происходят новые обновления.

Рисунок. Имеется три МПТ, два из которых хранятся в памяти (зеленые), а самый большой - на диске (желтый). При записи данные обновляются в ДМПТ и периодически выгружаются на диск. Чтение сначала обращается к ДМПТ в поисках данных, если их нет, то запрашивает ПМПТ и доходит до СМПТ, если в первых двух МПТ нет запрашиваемых данных.

Записи операций обновляются на ДМПТ, который находится в памяти. В ДМПТ, скорее всего, хранятся данные наиболее часто используемых счетов, таких как USDT или Uniswap, поэтому обновления на этих счетах будут происходить очень быстро. При доступе на чтение запрос сначала обращается к ДМПТ. Если данные не найдены, он продолжит поиск в ПМПТ и, наконец, если данные не найдены в двух предыдущих МПТ, будет произведен поиск в СМПТ.

Чтобы ДМПТ и ПМПТ были достаточно эффективными и умещались в памяти, через заданный интервал времени обновления в этих древах сбрасываются на диск с помощью операций слияния. Операция слияния состоит из следующих шагов.

Изменения в ПМПТ передаются в СМПТ для создания новой контрольной точки.
ДМПТ становится новым ПМПТ.
Новый ПМПТ очищается.

Обратите внимание, что выбор интервала влияет на производительность системы. Если интервал слишком мал, ДМПТ и ПМПТ будут слишком малы, чтобы вместить достаточно кэшированных данных, и операции слияния будут происходить очень часто. Если интервал слишком большой, ДМПТ и ПМПТ будут слишком большими, чтобы поместиться в памяти.

3.4 Дополнительные улучшения

Некоторые дополнительные сетевые возможности, которые вносят свой вклад в стеки RISE, включают альтернативные сети и JIT-компиляцию.

3.4.1 Сетевая работа

Исполнитель будет подключен к тысячам нод, и каждое из этих соединений имеет накладные расходы. В сети RISE используется протокол QUIC, альтернатива традиционному TCP, который, помимо прочего, обеспечивает более быстрое установление соединений и уменьшение задержек.

3.4.2 JIT-компиляция

Just-in-time допускает собственное выполнение VM, а не выполнение через интерпретатор. JIT будет оказывать инкрементное воздействие на этап выполнения EVM в стеке RISE.

4 Заключение

4.1 Будущая работа

4.1.1 RISE DB

Уровневые МПТ работают как кэш-слои для доступа к состоянию, чтобы помочь снизить коэффициент повышения частоты обращений к адресам ввода-вывода. Однако для дальнейшего раскрытия возможностей высокопроизводительных EVM неизбежно удаление дополнительных структур данных, таких как B-древа или LSM- древа. RISE DB является текущим исследовательским проектом в этом направлении. В идеале мы используем нативную структуру данных в виде древ в качестве индекса на диске, который никогда не нужно сжимать, в сочетании с несколькими низкоуровневыми оптимизациями доступа к диску, чтобы значительно снизить накладные расходы на ввод-вывод.

4.1.2 Совместимость

RISE строит будущее, ориентированное на роллапы, где роллап - это синоним сервера, а приложения обладают суверенитетом над своим пространством блоков. Рынок ценит пространство блоков гораздо больше, чем приложения, которые создают спрос на это пространство. Мы прогнозируем будущее, в котором приложения развертывают суверенные роллапы, владея своим пространством блоков и той ценностью, которую они привлекают к нему. Однако с сегодняшней технологией это невозможно: инфраструктура роллапов не поддерживает производительность и совместимость, необходимые многим приложениям. Отсутствие атомарной совместимости (Universal Synchronous Composability) между роллапами не позволяет приложениям использовать возможности смежных приложений в своих интересах. RISE стремится решить обе эти проблемы - непосредственно производительность и косвенно совместимость - путем совместной работы с другими новаторами в этой области. В этом документе речь идет исключительно о производительности; исследовательская группа RISE Labs будет работать над решением проблемы атомарной совместимости для роллапов.

4.2 Выводы

Разработка RISE представляет собой значительный шаг вперед в эволюции масштабируемости и блокчейн производительности. В этом документе рассматриваются проблемы, с которыми сталкиваются существующие технологии второго уровня в экосистеме Ethereum, и представляется RISE как инновационное решение, призванное преодолеть эти ограничения. Благодаря внедрению параллельного EVM, усовершенствованных процессов выполнения и инновационных дизайнов баз данных, RISE стремится к амбициозной пропускной способности в 100,000 TPS, устанавливая тем самым новый стандарт в области блокчейн-технологий.
Постоянное развитие RISE направлено не только на удовлетворение текущих потребностей, но и на прогнозирование и внедрение инноваций для решения будущих задач в блокчейн пространстве. Мы приглашаем сообщество присоединиться к нам в этом захватывающем путешествии, поскольку мы работаем над созданием более масштабируемой, эффективной и инклюзивной блокчейн экосистемы.

Выражение благодарности

Мы выражаем благодарность всем тем, кто проложил путь к развитию технологий Ethereum масштабируемости и роллап технологиям. В частности, мы отмечаем основополагающую работу и значительный вклад команд Arbitrum и Optimism. Их новаторские усилия в области оптимистичных роллапов доказали, что роллапы являются жизнеспособным вариантом масштабирования для Ethereum.

Мы также благодарны команде Reth за создание клиента исполнения, на котором строится RISE. Модульность и производительность, которые предлагает Reth, очень важны для RISE, а их команда является передовым лидером в этой области. Мы надеемся отплатить им взаимностью, внося свой вклад в развитие Reth по мере возможности.

Справочная информация

[1] Бутерин, В. (2014). Ethereum: Платформа следующего поколения для смарт-контрактов и децентрализованных приложений. Заимствовано с https://ethereum.org/content/whitepaper/whitepaper-pdf/Ethereum_Whitepaper_-_Buterin_2 014.pdf.

[2] Nakamoto, S. (2008). Bitcoin: одноранговая система электронных денег. Заимствовано с https://bitcoin.org/bitcoin.pdf

[3] Бутерин, В. (2021, 6 декабря). Конец игры. Взято с https://vitalik.eth.limo/general/2021/12/06/endgame.html

[4] Понимание дорожной карты развития Ethereum, Получено 10 апреля 2024 года, с https://www.blocknative.com/blog/ethereum-roadmap-guide

[5] Kalodner, H., Goldfeder, S., Chen, X., Weinberg, S. M., & Felten, E. W. (2018). Arbitrum: Масштабируемые приватные смарт-контракты. Принстонский университет. Получено с сайта https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-kalodner.pdf

[6] TPS, Max TPS, TTF, Block Time & Governance Model. (2024). Получено 14 апреля 2024 г. с https://chainspect.app/dashboard?range=30d

[7] Бутерин, В. [@VitalikButerin]. (2024, 29 марта). Что это значит в более широком смысле? Я утверждаю, что теперь, когда слияние и EIP-4844 завершены, мы находимся на правой стороне S-кривой. Дальнейшие изменения L1 будут весьма значительными и существенными, но относительно более мягкими. [X Post]. Взято с https://x.com/VitalikButerin/status/1773356271300706507

[8] Value Locked (2024). Взято 10 апреля 2024 года с https://l2beat.com/scaling/summary.

[9] Бутерин, В., и Бейко, Т. (2024). EIP-4844: Транзакции шардов-блобов. Ethereum Improvement Proposals. Взято 2 апреля 2024 года с https://eips.ethereum.org/EIPS/eip-4844.

[10] Electric Capital. (2023). 2023 Crypto Developer Report.

[11] Choi, J., Beillahi, S., Singh, S., Michalopoulos, P., Li, P., Veneris, A., & Long, F. (2022). LMPT: Новая структура данных с аутентификацией для устранения узких мест в хранении данных для высокопроизводительных блокчейнов. IEEE.

[12] Ethereum Optimism. (2024). Оптимизм: Оптимистичный Ethereum. Заимствовано с https://github.com/ethereum-optimism/optimism.

[13] Gelashvili, R., Spiegelman, A., Xiang, Z., Danezis, G., Li, Z., Malkhi, D., Xia, Y., & Zhou, R. (2022). Block-STM: масштабирование исполнения блокчейна путем преобразования заказного проклятья в благословение производительности. arXiv preprint arXiv:2203.06871. https://doi.org/10.48550/arXiv.2203.06871

Дневник разработчиков MELD 101

2024-08-27T10:58:07.648Z

Здравствуйте и спасибо, что присоединились к нам в Дневники разработчиков MELD! Это ваш эксклюзивный пропуск за кулисы всех обновлений, улучшений и прорывов, которые мы сделали с MELDapp за последнюю неделю. Окунитесь в атмосферу и узнайте, что нового мы сделали!

Веб-приложение MELDapp:

Разработан совершенно новый раздел для LP-токенов Azomi во вкладке WALLET - просмотр и отслеживание показателей токенов пользователя, обеспечивающих ликвидность, с кнопкой быстрого доступа к URL, перенаправляющей на конкретный пул,
Сотрудничество с командой Azomi в свете предстоящего официального релиза dApp на блокчейне MELD,
Исправлены проблемы с мостом MELD Akamon Bridge при использовании Metamask,
Исправлены проблемы с кнопкой максимальной суммы бриджа при использовании Metamask,
Начали рефакторинг основного приложения и внедрение улучшений.

Мобильное приложение MELDapp:

Продолжаем подготовку к официальному релизу iOS App Store,
Сосредоточились на интеграции и тестировании подписки MELD Premium,
Продолжение тестирование и совершенствование потока обмена (крипто-крипто свапы, вывод криптовалюты на фиат и ввод фиат-крипто).

Solidity | Бэкэнд:

Исправлен PR bump conway для репозитория cardano-multisig,
Реализовано динамическое вычисление комиссии при обратном бриджинге из MELD через MELD Akamon Bridge,
Добавлена поддержка Diamond Hands NFT в тестнет-кране MELD Cardano (для тестирования грядущей специальной утилиты для DH-ходлеров),
Взаимодействие с препаноптическим контрактом в сервисе бриджа,
Исследование возможности обновления lucid для бриджа,
Экспериментировали с использованием форк-ноды в локальном окружении для отслеживания подграфа, чтобы сократить время симуляции,
В CI-конвейере для проверки стейкинг вестинга, заменили сборку cabal на сборку Docker, реализовали CD для проверки стейкинг вестинга,
Исправлена пропажа иконки slug в конечной точке API GET /slugs,
Запрос баланса из блокчейна, если Kupo завершает работу,
Обработка токенов с null slugs для всех API, чтобы поддержать LP-токены Azomi в веб-приложении MELDapp,
Удален get datum из хэша datum во внутренней библиотеке Cardano,
Добавлено название релиза для CI,
Обновлена эра Конвея для отслеживания,
Улучшен бот MELD's Liquidation Bot для использования оптимальных многохоповых путей в Azomi DEX,
Реализован скрипт для заполнения MeldPriceOracle ценовыми данными MELD API для использования в качестве дополнительного резервного оракула,
Внедрен новый промежуточный смарт-контракт (MeldBridgePrePanoptic), позволяющий раздавать пользователям до 0,02 gMELD при бриджинге токенов в блокчейн MELD через мост MELD Akamon посредством контракта MeldBridgePanoptic,
Развернули контракт MeldBridgePrePanoptic в средах DEV, STAGING и MAINNET,
Реализован смарт-контракт Umbrella Network Price Oracle Adapter.

Инфраструктура:

Отключили старую ноду Cardano v8,
Настроили модуль terraform для google cloud sql,
Вывели из эксплуатации ноду Cardano v8,
Открыли порты Cardano для внутренней сети VPC,
Настроили базу данных и индексный сервис для нового сервиса смарт-контрактов,
Перенесены сервисы Cardano для основной сети на ноду Cardano v9..

Мы глубоко ценим вашу неизменную поддержку, которая остается для нас важнейшим фактором. Ваши отзывы имеют неизмеримую ценность, поскольку мы продолжаем совершенствовать и улучшать MELDapp. Следите за обновлениями в ближайшие недели.

Дневник разработчиков MELD 100 🎉

2024-08-20T13:06:33.707Z

🎉 Добро пожаловать в 100-й выпуск Дневников разработчиков MELD! 🎉

Сегодня мы отмечаем монументальную веху - 100 недель нашего путешествия, роста и инноваций с вами, нашим невероятным сообществом. Почти два года вы были с нами на каждом шагу, отмечая наши победы, поддерживая нас в трудные времена и формируя экосистему MELD L1 такой, какая она есть сейчас. Это не просто очередное обновление, это празднование нашей общей приверженности, нашего прогресса и удивительного сообщества, которое сделало все это возможным. Итак, присаживайтесь и давайте погрузимся в последние новости от технической команды MELD!

Веб-приложение MELDapp:

Проводилась работа по улучшению пользовательского интерфейса путем добавления поддержки токенов Azomi DEX LP в основной сети МЭЛД (создание специальной категории в кошельке МЭЛД),
Разработано и развернуто в основной сети новое автономное платежное dApp (MELD Pay), используемое для регистрации бизнес-клиентов в сервисе MELD Banking,
Добавлено поле электронной почты для предоставления ключа в платежах MELD Pay.

Мобильное приложение MELDapp:

Продолжается подготовка к официальному релизу App Store,
Реализован последний комплекс мер по обработке ошибок и обновлены все всплывающие подсказки «i» в потоках обмена c2c, c2f и f2c,
Проведена работа по созданию эффективной службы поддержки клиентов для обслуживания тысяч пользователей, которые в скором времени начнут использовать мобильное приложение для iOS.

Solidity | Бэкэнд:

Реализован, развернут и верифицирован смарт-контракт для мониторинга протокола MELD по кредитованию и займам,
Реализован адаптер Supra Oracles Adapter V2 с новыми возможностями,
Добавлена дополнительная функциональность экспорта информации о PaymentReceiver в CSV-файл (онбординг предприятий в MELD Banking через MELD Pay),
Обновлен мост MELD Akamon для совместимости с эрой Conway,
Исследованы проблемы с Cardano Contract Deployer, связанные с Conway и Ogmios,
Интегрировали Blocklytics Subgraph с Tracking-Proxy,
Переделали устаревшую систему стейкинга с блокировкой Cardano, чтобы она была совместима с эрой Conway,
Протестирован новый стейкинг индексер локально в основной сети,
Обновили большинство репозиториев для совместимости с эрой Cardano Conway,
Протестировали все обновления в dev и stage окружениях,
Обновили kupo infra до последней версии.

Инфраструктура:

Мигрировали все dev и staging сервисы Cardano на новую ноду Cardano v9,
Настроили инфраструктуру для нового банковского сервиса MELD, предлагаемого бизнес-клиентам,
Настроили новую сборку и развернули рабочий процесс на github для нового сервиса MELD для бизнеса,
Развернули новую версию индексатора Kupo и перенаправили его на новую ноду Cardano.

Мы глубоко ценим вашу неизменную поддержку, которая остается для нас важнейшим элементом. Ваши отзывы имеют неизмеримую ценность, поскольку мы продолжаем совершенствовать и улучшать MELDapp. Следите за обновлениями в ближайшие недели.

Дневник разработчиков MELD 99

2024-08-13T19:52:05.628Z

Добро пожаловать! Приготовьтесь к последним новостям из дневников разработчиков MELD! На прошлой неделе наша команда достигла значительного прогресса и представила несколько интересных обновлений для приложения MELDapp.

Веб-приложение MELDapp:

Официально запущен автономный мост MELD Akamon в PROD (https://bridge.meld.com/),
Официально запущена интеграция моста в WebApp в PROD (https://app.meld.com/secret-code),
Улучшена обработка и управление ошибками моста MELD Akamon после получения отзывов от наших пользователей,
Изменен URL-адрес сведений о MELD NFT (теперь корректно перенаправляет на https://meldscan.io/),
Обновлена интеграция моста ChainPort в соответствии с регулярными мероприятиями по техническому обслуживанию.
Начата разработка платежного шлюза для привлечения предприятий в MELD и интеграция его с BlockSurvey,
Внесены небольшие обновления для Sentry.

Мобильное приложение MELDapp:

Продолжается подготовка к выпуску приложения,
Проведены дополнительные сквозные тесты для различных сценариев обмена в основной сети (криптовалюта-фиат, фиат-криптовалюта, крипто-криптовалюта),
Точная настройка структуры комиссий на странице сводки транзакций и в пользовательском интерфейсе деталей транзакций,
Улучшен пользовательский опыт в сфере поддержки клиентов (изменена система тикетов),
Добавлена улучшенная обработка ошибок при свопах,
Добавлена поддержка выбора банковского метода вывода средств SWIFT/SEPA,
Реализовано несколько исправлений ошибок на основе внутренних тестов и контроля качества.

Solidity | Бэкэнд:

Библиотека cardano-api обновлена до версии 9.1.0 для Meld Cardano multisig,
Реализован выбор монет для моста Cardano tx-builder service,
Обновлен пользовательский интерфейс администратора для перебалансировки только ADA для Cardano,
Исправлены неправильные выходные данные для блокировщика,
Размещено ADA на страницах администратора,
Реализован новый внутренний код для стейкинга на Cardano,
Обновление API Cardano до версии 9.1.0 для моста MELD,
Отслеживание: оптимизированные SQL-запросы для получения последних цен на все токены с целью сокращения времени обработки,
Meld-supported-token: обновленная документация по иконкам токенов,
Мост: Реализован API журнала событий для отладки,
Имя метаданных Bank Manager NFT преобразовано из Meld Bank Manager в Meld Banker при чеканке,
Исправлена ошибка неизменяемости подграфа: сущность роли не может быть удалена, если она неизменяема.
Докеризованный ликвидационный бот Django Dashboard,
Использован Django-Q для автоматизации процессов ликвидации,
Обновленные метаданные MELD Banker NFT,
Реализован смарт-контракт PaymentReceiver для привлечения бизнес-клиентов,
Развернут PaymentReceiver в Kanazawa и Ethereum.

Спасибо вам огромное за то, что вы всегда нас поддерживаете. Ваши отзывы очень важны и помогают нам продолжать улучшать MELDapp. Следите за обновлениями, которые появятся в ближайшее время!

Дневник разработчиков MELD 98

2024-08-05T18:10:48.942Z

Привет! Добро пожаловать в наши дневники разработчиков. Здесь мы даем вам возможность заглянуть за кулисы и увидеть, как мы делаем MELDapp еще лучше. Итак, чем мы занимались на прошлой неделе?

Веб-приложение MELDapp:

Подготовили автономный мост MELD Akamon Standalone bridge dApp для развертывания в производственной среде,
Подготовили веб-мост Akamon в MeldApp для развертывания в prod,
Реализована логика проверки ликвидности целевой сети для моста MELD,
Исправлена ошибка, позволявшая пользователям осуществлять бриджинг с не-MELD NFT-коллекциями,
Выведен из эксплуатации сервис обновления кошелька Cardano,
Выведен из эксплуатации сервис ранней регистрации MELD Finance Neobank,
Исправлен сбой WalletConnect при взаимодействии с Minswap в сети Cardano,
Обновление до узла 20,
Исправлены визуальные проблемы, связанные с управлением Metamask NFTs при подключении к MELDapp.

Мобильное приложение MELDapp:

Исправлена пагинация для истории транзакций,
Добавлены конечные точки API обмена фиата,
Добавлены конечные точки ввода и вывода фиата,
Исправлены проблемы с дублированием транзакций в истории,
Исправлена обработка транзакций обмена Meld в истории,
Подготовили сборку к релизу,
Настроили тестовую производственную среду,
Развернули фиатные службы в производственной среде для тестирования основной сети и исправления ошибок,
Проведены успешные транзакции по вводу и выводу EUR между счетом MELD и платформами TradFi,
Удалось успешно обменять фиат на криптовалюту и провести кроссчейн обмены криптовалют на криптовалюту (включая наш токен MELD в сети MELD),
Внесены незначительные улучшения в пользовательский интерфейс.

Solidity | Бэкэнд:

Пересмотрели и обновили технический документ по архитектуре бэкэнда MELD,
Написали API для возврата ролей для контрактов EVM моста,
Изучили синхронизацию реестра токенов Cardano и написали документацию по добавлению CNT в meld-supported-config,
Обновлен API для предотвращения проблем с рейс-состоянием при вставке новых токенов.
Обновление cardano-api до версии 9.1.0.0 для моста MELD Akamon,
Добавлено исправление для интеграции EVM-кошелька в интерфейс администратора и отсутствия синхронизации между приложением и кошельком.
Кран Cardano перенесен из репозитория DeFi в репозиторий отслеживания,
Обновление cardano-api до версии 9.1.0.0 для репозитория отслеживания,
Добавлена конфигурация токена и протестировано бриджинг MELD Bank Manager NFT из Cardano в блокчейн MELD в основной сети.
Кнопка вывода вознаграждения перемещена со страницы Cardano Manager на страницу доходности Cardano,
Срабатывание при входе в Ethereum для авторизации при обновлении адреса сети или кошелька,
Добавлена возвратная ликвидность токенов на основе пула в API мостовых контрактов,
Улучшенная страница администратора Cardano,
Очищенный адрес токена в API комиссии,
Обновленная эра для миграции токенов MELD Cardano,
Узел Cardano был расширен для миграции токена MELD Cardano,
Обновленный образ частной тестовой сети Cardano,
Проверено несколько контрактов в основной сети MELD,
Реорганизация, исправлены ошибки и повторно развернут ликвидационный бот в Каназаве,
Проведена работа над панелью управления ботом ликвидации.

Дневник разработчиков MELD 97

2024-07-29T18:47:13.077Z

Здравствуйте и спасибо, что присоединились к нам в Дневники разработчиков MELD! Это ваш эксклюзивный пропуск за кулисы всех обновлений, исправлений и достижений, которые мы сделали с MELDapp за последнюю неделю. Окунитесь в атмосферу и узнайте, что нового мы сделали!

Веб-приложение MELDapp:

Исправлена копия статуса для заблокированного MELD Banker NFT с предоставленным/заимствованным активом на вкладке NFT кошелька,
Реализованы флаги для предварительного развертывания в основной сети,
Развернули полностью разработанную систему Supply & Borrow (L&B) для подготовки к запуску в основной сети для финального раунда внутреннего тестирования e2e и проверок качества.
Исправлены проблемы с некоторыми устаревшими библиотеками,
Обновление MELD Akamon Bridge для поддержки внешних кошельков,
Исправлены некоторые несовместимости ChainPort,
Передали последнюю техническую документацию по архитектуре веб-приложения в виртуальную комнату данных MELD.

Мобильное приложение MELDapp:

Началось тестирование услуг по переводу фиатных денег на реальные средства (внесение средств на счет MELD, ввод в эксплуатацию, покупка криптовалют за фиатные деньги, вывод средств, обмен криптовалют на фиатные деньги, вывод средств),
Началось тестирование подписок на Премиум-аккаунты,
Передали последнюю техническую документацию по архитектуре мобильного приложения в виртуальную комнату данных MELD.

Solidity | Бэкэнд:

Протестировали основной сетевой мост MELD Akamon и исследовали все зависшие запросы на соединение,
В MELD Akamon Bridge Admin проверил, совпадают ли текущая и подключенная сети кошелька,
Улучшен пользовательский интерфейс администратора: перезагрузка после перебалансировки, применение сетки для исправления проблем со стилем,
Добавлено отслеживание для всех ролей паноптического и приемного контракта в подграфе,
Развернута новая версия отслеживания для производства, включая подграф кредитования,
Возвращено количество токенов на основе хранилища паноптического контракта в результате API контракта,
Введено получение имени и версии eip712 из подграфа вместо жестко заданных,
Передана последняя техническая документация по отслеживанию внутренних служб в виртуальную комнату данных MELD,
Добавлена страница регистрации для учетных данных ставки скрипта Cardano для обхода проблемы аппаратного кошелька,
Установлен новый ключ компонента при обновлении роли,
Изменено имя сети и хэш блока для конфигурации cardano-index,
Добавлены erc721 и erc1155 для отслеживания уведомлений,
Применен вход с помощью Ethereum для аутентификации API администратора,
Использовали библиотеку SIWE вместо пароля для авторизации в интерфейсе администратора моста,
Проверен неверный адрес назначения в службе моста, чтобы избежать обработки недействительного запроса,
Улучшенный интерфейс администратора: отключение кнопки перебалансировки во время перебалансировки, рефакторинг компонента оповещения для доходности Cardano,
Развернуты смарт-контракты Supply & Borrow (L&B) для предварительной подготовки в основной сети для финального раунда внутреннего тестирования.
Развернутые адаптеры Yield в Ethereum и Avalanche,
Настроены адаптеры в MELD Akamon Bridge,
Исправлены ошибки, обнаруженные в боте ликвидации.

Дневник разработчиков MELD 96

2024-07-23T07:37:28.449Z

Веб-приложение MELDapp:

Исправлены незначительные проблемы интеграции с логикой моста Chainport-Akamon,
Внедрены кнопки "Supply" и "Borrow" для компонента обзорной дашборда MELD Banker NFT (добавление выпадающего меню в поток "ADD YOUR BANKER"),
Для каждого типа MELD Banker NFT (обычный, золотой) теперь отображается реальный бонусный множитель,
Улучшены стили кнопок главного экрана,
Исправлены описания карточек Yield Boost и Banker Rewards на главном экране (введена динамическая формула для получения данных в режиме реального времени),
Реализован мост MELD Bank Managers NFT в основном приложении,
Реализована логика отображения и скрытия NFT с баланса пользователя в статусе «Выполняется мостовое соединение»,
Решены некоторые проблемы с версиями устаревших библиотек.

Мобильное приложение MELDapp:

Настроен экран списка продажи/отправки NFT,
Интегрированный RemoteImageViewкомпонент в экран сведений NFT,
Настроены экраны «Получатель», «Сумма» и «Сводка» потока отправки NFT,
Добавлена поддержка переводов EVM NFT,
Добавлена поддержка переводов Cardano NFT,
Добавлены кнопки покупки и продажи NFT на панель управления,
Добавлен список NFT-коллекций на панель управления,
Продолжение разработки базовой панели управления NFT,
Запустили мобильное приложение MELD в iOS App Store на очень короткое время в целях тестирования,
Обновленный конвейер для поддержки счетов разработки Zero X One от MELD.

Solidity | Бэкэнд:

Развернули новый контракт MeldBankerNFTMetadata для сред DEV и STAGING и перенес данные из старых контрактов,
Развернуто Supply & Borrow (L&B) v1 в STAGING env с детерминированными адресами для всех контрактов,
Улучшенные потоки Bridge Yield Farming для предотвращения недействительных адаптеров фермерства в протоколе,
Подготовлены данные для развертывания L&B в основной сети,
Поддерживается повторное делегирование в новый пул Cardano на странице администратора,
Пропущена регистрация стейкинг-адреса, если он уже зарегистрирован при обновлении роли для Cardano,
Отлажена и исправлена проблема с подграфом, связанная с Set,
Поддерживается ввод адреса на странице контроля доступа Cardano,
Добавлен компонент оповещения на страницы Cardano,
Развернули новый контракт Cardano для разработки, этапа и производства,
Добавлено отображение адресов и хэша публичного ключа на страницах Cardano,
Исправление: добавлена попытка перехвата при регистрации стейкинга.
Добавлен ts-ignore для сгенерированного кода,
Исправлен рабочий процесс развертывания для отслеживания репозитория и развертывания новой версии,
Токен доступа администратора перемещен в env вместо файла конфигурации,
Протестировали ребалансировку на административном интерфейсе,
Развернули новый токен erc20 в тестовой сети Fuji для проверки балансировки.
Обновлен API администратора для проверки того, что сумма всех целей для токена в каждой сети должна быть меньше 100%.
Добавлена боковая панель на страницу администратора,
Улучшена доходность административной EVM: подсчет общей суммы, внесенной в распределения, настройка цвета делегированной суммы на основе конфигурации распределения, использование больших чисел для предотвращения переполнения,
Протестировано администрирование моста и устранены выявленные проблемы: операции загрузки, стили,
Обновлена служба моста: удален трекер nonce, скорректирован лимит газа,
Проведены испытания моста MELD в основной сети.

Инфраструктура:

Развернуты промежуточные изменения инфраструктуры моста MELD,
Настроено и развернуто производственное VPC-обслуживание MELD Exchange,
Исправлены разрешения IAM для пользователя Spot GitHub Runner,
Развернуты новые изменения переменных ENV для API бэкэнда во всех средах,
Развернул новый адрес провайдера в промежуточной среде,
Исправлены проблемы с разрешениями IAM для роли исполнителя GitHub Spot.
Настроили новый кардано-узел с ogmios,
Развернули Cardano-node 9 в тестовой сети,
Развернули службу Cardano ogmios в тестовой сети,
Настроили Cardano ogmios.

Дневник разработчиков MELD 95

2024-07-15T21:39:42.470Z

Добро пожаловать! Приготовьтесь к последним новостям из дневников разработчиков MELD! На этой неделе наша команда достигла значительного прогресса и представила несколько интересных обновлений для MELDapp.

Веб-приложение MELDapp:

Развернули автономную финальную версию моста MELD Akamon для разработки,
Изменен сетевой идентификатор для моста MELD в веб-приложении,
Исправлена ошибка отображения цветовой темы моста,
Исправлено всплывающее сообщение моста при ожидании транзакции и добавлена возможность его закрыть.
Применены некоторые визуальные корректировки для Supply & Borrow:

— Отображение полного формата даты в активном просмотре сведений о кредите,

— Удалены ненужные вызовы,

— Добавлены новые подсказки для обеих сторон: предоставленные и заемные средства,

— Исправлены различия в ценах между панелью управления вознаграждениями Yield Boost и основным интерфейсом обзора,

— Отображение множителя MELD Banker NFT при активной предоставленной или заемной позиции.

Мобильное приложение MELDapp:

Добавлена поддержка карт NFT в Дашборд,
Добавлены виджеты NFT в Дашборд,
Создан компонент RemoteImage,
Создан компонент NftTile для нового представления коллекции на Дашборде,
Доработан экран подробностей NFT (кроме рендеринга изображений),
Настроен экран списка NFT маркетплейсов,
Подготовлена кодовая база для вывода фиатных денег для поддержки различных методов вывода (SEPA и SWIFT),
Интегрирована конечная точка для получения и сохранения получателей фиатных денег,
Определена конечная точка для получения остатков фиатных денег,
Исправлена незначительная проблема с прокруткой экрана депозита фиатных денег,
Улучшена регистрация сообщений об ошибках WalletConnect.

Solidity | Бэкэнд:

Изменены потоки MeldFarmingManager для предотвращения несогласованного статуса в мосту MELD Akamon,
Добавлены дополнительные проверки на мосту для повышения безопасности.
Реализовано больше тестов для повышения охвата тестированием >99%,
Адаптированный сценарий детерминированного развертывания для работы со связанными библиотеками и прокси,
Исправлены скрипты проверки для автоматической проверки реализаций прокси,
Реализован смарт-контракт для переноса метаданных для MeldBankerNFT в другие контракты метаданных,
Реализован новый контракт MeldBankerNFTMetadata, позволяющий обновлять AddressesProvider,
Адаптированный сценарий развертывания для автоматизации обновления AddressesProvider контракта NFT Metadata,
Обновлен идентификатор сети Cardano во всех конфигурациях сервиса,
Добавлен токен моста на MELD в поддерживаемые конфигурации,
Развернули и протестировали сервисы MELD Akamon Bridge в основной сети,
Реализован API для извлечения всех конфигураций распределения,
Применили сетку данных к компоненту Cardano-yield и переместили таблицу EVM-yield в ее компонент,
Реализована возможность обновления идентификатора пула Cardano,
Протестировали функционал администратора на DEV и исправили связанные с этим проблемы.
Добавлена роль администратора для страницы администратора,
Включены депозиты активов для ячеек на странице администратора,
Добавлен скрипт ребалансировки для Cardano,
Добавлена роль казначея в контракт Cardano,
Обновлены сведения о NFT и токенах на странице администратора,
Управляемый вывод вознаграждений на Cardano из интерфейса администратора,
Проверили отчет по аудиту кредитования и новый код контракта, затем обновили подграф кредитования, чтобы адаптировать развертывание нового контракта,
Написаны интеграционные тесты для бриджинга токенов MELD,
Добавлены миграция БД и развертывание подграфа в рабочий процесс отслеживания релизов.
Обновлена админка для поддержки ребалансировки только ADA для Cardano,
В управлении доходностью Cardano отключен первый входной коэффициент стейкера и он рассчитывается автоматически на основе остальных.
Обновлен API ребалансировки для поддержки повторного делегирования в указанный пул Cardano.
Проверен API ребалансировки с помощью конфигуратора вместо исполнителя,
Обновленные роли для Cardano,
Добавлен валидатор контроля доступа в API,
Разбили страницу Cardano на более мелкие компоненты,
Развернуты и протестированы сервисы MELD Akamon Bridge на этапах разработки и подготовки.

Инфраструктура:

Настроена и развернута готовая инфраструктура для моста MELD Akamon,
Изменены правила группы безопасности основной сети и тестовой сети граф-узла,
Перенесен основной узел графа Aurora на более крупный экземпляр,
Развернуты изменения группы безопасности для cardano-node, kupo и graph-node в тестовой сети,
Изменена политика доступа к контейнерам S3 для пользователя Github,
Создан новый образ Spot GitHub Runner.

Ваша неизменная поддержка для нас очень важна! Ваши отзывы для нас как золото, так как мы продолжаем делать MELDapp еще лучше. Приготовьтесь к тому, что в ближайшие недели вас ожидают интересные обновления!