You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The HASHEXT_KECCAK256 implementation in TON differs from the Keccak-256 implementation in the EVM. In TON, the HASHEXT_KECCAK256 does not handle Cell refs, leading to a discrepancy in hash results compared to the EVM, which could potentially cause hash conflicts.
What behavior did you expect?
I expected HASHEXT_KECCAK256 in TON to process Cell refs similarly to the EVM’s Keccak-256 implementation, ensuring consistent hash results across both platforms.
What was the actual behavior?
The current behavior of HASHEXT_KECCAK256 in TON only hashes the Cell data without taking the refs into account, resulting in different hash values compared to the EVM’s Keccak-256 for the same data structure.
How reliably can you reproduce the issue, what are the steps to do so?
(int) keccack256_single(slice _t0) asm "1 PUSHINT HASHEXT_KECCAK256";
int op = in_msg_body~load_uint(32);
if (op == op::keccack256()) { dump(in_msg_bodyload_uint(64));
~dump(in_msg_body);
~dump(keccack256_single(in_msg_body));
}
Describe the issue
The HASHEXT_KECCAK256 implementation in TON differs from the Keccak-256 implementation in the EVM. In TON, the HASHEXT_KECCAK256 does not handle Cell refs, leading to a discrepancy in hash results compared to the EVM, which could potentially cause hash conflicts.
What behavior did you expect?
I expected HASHEXT_KECCAK256 in TON to process Cell refs similarly to the EVM’s Keccak-256 implementation, ensuring consistent hash results across both platforms.
What was the actual behavior?
The current behavior of HASHEXT_KECCAK256 in TON only hashes the Cell data without taking the refs into account, resulting in different hash values compared to the EVM’s Keccak-256 for the same data structure.
How reliably can you reproduce the issue, what are the steps to do so?
(int) keccack256_single(slice _t0) asm "1 PUSHINT HASHEXT_KECCAK256";
int op = in_msg_body~load_uint(32);
if (op == op::keccack256()) {
dump(in_msg_bodyload_uint(64));~dump(in_msg_body);
~dump(keccack256_single(in_msg_body));
}
messageBody1 x{0000006800000000000000000300007DDE0000334B0000000000000000000000008157668EC72C279C20C9D7387B7B711FCF713A4D0000271AEFAB5D355AD91A98BCBACEA3854E0EECB83942801BE6722B9A941317F050E2A668656C6C6F20776F726C642068656C6C6F20776F726C64202168656C6C6F20776F726C642068}
x{656C6C6F20776F726C64202168656C6C6F20776F726C642068656C6C6F20776F726C642021}
Output result1: 112128826363682873612496808615290492480709047111283954187881755354176156987312
messageBody2 x{0000006800000000000000000300007DDE0000334B0000000000000000000000008157668EC72C279C20C9D7387B7B711FCF713A4D0000271AEFAB5D355AD91A98BCBACEA3854E0EECB83942801BE6722B9A941317F050E2A668656C6C6F20776F726C642068656C6C6F20776F726C64202168656C6C6F20776F726C642068}
x{656C6C6F20776F726C64202168656C6C6F20776F726C642068656C6C6F20776F726C64202168656C6C6F20776F726C642068656C6C6F20776F726C64202168656C6C6F20776F726C642068656C6C6F20776F726C642021}
Output result2: 112128826363682873612496808615290492480709047111283954187881755354176156987312
hexToBigInt(
keccak256(
'0x0300007DDE0000334B0000000000000000000000008157668EC72C279C20C9D7387B7B711FCF713A4D0000271AEFAB5D355AD91A98BCBACEA3854E0EECB83942801BE6722B9A941317F050E2A668656C6C6F20776F726C642068656C6C6F20776F726C64202168656C6C6F20776F726C642068' as '0x',
),
)
Output result3: 112128826363682873612496808615290492480709047111283954187881755354176156987312
The text was updated successfully, but these errors were encountered: