← BLOG
05. studenoga 2026.blockchainauditabilita2 min čitanjaITENHR

Sidreno ne znači sidreno sada: prozor prije sidrenja

Između odluke i njezina sidrenja na chainu postoji prozor u kojem zapis štiti samo vaš sustav. Povežite zapise u lanac, sidrite po događaju i recite sidreno tek kad je konačno.

Usporedba stanja zapisa u ledgeru prije i nakon sidrenja na blockchainu.

Sidrenje dnevnika odluka na blockchain ne događa se u trenutku odluke. Zapisi se skupljaju, hashiraju zajedno i sidre u intervalima, jer svako sidrenje košta transakciju i treba vremena da postane konačno. Između odluke i sidrenja postoji prozor, a tijekom tog prozora jedino što štiti zapis je vaš vlastiti sustav.

Što je taj prozor

Kad agent odluči, zapis ulazi u ledger. Sustav izračuna hash, često spojen s drugim zapisima u jedan root, i objavi taj root na chainu određenom dinamikom. Dok ta objava nije uključena i konačna, nitko izvan vaše organizacije ne može dokazati da je zapis postojao u tom obliku. Svatko s pravom pisanja u vaš store mogao bi još uvijek promijeniti ili izbaciti noviji zapis, a na chainu mu ništa ne bi proturječilo. Što je ritam duži, prozor je dulji. To nije greška: to je kompromis troška koji treba zapisati, a ne sakriti. I kratak prozor je važan kad su odluke česte: mnogo zapisa čeka isti anchor i svi dijele istu izloženost.

Kako smanjiti štetu

Povežite svaki zapis s prethodnim tako da hash prethodnog uključite u sljedeći, i dajte mu sequence number. Tada uklanjanje ili promjena zapisa u sredini lomi lanac, a lom se vidi pri sljedećem sidrenju. Prozor ne nestaje, ali napad unutar njega mora prepisati sve nakon dotaknute točke prije nego stigne sljedeći anchor, i to bez rupe u slijedu. Možete sidriti i po događaju, ne samo po satu: odluka iznad određenog praga utjecaja ili ručno zatvaranje na kraju dana odmah pokreće anchor. Ritam tada prati rizik, a trošak prati odluke koje su važne.

Recite "sidreno" tek kad je konačno

Poslana transakcija nije anchor. Pričekajte broj potvrda koji odabrani chain smatra konačnim i u ledgeru zabilježite koji blok nosi root i kada je postao konačan. U verifieru pošteno prikažite tri stanja: recorded, submitted, final. Revizor koji vidi "sidreno" uz zapis koji još čeka dobio je netočnu informaciju. Ni konačnost nije trenutna, a dubina potvrde je odluka koja traži obrazloženje, a ne zadana vrijednost preuzeta iz tutoriala.

Što to znači za isporuku

Za tvrtku u regiji koja radi za strane klijente, u dizajn dokument upišite ritam, pravila okidanja i dubinu potvrde, s razlogom za svako i troškom jednog sidrenja na odabranom chainu. Revizor ne pita sidrite li. Pita što još ne možete dokazati i koliko dugo.

Odlučite i tko se obavještava kad anchor ne uspije ili predugo čeka. To je incident, a ne redak u logu: prozor se produljuje i netko za to mora odgovarati.

Koliko najdulje zapis u vašem ledgeru može postojati bez sidrenja?