Na época, o primeiro sistema de governança descentralizado de Polkadot era muito interessante: uma estrutura de separação de poderes com um comitê técnico para gerenciar o cronograma de atualização, um “governo” executivo eleito por aprovação para gerenciar parâmetros, propostas de gestão e gastos, e uma votação comum sistema usado para todo o resto, recompensando os detentores de longo prazo com maior influência. Baseia-se vagamente na democracia parlamentar e teve um desempenho razoavelmente bom nos seus primeiros 2-3 anos de funcionamento, ajudando a garantir que os fundos fiscais são gastos de forma sensata, as atualizações são implementadas rapidamente e as soluções críticas são geridas em tempo útil. No entanto, também tem suas desvantagens.
O executivo eleito (chamado Assembleia) é centralizado e geralmente não anônimo. Isto expõe tanto o acordo como os deputados individuais a um certo grau de risco, uma vez que podem ser pressionados a comportar-se de uma determinada forma. Os comités técnicos, embora possuam menos poder, enfrentam riscos semelhantes e maior centralização. Na sociedade atual, seja bem-intencionada ou maliciosa, a descentralização é cada vez mais necessária para a segurança de todos os participantes.
Além disso, existe apenas um modelo de referendos do tipo “tudo ou nada” – com o maior poder de todos os referendos. Em parte por esta razão, apenas um referendo pode ser realizado de cada vez, e estas votações duram semanas por defeito. Os problemas resultantes, bem como a largura de banda limitada do parlamento, significam que o sistema é mais propício à análise aprofundada de um pequeno número de propostas do que à consideração ampla de muitas propostas. Em vez de aproveitar o poder do poder das multidões, limita-o inadvertidamente nas instituições que se esforçam por gerir o potencial rendimento das decisões.
A natureza da delegação grosseira significa que uma certa exclusividade está incorporada ao sistema. As barreiras à entrada em quadros políticos eficazes são elevadas, reduzindo a inclusão e a diversidade, reduzindo a participação e a legitimidade.
É claro que a primeira versão da governança de Polkadot é apenas algo que será repetido ao longo do tempo. Agora, estou animado para detalhar as propostas de governança da próxima geração que estamos introduzindo no ecossistema Polkadot.
#Apresentar Gov2
O sistema de governança de próxima geração de Polkadot, conhecido como Gov2 em desenvolvimento, visa resolver os problemas do sistema atual. Em primeiro lugar, não altera o seguinte: não viola os princípios de governação originais de Polkadot, que consistem em que um total de 50% do sistema deve ser capaz de controlar, em última análise, o futuro do sistema se tiverem fé suficiente em suas opiniões. Da mesma forma, não se afasta da pioneira Votação de Condenação em Polkadot, que deu maior peso àqueles dispostos a travar seus tokens no sistema por mais tempo. Além disso, o Coletivo Técnico ainda exigirá um Grupo Técnico, embora seja diferente em importância, tamanho, composição e mecanismos de adesão dos atuais Comitês Técnicos.
A maior diferença é a forma como gere os meios práticos de tomada de decisões do dia-a-dia, dando mais abrangência e agilidade às consequências do referendo, aumentando significativamente o número de decisões colectivas que o sistema pode tomar. Vamos dar uma olhada mais profunda em como isso funciona.
Abaixe o limite
Em muitos aspectos, o Gov2 é na verdade mais simples do que os actuais sistemas de governação. Não existem outras instituições que sirvam como “primeira categoria de cidadãos” na governação, tais como parlamentos e comissões técnicas. Não há cronograma rotativo de propostas. Não há fila de propostas públicas. Em vez disso, temos apenas um mecanismo de tomada de decisão do tipo 1: o referendo. A principal diferença com o Gov2 é que pode haver muitos desses mecanismos – talvez até milhares – acontecendo simultaneamente.
No Gov2, qualquer pessoa pode iniciar um referendo a qualquer momento, e pode fazê-lo continuamente. Qualquer pessoa também pode votar nesses referendos. Não há um limite claro para o facto de um referendo poder ser votado a qualquer momento.
Mas isto pode resultar na votação de tantos assuntos que uma pessoa comum pode não ser capaz de avaliar todos eles num período de tempo razoável. Isso pode reduzir a inclusão e a segurança. Assim, para tornar estes potenciais itens de votação viáveis para as pessoas comuns, estamos a introduzir algumas novas funcionalidades interessantes no processo de referendo.
Origens e Órbitas
Todos os referendos são baseados em propostas, que na verdade são outra forma de dizer “ações” em Polkadot. É a mesma coisa descrita e executada quando você faz uma transação e a inclui em um bloco. Polkadot pode realizar uma ampla variedade de operações, mas algumas das que você já deve estar familiarizado são a operação de “transferência”, que pode movimentar ativos entre contas, e a operação de “aposta”, que bloqueia contas. Existem muitas outras operações. O que torna especial esta característica de governança não são as propostas/ações, mas a Origem com que são executadas.
Você pode pensar no Origin como um descritor rico de níveis de privilégio. Quando uma operação é executada, a Origem é passada e a lógica da operação geralmente verifica se é o que deveria ser. Quando uma transação regular é executada, o parâmetro Origin é definido como uma variante chamada Signed. Isso significa que uma conta específica no sistema (geralmente autorizada pela assinatura de uma transação) permite que a operação aconteça, e ela funciona com esse privilégio, implicando ainda que, por exemplo, poderão ser gastos fundos que só podem ser controlados por esta conta.
As operações em nível de governança permitem que as operações sejam executadas como outras origens mais privilegiadas. O mais privilegiado entre eles é o Root Origin, que possui poderes ilimitados. Esta é a Origem de onde serão enviadas todas as propostas de referendo aprovadas. No Gov2 temos muitos Origins diferentes, todos desfrutando de certas vantagens, mas muitos deles são muito mais fracos e mais especializados que o Root.
No Gov2, permitimos que os proponentes especifiquem a Origem em que desejam que suas propostas sejam executadas. Cada Origem suportada está associada a uma categoria de referendo, e a maioria dessas categorias corresponderá a exatamente uma Origem, mas pode haver algumas categorias compostas por múltiplas Origens. Cada categoria tem seu próprio Track, que é basicamente um pipeline onde as propostas passam e são totalmente independentes dos Tracks das outras categorias.
Ter vias separadas permite-nos adaptar a dinâmica de um referendo com base no seu nível implícito de privilégio. Um referendo que aprovasse as suas propostas da origem mais poderosa (leia-se: perigosa!) teria protecções mais rigorosas, limiares mais elevados e períodos de consideração mais longos. Root Origin tem os limites e salvaguardas mais altos. Origens que transferem relativamente pouco poder (como Tip Origin, que pode pagar até 10 DOT do tesouro) têm períodos de consideração mais curtos e limites de aprovação mais baixos.
comece
Quando o referendo foi criado, qualquer membro da comunidade poderia votar imediatamente. Mas ainda não atingiu um estado em que os seus votos possam ser encerrados ou de outra forma contados, aprovados e subsequentemente executados. Em vez disso, os referendos devem satisfazer uma série de condições antes de serem chamados de estado de “decisão” e, até entrarem neste estado, permanecem indecisos.
Três condições precisam ser atendidas: Primeiro, todos os referendos têm um período de preparação. Esse é o tempo que deve passar após a proposta. Isto dá tempo para um período de aviso inicial para que os votos possam ser apresentados, evitando a possibilidade de um "tiro de decisão", no qual um invasor que controla um grande número de direitos de voto poderia tentar aprovar uma proposta logo após ela ser submetida, impedindo em bloco votação As pessoas têm tempo para pensar e votar.
Em segundo lugar, deve haver espaço para a tomada de decisões. Todas as faixas têm seus próprios limites quanto ao número de referendos que podem ser decididos simultaneamente. Quanto mais poderoso (por exemplo, mais perigoso!) o Origin puder executar na pista, menor será esse limite. A origem do nível raiz é limitada a 1, o que significa que apenas uma proposta superperigosa pode ser decidida por vez. Em contraste, a faixa de tombamento bastante fraca é muito mais restritiva, já que qualquer dano que possa ser causado por decisões excessivas é mínimo, e ter muitas chamadas no nível raiz é mais útil. Quando houver espaço disponível, os referendos (de outra forma elegíveis) para as categorias com as aprovações mais favoráveis serão elevados ao status de decisão.
Por fim, o depósito da decisão deverá ser pago. Criar um referendo é barato, exigindo apenas um depósito associado ao armazenamento on-chain necessário para rastreá-lo. No entanto, permitir que os referendos sejam decididos acarreta maiores riscos e utiliza espaço limitado porque limitamos o número de referendos que podem ser decididos em cada via simultaneamente. Portanto, um depósito maior (embora reembolsável) deve ser feito para mitigar o risco de spam ou inchaço do sistema.
Decidir e confirmar propostas
Quando um referendo atinge o status de tomada de decisão, ele se torna elegível para aprovação. Esta qualificação é válida apenas por um tempo limitado (28 dias no Polkadot), após o qual, se não for aprovada, será negada por padrão. Para ser aprovado, deve atender a dois critérios (neste caso, chamamos de “aprovação”), e deve continuar atendendo a esses critérios por um período mínimo de tempo durante o período de confirmação. Órbitas diferentes têm períodos de confirmação diferentes, com órbitas mais poderosas demorando mais para serem confirmadas. Esta é uma defesa adicional para evitar que os eleitores das baleias “disparem” no referendo através de uma votação suficientemente grande.
Dois critérios de aprovação estão relacionados à aprovação e ao suporte. O preconceito adaptativo do quórum dos referendos anteriores já não existe. Agora temos um sistema mais flexível que pode adaptar estes requisitos a um nível mais granular. A aprovação é definida como a parcela do peso do voto de aprovação (ou seja, ajustado pela crença) do peso total dos votos (pesos dos votos para aprovação e rejeição). Apoio é o número total de votos em aprovação (ou seja, ignorando ajustes nas crenças) comparado ao número total de votos que poderiam ter sido gerados no sistema.
Cada categoria de referendo tem requisitos diferentes para esses valores. O mais interessante, porém, é que essas exigências podem ser reduzidas gradativamente de acordo com um cronograma bem definido. Isso significa que à medida que a votação avança ao longo dos 28 dias, podemos configurar as coisas para que o apoio e a aprovação geral necessários para que uma proposta seja aprovada sejam menores. De um modo geral, começarão e terminarão sempre da mesma forma, começando com o limiar mais elevado e terminando com o limiar mais baixo que ainda respeite o princípio geral: é necessária pelo menos 50% de aprovação.
O que acontece no meio determina o quão fácil será ser aprovado antes do prazo de 28 dias. Para propostas que utilizam Origens menos privilegiadas (como a categoria Tip, que só pode solicitar pagamentos de até 10 DOT do tesouro), seria mais razoável reduzir os votos exigidos mais cedo. Propostas que utilizam categorias altamente privilegiadas, como Root, terão maior probabilidade de receber menos controvérsia no início (e, portanto, exigirão maior aprovação).
Após aprovação
Após 28 dias, as propostas não aprovadas são consideradas rejeitadas por defeito. Neste ponto, o depósito da decisão pode ser reembolsado. Por outro lado, se uma proposta conseguir ser aprovada e permanecer aprovada durante esses 28 dias, ela será considerada aprovada e programada para ser implementada pela Origem devidamente proponente dentro de um determinado período de implementação após ter sido proposta.
O período de implementação também é especificado quando a proposta é feita, mas depende da via. Algumas das vias mais robustas exigirão períodos de implementação mais longos para garantir que a rede tenha tempo suficiente para se preparar para quaisquer alterações que a proposta possa trazer.
#intervenção
Às vezes acontece que uma proposta que já está em votação (talvez já aprovada) contém problemas e você deseja cancelá-la. Um exemplo seria uma atualização em cadeia que posteriormente descobriu conter algum tipo de problema. Embora isso não seja muito comum, também não é inédito.
No Gov2, existe uma operação especial chamada Intervenção de cancelamento. Tal acção rejeitaria imediatamente um referendo em curso, independentemente do seu estatuto. Na verdade, apresenta-se em duas formas, uma das quais apenas realiza operações básicas e a outra que também reduz o valor do depósito que o proponente paga ao referendo.
O cancelamento em si é uma operação de governança que deve ser votada pela rede para ser executada. Isto levanta possíveis problemas com os prazos, na medida em que, para ser útil, uma proposta para que uma proposta de cancelamento seja aprovada rapidamente deve geralmente ser aprovada muito mais rapidamente do que uma provável proposta alvo. Como tal, o Cancelamento tem origem e pista próprias, com tempos de arranque mais baixos e uma curva de aprovação/apoio ligeiramente mais acentuada para ultrapassar barreiras.
Delegação flexível
Num mundo perfeito, onde todos tivessem tempo e competências ilimitadas, cada proposta seria pesquisada, discutida, considerada e votada cuidadosamente. Porém, em um mundo perfeito, não vivemos. Nem todo mundo tem tempo ou vontade de pesquisar cada questão em profundidade. Desta constatação surgiu o Conselho, a governação original de Polkadot: um órgão nomeado pelos eleitores para compensar o facto de muitos deles não estarem dispostos a participar na governação quotidiana. No entanto, com os conselhos eliminados no Gov2, precisamos de um meio alternativo de garantir que as vozes dos eleitores “passivos” sejam ouvidas.
O sistema de governança original tinha um recurso chamado delegação de voto, que mantivemos e melhoramos no Gov2. Para quem não conhece, isto é semelhante à premissa da democracia líquida: você pode delegar seu voto a outro eleitor do sistema. Quando os seus representantes votam, eles não são apenas donos do seu voto, mas também do seu voto. Isso funciona em conjunto com a Votação por Condenação, permitindo que você bloqueie seus tokens para aumentar o nível de poder de voto que seu delegado tem ao votar em seu nome. É claro que os tokens envolvidos nunca saem do seu controle e você pode trocar de representante ou recuperar o controle direto a qualquer momento.
No Gov2, entretanto, isso foi melhorado por meio de um recurso especial chamado Multirole Delegation. Isto permite-lhe especificar um representante diferente para cada categoria de referendo no seu sistema. Se não quiser delegar para uma categoria específica do referendo, você também pode manter o controle direto dessa categoria.
Isso significa que você pode delegar um trabalho a um indivíduo para quaisquer propostas em que os contribuidores do ecossistema recebam dicas, outra entidade para propostas com maiores gastos financeiros e outra entidade para propostas puramente técnicas de atualizações e parametrização de rede, e manter o controle direto sobre quaisquer outras decisões. !
Grupo acadêmico e lista de permissões
Em qualquer sistema de governação que funcione bem, a opinião de “especialistas” bem informados desempenha um papel importante. A governação especializada traz as suas próprias falhas graves, por isso não queremos que os “especialistas” sejam colocados numa posição de comando: isto introduz a centralização, a autoridade irresponsável e a base que pode acabar por se tornar o núcleo da dominação. Esta é a razão lógica pela qual o comité técnico originalmente governado por Polkadot não tem “poder de decisão”.
Seu nome é Polkadot Fellowship, que é chamada de “Academia” em Gov2. Os Fellows desempenham uma função na rede e não são responsáveis pela decisão final sobre a implementação de uma proposta. Em vez disso, apoiam o processo de governação, monitorizando e fazendo recomendações sobre aspectos técnicos, de conformidade, de risco e outros aspectos das propostas candidatas. A proposta é opcional, não obrigatória, e pode ser adotada ou ignorada pelo referendo.
Os Fellows não são anónimos e são convidados a divulgar as suas identidades para aumentar a transparência e a responsabilização. Este é um dos papéis do grupo acadêmico no Gov2.
O Gov2 também introduz um mecanismo denominado “lista branca” que permite a um grupo de entidades do sistema obter poderes especiais de governação. Isso pode ser usado para diversos fins, incluindo a introdução de novos membros ao ecossistema, recompensando contribuidores do ecossistema ou outros usos semelhantes. O mecanismo de lista branca é altamente configurável e a comunidade pode decidir como usá-lo.
para concluir
No geral, o Gov2 é uma grande melhoria na governação Polkadot, visando resolver problemas no sistema existente e melhorar a inclusão, eficiência e transparência da governação. Introduz uma série de novos recursos, como multitrack, origem, lista branca e grupo acadêmico, bem como um sistema de eleição de delegações mais flexível para melhor atender às diferentes necessidades de governança.
O objectivo deste sistema é reforçar a governação descentralizada, garantir a segurança de todos os participantes e melhorar a qualidade e a quantidade da tomada de decisões públicas. Fornece ferramentas mais fortes para o desenvolvimento futuro do ecossistema Polkadot para garantir o seu sucesso e sustentabilidade a longo prazo.
Autor: Gavin Wood
Ver original
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
Gov2: A próxima geração de governança descentralizada para Polkadot
Introdução
Na época, o primeiro sistema de governança descentralizado de Polkadot era muito interessante: uma estrutura de separação de poderes com um comitê técnico para gerenciar o cronograma de atualização, um “governo” executivo eleito por aprovação para gerenciar parâmetros, propostas de gestão e gastos, e uma votação comum sistema usado para todo o resto, recompensando os detentores de longo prazo com maior influência. Baseia-se vagamente na democracia parlamentar e teve um desempenho razoavelmente bom nos seus primeiros 2-3 anos de funcionamento, ajudando a garantir que os fundos fiscais são gastos de forma sensata, as atualizações são implementadas rapidamente e as soluções críticas são geridas em tempo útil. No entanto, também tem suas desvantagens.
O executivo eleito (chamado Assembleia) é centralizado e geralmente não anônimo. Isto expõe tanto o acordo como os deputados individuais a um certo grau de risco, uma vez que podem ser pressionados a comportar-se de uma determinada forma. Os comités técnicos, embora possuam menos poder, enfrentam riscos semelhantes e maior centralização. Na sociedade atual, seja bem-intencionada ou maliciosa, a descentralização é cada vez mais necessária para a segurança de todos os participantes.
Além disso, existe apenas um modelo de referendos do tipo “tudo ou nada” – com o maior poder de todos os referendos. Em parte por esta razão, apenas um referendo pode ser realizado de cada vez, e estas votações duram semanas por defeito. Os problemas resultantes, bem como a largura de banda limitada do parlamento, significam que o sistema é mais propício à análise aprofundada de um pequeno número de propostas do que à consideração ampla de muitas propostas. Em vez de aproveitar o poder do poder das multidões, limita-o inadvertidamente nas instituições que se esforçam por gerir o potencial rendimento das decisões.
A natureza da delegação grosseira significa que uma certa exclusividade está incorporada ao sistema. As barreiras à entrada em quadros políticos eficazes são elevadas, reduzindo a inclusão e a diversidade, reduzindo a participação e a legitimidade.
É claro que a primeira versão da governança de Polkadot é apenas algo que será repetido ao longo do tempo. Agora, estou animado para detalhar as propostas de governança da próxima geração que estamos introduzindo no ecossistema Polkadot.
#Apresentar Gov2
O sistema de governança de próxima geração de Polkadot, conhecido como Gov2 em desenvolvimento, visa resolver os problemas do sistema atual. Em primeiro lugar, não altera o seguinte: não viola os princípios de governação originais de Polkadot, que consistem em que um total de 50% do sistema deve ser capaz de controlar, em última análise, o futuro do sistema se tiverem fé suficiente em suas opiniões. Da mesma forma, não se afasta da pioneira Votação de Condenação em Polkadot, que deu maior peso àqueles dispostos a travar seus tokens no sistema por mais tempo. Além disso, o Coletivo Técnico ainda exigirá um Grupo Técnico, embora seja diferente em importância, tamanho, composição e mecanismos de adesão dos atuais Comitês Técnicos.
A maior diferença é a forma como gere os meios práticos de tomada de decisões do dia-a-dia, dando mais abrangência e agilidade às consequências do referendo, aumentando significativamente o número de decisões colectivas que o sistema pode tomar. Vamos dar uma olhada mais profunda em como isso funciona.
Abaixe o limite
Em muitos aspectos, o Gov2 é na verdade mais simples do que os actuais sistemas de governação. Não existem outras instituições que sirvam como “primeira categoria de cidadãos” na governação, tais como parlamentos e comissões técnicas. Não há cronograma rotativo de propostas. Não há fila de propostas públicas. Em vez disso, temos apenas um mecanismo de tomada de decisão do tipo 1: o referendo. A principal diferença com o Gov2 é que pode haver muitos desses mecanismos – talvez até milhares – acontecendo simultaneamente.
No Gov2, qualquer pessoa pode iniciar um referendo a qualquer momento, e pode fazê-lo continuamente. Qualquer pessoa também pode votar nesses referendos. Não há um limite claro para o facto de um referendo poder ser votado a qualquer momento.
Mas isto pode resultar na votação de tantos assuntos que uma pessoa comum pode não ser capaz de avaliar todos eles num período de tempo razoável. Isso pode reduzir a inclusão e a segurança. Assim, para tornar estes potenciais itens de votação viáveis para as pessoas comuns, estamos a introduzir algumas novas funcionalidades interessantes no processo de referendo.
Origens e Órbitas
Todos os referendos são baseados em propostas, que na verdade são outra forma de dizer “ações” em Polkadot. É a mesma coisa descrita e executada quando você faz uma transação e a inclui em um bloco. Polkadot pode realizar uma ampla variedade de operações, mas algumas das que você já deve estar familiarizado são a operação de “transferência”, que pode movimentar ativos entre contas, e a operação de “aposta”, que bloqueia contas. Existem muitas outras operações. O que torna especial esta característica de governança não são as propostas/ações, mas a Origem com que são executadas.
Você pode pensar no Origin como um descritor rico de níveis de privilégio. Quando uma operação é executada, a Origem é passada e a lógica da operação geralmente verifica se é o que deveria ser. Quando uma transação regular é executada, o parâmetro Origin é definido como uma variante chamada Signed. Isso significa que uma conta específica no sistema (geralmente autorizada pela assinatura de uma transação) permite que a operação aconteça, e ela funciona com esse privilégio, implicando ainda que, por exemplo, poderão ser gastos fundos que só podem ser controlados por esta conta.
As operações em nível de governança permitem que as operações sejam executadas como outras origens mais privilegiadas. O mais privilegiado entre eles é o Root Origin, que possui poderes ilimitados. Esta é a Origem de onde serão enviadas todas as propostas de referendo aprovadas. No Gov2 temos muitos Origins diferentes, todos desfrutando de certas vantagens, mas muitos deles são muito mais fracos e mais especializados que o Root.
No Gov2, permitimos que os proponentes especifiquem a Origem em que desejam que suas propostas sejam executadas. Cada Origem suportada está associada a uma categoria de referendo, e a maioria dessas categorias corresponderá a exatamente uma Origem, mas pode haver algumas categorias compostas por múltiplas Origens. Cada categoria tem seu próprio Track, que é basicamente um pipeline onde as propostas passam e são totalmente independentes dos Tracks das outras categorias.
Ter vias separadas permite-nos adaptar a dinâmica de um referendo com base no seu nível implícito de privilégio. Um referendo que aprovasse as suas propostas da origem mais poderosa (leia-se: perigosa!) teria protecções mais rigorosas, limiares mais elevados e períodos de consideração mais longos. Root Origin tem os limites e salvaguardas mais altos. Origens que transferem relativamente pouco poder (como Tip Origin, que pode pagar até 10 DOT do tesouro) têm períodos de consideração mais curtos e limites de aprovação mais baixos.
comece
Quando o referendo foi criado, qualquer membro da comunidade poderia votar imediatamente. Mas ainda não atingiu um estado em que os seus votos possam ser encerrados ou de outra forma contados, aprovados e subsequentemente executados. Em vez disso, os referendos devem satisfazer uma série de condições antes de serem chamados de estado de “decisão” e, até entrarem neste estado, permanecem indecisos.
Três condições precisam ser atendidas: Primeiro, todos os referendos têm um período de preparação. Esse é o tempo que deve passar após a proposta. Isto dá tempo para um período de aviso inicial para que os votos possam ser apresentados, evitando a possibilidade de um "tiro de decisão", no qual um invasor que controla um grande número de direitos de voto poderia tentar aprovar uma proposta logo após ela ser submetida, impedindo em bloco votação As pessoas têm tempo para pensar e votar.
Em segundo lugar, deve haver espaço para a tomada de decisões. Todas as faixas têm seus próprios limites quanto ao número de referendos que podem ser decididos simultaneamente. Quanto mais poderoso (por exemplo, mais perigoso!) o Origin puder executar na pista, menor será esse limite. A origem do nível raiz é limitada a 1, o que significa que apenas uma proposta superperigosa pode ser decidida por vez. Em contraste, a faixa de tombamento bastante fraca é muito mais restritiva, já que qualquer dano que possa ser causado por decisões excessivas é mínimo, e ter muitas chamadas no nível raiz é mais útil. Quando houver espaço disponível, os referendos (de outra forma elegíveis) para as categorias com as aprovações mais favoráveis serão elevados ao status de decisão.
Por fim, o depósito da decisão deverá ser pago. Criar um referendo é barato, exigindo apenas um depósito associado ao armazenamento on-chain necessário para rastreá-lo. No entanto, permitir que os referendos sejam decididos acarreta maiores riscos e utiliza espaço limitado porque limitamos o número de referendos que podem ser decididos em cada via simultaneamente. Portanto, um depósito maior (embora reembolsável) deve ser feito para mitigar o risco de spam ou inchaço do sistema.
Decidir e confirmar propostas
Quando um referendo atinge o status de tomada de decisão, ele se torna elegível para aprovação. Esta qualificação é válida apenas por um tempo limitado (28 dias no Polkadot), após o qual, se não for aprovada, será negada por padrão. Para ser aprovado, deve atender a dois critérios (neste caso, chamamos de “aprovação”), e deve continuar atendendo a esses critérios por um período mínimo de tempo durante o período de confirmação. Órbitas diferentes têm períodos de confirmação diferentes, com órbitas mais poderosas demorando mais para serem confirmadas. Esta é uma defesa adicional para evitar que os eleitores das baleias “disparem” no referendo através de uma votação suficientemente grande.
Dois critérios de aprovação estão relacionados à aprovação e ao suporte. O preconceito adaptativo do quórum dos referendos anteriores já não existe. Agora temos um sistema mais flexível que pode adaptar estes requisitos a um nível mais granular. A aprovação é definida como a parcela do peso do voto de aprovação (ou seja, ajustado pela crença) do peso total dos votos (pesos dos votos para aprovação e rejeição). Apoio é o número total de votos em aprovação (ou seja, ignorando ajustes nas crenças) comparado ao número total de votos que poderiam ter sido gerados no sistema.
Cada categoria de referendo tem requisitos diferentes para esses valores. O mais interessante, porém, é que essas exigências podem ser reduzidas gradativamente de acordo com um cronograma bem definido. Isso significa que à medida que a votação avança ao longo dos 28 dias, podemos configurar as coisas para que o apoio e a aprovação geral necessários para que uma proposta seja aprovada sejam menores. De um modo geral, começarão e terminarão sempre da mesma forma, começando com o limiar mais elevado e terminando com o limiar mais baixo que ainda respeite o princípio geral: é necessária pelo menos 50% de aprovação.
O que acontece no meio determina o quão fácil será ser aprovado antes do prazo de 28 dias. Para propostas que utilizam Origens menos privilegiadas (como a categoria Tip, que só pode solicitar pagamentos de até 10 DOT do tesouro), seria mais razoável reduzir os votos exigidos mais cedo. Propostas que utilizam categorias altamente privilegiadas, como Root, terão maior probabilidade de receber menos controvérsia no início (e, portanto, exigirão maior aprovação).
Após aprovação
Após 28 dias, as propostas não aprovadas são consideradas rejeitadas por defeito. Neste ponto, o depósito da decisão pode ser reembolsado. Por outro lado, se uma proposta conseguir ser aprovada e permanecer aprovada durante esses 28 dias, ela será considerada aprovada e programada para ser implementada pela Origem devidamente proponente dentro de um determinado período de implementação após ter sido proposta.
O período de implementação também é especificado quando a proposta é feita, mas depende da via. Algumas das vias mais robustas exigirão períodos de implementação mais longos para garantir que a rede tenha tempo suficiente para se preparar para quaisquer alterações que a proposta possa trazer.
#intervenção
Às vezes acontece que uma proposta que já está em votação (talvez já aprovada) contém problemas e você deseja cancelá-la. Um exemplo seria uma atualização em cadeia que posteriormente descobriu conter algum tipo de problema. Embora isso não seja muito comum, também não é inédito.
No Gov2, existe uma operação especial chamada Intervenção de cancelamento. Tal acção rejeitaria imediatamente um referendo em curso, independentemente do seu estatuto. Na verdade, apresenta-se em duas formas, uma das quais apenas realiza operações básicas e a outra que também reduz o valor do depósito que o proponente paga ao referendo.
O cancelamento em si é uma operação de governança que deve ser votada pela rede para ser executada. Isto levanta possíveis problemas com os prazos, na medida em que, para ser útil, uma proposta para que uma proposta de cancelamento seja aprovada rapidamente deve geralmente ser aprovada muito mais rapidamente do que uma provável proposta alvo. Como tal, o Cancelamento tem origem e pista próprias, com tempos de arranque mais baixos e uma curva de aprovação/apoio ligeiramente mais acentuada para ultrapassar barreiras.
Delegação flexível
Num mundo perfeito, onde todos tivessem tempo e competências ilimitadas, cada proposta seria pesquisada, discutida, considerada e votada cuidadosamente. Porém, em um mundo perfeito, não vivemos. Nem todo mundo tem tempo ou vontade de pesquisar cada questão em profundidade. Desta constatação surgiu o Conselho, a governação original de Polkadot: um órgão nomeado pelos eleitores para compensar o facto de muitos deles não estarem dispostos a participar na governação quotidiana. No entanto, com os conselhos eliminados no Gov2, precisamos de um meio alternativo de garantir que as vozes dos eleitores “passivos” sejam ouvidas.
O sistema de governança original tinha um recurso chamado delegação de voto, que mantivemos e melhoramos no Gov2. Para quem não conhece, isto é semelhante à premissa da democracia líquida: você pode delegar seu voto a outro eleitor do sistema. Quando os seus representantes votam, eles não são apenas donos do seu voto, mas também do seu voto. Isso funciona em conjunto com a Votação por Condenação, permitindo que você bloqueie seus tokens para aumentar o nível de poder de voto que seu delegado tem ao votar em seu nome. É claro que os tokens envolvidos nunca saem do seu controle e você pode trocar de representante ou recuperar o controle direto a qualquer momento.
No Gov2, entretanto, isso foi melhorado por meio de um recurso especial chamado Multirole Delegation. Isto permite-lhe especificar um representante diferente para cada categoria de referendo no seu sistema. Se não quiser delegar para uma categoria específica do referendo, você também pode manter o controle direto dessa categoria.
Isso significa que você pode delegar um trabalho a um indivíduo para quaisquer propostas em que os contribuidores do ecossistema recebam dicas, outra entidade para propostas com maiores gastos financeiros e outra entidade para propostas puramente técnicas de atualizações e parametrização de rede, e manter o controle direto sobre quaisquer outras decisões. !
Grupo acadêmico e lista de permissões
Em qualquer sistema de governação que funcione bem, a opinião de “especialistas” bem informados desempenha um papel importante. A governação especializada traz as suas próprias falhas graves, por isso não queremos que os “especialistas” sejam colocados numa posição de comando: isto introduz a centralização, a autoridade irresponsável e a base que pode acabar por se tornar o núcleo da dominação. Esta é a razão lógica pela qual o comité técnico originalmente governado por Polkadot não tem “poder de decisão”.
Seu nome é Polkadot Fellowship, que é chamada de “Academia” em Gov2. Os Fellows desempenham uma função na rede e não são responsáveis pela decisão final sobre a implementação de uma proposta. Em vez disso, apoiam o processo de governação, monitorizando e fazendo recomendações sobre aspectos técnicos, de conformidade, de risco e outros aspectos das propostas candidatas. A proposta é opcional, não obrigatória, e pode ser adotada ou ignorada pelo referendo.
Os Fellows não são anónimos e são convidados a divulgar as suas identidades para aumentar a transparência e a responsabilização. Este é um dos papéis do grupo acadêmico no Gov2.
O Gov2 também introduz um mecanismo denominado “lista branca” que permite a um grupo de entidades do sistema obter poderes especiais de governação. Isso pode ser usado para diversos fins, incluindo a introdução de novos membros ao ecossistema, recompensando contribuidores do ecossistema ou outros usos semelhantes. O mecanismo de lista branca é altamente configurável e a comunidade pode decidir como usá-lo.
para concluir
No geral, o Gov2 é uma grande melhoria na governação Polkadot, visando resolver problemas no sistema existente e melhorar a inclusão, eficiência e transparência da governação. Introduz uma série de novos recursos, como multitrack, origem, lista branca e grupo acadêmico, bem como um sistema de eleição de delegações mais flexível para melhor atender às diferentes necessidades de governança.
O objectivo deste sistema é reforçar a governação descentralizada, garantir a segurança de todos os participantes e melhorar a qualidade e a quantidade da tomada de decisões públicas. Fornece ferramentas mais fortes para o desenvolvimento futuro do ecossistema Polkadot para garantir o seu sucesso e sustentabilidade a longo prazo.
Autor: Gavin Wood