From 5294e2bc8e6bec99cae69ad7cb832102fc0c0525 Mon Sep 17 00:00:00 2001 From: danieljperry Date: Fri, 25 Oct 2024 15:01:16 +0800 Subject: [PATCH 1/7] Add new keccak256 CHIP --- CHIPs/chip-keccak256.md | 104 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 104 insertions(+) create mode 100644 CHIPs/chip-keccak256.md diff --git a/CHIPs/chip-keccak256.md b/CHIPs/chip-keccak256.md new file mode 100644 index 00000000..d8043b7c --- /dev/null +++ b/CHIPs/chip-keccak256.md @@ -0,0 +1,104 @@ +CHIP Number | < Creator must leave this blank. Editor will assign a number.> +:-------------|:---- +Title | keccak256 CLVM operator +Description | Add a CLVM operator to support Ethereum addresses +Author | [Arvid Norberg](https://github.com/arvidn) +Editor | < Creator must leave this blank. Editor will be assigned.> +Comments-URI | < Creator must leave this blank. Editor will assign a URI.> +Status | < Creator must leave this blank. Editor will assign a status.> +Category | Standards Track +Sub-Category | Chialisp +Created | 2024-10-25 +Requires | None +Replaces | None +Superseded-By | None + +## Abstract +This CHIP will add a new `keccak256` operator to the CLVM in order to enable the support of Ethereum addresses. This operator could be added in one of two ways, depending on timing: +1. It could be made accessible from behind the `softfork` guard, which would require a soft fork of Chia's consensus. +2. It could be added to the core CLVM, which would require a hard fork. + +## Definitions + +Throughout this document, we'll use the following terms: +* **Chialisp** - The high-level [programming language](https://chialisp.com/) from which Chia coins are constructed +* **CLVM** - [Chialisp Virtual Machine](https://chialisp.com/clvm), where the bytecode from compiled Chialisp is executed. Also commonly refers to the compiled bytecode itself +* **Keccak-256** - The same hashing standard Ethereum uses. A few notes on this standard: + * The Keccak-256 standard referred to in this CHIP is specifically version 3 of the [winning submission](https://keccak.team/files/Keccak-submission-3.pdf) to the NIST SHA-3 contest by Bertoni, Daemen, Peeters, and Van Assche in 2011 + * This standard is _not_ the same as the final [SHA-3 standard](https://en.wikipedia.org/wiki/SHA-3), which NIST released in 2015 + * The EVM uses an opcode called `SHA3`, and Solidity has an instruction called `sha3`. However, these _do not_ refer to the final SHA-3 standard. They _do_ refer to the the same `Keccak-256` standard used in this CHIP + * In order to avoid confusion, we will not use the terms `SHA3`, `sha3`, or `SHA-3` further in this CHIP. Instead, the terms `Keccak-256` and `keccak256` will be used to denote the cryptographic standard used in Ethereum + +## Motivation + +CLVM currently includes an atomic operator called [`sha256`](https://chialisp.com/operators/#atoms). This operator calculates and returns the SHA-256 hash of the input atom(s). + +This CHIP will add an atomic operator to the CLVM called `keccak256`, which will calculate and return the Keccak-256 hash of the input atom(s). The primary reason to add this operator is to support Ethereum addresses, which also rely on Keccak-256. + +## Backwards Compatibility + +If this CHIP is accepted, the new operator will be added to the CLVM. If the operator could be called directly, it would break compatibility, and therefore would require a hard fork of Chia's blockchain. However, CLVM includes a [softfork operator](https://chialisp.com/operators/#softfork) specifically to define new CLVM operators without requiring a hard fork. + +One option for this CHIP is therefore to use `softfork` operator, which itself requires a soft fork of Chia's blockchain. If this method is chosen, then after the the fork's activation, the operator will need to be called from inside the `softfork` guard. It will use a numbered extension, as will eventually be detailed in the [softfork usage](#softfork-usage) section. + +Another option is to use a hard fork, which would add the `keccak256` operator to the core CLVM operator set. + +As with all forks, there will be a risk of a chain split. The soft fork could also fail to be adopted. This might happen if an insufficient number of nodes have upgraded to include the changes introduced by this CHIP prior to the fork's block height. + +If the soft-fork method is chosen, then the operator will be introduced in multiple phases: +* **Pre-CHIP**: Prior to a yet-to-be-chosen block height, the new operator will be undefined. Any attempt to call it will return `NIL`. +* **Soft fork**: A soft fork will activate at the yet-to-be-chosen block. From that block forward, the new operator will exhibit the functionality laid out in this CHIP. It will need to be called from inside the `softfork` guard. +* **Hard fork** (hypothetical): In the event that a hard fork is enacted after the code from this CHIP has been added to the codebase, this hypothetical hard fork could include adding the operator from this CHIP to the core CLVM operator set. If this were to happen, the operator could be also be called from outside the `softfork` guard. (Note that the operator would still be callable from inside the `softfork` guard if desired.) + +If the hard-fork method is chosen, then the operator will immediately be accessible from outside the `softfork` guard (no soft fork will be performed). + +## Rationale + +This CHIP's design was primarily chosen to support Ethereum addresses. It was implemented in a manner consistent with the Keccak-256 standard. + +The new operator will incur a CLVM cost, as detailed below. If this CHIP is adopted, the new operator will be optional when designing Chia coins. + +## Specification + +### `keccak256` + +Opcode: 64 + +Functionality: Calculate and return the Keccak-256 hash of the input atom(s) + +Arguments: +* If zero arguments, the Keccak-256 hash of an empty string will be returned +* If one or more arguments: + 1. Each argument (if more than one) will be concatenated + 2. The Keccak-256 hash of the resulting string will be returned + +Usage: `(keccak256 A B …)` + +CLVM Cost: `50` base, `160` per argument, `2` per byte + +### `softfork` usage + +This section will be added if the soft fork method is chosen. + +## Test Cases + +[todo] + +## Reference Implementation + +[todo] + +## Security + +[todo] + +## Additional Assets + +None + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). + + + + From 0e16bac04fc2ff712af90183774d14ea40e4fe29 Mon Sep 17 00:00:00 2001 From: danieljperry Date: Fri, 25 Oct 2024 15:11:59 +0800 Subject: [PATCH 2/7] Assign CHIP #36 --- CHIPs/{chip-keccak256.md => chip-0036.md} | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) rename CHIPs/{chip-keccak256.md => chip-0036.md} (94%) diff --git a/CHIPs/chip-keccak256.md b/CHIPs/chip-0036.md similarity index 94% rename from CHIPs/chip-keccak256.md rename to CHIPs/chip-0036.md index d8043b7c..353c25b7 100644 --- a/CHIPs/chip-keccak256.md +++ b/CHIPs/chip-0036.md @@ -1,11 +1,11 @@ -CHIP Number | < Creator must leave this blank. Editor will assign a number.> +CHIP Number | 0036 :-------------|:---- Title | keccak256 CLVM operator Description | Add a CLVM operator to support Ethereum addresses Author | [Arvid Norberg](https://github.com/arvidn) -Editor | < Creator must leave this blank. Editor will be assigned.> -Comments-URI | < Creator must leave this blank. Editor will assign a URI.> -Status | < Creator must leave this blank. Editor will assign a status.> +Editor | [Dan Perry](https://github.com/danieljperry) +Comments-URI | [CHIPs repo, PR #131](https://github.com/Chia-Network/chips/pull/131) +Status | Draft Category | Standards Track Sub-Category | Chialisp Created | 2024-10-25 From 1a9e3ba64821a10907d443ad2e574a7c55121ef1 Mon Sep 17 00:00:00 2001 From: danieljperry Date: Wed, 20 Nov 2024 11:11:57 +0800 Subject: [PATCH 3/7] Add softfork example and clean up writing --- CHIPs/chip-0036.md | 68 ++++++++++++++++++++++++++++++++++------------ 1 file changed, 50 insertions(+), 18 deletions(-) diff --git a/CHIPs/chip-0036.md b/CHIPs/chip-0036.md index 353c25b7..90c02ae6 100644 --- a/CHIPs/chip-0036.md +++ b/CHIPs/chip-0036.md @@ -2,7 +2,7 @@ CHIP Number | 0036 :-------------|:---- Title | keccak256 CLVM operator Description | Add a CLVM operator to support Ethereum addresses -Author | [Arvid Norberg](https://github.com/arvidn) +Author | [Arvid Norberg](https://github.com/arvidn), [Rigidity](https://github.com/Rigidity) Editor | [Dan Perry](https://github.com/danieljperry) Comments-URI | [CHIPs repo, PR #131](https://github.com/Chia-Network/chips/pull/131) Status | Draft @@ -14,9 +14,7 @@ Replaces | None Superseded-By | None ## Abstract -This CHIP will add a new `keccak256` operator to the CLVM in order to enable the support of Ethereum addresses. This operator could be added in one of two ways, depending on timing: -1. It could be made accessible from behind the `softfork` guard, which would require a soft fork of Chia's consensus. -2. It could be added to the core CLVM, which would require a hard fork. +This CHIP will add a new `keccak256` operator to the CLVM in order to enable the support of Ethereum addresses. This operator will be made accessible from behind the `softfork` guard, which requires a soft fork of Chia's consensus. ## Definitions @@ -26,7 +24,7 @@ Throughout this document, we'll use the following terms: * **Keccak-256** - The same hashing standard Ethereum uses. A few notes on this standard: * The Keccak-256 standard referred to in this CHIP is specifically version 3 of the [winning submission](https://keccak.team/files/Keccak-submission-3.pdf) to the NIST SHA-3 contest by Bertoni, Daemen, Peeters, and Van Assche in 2011 * This standard is _not_ the same as the final [SHA-3 standard](https://en.wikipedia.org/wiki/SHA-3), which NIST released in 2015 - * The EVM uses an opcode called `SHA3`, and Solidity has an instruction called `sha3`. However, these _do not_ refer to the final SHA-3 standard. They _do_ refer to the the same `Keccak-256` standard used in this CHIP + * The EVM uses an opcode called `SHA3`, and Solidity has an instruction called `sha3`. However, these _do not_ refer to the final SHA-3 standard. They _do_ refer to the same `Keccak-256` standard used in this CHIP * In order to avoid confusion, we will not use the terms `SHA3`, `sha3`, or `SHA-3` further in this CHIP. Instead, the terms `Keccak-256` and `keccak256` will be used to denote the cryptographic standard used in Ethereum ## Motivation @@ -37,21 +35,17 @@ This CHIP will add an atomic operator to the CLVM called `keccak256`, which will ## Backwards Compatibility -If this CHIP is accepted, the new operator will be added to the CLVM. If the operator could be called directly, it would break compatibility, and therefore would require a hard fork of Chia's blockchain. However, CLVM includes a [softfork operator](https://chialisp.com/operators/#softfork) specifically to define new CLVM operators without requiring a hard fork. +If this CHIP is accepted, the `keccak256` operator will be added to the CLVM. If the operator could be called directly, it would break compatibility, and therefore would require a hard fork of Chia's blockchain. However, CLVM includes a [softfork operator](https://chialisp.com/operators/#softfork) specifically to define new CLVM operators without requiring a hard fork. -One option for this CHIP is therefore to use `softfork` operator, which itself requires a soft fork of Chia's blockchain. If this method is chosen, then after the the fork's activation, the operator will need to be called from inside the `softfork` guard. It will use a numbered extension, as will eventually be detailed in the [softfork usage](#softfork-usage) section. - -Another option is to use a hard fork, which would add the `keccak256` operator to the core CLVM operator set. +This CHIP will therefore use the `softfork` operator, which itself requires a soft fork of Chia's blockchain. After the fork's activation, the operator will need to be called from inside the `softfork` guard. This process is detailed in the [softfork usage](#softfork-usage) section. As with all forks, there will be a risk of a chain split. The soft fork could also fail to be adopted. This might happen if an insufficient number of nodes have upgraded to include the changes introduced by this CHIP prior to the fork's block height. -If the soft-fork method is chosen, then the operator will be introduced in multiple phases: -* **Pre-CHIP**: Prior to a yet-to-be-chosen block height, the new operator will be undefined. Any attempt to call it will return `NIL`. -* **Soft fork**: A soft fork will activate at the yet-to-be-chosen block. From that block forward, the new operator will exhibit the functionality laid out in this CHIP. It will need to be called from inside the `softfork` guard. +The operator will be introduced in multiple phases: +* **Pre-CHIP**: Prior to block [todo], the new operator will be undefined. Any attempt to call it will return `NIL`. +* **Soft fork**: A soft fork will activate at block [todo]. From that block forward, the new operator will exhibit the functionality laid out in this CHIP. It will need to be called from inside the `softfork` guard. * **Hard fork** (hypothetical): In the event that a hard fork is enacted after the code from this CHIP has been added to the codebase, this hypothetical hard fork could include adding the operator from this CHIP to the core CLVM operator set. If this were to happen, the operator could be also be called from outside the `softfork` guard. (Note that the operator would still be callable from inside the `softfork` guard if desired.) -If the hard-fork method is chosen, then the operator will immediately be accessible from outside the `softfork` guard (no soft fork will be performed). - ## Rationale This CHIP's design was primarily chosen to support Ethereum addresses. It was implemented in a manner consistent with the Keccak-256 standard. @@ -78,19 +72,57 @@ CLVM Cost: `50` base, `160` per argument, `2` per byte ### `softfork` usage -This section will be added if the soft fork method is chosen. +As explained in the [Backwards Compatibility](#backwards-compatibility) section, starting with block [todo], the operators introduced in this CHIP will be available from inside the `softfork` guard. + +The following rules apply when calling the `keccak256` operator by using the `softfork` operator: +* The `softfork` operator works like `apply` (`a`) but takes two additional parameters, `cost` and `extension` +* The syntax is therefore `softfork ( )` +* The `cost` parameter is the CLVM cost of executing the `quoted-program` with the specified `arguments`. If this cost mismatches the actual cost of executing the program, the `softfork` operator will raise an exception +* The `extension` parameter is an integer indicating the set of extensions available in the `softfork` guard. + * `extension 0` referred to the `Coin ID`, `BLS`, etc operators described in [CHIP-11](https://github.com/Chia-Network/chips/blob/main/CHIPs/chip-0011.md). + * `extension 1` will refer to the operator from this CHIP, _as well as_ those from `extension 0`. +* Just like the `a` operator, the `quoted-program` parameter is quoted and executed from inside the `softfork` guard. +* A client that does not recognize the `extension` specifier must: + * In consensus mode, ignore the whole `softfork`, return `null` and charge the specified `cost` + * In mempool mode, fail the program immediately + +Since `softfork` guards always return null, the only useful outcome of executing one is terminating (i.e. failing) the program or not. + +The cost of executing the `softfork` operator is 140. This counts against the cost specified in its arguments. + +An example of using the `softfork` operator to call the `keccak256` operator is as follows: + +``` +(softfork + (q . 842) ; expected cost (including cost of softfork itself) + (q . 1) ; extension 1 + (q a ; defer execution of if-branches + (i + (= + (keccak256 + (q . f) + (q . oobar) + ) + (q . 0x38d18acb67d25c8bb9942764b62f18e17054f66a817bd4295423adf9ed98873e) + ) + (q . 0) ; if encoding matches, return 0 + (q x) ; if encoding mismatches, raise + ) + (q . ())) ; environment to apply + (q . ())) ; environment to softfork +``` ## Test Cases -[todo] +Test cases for the `keccak256` operator are located in the [clvm_rs](https://github.com/Chia-Network/clvm_rs/blob/0e12fd49da962365e409a4d889c618b854ee34b3/op-tests/test-keccak256.txt) repository. ## Reference Implementation -[todo] +[keccak256 and softfork implementation](https://github.com/Chia-Network/clvm_rs/pull/489/files) ## Security -[todo] +Chia Network, Inc. has conducted an internal review of the code involved with this CHIP. ## Additional Assets From 7cb4547ddf1f99f81dab2f17cb3b6cee4b7520c8 Mon Sep 17 00:00:00 2001 From: danieljperry Date: Wed, 20 Nov 2024 15:17:25 +0800 Subject: [PATCH 4/7] Move CHIP-36 to Review --- CHIPs/chip-0036.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CHIPs/chip-0036.md b/CHIPs/chip-0036.md index 90c02ae6..c6981bfe 100644 --- a/CHIPs/chip-0036.md +++ b/CHIPs/chip-0036.md @@ -5,7 +5,7 @@ Description | Add a CLVM operator to support Ethereum addresses Author | [Arvid Norberg](https://github.com/arvidn), [Rigidity](https://github.com/Rigidity) Editor | [Dan Perry](https://github.com/danieljperry) Comments-URI | [CHIPs repo, PR #131](https://github.com/Chia-Network/chips/pull/131) -Status | Draft +Status | Review Category | Standards Track Sub-Category | Chialisp Created | 2024-10-25 From b72e82e9c969f90e9bdb209c97bf5a846e1db7ae Mon Sep 17 00:00:00 2001 From: danieljperry Date: Fri, 6 Dec 2024 10:14:42 +0800 Subject: [PATCH 5/7] Add soft fork height and testcases --- CHIPs/chip-0036.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/CHIPs/chip-0036.md b/CHIPs/chip-0036.md index c6981bfe..9ea654a5 100644 --- a/CHIPs/chip-0036.md +++ b/CHIPs/chip-0036.md @@ -42,8 +42,8 @@ This CHIP will therefore use the `softfork` operator, which itself requires a so As with all forks, there will be a risk of a chain split. The soft fork could also fail to be adopted. This might happen if an insufficient number of nodes have upgraded to include the changes introduced by this CHIP prior to the fork's block height. The operator will be introduced in multiple phases: -* **Pre-CHIP**: Prior to block [todo], the new operator will be undefined. Any attempt to call it will return `NIL`. -* **Soft fork**: A soft fork will activate at block [todo]. From that block forward, the new operator will exhibit the functionality laid out in this CHIP. It will need to be called from inside the `softfork` guard. +* **Pre-CHIP**: Prior to block `6 800 000` (six million, eight hundred thousand), the new operator will be undefined. Any attempt to call it will return `NIL`. +* **Soft fork**: A soft fork will activate at block `6 800 000`. From that block forward, the new operator will exhibit the functionality laid out in this CHIP. It will need to be called from inside the `softfork` guard. * **Hard fork** (hypothetical): In the event that a hard fork is enacted after the code from this CHIP has been added to the codebase, this hypothetical hard fork could include adding the operator from this CHIP to the core CLVM operator set. If this were to happen, the operator could be also be called from outside the `softfork` guard. (Note that the operator would still be callable from inside the `softfork` guard if desired.) ## Rationale @@ -72,7 +72,7 @@ CLVM Cost: `50` base, `160` per argument, `2` per byte ### `softfork` usage -As explained in the [Backwards Compatibility](#backwards-compatibility) section, starting with block [todo], the operators introduced in this CHIP will be available from inside the `softfork` guard. +As explained in the [Backwards Compatibility](#backwards-compatibility) section, starting with block `6 800 000`, the operators introduced in this CHIP will be available from inside the `softfork` guard. The following rules apply when calling the `keccak256` operator by using the `softfork` operator: * The `softfork` operator works like `apply` (`a`) but takes two additional parameters, `cost` and `extension` @@ -116,9 +116,12 @@ An example of using the `softfork` operator to call the `keccak256` operator is Test cases for the `keccak256` operator are located in the [clvm_rs](https://github.com/Chia-Network/clvm_rs/blob/0e12fd49da962365e409a4d889c618b854ee34b3/op-tests/test-keccak256.txt) repository. +Additional tests were added as part of [PR #18988](https://github.com/Chia-Network/chia-blockchain/pull/18988) of the `chia-blockchain` repository. + ## Reference Implementation -[keccak256 and softfork implementation](https://github.com/Chia-Network/clvm_rs/pull/489/files) +* [keccak256 and softfork implementation](https://github.com/Chia-Network/clvm_rs/pull/489/files) in Rust +* [softfork implementation](https://github.com/Chia-Network/chia-blockchain/pull/18988/files) in the `chia-blockchain` repository ## Security From 2b771cc22a4fb6b0abf2122b90dda0a9e488e76b Mon Sep 17 00:00:00 2001 From: danieljperry Date: Sat, 7 Dec 2024 07:56:02 +0800 Subject: [PATCH 6/7] Move CHIP-36 to Last Call --- CHIPs/chip-0036.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CHIPs/chip-0036.md b/CHIPs/chip-0036.md index 9ea654a5..ee5e69b1 100644 --- a/CHIPs/chip-0036.md +++ b/CHIPs/chip-0036.md @@ -5,7 +5,7 @@ Description | Add a CLVM operator to support Ethereum addresses Author | [Arvid Norberg](https://github.com/arvidn), [Rigidity](https://github.com/Rigidity) Editor | [Dan Perry](https://github.com/danieljperry) Comments-URI | [CHIPs repo, PR #131](https://github.com/Chia-Network/chips/pull/131) -Status | Review +Status | Last Call Category | Standards Track Sub-Category | Chialisp Created | 2024-10-25 From f43dcae9705249554270093f4d611c8dbbecf0fb Mon Sep 17 00:00:00 2001 From: danieljperry Date: Thu, 19 Dec 2024 13:44:58 -0600 Subject: [PATCH 7/7] Move CHIP-36 to Final status --- CHIPs/chip-0036.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CHIPs/chip-0036.md b/CHIPs/chip-0036.md index ee5e69b1..3b88680c 100644 --- a/CHIPs/chip-0036.md +++ b/CHIPs/chip-0036.md @@ -5,7 +5,7 @@ Description | Add a CLVM operator to support Ethereum addresses Author | [Arvid Norberg](https://github.com/arvidn), [Rigidity](https://github.com/Rigidity) Editor | [Dan Perry](https://github.com/danieljperry) Comments-URI | [CHIPs repo, PR #131](https://github.com/Chia-Network/chips/pull/131) -Status | Last Call +Status | Final Category | Standards Track Sub-Category | Chialisp Created | 2024-10-25