Глибокий潮 примітка: У зв'язку з п'ятою річницею народження Solana, партнер Dragonfly Capital Хосеб сьогодні опублікував твіт, в якому згадує, як у 2018 році він пропустив можливість інвестувати в початковий раунд Solana за ціною 0,04 долара за одиницю і втратив прибуток у тисячі разів. Він також додав початкову інвестиційну записку на пам'ять. Додатково, ми також виділили обговорення між співзасновником Solana Толі та Хосебом під цим твіттом.
Наступна інформація є оригінальним текстом:
Я на початку 2018 року відмовився від можливості взяти участь у Seed Round інвестицій Solana за 0,04 долара.
За нинішньою ціною це еквівалентно вже втраченим 3250-кратним прибуткам.
Solana був одним із перших проектів, які я оцінив, коли був молодшим венчурним капіталістом. Тоді я був ще дуже милим, наївним і впевненим у собі, писав би меморандуми для кожного проекту, в якому відмовився інвестувати.
Тепер повторне читання цього меморандуму просто є "незручним моментом для початкових венчурних капіталістів" (peak junior VC cringe). Тоді ми всі були захоплені пошуками "вбивці ефіру", дослідженням консенсусних протоколів та тим, яка технологія може замінити EVM / eWASM.
Отже, це повний незмінений текст меморандуму — — найгірша інвестиція в моїй кар'єрі MISS.
З днем народження, Solana!
Зміст нотатки
Після прочитання білого паперу, мої конспекти такі:
Їхнє значне нововведення - це історичне підтвердження (PoH). По суті, це перевірна функція затримки часу, яка використовує безперервні хеш-обчислення, подібно до послідовного доказу роботи. Іншими словами, обирається зберігач часу, який постійно ітеративно виконує хешування певного значення та публікує всі проміжні хеш-значення. Оскільки цей процес має виконуватися послідовно на одному ядрі, що унеможливлює паралелізацію, вузли повинні мати можливість прогнозувати кількість часу, що минув між послідовними хешами (напевно, на основі їх знань про продуктивність апаратного забезпечення?).
Вузли PoH також змішуватимуть будь-який поточний стан (наприклад, транзакції, які потрібно подати) з цими хешами. Таким чином можна створити надійний історичний запис подій з відміткою часу.
Якщо вузли PoH мають проблеми або не можуть гарантувати онлайн-статус, вони запропонували рішення, яке передбачає регулярне змішування станів декількох вузлів PoH.
Група вузлів-верифікаторів повторно виконує та верифікує операції вузла PoH (процес верифікації може бути більш ефективно паралелізований за допомогою архітектури MapReduce). Ці верифікатори досягають консенсусу за допомогою PoS, застосовуючи протокол, подібний до Casper. Якщо буде виявлено, що вузол PoH має проблеми з візантійською поведінкою або діє неналежним чином, вузли-верифікатори можуть обрати новий вузол PoH на заміну.
Схоже, що вони розроблять функції платежів та смарт-контрактів.
Вони стверджують, що можуть досягти 710 тисяч TPS і досягли 35 тисяч TPS на тестовій мережі з одним вузлом.
Моя думка:
Їхні цифри абсолютно нісенітниця. 710 тисяч TPS просто смішно; навіть кількість пошукових запитів Google не перевищує 100 тисяч на секунду. Ці дані розміщені на їхньому сайті на найбільш помітному місці, що викликає у мене велику обережність.
Скасуйте попередню позитивну оцінку білого паперу. Зміст на високому рівні непоганий, але технічних деталей дуже не вистачає і вони розмиті. Як опис консенсусного протоколу, строгість викликає розчарування.
Команда в основному складається з інженерів базового рівня Qualcomm. Генеральний директор та технічний директор в основному займаються операційними системами, вбудованими системами, оптимізацією GPU та компіляторами. Їхній досвід у розподілених системах та криптографії явно недостатній, що чітко проявляється в статті. Обробка проблеми візантійської стійкості виконана погано. Це нагадує мені білль по Raiblocks/Nano (вони також є інженерами базового рівня).
І така інформація в білому документі викликає в мене сумніви:
[Оригінал білого паперу Solana, Розділ 5.12]
"PoH дозволяє мережевим валідаторам з певною мірою визначеності спостерігати за подіями, які сталися в минулому, та їхнім часом. Коли генератор PoH створює потік повідомлень, усім валідаторам потрібно подати свої підписи на стан протягом 500 мс. Це значення може бути додатково зменшено залежно від умов мережі. Оскільки кожна перевірка вводиться в потік, кожен у мережі може перевірити, чи всі валідатори подали свої голоси у встановлений час, не спостерігаючи безпосередньо за процесом голосування."
Це не є протоколом консенсусу. Припустимо, що обмеження 500 мс для консенсусу в передачі повідомлень є досить проблематичним і не реалізує значущу байєсівську стійкість. Більше того, як вони вимірюють 500 мс? Враховуючи, що вони будуть оцінювати час на основі кількості ітерацій хешування, виконаних у системі, як інші вузли в системі досягнуть консенсусу щодо 500 мс? Крім того, як вони планують вирішити відхилення, що виникають через поліпшення апаратного забезпечення, поломки обладнання або шуму, які призводять до зміни швидкості годинника з плином часу? Проблеми часу в розподілених системах є дуже складними, і я вважаю, що вони не усвідомлюють, наскільки це важко.
До того ж, кому цікаво, скільки часу? Це велика проблема в сфері блокчейну? Люди не задоволені частотою блоків у 15 секунд/1 секунду (наприклад, такі речі, як DFINITY)? Я вважаю, що це не є великою проблемою, і складність та плутанина, яку вони вводять у протокол, здається, не приносять багато цінності.
Вони мають частину, присвячену обговоренню проблеми атак і невідповідності стимулів. Їхня відповідь на атаки абсолютно не переконлива, а також їй бракує строгості чи детальних пояснень.
Вони мають цілий розділ, присвячений доказу копіювання, як-от у Filecoin. Що відбувається? Скажіть мені про ваш консенсусний протокол і як реалізуються транзакції, облікові записи, які характеристики матиме ваша блокчейн. Мене не цікавить доказ зберігання даних.
Є ще великий розділ, який починає описувати смарт-контракти, але просто говориться, що вони використовуватимуть LLVM як бекенд для підтримки кількох платформ. Але більше нічого не згадується.
Велика кількість вмісту про GPU та паралелізацію. Це викриває дивну зосередженість — якщо їм потрібно реалізувати BFT протокол консенсусу та доступну платформу смарт-контрактів, не слід занурюватись у паралельну обробку їх форматів пакетів. Я пам'ятаю, що в демонстрації, яку я бачив, було так само — витратили більшу частину часу на обговорення того, як оптимізувати обробку з цих вузлів, і майже не витратили часу на фактичний опис їх протоколу консенсусу.
Висновок: я абсолютно не буду вкладати в цей проєкт.
Цікаво, що через 5 років, коли Хасіб написав у Твіттері, щоб привітати Солану з тим, що вона зайняла своє місце в криптовалюті, і жартував про те, як у той час він упустив великий шанс, співзасновник Солани Толі відповів під цим твітом: "Усі твої занепокоєння на той час дійсно були обґрунтованими. По суті, це ставка — ставка на те, чи зможемо ми вирішити всі ці проблеми, зберігаючи при цьому базові переваги, яких немає в інших командах."
А потім Хасіб відповів Толі: "Я думаю, що це і є один з уроків. Ваша прихильність до оптимізації на базовому рівні та унікальних атакуючих підходів є тим, чого немає в інших командах. Саме це максимальне використання своїх сильних сторін та уникнення слабких є найважливішим. Тоді я зовсім не усвідомлював цього."
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
2 лайків
Нагородити
2
1
Поділіться
Прокоментувати
0/400
LifeChangerCrypto
· 03-24 23:49
ми чекаємо на великий бичачий ринок у крипторинкуBull Run 🐂
Dragonfly партнер: Як я пропустив 0.04 долара США в раунді посіву SOL? Найгірше рішення в моєму житті
Автор | Hosseeb
Компіляція | Глибокий приплив TechFlow
Глибокий潮 примітка: У зв'язку з п'ятою річницею народження Solana, партнер Dragonfly Capital Хосеб сьогодні опублікував твіт, в якому згадує, як у 2018 році він пропустив можливість інвестувати в початковий раунд Solana за ціною 0,04 долара за одиницю і втратив прибуток у тисячі разів. Він також додав початкову інвестиційну записку на пам'ять. Додатково, ми також виділили обговорення між співзасновником Solana Толі та Хосебом під цим твіттом.
Наступна інформація є оригінальним текстом:
Я на початку 2018 року відмовився від можливості взяти участь у Seed Round інвестицій Solana за 0,04 долара.
За нинішньою ціною це еквівалентно вже втраченим 3250-кратним прибуткам.
Solana був одним із перших проектів, які я оцінив, коли був молодшим венчурним капіталістом. Тоді я був ще дуже милим, наївним і впевненим у собі, писав би меморандуми для кожного проекту, в якому відмовився інвестувати.
Тепер повторне читання цього меморандуму просто є "незручним моментом для початкових венчурних капіталістів" (peak junior VC cringe). Тоді ми всі були захоплені пошуками "вбивці ефіру", дослідженням консенсусних протоколів та тим, яка технологія може замінити EVM / eWASM.
Отже, це повний незмінений текст меморандуму — — найгірша інвестиція в моїй кар'єрі MISS.
З днем народження, Solana!
Зміст нотатки
Їхнє значне нововведення - це історичне підтвердження (PoH). По суті, це перевірна функція затримки часу, яка використовує безперервні хеш-обчислення, подібно до послідовного доказу роботи. Іншими словами, обирається зберігач часу, який постійно ітеративно виконує хешування певного значення та публікує всі проміжні хеш-значення. Оскільки цей процес має виконуватися послідовно на одному ядрі, що унеможливлює паралелізацію, вузли повинні мати можливість прогнозувати кількість часу, що минув між послідовними хешами (напевно, на основі їх знань про продуктивність апаратного забезпечення?).
Вузли PoH також змішуватимуть будь-який поточний стан (наприклад, транзакції, які потрібно подати) з цими хешами. Таким чином можна створити надійний історичний запис подій з відміткою часу.
Якщо вузли PoH мають проблеми або не можуть гарантувати онлайн-статус, вони запропонували рішення, яке передбачає регулярне змішування станів декількох вузлів PoH.
Група вузлів-верифікаторів повторно виконує та верифікує операції вузла PoH (процес верифікації може бути більш ефективно паралелізований за допомогою архітектури MapReduce). Ці верифікатори досягають консенсусу за допомогою PoS, застосовуючи протокол, подібний до Casper. Якщо буде виявлено, що вузол PoH має проблеми з візантійською поведінкою або діє неналежним чином, вузли-верифікатори можуть обрати новий вузол PoH на заміну.
Схоже, що вони розроблять функції платежів та смарт-контрактів.
Вони стверджують, що можуть досягти 710 тисяч TPS і досягли 35 тисяч TPS на тестовій мережі з одним вузлом.
Їхні цифри абсолютно нісенітниця. 710 тисяч TPS просто смішно; навіть кількість пошукових запитів Google не перевищує 100 тисяч на секунду. Ці дані розміщені на їхньому сайті на найбільш помітному місці, що викликає у мене велику обережність.
Скасуйте попередню позитивну оцінку білого паперу. Зміст на високому рівні непоганий, але технічних деталей дуже не вистачає і вони розмиті. Як опис консенсусного протоколу, строгість викликає розчарування.
Команда в основному складається з інженерів базового рівня Qualcomm. Генеральний директор та технічний директор в основному займаються операційними системами, вбудованими системами, оптимізацією GPU та компіляторами. Їхній досвід у розподілених системах та криптографії явно недостатній, що чітко проявляється в статті. Обробка проблеми візантійської стійкості виконана погано. Це нагадує мені білль по Raiblocks/Nano (вони також є інженерами базового рівня).
І така інформація в білому документі викликає в мене сумніви:
[Оригінал білого паперу Solana, Розділ 5.12]
"PoH дозволяє мережевим валідаторам з певною мірою визначеності спостерігати за подіями, які сталися в минулому, та їхнім часом. Коли генератор PoH створює потік повідомлень, усім валідаторам потрібно подати свої підписи на стан протягом 500 мс. Це значення може бути додатково зменшено залежно від умов мережі. Оскільки кожна перевірка вводиться в потік, кожен у мережі може перевірити, чи всі валідатори подали свої голоси у встановлений час, не спостерігаючи безпосередньо за процесом голосування."
Це не є протоколом консенсусу. Припустимо, що обмеження 500 мс для консенсусу в передачі повідомлень є досить проблематичним і не реалізує значущу байєсівську стійкість. Більше того, як вони вимірюють 500 мс? Враховуючи, що вони будуть оцінювати час на основі кількості ітерацій хешування, виконаних у системі, як інші вузли в системі досягнуть консенсусу щодо 500 мс? Крім того, як вони планують вирішити відхилення, що виникають через поліпшення апаратного забезпечення, поломки обладнання або шуму, які призводять до зміни швидкості годинника з плином часу? Проблеми часу в розподілених системах є дуже складними, і я вважаю, що вони не усвідомлюють, наскільки це важко.
До того ж, кому цікаво, скільки часу? Це велика проблема в сфері блокчейну? Люди не задоволені частотою блоків у 15 секунд/1 секунду (наприклад, такі речі, як DFINITY)? Я вважаю, що це не є великою проблемою, і складність та плутанина, яку вони вводять у протокол, здається, не приносять багато цінності.
Вони мають частину, присвячену обговоренню проблеми атак і невідповідності стимулів. Їхня відповідь на атаки абсолютно не переконлива, а також їй бракує строгості чи детальних пояснень.
Вони мають цілий розділ, присвячений доказу копіювання, як-от у Filecoin. Що відбувається? Скажіть мені про ваш консенсусний протокол і як реалізуються транзакції, облікові записи, які характеристики матиме ваша блокчейн. Мене не цікавить доказ зберігання даних.
Є ще великий розділ, який починає описувати смарт-контракти, але просто говориться, що вони використовуватимуть LLVM як бекенд для підтримки кількох платформ. Але більше нічого не згадується.
Велика кількість вмісту про GPU та паралелізацію. Це викриває дивну зосередженість — якщо їм потрібно реалізувати BFT протокол консенсусу та доступну платформу смарт-контрактів, не слід занурюватись у паралельну обробку їх форматів пакетів. Я пам'ятаю, що в демонстрації, яку я бачив, було так само — витратили більшу частину часу на обговорення того, як оптимізувати обробку з цих вузлів, і майже не витратили часу на фактичний опис їх протоколу консенсусу.
Висновок: я абсолютно не буду вкладати в цей проєкт.
Цікаво, що через 5 років, коли Хасіб написав у Твіттері, щоб привітати Солану з тим, що вона зайняла своє місце в криптовалюті, і жартував про те, як у той час він упустив великий шанс, співзасновник Солани Толі відповів під цим твітом: "Усі твої занепокоєння на той час дійсно були обґрунтованими. По суті, це ставка — ставка на те, чи зможемо ми вирішити всі ці проблеми, зберігаючи при цьому базові переваги, яких немає в інших командах."
А потім Хасіб відповів Толі: "Я думаю, що це і є один з уроків. Ваша прихильність до оптимізації на базовому рівні та унікальних атакуючих підходів є тим, чого немає в інших командах. Саме це максимальне використання своїх сильних сторін та уникнення слабких є найважливішим. Тоді я зовсім не усвідомлював цього."