Polkadot adotou um mecanismo de governança sofisticado que pode evoluir de forma elegante com base nas necessidades dos stakeholders. O seu objetivo é garantir que a maioria dos interesses possa sempre controlar a rede.
O conteúdo deste artigo pode estar sujeito a alterações. O protocolo de governança já passou por várias iterações (v1 e v2), e haverá mais alterações no futuro (v2.5).
O primeiro sistema de governança descentralizada do Polkadot (v1) é composto por três componentes principais:
Comissão Técnica: Gestão do Cronograma de Atualização
Conselho: um "governo" eleito, responsável pela gestão de parâmetros, gestão e propostas de gastos.
Referendo: voto universal sobre todos os outros assuntos, com os principais interessados a terem maior influência.
Este sistema funcionou bem no início da operação, ajudando a utilizar os fundos do tesouro de forma razoável e a atualizar e reparar rapidamente. No entanto, à medida que o sistema amadurece, é necessário melhorar continuamente as deficiências e acompanhar os progressos. Por exemplo, na "governança v1", todos os pesos de votação eram iguais, e apenas era possível votar em uma proposta por vez, com um período de votação que podia durar várias semanas. Isso levou o sistema a se concentrar cuidadosamente em um número muito limitado de propostas, em vez de considerar amplamente várias propostas. Assim, surgiu a "governança v2".
"Governança v2" ou "Gov2" alterou a forma como as decisões são tomadas diariamente, tornando os referendos mais amplos e ágeis, aumentando significativamente o número de decisões coletivas que o sistema pode tomar.
Após a revisão profissional final do código, o Gov2 será lançado no Kusama. Após os testes no Kusama, será apresentada uma proposta para a sua implantação no Polkadot.
A seguir, serão apresentados os princípios centrais de governança da rede Polkadot. Compreender as raízes da governança v1 ajuda a entender melhor a direção da segunda iteração. Essas diferenças e distinções serão destacadas em vários subtópicos.
É importante notar que, nesta fase atual, a governança ainda é um protocolo em constante desenvolvimento. Com a atualização da governança v2 a entrar na rede, um plano para a governança v2.5 também está em elaboração.
premissa
Em resumo, a rede reúne vários mecanismos inovadores, incluindo funções de transição de estado não tipadas armazenadas na cadeia e definidas em WebAssembly, bem como vários mecanismos de votação na cadeia, como referendos com limiares de maioria absoluta adaptativa e mecanismos de votação de aprovação em massa.
Todas as alterações ao protocolo devem ser acordadas através de um referendo ponderado por direitos.
mecanismo
Na governança v1, os detentores de tokens ativos e o conselho gerenciam conjuntamente as decisões de atualização da rede. Independentemente de a proposta ser feita pelos detentores de tokens ( do público ) ou pelo conselho, ela deve passar por um referendo de todos os detentores, onde a quantidade de tokens em stake e o valor de crença são usados como pesos para a decisão.
A governança v2 teve algumas mudanças. A nova forma de governança que reflete as características de descentralização é:
Transferir todas as responsabilidades do conselho para os detentores de tokens através de votação democrática
Dissolver o atual conselho de administração coletivo
Permitir que os usuários deleguem direitos de voto a membros da comunidade de mais maneiras.
O conselho no Gov1 desempenhou os papéis de representante dos detentores passivos de tokens, guardião do tesouro e iniciador da legislação, mas geralmente é visto como uma entidade centralizada. Para descentralizar ainda mais a rede, o Gov2 propõe devolver as responsabilidades do conselho à comunidade.
referendo
O referendo é uma solução de votação simples, inclusiva e baseada em staking. Cada referendo tem uma proposta específica, utilizando o formato de chamada de função de privilégio de runtime (, que inclui a chamada set_code mais poderosa, capaz de alternar todo o código de runtime ).
Um referendo é um evento discreto com um período de votação fixo. Após o término do período de votação e a contagem dos votos, se aprovado, será chamada a função correspondente. O referendo é sempre binário; as escolhas podem ser "a favor", "contra" ou uma abstenção total.
No governo v1, os referendos podem ser iniciados por uma das seguintes maneiras:
Proposta submetida publicamente
Propostas aprovadas por maioria ou unanimidade do conselho
Proposta submetida como parte da execução do referendo anterior
Proposta de emergência submetida pelo comitê técnico e aprovada pelo conselho de administração
Todas as votações têm um período de atraso correspondente para execução. Este é o período de tempo entre o término da votação e a execução real da proposta (, se aprovada ).
Se o referendo for encerrado e a contagem for concluída, será considerado como concluído. Supondo que a proposta seja aprovada, ela será programada para execução. Se o referendo estiver à espera de resultados ou estiver a ser votado, será considerado como não concluído.
Se a proposta for apresentada pelo público ou pelo conselho, haverá um prazo fixo de 28 dias para a execução. Propostas apresentadas como parte da execução de um referendo anterior podem ter um prazo de execução definido conforme necessário. O tratamento de propostas urgentes requer questões significativas que necessitam de "seguimento rápido", reduzindo assim o tempo de execução.
No Gov2, qualquer pessoa pode iniciar um referendo a qualquer momento e pode iniciar múltiplos referendos. O Gov2 introduziu novas funcionalidades de Origins(, fontes) e Tracks(, trilhos), para ajudar no fluxo e processamento do protocolo de referendo.
Origin pode ser visto como um rico descritor do nível de privilégio dado. O proponente agora deve escolher o Origin adequado para o pedido com base nos requisitos da proposta.
Cada Origin está associado a uma categoria de referendo, e cada categoria está associada a um Track. O Track descreve o ciclo de vida da proposta e é independente dos Tracks de outras categorias. Ter diferentes Tracks independentes permite que a rede ajuste a dinâmica do referendo com base nos níveis de privilégio implícitos.
Por exemplo, o impacto da chamada set_code ( na atualização do Runtime ) no ecossistema é diferente da aprovação da taxa de tesouraria ( na chamada reportAwesome ), portanto, são necessárias origens diferentes, onde diferentes taxas de votação, taxas de aprovação, depósitos e o ciclo de execução mais curto serão pré-determinados no pallet.
Proposta de Referendo
Referendo público
Qualquer pessoa pode propor um referendo ao depositar a quantidade mínima de tokens dentro de um certo período ( número de blocos ). Se alguém concordar com a proposta, pode depositar a mesma quantidade de tokens para mostrar apoio.
Esta operação é chamada de "endosse". A proposta com o maior suporte de tokens vinculados será selecionada para o próximo ciclo de votação. Note que isso pode ser diferente do número absoluto de endossos; por exemplo, três contas vinculando 20 DOT cada uma "superarão" a eficácia de dez contas vinculando 1 DOT cada.
Uma vez que a proposta é submetida (, a votação será iniciada ), e o token vinculado será liberado.
Para a governança v1, a fila de propostas pode ter até 100 propostas públicas.
No Gov2, quando um referendo é criado, a comunidade pode votar imediatamente. No entanto, o referendo não está em um estado que permita encerrar ou contar os votos, ser aprovado e finalmente executado. Em vez disso, o referendo deve atender a alguns critérios para entrar no estado "decidindo (Decidindo)". Antes de entrar nesse estado, ainda se encontra em estado pendente.
Os critérios para entrar no estado Decided são os seguintes:
Passou pelo período de implementação ( lead-in period ), que é o tempo que deve ser cumprido antes que uma decisão possa ser iniciada. Isso ajuda a reduzir a possibilidade de "sniping de decisões", onde um atacante com controle sobre uma quantidade significativa de direitos de voto pode aprovar uma proposta imediatamente após a sugestão, em vez de permitir que todos os votantes tenham tempo suficiente para considerar e participar.
Deve haver ainda espaço restante para a decisão. Todos os Track têm limitações na quantidade de referendos que podem ser decididos simultaneamente. Tracks com capacidades mais robustas têm limites mais baixos. Por exemplo, o limite do nível Root Origin é 1, ou seja, apenas uma proposta super perigosa pode ser decidida de cada vez.
É necessário pagar um depósito de decisão. O custo para criar um referendo é muito baixo, pois o valor do depósito inclui apenas o valor necessário para o armazenamento em cadeia que é necessário para o rastreamento. No entanto, há o risco de esgotar as posições limitadas na fila de referendos ao revisar e decidir sobre eles. Exigir um depósito maior, mas reembolsável, ajuda a reduzir o spam.
Referendo do Conselho (v1)
Aprovado por unanimidade pelo Conselho - Quando todos os membros do Conselho concordam com uma proposta, ela pode ser submetida a referendo. Este referendo resultará em uma desvio de taxa de voto negativo (, ou seja, quanto menor o número de votos de direitos, menor será o número necessário para aprovação - consulte o viés adaptativo do grupo ).
Aprovado pela maioria do conselho - Quando apenas a maioria simples dos membros do conselho concorda, também é possível votar em referendos, mas será um sistema de maioria, em que a parte que obtiver 51% dos votos vence (.
Em qualquer momento, só pode haver um referendo válido, a menos que haja um referendo de emergência em andamento.
Cronograma de Votação
Na Governance v1, assumindo que há pelo menos uma proposta em uma das filas, uma nova votação será realizada a cada 28 dias. Há uma fila para as propostas aprovadas pelo conselho e outra para as propostas submetidas pelo público. A votação será alternada entre as propostas em primeiro lugar de ambas as filas.
As propostas mais bem classificadas são determinadas pela quantidade de staking vinculada a elas. Se a fila atual tentar criar um referendo sem propostas ) e outra fila tiver propostas em espera, a proposta mais bem classificada na outra fila entrará no referendo.
Não é possível votar em várias referendos ao mesmo tempo, exceto em referendos de emergência. Referendos de emergência que ocorrem simultaneamente com referendos regulares ( ou propostas do conselho ) são a única situação em que é possível votar em várias referendos ao mesmo tempo.
Quando a proposta for aprovada, a governança v2 partilhará o mesmo período de elegibilidade de 28 dias. Se a proposta não for aprovada até ao final deste período, será automaticamente rejeitada.
Referendo votação ( governança v2)
Na Governance v2, se a proposta atender aos requisitos de taxa de aprovação e taxa de suporte, a proposta será aprovada, ou seja, o sistema de viés de grupo adaptativo foi removido.
A taxa de aprovação ( é definida como o peso de voto aprovado ) após o ajuste da convicção (, que representa a proporção do peso total de votos ), incluindo as parcelas de aprovação e rejeição (.
A taxa de apoio )Suporte( é o número total de votos aprovados )ignorar o ajuste de condenação ( em comparação com o número total de votos que podem ser realizados no sistema.
Deve atender a este padrão no menor tempo possível do período de confirmação. Diferentes trilhas têm diferentes períodos de confirmação e requisitos de aprovação e apoio. Agora é configurável através da quantidade de apoio necessária e da aprovação geral. Para propostas que utilizam fontes de menor privilégio, é mais razoável reduzir a taxa de votação necessária para um número mais realista mais cedo, em comparação com propostas que utilizam categorias de alto privilégio ), como Root(. Propostas com maior significado político podem solicitar uma aprovação mais elevada mais cedo, para evitar controvérsias.
No Gov2, propostas não aprovadas após 28 dias serão consideradas como rejeitadas por padrão e o Depósito de Decisão será devolvido. Se a proposta conseguir manter a aprovação antes do término do período de confirmação, será considerada aprovada e planejada para ser executada a partir da fonte proposta após o período de elaboração. O período de elaboração é designado quando a proposta é votada por todos, mas também está sujeita a um mínimo baseado em trilhas. Trilhas mais robustas imporão um período de execução mais longo para garantir que a rede tenha tempo suficiente para se preparar para quaisquer mudanças que a proposta possa trazer.
Bloqueio voluntário
Polkadot usa o conceito de "bloqueio voluntário", permitindo que os detentores de tokens aumentem seus direitos de voto declarando a duração que desejam bloquear seus tokens. Assim, o número de votos de cada detentor de token será calculado usando a seguinte fórmula:
Número de votos = token * multiplicador de convicção
O número de períodos de bloqueio dobra a cada rodada, e o multiplicador de convicção aumentará o multiplicador de votos em um.
Período de bloqueio Multiplicador de votos
0 1
1 2
2 3
4 4
8 5
16 6
32 6
O número máximo de vezes que o "período de bloqueio" pode ser "duplicado" é 6), portanto, há um total de 32 períodos de bloqueio (, onde um período de bloqueio equivale a 28 dias. Apenas a duplicação é permitida, por exemplo, você não pode bloquear 24 ciclos e aumentar sua convicção em 5,5.
Após o token ser bloqueado, você ainda pode usá-lo para votar e fazer staking; você só está proibido de transferir esses tokens para outra conta.
Os votos são sempre "calculados" ao mesmo tempo, ou seja, no final do período de votação. Isso não é afetado pelo prazo de bloqueio dos tokens.
Viés de grupo adaptativo
O desvio adaptativo do grupo foi utilizado por mais tempo na Governance v2 e foi substituído pelo sistema de Aprovação/Suporte.
) Conselho
No governo v1, os participantes passivos na Polkadot são representados por uma entidade de gestão chamada "Conselho". O Conselho é uma entidade on-chain composta por vários participantes, cada um representando uma conta on-chain. Na Polkadot, o Conselho é atualmente composto por membros.
Além de controlar o tesouro, o conselho é também responsável por três tarefas principais de governança:
Referendo sábio
Cancelar referendos perigosos ou maliciosos
Comissão Técnica de Eleições
Na governança v2, é necessária uma estratégia alternativa para substituir as responsabilidades do conselho que anteriormente atuava como um órgão de delegação dos eleitores, a fim de compensar o fato de que muitas pessoas optam por não participar da governança diária. A Gov2 é construída sobre a funcionalidade de delegação de votos da v1, permitindo que os eleitores escolham delegar seus direitos de voto a outro eleitor no sistema. Isso é feito através da melhoria de uma função chamada delegação de múltiplos papéis, onde os eleitores podem designar representantes diferentes para cada categoria de referendo no sistema. Assim, por exemplo, um eleitor pode delegar uma entidade para gerenciar uma categoria de referendo de menor impacto, enquanto escolhe um representante diferente para gerenciar outra categoria com consequências mais significativas, mantendo ainda o direito de voto completo sobre quaisquer categorias restantes.
( Cancelar o referendo
Na governança v1, se o comitê técnico concordar unanimemente em cancelar a proposta, ou a origem Root ) se sudo### ativar essa funcionalidade, a proposta pode ser cancelada. O depósito da proposta cancelada será destruído.
Além disso, uma maioria de dois terços do conselho pode cancelar o referendo. Se um problema for encontrado tardiamente na proposta de referendo ###, como um erro no código runtime que a proposta irá executar (, isso pode ser usado como último recurso.
Se a controvérsia cancelada for grande o suficiente, para
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
19 gostos
Recompensa
19
9
Partilhar
Comentar
0/400
ShamedApeSeller
· 07-04 15:22
A gestão dessas coisas é só para fazer figura.
Ver originalResponder0
LiquidationKing
· 07-04 14:13
A DOT está fazendo grandes movimentos novamente?
Ver originalResponder0
LayerHopper
· 07-04 08:49
Todos os dias há atualizações, como fazer?
Ver originalResponder0
HodlNerd
· 07-01 15:56
a teoria dos jogos na governança é fixe... mas já viste a distribuição estatística da participação dos eleitores? meio preocupante, para ser honesto
Ver originalResponder0
BearMarketSurvivor
· 07-01 15:56
Ainda é apenas a nova armadilha para fazer as pessoas de parvas.
Ver originalResponder0
GhostChainLoyalist
· 07-01 15:42
Quando é que podemos realmente ter Descentralização?
Ver originalResponder0
CryptoMotivator
· 07-01 15:40
Mudou para a v2.5 e tudo ficou agitado?
Ver originalResponder0
BackrowObserver
· 07-01 15:40
Não consigo suportar, é demais para eu lembrar...
Ver originalResponder0
CoconutWaterBoy
· 07-01 15:39
Governança v2? É melhor adicionar um DAO comunitário.
Polkadot Governance V2: A Evolução da Tomada de Decisão Descentralizada
Governança V2
Polkadot adotou um mecanismo de governança sofisticado que pode evoluir de forma elegante com base nas necessidades dos stakeholders. O seu objetivo é garantir que a maioria dos interesses possa sempre controlar a rede.
O conteúdo deste artigo pode estar sujeito a alterações. O protocolo de governança já passou por várias iterações (v1 e v2), e haverá mais alterações no futuro (v2.5).
O primeiro sistema de governança descentralizada do Polkadot (v1) é composto por três componentes principais:
Este sistema funcionou bem no início da operação, ajudando a utilizar os fundos do tesouro de forma razoável e a atualizar e reparar rapidamente. No entanto, à medida que o sistema amadurece, é necessário melhorar continuamente as deficiências e acompanhar os progressos. Por exemplo, na "governança v1", todos os pesos de votação eram iguais, e apenas era possível votar em uma proposta por vez, com um período de votação que podia durar várias semanas. Isso levou o sistema a se concentrar cuidadosamente em um número muito limitado de propostas, em vez de considerar amplamente várias propostas. Assim, surgiu a "governança v2".
"Governança v2" ou "Gov2" alterou a forma como as decisões são tomadas diariamente, tornando os referendos mais amplos e ágeis, aumentando significativamente o número de decisões coletivas que o sistema pode tomar.
Após a revisão profissional final do código, o Gov2 será lançado no Kusama. Após os testes no Kusama, será apresentada uma proposta para a sua implantação no Polkadot.
A seguir, serão apresentados os princípios centrais de governança da rede Polkadot. Compreender as raízes da governança v1 ajuda a entender melhor a direção da segunda iteração. Essas diferenças e distinções serão destacadas em vários subtópicos.
É importante notar que, nesta fase atual, a governança ainda é um protocolo em constante desenvolvimento. Com a atualização da governança v2 a entrar na rede, um plano para a governança v2.5 também está em elaboração.
premissa
Em resumo, a rede reúne vários mecanismos inovadores, incluindo funções de transição de estado não tipadas armazenadas na cadeia e definidas em WebAssembly, bem como vários mecanismos de votação na cadeia, como referendos com limiares de maioria absoluta adaptativa e mecanismos de votação de aprovação em massa.
Todas as alterações ao protocolo devem ser acordadas através de um referendo ponderado por direitos.
mecanismo
Na governança v1, os detentores de tokens ativos e o conselho gerenciam conjuntamente as decisões de atualização da rede. Independentemente de a proposta ser feita pelos detentores de tokens ( do público ) ou pelo conselho, ela deve passar por um referendo de todos os detentores, onde a quantidade de tokens em stake e o valor de crença são usados como pesos para a decisão.
A governança v2 teve algumas mudanças. A nova forma de governança que reflete as características de descentralização é:
O conselho no Gov1 desempenhou os papéis de representante dos detentores passivos de tokens, guardião do tesouro e iniciador da legislação, mas geralmente é visto como uma entidade centralizada. Para descentralizar ainda mais a rede, o Gov2 propõe devolver as responsabilidades do conselho à comunidade.
referendo
O referendo é uma solução de votação simples, inclusiva e baseada em staking. Cada referendo tem uma proposta específica, utilizando o formato de chamada de função de privilégio de runtime (, que inclui a chamada set_code mais poderosa, capaz de alternar todo o código de runtime ).
Um referendo é um evento discreto com um período de votação fixo. Após o término do período de votação e a contagem dos votos, se aprovado, será chamada a função correspondente. O referendo é sempre binário; as escolhas podem ser "a favor", "contra" ou uma abstenção total.
No governo v1, os referendos podem ser iniciados por uma das seguintes maneiras:
Todas as votações têm um período de atraso correspondente para execução. Este é o período de tempo entre o término da votação e a execução real da proposta (, se aprovada ).
Se o referendo for encerrado e a contagem for concluída, será considerado como concluído. Supondo que a proposta seja aprovada, ela será programada para execução. Se o referendo estiver à espera de resultados ou estiver a ser votado, será considerado como não concluído.
Se a proposta for apresentada pelo público ou pelo conselho, haverá um prazo fixo de 28 dias para a execução. Propostas apresentadas como parte da execução de um referendo anterior podem ter um prazo de execução definido conforme necessário. O tratamento de propostas urgentes requer questões significativas que necessitam de "seguimento rápido", reduzindo assim o tempo de execução.
No Gov2, qualquer pessoa pode iniciar um referendo a qualquer momento e pode iniciar múltiplos referendos. O Gov2 introduziu novas funcionalidades de Origins(, fontes) e Tracks(, trilhos), para ajudar no fluxo e processamento do protocolo de referendo.
Origin pode ser visto como um rico descritor do nível de privilégio dado. O proponente agora deve escolher o Origin adequado para o pedido com base nos requisitos da proposta.
Cada Origin está associado a uma categoria de referendo, e cada categoria está associada a um Track. O Track descreve o ciclo de vida da proposta e é independente dos Tracks de outras categorias. Ter diferentes Tracks independentes permite que a rede ajuste a dinâmica do referendo com base nos níveis de privilégio implícitos.
Por exemplo, o impacto da chamada set_code ( na atualização do Runtime ) no ecossistema é diferente da aprovação da taxa de tesouraria ( na chamada reportAwesome ), portanto, são necessárias origens diferentes, onde diferentes taxas de votação, taxas de aprovação, depósitos e o ciclo de execução mais curto serão pré-determinados no pallet.
Proposta de Referendo
Referendo público
Qualquer pessoa pode propor um referendo ao depositar a quantidade mínima de tokens dentro de um certo período ( número de blocos ). Se alguém concordar com a proposta, pode depositar a mesma quantidade de tokens para mostrar apoio.
Esta operação é chamada de "endosse". A proposta com o maior suporte de tokens vinculados será selecionada para o próximo ciclo de votação. Note que isso pode ser diferente do número absoluto de endossos; por exemplo, três contas vinculando 20 DOT cada uma "superarão" a eficácia de dez contas vinculando 1 DOT cada.
Uma vez que a proposta é submetida (, a votação será iniciada ), e o token vinculado será liberado.
Para a governança v1, a fila de propostas pode ter até 100 propostas públicas.
No Gov2, quando um referendo é criado, a comunidade pode votar imediatamente. No entanto, o referendo não está em um estado que permita encerrar ou contar os votos, ser aprovado e finalmente executado. Em vez disso, o referendo deve atender a alguns critérios para entrar no estado "decidindo (Decidindo)". Antes de entrar nesse estado, ainda se encontra em estado pendente.
Os critérios para entrar no estado Decided são os seguintes:
Referendo do Conselho (v1)
Aprovado por unanimidade pelo Conselho - Quando todos os membros do Conselho concordam com uma proposta, ela pode ser submetida a referendo. Este referendo resultará em uma desvio de taxa de voto negativo (, ou seja, quanto menor o número de votos de direitos, menor será o número necessário para aprovação - consulte o viés adaptativo do grupo ).
Aprovado pela maioria do conselho - Quando apenas a maioria simples dos membros do conselho concorda, também é possível votar em referendos, mas será um sistema de maioria, em que a parte que obtiver 51% dos votos vence (.
Em qualquer momento, só pode haver um referendo válido, a menos que haja um referendo de emergência em andamento.
Cronograma de Votação
Na Governance v1, assumindo que há pelo menos uma proposta em uma das filas, uma nova votação será realizada a cada 28 dias. Há uma fila para as propostas aprovadas pelo conselho e outra para as propostas submetidas pelo público. A votação será alternada entre as propostas em primeiro lugar de ambas as filas.
As propostas mais bem classificadas são determinadas pela quantidade de staking vinculada a elas. Se a fila atual tentar criar um referendo sem propostas ) e outra fila tiver propostas em espera, a proposta mais bem classificada na outra fila entrará no referendo.
Não é possível votar em várias referendos ao mesmo tempo, exceto em referendos de emergência. Referendos de emergência que ocorrem simultaneamente com referendos regulares ( ou propostas do conselho ) são a única situação em que é possível votar em várias referendos ao mesmo tempo.
Quando a proposta for aprovada, a governança v2 partilhará o mesmo período de elegibilidade de 28 dias. Se a proposta não for aprovada até ao final deste período, será automaticamente rejeitada.
Referendo votação ( governança v2)
Na Governance v2, se a proposta atender aos requisitos de taxa de aprovação e taxa de suporte, a proposta será aprovada, ou seja, o sistema de viés de grupo adaptativo foi removido.
A taxa de aprovação ( é definida como o peso de voto aprovado ) após o ajuste da convicção (, que representa a proporção do peso total de votos ), incluindo as parcelas de aprovação e rejeição (.
A taxa de apoio )Suporte( é o número total de votos aprovados )ignorar o ajuste de condenação ( em comparação com o número total de votos que podem ser realizados no sistema.
Deve atender a este padrão no menor tempo possível do período de confirmação. Diferentes trilhas têm diferentes períodos de confirmação e requisitos de aprovação e apoio. Agora é configurável através da quantidade de apoio necessária e da aprovação geral. Para propostas que utilizam fontes de menor privilégio, é mais razoável reduzir a taxa de votação necessária para um número mais realista mais cedo, em comparação com propostas que utilizam categorias de alto privilégio ), como Root(. Propostas com maior significado político podem solicitar uma aprovação mais elevada mais cedo, para evitar controvérsias.
No Gov2, propostas não aprovadas após 28 dias serão consideradas como rejeitadas por padrão e o Depósito de Decisão será devolvido. Se a proposta conseguir manter a aprovação antes do término do período de confirmação, será considerada aprovada e planejada para ser executada a partir da fonte proposta após o período de elaboração. O período de elaboração é designado quando a proposta é votada por todos, mas também está sujeita a um mínimo baseado em trilhas. Trilhas mais robustas imporão um período de execução mais longo para garantir que a rede tenha tempo suficiente para se preparar para quaisquer mudanças que a proposta possa trazer.
Bloqueio voluntário
Polkadot usa o conceito de "bloqueio voluntário", permitindo que os detentores de tokens aumentem seus direitos de voto declarando a duração que desejam bloquear seus tokens. Assim, o número de votos de cada detentor de token será calculado usando a seguinte fórmula:
Número de votos = token * multiplicador de convicção
O número de períodos de bloqueio dobra a cada rodada, e o multiplicador de convicção aumentará o multiplicador de votos em um.
Período de bloqueio Multiplicador de votos 0 1 1 2 2 3 4 4 8 5 16 6 32 6
O número máximo de vezes que o "período de bloqueio" pode ser "duplicado" é 6), portanto, há um total de 32 períodos de bloqueio (, onde um período de bloqueio equivale a 28 dias. Apenas a duplicação é permitida, por exemplo, você não pode bloquear 24 ciclos e aumentar sua convicção em 5,5.
Após o token ser bloqueado, você ainda pode usá-lo para votar e fazer staking; você só está proibido de transferir esses tokens para outra conta.
Os votos são sempre "calculados" ao mesmo tempo, ou seja, no final do período de votação. Isso não é afetado pelo prazo de bloqueio dos tokens.
Viés de grupo adaptativo
O desvio adaptativo do grupo foi utilizado por mais tempo na Governance v2 e foi substituído pelo sistema de Aprovação/Suporte.
) Conselho
No governo v1, os participantes passivos na Polkadot são representados por uma entidade de gestão chamada "Conselho". O Conselho é uma entidade on-chain composta por vários participantes, cada um representando uma conta on-chain. Na Polkadot, o Conselho é atualmente composto por membros.
Além de controlar o tesouro, o conselho é também responsável por três tarefas principais de governança:
Na governança v2, é necessária uma estratégia alternativa para substituir as responsabilidades do conselho que anteriormente atuava como um órgão de delegação dos eleitores, a fim de compensar o fato de que muitas pessoas optam por não participar da governança diária. A Gov2 é construída sobre a funcionalidade de delegação de votos da v1, permitindo que os eleitores escolham delegar seus direitos de voto a outro eleitor no sistema. Isso é feito através da melhoria de uma função chamada delegação de múltiplos papéis, onde os eleitores podem designar representantes diferentes para cada categoria de referendo no sistema. Assim, por exemplo, um eleitor pode delegar uma entidade para gerenciar uma categoria de referendo de menor impacto, enquanto escolhe um representante diferente para gerenciar outra categoria com consequências mais significativas, mantendo ainda o direito de voto completo sobre quaisquer categorias restantes.
( Cancelar o referendo
Na governança v1, se o comitê técnico concordar unanimemente em cancelar a proposta, ou a origem Root ) se sudo### ativar essa funcionalidade, a proposta pode ser cancelada. O depósito da proposta cancelada será destruído.
Além disso, uma maioria de dois terços do conselho pode cancelar o referendo. Se um problema for encontrado tardiamente na proposta de referendo ###, como um erro no código runtime que a proposta irá executar (, isso pode ser usado como último recurso.
Se a controvérsia cancelada for grande o suficiente, para