Global variables and voting dapp

AlgoSDK
,
1

Hi everyone,

So, I’m trying to create a decentralized voting application. I’m thinking maybe for a start I should create a “poll dapp”. Are you aware of any project that is currently doing this? I’m still conceptualizing and trying to understand Algorand’s architecture though. So, with that said:

  1. What types of global variables are available for smart contracts? Can they store an array of strings for example? Integers? Or they store addresses only?

I’m guessing any time of data can be stored as long as its “limited to 64 bytes of storage each for both global and local storage”. Also from further reading; " The goal CLI supports passing strings, ints, base64 encoded data, and addresses as parameters".

This I think answers my question but further comments would be appreciated.

  1. Also, how can one change their values? Can it be done through sdk functions interacting with the smart contract (calling through some sdk method/function passing some value into the sc) or to change their value it has to be done through the smart contract code itself?

“Arguments can be passed to any of the supported application transaction calls, including create. The number and type can also be different for any subsequent calls to the stateful smart contract. The goal CLI supports passing strings, ints, base64 encoded data, and addresses as parameters. To pass a parameter supply the --app-arg option to the call and supply the value according to the format…”

So, again I’m guessing, we’ve got the sc running with its own ID on the bc and through a dapp implementing Algorand’s SDK we’d make a call and send the information. My question now is how would this information be validated before being updated to the global / local variable? Is it up to the programmer to decide how the sc validates calls?

If this question wasn’t clear enough please do say I’ll try to clarify.

  1. “To continue with the voting application, the smart contract can be combined with a voting token implemented as an Algorand ASA to create a permissioned voting application. When used in this fashion, a voter would spend a voting token at the same time they submit their vote to the stateful smart contract. These two transactions would be grouped using Algorand’s Atomic Transfers to guarantee both happen at the same time. A centralized source would be responsible for giving out the voting tokens. This is just one example of combining several technologies with stateful smart contracts.”

So, your suggestion is to have some form of centralized entity that will be responsible for handling “voting tokens” as assets.
Then the role of the sc will function as a trusted third party process that makes sure each token that is stored on the blockchain is of legit origin or that it was cast according a specific set of rules? Or otherwise is there another role for the sc in this context?

  1. When it is said in the text “centralized” does it really mean “permissioned”? Because afaik even permissioned bc are decentralized to a large degree (even if not as much as permissionless).

Thank you in advance.

2

We have a solution coming out in the next week that illustrates building a permissioned voting application on Alogrand. It shows how the smart contract could be built and a description of each step. It should be on the developer portal under solutions by the end of the week. We are also working on showing a non-permssioned voting application that we will upload as well. We are also going to publish a crowd funding example as well.

1 - You can write bytes slices or ints to global state
https://developer.algorand.org/docs/features/asc1/stateful/#write-to-state

2 - You call the smart contract with transactions, which can be created with goal or the SDKs. We are working on documentation for the SDKs now. The smart contract makes the change to the state variables. And if the smart contract call fails the changes will not take effect. The smart contract logic determines how and when state variables are changed.

3 - So you can create a voting app either as permissioned or permissionless. Permissionless may allow someone to generate several accounts and vote once for each account. One way to get around that is to have some central authority give out vote tokens. This allows the vote to play out on the blockchain but restrict who can vote.

4 - The central authority could be a government entity, or a specific application, or any group that wants to offer voting. The example we are putting on the dev site does not build the central authority part of the application.

1 Like
3

Thank you for your quick reply. It helped but it’s still not 100% clear to me how certain things will play out. I’ll wait to see and study the proposed solution before coming back with more questions.