Verifiable, Privacy-Preserving and Collaborative Multi-Objective Optimization with NSGA-II on Blockchain

Verifiable, Privacy-Preserving and Collaborative Multi-Objective Optimization with NSGA-II on Blockchain Goshgar Can Ismayilov Istanbul, Turkey goshgar.ismayilov@boun.edu.tr

arXiv:2611.11567v1 [cs.DC] 8 Nov 2026

Abstract Collaborative multi-objective optimization allows independent problem solvers to contribute their solutions to a shared problem. However, their validity cannot be reliably verified in open settings if the parties are reluctant to disclose their solutions. Therefore, this paper proposes a novel zk-NSGA-II protocol for verifiable, privacy-preserving and collaborative multi-objective optimization on blockchain. To the best of our knowledge, this is the first work that executes Non-Dominated Sorting Genetic Algorithm II (NSGAII) on the RISC Zero Zero-Knowledge Virtual Machine (zkVM) where evolutionary generations are certified by succinct proofs that are verified on-chain. Problem solvers maintain their own independent populations as the set of solutions in the decision space and their corresponding objective vectors in the objective space. They contribute to a global on-chain Pareto front by aggregating their local off-chain Pareto fronts according to the rule of nondomination which admits a contribution if it is non-dominated with respect to the existing contributions in the global front. To prevent fabricated contributions, population states across generations are linked through hash chains. The correctness of the zk-NSGA-II protocol is first evaluated on twelve problems from the ZDT and DTLZ benchmarks. Second, its feasibility is shown in a real-world portfolio optimization case study with the Hang Seng dataset. Performance on these problems is measured with nine different metrics across three complementary perspectives for optimization, zeroknowledge proof and blockchain. The empirical findings indicate that trustless collaborative multi-objective optimization is feasible with the existing zero-knowledge and blockchain technologies.

Keywords blockchain, privacy-preserving techniques, zero-knowledge proof, multi-objective optimization, federated optimization, NSGA-II, zkVM

1

Introduction

Consider a financial investor who asks several asset managers to construct portfolios, balancing the expected return against the risk. No portfolio is superior in both respects in principle since higher returns generally come at the cost of higher risks. Therefore, the investor is interested in the efficient frontier jointly formed from the portfolios of all managers. Although the asset managers are willing to report the returns and risks of their portfolios to form this frontier, they are reluctant to reveal the exact asset weights to the public, which are part of their hidden proprietary strategies. On the other hand, the investor needs to verify these reports since a portfolio with unusually high return at low risk might stem from a sound strategy or merely a clever presentation of a mediocre one. In this scenario, the investor can at least be assured that the portfolio is indeed the product of a mutually-agreed set

of operations without observing the weights. This is the issue of privacy-preserving but collaborative multi-objective optimization (MOO) among mutually-distrusting parties, with the conflicting objectives of return maximization and risk minimization. This work addresses privacy with zero-knowledge proof (ZKP), public verifiability and trust with blockchain, MOO with NSGA-II [1] and collaboration with frontier aggregation. The first key question about the scenario above is who will form the frontier with individual portfolios, which naturally raises the trust issue. The simplest answer is the investor itself. However, the managers would have to trust the investor about not maliciously changing contributions, not favoring certain ones or not colluding with the other managers. Relying on a neutral coordinator would also shift the trust issue somewhere else, rather than solving it. Our work incorporates blockchain to properly address this issue. Blockchain is a distributed ledger that is shared across all nodes in the network [2]. Smart contracts extend the idea of distributed ledger with public, self-executing and deterministic programs with states and functions [3]. For our scenario, blockchain offers several notable advantages. First, every contribution is permanently recorded and attributed to its contributor for auditability. Second, the rules of frontier aggregation are publicly-encoded and agreed. Third, participation is open to anyone at any time without the approval of an authority. In the literature, there exist works that focus on optimization and blockchain at the same time to replace hash puzzles with Proof-of-Useful-Work (PoUW) [4, 5] and to execute genetic algorithms [6]. However, these works reveal contributions for validation, which the managers in our scenario would not accept. The second key question is how to convince without revealing weights. In this work, we incorporate ZKP, which is a special cryptographic technique that allows a prover to convince a verifier about a certain statement [7]. Modern proof systems make this practical for general-purpose computations. For instance, zkSNARKs produce succinct and non-interactive proofs that can be verified in milliseconds off-chain [8] while zkSTARKs remove the need for a trusted setup [9]. In addition, zkVMs such as RISC Zero [10] prove the execution of ordinary programs and thus eliminate the need to design hand-crafted arithmetic circuits. ZKPs offer several critical advantages. First and most importantly, what should remain private remains private. Second, due to the soundness of proof systems, valid proofs cannot be forged for incorrect results. Third, proofs are succinct and cheap to verify on-chain regardless of how long the actual optimization is. These properties have been exploited for verifiable machine learning applications [11–13]. However, to the best of our knowledge, integration with multi-objective evolutionary algorithms (MOEAs) has not been considered.

1.1

Table 1: Common abbreviations used throughout the paper, listed in alphabetical order.

Contributions

This paper makes the following contributions to the literature: • zk-NSGA-II as verifiable, privacy-preserving and collaborative NSGA-II in zkVM. As the core contribution of this work, we propose zk-NSGA-II which executes NSGA-II on the RISC Zero zkVM off-chain and certifies the result with succinct proofs to verify on-chain. In zk-NSGA-II, problem owners deploy their problem instances as smart contracts while problem solvers maintain independent and asynchronous populations to solve these instances collaboratively. • Aggregation of local fronts into a global Pareto front. We formulate the privacy-preserving MOO from the federated perspective so that the mutually-distrusting solvers maintain their own local Pareto fronts off-chain and contribute to a single global Pareto front on-chain. The contract admits a new solution if it is valid and no solution on the global front dominates it. It also removes the solutions that the new one dominates from the global front. During front aggregation, populations are never exposed to the public except the objective vector of the non-dominated solution submitted to the contract. • Extensive experimental study. We evaluate zk-NSGAII on twelve synthetic problems from the ZDT and DTLZ benchmarks to justify its correctness. In the experiments, we use performance measures from three complementary perspectives: (i) number of non-dominated solutions, Schott’s spacing, inverted generational distance and hypervolume ratio for MOO, (ii) zkVM cycles, proving time, verification time and proof size for ZKP and (iii) function-level gas consumption for the blockchain perspective. • A privacy-preserving portfolio optimization case study. We apply zk-NSGA-II to the Hang Seng portfolio optimization to demonstrate its performance on a real-world problem. In the case, the solvers report the risk and return of their portfolios while the portfolio weights remain private. Our findings on both synthetic and real problems justify the feasibility of zk-NSGA-II while further improvements are necessary for practicality such as reduction in proving time.

1.2

Meaning

DTLZ EVM HVR IGD MOEA MOO NS NSGA-II RISC-V SHA-256 SNARK SS STARK ZDT ZKP zkVM

Deb–Thiele–Laumanns–Zitzler test suite Ethereum virtual machine Hypervolume ratio Inverted generational distance Multi-objective evolutionary algorithm Multi-objective optimization Number of non-dominated solutions Non-dominated sorting genetic algorithm II Reduced instruction set computer, fifth generation Secure hash algorithm, 256-bit digest Succinct non-interactive argument of knowledge Schott’s spacing Scalable transparent argument of knowledge Zitzler–Deb–Thiele test suite Zero-knowledge proof Zero-knowledge virtual machine

proof verification in this section. We also establish the terminology and common notations used throughout the work, which are listed in Tables 1 and 2, respectively.

2.1

Multi-Objective Optimization

MOO concerns a group of problems in which multiple conflicting objectives need to be optimized simultaneously [14]. Without loss of generality, a minimization problem with 𝑚 objectives can be formulated in the following way:
min F(x) = 𝑓1 (x), 𝑓2 (x), . . . , 𝑓𝑚 (x) x∈Ω

subject to 𝑐 𝑗 (x) ≤ 0,

𝑗 = 1, . . . , 𝐶

𝑒𝑙 (x) = 0,

𝑙 = 1, . . . , 𝐸

(1)

where x = (𝑥 1, . . . , 𝑥𝑛 ) is the decision vector, Ω is the decision space while 𝑐 𝑗 and 𝑒𝑙 are the inequality and equality constraints, respectively. In MOO with conflicting objectives, there is generally no single solution that minimizes all these objectives at once. Instead, the solutions are ranked through the principle of Pareto domination on their objective vectors. An objective vector a ∈ R𝑚 weakly-dominates another objective vector b ∈ R𝑚 (a ⪯ b) if 𝑎𝑖 ≤ 𝑏𝑖 for all objectives 𝑖 ∈ {1, . . . , 𝑚} and Pareto-dominates it (a ≺ b) if, in addition, 𝑎𝑖 < 𝑏𝑖 for at least one objective 𝑖. A solution is referred to as Pareto-optimal if no other solution dominates it. The set of all such Pareto-optimal solutions in the objective space forms the Pareto front P. The goal of MOO is therefore to find a set of nondominated solutions that approximates P as closely as possible. In this work, we consider only 𝑚 = 2 objectives. NSGA-II [1] is among the most widely used MOEAs [15, 16]. NSGA-II maintains a parent population 𝑃𝑡 with the size of 𝑁 and produces an offspring population 𝑄𝑡 with the same size in every generation 𝑡. The parent and offspring populations are then merged into 𝑅𝑡 = 𝑃𝑡 ∪ 𝑄𝑡 of size 2𝑁 and ranked through the fast nondominated sorting into successive fronts F1, F2, . . . , where F1 refers to the non-dominated solutions. The next population 𝑃𝑡 +1 is filled front by front until all 𝑁 solutions are selected. For the comparison

Paper Organization

The remainder of the work is organized in the following way. Section 2 provides the necessary background on MOO, ZKP and smart contracts. Section 3 reviews related work on privacy-preserving evolutionary computation, verifiable computation on blockchain and decentralized optimization on blockchain. Section 4 proposes the key contributions of the work by introducing the zk-NSGA-II protocol on a zkVM. Section 5 describes the experimental setup including the benchmark problems, real-world case study and performance measures. Section 6 reports the empirical results to show correctness and efficiency of zk-NSGA-II on numerous scenarios. Finally, Section 7 concludes the work.

2

Abbreviation

Background

The proposed protocol lies at the intersection of three domains as blockchain, ZKP and MOO. Therefore, we briefly provide background for the concepts of Pareto-domination, zkVMs and on-chain 2

Table 2: Common mathematical notation used throughout the paper, grouped by MOO, collaborative optimization, blockchain and portfolio optimization. Symbol

General-purpose proof systems express the computation as an arithmetic circuit, which is known as arithmetization. Designing a dedicated circuit for every computation is error-prone, especially for complex algorithms such as NSGA-II that involve loops, data-dependent branching, sorting and floating-point arithmetic. A zkVM addresses this issue by proving the correct execution of an arbitrary program, written in a programming language. In this work, we adopt the RISC Zero zkVM [10] that executes programs compiled to the RISC-V instruction set. The proven program (i.e., guest) is written in Rust and a host supplies the guest with private inputs to run it. In zk-NSGA-II, the guest executes one NSGA-II generation on a private population while the hash chain for the previous and new populations is maintained on-chain for integrity.

Description

Multi-objective optimization x, 𝑛 Decision vector (𝑥 1 , . . . , 𝑥𝑛 ) and number of decision variables Î Ω Decision space 𝑛𝑗=1 [𝑙 𝑗 , 𝑢 𝑗 ] defined by variable bounds F(x) Objective vector ( 𝑓1 (x), 𝑓2 (x) ) a≺b Objective vector a Pareto-dominates b a⪯b Objective vector a weakly dominates b P∗ True Pareto front 𝑁 , 𝐺, 𝑡 Population size, number of generations, generation index 𝑃𝑡 , 𝑄 𝑡 Parent and offspring populations at generation 𝑡 𝑝𝑐 , 𝑝𝑚 Crossover and mutation probabilities r Reference point for the hypervolume measure

2.3

Collaborative optimization 𝑆, 𝑖 Number of solvers, solver index 𝑎𝑖 Blockchain address of solver 𝑖 x𝑡∗ Solution selected from the local front 𝐿𝑖𝑡 Local front (off-chain) of solver 𝑖 at generation 𝑡 G Global (on-chain) front 𝐾 Maximum size of the global front

In its purest form, a blockchain is an append-only database that is shared across all the nodes in a peer-to-peer network [2]. In permissionless blockchains such as Bitcoin and Ethereum, anyone can join the network with pseudonymous addresses, read the ledger and submit transactions. Blockchain groups these separate transactions into blocks and chains those blocks with the hash of their predecessor block. This chaining enables transaction history to be tamper-proof since even a minimal change in any past transaction propagates into all subsequent blocks. The nodes in the network agree on blocks through a consensus protocol which selects the node to create the next block. However, the integrity, availability and transparency that a blockchain provides come at a price. First, all data on a public blockchain is visible to every node, which poses risks to privacy [17]. Second, replication and re-execution of transactions by every node make computation and storage on-chain more expensive than off-chain, which motivates moving heavy and privacy-sensitive computations out of chain. Smart contracts are self-executing programs that can be deployed on a blockchain [3]. A contract has a state and a set of functions that nodes can call through transactions. Since every node executes the same contract functions on the same state, the results of these calls are deterministic and publicly verifiable. Ethereum is a contract-supporting blockchain where contracts are written in Solidity, compiled to bytecode and executed by the Ethereum Virtual Machine (EVM). Each operation in the EVM is linked to a fixed amount of gas that the calling node needs to pay. The total gas cost of a function is the sum of the gas costs of all operations it executes. From the gas cost viewpoint, running a heavy computation directly on-chain is impractical while verifying a succinct proof of that computation is still affordable. In this work, our contracts verify the proofs of problem solvers to ensure the correct computation of NSGA-II while the populations still remain off-chain.

Zero-knowledge proof and blockchain Γ NSGA-II guest program proven in the zkVM 𝜋𝑡 Groth16 proof of the generation from 𝑃𝑡 to 𝑃𝑡 +1 𝑜𝑡 Public outputs (𝑎𝑖 , ℎ𝑡 , ℎ𝑡 +1 , F(x𝑡∗+1 ) ) of 𝜋𝑡 𝐻 (·) SHA-256 hash function ℎ𝑡 State hash of the population 𝑃𝑡 at generation 𝑡 head[𝑎𝑖 ] Latest state hash of solver 𝑖 stored on-chain Portfolio optimization Í w Portfolio weights, 𝑤 𝑗 ≥ 0, 𝑗 𝑤 𝑗 = 1 𝝁, 𝚺 Mean asset returns and covariance matrix w⊤ 𝚺w Portfolio risk (variance) 𝝁⊤w Portfolio expected return

of solutions in the same front, the crowding distance is used, which prefers the solutions in less crowded regions of the objective space. Overall, NSGA-II is an elitist approach since it always preserves the non-dominated solutions against the dominated ones.

2.2

Smart Contracts

Zero-Knowledge Proof

Introduced by Goldwasser, Micali and Rackoff [7], a ZKP is a protocol in which a prover convinces a verifier about the correctness of a statement. A ZKP satisfies three properties: completeness guarantees that a prover with a valid witness always convinces a verifier; soundness guarantees that no dishonest prover with an invalid witness can convince the verifier; and zero-knowledge ensures that the verifier eventually learns nothing beyond the validity of the statement. Modern proof systems are non-interactive where proof generation and verification can be separately carried out without the need for interaction between the prover and the verifier. Out of these proof systems, zkSTARKs [9] require no trusted setup with the trade-off of larger proof size while zkSNARKs [8] require a trusted setup but produce constant-size proofs of a few hundred bytes, which are cheap to verify on a blockchain.

3

Related Work

In this section, we review the literature of privacy-preserving evolutionary computation, verifiable computation on blockchain and decentralized optimization on blockchain. To the best of our knowledge, no prior work combines ZKP-based correct execution of a MOEA with the trustless front aggregation of mutually-distrusting solvers while still preserving the privacy of their decision variables. 3

3.1

Privacy-Preserving Evolutionary Computation

novel local search algorithm, called Doubly Parallel Local Search. The work [29] notes that most works focus on specific problems or algorithms and presents a generic PoUW framework for arbitrary problem formulations with a security analysis. Beyond the consensus mechanisms, smart contracts are used to coordinate decentralized optimization without a trusted coordinator in domains such as energy management [30]. However, none of these approaches addresses the issue of solution privacy or collaborative MOO for front aggregation. More recently, ZKPs are introduced to protect the privacy of learning and optimization systems. The following work [31] proposes zkFL which proves the correctness of gradient aggregation in federated learning where no blockchain nodes learn the local models. Another work [32] also proposes to couple evolutionary computation with programmable cryptography on blockchain that preserves the privacy of populations. Our protocol, zk-NSGA-II, builds on this line of research but differs in three critical aspects. First, it specifically targets MOO and executes a complete NSGA-II generation inside a general-purpose zkVM. Second, it links consecutive proofs of solvers through hash chains for integrity. Third, as model aggregation in federated learning, it enables the aggregation of objective spaces of mutually-distrusting solvers into a global front on-chain while still keeping their decision variables hidden.

Privacy-preserving evolutionary computation is addressed even before the blockchain era through secure multi-party computation where several parties jointly run an evolutionary algorithm. The work [18] proposes a genetic algorithm for distributed combinatorial optimization, especially for the traveling salesman problem. The following work [19] extends the secure computation to the entire MOEA. The work [20] addresses the federated data-driven evolutionary optimization when the data is distributed across separate servers. It is later extended to multi-objective and many-objective problems as well [21]. However, secure computation requires all parties to be available during the entire optimization and assumes that they honestly follow the protocol rules. In addition, none of these approaches allows verifying that the algorithm has been faithfully executed. ZKP specifically addresses this gap by certifying the correctness of a computation. The work [22] proposes Otti, which is a general-purpose compiler for zkSNARKs that supports numerical optimization problems. It provides efficient arithmetization, especially for linear programming, semi-definite programming and stochastic gradient descent instances. In contrast to these works, zk-NSGA-II enables solvers to run NSGA-II independently on their own machines in a privacy-preserving and verifiable manner.

3.2

4

Verifiable Computation on Blockchain

Verifiable computation allows verifier nodes on blockchain to check the result of a computation that is outsourced to a prover node. In the literature, there currently exist several systems that make this practical with succinct proofs in terms of proof size [23] and with no trusted setup [9]. For an optimistic approach, the work [24] moves computation off-chain by only resolving disputes on-chain by introducing challengers to disagree. For zero-knowledge approaches, the work [25] relies on privacy-preserving smart contracts while another work [26] provides a toolbox to compile off-chain computations into proofs that are later verified inside contracts. For multi-chain systems, the work [27] also verifies the consensus of one chain on another with zkBridge. The works for zkCNN [11], ZKML [12] and zkLLM [13] also make the verification of large machine and deep learning computations practical. However, note that all these systems express the computation in terms of dedicated arithmetic circuits. zkVMs remove this requirement by proving executions of entire programs. For instance, the RISC Zero zkVM [10] allows custom Rust programs to be efficiently verified on Ethereum. However, no prior work proves the faithful execution of a MOEA, which is the gap that zk-NSGA-II addresses.

3.3

zk-NSGA-II: Verifiable NSGA-II in zkVM

This section presents zk-NSGA-II, which runs NSGA-II inside the RISC Zero zkVM off-chain and verifies the resulting executions on-chain. The main motivation of the protocol is to move the entire evolutionary computation off-chain and enable blockchain nodes to verify succinct proofs of that computation. zk-NSGA-II has four core properties: verifiable since every solution in the global front is certified to be the result of a faithful NSGA-II execution, privacypreserving since the populations and hence the decision variables never leave the local solver machines, collaborative since mutuallydistrusting solvers first evolve their own populations independently and later contribute to a global front with no trusted coordinator and finally multi-objective since the guest program executes a complete NSGA-II generation with the non-dominated sorting and crowding distance operators. The pseudocode of the solver, the guest program and the contract is given in Appendix A.

4.1

Actors

The system involves four types of actors: problem owner who poses the optimization problem, solver who searches for solutions, prover who certifies the computation of solver and on-chain contract to verify computation and aggregate multiple local fronts to a single global front. For this work, we assume that solvers are also provers.

Decentralized Optimization on Blockchain

In the literature, there currently exist several works that couple blockchain with optimization. The work [4] proposes Proof-ofSearch where the node submitting the best candidate solution to an optimization problem is rewarded as the next block miner. Another work [6] extends this idea to Proof-of-Evolution so that the miners run genetic algorithms and cooperate by sharing their resulting solutions. A similar scheme is also proposed for real-life combinatorial optimization problems as PoUW [28]. The work [5] proposes the first provably secure PoUW protocol that relies on a

4.1.1 Problem Owner. The problem owners seek high-quality solutions for their multi-objective problems with objective functions and constraints. They are responsible for deploying contracts which bind problem instances to the maximum size of the global front. Once deployed, the contracts are ready to orchestrate optimization. 4.1.2 Solvers. Solvers are mutually-distrusting participants that run NSGA-II by maintaining their own populations and therefore their own local Pareto fronts off-chain. The decision variables in 4

populations never leave the solvers, but proofs reporting the correctness of computation are submitted to the contract, which binds the objective values of a locally non-dominated solution to the solver address. Solvers advance one generation per proof and initial submissions might start from an arbitrary population. This enables solvers to explore different regions of the search space for collaborative optimization.

independent prover nodes, they would have to be trusted with the confidentiality of the solver inputs.

4.3

4.1.3 Provers. Provers execute the NSGA-II program on zkVM with solver inputs and generate proofs to certify the correctness of computation. Here, two different designs are possible where the first design lets solvers delegate proving to third-party provers if the solvers lack necessary hardware. However, provers necessarily observe solver inputs or might refuse to provide service. The second design assumes solvers as provers, so sensitive inputs remain on their own machines. The soundness of the proof system used in the work prevents any prover from certifying an incorrect computation. 4.1.4 On-Chain Contract. The contract is responsible for verifying solver submissions and admitting their solutions to the global front. It maintains two key states: a single global on-chain front as the aggregation of multiple local off-chain fronts and hash chains of solvers to ensure that the current populations are always generated from the previous ones. It admits a new solution if the current solutions at the global front cannot dominate that new solution. Once admitted, the solutions that are dominated by that new solution are removed.

4.2

Architectural Design

The architectural design of zk-NSGA-II separates computation and verification into two different layers, as shown in Figure 1. Offchain, three components work interdependently where the host application is untrusted and orchestrates the optimization-centric computation while the population store is responsible for maintaining the latest version of the population across generations and the RISC Zero zkVM executes the NSGA-II guest program and proves its execution. On-chain, the problem owner deploys two contracts for a single problem instance. The Pareto Front contract holds the state such as the capacity 𝐾 of the global front, the latest population hash head[𝑎𝑖 ] of solvers and the global front G. The Groth16 verifier is a stateless contract that only checks proofs. In Figure 1, the problem owner first deploys the contracts to initiate an optimization session (step 1). For every generation, the host loads the current population from the population store (step 2) and executes the guest program on it (step 3). The prover then generates a corresponding Groth16 proof 𝜋𝑡 (step 4). The zkVM returns the new population to the host (step 5) together with the proof and the public outputs (step 6). The host stores the new population for the next generation in the population store (step 7). The host then submits only (𝜋𝑡 , 𝑜𝑡 ) to the Pareto Front contract (step 8). The contract delegates the proof verification operation to the Groth16 Verifier contract (step 9). If the proof is valid, the Pareto Front contract performs the additional operations for orchestration. The problem owner later reads the global front (step 10). The problem solvers available for this problem instance repeat steps 2–9 independently. Figure 2 shows the same interaction as a sequence diagram from contract deployment to reading the global front.

Trust Assumptions

The security of zk-NSGA-II assumes dishonest problem solvers with no trusted party. The additional assumptions are listed as: (1) Soundness and zero-knowledge of the proof system. It is computationally infeasible to produce a valid proof for an execution that differs from the actual program. In addition, a proof reveals nothing about the private inputs of the program beyond its public outputs, which keeps the populations of the solvers private. However, the Groth16 system [23] needs a circuit-specific trusted setup. We assume that at least one participant of that setup is honest and destroys secret randomness. (2) Collision and preimage resistance of the hash function. It is also computationally infeasible to find two different inputs with the same SHA-256 output. This assumption must hold for the state hash chain of each solver. In addition, it is computationally infeasible to recover a population from its public state hash. Since the state hash is not salted, this relies on the high entropy of the population, which consists of 𝑁 · 𝑛 real-valued decision variables. (3) Correctness of the NSGA-II program. The program implements NSGA-II by correctly specifying objective functions and constraints. A proof can only certify that this program is executed faithfully, but not that the program itself is correct. (4) Correct and live execution of the blockchain. The underlying blockchain platform is expected to operate reliably by executing the smart contracts exactly as written and eventually including valid transactions into its blocks.

4.4

Off-Chain Proof Generation

In zk-NSGA-II, each solver runs NSGA-II off-chain as the guest program inside the RISC Zero zkVM (steps 2–7 in Figure 1). For the first proof, the solver can start from an arbitrary initial population 𝑃0 of 𝑁 solutions. For every subsequent proof, it continues from the current population 𝑃𝑡 . In both cases, the guest receives the population as a private input, checks that all solutions lie within the variable bounds, re-evaluates their objective vectors and then evolves the population to the next generation. In each generation, parents are chosen by binary tournament selection [33]. They are recombined with simulated binary crossover [34] and mutated by polynomial mutation [35] until 𝑁 offspring are produced. The parents and offspring are then merged into a population of size 2𝑁 and sorted into fronts with fast non-dominated sorting. The first front of 𝑃𝑡 +1 forms the local front 𝐿𝑖𝑡 +1 of the solver, from which the objective vector of a single solution x𝑡∗+1 is selected to be reported. Only the objective vector F(x𝑡∗+1 ) and the hashes of 𝑃𝑡 and 𝑃𝑡 +1 are submitted on-chain while the populations with the decision variables remain hidden. The execution is proven by RISC Zero and compressed into a constant-size Groth16 proof 𝜋𝑡 for on-chain verification as:

Since solvers act as their own provers (Section 4.1), no assumption about third-party provers is required. If proving were delegated to

(𝜋𝑡 , 𝑜𝑡 , 𝑃𝑡 +1 ) ← Prove Γ; 𝑃𝑡 , 𝑎𝑖 5

(2)

«actor» Problem Owner

1

deploy the ParetoFront and Groth16Verifier contracts

Solver machine 𝑖 (𝑖 = 1, . . . , 𝑆 )

public: 𝜋𝑡 , 𝑜𝑡 , G

submit (𝜋𝑡 , 𝑜𝑡 ) «application» Host

8

public data only

2

load the current population 𝑃𝑡

7

store the new population 𝑃𝑡 +1

3

5

«guest program» NSGA-II 4

return the new population 𝑃𝑡 +1

return the proof 𝜋𝑡 and outputs 𝑜𝑡

read the global front G

Ethereum

private: populations

execute NSGA-II on 𝑃𝑡

10

«contract» Pareto Front

𝐾 : capacity head[𝑎𝑖 ] : latest population hash of solver 𝑖 G : global Pareto front bool ← submit(𝜋𝑡 , 𝑜𝑡 ) G ← getFront()

6

verify the proof 𝜋𝑡

9

return valid / invalid

«contract» Groth16 Verifier

prove the execution trace

«datastore» Population Store

valid / invalid ← verify(𝜋𝑡 , 𝑜𝑡 ) «process» Prover RISC Zero zkVM

Figure 1: Architectural design of zk-NSGA-II with off-chain solver machines and on-chain Ethereum contracts. The problem owner first deploys the Pareto front and verifier contracts. Off-chain, the host application of each solver loads its private population 𝑃𝑡 from the population store and executes the NSGA-II guest program inside the RISC Zero zkVM. The prover then generates a proof 𝜋𝑡 of this execution and the host stores the new population 𝑃𝑡 +1 . Only the proof and the public outputs 𝑜𝑡 = (𝑎𝑖 , ℎ𝑡 , ℎ𝑡 +1, F(x𝑡∗+1 )) are submitted on-chain while the populations stay hidden. On-chain, the Pareto Front contract delegates the proof verification to the Groth16 verifier contract, checks the correctness of the hash chain and updates the global front G. The problem owner can read the global front at any time. Steps 2–9 are repeated by every solver in every generation. where Γ is the NSGA-II guest program and 𝑜𝑡 = (𝑎𝑖 , ℎ𝑡 , ℎ𝑡 +1, F(x𝑡∗+1 )) are the public outputs. The proof 𝜋𝑡 shows the correctness of 𝑜𝑡 while revealing nothing about 𝑃𝑡 .

4.5

the new solution if it is non-dominated and removes the existing solutions that the new solution dominates.

4.6

On-Chain Proof Verification

After a solver generates a Groth16 proof for its generation off-chain, the proof is submitted to the Pareto Front contract for on-chain verification (steps 8–9 in Figure 1). The contract does not implement verification itself but rather delegates it to the Groth16 verifier contract of the RISC Zero zkVM [10]. Note that a valid proof only certifies the faithfulness of off-chain NSGA-II execution. Therefore, the contract needs to perform two additional post-verification checks. First, the correctness of the hash chain must be verified (i.e., the previous state hash must be equal to the current head head[𝑎𝑖 ] stored on-chain). Second, the blockchain address of the problem solver (i.e., msg.sender) must be verified. If these checks successfully pass, the head of the solver is updated accordingly. Formally, a submission is verified if and only if:
Verify Γ; 𝜋𝑡 , 𝑜𝑡 ∧ 𝑎𝑖 = msg.sender ∧ head[𝑎𝑖 ] = ⊥ ∨ ℎ𝑡 = head[𝑎𝑖 ]

Hash Chain for Computation Integrity

While a generation proof certifies that the population 𝑃𝑡 +1 is correctly derived from the population 𝑃𝑡 , it says nothing about where 𝑃𝑡 comes from. An adversarial solver could easily start every proof from a population of its own choice without following the generational approach of NSGA-II. In this case, each proof in isolation would be valid while the sequence of consecutive proofs does not correspond to any actual run of NSGA-II. The most direct solution would be to store populations on-chain. However, this would reveal the decision variables to the public and also incur a storage cost that grows with the population size and number of decision variables. To address this issue, zk-NSGA-II links the proofs of each solver with a chain of hashes, as illustrated in Figure 3. The hash of a population is defined in the following way: ℎ 𝑡 = H 𝑡 ∥ 𝑠 𝑡 ∥ 𝑁 ∥ 𝑛 ∥ x1 ∥ · · · ∥ x 𝑁

(4)

where ∥ denotes concatenation, 𝑠𝑡 is the state of the pseudo-random number generator and x1, . . . , x𝑁 are the decision vectors of 𝑃𝑡 . The objective vectors are deliberately excluded since the guest program can re-compute from the decision variables. In each proof, the guest program receives 𝑃𝑡 as a private input, computes ℎ𝑡 , evolves the population by a single generation and computes the hash of the

(3)

where ⊥ is the empty head of a solver. The objective vector submitted together with the proof is compared against the global front with respect to the non-domination principle. The contract admits 6

Off-chain

Problem Owner

On-chain: Ethereum Solver 𝑖 (address 𝑎𝑖 )

Pareto Front Contract

Groth16 Verifier

deployGroth16Verifier() deployParetoFront(Groth16Verifier, problem, 𝐾 )

G ← ∅, head[·] ← ⊥ loop for each generation 𝑡 = 0, . . . , 𝐺 − 1

run NSGA-II in zkVM on 𝑃𝑡 : (𝜋𝑡 , 𝑜𝑡 ) submit(𝜋𝑡 , 𝑜𝑡 )

verify(𝜋𝑡 , 𝑜𝑡 )

valid / invalid

check 𝑎𝑖 = msg.sender check ℎ𝑡 = head[𝑎𝑖 ]

head[𝑎𝑖 ] ← ℎ𝑡 +1

admit / discard F(x𝑡∗+1 ) in G event admitted / discarded

getFront()

global front G

Figure 2: Sequence diagram of zk-NSGA-II. The problem owner first deploys the Groth16 verifier contract and then the Pareto Front contract for a problem instance. In every generation, a solver runs NSGA-II on its private population in zkVM and submits the resulting proof 𝜋𝑡 together with the public outputs 𝑜𝑡 = (𝑎𝑖 , ℎ𝑡 , ℎ𝑡 +1, F(x𝑡∗+1 )). The Pareto Front contract delegates the proof verification to the Groth16 verifier contract and later checks the solver and the hash chain. It admits or discards the objective vector. The problem owner can read the global front G afterwards.

4.7

resulting population. On-chain, the contract stores only the latest population hash head[𝑎𝑖 ] of every solver 𝑖. After verifying a proof, the contract considers the submission verified only if its previous state hash equals head[𝑎𝑖 ] and then replaces head[𝑎𝑖 ] with the new state hash. A caveat here is that the first submission of a solver can start from an arbitrary state without enforcing an initial starting population. In this way, solvers can explore solutions in distinct regions, improving the diversity of decentralized optimization. However, from then on, every proof must continue exactly where the previous proof ended. The hash chain provides several guarantees for our work. First, a chain clearly corresponds to one uninterrupted NSGA-II run from its genesis population to the final population. Second, it prevents proofs from being replayed or forked since the proofs are rejected when their previous state hash does not match. Third, the privacy of populations is preserved while computations carried out are still verifiable.

From Local Fronts to Global Front

In zk-NSGA-II, every solver 𝑖 maintains its own local front 𝐿𝑖𝑡 offchain while the contract maintains a single global front G that aggregates the contributions of all solvers, as shown in Figure 4. In our design, only one solution x𝑡∗+1 is reported per proof, which leads the global front to be built incrementally. When a verified solution y = F(x𝑡∗+1 ) is submitted by solver 𝑖, the contract updates the global front in the following way: ( G, if ∃ q ∈ G : q ⪯ y G← (5) {q ∈ G : y ⪯̸ q} ∪ {y}, otherwise where q ⪯ y denotes weak dominance. In the first case, the solution is discarded since an existing solution in the global front is at least as good in both objectives. This prevents duplication in the global front as well. In the second case, the solution is admitted and all points it dominates are removed. This update rule preserves that G is always non-dominated. Since the contract compares each submission against every point in the global front, the gas cost of an update grows linearly with |G|. In this design, we therefore 7

Contract

2nd generation in RISC Zero zkVM

3rd generation in RISC Zero zkVM

𝑃1

𝑃2

𝑃3

ℎ 0 = 𝐻 (𝑃 0 )

ℎ 1 = 𝐻 (𝑃 1 )

ℎ 2 = 𝐻 (𝑃 2 )

ℎ 3 = 𝐻 (𝑃 3 )

𝜋0 , F(x∗1 )

Proofs

Solver 𝑖

1st generation in RISC Zero zkVM

𝑃0

𝜋1 , F(x∗2 )

prev = ℎ 0 , curr = ℎ 1

⊥

𝜋 2 , F(x∗3 )

prev = ℎ 1 , curr = ℎ 2

no chain yet

replayed prev = ℎ 1 ≠ head

prev = ℎ 2 , curr = ℎ 3

ℎ1 genesis: any prev allowed

ℎ3

ℎ2 verified:

verified:

prev = head

prev = head

rejected

Figure 3: Hash chain linking the population of a solver 𝑖 with address 𝑎𝑖 across three generations. Off-chain, the solver advances its population by a single generation and submits its proof 𝜋𝑡 , together with the objective vector F(x𝑡∗+1 ) of the selected nondominated solution from its local front. On-chain, the contract maintains the latest state hash for every solver. The first submission starts its chain from an arbitrary state, but every subsequent submission is verified only if its previous state is correct. The state is replaced with the new hash. A mismatched proof is simply rejected. Table 3: Experimental setup parameters, grouped by MOO, proof system, blockchain and hardware. These are the default values used in all experiments unless otherwise stated. The gas and ETH prices are used to convert the measured gas consumption into dollars.

introduce a maximum capacity 𝐾 for the global front, which bounds this cost by 𝑂 (𝐾) per submission. When the front is full, a new solution is admitted only if it removes at least one existing point even if that new solution is non-dominated.

4.8

Randomness in NSGA-II Parameter

NSGA-II is inherently a stochastic algorithm that relies on random numbers for its genetic operators such as the binary tournament selection. However, the guest program of the zkVM has no source of entropy and its execution must be reproducible for verifiability. Therefore, zk-NSGA-II replaces true randomness with a SplitMix64 pseudo-random number generator [36]. The hash chain also provides integrity of the random numbers of every generation and hence, a solver cannot re-run a generation with different random numbers and submit only the most favorable one. Any different random state would generate a different ℎ𝑡 that the contract rejects. However, the seed itself can be chosen freely at the genesis generation just as the initial population. This enables different solvers to have different seeds to improve population diversity. Similarly, the reported solution x𝑡∗+1 on the local front is drawn from the generator state 𝑠𝑡 +1 , which is part of ℎ𝑡 +1 .

5

Value

Multi-objective optimization Population size 𝑁 50 Number of solvers 𝑆 10 Global front capacity 𝐾 100 Generations 𝐺 250 (ZDT, DTLZ); 1000 (Hang Seng)

Experimental Setup

The experiments in this work are specifically designed to evaluate zk-NSGA-II from multiple perspectives. First, zk-NSGA-II is applied to the well-known synthetic benchmark problems with known Pareto fronts to evaluate the correctness of the verifiable execution and the quality of the fronts. Second, it is applied to a realworld portfolio optimization problem to understand the relations of the local fronts with the global front and to measure the cost of verifiability both off-chain and on-chain. Table 3 provides the key parameters and their values where all experiments are carried out on an Apple MacBook Air M2 with 8 cores and 8 GB RAM.

Proof system zkVM Proof type State hash 𝐻 (·)

RISC Zero 3.0.6 Groth16 SHA-256

Blockchain Smart contracts Proof verifier Gas price ETH price Execution environment

Solidity 0.8.26 RISC Zero Groth16 verifier 10 gwei 2,221 dollars (30 October 2026) Anvil, Foundry 1.8.5 [37]

Hardware Machine

Apple MacBook Air M2, 8 cores, 8 GB RAM

5.1

Benchmark Problems

We first evaluate the correctness of our zk-NSGA-II implementation on two popular synthetic test suites of ZDT [38] and DTLZ [39], resulting in twelve two-objective problems in total. The problems are scalable in terms of real-valued decision variables with analytically-known Pareto fronts, which allows the quality of the found fronts to be measured exactly against the true front. The 8

Solver 1 (off-chain) 𝑓2

𝑓1 submissions

(𝜋𝑡 , F(x𝑡∗+1 ) )

Solver 2 (off-chain)

Global front G (on-chain)

𝑓2

𝑓2

𝑓1

Smart contract (on-chain) 1. verify proof 𝜋𝑡 2. check hash chain 3. admit F(x𝑡∗+1 ) if no point in G dominates it 4. remove points it dominates 5. keep capacity as | G | ≤ 𝐾

admit or discard

.. .

𝑓1

Solver 𝑆 (off-chain)

global front

removed (dominated)

newly admitted

newly discarded

𝑓2

𝑓1

Figure 4: Aggregation of the local fronts of multiple solvers into a single global front on-chain. Off-chain, each solver evolves its population and maintains its own local front (filled gray) where the dominated solutions are shown as hollow circles. From the local front, one solution x𝑡∗+1 (large black) is reported per proof. Each solver submits the objective vector F(x𝑡∗+1 ) together with the proof 𝜋𝑡 while decision variables always remain private. The smart contract verifies the proof, checks the hash chain and admits the point to the global front G only if no point of G dominates it. The points dominated by that newly admitted point are also removed. A submission that is dominated by the global front is discarded. If a front reaches its capacity 𝐾, it admits the point only if it dominates at least one existing point. 5.1.2 DTLZ Suite. The DTLZ problems [39] are instantiated with two objectives in this work. In each problem, the first decision variable 𝑥 1 determines the position of a solution along the Pareto front and a distance function 𝑔 of the remaining variables controls the proximity to the front. As in ZDT, the DTLZ problems pose different sorts of difficulties: DTLZ1 has a linear Pareto front with a multi-modal distance function; DTLZ2 has a non-convex front; DTLZ3 combines the front of DTLZ2 with the multi-modal distance function of DTLZ1; DTLZ4 moves the density of solutions to the extremes of the front; DTLZ6 biases the distance function and DTLZ7 has a disconnected front. DTLZ5 differs from DTLZ2 only in the mapping of the position angles 𝜃 2, . . . , 𝜃𝑚−1 , which do not exist for 𝑚 = 2 objectives. Therefore, DTLZ5 reduces to DTLZ2 in our two-objective setting. We still include DTLZ5 to cover the complete DTLZ1–DTLZ7 suite. The definitions of these seven problems are given in Table 8 in Appendix B.

problems are chosen to span a broad range of characteristics such as convex, non-convex and disconnected fronts. Complementing these two synthetic benchmarks, we also establish a case study for a real-world portfolio optimization problem in Section 5.2.

5.1.1 ZDT Suite. The ZDT problems [38] are among the most widely used benchmarks for two-objective optimization. Each problem is constructed from three functions: the first objective 𝑓1 depends only on the first decision variable 𝑥 1 ; a distance function 𝑔 controls the proximity to the Pareto front; and the second objective 𝑓2 depends on 𝑓1 and 𝑔. The problems in ZDT pose different sorts of difficulty to handle: ZDT1 has a convex Pareto front; ZDT2 has a non-convex front; ZDT3 has a front with five disconnected segments; ZDT4 has the same front as ZDT1 but a multi-modal distance function; and ZDT6 has a non-convex front with a non-uniform density of solutions. ZDT5 is excluded since it is defined over binary decision variables, rather than real-valued variables. The definitions of these five problems are given in Table 7 in Appendix B. 9

5.2

Hang Seng Portfolio Problem

in objective space. Then, the spacing is: v u t |P| ∑︁
2 1 𝑑¯ − 𝑑𝑖 SS(P) = |P | − 1 𝑖=1

To evaluate zk-NSGA-II beyond the synthetic benchmarks, we consider the Hang Seng portfolio optimization problem [40] where an investor distributes a total capital into 𝑛 different assets to minimize risk while maximizing expected return. We believe that this problem is a natural fit for privacy-preserving collaborative optimization since the portfolio weights represent a confidential investment strategy while the risk and return of a portfolio are necessary for comparison. With zk-NSGA-II, the solvers can prove that the reported risk and return belong to a portfolio produced by NSGA-II without disclosing its weights. In the problem, each decision variable 𝑥 𝑗 ∈ [0, 1] is mapped to a portfolio weight with normalization: 𝑥𝑗 𝑤 𝑗 (x) = Í𝑛

,

𝑗 = 1, . . . , 𝑛

where 𝑑¯ is the mean distance. Lower SS values mean better solution distribution on a front. 5.3.3 Inverted Generational Distance (IGD). The inverted generational distance takes the average distance from each point of a true front P ∗ to the nearest solution of a found front P [44]: 1 ∑︁ min ∥z − p∥ 2 (9) IGD(P, P ∗ ) = ∗ |P | z∈ P ∗ p∈ P

(6)

where p refers to an individual solution on P. This measure requires the true front to be known in advance. In our work, both synthetic problems and the portfolio problem satisfy this requirement.

𝑙=1 𝑥𝑙

Í

where 𝑤 𝑗 ≥ 0 and 𝑗 𝑤 𝑗 = 1. Given the vector of mean asset returns 𝝁 and their covariance matrix 𝚺, the two objectives are:

5.3.4 Hypervolume Ratio (HVR). The hypervolume ratio (HVR) normalizes the hypervolume of a found front P with the hypervolume of the true front P ∗ [45]:

min 𝑛 𝑓1 (x) = w(x) ⊤ 𝚺 w(x)

x∈ [0,1]

min 𝑛 𝑓2 (x) = −𝝁 ⊤ w(x)

(7)

x∈ [0,1]

HVR(P) =

where 𝑓1 is the variance of the portfolio return, which measures its risk and 𝑓2 is the negative expected return, so that maximizing the return corresponds to minimizing 𝑓2 . Both objectives are thus minimized simultaneously.

HV(P, r) HV(P ∗, r) (10)

©Ø ª HV(𝐴, r) = 𝜆 ­ {y ∈ R2 : p ⪯ y ⪯ r}® «p∈𝐴 ¬ where HV(𝐴, r) is the area of the objective space between the set 𝐴 and the reference point r while 𝜆 denotes the Lebesgue measure. A higher HVR is better where a value of one means that the found front covers the same area as the true front. In our implementation, the reference point is placed 10% beyond the nadir point, which is the point of the worst objective values on the true front.

5.2.1 Hang Seng Dataset. The portfolio optimization problem in our work is instantiated with the Hang Seng dataset [40] from the OR-Library [41], which is widely used as a benchmark for portfolio optimization. The dataset has 31 assets of the Hang Seng index of Hong Kong, with weekly price data from March 1992 to September 1997 and 291 return observations per asset. For each asset, it provides the mean weekly return 𝜇 𝑗 , ranging from 0.000141 to 0.010865 and the standard deviation of the return 𝜎 𝑗 , ranging from 0.0358 to 0.0691. The dataset includes the efficient frontier of the problem, which serves as the true Pareto front P ∗ for our performance measures.

5.3

(8)

5.3.5 zkVM Cycles. The computational cost of a proof is measured with the number of cycles that zkVM needs to execute. For this metric, cycles are first measured for a single generation proof and then reported after the decomposition into individual evolutionary phases such as non-dominated sorting. 5.3.6 Proving Time. The proving time is the wall-clock time to generate a Groth16 proof for a single generation, including the internal STARK proving of the execution and its compression into Groth16. Although the RISC Zero zkVM provides three alternative proof types as composite, succinct and Groth16 [10], this work considers only Groth16 since it is the only proof type that can be verified on-chain at a constant cost.

Performance Measures

The performance of zk-NSGA-II is measured from three complementary perspectives. For the optimization perspective, four measures are used based on local and global fronts. For the ZKP perspective, four additional measures are considered by relying on only offchain computation and size. Lastly, for the blockchain perspective, gas consumption of individual contract functions is measured. The performance measures are briefly defined as:

5.3.7 Verification Time. The verification time is the wall-clock time to verify a proof off-chain. It is reported as the average of multiple consecutive verifications. Note that on-chain verification is evaluated differently through blockchain gas consumption.

5.3.1 Number of Non-Dominated Solutions (NS). The number of non-dominated solutions counts the solutions in the first nondominated front [42]. It is bounded by the population size 𝑁 for a local front and by the capacity 𝐾 for the global front. Greater NS refers to a wider set of non-dominated solutions.

5.3.8 Proof Size. The proof size is the size of the Groth16 proof in bytes, which is submitted to the blockchain together with the public outputs of the off-chain computation. Since a Groth16 proof consists of a fixed number of elliptic curve points, its size is constant regardless of the population size, the number of decision variables and the length of the execution.

5.3.2 Schott’s Spacing (SS). Schott’s spacing measures how evenly the solutions are distributed on a front [43]. Let 𝑑𝑖 be the Manhattan distance from the 𝑖th solution of a front P to its nearest neighbor 10

5.3.9 Blockchain Gas Consumption. Gas consumption measures the on-chain gas costs of smart contract functions. It is measured from the receipts of transactions executed on a local Ethereum blockchain. Since gas prices and exchange rates fluctuate constantly, gas consumption is converted into ETH and US dollars with 10 gwei per unit of gas and an ETH price of 2,221 US dollars as of 30 October 2026. The cost of a function is therefore its gas consumption multiplied by the gas price and the ETH price.

6

the generations. For instance, the global front reaches an HVR of 0.9 on ZDT2 at generation 89 while the mean local front needs 130 generations. Similarly, it needs 124 versus 193 generations on DTLZ1, 176 versus 230 on ZDT4, and 33 versus 92 on DTLZ6. This favors the problem owner who gets a front close to the best solver at every generation without knowing who will perform best.

6.2

Experimental Results

This section reports the results of the experiments. Section 6.1 first validates that zk-NSGA-II produces correct results on the ZDT and DTLZ problems with known fronts. Section 6.2 examines the aggregation of the local fronts of the solvers into the global front on-chain. Sections 6.3 and 6.4 quantify the cost of verifiability both off-chain and on-chain. Finally, Section 6.5 presents the results of zk-NSGA-II on the portfolio optimization case study.

6.1

Aggregation of Local Fronts to Global Front

This section discusses the empirical findings of aggregating multiple local fronts off-chain into a single global front on-chain. The aggregation compensates for the solvers that fail. The global front outperforms the best local front on ten of the twelve problems. The global front reaches an HVR of 0.9922 on ZDT1 and 0.9950 on DTLZ7 while the best local fronts reach 0.9869 and 0.9913 in Table 4. The first of the exceptions is ZDT4 where the global front (0.9766) and the best local front (0.9769) are nearly equal. The second one is DTLZ3 where the global front (0.2475) exceeds the mean local front (0.0422) but falls short of the best local front (0.2910). The solvers start from populations at different regions of the available search space. Not all the solvers are lucky enough to start from or reach promising regions. Hence, the front aggregation compensates for these solvers by using the well-performing ones. Currently, nothing prevents independent solvers from exploring overlapping regions, which might partially waste their effort. Such coordination among the solvers is left for future work. The acceptance rate decreases over generations. The acceptance rate of submissions to the global front is between 21.6% and 62.4% in the first 25 generations and between 0.0% and 19.2% in the last 25 generations in Table 4. ZDT6 and DTLZ6 admit no submission at all in the last 25 generations. At the early generations, the global front is sparse where most submissions are likely to be non-dominated. However, at the later generations, the global front is full and close to the true front where solutions are admitted only if they dominate the existing ones. Therefore, especially the problems that are still converging keep the highest late acceptance such as DTLZ3 with 19.2% and ZDT4 with 12.4%. This builds an interesting connection between the acceptance rate and the convergence of the global front. The acceptance rate and the global front size over generations are given in Figures 10 and 11 in Appendix C. In addition, this might motivate early solution submissions and discourage solvers to join late.

Performance on ZDT and DTLZ Problems

This section evaluates zk-NSGA-II on the ZDT and DTLZ problems with known Pareto fronts. For this experiment, we execute NSGA-II as the guest program natively. The local fronts converge to the true Pareto fronts on all problems except DTLZ3 and DTLZ4. As shown in Table 4, the local fronts reach mean HVR values between 0.9511 and 0.9938 on the remaining ten problems. On eight of them, the mean IGD stays between 0.0066 and 0.0125 with the HVR standard deviation of at most 0.0082. The two exceptions are ZDT4 and DTLZ7 with the high standard deviations of IGD (0.0287±0.0193 and 0.0544±0.1372) and HVR (0.9511 ± 0.0255 and 0.9636 ± 0.0851). The number of nondominated solutions reaches 50 on all ten problems except ZDT4 (47.5 ± 7.9). Schott’s spacing is between 0.0093 and 0.0196, which indicates that the solutions are evenly spread along the fronts, as shown in Figure 5. Note that DTLZ5 yields the same values as DTLZ2 since the two problems have the same two objectives. This experiment validates the correctness of zk-NSGA-II on the zkVM. DTLZ3 and DTLZ4 remain hard to solve due to the known difficulties of these problems. In DTLZ3, the multi-modal function traps the populations in local fronts with the mean IGD of 2.4067 ± 1.4631 and the HVR of 0.0422 ± 0.0966. In DTLZ4, the density bias maps most values of 𝑥 1 to the extremes of the front with the mean IGD of 0.5989 ± 0.3097 and the HVR of 0.4023 ± 0.3015. These high standard deviations imply that the results of individual problem solvers depend on the initial population and the random seed since they all execute the same zk-NSGA-II program. These problems also motivate further collaboration among solvers such as privacy-preserving solution sharing. The global front converges faster than the average solver. Figures 6 and 7 show how the global front and the local fronts evolve over the generations for the twelve synthetic problems. Figure 6 plots the HVR of the global front together with the mean HVR of the local fronts while the shaded area indicates the minimum and the maximum HVR bounds among all the solvers. Figure 7 plots the IGD of the global front and the mean IGD of the local fronts. On every problem, it is observed that the global front is at least as good as the mean local front in both HVR and IGD in most of

6.3

Off-Chain Proof Generation Cost

This section presents the empirical findings of generating a single zk-NSGA-II proof off-chain. Note that the zkVM cycles in this experiment count the RISC-V instructions that the guest program Γ executes inside the zkVM (i.e., cost of proving) while the native CPU time measures the same generation directly on the host CPU without proving (i.e., cost of computation itself). Objective evaluation dominates the proof generation cost in the zkVM while NSGA-II-native genetic operators remain relatively cheap. For the Hang Seng portfolio problem shown in Figure 8, objective evaluation accounts for 74.07% of the zkVM cycles but only 17.05% of the native CPU time. On the other hand, non-dominated sorting decreases from 20.12% of the native time to 5.16% of the cycles and chain hashing from 40.31% to 0.36%. While 11

Table 4: Quality of the local fronts and the global front at generation 𝐺 = 250 for the ZDT and DTLZ problems. Each problem is solved by 𝑆 = 10 solvers with population size 𝑁 = 50 and a global front capacity of 𝐾 = 100. Arrows indicate whether higher (↑) or lower (↓) values are better. The acceptance rate is the share of submissions admitted to the global front. Local fronts

Global front

Acceptance rate (%)

Problem

NS ↑

SS ↓

IGD ↓

HVR ↑

Max HVR ↑

NS

IGD ↓

HVR ↑

All

First 25

Last 25

ZDT1 ZDT2 ZDT3 ZDT4 ZDT6 DTLZ1 DTLZ2 DTLZ3 DTLZ4 DTLZ5 DTLZ6 DTLZ7

50.0 ± 0.0 50.0 ± 0.0 50.0 ± 0.0 47.5 ± 7.9 50.0 ± 0.0 50.0 ± 0.0 50.0 ± 0.0 26.0 ± 15.1 11.2 ± 20.5 50.0 ± 0.0 50.0 ± 0.0 50.0 ± 0.0

0.0163 ± 0.0021 0.0149 ± 0.0021 0.0196 ± 0.0018 0.0187 ± 0.0088 0.0171 ± 0.0008 0.0093 ± 0.0010 0.0169 ± 0.0026 0.2966 ± 0.2958 0.0056 ± 0.0087 0.0169 ± 0.0026 0.0194 ± 0.0023 0.0159 ± 0.0038

0.0100 ± 0.0006 0.0102 ± 0.0007 0.0114 ± 0.0004 0.0287 ± 0.0193 0.0103 ± 0.0007 0.0066 ± 0.0014 0.0106 ± 0.0005 2.4067 ± 1.4631 0.5989 ± 0.3097 0.0106 ± 0.0005 0.0125 ± 0.0005 0.0544 ± 0.1372

0.9853 ± 0.0009 0.9763 ± 0.0020 0.9938 ± 0.0004 0.9511 ± 0.0255 0.9750 ± 0.0015 0.9667 ± 0.0082 0.9752 ± 0.0016 0.0422 ± 0.0966 0.4023 ± 0.3015 0.9752 ± 0.0016 0.9721 ± 0.0013 0.9636 ± 0.0851

0.9869 0.9790 0.9947 0.9769 0.9778 0.9746 0.9771 0.2910 0.9755 0.9771 0.9750 0.9913

100 100 100 100 100 100 100 13 100 100 100 100

0.0053 0.0059 0.0061 0.0115 0.0076 0.0037 0.0058 0.2071 0.0060 0.0058 0.0095 0.0059

0.9922 0.9879 0.9968 0.9766 0.9818 0.9816 0.9878 0.2475 0.9854 0.9878 0.9793 0.9950

30.4 22.7 37.2 22.5 12.2 19.8 21.5 13.5 13.6 21.5 9.0 24.8

50.0 34.8 53.2 21.6 45.6 34.4 62.4 33.6 24.0 62.4 49.6 46.0

5.6 4.8 3.6 12.4 0.0 6.4 5.6 19.2 2.8 5.6 0.0 4.4

Table 5: Proof generation and off-chain verification of a single generation of ZDT1. Proving is split into the STARK proving of the execution and compression into a Groth16 proof.

crossover/mutation takes 16.94% of the cycles, crowding distance and survivor selection together stay under 1%. The issue here is that the zkVM has no support for floating-point unit, which therefore must be emulated over many cycles. In this regard, the quadratic form of the portfolio variance with multiple multiplications and additions results in most of the cycles. Non-dominated sorting performs only comparisons, which is cheaper. Overall, the objective functions of the problem being solved are of critical importance in terms of zkVM cycles. Generating a single proof takes about half an hour, whereas verifying it takes only milliseconds regardless of computation. As Table 5 shows, a ZDT1 generation executes in 8.43 × 106 cycles with 9.44 × 106 proving cycles. Generating a single Groth16 proof takes 1,947.8 s in total while verifying the STARK and Groth16 proofs off-chain takes only 11.61 ms and 2.84 ms, respectively. Note that the Groth16 proof here makes the on-chain verification very affordable since the STARK proof is around 222,668 B while the Groth16 proof is just 260 B. In addition, hash-heavy verification of the STARK proof is too expensive for the EVM. Compression to Groth16 therefore enables the verifier contract to accept and verify this succinct proof on-chain. Overall, despite the expensive computation needed to be executed by the prover, the verifier is responsible for checking only a constant-size proof.

6.4

Measure Execution zkVM cycles Proving cycles

Value 8.43 × 106 9.44 × 106

Proof generation STARK proving to succinct receipt Compression to Groth16 Total proving time

1,763.5 s 184.3 s 1,947.8 s

Proof size Succinct STARK proof Groth16 proof

222,668 B 260 B

Off-chain verification Succinct STARK proof Groth16 proof

11.61 ms 2.84 ms

the consumption might increase due to the removal of dominated solutions from the front. Overall, the proof system rather than the optimization problem is the critical factor for the on-chain cost of verifiability. This implies that the harder problems might be more expensive to prove off-chain but not to verify on-chain. Deployment is a one-time cost and reading the global front is free. Deploying the Groth16 Verifier and the Pareto Front contract consumes 1,179,986 and 720,797 gas, respectively. The problem owner needs to pay around 42.22 dollars in total per problem. Reading the global front through getFront is an off-chain call that consumes no gas at all. However, the 28,322 gas is necessary when another contract reads it within another transaction. From a system perspective, suppose a scenario with 𝑆 = 10 solvers for 𝐺 = 250 generations. A ZDT1 run results in 2,500 submissions with around 1,940 dollars per solver, which is quite expensive for most practical applications. Here, the number of generations a solver participates in determines the main cost of on-chain verifiability.

On-Chain Proof Verification Cost

This section discusses the results of verifying a zk-NSGA-II proof onchain. The gas consumption is measured from transaction receipts on a local Ethereum node. The conversion rates from gas units to ETH and USD are set to 10 gwei and 2,221 dollars, respectively. Proof submission takes a fixed gas consumption regardless of the NSGA-II computation behind the proof. As shown in Table 6, a submit transaction for ZDT1 consumes 348,961 gas (around 0.0035 ETH and 7.75 dollars). The Groth16 verification alone consumes 250,960 gas, accounting for 71.9% of the submission. The remaining 98,001 gas consumption includes additional checks such as for hash chain or admission to the global front. For the sake of simplicity and reproducibility, we intentionally measure consumption on an empty global front to determine the lower bound. On the global front with multiple non-dominated solutions, 12

True Pareto front

Local fronts

0.8

0.8

f2

0.4

0.4

0.0

0.0 0.4

f1

0.8

0.4

f1

0.8

(e) ZDT6

0.2

f1

0.4

f1

0.8

5.0

2.5

0.0 0.0

0.4

(d) ZDT4

f2

0.0 0.9

f1

0.4

0.2

0.0

0.0

0.8

0.8

f2

f2

0.4

0.4

(c) ZDT3

0.4

f1

0.0 0.0

(b) ZDT2

0.8

0.6

0.4

−0.8

0.0

(a) ZDT1

0.3

0.0

f2

0.0

f2

0.8

f2

f2

0.8

Global front

0.0 0.0

(f) DTLZ1

0.4

f1

0.8

0.0

(g) DTLZ2

2.5

f1

5.0

(h) DTLZ3 4.0

0.8

0.4

0.4

0.4

0.0

0.0

0.0

0.0

0.4

f1

0.8

(i) DTLZ4

3.2

f2

f2

f2

0.8

0.0

0.4

f1

0.8

f2

0.8

2.4 0.0

(j) DTLZ5

0.4

f1

(k) DTLZ6

0.8

0.0

0.4

f1

0.8

(l) DTLZ7

Figure 5: Final fronts of zk-NSGA-II at the last generation 𝐺 = 250 for the twelve ZDT and DTLZ problems, each with 𝑆 = 10 solvers of population size 𝑁 = 50 and a global front capacity of 𝐾 = 100. Each panel plots the two objectives 𝑓1 and 𝑓2 and overlays the known true Pareto front, the local fronts of the solvers kept off-chain (hollow gray circles) and the global front on-chain from their submissions (filled black circles).

6.5

Portfolio Case Study

the HVR of 0.978 at generation 1000. With a similar trend, the IGD of the global front ends at 9.54 × 10−4 while the mean IGD of the local fronts falls to 8.5 × 10−5 . Recall that once the global front is full, the contract admits a new solution only if it removes at least one dominated solution in our design. Portfolios that extend the front to the higher risk and the higher return are essentially nondominated but dominate no solutions at the global front, resulting in being discarded without admission. Of the 8,030 submissions from generation 198 on, 4,147 (i.e., 51.6%) are discarded because the global front is full and only 276 are admitted. This has two implications. First, the capacity favors the first-come admission.

In this experiment, we apply zk-NSGA-II to the real-world problem of the Hang Seng portfolio optimization with 𝑆 = 10 solvers, 𝑁 = 50 portfolios per solver and 𝐺 = 1000 generations. The global front outperforms the local fronts at the early generations but stalls once it reaches its capacity. As shown in Figure 9, the global front reaches an HVR of 0.542 at generation 100 and 0.658 at generation 250 while the mean local front reaches 0.486 and 0.595, respectively. However, the global front fills its capacity of 𝐾 = 100 solutions at generation 198 and its HVR stalls at 0.718 after generation 500. The local fronts keep converging to 13

Local fronts (mean)

Local fronts (min-max)

0.4

0.4

0.4

0.0

0.0

0.0 0

200

(a) ZDT1

100

Generation

200

(b) ZDT2

200

(e) ZDT6

100

Generation

200

Generation

(i) DTLZ4

200

100

Generation

200

0.0 0

(j) DTLZ5

200

0.4

0.0 0

100

Generation

0.8

0.4

0.0 100

0

(h) DTLZ3

HV ratio ( ↑ )

0.4

0.0

200

0.8

HV ratio ( ↑ )

HV ratio ( ↑ )

0.4

100

Generation

(g) DTLZ2

0.8

0

0.0 0

(f) DTLZ1

0.8

200

0.4

0.0 0

100

Generation

0.8

0.4

0.0 100

Generation

0

(d) ZDT4

HV ratio ( ↑ )

0.4

0.0

200

0.8

HV ratio ( ↑ )

0.4

100

Generation

(c) ZDT3

0.8

HV ratio ( ↑ )

0.8

0

0.0 0

HV ratio ( ↑ )

100

Generation

0.4

HV ratio ( ↑ )

0

0.8

HV ratio ( ↑ )

HV ratio ( ↑ )

HV ratio ( ↑ )

0.8

HV ratio ( ↑ )

0.8

0.8

Global front

100

Generation

(k) DTLZ6

200

0

100

Generation

200

(l) DTLZ7

Figure 6: Convergence of the HVR over the 𝐺 = 250 generations for the twelve ZDT and DTLZ problems with 𝑆 = 10 solvers. The black line is the HVR of the on-chain global front, the gray line is the mean HVR of the 10 off-chain local fronts and the shaded area spans the minimum and maximum HVR among the solvers at each generation. solutions with 𝐺 = 250 generations. Hence, careful selection of the capacity parameter for the problem being solved is critical.

Second, the capacity introduces a trade-off between efficiency in gas consumption (since on-chain solution comparison would increase otherwise) and global front quality. The problem owner receives a verified but incomplete frontier. Each problem solver evolves its own population, converging to the true efficient frontier as in Figure 9a while it is not true for the global front. Over all 10,000 submissions, only 849 (8.5%) are admitted and all admissions are verified for an honest NSGA-II execution against solution fabrication. This differs from the ZDT and DTLZ problems (Section 6.2) since the global front fills its capacity in 11 of the 12 problems and their true fronts are covered well by 𝐾 = 100

7

Conclusion

This work addresses the problem of verifiable, privacy-preserving and collaborative MOO on blockchain where mutually distrusting solvers contribute their solutions. In this regard, a novel zk-NSGA-II protocol is proposed, which executes NSGA-II inside a zkVM and certifies each evolutionary generation with a succinct proof that is later verified on-chain. In the protocol, the solvers privately maintain their own populations with decision variables and off-chain Pareto fronts, which are aggregated into a single global Pareto front 14

10

10

−1

10

−2

0

10

−1

10

−2

10

IGD ( ↓ )

0

IGD ( ↓ )

IGD ( ↓ )

10

Local fronts (min-max)

Global front

0

10

10

−1

10

−2

10

200

0

10

0

10

−1

10

−2

10

100

Generation

10

−1

0

(e) ZDT6

10

−2

10 0

100

Generation

(i) DTLZ4

200

0

100

Generation

200

(d) ZDT4

−1

−2

0

200

(f) DTLZ1

10

3

10

2

100

Generation

10

1

10

0

0

200

(g) DTLZ2

−1

IGD ( ↓ )

IGD ( ↓ )

IGD ( ↓ )

10

100

Generation

0

10

200

1

200

−1

100

Generation

(c) ZDT3

10 0

10

0

IGD ( ↓ )

10

200

(b) ZDT2

IGD ( ↓ )

IGD ( ↓ )

(a) ZDT1

100

Generation

−1

IGD ( ↓ )

100

Generation

10

1

10

0

10

−1

10

−2

10

100

Generation

200

0

(j) DTLZ5

100

Generation

(k) DTLZ6

200

200

0

10

−1

10

−2

−2

0

100

Generation

(h) DTLZ3

IGD ( ↓ )

0

1

IGD ( ↓ )

Local fronts (mean)

0

100

Generation

200

(l) DTLZ7

Figure 7: Convergence of the IGD over the 𝐺 = 250 generations for the twelve ZDT and DTLZ problems with 𝑆 = 10 solvers. The black line is the IGD of the on-chain global front and the gray line is the mean IGD of the 10 off-chain local fronts.

References

on-chain. Population states are linked through hash chains, which guarantees that transitions from the current populations to the next populations are carried out by NSGA-II. The correctness of the protocol is first assessed on the ZDT and DTLZ benchmarks with known Pareto fronts. Further, the feasibility of the protocol is shown on the real-world problem of the Hang Seng portfolio optimization. The performance is measured from three complementary perspectives of optimization, ZKP and blockchain with nine different metrics. The experimental measurements indicate that the privacy-preserving collaborative optimization based on NSGA-II is feasible with the existing zero-knowledge and blockchain technologies. However, the cost of proof generation is clearly visible as the primary bottleneck for further adoption.

[1] Kalyanmoy Deb, Amrit Pratap, Sameer Agarwal, and T. Meyarivan. A fast and elitist multiobjective genetic algorithm: NSGA-II. IEEE Transactions on Evolutionary Computation, 6(2):182–197, 2002. [2] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system. https://bitcoin. org/bitcoin.pdf, 2008. [3] Vitalik Buterin. Ethereum: A next-generation smart contract and decentralized application platform. https://ethereum.org/whitepaper, 2014. [4] Naoki Shibata. Proof-of-search: Combining blockchain consensus formation with solving optimization problems. IEEE Access, 7:172994–173006, 2019. [5] Matthias Fitzi, Aggelos Kiayias, Giorgos Panagiotakos, and Alexander Russell. Ofelimos: Combinatorial optimization via proof-of-useful-work. In Advances in Cryptology – CRYPTO 2022, volume 13508 of Lecture Notes in Computer Science, pages 339–369. Springer, 2022. [6] Francesco Bizzaro, Mauro Conti, and Maria Silvia Pini. Proof of evolution: Leveraging blockchain mining for a cooperative execution of genetic algorithms. In 2020 IEEE International Conference on Blockchain (Blockchain), pages 450–455, 2020. 15

Table 6: Gas consumption of the contract functions for ZDT1, converted with a gas price of 10 gwei and an ETH price of 2,221 dollars (as of 30 October 2026). Function

Gas

ETH

USD

Deployment by the problem owner (once per problem) Groth16 verifier contract Pareto Front contract

1,179,986 0.0118 26.21 720,797 0.0072 16.01

Submission by a solver (once per generation) submit: proof verification, solver and hash-chain checks and global front update verify: Groth16 proof verification only

348,961 0.0035 250,960 0.0025

7.75 5.57

Reading the global front (free as an off-chain call) getFront: all solutions of G size: number of solutions in G

28,322 23,387

0.63 0.52

Native CPU time

[14] Kalyanmoy Deb. Multi-Objective Optimization Using Evolutionary Algorithms. John Wiley & Sons, Chichester, UK, 2001. [15] Goshgar Ismayilov and Haluk Rahmi Topcuoglu. Dynamic multi-objective workflow scheduling for cloud computing based on evolutionary algorithms. In 2018 IEEE/ACM International Conference on Utility and Cloud Computing Companion (UCC Companion), pages 103–108. IEEE, 2018. [16] Goshgar Ismayilov and Haluk Rahmi Topcuoglu. Neural network based multiobjective evolutionary algorithm for dynamic workflow scheduling in cloud computing. Future Generation Computer Systems, 102:307–322, 2020. [17] Goshgar Ismayilov and Can Özturan. PTTS: Zero-knowledge proof-based private token transfer system on Ethereum blockchain and its network flow based balance range privacy attack analysis. Journal of Network and Computer Applications, 233:104045, 2025. [18] Jun Sakuma and Shigenobu Kobayashi. A genetic algorithm for privacy preserving combinatorial optimization. In Proceedings of the 9th Annual Conference on Genetic and Evolutionary Computation (GECCO), pages 1372–1379, 2007. [19] Daniel Funke and Florian Kerschbaum. Privacy-preserving multi-objective evolutionary algorithms. In Parallel Problem Solving from Nature – PPSN XI, volume 6239 of Lecture Notes in Computer Science, pages 41–50. Springer, 2010. [20] Jinjin Xu, Yaochu Jin, Wenli Du, and Sai Gu. A federated data-driven evolutionary algorithm. Knowledge-Based Systems, 233:107532, 2021. [21] Jinjin Xu, Yaochu Jin, and Wenli Du. A federated data-driven evolutionary algorithm for expensive multi-/many-objective optimization. Complex & Intelligent Systems, 7(6):3093–3109, 2021. [22] Sebastian Angel, Andrew J. Blumberg, Eleftherios Ioannidis, and Jess Woods. Efficient representation of numerical optimization problems for SNARKs. In 31st USENIX Security Symposium (USENIX Security 22), pages 4273–4290, 2022. [23] Jens Groth. On the size of pairing-based non-interactive arguments. In Advances in Cryptology – EUROCRYPT 2016, volume 9666 of Lecture Notes in Computer Science, pages 305–326. Springer, 2016. [24] Jason Teutsch and Christian Reitwießner. A scalable verification solution for blockchains. In Lecture Notes Series, Institute for Mathematical Sciences, National University of Singapore, pages 377–424. World Scientific, 2023. [25] Ahmed Kosba, Andrew Miller, Elaine Shi, Zikai Wen, and Charalampos Papamanthou. Hawk: The blockchain model of cryptography and privacy-preserving smart contracts. In 2016 IEEE Symposium on Security and Privacy (SP), pages 839–858, 2016. [26] Jacob Eberhardt and Stefan Tai. ZoKrates – scalable privacy-preserving off-chain computations. In 2018 IEEE International Conference on Internet of Things (iThings), Green Computing and Communications (GreenCom), Cyber, Physical and Social Computing (CPSCom) and Smart Data (SmartData), pages 1084–1091, 2018. [27] Tiancheng Xie, Jiaheng Zhang, Zerui Cheng, Fan Zhang, Yupeng Zhang, Yongzheng Jia, Dan Boneh, and Dawn Song. zkBridge: Trustless cross-chain bridges made practical. In Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security (CCS), pages 3003–3017, 2022. [28] Milan Todorović, Luka Matijević, Dušan Ramljak, Tatjana Davidović, Dragan Urošević, Tatjana Jakšić Krüger, and Ðorđe Jovanović. Proof-of-useful-work: BlockChain mining by solving real-life optimization problems. Symmetry, 14(9):1831, 2022. [29] Weihang Cao, Xintong Ling, Jiaheng Wang, Xiqi Gao, and Zhi Ding. Optimizationbased proof of useful work: Framework, modeling, and security analysis. arXiv preprint arXiv:2405.19027, 2024. [30] Qing Yang, Hao Wang, Taotao Wang, Shengli Zhang, Xiaoxiao Wu, and Hui Wang. Blockchain-based decentralized energy management platform for residential distributed energy resources in a virtual power plant. Applied Energy, 294:117026, 2021.

zkVM cycles

objective evaluation crossover/mutation non-dominated sorting input validation chain hashing crowding distance survivor selection 0

20

40

0.0003 0.0002

60

Share of cost (%)

Figure 8: Share of the zkVM cycles and the native CPU time of each algorithm component in a single proven generation of the Hang Seng portfolio problem. Filled circles give the share of zkVM cycles (i.e., the cost of proving) and hollow circles give the share of native CPU time on the host without proving (i.e., the cost of the computation itself).

[7] Shafi Goldwasser, Silvio Micali, and Charles Rackoff. The knowledge complexity of interactive proof systems. SIAM Journal on Computing, 18(1):186–208, 1989. [8] Eli Ben-Sasson, Alessandro Chiesa, Eran Tromer, and Madars Virza. Succinct non-interactive zero knowledge for a von Neumann architecture. In 23rd USENIX Security Symposium (USENIX Security 14), pages 781–796, 2014. [9] Eli Ben-Sasson, Iddo Bentov, Yinon Horesh, and Michael Riabzev. Scalable, transparent, and post-quantum secure computational integrity. Cryptology ePrint Archive, Paper 2018/046, 2018. [10] Jeremy Bruestle, Paul Gafni, and RISC Zero Team. RISC Zero zkVM: Scalable, transparent arguments of RISC-V integrity. https://dev.risczero.com/proofsystem-in-detail.pdf, 2023. Draft, August 11, 2023. [11] Tianyi Liu, Xiang Xie, and Yupeng Zhang. zkCNN: Zero knowledge proofs for convolutional neural network predictions and accuracy. In Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security (CCS), pages 2968–2985, 2021. [12] Bing-Jyue Chen, Suppakit Waiwitlikhit, Ion Stoica, and Daniel Kang. ZKML: An optimizing system for ML inference in zero-knowledge proofs. In Proceedings of the Nineteenth European Conference on Computer Systems (EuroSys), pages 560–574, 2024. [13] Haochen Sun, Jason Li, and Hongyang Zhang. zkLLM: Zero knowledge proofs for large language models. In Proceedings of the 2024 ACM SIGSAC Conference on Computer and Communications Security (CCS), pages 4405–4419, 2024. 16

Local fronts

Local fronts (mean)

Local fronts (min-max)

Global front

0.8

0.009

0.006

0.4

0.003

0.0 0.0015

0.0030

Risk (variance)

0.0045

(a) Fronts at generation 1000

10

−3

10

−4

IGD ( ↓ )

HV ratio ( ↑ )

Mean return

True Pareto front

0

400

Generation (b) HVR

800

0

400

Generation

800

(c) IGD

Figure 9: Results of zk-NSGA-II on the Hang Seng portfolio problem with 𝑛 = 31 assets, 𝑆 = 10 solvers, 𝑁 = 50 portfolios per solver, 𝐺 = 1000 generations and a global front capacity of 𝐾 = 100: (a) the minimization of risk versus the maximization of mean return, (b) HVR and (c) IGD over generations for the global front.

[31] Zhipeng Wang, Nanqing Dong, Jiahao Sun, William Knottenbelt, and Yike Guo. zkFL: Zero-knowledge proof-based gradient aggregation for federated learning. IEEE Transactions on Big Data, 11(2):447–460, 2025. [32] Goshgar Can Ismayilov. zkEC@0.0.1: Evolutionary computation meets programmable cryptography on blockchain. In Proceedings of the 40th ACM/SIGAPP Symposium on Applied Computing (SAC), pages 154–156. ACM, 2025. [33] David E. Goldberg and Kalyanmoy Deb. A comparative analysis of selection schemes used in genetic algorithms. In Foundations of Genetic Algorithms, volume 1, pages 69–93. Morgan Kaufmann, 1991. [34] Kalyanmoy Deb and Ram Bhushan Agrawal. Simulated binary crossover for continuous search space. Complex Systems, 9(2):115–148, 1995. [35] Kalyanmoy Deb and Mayank Goyal. A combined genetic adaptive search (GeneAS) for engineering design. Computer Science and Informatics, 26(4):30–45, 1996. [36] Guy L. Steele, Doug Lea, and Christine H. Flood. Fast splittable pseudorandom number generators. In Proceedings of the 2014 ACM International Conference on Object Oriented Programming Systems Languages & Applications (OOPSLA), pages 453–472, 2014. [37] Foundry Contributors. Foundry: A blazing fast, portable and modular toolkit for Ethereum application development. https://github.com/foundry-rs/foundry, 2025. [38] Eckart Zitzler, Kalyanmoy Deb, and Lothar Thiele. Comparison of multiobjective evolutionary algorithms: Empirical results. Evolutionary Computation, 8(2):173– 195, 2000. [39] Kalyanmoy Deb, Lothar Thiele, Marco Laumanns, and Eckart Zitzler. Scalable multi-objective optimization test problems. In Proceedings of the 2002 Congress on Evolutionary Computation (CEC), volume 1, pages 825–830. IEEE, 2002. [40] T.-J. Chang, N. Meade, J. E. Beasley, and Y. M. Sharaiha. Heuristics for cardinality constrained portfolio optimisation. Computers & Operations Research, 27(13):1271– 1302, 2000. [41] John E. Beasley. OR-Library: Distributing test problems by electronic mail. Journal of the Operational Research Society, 41(11):1069–1072, 1990. [42] Mardé Greeff and Andries P Engelbrecht. Solving dynamic multi-objective problems with vector evaluated particle swarm optimisation. In 2008 IEEE Congress on Evolutionary Computation (IEEE World Congress on Computational Intelligence), pages 2917–2924. IEEE, 2008. [43] Jason Ramon Schott. Fault tolerant design using single and multicriteria genetic algorithm optimization. Master’s thesis, Massachusetts Institute of Technology, 1995. [44] Carlos A. Coello Coello and Margarita Reyes Sierra. A study of the parallelization of a coevolutionary multi-objective evolutionary algorithm. In MICAI 2004: Advances in Artificial Intelligence, volume 2972 of Lecture Notes in Computer Science, pages 688–697. Springer, 2004. [45] Eckart Zitzler and Lothar Thiele. Multiobjective evolutionary algorithms: A comparative case study and the strength Pareto approach. IEEE Transactions on Evolutionary Computation, 3(4):257–271, 1999.

17

A

zk-NSGA-II Pseudocode

This appendix gives the pseudocode of the three components in zk-NSGA-II. Algorithm 1 describes the off-chain loop of a solver, Algorithm 2 the NSGA-II generation proven in the zkVM and Algorithm 3 the on-chain verification and aggregation on the smart contract. Algorithm 1 (Host) Off-chain loop of a solver 𝑖 with address 𝑎𝑖 . The step numbers in the comments refer to Figure 1. Require: Address 𝑎𝑖 , guest program Γ, private population store D, number of generations 𝐺 1: if D is empty then 2: choose an arbitrary population 𝑃 0 of 𝑁 solutions in Ω and a seed 𝑠 0 3: D ← Store(𝑃0 , 𝑠 0 ) 4: end if 5: for 𝑡 = 𝑡 0 , . . . , 𝐺 − 1 do 6: (𝑃𝑡 , 𝑠𝑡 ) ← Load( D, 𝑡 )
7: (𝜋𝑡 , 𝑜𝑡 , 𝑃𝑡 +1 , 𝑠𝑡 +1 ) ← Prove Γ; Guest(𝑃𝑡 , 𝑠𝑡 , 𝑎𝑖 ) 8: D ← Store(𝑃𝑡 +1 , 𝑠𝑡 +1 ) 9: send transaction Submit(𝜋𝑡 , 𝑜𝑡 ) from 𝑎𝑖 10: end for

⊲ genesis

⊲ step 2 ⊲ steps 3–6 ⊲ step 7 ⊲ step 8

Algorithm 2 (Guest) An NSGA-II generation proven in the zkVM as the guest program Γ. 1: procedure Guest(𝑃𝑡 , 𝑎𝑖 ) 2: ℎ𝑡 ← 𝐻 (𝑃𝑡 ) 3: 𝑄𝑡 ← ∅ 4: while |𝑄𝑡 | < 𝑁 do 5: p1 , p2 ← binary tournaments on 𝑃𝑡 6: c1 , c2 ← SBX(p1 , p2 ; 𝑝𝑐 , 𝜂𝑐 ) 7: c1 , c2 ← PM(c1 , c2 ; 𝑝𝑚 , 𝜂𝑚 ) 8: 𝑄𝑡 ← 𝑄𝑡 ∪ {c1 , c2 } 9: end while 10: F1 , F2 , · · · ← NonDominatedSort(𝑃𝑡 ∪ 𝑄𝑡 ) 11: 𝑃𝑡 +1 ← ∅; 𝑗 ← 1 12: while |𝑃𝑡 +1 | + | F𝑗 | ≤ 𝑁 do 13: 𝑃𝑡 +1 ← 𝑃𝑡 +1 ∪ F𝑗 ; 𝑗 ← 𝑗 + 1 14: end while 15: ℎ𝑡 +1 ← 𝐻 (𝑃𝑡 +1 ) 16: x𝑡∗+1 ← solution of F1 (𝑃𝑡 +1 ) at index randomly drawn 17: commit 𝑜𝑡 = (𝑎𝑖 , ℎ𝑡 , ℎ𝑡 +1 , F(x𝑡∗+1 ) ) 18: return 𝑃𝑡 +1 19: end procedure

⊲ step 3 ⊲ previous state hash ⊲ offspring generation ⊲ simulated binary crossover ⊲ polynomial mutation

⊲ sort merged population ⊲ front by front survivor selection

⊲ new state hash ⊲ step 6 ⊲ step 5

Algorithm 3 (Smart Contract) Front aggregation by the Pareto Front contract. The step numbers in the comments refer to Figure 1. 1: procedure Submit(𝜋𝑡 , 𝑜 𝑡 ) 2: require Verify(Γ; 𝜋𝑡 , 𝑜𝑡 ) 3: require 𝑎𝑖 = msg.sender 4: require head[𝑎𝑖 ] = ⊥ or ℎ𝑡 = head[𝑎𝑖 ] 5: head[𝑎𝑖 ] ← ℎ𝑡 +1 6: if no q ∈ G dominates or equals F(x𝑡∗+1 ) then 7: remove from G all points dominated by F(x𝑡∗+1 ) 8: if | G | < 𝐾 or a point is removed then 9: G ← G ∪ {F(x𝑡∗+1 ) } 10: emit admitted(𝑎𝑖 , F(x𝑡∗+1 ) ) 11: return 12: end if 13: end if 14: emit discarded(𝑎𝑖 , F(x𝑡∗+1 ) ) 15: end procedure

⊲ step 8 ⊲ step 9 ⊲ solver check ⊲ hash-chain check ⊲ advance the hash chain

⊲ capacity check

⊲ dominated or front full

18

B

Definitions of the Benchmark Problems

Tables 7 and 8 give the definitions of the ZDT and DTLZ problems used in Section 5.1. Table 7: Definitions of the ZDT problems [38] used in this work. Both objectives are minimized and 𝑛 denotes the number of decision variables. The Pareto front is given in the last column. Problem

𝑛

Bounds

Objective functions

ZDT1

30

𝑥 𝑗 ∈ [0, 1]

𝑓1 = 𝑥 1

𝑓2 = 𝑔 1 −

√︁

9 𝑔 = 1 + 𝑛−1

𝑓1 /𝑔 Í𝑛

Pareto front √︁ 𝑓2 = 1 − 𝑓1 convex



𝑗 =2 𝑥 𝑗

ZDT2

30

𝑥 𝑗 ∈ [0, 1]

𝑓1 = 𝑥 1
𝑓2 = 𝑔 1 − ( 𝑓1 /𝑔) 2 9 Í𝑛 𝑔 = 1 + 𝑛−1 𝑗 =2 𝑥 𝑗

ZDT3

30

𝑥 𝑗 ∈ [0, 1]

𝑓1 = 𝑥 1

𝑓2 = 𝑔 1 −

√︁

𝑓1 = 𝑥 1

√︁

𝑓2 = 1 − 𝑓12 non-convex

𝑓 𝑓1 /𝑔 − 𝑔1 sin(10𝜋 𝑓1 ) 9 Í𝑛 𝑔 = 1 + 𝑛−1 𝑗 =2 𝑥 𝑗

ZDT4

10

𝑥 1 ∈ [0, 1] 𝑥 𝑗 ∈ [ −5, 5], 𝑗 ≥ 2

𝑓2 = 𝑔 1 −

𝑓1 /𝑔

10

𝑥 𝑗 ∈ [0, 1]

√︁ 𝑓2 = 1 − 𝑓1 convex, multi-modal



𝑔 = 1 + 10(𝑛 − 1) + ZDT6

√︁ 𝑓2 = 1 − 𝑓1 − 𝑓1 sin(10𝜋 𝑓1 ) disconnected



Í𝑛

𝑗 =2

  𝑥 2𝑗 − 10 cos(4𝜋𝑥 𝑗 )

𝑓1 = 1 − 𝑒 −4𝑥 1 sin6
(6𝜋𝑥 1 ) 𝑓2 = 𝑔 1 − ( 𝑓1 /𝑔) 2   0.25 1 Í𝑛 𝑔 = 1 + 9 𝑛−1 𝑗 =2 𝑥 𝑗

𝑓2 = 1 − 𝑓12 non-convex, non-uniform

Table 8: Definitions of the DTLZ problems [39] used in this work. Both objectives are minimized, 𝑛 denotes the number of decision variables and 𝑘 = 𝑛 − 1. All decision variables lie in [0, 1]. The Pareto front is given in the last column. Problem

𝑛

Objective functions

Pareto front

DTLZ1

6

𝑓1 + 𝑓2 = 12 linear, multi-modal

DTLZ2

11

DTLZ3

11

DTLZ4

11

DTLZ5

11

DTLZ6

11

𝑓1 = 12 𝑥 1 (1 + 𝑔) 𝑓2 = 12 (1 − 𝑥 1 ) (1 + 𝑔) h

i Í 𝑔 = 100 𝑘 + 𝑛𝑗=2 (𝑥 𝑗 − 0.5) 2 − cos 20𝜋 (𝑥 𝑗 − 0.5)
𝑓1 = (1 + 𝑔) cos 𝜋2 𝑥 1
𝜋 𝑓2 = (1 + 𝑔) sin 2 𝑥 1 Í 𝑔 = 𝑛𝑗=2 (𝑥 𝑗 − 0.5) 2
𝑓1 = (1 + 𝑔) cos 𝜋2 𝑥 1
𝜋 𝑓2 = (1 + 𝑔) sin 2 𝑥 1 h

i Í 𝑔 = 100 𝑘 + 𝑛𝑗=2 (𝑥 𝑗 − 0.5) 2 − cos 20𝜋 (𝑥 𝑗 − 0.5)
𝑓1 = (1 + 𝑔) cos 𝜋2 𝑥 1𝛼
𝑓2 = (1 + 𝑔) sin 𝜋2 𝑥 1𝛼 , 𝛼 = 100 Í 𝑔 = 𝑛𝑗=2 (𝑥 𝑗 − 0.5) 2
𝑓1 = (1 + 𝑔) cos 𝜋2 𝑥 1
𝜋 𝑓2 = (1 + 𝑔) sin 2 𝑥 1 Í 𝑔 = 𝑛𝑗=2 (𝑥 𝑗 − 0.5) 2
𝑓1 = (1 + 𝑔) cos 𝜋2 𝑥 1
𝜋 𝑓2 = (1 + 𝑔) sin 2 𝑥 1 Í 𝑔 = 𝑛𝑗=2 𝑥 0.1 𝑗

DTLZ7

21

𝑓1 = 𝑥 1

𝑓2 = 4 − 𝑓1 (1 + sin(3𝜋 𝑓1 ) ) disconnected

𝑓12 + 𝑓22 = 1 non-convex 𝑓12 + 𝑓22 = 1 non-convex, multi-modal

𝑓12 + 𝑓22 = 1 non-convex, biased density 𝑓12 + 𝑓22 = 1 non-convex, identical to DTLZ2 𝑓12 + 𝑓22 = 1 non-convex, biased distance

  𝑓1 (1 + sin(3𝜋 𝑓1 ) ) 𝑓2 = (1 + 𝑔) 2 − 1+𝑔 Í 𝑔 = 1 + 𝑘9 𝑛𝑗=2 𝑥 𝑗

19

C

Acceptance Rate and Global Front Size

0

40

0 200

0 0

40

100

Generation

80

40

200

(e) ZDT6

100

Generation

0

40

100

Generation

(i) DTLZ4

200

100

Generation

100

Generation

40

200

0

200

80

40

200

80

40

0 0

(j) DTLZ5

100

Generation

(h) DTLZ3

0 0

200

80

(g) DTLZ2

80

100

Generation

0 0

0 0

0

(d) ZDT4

40

200

Admitted (%)

Admitted (%)

40

200

80

(f) DTLZ1

80

100

Generation

0 0

40

(c) ZDT3

0 0

80

0 0

Admitted (%)

80

0

Admitted (%)

200

(b) ZDT2

Admitted (%)

Admitted (%)

(a) ZDT1

100

Generation

Admitted (%)

100

Generation

40

Admitted (%)

0

80

Admitted (%)

40

80

Admitted (%)

80

Admitted (%)

Admitted (%)

Figures 10 and 11 complement the aggregation results in Section 6.2 by showing how the acceptance rate and the global front size change over the generations of the ZDT and DTLZ problems.

100

Generation

(k) DTLZ6

200

0

100

Generation

200

(l) DTLZ7

Figure 10: Acceptance rate of the global front over the 𝐺 = 250 generations for the twelve ZDT and DTLZ problems. At each generation, each solver submits one objective vector for the admission to the global front. 20

0

80

40

0 0

100

Generation

200

Global front size

40

Global front size

Global front size

Global front size

80

80

40

0 0

(a) ZDT1

100

Generation

200

80

40

0 0

(b) ZDT2

100

Generation

200

0

(c) ZDT3

100

Generation

200

(d) ZDT4

0

80

40

0 100

Generation

200

Generation

200

40

0

Generation

(i) DTLZ4

100

Generation

80

40

100

Generation

200

80

40

200

80

40

0 0

(j) DTLZ5

100

Generation

(h) DTLZ3

0 0

0

200

(g) DTLZ2

0 200

15

0 0

Global front size

Global front size

Global front size

100

(f) DTLZ1

80

100

40

0 0

(e) ZDT6

0

80

Global front size

0

Global front size

40

Global front size

Global front size

Global front size

30 80

100

Generation

(k) DTLZ6

200

0

100

Generation

200

(l) DTLZ7

Figure 11: Size of the on-chain global front over the 𝐺 = 250 generations for the twelve ZDT and DTLZ problems with a capacity of 𝐾 = 100. The size grows as solutions are admitted after proof verification and drops when a new solution removes the ones it dominates. Once the size reaches the capacity 𝐾, a new solution is admitted if it replaces at least one existing solution.

21

Related documents

• Kerberos Cryptosystem Negotiation Extension#266733
• AlchemQ: Proof-Carrying Quantum Circuit Optimization with Per-Result Equivalence Certificates#1013761
• Non-Functional Requirements for Blockchain: Challenges and New Directions#199483
• Extending Binary Byzantine Agreement to Multivalued Byzantine Agreement#464644
• Blockchain security enhancement: an approach towards hybrid consensus algorithms and machine learning techniques#133957