Какво е rollup и защо Bitcoin имаше нужда от него?

Проблемът с мащабируемостта на Bitcoin

Bitcoin е проектиран така, че да поставя на първо място проверимостта, децентрализацията и устойчивостта, а не максималния брой транзакции в секунда. Всеки пълен възел валидира транзакциите съгласно правилата на протокола. На базовия слой капацитетът е ограничен и често се оценява на около 7 транзакции в секунда, макар че действителната стойност зависи от вида и размера на транзакциите.

Години наред дебатът се свеждаше до един въпрос: как може да се увеличи капацитетът на Bitcoin, без да се компрометира онова, което го прави уникален?

Опитаните досега пътища

Първият отговор беше Lightning Network, действаща от 2018 г.: мрежа от платежни канали, която позволява бързи и обикновено нискотарифни плащания, включително по маршрути през няколко канала. Тя е предназначена основно за плащания и не предлага среда за смарт договори с общо предназначение. Работата ѝ зависи и от наличната ликвидност, и от възможността да бъде намерен подходящ маршрут.

Stacks поема по друг път: мрежа за смарт договори, свързана с Bitcoin чрез механизма PoX и със собствен език — Clarity. Нейният модел на сигурност и окончателност се различава от този на Bitcoin и освен това зависи от специфичните правила на мрежата Stacks.

Rootstock (RSK) залага на съвместимост с EVM и на съвместен добив (merge-mining) с Bitcoin. Мрежата работи от 2018 г. и използва модел на sidechain със собствени допускания относно сигурността и bridge-а.

Защо rollup е нещо различно

Rollup не е sidechain. Техническото разграничение е важно:

• - Sidechain запазва собствен механизъм за консенсус или валидация. Сигурността ѝ зависи главно от тази система и от дизайна на нейния bridge, който я свързва с Bitcoin.
• - В архитектурата, описана за Bitcoin Hyper, изпълнението би се извършвало извън Bitcoin, докато ангажиментите за състоянието биха се публикували на базовия слой. Дали това наистина отговаря на определението за rollup, зависи и от наличността на данните, и от системата за доказателства.

Според публикуваната от проекта архитектура предвиденият процес би изглеждал така:

1. Потребителите изпращат транзакциите си към секвенсъра
2. Секвенсърът ги подрежда и ги изпълнява на групи (batches)
3. През определени интервали ангажиментът за състоянието, описан като Merkle корен на обновеното състояние, се публикува в Bitcoin чрез OP_RETURN или Taproot
4. Възможността преходът да бъде проверен зависи от наличността на данните и от системата за доказателства; сам по себе си ангажиментът не доказва, че преходът е коректен

Веднага след потвърждаването си в Bitcoin ангажиментът за състоянието придобива практическата неизменност на транзакцията, която го съдържа. Това затруднява последващото изменение на този запис, но само по себе си не възпрепятства публикуването на некоректен ангажимент, нито гарантира валидността на състоянието, наличността на данните или сигурността на bridge-а.

Наличността на данните: все още отворен въпрос

Ключовият въпрос е следният: къде всъщност се намират данните за транзакциите? Ако в Bitcoin се публикува само ангажиментът, а пълните данни останат в ръцете на секвенсъра, архитектурата би била по-близка до модел от типа validium, отколкото до rollup с публична наличност на данните. Това разграничение не е чисто академично: ако секвенсърът изчезне заедно с данните, потребителите може вече да не са в състояние да проверят собственото си салдо.

Според публикуваната от проекта документация окончателното решение за наличността на данните все още се проучва; актуализация от 27 март 2026 г. заявява това изрично. Сред разглежданите варианти са външни слоеве за наличност на данните, като Celestia, erasure coding и използването на разпределени възли.

Rollup върху Bitcoin може да преследва няколко проектни цели: използване на Bitcoin за закотвяне на ангажиментите за състоянието; повишаване на капацитета чрез изпълнение извън веригата; осигуряване на среда за смарт договори; и намаляване на разходите за потребителите. Доколко тези цели могат да бъдат постигнати, зависи от конкретната имплементация, от наличността на данните, от системата за доказателства и от механизмите за излизане.

Цената на този подход е по-голяма архитектурна сложност и няколко проектни решения, които остават неразрешени: секвенсърът, наличността на данните, bridge-ът и системата за доказателства. Проектът твърди, че тези компоненти могат да бъдат управлявани постепенно; това е гледната точка на самия проект и тепърва подлежи на независима проверка.