Artikkeli · r8-history-001
Miksi Bitcoinin alkuperäinen suunnitelma tarvitsi muutakin kuin digitaaliset allekirjoitukset?
>
Bitcoinin vuoden 2008 suunnitelman lähtökohta ei ollut pelkästään sähköisen rahan allekirjoittaminen. Satoshi Nakamoto kuvasi ongelman, jossa vastaanottajan pitäisi tietää myös, ettei samaa rahaa ole jo käytetty toisessa maksussa. Allekirjoitus ja yhteinen tapahtumahistoria vastaavat eri kysymyksiin.[5]
Tämä artikkeli lukee alkuperäistä suunnitelmaa historiallisena asiakirjana. Se ei väitä, että jokainen tuolloin kuvattu yksityiskohta vastaisi sellaisenaan kaikkia nykyisiä Bitcoin-ohjelmia. Tarkoitus on selittää paperin oma ongelmanasettelu, ei arvioida sijoitusta tai yksittäisen palvelun luotettavuutta.
Mitä alkuperäinen ehdotus yritti ratkaista?
Nakamoto lähetti 31. lokakuuta 2008 kryptografiaa käsittelevälle sähköpostilistalle viestin, jossa hän esitteli vertaisverkkona toimivan sähköisen rahajärjestelmän ja linkitti suunnittelupaperin. Viesti ja paperi kuvaavat ehdotusta; viestin päiväys ei itsessään kerro, milloin verkko aloitti toimintansa.[6]
Paperin johdannossa tarkastellaan verkkomaksuja, joissa rahoituslaitokset toimivat luotettuina välikäsinä. Kirjoittaja yhdisti maksujen mahdolliseen peruuttamiseen myös riitojen välittämisen kustannuksia ja tarvetta kerätä tietoja asiakkaista. Nämä ovat asiakirjan esittämiä perusteluja, eivät arvio kaikista nykyisistä maksujärjestelmistä.[5]
Allekirjoitus ei yksin kerro järjestystä
Paperi kuvaa digitaalisten allekirjoitusten ketjun: omistaja allekirjoittaa tietoa edellisestä tapahtumasta ja seuraavan omistajan julkisesta avaimesta. Vastaanottaja voi tarkistaa allekirjoitusten ketjua, mutta pelkkä ketju ei paljasta, onko jokin aiempi omistaja allekirjoittanut kilpailevan siirron samoista varoista.[5]
Kuvitellaan, että sama lähtö yritetään käyttää kahteen eri maksuun. Molemmat viestit voivat näyttää allekirjoituksen kannalta uskottavilta, vaikka niitä ei voida hyväksyä saman varan kahdeksi erilliseksi käytöksi. Vastaanottajan ongelma on siis myös yhteisesti hyväksytyn tapahtumahistorian järjestys, ei vain se, onko viestissä oikea allekirjoitus. Tämä järjestys ei takaa kaikkien tapahtumien todellisen syntyajan yleispätevää kronologista järjestystä.[5]
Aiemmin tehtävä voitaisiin asiakirjan esimerkissä antaa luotetulle keskitetylle taholle. Ehdotuksen tavoite oli löytää tapa sopia historiasta ilman tällaista jokaista tapahtumaa tarkistavaa keskusta.[5]
Miksi laskentatyö tuli mukaan?
Paperissa tapahtumia kootaan lohkoihin, jotka liitetään toisiinsa tiivisteiden avulla. Proof of work eli työn todistaminen tekee vaihtoehtoisen historian rakentamisesta laskennallisesti työlästä: vanhan lohkon muuttaminen edellyttäisi työn tekemistä uudelleen myös sitä seuraavilta lohkoilta.[5]
Paperin turvallisuusperustelu on ehdollinen. Sen mukaan rehellisten osallistujien on hallittava riittävä enemmistö laskentatehosta, jotta heidän ketjunsa voi kasvaa hyökkääjän kilpailevaa ketjua nopeammin. Tämä ei ole väite siitä, että yksittäinen maksu olisi heti peruuttamaton tai että kaikki Bitcoinin ympärillä toimivat palvelut olisivat turvallisia.[5]
Paperin mallissa tapahtuman sisältyminen lohkoon ja sen jälkeen kasvava lohkojen määrä lisäävät luottamusta maksun pysyvyyteen sen laskentatehoa koskevien oletusten puitteissa. Kilpaileva haara voi silti ohittaa aiemmin hyväksytyn haaran, jolloin tapahtuman vahvistukset voivat kadota; vahvistus ei ole ehdoton lopullisuuden lupaus.[5]
Alkuperäisessä kuvauksessa solmut hyväksyvät lohkon vain, jos sen tapahtumat ovat kelvollisia eikä niitä ole jo käytetty. Laskentatyö ja tapahtumien kelpoisuuden tarkistus ovat siis asiakirjassakin eri osia samaa kokonaisuutta.[5]
Suunnitelma ei ole lupaus kaikesta
Paperi kuvaa myös kevyempää maksujen tarkistusta ja sen rajoituksia. Se esittää mallin, jossa käyttäjä tarkastelee lohkojen otsakkeita ja tapahtuman Merkle-haaraa, mutta ei itse tarkista tapahtumaa samalla tavalla kuin täysi verkkosolmu. Tämä on historiallinen kuvaus, ei kaikkien nykyisten lompakoiden toimintatapa.[5]
Hyödyllinen tapa lukea dokumenttia on erottaa sen tavoite, oletukset ja toteutus toisistaan. Vuoden 2008 paperi selittää, miksi allekirjoitukset eivät yksin riitä kaksinkertaisen käytön ongelmaan. Tietyn nykyisen ohjelman käyttäytyminen on sen sijaan tarkistettava kyseisen ohjelmiston ja version dokumentaatiosta tai lähdekoodista.