aelf - Uma Estrutura Blockchain de

Computação Paralela e Multi-Cadeias

V 1.6

7 de Junho de 2018
 Resumo
Durante os últimos anos a comunidade Blockchain tem vivenciado um rápido
desenvolvimento . Desde que o Bitcoin criado por Satoshi apareceu como um
mecanismo de transferências Peer-to-Peer seguro e descentralizado , o conceito de
uma criptomoeda descentralizada se tornou popular e mudou para sempre o mundo
das finanças. A seguir, o Ethereum expandiu essa ideia com a implementação bem-
sucedida de versáteis "Smart Contracts ”, demonstrando o potencial da Blockchain
em inúmeras aplicações e indústrias . Como resultado , muitos crypto ativos
alternativos foram construídos sobre essas Blockchains. Entretanto, a barreira entre
a comunidade Blockchain e o mundo dos negócios ainda precisa ser rompida .
Acreditamos ter chegado a um momento chave para essa tecnologia , com a
próxima fase levando à integração entre a Blockchain e o mundo físico dos negócios
, o que inevitavelmente traz consigo sólidos ativos digitais.
Para adentrar este novo paradigma que é Blockchain , é preciso um Sistema
Operacional versátil e projetado para atender as necessidades comerciais. A Cadeia
deve abranger três principais desafios:
1. As Blockchains atuais não são escaláveis , à medida que o desempenho de um
único node
/máquina de mineração determina o desempenho de todo o sistema.
2. As Blockchains atuais não separam recursos para diferentes Smart Contracts, o
que causa interferências nas execuções dos Smart Contracts.
3. As Blockchains não possuem um Protocolo de Consenso pré -definido para
adotar atualizações ou se adaptar à uma nova tecnologia.
Esse white paper apresenta uma arquitetura Blockchain altamente eficiente que
utiliza os melhores e mais inovadores princípios da Tecnologia da Informação para
colocar a Blockchain em um padrão comercial . Pretendemos criar um “Sistema
Linux” para Blockchains. Nossos objetivos são definir e prover as informações mais
básicas , essenciais e consumidoras de tempo para desenvolver componentes do
sistema, além de fazer melhoras significativas em redes já existentes no mercado. O
Sistema permite que os desenvolvedores personalizem Cadeias para atender suas
próprias necessidades , especialmente solicitações comerciais para diversas
indústrias. Serão abordados os seguintes recursos fundamentais:
1. Main Chain e Side Chains de várias camadas para lidar com os mais variados
cenários comerciais . Uma cadeia é designada para um uso específico , distribuindo
diferentes tarefas em múltiplas cadeias, melhorando assim a eficiência do processo.
2. Comunicação com sistemas de Blockchains externas como Bitcoin e Ethereum ,
através de mensagens.
3. Processamento paralelo para transações não concorrentes e serviços baseados
em nuvem.
4. Componentes básicos de um bloco viável mínimo e compilação do Smart
Contract “Genesis ” para cada Cadeia com o intuito de reduzir a complexidade dos
dados e alcançar um alto índice de personalização.

5. Permissão aos stakeholders para aprovar emendas ao Protocolo , incluindo a

redefinição do Protocolo de Consenso ; Permissão para Side Chains entrarem ou
saírem de maneira dinâmica da Main Chain, com base no Protocolo de Consenso e,
portanto, introduzir certa competição e incentivos para melhorar cada Side Chain.
Assuntos

3
4
1. Sistemas de Blockchains Atuais
A tecnologia Blockchain e suas aplicações estão se desenvolvendo
exponencialmente . Muitas indústrias estão migrando da arquitetura de rede
tradicional para uma que seja baseada na Blockchain . Entretanto , os sistemas de
Blockchain atuais ainda não são capazes ou eficientemente suficientes para
trabalharem como um sistema operacional versátil e ainda suportarem várias
aplicações . O Bitcoin , projeto pioneiro na Blockchain , é mais semelhante à um
aplicativo . O Ethereum demonstrou algumas características de um Sistema
Operacional – os desenvolvedores conseguem programar aplicações tais como
Smart Contracts e a Rede oferece uma linguagem de programação através do
Solidity . Todavia , a partir da perspectiva de um Sistema Operacional moderno , o
Ethereum ainda tem uma série de desvantagens , como falta de dissociação de
componentes do sistema , falta de customização na maioria dos módulos e
interfaces de sistema insuficientes , dentre outras . Essa abordagem carece do
design holístico da aelf e ainda não é comercialmente vável para cenários em
aplicações do tipo cross-industry . Isso limita muito a aplicabilidade commercial da
tecnologia Blockchain.
1.1. Blockchain Genérica x Cenários Comerciais Complexos
O maior desafio enfrentado para a adoção em escala comercial da tecnologia
Blockchain é a atual inabilidade de atender as solicitações de múltiplos , diversos e
complexos cenários comerciais . Naturalmente , cenários distintos geralmente tem
características diferentes em termos de processo e execução lógica , portanto são
esperadas soluções diferentes . Sendo assim, a política de que "um tamanho dá pra
tudo" que é atualmente usada por outras redes não se torna viável caso a Blockchain
venha a ser bem-sucedida no futuro. Por exemplo, a emissão de tickets requer uma
alta frequência onde uma taxa de transação alta no sistema é desejável , enquanto
contratos digitais legais enfatizam alta segurança e confiabilidade ao invés de
velocidade. Simplesmente não faz sentido estes dois exemplos serem construídos ao
redor da mesma Rede. Existem duas soluções gerais para essa questão:
i. I. Usar a Blockchain somente como um banco de dados que não lide com a
lógica dos negócios: Essa abordagem tem a intenção de lidar com qualquer
cenário comercial além de manter compatibilidade. Muitas redes similares à
do Bitcoin utilizam essa saída. Elas registram informações relacionadas aos
negócios e as guardam dentro de uma saída de transação "OP_RETURN",
a qual é armazenada na Blockchain.
ii. Registrar vários Smart Contracts complexos em uma única Blockchain :
Esses Smart Contracts se adequam à modelos de negócios pré-definidos
de vários cenários . O Ethereum representa esse tipo de Rede. Devido ao
fato de que todos os Smart Contracts são escritos em uma única Rede, a
Blockchain se torna extremamente complexa , requisitando assim um alto
custo de manutenção e ainda sem uma estrutura efetiva para executar os
smart contracts.

1.2. Limitação no Desempenho de Processamentos Sequenciais

À medida que a Blockchain se torna amplamente usada, em especial por lidar com
transações em grande escala , sua capacidade de processamento de transações
encara uma pressão imensa ao utilizar processamento sequencial, o que resulta em
gargalos na performance da rede . Os sistemas de Blockchain atuais enfrentam
vários desafios para otimizar essa capacidade , algumas vezes às custas de perder
eficiência nas transações. Por exemplo, a taxa de transação do Bitcoin está ficando
mais cara à medida que o volume de transações aumenta e um grande acúmulo se
5
forma, aguardando pela confirmação. O Ethereum encara um número crescente de
congestionamentos durante vendas de tokens. Porém, na arquitetura tradicional da
Tecnologia da Informação , técnicas modernas como particionamento
fragmentação e arquitetura descentralizada provaram ser altamente efetivas em,
melhorar o desempenho do sistema . Por outro lado, o conceito do processamento
paralelo de tarefas não foi adotado para aumentar a eficiência . Quando um bloco
contém uma grande quantidade de dados de transações e Smart Contracts
complexos , a transação sequencial atinge sua limitação de eficiência para
formação e verificação de blocos.

1.3. Complexidade das Informações e Redundância

Conforme mencionado na Seção 1.1, uma única Blockchain é utilizada para
atender as necessidades de diferentes cenários comerciais. As desvantagens de
um Sistema de Blockchain universal são Smart Contracts e Protocolos de
Consenso altamente complexos, falta de soluções apropriadas para cenários
comerciais específicos e informações redundantes..

1.4. O Dilema da Atualização de Protocolo

Apesar da crescente adoção da Blockchain , ela ainda está em seu estágio inicial.
Muitas melhorias e inovações significativas ainda estão por vir. Essas atualizações
são fundamentais para que as Blockchains possam evoluir e acompanhar tanto o
ambiente em si como o interesse dos investidores , coisas que estão em constante
mudança . A grande variedade de stakeholders dentro do ecossistema geralmente
dificulta o alcance de um consenso sem mecanismos eficientes de governança ,
fazendo com que a maioria das mudanças em protocolos atuais caiam em impasse
ou disputa . Um claro exemplo disso é o próprio Bitcoin, visto que sua comunidade
achou difícil chegar a um acordo pela introdução de muitos recursos novos nos
últimos anos.

1.5. Inflação do Bloco

Quanto mais bem -sucedida é uma Blockchain , mais alto é seu custo de
manutenção . Atualmente , rodar um full node do Bitcoin requer mais 130 GB de
espaço e o Ethereum exige mais de 180GB. Essa situação não vai melhorar com o
tempo . À medida que mais usuários adotam a Blockchain e executam mais
transações , a inflação dos Blocos vai aumentar e os custos com manutenção
crescerão ainda mais . Medidas precisam ser tomadas para mitigar este círculo
vicioso.

1.6 Suporte de Comunicação Ponto-a-Ponto Ineficiente

As Blockchains existentes se comunicam principalmente através de uma rede de
transmissão onde o suporte para comunicação P2P é ineficiente, além de não ser seguro.
Por exemplo , se certa informação é pertinente apenas a um grupo de usuários , ela deveria
ser transmitida entre um número limitado de nodes, e não para todos eles.

1.7. Avanço Pendente para Comunicação Cross-Chain

Os sistemas de Blockchain exsistentes chegaram a testar uma comunicação cross-

chain para processos lógicos em nível comercial . Entretanto , os resultados não
foram satisfatórios . A atual comunicação cross -chain inclui o mecanismo
centralizado , além do HTLC . O mecanismo centralizado vai contra o princípio da
Blockchain , e leva à falta de confiança , falhas em nodes individuais , gargalos em
nodes individuais e só é aplicável em certas situações .
6
O mecanismo HTLC também consegue lidar apenas com situações específicas ,
como uma negociação de ativo , e impõe requisitos rigorosos aos protocolos ,
inclusive aos de Consenso das redes de comunicação . A implementação de tal
mecanismo geralmente é complexa . Dessa forma , é imperativo destacar duas
questões críticas : Compatibilidade de Protocolo e compatibilidade de formato para
intercâmbio de dados.

7
2. Objetivos Principais da aelf

2.1. Um S. O. Altamente Customizável para Uso Comercial

Nós vislumbramos a aelf como um Sistema operacional altamente eficiente e
customizável que se tornará o "sistema Linux" para a Blockchain . Veja o exemplo
do Linux: O núcleo Linux e várias outras de suas versões compõe a vasta e bem-
sucedida família Linux . O núcleo Linux resolve as coisas mais fundamentais ,
críticas e que demandam tempo , permitindo que outros desenvolvedores criem
sistemas personalizados baseados em cenários aplicáveis e necessidades dos
clientes . Isso faz do Linux o mais popular servidor OS , e ele atende todos os
segmentos comerciais . Essa mesma ideia foi incorporada no projeto da aelf .
Primeiramente , definimos e implementamos o núcleo aelf , o que inclui funções
essenciais de uma Blockchain , conhecido como sistema de Blockchain mínimo
viável . Em seguida , desenvolvemos um "shell " para ser uma interface interativa
básica do Núcleo . Os usuários podem usar o Sistema operacional completo da
Blockchain , ou rapidamente desenvolver outro sistema operacional baseado no
Núcleo por redefinir este através das interfaces.

2.2. Interação Cross-Chain

A aelf pode interagir com o Bitcoin , Ethereum e outras Blockchains . Interações
Cross -chain com Redes mainstream podem ser realizadas através de troca de
mensagens . Também será formada uma estrutura cross -chain endógena de
múltiplos níveis baseada em interações cross -chain , no intuito de compartilhar
arquivos digitais, usuários e informações.

2.3. Melhoria no Desempenho

Na arquitetura tradicional de TI, a estrutura distribuída é a solução mais popular
para sanar limitações de capacidade. Os sistemas de Blockchain também deveriam
suportar processamentos paralelos distribuídos, o que nada mais é do que o ato de
processar múltiplas transações com dados não -concorrentes para otimizar a
eficiência nas transações . Sem contar que , quando uma rede se torna muito
complexa para ser processada de maneira efetiva , ela deveria ser dividida em
Redes paralelas para desafogar o tráfego . O projeto inicial de uma Blockchain
eficiente deveria ser focado em resolver situações comerciais específicas e não
juntar todos os Smart Contracts em uma única Rede. Na intenção de entregar um
desempenho ideal com base nos requisitos dos usuários , a Rede precisa fornecer
uma estrutura de informações eficiente e personalizada, lógica nos Smart Contracts
e um Protocolo de Consenso que possa ser pensado especificamente para o
objetivo desejado . Por fazerem isso, os componentes e as informações dentro da
Rede serão muito mais simples e fáceis de gerenciar . Além disso , a aelf pode
determinar um mecanismo para disparar snapshots no sistema. Ao definir um ciclo,
tira-se um snapshot das informações atuais e os dados detalhados da transação
são ajustados . Um novo Bloco Gênesis irá incluir todas as transações
subsequentes . Essa ideia tem sido adotada na arquitetura de banco de dados
tradicional da TI para mitigar a inflação no sistema.

2.4. Atualização de Protocolo

O mecanismo de votação e atualizações precisa estar claramente definido na
Gênese da Blockchain . Com a introdução do Protocolo de Consenso para incluir
novos recursos posteriormente , não há chance de impasses ou disputas quanto à
atualizações no Protocolo.

8
2.5. Módulo de Rede Privada
Um número considerável de empresas está interessado em Redes Privadas para
alavancar as vantagens da tecnologia Blockchain . Essas Redes Privadas
geralmente existem independente de quaisquer conexões à ecossistemas externos
ou outros negócios . Fornecemos um modelo semelhante ao serviço de nuvem da
Amazon , "o AMI ", onde os usuários podem rapidamente criar uma Rede
independente usando nosso módulo de Redes Privadas, obtendo assim total posse
delas.

9
3. Abordagens Fundamentais na Execução do Sistema da aelf

3.1. Aprimoramentos de Performance

O princípio fundamental da aelf é resolver problemas técnicos práticos utilizando
soluções que já foram estadas. Ao invés de “otimizar” os conceitos da Blockchain,
tem sido dada mais atenção a fornecer uma configuração madura para uma
execução estável de aplicações comerciais . Algumas ideias para melhorias no
desempenho que estão sendo analisadas atualmente : A maioria das soluções de
particionamento na Blockchain são implementadas dividindo um único consenso
em inúmeros sub-consensos . Basicamente , o consenso como um todo é dividido ,
deixando vários grupos de sub-consensos, os quais são mais suscetíveis a ataques
do que um único apenas . As pessoas podem aumentar a aleatoriedade para
dificultar o caminho de roteamento mas isso prejudicará a especificação do node de
mineração . Os Nodes de mineração PoW diminuem substancialmente à medida
que mais pools de mineração os substituem como um ledger system especializado.
Essas pools são capazes de assegurar a eficiência da mineração e fazer
transmissões oportunas , diminuindo a velocidade de formação dos blocos ,
mantendo -a estável . Por alavancar as experiências do setor de TI, as pools de
mineração deixaram para trás o software padrão oficial de nodes e agregam
potência computacional por meio de balanceamento de carga e por rodarem smart
contracts de uma maneira paralela e assíncrona , inserindo globalmente seus
próprios nodes para melhorar a eficiência da transmissão . Todavia , o desempenho
das pools de mineração ainda é limitado pelas diferenças técnicas utilizadas nelas e
pelo fato de que os nodes são todos projetados igualmente e limitados pelo próprio
protocolo . Assim, a atualização de um único node não leva à melhoria de toda a rede.
A lógica da aelf é que os nodes são classificados de acordo com seus papeis ; aqueles
que fornecem serviços padrão nos clusters são open -source e funcionam através de
DPoS para obter consenso da Main Chain . Os nodes de mineração delegados podem
proteger as Side Chains e compartilhar o forte consenso da Main Chain. Esse método
aumenta a pressão para cada delegado , entretanto , a eficiência irá melhorar ao
passo que mais Side Chains são adicionadas , porqque os nodes de mineração
delegados são capazes de rodar em clusters . As Side Chains são independentes
umas das outras, portanto uma Side Chain adicional irá aumentar a eficiência de todo
o sistema . Além disso , a eficiência de cada Side Chain irá se beneficiar de
processamentos paralelos.

3.2. Segregação de Recursos

Para proteger os Smart Contracts de interferências mútuas desnecessárias e
manter seu funcionamento estável na Blockchain , a aelf deixa de lado a ideia de
que “uma rede dá para tudo ” e projeta uma Blockchain pública que é capaz de
garantir o funcionamento apropriado de cada contrato . A aelf será uma plataforma
de computação em nuvem similar à AWS . Nenhum negócio gostaria de ser
incomodado por outro. Por exemplo, trades em um mercado futuro não devem ser
influenciados pelo tráfego gerado resultante da Black Friday . Porém , essa
aparentemente impossível interferência é comumente vista no domínio da
Blockchain. Portanto, o principal obstáculo que impede que a tecnologia Blockchain
seja aplicada em casos reais está em seu projeto inicial.

10
3.3. Estrutura de Governança
Devido a limitações antigas , a estrutura de governança atual da Blockchain é
frequentemente não muito bem definida. Esse problema fica maior quando há uma
atualização funcional importante ou uma estagnação causada por bugs . Por
exemplo , o Bitcoin tem ficado preso em problemas de escalabilidade há mais de
dois anos para finalmente ter seu fork e as diferenças na incidência da DAO entre a
comunidade do Ethereum e a fundação levaram ao nascimento do ETC . Como
resultado, nós esclarecemos o método da aelf – preparando antes que os usuários
adentrem o mundo da aelf: Reconhecemos o fato de que os holders da aelf tem o
maior direito de decisão no futuro da moeda e que seus interesses estão ligados ao
destino do projeto, em particular aqueles com tokens trancados pensando no longo
prazo.
3.3.1. Semelhança em Relação à Democracia Representativa
Um dos princípios essenciais da aelf é designar nodes específicos para realizar
tarefas específicas. Na aelf, decisões vitais são tomadas através de um mecanismo
que se assemelha à democracia representativa . Nodes delegados devem ter votos
suficientes de outros stakeholders para participar na governança da aelf. Até certo
ponto , os nodes de mineração constituem a saúde do Sistema da aelf , portanto
eles são responsáveis por serem os ‘contadores ’ além de distribuírem bônus e
feedback aos stakeholders que depositaram confiança nestes , por intermédio de
Smart Contracts.

3.3.2. Exercício de Poder pelos Delegados

Os membros da fundação realizam sua governança por submeter à revisão e voto
tanto o código fonte como os nodes de mineração . O processo ocorre assim : Os
membros da fundação fornecem o código open-source e submetem novos recursos.
A seguir, os delegados escolhem recursos específicos para serem incorporados, com
base em suas necessidades. Se um recurso for adotado por um número suficiente de
delegados, ele ganha a aprovação de todo o sistema.

11
4. Sistema da aelf

4.1. Arquitetura da aelf

Apresentamos como a aelf consiste de uma Main Chain e várias Side Chains
ligadas à Main Chain (Figura 4.1). Isso difere de um Sistema tradicional de Rede
Única pois a aelf é um "ecossistema que se ramifica " no qual a Main Chain
funciona como a espinha dorsal do sistema e faz conexões à múltiplas Side Chains
(isso até pode incluir múltiplas camadas).

Figura 4.1: Visão Geral da Estrutura da aelf

A aelf se conecta com o Bitcoin , Ethereum e outras Blockchains por adaptadores

no intuit de ser compatível com ecossistemas populares já existentes . As Side
Chains da aelf incluem as Side Chains internas do Sistema e outras geradas com
base ou no sistema operacional ou no núcleo da aelf. A Main Chain interage com
as Side Chains através da indexação dinâmica de Side Chains.

4.1.1. Uma Cadeia, Um Contrato

Comparada à estrutura tradicional de "uma cadeia para qualquer tipo de contrato",
a aelf impõe "uma cadeia para UM tipo de contrato". Como mostrado na figura 4.2
(b), cada Cadeia é dedicada a um tipo de transação e resolve um tipo de problema
comecial. Isso faz com que toda a estrutura e informações sejam mais simples e
mais adequadas às solicitações comerciais. Por adicionar novas Side Chains à
aelf, o projeto será capacitado com novas funções e vai manter uma estrutura
facilmente gerenciável.

(a) uma Cadeia para quaisquer tipos (b) na aelf, cada Cadeia é para um tipo de Contrato
de Contratos
Figura 4.2: Uma Blockchain com Estrutura Complexa de Dados

12
4.1.2. Indexação Dinâmica de Side Chains
A aelf é um Sistema dinâmico onde todas as Side Chains estão conectadas à Main
Chain. Esta contém o índice com os limites do sistema e registros de onde estão as
Side Chains . Elas se comunicam umas com as outras via Main Chain na forma
verificações por árvores de Merkle através da entrada de informações externas .
Assim , as Side Chains não interagem diretamente , permitindo que sejam
adicionadas ao sistema da Aelf ou excluídas dele.

4.1.3. Extensão das Side Chains do tipo "Ramos de Árvore"

Conforme ilustrado na Figura 4.3, a aelf define uma "estrutura composta por Main
Chain e Side Chain". Teoricamente falando, qualquer Side Chain também pode ser
conectada com algumas sub Chains sob ela, agindo como uma "Main Chain " em
uma parte do sistema . Isso cria uma estrutura de ramificação no Sistema que
permite a aelf se estender tanto horizontal como verticalmente. Essa ideia é similar
às de particionamento e fragmentação na arquitetura de banco de dados. Com isso
, cada fragment 0 pode realizar funções específicas e quando um deles se torna
muito grande para gerenciar há como ele posteriormente ser dividido em múltiplos
fragmentos. Na aelf isso corresponde às Side Chains.

Figura 4.3: Estrutura com Side Chains Multi-Camadas

4.2. Main Chain da aelf

A Main Chain da aelf é uma Blockchain rodada pelo Sistema Operacional da aelf e atua
como espinha dorsal de todo o sistema. A Main Chain é composta por um Sistema de
indexação de Side Chains, um sistema de Tokens e um Protcolo de Consenso DPoS.

4.2.1. Sistema de Indexação de Side Chains

O Sistema de Indexação de Side Chains interliga todas as Cadeias dentro do
ecossistema da aelf. A aelf indexa dois tipos de Cadeias:
• Cadeias externas de alta relevância, as quais podem ser usadas para expandir
os limites da aelf, ex: Bitcoin, Ethereum
• Side Chains internas operando sob o Sistema Operacional da aelf , as quais
contribuem economicamente ao sistema e utilizam o token aelf
A indexação de Side Chains funciona da seguinte maneira:

13
 • Os nodes da Main Chain leem as informações das Side Chains e
formam uma Árvore de Merkle.
• O cabeçalho do novo Bloco registra a raiz da Árvore de Merkle. Conforme
ilustrado na Figura 4.4, se quisermos confirmar a transação TX1 no milésimo
Bloco de BTC, só precisamos provar a existência da Árvore de Merkle para o
milésimo Bloco de BTC armazenado na Raiz da Árvore de Merkle da Main
Chain, e provar TX1 no milésimo Bloco de BTC por meio de troca de
mensagens. Esse método também funciona para outras Cadeias como o
Ethereum, contanto que uma Raiz de Árvore de Merkle seja formada.

Figura 4.4: Indexação das Side Chains

Para melhorar a eficiência das verificações , sugerimos expandir a estrutura de

uma Árvore de Merkle para incluir não apenas hashes de Blocos mas também a
Raiz da Árvore de Merkle das transações (Figura 4.5) e seus status (Figura 4.6).

Figura 4.5: Indexação das Transações

14
 Figura 4.6: Indexação dos Status

Uma questão chave que aparece aqui é o momento que é feita a indexação das Side
Chains pela Main Chain . Se a Main Chain frequentemente indexa uma Side Chain
com altas chances de sofrer fork, ela desperdiça esforços indexando Blocos Órfãos.
Portanto , sugerimos uma estratégia diferente de indexação para cada Side Chain
baseada em suas próprias e únicas características e isso pode ser definido no
sistema . A estratégia de indexação para Blockchains parecidas com a do Bitcoin
podem aguardar um minuto a partir da criação de um Bloco . Isso foi provado
estaticamente já que um bloco pode ser confirmado como não -órfão após um minuto
transcorrido de sua formação. Com a aelf, se uma Side Chain e a Main Chain adotarem
a mineração mesclada , uma indexação em tempo real pode ser conduzida pelos
mesmos mineradores.

Figura 4.7 Momentos da Indexação

15
4.2.2. Sistema do Token da aelf
O token da aelf incentiva comportamentos honestos no sistema . Todas as Side Chains
aceitam o Token como reserva de valor e um meio para transferência de valores .
Podem ser feitas trasnferências por quaisquer Cadeias que aceietm o Token da aelf.

Quando uma Side Chain pede para ser indexada pela Main Chain, ela recebe alguns
Tokens 'trancados ' da Main Chain . Ao receberem taxas de transações , as Side
Chains as dividem parcialmente com os mineradores da Main Chain. Quando a Main
Chain acha que indexar uma Side Chain não seja economicamente favorável , ela
tem o direito de suspender a indexação ou permitir uma concorrência de duas Side
Chains que ofereçam os mesmos serviços.

4.2.3. Protocolo de Consenso

Um mecanismo eficiente e estável para formação de Blocos é a base do sistema da
aelf. A operação e manutenção da aelf is more complicatedé mais sofisticada que a
do Bitcoin ou do Ethereum devido ao fato de a formação de Blocos na aelf exigir que a
Main Chain registre informações das Side Chains , sem dizer que a aelf ´´e projetada
para prestar serviços empresariais em nuvem em uma estrutura mais complexa .
Além disso , os mineradores tem que atualizar informações de várias Cadeias
paralelas . A Main Chain vai adotar o DPoS para garantir alta frequência e
previsibilidade da formação de blocos, o que irá melhorar a experiência do usuário.

4.2.4. DPoS
A aelf delega 2N+1 nodes de mineração . N começa em 8 e vai aumentando em 1 a
cada ano. Esses nodes no sistema reforçam todas as regras de consenso da aelf.
O propósito destes nodes delegados de mineração é habilitar a confirmação e
retransmissão de transações , alocar blocos e transferir dados. Visto que a aelf usa
uma arquitetura com múltiplas Side Chains , os nodes de mineração precisam agir
como mineradores para algumas Side Chains.
2N+1 nodes irão passar por um cálculo de ordem aleatória a cada semana.
O processo de randomização é ilustrado a seguir:
A aelf está rodando na linha do tempo dentro de unidades de processamento que
chamamos de “rodadas” (seta horizontal nas Fig. 4.8 e 4.9). Em uma rodada , um
node de mineração irá produzir um bloco por vez ,enquanto um node terá uma
transação extra ao fim da rodada (seta vertical na Fig 4.9).

Cada um dos nodes ( ) tem três principais propriedades em uma rodada

específica ( ): (1) Chave Privada, , que é um valor obtido do node de
mineração e mantido em sigilo pelo próprio node na rodada . Ele se tornará
público depois que todas as gerações de bloco na rodada forem completadas; (2)
Chave Pública, , que é o hash . Todos os nodes na rede aelf
podem procurar este valor a qualquer momento; (3) Assinatura, , que é um
valor gerado pelo próprio node de mineração na primeira rodada. Depois da
primeira rodada, ele só pode ser calculado uma vez que a rodada anterior estiver
completa. Ela é usada como assinatura deste node de mineração nessa rodada e
também é sempre aberta a todos assim como a . Veja a figura 2.1 para
maiores detalhes.

16
Há dois principais processos no DPoS: (1) Pre-verifciação;e (2)o ordem de cálculo
em cada rodada.

Pré-verificação (Fig 4.8): Antes que um node comece sua geração de blocos na
rodada , ele precisa ter seu status verificado na rodada . Na rodada
, já está classificada como pública e pode ser colocada na fila a
qualquer momento. Portanto, para verificar o status do na rodada ,
outros nodes podem checar .

Figura 4.8 Pré-verificação

Ordem de cálculo (Fig 4.9): Na Fig. 4.9 usamos 4 nodes de mineração como
exemplo para explicarmos nossa estratégia de cálculo. Em cada rodada N, os
mining nodes tem N+1 gerações de blocos. Na primeira rodada (Rodada 1 na Fig 4.
9), a ordem da geração de blocos bem como a assinatura ( ) para cada node
são totalmente arbitrárias. Na segunda rodada (Rodada 2 na Fig 4.9), as gerações
de blocos são mais uma vez ordenada de maneira arbitrária. Entretanto, na segunda
rodada a assinatura será calculada por

onde

aqui, diz que o node está processando a transação na rodada .

A partir da rodada 3, a ordenação dentro de uma rodada é gerada partindo do node
e da assinatura da rodada anterior. Na rodada , nós atravessamos a
assinatura dos nodes na rodada . A ordenação de um node em é calculada
por

Para casos de conflito, como resultados apontando para locais que não estão
vazios, direcionamos o node para o próximo lugar disponível. Se o node entra em
conflito no lugar, iremos localizar o local disponível a partir do primeiro lugar.

17
O node que processa a transação extra é calculado a partir da assinatura do node
no primeiro lugar da rodada anterior.

Figura 4.9 Detalhes dos cálculos para as primeiras três rodadas

é decidido por: (1) todas as assinaturas da rodada anterior ; (2) o

próprio valor na rodada ; (3) qual node gera o bloco extra. Portanto ele só
pode ser calculado depois que a rodada anterior estiver completa . Ademais ,
como são necessárias todas as assinaturas das rodadas anteriores , além da
necessidade que o valor seja colocado por cada node independentemente , não
tem como controlar a ordenação. A geração do bloco extra é usada para aumentar a
aleatoriedade . No geral , criamos um sistema randômico que se apega à entradas
extras de fora. Com base no conceito de que nenhum node conhece as entradas de
outros nodes em uma rodada específica, nenhum node pode controlar a ordenação.
Se um node não puder gerar um bloco em uma rodada , ele também não pode
entrar com seu para essa rodada.
Em um caso assim, o anterior será usado. Já que todos os nodes de mineração
são votados para serem nodes de confiança , tal situação não deve ocorrer com
frequência . Mesmo que isso aconteça , a estratégia acima mencionada é mais que
suficiente para lidar com a questão.
Cada node tem apenas um tempo de T segundos para processar transações . Sob
as atuais condições da rede, T=4 é um tempo razoável, ou seja, consideramos que
todo node tem apenas 4 segundos para processa transações e submeter o
resultado à rede. Qualquer delegado que falhar ao submeter dentro de 4 segundos
é tipo como que abandonou o bloco . Se um delegado falhar por duas vezes
seguidas, haverá um período de janela calculado como W horas (W=2N, N indica o
número de falhas) para aquele node.
No projeto sistemático, a aelf define que apenas um node gera blocos dentro de um
determinado período . Assim sendo , é improvável que aconteça um fork em um
ambiente onde os nodes de mineração estejam trabalhando com boa conectividade.

18
Se vários grupos de nodes órfãos aparecerem devido a problemas na rede , o
sistema irá adotar a cadeia mais distante já que esta tem a maior probabilidade
devir do grupo de nodes órfãos com o maior número de nodes de mineração. Se um
nó defeituoso minerar ao mesmo tempo duas Blockchains 'forkadas ' para atacar a
rede, esse node será eliminado de toda a rede.
Os nodes de mineração DPoS são eleitos de uma forma que lembra a democracia
representativa . Os nodes eleitos decidem como distribuir bônus para os outros
nodes de mineração e stakeholders . Esse mecanismo ainda será abordado no
capítulo seguinte.

4.2.5. Confirmação das Transações

A aelf tem um processo de confirmação mais rápido e previsível do que os atuais
sistemas de Blockchains. O DPoS é diferente do PoW porque ele não precisa ficar
organizando repetidamente as hashes. Isso quer dizer que o tempo que cada node
de mineração finaliza um bloco é estável e pode ser controlado dentro de T (4
segundos).
A aelf recomenda que uma confirmação rápida aceita por cinco blocos seja usada
para transações gerais e que uma aceita por 15 blocos seja usada para transações
substanciais . Assim, uma transação geral será confirmada dentro de 20 segundos
enquanto que uma transação substancial levará 60.
Note, por favor, que esta é uma recomendação conservadora . O Bitcoin trabalha
com uma recomendação de seis blocos , porém muitos usuários utilizam apenas
um ou dois blocos por confirmação . Usuários avançados podem ficar atentos e
coletar dados de sua própria Blockchain para personalizar um tempo de
confirmação de acordo com o tempo médio de processamento de seus próprios
nodes de mineração e de toda a rede.

4.3. Side Chains da aelf

As Cadeias indexadas pela Main Chain da aelf são chamadas Side Chains . Como
mencionado antes, é recomendável que cada Side Chain seja designada para lidar
com um tipo específico de transação (Figura 4.8). .
Quando novas Side Chains são geradas pelo SO da aelf , é uma boa ideia
minerarem de forma mesclada com a Main Chain e estabeleçam seus próprios
Protocolos de Consenso . Para contribuir com o ecossistema da aelf , as Side
Chains devem reservar uma certa quantidade de Tokens aelf e dividir parcialmente
as taxas de transação com a Main Chain.
Quando uma Side Chain necessita verificar informações de outra Side Chain, esta
deve incluir as informações do cabeçalho do Bloco da Main Chain da aelf . Como
as Side Chains não interagem diretamente umas com as outras, a verificação é feita
através da Raiz da Árvore de Merkle fornecida pela Main Chain.

Figura 4.8: Interação por Mensagens entre Duas Side Chains

19
Obter informações de status a partir de sistemas UTXO como o Bitcoin é um
processo altamente complexo . Por exemplo , é bem complicado obter o balanço
disponível em um endereço Bitcoin . Uma comunicação Cross -Chain pode ser
usada através de um adaptador de Blockchains, o que cria um cabeçalho de Bloco
compatível incluindo a Árvore de Merkle com o Bitcoin . A aelf usa um adaptador
como este e pretende estabelecer uma Side Chain completamente compatível com
o Bitcoin utilizando seu SO para cooperar com essa moeda tão amplamente
utilizada, além de interagir com seus ativos.

4.4. O Lado Econômico da aelf

Uma economia virtuosa é a base de um ecossistema sustentável na aelf.
Na PoS e DPoS , qualquer stakeholder pode vender seus Tokens e sair do
ecossistema em pouco tempo (a PoS tem um período determinado de ‘lock-up’).
Um dos desafios que estes métodos enfrentam é o fato de que as Exchanges
podem controlar grandes quantidades de Tokens no sistema e ainda recebem juros
quase que à custo zero.
Na PoW, os mineradores encaram uma situação mais complexa antes de saírem.
Suas saídas são restringidas por fatores externos como despesas de eletricidade ,
depreciação das máquinas de mineração , custos com os locais p/ mineração e
recursos humanos.
A aelf usará o DPoS na Main Chain para incentivar grandes Stakeholders a manter
um sistema estável. No Sistema da aelf, o Protocolo de Consenso em cada Cadeia
pode ser customizado para atender a objetivos específicos.

Figure 4.9: Mecanismo de Taxas de Indexação nas Side Chains da aelf

Depois que uma Side Chain é incluída no ecossistema da aelf , ela irá pagar uma
certa taxa de transação à Main Chain referente à indexação . A aelf adota uma
estratégia dinâmica para taxas de transações para refletir os diferentes níveis de
contribuição de cada Side Chain para o ecossistema . Por exemplo , a aelf irá cobrar
uma taxa de transação mais baixa para uma Side Chain com um grande índice de
contribuição, tal como o Bitcoin, que possui ampla adoção e muitos ativos associados
a ele. Por outro lado, uma Side Chain com pequeno valor perante o ecossistema e
que consuma muitos recursos de outras Cadeias terá que arca com taxas mais altas.

20
 Figura 4.10.: Indexação de Sub-chains

O ecossistema de cada Side Chain vota para determinar a estratégia de indexação de

Sub- Chains independente da Main Chain. Sua própria estratégia é composta por, mas
não sendo limitada à, escopo de negócios (ex: Uma Cadeia de seguros só irá incluir sub-
Chains relacionadas ao segmento de Seguros) e esquemas de taxas das Sub-Chains.
Qualquer Cadeia também pode decidir por não incluir qualquer Sub-Chain ou convidar
ativamente uma Cadeia para se tornar uma Sub-Chain como forma de enriquecer seu
ecossistema . Dentro do ecossistema da aelf, qualquer Cadeia pode solicitar para se
tornar uma Sub-Chain de outra Cadeia ou até mesmo de várias Cadeias.

4.5. Sistema Embutido nas Side Chains da aelf

A Topologia de nodes da aelf consiste de uma rede P2P interconectada entre full
nodes da Main Chain, light nodes e nodes das Side Chains. Nodes que não sejam
de mineração geralmente são Light Nodes . De maneira similar , ledger nodes são
full nodes. Os Nodes de Side Chains são distribuídos pela Topologia de nodes da
aelf com base nas suas relações de indexação com a Main Chain. As Side Chains
podem ser desenvolvidas sob as diretrizes desta Fundação . Acreditamos que seja
necessário construir um Sistema como este . A aelf não pretende construir uma
Side Chain em si, porém irá fornecer uma template de desenvolvimento além de
infraestrutura para isso com o fim de facilitar a comunicação entre as Side Chains.
Por exemplo , poderia haver uma rede de conteúdos onde os usuários
conseguissem pagar por esses conteúdos usando o token desta rede. Quando um “
Twitter” descentralizado se juntar à nós, a aelf irá ajudar os usuários a compartilhar
conteúdo através desta rede e também distribuir recursos de rede, além de fazer a
troca deste token “Twitter” por tokens de uma rede de distribuição de conteúdo em
uma Exchange descentralizada.

Figura 4.11: Ilustração da Topologia de Nodes da aelf

4.5.1. Side Chain de Informações, Registros e Autenticações

Informações, registros e autenticações nas Side Chains geram grande valor tanto a
indústrias online como para as que são offline . Negócios do tipo O2O como e-
commerce, chamadas de veículos e entregas já adotaram essa tecnologia. Grandes

21
oportunidades ainda aparecerão em negócios como finanças em cadeias de
fornecimento, logística, pontuação de crédito e outros, onde seus grandes ativos de
informação podem ser migrados para esta Side Chain no futuro.

4.5.2. Side Chain de Propriedade de Ativos Digitais

A principal função desta Side Chain é armazenar informações sobre propriedades
de carteiras e ativos digitais.

4.5.3. Side Chain de Distribuição Inicial de Ativos

A principal função desta Side Chain é facilitar a inicialização dos ativos (Venda
Inicial de moedas ). Uma vez que a distribuição tenha sido completada , os ativos
serão movidos para a Side Chain de Propriedade de Ativos Digitais . A vantagem
aqui é que as transações normais não serão interrompidas durante uma Venda
Inicial de Moedas de grande escala.

4.5.4. Side Chain de Exchange Descentralizada

Uma Side Chain de transações descentralizadas funciona como uma Exchange.
Ela possibilita o KYC, transferência de ativos e colocação/execução de ordens e
saques.

4.6. Otimização Cross-Chain na aelf

Transações Cross-chain precisam ser otimizadas para se adequarem à velocidade
de formação do Bloco entre cadeias diferentes . A aelf tem dois mecanismos para
combater isto. O primeiro se trata de um mecanismo hierárquico de Side Chains .
Nós classificamos as cadeias em diferentes níveis de acordo com a velocidade de
formação do Bloco da cadeia e fornecemos uma side chain de adaptação dedicada
ou um módulo adaptador para conduzir o mesmo nível de transações cross-chain
para cada nível da cadeia . Parte dessa solução é um mecanismo de guarantia
entre -níveis . Para transações cross -chain em níveis diferentes , a main chain dá
uma garantia para a rede mais lenta , porém esse é só um mecanismo opcional ,
caso solicitado . Esses dois mecanismos melhoram efetivamente a velocidade das
transações cross-chain da aelf.

Figura 4.12: Ilustração da Topologia de Nodes da aelf

22
5. Sistema Operacional da aelf

5.1. Definição de Sistema de Blockchain Mínimo Viável

O Sistema da aelf cria estruturas de Cadeia altamente específicas e eficientes para
lidar como todos os tipos de cenários comerciais. Ele também possibilita ‘splits’ nas
cadeias para resolver questões de capacidade à medida que a demanda aumente.
Para melhorar ainda mais o potencial comercial da aelf, nós esquematizamos o
bloco mais importante do sistema e sua infraestrutura para os desenvolvedores e a
comunidade . Os capítulos a seguir discutem o Sistema de Blockchain Mínimo
Viável e o Sistema Operacional da aelf como as fundações para alcançar altos
índices de customização e eficiência.
Bloco: Um bloco é usado para registrar um status no sistema. A transição do último
Bloco para o Bloco atual é definida pelas transações incluídas no Bloco atual.
Transação: A lógica de Transação é definida como um Smart Contract. Um Smart
Contract é basicamente um Protocolo. Ele sempre dá a mesma saída a partir da
mesma entrada.
Conta: Uma conta é usada para distinguir os limites de armazenamento de dados.
Ela consiste de sistemas de chave público e privado.
Comunicação em Rede P2P: A transmissão de dados entre nodes é feita através
da rede P2P subjacente.
Protocolo de Consenso: Um Protocolo de Consenso define as regras e autoridade
para atualizar um status dentro da Blockchain.

5.2. Núcleo da aelf (Kernel)

5.2.1. Sistema de Blockchain Mínimo Viável Embutido

Esses são os componentes essenciais da Blockchain operando dentro do Kernel da
aelf . Eles estão ligados a interfaces importantes para estabelecer as partes
customizáveis de Smart Contracts , Protocolos de Consenso e cabeçalhos de
Blockchain.

5.2.2. Sistema Unificado de Contas

O Sistema do Bitcoin introduziu as chaves públicas e privadas ao conceito de uma
conta. O hash ‘Pay to Script’ fornece autoridade de transação à um Smart Contract.
Enquanto o Ethereum define externamente contas com propriedade e contas de
contratos, o Kernel da aelf define ambos os tipos de contas como Smart Contracts.

5.2.3. Transações Paralelas Sendo Processadas Dentro de um Bloco

A aelf analisa o estado estático das transações e acessa o intervalo de informações
impactada em cada transação. Como mostrado na Figura 5.1, transações múltiplas
sem conflitos de leitura /escrita podem , então , ser processadas em paralelo , sem
afetar a saída de cada transação . Durante o processo de formação do Bloco , os
nodes assinam transações para diferentes grupos com base nas exclusões mútuas
(mutex ) de transações . Transações dentro de um grupo vão ser processadas em
sequência, enquanto todos os grupos serão processados simultaneamente.

23
 Figura 5.1: Transações paralelas sendo processadas em um bloco

Essas são transações especiais que não podem ser processadas em paralelo porque
elas impactaram o intervalo de dados enquanto outras transações estão em
processamento . Nessas circunstâncias , os nodes vão priorizar transações que podem
ser processadas em paralelo . Com taxas de transações suficientes , essas transações
especiais em um grupo não-paralelo serão processadas na sequência. Caso contrário,
os nodes podem rejeitar essas transações. É digno de nota que, quando um node falho
aceita uma transação que não pode ser processada de uma forma paralela e demorada,
a probabilidade de que outros nodes rejeitem esse Bloco aumenta.
A lei de Amdahl é uma regra empírica na arquitetura da computação nomeada depois
que o cientista da computação Gene Amdahl que dá o speedup teórico na eficiência
ao usar processamento paralelo . Pense em um programa que roda em apenas um
processador . Em termos de tempo de execução , “f” é a proporção do tempo de
execução que a parte beneficiada dos recursos melhorados originalmente ocupou ,
então (1-f) é a proporção do tempo de execução que é fixa para processamentos
sequenciais. Se existem “m” (números) de processadores rodando em paralelo, então
o speedup teórico deste programa será calculado como segue:
1
𝑆𝑝𝑒𝑒𝑑𝑈𝑝&'()*+ =
𝑓
(1 − 𝑓) + 𝑚
Tiramos duas conclusões maiores:
• (1) O Speedup mal se move quando 'f' está em seu mínimo.
• (2) À medida que 'm' vai ao máximo, o speedup é limitado em 1/(1-f).
A lei de Amdahl é um modelo de tamanho fixo, o que significa que ela irá resolver
problemas de tamanho fixo com uma proporção fixa de execuções em paralelo. A
maioria das transações na Blockchain não são correlacionadas. Usando a Lei de
Amdahl, a execução dos dados pode ser bastante acelerada. Entretanto, a grande
parte das Blockchains atuais fazem execuções em sequência e todos os nodes carry
out the same set of computing. Isso desperdiça recursos e trava a velocidade das
transações. A EVM, por exemplo, não apenas processa transações sequencialmente
mas também possui requisitos para taxas de gas, resultando em uma performance de
eficiência extremamente baixa.

24
 Figure 5.2

Para solucionar problemas complexos da Blockchain , transações de baixa velocidade

simplesmente não são uma opção viável . A aelf deseja construir um Sistema de
Blockchain com uma alta TPS on-chain através de processamento paralelo. O segredo
aqui é separar dados de transações e dependência computacional , o que resolve
questões de risco dos dados. Podemos citar a arquitetura do micro-processador Intel,
onde uma estação de reserva separa a dependência de eletrocircuitos juntamente com
outras técnicas como renomeação de registros para lidar com os grandes riscos de
dados , os quais frequentemente ocorrem com RAW, WAW e WAR e ainda executam
ALU’s em paralelo.
O Agendador de Execuções Paralelas da aelf (GPES) adota uma abordagem parecida.
Nos testes internos regulares, a aelf separa dependência computacional e dependência
de dados na Blockchain a partir do pool de memória . O GPES também conta com um
conjunto de pré-tratamento (previsão no intervalo de tempo de computação ) e pré-
indexação de segmentos de códigos que podem ser processados em paralelo. Ele ainda
inicia a segmentação de instruções e executa processamentos paralelos em várias
dimensões.
Esse conjunto de linguagens de indexação pode ser usado para solucionar problemas
de lógica paralela mais complicados.
A segmentação de instruções da aelf também é um importante método para aumentar a
velocidade . Ela tem sido amplamente usada em casos que envolvem CPU e
processamento em metaprogramação . Esse conjunto de linguagens é perfeito para
processar fluxos de dados (ou fluxos de transações simples ). As funções do
processamento paralelo e o contexto de computação livre/imutável vão fazer uso total
dos núcleos e dos nodes.
No geral, o processamento paralelo é uma estratégia compreensiva para aumentar
significativamente a velocidade das transações na Blockchain.

5.2.4. Transações Marcadas por Blocos

Uma transação válida no período entre a transmissão e a confirmação é tida como
estando em um status “pendente ”. Geralmente , as transações serão rapidamente
alocadas e confirmadas . Todavia , também há casos em que as transações ficam
como não confirmadas por um período relativamente longo , como por exemplo ,
durante épocas de congestionamento na rede do Bitcoin ou quando a maioria de
mineradores estiver insatisfeita com as taxas de gas. Quando uma transação não
for confirmada e nem ficar disponível para saque por um período relativamente longo,
ela será considerada como estando em um estado de “caos”.
A aelf exige que a transmissão para cada transação seja identificada com uma 'marca',
a qual é o cabeçalho de hash do último bloco quando a transação ocorrer . O node de
mineração , então , irá processar apenas o cabeçalho de hash dos 64 últimos blocos.
Se uma transação não for confirmada depois de 64 blocos gerados, ela será tida como
expirada . De maneira simples , uma transação que não for confirmada dentro de cinco
minutos pode ser refeita pelos holders.

25
Outra função das transações marcadas é efetivamente tornar obsoletos forks na
Blockchain . Um node marca uma transação de forma bem -sucedida quando as
hashes dessa transação forem incluídas nos últimos 64 blocos . Se um node
receber da cadeia mais alta uma grande quantidade de hashes de marcação
inválidas e ele não for capaz de alocar essas transações, então é provável que ele
esteja trabalhando em uma cadeia que sofreu fork. Se os nodes receberem uma
grande quantidade de transações com marcações inválidas , há grandes chances
de que essa Blockchain tenha passado por um fork . Neste momento , os nodes
podem suspender as negociações para evitar riscos.

5.2.5. Coleção de Smart Contracts

O Contrato de Cadeia da aelf tem uma coleção de Smart Contracts que são
definidos durante a Gênese . Essa coleção é nomeada como a Coleção de Smart
Contracts da Gênese, em homenagem à Satoshi. A essência dessa coleção é uma
classe que define as principais funções , o Protocolo de Consenso da cadeia e o
mecanismo de atualizações da coleção.

5.2.6. Atualizações dos Smart Contracts

As funções da aelf são definidas pela Coleção de Smart Contracts . Portanto ,
atualizar a coleção impacta nas funções de toda a Cadeia . O mecanismo de
atualizações da coleção é definido pelacoleção anterior . Por exemplo , se uma
maioria de 80% vota por uma nova Coleção de Smart Contracts no mais recente
centésimo Bloco , isso é confirmado pelos próximos 2000 Blocos e uma nova
coleção irá substituir a original . Nodes que não atualizarem a coleção terão suas
atividades encerradas.

5.2.7. Protocolo de Consenso Customizável

Para cenários comerciais específicos , o Protocolo de Consenso tem um impacto
maior nas decisões dos participantes. No caso de uma cadeia privada com um alto
índice de confiança , o PBFT é um Protocolo popular . Ele gera um ótimo
desempenho com um pequeno número de mineradores pré-designados . Em um
ambiente com baixa confiança , a escalabilidade de uma Blockchain é mantida por
meio de Protocolos de Consenso como PoW, PoS and DPoS.
A aelf define Protocolos de Consenso como parte da Coleção de Smart Contracts e
podeimplementar qualquer tipo de Protocolo de Consenso com base em qualquer
tipo de cenário . Vamos utilizar o Bitcoin e a Peercoin como exemplos para ilustrar
as considerações sobre escolher o Protocolo de Consenso.
O PoW usado pelo Bitcoin autentica a Blockchain com base unicamente nas
informações do cabeçalho de Bloco sem quaisquer formas de entrada de dados .
Por outro lado, o PoS usado pela Peercoin exige dados das transações de stake
dentro do Bloco – sua própria autenticação de transações à parte do cabeçalho de
Bloco . Recomendamos aos futuros usuários que busquem um Protocolo de
Consenso que exija informações apenas do cabeçalho de Bloco com o intuito de
conseguir a autenticação em um tempo apropriado . Além disso , em casos bem
específicos, Protocolos de Consenso customizáveis podem ser implementados.

5.2.8. Arquivo de Cabeçalho do Bloco Customizável

Para facilitar o entendimento de que o Protocolo de Consenso usa somente
informações do cabeçalho de Bloco , apresentamos um cabeçalho de Bloco
customizável . O cabeçalho da Peercoin não contém informações que verifiquem a
legitimidade de um Bloco , o que significa que um Bloco de stake não é capaz de
verificar legitimidades por si só. O Kernel da aelf permite aos usuários customizarem
a estrutura de cabeçalhos de Bloco durante a criação de uma Cadeia. Uma ‘auto-
26
prova’ baseada em cabeçalhos de Bloco só pode ser feita por verificar transações
não-gastas na Árvore de Merkle com a Hash (TxID + N + Valor), calculando a Raiz
armazenada para obter esses dados (TxID, N, Valor) além da verificação da Árvore
de Merkle.

5.3. Interface de Cliente do Sistema Operacional da aelf

Figura 5.3: Interface do Sistema Operacional da aelf

5.3.1. Execução dos Smart Contracts

O Sistema Operacional da aelf define Smart Contracts como Protocolos. Eles podem
ser executados em qualquer forma de realização de serviços.
O Sistema Operacional da aelf prefere o Docker mas também oferece suporte à
linguagens de programação nativas como Java, C#, Go, Javascript e LUA.
No caso do Docker, a aelf oferece serviços de RPC internos para garantir acesso á
leitura de variáveis e contas de usuários durante a execução dos Smart Contracts .
Para linguagens de programação nativas , a aelf provê SDKs respectivos para a
execução de funções.

5.3.2. Micro Serviços

Os Smart Contracts são definidos como micro serviços na aelf. Isso torna os Smart
Contracts independentes de linguagens de programação específicas . Com isso, o
Protocolo de Consenso essencialmente se torna um serviço porque ele tem sua
definição por meio dos Smart Contracts.

27
5.3.3. Base em Nuvem
Por meio da abordagem de micro serviço, o Kernel da aelf estende processamentos
paralelos àuma nuvem, permitindo assim uma execução de contratos baseada em
nuvem.
O Kernel definiu estrutura dos dados e padrões , portanto dados usados com mais
frequência podem ser salvos na RAM . Por utilizar um serviço de banco de dados
maduro e descentralizado , isso melhora efetivamente o desempenho de Entradas /
Saídas do sistema.

5.3.4. Light Node

Figura 5.4:Ilustração da Estrutura de Dados dos Light Nodes

Cada node na aelf lida apenas com informações relevantes dentro do sistema, o que
é alcançado através de customizações e um mecanismo interno de verificação por
Árvore de Merkle . Isso capacita os nodes a serem mais leves e aumenta
substancialmente a compatibilidade com light desktops e terminais móveis.

5.3.5. Módulos Opcionais

5.3.5.1. Mecanismo de Limpeza de Dados

Figura 5.5: Ilustração do Mecanismo de Limpeza de Dados

O Sistema da aelf adota um mecanismo instantâneo que reseta a formação de Blocos

com a adição dos dados originais ao novo Bloco Gênese. Entretanto, o Sistema da aelf
não se apega a dados antigos , mas foca em novas informações que precisam ser
processadas . Isso é semelhante a história humana, onde apesar do fato de que muitos
detalhes históricos foram perdidos as decisões das pessoas no presente não foram
afetadas . De modo semelhante , o Sistema da aelf tem como deixar de lado dados
antigos caso fique muito volumoso para se registrar..

5.3.5.2. Túnel de Dados

O túnel de dados é um mecanismo de execução de transferências P2P. Esses
dados não são registrados no Bloco. Tal método só é aplicável para transferências
de dados P2P que sejam criptografadas . Por exemplo, Se ‘A’ compra informações
de ‘B’, ‘B’ transfere dados ´para ‘A’ enquanto ‘A’ transfere ativos para ‘B’, ambos
sendo feitos através do túnel de dados . Esse formato visa habilitar transferência
de dados entre dois nodes de maneira direta. Nos atuais sistemas de Blockchain ,
a única estratégia é transmitir transações de forma que todos os nodes precisam
processá -las. Isto é um desperdício de recursos e também irá limitar o volume de
transações processadas . Os túneis de dados podem ser executados por meio de
um protocolo de plug-in, porém isso exigiria aprovação de todos os nodes . Caso
isso não aconteça, a situação ficaria intratável. Como exemplo: desenvolvedores

28
frequentemente enfrentam problemas quando o Internet Explorer não suporta
recursos do Chrome . Com esse protocolo , a aelf dará suporte a mais aplicações ,
como contratos de obtenção de dados, entre outras. (veja mais abaixo).

5.3.5.3. Modelo de Confirmação Rápida

A aelf permite confirmações rápidas de transações apenas se o recebedor tiver sido
autorizado pelo remetente. A autorização só é válida para um certo tipo de transação
durante um período determinado e entre endereços especificados. Por exemplo, se ‘
A’ quiser começar com um modelo de confirmação rápida com ‘B’ durante uma
transferência de ativos , então ‘A’ precisa iniciar uma transação com uma certa
quantidade de ativos reservada para a transação , além de especificar ‘B’ como a
contraparte . Durante o processo de transações atual , ‘A’ irá enviar a transação
validada para ‘B’ via Túnel de Dados. ‘B’ instantaneamente confirma a transação ao
recebê -la. Os ativos em questão serão então transferidos para ‘B’ depois que ‘B’
validar a transação com seus endereços . ‘A’ receberá , então, os ativos restantes . O
Túnel de Dados é encerrado após a transação.

5.3.5.4. Módulo de Tokens

O Módulo de Tokens define toda a lógica e algoritmos para o portador de valor (
Token). Ele serve especificamente em situações como pagamentos por alocação
de recursos ou recompensas por manter a estabilidade da aelf.
Na maioria das Cadeias públicas , o mecanismo de tokens é indispensável . Ele é
usado para incentivar o desenvolvimento saudável de toda a rede e organizar as
contribuições de diversas partes. A aelf projetou um módulo de tokens onde toda
Side Chain reconhecida pelo seu Sistema Operacional é liberada para a aceitar o
token aelf.

5.3.5.5. Customização
A aelf permite que desenvolvedores rapidamente customizem o Sistema por
redefinir parâmetros em cada modulo e por implementar Side Chains pelo seu
Sistema Operacional . A ideia essencial da aelf é que "uma cadeia atende um
cenário comercial específico" e estabelecemos uma arquitetura altamente abstrata e
modular. Para usuários empresariais emepreendedores, isso acelera o processo de
implementação de seus conceitos. Para usuários mais avançados, isso permite uma
alta customização para suas próprias Cadeias e revela o completo potencial da
Blockchain.

29
6. Desenvolvimento do Ecossistema da aelf
Qualquer tecnologia nova não irá ser bem -sucedida sem adoção comercial e um
ecossistema sustentável . A aelf propôs um modelo técnico com aplicação comercial
instilada em todo o projeto. É crucial estabelecer um ecossistema incluindo recursos
internos e externos . Buscamos este objetivo por nos esforçarmos simultaneamente
em três esferas: tecnologia, negócios e capital.

6.1. Tecnologia
Os capítulos acima destacaram os principais recursos técnicos da aelf. A equipe da
aelf possui anos de experiência em desenvolvimentos de Blockchain , com
envolvimento particular em alguns projetos empresariais focados no comércio . A
solução técnica proposta pela aelf pretende resolver os obstáculos que mais
impedem uma adoção comercial da Blockchain , como escalabilidade , segurança ,
customização e interoperabilidade . Ela fornece uma infraestrutura altamente
eficiente para adotar novos protocolos e dar suporte a todos os tipos de cenários
comerciais no futuro.

6.2. Aplicações nos Negócios

Por fim, A aelf deseja se tornar uma nova “Infrasestrutura de Internet” para dar
suporte à próxima geração de “negócios digitais”. A equipe e seus conselheiros
trabalharam em vários projetos de Blockchain no passado e delineamos as
indústrias que serão os “early adopters” e “estrelas da Blockchain” da aelf:

Figura 6.1: Ilustração das Aplicações em Negócios da aelf

1) Serviços Financeiros
A Blockchain tem chamado muita atenção do segmento de serviços
financeiros já que ela reduz os intermediários de forma significativa e
garante transações seguras. Múltiplas cadeias podem ser desenvolvidas na
aelf , especialmente para serviços financeiros , incluindo pagamentos
transfronteiriços , operações de trade e financiamento de cadeia de
suprimentos . O recurso de processamento paralelo é capaz de lidar com
transações comerciais em escala internacional e o recurso de comunicação
intra -cadeias permite uma coordenação suave do registro de ativos ,
gerenciamento de contas e transações em tempo real.

30
2) Seguros
O segmento dos seguros é outro atrativo e bem estabelecdo campo que
pode ser alcançado pela Blockchain. Uma side chain dedicada à seguros vai
integrar vários DAPPs e transformar toda a cadeia de valores de indústria .
Essas cadeias irão abranger tudo desde identidade do usuário, execução do
contrato de seguro e manipulação de reclamações.
3) Identidade Digital e IPs
A estrutura multi-cadeias da aelf tem uma cadeia embutida para identidade
digital . Isso garante o desempenho dessa side chain se outra side chain
estiver atarefada , como quando um novo token é emitido nessa outra side
chain . Dentro da aelf , a identidade digital pode ser usada por outras side
chains por meio de “trocas de mensagens ”. Usando um adaptador , a aelf
também é capaz de recuperar informações e dados de outras cadeias
estabelecidas, como do Bitcoin e do Ethereum.
4) Cidades Inteligentes
Os governos poderiam usar a aelf para executar certas tarefas
administrativas de maneira segura e conveniente. Governos ou organizações
poderiam também customizar o protocolo de consenso para atender
exigências de segurança nacional . Atividades envolvendo gravações ,
identidades de cidadãos , divulgação de informações de agências
governamentais e eleições seriam realizadas utilizando a aelf e tudo com
transparência e eficiência. Alguns países já fazem experimentos nessa área,
como Estônia, Singapura e China.
5) Internet das Coisas
A aelf dá suporte a light nodes serviços em nuvem, o que reduz as exigências
computacionais para dispositivos conectados enquanto uma alta performance
é mantida . Isso é fundamental para gerenciar bilhões de dispositivos e
habilitar micro pagamentos por meio deles ao conectar à Internet das Coisas.
A aelf desenvolveu uma forte base para os segmentos acima e ainda para
outros por vir. Além disso, nós ativamente identificamos novas oportunidades
de negócios e DAPPS para fazerem parte do ecossistema da aelf..
1) Interoperabilidade com DAPPs atuais em cadeias existentes
Já há alguns DAAPs em funcionamento nas Cadeias atuais, como no Bitcoin
e no Ethereum . A aelf irá alavancar seu recurso de interoperabilidade para
se conectar a esses DAPPs no intuito de permitir trocas de ativos e capturar
os dados de transação vindos desses DAPPs.

2) Nutrir Novas Ideias de Start-Ups

A equipe de desenvolvimento e seus conselheiros estão profundamente
envolvidos em novas formações de ideias e comercialização na comunidade
global da Blockchain . Novas startups nos contataram para consultorias
técnicas e comerciais . Iremos reforçar essas novas conexões para nutrir as
start-ups e incluí-las no ecossistema da aelf. Juntamente com VCs, estamos
confiantes que podemos identificar e atrair os projetos mais promissores
para se lançarem na aelf.

31
 3) Transformar empresas consolidadas em “experts em Blockchain”
Empresas consolidadas indicam outra oportunidade da qual pode -se tirar
benefícios e juntam-se ao ecossistema da aelf. Elas já têm uma grande base
de clients e provaram ter valor em seus negócios atuais. A aelf pode ajudá-
las a se tornarem ainda mais poderosas usando fortes incentivos e
recompensas aos clientes , resolvendo alguns pontos críticos dentro de
vários segmentos conforme descrito anteriormente . A equipe da aelf vem
conversando com empresas de Internet e corporações tradicionais sobre seu
modelo de negócios disruptivo. Prevemos alguns anúncios animadores para
o future próximo . Além disso, o time pretende colaborar com firmas globais
de consultoria estratégica pensando em ampliar os limites os modelos de
negócios da próxima geração no ecossistema da aelf.

6.3. Capital
Construir um ecossistema requer uma grande quantidade de capital . Além de
alavancar os fundos obtidos durante a Token sale, a equipe e seus conselheiros tem
estabelecido fortes alianças pelo mundo com os principais cripto fundos .
Trabalhamos como consultores em diversos projetos de Token sale para levantar
fundos de forma bem-sucedida e os ajudamos a superarem muitos obstáculos que
enfrentaram. Essa rede de internacional de capital e nossa reputação garantem uma
forte capacidade de financiamento e estamos construindo um meio de, globalmente,
dar suporte a esses negócios.

32
 Referências
1. Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system. 2008.

2. Vitalik Buterin. Ethereum White Paper: A Next Generation Smart Contract and

Decentralized Application Platform. 2013.

3. Melanie Swan. Blockchain: Blueprint for a new economy. ” O’Reilly Media,

Inc.”,2015.

4. Frederick P. Brooks. The Design of Design: Essays from a Computer Scientist.

“Addison-Wesley”, 2010.

5. Andrew S. Tanenbaum. Modern Operating Systems “Pearson”, 2007.

6. Joseph Poon and Thaddeus Dryja, The Bitcoin Lightning Network: Scalable Off-

Chain Instant Payments. 2016.

7. Gavin Wood. Ethereum: A secure decentralised generalised transaction ledger.

2014.

8. Hyperledger Whitepaper. 2016.

9. Muhammad Saqib Niaz and Gunter Saake. Merkle Hash Tree based Techniques

for Data Integrity of Outsourced Data. 2015.

10. Robert McMillan. The inside story of mt. gox, Bitcoin’s 460 dollar million disaster.

2014.

11. Sunny King, Scott Nadal. PPCoin: Peer-to-Peer Crypto-Currency with Proof-of-

Stake. 2012.

12. David Schwartz, Noah Youngs, and Arthur Britto. The ripple protocol consensus

algorithm. Ripple Labs Inc White Paper, 5, 2014.

33
13. Leslie Lamport. The Part-Time Parliament. ACM Transactions on Computer

Systems, 21(2):133–169, May 1998.

14. Leslie Lamport, Robert Shostak, and Marshall Pease. The byzantine generals

problem. ACM Transactions on Programming Languages and Systems

(TOPLAS), 4(3):382–401, 1982.

15. Leslie Lamport. Time, Clocks, and the Ordering of Events in a Distributed

System. Communications of the ACM, 21(7):558–565, Jul 1978.

16. Paul Tak Shing Liu. Medical record system using Blockchain, big data and

tokenization. Information and Communications Security, pages 254–261.

Springer, 2016.

17. Robert Love. Linux Kernel Development. “Addison-Wesley”, 2010.

18. Shawn Wilkinson and Tome Boshevski, Storj: A Peer-to-Peer Cloud Storage

Network. 2016.

19. Contract. URL https://en.Bitcoin.it/wiki/Contract, 2014.

20. Mandatory activation of segwit deployment, UASF, BIP 0148. URL

https://github.com/Bitcoin/bips/blob/master/bip-0148.mediawiki, 2017.

21. Smart Property. URL https://en.Bitcoin.it/wiki/Smart_Property, 2016.

34