[ZK Stack] - From and to are uint256?

[alexhooketh]

Module Affected

• System contracts (era-system-contracts)
• Smart contracts (era-contracts)
• zkEVM (era-zk_evm)
• Server (zksync-era)
• Prover (era-boojum)
• Fee withdrawer (era-fee-withdrawer)
• Block Explorer (clock-explorer)
• Portal - Wallet + Bridge (dapp-portal)
• Other (please specify below)

Rust Version

Operating System

• Ubuntu
• MacOS
• Windows
• Other (Please specify below)

Issue Description

It's not an issue. I'm just asking.

https://github.com/matter-labs/era-contracts/blob/f4ae6a1b90e2c269542848ada44de669a5009290/system-contracts/contracts/libraries/TransactionHelper.sol#L28

How come from and to fields are uint256 and not address? Should I cast them as address on comparison, or cast expected address as uint256?

Expected Behavior

Current Behavior

Repository Link (if applicable)

No response

Additional Details

No response

Prior Research

• Yes, I searched for similar issues and did not find any matching ones.

[alhenaai[bot]]

In the context of zkSync transactions, the from and to fields are indeed defined as uint256 values rather than the typical address type, which is essentially uint160 under the hood. This design choice is primarily for forward compatibility, considering potential future changes in address sizes, such as the migration to 32-byte addresses discussed in various Ethereum community proposals.

Here’s how you should handle these fields in your smart contracts or when performing comparisons:

1. Casting for Comparisons: When you need to compare these uint256 fields with actual EVM addresses, you should safely cast the uint256 to uint160. This casting ensures that you are only dealing with valid EVM addresses and not larger values that could potentially be stored in a uint256.

   address expectedAddress = 0x123...; // Example address
   require(address(uint160(transaction.to)) == expectedAddress, "Address does not match");

2. Safety Considerations: It's crucial to ensure that any uint256 values used as addresses are valid EVM addresses. This means they should not exceed the maximum possible value for a uint160 address. You might consider adding checks to ensure that values do not overflow this limit.

3. Smart Contract Implementations: If you are implementing or interacting with smart contracts that use these fields, consider enforcing checks or using utility functions to handle conversions and validations. This approach helps in maintaining robustness, especially when dealing with external inputs.

The decision to use uint256 for address fields in the zkSync context is a strategic one, allowing for greater flexibility and future-proofing as the ecosystem evolves. However, when working with these fields, always ensure that you handle type conversions carefully to maintain the integrity and security of your applications.

Your feedback helps us serve you better. If this fully addresses your question, please give it a thumbs up. If it doesn't, please give it a thumbs down. This will inform the community and team so we can improve our support.

[alexhooketh]

That's what I thought. If it's for forward compatibility, should I do

require(address(uint160(transaction.to)) == expectedAddress)

or

require(transaction.to == uint256(uint160(expectedAddress)))

?

[alhenaai[bot]]

For ensuring compatibility and correctness in your smart contracts, especially when dealing with address comparisons in the context of uint256 fields, you should focus on the direction of casting that maintains the integrity of the data and prevents any potential issues like address truncation or overflow.

Here are the recommended practices for each approach:

1. Casting the transaction.to to an address:

   require(address(uint160(transaction.to)) == expectedAddress, "Address does not match");

   This method involves casting the uint256 transaction.to field down to a uint160, and then to an address. This is safe as it ensures that any value in transaction.to that is larger than what is valid for an address (i.e., larger than 2**160 - 1) will not falsely match an actual EVM address. It effectively checks that the transaction.to field contains a valid address within the EVM's addressable range.

2. Casting the expectedAddress to uint256:

   require(transaction.to == uint256(uint160(expectedAddress)), "Address does not match");

   This approach involves casting the expectedAddress to uint160 first (which it inherently is, so this cast is more about explicitness in code), and then upcasting to uint256. This is also safe and ensures that the comparison is made in the full uint256 space. This method is particularly useful if you expect that the transaction.to might contain values that are valid uint256 representations of addresses, ensuring that no data is lost in the comparison.

Both methods are technically correct and safe, but the choice between them can depend on the specific requirements or expectations within your contract or application:

• If you are certain that the transaction.to will always be within the valid range of EVM addresses, either method works.
• If there is a possibility that transaction.to could contain values outside the typical address range (due to bugs or design choices in other parts of the system), the first method provides an additional safety check by ensuring the value is a valid address before performing the comparison.

In summary, both lines of code achieve the goal of comparing addresses safely under the assumption of correct inputs. The choice depends on your specific contract's logic and the broader system's design considerations.

Your feedback helps us serve you better. If this fully addresses your question, please give it a thumbs up. If it doesn't, please give it a thumbs down. This will inform the community and team so we can improve our support.