Глибокі поглиблення: Саме на п'ятиріччя народження Solana партнер Dragonfly Capital @hosseeb сьогодні опублікував твіт, в якому він згадує, як у 2018 році пропустив можливість інвестувати в Solana на початковому етапі за ціною 0,04 долара за одиницю і втратив більше тисячі разів більше прибутку. Також додається пам'ятна записка про інвестиції того часу. Крім того, ми також вибрали фрагменти розмови Толі, співзасновника Solana, та Хоссіба під цим твітом.
Нижче наведено деталі оригіналу:
Я відмовився від можливості інвестувати в раунд заснування @solana за 0,04 долара у початку 2018 року.
За поточною ціною це означає втрату 3250-кратного прибутку.
Solana - один з перших проектів, які я оцінював як молодший VC. Тоді я був миленько наївним та впевненим у собі, і писав меморандуми для кожного проекту, від якого відмовлявся інвестувати.
Зараз перечитувати цей меморандум - це просто "пік відчуттів молодого VC" (вершина молодшого VC cringe). Тоді ми всі були зачаровані пошуками "вбивців Ethereum", вивченням протоколів консенсусу та тим, яка технологія замінить EVM / eWASM.
Отже, це абсолютно не відредагований оригінал меморандуму - найгірша інвестиція у моїй кар'єрі MISS.
З Днем народження, Солана!🎂
Зміст нотаток
Після прочитання білого паперу мої нотатки такі:
Їхній значний інноваційний внесок підтверджує історія (PoH). Фактично, це перевірна функція затримки за часом, яка використовує послідовні хеш-операції, схожі на послідовну робочу вагу доказу. Іншими словами, обирається часовий утримувач, який безперервно ітеративно хешує якусь значення та публікує всі проміжні хеш-значення. Оскільки цей процес має виконуватися послідовно на одному ядрі та не може бути паралельним, вузли повинні бути здатні передбачити часовий інтервал між послідовними хешами (імовірно, на основі їх розуміння продуктивності апаратного забезпечення?).
Вузол PoH також включатиме будь-який поточний стан (наприклад, транзакції, які потрібно підтвердити) в ці хеші. Це дозволить створити надійну історію подій з можливістю достовірно поставити печатку часу.
Якщо вузол PoH має проблеми або не може гарантувати онлайн, вони запропонували схему, за якою декілька вузлів PoH регулярно міняють стан один з одним.
Група валідаторських вузлів перевіряє та повторює операції вузлів PoH (процес перевірки може бути більш ефективним та паралельним завдяки архітектурі MapReduce). Ці валідатори досягають консенсусу за допомогою протоколу, схожого на Casper, використовуючи PoS. У разі виявлення вузлом PoH випадків відмови від Байєсової тактики або неналежної поведінки, валідаторські вузли можуть обрати новий вузол PoH для заміни.
Здається, вони розвиватимуть функції платежів та смарт-контрактів.
Вони заявили, що можуть досягти 71 тис. TPS і досягли 3,5 тис. TPS на тестовій мережі з одним вузлом.
Мої думки:
Їхні цифри цілком дурні. 71 тис. TPS - просто смішно; навіть пошуковий трафік Google не досягає навіть 10 тис. за секунду. Ці дані розміщені на найбільш помітному місці на їхньому веб-сайті, що дуже насторожує мене.
Відкликаю попередню оцінку хорошого написання білого паперу. Високорівневий зміст непоганий, але технічні деталі дуже відсутні та нечіткі. Як опис протоколу консенсусу, він робить людей розчарованими в його строгості.
Команда в основному складається з інженерів нижнього рівня Qualcomm. Генеральний директор та технічний директор в основному займаються операційними системами, вбудованими системами, оптимізацією графічних процесорів та компіляторами. Їхнє фахове обладнання у розподілених системах та криптографії досить слабке, що досить очевидно в їхній науковій роботі. Погано справляються з проблемою візантійської відмовостійкості. Це нагадує мені білу книгу Raiblocks/Nano (вони також інженери нижнього рівня).
І в такий спосіб вміст у білій книзі викликає у мене сумніви:
[Solana Оригінальний білий папір, Розділ 5.12]
"PoH дозволяє мережевим перевіряючим спостерігати минулі події та їх час до певної міри з визначеною впевненістю. Коли генератор PoH створює потік повідомлень, всі перевіряючі повинні надіслати підпис свого стану протягом 500 мс. Це значення може бути подальш знижено в залежності від умов мережі. Оскільки кожна перевірка включається до потоку, кожен у мережі може перевірити, чи всі перевіряючі вчасно надали свої голоси, не спостерігаючи напряму за процесом голосування."
Це не є протоколом консенсусу. Припустимо, що обмеження 500 мс на передачу повідомлень як консенсус, є досить проблематичним, і не має сенсу для досягнення відмовостійкості Байєза. Як вони будуть вимірювати 500 мс? Враховуючи, що вони оцінюватимуть час на основі кількості ітерацій хешування, як вони досягнуть консенсусу щодо пройдених 500 мс у системі інших вузлів? Крім того, як вони збиратимуться вирішити відхилення часу, що виникає з покращення апаратного забезпечення, відмови апаратного забезпечення або шуму? Проблема часу в розподілених системах є дуже складною, і я вважаю, що вони не усвідомлюють, наскільки вона складна.
Знову, хто турбується про час? Це велика проблема у сфері блокчейну? Люди не вдоволені часовою гранулярністю блоку 15 секунд / 1 секунда (наприклад, щось на кшталт DFINITY)? Я думаю, що це не є проблемою, складність і хаос, які вони вводять у протокол, здається, не додають багато цінності.
Вони мають окремий розділ, присвячений обговоренню проблеми невідповідності атак та заохочень. Їх відповідь на атаку абсолютно не переконлива, а також не має жодної уважності або детального пояснення.
У них є цілий розділ, присвячений доказу копіювання, схожий на Filecoin. Що це за фокус? Скажіть мені про ваш протокол консенсусу та те, як ви реалізуєте операції, облікові записи, які особливості матиме ваша блокчейн. Мене не цікавить доказ зберігання даних.
Є ще великий розділ, який починає описувати смарт-контракти, але лише каже, що вони використовуватимуть LLVM як бекенд, щоб підтримувати кілька платформ. Але крім цього вони нічого не зазначають.
Велика кількість вмісту щодо GPU та паралелізації. Це викликає дивне почуття уваги — якщо вони мають реалізувати протокол консенсусу BFT та платформу для розумних контрактів, то вони не повинні захоплюватися паралельною обробкою їх пакунків даних. Я пам'ятаю, що вони робили саме це на демонстраціях, які я бачив — витрачали більшість часу на обговорення оптимізації обробки цих вузлів, майже не виділяючи часу на реальний опис їхнього протоколу консенсусу.
Висновок: я абсолютно не буду інвестувати в цей проект
Цікаво, що через 5 років, коли Хасіб @hosseeb вітає Solana з успішним зайняттям своєї ніші в криптосвіті, підшучуючи самого себе за те, що втратив великий шанс, співзасновник Solana Толі @aeyakovenko відповідає під цим твітом: "Твої початкові страхи були дійсно обґрунтованими. По суті, це було ставкою - ставкою на те, чи зможемо ми зберегти основні переваги над іншими командами і вирішити всі ці питання."
Потім Хасіб відповів Толі: "Я думаю, що ось в чому полягає урок. Ваша наполегливість на оптимізацію на найнижчому рівні та унікальний кут атаки, який не мають інші команди, це саме те, що робиться вирішальним. Тоді я абсолютно не усвідомлював цього".
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Партнер Dragonfly: Я пропустив можливість інвестувати у Solana на початковому етапі?
Автор оригіналу: @hosseeb
Компіляція: TechFlow DeepTide
Глибокі поглиблення: Саме на п'ятиріччя народження Solana партнер Dragonfly Capital @hosseeb сьогодні опублікував твіт, в якому він згадує, як у 2018 році пропустив можливість інвестувати в Solana на початковому етапі за ціною 0,04 долара за одиницю і втратив більше тисячі разів більше прибутку. Також додається пам'ятна записка про інвестиції того часу. Крім того, ми також вибрали фрагменти розмови Толі, співзасновника Solana, та Хоссіба під цим твітом.
Нижче наведено деталі оригіналу:
Я відмовився від можливості інвестувати в раунд заснування @solana за 0,04 долара у початку 2018 року.
За поточною ціною це означає втрату 3250-кратного прибутку.
Solana - один з перших проектів, які я оцінював як молодший VC. Тоді я був миленько наївним та впевненим у собі, і писав меморандуми для кожного проекту, від якого відмовлявся інвестувати.
Зараз перечитувати цей меморандум - це просто "пік відчуттів молодого VC" (вершина молодшого VC cringe). Тоді ми всі були зачаровані пошуками "вбивців Ethereum", вивченням протоколів консенсусу та тим, яка технологія замінить EVM / eWASM.
Отже, це абсолютно не відредагований оригінал меморандуму - найгірша інвестиція у моїй кар'єрі MISS.
З Днем народження, Солана!🎂
Зміст нотаток
Після прочитання білого паперу мої нотатки такі:
Їхній значний інноваційний внесок підтверджує історія (PoH). Фактично, це перевірна функція затримки за часом, яка використовує послідовні хеш-операції, схожі на послідовну робочу вагу доказу. Іншими словами, обирається часовий утримувач, який безперервно ітеративно хешує якусь значення та публікує всі проміжні хеш-значення. Оскільки цей процес має виконуватися послідовно на одному ядрі та не може бути паралельним, вузли повинні бути здатні передбачити часовий інтервал між послідовними хешами (імовірно, на основі їх розуміння продуктивності апаратного забезпечення?).
Вузол PoH також включатиме будь-який поточний стан (наприклад, транзакції, які потрібно підтвердити) в ці хеші. Це дозволить створити надійну історію подій з можливістю достовірно поставити печатку часу.
Якщо вузол PoH має проблеми або не може гарантувати онлайн, вони запропонували схему, за якою декілька вузлів PoH регулярно міняють стан один з одним.
Група валідаторських вузлів перевіряє та повторює операції вузлів PoH (процес перевірки може бути більш ефективним та паралельним завдяки архітектурі MapReduce). Ці валідатори досягають консенсусу за допомогою протоколу, схожого на Casper, використовуючи PoS. У разі виявлення вузлом PoH випадків відмови від Байєсової тактики або неналежної поведінки, валідаторські вузли можуть обрати новий вузол PoH для заміни.
Здається, вони розвиватимуть функції платежів та смарт-контрактів.
Вони заявили, що можуть досягти 71 тис. TPS і досягли 3,5 тис. TPS на тестовій мережі з одним вузлом.
Мої думки:
Їхні цифри цілком дурні. 71 тис. TPS - просто смішно; навіть пошуковий трафік Google не досягає навіть 10 тис. за секунду. Ці дані розміщені на найбільш помітному місці на їхньому веб-сайті, що дуже насторожує мене.
Відкликаю попередню оцінку хорошого написання білого паперу. Високорівневий зміст непоганий, але технічні деталі дуже відсутні та нечіткі. Як опис протоколу консенсусу, він робить людей розчарованими в його строгості.
Команда в основному складається з інженерів нижнього рівня Qualcomm. Генеральний директор та технічний директор в основному займаються операційними системами, вбудованими системами, оптимізацією графічних процесорів та компіляторами. Їхнє фахове обладнання у розподілених системах та криптографії досить слабке, що досить очевидно в їхній науковій роботі. Погано справляються з проблемою візантійської відмовостійкості. Це нагадує мені білу книгу Raiblocks/Nano (вони також інженери нижнього рівня).
І в такий спосіб вміст у білій книзі викликає у мене сумніви:
[Solana Оригінальний білий папір, Розділ 5.12]
"PoH дозволяє мережевим перевіряючим спостерігати минулі події та їх час до певної міри з визначеною впевненістю. Коли генератор PoH створює потік повідомлень, всі перевіряючі повинні надіслати підпис свого стану протягом 500 мс. Це значення може бути подальш знижено в залежності від умов мережі. Оскільки кожна перевірка включається до потоку, кожен у мережі може перевірити, чи всі перевіряючі вчасно надали свої голоси, не спостерігаючи напряму за процесом голосування."
Це не є протоколом консенсусу. Припустимо, що обмеження 500 мс на передачу повідомлень як консенсус, є досить проблематичним, і не має сенсу для досягнення відмовостійкості Байєза. Як вони будуть вимірювати 500 мс? Враховуючи, що вони оцінюватимуть час на основі кількості ітерацій хешування, як вони досягнуть консенсусу щодо пройдених 500 мс у системі інших вузлів? Крім того, як вони збиратимуться вирішити відхилення часу, що виникає з покращення апаратного забезпечення, відмови апаратного забезпечення або шуму? Проблема часу в розподілених системах є дуже складною, і я вважаю, що вони не усвідомлюють, наскільки вона складна.
Знову, хто турбується про час? Це велика проблема у сфері блокчейну? Люди не вдоволені часовою гранулярністю блоку 15 секунд / 1 секунда (наприклад, щось на кшталт DFINITY)? Я думаю, що це не є проблемою, складність і хаос, які вони вводять у протокол, здається, не додають багато цінності.
Вони мають окремий розділ, присвячений обговоренню проблеми невідповідності атак та заохочень. Їх відповідь на атаку абсолютно не переконлива, а також не має жодної уважності або детального пояснення.
У них є цілий розділ, присвячений доказу копіювання, схожий на Filecoin. Що це за фокус? Скажіть мені про ваш протокол консенсусу та те, як ви реалізуєте операції, облікові записи, які особливості матиме ваша блокчейн. Мене не цікавить доказ зберігання даних.
Є ще великий розділ, який починає описувати смарт-контракти, але лише каже, що вони використовуватимуть LLVM як бекенд, щоб підтримувати кілька платформ. Але крім цього вони нічого не зазначають.
Велика кількість вмісту щодо GPU та паралелізації. Це викликає дивне почуття уваги — якщо вони мають реалізувати протокол консенсусу BFT та платформу для розумних контрактів, то вони не повинні захоплюватися паралельною обробкою їх пакунків даних. Я пам'ятаю, що вони робили саме це на демонстраціях, які я бачив — витрачали більшість часу на обговорення оптимізації обробки цих вузлів, майже не виділяючи часу на реальний опис їхнього протоколу консенсусу.
Висновок: я абсолютно не буду інвестувати в цей проект
Цікаво, що через 5 років, коли Хасіб @hosseeb вітає Solana з успішним зайняттям своєї ніші в криптосвіті, підшучуючи самого себе за те, що втратив великий шанс, співзасновник Solana Толі @aeyakovenko відповідає під цим твітом: "Твої початкові страхи були дійсно обґрунтованими. По суті, це було ставкою - ставкою на те, чи зможемо ми зберегти основні переваги над іншими командами і вирішити всі ці питання."
Потім Хасіб відповів Толі: "Я думаю, що ось в чому полягає урок. Ваша наполегливість на оптимізацію на найнижчому рівні та унікальний кут атаки, який не мають інші команди, це саме те, що робиться вирішальним. Тоді я абсолютно не усвідомлював цього".