📜 [專欄新文章] Ethereum Token — ERC20 mint 跟 burn
✍️ Kimi Wu
📥 歡迎投稿： https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium

這篇會著重在erc20 smart contract實作mint跟burn的部分，所以需要先了解erc20喔！

erc20 token在設計上可以a.預先產生，b.產生部分然後部分用挖的(mint)或是c.都用挖的。當然在應用上跟token屬性有關，例如是屬於security token或是utility token。簡單來說，像是股票可以獲利或是配息概念的算是security token，需要受各國法令監管，那utility token就比較像是點數的概念，至於細節怎麼分不是本篇重點。

mint的使用時機，例如在crowd sale時，每一筆進入crowd sale的錢，crowd sale 的contract 就會呼叫token contract去產生某個數量的token，這個動作就可以稱作mint。也有不用挖的，一開始就產生好，例如秘銀（MITH），從etherscan可以看到token contract怎麼寫的，這裡可以看到MITH的contract。當然你想產多少就多少，不過就看有沒有人買單 ＸＤ

回到正題，要”挖”聽起來，就覺得很複雜，但其實smart contract的本質就是記帳，所以其實就只是數字上的加減而已，下面是範例程式

function mint(address _to, uint256 _amount) public { totalSupply_ = totalSupply_.add(_amount); balances[_to] = balances[_to].add(_amount); emit Mint(_to, _amount); }

其實就只是把增加個人的token的數量，然後增加整個contract token的總數而已。當然，這種function需要做權限的控管，不然大家都可以自己產，token就會沒價值了。講完”挖”應該很好想像怎麼burn吧?! 就是把數量減掉就好了！(當然這也需要做權限控管)

function _burn(address _who, uint256 _value) public { balances[_who] = balances[_who].sub(_value); totalSupply_ = totalSupply_.sub(_value); emit Burn(_who, _value); }

這是基本的mint跟burn，至於在應用上有需要其他邏輯，就是基於這個在往上堆疊。例如可以多加Transfer的event（erc20 標準中的Transfer event），在mint時from就是0x0，burn就是to為0x0，在應用上如果要追蹤token數量，就會比較方便。

最後在分享openzeppelin-solidity這個github repository，在看網路上很多的sample code常會看到SafeMath或是Ownable這兩個contract，其實都是出自於openzeppelin，裡面還有很多contract的範例可以參考或是使用，最棒的是他們一直有根據最新solidity的版本而做更新，所以都會根據新的語法做更新。他們把module切得相當的細，非常的OO，不過在看的時候會比較難一口氣看完，這也是Vyper開發者覺得solidity需要改善的其中一個點 -「可讀性」。因為可讀性越差，可稽核性就越差，相較之下安全性就越差。

* Vyper是類Python語法的新一代smart contract語言，目前還在beta(0.1.0-beta.2)，不過Casper的smart contract已經是用Vyper寫的囉！看來Ethereum foundation的開發者是傾向往這邊走。

有錯誤或是不同看法，歡迎指教喔！

Originally published at kimiwublog.blogspot.com.

Ethereum Token — ERC20 mint 跟 burn was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.

👏 歡迎轉載分享鼓掌

📜 [專欄新文章] Solidity Weekly #6
✍️ mingderwang
📥 歡迎投稿： https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium

constructor 的新寫法

還在用 function contract_name 當 solidity 智能合約 constructor 嗎? 雖然目前還可以用, 但 deprecated 的寫法, 以後 compilers 可能就不支援了.

跟手機 OS 升級一樣, 每次 Solidity 新版本出來, 就是為了修要一些 bugs, 也同時讓寫出來的 code 更安全. 所以請儘早把 舊的寫法改掉, 且用最新的編譯器來編譯.

例如:

contract Ownable { address public owner;

function Ownable() public { owner = msg.sender; }}

改成

contract Ownable { address public owner;

constructor() public { // <--- 這一行 改用 constructor owner = msg.sender; }}

不建議再用 function 加上 contract name 來當 constructor 是因為, 避免 contract name 被 rename, 卻忘了改 constructor 的 function name 產生的問題, 所以有此寫法上有了此的新設計.

Solidity v0.4.23 之前, 還有可能同時寫兩個 constructor, 一個新的寫法, 一個舊的寫法. 但只執行其中一個. 在 ^0.4.23 修正了這個問題.

*適用版本 Solidity 0.4.22 或以上

Solidity Weekly #6 was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.

👏 歡迎轉載分享鼓掌

📜 [專欄新文章] 比較 require(), assert() 和 revert()，及其運作方式。
✍️ Hsieh Yung-chen
📥 歡迎投稿： https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium
利用 solidity 來撰寫 ethereum 智能合約的時候，很常會需要做一些狀態檢查。比如很多dapp常用到的 ownable：

在 transferOwnership 的時候合約需要檢查交易發起人是否為 owner , 若不是則執行 throw。throw 會使整個交易終止，並讓合約狀態回到交易執行前的狀態，並取走“所有”交易手續費，及 msg.sender 會被抽走 gasLimit * gasPrice 這麼多 ether。
一筆失敗的交易，記上區塊鏈之後，gasUsed 直接等於 gasLimit。
補充：若是一筆沒有遇到 throw 的正常交易, 則會被抽走 gasUsed * gasPrice 這麼多 ether。

有參與過 ICO 的人應該會知道，ICO 很常會也一些奇怪的投標規則。像是會限制投標時間，或是 gasPrice，或是個人投標上限等等。你會發現如果你沒有遵守這些規則，那你發出去的交易會失敗，還會被抽走所有的交易手續費，而這通常都不少錢，因為很多投標需要大量的 gas，致使 gasLimit 不能設太低。像我只是搞錯了投標時間，提早發出了投標交易，就被抽走這麼多手續費，實在是叫我情何以堪。所以需要不同的狀態檢查機制，能夠分辨是簡單的錯誤，或是較嚴重的系統錯誤，兩者會顯示不同的錯誤，抽不同的手續費。

補充：在還沒更新前，還是可以透過 return 的寫法來避免抽取過多的手續費。不過這樣會合約會需要寫比較多東西。另外，因為智能合約為 ethereum 上所有節點所執行， return 如果不是由其他智能合約承接的話，無法直接從交易上看出回傳值，導致很難從交易本身直接看出交易成功或失敗。
用 return 的寫法。
在 0.4.10 版的 solidity，新增了 require(), assert(), revert() 想要解決上段提到的問題。預計 require() 用來檢查較不嚴重的錯誤，可以退回為使用到的 gas。而 assert() 用來檢查較嚴重的錯誤，會像以前一樣拿走所有 gasLimit 的手續費。寫法基本上都相同，只是處理方式不一樣。而 revert 跟 require 基本上相同，但是 revert 沒有包括狀態檢查。
11 行原為 throw 的寫法，改為 require，也可直接改成 assert。revert 寫法。
solidity 的智能合約完成後，會編譯成 ethereum byte code 在 ethereum virtual machine (EVM) 上執行。在 0.4.10 版之前，throw 這個關鍵字，會被編譯成 0xfe 開頭的 opcode ，如果你有把黃皮書背熟的話，就會知道這個 opcode 是沒有被定義的，所以當 evm 執行到這個 opcode 會回傳 invalid opcode error。

而在 0.4.10 版之後，新增了 require(), assert(), revert() 三個函式。編譯器會把 require() 以及 revert() 編譯成 0xfd。把 assert() 編譯成 0xfe。 throw 處理方式跟 require相同，會編譯成 0xfd。這些更新只在 solidity 跟 solidity compiler，與 ethereum protocol 無關。當然，新產生的 0xfd opcode， evm 也不認得。

要讓 evm 認得新的 opcode，以便執行相對應的動作，會要更改到 ethereum protocol， 需要硬分岔來更新。在還未更新之前，這些變更都還是會跟之前相同的結果。而這項更新會在 即將到來的 Byzantium 硬分叉裡。新增 REVERT opcode ，就是 0xfd 。

當 evm 執行到 REVERT 指令，會把這個交易更新到的合約狀態都回復到交易前，且會退還剩餘的手續費。另外允許回傳一些資訊，讓錯誤訊息不再只有 execution error。可能會像是這樣：

補充： solidity 目前還沒有 error message 的寫法，相關討論在 (連結)。

最後，關於 assert 以及 require 等如何選用並沒有硬性規定，在合約撰寫的時候可以自行決定。不過，建議像是狀態檢查，input 檢查這些不影響合約狀態的可以用 require()。而 revert() 跟 require 相同，但當合約較複雜的時候，你會發現用 revert 會比較好讀。assert ()用在較安全性上的檢查，像是 overflow 等等。

reference:

EIP 140: https://github.com/axic/EIPs/blob/revert/EIPS/eip-140.md

https://medium.com/…/the-use-of-revert-assert-and-require-i…

比較 require(), assert() 和 revert()，及其運作方式。 was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.

👏 歡迎轉載分享鼓掌