PascalCoin/PIP/PIP-0024.md

  PIP: PIP-0024
  Title: Account Data
  Type: Protocol
  Impact: Hard-Fork
  Author: Herman Schoenfeld <[email protected]>
  Comments-URI: https://discord.gg/sJqcgtD  (channel #pip-0023)
  Status: Active
  Created: 2018-07-23

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 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

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

This change is not backwards compatible and requires a hard-fork activation.