ethereum / ethereum/populus

Provider and Registrar refactory

Open
#411 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
No language data
Stars
319
Forks
110
PR merge metrics
No merged PRs in 30d

Description

### What was wrong?

Primary things that are being fixed here.

1. Dependency on the `Chain` class which is slated to be deprecated.
2. Registrar and Provider API should be independent.
3. Provider access to registrar should be done via provider backend API.

### How it should be fixed.

#### Step 1

Minimal code change to remove `chain` as dependency and switch to constructor taking `web3`, `registrar` and `provider_backends`.

#### Step 2

Refactor provider API to use *minimal* ERC190 package spec to store serialized packages.

- Introduce new API for setting package name in all places where storing deployments would happen.
- if a package name is not provided, create one using automated whole number versioning name generation. `ContractName-v1`.
- if package name is not provided raise `PendingDeprecation` warning indicating that it will be required *soon*
- store *all* deployments in a JSON document for the time being.
- figure out strategy for test runs to ensure we don't pollute the registrar JSON file.

#### Step 3

Decouple provider and registrar into independent backend APIs.

- `Registrar.record_package`
- `Registrar.lookup_package`
- `Provider.get_contract_address`
- `Provider.is_contract_available`
- `Provider.is_contract_available`
- `Provider.are_contract_dependencies_available`
- `Provider.get_contract_instance` (replaces and deprecates `Provider.get_contract`)
- `Provider.get_contract_factory`
- `Provider.get_base_contract_factory`
- Deprecate: `Provider.get_all_contract_data`
- Deprecate: `Provider.get_all_contract_names`
- Deprecate: `Provider.get_contract_data`

The term `contract_identifier` in these apis should use scheme similar to the one laid out in https://github.com/ethereum/populus/issues/373 for differentiating between which contract is being retrieved.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by tracing the Chain dependency and the Provider and Registrar APIs described in Steps 1–3. Review the contract identifier approach in issue #373, then map the listed API changes and deployment JSON requirements before defining tests for independent Provider and Registrar backends. Done means the deprecated Chain dependency is removed and the listed API and storage behavior are covered.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
backend-api-design, blockchain
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.