DAWN-400 ⁃ Transaction Proposal System

[wanderingbort]

Transaction Proposal System

A user, Alice, wishes to propose a transaction that contains actions which require permissions from Alice, Bob, and Charlie in order to process. She proposes the transaction through the Transaction Proposal system, publicly on-chain. Bob and Charlie review the transaction at their convenience and individually contribute their approvals. The transaction is posted to the chain and processes with the permission levels granted by the individuals at the time of approval.

Description

This system is designed to allow multiple parties to co-operate on-chain to authorize a given transaction. While SignedTransaction s can be constructed through side-channels and published to the chain to represent multi-party consent, the process of doing so can be opaque to the point of untenable in certain circumstances. As an alternative, the Proposal system allows parties to conduct that process asynchronous and transparently. Additionally, it allows for a hierarchical set of proposals which can respect a much larger and deeper authorization structure than a single transaction would likely have the capacity to represent within the limits of the chain.

Implementation Details

In order to facilitate hardforks without binary code drops, this will be implemented in WASM however, it will require some privilege not available to normal user contracts. This means there is need for a privileged mode of execution and relates to to #1029 .

• Add eosio.any permission to linkauth which allows any named permission to satisfy the link and assumes contracts will implement additional considerations
• Add wasm API to access the permission names on the action as read only
• Implement proposal endpoints
  • propose which takes a packed transaction and a list of authorizers
  • approve which takes a permission level and must be be authorized by the user at that permission level
• Implement API to check to see if a set of named permissions and public keys can satisfy the stated permission levels on a transaction.
• Add support for privileged contracts to send deferred_transactions with the explicit permission levels instead of the assumed code account's active

[andriantolie]

Verifying the subtask one by one:

• Add eosio.any permission to linkauth which allows any named permission to satisfy the link and assumes contracts will implement additional considerations ( Verified, auth_tests/any_auth unit tests verify that eosio.any permission enable an action to be satisfied by any named permission of an account )
• Add wasm API to access the permission names on the action as read only (Verified with additional unit test in PR Add additional assert to verify permission #2612)
• Implement proposal endpoints
  • propose which takes a packed transaction and a list of authorizers
  • approve which takes a permission level and must be be authorized by the user at that permission level
    ( Verified, multisig_tester unit tests verify that propose and approve action is working )
• Implement API to check to see if a set of named permissions and public keys can satisfy the stated permission levels on a transaction. (Verified, test_permission/check_authorization checks this)
• Add support for privileged contracts to send deferred_transactions with the explicit permission levels instead of the assumed code account's active (Verified, privilege contract can send deferred trx without specifying the active key)

[andriantolie]

Based on the previous comment, all subtasks verified