Вопросы на собеседовании: Блокчейн-разработчик

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

• В пуле с постоянным произведением чистая входная сумма после комиссии двигает цену по кривой x умножить на y и ограничивает выходную сумму.
• Если комиссия остается в пуле, фактическое произведение резервов после обмена обычно растет, поэтому инвариант не означает, что численное значение k навсегда фиксировано.
• Хранимые резервы, токен-балансы и предложение LP-долей могут разойтись после donation или rebase, поэтому протокол должен явно определить момент синхронизации и то, как эта стоимость достается LP.

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

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

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

• Каждый инициализированный тик хранит чистое изменение ликвидности, и при его пересечении эта величина добавляется к активной ликвидности или вычитается из нее.
• Позиция хранит владельца, нижний тик, верхний тик и объем ликвидности, часто в виде NFT, потому что провайдеры выбирают разные диапазоны и их доли больше не взаимозаменяемы.
• Комиссии рассчитываются по глобальному росту комиссий и росту за пределами двух границ, поэтому позиция зарабатывает только пока цена находится внутри диапазона.
• Узкие диапазоны повышают эффективность капитала, но требуют активного управления и делают обмен дороже при пересечении множества инициализированных тиков.

LTV ограничивает начальную сумму займа, а порог ликвидации определяет момент, когда позиции уже не хватает обеспечения.

• Доступный заем рассчитывается по стоимости залога из оракула, умноженной на LTV каждого актива, поэтому залог стоимостью 100 при LTV 80 процентов поддерживает не более 80 долга.
• Платежеспособность сравнивает залог с поправкой на порог ликвидации и текущий долг, обычно через health factor, при значении ниже 1 позицию можно ликвидировать.
• Разница между LTV и порогом ликвидации служит запасом на движение цены и накопление процентов, а не дополнительной ликвидностью для свободного вывода.

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

• Утилизация обычно равна объему займов, деленному на сумму свободных средств и займов, при последовательном учете резервов по правилам конкретного протокола.
• Ломаная кривая плавно растет ниже целевого уровня, например 80 процентов, и круто выше него, чтобы стимулировать погашение и приток депозитов.
• Доходность поставщика выводится из ставки займа, утилизации и reserve factor, поэтому она ниже объявленной ставки заемщика.
• Высокая ставка оценивает дефицит ликвидности, но не создает деньги мгновенно, поэтому дизайн вывода и резервов не должен считать доступность гарантированной кривой.

Бонус платит ликвидатору за восстановление платежеспособности, а close factor ограничивает долю долга, которую можно погасить за одну ликвидацию.

• Ликвидатор погашает долг и получает залог стоимостью погашения плюс бонус, который должен покрывать gas, движение цены и риск исполнения без лишнего изъятия залога.
• Close factor в 50 процентов не дает одному вызову закрыть весь долг, но при быстром падении цены может оставить позицию под риском на несколько ликвидаций.
• Безнадежный долг появляется, когда оставшегося залога с учетом бонуса и рыночной цены недостаточно для покрытия оставшегося долга.
• Тогда протоколу нужен явный путь распределения убытка через резервы, страховку или поставщиков, потому что больший бонус не вернет стоимость, которой уже нет.

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

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

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

• В контрольной точке контракт добавляет к аккумулятору новые награды, умноженные на коэффициент точности и разделенные на общий стейк.
• Ожидающая награда пользователя равна его стейку, умноженному на аккумулятор и деленному на коэффициент точности, минус reward debt, поэтому награду нужно зафиксировать до изменения стейка.
• После депозита, вывода или получения награды reward debt устанавливается по новому стейку пользователя и текущему аккумулятору с делением на тот же коэффициент.
• Дизайн должен определить судьбу наград при нулевом общем стейке и сохранить достаточную точность, чтобы пыль от целочисленного деления нельзя было извлекать повторно.

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

• Задержка должна покрывать окно доказательства, оспаривания и финальности сети, а ожидающий вывода стейк должен оставаться доступным для штрафа весь этот период.
• Условия штрафа должны объективно доказываться и иметь предел, причем нарушения безопасности вроде equivocation требуют более сильного наказания, чем короткий простой.
• Начало unbonding не должно отвязывать стейк от периода совершенного нарушения, чтобы более позднее доказательство все еще позволяло применить штраф до закрытия окна.
• Более долгая задержка усиливает ответственность, но повышает стоимость блокировки капитала и спрос на liquid staking, поэтому ее выбирают по реальной задержке обнаружения.

После callback кредитор должен получить обратно основную сумму и согласованную комиссию либо откатить всю транзакцию.

• Кредитор фиксирует баланс, переводит актив, вызывает получателя, а затем проверяет итоговый баланс или списывает точную сумму с комиссией по одобренному стандарту вроде ERC-3156.
• Успешное возвращаемое значение callback не доказывает погашение, поэтому баланс или результат перевода проверяется независимо от внутреннего учета получателя.
• Получатель должен проверить кредитора и инициатора до выполнения действий, чтобы произвольный вызывающий не мог запустить approvals или привилегированную callback-логику.
• Любая ошибка погашения атомарно откатывает перевод и все вложенные действия, что и делает возможным необеспеченный заем на одну транзакцию.

Я бы проводил границы вокруг владения инвариантами и полномочий, а не только вокруг бизнес-сущностей.

• Каждый критический факт учёта, например общий долг или объём выпущенных долей, должен принадлежать одному модулю, который раскрывает узкие команды вместо общего изменяемого состояния.
• У межмодульной операции должен быть один атомарный координатор, который проверяет предусловия и применяет все связанные переходы, с явными точками проверки инварианта и правилами reentrancy вокруг обязательных callback.
• Интерфейсы должны фиксировать единицы измерения, округление, предположения о доверии и поведение при ошибке, чтобы вызывающий модуль не переосмысливал значения другого модуля.
• Направление зависимостей, полномочия обновления и область паузы должны следовать той же границе, ограничивая состояние и права, затронутые ошибкой модуля.

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

• Неизменяемость подходит небольшому устоявшемуся ядру, когда пользователи могут проверить постоянные правила и перенести активы в замену без привилегированной миграции.
• Обновляемость подходит компонентам, чьи интеграции или параметры риска должны развиваться, но добавляет ограничения хранилища и полномочие заменить всю делегируемую логику.
• Гибрид может оставить хранение активов и основной учёт неизменяемыми, а настраиваемую политику или интеграции вынести в строго ограниченные заменяемые модули.
• Архитектура должна явно показывать область обновления, задержку, пределы отката и возможность выхода пользователя, поскольку это гарантии протокола, а не детали реализации.

Я бы выбирал паттерн по размеру парка, гранулярности обновлений, стоимости развёртывания и тому, кому доверено менять код.

• UUPS подходит независимо обновляемым экземплярам с небольшими прокси, если каждая реализация сохраняет совместимую логику обновления и строго авторизует обновления.
• Transparent-прокси подходят независимым экземплярам, когда отдельный ProxyAdmin и разделение административных вызовов по отправителю оправдывают более тяжёлое развёртывание.
• Beacon-прокси подходят однородному парку, который должен обновляться целиком через один beacon, с принятием общего радиуса поражения одного обновления beacon.
• Минимальные клоны подходят множеству дешёвых экземпляров с фиксированной реализацией; если им нужны согласованные обновления, парк beacon обычно понятнее, чем скрытая изменяемость клонов.

Diamond сопоставляет маршрутизируемые селекторы функций с facets и делегирует эти вызовы, поэтому код facet работает с адресом и хранилищем diamond.

• Неизменяемые функции исполняются прямо в diamond, а fallback для остальных msg.sig находит facet, передает calldata через delegatecall и возвращает его данные либо ошибку.
• diamondCut атомарно добавляет, заменяет и удаляет селекторы, а затем может через delegatecall выполнить инициализацию нового состава.
• Функции loupe раскрывают facets и соответствия селекторов, чтобы клиенты и инструменты могли проверить текущий интерфейс.
• Поэтому полномочие diamondCut позволяет менять код всего diamond и должно быть защищено так же, как обновление прокси.

Я бы считал пространства имён хранилища и таблицу селекторов постоянными схемами, которые должна проверять каждая операция cut.

• Каждый домен facet может закрепить структуру хранилища за уникальным детерминированным слотом, а поля внутри пространства имён должны добавляться только в конец и сохранять совместимые типы.
• Общее для facets состояние должно иметь одно каноническое представление и accessor, чтобы разные facets не создали конкурирующие копии одного инварианта.
• Cut должен отклонять добавление существующего селектора, замену на тот же facet, удаление отсутствующего селектора или потерю обязательных селекторов интерфейса.
• Перед атомарным применением всех изменений манифест cut должен сравнить старое и новое владение селекторами, layouts хранилища, поддержку интерфейсов и эффекты инициализации.

Я бы моделировал роли как узкие полномочия с явными административными связями и отделял рабочие права от права их выдавать.

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

Я бы дал каждому механизму одну задачу: multisig подтверждает порог подписей, timelock задерживает обычные изменения, а guardian только ограничивает ущерб.

• Обновления, переводы казначейства и долгосрочные изменения параметров должны исполняться через timelock после авторизованного предложения и задержки на проверку, а не напрямую ключами подписантов.
• Multisig может владеть ролями proposer или администратора, но его порог и разнообразие подписантов не заменяют публичную задержку исполнения.
• Guardian может поставить ограниченную область на паузу или отменить действие в очереди, но не должен обновлять код, перемещать средства пользователей или обходить timelock.
• Снятие паузы и восстановление обычных полномочий должны идти по более строгому пути, чтобы компрометация самого быстрого ключа не дала постоянный контроль.

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

• Управление паузой должно быть гранулярным по модулю и действию, блокируя займы, плечо, рискованные сделки и небезопасные выводы, но по возможности сохраняя погашения, получение средств, отмены и добавление залога.
• Путь выхода должен использовать консервативный учёт и не зависеть от необязательных компонентов, которые может отключить та же авария, например изменяемой интеграции или нового рискованного чтения оракула.
• Guardian может быстро включить ограниченную паузу, а её снятие и любое расширение ограничений требуют более сильного отложенного полномочия.
• Если немедленный вывод нарушает платёжеспособность или порядок расчётов, протоколу заранее нужен механизм пропорционального погашения или отложенного выхода вместо бессрочной заморозки.

Я бы рассчитывал все три параметра по исторической силе голоса и настраивал их по участию и концентрации, а не по текущим балансам токенов.

• Checkpoints делегирования должны фиксировать силу голоса каждого аккаунта на snapshot предложения, чтобы переводы во время голосования не дублировали и не перемещали голоса.
• Ненулевая задержка голосования даёт делегатам время отреагировать и помещает snapshot после создания предложения по явно выбранным часам на основе блоков или timestamps.
• Quorum должен быть документированной долей исторического доступного supply с ясным учётом воздержавшихся, чтобы изменения supply не переписывали требование активного предложения.
• Proposal threshold должен сдерживать спам, но допускать обоснованные предложения меньшинства, а изменение threshold или quorum само должно проходить через отложенное управление.

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

• Голоса и право создать предложение должны читаться из checkpoints до активации, а задержка голосования должна исключать полезную силу токенов, взятых и возвращённых в одной транзакции.
• Если токены голосования широко доступны для займа, возраст стейка, срок блокировки или усреднённая по времени сила голоса защищают от краткосрочных позиций, которые всё ещё допускает простой snapshot блока.
• Quorum и proposal threshold должны использовать тот же исторический источник голосов, а концентрацию делегирования и wrapper-контракты нужно включать в модель захвата.
• Timelock, ограниченное право guardian на отмену, неизменяемые пределы критических полномочий и окно выхода пользователей сдерживают вредоносные предложения, но не делают честным действительно купленное большинство.