AIP: 11 Title: Upgrade of Transaction Protocol Authors: François-Xavier Thoorens firstname.lastname@example.org, dafty Status: Draft Type: Standards Track Created: 2017-09-25 Last Update: 2019-05-07
In order to move forward with the ARK blockchain for future evolution, the transaction protocol needs to be upgraded. Comment thread: https://github.com/ArkEcosystem/AIPs/issues/11
The current status of protocol has several limitations that prevent from future development of services as envisioned on the roadmap:
- impossibility to have cost efficient deserialisation, preventing from scalability of the network
retention-replayattack: a third party can prevent transaction from hitting blockchain inducing the transaction author to create a new transaction. However the transaction is still valid and could be included in the blockchain whenever in the future
- impossible to upgrade transactions without hard fork / no support for private transactions
- impossible to scale fees following the market price
- Fast serialisation and deserialisation
- Lay groundwork for future upgrade without the need of a fork
- Able to validate custom private transactions
- Prevent “retention-replay” attack scheme
All numeric values are stored in unsigned little-endian form.
The preferred signature scheme will be Schnorr. Schnorr signatures are fixed 64 bytes long while ECDSA signatures vary between 70-72 bytes. The latter will still be supported just fine, although discouraged.
General form (total header size excluding vendorfield: 53 bytes)
|sender public key||33||0x025f81956d5826bad7d30daed2b5c8c98e72046c1ec8323da336445476183fb7ca|
|asset||variable||see details below|
Version 0x01 is used for the legacy v1 signature format. Starting at 0x02 all transactions are going to follow the new signature format. Additionally, the transaction timestamp is going to be replaced by a nonce.
The asset is defined according to the type of the transaction. This may be changed with a version change in the future.
Type 0 (transfer, 33bytes)
|expiration||4||0x04000000 (0x00000000 = no expiration)|
Expiration is the blockchain height at or after which the transaction cannot be included in a block. In other words, if the block height is equal or bigger than the transaction expiration, the transaction is invalid.
Type 1 (second signature registration, 33 bytes)
|public key of second signature||33||0x025f81956d5826bad7d30daed2b5c8c98e72046c1ec8323da336445476183fb7ca|
Type 2 (delegate registration, 1 + 3-20 bytes)
|length||1||0x10 (minimum 0x03, maximum 0x14)|
Type 3 (vote, 34 bytes)
Vote consists of:
- Vote flag (0x01 if vote, 0x00 if unvote)
- Public key of the delegate
Type 4 (multisignature registration, 1 + 33N bytes)
|min participants||1||0x02 (minimum 0x01, maximum 0x10)|
Public keys is the concatenation of the public key of all participants of the multi signature wallet.
Limited to a maximum of 16 participants for now.
Also see AIP18
Type 5 (IPFS, 0-255 bytes)
Type 6 (timelock transfer 34 bytes)
|timelock type||1||0x00 (block height)|
Timelock type defines different types for
timelock value field (current supported types are
0:for block height timelock value). If timelock type=0, timelock value shall be specified in block height.
Type 7 (multipayment, 2-65546 bytes)
- N > 1 (ideally fees should be higher than type 0 if N < 2)
- Maximum of possible payments per transaction: 2^16 / 29 or 2259. Initially capped via milestone.
Type 8 (delegate resignation)
The sender must be a delegate. Once forged the delegate is irreversibly deactivated:
- no longer possible to vote for this delegate
- no longer treated as an active delegates, regardless of vote balance
Dynamic Fees calculation
see AIP-16 for more detailed information.
A new process will be used where the fee is related to:
- Type of the transaction
- Size of the serialised transaction
The calculation formula is
Fee = (T+S) * C
- T: minimum offset byte depending on transaction type, defined by the network (byte)
- S: size of the serialised transaction (byte)
- C: constant (Ark/byte) defined by the delegate including the transaction in his forged block
For instance, for transfer we could have T = 0 byte, C = 0.0001 Ark/byte. For a classic transfer transaction with empty VendorField S = 80 bytes, hence the fee is 0.008 Ark.
For a vote we could have T = 100 bytes, C=0.0001 Ark/byte, S = 82 bytes, fee = 0.0182 Ark
T is here to account for extra processing power to process special transaction whose transfer value is null, and thus reducing economic interest to spam the network.