Diretrizes para operar grandes stake pools

Esta seção fornece diretrizes para operadores de grandes stake pools, especificamente como gerenciar os riscos e complexidades de manter uma participação significativa ou várias pools. Operadores de pools menores também podem achar grande parte deste conselho útil.

Principais recomendações

1. Considere confiabilidade e robustez. Stake pools exigem servidores de alta confiabilidade com:
   • Capacidade de computação resiliente.
   • Capacidade de rede robusta.
2. Considere cuidadosamente os requisitos de rede:
   • Conexões de alta largura de banda são essenciais para executar um nó de retransmissão (por exemplo, 5 Mbit/s + 0,1 Mbit/s por par a jusante como um número de planejamento de capacidade).
3. Opere nós de retransmissão suficientes além de stake pools:
   • Nós de retransmissão são necessários para a manutenção da rede.
   • Forneça dois nós de retransmissão para cada stakepool ativa.
4. Esteja ciente do desempenho do sistema e da rede, especialmente se estiver usando servidores virtualizados ou compartilhados:
   • Cada stakepool pode precisar de seus próprios recursos de hardware dedicados (computação, memória e rede).
   • É recomendável usar servidores diferentes para pools de stake e nós de retransmissão.
   • A virtualização pode complicar o processo de determinar se as pools de stake têm recursos adequados.
5. Não replique as stake pools na rede:
   • A replicação de pools de stake é um comportamento adversarial, o que pode levar à rejeição de blocos.
   • Use técnicas de alta confiabilidade para alternar entre servidores duplicados ou de backup sem expor ambos simultaneamente à rede.
6. As stake pools devem ter conexões de rede limitadas:
   • Isso reduz a exposição da stakepool a ataques de negação de serviço (DOS) e melhora o desempenho.
   • Os nós de retransmissão devem lidar com a maior parte do tráfego de rede.
   • As stake pools devem estar conectadas apenas a nós confiáveis (retransmissão e/ou geração de stake).
   • As stake pools e os nós de retransmissão devem restringir os serviços que são expostos (por exemplo, usando um firewall).
7. A segurança é primordial:
   • Use airgapping ao assinar transações - não armazene chaves frias em um servidor online (incluindo aquele que está executando uma stakepool ou um nó de retransmissão).
   • Use carteiras de hardware para chaves privadas de alto valor, sempre que possível.
   • Onde as chaves privadas não podem ser armazenadas em carteiras de hardware (por exemplo, chaves frias), armazene-as offline.
   • Esteja ciente e planeje para rotações de chaves forçadas usando o esquema de assinatura evolutiva de chave (KES).

Gerenciando riscos e complexidades

Operar pools de stake de forma eficaz é crucial para garantir a saúde e a vivacidade de longo prazo da descentralização no Cardano. Quando um operador de stakepool (SPO) opera várias pools de stake (ou tem uma única pool que controla diretamente uma porcentagem significativa do ada total apostado), eles podem ter um efeito significativo no throughput geral do sistema como consequência do princípio de "prova de participação".

O design e a análise de segurança do Cardano assumem que cada pool de stake opera de forma amplamente independente e mutuamente solidária (não adversarial). Isso significa que grandes SPOs têm uma responsabilidade particular de garantir que sua operação apoie as necessidades da rede como um todo. Para isso, é essencial avaliar e abordar os riscos comuns que podem ser experimentados nas operações de pool de stake.

Riscos de virtualização e containerização

Como pools de stake e nós de retransmissão têm requisitos específicos de tempo real, geralmente não é recomendado executar nós do Cardano em recursos virtualizados sem realizar análises cuidadosas de desempenho, confiabilidade e segurança. O mapeamento de nós do Cardano para a infraestrutura física subjacente deve considerar problemas de temporização para a produção e propagação de blocos.

Segurança e falhas de modo comum

Os riscos de operar uma stakepool usando virtualização baseada em contêiner incluem chances aumentadas de falhas de sistema em modo comum, contenção de recursos e exposição aumentada a riscos de segurança (incluindo ataques DOS e perda de chaves privadas). O uso de ambientes containerizados, onde os nós de retransmissão compartilham a mesma infraestrutura física que os nós de stakepool, pode impactar os requisitos em tempo real na produção de blocos e infraestrutura de rede, reduzindo assim a renda da pool de stake. Além disso, a concentração de conexões de rede (como pode acontecer com serviços virtualizados ou containerizados) aumenta as chances de um ataque DOS, além de reduzir a redundância de rede de maneiras não óbvias. Em um ambiente virtualizado ou compartilhado, uma única falha de NIC/cabo ou ataque DOS, por exemplo, pode então afetar várias pools de stake ou nós de retransmissão, incluindo aqueles que podem ser executados por diferentes SPOs.

Recursos compartilhados

A difusão de um bloco recém-emitido causa um "pulso" de atividade. Pools de stake e nós de retransmissão que compartilham recursos de computação física serão forçados a competir por CPU, memória, armazenamento, rede e outros recursos compartilhados. A demanda por esses recursos não é uniforme, é correlacionada pela difusão do bloco. Isso pode afetar negativamente a produção de blocos ou resultar em falhas de sincronização do blockchain. Em algumas condições, o desempenho pode se degradar de forma não linear (por exemplo, adicionar um segundo nó pode reduzir o desempenho em mais de 50%). Para eliminar tais riscos, é importante analisar os requisitos de desempenho não apenas para a carga típica, mas também para casos limites.

Manutenção e atualização

A manutenção e as atualizações do sistema devem ser sempre consideradas. Embora a migração de uma instância virtualizada para novo hardware, ou a duplicação de uma instância em execução possa parecer fácil, isso geralmente resulta em alguma interrupção de temporização. Isso é mais significativo em um ambiente em tempo real (como o Cardano) do que para aplicativos de processamento de dados típicos, que geralmente têm altos níveis de replicação e redundância. As atualizações do sistema também podem ter efeitos inesperados no desempenho do sistema virtualizado ou, ocasionalmente, na funcionalidade. Portanto, os SPOs precisam estar cientes da manutenção do sistema subjacente e tomar as medidas apropriadas para evitar a perda de blocos (e renda).

Concentração geográfica e física

Os sistemas virtualizados geralmente são concentrados em alguns grandes data centers. Isso cria pontos potenciais de falhas comuns na rede, incluindo a dependência de porções específicas das infraestruturas nacionais (backbones da internet, redes de energia, etc.). Grandes SPOs devem visar dispersar suas operações por várias regiões e operadores muito grandes devem visar uma presença global.

Provisionamento

Para garantir a resiliência e robustez globais da rede, SPOs que operam grandes pools de stake devem ter cuidado especial com:

Configuração da pool de stake

1. As configurações de rede devem garantir conectividade suficiente com outras pools de stake (incluindo aquelas executadas por outros operadores).
2. Os efeitos da virtualização devem ser considerados cuidadosamente: dada a natureza pulso da difusão do bloco, é fácil sobrecarregar recursos físicos de computação, memória e rede. Ao contrário de uma operação de banco de dados ou serviço da web típico, as pools de stake do Cardano têm requisitos de computação e rede em tempo real. Não é recomendável compartilhar recursos do servidor entre várias pools de stake ou nós de retransmissão.
3. As pools de stake devem sempre ser apoiadas por nós de retransmissão suficientes (dois ou mais). Isso reduz o risco de falha de um único nó de retransmissão, que pode potencialmente isolar um nó produtor de blocos. A falha de um nó produtor de blocos deve afetar apenas a produção de blocos para essa única pool de stake. É particularmente importante que os grandes SPOs assumam essa responsabilidade, pois estão recebendo uma proporção maior das recompensas de operação para a rede.
4. Para apoiar a escalabilidade da capacidade de retransmissão, é desejável usar nomes DNS que mapeiam para múltiplos endereços IP e/ou usar múltiplas entradas DnsName on-chain. Idealmente, essas entradas devem ser suportadas por infraestrutura de rede desconjuntiva (por exemplo, ISPs ou caminhos físicos diferentes).

Preferências de segurança

1. Chaves frias nunca devem ser armazenadas em servidores ativos (especialmente servidores em nuvem).
2. Chaves de pagamento devem ser mantidas separadas das chaves de assinatura de blocos. Airgaps devem ser mantidos entre as pools de stake e os sistemas usados para assinatura de transações.
3. Carteiras de hardware ou outros meios seguros devem ser usados para proteger chaves frias. Uma carteira de hardware pode ser necessária por conjunto de chaves (por exemplo, por pool de stake), e essas podem precisar ser fisicamente protegidas.
4. Chaves de backup também devem ser mantidas de forma segura para cada pool de stake.

Conselhos gerais:

1. Considere o desempenho do hardware, incluindo memória, armazenamento e capacidades de rede.
2. Realize uma análise de modo de falha-efeitos para garantir que as falhas únicas de um componente de entrega sejam devidamente limitadas.
3. Considere cuidadosamente o desempenho da containerização e virtualização para eliminar a contenção excessiva de recursos comuns (por exemplo, núcleos de CPU).
4. Envie certificados de stakepool que incluam tanto o endereço IP quanto os nomes DNS.
5. Garanta que haja monitoramento adequado:
   • Recebendo a grande maioria (>90%) dos blocos dentro de 4.000ms de seu tempo de slot associado.
   • Acompanhe os tempos de produção de blocos para garantir que os recursos alocados permaneçam suficientes (isso aumentará conforme as taxas de transação e os tamanhos de bloco aumentarem).
6. Planeje a expansão dos nós de retransmissão (potencialmente em uma localização diferente) que estão associados ao seu registro de stake (mitigação de DDoS / aumentos rápidos na carga devido ao aumento da delegação para as pools de stake do SPO, etc.).
7. Planeje eventos regulares de manutenção (para minimizar o tempo de inatividade da stakepool e/ou realizar manutenção quando o cronograma de liderança indicar um intervalo adequado).
8. Planeje e exerça a recuperação de desastres a cada 3 a 6 meses.
9. Ao operar várias stake pools, distribua seus nós produtores de blocos por múltiplos continentes para limitar a interrupção na produção de blocos e eliminar as interrupções na rede em grande escala.

Configurações de topologia de sistemas e retransmissão de exemplo

Não existe uma configuração de sistema padrão, pois cada stakepool tem requisitos operacionais e preferências diferentes. É escolha de um SPO como configurar a topologia.

No entanto, levando em conta os conselhos anteriores, é recomendável que um SPO mantenha pelo menos dois e um ou mais nós de retransmissão adicionais por stakepool. No caso de executar várias stake pools, é melhor que os SPOs usem pares geograficamente diversos, distribuam nós de retransmissão pelo mundo e entrem em contato com outros SPOs (especialmente os grandes) fazendo acordos para adicionar os nós de retransmissão uns dos outros. Quanto mais SPOs tiverem acordos de compartilhamento de pares, mais provável será que seus blocos se propaguem e sejam incluídos na cadeia.

O monitoramento é importante para todos os SPOs, e é essencialmente uma responsabilidade do operador garantir a qualidade da funcionalidade de suas pools. Como exemplo de um processo de monitoramento que reflete alertas de regras do Prometheus sobre limites, pode-se dar uma olhada no repositório cardano-ops aqui.

Exemplo de topologia de retransmissão

Observação: os nós de retransmissão da IOHK são delineados como exemplos.

{
  "Producers": [
	{
  	"addr": "north-america.relays-new.cardano-mainnet.iohk.io",
  	"port": 3001,
  	"valency": 4
	},
	{
  	"addr": "asia-pacific.relays-new.cardano-mainnet.iohk.io",
  	"port": 3001,
  	"valency": 4
	},
	{
  	"addr": "europe.relays-new.cardano-mainnet.iohk.io",
  	"port": 3001,
  	"valency": 4
	}
  ]
}

Opções de configuração de nó

A opção de configuração MaxConcurrencyDeadline controla quantas tentativas o nó executará em paralelo para buscar o mesmo bloco. Considerando que obter o mesmo bloco o mais rápido possível é importante tanto para os nós de retransmissão quanto para os nós produtores de blocos, recomendamos definir o valor MaxConcurrencyDeadline como 4.

Conselhos de delegação e comprometimento

Delegação

A delegação de stake é o processo de alocação dos fundos individuais dos detentores de tokens para pools de stake coletivas. A delegação é realizada para fins de produção de blocos para garantir que a criação de blocos esteja em conformidade com o consenso proof-of-stake. Ao delegar, os detentores de tokens não transferem a propriedade da stake, votação ou outros direitos.

Geralmente, os grandes SPOs controlarão uma quantidade significativa de stake de terceiros para manter a confiança na blockchain, sendo assim responsáveis por:

• produzir blocos
• processar transações
• manter a rede Cardano
• garantir que o compromisso do proprietário seja feito
• proteger a pool (por exemplo, proteger suas chaves privadas)
• fornecer comunicações públicas sobre a pool, incluindo anúncios de aposentadoria, mudanças de preços ou outros parâmetros da pool.

Os grandes operadores não são responsáveis por distribuir recompensas de produção de blocos para delegadores, pois isso é tratado automaticamente pela blockchain. Os SPOs também não são responsáveis por proteger chaves de delegadores ou tomar delegação, votação ou outras ações em nome dos detentores de tokens. Os detentores de tokens individuais devem assumir a responsabilidade pessoal por sua própria segurança e devem tomar suas próprias decisões em termos de delegação, votação, etc.

Compromisso

O compromisso é um mecanismo importante para produzir o ecossistema saudável da Cardano. Os SPOs podem optar por comprometer parte ou toda a sua ada para a pool a fim de torná-la mais atraente para outros delegadores e, assim, aumentar o tamanho da pool como um todo. A ada comprometida pode ser fornecida tanto por um SPO quanto por outros proprietários.

Recompensas de compromisso

O compromisso influencia as recompensas que uma pool de stake pode ganhar e, portanto, as recompensas que os delegadores podem obter da pool. O valor comprometido pode ser especificado, se desejado, durante o registro da pool e pode ser alterado de epoch em epoch. Não há compromisso mínimo exigido, no entanto, também não há compromisso máximo.

Dadas duas pools de stake equivalentes, aquela com o compromisso maior ganhará mais recompensas e, portanto, será mais atraente para outros delegadores. No entanto, o SPO ou outros proprietários da pool devem atender coletivamente ao compromisso por meio de delegação. Também é importante garantir que haja fundos suficientes em endereços que usem o(s) endereço(s) do proprietário da pool como referência de stake. Não cumprir o compromisso significará que nenhuma recompensa poderá ser ganha para a pool por nenhum proprietário ou delegador. Isso geralmente resultará na perda de delegação e possivelmente no colapso da pool.

Diferentemente da delegação, o SPO é responsável por distribuir todas as recompensas de compromisso. Isso pode ser feito de qualquer maneira acordada e não é imposto pela blockchain.

A operação coletiva de pools de stake (mantida por um operador e um grupo de proprietários, comprometendo sua stake) requer confiança mútua e é uma boa maneira de construir uma pool maior enquanto compartilha os riscos e recompensas.

Defesa contra ataques Sybil

O mecanismo de compromisso é projetado para mitigar contra ataques Sybil, que teoricamente poderiam permitir que uma rede de prova de participação fosse tomada sem fornecer uma participação pessoal significativa. Ao tornar as pools com compromissos maiores mais atraentes, tais ataques são evitados. A fórmula de compromisso é projetada para que uma pool com um compromisso maior produza recompensas maiores e, portanto, se torne mais atraente. Para conduzir um ataque Sybil, um adversário deve dividir seu compromisso entre um grande número de pools. Como isso diluirá cada compromisso de pool, os delegadores serão motivados pelo mecanismo de recompensas a re-delegar para pools não adversárias.