Upgrading the smart contracts or program binary is a more important process than we are currently treating it. With Eigenlayer updated and Tangle updating, staying up-to-date on your blueprint will actually be a crucial part of the blueprint development lifecycle.
This includes
Smart contract upgrading and versioning.
Gadget binary upgrading and versioning.
Onchain upgrading and versioning.
We must take this into account with priority. Making it easy to upgrade and re-deploy changes to your blueprint / AVS system will be important for making this SDK developer friendly.
Tangle
On Tangle, we should have a versioning/git-like structure for updating your blueprint metadata. Old metadata should be preserved and back-linked from new metadata. Initial implementations here should avoid complexity with respect to malicious behavior and provide a clear API for dealing with blueprint upgrade-ability. For example, we can make the blueprint developer deployer account in control of this process and allow them to transfer this responsibility to any other origin/EVM account.
Eigenlayer
We should investigate how other teams have dealt with upgrading their Eigenlayer contract systems and binaries. This process is likely to be offchain and done through social channels: "Hey [OPERATOR], we've updated our node please download the new one and re-run". We should consider tooling for how we might streamline this but at the very least provide documentation on how we think this should happen.
Any upgrade path should be done with research and investigation into existing upgrade methods.
Overview
Upgrading the smart contracts or program binary is a more important process than we are currently treating it. With Eigenlayer updated and Tangle updating, staying up-to-date on your blueprint will actually be a crucial part of the blueprint development lifecycle.
This includes
We must take this into account with priority. Making it easy to upgrade and re-deploy changes to your blueprint / AVS system will be important for making this SDK developer friendly.
Tangle
On Tangle, we should have a versioning/git-like structure for updating your blueprint metadata. Old metadata should be preserved and back-linked from new metadata. Initial implementations here should avoid complexity with respect to malicious behavior and provide a clear API for dealing with blueprint upgrade-ability. For example, we can make the blueprint developer deployer account in control of this process and allow them to transfer this responsibility to any other origin/EVM account.
Eigenlayer
We should investigate how other teams have dealt with upgrading their Eigenlayer contract systems and binaries. This process is likely to be offchain and done through social channels: "Hey [OPERATOR], we've updated our node please download the new one and re-run". We should consider tooling for how we might streamline this but at the very least provide documentation on how we think this should happen.
Any upgrade path should be done with research and investigation into existing upgrade methods.