Cypherpunk Whisper

The lesson isn't that software is dying, it's that thin software was never a business. If your product can be reverse engineered in a weekend, the code was never the asset. The companies that survive this own something that can't be cloned: the data, the distribution, or the relationship. Everything else was renting time until the clone showed up.

Joe Lonsdale says the best thing Peter Thiel taught him was how to win with focus: 1. “Effort on any project is convex.” 2. “If you spend 80% of your time focused on something - that’s half as good as spending 90% of your time.” 3. “Being 99th percentile is worth so much more than being 90th percentile. Because it means you’re number one.” 4. “And being number one is worth a lot.” 5. “Anything I invest in - someone really amazing is making it their main thing. The CEO has to be all in.” Peter Thiel’s biggest advice for Founders: Focus. 1. “Focus your business as precisely as you can.” 2. “Don’t try to do half a dozen things sort of well.” 3. “Do one thing better than anyone else in the world.”

Повсюду мудрец видит одно и то же... Бхагавад-гита

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

https://www.youtube.com/watch?v=isr4-tsfhsg

Концепции морали и добра универсальны, как теорема Пифагора. Цивилизации не выживают, если не следуют этим концепциям. Н.С.Кардашёв https://youtu.be/IOfxvsdBpDQ?si=iFqamjMLDTS3iNEx

🧊 Айсберг питча: почему 9 из 10 фаундеров уходят с пустыми руками Неприятная статистика: менее 1% стартапов получают венчурное финансирование. И проблема не в рынке, не в конкуренции и не в «плохом времени для привлечения». Проблема - в вас. Точнее - в том, на что вы тратите время перед встречей с инвестором. Вижу это регулярно. Фаундер приходит ко мне на консультацию: «Давид, у нас всё готово, помогите доупаковать». Открываю материалы - дизайн на уровне Apple keynote. Pitch deck на 25 слайдов. TAM/SAM/SOM с красивыми кружочками. Спрашиваю «Какой у вас CAC по каналам?» - тишина. «Churn rate за последние 6 месяцев?» - «ну, мы пока не считали детально». «Почему конкурент Х не сделает то же самое за квартал?» - «у нас уникальная команда». Всё. Разговор окончен. Инвестор задаст те же вопросы, только у вас не будет второго шанса. Вот в чём ловушка. Фаундеры путают упаковку с продуктом. Тратят 80% подготовки на верхушку айсберга, отполированный дизайн слайдов, заученный питч с паузами «для эффекта», модные формулировки «дизрапт», «AI-driven», «экосистемный подход», проекции в стиле «х50 за три года в базовом сценарии» А то, что реально определяет решение инвестора, остается сырым: 📌 Глубина понимания рынка. Не «рынок EdTech в России растёт», а: «Сегмент корпоративного онлайн-обучения для компаний с штатом 500+ человек - 62 млрд руб., CAGR 19%, текущее проникновение 12%, основной драйвер - дефицит кадров, который вынуждает бизнес переходить от найма к внутреннему апскиллингу. Вот три болевые точки текущих решений - и вот как мы их закрываем». Чувствуете разницу? 📌 Product-market fit с доказательствами. Не «клиентам нравится». А: retention 78% на третий месяц, NPS 62, средний LTV вырос на 40% после запуска второго продукта. Цифры - единственный язык, который инвестор понимает без переводчика. 📌 Реалистичная финмодель. Когда я вижу EBITDA margin 45% на третий год у компании без единого прибыльного месяца - я закрываю презентацию. Инвестор делает то же самое. Только молча. 📌 Конкурентный барьер. «Уникальная технология» - это не барьер. Патент, эксклюзивные контракты, сетевой эффект, регуляторное преимущество — это барьер. Если вашу модель можно скопировать за полгода - это не конкурентное преимущество, это фора. 📌 Юнит-экономика, которая масштабируется. Если CAC растёт быстрее LTV при увеличении объёмов - у вас не бизнес, а благотворительность за счёт инвесторов. И опытный фондовый менеджер это увидит на второй минуте. 📌 Команда, в которую можно поверить. Не «мы все из топовых компаний». А: кто уже проходил через масштабирование, кто закрывает ключевые компетенции, какой план, если CTO уйдёт завтра. Из практики. Два проекта. Одинаковый рынок. Первый- идеальная презентация, фаундер с MBA, харизма уровня TED Talk. Второй - слайды в Google Docs, фаундер говорит сухо, местами сбивается. Первый не закрыл раунд за 8 месяцев. Второй получил term sheet на третьей встрече. Разница? Второй знал каждую цифру в своём бизнесе. На любой вопрос отвечал без заминки. Не потому что репетировал, а потому что жил этими цифрами каждый день. Инвестор покупает не шоу. Он покупает уверенность в том, что вы понимаете свой бизнес глубже, чем кто-либо. Перестаньте полировать верхушку. Стройте айсберг снизу вверх: 1. Разберите юнит-экономику до винтика 2. Соберите доказательства product-market fit 3. Постройте финмодель, в которую вы сами верите 4. Сформулируйте конкурентный барьер одним предложением 5. И только потом — открывайте Figma Successful pitches are built on a foundation of substance, not just style. Или, если по-русски: инвестору плевать на ваши слайды, если за ними ничего нет.

Построить опен-сорсный аналог Palantir за выходные? И не на такое способны самородки из твиттера! https://x.com/unicodeveloper/status/2015802752396394721

TinyRAM <> MicroRAM <> zkVM В [первой] и [второй] части цикла мы разобрались, что пытаться компилировать реальное ПО напрямую в ZK-схемы бессмысленно из-за экспоненциального роста constraints, и вместо этого более корректно доказывать knowledge of execution, а именно кодировать внутри w(witness) специфический trace выполнения программы, который ведет к доказываемому output. Часть 3. Практический опыт реализации knowledge of execution TinyRAM - это один из первых и наиболее чистых примеров реализации рассматриваемого подхода: виртуальная машина, чьё исполнение можно доказать в zero-knowledge. TinyRAM оптимизирован под ZK и схож с zkVM: с простым набором инструкций и семантикой, которую удобно проверять в схемах. Формально, zkVM утверждает: ∃ execution trace: state₀ → state₁ → … → state_T such that ∀t: state_{t+1} = Step_VM(state_t) TinyRAM является одним из первых примеров VM, для которой такое утверждение можно эффективно закодировать в ZK. Чтобы компилировать программу под эту VM и затем доказывать её исполнение в ZK, внутри TinyRAM задаётся наивная архитектура процессора: регистры, память, счётчик команд и набор инструкций; и формализует её пошаговую семантику. ZKP затем утверждает существование такой последовательности состояний этой машины (execution trace), которая начинается с корректного начального состояния и переходит шаг за шагом согласно семантике TinyRAM. Однако, TinyRAM недостаточно "дешевый" для продакшена. Как можно было понять, проверка исполнения проходит на уровне отдельных инструкций процессора. Каждый шаг трассы = проверка одной инструкции. Но стоимость TinyRAM определяется не только длиной execution trace, но и структурой самой проверки одного шага. В типичном кодировании Step_VM получается слишком универсальным, потому что на каждом шаге ZK-схема должна уметь корректно обработать любую инструкцию, и это добавляет много условной логики даже на простых шагах. Получается, что TinyRAM платит за универсальность дважды - через линейную зависимость стоимости доказательства от длины трассы и через высокую сложность самой функции перехода состояний. Эта архитектура концептуально корректна, но плохо масштабируется на реальные программы. Закономерным следующим шагом здесь было бы начать оптимизировать логику, например, через упрощение схем перехода состояний. Однако, в контексте ZK любая агрессивная оптимизация, завязанная на структуру исполняемой программы начинает раскрывать информацию о control flow, а значит и потенциально компрометировать метаданные об инпутах. Далеко не для всех сценариев это допустимо. Здесь на сцену выходит MicroRAM - эволюция TinyRAM, в которой ISA и семантика виртуальной машины спроектированы так, чтобы удешевить проверку одного шага исполнения в ZK. MicroRAM не сокращает execution trace и не ускоряет выполнение программы, вместо этого он делает функцию Step_VM проще и дешевле для кодирования в constraints. В этом смысле TinyRAM и MicroRAM можно рассматривать как ранние шаги к современным zkVM, ведь во всех трёх подходах избегается вычисление функции в лоб. В следующей (финальной) части мы изучим, почему MicroRAM открывает большое количество новых use-кейсов, и как именно он снижает количество constraints. Если вы дочитали до конца и имеете какие-то вопросы по любой части поста, то обязательно задайте их в комментариях. Это поможет сделать следующую часть более информативной! Продолжение следует... #zkp #progcrypto #tinyram #zkvm

Будь Палмером Лаки: > родился в 1992-м, Лонг-Бич, Калифорния > на домашнем обучении у мамы; папа — продавец машин > в подростковом возрасте собираешь в гараже рельсотроны, катушки Теслы и лазеры > бьёшь себя током, выжигаешь себе «серое пятно» в поле зрения, пока чистишь лазер > не жалеешь ни о чём > начинаешь брать университетские курсы в 14 > собираешь игровой сетап на шесть мониторов за десятки тысяч долларов > к 18 годам собрал 43 VR-шлема > крупнейшая частная коллекция в мире 2009: > в 17 лет создаешь форум ModRetro > ради фана переделываешь старые консоли в портативки > подрабатываешь в USC Mixed Reality Lab, делая VR для ветеранов с ПТСР 2012: > в 19 лет собираешь прототип Oculus Rift в гараже у родителей > бросаешь колледж > Джон Кармак (создатель Doom) показывает твой шлем на E3 > Гейб Ньюэлл его одобряет > запускаешь Kickstarter с целью $250K > собираешь $2,4 млн 2014: > приходит Марк Цукерберг > Facebook покупает Oculus за $2 млрд > тебе 21 > Forbes оценивает твое состояние в $700 млн > тебя называют «лицом виртуальной реальности» 2016: > жертвуешь $10K группе в поддержку Трампа > постишь анти-Хиллари мемы на Reddit под псевдонимом > тебя вскрывают > разработчики игр бойкотируют Oculus > Facebook давит, чтобы ты публично поддержал вместо этого Гэри Джонсона > отказываешься 2017: > тебя увольняют из собственной компании > Цукерберг не говорит почему > выбиваешь выплату $100 млн+ за незаконное увольнение > сразу же основываешь Anduril Industries > называешь в честь меча Арагорна из «Властелина колец» > партнёришься с Питером Тилем > начинаешь делать автономное оружие и оборонные ИИ-системы 2020–2024: > выигрываешь контракт на $1 млрд с Командованием спецопераций США > дроны разворачивают в Украине > выручка вырастает вдвое до $1 млрд > забираешь у Microsoft военный контракт на шлемы за $22 млрд > Пентагон не может перестать выписывать тебе чеки 2022: > делаешь VR-шлем, который буквально убивает тебя, если ты умираешь в игре > вдохновляешься Sword Art Online > три взрывных заряда, направленных в лоб > называешь это «офисным артом» > «и это не последний» 2025: > Anduril оценивают в $30,5 млрд > анонсируешь планы построить Arsenal-1 > оружейный завод на 5 млн квадратных футов в Огайо > автономные истребители, ракеты, торпеды > Китай персонально вводит против тебя санкции > состояние — $3,5 млрд > платишь себе зарплату $100K > всё так же ходишь на встречи в Пентагоне в гавайках и шлёпанцах > у тебя есть подлодка, вертолёты и PT boat > держишь одну из крупнейших в мире коллекций видеоигр под землёй > женат на женщине, которая шьёт исторически точные тюдоровские костюмы > берёшь первое место на Texas Renaissance Festival в образе Генриха VIII > автор Sword Art Online нарисовал тебе свадебный подарок Source: https://x.com/jaynitx/status/2011712639790170236 #startups

TinyRAM <> MicroRAM <> zkVM В [первой] части мы разобрались, что пытаться компилировать реальное ПО напрямую в ZK-схемы бессмысленно из-за экспоненциального роста constraints. Часть 2. Кодирование knowledge of execution В ранних практических применениях ZK-SNARKs часто использовались для доказательства утверждений вида: «Я знаю x такое, что f(x)=y», где f была фиксированной, относительно небольшой функцией (например, хэш-функцией). Попытки применить тот же метод, прямую компиляцию, к произвольным программам с неизвестным Control Flow наталкивались на непреодолимые сложности. Но что если сделать утверждаемым фактом не значение вычисления, а существование корректной трассы исполнения абстрактной машины, реализующей данную программу? При таком подходе доказываемое утверждение в новом виде выглядело бы примерно так: ∃ input, trace: trace = Exec(P, input) ⋀ Property(trace) "Я знаю trace выполнения программы, который при некоторых входных данных приводит к определённому результату, и могу доказать это в ZK." Но как реализовать такой подход на уровне эвристики? Вместо того чтобы проверять все возможные трассы исполнения программы, мы можем закодировать в w(witness)один конкретный путь, который содержит в себе точные ветвления, точное число итераций циклов, точные адреса памяти и значения регистров. ZK Circuit не должен моделировать всю программу целиком, он лишь проверяет, что каждый шаг этой конкретной трассы корректен согласно формальной семантике процессора. Именно это в академической литературе иногда называют “knowledge of execution”: доказательство знания корректной трассы выполнения. Стоимость доказательства растёт линейно с длиной выполненной трассы, а не с количеством возможных ветвлений программы. В теории, это делает возможным доказывать утверждения о реальном ПО. Программа с миллионами строк и сложным управлением сводится не к гигантской формуле всех её возможных поведений, а к проверке одной конкретной истории того, как она была выполнена. В теории, такой подход звучит эффективно. Но те, кто взялись его реализовывать в виде конкретных криптографических протоколов, наткнулись на ряд непростых вызовов. TinyRAM - один из таких протоколов. На его примере мы в следующей части разберем аспекты реализации подхода и практическую пользу самого решения (если я, конечно, увижу фидбэк🌚). Продолжение следует... #zkp #progcrypto #tinyram #zkvm

"A Pragmatic Introduction to Secure Multi-Party Computation" Authors: David Evans, Vladimir Kolesnikov and Mike Rosulek Distribution policy: available free via the book website Link: https://securecomputation.org/ #mpc #books

TinyRAM <> MicroRAM <> zkVM Есть вот такой простой абзац в одном интересном Research Paper: TinyRAM is sufficiently flexible to validate the executions of applications, but it is expensive, in part due to the fact that it simulates every instruction in the modeled CPU’s ISA in each step. TinyRAM’s performance is surpassed by those of Pantry and Buffet, but both frameworks require loops to be unrolled to a public bound: publicly revealing these bounds leaks information about the underlying vulnerability. Но при прочтении поймал себя на мысли, что не смогу сам себе даже внятно объяснить отличие MicroRAM от TinyRAM, поэтому решил сделать пост по этой теме. Если увижу какой-то фидбэк, напишу ещё несколько частей. Там больше интересностей. Часть 1. Проблема компиляции Прямое компилирование программ в ZK-схемы не работает для реального ПО. Чтобы это понять, разберем классический подход, в котором каждая операция программы, каждая ветка, каждый if и каждый доступ к памяти становится частью одной большой схемы: Rust/C → SSA/IR → Arithmetic Circuit → ZK Circuit Такой подход хорошо работает для маленьких алгоритмов, фиксированной структуры, криптографии и ML, но не для OpenSSL, FFmpeg, сетевых даемонов, Rust-сервисов и всего, что имеет pointers + heap + loops + syscalls. В реальных программах Control Flow выглядит не как линейная формула, а сложный, ветвящийся процесс. Условные переходы, циклы, вызовы функций, исключения, возвраты... Одна и та же программа может при разных входных данных пройти по радикально разным путям исполнения. Когда мы пытаемся скомпилировать такую программу напрямую в ZK-схему, мы вынуждены заранее зафиксировать все возможные варианты её поведения: сколько раз выполнится каждый цикл, какие ветки if будут выбраны, какие функции будут вызваны. ZK-схема не умеет «исполняться», она должна уже содержать всю структуру вычисления. Поэтому компилятор обязан включить в неё логику всех потенциальных путей, а затем внутри схемы маскировать те, которые в конкретном запуске не используются. Это приводит к тому, что даже простые программы с несколькими вложенными циклами и условиями порождают экспоненциальное количество возможных путей, что невозможно масштабировать эффективно. Схема должна содержать ограничения для всех этих путей одновременно, потому что заранее неизвестно, какой из них будет активирован через w(witness). В результате размер схемы растёт не с длиной фактического выполнения, а с размером пространства всех возможных выполнений, и это делает прямую компиляцию практически непригодной для реального кода. Но есть решение. Продолжение следует... #zkp #progcrypto #tinyram #zkvm

Serendipity is manufactured. There are clear inputs. Proximity to other founders, investors, and customers being the main one. And not giving up to increase the surface area where luck can find you. Jason Freedman

Никогда не доверяйте тем, кто за всю жизнь не попробовал ничего построить. Алекс Карп

Парень, который ревьюил 8000 заявок в YCombinator, написал пост о качестве, наличие которого является лучшим предиктором успеха стартапа, и наличие которого в заявке YC выявляется 5-ю разными способами. Лучшее, что вы сегодня прочитаете в твиттере о стартапах. Обязательно гляньте и тред. https://x.com/jasonfreedman/status/1995616534140739788?s=20