Stan kodu to cotygodniowe krótkie podsumowanie technicznych aktualizacji ekosystemu.

Jest to w zasadzie skondensowana wersja tego, co można znaleźć na forum Dfinity, w Global R&D oraz na portalach społecznościowych. Skupia się na tematach technicznych. Spodziewajcie się cotygodniowych publikacji!

Temat 1: Wynagrodzenie dostawcy węzłów

Liczba i różnorodność dostawców węzłów ma fundamentalne znaczenie dla decentralizacji komputera internetowego. Model wynagradzania określał, ile nagród otrzymują węzły ICP za swój wkład w sieć.

Co się dzieje? Trwają prace nad nowym modelem wynagrodzeń, który wkrótce trafi pod głosowanie (jako wniosek w NNS).

Dlaczego ten nowy model jest potrzebny?

• Początkowy model wynagrodzenia oparty jest na sprzęcie Gen 1 , ale sprzęt Gen 2 jest droższy i wymaga większych nagród dla dostawców węzłów.
• Pierwotny model wynagrodzeń nie przewidywał silnych zachęt do decentralizacji.

• Nagrody bonusowe zostaną przyznane za pierwsze węzły nowego dostawcy węzłów ⇒ Celem jest zwiększenie liczby różnych dostawców węzłów i zwiększenie decentralizacji własności.
• Dodatkowe nagrody zostaną przyznane za węzły w nowych lokalizacjach (Ameryka Południowa, Afryka, Azja…). ⇒ Celem jest poprawa decentralizacji geograficznej.

1. Upewnienie się, że żaden kraj nie będzie w stanie ingerować w komputer internetowy — zostanie to osiągnięte poprzez przyciąganie węzłów w nowych regionach geograficznych, omówionych wcześniej, przy jednoczesnym ograniczeniu węzłów w regionach geograficznych/jurysdykcjach z już istniejącymi węzłami (Europa, USA).
2. Upewnij się, że każdy dostawca węzłów może współtworzyć tylko jeden węzeł na podsieć. Zostanie to osiągnięte poprzez zachęcanie dostawców węzłów do posiadania „zbyt wielu” węzłów (tj. więcej niż liczba podsieci) przy jednoczesnym zachęcaniu nowych dostawców węzłów do przyłączania się do sieci poprzez zwiększanie nagród za pierwsze węzły nowego dostawcy węzłów, jak wspomniano wcześniej .
3. Tylko jeden węzeł na centrum danych i podsieć, co będzie wymagać od nowych dostawców węzłów współpracy z właścicielami centrów danych, którzy nie hostują jeszcze żadnego węzła dla komputera internetowego.

1. Ten nowy model jest prezentowany i dyskutowany na forum DFINITY.
2. Wniosek zostanie poddany pod głosowanie przez NNS.
3. Jeśli zostanie zaakceptowany, ten nowy model zostanie wdrożony i będą pracować nad dalszymi ulepszeniami (zwłaszcza karami za nagrody, jeśli węzły nie wnoszą prawidłowego wkładu!)

Idąc dalej

Post na forum

Szczegóły dotyczące modelu nagrody

Informacje o sprzęcie węzła.

Temat 2: ICRC_2

Ogromny krok w kierunku większej liczby aplikacji DeFi na IC!

Jaki jest aktualny problem?

Jednym z powodów, dla których rozwój ekosystemu DeFi w Internecie był powolny, jest brak standardu tokena.

Chociaż standard tokenów ICRC-1 jest dostępny od kilku miesięcy, obecnie nie pozwala on na delegowanie transferów tokenów stronie trzeciej do działania w imieniu właściciela bez faktycznego przenoszenia tokenów.

W praktyce oznacza to, że dla dowolnej aplikacji (DEX, Gra, portal społecznościowy...), która chce wykorzystać Twoje środki, musisz przesłać środki do tej dApp (tj. do kanistra dApp).

Jest to problematyczne z kilku powodów:

1. Płatności cykliczne (subskrypcje) wymagają wielu transakcji.
2. Jeśli kupisz coś, czego cena jest nieznana lub się zmienia (jak na DEX), będziesz musiał wysłać wystarczającą ilość środków, aby mieć pewność, że pokryjesz zakup, a następnie upewnić się, że dApp ponownie prześle ci pozostałe środki…

ICRC_2 jest rozszerzeniem obecnego standardu, który wprowadza dwie metody:

• icrc2_approve: Możesz użyć tej metody, aby pozwolić komuś wydać twoje żetony do określonej kwoty. Możesz także ustawić limit czasu wygaśnięcia tego uprawnienia.
• icrc2_transfer_from: Jeśli ktoś ma pozwolenie na wydawanie twoich tokenów, może użyć tej metody, aby wydać tokeny w twoim imieniu, bez konieczności robienia czegokolwiek

1. W przypadku subskrypcji wystarczy, że zezwolisz aplikacji na korzystanie z określonej kwoty Twoich środków (musisz zaufać aplikacji!)
2. W przypadku zmiennej ceny zezwalasz na wystarczającą liczbę tokenów, aby mieć pewność, że będziesz mieć ich wystarczająco dużo, ale wtedy nie jest potrzebny zwrot pieniędzy, ponieważ aplikacja wyśle ​​żądanie przeniesienia bezpośrednio ze znaną ceną.

• Grupa robocza będzie głosować nad tym standardem.
• Jeśli grupa robocza zaakceptuje ten nowy standard, zostanie on poddany pod głosowanie przez NNS.
• Jeśli głosowanie zostanie zaakceptowane, wszystkie główne tokeny ICRC_1 zostaną zaktualizowane do tej nowej wersji (w tym sam ICP!)

I propozycja CRC_2

Temat 3: WebSockets w komputerze z Internetem

Jaki jest problem?
W tej chwili jedynym sposobem na interakcję z komputerem internetowym są tylko wywołania aktualizacji i zapytań. Wyobraź sobie, że przeglądasz witrynę hostowaną w układzie scalonym, która wyświetla dane w czasie rzeczywistym, takie jak tabela liderów gry wieloosobowej, która ciągle się zmienia.

Obecnie najlepszym sposobem informowania przeglądarki o tych zmianach jest ciągłe wysyłanie zapytań o aktualizacje, co jest znane jako odpytywanie. Oznacza to, że Twoja przeglądarka wysyła zapytania do kanistra w regularnych odstępach czasu, aby sprawdzić dostępność aktualizacji, nawet jeśli nie ma żadnych zmian. Ta strategia powoduje kilka problemów:

• Zwiększa obciążenie kanistra wieloma (niepotrzebnymi) wywołaniami zapytań.
• Twoja strona internetowa nie jest aktualizowana „bezpośrednio” i w zależności od opóźnienia między wywołaniami zapytań może działać dość wolno.

WebSockets to protokół komunikacji, który pozwala „serwerowi” przesyłać dane do klienta (w celu ich aktualizacji) bez konieczności ciągłego odpytywania. Jest idealny do aplikacji do przesyłania wiadomości, gier w czasie rzeczywistym i platform handlowych….
Dlatego w społeczności wielokrotnie pojawiała się potrzeba posiadania WebSocketów w kanistrach.

Z przyjemnością ogłaszam, że WebSocket jest w fazie prac w DFINITY, a podczas globalnych prac badawczo-rozwojowych zaprezentowano wersję demonstracyjną!

Implementacja opiera się na serwerze bramy, brama implementuje połączenie WebSocket z klientem i przekazuje komunikaty podpisane przez podsieć (tzn. certyfikowane dane), aby upewnić się, że brama nie może oszukać zawartości aktualizacji.

Czego spodziewać się w najbliższych tygodniach?
Kod źródłowy będzie dostępny około połowy marca po sprawdzeniu bezpieczeństwa.

Życzę miłego i produktywnego tygodnia! ‍