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

Фон

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

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

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

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

Тем не менее, рабочий контекст изменился значительно.

Почему LTO Layer 1 должен быть отменен

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

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

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

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

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

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

  • Узлы сообщества больше не являются экономически жизнеспособными.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Близкое соответствие слою активов и ликвидности EQTY, который также существует на Base

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

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

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

  • Поддержание Layer 1 предоставляет мало стратегического преимущества при высоких затратах.

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

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

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

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

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

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

3. Контракт анкоринга на Base

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

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

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

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

Интерфейс

структура Anchor {

bytes32 ключ;

bytes32 значение;

}

функция anchor(Anchor[] calldata anchors) external;

событие Анкоринг(

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

bytes32 значение,

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

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

);

Поведение

  • Контракт испускает одно событие Анкоринга на каждую пару (ключ, значение).

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

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

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

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

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

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

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

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

  • Клиентам необходимо вызвать approve() на контракте ERC20 для включения анкоринга

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

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

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

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

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

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

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

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

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

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

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

Область и содержание

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

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

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

  • Поддерживающий код Включает утилитарные классы, такие как 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 новым индексатором, который обрабатывает события Анкоринга, испускаемые контрактом анкоринга 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=...) должны включать токен доступа в заголовке Authorization.

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

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

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

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

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

  • ключ = messageHash

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

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

  • blockNumber, txHash, timestamp

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

  • Существует событие Анкоринга с ключом = messageHash

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

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

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

Реле выполняет эту проверку, используя свой собственный внутренний индексатор и не полагается на oBridge.

8. Изменения контракта Ownable (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>. Контракт проверяет, что:

  • Сеть события совпадает с ожидаемой сетью

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

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

Влияние

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

  • Полностью совместим с Ethereum-родным подписанием и идентичностью

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

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

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

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

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

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

  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 (Sign-In with Ethereum)

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

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

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

  • Пользовательский интерфейс аренды LTO

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

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

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

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

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

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

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

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

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

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

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

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

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

Нет снимка

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

#ETH