Существует версия стейкинга, где стейкинг выполняете не вы.
Я часто думал, что стейкинг — это то, что может делать только кошелёк. подключение, делегирование, ожидание. вот такая схема везде, где я раньше это использовал.
Но когда я читал раздел про абстракцию стейкинга @Dusk stake, я решил, что это просто делегирование, только с новым названием. мне понадобилось пару прочтений документации, прежде чем я понял, что это не так.
Оказалось, всё сводится к тому, как Dusk обращается с контрактами — они могут хранить и управлять состоянием, как это делает кошелёк, а не просто выполнять логику. Так что стейкинг может делать контракт, а не только кошелёк.
Вот последовательность. контракт не вызывает функцию стейкинга напрямую. средства сначала попадают в контракт, затем он делает перевод контракт-к-контракту в стейкинг-контракт. анстейкинг и награды работают обратно через callbacks. минимум всё так же 1,000 DUSK, и действуют те же правила активации, что и в обычном режиме.
То, что здесь называется «абстракцией», не означает меньшую сложность — оно просто меняет того, кто всё это делает. стейкинг из кошелька прост, потому что решение принимает человек. стейкинг из контракта означает, что коду нужно самому принимать каждое решение правильно. один неверный callback — и награды могут зависнуть.
При этом я всё ещё не уверен, где проходит граница, когда что-то ломается. контракт владеет рабочим процессом, но протокол всё равно владеет правом участвовать в консенсусе. так что если пулованный стейкинг-контракт ошибается — это баг контракта или риск протокола? ответа пока не нашёл.
@Dusk_Foundation $DUSK #dusk
Я часто думал, что стейкинг — это то, что может делать только кошелёк. подключение, делегирование, ожидание. вот такая схема везде, где я раньше это использовал.
Но когда я читал раздел про абстракцию стейкинга @Dusk stake, я решил, что это просто делегирование, только с новым названием. мне понадобилось пару прочтений документации, прежде чем я понял, что это не так.
Оказалось, всё сводится к тому, как Dusk обращается с контрактами — они могут хранить и управлять состоянием, как это делает кошелёк, а не просто выполнять логику. Так что стейкинг может делать контракт, а не только кошелёк.
Вот последовательность. контракт не вызывает функцию стейкинга напрямую. средства сначала попадают в контракт, затем он делает перевод контракт-к-контракту в стейкинг-контракт. анстейкинг и награды работают обратно через callbacks. минимум всё так же 1,000 DUSK, и действуют те же правила активации, что и в обычном режиме.
То, что здесь называется «абстракцией», не означает меньшую сложность — оно просто меняет того, кто всё это делает. стейкинг из кошелька прост, потому что решение принимает человек. стейкинг из контракта означает, что коду нужно самому принимать каждое решение правильно. один неверный callback — и награды могут зависнуть.
При этом я всё ещё не уверен, где проходит граница, когда что-то ломается. контракт владеет рабочим процессом, но протокол всё равно владеет правом участвовать в консенсусе. так что если пулованный стейкинг-контракт ошибается — это баг контракта или риск протокола? ответа пока не нашёл.
@Dusk_Foundation $DUSK #dusk