Слой 2: бързото потвърждение не е равнозначно на окончателен сетълмент
Картографирайте приемането на транзакции, публикуването на данни и приключването на тегленията в система за мащабиране.

Назовете етапа, който наблюдавате
Бързо потвърждение в интерфейса може да означава, че секвенсър е приел транзакцията, а не че всички последващи условия за сетълмент са изпълнени. Системите от слой 2 извършват работа извън базовата верига и използват допълнителни механизми за уреждане или проверка на резултатите. Документацията на Ethereum за мащабиране разграничава оптимистичните подходи от подходите с доказателства за валидност. Архитектурата определя какво наблюдателят може безопасно да заключи на всеки етап.
Използвайте точни обозначения в изследователска бележка: подадено, прието от оператора, включено в пакет, публикувано в базовата верига, проверено или с приключил срок за оспорване и изтеглено. Не всяка система използва точно тези етапи, но сливането им в една дума — потвърдено — скрива оперативни разлики, важни за борсите и управляващите обезпечение.
Разберете разликата в проверката
Оптимистичните rollup системи разчитат на механизми за оспорване на неверни твърдения за състоянието в определен прозорец. Конструкциите с доказателство за валидност подават криптографски доказателства за преходите на състоянието, но наличността на данни, обновяванията и оперативните им договорености пак изискват проверка. Системата за доказателства е един компонент на сигурността, не обща гаранция за всяко приложение или мост около нея.
Практическото упражнение е да попитате какво би станало, ако оператор подаде грешен резултат, спре обработването на трансакции или откаже необходима услуга. Определете кои участници могат да реагират и каква информация им е нужна. Отговорът трябва да идва от документацията на внедрената система, не от идеализирано описание на широката категория.
Разграничавайте забавянето на сетълмента от ликвидността за теглене
Тегленето чрез самия протокол може да изисква изчакване на неговите условия. Външен доставчик на ликвидност може да предложи средствата по-рано срещу такса, фактически предоставяйки друг изход. Този маршрут променя експозицията; не премахва условията за сетълмент на базовия протокол. Капацитетът може да се свие при стрес точно когато много потребители искат ранен изход.
Представете си задължение с падеж утре в базовата верига и активи, чието стандартно теглене отнема няколко дни в хипотетична система. Тези активи може да са ценни, но недостъпни по необходимия график. Котировка за бърз изход е полезно доказателство само за действително котираните сума и момент. Не трябва да се приема, че ще остане налична при масов наплив на целия пазар.
Проверете контролите и инфраструктурата
Концентрацията на секвенсъри, ключовете за надграждане, аварийните съвети, подаването на доказателства и публикуването на данни заслужават отделни редове в сравнението. Система може да има силни правила за проверка на трансакции, докато разчита на централизирани оперативни услуги. Прекъсване може да засегне достъпността, без да промени собствеността, но невъзможността за трансакции все пак може да причини финансови щети, ако позициите изискват спешна корекция.
Проверете дали съществуват механизми за принудително включване или алтернативен изход, кой може да ги използва и какви са практическите забавяния. Теоретично достъпен път за изход може да изисква такси в базовата верига, технически стъпки и периоди на изчакване. При нетехническо проучване документирайте тези изисквания, вместо да приемате, че „без разрешение“ означава лесен или незабавен достъп.
Измервайте общия разход за целия жизнен цикъл
Ниските такси за трансакции могат да са ценни, но пълното сравнение включва депозити, тегления, прехвърляния през мостове, ликвидност в целевата мрежа и време, през което средствата са недостъпни. Стратегия с чести локални трансакции и редки тегления има различен профил на разходите от такава, която постоянно мести средства между мрежи. Подходящата единица за сравнение е целият работен процес, а не една удобно евтина операция.
Изградете времева линия за обичаен случай и случай на прекъсване. Запишете кой баланс е разходваем във всеки момент и кои допускания биха забавили следващата стъпка. Това прави анализа полезен без прогноза коя система за мащабиране ще успее. Техническата пропускателност, окончателността, ликвидността и стойността на токена на приложението са отделни теми и не бива да се представят така, сякаш подобряването на едната автоматично подобрява всички останали.
Полезно заключително упражнение е да обозначите един и същ баланс в три момента: използваем локално, достъпен за изход чрез самия протокол и използваем в крайната мрежа. Отделните времеви печати правят ликвидните празнини видими. Ако краен срок попада в такава празнина, позицията има оперативен проблем с финансирането, дори ако всеки баланс накрая се уреди правилно и няма трайно изгубена главница.
Достъпните данни не са гарантиран вечен архив
За проверка на промяна в състоянието са нужни съответните данни. Достъпността им в необходимия момент не означава, че всяка услуга ще ги пази завинаги. Разграничавай наличността за проверка от по-късното извличане на историята.
Задай два въпроса: какво е нужно на мрежата, за да приеме промяната, и откъде потребителят по-късно ще получи доказателство за своята операция? Липсващ стар запис в един интерфейс не доказва, че трансакцията не е била потвърдена.
Пази идентификатора, мрежата, датата на проверка и източника на данни. Бързото съобщение на приложението не потвърждава, че едновременно са приключили всички етапи на окончателното уреждане и всички условия за теглене.
Провери изхода без обичайния сайт
При условен отказ сайтът изчезва, но договорите и мрежата продължават да работят. Има ли документиран и използваем изход? Какво изисква? Възможност на ниво протокол не е равна на практическата способност на потребителя да я изпълни.
Добави към картата посредническата услуга, секвенсъра, механизма за доказване и приемащата платформа. Премахвай ги поотделно и проверявай оставащите стъпки. Не предполагай еднакво бърз резервен път във всяка система или поддръжка на всяка функция във всяка платформа.
Различавай наблюдавана работа, описана възможност и непроверено допускане. Така привлекателният брой секунди не скрива зависимостите на крайния достъп до средствата и случаите, в които чакането може да се удължи.