Ракеты, квантовые угрозы, нули и единицы: Дин Литтл о создании истины Solana

Введение

Блокчейны построены на лжи. Точнее, на вежливой лжи, которая проявляется в слоях абстракции. Разработчик видит мир SDK, API и фреймворков, обещающих скорость и безопасность. Реальность гораздо сложнее: она полна регистров, системных вызовов и байт-кода — и войти в нее осмеливаются лишь одержимые. На деле каждая абстракция создает накладные расходы, а каждый компилятор скрывает истину.

Всю свою карьеру Дин Литтл пробирался сквозь эту ложь в поисках истины, паяя схемы и прошивая EEPROM. Работая с Bitcoin, он создавал майнинговые пулы, GPU-ядра и инструменты SPV, стараясь держаться как можно ближе к машине и изучая потенциал распределенных систем, который в то время так и не удавалось полностью реализовать. Затем он нашел Solana, где прославился своей ересью: ручным написанием ассемблерного кода, пренебрежением к компиляторам и злоупотреблением системными вызовами — не потому, что это весело, а потому, что скорость и есть истина.

На посту главного научного сотрудника Zeus Network он с нуля реализовал весь протокол Bitcoin поверх Solana, обеспечив беспрепятственное перемещение ликвидности BTC. А в качестве неуязвимого для троллей ответа на квантовый FUD он разработал хранилище на основе одноразовой подписи Винтерница, способное переносить десятки тысяч активов в секунду, пока другие лишь мечтают о шести. 

Но Дин еще и преподаватель. От Turbin3 до Blueshift и недавней работы в команде по взаимодействию с разработчиками на рынках мандаринского и кантонского языков в Solana Foundation — он погружает разработчиков в мир, который большинство никогда не увидит. Он научил сотни разработчиков выпускать ончейн-продукты, часто на их родных языках и с самых основ. Он постоянно находится между двумя полюсами: сначала помогает людям подняться с помощью абстракций, а затем направляет их вниз, к машине. 

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

Эта беседа была отредактирована и сокращена. 

Интервью

Истоки и мировоззрение

Ичиго: Задолго до Solana вы ремонтировали оборудование, прошивали EEPROM и писали встраиваемые системы управления для ракет. Как работа настолько близко к железу — буквально с паяльником и прошивками — повлияла на ваше мировоззрение как создателя?

Дин Литтл: Я научился паять примерно в десять лет. В детстве я занимался микропроцессорами и микроконтроллерами, затем перешел к веб- и мобильной разработке, а в итоге присоединился к ракетному стартапу в Норвегии.

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

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

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

Затем ваша карьера быстро привела вас к Bitcoin. Вы работали над майнинговыми пулами, GPU-ядрами, инструментами SPV, а позже — над Twetch. Чему эти годы работы над инфраструктурой Bitcoin научили вас в плане создания масштабных распределенных систем и ограничений блокчейнов того времени?

Примерно в 2017 году я полностью переключился на разработку для Bitcoin. Я создавал продукты для нескольких блокчейнов — Bitcoin, EOS и еще нескольких популярных в то время сетей. Сначала я просто пользовался Bitcoin, но когда комиссии резко выросли, он фактически стал непригоден для использования. Это был первый настоящий наплыв розничных пользователей в криптоиндустрию, и тогда я понял: как только комиссии взлетают, блокчейн становится бесполезным.

Этот опыт заставил меня переосмыслить так называемую «трилемму масштабируемости». Честно говоря, это высосанная из пальца чушь. Еще в 2017 году мы могли передавать фотографии размером 4 МБ по всему миру меньше чем за секунду. Было нелепо верить, что блокчейны не способны масштабироваться дальше блоков по 1 МБ. Ограничение было не в физике, а в архитектуре. 

Поскольку базовый уровень Bitcoin настолько ограничен, приходится внедрять инновации другими способами. Я глубоко погрузился в Secp256k1 и создавал решения для сокрытия результатов выполнения в подписях. Это была своего рода примитивная проверяемая вычислительная система — задолго до того, как ZK по-настоящему набрал популярность.

Эти годы научили меня, что управлять компанией в сфере Bitcoin — значит управлять инфраструктурной компанией. Протокол Bitcoin способен на многое, но ПО ноды ограничено. Модель UTXO отлично подходит для распараллеливания, поскольку состояние разделено — почти как аккаунты Solana, — но ужасна для общего состояния и индексации. Модель аккаунтов Ethereum, напротив, отлично подходит для общего состояния, но плохо — для распараллеливания. В Solana меня привлекла модель разделенных аккаунтов: она объединяет параллелизм UTXO с удобством глобальной модели состояния Ethereum.

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

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

Вопреки распространенному мнению, я участвую в разработке Anchor, Pinocchio, Agave, Alpenglow — фактически всего подряд. Я работал над криптографией, SIMD и низкоуровневыми программами на всех уровнях стека. 

Главная проблема разработки для Solana в том, что все, кроме ончейн-программ и инфраструктуры, полностью контролируется допусками. Добиться слияния моих PR с каким-либо официальным репозиторием почти невозможно. А ончейн-программы? Я могу делать все, что система по недосмотру позволяет мне делать. Там меня ничто не сдерживает. Это среда без разрешений. Я могу просто продолжать улучшать ее и выжимать максимум.

Поэтому вопрос такой: если вы видите мою работу, ее качество и то, что я сделал для ончейн-программ, и хотите таких же изменений на других уровнях стека — начните принимать мои PR, ха-ха.

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

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

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

Технические инновации и вклад

Продолжая тему работы на разных уровнях стека: в Zeus, Jupiter и свободное время вы создали и интегрировали несколько продвинутых криптографических примитивов. Реализовать любую ончейн-криптографию в Solana, как известно, очень сложно. Каким вы видите будущее криптографии в Solana? И если не считать призывов принять PR, ха-ха, как упростить другим разработчикам создание более продвинутых примитивов?

Я считаю, что несколько лет назад целая очередь команд, занимавшихся ZK, хотела создавать продукты на Solana. Мы фактически говорили им: «Да, скоро все будет», а потом появился Firedancer и заявил: «Нет, мы это принимать не будем», — и все отложили. Некоторые из этих команд привлекли финансирование, но буквально не могли вести бизнес из-за отсутствия необходимых ончейн-криптографических примитивов, поэтому были вынуждены уйти в другие экосистемы. Это было очень тяжело. Так обращаться с разработчиками неправильно. Первые клиенты протокола — разработчики. Если о них не заботиться, ничего не будет создано, а розничным пользователям будет нечем пользоваться. 

Поэтому я сказал: ладно, разберусь сам. Я взломал системный вызов Secp256k1 recover и фактически освободил всю кривую от ограничений. Теперь можно использовать подписи Шнорра, обязательства Педерсена, Bulletproofs, произвольное умножение на эллиптической кривой и даже модифицированные адреса Taproot — без единого изменения протокола и всего примерно за 25 000 CU. И все это сделал один человек в свободное время. Я выпустил больше криптографических протоколов, чем Anza, верно? Представьте, что было бы, если бы такую работу действительно поощряли. Представьте, если бы разработка была более открытой. 

Забавно, что большинство людей даже не понимает масштаб этого прорыва. Я прихожу на конференцию и рассказываю кому-нибудь из Arcium, что создал. Они отвечают: «Это невероятно круто». Но кроме, возможно, десяти человек, которые действительно разбираются в криптографии Solana на таком уровне, никто этого особо не замечает. 

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

Как вы думаете, это скорее культурная проблема? Например, у Ethereum есть целые L2, посвященные ZK, — ZKsync или StarkWare. Может быть, Solana просто отмахнулась от ZK как от туманной идеи масштабирования? Мол, мы предпочитаем выжать максимум из оборудования, это наш главный приоритет — так и будем масштабировать сеть. И хотя ZK в Solana необязательно использовать только для масштабирования, его свели именно к этому, из-за чего теперь ZK оказался в странном положении?

Думаю, инструменты недостаточно хороши. Нет ни одного руководства по их использованию. Blueshift добавит несколько — сейчас мы пытаемся влить реализацию Little Endian SIMD. После этого мы выпустим простой в использовании и очень производительный шаблон ZK, а также несколько руководств. Мы хотим упростить людям создание таких решений и понимание их работы.

Сейчас путь от нуля до Hello, World! в Solana совершенно абсурден. Например, в Sui достаточно пять минут следовать документации — и вы получите работающий Hello, World! В Solana такого нет. Вот в чем разница между Mysten Labs, где наняли около десяти специалистов по криптографии, и Anza, где наняли одного, верно?

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

Foundation исходит из того, что дела идут отлично. Но разработчики говорят: «Этим трудно пользоваться». Людям, которые компетентнее тех, кто реализует функции на уровне протокола, безвозмездно выполняют работу, но не могут добиться серьезного отношения к ней, чертовски тяжело. Все выглядит так: «Не знаю, у них нет волшебного значка Anza, проигнорируем их, чтобы не брать на себя репутационные риски и не принимать PR от сообщества». Поэтому, вероятно, вы замечали, что я упорно борюсь за разработчиков ПО с открытым исходным кодом. Я хочу избавиться от такого подхода, потому что многие участники сообщества отправляют действительно хорошие PR. Конечно, много ИИ-мусора и откровенного дерьма, но есть и множество очень талантливых людей, которые заслуживают внимания. Это блокчейн, распределенная сеть — для внесения вклада нам не должен требоваться какой-то значок Anza. Они должны считать своей обязанностью заботиться о хорошем коде независимо от того, кто его написал.

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

Честно говоря, все началось с твита, ха-ха. В конце прошлого года один максималист Bitcoin написал: «Solana станет первой жертвой квантовых вычислений». Я прочитал это и подумал: «Ладно, дружище. Если когда-нибудь понадобится переводить людей с квантово-уязвимой криптографии на квантово-устойчивую, наша сеть сможет выполнять более 50 000 миграций в секунду. Ваша — около шести. Так кого уничтожат первым?»

Тогда я просто сказал: к черту, я это сделаю. 

Через десять дней я выпустил хранилище Винтерница и процитировал его твит с комментарием: GG. 

Вот что меня мотивировало — кто-то заявил, что это невозможно. Я уже некоторое время размышлял о постквантовых схемах подписи, но именно это окончательно подтолкнуло меня.

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

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

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

Вообще, получилось очень забавно. На следующий день Толи написал мне в личку. В шутку он сказал: «Бро, я думал, что с появлением квантовых компьютеров мне придется тихо уйти на пенсию». Я ответил: «Ха-ха, нет, бро, не уходи. Мы тебя прикроем».

Раз уж речь зашла о Bitcoin: вы главный научный сотрудник Zeus Network, где фактически с нуля реализовали весь протокол Bitcoin поверх Solana. Какие трудности были самыми серьезными? И видите ли вы будущее, в котором поверх Solana будут заново реализованы другие сети?

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

С блокчейнами второго поколения, такими как Ethereum, сложнее. Они гораздо менее примитивны и значительно сложнее. Поэтому возникает вопрос: сможет ли Solana становиться все быстрее, одновременно выделяя все больше ресурсов отдельным транзакциям? 

Сейчас это по-прежнему трудно, хотя и возможно. Для совместимости с EVM сегодня в основном не хватает системного вызова BigModExp. Если его включить, думаю, на уровне VM мы сможем почти достичь полного паритета с Ethereum. Даже думать об этом безумно. 

Однако более важный вопрос: зачем вообще это делать? 

С Bitcoin ответ очевиден: его стоимость исчисляется триллионами, это золотой стандарт денег, и он достаточно примитивен, чтобы Solana могла точно его воспроизвести. 

Ethereum? Не особо. 

«Ультразвуковые деньги» — это мем. На короткое время бюджет безопасности Solana действительно превысил бюджет Ethereum. Значит ли это, что Solana — ультразвуковые деньги? Перенос ETH в обертке в Solana дает далеко не столько пользы, сколько перенос BTC в обертке.

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

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

Оракулы — очень интересный предмет для изучения, потому что все считают эту задачу «решенной». 

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

Если это возможно, то полностью рушится весь нарратив о том, что «нам нужны более короткие интервалы между блоками, чтобы конкурировать с Binance». Если оракул можно обновлять сто тысяч раз в секунду, кого волнуют обновления Binance раз в 20 миллисекунд?

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

С Doppler нет особых причин сохранять такую сложность внутри их программ. Обновление оракула можно полностью вынести наружу и запускать отдельно.

Размер тоже крошечный. Оракул Doppler занимает всего около 480 байт. Я даже готовлю TypeScript SDK, чтобы разработчики могли развертывать собственные версии прямо из TypeScript, не прикасаясь к Rust. Вы просто определяете схему Borsh, публикуете ее и начинаете отправлять обновления оракула на полной скорости. Разумеется, разработчики на Rust могут делать то же самое, но интересно, что теперь даже разработчик на TypeScript получает такой уровень производительности благодаря скрытому внутри гипероптимизированному ассемблерному коду.

Что касается вариантов применения: оракулы случайности, бессрочные контракты, оракульные AMM и проприетарные AMM — все они выиграют. То же касается платежных каналов и масштабирования L2. Если каналы можно открывать и закрывать практически бесплатно, это колоссальная возможность. По сути, теперь для простого обновления оракула не нужна огромная неповоротливая программа Anchor. 

Абстракция, ассемблер и IBRL

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

Думаю, каждому стоит хотя бы немного его изучить. У Джорджа Хотца, возможно, лучшего ныне живущего программиста, есть фраза: всем следует изучить Python, C и ассемблер. 

Если вы не понимаете ассемблер, то не понимаете, что на самом деле делает компилятор. Если вы не понимаете C, то не цените всех удобств Python. Я не считаю Python особенно хорошим языком, но Rust, например, очень выразителен и подходит как для высокоуровневой, так и для низкоуровневой работы. Это отличный выбор.

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

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

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

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

Посмотрите на подавляющее большинство улучшений Pinocchio за последние шесть месяцев: все они появились благодаря оптимизациям на ассемблере. Febo разобрал каждый PR как настоящий Chad и добился слияния нескольких очень хороших решений. Взгляните хотя бы на p-token — концепция та же. 

Вы считаете низкоуровневое программирование не только техническим выбором, но и в некотором смысле идеологическим?

Да, думаю, это и то и другое. Зачем люди хотят поместить JPEG в Bitcoin? Есть что-то первобытное и само по себе интересное в том, чтобы использовать эту крайне ограниченную систему для задачи, на которую она никогда не была рассчитана. Это одновременно забавно и прекрасно. 

Любопытство заканчивается, когда вы перестаете задавать вопросы. 

Если вы любознательны, логической конечной точкой вашего интереса, вероятно, будет примерно такая цепочка: «Я написал на TypeScript код, который использует программу Anchor. Как работает Anchor? Как работают макросы? Как работает Rust? Как работает ассемблер?» 

Возможно, затем вы начинаете глубоко изучать компилятор Rust, потом MIR, LLVM IR и компиляцию в eBPF. Затем спрашиваете, что такое eBPF, и читаете о его ассемблере. В конце концов вы смотрите на сырой байт-код и понимаете, что можете убрать несколько байтов, потому что компилятор не оптимизировал что-то автоматически. Это логическая конечная точка такого поиска. Здесь определенно есть идеологическая составляющая.

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

Если посмотреть на Blueshift, мы фактически создали непрерывный путь от новичка до эксперта. Моя позиция проста: вы получаете разработчиков того уровня, на который их обучаете. Если преподавать только Anchor или TypeScript, вы привлечете лишь тех разработчиков, которые считают этого достаточным. Но если начать говорить об экономии отдельных вычислительных единиц с помощью написанного вручную ассемблерного кода, вы привлечете разработчиков другого уровня — людей, которые действительно понимают смысл этих слов.

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

Такой подход лучше масштабируется. Я могу каждый день часами учить новичков выполнять CPI в Token Program, что требуется в 90% всех программ Solana. А могу обучить этому сотню человек, каждый из которых затем привлечет еще сотню. Именно так достигается масштаб. 

Мы хотим принимать людей на любом уровне и постоянно сдвигать их вправо. Blueshift, Solana Foundation — цель у всех одна.

Образование, передача знаний и сообщество

Раз уж мы говорим о Blueshift: вы стали сооснователем этой инициативы наряду с Turbin3, и у обеих сильная образовательная миссия. Как вы видите их будущее? 

Когда я присоединился к Turbin3, там почти ничего не было. Я пришел, написал все программы учебного курса и начал управлять процессами. Кажется, я провел три или четыре потока и обучил всех, кто теперь преподает. За девять месяцев мы прошли путь от нуля до моей замены благодаря качественному обучению, и для меня там почти не осталось работы. Если качественно обучать людей, возникает масштабируемый маховик.

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

Поэтому правильнее спросить: как дать шанс тем способным людям из числа 800–900 кандидатов, которым отказали буткемпы? 

Ответ Blueshift — создать качественное самостоятельное обучение. Если вы способны следовать материалам, то можете пройти курс в удобном темпе и получить NFT в качестве подтверждения. Все имеет открытый исходный код, и мы активно поощряем PR от сообщества и рассказываем об их авторах в Twitter, чтобы помочь им заявить о себе и начать карьеру. Люди предлагают улучшения, мы принимаем их, и вся платформа становится лучше.

Вместо фразы «К сожалению, вас не приняли, удачи в следующий раз» мы говорим: «Вот учебная программа — пройдите ее самостоятельно в удобное время». Уроки уже переведены на восемь языков, поэтому люди могут проводить встречи или буткемпы в любой точке мира. Их может использовать Superteam. Их может использовать Forma. В конце есть объективный стандарт: все получают одинаковый NFT, вы знаете их уровень и можете соответствующим образом нанимать их или ставить перед ними новые задачи.

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

По сути, вы уже косвенно ответили, но сформулируем вопрос прямо: считаете ли вы обучение разработчиков скорее задачей перевода — сделать сложные идеи доступнее, — задачей буткемпа — быстро довести множество людей до базового уровня, — или чем-то совершенно иным?

Да, главная проблема обучения разработчиков сегодня в том, что бесплатные ресурсы, которые мы публикуем, — дерьмо. Многие из них устарели. Практически все пишут на Anchor или Pinocchio. Никто не использует solana_program. Все очень быстро устаревает. Если весь код открыт, мы можем быстро и тщательно создавать качественные материалы и поддерживать их в актуальном состоянии. Похоже, никто больше не хочет этим заниматься, поэтому этим займемся мы. 

Даже Мерт признал это шесть месяцев назад, когда мы обсуждали вопрос. Он был рад, что кто-то решил уделить внимание этой проблеме. И кто подойдет лучше нас, верно? Мне повезло быть одним из наиболее влиятельных разработчиков в этой сфере. Все имеет открытый исходный код. У нас нет защитного рва, ха-ха. У нас нет огромного гранта Foundation — мы финансируем себя сами. Мы сделали все самостоятельно, и наше единственное преимущество — качество исполнения. 

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

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

Каким вы видите будущее Blueshift?

Будущее Blueshift — это, по сути, два продукта: Coursera и LeetCode. У нас уже есть приемлемые — даже более чем приемлемые, но не идеальные — версии обоих продуктов, однако их нужно улучшить. Мы работаем над V3, поэтому все станет значительно лучше. 

Мы хотим предельно эффективно удовлетворять потребности разработчиков, способных учиться самостоятельно. И, честно говоря, именно таких разработчиков я предпочел бы видеть в экосистеме. 

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

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

Блиц-вопросы

Какую музыку вы слушали в последнее время, пока писали на ассемблере?

Ха-ха, обычно дэт-метал.

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

secp256k1_recover

Что бы вы предпочли писать до конца жизни: C# или Java?

Нет.

Что лучше: модель UTXO или модель на основе аккаунтов?

UTXO стоит дороже.

Если бы у вас были неограниченные ресурсы, какую образовательную инициативу мечты вы запустили бы завтра?

Blueshift плюс IRL. 

Какой один совет вы дали бы тем, кто обучает новых разработчиков низкоуровневым концепциям Solana и не хочет их отпугнуть?

Самоирония.

Заключение

В мире высокоуровневых абстракций, которые выдают за «реальность», чтобы привлечь массы, Дин Литтл остается редким связующим звеном — низкоуровневым алхимиком, создающим инструменты из самых базовых элементов, чтобы поднимать других на свои плечи. Его путь от ракет до массового внедрения гипероптимизированных обновлений оракулов раскрывает этику создателя. Этику, непреклонную в поиске истины: проектировать с учетом отказов, преодолевать ограничения инновациями и никогда ничему слепо не доверять.

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

Пока Solana стремительно движется к следующему рывку — будь то полный паритет с EVM, Alpenglow или 100 000 обновлений оракулов в секунду, — работа Дина бросает всем нам тихий вызов: зачем соглашаться на вежливую ложь, если можно спаять собственную реальность? Если любопытство — это искра, то такие люди, как Дин, служат ускорителем.

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