AIP: 11 Title: Upgrade of Transaction Protocol Authors: François-Xavier Thoorens email@example.com, dafty Status: Draft Type: Standards Track Created: 2017-09-25 Last Update: 2019-09-15
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: 59 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 will follow the new signature format and the transaction timestamp will be replaced by a nonce.
Type & TypeGroup
A monotonically increasing number derived from the sender wallet.
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 (multipayment, 2-1900544 bytes)
- N > 1 (ideally fees should be higher than type 0 if N < 2)
- Maximum of possible payments per transaction: 2^16 or 65536. Initially capped to 500 for performance reasons.
Type 7 (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
Type 8 (htlc lock 66 bytes)
|expirationType||1||0x01(network epoch timestamp), 0x02 (block height)|
Also see AIP102
Type 9 (htlc claim 64 bytes)
Also see AIP102
Type 10 (htlc refund 32 bytes)
Also see AIP102
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.