From 334737547ed9f04d484af7c01d8fb05a6175bf42 Mon Sep 17 00:00:00 2001 From: PhilWindle Date: Thu, 15 Feb 2024 17:22:02 +0000 Subject: [PATCH 1/7] Refactoring of private message delivery section of yellow paper --- .../docs/pre-compiled-contracts/index.md | 5 +++ .../registry.md | 0 .../encryption-and-decryption.md | 21 ---------- .../docs/private-message-delivery/index.md | 6 --- .../note-discovery.md | 21 ---------- .../private-msg-delivery.md | 41 +++++++++++++++++-- .../send-note-guidelines.md | 6 +-- 7 files changed, 45 insertions(+), 55 deletions(-) create mode 100644 yellow-paper/docs/pre-compiled-contracts/index.md rename yellow-paper/docs/{private-message-delivery => pre-compiled-contracts}/registry.md (100%) delete mode 100644 yellow-paper/docs/private-message-delivery/encryption-and-decryption.md delete mode 100644 yellow-paper/docs/private-message-delivery/note-discovery.md diff --git a/yellow-paper/docs/pre-compiled-contracts/index.md b/yellow-paper/docs/pre-compiled-contracts/index.md new file mode 100644 index 00000000000..630273e4b44 --- /dev/null +++ b/yellow-paper/docs/pre-compiled-contracts/index.md @@ -0,0 +1,5 @@ +# Pre-Compiled Contracts + +import DocCardList from '@theme/DocCardList'; + + \ No newline at end of file diff --git a/yellow-paper/docs/private-message-delivery/registry.md b/yellow-paper/docs/pre-compiled-contracts/registry.md similarity index 100% rename from yellow-paper/docs/private-message-delivery/registry.md rename to yellow-paper/docs/pre-compiled-contracts/registry.md diff --git a/yellow-paper/docs/private-message-delivery/encryption-and-decryption.md b/yellow-paper/docs/private-message-delivery/encryption-and-decryption.md deleted file mode 100644 index a00e82bea19..00000000000 --- a/yellow-paper/docs/private-message-delivery/encryption-and-decryption.md +++ /dev/null @@ -1,21 +0,0 @@ -# Encryption and Decryption - -Applications should be able to provably encrypt data for a target user, as part of private message delivery. As stated in the Keys section, we define three types of encrypted data, based on the sender and the recipient, from the perspective of a user: - -- Incoming data: data created by someone else, encrypted for and sent to the user. -- Outgoing data: data created by the user to be sent to someone else, encrypted for the user. -- Internal incoming data: data created by the user, encrypted for and sent to the user. - -Encryption mechanisms support these three types of encryption, which may rely on different keys advertised by the user. - -## Precompiles and Note Discovery - -Even though encryption is a well-solved problem, unlike note discovery, the protocol bundles both operations together for simplicity and efficiency. Most use cases call for encryption and note tagging to be executed together, so note tagging precompile contracts are expected to handle encryption as well. This allows users to choose their preferred encryption method, trading between encryption cost and bits of security. - -## Key Abstraction - -To support different kinds of encryption mechanisms, the protocol does not make any assumptions on the type of public keys advertised by each user. Validation of their public keys is handled by the precompile contract selected by the user. - -## Provable Decryption - -While provable encryption is required to guarantee correct private message delivery, provable decryption is required for disclosing activity within an application. This allows auditability and compliance use cases, as well as being able to prove that a user did not execute certain actions. To support this, encryption precompiles also allow for provable decryption. diff --git a/yellow-paper/docs/private-message-delivery/index.md b/yellow-paper/docs/private-message-delivery/index.md index c15f4cb06cf..679d3e9abb5 100644 --- a/yellow-paper/docs/private-message-delivery/index.md +++ b/yellow-paper/docs/private-message-delivery/index.md @@ -2,12 +2,6 @@ title: Private Message Delivery --- - - # Private Message Delivery Private message delivery encompasses the encryption, tagging, and broadcasting of private messages on the Aztec Network. diff --git a/yellow-paper/docs/private-message-delivery/note-discovery.md b/yellow-paper/docs/private-message-delivery/note-discovery.md deleted file mode 100644 index 8f4bee16e39..00000000000 --- a/yellow-paper/docs/private-message-delivery/note-discovery.md +++ /dev/null @@ -1,21 +0,0 @@ - - -# Note Discovery - -When users interact with contracts they will generate and publish encrypted notes for other network participants. In order for a user to consume notes that belong to them, they need to identify, retrieve and decrypt them. A simple, privacy-preserving approach to this would be to download all of the notes and attempt decryption. However, the total number of encrypted notes published by the network will be substantial, making it infeasible for some users to do this. Those users will want to utilize a note discovery protocol to privately identify their notes. - -## Precompiles - -A number of techniques currently exist to help with note discovery and it is a field into which a lot of research is being conducted, where each technique has its tradeoffs. Therefore, our approach is not to dictate a specific note discovery mechanism, but to implement multiple options via precompiles that users can choose from. These precompiles define both encryption and tagging mechanisms, and allow constraining their correct execution. Additionally, through this approach we allow for integration of new or improved protocols in the future. - -> Note: Constraining tag generation is not solely about ensuring that the generated tag is of the correct format. It is also necessary to constrain that tags are generated in the correct sequence. A tag sequence with duplicate or missing tags makes it much more difficult for the recipient to retrieve their notes. This will likely require tags to be nullified once used. - -## Tag Abstraction - -When applications produce notes they will need to call a protocol defined function within the account contract of the recipient and request that a tag be generated. From the protocol's perspective, this tag will simply be a stream of bytes relevant only to the recipient's note discovery protocol. It will be up to the account contract to constrain that the correct tag has been generated and from there the protocol circuits along with the rollup contract will ensure that the tag is correctly published along with the note. - -## User Handshaking - -Even if Alice correctly encrypts the note she creates for Bob and generates the correct tag to go with it, how does Bob know that Alice has sent him a note? Bob's note discovery protocol may require him to speculatively 'look' for notes with the tags that Alice (and his other counterparties) have generated. If Alice and Bob know each other then they can communicate out-of-protocol. But if they have no way of interacting then the network needs to provide a mechanism by which Bob can be alerted to the need to start searching for a specific sequence of tags. - -To facilitate this we will deploy a canonical 'handshake' contract that can be used to create a private note for a recipient containing the sender's information (e.g. public key). It should only be necessary for a single handshake to take place between two users. The notes generated by this contract will be easy to identify enabling users to retrieve these notes, decrypt them and use the contents in any deterministic tag generation used by their chosen note discovery protocol. diff --git a/yellow-paper/docs/private-message-delivery/private-msg-delivery.md b/yellow-paper/docs/private-message-delivery/private-msg-delivery.md index 04ba5fcdd0e..a62e3df3e76 100644 --- a/yellow-paper/docs/private-message-delivery/private-msg-delivery.md +++ b/yellow-paper/docs/private-message-delivery/private-msg-delivery.md @@ -19,20 +19,53 @@ If Alice executes a function that generates a note for Bob: ## Constraining Message Delivery -The protocol will enable app developers to constrain the correctness of the following: +The protocol will enable account contract developers to constrain the correctness of the following: 1. The encryption of a user's note. 2. The generation of the tag for that note. 3. The publication of that note and tag to the correct data availability layer. -Each app will define whether to constrain each such step. Encryption and tagging will be done through a set of [precompiled contracts](../addresses-and-keys/precompiles.md), each contract offering a different mechanism, and users will advertise their preferred mechanisms in a canonical [registry](./registry.md). +Each account contract will define whether to constrain each such step. Encryption and tagging will be done through a set of [precompiled contracts](../addresses-and-keys/precompiles.md), each contract offering a different mechanism, and users will advertise their preferred mechanisms in a canonical [registry](./registry.md). The advantages of this approach are: - - 1. It enables a user to select their preferred [note discovery protocol](./note-discovery.md) and [encryption scheme](./encryption-and-decryption.md). 2. It ensures that notes are correctly encrypted with a user's public encryption key. 3. It ensures that notes are correctly tagged for a user's chosen [note discovery protocol](./note-discovery.md). 4. It provides scope for upgrading these functions or introducing new schemes as the field progresses. 5. It protects applications from malicious unprovable functions. + +## Note Discovery Protocol Selection + +In order for a user to consume notes that belong to them, they need to identify, retrieve and decrypt them. A simple, privacy-preserving approach to this would be to download all of the notes and attempt decryption. However, the total number of encrypted notes published by the network will be substantial, making it infeasible for some users to do this. Those users will want to utilize a note discovery protocol to privately identify their notes. + +Selection of the encryption and tagging mechanisms to use for a particular note are the responsibilty of a user's account contract rather than the application generating the note. This is to ensure the note is produced in a way compatible with the user's chosen note discovery scheme. Leaving this decision to applications could result in user's having to utilise multiple note discovery schemes, a situation we want to avoid. + +## User Handshaking + +Even if Alice correctly encrypts the note she creates for Bob and generates the correct tag to go with it, how does Bob know that Alice has sent him a note? Bob's note discovery protocol may require him to speculatively 'look' for notes with the tags that Alice (and his other counterparties) have generated. If Alice and Bob know each other then they can communicate out-of-protocol. But if they have no way of interacting then the network needs to provide a mechanism by which Bob can be alerted to the need to start searching for a specific sequence of tags. + +To facilitate this we will deploy a canonical 'handshake' contract that can be used to create a private note for a recipient containing the sender's information (e.g. public key). It should only be necessary for a single handshake to take place between two users. The notes generated by this contract will be easy to identify enabling users to retrieve these notes, decrypt them and use the contents in any deterministic tag generation used by their chosen note discovery protocol. + +## Encryption and Decryption + +Applications should be able to provably encrypt data for a target user, as part of private message delivery. As stated in the Keys section, we define three types of encrypted data, based on the sender and the recipient, from the perspective of a user: + +Incoming data: data created by someone else, encrypted for and sent to the user. +Outgoing data: data created by the user to be sent to someone else, encrypted for the user. +Internal incoming data: data created by the user, encrypted for and sent to the user. +Encryption mechanisms support these three types of encryption, which may rely on different keys advertised by the user. + +### Key Abstraction +To support different kinds of encryption mechanisms, the protocol does not make any assumptions on the type of public keys advertised by each user. Validation of their public keys is handled by the precompile contract selected by the user. + +### Provable Decryption +While provable encryption is required to guarantee correct private message delivery, provable decryption is required for disclosing activity within an application. This allows auditability and compliance use cases, as well as being able to prove that a user did not execute certain actions. To support this, encryption precompiles also allow for provable decryption. + +## Note Tagging + +Note discovery schemes typically require notes to be accompanied by a stream of bytes generated specifically for the note discovery protocol. This 'tag' is then used in the procss of note identification. Whilst the tag itself is nnot sufficient to enable efficient note retrieval, the addition of it alongside the note enables the note discovery protocol to privately select a subset of the global set of notes to be returned to the user. This subset may still require some degree of trial-decryption but this is much more feasible given the reduced dataset. + +When applications produce notes, they will need to call a protocol defined function within the account contract of the recipient and request that a tag be generated. From the protocol's perspective, this tag will simply be a stream of bytes relevant only to the recipient's note discovery protocol. It will be up to the account contract to constrain that the correct tag has been generated and from there the protocol circuits along with the rollup contract will ensure that the tag is correctly published along with the note. + +Constraining tag generation is not solely about ensuring that the generated tag is of the correct format. It is also necessary to constrain that tags are generated in the correct sequence. A tag sequence with duplicate or missing tags makes it much more difficult for the recipient to retrieve their notes. This will likely require tags to be nullified once used. \ No newline at end of file diff --git a/yellow-paper/docs/private-message-delivery/send-note-guidelines.md b/yellow-paper/docs/private-message-delivery/send-note-guidelines.md index b3394085a37..707118f943c 100644 --- a/yellow-paper/docs/private-message-delivery/send-note-guidelines.md +++ b/yellow-paper/docs/private-message-delivery/send-note-guidelines.md @@ -2,7 +2,7 @@ Application contracts are in control of creating, encrypting, tagging, and broadcasting private notes to users. As such, each application is free to follow whatever scheme it prefers, choosing to override user preferences or use custom encryption and note tagging mechanisms. However, this may hinder composability, or not be compatible with existing wallet software. -In order to satisfy the requirements established for private message delivery, we suggest the following guidelines when building applications, which leverage the canonical [registry](./registry.md) contract. +In order to satisfy the requirements established for private message delivery, we suggest the following guidelines when building applications, which leverage the canonical [registry](../pre-compiled-contracts/registry.md) contract. ## Provably Sending a Note @@ -16,7 +16,7 @@ Execution of the precompile that implements the recipient's choice for encryptio ## Pseudocode -The following pseudocode covers how to provably send a note to a recipient, given an `encryption_type` (incoming, outgoing, or internal incoming). Should the registry support [multiple entries for a given recipient](./registry.md#multiple-recipients-per-address), this method must execute a batched call per each entry recovered from the registry. +The following pseudocode covers how to provably send a note to a recipient, given an `encryption_type` (incoming, outgoing, or internal incoming). Should the registry support [multiple entries for a given recipient](../pre-compiled-contracts/registry.md#multiple-recipients-per-address), this method must execute a batched call per each entry recovered from the registry. ``` fn provably_send_note(recipient, note, encryption_type) @@ -56,7 +56,7 @@ Last, applications with strong compliance and auditability requirements may choo ## Delivering Messages to Multiple Recipients via Shared Secrets -As an alternative to registering [multiple recipients for a given address](./registry.md#multiple-recipients-per-address), multisig participants may deploy a contract using a shared secret derived among them. This makes it cheaper to broadcast messages to the group, since every note does not need to be individually encrypted for each of them. However, it forces all recipients in the group to use the same encryption and tagging method, and adds an extra address they need to monitor for note discovery. +As an alternative to registering [multiple recipients for a given address](../pre-compiled-contracts/registry.md#multiple-recipients-per-address), multisig participants may deploy a contract using a shared secret derived among them. This makes it cheaper to broadcast messages to the group, since every note does not need to be individually encrypted for each of them. However, it forces all recipients in the group to use the same encryption and tagging method, and adds an extra address they need to monitor for note discovery. ## Discussions From a4472e94a25fc5e8350cc46d797092ea94c685c2 Mon Sep 17 00:00:00 2001 From: PhilWindle Date: Thu, 15 Feb 2024 17:34:31 +0000 Subject: [PATCH 2/7] Fixes --- yellow-paper/docs/addresses-and-keys/address.md | 2 +- yellow-paper/docs/addresses-and-keys/precompiles.md | 2 +- .../private-message-delivery/private-msg-delivery.md | 8 ++++---- yellow-paper/sidebars.js | 11 ++++++++--- 4 files changed, 14 insertions(+), 9 deletions(-) diff --git a/yellow-paper/docs/addresses-and-keys/address.md b/yellow-paper/docs/addresses-and-keys/address.md index 1304efcf15b..221a7265085 100644 --- a/yellow-paper/docs/addresses-and-keys/address.md +++ b/yellow-paper/docs/addresses-and-keys/address.md @@ -44,6 +44,6 @@ public_keys_hash = pedersen([ ], GENERATOR__PUBLIC_KEYS) ``` -This recommended hash format is compatible with the [encryption precompiles](./precompiles.md#encryption-and-tagging-precompiles) initially defined in the protocol and advertised in the canonical [registry](../private-message-delivery/registry.md) for private message delivery. An address that chooses to use a different format for its keys will not be compatible with apps that rely on the registry for note encryption. Nevertheless, new precompiles introduced in future versions of the protocol could use different public keys formats. +This recommended hash format is compatible with the [encryption precompiles](./precompiles.md#encryption-and-tagging-precompiles) initially defined in the protocol and advertised in the canonical [registry](../pre-compiled-contracts/registry.md) for private message delivery. An address that chooses to use a different format for its keys will not be compatible with apps that rely on the registry for note encryption. Nevertheless, new precompiles introduced in future versions of the protocol could use different public keys formats. diff --git a/yellow-paper/docs/addresses-and-keys/precompiles.md b/yellow-paper/docs/addresses-and-keys/precompiles.md index 093ff92fc4d..9cdfda3a514 100644 --- a/yellow-paper/docs/addresses-and-keys/precompiles.md +++ b/yellow-paper/docs/addresses-and-keys/precompiles.md @@ -8,7 +8,7 @@ Precompiled contracts, which borrow their name from Ethereum's, are contracts no Note that, unlike user-defined contracts, the address of a precompiled [contract instance](../contract-deployment/instances.md) and the [identifier of its class](../contract-deployment/classes.md#class-identifier) both have no known preimage. -The rationale for precompiled contracts is to provide a set of vetted primitives for [note encryption](../private-message-delivery/encryption-and-decryption.md) and [tagging](../private-message-delivery/note-discovery.md) that applications can use safely. These primitives are guaranteed to be always-satisfiable when called with valid arguments. This allows account contracts to choose their preferred method of encryption and tagging from any primitive in this set, and application contracts to call into them without the risk of calling into a untrusted code, which could potentially halt the execution flow via an unsatisfiable constraint. Furthermore, by exposing these primitives in a reserved set of well-known addresses, applications can be forward-compatible and incorporate new encryption and tagging methods as accounts opt into them. +The rationale for precompiled contracts is to provide a set of vetted primitives for [note encryption](../private-message-delivery/private-msg-delivery.md#encryption-and-decryption) and [tagging](../private-message-delivery/private-msg-delivery.md#note-tagging) that applications can use safely. These primitives are guaranteed to be always-satisfiable when called with valid arguments. This allows account contracts to choose their preferred method of encryption and tagging from any primitive in this set, and application contracts to call into them without the risk of calling into a untrusted code, which could potentially halt the execution flow via an unsatisfiable constraint. Furthermore, by exposing these primitives in a reserved set of well-known addresses, applications can be forward-compatible and incorporate new encryption and tagging methods as accounts opt into them. ## Constants diff --git a/yellow-paper/docs/private-message-delivery/private-msg-delivery.md b/yellow-paper/docs/private-message-delivery/private-msg-delivery.md index a62e3df3e76..3af70dcce06 100644 --- a/yellow-paper/docs/private-message-delivery/private-msg-delivery.md +++ b/yellow-paper/docs/private-message-delivery/private-msg-delivery.md @@ -6,7 +6,7 @@ If Alice executes a function that generates a note for Bob: 1. Alice will need to **encrypt** that note such that Bob, and only Bob is able to decrypt it. 2. Alice will need to **broadcast** the encrypted note ciphertext so as to make it available for Bob to retrieve. -3. Alice will need to **broadcast a 'tag'** alongside the encrypted note ciphertext. This tag must be identifiable by Bob's chosen [note discovery protocol](./note-discovery.md) but not identifiable by any third party as "intended for Bob". +3. Alice will need to **broadcast a 'tag'** alongside the encrypted note ciphertext. This tag must be identifiable by Bob's chosen [note discovery protocol](./private-msg-delivery.md#note-discovery-protocol-selection) but not identifiable by any third party as "intended for Bob". ## Requirements @@ -25,13 +25,13 @@ The protocol will enable account contract developers to constrain the correctnes 2. The generation of the tag for that note. 3. The publication of that note and tag to the correct data availability layer. -Each account contract will define whether to constrain each such step. Encryption and tagging will be done through a set of [precompiled contracts](../addresses-and-keys/precompiles.md), each contract offering a different mechanism, and users will advertise their preferred mechanisms in a canonical [registry](./registry.md). +Each account contract will define whether to constrain each such step. Encryption and tagging will be done through a set of [precompiled contracts](../addresses-and-keys/precompiles.md), each contract offering a different mechanism, and users will advertise their preferred mechanisms in a canonical [registry](../pre-compiled-contracts/registry.md). The advantages of this approach are: -1. It enables a user to select their preferred [note discovery protocol](./note-discovery.md) and [encryption scheme](./encryption-and-decryption.md). +1. It enables a user to select their preferred [note discovery protocol](./private-msg-delivery.md#note-discovery-protocol-selection) and [encryption scheme](./private-msg-delivery.md#encryption-and-decryption). 2. It ensures that notes are correctly encrypted with a user's public encryption key. -3. It ensures that notes are correctly tagged for a user's chosen [note discovery protocol](./note-discovery.md). +3. It ensures that notes are correctly tagged for a user's chosen note discovery protocol. 4. It provides scope for upgrading these functions or introducing new schemes as the field progresses. 5. It protects applications from malicious unprovable functions. diff --git a/yellow-paper/sidebars.js b/yellow-paper/sidebars.js index 447505ec054..9b364eb332d 100644 --- a/yellow-paper/sidebars.js +++ b/yellow-paper/sidebars.js @@ -130,15 +130,20 @@ const sidebars = { link: { type: "doc", id: "logs/index" }, items: [], }, + { + label: "Pre-compiled Contracts", + type: "category", + link: { type: "doc", id: "pre-compiled-contracts/index" }, + items: [ + "pre-compiled-contracts/registry", + ], + }, { label: "Private Message Delivery", type: "category", link: { type: "doc", id: "private-message-delivery/index" }, items: [ "private-message-delivery/private-msg-delivery", // renamed to avoid routing problems - "private-message-delivery/note-discovery", - "private-message-delivery/encryption-and-decryption", - "private-message-delivery/registry", "private-message-delivery/send-note-guidelines", ], }, From 207c86c4577cf50bdff0912e4e7c6a079f65411c Mon Sep 17 00:00:00 2001 From: PhilWindle <60546371+PhilWindle@users.noreply.github.com> Date: Fri, 16 Feb 2024 09:43:46 +0000 Subject: [PATCH 3/7] Update yellow-paper/docs/private-message-delivery/private-msg-delivery.md Co-authored-by: Santiago Palladino --- .../docs/private-message-delivery/private-msg-delivery.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/yellow-paper/docs/private-message-delivery/private-msg-delivery.md b/yellow-paper/docs/private-message-delivery/private-msg-delivery.md index 3af70dcce06..9a318bcacfb 100644 --- a/yellow-paper/docs/private-message-delivery/private-msg-delivery.md +++ b/yellow-paper/docs/private-message-delivery/private-msg-delivery.md @@ -66,6 +66,6 @@ While provable encryption is required to guarantee correct private message deliv Note discovery schemes typically require notes to be accompanied by a stream of bytes generated specifically for the note discovery protocol. This 'tag' is then used in the procss of note identification. Whilst the tag itself is nnot sufficient to enable efficient note retrieval, the addition of it alongside the note enables the note discovery protocol to privately select a subset of the global set of notes to be returned to the user. This subset may still require some degree of trial-decryption but this is much more feasible given the reduced dataset. -When applications produce notes, they will need to call a protocol defined function within the account contract of the recipient and request that a tag be generated. From the protocol's perspective, this tag will simply be a stream of bytes relevant only to the recipient's note discovery protocol. It will be up to the account contract to constrain that the correct tag has been generated and from there the protocol circuits along with the rollup contract will ensure that the tag is correctly published along with the note. +When applications produce notes, they will need to call a protocol defined contract chosen by the recipient and request that a tag be generated. From the protocol's perspective, this tag will simply be a stream of bytes relevant only to the recipient's note discovery protocol. It will be up to the precompile to constrain that the correct tag has been generated and from there the protocol circuits along with the rollup contract will ensure that the tag is correctly published along with the note. Constraining tag generation is not solely about ensuring that the generated tag is of the correct format. It is also necessary to constrain that tags are generated in the correct sequence. A tag sequence with duplicate or missing tags makes it much more difficult for the recipient to retrieve their notes. This will likely require tags to be nullified once used. \ No newline at end of file From f3d4bb3f4d567f1a89a396528f96264f21da156f Mon Sep 17 00:00:00 2001 From: PhilWindle <60546371+PhilWindle@users.noreply.github.com> Date: Fri, 16 Feb 2024 09:50:10 +0000 Subject: [PATCH 4/7] Apply suggestions from code review Co-authored-by: Santiago Palladino --- .../docs/private-message-delivery/private-msg-delivery.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/yellow-paper/docs/private-message-delivery/private-msg-delivery.md b/yellow-paper/docs/private-message-delivery/private-msg-delivery.md index 9a318bcacfb..4ad7003b29a 100644 --- a/yellow-paper/docs/private-message-delivery/private-msg-delivery.md +++ b/yellow-paper/docs/private-message-delivery/private-msg-delivery.md @@ -39,7 +39,7 @@ The advantages of this approach are: In order for a user to consume notes that belong to them, they need to identify, retrieve and decrypt them. A simple, privacy-preserving approach to this would be to download all of the notes and attempt decryption. However, the total number of encrypted notes published by the network will be substantial, making it infeasible for some users to do this. Those users will want to utilize a note discovery protocol to privately identify their notes. -Selection of the encryption and tagging mechanisms to use for a particular note are the responsibilty of a user's account contract rather than the application generating the note. This is to ensure the note is produced in a way compatible with the user's chosen note discovery scheme. Leaving this decision to applications could result in user's having to utilise multiple note discovery schemes, a situation we want to avoid. +Selection of the encryption and tagging mechanisms to use for a particular note are the responsibilty of a user's wallet rather than the application generating the note. This is to ensure the note is produced in a way compatible with the user's chosen note discovery scheme. Leaving this decision to applications could result in user's having to utilise multiple note discovery schemes, a situation we want to avoid. ## User Handshaking @@ -64,7 +64,7 @@ While provable encryption is required to guarantee correct private message deliv ## Note Tagging -Note discovery schemes typically require notes to be accompanied by a stream of bytes generated specifically for the note discovery protocol. This 'tag' is then used in the procss of note identification. Whilst the tag itself is nnot sufficient to enable efficient note retrieval, the addition of it alongside the note enables the note discovery protocol to privately select a subset of the global set of notes to be returned to the user. This subset may still require some degree of trial-decryption but this is much more feasible given the reduced dataset. +Note discovery schemes typically require notes to be accompanied by a stream of bytes generated specifically for the note discovery protocol. This 'tag' is then used in the procss of note identification. Whilst the tag itself is not sufficient to enable efficient note retrieval, the addition of it alongside the note enables the note discovery protocol to privately select a subset of the global set of notes to be returned to the user. This subset may still require some degree of trial-decryption but this is much more feasible given the reduced dataset. When applications produce notes, they will need to call a protocol defined contract chosen by the recipient and request that a tag be generated. From the protocol's perspective, this tag will simply be a stream of bytes relevant only to the recipient's note discovery protocol. It will be up to the precompile to constrain that the correct tag has been generated and from there the protocol circuits along with the rollup contract will ensure that the tag is correctly published along with the note. From b2ebc4a5210183f19efae162c6dd9de60888a07e Mon Sep 17 00:00:00 2001 From: PhilWindle Date: Fri, 16 Feb 2024 09:50:32 +0000 Subject: [PATCH 5/7] Fixes --- .../docs/private-message-delivery/private-msg-delivery.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/yellow-paper/docs/private-message-delivery/private-msg-delivery.md b/yellow-paper/docs/private-message-delivery/private-msg-delivery.md index 3af70dcce06..147bb769f00 100644 --- a/yellow-paper/docs/private-message-delivery/private-msg-delivery.md +++ b/yellow-paper/docs/private-message-delivery/private-msg-delivery.md @@ -19,13 +19,13 @@ If Alice executes a function that generates a note for Bob: ## Constraining Message Delivery -The protocol will enable account contract developers to constrain the correctness of the following: +The protocol will enable app developers to constrain the correctness of the following: 1. The encryption of a user's note. 2. The generation of the tag for that note. 3. The publication of that note and tag to the correct data availability layer. -Each account contract will define whether to constrain each such step. Encryption and tagging will be done through a set of [precompiled contracts](../addresses-and-keys/precompiles.md), each contract offering a different mechanism, and users will advertise their preferred mechanisms in a canonical [registry](../pre-compiled-contracts/registry.md). +Each app will define whether to constrain each such step. Encryption and tagging will be done through a set of [precompiled contracts](../addresses-and-keys/precompiles.md), each contract offering a different mechanism, and users will advertise their preferred mechanisms in a canonical [registry](../pre-compiled-contracts/registry.md). The advantages of this approach are: From 79b2686adddd6ca33c5d06f73f9c0854b7e03b21 Mon Sep 17 00:00:00 2001 From: PhilWindle Date: Fri, 16 Feb 2024 16:58:52 +0000 Subject: [PATCH 6/7] WIP --- .../docs/private-message-delivery/private-msg-delivery.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/yellow-paper/docs/private-message-delivery/private-msg-delivery.md b/yellow-paper/docs/private-message-delivery/private-msg-delivery.md index 97b82856331..e1738d1261e 100644 --- a/yellow-paper/docs/private-message-delivery/private-msg-delivery.md +++ b/yellow-paper/docs/private-message-delivery/private-msg-delivery.md @@ -45,7 +45,7 @@ Selection of the encryption and tagging mechanisms to use for a particular note Even if Alice correctly encrypts the note she creates for Bob and generates the correct tag to go with it, how does Bob know that Alice has sent him a note? Bob's note discovery protocol may require him to speculatively 'look' for notes with the tags that Alice (and his other counterparties) have generated. If Alice and Bob know each other then they can communicate out-of-protocol. But if they have no way of interacting then the network needs to provide a mechanism by which Bob can be alerted to the need to start searching for a specific sequence of tags. -To facilitate this we will deploy a canonical 'handshake' contract that can be used to create a private note for a recipient containing the sender's information (e.g. public key). It should only be necessary for a single handshake to take place between two users. The notes generated by this contract will be easy to identify enabling users to retrieve these notes, decrypt them and use the contents in any deterministic tag generation used by their chosen note discovery protocol. +To facilitate this we will deploy a canonical 'handshake' contract that can be used to create a private note for a recipient containing the sender's information (e.g. public key). It should only be necessary for a single handshake to take place between two users. The notes generated by this contract will be easy to identify, enabling users to retrieve these notes, decrypt them and use the contents in any deterministic tag generation used by their chosen note discovery protocol. ## Encryption and Decryption From bf9d6571cf743b1432404399988cf27cfe982af0 Mon Sep 17 00:00:00 2001 From: PhilWindle Date: Sun, 18 Feb 2024 15:32:49 +0000 Subject: [PATCH 7/7] Fixed link --- yellow-paper/docs/decentralization/actors.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/yellow-paper/docs/decentralization/actors.md b/yellow-paper/docs/decentralization/actors.md index 6c2890a1b62..dc4eba58513 100644 --- a/yellow-paper/docs/decentralization/actors.md +++ b/yellow-paper/docs/decentralization/actors.md @@ -99,7 +99,7 @@ The index is built by the node as it receives new blocks from the network. If the node have the full index it can serve any user that wants to retrieve their notes. This will be elaborated further in [responding to queries](#responding-to-queries). A node could be configured to only build and serve the index for a subset of the tags and notes. -For example, a personal node could be configured to only build the index for the notes that belong to the owner based on their [tag derivation](./../private-message-delivery/note-discovery.md). +For example, a personal node could be configured to only build the index for the notes that belong to the owner based on their [tag derivation](./../private-message-delivery/private-msg-delivery.md#note-tagging). If the node is intended only for block production, it can skip the index entirely.