|
|
@@ -0,0 +1,79 @@
|
|
|
+<pre>
|
|
|
+ PIP: PIP-0024
|
|
|
+ Title: Account Data
|
|
|
+ Type: Protocol
|
|
|
+ Impact: Hard-Fork
|
|
|
+ Author: Herman Schoenfeld <i><[email protected]></i>
|
|
|
+ Comments-URI: https://discord.gg/sJqcgtD (channel #pip-0023)
|
|
|
+ Status: Proposed
|
|
|
+ Created: 2018-07-23
|
|
|
+</pre>
|
|
|
+
|
|
|
+## Summary
|
|
|
+
|
|
|
+It is proposed to allow PascalCoin Accounts (PASA) to contain a 32byte data field which can be changed by the account owner.
|
|
|
+
|
|
|
+## Motivation
|
|
|
+
|
|
|
+By allowing users to store a data field in their account, a door to many new possible use cases is opened. These include, but are not limited to:
|
|
|
+
|
|
|
+- **Federated databases**: by storing the HASH of a database in an Account, the account owner can serve as an authority of that database without being required to store, propagate or publically identify themselves. The task of distributing the database can be delegated to a separate peer-to-peer network and the account data used by that network to validate the database (simply by comparing the HASH(DATABASE) = Account.Data ). The database can be of any form including a side-chain, an SQL database, a file-system, etc.
|
|
|
+
|
|
|
+- **Decentralised Databases**: Following from Federated Databases, it is possible to have a database without an authority. In this usecase, a Proof-Of-Stake overlay network can serve as an authority over "null accounts". A null account is simply an account with a NULL public key (and optionally a specific type number, such as 65535). Instead of digital signatures being
|
|
|
+required to authorise operations from this account, a STAKE PROOF is used instead. The STAKE PROOF must contain the digital signatures of a Proof-of-Stake (PoS) overlay network conforming to an accepted PoS algorithm (such as DPoS). In this manner, truly decentralised and anonymous databases can be used to power Ethereum-style smart-contracts that scale horizontally and independently of each other. Use cases here include, high-volume high-frequency decentralised exchanges, or a real-world decentralised Uber.
|
|
|
+
|
|
|
+- **Data Storage Networks**: by storing the HASH of an entire file or file-system, it is possible for an account owner (or a PoS network) to "notarise data". The data itself can be distributed via a segregated P2P network (such as BitTorrent). With these relatively minor and simple modifications, it will be possible to deliver the functionality of MAIDSAFE without the extraordinary technical effort such undertakings currently require.
|
|
|
+
|
|
|
+- **Minor use-cases**: account data can also serve as titles for a chat room or topic specific to account types. Example, if account type = 1 then data = string, if account type = 2 then data = URL, if account type = 65535 then data = side-chain-root, etc.
|
|
|
+
|
|
|
+## Specification
|
|
|
+
|
|
|
+Two new fields are to be added to Account record, a DATASIZE byte and DATA byte-array.
|
|
|
+
|
|
|
+```
|
|
|
+Account = record
|
|
|
+ ...
|
|
|
+ DataSize : byte;
|
|
|
+ Data : array of byte;
|
|
|
+ ...
|
|
|
+end;
|
|
|
+```
|
|
|
+
|
|
|
+## DataSize field format
|
|
|
+
|
|
|
+The Account.DataSize is a byte value that denotes the size of the Account.Data array.
|
|
|
+
|
|
|
+The range of values are limited to:
|
|
|
+
|
|
|
+```
|
|
|
+0 <= Account.DataSize <= 32
|
|
|
+```
|
|
|
+
|
|
|
+### Data field format
|
|
|
+
|
|
|
+The Account.Data is a byte array that contains the account data. The size of this array **must be equal to** the Account.DataSize at **every point in time**.
|
|
|
+
|
|
|
+```
|
|
|
+ Length(Account.Data) = Account.DataSize
|
|
|
+```
|
|
|
+
|
|
|
+
|
|
|
+### Operation Updates
|
|
|
+
|
|
|
+The following operations will be required for updating:
|
|
|
+
|
|
|
+- **CHANGE ACCOUNT INFO** an additional field is required to denote the new account data of the account.
|
|
|
+
|
|
|
+- **MULTI OPERATION** an additional field is required to denote the new account data of a **changer** sub-record within the operation.
|
|
|
+
|
|
|
+### 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.
|
|
|
+
|
|
|
+## 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.
|
|
|
+
|
|
|
+## Backwards Compatibility
|
|
|
+
|
|
|
+This change is not backwards compatible and requires a hard-fork activation.
|
Herman Schoenfeld