Transaksjoner, blokker og endelighet

Fra forespørsel til registrering

Å trykke Send starter en rekkefølge med fem tydelige trinn. Lommeboken bygger en transaksjon som beskriver hva som skal endres. Du godkjenner den med en signatur som den private nøkkelen din lager. Lommeboken sprer den til nettverkets noder, som prøver den mot reglene: er signaturen gyldig, har kontoen nok midler, holder gebyret? Deretter tar en validator eller utvinner med gyldige transaksjoner i en blokk. Til slutt verifiserer andre noder blokken og bygger kjeden videre oppå den.

Bare det andre trinnet er ditt, og det er ugjenkallelig på en måte de fleste grensesnitt ikke framhever. Når en gyldig signatur først er spredt, spør ingen del av resten av rekkefølgen om samtykket ditt igjen. Alt du kan styre, skjer før godkjenningen.

Mellom spredning og inkludering venter en transaksjon i et område som ofte kalles mempool. Ved trengsel vokser køen, og transaksjonene som tilbyr høyere gebyrer, velges som regel først. Derfor kan en overføring virke å ha stoppet opp: den er ikke borte, den står i kø.

Bekreftelser og endelighet er ikke det samme

En bekreftelse er beviset på at en transaksjon er tatt med i en blokk. Hver blokk som bygges oppå, gjør det dyrere å skrive om den historikken, og derfor venter tjenester ofte på flere bekreftelser før de godskriver en konto. Antallet de venter på, er en risikopolicy, ikke en konstant i protokollen.

Noen nettverk legger til uttrykkelig endelighet: forbi et definert punkt regner protokollen en blokk som lukket, og å snu den ville krevd et angrep reglene gjør urimelig dyrt. Andre gir bare en sannsynlighetsgaranti som styrkes med dybden. Ingen av metodene er absolutt bedre, men den praktiske følgen er ulik, og en regel du lærte på ett nettverk, kan være feil på et annet.

Den ærlige generelle påstanden er snever: større dybde betyr lavere sannsynlighet for reversering, hvor mye dybde som trengs avhenger av nettverket og av innsatsen, og ingen nettverk tilbyr en reversering via kundeservice i etterkant.

Les statusen før du reagerer

Ventende, erstattet, mislykket og bekreftet er fire ulike tilstander med fire ulike svar. Ventende betyr spredt, men ennå ikke inkludert: svaret er som regel å vente, eller å erstatte med høyere gebyr hvis lommeboken tilbyr det. Erstattet betyr at en senere transaksjon med samme nonce har tatt plassen. Mislykket betyr at nettverket har behandlet forsøket og avvist utfallet.

Et mislykket kall til en smartkontrakt kan likevel koste gebyrer. Det overrasker, men følger av hvordan nettverket virker: validatorer har brukt reell regnekraft på å kjøre koden og oppdage at den ble avbrutt, og det arbeidet betales uansett utfall.

Den dyreste feilen på dette stadiet er å sende samme betaling to ganger fordi den første så ut til ikke å ha gjort noe. Finn transaksjonshashen og undersøk den i en utforsker for riktig nettverk før du sender noe på nytt. En overføring som bare er treg, og en som virkelig er mislykket, ser like ut i en lommebok og helt ulike på kjeden.

• Finn transaksjonshashen før du trekker noen konklusjoner.
• Undersøk den i en utforsker for nettverket du faktisk brukte.
• Skill tjenestens status fra nettverkets status: de kan skille lag.
• Send aldri på nytt før du kjenner statusen på det første forsøket.

Hva kjeden viser og hva den ikke viser

Offentlige utforskere viser adresser, beløp, kontraktskall, gebyrer, tidsstempler og statuser. Det gjør uavhengig verifisering mulig uten å be noen om lov, noe som er virkelig verdifullt når en tjeneste og et nettverk er uenige om hva som har skjedd.

Det en utforsker ikke viser, er hvem som er hvem. Den oppgir ikke noe juridisk navn og kan ikke si om en adresse tilhører en person, et selskap eller en kontrakt. Men aktivitet kan ofte knyttes: gjennom gjenbrukte adresser, gjennom tjenester som har verifisert identiteten, gjennom offentlige innlegg eller gjennom analyse av transaksjonsmønstre. Offentlig betyr ikke anonym, og en permanent registrering i dag kan analyseres i morgen med bedre verktøy.