1. Введение и мотивация

Фон

Платформа EQTY основывается на архитектуре с двумя уровнями:

  • Частный уровень для управления проверяемыми цепочками событий (например, Ownables, сообщения)

  • Публичный уровень якорения для временной метки и проверки этих цепочек событий на неизменяемом блокчейне

Исторически этот публичный уровень предоставлялся LTO Network Layer 1, специализированным блокчейном Proof-of-Stake, оптимизированным для якорения.

Однако операционная обстановка значительно изменилась.

Почему уровень LTO 1 должен быть устаревшим

1. Экономическая безопасность рухнула

  • В настоящее время рыночная капитализация LTO составляет менее 5 миллионов долларов, при этом только ~20% токенов заложены.

  • Это означает, что эффективный бюджет безопасности (т.е. общая стоимость, обеспечивающая консенсус) составляет < 1 миллион долларов.

  • На этих уровнях финансово целесообразно, чтобы злонамеренный актор нарушил консенсус, цензурировал транзакции якорения или переписал историю.

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

2. Централизация валидаторов и низкие стимулы

  • Сообщество узлов больше не экономически жизнеспособно.

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

  • Это подрывает гарантии децентрализации, которые якорение должно обеспечивать.

3. Трение в принятии

  • С каждым годом становится все сложнее оправдать LTO в качестве надежного уровня якорения в продажах или аудитах.

  • Клиенты и партнеры ожидают, что EQTY будет якорить на широко принятых и надежных публичных сетях (например, Ethereum, Base).

  • Восприятие «якорения на уровне 1 с капитализацией $5M» подрывает доверие к основной инфраструктуре EQTY.

4. Хрупкость инфраструктуры

  • Если даже несколько ключевых валидаторов выйдут из строя, LTO станет нестабильным или полностью остановится.

  • Продолжение обслуживания (эксплореры, индексаторы, инфраструктура узлов) добавляет накладные расходы с уменьшающейся ценностью.

Почему Base является правильным уровнем якорения

Base предлагает:

  • Полная совместимость с EVM

  • Экономическая и техническая безопасность, унаследованная от Ethereum

  • Широкая поддержка инструментов (MetaMask, WalletConnect, The Graph и др.)

  • Почти нулевые комиссии с быстрой финализацией

  • Близкое соответствие с активами и ликвидностью EQTY, которые также находятся на Base

Якорение на Base снимает бремя поддержания собственного уровня 1, увеличивая аудируемость, совместимость и доверие.

Стратегическая мотивация

  • Ценность EQTY не в консенсусе — она в его частном уровне, модели активов и архитектуре соблюдения.

  • Поддержание уровня 1 предлагает небольшие стратегические преимущества при высокой стоимости.

  • Переход на Base позволяет EQTY сосредоточиться исключительно на принятии продукта, юридической интеграции и токенизации активов, не отвлекаясь на инфраструктуру уровня 1.

2. Новый токен $EQTY ERC-20

Платформа EQTY введет новый токен ERC-20, $EQTY, развернутый в сети Base. Этот токен заменяет токен LTO и служит в качестве родной валюты для операций протокола, включая якорение и управление.

Контракт токена начинается с нулевого запаса. $EQTY выпускается по запросу, когда пользователи обменивают свои токены LTO в течение ограниченного периода миграции. Этот срок обеспечивается в блокчейне: после предопределенной высоты блока функция выпуска становится навсегда отключенной. Любые токены LTO, не обмененные до этого предела, исключаются из экосистемы EQTY, а окончательный запас $EQTY будет меньше исходного запаса LTO.

Контракт токена намеренно минимален. Он следует стандартному интерфейсу ERC-20, без специальной логики передачи, функций airdrop или графиков вестинга.

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

3. Контракт якоря на Base

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

Каждый якорь сопоставляет ключ со значением, где:

  • Для цепочек событий: ключ = stateHash, значение = eventHash

  • Для сообщений: ключ = messageHash, значение = 0x0

Интерфейс

struct Anchor {

bytes32 ключ;

bytes32 значение;

}

function anchor(Anchor[] calldata anchors) external;

событие Anchored(

bytes32 индексированный ключ,

bytes32 значение,

адрес индексированный отправитель,

uint64 временная метка

);

Поведение

  • Контракт вызывает одно событие Anchored для каждой пары (ключ, значение).

  • Текущая метка времени блока включена в событие в качестве отдельного поля для удобства и аудита.

  • В контракте не хранится состояние. Все данные якорения записываются только через логи.

  • Контракт не требует разрешений — любой может якорить.

Эти события предназначены для индексации и доступа:

  • Внутренние компоненты, такие как индексатор oBridge и платформа EQTY

  • Внешние сервисы, включая The Graph, Infura или пользовательские проверяющие

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

Механизм сборов

  • Клиенты должны вызвать approve() на контракте ERC20, чтобы разрешить якорение

  • Каждый якорь влечет за собой сжигание $EQTY, что обеспечивается в функции anchor()

  • Сумма платы считывается из отдельного контракта конфигурации под контролем управления

  • Якорение не будет использовать approve(), а вместо этого сжигать через eqtyToken.burnFrom(msg.sender, fee * n)

4. Управление сборами

Чтобы сохранить якорение экономически устойчивым и справедливым с течением времени, плата, выплачиваемая в $EQTY за якорь, должна быть регулируемой. Вместо жесткого кодирования статической платы или полагания на ценовые оракулы, EQTY будет использовать модель управления в блокчейне, чтобы контролировать этот параметр прозрачным и децентрализованным способом.

Специальный контракт конфигурации будет хранить текущую плату за якорение. Это значение может быть обновлено только контрактом управления — конкретно, экземпляром Governor от OpenZeppelin, связанным с токеном $EQTY. Голоса будут отданы на основе остатков $EQTY с использованием стандартной логики ERC20Votes.

Контракт якорения считывает текущую плату из контракта конфигурации каждый раз, когда вызывается anchor(). Затем он сжигает соответствующее количество $EQTY непосредственно из баланса отправителя. Этот подход избегает необходимости в транзакциях approve() и гарантирует, что контракт якорения остается легковесным и бессостоянием за пределами обеспечения сборов.

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

5. Новая библиотека частного уровня

Чтобы поддержать якорение на Base и подписание на основе кошелька, будет создана новая отдельная библиотека TypeScript для обработки логики частного уровня — включая цепочки событий, подписания событий, якорение и структуры сообщений реле. Эта библиотека заменяет LTO-специфичную @ltonetwork/lto-api.js для всех случаев использования EQTY.

Новая библиотека предназначена для использования как в браузерных средах (например, MetaMask, WalletConnect), так и в серверных инструментах.

Объем и содержимое

Будут включены только соответствующие компоненты частного уровня LTO:

  • события/ Включает Event, EventChain, MergeConflict и связанную сериализацию.

  • сообщение/ Включает Message и Relay, используемые для зашифрованной связи вне цепи.

  • Поддерживающий код включает утилитарные классы, такие как Binary.

Библиотека не будет иметь зависимости от LTO Network:

  • Нет API узлов LTO

  • Нет логики транзакций

  • Нет инструментов генерации пар ключей

  • Нет кодирования адресов, специфичных для LTO

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

Модель подписания событий

Метод Event.signWith() будет асинхронным, чтобы поддерживать подписание в браузере через MetaMask, WalletConnect или любого внешнего подписанта, в дополнение к подписанию напрямую с помощью ethers. Он использует абстрактный интерфейс ISigner:

интерфейс ISigner {

sign(data: Uint8Array): Promise<Uint8Array>;

}

Подписанное событие больше не требует открытого ключа; оно включает только подпись и производный адрес. Это делает его совместимым с потоками подписания Ethereum (personal_sign) и устраняет необходимость извлекать открытые ключи, что невозможно в большинстве сред кошельков.

Интеграция якорения

Библиотека включает метод для генерации карт якорей:

const anchors = chain.from(lastKnownEvent.hash).getAnchorMap();

Каждый якорь сопоставляет stateHash (ключ) с lastEventHash (значение), готовым к отправке в смарт-контракт Base. Для сообщений реле используется сам хеш сообщения в качестве ключа якоря, а значение устанавливается в ноль (0x0).

Якорение может выполняться путем непосредственного вызова смарт-контракта через ethers.Contract.anchor(Anchor[]). Это избегает зависимости от любых бэкенд-сервисов или проприетарной инфраструктуры.

Подписание сообщений

Библиотека также включает классы Message и Relay для оффлайн-коммуникации. Как и события, сообщения подписываются асинхронно с использованием интерфейса ISigner. Подписи делаются по хешу сообщения, и открытый ключ не включается — используется только производный адрес для проверки.

После подписания хеш сообщения якорится в блокчейне через тот же контракт Anchor. Формат:

  • ключ = messageHash

  • значение = 0x0

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

Развертывание и использование

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

  • Кошелек EQTY (для подписания событий и сообщений)

  • Служба реле (для вычисления хешей и разбора сообщений)

  • SDK Ownables (для построения и подачи событий)

  • Любой сторонний интерфейс или проверяющий

6. Индексация oBridge

Служба oBridge заменит свою текущую логику индексации на основе LTO на новый индексатор, который обрабатывает события Anchored, сгенерированные контрактом якорения Base.

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

  • ключ: зафиксированное состояние или хеш сообщения

  • значение: соответствующий хеш события или 0x0

  • txHash, blockNumber, logIndex и отправитель

Эти записи доступны через публичный HTTP API. Структура и поведение этого API останутся совместимыми с существующим индексацией якорения LTO, включая конечную точку GET /hash/verify, что позволит существующим компонентам EQTY перейти с минимальными изменениями.

Индексатор oBridge выполняет две роли:

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

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

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

7. Служба реле

Сервис реле обеспечивает безопасную доставку зашифрованных сообщений между сторонами. Чтобы гарантировать, что сообщения являются подлинными, имеют метку времени и контролируются доступом, сервис будет обновлен для поддержки как проверки якоря в блокчейне, так и современной аутентификации, нативной для кошельков, с помощью Sign-In with Ethereum (SIWE).

Аутентификация сообщений с SIWE

Вместо того чтобы полагаться на подписи сообщений HTTP или пользовательские проверки, реле реализует стандарт SIWE (EIP-4361). Этот подход позволяет пользователям аутентифицироваться, подписывая стандартное текстовое сообщение с помощью своего Ethereum-кошелька, создавая восстанавливаемую подпись, которая связывает их сессией.

Поток входа:

  1. Клиент запрашивает сообщение SIWE у бэкенда реле: GET /auth/siwe-message?address=0x...

  2. Сервер возвращает стандартное сообщение SIWE, включая:

  • Домен (например, relay.eqty.network)

  • Nonce

  • Срок действия метки времени

  • Дополнительное поле ресурсов ограничено /messages?to=...

  • Заявление: например, “Войдите, чтобы получить доступ к своим сообщениям EQTY.”

  1. Клиент подписывает сообщение с помощью personal_sign

  2. Клиент отправляет подписанное сообщение и подпись на POST /auth/verify

  3. Сервер проверяет подпись и выдает:

  • JWT токен доступа (краткосрочный, например, 15 минут)

  • Токен обновления (долгосрочный, например, 24 часа)

Все последующие запросы на получение сообщений (GET /messages?to=...) должны включать токен доступа в заголовке Авторизации.

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

Эта модель полностью совместима с MetaMask, WalletConnect и другими кошельками EIP-1193, и следует широко принятым шаблонам безопасности. Не требуется никакой пользовательской логики или инфраструктуры, кроме существующих библиотек SIWE.

Якорение и проверка сообщений

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

Служба реле поддерживает свой собственный легковесный индексатор для контракта по якорению на Base. Она слушает события Anchored и записывает:

  • ключ = messageHash

  • значение = 0x0

  • отправитель

  • blockNumber, txHash, timestamp

Чтобы проверить сообщение перед доставкой, реле проверяет, что:

  • Существует событие Anchored с ключом = messageHash

  • Значение равно 0x0 (т.е. не является якорем цепочки событий)

  • Отправитель совпадает с подписантом сообщения (т.е. адресом отправителя)

Только после успешного якорения сообщение будет выпущено получателю. Это гарантирует, что все сообщения публично проверяемы, имеют временные метки на Base и якорятся правильной идентичностью.

Служба реле выполняет эту проверку с использованием своего собственного внутреннего индексатора и не полагается на oBridge.

8. Изменения контракта собственника (CosmWasm)

С переходом от LTO Layer 1 и устареванием подписания событий на основе открытых ключей контракты Ownable должны быть обновлены для поддержки авторизации на основе адресов с использованием стандартных адресов Ethereum.

Авторизация на основе адресов

Ранее проверка собственности полагалась на восстановление и сравнение открытых ключей, извлеченных из подписанных событий. Поскольку кошельки Ethereum не раскрывают открытые ключи, а подписи теперь используют personal_sign (восстанавливаемые в адрес), модель проверки должна измениться на прямое сравнение адресов.

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

Это затрагивает все входные точки, где требуется авторизация:

  • try_transfer: отправитель должен совпадать с текущим адресом владельца

  • try_release: отправитель должен совпадать с предыдущим заблокированным адресом владельца

  • try_register_lock: проверяет, что поле владельца события совпадает с подписантом

Вместо преобразования открытых ключей в адреса LTO контракт просто хранит и сравнивает значения Addr (например, 0xabc123...).

CAIP-2 и соответствие сети

Контракт продолжает проверять источник кросс-цепочных событий с использованием идентификатора сети CAIP-2. Для сообщений на основе Ethereum пространство имен – eip155:<chainId>. Контракт проверяет, что:

  • Событие .network соответствует ожидаемой сети

  • Поле владельца в событии совпадает с подписантом (info.sender) в рамках данного пространства имен CAIP

Функции преобразования address_lto() и address_eip155() могут быть удалены, так как больше не требуется перевод в или из адресов LTO.

Влияние

Это изменение делает контракт Ownable:

  • Полностью совместим с нативным подписанием и идентификацией Ethereum

  • Независимо от инфраструктуры ключей LTO

  • Совместим с любой цепочкой, которая поддерживает восстановление на основе адресов (например, EVM)

Существующие Ownables, которые полагаются на подписание и якорение, специфичные для LTO, станут недействительными в новой модели и должны быть повторно выпущены (см. Раздел 11).

9. Обновление SDK Ownables

SDK Ownables должен быть обновлен, чтобы отразить переход от подписания с использованием открытых ключей на базе LTO к авторизации на основе адресов в стиле Ethereum и якорению на базе.

Ключевые обновления

  1. Подписание событий

  • Обновите создание событий, чтобы использовать новую библиотеку частного уровня (@eqty-core/events)

  • Используйте реализации ISigner, совместимые с MetaMask, WalletConnect или подписчиками на основе ethers

  • Убедитесь, что signWith() больше не зависит от открытого ключа; используется только восстанавливаемый адрес

  1. Якорение

  • Замените логику якорения узлов LTO на подачу смарт-контракта на Base

  • Используйте getAnchorMap() для сбора пар (ключ, значение) и отправляйте их через ethers.Contract.anchor()

  • Убедитесь, что якорение сообщений использует (ключ = messageHash, значение = 0x0)

  1. Проверка

  • Обновите логику проверки, чтобы использовать совместимый с oBridge API /hash/verify или прямой запрос журнала

  • Подтвердите, что значение якоря соответствует ожидаемому хешу события и что отправитель совпадает с адресом Ethereum подписанта

  1. Использование адресов

  • Замените любую логику, которая сравнивает или генерирует адреса LTO

  • Используйте обычные адреса Ethereum (0x...) на протяжении всего потока событий и сообщений

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

Обновленный SDK остается структурно похожим, но больше не связан с библиотекой @ltonetwork/lto-api.js или услугами узлов LTO. Он совместим с новой библиотекой частного уровня и якорением на Base и будет взаимодействовать с обновленными контрактами Ownable и службой реле.

10. Обновление Универсального Кошелька

Универсальный кошелек должен быть обновлен, чтобы отразить миграцию на Base и новую архитектуру EQTY. Он больше не взаимодействует с узлами LTO.

Основные обновления

  1. Подключение кошелька

  • Замените обработку пар ключей LTO на совместимую с Ethereum библиотеку (ethers.js)

  • Используйте интерфейсы поставщика EIP-1193 для включения подписания и получения адресов

  1. Поддержка токенов

  • Добавьте поддержку отображения и управления балансами нового токена $EQTY ERC-20 на Base

  • Включите метаданные токена, историю и отслеживание баланса через публичные конечные точки RPC

  1. Подписание событий и сообщений

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

  • Используйте personal_sign через подключенный кошелек; открытые ключи больше не требуются

  1. Якорение

  • Отправьте карты якорей непосредственно в контракт якоря Base с помощью ethers.js

  • Обработайте подачу в цепочку, подтверждение и необязательную обратную связь пользовательского интерфейса для стоимости якорения в $EQTY

  1. Интеграция реле

  • Аутентификация через SIWE (вход с Ethereum)

  • Храните и обновляйте токены доступа по мере необходимости

  • Используйте аутентифицированные запросы для получения зашифрованных сообщений от службы реле

Удаленные функции

  • Интерфейс аренды LTO

  • Выбор узлов и просмотр цепи

  • Управление идентификацией в блокчейне, связанное с LTO

11. План миграции

С устареванием LTO Layer 1 и введением новой системы якорения на Base все основные компоненты протокола должны мигрировать. Устаревшие данные, связанные с инфраструктурой LTO — включая якоря, цепочки событий и сообщения — больше не будут действительными.

Что становится недействительным

  • Цепочки событий, подписанные с использованием пар ключей LTO, не могут быть проверены, так как открытый ключ больше не может быть извлечен из подписей на базе Ethereum.

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

  • Объекты, связанные с идентификациями на базе LTO или якорными цепями, должны быть заменены.

  • Сообщения, не закрепленные на Base, будут отклонены службой реле.

Необходимые действия

  1. Миграция токеновПользователи должны вручную обменять свои токены LTO на $EQTY с помощью моста. Выпуск возможен только до определенной высоты блока на Base. После этого блока мост будет закрыт, а функция выпуска станет навсегда отключенной. Необмененные токены LTO становятся бесполезными.

  2. Выпустить активы Ownables.Эмитенты Ownable должны выпустить новые ownables, привязанные к сети BASE. Инструкции последуют о том, как обменять устаревшие Ownables на новые Ownables

  3. Переход на кошелек Пользователи должны обновить Универсальный Кошелек.

Нет снимка

Не будет снимка, автоматической миграции или слоя обратной совместимости. Каждый компонент (события, сообщения, балансы токенов) должен быть восстановлен на Base через соответствующие интерфейсы. Новый протокол чист по дизайну и не сохраняет связи с LTO L1.

#ETH