Se você quiser construir um produto de liquid staking no @Dusk , a primeira coisa que você aprende é que a abordagem óbvia não funciona.
Um usuário fazendo staking a partir de uma carteira chama stake. Um contrato não pode. stake_from_contract não permite ser invocado diretamente — ele valida que foi acessado como parte de uma transferência de fundos. Então o padrão é: mova os fundos para o seu contrato e, depois, execute uma transferência de contrato para contrato para o contrato de staking, informando qual função você quer como parte da própria transferência.
Dinheiro e instrução viajam juntos, ou nada acontece.
Essa é uma escolha de design deliberada e eu passei a gostar dela. Ela elimina uma classe inteira de bugs em que um contrato afirma que fez staking de um valor que, na prática, nunca foi movimentado. A transferência é a autorização.
A segunda metade é a parte que os construtores subestimam. Seu contrato precisa implementar callbacks — uma para receber fundos não apostados (unstaked) e outra para receber recompensas. A Dusk não entrega valor para você e torce para que dê certo. Ela devolve isso por meio de uma função que você foi obrigado a escrever. Se você esquecer uma, você constrói um pool que pode aceitar depósitos e não consegue devolvê-los.
Duas restrições valem a pena saber antes de começar: o 1,000 $DUSK minimum se aplica a contratos exatamente como se aplica a pessoas, e o stake se torna ativo após um período de maturidade.
Um pequeno aviso de honestidade: na maturidade, a documentação me dá duas molduras diferentes em dois lugares — uma página diz 4,320 blocos, aproximadamente 12 horas; outra descreve a ativação no limite de um epoch. Ambas podem estar descrevendo a mesma coisa por ângulos diferentes. Se você estiver construindo em cima disso, confirme na testnet em vez de confiar em qualquer uma das páginas.
Neste momento, a página do ecossistema lista exatamente um pool de staking construído dessa forma.
Contribuidores — forçar valor e instrução em uma única movimentação atômica deixa sua vida mais segura, ou apenas mais lenta?
#dusk
Um usuário fazendo staking a partir de uma carteira chama stake. Um contrato não pode. stake_from_contract não permite ser invocado diretamente — ele valida que foi acessado como parte de uma transferência de fundos. Então o padrão é: mova os fundos para o seu contrato e, depois, execute uma transferência de contrato para contrato para o contrato de staking, informando qual função você quer como parte da própria transferência.
Dinheiro e instrução viajam juntos, ou nada acontece.
Essa é uma escolha de design deliberada e eu passei a gostar dela. Ela elimina uma classe inteira de bugs em que um contrato afirma que fez staking de um valor que, na prática, nunca foi movimentado. A transferência é a autorização.
A segunda metade é a parte que os construtores subestimam. Seu contrato precisa implementar callbacks — uma para receber fundos não apostados (unstaked) e outra para receber recompensas. A Dusk não entrega valor para você e torce para que dê certo. Ela devolve isso por meio de uma função que você foi obrigado a escrever. Se você esquecer uma, você constrói um pool que pode aceitar depósitos e não consegue devolvê-los.
Duas restrições valem a pena saber antes de começar: o 1,000 $DUSK minimum se aplica a contratos exatamente como se aplica a pessoas, e o stake se torna ativo após um período de maturidade.
Um pequeno aviso de honestidade: na maturidade, a documentação me dá duas molduras diferentes em dois lugares — uma página diz 4,320 blocos, aproximadamente 12 horas; outra descreve a ativação no limite de um epoch. Ambas podem estar descrevendo a mesma coisa por ângulos diferentes. Se você estiver construindo em cima disso, confirme na testnet em vez de confiar em qualquer uma das páginas.
Neste momento, a página do ecossistema lista exatamente um pool de staking construído dessa forma.
Contribuidores — forçar valor e instrução em uma única movimentação atômica deixa sua vida mais segura, ou apenas mais lenta?
#dusk