eos INLINE Action 和 eosio.code 使用說明

1、inline action简单来说就是action调用另外一个action, 具体来说就是一个智能合约的代码调用另外一个智能合约的函数。现在的eos（好像是自从dawn 4.0之后），只要在合约中调用另一个合约的action，不管以什么代码格式调用，都自动是inline action。

eosio.code 的解释：

eoiso.code这一特殊权限是dawn4.0后新增的内部特殊权限，用来加强inline action的安全性。比如alice调用智能合约contract1.test，一开始alice看过contract1.test的逻辑，发现它只是一个打印函数，并不会调用其他合约。所以alice以自己active的权限alice@active去执行contract1.test。但是contract1的拥有者某一天可能偷偷更改了test的实现，在test函数中调用eosio.token的transfer函数以alice@active权限就可以取走alice的EOS. 为了解决权限乱用问题，EOS新增了eosio.code这个特殊权限。采用eosio.code后，contract1.test要以alice@active去调用其它合约如eosio.token，必须得到alice的授权，即必须在alice@active里添加[email protected]授权，让 contract1 在自己的合约代码里运行的代码具有 alice@active 权限。而且只有在 contract1 自己的合约代码里才能拿到alice@active权限，在外部手动以contract1的active权限调用alice的active权限的action（如转账等）是不会成功的，非得在contract1的自己合约代码里调用才会获得alice@active 权限。

https://eosio.stackexchange.com/questions/1621/require-inline-action-be-sent-by-contract-and-not-account

UPDATE: This is the code I used to experiment with all combinations of permissions I could come up with: https://github.com/andresberrios/permissions_test

After a lot of experimentation, I finally understand how permissions work in EOSIO!

EOS Permission Model - Overview

An account can have various permissions (like owner and active), which are represented by an account@permission pair. 一个账户会有很多类型的权限级别。
Permissions (which are like roles) can be linked to specific actions of specific contracts to allow those permissions to execute those actions (linkauth). By default, the owner and active permissions can do anything except active can't change the owner permission. 权限级别相当于角色的意思。角色可以被指定赋予给特定合约的特定action，从而允许这些action执行这些角色能执行的actions。
Permissions are controlled by an "authority", which is the multisig configuration of who can give that permission (in other words, who can act under that role).
Within this multisig configuration, you can have a combination of public keys and other permissions (account@permission pairs), which makes permissions an intrinsically recursive construct.

Acting as another account

Contracts in general should use require_auth(account) and not require_auth2(account, permission) unless there is a very specific reason to do so. Using require_auth2 to require a specific permission of an account can hinder the configurability of the EOSIO permission system. This is because in general, if actions simply require the auth of an account, then that means they are implicitly requiring one of the following permissions of that account:

The owner permission.
The active permission.
Any other custom permission that the user decided to create for their account in order to give granular authorization to specific contract actions.

Point 3 means that a user can create a permission (as I mentioned, it can be seen as a "role") called for example ramtrader and then use linkauth to authorize that permission to use the eosio::buyram and eosio::sellram system contract actions. This can work with any contract, not only the system contract. This way, when defining the ramtrader permission, users will need to specify an authority for it (a multisig configuration), and this authority could specify that the only object that can act under this permission is accountb@active, for example, giving access to the accountb account to buy and sell RAM for account.

Contract code acting as another account（合约中运行的代码调用/使用其它合约的权限）

Now that we understand how to act as another account, we can figure out how to allow a contract's code to act as another account, be it for transferring funds (eosio.token::transfer action) or just calling another contract's actions.

When contracts call inline actions, they are supposed to send the right permissions for that action. If for instance a contract that lives in the contract account would try to buy RAM for account using the funds of account itself, it would need to provide the same permissions that account is required to provide when they buy RAM for themselves manually. If we use the account@active permission, then the contract would need to send that permission in the inline action, and not [email protected] as many of us could end up thinking (the documentation on this is very scarce and confusing). In order for the code in the contract account to be able to provide that permission, first account would have to add authorization for the code of contract to the authority (multisig config) that rules it's account@activepermission. 当合约调用inline actions，他们必须具有调用这些action所需要的权限。

This can be achieved by adding the [email protected] permission to the authority, which is a special permission defined by the EOSIO software to specify that only the contract code of the contract account will be able to act under the permission (role) ruled by that authority. This means that the account@active authority would contain the public key that the owner of that account controls, as well as the [email protected] permission. 这表明account@active 的权限被授权给自己的公钥及[email protected]。

This effectively implements what you were looking for: Authorizing a contract's code to act as another account, but not letting the contract's account act as the other account.

If you wanted to let a contract's account act as yourself but not the contract's code, you would have to do the same thing but instead of setting [email protected] you would set contract@active or some other more specific (limited) permission.

Setting up the permission authority

To configure your account to allow [email protected] to act on your behalf, you would need to issue a transaction to the eosio::updateauth action with the properly formatted authority data. One way to do it using cleos is what @confused00 showed in his example:

cleos set account permission <YOUR_ACCOUNT> active '{"threshold": 1,"keys": [{"key": "<YOUR_PUBLIC_KEY>","weight": 1}],"accounts": [{"permission":{"actor":"<CONTRACT_ACCOUNT>","permission":"eosio.code"},"weight":1}]}' owner -p <YOUR_ACCOUNT>

It might be easier to save a data.json file and then put the payload in there and point cleos to it:

data.json

{
  "threshold": 1,
  "keys": [
    {
      "key": "<YOUR_PUBLIC_KEY>",
      "weight": 1
    }
  ],
  "accounts": [
    {
      "permission": {
        "actor": "<CONTRACT_ACCOUNT>",
        "permission": "eosio.code"
      },
      "weight": 1
    }
  ]
}

and then:

cleos set account permission <YOUR_ACCOUNT> active data.json owner -p <YOUR_ACCOUNT>

https://eoscity.io/f/viewtopic.php?f=7&t=29

### inline action 和 eosio.code 的使用說明.
### based on v1.3.1 EOS version.
### By Chester Kuo

### 使用到的資料
### account: eoscityiobak
### Private key: 5JSm39HQThMksaCnKpCjPA8YV1qDoPKDUr4GEFLsxTxH3P4ZGvo
### Public key: EOS6QCc7maHCvmHcuv8dE159z8yttuTCcctVqZo7vq1LtJiyMELzH

### EOS 提供了一方法, 可以在一合約中(smart contract) 中去呼叫/調用另一合約 (smart contract) 中的 ACTION 動作.
### 但是為了避免因為權限過大(如使用到 active 權限是可以做轉帳功能), 又引進來 "eosio.code"這一特殊權限, 來處理合約中所需的動作(action)
### https://github.com/EOSIO/eos/issues/3013

### 底下的範例主要參考了前陣子剛推出的針對 EOS CPU 的免費及付費 CPU 租賃服務, 又有用到 inline action 的作法, 所以用這當做範例.
### https://github.com/EOSLaoMao/BankofStak ... re/mainnet
### https://github.com/chesterkuo/EOS/tree/ ... fStaked-CE
### 程式中, 有許多的 INLINE_ACTION 的使用, 透過底下的操作和程式碼交叉驗證, 應該可以讓使用者了解到其使用方法了.

### 首先, 分別產生 ABI 和 WASM 檔案.