Use @nucypher/nucypher-contracts contract registry#314
Use @nucypher/nucypher-contracts contract registry#314piotr-roslaniec merged 8 commits intonucypher:monorepofrom
@nucypher/nucypher-contracts contract registry#314Conversation
Codecov Report
@@ Coverage Diff @@
## monorepo #314 +/- ##
============================================
- Coverage 88.25% 87.34% -0.91%
============================================
Files 33 33
Lines 2409 2465 +56
Branches 205 206 +1
============================================
+ Hits 2126 2153 +27
- Misses 254 282 +28
- Partials 29 30 +1
|
14b7264 to
56404a2
Compare
a3efcae to
9a4a1e4
Compare
| const parseContractRegistry = (registry: ContractRegistry): Contract[] => | ||
| Object.keys(registry) | ||
| .map((chainId) => { | ||
| const networkRegistry = registry[chainId]; | ||
| return Object.keys(networkRegistry).map((contractName): Contract => { | ||
| const contract = networkRegistry[contractName]; | ||
| return { name: contractName as ContractName, abi: contract.abi }; | ||
| }); | ||
| }) | ||
| .flat(); |
There was a problem hiding this comment.
Nice to see this data model from nucypher-contracts adopted here.
There was a problem hiding this comment.
👍 Happy to see these files go away.
| import { DEFAULT_WAIT_N_CONFIRMATIONS, getContract } from '../registry'; | ||
|
|
||
| export class GlobalAllowListAgent { | ||
| public static async registerEncrypters( |
There was a problem hiding this comment.
Doesn't have to be this PR, but you may want to add a follow-up issue to add the ability to check if an encrypter is already registered i.e. isAddressAuthorized(ritualid, address) I think the contract method is called.
There was a problem hiding this comment.
You could also use it to check if the encrypter is already authorized before performing the authorization below.
There was a problem hiding this comment.
These two methods are exposed by taco. I think the latter (registering encrypters) could use the former under the hood.
There was a problem hiding this comment.
isEncryptionAuthorized on the Coordinator contract is different to isAddressAuthorized on the GlobalAllowList contract. The former is done during decryption because it needs the ciphertext digest etc.
The latter is a check for determining if a specific encryptor address is already authorized and doesn't need any ciphertext. See example here - https://github.com/nucypher/nucypher/blob/development/scripts/hooks/nucypher_dkg.py#L336.
| ) => DkgCoordinatorAgent.isEncryptionAuthorized(provider, ritualId, messageKit); | ||
| ) => DkgCoordinatorAgent.isEncryptionAuthorized(provider, domain, ritualId, messageKit); | ||
|
|
||
| export const registerEncrypters = async ( |
There was a problem hiding this comment.
This is very specific to the GlobalAllowList. I think we need to be careful here. Rituals may use the GlobalAllowList but I don't believe they have to. We'd need to first check here whether the accessController for the associated ritual is the global allow list contract before registering the encrypter. It doesn't have to be, although more often than not, it may be.
There was a problem hiding this comment.
Yes, the encryptor onboarding is a bit more complicated and it depends on #306
We could hide this method from the taco API until we sort it out.
There was a problem hiding this comment.
👍 I think that would be prudent.
| <body> | ||
| <noscript>This page contains webassembly and javascript content, please enable | ||
| <noscript | ||
| >This page contains webassembly and javascript content, please enable |
There was a problem hiding this comment.
I guess this <noscript > is done by a linter, but it looks pretty ugly
There was a problem hiding this comment.
I guess I could play around with linter rules, but I don't think these files are read as frequently.
| "dependencies": { | ||
| "@ethersproject/abi": "^5.7.0", | ||
| "@ethersproject/providers": "^5.7.2", | ||
| "@nucypher/nucypher-contracts": "^7.0.0-rc.1", |
|
|
||
| export type GetARGsTypeFromFactory<F> = F extends MinEthersFactory<any, any> | ||
| ? Parameters<F["deploy"]> | ||
| ? Parameters<F['deploy']> |
There was a problem hiding this comment.
Just curious: if these files are generated automatically, why the linting change?
There was a problem hiding this comment.
It's an oversight on my part. They should be generated and formatted in one step (to prevent line changes), but I haven't set it up yet.
9a4a1e4 to
2b0a6e2
Compare
2b0a6e2 to
ed55e6b
Compare
Type of PR:
Required reviews:
What this does:
@nucyper/nucypher-contractsdomain: Domainfrom user-facing APItypechainusage for contract typings generationIssues fixed/closed: