{"id":19390390,"url":"https://github.com/nucypher/confirm-activity-doc","last_synced_at":"2026-03-19T09:35:58.379Z","repository":{"id":101544044,"uuid":"246434551","full_name":"nucypher/confirm-activity-doc","owner":"nucypher","description":null,"archived":false,"fork":false,"pushed_at":"2020-08-05T18:20:27.000Z","size":5934,"stargazers_count":0,"open_issues_count":0,"forks_count":3,"subscribers_count":9,"default_branch":"master","last_synced_at":"2025-03-03T21:27:05.627Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"TeX","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/nucypher.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2020-03-11T00:02:16.000Z","updated_at":"2020-08-05T18:20:29.000Z","dependencies_parsed_at":"2023-06-05T09:45:19.199Z","dependency_job_id":null,"html_url":"https://github.com/nucypher/confirm-activity-doc","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/nucypher/confirm-activity-doc","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/nucypher%2Fconfirm-activity-doc","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/nucypher%2Fconfirm-activity-doc/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/nucypher%2Fconfirm-activity-doc/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/nucypher%2Fconfirm-activity-doc/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/nucypher","download_url":"https://codeload.github.com/nucypher/confirm-activity-doc/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/nucypher%2Fconfirm-activity-doc/sbom","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":262862280,"owners_count":23376398,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-10T10:20:39.606Z","updated_at":"2026-03-19T09:35:56.699Z","avatar_url":"https://github.com/nucypher.png","language":"TeX","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Confirm Activity \n\nThis repository contains proposed solutions for the confirm activity problem in the NuCypher network. This problem is concerned with how to prove that an Ursula is indeed active and providing service in the network. \n\nThe presented work considers two definitions of the problem: confirm availability and confirm service activity. The former is about confirming that each Ursula is indeed online and willing to serve Bob requests, while the latter is about confirming that Ursula served a distinct number of requests withing a given period. Such definitions arise due to the difference in requirements of the different stages of the network operation. During the initial stage, while subsidies still exist, confirm availability is what we are after to increase adoption. At a later stage, when the only income source is service fees, we think that confirm service activity is what we need.\n\n## Repo Organization\nconfirm-activity/ contains the full research work on the confirm activity problem, while CESC-submission/ contains the paper submitted to CESC 2020.\n\n## Current Work\nSeveral solutions are proposed that vary based on the problem they solve, threat model, and efficiency. The first one is for confirm availability, while the rest are for confirm service activity.\n\n### Optimistic Challenge-based Approach\nHere Bob request the service as usual. If the working Ursula is not responding Bob falls back to a challenge protocol to investigate this Ursula and punish her financially if unavailability is confirmed. At a high level, for each round a set of Ursulas, called gateways, is elected. Bob complains to these gateways, which in turn forward Bob's request to the working Ursula and wait for an answer. If not reply is received, the gateways sign a statement attesting that the working Ursula is not responsive. This will result in slashing part of the working Ursula stake as a punishment.\n\n### ZKP-based Scheme\nwe utilize the fact that in our network each Ursula already produces a ZKP attesting to the correctness of each re-encryption request she performs. Our solution is to aggregate the proofs of all served requests within a round into one proof attesting to the above statement. This accumulation can be done by using generic techniques like proof carrying data (PCD) or incrementally verifiable computation (IVC). An alternative, possibly more efficient approach, is to view the statement that an Ursula served a given number of requests as an instance of arithmetic circuit satisfiability problem and combine it with a highly efficient ZKP system, e.g., Bulletproofs, to produce a proof attesting to the statement claim. \n\n### Committee-Attestation Scheme\nThis solution shares a similar theme to confirm availability solution mentioned previously. For each round, a committee of Ursulas (and possibly outsider verifiers) is elected to attest for the work load an Ursula served. In detail, the working Ursula sends all Bob requests she served along with the correctness proofs to this committee. After verifying all the proofs, the committee collectively signs a statement attesting to the workload performed by Ursula. The committee (or the working Ursula) submits the signed statement to the network so the working Ursula can claim her payments. \n\n### Commit/Challenge/Open-based Scheme\nHere we introduce a mechanism inspired from the Merkle tree-based ZKP system. For each round a working Ursula constructs a Merkle hash tree of all served requests and their correctness proofs. Then, she uses the root as a random beacon to be fed into an iterative hash process to select n leaf nodes at random to open them (i.e., these are the challenges). Ursula signs the Merkle tree root and the activity proof will be composed of the signed root, the challenge leaf nodes along with their openings, and membership paths of the challenge leaves. Ursula sends this proof either to a sidechain (maintained by round-selected committee) or to the main network to verify. Once verified, Ursula will be rewarded with the service payment.\n\n## Future Work\n* Implement the optimistic challenge-based solution into the network.\n* Collect data from the network once we move to phase two (when the inflation rewards disappear) and assess the need to switch to any of the confirm service activity solutions.\n* Implement the three solutions of the confirm service activity and compare their performance to choose the best (if needed in the network).","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fnucypher%2Fconfirm-activity-doc","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fnucypher%2Fconfirm-activity-doc","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fnucypher%2Fconfirm-activity-doc/lists"}