Amarok Update, включва обширни промени в основния протокол, за да подобри значително изживяването да бъдете потребител на Connext мрежата.

Проблеми за потребителите на Connext Network в момента:

• Разходи за транзакции: Настоящият двупосочен процес на подготовка/изпълнение за завършване на транзакции във всички вериги, пречи да бъдат лесно групирани.

• Подписване за приключване на транзакцията: Завършването на транзакции изисква потребителите да подпишат (Sign чрез портфейла) съобщение, за да получат средствата. Това е, което поддържа доверието в Connext сведено до минимум, но е и проблем, защото изисква потребителите да останат онлайн, докато не подпишат.

• Риск от блокиране на средства: Потребителските транзакции имат отношение 1:1 с осигуряващите ликвидност (Router). Ако този Router излезе офлайн или загуби връзката си с веригата по средата на потока, средствата на потребителя могат да бъдат блокирани до изтичане на транзакцията (72 часа).

• Скорост: Тъй като потребителите са обвързани с даден Router за своята транзакция, всички закъснения, които този конкретен Router изпитва, се предават на потребителя.

• Разчленяване на ликвидността: Предоставената ликвидност, зависи от извървяния маршрут, което означава, че е налична само между дадена двойка вериги. С нарастването на броя на веригите става все по-трудно за потребителите да извършват големи транзакции поради липса на ликвидност.

Проблеми за разработчиците (Dev) в момента:

• Зависимости от Off-chain търгове: Повечето интеграции в пространството са само с договори, но Connext в момента изисква стартиране на sdk (Software development kit) от страна на клиента, за да намери Router за дадена транзакция.

• Подписване за приключване на транзакцията: Необходимостта от заявяване, изисква от разработчиците да проследяват текущите транзакции и да “подканят” потребителите да подпишат в точното време. Това добавя много разходи и сложност в сравнение с обикновена On-chain транзакция.

• Няма генерализирани съобщения: Connext вече поддържа съобщения на договори към всички вериги, но това може да се направи безопасно само в някои случаи. Изискването от разработчиците да научат кога могат и не могат да използват тази функция е голямо препятствие.

Проблеми за осигуряващите ликвидност (Routers) в момента:

• Ребалансиране: Осигуряващите ликвидност изпращат средства по веригата на местоназначението и получават средства на източника. Това означава, че тяхната ликвидност се движи между вериги и може да заседне, намалявайки капиталовата ефективност.

• Неясна възвръщаемост на инвестициите (ROI): ROI на осигуряващите ликвидност е трудно за точно проследяване, тъй като двупосочния поток означава, че данните, необходими за проследяване на възвръщаемостта, са фрагментирани/разчленени във вериги.

• Препятствия с таксата за транзакция: Транзакциите могат да бъдат анулирани съвместно от потребители или Routers (LP). Въпреки това, когато това се случи, няма ясен механизъм за възстановяване на първоначалните разходи за транзакцията.

Горе описани точки са първоначални Компромиси направени с протокола за да постигне гаранция за ниски такси на транзакциите и сигурност.

Точно това подобрение се внедрява с Amarok Update!

Как целят да го осъществат ?

Това може да се осъществи чрез партньорство с Nomad. Nomad е “оптимистичен” мост (използващ Optimistic Rollups), който дава сигурна комуникация с минимизирано доверие във всяка верига, но с компромис от 30 минути забавяне.

Общо взето преминават от Monolithic към Modular подход. Препоръчвам, ако на някой му е интересно да изгледа и този клип:

Новият метод на работа включва интензивно използване на Nomad (и евентуално други локализирани слоеве за съобщения!) за своя модел на сигурност. Вместо да изисква подписи(sign), подходът просто позволява на всеки Router(LP) да предявява капитал и да изпълнява извиквания за транзакция на потребителя и да изисква средства от преминаващи през Nomad.

Тъй като нито един Router(LP) не е изрично посочен предварително, съществува риск Router(LP) да могат да се състезават помежду си, за да завършат дадена транзакция.

Това не е оптимален начин на работа, тъй като загубата на това състезание все пак струва такси (транзакции) за всеки Router(LP). За да коригира това, Connext Network въвежда Sequencer (подобен по концепция на rollup), който е отговорен за събирането на оферти (опит за транзакции) от **Router(LP) **и публикуването им във верига на партиди.

Имайте предвид, че ролята на Sequencer в Connext не засяга по никакъв начин основната сигурност на системата или нейните средства.

• Нов метод на работа: Вместо двупосочния поток с подписи, всички транзакции вече се извършват в една транзакция във веригата за изпращане, опростявайки както UX, така и devX. Също така, вече не се нуждаем от анулиране на транзакции, по този начин елиминирайки разходите за такси на Routers (LP).

• 1-of-N-Routing: Всеки Router(LP) може да завърши транзакцията на потребителя, премахвайки възможността за блокиране на средствата на потребителя и значително намалявайки изискванията за жизненост за Routers(LP). Това също така напълно премахва необходимостта от какъвто и да е Off-Chain търг за разработчиците.

• По-евтини и по-бързи транзакции: Новият метод намалява броя на On-chain съобщения от 4 → 2, което прави транзакциите не само много по-евтини, но и по-бързи.

• По-лесен начин на осигуряване на ликвидност: Routers(LP) получават ликвидност по веригата на местоназначението на транзакция, точно там, където я предоставят. Ликвидността също вече не зависи от маршрута. Това елиминира балансирането и фрагментацията, значително подобрявайки капиталовата ефективност и наличността.

Вече има напълно функционална частна тестова мрежа, изпълняваща надстройката на Amarok. Работи се с ключови членове на общността, съществуващи Routers(LP) и някои пилотни партньори с висок профил, за да се разработи и тества мрежата.

Amarok Update, включва обширни промени в основния протокол, за да подобри значително изживяването да бъдете потребител на Connext мрежата.

Проблеми за потребителите на Connext Network в момента:

• Разходи за транзакции: Настоящият двупосочен процес на подготовка/изпълнение за завършване на транзакции във всички вериги, пречи да бъдат лесно групирани.

• Подписване за приключване на транзакцията: Завършването на транзакции изисква потребителите да подпишат (Sign чрез портфейла) съобщение, за да получат средствата. Това е, което поддържа доверието в Connext сведено до минимум, но е и проблем, защото изисква потребителите да останат онлайн, докато не подпишат.

• Риск от блокиране на средства: Потребителските транзакции имат отношение 1:1 с осигуряващите ликвидност (Router). Ако този Router излезе офлайн или загуби връзката си с веригата по средата на потока, средствата на потребителя могат да бъдат блокирани до изтичане на транзакцията (72 часа).

• Скорост: Тъй като потребителите са обвързани с даден Router за своята транзакция, всички закъснения, които този конкретен Router изпитва, се предават на потребителя.

• Разчленяване на ликвидността: Предоставената ликвидност, зависи от извървяния маршрут, което означава, че е налична само между дадена двойка вериги. С нарастването на броя на веригите става все по-трудно за потребителите да извършват големи транзакции поради липса на ликвидност.

Проблеми за разработчиците (Dev) в момента:

• Зависимости от Off-chain търгове: Повечето интеграции в пространството са само с договори, но Connext в момента изисква стартиране на sdk (Software development kit) от страна на клиента, за да намери Router за дадена транзакция.

• Подписване за приключване на транзакцията: Необходимостта от заявяване, изисква от разработчиците да проследяват текущите транзакции и да “подканят” потребителите да подпишат в точното време. Това добавя много разходи и сложност в сравнение с обикновена On-chain транзакция.

• Няма генерализирани съобщения: Connext вече поддържа съобщения на договори към всички вериги, но това може да се направи безопасно само в някои случаи. Изискването от разработчиците да научат кога могат и не могат да използват тази функция е голямо препятствие.

Проблеми за осигуряващите ликвидност (Routers) в момента:

• Ребалансиране: Осигуряващите ликвидност изпращат средства по веригата на местоназначението и получават средства на източника. Това означава, че тяхната ликвидност се движи между вериги и може да заседне, намалявайки капиталовата ефективност.

• Неясна възвръщаемост на инвестициите (ROI): ROI на осигуряващите ликвидност е трудно за точно проследяване, тъй като двупосочния поток означава, че данните, необходими за проследяване на възвръщаемостта, са фрагментирани/разчленени във вериги.

• Препятствия с таксата за транзакция: Транзакциите могат да бъдат анулирани съвместно от потребители или Routers (LP). Въпреки това, когато това се случи, няма ясен механизъм за възстановяване на първоначалните разходи за транзакцията.

Горе описани точки са първоначални Компромиси направени с протокола за да постигне гаранция за ниски такси на транзакциите и сигурност.

Точно това подобрение се внедрява с Amarok Update!

Как целят да го осъществат ?

Това може да се осъществи чрез партньорство с Nomad. Nomad е “оптимистичен” мост (използващ Optimistic Rollups), който дава сигурна комуникация с минимизирано доверие във всяка верига, но с компромис от 30 минути забавяне.

Общо взето преминават от Monolithic към Modular подход. Препоръчвам, ако на някой му е интересно да изгледа и този клип:

Новият метод на работа включва интензивно използване на Nomad (и евентуално други локализирани слоеве за съобщения!) за своя модел на сигурност. Вместо да изисква подписи(sign), подходът просто позволява на всеки Router(LP) да предявява капитал и да изпълнява извиквания за транзакция на потребителя и да изисква средства от преминаващи през Nomad.

Тъй като нито един Router(LP) не е изрично посочен предварително, съществува риск Router(LP) да могат да се състезават помежду си, за да завършат дадена транзакция.

Това не е оптимален начин на работа, тъй като загубата на това състезание все пак струва такси (транзакции) за всеки Router(LP). За да коригира това, Connext Network въвежда Sequencer (подобен по концепция на rollup), който е отговорен за събирането на оферти (опит за транзакции) от **Router(LP) **и публикуването им във верига на партиди.

Имайте предвид, че ролята на Sequencer в Connext не засяга по никакъв начин основната сигурност на системата или нейните средства.

• Нов метод на работа: Вместо двупосочния поток с подписи, всички транзакции вече се извършват в една транзакция във веригата за изпращане, опростявайки както UX, така и devX. Също така, вече не се нуждаем от анулиране на транзакции, по този начин елиминирайки разходите за такси на Routers (LP).

• 1-of-N-Routing: Всеки Router(LP) може да завърши транзакцията на потребителя, премахвайки възможността за блокиране на средствата на потребителя и значително намалявайки изискванията за жизненост за Routers(LP). Това също така напълно премахва необходимостта от какъвто и да е Off-Chain търг за разработчиците.

• По-евтини и по-бързи транзакции: Новият метод намалява броя на On-chain съобщения от 4 → 2, което прави транзакциите не само много по-евтини, но и по-бързи.

• По-лесен начин на осигуряване на ликвидност: Routers(LP) получават ликвидност по веригата на местоназначението на транзакция, точно там, където я предоставят. Ликвидността също вече не зависи от маршрута. Това елиминира балансирането и фрагментацията, значително подобрявайки капиталовата ефективност и наличността.

Вече има напълно функционална частна тестова мрежа, изпълняваща надстройката на Amarok. Работи се с ключови членове на общността, съществуващи Routers(LP) и някои пилотни партньори с висок профил, за да се разработи и тества мрежата.