Eu assumi que fazer staking em uma blockchain PoS significava que uma chave controla uma coisa: coloca DUSK, recebe recompensas, e a mesma chave cuida do processo inteiro, de ponta a ponta.
A documentação oficial do Dusk divide isso em duas.
A chave de consenso é a chave que um nó usa para assinar e votar no consenso. Ela precisa ficar em um nó conectado à internet e participar enquanto o validador opera. A chave do proprietário é separada: é a chave que pode remover o stake (unstake) ou sacar fundos, e a documentação diz que ela não precisa nem tocar o nó.
O benefício de segurança não é apenas haver duas chaves. A vantagem é que a autoridade para participar do consenso e a autoridade para sacar fundos não precisam estar no mesmo lugar. Se a chave de consenso for comprometida porque o servidor em que ela está for violado, um atacante pode interferir na participação no consenso, mas ainda assim não consegue retirar o stake nem sacar os fundos. Essa autoridade nunca morou na máquina que está exposta à internet. Em outras palavras, a verdadeira questão de segurança não é só quanto é stakeado. É onde exatamente a autoridade para retirá-lo fica em relação à máquina que está exposta a atacantes.
Mas há uma pegadinha que a documentação não esconde: essa separação não é o padrão. Se você fizer staking sem especificar um proprietário separado, a chave de consenso automaticamente vira também a chave do proprietário—uma chave, um limite, voltando ao modelo que eu originalmente assumi. A configuração mais segura é uma escolha que o operador precisa fazer ativamente, não algo que o protocolo força.
"Um limite de segurança que precisa ser ativado é uma garantia diferente daquela embutida no caminho padrão, mesmo quando ambos estão tecnicamente disponíveis."
O que eu realmente gostaria de saber: quantos provedores ativos rodam com uma chave de proprietário separada versus a opção padrão, porque isso me diria se o limite mais forte está de fato sendo adotado, e não apenas disponibilizado.
#dusk $DUSK @Dusk
A documentação oficial do Dusk divide isso em duas.
A chave de consenso é a chave que um nó usa para assinar e votar no consenso. Ela precisa ficar em um nó conectado à internet e participar enquanto o validador opera. A chave do proprietário é separada: é a chave que pode remover o stake (unstake) ou sacar fundos, e a documentação diz que ela não precisa nem tocar o nó.
O benefício de segurança não é apenas haver duas chaves. A vantagem é que a autoridade para participar do consenso e a autoridade para sacar fundos não precisam estar no mesmo lugar. Se a chave de consenso for comprometida porque o servidor em que ela está for violado, um atacante pode interferir na participação no consenso, mas ainda assim não consegue retirar o stake nem sacar os fundos. Essa autoridade nunca morou na máquina que está exposta à internet. Em outras palavras, a verdadeira questão de segurança não é só quanto é stakeado. É onde exatamente a autoridade para retirá-lo fica em relação à máquina que está exposta a atacantes.
Mas há uma pegadinha que a documentação não esconde: essa separação não é o padrão. Se você fizer staking sem especificar um proprietário separado, a chave de consenso automaticamente vira também a chave do proprietário—uma chave, um limite, voltando ao modelo que eu originalmente assumi. A configuração mais segura é uma escolha que o operador precisa fazer ativamente, não algo que o protocolo força.
"Um limite de segurança que precisa ser ativado é uma garantia diferente daquela embutida no caminho padrão, mesmo quando ambos estão tecnicamente disponíveis."
O que eu realmente gostaria de saber: quantos provedores ativos rodam com uma chave de proprietário separada versus a opção padrão, porque isso me diria se o limite mais forte está de fato sendo adotado, e não apenas disponibilizado.
#dusk $DUSK @Dusk
