Głosowanie nad opłatami Solany, osąd zasobów

Solana (SOL) przeprowadza głosowanie on-chain w sprawie zmiany modelu opłat transakcyjnych z opartego na liczbie podpisów na oparty na zasobach wymaganych do realizacji transakcji. Niezależnie od wyniku głosowania, pojawił się problem, jak dokładnie portfele, routery i aplikacje transakcyjne żądają zasobów obliczeniowych, co wpływa na koszty.

Dokument poprawkowy Solany SIMD-0553 zawiera propozycję podziału opłaty w wysokości 5000 lamportów na 2500 lamportów jako podstawową opłatę oraz opłatę za zasoby opartą na żądanych jednostkach kosztów. Opłata za zasoby jest obliczana proporcjonalnie do requested_cost_units i jest całkowicie spalana. Opłata priorytetowa pozostaje w rękach weryfikatorów, tak jak dotychczas.

Oficjalny dokument opłat Solany opisuje obecnie podstawową opłatę na poziomie 5000 lamportów za podpis. Połowa tej kwoty jest spalana, a połowa trafia do weryfikatorów. Dokument budżetu obliczeniowego wyjaśnia, że opłata priorytetowa jest obliczana na podstawie limitu żądanych jednostek obliczeniowych, a nie rzeczywistego zużycia.

Kluczowym punktem tej propozycji nie jest jedynie podwyżka opłat. Jest to bardziej struktura, która dokładniej odzwierciedla zasoby wymagane przez transakcje w cenach. Dotychczas podstawowa opłata działała głównie na podstawie kosztów weryfikacji podpisów, ale nowa propozycja uwzględnia również koszty związane z blokowaniem zapisu, danymi poleceń, wykonaniem programów oraz rozmiarem danych konta.

Requested_cost_units to jednostki kosztów zasobów żądane przed wykonaniem transakcji. Nie są to zasoby rzeczywiście używane, lecz wartości żądane z wyprzedzeniem. Aplikacje, które mają duży margines w budżecie obliczeniowym, mogą ponieść większe koszty w nowej strukturze.

Propozycja przedstawia strukturę bramki funkcji, która podnosi stawki opłat za zasoby do poziomów 1/10, 1/4, 1/2 lamporta. Nie jest to sposób stosowania ostatecznej stawki jednorazowo, lecz projekt oparty na stopniowej aktywacji. Należy jednak zauważyć, że przyjęcie dokumentu nie oznacza automatycznego wprowadzenia go na mainnet.

Crypto Briefing w swoim raporcie symulacyjnym podał, że dzienna ilość spalania SOL na podstawie ostatecznej stawki może wzrosnąć z około 648 SOL do zakresu 1500-9000 SOL. Ten sam raport zauważył, że aplikacje i routery o dużym obciążeniu, takie jak Jupiter, Titan i DFlow, mogą być pod presją wzrostu średnich opłat. Ta liczba jest szacunkowa, a nie wynikiem obserwacji.

Dla poszczególnych aplikacji kluczowe jest, jak precyzyjnie określają one swoje żądania. Aplikacje typu router często obsługują wiele ścieżek transakcyjnych i kont jednocześnie, co może zwiększać rozmiar żądanych zasobów. Z drugiej strony, efektywne transakcje głosowania mogą mieć niższe koszty w nowej strukturze.

Solana Company ogłosiła 21 sierpnia, że jest przeciwna SGP-0003. Firma uważa, że stała opłata jest łatwiejsza do zaplanowania dla użytkowników instytucjonalnych. Zmienność kosztów transakcji przed dostosowaniem się ekosystemu przenosi ryzyko oszacowania na użytkowników i operatorów.

Dyskusja ta jest związana z dokumentem technicznym SIMD-0553 oraz propozycją zarządzania SGP-0003. SIMD zajmuje się samym sposobem obliczania opłat, a SGP pyta, czy sieć powinna podążać w tym kierunku, mając charakter głosowania on-chain. Dokument zarządzania Solany wyjaśnia, że SGP przechodzi do etapu głosowania, gdy uzyska 15% aktywnego poparcia.

Aktualizacja dewelopera Solany ogłosiła 23 lipca, że SIMD dotyczący opłat za zasoby i włączenie został zaakceptowany. Oznacza to przyjęcie dokumentu, ale nie określa momentu aktywacji mainnetu ani zastosowania bramki funkcji. Informacje o weryfikatorach wskazują, że SGP-0003 jest w stanie głosowania.

Czas zakończenia głosowania był różnie przedstawiany w dostępnych materiałach. Niektóre źródła wskazywały na zakończenie o godzinie 0:30 27. dnia według czasu koreańskiego, podczas gdy inne podawały 27 lub 28. W momencie pisania artykułu trudno było ustalić jeden termin zakończenia.

To głosowanie jest kontynuacją naszych wcześniejszych doniesień o tym, że weryfikatorzy Solany głosują nad propozycją zarządzania, która jednocześnie zajmuje się szybkością nowego wydania i strukturą opłat. Wcześniej informowaliśmy, że weryfikatorzy Solany głosują nad propozycją zarządzania, która jednocześnie zajmuje się szybkością nowego wydania i strukturą opłat.

Solana Company ogłosiła 21 sierpnia, że popiera SGP-0001, a jest przeciwna SGP-0003. Kluczowym punktem jest nie tyle potrzeba zmiany struktury ekonomicznej sieci, co czas i przewidywalność kosztów.

Rzeczywiste koszty dla użytkowników i zakres dostosowań dla aplikacji mają się ujawnić po wynikach głosowania, zastosowaniu bramki funkcji oraz aktualizacjach portfeli i SDK. Na obecnym etapie potwierdzono, że Solana pyta w procedurze on-chain, czy będzie w stanie utrzymać zaletę niskich opłat, jednocześnie bardziej odzwierciedlając koszty transakcji, które wymagają dużych zasobów.

Niniejsza treść ma charakter wyłącznie informacyjny i nie stanowi porady finansowej, inwestycyjnej, prawnej ani podatkowej. Wszelkie wydarzenia, nagrody, promocje online lub powiązane informacje, o których tu mowa, nie powinny być traktowane jako rekomendacja, zachęta ani zaproszenie do kupna, sprzedaży, wymiany lub innego rodzaju obrotu aktywami kryptograficznymi. Aktywa kryptograficzne charakteryzują się dużą zmiennością i mogą prowadzić do strat. Dostępność usług, produktów i powiązanych wydarzeń WEEX może się różnić w zależności od regionu. Użytkownik jest odpowiedzialny za upewnienie się, że jego udział jest zgodny z obowiązującymi lokalnymi przepisami i regulacjami.