GAS opcode should be included in purity checker
See original GitHub issueIssue
Purity checker does not currently include the GAS
opcode. This opcode can reveal information about the outside world and can make the result of the function not entirely deterministic upon its input arguments.
Proposed Implementation
- Add
GAS
opcode (0x5a
) to the purity checker - Compile to bytecode and integrate into testing setup in
conftest.py
- Update deploy scripts
Issue Analytics
- State:
- Created 5 years ago
- Comments:21 (10 by maintainers)
Top Results From Across the Web
sigp/opcode-purity: A document describing purity ... - GitHub
A contract is considered pure if it will always return the same result given sufficient gas for execution and the same transaction data...
Read more >Opcodes for the EVM - Ethereum.org
Stack Name Gas Initial Stack Resulting Stack
00 STOP 0
01 ADD 3 a, b a + b
02 MUL 5 a, b a * b...
Read more >EIP-1153: Transient storage opcodes - Core EIPs - Fellowship of ...
I would rather the gas costs be fixed than for two opcodes to go toward this. ... You'd then change how SSTORE is...
Read more >Appendix A: Ethereum EVM Opcodes and Gas Consumption
Opcode Name Gas
0x00 STOP 0
0x01 ADD 3
0x02 MUL 5
Read more >Fmt - River Thames Conditions - Environment Agency - GOV.UK
Grammar checking sentences, Semi marathon bolbec 2011, ... Scottish power vs british gas, 45601 resistant materials, Winterboard not working ios 7.0.6.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@gitcoinbot refer #169
Purity of contracts defined by this purity checker need to give a deterministic output only on the parameters pass in, not on the state of the blockchain at the time. An example could be something like the following:
This function is not deterministic on its inputs but rather on the state of the context of its execution. If a validator’s signature had such a triviality, they could sign a message that would validate as True in one context but not in another. Thus opening up the potential of being able to sign nefarious messages and not get slashed for it.