|
@@ -39,7 +39,7 @@ Account = record
|
|
end;
|
|
end;
|
|
```
|
|
```
|
|
|
|
|
|
-## DataSize field format
|
|
|
|
|
|
+### DataSize field format
|
|
|
|
|
|
The Account.DataSize is a byte value that denotes the size of the Account.Data array.
|
|
The Account.DataSize is a byte value that denotes the size of the Account.Data array.
|
|
|
|
|
|
@@ -57,7 +57,6 @@ The Account.Data is a byte array that contains the account data. The size of th
|
|
Length(Account.Data) = Account.DataSize
|
|
Length(Account.Data) = Account.DataSize
|
|
```
|
|
```
|
|
|
|
|
|
-
|
|
|
|
### Operation Updates
|
|
### Operation Updates
|
|
|
|
|
|
The following operations will be required for updating:
|
|
The following operations will be required for updating:
|
|
@@ -68,11 +67,11 @@ The following operations will be required for updating:
|
|
|
|
|
|
### Signature & Hashing Updates
|
|
### Signature & Hashing Updates
|
|
|
|
|
|
-Operation signing and signature verification need to be updated to account for Data in impacted operations. Similarly, OPHASH computation needs to account for Account.Data as well. When computing SafeBox Hash, the Account.DataSize and Account.Data need to be similarly included in the hashable digest.
|
|
|
|
|
|
+Operation signing and verification need to include Account Data. Similarly, OPHASH computation needs to include Account.Data as well. When computing the SafeBox Hash, the Account.DataSize and Account.Data need to be similarly included in the hashable digest.
|
|
|
|
|
|
## Rationale
|
|
## Rationale
|
|
|
|
|
|
-This proposal introduces account data in an virtually impact-free manner for both the short-term and long-term. Since only the data itself is necessarily allocated, it means accounts will only grow by 2 byte on PIP activation. Since only a small subset of accounts will ever use this feature, the SafeBox growth is negligible. In the unlikely event that all accounts store full data immediately, the SafeBox would only grow by ~40MB. Long-term, it is possible to easily increase the max-size of the account data by changing a single line of code. This value can be modified in future in accordance with Moore's law which predicts exponential increase in available memory for PascalCoin nodes.
|
|
|
|
|
|
+This proposal introduces Account Data in an virtually impact-free manner. Since account data is only allocated in memory when there is data, each account will only grow by approximately 9 bytes (1 byte data-size, 8 bytes for data pointer). This adds under 10MB to the current SafeBox size. Since only a small subset of accounts will ever use this feature, the SafeBox growth will be negligible. In the unlikely event that all accounts store full data immediately, the SafeBox would only grow by ~50MB. Long-term, there is much room to grow the max Account Data size in accordance with Moore's law which predicts exponentially higher memory for nodes in the future. Changing this requires updating a single line of code.
|
|
|
|
|
|
## Backwards Compatibility
|
|
## Backwards Compatibility
|
|
|
|
|