- Az első szabály, hogy a Portfolio bármikor létrehozhat új Profcoinokat.
- A második szabály, hogy a Portfolio bármikor el is költheti a meglévő Profcoinjait.
Első lépésben tehát a Profcoinok generálást hajtjuk végre egy erre kitüntetett funkcióval, amiket alá is írunk a Portfolio titkos kulcsával. Ez lesz a kezdőpontunk. Amikor pedig el akarjuk ezt költeni, és például a Pénzcentrumnak fizetni vele, akkor a tranzakciót szintén aláírjuk a Portfolio kulcsával, majd erről az új blokkról egy hash mutató fog kapcsolódni a láncunk kiinduló pontjához. Ez mutatja meg, hogy ki fizetett kinek, tehát milyen úton haladtak a Profcoinok. A példánk következő lépésében a Pénzcentrum fizet az Agrárszektornak, amit már a Pénzcentrum ír alá a saját titkos kulcsával, és onnan az ő korábbi blokkjára kapcsolódik a hash mutató. Ebben a folyamatban bármikor ellenőrizhető a fizetések hitelessége azáltal, hogy a Profcoinok vándorlását végigkövetjük a láncon egészen a kezdetig, ahol is azt a Portfolio létrehozta. Szemléletesen eddig ennyi történt:
Ennél a pontnál viszont egy igen lényeges problémával találjuk szembe magunkat: az úgynevezett kettős fizetés (double spending) lehetőségével. Mi van akkor ugyanis, ha a Pénzcentrum úgy dönt, hogy a nála lévő Profcoinokkal trükközni kezd, és egyszerre fizet az Agrárszektornak és a TraderSzobának. Ha a TraderSzoba nem tud arról, hogy a neki küldött pénzzel már egyszer fizettek, akkor pusztán a Pénzcentrum aláírását elnézve, illetve a láncon visszalépkedve, azt fogja gondolni, hogy ez egy teljesen hiteles tranzakció. Csakhogy az Agrárszektor ugyanígy látja majd mindezt, ami igen súlyos problémát okoz a számunkra. Itt a Pénzcentrum kettős fizetéses támadása kivédhetetlen. Ez a jelenség jelenti a terület egyik legalapvetőbb tervezési problémáját, amire megoldást kell találnunk.
Az egyik lehetséges védekezés az, hogy a Profcoint létrehozó Portfolio minden tranzakció történetét közzéteszi. Ez pedig egy blokklánc lesz, ahol az időbélyeggel ellátott tranzakciókat mind a Portfolio írja majd alá a saját kulcsával. A tranzakciók így végig követhetőek lesznek a kezdeti pontig, aminek a hash-jét pedig a Portfolio közszemlére teszi, hogy bárki meggyőződhessen annak hitelességéről. Ebben a rendszerben tehát a Portfolio tölti be a hitelesítés nélkülözhetetlen funkcióját.
Azáltal, hogy a tranzakcióknak a történetét ilyen módon közli a Portfolio, képesek leszünk a Pénzcentrum dupla fizetéses támadását észlelni. Hiszen ekkor a TraderSzoba észre fogja venni, hogy azzal a Profcoinnal amivel neki akarnak fizetni, már korábban az Agrárszektornak fizettek. Sőt, ezt nemcsak a TraderSzoba, hanem mindenki más is látni fogja, hiszen a Portfolio által közzétett tranzakciókat rögzítő blokklánc nyilvános. Ennek a segítségével a kettős fizetéses kísérletet a TraderSzoba sikeresen vissza tudja utasítani. Általánosítva és összefoglalva mindezt: ebben a fizetési rendszerben csak akkor fogadunk majd el egy tranzakciót, ha a következő feltételek mind teljesülnek:
- A felhasznált Profcoin létezik (egyedi azonosítója hiteles)
- Korábban még nem költötték el
- A kimenő Profcoinok száma megegyezik a bejövőkkel a lépések között
- A tranzakciók alá lettek írva a tulajdonosok által
A fentieknek eleget tevő tranzakciók bekerülhetnek a Portfolio által menedzselt blokkláncba, és mindenki láthatja, hogy azok megtörténtek.
Ezáltal már el is jutottunk egy használható, blokklánc-alapú rendszerhez, amiben a kriptogárfia eszközeit felhasználva fizethetünk egymásnak biztonságosan. Egy komoly probléma viszont még maradt: a rendszer működéséhez mindenkinek meg kell bíznia a Portfolio-ban. Ebben a modellben ugyanis ő az, aki hitelesíti a tranzakciókat, vagyis a rendszer ebből a szempontból centralizáltan működik.
Természetesen egy ilyen rendszer is tökéletesen életképes, amennyiben a központ nem él vissza a hatalmával és kialakul a bizalom. Csakhogy még biztosabb alapokra helyezhetjük az egészet, ha valahogyan a központi szereplőtől megszabadulva is tudjuk hitelesíteni a tranzakciókat. Hogyan érhetjük el, hogy ezt a hitelesítési folyamatot valaki vagy valakik jól végezzék el, de azért ne kelljen őket a bizalmunkba fogadni? Az egyik lehetséges megoldás az, hogy a hitelesítési feladatot szétterítjük és valamilyen protokoll szerint konszenzusra juttatjuk a résztvevőket az érvényes tranzakciók kapcsán. Ha ezt a problémát meg tudjuk oldani, akkor a kriptopénzünk elméletben már egészen közel jár a bitcoin prototípusához. Fejlesszünk tehát egy kicsit még rajta.Nem bízunk senkiben: decentralizált működés
Ahhoz, hogy decentralizálttá, vagyis egy központi hatalomtól függetlenné varázsoljuk a fizetési rendszerünket, a következő alapkérdésekre kell megtalálnunk a válaszokat:- Ki üzemeltesse a blokkláncot?
- Kinek a hatásköre legyen a tranzakciók jóváhagyása?
- Hogyan keletkezzen a rendszerben a kriptopénz?
A bitcoin feltalálsában az egyik legfontosabb ötlet az volt, hogy a rendszert peer-to-peer módon kell felépíteni, ami azt jelenti, hogy az egyes résztvevők maguk működtetik azt, közvetlenül egymással kommunikálnak, és így nincs egy kitüntetett központ. Ilyen esetben, ha egy tranzakciót akarunk indítani, akkor azt mindenki felé egyszerre kell jeleznünk. A Profcoin gondolati kísérletét folytatva, ekkor már a blokklánc üzemeltetését nem a Portfolio végzi, hanem minden résztvevő egyszerre. Itt ha a Pénzcentrum fizetni akar valakinek, akkor a következőket kell tennie: aláírja a tranzakcióját a saját titkos kulcsával úgy, hogy az üzenet tartalmazza a címzett publikus kulcsát is. Ezen felül meg kell adnia azt a hash mutatót, ami majd elárulja, hogy a pénz, amivel fizetni akar, pontosan honnan is jött. Ezáltal mindenki láthatja, hogy kitől és kinek is megy az ellenőrzött forrásból jövő pénz.
Ahhoz, hogy egy ilyen tranzakció jóváhagyásra kerüljön, egyet kell értenie a peer-to-peer hálózat tagjainak. Egyszerűbb, de nagyon lassú lenne, ha szimplán minden egyes tranzakciót sorra vennénk, hogy döntsünk róla. Ehelyett a tranzakciókat érdemes csokrokba szedni, és azok egészéről dönteni meghatározott időközönként. A legnagyobb probléma viszont magával a konszenzusos döntés meghozatalával van. Nem pusztán a konszenzusra jutás logikai-matematikai kihívásaival állunk szemben, hanem még olyan technikai problémákkal is, amik a hálózat hibájából vagy a késleltetéséből erednek. Tökéletes protokollt az elosztott konszenzus kialakítására egyelőre nem ismerünk, de olyat viszont igen, ami a gyakorlatban egészen jól működik még az ismert nehézségek ellenére is.