SCF’s Implementation of NQG–on Mainnet! Open-source!

The Stellar Community Fund (SCF) is taking a significant step forward with its collaboration with BlockScience to develop Neural Quorum Governance (NQG). This innovative governance model merges reputation-based voting power with the flexibility of opt-in group delegation, paving the way for a more democratic and transparent decision-making process. SCF’s implementation of NQG is currently in development leveraging Soroban, the native smart contract platform on Stellar.

Following our previous update on the roadmap, we are thrilled to announce that Phase 6 of full-scale deployment within SCF has begun!

• Deployed contract on Stellar Mainnet ✅
• Open-source repo ✅

Contract Mechanics: How It Works

NQG combines two fundamental concepts: Neural Governance and Quorum Delegation. Neural Governance employs voting neurons layered and aggregated to calculate a user’s voting power. Quorum Delegation enables users to delegate their votes to trusted, private groups — known as Quorums — where a consensus among delegates is necessary for vote delegation.

To balance user privacy, transparency, and computational efficiency within the current constraints of Soroban, NQG employs a hybrid computational model. Currently, the contract aggregates results from each neuron to ascertain the final voting power for submissions, with computations performed off-chain and results uploaded to the contract by an administrator.

Tally Votes (On-Chain)

After votes and voting powers are uploaded, the below function in the on-chain contract is called for each submission to get the its final voting score.

    /// Compute the final voting power of a submission.
    ///
    /// Requires calling `calculate_voting_powers` first to compute and store voting powers for the round.
    ///
    /// # Panics:
    ///
    /// The function will panic if no voting powers are set for the active round.
    pub fn tally_submission(env: &Env, submission_id: String) -> Result<I256, VotingSystemError> {
        let submission_votes = Self::get_votes_for_submission(env, submission_id.clone())?;
        let mut submission_voting_power_plus = I256::from_i32(env, 0);
        let mut submission_voting_power_minus = I256::from_i32(env, 0);
        let voting_powers = Self::get_voting_powers(env.clone())?;

        for (voter_id, vote) in submission_votes {
            let voting_power = match vote {
                Vote::Abstain => I256::from_i32(env, ABSTAIN_VOTING_POWER),
                _ => voting_powers
                    .get(voter_id)
                    .ok_or(VotingSystemError::NGQResultForVoterMissing)?,
            };
            match vote {
                Vote::Yes => {
                    submission_voting_power_plus = submission_voting_power_plus.add(&voting_power);
                }
                Vote::No => {
                    submission_voting_power_minus =
                        submission_voting_power_minus.add(&voting_power);
                }
                Vote::Abstain => (),
            };
        }

        Ok(submission_voting_power_plus.sub(&submission_voting_power_minus))
    }

Delegation (Off-Chain)

Delegations are resolved off-chain, uploading only the final votes. This is due to the use of Discord usernames in the voting interface, which could link usernames to public keys if handled on-chain. Future updates may utilize public keys directly to enable on-chain resolution, which would require the keys to have sufficient associated ‘reputation’ data before this change can be made.

fn calculate_quorum_consensus(
    delegatees: &[String],
    submission_votes: &HashMap<String, Vote>,
) -> Result<Vote> {
    let valid_delegates: Vec<&String> = delegatees
        .iter()
        .filter(|delegatee| {
            let delegatee_vote = submission_votes.get(*delegatee).unwrap_or(&Vote::Abstain);
            matches!(delegatee_vote, Vote::Yes | Vote::No)
        })
        .collect();

    let selected_delegatees = if valid_delegates.len() < QUORUM_SIZE as usize {
        valid_delegates.as_slice()
    } else {
        &valid_delegates[..QUORUM_SIZE as usize]
    };

    let mut quorum_size = 0;
    let mut agreement: i32 = 0;
    for &delegatee in selected_delegatees {
        let delegatee_vote = submission_votes.get(delegatee).unwrap_or(&Vote::Abstain);

        if delegatee_vote == &Vote::Delegate {
            continue;
        }

        quorum_size += 1;
        match delegatee_vote {
            Vote::Yes => agreement += 1,
            Vote::No => agreement -= 1,
            Vote::Abstain => {}
            Vote::Delegate => {
                bail!("Invalid delegatee operation");
            }
        };
    }

    let absolute_agreement: f64 = f64::from(agreement) / f64::from(QUORUM_SIZE);
    let relative_agreement: f64 = if quorum_size > 0 {
        f64::from(agreement) / f64::from(quorum_size)
    } else {
        0.0
    };

    Ok(
        if absolute_agreement.abs() > QUORUM_ABSOLUTE_PARTICIPATION_THRESHOLD {
            if relative_agreement.abs() > QUORUM_RELATIVE_PARTICIPATION_THRESHOLD {
                if relative_agreement > 0.0 {
                    Vote::Yes
                } else {
                    Vote::No
                }
            } else {
                Vote::Abstain
            }
        } else {
            Vote::Abstain
        },
    )
}

Neurons (Off-Chain)

The design of the voting neurons allows for a nuanced encoding of power determinants, supporting a modular approach to incentive alignment without the need for a complex, monolithic function.

Currently, SCF’s NQG implementation utilizes three types of neurons:

• Trust Graph Neuron: Employs a page rank algorithm allowing community members to assign trust, which translates into voting power.
• Assigned Reputation Neuron: Increases voting power based on tiered roles like Pathfinder, Navigator, and Pilot.
• Voting History Neuron: Enhances voting power based on historical voting frequency.

As system capacity grows, we aim to migrate more functionalities of the NQG contract to on-chain operations, prioritizing voter privacy and system efficiency. If you encounter any issues, please report them in the GitHub repository. For any questions, join our discussion on Discord.

Insights from Building on Soroban

Soroban is the native smart contracts platform on the Stellar network. Live on Mainnet with application-ready functionality since March 19, there’s a greenfield of opportunities for builders to pioneer in this new smart contracts ecosystem, powered by the robust Stellar network. Building SCF’s implementation of NQG on Soroban and resulting community feedback has taught us to adapt our strategies based on technical challenges, and identify opportunities for further growth.

The Need for a Hybrid Computational Model

The earlier described hybrid computational model arose as the only preferred solution to balance the intense computational demands of NQG’s design with some level of efficiency, and ensuring voter privacy while having some form of known reputation. Until compatible layer 2, ZK or roll-up solutions are available on Soroban, the current implementation is unable to provide a completely on-chain verifiable proof of computation.

• Computational Intensity and Costs: Our initial intent to run voting entirely on-chain proved highly impractical due to cost and resource constraints. The computation for just the Trust Neuron, involving four users and 12 nodes, requires over 500 million CPU instructions, significantly exceeding Soroban’s transaction limit of 100 million. To ensure operations remain within Soroban’s limits, only Neuron results along with other necessary data are uploaded to the contract.
• Data Storage Optimization: Early implementations attempted to upload and tally entire neuron results on-chain, but this approach failed due to memory constraints. We then experimented with splitting neuron results into multiple contract keys, which initially seemed viable until discrepancies between the NQG specifications and our implementation necessitated a return to predominantly off-chain computations.
• Balancing Anonymity with Verifiability: A key decision point was whether to prioritize voter (and delegate) anonymity or the verifiability of results. Heeding community feedback, we chose to safeguard voter anonymity. Consequently, we only upload normalized votes and final neuron results for on-chain tallying, preventing any potential linkage between Discord usernames and public keys used in the contract.

Navigating Storage on Soroban

Soroban uniquely addresses ledger state bloat with state expiration, where data written by smart contracts eventually expires unless maintained by additional fees. This feature compelled us to optimize for contract efficiency early on:

• Storage Challenges and Solutions: We faced issues with the scalability of transactions, which were resolved by transitioning from instance storage, which loads all data into memory per transaction, to a more efficient permanent storage model.
• Cost-effective Contract Execution: Our final implementation uses a mix of persistent and temporary storage types. While final voting powers and user votes are stored permanently, allowing for data recovery even after expiration, intermediate calculations utilize temporary storage to reduce costs.

Next Steps

The goal is to refine the voting mechanism to the point where the SCF award allocation process can be made fully deterministic. To achieve this, we’ve identified the following key next steps:

Reduce Non-Successful Delegation

Inspired by the Stellar Consensus Protocol, Quorum Delegation empowers members to select their own delegates for achieving vote consensus, effectively mitigating rogue behaviors. This feature enables liquid democracy within SCF’s voting system, providing flexibility for members to vote directly or delegate their votes when they lack time, expertise, or the necessary tier to vote:

• Quorum Delegation has been instrumental for Navigators and Pilots with active voting capabilities, allowing them to delegate responsibly when they are unable to participate directly due to time constraints, lack of expertise, or potential biases.
• It also enables Pathfinders to delegate their votes to other Navigators and Pilots, enhancing their involvement in governance, building their reputation, and ensuring the voting process more accurately reflects community sentiment.

However, in recent rounds, we observed a high rate of non-successful delegations, primarily because delegated votes often failed to meet the minimum active voter threshold. Currently, community members delegate to Discord usernames, which obscures exact voter histories to protect privacy but hampers informed decision-making in delegations. To address this, by the next voting round, we plan to:

• Enhance Transparency: Introduce an aggregated voter activity score in the voter UI, providing more transparency while continuing to safeguard privacy.
• Adjust Quorum Sizes: Increase the minimum potential quorum size (e.g. from 5 to 8) and the maximum (e.g. from 10 to 15).
• Lower Voting Thresholds: Reduce the number of minimum active voters required for a quorum to successfully cast votes (e.g. from 5 to 3).

Scaling Neuron Weight Attribution

The current model of Neural Governance simplifies the addition of voting power where e.g. the Voting History Neuron adds a fixed increment per voting round. While effective short-term, this linear progression risks long-term centralization, as veteran members might accumulate disproportionate influence, overshadowing newer participants.

To prevent such disparities and promote a balanced community dynamic, we are exploring a scaling system for neuron weights inspired by learning curves. Unlike linear growth, learning and reputation typically follow logistic curves: after an initial hurdle, subsequent efforts lead to rapid gains, reaching a plateau as progression slows. This model will allow new members to effectively gain influence through positive contributions, while established members will experience slower growth rates after reaching a certain inflection point.

On the flipside, this approach also ensures that i.e. mistrust from one or two members won’t significantly impact a user’s voting power, but widespread distrust from many will lead to noticeable decreases, preserving the integrity of community consensus.

Tokenization of NQG Scores

To further enhance the utility of SCF’s implementation of NQG, we’re exploring the tokenization of the final voting scores generated by the contract each voting round. These mintable and burnable balances on a voter’s account allow for on-chain verification and history record, as well as use in other (token-based) governance platforms like Soroban Governor. This could enable SCF voters to participate in a broader range of governance decisions, such as voting on proposals to adjust SCF’s structure.

Get Involved

We invite the entire Stellar community to actively engage with and contribute to the ongoing development:

• Code Review and Contributions: Dive into the codebase, identify potential improvements, and contribute via pull requests.
• Feedback and Discussion: Participate in community discussions on Discord (#scf-general or #verified-panel) or provide feedback through this feedback form.
• Become verified and participate in voting: Become a verified member of the Stellar Community Fund, reach the pathfinder level and start participating in SCF’s monthly Community Vote through delegation.
• Innovation and Development: Create your own implementations of NQG or contribute new ideas to the Governance Modules Library! Find instructions on how to contribute in this repo, get involved in the GML discussion on Discord in #projects. If your work involves development on Soroban, consider applying for support through the Stellar Community Fund.

Co-Authored by Anke Liu from the Stellar Development Foundation and Artur Michalek and Igor Dzierwa from Software Mansion. Contributions and review provided by Jakob Hackel and Danilo Lessa Bernardineli from BlockScience, as well as SCF Verified Members.

About BlockScience
BlockScience® is a complex systems engineering, R&D, and analytics firm. Our goal is to combine academic-grade research with advanced mathematical and computational engineering to design safe and resilient socio-technical systems. We provide engineering, design, and analytics services to a wide range of clients, including for-profit, non-profit, academic, and government organizations, and contribute to open-source research and software development.

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 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.

SCF’s Implementation of NQG–on Mainnet! Open-source! was originally published in Stellar Community on Medium, where people are continuing the conversation by highlighting and responding to this story.