上篇文章中，我们讲解了deferred action和inline action，并且举了两个例子。然而，那两个例子中，我们从合约发出的action，都是发给自己的。那么可以发给其他的合约吗？这就引出今天的知识点了：神秘的eosio.code。
eosio.code在狼人杀游戏里有用到，并且备受争议；本文将详细介绍一下eosio.code。
在开菜之前，我们先做好准备工作：
更新一下MakeContract
MakeContract是我们之前写的一个编译脚本。为了便于后面的使用，更改了一下这个脚本：
#/bin/bash
cd $1
filename=`basename $1`
eosiocpp -o $filename.wast $filename.cpp
eosiocpp -g $filename.abi $filename.cpp
相比之前的脚本，此脚本可以编译子文件夹下的合约了。
编写两个合约send.code和recv.code
我们先在～/eos-workspace里面建立相关的智能合约文件夹：
mkdir testAB
cd testAB
mkdir sender
mkdir receiver
在testAB/sender文件夹里建立一个sender.cpp，并写入如下合约内容：
#include <eosiolib/eosio.hpp>
#include <eosiolib/transaction.hpp>
#include <eosiolib/asset.hpp>
using namespace eosio;
class sender : public eosio::contract {
public:
using contract::contract;
void send( account_name user ) {
require_auth( user );
print( "before send inline code sender Say, ", name{user});
action(
permission_level{user, N(active)},
N(recv.code), N(receive),
user).send();
}
};
EOSIO_ABI( sender, (send) )
可以看到，这个合约中有个inline action，它在原action的处理器里，向recv.code发了个receive action。
然后在testAB/receiver文件夹里建立一个receiver.cpp，并写入如下合约内容：
#include <eosiolib/eosio.hpp>
#include <eosiolib/transaction.hpp>
using namespace eosio;
class receiver1 : public eosio::contract {
public:
using contract::contract;
void receive( account_name user ) {
require_auth( user );
print( "receiver Say, ", name{user});
}
};
EOSIO_ABI( receiver1, (receive) )
这个合约更为简单，仅仅打印一个文字，代表收到了receive action。
你可能注意到了，这个类名是receiver1而不是receiver，是为了避免与EOSIO_ABI中的receiver名字冲突，从而引起编译错误。
编译和部署合约
以前都介绍过，这里仅列出命令，不再做解释了：
./MakeContract testAB/receiver
./MakeContract testAB/sender
cleos create account user send.code \
EOS83sN8bfKGk3jTBezN41UN7LfXSVFa1w3YQcGApE67J26t3HLcr \
EOS83sN8bfKGk3jTBezN41UN7LfXSVFa1w3YQcGApE67J26t3HLcr
cleos create account user recv.code \
EOS83sN8bfKGk3jTBezN41UN7LfXSVFa1w3YQcGApE67J26t3HLcr \
EOS83sN8bfKGk3jTBezN41UN7LfXSVFa1w3YQcGApE67J26t3HLcr
cleos wallet unlock
cleos set contract recv.code ./testAB/receiver -p recv.code@active
cleos set contract send.code ./testAB/sender -p send.code@active
向send.code合约发送send action
~ cleos push action send.code send '["user"]' -p user@active
Error 3090003: Provided keys, permissions, and delays do not satisfy declared authorizations
Ensure that you have the related private keys inside your wallet and your wallet is unlocked.
再看一下nodeos的output，有如下内容：
pending console output: before send inline code sender Say, user
{"console":"before send inline code sender Say, user"}
send action handler 的 log已经在在pending console里了，说明send.code合约的send action handler已经成功触发了。后面的错误是inline action失败的信息。
为什么会失败呢？
我们想想看，如果一个用户向某个合约里发送了action消息，这个合约就能够使用该用户的权限发送任何的inline action是不是很可怕？比如把该用户的所有的EOS都转走，那用户岂不是很惨？
在一开始，EOS的确存在这个漏洞，后来为了限制合约滥用用户的授权，就不再允许inline action使用原有action的权限了。
那没有用户授权，智能合约如何互相发inline action消息呢？
BM想了一个办法，设计了一个eosio.code许可，这个许可是虚拟的。我们对比下这个方式和之前方式的区别：
以前的方式是：用户对交易(或者称为事务)签名授权后，发送给合约，合约收到action之后，以
当前合约被授权的许可执行新的inline action。我们知道用户通常使用active许可签名的，并且此权限可以做很多事情，比如把资产转移等等。
现在的方式是：用户把交易(或者称为事务)签名，发送给合约，合约收到action之后，以当前合约账号的eosio.code许可，执行inline action。
解决方案
根据我们之前学的账号和权限相关的知识，如果要让send.code的eosio.code能够代表user执行inline action，那么需要四步：
- 给
send.code设置一个eosio.code许可- 把
user的某个许可(可以是active，不过我们这次不用active了，新建一个sendp许可吧)授权给send.code的eosio.code许可- 把user的这个
sendp许可和recv.code的receive关联起来- 因为新建了一个
sendp许可，所以为了能向send.code发送sendaction，我们还需要把它和send.code的sendaction关联起来。
我们先给send.code加上一个eosio.code许可：
~ cleos set account permission send.code eosio.code EOS83sN8bfKGk3jTBezN41UN7LfXSVFa1w3YQcGApE67J26t3HLcr -p send.code@active
Error 3050000: Action validate exceptio
失败了，nodeos的output有详情：
Permission names that start with 'eosio.' are reserved
说明eosio.是保留给系统用的，我们没法给合约账号设置eosio.code许可了。这也说明了，我们无需给合约设置eosio.code许可，系统会帮我们处理好相关的问题。
那我们进入第二步吧， 给user新建一个许可sendp，并把它授权给send.code的eosio.code许可:
~ cleos set account permission user sendp '{"threshold": 1,"keys": [{"key":"EOS83sN8bfKGk3jTBezN41UN7LfXSVFa1w3YQcGApE67J26t3HLcr", "weight":1}],"accounts": [{"permission":{"actor":"send.code","permission":"eosio.code"},"weight":1}]}' owner -p user@owner
executed transaction: aa60976084adbada1d89b35a023a88cc2d8535a284d1fca04084a952168fbfd6 184 bytes 1076 us
# eosio <= eosio::updateauth {"account":"user","permission":"sendp","parent":"owner","auth":{"threshold":1,"keys":[{"key":"EOS83s...
很成功。
进入第三步，把user的sendp许可和recv.code的receive关联起来:
~ cleos set action permission user recv.code receive sendp -p user@active
executed transaction: f85293c5ef00f1ca56b8ae75f02b74f94f45e22d8dbf31ffddc4dc235e60c492 128 bytes 4338 us
# eosio <= eosio::linkauth {"account":"user","code":"recv.code","type":"receive","requirement":"sendp"}
第四步， 把sendp和send.code的send action关联起来:
~ cleos set action permission user send.code send sendp -p user@active
executed transaction: d4670605d0a64648158cc96ade52b86fc6818a5fa0d62c393acccaca6106a254 128 bytes 943 us
# eosio <= eosio::linkauth {"account":"user","code":"send.code","type":"send","requirement":"sendp"}
再修改一下send.code的合约代码，主要是发送action这里，把原来的active许可，修改为sendp许可：
action(
permission_level{user, N(sendp))},
N(recv.code), N(receive),
user).send();
最后，我们使用sendp许可向send.code发送send action:
~ cleos push action send.code send '["user"]' -p user@sendp
executed transaction: 7c5262c16ca32fd809258794e259846f012ae6ba57b97b6fda0c3c7a13849ca3 104 bytes 2534 us
# send.code <= send.code::send {"user":"user"}
>> before send inline code sender Say, user
# recv.code <= recv.code::receive {"user":"user"}
>> receiver Say, user
哈哈，成功了。
注意事项
- 我们在给
user设置sendp许可的时候，使用的是这样的命令：
~ cleos set account permission user sendp '{"threshold": 1,"keys": [{"key":"EOS83sN8bfKGk3jTBezN41UN7LfXSVFa1w3YQcGApE67J26t3HLcr", "weight":1}],"accounts": [{"permission":{"actor":"send.code","permission":"eosio.code"},"weight":1}]}' owner -p user@owner
我们除了授权给send.code的eosio.code许可外，还授权给了一个key，其实这个key是什么无关紧要，只要你的钱包里有这个key就可以了。问题是，可以把这个key去掉吗？可以只授权给send.code的eosio.code许可吗？
答案是不可以。如果只授权给send.code的eosio.code许可，那么触发send.code的send action的交易，就找不到合适的key签名，因为用户是没有eosio.code许可所对应的key的。
- 真的会比没有
eosio.code许可权限之前的情况要好吗？
在之前没有eosio.code许可权限以前，系统允许inline action以原有的action的权限运行，存在重大隐患，因为合约可以很容易的转移到用户的资产。
在引入eosio.code之后，原来的方式行不通了。合约要想代表用户，必须要用户自己同意添加eosio.code授权。这中间多了个用户授权的过程。如果用户信任该合约，那么可以授权；如果不信任，则不予授权，相对来说的确安全了一些。
等一下，这真的安全吗？
这真的安全吗？狼人杀也用了eosio.code，不是说有漏洞吗？我们下次详解。
简介：不羁，一名程序员；专研EOS技术，玩转EOS智能合约开发。
微信公众号：know_it_well
知识星球地址：https://t.zsxq.com/QvbuzFM
