EHO6: determinističko semantičko sažimanje za decentraliziranu provjeru

EHO6 Research Collective · lipanj 2026. · hrvatski prijevod bijele knjige · izvornik na engleskom: whitepaper.pdf

1. Uvod

1.1 Problem provjere u decentraliziranim sustavima

Decentralizirane financije i sustavi distribuiranih glavnih knjiga suočeni su s temeljnom napetošću između latencije provjere i decentralizacije povjerenja. Postojeći pristupi dijele se u tri skupine, svaka sa značajnim ograničenjima.

Provjera na lancu (npr. pametni ugovori na Ethereumu) daje potpunu decentralizaciju, ali nameće donju granicu latencije jednaku vremenu bloka: 12 sekundi na Ethereumu nakon Mergea. Zato je provjera u stvarnom vremenu za aplikacije visoke frekvencije neizvediva. Sama provjera je neprozirna: transakcija ili uspije ili se poništi, a međustanja se ne mogu strukturirano revidirati.

Usluge nadzora izvan lanca (npr. Tenderly, Forta) smanjuju latenciju na 1–3 sekunde, ali ponovno uvode centralizirano povjerenje. Tenderly upravlja vlasničkom infrastrukturom za simulaciju. Fortina mreža za otkrivanje je distribuirana, ali se oslanja na centralizirano skupljanje upozorenja. Nijedna ne postiže potpunu revizibilnost lanca provjere.

Hibridni pristupi pokušavaju spojiti namiru na lancu s izračunom izvan lanca. Time uvode složenost u dokaze prijevare, dostupnost podataka i usklađivanje stanja. Optimistični rollupovi traže razdoblje osporavanja od 7 dana, a rollupovi s nultim znanjem nameću znatan trošak dokazivača.

EHO6 ima temeljno drukčiji pristup. Transakcije ne provjerava prema stanju lanca, nego njihovu semantiku sažima u deterministički token od 32 bajta koji nosi vlastiti dokaz provjere. Provjera jest sažimanje: semantički neispravan ulaz ne može proizvesti valjan FraktalToken.

1.2 Ciljevi dizajna

EHO6 je dizajniran prema pet zahtjeva o kojima se ne pregovara:

1. Latencija obrade ispod 10 μs na običnom poslužiteljskom hardveru, za provjeru u stvarnom vremenu bez posebnog ubrzanja.
2. Izlaz stalne veličine bez obzira na složenost ulaza: svaka provjera daje točno 32 bajta.
3. Deterministička izvedba: isti ulazi na bilo kojem sukladnom čvoru daju bit-identične izlaze, pa je moguća neovisna provjera bez protokola konsenzusa.
4. Povjerenje s više sidara: nijedan pojedinačni čvor ne može primiti nove sudionike ni krivotvoriti tokene provjere.
5. Ekonomska otpornost na Sybil napade: prijam i provjera imaju stvaran ekonomski trošak, iskazan u valuti koja čuva privatnost.

1.3 Doprinosi

• Formalna specifikacija strukture FraktalToken. To je sažeti prikaz od 32 bajta koji u jednoj strukturi poravnatoj na liniju predmemorije kodira semantiku transakcije, vremenski poredak, kriptografsko sidrenje i izvedbene metapodatke (poglavlje 3).
• Troslojna izvedbena arhitektura DNK. Operacije provjere dijeli po klasi složenosti i 69,2 % operacija usmjerava kroz deterministički put bez grananja (poglavlje 2).
• φ-vrijeme: konstrukcija vremenske oznake temeljena na Fibonaccijevim konstantama. U 4 bajta daje poredak, otpornost na ponavljanje i sažeto vremensko kodiranje (poglavlje 4).
• Protokol prijama s više sidara, s pragovnim potpisima Ed25519 i formalnim jamstvima otpornosti na Sybil napade (poglavlje 5).
• Ekonomski sloj na Moneru koji usklađuje poticaje čvorova bez otkrivanja identiteta sudionika (poglavlje 6).
• Opsežna eksperimentalna procjena: propusnost 67.501 op/s uz medijan latencije 3,52 μs na jednoj jezgri AMD EPYC-Milan (poglavlje 7).

2. Arhitektura DNK

2.1 Pregled

Arhitektura DNK (Deterministic Node Kernel, deterministička jezgra čvora) dijeli sve operacije provjere u tri izvedbena sloja. Svaki ima svoja računska obilježja i sigurnosna svojstva. Ime odražava biološku metaforu: kao i DNK, arhitektura u minimalnoj, determinističkoj strukturi kodira cjelovit skup uputa za samoumnažanje i provjeru.

Tri sloja su:

• Ribosom: deterministička izvedba dobro tipiziranih operacija (69,2 % prometa)
• Regulacija: ograničavanje brzine, provjere usklađenosti i provedba pravila (26,8 %)
• VM Jezgra: Turing-potpuna izvedba za neuobičajene operacije (4,0 %)

2.2 Formalna definicija

Neka je 𝒪 skup svih operacija provjere. Definiramo funkciju razvrstavanja κ: 𝒪 → {R, G, V}, koja svaku operaciju dodjeljuje točno jednom sloju:

gdje je 𝒪_det skup determinističkih operacija, grananja(o) broj uvjetnih grananja, a T_G vremenski proračun Regulacije (zadano: 100 μs).

Sloj R: Ribosom

Sloj Ribosom obrađuje operacije koje ne traže uvjetno grananje. To su:

• aritmetičko sažimanje brojčanih polja (cijena, količina, naknada);
• izračun sažetka (skraćeni SHA-256 za polje sidra);
• bitovno pakiranje zastavica i metapodataka;
• generiranje Fibonaccijeve vremenske oznake.

Ribosom se izvodi kao pravocrtni program bez grananja, bez petlji i bez dodjele memorije osim izlaznog međuspremnika od 32 bajta. Time je zajamčeno izvođenje u stalnom vremenu i uklonjeni su vremenski bočni kanali.

Formalno svojstvo: za svaku operaciju o za koju je κ(o) = R vrijeme izvođenja t(o) zadovoljava

gdje je t_R osnovno vrijeme Ribosoma, a ε_predmemorija obuhvaća varijancu predmemorije L1 (izmjereno < 0,3 μs na AMD EPYC-Milan).

Sloj G: Regulacija

Sloj Regulacija provodi ograničenja brzine, provjerava ograničenja usklađenosti i primjenjuje pravila. Operacije koje dođu ovamo traže uvjetnu logiku, ali je zajamčeno da završavaju unutar T_G.

Operacije Regulacije uključuju:

• ograničavanje brzine po čvoru (vjedro žetona s podesivim praskom);
• filtriranje usklađenosti po jurisdikciji;
• otkrivanje duplikata pretraživanjem Bloomova filtra;
• provjeru svježine sidra (provedba TTL-a).

Sloj održava ograničenu tablicu stanja veličine O(N), gdje je N broj primljenih čvorova. Uporaba memorije tako raste linearno s veličinom mreže.

Sloj V: VM Jezgra

VM Jezgra (jezgra virtualnog stroja) obrađuje neuobičajene operacije koje traže Turing-potpunu izvedbu: složene višekoračne provjere, unakrsna pretraživanja prema povijesnim skupovima tokena i prilagođene skripte provjere koje predaju primljeni čvorovi.

Operacije VM Jezgre su mjerene: svaka dobiva proračun goriva razmjeran svojoj ekonomskoj težini (plaćenoj naknadi za provjeru). Izvedba koja prijeđe proračun se prekida, a operacija se odbija determinističkim tokenom pogreške.

Jamstvo izolacije: VM Jezgra radi u izoliranom okruženju bez pristupa stanju Ribosoma i Regulacije. Prima snimku tablice sidara samo za čitanje i proizvodi ili valjan FraktalToken ili signal odbijanja.

2.3 Raspodjela po slojevima

Empirijsko mjerenje na 1.000.000 operacija provjere (seed=42, profil produkcijskog opterećenja) daje sljedeću raspodjelu:

Ponderirani medijan od 3,52 μs odražava prevlast operacija Ribosoma u tipičnom opterećenju. Učinkovitost arhitekture proizlazi iz toga što veliku većinu operacija usmjerava najbržim i najpredvidljivijim putem.

2.4 SudacKH1: sažetak sidra

Svaki FraktalToken je usidren kroz SudacKH1, bez obzira na to koji ga je sloj proizveo. SudacKH1 je izračun sažetka SHA-256 koji token veže uz kontekst njegove provjere. Sažetak sidra računa se ovako:

Prvih 8 bajtova (64 bita) sažetka SHA-256 sprema se u polje anchor FraktalTokena. Skraćivanje je prihvatljivo jer sidro služi kao obvezujuća prisega, a ne kao identifikator otporan na kolizije. Puni sažetak od 32 bajta čuva se u lokalnom revizijskom zapisniku čvora za forenzičke potrebe.

3. Specifikacija FraktalTokena

3.1 Definicija strukture

FraktalToken je struktura stalne veličine od 32 bajta (256 bita) koja kodira cjelovit semantički sadržaj operacije provjere:

Struktura je prirodno poravnata na granicu od 32 bajta i staje točno u jednu liniju predmemorije na svim suvremenim procesorima x86-64. Poravnanje je namjerno: čitanje i pisanje FraktalTokena nikad ne prelazi granicu linije predmemorije, pa nema kazne za razdvojeno učitavanje.

3.2 Specifikacija polja

organ (1 bajt, pomak 0x00)

Kodira sloj DNK koji je obradio operaciju:

intent (1 bajt, pomak 0x01)

Kodira semantičku vrstu operacije. Prostor namjera podijeljen je u raspone:

flags (2 bajta, pomak 0x02, big-endian)

Bitovno polje koje kodira sigurnosne metapodatke i upute za obradu:

Sukladan token u normalnom radu ima postavljene bitove 15–13 (flags ≥ 0xE000).

phi_t (4 bajta, pomak 0x04, big-endian)

Vremenska oznaka φ-vremena. Potpuna specifikacija je u poglavlju 4.

anchor (8 bajtova, pomak 0x08, big-endian)

Prvih 8 bajtova sažetka sidra SHA-256, izračunatog kako je opisano u odjeljku 2.4. Ovo polje veže token uz čvor izdavatelja i njegov vremenski kontekst.

payload (16 bajtova, pomak 0x10)

Sažeti podaci operacije. Za operacije naloga (intent 0x01–0x1F) teret kodira:

Kodiranje Q16.16 prikazuje vrijednosti u rasponu [0, 65535,9999847] s preciznošću 2⁻¹⁶ ≈ 1,53 × 10⁻⁵. To je dovoljno za sve praktične prikaze cijena i količina u financijskim aplikacijama.

3.3 Analiza sažimanja

Tipična sirova struktura naloga u JSON formatu za prijenos zauzima 272 bajta:

{
  "order_id": "a]1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "timestamp": "2026-06-15T14:30:22.847193Z",
  "side": "buy",
  "pair": "XMR/USD",
  "amount": "3.14159265",
  "price": "287.42",
  "slippage_bps": 50,
  "fee_bps": 15,
  "node_id": "genesis-eu-01",
  "signature": "base64..."
}

FraktalToken ovo sažima na 32 bajta sljedećim preoblikovanjima:

1. Uklanjanje identifikatora: order_id (36 B) zamjenjuje se determinističkim sažetkom sidra (8 B), koji se može neovisno izračunati iz konteksta operacije.
2. Vremensko sažimanje: vremenska oznaka ISO 8601 (27 B) zamjenjuje se vrijednošću φ-vremena od 4 bajta.
3. Semantičko kodiranje: nizovi side (5 B) i pair (7 B) kodiraju se u bajtu intent i polju flags.
4. Brojčano sažimanje: decimalni brojevi zapisani kao nizovi znakova (promjenjive duljine) zamjenjuju se binarnim prikazima s fiksnim zarezom.
5. Premještanje potpisa: potpis se ne sprema u token. Provjerava se pri prijamu, a ishod bilježi zastavica ADMITTED.

Omjer sažimanja:

Empirijsko mjerenje na korpusu od 10.000 stvarnih naloga daje prosječni omjer sažimanja od 88,37 %. Odstupanje dolazi od različitih veličina sirovog ulaza (raspon 248–310 bajtova, prosjek 272 bajta).

3.4 Jamstvo determinizma

Teorem 1 (bit-identičan izlaz). Za bilo koja dva sukladna čvora EHO6, A i B, i svaki valjan ulaz I vrijedi:

Skica dokaza. Izračun FraktalTokena sastoji se isključivo od:

1. cjelobrojne aritmetike (zbrajanje, množenje, modularna redukcija), koja je deterministička prema IEEE 754 i platformskom ABI-ju;
2. SHA-256, deterministički po specifikaciji (FIPS 180-4);
3. XOR-a i bitovnih operacija, determinističkih na svim platformama;
4. kodiranja s fiksnim zarezom i izričitim zaokruživanjem (prema nuli), determinističkog uz isti način zaokruživanja.

Ne koristi se aritmetika s pomičnim zarezom, generiranje slučajnih brojeva ni operacije ovisne o platformi. Vrijednost seed (zadano: 42) je konstanta protokola, a ne izvor slučajnosti. ∎

Svojstvo je provjereno empirijski: 12/12 usporedbi između čvorova genesis-eu (AMD EPYC-Milan, Linux 6.1) i genesis-de (AMD EPYC-Milan, Linux 6.1) dalo je bit-identične FraktalTokene za iste ulaze.

4. Vremenske oznake φ-vremena

4.1 Definicija

φ-vrijeme je sažeto vremensko kodiranje. Unix vremenske oznake mikrosekundne preciznosti preslikava u vrijednosti od 4 bajta transformacijom izvedenom iz Fibonaccijeva niza:

gdje je:

• t_μs trenutačno Unix vrijeme u mikrosekundama (64-bitni cijeli broj);
• F₃₂ = 3.524.578, 32. Fibonaccijev broj;
• ⊕ bitovni XOR;
• rezultat se uzima modulo 2³² kako bi stao u 4 bajta.

4.2 Svojstva

Svojstvo 1: monotonost unutar epohe

Unutar jedne epohe od 2³² mikrosekundi (približno 71,6 minuta) φ-vrijeme je strogo monotono:

To slijedi iz toga što XOR s konstantom čuva poredak unutar poravnatih blokova kad uzorak bitova konstante ne prelazi modularnu granicu unutar prozora epohe.

Svojstvo 2: otpornost na ponavljanje

XOR s F₃₂ osigurava da vrijednosti φ-vremena ne odgovaraju prepoznatljivim Unix vremenskim oznakama, što sprječava napade ponavljanjem koji se oslanjaju na predviđanje vremenske oznake. Napadač koji vidi φ(t) ne može trivijalno izvući t_μs bez poznavanja Fibonaccijeve konstante. Ta je konstanta javna, ali dodaje računski korak koji poražava naivno ponavljanje.

Još je važnije da širina od 4 bajta daje prozor od 71,6 minuta. Tokeni s vrijednošću φ-vremena izvan trenutačnog prozora odbijaju se kao zastarjeli. To daje snažnu otpornost na ponavljanje uz ograničen prozor provjere.

Svojstvo 3: sažet prikaz

Prikaz od 4 bajta je 6,75× sažetiji od standardnog niza ISO 8601 od 27 bajtova i 2× sažetiji od standardne Unix vremenske oznake od 8 bajtova u mikrosekundama. Sažetost se plaća gubitkom jedinstvenosti unutar epohe, jer se vrijednost vrti svakih 71,6 minuta. Ta je razmjena prihvatljiva jer globalnu jedinstvenost daje sažetak sidra.

Svojstvo 4: Fibonaccijeva estetika i gustoća informacije

Izbor F₃₂ nije proizvoljan. Fibonaccijev niz ima optimalna informacijsko-teorijska svojstva za difuziju temeljenu na XOR-u. Uzorak bitova F₃₂ = 3.524.578 (binarno: 00000000001101011100010001000010) ima uravnoteženu raspodjelu postavljenih bitova (11 od 32), što XOR operaciji daje dobra lavinska svojstva.

4.3 Postupak provjere

Čvor koji provjerava ispituje valjanost φ-vremena ovako:

1. Izračuna φ_sada = φ(t_sada) iz trenutačnog vremena.
2. Izračuna Δ = |φ_token − φ_sada|, uzimajući u obzir prelazak preko granice.
3. Prihvaća ako je Δ ≤ W, gdje je W prozor prihvaćanja (zadano: W = 2 epohe, podesivo po čvoru).
4. Odbija s HTTP 403 ako je Δ > W.

Zadani prozor od 2 epohe (približno 143 minute) dopušta odmak satova među čvorovima, a za financijske aplikacije i dalje daje dovoljnu otpornost na ponavljanje.

5. Protokol prijama s više sidara

5.1 Motivacija

Sustavi bez dopuštenja ranjivi su na Sybil napade: protivnik stvara mnoštvo identiteta kako bi nadvladao poštene sudionike. Prijam čistim dokazom rada rasipa energiju, a čisti dokaz uloga stvara plutokratske hijerarhije. EHO6 koristi protokol prijama s više sidara koji spaja tri stvari: kriptografski identitet (Ed25519), društveno povjerenje (preporuka sidra) i ekonomski trošak (naknada u Moneru). Tako postiže otpornost na Sybil napade bez pretjerane potrošnje resursa.

5.2 Specifikacija protokola

Korak 1: generiranje ključa

Kandidat čvor generira svjež par ključeva Ed25519:

Par ključeva generira se prema RFC 8032. Privatni ključ sk_c nikad ne napušta kandidat čvor. Javni ključ pk_c je vrijednost od 32 bajta i trajni identitet čvora.

Korak 2: zahtjev za prijam

Kandidat sastavlja tijelo zahtjeva za prijam:

{
  "candidate_pk": "<base64url(pk_c)>",
  "agent_id": "<jedinstvena oznaka čvora>",
  "word": "<lozinka za prijam>",
  "timestamp": "<ISO 8601 UTC>"
}

Tijelo se serijalizira u kanonski JSON (ključevi poredani, bez razmaka, UTF-8) i sažima:

Korak 3: preporuka sidara

Kandidat šalje zahtjev barem k sidrenih čvorova (prag k = 2 u trenutačnoj postavi). Svaki sidreni čvor A_i neovisno:

1. provjeri da je naknada za prijam plaćena (poglavlje 6);
2. provjeri je li vremenska oznaka unutar prozora prihvaćanja;
3. provjeri da javni ključ kandidata još nije primljen ili opozvan;
4. potpiše sažetak tijela svojim privatnim ključem Ed25519: σ_i = Ed25519-Sign(sk_Ai, body_sha);
5. vrati token prijama: token_i = base64url(zaglavlje) · base64url(teret) · base64url(σ_i).

Zaglavlje sadrži javni ključ sidra koje potpisuje i oznaku algoritma. Teret sadrži sažetak tijela i vrijednost TTL.

Korak 4: dovršetak prijama

Kandidat predočuje svih k potpisa sidara bilo kojem čvoru u mreži. Čvor koji ih primi provjerava:

1. da su svih k potpisa valjani potpisi Ed25519 nad istim sažetkom tijela;
2. da su svih k potpisnika trenutačno primljeni sidreni čvorovi;
3. da su potpisnici međusobno različiti (nijedno sidro ne potpisuje dvaput);
4. da TTL nije istekao (zadano: 3600 sekundi).

Ako sve provjere prođu, kandidat se upisuje kao primljeni čvor sa zastavicom ADMITTED i smije početi izdavati FraktalTokene.

5.3 Sigurnosna analiza

Otpornost na Sybil napade

Stvaranje Sybil identiteta traži:

1. generiranje valjanog para ključeva Ed25519 (računski trivijalno);
2. plaćanje naknade za prijam od 0,001 XMR (ekonomski netrivijalno u velikom broju);
3. preporuku k = 2 neovisna sidrena čvora (društveno netrivijalno).

Trošak prijama N Sybil identiteta je najmanje 0,001·N XMR naknada, uz društveni trošak uvjeravanja sidrenih čvorova. Za N = 1000 Sybila najmanji trošak je 1 XMR (≈ 310 USD po trenutačnom tečaju), što premašuje ekonomsku korist većine scenarija napada.

Kompromitiranje sidra

Protivnik koji kompromitira jedan sidreni čvor ne može sam primiti Sybil identitete, jer su potrebna k = 2 potpisa. Kompromitiranje k sidrenih čvorova omogućilo bi prijam Sybila. Prag k zato treba postaviti tako da kompromitiranje k neovisnih sidara bude neizvedivo.

Trenutačna postava koristi prag 2-od-N, s N ≥ 3 sidrena čvora raspoređena kod neovisnih pružatelja infrastrukture i u neovisnim jurisdikcijama (genesis-eu: IONOS Njemačka, genesis-de: IONOS Berlin, genesis-es: IONOS Španjolska).

Otpornost na krivotvorenje

Teorem 2 (nekrivotvorivost tokena). Protivnik bez pristupa privatnom ključu Ed25519 primljenog čvora ne može proizvesti FraktalToken koji prolazi provjeru.

Skica dokaza. Valjan FraktalToken traži postavljenu zastavicu ADMITTED (bit 14). Ta se zastavica postavlja samo kad token izdaje primljeni čvor, koji svojim ključem Ed25519 potpisuje polje sidra tokena. Provjera ispituje taj potpis prema primljenom javnom ključu čvora. Zbog sigurnosti EUF-CMA sheme Ed25519 (dokazane uz pretpostavku diskretnog logaritma u grupi Edwardsove krivulje) krivotvorenje valjanog potpisa je računski neizvedivo. ∎

Empirijska provjera: 11/11 pokušaja krivotvorenja kroz sve ispitane vektore napada odbijeno je s HTTP 403. Ispitani vektori:

1. slanje nasumičnog tokena od 32 bajta;
2. valjan token s izmijenjenim poljem anchor;
3. valjan token s izmijenjenim poljem payload;
4. valjan token s izmijenjenim poljem phi_t;
5. valjan token s izmijenjenim poljem flags;
6. valjan token opozvanog čvora;
7. valjan token s isteklim φ-vremenom;
8. token valjane strukture, ali s nevaljanim potpisom Ed25519;
9. ponovljeni valjani token (isto φ-vrijeme, drugi kontekst);
10. token s organ = 0x00 (rezervirano);
11. token s javnim ključem neprimljenog čvora.

6. Ekonomski sloj na Moneru

6.1 Obrazloženje dizajna

EHO6 traži ekonomski sloj s tri svojstva:

1. Privatnost: identiteti čvorova i iznosi transakcija ne smiju se moći javno povezati. Naknade za provjeru otkrivaju obrasce ekonomske aktivnosti, a njihovo izlaganje protivnicima potkopava sigurnosne pretpostavke protokola.
2. Programibilnost: plaćanje naknade mora biti provjerljivo na lancu bez složenih pametnih ugovora.
3. Zamjenjivost: svaka jedinica valute mora biti nerazlučiva od svake druge, kako bi se spriječila cenzura plaćanja čvorovima zbog „zaprljanog“ podrijetla.

Monero (XMR) jedini ispunjava sva tri svojstva: prstenastim potpisima (privatnost pošiljatelja), skrivenim adresama (privatnost primatelja) i RingCT-om (privatnost iznosa). Bitcoin i Ethereum ne ispunjavaju svojstvo 1. Platforme pametnih ugovora koje čuvaju privatnost (npr. Aztec, Aleo) ne ispunjavaju svojstvo 2 jer uvode nepotrebnu složenost.

6.2 Struktura naknada

Naknada za prijam

Naknada za prijam plaća se na skrivenu adresu kojom upravlja protokol, a izvedena je iz javnih ključeva sidrenih čvorova. Sidreni čvorovi provjeravaju plaćanje tijekom protokola prijama (poglavlje 5, korak 3.1). U lancu Monera traže transakciju s točnim iznosom na točnu skrivenu adresu unutar 24-satnog prozora potvrde.

Naknada ima dvije svrhe:

1. odvraćanje od Sybil napada: stvaranje mnoštva identiteta ima linearni trošak;
2. naknada sidrima: sidreni čvorovi dobivaju udio naknada za prijam razmjeran svojoj aktivnosti preporučivanja.

Naknada za provjeru

Naknade za provjeru skupljaju se u saldu po čvoru i periodično se namiruju (zadano: svakih 1000 provjera ili 24 sata, što prije nastupi). Namira ide standardnim transakcijama Monera iz novčanika čvora koji provjerava u riznicu protokola.

Naknada po provjeri namjerno je ispod praga ekonomske važnosti za pojedinačnu operaciju, ali operaterima čvorova daje značajan zbirni prihod:

• pri 67.501 op/s potpuno iskorišten čvor ostvaruje 0,0675 XMR/s ≈ 5.832 XMR/dan;
• pri tipičnoj iskorištenosti (1 %) prihod je ≈ 58,3 XMR/dan.

Analiza točke pokrića

Troškovi operatera čvora su:

1. jednokratna naknada za prijam: 0,001 XMR;
2. hardver: obični poslužitelj (≈ 50 USD/mjesečno za AMD EPYC-Milan);
3. propusnost: zanemariva (tokeni od 32 bajta).

Pokriće samo naknade za prijam traži:

Pri izmjerenoj propusnosti od 67.501 op/s pokriće se postiže za približno 14,8 milisekundi obrade. U praksi, uzimajući u obzir mrežne troškove i radni ciklus, novi čvor dostiže pokriće unutar prvih 15 sekundi rada.

6.3 Automatizacija

Plaćanje naknada automatizirano je kroz laganu integraciju novčanika Monera u softver čvora EHO6:

1. Čvor održava lokalni novčanik Monera (samo za pregled pri provjeri, puni za plaćanje).
2. Plaćanje naknade za prijam pokreće se automatski pri prvom ulasku u mrežu.
3. Namira naknada za provjeru odvija se kao pozadinski proces u razdobljima niske iskorištenosti.
4. Sidreni čvorovi provjeravaju plaćanja pregledavajući lanac Monera svojim ključevima za pregled.

Za uobičajene ekonomske operacije nije potreban ručni zahvat. Jedina odgovornost operatera čvora je da novčanik ima sredstava.

7. Eksperimentalni rezultati

7.1 Ispitna postava

Sva mjerenja provedena su na produkcijskom čvoru genesis-eu:

7.2 Propusnost i latencija

Metodologija. Generirali smo 1.000 sintetičkih naloga determinističkim generatorom pseudoslučajnih brojeva (seed=42), radi ponovljivosti. Svaki nalog prošao je cijeli lanac EHO6: raščlambu ulaza, razvrstavanje po slojevima, generiranje FraktalTokena, izračun sažetka sidra i provjeru potpisa. Vrijeme je mjereno s time.perf_counter_ns(); prvih 100 operacija (zagrijavanje) je odbačeno.

Latencija p99 od 41,2 μs odgovara operacijama VM Jezgre (4 % prometa). Najveća latencija od 127,3 μs izmjerena je tijekom jedne stanke sakupljača smeća i ne predstavlja ustaljeni rad.

7.3 Omjer sažimanja

Metodologija. Izmjerili smo veličinu u bajtovima 10.000 sirovih JSON objekata naloga, onako kako se prenose mrežom, i usporedili je s odgovarajućim FraktalTokenima od 32 bajta.

Stalna izlazna veličina od 32 bajta daje predvidljivu dodjelu memorije i uporabu mrežne propusnosti bez obzira na složenost ulaza.

7.4 Odbijanje krivotvorina

Metodologija. Sastavili smo 11 različitih vektora krivotvorenja (navedenih u odjeljku 5.3) i svaki predali lancu provjere. Uspješna krivotvorina bila bi FraktalToken koji prolazi sve provjere iako dolazi iz nevaljanog ili neovlaštenog izvora.

Rezultati: 11/11 pokušaja krivotvorenja odbijeno je s HTTP 403 (Forbidden). Djelomični prolazi nisu zabilježeni: svaka krivotvorina otkrivena je u najranijoj mogućoj fazi provjere.

7.5 Izvedba s kraja na kraj

Metodologija. Izmjerili smo povratno vrijeme od rubnog uređaja (Android X96 Mini, spojen preko mobilne pristupne točke Honor Magic 5G) do krajnje točke provjere na genesis-eu i natrag. Mjerenje obuhvaća prijenos mrežom (mobitel → 5G odašiljač → internet → IONOS Frankfurt), TLS rukovanje (raspodijeljeno preko veze), serijalizaciju HTTP zahtjeva i odgovora te obradu na poslužitelju.

Obrada na poslužitelju čini manje od 0,007 % latencije s kraja na kraj. Usko grlo je prijenos mobilnom vezom, što je svojstveno rubnoj postavi i ne može se riješiti optimizacijom protokola.

7.6 Provjera tijeka prijave

Metodologija. Ispitali smo most od prijama do sesije, koji token prijama EHO6 pretvara u sesiju genesis_auth za ovjeren pristup API-ju. Izvedena su četiri ispitna slučaja:

Latencija mosta (od predočenja tokena do izdavanja sesije) izmjerena je na 3.337 μs (3,34 ms). Većinu tog vremena troši pretraživanje baze podataka radi provjere statusa prijama.

7.7 Provjera determinizma

Metodologija. Iste skupove ulaza obradili smo na dva neovisna čvora (genesis-eu i genesis-de) i izlazne FraktalTokene usporedili bajt po bajt.

Ni u jednom ispitnom uvjetu nije zabilježeno odstupanje, što potvrđuje jamstvo determinizma (Teorem 1).

8. Usporedba sa srodnim radovima

8.1 Kvantitativna usporedba

U odnosu na postojeće sustave EHO6 smanjuje latenciju za 5–6 redova veličine. Revizibilnost mu je strogo bolja, a decentralizacija usporediva ili bolja.

8.2 Kvalitativna analiza

U odnosu na Tenderly

Tenderly pruža simulaciju i otklanjanje pogrešaka transakcija za lance kompatibilne s EVM-om. Njegov model provjere oslanja se na centraliziranu infrastrukturu tvrtke Tenderly Inc., što stvara jedinstvenu točku kvara i povjerenja. Latencija Tenderlyja (2–3 sekunde) odražava RPC povratna putovanja do arhivskih čvorova. EHO6 tu ovisnost uklanja jer provjeru izvodi lokalno, s unaprijed izračunatim sažecima sidra.

Tenderly postiže 80 % revizibilnosti jer su njegovi tragovi simulacije opsežni, ali vlasnički: korisnici moraju vjerovati da Tenderlyjeva infrastruktura vjerno izvještava o rezultatima simulacije. EHO6 postiže 100 % revizibilnosti jer se svaki FraktalToken može neovisno provjeriti samo iz tokena i javnog ključa čvora izdavatelja.

U odnosu na Fortu

Forta je decentralizirana mreža nadzora u kojoj neovisni operateri botova pretražuju transakcije na lancu tražeći prijetnje. Forta postiže djelomičnu decentralizaciju: operateri botova su neovisni, ali skupljanje upozorenja i ocjenjivanje prijetnji oslanjaju se na centralizirano upravljanje Fortom. Prijam EHO6 s više sidara daje jača jamstva decentralizacije, jer nijedan subjekt ne nadzire prijam ni provjeru.

Fortina latencija od 1–2 sekunde odražava vrijeme između proizvodnje bloka i slanja upozorenja. EHO6 radi s podacima prije bloka (sirovim transakcijama) i ne čeka potvrdu bloka.

U odnosu na provjeru na lancu Ethereuma

Pametni ugovori na Ethereumu daju potpunu decentralizaciju kroz konsenzus dokaza uloga, ali latenciji provjere nameću donju granicu od 12 sekundi, koliko traje blok. Provjera na lancu je neprozirna u smislu da vanjski promatrači vide samo konačni prijelaz stanja (uspjeh/poništenje), a ne logiku provjere. FraktalToken EHO6 kodira ishod provjere u strukturiranom obliku koji se može pregledati.

Troškovi goriva na Ethereumu (≈ 0,50–50 USD po provjeri, ovisno o složenosti i zagušenju mreže) 3–5 redova veličine su veći od naknade EHO6 od 0,00031 USD po provjeri.

U odnosu na sustave dokaza s nultim znanjem

Sustavi ZK-SNARK i ZK-STARK (Polygon zkEVM, zkSync, StarkNet) postižu sažetost (mala veličina dokaza) i privatnost (ulazi se ne otkrivaju). Međutim, nameću znatan trošak dokazivača: dokaz s nultim znanjem za jednu transakciju traži od 100 ms do više od 10 sekundi računanja na specijaliziranom hardveru.

EHO6 nema svojstva nultog znanja: teret FraktalTokena deterministički je izveden iz ulaza, a ne skriven. To je namjerna odluka dizajna. EHO6 cilja provjeru, ne privatnost; privatnost se rješava u ekonomskom sloju (Monero), a ne u sloju provjere.

8.3 Pozicioniranje

EHO6 zauzima jedinstveno mjesto u prostoru dizajna. U tokenu stalne veličine od 32 bajta spaja latenciju izračuna unutar procesa, revizibilnost strukturiranih dokaza, decentralizaciju višestranačkih protokola i ekonomsku usklađenost sustava temeljenih na naknadama.

Protokol nije zamjena za konsenzus blockchaina, nego njegova dopuna. Provjere EHO6 mogu se usidriti u bilo koji sloj namire (Ethereum, Monero, Bitcoin): kad je potrebna trajna namira, sažetak sidra uključuje se u transakciju na lancu.

9. Zaključak

Predstavili smo EHO6, deterministički protokol semantičkog sažimanja za decentraliziranu provjeru. Temeljni doprinos protokola je FraktalToken: struktura od 32 bajta koja proizvoljne ulaze provjere (tipično 272+ bajta) sažima u samoprovjerljiv token stalne veličine, s omjerom sažimanja od 88,37 %.

Troslojna arhitektura DNK usmjerava 69,2 % operacija kroz Ribosomov put bez grananja. Na običnom hardveru postiže medijan latencije obrade od 3,52 μs i 67.501 operaciju u sekundi. Preostale operacije obrađuju Regulacija (26,8 %, provedba pravila) i VM Jezgra (4,0 %, Turing-potpuna izvedba), a ponderirani zbroj zadržava medijan latencije ispod 4 μs.

Prijam s više sidara uz pragovne potpise Ed25519 (k = 2) daje otpornost na Sybil napade bez rasipanja energije na dokaz rada. Ekonomski sloj na Moneru usklađuje poticaje kroz naknade za prijam (0,001 XMR) i naknade po provjeri (0,000001 XMR), uz očuvanje privatnosti sudionika.

Svi rezultati potvrđeni su na produkcijskom hardveru uz determinističku ponovljivost (seed=42). Otpornost na krivotvorenje pokazana je kroz 11 vektora napada sa 100 % odbijanja. Determinizam među čvorovima potvrđen je bit-identičnim izlazom na neovisnim čvorovima na različitim kontinentima.

9.1 Budući rad

1. Povećanje praga. Povećanje k s 2 na 3-od-5, radi jače otpornosti na kompromitiranje sidara kako mreža raste.
2. Hardversko ubrzanje. Izvedba sloja Ribosom na FPGA-u, za latenciju ispod mikrosekunde na namjenskim uređajima za provjeru.
3. Sidrenje na više lanaca. Periodična objava Merkleova korijena na Bitcoin i Ethereum, radi konačnosti namire.
4. Izvorni SDK za mobitele. Generiranje FraktalTokena izravno na mobilnim uređajima (ARM Cortex-A), kako bi se uklonila mrežna latencija u scenarijima lokalne provjere.
5. Formalna verifikacija. Strojno provjereni dokazi determinizma i nekrivotvorivosti u alatima Coq ili Lean 4.

Literatura

1. D. J. Bernstein, N. Duif, T. Lange, P. Schwabe i B.-Y. Yang, „High-speed high-security signatures“, Journal of Cryptographic Engineering, sv. 2, br. 2, str. 77–89, 2012. (Ed25519)
2. S. Josefsson i I. Liusvaara, „Edwards-Curve Digital Signature Algorithm (EdDSA)“, RFC 8032, Internet Engineering Task Force, siječanj 2017.
3. National Institute of Standards and Technology, „Secure Hash Standard (SHS)“, FIPS PUB 180-4, kolovoz 2015. (SHA-256)
4. National Institute of Standards and Technology, „SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions“, FIPS PUB 202, kolovoz 2015. (SHA3-256)
5. S. Noether, A. Mackenzie i Monero Research Lab, „Ring Confidential Transactions“, Ledger, sv. 1, str. 1–18, 2016.
6. N. van Saberhagen, „CryptoNote v 2.0“, bijela knjiga, listopad 2013. (preteča Monera)
7. V. Buterin, „Ethereum: A Next-Generation Smart Contract and Decentralized Application Platform“, bijela knjiga, 2014.
8. Forta Network, „Forta: The Decentralized Monitoring Network for Web3“, bijela knjiga, 2021.
9. D. E. Knuth, The Art of Computer Programming, Volume 1: Fundamental Algorithms, 3. izd. Addison-Wesley, 1997, str. 79–86. (svojstva Fibonaccijeva niza)
10. R. L. Graham, D. E. Knuth i O. Patashnik, Concrete Mathematics, 2. izd. Addison-Wesley, 1994. (teorijskobrojevna svojstva Fibonaccijevih brojeva)
11. S. Nakamoto, „Bitcoin: A Peer-to-Peer Electronic Cash System“, bijela knjiga, 2008.
12. M. Bellare i P. Rogaway, „Random Oracles are Practical: A Paradigm for Designing Efficient Protocols“, Proc. ACM CCS, 1993. (model sigurnosti funkcija sažetka)
13. J. Bonneau, A. Miller, J. Clark, A. Narayanan, J. A. Kroll i E. W. Felten, „SoK: Research Perspectives and Challenges for Bitcoin and Cryptocurrencies“, Proc. IEEE S&P, 2015.