Переслати оригінальну назву:新公链 Nibiru 主网将上线，解析其技术特点与安全开发实践

Публічний ланцюжок першого рівня - Nibiru Chain запустив стимул airdrop наприкінці січня 2024 року. Після місяця активностей, пов'язаних з повітряним десантуванням, його спільнота зросла більш ніж утричі, налічуючи понад 500 000 підписників у Твіттері. Залучивши понад $20 млн фінансування, Nibiru Chain готова вирішити питання безпеки та швидкості роботи DeFi-додатків, потенційно конкуруючи з dYdX. Наразі Nibiru Chain планує запустити свою основну мережу цього тижня. Які технічні особливості та конкурентні переваги Nibiru Chain, як рішення Layer1, що швидко розвивається, мають технічні особливості та конкурентні переваги? Які міркування щодо безпеки слід враховувати розробникам, розробляючи проекти в її екосистемі? Сьогодні Beosin представить детальний аналіз.

Аналіз протоколу ланцюжка Nibiru

Nibiru Chain в першу чергу зосереджується на DeFi-транзакціях як на своєму основному бізнесі. Він складається з чотирьох основних компонентів:

1. Нібі-злочинці

Торгівля безстроковими контрактами в мережі, що дозволяє користувачам брати участь у торгівлі популярними криптовалютами, такими як BTC, ETH та ATOM, з кредитним плечем до 10 разів. Власники токенів $NIBI матимуть права на управління Nibi-Perps і користуватимуться знижками на торгову комісію.

1. Nibi-Swap

Протокол автоматизованого маркет-мейкера Nibiru розроблений для підтримки двох типів пулів ліквідності: пулів обміну стейблкоінів і звичайних пулів постійних продуктів.

1. $NUSD

Повністю забезпечений стейблкоїн в екосистемі Nibiru. Nibiru планує спочатку підтримувати карбування $NUSD, використовуючи $USDC і $NIBI, при цьому конкретне співвідношення визначається коефіцієнтом забезпечення (Collateral Ratio, CR). Наприклад, якщо CR=80%, це означає, що для карбування 100 $NUSD користувач повинен надати 80 $USDC і еквівалент 20 $NUSD в NIBI. В майбутньому Nibiru Chain буде підтримувати більше типів забезпечення, а наразі $NUSD більше схожий на $FRAX в екосистемі Cosmos.

1. Нібі-оракули

Nibi-Oracles - це власне рішення Nibiru для оракулів, що дозволяє операторам валідаторів брати активну участь у консенсусному голосуванні оракулів. Він інтегрує позамережеві дані з високою точністю в блокчейн, забезпечуючи зворотній зв'язок із зовнішніми API та смарт-контрактами з низькою затримкою.

У 2024 році Nibiru Chain зосередиться на розширенні екосистеми, а основні розробки включають кілька планів, таких як інтеграція з великими DeFi-проектами в декількох ланцюжках, лістинг на першокласних централізованих біржах, завершення паралельного оптимізованого виконання та досягнення повної сумісності з EVM.

Практики безпечної розробки

Якщо ви розробляєте додаток на Nibiru Chain, процес розробки та необхідні мови майже ідентичні процесам на інших публічних ланцюжках Cosmos. Дотримання наведених нижче рекомендацій з безпеки може покращити безпеку контракту в проекті:

Безпека розробки контрактів

1. Будьте готові протистояти атакам

Подібно до розробки контрактів з використанням Solidity, розробники повинні продумати, як протистояти атакам і виправляти вразливості. Тому розробники повинні створювати смарт-контракти, які можна модернізувати, і формулювати плани реагування на ризики.

1. Зверніть увагу на стандартизацію перевірки адрес

Будь-яка дійсна адреса Cosmos SDK має два допустимих представлення: всі малі літери та всі великі літери, наприклад

cosmos1uzwqa88hcqe5gs7u7lgjxekz7xc6sm0f7xwp6a vs.

COSMOS1UZWQA88HCQE5GS7U7LGJXEKZ7XC6SM0F7XWP6A

Вони знаходяться за тією ж адресою, що й "Нібіру". Коли ми маємо справу з адресами в контрактах, ми повинні враховувати цю характеристику адрес.

pub fn valid_transfer (

Депс: DepsMut,

інфо: MessageInfo,

кількість: Uint128,

dest: Рядок,

) -> Результат <Відповідь, ContractError> {

// Перевірити, чи є адреса в чорному списку

if let Some (is_in_blacklist) = BLACKLIST. may_load (deps.storage, &dest.to_string ( )? {

if is_denied {

return Err (ContractError::DeniedRecipient);

}

} else if let Some (is_in_blacklist) = BLACKLIST.may_load ( deps.storage , &info.sender.clone ( ) )? {

if is_denied {

return Err (ContractError::DeniedSender);

}

......

};

Як показано у наведеному вище коді, оскільки адреса dest не стандартизована і зазвичай використовуються малі літери, будь-хто може обійти BLACKLIST, ввівши адресу великими літерами.

1. Зверніть увагу на арифметичні операції та переповнення

У контрактах CosmWasm розробники повинні пам'ятати про ризики цілочисельного переповнення або такі ситуації, як ділення на нуль. Розробникам рекомендується використовувати типи Uint256 та Uint512 CosmWasm і застосовувати математичні функції, такі як full_mul(), які не спричиняють переповнення.

1. Проблеми контролю доступу

Контроль доступу є однією з основних проблем безпеки програм, і численні інциденти безпеки були спричинені проблемами контролю доступу. Не менш важливо вирішити питання контролю доступу в контрактах Cosmwasm.

Ось типовий приклад:

fn update_config(

Депс: DepsMut,

msg: UpdateMsg

) -> Результат<Відповідь, ContractError> {

let config = CONFIG.load(deps.storage)?

let new_config = Config {

rewards_vault_contract: msg.vault_address

.map(|human| deps.api.addr_validate(&human))

.transpose()?

.unwrap_or(config.rewards_vault_contract)

};

CONFIG.save(deps.storage, &new_config)?

Ok(Response::new().add_attribute("action", "update_config"))

}

Через відсутність перевірок та обмежень на адресу абонента, наведений вище код дозволяє будь-кому викликати update_config(), встановити власну адресу як адресу сховища та отримати всі винагороди, що генеруються за контрактом.

1. Остерігайтеся нескінченних циклів

Контрактна експлуатація Cosmwasm встановлює високий ліміт газу, але неправильне використання призведе до вихлопу газу. Контракт CosmWasm може застрягти в нескінченному циклі, викликаючи себе назад в обробнику ACK. Якщо розробники передають пакети даних між двома контрактами CosmWasm, вони повинні знати, що це може призвести до нескінченного циклу і споживання великої кількості плати за газ.

Практика безпеки в проєкті

1. Аудит смарт-контрактів

Аудит смарт-контрактів передбачає систематичне тестування та перевірку коду смарт-контрактів з метою виявлення потенційних вразливостей безпеки, зниження ризиків безпеки, а також забезпечення відсутності недоліків бізнес-логіки та відповідності коду очікуваним операційним процесам і результатам. Вкрай важливо проводити регулярний аудит безпеки смарт-контрактів для проектів. Аудит рекомендується проводити після завершення розробки контракту та перед розгортанням магістральної мережі.

1. Використання гаманців Multisig

Проектні команди повинні розглянути можливість використання мультигаманців для управління проектними казначействами та смарт-контрактами. Облікові записи з мультипідписом повинні належати кільком організаціям, щоб зменшити потенційні ризики контролю доступу та внутрішніх зловживань. Nibiru Chain вже прийняла рішення Nomos, і проектні команди можуть розглянути можливість використання Nomos для управління активами.

Зведення

Як новий публічний ланцюжок Layer1, Nibiru Chain надає інноваційну платформу для DeFi, ігор, RWA та інших сфер. Він покликаний вирішити проблеми доступності, безпеки та продуктивності Web3-додатків і надати розробникам і звичайним користувачам комплексні та якісні послуги. Послуги.

Відмова від відповідальності:.

1. Ця стаття передрукована з [Techflow]. *Переслати оригінальну назву '新公链 Nibiru 主网将上线，解析其技术特点与安全开发实践'. Всі авторські права належать оригінальному автору [Beosin]. Якщо у вас є заперечення щодо цього передруку, будь ласка, зв'яжіться з командою Gate Learn, і вони оперативно його опрацюють.
2. Відмова від відповідальності: Погляди та думки, висловлені в цій статті, належать виключно автору і не є інвестиційною порадою.
3. Переклади статті іншими мовами виконані командою Gate Learn. Якщо не зазначено інше, копіювання, розповсюдження або плагіат перекладених статей заборонені.