现在做点设计的方便之处在于，有点问题查下谷歌就可以啰！谷歌如些强大，以至于有人提出：面向谷歌的设计！不管如何，谷歌有很多方面可以快速解决问题。

你也可以直接查询下编译器的报错，上面就有很直接的解决方法，很是方便。谷歌对技术文献方面的检索要超出百度不少，特别是在智能合约等稍有点新的技术上，国内就很难查出有效的资料。国外的stackoverflow.com技术网站相当给力，很多技术难题上面都有，谷歌对它的检索也不少。

我现在做的一些前端，直接在谷歌里也可以找到现成的方法。比如最近想把秒转成时分的显示，一查就有很多实现方法。找到一个改改就可以啰，简直不能太方便了。

可能有些人认为过于依赖谷歌对于设计的创作力不好，不过我已经习惯了，“面向谷歌的设计”也是个不错的解决方案不是！

This page is synchronized from the post: ‘面向谷歌的设计’

当我们天天还在盼望着疫情早点结束的时候，世界已经悄悄发生了巨大的变化，有点像是温水煮青蛙，当你猛然察觉时，世界已面目全非！

广州现在已经很热了，可我去超市买东西时因为担心还是一样会戴口罩，不管我有多热多想把它摘掉。这种心态可能会长期存在，一直持续到疫苗的广泛使用。

线上化似乎在一夜之间！ 国内教育的线上化真的就只用了一个晚上，全面的线上教育就开始了。线上课程、线上答辩、线上考试……一切和教育相关的都放到了线上！这种状态估计会一直持续，线上教育所占的份重会越来越重。

随便一个网红就年入百万、过亿！ 很多人做梦都想的事情真的实现了！“卖笑”也有了新的市场，权威似乎也不那么有权威了，价格说了算。据说很多95后开始喜欢做网红了，正儿八经的工作意义也不大了，完全看心情。

很多人发现“家里蹲”也能挣到钱的时候就会更加深入得挖掘一切的机会去挣钱。就算网赚不能成为全职工作，也能成为一个副业不是。

国内已经在试行数字货币。以前国家至少还要开个印钞机来印钞票，以后不会了，电脑上输个数字就行。可以预见，通胀率会加速提高，也许明年100大元就只能买个鸡蛋了！

也许“第三次世界大战”已经开始，只是我们还不自知！

This page is synchronized from the post: ‘后疫情时代……’

如果只是简单地逻辑实现，那么就应该只用msg.sender就好啰。但是真实情况往往是你需要把逻辑划分成不同的合约来实现，再通过它们之间的相互调用来实现复杂的逻辑。这就好比不同的类之间要相互交流一样。

如上图所示，用户D通过合约B调用合约接口来调用合约A中的函数，这时tx.origin的穿透性就体现出来了。msg.sender只能得到直接调用它的地址（即合约B），得不到用户D的身份，只有tx.origin才能得到！所以，从这里可能看到，tx.origin具有的穿透的访问性。

利用tx.origin的穿透性会产生一定的钓鱼攻击，如下面所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

pragma solidity >=0.4.22 <0.7.0;

contract UserWallet {
    address owner;

    constructor() public payable {
        owner = msg.sender;
    }

    function transferTo(address payable _to, uint amount) public {
        require(tx.origin == owner);  //tx.origin作验证会有漏洞
        _to.transfer(amount);
    }
}

require(tx.origin == owner);用它用验证时有一定的漏洞，因为任何人都可以创建一个合约B来试图调用这个合约中的transferTo方法来攻陷你的钱包！

如果你已经熟悉了tx.origin的这点特性，倒也不用谈虎色变，它的特性还是给了我们相互调用合约的便利性，使得我们设计的合约复杂度得以提高，能做的事更多。

This page is synchronized from the post: ‘tx.origin的穿透性和攻击性 / 学习智能合约#19’

“社畜”，我也是最近听到这个流行词，看其词识其意：“社会的牲畜”，简称“社畜”。国内早先其实倒还有另一个流行的说法：女人当男人用 ，男人当畜牲用！词语发生点变化，就是“社畜”了。不过究其来源，据称是来自于日本，“是日本用于形容上班族的贬义词，指在公司很顺从地工作，被公司当作牲畜一样压榨的员工，多用于自嘲。”

自从听到这个词“社畜”就很难忘记了，这实是一种很贴切的比喻啊！这真是道出了当下人们的艰难处境。还有什么能比“社畜”这个词更加形容的呢？！

国内流行“北漂”，“广漂”的说法，但论起深刻性，我还是觉得“社畜”更加深刻。底层民众可不就是任人鱼肉的“畜牲”吗？！这种无奈又无能的深刻无力感，又有谁能明确地表达和显露呢？

This page is synchronized from the post: ‘社畜’

如上图所示，在MetaMask钱包（和大多数交易所的一样）以太币的地址是大小写混杂的。但是细心的用户相必已经注意到了，所有的浏览器中都是全小写的地址！

我在用前端做地址校验时突然发现前端得到的以太地址全是小写的？！这是什么鬼啊！找了好久也没发现问题所在，只能将MetaMask中的地址全部小写再与前端地址校验这才得到正确结果。

以前在鱼池中就发现了这个问题。但是以太地址的大小写是不区分的，两个都是同一个地址。在网上稍查下资料，一致性是没错的，只是有个校验和的问题。看了半天，貌似关系不是太大，也就先放着吧。

This page is synchronized from the post: ‘MetaMask地址和前端地址的大小写问题 / 学习智能合约#18’

当你同时需要向不同的用户转帐时，批量转帐合约就有了它的应用场景。批量化在不少语言中就是一个for循环，但在智能合约中使用for循环可能就会有不少的大坑了。所以，在设计时要多参考，多测试。

先看看代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

pragma solidity >=0.4.22 <0.7.0;

contract TransferMany {
    constructor() payable public {
    }
    
    receive() external payable { }
    
    fallback () external payable { }
    
    function transferEths(address payable[]  memory _tos) payable public returns (bool) 
    {
        require(_tos.length > 0);
        // require(msg.sender == owner);
        for(uint32 i=0;i<_tos.length;i++){
          _tos[i].transfer(1 ether);
        }
       return true;
    }
}

总体来讲，先将以太币传入合约，再调用合约批量转帐。新版的Solidity是使用receive接收以太币，业务逻辑中同样是使用for来完成批量业务。在生成合约时最好加上权限，只有owner才能调用合约。

如果是批量转帐代币也是并不多思路，只是调用的方法不太一样而已，大家可以自行尝试。

This page is synchronized from the post: ‘试试批量转帐合约 / 学习智能合约#17’