Handel NFT przez inteligentne kontrakty: zlecenia i zatwierdzenia

Handel NFT obejmuje kilka kontraktów

Zacznij od kontraktu NFT. Dla typowego przedmiotu EVM połączenie łańcucha, adresu kontraktu i identyfikatora tokena odróżnia aktywo. Obraz i nazwa kolekcji są użytecznymi opisami, ale nie zastępują identyfikatorów. Dwa kontrakty mogą wyświetlać niemal identyczną grafikę, zapisując różne tokeny.

Protokół platformy pełni inną rolę. Sprawdza obsługiwane warunki zlecenia i koordynuje określone transfery przy ważnej realizacji. Seaport jest ważnym przykładem EVM; jego model zleceń oddziela oferowane aktywa od wymaganego świadczenia. Struktura może reprezentować więcej niż prostą wymianę jednego NFT za jedną płatność.

Kontrakt tokena płatniczego dodaje kolejną granicę przy użyciu aktywa ERC-20, takiego jak WETH. Natywne saldo ETH portfela i saldo WETH są osobne. Wymagane aktywo płatnicze musi pasować do zlecenia, a odpowiednie uprawnienie transferu musi być ważne w potrzebnym momencie.

Dodatkowe składniki mogą egzekwować ograniczenia transferu, zarobki twórców lub inne obsługiwane warunki. Ich obecność należy rozumieć na podstawie rzeczywistej ścieżki, nie znajomej nazwy kolekcji. Ogólny schemat kupującego, sprzedawcy i platformy może ukrywać kilka istotnych kontroli.

Przegląd Seaport OpenSea dostarcza podstawowego słownictwa oferty i świadczenia. Używaj go do identyfikowania aktywów i odbiorców zlecenia EVM, weryfikując aktualne szczegóły implementacji przez konkretny obsługiwany proces.

Standardy tokenów zmieniają znaczenie ilości

Identyfikator tokena ERC-721 zwykle wskazuje odrębne NFT z jednym obecnym właścicielem według modelu własności standardu. Instrukcja handlu powinna wskazywać zamierzony token, nie tylko kolekcję. Własność tokena 17 nie ustala własności tokena 18.

ERC-1155 obsługuje wiele typów tokenów w jednym kontrakcie i ilości dla każdego identyfikatora. Zlecenie na jedną jednostkę identyfikatora może więc różnić się od zlecenia na wszystkie jednostki portfela. Ekran oferty sprzedaży musi zachowywać wybraną ilość obok identyfikatora tokena.

Dokumentacja ERC-721 i ERC-1155 Ethereum opisuje różne interfejsy. Pomaga wyjaśnić niewystarczalność ogólnego licznika salda NFT dla przeglądu transakcji.

Rozważ fikcyjny portfel z pięcioma jednostkami jednego identyfikatora ERC-1155. Proponowana sprzedaż dwóch powinna pozostawić trzy przy wykonaniu zgodnym z zamiarem i braku innych istotnych zmian. Raport oznaczający cały identyfikator jako sprzedany usunąłby pozostałe zasoby.

Standard wpływa też na obsługiwane zatwierdzenia i zachowanie odbiorcy. Transfer może zawieść przez niezgodne miejsce docelowe lub warunki wywołania nawet przy poprawnie wyglądającej nazwie i ilości. Oceniaj rzeczywiste aktywo i ścieżkę zamiast zakładać jedną funkcję transferu każdego NFT.

Zatwierdzenie jest uprawnieniem, nie zakupem

Zatwierdzenie upoważnia operatora do działania w określonym zakresie. Nie jest tym samym co podpisanie ceny zakupu, wystawienie oferty sprzedaży lub potwierdzenie sprzedaży. Rozdzielenie pojęć wyjaśnia możliwość żądania przez portfel więcej niż jednej autoryzacji w procesie.

Dla ERC-721 uprawnienia mogą obejmować zatwierdzenie konkretnego tokena lub operatora dla tokenów właściciela w tym kontrakcie. ERC-1155 używa zatwierdzenia operatora według swojego standardowego interfejsu. Limity tokenów płatniczych mają własne znaczenie kwoty i podmiotu uprawnionego do wydawania. Dokładne uprawnienie należy sprawdzić przed nadaniem.

Zatwierdzenia w handlu NFT przez inteligentne kontrakty trzeba więc przeglądać według kontraktu, operatora i zakresu. „Zatwierdź platformę” jest wygodną etykietą, ale istotne pytanie dotyczy adresu, zdolności i objętych aktywów. Znajome logo nie odpowiada na to pytanie.

Istniejące zatwierdzenie może pozostać po zakończeniu konkretnej transakcji. Usunięcie oferty sprzedaży nie musi cofać uprawnienia tokena, a cofnięcie uprawnienia nie usuwa historycznego zapisu oferty. To powiązane kontrole o różnych skutkach.

Praktyczny przegląd jest proporcjonalny do działania. Zrozum potrzebne uprawnienie zamierzonej ścieżki, zweryfikuj kontekst żądania i zachowuj dane wystarczające do późniejszego sprawdzenia lub cofnięcia obsługiwanymi sposobami. Żadna strategia handlu nie potrzebuje klucza prywatnego w notatce badawczej do wyjaśnienia tych granic.

Podpisane zlecenie opisuje warunkową wymianę

Podpisane zlecenie zapisuje warunki, które kontrahent może być w stanie zrealizować przy dalszej ważności zlecenia. Znaczenie może obejmować identyfikatory aktywów, kwoty, odbiorców, czasy ważności i kryteria. Nie jest to tylko wiadomość o upodobaniu podpisującego do obecnej ceny.

Przy sprzedaży badaj, co opuszcza sprzedawcę i co sprzedawca lub inni wskazani odbiorcy muszą otrzymać. Przy ofercie kupna badaj aktywa płacone przez oferenta i kryteria NFT spełniające wymianę. Kierunek się zmienia, ale potrzeba odczytania obu stron pozostaje.

Podpisane zlecenia handlu NFT mogą mieć konsekwencje po zamknięciu interfejsu podpisu. Kontrahent może działać później przy nadal spełnionych wymaganiach. Dlatego czas trwania, pokrycie, własność i stan anulowania należą do bieżącego widoku konta.

Identyfikatory zleceń i hashe transakcji odpowiadają na inne pytania. Zlecenie wskazuje warunkowe zasady. Transakcja realizacji wskazuje konkretną próbę ich wykonania. Kilku aktualizacji stanu jednego zlecenia nie należy liczyć jako kilku niezależnych transakcji handlowych.

Nie utożsamiaj prośby o podpis z nieszkodliwym logowaniem tylko przez brak natychmiastowej opłaty gazu. Ważne jest upoważnienie podpisanej wiadomości. Dobrze zaprojektowany interfejs powinien ujawniać domenę, warunki i zamierzony skutek w formie zrozumiałej dla podpisującego.

Czytaj świadczenie jako pełną mapę płatności

Sprzedaż może kierować części płatności brutto do różnych odbiorców. Kwota dostarczona przez kupującego nie zawsze jest kwotą zachowaną przez sprzedawcę. Różnica ma znaczenie dla przeglądu transakcji i ewidencji zysku.

Wyobraź sobie wymyślony zakup o pełnym świadczeniu 1,20 ETH. Określona mapa płatności wysyła 1,128 do sprzedawcy, 0,024 do jednego odbiorcy opłaty i 0,048 do odbiorcy będącego twórcą. Trzy kwoty sumują się do 1,20. Załóż osobny wydatek kupującego 0,007 ETH na wykonanie sieciowe.

Pełny wydatek kupującego w ćwiczeniu wynosi 1,207 ETH. Ponowne dodanie 0,024 i 0,048 ponad 1,20 podwaja kwoty już zawarte w świadczeniu. Wpływ brutto sprzedawcy z mapy płatności wynosi 1,128, nie 1,20.

Te fikcyjne procenty nie są bieżącymi opłatami OpenSea. Celem jest pokazanie konieczności wskazania płatnika, odbiorcy i podstawy opłaty w rzeczywistym zestawieniu transakcji. Napis „opłaty zawarte” należy uzgodnić z transferami zamiast interpretować jako brak opłat dla jakiegokolwiek odbiorcy.

Wymagane i opcjonalne płatności na rzecz twórców też wymagają osobnego traktowania. Dokumentacja realizacji ofert sprzedaży OpenSea odróżnia opcjonalne uwzględnienie od już wymaganych opłat twórców. Nie należy zakładać usunięcia wymaganej kwoty świadczenia przez opcjonalne ustawienie.

Jasna mapa płatności umożliwia przegląd przed podpisem i odtworzenie ewidencji po nim. Ujawnia też nieoczekiwanych odbiorców niewidocznych w głównej cenie zakupu.

Handel NFT ma granice atomowości

Atomowe przejście stanu oznacza, że istotne zmiany wewnątrz transakcji zachodzą według reguł wykonania lub zostają cofnięte po niepowodzeniu transakcji. Może to chronić relację płatności i transferu NFT wewnątrz poprawnie zaprojektowanej wymiany.

Przy ocenie handlu NFT z atomowym rozliczeniem wskaż dokładną transakcję, której skutki muszą wspólnie się powieść. Granicą są rzeczywista transakcja i zachowanie kontraktu. Nie obejmuje automatycznie osobnego wcześniejszego zatwierdzenia, przyszłej odsprzedaży lub transferu w innej sieci. Strategia kilku transakcji może więc zakończyć się stanem pośrednim nawet przy przestrzeganiu reguł każdej pojedynczej transakcji.

Na przykład zatwierdzenie może się powieść, a zakup potem zawieść przez sprzedaż przedmiotu gdzie indziej. Zatwierdzenie może pozostać mimo braku nabycia NFT. Traktowanie całej ścieżki użytkownika jako jednego atomowego działania daje błędną interpretację konta.

Zachowanie partii też wymaga badania. Niektóre obsługiwane ścieżki mogą przetwarzać dostępne zlecenia, pozostawiając niedostępne niewykonane. Udanej transakcji zewnętrznej nie należy automatycznie odczytywać jako potwierdzenia zakupu każdego pierwotnie wybranego przedmiotu. Uzgadniaj rzeczywiste transfery i ilości.

Kluczowe pytanie dotyczy skutków wymaganych razem przez wysłane wywołanie i dopuszczonych do niezależnego powodzenia. Przycisk z napisem sweep, batch lub execute nie ustanawia tej gwarancji. Ustanawia ją obsługiwana semantyka transakcji.

Udany zakup nie zapewnia odsprzedaży

Wróć do hipotetycznego nabycia za 1,207 ETH. Załóż osobnego potencjalnego kupującego obecnie oferującego 1,30 za to samo kwalifikujące się NFT. Przy wymyślonym łącznym potrąceniu sprzedawcy 6% i kosztach wyjścia 0,005 ETH wpływy netto odsprzedaży wyniosłyby 1,217 ETH.

Jeśli obie transakcje rzeczywiście zakończą się na tych warunkach, modelowany wynik jest zyskiem 0,010 ETH. Atomowe rozliczenie zakupu może zapewnić własną wymaganą wymianę, ale nie zachowuje oferty późniejszego kupującego podczas uzyskiwania własności i przygotowania odsprzedaży.

Jeśli dostępna odsprzedaż spadnie do 1,05 przed drugim działaniem, te same hipotetyczne koszty pozostawiają wpływy netto 0,982 ETH. Wyjście tam dałoby stratę 0,225 ETH względem nabycia 1,207. Pierwszy zakup mógł być technicznie poprawny przy niekorzystnej całej sekwencji.

To ryzyko sekwencyjnych części. Powstaje, gdy strategia zależy od przyszłego działania poza tą samą zweryfikowaną granicą atomowego wykonania. Szybsze oprogramowanie może zmniejszać część czasu bez zamiany osobnych działań we wspólną gwarancję.

Poprawne wyjaśnienie arbitrażu musi więc wskazywać rzeczywiście obsługiwaną strukturę wykonania. Jeśli ścieżka nie może wspólnie uzależnić potrzebnych części, pośrednie zasoby i możliwa strata wymagają jawnej analizy. Nazwanie składników inteligentnymi kontraktami nie usuwa ekspozycji.

Symulacja opisuje konkretny stan

Symulacja transakcji może pomagać wskazywać oczekiwane transfery i błędy wykonania przy użytym stanie. Jest cennym dowodem, zwłaszcza przy kilku kontraktach lub odbiorcach proponowanego działania. Nadal pozostaje obserwacją konkretnego zbioru warunków.

Własność, salda, limity wydawania i ważność zlecenia mogą zmieniać się przed włączeniem. Ofertę z udaną symulacją może najpierw zrealizować ktoś inny. Operacja wrażliwa na opłaty może trafić do innego środowiska kosztów sieci przy wysłaniu. Wynik symulacji powinien zachowywać czas i założenia.

Używaj symulacji do porównywania proponowanych skutków z autoryzacją użytkownika. Czy zamierzony token trafia do zamierzonego odbiorcy? Czy oczekiwana płatność wychodzi we właściwym aktywie? Czy występują inne zatwierdzenia lub transfery spoza decyzji badawczej?

Nie interpretuj udanej symulacji jako dowodu autentyczności, wartości lub prawdopodobnego wzrostu ceny aktywa. To inne pytania. Podrobiona kolekcja może zawierać technicznie wykonalną transakcję, a ekonomicznie złe zlecenie może doskonale się symulować.

Po zmianie ścieżki po symulacji powtórz odpowiedni przegląd. Użycie korzystnego wyniku innych danych wywołania lub innego odbiorcy testowałoby niewłaściwą instrukcję. Użytecznym zapisem jest powiązanie zatwierdzonego zamiaru, przejrzanej transakcji i rzeczywistego wykonania.

Niepowodzenie nadal może kosztować

Cofnięte wykonanie może pozostawić zamierzone transfery aktywów niewykonane przy zużyciu zasobów sieci. Dokumentacja gazu Ethereum wyjaśnia możliwość zużycia gazu przez nieudane wykonanie. Nieudane próby należą więc do ewidencji handlu nawet bez nabycia NFT.

Odróżniaj żądanie odrzucone przed włączeniem transakcji od transakcji wykonanej i cofniętej. To różne stany o potencjalnie różnych kosztach. Ogólne oznaczenie niepowodzenia może ukrywać różnicę i czynić łączne szacunki wydatków niewiarygodnymi.

W wymyślonym przykładzie trzy nieudane próby po 0,004 ETH dodają 0,012 ETH wydatków strategii. Jeśli późniejsza udana transakcja zarabia 0,010 po własnych kosztach, sekwencja nadal traci 0,002, gdy wcześniejsze próby należą do tego samego ocenianego działania.

Ponowienie powinno zaczynać się od dowodów dotyczących pierwotnej próby. Przekroczenie czasu usługi nie dowodzi, że sieć nigdy nie otrzymała transakcji. Zachowuj identyfikator i sprawdzaj stan przed tworzeniem nowego działania ekonomicznego.

Poradnik bota Stream API OpenSea wyjaśnia współdziałanie dostarczania zdarzeń i odtwarzania stanu konta. Wiadomość strumienia może być użytecznym dowodem, lecz program nadal powinien uzgadniać rzeczywistą transakcję i skutki własności przed zamknięciem ewidencji.

Potwierdzenie i ostateczność to różne poziomy dowodów

Hash transakcji wskazuje próbę. Włączenie do bloku dowodzi przetworzenia transakcji w tym bloku. Wynik wykonania i wyemitowane skutki wskazują następnie rzeczywisty przebieg. Dalsze potwierdzenie lub ostateczność zmienia pewność trwałości obserwowanej historii łańcucha.

Właściwa polityka potwierdzania zależy od sieci i wykonywanej aktywności. Unikaj przypisywania uniwersalnej liczby sekund lub bloków każdemu procesowi NFT. Szybko aktualizowany ekran sam nie definiuje standardu ostateczności aplikacji.

Dokumentacja transakcji Ethereum opisuje cykl od podpisanej transakcji do przetwarzania sieci. Narzędzie konta powinno uwidaczniać odpowiedni etap zamiast jednej etykiety sukcesu w każdym punkcie cyklu.

Dalsze działanie powinno określać wymagane dowody. Powiadomienie badawcze może rozsądnie pojawiać się przed ostatecznością transferu, pod warunkiem oznaczenia. Raport finansowy deklarujący rozliczoną własność wymaga silniejszej i jawnie określonej podstawy.

Zachowuj możliwość korekt lokalnych zapisów. Jeśli wcześniej obserwowany skutek nie należy już do przyjętej historii łańcucha, aplikacja nie powinna po cichu zachowywać go jako niekwestionowanej sprzedaży. Odtwarzanie stanu wymaga więcej niż jednokrotnego zebrania powiadomień zdarzeń.

Solana wymaga własnego modelu programów

Powyższe przykłady EVM nie opisują każdej sieci obsługiwanej przez OpenSea. Solana używa innego modelu kont i programów, a reprezentacje NFT mogą różnić się wewnątrz tego ekosystemu. Integracja musi weryfikować rzeczywisty standard aktywa i obsługiwaną ścieżkę.

Identyfikator mintu Solana, konto tokena i właściciel pełnią różne role. Skompresowane NFT wymagają dodatkowych kwestii reprezentacji zamiast wciskania w prosty model kontraktu i identyfikatora tokena EVM. Znajoma karta platformy nie usuwa tych różnic.

Obecna obsługa OpenSea też oddziela widoczne oferty Solana od możliwych do kupienia obsługiwanymi ścieżkami. Konstruktor transakcji powinien weryfikować kwalifikację zamiast traktować każdą wyświetlaną ofertę sprzedaży jako wykonalną. To pytanie o obsługę produktu obok stanu łańcucha.

Poradnik zarabiania na handlu NFT Solana łączy różnice z kosztami i założeniami odsprzedaży. Wspólne zasady finansowe nadal obowiązują, ale uprawnienia, finansowanie i walidacja transakcji powinny podążać za odpowiednią siecią.

Raportowanie między sieciami może używać wspólnego formatu ewidencji przy zachowaniu dowodów właściwych dla sieci. Wspólne pola wyjaśniają wynik ekonomiczny; pola łańcucha wyjaśniają wiarygodność zapisu. Usunięcie tych drugich dla prostoty wizualnej osłabia historię konta.

Oceniaj zakończoną wymianę jako zbiór skutków

Po transakcji wskaż dokładne otrzymane lub wydane aktywo, kwoty tokenów płatniczych, odbiorców, koszt sieci i pozostałe uprawnienia lub aktywne zlecenia. Porównaj skutki z zatwierdzonym zamiarem. Potwierdzenie transakcji bez porównania może być szczegółowe technicznie, a nieprzydatne finansowo.

Dla hipotetycznego zakupu 1,20 ETH zapis powinien wyjaśniać składniki płatności 1,128, 0,024 i 0,048 oraz osobny koszt sieci 0,007. Nie powinien liczyć pełnej sumy brutto i tych samych transferów odbiorców jako osobnych wydatków.

Dla aktywa z ilością zweryfikuj pozostałe saldo. Dla operacji wielu przedmiotów zapisz każdy rzeczywisty transfer. Dla nieudanego działania zachowuj pozostały koszt i nierozstrzygnięte uprawnienia mimo braku oczekiwanego NFT.

Samouczek handlu OpenSea umieszcza weryfikację w pełnym procesie użytkownika. Zrozumienie granic kontraktów czyni każdy krok bardziej świadomym: uprawnienie, podpisane warunki, próba wykonania i końcowe skutki konta są powiązane, lecz każde wymaga własnych dowodów.

Użyteczne zrozumienie handlu NFT przez inteligentne kontrakty kończy się zdolnością wyjaśnienia tego łańcucha dowodów prostym językiem. Kod może egzekwować otrzymane warunki. Użytkownik nadal musi wiedzieć, że są zamierzone i że zakończony wynik finansowy im odpowiada.