通過對Solidity官方文檔的學(xué)習(xí)，發(fā)現(xiàn)投票案例代碼有些不夠嚴謹，簡要做以下說明。

1. 調(diào)用者問題

在vote函數(shù)中，如果是一個沒有投票權(quán)的地址（假設(shè)A地址）調(diào)用了vote 函數(shù)，代碼也能順利執(zhí)行。
首先，A地址雖然沒有被chairperson 賦予投票權(quán)，但是代碼也能正常獲取Voter 對象sender ，只不過sender的所有屬性值是對應(yīng)類型的默認值，函數(shù)可以繼續(xù)執(zhí)行。

表1 Voter對象屬性對應(yīng)的默認值

類型屬性取值

uint	weight	0
bool	voted	false
uint	vote	0
address	delegate	0x0

接下來，代碼將A 的voted設(shè)為true (sender.voted = true;)，權(quán)重被累加到了對應(yīng)的提案票數(shù)上，我們會發(fā)現(xiàn)，這對于投票結(jié)果并沒有什么影響（A 的weight 值為0），但是因為此時A.voted = true ，當(dāng)主持人chairperson 試圖給A 賦予投票權(quán)時將無法正常執(zhí)行，這就導(dǎo)致A永久不能擁有投票權(quán)，顯然這是不合適的。

2. 提案不存在

同樣在vote函數(shù)中，如果調(diào)用者輸入的參數(shù)proposal 并不存在(即proposal >= proposals.length)，導(dǎo)致數(shù)組越界，雖然這不會給合約的安全性帶來問題，但是會造成調(diào)用執(zhí)行失敗，顯然這不是我們希望看到的。

注意：

在delegate函數(shù)中也出現(xiàn)了上面兩個問題，具體不再描述。

3. 提案票數(shù)相同

在獲取最高票數(shù)的提案編號winningProposal 和提案名稱winnerName 的方法中，如果出現(xiàn)兩個或者多個提案的票數(shù)最高且相同時，只會返回編號靠前的提案編號。

代碼優(yōu)化請點這里查看

總結(jié)

以上是生活随笔為你收集整理的Solidity智能合约案例——投票存在的问题的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。