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

Crescendo #164

Merged
merged 34 commits into from
May 28, 2024
Merged

Crescendo #164

merged 34 commits into from
May 28, 2024

Conversation

austinkline
Copy link
Collaborator

This PR covers changes needed to upgrade HybridCustody to Cadence 1.0

Some key points:

  1. Private Paths are not going to be in Cadence 1.0, so our standard path for getCapability that takes a CapabilityPath type had to be moved to take a Capability Controller ID instead.
  2. Because there are no private paths, we now have to use storage iteration for clearing out existing capabilities when things like ownership updates or sealing change.
  3. There are 4 entitlements added to the HybridCustody contract. Three of them map to a resource, and one of them is added just for publishing an account to a parent from a child.
  4. ResourceDestroyed events have been added to each core resource type. There was an issue with emitting some fields we might want in the event which might need some follow-up
  5. You can no longer get a public capability without so retrieving a public capability had to be moved to the CapabilityFactory interface.
  6. Since HybridCustody takes in a full AuthAccount reference currently, we have migrated all AuthAccount types to a fully entitled &Account reference. It does seem to need nearly all of them with the exception of the Contract entitlement.

The main questions coming out of this work as I see them are around Entitlements and whether the use of each entitlement gives us the access control pattern(s) we want. Personally, I had a hard time justifying splitting entitlements beyond each resource type.

Copy link
Member

@joshuahannan joshuahannan left a comment

Choose a reason for hiding this comment

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

Just reviewed the contracts so far. They look pretty good! I made some comments about migrating capability types, but I'm not 100% sure about the answer, so I didn't put it on every single instance that the comment would apply to in case I'm wrong. I'll flag the other ones if it turns out I am right

contracts/HybridCustody.cdc Outdated Show resolved Hide resolved
contracts/HybridCustody.cdc Outdated Show resolved Hide resolved
contracts/HybridCustody.cdc Outdated Show resolved Hide resolved
contracts/HybridCustody.cdc Show resolved Hide resolved
contracts/HybridCustody.cdc Outdated Show resolved Hide resolved
contracts/CapabilityDelegator.cdc Outdated Show resolved Hide resolved
contracts/CapabilityDelegator.cdc Outdated Show resolved Hide resolved
contracts/CapabilityDelegator.cdc Show resolved Hide resolved
contracts/CapabilityFactory.cdc Outdated Show resolved Hide resolved
contracts/CapabilityDelegator.cdc Outdated Show resolved Hide resolved
@@ -27,39 +29,43 @@ import "CapabilityFilter"
///
/// Repo reference: https://github.com/onflow/hybrid-custody
///
pub contract HybridCustody {
access(all) contract HybridCustody {
access(all) entitlement Owner
Copy link

Choose a reason for hiding this comment

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

I think adding some notes about entitlements that explains what permission they will give is good here. Like will Owner give you all of the below or not? I think best practise in flow around entitlements should describe what they do briefly where they are defined. thoughts?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Not opposed at all. I started writing some comments out for each entitlement then realized they might just end up changing anyway which is why they're missing right now

contracts/HybridCustody.cdc Outdated Show resolved Hide resolved
contracts/HybridCustody.cdc Outdated Show resolved Hide resolved
contracts/HybridCustody.cdc Outdated Show resolved Hide resolved
contracts/HybridCustody.cdc Show resolved Hide resolved
Copy link
Collaborator

@sisyphusSmiling sisyphusSmiling left a comment

Choose a reason for hiding this comment

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

Great refactor so far, thank you! I was only able to look over the contracts, but left some comments. I'm also wondering if we'll need to introduce new Factory implementations for deployment covering Vault & Collection with the migration given the move from nested resources to interfaces within FT & NFT v2 standards.

contracts/CapabilityFactory.cdc Outdated Show resolved Hide resolved
contracts/CapabilityFilter.cdc Outdated Show resolved Hide resolved
contracts/factories/FTAllFactory.cdc Show resolved Hide resolved
contracts/factories/FTAllFactory.cdc Show resolved Hide resolved
contracts/factories/FTAllFactory.cdc Outdated Show resolved Hide resolved
contracts/HybridCustody.cdc Outdated Show resolved Hide resolved
contracts/HybridCustody.cdc Show resolved Hide resolved
contracts/HybridCustody.cdc Show resolved Hide resolved
contracts/HybridCustody.cdc Outdated Show resolved Hide resolved
contracts/HybridCustody.cdc Outdated Show resolved Hide resolved
@austinkline
Copy link
Collaborator Author

Quick update to this PR that I'm back from a company offsite so we're picking this up again.

Core questions are around entitlements (expected, I'll start focusing on them soon), and on how migrations are going to work.

For migrations, my understanding right now is that all capabilities are going to be migrated to their conformance types. That is Capability<&T{I}> will be migrated to Capability<&{I}> in all cases. So if we want things to migrate successfully, it is the right thing to go with Capability<&{I}> versus Capability<&T>. I will operate on this assumption and then ask Bastian or someone else on the cadence team to review what they can before we finalize all of this

@codecov-commenter
Copy link

codecov-commenter commented Apr 12, 2024

Codecov Report

Attention: Patch coverage is 89.74359% with 8 lines in your changes are missing coverage. Please review.

Project coverage is 91.48%. Comparing base (84bb6f3) to head (756be5f).

Files Patch % Lines
contracts/HybridCustody.cdc 89.61% 8 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #164      +/-   ##
==========================================
+ Coverage   83.95%   91.48%   +7.52%     
==========================================
  Files           4        4              
  Lines         349      364      +15     
==========================================
+ Hits          293      333      +40     
+ Misses         56       31      -25     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Collaborator

@sisyphusSmiling sisyphusSmiling left a comment

Choose a reason for hiding this comment

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

Only got through the contracts again but can revisit tomorrow to cover txns & scripts. The entitlement assignments make sense to me, they look well done! Just have one question about GetterPrivate using Get vs Capabilities - curious what you think there.

contracts/HybridCustody.cdc Show resolved Hide resolved
contracts/HybridCustody.cdc Outdated Show resolved Hide resolved
contracts/standard/ExampleNFT.cdc Show resolved Hide resolved
contracts/standard/ExampleToken.cdc Show resolved Hide resolved
contracts/standard/ExampleToken.cdc Show resolved Hide resolved
contracts/standard/ExampleToken.cdc Show resolved Hide resolved
contracts/standard/ExampleToken.cdc Show resolved Hide resolved
contracts/standard/ExampleToken.cdc Show resolved Hide resolved
contracts/CapabilityDelegator.cdc Show resolved Hide resolved
Copy link
Collaborator

@sisyphusSmiling sisyphusSmiling left a comment

Choose a reason for hiding this comment

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

Great work!

Update: All HC contracts (except FTVaultFactory and NFTCollectionFactory) up to 2b22935 on crescendo branch have been staged on Testnet. However, as-is I needed to skip validation due to errors. See ongoing discussion around migration errors in this discord thread.

@sisyphusSmiling
Copy link
Collaborator

sisyphusSmiling commented May 2, 2024

Update after latest migration - looks like migration failed. A couple failures stand out:

  1. References to NonFungibleToken.Owner entitlement caused failures in NFTProviderFactory and NFTProviderAndCollectionFactory
  2. Disjunction access modifiers in CapabiltyFactory, CapabiltyFilter and CapabiltyDelegator resulted in unsafe entitlements migration.
  3. Capabilities no longer return optional values which resulted in failures within HybridCustody, but I'm sure there are occurrences elsewhere throughout transactions/scripts where capability retrieval is optionally chained
  4. OwnedAccount.removeParent is access(Owner | Remove) while OwnedAccountPrivate interface modifier is simply Owner

I think addressing these should fix the migration issue. We'll need a new pre-release version of CLI (currently in progress) to validate the changes via Cadence tests though since the capability retrieval pattern has been updated since the current v1.18.0-cadence-v1.0.0-preview.22

@austinkline
Copy link
Collaborator Author

Update after latest migration - looks like migration failed. A couple failures stand out:

  1. References to NonFungibleToken.Owner entitlement caused failures in NFTProviderFactory and NFTProviderAndCollectionFactory
  2. Disjunction access modifiers in CapabiltyFactory, CapabiltyFilter and CapabiltyDelegator resulted in unsafe entitlements migration.
  3. Capabilities no longer return optional values which resulted in failures within HybridCustody, but I'm sure there are occurrences elsewhere throughout transactions/scripts where capability retrieval is optionally chained
  4. OwnedAccount.removeParent is access(Owner | Remove) while OwnedAccountPrivate interface modifier is simply Owner

I think addressing these should fix the migration issue. We'll need a new pre-release version of CLI (currently in progress) to validate the changes via Cadence tests though since the capability retrieval pattern has been updated since the current v1.18.0-cadence-v1.0.0-preview.22

Thanks for summarizing 🙏

I believe I've addressed everything for this week's migration, but if we're able to dry-run it locally that's probably a good idea as well

@sisyphusSmiling
Copy link
Collaborator

Local migration passed! All contracts up to this point have been staged on Testnet, so we'll get a sanity check in the next network migration run.

@sisyphusSmiling
Copy link
Collaborator

Following up on office hours discussion about merging these changes. Looks like the past two migrations have been successful. Maybe we a last call for reviews before merging - thoughts @austinkline?

@austinkline
Copy link
Collaborator Author

Following up on office hours discussion about merging these changes. Looks like the past two migrations have been successful. Maybe we a last call for reviews before merging - thoughts @austinkline?

Good with me! I'll reach out to folks and see if we can't get some approvals/comments going

@austinkline
Copy link
Collaborator Author

Merging! Thanks everyone for the feedback and participation in this PR. We still have time until Crescendo goes live, so if there are any other things that come up or need addressing, please open a ticket and flag it 🙏

https://discord.com/channels/613813861610684416/1162086721471647874/1245041945013780601

@austinkline austinkline merged commit 1a4224c into main May 28, 2024
1 check passed
@austinkline austinkline deleted the crescendo branch May 28, 2024 20:25
sisyphusSmiling added a commit that referenced this pull request Sep 6, 2024
Closes: #165 #171

### Description

- Replaces existing node modules dependency system with Flow CLI's
dependency manager for consistency with other onflow repos
- Updates CI commands to use the Flow CLI `flow` command found in
`v2.0.0`
- Removes Previewnet deployment addresses as that network will be
deprecated
- Removes the code normalization script which has been integrated with
the `flow test` command
- Removes the outdated `.gitmodules` file, a remnant from when this repo
used git submodules

Also, outside of the context of this PR, the new `NFTCollectionFactory`
and `FTVaultFactory` (#164) contracts have been deployed on Testnet &
Mainnet. After deployment, the existing hosted factory managers (see
README) have been configured with the setup transactions already found
in this repo.
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.

7 participants