Wallet 5 revision 2 - features and optimisations

[Skydev0h]

This pull request contains a pack of new features and improvements to enhance Wallet 5, make it safer, and optimise, as possible.

Optimisations

A magnitude of optimisations including those from feature/optimisation branch are included, that decrease gas usage, in total, by about 25 - 30% depending on the situation. There are further optimisations on logic of the code, that were not implemented in that branch, but were found afterwards, but most of the branch optimisations are covered in Improvements.rst file.

The root cell repacker ("radical" optimisation) was not implemented in order to maintain highest safety and integrity of the code and to avoid opaque and complex fift tricks in important production wallet contracts.

Features and safety

There are several new features implemented in this revision of the contract to further increase safety and flexibility of the contract.

• The action list is now checked to make sure that only send_msg (0ec3c86d) simple actions are allowed. The reasoning behind this change is make the contract safer by disallowing all other actions, including, most prominently, set_code action, that might, if misused, completely break the contract and make all owned assets inaccessible. Moreover, this change makes the wallet future-proof, because if any other, potentially unsafe, actions will be introduced into the blockchain in the future, they are not allowed by default, thus staying safe for the users.

• The set_data (1ff8ea0b) extended action was removed from code for the same reasons as above, because misuse of this action may easily break contract, or cause security issues. Reasonably, this action is most useful with combination of set_code that was also disabled for security reasons, and therefore, there are much less possible valid reasons of using such actions.

Overall, the above changes increase the security of the contract by making it impossible to change the code or data of the contract, that may very easily cause serious consequences to the integrity and security of the contract.

• The send modes of outgoing messages in action list are checked so that the flag 2 (ignore errors) in outgoing actions is set, because, otherwise, unexpected situations may happen if action phase fails in some situations. Therefore, it is mandatory to use flag 2 in all outgoing messages.

• Internally operation codes for signing internal and external messages are now different to prevent a very specific relaying attack, that might, in theory, undermine one of the advantages of the smart contract - making it possible for third party to pay for the gas without compromising any sensitive data.

• Because of the previous point, signature scheme is changed to be quite unusual, that is the signature now comes after the data (instead of the usual before layout), and includes the operation code.

The changes above increase security of user and the contract by preventing some possible issues, that might happen if previous layout and mechanics were used.

• The ability to disallow signature authentication was introduced, that allows any authenticated entity (owner of the account using signed message or an extension) to allow or disallow usage of public key for authentication. Internally this is implemented by extending UInt32 seq_no to Int33, and setting it to a negative value, when signature authentication is disallowed, thus making it impossible to use private key for authentication, because it is not possible to provide a negative seq_no since it is read as UInt32, therefore rendering private key unusable. To prevent accidentally turning the wallet into electronic paperweight by disallowing signature authentication it is not possible to do this when there are no extensions installed, since only they will be able to do anything with the wallet after private key is disabled.

The aforementioned feature may be useful for two-factor authentication schemes and account recovery, please see Why it can be useful to disallow authentication with signature? in Specification.md for a more detailed explanation of possible use cases.

Tests and documentation

All changes and new features are thoroughly tested by new added tests, that test both positive and negative cases to ensure the correctness of the code logic.

The documentation and TLB schemes were updated accordingly to reflect changes in the code.