# Az észlelt tranzakciótól az egyeztetett rendelésig: megerősítések és reorganizációk | SwissOctet Insights https://swissoctet.com/hu/insights/confirmations-reorgs-order-reconciliation/ SwissOctet / Betekintések / Kriptofizetések Kriptofizetések Haladó · 4 perc olvasás Az észlelt tranzakciótól az egyeztetett rendelésig: megerősítések és reorganizációk A fizetési állapotokat ellenőrzött láncbizonyítékok, kifejezett elfogadási szabályok és egyértelmű rendeléshozzárendelés köré tervezze, ne pedig a böngésző azon állítása köré, hogy pénzeszközöket küldtek. Szerző: SwissOctet Editorial Útmutató mentése Hivatkozás másolása EZEN AZ OLDALON 01 Válassza külön a lánceseményt a rendelési eseménytől 02 Használjon láncspecifikus megbízhatósági szabályokat 03 Ellenőrizze a tényleges átutalási adatcsomagot 04 Tegye egyértelművé a rendeléshozzárendelést 05 Határozzon meg olyan állapotokat, amelyek elviselik a késői és változó bizonyítékokat 06 Tegye biztonságossá és megfigyelhetővé az újrapróbálkozásokat 07 Tudja, mire van még szüksége egy függőben lévő rendelésnek Az Ön gyakorlati ellenőrzőlistája Források és további olvasmányok Vissza a könyvtárhoz A KÖZVETLEN VÁLASZ A tranzakcióészlelés, a láncmegerősítés, a rendeléshozzárendelés és a szolgáltatásnyújtás külön lépések. Ellenőrizze a helyes láncot, eszközt, címzettet és összeget; alkalmazzon dokumentált elfogadási szabályzatot; és tegye idempotenssé az egyeztetést. Egy tranzakciós hivatkozás, képernyőkép vagy böngészőgomb önmagában nem tudja megállapítani, hogy egy adott rendelést kifizettek. 01 Válassza külön a lánceseményt a rendelési eseménytől Az, hogy egy tárca azt jelenti, hogy egy átutalást elküldtek, a saját műveletére vonatkozó bizonyíték, nem teljes fizetési döntés. A fogadó háttérrendszernek meg kell figyelnie a szándékolt hálózatot, ellenőriznie kell a tényleges átutalást, és hozzá kell rendelnie egy rendeléshez. Csak ezután alkalmazhatja a rendelés az elfogadási szabályzatát. Az infrastruktúra nyújtása a fizetés elfogadása utáni további üzemeltetési lépés. Tartsa ezeket az átmeneteket kifejezetten mind a kódban, mind az ügyfélnek szóló szövegben. Egy képernyő mutathat várakozást, észlelést vagy megerősítést anélkül, hogy a rendelést kifizetettnek nevezné. Ne engedje, hogy a böngésző adja meg az elfogadott összeget, vagy felülírja a hiteles állapotot. Tárolja a szerver által létrehozott ajánlatot és annak utasításait, hogy a későbbi egyeztetés az eredeti rendeléshez viszonyítva értékelhető legyen, ne egy változó bevásárlókosárhoz. 02 Használjon láncspecifikus megbízhatósági szabályokat A különböző hálózatok eltérően írják le a tranzakció megbízhatóságát. A Bitcoin fejlesztői útmutatója elmagyarázza, hogyan választják ki a csomópontok a legtöbb felhalmozott munkabizonyítékkal rendelkező láncot, és hogyan fordulhatnak elő versengő blokkok. Egy nemrég látott tranzakcióhoz ezért szabályzatra van szükség a megerősítési mélységre és a lehetséges láncváltozásokra. Nincs egyetlen, minden eszközhöz és kereskedelmi kockázathoz illő megerősítési szám. A Ethereum proof-of-stake dokumentációja az ellenőrzési pont véglegességét magyarázza, míg a Solana a feldolgozott, megerősített és véglegesített kötelezettségvállalási állapotokat dokumentálja. Ne fordítsa le ezeket a kifejezéseket könnyedén egyetlen általános blokkszámra. Rögzítse a hálózatspecifikus szabályt, az információforrást és a bizonytalanság alatti viselkedést. Az üzemeltetőnek a fizetési és szállítási kockázathoz kell meghatároznia az elfogadási küszöbértékeket, nem pedig egy nem kapcsolódó fizetési folyamatból másolnia egy számot. 03 Ellenőrizze a tényleges átutalási adatcsomagot A helyes láncon azonosítsa a címzettet, az eszközt és az összeget. A tokenfizetésekhez a szándékolt tokenazonosság szükséges, nem csupán egy sikeres tranzakció egy címre. A lánc modelljének megfelelően ellenőrizze a releváns végrehajtási sikert és az átutalási bizonyítékot. Az egész számú összegeket az eszköz megfelelő pontosságával dolgozza fel, ahelyett hogy a böngésző által megadott formázott tizedes értékben bízna. A fizetési utasításnak az eredeti útvonalához kötve kell maradnia. Egy másik hálózaton végzett átutalás, egy ugyanolyan szimbólumú más token vagy egy nem kapcsolódó tranzakciós hivatkozás nem elégítheti ki. Az ellenőrzési feljegyzésnek meg kell magyaráznia, mit ellenőriztek, és meg kell őriznie a döntés felülvizsgálatához szükséges bizonyítékokat. Ez az útmutató az általános fizetés-egyeztetési elveket írja le, nem egy adott szolgáltatás megvalósítását. 04 Tegye egyértelművé a rendeléshozzárendelést A rögzített fogadó címek több, hasonló összegű rendelést is fogadhatnak. Egy egyező átutalás létezése nem bizonyítja, hogy melyik ügyfél vagy rendelés kapjon jóváírást. Az élő fizetések elfogadása előtt határozza meg a hozzárendelési módszert, és foglalja bele az ütközések kezelését. A felhasználó által megadott tranzakciós hivatkozás továbbra is megköveteli annak ellenőrzését, hogy ugyanazt az átutalást nem rendelték-e már máshoz. Képzeljen el két számlát ugyanarra az összegre ugyanazon az útvonalon egy átfedő időablakban. Egy figyelő egy átutalást lát. Mindkettő automatikus kifizetettnek jelölése helytelen; az egyik kiválasztása elegendő bizonyíték nélkül szintén nem biztonságos. Tartsa az átutalást hozzá nem rendeltként vagy felülvizsgálat alatt, amíg az üzemeltető szabályzata meg tud állapítani egy érvényes hozzárendelést. A kétértelmű egyezés kezelendő állapot, nem ok a bizonyosság kitalálására. 05 Határozzon meg olyan állapotokat, amelyek elviselik a késői és változó bizonyítékokat Egy fizetési folyamat előnyére válik egy kis, világos állapotkészlet, ahol a láncbizonyíték elkülönül a rendelés elfogadásáról szóló döntéstől. Ez a szemléltető táblázat lehetséges szakaszokat magyaráz, nem egy adott szolgáltatás állapotneveit írja le. Minden átmenetnek ellenőrzött indoka kell legyen, és a fizetés elfogadásának külön kell maradnia az infrastruktúra nyújtásától. Foglalja bele a késői, részleges és többletátutalásokat, az ajánlat lejáratát és az átmenetileg elérhetetlen láncadatokat. A lejárat nem tünteti el a valódi átutalást. Egy késői fizetés felülvizsgálatot igényelhet az automatikus elfogadás vagy elutasítás helyett. Ha egy korábban megfigyelt láncesemény megváltozik, a dokumentált szabályzat szerint értékelje újra az állapotot, ahelyett hogy minden figyelői értesítést visszafordíthatatlan igazságként kezelne. Szemléltető állapot Jelentés Következő döntés Várakozik Nincs ellenőrzött, minősülő átutalás Folytassa az érvényes számla megfigyelését Észlelve Releváns átutalás megfigyelve Ellenőrizze a lánc megbízhatóságát és a hozzárendelést Megerősítés alatt Az elfogadási szabály még nem teljesült Figyelje meg, amíg a szabályzat lehetővé teszi a döntést Felülvizsgálat Késői, részleges vagy kétértelmű bizonyíték Oldja fel az üzemeltetői szabályzat szerint Elfogadva Ellenőrzött és egyeztetett fizetés Folytassa a külön szállítási munkafolyamattal 06 Tegye biztonságossá és megfigyelhetővé az újrapróbálkozásokat A figyelők és az egyeztetési feladatok megszakadt kapcsolatok vagy folyamat-újraindítások után újrapróbálkoznak. Használjon stabil átutalás-azonosítót, például a láncot és a megfelelő tranzakció- vagy átutalás-azonosítót, hogy megakadályozza az ismételt jóváírásokat. Tartósítsa a folyamatot és a döntéseket, hogy ugyanaz az esemény újra feldolgozható legyen anélkül, hogy második szolgáltatást nyújtana vagy egy elfogadott ajánlatot megváltoztatna. Különböztesse meg az ismeretlen eredményt a sikertelen művelettől. Ha egy alsóbb szintű kérés időtúllépésbe fut, az újraküldés előtt vizsgálja meg annak hiteles eredményét. Tartson tartós nyilvántartást az elfogadott és bizonytalan műveletekről. Korlátozza a hozzáférést a rendelési tokenekhez és a belső bizonyítékokhoz, miközben elegendő információt tartson meg egy vitatott fizetés kivizsgálásához. A megbízhatóság itt az ismételhető döntésekről szól, nem a fizetési folyamat sima animációjáról. 07 Tudja, mire van még szüksége egy függőben lévő rendelésnek Egy rendelés függőben maradhat, mert az átutalást nem figyelték meg, a szükséges láncmegbízhatóságot nem érték el, vagy a számlához való hozzárendelését felül kell vizsgálni. Őrizze meg a számlát és a nyilvános tranzakciós hivatkozást, ellenőrizze a megadott elfogadási szabályokat, és használja a rendelés szánt segítségnyújtási folyamatát. A késleltetett állapotfrissítés önmagában nem ok arra, hogy újabb fizetést küldjön. Kövesse a tényleges rendelés utasításait és ellenőrzött állapotát. A fizetés megerősítésének az egyeztetett átutalás elfogadását kell azonosítania, míg a szolgáltatásnyújtásnak külön állapota van. A segítségkérésekből tartsa ki a privát hozzáférési tokeneket és a tárca titkait. FORDÍTSA CSELEKVÉSRE Az Ön gyakorlati ellenőrzőlistája. ✓ Tartósítson egy megváltoztathatatlan, szerver által létrehozott ajánlatot. ✓ Ellenőrizze a láncot, a címzettet, az eszközt és az egész számú összeget. ✓ Dokumentálja a láncspecifikus elfogadási szabályokat. ✓ Kezelje a rögzített címek ütközéseit találgatás nélkül. ✓ Akadályozza meg az ismételt jóváírásokat és a nem biztonságos újrapróbálkozási beküldéseket. ✓ Tesztelje a késői, részleges, rossz útvonalú és megváltozott bizonyítékú eseteket. Ellenőrzőlista letöltése GYAKORI KÉRDÉSEK A fontos részletek. Elegendő egy tranzakciós hash a fizetés megerősítéséhez? + Nem. Ellenőrizze az átutalást a szándékolt láncon, annak adatcsomagját és megbízhatóságát, majd állapítsa meg, hogy a rendeléshez tartozik, és még nem írták jóvá. Használhat minden hálózat ugyanazt a megerősítési küszöbértéket? + Nem. A hálózatok eltérő megbízhatósági és véglegességi modelleket tárnak fel. Az üzemeltetőnek minden útvonalhoz megfelelő elfogadási szabályzatot kell meghatároznia és tesztelnie. A megerősített fizetés azt jelenti, hogy a szervert kiépítették? + Nem. A fizetés elfogadása és a szállítás külön munkafolyamat-események. A kiépítési állapotot a saját hiteles folyamatából közölje. ELSŐDLEGES HIVATKOZÁSOK Menjen a forráshoz. Ezek a hivatkozások támogatják az útmutató műszaki fogalmait. Kövesse az aktuális dokumentációt, mielőtt éles rendszert módosítana. Bitcoin fejlesztői útmutató: Blokklánc viselkedés developer.bitcoin.org Ethereum: Proof of stake és véglegesség ethereum.org Solana: RPC állapotkötelezettség-vállalás solana.com Szerkesztői útmutatás: SwissOctet. A példák tájékoztató jellegűek. A szolgáltatási specifikációkat, az elérhető opciókat és a szerződéses feltételeket külön kell ellenőrizni. KAPCSOLJA ÖSSZE A TUDÁST Kapcsolódó infrastruktúra. Vector VPS Svájc Metal Hyper Svájc Veil Onion Svájc TARTSA A FONALAT Az Ön következő terepjegyzetei. Fedezze fel az összes útmutatót TEREPJEGYZET / 01 + Felhő és VPS Alapok Hogyan válasszunk VPS-t találgatás nélkül Alakítsa az alkalmazásötletet hasznos erőforrás-költségvetéssé, majd hasonlítsa össze a CPU, a memóriát, a tárhelyet és az átvitelt együtt. 4 perc olvasás Olvassa el az útmutatót TEREPJEGYZET / 02 + Kriptofizetések Alapok Kripto fizetési folyamat és a fizetési adatvédelem korlátai Ismerje meg az eszköz, a hálózat és a megerősítés útját, és védje azokat az információkat, amelyek a projektjét egy fizetéshez kapcsolják. 4 perc olvasás Olvassa el az útmutatót TEREPJEGYZET / 03 + Kriptofizetések Alapok Válassza ki az eszközt és a hálózatot, mielőtt kriptofizetést készítene elő Olvassa el a fizetési útvonalat teljes eszköz- és hálózatpárként, majd ellenőrizze a számla utasításait, a token azonosságát és a beérkező összeget, mielőtt engedélyezné az átutalást. 4 perc olvasás Olvassa el az útmutatót