На этот раз, когда я читал документацию по разработке Dusk, меня остановило не ZK и не вопросы приватности.
А одна маленькая деталь интерфейса:
**узел сообщает клиенту свою версию Rusk, и при этом клиент может сам запросить диапазон версий.**
Если версии несовместимы — просто отклоняют.
С первого взгляда это вообще никак не связано с большой «блокчейн»-историей.
Но когда я встроил это в реальный процесс разработки, внезапно показалось довольно интересным.
Потому что большинство ончейн-приложений больше всего боятся не того, что интерфейс работает чуть медленнее.
А вот этого:
сегодня всё работает, а после обновления вдруг начинают появляться ситуации «часть узлов принимает, а часть — нет».
Если разработчик не понимает, какую именно версию запускают те узлы, к которым он подключается, ему очень трудно определить, проблема в коде, в узлах или в самой сути протокола.
Сейчас Dusk выводит эту информацию о версии прямо в HTTP-ответ, а также позволяет клиенту выполнять strict version check.
Раньше я больше привык оценивать, годится ли L1 для использования, по TPS и финальности.
А сейчас, наоборот, мне кажется, что такие небольшие правила на уровне интерфейса лучше всего показывают, подумала ли сеть всерьёз о тех трудностях, с которыми разработчики реально столкнутся.
Потому что инфраструктура больше всего боится не сложности.
А **неопределённости**.
Если приложение зависит от определённой возможности узла, и после обновления узел начинает вести себя иначе, то чаще всего в самой неприятной ситуации оказываются не команда, которая делает протокол, а уже запущенные приложения.
Так что эта, на вид довольно «инженерная», система контроля версий на самом деле решает очень насущную проблему:
помочь разработчикам понять, с какой именно «линией» правил протокола они сейчас разговаривают.
Вот почему я сейчас думаю, что в Dusk есть чему по-настоящему уделить внимание.
По-настоящему зрелый L1 — это не только «заставить цепочку работать».
Нужно ещё и сделать так, чтобы при подключении других было понятно, где находятся границы.
#dusk $DUSK @Dusk
А одна маленькая деталь интерфейса:
**узел сообщает клиенту свою версию Rusk, и при этом клиент может сам запросить диапазон версий.**
Если версии несовместимы — просто отклоняют.
С первого взгляда это вообще никак не связано с большой «блокчейн»-историей.
Но когда я встроил это в реальный процесс разработки, внезапно показалось довольно интересным.
Потому что большинство ончейн-приложений больше всего боятся не того, что интерфейс работает чуть медленнее.
А вот этого:
сегодня всё работает, а после обновления вдруг начинают появляться ситуации «часть узлов принимает, а часть — нет».
Если разработчик не понимает, какую именно версию запускают те узлы, к которым он подключается, ему очень трудно определить, проблема в коде, в узлах или в самой сути протокола.
Сейчас Dusk выводит эту информацию о версии прямо в HTTP-ответ, а также позволяет клиенту выполнять strict version check.
Раньше я больше привык оценивать, годится ли L1 для использования, по TPS и финальности.
А сейчас, наоборот, мне кажется, что такие небольшие правила на уровне интерфейса лучше всего показывают, подумала ли сеть всерьёз о тех трудностях, с которыми разработчики реально столкнутся.
Потому что инфраструктура больше всего боится не сложности.
А **неопределённости**.
Если приложение зависит от определённой возможности узла, и после обновления узел начинает вести себя иначе, то чаще всего в самой неприятной ситуации оказываются не команда, которая делает протокол, а уже запущенные приложения.
Так что эта, на вид довольно «инженерная», система контроля версий на самом деле решает очень насущную проблему:
помочь разработчикам понять, с какой именно «линией» правил протокола они сейчас разговаривают.
Вот почему я сейчас думаю, что в Dusk есть чему по-настоящему уделить внимание.
По-настоящему зрелый L1 — это не только «заставить цепочку работать».
Нужно ещё и сделать так, чтобы при подключении других было понятно, где находятся границы.
#dusk $DUSK @Dusk
