Skip to content
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.

Sign up for GitHub

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

Jump to bottom

bootstrap config: uniform treatment of contract terms, governance parameters #7309

Open
3 tasks
dckc opened this issue Apr 2, 2023 · 4 comments
Open
3 tasks

bootstrap config: uniform treatment of contract terms, governance parameters #7309

dckc opened this issue Apr 2, 2023 · 4 comments
Assignees
@dckc
Labels
cosmic-swingset package: cosmic-swingset enhancement New feature or request technical-debt

Comments

@dckc
Copy link
Member

dckc commented Apr 2, 2023 •
edited
Loading

Problem

One solution to more frequent auctions for testing (#7249) would be to give a value for StartFrequency in the config file when starting the chain. But the config.auctionParams in startAuctioneer isn't wired up to the config file.

The connections between initial governance parameter values (and contract terms) and config file options is incomplete and ad-hoc.

Plus, the value for StartFrequency includes the timerBrand, and we can't put objects such as that directly in JSON config files. Likewise bignums, ratios. We have various ad-hoc conventions for building objects from JSON data in config files.

Design

  • a uniform mechanism to set the initial value of any governance parameter
    • perhaps a small expression language... akin to Justin, but embedded in JSON. the smartWallet callPipe is similar.
  • likewise for contract terms

Goals (optional):
@dckc dckc mentioned this issue Apr 2, 2023
Closed
2 tasks
@dckc dckc added cosmic-swingset package: cosmic-swingset enhancement New feature or request labels Apr 2, 2023
@dckc dckc changed the title uniform treatment of contract terms, governance parameters bootstrap config: uniform treatment of contract terms, governance parameters Apr 2, 2023
@dckc dckc self-assigned this Apr 2, 2023
@dckc dckc mentioned this issue Apr 3, 2023
Closed
@dckc
Copy link
Member Author

dckc commented Apr 21, 2023

Looks like our ad-hoc treatment of initial settings bit us again today for oracle testing.

the minSubmissionCount is set to 1 not 3
we need to override DEFAULT_CONTRACT_TERMS around
https://github.com/Agoric/agoric-sdk/blob/master/packages/vats/decentral-devnet-config.json#L116

cc @michaelfig

@dckc dckc mentioned this issue Apr 29, 2023
Merged
@Chris-Hibbert
Copy link
Contributor

@dckc is aware of this, but for others following along, minSubmissionCount is addressed somewhat in #7583. If it needs to be modified in other places, that PR demonstrates an approach that works.

@dckc
Copy link
Member Author

dckc commented May 11, 2023 •
edited
Loading

took some extra time while thinking about #7683 to explore this a little...

config-schema.json
2023-05-11 08:15 febe1f0 feat: generate schema for swingset config

see also notes in discord thread:

@dckc dckc mentioned this issue May 12, 2023
Open
@dckc dckc mentioned this issue Jun 27, 2024
Open
@dckc
Copy link
Member Author

dckc commented Nov 14, 2024 •
edited
Loading

I ran into this problem when configuring fees in Fast USDC terms. I suggest that the LegibleCapData approach in #10477 could work. currently: d6dcd8d

p.s.

agoric-sdk/packages/fast-usdc/src/utils/config-marshal.js

Line 5 in d703190

// TODO(#7309): move to make available beyond fast-usdc.

@dckc dckc mentioned this issue Nov 14, 2024
Merged
3 tasks
mergify bot added a commit that referenced this issue Nov 18, 2024
@mergify
feat(fast-usdc): core-eval, builder script (#10477)
5a4fc01 
closes: #10301

## Description

 - feat(fast-usdc): .start.js core-eval w/oracle invitations
    - the pool share brand is called `FastLP` , at least **UNTIL #10432**
    - needed contract tweak: STUB! makeOracleInvitation , so perhaps this should wait for #10478
 - feat(builders): fast-usdc builder w/CLI config for fees, oracle addresses

Also, rather than yet another ad-hoc way of passing terms containing amounts from builders to core-eval, this includes `LegibleCapData`, an approach for...

   -  #7309

### Security Considerations

Oracle invitations are sent do parties identified by addresses, so the usual key management issues apply. In order to reduce "which address is for which operator?" hassle, configuration uses a record, like we do for `voterAddresses`, rather than a plain array as in price feed core-eval code.

The core eval produces a `fastUSDCKit` including `privateArgs`; this was prompted by testing difficulties: `instancePrivateArgs` is a heap map, not a remotable, so `EV(instancePrivateArgs).get(instance)` is a no-go. But it also usefully avoids handing out all of `instancePrivateArgs` to any core-eval for upgrading this contract.

### Scaling Considerations

The core-eval is O(1), I think. It's O(n) in the number of oracle operators, but that number is fixed by proposal time.

### Documentation Considerations

The builder CLI args are lightly documented, in the source:

```js
/** @type {ParseArgsConfig['options']} */
const optionsConfig = {
  contractFee: { type: 'string', default: '0.01' },
  poolFee: { type: 'string', default: '0.01' },
  oracle: { type: 'string', multiple: true },
};
const oraclesRequiredUsage = 'use --oracle name:address ...';
```


### Testing Considerations

 - [x] test(boot): fast-usdc core eval
   - needed chore: include noble USDC in orch integration test config
 - [x] test(boot): restart fastUSDC
 - [x] unit tests for config marshal 

### Upgrade Considerations

Restart is a pre-requisite for upgrade, so this is progress on testing upgrade of fastUSDC.
@dckc dckc mentioned this issue Nov 26, 2024
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@dckc dckc

Labels
cosmic-swingset package: cosmic-swingset enhancement New feature or request technical-debt
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@dckc @Chris-Hibbert