Если вы хотите построить продукт ликвидного стейкинга на @Dusk , первое, что вы узнаете: очевидный подход не работает.
С пользователя, который стейкит из кошелька, вызывается stake. Контракт так вызвать не может. stake_from_contract отказывается вызываться напрямую — он проверяет, что его достигли как часть передачи средств. Поэтому схема такая: сначала переместите средства в ваш контракт, затем выполните контракт-к-контракту перевод в контракт стейкинга, указав функцию, которую вы хотите вызвать, прямо в рамках этой передачи.
Деньги и инструкция идут вместе — или ничего не произойдёт.
Это осознанное дизайнерское решение, и мне оно нравится. Оно устраняет целый класс багов, когда контракт «утверждает», что застейкал значение, которое он на самом деле никогда не переводил. Передача и есть авторизация.
Вторая половина — та часть, которую энтузиасты сборки недооценивают. Ваш контракт должен реализовать коллбэки — один для получения разстейкнутых средств, и один для получения наград. Dusk не «вкладывает» вам значение и не надеется, что вы всё обработаете. Он возвращает его через функцию, которую вы были обязаны написать. Забудьте одну — и вы соберёте пул, который может принимать депозиты, но не сможет возвращать их.
Две оговорки, которые стоит знать перед стартом: минимальное условие 1,000 $DUSK действует для контрактов так же, как и для людей, а стейкинг становится активным после периода зрелости.
Небольшая честная ремарка: при зрелости документация даёт мне два разных описания в двух местах — на одной странице сказано 4,320 блоков, что примерно равно 12 часам; другая описывает активацию на границе эпохи. Оба варианта могут говорить об одном и том же с разных ракурсов. Если вы строите вокруг этого, подтвердите на testnet, а не доверяйте ни одной из страниц.
Прямо сейчас на странице экосистемы перечислен ровно один стейкинг-пул, построенный именно таким способом.
Разработчики — заставляет ли принудительно объединять значение и инструкцию в один атомарный шаг сделать вашу жизнь безопаснее, или просто медленнее?

#dusk