There are two types of Penta accounts: common user or just user, and contract accounts. External accounts fall into the common user account category, while contract accounts are utilised for smart contract information storage. Together they are core elements of the Penta data model.
In Bitcoin nomenclature addresses, like bank account numbers, are where to deposit bitcoins (BTC). In the Penta data model these are instead referred to as accounts. Ownership of Penta accounts is either on an individual or group basis, and only account holders can transact on the Penta blockchain. Accounts are the fundamental machinery DApp users connect to the Penta blockchain with, and the basic data structure containing user summary data, like a total account balance.
Among the benefits of the Account-Balance Model are:
Simplified developer (Penta blockchain integration) api usage, reducing the complexity of creating and maintaining a DApp model layer
Streamlined transaction processing. Basically, only validation of the payer account balance is needed to authorize a transaction, without a computationally intensive review of prior transactions on the chain.
The Penta account model has a number of requirements, a few of which are:
Be fully compatible with the Penta Dynamic Stake Consensus (DSC) algorithm, while adding features and greater flexibility to the usage of each account
Distinguish between user and contract accounts in clearly demarked ways
Minimize computational requirements by storing some user state information with the account data
What follows are the specification details for Penta user and contract accounts.
The Penta user account is also referred to as the common user account. Every one stores four private keys: OwnerKey, TxKey, ConsensusKey and SeedKey. And each of these keys has a specific function, different from the others, as detailed here:
OwnerKey: used to set the transaction, consensus, and seed private key
TxKey: used for transaction signatures
ConsensusKey: signature used in the consensus accounting process
SeedKey: the signature used for the seed generation process in the block proposal process
Generally only the OwnerKey and TxKey are needed for common users of the Penta Network. For nodes participating in the DSC consensus, the ConsensusKey and SeedKey are necessary.
Each Penta account incorporates multiple private keys. For authentication purposes instead of a one-key-one-password policy (of one password) for each private key, a Penta user account sets a single, global owner password for all. Users are required to successfully authenticate with this global password to obtain authorization and control of an account. To facilitate greater security, a secondary password is attached to the core OwnerKey. That is, a second password must be provided before the OwnerKey can be utilized. In this way, user accounts are protected under a two-pass authentication method.
The Penta contract account stores smart contract state information. The account also stores the smart contract code to be executed according to the specified rules encapsulated within the smart contract code.
The Penta Network operates under the guiding principle that anything transacted on the blockchain has an associated cost that must be paid for. Whether a PNT transfer between accounts, or execution of smart contracts, all transactions involve an update to the blockchain and the associated fees paid. The updated data is then always placed into a transaction pool and incorporated in the next generated block.
The Penta account address consists of a 21-byte binary number, in the form of an encoded string (Base58) + 4-byte check digit.
Generating a new Penta account public address is a multi-step process:
An elliptic curve encryption algorithm is used to calculate the uncompressed public key linked (associated with) to a random private key. Its total length is 65 bytes, with a first byte of 0x04 indicating an uncompressed state.
Next, the SHA3–256 hash value of the uncompressed public key is calculated, to produce a 32-byte binary value. The last 20 bytes of this result are taken as the (same) input for both of the next two steps (3,4).
Prefix the 20 bytes of step 2 with 1 byte as an identifier to distinguish between: the primary network, test network, or other adjunct networks. As an example, the 1 byte value for the main network chain is (MainID): 0x37. Use this 21 byte result as the ‘head’ value for step 5.
Calculate a SHA3–256 hash value, again using the 20 byte output of step 2. Take the first 4 bytes of the 32 byte result and use it as the ‘tail’ value for step 5.
Concatenate the 21 byte ‘head’ from step 3, and the 4 byte ‘tail’ of step 4 to generate a 25 byte result as input for step 6.
Perform a Base58 encoding on the concatenated 25 byte address of step 5. This final generated string is a Penta Account Public Address.
The Penta Account Address Field algorithm is different from Ethereum’s. For example, when generating the 20 hash in step 2, Ethereum utilizes the ‘academic’ RIPEMD 160-bit hash scheme, in contrast to NIST backed SHA3–256 algorithm. Another major distinction, different to steps 3–5, Ethereum runs two SHA-256 operations to generate a 25-byte result for final address encoding. The Penta algorithm requires only a single SHA3–256 hash.
This article provides a technical overview of the Penta account structure and address scheme. In its design the Penta team has sought to: simplify development of DApps that integrate with the Penta Network, optimize transaction processing, and clarify the distinction between the functions of common user and contract accounts. The team also recognizes performance of the DSC algorithm, account security, and usability as priorities too. The articles that follow, extend this overview by introducing account management mechanisms, and the account creation process within the Penta ecosystem.
