【追币课堂】EOS智能合约如何实现去中心化
From 中本错
前言
从资金盘频频跑路，我们看到了EOS智能合约存在的“大坑”。那就是智能合约竟然可以升级、可以更新、可以替换。
不少人听了这点，就开始发牢骚了。到处宣扬EOS的种种不好。提出分叉意见和各种吐槽。这种时候，比较懂EOS技术的同学，通常会呵呵一笑。彷佛听到了些好笑的事情。
灵活的东西，你不懂得正确的运用，却评说不合理。于是我写下这篇文章，希望让大家进一步理解下EOS的权限，看看到底是EOS的设计不合理，还是只是你不懂的它的工作原理。
导航：
EOS的合约权限的合理解释
EOS账号和智能合约的关系
权限即权力（power）
具体操作
eosio.prods和黑洞公钥方案的比较
EOS的合约权限的合理解释
EOS智能合约能更新的这个特点，可以视为是一种默认设置。就是说，如果你不去进行任何操作，那么默认情况下，一份智能合约是可以更新的。如果要设置成不可更新的智能合约。只要进行一些操作就行了。
EOS账号和智能合约的关系
默认情况下，账号拥有者，可以给自己的账号设置 “代码” 用来自动处理接收到什么信号的时候，自动干什么。这份代码被我们称之为 “智能合约”。
“智能合约” 跟EOS账号是一一对应的关系。一个EOS账号，可以没有智能合约，但最多只能有一个智能合约。所以，当我们说 “智能合约”的权限的时候，说的其实是EOS账号的权限。
要让 “智能合约” 变成不可更新、不可销毁的去中心化状态，意味着，是要将这个EOS账号 “去中心化”。也就是说，改变这个账号的权限。让它不仅不归你所有，而且不归世界上任何一个人所有。此时，智能合约，就是真正的去中心化状态了。
权限即权力（power）
code is law , permission is power.
在智能合约世界里，代码是法律，而权限是权力。
在 code is law 的环境里， EOS给了程序员最高的权力。
放下权力，才是真正的去中心化。放不下权力，就有突然反悔去“杀死合约”的可能性，没有做到真正的去中心化。所以要做到真正的去中心化，那就是自动放弃更新智能合约的权力。正所谓，放下屠刀，立地成佛。
具体操作
要放下权力，也就是主动放弃权限——放弃对智能合约的生杀大权。目前主流的有两种选择。
第一种，是把权限设置成超级节点： eosio.prods 。下面我们追币bidream团队来进行实操演示：
1. 我们创建了追币bidream的测试账号： testuser1111
2. 查看其权限：
➜ ~ cleos get account testuser1111
permissions:
owner 1: 1 EOS6Fhx9xMx5eNoTQjVSvNVMarT5QpPj9kddJmNbzpCbXMvtbgL9q
active 1: 1 EOS6Fhx9xMx5eNoTQjVSvNVMarT5QpPj9kddJmNbzpCbXMvtbgL9q
memory:
3. 设置active权限：
➜ ~ cleos set account permission testuser1111 active '{"threshold": 1,"keys": [],"accounts":[{"permission":{"actor":"eosio.prods","permission":"active"},"weight":1}]}' owner -p
testuser1111
executed transaction: 90550d1877b514b90a21888e68ee8520af883756f8310723530b5ffd7e525f06 144 bytes 156 us
# eosio <= eosio::updateauth {"account":"testuser1111","permission":"active","parent":"owner","auth":{"threshold":1,"keys":[],"ac...
warning: transaction executed locally, but may not be confirmed by the network yet
4. 设置owner权限：
➜ ~ cleos set account permission testuser1111 owner '{"threshold": 1,"keys": [],"accounts":[{"permission":{"actor":"'eosio.prods'","permission":"active"},"weight":1}]}' -p test
user1111@owner
executed transaction: 8d060b64470d5d0189478c98b44d2c735675baad35bb8a7de7b4e285b51e9137 144 bytes 178 us
# eosio <= eosio::updateauth {"account":"testuser1111","permission":"owner","parent":"","auth":{"threshold":1,"keys":[],"accounts...
warning: transaction executed locally, but may not be confirmed by the network yet
5. 再次检查设置结果：
➜ ~ cleos get account testuser1111
permissions:
owner 1: 1 eosio.prods@active,
active 1: 1 eosio.prods@active,
memory:
设置成功。
第二种，是把权限设置为“黑洞公钥”：
1. 我们创建了第二个追币bidream测试账号： testuser2222
2. 查看其权限：
➜ ~ cleos get account testuser2222
permissions:
owner 1: 1 EOS6Fhx9xMx5eNoTQjVSvNVMarT5QpPj9kddJmNbzpCbXMvtbgL9q
active 1: 1 EOS6Fhx9xMx5eNoTQjVSvNVMarT5QpPj9kddJmNbzpCbXMvtbgL9q
memory:
3. 设置 active 权限：
➜ ~ cleos set account permission testuser2222 active '{"threshold": 1,"keys": [{"key": "EOS1111111111111111111111111111111114T1Anm","weight": 1}],"accounts":[]}' owner -p testu
ser2222@owner
executed transaction: fd7c648b2fc298801dc7dad32d10a338f377efd74de6b6f83c4be953e5a1e485 160 bytes 313 us
# eosio <= eosio::updateauth {"account":"testuser2222","permission":"active","parent":"owner","auth":{"threshold":1,"keys":[{"key...
warning: transaction executed locally, but may not be confirmed by the network yet
4. 设置 owner 权限：
➜ ~ cleos set account permission testuser2222 owner '{"threshold": 1,"keys": [{"key": "EOS1111111111111111111111111111111114T1Anm","weight": 1}],"accounts":[]}' -p testuser2222
@owner
executed transaction: 71e29f908e5c538d90b6bd35309326bb67f6fef0cf9db45d775920f9749e7da1 160 bytes 184 us
# eosio <= eosio::updateauth {"account":"testuser2222","permission":"owner","parent":"","auth":{"threshold":1,"keys":[{"key":"EOS...
warning: transaction executed locally, but may not be confirmed by the network yet
5. 再次检查设置结果：
➜ ~ cleos get account testuser2222
permissions:
owner 1: 1 EOS1111111111111111111111111111111114T1Anm
active 1: 1 EOS1111111111111111111111111111111114T1Anm
memory:
设置成功。
eosio.prods和黑洞公钥方案的比较
eosio.prods是21个超级节点的多签权限。也就是，把权限充公，交给大家都信任的公众组织。这种方案，基本可以建立信任基石了。除非BP发起投票，15票通过，才能修改你的合约。可能性不大。而黑洞公钥，就不一样了。做的更绝。
EOS1111111111111111111111111111111114T1Anm
这个公钥来历比较牛逼。当初EOS主网创世区块的生产者 genesisblock 用到的公钥。世界上没有人有这个公钥对应的私钥。想暴力破解？ 那恐怕得集中整个地球上的算力去算100年。
➜ ~ cleos get accounts EOS1111111111111111111111111111111114T1Anm
{
"account_names": [
"genesisblock",
"octblackhole",
"uipblackhole"
]
}
可以看到，目前EOS系统中，有人也用的这个公钥，并把名字取名“黑洞”。octblackhole， uipblackhole，黑洞，意味着只进不出。这是最安全的解决方案。连21超级节点和BM都动不了。
为EOS正名
那些看到EOS智能合约能更新，就说EOS还不如以太坊的人，你们对以太坊又懂多少？
以太坊solidity智能合约里的ownable了解一下，suicide、self-destruct 函数了解一下。以太坊智能合约里的这些 “后门” 函数，同样也可以做到开发者一人一键清除所有数据，甚至销毁整个合约。所以说， 以太坊智能合约，只要开发者愿意，依然也可以一手控制合约中的所有数据。事在人为，代码程序员写。 中不中心化，去不去中心化，最终，我们还得看代码是怎么写的，才能去评论。
EOS上，同样可以写出优雅的，完全透明公正、完全去中心化的智能合约。以太坊能实现的去中心化不可改智能合约，EOS也可以实现。而EOS能实现的可更新迭代智能合约，以太坊却不能实现。
坚持拥抱EOS生态的追币bidream认为，以太坊上能做的事，EOS上都能做，并且能做的更好。而以太坊能做EOS上做不到的事，那就是不需要做的事。手动滑稽脸。
总结
EOS上的智能合约。可以更新，这是默认特性。可以更新的合约，对那些不可能一次性写完就保证没有bug的大型DAPP有好处。
EOS上的智能合约，同样可以做到不可更新。那就是主动放弃更新的权力。不可更新的智能合约的应用场景，在于那些合约账号持有大量用户的资金，需要去中心化，确保不会跑路。比如大家都在期待的去中心化交易平台。
追币bidream(zhuibi.com)正在开发基于EOS生态的颠覆性的去中心化交易平台，实现人与智能合约的直接交互。代码开源并无bug运转后，也将从智能合约的权限层面，真正做到去中心化。
