Читая стейкинг-документацию Babylon, одна строка поразила меня больше всего, даже сильнее чем любая схема: арбитраж и судебное принуждение, рядом с оговорками, которые ограничивают ответственность сторон Babylon.
Я воспринимаю Babylon как два слоя, описывающих одну систему. Технический слой — хранилища, координация валидаторов, потоки выкупа — отвечает за то, что можно проверить. Нетехнический слой — оговорки, арбитражные положения — отвечает за то, что проверить нельзя.
Набор валидаторов приходит к консенсусу, хранилище проверяет условия, контракт применяет фиксированные правила — но все это не решает спор, когда в дело вступают люди, юрисдикции или обязательства вне блокчейна. Тогда на смену этому приходят арбитраж и суды.
Для меня это не «пробел» в дизайне — это и есть дизайн. Децентрализация не заменяет правовую инфраструктуру; она лишь сужает, где именно этой инфраструктуре нужно действовать. Код поглощает рутинное трение; право остается про запас для того, что код не может разрешить.
Babylon не стирает институты — оно отмечает, с чего начинается принуждение
$BABY
@BabylonLabs_io #baby $COTI $VANRY
Я воспринимаю Babylon как два слоя, описывающих одну систему. Технический слой — хранилища, координация валидаторов, потоки выкупа — отвечает за то, что можно проверить. Нетехнический слой — оговорки, арбитражные положения — отвечает за то, что проверить нельзя.
Набор валидаторов приходит к консенсусу, хранилище проверяет условия, контракт применяет фиксированные правила — но все это не решает спор, когда в дело вступают люди, юрисдикции или обязательства вне блокчейна. Тогда на смену этому приходят арбитраж и суды.
Для меня это не «пробел» в дизайне — это и есть дизайн. Децентрализация не заменяет правовую инфраструктуру; она лишь сужает, где именно этой инфраструктуре нужно действовать. Код поглощает рутинное трение; право остается про запас для того, что код не может разрешить.
Babylon не стирает институты — оно отмечает, с чего начинается принуждение
$BABY
@BabylonLabs_io #baby $COTI $VANRY
