Ця стаття розгляне контроль доступу в смартконтрактах Rust з двох точок зору:
Видимість методів смартконтракту
Контроль доступу до функцій привілеїв
1. Видимість функцій смартконтракту
У розробці смартконтрактів правильне налаштування видимості функцій є вкрай важливим. Наприклад, у випадку безпеки біржі Bancor Network 18 червня 2020 року, через неправильне встановлення ключової функції передачі активів як public, активи користувачів опинилися під загрозою.
У Rust смартконтрактах контроль видимості функцій також важливий. Макрос #[near_bindgen] у NEAR SDK визначає такі види видимості:
pub fn: публічна функція, може бути викликана ззовні контракту
fn: може бути викликано лише всередині смартконтракту
pub(crate) fn: обмежити виклики всередині crate
Інший спосіб налаштування методу internal - це визначення окремого блоку коду impl Contract без використання #[near_bindgen] модифікатора.
Для функцій зворотного виклику потрібно встановити їх як public, але при цьому обмежити виклики лише з самого контракту. Для досягнення цієї мети можна використовувати макрос #[private].
Слід зазначити, що за замовчуванням у Rust все є приватним, за винятком елементів у pub Trait і pub Enum.
!
2. Контроль доступу до функцій привілеїв
Окрім видимості функцій, також потрібно створити повний механізм білого списку контролю доступу. Подібно до модифікатора onlyOwner у Solidity, у контракті Rust також можна реалізувати власний Trait для контролю доступу до привілейованих функцій:
Це може обмежити виклик певних функцій привілеїв лише власником. На основі цього принципу можна налаштувати більш складні білі списки та груповий контроль доступу.
!
3. Інші методи контролю доступу
Є й інші методи контролю доступу, такі як контроль часу виклику контракту, механізм багаторазового підпису, реалізація DAO тощо, які будуть детально розглянуті в наступних статтях.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
17 лайків
Нагородити
17
4
Репост
Поділіться
Прокоментувати
0/400
MetaNomad
· 08-04 05:07
rust новачок питає, який з них безпечніший?
Переглянути оригіналвідповісти на0
NftPhilanthropist
· 08-04 05:02
*зітхання* ще один проблемний випадок безпеки, бо хтось забув базові права... коли вже розробники навчаться уважно мінтити, смх
Переглянути оригіналвідповісти на0
BearMarketGardener
· 08-04 04:57
Якщо управління правами зірветься, буде кінець.
Переглянути оригіналвідповісти на0
RuntimeError
· 08-04 04:45
Некоректний контроль доступу, дебагging на колінах.
Керування доступом до смартконтрактів Rust: видимість функцій та управління привілейованим доступом
Контроль доступу в смартконтрактах Rust
Ця стаття розгляне контроль доступу в смартконтрактах Rust з двох точок зору:
1. Видимість функцій смартконтракту
У розробці смартконтрактів правильне налаштування видимості функцій є вкрай важливим. Наприклад, у випадку безпеки біржі Bancor Network 18 червня 2020 року, через неправильне встановлення ключової функції передачі активів як public, активи користувачів опинилися під загрозою.
У Rust смартконтрактах контроль видимості функцій також важливий. Макрос #[near_bindgen] у NEAR SDK визначає такі види видимості:
Інший спосіб налаштування методу internal - це визначення окремого блоку коду impl Contract без використання #[near_bindgen] модифікатора.
Для функцій зворотного виклику потрібно встановити їх як public, але при цьому обмежити виклики лише з самого контракту. Для досягнення цієї мети можна використовувати макрос #[private].
Слід зазначити, що за замовчуванням у Rust все є приватним, за винятком елементів у pub Trait і pub Enum.
!
2. Контроль доступу до функцій привілеїв
Окрім видимості функцій, також потрібно створити повний механізм білого списку контролю доступу. Подібно до модифікатора onlyOwner у Solidity, у контракті Rust також можна реалізувати власний Trait для контролю доступу до привілейованих функцій:
іржа публічний трейд Власний { fn assert_owner(&self) { assert_eq!(env::p redecessor_account_id(), self.get_ owner()); } fn get_owner(&self) -> AccountId; fn set_owner(&mut self, власник: AccountId); }
Це може обмежити виклик певних функцій привілеїв лише власником. На основі цього принципу можна налаштувати більш складні білі списки та груповий контроль доступу.
!
3. Інші методи контролю доступу
Є й інші методи контролю доступу, такі як контроль часу виклику контракту, механізм багаторазового підпису, реалізація DAO тощо, які будуть детально розглянуті в наступних статтях.
!
!
!
!
!
!
!
!