Alter PRE-adapted tDec API design for CBD-DKG

[piotr-roslaniec]

• Scope it from comments in this issue: Sketch client-facing and server-facing APIs ferveo#53 (comment)

[theref]

Ritual Initiation

We already have Cohorts and Strategies so this will stay unchanged!

import { Cohort, Strategy } from '@nucypher/nucypher-ts';

const config = {
  threshold: 3,
  shares: 5,
  porterUri: 'https://porter-tapir.nucypher.community',
};
const newCohort = await Cohort.create(config);
const newStrategy = Strategy.create(newCohort);

import detectEthereumProvider from '@metamask/detect-provider';
import { providers } from 'ethers';

const MMprovider = await detectEthereumProvider();
const mumbai = providers.getNetwork(80001);

const web3Provider = new providers.Web3Provider(MMprovider, mumbai);
const newDeployed = await newStrategy.deploy('test', web3Provider);

The background work will be very different though. newStrategy.deploy needs to call initiateRitual on the Coordinator contract.

This also means that newStrategy will be unusable until the ritual has completed successfully (this is similar to having to deploy the strategy previously, however the await will now take much longer. Therefore the Strategy class probably needs to have a getStatus function that returns one of:

enum RitualState {
    NON_INITIATED,
    AWAITING_TRANSCRIPTS,
    AWAITING_AGGREGATIONS,
    TIMEOUT,
    INVALID,
    FINALIZED
}

Strategy class will also contain the ritualID, this should probably be exposed.

[theref]

Another option for Ritual Initiation...

We don't handle it within the strategy because this could become restrictive. Instead we just give detailed examples of how to achieve the functionality with standard tools (ethersjs, hardhat, truffle, etc):

import { Cohort, CoordinatorABI, CoordinatorAddress } from '@nucypher/nucypher-ts';

const config = {
  threshold: 3,
  shares: 5,
  porterUri: 'https://porter-tapir.nucypher.community',
};
const newCohort = await Cohort.create(config);
const nodes = newCohort.ursulaAddresses;

import { ethers } from "ethers";
const provider = new ethers.providers.Web3Provider(window.ethereum);
const coordinatorContract = new ethers.Contract(CoordinatorAddress, CoordinatorABI, provider);

// currently only connected via provider which is read-only, we need to connect using the signer
const signer = provider.getSigner();
const CoordinatorWithSigner = coordinatorContract.connect(signer);

// initiate ritual
tx = await CoordinatorWithSigner.initiateRitual(nodes);

There are similar questions regarding PSS and how that status is handled.

[theref]

Another question... Cohort and Strategy are really just configuration objects, but which should handle the interface to the DKG ritual? In the comments above I outlined an example where it was contained within Strategy, but there's an argument that it should be part of the Cohort.

Thus const newCohort = await Cohort.create(config); would be calling initiateRitual on the Coordinator contract. A Strategy would no longer need to be deployed, so whilst it would be a breaking api change, the overall flow would be simpler. At this point a reasonable question become, what is the point of Strategy then? are there other configuration options that it should contain? (default conditions is a good example).

[piotr-roslaniec]

Currently, Cohort represents a set of nodes that may be re-used in multiple CBD strategies. The same remains true for rituals - we could have a bunch of hand-picked nodes from which we draw ritual participants. But in order to make a decision on that design we need to have a better understanding of how node sampling is supposed to work in DKG.

[arjunhassard]

• Final push to get feedback from Godmode testers
• Collect and collate final feedback-driven changes
• User defined context variables on ts side -> Add support for user defined parameters in ConditionContext #173
• consider optionality for timeout -> Error on retrieve_cfrags for multiple retrieval_kits nucypher-porter#23
• Meeting to finalize other changes (based on ferveo, wasm bindings, etc.)