-
Notifications
You must be signed in to change notification settings - Fork 187
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
feat(node): support execution without ecdsa key #438
Merged
jianoaix
merged 3 commits into
Layr-Labs:master
from
jeffhubCB:node-runtime-without-ecdsa-key
Apr 4, 2024
Merged
Changes from all commits
Commits
Show all changes
3 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if you just set some dummy keys for these two flags on the machine running the node, and then use the real keys on other machine to opt-in/out? That way it doesn't even need to make this change?
The
PubIPCheckIntervalFlag
can be set 0 do disable the IP checker. Then there will be no need of (real) keys for node.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Setting it to a dummy key is certainly an option, but I believe supporting this as a valid runtime option, versus expecting users that want to run in this configuration to know they can generate a dummy ECDSA key and use that, seems like a better user experience.
Additionally, by not providing a key at all it ensures failure on startup if the key is needed (given the changes in this PR), versus failure at a later point while running when the provided dummy key (to get eigenda node to start, because it won't otherwise) tries to use that key.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jianoaix Dummy keys is a confusing concept. Generally, my understanding is that an Operator can associate with any number of AVSs which are run separately - this arrangement should not require privileged access to the privkeys of the Operator at all. More than that though, if it did require access to the Operators private keys then the opt in/out process would be unnecessary. Please clarify if that was not the intent of the Operator AVS relationship.
In the context then that Operators and AVSs are intended to be separately owned entities, I would suggest that providing the Operator privkey be an option rather than a default with clear documentation about why you might want to do this. Even then though this is not really a clear separation of ownership nor does it communicate the intended relationships.
Dummy keys does not address this ambiguity of ownership, rather it reinforces it by requiring a user to know when to use dummy keys or when to use real keys (should be never) - in reality its seems you almost never want the AVS to have access to the Operators keys.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are lifecycle operations needed to register/deregister an AVS that is consistent with all AVSes. Those operations require the Operator private key, but that does not equate to "the AVS should always have access to the Operator private key in its default running state". The separation and usage of the Operator ECDSA key, versus the AVS BLS key, should be much clearer than the current implementation demonstrates.
I believe
node
requires the private key today because of the way the codebase was originally structured, as well as the auto-socket-update (which can easily be disabled by default, with docs explaining how to enable it and the implications... gas fees, requirement to provide the ECDSA key to node w/ those security implications, etc). There are shared code paths between node, node-plugin, retriever and disperser. I believe only 2 of these need the ECDSA key... node-plugin (for opt-in/update-socket) and disperser. Because of this setup, the code was written to assume the ECDSA key is always required, leading to a situation where additional code can readily be added to leverage it at runtime when that should not be encouraged.The scope of this PR wasn't intended to clean all of that up and formalize it more, it was an initial step so that the EigenDA Node Operator can be run without providing the Node Operator ECDSA key (or a dummy key), to increase security posture and ideally encourage further changes, in both documentation and implementation, that will enable a more secure deployment pattern and encourage the rest of the AVS community to do the same.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are valid points. Note I'm not against having a proper solution. I'm suggesting a way to workaround to quickly unblock the use case you are looking for.