eosio contract由3个部分构成
nativeaction
nativeactions是setcode, setabi, newaccount功能的函数集。这部分代码是hardcode在EOS系统代码里的，也就说不需要部署这一步骤，所以就解决了蛋生鸡，鸡生蛋问题。
nativeaction是通过SET_APP_HANDLER注册的
对应的函数名是apply_eosio_xxx,比如apply_eosio_setcode,apply_eosio_newaccount
eosio.bios, eosio.system
eosio.bios是一个智能合约的代码，是通过智能合约部署方式绑定到eosio contract上的。那eosio.bios部署后，nativeactions部分是不是就失效了啊。确实可以这样实现，由于setcode这些action需要永久生效，这就需要eosio.bios包含nativeactions这些函数，这样就出现了相同一份代码分散在两个模块，独立性和维护不够好。所以，目前的实现是通过特殊处理让nativeactions的函数有最高优先级，永不覆盖，哪怕eosio.bios实现了同样的函数(比如set_code, set_abi)。
但是eosio.system和eosio.bios是一个级别的，都是contract, 是水火不相容的，一旦将eosio.system绑定到eosio这个账号，eosio.bios就失效了，所以eosio.bios的函数要么是临时用途的，要么就需要bios.system重新实现，比如setalimits会失效，而setpriv会在eosio.system重新实现。
这个和操作系统启动一样，一开始bios(bootloader)代码运行，然后引导system代码，当system加载后，bios(bootloader)代码失效。所以从这个设计和名字可以看出，EOS确实是在按照操作系统的逻辑设计。