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

[ELO-189] refactor el reader/writer to a config based approach #278

Merged
merged 8 commits into from
Jun 26, 2024

Conversation

shrimalmadhur
Copy link
Collaborator

@shrimalmadhur shrimalmadhur commented Jun 21, 2024

Fixes # .

What Changed?

  • Add a new config based constructor for EL reader and writer
  • Add nil checks so as to avoid nil pointer

Reviewer Checklist

  • Code is well-documented
  • Code adheres to Go naming conventions
  • Code deprecates any old functionality before removing it

@shrimalmadhur shrimalmadhur changed the title refactor to more config based approach refactor to make config based approach Jun 21, 2024
@shrimalmadhur shrimalmadhur requested a review from samlaf June 21, 2024 04:33
@shrimalmadhur shrimalmadhur force-pushed the madhur/refactor-el-reader branch from 846ab5b to 6edf46c Compare June 21, 2024 04:34
@shrimalmadhur shrimalmadhur changed the title refactor to make config based approach refactor el reader to a config based approach Jun 21, 2024
@shrimalmadhur shrimalmadhur changed the title refactor el reader to a config based approach [ELO-189] refactor el reader to a config based approach Jun 21, 2024
Copy link
Collaborator

@samlaf samlaf left a comment

Choose a reason for hiding this comment

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

Not super convinced by this. Honestly I think the better approach unfortunately is to fix the problem upstream, and to go fix the contracts so that they all point to each other and we only need to pass a single contract address, and we can recover all the other contracts from that one contract. Otherwise right now it's a bit confusing that I need to pass DM and AvsDirectory, but if I don't pass the DM, then I also don't get the slasher or SM, but the AvsDirectory is kind of its own little island.

types/config.go Outdated Show resolved Hide resolved
chainio/clients/elcontracts/reader.go Show resolved Hide resolved
chainio/clients/elcontracts/reader.go Outdated Show resolved Hide resolved
@shrimalmadhur
Copy link
Collaborator Author

Not super convinced by this. Honestly I think the better approach unfortunately is to fix the problem upstream, and to go fix the contracts so that they all point to each other and we only need to pass a single contract address, and we can recover all the other contracts from that one contract. Otherwise right now it's a bit confusing that I need to pass DM and AvsDirectory, but if I don't pass the DM, then I also don't get the slasher or SM, but the AvsDirectory is kind of its own little island.

I 100p agree that's the better approach but I feel it's not going to happen soon and we will be stuck with breaking changes anytime we need to add some contracts. we should still go with this even though it's not ideal and make it flexible IMO to unblock. If at any point in future, contracts gets fixed and we have one master registry contract, we could just update the config to have that and deprecate other fields and then just use master contract.

@samlaf samlaf force-pushed the madhur/refactor-el-reader branch from b0c43dc to ea8dc07 Compare June 25, 2024 23:24
@shrimalmadhur shrimalmadhur force-pushed the madhur/refactor-el-reader branch from ea8dc07 to 97c71a3 Compare June 26, 2024 00:50
@shrimalmadhur shrimalmadhur requested a review from samlaf June 26, 2024 00:53
@@ -116,7 +119,34 @@ func BuildELChainReader(
), nil
}

func BuildFromConfig(
Copy link
Collaborator

Choose a reason for hiding this comment

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

Should this just be called NewFromConfig? What's the rationale for using Build again?

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 don't have a strong pref. not sure why we used build in first place - maybe because it's building the bindings?

Copy link
Collaborator Author

@shrimalmadhur shrimalmadhur Jun 26, 2024

Choose a reason for hiding this comment

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

I have a better names now - b9ba1be

elcontracts.NewReaderFromConfig

I will add similar in future

elcontracts.NewWriterFromConfig
avsregistry.NewReaderFromConfig
avsregistry.NewWriterFromConfig

wdyt?

@samlaf samlaf force-pushed the madhur/refactor-el-reader branch from 25eb5d5 to 984c63d Compare June 26, 2024 06:35
@shrimalmadhur shrimalmadhur requested a review from samlaf June 26, 2024 17:44
@shrimalmadhur shrimalmadhur changed the title [ELO-189] refactor el reader to a config based approach [ELO-189] refactor el reader/writer to a config based approach Jun 26, 2024
@samlaf samlaf merged commit fcb5366 into dev Jun 26, 2024
4 checks passed
@samlaf samlaf deleted the madhur/refactor-el-reader branch June 26, 2024 19:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants