Update to doc for the new on-chain architecture

modules/ROOT/pages/accounts.adoc

@@ -1,5 +1,5 @@
 = Accounts
-:description: This section explains the different account properties and how these relate to different transaction types.
+:description: This section explains the different account properties and their correspondence to different modules.
 :imagesdir: ../assets/images
 :page-previous: /lisk-protocol/index.html
 :page-previous-title: Introduction
@@ -21,7 +21,7 @@ Verification of the validity of a transaction requires the state of the referenc
 
 == Account properties
 
-This section lists the properties stored in a Lisk account.
+This section lists the properties of a Lisk account. The properties, except the `address` as account identifier,  are organized into four different objects, each corresponding to one of the account schemas defined in the four default modules: `token`, `sequence`, `keys`, and `dpos`.
 
 image::unif_diagrams/Account.png[accountJSON]
 
@@ -38,29 +38,29 @@ For the front end, a xref:{url_appendix_user_friendly_address}[user-friendly add
 
 === `balance`
 
-The balance is an integer value indicating how many tokens are stored in the account and available to be used.
+The balance is an integer value indicating how many tokens are stored in the account and available to be used. It belongs to the `token` object of the account.
 The total number of tokens owned by an account is the sum of the balance and the tokens locked into <<votes,`votes`>> and <<unlocking,`unlocking`>>.
-The balance can be sent from one account to another using a xref:{url_transactions_balance_transfer}[balance transfer transaction].
+The balance can be sent from one account to another using a xref:{url_transactions_balance_transfer}[token transfer transaction].
 
 === `keys`
 
 By default, a transaction issued by an account has to be signed with the private key corresponding to the original public key that generated the account address.
 However, this default configuration can be changed, and issuing a transaction can require signatures by multiple different private keys (and not necessarily the default one).
 The corresponding public keys are stored in the `keys` property.
 These public keys can be either [#index-mandatory-1]#mandatory# or [#index-optional-1]#optional#: All mandatory keys have to sign the transaction, and the total number of signatures (mandatory plus optional) has to be equal to `numberOfSignatures` (also stored in `keys`).
-Users can update the `keys` property with a xref:{url_transactions_multisignature}[multisignature registration transaction], specifying the mandatory and optional keys and the number of required signatures.
+Users can update the `keys` property with a xref:{url_transactions_multisignature}[multisignature group registration transaction], specifying the mandatory and optional keys and the number of required signatures.
 
 === `nonce`
 
-This property stores the current xref:{url_transactions_nonce}[*`nonce`*] of the account.
+This property stores the current xref:{url_transactions_nonce}[*`nonce`*] of the account. It belongs to the `sequence` object of the account.
 Starting from zero, each transaction sent from the account increases the `nonce` value by one.
 Hence the current `nonce` corresponds to the number of transactions sent from the account.
 
-=== `asset`
+=== `dpos`
 
-The account asset contains all extra information that is specific to a transaction or to the blockchain the account belongs to.
+The `dpos` object contains all account properties related to the DPoS protocol.
 
-The following properties are part of an account asset in the default Lisk protocol.
+The following properties are part of the `dpos` object in the default Lisk protocol.
 
 ==== `delegate`
 
@@ -76,5 +76,5 @@ Tokens used for voting are [#index-locked-1]#locked#, and cannot be used (or mov
 [[unlocking]]
 ==== `unlocking`
 
-Tokens used to vote for a delegate are frozen, and have to be unlocked to make them available again. Similarly to the `votes` property, this property stores the voted-delegate's address and the amount, but also the block in which the votes have been removed from the delegate.
-After the appropriate waiting time, the user can then unlock the tokens with an xref:{url_transactions_unlock}[unlock transaction].
+Tokens used to vote for a delegate are locked, and have to be unlocked to make them available again. Similarly to the `votes` property, this property stores the voted-delegate's address and the amount, but also the block in which the votes have been removed from the delegate.
+After the appropriate waiting time, the user can then unlock the tokens with a xref:{url_transactions_unlock}[token unlock transaction].

modules/ROOT/pages/mainnet.adoc

@@ -13,9 +13,9 @@ The native token for the Lisk Mainnet is the *LSK*. Each LSK is further subdivid
 
 == Transactions
 
-The Lisk Mainnet supports one additional transaction.
+Lisk Mainnet additionally contains the `legacyAccount` module which contains the following transaction.
 
-=== Reclaim
+=== LSK Reclaim
 
 This transaction allows to access the balance that was sent to a legacy address without any associated public key.
 Legacy addresses, generated from the first eight bytes of the public key, were used in older versions of the protocol.

modules/ROOT/pages/transactions.adoc

@@ -18,30 +18,32 @@
 :url_transactions_vote: transactions.adoc#vote
 
 In Lisk, the state of accounts is updated by transactions included in a xref:{url_blocks}[block].
-Every account can issue a transaction, with the corresponding signature and data.
-There is a set of different transaction types and each of these types defines a specific logic for modifying accounts depending on the transaction data.
-In the table below, a summary of these transaction types and the purpose each of them serve is shown.
+Every account can issue a transaction, with the corresponding signature and data. There is a set of different transaction and each of these transactions has an specific validation and execution logic. Similar transactions are grouped together into one module. The Lisk protocol contains four default modules, `token`, `sequence`, `keys`, and `dpos`, which contain the six transactions shown in the table below.
 
 |===
-|*Transaction Type*|*Purpose*
-
-|*balance transfer*|Transmit funds to another Lisk account
-|*delegate registration*|Register a delegate for the account
-|*vote*|Submit or remove vote(s) for delegates
-|*unlock vote*|Unlock locked tokens
-|*multisignature*|Register a multisignature in the account
-|*PoM*|Submit a proof-of-misbehavior of a delegate
+|*Transaction*|*Module*|*Purpose*
+
+|*token transfer*|*token*|Transmit funds to another Lisk account
+|*delegate registration*|*dpos*|Register a delegate for the account
+|*delegate vote*|*dpos*|Submit or remove vote(s) for delegates
+|*token unlock*|*dpos*|Unlock locked tokens
+|*multisignature group registration*|*keys*|Register a multisignature group for the account
+|*delegate misbehavior report*|*dpos*|Report a misbehavior of a delegate
 |===
 
 == Transaction properties
 
 image::unif_diagrams/BaseTransaction.png[TxDiagram,width=339,height=310]
 
-Every transaction object in the Lisk protocol, regardless of the type, has a common set of properties. These properties are shown in the subsection below.
+Every transaction object in the Lisk protocol has a common set of properties. These properties are shown in the subsection below.
 
-=== `type`
+=== `moduleID`
 
-An integer identifying the type of the transaction.
+An integer identifying the module the transaction belongs to.
+
+=== `assetID`
+
+An integer identifying the specific asset for the transaction in the module.
 
 [[nonce]]
 === `nonce`
@@ -54,9 +56,9 @@ Once one of the two transactions is included in the blockchain, the other one be
 [[fee]]
 === `fee`
 
-The fee to be spent by the transaction. This fee has to be equal or greater than a minimum value for the transaction to be valid. The minimum value is calculated as the size of the transaction object multiplied by a constant, `minFeePerByte`, given by the protocol. The value of `minFeePerByte` is 1000 (10^-5^ LSK/byte in Lisk Mainnet). Note that for *delegate registration* transactions there is an extra summand of 10^9^ (10 LSK in Lisk Mainnet) added to the minimum fee to account for the name space used by this type of transaction.
+The fee to be spent by the transaction. This fee has to be equal or greater than a minimum value for the transaction to be valid. The minimum value is calculated as the size of the transaction object multiplied by a constant, `minFeePerByte`, given by the protocol. The value of `minFeePerByte` is 1000 (10^-5^ LSK/byte in Lisk Mainnet). Note that for *delegate registration* transactions there is an extra summand of 10^9^ (10 LSK in Lisk Mainnet) added to the minimum fee to account for the name space used by this transaction.
 
-For example, in Lisk Mainnet, for a <<transfer,balance transfer>> transaction with a size of 133 bytes, the minimum fee is 10^-5^ LSK/byte × 133 bytes = 0.00133 LSK.
+For example, in Lisk Mainnet, for a <<transfer,token transfer>> transaction with a size of 133 bytes, the minimum fee is 10^-5^ LSK/byte × 133 bytes = 0.00133 LSK.
 In the case of <<delegate,delegate registration>> transaction with a size of 124 bytes, the minimum fee of the transaction is 10 LSK + 10^-5^ LSK/byte × 124 bytes = 10.00124 LSK.
 
 This required minimum fee paid by every transaction is burned, in other words, it is not assigned to any account balance.
@@ -73,13 +75,12 @@ The `senderPublicKey` is used to compute the address under which the sender acco
 === `asset`
 
 This property contains the data specific to the type of the transaction.
-For each `type` value, there exist a unique `asset` property.
-The section <<types,Transaction types>> describes the different transaction types with respect to the `asset` property of each of them.
+Every pair of values (`moduleID`,`assetID`) must uniquely correspond to one asset schema defined in the respective module. The section <<types,Transactions>> describes the different transaction with respect to the `asset` property of each of them.
 
 === `signatures`
 
 An array with the signatures of the transaction.
-If the account associated to `senderPublicKey` does not have the xref:{url_accounts_keys}[`keys`] property, the object containing the five properties, `type`, `nonce`, `fee`, `senderPublicKey`, and `asset`, has to be signed by the private key corresponding to the `senderPublicKey`.
+If the account associated to `senderPublicKey` does not have the xref:{url_accounts_keys}[`keys`] property, the object containing the six properties, `moduleID`, `assetID`, `nonce`, `fee`, `senderPublicKey`, and `asset`, has to be signed by the private key corresponding to the `senderPublicKey`.
 Otherwise, the signing process has to be repeated for each of the private keys associated with an applicable set of public keys specified in  the `keys` property of the account.
 In the xref:{url_appendix_signature_scheme}[Appendix] section more details about the signing process are given.
 
@@ -91,35 +92,35 @@ The transaction ID is the SHA-256 hash of the serialized transaction.
 
 == Minimum balance
 
-A <<transfer,balance transfer>> transaction must make the balance of the receiving account equal to or greater than 5 × 10^6^ (0.05 LSK in Lisk Mainnet).
+A <<transfer,token transfer>> transaction must make the balance of the receiving account equal to or greater than 5 × 10^6^ (0.05 LSK in Lisk Mainnet).
 Subsequently, any transaction sent from an account is only valid if the resulting balance of the sender account is at least 5 × 10^6^.
 This constraint exists to account for the cost of creating and storing accounts in Lisk.
 
 [[types]]
-== Transaction types
+== Transactions
 
-The 6 transactions types available in the Lisk protocol are listed in the table displayed above.
+The 6 different transactions from the default modules of the Lisk protocol are listed in the table displayed above.
 Each one induces a concrete operation on accounts and is defined by a unique schema and transaction logic.
-The type-specific data is given in the `asset` property previously mentioned.
+The specific data is given in the `asset` property previously mentioned.
 The key points and useful information for each of these transactions are commented in the following subsections.
 
 [[transfer]]
-=== Balance transfer
+=== Token transfer
 
 image::unif_diagrams/BalanceTransferAsset.png[BalanceTDiagram,340,211]
 
-This transaction type transfers the amount of tokens specified in the `amount` property from the xref:{url_accounts}[account] corresponding to the `senderPublicKey`, i.e. the sender account, to the account specified in `recipientAddress`.
+This transaction transfers the amount of tokens specified in the `amount` property from the xref:{url_accounts}[account] corresponding to the `senderPublicKey`, i.e. the sender account, to the account specified in `recipientAddress`.
 This transaction offers the possibility to send a message in the optional property `data`.
 
 [[delegate]]
 === Delegate registration
 
 image::unif_diagrams/DelegateRegAsset.png[DelegateDiagram,332,151]
 
-This transaction registers the sender account as a xref:{url_consensus_voting_and_weight}[delegate] with the name given in `username`.
+This transaction registers the sender account as a xref:{url_consensus_voting_and_weight}[delegate] with the name given in `username`. A valid name contains only characters from the set `[a-z0-9!@$&_.]` and has to be at most 20 characters long.
 
 [[vote]]
-=== Vote
+=== Delegate vote
 
 image::unif_diagrams/VoteAsset.png[VoteDiagram,736,192]
 
@@ -130,7 +131,7 @@ If the amount is negative, it implies that the specified amount of votes are rem
 The maximum number of votes that can be cast in a single transaction is 20 and `amount` has to be a multiple of 10^9^ (10 LSK in Lisk Mainnet).
 
 [[unlock]]
-=== Unlock vote
+=== Token unlock
 
 image::unif_diagrams/UnlockVoteAsset.png[UnlockVoteDiagram,765,202]
 
@@ -140,20 +141,20 @@ For a regular vote the unlocking period is 2000 blocks (around 5 hours).
 For self-votes, i.e. if the `delegateAddress` property of the transaction is equal to the account xref:{url_accounts_address}[address], this period is 260,000 blocks (around 30 days).
 
 [[multisignature]]
-=== Multisignature registration
+=== Multisignature group registration
 
 image::unif_diagrams/MultisigRegAsset.png[MultisigDiagram,375,204]
 
-This transaction registers the sender account as a multisignature account.
+This transaction registers the sender account as a multisignature group account.
 The set of [#index-mandatory-2]#*mandatory*# keys needs to be specified in `mandatoryKeys` whereas the set of [#index-optional-2]#*optional*# keys have to be specified in `optionalKeys`.
 The total number of keys required for every future outgoing transaction from the account is given in `numberOfSignatures`.
 Once this transaction is included in a block, every transaction from this account has to be signed by an applicable set of private keys.
 
 [[pom]]
-=== PoM
+=== Delegate misbehavior report
 
 image::unif_diagrams/PoMAsset.png[PoMDiagram,330,184]
 
-This transaction submits a proof of misbehaviour of a certain delegate.
+This transaction can be utilized to report a misbehavior of a certain delegate.
 It contains the information necessary to prove that the delegate who signed the xref:{url_blocks_header}[block headers] given in `header1` and `header2` has violated the xref:{url_consensus_bft}[Lisk-BFT protocol].
-The xref:{url_consensus_bft_punishment}[Punishment of Lisk-BFT protocol violations] section provides the details regarding implications of this transaction type.
+The xref:{url_consensus_bft_punishment}[Punishment of Lisk-BFT protocol violations] section provides the details regarding the implications of this transaction.