Support for Multisig Notary for Huge Datacap allocations

josepablofm78 commented 3 years ago

In order to allow allocations of huge amounts of datacap, a possible approach would be to have a multisig Notary which requires multiple signs to verify one of these clients with this kind of needs.

josepablofm78 commented 3 years ago

Initial Analysis

Multisig Setup

Decide number of signatures to approve tx
Decide initial signer (to create multisig)
Create multisig with threshold using lotus CLI
Add the rest of the signers to the multisig using lotus CLI

Github Governance

Create issue to:

discuss signers in this multisig
discuss criteria to accept (propose) new datacap requests

Update issue to publish multisig ID and robust address after the multisig is created

Create issue to request datacap to multisig Notary

Governance team member has to approve it

Filecoin+

RKH View

RKHs propose/sign new Notary as usual -> datacap is allocated to multisig address

Client Onboarding

New Notary is published in the table in the clients onboarding. This Notary will be associated with a list of GitHub users, corresponding to the signers in the multisig

Clients can only request to this Notary if the datacap exceeds a certain (huge) amount. the formulary will include a validation to be sure of this.

when a client requests datacap to this notary, the GitHub issue will be assigned to all the GitHub users of the signers, so all of them will be able to see the issue in the Notary View, Signing in GitHub with their own user

Notary View

Signers in the multisig will use the Organization option, indicating the address or Id of the multisig, to access the Notary view. The ledger must contain at least one address that is a signer in the multisig.

the notary signs in with him/her GitHub user to get the issues with the datacap request

To propose a new Verified Client, it will use the Verify button as usual. Under the hoods, the app will send a propose to the multisig address (Modification: in this particular case, where there signers of the multisig>1 we may want to change the label in the gihub issue to avoid multiple individuals propose the same client request) (Problem: if one of the signers of the multisig is also an individual Notary and uses the same github user for the individual and the organization notary, the list of pending issues will mix requests for the particular and for the multisig notaries. This is not bad by itself, but the problem is we need to call different methods of the API depending on the type of notary)

New View: we need to list the proposals sent to the multisig and still pending for additional signatures (to get this pending tx we use the method pendingTransactions(address) in filecoin-verifier-tools API)

In this View, the notary will use a Sign button that internally will send a new approval for the tx to the multisig. To do this, it will be needed to include a new method in the API, but the implementation should be pretty straightforward.

A rough implementation of this new method could be:

async multisigApproveVerifyClient(multisigAddress, clientAddress, datacap, fromAccount, transactionId, indexAccount, wallet, { gas } = { gas: 0 }) {

    const verifyTx = this.methods.verifreg.addVerifiedClient(clientAddress, datacap)
    const m_actor = this.methods.actor(multisigAddress, this.methods.multisig)

    const approveTx = m_actor.approve(parseInt(transactionId, 10), { ...verifyTx, from: fromAccount )

    const res = await this.methods.sendTx(this.client, indexAccount, this.checkWallet(wallet), { ...approveTx, gas })

    return res['/']
}

jernejpregelj commented 3 years ago

Blockers to resolve: multisig account with users addresses and their githubs

keyko-io / filecoin-verifier