actor:actionpair there is at most one explicit associated minimum permission. If there are no explicit minimum permissions set, the implicit default is
[email protected]. Each actor can independently set their personal minimum permission for a given action. Also, a complex but flexible authorization structure is in place within the EOSIO software to allow actors to push actions on behalf of other accounts. Thus, further checks are enforced to authorize an actor to send an action (see 3.4.2. Permission Check).
eosio::contract. Actions are implemented as C++ methods within the derived class. Transactions, on the other hand, are generated dynamically (as transaction instances) within an EOSIO application. The EOSIO software processes each transaction instance within a block and keeps track of its state as it evolves from creation, signing, validation, and execution.
signed_transactionschema below). A transaction is not ready for execution and validation unless it is signed by the applicable actors.
packed_transactionschema below). A packed transaction forms the most generic type of transaction in an EOSIO blockchain. Consequently, when transactions are pushed to a block, they are actually packed transactions whether compressed or not.
unpacked_trxfield holds the cached unpacked transaction after the transaction instance is constructed. If the signed transaction was previously compressed, it is decompressed from the
packed_trxfield and cached to
unpacked_trx. If the signed transaction was stored uncompressed, it is simply copied verbatim to
signaturesfield allows a quick signature validatio of the transaction without requiring a full decompression of the transaction.
actor:permissionpairs specified in all the actions enclosed within the transaction. This linkage is done through the authority table for the given permission (see Accounts and Permissions: 3. Permissions). The actual signing key is obtained by querying the wallet associated with the signing account on the client where the application is run.
actor:permissionis checked against the associated minimum permission required for that
actor:contract::actionpair to see if it meets or exceeds that minimum. This last check is performed at the action level before any action is executed (see 3.4.2. Permission Check).
actor:contract::actionpair specified in the smart contract.
actor:contract::actionpair in the smart contract, the transaction fails. The reason why action permissions are checked before any action is executed is due to performance. It is more efficient to cancel a transaction with all actions unexecuted, than doing so after a few actions executed, but later were rolled back as a result of a failed action or authorization. Any state changes incurred during a failed action must be undone to preserve data integrity. Database sessions are expensive in terms of memory usage and computing resources. Therefore, undo operations must be minimized as possible.
fromparameter and the receiving account in the
statusfield is an 8-bit enumeration type that can hold one of the following results:
executed- transaction succeeded, no error handler executed.
soft_fail- transaction failed, error handler succeeded.
hard_fail- transaction failed, error handler failed.
delayed- transaction scheduled for future execution.
expired- transaction expired, CPU/NET refunded to user.
trxfield holds the transaction ID or the packed transaction itself. The actual choice depends on the transaction type. Receipts generated from Deferred Transactions and Delayed User Transactions are stored by transaction ID; all other types are stored as packed transactions.
action_mrootfields in the block header. Therefore, if a recorded transaction is tampered within a block, not only the merkle tree root hashes would cause a mismatch, but also the transaction signature(s) would fail to validate. If the tampering was not performed by a bona-fide block producer, the block signature would fail to validate as well (see Consensus Protocol: 5.3. Block Validation).