EDS calculation
EDS calculation is based on the same principles as in EON 1 ([TestNet3 - EON Peer API / Transaction signature], but the Bencode string is not converted to uppercase):
    1.
    Forming a dictionary with the data to be signed.
    2.
    Forming a Bencode string from the dictionary.
    3.
    Bytes are taken in UTF-8 coding.
    4.
    Signing received bytes with the private key.
    5.
    The obtained signature is inserted into the appropriate field.

For transaction

The following fields are used to form the dictionary (similar to the transaction structure):
    version : long
    timestamp : long
    deadline : long
    publisher : String
    fee : long
    tags : map<string> (optional field)
    commands : list<map> (commands are formed as for signature)
Example (JSON):
1
{
2
"commands": [
3
{
4
"data": {
5
"alg": "ed25519",
6
"id": "EON-27Z6X-N77SJ-B8GEM",
7
"key": "9zUema0KRJFkx2mC4HjEZZ0xCH0MMAdGH34rXfz2p4o="
8
},
9
"deadline": 300,
10
"network": "core.dev.Ti2YGY",
11
"publisher": "EON-HRAEQ-8NZL7-C9LHJ",
12
"timestamp": 1592296782,
13
"type": "core.auth.pk.new",
14
"version": 1
15
}
16
],
17
"deadline": 300,
18
"fee": 1000,
19
"publisher": "EON-HRAEQ-8NZL7-C9LHJ",
20
"timestamp": 1592296782,
21
"version": 1
22
}
Copied!

For command

The following fields are used to form the dictionary (similar to the command structure):
    version : long
    network : String
    timestamp : long
    deadline : long
    publisher : String
    type : String
    data : map
    reference : string (optional field)
    note : string (optional field)
Example (JSON):
1
{
2
"data": {
3
"alg": "ed25519",
4
"id": "EON-27Z6X-N77SJ-B8GEM",
5
"key": "9zUema0KRJFkx2mC4HjEZZ0xCH0MMAdGH34rXfz2p4o="
6
},
7
"deadline": 300,
8
"network": "core.dev.Ti2YGY",
9
"publisher": "EON-HRAEQ-8NZL7-C9LHJ",
10
"timestamp": 1592296782,
11
"type": "core.auth.pk.new",
12
"version": 1
13
}
Copied!

Signing transactions and commands

The transaction is signed by the account specified in the publisher field. Each type of command has its own rules for determining who should sign it (if the command requires a signature at all).
Commands and transactions are signed according to the multisignature settings. I.e., if multisignature is enabled, then it should be signed by the accounts specified in the multisignature. The accounts sign the commands and transactions according to their multisignature settings if they are enabled (except when an account includes itself in the multisignature setting, in which case the account's EDS is required).
For example:
    The `A' account issues the transaction. It must be signed.
    If account A has set the accounts B and C in the multisignature, then the signatures of accounts B and C are expected in the transaction (taking into account their multisignature settings).
    If account B has set multisignature to account C, then only account C is expected to sign in the transaction (taking into account its multisignature settings).
    If account C has set multisignature to accounts C and D, then the signatures of accounts C and D are expected in the transaction (EDS forC and for D, taking into account the multisignature settings).
    If account D has not set multisignature, then the transaction must have two EDS: one from account C and one from accountD.
Last modified 6mo ago