Muitas pessoas veem os protocolos de alavancagem como uma mera otimização técnica — maior velocidade de execução, algoritmos de liquidação mais inteligentes. Mas isso está longe de ser a imagem completa.
A verdadeira disputa ocorre em outro nível: quando a tomada de decisão de risco passa de ser humana para ser do protocolo, o que acontece com a responsabilidade?
Imagine um cenário. Nos negócios tradicionais de alavancagem, uma liquidação forçada é uma decisão errada do trader. É uma questão de julgamento humano. Mas assim que a lógica de gestão de risco fica congelada no código do protocolo, a falha se torna um resultado do sistema. E o que o sistema produz é avaliado de forma muito mais rigorosa.
Ninguém pode culpar um algoritmo por uma "falha de julgamento". Você só pode perguntar: por que o design do sistema permite que esse resultado aconteça? Essa é uma questão de limites do design.
Por isso, muitos protocolos DeFi atualmente estão sendo cautelosos ao pensar em mecanismos de liquidação, parâmetros de gestão de risco e hipóteses de liquidez. Porque, se algo der errado, não é uma falha de alguém, mas toda a mecânica que revela suas deficiências de design.
Portanto, a questão não é se a tecnologia pode ser mais inteligente. A questão é: quando o sistema assume a responsabilidade pela tomada de risco, qual o padrão de confiabilidade que ele precisa atingir? Essa é uma questão mais profunda.
Ver original
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
14 Curtidas
Recompensa
14
4
Repostar
Compartilhar
Comentário
0/400
DaoResearcher
· 12-24 18:50
É por isso que tenho sempre dito que os ajustes de parâmetros na governança da Aave são feitos com muita cautela, não por conservadorismo, mas por usar dados on-chain para verificar repetidamente as condições de limite. É importante notar que, na proposta de governança do Compound em 2020, cada relaxamento nos parâmetros de risco desencadeava debates acirrados na comunidade — exatamente porque, uma vez que o código está definido, ninguém consegue mudar a ganância das pessoas.
Ver originalResponder0
GweiWatcher
· 12-24 18:49
Em resumo, é uma questão de transferir a culpa, não é? O código está fixo e não dá para passar a responsabilidade para alguém.
Ver originalResponder0
gas_fee_trauma
· 12-24 18:49
Muito bem dito, a responsabilidade é realmente o ponto fraco do DeFi
Ver originalResponder0
unrekt.eth
· 12-24 18:46
Bem dito, isto é o ponto. Muitas pessoas ainda estão a discutir sobre taxas de gás e TPS, sem perceberem qual é o verdadeiro problema do DeFi
Muitas pessoas veem os protocolos de alavancagem como uma mera otimização técnica — maior velocidade de execução, algoritmos de liquidação mais inteligentes. Mas isso está longe de ser a imagem completa.
A verdadeira disputa ocorre em outro nível: quando a tomada de decisão de risco passa de ser humana para ser do protocolo, o que acontece com a responsabilidade?
Imagine um cenário. Nos negócios tradicionais de alavancagem, uma liquidação forçada é uma decisão errada do trader. É uma questão de julgamento humano. Mas assim que a lógica de gestão de risco fica congelada no código do protocolo, a falha se torna um resultado do sistema. E o que o sistema produz é avaliado de forma muito mais rigorosa.
Ninguém pode culpar um algoritmo por uma "falha de julgamento". Você só pode perguntar: por que o design do sistema permite que esse resultado aconteça? Essa é uma questão de limites do design.
Por isso, muitos protocolos DeFi atualmente estão sendo cautelosos ao pensar em mecanismos de liquidação, parâmetros de gestão de risco e hipóteses de liquidez. Porque, se algo der errado, não é uma falha de alguém, mas toda a mecânica que revela suas deficiências de design.
Portanto, a questão não é se a tecnologia pode ser mais inteligente. A questão é: quando o sistema assume a responsabilidade pela tomada de risco, qual o padrão de confiabilidade que ele precisa atingir? Essa é uma questão mais profunda.