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

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

  • Блокчейн — это общий термин, который включает в себя кульминацию многих современных технологий (очевидных, но недооцененных).
  • Блокчейн — это, по сути, распределенная база данных, поэтому любое корпоративное решение требует полной реализации ряда других технологий.
  • Будучи децентрализованной технологией, блокчейн будет значительно сложнее по сравнению с централизованным решением. Корпоративное внедрение всегда будет происходить на фоне повышенного риска и затрат на внедрение технологии блокчейн по сравнению с затратами (временем и усилиями) на ручную сверку.

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

Обо мне

  • Возраст: 26 лет
  • Гороскоп: Рак
  • Тип личности: INTJ
  • Любит: много думать
  • Ненавидит: слишком много думать
  • Любимая фраза: «Я волевой, не упрямый» — я маме

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

Беглый взгляд на статьи, которые я написал, дал бы ответ на вопрос, почему я нахожу технологию блокчейна такой интригующей, но в основе всего этого лежит еще более фундаментальный интерес к проектированию систем и его влиянию на человеческое взаимодействие. Я действительно считаю, что проектирование систем является средством реализации индивидуальных действий, которые затем объединяются в выгоды или затраты на уровне общества. Это то, что привело меня к получению степени в области городского планирования и недвижимости, поскольку было интересно посмотреть, как экономия земли повлияла на функционирование общества (вспомните SimCity). Сочетая это с моим отношением любви/ненависти к чрезмерному размышлению о технологиях и будущем, нетрудно понять, почему я был очарован, прочитав технический документ Биткойн.

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

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

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

Основные блоки блокчейна

Существует огромное количество технологий, которые предшествовали техническому документу Биткойн, и на то есть веские причины. Блокчейн — это, по сути, код, написанный для работы на разных машинах, чтобы обеспечить связь в рамках определенного набора заранее согласованных правил, применяемых сетевой политикой. Понять, как происходит единичное изменение данных на вашей собственной машине, уже достаточно сложно, поскольку для этого требуется понимание того, как программное обеспечение взаимодействует с базовым оборудованием. Понимание того, как отдельный фрагмент данных синхронизируется в сети машин, повышает уровень сложности, потому что теперь вам нужно начать беспокоиться о различиях машин. Это тем более важно, когда вы не владеете этими машинами, но все же хотите, чтобы они были синхронизированы. Учитывая, что это задача, которую решает блокчейн, хорошо продуманное решение зависит от понимания сложностей на каждом этапе.

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

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

Абстракция: управление умственной нагрузкой и детали реализации

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

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

Эта ментальная модель может показаться довольно расплывчатой ​​и слишком общей, когда вы только начинаете, но трудно переоценить важность такого подхода, когда речь идет о компьютерных системах. Основная причина этого заключается в том, что большинство новых технологий создается в контексте существующих технологий. Например, даже для того, чтобы простое Hello World! отображалось в вашем браузере, требуется, чтобы ваш браузер связывался с сервером, интерпретировал то, что было записано, и сообщал аппаратному обеспечению вашего компьютера, как отображать слова. Мало того, что было бы невозможно построить это с нуля, учитывая количество и скорость накопления знаний, вы также отказались бы от гарантий, предоставляемых существующими решениями.

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

  • Вам просто нужно было перейти по ссылке на эту страницу и определить, стоит ли ее содержание вашего времени. Вы (предположительно) ничего не знаете о том, как оно было доставлено вам, и вам не нужны такие подробности.
  • Я, как автор, должен убедиться, что делюсь правильной ссылкой после публикации статьи на платформе Medium. То, как она хранится, меня не беспокоит, пока я знаю, что эта история доступна каждый раз, когда кто-то щелкает ссылку, которой поделились.
  • Инженеров команды Medium не должно беспокоить, что на самом деле написано в этой статье, но их менеджеры будут беспокоиться, если эта статья вдруг станет недоступной.
  • Команду среднего бизнеса не особо интересует содержание статьи, а скорее данные о взаимодействии, помеченные моей статьей, которые, вероятно, будут отдельной точкой данных на их информационных панелях.

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

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

  • Вычисления. Где выполняется ваша программа? Как запускается программа? Какой путь проходят данные через вашу программу?
  • Сеть. С какими внешними системами или пользователями должна взаимодействовать ваша программа? Как ваша программа будет получать доступ и интерфейс соответственно?
  • Хранилище. Где ваша программа считывает или хранит информацию во время и после запуска? Хранилище постоянное? Какие виды данных вы храните?

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

Когда вы только начинаете свой путь программирования, особенно легко развить туннельное зрение, поскольку вы просто пытаетесь заставить свой код работать. Делая шаг назад и размышляя о более широкой картине, вы можете задавать правильные вопросы, поскольку это обеспечивает контекст для возможного решения. Это сэкономит вам часы поиска точного решения, потому что вы больше не ищете узнаваемый шаблон, а скорее рассуждаете о решении (поверьте мне, я был там).

Углубление в код

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

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

  • От человека к человеку: передача своих идей единомышленникам, что является ключом к тому, чтобы их идеи набирали обороты. Основное внимание уделяется дополнению их знаний за счет помощи ключевых людей с техническими навыками, необходимыми для тестирования, создания и улучшения их идеи. Учитывая, что большая часть кода не пишется изолированно, решение также зависит от понимания идей их предшественников.
  • Межмашинное взаимодействие. Принятие решения населением будет зависеть от того, насколько хорошо их решение решает реальные проблемы. Это также, вероятно, будет означать, что их код должен будет работать на множестве взаимосвязанных устройств, используемых разными людьми. Таким образом, основное внимание уделяется тому, чтобы решение работало максимально эффективно, чтобы обеспечить наилучшую производительность для людей, которые его используют.
  • Человек-машина:компьютерная логика не интуитивно понятна для нас, а наш человеческий язык слишком общий для компьютеров. Затем основное внимание уделяется поиску баланса между удобочитаемостью для человека и производительностью машины.

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

Это особенно важно, учитывая, что никому трудно понять масштабы, в которых работают компьютеры сегодня. Например, любой современный компьютер сможет выполнять сто миллиардов (100 000 000 000 или 10¹¹) инструкций в секунду с тактовой частотой в диапазоне гигагерц (1 000 000 000 или 10⁹). В результате сегодня для большинства приложений узким местом является не аппаратное обеспечение, а информация, которую мы ему передаем. В конечном счете, данные заняли центральное место, поскольку технологии стали более интенсивно использовать данные, а не вычислительные ресурсы.

Бинарный мир компьютеров и красота человеческого языка

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

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

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

Все компьютерные языки предоставляют разработчикам стандартный способ сообщить машине о своих намерениях, одновременно делясь этими намерениями с другими разработчиками. Хитрость заключается в том, что любые данные на компьютере по сути являются бинарными. Одна и та же комбинация единиц и нулей может означать что угодно без контекста. Например, если у нас есть четыре бита 1010, это может означать число 10 в двоичном формате [(1 x 2³) + (0 x 2²) + (1 x 2¹) + (1 x 2⁰)], 10-й элемент в списке. , или это может относиться к определенному оттенку черного на шестнадцатеричной цветовой диаграмме. Неудивительно, что все очень быстро усложняется, когда вы пытаетесь объединить данные из разных источников. Смешивание типов данных приведет к тому, что данные станут бесполезными, поскольку компьютер не будет знать, как интерпретировать полученные единицы и нули.

Чтобы сбалансировать удобочитаемость, многие языки решают эту проблему, устанавливая правила о том, как разработчики могут объявлять переменные и как такие переменные могут быть неявно преобразованы машиной. В таких языках, как javascript, разработчику не нужно указывать тип при объявлении переменной, поскольку машина делает это посредством логического вывода. Скрывая эту деталь, javascript становится более гибким для разработчика, но разработчику не предоставляются какие-либо гарантии того, как будут обрабатываться данные. Следовательно, устранение неполадок программ javascript может стать кошмаром, поскольку эта непрозрачность приводит к тому, что возможные проблемы становятся безграничными. Чтобы обойти эту проблему, не нарушая привычный нам Интернет, Microsoft создала машинописный текст, который добавил дополнительные требования к объявлению типов переменных. Даже из истории одного языка нетрудно понять, почему понимание обработки типов жизненно важно для понимания дисциплины программирования в целом.

Распределенные системы и растущая сложность

Подумайте о групповых проектах, которые вас заставляли делать в университете. Обязательно будут времена, когда вы думали, что будет намного проще просто делать все самому, чем тратить столько часов на групповые собрания, решая, кто что делает. Сначала группа должна договориться о том, как распределить рабочую нагрузку с учетом индивидуальных способностей и доступных ресурсов для каждого члена, прежде чем какая-либо работа будет выполнена. Со временем это становится легче, поскольку вы начинаете привыкать к шаблонам друг друга, и достаточно скоро распределение рабочей нагрузки занимает все более незначительное количество общего времени проекта. Случилось так, что ваша команда установила свой собственный набор правил: человек А берет на себя инициативу, человек Б занимается исследованием, человек С подготавливает графику, человеку Г поручают некритическую работу, потому что у него всегда так много чрезвычайных ситуаций, которые необходимо выполнить. . Эти правила очень сложны для первоначальной настройки, потому что команда должна настроить рабочий процесс, оценить возможности/ресурсы команды и договориться о том, что является справедливым распределением. Тем не менее, однажды созданная группа способна с относительной легкостью справляться с более сложными проектами.

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

На одной машине у вас есть полное представление о том, как работает ваша программа, поскольку у вас есть полный контроль над машиной. С точки зрения машины это также означает, что она может планировать свою собственную рабочую нагрузку, поскольку она несет единоличную ответственность за выполнение программы, которая либо завершается успешно, либо полностью терпит неудачу. Это хорошо для изолированных рабочих нагрузок, но, как упоминалось выше, многие из технологий, на которые мы полагаемся сегодня, получают свою ценность от того, что являются частью сети. Взрывной рост Интернета за несколько коротких лет является доказательством этого. Популярный сейчас закон Меткалфа (стоимость сети = число участников в квадрате) был прямым следствием этого, но он почти никогда не уравновешивается сложностями управления такой сетью.

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

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

Например, мой запрос к www.google.com мог быть доставлен мне с их сингапурского сервера, но тот же сервер может быть недоступен через час по множеству причин, но я был бы неразумен, так как другой сервер будет там для обслуживания моего запроса, что приведет к я прихожу на ту же домашнюю страницу Google. Следует отметить, что Google несет ответственность за ответ на мой запрос только тогда, когда его серверы получают его, но мой запрос по-прежнему должен проходить через мой ноутбук и различные другие сетевые устройства, которые находятся за пределами домена Google. Это также верно и для обратной поездки, которая в конечном итоге приводит к тому, что я вижу домашнюю страницу Google в своем браузере. В конечном счете, невозможно гарантировать, что эти данные были обработаны должным образом, поскольку каждый участник сети имеет лишь частичное представление о полном потоке данных. Это причина того, почему ошибки тайм-аута настолько распространены, поскольку трудно определить причину таких сбоев и гораздо легче предположить, что что-то пошло не так, если ответ не получен через заданное время.

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

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

При этом достижение консенсуса по-прежнему сложно, учитывая необходимость учитывать время обновлений на разных машинах и то, что такие обновления могут дать сбой на одних машинах, но не на других. То, как такие системы предназначены для решения этих проблем, является источником десятилетий исследований, и достаточно сказать, что я не смогу осветить даже самую суть этого в такой статье. Вместо этого я хочу обратить ваше внимание на то, что системы блокчейна представляют собой объединение многих абстрактных идей, которые были созданы для того, чтобы обойти ограничения реального мира. Эти ограничения ограничены реальностью и, следовательно, не изменятся, даже если абстрактные системы будут продолжать развиваться для более эффективного решения таких проблем. Поэтому очень важно понимать эти ограничения (время передачи данных не является мгновенным, данные могут быть физически потеряны или затронуты случайным образом, машины могут и будут выходить из строя по прошествии достаточного времени), поскольку они обеспечивают контекст для технологического решения. Возможность абстрагироваться от логического дизайна системы, отслеживая при этом, как система физически распределена, будет ключом к созданию более гибких блокчейн-решений.

Взгляд в будущее

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

Общие вычислительные ресурсы:

  • Designing Data-Intensive Applications Мартина Клеппманна: обязательная литература для понимания основ распределенных вычислений. Если бы мне пришлось выбирать только одну книгу, это была бы она.
  • Основы работы в сети Кевина Уоллеса: дает представление о стандартах и ​​политиках, лежащих в основе машинного взаимодействия.
  • Docker и Kubernetes: полное руководство Стивена Гриндера: это ключевая технология, лежащая в основе развития облачных вычислений. Поначалу это может показаться не очень связанным с блокчейном, но многие рассматриваемые концепции являются отправной точкой для понимания распределенной архитектуры в контексте предприятия.

Ресурсы по языку программирования:

  • Учебный курс для веб-разработчиков, автор Colt Steele: отличная отправная точка для знакомства с программированием, так как он представляет ключевые веб-технологии в веселой и увлекательной форме.
  • JavaScript: Полное руководство, 7-е издание Дэвида Фланагана: более глубокое погружение в проектные решения, лежащие в основе языка JS.
  • Ultimate Go Programming Уильяма Кеннеди: очень полезно для объяснения фундаментальных концепций языка, таких как типы, механические симпатии, указатели и т. д.

Ресурсы, посвященные блокчейну:

  • Освоение Биткойна и Освоение Эфириума Андреаса М. Антонопулоса: две ключевые технологии, о которых следует знать любителям блокчейна. Обеспечивает гораздо более простое введение в технический дизайн каждой платформы и то, как они обе различаются с точки зрения архитектуры.
  • Блокчейн от А до Я: узнайте, как построить свой первый блокчейн от команды SuperDataScience: хорошее введение в ключевые концепции блокчейна, если вы предпочитаете его в формате видео. Это скорее отправная точка, с которой вы сможете глубже погрузиться в различные идеи блокчейна.