Artwork

Контент предоставлен Sergei Tikhomirov, Сергей Тихомиров, Иван Иваницкий, Сергей Павлин, and Александр Селезнев. Весь контент подкастов, включая эпизоды, графику и описания подкастов, загружается и предоставляется непосредственно компанией Sergei Tikhomirov, Сергей Тихомиров, Иван Иваницкий, Сергей Павлин, and Александр Селезнев или ее партнером по платформе подкастов. Если вы считаете, что кто-то использует вашу работу, защищенную авторским правом, без вашего разрешения, вы можете выполнить процедуру, описанную здесь https://ru.player.fm/legal.
Player FM - приложение для подкастов
Работайте офлайн с приложением Player FM !

ББ-082: Алекс Скиданов (NEAR) о шардинге в блокчейнах и спортивном программировании

1:27:47
 
Поделиться
 

Manage episode 238587307 series 1542756
Контент предоставлен Sergei Tikhomirov, Сергей Тихомиров, Иван Иваницкий, Сергей Павлин, and Александр Селезнев. Весь контент подкастов, включая эпизоды, графику и описания подкастов, загружается и предоставляется непосредственно компанией Sergei Tikhomirov, Сергей Тихомиров, Иван Иваницкий, Сергей Павлин, and Александр Селезнев или ее партнером по платформе подкастов. Если вы считаете, что кто-то использует вашу работу, защищенную авторским правом, без вашего разрешения, вы можете выполнить процедуру, описанную здесь https://ru.player.fm/legal.

Алекс Скиданов - сооснователь NEAR. NEAR protocol решает проблему масштабирования с помощью шардинга и proof-of-stake. До перехода в блокчейн-индустрию Алекс побеждал на чемпионате мира по программированию ACM ICPC и был первым сотрудником MemSQL. Обсуждаем отличия спортивного программирования от промышленного, эволюцию баз данных и масштабирование блокчейнов. Шардированные протоколы с proof-of-stake сталкиваются со множеством новых проблем: как NEAR их решает?

  • 00:30 спортивное программирование и победы на ACM ICPC
  • 01:55 отличия спортивного программирования от промышленного, вредные привычки спортивных программистов
  • 04:50 почему программисты из России так часто выигрывают чемпионат мира?
  • 05:36 чем чемпионат по программированию отличается от хакатона?
  • 07:51 работа Алекса в MemSQL: как разработать очень быструю базу данных?
  • 12:21 развитие индустрии баз данных: прогресс остановился?
  • 14:29 мир стартапов в Кремниевой Долине: компания Алекса в Y Combinator
  • 18:02 зачем делать ещё один блокчейн-стартап?
  • 21:15 три школы масштабирования блокчейнов. "Solana ушла настолько вперёд, что в плане скорости её не догнать" (если все узлы валидируют всё)
  • 25:01 Layer-2 для масштабирования: каналы, сайдчейны, rollups
  • 26:34 Подход NEAR к масштабированию: шардинг
  • 28:42 почему "наивный" подход для шардированных систем требует слишком много доверия
  • 29:01 стандартный подход: выбирать валидаторов на шарды рандомно, чтобы нельзя было сконцентрировать стейк
  • 31:27 откуда берётся рандом? Threshold relays (Dfinity) и RANDAO + VDF (Ethereum)
  • 34:11 моделирование времени в proof-of-stake: можно ли верить часам валидаторов?
  • 35:50 архитектура NEAR и три типа атак на шардированные proof-of-stake-системы. Невалидный переход и доступность данных
  • 41:16 что делать, если всё-таки обнаружится заголовок невалидного блока на beacon chain?
  • 42:50 как ограничить ущерб, если один шард скомпрометирован? "Social consensus это всегда дорого и неприятно"
  • 44:13 проблема доступности данных (data availability)
  • 45:26 вопрос от Дмитрия Ховратовича: делаете ли proof of custody и какой? Адаптивный злоумышленник и быстрое перебрасывание валидаторов между шардами для проверки доступности данных
  • 49:43 аналогия с miner's dilemma
  • 50:21 решение Ethereum: последний бит от хеша блока плюс коммитмента, валидация блоков без стейта
  • 52:41 вопрос от Егора Хомякова: какая модель безопасности? Что валидаторы могут делать плохого? Предположения: максимум 33% византийских узлов, максимум 50% офлайн (по стейку)
  • 55:55 система мотивации в proof-of-stake: циклический аргумент?
  • 57:36 почему не proof-of-work?
  • 59:01 дизайн-пространство proof-of-stake: разные протоколы сойдутся к одному? Проблема DPOS
  • 1:01:03 как NEAR решает data availability с помощью erasure code
  • 1:06:20 сложные протоколы увеличивают поверхность атаки?
  • 1:09:31 контракты в NEAR: WASM и Typescript; опасность "простых" языков и Rust
  • 1:13:15 проблемы какой сложности имеет смысл класть на блокчейн?
  • 1:15:00 проблема оракулов и постонная цена газа
  • 1:16:16 какую проблему решает NEAR?
  • 1:17:56 кому и зачем нужны децентрализованные технологии? Будущее DeFi и Web3
  • 1:19:52 максимально оптимистичный сценарий для блокчейнов и для NEAR
  • 1:21:33 NEAR как централизованная компания и децентрализованный протокол - есть ли противоречие? Планы передачи контроля сообществу, выкатывание обновлений, on-chain governance
  • 1:24:47 ближайшие планы: запуск тестнета (скоро) и мейннета (1 ноября)

Ссылки:

Поддержите подкаст!

basicblockradio.com

  continue reading

187 эпизодов

Artwork
iconПоделиться
 
Manage episode 238587307 series 1542756
Контент предоставлен Sergei Tikhomirov, Сергей Тихомиров, Иван Иваницкий, Сергей Павлин, and Александр Селезнев. Весь контент подкастов, включая эпизоды, графику и описания подкастов, загружается и предоставляется непосредственно компанией Sergei Tikhomirov, Сергей Тихомиров, Иван Иваницкий, Сергей Павлин, and Александр Селезнев или ее партнером по платформе подкастов. Если вы считаете, что кто-то использует вашу работу, защищенную авторским правом, без вашего разрешения, вы можете выполнить процедуру, описанную здесь https://ru.player.fm/legal.

Алекс Скиданов - сооснователь NEAR. NEAR protocol решает проблему масштабирования с помощью шардинга и proof-of-stake. До перехода в блокчейн-индустрию Алекс побеждал на чемпионате мира по программированию ACM ICPC и был первым сотрудником MemSQL. Обсуждаем отличия спортивного программирования от промышленного, эволюцию баз данных и масштабирование блокчейнов. Шардированные протоколы с proof-of-stake сталкиваются со множеством новых проблем: как NEAR их решает?

  • 00:30 спортивное программирование и победы на ACM ICPC
  • 01:55 отличия спортивного программирования от промышленного, вредные привычки спортивных программистов
  • 04:50 почему программисты из России так часто выигрывают чемпионат мира?
  • 05:36 чем чемпионат по программированию отличается от хакатона?
  • 07:51 работа Алекса в MemSQL: как разработать очень быструю базу данных?
  • 12:21 развитие индустрии баз данных: прогресс остановился?
  • 14:29 мир стартапов в Кремниевой Долине: компания Алекса в Y Combinator
  • 18:02 зачем делать ещё один блокчейн-стартап?
  • 21:15 три школы масштабирования блокчейнов. "Solana ушла настолько вперёд, что в плане скорости её не догнать" (если все узлы валидируют всё)
  • 25:01 Layer-2 для масштабирования: каналы, сайдчейны, rollups
  • 26:34 Подход NEAR к масштабированию: шардинг
  • 28:42 почему "наивный" подход для шардированных систем требует слишком много доверия
  • 29:01 стандартный подход: выбирать валидаторов на шарды рандомно, чтобы нельзя было сконцентрировать стейк
  • 31:27 откуда берётся рандом? Threshold relays (Dfinity) и RANDAO + VDF (Ethereum)
  • 34:11 моделирование времени в proof-of-stake: можно ли верить часам валидаторов?
  • 35:50 архитектура NEAR и три типа атак на шардированные proof-of-stake-системы. Невалидный переход и доступность данных
  • 41:16 что делать, если всё-таки обнаружится заголовок невалидного блока на beacon chain?
  • 42:50 как ограничить ущерб, если один шард скомпрометирован? "Social consensus это всегда дорого и неприятно"
  • 44:13 проблема доступности данных (data availability)
  • 45:26 вопрос от Дмитрия Ховратовича: делаете ли proof of custody и какой? Адаптивный злоумышленник и быстрое перебрасывание валидаторов между шардами для проверки доступности данных
  • 49:43 аналогия с miner's dilemma
  • 50:21 решение Ethereum: последний бит от хеша блока плюс коммитмента, валидация блоков без стейта
  • 52:41 вопрос от Егора Хомякова: какая модель безопасности? Что валидаторы могут делать плохого? Предположения: максимум 33% византийских узлов, максимум 50% офлайн (по стейку)
  • 55:55 система мотивации в proof-of-stake: циклический аргумент?
  • 57:36 почему не proof-of-work?
  • 59:01 дизайн-пространство proof-of-stake: разные протоколы сойдутся к одному? Проблема DPOS
  • 1:01:03 как NEAR решает data availability с помощью erasure code
  • 1:06:20 сложные протоколы увеличивают поверхность атаки?
  • 1:09:31 контракты в NEAR: WASM и Typescript; опасность "простых" языков и Rust
  • 1:13:15 проблемы какой сложности имеет смысл класть на блокчейн?
  • 1:15:00 проблема оракулов и постонная цена газа
  • 1:16:16 какую проблему решает NEAR?
  • 1:17:56 кому и зачем нужны децентрализованные технологии? Будущее DeFi и Web3
  • 1:19:52 максимально оптимистичный сценарий для блокчейнов и для NEAR
  • 1:21:33 NEAR как централизованная компания и децентрализованный протокол - есть ли противоречие? Планы передачи контроля сообществу, выкатывание обновлений, on-chain governance
  • 1:24:47 ближайшие планы: запуск тестнета (скоро) и мейннета (1 ноября)

Ссылки:

Поддержите подкаст!

basicblockradio.com

  continue reading

187 эпизодов

Все серии

×
 
Loading …

Добро пожаловать в Player FM!

Player FM сканирует Интернет в поисках высококачественных подкастов, чтобы вы могли наслаждаться ими прямо сейчас. Это лучшее приложение для подкастов, которое работает на Android, iPhone и веб-странице. Зарегистрируйтесь, чтобы синхронизировать подписки на разных устройствах.

 

Краткое руководство