From 49a4d42fb23eca0c125f1d58151be2acfe585de8 Mon Sep 17 00:00:00 2001 From: gagdiez Date: Wed, 24 May 2023 11:12:09 +0200 Subject: [PATCH 1/7] trying to reopen PR --- neps/nep-0461.md | 79 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 79 insertions(+) create mode 100644 neps/nep-0461.md diff --git a/neps/nep-0461.md b/neps/nep-0461.md new file mode 100644 index 000000000..1d6034ea7 --- /dev/null +++ b/neps/nep-0461.md @@ -0,0 +1,79 @@ +--- +NEP: 0461 +Title: Prefix Tag for Signed Messages +Author: Evgeny Kapun , Gallardo Guillermo , Firat Sertgoz +DiscussionsTo: https://github.com/nearprotocol/neps/pull/461 +Status: Review +Type: Protocol +Category: Runtime +Version: 1.0.0 +Created: 14-Feb-2023 +Updated: 14-Feb-2023 +--- + +## Summary +A proposal to include a standardized prefix in all standardized signable messages, to distinguish between (1) actionable messages (i.e. those that are validated on chain), (2) non-actionable messages (i.e. those that are used off-chain), and (3) [classic transactions](https://nomicon.io/RuntimeSpec/Transactions). + +Particularly, we propose to prepend an implicit prefix to the structure being signed using the following rules: + +| Implicit Prefix | Message | +| - | - | +| $< 2^{30}$ | [Classic Transactions](https://nomicon.io/RuntimeSpec/Transactions) | +| $2^{30}$ + NEP-number | On-chain Actionable Message, e.g. [`SignedDelegateAction`](https://github.com/near/NEPs/blob/master/neps/nep-0366.md) | +| $2^{31}$ + NEP-number | Off-chain Message, e.g. [`signMessage`](https://github.com/near/NEPs/pull/413) | + +## Motivation +As the ecosystem grows, more standards will appear, enabling users to sign messages that are not transactions (e.g. [NEP413](https://github.com/near/NEPs/pull/413/), and [NEP366](https://github.com/near/NEPs/blob/master/neps/nep-0366.md)). If such messages collide with transactions, a malicious app could ask users to sign them, only to later relay them as valid transactions to the network. + +## Rationale and alternatives + +In NEAR, users sign transactions that are later relayed to the network. At the moment of being relayed, the transactions are simple streams of bytes that a node then parses into a [valid transaction](https://nomicon.io/RuntimeSpec/Transactions). + +As the protocol expands, more messages will be added for users to sign. We want users to be able to use the protocol safely, making sure that all those signed messages cannot be interpreted as a valid transaction. + +In practice, what users sign is the `sha256` hash of a [borsh-serialized](https://borsh.io) structure. This is: + +```ts +sha256.hash(Borsh.serialize(MessageStructure)) +``` + +Including a large `u32` prefix allows to easily distinguish transactions from messages, ensuring that they never overlap. + +```ts +sha256.hash(Borsh.serialize(large-number) + Borsh.serialize(MessageStructure)) +``` + +This is because the first field of a [valid transaction](https://nomicon.io/RuntimeSpec/Transactions) is an `AccountId`, which is encoded as `string length ` + `string chars `. Adding a prefix in the range of $(2^{30}, 2^{32})$ will automatically make the message deserialize into an invalid transaction, since no `AccountId` has more than 64 chars. + + +## Specification + +### On-Chain Messages +All actionable messages, i.e. those that ARE validated on-chain, should prepend an implicit `prefix: u32` with fixed value $2^{30}$ + NEP-number. + +For example, if we implement a new actionable message `ActionableMessage` destined to be used on-chain, and the proposal has the number `NEP400`, then the message must have the following form: + +```ts +// 2**30 + 400 = 1073742224 +sha256.hash(Borsh.serialize(1073742224) + Borsh.serialize(ActionableMessage)) +``` + +### Off-Chain Messages +All non-actionable messages, i.e. those that are NOT validated on-chain, should prepend an implicit `prefix: u32` with fixed value $2^{31}$ + NEP-number. + +For example, if we implement a new non-actionable message `NonActionableMessage`, destined to be used off-chain, and the proposal has the number `NEP400`, then the message to be signed is: + +```ts +// 2**31 + 400 = 2147484048 +sha256.hash(Borsh.serialize(2147484048) + Borsh.serialize(NonActionableMessage)) +``` + +## Security Implications + +By implementing this NEP, we can be sure that all new messages do not collide with classic transactions. + +## Drawbacks + +We will need to update [NEP366](https://github.com/near/NEPs/blob/master/neps/nep-0366.md) to follow this standard, and make sure all future NEPs follow it, which might be hard to track. + +If at any point there is an update on how transactions are encoded, this NEP could stop being valid. From 6c7563aa53b6a582e4530c99d529caa62ea69546 Mon Sep 17 00:00:00 2001 From: gagdiez Date: Wed, 24 May 2023 11:17:45 +0200 Subject: [PATCH 2/7] renamed proposal accordingly --- neps/{nep-0461.md => nep-483.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename neps/{nep-0461.md => nep-483.md} (100%) diff --git a/neps/nep-0461.md b/neps/nep-483.md similarity index 100% rename from neps/nep-0461.md rename to neps/nep-483.md From 070ff84671324e02b6e126e07c92e1f2f0b660bf Mon Sep 17 00:00:00 2001 From: gagdiez Date: Wed, 24 May 2023 11:26:35 +0200 Subject: [PATCH 3/7] implemented suggestions --- neps/{nep-483.md => nep-0483.md} | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) rename neps/{nep-483.md => nep-0483.md} (89%) diff --git a/neps/nep-483.md b/neps/nep-0483.md similarity index 89% rename from neps/nep-483.md rename to neps/nep-0483.md index 1d6034ea7..bd21ae3f8 100644 --- a/neps/nep-483.md +++ b/neps/nep-0483.md @@ -14,9 +14,9 @@ Updated: 14-Feb-2023 ## Summary A proposal to include a standardized prefix in all standardized signable messages, to distinguish between (1) actionable messages (i.e. those that are validated on chain), (2) non-actionable messages (i.e. those that are used off-chain), and (3) [classic transactions](https://nomicon.io/RuntimeSpec/Transactions). -Particularly, we propose to prepend an implicit prefix to the structure being signed using the following rules: +Particularly, we propose to prepend an explicit prefix to the structure being signed using the following rules: -| Implicit Prefix | Message | +| Prefix | Message | | - | - | | $< 2^{30}$ | [Classic Transactions](https://nomicon.io/RuntimeSpec/Transactions) | | $2^{30}$ + NEP-number | On-chain Actionable Message, e.g. [`SignedDelegateAction`](https://github.com/near/NEPs/blob/master/neps/nep-0366.md) | @@ -43,13 +43,13 @@ Including a large `u32` prefix allows to easily distinguish transactions from me sha256.hash(Borsh.serialize(large-number) + Borsh.serialize(MessageStructure)) ``` -This is because the first field of a [valid transaction](https://nomicon.io/RuntimeSpec/Transactions) is an `AccountId`, which is encoded as `string length ` + `string chars `. Adding a prefix in the range of $(2^{30}, 2^{32})$ will automatically make the message deserialize into an invalid transaction, since no `AccountId` has more than 64 chars. +This is because the first field of a [valid transaction](https://nomicon.io/RuntimeSpec/Transactions) is an `AccountId`, which is encoded as `string length ` + `string chars `. Prepending a prefix in the range of $(2^{30}, 2^{32})$ will automatically make the message deserialize into an invalid transaction, since no `AccountId` has more than 64 chars. ## Specification ### On-Chain Messages -All actionable messages, i.e. those that ARE validated on-chain, should prepend an implicit `prefix: u32` with fixed value $2^{30}$ + NEP-number. +All actionable messages, i.e. those that ARE validated on-chain, should prepend an explicit `prefix: u32` with fixed value $2^{30}$ + NEP-number. For example, if we implement a new actionable message `ActionableMessage` destined to be used on-chain, and the proposal has the number `NEP400`, then the message must have the following form: @@ -59,7 +59,7 @@ sha256.hash(Borsh.serialize(1073742224) + Borsh.serialize(ActionableMessage ``` ### Off-Chain Messages -All non-actionable messages, i.e. those that are NOT validated on-chain, should prepend an implicit `prefix: u32` with fixed value $2^{31}$ + NEP-number. +All non-actionable messages, i.e. those that are NOT validated on-chain, should prepend an explicit `prefix: u32` with fixed value $2^{31}$ + NEP-number. For example, if we implement a new non-actionable message `NonActionableMessage`, destined to be used off-chain, and the proposal has the number `NEP400`, then the message to be signed is: From babb153d00021ecb0f4d545a4767d64739712bc2 Mon Sep 17 00:00:00 2001 From: gagdiez Date: Wed, 24 May 2023 11:32:54 +0200 Subject: [PATCH 4/7] lint fixes --- neps/nep-0483.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/neps/nep-0483.md b/neps/nep-0483.md index bd21ae3f8..16590f473 100644 --- a/neps/nep-0483.md +++ b/neps/nep-0483.md @@ -12,6 +12,7 @@ Updated: 14-Feb-2023 --- ## Summary + A proposal to include a standardized prefix in all standardized signable messages, to distinguish between (1) actionable messages (i.e. those that are validated on chain), (2) non-actionable messages (i.e. those that are used off-chain), and (3) [classic transactions](https://nomicon.io/RuntimeSpec/Transactions). Particularly, we propose to prepend an explicit prefix to the structure being signed using the following rules: @@ -23,6 +24,7 @@ Particularly, we propose to prepend an explicit prefix to the structure being si | $2^{31}$ + NEP-number | Off-chain Message, e.g. [`signMessage`](https://github.com/near/NEPs/pull/413) | ## Motivation + As the ecosystem grows, more standards will appear, enabling users to sign messages that are not transactions (e.g. [NEP413](https://github.com/near/NEPs/pull/413/), and [NEP366](https://github.com/near/NEPs/blob/master/neps/nep-0366.md)). If such messages collide with transactions, a malicious app could ask users to sign them, only to later relay them as valid transactions to the network. ## Rationale and alternatives @@ -49,6 +51,7 @@ This is because the first field of a [valid transaction](https://nomicon.io/Runt ## Specification ### On-Chain Messages + All actionable messages, i.e. those that ARE validated on-chain, should prepend an explicit `prefix: u32` with fixed value $2^{30}$ + NEP-number. For example, if we implement a new actionable message `ActionableMessage` destined to be used on-chain, and the proposal has the number `NEP400`, then the message must have the following form: @@ -59,6 +62,7 @@ sha256.hash(Borsh.serialize(1073742224) + Borsh.serialize(ActionableMessage ``` ### Off-Chain Messages + All non-actionable messages, i.e. those that are NOT validated on-chain, should prepend an explicit `prefix: u32` with fixed value $2^{31}$ + NEP-number. For example, if we implement a new non-actionable message `NonActionableMessage`, destined to be used off-chain, and the proposal has the number `NEP400`, then the message to be signed is: @@ -76,4 +80,4 @@ By implementing this NEP, we can be sure that all new messages do not collide wi We will need to update [NEP366](https://github.com/near/NEPs/blob/master/neps/nep-0366.md) to follow this standard, and make sure all future NEPs follow it, which might be hard to track. -If at any point there is an update on how transactions are encoded, this NEP could stop being valid. +If at any point there is an update on how transactions are encoded, this NEP could stop being valid. \ No newline at end of file From b4e053c7850946f32c9154247b3e29d6d5948675 Mon Sep 17 00:00:00 2001 From: gagdiez Date: Wed, 24 May 2023 11:33:43 +0200 Subject: [PATCH 5/7] lint fixes --- neps/nep-0483.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/neps/nep-0483.md b/neps/nep-0483.md index 16590f473..5e5dce331 100644 --- a/neps/nep-0483.md +++ b/neps/nep-0483.md @@ -80,4 +80,4 @@ By implementing this NEP, we can be sure that all new messages do not collide wi We will need to update [NEP366](https://github.com/near/NEPs/blob/master/neps/nep-0366.md) to follow this standard, and make sure all future NEPs follow it, which might be hard to track. -If at any point there is an update on how transactions are encoded, this NEP could stop being valid. \ No newline at end of file +If at any point there is an update on how transactions are encoded, this NEP could stop being valid. From 428c778cf3e36d012a1a918657b2e436d1003813 Mon Sep 17 00:00:00 2001 From: Guille Date: Tue, 1 Oct 2024 09:57:37 +0200 Subject: [PATCH 6/7] Update nep-0483.md --- neps/nep-0483.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/neps/nep-0483.md b/neps/nep-0483.md index 5e5dce331..ba5891d38 100644 --- a/neps/nep-0483.md +++ b/neps/nep-0483.md @@ -23,6 +23,16 @@ Particularly, we propose to prepend an explicit prefix to the structure being si | $2^{30}$ + NEP-number | On-chain Actionable Message, e.g. [`SignedDelegateAction`](https://github.com/near/NEPs/blob/master/neps/nep-0366.md) | | $2^{31}$ + NEP-number | Off-chain Message, e.g. [`signMessage`](https://github.com/near/NEPs/pull/413) | + +#### Limits on prefix space +To not use the entire $2^{30}$ and $2^{31}$ prefix space, we propose to limit the ranges used to NEPs as follows: +- $[0, 2^{30})$: Regular transactions +- $[2^{30}, 2^{30} + 2^{22})$: $2^{18}$ blocks of $2^{4}$ numbers, allowing for up to 262144 NEPs of up to 4 message types +- $[2^{30} + 2^{22}, 2^{31})$: Space reserved for future use +- $[2^{31}, 2^{31} + 2^{20})$: Space reserved for manual allocation of message types for NEPs that’d need more than 4, NEP-413 would fall here +- $[2^{31} + 2^{20}, 2^{32})$: Space reserved for future use + + ## Motivation As the ecosystem grows, more standards will appear, enabling users to sign messages that are not transactions (e.g. [NEP413](https://github.com/near/NEPs/pull/413/), and [NEP366](https://github.com/near/NEPs/blob/master/neps/nep-0366.md)). If such messages collide with transactions, a malicious app could ask users to sign them, only to later relay them as valid transactions to the network. From 4c8062f61369e3fe57966c0d177476dca34bc593 Mon Sep 17 00:00:00 2001 From: Guille Date: Tue, 1 Oct 2024 09:58:57 +0200 Subject: [PATCH 7/7] Update neps/nep-0483.md --- neps/nep-0483.md | 1 + 1 file changed, 1 insertion(+) diff --git a/neps/nep-0483.md b/neps/nep-0483.md index ba5891d38..bb3d95e54 100644 --- a/neps/nep-0483.md +++ b/neps/nep-0483.md @@ -25,6 +25,7 @@ Particularly, we propose to prepend an explicit prefix to the structure being si #### Limits on prefix space + To not use the entire $2^{30}$ and $2^{31}$ prefix space, we propose to limit the ranges used to NEPs as follows: - $[0, 2^{30})$: Regular transactions - $[2^{30}, 2^{30} + 2^{22})$: $2^{18}$ blocks of $2^{4}$ numbers, allowing for up to 262144 NEPs of up to 4 message types