2025年區(qū)塊鏈工程師職業(yè)能力測試卷：智能合約設計與安全防范實戰(zhàn)試題考試時間：______分鐘總分：______分姓名：______一、選擇題（請將正確選項的字母填入括號內）1.智能合約在區(qū)塊鏈上運行的主要優(yōu)勢之一是（）。A.可信執(zhí)行B.高性能計算C.離線工作D.易于修改2.在Solidity中，用于存儲合約地址的內置類型是（）。A.`uint`B.`address`C.`struct`D.`bool`3.以下關于EVM（以太坊虛擬機）的說法中，錯誤的是（）。A.EVM是運行以太坊智能合約的虛擬機。B.EVM的每一步操作都消耗Gas。C.EVM是圖靈完備的。D.EVM的執(zhí)行環(huán)境是中心化的。4.Solidity中的`view`和`pure`函數(shù)的主要區(qū)別在于（）。A.`view`函數(shù)可以修改狀態(tài)變量，`pure`不能。B.`view`函數(shù)讀取狀態(tài)變量不消耗Gas，`pure`函數(shù)讀取消耗Gas。C.`view`函數(shù)可以調用`pure`函數(shù)，`pure`函數(shù)不能調用`view`函數(shù)。D.兩者沒有區(qū)別，可以互換使用。5.當一個函數(shù)被標記為`public`時，意味著（）。A.該函數(shù)只能在合約內部訪問。B.該函數(shù)可以被任何地址調用，但只能讀取狀態(tài)。C.該函數(shù)可以被任何地址調用，并且可以修改狀態(tài)。D.該函數(shù)只能在構造函數(shù)中調用。6.以下哪種情況可能導致智能合約的整數(shù)溢出（Underflow）漏洞？（）A.將一個負數(shù)與一個很大的正數(shù)相加。B.將一個變量賦值為它能夠表示的最大數(shù)值，然后再加上1。C.對一個無符號整數(shù)進行右移操作。D.將一個地址類型的值錯誤地當作整數(shù)進行算術運算。7.在智能合約中，`require`、`assert`和`revert`函數(shù)的主要區(qū)別在于（）。A.`require`用于正常流程控制，`assert`和`revert`用于錯誤處理。B.只有`require`可以接受字符串參數(shù)用于提示。C.`assert`用于預期永遠不會發(fā)生的情況，`require`用于檢查業(yè)務邏輯條件。D.使用`revert`比使用`require`或`assert`消耗更多的Gas。8.以下關于智能合約事件（Events）的說法中，錯誤的是（）。A.事件是向外部世界傳遞信息的機制。B.事件在合約部署時占用Gas。C.事件可以存儲數(shù)據(jù)，并在之后被檢索。D.事件數(shù)據(jù)是不可變的。9.重入（Reentrancy）攻擊通常利用智能合約的哪種特性？（）A.修改狀態(tài)變量B.發(fā)送以太幣C.并發(fā)執(zhí)行D.多重簽名10.以下哪種模式通常用于提高智能合約的可擴展性？（）A.單例模式B.工廠模式C.代理模式D.觀察者模式二、填空題1.智能合約一旦部署到區(qū)塊鏈上，其代碼通常是________修改的。2.Solidity中，`mapping(keyType=>valueType)`定義了一種________數(shù)據(jù)結構。3.為了防止整數(shù)溢出，可以使用Solidity內置的`SafeMath`庫或使用開平方加一的方法來計算最大整數(shù)，即`MAX_VALUE=2(8*256-1)-1`，其中8代表每個`uint`字節(jié)的字節(jié)數(shù)。4.當智能合約的Gas耗盡時，通常會觸發(fā)一個________事件。5.在設計去中心化自治組織（DAO）時，投票權通常與________持有量相關聯(lián)。6.為了防止時間戳依賴（TimestampDependence）攻擊，可以采用________或鏈上隨機數(shù)服務。7.使用`transfer()`或`send()`發(fā)送以太幣時，如果接收方合約中存在重入點，可能會導致發(fā)送方資金損失，這是________漏洞的一種變體。8.ERC-20標準定義了代幣的接口，其中`totalSupply()`函數(shù)返回代幣的________量。9.在進行智能合約安全審計時，靜態(tài)分析工具主要在________階段對代碼進行分析。10.為了限制外部調用者修改合約狀態(tài)的成本，可以設計智能合約只暴露必要的________函數(shù)。三、簡答題1.請簡述智能合約與傳統(tǒng)中心化程序在執(zhí)行環(huán)境、數(shù)據(jù)持久性、透明度和修改性方面的主要區(qū)別。2.什么是整數(shù)溢出/下溢漏洞？請列舉至少兩種在Solidity中防范該漏洞的方法。3.解釋一下“時間戳依賴”漏洞的含義及其潛在風險。在智能合約設計中應如何規(guī)避？4.請描述一下“重入攻擊”的原理，并說明如何通過`checks-effects-interactions`模式來防范。5.在設計一個公開的代幣兌換合約時，需要考慮哪些安全因素？請至少列舉三項。四、代碼分析題1.分析以下Solidity代碼片段，指出其中存在的安全漏洞或潛在風險，并簡要說明原因。```soliditypragmasolidity^0.8.0;contractSimpleBank{mapping(address=>uint)publicbalances;functiondeposit()externalpayable{balances[msg.sender]+=msg.value;}functionwithdraw(uintamount)external{require(balances[msg.sender]>=amount,"Insufficientbalance");balances[msg.sender]-=amount;payable(msg.sender).transfer(amount);}}```2.分析以下Solidity代碼片段，假設合約部署時傳入了一個初始管理員地址。`renounceOwnership`函數(shù)的作用是什么？這個函數(shù)的設計存在什么潛在風險？```soliditypragmasolidity^0.8.0;import"@openzeppelin/contracts/access/Ownable.sol";contractMyContractisOwnable{//...otherstatevariables...constructor(address_initialOwner){_transferOwnership(_initialOwner);}functionrenounceOwnership()externaloverrideonlyOwner{_transferOwnership(address(0));}}```（注：此處假設`Ownable`合約的`_transferOwnership`和`onlyOwner`等函數(shù)已正確定義）五、設計與加固題1.假設你需要設計一個簡單的去中心化投票系統(tǒng)，投票者可以對多個候選者進行投票（每人限投一次）。請簡要描述你的設計思路，包括關鍵的數(shù)據(jù)結構、核心函數(shù)的設計（如`registerCandidate`、`vote`），并指出在設計時需要重點考慮的安全問題以及相應的防范措施。2.假設你發(fā)現(xiàn)一個現(xiàn)有的智能合約存在允許重入攻擊的風險（例如，在發(fā)送以太幣時，接收方的回調函數(shù)可以再次調用發(fā)送方的耗資函數(shù)）。請?zhí)岢鲋辽賰煞N不同的加固方案，以防止此類攻擊的發(fā)生。試卷答案一、選擇題1.A2.B3.D4.B5.C6.B7.C8.C9.D10.C二、填空題1.不可2.映射3.安全4.事件5.代幣6.偏移量7.重入8.總9.編譯10.交互三、簡答題1.解析思路：對比智能合約和中心化程序在環(huán)境（分布式vs中心化）、數(shù)據(jù)（鏈上永久vs鏈下臨時）、透明度（公開可查vs內部）、修改性（不可變vs可改）上的核心差異。*執(zhí)行環(huán)境：智能合約在區(qū)塊鏈上由網(wǎng)絡節(jié)點分布式執(zhí)行，代碼透明；中心化程序在單一服務器上執(zhí)行，環(huán)境不透明。*數(shù)據(jù)持久性：智能合約數(shù)據(jù)存儲在區(qū)塊鏈上，永久、不可篡改；中心化程序數(shù)據(jù)存儲在服務器，可隨時修改刪除。*透明度：智能合約代碼和執(zhí)行結果公開可查；中心化程序代碼通常不公開，執(zhí)行邏輯不透明。*修改性：智能合約部署后代碼不可變（或通過代理模式間接修改）；中心化程序可以隨時修改更新。2.解析思路：解釋整數(shù)溢出/下溢的概念（計算結果超出類型表示范圍），列舉原因（無符號整數(shù)加1變?yōu)?，減1變?yōu)樽畲笾?；有符號整?shù)加減溢出），說明危害（導致預期之外的值，可能引發(fā)安全漏洞），提出防范方法（使用SafeMath庫，或手動檢查邊界，開平方加一法等）。*漏洞定義：在無符號整數(shù)運算中，超出最大值變?yōu)?；在有符號整數(shù)運算中，超出正最大值變?yōu)樽钚∝摂?shù)，超出負最小值變?yōu)檎畲髷?shù)。*危害：結果錯誤，可能導致合約邏輯異?；虮还粽呃谩?防范方法：*使用OpenZeppelin等庫提供的SafeMath模塊。*手動檢查運算前是否滿足安全條件（如`a+b<=type(uint256).max-b`）。*對于平方根等運算，使用`x*x<=y`和`(x+1)*(x+1)>y`來逼近。3.解析思路：解釋時間戳依賴的概念（合約邏輯依賴于`block.timestamp`或`block.number`等鏈上時間值），說明風險（利用區(qū)塊時間戳的可預測性或微小變動制造漏洞，如雙花、投票規(guī)則異常），提出規(guī)避方法（避免使用時間戳進行關鍵判斷，使用鏈上隨機數(shù)服務，引入隨機因子）。*漏洞定義：智能合約的決策基于區(qū)塊時間戳，而區(qū)塊時間戳是礦工可影響的，可能被操縱。*危害示例：*雙花：根據(jù)時間戳決定是否扣款，攻擊者可調整時間。*投票：根據(jù)時間戳判斷是否允許投票，攻擊者可調整時間。*規(guī)避方法：*不使用時間戳進行核心邏輯判斷。*使用`blockhash`獲取臨近區(qū)塊哈希（有一定隨機性，但有區(qū)塊數(shù)限制）。*使用鏈上預言機服務（如ChainlinkVRF）獲取高質量隨機數(shù)。4.解析思路：解釋重入攻擊原理（調用方合約在接收以太幣后，可以再次調用發(fā)送方合約的耗資函數(shù)，循環(huán)調用直至發(fā)送方資金耗盡），說明觸發(fā)條件（發(fā)送方合約的耗資函數(shù)存在外部調用，且該調用可能改變狀態(tài)），闡述防范方法（`checks-effects-interactions`模式：先檢查條件->改變狀態(tài)->再進行外部調用）。*攻擊原理：發(fā)送方A調用接收方B合約的`withdraw`函數(shù)，`withdraw`先發(fā)送以太幣給A，然后調用一個第三方C合約，C合約又調回A的`withdraw`函數(shù)，A的資金被不斷抽干。*防范方法：*ChecksEffectsInteractions:在發(fā)送以太幣（或其他改變狀態(tài)的操作）之前，完成所有狀態(tài)檢查；在發(fā)送以太幣之后，完成所有外部調用。即：檢查->改變狀態(tài)->外部交互。5.解析思路：從輸入驗證、狀態(tài)管理、訪問控制、事件記錄、重入防范等多個角度思考代幣兌換合約的安全要點。*輸入驗證：確保接收的代幣地址、數(shù)量等輸入合法有效。*狀態(tài)管理：正確處理代幣余額的增減，確保原子性。*訪問控制：限制誰可以發(fā)起兌換操作，誰可以接收兌換結果。*事件記錄：記錄所有兌換操作的關鍵信息，便于追蹤。*重入防范：如果涉及發(fā)送代幣給用戶合約，需防范重入攻擊。*惡意交互防范：避免調用不可信的外部合約。*氣價考慮：為外部調用設置合理的gas限制。四、代碼分析題1.解析思路：*重入攻擊風險：`withdraw`函數(shù)先減少`balances[msg.sender]`，然后調用`payable(msg.sender).transfer(amount)`。如果接收方（`msg.sender`）是一個惡意合約，它在收到以太幣后，可以再次調用這個`withdraw`函數(shù)，導致發(fā)送方（調用者）的資金被持續(xù)抽取。*Gas限制風險：如果`msg.value`非常大，`transfer`可能會失敗，導致用戶資金被卡在合約中。*改進建議：*使用`require(balances[msg.sender]>=amount,"Insufficientbalance");`放在`transfer`之前，但這樣無法阻止重入。最好放在`transfer`之后，確認余額足夠再轉。*使用`checks-effects-interactions`模式：先檢查余額->減少余額->發(fā)送以太幣。*使用`call{value:amount}()`代替`transfer()`，可以限制gas消耗，但需要更復雜的重入防范邏輯。*使用`revert`或`selfdestruct`在轉賬失敗時立即停止執(zhí)行。2.解析思路：*`renounceOwnership`作用：該函數(shù)的作用是讓當前`owner`（合約部署者或之前設置的管理員）放棄對合約的擁有權。通過調用`_transferOwnership(address(0))`，將所有權轉移給地址`0`，這是一個無效地址，從此該合約不再有合法的所有者，任何人也無法再通過`Ownable`合約提供的標準方法（如`transferOwnership`）來獲得所有權。*潛在風險：*操作失誤：如果當前擁有者本意是想轉移所有權給其他地址，但錯誤地調用了`renounceOwnership`，將導致合約永久失效，無法再管理。*依賴失效：如果合約邏輯深度依賴`owner`地址進行某些操作授權或信息記錄，一旦所有權變?yōu)閌0`，這些依賴邏輯可能失效。*無法升級：如果合約使用了代理模式進行升級，`renounceOwnership`可能會破壞代理關系或升級機制（取決于具體實現(xiàn)）。五、設計與加固題1.解析思路：*設計思路：*數(shù)據(jù)結構：`mapping(address=>uint)voteCounts;`(記錄每個候選人的票數(shù)),`mapping(address=>bool)hasVoted;`(記錄是否已投票),`address[]candidates;`(候選人列表).*核心函數(shù)：*`functionregisterCandidate(address_candidate)public`：只有合約管理員可以調用，將`_candidate`添加到`candidates`數(shù)組中。*`functionvote(address_candidate)public`：*檢查`_candidate`是否在`candidates`列表中。*檢查`msg.sender`是否已經投過票(`hasVoted[msg.sender]`).*如果未投票，增加`_candidate`的票數(shù)(`voteCounts[_candidate]++`)，并將`hasVoted[msg.sender]`設為`true`。*安全問題與防范：*重入攻擊：`vote`函數(shù)中修改狀態(tài)(`voteCounts`,`hasVoted`)后調用了外部合約（可能），應使用`checks-effects-interactions`模式。*時間戳依賴：避免使用`block.timestamp`來決定是否允許投票，除非有特定理由并采取了防范措施。*整數(shù)溢出：票數(shù)計數(shù)可能溢出，使用`uint256`類型并考慮SafeMath或邊界檢查。*雙花：`hasVoted`狀態(tài)確保每個地址只能投票一次。*訪問控制：`registerCandidate`應限制為管理員調用。2.解析思路：*加固方案一（Checks-Effects-Interactions）：嚴格遵循`checks-effects-interactions`模式。