Wczoraj ogłosiliśmy, że nowa wersja protokołu Tinyman AMM pojawi się w styczniu 2023 r. W tym poście na blogu chcielibyśmy przedstawić przegląd nowego protokołu i wyjaśnić kolejne kroki. Podajemy te szczegóły na wczesnym etapie przed uruchomieniem, aby dać użytkownikom i projektom ekosystemu wystarczająco dużo czasu na zapoznanie się z nowym protokołem i przygotowanie się do migracji.

Od czasu premiery Tinyman AMM w październiku 2021 r. w protokole Algorand wprowadzono wiele ulepszeń, które pozwalają aplikacjom robić bardziej złożone i interesujące rzeczy, jednocześnie poprawiając bezpieczeństwo i usuwając niektóre punkty tarcia. Przez ostatnie 6 miesięcy pracowaliśmy nad projektowaniem, budowaniem i testowaniem nowej implementacji Tinyman AMM, która wykorzystuje te ulepszenia.

Niektóre najważniejsze elementy tego nowego protokołu obejmują:

• Dynamiczne obliczanie wyników w celu wyeliminowania konieczności wykupu
• Elastyczne dodawanie i usuwanie płynności
• Błyskawiczne pożyczki i błyskawiczne swapy
• Dynamiczne ustawienia opłat
• Pełna komponowalność i interoperacyjność
• Dodatkowe kontrole bezpieczeństwa
• Poprawiona czytelność umowy

Tinyman AMM V2 jest bez uprawnień

Tinyman AMM V2 jest niezmienny (nie można go aktualizować)

Tinyman AMM V2 nie ma kluczy administratora do wstrzymywania aktywności lub opróżniania pul

Tinyman AMM V2 jest przejrzysty i ma otwarte oprogramowanie

Tinyman AMM V2 jest audytowany

Tinyman AMM V2 jest nadal śmiesznie szybki i tani w użyciu

Nigdy więcej wykupów

Jednym z najważniejszych ulepszeń protokołu Algorand w ciągu ostatniego roku było wprowadzenie Inner Transactions. Umożliwiają one kontraktom programowe tworzenie transakcji. Dzięki temu Tinyman może dynamicznie obliczać wyniki wymiany i wystawiać transakcję na pełną kwotę wyjściową. Kontrakty nadal bezpiecznie zapewniają otrzymanie minimalnej oczekiwanej kwoty.

Eliminuje to główne źródło tarć i nieporozumień i natychmiast przekłada się na lepsze wrażenia użytkownika.

Koniec z akceptacją aplikacji

Teraz, gdy nie musimy już obsługiwać wykupów, nie musimy również przechowywać w łańcuchu poszczególnych stanów użytkownika. To pozwala nam usunąć wymóg wyrażenia zgody na aplikację kontraktową Tinyman. Spowoduje to zwolnienie niektórych minimalnych wymagań dotyczących równowagi użytkowników Tinyman i usunięcie kolejnego źródła tarcia.

Zgody na aktywa są nadal wymagane, ale teraz możemy je pogrupować z wymianą i innymi operacjami, dzięki czemu użytkownicy nie będą musieli podpisywać ich osobno. Przyspieszy to proces i ograniczy kroki związane z zamianą.

Bardziej elastyczne zarządzanie płynnością

Zauważyliśmy, że bardzo powszechnym wzorcem wśród użytkowników, którzy chcą zostać poolerami, była zamiana jednego aktywa na inny, a następnie zdeponowanie równej kwoty obu w puli. Dodaliśmy funkcję, która automatyzuje ten krok na poziomie protokołu, dzięki czemu użytkownik może dodać płynność do puli z tylko jednym z aktywów puli w jednej operacji. Jest również elastyczny, więc użytkownik może dodać wszystko, co ma dostępne z każdego zasobu, a pula zrównoważy wszystko i wyda odpowiednią liczbę tokenów puli dla łącznej wartości.

Bardzo ważne jest, aby zrozumieć, że podczas korzystania z tej techniki użytkownik nadal ma kontakt z obydwoma zasobami. Niejawna wewnętrzna zamiana jest tylko funkcją wygodną dla użytkownika. Ważne jest również, aby zrozumieć, że ta funkcja jest najbardziej odpowiednia dla małych poolerów. Aby w ogóle stworzyć zrównoważoną pulę, nadal muszą istnieć jacyś poolerzy ze znaczną płynnością w obu aktywach.

Ta funkcja zapewnia również, że cała płynność użytkownika w tokenie LP jest prawidłowo rozliczana, nawet jeśli dostarcza on płynność w nieprawidłowym stosunku. Poprawia to bezpieczeństwo nowych użytkowników puli w okresach dużej zmienności.

Protokół obsługuje teraz również usuwanie płynności tylko z jednego składnika aktywów. Jest to odwrotność powyższego przypadku, w którym niejawna wewnętrzna wymiana ma miejsce przed zwróceniem środków użytkownikowi jako wybranego składnika aktywów.

Te dwie funkcje pozwalają nam poprawić wrażenia użytkownika poprzez uproszczenie typowych przepływów. Jednak kładą one również podwaliny pod znacznie bardziej złożone interakcje między umowami.

Komponowalność i interoperacyjność

Ponownie skorzystaliśmy z najnowszych ulepszeń protokołu Algorand, aby zaprojektować protokół V2 tak, aby był w pełni komponowalny i interoperacyjny. Oznacza to, że transakcje Tinyman V2 można umieszczać w tych samych grupach atomowych, co inne transakcje, oraz że Tinyman V2 można wywoływać z innych kontraktów.

To pozwala nam i innym na budowanie funkcji na szczycie protokołu dla atomowych swapów multihop, zleceń z limitem, metapooli i wielu innych. Te funkcje pomogą poprawić komfort użytkowania dla osób wymieniających się, jednocześnie zwiększając wolumen w pulach Tinyman i generując wyższe opłaty dla puli.

Błyskawiczne pożyczki i swapy

Jedną z funkcji, która wykorzystuje tę komponowalność, są pożyczki błyskawiczne. Mamy teraz wsparcie dla tego wbudowane w protokół, dzięki czemu użytkownicy mogą wziąć pożyczkę z zerowym zabezpieczeniem z puli, o ile spłacają ją w ramach tej samej grupy transakcji. Może się to wydawać bezużyteczną funkcją, ale dzięki interoperacyjności protokołu i rozwijającej się przestrzeni Algorand DeFi będzie mnóstwo możliwości zarobku w ramach jednego bloku. Jest to złożona funkcja i przeznaczona do użytku wyłącznie przez osoby ze szczegółową znajomością protokołów i strategii DeFi i jako taka nie będzie uwzględniona w internetowym interfejsie użytkownika. Włączenie tej funkcji wynika z naszej podstawowej filozofii dostarczania narzędzi finansowych wszystkim, niezależnie od ich zamożności.

Błyskawiczne swapy i pożyczki są wolne od ryzyka dla protokołu (w sensie finansowym) i zapewniają dodatkowe źródło dochodów dla poolerów.

Regulowane opłaty

Tinyman AMM V1 ma stałą opłatę za swap w wysokości 30 punktów bazowych, która jest podzielona w stosunku 5:1 między poolerów i protokół. Do tej pory dobrze służyło to użytkownikom, ale są przypadki, w których bardziej odpowiednie byłyby inne opcje opłat. W przypadku aktywów powiązanych/stabilnych niższa opłata, która powoduje mniejszy wpływ na cenę, byłaby korzystna dla osób wymieniających się. Zwiększony wolumen dzięki niższym opłatom powinien również przynieść korzyści przedsiębiorcom. Zamiast fragmentacji płynności w wielu pulach dla różnych poziomów opłat za te same pary aktywów, protokół V2 umożliwia dostosowywanie opłat z puli w czasie. Wszystkie pule rozpoczną się z ustawieniami domyślnymi (takimi samymi jak V1), ale stawka opłaty może zostać zmieniona przez konto Setera opłat w dozwolonych granicach.

Zamiarem jest, aby ustalający opłaty początkowo był kontem kontrolowanym przez podstawowy zespół Tinyman, a opłaty będą dostosowywane tylko do par stabilnych/powiązanych. Później zamierzamy wprowadzić funkcję umożliwiającą poolerom wspólne decydowanie o opłatach za ich pool. Docelowo chcemy, aby wszystkie opłaty były kontrolowane przez Tinyman DAO, jeśli takie istnieje. Protokół ma być elastyczny pod tym względem, tak aby odpowiedzialność za ustalanie i pobieranie opłat mogła być delegowana do inteligentnych kontraktów lub kont zewnętrznych i w razie potrzeby odwołana. Pozwala to na zmianę zasad i mechanizmów dotyczących opłat w czasie bez wpływu na inne aspekty protokołu. Dalsze szczegóły zostaną podane przed uruchomieniem zasad dotyczących zmian opłat.

Bezpieczniejszy, przejrzysty protokół

Z każdym protokołem wiążą się założenia projektowe i nieodłączne ograniczenia techniczne. Udokumentowaliśmy to wcześniej dla V1 i wprowadziliśmy zabezpieczenia w interfejsie użytkownika, aby uniemożliwić użytkownikom korzystanie z protokołu w nieoczekiwany sposób. Dzięki Tinyman V2 byliśmy w stanie pójść o krok dalej i wymusić niektóre z nich na poziomie protokołu.

Istnieje szereg niezmienników matematycznych/logicznych, które powinny być zawarte w protokole. W Tinyman V2 są one jawnie sprawdzane po każdej operacji, aby zapewnić, że nawet przy bardzo nieoczekiwanym zachowaniu pule nie stracą na wartości.

Protokół może być bezpieczny tylko wtedy, gdy może być łatwo odczytany, zrozumiany i przejrzany przez wiele niezależnych osób. Aby pomóc w tym zakresie, włożyliśmy pracę w szereg obszarów:

• Czytelny kod źródłowy kontraktu — Opracowaliśmy nowy język dla Algorand, Tealish , który pozwala nam jasno wyrażać naszą logikę i intencje na wysokim poziomie, jednocześnie kompilując się do czytelnego niskiego poziomu Teal. Fergal Walsh (Tinyman CTO) będzie mówił o Tealish i o tym, jak został użyty w V2 na Decipher 2022 .

• Audyty podlegające audytowi — Specyfikacje protokołów i umowy zostały przeanalizowane i poddane audytowi na wielu poziomach, aby spróbować zidentyfikować wiele różnych rodzajów problemów. Obejmuje to analizę i modelowanie specyfikacji, kodu źródłowego Tealish i wygenerowanego kodu Teal, który ostatecznie jest wykonywany na AVM. Współpracowaliśmy z audytorami, aby proces audytu był bardziej przejrzysty niż zwykle. W nadchodzących tygodniach opublikujemy kolejny wpis na blogu na ten temat z odniesieniami do raportów i wszystkich materiałów pomocniczych.
• Bug Bounty — Współpracowaliśmy z Algorand Foundation i Immunefi, aby stworzyć program bug bounty z nagrodami w wysokości do 250 000 USD za krytyczne problemy. Ten program jest natychmiast dostępny i pozostanie aktywny po uruchomieniu sieci Mainnet.
• Publiczne kontrakty i specyfikacje open source — Opublikowaliśmy kontrakty źródłowe, wygenerowaliśmy Teal i końcowy kod bajtowy wraz z dokumentem projektowym protokołu i specyfikacją. Dzięki temu każdy może przejrzeć szczegóły protokołu, aby upewnić się, że jego implementacja odpowiada jego oczekiwaniom.

Regularnie jesteśmy pytani, dlaczego nie ma Wielkiego Czerwonego Przycisku, aby Tinyman mógł wstrzymać kontrakty, jeśli coś pójdzie nie tak. Kwestia ta została podniesiona bardziej po niefortunnym incydencie w styczniu. Projektując V2, dużo myśleliśmy nad tym pytaniem. Czy możemy zaimplementować funkcję pauzy? Jak by to działało? Kto może to kontrolować? Kto jest odpowiedzialny za jego wywołanie? Co dzieje się po pauzie? Więcej szczegółów na ten temat omówimy w przyszłym poście na temat kwestii bezpieczeństwa, ale ostatecznie doszliśmy do tego samego wniosku, który mieliśmy podczas projektowania V1; nie ma bezpiecznego i użytecznego mechanizmu pauzy, który nie naruszałby podstawowych wartości Tinymana i ogólnie DeFi. Mechanizm pauzy bez kontraktów, które można aktualizować, nie jest zbyt przydatny, a kontrakty, które można aktualizować, to druga strona linii, której nie chcemy przekraczać. Kontrakty, które można aktualizować, umożliwiłyby zespołowi Tinyman (lub atakującemu) zmianę zasad protokołu i potencjalne przejęcie kontroli nad płynnością. Głównym celem DeFi jest uniknięcie takich możliwości.

Twoje fundusze, Twoja decyzja

Jako zespół jesteśmy podekscytowani nowym protokołem i byliśmy zajęci budowaniem wokół niego nowego i ulepszonego interfejsu użytkownika. Wierzymy, że użytkownicy będą mieli znacznie lepsze wrażenia z korzystania z nowego protokołu, ale ostatecznie to Twoja decyzja jako użytkownika protokołu. Umieszczając swoje środki w V1 zgodziłeś się, że będą one związane zasadami i logiką kontraktów V1. Z założenia nie możemy zmienić tych zasad, aby przenieść Twoją płynność do V2. To musi być twoja decyzja. Zachęcamy wszystkich poolerów na V1 do zapoznania się ze szczegółami protokołu i raportu z niezależnego audytu oraz do samodzielnego decydowania, czy chcą przenieść swoją płynność do V2. Protokół V1 będzie nadal działał w Algorand Mainnet przez wieczność, a my będziemy nadal wspierać istniejące pule w internetowym interfejsie użytkownika w dającej się przewidzieć przyszłości.

Następne kroki

Mamy nadzieję, że jesteście tak samo podekscytowani V2, jak my. To jednak dopiero początek! Mamy również wiele ulepszeń interfejsu użytkownika, które zostaną wprowadzone wraz z protokołem V2. Omówimy je w kolejnych wpisach na blogu w nadchodzących tygodniach. Po uruchomieniu pojawią się dodatkowe ulepszenia i funkcje zbudowane na fundamencie zapewnianym przez protokół V2.

Przed premierą opublikujemy również dodatkowe posty na temat planu migracji.

W międzyczasie sugerujemy zapoznanie się ze szczegółami protokołu i zadawanie pytań w naszych przestrzeniach społecznościowych.

Bibliografia

Dokumentacja i specyfikacja protokołu V2

Repozytorium kontraktów V2

Raport z audytu kontraktów V2

Tealish Repo

Immunefi Bug Bounty Program (link do dodania)