Blockchain Engineering Class of 2020: Delft-DAO - Distributed Democracy

[synctext]

Delft-DAO

What is a DAO? Within the coming decade the future of jobs, employment and the nature of the firm will change profoundly. Automation, AI, and robots will replace many of today's jobs. A new type of company is a company without any employees, without any machines or physical infrastructure. A Decentralized Autonomous Organizations, DAO, only exists in software. It goes beyond smart contracts, it is a complete company inside software. DAO development is still in the experimental stage.

Within this course you can create your very own autonomous organisation, the Delft-DAO. Learn to engineer a decentralised autonomous organisation, use the existing tools, and understand the security risks. The aim is to alter the nature of the firm in the Internet age, see the Nobel prize winning theory. Production cost become essentially cost-free. An organisation which exists purely in cyberspace. The Delft-DAO is designed to be the first sustainable DAO. How can we empower leaderless organizations? How can it earn money from manipulating bits?

Several teams from the class will create running code (requirements for a passing grade..) for one of the following functionalities. Four teams together create the building blocks of the complete Delft-DAO (time consuming integration step is outside our scope).

Distributed Democracy Key component of a DAO is controlling the fully automated firm through a voting process. A DAO is fully autonomous and has the integrated ability to govern itself. Self-governance is difficult to realise. Anonymous owners of the DAO coordinate their action through a voting process. Collective decision making by the stakeholders is known as a hard problem. Electronic voting is known to be difficult security problem. This is a challenging part of DAO engineering. Mandatory starting point for your code is this Kotlin app

• Each DAO owner can propose what the firm will do next and spend its own money on
• vote on Delft-DAO investment proposals
• cryptographically guaranteed democracy
• collective decision problem is core (voting thesis from 2017 and issue).
• Proposed sprint breakdown
  • register identity
  • voting pass on Trustchain
  • collect votes
  • tally votes

[synctext]

@emieldesmidt @koningr @PraveshMoelchand @erwinvanthiel Welcome to the course! Sprint proposal divided on team of 4 students :

• get familiar with Trustchain concept read docs
• get familiar with existing app
• Real voting handling
  • background reading: https://blog.scottlogic.com/2018/03/13/leadership-election-with-apache-curator.html
  • general background2: https://arxiv.org/abs/1702.02566
  • some code: https://spectrum.ieee.org/tech-talk/computing/networks/ethereums-150-million-dollar-dao-opens-for-business-just-as-researchers-call-for-a-moratorium
  • fantasy idea? https://medium.com/moatcoin/an-experiment-fund-managing-protocol-powered-by-ethereum-blockchain-with-dao-implemented-9aae19b243fd
• read about creation of money
• Coding sprint 1:
  • assume for now: central node determines the voting group
  • everybody with the app can create a proposal to vote on (yes/no)
  • everybody invited to vote

Future sprint ideas:

• distribute voting pass?
• manage the "super_app" challenge (secure communication, media, money, market and passports)

[rwblokzijl]

Related:

• Vitalik, founder of Ethereum, has a talk about common pitfalls in decentralized governance, how to prevent oligarchies, and how to incentivise people from always voting for themselves. He had to solve this to make Proof of Stake work in Ethereum 2.0.
  • Kleros decentralised arbitration platform is a system that settles legal disputes through community voting.
• Augur decentralised prediction markets is a system that implements a prediction market on the blockchain. Prediction markets are a tool to have financial markets vote (bet) on future events in order to (hopefully) predict outcomes.
• Chainlink is a system that aims to get real world data (like stock prices, airplane cancelations, etc) onto the blockchain using a voting mechanism.

[emieldesmidt]

The APK from last sprint: demo-voting-android-debug.zip

[PraveshMoelchand]

Propose button in debug screen (1) and creating a proposal (2):

Proposal has been added to chain (1), can be voted on (2), and votes can be viewed in the chain (3):

[synctext]

Next sprint:

• Unit tests
• documentation
• Find working algorithm to implement from the literature?
• next step for secure voting: design??, document in README.md and implement.
  • can we do completely open and public voting without security issues?
  • replay attack
  • member hiding attack?
  • block hiding attack?
  • for security, everything is still ToDo :-)
  • @MattSkala idea us the Trustchain primitive anycounterparty?
• please do not start from scratch, just disable no needed stuff

[synctext]

related work (critical components are still MIA) https://vocdoni.io/docs/#/architecture/process-overview

[MattSkala]

For integrating work of all teams with the existing codebase, we have decided to take the super app approach. To separate IPv8 library from the app, we have moved demo-android app from kotlin-ipv8 to trustchain-superapp repository. Please create a module for your app and add a link to the dashboard according to the provided tutorial. When you feel ready (in the upcoming weeks), you can create a pull request with your contribution.

[synctext]

The team seems stuck, yet still determined

• 40% of the course is now integration with the other teams, see here
• Find some Scholar.google electronic voting algorithm for usage and inspiration
• search search for voting algorithm and cut-off date for voting
• thus stumbled upon fundamental hard problems: identity, time and security
• thus we will "cheat" and create a prototype with known weak security assumptions
  • single central proposer
  • use any_counterparty proposal block_type of Trustchain with your own custom validation function
  • prevent an explicit list of all voters, unknown if this is possible
  • everybody crawls and exchanges the votes (e.g. collaborates) and sees the outcome
  • somehow we prevent deletion of undesired result (vote hiding, ignore this attack is it's a showstopper, but document)
  • time and late voting is going to be hard
  • document election stalling attack in this issue
  • dealing with offline people it out of scope, above is already hard enough
• start exploring Bitcoin scripting for DAO voting
  • future sprints will use Trustchain, real Bitcoin and Delft-DAO
  • full list of voting members
  • known voting wallet in Bitcoin

[synctext]

smart idea from another group: if you can always pull out your Bitcoins, you mitigated the "Voting Quorum capture" attack. If people don't like the direction a DAO is going, it trigger something like a "bank run", a large-scale exit. Does an "always-exit" mechanism solve this attack for any permissionless DAO with true democratic voting (e.g. no special voting privileges)?

[emieldesmidt]

Markdown documentation keeping track of how to use our voting application, design choices that have been made, and ongoing questions: hackmd link

[synctext]

Sprint progress:

• use Hangouts to integrate with other teams
• tried to create a custom community (mocking and testing is not easy)
• if you can always exit with your money; no need to protect against evil Sybil attack
• solid progress!
• there is no such thing as an end-time or no vote
• we need an exit mechanism!
• Upcoming sprint:
  • integrate with MultiSig wallet
  • quorum voting code

[PraveshMoelchand]

UPDATE

• We have been working on the double voting defense and have implemented that a vote is only counted once.
• We updated the HackMD file
• We have been in contact with the currency group to merge our stuff with theirs, but figured out that they were not ready yet for merging. We were not aware that they had asked for a deadline extension. We are now specifying our functions so that the integration progress will run more smoothly

[PraveshMoelchand]

We have proposed first version of API to work with the currency group (translated from Dutch):

fun startVote(voteSubject: whatever, , voters: List<whatever>)
//  Proposer calls startVote() and sends all voters a proposal 
//  block with the subject of the vote in JSON.
//  Votesubject could also contain something else, as long as it is JSON-able.
//  Voters could also be a list of peers, as long as the public keys are retrievable.

fun respondToVote(voteSubject: whatever, signature: whatever, proposalBlock: TrustChainBlock)
//  Voters call respondToVote() to vote. VoteSubject is the name of the vote. 
//  Signature is the BTC signature as string or something else JSON-able.
//  Proposalblock is the block that is being responded on.

fun countVotes(voteSubject: whatever, proposerKey: ByteArray): List<whatever>
//  VoteSubject is the name of the vote. Proposerkey it the key of proposer, used
//  to crawl the chain to find the voting responds. Return type is a list of signatures.
//  Please give us instructions of how we could verify a signature for its validity, so we
//  can incorporate this when counting votes.

[synctext]

Sprint progress:

• [ ] be the pro-active drivers of integration with the two adjacent teams
• [X] first version of integration API with MutiSIG Bitcoin, next version coming
• [ ] Quality control: mocking and testing; but not easy
• [ ] two type of votes
  • [ ] vote on new member in the Delft-DAO (automatically approve if interity is OK)
  • [ ] vote on new code addition in superapp / Delft-DAO
• [ ] operational voting system
  • [ ] "cheat" and create a prototype with known weak security assumptions
  • [ ] Anybody can propose a vote on 1) magnet link to Bittorrent swarm with new Kotlin code 2) payout to their own wallet
  • [ ] use any_counterparty proposal block_type of Trustchain with your own custom validation function
  • [ ] transparent voting: we have a list of all public key participating and how they voted; visible in Bitcoin?
  • [ ] everybody crawls and exchanges the votes (e.g. collaborates) and sees the outcome
  • [ ] somehow we prevent deletion of undesired result (vote hiding, ignore this attack is it's a showstopper, but document)
  • [ ] Votes do not timeout, no end time; just meet the quorum
  • [X] dealing with offline people it out of scope, above is already hard enough

[emieldesmidt]

Last week was for all of us rather hectic, nevertheless we have made some solid progress both in terms of coordination as well as voting.

For the integration with the other groups:

• Organised a joined team call with the other teams to track progress and raise awareness (more on that later)
• Close contact with Bitcoin team, which highlighted some issues (One of us will briefly join the 11am meeting of their group)
• Encouraged other group (F.O.C) to improve their repository/git aproach (simple copy, not a fork). This likely saved them from future struggles with merging. Guided them how to do so as they were uncertain in how to do so.
• Created our own fork, prepared for first integration with main super app

For our own voting development:

• Any counterparty votingblock
• Moved to super app, created own module in the utils directory
• Removed reliability on voting community, make it passable as a list
• Refactoring of code
• Cleared path for mocking and testing

However, there were some issues that we have encountered:

• Bitcoin group was under the impression that they had to implement voting themselves, so they did.
• Realisation that a lot of effort that has been put into this project will not be put to use, mainly referring to the first few weeks were we focused on a more sophisticated solution.

We'll address these issues and our further progress during the meeting.

[synctext]

• goal of generic voting: quorum based, no endtime
• as-simple-as-possible with PR this Friday
• detailed commenting on the MultiSig voting part
• also checking the code of others, but not responsible for overall integration & testing
• Gap with end-to-end vote handling, vote actions; live code injection, magnet links, payout of reward
• Consider a deep dive into performance analysis. Hardcore engineering, Phone overloading and beautiful graph fabrication. How big do the Trustchain/MultiSig blocks be with the actual code? So you know the cost per vote and additionally cost per vote per capita. 1 million people is 1 GByte any_counterpart block?

[emieldesmidt]

Due to a fair share of stress from other deadlines/exams, last week amounted to a little less than hoped. Nevertheless a fair share of work has been done. Our voting has finally moved to the super-app, see the pr. We only wanted to do so once there was sufficient unit testing as there is no way to manually test an API without writing a dedicated application for it.

@erwinvanthiel took the time to check out some of the pr's from other groups.

There were some complications with the build. (Classic case of 'works on my machine'), obstructing @KoningR and @PraveshMoelchand from continuing to work on the threshold implementation. This has been discussed with @MattSkala and is currently trying to be fixed. The issue involves gradle modules, something where we are inexperienced with.

[synctext]

• [X] Basic GUI for creating a proposal for voting
• [ ] connect with SuperApp and new voting solution (Yes/No)
• [ ] Simple demonstration of your project:
  • visual final demo of voting within this project
  • everybody can propose a new project
  • suggest a budget and call for a vote
  • SuggestProject(ProjectDescriptionText, BitcoinBudget, VoteDeadlineTime)
  • record votes inside Trustchain blocks, but in Delft-DAO dedicated community (e.g. not main but Trustchain IPv8 community itself)
  • discovery of things to Yes/No vote on in GUI (main element even?)
  • non-binding, but good for future binding votes with real Bitcoins

[emieldesmidt]

Connected with super app, and created demo application that showcases our yes/no voting solution. As of right now it is a rudimentary state, but we expect to extend its functionality and style over the coming days.

It serves as a place where new vote proposals can be discovered, voted upon, and created.

[PraveshMoelchand]

Corresponding APK app-debug.zip

[synctext]

Sprint progress:

• which direction can yield impressive Tweakers.net features?
• main working branch
• Yes/No votes focus
• dynamic voting list, marked as voted
• Consider beyond text_blob voting
  • Magnet link voting?
  • transfer_bitcoin(Common_wealth,private_wallet)
  • This requires Quorum-voting!
  • insecure Yes/No vote
• documentation; use screenshots to explain what is going on.

[PraveshMoelchand]

Just created a PR for the initial GUI with yes/no voting. This ticks off the dynamic voting list bullet point.

Also, our main working branch is now the forked dao branch. When creating new functionalities, we create a new branch from here and merge them back into dao once finished.

Some screenshots of the GUI can already be seen in the PR.

[PraveshMoelchand]

We also fixed an exclusion that wasn't working in the ktlint of the kotlin-ipv8 repo, see the PR here

[emieldesmidt]

Summary of this weeks sprint progress as we are nearing the end of the project:

• Vastly improved usability and usefulness of our demo app. It displays significantly more info to the user, and is much more intuitive. The application is also dynamic (frequent polling), and new votes appear immediately at peers.
• Threshold implementation, see PR
• Significantly extended documentation both for the project as well as the project progression during the course (https://hackmd.io/d1R8DNISRhCbXzmkwXcebw) and PR
• Refactoring of error handling and exception catching.
• Discussion with FOC for potential integrations. From this discussion it came forward that doing this would be mostly for the sake of doing it. Idea for now is that someone proposes a file to upload, this will become a proposal, when vote is concluded this can be retrieved using an endpoint. @synctext had a meeting with FOC this morning where details are discussed further.

Some screenshots indicating all that's new.

Main screen:

### Clicking on a vote were you have already proposed upon: ### Toggle to only uncasted votes mode + cast dialog: ### Initiating vote with toggle between yesno/threshold:

[PraveshMoelchand]

voting-23-04-2020.zip

[synctext]

Last sprint comment:

• Documentation PR, see this example
  • contribute to the main DAO readme.MD with text + animated .GIF + pointer to full docs
  • Please also link to actual code you wrote
  • 20-line ish introduction. Why, what, how?
• Binary blob heroic effect (UDP overflow problem) @emieldesmidt
• Integration Freedom-of-Computing
• work branch https://github.com/emieldesmidt/trustchain-superapp/tree/dao/voting

[PraveshMoelchand]

For this final sprint, we decided to make use of the GitHub issue board

[PraveshMoelchand]

Final pull request created: https://github.com/Tribler/trustchain-superapp/pull/23 🎉

[emieldesmidt]

That was a lie, https://github.com/Tribler/trustchain-superapp/pull/25

[emieldesmidt]

So to conclude:

• Extensively used GitHub issues and a board to track final todo's (thanks @PraveshMoelchand)
• Progress report: report
• Documentation: common and trustchain-voter
  • FOC integration: see doc

We will use the app where the FOC integration proof of concept is present. Both this APK and the FOC APK can be found below!

[PraveshMoelchand]

APK for our final app: trustchain-voter.zip

APK for the FOC-integration proof of concept: foc-integration.zip

[synctext]

Fascinating final result feature; Freedom of Computing integration: https://github.com/Tribler/trustchain-superapp/blob/dao/trustchain-voter/README.md#experimental-freedom-of-computing-file-proposal