Механизм Sui Proof-of-Stake (PoS) объединяет эпохи и наборы валидаторов для обеспечения сетевой безопасности и консенсуса, что значительно отличается от цепочек EVM. Вот подробное объяснение, адаптированное к вашим целям разработки:

Эпохи в Суе

Sui работает в отдельные периоды времени, называемые эпохами, каждый из которых длится около 24 часов (настраивается, по умолчанию 864 000 слотов со скоростью ~150 мс на слот). Эпохи управляют изменениями набора валидаторов и параметрами консенсуса:

• Структура: каждая эпоха начинается с настройки параметров системной транзакции (например, пороговых значений ставок, вознаграждений) и заканчивается контрольной точкой, завершающей изменение состояния.
• Переход: валидаторы предлагают ввести новую эпоху с помощью вызова на перенос системы. Для этого требуется согласие в формате «2f+1» (где f — максимальное количество ошибочных валидаторов). Это приводит к переконфигурированию, когда сеть ненадолго приостанавливается.
• Назначение: Epochs позволяет динамически обновлять наборы валидаторов, переделегировать ставки и корректировать параметры без остановки цепочки.

Наборы валидаторов и PoS

Sui использует делегированную модель PoS, в которой валидаторы выбираются на основе размещенных токенов SUI:

• Выбор: валидаторы должны поставить минимальную сумму (например, 30 SUI, с возможностью корректировки) и привлечь делегацию от пользователей. Активный набор формируют N лучших валидаторов (например, 100) по общей сумме ставок.
• Консенсус: Sui использует византийский отказоустойчивый протокол (BFT) (Narwhal/Bullshark) для общих объектов, гарантирующий честные валидаторы в формате «2f+1» из 3f+1. Для простых транзакций используется параллельная обработка без полного консенсуса.
• Награды и слэши: валидаторы получают вознаграждение в виде комиссий за транзакции и перераспределения средств хранения, пропорциональное размеру ставки. Плохое поведение (например, двойное подписание) приводит к сокращению расходов, хотя особенности определяются правительством.
• Ротация: в конце эпохи изменения ставок запускает новый набор валидаторов: неактивные валидаторы закрываются, а новые появляются в зависимости от рейтинга ставок.

Это контрастирует с наборами статических валидаторов EVM в цепочках PoS, таких как Ethereum, где изменения происходят в результате хардфорков или обновлений.

Архитектурные концепции

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

Переместить структуру кода

Системные перемещения управляют переходами эпох, но разработчики могут работать с данными эпох. Пример:

переехать модуль my_module: :epoch_tracker { используйте sui: :epoch_time: :epochTime; используйте sui: :tx_context: :txContext;

в публичной структуре EpochData есть ключ, store { идентификатор: UID, текущая_эпоха: u64, }

публичная запись в формате update_epoch (данные: &mut epochData, эпоха: u64, ctx: &mut txContext) { data.current_epoch = эпоха; //Дополнительная логика, основанная на эпохе }

функция публичного входа create_epoch_tracker (ctx: &mut txContext) { пусть данные = EpochData { идентификатор: объект: :новый (ctx), текущая_эпоха: временная_эпоха: :текущая_эпоха (ctx), }; передача: :передача (данные, tx_context: :отправитель (ctx)); } }

• Ключевые моменты: используйте epoch_time: :current_epoch для доступа к текущей эпохе. Системные перемещения (например, sui_system: :request_add_validator) относятся только к сфере управления.
• Безопасность: проверяйте данные эпохи, чтобы предотвратить манипуляции во время повторного конфигурирования.

Использование интерфейса командной строки

Управляйте взаимодействиями валидаторов и данными эпох с помощью интерфейса командной строки Sui:

• Проверьте эпоху: бить sui клиент get-epoch-info

• Выходные данные: текущая эпоха, время начала, набор валидаторов.

• Stake SUI (в качестве делегата): бить ставка клиента --сумма 100 --валидатор --газ-бюджет 1000000

• Обратите внимание на: недостаточный баланс или неправильный адрес валидатора.

• Запросите добавление валидатора (только для управления, смоделировано в локальной сети): бить вызов клиента si --package --module sui_system --function request_add_validator --args --gas-budget 1000000

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

• Настройка локальной сети: бить валидатор sui-test --with-faucet

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

Лучшие практики и принципы безопасности

1. Логика, ориентированная на эпох: разрабатывайте контракты таким образом, чтобы обрабатывать паузы при повторном конфигурировании (например, повторные транзакции).
2. Мониторинг стейков: используйте интерфейс командной строки или SDK для отслеживания долей валидатора, обеспечивая делегирование полномочий надежным узлам.
3. Тестирование: смоделируйте переходы эпох в локальной сети с помощью sui-test-validator --epoch-duration-ms 10000 для тестирования поведения.

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

4. Безопасность: не полагайтесь на данные, относящиеся к конкретным эпохам, без проверки, поскольку повторные конфигурации могут изменить состояние.
5. Реалистичные условия: Тестируйте с различным распределением ставок в тестовой сети, чтобы имитировать изменения в наборе валидаторов.

Отличия от EVM и влияние на разработку

• Динамические валидаторы: EVM PoS (например, Ethereum) исправляет валидаторы до обновления, а ротация Sui, основанная на эпохах, обеспечивает адаптивность, что идеально подходит для пулов ликвидности DeFi, нуждающихся в частых корректировках.
• Параллелизм: параллелизм Sui на уровне объектов снижает временные издержки, в отличие от лимитов EVM, основанных на блокчейне, и позволяет майнингу NFT или пакетным операциям с кошельками.
• Разработка: ограничения Move на перенос системы требуют взаимодействия органов управления, в отличие от развертывания открытых контрактов EVM, что требует тщательного планирования функций, связанных с валидаторами.

Распространенные ошибки и их исправления

• Игнорирование переконфигурации: при условии, что непрерывная работа не работает во время переходов. Исправление: Реализуйте логику повторов.
• Неверная ставка: ставки ниже минимального уровня вызывают ошибки. Исправление: проверьте пороговые значения в get-epoch-info.
• Несоответствие сети: использование интерфейса командной строки основной сети в тестовой сети не работает. Исправление: согласование с целевой сетью (например, коммутатор sui client --env testnet).

Это относится к смарт-контрактам (эпохальная логика), NFT (майнинг, зависящий от валидатора), кошелькам (отслеживание ставок) и DeFi (динамические пулы ликвидности). Тщательно тестируйте в локальной сети/тестовой сети, чтобы обеспечить надежность в разных эпохах.

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

Теперь давайте поговорим о валидаторах. Sui использует делегированную систему Proof-of-Stake (PoS). Валидаторам необходимо поставить минимальное количество SUI (скажем, 30 токенов) и привлечь больше участников, чтобы войти в список N лучших валидаторов, определяющий, кто войдет в набор активных валидаторов той эпохи. Если ваш валидатор не попадет в топ, его выкинут при переходе в следующую эпоху. Таким образом, размер ставок и делегирование полномочий фактически автоматически определяют ротацию валидаторов. В отличие от Ethereum, где наборы валидаторов практически фиксированы, если не требуется модернизация сети или какие-либо предложения по управлению.

В Sui система Proof-of-Stake (PoS) основана на так называемых эпохах. Их можно рассматривать как временные окна, в которых набор валидаторов остается заблокированным для работы сети. Каждая эпоха по умолчанию длится около 24 часов, но ее можно настроить. Когда начинается эпоха, система устанавливает такие правила, как пороговые значения ставок и количество игроков в наборе валидаторов. По истечении срока действия система полностью завершает состояние и готовится к следующему.

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

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

Консенсус также работает по-другому. Sui использует Narwhal и Bullshark для транзакций с общими объектами, которые требуют координации. Но если ваше приложение работает с объектами, находящимися в собственности (например, с личными кошельками), оно не получает полного консенсуса и обрабатывает данные параллельно. Это кардинально меняет правила игры, потому что ваши транзакции не будут ждать несвязанных транзакций, как это происходит в Ethereum.

В коде Move вы можете сохранить текущую эпоху, используя epoch_time: :current_epoch (ctx). Например, если вы создаете модуль, реагирующий на изменения эпох, вы можете создать свой собственный объект для хранения и обновления значений эпох. Вот базовый эскиз того, как это выглядит:

module my_module::epoch_tracker {
    use sui::epoch_time;
    use sui::tx_context::{Self, TxContext};
    use sui::object;
    use sui::transfer;

    struct EpochData has key, store {
        id: UID,
        current_epoch: u64,
    }

    public entry fun create(ctx: &mut TxContext) {
        let epoch = epoch_time::current_epoch(ctx);
        let data = EpochData { id: object::new(ctx), current_epoch: epoch };
        transfer::transfer(data, tx_context::sender(ctx));
    }

    public entry fun update(data: &mut EpochData, epoch: u64, ctx: &mut TxContext) {
        data.current_epoch = epoch;
    }
}

В Sui Network эпохи и наборы валидаторов являются центральными компонентами делегированной модели консенсуса Proof-of-Stake (DPoS). Эпоха в Sui — это временной интервал фиксированной продолжительности (например, 24 часа), в течение которого определенный набор валидаторов отвечает за обработку транзакций и создание блоков. Каждая эпоха начинается с этапа реконфигурации, когда набор валидаторов может меняться в зависимости от ввода данных из предыдущей эпохи.

1. Эпохи и ротация валидаторов

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

Делегаты передают свои токены SUI валидаторам, влияя на то, кто присоединится к активному набору в следующую эпоху.

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

2. Структура набора валидаторов

Набор валидаторов хранится в объекте Move, обслуживаемом системным модулем 0x3: :sui_system.

Каждый валидатор имеет метаданные, включая открытый ключ, сумму ставки, комиссию и сетевой адрес.

Валидатор структуры { метаданные: метаданные валидатора, сила голосования: до 64 лет, цена газа: 64 долл. США, ставка комиссии: 64 долл. США, ... }

3. Ставки и делегирование

Стейкеры взаимодействуют с системным модулем Sui через интерфейс командной строки или SDK для делегирования своих долей:

ставка клиента — сумма 1000000000 — валидатор <VALIDATOR_ADDRESS>

Токены, поставленные на карту, заблокированы и влияют на общую сумму ставки валидатора в следующую эпоху.

Награды распределяются по эпохам и могут быть получены с помощью метода withdraw_rewards.

4. Взаимодействие с перемещением

Функция sui_system: :request_epoch_change вызывается автоматически для ротации валидаторов.

Смарт-контракты напрямую не контролируют эпохи, но с помощью модуля sui_system могут обращаться к информации валидатора в целях управления или логики стейкинга.

5. Использование CLI/SDK

Чтобы запросить текущую эпоху и валидаторы, выполните следующие действия:

вызовите клиент sui --package 0x3 --модуль sui_system --function get_current_epoch вызов клиента sui --пакет 0x3 --модуль sui_system --функция get_validator_set

Из пакета SDK:

const EpochInfo = await provider.getLatestsUI SystemState (); console.log (эпоха, эпоха, эпоха. Активные валидаторы);

6. Возможность управления в сети

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

7. Распространенные подводные камни

Использование устаревших адресов валидаторов может привести к сбою стекинга.

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

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

8. Тестирование и лучшие практики

В localnet вы можете смоделировать переходы эпох, вызвав:

генезис суицида --эпоха-длительность-мс 10000

Реконфигурации мониторов с помощью события EpochchangeEvent.

9. Безопасность

Убедитесь, что метаданные валидатора проверены (например, валидатор sybil не установлен).

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

10. Дизайн и еда на вынос

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

Сообщите мне, нужен ли вам шаблон контракта Move, который считывает данные эпох или проверяет условия, основанные на ставках.

В Суе время разделено на части, называемые эпохами. Каждая эпоха похожа на сеанс, который по умолчанию длится около 24 часов (это можно изменить). В течение целой эпохи валидаторы обрабатывают транзакции, получают вознаграждения и поддерживают сеть. Когда эпоха заканчивается, система дорабатывает все и переходит к следующей. Этот переход включает в себя небольшую паузу, называемую временем перенастройки, которая дает сети возможность безопасно обновить свое внутреннее состояние — как будто глубоко вздохнуть перед началом следующего раунда.

Эти эпохи очень важны, потому что именно в эти периоды наборы валидаторов могут меняться. В Sui используется делегированная модель PoS, поэтому валидаторы выбираются в зависимости от того, сколько SUI они ставят на карту и сколько им делегируют другие. Чтобы стать валидатором, вам необходимо уложиться в минимальную ставку (например, 30 SUI), а чтобы оставаться в числе лучших валидаторов, необходимо привлечь достаточное количество делегированных долей. В конце каждой эпохи система проверяет эти рейтинги и автоматически корректирует набор валидаторов — никаких хардфорков или ручных обновлений не требуется.

Для достижения консенсуса компания Sui использует протоколы Narwhal и Bullshark для сложных транзакций или транзакций с общим состоянием. Он обеспечивает безопасность даже в случае плохого поведения нескольких валидаторов. Но если речь идет о простых транзакциях, не связанных с общими объектами, Sui не принимает жестких решений и выполняет их параллельно, тем самым ускоряя процесс.

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

Под капотом система отслеживает информацию об эпохе в специальном объекте в блокчейне. В этом объекте хранятся такие сведения, как текущий номер эпохи, когда она началась и какие валидаторы активны. Разработчики не контролируют это напрямую, но вы можете прочитать текущую эпоху в смарт-контрактах Move, используя epoch_time: :current_epoch (ctx).

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

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

Для взаимодействия с эпохами и валидаторами можно использовать интерфейс командной строки Sui. Вы можете проверить текущую эпоху, передать свой SUI валидатору или даже смоделировать поведение валидатора в локальной сети. Если вы запускаете тестовую сеть локально, вы можете сократить продолжительность эпохи (например, до 10 секунд), чтобы увидеть, как ваше приложение ведет себя во время переходов.

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

По сравнению с Ethereum, где до обновления в основном используется фиксированный набор валидаторов, набор валидаторов Sui динамичен и обновляется каждый день. Такая гибкость очень важна, особенно для таких случаев использования, как пулы DeFi, где может потребоваться частая смена делегирования полномочий, но она также означает, что логику нужно строить на основе системы, которая постоянно находится в движении.

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

Но поскольку Sui ограничивает доступ к некоторым системным функциям, в отличие от стиля EVM «развертывайте что угодно и когда угодно», вам придется заранее планировать, зависят ли ваши функции от валидаторов или эпох.

В Sui эпохи и наборы валидаторов являются фундаментальными компонентами модели консенсуса с делегированным подтверждением ставки (DPoS). Эпоха — это фиксированный период, в течение которого определенный набор валидаторов отвечает за проверку транзакций и защиту сети. В конце каждой эпохи может быть сформирован новый набор валидаторов на основе деятельности по размещению ставок и управленческих решений. Валидаторы выбираются в соответствии с количеством поставленных на них токенов SUI, а делегаты могут использовать свои SUI для участия в обеспечении безопасности сети и получении вознаграждений. Право голоса каждого валидатора пропорционально общей сумме поставленной ему суммы, что напрямую влияет на консенсус.

Механизм контрольных точек Sui помогает завершать транзакции между валидаторами и обеспечивает детерминированный прогресс состояний. Изменения в валидаторах, ставках и параметрах протокола вступают в силу только в начале новой эпохи. Логика перехода к этой эпохе закодирована в системных модулях Sui Move и видна в пакете sui-system. Разработчики могут просматривать метаданные эпохи через интерфейс командной строки Sui, используя такие команды, как вызов клиента sui --function get_current_epoch.

В отличие от цепочек EVM, изменения в наборах валидаторов в Sui тесно связаны с объектно-ориентированной моделью и строгими правилами доступа Move, что позволяет поддерживать согласованность и безопасность при переходах. Чтобы избежать проблем с развертыванием, разработчикам следует составлять контракты с тщательным использованием информации о динамических валидаторах, особенно в таких приложениях, как управление, создание информационных панелей или межэпохальные рабочие процессы.