Описание Nebulas

Nebulas (NAS) представляет собой токен управления и базовый актив блокчейна-сети Nebulas NOVA.

Nebulas позиционируется разработчиками, как автономную метасеть, которая фокусируется на данных в цепочке, взаимодействиях и сотрудничестве. Сообщается, что его гипер-сопоставленные структурные метаданные могут обрабатывать все более сложные данные в цепочке и описывать эти взаимодействия.

15 апреля 2019 года команда запустила основную сеть Nebulas NOVA, блокчейн-сеть со встроенными стимулами. После запуска Nebulas NOVA разработчики и пользователи могут участвовать в развитии экосистемы Nebulas для реализации ее видения - позволить каждому получить справедливую выгоду от децентрализованного сотрудничества.

Чтобы способствовать развитию экосистемы, управлению активами и продвижению «автономной метасети», команда основателей Nebulas вместе с сообществом сформирует «Nebulas Community Group». В группу сообщества Nebulas входят 3 организации - Совет Nebulas, Фонд Nebulas и Технический комитет Nebulas. Эти организации будут контролировать друг друга и поддерживать устойчивое развитие Nebulas.

Технология метасети Nebulas

Разработчики выделяют три основных компонента технологии «автономной метасети» Nebulas:

• Консенсус и механизм управления Proof of Devotion (PoD) - доказательство преданности.
• Токеномика NextDAO и Децентрализованнаый стекинг - dStaking.
• Платформа совместной работы · Go.nebulas.io

Рассмотрим эти элементы подробнее.

Консенсус и механизм управления - Proof of Devotion (PoD)

Nebulas начал свой путь с видения «Пусть каждый получит справедливые ценности от децентрализованного сотрудничества». Продолжая развитие «автономной метасети», Nebulas строит новую децентрализованную автономную организацию (DAO) для сложных сетей передачи данных, которая будет полностью охватывать сообщество, децентрализацию и автономию на основе измеряемого вклада. Идея механизма Proof of Devotion (PoD) состоит в том, чтобы обеспечить измеримую ценность для всех пользователей в зависимости от размера их вклада в экосистему, который включает механизмы обещания, консенсуса и управления. Есть две части:

1. Механизм консенсуса: децентрализовать узлы цепочки блоков Nebulas;
2. Механизм управления: децентрализовать управление сообществом через формирование представительной системы и правительственных комитетов.

Сейчас PoD уже запущен в основной сети. Вы можете проверить блоки и ситуацию управления на платформе узла. Первое голосование по управлению PoD в основной сети началось 29 апреля 2020 года.

Токеномика NextDAO и децентрализованный стейкинг · dStaking

В отличие от традиционных методов залога / размещения ставок, которые требуют, чтобы пользователи переводили средства на контракт, децентрализованный договор залога записывает залог пользователя, в то время как активы все еще контролируются и хранятся на личном адресе пользователя.

1. Пользователи имеют полное право собственности на личные активы;
2. Исключает риск потери по техническим причинам;
3. Участие в залоге проще, что, по мнению разработчиков, приведет к значительному увеличению активности.

Награды пользователя dStaking - это отзывы об их вкладе во владение токеном. Используется в голосовании по управлению PoD, в стимулах экосистемы и других сценариях использования, составляет экономику с положительной обратной связью. Например, пользователи голосуют за узлы через NAX, алгоритм ранжирования узлов-кандидатов ссылается на индекс стабилизации блока и номер голосования NAX. Затем он учитывает вклад удерживаемого токена и генерируемых блоков.

Сотрудничество. Платформа совместной работы · Go.nebulas.io

Платформа для совместной работы сообщества Nebulas (go.nebulas.io) была запущена еще 25 марта 2019 года с намерением изучить новую модель сотрудничества. Она направлена на снижение уровня сложности участия сообщества, привнесение новых идей, творчества и на то, чтобы другие помогли в продолжении строительства туманностей (видимо это метафора для подсообществ пользователелей - прим. ред).

На платформе Go.nebulas члены сообщества могут давать свои собственные рекомендации для новых и существующих проектов, участвовать в предложениях и контролировать текущий процесс разработки всех активных проектов. Последняя инновационная модель сетевого управления Nebulas и экономия токенов также будут запущены на платформе сотрудничества с сообществом.

Смарт-контракты

Whitepaper разработчиков анонсирует полный по Тьюрингу язык программирования смарт-контрактов, совместимый c Ethereum, но имеющий дополнительные функции. Кроме того, смарт-контракты Nebulas, в отличие от смарт-контрактов Ethereum, будут обновляемыми.

Отличия от Ethereum

Смарт-контракт - это набор обусловленных обязательств, определенных в цифровой форме, включая соглашения об исполнении этих обязательств участниками контракта. Физически носителем смарт-контракта является компьютерный код, который компьютер может распознать и с которым можно работать на компьютере. Язык сценариев Биткойн - это анимативный язык программирования, основанный на стеке, и, поскольку он не является полным по Тьюрингу, его приложения имеют некоторые ограничения. Ethereum - первая в мире блокчейн-система, реализующая полные смарт-контракты Тьюринга. Принятый язык программирования - Solidity и Serpent, что позволяет разработчикам быстро и эффективно разрабатывать широкий спектр приложений. После публикации кода смарт-контракта в блокчейне он может выполняться автоматически без участия каких-либо посредников.

На раннем этапе язык программирования смарт-контрактов в Nebulas был полностью совместим с Solidity of Ethereum, что позволяло разработчикам легко переносить приложения смарт-контрактов, разработанные для Ethereum, в Nebulas. Затем разработчики добавили некоторые наборы инструкций, относящиеся к языку Nebulas Rank toSolidity, чтобы смарт-контракты могли получать значение NR для любых пользователей.

В дальнейшем на основе NVM (Nebulas Virtual Machine), команда проекта обещает реализовать поддержку различных языков программирования, что упростит разработчикам программирование на их любимых продвинутых языках, таких как Java, Python, Go, JavaScript, Scala и т.д., или даже создание индивидуальных приложений с некоторыми продвинутыми языками в отдельной предметной области.

Обновляемые смарт-контракты

Код смарт-контрактов, развернутых в сети Ethereum, нельзя менять после того, как они записываются в блокчейн. С момента создания логики кода его нельзя обновлять вечно. Если смарт-контракт служит соглашением, он должен быть неизменным, что представляет собой соглашение о том, что его действие определено. Однако по мере того, как смарт-контракт получает все большее распространение, его рабочий процесс и код становятся все более сложными. Выяснилось, что это выглядит как настоящий контракт в реальном мире. Если его не проанализировать внимательно, трудно предотвратить человеческие ошибки в процессе проектирования и кодирования. Как только хакеры обнаруживают какие-либо ошибки, потери всегда очень значительны. В июне 2016 года атака DAO произошла из-за дефекта кода, в результате чего пользователи Ethereum понесли убытки в размере 60 миллионов долларов. Кроме того, обнаруженная ошибка в Parity Wallet привела к потере 150 000 ETH на сумму 30 миллионов долларов. Скрипт-язык биткойна спроектирован с учетом неполноты Тьюринга и многие инструкции были удалены, поэтому его уровень безопасности существенно выше.

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

В Ethereum есть несколько решений по обновлению смарт-контракта, которые обычно делятся на две категории. Первый - это общедоступный договор о доверенности. Его код очень прост, он только перенаправляет запрос на следующий реальный функциональный контракт. Когда контракт нуждается в обновлении, просто сделайте указатель внутреннего функционального контракта Proxy Contractpoint на новый контракт. Второй - отделить контракт кода от контракта хранения. Контракт хранения отвечает за предоставление внешнему контракту методов для чтения и записи внутреннего состояния. Контракт кода отвечает за реальную бизнес-логику, а при обновлении он отвечает только за развертывание нового контракта кода, чтобы не потерять состояние. У этих двух решений есть свои ограничения соответственно, поэтому они не могут решить все проблемы. Например, разделение контракта кода и контракта хранения усложняет задачу. Иногда это даже невозможно. Хотя контракт прокси может указывать на новый контракт, данные состояния старого контракта не могут быть перенесены. Некоторые контракты плохо спроектированы на начальной стадии разработки, поэтому они не могут оставить какой-либо интерфейс для последующего обновления.

Команда Nebulas утверждает, что разработала простое решение для обновления смарт-контрактов. Таким образом, на уровне языка другой контракт может напрямую читать и записывать переменную состояния контракта (в соответствии с ограничениями безопасности).

При развертывании контракта переменная balances помечается ключевым словом shared, а когда она компилируется в байт-код для работы, виртуальная машина спроектирует область хранения отдельно для этой переменной. Для переменной, которая не помечена ключевым словом shared, другие контракты не могут получить доступ к ней напрямую.

Если ошибка в функции передачи исходного кода требует изменения, проверьте _value и разверните новый код смарт-контракта.

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

Для обеспечения безопасности обновление контракта и старый контракт должны использовать одного и того же создателя, в противном случае во время работы будет выдано исключение.

В этом дизайне есть моральная проблема. После того, как положения контракта были предложены и заключены, их не следует изменять. Любые последующие изменения должны быть согласованы с аудиторией контракта. Разработчики планируют ввести механизм голосования для утверждения обновления смарт-контракта, предотвращая автоматическое изменение контракта его создателем.

С помощью этого обновляемого решения ошибку DAO Attack или Parity или аналогичные события атаки с ошибкой можно исправить быстрее, чем с помощью хард-форка. После ремонта активы всех пользователей можно продолжать использовать без миграции.