peggyjv / sommelier Goto Github PK

Requirements:

• Container for orchestrator or gorc built from commit of peggyjv/gravity-bridge in go.mod
• Artifacts from peggyjv/gravity-bridge contracts installable via npm
• Artifacts from volumefi/cellars contracts installable via npm
• Container for sommelier from peggyjv/sommelier built for each commit
• Container for allocation-feeder from peggyjv/sommelier built for each commit

Test Setup:

• Spin up new testing ETH chain
• Bootstrap sommelier cluster along with key delegations for gorc and allocation-feeder
  • TODO: would be nice to input the test cellar into state at genesis so think about order of operations here
• Create gravity contract on test ETH chain w/ info from validators
• Create test ERC20 tokens (2-3)
• Create uniswap v3 contracts
• Create graph node indexing the uniswap v3 contracts
• Start sommelier cluster, gorc/orchestrator instances, and allocation-feeder/aphid instances
• Create uniswap markets for the erc20 tokens with some liquidity in them
• Create a cellar for that market

First proposed test:

• trade the market to trigger a rebalance call

Problem Definition

We would like to be confident in Cork's ability to modify allowed cellars via governance and to respect the allowed IDs within handlers

Summary

Cork full feature auotmated integration tests

Proposal

Bring up the cluster with no allowed cellars.
Make a failing call against a cellar.
Add the cellar via governance.
Make a succeeding call against that cellar.
Make a failing call against a different cellar.
Remove the cellar via governance.
Make a failing call against the cellar.

Define metrics for each transaction type both for peggy and the oracle module

Summary of Bug

Sommelier ignores the log_level command-line/toml config, except for the first time it is run.
An unsafe-reset-all and a wipe of ~/.sommelier/data is required for sommelier to observe the new log_level config

Version

2.0.0

Reproduction Steps

• Start sommelier with log_level=info. Stop the process, then restart with log_level=debug. Only info logs are produced.
• Run sommelier unsafe-reset-all and rm -r ~/.sommelier/data, then restart sommelier again with log_level=debug. Now debug logs are produced.

The allocation feeder will take data from an array of sources and output an Allocation for each cellar supported in the Params for the allocation module once every time period:

// Allocation is the commit for all allocations for a cellar by a validator
message Allocation {
  string cellar_id = 1;
  PoolAllocations pool_allocations = 2;
  string salt = 3;
}

This piece is currently underspecified and needs a bit of work to decide: language, other consumers requirements. cc @kkennis @zmanian @mvid

• Calculation for block emission
• Param for reward emission period
• Send SOMM to distribution each block

Buf version 0.48.2 (https://github.com/bufbuild/buf/releases/tag/v0.48.2) is the highest confirmed working version to compile proto files using ./scripts/protocgen.sh; at the moment, to install this version a manual buf installation from source is required.

As of writing this ticket, buf is currently on release 1.7.0 so we are considerably behind the latest release.

The goal of this ticket should be to investigate if we actually want buf as a depencency, and either update the script to work with the most recent version of buf, or remove it entirely from the script.

Note: Regardless of buf version changes, the protoc-gen-grpc-gateway plugin will also have to be upgraded to v2. Our current script assumes v1 which is out of date and must be force installed.

Ideally the testnet can be done with both the auction and cellar fee modules together, but if timing does not align they can be separate.

Things to be tested (living list):

• Token price governance proposal
• Mock Auction

osmosis-labs/osmosis#567

We should collaborate with Osmosis.

The current Peg Zone smart contracts emit a SendToCosmos event when ERC 20 tokens are added to the bridge.

We need a flow from SendToCosmos event to stop loss initiated.

1. We need to validate that that the EthAddress of ERC20 token is a valid liquidity pool.

2. We need to capture the stop loss information for that pair_id/Etheraddress of the ERC20 token issue.

Should the validation of 1 be done in the consensus state machine?

Should we be trying to have an additional event in the contract to capture the stop loss information or should we capture this information in a metatransaction?

The following is a list of components required for sommelier protocol. In order to properly test, we need these components in a full integration testing suite that allow for end to end local testing. Once this checklist is complete, public testnets will begin:

Components

• Cellar Contracts
  • Finished Rebalance call
  • Rebalance call ABI generated and committed to the allocation module repo w/ test #41
  • npm install for contracts VolumeFi/cellars#1
  • test suite that includes uniswap v3 integration testing, see the v3 staking contract tests VolumeFi/cellars#2
  • Pay validators out of fees generated on cellars VolumeFi/cellars#3
  • Gas optimization for rebalance call
• Allocation Module
  • Integrate cellar contract ABI #41
  • Handle invalidation ID/ nonce and retries for timed out transactions (cc @jtremback) #42
  • finalize voting method (i.e. every period or when a number of votes accumulate during a period) #43
• Allocation feeder (TBD name, aphid?) #44
  • decide on language (JS, Go, Rust)
  • ingest data from APIs (TODO: which apis? just v2 and v3 graph?)
  • price range decision method (i.e. bollinger bands or other)
  • loop over list of contracts in allocation params
  • send transactions when allocations should change
• Gravity Bridge
  • Passing integration tests
  • Docker/binary/artifacts built in CI on each commit for consumption by downstream CI processes PeggyJV/gravity-bridge#30
  • Finalize handling of contract call txs and how to time them out with additional testing and examples of invalidation id/nonce working in practice PeggyJV/gravity-bridge#31

Integrating all the components

• Sommelier Integration testing #45
  • Four validator sommelier chain w/ gravity and allocation modules wired up
  • Four orchestrators connected
  • Four allocation feeders connected
  • Mock/real graph data for testing (TODO: need to decide if we want to spin up full graph infra in integration environment)
  • Ethereum chain
  • Gravity contract deployed
  • Cellar contract deployed
  • Uni v3 deployed
  • testing erc20s and supporting infra deployed
  • Integration test spins up full environment, and tests adding/removing liquidity and rebalances

This is an issue to track design and implementation of a feature in the Peggy.sol contract which can enable the following use case:

• User locks tokens in Uniswap, receiving LP tokens
• User sends LP tokens to Peggy
• User gives Cosmos chain instructions to liquidate LP tokens under various conditions (this is outside the scope of this issue)
• Liquidation criteria are met, Cosmos validators sign an Ethereum tx which is then relayed to Peggy.sol and causes it to send the user's LP tokens back to Uniswap, receive the underlying tokens, and then transfer the underlying tokens to the user's account

This should be generic- i.e. no hardcoded calls to Uniswap or any other contract in the Peggy.sol contract. Peggy.sol should be able to do the same thing with a different AMM, or even execute a completely different strategy.

Also, it should be possible to do a number of operations for different users in a batch. This will amortize the cost of the validator signature verification, similar to how peggy amortizes the cost of token transfers now.

panic: runtime error: index out of range [0] with length 0

goroutine 1 [running]:
github.com/peggyjv/gravity-bridge/module/x/gravity/client/cli.CmdUnbatchedSendToEthereums.func1(0xc0011c8500, 0x328ed98, 0x0, 0x0, 0x0, 0x0)
/home/runner/go/pkg/mod/github.com/peggyjv/gravity-bridge/[email protected]/x/gravity/client/cli/query.go:667 +0x3f4
github.com/spf13/cobra.(*Command).execute(0xc0011c8500, 0x328ed98, 0x0, 0x0, 0xc0011c8500, 0x328ed98)
/home/runner/go/pkg/mod/github.com/spf13/[email protected]/command.go:856 +0x472
github.com/spf13/cobra.(*Command).ExecuteC(0xc0010c0780, 0x0, 0x0, 0xc0010bcf60)
/home/runner/go/pkg/mod/github.com/spf13/[email protected]/command.go:974 +0x375
github.com/spf13/cobra.(*Command).Execute(...)
/home/runner/go/pkg/mod/github.com/spf13/[email protected]/command.go:902
github.com/spf13/cobra.(*Command).ExecuteContext(...)
/home/runner/go/pkg/mod/github.com/spf13/[email protected]/command.go:895
github.com/cosmos/cosmos-sdk/server/cmd.Execute(0xc0010c0780, 0xc0010bcf60, 0x1d, 0x24a9618, 0xc0010d93c0)
/home/runner/go/pkg/mod/github.com/cosmos/[email protected]/server/cmd/execute.go:36 +0x285
main.main()
/home/runner/work/sommelier/sommelier/cmd/sommelier/main.go:14 +0x45

Upgrade to cosmos-sdk 0.45.7, tendermint 0.34.20, and IBC 3.2.0.

This depends on the upgrade first being done on the included gravity module: PeggyJV/gravity-bridge#457.

When submitContractCall() is called, it's supposed to increment a nonce that is scoped to a specific function on a specific contract address. Right now it's incrementing a global nonce that has no reference to any scopes. The result one nonce being incremented for all Cork contract calls.

func (k Keeper) submitContractCall(ctx sdk.Context, cork types.Cork) {
	k.Logger(ctx).Info("setting outgoing tx for contract call",
		"address", cork.TargetContractAddress,
		"encoded contract call", cork.EncodedContractCall)
	// increment invalidation nonce
	invalidationNonce := k.IncrementInvalidationNonce(ctx)           // <---------------------
	// submit contract call to bridge
	contractCall := k.gravityKeeper.CreateContractCallTx(
		ctx,
		invalidationNonce,
		cork.InvalidationScope(),
		common.HexToAddress(cork.TargetContractAddress),
		cork.EncodedContractCall,
		[]gravitytypes.ERC20Token{}, // tokens are always zero
		[]gravitytypes.ERC20Token{})
	k.gravityKeeper.SetOutgoingTx(ctx, contractCall)
}

k.IncrementInvalidationNonce() uses LastInvalidationNonceKey which afaict is not include the invalidation scope for keying.

Summary of Bug

When --db_dir is set via command line args or via config.toml, tendermint still stores its state in ~/.sommelier/data

Version

2.0.0

Reproduction Steps

Run sommelier with an overridden db_dir config to point away from ~/.sommelier/data. Check for creation of ~/.sommelier/data

• Goreli Graph node synced @tony-iqlusion
  • Test w/ oracle feeder @jackzampolin
• Logic contract for withdraws @zmanian
• Encoding call for logic contract
  • Go side (in the module) @jackzampolin logic contract
  • Rust side (in the relayer) @jkilpatr
• Merge IL module PR (#14)
• Batched txs for IL module
• Commit - reveal oracle phases
• Prunning oracle data and stoploss positions
• Deploy peggy contract @jkilpatr
  • Need initial keys from testnet validators @jackzampolin @jkilpatr @zmanian @fedekunze @tony-iqlusion
• Genesis file @jackzampolin @jkilpatr @zmanian @fedekunze @tony-iqlusion
• Spin up network @jackzampolin @jkilpatr @zmanian @fedekunze @tony-iqlusion

• Types/protos
• CellarFeePool store and getter/setter
• Helper functions for managing pool
• Unit tests
• Genesis init
• Pool invariants
• Conditionally update pool based on SendToCosmos events

The validator set should be able to call the reinvest function on the cellars from the allocation module. Validators will also need to feed the state machine some data to trigger this reinvest call:

message MsgCellarOracleVote {
    string cellar_id             = 1;
    uint64 usd_fees_accrued      = 2;
    uint64 usd_cellar_value      = 3;
    uint64 usd_reinvestment_cost = 4;
    string signer                = 5;
}

Validators will be required to submit these messages once every params.CellarOracleVotePeriod for each cellar tracked by the allocation module. At the params.CellarOracleVotePeriod boundary these votes should be tallied up and any required reinvest calls should be sent out at that time. This feature is a great candidate for batching contract call txs and may require that feature. This is a post launch feature.

This ticket should create a documentation template + workflow to create token price updates to be used by the auction module as well as publish the first ever token price update.

Bonus points if we create a server to automatically submit these governance proposals at a regular cadence (if not done in this ticket should be tracked and followed up in another ticket shortly after).

Problem Definition

The current single-phase voting period on the oracle module allows for freeloading of data feeding.

Proposal

This should be refactored to have 2 phases (commit and reveal) where only prevote msgs are allowed during the commit phase and only vote msgs are allowed on the reveal phase.

cc: @zmanian @jackzampolin

Come up with a strategy for this pending perf testing with larger data sets cc @fedekunze

ExchangeRateTuple IS sdk.DecCoin refactor it to be such and simplify code.

Summary of Bug

README instructions don't include -a flag on gorc sign-delegate keys

Version

38ebef6

Reproduction Steps

Following the instructions, the step that asks you to:

$ gorc --config $HOME/gorc/config.toml sign-delegate-keys signer $(sommelier keys show validator --bech val -a)

Prints an error:

error: Found argument 'signer' which wasn't expected, or isn't valid in this context

USAGE:
    gorc sign-delegate-keys [OPTIONS]

For more information try --help

1. cork/v1/proposal.json is still using "v3" as its go_package

2. cellarfees/v1/query.proto defines a Query/ModuleAccounts rpc method with "sommeliers" (note the extra 's' at the end) instead of "sommelier"

The agreed upon cellar_id format up to this point is of the format chainname:address (example: ethereum:0x4C4a2f8c81640e47606d3fd77B353E87Ba015584) but currently the cork module treats an ID as only the address. Steward currently requires IDs to be in this format. 0x4C4a2f8c81640e47606d3fd77B353E87Ba015584 can be approved by governance but the Steward cork submission will fail when steward checks for approval of ethereum:0x4C4a2f8c81640e47606d3fd77B353E87Ba015584.

Opening this issue to document the need for a solution.

Change bech32 human readable prefix from cosmos to somm

cc @zmanian @jackzampolin

In order to have a module account for the first set of cellars to send fees to before the staking distribution is set up, we need a mostly empty fee distribution module that will provide a constant module account address and later be upgraded to distribute the funds sent to it.

Add the ability for validators to schedule a cork to run at a future block height.

Bring docs up to date for the current mainnet (some of this already done in open PRs, will verify) to ensure easier onboarding for validators.

Add prometheus metrics for the oracle feeder. Some ideas:

• Last block height
• Successful transactions
• Successful graph queries

This will also allow easy setup for monitoring and alerting.

Start metrics server in this function
Prometheus Docs

https://github.com/VolumeFi/cellars/blob/main/contracts/CellarPoolShare.sol#L491

When creating a ContractCallTx in Gravity the calling module must assign the transaction an invalidation nonce and ID and track the created nonces and IDs in the calling module until they are either timed out (by the calling module) or have been been executed (ContractCallTxExecutedEvent from gravity).

The allocation module must handle this workflow

Add upgrade handler code for the addition of the cork module.

Summary of Bug

Unable to send from Ethereum to Cosmos. Sending cosmos to eth works. @jackzampolin 's theory is this is related to the fee upgrade on ethereum. @jkilpatr may have worked on something related.

Version

branch: main
sommelier: 0.1.3
network: sommtest-1

Reproduction Steps

user:~$ client eth-to-cosmos \
>     --ethereum-key="0x64201df2871d66fb088946431508cd09a592ea4e6787cddc0ebecfd4b6705acd" \
>     --ethereum-rpc="http://localhost:8545" \
>     --cosmos-prefix="cosmos" \
>     --contract-address="0x3E3EB9587d5a4DA21f1D8BCC1De45Eaf7f455523" \
>     --erc20-address="0x1f9840a85d5af5bf1d1762f925bdaddc4201f984" \
>     --amount="2.0000" \
>     --cosmos-destination="cosmos18trglj7kcvzptsjc9ug8yeg3dfs842qlwq8jet"
thread 'main' panicked at 'Failed to query ERC20 contract: JsonRpcError { code: -32000, message: "err: max fee per gas less than block base fee: address 0x65db01253515ad2Ea442F3c0dF083e99AeCC01D5, maxFeePerGas: 1 baseFee: 7 (supplied gas 50000000)", data: "None" }', client/src/main.rs:290:14

Create a generic pubsub module to support strategy provider registration and subscription.

Draft design doc here: https://docs.google.com/document/d/1gKW7dpEc6-LANN5KqjaMQEZYos6ROBJA4QyBlcZTqkI/edit#heading=h.my32d1p27hao

Problem Definition

As a validator I am risking my stake and providing a service to the network, I should not be charged fees for oracle transactions

Proposal

Use modular ante handlers to allow free oracle transactions for validators

Currently validators must vote every period on allocations. The plan is to use a modular ante-handler to prevent validators from paying gas on these transactions. If there is another desired method here (more sparse voting) we need a specification for it cc @zmanian

Run a testnet of a new release including the cork module.