Lisk Research – Krótki przegląd LIP 12

Dzisiaj opiszemy LIP 12. W propozycji tej znajduje się zalecenie usunięcia zbędnych właściwości obiektów transakcyjnych w aktualnym protokole.

LIP 12 został przygotowany przez Andreasa Kendziorrę z udziałem Olivera Beddowsa. Deweloperzy zauważyli nadmiar właściwości obiektów transakcyjnych, które zwiększają wielkość transakcji i złożoność protokołu bez żadnych korzyści, dlatego sugerują ich usunięcie.

Andreas wyjaśnił, że w aktualnym protokole możliwe jest stosowanie par właściwość-wartość w obiektach transakcyjnych, które nie są ani konieczne, ani używane. Wspomniane pary właściwości występują zarówno w obiektach JSON wykorzystywanych do komunikacji transakcji, jak i w komunikatach wejściowych do sygnatury transakcji i generowania identyfikatora transakcji. W rezultacie pary zwiększają ilość danych przesyłanych pomiędzy węzłami, spowalniając przetwarzanie transakcji. Chociaż, jak wyjaśniają programiści, nawet jeśli wpływ może być minimalny, może pojawić się zamieszanie podczas czytania protokołu i jego implementacja staje się niepotrzebnie duża. Z tego powodu proponują oni usunięcie wszystkich par właściwość-wartość w nadmiarze.

Nie wszystkie właściwości są redundantne w ten sam sposób. Na przykład, kwota i właściwości “recipientId” są niezbędne tylko dla transakcji przelewu salda, ale nie są konieczne dla żadnego innego rodzaju transakcji. Aby wymienić tylko inny przykład, właściwość “requesterPublicKey” jest odziedziczoną właściwością, która nie jest już wymagana dla żadnego rodzaju transakcji.

Właściwości te są dozwolone dla transakcji JSON obiektów podczas przesyłania: kwota, aktywa, opłata, id (opcjonalnie), recipientId, recipientPublicKey (opcjonalnie), requesterPublicKey (opcjonalnie), senderId (opcjonalnie), senderPublicKey, podpis, podpisy (opcjonalnie), podpis (opcjonalnie), znacznik czasu, typ.

Właściwości zidentyfikowane jako zbędne to: kwota, opłata, identyfikator, recipientId, recipientPublicKey, requesterPublicKey i senderId. Pozostałe właściwości są fundamentalne, więc programiści sugerują, aby ich nie usuwać.

Zbędne właściwości są bardziej szczegółowo analizowane przez Andreasa:

1. Kwota i “recipientId”: te dwie właściwości są wymagane dla każdego obiektu transakcji, ale są one istotne tylko dla transakcji transferu salda. Z tego powodu deweloperzy proponują przeniesienie ich z obiektów transakcyjnych do własności aktywów transakcji przeniesienia salda;
2. Opłata: opłata za transakcję może być zawsze odliczona od rodzaju transakcji ze względu na system opłat stałych.
3. Id: zawsze możliwe jest określenie id transakcji z innych właściwości. Ponadto nie jest wygodne podawanie id przy wysyłaniu transakcji, ponieważ węzeł otrzymujący transakcję musi zweryfikować wszystkie właściwości i sprawdzić id, konieczne jest obliczenie id. Tak więc programiści proponują usunięcie właściwości id z obiektów transakcji JSON;
4. RecipientPublicKey: Odbiorca przelewu salda powinien być zawsze określony przez jego adres, a wszystkie inne rodzaje transakcji nie mają odbiorcy. Deweloperzy sugerują więc usunięcie tej właściwości, ponieważ nie jest ona potrzebna;
5. RequesterPublicKey: początkowo właściwość ta została zaprojektowana tak, aby mogła być wykorzystywana do zlecania transakcji złożonych z wielu podpisów przez osoby niebędące posiadaczami kont. Jednak funkcja ta nie jest obecnie dostępna i dlatego programiści sugerują jej wyeliminowanie;
6. SenderId: nie ma potrzeby korzystania z tej właściwości, ponieważ senderPublicKey jest wymaganą właściwością dla każdego obiektu transakcyjnego i zawsze można obliczyć adres/id z klucza publicznego.

Jeśli chcesz dowiedzieć się więcej na ten temat, zapoznaj się z pełnym opisem każdego LIP na stronie GitHub.

———————————————-
Lisk Magazine jest projektem wspieranym przez Lisk Italian Group i EliteX.
Wspieraj naszą pracę, głosuj na Lisk Magazine.