#opg $OPG Há uma coisa que nunca consegui entender. Quando chega uma solicitação de IA e mais de dez nós a recebem, quem fica com ela?
Se quem for mais rápido ficar com a tarefa, os nós com conexão rápida sempre terão trabalho, e os lentos nunca terão. No fim, só sobram dois ou três grandes operadores, enquanto todos os outros nós morrem de fome. Que descentralização é essa?
A OpenGradient propôs uma solução no white paper: sortear.
Mas não é um sorteio às cegas. O sistema pega o hash do bloco atual e o ID dessa solicitação, joga os dois em algo chamado VRF e calcula um número aleatório. Depois, usa esse número para ordenar todos os nós online. O nó que ficar em primeiro tem prioridade para aceitar a tarefa. Ele precisa enviar o resultado e a prova dentro do prazo estipulado. Se estourar o prazo ou trapacear, a vez passa para o segundo colocado, e assim por diante.
O principal é que esse número aleatório pode ser verificado. Os nós não podem trapacear, porque a lógica de ordenação é pública e qualquer um pode refazer o cálculo. O white paper diz que usa provas de conhecimento zero para garantir que o número aleatório foi realmente gerado de acordo com as regras. Quer descobrir antecipadamente quem vai receber a próxima solicitação? Nem pensar.
Vi outro projeto que também usava VRF, mas a ordenação ainda era manipulada por quem agia primeiro. Depois, descobriram que os nós tinham conseguido adivinhar a semente aleatória com antecedência. A OpenGradient vincula a semente ao hash do bloco, que não pode ser previsto, e assim fecha essa brecha.
Mas esse projeto tem um aspecto irritante. Se um nó estourar o prazo de propósito, ele não perde imediatamente o stake; apenas é removido temporariamente da fila. Só depois de estourar o prazo várias vezes seguidas é que recebe uma punição. O white paper chama isso de “punição branda”. Eu entendo: qualquer um pode ter instabilidade na rede, e aplicar uma multa por um único atraso seria mesmo muito severo. Mas isso também abre espaço para abusos — alguém pode estourar o prazo repetidamente de propósito e reduzir a eficiência geral. Não há muito o que fazer, porque essa pessoa ainda não atingiu o limite que gera uma punição.
O white paper não especifica o número de atrasos nem o limite para a punição. Imagino que deixaram isso para ajustar depois do lançamento da mainnet, de acordo com as condições reais.
Enfim, acho que esse mecanismo de sorteio aponta na direção certa, mas protege contra quem age de boa-fé, não contra quem age de má-fé. Se alguém explorar bugs de propósito, talvez ainda seja preciso contar com denúncias da comunidade.
O que você acha? Esse método de ordenação é justo? Críticas são bem-vindas. @OpenGradient
Se quem for mais rápido ficar com a tarefa, os nós com conexão rápida sempre terão trabalho, e os lentos nunca terão. No fim, só sobram dois ou três grandes operadores, enquanto todos os outros nós morrem de fome. Que descentralização é essa?
A OpenGradient propôs uma solução no white paper: sortear.
Mas não é um sorteio às cegas. O sistema pega o hash do bloco atual e o ID dessa solicitação, joga os dois em algo chamado VRF e calcula um número aleatório. Depois, usa esse número para ordenar todos os nós online. O nó que ficar em primeiro tem prioridade para aceitar a tarefa. Ele precisa enviar o resultado e a prova dentro do prazo estipulado. Se estourar o prazo ou trapacear, a vez passa para o segundo colocado, e assim por diante.
O principal é que esse número aleatório pode ser verificado. Os nós não podem trapacear, porque a lógica de ordenação é pública e qualquer um pode refazer o cálculo. O white paper diz que usa provas de conhecimento zero para garantir que o número aleatório foi realmente gerado de acordo com as regras. Quer descobrir antecipadamente quem vai receber a próxima solicitação? Nem pensar.
Vi outro projeto que também usava VRF, mas a ordenação ainda era manipulada por quem agia primeiro. Depois, descobriram que os nós tinham conseguido adivinhar a semente aleatória com antecedência. A OpenGradient vincula a semente ao hash do bloco, que não pode ser previsto, e assim fecha essa brecha.
Mas esse projeto tem um aspecto irritante. Se um nó estourar o prazo de propósito, ele não perde imediatamente o stake; apenas é removido temporariamente da fila. Só depois de estourar o prazo várias vezes seguidas é que recebe uma punição. O white paper chama isso de “punição branda”. Eu entendo: qualquer um pode ter instabilidade na rede, e aplicar uma multa por um único atraso seria mesmo muito severo. Mas isso também abre espaço para abusos — alguém pode estourar o prazo repetidamente de propósito e reduzir a eficiência geral. Não há muito o que fazer, porque essa pessoa ainda não atingiu o limite que gera uma punição.
O white paper não especifica o número de atrasos nem o limite para a punição. Imagino que deixaram isso para ajustar depois do lançamento da mainnet, de acordo com as condições reais.
Enfim, acho que esse mecanismo de sorteio aponta na direção certa, mas protege contra quem age de boa-fé, não contra quem age de má-fé. Se alguém explorar bugs de propósito, talvez ainda seja preciso contar com denúncias da comunidade.
O que você acha? Esse método de ordenação é justo? Críticas são bem-vindas. @OpenGradient