White Paper Técnico EOS.IO v2 - Português

White Paper Técnico EOS.IO v2
16 de março de 2018

Resumo: O software EOS.IO introduz uma nova arquitetura blockchain projetada para permitir o dimensionamento vertical e horizontal de aplicativos descentralizados. Isso é obtido criando-se uma construção semelhante a um sistema operacional, sobre a qual os aplicativos podem ser construídos. O software fornece contas, autenticação, bancos de dados, comunicação assíncrona e agendamento de aplicativos em muitos núcleos ou clusters de CPU. A tecnologia resultante é uma arquitetura blockchain que pode, em última análise, ser dimensionada para milhões de transações por segundo, elimina as taxas de usuários e permite a implantação e manutenção rápida e fácil de aplicativos descentralizados, no contexto de uma blockchain governada.

POR FAVOR, NOTE: TOKENS CRIPTOGRÁFICOS NESTE WHITE PAPER SE REFEREM A TOKENS CRIPTOGRÁFICOS EM UMA BLOCKCHAIN​​ QUE ADOTA O SOFTWARE EOS.IO. NÃO CONSIDERAM OS TOKENS COMPATÍVEIS COM O ERC-20 DISTRIBUÍDOS NA BLOCKCHAIN DO ETHEREUM EM CONEXÃO COM A DISTRIBUIÇÃO DOS TOKENS DO EOS.

Copyright © 2018 block.one

Sem permissão, qualquer um pode usar, reproduzir ou distribuir qualquer material neste white paper para uso não comercial e educacional (ou seja, que não seja por uma taxa ou para fins comerciais) desde que a fonte original e o aviso de copyright aplicável sejam citados.

ISENÇÃO DE RESPONSABILIDADE: Este white paper técnico EOS.IO v2 é apenas para fins informativos. A Block.one não garante a precisão ou as conclusões alcançadas neste white paper, e este white paper é fornecido "como está". A Block.one não faz e expressamente renuncia a todas as representações e garantias, expressas, implícitas, estatutárias ou de qualquer outro tipo, incluindo, mas não limitadas a: (i) garantias de comerciabilidade, adequação a uma finalidade específica, adequação, uso, título ou não-infração; (ii) que o conteúdo deste white paper esteja livre de erros; e (iii) que tais conteúdos não violem os direitos de terceiros. A Block.one e suas afiliadas não terão nenhuma responsabilidade por danos de qualquer espécie decorrentes do uso, referência ou confiança neste white paper ou qualquer conteúdo contido neste documento, mesmo se avisados ​​da possibilidade de tais danos. Em nenhuma hipótese a Block.one ou suas afiliadas serão responsáveis ​​perante qualquer pessoa ou entidade por quaisquer danos, perdas, responsabilidades, custos ou despesas de qualquer natureza, direta ou indireta, consequencial, compensatória, incidental, real, exemplar, punitiva ou especial. para o uso, referência ou confiança neste white paper ou qualquer conteúdo contido neste documento, incluindo, sem limitação, qualquer perda de negócios, receitas, lucros, dados, uso, boa vontade ou outras perdas intangíveis.

Por Trás da Tecnologia

A tecnologia Blockchain foi introduzida em 2008 com o lançamento da moeda Bitcoin, e desde então os empreendedores e desenvolvedores tentaram generalizar a tecnologia para suportar uma ampla gama de aplicações em uma única plataforma Blockchain.

Embora várias plataformas Blockchain tenham se esforçado para suportar aplicativos funcionais descentralizados, somente algumas Blockchains específicas, como o BitShares Descentralized Exchange (2014) e a plataforma de mídia social Steem (2016), tornaram-se Blockchains com dezenas de milhares de usuários ativos diariamente. Eles conseguiram isso aumentando o desempenho para milhares de transações por segundo, reduzindo a latência para 1,5 segundo, eliminando as taxas por transação e proporcionando uma experiência do usuário semelhante àquelas oferecidas atualmente pelos serviços centralizados existentes.

Em geral, as plataformas Blockchain atuais são sobrecarregadas por grandes taxas e capacidade computacional limitada que impedem a adoção generalizada da tecnologia Blockchain.

Requisitos para Aplicações Blockchain

Para obter amplo uso, os aplicativos na Blockchain exigem uma plataforma flexível o suficiente para atender aos seguintes requisitos:

Suporte a Milhões de Usuários

Competir com empresas como eBay, Uber, AirBnB e Facebook requer tecnologia Blockchain capaz de lidar com dezenas de milhões de usuários ativos diariamente. Em certos casos, um aplicativo pode não funcionar, a menos que uma massa crítica de usuários seja atingida e, portanto, uma plataforma que possa lidar com números muito grandes de usuários é primordial.

Uso Livre

Os desenvolvedores de aplicativos precisam da flexibilidade para oferecer aos usuários serviços gratuitos; os usuários não devem ter que pagar para usar a plataforma ou se beneficiar de seus serviços. Uma plataforma Blockchain que é gratuita para usuários provavelmente obterá uma adoção mais ampla. Desenvolvedores e empresas podem criar estratégias de monetização eficazes.

Atualizações Fáceis e Recuperação de Bugs

As empresas que criam aplicativos baseados em Blockchain precisam da flexibilidade para aprimorar seus aplicativos com novos recursos. A plataforma deve suportar software e atualizações de contrato inteligentes.
Todo software não-trivial está sujeito a erros, mesmo com a mais rigorosa verificação formal. A plataforma deve ser robusta o suficiente para consertar bugs quando eles inevitavelmente ocorrerem.

Baixa Latência

Uma boa experiência do usuário exige um feedback confiável com um atraso de não mais do que alguns segundos. Atrasos mais longos frustram os usuários e tornam os aplicativos construídos em uma Blockchain menos competitivo com as alternativas não-Blockchain existentes. A plataforma deve suportar baixa latência de transações.

Desempenho Sequencial

Existem alguns aplicativos que simplesmente não podem ser implementados com algoritmos paralelos devido a etapas sequencialmente dependentes. Aplicativos como Corretoras precisam de desempenho sequencial suficiente para lidar com volumes altos. Portanto, a plataforma deve suportar um desempenho sequencial rápido.

Desempenho Paralelo

Aplicativos de grande escala precisam dividir a carga de trabalho em várias CPUs e computadores.

Algoritmo de Consenso (BFT-DPOS)

O software EOS.IO utiliza o único algoritmo de consenso descentralizado conhecido e comprovado capaz de atender aos requisitos de desempenho de aplicações na Blockchain, Prova Delegada de Participação (DPOS). Sob esse algoritmo, aqueles que possuem tokens em uma Blockchain que adotam o software EOS.IO podem selecionar produtores de bloco por meio de um sistema de votação de aprovação contínua. Qualquer pessoa pode optar por participar da produção em bloco e terá a oportunidade de produzir blocos, desde que consiga persuadir os detentores de tokens a votarem neles.

O software EOS.IO permite que os blocos sejam produzidos exatamente a cada 0,5 segundo e exatamente um produtor está autorizado a produzir um bloco em um determinado ponto no tempo. Se o bloco não for produzido no horário programado, o bloco desse intervalo de tempo será ignorado. Quando um ou mais blocos são ignorados, há um intervalo de 0,5 ou mais segundos na Blockchain.

Usando o software EOS.IO, os blocos são produzidos em rodadas de cento e vinte e seis (6 blocos cada, vezes 21 produtores). No início de cada rodada, vinte e um produtores únicos de blocos são escolhidos por preferência dos votos expressos pelos detentores dos tokens. Os produtores selecionados são agendados em uma ordem acordada por quinze ou mais produtores.

Se um produtor perder um bloco e não tiver produzido nenhum bloco nas últimas 24 horas, ele será removido da consideração até que notifique a Blockchain de sua intenção de começar a produzir blocos novamente. Isso garante que a rede funcione sem problemas, minimizando o número de blocos perdidos por não agendar os produtores que comprovadamente não são confiáveis.

Em condições normais, uma Blockchain de DPOS não experimenta nenhuma bifurcação porque, ao invés de competir, os produtores de blocos cooperam para produzi-los. No caso de haver uma bifurcação, o consenso mudará automaticamente para a cadeia mais longa. Esse método funciona porque a taxa na qual os blocos são adicionados a uma ramificação da Blockchain é diretamente correlacionada à porcentagem de produtores de blocos que compartilham o mesmo consenso. Em outras palavras, uma ramificação com mais produtores crescerá mais rápido do que uma com menos produtores, porque o garfo com mais produtores experimentará menos blocos perdidos. Além disso, nenhum produtor de blocos deve produzir blocos em dois garfos ao mesmo tempo. Um produtor de blocos flagrado fazendo isso provavelmente será eliminado. Evidência criptográfica de tal dupla produção também pode ser usada para remover automaticamente abusadores. A Tolerância a Faltas Bizantinas é adicionada aos DPOS tradicionais permitindo que todos os produtores assinem todos os blocos, desde que nenhum produtor assine dois blocos com o mesmo timestamp ou na mesma altura de bloco. Uma vez que 15 produtores tenham assinado um bloco, este bloco é considerado irreversível. Qualquer produtor bizantino teria que gerar evidência criptográfica de sua traição, assinando dois blocos com a mesma data e hora. Sob este modelo, um consenso irreversível deve ser alcançável dentro de 1 segundo.

Confirmação de Transação

As Blockchains DPOS típicas têm 100% de participação do produtor de bloco. Uma transação pode ser considerada confirmada com 99,9% de certeza após uma média de 0,25 segundos a partir do momento da transmissão. Além do DPOS, o EOS.IO adiciona Tolerância de Falha Bizantina Assíncrona (aBFT) para obter uma irreversibilidade mais rápida. O algoritmo aBFT fornece 100% de confirmação de irreversibilidade em 1 segundo.

Transação como Prova de Participação (TaPoS)

O software EOS.IO exige que todas as transações incluam parte do hash de um cabeçalho de bloco recente. Esse hash tem duas finalidades:

1. Impede a reprodução de uma transação em garfos que não incluem o bloco referenciado;
2. Sinaliza para a rede que um usuário em particular e sua participação estão em uma bifurcação específica.
   Com o tempo, todos os usuários acabam confirmando diretamente na Blockchain, o que dificulta a falsificação de cadeias, pois a falsificação não seria capaz de migrar transações da cadeia legítima.

Contas

O software EOS.IO permite que todas as contas sejam referenciadas por um único nome legível por humanos, com até doze caracteres de comprimento. O nome é escolhido pelo criador da conta. O criador da conta deve reservar a RAM necessária para armazenar a nova conta até que a nova conta implemente tokens para reservar sua própria RAM. Em um contexto descentralizado, os desenvolvedores de aplicativos pagarão o custo nominal da criação da conta para inscrever um novo usuário. As empresas tradicionais já gastam quantias significativas de dinheiro por cliente que adquirem na forma de publicidade, serviços gratuitos, etc. O custo de financiamento de uma nova conta na Blockchain deve ser insignificante em comparação. Felizmente, não há necessidade de criar contas para usuários já inscritos por outro aplicativo.

Manipulação de Eventos

Cada conta pode enviar Eventos estruturados para outras contas e pode definir scripts para utilizar tais Eventos quando eles são recebidos. O software EOS.IO fornece a cada conta seu próprio banco de dados privado, que só pode ser acessado por seus próprios manipuladores de eventos.. Os scripts de manipulação de eventos também podem enviar eventos para outras contas. A combinação de eventos e manipuladores de evento de forma automatizada é como o EOS.IO define contratos inteligentes. Para dar suporte à execução paralela, cada conta também pode definir qualquer número de escopos no banco de dados. Os produtores de bloco programarão a transação de forma que não haja conflito sobre o acesso à memória aos escopos e, portanto, possam ser executados em paralelo.

Gerenciamento de Permissões Baseadas em Função

O gerenciamento de emissão envolve determinar se uma Ação está devidamente autorizada. A forma mais simples de gerenciamento de permissão é verificar se uma transação possui as assinaturas necessárias, mas isso implica que as assinaturas necessárias já são conhecidas. Geralmente, a autoridade está vinculada a indivíduos ou grupos de indivíduos e é frequentemente compartimentada. O software EOS.IO fornece um sistema de gerenciamento de permissão declarativo que fornece controle de alto nível e granular sobre quem pode fazer o que e quando. É essencial que o gerenciamento de autenticação e permissão seja padronizado e separado da lógica de negócios do aplicativo. Isso permite que ferramentas sejam desenvolvidas para gerenciar permissões de maneira geral e também oferecem oportunidades significativas para otimização de desempenho. Todas as contas podem ser controladas por qualquer combinação ponderada de outras contas e chaves privadas. Isso cria uma estrutura de autoridade hierárquica que reflete como as permissões são organizadas na realidade e torna o controle de vários usuários sobre as contas mais fácil do que nunca. O controle multiusuário é o maior contribuinte para a segurança e, quando usado corretamente, pode reduzir muito o risco de roubo devido a invasões. O software EOS.IO permite que as contas definam qual combinação de chaves e/ou contas pode enviar um determinado Tipo de Ação para outra conta. Por exemplo, é possível ter uma chave para a conta de mídia social de um usuário e outra para acesso à Corretora. É até possível conceder a outras contas permissão para agir em nome da conta de um usuário sem atribuí-las.

Níveis de Permissão Denominados

Usando o software EOS.IO, as contas podem definir níveis de permissão nomeados, cada um dos quais pode ser derivado de seu nível de permissão. Cada nível de permissão nomeado define uma autoridade; uma autoridade é um limite de verificação de assinatura múltipla que consiste em chaves e/ou níveis de permissão nomeados de outras contas. Por exemplo, o nível de permissão "Amigo" de uma conta pode ser definido para que uma Ação na conta seja controlada igualmente por qualquer um dos amigos da conta. Outro exemplo é a Blockchain Steem, que possui três níveis de permissão nomeados: proprietário, ativo, e postagem. A permissão de postagem só pode realizar ações sociais, como votação e postagem, enquanto a permissão ativa pode fazer tudo, exceto alterar o proprietário. A permissão do proprietário é destinada ao armazenamento a frio e é capaz de fazer tudo. O software EOS.IO generaliza este conceito, permitindo que cada titular de conta defina sua própria hierarquia, bem como o agrupamento de ações.

Mapeamento de Permissão

O software EOS.IO permite que cada conta defina um mapeamento entre um contrato/ ação ou contrato de qualquer outra conta e seu próprio nível de permissão nomeada. Por exemplo, um titular de conta pode mapear o aplicativo de mídia social do proprietário da conta para o grupo de permissão "Amigo" do proprietário da conta. Com esse mapeamento, qualquer amigo poderia postar como o titular da conta nas mídias sociais do titular da conta. Mesmo que eles postassem como o titular da conta, eles ainda usariam suas próprias chaves para assinar a Ação. Isso significa que sempre é possível identificar quais amigos usaram a conta e de que maneira.

Avaliando as Permissões

Ao entregar uma ação do tipo "Ação", de @alice para @bob, o software EOS.IO primeiro verificará se @alice definiu um mapeamento de permissão para @ bob.groupa.subgroup.Action. Se nada for encontrado, então um mapeamento para @ bob.groupa.subgroup e @ bob.groupa, e por último @bob será verificado. Se nenhuma correspondência adicional for encontrada, o mapeamento assumido será para o grupo de permissões nomeado @ alice.active.
Uma vez identificado um mapeamento, a autoridade de assinatura será validada usando o processo de multisinatura de limite e a autoridade associada à permissão nomeada. Se isso falhar, ele será transferido para a permissão pai e, finalmente, para a permissão do proprietário, @ alice.owner.

Grupos de Permissões Padrão

A tecnologia EOS.IO também permite que todas as contas tenham um grupo "proprietário" que possa fazer tudo e um " "grupo ativo" que pode fazer tudo exceto mudar o grupo de dono. Todos os outros grupos de permissões são derivados de "ativos".

Avaliação Paralela de Permissões

O processo de avaliação de permissão é "somente leitura" e as alterações feitas nas permissões não são efetivadas até o final de um bloco. Isso significa que todas as chaves e avaliação de permissão para todas as transações podem ser executadas em paralelo. Além disto, isso significa que uma validação rápida de permissão é possível sem iniciar uma lógica de aplicativo dispendiosa que teria que ser revertida. Por fim, isso significa que as permissões de transação podem ser avaliadas à medida que as transações pendentes são recebidas e não precisam ser reavaliadas à medida que são aplicadas. Tudo considerado, a verificação de permissão representa uma porcentagem significativa do cálculo necessário para validar as transações. Tornar isso um processo de somente leitura e fácil de funcionar em paralelo permite um aumento dramático no desempenho. Ao reproduzir a blockchain para regenerar o estado determinístico do log de Ações, não há necessidade de avaliar as permissões novamente. O fato de uma transação estar incluída em um bom bloco conhecido é suficiente para pular esta etapa. Isso reduz drasticamente a carga computacional associada à repetição de uma blockchain crescente.

Ações com Atraso Obrigatório

As Ações com Atraso Obrigatório são um componente crítico da segurança. Na maioria dos casos, não é possível saber se uma chave privada foi roubada até que tenha sido usada. A segurança baseada em tempo é ainda mais crítica quando as pessoas têm aplicativos que exigem que as chaves sejam mantidas em computadores conectados à Internet para uso diário. O software EOS.IO permite que os desenvolvedores de aplicativos indiquem que determinadas ações devem aguardar um período mínimo após serem incluídas em um bloco antes de poderem ser aplicadas. Durante esse período, eles podem ser cancelados. Os usuários podem receber um aviso via e-mail ou mensagem de texto quando uma dessas ações for transmitida. Se eles não autorizaram, poderão usar o processo de recuperação de conta para recuperar sua conta e cancelar a Ação. O atraso necessário depende de quão sensível é uma operação. Pagar por um café pode não ter nenhum atraso e ser irreversível em segundos, enquanto a compra de uma casa pode exigir um período de limpeza de 72 horas. A transferência de uma conta inteira para um novo controle pode levar até 30 dias. Os atrasos exatos são escolhidos pelos desenvolvedores de aplicativos e usuários.

Recuperação de Chaves Roubadas

O software EOS.IO fornece aos usuários uma maneira de restaurar o controle de suas contas quando as chaves são roubadas. O proprietário de uma conta pode usar qualquer chave de proprietário que estava ativa nos últimos 30 dias, juntamente com a aprovação de seu parceiro de recuperação de conta designado, para redefinir a chave do proprietário em sua conta. O parceiro de recuperação de conta pode redefinir o controle da conta sem a ajuda do proprietário. Não há nada para o hacker ganhar ao tentar passar pelo processo de recuperação porque eles já "controlam" a conta. Além disso, se eles passassem pelo processo, o parceiro de recuperação provavelmente exigiria identificação e autenticação de múltiplos fatores (telefone e email). Isso provavelmente comprometeria o hacker ou não levaria nada ao hacker no processo. Esse processo também é muito diferente de um simples arranjo de assinatura múltipla. Com uma transação de assinatura múltipla, outra entidade é parte de todas as transações executadas. Em contrapartida, com o processo de recuperação, o parceiro de recuperação é apenas uma parte do processo de recuperação e não tem poder sobre as transações do dia-a-dia. Isso reduz drasticamente os custos e as responsabilidades legais de todos os envolvidos.

Execução Paralela Determinística de Aplicações

O consenso da cadeia de bloqueio depende de um comportamento determinístico (reprodutível). Isso significa que toda execução paralela deve estar livre do uso de mutexes ou outras formas primitivas de travamento. Sem bloqueios, deve haver alguma forma de garantir que as transações que podem ser executadas em paralelo não criem resultados não determinísticos. A versão de junho de 2018 do software EOS.IO será executada com encadeamento único, mas conterá as estruturas de dados necessárias para futuras programações assincronas, execução paralela. Em uma blockchain baseada em software EOS.IO, uma vez que a operação paralela é ativada, o trabalho do produtor de blocos será organizar a entrega da Ação em fragmentos independentes para que possam ser avaliados em paralelo. O cronograma é a saída de um produtor de blocos e será executado de forma determinística, mas o processo para gerar o cronograma não precisa ser determinístico. Isso significa que os produtores de bloco podem utilizar algoritmos paralelos para agendar transações. A execução paralela significa que, quando um script gera uma nova Ação, ela não é entregue imediatamente; em vez disso, ela é programada para ser entregue no próximo ciclo. O motivo pelo qual não pode ser entregue imediatamente é porque o receptor pode modificar ativamente seu próprio estado em outro fragmento.

Minimizar a Latência de Comunicação

A duração de uma mensagem é o tempo que uma conta leva para enviar uma Ação para outra conta e receber uma resposta. O objetivo é permitir que duas contas troquem ações para frente e para trás em um único bloco, sem ter que esperar 0,5 segundos entre cada ação. Para permitir isso, o software EOS.IO divide cada bloco em ciclos. Cada ciclo é dividido em shards e cada shard contém uma lista de transações. Cada transação contém um conjunto de ações a serem entregues. Essa estrutura pode ser visualizada como uma árvore onde as camadas alternadas são processadas sequencialmente e em paralelo.

Blocos
Região
Ciclos (Sequenciais)
Fragmentos (paralelos)
Transações (sequenciais)
Ações (sequenciais)
Receptor e Contas Notificadas (paralelas)

As transações geradas em um ciclo podem ser entregues em qualquer ciclo ou bloco subsequente. Os produtores de blocos continuarão adicionando ciclos a um bloco até que o tempo máximo programado tenha passado ou não haja novas transações geradas para entregar. É possível usar a análise estática de um bloco para verificar que dentro de um determinado ciclo não há dois fragmentos contendo transações que modifiquem a mesma conta. Contanto que essa invariante seja mantida, um bloco pode ser processado executando-se todos os fragmentos em paralelo.

Manipuladores de Evento Somente para Leitura

Algumas contas podem ser capazes de processar uma ação em uma base de aprovação/ reprovação sem modificar seu estado interno. Se esse for o caso, esses manipuladores podem ser executados em paralelo, desde que apenas os manipuladores de Evento somente para leitura de uma conta específica sejam incluídos em um ou mais fragmentos dentro de um ciclo específico.

Transações Atômicas com Múltiplas Contas

Às vezes, é desejável assegurar que as ações são entregues e aceitas por várias contas atomicamente. Nesse caso, ambas as ações são colocadas em uma transação e ambas as contas receberão o mesmo fragmento e as ações serão aplicadas sequencialmente.

Avaliação Parcial do Estado da Blockchain

Uma tecnologia de Blockchain escalável exige que os componentes sejam modulares. Nem todos devem ter que executar tudo, especialmente se precisarem usar apenas um pequeno subconjunto dos aplicativos. Um desenvolvedor de aplicativos de troca executa nós completos com o objetivo de exibir o estado de troca para seus usuários. Este aplicativo de troca não precisa do estado associado aos aplicativos de mídia social. O software EOS.IO permite que qualquer nó completo escolha qualquer subconjunto de aplicativos para executar. As ações entregues a outros aplicativos são ignoradas com segurança se o seu aplicativo nunca depender do estado de outro contrato.

Melhor Agendamento Subjetivo de Esforços

O software EOS.IO não pode obrigar os produtores de bloco a entregar qualquer Ação a qualquer outra conta. Cada produtor de bloco faz sua própria medição subjetiva da complexidade computacional e do tempo necessário para processar uma transação. Isso se aplica se uma transação é gerada por um usuário ou automaticamente por um contrato inteligente.
No lançamento de uma Blockchain que adote o software EOS.IO, em um nível de rede, todas as transações recebem um custo computacional de largura de banda baseado no número de instruções WASM executadas. No entanto, cada produtor de bloco individual usando o software pode calcular o uso de recursos usando seu próprio algoritmo e medidas. Quando um produtor de blocos conclui que uma transação ou conta consumiu uma quantidade desproporcional da capacidade computacional, eles simplesmente rejeitam a transação quando produzem seu próprio bloco; no entanto, eles ainda processarão a transação se outros produtores de bloco a considerarem válida.
Em geral, desde que até um produtor de bloco considere uma transação como válida e sob os limites de uso de recursos, todos os outros produtores também a aceitarão, mas pode levar até um minuto para a transação localizar esse produtor.
Em alguns casos, um produtor pode criar um bloco que inclui transações que estão em uma ordem de magnitude fora dos intervalos aceitáveis. Nesse caso, o próximo produtor do bloco pode optar por rejeitar o bloco e o empate será quebrado pelo terceiro produtor. Isso não é diferente do que aconteceria se um grande bloco causasse atrasos de propagação de rede. A comunidade notaria um padrão de abuso e, eventualmente, removeria os votos do produtor trapaceiro.
Essa avaliação subjetiva do custo computacional libera a Blockchain de ter que medir com precisão e deterministicamente quanto tempo algo leva para ser executado. Com este design, não há necessidade de contar com precisão as instruções, o que aumenta drasticamente as oportunidades de otimização sem quebrar o consenso.

Transações Diferidas

O software EOS.IO suporta transações diferidas programadas para execução no futuro. Isso permite que a computação se mova para shards diferentes e/ou a criação de processos de longa execução que agendam continuamente uma transação de continuação.

Ações Livres de Contexto

Uma Ação Livre de Contexto envolve cálculos que dependem apenas dos dados da transação, mas não do estado da Blockchain. A verificação de assinatura, por exemplo, é uma computação que requer apenas os dados da transação e uma assinatura para determinar a chave pública que assinou a transação. Este é um dos cálculos individuais mais caros que uma blockchain deve executar, mas como este cálculo é livre de contexto, ele pode ser executado em paralelo.
Ações livres de contexto são como outras Ações do usuário, exceto que elas não têm acesso ao estado da Blockchain para realizar a validação. Isso não só permite que o software EOS.IO processe todas as Ações Livres do Contexto, como a verificação de assinaturas em paralelo, mas, o mais importante, possibilita a verificação de assinaturas generalizada.
Com o suporte a Ações Livres do Contexto, técnicas de escalabilidade como Sharding, Raiden, Plasma, Canais de Estado e outros se tornam muito mais paralelizáveis ​​e práticas. Este desenvolvimento permite comunicação inter-blockchain eficiente e escalabilidade potencialmente ilimitada.

Modelo de Toque e Uso de Recursos

POR FAVOR, NOTE: TOKENS CRIPTOGRÁFICOS NESTE WHITE PAPER SE REFEREM A TOKENS CRIPTOGRÁFICOS EM UMA BLOCKCHAIN​​ QUE ADOTA O SOFTWARE EOS.IO. NÃO CONSIDERAM OS TOKENS COMPATÍVEIS COM O ERC-20 DISTRIBUÍDOS NA BLOCKCHAIN DO ETHEREUM EM CONEXÃO COM A DISTRIBUIÇÃO DOS TOKENS DO EOS.

Todas as Blockchains tem recursos restritos e requerem um sistema para evitar abusos. Com uma Blockchain que usa o software EOS.IO, existem três grandes classes de recursos que são consumidos pelos aplicativos:

1. Largura de Banda e Armazenamento de Log (Disco);
2. Computação e Backlog Computacional (CPU);
3. Armazenamento do Estado (RAM).

A largura de banda e o cálculo têm dois componentes, uso instantâneo e uso a longo prazo. Uma Blockchain mantém um log de todas as ações e esse log é finalmente armazenado e baixado por todos os nós completos. Com o log de ações, é possível reconstruir o estado de todos os aplicativos.
O custo computacional deve ser calculado de forma que a performance possa regenerar o estado do log de ações. Se a dívida computacional se torna muito grande, torna-se necessário tirar instantâneos do estado da Blockchain e descartar o histórico dela. Se a dívida computacional cresce muito rapidamente, pode levar seis meses para reproduzir um ano de transações. É fundamental, portanto, que a dívida computacional seja cuidadosamente gerenciada.
O armazenamento de estado da Blockchain é uma informação acessível a partir da lógica do aplicativo. Inclui informações como carteiras de pedidos e saldos de contas. Se o estado nunca for lido pelo aplicativo, ele não deverá ser armazenado. Por exemplo, o conteúdo e os comentários da postagem do blog não são lidos pela lógica do aplicativo, portanto, eles não devem ser armazenados no estado da Blockchain. Enquanto isso, a existência de um post/comentário, o número de votos e outras propriedades ficam armazenadas como parte do estado da Blockchain.
Os produtores de bloco publicam a sua capacidade disponível para largura de banda, computação e estado. O software EOS.IO permite que cada conta consuma uma porcentagem da capacidade disponível proporcional à quantidade de tokens mantidos em um contrato de piquetagem de três dias. Por exemplo, se uma Blockchain baseada no software EOS.IO for lançada e se uma conta tiver 1% do total de tokens distribuídos nesta blockchain, então essa conta tem o potencial de utilizar 1% da capacidade de armazenamento do estado.
Adotar o software EOS.IO em uma Blockchain significa que a largura de banda e a capacidade computacional são alocadas em uma base de reserva fracionária, porque elas são transientes (capacidade não utilizada não pode ser salva para uso futuro). O algoritmo usado pelo software EOS.IO é semelhante ao algoritmo usado pelo Steem para limitar o uso da largura de banda de limite.

Medições Objetivas e Subjetivas

Como discutido anteriormente, instrumentalizar o uso computacional tem um impacto significativo no desempenho e na otimização; portanto, todas as restrições de uso de recursos são, em última análise, subjetivas, e a imposição é feita pelos produtores de blocos de acordo com seus algoritmos e estimativas individuais. Estes seriam tipicamente implementados por um produtor de blocos através da escrita de um plugin personalizado.
Dito isto, há certas coisas que são triviais para medir objetivamente. O número de ações entregues e o tamanho dos dados armazenados no banco de dados interno são baratos para medir objetivamente. O software EOS.IO permite que os produtores de blocos apliquem o mesmo algoritmo sobre essas medidas objetivas, mas podem optar por aplicar algoritmos subjetivos mais rígidos em relação a medidas subjetivas.

Receber Pagamentos

Tradicionalmente, é a empresa que paga pelo espaço do escritório, energia computacional e outros custos necessários pra tocar o negócio. O cliente compra produtos específicos da empresa e a receita dessas vendas de produtos é usada para cobrir os custos comerciais da operação. Da mesma forma, nenhum site obriga seus visitantes a fazer micropagamentos para visitar seu site para cobrir os custos de hospedagem. Portanto, aplicativos descentralizados não devem forçar seus clientes a pagar diretamente pelo uso da blockchain.
A Blockchain que utilizar o software EOS.IO não exigirá que seus usuários paguem a Blockchain diretamente pelo seu uso e, portanto, não restringirá ou impedirá que uma empresa determine sua própria estratégia de monetização para os seus produtos.
Embora seja verdade que o receptor pode pagar, o EOS.IO permite que o remetente pague pela largura de banda, computação e armazenamento. Isso permite que os desenvolvedores de aplicativos escolham o método que é melhor para a sua aplicação. Em muitos casos, o fato de o remetente pagar tais operações reduz significativamente a complexidade para os desenvolvedores de aplicativos que não desejam implementar seu próprio sistema de racionamento. Os desenvolvedores de aplicativos podem delegar largura de banda e computação aos seus usuários e, em seguida, permitir que o modelo “remetente paga” se imponha. Do ponto de vista do usuário final, ele é gratuito, mas do ponto de vista da Blockchain isto ficara a cargo do remetente-pagador.

Delegando Capacidade

Um detentor de tokens em uma Blockchain que adota o software EOS.IO que não tiver uma necessidade imediata de consumir todos ou parte da largura de banda disponível, pode delegar ou alugar essa largura de banda não consumida a outras pessoas; os produtores de blocos que executam o software EOS.IO em tais blockchains irão reconhecer esta delegação de capacidade e de alocar os custos de forma adequada.

Separando os Custos de Transação do Valor do Token

Um dos principais benefícios do software EOS.IO é que a quantidade de largura de banda disponível para uma aplicação é inteiramente independente de qualquer preço simbólico. Se um proprietário do aplicativo tiver um número relevante de tokens em uma Blockchain que adota o software EOS.IO, o aplicativo poderá ser executado indefinidamente dentro de um estado fixo e uso de largura de banda. Neste caso, os desenvolvedores e usuários não são afetados por qualquer volatilidade de preço no mercado de tokens e, portanto, não dependem de um de determinado preço. Em outras palavras, uma Blockchain que adota o software EOS.IO permite que os produtores de blocos aumentem a largura de banda, a computação e o armazenamento disponíveis por token independentemente do valor do token.
Uma Blockchain usando o software EOS.IO também concede tokens aos produtores de bloco toda vez que eles produzem um bloco. O valor dos tokens afetará a quantidade de largura de banda, armazenamento e computação que um produtor pode comprar; Esse modelo naturalmente aproveita os valores de token crescente para aumentar o desempenho da rede.

Custos de Armazenamento do Estado

Embora a largura de banda e a computação possam ser delegadas, o armazenamento do estado do aplicativo exigirá que um desenvolvedor de aplicativos armazene tokens até que esse estado seja excluído. Se o estado nunca for excluído, os tokens serão efetivamente tirados de circulação.

Recompensas dos Blocos

Uma Blockchain que adota o software EOS.IO concederá novos tokens a um produtor de bloco sempre que um bloco for produzido. Nessas circunstâncias, o número de tokens criados é determinado pela mediana da remuneração desejada publicada por todos os produtores de bloco. O software EOS.IO pode ser configurado para impor um teto aos prêmios do produtor, de forma que o aumento anual total do fornecimento de token não exceda 5% .

Sistema de Proposta de Trabalho

Além de eleger produtores de bloco, de acordo com uma Blockchain baseada no software EOS.IO, os detentores de token podem eleger várias Propostas de Trabalhadores destinadas a beneficiar a comunidade. As propostas vencedoras receberão tokens de até um percentual configurado da inflação do token menos os tokens que foram pagos para os produtores de blocos. Essas propostas receberão tokens proporcionais aos votos que cada aplicativo recebeu dos detentores dos tokens, até o valor que eles solicitarem para realizar seu trabalho. As propostas eleitas podem ser substituídas por propostas recém-eleitas pelos detentores de tokens.
Os contratos de sistema que implementam Propostas de Trabalhadores podem não estar em vigor no lançamento inicial em junho de 2018, mas o mecanismo de financiamento estará. Ele começará a acumular fundos ao mesmo tempo em que os prêmios de produtor de bloco começarem. Uma vez que o Sistema de Proposta do Trabalhador será implementado no WASM, ele pode ser adicionado em uma data posterior sem uma bifurcação.

Governança

Governança é o processo pelo qual as pessoas em uma comunidade:

1. Alcançam consenso em assuntos subjetivos de ação coletiva que não podem ser capturados inteiramente por algoritmos de software;
2. Executam as decisões estabelecidas consensualmente;
3. Alteram as regras de governança por meio de emendas constitucionais.

Uma Blockchain baseada em software EOS.IO implementa um processo de governança que direciona eficientemente a influência existente dos produtores de blocos. Sem um processo de governança definido, as Blockchains anteriores se baseavam em processos de governança ad hoc, informais e frequentemente controversos que resultam em resultados imprevisíveis. Uma Blockchain baseada no software EOS.IO reconhece que a energia é originada com os detentores de token que delegam essa energia aos produtores de Blocos. Os produtores de bloco recebem autoridade limitada e verificada para congelar contas, atualizar aplicativos defeituosos e propor mudanças através de bifurcações críticas no protocolo subjacente.
Incorporado ao software EOS.IO está a eleição de produtores de blocos. Antes que qualquer mudança possa ser feita na Blockchain, esses produtores de bloco devem aprová-la. Se os produtores do bloco se recusarem a fazer mudanças desejadas pelos detentores dos tokens, eles podem ser eliminados. Se os produtores de bloco fizerem alterações sem a permissão dos detentores de tokens, todos os outros validadores de nó completo não produtivos (trocas, etc.) rejeitarão a alteração.

Congelamento de Contas

Às vezes, um contrato inteligente se comporta de maneira aberrante ou imprevisível e não performa como pretendido; outras vezes, um aplicativo ou conta pode descobrir uma exploração que permite consumir uma quantidade irracional de recursos. Quando tais problemas inevitavelmente ocorrem, os produtores de blocos têm o poder de corrigir tais situações.
Os produtores de blocos em todas as Blockchains têm o poder de selecionar quais transações são incluídas nos blocos, o que lhes dá a capacidade de congelar as contas. Uma Blockchain usando o software EOS.IO formaliza essa autoridade ao sujeitar o processo de congelamento de uma conta a um voto de 15/21 de produtores ativos. Se os produtores abusarem do poder, eles poderão ser descartados e uma conta será descongelada.
Mudando o Código da Conta
Quando tudo mais falha e uma "aplicação imparável" age de maneira imprevisível, uma blockchain usando o software EOS.IO permite que os produtores de blocos substituam o código da conta sem uma bifurcação da blockchain inteira. Semelhante ao processo de congelamento de uma conta, essa substituição do código exige um voto de 15/21 dos produtores de bloco eleitos.

Constituição

O software EOS.IO permite que as Blockchains estabeleçam um contrato de termos de serviço peer-to-peer ou um contrato vinculativo entre aqueles usuários que o assinam, e a isto nos referimos como "constituição". O conteúdo desta constituição define obrigações entre os usuários que não podem ser totalmente aplicadas por código e facilita a resolução de disputas estabelecendo jurisdição e escolha de lei junto com outras regras mutuamente aceitas. Toda transação transmitida na rede deve incorporar o hash da constituição como parte da assinatura e, assim, vincular explicitamente o assinante ao contrato.
A constituição também define a legíbilidade do protocolo do código-fonte. Esta característica é usada para identificar a diferença entre um bug e um recurso quando ocorrem erros e orienta a comunidade sobre quais correções são adequadas ou impróprias.

Atualizando o Protocolo e a Constituição

O software EOS.IO define o seguinte processo pelo qual o protocolo, conforme definido por o código fonte canônico e sua constituição, podem ser atualizados:

1. Os produtores em bloco propõem uma mudança na constituição e obtêm aprovação em 15/21.
2. Os produtores de blocos mantêm a aprovação da nova constituição em 15/21 por 30 dias consecutivos.
3. Todos os usuários são obrigados a indicar aceitação da nova constituição como condição para o processamento de transações futuras.
4. Os produtores de blocos adotam mudanças no código-fonte para refletir a mudança na constituição e propõem-no à Blockchain usando o hash da nova constituição.
5. Os produtores de blocos mantêm 15/21 aprovação de o novo código por 30 dias consecutivos.
6. As mudanças no código entram em vigor sete dias depois, dando a todos os nós completos não produtores uma semana para atualizar após a ratificação do código-fonte.
7. Todos os nós que não atualizam para o novo código desligam automaticamente.
   Por padrão, a configuração do software EOS.IO, o processo de atualização da blockchain para adicionar novos recursos leva de dois a três meses, enquanto atualizações para corrigir bugs não críticos que não exigem alterações na constituição podem levar de um a dois meses.

Mudanças de emergência

Os produtores de bloco podem acelerar o processo se uma alteração de software for necessária para corrigir um bug prejudicial ou uma exploração de segurança que esteja prejudicando ativamente os usuários. De modo geral, pode ser prejudicial para a constituição atualizações precipitadas para introduzir novos recursos ou corrigir bugs inofensivos.

Scripts & Máquinas Virtuais

O software EOS.IO será, antes de mais nada, uma plataforma para coordenar a entrega de mensagens autenticadas (chamadas Ações) às contas. Os detalhes da linguagem de script e da máquina virtual são detalhes específicos da implementação que são, em sua maioria, independentes do design da tecnologia EOS.IO. Qualquer linguagem ou máquina virtual que seja determinística e adequadamente protegida com desempenho suficiente pode ser integrada com o software EOS.IO API.

Esquematização de Ações Definidas

Todas as ações enviadas entre contas são definidas por um esquema que faz parte do estado de consenso da Blockchain. Esse esquema permite a conversão contínua entre a representação binária e JSON do estado
Banco de Dados Definido pelo Esquema
O estado do banco de dados também é definido usando um esquema semelhante. Isto garante que todos os dados armazenados por todos os aplicativos estejam em um formato que possa ser interpretado como JSON legível por humanos, mas armazenado e manipulado com a eficiência do binário.

API Genérica de Banco de Dados de Vários Índices

Desenvolver contratos inteligentes requer um esquema de banco de dados definido para rastrear, armazenar e localizar dados. Em geral, os desenvolvedores precisam dos mesmos dados classificados ou indexados por vários campos e manter a consistência entre todos os índices.

Separando Autenticação do Aplicativo

Para maximizar as oportunidades de paralelização e minimizar a dívida computacional associada ao estado do aplicativo em regeneração a partir do log de transações, o software EOS.IO separa a lógica de validação em três seções:

1. Validação de uma ação que é internamente consistente;
2. Validação de que todas as pré-condições são válidas; e
3. Modificação do estado do aplicativo.

Validar a consistência interna de uma ação é somente leitura e não requer acesso ao estado da Blockchain. Isso significa que pode ser executada com o máximo paralelismo. A validação de condições prévias, como o equilíbrio necessário, é somente leitura e, portanto, também pode se beneficiar do paralelismo. Apenas a modificação do estado do aplicativo requer acesso de gravação e deve ser processada seqüencialmente para cada aplicativo.
A autenticação é o processo somente leitura de verificação a que uma ação pode ser aplicada. A aplicação está realmente fazendo o trabalho. Em tempo real, ambos os cálculos são necessários para serem executados, no entanto, uma vez que uma transação é incluída na Blockchain, não é mais necessário realizar as operações de autenticação.

Comunicação Inter-Blockchain

O software EOS.IO foi projetado para facilitar a comunicação entre Blockchains. Isto é conseguido facilitando a geração de prova de existência de Ação e prova de seqüência de Ação. Estas provas, combinadas com uma arquitetura de aplicativo projetada em torno do Action Pass, permitem que os detalhes da comunicação Inter-Blockchain e da validação de prova sejam ocultados dos desenvolvedores de aplicativos, permitindo que abstrações de alto nível sejam apresentadas aos desenvolvedores.
A validação da Prova de Merkle Para Clientes Leves (LCV)
A integração com outras Blockchains é muito mais fácil se os clientes não precisarem processar todas as transações. Afinal, uma Corretora só se preocupa com transferências para dentro e para fora da Corretora e nada mais. Também seria ideal se um grupo de Corretoras pudesse utilizar provas de Merkle leves para depósitos em vez de confiar inteiramente em seus próprios produtores de blocos. No mínimo, os produtores de blocos de uma cadeia gostariam de manter a menor sobrecarga possível ao sincronizar com outra Blockchain.
O objetivo do LCV é possibilitar a geração de provas de existência relativamente leves que podem ser validadas por qualquer pessoa que rastreie um conjunto de dados relativamente leve. Nesse caso, o objetivo é provar que uma determinada transação foi incluída em um determinado bloco e que o bloco está incluído no histórico verificado de uma determinada Blockchain.
O Bitcoin suporta a validação de transações assumindo que todos os nós tenham acesso ao histórico completo de cabeçalhos de bloco. o que equivale a 4MB de cabeçalhos de bloco por ano. Em 10 transações por segundo, uma prova válida requer cerca de 512 bytes. Isso funciona bem para um blockchain com um intervalo de bloco de 10 minutos, mas não é o mais "leve" para Blockchains com um intervalo de bloco de 0.5 segundos.
O software EOS.IO permite provas leves para qualquer um que tenha algum cabeçalho de bloco irreversível após o ponto em que a transação foi incluída. Usando a estrutura de hash-linked mostrada é possível provar a existência de qualquer transação com uma prova menor que 1024 bytes de tamanho.
Quando é dado a qualquer id de bloco um bloco na Blockchain, os cabeçalhos de um bloco serão confiáveis e irreversíveis. É possível provar que o bloco está incluído na Blockchain. Este conceito pode ser provado por (log2 (N)), onde N é o número de blocos na cadeia. Dado um método de compilação de SHA256, você pode provar a existência de qualquer bloco em uma cadeia que contém 100 milhões de blocos em 864 bytes.
Há pouca sobrecarga associada à produção de blocos com a própria vinculação de hash para habilitar essas provas, o que significa que não há razão para não gerar blocos dessa maneira.
Quando chega a hora de validar provas em outras cadeias, há uma grande variedade de otimizações de tempo/ espaço/ largura de banda que podem ser feitas. O rastreamento de todos os cabeçalhos de bloco (420 MB / ano) manterá os tamanhos de prova pequenos. O rastreamento somente de cabeçalhos recentes pode oferecer uma troca entre o armazenamento mínimo de longo prazo e o tamanho da prova. Alternativamente, uma Blockchain pode usar uma abordagem de avaliação preguiçosa, onde se lembra de hashes intermediários de provas passadas. Novas provas só precisam incluir links para a árvore esparsa conhecida. A abordagem exata usada dependerá necessariamente da porcentagem de blocos estrangeiros que incluem transações referenciadas pela prova de merkle.
Após uma certa densidade de interconectividade, torna-se mais eficiente simplesmente ter uma cadeia contendo todo o histórico de blocos de outra cadeia e eliminar a necessidade de provas todas juntas. Por razões de desempenho, é ideal para minimizar a frequência das provas inter-cadeias.

Latência da Comunicação Intermediária

Ao comunicar-se com uma Blockchain externa, os produtores de bloco devem esperar até que haja 100% de certeza de que uma transação foi confirmada irreversivelmente pela outra Blockchain antes de aceitar como uma entrada válida. Usando uma Blockchain baseada em software EOS.IO e DPOS com blocos de 0,5 segundo e a adição de irreversibilidade tolerante a falhas bizantinas, isso leva aproximadamente 0,5 segundo. Se os produtores de blocos de uma cadeia não esperassem pela irreversibilidade, seria como uma Corretora creditando um depósito que foi posteriormente revertido e poderia impactar a validade do consenso da Blockchain. O Software EOS.IO usa DPOS e aBFT para fornecer irreversibilidade rápida.

Prova de Completude

Ao usar provas de merkle de Blockchains externas, há uma diferença significativa entre saber que todas as transações processadas são válidas e saber que nenhuma transação foi ignorada ou omitida. Embora seja impossível provar que todas as transações mais recentes são conhecidas, é possível provar que não houve lacunas no histórico de transações. O software EOS.IO facilita isto atribuindo um número de seqüência a cada ação entregue a cada conta. Um usuário pode usar esses números de sequência para provar que todas as ações destinadas a uma conta específica foram processadas e processadas em ordem.

Testemunha Segregada

O conceito de Testemunha Segregada (SegWit) é de que as assinaturas de transação não são relevantes depois que uma transação incluída é imutável na Blockchain. Uma vez que é imutável, os dados de assinatura podem ser removidos e todos os outros ainda podem derivar do estado atual. Como as assinaturas representam uma grande porcentagem da maioria das transações, o SegWit representa uma economia significativa no uso do disco e no tempo de sincronização.
Este mesmo conceito pode ser aplicado às provas de merkle usadas para comunicação Inter-Blockchain. Uma vez que uma prova seja aceita e irreversivelmente registrada na Blockchain, os hashes de 2 KB de sha256 usados ​​pela prova não são mais necessários para derivar o estado adequado da blockchain. No caso de comunicação Inter-Blockchain, essa economia é 32x maior que a economia com assinaturas normais.
Outro exemplo de SegWit seria para posts de blog Steem. Sob esse modelo, uma postagem conteria apenas o sha256 (conteúdo do blog) e o conteúdo do blog estaria nos dados de Testemunhas Segregadas. O produtor do bloco verificaria se o conteúdo existe e tem o hash fornecido, mas o conteúdo do blog não precisaria ser armazenado para recuperar o estado atual do log da Blockchain. Isto permite a prova de que o conteúdo já foi conhecido sem ter que armazenar esse conteúdo para sempre.

Conclusão

O software EOS.IO foi projetado com base na experiência com conceitos comprovados e práticas recomendadas e representa avanços fundamentais na tecnologia Blockchain. O software faz parte de um projeto holístico para uma sociedade Blockchain globalmente escalável, na qual os aplicativos descentralizados podem ser facilmente implantados e gerenciados.

https://github.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md