Short Weierstrass wrapping curve for BLS12-377 #2541
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Make even with master
|
|
||
| ##### Encoding of scalars for multiplication operation: | ||
|
|
||
| Group order has 377 bits so scalars for multiplication operation is redundantly encoded as `48` bytes by performing BigEndian encoding of the corresponding (unsigned) integer. Corresponding integer is **not** required to be less than or equal than main subgroup size. |
There was a problem hiding this comment.
@shamatar to be compatible with 32-byte 'words' of the EVM/Solidity (and to allow easy mload and mstore operations of 32-byte values in assembly), perhaps scalars should be encoded as 64 bytes instead?
Either:
- the first
16-bytes could be enforced to be all zeros; or - any 64-byte integer could be permitted, and precompiles would need to coerce any
64-byte value into an element ofFr(whereris the 377-bit main subgroup order).
(I prefer the first option)
It'd be great to get your thoughts.
I'm facing the same decision making process for an EIP for the BW6-761 curve (which also has a 377-bit scalar field).
|
There has been no activity on this pull request for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review. |
MicahZoltu
suggested changes
Sep 9, 2020
Comment on lines
+13
to
+14
| <!--You can leave these HTML comments in your merged EIP and delete the visible duplicate text guides, they will not appear and may be helpful to refer to if you edit it again. This is the suggested template for new EIPs. Note that an EIP number will be assigned by an editor. When opening a pull request to submit your EIP, please use an abbreviated title in the filename, `eip-draft_title_abbrev.md`. The title should be 44 characters or less.--> | ||
|
|
There was a problem hiding this comment.
Suggested change
| <!--You can leave these HTML comments in your merged EIP and delete the visible duplicate text guides, they will not appear and may be helpful to refer to if you edit it again. This is the suggested template for new EIPs. Note that an EIP number will be assigned by an editor. When opening a pull request to submit your EIP, please use an abbreviated title in the filename, `eip-draft_title_abbrev.md`. The title should be 44 characters or less.--> |
Comment on lines
+16
to
+17
| <!--"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the EIP.--> | ||
|
|
There was a problem hiding this comment.
Suggested change
| <!--"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the EIP.--> |
Comment on lines
+21
to
+22
| <!--A short (~200 word) description of the technical issue being addressed.--> | ||
|
|
There was a problem hiding this comment.
Suggested change
| <!--A short (~200 word) description of the technical issue being addressed.--> |
Comment on lines
+36
to
+37
| <!--The motivation is critical for EIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the EIP solves. EIP submissions without sufficient motivation may be rejected outright.--> | ||
|
|
There was a problem hiding this comment.
Suggested change
| <!--The motivation is critical for EIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the EIP solves. EIP submissions without sufficient motivation may be rejected outright.--> |
Comment on lines
+41
to
+42
| <!--The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and [others](https://github.com/ethereum/wiki/wiki/Clients)).--> | ||
|
|
There was a problem hiding this comment.
Suggested change
| <!--The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and [others](https://github.com/ethereum/wiki/wiki/Clients)).--> |
| Test vector for all operations are expanded in this [gist](https://gist.github.com/shamatar/c2cf7608fb4dee4d23f40461da15ad8c) until it's final. | ||
|
|
||
| ## Implementation | ||
| <!--The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.--> |
There was a problem hiding this comment.
Suggested change
| <!--The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.--> |
| - EIP1962 code bases with fixed parameters | ||
|
|
||
| ## Security Considerations | ||
| <!--All EIPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life cycle of the proposal. E.g. include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. EIP submissions missing the "Security Considerations" section will be rejected. An EIP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers.--> |
There was a problem hiding this comment.
Suggested change
| <!--All EIPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life cycle of the proposal. E.g. include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. EIP submissions missing the "Security Considerations" section will be rejected. An EIP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers.--> |
| eip: 2541 | ||
| title: EY SW6-Bis curve operations | ||
| author: Alex Vlasov (@shamatar) | ||
| discussions-to: https://github.com/ethereum/EIPs/pull/2541 |
There was a problem hiding this comment.
This cannot be the Pull Request. You can create a thread on https://ethereum-magicians.org/ or you can create an issue here on GitHub.
axic
reviewed
Sep 9, 2020
| type: Standards Track | ||
| category: Core | ||
| created: 2020-02-27 | ||
| requires : 1109, 2046 |
There was a problem hiding this comment.
Suggested change
| requires : 1109, 2046 | |
| requires: 1109, 2046 |
|
This pull request was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This EIP adds specification to support an "outer" wrapping curve to allow aggregation of proof and signatures on BLS12-377 (Zexe curve).