Polkadot adotou um mecanismo de governança sofisticado que lhe permite evoluir continuamente com base nas necessidades das partes interessadas. O objetivo é garantir que a maioria das participações possa sempre controlar a rede.
O conteúdo deste artigo pode sofrer alterações. O protocolo de governança já passou por várias iterações (v1 e v2), e haverá mais mudanças no futuro (v2.5).
O primeiro sistema de governança descentralizada da Polkadot (v1) é composto por três componentes principais:
Comissão Técnica: Gerir o cronograma de atualização
Conselho: órgão executivo eleito que "governa", responsável pela gestão de parâmetros, gestão e propostas de despesas.
Referendo: sistema de votação universal, que confere maior influência aos stakeholders de longo prazo
O sistema funcionou bem nos primeiros anos, mas à medida que amadurecia, precisou evoluir constantemente para melhorar suas deficiências e acompanhar os avanços. Por exemplo, na "governança v1", todos os pesos dos referendos eram iguais, e só era possível votar em um referendo de cada vez, com um período de votação que poderia durar várias semanas. Isso levou o sistema a se concentrar em considerar cuidadosamente 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 diárias são tomadas, tornando os referendos mais abrangentes e ágeis, aumentando assim significativamente o número de decisões coletivas que o sistema pode fazer.
O Gov2 será lançado e testado na Kusama antes de ser proposto para implantação na Polkadot. Atualmente, o Gov2 já está ativo na rede Kusama.
O seguinte conteúdo apresentará os princípios centrais de governança da rede Polkadot. Compreender as raízes da governança v1 ajudará a entender melhor a direção da segunda iteração. Essas diferenças serão destacadas em vários subtemas.
É importante notar que, nesta fase atual, a governança ainda é um protocolo em constante desenvolvimento. Com a atualização da governança v2, o 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 conversão de estado amorfo armazenadas na cadeia definidas em WebAssembly (, bem como vários mecanismos de votação na cadeia, como referendos com um limiar de maioria absoluta adaptativa e votação de aprovação em massa.
Todas as alterações ao protocolo devem ser acordadas através de um referendo ponderado por direitos de voto.
) mecanismo
Na governança v1, os detentores de tokens ativos e o conselho gerem em conjunto as decisões de atualização da rede. Independentemente de a proposta ser apresentada pelo público ou pelo conselho, a decisão final deve passar por um referendo popular, com o valor da participação e da fé a servirem como pesos na decisão.
A governança v2 teve algumas mudanças. A nova forma de governança reflete características de descentralização da seguinte maneira:
Transferir a responsabilidade do conselho para os detentores de token através de votação democrática
Dissolver o atual conselho diretivo
Permitir que os usuários deleguem os seus direitos de voto a membros da comunidade de mais maneiras.
referendo
O referendo é uma solução de votação simples, inclusiva e baseada em staking. Cada referendo tem uma proposta relacionada, utilizando a chamada de função de privilégio de runtime ###, incluindo a chamada set_code mais poderosa, que pode 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 for aprovado, serão chamadas as funções relevantes. Um referendo é sempre binário; as opções de votação só podem ser "a favor", "contra" ou completamente abstenção.
Na governança v1, a votação pode ser iniciada de várias maneiras:
Propostas submetidas publicamente
Proposta aprovada por maioria ou unanimidade do conselho
Proposta apresentada como parte da execução do referendo anterior
Proposta de emergência submetida pelo comitê técnico e aprovada pelo conselho de administração
Todos os referendos têm um período de atraso de execução correspondente. Este é o tempo entre o término do referendo e a execução real da proposta.
No Gov2, qualquer pessoa pode iniciar um referendo a qualquer momento, sem limite de vezes. O Gov2 introduz os conceitos de Origins) e Tracks( para ajudar no fluxo e processamento do protocolo de referendo.
Origin pode ser considerado um descritor para um determinado nível de privilégios. O proponente precisa escolher o Origin apropriado com base nos requisitos da proposta.
Cada Origem está associada a uma categoria de referendo, e cada categoria tem uma Trilha. A Trilha descreve o ciclo de vida da proposta e é independente de outras categorias. Diferentes trilhas independentes permitem que a rede ajuste a dinâmica do referendo com base nos níveis de privilégio implícitos.
Por exemplo, o impacto da atualização do Runtime no ecossistema é diferente da aprovação de gorjetas do tesouro, portanto, são necessárias diferentes Origens, nas quais diferentes taxas de votação, taxas de aprovação, depósitos e o período mínimo de execução serão previamente determinados.
) Proposta de Referendo
Referendo público
Qualquer pessoa pode propor um referendo depositando a quantidade mínima de tokens durante um determinado período. Se alguém concordar, pode depositar a mesma quantidade de tokens para expressar apoio.
Isto é chamado de "endorse". A proposta que obtiver o maior suporte de token vinculado 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 cada uma vinculando 20 DOT "superarão" dez contas cada uma vinculando 1 DOT.
Uma vez que a proposta é submetida ( para votação ), os tokens vinculados serão liberados.
Para a governança v1, pode haver até 100 propostas públicas na fila de propostas.
No Gov2, assim que o referendo é criado, a comunidade pode votar imediatamente. No entanto, o referendo não está em um estado que permita ser encerrado, contar os votos, obter aprovação e ser finalmente executado. Em vez disso, o referendo deve atender a alguns critérios para entrar no estado "decidir ###Decidindo (". Antes disso, ainda está em estado pendente.
Os critérios para entrar no estado Decided são os seguintes:
Passou pelo período de introdução, que é o tempo necessário antes de se poder começar a decidir. Isso ajuda a reduzir a possibilidade de "decisões precipitadas", ou seja, um atacante que controla uma grande quantidade de direitos de voto pode aprovar uma proposta imediatamente após a proposta ser apresentada, sem dar aos votantes tempo suficiente para considerar e participar.
Deve haver espaço restante para decisões. Todos os Traks têm limitações sobre o número de referendos que podem ser decididos simultaneamente. Traks mais poderosos têm limitações mais baixas. Por exemplo, a limitação do nível Root Origin é 1, o que significa que apenas 1 proposta superperigosa pode ser decidida de cada vez.
É necessário pagar um depósito para a decisão. O custo para criar um referendo é muito baixo, pois o depósito só inclui o valor necessário para o armazenamento em cadeia. No entanto, revisar e decidir sobre o referendo apresenta o risco de esgotar os limites de posições na fila do referendo. Exigir um depósito maior, mas reembolsável, ajuda a reduzir o spam.
Votação do Conselho )v1(
Aprovação unânime do conselho - Quando todos os membros do conselho concordam com uma proposta, esta pode ser submetida a referendo. Este referendo resultará em uma discrepância na 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 (.
Aprovação pela maioria do conselho - Quando apenas a maioria simples dos membros do conselho concorda, também pode haver votação em referendo, mas será pelo sistema de maioria, onde a parte que obtiver 51% dos votos vence.
Só pode haver um referendo válido a qualquer momento, a menos que haja um referendo de emergência em andamento.
Tabela de Votação
Na governança v1, se houver pelo menos uma proposta na fila, uma nova votação será realizada a cada 28 dias. As propostas aprovadas pelo conselho têm uma fila, assim como as propostas submetidas pelo público. A votação será alternada entre as propostas que estão no topo das duas filas.
As propostas com melhor classificação são determinadas pela quantidade de staking associada a elas. Se a fila atual tentar criar um referendo sem proposta, a fila ) estará vazia (, e se houver propostas na fila de outra fila, a proposta mais bem classificada dessa fila entrará no referendo.
Não é permitido votar em várias propostas de referendo ao mesmo tempo, exceto em referendos de emergência. Os referendos de emergência que ocorrem simultaneamente com referendos regulares são a única situação em que se pode votar em várias propostas de referendo ao mesmo tempo.
Quando a proposta for aprovada, a governança v2 partilha o mesmo período de elegibilidade de 28 dias. Se a proposta não for aprovada até ao final desta fase, será automaticamente rejeitada.
Referendo votação ) governança v2(
Na governança v2, se a proposta atender aos requisitos de taxa de aprovação e taxa de apoio, a proposta será aprovada, ou seja, o sistema de viés de grupo adaptativo será removido.
A taxa de aprovação ) é definida como o peso de voto aprovado ( após ajustes de convicção ) que representa a parte do peso total dos votos (, incluindo as partes aprovadas e rejeitadas ).
A taxa de apoio ( Support ) é o número total de votos aprovados ( ignorar o ajuste de convicção ) em comparação com o número total de votos que podem ser feitos no sistema.
Deve atender a este padrão no menor tempo possível durante o período de confirmação. Diferentes trilhos têm diferentes períodos de confirmação e requisitos de aprovação e suporte. Agora é possível configurar através da quantidade de suporte necessária e da aprovação geral. Para propostas que utilizam fontes de privilégio mais baixo, é 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). Cursos com maior significado político podem solicitar aprovação mais alta mais cedo para evitar controvérsias.
No Gov2, propostas que não forem 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 continuar aprovada antes do término do período de confirmação, será considerada aprovada e a execução começará a partir da fonte proposta após o período de formulação. O período de formulação é definido quando uma proposta de votação popular é feita, mas também está sujeito 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 as mudanças que a proposta pode trazer.
Bloqueio Voluntário
Polkadot utiliza o conceito de "bloqueio voluntário", permitindo que os detentores de tokens aumentem seu poder de voto ao declarar por quanto tempo estão dispostos a bloquear seus tokens. Assim, o número de votos de cada detentor de token será calculado pela seguinte fórmula:
Número de votos = token * multiplicador de convicção
O número de períodos de bloqueio dobra a cada vez, e o multiplicador de convicção aumentará o multiplicador de votos em um.
Multiplicador de votação do período de bloqueio 00.111224384165326
O número máximo de vezes que o "período de bloqueio" pode ser "duplicado" é 6( um total de 32 períodos de bloqueio ), um período de bloqueio equivale a 28 dias. Apenas a duplicação é permitida, por exemplo, não é possível bloquear 24 períodos e aumentar a convicção em 5,5.
Após o bloqueio do token, este ainda pode ser utilizado para votação e staking; apenas é proibido 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 período de bloqueio do token.
Bias de grupo adaptativo
O desvio adaptativo do grupo foi utilizado por mais tempo na governança v2 e foi substituído pelo sistema de Aprovação/Apoio.
( Conselho
Na governança v1, os stakeholders passivos na Polkadot são representados por um órgão de gestão chamado "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 nacional, o conselho é responsável por três tarefas de governança principais:
Referendo sábio da proposta
Cancelar referendos perigosos ou maliciosos
Comissão Técnica de Eleições
Na governança v2, são necessárias estratégias substitutas para substituir as responsabilidades do conselho que anteriormente atuava como ó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 cotidiana. A Gov2 é construída sobre a funcionalidade de delegação de voto da v1, permitindo que os eleitores escolham delegar seus direitos de voto a outro eleitor no sistema. Isso é realizado através de uma melhoria chamada delegação de múltiplos papéis, onde os eleitores podem designar representantes diferentes para cada classe de referendo no sistema. Assim, os eleitores podem delegar a uma entidade a gestão de uma categoria de referendo de menor impacto, enquanto escolhem um representante diferente para gerir outra categoria com consequências mais significativas, e ainda mantêm o direito de voto completo sobre quaisquer categorias restantes.
) Cancelar referendo
Na governança v1, se o comitê técnico concordar por unanimidade em cancelar a proposta, ou se a origem Root (, como sudo ), ativar essa função, 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 descoberto tardiamente na proposta do referendo (, como um erro no código runtime que a proposta irá executar ), isso pode ser considerado como um último recurso.
Se a controvérsia sobre o cancelamento for grande o suficiente para que o conselho não consiga obter uma maioria de dois terços, então o destino da proposta será decidido conjuntamente pelos interessados.
Na governança v2, há uma operação especial chamada Cancelation###, utilizada para intervir em propostas que já foram votadas. Esta operação rejeitará imediatamente a votação em andamento, independentemente do seu estado. Há também uma disposição que garante que, se a proposta for maliciosa ou spam, o depósito do proponente será confiscado.
A cancelamento é, em si, uma operação de governança, que deve ser executada por votação na rede. A revogação vem acompanhada de sua própria Origem e Rastreio, tendo um período de importação muito curto e uma curva de taxa de aprovação/suporte, que cai ligeiramente mais rápido através do limiar, uma vez que é acionada em situações de urgência.
Comissão Técnica
Na governança v1, o comitê técnico (TC) é um dos três órgãos da governança do Kusama(, os outros dois órgãos são o conselho e o referendo). O TC é composto por equipes que implementaram ou definiram o runtime do Polkadot ou o Polkadot Host. Através de uma votação simples da maioria do conselho, equipes podem ser adicionadas ou removidas do TC.
O objetivo do TC é prevenir votações maliciosas, implementar correções de bugs, reverter atualizações de runtime erradas ou adicionar novas funcionalidades que foram testadas em campo. O TC tem o direito de usar o pallet de Democracia para acelerar propostas e é o único que pode.
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.
14 gostos
Recompensa
14
7
Partilhar
Comentar
0/400
CoffeeOnChain
· 9h atrás
Iterou tantas vezes, está tudo bem?
Ver originalResponder0
ApyWhisperer
· 12h atrás
A governança é realmente boa. Quando sobe para v3?
Governação Polkadot V2: Um novo capítulo na Descentralização de decisões
Governança V2
Polkadot adotou um mecanismo de governança sofisticado que lhe permite evoluir continuamente com base nas necessidades das partes interessadas. O objetivo é garantir que a maioria das participações possa sempre controlar a rede.
O conteúdo deste artigo pode sofrer alterações. O protocolo de governança já passou por várias iterações (v1 e v2), e haverá mais mudanças no futuro (v2.5).
O primeiro sistema de governança descentralizada da Polkadot (v1) é composto por três componentes principais:
O sistema funcionou bem nos primeiros anos, mas à medida que amadurecia, precisou evoluir constantemente para melhorar suas deficiências e acompanhar os avanços. Por exemplo, na "governança v1", todos os pesos dos referendos eram iguais, e só era possível votar em um referendo de cada vez, com um período de votação que poderia durar várias semanas. Isso levou o sistema a se concentrar em considerar cuidadosamente 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 diárias são tomadas, tornando os referendos mais abrangentes e ágeis, aumentando assim significativamente o número de decisões coletivas que o sistema pode fazer.
O Gov2 será lançado e testado na Kusama antes de ser proposto para implantação na Polkadot. Atualmente, o Gov2 já está ativo na rede Kusama.
O seguinte conteúdo apresentará os princípios centrais de governança da rede Polkadot. Compreender as raízes da governança v1 ajudará a entender melhor a direção da segunda iteração. Essas diferenças serão destacadas em vários subtemas.
É importante notar que, nesta fase atual, a governança ainda é um protocolo em constante desenvolvimento. Com a atualização da governança v2, o 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 conversão de estado amorfo armazenadas na cadeia definidas em WebAssembly (, bem como vários mecanismos de votação na cadeia, como referendos com um limiar de maioria absoluta adaptativa e votação de aprovação em massa.
Todas as alterações ao protocolo devem ser acordadas através de um referendo ponderado por direitos de voto.
) mecanismo
Na governança v1, os detentores de tokens ativos e o conselho gerem em conjunto as decisões de atualização da rede. Independentemente de a proposta ser apresentada pelo público ou pelo conselho, a decisão final deve passar por um referendo popular, com o valor da participação e da fé a servirem como pesos na decisão.
A governança v2 teve algumas mudanças. A nova forma de governança reflete características de descentralização da seguinte maneira:
referendo
O referendo é uma solução de votação simples, inclusiva e baseada em staking. Cada referendo tem uma proposta relacionada, utilizando a chamada de função de privilégio de runtime ###, incluindo a chamada set_code mais poderosa, que pode 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 for aprovado, serão chamadas as funções relevantes. Um referendo é sempre binário; as opções de votação só podem ser "a favor", "contra" ou completamente abstenção.
Na governança v1, a votação pode ser iniciada de várias maneiras:
Todos os referendos têm um período de atraso de execução correspondente. Este é o tempo entre o término do referendo e a execução real da proposta.
No Gov2, qualquer pessoa pode iniciar um referendo a qualquer momento, sem limite de vezes. O Gov2 introduz os conceitos de Origins) e Tracks( para ajudar no fluxo e processamento do protocolo de referendo.
Origin pode ser considerado um descritor para um determinado nível de privilégios. O proponente precisa escolher o Origin apropriado com base nos requisitos da proposta.
Cada Origem está associada a uma categoria de referendo, e cada categoria tem uma Trilha. A Trilha descreve o ciclo de vida da proposta e é independente de outras categorias. Diferentes trilhas independentes permitem que a rede ajuste a dinâmica do referendo com base nos níveis de privilégio implícitos.
Por exemplo, o impacto da atualização do Runtime no ecossistema é diferente da aprovação de gorjetas do tesouro, portanto, são necessárias diferentes Origens, nas quais diferentes taxas de votação, taxas de aprovação, depósitos e o período mínimo de execução serão previamente determinados.
) Proposta de Referendo
Referendo público
Qualquer pessoa pode propor um referendo depositando a quantidade mínima de tokens durante um determinado período. Se alguém concordar, pode depositar a mesma quantidade de tokens para expressar apoio.
Isto é chamado de "endorse". A proposta que obtiver o maior suporte de token vinculado 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 cada uma vinculando 20 DOT "superarão" dez contas cada uma vinculando 1 DOT.
Uma vez que a proposta é submetida ( para votação ), os tokens vinculados serão liberados.
Para a governança v1, pode haver até 100 propostas públicas na fila de propostas.
No Gov2, assim que o referendo é criado, a comunidade pode votar imediatamente. No entanto, o referendo não está em um estado que permita ser encerrado, contar os votos, obter aprovação e ser finalmente executado. Em vez disso, o referendo deve atender a alguns critérios para entrar no estado "decidir ###Decidindo (". Antes disso, ainda está em estado pendente.
Os critérios para entrar no estado Decided são os seguintes:
Passou pelo período de introdução, que é o tempo necessário antes de se poder começar a decidir. Isso ajuda a reduzir a possibilidade de "decisões precipitadas", ou seja, um atacante que controla uma grande quantidade de direitos de voto pode aprovar uma proposta imediatamente após a proposta ser apresentada, sem dar aos votantes tempo suficiente para considerar e participar.
Deve haver espaço restante para decisões. Todos os Traks têm limitações sobre o número de referendos que podem ser decididos simultaneamente. Traks mais poderosos têm limitações mais baixas. Por exemplo, a limitação do nível Root Origin é 1, o que significa que apenas 1 proposta superperigosa pode ser decidida de cada vez.
É necessário pagar um depósito para a decisão. O custo para criar um referendo é muito baixo, pois o depósito só inclui o valor necessário para o armazenamento em cadeia. No entanto, revisar e decidir sobre o referendo apresenta o risco de esgotar os limites de posições na fila do referendo. Exigir um depósito maior, mas reembolsável, ajuda a reduzir o spam.
Votação do Conselho )v1(
Aprovação unânime do conselho - Quando todos os membros do conselho concordam com uma proposta, esta pode ser submetida a referendo. Este referendo resultará em uma discrepância na 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 (.
Aprovação pela maioria do conselho - Quando apenas a maioria simples dos membros do conselho concorda, também pode haver votação em referendo, mas será pelo sistema de maioria, onde a parte que obtiver 51% dos votos vence.
Só pode haver um referendo válido a qualquer momento, a menos que haja um referendo de emergência em andamento.
Tabela de Votação
Na governança v1, se houver pelo menos uma proposta na fila, uma nova votação será realizada a cada 28 dias. As propostas aprovadas pelo conselho têm uma fila, assim como as propostas submetidas pelo público. A votação será alternada entre as propostas que estão no topo das duas filas.
As propostas com melhor classificação são determinadas pela quantidade de staking associada a elas. Se a fila atual tentar criar um referendo sem proposta, a fila ) estará vazia (, e se houver propostas na fila de outra fila, a proposta mais bem classificada dessa fila entrará no referendo.
Não é permitido votar em várias propostas de referendo ao mesmo tempo, exceto em referendos de emergência. Os referendos de emergência que ocorrem simultaneamente com referendos regulares são a única situação em que se pode votar em várias propostas de referendo ao mesmo tempo.
Quando a proposta for aprovada, a governança v2 partilha o mesmo período de elegibilidade de 28 dias. Se a proposta não for aprovada até ao final desta fase, será automaticamente rejeitada.
Referendo votação ) governança v2(
Na governança v2, se a proposta atender aos requisitos de taxa de aprovação e taxa de apoio, a proposta será aprovada, ou seja, o sistema de viés de grupo adaptativo será removido.
A taxa de aprovação ) é definida como o peso de voto aprovado ( após ajustes de convicção ) que representa a parte do peso total dos votos (, incluindo as partes aprovadas e rejeitadas ).
A taxa de apoio ( Support ) é o número total de votos aprovados ( ignorar o ajuste de convicção ) em comparação com o número total de votos que podem ser feitos no sistema.
Deve atender a este padrão no menor tempo possível durante o período de confirmação. Diferentes trilhos têm diferentes períodos de confirmação e requisitos de aprovação e suporte. Agora é possível configurar através da quantidade de suporte necessária e da aprovação geral. Para propostas que utilizam fontes de privilégio mais baixo, é 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). Cursos com maior significado político podem solicitar aprovação mais alta mais cedo para evitar controvérsias.
No Gov2, propostas que não forem 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 continuar aprovada antes do término do período de confirmação, será considerada aprovada e a execução começará a partir da fonte proposta após o período de formulação. O período de formulação é definido quando uma proposta de votação popular é feita, mas também está sujeito 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 as mudanças que a proposta pode trazer.
Bloqueio Voluntário
Polkadot utiliza o conceito de "bloqueio voluntário", permitindo que os detentores de tokens aumentem seu poder de voto ao declarar por quanto tempo estão dispostos a bloquear seus tokens. Assim, o número de votos de cada detentor de token será calculado pela seguinte fórmula:
Número de votos = token * multiplicador de convicção
O número de períodos de bloqueio dobra a cada vez, e o multiplicador de convicção aumentará o multiplicador de votos em um.
Multiplicador de votação do período de bloqueio 00.111224384165326
O número máximo de vezes que o "período de bloqueio" pode ser "duplicado" é 6( um total de 32 períodos de bloqueio ), um período de bloqueio equivale a 28 dias. Apenas a duplicação é permitida, por exemplo, não é possível bloquear 24 períodos e aumentar a convicção em 5,5.
Após o bloqueio do token, este ainda pode ser utilizado para votação e staking; apenas é proibido 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 período de bloqueio do token.
Bias de grupo adaptativo
O desvio adaptativo do grupo foi utilizado por mais tempo na governança v2 e foi substituído pelo sistema de Aprovação/Apoio.
( Conselho
Na governança v1, os stakeholders passivos na Polkadot são representados por um órgão de gestão chamado "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 nacional, o conselho é responsável por três tarefas de governança principais:
Na governança v2, são necessárias estratégias substitutas para substituir as responsabilidades do conselho que anteriormente atuava como ó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 cotidiana. A Gov2 é construída sobre a funcionalidade de delegação de voto da v1, permitindo que os eleitores escolham delegar seus direitos de voto a outro eleitor no sistema. Isso é realizado através de uma melhoria chamada delegação de múltiplos papéis, onde os eleitores podem designar representantes diferentes para cada classe de referendo no sistema. Assim, os eleitores podem delegar a uma entidade a gestão de uma categoria de referendo de menor impacto, enquanto escolhem um representante diferente para gerir outra categoria com consequências mais significativas, e ainda mantêm o direito de voto completo sobre quaisquer categorias restantes.
) Cancelar referendo
Na governança v1, se o comitê técnico concordar por unanimidade em cancelar a proposta, ou se a origem Root (, como sudo ), ativar essa função, 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 descoberto tardiamente na proposta do referendo (, como um erro no código runtime que a proposta irá executar ), isso pode ser considerado como um último recurso.
Se a controvérsia sobre o cancelamento for grande o suficiente para que o conselho não consiga obter uma maioria de dois terços, então o destino da proposta será decidido conjuntamente pelos interessados.
Na governança v2, há uma operação especial chamada Cancelation###, utilizada para intervir em propostas que já foram votadas. Esta operação rejeitará imediatamente a votação em andamento, independentemente do seu estado. Há também uma disposição que garante que, se a proposta for maliciosa ou spam, o depósito do proponente será confiscado.
A cancelamento é, em si, uma operação de governança, que deve ser executada por votação na rede. A revogação vem acompanhada de sua própria Origem e Rastreio, tendo um período de importação muito curto e uma curva de taxa de aprovação/suporte, que cai ligeiramente mais rápido através do limiar, uma vez que é acionada em situações de urgência.
Comissão Técnica
Na governança v1, o comitê técnico (TC) é um dos três órgãos da governança do Kusama(, os outros dois órgãos são o conselho e o referendo). O TC é composto por equipes que implementaram ou definiram o runtime do Polkadot ou o Polkadot Host. Através de uma votação simples da maioria do conselho, equipes podem ser adicionadas ou removidas do TC.
O objetivo do TC é prevenir votações maliciosas, implementar correções de bugs, reverter atualizações de runtime erradas ou adicionar novas funcionalidades que foram testadas em campo. O TC tem o direito de usar o pallet de Democracia para acelerar propostas e é o único que pode.