Escreva Contratos Inteligente em Cadence Para Votações

Hoje nós vamos ver como é fácil programar seu primeiro smart contract em Cadence de votação, ele sem dúvidas é o verdadeiro mestre das eleições!

Ele permite que os participantes votem em uma das propostas disponíveis e armazena as contagens de votos para cada uma das propostas.

Ele possui três recursos principais:

MaioriaGanha,

Voto e

Administrar.

Com esses recursos, o smart contract em Cadence é capaz de realizar eleições de forma eficiente e segura.

O recurso MaioriaGanha é o contrato principal e define as variáveis propostas e votos, bem como as funções processar e init.

A variável propostas é uma lista de strings que armazena as propostas disponíveis para votação, enquanto a variável votos é um dicionário que armazena a contagem de votos para cada uma das propostas.

A função processar é usada para processar um voto quando um participante decide finalizá-lo, enquanto a função init é chamada quando o contrato é criado e inicializa as variáveis propostas e votos com valores vazios e salva uma instância do recurso Administrar na storage do contrato.

O recurso Voto é usado para permitir que os participantes votem em uma das propostas e armazenar suas escolhas em uma variável escolha.

Quando uma nova instância do recurso Voto é criada, a função init é chamada para inicializar a variável escolha com um dicionário vazio e preencher o dicionário com as propostas disponíveis. O participante pode chamar a função vote para votar em uma das propostas, passando o índice da proposta como argumento.

O recurso Administrar permite que o administrador inicialize as propostas e crie novas instâncias do recurso Voto. A função inicializePropostas é usada para atribuir a lista de propostas fornecida à variável propostas do contrato principal e inicializar a variável votos com um dicionário vazio, com chaves correspondentes a cada uma das propostas.

A função emitirVoto é usada para criar uma nova instância do recurso Voto e retorná-la.

Espero que isso tenha ajudado a esclarecer o que o seu smart contract está fazendo de forma mais detalhada e descontraída. Se você tiver mais perguntas ou precisar de mais assistência, não hesite em perguntar.
pub contract MaioriaGanha {
    pub var propostas: [String]
    pub let votos: {Int: Int}

    pub resource Voto {
        pub let propostas: [String]
        pub var escolha: {Int: Bool}

        init() {
            self.propostas = MaioriaGanha.propostas
            self.escolha = {}
            var i = 0
            while i < self.propostas.length {
                self.escolha[i] = false
                i = i + 1
            }
        }
        pub fun vote(propostas: Int) {
            pre {
                propostas >= 0
                propostas < self.propostas.length
            }
            self.escolha[propostas] = true
        }
    }

    pub resource Administrar {
        pub fun inicializePropostas(_ propostas: [String]) {
            pre {
                MaioriaGanha.propostas.length == 0
                propostas.length > 0
            }
            MaioriaGanha.propostas = propostas

            var i = 0
            while i < propostas.length {
                MaioriaGanha.votos[i] = 0
                i = i + 1
            }
        }

        pub fun emitirVoto(): @Voto {
            return <-create Voto()
        }
    }

    pub fun processar(voto: @Voto) {
        var index = 0
        while index < self.propostas.length {
            if voto.escolha[index]! {
                self.votos[index] = self.votos[index]! + 1
            }
            index = index + 1;
        }
        destroy voto
    }
    init() {
        self.propostas = []
        self.votos = {}

        self.account.save<@Administrar>(<-create Administrar(), to: /storage/CalcularVotos)
    }
}
Parece que o seu código em Cadence é uma transação que permite ao administrador inicializar uma lista de propostas para eventos. Quando a transação é executada, ela solicita ao administrador que forneça suas credenciais de autenticação e, em seguida, usa essas credenciais para obter uma referência para o recurso Administrar do contrato MaioriaGanha.

Em seguida, a função inicializePropostas é chamada no recurso Administrar, passando uma lista de três cidades como argumento: Rio de Janeiro, São Paulo e Floripa.

Essa função atribui a lista de propostas fornecida à variável propostas do contrato principal e inicializa a variável votos com um dicionário vazio, com chaves correspondentes a cada uma das propostas.

Por fim, a transação exibe uma mensagem de log informando que as sugestões de locais para eventos foram publicadas.
import MaioriaGanha from 0x01

transaction {
    prepare(admin: AuthAccount) {

        let adminRef = admin.borrow<&MaioriaGanha.Administrar>(from: /storage/CalcularVotos)!

        adminRef.inicializePropostas(
            ["Rio de Janeiro", "Sao Paulo","Floripa" ]
        )

        log("Sugestoes de Locais para Eventos Publicada!")
    }
}
Agora veremos um contrato de uma transação que permite a um eleitor emitir um voto em uma das propostas disponíveis em um contrato MaioriaGanha
. Quando a transação é executada, ela solicita ao administrador e ao eleitor que forneçam suas credenciais de autenticação.

Em seguida, a transação obtém uma referência para o recurso Administrar do contrato MaioriaGanha e chama a função emitirVoto nesse recurso. A função emitirVoto cria uma nova instância do recurso Voto e retorna uma referência para ela.

Em seguida, a transação salva a instância do recurso Voto na storage do eleitor e exibe uma mensagem de log informando que o acesso foi concedido.
import MaioriaGanha from 0x01

transaction {
    prepare(admin: AuthAccount, eleitor: AuthAccount) {

        let adminRef = admin.borrow<&MaioriaGanha.Administrar>(from: /storage/CalcularVotos)!

        let voto <- adminRef.emitirVoto()

        eleitor.save<@MaioriaGanha.Voto>(<-voto, to: /storage/Voto)

        log("Acesso Concedido")
    }
}
Agora uma transação que permite a um eleitor emitir um voto em uma das propostas disponíveis em um contrato MaioriaGanha. Quando a transação é executada, ela solicita ao eleitor que forneça suas credenciais de autenticação e, em seguida, tenta carregar uma instância do recurso Voto da storage do eleitor.

Se uma instância do recurso Voto for encontrada na storage do eleitor, a transação chama a função vote nessa instância, passando o valor 0 como argumento. Isso marca a primeira proposta da lista como a escolha do eleitor.

Em seguida, a transação chama a função processar do contrato MaioriaGanha, passando a instância do recurso Voto como argumento. Isso adiciona o voto do eleitor à contagem de votos para a primeira proposta.

Por fim, a transação exibe uma mensagem de log informando que o voto foi computado.
import MaioriaGanha from 0x01

transaction {
    prepare(eleitor: AuthAccount) {

        let voto <- eleitor.load<@MaioriaGanha.Voto>(from: /storage/Voto)!

        voto.vote(propostas: 0)

        MaioriaGanha.processar(voto: <-voto)

        log("Voto computado")
    }
}
Por fim, no script template.

Quando a função é chamada, ela exibe os valores da primeira, segunda e terceira propostas na lista de propostas, seguidos dos respectivos valores de votos.

A função usa os índices 0, 1 e 2 para acessar os elementos da lista de propostas e do dicionário de votos, respectivamente. Isso significa que ela exibirá a primeira proposta da lista, seguida do número de votos para essa proposta, depois a segunda proposta da lista e o número de votos para ela, e assim por diante.
import MaioriaGanha from 0x01

pub fun main() {
    log(MaioriaGanha.propostas[0])
    log(MaioriaGanha.votos[0])

    log(MaioriaGanha.propostas[1])
    log(MaioriaGanha.votos[1])

    log(MaioriaGanha.propostas[2])
    log(MaioriaGanha.votos[2])
}
Try out this Playground project

O smart contract em Cadence é um código que é executado em uma rede blockchain, que é uma tecnologia de banco de dados descentralizada. Ele é utilizado para realizar eleições de forma segura e eficiente, permitindo que os participantes votem em uma das propostas disponíveis e armazenando as contagens de votos para cada uma das propostas. O smart contract possui três recursos principais: MaioriaGanha, Voto e Administrar. O recurso MaioriaGanha é o contrato principal e define as variáveis propostas e votos, bem como as funções processar e init. O recurso Voto permite que os participantes votem em uma das propostas e armazenem suas escolhas em uma variável escolha. O recurso Administrar permite que o administrador inicialize as propostas e crie novas instâncias do recurso Voto.

Como construir um Dapp para cunhagem de NFT na Flow

Para configurar uma conta no blockchain Flow, é necessário gerar um par de chaves públicas e privadas. Isso pode ser feito usando o comando "generateKeys" da biblioteca "flow-js" ou através de outra ferramenta de geração de chaves. As chaves públicas e privadas são usadas para assinar transações no blockchain Flow e garantir a segurança da conta. Depois de gerar as chaves, é preciso criar uma conta no blockchain Flow usando as chaves e seguir as instruções fornecidas pela plataforma para configurar a conta. Depois de configurar a conta, você poderá implantar seu contrato inteligente no blockchain Flow.

Como a programação orientada a recursos funciona?

Entre as opções que EVM ou WASM e são um ajuste perfeito para ativos digitais.

A rotulagem de algo como um “recurso” informa ao ambiente de programação que essa estrutura de dados representa algo de valor tangível e que todo código que interage com essa estrutura de dados precisa seguir uma série de regras especiais que manterão o valor dessa estrutura de dados.

Então, quais são essas regras?

1.  **Cada recurso existe exatamente em um lugar a qualquer momento.**

Os recursos não podem ser duplicados ou excluídos acidentalmente, por erro de programação ou código malicioso.

2.  **A propriedade de um recurso é definida por onde ele é armazenado.**

Não há razão central que precise ser consultada para determinar a propriedade.

3.  **O acesso aos métodos em um recurso é limitado ao proprietário.**

Por exemplo, apenas o proprietário de um CryptoKitty pode iniciar uma operação de criação que levará ao nascimento de um novo Kitty.

Não basta que o status especial dos objetos Resource seja aplicado apenas pelo compilador.

As regras devem ser aplicadas enquanto o código estiver realmente sendo executado na blockchain, seria muito fácil para um invasor usar uma cópia comprometida do compilador que ignora as regras que mantêm os recursos seguros.

Contudo! Se você aplicar essas regras corretamente, poderá permitir que o ativo mais importante da rede do token nativo seja armazenado com segurança dentro de estruturas de dados controladas por código enviado pelo usuário.

# **Mostre-me um exemplo!**

A maneira mais fácil de pensar sobre Recursos é pensar em um exemplo usando um Token Não Fungível (NFT), como um CryptoKitty.

Cada CryptoKitty é indivisível, não copiável e pode ter um único proprietário direto, que corresponde diretamente à construção de programação de Recursos.

Em um modelo de Ledger como o Ethereum, todos os CryptoKitties são armazenados em um único contrato inteligente como uma lista gigante. A propriedade de cada Kitty é rastreada armazenando o ID da conta de cada proprietário em um livro central, e a única maneira de alterar a propriedade de uma Kitty é entrar em contato com o livro central e solicitar que ele atualize o ID da conta associado a essa Kitty.

`contract KittyLedger {     struct Kitty {}     priv let kitties: {Int: Kitty}     fun transfer(kittyId: Int, newOwner: AccountId) {         if (msg.sender == kitties[kittyId].owner) {             kitties[kittyId].owner = newOwner         }     } } transaction(signer: Account) {     // diz ao razão central para atribuir a propriedade de     // myKittyId para uma conta diferente centralKittyLedger.transfer(myKittyId, receiverAccountId) }`

No Modelo de Recursos, o próprio Kitty é representado como um objeto de Recursos e é armazenado \*diretamente na conta que a possui.

\*Assim como no mundo físico, a propriedade é representada pela posse. Você não precisa procurar em um livro central para ver se possui algo, ou o armazena em sua conta ou não.

E se você tiver, pode transferi-lo ou controlá-lo de outra forma, e se você *não* tem, não há como capturá-lo ou alterá-lo.

`contract CryptoKitties {     //As contas armazenam uma coleção em seu recurso de armazenamento de conta KittyCollection {         // Cada coleção tem funções para //mover recursos armazenados para dentro e para fora         fun withdraw(kittyId: int): CryptoKitty         fun deposit(kitty: CryptoKitty)     }     //Os objetos de recurso que podem ser armazenados no recurso de coleção CryptoKitty {} } transaction(signer: Account) {     //Remove o Kitty da coleção do signatário e o armazena     // temporariamente na pilha.      let theKitty <- signer.kittyCollection.withdraw(kittyId: myKittyId)     // Move o Kitty para a conta do destinatário     let receiver = getAccount(receiverAccountId)     receiver.kittyCollection.deposit(kitty: <-theKitty) }`

*Nota: para manter o foco nas diferenças entre os modelos de contabilidade e propriedade direta, os dois exemplos acima ignoram questões como controle de acesso, definindo todas as variáveis, e outros fatores com os quais o código ativo precisaria se preocupar.*

# **Por que os recursos importam**

Além da vitória óbvia de incluir abstrações para gerenciar a propriedade, existem vários outros benefícios secundários decorrentes do uso de Recursos, cada um dos quais bastante significativo por si só:

# **Aluguel de Estado**

As plataformas escaláveis de contratos inteligentes precisam de alguma maneira de cobrar “ aluguel de estado ” para que os dados armazenados no blockchain sejam pagos ou removidos do conjunto de trabalho.

Com o modelo de contabilidade, é difícil saber quem deve pagar esse aluguel. Por exemplo, o contrato CryptoKitties representa dezenas de milhares de jogadores com quase dois milhões de Kitties e mais de 111MB de dados na blockchain.

A Ethereum não fornece nenhuma maneira de cobrar aluguel de maneira justa a todos os proprietários da Kitty.

Usando um modelo de propriedade direta via Tipos de Recursos, cada Kitty seria armazenada dentro da conta de seu proprietário, juntamente com os outros ativos dessa pessoa.

A responsabilidade de quem precisa pagar por esse armazenamento é clara.

Além disso, usuários individuais (assistidos pelo software cliente) podem arquivar ativos não utilizados para reduzir seus custos e reduzir a carga na rede.

# **Propriedade flexível**

O uso de um modelo de contabilidade para propriedade limita os tipos de relacionamentos com proprietários disponíveis.

Por exemplo, o ERC-721 define um modelo de propriedade para NFTs que pressupõe que apenas endereços Ethereum podem possuir uma NFT.

No entanto, a ideia de um ativo em si possuir outros ativos (como um CryptoKitty que possui um par bacana de óculos de sol ) é muito interessante em alguns casos de uso, e exigiu a criação de uma nova especificação (ERC-998).

O ERC-998 é muito poderoso, mas também é muito mais complicado que o ERC-721. Implementá-lo adequadamente é muito difícil e aplicar retroativamente seus recursos aos ativos existentes do ERC-721 é efetivamente impossível.

O modelo de propriedade direta permite que qualquer ativo modelado usando Tipos de Recursos seja armazenado com segurança em qualquer lugar do sistema, incluindo “dentro” de outros ativos, quando apropriado.

Todas as garantias de segurança e valor podem ser mantidas pelo sistema de tempo de execução, enquanto desbloqueia a flexibilidade criativa para desenvolvedores sem complexidade indevida.

# **Segurança baseada em capacidade**

Os tipos de recursos fornecem todas as garantias necessárias para implementar o conceito de “Capacidades” do [Segurança baseada em capacidade](https://en.wikipedia.org/wiki/Capability-based_security) modelo. Os recursos são um mecanismo poderoso para definir sistemas seguros e podem facilitar a adesão ao [Princípio do Menos Privilégio](https://en.wikipedia.org/wiki/Principle_of_least_privilege) (uma prática recomendada comum em sistemas de segurança).

Os modelos de segurança baseados em capacidade são geralmente considerados muito mais fáceis de raciocinar sobre, (o que aumenta a segurança), permitindo maior flexibilidade.

# **Eliminando erros de reentrada**

[O bug de contrato inteligente mais famoso da história da Ethereum](https://www.wired.com/2016/06/50-million-hack-just-showed-dao-human/) foi devido a um problema de reentrada, e os desenvolvedores de solidity precisa estar constantemente vigilantes contra a introdução de fluxo lógico suscetível a ataques de reentrada.

Felizmente, os métodos definidos nos recursos dos objetos não podem ser vítimas de nenhuma exploração de reentrada.

Parece uma afirmação ousada! No entanto, segue naturalmente como os Recursos são definidos: cada Recurso tem um único proprietário e somente o proprietário de um Recurso pode chamar os métodos nele.

Se um método de recurso estiver “na pilha”, sabemos que a referência de propriedade única a esse objeto já está em uso simplesmente não é possível que qualquer código que chamamos de dentro desse método, no entanto indiretamente, obtenha uma segunda referência a esse objeto para fazer uma chamada de método reentrante.

Obviamente, trabalhar diretamente com o estado compartilhado global (ignorando o uso de objetos de Recursos) ainda pode criar um código vulnerável a erros de reentrada.

É por isso que o estilo idiomático de cadência é usar Recursos para todo o estado compartilhado autores de contratos inteligentes que adotam Recursos nunca precisam pensar em bugs de reentrada novamente!

# **Mais sobre recursos**

Para aprofundar os recursos e a programação orientada a recursos, você pode:

*   Leia o [Mover papel técnico](https://developers.libra.org/docs/assets/papers/libra-move-a-language-with-programmable-resources/2019-09-26.pdf)[documentos do desenvolvedor](https://developers.libra.org/docs/move-overview) e

*   Leia o [Documentos do desenvolvedor de Flow](https://docs.onflow.org/docs)[Introdução à Cadence](https://docs.onflow.org/docs/introduction)

*   Aprenda a linguagem de programação Cadence em [Flow Playground](https://www.onflow.org/play)


Como a programação orientada a recursos funciona? 

O diagrama abaixo descreve os componentes de um dapp típico construído na blockchain Flow. Embora muitos dapps sejam estruturados de maneira diferente, essa arquitetura apresenta conceitos fundamentais que serão discutidos ao longo deste guia.

**Cliente Dapp**
O cliente dapp é a interface através da qual os usuários interagem com seu dapp. Aplicativos da Web e móveis são exemplos comuns de clientes dapp.

**Contrato Inteligente**
Um contrato inteligente é uma coleção de código, implantado em um local permanente na blockchain, que define a lógica central de um dapp.

**Conta de usuário**
Uma conta de usuário é um registro na blockchain que armazena os ativos digitais pertencentes a um único usuário.

**Transação**
Uma transação é um pedaço de código submetido ao blockchain que altera o estado de uma ou mais contas de usuário e contratos inteligentes. Todas as transações são originadas de pelo menos uma conta de usuário. Na maioria dos casos, uma transação passa dados entre uma conta de usuário e um contrato inteligente.

**consulta de estado**
Uma consulta de estado é uma solicitação feita ao blockchain que retorna informações sobre o estado dos contratos inteligentes do seu dapp.

**Carteira do usuário**
Uma carteira de usuário é um software ou hardware que controla o acesso à conta de um usuário na blockchain. O aplicativo cliente normalmente se conecta à carteira do usuário para enviar transações para a blockchain. Em muitos casos, o dapp transmite fisicamente a transação para o blockchain em nome do usuário. No entanto, é importante observar que a carteira tem a palavra final sobre o que é assinado ou não e, portanto, tem controle sobre todas as transações que interagem com a conta do usuário.

**Biblioteca de cliente Flow(FCL)**
A Flow Client Library é uma estrutura que fornece uma interface padrão para conectar aplicativos clientes e carteiras de usuários.
