Polkadot adotou um conjunto elegante de mecanismos de governança que podem evoluir de forma elegante de acordo com as necessidades das partes interessadas. O objetivo é garantir que a maioria dos interesses possa sempre controlar a rede.
O conteúdo deste documento pode ser alterado. O protocolo de governança passou por várias iterações (v1 e v2), e mais mudanças estão planejadas (v2.5).
O primeiro sistema de governança descentralizada do Polkadot (v1) é composto por três componentes principais:
Comissão Técnica: Comissão técnica responsável por gerir o cronograma de atualização.
Conselho: um "governo" executivo eleito por votação, responsável pela gestão de parâmetros, propostas de gestão e despesas.
Referendo: um sistema de votação universal, onde se vota sobre todas as outras questões, com os interessados de longo prazo a terem maior influência.
Este sistema funcionou bem nos primeiros anos, ajudando a garantir o uso adequado dos fundos do tesouro e a realizar atualizações e reparos em tempo hábil. Como a maioria das tecnologias iniciais, os sistemas e protocolos precisam evoluir continuamente para melhorar as deficiências e acompanhar o progresso. Por exemplo, na "governança v1", todos os referendos tinham o mesmo peso, pois apenas um referendo poderia ser votado de cada vez, e o período de votação poderia durar várias semanas. Isso levou o sistema a tender a considerar cuidadosamente um número muito limitado de propostas, em vez de considerar amplamente várias propostas. Assim, nasceu 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 tomar.
Após a revisão profissional final do seu código, o Gov2 será lançado no Kusama. Após os testes no Kusama, será feita uma proposta para a sua implantação no Polkadot.
O conteúdo a seguir apresentará muitos dos princípios fundamentais de governança na rede Polkadot. Compreender as raízes da governança v1 é importante para 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 do seu ciclo de vida, a governança é um protocolo em constante evolução. Com a atualização da governança v2 a entrar na rede, o plano para a governança v2.5 também está em desenvolvimento.
Premissa
Em resumo, a rede reúne uma variedade de mecanismos inovadores, incluindo funções de transição de estado amorfo armazenadas na cadeia e definidas em uma linguagem intermediária neutra da plataforma (WebAssembly), assim como vários mecanismos de votação em 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 juntos as decisões de atualização da rede. Independentemente de a proposta ser apresentada pelo público ( detentores de token ) ou pelo conselho, ela deve passar por um referendo nacional de todos os detentores, onde o valor em stake ( e o valor de crença ) são usados como pesos para a decisão.
A governança v2 tem algumas mudanças. A nova forma de refletir suas características descentralizadas é:
Transferir todas as responsabilidades do conselho para os detentores de tokens através de votação democrática
Dissolver o atual conselho diretivo 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 de tokens passivos, guardião do tesouro e iniciador legislativo, mas geralmente é visto como uma entidade centralizada. Para descentralizar ainda mais as redes Polkadot e Kusama, 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 relacionada, que utiliza chamadas de função de privilégio de runtime na forma ), incluindo a chamada mais poderosa: set_code, que pode alternar todo o código do runtime, realizando funcionalidades que originalmente exigiriam um "hard fork" para serem implementadas ###.
O referendo é um evento discreto com um período de votação fixo. Quando o período de votação termina e os votos são contados, se a votação for aprovada, a função (set_code) será chamada. O referendo é sempre binário; a sua escolha na votação pode ser apenas "a favor", "contra" ou totalmente abstenção.
No governo v1, o referendo pode ser iniciado de uma das seguintes maneiras:
Propostas submetidas publicamente;
Propostas aprovadas por maioria ou unanimidade do conselho;
Proposta apresentada como parte da execução do referendo anterior;
Proposta de emergência apresentada pelo comitê técnico e aprovada pelo conselho.
Todos os referendos têm um prazo de execução correspondente. Este é o período de tempo entre o término do referendo e a execução real da proposta (, assumindo que a proposta foi aprovada ).
Se um referendo for encerrado e os resultados contabilizados, o referendo será considerado concluído. Da mesma forma, supondo que a proposta seja aprovada, ela será programada para execução. Se o referendo estiver aguardando resultados, ou seja, estiver em votação, o referendo será considerado incompleto.
Se a proposta for apresentada pelo público ou pelo conselho, haverá um período fixo de atraso de execução de 28 dias. Propostas apresentadas como parte da execução de um referendo anterior podem ter um período de atraso de execução determinado conforme necessário. O tratamento de propostas urgentes requer a "seguimento rápido" de questões significativas da rede, reduzindo assim o tempo de execução.
No Gov2, qualquer pessoa pode iniciar um referendo a qualquer momento e quantas vezes quiser. O Gov2 introduz várias novas funcionalidades, chamadas Origins( origem) e Tracks( trilhos), para ajudar no processo e na gestão dos referendos.
Origin pode ser considerado um descritor rico para um nível de privilégio dado. Os proponentes do referendo agora precisam escolher um Origin adequado para seus pedidos, de acordo com os requisitos da proposta.
Cada Origin está associado a uma categoria de votação, 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 da votação com base nos níveis de privilégio implícitos.
Por exemplo, o impacto da chamada set_code da atualização Runtime ( no ecossistema é diferente da aprovação da gorjeta do tesouro ), chamada reportAwesome (, portanto, são necessárias origens diferentes, nas quais diferentes taxas de votação, taxas de aprovação, depósitos e o menor período de execução serão previamente 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 determinado período de ( blocos ). Se alguém concordar com a proposta, pode depositar a mesma quantidade de tokens para demonstrar apoio.
Esta operação é chamada de "endosse". A proposta que receber o maior número 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 com 20 DOT vinculados cada terão um efeito "superior" ao de dez contas com 1 DOT vinculado cada.
Uma vez que a proposta é submetida ###, a votação será iniciada (, e os tokens vinculados serão liberados.
Para a governança v1, pode haver até 100 propostas públicas na fila de propostas.
No Gov2, quando uma votação é criada, a comunidade pode imediatamente votar nela. No entanto, essa votação não está em um estado que possa ser encerrado ou de outra forma contar seus votos, obter aprovação e ser executada. Em vez disso, a votação deve atender a alguns critérios antes de entrar em um estado chamado "decisão )Decidindo(". Enquanto não estiver nesse estado, ainda está em estado pendente.
Os critérios para entrar no estado Decided são os seguintes:
A período de introdução)lead-in period( é o tempo que deve ser ultrapassado antes de se decidir que se pode começar. Isso ajuda a reduzir a probabilidade de "decisão de sniper", onde um atacante com controle significativo sobre os direitos de voto pode aprovar uma proposta imediatamente após a proposta ser feita, em vez de permitir que todos os votantes tenham tempo suficiente para considerar e participar.
Deve haver um espaço restante decisivo. Todos os Track limitam o número de referendos que podem ser decididos simultaneamente. Os trilhos com maior capacidade terão limites mais baixos. Por exemplo, o limite do nível Root Origin é 1, o que significa que apenas 1 proposta super perigosa pode ser decidida de cada vez.
É necessário pagar um depósito decisivo. O custo para criar um referendo é muito baixo, uma vez que o valor do depósito inclui apenas o valor necessário para o armazenamento em cadeia que o acompanha. No entanto, existe 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 lixo informativo.
Calendário de Votação
Na Governance v1, supondo que haja 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 fila para as propostas submetidas pelo público. As votações serão alternadas entre as propostas que estão nas primeiras posições das duas filas.
As propostas mais bem classificadas são determinadas pela quantidade de staking vinculada a elas. Se a fila atual tentar criar uma votação sem propostas e a fila ) estiver vazia (, e outra fila tiver propostas em espera, a proposta mais bem classificada na outra fila entrará na votação.
Não é permitido realizar votação em várias referendos ao mesmo tempo, exceto em referendos de emergência. O referendo de emergência que ocorre ao mesmo tempo que um referendo regular ) ou uma proposta do conselho ( é a única situação em que se pode votar em múltiplos referendos simultaneamente.
Quando a proposta for aprovada, a governança v2 compartilhará o mesmo período de qualificação de 28 dias. Se não for aprovada até o final deste período, a proposta 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 apoio, 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 de convicção ) em relação ao peso total de voto (, incluindo as quotas de aprovação e rejeição ).
A taxa de apoio ( Support ) é o total de votos aprovados ( ignorando o ajuste de conviction ) em comparação com o total de votos que podem ser realizados no sistema.
Deve cumprir 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 é possível configurar com base na quantidade de apoio necessária e na 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). Cursos com maior significado político podem solicitar uma aprovação mais alta 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 ser mantida aprovada antes do fim do período de confirmação, será considerada aprovada e o seu início será planejado a partir da fonte proposta após o período de elaboração. O período de elaboração é designado quando a proposta é submetida a votação pública, mas também está sujeito a um mínimo baseado em trilhos. Trilhos mais robustos 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 utiliza um conceito chamado "bloqueio voluntário", que permite aos detentores de tokens aumentar seu poder de voto declarando por quanto tempo estão dispostos a bloquear seus tokens. Assim, o número de votos de cada detentor de tokens 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.
Número de votos do período de bloqueio multiplicador 00.111224384165326
O número máximo de vezes para "dobrar" o período de bloqueio é definido como 6(, portanto, há um total de 32 períodos de bloqueio ), cada período de bloqueio é igual a 28 dias. Apenas é permitido dobrar, por exemplo, você não pode bloquear 24 ciclos e aumentar sua convicção em 5,5.
Após o bloqueio do token, você ainda pode usá-lo para votar e fazer staking; você apenas não pode 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.
( Cancelar o referendo
Na governança v1, se o comitê técnico concordar unanimemente em cancelar uma proposta, ou se a fonte Root ativar esta 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 anular o referendo. Se um problema for encontrado tarde na proposta de referendo ), por exemplo, se houver um erro no código runtime que a proposta irá executar (, isso pode ser considerado como um último recurso.
Se a controvérsia em torno do cancelamento for grande o suficiente para que o conselho não consiga obter uma maioria de dois terços, o destino da proposta será decidido em conjunto pelos interessados.
Na governança v2, há uma operação especial chamada Cancelation) que revoga###, destinada a 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 seja confiscado.
A cancelamento é, em si, uma operação de governança e deve ser executada por votação na rede. A revogação vem acompanhada de sua própria Origem e Rastreio, possui um período de importação muito curto e uma curva de taxa de aprovação/suporte, cuja barreira de aceitação diminui um pouco mais rapidamente, pois é invocada em situações de urgência.
( Bolsa Polkadot
A Fellowship é uma instituição especializada de autonomia básica, cujo principal objetivo é representar a base de conhecimento técnico das pessoas envolvidas com a rede e os protocolos Polkadot. A Fellowship através de "igual
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.
12 gostos
Recompensa
12
6
Partilhar
Comentar
0/400
Lonely_Validator
· 16h atrás
O que é governança? Se não entende, não invista.
Ver originalResponder0
GateUser-4745f9ce
· 20h atrás
Não se preocupe com o V2, trate logo das taxas de gás do V1.
Ver originalResponder0
GraphGuru
· 20h atrás
Estive a seguir o v2 há algum tempo. Muito bom, muito bom.
Ver originalResponder0
BearMarketSurvivor
· 20h atrás
Não é apenas uma questão de descentralização do voto? O que há de novo nisso?
Ver originalResponder0
SneakyFlashloan
· 20h atrás
Ainda é melhor dar-me diretamente o poder de governança.
Ver originalResponder0
TokenSherpa
· 20h atrás
na verdade, este modelo v2 ainda ignora a mecânica de votação quadrática... *sigh* deixe-me explicar isso
Polkadot Governança V2: Inovação no Mecanismo de Votação para Aumentar a Eficiência na Tomada de Decisões
Governança V2
Polkadot adotou um conjunto elegante de mecanismos de governança que podem evoluir de forma elegante de acordo com as necessidades das partes interessadas. O objetivo é garantir que a maioria dos interesses possa sempre controlar a rede.
O conteúdo deste documento pode ser alterado. O protocolo de governança passou por várias iterações (v1 e v2), e mais mudanças estão planejadas (v2.5).
O primeiro sistema de governança descentralizada do Polkadot (v1) é composto por três componentes principais:
Este sistema funcionou bem nos primeiros anos, ajudando a garantir o uso adequado dos fundos do tesouro e a realizar atualizações e reparos em tempo hábil. Como a maioria das tecnologias iniciais, os sistemas e protocolos precisam evoluir continuamente para melhorar as deficiências e acompanhar o progresso. Por exemplo, na "governança v1", todos os referendos tinham o mesmo peso, pois apenas um referendo poderia ser votado de cada vez, e o período de votação poderia durar várias semanas. Isso levou o sistema a tender a considerar cuidadosamente um número muito limitado de propostas, em vez de considerar amplamente várias propostas. Assim, nasceu 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 tomar.
Após a revisão profissional final do seu código, o Gov2 será lançado no Kusama. Após os testes no Kusama, será feita uma proposta para a sua implantação no Polkadot.
O conteúdo a seguir apresentará muitos dos princípios fundamentais de governança na rede Polkadot. Compreender as raízes da governança v1 é importante para 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 do seu ciclo de vida, a governança é um protocolo em constante evolução. Com a atualização da governança v2 a entrar na rede, o plano para a governança v2.5 também está em desenvolvimento.
Premissa
Em resumo, a rede reúne uma variedade de mecanismos inovadores, incluindo funções de transição de estado amorfo armazenadas na cadeia e definidas em uma linguagem intermediária neutra da plataforma (WebAssembly), assim como vários mecanismos de votação em 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 juntos as decisões de atualização da rede. Independentemente de a proposta ser apresentada pelo público ( detentores de token ) ou pelo conselho, ela deve passar por um referendo nacional de todos os detentores, onde o valor em stake ( e o valor de crença ) são usados como pesos para a decisão.
A governança v2 tem algumas mudanças. A nova forma de refletir suas características descentralizadas é:
O conselho no Gov1 desempenhou os papéis de representante dos detentores de tokens passivos, guardião do tesouro e iniciador legislativo, mas geralmente é visto como uma entidade centralizada. Para descentralizar ainda mais as redes Polkadot e Kusama, 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 relacionada, que utiliza chamadas de função de privilégio de runtime na forma ), incluindo a chamada mais poderosa: set_code, que pode alternar todo o código do runtime, realizando funcionalidades que originalmente exigiriam um "hard fork" para serem implementadas ###.
O referendo é um evento discreto com um período de votação fixo. Quando o período de votação termina e os votos são contados, se a votação for aprovada, a função (set_code) será chamada. O referendo é sempre binário; a sua escolha na votação pode ser apenas "a favor", "contra" ou totalmente abstenção.
No governo v1, o referendo pode ser iniciado de uma das seguintes maneiras:
Todos os referendos têm um prazo de execução correspondente. Este é o período de tempo entre o término do referendo e a execução real da proposta (, assumindo que a proposta foi aprovada ).
Se um referendo for encerrado e os resultados contabilizados, o referendo será considerado concluído. Da mesma forma, supondo que a proposta seja aprovada, ela será programada para execução. Se o referendo estiver aguardando resultados, ou seja, estiver em votação, o referendo será considerado incompleto.
Se a proposta for apresentada pelo público ou pelo conselho, haverá um período fixo de atraso de execução de 28 dias. Propostas apresentadas como parte da execução de um referendo anterior podem ter um período de atraso de execução determinado conforme necessário. O tratamento de propostas urgentes requer a "seguimento rápido" de questões significativas da rede, reduzindo assim o tempo de execução.
No Gov2, qualquer pessoa pode iniciar um referendo a qualquer momento e quantas vezes quiser. O Gov2 introduz várias novas funcionalidades, chamadas Origins( origem) e Tracks( trilhos), para ajudar no processo e na gestão dos referendos.
Origin pode ser considerado um descritor rico para um nível de privilégio dado. Os proponentes do referendo agora precisam escolher um Origin adequado para seus pedidos, de acordo com os requisitos da proposta.
Cada Origin está associado a uma categoria de votação, 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 da votação com base nos níveis de privilégio implícitos.
Por exemplo, o impacto da chamada set_code da atualização Runtime ( no ecossistema é diferente da aprovação da gorjeta do tesouro ), chamada reportAwesome (, portanto, são necessárias origens diferentes, nas quais diferentes taxas de votação, taxas de aprovação, depósitos e o menor período de execução serão previamente 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 determinado período de ( blocos ). Se alguém concordar com a proposta, pode depositar a mesma quantidade de tokens para demonstrar apoio.
Esta operação é chamada de "endosse". A proposta que receber o maior número 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 com 20 DOT vinculados cada terão um efeito "superior" ao de dez contas com 1 DOT vinculado cada.
Uma vez que a proposta é submetida ###, a votação será iniciada (, e os tokens vinculados serão liberados.
Para a governança v1, pode haver até 100 propostas públicas na fila de propostas.
No Gov2, quando uma votação é criada, a comunidade pode imediatamente votar nela. No entanto, essa votação não está em um estado que possa ser encerrado ou de outra forma contar seus votos, obter aprovação e ser executada. Em vez disso, a votação deve atender a alguns critérios antes de entrar em um estado chamado "decisão )Decidindo(". Enquanto não estiver nesse estado, ainda está em estado pendente.
Os critérios para entrar no estado Decided são os seguintes:
Calendário de Votação
Na Governance v1, supondo que haja 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 fila para as propostas submetidas pelo público. As votações serão alternadas entre as propostas que estão nas primeiras posições das duas filas.
As propostas mais bem classificadas são determinadas pela quantidade de staking vinculada a elas. Se a fila atual tentar criar uma votação sem propostas e a fila ) estiver vazia (, e outra fila tiver propostas em espera, a proposta mais bem classificada na outra fila entrará na votação.
Não é permitido realizar votação em várias referendos ao mesmo tempo, exceto em referendos de emergência. O referendo de emergência que ocorre ao mesmo tempo que um referendo regular ) ou uma proposta do conselho ( é a única situação em que se pode votar em múltiplos referendos simultaneamente.
Quando a proposta for aprovada, a governança v2 compartilhará o mesmo período de qualificação de 28 dias. Se não for aprovada até o final deste período, a proposta 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 apoio, 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 de convicção ) em relação ao peso total de voto (, incluindo as quotas de aprovação e rejeição ).
A taxa de apoio ( Support ) é o total de votos aprovados ( ignorando o ajuste de conviction ) em comparação com o total de votos que podem ser realizados no sistema.
Deve cumprir 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 é possível configurar com base na quantidade de apoio necessária e na 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). Cursos com maior significado político podem solicitar uma aprovação mais alta 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 ser mantida aprovada antes do fim do período de confirmação, será considerada aprovada e o seu início será planejado a partir da fonte proposta após o período de elaboração. O período de elaboração é designado quando a proposta é submetida a votação pública, mas também está sujeito a um mínimo baseado em trilhos. Trilhos mais robustos 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 utiliza um conceito chamado "bloqueio voluntário", que permite aos detentores de tokens aumentar seu poder de voto declarando por quanto tempo estão dispostos a bloquear seus tokens. Assim, o número de votos de cada detentor de tokens 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.
Número de votos do período de bloqueio multiplicador 00.111224384165326
O número máximo de vezes para "dobrar" o período de bloqueio é definido como 6(, portanto, há um total de 32 períodos de bloqueio ), cada período de bloqueio é igual a 28 dias. Apenas é permitido dobrar, por exemplo, você não pode bloquear 24 ciclos e aumentar sua convicção em 5,5.
Após o bloqueio do token, você ainda pode usá-lo para votar e fazer staking; você apenas não pode 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.
( Cancelar o referendo
Na governança v1, se o comitê técnico concordar unanimemente em cancelar uma proposta, ou se a fonte Root ativar esta 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 anular o referendo. Se um problema for encontrado tarde na proposta de referendo ), por exemplo, se houver um erro no código runtime que a proposta irá executar (, isso pode ser considerado como um último recurso.
Se a controvérsia em torno do cancelamento for grande o suficiente para que o conselho não consiga obter uma maioria de dois terços, o destino da proposta será decidido em conjunto pelos interessados.
Na governança v2, há uma operação especial chamada Cancelation) que revoga###, destinada a 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 seja confiscado.
A cancelamento é, em si, uma operação de governança e deve ser executada por votação na rede. A revogação vem acompanhada de sua própria Origem e Rastreio, possui um período de importação muito curto e uma curva de taxa de aprovação/suporte, cuja barreira de aceitação diminui um pouco mais rapidamente, pois é invocada em situações de urgência.
( Bolsa Polkadot
A Fellowship é uma instituição especializada de autonomia básica, cujo principal objetivo é representar a base de conhecimento técnico das pessoas envolvidas com a rede e os protocolos Polkadot. A Fellowship através de "igual