Автор: PolkaWorld

Гэвин Вуд, соучредитель Ethereum, создатель Polkadot и сторонник видения Web3.

Перед тем как официально начать, давайте поделимся некоторыми высказываниями Гэвина в этой части!

Какое самое большое достижение Ethereum на сегодняшний день? — Возможно, это CryptoKitties, я не знаю, на самом деле не очень уверен. Я слышал, что Ethereum создал больше всего миллионеров в истории.

Является ли Ethereum успешным проектом? — Если смотреть по моим критериям успеха? Очевидно, что не все критерии соответствуют, возможно, лишь малая их часть. Конечно, он финансово успешен.

С введением JAM направление Polkadot изменилось. Это можно рассматривать как нативную Rollup-хостинговую цепочку, а разработанные нами технологии значительно превосходят оптимистичные Rollup и Rollup с нулевыми знаниями на Ethereum.

Какое самое большое достижение Polkadot на сегодняшний день? — Реализация безопасной шардированной блокчейн-технологии.

Какова самая большая проблема, с которой сегодня сталкивается Polkadot? — Это именно шардирование.

Как решить эти проблемы? — JAM

Продолжайте читать, чтобы увидеть весь контент!

Какое самое большое достижение Ethereum на сегодняшний день?

Кевин: Значит, ты говоришь, что в 2014 году ты стал соучредителем Ethereum? Почему ты присоединился к ним как соучредитель и технический директор?

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

Кевин: Что это?

Гэвин: Это, по сути, оптимистичный взгляд на общество и развитие, который, вероятно, возник в Западной Европе около четырех-пятисот лет назад.

Кевин: Какое самое большое достижение Ethereum на сегодняшний день?

Гэвин: Возможно, это CryptoKitties, я не знаю, на самом деле не очень уверен. Я слышал, что Ethereum создал больше всего миллионеров в истории. Возможно, это связано с тем, что во время краудфандинга участвовало много людей, а цена затем выросла до достаточно высокого уровня. Так что, возможно, это и есть его самый большой вклад. Но, честно говоря, трудно сказать, насколько он действительно достиг чего-то полезного. Он определенно не соответствовал моим ожиданиям, которые у меня были 10 лет назад.

Кевин: Так что, если я спрошу тебя, считаешь ли ты, что Ethereum — это успешный проект? Твой ответ отрицательный?

Гэвин: Мой ответ таков: считаю ли я его успешным? Если смотреть по моим критериям успеха? Очевидно, что не все критерии соответствуют, возможно, лишь малая их часть. Конечно, он финансово успешен. Я думаю, возможно, один или два соучредителя Ethereum, возможно, изначально ожидали, что он будет работать лучше.

Кевин: Какие критерии могут заставить тебя считать его успешным?

Гэвин: Полезность (Utility)

Кевин: Как измерить полезность?

Гэвин: Способ измерения полезности — это посмотреть, сколько вещей люди сейчас могут делать, чего раньше они не могли.

Кевин: Разве это не проблема всей криптоиндустрии, а не только Ethereum?

Гэвин: Это действительно так. Это проблема, с которой сталкивается вся криптоиндустрия. В 2014 и 2015 годах мы предложили много идей, пытаясь разблокировать некоторые ранее недоступные экономические области с помощью «безопасного доверия». Один из примеров, который мне особенно нравится, — это цепочка поставок. Например, когда вы идете в супермаркет, на всех товарах есть QR-код, который вы можете отсканировать, чтобы узнать все составные части этого товара: когда, где и сколько и так далее. Я бы хотел знать, откуда поступает хлопок, когда я покупаю футболку.

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

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

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

Почему вы ушли из Ethereum?

Кевин: Почему вы ушли из Ethereum в 2016 году?

Гэвин: На самом деле, это было в конце 2015 года. Тогда мы решили, что Ethereum нужно сделать много вещей, чтобы быть более широко принятой. Мы искали внешние инвестиции, и один из самых очевидных способов — это создать стартап, связанный с Ethereum, и искать внешнее финансирование для него. Это было первоначально решено Виталиком и Джеффом (основные разработчики и инженеры).

Позже Джефф не очень адаптировался к жизни в стартапе. На самом деле, он быстро покинул Ethereum, чтобы заняться своей карьерой в видеоиграх. Так что в итоге остался только Виталик. Виталик считал, что ему необходимо продолжать оставаться в Фонде Ethereum и выполнять более академическую роль, одновременно выступая советником компании Ethcore, которую мы тогда создали.

Мы тогда собрали некоторые средства, перевели приблизительно половину технической команды Фонда Ethereum в Ethcore и разработали клиент Ethereum. Я покинул Фонд Ethereum в конце 2015 года, на самом деле, чтобы создать эту дочернюю компанию, с целью добавить в экосистему Ethereum сущность, поддерживаемую частными инвестициями.

Однако я полностью покинул экосистему Ethereum в конце 2017 года, когда основал Polkadot.

Polkadot разрабатывает технологию Rollup.

Кевин: Если бы ты объяснил своей маме, что такое Polkadot, что бы ты сказал?

Гэвин: Эм... За эти годы Polkadot претерпел некоторые изменения. Изначальное видение заключалось в интеграции различных архитектур блокчейнов, чтобы они могли быть совместимыми и делиться одной и той же безопасной основой. Благодаря такой общей безопасности можно значительно повысить экономическую эффективность. Например, если правильно спроектировать, можно защитить 100 цепочек одновременно за те же деньги, вместо того чтобы каждая цепочка, как в других проектах (например, Cosmos), нуждалась в независимой защите.

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

Сейчас, с введением JAM, это направление претерпело некоторые изменения. Технологии, которые мы разрабатываем для Polkadot, можно рассматривать как технологию Rollup, а сам Polkadot может считаться специально разработанной Rollup-хостинговой цепочкой. Разработка и проектирование этой технологии не являются простыми, поэтому неудивительно, что мы видим, как другие две конкурирующие технологии значительно уступают разработанным нами технологиям для Polkadot. В частности, это оптимистичные Rollup (Optimistic Rollups) и Rollup с нулевыми знаниями (ZK Rollups), которые уже используются на Ethereum. Таким образом, мы можем описать Polkadot как нативную Rollup-хостинговую цепочку — конечно, это определение может не подойти для объяснения маме, но для тех, кто понимает крипто-сферу, это приемлемо.

Через JAM, то есть следующую цель развития Polkadot, мы пытаемся преобразовать Polkadot из мультицепочной модели в более универсальную модель вычислительных ресурсов. В мультицепочной модели различные цепочки Polkadot (в системе Polkadot называемые параллельными цепочками) делят одну и ту же безопасную основу и могут взаимодействовать друг с другом. В новой модели наша цель — еще больше расширить область применения Polkadot, как Ethereum расширил базовые функции Bitcoin в универсальный вычислительный ресурс. Мы хотим убрать чрезмерные субъективные ограничения проектирования, чтобы Polkadot поддерживал более широкий спектр случаев использования.

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

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

Самым большим достижением Polkadot на сегодняшний день является его самая большая проблема.

Кевин: Я думаю, ты, возможно, имеешь в виду тот факт, который, как мы все знаем, на самом деле вызывает много путаницы в нынешней экосистеме Ethereum. Так что, каково самое большое достижение Polkadot на сегодняшний день?

Гэвин: Реализация безопасной шардированной блокчейн-технологии.

Кевин: Какова самая большая проблема, с которой сегодня сталкивается Polkadot?

Гэвин: Это шардирование.

Кевин: Что это конкретно означает?

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

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

Каждый ящик можно рассматривать как шард. Они работают независимо друг от друга: вы можете открыть один ящик, не открывая другие, и можете искать в одном ящике, не просматривая все ящики. Это контрастирует с одним особенно длинным ящиком (например, 10 метровым ящиком). Если бы был только один длинный ящик, это было бы явно непрактично, потому что вам понадобилась бы 10-метровая комната, чтобы разместить его. А когда вы ищете человека, чье имя начинается на «W», вам, возможно, придется вытащить весь ящик и пройтись по ящику до места «W», что явно неэффективно.

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

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

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

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

Другой подход заключается в том, чтобы позволить ящикам общаться друг с другом, отправляя сообщения. Один ящик (шард) может отправить сообщение, и это сообщение позже будет передано в другой ящик. Именно это Polkadot делает с помощью XCM (межконсенсусной передачи сообщений). Хотя такой способ возможен, проблема в том, что он не может обеспечить близкое, эффективное и гибкое взаимодействие, это не так плавно, как когда все работает в одном пространстве или «игровой площадке».

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

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

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

В смарт-контрактах ситуация аналогична. Некоторые смарт-контракты не так сложно работать в этой модели, может быть, они просто немного медленнее, чем обычно, но это не большая проблема. А некоторые сценарии, такие как верификация личности (KYC), относительно просты. Например, у вас может быть одна цепочка, отвечающая за верификацию личности, а другая цепочка обрабатывает переводы. Цепочка переводов может потребовать подтвердить, прошел ли целевой адрес проверку KYC и AML, прежде чем выполнить перевод. Она может отправить сообщение, спрашивая: «Прошел ли этот адрес проверку KYC и AML?» Цепочка верификации отвечает: «Да», после чего цепочка переводов выполняет перевод. Весь процесс может занять несколько дополнительных секунд, но это не проблема.

Тем не менее, есть и другие случаи использования, такие как децентрализованные биржи (DEX), которые гораздо сложнее. Например, вам нужно спросить текущую цену, а затем решить, делать ли сделку. В этом случае вам может потребоваться отправить сообщение на другую цепочку, которая отвечает: «Текущая цена такая-то, сделка может быть завершена таким образом». Затем сообщение возвращается на оригинальную цепочку, которая подтверждает: «Я принимаю эту цену, пожалуйста, выполните сделку». Но когда сделка почти завершена, другая цепочка может снова сказать: «Цена изменилась, теперь она такая-то». Сообщения будут передаваться взад-вперед, и вскоре весь процесс станет очень неэффективным и даже невозможно завершить.

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

Решение — это JAM.

Кевин: Какие возможные решения?

Гэвин: Эм, JAM — это мое предложение, которое означает Join Accumulate Machine (Машина Объединённого Накопления).

Кевин: Что такое JAM?

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

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

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

Если мы реализуем систему более гибким способом, можно представить систему, которая одновременно может масштабироваться и поддерживать синхронное объединение. Ее суть в том, что «состояние» не будет разделено навсегда. Другими словами, игроки не будут жестко привязаны к определенной игровой площадке, а будут динамически группироваться в реальном времени по мере необходимости. Система будет делить игроков на разные группы в зависимости от фактических потребностей и продвигать игру в соответствии с этими группами.

В сценарии смарт-контрактов реализация этой концепции похожа на то, чтобы поместить все смарт-контракты в общий большой «плавильный котел», но этот котел не заставляет все контракты постоянно взаимодействовать друг с другом, а способен динамически разделять их. Например, система может извлекать 10, 50 или 2 смарт-контракта из этого котла, объединять их, позволяя им синхронно взаимодействовать и работать, а затем снова разделять их. Затем система переоценивает, выбирает другой набор смарт-контрактов и снова объединяет их для работы, а затем снова разделяет.

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