智能合约的永固性
到目前所学的内容中，一直有一个疑问，那就是Solidity和其他语言到底有什么区别，它甚至长得很像JavaScript！事实上，在几个方面上，以太坊上的DApp和普通的应用之间有着天壤之别。当智能合约上传到以太坊网络之后，它就变得不可更改，也就意味着你的代码永远不能被调整或更新。
你编译的程序会一直，永久的，不可更改的，存在以太坊上。这就是 Solidity 代码的安全性如此重要的一个原因。如果你的智能协议有任何漏洞，即使你发现了也无法补救。你只能让你的用户们放弃这个智能协议，然后转移到一个新的修复后的合约上。
这也恰好是智能合约的优势所在。代码说明一切。如果你去读智能合约的代码，并验证它，你会发现，一旦函数被定义下来，每一次的运行，程序都会严格遵照函数中原有的代码逻辑一丝不苟地执行，完全不用担心函数被人篡改而得到意外的结果。
外部依赖
当合约地址被硬编码到DApp中时，可能会出现这种情况，比如所有的地址在一瞬间都消失了！虽然这种情况出现的可能性很低，但是倘若这种情况真的发生，那DApp也会随之失效。因此，我们可能需要改变硬编码的方法获取地址，而是选择使用函数，在运行函数时再去获取地址，从而达到提高DApp安全性的效果。
构造函数
构造函数不是必须的，它与合约同名，构造函数一生中唯一一次的执行就是在合约最初被创建的时候。
函数修饰符
modifier关键字。修饰符和函数很类似，但是是用于修饰其他已有的函数，它不能像函数被直接调用，只能被添加到函数定义的末尾，在其他语句执行前检查其先验条件，确保合约的主人才能运行本函数。
Tips：最常见的函数修饰符还是放在函数执行前添加快速的require检查。
Tips2: 部署在以太坊上的 DApp，并不能保证它真正做到去中心，你需要阅读并理解它的源代码，才能防止其中没有被部署者恶意植入后门；作为开发人员，如何做到既要给自己留下修复 bug 的余地，又要尽量地放权给使用者，以便让他们放心你，从而愿意把数据放在你的
DApp 中，这确实需要个微妙的平衡。
OpenZepplin_Solidity库中的Ownable合约
Gas-驱动以太坊DApps的能源
在Solidity中，用户每次执行DApp都需要支付一笔gas fee，一个DApp收取多少gas取决于功能逻辑的复杂程度。每个操作背后都在计算完成这个操作所需要的计算资源。（例如，存储数据就比做加法运算贵得多），一次操作所需要花费的gas fee相当于这个操作背后所有运算花销的总和。
Tips：由于运行DApp需要花费用户的真金白银，在以太坊中代码的编程语言，比其他任何编程语言都更强调优化。同样的功能，使用笨拙的代码开发的程序，比起经过精巧优化的代码来，运行花费更高，这显然会给成千上万的用户带来大量不必要的开销。
为什么使用Gas
以太坊就像一个巨大、缓慢、但非常安全的电脑。当你运行一个程序的时候，网络上的每一个节点都在进行相同的运算，以验证它的输出，这就是所谓的“去中心化” 由于数以千计的节点同时在验证着每个功能的运行，这可以确保它的数据不会被被监控，或者被刻意修改。可能会有用户用无限循环堵塞网络，抑或用密集运算来占用大量的网络资源，为了防止这种事情的发生，以太坊的创建者为以太坊上的资源制定了价格，想要在以太坊上运算或者存储，你需要支付Gas fee。
节省Gas fee的方式：结构封装（Struct packing）
在Solidity中除了标准的uint之外还有uint8，uint16，uint32等，在通常情况下无论如何定义uint的大小，Solidity都会为它保留256位存储空间。但是把uint绑定到struct里面是，尽可能的使用较小的uint，Solidity会将这些uint打包在一起，从而占用较少的存储空间，达到节省Gas fee的目的。
使用结构打包后“MIniMe”比“Nomal”占用的空间更小
Leave a Reply