開發者可以通過遵循以上安全實踐，避免常見的錯誤和漏洞，有效提升其合約的安全性。
原用標題：熱度暴漲的 SOL 為何狂飆 4 倍？ 開發者構建 Solana 專案需要注意哪些安全問題？
封面：Solana
自今年年初以來，Solana 的生態一直處於快速發展的狀態，尤其是 SOL 在過去幾周內大幅上漲，讓大家將目光再次轉移到這個老牌專案。 Marinade Finance、Lido 和 Jito 等流動性質押專案的推出讓 Solana 的 TVL 相比年初增長了 1 倍。 Solana 與 Visa、Shopify 等實體的合作讓用戶和投資者看到了 Solana 生態與現實消費者結合的巨大潛力。
目前，越來越多的開發者參與到 Solana 的生態構建中。 10 月，Beosin 受邀成為 Solana Hackerhouse Shanghai 的合作夥伴，為開發者分享安全開發經驗。 本文 Beosin 將為大家講解開發 Solana 智慧合約的安全實踐，加強專案方智慧合約的安全性。
Solana 帳戶特點及風險
在 Solana 的設計中，所有的資訊都存儲在帳戶（Account）物件中，而帳戶類型分為三類：
1. 資料帳戶，用於儲存數據。 資料帳戶又分為系統所有帳戶和程式派生帳戶（Program Derived Address）
2. 程式帳戶，用於存儲可執行程式，即使用者/Solana 官方開發並部署的智能合約。 值得注意的是，Solana 的智慧合約是可以被更新/銷毀的。
3. 原生帳戶，指 Solana 上的原生程式，它們是由節點在部署時生成的智慧合約，普通使用者無法更新/銷毀，但和其它智慧合約一樣，可以被合約/RPC 調用。
注：Solana 的程式（Program）本質上和其它區塊鏈的智能合約（Contract）類似，下文的程式等同於智能合約。
以下是 Solana 帳戶與乙太坊帳戶的對比：
從上圖可以看到，Solana 獨特的帳戶模型將數據資源和執行程式分離，使其可以快速處理併發交易，但同時開發者如何處理好帳戶之間的關係成為了一項安全挑戰。 開發者需要注意以下有關賬戶的風險：
1. 帳戶依賴校驗缺失
對於一個 Solana 項目來說，不同的業務場景會有不同的分層架構，並且分層架構之間的數據帳戶存在依賴關係。 開發者需要非常清楚合約與數據帳戶之間的依賴關係並加入約束，避免攻擊者通過偽造數據進行攻擊。
2. 帳戶數據校驗缺失
當執行某些 Instructions 時，需要對帳戶進行校驗，以確定交互的數據物件/程式是正確的。 Solana 的合約開發者可能會忽略對交互的數據/程式位址進行一致性檢查。
如上圖所示，主程式在調用外部程式前應驗證外部程式的位址是否正確。 否則駭客可以提供惡意的外部程序進行攻擊。
Solana 智慧合約安全實踐
開發者除了避免圍繞 Solana 帳戶產生的風險，遵循以下安全實踐可以提高在開發智慧合約、運行專案時的安全性：
1. 設置緊急模式
任何智慧合約都可能存在未被發現的漏洞，因此，專案的開發團隊應在合約中設置緊急模式並制定風險應對方案，以便在風險出現時能強制暫停合約業務並修復漏洞。
impl Mode{ pub fn transform(&mut self, desired_mode: Mode) -> Result<()>{ let new_mode = match self{ Mode::Normal => match desired_mode { Mode::Normal => None, Mode::Paused => Some(Mode::Paused), Mode::Terminated => Some(Mode::Terminated), }, Mode::Paused => match desired_mode { Mode::Normal => Some(Mode::Normal), Mode::Paused => None, Mode::Terminated => None, }, Mode::Terminated => None, }; if let Some(mode) = new_mode{ *self = mode; Ok(()) }else{ Err(StakingError::IllegalModeTransformation.into()) } }}2. 盡量使用 Anchor 開發框架
Anchor 框架已有許多成熟的代碼模版，並支援對 Solana 的大部分特性進行檢查，可以避免很多易忽略的細節錯誤，比如跨程式調用時使用 Program<『info， T> 類型，Anchor 會幫助開發者檢查調用的外部程序的位址。 因此，對於 Solana 的合約開發者來說，我們建議在大部分的情況下考慮使用 Anchor 框架進行合約開發。
3. 注意數學相關問題
由於 Rust 在處理整數除法時會約去小數部分，因此在做複雜計算時開發者需要留意結果的精度問題。 開發者應結合實際場景對計算結果向上/向下取整，或者對計算的數據做特別處理。 對於整形溢出問題，建議開發者使用 SafeMath 或者在 Cargo.toml 中添加發佈模式的溢出檢查。
4. 重入檢查
Solana 支援跨程序調用，但深度目前限製為 4。 此限制可以防止程式可能從中間狀態調用另一程式而忽略其自身可能會被回調到的情況。 因此 Solana 的智慧合約難以被重入攻擊，但還是建議開發者應當進行重入檢查。
5. Solana cli 關閉程式帳戶
開發者如果使用 Solana cli 關閉程式，那麼需注意後續將無法通過升級或重新部署的方式還原該程序帳戶。
6. 注意區分類型
在 Solana 合約開發中，帳戶數據本質上只是一個字節陣列，程式將其反序列化為自訂的帳戶類型。 如果沒有實現明確區分帳戶類型的方法，程式可能會使用到預期之外的賬戶數據。
#[program]pub mod type_cosplay_insecure { use super::*; pub fn admin_instruction(ctx: Context<AdminInstruction>) -> Result<()> { ... }}#[derive(Accounts)]pub struct AdminInstruction<'info> { admin_config: UncheckedAccount<'info>, admin: Signer<'info>,}#[derive(BorshSerialize, BorshDeserialize)]pub struct AdminConfig { admin: Pubkey,}#[derive(BorshSerialize, BorshDeserialize)]pub struct UserConfig { user: Pubkey,}在上面的案例中，AdminConfig 和 UserConfig 類型具有相同的數據結構。 這意味著 UserConfig 類型可以作為 AdminConfig 傳入。 只要存儲在賬戶數據中的公鑰與簽署交易的管理員匹配， admin_instruction 指令就會繼續執行，即使簽名者實際上不是 Admin。
對此，開發者應該進行鑒權然後使用 Account<'info， AdminConfig> 指定 admin_config 類型為 AdminConfig，然後使用 #[account（has_one=xxx）]，檢查交易上下文的帳戶許可權依賴，如下所示：
...#[derive(Accounts)]pub struct AdminInstruction<'info> { #[account(has_one = admin)] admin_config: Account<'info, AdminConfig>, admin: Signer<'info>,}...7. 對智慧合約進行審計
智慧合約審計是通過對智慧合約代碼進行系統的測試和審查，盡可能發現代碼中的潛在安全漏洞，排除安全風險，確保代碼沒有業務邏輯漏洞，符合預期運行流程和結果。 此前 Beosin 已完成對 Solana 生態 NFT 專案 Space Runners 的安全審計，保障專案安全運行。
總結
Solana 的開發者社區正在不斷壯大，Beosin 之前支援的 Solana Hyperdrive 全球線上駭客松已經順利開展，Beosin 也為整個 Solana 生態提供安全説明。 由於 Solana 獨特的帳戶設計和採用 Rust 作為開發語言，開發者在進行相關智慧合約開發時，有關代碼安全方面可能存在疏漏之處。 開發者可以通過遵循以上安全實踐，避免常見的錯誤和漏洞，有效提升其合約的安全性。 此前 Beosin 也對 Solana 生態相關項目被攻擊事件進行分析：用一千萬撬動上億資金？ Solana 生態 Mango 協定遭受駭客攻擊事件分析。
免責聲明：作為區塊鏈資訊平臺，本站所發佈文章僅代表作者及嘉賓個人觀點，與 Web3Caff 立場無關。 文章內的資訊僅供參考，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。
