Gostaria de colocar a minha perspectiva em relação aos fatores que envolvem os pools em datacenter x home pools nas batalhas de slot.
Vamos começar lembrando alguns pontos que um operador tem que observar ao rodar um pool:
-Estabilidade da máquina Software / Reposição / Backup /Segurança
-Estabilidade e qualidade da rede de dados
-Estabilidade da rede elétrica
-Custo de infra-estrutura / Manutenção
Com estes 4 pontos podemos iniciar o nosso pool na tentativa de alcançar uma alta disponibilidade. O objetivo mais simples aqui é rodar um serviço onde se tenha um usuário satisfeito (e essa definição de satisfeito definitivamente não é um item único).
Dos pools temos:
Tipo 1
-Pools que rodam em data centers, esse colocam na ponta dos dedos dos operadores a conveniência e a estabilidade de uma infra estrutura para rodar um serviço com um SLA superior.
Tipo 2
-Pools que rodam em cima de uma infraestrutura que o operador já possui, neste caso o operador está em sua maioria, re-utilizando a sua infra para rodar o serviço ou adquirindo uma, o legal é que isso também evite disrupções na nossa rede devido ao encerramento abrupto de datacenters por qualquer motivo que seja.
Sem sombra de dúvidas a melhor opção para a rede seria um Tipo 2, mas ela não se encaixa para qualquer operador ou tamanho de pool.
Imagina o seguinte, preocupação de um operador de pool do Tipo 2 em que esteja tirando do bolso para se aproximar de um nível de datacenter, melhorando sua fibra, peças de hardware, requerendo uma perspectiva de investimento na expectativa de um retorno futuro que não tem data para ocorrer, dependendo do crescimento do projeto e do seu pool.
Só para ficar claro aqui que, em algum momento, é bom ter essa combinação do tipo 1 e do tipo 2 para criar uma mistura de benefícios, mas isso custará mais.
O que eu quero enfatizar aqui é, existe um grupo de operadores que se sentiram confortáveis em arcar com esse movimento e a possibilidade de alguém bater em um poste e quebrar a sua fibra, do outro lado temos operadores que não tem condição alguma de rodar um serviço desses na sua localidade ou até mesmo o capital para isso. No caso, o que ocorre na minha região.
Pensar estabilidade na rede elétrica na minha região é um sonho de longo prazo. Aqui existem muitas árvores em uma região com muito vento próxima a praia, qualquer mudança no clima joga os galhos para cima dos fios e a manutenção disso está longe do ideal.
Para rodar algo localmente seria necessário um banco de baterias, o que não é muito barato aqui. A última vez que fiquei sem luz foi a duas semanas atrás, durou umas 30h com pico de instabilidades e ainda queimou alguns itens da cozinha.
Já a minha irmã que mora em Kansas quando perguntei pra ela, teve que fazer força pra pensar e concluiu que nunca foi afetada nos últimos 2 anos.
Equipamentos eletrônicos aqui ficam cada vez mais inacessíveis, o imposto em tecnologia e serviços beira o sobrenatural, algo em torno de 60% (agora dá uma somada com a queda de 85% do real nos últimos 24 meses), encontrar um datacenter com preço bom, qualidade e que não esteja nas mãos de gigantes é uma tarefa árdua. Em média os serviços de hosting aqui custam 4x mais e subindo.
Cada operador vive uma realidade diferente.
E foi por causa dessas realidades diferentes que eu resolvi escrever este artigo, sou um operador que utiliza datacenters para o node, no momento atual, ainda é complicado trazer uma operação de stake onde moro, muito pela questão de infra-estrutura e pelo tamanho do stakepool.
Trazer o node pra minha região é algo que definitivamente quero tentar, mas assim como todos os operadores eu quero ter a possibilidade de entregar uma boa estabilidade no serviço.
A questão é, se você é um stakepool pequeno em um lugar sem densidade de pools, se dar ao luxo de falhar é garantia de péssimas estatísticas, com certeza isso irá dificultar o crescimento do seu pool e em paralelo uma tentativa de descentralizar mais o node.
Para pools menores a corrida é para não perder dinheiro na operação de curto prazo e prestar um bom serviço. O pool precisa ganhar um bom tamanho para que você consiga fazer algumas modificações, a minha conclusão aqui é que inclusive sem uma boa distribuição de stake entre os pools fica mais difícil descentralizar!
Talvez essa parte seja controversa, de que tamanho de stakepool não importa na tentativa de rodar um Tipo 2 em lugares remotos! Talvez isso seja o caso de operadores que tem o node em países de primeiro mundo em que a probabilidade de serem rodeados por outros nodes é muito maior, tem ótima rede, componentes baratos e conseguem inclusive ter uma propagação razoável até a europa. Nesses casos até consigo imaginar o cara que configurou um raspberry jogou no porão e bateu a porta.
Batalhas de slot e batalhas de operadores
Acredito que a comunidade já podem ter visto o problema da batalha de slots sendo debatido em diversos canais.
O que acontece aqui é que temos um limite físico na internet hoje, e a regra é simples, com caminhos mais longos maior é o tempo para a informação ir e vir.
Eu não quero nem falar da tristeza que é a latência da minha rede, a quantidade de pontos e rotas conectando EUA e EU ao Brasil são significativas, rotas essas com preferência de entrega de pacotes diferenciadas, encontrar a melhor rota ou o melhor serviço não é uma tarefa fácil. E aqui vale o destaque, o limite físico continua existindo, não importa se eu encontrar a rota mais rápida na minha região.
Mas afinal, qual é o erro, o que está acontecendo com os tais slots? Qual o problema?
O problema é que não temos uma implementação na camada de rede que possa amenizar o problema da distância, isso atrapalha o momento de decidir o vencedor de uma batalha de slots.
Isso proporciona incentivos para que operadores se comportem de uma determinada forma, todos querem ser perfeitos quando o fator não é determinado por sorte.
O operador busca posicionar o node em uma região que tem uma melhor conexão com a maior quantidade possível de nodes, causando a centralização dos nodes.
Mas isso é a mesma coisa que centralizar a produção de blocos?
Não, cada stakepool garante a descentralização por serem autonomos. Aqui é justamente o poder de uma rede que é proof of stake, se um serviço de um operador for encerrado em algum lugar, em poucos segundos estará rodando em um novo lugar.
A descentralização é a nossa comunidade e nossos operadores, a infra pode acabar centralizando, não afeta os fundamentos.
Não me entendam errado, isso não é uma passada de mão, são fatos, continuo…
Apenas ratificando, isso não é um problema NO protocolo, é mais um problema no node, um problema de rede.
Soluções podem ser implementadas pelo lado da rede como pelo lado do protocolo, porém não é interessante uma alteração no protocolo sendo que uma solução pode ser atingida via gestão da camada de rede no momento.
Uma das soluções que não alteraria o protocolo seria um ajuste dinâmico para incentivar nodes a operarem de lugares com baixa densidade de nodes. No momento eu não consigo ter uma ideia clara de como essa funcionalidade deveria se comportar em um ambiente denso de baixa latência, mas poderia ser uma ótima opção no node para operadores isolados em grandes distâncias.
A batalha entre pool pequenos em regiões afastadas e pools grandes se intensificam aqui, se temos pools grandes dominando a produção de slots em regiões densas, isso dízima ainda mais a probabilidade de pools ganharem essas batalhas a distância.
A batalha de slots, que deveria equilibrar o retorno do serviço agora é dominado por pools que tem uma alta produção de blocos, onde a perda em performance é quase imperceptível comparada a um pool menor na mesma situação.
Pools menores que poderiam performar melhor e se tornar mais atrativos ficam em desvantagem, e talvez este seja o cerne do problema em uma distribuição de stake no futuro, gerando uma dificuldade de espalhar o stake com um K maior.
Na verdade a testnet em grande parte foi substancialmente mais danosa para pools menores, o problema com a múltipla submissão de blocos por pools maiores foi devastadora para os que tinham seus poucos blocos jogados para fora da chain.
A busca pelo perfeccionismo na nossa comunidade de stakepool operators é um reflexo dos ideais no qual cardano é baseado, não por menos é esperado que situações desse tipo causem questionamentos de conduta que podem ser exacerbados, até mesmo pela interpretação da nossa comunidade. Visivelmente operadores do Tipo 2 estão descontentes por investirem em um local fixo, mas sinceramente eu acredito que deveriam considerar um mix nesse caso. Muitos operadores grandes tem 2 ou mais pools, deixe 1 em um lugar e um em outro.
Minha chamada aqui é mais para um calm down pois por um breve momento todos os operadores do Tipo 1 foram colocados no mesmo saco, junto com os que moveram suas máquinas para especular o benefício. Se o cara esteve naquela região desde o início agora não faz mais diferença, e o mesmo para operadores do Tipo 2 que querem melhorar mas são pequenos e estão passando dificuldades.
Se o protocolo ou a configuração do node der uma brecha para abrir vantagem, ela será explorada.
Quão exposta a nossa rede fica sujeita a centralização?
Não, nosso protocolo de consenso garante isso.
Nossa infra estrutura?
Sim, enquanto o incentivo permanecer.
Isso é ruim?
Sim, a nossa comunidade tem sempre que buscar pela melhor solução, Ouroboros chronos pode ter algumas respostas.
E aqui vai um extra, frequentemente vemos os operadores formando grupos para testar uma coisa ou outra.
E se a nossa comunidade formasse grupos ou guildas, que apoiam fatores específicos da rede?
Uma delas poderia sim ser a descentralização. Quantos dos seus delegadores apoiam lidar com uma queda de performance em defesa de uma descentralização de infra estrutura?
Esse grupo de membros da comunidade poderia fomentar isso, seria interessante ver esse lado ativo da comunidade de forma organizada.
É isso ai pessoal, obrigado pelo tempo de tentar entender minha perspectiva em relação ao problema e a comunidade.
Obrigado a todos que são pacientes e ajudam os outros
Ouros Stakepool