-
Notifications
You must be signed in to change notification settings - Fork 212
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Grant proposing rights to new charter members #10166
Conversation
Deploying agoric-sdk with Cloudflare Pages
|
@@ -0,0 +1,54 @@ | |||
import { makeHelpers } from '@agoric/deploy-script-support'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hm. I wasn't expecting a separate builder script for each issue. I suppose it could work, but it seems kinda awkward.
I guess I was expecting this to use the same builder script from #10164 and just expand the core eval code. What do you think about stacking the PRs?
ac34a12
to
caeddfd
Compare
c486362
to
502343e
Compare
502343e
to
cd7809e
Compare
cd7809e
to
e993aeb
Compare
e993aeb
to
cd7809e
Compare
…er (#10178) <!-- < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < ☺ v ✰ Thanks for creating a PR! ✰ ☺ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --> <!-- Most PRs should close a specific Issue. All PRs should at least reference one or more Issues. Edit and/or delete the following lines as appropriate (note: you don't need both `refs` and `closes` for the same one): --> refs: #10134 #10133 ## Description This pull request builds on #10166 and #10164. It updates the core eval code to utilize the `governorCreatorFacet` for the governed contracts via the `governedContractKit`. Initially, the aim was to use the `governedContractKit` to access facets from price feed contracts. But since it also includes facets for other governed contracts, I expanded the code to incorporate these as well. ### Security Considerations Same as #10166 and #10164 ### Scaling Considerations <!-- Does this change require or encourage significant increase in consumption of CPU cycles, RAM, on-chain storage, message exchanges, or other scarce resources? If so, can that be prevented or mitigated? --> ### Documentation Considerations <!-- Give our docs folks some hints about what needs to be described to downstream users. Backwards compatibility: what happens to existing data or deployments when this code is shipped? Do we need to instruct users to do something to upgrade their saved data? If there is no upgrade path possible, how bad will that be for users? --> ### Testing Considerations Same as specified in #10164 ### Upgrade Considerations <!-- What aspects of this PR are relevant to upgrading live production systems, and how should they be addressed? -->
|
||
const oracleInvitationAfterProposal = | ||
await governanceDriver.ecMembers[0].getOracleInvitation(); | ||
t.not(oracleInvitationAfterProposal, undefined); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
t.not(oracleInvitationAfterProposal, undefined); | |
t.truthy(oracleInvitationAfterProposal); |
or better:
t.not(oracleInvitationAfterProposal, undefined); | |
t.is(passStyleOf(oracleInvitationAfterProposal), 'remotable'); |
That's the most info you can get without a remote call to the zoe invitation issuer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
cafe7fd
to
ca27d2f
Compare
ffce1a7
to
aef84d0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
gotta go to a meeting; this is what i have so far...
@@ -0,0 +1,475 @@ | |||
import { test as anyTest } from '@agoric/zoe/tools/prepare-test-env-ava.js'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's a substantial overlap between ec-membership-update.test.ts
and ec-replace-charter.test.ts
. How about putting everything in ec-membership-update.test.ts
to eliminate duplication?
packages/boot/tools/drivers.ts
Outdated
@@ -281,6 +281,17 @@ export const makeGovernanceDriver = async ( | |||
proposal: {}, | |||
}); | |||
}, | |||
getOracleInvitation: async () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we have method naming conventions and "get" usually throws when it doesn't find the thing... at least in the store API... so consider...
getOracleInvitation: async () => { | |
findOracleInvitation: async () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is getting pretty close, but I think some of these are worth fixing.
The test.macro
thing is not critical.
Here's hoping I find a moment to go over these comments and clarify which ones are ciritical.
test.serial('successful proposal by outgoing member', async t => { | ||
// Ability to propose by outgoing member should still exist |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hm. it's not so much that it should. It shouldn't, but postponed addressing that, for now.
Perhaps write this as a test that they cannot propose, but mark it test.failing
, and cite issue #10136 ?
t.assert(lastOutcome.outcome === 'win'); | ||
}); | ||
|
||
test.serial('successful proposal and vote for auctioneer', async t => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think of this more as...
test.serial('successful proposal and vote for auctioneer', async t => { | |
test.serial('EC can govern auctioneer parameter', async t => { |
t.assert(lastOutcome.outcome === 'win'); | ||
}); | ||
|
||
test.serial('successful proposal and vote for provisionPool', async t => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
test.serial('successful proposal and vote for provisionPool', async t => { | |
test.serial('EC can govern provisionPool parameter', async t => { |
This starts to get repetitive. You might try a test.macro
parameterized on contract instance and governed parameter.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The issue calls for checking all instanced of 6 contract installations. I see only 5. Reserve seems to be missing.
But maybe it's there and I don't see it. It would be nice to see all 6 on one screen using invocations of a macro. For example:
const ecCanGovern = test.macro({
title:(_t, label) => `EC can govern ${label}`,
exec(t, label, findInstances, parameters) => { ... },
});
test('auctioneer', ecCanGovern, instance => [instance.auctioneer], { LowestRate: 100_000_000n });
test('reserve', ecCanGovern, instance => [instance.reserve], { ... });
test('PSM', ecCanGovern, instance => instance.map(...).filter(...), { ... });
I hope that's enough of a suggestion. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
added the test for reserve. missed that accidentally. thanks for the catch
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
regarding test.macro
, i tried it out. personally it didn't improve readability a lot since there are a lot of minor variations between the tests due to which I have to pass a ton of parameters to the macro. reading the tests at first glance, it isnt immediately obvious what those parameters do
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks for trying it out.
@@ -322,6 +333,28 @@ export const makeGovernanceDriver = async ( | |||
}); | |||
}; | |||
|
|||
const proposeApiCall = async ( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👏
@@ -18,6 +18,7 @@ import { | |||
import { reserveThenDeposit } from './utils.js'; | |||
|
|||
/** @import {EconomyBootstrapPowers} from './econ-behaviors.js' */ | |||
/** @import {EconCharterStartResult} from './econ-behaviors.js') */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/** @import {EconCharterStartResult} from './econ-behaviors.js') */ | |
/** @import {EconCharterStartResult} from './econ-behaviors.js' */ |
* options: { | ||
* voterAddresses: Record<string, string>; | ||
* econCharterKit: { | ||
* creatorFacet: { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIUC, the config is plain data. How are we getting an object with a method in there?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh... this isn't an exported function referred to by a behavior.
Still.. the name config
threw me off. Maybe opts
instead?
* Starts a new Economic Committee Charter by creating an instance with the | ||
* provided committee specifications. | ||
* | ||
* - @param {EconomyBootstrapPowers} powers - The resources and capabilities |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* - @param {EconomyBootstrapPowers} powers - The resources and capabilities | |
* @param {EconomyBootstrapPowers} powers - The resources and capabilities |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's odd that this doesn't fail the lint check in ci.
Github says
Missing JSDoc @param "root0.installation.consume.econCommitteeCharter" declaration
packages/boot/tools/drivers.ts
Outdated
proposal: {}, | ||
}); | ||
const invitation = findInvitation(w, 'Voter'); | ||
if (invitation) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If there's no such invitation, this seems to fail silently. Silent failures drive me buggy. How about assert(invitation);
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this check was added because this function is also triggered from the liquidationDriverKit. since im now using that along with my regular tests, it results in the invitation being accepted twice.
since we dont want that, and it would be kind of unnecessary complicated to update the liquidationDriverKit (and as a result, the tests that use it), i thought it would be easier to have this check present
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
rename it to acceptOutstandingInvitation()
? and add an else
case to console.log('no outstanding Voter invitation')
?
For this sort of thing, I prefer an early return:
if (!invitation) {
console.log(...);
return;
}
It avoids indenting the code for the main execution path.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this should work!
please do edit the price feed test name
|
||
import { makeSwingsetTestKit } from '../../tools/supports.js'; | ||
import { | ||
makeGovernanceDriver, | ||
makeWalletFactoryDriver, | ||
} from '../../tools/drivers.js'; | ||
import { makeLiquidationTestKit } from '../../tools/liquidation.js'; | ||
import { NonNullish } from '@agoric/internal'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this pass lint? don't all the intra-package imports (../
) have to go after all the inter-package imports?
Try optimize imports?
not critical, unless our lint rules require it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
its required. for some reason the lint issues are not actively appearing in my IDE.
thanks for the catch
} | ||
}); | ||
|
||
test.serial('EC can govern price feed parameter', async t => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this case isn't about a parameter.
test.serial('EC can govern price feed parameter', async t => { | |
test.serial('EC can make calls to price feed governed APIs', async t => { |
not a critical correctness issue, but misleading
6a3afcb
to
78581b1
Compare
closes: #10133
refs: #10133
Description
The PR builds on #10164, introducing code changes to initiate a new charter committee instance and send invitations to the members.
Security Considerations
The EC Charter is important for deciding who can suggest changes to governed contract parameters. If the wrong people are given access or if expired members aren't removed, it can lead to security risks by letting unauthorized individuals propose changes.
Since we're starting a new contract, old charter members can still propose questions, even though they can't vote. This still creates a potential security issue, as people who are no longer active can still influence the process. These people might fill the system with too many unnecessary or harmful proposals, which can make it difficult to focus on the important ones and slow down the decision-making process.
Scaling Considerations
Documentation Considerations
Testing Considerations
Same as specified in #10164
Upgrade Considerations