[EOSIO/eos] Transaction signatures should be on digest that commits to the context free data (#1848)

Transaction signatures are currently not committed to the context free data. This allows an attacker to modify the context free data of a signed transaction in an attempt to make the context-free action validation potentially take a long time (and/or be unnecessarily large), penalizing the honest signer(s) either through the system charging them for a larger cpu (and/or net) bandwidth if the transaction still validates or by appearing to be malicious to network nodes according to their own subjective soft consensus rules.

So, a transaction signature should be on a digest that commits not only to the digest of the unsigned transaction (the transaction id) and the chain id, but also to the hash of the context free data. A verifier would calculate the transaction id and also the hash of the context free data, then use those two hashes as well as the chain id to calculate the actual digest from which the signatures could be used to recover the public keys.

Well after being included in the blockchain, the context free data would eventually be pruned, and without that data (or at least a hash of it) it would not be possible to validate the signatures / recover the public keys from the signatures. However, at that point in time it is also not necessary to validate the signatures, and the signatures themselves could also be pruned.

We do not want the transaction signatures to commit to the public keys that must be involved in the transaction signing. This means an attacker could modify a signed transaction to make it invalid either by removing some, but not all (since the attacker is still trying to penalize at least one honest signer), signatures or by adding unnecessary signatures . In this case, since the transaction would become invalid, the remaining accounts that did have signatures on the invalid transaction would not be charged for the cpu/net bandwidth. They could potentially still be effected by the soft consensus DDOS protection rules of network nodes, but that depends on how those nodes implement their rules. Nevertheless, our current thinking is that we do not want the signatures to commit to the public keys that must be used to sign the transaction because that reduces the flexibility of and complicates the transaction signing process.

Protecting against attackers spamming the network, whether by removing/adding signatures on otherwise valid transactions signed by other users or just by crafting their own invalid transaction, should be protected at the network level by the soft consensus rules. These rules can include disconnecting from nodes that have consistently sent many transactions that are not valid.

Another important point regarding the network soft consensus rules that is worth noting is that the tracking of which transactions are invalid (to avoid spending additional computing resources to validate/process them) should be based on a digest of the signed transaction (which includes the context free data and the signatures) and not on the digest of the unsigned transaction (i.e. the transaction id). This is in order to protect honest users in the following attack scenario: an attacker modifies an otherwise valid signed transaction by some honest user to make it invalid and then immediately broadcasts it to the network in an attempt to beat the honest user’s broadcast; if the network nodes tracked invalid transactions by transaction id, then when they later received the honest user’s valid transaction they would immediately (and unfairly) dismiss it, but by tracking invalid transactions by the signed transaction digest they would consider the honest user’s transaction to be a transaction (that they should spend computing resources to validate/process) separate from the attacker’s manipulated transaction that they already know to be invalid. To prevent DDOS attacks, they would again rely on the other soft consensus rules that would, for example, disconnect from nodes that are regularly providing them with invalid transactions.

Добавить комментарий