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.
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.
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.
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.
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.
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 |
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.
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.
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.
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.
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.