1
智能合約的定義
1994年蜈七,計(jì)算機(jī)科學(xué)家和密碼學(xué)家 Nick Szabo 首次提出“智能合約”概念噪馏。它早于區(qū)塊鏈概念的誕生。Szabo 描述了什么是“以數(shù)字形式指定的一系列承諾,包括各方履行這些承諾的協(xié)議”咆霜。雖然有它的好處穷绵,但智能合約的想法一直未取得進(jìn)展——主要是缺乏可以讓它發(fā)揮出作用的區(qū)塊鏈轿塔。
直到 2008 年,第一個(gè)加密貨幣比特幣才出現(xiàn)仲墨,同時(shí)引入了現(xiàn)代區(qū)塊鏈技術(shù)勾缭。區(qū)塊鏈最初是以比特幣的底層技術(shù)出現(xiàn)的,各種區(qū)塊鏈分叉導(dǎo)致發(fā)生很大的變化目养。智能合約在 2008 年依然無法融入比特幣區(qū)塊鏈網(wǎng)絡(luò)俩由,但在五年后,以太坊讓它浮出水面混稽。從此采驻,涌現(xiàn)出了各種不同形式的智能合約,其中以太坊智能合約使用最廣匈勋。
自以太坊開始礼旅,區(qū)塊鏈?zhǔn)且粋€(gè)運(yùn)行著智能合約的分布式平臺:應(yīng)用程序可以按照程序運(yùn)行,不存在故障洽洁、審查痘系、欺詐或第三方干預(yù)的可能性。智能合約給予了我們使用區(qū)塊鏈技術(shù)來驗(yàn)證我們運(yùn)行的代碼的執(zhí)行情況的能力饿自。
智能合約定義
智能合約(英語:Smart contract )是一種旨在以信息化方式傳播汰翠、驗(yàn)證或執(zhí)行的計(jì)算機(jī)協(xié)議。智能合約允許在沒有第三方的情況下進(jìn)行可信交易昭雌,這些交易可追蹤且不可逆轉(zhuǎn)复唤。
智能合約簡單定義就是智能合約是可以處理 token 的腳本,圍繞它可以發(fā)行烛卧,轉(zhuǎn)移和銷毀資產(chǎn)佛纫。這里說的資產(chǎn)是一個(gè)泛化的定義,不一定是幣总放,可以是任何一種虛擬物品(比如應(yīng)收呈宇,支付信息甚至加密貓)和現(xiàn)實(shí)世界的物品在區(qū)塊鏈上的映射(比如艙單,抵押)局雄。
CITA 智能合約
CITA 區(qū)塊鏈框架使用的虛擬機(jī) CITA-VM 和 EVM 采取同樣的指令集甥啄,所以合約所使用的語言也是 solidity。由于 Ethereum 是目前全球最廣泛的區(qū)塊鏈網(wǎng)絡(luò)炬搭,所以 solidity 也是使用最廣泛的智能合約語言蜈漓,圍繞它的生態(tài)是非常豐富的穆桂,包括了合約調(diào)試,部署工具和保護(hù)合約安全的一些庫融虽。
這里再談一下合約是由誰來執(zhí)行的問題充尉,在公鏈上,比如比特幣或者以太坊衣形,這些合約由我們稱為“礦工”的參與方強(qiáng)制執(zhí)行和證明驼侠。礦工其實(shí)是多臺電腦(也可以稱為礦機(jī)),它們把一項(xiàng)交易(執(zhí)行智能合約谆吴,代幣轉(zhuǎn)賬等) 以區(qū)塊的形式添加到一個(gè)公開分賬本上倒源。使用者給這些礦工支付 “Gas”也就是手續(xù)費(fèi),它是運(yùn)行一份合約的成本句狼。
由于 CITA 是針對于企業(yè)的開放許可鏈框架笋熬,在 CITA 中礦工是出塊節(jié)點(diǎn),使用智能合約所需要的手續(xù)費(fèi)是支付給出塊節(jié)點(diǎn)的腻菇, gas 在這里叫做 quota胳螟。當(dāng)然這里支付比例是可以自定義調(diào)整的,具體可以見文檔筹吐。同時(shí) CITA 可以調(diào)節(jié)為無幣模式糖耸,在無幣模式下,不存在手續(xù)費(fèi)丘薛。
2
智能合約開發(fā)
現(xiàn)在嘉竟,我們開始智能合約的開發(fā)部分,Solidity 與 Javascript 很接近洋侨,但它們并不相同舍扰。而且不能在一段代碼上強(qiáng)加 JQuery,智能合約是無法調(diào)用區(qū)塊鏈體系之外的代碼的希坚。同時(shí)還有一個(gè)特點(diǎn)是边苹,你在開發(fā)的時(shí)候需要特別注意安全性,因?yàn)樵趨^(qū)塊鏈上的交易是不可逆的裁僧。
智能合約定義
通過一個(gè)例子說明基本語法个束,這里參考了 ethfans 上的一個(gè)例子,如果難以理解的話可以換一個(gè)锅知,使用當(dāng)時(shí) PeckShield 講的一個(gè)分餅干的例子播急。
現(xiàn)在脓钾,關(guān)于我們的第一個(gè)例子售睹,我正在考慮一個(gè)由電影《時(shí)間規(guī)劃局》啟發(fā)的腳本。電影中可训,人們生活在一個(gè)反烏托邦式的未來昌妹,改用時(shí)間作為貨幣流通捶枢。他們可以通過掰手腕的方式贏取對手的時(shí)間(他們的“手臂”上存儲著時(shí)間,輸方的時(shí)間將會傳送給贏家)飞崖,我們也可以這么做烂叔!用智能合約以角力( Wrestling )的方式賺錢。
首先固歪,solidity 腳本的基礎(chǔ)是下面這段代碼蒜鸡,pragma 指明正在使用的 Solidity 版本。Wrestling 是合約的名稱牢裳,是一種與 Javascrip 上的類(class)相似的結(jié)構(gòu)逢防。
我們需要兩個(gè)參與者,所以我們要添加兩個(gè)保存他們賬戶地址的變量(他們的公鑰)蒲讯,分別是 wrestler1 和 wrestler2 忘朝,變量聲明方式如下灵疮。
在我們的小游戲中谚咬,每一輪的比賽赢笨,參與者都可以投入一筆錢轿钠,如果一個(gè)人投入的錢是另一個(gè)人的兩倍(總計(jì))壹若,那他就贏了虑乖。定義兩個(gè)玩家是否已經(jīng)投入的flagwrestler1Played和wrestler2Played以及兩位玩家投入的金額wrestler1Deposit和wrestler1Deposit挨务。
還有判斷游戲結(jié)束與否纯丸,贏家和收益的變量晌畅。
下面介紹一些關(guān)于公鑰/私鑰的規(guī)則旱捧,在區(qū)塊鏈上每一個(gè)賬戶都是一對公私鑰,私鑰可以對一個(gè)信息進(jìn)行簽名踩麦,從而使這條信息可以被他人驗(yàn)證枚赡,被驗(yàn)證的時(shí)候它的公鑰需要被使用到。在整個(gè)簽名和驗(yàn)證的過程中谓谦,沒有信息是加密的贫橙,實(shí)際上任何信息都是公開課查驗(yàn)的。
對于合約里面的變量反粥,本質(zhì)上來講卢肃,也是可以被公開訪問的。在這里要注意是的才顿,即使一個(gè)變量是私有的莫湘,并不是說其他人不能讀取它的內(nèi)容,而是意味著它只能在合約中被訪問郑气。但實(shí)際上幅垮,由于整個(gè)區(qū)塊鏈存儲在許多計(jì)算機(jī)上,所以存儲在變量中的信息總是可以被其他人看到尾组,這是在區(qū)塊鏈中一個(gè)很重要額原則忙芒。
另一方面示弓,和很多編程語言很像,編譯器會自動(dòng)為公共變量創(chuàng)建 getter 函數(shù)呵萨。為了使其他的合約和用戶能夠更改公共變量的值奏属,通知也需要針對不同的變量創(chuàng)建一個(gè) setter 函數(shù)。
現(xiàn)在我們將為游戲的每一步添加三個(gè)事件潮峦。
開始囱皿,參與者注冊;
游戲期間忱嘹,登記每一輪賽果铆帽;
最后,其中一位參與者獲勝德谅。
事件是簡單的日志爹橱,可以在分布式應(yīng)用程序(也稱為 dapps)的用戶界面中調(diào)用 JavaScript 回調(diào)函數(shù)。在開發(fā)過程中窄做,事件甚至可以用于調(diào)試的目的愧驱,因?yàn)椴煌?JavaScript 有console.log() 函數(shù),solidity 中是沒有辦法在 console 中打印出信息的椭盏。代碼如下:
現(xiàn)在我們將添加構(gòu)造函數(shù)组砚,在 Solidity 中,它與我們的合約具有相同的名稱掏颊,并且在創(chuàng)建合約時(shí)只調(diào)用一次糟红。在這里,第一位參與者將是創(chuàng)造合約的人乌叶。msg.sender是調(diào)用該函數(shù)的人的地址盆偿。
接下來,我們讓另一個(gè)參與者使用以下函數(shù)進(jìn)行注冊:
Require 函數(shù)是 Solidity 中一個(gè)特殊的錯(cuò)誤處理函數(shù)准浴,如果條件不滿足事扭,它會回滾更改。在我們的示例中乐横,如果變量參與者2等于0x0地址(地址等于0)求橄,我們可以繼續(xù);如果參與者2的地址與0x0地址不同葡公,這就意味著某個(gè)玩家已經(jīng)注冊為對手罐农,所以我們會拒絕新的注冊〈呤玻可以把它認(rèn)為是 solidity 中的if() {} else{}條件判斷涵亏。
再次強(qiáng)調(diào),msg.sender是調(diào)用該函數(shù)的帳戶地址,并且當(dāng)我們觸發(fā)一個(gè)事件溯乒,就標(biāo)志著角力的開始。
現(xiàn)在豹爹,每一個(gè)參與者都會調(diào)用一個(gè)函數(shù)裆悄, wrestle(),并投入資金臂聋。如果雙方已經(jīng)玩過這場游戲光稼,我們就能知道其中一方是否獲勝(我們的規(guī)則是其中一方投入的資金必須是另一方的雙倍)。關(guān)鍵字payable意味著函數(shù)可以接收資金孩等,如果它不是集合艾君,函數(shù)則不會接受幣。msg.value是發(fā)送到合約中的幣的數(shù)量肄方。
請注意冰垄,我們不是直接把錢交給贏家,在此情況下這并不重要权她,因?yàn)橼A家會把該合約所有的錢提取出來虹茶;而在其他情況下,當(dāng)多個(gè)用戶要把合約中的以太幣提取出來隅要,使用withdraw模式會更安全蝴罪,可以避免重入,在合約安全部分我們會詳細(xì)討論這些情況步清。
簡單地說要门,如果多個(gè)用戶都可以從合約中提取資金,那么任誰都能一次性多次調(diào)用withdraw函數(shù)并多次得到報(bào)酬廓啊。所以我們需要以這樣一種方式來編寫我們的取款功能:在他繼續(xù)得到報(bào)酬之前欢搜,他應(yīng)得的數(shù)額會作廢。
它看起來像這樣:
https://github.com/devzl/ethereum-walkthrough-1/blob/master/Wrestling.sol 有代碼段谴轮。
智能合約的IDE
在區(qū)塊鏈技術(shù)中狂巢,不僅轉(zhuǎn)賬是一筆交易,對合約中函數(shù)的調(diào)用和合約的部署都是以發(fā)送交易的方式完成书聚。整個(gè)過程比較繁瑣唧领,正如同其他的變成語言一樣,針對于 solidity 智能合約雌续,我們也提供了 IDE (CITA IDE) 來編譯和部署合約斩个。
CITA 的IDE
CITA IDE 是基于 Ethereum 的 Solidity 編輯器進(jìn)行修改并適配了 CITA ,是面向 CITA 的智能合約編輯器驯杜,能夠編寫受啥、編譯、debug、部署智能合約滚局【优可直接運(yùn)行官方 CITA IDE 1(https://cita-ide.citahub.com)進(jìn)行體驗(yàn)。
使用說明
browser 內(nèi)置常用的模板合約藤肢,首先從內(nèi)置合約模板中選擇合適的模板開始開發(fā)Compile 本地編譯太闺,選擇當(dāng)前 solidity 版本,與合約 pragma 一致進(jìn)入右側(cè)的 Run 標(biāo)簽, 在 Deploy to CITA 中填入相關(guān)信息勾選 Auto ValidUntilBlock 則發(fā)送交易前會自動(dòng)更新 validUntilBlock 字段勾選 store ABI on chain 則會在合約部署成功后將合約 ABI 存儲到 CITA 上此處特別注意 Quota 的設(shè)置, 一般合約需要較多 Quota, 若 quota 不足, 在交易信息打印的時(shí)候可以查看 Error Message 獲知點(diǎn)擊 Load Contracts 加載當(dāng)前編譯完成的合約, 并選擇要部署的合約點(diǎn)擊 Deploy to CITA 發(fā)起部署合約的交易觀察控制臺的輸出, 交易詳細(xì)信息會顯示在控制臺上, 當(dāng)流程結(jié)束時(shí), 會輸出交易 hash 和合約地址, 并且以鏈接形式支持到 Microscope 查看
DApp 及智能合約開發(fā)實(shí)例
First Forever 是一個(gè)DApp demo嘁圈,展示了在 CITA 上開發(fā)一個(gè)最小可用的 DApp 的完整流程省骂。
FIrst Forever 地址:
https://github.com/citahub/first-forever-demo/blob/develop/README-CN.md
以下是區(qū)塊鏈DApp的開發(fā)步驟示意圖:
在該項(xiàng)目中使用了一個(gè)簡單的可以存儲用戶提交內(nèi)容的智能合約,源碼:SimpleStore
地址:
https://github.com/citahub/first-forever-demo/blob/develop/src/contracts/SimpleStore.sol
更詳細(xì)的介紹看:如何動(dòng)手做一個(gè)DApp
地址:https://github.com/citahub/first-forever-demo/blob/develop/README-CN.md
3
智能合約安全性
參考視頻
[https://www.bilibili.com/video/av58299098]
因?yàn)橹悄芎霞s是不可逆的最住,所以他的交易一旦形成钞澳,是無法回退的。在這種情形下涨缚,智能合約的安全性尤為重要轧粟。以下先介紹幾種合約常見的合約安全性隱患,然后會給出改善他們的方法脓魏。
智能合約溢出型漏洞
16bit 整數(shù):0x0000逃延,0x0001,0x0002轧拄,…揽祥,0xfffd,0xffff
0x8000 + 0x8000 = 0x10000 = 0x0000 = 0
0xffff + 0x0003 = 0x10002 = 0x0002 = 2
0x0000 - 0x0001 = 0xffff = -1 = 65535
這個(gè)函數(shù)想要做到的是把 msg.sender 在合約中的 token 轉(zhuǎn)給多個(gè)人檩电,amount += _value[j];這個(gè)操作會存在溢出的風(fēng)險(xiǎn)拄丰,如果在加的時(shí)候出現(xiàn)狀況 amount = 0x8000 + 0x8000 = 0,那么在后面一步的判斷 require(balanceOf[msg.sender] >= amount);中會出現(xiàn)的實(shí)際判斷的是balanceOf[msg.sender] >= 0那么可以從空的賬戶中把錢轉(zhuǎn)出俐末。
代碼注入漏洞
可以把這個(gè)合約本身擁有的代幣偷走轉(zhuǎn)給別的用戶料按,因?yàn)閷τ趀xtraData 來說,自由度非常高卓箫,_spender.call(_extraData)可以是任何一個(gè)地址調(diào)用任何一個(gè)函數(shù)载矿。
itchyDAOin MakerDAO 投票系統(tǒng)
這個(gè)主要是以一個(gè)比較復(fù)雜的例子來給學(xué)員講合約中函數(shù)調(diào)用需要知道的地方,暗示智能合約還是比較難以把控的烹卒,需要多學(xué)習(xí)
以下是一個(gè)在 MakerDAO 中的投票系統(tǒng)闷盔,在這個(gè)投票系統(tǒng)中,一個(gè)sender 需要根據(jù)自己的權(quán)重對一個(gè)提案進(jìn)行投票旅急。
以下是投票函數(shù)逢勾,在投票以后把票數(shù)進(jìn)行 addWeight 和 subWeight 操作。
最后一步是在 lock 一種幣藐吮,在 lock 以后可以進(jìn)行投票操作溺拱,在投票完成以后逃贝,可以 free 從而退回自己的幣。
4
智能合約場景
長遠(yuǎn)看迫摔,遵循標(biāo)準(zhǔn)有很多不應(yīng)忽視的益處沐扳。首先,如果遵照某個(gè)標(biāo)準(zhǔn)生成代幣句占,那么每個(gè)人都會知道該代幣的基礎(chǔ)功能沪摄,并知道如何與之交互,因此就會有更多信任辖众。去中心化程序(DApps)可以直接辨別出其代幣特征卓起,并通過特定的 UI 來與其打交道和敬。另外凹炸,一種代幣智能合約的標(biāo)準(zhǔn)實(shí)現(xiàn)已經(jīng)被社區(qū)開發(fā)出來,它采用類似 OpenZeppelin 的架構(gòu)昼弟。這種實(shí)現(xiàn)已經(jīng)被很多大神驗(yàn)證過啤它,可以用來作為代幣開發(fā)的起點(diǎn)。
本文中會從頭開始提供一個(gè)不完整的舱痘,但是遵循 ERC20 標(biāo)準(zhǔn)的变骡,基礎(chǔ)版的代幣實(shí)現(xiàn),然后將它轉(zhuǎn)換成遵循 ERC721 標(biāo)準(zhǔn)的實(shí)現(xiàn)芭逝。這樣就能讓讀者看出兩個(gè)標(biāo)準(zhǔn)之間的不同塌碌。
出發(fā)點(diǎn)是希望大家了解代幣是如何工作的,其過程并不是一個(gè)黑箱旬盯;另外台妆,對于 ERC20 這個(gè)標(biāo)準(zhǔn),盡管它至少已經(jīng)被廣泛接受兩年以上胖翰,如果只是從標(biāo)準(zhǔn)框架簡單地生成自己的代幣接剩,也還會存在某些不易發(fā)現(xiàn)的故障點(diǎn)。
ERC20 標(biāo)準(zhǔn)
ERC20(https://theethereum.wiki/w/index.php/ERC20_Token_Standard)是為同質(zhì)(Fungible)代幣標(biāo)準(zhǔn)設(shè)立的標(biāo)準(zhǔn)萨咳,可以被其它應(yīng)用(從錢包到去中心化交易所)重復(fù)使用懊缺。同質(zhì)意味著可以用同類的代幣互換,換句話說培他,所有的代幣都是等價(jià)的(就像錢幣鹃两,某一美金和其它美金之間沒有區(qū)別)。而一個(gè)非同質(zhì)代幣(Non-fungible Token)代表一種特定價(jià)值(例如房屋舀凛,財(cái)產(chǎn)怔毛,藝術(shù)品等)。同質(zhì)代幣有其內(nèi)在價(jià)值腾降,而非同質(zhì)代幣只是一種價(jià)值智能合約的代表拣度。
要提供符合ERC20標(biāo)準(zhǔn)的代幣,需要實(shí)現(xiàn)如下功能和事件:
標(biāo)準(zhǔn)不提供功能的實(shí)現(xiàn),這是因?yàn)榇蠹铱梢杂米约合矚g的方式寫出任何代碼抗果,如果不需要提供某些功能只需要按照標(biāo)準(zhǔn)(https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20.md)返回 null/false 的值就可以了筋帖。
注意:這里并不很強(qiáng)調(diào)代碼,大家只需了解內(nèi)部機(jī)理冤馏,全部代碼將會在文末附上鏈接日麸。
實(shí)現(xiàn)
首先,需要給代幣起一個(gè)名字逮光,因此會采用一個(gè)公有變量(Public Variable):
string public name = “Our Tutorial Coin”;
然后給代幣起一個(gè)代號:
string public symbol = “OTC”;
當(dāng)然還要有具體小數(shù)位數(shù):
uint8 public decimals = 2;
因?yàn)?Solidity 并不完全支持浮點(diǎn)數(shù)代箭,因此必須把所有數(shù)表示成整數(shù)。例如涕刚,對于一個(gè)數(shù)字 “123456”嗡综,如果使用 2 位小數(shù),則代表 “1234.56”杜漠;如果采用4位小數(shù)极景,則代表 “12.3456”。0 位小數(shù)代表代幣不可分驾茴。而以太坊的加密幣以太幣則使用18位小數(shù)盼樟。一般地,代幣不需要使用18位小數(shù)锈至,因?yàn)樽裱艘蕴坏膽T例晨缴,也沒有什么特別的目的。
你需要統(tǒng)計(jì)一共發(fā)行了多少代幣峡捡,并跟蹤每人擁有多少:
當(dāng)然击碗,你需要從0個(gè)代幣開始,除非在代幣智能合約創(chuàng)建時(shí)候就生成了一些棋返,如下例:
totalSupply()函數(shù)只是從totalSupply變量中獲取數(shù)值:
接下來就是ERC20的神奇之處了延都,transfer()函數(shù)是將代幣從一個(gè)地址發(fā)送到另外一個(gè)地址的函數(shù):
以上基本就是 ERC20 代幣標(biāo)準(zhǔn)的核心內(nèi)容。
鑒于 ERC20 還存在其他一些問題睛竣,更安全容錯(cuò)的transferFrom()實(shí)現(xiàn)和其它方案被發(fā)布出來(如之前所說晰房,該標(biāo)準(zhǔn)只是一些功能原型和行為定義,具體細(xì)節(jié)則靠開發(fā)者自己實(shí)現(xiàn))射沟,并正在討論中殊者,其中就包括
ERC223(https://github.com/ethereum/EIPs/issues/223)ERC777(https://github.com/ethereum/EIPs/issues/777)
ERC223 方案的動(dòng)機(jī)是避免將代幣發(fā)送到錯(cuò)誤地址或者不支持這種代幣的合約上,成千上萬的金錢因?yàn)樯鲜鲈騺G失验夯,這一需求作為以太坊后續(xù)開發(fā)功能的第 223 條記錄第 223 條記錄在案猖吴。ERC777 標(biāo)準(zhǔn)在支持其它功能的同時(shí),對接收地址進(jìn)行“即將收到代幣”的提醒功能挥转,ERC777 方案看起來很有可能替代 ERC20.
ERC721標(biāo)準(zhǔn)
ERC721目前看海蔽,ERC721 跟 ERC20 及其近親系列有本質(zhì)上的不同共屈。ERC721 中,代幣都是唯一的党窜。ERC721 提出來后的眾多使用案例中拗引,CryptoKitties,這款使用ERC721標(biāo)準(zhǔn)實(shí)現(xiàn)的收集虛擬貓游戲使得它備受矚目幌衣。以太貓游戲?qū)嶋H就是智能合約中的非同質(zhì)代幣 (non-fungible token)矾削,并在游戲中用貓的形象來表現(xiàn)出來。
如果想將一個(gè) ERC20 合約轉(zhuǎn)變成 ERC721 合約豁护,我們需要知道 ERC721 是如何跟蹤代幣的哼凯。在 ERC20 中,每個(gè)地址都有一個(gè)賬目表楚里,而在 ERC721 合約中断部,每個(gè)地址都有一個(gè)代幣列表:
mapping(address => uint[]) internal listOfOwnerTokens;
由于 Solidity 自身限制,不支持對隊(duì)列進(jìn)行 indexOF()的操作腻豌,我們不得不手動(dòng)進(jìn)行隊(duì)列代幣跟蹤:
mapping(uint => uint) internal tokenIndexInOwnerArray;
當(dāng)然可以用自己實(shí)現(xiàn)的代碼庫來發(fā)現(xiàn)元素的索引家坎,考慮到索引時(shí)間有可能很長嘱能,最佳實(shí)踐還是采用映射方式吝梅。
為了更容易跟蹤代幣,還可以為代幣的擁有者設(shè)置一個(gè)映射表:
mapping(uint => address) internal tokenIdToOwner;
以上就是兩個(gè)標(biāo)準(zhǔn)之間最大的不同惹骂,ERC721 中的 transfer()函數(shù)會為代幣設(shè)置新的擁有者:
盡管代碼比較長苏携,但卻是轉(zhuǎn)移代幣流程中必不可少的步驟。
還必須注意对粪,ERC721 也支持approve()和transferFrom()函數(shù)右冻,因此我們必須在 transfer 函數(shù)內(nèi)部加上其它限制指令,這樣一來著拭,當(dāng)某個(gè)代幣有了新的擁有者纱扭,之前的被授權(quán)地址就無法其代幣進(jìn)行轉(zhuǎn)移操作,代碼如下:
挖礦基于以上兩種標(biāo)準(zhǔn)儡遮,可能面對同一種需求乳蛾,要么產(chǎn)生同質(zhì)代幣,要么產(chǎn)生非同質(zhì)代幣鄙币,一般都會用一個(gè)叫做Mint()的函數(shù)完成肃叶。
實(shí)現(xiàn)以上功能函數(shù)的代碼如下:
用任意一個(gè)數(shù)字產(chǎn)生一個(gè)新代幣,根據(jù)不同應(yīng)用場景十嘿,一般在合約內(nèi)部只會授權(quán)部分地址可以對它進(jìn)行鑄幣(mint)操作因惭。
這里需要注意mint()函數(shù)并沒有出現(xiàn)在協(xié)議標(biāo)準(zhǔn)定義中,而是我們添加上去的绩衷,也就是說我們可以對標(biāo)準(zhǔn)進(jìn)行擴(kuò)充蹦魔,添加其它對代幣的必要操作激率。例如,可以添加用以太幣來買賣代幣的系統(tǒng)勿决,或者刪除不再需要代幣的功能柱搜。
來源:溪塔科技
本文來自互聯(lián)網(wǎng),如有侵權(quán)請與我們聯(lián)系刪除剥险。