U NIVERSIDADE F EDERAL DE M INAS G ERAIS

C URSO DE E NGENHARIA DE S ISTEMAS

D ESENVOLVIMENTO DE P LATAFORMA
DE C ROWDFUNDING
D ESCENTRALIZADA U TILIZANDO A
T ECNOLOGIA B LOCKCHAIN

R AMON C ALDEIRA FARIA

Orientadora: Ana Liddy Cenni de Castro Magalhães

Universidade Federal de Minas Gerais

B ELO H ORIZONTE
J UNHO DE 2018
 R AMON C ALDEIRA FARIA

D ESENVOLVIMENTO DE P LATAFORMA DE
C ROWDFUNDING D ESCENTRALIZADA
U TILIZANDO A T ECNOLOGIA B LOCKCHAIN

Trabalho de Conclusão de Curso apresentado ao Curso

de Engenharia de Sistemas da Universidade Federal de
Minas Gerais, como requisito parcial para a obtenção do
título de Bacharel em Engenharia de Sistemas.

Orientadora: Ana Liddy Cenni de Castro Magalhães

Universidade Federal de Minas Gerais

U NIVERSIDADE F EDERAL DE M INAS G ERAIS

C URSO DE E NGENHARIA DE S ISTEMAS
B ELO H ORIZONTE
J UNHO DE 2018

ii
 Resumo
Campanhas de crowdfunding coordenadas por plataformas que operam de forma
centralizada oferecem pouca transparência sobre o histórico de suas movimentações
financeiras, o que leva potenciais contribuidores a desistirem de apoiar projetos em
que acreditam, por não confiarem nos níveis de segurança oferecidos por essas plata-
formas. Este trabalho propõe o desenvolvimento de uma plataforma de crowdfunding
descentralizada, focada no modelo de doações, que utiliza a tecnologia blockchain
para oferecer a seus usuários maior transparência a respeito da destinação dos fundos
nela arrecadados. Para isso, foi desenvolvida uma plataforma que implementa duas
modalidades de campanhas de crowdfunding: repasse de criptomoedas a entidades
pré-cadastradas e repasse de criptomoedas a criadores de campanha por meio de um
planejamento dividido em fases, no qual a mudança de uma fase para outra ocorre a
partir do consentimento explícito dos apoiadores, utilizando um sistema de votação. Os
resultados obtidos evidenciam o funcionamento dos contratos inteligentes no contexto
de uma aplicação web que se comunica com uma rede blockchain pública da plataforma
Ethereum.

Palavras-chave: Contratos inteligentes. Ethereum. Criptomoedas. Crowdfunding.

iii
 Abstract
Crowdfunding campaigns coordinated by central entities offer little transparency over
their financial transactions history, which leads potential contributors to give up sup-
porting projects they believe in because they do not trust the security levels offered by
those platforms. This work proposes the development of a decentralized crowdfunding
platform, focused on the donations model, which uses blockchain technology to offer
greater transparency to its users regarding the allocation of the funds raised through
them. Taking that into account, it was developed a platform that implements two types
of crowdfunding campaigns: transfer of crypto-coins to pre-registered entities and
transfer of crypto-coins to campaign owners through a planning divided by phases,
in which the change from one phase to another occurs through explicit consent of
the supporters, by the means of a voting system. The obtained results evidences the
operation of smart contracts in the context of a web application that communicates with
a public blockchain network of the Ethereum platform.

Keywords: Smart contracts. Ethereum. Cryptocoins. Crowdfunding.

iv
 Lista de Figuras

Figura 1 – Modelos de Crowdfunding . . . . . . . . . . . . . . . . . . . . . . . . . 5

Figura 2 – Problema do gasto-duplo de criptomoedas . . . . . . . . . . . . . . . 7
Figura 3 – Amostra de transações de um bloco do Blockchain . . . . . . . . . . . 8
Figura 4 – Função de hash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Figura 5 – Bloqueio e desbloqueio de uma transação . . . . . . . . . . . . . . . . 10
Figura 6 – Tempo de confirmação dos blocos . . . . . . . . . . . . . . . . . . . . 11
Figura 7 – Contrato de custódia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Figura 8 – Estados de uma campanha na plataforma GiveTrack . . . . . . . . . . 15
Figura 9 – Funcionamento de uma campanha na plataforma Charity Chain . . . 15
Figura 10 – Funcionamento de uma campanha na plataforma Alice . . . . . . . . 16
Figura 11 – Diagrama de requisitos funcionais da solução proposta . . . . . . . . 20
Figura 12 – Diagrama de classes dos contratos inteligentes . . . . . . . . . . . . . 22
Figura 13 – Tela de criação de campanhas . . . . . . . . . . . . . . . . . . . . . . . 23
Figura 14 – Tela de confirmação de transação . . . . . . . . . . . . . . . . . . . . . 24
Figura 15 – Tela de de listagem de campanhas cadastradas na plataforma . . . . 24
Figura 16 – Tela de doação de ethers . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Figura 17 – Expiração de campanhas através da IDE Remix . . . . . . . . . . . . 26
Figura 18 – Tela de transferência de ethers . . . . . . . . . . . . . . . . . . . . . . . 26

v
 Lista de Abreviaturas e Siglas

API Application Interface Programming

DLT Distributed Ledger Technology

EOA Externally Owned Account

EVM Ethereum Virtual Machine

IDE Integrated Development Environment

LLL Lisp Like Language

RPC Remote Procedure Call

UTXO Unspent Transaction Output

vi
 Sumário

1 – Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Estrutura do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 – Referencial Teórico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Crowdfunding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1 Modelos sem recompensa . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1.1 Modelo de doação . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1.2 Modelo de empréstimo sem juros . . . . . . . . . . . . . 5
2.1.2 Modelos não-financeiros . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2.1 Modelo de recompensa . . . . . . . . . . . . . . . . . . . 6
2.1.2.2 Modelo de patrocínio . . . . . . . . . . . . . . . . . . . . 6
2.1.2.3 Modelo de compra antecipada . . . . . . . . . . . . . . . 6
2.1.3 Modelos financeiros . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.3.1 Modelo de empréstimo com juros . . . . . . . . . . . . . 6
2.1.3.2 Modelo de participação . . . . . . . . . . . . . . . . . . . 7
2.2 Bitcoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1 Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1.1 Funções de hash . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1.2 Criptografia assimétrica . . . . . . . . . . . . . . . . . . . 9
2.2.2 Prova de trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.3 Scripts de transação . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Ethereum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.1 Contratos inteligentes . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.1.1 Linguagem Solidity . . . . . . . . . . . . . . . . . . . . . . 12
2.3.1.2 Gas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.2 Contas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.2.1 Redes Ethereum . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.2.2 Carteiras . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4 Trabalhos relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3 – Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1 Levantamento de requisitos do projeto . . . . . . . . . . . . . . . . . . . . 17
3.2 Desenho da interface gráfica da aplicação web . . . . . . . . . . . . . . . . 17
3.3 Projeto do banco de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

vii
 3.4 Elaboração dos contratos inteligentes . . . . . . . . . . . . . . . . . . . . . 18
3.5 Verificação dos contratos inteligentes . . . . . . . . . . . . . . . . . . . . . 18
3.6 Integração dos contratos inteligentes à aplicação web . . . . . . . . . . . . 19

4 – Desenvolvimento e Resultados Obtidos . . . . . . . . . . . . . . . . . . . . . 20

4.1 Requisitos do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2 Contratos inteligentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.1 Contrato EntitiesCampaign . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.2 Contrato PhasesCampaign . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3 Telas da aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.4 Discussão dos resultados obtidos . . . . . . . . . . . . . . . . . . . . . . . 25

5 – Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Apêndices 31

APÊNDICE A – Documento de Requisitos . . . . . . . . . . . . . . . . . . . . . . 32

APÊNDICE B – Contratos Inteligentes . . . . . . . . . . . . . . . . . . . . . . . . 36

B.1 Fábrica de campanhas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
B.2 Campanha com repasse a entidades pré-cadastradas . . . . . . . . . . . . 36
B.3 Campanha com repasse dividido em fases . . . . . . . . . . . . . . . . . . 38

viii
Capítulo 1

Introdução

O crowdfunding, ou financiamento coletivo, é um tipo de iniciativa que permite a pessoas

físicas ou empresas angariar investimentos para desenvolver projetos de interesse
coletivo por meio da mobilização de comunidades de apoiadores que se interessam
pelos resultados almejados.

Algumas plataformas de crowdfunding disponíveis na web auxiliam consumidores in-

teressados em produtos inovadores a estabelecer relações de benefício mútuo com
criadores de campanhas, trocando, por exemplo, o capital necessário para o desenvolvi-
mento de um produto por condições especiais para sua aquisição.

No entanto, o modelo de negócios atualmente adotado por essas plataformas não

garante que os projetos financiados por meio delas irão de fato se concretizar. Para
que as campanhas sejam bem-sucedidas, elas dependem de que seus criadores sejam
honestos e honrem seus compromissos, o que pode não acontecer.

Riscos associados à destinação do dinheiro arrecadado podem afastar potenciais apoia-

dores, limitando o alcance dessas campanhas. Dessa forma, como criar campanhas de
financiamento coletivo mais transparentes e controladas?

Uma forma de contornar o problema consiste na adoção de políticas restritivas por

intermédio das plataformas on-line de crowdfunding, de modo que os apoiadores tenham
poder de decisão sobre a destinação dos fundos arrecadados. No entanto, para que este
sistema funcione, é preciso existir uma relação de confiança entre esta entidade central
intermediadora e os seus pares.

1.1 Objetivos
O presente trabalho se propõe a utilizar tecnologias baseadas em matemática e cripto-
grafia para reduzir a probabilidade de ocorrência de incidentes relacionados à quebra

1
de confiança entre as partes envolvidas em iniciativas de financiamento coletivo, seja
em movimentações de valores monetários ou seja na execução de regras de negócio
implementadas em software.

O software que gerencia as lógicas de negócio da aplicação de crowdfunding será desen-

volvido no formato de um contrato inteligente, a ser executado sobre a infraestrutura
de uma rede peer-to-peer pública utilizando a tecnologia Blockchain.

Objetivos específicos:

• Estudar os conceitos e ferramentas relacionados ao desenvolvimento de aplicações

descentralizadas baseadas em Blockchain;
• Desenvolver uma plataforma de crowdfunding baseada em blockchain que possibi-
lite a criação de campanhas voltadas para doação, nas quais não existe por parte
dos contribuintes expectativa de recompensa financeira;
• Implementar uma modalidade de campanha em que o dinheiro arrecadado só
possa ser destinado a fornecedores pré-cadastrados;
• Implementar uma modalidade de campanha em que o dinheiro arrecadado seja
liberado por fases e que a campanha só avance caso seja autorizada pelos apoia-
dores por meio de votação;
• Evidenciar o funcionamento dos contratos inteligentes, mostrando a movimenta-
ção de transações entre contas distintas.

1.2 Justificativa
O desenvolvimento de uma plataforma de crowdfunding descentralizada, baseada na
tecnologia blockchain, agrega transparência ao gerenciamento do dinheiro arrecadado
pelas campanhas. Com a adoção de regras para a destinação dos fundos arrecadados,
regidas por contratos inteligentes, espera-se que os usuários da plataforma tenham
maior sensação de segurança ao contribuir com as causas nela veiculadas, pois não será
necessário confiar em uma entidade central intermediadora e as possíveis destinações
fraudulentas do dinheiro arrecadado por parte dos donos das campanhas terão seus
efeitos limitados pelas regras pré-estabelecidas nos contratos inteligentes.

1.3 Estrutura do trabalho

O trabalho está dividido em cinco capítulos.

O capítulo de Introdução apresenta a contextualização do problema, os objetivos do

trabalho e uma justificativa para o desenvolvimento da solução proposta.

2
Em seguida, o capítulo de Referencial Teórico apresenta uma classificação de modelos
de crowdfunding, fornece uma visão geral dos conceitos que fundamentam as tecnologias
blockchain e Ethereum e discute trabalhos anteriores que se relacionam com este texto.

Na sequência, o capítulo de Metodologia descreve a forma como o trabalho será reali-

zado, separando o seu desenvolvimento nas etapas de levantamento de requisitos do
projeto, desenho de interface gráfica da aplicação web, projeto de Banco de Dados, ela-
boração dos contratos inteligentes e integração desses contratos inteligentes à aplicação
web.

Depois, no capítulo de Desenvolvimento e Resultados Obtidos, são apresentados dia-

gramas que desecrevem os trabalhos realizados durante o projeto, bem como decisões
tomadas ao longo do seu curso. Ao final do capítulo, é feita uma discussão dos resulta-
dos obtidos e são apontados pontos fortes do trabalho e oportunidades de melhoria.

Por fim, o capítulo de Conclusão retoma os principais pontos abordados durante o texto
e menciona possíveis desdobramentos futuros.

3
Capítulo 2

Referencial Teórico

Neste capítulo serão apresentados os conceitos que irão servir como base para a com-
preensão do desenvolvimento deste trabalho.

Inicialmente serão abordados o conceito de crowdfunding encontrado na literatura e

os diferentes modelos pelos quais esta prática vem sendo aplicada. Em seguida, se-
rão apresentados conceitos relacionados ao desenvolvimento de aplicações por meio
da utilização de matemática e criptografia, abordando as tecnologias Bitcoin, Block-
chain e Ethereum. Por fim, serão apresentados alguns trabalhos anteriores sobre temas
relacionados a este trabalho.

2.1 Crowdfunding
A Internet facilita a cooperação entre as pessoas para atingir seus mais diversos objetivos,
dentre estes, objetivos financeiros que envolvem a arrecadação coletiva de fundos, como
doações, empréstimos e até mesmo comércio de ações.

Neste sentido, o termo Crowdfunding pode ser definido como a prática de financiar um
projeto ou empreendimento, arrecadando dinheiro de um grande número de pessoas
que contribuem, cada uma, com uma quantidade relativamente pequena, geralmente
pela Internet (OXFORD, 2018).

Segundo o trabalho desenvolvido por Gedda et al. (2016), existem atualmente sete
modelos de Crowdfunding operando em plataformas pela Internet: doação, recompensa,
patrocínio, compra antecipada, empréstimo com juros, empréstimo sem juros e partici-
pação.

Como ilustra a Figura 1, estes modelos são classificados pelos autores em três categorias:
sem recompensa, não-financeiros e financeiros.

4
 Figura 1 – Modelos de Crowdfunding

Fonte: Gedda et al. (2016)

2.1.1 Modelos sem recompensa

Nos modelos compreendidos por esta categoria de financiamento coletivo, as pessoas
investem em um projeto ou uma causa que acreditam sem qualquer expectativa de
recompensa financeira. Estão incluídos nesta categoria os modelos de doação e de
empréstimo sem juros.

2.1.1.1 Modelo de doação

Neste modelo as pessoas apenas doam o dinheiro, sem receber nada em troca. Um exem-
plo de plataforma que segue este modelo é a JustGiving, em que é possível encontrar
campanhas de arrecadação de fundos relacionadas a projetos de caridade, tais como
despesas médicas, alimentação de refugiados e despesas com veterinário.

2.1.1.2 Modelo de empréstimo sem juros

Neste modelo as pessoas emprestam dinheiro para ajudar projetos tipicamente de

cunho social e depois de algum tempo são reembolsadas sem o acréscimo de juros. Um
exemplo de plataforma que segue este modelo é a Kiva, em que é possível contribuir
com iniciativas tais como compra de insumos para agricultura, pagamento de despesas
escolares e compra de produtos para revenda.

5
2.1.2 Modelos não-financeiros
Nos modelos não-financeiros, o contribuinte tem a expectativa de receber uma recom-
pensa tangível, porém não-financeira, em troca do dinheiro arrecadado. Incluem-se
nessa categoria os modelos de recompensa, patrocínio e compra antecipada.

2.1.2.1 Modelo de recompensa

Neste modelo as pessoas recebem, em contrapartida por suas contribuições financeiras,

recompensas que não correspondem ao produto ou serviço com o qual elas estão
contribuindo. Um exemplo de plataforma que segue este modelo é a Kickstarter, em que
é possível encontrar campanhas em que as pessoas recebem adesivos ou camisas por
contribuir com um projeto.

2.1.2.2 Modelo de patrocínio

Este modelo é mais voltado para empresas. Nele, as pessoas trocam suas contribui-
ções financeiras por uma conexão publicamente visível ao projeto. Um exemplo de
plataforma que segue este modelo é a SPONSOR.ME, em que é possível encontrar
campanhas que oferecem divulgação da marca dos doadores em meios eletrônicos ou
físicos, como camisetas, com visibilidade proporcional à quantia doada.

2.1.2.3 Modelo de compra antecipada

Este modelo é análogo ao modelo de recompensa, porém a recompensa corresponde

à aquisição antecipada do produto ou serviço promovido pela campanha. Também é
possível encontrar campanhas que seguem este modelo no Kickstarter.

2.1.3 Modelos financeiros

Nos modelos financeiros existe a expectativa por parte dos contribuintes de receber
uma recompensa financeira em troca do dinheiro investido. Incluem-se nessa categoria
os modelos de empréstimo com juros e de participação.

2.1.3.1 Modelo de empréstimo com juros

Neste modelo as pessoas emprestam dinheiro a indíviduos ou empresas a troco de

juros. Um exemplo de plataforma que segue este modelo é a FundingCircle, em que
um investidor pode emprestar dinheiro diretamente para proprietários de pequenos
negócios na Inglaterra.

6
2.1.3.2 Modelo de participação

Neste modelo, empresas criam a campanha oferecendo aos contribuintes uma parcela
de participação nos lucros da empresa. Um exemplo de plataforma que segue este
modelo é a CrowdCube.

2.2 Bitcoin
O Bitcoin é um sistema de pagamentos que nasceu com o objetivo de utilizar criptografia
para eliminar a necessidade de organizações intermediárias nas transações de comércio
eletrônico. O trabalho desenvolvido por Nakamoto (2008) resultou na criação de um
mecanismo em que indivíduos participantes de uma rede peer-to-peer podem trocar
criptomoedas diretamente entre si.

Nesta tecnologia, os usuários não possuem moedas propriamente ditas, mas sim um
histórico de transações efetuadas e recebidas registradas em um livro-razão. Neste
sentido, se um usuário possui bitcoins então ele possui transações endereçadas a ele
registradas neste livro.

Um dos desafios enfrentados na implementação deste sistema consiste no problema

do gasto duplo da mesma criptomoeda, de forma que uma mesma transação pode ser
utilizada mais de uma vez, por consistir em um arquivo digital que pode ser duplicado
ou falsificado (CHOHAN, 2017).

A Figura 2 ilustra uma situação hipotética em que uma usuária do Bitcoin possui
transações endereçadas a ela no valor de 10 bitcoins e tenta transferir essa quantia para
dois usuários diferentes, referenciando as mesmas transações mais de uma vez.

Figura 2 – Problema do gasto-duplo de criptomoedas

Fonte: Kasireddy (2018)

7
2.2.1 Blockchain
O Blockchain é uma outra criação de Nakamoto (2008), que se baseia na tecnologia de
log seguro para implementar o livro-razão distribuído utilizado pelo Bitcoin.

Segundo Une (2001), um serviço de log seguro tem o papel de assegurar a existência de
determinado documento digital antes de um ponto específico no tempo.

No caso do Bitcoin, é preciso estabelecer um critério de desempate para que a mesma

moeda não seja gasta mais de uma vez. A estratégia utilizada considera válida somente
a primeira transação a ser registrada. Em inglês, essa estratégia é conhecida como
first-to-file (BUTERIN et al., 2014).

Para verificar se uma transação já foi utilizada, faz-se necessário que todos os partici-
pantes da rede tenham conhecimento sobre as transações já registradas até o momento.
Desta forma, em contraste com o modelo centralizado adotado pelos bancos, as transa-
ções que ocorrem no Blockchain são visíveis publicamente, como ilustra a Figura 3.

Figura 3 – Amostra de transações de um bloco do Blockchain

Fonte: Blockchain (2018)

Na figura é possível observar algumas estruturas indicadas por contornos coloridos,

de forma que o contorno em azul indica as entradas de uma transação, o contorno em
verde indica suas saídas e o contorno em vermelho indica seu identificador no sistema.

Ambas as entradas e as saídas da transação estão representadas por pares endereço-

quantia denominados saídas não-gastas de transação, ou UTXO (do inglês Unspent
Transaction Output), de forma que as UTXO que entram são gastas e as UTXO que saem
são geradas.

Ainda segundo Nakamoto (2008), o Bitcoin é constituído por uma cadeia de assinaturas

8
digitais que envolvem o hash da transação anterior e a chave pública do beneficiário da
transação corrente.

2.2.1.1 Funções de hash

Na matemática aplicada à criptografia, uma função de hash é definida como uma

operação de via única, que não pode ser invertida, cuja aplicação resulta em uma saída
de tamanho fixo, que só pode ser obtida por meio de uma entrada idêntica (CABRAL;
CAPRINO, 2015).

A Figura 4 ilustra este processo, de forma que uma mensagem de texto com tamanho
arbitrário se transforma em um código de tamanho fixo denominado digest ao passar
por um funil que representa a função de hash.

Figura 4 – Função de hash

Fonte: Mateti (2017)

O comprimento da saída gerada depende do algoritmo de hash escolhido. No caso do

Bitcoin, é utilizado o algoritmo SHA-256, que produz uma saída de 256 bits.

Algoritmos de hash são construídos por meio de complexos arranjos de operações

matemáticas encadeadas, projetados de forma a oferecer uma baixa probabilidade de
colisão entre os hashes de duas mensagens distintas.

2.2.1.2 Criptografia assimétrica

A criptografia assimétrica utiliza uma chave pública para cifrar e uma chave privada
para decifrar uma mensagem. Quando se cifra utilizando a chave privada, está se apli-
cando uma assinatura digital, pois essa mensagem só poderá ser decifrada utilizando a
chave pública correspondente (CANAVAN, 2001).

9
As UTXOs geradas no sistema Bitcoin são matematicamente vinculadas às chaves cripto-
gráficas de quem as possui. Dessa forma, assinaturas digitais podem ser utilizadas para
provar a posse de uma chave privada sem que seja necessário revelá-la, possibilitando
assim o desbloqueio das UTXOs para que sejam utilizadas pelos seus respectivos donos
em novas transações (BARRERA, 2014).

Quando ocorre uma transação no Bitcoin, as UTXOs utilizadas na entrada precisam ser
desbloqueadas e as UTXOs geradas na saída precisam ser bloqueadas. Dessa forma,
quando um usuário transfere bitcoins a alguém, este deve primeiro provar que possui
as UTXOs da entrada, por meio do fornecimento de uma assinatura digital, e então
fornecer a chave pública do destinatário da transação, para que um script seja gerado
para bloquear a nova UTXO, de forma que apenas o possuidor da respectiva chave
privada possa desbloqueá-la.

A Figura 5 ilustra os scripts de bloqueio e desbloqueio de uma transação. O script de

bloqueio recebe o script de desbloqueio como argumento e verifica se a assinatura
fornecida correspondente à chave pública especificada.

Figura 5 – Bloqueio e desbloqueio de uma transação

Fonte: Antonopoulos (2014)

2.2.2 Prova de trabalho

Para resolver o problema do gasto-duplo no Bitcoin, as transações são organizadas em
blocos e encadeadas cronologicamente no Blockchain. Com isso, faz-se necessário um
mecanismo de consenso para que os participantes concordem em um histórico único
que contenha a ordem em que os blocos foram recebidos.

O mecanismo de consenso empregado pelo Bitcoin é chamado de prova de trabalho ou,

em inglês, proof-of-work. Neste mecanismo, os participantes da rede que desejam adicio-
nar blocos de transações ao histórico compartilhado, aqui denominados mineradores,
competem entre si para resolver um desafio matemático que envolve a obtenção de um
hash criptográfico com uma determinada quantidade de zeros à esquerda.

10
Nakamoto (2008) afirma que o trabalho médio necessário para resolver o desafio é
exponencialmente proporcional ao número de bits zero requeridos pela rede, mas o
resultado pode ser verificado pela simples aplicação do algoritmo de hash, que precisa
ser feita apenas uma única vez.

A Figura 6 apresenta o histórico do tempo de confirmação dos blocos no período de

Maio/2017 a Maio/2018. Como pode ser observado, o tempo se mantém ao redor
de 10 minutos. Isto se deve ao fato de que a cada 2016 blocos — aproximadamente
duas semanas — o nível de dificuldade do desafio é reavaliado para que este tempo se
mantenha (BITCOINWIKI, 2018).

Figura 6 – Tempo de confirmação dos blocos

Fonte: (BITINFOCHARTS, 2018)

2.2.3 Scripts de transação

A Subsubseção 2.2.1.2 exemplificou um caso em que uma assinatura digital pode ser
utilizada para desbloquear uma UTXO em posse de um determinado usuário da rede
Bitcoin, contudo, esta não é a única possibilidade que o sistema oferece.

UTXOs também podem ser desbloqueadas por meio da execução de um script, de forma
que para utilizá-las é preciso fornecer dados que satisfaçam o algoritmo implementado.

Buterin et al. (2014) explicam que:

Até mesmo o mecanismo de posse por chaves públicas é implementado por

um script: o script recebe uma assinatura digital como entrada, verifica-a
perante a transação e o endereço que possui a UTXO e retorna 1 se a verifica-
ção for bem-sucedida e 0 caso contrário. Outros scripts, mais complicados,
existem para vários casos de uso adicionais. Por exemplo, pode-se construir
um script que requeira assinaturas de duas dentre três chaves privadas para
que o gasto de uma UTXO seja autorizado (multisig).

11
Entretanto, a linguagem de script implementada no Bitcoin possui limitações. Por meio
dela não é possível, por exemplo, autorizar o gasto de apenas uma fração da quantia
armazenada em uma UTXO (BUTERIN et al., 2014).

2.3 Ethereum
Ethereum é uma tecnologia de livro-razão distribuído, ou DLT (do inglês Distributed
Ledger Technology), que permite a escrita de contratos inteligentes e aplicações descentra-
lizadas por meio de uma máquina virtual distribuída (WIKIPEDIA, 2018; BUTERIN et
al., 2014).

Diferentemente do Bitcoin, que é um sistema especializado para operar com transações

financeiras, o Ethereum tem um escopo mais amplo e sua máquina virtual turing-
completa, a Ethereum Virtual Machine (EVM), é capaz de executar qualquer aplicação
que possa ser definida em termos de um algoritmo.

O Ethereum mantém o estado da EVM no blockchain e todos os nós mineradores proces-

sam e verificam a integridade dos contratos inteligentes.

2.3.1 Contratos inteligentes

Contratos inteligentes são trechos de software associados a contas do Ethereum que ape-
nas desbloqueiam os valores nelas armazenados mediante a satisfação de determinadas
condições (BUTERIN et al., 2014).

A Figura 7 ilustra um exemplo de aplicação em que um contrato inteligente é utilizado

como parte neutra para armazenar o pagamento e a garantia de uma negociação que
envolve os atores Bob e Alice. Neste exemplo, Alice contratou Bob para construir um
pátio e os dois concordaram em depositar 1 ether em um contrato de custódia (em inglês,
escrow). Caso Bob realize o serviço corretamente, ele poderá sacar o valor de 2 ether após
o encerramento das atividades. No entanto, caso o compromisso não seja cumprido,
Alice resgata o seu depósito e o de Bob.

2.3.1.1 Linguagem Solidity

Ao longo do tempo, muitas linguagens de programação foram desenvolvidas para o

desenvolvimento de contratos inteligentes, tais como LLL, Serpent e Mutan. No entanto,
atualmente os contratos inteligentes são escritos majoritariamente na linguagem Solidity.
As linguagens Serpent e Mutan foram descontinuadas e a linguagem LLL ainda é usada
para casos muito específicos. (ORLICKI, 2018).

12
 Figura 7 – Contrato de custódia

Fonte: (TRUFFLE, 2018)

2.3.1.2 Gas

No Ethereum, a leitura de dados do blockchain é uma operação gratuita, mas a escrita

não. O custo de uma transação é denominado gas, em referência ao termo em inglês
gasoline, e tem o propósito de limitar a quantidade de trabalho necessária para executar
a transação e também de pagar por essa execução (TRUFFLE, 2018; SOLIDITY, 2018a).

De certa forma, gas é uma medida de complexidade de uma transação. À medida que
o número de operações realizadas por um contrato inteligente aumenta, o custo da
transação também cresce.

2.3.2 Contas
Uma conta no Ethereum pode ser de dois tipos: conta de propriedade externa, do inglês
Externally Owned Account (EOA), ou conta de contrato.

Essas contas contém quatro campos:

• nonce, um contador usado para garantir que cada transação possa ser processada
apenas uma vez;
• saldo atual da conta;
• código do contrato da conta, se presente;
• armazenamento da conta (vazio por padrão).

Como se pode observar, o Ethereum apresenta importantes diferenças em relação ao

Bitcoin. No Ethereum, as UTXOs dão lugar ao conceito de saldo e a verificação de
gasto-duplo é feita por meio do campo nonce.

13
Contratos no Ethereum são considerados “cidadãos de primeira classe“ (BUTERIN et
al., 2014). Toda vez que uma conta de contrato recebe uma mensagem seu código é
ativado, o que permite a leitura e a escrita no armazenamento interno, o envio de novas
mensagens e a criação de novos contratos.

2.3.2.1 Redes Ethereum

Uma rede Ethereum pode ser pública ou privada. Dentre as redes públicas, existem
algumas redes de teste e existe a Main Network, que é a principal rede dessa tecnologia e
trafega o maior volume diário de transações.

As redes públicas de teste são três:

• Ropsten funciona de maneira similar à Main Network;

• Kovan utiliza um algoritmo de consenso chamado proof-of-authority. As transações
são validadas por membros selecionados e não é necessário realizar o procedi-
mento de mineração. Utiliza o algoritmo Authority round como mecanismo de
consenso;
• Rinkeby também é baseada no algoritmo proof-of-authority, porém adota o algo-
ritmo Clique como mecanismo de consenso.

2.3.2.2 Carteiras

No ambiente Ethereum, uma carteira consiste em um software que armazena chaves

criptográficas relacionadas a contas de usuário (EOA) e realiza transações em redes
públicas ou privadas.

As carteiras precisam manter cópias atualizadas do blockchain para operar. Ao abrir

o software, é necessário aguardar o processo de sincronização, que pode levar alguns
minutos.

Existem serviços na internet que fornecem acesso remoto a clientes Ethereum que rodam
em infraestruturas de nuvem. Ao usufruir desses serviços, o usuário não precisa se
preocupar com o armazenamento e nem com a sincronização do blockchain. Um exemplo
de tal serviço é o Infura, oferecido pela empresa ConsenSys.

14
2.4 Trabalhos relacionados
A plataforma GiveTrack utiliza o Bitcoin como meio de pagamento do seu serviço de
crowdfunding voltado para arrecadar doações. Ela não impede o mau uso das doações,
mas provê um log seguro e transparente das movimentações feitas com o dinheiro
arrecadado.

A Figura 8 ilustra o estados de uma campanha no GiveTrack. Através desse componente,

os usuários da plataforma podem acompanhar o estado das campanhas de doação de
forma transparente.

Figura 8 – Estados de uma campanha na plataforma GiveTrack

Fonte: GiveTrack

O projeto Charity Chain, ainda em desenvolvimento, consiste em uma plataforma que

permite a criação de campanhas de crowdfunding para projetos de caridade. As campa-
nhas da plataforma implementam, através de contratos inteligentes, um protocolo que
estabelece que os donos das campanha devem arcar com 50% do objetivo estabelecido e
os outros 50% devem ser obtidos através de doações da comunidade. A Figura 9 ilustra
este processo.

Figura 9 – Funcionamento de uma campanha na plataforma Charity Chain

Fonte: Charity Chain

Mazet e Wojciechowski (2017) desenvolveram uma plataforma de crowdfunding baseada

em contratos inteligentes em que os objetivos das campanhas devem ser validados por
instituições independentes. A plataforma se chama Alice e é similar à GiveTrack, pois
também reporta o estado das campanhas para os doadores.

15
A Figura 10 ilustra o protocolo implementado pelos contratos inteligentes da plataforma
Alice. Destaca-se o papel do validador, que confere o que será feito com o dinheiro antes
de permitir a efetuação dos pagamentos.

Figura 10 – Funcionamento de uma campanha na plataforma Alice

Fonte: Mazet e Wojciechowski (2017)

16
Capítulo 3

Metodologia

Neste capítulo serão apresentadas as atividades a serem desenvolvidas neste trabalho

assim como os métodos e ferramentas utilizados para a realização destas.

3.1 Levantamento de requisitos do projeto

Com base nas informações de contextualização, objetivos e justificativa, levantadas
no capítulo de Introdução, deve-se identificar necessidades essenciais, importantes e
desejáveis que o serviço desenvolvido deve atender. Após a listagem desses aspectos,
deve-se identificar os requisitos funcionais, não-funcionais e de interface do serviço e
relacioná-los, por meio de uma tabela, com as necessidades elicitadas, de forma a gerar
uma matriz de rastreabilidade.

Acredita-se que a identificação das necessidades e expectativas dos stakeholders auxilia

na qualidade do levantamento de requisitos, de forma a evitar a elicitação de requisitos
desnecessários e a cobrir casos de uso de partes interessadas que por ventura poderiam
ser esquecidas.

3.2 Desenho da interface gráfica da aplicação web

Após a etapa de levantamento dos requisitos, é iniciada a etapa de desenho da interface
gráfica da aplicação web. Optou-se por elaborar as telas da aplicação diretamente por
meio de código, sem passar pela etapa de criação dos desenhos em um software de design
gráfico. Esta escolha se deu pois almeja-se um resultado final simples, em que as telas
serão criadas a partir de componentes de prateleira.

Optou-se por utilizar a biblioteca de código React para estruturar a interface gráfica, pois
ela provê uma estrutura de código que auxilia na criação de aplicativos web e também

17
auxilia na integração com a biblioteca de componentes gráficos adotada, que será a
Material-UI.

3.3 Projeto do banco de dados

De posse da especificação de requisitos e das telas de interface gráfica, deve-se extrair
os dados que necessitam ser persistidos pela aplicação e mapeá-los aos seus destinos de
armazenamento. Parte dos dados será armazenada em contratos inteligentes e parte
será armazenada em um banco de dados.

De forma a facilitar o desenvolvimento da aplicação e dispensar a criação de um software

de back-end para prover uma API de acesso aos dados, optou-se pela utilização do serviço
de banco de dados Firebase, oferecido pela empresa Google Cloud. Este serviço armazena
coleções de dados não-estruturados no formato JSON e fornece uma biblioteca javascript
para acessá-los.

3.4 Elaboração dos contratos inteligentes

Com toda a especificação definida, inicia-se a etapa de elaboração dos contratos inteli-
gentes. Para realizar a compilação, implantação e testes dos contratos inteligentes, será
utilizada a ferramenta Remix, que é uma IDE online da linguagem Solidity.

Para que a IDE consiga se comunicar com a rede Ethereum, deve-se utilizar o navegador
Google Chrome e instalar uma extensão chamada Metamask. Essa extensão oferece a
funcionalidade de carteira Ethereum e permite a conexão a redes Ethereum através de
nós remotos que executam sobre uma infraestrutura de nuvem fornecida pelo serviço
Infura.

O desenvolvimento do software será feito na rede de testes Rinkeby, pois, por utilizar
o algoritmo proof-of-authority ao invés do algoritmo proof-of-work, esta rede é menos
suscetível a sofrer ataques de pessoas mal intencionadas.

3.5 Verificação dos contratos inteligentes

Após o desenvolvimento dos contratos inteligentes, é iniciada a etapa de verificação e
testes da solução no ambiente Remix. Para isso, devem ser criadas contas de teste na
rede Rinkeby e estas devem ser utilizadas para testar todas as operações dos contratos,
buscando cobrir o maior número de condições de utilização possível.

18
3.6 Integração dos contratos inteligentes à aplicação web
Por fim, com o contrato inteligente publicado na rede Ethereum, a aplicação web pre-
cisa interagir com os métodos implementados nos contratos inteligentes. Para isto, é
utilizada a biblioteca de software web3, que é capaz de comunicar com redes Ethereum
por meio de uma especificação de chamada de procedimento remoto, do inglês Remote
Procedure Call (RPC).

19
Capítulo 4

Desenvolvimento e Resultados Obtidos

4.1 Requisitos do projeto

Como descrito no capítulo anterior, o desenvolvimento deste projeto se inicia pelo
levantamento de requisitos. Um documento com os requisitos detalhados encontra-se
disponível no Apêndice A.

A Figura 11 apresenta um diagrama que contém os requisitos funcionais da solução

proposta. Estes requisitos representam as funcionalidades que o contrato inteligente
precisa prover para o aplicativo, que consistem nas capacidades de criar campanhas e
de doar, transferir e recuperar ethers. Para as campanhas da modalidade de fases, são
apresentadas também as funcionalidades relativas ao sistema de votação.

Figura 11 – Diagrama de requisitos funcionais da solução proposta

Fonte: Do autor

Com base nos requisitos elicitados, foram desenvolvidos os contratos inteligentes

apresentados na figura Figura 12: CampaignFactory , EntitiesCampaign e
PhasesCampaign .

20
4.2 Contratos inteligentes
O contrato CampaignFactory se faz necessário para manter a integridade dos contra-
tos de campanha criados pelos usuários da plataforma. Se os usuários criassem os contra-
tos de campanha de forma independente, a plataforma não saberia se estes são legítimos
e, caso a plataforma criasse os contratos inteligentes em nome dos usuários, o custo das
transações recairia sobre os seus mantenedores. O padrão factory resolve esse impasse,
de forma que os usuários executam as operações createEntitiesCampaign ou
createPhasesCampaign , que, por sua vez, criam o contrato inteligente e repassam
os custos da transação para o cliente que iniciou a operação.

No Ethereum, operações que alteram o estado do blockchain não podem retornar valores.
Para contornar este problema, as operações de criação de campanha fazem uso do
evento LogCampaign para notificar o endereço do novo contrato.

A seguir são detalhados o funcionamento dos contratos de campanha. Os códigos dos

contratos inteligentes, escritos em Solidity, encontram-se disponíveis no Apêndice B.

4.2.1 Contrato EntitiesCampaign

O contrato EntitiesCampaign descreve as operações da modalidade de campanha
em que os fundos arrecadados só podem ser repassados a entidades que foram listadas
no momento de criação da campanha. Neste contrato, o modificador restricted
indica que a operação só pode ser chamada pelo criador da campanha e o modificador
payable indica que a operação recebe ethers.

A função donate tem a responsabilidade de receber uma doação e armazenar o valor

recebido nos atributos contributions e amountRaised . Esta função só é executada
caso a campanha esteja em período de vigência.

A função transferTo tem a responsabilidade de transferir ethers no valor estipulado

pelo parâmetro value para a conta estipulada pelo parâmetro entity . A implemen-
tação dessa operação segue o padrão Check-Effects-Interactions, para evitar ataques de
reentrância (SOLIDITY, 2018b). Esta função só é executada caso exista saldo suficiente,
a conta de destino esteja na lista das entidades permitidas pelo contrato e a campanha
tenha encerrado e atingido o seu objetivo.

A função reclaim tem a responsabilidade de devolver doações de volta para os

usuários caso uma campanha não atinja seu objetivo. Essa função só é executada caso a
campanha tenha falhado e o usuário tenha ethers para receber.

A função expire não faz parte da lógica da aplicação. Ela existe apenas para fins

21
 Figura 12 – Diagrama de classes dos contratos inteligentes

Fonte: Do autor

de demonstração e não deve ser considerada em uma implantação em ambiente de

produção. Tem a responsabilidade de expirar uma campanha de modo forçado.

4.2.2 Contrato PhasesCampaign

O contrato PhasesCampaign possui comportamento análogo ao observado no con-
trato EntitiesCampaign para as operações donate , reclaim e expire . No
entanto, este contrato difere do anterior na operação utilizada para transferir o valor
arrecadado por uma campanha. Neste contrato, não existe um método transferTo
que recebe a conta de destino e o valor, mas sim o método transfer , que repassa o
valor correspondente à fase atual para a conta do próprio criador da campanha.

Para que o criador de uma campanha consiga usufruir dos fundos arrecadados para
cada uma de suas fases, ele deve realizar pedidos de mudança de fase por meio da
operação requestPhaseChange . Esta ação inicia um processo de votação em que
os doadores que apoiam o resgate dos fundos para a nova fase devem explicitar seus
consentimentos individuais por meio da operação approvePhaseChange .

Para que o pedido de alteração de fase seja aprovado, é necessário que a soma das
contribuições realizadas pelos usuários votantes para a campanha exceda 50% do
montante total arrecadado. Esta estratégia foi adotada para prevenir ataques Sybil,

22
em que um mesmo indivíduo mal intencionado pode criar múltiplas identidades e
atacar uma rede peer-to-peer (DOUCEUR, 2002). Desta forma, para que um dono de
campanha mal intencionado consiga manipular o resultado de uma votação, este deve
ter contribuído com grande parte dos recursos da campanha, o que diminui os impactos
de um possível ataque.

Uma vez que a votação tenha acontecido e o pedido tenha sido aprovado, a fase corrente
pode ser alterada por meio da operação changePhase .

4.3 Telas da aplicação

A Figura 13 ilustra a tela de criação de campanhas. Nela, o usuário preenche um formulá-
rio com os dados da campanha e clica no botão Criar, que aciona, por meio da extensão
MetaMask, o método createCampaign do contrato inteligente que implementa o
padrão Factory.

Figura 13 – Tela de criação de campanhas

Fonte: Do autor

A Figura 14 apresenta a tela de confirmação de transação da extensão MetaMask. Nesta

tela é possível definir o preço da transação a partir dos campos Gas Limit e Gas Price.
Quanto maior for o valor oferecido pela confirmação desta transação, mais altas serão
as chances da transação ser confirmada mais rapidamente.

23
 Figura 14 – Tela de confirmação de transação

Fonte: Do autor

A Figura 15 apresenta a tela de listagem de campanhas cadastradas na plataforma.

As campanhas são buscadas do banco de dados Firebase e então os seus parâmetros
sensíveis são consultados por meio do contrato inteligente.

Figura 15 – Tela de de listagem de campanhas cadastradas na plataforma

Fonte: Do autor

24
A Figura 16 apresenta a tela de doação ethers. O usuário entra com o valor em ether
que deseja contribuir para a campanha e clica no botão Doar, que aciona o contrato
inteligente por intermédio da extensão MetaMask.

Figura 16 – Tela de doação de ethers

Fonte: Do autor

A Figura 17 apresenta o ambiente de testes da IDE Remix. Por meio dessa interface
é possível executar a operação expire , que não se encontra disponível na interface
gráfica da solução proposta.

A Figura 18 apresenta a tela de transferência de ethers para a modalidade de campanha

por entidades pré-registradas. O criador da campanha preenche o endereço da institui-
ção beneficiada na rede pública do Ethereum e o valor a ser transferido, e então clica no
botão Criar, que também aciona o contrato inteligente. A tela de transferência de ethers
para a modalidade de campanha por fases não precisou ser desenhada, pois a operação
não recebe nenhum argumento.

4.4 Discussão dos resultados obtidos

Os resultados obtidos alcançaram o objetivo de demonstrar o funcionamento de con-
tratos inteligentes aplicados ao domínio de crowdfunding por doações. Pontos fortes da

25
 Figura 17 – Expiração de campanhas através da IDE Remix

Fonte: Do autor

Figura 18 – Tela de transferência de ethers

Fonte: Do autor

plataforma desenvolvida incluem as proteções empregadas na transferência dos fundos

arrecadados e a transparência alcançada pela utilização da plataforma Ethereum.

Alguns pontos que poderiam melhorar incluem a definição de prazos da modalidade

26
de campanha organizada por fases e a destinação dos fundos não gastos pelo criador
da campanha que remanescem nos contratos inteligentes. Na implementação atual, não
existe prazo para o processo de votação se encerrar e, também, o sistema não permite
que os usuários resgatem dinheiro de campanhas bem-sucedidas.

27
Capítulo 5

Conclusão

Com a finalidade de mitigar os riscos de mau uso dos fundos arrecadados por cam-
panhas de crowdfunding, este trabalho propôs o desenvolvimento de uma plataforma
descentralizada, focada no modelo de crowdfunding por doações, que utiliza a tecnologia
blockchain para oferecer a seus usuários maior transparência a respeito da destinação
dos fundos nela arrecadados.

Na solução desenvolvida, foram implementadas regras para a destinação dos fundos

arrecadados, de forma que os apoiadores das campanhas tenham maior previsibilidade
e controle sobre as movimentações financeiras realizadas com os recursos adquiridos
por meio de doações.

Os resultados obtidos se mostraram alinhados aos objetivos esperados, porém alguns

pontos de melhoria foram identificados, como o aperfeiçoeamento da definição de pra-
zos e da destinação dos fundos não transferidos, que ficam armazenados nos contratos
inteligentes por tempo indeterminado.

Em trabalhos futuros, a plataforma poderia ser extendida para outros modelos de

crowdfunding que não o de doação, como, por exemplo, o modelo de empréstimos sem
juros, que também pertence à categoria de modelos sem recompensa.

28
 Referências

ANTONOPOULOS, A. M. Mastering Bitcoin: unlocking digital cryptocurrencies.

[S.l.]: "O’Reilly Media, Inc.", 2014. Citado na página 10.
BARRERA, A. A Guide to Bitcoin (Part I): A look under the hood. [s.n.], 2014. Dis-
ponível em: <http://tech.eu/features/808/bitcoin-part-one/>. Citado na página
10.
BITCOINWIKI. Difficulty - Bitcoin Wiki. 2018. Disponível em: <https://en.bitcoin.it/
wiki/Difficulty>. Citado na página 11.
BITINFOCHARTS. Bitcoin Block Time chart. [s.n.], 2018. Disponível em: <https://
bitinfocharts.com/comparison/bitcoin-confirmationtime.html>. Citado na página 11.
BLOCKCHAIN. Bitcoin Block 523452. [s.n.], 2018. Disponível em: <https://blockchain.
info/block/000000000000000000208cbf4c8763c61d7ceacde416ad58635b367fb1d21fc0>.
Citado na página 8.
BUTERIN, V. et al. A next-generation smart contract and decentralized application
platform. white paper, 2014. Citado 4 vezes nas páginas 8, 11, 12 e 14.
CABRAL, C.; CAPRINO, W. Trilhas em Segurança da Informação: Caminhos e ideias
para a proteção de dados. [S.l.]: Brasport, 2015. Citado na página 9.
CANAVAN, J. E. Fundamentals of Network Security. [S.l.]: Artech House, 2001. Ci-
tado na página 9.
CHOHAN, U. The double spending problem and cryptocurrencies. 2017. Citado na
página 7.
DOUCEUR, J. R. The sybil attack. In: SPRINGER. International workshop on peer-to-
peer systems. [S.l.], 2002. p. 251–260. Citado na página 23.
GEDDA, D. et al. Crowdfunding: Finding the optimal platform for funders and en-
trepreneurs. Technology Innovation Management Review, Talent First Network, v. 6,
n. 3, p. 31–40, 2016. Citado 2 vezes nas páginas 4 e 5.
KASIREDDY, P. ELI5: What do we mean by “blockchains are trus-
tless”? 2018. Disponível em: <https://medium.com/@preethikasireddy/
eli5-what-do-we-mean-by-blockchains-are-trustless-aa420635d5f6>. Citado na
página 7.
MATETI, P. Hash Functions. 2017. Disponível em: <http://cecs.wright.edu/~pmateti/
Courses/3900/Lectures/Passwords/hash-functions.html>. Citado na página 9.
MAZET, R.; WOJCIECHOWSKI, J. Alice white paper. 2017. Disponível em: <https:
//github.com/alice-si/whitepaper>. Citado 2 vezes nas páginas 15 e 16.
NAKAMOTO, S. Bitcoin: A peer-to-peer electronic cash system. 2008. Citado 3 vezes
nas páginas 7, 8 e 11.

29
ORLICKI, J. I. Programming languages intro. 2018. Disponível em: <https://github.
com/ethereum/wiki/wiki/Programming-languages-intro>. Citado na página 12.

OXFORD. Oxford British And World English Dictionary. [s.n.], 2018. Disponível em:
<https://en.oxforddictionaries.com/definition/crowdfunding>. Citado na página 4.

SOLIDITY. Introduction to Smart Contracts. 2018. Disponível em: <http://solidity.

readthedocs.io/en/v0.4.21/introduction-to-smart-contracts.html>. Citado na página
13.

SOLIDITY. Security Considerations. 2018. Disponível em: <http://solidity.

readthedocs.io/en/v0.4.21/security-considerations.html>. Citado na página
21.

TRUFFLE. Ethereum Overview. 2018. Disponível em: <http://truffleframework.com/

tutorials/ethereum-overview>. Citado na página 13.

UNE, M. The security evaluation of time stamping schemes: The present situation and
studies. In: IMES Discussion Papers Series 2001-E-18. [S.l.: s.n.], 2001. p. 100–8630.
Citado na página 8.

WIKIPEDIA. Ethereum. 2018. Disponível em: <https://en.wikipedia.org/wiki/

Ethereum>. Citado na página 12.

30
Apêndices
APÊNDICE A – Documento de
Requisitos

32
1 NECESSIDADES IDENTIFICADAS
A prioridade dos requisitos pode ser classificada como: [E] Essencial - é o requisito
imprescindível, sem o qual o sistema não faz sentido; [I] Importante - é o requisito sem o qual o
sistema entra em funcionamento (poderá ser implantado e usado), mas de forma restrita e não
satisfatória; [D] Desejável - é o requisito que não compromete o funcionamento básico do sistema
(pode funcionar de forma satisfatória sem o requisito, que pode ser deixado para versões
posteriores do sistema, caso não haja tempo hábil para implementá-lo).

Da mesma forma, a complexidade pode ser classificada como: [A] Alta - exige um esforço
significativo e/ou o conhecimento de profissional especialista no assunto (sênior); [M] Média -
exige um esforço grande e/ou o conhecimento de profissional com fluência no assunto (pleno);
[B] Baixa - exige um esforço moderado e/ou um conhecimento básico no assunto (profissional
júnior)>

PARTE (S)
ID NECESSIDADE A SER ATENDIDA PRIORIDADE
ENVOLVIDA (S)
1 Arrecadar fundos E Dono da campanha
2 Usufruir dos fundos arrecadados E Dono da campanha
3 Evitar desperdício de dinheiro I Doador, Dono da
campanha
4 Contribuir com campanhas de E Doador
crowdfunding

2 REQUISITOS DO PRODUTO / SERVIÇO

2.1 REQUISITOS FUNCIONAIS
ID: RF01 NOME: REGISTRO DE CAMPANHAS
DESCRIÇÃO:
O SISTEMA DEVE PERMITIR O REGISTRO DE UMA CAMPANHA DE CROWDFUNDING POR MEIO DA
INTERFACE GRÁFICA. O REGISTRO DEVE CONTER NOME, DESCRIÇÃO , TIPO , OBJETIVOS, PRAZO DE
VIGÊNCIA, ENTIDADES PERMITIDAS (SE APLICÁVEL ) E FASES (SE APLICÁVEL ).
ALOCAÇÃO: INTERFACE GRÁFICA, CONTRATO INTELIGENTE
PRIORIDADE: [X] E [ ] I [ ] D COMPLEXIDADE: [ ] A [ ] M [ X] B

ID: RF02 NOME: DOAÇÃO DE ETHERS

DESCRIÇÃO:
O SISTEMA DEVE PERMITIR A DOAÇÃO DE ETHERS PARA UMA CAMPANHA DENTRO DO SEU PRAZO
DE VIGÊNCIA .
ALOCAÇÃO: INTERFACE GRÁFICA, CONTRATO INTELIGENTE
PRIORIDADE: [X] E [ ] I [ ] D COMPLEXIDADE: [ ] A [ ] M [ X] B

ID: RF03 NOME: TRANSFERÊNCIA DE ETHERS ( MODALIDADE DE ENTIDADES PRÉ-

CADASTRADAS)
DESCRIÇÃO:
O SISTEMA DEVE PERMITIR A TRANSFERÊNCIA DE ETHERS PARA CONTAS PRÉ-CADASTRADAS ,
DESDE QUE A CAMPANHA TENHA ATINGIDO SEU OBJETIVO E EXISTA SALDO SUFICIENTE NA CONTA
DO CONTRATO .
ALOCAÇÃO: INTERFACE GRÁFICA, CONTRATO I NTELIGENTE
PRIORIDADE: [X] E [ ] I [ ] D COMPLEXIDADE: []A [ X] M [] B

ID: RF04 NOME: TRANSFERÊNCIA DE ETHERS ( MODALIDADE DE FASES)

DESCRIÇÃO:
O SISTEMA DEVE PERMITIR A TRANSFERÊNCIA DE ETHERS DA FASE CORRENTE PARA A CONTA DO
CRIADOR DA CAMPANHA , DESDE QUE A CAMPANHA TENHA ATINGIDO SEU OBJETIVO, EXISTA
SALDO SUFICIENTE NA CONTA DO CONTRATO E A OPERAÇÃO JÁ NÃO TENHA SIDO REALIZADA PARA
A MESMA FASE.
ALOCAÇÃO: INTERFACE GRÁFICA, CONTRATO I NTELIGENTE
PRIORIDADE: [X] E [ ] I [ ] D COMPLEXIDADE: [ ] A [ X] M [ ] B

ID: RF05 NOME: RECUPERAÇÃO DE ETHERS

DESCRIÇÃO:
O SISTEMA DEVE PERMITIR QUE DOADORES DE CAMPANHAS QUE EXPIRARAM SEM ATINGIR SEUS
OBJETIVOS POSSAM RECUPERAR OS VALORES DOADOS PARA SUAS CONTAS.
ALOCAÇÃO: INTERFACE GRÁFICA, CONTRATO I NTELIGENTE
PRIORIDADE: [ ] E [ X] I [ ] D COMPLEXIDADE: [ ] A [ X] M [ ] B

ID: RF06 NOME: LISTAGEM DE CAMPANHAS

DESCRIÇÃO:
O SISTEMA DEVE LISTAR AS CAMPANHAS CADASTRADAS PARA QUE OS USUÁRIOS POSSAM
INTERAGIR COM ELAS.
ALOCAÇÃO: INTERFACE GRÁFICA
PRIORIDADE: [X] E [ ] I [ ] D COMPLEXIDADE: [ ] A [ ] M [ X] B

ID: RF07 NOME: ALTERAR FASE DE CAMPANHA ( MODALIDADE DE FASES)

DESCRIÇÃO:
O SISTEMA DEVE PERMITIR QUE O DONO DA CAMPANHA ALTERE A FASE DA CAMPANHA PARA A
PRÓXIMA , DESDE QUE OS DOADORES APROVEM ESTE PROCEDIMENTO POR MEIO DE UMA VOTAÇÃO.
ALOCAÇÃO: INTERFACE GRÁFICA
PRIORIDADE: [X] E [ ] I [ ] D COMPLEXIDADE: [ ] A [ ] M [ X] B

ID: RF08 NOME: REALIZAR VOTAÇÃO ( MODALIDADE DE FASES)

DESCRIÇÃO:
O SISTEMA DEVE IMPLEMENTAR UM SISTEMA DE VOTAÇÃO PARA PERMITIR QUE OS USUÁRIOS
DOADORES DELIBEREM SOBRE A ALTERAÇÃO DE FASE DE UMA CAMPANHA. E STE SISTEMA DEVERÁ
FUNCIONAR DE MODO QUE SOMENTE SEJA REGISTRADO UM CONSENSO SE A SOMA DAS
CONTRIBUIÇÕES EFETUADAS PELOS APOIADORES FOR MAIOR QUE 50% DO VALOR TOTAL
RECEBIDO PELA CAMPANHA.
ALOCAÇÃO: INTERFACE GRÁFICA
PRIORIDADE: [X] E [ ] I [ ] D COMPLEXIDADE: [ ] A [ ] M [ X] B
 2.2 REQUISITOS NÃO FUNCIONAIS
ID: RNF01 NOME: PERSISTÊNCIA DE INFORMAÇÕES NÃO-CRÍTICAS
DESCRIÇÃO:
INFORMAÇÕES NÃO-CRÍTICAS, COMO TÍTULO E DESCRIÇÃO DA CAMPANHA , NÃO DEVEM SER
PERSISTIDAS NO BLOCKCHAIN , MAS SIM EM UM B ANCO DE DADOS SEPARADO.

ALOCAÇÃO: BANCO DE DADOS

PRIORIDADE: [ ] E [ X] I []D COMPLEXIDADE: []A [ X] M [] B

2.3 REQUISITOS DE INTERFACE

ID: RI01 NOME: INTERFACE ENTRE APLICAÇÃO E REDE ETHEREUM
DESCRIÇÃO:
O SISTEMA DEVE PROVER INTEGRAÇÃO ENTRE A INTERFACE GRÁFICA E UM CLIENTE ETHEREUM.

ALOCAÇÃO: INTERFACE GRÁFICA

PRIORIDADE: [X] E [ ] I [ ] D COMPLEXIDADE: []A [ X] M [] B

ID: RI02 NOME: INTERFACE ENTRE APLICAÇÃO E BANCO DE DADOS

DESCRIÇÃO:
O SISTEMA DEVE PROVER INTEGRAÇÃO ENTRE A INTERFACE GRÁFICA E UM SERVIDOR DE BANCO
DE DADOS .

ALOCAÇÃO: INTERFACE GRÁFICA, BANCO DE DADOS

PRIORIDADE: [ ] E [ X] I [ ] D COMPLEXIDADE: []A []M [ X] B

2.4 RELACIONAMENTO ENTRE REQUISITOS E NECESSIDADES

REQUISITO N1 N2 N3 N4
RF01 X
RF02 X X
RF03 X
RF04 X
RF05 X
RF06 X X X X
RF07 X X
RF08 X
RNF01 X
RI01 X X X X
RI02 X
APÊNDICE B – Contratos Inteligentes

B.1 Fábrica de campanhas

contract CampaignFactory {
event LogCampaign(
address _campaign
);

function createEntitiesCampaign(address[] _entities,

uint _goal, uint _days) public
{
address newCampaign = new EntitiesCampaign(_entities,
_goal, _days, msg.sender);
emit LogCampaign(newCampaign);
}

function createPhasesCampaign(uint[] _goals, uint _days) public

{
address newCampaign = new PhasesCampaign(_goals,
_days, msg.sender);
emit LogCampaign(newCampaign);
}
}

B.2 Campanha com repasse a entidades pré-cadastradas

contract EntitiesCampaign {
address public manager;
uint public expiration;
uint public amountRaised;
uint public goal;
mapping(address => bool) public allowedEntities;
mapping(address => uint) private contributions;

36
modifier restricted() {
require(msg.sender == manager);
_;
}

constructor(address[] _entities, uint _goal,

uint _days, address _manager) public
{
require(_entities.length > 0);

for(uint i = 0; i < _entities.length; i++) {

allowedEntities[_entities[i]] = true;
}

goal = _goal;
manager = _manager;
expiration = block.timestamp + (_days * 1 days);
}

function donate() public payable {

require(block.timestamp < expiration);

contributions[msg.sender] += msg.value;
amountRaised += msg.value;
}

function transferTo(address entity, uint value)

public restricted
{
require(block.timestamp > expiration);
require(amountRaised >= goal);
require(address(this).balance >= value);
require(allowedEntities[entity]);

entity.transfer(value);
}

function reclaim() public {

require(block.timestamp > expiration);

37
 require(amountRaised < goal);
require(contributions[msg.sender] > 0);

// Padrão Checks-Effects-Interactions
uint share = contributions[msg.sender];
contributions[msg.sender] = 0;
msg.sender.transfer(share);
}

// [!] Função utilizada apenas para auxiliar

// na demonstração do funcionamento do contrato
function expire() public {
expiration = 0;
}
}

B.3 Campanha com repasse dividido em fases

contract PhasesCampaign {
address public manager;
uint public expiration;
uint public amountRaised;
uint public netGoal;
uint[] public goals;
uint public currentPhase;
PhaseChangeRequest[] public phaseChangeRequests;
uint private transferPhase;
uint private requestPhase;
mapping(address => uint) private contributions;

struct PhaseChangeRequest {
uint approvalStake;
mapping(address => bool) approvals;
}

modifier restricted() {
require(msg.sender == manager);
_;

38
}

constructor(uint[] _goals, uint _days,

address _manager) public
{
require(_goals.length > 0);

for(uint i = 0; i < _goals.length; i++) {

netGoal += _goals[i];
}

goals = _goals;
manager = _manager;
expiration = block.timestamp + (_days * 1 days);
}

function donate() public payable {

require(block.timestamp < expiration);

contributions[msg.sender] += msg.value;
amountRaised += msg.value;
}

function transfer() public restricted {

require(block.timestamp > expiration);
require(amountRaised >= netGoal);
require(transferPhase == currentPhase);

transferPhase += 1;
msg.sender.transfer(goals[currentPhase]);
}

function requestPhaseChange() public restricted {

require(block.timestamp > expiration);
require(amountRaised >= netGoal);
require(requestPhase == currentPhase);

PhaseChangeRequest memory newRequest = PhaseChangeRequest({

approvalStake: 0

39
 });

requestPhase += 1;
phaseChangeRequests.push(newRequest);
}

function approvePhaseChange() public {

PhaseChangeRequest storage request
= phaseChangeRequests[currentPhase];

require(block.timestamp > expiration);

require(!request.approvals[msg.sender]);

request.approvals[msg.sender] = true;
request.approvalStake += contributions[msg.sender];
}

function changePhase() public restricted {

PhaseChangeRequest storage request
= phaseChangeRequests[currentPhase];

require(block.timestamp > expiration);

require(request.approvalStake > (netGoal / 2));
require(currentPhase + 1 < goals.length);

currentPhase += 1;
}

function reclaim() public {

require(block.timestamp > expiration);
require(amountRaised < netGoal);
require(contributions[msg.sender] > 0);

// Padrão Checks-Effects-Interactions
uint share = contributions[msg.sender];
contributions[msg.sender] = 0;
msg.sender.transfer(share);
}

40
 // [!] Função utilizada apenas para auxiliar
// na demonstração do funcionamento do contrato
function expire() public {
expiration = 0;
}
}

41