Merge pull request #1164 from ethereum/keccak256-alias

Add alias keccak256() for sha3()
This commit is contained in:
Yoichi Hirai 2016-10-06 18:33:00 +02:00 committed by GitHub
commit 3f833c9ef4
9 changed files with 52 additions and 27 deletions

View File

@ -1,8 +1,10 @@
### 0.4.3 (unreleased)
Features:
* Inline assembly: support both `sucide` and `selfdestruct` opcodes
(note: `suicide` is deprecated)
* Include `keccak256()` as an alias to `sha3()`
Bugfixes:
* Disallow unknown options in `solc`

View File

@ -136,7 +136,7 @@ This means that cyclic creation dependencies are impossible.
) returns (bool ok) {
// Check some arbitrary condition.
address tokenAddress = msg.sender;
return (sha3(newOwner) & 0xff) == (bytes20(tokenAddress) & 0xff);
return (keccak256(newOwner) & 0xff) == (bytes20(tokenAddress) & 0xff);
}
}
@ -544,7 +544,7 @@ to be searched for: It is possible to filter for specific values of
indexed arguments in the user interface.
If arrays (including ``string`` and ``bytes``) are used as indexed arguments, the
sha3-hash of it is stored as topic instead.
Keccak-256 hash of it is stored as topic instead.
The hash of the signature of the event is one of the topics except if you
declared the event with ``anonymous`` specifier. This means that it is
@ -622,7 +622,7 @@ as topics. The event call above can be performed in the same way as
);
where the long hexadecimal number is equal to
``sha3("Deposit(address,hash256,uint256)")``, the signature of the event.
``keccak256("Deposit(address,hash256,uint256)")``, the signature of the event.
Additional Resources for Understanding Events
==============================================

View File

@ -34,17 +34,17 @@ Statically-sized variables (everything except mapping and dynamically-sized arra
The elements of structs and arrays are stored after each other, just as if they were given explicitly.
Due to their unpredictable size, mapping and dynamically-sized array types use a ``sha3``
Due to their unpredictable size, mapping and dynamically-sized array types use a Keccak-256 hash
computation to find the starting position of the value or the array data. These starting positions are always full stack slots.
The mapping or the dynamic array itself
occupies an (unfilled) slot in storage at some position ``p`` according to the above rule (or by
recursively applying this rule for mappings to mappings or arrays of arrays). For a dynamic array, this slot stores the number of elements in the array (byte arrays and strings are an exception here, see below). For a mapping, the slot is unused (but it is needed so that two equal mappings after each other will use a different hash distribution).
Array data is located at ``sha3(p)`` and the value corresponding to a mapping key
``k`` is located at ``sha3(k . p)`` where ``.`` is concatenation. If the value is again a
non-elementary type, the positions are found by adding an offset of ``sha3(k . p)``.
Array data is located at ``keccak256(p)`` and the value corresponding to a mapping key
``k`` is located at ``keccak256(k . p)`` where ``.`` is concatenation. If the value is again a
non-elementary type, the positions are found by adding an offset of ``keccak256(k . p)``.
``bytes`` and ``string`` store their data in the same slot where also the length is stored if they are short. In particular: If the data is at most ``31`` bytes long, it is stored in the higher-order bytes (left aligned) and the lowest-order byte stores ``length * 2``. If it is longer, the main slot stores ``length * 2 + 1`` and the data is stored as usual in ``sha3(slot)``.
``bytes`` and ``string`` store their data in the same slot where also the length is stored if they are short. In particular: If the data is at most ``31`` bytes long, it is stored in the higher-order bytes (left aligned) and the lowest-order byte stores ``length * 2``. If it is longer, the main slot stores ``length * 2 + 1`` and the data is stored as usual in ``keccak256(slot)``.
So for the following contract snippet::
@ -54,7 +54,7 @@ So for the following contract snippet::
mapping(uint => mapping(uint => s)) data;
}
The position of ``data[4][9].b`` is at ``sha3(uint256(9) . sha3(uint256(4) . uint256(1))) + 1``.
The position of ``data[4][9].b`` is at ``keccak256(uint256(9) . keccak256(uint256(4) . uint256(1))) + 1``.
*****************
Esoteric Features
@ -281,7 +281,7 @@ The following is the order of precedence for operators, listed in order of evalu
| *16* | Comma operator | ``,`` |
+------------+-------------------------------------+--------------------------------------------+
.. index:: block, coinbase, difficulty, number, block;number, timestamp, block;timestamp, msg, data, gas, sender, value, now, gas price, origin, sha3, ripemd160, sha256, ecrecover, addmod, mulmod, cryptography, this, super, selfdestruct, balance, send
.. index:: block, coinbase, difficulty, number, block;number, timestamp, block;timestamp, msg, data, gas, sender, value, now, gas price, origin, keccak256, ripemd160, sha256, ecrecover, addmod, mulmod, cryptography, this, super, selfdestruct, balance, send
Global Variables
================
@ -299,7 +299,8 @@ Global Variables
- ``now`` (``uint``): current block timestamp (alias for ``block.timestamp``)
- ``tx.gasprice`` (``uint``): gas price of the transaction
- ``tx.origin`` (``address``): sender of the transaction (full call chain)
- ``sha3(...) returns (bytes32)``: compute the Ethereum-SHA-3 (KECCAK-256) hash of the (tightly packed) arguments
- ``keccak256(...) returns (bytes32)``: compute the Ethereum-SHA-3 (Keccak-256) hash of the (tightly packed) arguments
- ``sha3(...) returns (bytes32)``: an alias to `keccak256()`
- ``sha256(...) returns (bytes32)``: compute the SHA-256 hash of the (tightly packed) arguments
- ``ripemd160(...) returns (bytes20)``: compute the RIPEMD-160 hash of the (tightly packed) arguments
- ``ecrecover(bytes32 hash, uint8 v, bytes32 r, bytes32 s) returns (address)``: recover address associated with the public key from elliptic curve signature, return zero on error

View File

@ -207,7 +207,7 @@ Minor Details
You can craft transactions that call a function ``f(uint8 x)`` with a raw byte argument
of ``0xff000001`` and with ``0x00000001``. Both are fed to the contract and both will
look like the number ``1`` as far as ``x`` is concerned, but ``msg.data`` will
be different, so if you use ``sha3(msg.data)`` for anything, you will get different results.
be different, so if you use ``keccak256(msg.data)`` for anything, you will get different results.
***************
Recommendations

View File

@ -415,7 +415,7 @@ high or low invalid bids.
revealEnd = biddingEnd + _revealTime;
}
/// Place a blinded bid with `_blindedBid` = sha3(value,
/// Place a blinded bid with `_blindedBid` = keccak256(value,
/// fake, secret).
/// The sent ether is only refunded if the bid is correctly
/// revealed in the revealing phase. The bid is valid if the
@ -459,7 +459,7 @@ high or low invalid bids.
var bid = bids[msg.sender][i];
var (value, fake, secret) =
(_values[i], _fake[i], _secret[i]);
if (bid.blindedBid != sha3(value, fake, secret)) {
if (bid.blindedBid != keccak256(value, fake, secret)) {
// Bid was not actually revealed.
// Do not refund deposit.
continue;

View File

@ -106,7 +106,7 @@ the function ``call`` is provided which takes an arbitrary number of arguments o
address nameReg = 0x72ba7d8e73fe8eb666ea66babc8116a41bfb10e2;
nameReg.call("register", "MyName");
nameReg.call(bytes4(sha3("fun(uint256)")), a);
nameReg.call(bytes4(keccak256("fun(uint256)")), a);
``call`` returns a boolean indicating whether the invoked function terminated (``true``) or caused an EVM exception (``false``). It is not possible to access the actual data returned (for this we would need to know the encoding and size in advance).
@ -610,7 +610,7 @@ can actually be any type, including mappings.
Mappings can be seen as hashtables which are virtually initialized such that
every possible key exists and is mapped to a value whose byte-representation is
all zeros: a type's :ref:`default value <default-value>`. The similarity ends here, though: The key data is not actually stored
in a mapping, only its ``sha3`` hash used to look up the value.
in a mapping, only its ``keccak256`` hash used to look up the value.
Because of this, mappings do not have a length or a concept of a key or value being "set".

View File

@ -79,7 +79,7 @@ Block and Transaction Properties
You can only access the hashes of the most recent 256 blocks, all other
values will be zero.
.. index:: sha3, ripemd160, sha256, ecrecover, addmod, mulmod, cryptography, this, super, selfdestruct, balance, send
.. index:: keccak256, ripemd160, sha256, ecrecover, addmod, mulmod, cryptography, this, super, selfdestruct, balance, send
Mathematical and Cryptographic Functions
----------------------------------------
@ -88,8 +88,10 @@ Mathematical and Cryptographic Functions
compute ``(x + y) % k`` where the addition is performed with arbitrary precision and does not wrap around at ``2**256``.
``mulmod(uint x, uint y, uint k) returns (uint)``:
compute ``(x * y) % k`` where the multiplication is performed with arbitrary precision and does not wrap around at ``2**256``.
``keccak256(...) returns (bytes32)``:
compute the Ethereum-SHA-3 (Keccak-256) hash of the (tightly packed) arguments
``sha3(...) returns (bytes32)``:
compute the Ethereum-SHA-3 (KECCAK-256) hash of the (tightly packed) arguments
alias to `keccak256()`
``sha256(...) returns (bytes32)``:
compute the SHA-256 hash of the (tightly packed) arguments
``ripemd160(...) returns (bytes20)``:
@ -100,18 +102,18 @@ Mathematical and Cryptographic Functions
In the above, "tightly packed" means that the arguments are concatenated without padding.
This means that the following are all identical::
sha3("ab", "c")
sha3("abc")
sha3(0x616263)
sha3(6382179)
sha3(97, 98, 99)
keccak256("ab", "c")
keccak256("abc")
keccak256(0x616263)
keccak256(6382179)
keccak256(97, 98, 99)
If padding is needed, explicit type conversions can be used: ``sha3("\x00\x12")`` is the
same as ``sha3(uint16(0x12))``.
If padding is needed, explicit type conversions can be used: ``keccak256("\x00\x12")`` is the
same as ``keccak256(uint16(0x12))``.
Note that constants will be packed using the minimum number of bytes required to store them.
This means that, for example, ``sha3(0) == sha3(uint8(0))`` and
``sha3(0x12345678) == sha3(uint32(0x12345678))``.
This means that, for example, ``keccak256(0) == keccak256(uint8(0))`` and
``keccak256(0x12345678) == keccak256(uint32(0x12345678))``.
It might be that you run into Out-of-Gas for ``sha256``, ``ripemd160`` or ``ecrecover`` on a *private blockchain*. The reason for this is that those are implemented as so-called precompiled contracts and these contracts only really exist after they received the first message (although their contract code is hardcoded). Messages to non-existing contracts are more expensive and thus the execution runs into an Out-of-Gas error. A workaround for this problem is to first send e.g. 1 Wei to each of the contracts before you use them in your actual contracts. This is not an issue on the official or test net.

View File

@ -48,6 +48,8 @@ m_magicVariables(vector<shared_ptr<MagicVariableDeclaration const>>{make_shared<
make_shared<FunctionType>(strings{"uint256", "uint256", "uint256"}, strings{"uint256"}, FunctionType::Location::MulMod)),
make_shared<MagicVariableDeclaration>("sha3",
make_shared<FunctionType>(strings(), strings{"bytes32"}, FunctionType::Location::SHA3, true)),
make_shared<MagicVariableDeclaration>("keccak256",
make_shared<FunctionType>(strings(), strings{"bytes32"}, FunctionType::Location::SHA3, true)),
make_shared<MagicVariableDeclaration>("log0",
make_shared<FunctionType>(strings{"bytes32"}, strings{}, FunctionType::Location::Log0)),
make_shared<MagicVariableDeclaration>("log1",

View File

@ -2872,6 +2872,24 @@ BOOST_AUTO_TEST_CASE(iterated_sha3_with_bytes)
));
}
BOOST_AUTO_TEST_CASE(keccak256_multiple_arguments)
{
char const* sourceCode = R"(
contract c {
function foo(uint a, uint b, uint c) returns (bytes32 d)
{
d = keccak256(a, b, c);
}
})";
compileAndRun(sourceCode);
BOOST_CHECK(callContractFunction("foo(uint256,uint256,uint256)", 10, 12, 13) == encodeArgs(
dev::sha3(
toBigEndian(u256(10)) +
toBigEndian(u256(12)) +
toBigEndian(u256(13)))));
}
BOOST_AUTO_TEST_CASE(generic_call)
{
char const* sourceCode = R"**(