Esta é a continuação do fio condutor inicial sobre a governação dupla 18. O tópico vinculado contém um contexto importante, portanto, leia-o se tiver tempo.

Desde que a última versão do design do mecanismo foi proposta neste post 5, os contribuidores do protocolo que trabalham no DG fizeram diversas iterações para incorporar o feedback recebido e tornar o mecanismo mais simples, menos frágil e mais eficiente.

Antes de apresentar a versão atualizada, deixe-me descrever o problema que estamos tentando resolver e traçar brevemente a cadeia de raciocínio que nos levou à solução proposta.

O problema

Atualmente, o código do protocolo Lido e seus parâmetros são controlados pelo Lido DAO por meio de votação de token LDO. O protocolo cobra uma taxa de 5% das recompensas de staking e a direciona para o tesouro DAO (outros 5% são distribuídos aos operadores de nós participantes do protocolo).

Embora os detentores de LDO devam geralmente ser motivados a manter o bem-estar do protocolo, uma vez que isso se reflete no preço do token LDO, isso não significa necessariamente que os detentores de LDO representem eficientemente os usuários do protocolo. Por exemplo, imagine que os titulares de LDO decidam coletivamente aumentar as taxas de protocolo: embora isto possa ter um efeito positivo no bem-estar imediato dos titulares de LDO, é claramente contra os interesses de pelo menos uma parte dos utilizadores do protocolo.

Isto pode ser generalizado como um problema de agente principal (PAP) entre o DAO (o agente) e os usuários do protocolo (o principal). O problema existe porque os titulares de LDO não têm exatamente os mesmos incentivos que os usuários.

Além disso, como destaca Vitalik no seu ensaio Moving Beyond Coin Voting 9 , o PAP é exacerbado pelo facto de o interesse económico nas receitas do protocolo poder ser desagregado do poder de governação: poder-se-ia distorcer os incentivos dos detentores de tokens DAO subornando-os ou pegue emprestado o token de votação do DAO no mercado aberto para tentar obter poder de voto suficiente para promover uma mudança que vai contra os interesses do DAO e dos usuários do protocolo.

A presença do PAP não é grande mas pode-se argumentar que, se os utilizadores perceberem que o agente actual não os representa suficientemente bem, podem sempre sair do protocolo e escolher outro agente que esteja mais alinhado com os seus interesses ou mesmo decidir remover o agente completamente por meio de piquetagem solo.

Este é um mecanismo muito importante, geralmente conhecido como voto a pé. Em teoria, deveria proteger os usuários dos efeitos negativos de qualquer desalinhamento de incentivos entre eles e o DAO ou qualquer ataque ao DAO. No entanto, na prática e no caso específico do staking líquido Ethereum, a eficiência do voto a pé é limitada devido a uma série de fatores em jogo.

O primeiro fator são as especificidades de como funciona o Ethereum PoS. Para retirar o ETH de um validador, é preciso esperar até que o validador seja totalmente encerrado e todas as saídas do validador Ethereum sejam processadas por meio de uma única fila com rendimento limitado. Isso significa que o tempo necessário para sair do protocolo depende de fatores externos fora do protocolo e pode variar em ordens de grandeza. Isto, por sua vez, implica que a imposição de um timelock estático nas decisões do DAO não pode garantir que qualquer usuário tenha tempo suficiente para deixar o protocolo antes que o DAO aplique uma alteração que não seja do interesse do usuário.

O segundo fator é que uma parcela significativa dos usuários escolhe o staking líquido porque deseja redistribuir o capital apostado para outras formas de atividades econômicas, resultando em tokens de staking líquidos (LSTs) sendo amplamente utilizados no DeFi, incluindo os protocolos que exigem tempo adicional para se retirar (por exemplo mercados de empréstimos). Isso adiciona mais uma dependência externa que pode impedir que os usuários saiam do protocolo dentro de um prazo pré-definido.

O terceiro factor decorre da assimetria de informação entre a maioria passiva e a minoria activa e educada dos utilizadores: avaliar correctamente todos os riscos associados a uma determinada decisão de governação, incluindo os riscos de cauda, requer o conhecimento que a maioria dos utilizadores não possui. A comunicação dos potenciais efeitos adversos de uma decisão DAO através da camada social leva mais tempo, reduzindo a probabilidade de a maioria passiva deixar o protocolo antes que a decisão se torne executável.

Lido DAO estabeleceu uma série de protocolos de governança para reduzir a assimetria de informação (por exemplo, a estrutura GOOSE, o Grupo de Subgovernança de Operadores de Nó, a estrutura LIP, o compromisso para o número mínimo de auditorias de qualquer mudança de código da rede principal), mas todos eles são acordos da camada social entre os atuais titulares de LDO e, portanto, não podem proteger de um ataque externo ao DAO.

Em direção à solução

A solução definitiva para o problema é a minimização da governança e eventual ossificação do código e dos parâmetros do protocolo. Não há risco de governação se nada estiver a ser governado.

Minimizar gradualmente o âmbito da governação é algo que os contribuidores do protocolo veem como uma necessidade nos próximos anos. No entanto, até que a especificação Ethereum se ossifique, a capacidade de atualização do código só pode ser reduzida até certo ponto (por exemplo, consulte EIP-7002 5, EIP-7251 6). Além disso, qualquer código imutável deve ser verificado formalmente no nível do bytecode para excluir a possibilidade de um bug do compilador produzir uma vulnerabilidade não corrigível.

Há também a camada de fungibilidade do protocolo que serve como mecanismo de avaliação de risco/recompensa e distribui ETH entre diferentes subconjuntos de validadores de uma forma que equilibra o rendimento e os riscos do conjunto de validadores resultante. Os riscos aqui incluem os riscos finais que o conjunto de validadores cria para a rede Ethereum, por exemplo censura e riscos de corte correlacionados. Há pesquisas em andamento (veja este relatório 6 para a iteração mais recente) sobre se esses riscos podem ser estimados pelo protocolo com a ajuda de um dispositivo oráculo confiável que traz as informações necessárias para a cadeia, mas é um esforço de longo prazo e ainda não está claro como o o resultado desejado pode ser alcançado na prática. Até que o protocolo tenha implementado esse mecanismo sem confiança, deve haver alguma governança na camada de fungibilidade.

Mais uma área potencial de pesquisa é procurar maneiras de introduzir uma aceitação explícita para novas versões de código e conjunto de parâmetros para detentores e integrações de stETH. Ainda não está claro se isso pode ser feito sem quebrar a fungibilidade do LST e a fragmentação de liquidez resultante que, dado que a liquidez é um dos principais factores que levam os utilizadores aos LST, destruiria a competitividade do protocolo contra outros fornecedores de staking de líquidos descentralizados e centralizados. No entanto, é uma direção de pesquisa interessante.

Agora que estabelecemos que o protocolo terá que conviver com algum tipo de governança pelo menos no médio prazo, vamos ver como podemos minimizar <a href="https://notes.ethereum.org/@mikeneuder/magnitude -e-direção">o riscos que esta governação cria 1 .

Governança dupla

Conforme destacado na primeira secção, o problema geral pode ser decomposto em 1) a presença do PAP e 2) a eficiência limitada do voto a pé. Então, idealmente, gostaríamos de introduzir algum mecanismo que melhore tanto o alinhamento entre o DAO e os usuários do protocolo quanto a eficiência da votação a pé.

É aí que chegamos ao projeto proposto de governança dupla. Visa as seguintes melhorias:

1. Dê aos stakeholders uma forma de sinalizar de forma credível o seu desacordo com o DAO e o compromisso de abandonar o protocolo se o DAO não cooperar na resolução do conflito de incentivos.
2. Fornece um dispositivo de negociação entre os stakers e o DAO.
3. Introduzir um timelock dinâmico estendido nas decisões DAO que pode ser acionado por uma minoria ativa de stakers e prolongado à medida que mais stakers participam.
4. Melhore a eficiência da votação a pé, permitindo que os stakers saiam do protocolo sem estarem sujeitos a decisões DAO novas e pendentes.

Uma visão geral do design do mecanismo proposto e algumas ideias para pesquisas futuras sobre minimização de riscos de governança podem ser encontradas nesta nota: <a href="https://hackmd.io/ @skozin /r17mlW2la"">https://hackmd. io/@skozin/r17mlW2la 37.

Deve-se notar que os stakers não são a única categoria de usuários do protocolo; também existem operadores de nó. Uma possível direção de pesquisa futura é procurar maneiras de melhorar também a eficiência do voto a pé pelos operadores de nós, por exemplo permitindo que um subconjunto de stakers e operadores de nós coordenem um protocolo e uma bifurcação DAO, redirecionando as credenciais de retirada do validador para um novo contrato (atualmente não suportado pela camada de consenso).

Outra direção de pesquisas futuras é explorar a governança não-token e híbrida 2.

Próximos passos

A partir daqui, várias coisas precisam acontecer antes que o projeto seja finalizado, resultando em uma Proposta de Melhoria do Lido (LIP) mais formal que será submetida à votação do DAO e ao documento associado de Registro de Decisão de Arquitetura (ADR):

1. Avaliar a robustez do mecanismo proposto por meio de modelagem de cenários e ataques.
2. Avaliar a praticidade do mecanismo por meio da prototipagem do código.
3. Coletando o feedback da comunidade.

Este tópico tem como objetivo realizar 3 enquanto os contribuidores do protocolo trabalham em 1 e 2 (ambos em andamento), portanto, qualquer feedback será muito apreciado!

É importante realçar que, embora a governação dupla seja (na minha opinião) um passo importante na redução dos riscos de governação do protocolo, não é de forma alguma o passo final. Algumas das ideias para melhorias adicionais podem ser encontradas no documento de design do mecanismo vinculado acima, e convido todos os interessados a discutir essas e quaisquer outras melhorias potenciais postando um tópico neste fórum.

Isenção de responsabilidade:

1. Este artigo foi reimpresso de [lido]. Todos os direitos autorais pertencem ao autor original [skozin]. Se houver objeções a esta reimpressão, entre em contato com a equipe do Gate Learn e eles cuidarão disso imediatamente.
2. Isenção de responsabilidade: As opiniões e pontos de vista expressos neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.