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

Desde que a última versão de design do mecanismo foi proposta neste post 5, os contribuintes do protocolo que trabalham na DG fizeram várias 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 a tentar resolver e traçar brevemente a cadeia de raciocínio que nos levou à solução que está a ser proposta.

O problema

Atualmente, o código do protocolo Lido e os seus parâmetros são controlados pelo Lido DAO através da votação do token LDO. O protocolo recebe uma taxa de 5% das recompensas de staking e direciona-a para o tesouro do DAO (outros 5% sendo distribuídos aos operadores de nós que participam no protocolo).

Embora os detentores de LDO devam geralmente estar motivados a manter o bem-estar do protocolo, uma vez que se reflete no preço do token LDO, não significa necessariamente que os titulares de LDO representam eficientemente os utilizadores do protocolo. Por exemplo, imagine que os titulares de LDO decidam coletivamente aumentar as taxas do protocolo: embora isso 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 utilizadores do protocolo (o principal). O problema existe porque os titulares de LDO não têm exatamente os mesmos incentivos que os utilizadores.

Além disso, como Vitalik destaca no seu ensaio Moving beyond coin vote 9, o PAP é exacerbado pelo facto de que o interesse económico na receita do protocolo pode ser separado do poder de governação: pode-se distorcer os incentivos dos detentores do token DAO subornando-os ou pedir emprestado o token de votação DAO no mercado aberto para tentar obter poder de voto suficiente para promover uma mudança que é contra os interesses de ambos os DAO O e os utilizadores do protocolo.

A presença do PAP não é grande mas pode-se argumentar que, se os utilizadores perceberem que o agente atual não os representa bem o suficiente, podem sempre deixar o protocolo e escolher outro agente que esteja melhor alinhado com os seus interesses ou mesmo decidir remover o agente completamente através do sollo-staking.

Este é um mecanismo muito importante geralmente conhecido como votação a pé. Em teoria, deveria proteger os utilizadores dos efeitos negativos de qualquer desalinhamento de incentivo entre eles e o DAO ou qualquer ataque ao DAO. No entanto, na prática e no caso específico do Ethereum liquid staking, 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 saído e todas as saídas do validador Ethereum sejam processadas através de uma única fila com rendimento limitado. Isto significa que o tempo necessário para deixar o protocolo depende de fatores externos fora do protocolo e pode variar em ordens de magnitude. Isso, por sua vez, implica que a imposição de um timellock estático às decisões do DAO não pode garantir que qualquer utilizador tenha tempo suficiente para deixar o protocolo antes que o DAO aplique uma alteração que não é do interesse do utilizador.

O segundo fator é que uma parcela significativa dos utilizadores escolhe o liquid staking porque querem reimplantar o capital em risco para outras formas de atividades económicas, resultando em tokens de staking líquidos (LSTs) a serem amplamente utilizados no DeFi, incluindo os protocolos que exigem tempo adicional para se retirarem (por exemplo mercados de crédito). Isto adiciona mais uma dependência externa que pode impedir os utilizadores de deixarem o protocolo dentro de um prazo pré-definido.

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

O Lido DAO estabeleceu uma série de protocolos de governação para reduzir a assimetria de informação (por exemplo, a estrutura GOOSE, o Node Operators Sub-Governance Group, a estrutura LIP, o compromisso para o número mínimo de auditorias de qualquer alteração de código da rede principal) mas são todos acordos de camada social entre os atuais detentores de LDO e, portanto, não podem proteger de um ataque externo ao DAO.

Rumo à solução

A solução definitiva para o problema é a minimização da governação 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 contribuintes do protocolo veem como uma necessidade nos próximos anos. No entanto, até que a especificação Ethereum se ossifique, a capacidade de actualização do código só pode ser reduzida até certo ponto (ex. ver EIP-7002 5, EIP-7251 6). Além disso, qualquer código imutável tem de ser formalmente verificado no nível do bytecode para excluir a possibilidade de um bug do compilador produzir uma vulnerabilidade não corrijável.

Há também a camada de fungibilidade do protocolo que serve como motor 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 de cauda 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 oracle confiável trazendo as informações necessárias na cadeia mas é um esforço de longo prazo e ainda não está claro como o resultado desejado pode ser praticamente realizado. Até que o protocolo tenha implementado um mecanismo tão fidedigno, tem de haver alguma governação na camada de fungibilidade.

Mais uma área potencial de investigação é procurar formas de introduzir um opt-in explícito para novas versões de código e de conjunto de parâmetros para titulares e integrações STETH. Ainda não está claro se isso pode ser feito sem quebrar a fungibilidade do LST e a consequente fragmentação da liquidez que, dado que a liquidez é um dos principais fatores que levam os utilizadores aos LSTs, destruiria a competitividade do protocolo em relação a outros fornecedores de liquidez descentralizados e centralizados de liquidez. No entanto, é uma direção de pesquisa interessante.

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

Dupla governação

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

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

1. Dê aos apostadores uma maneira de sinalizar com credibilidade o seu desacordo com o DAO e o compromisso de deixar o protocolo se o DAO não cooperar na resolução do conflito de incentivos.
2. Fornecer um dispositivo de negociação entre os stakers e o DAO.
3. Introduzir um cronograma dinâmico estendido nas decisões DAO que pode ser acionado por uma minoria ativa de participantes e prolongado à medida que mais stakers participam.
4. Melhore a eficiência da votação a pé permitindo que os stakers saírem 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 do risco de governança podem ser encontradas nesta nota: < a href= " https://hackmd.io/@skozin/R17MLW2La " " > https://hackmd.io/@skozin/r17mlW2la 37.

Note-se que os stakers não são a única categoria de utilizadores de protocolo; também existem operadores de nós. Uma potencial direção de pesquisa futura é procurar maneiras de também melhorar a eficiência da votação a pé por operadores de nós, por ex. permitindo que um subconjunto de stakers e operadores de nós coordene um protocolo e uma bifurcação DAO, apontando novamente as credenciais de retirada do validador para um novo contrato (atualmente não suportado pela camada de consenso).

Outra direção da pesquisa futura é explorar a governança não simbólica e híbrida 2.

Próximos passos

A partir daqui, várias coisas têm de acontecer antes que o projeto seja finalizado, resultando numa Proposta de Melhoria do Lido (LIP) mais formal que será submetida a uma votação DAO e o documento associado do Architecture Decision Record (ADR):

1. Avaliar a robustez do mecanismo proposto através de modelagem de cenários e ataques.
2. Avaliar a praticidade do mecanismo através da prototipagem do código.
3. Reunir o feedback da comunidade.

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

É importante destacar que, embora a dupla governação 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 publicando um tópico neste fórum.

Isenção de responsabilidade：

1. Este artigo foi reimpresso de [lido]. Todos os direitos de autor pertencem ao autor original [skozin]. Se houver objeções a esta reimpressão, contacte a equipa do Gate Learn, e eles tratarão disso imediatamente.
2. Isenção de responsabilidade: As opiniões e opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outras línguas são feitas pela equipa do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.