Партнер Dragonfly: як я пропустив можливість інвестувати в Solana на сіменищному раунді?

robot
Генерація анотацій у процесі

Втрата одного з найбільш дорогих інвестиційних меморандумів в історії криптовалют, що призвела до втрати 3250 разів більше прибутку.

Написано: @hosseeb

Компіляція: Deep Tide TechFlow

Глибокий приплив: у самий час Солана святкує п'ятиріччя, партнер Dragonfly Capital @hosseeb сьогодні оприлюднив твіт, у якому згадує, як у 2018 році втратив можливість інвестувати в Solana на початковому етапі за ціною 0,04 долара за одиницю і пропустив можливість заробити більше тисячі разів від вкладу. Також додаємо початкову інвестиційну документацію для пам'яті. Крім того, ми взяли уривок з обговорення між співзасновниками Солани Толі та Хоссібом під цим твітом.

Нижче наведено деталі оригіналу:

Я відмовився від можливості взяти участь в інвестиціях за насінням @solana на початку 2018 року за 0,04 долара.

За поточною ціною це означає втрату вже 3250 разів.

Solana була одним з перших проектів, які я оцінював як початківець VC. Тоді я був дуже милим, наївним і впевненим, і писав меморандум для кожного проекту, від якого відмовлявся інвестувати.

Зараз перечитувати цей меморандум - це просто "пік жалю для молодшого VC" (пік жалю для молодшого VC). Тоді ми всі були зачаровані пошуками "вбивців Ethereum", дослідженням протоколів консенсусу та тим, яка технологія замінить EVM / eWASM.

Отже, це абсолютно не відредагований оригінал меморандуму - найгірша інвестиція у моїй кар'єрі MISS.

З Днем народження, Solana!🎂

Зміст нотаток

Після прочитання білого паперу мої нотатки наступні:

Їхнім великим інноваціям є історичне підтвердження (PoH). У суті, це перевірка затримки часу, що може бути підтверджена, використовуючи послідовні хеш-операції, схожі на послідовну роботу. Іншими словами, виберіть хронологію, яка безперервно ітерує хеш-операції для певного значення і оприлюднює всі проміжні хеш-значення. Оскільки цей процес повинен виконуватися послідовно на одному ядрі і не може бути паралельним, вузли повинні бути здатні передбачити час, який пройде між послідовними хешами (можливо, на основі їх розуміння апаратного забезпечення?).

Вузол PoH також змішує будь-який поточний стан (наприклад, угоди, які потрібно підтвердити) в ці хеші. Це дозволяє створити надійну історію подій з можливістю накладання часового печатки.

Якщо вузол PoH має проблеми або не може гарантувати онлайн, вони запропонували план, за яким декілька вузлів PoH регулярно змішують стани один з одним.

Група валідаторів відтворює та перевіряє дії вузла PoH (процес перевірки може бути здійснений більш ефективно через архітектуру MapReduce для забезпечення паралельності). Ці валідатори досягають згоди за допомогою протоколу, схожого на Casper, використовуючи PoS. Якщо виявлено проблему вузла PoH або некоректну поведінку, валідатори можуть обрати новий вузол PoH для заміни.

Здається, вони будуть розробляти функції платежів та смарт-контрактів.

Вони стверджують, що можуть досягти 71 тис. транзакцій за секунду і досягли 3,5 тис. транзакцій за секунду на тестовій мережі одного вузла.

Мої думки:

Їхні цифри це абсолютна дурниця. 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 відповів на цей твіт: "Всі ваші початкові страхи були цілком обґрунтовані. По суті, це було ставкою - ставкою на те, чи зможемо ми, тримаючи наші основні переваги перед іншими командами, вирішити всі ці проблеми."

Потім Хасіб відповів Толі: "Я думаю, що це один із уроків. Ваша наполегливість на оптимізацію на нижньому рівні та унікальний кут нападу, які не є характерними для інших команд. Це вміння максимально розвивати свої сильні сторони і уникати слабких - саме це найважливіше. Тоді я абсолютно не розумів цього".

!

Переглянути оригінал
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
  • Нагородити
  • Прокоментувати
  • Поділіться
Прокоментувати
0/400
Немає коментарів
  • Закріпити