通過對Solidity官方文檔的學習，發現投票案例代碼有些不夠嚴謹，簡要做以下說明。

1. 調用者問題

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

表1 Voter對象屬性對應的默認值

類型屬性取值

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

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

2. 提案不存在

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

注意：

在delegate函數中也出現了上面兩個問題，具體不再描述。

3. 提案票數相同

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

代碼優化請點這里查看

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。