Термины по системной программе
Системная программа – машинная программа, предназначенная для управления работой ВС, либо для автоматизации программирования.
Управляющая программа – системная программа для управления работой МП, обеспечивающая взаимосвязанное функционирование всех устройств ЭВМ при обработке заданий.
Транслирующая программа (транслятор) – программа перевода текста с одного языка программирования на машинный язык.
Компиляция – метод автоматического составления машинной программы по исходной программе, записанной на язык программирования, выполняемая транслятором-компилятором.
Компилятор – системная программа, осуществляющая трансляцию всей исходной программы в машинную программу.
Интерпретация – метод выполнения в ЭВМ программы, созданной на языке программирования, без перевода ее в машинную программу.
Интерпретатор – системная программа, осуществляющая синтаксический контроль операторов исходной программы и последовательное выполнение ее команд.
Ассемблирование – системная программа процесса перевода исходной программы, заданной на машинно-ориентировочном языке (ассемблере), в машинную программу.
Ассемблер – системная программа, осуществляющая ассемблирование (перевод исходной программы на язык Ассемблер).
Редактор связей – системная программа, объединяющая отдельно оттранслированные объектные модули в один готовый к выполнению модуль (загрузочный).
Обслуживающая (сервисная) программа – системная программа, предназначенная для реализации протокола взаимодействия центрального процессора с внешним устройством (определение порядка пуска и останова механизмов и процессов, обмена данными и служебной информацией, обнаружения ошибок, сигнализации занятости). Иногда такую программу называют драйвером (водителем) внешнего устройства.
Эмуляция – автоматическое составление машинной программы для ЭВМ другой архитектуры по исходной программе, созданной на языке программирования посредством кросс-системы.
Кросс-система – система программирования, предназначенная для разработки на конкретной ЭВМ машинной программы для ЭВМ другой архитектуры.
Прикладная программа – алгоритм решения конкретной задачи пользователя, заданный на языке программирования.
Сервисная программа – программа, способствующая повышению производительности труда программистов и пользователей, автоматизируя некоторые операции взаимодействия их с компьютером (редакторы: текстовый, графический, экранный).
Диспетчер (монитор)– основная системная управляющая программа, обеспечивающая взаимодействие входящих в вычислительную систему устройств и программ математического обеспечения в процессе решения задач.
Отладочная программа – системная программа, предназначенная для автоматизации некоторых этапов отладки программы пользователя.
Супервизор – управляющая программа, определяющая очередность выполнения программ.
Основные термины технического обеспечения
Интерфейс – разъемное соединение с четко обговоренными функциями каждого провода и каждого сигнала в проводе, позволяющее стационарное подключение любых требуемых внешних устройств к внутренней части вычислительной системы и их программное обслуживание.
Мультиплексор – схема, служащая для передачи сигналов с одной из входных линий в выходную информацию.
Адаптер – это обобщенное название электронных устройств сопряжения различных компонентов автоматической аппаратуры.
Например, адаптер линии связи применяется в составе аппаратуры передачи данных для сопряжения ее с линией передачи данных. Адаптер межпроцессорной связи обеспечивает непосредственную связь по входным и выходным сигналам двух или более процессоров одной или разных вычислительных систем.
В компьютере адаптер представляет собой специальную микросхему, предназначенную для согласования центральных и периферийных устройств и для управления работой последних. Например, адаптер цветного графического монитора позволяет управлять выводом на монитор точек, букв, точечных изображений, их цвета и фона на экране.
САПР позволяет поддерживать автоматизацию научных исследований, проектно-конструкторских работ, управление производством. Контроль работы данных системы может осуществлять АСУ. Интегрируя АСУ и АСУТП можно получить гибкие автоматизированные производства (ГАП). Интегрируя САПР и ГАП можно получить интегрированные компьютеризированные производства (ИКП). От АСУ все, входящие в ИКП системы, должны получать информацию планового характера, в также информацию о фактическом наличии ресурсов. От АСНИ поступает информация о технических требованиях к проектируемому объекту.
Объединение АСУ, САПР, АСУП даст возможность обходиться производству без выпуска традиционной проектной документации, т.к. результаты проектирования непосредственно используются в производстве.
1. Основные понятия программного обеспечения.
Программа – упорядоченная последовательность команд компьютера для решения задач.
ПО – это совокупность программ обработки данных и необходимых для их эксплуатации документов.
Задача – это проблема, подлежащая решению.
Приложение – это программная реализация на компьютере решения задач.
Различают 2 вида задач:
1) Технические, которые являются основой для разработки сервисных средств ПО в виде утилит, сервисных программ, библиотек процедур и др., применяемых для обеспечения работоспособности компьютера, разработки др. программ или обработки данных функциональных задач.
2) Функциональные, которые требуют решения при реализации функций управления в рамках информационных систем предметных областей.
Предметная область – это совокупность связанных между собой функций, задач управления, с помощью которых достигается выполнение поставленных целей.
Процесс создания программ можно представить, как последовательность следующий действий:
Постановка задачи→алгоритм решения→программирование.
Постановка задачи – это точная формулировка решения задачи на компьютере с описанием входной и выходной информации.
Алгоритм решения – это система точно сформулированных правил, определяющая процесс преобразования допустимых исходных данных (входной информации) в желаемый результата (выходной информации) за конечное число шагов.
Программирование – теоретическая и практическая деятельность, связанная с созданием программ. Базируется на комплексе научных дисциплин, направленных на исследование, разработку и применение методов и средств разработки программ.
2. Характеристика программного продукта.
Программные продукт – это комплекс взаимосвязанных программ для решения определенной проблемы массового спроса, подготовленной к реализации как любой вид промышленной продукции.
Основные характеристики программ:
1) Алгоритмическая сложность.
2) Состав и глубина проработки реализованных функций обработки.
3) Полнота и системность функций обработки.
4) Объем файлов программ.
5) Требования к операционной системе и техническим средствам обработки со стороны программного средства.
6) Объем дисковой памяти.
7) Размер оперативной памяти для запуска программ.
8) Тип процессора.
9) Версия операционной системы.
10) Наличие сети и др.
Основные характеристики качества программ:
1) Мобильность означает их независимость от технического комплекса системы обработки данных, операционной среды, сетевой технологии обработки данных, специфики предметной области и др.
2) Надежность работы программного продукта (ПП) определяется бесперебойностью и устойчивостью в работе программ, точностью выполнения приписанных функций обработки, возможностью диагностики ошибок, возникающих в процессе работы программ.
3) Эффективность ПП оценивается как с позиции прямого его назначения – требований пользователя, так и с точки зрения расходов вычислительных ресурсов, необходимых для его эксплуатации.
4) Модифицируемость ПП означает способность к внесению изменений, например, расширение функций обработки, переход на другую техническую базу обработки.
5) Коммуникативность ПП основана на максимально возможной их интеграции с другими программами, обеспечением обмена данными в общих форматах представления.
3. Основные виды программного обеспечения.
1) Прикладные программы непосредственно обеспечивают выполнение необходимых пользователям работ: редактирование текста, рисование картинок, обработку информационных массивов и т.д. Наиболее широко применяются:
- Редакторы текстов;
- Табличные процессоры;
- Издательские системы (для подготовки документа топографического качества);
- Системы управления базами данных (для обработки массивов информации);
- Подготовка презентаций (слайд-шоу);
- Программы экономического назначения (бухгалтерские программы, программы финансового анализа, правовые базы данных);
- Программы для создания рисунков, анимационных и видеофильмов;
- Системы автоматизированного проектирования (САПР) – программы черчения и конструирования различных предметов и механизмов;
- Программы для статистического анализа данных;
- Компьютерные игры, электронные справочники, обучающие программы и др.
2) Системные программы выполняют различные вспомогательные функции, например, создание копий используемой информации, проверку работоспособности устройств компьютера и др.
- Драйверы – программы, обеспечивающие взаимодействие с каким-либо устройством. Они расширяют возможности операционных систем (ОС), например, позволяя ей работать с тем или иным устройством, обучаю ее новому протоколу обмена данными и др.
- Программные оболочки – популярный класс системных программ, который обеспечивает более удобный и наглядный способ общения с компьютером, чем штатные ОС.
- Вспомогательные (сервисные) программы (утилиты) обеспечивают безопасность хранения дисковых данных, восстановление данных в аварийных ситуациях, телефонной связи, шифрования данных и прочее (программы резервирования, антивирусные программы, программы упаковщики, русификаторы, программы для диагностики компьютера, для оптимизации дисков, динамичного сжатия дисков, ограничения доступа и др.)
3) Инструментальные системы (системы программирования, которые обеспечивают создание новых программ для компьютера). Эти системы обычно включают компилятор, осуществляющий преобразование программ на языке программирования в программу в машинных кодах. Или интерпретатор, осуществляющий непосредственное выполнение программы на языке программирования высокого уровня, редактор текстов программ, библиотеки полезных программ, а иногда и различные вспомогательные программы.
4. Общая характеристика пакетов прикладных программ.
1) ППП являются наиболее динамично развивающейся частью ПО: круг решаемых с помощью ППП задач постоянно расширяется. Во многом внедрение компьютеров практически во все сферы деятельности стало возможным благодаря появлению новых и совершенствованию существующих ППП.
2) Достижения в области микроэлектроники, приводящие к появлению более мощных по своим функциональным возможностям, также являются причиной создания новых ППП. В свою очередь, необходимость улучшения характеристик использования пакета при решении конкретных задач пользователя стимулирует совершенствование архитектуры и элементной база компьютеров и периферийных устройств.
3) Структура и принципы построения ППП зависят от класса ЭВМ и операционной системы, в рамках которой этот пакет будет функционировать. Наибольшее количество разнообразных ППП создано для IBM PC- совместных компьютеров с операционной системой MS DOS и операционной оболочкой WINDOWS.
5. Классификация ППП.
1) Проблемно-ориентированные ППП — наиболее развитая в плане реализуемых функций и многочисленная по количеству созданных пакетов ППП.
2) Текстовые процессоры – специализированные программы, предназначенные для работы с документами (текстами), позволяющие компоновать, форматировать, редактировать тексты при создании пользователем документа.
3) Настольные издательские системы (НИС) – программы, предназначенные для профессиональной издательской деятельности и позволяющие электронную верстку широкого спектра основных типов документов, типа информационного бюллетеня, краткой цветной брошюры и объемного каталога или торговой заявки, справочника (Page Maker, Quark XPress, Frame Maker, Microsoft Publisher и т.д.).
4) Графические редакторы – пакеты, предназначенные для обработки графической информации, делятся на ППП обработки растровой графики и изображений (Adobe Photoshop), и векторной графики (предназначены для профессиональной работы, связанной с художественными и техническими иллюстрациями с последующей цветной печатью, занимают промежуточное положение между САПР и НИС (пример:Corel Draw).
5) Электронные таблицы – пакеты программ, предназначенных для обработки табличным образом организованных данных.
6) Организаторы работ – это пакеты программ, предназначенные для автоматизации процедур планирования, использования различных ресурсов, как отдельного человека, так и всей фирмы или ее структурных подразделений. Подразделяются на: управление проектами (MS Project) и организацию деятельности отдельного человека (Lotus Organizer ACTI).
7) Системы управления базами данных(СУБД) – предназначены для автоматизации процедур создания, хранения и извлечения электронных данных (dBase, Paradox, MS Access, Oracle).
8) Пакеты программ мультимедиа предназначены для использования ПЭ ВМ для отображения и обработки аудио-видео информации. Подразделяются на пакеты для обучения и досуга, и программы для подготовки видеоматериалов для создания мультимедиа, представления демонстрационных дисков и стендовых материалов. Пример: Director for Windows
9) Программы распознавания символов – предназначены для перевода графического изображения букв и цифр в ASCH-коды этих символов. Используются, как правило, совместно со сканерами (Fine Reader).
10) Финансовые программы – предназначены для ведения различных финансов, автоматизации бухгалтерского учета малых и крупных фирм, экономического прогнозирования развития фирмы, анализа инвестиционных проектов, разработки технико-экономического обоснования финансовых сделок и т.п. (Turbo Tax for Windows, Systat).
11) Интегрированные пакеты программ – по количеству наименований продуктов немногочисленная, но довольно мощная и активно развивается (Flame Work, Microsoft Officce)
Как понять нужно ли интегрировать blockchain в ваш продукт?
Это, пожалуй, доверительная оценка — выбирайте
Автор оригинала: Gideon Greenspan
- Блог компании Web-payment.ru ,
- Криптография ,
- Анализ и проектирование систем
- Перевод
Blockchain технологии в данный момент являются слишком раздутыми. О нем пишут и говорят все: от конференций Sibos и Money20/20 до популярных материалов в изданиях The Economist и Euromoney – кажется, что каждый стремится ухватить свою долю в золотой блокчейн-лихорадке.
Как определить, что у вас реальный случай применения технологии блокчейн? Мы в Web-payment.ru много пишем о технологии распределенного реестра, и по роду деятельности нашего Digital агентства, ориентированного на финтех компании, замечаем, что поднятый вопрос очень актуальный для многих игроков рынка. Эта статья, опубликованная в блоге открытой платформы для создания своих блокчейнов MultiChain , призвана помочь разобраться в этом.
Огромное количество приходящих в MultiChain проектов вообще не имеет ничего общего с технологией блокчейн. Все происходит по следующему сценарию. Большая компания узнает о том, что blockchain – это технология будущего. Большая компания находит людей извне, которые работают с банковскими технологиями для обращения криптовалюты биткойн. Большая компания выделяет им бюджет и поручает сделать что-нибудь «блокчейновое». И вскоре эти умельцы приходят к MultiChain и, размахивая деньгами, просят нас помочь им выдумать какой-то сценарий использования.
А что не так с теми, у кого действительно есть идея проекта? Очень часто проект может быть замечательно реализован при помощи обычной реляционной базы данных. Это такие железные чудища, как Oracle и SQL Server, а для менее предубежденных – MySQL и Postgres. Так что позвольте начать, расставив все точки над «i»:
Если современные реляционные базы данных удовлетворяют вашим требованиям, то нужно быть сумасшедшим, чтобы использовать блокчейн.
Почему? Потому что такие продукты, как Oracle и MySQL проверены десятилетиями разработки. Они были установлены на миллионах серверов, обрабатывающих триллионы запросов. Их код был наиболее тщательно тестирован, оптимизирован и отлажен в сравнении с другими на планете Земля. Они, не напрягаясь, обрабатывают тысячи транзакций в секунду. Ну и что у нас с блокчейн? Существуют продукты, которые стали пионерами рынка и отличаются относительной стабильностью. Но несмотря на это, все продукты данной категории, образно выражаясь, все еще сидят в подгузниках.
Пытаюсь ли я доказать, что технология блокчейн бесполезна? Никак нет. Но до того, как с разбегу прыгнуть в такой передовой и блестящий блокчейн-проект, вы должны выработать четкое понимание, зачем вы используете блокчейн . Есть несколько условий, которые должны быть выполнены. А если нет, то вам стоит вернуться к этапу проектирования. Может быть, вы могли бы лучше обозначить и детальнее описать проект. Может быть, вам удастся сэкономить для всех тонны времени и средств, потому что технология блокчейн вам вообще не нужна.
1. База данных
Вот первое правило. Блокчейн – это технология для баз данных общего пользования. Поэтому вам стоит начать с понимания того, зачем вы используете базу данных. Здесь я имею ввиду структурированное хранилище информации. Это может быль традиционная реляционная база данных с одной или более электронными таблицами. Или это могут быть более трендовые базы данных NoSQL, которые работают больше как системы файлов или словари. (В любом случае, в теории базы данных NoSQL являются подмножеством реляционных баз данных). Регистр для финансовых активов обычно может быть выражен в виде таблицы базы данных, в которой каждая строка представляет один вид активов, принадлежащих одной конкретной сущности. Каждая строка содержит три колонки, содержащие: (а) идентификатор владельца, например, номер счета; (б) идентификатор типа активов, например, «USD» или «AAPL»; (в) количество единиц актива на счету конкретного владельца.
Базы данных модифицируются с помощью «транзакций», представляющих собой набор изменений в базе данных, которые должны быть приняты или отклонены. Например, в случае учета активов платеж от одного пользователя к другому представлен транзакцией, которая вычитает соответствующее количество средств из одной строки и добавляет его в другую.
2. Множество авторов.
Это простое правило. Блокчейн – это технология для баз данных с множеством авторов. Иными словами, должно быть больше одной сущности, которые генерируют транзакции, модифицирующие базу данных. Вы знаете, кто такие эти авторы? В большинстве случаев авторы также будут поддерживать ноды, содержащие копию базы данных, и ретранслировать транзакции другим узлам в пиринговом режиме. Однако транзакции для запуска узла сами также могут быть созданы пользователями, которые не поддерживают ноды. Рассмотрим, например, систему платежей, которая коллективно поддерживается небольшой группой банков, но имеет миллионы конечных пользователей с мобильными устройствами, которые взаимодействуют только с системой выбранного ими банка.
3. Отсутствие доверия
И теперь перейдем к третьему правилу. Если несколько сущностей изменяют базу данных, то между ними должно быть определенное недоверие. Другими словами, блокчейн – это технология для баз данных с множеством авторов, не доверяющих друг другу.
Можно подумать, что недоверие возникает только между отдельными организациями, такими как банки или компании, участвующие в цепочке поставок. Но недоверие появляется и внутри одной крупной организации, например, между отделами или при совершении операций в различных странах.
Что именно я имею в виду говоря об отсутствии доверия? Я говорю о том, что один пользователь не желает, чтобы другой пользователь изменял строки в базе данных, которые «принадлежат» ему самому. Точно так же, когда речь идет о чтении содержимого базы данных, пользователь не будет принимать на веру «правду» другого пользователем, потому что каждый из них имеет различные экономические или политические мотивации.
4. Транзакции без посредников
Итак, до сих пор проблема заключалась в том, что к базе данных имеют доступ многочисленные авторы, не доверяющие друг другу. Но имеется хорошо известное решение этой проблемы: доверенный посредник. Это тот, кому доверяют все авторы даже с учетом того, что они не доверяют друг другу. И действительно, в мире полно таких баз данных, и к ним относятся и реестры аккаунтов в банках. Ваш банк контролирует базу данных самостоятельно и следит за тем, чтобы каждая транзакция была валидна и проводилась авторизированным пользователем, средства которого перечисляются со счета на счет. И как бы вежливо вы не просили, ваш банк никогда не позволит вам непосредственно вносить изменения в его базу данных.
Блокчейн отсекает необходимость в доверенных посредниках, позволяя множеству не доверяющих друг другу авторов непосредственно вносить изменения в базы данных. Нет никакой инстанции, проверяющей валидность транзакций и аутентичность их источников. Вместо этого определение транзакции расширено и включает в себя доказательство авторизации и доказательство валидности. Таким образом, транзакции могут быть независимо верифицированы и обработаны каждым нодом, который располагает локальной копией базы данных.
Но вот вопрос, который вы должны себе задать: хотите ли вы и нуждаетесь ли вы в отказе от посредников? Если взять ваш случай, действительно ли вам мешает центральная организация, которая поддерживает заслуживающую доверия базу данных и действует как посредник в транзакциях? Хорошие причины отказа от доверенного посредника в пользу баз данных блокчейн – это, например, большая экономия средств, более быстрые транзакции, автоматическое согласование счетов или невозможность найти подходящего посредника.
5. Взаимодействие транзакций
Итак, технология blockchain хороша для баз данных с множеством авторов, которые не доверяют друг другу и которые непосредственно изменяют базу данных. Но этого все еще недостаточно. Блокчейн в полной мере окупает себя тогда, когда созданные этими авторами транзакции взаимодействуют между собой.
Что я имею ввиду, говоря о взаимодействии? Это когда транзакции, созданные разными авторами, часто зависят друг от друга. К примеру, скажем, Алиса отправляет средства Бобу и затем Боб отправляет средства Чарли. В этом случае транзакция Боба зависит от транзакции Алисы, и нет другого способа проверить транзакцию Боба без предварительной проверки транзакции Алисы. Благодаря этой зависимости вместе эти транзакции принадлежат к единой распределенной базе данных.
Развивая данную тему, замечательной особенностью блокчейна является то, что транзакции могут создаваться совместно многими авторами, при этом никто не берет на себя риск. Именно это позволяет решить проблему очередности оплаты без необходимости в доверенном посреднике.
Менее наглядный случай взаимодействия – это когда транзакции разных авторов коррелируют между собой, оставаясь независимыми. Одним из примеров может быть распределенная база с личными данными, в которой множество сущностей подтверждает различные аспекты личностей потребителей. Несмотря на то, что каждая из проверок производится отдельно, блокчейн позволяет пользователю объединить все изменения.
6. Установка правил
Это не условие, но скорее неизбежное следствие предыдущих условий. Если у нас есть база данных, в которую вносят изменения многие авторы, и эти авторы не доверяют друг другу в полной мере, то эта база данных должна предусматривать правила, в соответствии с которыми проводятся транзакции.
Эти требования существенно отличаются от ограничений, которые есть в традиционных базах данных, потому что они касаются законности преобразований, а не состояния базы данных в конкретное время. Каждая транзакция проверяется каждым узлом в данной сети на соответствие этим требованиям. Те транзакции, которые требованиям не соответствуют, отклоняются еще до проведения.
Книги для учета активов содержат простой пример этого типа правила, чтобы предотвратить транзакции, создающие активы на пустом месте. Согласно этому требованию, общее количество каждого актива в реестре остается неизменным до и после каждой транзакции.
7. Выберите своих валидаторов
Итак, мы описали распределенную базу данных, в которой транзакции могут исходить из разных источников, распространяться от одного узла к другому и проверяться каждым узлом независимо. Таким образом, что же делает блокчейн? Здесь работа этой технологии состоит в том, чтобы быть окончательной версией журнала транзакций, заслуживающей доверия, с содержанием которого все узлы согласны, и это можно доказать. Зачем нам нужен этот журнал? Во-первых, это позволяет недавно добавленным узлам вычислить содержание базы данных с нуля и без необходимости доверия другому узлу. Во-вторых, это предусматривает возможность того, что некоторые узлы могут пропустить некоторые транзакции из-за сбоев связи. Без журнала транзакций это стало бы причиной того, что база данных одного узла отличается от других, что противоречит назначению распределенных баз данных.
В-третьих, есть возможность того, что две транзакции конфликтуют, и только одна из них может быть принята. Классическим примером этого является двойная трата, при которой одинаковое количество средств отправляется двум разным получателям. В базе данных, функционирующей по пиринговому принципу без центрального администратора, узлы могут иметь разные мнения относительно того, какую транзакцию стоит принять, потому что в данном случае объективного правильного ответа нет. Требуя подтверждения транзакций в блокчейне, мы гарантируем то, что все узлы будут согласны с единым решением.
И, наконец, в блокчейнах типа Ethereum точный порядок транзакций играет решающую роль, поскольку каждая транзакция может повлиять на последующую. В этом случае блокчейн определяет хронологию событий, без которых транзакции не могут быть обработаны.
Блокчейн – это цепь блоков, в которой каждый блок содержит набор транзакций, подтверждаемых как группа. Но кто несет ответственность за выбор транзакций, которые идут в каждом блоке? Для «частных блокчейнов», которые подходят для корпораций, это закрытая группа валидаторов (майнеров), оставляющих цифровую подпись в создаваемых ими блоках. Этот белый список совмещается со схемой распределенного консенсуса для того, чтобы предотвратить получение контроля над блокчейном меньшинством валидаторов.
Независимо от того, какая используется схема консенсуса, узлы-валидаторы имеют гораздо меньше власти, нежели администраторы традиционной централизованной базы данных. Валидаторы не могут подделать транзакцию или модифицировать базу данных в разрез правилам. Когда речь идет об учете активов, это значит, что они не могут потратить деньги других людей или изменить общее количество представленных активов. Тем не менее, все же есть два случая, когда валидаторы могут ненадлежащим образом повлиять на контент базы данных:
Цензурирование транзакций. Если достаточное количество валидаторов вступят в сговор, то они могут предотвратить подтверждение конкретной транзакции в блокчейне, постоянно оставляя ее в пуле неподтвержденных транзакций.
Предвзятое урегулирования конфликтов. Если две транзакции конфликтуют, то следующий блок валидатор решает, какая транзакция в блокчейне будет принята, а какая в результате этого будет отклонена. Справедливый выбор – это транзакция, которая появилась ранее, но валидаторы могут основывать свой выбор на других факторах, не выказывая этого.
Из-за этих проблем при развертывании блокчейн-базы данных вы должны иметь четкое представление о том, кто ваши валидаторы и почему вы доверяете им. В зависимости от случая, валидаторы могут быть выбраны в качестве: (а) одного или нескольких узлов, управляемых с помощью единой организации, (б) основной группы организаций, которые поддерживают цепь, или (с) каждого узла сети.
8. Обеспечивайте свои активы
Если вы дочитали до этого места статьи, то вы могли заметить, что я скорее отношу блокчейны к распределенным базам данных, нежели к «распределенным учетным книгам», что является более привычным. Почему? Потому что как технология блокчейн может быть применена к проблемам, лежащим за границами отслеживания прав собственности на активы. Любая база данных, которая имеет множество не доверяющих друг другу авторов может быть реализована посредством блокчейн без необходимости в доверенном посреднике. Среди примеров можно назвать распределенные календари, форумы и совместные проекты типа «Википедии».
В настоящий момент блокчейны в основном представляют интерес для тех, кто отслеживает движение финансовых активов. На мой взгляд, этому есть две причины: (а) финансовый сектор отвечает на (пока очень незначительную) угрозу таких криптовалют, как биткойн, и (б) книга учета активов является наиболее простым и естественным примером распределенной базы данных с взаимозависимыми транзакциями, создаваемыми множеством сущностей, не доверяющих друг другу.
Если вы хотите использовать блокчейн для учета активов, необходимо ответить на еще один важный вопрос: какова природа этих активов? Я не имею в виду наличные, облигации или коносаменты, хотя это тоже очень важно. Вопрос скорее в том, кто стоит за активами, представленными в блокчейне? Если в базе есть информация о том, что мне принадлежит 10 единиц чего-то, кто позволит мне претендовать на эти 10 единиц в реальном мире? На кого я могу подать в суд, если не смогу преобразовать то, что у меня есть в блокчейне в традиционные физические активы? (См. пример соглашения об активах).
Конечно же, ответ на этот вопрос зависит от конкретного случая применения. К примеру, для денежных активов банки-кастоди могут принимать наличные в традиционной форме и затем зачислять средства на аккаунты пользователей в распределенной системе учета, созданной на базе блокчейна. В сфере финансирования торговли аккредитивы и коносаменты могут быть обеспечены банком импортера и транспортной компании соответственно. Вероятно, что в более отдаленном будущем основной выпуск корпоративных облигаций будет осуществляться непосредственно с помощью блокчейна компанией, стремящейся привлечь средства.
Заключение
Как я уже упоминал во вступлении, если ваш проект не удовлетворяет хотя бы одному из этих критериев, вам не следует использовать блокчейн. Если не выполнено одно из первых пяти условий, то вам стоит использовать что-либо из следующих решений: (а) обычное файловое хранилище, (б) централизованная база данных, (в) реплицированная база данных, (г) несколько баз данных с подпиской для пользователей.
И если первые пять условий выполнены, это еще не все — вам нужно будет обозначить правила вашего приложения в терминах транзакций, разрешенных базой данных. Вы должны быть уверены в своих валидаторах и в своем механизме распределенного консенсуса. И наконец, если вы собираетесь создать распределенную систему учета активов, вы должны знать, кто обеспечит эти активы.