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

Публичная цепочка Layer1 - Nibiru Chain - запустила стимул для airdrop в конце января 2024 года. Через месяц после начала деятельности, связанной с воздушным десантированием, его сообщество выросло более чем в три раза и насчитывает более 500 000 подписчиков в Twitter. Получив более $20 млн. финансирования, компания Nibiru Chain готова решить проблему безопасности и скорости работы приложений DeFi, потенциально конкурируя с dYdX. В настоящее время Nibiru Chain планирует запустить свой Mainnet на этой неделе. Каковы технические особенности и конкурентные преимущества Nibiru Chain как быстро развивающегося решения Layer1? О каких соображениях безопасности следует помнить разработчикам при создании проектов в экосистеме? Сегодня Beosin представит подробный анализ.

Анализ протокола цепочки Нибиру

Nibiru Chain в основном занимается DeFi транзакциями в качестве своего основного бизнеса. Он включает в себя четыре основных компонента:

1. Nibi-Perps

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

1. Nibi-Swap

Автоматический протокол маркет-мейкеров Nibiru разработан для поддержки двух типов пулов ликвидности: пулов обмена стабильных монеток и пулов обычных постоянных продуктов.

1. $NUSD

Стаблкоин с полным обеспечением в экосистеме Нибиру. Нибиру планирует первоначально поддерживать чеканку $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 (

deps: DepsMut,

Инфо: MessageInfo,

количество: Uint128,

dest: String,

) -> Результат <Ответ, 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(

deps: 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. Аудит смарт-контрактов

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

1. Использование мультисиговых кошельков

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

Краткая информация

Будучи новой публичной цепочкой Layer1, Nibiru Chain предоставляет инновационную платформу для DeFi, игр, RWA и других сфер. Его цель - решить проблемы доступности, безопасности и производительности приложений Web3 и предоставить разработчикам и обычным пользователям комплексные и превосходные услуги. Услуги.

Отказ от ответственности：

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