The Collaborative Ideation of Novel Mechanisms Through the Engineering Design Process
In this post, we’ll continue the conversation on Neural Quorum Governance that was initiated in Introducing Neural Quorum Governance. This is the second of a three-part series of publications on the collaboration between BlockScience and Stellar Development Foundation (SDF). The third post will be about the Governance Modules Library for smart contract platform Soroban, a curation of both new and classic modules for governance in decentralized applications and decentralized autonomous organizations (DAOs). Its stated goal is to spread best practices and innovation, as well as to accelerate the adoption of Soroban as an ecosystem.
Specifically, we’ll describe the ideation, design, and implementation journey that led to the development of Neural Quorum Governance. Here we outline and describe the steps we went through in the engineering lifecycle.
Outlining the Engineering Design Process
At BlockScience, we adhere to a process called the “Engineering Design Process”. This allows for a clear separation of focus for each phase, generally starting with Phase 0 where work is scoped and agreed on, Phase 1 for ideation and requirements gathering, followed by Phase 2 for System Design, where specifications are written, and finalized in Phase 3 with System Validation, where we test and simulate mechanisms and systems to make sure they are safe for implementation. This process is exemplified by Fig. [EDP] and is described in Block by Block: Managing Complexity with Model-Based Systems Engineering.
1) Kick-off and Ideation
For the Ideation Phase, the adopted methodology was to perform five collaborative workshops with the SDF team that were 1h30m in duration each. Each workshop had predefined topics where the BlockScience team prepared material for inspiration, including literature reviews, systematization of properties, implementation examples, and so on. The workshop format took the shape of semi-structured interviews, with a set of questions, both general and specific, and both teams discussed and brainstormed freely to share knowledge. The topics being covered included 1) Discovering the Innovation Scope, 2) Component Brainstorming, 3) Component Pruning, and 4) Plugging Components and Agreeing on the Subsystem to be specified.
Generally, our focus in the early phase of a collaboration lies squarely on understanding the system we are to work on. A deep understanding of the underlying assumptions and visions helps to drastically reduce later revisions. With that in mind, our second meeting two weeks later served to align on many of these points — what are the purposes of the (in this case voting) mechanism, what constraints are likely to emerge, which desired outcomes are to result from the work, and what are the longer term intentions for this mechanism.
During the process, we discussed many of the specifics surrounding smart contract platform Soroban (currently available on Testnet), which at that point were not all publicly available or even finalized yet. Specifically, we were interested in both operational questions, such as potentially available features, computational properties of Soroban as well as strategic understanding, such as Stellar’s reasons for integrating Soroban.
After these two initial meetings, the BlockScience team added the Stellar Consensus Protocol as a focus point for investigation. While consensus protocols have considerably different requirements than governance voting mechanisms, there were two main aspects that made a closer look important: 1) First, slices of the consensus participants form together into so-called Quorums. This closeness to how social groups form was considered as a likely candidate for a future mechanism, and indeed found its way into the Quorum Delegation. 2) Second, mechanisms — and particularly voting mechanisms — should be understandable and legible to their constituents to allow them to self-govern, including any adaptations that the community wants to make to the mechanism. One way to further this aspect is to design along a community-shared knowledge and understanding, where concepts that the community clearly values — indicated by these concepts forming core aspects of the infrastructure — are adapted and incorporated.
Aside from these two aspects, the BlockScience team additionally started developing a series of questions that would ultimately serve as the basis for our requirements engineering and design process.
Some of the questions that came up early in this process surrounded general dynamics of a voting mechanism:
1) Are voters doing their work voluntarily or is there an intention to pay them for their contribution?
2) Are voting windows expected to stay discrete or might they become dynamic and continuous?
3) Are voting outcomes binding — potentially paying out programmatically upon resolution of the voting process — or are they considered a strong signal upon which other actors conduct a final review?
4) Should voting power be equal among all members, or correlated to weighting schemes incorporating aspects of community values? For example, a voter might receive a higher voting power if they were actively voting in prior rounds.
Through this initial exercise of gathering information, clarifying underlying desired properties, outcomes, and constraints, and then formulating these into requirements, the BlockScience team sketched out some architectural considerations and first designs. Generally, we prefer to provide such suggestions both in text, describing our intentions and assumptions, as well as in diagrams, allowing for visual representation and interpretation of systems and their interactions. The first diagram representing our idea for a modular voting mechanism can be seen in Fig. [MIWVP]. In this early version, several of these modules would be connected through layering, with optionality for the voter to use as many of these modules as they like or have access to. This feature has since been removed to reduce complexity for a proof of concept.
Some important points can be gleaned from this diagram: First, when votes are tallied up, “module” outputs need to be aggregated. In this diagram, the choice was to do aggregation by simple multiplication. This was later revisited and changed to be adaptable arbitrarily, in order to allow for more expressiveness. Second, a modular approach, with a separate weighting part, allows for simpler community adaptation through governance processes. If a module concept is still desired, but results in unintended effects, the community can decide to scale the strength of individual modules with higher legibility on discussions.
After earlier alignment on the modularity of the mechanism as well as the introduction of a group delegation scheme with similarity to the Stellar Consensus Protocol, we moved to defining the general form and structure of the subsystem. With it came first descriptions of this mechanism — a weighted multi-layer hybrid delegation. To dissect this description, let’s look at it in parts:
- Weighted: the usage of voting power changes through Neural Governance and Voting Neurons. The Voting Power Weights can include multiple innovative sub-mechanisms, like the usage of a Trust Graph and reputation scores.
- Multi-Layer: Votes can be aggregated through more than Neuron layer
- Hybrid: Votes can be delegated to both individuals and Quorums
At this stage, naming the mechanism was mostly irrelevant, but in later stages, we would revisit this and ultimately agree on Neural Quorum Governance (NQG).
In this first phase, we generally expected to have various questions driving future design paths. Fig. [VDopt] shows some of the decisions we were confronted with at this point and signifies the importance of artifacts — written or drawn — that serve as a basis to criticize, decide and ultimately revisit earlier assumptions.
With a form and structure defined, and requirements and constraints described (as we described in the Introducing Neural Quorum Governance article), we were ready to move to Phase 2: System Design. (link for hi-res image)
2) Designing Neural Quorum Governance
In this phase, we would expect most of the hours to be conducted internally as we specify parts of the system and work towards our Python implementation. At BlockScience, we often hand off designs and specifications to implementation teams (Fig. [SPEC]). By providing varying material, including context for decisions, we attempt to reduce uncertainties. While a Python example implementation cannot simply be translated into Rust for Soroban, it does provide a clear example of how one might translate the specification into code as per Fig. [Model].
As with earlier stages, not every detail had been fleshed out yet. Some of the questions we posed at this point were:
1) Should Quorum Consensus be determined through Vote Consensus (1 delegate has 1 vote) or Voting Power Consensus (Voting Power taken into account)?
2) Should Quorum Consensus be based on Absolute Agreement (eg. the majority even when including those who abstain) or Relative Agreement (eg. the majority excluding those who abstain)? Or both?
3) What happens if there’s no Quorum Consensus on voting “yes”? Should it render an “absent” position or a “no” position?
4) How should Quorum Delegation resolve circular delegation? (e.g. how do we treat the quorum agreement when one of its delegates has also delegated to another quorum?)
By resolving such questions and documenting the discussions and decisions made, we were able to conclude Phase 2 successfully. By handing off the deliverables to the implementation team, our job would now transform into Phase 3: Implementation Support and System Validation.
3) Implementing and Validating Neural Quorum Governance
Finally, in the Implementation & Validation phase, there were two main work streams. The first one concerned clarifying any uncertainties and assisting with issues raised during implementation. This was performed by tasks such as code review on the Rust implementation (Fig. [SUPPORT]) and validation of implementation decisions. This helped assert that the implementation was faithful to the mechanism that was specified.
The actual implementation was done by members of the SDF on Soroban, a Smart Contract Platform that is integrated into the Stellar Ecosystem. Using Soroban is justified by the fact that 1) Soroban itself is in Testnet and one desirable for the Voting Mechanism was to explore and validate its performance characteristics for governance modules and 2) it is on the scope of the Stellar Community Fund (SCF) to support projects that are building on Soroban, therefore the implementation of an innovative Voting Mechanism is also meant to pioneer governance in the ecosystem.
Soroban not only provided us with a strong base for development but also facilitated our collaboration with the Stellar network’s rapidly expanding developer community. This selection allowed us to effectively test its functionalities and monitor its developmental stages up to its launch on Mainnet.
The approach to the NQG implementation in Soroban was lean and agile. Initially, the design implemented a one contract per neuron architecture, but as we learned on best practices, we adapted into a better design by using only two contracts: the voting_system and external_data_provider. The former serves as the heart of Neural Quorum Governance, making its capabilities accessible via a set of high-level API functions. On the other hand, the latter contract was dedicated to storing any external data, which the voting contract might need for its operations.
The second work stream concerned further validation of the mechanism specified by coding a cadCAD simulation that allows us to understand system dynamics at a higher complexity, to increase confidence that intended effects are realized and initial parameters can be set to safe values. More specifically, we collected data from previous rounds, and together with simplifying assumptions were able to create stylized simulations for backtesting the Neural Quorum Governance behavior over past rounds. (Fig. [Model])
Conclusions & Next Steps
Neural Quorum Governance is the culmination of an engineering journey that went through many steps to ensure a robust system. We’ve gone through a full cycle of the Engineering Design Process for delivering an innovative governance module, which will highlight Soroban capabilities and Stellar features while asserting a solution that is prepared for a future where the community and ecosystem scales.
Moving forward to the last quarter of 2023 and beyond, our expected next steps are to continue developing the relevant processes and procedures to conduct modeling and analysis of the SCF voting mechanism during each SCF round. This will enable us to provide per-round reports on the SCF round outcomes as per their success and any required calibration and fine-tuning, which may require ideating more capacities through new voting neurons on the NQG. For more information, as well as blogs and updates check out the SCF Handbook, and stay tuned for the final article in this series!
Article written by Danilo Lessa Bernardineli and Jakob Hackel, with contributions and reviews provided by Kelsie Nabben, Jessica Zartler, Jeff Emmett, Daniel Furfari, Anke Liu, Alejo Mendoza, Giuliano Losa, and SCF verified members.
About BlockScience
BlockScience® is a complex systems engineering, R&D, and analytics firm. By integrating ethnography, applied mathematics, and computational science, we analyze and design safe and resilient socio-technical systems. With deep expertise in Market Design, Distributed Systems, and AI, we provide engineering, design, and analytics services to a wide range of clients including for-profit, non-profit, academic, and government organizations.
🐦Twitter | 📚 Medium | 👻Blog | 🎥 YouTube | 👥Linkedin
About Stellar Community Fund
The Stellar Community Fund (SCF) is an open-application awards program managed by the Stellar Development Foundation to support developers and startups building on Stellar and Soroban. SCF relies on input from verified members in the Stellar community for award allocation, governance and project support to keep the fund running and developing. Review rounds run monthly and projects can request up to $100K worth of XLM at a time.
About Stellar and Soroban
Stellar is a public and open-source blockchain network for payments, on- and off-ramps, and tokenization. It is powered by the Stellar Consensus Protocol (SCP), which is a federated proof-of-agreement consensus mechanism. Soroban is a Rust / WASM / JSON-RPC based smart contract platform which is designed to be sensible, built-to-scale, batteries-included, and developer-friendly. It is meant to have seamless integration with the Stellar network and is currently live on Testnet.
About Stellar Development Foundation
The Stellar Development Foundation (SDF) is a non-profit organization that supports the development and growth of Stellar, an open-source network that connects the world’s financial infrastructure. Founded in 2014, the Foundation helps maintain Stellar’s codebase, supports the technical and business communities building on the network, and serves as a voice to regulators and institutions. The Foundation seeks to create equitable access to the global financial system, using the Stellar network to unlock the world’s economic potential through blockchain technology. For more information, visit stellar.org/foundation.
Appendix
A1: Voting Mechanism Properties that were considered for design
In the ideation phase of this project, we explored various mechanisms and implementations, including:
a) Non-Sequential Voting (Hybrid temporal mechanisms)
- Non-sequentiality throughout the entire voting process
Example: Bitcoin, Ethereum (Proposals can be made at any time, votes can be held when convenient)
- Submissions at any time, but voting in a discrete window
Example: Holographic Consensus (DAOstack)
- Voting/Signaling before submission is finalized
Example: MakerDAO Governance Pools help signal current sentiment and will lead to refinement before submitting for an Executive Vote. Submissions can be made at any time, whereas polls go live each week on Monday at 4pm UTC.
- Voting retroactively
- Retroactive Funding for Public Goods to encourage collective value creation
Example: Optimism
b) Voting Weights
- One identity one vote
This method encourages individual participation in voting but struggles with identity verification complexities in blockchain networks.
Benefits: Encourages participation, equality and democratic decision making.
Trade-offs: Difficulty in proving unique identity in blockchain networks. Can lead to rule by mob by not including subject matter expertise.
Example: Gitcoin proposals via Snapshot.
- One token one vote
This system avoids identity verification by linking votes to tokens, promoting clear rules and potential network effects.
Benefits: Avoids need for identity verification, establishes clear rules, potential network effect on token value and utility.
Trade-offs: Tends to be plutocratic, early token distributions impact long-term decision-making.
Example: MakerDAO.
- Delegation
Delegation allows voters to entrust their voting power to another trusted actor, reducing the burden on individual voters.
Benefits: Reduces attention cost, technical requirements, and administrative overhead for individuals.
Trade-offs: Difficulty in identifying suitable delegates; increased risk of collusion and centralization.
Examples: ENS, GitcoinDAO, Compound, Aave, MakerDAO, Optimism, delegated Proof-of-Stake like EOS, Steemit, PolkaDot.
- Expert weighting / Community Engagement / Prior Voting
Expertise-weighted voting assigns additional weight to votes from domain experts, promoting more informed decision-making.
Benefits: Better delegation to domain experts; reduces overhead for individual users; can expedite governance.
Trade-offs: Risk of centralization; overhead and complexity in assigning and re-assigning weights.
Examples: Colony, Aragon (additional proposal)
- Token amount + time-weighted
Curve Finance: Lock-up period, with voting power decreasing as time until lock-up decreases
Conviction voting (Commons Stack, TEC): Voting power increases for each time step that voting tokens are locked up for a specific proposal. Streamlines attention cost, introduces time dimension, less exploitable by large holders in discrete voting windows, more suited for subjective decisions such as budget and resource allocation, but increases complexity and requires locking of tokens, not very suitable for objective decision making
- Quadratic Voting
GitcoinDAO (quadratic funding): Voting power decreases quadratically by amount of tokens used. Better minority voice representation, but incentivizes sybil attacks (multiple, fake identities) and is slightly more complex to understand / judge outcomes for users. Can lead to the Matthew effect.
c) Differing Voting Outputs
Binary Yes/No but signaling first
MakerDAO
Conviction Voting: Conviction turns to yes or no
- Voting on subcomponents (Budget, deliverables,…)
Mostly used in signaling before actual vote
Conditional Yes
Gnosis: Conditional Tokens (via prediction markets)
d) Votes as Bets
Futarchy / Prediction Markets
Gnosis, DAOstack (Holographic Consensus): Scales decision making process by introducing a prediction market to boost proposals towards differing vote processes. Can help avoiding bootstrap issues due to voter apathy in initial phases, scaling through different phases of voting, but introduces complexity and dependencies of prediction markets while financializing attention.
e) Permissioning
- Multi-Sig Control
In Multi-Sig Control approaches, token holders signal their preferences, while a smaller centralized committee executes decisions.
Benefits: Establishes regulatability where legal systems require it.
Trade-offs: Less decentralized.
Example: Balancer
- Permissioned Relative Majority
Only allow a token-holder relative majority vote after a proposal has been validated and signed-off by a DAO member.
Benefits: Extra layer of security, accountability for participants, and decreases overhead by the general voting public.
Trade-offs: Slows the process; can create a less active community, making it easy to pass proposals.
Examples: Moloch V2, Raid Guild, DAOhaus
f) Privacy
- Homomorphic Encryption
A16Z Homomorphic Encryption Scheme to hide running vote tally as voting is ongoing. After voting, both vote tally and individual votes are revealed. Achieved through time lock puzzle hiding the votes within a timeframe in which computation to reveal is infeasible. Needs additional MPC (multi-party computation) or class groups to avoid a central party having knowledge of factorization for the RSA modulus N used. Also needs an additional ZK anonymity set if voter anonymity after time lock is needed.
g) Other Agnostic Voting Attributes (could apply across various mechanisms):
- Opportunity for non-binary vote outcome in funding scenarios (e.g. matching pools, rather than ‘yes’ or ‘no’).
- Discrete vs dynamic voting windows.
- Third-party or ‘expert’ opinion / endorsement.
- Expert advisory (meritocracy. Paid roles?).
- Democratically elected ‘council’.
- Retroactive funding. (e.g. Optimism).
- More granular milestone-based payments (e.g. GitHub based progress).
- Quorum based (threshold of total votes, or of yes votes, or of no votes [objection-based — i.e. passes unless there’s X no, e.g. Lido Easy Track])
- Non-voting as3 voting against vs. abstaining.
- Bonus trust score (e.g. Gitcoin passport). Trusted community members get benefits in the funding mechanism (e.g. more matching funds allocated to the grant of their choice). In Gitcoin, this is also about addressing the sybil / identity problem.
