Bitwise Operations

The AND operator compares each bit of two numbers and returns 1 only if both corresponding bits are 1. It is commonly used for bitmasking to check or clear specific bits.

• Example: 5 & 3 (binary 0101 & 0011) results in 1 (0001).
• Use Case: Checking if a specific flag is set in a packed storage variable, or extracting a subset of bits from a larger integer.

The OR operator compares each bit of two numbers and returns 1 if at least one of the corresponding bits is 1. It is used to combine or set specific bits.

• Example: 5 | 3 (binary 0101 | 0011) results in 7 (0111).
• Use Case: Setting permissions or flags within a single storage slot by turning on specific bits without affecting others.

The exclusive OR (XOR) operator returns 1 only if the corresponding bits of two numbers are different. A key property is that applying XOR twice with the same value returns the original number (a ^ b ^ b = a).

• Example: 5 ^ 3 (binary 0101 ^ 0011) results in 6 (0110).
• Use Case: Simple symmetric encryption, toggling bits, or finding a unique element in a duplicate array.

The NOT operator is a unary operator that inverts all bits of a single number, turning every 1 to 0 and every 0 to 1. This is also known as the bitwise complement.

• Example: In an 8-bit system, ~5 (binary ~00000101) results in 250 (11111010).
• Use Case: Creating masks to invert a set of flags or in conjunction with AND to clear bits (x & ~mask).

The left shift operator (<<) moves all bits of a number to the left by a specified number of positions, filling the vacated bits with 0. This is equivalent to multiplying by powers of two.

• Example: 5 << 1 (binary 0101 << 1) results in 10 (1010). 5 << 2 results in 20.
• Use Case: Efficiently multiplying by 2^n, or positioning a value within a specific bit range for storage packing.

The right shift operator (>>) moves all bits of a number to the right by a specified number of positions. For unsigned integers, vacated bits are filled with 0. For signed integers, behavior varies by language. This is equivalent to integer division by powers of two.

• Example: 20 >> 2 (binary 10100 >> 2) results in 5 (00101).
• Use Case: Efficiently dividing by 2^n, or extracting a value from a specific position within a packed storage slot.

A primary use case is storing multiple boolean flags or small integers within a single uint256 variable to drastically reduce storage costs. Each bit represents a distinct on/off state. For example, a user's permissions (canTrade, canWithdraw, isFrozen) can be packed into one slot, saving thousands in gas compared to separate bool variables.

• Mechanism: Use bitwise OR (|) to set bits and bitwise AND (&) with a mask to check them.
• Example: permissions = permissions | (1 << 2); sets the 3rd bit (index 2). (permissions & (1 << 2)) != 0 checks if it's set.

Bitwise operations create compact and gas-efficient role-based access control (RBAC) systems. Instead of multiple mappings, a single uint256 can represent up to 256 unique roles for an address, where each bit corresponds to a specific permission.

• Standard: Inspired by Unix file permissions and systems like OpenZeppelin's AccessControl.
• Operations: grantRole: roles |= 1 << roleId. hasRole: (roles & (1 << roleId)) != 0. revokeRole: roles &= ~(1 << roleId).
• Advantage: Checking and modifying roles requires minimal computation and no storage reads/writes for individual roles.

To optimize transaction costs, contracts can pack multiple function arguments into a single calldata word. Bitwise operations are then used to unpack them within the contract's function logic.

• Use Case: Common in advanced DeFi protocols and NFT minting to batch parameters (e.g., multiple token IDs, prices, and traits).
• Process: The caller packs data using shifts (<<) and OR (|). The contract uses right shifts (>>) and AND (&) with a bitmask to extract each value.
• Benefit: Reduces calldata size, a major component of transaction gas costs on Ethereum.

For NFTs or enumerable tokens, tracking which IDs are minted or claimed using a simple mapping(uint256 => bool) is expensive. A bitmap uses an array of uint256, where each bit tracks the status of a sequential ID.

• Efficiency: One uint256 tracks 256 IDs. Setting or checking a bit costs a fraction of a storage slot write.
• Implementation: uint256 index = tokenId / 256; uint256 bitPosition = tokenId % 256;. To mint: bitmap[index] |= (1 << bitPosition);.
• Adoption: Used extensively in standards like ERC721A and Merkle airdrop claims to batch mint efficiently.

Bitwise logic enables certain arithmetic and comparison operations that are more efficient than their high-level counterparts, which is critical for gas optimization in complex contract logic.

• Fast Division/Multiplication by Powers of Two: x >> 2 is equivalent to x / 4. x << 3 is equivalent to x * 8.
• Checking for Even/Odd: (x & 1) == 0 checks if a number is even.
• Swapping Values: Can be done without a temporary variable using XOR: a ^= b; b ^= a; a ^= b;.
• Underflow Checks: Used in custom math libraries for precise bit-level control.

Smart contracts often model state transitions (e.g., auction phases, loan states). Using bits to represent states allows for compact, bitmask-based validation of allowed transitions and the combination of multiple states.

• Example: An auction could have states: None(0), Created(1 << 0), Started(1 << 1), Ended(1 << 2). A contract can be in multiple valid sub-states (e.g., Created | Started).
• Validation: Check transition validity with bitwise logic: require(allowedTransitions[oldState] & newState != 0);.
• Advantage: Extremely lightweight representation and validation of complex business logic flows.

Bitwise operations like & (AND), | (OR), ~ (NOT), ^ (XOR), and <</>> (shifts) map directly to single EVM opcodes (e.g., AND, OR, XOR, NOT, SHL, SHR). This is more efficient than Solidity-level arithmetic, which may compile to multiple opcodes. For example, checking if a number is even with x & 1 == 0 is cheaper than x % 2 == 0.

A primary use case is bit packing, where multiple small integers or booleans are stored in a single uint256 variable. This drastically reduces SSTORE and SLOAD gas costs by minimizing storage slots used.

• Example: Packing a uint8, uint16, and address into one 256-bit slot.
• Mechanics: Values are placed using shifts (<<) and combined with OR (|), then extracted using AND (&) with a bitmask and a reverse shift.

Bitwise operations enable gas-efficient management of multiple boolean flags or permissions within a single storage variable.

• Use Case: User roles, feature toggles, or status flags.
• Method: Each bit represents a distinct flag. Use | to set a bit, & with a mask to check it, and & with the bitwise complement of a mask to clear it. This avoids the gas overhead of multiple bool mappings or separate storage variables.

The gas savings are measurable. Key comparisons:

• Storage: One SSTORE for a packed 256-bit slot vs. multiple SSTOREs for individual variables.
• Computation: a / 256 (expensive division) vs. a >> 8 (cheap shift).
• Checking Flags: A bitmask check (flags & 0x01 != 0) is cheaper than accessing a mapping(address => bool). These optimizations are critical for functions called repeatedly or in high-throughput DeFi contracts.

Effective bitwise usage relies on standard patterns:

• Creating a Mask: uint256 mask = 1 << bitPosition;
• Setting a Bit: packedData = packedData | mask;
• Clearing a Bit: packedData = packedData & ~mask;
• Checking a Bit: if ((packedData & mask) != 0) { ... }
• Extracting a Field: uint8 field = uint8((packedData >> offset) & 0xFF); Mastering these patterns is essential for low-gas contract design.

While powerful, bitwise operations require careful implementation:

• Readability: Overuse can make code harder to audit. Use comments and helper libraries (like OpenZeppelin's BitMaps).
• Overflow/Underflow: Shifting beyond 256 bits will overflow. Use SafeCast libraries for shifts.
• Gas Trade-offs: The optimization is most valuable for state variables in storage. The benefit for in-memory (memory) calculations is smaller. Always profile gas usage.

The most common pitfall when using bitwise shifts (<<, >>). Shifting bits beyond the width of the data type (e.g., a 256-bit integer) discards the overflow, leading to silent, incorrect calculations. This can break tokenomics, rewards, or voting logic.

• Example: uint8 x = 255; // binary 11111111 x << 2; // Result is 11111100, which is 252, not 1020.
• Mitigation: Use Solidity 0.8.x's built-in overflow checks or libraries like SafeMath for arithmetic; for bitwise ops, explicitly check shift amounts.

Using bitwise AND (&) and OR (|) to manage permissions is efficient but error-prone. A single incorrect mask or bit position can grant excessive privileges or lock out legitimate users.

• Critical Risk: A flawed require(userPermissions & ADMIN_ROLE > 0) check might pass for non-admin users if the bitmask logic is inverted.
• Best Practice: Use well-audited, standard libraries (like OpenZeppelin's AccessControl) for complex permission systems instead of manual bit fiddling.

While bitwise operations are extremely gas-efficient for packing data and flags into a single storage slot, they severely reduce code readability and auditability. Obfuscated logic is a security risk.

• Trade-off: Packing eight bool states into one uint256 saves ~20k gas in storage but makes state transitions hard to trace.
• Rule: Use bitwise packing only for well-documented, immutable logic (like constant flag sets) and after thorough testing.

In signature recovery (e.g., ECDSA) or Merkle proof verification, bitwise operations are used to parse v, r, s components. Incorrect bit masking can lead to accepting invalid signatures or replay attacks.

• Example: uint8 v = uint8(ethSignature[64]) + 27; requires precise byte extraction.
• Vulnerability: Failing to properly mask the v value (e.g., not using & 0xff) can result in incorrect chain ID separation (EIP-155).

Bitwise logic has non-intuitive edge cases that unit tests must exhaustively cover. Standard arithmetic tests are insufficient.

• Essential Tests: Zero shifts, shifts equal to bit width, all-bits-set (type(uint256).max) values, and negative numbers (if using int types).
• Tooling: Use property-based testing (e.g., with Foundry's ffi and differential fuzzing) to compare bitwise results against a reference implementation.

Bitwise operation behavior can differ between the EVM version, the compiler (Solidity, Vyper), and even testing frameworks. The SAR (signed right shift) opcode, for instance, handles negative numbers with arithmetic shift.

• Risk: Code tested on one EVM version (e.g., Shanghai) may behave differently on another or a fork like Arbitrum.
• Action: Explicitly document assumed behaviors and include EVM version pragmas (pragma evm-version).

A bitmask is a sequence of bits used to selectively enable, disable, or check the status of specific bits within a larger value. It is a core application of bitwise operations.

• Purpose: Used for efficient flag management and permission systems.
• Example: In a smart contract, a single uint256 can store 256 boolean flags (like user permissions) by using a bitmask, where each bit position represents a different permission.
• Operation: The & (AND) operator is used with a mask to check if a specific bit is set.

Bit shifting moves all bits in a binary number left or right by a specified number of positions. It is a fundamental operation for fast multiplication and division by powers of two.

• Left Shift (<<): Adds zeros to the right, effectively multiplying the number by 2^n. Example: 5 << 2 (binary 101 shifted left twice) becomes 20 (binary 10100).
• Right Shift (>>): Discards bits on the right, effectively dividing the number by 2^n (floor division).
• Use Case: Extremely gas-efficient for arithmetic in Ethereum smart contracts compared to the * and / operators.

The bitwise AND operation compares two binary sequences and returns a 1 only in positions where both inputs have a 1. It is primarily used for masking and checking bit states.

• Truth Table: 0 & 0 = 0, 0 & 1 = 0, 1 & 0 = 0, 1 & 1 = 1.
• Common Use:
  • Extracting a specific bit: value & mask isolates the bits defined by the mask.
  • Checking if a bit is set: if ((flags & USER_ROLE_BIT) != 0) { ... }.
• Analogy: A logical filter that only lets through bits that are 'on' in both numbers.

The bitwise OR operation compares two binary sequences and returns a 1 in any position where at least one input has a 1. It is used to combine or set specific bits.

• Truth Table: 0 | 0 = 0, 0 | 1 = 1, 1 | 0 = 1, 1 | 1 = 1.
• Common Use:
  • Combining flags: newFlags = adminFlag | writeFlag creates a permission set with both abilities.
  • Setting a bit: value = value | SET_BIT_MASK ensures a specific bit is turned on.
• Analogy: A logical merger that turns on bits present in either operand.

The bitwise XOR (exclusive OR) operation compares two binary sequences and returns a 1 only in positions where the two input bits are different. It is crucial for cryptography and toggling states.

• Truth Table: 0 ^ 0 = 0, 0 ^ 1 = 1, 1 ^ 0 = 1, 1 ^ 1 = 0.
• Key Properties:
  • Toggling: value ^= MASK flips (inverts) all bits where the mask is 1.
  • Symmetry: A ^ B ^ B = A. This property is used in simple ciphers and error detection.
• Blockchain Use: Foundational for cryptographic hash functions and certain consensus algorithms.

The bitwise NOT (or complement) is a unary operation that inverts every bit in a binary number, turning every 0 to 1 and every 1 to 0. It flips the entire bit pattern.

• Operation: Applied to a single operand. Example: In an 8-bit system, ~00001111 becomes 11110000.
• Use with AND: Often used with AND to clear bits: value & ~mask clears the bits specified by the mask.
• Two's Complement: In signed integer representations, ~x is equivalent to -x - 1, which is important for low-level arithmetic.
• Consideration: The result depends on the data type's bit length (e.g., uint8 vs uint256).