Plataforma de blockchain R-chain: arquitetura geral e evolução

Olá a todos que acompanham o desenvolvimento do uso de plataformas descentralizadas em processos corporativos e inter-corporativos. Nossas publicações sobre este assunto foram interrompidas no início de 2018. Não, o Raiffeisenbank não parou de trabalhar nessa direção: chegou a hora de passar dos cálculos metodológicos e da familiarização com as capacidades das tecnologias individuais para a implementação de casos de negócios específicos em um ambiente industrial ou o mais próximo possível. Este artigo é bastante volumoso e ao mesmo tempo informativo. Portanto, esperamos o seu envolvimento e alertamos sobre o formato do tutorial.











Em 2016-2017, concluímos uma série de projetos de pesquisa para construir uma plataforma descentralizada de financiamento do comércio. Usei o teste Ethereum (Rinkeby) como a plataforma de razão distribuída subjacente e o Ethereum Swarm como uma ferramenta de compartilhamento de arquivos descentralizada. Além de questões gerais de construção de uma plataforma descentralizada, testamos as possibilidades de contratos inteligentes, o uso de oráculos e contratos inteligentes de arbitragem. Alguns desses resultados são





Com base nesses projetos de pesquisa,





O resultado desse trabalho bastante demorado foi, como dizem os militares, a “aceitação para fornecimento” do IT Raiffeisenbank da plataforma R-Chain descentralizada regular. Agora é oferecido como um elemento de serviço ao cliente para grupos corporativos de vários tamanhos.



Compartilhamos as principais características da construção desta plataforma e também falamos sobre a evolução do uso de vários componentes "técnicos" nela - plataformas de blockchain e sistemas de arquivos distribuídos.

Conteúdo

• Recursos de sistemas corporativos e inter-corporativos
• Arquitetura geral da plataforma
  
  
  • Arquitetura do componente de software
  • Processo de negócios completo
  • Benefícios de usar um processo de negócios completo
  • Desvantagens de usar um processo de negócios genérico
  • Monitoramento de rede host
• Evolução do uso de vários componentes técnicos
• Experiência em pesquisa e operação de plataformas corporativas e seu posterior desenvolvimento

Recursos de sistemas corporativos e inter-corporativos

Para que a implantação da plataforma em operação industrial ocorra de maneira tranquila e sem excessos inesperados para os desenvolvedores, é necessário entender que a plataforma proposta ao futuro participante deve atender aos seguintes requisitos:

• A plataforma deve ter um operador - pessoa jurídica que seja responsável perante os participantes pelo seu funcionamento. A opção - cada um por si, tudo será decidido pelo consenso dos participantes, e assim por diante, típico de plataformas públicas de blockchain, não funcionará aqui.
• , . , - - 15 — , .
• « » , . , , , « » , .
• , , . , — .
• «» . , - — , , . , , — , .

Muitos nesta lista ficarão surpresos ao descobrir que as palavras "transações por segundo" e outras classificações de desempenho estão faltando. Nossa experiência mostra que a produtividade não é a condição mais importante para o sucesso da implementação de uma plataforma. O desempenho precisa ser "suficiente" e há muitas arquiteturas de fluxo de dados que podem aumentar drasticamente o rendimento da plataforma subjacente - de registradores de dados a turbo streams laterais. A probabilidade de seu projeto morrer devido à falta de atenção aos pontos acima é hiperbolicamente maior.

Arquitetura geral da plataforma

Arquitetura do componente de software

Os aplicativos que usamos em nossos projetos de pesquisa em 2016-2017 foram escritos com base na integração direta de interfaces de diálogo com os componentes "técnicos" da plataforma distribuída - geth e swarm. Mas, tendo analisado as possibilidades e consequências desta abordagem, chegamos à conclusão de que é necessário introduzir outra camada entre o backend de negócios e os componentes "técnicos" - um adaptador de objetos de negócios unificados. Essa técnica pertence a padrões razoavelmente padronizados para a construção de arquitetura de software, o que, no entanto, não reduz sua eficácia. Como resultado, a arquitetura de software do nó de nossa plataforma começou a se parecer com isto:







Nesta arquitetura, o aplicativo de negóciosnão trabalha diretamente com abstrações de componentes DLT, mas com um certo "processo de negócios universal" condicional (doravante denominado processo) - cria um processo, altera o estado do processo. A redução da estrutura de dados do processo universal e operações sobre ele aos dados e operações utilizadas no cliente DLT é realizada por um conjunto de componentes designados como "Espelho de processos de negócios". O "espelho" também realiza a transformação reversa das informações recebidas do cliente DLT, e também filtra as informações por processos que não são relacionados ao participante - o dono do nó. Assim, em cada nó, um banco de dados de processos de negócios do qual este nó faz parte é mantido em estado síncrono e no formato que for mais conveniente para um aplicativo de negócios . Aplicação de Negóciosinterage com este banco de dados - um banco de dados de processos de negócios, recebendo informações sobre o estado dos processos e transferindo operações para alterar esses estados.

Processo de negócios completo

Naturalmente, surgiu a questão de quais propriedades devem ser dotadas de um processo de negócios universal para que forneça, por um lado, o máximo aproveitamento das vantagens das plataformas de blockchain e, por outro lado, o máximo de flexibilidade e funcionalidade para uso em um Aplicativo de Negócios. Uma condição adicional era a capacidade de implementar as propriedades selecionadas na maioria das plataformas DLT comuns, cuja funcionalidade é significativamente diferente em alguns aspectos (Ethereum / Quorum / Masterchain, Hyperledger Fabric, Corda, EOS, Waves). Com base na experiência de nossos projetos e de outros, chegamos às seguintes conclusões.



Um processo de negócios universal deve ter os seguintes atributos:

• Parâmetros do processo (tipo de processo, status, atributos de contexto do processo)
• Lista de funções dos participantes do processo
• Lista de documentos eletrônicos relacionados ao processo
• Mapa de transição de processos

Ao mesmo tempo, a plataforma deve, no nível do componente blockchain, fornecer as seguintes condições para a propagação do processo na rede:

• Completude e integridade da informação
• Confidencialidade de documentos eletrônicos fora do círculo de participantes do processo
• Controle de seguir o mapa de transição do processo
• Armazenando o histórico de mudanças nos estados do processo

Para implementar esses recursos, foram desenvolvidos contratos inteligentes de “estrutura” com os conjuntos correspondentes de propriedades e métodos.



Vamos nos deter em alguns dos atributos e condições listados - o quê, como e por quê.



Parâmetros do processo- são condicionalmente abertos, uma vez que são transmitidos diretamente por meio de um contrato inteligente. Para algumas plataformas de blockchain, eles são fundamentalmente públicos (Ethereum / Masterchain), para outros podem ser fechados por meios padrão para garantir a privacidade de dados (Quorum - contratos inteligentes privados, Hyperledger Fabric - canais e dados privados). Provavelmente o mais importante dos parâmetros do “núcleo” do processo em nossa implementação é o “tipo de processo”, uma vez que carrega não apenas carga semântica, mas também funcional - dependendo do “tipo de processo”, o adaptador DLT escolhe um modelo de contrato inteligente que esse processo será apresente-se. Por que isso é necessário? Obviamente, existem inúmeros tipos de transações e os mesmos diversos processos de negócios que garantem sua implementação.Em um número bastante grande de casos, os processos de negócios diferem essencialmente apenas no mapa de transição (do ponto de vista da plataforma) e podem ser implementados com um único contrato inteligente que suporta um mapa de transição arbitrário (mais sobre isso abaixo). Mas momentos bastante únicos podem ser associados a um processo de negócios específico:

• (, )
• (, )
• (, )

Tentar formalizar, "formatar" e amontoar toda essa diversidade potencial em um único modelo de contratos inteligentes é absolutamente utópico. O desenvolvimento de um modelo exclusivo para um tipo específico de processo de negócios é uma maneira muito mais eficiente, fornecendo alta flexibilidade e a capacidade de atualizar "fortemente" os elementos de processo necessários e verificações críticas diretamente no "núcleo" do componente blockchain. Isso excluirá qualquer possibilidade de manipulação por participantes individuais. Além disso, a plataforma como um todo combinará a unificação de interfaces para a interação de aplicações de negócios com processos e alta modularidade de implementação de suas funcionalidades específicas.



Os "atributos do kernel" do nosso processo também incluem "status" e "nota": o primeiro é uma breve descrição do estado do processo ("Novo", "Cancelado", "Fechado", "OnApproval"), o segundo é uma string "longa" com uma descrição mais detalhada do "status". Limitamos o comprimento de uma nota a algo em torno de 1000 caracteres (por exemplo, "Fundos insuficientes na conta"), uma vez que os documentos eletrônicos anexados ao processo se destinam a transferir quantidades significativas de informações (especialmente confidenciais).



Mapa de transição de processos- descreve se um participante com uma função específica pode alterar o estado do processo e para qual. O controle sobre a admissibilidade das transições é realizado pelo "núcleo" do componente blockchain e não pode ser forjado por um participante "impotente". Além disso, o mapa de navegação pode, por exemplo, ser usado por um aplicativo de negócios para determinar as possíveis ações do proprietário do nó no status atual do processo para o gerenciamento apropriado de componentes de diálogo.



Transferência de dados confidenciais.Para a transferência de informações confidenciais, são utilizados documentos eletrônicos que acompanham o processo. O aplicativo de negócios carrega os documentos necessários para o armazenamento de arquivo local "Espelhos" e os indica na operação para alterar o estado do processo. Antes de transferir do armazenamento local para o DFS, o documento é criptografado com as chaves públicas dos nós destinatários - participantes do processo. Depois que o contêiner de criptografia gerado é transferido para o DFS, o link para ele e o hash do documento original são transferidos para o contrato inteligente do processo. Após o recebimento de informações sobre uma mudança no estado do processo, os detalhes do arquivo são extraídos para o banco de dados do processo de negócios e, em seguida, o cripto-contêiner é extraído do DFS usando o link e descriptografado com a chave do nó receptor. Uma verificação é feita para garantir que o hash do documento especificado no contrato inteligente do processo corresponda,o documento é colocado no armazenamento de arquivo local e fica disponível para o aplicativo de negócios. Assim, a aplicação empresarial funciona apenas com a versão "aberta" do documento - todas as preocupações quanto à sua transferência segura são assumidas pelo "Mirror".



O histórico da mudança de estado do processo é uma sequência de "quadros", cada um dos quais corresponde a uma operação de mudança de estado do processo. Em nossa implementação, armazenamos os seguintes dados para cada "quadro" do histórico:

• status
• Nota
• o identificador do iniciador da transação de mudança de estado

O histórico de mudanças é registrado no nível de contrato inteligente e permite não apenas rastrear a sequência de transições para fins de auditoria, mas também permite que o aplicativo de negócios processe corretamente a cadeia de eventos, mesmo no caso de sua chegada única (por exemplo, congelamento, interrupção no funcionamento, etc.).



Garantir significado legal- uma questão muito importante, observada por nós na seção "Características dos sistemas corporativos e inter-corporativos". Inicialmente partimos do conceito de que o significado jurídico não deve ser fornecido por meio de uma plataforma de blockchain, mas por meio do uso de uma PKI externa que tenha suporte regulamentar ou um nível adequado de confiança entre os participantes da plataforma. Em termos gerais, um documento eletrônico que forneça uma base legal para suas ações (documento de pagamento, contrato, demanda, etc.) e anexado ao processo deve ser assinado com base em uma PKI "kosher" (na Rússia - GOST, em algum lugar no exterior, por exemplo, SSL ou PGP / GPG). O aplicativo de negócios verificará a assinatura "externa" e executará a ação apropriada. Ou não, dependendo do resultado. Alguem vai dizerque isso não é "evangélico" e "precisamos convencer os advogados do significado legal das transações de blockchain". Percorremos várias etapas dessa jornada e o resultado foi sempre o mesmo. No entanto, no caso da RússiaA certificação Masterchain abre certas oportunidades a esse respeito - como diz o ditado "Boa caça!"

Benefícios de usar um processo de negócios completo

O que essa abordagem nos deu no final?

• Expandindo o círculo de desenvolvedores potenciais de aplicativos de negócios descentralizados. «» - - , - «» , . . -, Corda, «» Ethereum, Quorum. , - «» - .
• «» . , , , , , - . , «» «» ( ), «- » . , « , ...», . «» -, «» . , «» -, . , - , . , , , , , , «» insufficient funds for gas * price + value gas required exceeds allowance or always failing transaction.
• «» -. - - , -. -, , 75-95% . , , « , » . , :
  
  
  
  >>> - DFS, , , «» -. Ethereum, «» . - (TON!), . , . … , , .
  
  
  
  >>> - . , Ethereum — , , , , , — .
• . . . , , , , , , . , , , , — .
• . , , « , ». , . — -. , - ( ) — - .

-

Aqui, provavelmente, como é cantado em uma canção famosa - "Atrás deles você pode ouvir um murmúrio ..." - por exemplo, que o Hyperledger Fabric ou Corda chaincode, ao contrário do Solidity um pouco elegante demais, permite que você implemente uma lógica quase infinitamente complexa de processos de negócios, e esta abordagem profana sua funcionalidade. Bem, sim, eles estarão absolutamente certos. Para os murmuradores, vou lembrá-los de várias mensagens bem conhecidas do campo da engenharia de software:

• Onde colocar a lógica de negócios - nos procedimentos armazenados do banco de dados ou no código dos aplicativos de negócios?
• O que é melhor - um mainframe ou um computador especial?
• Tem certeza de que a linha de base escolhida manterá a compatibilidade nas atualizações futuras? E em geral ele vai sobreviver nos próximos 2 anos?

A resposta é bastante simples se:

• Você tem muito dinheiro, tempo e especialistas em blockchain grátis
• Você tem certeza de que a base do blockchain que você escolheu não terá que ser alterada da palavra "nunca"
• Você realmente precisa "espremer" os recursos da plataforma em 101%

Bem, então - uma calculadora especial ... no sentido de Hyperledger Fabric ou Corda com costura no cheyncode e outro "corte de cinzel na pedra". Se não, pense por si mesmo ...

Monitoramento de rede host

Talvez para alguns seja uma revelação, mas um monitoramento bem organizado é a base para a operação bem-sucedida de sistemas de software em uma empresa. E esse conceito inclui não apenas (e nem tanto) o monitoramento da infraestrutura padrão dos servidores, mas o monitoramento funcional dos componentes de software. A sua plataforma distribuída não deve apenas funcionar corretamente, mas também errar corretamente, fornecendo ao serviço de suporte uma quantidade suficiente de informações sãs que lhe permitam identificar, identificar e corrigir rapidamente uma falha. É ainda melhor se o sistema de monitoramento tiver recursos proativos - ele permite que você identifique "coisas ruins" em potencial e bloqueie suas possíveis consequências antes que "aconteçam".



Se a cada momento você não entende em que estado os nós de sua rede estão e o que está acontecendo neles, mas vão funcionar "de acordo com os sinais dos usuários", é melhor liberar imediatamente espaço na fila e não perder o tempo de seus queridos clientes.



Com base no acima exposto, desde o início do desenvolvimento de nossa plataforma, um sistema de monitoramento pró-ativo foi integrado nela. Vamos descrever o princípio de seu funcionamento:

• Na base do blockchain da plataforma, um contrato inteligente especial é estabelecido que é responsável pela coleta e distribuição de dados de monitoramento (para ser breve, vamos nos referir a este contrato inteligente como SCM)
• , (), « », , . , - .
• - « », — .
• DFS- « », .
• , DFS .
• , , :
  
  >
  
  > «» -
  
  > «» DFS
  
  > - ( Ethereum- )
  
  > «»
  
  > «» — , «»
  
  > «»
  
  > «»
  
  > trilha de auditoria de aplicativos de negócios

Em um determinado valor ou combinação de valores para indicadores de monitoramento, o Mirror automaticamente pausa o processamento de suas filas de operações, bloqueia o aparecimento de possíveis consequências indesejáveis, por exemplo:

• No caso de um atraso crítico no rótulo de controle do canal do blockchain, que é interpretado como um nó saindo da rede do blockchain ou uma interrupção completa de seu funcionamento
• Em caso de atraso crítico no rótulo de controle do canal DFS, que é interpretado como a perda de um nó da rede DFS ou uma interrupção completa de seu funcionamento
• Em caso de erros na fila de operações, todas as operações subsequentes associadas a este objeto de negócios (processo de negócios universal) são bloqueadas

Atenção especial foi dada ao tratamento de erros de banco de dados usados ​​pelo "Mirror". Este banco de dados é usado não apenas como uma interface com aplicativos de negócios, mas também como uma pilha de status para a máquina de estado das filas de operação "Espelho". A experiência tem mostrado que, na presença de erros específicos ao alterar dados nas tabelas do banco de dados, as operações de loop podem ocorrer com reenvio massivo de transações e outros prazeres. Certa vez, por erro semelhante, em dois dias “fizemos” um volume semestral da rede no Quorum. Portanto, se um erro desse tipo for detectado, "Mirror" é totalmente desligado e aguarda uma resposta manual do serviço de suporte.



Os nós de monitoramento central recuperam informações de todos os nós da rede (inclusive eles próprios, aliás) do SCM e as analisam, permitindo a detecção oportuna de condições perigosas ou potencialmente perigosas como, por exemplo:

• - DFS-
• - DFS-
• -
• «»
• «»

A imagem abaixo mostra um exemplo de monitor simples para uma de nossas redes de teste:







Mais esquemas de monitoramento proativo de "nível superior" foram desenvolvidos e implementados, incluindo aplicativos de negócios, mas aqui chegamos à fronteira instável da propriedade intelectual de clientes específicos.



Não vamos esconder o fato de que, em algumas de nossas redes de blockchain, monitorar o tráfego constitui a esmagadora maioria do tráfego total. A este respeito, pensou-se mesmo em utilizar um horário flutuante para a frequência das "parcelas de sondagem" - mais frequentemente durante o horário de trabalho, menos frequentemente durante o período não laboral. Mas vale a pena. Sério.



Em geral, monitore tudo o que puder, contanto que a largura de banda de sua rede descentralizada permita. Você vai louvar os Deuses da Programação mais de uma ou duas vezes, bem, e os autores deste artigo, é claro :)



Pois como diz uma das interpretações da lei de Murphy: "O erro geralmente está em uma posição da qual ninguém duvida."

Evolução do uso de vários componentes técnicos

Tendo considerado as condições gerais para a implantação e operação de redes corporativas descentralizadas, bem como os princípios arquitetônicos que usamos para construir a plataforma R-Chain, agora nos voltamos para a história de como e por que seus componentes técnicos individuais evoluíram no processo de implementação de projetos específicos.



O primeiro foi o projeto de emissão de uma garantia internacional , em que nossos parceiros eram colegas da Bielo-Rússia - março-dezembro de 2018.



Começamos com a configuração Ethereum - Ethereum Swarm - Crypto-Pro (DLT-DFS-criptografia), que tem se mostrado bem em projetos de pesquisa. Em vez da rede PoA de teste pública Ethereum Rinkeby usada, foram criadas a rede privada Ethereum PoA e a rede privada Ethereum Swarm. Inicialmente, nenhum problema técnico surgiu, mas encontramos um problema "criptográfico" - um dos participantes bielorrussos se recusou terminantemente a usar as ferramentas de criptografia que oferecemos, referindo-se à lei local sobre gerenciamento eletrônico de documentos. Naquela época, não era possível encontrar uma solução de alta qualidade “no momento”, mas havia um entendimento constante do difícil e importante papel da criptografia no sucesso de projetos internacionais.



Já no processo de execução de transações de controle na infraestrutura de rede real (cada participante implantou um nó em seus recursos), foram identificadas falhas no trabalho do Ethereum Swarm - as perdas de arquivos foram da ordem de 20%. Foi sugerido que a perda se deve a problemas no cliente Swarm ao enviar vários arquivos em paralelo. Em geral, essa suposição foi confirmada: experimentalmente, conseguimos encontrar uma pausa entre o envio de arquivos individuais para o Swarm em 5 segundos. Durante a transição para uma configuração de rede totalmente de combate, que, devido às peculiaridades da segmentação de rede aplicada na infraestrutura do Raiffeisenbank, exigiu a criação de um nó de trânsito Swarm, surgiu um problema crítico - o Ethereum Swarm permitiu que até 30% dos arquivos fossem perdidos ao trabalhar através de um nó de trânsito.A arquitetura “em camadas” e o bom sistema de monitoramento permitiram realizar com sucesso a real emissão da garantia na modalidade de “bombeamento manual de gasolina”, mas o destino do Ethereum Swarm estava selado. Devo dizer que a capacidade declarada do Ethereum Swarm de trabalhar em topologias sem conexão direta remetente-receptor foi um dos principais motivos para escolhê-lo como a base tecnológica para DFS, e sua incapacidade de trabalhar de forma confiável neste modo criou muitos problemas.e sua incapacidade de trabalhar de forma confiável neste modo criou muitos problemas.e sua incapacidade de trabalhar de forma confiável neste modo criou muitos problemas.



Refira-se que a rede privada baseada no Ethereum neste projeto está satisfeita com a sua recuperabilidade. O cronograma do projeto pressupôs que o fechamento da garantia emitida seria feito 3 meses após a sua emissão, e durante esta pausa, alguns dos participantes pararam seus nodos. Porém, ao reiniciar a rede sem nenhuma dança com pandeiros em 1 dia, ela restabeleceu sua integridade, e a operação de encerramento da garantia transcorreu sem reclamações.



O próximo projeto foi a criação de uma rede intragrupo para o Grupo Ascona de Empresas - setembro de 2018 - hora atual.



Com base na experiência do projeto de garantia internacional, o IPFS (InterPlanetary File System) foi escolhido como a base tecnológica do DFS. Funcionou bem para enviar arquivos em paralelo e não exigiu ajustes de modo especiais. Talvez o único ponto fraco do IPFS seja a impossibilidade (especificada!) De trabalhar em topologias de "trânsito". Ao construir redes com um grande número de participantes, a implementação por cada um deles de uma "estrela cheia" de acesso de cada um é, para dizer o mínimo, um problema organizacional. Por outro lado, todos os participantes implementam o acesso entre eles e os nós de "suporte" do operador. Portanto, para organizar a distribuição tranquila dos arquivos, o seguinte mecanismo foi implementado:

• Quando um arquivo é anexado a um contrato inteligente de um determinado processo de negócios, o evento DeliveryFile é gerado contendo um link para o arquivo
• DeliveryFile IPFS. IPFS , , . .
• , , , «» ,

Assim, o projeto Ascona iniciou na configuração Ethereum - IPFS - Crypto-Pro.



O uso do Crypto-Pro para criptografia de arquivos e a assinatura "externa" de documentos juridicamente significativos garantiram a simplicidade da vinculação legal, bem como a ausência de reclamações dos departamentos de Segurança da Informação, o que por sua vez teve um efeito extremamente positivo no momento de obtenção das aprovações necessárias tanto do banco quanto partes nas empresas do Grupo de Empresas Ascona Em geral, o projeto se desenvolveu em bom estado de funcionamento e, tendo passado da fase piloto, estava na linha de chegada para entrar em produção e aqui ...



... e aqui em dois projetos ao mesmo tempo - condicionalmente "alien", mas em que participamos como experts, em configurações semelhantes capturamos megafifs de milhares de blocos, com a perda de transações de uma parte da rede. Uma análise dos logs e interpretações da comunidade blockchain levou a uma conclusão decepcionante - o uso de Ethereum PoA (e em alguns casos até PoW) em redes compactas com um pequeno número de nós (e as redes corporativas pertencem exatamente a este) tem um alto risco de tais monstros. Além disso, um bug misterioso começou a aparecer periodicamente em nossa rede de teste, quando um nó saiu da rede e não quis mais se sincronizar com ele. Mesmo depois de reinstalar o Ethereum e totalmente despojado. Em suma, ficou claro que a cadeia alimentar precisava de uma alternativa à base do blockchain. E rápido. Muito rápido.



A solução acabou sendo Quorum - praticamente, irmão de Ethereum. O número de melhorias no "Mirror" era mínimo, o aplicativo de negócios, é claro, não precisava de nenhuma melhoria.



No momento, a transição para o Quorum trouxe apenas vantagens:

• Consenso de jangada usado elimina garfos
• A ausência de blocos vazios reduz o tamanho da corrente

A ausência de bifurcações nos permite fazer uma pausa enquanto aguardamos a finalização condicional das transações, que antes era necessária para não lidar com um possível rollback das transações, e tínhamos até 6 ciclos de geração de blocos. Isso, em primeiro lugar, aumenta naturalmente o desempenho da plataforma e, em segundo lugar, remove problemas muito difíceis que surgem se a bifurcação excedeu a pausa calculada e o estado dos objetos de negócios "espelhados" que ele toca deixa de ser consistente com seu estado de blockchain.



A única, talvez, característica desagradável do Quorum é a capacidade de gerar um megabyte de vários megabytes ao reiniciar após uma longa pausa, o que simplesmente congestiona o adaptador DLT ao tentar descarregar seu conteúdo. Mas, estritamente falando, a central de atendimento não deve dormir tanto.



Como resultado de toda essa evolução dramática, chegamos à configuração Quorum - IPFS - Crypto-PRO , que agora usamos no mercado doméstico russo.



Talvez alguém faça uma pergunta lógica: "Bem, você nunca ouviu falar do Quorum antes ou o quê?"... Ouvimos falar do Quorum, Hyperledger Fabric e EOS. O autor deste artigo até participou do primeiro workshop Corda em russo no outono de 2017. Provavelmente, especificamente para uma resposta inteligente a tais perguntas, Hegel inventou sua Dialética. A pequena equipe que começou a pesquisa em 2016 tinha boa experiência no desenvolvimento de aplicativos interativos para Windows, e Ethereum público (o teste um é compreensível) tinha o limite de entrada mais baixo de plataformas de blockchain. E como estávamos interessados ​​em conduzir pesquisas especificamente sobre o tópico blockchain, e não em fuçar em diferentes dockers, sem os quais seria simplesmente irrealista lançar o Quorum ou Hyperledger Fabric "adulto" (e nem em todas as plataformas virtuais do Windows é possível), então a escolha era óbvio. À medida que os resultados da pesquisa começaram a atrair a atenção das unidades de negócios do banco e de seus parceiros,tornou-se possível expandir a equipe, confiar botas aos sapateiros e tortas aos bolos, obter servidores Linux e assim por diante. E, naturalmente, ninguém jogou fora as soluções desenvolvidas enquanto elas mantiveram seu potencial de desenvolvimento. Dialética e evolução.

Experiência em pesquisa e operação de plataformas corporativas e seu posterior desenvolvimento

O autor deste artigo participou de um número bastante grande de projetos de blockchain realizados no Raiffeisenbank, na FinTech Association e em alguns outros lugares - tanto como desenvolvedor quanto como especialista em plataformas descentralizadas. Alguns deles eram puramente projetos de pesquisa, alguns acabaram como pilotos, alguns cresceram para redes industriais bastante grandes de várias dezenas de nós.



Quais são as principais conclusões que podem ser tiradas de toda essa experiência?



1. Há uma certa variedade de plataformas de blockchain, que são muito diferentes em suas qualidades de "consumidor":

• "Limiar de entrada" e facilidade de implantação de rede
• largura de banda
• funcionalidade de contratos inteligentes
• opções de fechamento de informações
• tempo e custo de desenvolvimento

Portanto, acho que é impossível dizer que qualquer uma das plataformas acabará por ser absolutamente dominante. Cada um tem seu próprio círculo de usuários e tarefas potenciais, onde seu uso é mais racional e econômico. Isso se aplica a Ethereum, Quorum, Hyperledger Fabric e Corda. Aqui, como acontece com as linguagens de programação - apenas Vasya e Petya, que conhecem uma linguagem cada, vão argumentar ao ponto da estupidez sobre qual é melhor - "vantagens" ou "sapo". E Semyon Petrovich e Albert Ivanovich, que conhecem uma dúzia deles, vão conversar pacificamente - quando os "prós" são melhores, e quando - "sapo".



2. Apesar do fato de que algumas das plataformas DLT (por exemplo, Hyperledger Fabric e Corda) fornecem a capacidade de transferir grandes itens de dados - na verdade, os arquivos, muito provavelmente, a base do blockchain com mecanismos de contrato inteligentes e a funcionalidade de transferência de arquivos permanecerão separados. Isso se deve aos seguintes pontos:

• , DLT-. . Hyperledger Fabric Corda 2M « », , IPFS 100M. - - pdf (, ), 50M — , .
• - , ( + ), , .
• , , S3. , , « », , DFS. .
• , , -, «» .

3. Atualmente, há uma carência crônica de especialistas para os serviços de suporte técnico das plataformas descentralizadas. Mais precisamente, eles simplesmente não existem. Absolutamente. Na maioria dos projetos que conheço, a maior parte do trabalho de suporte técnico é feito pelos desenvolvedores ou engenheiros de pesquisa que criaram essas plataformas, o que, obviamente, não é bom. Acho que isso se deve à juventude da direção e aos poucos está em andamento o desenvolvimento de instruções técnicas, modelos de respostas, esquemas de monitoramento e outros materiais metodológicos necessários para organizar o trabalho eficiente do serviço de apoio. Um dos problemas aqui é a falta de bons cursos de visão geral em russo em plataformas de blockchain específicas. Tudo tem que ser passado de mão em mão. Mas um especialista de suporte em uma empresa não é um desenvolvedor e está focado em outras questões: monitoramento,diagnóstico de erros, garantindo a confiabilidade e recuperação dos sistemas após acidentes (você acha que não vai ter acidentes? Sim, claro). E, francamente, a probabilidade de um projeto corporativo morrer devido a um suporte insuficiente é significativamente maior do que devido à baixa qualidade de desenvolvimento. Portanto, atrair especialistas de boa qualidade com experiência no suporte e operação de sistemas corporativos é um fator importante, senão o mais importante, no fato de que o projeto viverá e se desenvolverá por um longo tempo, e não murchará assim que um casal de fundadores o deixarem.Portanto, atrair especialistas de boa qualidade com experiência no suporte e operação de sistemas corporativos é um fator importante, senão o mais importante, no fato de que o projeto viverá e se desenvolverá por um longo tempo, e não murchará assim que um casal de fundadores o deixarem.Portanto, atrair especialistas de boa qualidade com experiência no suporte e operação de sistemas corporativos é um fator importante, senão o mais importante, no fato de que o projeto viverá e se desenvolverá por um longo tempo, e não murchará assim que um casal de fundadores o deixarem.



4. Uma das áreas jurídicas mais obscuras é a formalização das relações entre o operador e os participantes da rede, o que é agravado pelo facto de o operador, por um lado, não ser o dono da rede e dos seus recursos e, por outro lado, ser obrigado a garantir o seu funcionamento, ainda que o esta medida está em conflito com os interesses dos participantes individuais. O equilíbrio entre os direitos e obrigações do operador, o seu "meio de influência" nos participantes da rede, a responsabilidade financeira do operador - tudo isto é agora objecto de disputas muito difíceis. A pergunta mais simples:Como garantir a substituição síncrona de software crítico por todos os participantes da rede, apesar de sua aparente simplicidade, resulta em discussões muito acaloradas? O surgimento de exemplos de formalização legal da posição do operador e dos participantes da rede com base na experiência de plataformas já lançadas em prod irá acelerar significativamente a introdução de redes descentralizadas como elemento significativo das relações empresariais e inter-empresariais.



Se você chegou ao fim, também há um bônus: algumas das perguntas sobre o estado atual e os caminhos de desenvolvimento das plataformas corporativas descentralizadas estão refletidas no material preparado pelo autor deste artigo para um dos recursos do blockchain (o material é projetado para uma ampla gama de leitores ).