磨链（mochain）区块链技术社区-4.25分享-讨论分享-以

2018-04-25 本文已影响2人磨链社区

群内分享

1.磨链内容输出计划欢迎各位小伙伴积极参与。

群内讨论

1.IPFS相关

文件上传到IPFS后会被分成很多小块，那这些小块是存储在一个节点里，还是分布到很多节点存储？相同内容的文件，在IPFS中只能存在一份吗？文件本身是拆散保存的，但这是底层协议解决的事，应用层面不用关心。你上传的文件，最终会由一个url所标示，类似http中的url。两个url的实际内容协议本身不关心，可以一样也可以不一样。也是就说，可以有N多内容相同的文件被存储在IPFS里？既然文件存储在节点里，如果节点掉线，岂不是就拿不到文件了？如果你要存多份，没人会阻拦你，就像你在自己硬盘里存好多文件副本一样，但它们的url是不一样的。文件被打散之后，没个碎片都会有多个副本，分散到多个节点中，就是说数据是过量冗余存储的，这个原理和当初的BT、emule是一样的。就是文件会被打散，然后复制N个副本，分散到不同的节点，即使某个节点掉线了，也可以从别的节点下载到文件，毕竟同时掉线的几率很小，这样理解对吧？读取文件时会去有碎片副本的节点上取数据，拼凑出整个文件，极端情况缺少某个碎片导致文件不能完整拼出来也是可能的，那个内容可寻址，就是我说的每个文件会有一个唯一的url，但这个url并不是简单的文件内容哈希，你要想看算法直接去看ipfs的github：https://github.com/ipfs/ipfs一份是指一个逻辑存储单位，但是物理存储的时候，为了安全考虑会存三份还是7份都是有可能的。这个算法能实现相同内容的文件只能上传一次吗？这个你就要看协议细节了，允许也可能、不允许也可能，但如果不允许的话，就是协议层会判断文件内容哈希是否一致，如果一致则生成一个新的引用url，以节省存储，技术上这是可能的。从应用上讲，两次上传生成的url也可能是一样的，如果协议有关于文件内容哈希的优化的话。

2.最近的 ERC20 的转账的安全问题，直接原因都是代码安全漏洞，由程序员背锅，但大家比较少讨论其深层次的原因，为什么以太坊比较容易出安全问题？

以太坊只是一个记录 dapp 执行结果的区块链，其本身并没有加密货币复式记账所需的 utxo 模型。以太坊自身的以太币也是由 balance 来表示账号余额，用余额的区块链有一个明显的缺陷，很容易遭受重放攻击（交易的请求再发送一次）。以太坊用了 nonce 等 tricky 的做法避免主链货币重放，但对于基于 dapp 的代币，就需要依赖开发者自己来保障其安全逻辑。

采用复试记账的 utxo 则所有的转账需要检查输入来源，如果这个来源已经被使用过一次，则表示这次转账是一个双花尝试，而比特币最主要的架构设计逻辑比如 PoW 以及长链胜出就是用于防止双花攻击。

以太坊智能合约运行的大致流程是，取得写区块的节点运行 dapp 并记录运行结果到新的区块，当这个结果被其他节点验证之后这个新区块就被整个网络认可，验证的方法也是执行一遍这个合约脚本，智能合约的设计约束是 deterministic, 但并无其他机制可保证这个执行的安全性及正确性。即使有 bug，只要 bug 能被其他节点运行出相同结果，记录就会上链，erc20 或 erc721 是一个智能合约接口的约定，方便通用的钱包可以访问这些合约。

从 dao 到 bec, smt 这些问题都是程序员的问题吗？在数字货币的时代，重要的 token 资产本身是需要货币级别的安全程度，以太坊目前的设计更适合游戏积分之类的合约运行结果，我的看法是，重要的 token 资产不适合构建在 erc 20 基础之上。它没有任何货币安全设计的考虑。

讨论：他们如果只用官方token代码的话，也不会出这个问题，用了safemath也能避免，就这个事来讲，就是程序员的问题，其实没什么好讨论的。以太坊的设计目标是基于区块链的计算平台，不是货币系统，自然在设计上就会有取舍和权衡，比如引入账户的概念和World State。这就好像现在有经验的律师和没经验的律师起草的合约漏洞肯定有区别一样，不应该因为某些律师经验不足就否定合约本身的价值。当然谁都有评论和讨论的权利，但我觉得更重要的是提出可行方案。挑毛病还不容易，我们最不缺的就是挑毛病的大神。简单的东西不容易出问题。谁让他们用那么复杂的智能合约的官方最简单的智能合约。关键是没审计出来，这么简单的bug，或者就根本没做合约审计，其实说明他们的开发团队没有测试这个关键职位，代码越复杂越难保证安全，否则就没有黑客这个角色，所以才说公链是很有技术挑战以及运营智慧的项目，其实本质来说任何产品一旦用的人多就会形成一个生态系统。只是区块链不一样一开始就要设计成开放系统而且是完全开放，在上面生长各种dapp第三方的企业和个人。

MIT科技评论区块链峰会的几个材料

以太坊概念

MPT树的操作说明：

参考：https://www.cnblogs.com/fengzhiwu/p/5584809.html

之前的文章说到了更新，这里再说下删除和查找。

MPT树删除操作：

删除函数：_delete_and_delete_storage(self,key)

同样和更新分多种情况：

Node为空节点，那么直接返回。

Node为分支节点，如果key为空，那么表示删除了分支节点的值，node[-1]=‘’，返回node的正规化的结果。如果key不为空，递归查找node的子及诶单，删除对应的value，调用elf._delete_and_delete_storage(self._decode_to_node(node[key[0]]),key[1:])。返回新节点。

Node为叶子节点或者扩展节点，curr_key是当前node的key。一种情况，如果key不是以curr_key开头，说明key不在node为根的子树内，直接返回node。另一种情况，如果node是叶节点，返回BLANK_NODE if key == curr_keyelse node。Node是扩展节点的话，递归删除node的子节点，即调用

_delete_and_delete_storage(self._decode_to_node(node1),key[len(curr_key):])。如果新的子节点和node[-1]相等直接返回node。否则，如果新的子节点是kv节点，将curr_key与新子节点的可以串联当做key，新子节点的value当做vlaue，返回。如果新子节点是branch节点，node的value指向这个新子节点，返回。

MPT树查找：

查找函数：_get(self, node, key)

Node为空节点，那么直接返回。

Node是分支节点，key为空，返回分支节点的value；否则递归查找node的子节点，即调用_get(self._decode_to_node(node[key[0]]),key[1:])

Node是叶子节点，返回node1 if key == curr_key else ‘’

Node是扩展节点，key以curr_key开头，递归查找node的子节点，即调用_get(self._decode_to_node(node1), key[len(curr_key):])；否则，说明key不在以node为根的子树里，返回空。

在以太坊的安全树中采用SHA3（k）作为密钥，状态树和账户存储树中均使用。通过设置离散节点的链深度为64，反复用sload和sstore指令，有效防范Dos攻击。

RLP（recursive length prefix）递归长度前缀。

参考：以太坊爱好者公众号

RLP编码是以太坊的主要的序列化格式，在区块，交易，账户状态、线路协议消息都会用到。这是高度简化的序列化格式，唯一目的存储嵌套的字节数组。RLP不定义任何指定的数据类型，就以嵌套数组的形式存储结构，并用协议来确定数组的含义。RLP也没有明确支持map集合。建议采用[[k1,v1][k2、v2]…]的嵌套数组来表示键值对集合。K1、k2…按照字符串的标准排序。在以太坊中使用，由于易于实现，且保证字节的一致性。

以太坊中树的使用：

以太坊区块链中区块头包含三个树的指针：状态树、交易树、收据树。

状态树代表访问区块后的整个状态。

交易树代表区块中所有交易，这些交易由index索引作为key；

收据树代表每笔交易相应的收据。交易的收据是一个RLP编码的数据结构：

[medstate,gas_used, logbloom, logs ]：

medstate：交易处理后，树的根的状态。

gas_used：交易处理后，gas的使用量。

logbloom：交易中所有logs的address和topic组成的布隆过滤器。

logs：是表格[address, [topic1, topic2...], data] 元素的列表。表格由交易执行期间调用的操作码LOG0 ... LOG4 生成（包含主调用和子调用）；address 是生成日志的合约的地址topics是最多4个32字节的值；data是任意字节大小的数组。

以太坊中的难度更新算法：

diff(genesis) =2^32