From ee0b7d5fb250d0e18241a236e365e21e84389936 Mon Sep 17 00:00:00 2001 From: Brooklyn Zelenka Date: Sat, 20 Oct 2018 21:38:27 -0700 Subject: [PATCH] Automatically merged updates to draft EIP(s) 1444 Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing --- EIPS/eip-1444.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-1444.md b/EIPS/eip-1444.md index c67825f2..ac3a05a0 100644 --- a/EIPS/eip-1444.md +++ b/EIPS/eip-1444.md @@ -133,7 +133,7 @@ Text with 2 or more arguments SHOULD use the POSIX parameter field extension. ### `bytes32` Keys -`bytes32` is very efficient since it is the EVM's base word size. Given the enormous number of elements (
|A| > 1.1579 × 1077
), it can embed nearly any practical signal, enum, or state. In cases where an application's key is longer than `bytes32`, hashing that long key can map that value into the correct width. +`bytes32` is very efficient since it is the EVM's base word size. Given the enormous number of elements (card(A) > 1.1579 × 1077), it can embed nearly any practical signal, enum, or state. In cases where an application's key is longer than `bytes32`, hashing that long key can map that value into the correct width. Designs that use datatypes with small widths than `bytes32` (such as `bytes1` in [ERC-1066](https://eips.ethereum.org/EIPS/eip-1066)) can be directly embedded into the larger width. This is a trivial one-to-one mapping of the smaller set into the the larger one.