У цій статті буде розглянуто питання контролю доступу в смартконтрактах Rust з двох аспектів: видимість методів контракту та контроль доступу до привілейованих функцій.
1. Видимість функцій смартконтракту
При написанні смартконтрактів, вказавши видимість функції, можна контролювати, хто може викликати конкретну функцію, таким чином захищаючи ключові частини контракту.
Наприклад, безпекова подія, що сталася на біржі 18 червня 2020 року. Через неправильне налаштування контролю доступу до ключових функцій контракту, активи користувачів опинилися під загрозою. Цей випадок підкреслює важливість правильного налаштування видимості функцій контракту.
У смартконтрактах Rust основні типи видимості функцій такі:
pub fn: вказує на те, що цей метод є публічним, є частиною інтерфейсу контракту, і будь-хто може викликати його ззовні.
fn: Якщо не вказано явно pub, це означає, що ця функція може бути викликана тільки зсередини контракту іншими функціями.
pub(crate) fn: Обмежити виклик методу в межах внутрішнього діапазону crate.
Інший спосіб визначити метод як внутрішній — це визначити його в кодовому блоці impl Contract, який не має модифікатора #[near_bindgen].
Для функцій зворотного виклику їх потрібно встановити як публічні властивості, щоб їх можна було викликати через функцію call. Одночасно потрібно забезпечити, щоб функції зворотного виклику не могли викликатися довільно, для цього можна використовувати макрос #[private].
Слід зазначити, що в Rust за замовчуванням все є приватним, за винятком підпроектів у pub Trait та змінних у pub Enum, які за замовчуванням є публічними.
!
2. Контроль доступу до функцій з привілейованим доступом
Окрім видимості функцій, також необхідно з семантичного рівня створити повноцінний механізм контролю доступу в білому списку. Деякі привілейовані функції (як-от ініціалізація контракту, активація/призупинення тощо) можуть бути викликані лише власником контракту.
У смартконтрактах на Rust можна реалізувати функціонал, подібний до модифікатора onlyOwner у Solidity:
Використання цього методу дозволяє здійснити контроль доступу до функцій привілейованості, забезпечуючи, що лише власник контракту може повноцінно виконувати ці функції. На основі цього принципу можна налаштувати більш складний механізм білого списку для реалізації детального контролю доступу до груп.
!
3. Інші методи контролю доступу
Окрім вищезазначених методів, у Rust смартконтрактах також є інші способи контролю доступу, такі як контроль часу виклику контракту, механізм багаторазового підпису та реалізація управління (DAO) тощо. Ці питання будуть детально розглянуті в наступних статтях.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
10 лайків
Нагородити
10
4
Поділіться
Прокоментувати
0/400
ProxyCollector
· 5год тому
Знову пастка з налаштуваннями прав, хто попався - той і нещасливий.
Контроль доступу до смартконтрактів Rust: практика видимості функцій та привілейованого доступу
Контроль доступу в смартконтрактах Rust
У цій статті буде розглянуто питання контролю доступу в смартконтрактах Rust з двох аспектів: видимість методів контракту та контроль доступу до привілейованих функцій.
1. Видимість функцій смартконтракту
При написанні смартконтрактів, вказавши видимість функції, можна контролювати, хто може викликати конкретну функцію, таким чином захищаючи ключові частини контракту.
Наприклад, безпекова подія, що сталася на біржі 18 червня 2020 року. Через неправильне налаштування контролю доступу до ключових функцій контракту, активи користувачів опинилися під загрозою. Цей випадок підкреслює важливість правильного налаштування видимості функцій контракту.
У смартконтрактах Rust основні типи видимості функцій такі:
Інший спосіб визначити метод як внутрішній — це визначити його в кодовому блоці impl Contract, який не має модифікатора #[near_bindgen].
Для функцій зворотного виклику їх потрібно встановити як публічні властивості, щоб їх можна було викликати через функцію call. Одночасно потрібно забезпечити, щоб функції зворотного виклику не могли викликатися довільно, для цього можна використовувати макрос #[private].
Слід зазначити, що в Rust за замовчуванням все є приватним, за винятком підпроектів у pub Trait та змінних у pub Enum, які за замовчуванням є публічними.
!
2. Контроль доступу до функцій з привілейованим доступом
Окрім видимості функцій, також необхідно з семантичного рівня створити повноцінний механізм контролю доступу в білому списку. Деякі привілейовані функції (як-от ініціалізація контракту, активація/призупинення тощо) можуть бути викликані лише власником контракту.
У смартконтрактах на Rust можна реалізувати функціонал, подібний до модифікатора onlyOwner у Solidity:
іржа публічна ознака Власник { 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. Інші методи контролю доступу
Окрім вищезазначених методів, у Rust смартконтрактах також є інші способи контролю доступу, такі як контроль часу виклику контракту, механізм багаторазового підпису та реалізація управління (DAO) тощо. Ці питання будуть детально розглянуті в наступних статтях.
!