Dash Trust Protector election software has been released! A full voting system comprised of Vote Collector API, a front end website, and Vote Verification and Tally for gathering votes and electing Dash Trust Protectors. For more info:<\/p>\n
https:\/\/blog.dash.org\/trust-protector-election-software-93ed67c7455b<\/a><\/p>\n <\/p>\n Hi everyone,<\/p>\n I wanted announce the release of our Dash Trust Protector election software.<\/p>\n A couple months ago I was approached and tasked with building a voting system for gathering votes for the Dash Trust Protectors, which would then be audited by a third-party auditor (later determined to be the DashWatch team).<\/p>\n This is done, and I wanted to announce the release of this software, and delve a bit into why I made the decisions that I did which resulted in the tech stack being used.<\/p>\n For one, I had some constraints to take into consideration. Our developers on individual component teams are all busy with Evo work, and didn\u2019t have time to spare for this project without delaying progress on Evolution components (e.g Drive, DAPI, DashPay wallet). So, in order to prevent any delay in Evo delivery, I needed to do this myself, balancing my ability to deliver quickly without sacrificing quality.<\/p>\n It\u2019s a valid question, and I\u2019m glad someone might ask. This is actually different from the current budget system in that it\u2019s not a simply binary yes\/no, and the MN owners who currently delegate or e.g. share their voting keys with MN operators, may not want to delegate or share ability to vote for the Dash Trust Protectors.<\/p>\n Because of this difference and the importance of the Trust Protector position and to ensure that it is MN owners and not e.g. hosting providers or budget vote delegates, we determined that we needed to use the MN collateral key for signing and verifying messages.<\/p>\n With that in mind, let\u2019s dig in. The software consists of 3 pieces which are loosely coupled and working together.<\/p>\n 1. A backend API which talks to the database. This final piece is actually the responsibility of the 3rd-party auditor, and they are free to use my implementation or roll their own. It\u2019s open-source anyway, so nothing to hide.\u00a0\ud83d\ude09<\/p>\n I wanted to make sure that up front, there weren\u2019t a whole lot of restrictions or complicated logic which could lead to bugs in getting votes in the database. Once the vote is over, the votes can easily be filtered and invalid votes discarded, but it would be terrible to have valid MNO votes not show up due to some bug in validation logic.<\/p>\n I think that the natural tendency for most junior software engineers would be to build tight validation into every part of the application. Of course, the more checks that exist, the more potential for bugs, and the less \u201celegant\u201d, as I like to use the term.<\/p>\n It\u2019s also useful to remember that the valid masternode list is a moving target\u200a\u2014\u200ameaning, it changes as MNs join and leave. The only one that matters is on March 31st, when a single \u201csnapshot\u201d of the MN list will be taken for validation purposes.<\/p>\n Even if a vote is cast with an address that isn\u2019t currently an active MN (e.g. might be down for maintenance), as long as that MN collateral address is in the list as of March 31st when the snapshot is taken, the vote should be considered valid. This is also used to ensure that if MN owners were to attempt to \u201cgame\u201d the system by moving collateral around and re-casting votes, well, it wouldn\u2019t matter. Only MNs valid as of March 31st when the snapshot is taken will be considered.<\/p>\n So we need to be more open at first, and allow a little more than strictly necessary, and later we can tighten down when the tally is done. Disk space is cheap, and our software architected such that a little extra load shouldn\u2019t really be noticeable. Instead of a lot of extra logic and code clutter, I think that up-front it\u2019s better to be more elegant, and validate the data at the end, which is the real proof.<\/p>\n Remember, invalid votes can be rejected, but valid MNO votes which didn\u2019t get cast due to buggy software can\u2019t be recovered! So the software is built with a view to keeping the input \/ DB accepting, with very minimal validation up-front, and we enforce strong validation later.<\/p>\n With that in mind, let\u2019s discuss each piece in detail:<\/p>\n https:\/\/github.com\/dashevo\/vote-collector<\/a><\/p>\n We needed a database to store the results, and Postgres is one of the best open-source and SQL-compliant offerings. But I also needed a way to talk to it, and an HTTP API (REST or otherwise) is pretty standard.<\/p>\n I chose to use JSON and write my own routes instead of using REST because that didn\u2019t really serve my needs for the routes which exist. Due to the simplicity and speed (both in running and speed of development time), I chose to use Go for this.<\/p>\n Go is static typed, compiles to a single binary (like C\/C++), has a single code style for the language which is built-in (so no issues with linting or mucking about with syntax config files), has cross-compilation built in, and both compiles and runs very quickly. Since it compiles to a single binary, it doesn\u2019t require an interpreter or that Go is installed on the target machine. I\u2019ve heard it described it as \u201cC++ for the 21st century\u201d. And in my assessment, unlike some other tech fads, Go will be around for a while.<\/p>\n So I wrote our vote-collector API in Go. This is the single point of access for the Postgres DB, meaning that all reads & writes go thru the API. Configuration<\/a> is done via environment variables<\/a>, \u00e0 la 12-Factor app<\/a>.<\/p>\n By the way, if you aren\u2019t familiar with the 12-Factor software design methodology<\/a>, I\u2019d really recommend giving it a read. It\u2019s very short, and reinforces a lot of good software design principles.<\/p>\n As far as auditing the votes, this is also part of this API. I have created a JSON Web Token<\/a> for the auditors, which grants access to the routes which select votes from the database. The `\/allVotes` route is used for auditing and can be used by the 3rd-party auditors to verify that they are able to see any\/all votes, including ones they insert themselves. By doing so, and checking this periodically, they are able to verify that votes aren\u2019t being excluded from the system.<\/p>\n Another route is the `\/validVotes` route, which actually doesn\u2019t do validation, but lists the most recent vote per MN collateral address. This is what should be used for the vote tally at the end, as it doesn\u2019t display previous votes which are superceded by newer ones. An MN owner can cast a vote multiple times per address, but only the most recent will count.<\/p>\n I\u2019ve used our AWS account to deploy this infrastructure.<\/p>\n The vote-collector deployment is 3 of these processes running behind a single load balancer and using an auto-scaling group to ensure there are always 3 running, which gives plenty of resilience even if the load is heavy.<\/p>\n Next, let\u2019s move to the frontend site:<\/p>\n https:\/\/github.com\/dashevo\/trust-vote-site<\/a><\/p>\n We needed a way for MNOs to cast votes, and also<\/em> needed a way to automate the vote verification and tallying of them. Otherwise, manual work could take many hours or more, and lots of cut-and-pasting for verifying signatures. This isn\u2019t necessary with modern technology, so I devised a way to count votes in an automated fashion.<\/p>\n To do this, we needed 3 things:<\/p>\n * A message with a custom structure which can later be parsed by the tally mechanism This will also ensure that the format is correct.<\/p>\n The format is actually a string with a prefix and pipe-delimited list of candidate identifiers (which are a candidate\u2019s first initial and last name). This identifier is used internally to keep the message short\/legible and reduce chance of error by removing things like spaces from the string.<\/p>\n As long as MN owners use this tool in the expected way, their votes should be recorded and in the correct format.<\/p>\n This is a static site which is generated and uploaded to Amazon S3, and deployed via Amazon CloudFront, meaning it should be available globally with next to zero lag (and we have zero servers to maintain or worry about getting hacked).<\/p>\n This describe the existing two pieces of deployed infrastructure, but let\u2019s examine the final bit which does the verification and tallying after the election.<\/p>\n https:\/\/github.com\/dashevo\/vote-tally<\/a><\/p>\n I probably would have chosen Go for this also, if there were some existing Dash \/ Bitcoin libraries for signing and validating string messages. But I didn\u2019t have time to delve into adding or porting this, along with all the other pieces. Fortunately, this was simple to do in Node.js using only dashcore-lib as the only dependency.<\/p>\n This is technically the responsibility of the 3rd-party auditor to run, but I wanted to make sure everyone knew how the tally was intended to work, and ensure that no invalid assumptions were made about the vote data (e.g. that anything had already been verified).<\/p>\n This expects a JSON list of votes as returned by the `\/validVotes` route, and a valid masternode snapshot as return by the dash-cli command `masternodelist json ENABLED` on March 31st.<\/p>\n Once these 2 files are added (see the README for specific locations), the software verifies each vote entry, ensuring that:<\/p>\n * a MN collateral can only vote once * the MN collateral address must be a valid Dash address If a vote breaks ANY of these conditions, the entire vote is nullified (with the exception of the first, which stops the program entirely as the entire dataset is considered invalid).<\/p>\n So that\u2019s the run-down of all the pieces of software for the Trust Protector vote, how they work together, and a little of why I made the technical and architectural decisions that I did, given my constraints. I hope this has been informational and helpful, and I\u2019m happy to answer any questions anyone may have.<\/p>\n If anyone is interested I\u2019d also recommend looking at the README.md for each specific piece, which has basic documentation, including configuration.<\/p>\n Oh, one quick note: Apparently there is some confusion in the Dash community about whether or not software located at https:\/\/github.com\/dashevo<\/a> is ours\u200a\u2014\u200ait is. It\u2019s actually pretty common for larger organizations to have multiple GitHub organizations, and there are some good reasons for this. But I will discuss this in more detail next week when I write about our open-sourcing efforts. Stay tuned!\u00a0\ud83d\ude42<\/p>\n And please let me know if you have any questions.<\/p>\n Cheers, P.S.<\/p>\n\u201cWhy not use the existing budget\u00a0system?\u201d<\/h3>\n
High-Level Architecture<\/h3>\n
\n2. A frontend website which talks to the MNOs and the API.
\n3. A vote validation and tallying tool which validates (or rejects) votes and tallies them, to be used once the vote period ends on March 31st.<\/p>\n1. Vote Collector\u00a0: backend JSON API written in\u00a0Go<\/h3>\n
2. Dash Trust Election Vote site\u00a0: frontend Static javascript website using\u00a0React<\/h3>\n
\n* The MN collateral address (to prove that the signed message belongs to this address, and to later verify that this address exists in the list of masternode addresses)
\n* The signature, which must be done externally and pasted in<\/p>\n3. Vote Verification and Tally\u00a0: Node.js tool to verify vote validity and tally valid\u00a0votes<\/h3>\n
\n\u2014\u200aif this condition is not met, the program exits w\/an \u201cinvalid dataset\u201d message. It is expected that the correct data is generated from the API via the `\/validVotes` route to prefix this from ever happening.<\/p>\n
\n* the MN collateral address must exist in the valid MN list
\n* the given signature is valid for the message + address
\n* the vote message matches the aforementioned format required for parsing (including message prefix)
\n* a candidate can only be listed once per MN collateral vote
\n* ONLY candidates in the valid candidate list as provided by DashWatch are valid<\/p>\nSummary<\/h3>\n
\nNathan<\/p>\n