Поехали!
Мы создаем новую архитектуру программного обеспечения. Эта архитектура охватывает существующие децентрализованные прикладные технологии, значительно расширяя их возможности. Он позволяет создавать децентрализованные и распределенные приложения нового поколения, выходящие за рамки криптовалют и управления активами. Для нас ключевой ценностью этого дизайна является расширение автономии пользователей, распределение между ними власти.
Приглашаем вас присоединиться к альянсу, развивающему эту архитектуру и фундамент, который ей посвящен.
Архитектура для создания криптографических протоколов
Предлагаемая архитектура основана на языке, ориентированном на возможности, с рабочим названием DJS (Распределенный JavaScript). Криптографические протоколы определяются просто как бизнес-логика.
Биткойн, Ethereum и OpenBazaar - это примеры приложений, реализующих криптографические протоколы, разработанные для определенной цели. Напротив, DJS идет на шаг глубже: это язык для создания различных криптографических протоколов для различных целей. Дополнительная гибкость важна для безопасной и надежной взаимосвязанности. Биткойн можно рассматривать как одну виртуальную машину на уровне приложений. Если мы определяем виртуальные машины таким образом, DJS позволяет создавать несколько виртуальных машин (децентрализованных или иных) и позволяет им безопасно взаимодействовать. Это означает, что точки интеграции и поддерживающие приложения (например, обмен в случае криптоактивов) также могут обеспечивать такую же децентрализацию, безопасность и надежность.
Атомарные транзакции
Изменения состояния на нескольких виртуальных машинах происходят в рамках транзакции. Транзакции бывают распределенными и атомарными. Это означает, что можно гарантировать, что операция на виртуальных машинах будет выполняться целиком или не выполняться вообще. Если транзакция не может быть завершена, возникает исключение, поэтому разработчик может повторить попытку или обработать ее индивидуальным способом. Это, в сочетании с другими функциями, такими как проверяемость и неотвратимость, гарантирует надежность распределенного изменения состояния. Кроме того, распределенная транзакционная программная память позволяет продолжать неконфликтующие транзакции, пока текущие транзакции завершаются.
Архитектура является модульной: разработчик может выбирать, будет ли приложение централизованным или децентрализованным, проверяемым или нет, публичным или частным. Приложение можно безопасно распределить между разными виртуальными машинами. Архитектура повторяет цель технологии распределенного реестра: отказ от посредников для централизованного управления данными и безопасное взаимодействие между одноранговыми узлами без третьих сторон.
Права и активы
В DJS основное внимание уделяется управлению правами. Общая категория прав делает возможным широкий спектр взаимосвязей и перемещает обеспечение безопасности и примитивы доступа с уровня приложения на сам язык. Например, владение активами - это особый случай категории прав. Идея, лежащая в основе DJS, во многом обязана идеям Марка С. Миллера Возможности как криптографический протокол. Что особенно важно, когда виртуальные машины взаимодействуют через возможности (смарт-контракты по доступу виртуальных машин к объектам друг друга), их уязвимость ограничивается известным образом.
Архитектура выходит за рамки того, что предусмотрено Миллером, заключается в расширении структуры возможностей с частных и однозначно идентифицируемых виртуальных машин как на общедоступные (проверяемые, децентрализованные), так и на анонимные частные виртуальные машины. Вот где предложение учится на биткойнах и аналогичных более поздних протоколах, заменяя «доверенную третью сторону» общедоступным и не требующим доверия протоколом. Этот шаг необходим, чтобы сделать объекты (в виртуальных машинах) идентифицируемыми, не раскрывая, кто контролирует их. Это позволяет сторонам транзакции («кошелькам») оставаться конфиденциальными.
Децентрализованные виртуальные машины как смарт-контракты
В рамках DJS смарт-контракт - это виртуальная машина, совместно используемая всеми сторонами контракта. Всем сторонам может быть предоставлена возможность проверить каждую транзакцию и достичь консенсуса до того, как транзакция будет совершена. Если до исполнения требуется согласие всех сторон, договор является частным; если к договору можно присоединиться в любой момент, то он является публичным. Такой протокол, как Биткойн, можно понимать как публичный контракт.
Написание эффективных распределенных приложений
Например, через DJS мы можем определить криптографический протокол, который копирует то, что делает типичное приложение блокчейна. Однако алгоритм консенсуса может быть другим. Мы могли бы дополнительно поэкспериментировать с полезностью приложения, являющейся единственным стимулом, необходимым для его запуска. Это возможно, потому что обеспечение неподдельности записей на DJS не обязательно требует вычислительных затрат на алгоритм доказательства работы или настройки управления доказательством доли (хотя они могут быть реализованы при необходимости) .
В общем, DJS (через ориентацию на возможности и распределение на основе служебных программ) дает выигрыш в эффективности при написании распределенных приложений. Приложения не нужно «создавать вручную», как если бы они были написаны на ассемблере. По сути, DJS обеспечивает абстракцию более высокого уровня для программирования распределенных приложений. Это цель: «открыть шлюзы», позволяя разработчикам легко и эффективно кодировать распределенные приложения.
Управление
В существующих системах управление приложением, то есть возможность обновлять бизнес-логику или протоколы, происходит вне приложения. Это часто означает подрывные действия, такие как хард-форки. DJS интегрирует управление в логику приложения, позволяя выполнять итерацию приложения в соответствии с правилами, определенными в самом приложении. Изменение приложения - это право, которое может быть предоставлено по любым критериям; например, в приложении криптографической книги по критериям подтверждения доли. Итерация становится неотъемлемой возможностью приложений, при этом сохраняется некоторая неизменность.
Модульный дизайн приложения
Разрешение нескольким приложениям безопасно подключаться и взаимодействовать с помощью правил, определенных в их бизнес-логике, способствует модульному дизайну. Это дополнительно помогает облегчить проблемы масштабируемости, с которыми сталкиваются текущие монолитные архитектуры, позволяя приложениям выполнять итерацию в гораздо меньших единицах.
В конечном счете, упомянутые выше конструктивные особенности предназначены для приложений, которые создают новое экономическое пространство: новые финансовые системы, альтернативные формы управления, социальная и политическая организация и правовые системы.
