Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update Frontier #307

Open
wants to merge 52 commits into
base: frontier
Choose a base branch
from
Open

Update Frontier #307

wants to merge 52 commits into from

Conversation

pirapira
Copy link
Member

This PR updates the frontier branch, cherry-picking the commits in master that are not about the more recent hardforks.

@pirapira pirapira force-pushed the frontier branch 2 times, most recently from 5b493cf to 47a8195 Compare January 31, 2018 13:09
@fulldecent
Copy link
Contributor

fulldecent commented Feb 16, 2018

Maybe this type of "backporting" PR will be opened many times (for Frontier and others). Do you have a system in mind to track this?

@jamesray1
Copy link
Contributor

jamesray1 commented Feb 21, 2018

Note that the merge conflicts need to be fixed and there are other changes that have been made and are pending in PRs that would apply to previous releases. PR titles and commit summaries should include an abbreviate to indicate whether they are a release-specific change or not, in order to help systematize these kind of changes. E.g. RS = Release-specific. GC = general change (not release specific), applies to all releases. Either should be explicitly included.

@jamesray1
Copy link
Contributor

Or better than or in addition to RS: have the specific release. Changes in a release may apply in future releases, unless overwritten or major protocol-wide sweeping changes occur, e.g. abstraction, Casper, statelessness, etc.

4tXJ7f and others added 24 commits April 4, 2018 18:27
… is already used nearby for the set of nibble sequences.
This commit adds notes to MLOAD, MSTORE and MSTORE8 specification
saying the modulo is not considered when computing the new memory
size.

Before this change, since the beginning of the table contains
`All arithmetic is modulo $2^{256}$ unless otherwise noted.`,
the memory size computation was affected by the modulo computation too.
For instance, MLOAD with the biggest uint256 didn't change the memory size
most of the time.
Before this commit, equation (100) was not satisfiable when s and r
were equal and v + v was not zero.  Though this equation is further
complemented in equations (101) through (104), I thought (100) needed
a condition s != r.
pirapira and others added 28 commits April 4, 2018 18:30
)

The VMtest case calldatacopy_DataIndexTooHigh suggests this behavior.
This solves ethereum#190.  The other way of putting parentheses
did not make sense becasue `sign(x) * |x|` can immediately
be optimized into `x`.

Also, I checked one EVM implementation's behavior
```
evm --debug --code "60601960401907"
```
and saw SMOD returning a negative-looking number.
as in other occurrences.
Also cleanup nomenclature around byte sequences.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.