-
Notifications
You must be signed in to change notification settings - Fork 7
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #27 from onflow/bastian/add-old-cadence-meeting-notes
- Loading branch information
Showing
19 changed files
with
2,992 additions
and
1 deletion.
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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1 +1,3 @@ | ||
| .idea | ||
| .idea | ||
| .DS_Store | ||
|
|
106 changes: 106 additions & 0 deletions
106
cadence_language_and_execution_working_group/meetings/2022-07-22.md
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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,106 @@ | ||
|
|
||
| # July 22, 2022 | ||
|
|
||
| ## External Mutability | ||
|
|
||
| - FLIP that prevents external mutation was approved, implemented, and released in Secure Cadence: | ||
| [https://github.com/onflow/flow/pull/703](https://github.com/onflow/flow/pull/703) | ||
| - Open problems: | ||
| - Composites were not covered by the FLIP, only arrays and dictionaries | ||
| - Externally taking a reference to a field can circumvent the external mutability restriction | ||
| - New FLIP: [https://github.com/onflow/flow/pull/1056](https://github.com/onflow/flow/pull/1056) | ||
| - Purity/mutability modifier for functions | ||
| - Automatic analysis to determine if function has side-effects | ||
|
|
||
| ## Condition can currently have side effects | ||
| - https://github.com/onflow/cadence/issues/1805 | ||
| - Might be used for underhanded code: Post-condition might perform mutation. Example: FT withdrawal | ||
| - Might be solved by purity FLIP | ||
| - Can a pure function emit events? | ||
| - Does affect on-chain state, but is not observable | ||
| - Are other side-effecting functons like debugging logging allowed? | ||
| - "Pure" vs "no side-effects" | ||
| - "Pure" usually means no side-effects at all | ||
| - Have to be pragmatic | ||
| - Alternatives: | ||
| - Prevent calls in general | ||
| - Run-time errors if there are side-effects | ||
|
|
||
| ## Remove deprecated key API | ||
| - We currently have two key management APIs: | ||
| - `AuthAccount.addPublicKey`/`AuthAccount.removePublicKey`: | ||
| - Low-level, accepts encoded key as byte array | ||
| - Deprecated a year ago | ||
| - [`AuthAccount.keys.add`](https://docs.onflow.org/cadence/language/accounts/#add-account-keys)/`AuthAccount.keys.remove` | ||
| - High-level, accepts key as object (`PublicKey`) | ||
| - Added a year ago | ||
| - We attempted to remove the deprecated in the Secure Cadence release | ||
| - Rolled back, as it will break client applications if they use SDK which uses deprecated API | ||
| - Also: Events that are emitted when a key is added is inconsistent, depends on which API is used: https://github.com/onflow/cadence/issues/1796 | ||
| - Do we have metrics on how many SDKs are still using the deprecated API? | ||
| - Actionables: | ||
| - Add deprecation annotation to developer tooling | ||
| - Pragma, e.g. `#deprecated` | ||
| - Comment, e.g. `@deprecated` | ||
| - Add support in VS Code, render as ~~addPublicKey~~ | ||
|
|
||
| ## Interface default methods | ||
| - https://github.com/onflow/cadence/pull/1076 | ||
| - Proposed for NFT metadata standard | ||
| - Helps with preventing breakage in ecosystem | ||
| - Avoid copy/paste and boilerplate, making code reusable | ||
| - Does not help with FT/NFT rewrite proposal | ||
| - Useful for utility/convenience functions, reducing boilerplate | ||
| - Open Questions: | ||
| - Security implications? | ||
| - Related: | ||
| - Post-conditions with side-effects | ||
| - Mutability | ||
| - Restrict to pure functions? Potentially too restrictive, e.g. couldn’t provide | ||
| - Maybe allow opt out of mutating functions. But could also be used to opt-out of a fix | ||
| - Examples? | ||
| - Trust relationship problem | ||
| - Already have this problem with contract updates | ||
| - Modification of default implementation | ||
| - Would be useful to provide utility functions, like FT transfer | ||
| - It should not be possible to perform malicious code, as the same could be done in a non-default function | ||
| - Not a breaking change, could merge and ship before Stable Cadence | ||
| - When there is a conflict, e.g multiple interfaces provide default implementation: | ||
| - No "winner" is selected by default | ||
| - Instead, the user is required to provide an implementation | ||
| - Follow up feature: Interface requirements | ||
| - Declaration site: `CI1: CI2` | ||
| - Use-site would still have to explicitly declare conformance for all interfaces: `C: CI1, CI2` | ||
|
|
||
| ## Storage Querying/Iteration API | ||
| - https://github.com/onflow/cadence/issues/208 | ||
| - Finally added technical foundation a couple months ago: | ||
| Account storage data is now stored in [atree](https://github.com/onflow/atree) values | ||
| (atree is Cadence's storage layer) | ||
| - Issue lays out proposal for adding API to iterate over account paths/values | ||
| - Outstanding issues: | ||
| - Accounts may store a lot of data. Pagination iteration? Iterator, cursor, enumerator | ||
| - Concrete API proposal | ||
| - First use-case: Developer tools like the Emulator and Playground | ||
| - Need to show wallet developers how they can render information to users | ||
| - Mutability not necessarily a problem: Run script against block. | ||
| - Problem: data availability | ||
| - Might be solved in future by "historic" data node | ||
| - Storage Layer: | ||
| - Iteration over dictionary changes when mutated | ||
| - Keys are hashed | ||
| - Start with MVP | ||
| - Stages: | ||
| - 1. Even useful if pagination problem is not solved yet | ||
| - 2. Pagination for larger accounts | ||
| - 3. Support for handling mutation | ||
| - Also useful for e.g. dictionary, keys. Might be too large | ||
| - Keys on demand | ||
| - E.g. useful to pick a random key | ||
|
|
||
| ## Organisational | ||
|
|
||
| - Should we move this meeting so it is not on a Friday evening for folks in Europe? | ||
| - Not Friday, not Monday | ||
| - Tuesday is best | ||
| - Same time (8am PT) |
93 changes: 93 additions & 0 deletions
93
cadence_language_and_execution_working_group/meetings/2022-08-30.md
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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,93 @@ | ||
| # August 30, 2022 | ||
|
|
||
| * We discussed the currently open FLIPs | ||
|
|
||
| * **Remove public resource fields:** | ||
| * https://github.com/onflow/flow/pull/739 | ||
| * Status: | ||
| - No consensus | ||
| * Open problems: | ||
| - None | ||
| * Next steps: | ||
| - Ask author (Dete) | ||
|
|
||
| * **Capability Controllers:** | ||
| * https://github.com/onflow/flow/pull/798 | ||
| * Status: | ||
| * More API discussions (delegation, revocation) | ||
| * Exploring how to make APIs/use-casess simpler to use/understand | ||
| * Sentiment: proposal OK, but also want to cover more use-cases | ||
| * Maybe split proposal? At least gather use-cases, maybe propose functionality in separate FLIP(s) | ||
| * Next steps: | ||
| * Meeting | ||
| * Finish use-case gathering | ||
| * Open problems: | ||
| * Should capabilities be resources? Agreement they should be values | ||
| * Relation to extensibility proposal → some use-cases could be covered by extensibility ([FLIP 1101](https://github.com/onflow/flow/pull/1101)) | ||
| * It would be great to have account identity (-> [FLIP 945](https://github.com/onflow/flow/pull/945)), do not have to be storable, only needs to prove | ||
| * Cons: tied to identity, not transferable between accounts owned by same person | ||
| * Alternative (?): wrapping/unwrapping (pattern instead of new language feature) | ||
| * Alternative (?): sharing using account | ||
|
|
||
| * **Add identity to AuthAccount:** | ||
| * https://github.com/onflow/flow/pull/945 | ||
| * Status: | ||
| * Maybe not needed if capability controllers proposal gets added (?) | ||
| * Missing use-case / documentation | ||
| * Many cons, alternatives exist → need to be added to FLIP | ||
| * Next steps: | ||
| * Add cons to proposal | ||
| * Extend article with why identity resource is not a good alternative | ||
| * Promote safe patterns for identity/access control | ||
| * Open problems: | ||
| * "Too easy" to use instead of capabilities introduces a footgun. | ||
| But: just another tool for access control, useful for certain use-cases, still recommend capabilities | ||
| * Possible to pass on identity, potentially a malicious program pretends it has access | ||
| * But also *not* providing identity will cause developers to create their own potential unsafe. Cannot prevent it | ||
| * Alternative: instead of passing identity around, code wraps value for target, target has secret unwrapper | ||
|
|
||
| * **Purity/mutability analysis:** | ||
| * https://github.com/onflow/flow/pull/1056 | ||
| * Status: | ||
| * Simplified original proposal | ||
| * Consensus | ||
| * Next steps: | ||
| * Merge PRs into feature branch, let people try it out | ||
| * Make decision on FLIP | ||
| * Notes: | ||
| * `pure` was changed to `view`, like in Solidity | ||
| * Open problems: | ||
| * None | ||
|
|
||
| * **Extensibility:** | ||
| * https://github.com/onflow/flow/pull/1101 | ||
| * Status: | ||
| * Many open problems | ||
| * Unclear definition of problem | ||
| * Next steps: | ||
| * Meeting | ||
| * Clearly defining use-case / features | ||
| * Open problems: | ||
| * Current proposal has many open questions / edge cases | ||
| * Unclear what features should be provided by proposal | ||
|
|
||
| * **Add fields during contract update:** | ||
| * https://github.com/onflow/flow/pull/1097 | ||
| * Status: | ||
| * Good start | ||
| * Need to answer outstanding questions | ||
| * Overall agreement, probably gets approved/implemented once details figured out | ||
| * Next steps: | ||
| * Meeting | ||
| * Open problems: | ||
| * Migration | ||
| * Field removal | ||
| * Syntax | ||
|
|
||
| * **Invalidate references to transferred resources:** | ||
| * https://github.com/onflow/flow/pull/1043 | ||
| * Status: | ||
| * Paused discussion on this, hoped to have [FLIP 1056](https://github.com/onflow/flow/pull/1056) solve this | ||
| * Need to increase priority | ||
| * Open problems: | ||
| * ? |
Oops, something went wrong.