Dziś wieczorem uważnie przeczytałem oficjalną dokumentację dotyczącą $OPG x402 po aktualizacji i odkryłem, że wielu ludzi błędnie uważa, iż wstępne doładowanie konta rozwiązuje raz na zawsze problem asynchronicznych rozliczeń, a także pokrywa złe należności. W rzeczywistości ten mechanizm to tylko płytki bufor i w ogóle nie blokuje luki umożliwiającej złośliwe wyprowadzanie środków.
Oficjalnie przedstawiony plan kontroli ryzyka jest bardzo prosty: użytkownik z góry wpłaca #opg na dedykowane konto przedpłat, a późniejsze potrącenia za wnioskowanie pobierane są z tej puli, zamiast bezpośrednio zużywać tokeny z głównego portfela. Sporo osób uznało na tej podstawie, że nie ma problemu z przenoszeniem tokenów przed rozliczeniem użytkownika i uchylaniem się od zapłaty. Ale po dogłębnym prześledzeniu procesu widać wyraźnie słabości w warstwie bazowej.
Cały system przedpłat nie wymusza minimalnego salda. W scenariuszach komercyjnych na skalę hurtową luka będzie się nieustannie powiększać. Deweloper może w praktyce wpłacić tylko tyle tokenów, ile potrzeba do pojedynczego wnioskowania, wysłać serię żądań aż do wyczerpania środków, po czym natychmiast wypłacić całe saldo z konta przedpłat. Kiedy węzły składają dowód do rozliczenia na łańcuchu, pula jest już wyzerowana — potrącenie kończy się bezskutecznie. Moc obliczeniowa GPU i energia elektryczna węzła zostają realnie zużyte, a na końcu nie da się odzyskać nawet jednego grosza @OpenGradient .
Najbardziej krytyczną usterką jest brak logiki natychmiastowego zamrażania środków. Wiodące usługi chmurowe, inicjując wnioskowanie, blokują równocześnie odpowiednią kwotę, a zwalniają ją dopiero po zakończeniu rozliczenia — eliminując problem u źródła. Natomiast konto przedpłat OPG to wyłącznie statyczna pula salda: złożenie żądania nie powoduje blokady na łańcuchu. Wynik wnioskowania wraca w sekundy, a dowód rozliczenia pojawia się dopiero po kilku blokach na łańcuchu. Ta długa „okno czasowe” wystarcza, by użytkownik wyczyścił wszystkie tokeny przedpłat.
Jeszcze bardziej absurdalne jest to, że nie ma żadnej kary za niewywiązanie się. Zwróciłem uwagę, że protokół nie ma żadnych wymagań ani ograniczeń w zakresie kontroli ryzyka „y”. Nawet wielokrotne złośliwe wyprowadzanie środków i uchylanie się od wypłat za moc obliczeniową nie będzie ograniczać uprawnień użytkownika ani nie spowoduje zamrożenia adresów — koszt wyrządzania szkód jest praktycznie zerowy. W testnecie pojedyncze interakcje nie pokazują problemu, ale gdy wejdzie się w integrację z usługami w środowisku przedsiębiorstw i uruchomi wnioskowania hurtowo, masowe złe należności będą stale podgryzać zyski węzłów.
Oficjalnie promują jedynie usprawnienie doświadczenia asynchronicznych rozliczeń dzięki kontu przedpłat i celowo omijają słabość w kontroli ryzyka: brak zamrożenia środków i brak kar za naruszenie. Moim zdaniem wygląda to tak, jakby załatano lukę związaną z wymianą środków, ale w praktyce to tylko leczenie objawowe. Węzły i tak ponoszą nieodwracalne straty wynikające z złośliwych „ucieczek” użytkowników i bardzo trudno będzie utrzymać długoterminowo stabilne dostarczanie mocy obliczeniowej. Zgadzasz się?
Oficjalnie przedstawiony plan kontroli ryzyka jest bardzo prosty: użytkownik z góry wpłaca #opg na dedykowane konto przedpłat, a późniejsze potrącenia za wnioskowanie pobierane są z tej puli, zamiast bezpośrednio zużywać tokeny z głównego portfela. Sporo osób uznało na tej podstawie, że nie ma problemu z przenoszeniem tokenów przed rozliczeniem użytkownika i uchylaniem się od zapłaty. Ale po dogłębnym prześledzeniu procesu widać wyraźnie słabości w warstwie bazowej.
Cały system przedpłat nie wymusza minimalnego salda. W scenariuszach komercyjnych na skalę hurtową luka będzie się nieustannie powiększać. Deweloper może w praktyce wpłacić tylko tyle tokenów, ile potrzeba do pojedynczego wnioskowania, wysłać serię żądań aż do wyczerpania środków, po czym natychmiast wypłacić całe saldo z konta przedpłat. Kiedy węzły składają dowód do rozliczenia na łańcuchu, pula jest już wyzerowana — potrącenie kończy się bezskutecznie. Moc obliczeniowa GPU i energia elektryczna węzła zostają realnie zużyte, a na końcu nie da się odzyskać nawet jednego grosza @OpenGradient .
Najbardziej krytyczną usterką jest brak logiki natychmiastowego zamrażania środków. Wiodące usługi chmurowe, inicjując wnioskowanie, blokują równocześnie odpowiednią kwotę, a zwalniają ją dopiero po zakończeniu rozliczenia — eliminując problem u źródła. Natomiast konto przedpłat OPG to wyłącznie statyczna pula salda: złożenie żądania nie powoduje blokady na łańcuchu. Wynik wnioskowania wraca w sekundy, a dowód rozliczenia pojawia się dopiero po kilku blokach na łańcuchu. Ta długa „okno czasowe” wystarcza, by użytkownik wyczyścił wszystkie tokeny przedpłat.
Jeszcze bardziej absurdalne jest to, że nie ma żadnej kary za niewywiązanie się. Zwróciłem uwagę, że protokół nie ma żadnych wymagań ani ograniczeń w zakresie kontroli ryzyka „y”. Nawet wielokrotne złośliwe wyprowadzanie środków i uchylanie się od wypłat za moc obliczeniową nie będzie ograniczać uprawnień użytkownika ani nie spowoduje zamrożenia adresów — koszt wyrządzania szkód jest praktycznie zerowy. W testnecie pojedyncze interakcje nie pokazują problemu, ale gdy wejdzie się w integrację z usługami w środowisku przedsiębiorstw i uruchomi wnioskowania hurtowo, masowe złe należności będą stale podgryzać zyski węzłów.
Oficjalnie promują jedynie usprawnienie doświadczenia asynchronicznych rozliczeń dzięki kontu przedpłat i celowo omijają słabość w kontroli ryzyka: brak zamrożenia środków i brak kar za naruszenie. Moim zdaniem wygląda to tak, jakby załatano lukę związaną z wymianą środków, ale w praktyce to tylko leczenie objawowe. Węzły i tak ponoszą nieodwracalne straty wynikające z złośliwych „ucieczek” użytkowników i bardzo trudno będzie utrzymać długoterminowo stabilne dostarczanie mocy obliczeniowej. Zgadzasz się?