From d3a9513d5769ee7e0ec5072283ac1aca2cc857d6 Mon Sep 17 00:00:00 2001 From: gagdiez Date: Tue, 14 Feb 2023 17:48:20 +0100 Subject: [PATCH 1/9] first draft --- neps/nep-9999.md | 56 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 56 insertions(+) create mode 100644 neps/nep-9999.md diff --git a/neps/nep-9999.md b/neps/nep-9999.md new file mode 100644 index 000000000..954cb8d4e --- /dev/null +++ b/neps/nep-9999.md @@ -0,0 +1,56 @@ +--- +NEP: xxxx +Title: Prefix Tag for Messages and Transactions +Author: Gallardo Guillermo , Firat Sertgoz +DiscussionsTo: https://github.com/nearprotocol/neps/pull/XXX +Status: Draft +Type: Standards Track +Category: Tools +Version: 1.0.0 +Created: 14-Feb-2023 +Updated: 14-Feb-2023 +--- + +## Summary +A proposal to include a standardized prefix in all signed messages that are not transactions. + +Particularly, we propose to prepend the <$2^{31}$ + NEP-number> prefix to all non-transactional messages. + +## Motivation +As the ecosystem grows, more wallet 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 non-transactional 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 message cannot be interpreted as a valid transaction. + +Including a `u32` fixed prefix with value <$2^{31}$+NEP-number> will enable to easily distinguish non-transactional messages from transactions, while also ensuring that they never overlap. This is because the first parameter of a [valid transactions](https://nomicon.io/RuntimeSpec/Transactions) is an `AccountId`, which is encoded as `string length ` + `string chars `. Adding a prefix in the range of $2^31 - 2^32$ will automatically make the non-transactional message to deserialize into an invalid transaction, since no `AccountId` has more than 64 chars. + +## Specification + +All non-transactional messages should have a structure which first parameter is a `prefix: u32`. + +For example, if we want to simply make the user sign a message, and the proposal has the number `NEP400`, then the structure of the message to be sign must be: + +```ts +MessageToSign{ + prefix: u32 // fixed to 2**31 + 400 == 2147484048 + message: string; +} +``` + +## Security Implications + +All non-transactional messages will be ensured to not be parsable into valid 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. + + +## Future possibilities + +A future possibility is to update the transactions structure, such that they also include a prefix, in this case lower than $2^31$. \ No newline at end of file From 06793923acda2508b3e71c7fbfb50948017d6651 Mon Sep 17 00:00:00 2001 From: gagdiez Date: Tue, 14 Feb 2023 17:51:57 +0100 Subject: [PATCH 2/9] Added NEP number --- neps/nep-9999.md | 56 ------------------------------------------------ 1 file changed, 56 deletions(-) delete mode 100644 neps/nep-9999.md diff --git a/neps/nep-9999.md b/neps/nep-9999.md deleted file mode 100644 index 954cb8d4e..000000000 --- a/neps/nep-9999.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -NEP: xxxx -Title: Prefix Tag for Messages and Transactions -Author: Gallardo Guillermo , Firat Sertgoz -DiscussionsTo: https://github.com/nearprotocol/neps/pull/XXX -Status: Draft -Type: Standards Track -Category: Tools -Version: 1.0.0 -Created: 14-Feb-2023 -Updated: 14-Feb-2023 ---- - -## Summary -A proposal to include a standardized prefix in all signed messages that are not transactions. - -Particularly, we propose to prepend the <$2^{31}$ + NEP-number> prefix to all non-transactional messages. - -## Motivation -As the ecosystem grows, more wallet 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 non-transactional 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 message cannot be interpreted as a valid transaction. - -Including a `u32` fixed prefix with value <$2^{31}$+NEP-number> will enable to easily distinguish non-transactional messages from transactions, while also ensuring that they never overlap. This is because the first parameter of a [valid transactions](https://nomicon.io/RuntimeSpec/Transactions) is an `AccountId`, which is encoded as `string length ` + `string chars `. Adding a prefix in the range of $2^31 - 2^32$ will automatically make the non-transactional message to deserialize into an invalid transaction, since no `AccountId` has more than 64 chars. - -## Specification - -All non-transactional messages should have a structure which first parameter is a `prefix: u32`. - -For example, if we want to simply make the user sign a message, and the proposal has the number `NEP400`, then the structure of the message to be sign must be: - -```ts -MessageToSign{ - prefix: u32 // fixed to 2**31 + 400 == 2147484048 - message: string; -} -``` - -## Security Implications - -All non-transactional messages will be ensured to not be parsable into valid 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. - - -## Future possibilities - -A future possibility is to update the transactions structure, such that they also include a prefix, in this case lower than $2^31$. \ No newline at end of file From e3e81ccf015d5b0ba856cf8ca0db612b2807ae18 Mon Sep 17 00:00:00 2001 From: gagdiez Date: Tue, 14 Feb 2023 17:52:08 +0100 Subject: [PATCH 3/9] Added NEP number --- neps/nep-0461.md | 56 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 56 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..b2e136d03 --- /dev/null +++ b/neps/nep-0461.md @@ -0,0 +1,56 @@ +--- +NEP: 0461 +Title: Prefix Tag for Non-Transactional Messages +Author: Gallardo Guillermo , Firat Sertgoz +DiscussionsTo: https://github.com/nearprotocol/neps/pull/XXX +Status: Draft +Type: Standards Track +Category: Tools +Version: 1.0.0 +Created: 14-Feb-2023 +Updated: 14-Feb-2023 +--- + +## Summary +A proposal to include a standardized prefix in all signed messages that are not transactions. + +Particularly, we propose to prepend the <$2^{31}$ + NEP-number> prefix to all non-transactional messages. + +## Motivation +As the ecosystem grows, more wallet 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 non-transactional 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 message cannot be interpreted as a valid transaction. + +Including a `u32` fixed prefix with value <$2^{31}$+NEP-number> will enable to easily distinguish non-transactional messages from transactions, while also ensuring that they never overlap. This is because the first parameter of a [valid transactions](https://nomicon.io/RuntimeSpec/Transactions) is an `AccountId`, which is encoded as `string length ` + `string chars `. Adding a prefix in the range of $2^31 - 2^32$ will automatically make the non-transactional message to deserialize into an invalid transaction, since no `AccountId` has more than 64 chars. + +## Specification + +All non-transactional messages should have a structure which first parameter is a `prefix: u32`. + +For example, if we want to simply make the user sign a message, and the proposal has the number `NEP400`, then the structure of the message to be sign must be: + +```ts +MessageToSign{ + prefix: u32 // fixed to 2**31 + 400 == 2147484048 + message: string; +} +``` + +## Security Implications + +All non-transactional messages will be ensured to not be parsable into valid 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. + + +## Future possibilities + +A future possibility is to update the transactions structure, such that they also include a prefix, in this case lower than $2^31$. \ No newline at end of file From afa0111b9b638ed431add13247f6121a14863a4d Mon Sep 17 00:00:00 2001 From: gagdiez Date: Tue, 14 Feb 2023 17:52:29 +0100 Subject: [PATCH 4/9] Added URL --- neps/nep-0461.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/neps/nep-0461.md b/neps/nep-0461.md index b2e136d03..0671ee0cb 100644 --- a/neps/nep-0461.md +++ b/neps/nep-0461.md @@ -2,7 +2,7 @@ NEP: 0461 Title: Prefix Tag for Non-Transactional Messages Author: Gallardo Guillermo , Firat Sertgoz -DiscussionsTo: https://github.com/nearprotocol/neps/pull/XXX +DiscussionsTo: https://github.com/nearprotocol/neps/pull/461 Status: Draft Type: Standards Track Category: Tools From 60f0efff237aff6f155eea8c6060935f7baa59ff Mon Sep 17 00:00:00 2001 From: gagdiez Date: Wed, 15 Feb 2023 20:23:46 +0100 Subject: [PATCH 5/9] Added prefix for actionable messages --- neps/nep-0461.md | 56 +++++++++++++++++++++++++++++++----------------- 1 file changed, 36 insertions(+), 20 deletions(-) diff --git a/neps/nep-0461.md b/neps/nep-0461.md index 0671ee0cb..a75058b66 100644 --- a/neps/nep-0461.md +++ b/neps/nep-0461.md @@ -1,56 +1,72 @@ --- NEP: 0461 -Title: Prefix Tag for Non-Transactional Messages +Title: Prefix Tag for Signed Messages Author: Gallardo Guillermo , Firat Sertgoz DiscussionsTo: https://github.com/nearprotocol/neps/pull/461 Status: Draft -Type: Standards Track -Category: Tools +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 signed messages that are not transactions. +A proposal to include a standardized prefix in all standardized signable messages, to distinguish actionable messages (i.e. those that are validated on chain), from non-actionable messages (i.e. those that are used off-chain), from [classic transactions](https://nomicon.io/RuntimeSpec/Transactions). -Particularly, we propose to prepend the <$2^{31}$ + NEP-number> prefix to all non-transactional messages. +Particularly, we propose to prepend the following prefixes: + +| 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 wallet 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. +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 non-transactional 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 message cannot be interpreted as a valid transaction. +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 message cannot be interpreted as a valid transaction. -Including a `u32` fixed prefix with value <$2^{31}$+NEP-number> will enable to easily distinguish non-transactional messages from transactions, while also ensuring that they never overlap. This is because the first parameter of a [valid transactions](https://nomicon.io/RuntimeSpec/Transactions) is an `AccountId`, which is encoded as `string length ` + `string chars `. Adding a prefix in the range of $2^31 - 2^32$ will automatically make the non-transactional message to deserialize into an invalid transaction, since no `AccountId` has more than 64 chars. +Including a `u32` fixed prefix will enable to easily distinguish transactions from messages, while also ensuring that they never overlap. This is because the first parameter of a [valid transactions](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 non-transactional message to deserialize into an invalid transaction, since no `AccountId` has more than 64 chars. ## Specification -All non-transactional messages should have a structure which first parameter is a `prefix: u32`. +### On-Chain Messages +All actionable messages, i.e. those that **ARE going** to be validated on-chain, should have a structure which first parameter is a `prefix: u32` with value $2^{30} + NEP-number$. -For example, if we want to simply make the user sign a message, and the proposal has the number `NEP400`, then the structure of the message to be sign must be: +For example, if we implement a new actionable message, destinated to be used on-chain, and the proposal has the number `NEP400`, then the structure must start with the prefix `1073742224`: ```ts -MessageToSign{ - prefix: u32 // fixed to 2**31 + 400 == 2147484048 - message: string; +Structure{ + prefix: u32 = 1073742224 // prefix fixed to 2**30 + 400 == 1073742224 + // Rest of the attributes go here } ``` -## Security Implications +### Off-Chain Messages +All non-actionable messages, i.e. those that are **NOT going** to be validated on-chain, should have a structure which first parameter is a `prefix: u32` with value $2^{31} + NEP-number$. -All non-transactional messages will be ensured to not be parsable into valid transactions. +For example, if we implement a new non-actionable message, destinated to be used off-chain, and the proposal has the number `NEP400`, then the structure must start with the prefix `2147484048`: -## Drawbacks +```ts +Structure{ + prefix: u32 = 2147484048 // prefix fixed to 2**31 + 400 == 2147484048 + // Rest of the attributes go here +} +``` -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. +## Security Implications -If at any point there is an update on how transactions are encoded, this NEP could stop being valid. +By implementing this NEP, we can be sure that all new messages do not collide with classic transactions. +## Drawbacks -## Future possibilities +A protocol change would be needed to ensure that `actionable messages` are treated as such, and not be confused with classic transactions. + +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. -A future possibility is to update the transactions structure, such that they also include a prefix, in this case lower than $2^31$. \ 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 59a7a0b042f0eb072af75d91710a475169949670 Mon Sep 17 00:00:00 2001 From: gagdiez Date: Thu, 16 Feb 2023 11:13:52 +0100 Subject: [PATCH 6/9] Added Evgeny + minor changes --- neps/nep-0461.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/neps/nep-0461.md b/neps/nep-0461.md index a75058b66..b67f7521e 100644 --- a/neps/nep-0461.md +++ b/neps/nep-0461.md @@ -1,7 +1,7 @@ --- NEP: 0461 Title: Prefix Tag for Signed Messages -Author: Gallardo Guillermo , Firat Sertgoz +Author: Evgeny Kapun , Gallardo Guillermo , Firat Sertgoz DiscussionsTo: https://github.com/nearprotocol/neps/pull/461 Status: Draft Type: Protocol @@ -36,7 +36,7 @@ Including a `u32` fixed prefix will enable to easily distinguish transactions fr ## Specification ### On-Chain Messages -All actionable messages, i.e. those that **ARE going** to be validated on-chain, should have a structure which first parameter is a `prefix: u32` with value $2^{30} + NEP-number$. +All actionable messages, i.e. those that ARE validated on-chain, should have a structure which first parameter is a `prefix: u32` with fixed value $2^{30} + NEP-number$. For example, if we implement a new actionable message, destinated to be used on-chain, and the proposal has the number `NEP400`, then the structure must start with the prefix `1073742224`: @@ -48,7 +48,7 @@ Structure{ ``` ### Off-Chain Messages -All non-actionable messages, i.e. those that are **NOT going** to be validated on-chain, should have a structure which first parameter is a `prefix: u32` with value $2^{31} + NEP-number$. +All non-actionable messages, i.e. those that are NOT validated on-chain, should have a structure which first parameter is a `prefix: u32` with fixed value $2^{31} + NEP-number$. For example, if we implement a new non-actionable message, destinated to be used off-chain, and the proposal has the number `NEP400`, then the structure must start with the prefix `2147484048`: From d42e4bab63472366d1c097592f251aec12589e0f Mon Sep 17 00:00:00 2001 From: gagdiez Date: Thu, 16 Feb 2023 16:31:33 +0100 Subject: [PATCH 7/9] Update nep-0461.md --- neps/nep-0461.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/neps/nep-0461.md b/neps/nep-0461.md index b67f7521e..bd1876ead 100644 --- a/neps/nep-0461.md +++ b/neps/nep-0461.md @@ -3,7 +3,7 @@ NEP: 0461 Title: Prefix Tag for Signed Messages Author: Evgeny Kapun , Gallardo Guillermo , Firat Sertgoz DiscussionsTo: https://github.com/nearprotocol/neps/pull/461 -Status: Draft +Status: Review Type: Protocol Category: Runtime Version: 1.0.0 From e145ee97d6ceb8ec7d9f06018b420d673195658d Mon Sep 17 00:00:00 2001 From: gagdiez Date: Fri, 17 Feb 2023 11:53:31 +0100 Subject: [PATCH 8/9] Changed prefix to implicit --- neps/nep-0461.md | 45 ++++++++++++++++++++++++++------------------- 1 file changed, 26 insertions(+), 19 deletions(-) diff --git a/neps/nep-0461.md b/neps/nep-0461.md index bd1876ead..2f2ed3460 100644 --- a/neps/nep-0461.md +++ b/neps/nep-0461.md @@ -12,11 +12,11 @@ Updated: 14-Feb-2023 --- ## Summary -A proposal to include a standardized prefix in all standardized signable messages, to distinguish actionable messages (i.e. those that are validated on chain), from non-actionable messages (i.e. those that are used off-chain), from [classic transactions](https://nomicon.io/RuntimeSpec/Transactions). +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 the following prefixes: +Particularly, we propose to prepend an implicit prefix to the structure being signed using the following rules: -| Prefix | Message | +| 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) | @@ -29,34 +29,43 @@ As the ecosystem grows, more standards will appear, enabling users to sign messa 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 message cannot be interpreted as a valid transaction. +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 parameter of a [valid transactions](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. -Including a `u32` fixed prefix will enable to easily distinguish transactions from messages, while also ensuring that they never overlap. This is because the first parameter of a [valid transactions](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 non-transactional message to 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 have a structure which first parameter is a `prefix: u32` with fixed value $2^{30} + NEP-number$. +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, destinated to be used on-chain, and the proposal has the number `NEP400`, then the structure must start with the prefix `1073742224`: +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 -Structure{ - prefix: u32 = 1073742224 // prefix fixed to 2**30 + 400 == 1073742224 - // Rest of the attributes go here -} +// 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 have a structure which first parameter is a `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 implicit `prefix: u32` with fixed value $2^{31}$ + NEP-number. -For example, if we implement a new non-actionable message, destinated to be used off-chain, and the proposal has the number `NEP400`, then the structure must start with the prefix `2147484048`: +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 -Structure{ - prefix: u32 = 2147484048 // prefix fixed to 2**31 + 400 == 2147484048 - // Rest of the attributes go here -} +// 2**31 + 400 = 2147484048 +sha256.hash(Borsh.serialize(2147484048) + Borsh.serialize(NonActionableMessage)) ``` ## Security Implications @@ -65,8 +74,6 @@ By implementing this NEP, we can be sure that all new messages do not collide wi ## Drawbacks -A protocol change would be needed to ensure that `actionable messages` are treated as such, and not be confused with classic transactions. - 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 ae4c83403afa5a90c67ca04acbefe2fa4f0bbc72 Mon Sep 17 00:00:00 2001 From: gagdiez Date: Wed, 1 Mar 2023 16:31:43 +0100 Subject: [PATCH 9/9] Apply suggestions from code review Co-authored-by: Evgeny Kapun --- neps/nep-0461.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/neps/nep-0461.md b/neps/nep-0461.md index 2f2ed3460..1d6034ea7 100644 --- a/neps/nep-0461.md +++ b/neps/nep-0461.md @@ -43,7 +43,7 @@ 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 parameter of a [valid transactions](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 `. 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