Упрощение создания безопасных децентрализованных приложений (DApps) — внедрение блокчейна

Источник · Перевод автора

Модель для практического развития DApp

Создание смарт-контрактов в блокчейне — не простая, но хорошо понятая часть. Создание этого автоматически на платформе, которая также выводит остальные децентрализованные приложения (DApps), было бы большим прорывом. Автоматизированный вывод всего DApp с формальной верификацией является максимальным: это был бы идеальный, практичный способ для крупномасштабного построения надежных распределенных приложений.

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

Подобно другим продуктам, мы знаем, что у нас есть соответствие продуктового маркета, когда мы видим простое принятие проектов: легкое «притяжение», а не необходимость продавать ценность разработчиков блокчейна и привлекать. Мы знаем, что нам нужно добраться до точки (диаграмма 1), где больше разработчиков развивают больше приложений, которые, в свою очередь, приводят к появлению большего количества «смертоносных приложений», что, в свою очередь, привлекает все больше пользователей и способствует их принятию, создавая условия для привлечения еще большего числа разработчиков в экосистему.

Сегодня специалистов по блокчейну меньше — будь то бэкэнд-разработчики, инженеры Solidity для смарт-контрактов и так далее — по сравнению с традиционными разработчиками, с большим отрывом. Около 35 000 инженеров блокчейна против 25 миллионов разработчиков программного обеспечения. Это фактор более 700! Если мы не получим критическую массу разработчиков в блокчейн-разработку, шансы получить столь необходимые «убийственные» приложения в блокчейне мрачны. Потому что, как мы знаем, приложения-убийцы в мобильном или даже в традиционном мире информационных технологий специально не предназначены для этого. Они происходят в основном по счастливой случайности в процессе решения проблем и экспериментов с бизнес-моделями. Это происходит потому, что разработка этих приложений хорошо понятна, и существует большое количество удобных для разработчиков инструментов и платформ и языков более высокого уровня, доступных для экспериментов и решения проблем в различных случаях использования и отраслях.

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

Проблемы блокчейна для разработчиков

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

Во-первых, это совершенно новая парадигма. Децентрализованные приложения без центральной точки контроля, доверия, распределенного хранения данных и так далее — все это новые и все еще развивающиеся концепции. Понимание внутренних особенностей децентрализованных вычислительных платформ, доказательство заинтересованности и работы, обмен сообщениями, консенсус и так далее — все это важно для разработки осмысленных децентрализованных блокчейн-приложений. Но затем некоторые технологии, такие как стек Web3, в котором все еще отсутствуют четкие определения, не совершенны и могут иметь уязвимости. Даже если кто-то приобретет глубину в любой из этих технологий, разработка DApp для различных вариантов использования требует более чем увлекательного знакомства с функциональным программированием, теорией игр и криптографией или управлением и экономикой. Это просто сложно встроить в блокчейн (диаграмма 2).

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

Практическая модель: удобство использования блокчейна для разработчиков

Итак, как мы можем сделать разработку блокчейна более практичной? Нам нужно облегчить разработчикам процесс создания блокчейна. Разработка блокчейна не может быть преобразована в одночасье переключением на другой язык программирования или передачей разрешения в «вычислительный сенат», как бы это было проще. Следует признать, что по-прежнему существуют фундаментальные проблемы задержки и масштабируемости, но над ними работают ряд проектов и альтернативных решений, таких как подходы Celer, Loom, Plasma или Side-Chain и Mutual Knowledge Base. Но ближайшая, неотложная проблема — привлечь разработчиков в блокчейн. Для этого, даже если значительное большинство, скажем, от 75 до 80 процентов сложности блокчейна, каким-то образом становится доступным, оно станет более удобным для разработчиков. Конечно, некоторые специфичные для протокола низкоуровневые синтаксисы, криптография и / или сложные экономические теории все еще могут быть необходимы, особенно для запуска сложных DApp в производство, но блокчейн-разработка станет менее сложной для миллионов традиционных разработчиков полного стека.

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

  • Единая платформа на основе предметно-ориентированного языка (Domain Specific Language, DSL), которая принимает на вход несколько строк кода и автоматически генерирует весь DApp, а не только «умный контракт».
  • Автоматизированная система проецирования конечных точек для автоматизации производства подпрограмм (клиентов, контрактов) в собственных двоичных файлах, а также их оптимизации.
  • Абстракция для обобщения протоколов уровня 1 и уровня 2, так что разработчики остаются на достаточно высоком уровне и пишут один раз, но могут использовать любой блокчейн.
  • Сервисы / Примитивы для использования в качестве строительных блоков для ускорения разработки.
  • Формальная проверка, которая может автоматически проверять и создавать безопасные DApps
  • Easy Onramp, который включает в себя все вышеперечисленные возможности без бремени затрат или большой кривой обучения.

Специфичный для предметной области язык

Это базовая основополагающая среда для продуктивной разработки DApp без ошибок, в которой комплексный дизайн и встроенные меры безопасности позволяют традиционным разработчикам с уверенностью погрузиться в это. Здесь разработчики DApp используют несколько строк кода для явного выражения логики и цели для конкретного приложения, которое они должны построить. Затем платформа DSL выполняет прогрессивную компиляцию, автоматически генерируя остальную часть кода для всего DApp и использует набор встроенных инструментов — математические доказательства, такие как Z3, показанные на диаграмме, другие различные типы логики и теории игр — для проверки выполнение программы, логика, эффективность, соответствие протокола и общая корректность по отношению к целям и спецификациям приложения, включая экономические критерии. Этот метод обеспечивает локализацию проблем и их эффективную проверку, разбивая проблемы на более мелкие, управляемые этапы, устраняя утечки «безопасности» и устраняя ошибки — например, ошибки, угрозы безопасности и т. Д. — на этих этапах, вместо того, чтобы позволять им превращаться в неразрешимые сложные ошибки по всей программе. Эти шаги повторяются каскадным образом (технические подробности здесь и здесь) без вмешательства разработчика на всем пути от кода низкого уровня базового уровня до приложений более высокого уровня. По сути, хорошо спроектированный DSL является мощной альтернативой разработки, особенно в контексте сложного распределенного приложения, такого как DApp, и преодолевает ограничения языков общего назначения, SDK и библиотек, устраняя необходимость выполнять ручные проверки и проверки обеспечивая при этом гарантии выполнения программ, эффективности и правильности.

Хороший DSL должен иметь встроенную защиту для разработки без ошибок с помощью подхода, который считается «правильным по построению». Это парадигма, в которой платформа не позволяет разработчикам писать код, который приведет к ошибкам. Например, код на стороне клиента не отправит сообщение в смарт-контракт в формате, который не будет выполнен. Это делает разработку DApp продуктивной, корректной и безошибочной даже в процессе разработки, в отличие от необходимости проверять наличие ошибок после завершения кода, что может привести к повторному отслеживанию, повторной записи и повторной проверке на наличие ошибок.

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

Есть, конечно, обычные, но все же важные соображения для хорошего DSL. Например, простой в использовании популярный синтаксис, такой как JavaScript, для устранения дополнительных препятствий для изучения еще одного синтаксиса. Компиляторы и инструменты тестирования также помогают разработчикам легко создавать распределенные приложения.

Автоматизированное производство DApp с использованием проекции конечной точки

Недостаточно иметь DSL, обеспечивающий среду для разработки. Разработчикам также нужны инструменты для окончательного создания конечных программ в собственных двоичных файлах, которые должны выполняться в процессе разработки в соответствии с проектом. Автоматизированное производство DApp — это модуль, который делает это и дополняет общую платформу, тем самым облегчая освоение традиционных разработчиков.

Начиная с относительно небольшого исходного кода, DSL позволяет компилировать с помощью различных этапов (а) синтаксического анализа, в легко проверяемые математические выражения (b) расширения, в код виртуальной машины в качестве подготовки к работе в различных точках распределенной сети и (с) анализа в логическую модель, которую можно проверить с использованием различных методов, таких как средство проверки Z3.

С этого момента, используя технику, называемую «проекция конечной точки» (EPP, диаграмма 4), можно автоматически создать несколько необходимых программ. Здесь, для иллюстрации, мы видим конечные программы, такие как клиентский код на JavaScript, серверный код на OCaml или аналогичный язык и смарт-контракты в Solidity или аналогичный язык. End-Point-Projection может производить все программы, необходимые для конкретного DApp — Oracle, другие серверы и так далее, Все из небольшого исходного кода DSL.

Это очень мощный сдвиг парадигмы развития в сторону упрощения разработки, а также ее надежности по сравнению с традиционной платформой разработки. В распределенных приложениях, в которых, естественно, задействовано много программ или участников, важно, чтобы все участники согласовали правила взаимодействия. При таких обстоятельствах язык общего назначения требовал бы, чтобы программы поддерживали несколько копий программы и обеспечивали их согласованность, что является дорогостоящим и подверженным ошибкам. Кроме того, написание исходного кода — реальное усилие для разработчика — составляет лишь долю, в 40-80 и более раз, в зависимости от длины вывода некоторых машинно-сгенерированных исполняемых файлов, созданных в результате этого процесса. Это, безусловно, экономит драгоценное время по сравнению с написанием кода вручную, но, что более важно, машинно-сгенерированный код создает логически и функционально правильный код по конструкции, по конструкции.

Абстракция

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

Сервисы и примитивы

Повторное использование хорошо известных хороших фрагментов кода известно разработчикам как сокращение производительности. В контексте блокчейна это категория сегментов, которая включает библиотеки кода, серверные части компилятора, криптографические примитивы и так далее. По сути, это строительные блоки, которые могут помочь разработчикам интегрироваться в базовые уровни, включать новые функции и тому подобное. Мы могли бы представить бэкенды компилятора для боковых цепей, для базы взаимных знаний или для взаимодействия с другим протоколом или библиотеками для оценки газа и так далее. Благодаря этой модульной функциональности, подобной Lego, приложения могут объединять один или несколько из этих сервисов и строить их на основе другого кода, что приводит к очень быстрой разработке. В управляемой сообществом среде с открытым исходным кодом примитивы могут стать эффективным подходом для запуска ряда перекрестных проектов.

Формальная проверка (Formal Verification, FV)

Этот метод может помочь покрыть логическую, экономическую корректность, а также меры безопасности. По сути, формальная проверка может начинаться с одной спецификации для всего DApp и последующего моделирования математических объектов программ DApp. Затем процесс FV — в сочетании с подходом DSL по созданию управляемых кусков проблемных пространств — может выполнять серию математических проверок и проверок, чтобы обеспечить логику, семантическую точность и правильность использования протокола, чтобы гарантировать общую корректность. Зная, что блокчейны имеют неограниченные входные данные и работают в бесконечных доменах, в смеси частных или общедоступных сетей и облаков, тестирования правильности программного обеспечения с использованием традиционных методов просто будет недостаточно. И проблемы в блокчейне, которые сдерживают массовое принятие, заключаются в том, что терпимость к ошибкам в разработке блокчейна равна нулю. Несмотря на то, что блокчейн-приложения предоставляют автоматический, неконтролируемый доступ к активам на миллиарды долларов. Таким образом, FV является основным в подходе к созданию простого наладчика для разработчиков путем преодоления одной из самых неприятных и критических проблем.

Методы FV в сочетании с тем, как DSL может быть настроен через DApp, обеспечивает корректность на различных уровнях разработки — ниже, ближе к базовому уровню или выше, ближе к уровню приложений и могут быть встроены в процесс разработки, устранение потенциальных рисков или их устранение. Эти методы FV, однако, трудно, если не невозможно, реализовать после разработки кода. Следовательно, необходимо включить прямо вместе со спецификациями.

Различные теории и методы могут быть использованы для управления методами FV. Некоторые из них перечислены ниже, а более подробная информация, включая статьи, цитируется по ссылкам.

  • Теория типов
  • Доказательство теорем
  • Проверка модели
  • Strand Spaces и
  • Динамическое моделирование систем

Easy Onramp

Последний компонент практической модели — создание структуры, обеспечивающей доступность остальных компонентов, DSL, формальной проверки, EPP и так далее. Это важно, так как эти методы и дизайн, несмотря на то, что они надежны, продуктивны, не просты в освоении и, конечно, не так легко реализуются на практике. Внедрение этих методов использования DSL, автоматической генерации кода и даже формальной проверки в готовую платформу, которую может использовать любой традиционный разработчик, является мощным. Таким образом, действительно практичная модель блокчейн-разработки DApp будет иметь Easy Onramp, где эти мощные функции встроены в платформу и делают их доступными и прозрачными для любого традиционного разработчика без затрат и с минимальным обучением.

Создание и поддержание импульса

Практическая модель, изложенная выше, обсуждает шесть компонентов, которые в совокупности могут обеспечить надежную, связную платформу для привлечения традиционных разработчиков в блокчейн-разработку. Будет ли такая платформа достаточной, чтобы инициировать принятие блокчейн-разработки основным сообществом разработчиков? На мой взгляд, это наверняка решило бы первый шаг для подбора рынка. Но, как обсуждалось в модели «Платформа-экосистема», нам все еще необходимо учитывать необходимость развития сообщества и концепции целого продукта. Это важно для поддержания импульса привлечения все большего числа разработчиков в блокчейн. Экосистема также должна обеспечивать хороший опыт для конечных пользователей. Современные мобильные приложения не навязывают кривую обучения или трения, которые делают блокчейн-приложения. Но, как модель практического развития DApp, это решает ключевые проблемы. Действительно, очень большая часть сопротивления разработчиков к использованию блокчейн-технологий отпадет, особенно с гарантией формальной проверки по всему DApp. В сочетании с тысячами специалистов по блокчейну, теперь можно было создать полную силу программной инженерии, стоящей за созданием новых приложений для реализации обещания блокчейна.

Рекомендации для технически склонных:

  • Пример автоматически сгенерированного DApp: Rock Paper Scissor DApp
  • Проверка модели параллельных программ для Data-Race
  • Системы типов как макросы
  • Библиотека Coq для внутренней проверки времени выполнения
  • Временные контракты высшего порядка