Gov2: a próxima geração de governança descentralizada da Polkadot

O primeiro sistema de governança descentralizado do Polkadot era bastante interessante na época: uma estrutura tricameral (tri-câmara) com um comitê tecnocrático gerenciando os prazos de renovação, eleito pelo "governo" executivo para gerenciar parâmetros, administração e propostas de gastos como um sistema de votação comum para tudo o mais que recompensasse as partes interessadas com maior influência. Foi vagamente baseado na democracia parlamentar e funcionou razoavelmente bem durante seus primeiros 2 a 3 anos de operação, ajudando a garantir o uso eficiente dos fundos do tesouro, acompanhando o lançamento de atualizações e gerenciando o lançamento de patches mais importantes em tempo hábil moda. No entanto, tem suas desvantagens.

O órgão executivo eleito (conhecido como Conselho) é centralizado e geralmente não é anônimo. Isso coloca tanto o protocolo em algum grau de risco quanto os conselheiros individuais que podem estar sob pressão para agir de uma forma ou de outra. A comissão técnica, embora tenha muito menos poderes, tem a mesma influência e maior centralização. Em um mundo onde o poder sobre a sociedade (benevolente e malévolo), a descentralização está se tornando cada vez mais necessária para a segurança e proteção de todos os participantes.

Além disso, existe apenas um modelo de referendo tudo ou nada - todos os referendos têm poder máximo. Em parte por causa disso, apenas um referendo pode ser realizado por vez e, por padrão, essas votações duram várias semanas. Isso, e os poderes limitados do Conselho, significam que, em geral, o sistema incentiva a consideração em profundidade de um número muito pequeno de propostas, em vez de uma consideração ampla de muitas. Em vez de aproveitar o poder da multidão, inadvertidamente limita seus esforços para gerenciar a quantidade de largura de banda potencial em sua tomada de decisão.

A natureza da delegação grosseira significa que um certo grau de exclusividade é incorporado ao sistema. As barreiras à entrada em uma estrutura política eficaz são altas, reduzindo a inclusão e a diversidade e prejudicando a participação e a legitimidade.

Sempre ficou claro que a primeira versão da gestão do Polkadot era apenas isso: algo a ser repetido ao longo do tempo. Agora estou muito satisfeito por poder detalhar nossa proposta de governança de próxima geração no ecossistema Polkadot.

Apresentando Gov2 #

O sistema de controle de próxima geração da Polkadot, conhecido na época como Gov2, visa solucionar problemas com o sistema atual. Primeiro, o que não muda: não se desvia do princípio de governança original de Polkadot, que afirma que 50% da participação total no sistema deve, se tiver poder de persuasão suficiente, ser capaz de gerenciar o futuro do sistema. Da mesma forma, não se afasta da votação de persuasão pioneira da Polkadot, dando mais peso àqueles que estão dispostos a trancar seus tokens no sistema por mais tempo. Além disso, o coletivo tecnocrático ainda é útil, embora difira um pouco em importância, tamanho, composição e mecânica de filiação do atual Comitê Técnico.

Diferencia-se mais na forma como administra os meios práticos de tomada de decisão no dia-a-dia, tornando as consequências dos referendos maiores e mais flexíveis para aumentar drasticamente o número de decisões coletivas que o sistema pode tomar. Vejamos um pouco mais a fundo como isso funciona.

Reduzindo Barreiras#

Gov2 é realmente muito mais simples em muitos aspectos do que o gerenciamento atual. O departamento não possui órgãos adicionais que atuam como "cidadãos de primeira classe", como o Conselho e o Comitê Técnico. Não há programação de oferta rotativa. Não há fila de oferta pública. Em vez disso, temos apenas um mecanismo de tomada de decisão de primeira classe: o referendo. A principal diferença no Gov2 é que pode haver muitos deles - talvez até milhares - e todos acontecem ao mesmo tempo.

No Gov2, qualquer pessoa pode iniciar um referendo a qualquer momento, e pode fazê-lo quantas vezes desejar. Qualquer pessoa também pode votar nestes referendos. Não há limites explícitos para o número de referendos abertos à votação a qualquer momento.

Mas poderia levar a mais coisas para votar que uma pessoa normal com uma quantidade razoável de tempo poderia apreciar. Isso pode reduzir a inclusão e a segurança. Então, para tornar esse potencial conjunto de coisas para votar gerenciável para as pessoas comuns, estamos introduzindo alguns novos recursos interessantes no processo de referendo.

Origem e rastreabilidade#

Todos os referendos são baseados em uma proposta, que na verdade é apenas outra maneira de dizer "operação" em Polkadot. Isso é o mesmo que é descrito e executado quando você faz uma transação e está incluído em um bloco. Existem muitas operações que o Polkadot pode realizar, mas algumas com as quais você provavelmente já está familiarizado são a transferência, que pode mover ativos entre contas, e o staking, que permite apostar em uma conta. Existem muitos outros. O que torna essa função de controle especial não são essas instruções/operações, mas sim a fonte pela qual elas são executadas.

Uma origem pode ser pensada como um tipo de descritor de nível de privilégio estendido. Ele é passado quando a operação é executada, e a lógica da operação normalmente verifica se é o que deveria ser. Quando uma transação normal está em andamento, o parâmetro Origem é definido para o que é conhecido como Assinado. Isto significa que uma determinada conta do sistema autorizou (normalmente através da assinatura de uma transação) a execução de uma operação, e esta é realizada com esse privilégio, o que implica também, por exemplo, que os fundos controlados por essa conta e só essa conta possam ser gasto.

Os materiais do plano de controle permitem que você execute operações em outras fontes mais privilegiadas. A mais privilegiada delas é a linhagem Raiz, que é onipotente. Esta é a Fonte de onde foram enviadas as propostas de todos os referendos aprovados no antigo sistema de governo. Em Gov2, temos muitas origens diferentes, todas com algumas vantagens exóticas, mas muitas delas são significativamente menos poderosas e mais específicas do que a Root.

No Gov2, permitimos que o proponente especifique com qual fonte gostaria que sua proposta fosse completada. Cada origem suportada está associada a uma classe de referendo (ou seja, tipo de referendo), e a maioria dessas classes corresponderá a apenas uma origem, mas pode haver aquelas que consistem em várias origens. Cada classe tem sua própria trilha, que é essencialmente um pipeline no qual a sentença vive e passa, e é completamente independente das trilhas de outras classes.

Ter faixas independentes nos permite adaptar a dinâmica do referendo com base em seu nível de privilégio implícito. Referendos que implementam suas propostas de fontes mais influentes (leia-se: perigoso!) terão garantias mais fortes, limites mais altos e tempos de revisão mais longos. A origem raiz tem os limites e medidas de segurança mais altos. Aquelas Origens que delegam relativamente pouco poder (como uma Origem Soviética capaz de gastar não mais que 10 DOTs do tesouro) têm períodos de revisão correspondentemente mais curtos e limites mais baixos para aprovação.

Começar#

Quando um referendo é inicialmente criado, qualquer membro da comunidade pode votar imediatamente nele. No entanto, não está em condições de esgotar ou de outra forma contar os seus votos, ser aprovado e adoptado de forma simplificada. Em vez disso, os referendos devem atender a uma série de critérios antes de entrar em um estado conhecido como Decisão. Até que estejam nesse estado, permanecem indecisos.

Três critérios devem ser atendidos: primeiro, todos os referendos têm um período preparatório. Esta é a quantidade de tempo que deve decorrer após uma proposta antes que uma decisão possa ser tomada. Isso prevê um período de aviso inicial durante o qual os votos podem ser lançados para mitigar a possibilidade de uma "decisão de atirador" em que um invasor que controla um número significativo de votos pode tentar forçar a aprovação de uma proposta logo após ter sido feita, evitando que um votação geral. É hora de as pessoas pensarem e votarem.

Em segundo lugar, deve haver espaço para a tomada de decisões. Todas as faixas têm seu próprio limite no número de referendos que podem tomar decisões ao mesmo tempo. Quanto mais poderosas forem as Fontes permitidas na pista, menor será esse limite. No nível da raiz, há um limite de um, o que significa que apenas uma proposta super arriscada pode ser decidida por vez. Por outro lado, a trilha Tipping de baixa potência tem limites muito menos rigorosos, já que qualquer dano causado pela superpopulação é mínimo, e é muito mais útil ter várias dicas aceitas simultaneamente em muitas chamadas de nível raiz. Quando há uma vaga aberta, então um referendo (de outra forma válido) da classe com mais votos a favor da aprovação se torna decisivo.

Finalmente, você precisa pagar um Depósito de Solução. Criar um referendo é barato e requer um depósito relativo apenas ao armazenamento de rede necessário para rastreá-lo. No entanto, a decisão do referendo é altamente arriscada e requer espaço limitado, pois limitamos o número de referendos que podem ser decididos simultaneamente em cada via. Assim, um depósito maior (embora reembolsável) é necessário para evitar spam ou inchaço do sistema.

Tomar uma decisão e confirmar a oferta#

Uma vez que o referendo entra em um estado de tomada de decisão, ele pode ser aprovado. Este direito é válido apenas por um tempo limitado (28 dias na Polkadot), após o qual, se não aprovado, é negado por padrão. Para ser aprovado, ele deve atender a dois critérios (nesse caso, dizemos que foi aprovado) e deve continuar atendendo a esses critérios pelo menos durante o período de confirmação. Diferentes faixas têm diferentes durações de período de confirmação, com faixas mais poderosas demorando mais para confirmar. Esta é uma salvaguarda adicional contra o eleitor da baleia que tenta "contornar" o referendo ganhando votos suficientes para que os critérios de aprovação sejam inesperadamente violados.

Os dois critérios de aprovação estão relacionados à aprovação e suporte. Foi-se o viés de quórum adaptativo dos referendos anteriores. Agora temos um sistema mais flexível onde esses requisitos podem ser ajustados em um nível muito mais refinado. Aprovação é definida como a proporção do peso da aprovação (ou seja, após ajuste para condenação) em relação ao número total de votos (tanto para aprovação quanto para rejeição). Apoio é o número total de votos aprovados (ou seja, ignorando qualquer emenda para condenar) comparado ao número total de votos possíveis que podem ser feitos no sistema.

Cada classe de referendo tem requisitos diferentes para esses valores. No entanto, o mais interessante é que esses requisitos podem ser reduzidos ao longo do tempo em um cronograma bem definido. Isso significa que, à medida que a votação durar 28 dias, podemos ajustar as coisas para que exija cada vez menos apoio e aprovação geral da proposta para ser aprovada. Em geral, eles sempre começarão e terminarão da mesma maneira, começando com os limites mais altos e terminando com os mais baixos, que ainda atendem aos princípios gerais: pelo menos 50% de aprovação.

O que acontece no meio determina o quão fácil é obter aprovação antes do prazo de 28 dias. Em propostas que usam fontes menos privilegiadas (como a classe Tip, que só pode reivindicar até 10 DOT do Tesouro), faz muito mais sentido reduzir a participação necessária para um valor mais realista mais cedo do que aquelas que usam classes altamente privilegiadas como Raiz. Da mesma forma, classes de maior importância política tenderão a aceitar menos controvérsia (e, portanto, exigir maior aprovação) desde o início.

Após aprovação#

As propostas não aprovadas no prazo de 28 dias são consideradas rejeitadas por defeito. Neste ponto, o Depósito de Decisão pode ser devolvido. Se, por outro lado, a proposta se tornar e permanecer em andamento durante o período de confirmação durante esses 28 dias, então ela é considerada aprovada e está programada para ser executada desde a fonte, caso tenha sido devidamente proposta, após algum período de vigência.

O período de aceitação também é especificado quando um referendo é proposto, mas seu valor mínimo depende da faixa. Algumas das faixas mais poderosas exigem um período de aceitação mais longo para dar à rede tempo suficiente para se preparar para quaisquer mudanças que a proposta possa trazer.

Intervenções#

Às vezes, torna-se evidente que uma proposta que já está sendo votada (e possivelmente já está sendo votada) contém um problema e é desejável cancelá-la. Um exemplo disso seria uma atualização em cadeia que mais tarde descobriu um problema. Embora não seja muito comum, também não é totalmente inédito.

Gov2 tem uma operação especial para esta intervenção conhecida como Cancelar. Esta operação rejeita imediatamente o referendo atual, independentemente de seu status. Na verdade, isso vem em duas formas, uma apenas realiza uma operação simples e a outra também corta o autor original do(s) depósito(s) pago(s) pelo referendo.

O cancelamento em si é uma operação de controle que deve ser aprovada pela rede para ser realizada. Isso representa um possível problema de cronograma e, para ser útil, aceitar uma proposta de cancelamento normalmente teria que ser muito mais rápido do que qualquer proposta segmentada possível. Portanto, o cancelamento tem sua própria fonte e caminho, que tem lead times baixos e curvas de aprovação/suporte com quedas um pouco mais acentuadas em seus limites para passar.

Delegação flexível#

Em um mundo ideal onde todos tivessem tempo e virtuosismo ilimitados, todos pesquisariam, discutiriam, considerariam e votariam cuidadosamente em cada proposta. No entanto, não vivemos em um mundo ideal. Nem todo mundo tem tempo ou inclinação para conduzir uma votação elaborada em cada questão. A partir dessa constatação, o Conselho nasceu na administração original do Polkadot: um órgão delegado pelos eleitores para compensar o fato de muitos deles não quererem participar do dia-a-dia da administração. No entanto, uma vez que o Conselho deixou Gov2, precisamos de meios alternativos para garantir que os eleitores "passivos" sejam ouvidos.

O sistema de governança original tinha um recurso chamado "Delegação de Voz" que mantivemos e melhoramos no Gov2. Para quem não conhece, isso é semelhante à premissa da democracia líquida: você pode delegar seu direito de voto a outro eleitor do sistema. Quando seu delegado vota, ele não só tem seu próprio voto, mas também o seu. Isso funciona com votação de persuasão, permitindo que você bloqueie seus tokens para aumentar o nível de poder de voto que seu delegado detém em seu nome. Claro, os tokens em questão nunca estão fora de seu controle, e você pode trocar de delegado ou recuperar o controle direto sempre que quiser.

No entanto, o Gov2 melhora isso com um recurso bastante especial chamado delegação multiusuário. Isso permite que você especifique um delegado diferente para cada classe de referendo no sistema. Se você não quiser delegar autoridade para uma classe específica de referendo, você também pode manter o controle direto sobre essa classe.

Isso significa que você pode delegar autoridade a uma pessoa para qualquer referendo para dar pequenos conselhos aos participantes do ecossistema, para outra pessoa para referendos sobre gastos maiores do tesouro, para outra pessoa para atualizações puramente técnicas e parametrização de rede e, finalmente, manter o controle direto sobre qualquer outro decisões!

Comunicação e lista branca#

Uma opinião de "especialista" bem informada desempenha um papel importante em qualquer sistema de gestão que funcione bem. A tecnocracia tem suas próprias desvantagens bastante sérias, e é por isso que não queremos "especialistas" em uma posição de liderança: ela cria os riscos de centralização, poder irresponsável e estabelece as bases para o que poderia eventualmente se tornar uma camarilha dominante. É por esta razão que o Comitê Técnico de Governança Inicial da Polkadot não tem "poder de decisão", mas apenas a capacidade de encurtar o período de votação.

No entanto, expressar uma opinião bem informada e permitir que ela ajude a melhorar o processo de tomada de decisão, mesmo que não afete diretamente o resultado da tomada de decisão, parece uma meta razoável a ser almejada. É extremamente importante, e para o bem de todos os participantes, que o órgão de peritos não possa de forma alguma prejudicar a decisão comum das partes interessadas.

Propostas de origem raiz são necessárias para atualizações, patches e resgates, mas elas podem quebrar e corromper arbitrariamente o sistema. Em Gov2, por serem tão perigosos, erramos do lado da segurança e temos um nível extremamente alto de aprovação e suporte necessário para uma jogada inicial, que é reduzida muito lentamente aos níveis finais. Os períodos de entrada e jogo também são longos. No geral, o processo é lento e isso é feito para notificar todos no Polkadot o máximo possível para garantir que sugestões ruins não sejam aceitas.

No entanto, há momentos em que é importante implantar uma lógica de correção, atualização ou restauração em um período mais curto. Podemos supor que atualmente existe um amplo consenso, mas as medidas de segurança descritas acima em relação ao processo de votação significam que fazer essa correção pode ser difícil ou impraticável apenas por falta de tempo. Passar à ideia de que "os especialistas concordam que é seguro e urgente" pode ser uma ferramenta muito útil para estabelecer um processo claro, bem pensado em geral, mas capaz de tomar decisões em um cronograma apertado quando há boas razões para acreditar que as circunstâncias o exigem.

Duas grandes questões ainda precisam ser respondidas aqui: como pode uma cadeia (um grupo lógico determinista que não tem sua capacidade inerente de expressar ou observar os conceitos como "seguro" e "tempo crítico"? circunstâncias, como é adaptável a nossa lógica sem comprometer nossa flexibilidade e simplicidade gerais?

A irmandade#

A resposta à primeira pergunta está no novo corpo diretivo. Para quem conhece o antigo sistema de governança, esse órgão pode ser visto como o sucessor lógico do Comitê Técnico.

Chama-se Polkadot Fellowship e, no geral, é rica e complexa o suficiente para ser objeto de um artigo totalmente diferente. Ele operará inicialmente na rede Kusama, pois o Gov2 será implantado lá para fins de teste ao vivo, no entanto, será movido para Polkadot com o lançamento final do Gov2 e, posteriormente, atenderá a ambas as redes através da ponte Polkadot/Kusama.

A Irmandade é basicamente um corpo de especialistas autônomo cujo objetivo principal é representar as pessoas que incorporam e mantêm a base de conhecimento técnico da rede e do protocolo Polkadot. Ao contrário do Coletivo Técnico atual, ele é projetado para uma adesão muito mais ampla (ou seja, para trabalhar efetivamente com até dezenas de milhares de membros) e com barreiras de entrada muito menores (tanto em termos de fluxo de processos administrativos quanto de expectativas de experiência). ). Tornar-se um candidato a membro da Comunidade é tão fácil quanto fazer um pequeno depósito.

Para ajudar a garantir a alta qualidade das decisões coletivas à luz dessa ampla associação, os membros recebem uma classificação que indica até que ponto o sistema espera que sua opinião seja bem informada, com base técnica sólida e alinhada aos interesses da Polkadot. Os membros da Comunidade podem votar em qualquer proposta da Comunidade, e a opinião conjunta dos membros (ponderada pela sua posição) constitui a opinião ponderada da Comunidade.

Muito bom, o meio técnico pelo qual a Comunidade vota é exatamente o mesmo código (palete de substrato) que o meio pelo qual as partes interessadas do Polkadot votam em um referendo, e tem exatamente as mesmas capacidades (pistas múltiplas, delegação flexível, etc.).

Ranks e armadilhas#

A introdução do conceito de classificação está associada a armadilhas. No entanto, temos relativamente poucas opções se nossos requisitos forem descentralização, responsabilidade e segurança para todos os participantes. Achamos prudente usar a abertura, transparência e resistência à corrupção que o consenso descentralizado oferece para garantir que quaisquer “governantes” não sejam superiores a “regras”, e que a classificação seja acompanhada por expectativas, regras e responsabilidade claras. As desvantagens da classificação não são apenas ruins para a rede, mas, à luz de algumas posições políticas recentes sobre política de tecnologia descentralizada, também são ruins para os participantes: se a classificação permitisse que um pequeno grupo de participantes tivesse controle efetivo sobre a rede, eles poderiam ser considerado para realmente controlá-lo e, portanto, responsável pelo que aconteceu com ele.

Assim, aderimos a três princípios: primeiro, a Irmandade nunca deve ter um poder rígido sobre a rede: não pode alterar parâmetros, realizar resgates ou movimentar ativos. No que diz respeito à gestão da rede, a única coisa que pode fazer é encurtar o calendário efectivo do referendo.

Em segundo lugar, o sistema de classificações e pesos deve ser projetado de tal forma que não esperemos que pequenos grupos de pessoas capturem e controlem a capacidade geral de tomada de decisão. Embora a Comunidade dê mais peso àqueles que têm uma classificação mais alta na opinião agregada, o peso não deve ser tão alto a ponto de fazer com que um pequeno número de opiniões de membros mais altos seja dominante em comparação com a opinião consistente vinda de membros menos classificados.

Em terceiro lugar, a Comunidade deve ser concebida para aumentar e desenvolver os seus membros e o seu nível de conhecimento combinado, e assegurar que a sua capacidade global de tomada de decisão seja reforçada ao longo do tempo. Para o sucesso a longo prazo, a Comunidade deve ser uma meritocracia efetiva na qual pessoas com dedicação, talento e experiência alcancem níveis mais altos de influência. Para isso, devemos trazer clareza e transparência ao processo de entrada e promoção. Na medida do possível, a personalidade de uma pessoa não deve ser considerada, mas apenas suas habilidades devem ser consideradas.

Diante disso, a Irmandade terá um estatuto que descreva em termos concretos as exigências e expectativas das pessoas para alcançar e manter este ou aquele grau. Os escalões mais altos podem votar e promover a votação dos escalões mais baixos com base nesta constituição. O rebaixamento ocorre automaticamente após um período durante o qual o membro não consegue defender sua posição diante de seus pares. A suspensão só pode ocorrer através de um referendo geral (polkadot) que forneça um meio de garantir que a dissensão ou a impopularidade na Comunidade não conduza (necessariamente) à expulsão. Além disso, para se proteger contra a chance da Irmandade se tornar uma cabala, a entrada nos escalões mais altos também requer um referendo completo (polkadot) e não pode ser concedido por apenas um dos membros da Irmandade.

A lista branca#

Embora a Irmandade possa representar um grupo de especialistas da Polkadot na rede e fornecer uma lógica determinística da qual sua opinião combinada possa ser derivada, pode não estar claro como podemos integrar isso ao sistema geral de referendos. Na verdade, isso é alcançado por meio de uma combinação de conceitos que já conhecemos e uma peça surpreendentemente simples de lógica de encadeamento chamada paleta de lista branca.

A paleta whitelist faz uma coisa: permite que uma origem eleve os privilégios de outra origem para uma operação específica. Para Gov2, isso permite que a Comunidade autorize uma nova origem (que chamaremos de Whitelisted-Root) para ser executada com privilégios de nível de raiz. Você pode pensar nisso como algo como Unix sudo, exceto que ele só funciona com certos comandos que são previamente permitidos pela comunidade. Isso significa que podemos ter uma nova direção na governança do Polkadot dedicada às propostas da lista de permissões da Comunidade. Se o referendo for aprovado, eles serão executados dentro de um palete de lista branca com essa fonte raiz da lista branca. A paleta da lista branca confirma duas coisas: que esta origem é de fato uma raiz da lista branca (ou seja, que o referendo seguiu esse caminho) e que a proposta foi de fato incluída na lista branca pela Comunidade. Em caso afirmativo, ele executa a operação com privilégios de nível raiz.

Dito isto, não precisamos mudar nada sobre como funciona o sistema de referendo (sim!). Agora temos uma nova pista (para origem na lista branca) cujos parâmetros nos permitem acelerar o processo de votação, sabendo que através de um processo aberto e transparente, um grupo de especialistas mundiais no protocolo Polkadot determinou que isso é seguro e rápido crítico.

Cronograma e trabalho futuro#

Gov2 será lançado em Kusama logo após uma auditoria profissional final de seu código. Depois de testar no Kusama, a rede Polkadot será convidada a votar.

Uma atualização para esse sistema de gerenciamento comum, com o codinome "Gov2.5", está programada para lançamento final em alguns meses. Ele trará dois recursos principais: primeiro, um recurso de "chamada a cobrar" para delegação de votos, essencialmente permitindo que os usuários (através de suas carteiras) ofereçam seus fundos para delegação sem pagar nenhuma taxa de transação; em vez disso, o delegado poderá pagar uma taxa de transação adicional para receber os fundos delegados. Em segundo lugar, será introduzida uma operação de delegação gratuita, que pode ser utilizada de forma limitada por todos os utilizadores delegantes. Juntos, esses recursos permitem que as carteiras ofereçam integrações de governança simplificadas e econômicas para seus usuários, o que esperamos incentivar os usuários a se envolverem mais no processo geral de governança.

Este material foi traduzido pela equipe de validadores do NQ4.NET. Obrigado por ler.
Original: https://blog.nq4.net/gov2-polkadots-next-generation-of-decentralised-governance-b93d2e064a04
Nossas atividades nas redes sociais: facebook, twitter, reddit, linkedin, youtube