search

juliusbenson / republickey

blockchain-based voting system
GNU General Public License v3.0
4 stars 3 forks source link

Nothing exists #1

Open juliusbenson opened 8 years ago

juliusbenson commented 8 years ago

Let's have a conversation about how to build this software

juliusbenson commented 8 years ago

Code we need to write: -an html landing page, probably that contains the javascript code to make blockchain requests -php code to request the database for the master hash, the database then gives us a URL for the file corresponding to that hash. -solidity for the voting contract --This code exposes 4 functions: "get master hash", "commit vote", "add voter", and "remove voter" --This code keeps track of 2 things: "master hash", and a key-value pair list of voter public keys and the "new master hash" each of them has voted for. --This code has some logic that, at the end of every voting period, it counts all the votes, and the "new master hash" that has the most voters behind it, becomes the new "master hash"

Research we need to do: -how in the world do we even code php in the first place? -look into the api for the ethereum js library and figure out how to make requests to and get data from the blockchain -How do we set up a database on EC2? Where/how are we storing the files?

juliusbenson commented 8 years ago

Ok, so Max and I met up today briefly and laid out a vague timeline with tasks for each file.

Timeline

  1. Deploy the first-draft solidity contract and get it talking to Mist, the Ethereum wallet. Time: 4 wks? 1a. Of the 5 functions we'll eventually put into the contract, we'll start with the most basic 3: get(), set(..), and recount(). We'll just hard-code in the registered voters for now every time we deploy a contract, so add(..) and delete(..) aren't neccessary for the moment. 1b. TESTING! Let's figure out how to write/perform test cases on contracts!
  2. Write up the html/js page that uses web3 and Mist to call our contract on the blockchain. Time: 1wk? 2a. We'll need to learn the Ethereum web3 api and give the js an index.html or something. For the moment we'll hold off on hosting these files on a server, and we can just test things out hosting them on my laptop's localhost WAMP server. 2b. TESTING! Who knows how to write test cases for javascript? Not me! Lets figure this out too, there might even be some coverage testing software for this
  3. PHP and SQL server. Time: 3-4 wks? 3a. Like the html/js, we'll just host the sql server (probably actually a MySQL server, to be precise) on my laptop at first, again, using my WAMP stack. This part involves defining the whole table schema and whatnot. The PHP needs to query the database based on the hash we get from the contract on the blockchain, and give us back either: a location for the incumbent proposal file, OR the body of the incumbent proposal itself (I might actually prefer this, for reasons mentioned later) 3b. I know as much about testing PHP as I do about PHP itself. Let's get that sorted out.
  4. Actually display the Incumbent Proposal to the end user. Time: 1-2wks? 4a. Once we get the location or body of the incumbent proposal back from the database, we actually have to show that file to the user. In the case of a file location, this would mean a redirect or an iframe or something (right? maybe not, there might be another way to do it). In the case of the body itself, we'll just insert the proposal body into a <div>. 4b. We need to VERIFY the page that comes back to the user, in case the SQL database gets hacked. The javascript should have a subroutine that hashes the body of the proposal to make sure it matches with the hast we got back from the contract. This is actually why I prefer just storing the whole body of the proposal in the database, because I think it would probably be easier to hash the proposal body if we actually got the proposal body back from the database, as opposed to just blindly redirecting to wherever the database tells us to. 4c. Testing! This is just more javascript testing.

NOTE: I didn't really include testing in my approximation of the timeline dates

Ok, cool. So, who wants to work on what? I've sort of been playing around a bit with MySQL and WAMP to familiarize myself with PHP, so I'd be down to grab that task if nobody else wants it.

supermaxio commented 8 years ago

That's great Julius! I've been thinking and in my opinion I think if we followed our implementation/verification model at work, we could have:

  1. SQL/PHP/WAMP implementer: JSB verifier: RKJ
  2. MIST/SOLIDITY implementer: MJM verifier: JSB
  3. JAVASCRIPT/HTML implementer: RKJ verifier: MJM

we can always work together on stuff too! Verifier role will be big because of test cases. -Max