Serviços de programa

Há coisas que uma plataforma de negociação precisa de saber sobre uma conta e que não podem ser calculadas enquanto um bloco executa. Um escalão de volume depende de trinta dias de negociação. Uma recompensa depende de uma janela que ainda não fechou. Uma atribuição de referências depende de uma relação estabelecida há meses. Colocar esse trabalho dentro da execução do bloco seria errado por duas razões: obrigaria todos os blocos a pagar por um cálculo de que quase nenhum bloco precisa e exigiria que o kernel guardasse histórico que não tem outro motivo para guardar. Os serviços de programa resolvem-no invertendo a direção. O cálculo corre fora do bloco, sobre o registo confirmado. O seu resultado é depois gravado de volta na cadeia como estado de protocolo, onde a execução o pode ler em tempo constante como qualquer outra configuração. A cadeia continua a ser a autoridade. Um serviço não guarda estado de que a rede dependa — propõe um valor, e só o que a cadeia aceitou é real.

​

O que está em funcionamento hoje

Escalões de comissões por volume. O serviço consome o histórico de negociação transmitido por um nó, acumula o volume por conta e regista instantâneos com uma periodicidade definida. Quando um período fecha, calcula o volume de cada conta na janela móvel, mapeia-o através da configuração de comissões lida em direto da cadeia e escreve de volta, em lotes, as contas que mudaram. Vários pormenores desta frase são determinantes:

• A tabela de escalões é lida da cadeia, nunca fixada no código. Um serviço com uma cópia própria continuaria a aplicar a tabela de ontem depois de a rede a ter alterado.
• A comparação é feita sobre as taxas, não sobre as posições dos escalões. Comparar índices de escalão deixa escapar dois casos reais: um limiar que se desloca e faz uma conta inalterada cair noutro escalão, e um escalão cuja taxa muda sem que o índice mude. Ambos alteram o que uma conta paga; nenhum altera o índice.
• A cadeia resolve a taxa final. A transação transporta um índice de escalão; a execução resolve-o pela configuração de comissões em vigor. Um índice de escalão fora do intervalo válido faz falhar o lote inteiro, em vez de ser aplicado parcialmente.
• Um período só é registado como aplicado depois de todos os lotes serem confirmados. Uma falha a meio do período faz reexecutar o período inteiro, o que é seguro porque o cálculo é idempotente — a mesma janela produz o mesmo resultado.

​

O modelo de falhas

Estes serviços situam-se entre dois sistemas que, em algum momento, estarão indisponíveis. O desenho parte desse princípio, em vez de tratar a indisponibilidade como excecional. As falhas de dependências — a base de dados, o fluxo do nó, a API do nó — são repetidas com espera crescente (backoff). Não terminam o processo, porque um reinício não repara uma dependência inacessível; limita-se a somar um arranque a frio à indisponibilidade. Continua a ser fatal aquilo que um reinício pode corrigir ou que um operador tem de ver: configuração inválida no arranque, incapacidade de abrir o endpoint de saúde e panics. Durante uma indisponibilidade, o processo mantém-se a correr, declara-se não pronto e contabiliza erros. O sinal operacional é, por isso, «já está há N minutos sem estar pronto?» e não «o processo está vivo?» — que é a pergunta útil, já que um processo vivo que há uma hora não consegue ingerir dados é o incidente real. O encerramento é controlado perante os sinais que um orquestrador envia: o trabalho para, os checkpoints são gravados e o processo termina de forma limpa. Sem isso, cada implantação de rotina custaria uma janela por gravar e uma reexecução.

​

Porque o padrão se generaliza

O caminho de escrita de volta é genérico. Existem transações de protocolo para definir configuração ao nível da conta e para definir configuração global, e um serviço de programa é qualquer processo que calcule um valor para uma delas a partir do histórico confirmado. Os escalões de comissões são o único caso em funcionamento. Programas de incentivos, atribuição de referências e elegibilidade para campanhas teriam a mesma forma: um cálculo por janela sobre o histórico de negociação, uma comparação com o que está atualmente aplicado e uma escrita de volta em lotes. Pertenceriam aqui, e não ao kernel, pela mesma razão que os escalões de comissões — o cálculo é periódico e histórico, ao passo que a execução precisa de que a resposta seja uma consulta em tempo constante. Nenhum deles está construído; o que se generaliza é o padrão, não um compromisso de que virão a usá-lo. As condições comerciais destes programas estão em Comissões de negociação. Esta página trata de como o resultado chega à cadeia.

​

Para onde ir a seguir