Create bigint_modexp.md #198

vbuterin · 2017-01-30T10:35:29Z

Precompile for bigint modular exponentiation. Meant to supersede #101.

axic · 2017-02-06T23:30:32Z

EIPS/bigint_modexp.md

+
+    <length_of_BASE> <length_of_EXPONENT> <length_of_MODULUS> <BASE> <EXPONENT> <MODULUS>
+
+Where every length is a 32-byte left-padded integer representing the number of bytes to be taken up by the next value. Call data is assumed to be infinitely right-padded with zero bytes, and excess data is ignored. Consumes `floor(max(length_of_MODULUS, length_of_BASE) ** 2 * max(length_of_EXPONENT, 1) / GQUADDIVISOR)` gas, and if there is enough gas, returns an output `(BASE**EXPONENT) % MODULUS` as a byte array with the same length as the modulus.


Would it be safe assuming that it is unlikely to have calls consuming gigabytes of data?

If yes, how about making each length field 32 bits wide (or even less):

00000001 00000020 00000020 03 fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2e fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f

I understand we have 0 gas for 0 bytes in the payload, but does that make any sense?

"representing the number of bytes to be taken up by the next value" <- I don't think this is correct anymore. It used to be like that in the initial drafts, but not anymore.

vbuterin · 2017-02-10T16:19:30Z

I like 32 bytes more for two reasons:

Similarity to how the existing ABI works, and generally how ethereum works (we don't really do static sizes other than 32 at this point)
It's actually easier to pack 32 bytes in EVM than it is to pack 4 bytes in EVM; the latter requires some arithmetic manipulations to fit the slice in, whereas the former is the same width as MLOAD/MSTORE so it works directly.

axic · 2017-02-11T12:15:39Z

It's actually easier to pack 32 bytes in EVM than it is to pack 4 bytes in EVM

We could also pack them into a single 32 byte slot, that would make it easier. That would only need multiplication (2 times) and a single mstore.

If however the motivation is to make it easy on ABI encoding, then I would change the gas calculation not to be based on supplied length, but based on first byte set. That would allow sending each field as a multiple of 32 bytes.

Your example would become:

     0000000000000000000000000000000000000000000000000000000000000020
     0000000000000000000000000000000000000000000000000000000000000020
     0000000000000000000000000000000000000000000000000000000000000020
     0000000000000000000000000000000000000000000000000000000000000003
     fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2e
     fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f

This way it is up to the caller's implementation to decide which is more beneficial: allocating more memory or using more instructions to pack them tight.

Souptacular · 2017-02-21T16:57:59Z

Please make compliant with EIP-0 (eg, add a header with number/status etc), renumber to EIP 198 (or the issue number), update in response to any comments, and tag with editor-needs-to-review when it's ready for merge.

pirapira · 2017-03-03T13:34:15Z

@vbuterin What is the value of (0 ** 0) % 10000? Zero or one? Maybe one because PUSH_1 0 PUSH_1 0 EXP results in one.

rphmeier · 2017-03-15T17:49:18Z

EIPS/bigint_modexp.md

+    fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2e
+    fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f
+
+Would be parsed as a base of 0, exponent of `2**256 - 2**32 - 978` and modulus of `2**256 - 2**32 - 978`, and so would return 0. Notice how if the length_of_BASE is 0, then it does not interpret _any_ data as the base, instead immediately interpreting the next 32 bytes as length_of_EXPONENT.


length_of_EXPONENT -> EXPONENT?

Why? BASE is followed by length_of_EXPONENT.

L9: <length_of_BASE> <length_of_EXPONENT> <length_of_MODULUS> <BASE> <EXPONENT> <MODULUS>

Since length_of_BASE is zero, it does not interpret any data as the base. The following 32 bytes (after the zero-length BASE) are the EXPONENT, not the length_of_EXPONENT.

Also, modulus is interpreted as 2**256 - 2**32 - 977

pirapira · 2017-03-15T18:33:37Z

You're right. I was not following the format change in the last commit.

gumb0 · 2017-04-04T13:26:46Z

EIPS/bigint_modexp.md

+    fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe
+    fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffd
+
+Would parse a base length of 0, a modulus length of 32, and an exponent length of `2**256 - 1`, where the base is empty, the modulus is `2**256 - 2` and the exponent is `(2**256 - 3) * 256**(2**256 - 33)` (yes, that's a really big number). It would then immediately fail, as it's not possible to provide enough gas to make that computation.


This is base of length 0, an exponent of length 32 and modulus of length 2**256 - 1.
The exponent is 2**256 - 2, the modulus is (2**256 - 3) * 256**(2**256 - 33)

This seems correct. I apply this change.

Arachnid · 2017-04-14T11:49:04Z

Please update to follow the template here and rename to eip-198.md, and we'll merge as draft.

axic · 2017-04-23T16:47:27Z

I would change the gas calculation not to be based on supplied length, but based on first byte set. That would allow sending each field as a multiple of 32 bytes.

I would like to propose this again. This enables callers to save on gas costs. (See the explanation above)

@vbuterin ?

chfast · 2017-04-23T17:39:06Z

I support for paying only for significant bytes in the provided data (the same way it is done for exponent of EXP).

If the field lengths are known at the "compile" time in most of the use cases, can we represent all lengths in a single word, with 32-bit reserved per field length?

When the lengths are combined (and known up-front) we have: PUSH 0x200000002000000020 PUSH 0x00 MSTORE (13 bytes of code).
When the lengths occupy a word each we have: PUSH 0x20 PUSH 0x00 MSTORE PUSH 0x20 PUSH 0x01 MSTORE PUSH 0x20 PUSH 0x02 MSTORE (15 bytes of code).

pirapira · 2017-04-24T10:34:19Z

This PR is meant to replace #101, but I'm not seeing big int addition, subtraction, multiplication or division in this PR. Are they going to be added or not? This affects the choice of addresses for the following precompiled contracts.

pirapira · 2017-04-24T10:42:21Z

~~Since #101 and #198 use different addresses, there is uncertainty about what address is assigned to which contract. I added [WIP] in the title.~~ I was trying to change my PR in yellowpaper repository.

riordant · 2017-09-18T11:33:10Z

What is recommended for doing bigint division now that the division precompile was removed? Currently I am getting the reciprocal of the divisor using the Newton-Raphson method and multiplying with the dividend using this contract. Is that sufficient?

tristanhoy · 2017-09-21T23:55:02Z

Division is incredibly slow - but there is an alternative for some cases.

Modular reduction (and therefore exponentiation) for any cryptographic scheme operating over a public prime group (Schnorr, ECC, ElGamal) can be massively sped up when a prime is chosen that is close to a power of two (e.g. 2^255 - 19, 2^3072 - 77405 etc).

The algorithm is really simple: https://gist.github.com/tristanhoy/01450b820864aa7205587581c7b12099

Additionally, if a set of recommended public primes are provided, the gas costs for exponentiation will be very predictable (unlike the product of two secret primes).

https://github.com/ethereum/EIPs/pull/198/files#r106236783

https://github.com/ethereum/EIPs/pull/198/files#r109660742

pirapira · 2017-12-01T11:53:56Z

@vbuterin do you mind if I append

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

?

Because ethereum/EIPs#198 supersedes ethereum/EIPs#101 and the new version does not contain these.

fulldecent · 2018-03-22T16:16:50Z

@Arachnid You nominated this as an "EIPs that should be merged". Can you please share your notes on that here?

Arachnid · 2018-03-22T16:19:59Z

This pull request is referenced by #609, which has already been merged. As such, it needs to either be finalised and merged, or the dependency in the existing EIP needs to be removed.

… notice.

Rename bigint_modexp.md to eip-198.md, add new prologue and copyrigt notice

Arachnid · 2018-03-27T15:12:32Z

This is a courtesy notice to let you know that the format for EIPs has been modified slightly. If you want your draft merged, you will need to make some small changes to how your EIP is formatted:

Frontmatter is now contained between lines with only a triple dash ('---')
Headers in the frontmatter are now lowercase.

If your PR is editing an existing EIP rather than creating a new one, this has already been done for you, and you need only rebase your PR.

In addition, a continuous build has been setup, which will check your PR against the rules for EIP formatting automatically once you update your PR. This build ensures all required headers are present, as well as performing a number of other checks.

Please rebase your PR against the latest master, and edit your PR to use the above format for frontmatter. For convenience, here's a sample header you can copy and adapt:

---
eip: <num>
title: <title>
author: <author>
type: [Standards Track|Informational|Meta]
category: [Core|Networking|Interface|ERC] (for type: Standards Track only)
status: Draft
created: <date>
---

* Create bigint_modexp.md * Update bigint_modexp.md * Update bigint_modexp.md * Update bigint_modexp.md * Update bigint_modexp.md * Update bigint_modexp.md * Update bigint_modexp.md * Update bigint_modexp.md * Update bigint_modexp.md * Update bigint_modexp.md * Update bigint_modexp.md * Update bigint_modexp.md * Update bigint_modexp.md * Fixing an example after the specification change https://github.com/ethereum/EIPs/pull/198/files#r106236783 * Fix one example after a format change https://github.com/ethereum/EIPs/pull/198/files#r109660742 * Rename bigint_modexp.md to eip-198.md, add new prologue and copyright notice.

Akrom99 · 2024-06-13T02:16:03Z

Good projeck

vbuterin added 3 commits January 30, 2017 05:35

Create bigint_modexp.md

fd1d312

Update bigint_modexp.md

22b92a0

Update bigint_modexp.md

61145e3

obscuren mentioned this pull request Feb 1, 2017

core/vm: big expmod - eip#198 progress ethereum/go-ethereum#3633

Closed

vbuterin added 3 commits February 1, 2017 21:27

Update bigint_modexp.md

c4a771e

Update bigint_modexp.md

1c3ee13

Update bigint_modexp.md

60fe651

axic reviewed Feb 6, 2017

View reviewed changes

Souptacular mentioned this pull request Feb 10, 2017

All Core Devs Meeting 10 Agenda ethereum/pm#5

Closed

pirapira mentioned this pull request Mar 3, 2017

EIP101/198: bigint arithmetics precompiled contracts ethereum/aleth#3615

Closed

arkpar mentioned this pull request Mar 9, 2017

Byzantium release openethereum/parity-ethereum#4833

Closed

12 tasks

rphmeier reviewed Mar 15, 2017

View reviewed changes

rphmeier mentioned this pull request Mar 15, 2017

EIP198 and built-in activation openethereum/parity-ethereum#4926

Merged

gumb0 mentioned this pull request Apr 3, 2017

EIP198 - Bigint modexp precompiled contract ethereum/aleth#4028

Merged

3 tasks

gumb0 reviewed Apr 4, 2017

View reviewed changes

Arachnid added EIP labels Apr 14, 2017

chfast mentioned this pull request Apr 21, 2017

[META] Byzantium implementation progress ethereum/aleth#4050

Closed

17 tasks

pirapira mentioned this pull request Apr 24, 2017

Precompiles for bigint arithmetic #101

Closed

pirapira mentioned this pull request Apr 24, 2017

[WIP] EIP 101: big-int precompiles ethereum/yellowpaper#235

Open

mkalinin mentioned this pull request Aug 25, 2017

Byzantium release ethereum/ethereumj#923

Closed

13 tasks

Update bigint_modexp.md

3005564

pipermerriam mentioned this pull request Oct 20, 2017

Byzantium Fork Rules ethereum/py-evm#123

Merged

9 tasks

pirapira mentioned this pull request Oct 23, 2017

Apply Byzantium changes pirapira/eth-isabelle#459

Open

10 tasks

nicksavers mentioned this pull request Nov 17, 2017

Vbuterin patch 2 #751

Closed

5chdn mentioned this pull request Nov 18, 2017

Move Meta Byzantium to Finalized #770

Closed

pirapira added 2 commits November 30, 2017 16:13

Fixing an example after the specification change

ca82cd9

https://github.com/ethereum/EIPs/pull/198/files#r106236783

Fix one example after a format change

f417998

https://github.com/ethereum/EIPs/pull/198/files#r109660742

nicksavers mentioned this pull request Dec 12, 2017

Update links to EIPs in Byzantium Informational #796

Merged

tinybike mentioned this pull request Jan 9, 2018

No file for EIP-198 #825

Closed

pirapira added a commit to pirapira/yellowpaper that referenced this pull request Jan 17, 2018

Remove add, sub, mul and div precompiles

3ff0df0

Because ethereum/EIPs#198 supersedes ethereum/EIPs#101 and the new version does not contain these.

pirapira added a commit to pirapira/yellowpaper that referenced this pull request Jan 17, 2018

Reformulate EXPMOD as ethereum/EIPs#198 specifies

ab64389

pirapira added a commit to pirapira/yellowpaper that referenced this pull request Jan 19, 2018

Reformulate EXPMOD as ethereum/EIPs#198 specifies

aa475fc

pirapira added a commit to pirapira/yellowpaper that referenced this pull request Jan 19, 2018

Reformulate EXPMOD as ethereum/EIPs#198 specifies

dfe36bb

Arachnid added the needs-merge label Mar 22, 2018

Arachnid and others added 2 commits March 25, 2018 17:56

Rename bigint_modexp.md to eip-198.md, add new prologue and copyright…

9504333

… notice.

Merge pull request #946 from ethereum/vbuterin-patch-2-patch

5f92749

Rename bigint_modexp.md to eip-198.md, add new prologue and copyrigt notice

Arachnid approved these changes Mar 27, 2018

View reviewed changes

Arachnid merged commit a76a0a0 into master Mar 27, 2018

Arachnid deleted the vbuterin-patch-2 branch March 27, 2018 14:34

aerth mentioned this pull request Jun 5, 2018

HF7 @ 36050 aquanetwork/aquachain#24

Merged

holgerd77 mentioned this pull request Jun 25, 2020

SpuriousDragon HF Support ethereumjs/ethereumjs-monorepo#791

Merged

15 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Create bigint_modexp.md #198

Create bigint_modexp.md #198

vbuterin commented Jan 30, 2017

axic Feb 6, 2017 •

edited

Loading

pirapira Apr 24, 2017

Yeazaaa Apr 3, 2023

vbuterin commented Feb 10, 2017

axic commented Feb 11, 2017 •

edited

Loading

Souptacular commented Feb 21, 2017

pirapira commented Mar 3, 2017 •

edited

Loading

rphmeier Mar 15, 2017

pirapira Mar 15, 2017

rphmeier Mar 15, 2017

gumb0 Apr 4, 2017

pirapira commented Mar 15, 2017 via email

gumb0 Apr 4, 2017

pirapira Dec 1, 2017

Arachnid commented Apr 14, 2017

axic commented Apr 23, 2017 •

edited

Loading

chfast commented Apr 23, 2017

pirapira commented Apr 24, 2017

pirapira commented Apr 24, 2017 •

edited

Loading

riordant commented Sep 18, 2017

tristanhoy commented Sep 21, 2017

pirapira commented Dec 1, 2017

fulldecent commented Mar 22, 2018

Arachnid commented Mar 22, 2018

Arachnid commented Mar 27, 2018

Akrom99 commented Jun 13, 2024


		<length_of_BASE> <length_of_EXPONENT> <length_of_MODULUS> <BASE> <EXPONENT> <MODULUS>

		Where every length is a 32-byte left-padded integer representing the number of bytes to be taken up by the next value. Call data is assumed to be infinitely right-padded with zero bytes, and excess data is ignored. Consumes `floor(max(length_of_MODULUS, length_of_BASE) ** 2 * max(length_of_EXPONENT, 1) / GQUADDIVISOR)` gas, and if there is enough gas, returns an output `(BASE**EXPONENT) % MODULUS` as a byte array with the same length as the modulus.

Create bigint_modexp.md #198

Create bigint_modexp.md #198

Conversation

vbuterin commented Jan 30, 2017

axic Feb 6, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vbuterin commented Feb 10, 2017

axic commented Feb 11, 2017 • edited Loading

Souptacular commented Feb 21, 2017

pirapira commented Mar 3, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pirapira commented Mar 15, 2017 via email

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Arachnid commented Apr 14, 2017

axic commented Apr 23, 2017 • edited Loading

chfast commented Apr 23, 2017

pirapira commented Apr 24, 2017

pirapira commented Apr 24, 2017 • edited Loading

riordant commented Sep 18, 2017

tristanhoy commented Sep 21, 2017

pirapira commented Dec 1, 2017

fulldecent commented Mar 22, 2018

Arachnid commented Mar 22, 2018

Arachnid commented Mar 27, 2018

Akrom99 commented Jun 13, 2024

axic Feb 6, 2017 •

edited

Loading

axic commented Feb 11, 2017 •

edited

Loading

pirapira commented Mar 3, 2017 •

edited

Loading

axic commented Apr 23, 2017 •

edited

Loading

pirapira commented Apr 24, 2017 •

edited

Loading