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.

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

[Multi-Chain] Add config file #412

Merged
merged 28 commits into from
Nov 15, 2024
Merged

[Multi-Chain] Add config file #412

merged 28 commits into from
Nov 15, 2024

Conversation

fhenneke
Copy link
Collaborator

@fhenneke fhenneke commented Nov 4, 2024

This PR adds a config file. This configuration is supposed to be extended to other chains in future PRs.

This PR adds a config AccountingConfig which consists of multple configurations for different aspects of the accounting.

The config is used as a global config. At the moment it is not explicitly passed to any function.

Next steps:

  • Pass config explicitly to functions.
  • Make some of the code more general to allow for using it on other chains.
  • Add support for other networks. (At the moment I only copied the testing setup on other chains from the original code.)
  • Make config more consistent.

There are still hardcoded constants somewhere in the code. One place is when fetching prices in converting token values, via an ID. The id cannot be part of the config due to circular imports. Instead, an address or id string should be passed and the pricing code should turn it into an appropriate type.

How to review

The first two commits (the names are wrong, I might force push correct ones) add a config and use the config throughout the code. The third commit just removes the old constants file.

One discussion should mostly be about the first commit, i.e. the one adding the configuration classes in config.py.

  • Should the config be structured differently?
  • Do we need special treatment of secrets?

Another discussion would be around how to move forward from here.

  • Should we pass the config struct more explicitly? (That is what I did in the more complete code I have.)
  • Which parameters are probably still missing for making it work on other chains?

since tests need this variable
this should be removed later. we should
- add special handling of secrets, or
- check this variable at the start of the script
remove token_list again
@harisang
Copy link
Contributor

harisang commented Nov 5, 2024

@fhenneke can you rebase once the easy PRs are merged, and in case it is ready for review, let's also remove the "draft" label

# Conflicts:
#	tests/unit/test_models.py
@fhenneke fhenneke marked this pull request as ready for review November 6, 2024 16:10
@fhenneke
Copy link
Collaborator Author

fhenneke commented Nov 6, 2024

The things which can already be discussed are:

  • The structure of the config class. Is anything obvious missing? Are the abstractions reasonable, i.e., the split into separate configs for rewards, protocol fees, buffer accounting, general payment information, input output config.
  • The general design of having a config which can later be passed to all payment functions. That would make it easy to switch between configs without keeping track when environment variables are available. It also makes it easier to check that the config is correct, e.g., that the private key is set if the post transaction command line flag is set.

src/config.py Outdated Show resolved Hide resolved
src/config.py Outdated Show resolved Hide resolved
src/config.py Outdated Show resolved Hide resolved
this addresses review comments
- uses an enum instead of a string for better checking of network values
- move initialization of configs into individual classes: use from_network and from_env to initialize classes
mostly by adding comments
fhenneke added a commit that referenced this pull request Nov 10, 2024
This PR slightly restructures the price fetching for converting token
amount for rewards.

- Instead of having functions for converting to and from ETH
(`eth_in_token`, `token_in_eth`) we just provide an exchange rate for
conversion between two tokens (`exchange_rate_atoms`). This will make it
easier to add conversion between COW and the native token of the chain,
as well as between XDAI and ETH.
- Instead of using token ids as argument, the main function accepts
addresses. This is mostly to avoid leaking the implementation of the
price fetching (token id on coin paprika) into the rest of the code. It
also avoids a circular dependency in making the reward token part of the
configuration in #412.

The `TokenId` abstraction still feels a bit stange as there is some
overlap with `Token` due to decimals. Supporting USDC seems a bit
artificial since that is only used for testing and checking that
decimals are correctly accounted for.

Tests for price fetching were adapted accordingly. Transfers for the
accounting week starting on 2024-10-29 only differ on the level of
floating point precision.

---------

Co-authored-by: Haris Angelidakis <[email protected]>
# Conflicts:
#	src/fetch/payouts.py
# Conflicts:
#	src/fetch/payouts.py
#	tests/unit/test_payouts.py
src/config.py Outdated Show resolved Hide resolved
src/config.py Outdated
"""Initialize node config for a given network."""
# Found this exposed infura key on https://rpc.info/
infura_key = os.environ.get("INFURA_KEY", "9aa3d95b3bc440fa88ea12eaa4456161")
node_url = f"https://{network}.infura.io/v3/{infura_key}"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PR #430 simplifies a bit this part

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The new environment variable is used now.

src/config.py Outdated
safe_url = (
f"https://app.safe.global/{short_name}:{payment_safe_address}"
)
airdrop_url = (
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we remove this? Seems like an overkill

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can remove it, as it also did not work for me when I tried it some time ago.

Generally, I think we should provide instructions as part of error messages and logging as much as possible.

# Conflicts:
#	src/config.py
Copy link
Contributor

@harisang harisang left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense overall, although i admit i haven;t thought too much about its structure.

Definitely nice to save on a lot of imports and random constants showing up in various files.

@fhenneke fhenneke merged commit 0870ebf into main Nov 15, 2024
5 checks passed
@fhenneke fhenneke deleted the add_config branch November 15, 2024 16:18
@github-actions github-actions bot locked and limited conversation to collaborators Nov 15, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants