Krüptopilv: ICP kui pilveprotokoll ja Interneti järgmine tarkvaraalus

Elame ajastul, kus mitu suurt tehnoloogilist muutust langevad kokku. Tehisaru ehk AI muudab kiiresti seda, kuidas tarkvara luuakse ja kasutatakse. Krüptograafilised võrgud on toonud internetti uued digitaalse omandi ja usalduse mudelid ning ettevõtted ja riigid vaatavad järjest teravamalt oma tehnoloogiliste sõltuvuste ja suveräänsuse poole. Need arengud ei ole üksteisest lahus. Tarkvara on saanud majanduse, kommunikatsiooni, hariduse, ettevõtete ja riikide üheks keskseks aluskihiks ning selle fundamentaalne muutumine kandub edasi peaaegu kõikidesse eluvaldkondadesse.

Praegu koondub tähelepanu põhjendatult AI-le, sest muutus on vahetult nähtav. Ühe vestluse kaudu saab juba täna analüüsida andmeid, kirjutada programmi, luua rakenduse või automatiseerida varem inimese tehtud tööd. Selle kõrval toimub aga teine, vaiksem ja vähemalt sama fundamentaalne muutus: muutub alus, millel kogu see uus tarkvara töötab. Mida võimekamaks, paindlikumaks ja autonoomsemaks tarkvara muutub, seda olulisemaks saab selle all olev pilv.

Pilv võib tavakasutajale tähendada Google Drive’i, iCloudi või kohta, kuhu salvestatakse fotosid ja dokumente. Tegelikult on pilvetaristu suure osa tänapäevase digimaailma arvutuslik alus. Seal töötavad veebiteenused, ettevõtete infosüsteemid, andmebaasid, rakendused ja järjest enam ka tehisaru. Pilv on sedavõrd sügavale tarkvarasse kasvanud, et kasutaja seda enamasti ei näe, kuid selle arhitektuur määrab suuresti, kuidas digitaalset maailma saab ehitada, hallata, kaitsta ja usaldada.

Avatud internetist pilveni

Interneti esimene suur läbimurre oli avatud ülemaailmne ühendus. Ühised protokollid võimaldasid erinevatel arvutitel ja võrkudel omavahel suhelda ilma, et kogu süsteemi kontrolliks üks ettevõte. Veeb ehitas sellele ühise informatsiooniruumi ning varases internetis võis põhimõtteliselt igaüks käitada oma serverit ja saada võrgu otseseks osaks.

Web2 järgmine suur muutus ei toimunud ainult veebilehtede kasutajaliideses. Selle üks olulisemaid infrastruktuurseid uuendusi oli pilv. Arvutusvõimsust, andmebaase, salvestust ja järjest rohkem muid teenuseid sai kasutada vajaduspõhiselt, ilma et iga tarkvaralooja peaks ise füüsilist infrastruktuuri ehitama. Väike meeskond võis luua teenuse, mida kasutasid miljonid inimesed, ning selle peale kasvasid SaaS, sotsiaalvõrgustikud, mobiilsed teenused ja suur osa tänapäevasest globaalsest tarkvaramajandusest.

Selle edu käigus tekkis aga sügav arhitektuuriline pinge. Interneti ühenduskiht jäi avatuks ja protokolliliseks, samal ajal kui järjest suurem osa selle peal töötavast tarkvarast koondus väheste suurte pilveettevõtete taristusse. Ka tarkvarapinu ise muutus järjest kihilisemaks: rakendus võib sõltuda eraldi arvutusest, andmebaasidest, salvestusest, autentimisest, API-dest, võtmehaldusest, võrgu- ja turvateenustest ning paljudest välistest osapooltest. Pilv muutis selle keerukuse kasutamise mugavamaks, kuid pilv ise ei muutunud interneti sarnaseks avatud protokolliliseks taristuks.

Krüpto + Pilv

Krüpto tõi interneti arengusse teise olulise liini. Bitcoin näitas, et ühist digitaalset arvestusraamatut saab pidada ilma ühe keskse registripidajata. Krüptograafia, konsensus ja avalikult kontrollitavad reeglid võimaldasid luua digitaalset raha, mille toimimine ei sõltunud ühe ettevõtte andmebaasist. Ethereum ja sellele järgnenud võrgud laiendasid sama põhimõtet programmeeritavatele lepingutele, varadele ja ühisele digitaalsele olekule.

Krüpto sügavam tähendus ei piirdu seega tokenite ega uue varaklassiga. See tõi tagasi interneti algse avatud võrgu loogika ning lisas sellele kontrollitava digitaalse omandi ja matemaatiliselt tugevdatud usaldusmudeli. Samas on enamiku plokiahelate kese jäänud jagatud oleku muutmise ehk tehingute ümber. Isegi siis, kui kasutusjuht ei ole otseselt finantsiline, registreeritakse põhivõrgus enamasti vara, õiguse, lepingu või muu ühise oleku muutus.

Tervikliku tarkvara seisukohalt jäi suur osa Web3-st seetõttu Web2 pilvest sõltuvaks. Nutileping võib töötada avatud krüptograafilises võrgus, kuid kasutajaliides, failid, indekseerimine, RPC-teenused, API-d ja muu rakendusloogika paiknevad sageli teistes süsteemides. Isegi NFT puhul on token ise tavaliselt arvestusraamatus, samal ajal kui suurem meediasisu võib paikneda mujal. Uued hajutatud salvestus-, arvutus- ja identiteedilahendused on seda maailma rikastanud, kuid võivad tervikrakenduse arhitektuuri muuta ka veel killustatumaks.

Siit tuleb krüptopilve mõte. Web2 pilv andis tarkvarale tohutu paindlikkuse, kasutatavuse ja ulatuse, krüpto aga avatud võrgu, omandi ja kontrollitava usalduse. Krüpto + Pilv tähendab nende kahe arenguliini ühendamist: mitte pilve krüptoraha jaoks, vaid krüptograafilise võrgu põhimõtete laiendamist tarkvara kogu käituskeskkonnale.

Just selles võrdlusruumis muutub Internet Computer Protocoli tegelik ulatus nähtavaks.

Globaalne tarkvaramaastik: Web2, Web2.5, Web3 ja krüptopilv
Globaalne tarkvaramaastik: Web2, Web2.5, Web3 ja krüptopilv

Arvestusraamatust pilveprotokollini

ICP-d võib tehniliselt paigutada plokiahelate maailma, kuid sellest kategooriast üksi jääb selle mõistmiseks väheks. Selle arhitektuuriline eesmärk on laiendada protokolliliselt koordineeritud ja krüptograafiliselt kaitstud keskkond üldotstarbelise tarkvara käitamisele. Internet Computeri tänane ametlik suund nimetab ICP-d juba uueks pilvetehnoloogia pinuks: avatud matemaatiline võrk ühendab sõltumatult opereeritud arvutusmasinad pilveks, millel saab käitada veebiteenuseid, ettevõttetarkvara ja AIware’i.[1]

Tehniliselt on siin mõned olulised erinevused. ICP kasutab avatud WebAssembly ehk Wasm standardil põhinevat käituskeskkonda ning rakenduse põhiüksus on kanister. Kanister ühendab programmi koodi ja püsiva oleku üheks autonoomseks käitusüksuseks, mida replikeeritakse alamvõrgu sõlmede vahel. Rakendus saab säilitada ja töödelda andmeid, teenindada veebi ning suhelda teiste kanistritega ilma, et arendaja peaks samal kujul haldama eraldi rakendusserverit, operatsioonisüsteemi ja andmebaasiserverit.[1]

Püsivus on siin eraldi märkimist väärt, sest see näitab arhitektuuri suunda. ICP võimaldab rakenduse olekul kuuluda otseselt käituskeskkonda ning Motoko programmeerimiskeel toetab veel kaugemale minevat ortogonaalset püsivust, mille puhul programmi andmestruktuure saab säilitada üle tarkvarauuenduste ilma tavapärast andmebaasikihti rakenduse keskmesse ehitamata.[2] Tavalugeja jaoks ei ole termin ise oluline; oluline on põhimõte, et programm ja selle mälu võivad moodustada palju terviklikuma süsteemi.

Sama loogika ulatub ülejäänud infrastruktuuri. Rakenduse arendaja ei halda klassikalist serveri operatsioonisüsteemi, SSH-ligipääsu ega tulemüüri ning võrk ise tegeleb arvutuse replikeerimise ja suure osa töökindluse loogikaga. Identiteedilahendused nagu Internet Identity töötavad samas võrgukeskkonnas ning ICP sisseehitatud krüptograafia võimaldab tarkvaral suhelda ka teiste võrkudega. See ei tähenda, et kõik võimalikud infrastruktuuriteenused kaoksid, vaid et paljud tavapärase pilve tuumprobleemid liiguvad rakenduse juurest alusprotokolli tasandile.[1]

Siin toimub oluline kategooriavahetus: krüptograafiline usaldus liigub arvestusraamatust pilvetaristusse endasse. Küsimus ei ole enam ainult selles, kuidas paigutada rohkem tehinguid või nutilepinguid plokiahelasse, vaid selles, kas pilv ise saab olla internetiprotokolli laadne alus.

ICP ametlik nimi on Internet Computer Protocol. EFTI kasutab selle kõrval teadlikult ka nimetust Internet Cloud Protocol ehk interneti pilveprotokoll. See ei ole ettepanek protokolli ümber nimetada ega ametliku nimega konkureerida, vaid teadlik sõnamäng ja arhitektuuriline signaal. Viimastel aastatel on ka DFINITY ja Internet Computeri enda käsitlus liikunud järjest selgemalt pilve kui keskse kategooria poole: New Cloud Tech Stack, Cloud Engines, Open Cloud, sovereign cloud ja agentic cloud infrastructure.

Sõna „pilv“ aitab nähtavaks teha ICP tegelikku skoopi. Pilv ei ole siin üks funktsioon paljude seas, vaid kategooria, mis hõlmab kogu tarkvara käituskeskkonda. ICP ühendab arvutuse, püsiva oleku, võrgu, krüptograafia ja järjest enam ka intelligentse tarkvara üheks terviklikuks pilvepinuks. Internet Cloud Protocol on seetõttu EFTI jaoks lihtne signaal suuremale mõttele: ICP on pilv.

Selle taga ei ole lühiajaline tehnoloogiline eksperiment. ICP-d on arendatud ligikaudu kümme aastat ning DFINITY ja Pakistan Digital Authority 2026. aasta ühise teate järgi on DFINITY investeerinud teadus- ja arendustöösse üle poole miljardi dollari, avaldanud üle 1500 teadustöö ning koondanud hajutatud süsteemide, krüptograafia ja programmeerimiskeelte ekspertiisi.[5] Need arvud ei tõesta iseenesest ühe arhitektuuri tulevast edu, kuid aitavad mõista tehnoloogilise töö mastaapi.

Kui tarkvara muutub agentseks

Uue pilvetaristu tähendus ei seisne ainult aluses. Iga infrastruktuuri väärtus selgub lõpuks sellest, mida sellele ehitatakse, ning just siin muudab AI tarkvara enda olemust.

Traditsiooniline rakendus on suuresti ette kavandatud artefakt. Arendaja määrab andmemudeli, kasutajaliidese ja funktsioonid ning kasutaja tegutseb nende ette ehitatud võimaluste piires. AI muudab selle suhte paindlikumaks. Tarkvaraga saab suhelda loomulikus keeles, see võib mõista konteksti, leida ja muuta andmeid, kasutada tööriistu ning järjest enam inimese või organisatsiooni nimel tegutseda. Samal ajal saab AI ise tarkvara luua, täiendada, testida ja hallata.

Selles tähenduses muutub tarkvara elavamaks. Mitte bioloogiliselt ega tingimata teadvuslikuks, vaid oma toimimisviisilt. Valmis ja jäigalt määratud tootest liigume süsteemide poole, mida saab vestluse kaudu kujundada ning mis suudavad oma andmeid ja funktsioone kasutaja eesmärgi saavutamiseks paindlikult kombineerida. Iga võimaliku tegevuse jaoks ei pea enam tingimata ette ehitama eraldi nuppu, vormi või töövoogu. Graafilised kasutajaliidesed ei kao, kuid nende kõrvale tekib üldisem suhtluskiht: inimene saab järjest enam lihtsalt öelda, mida ta soovib teada või teha.

Siin saab AIware sisulise tähenduse. See ei ole lihtsalt senine tarkvara, mille kõrvale on lisatud juturobot, vaid tarkvara, mille funktsioonid, andmed ja õigused on AI-le piisavalt struktureeritult kättesaadavad, et agent saaks rakenduse sees päriselt tegutseda. Internet Computeri praegune pilvepinu on teadlikult kujundatud just sellise tarkvara jaoks: agent võib olla korraga rakenduse ehitaja, haldaja ja kasutaja.[1]

See muudab ka ettevõttetarkvara võimalikku kuju. Open Cloudi arendatav OpenSaaS on selle üks varajane näide: eesmärk on tuua raamatupidamine, personal, kulud, CRM, projektid, kalender ja teised tavapärased ärifunktsioonid ühe avatud AIware’i terviku alla. Agent saab kasutaja õiguste piires liikuda üle eri funktsioonide ja andmete, samal ajal kui inimene ei pea iga tegevuse jaoks avama eraldi rakendust ja läbima eelnevalt ehitatud töövoogu. OpenSaaS on veel kujunemisjärgus, kuid selle tähendus on arhitektuuriline: ettevõttetarkvara võib liikuda eraldiseisvate kasutajaliideste kogumist üha rohkem suhtluspõhise ja agentse süsteemi suunas.[4]

Siit tekib ka mõiste agentne pilvetaristu. AI ei ole enam ainult rakenduse sees olev funktsioon, vaid hakkab osalema kogu tarkvaratsüklis: tarkvara loomises, uuendamises, opereerimises ja kasutamises. Kui infrastruktuuri hakkab järjest enam haldama masinagent, muutub väga oluliseks, kui palju eraldiseisvaid süsteeme, võtmeid, servereid ja konfiguratsioone talle üldse usaldada tuleb.

Võimekam tarkvara vajab tugevamat alust

Sama AI, mis võimaldab tarkvara kiiremini ehitada ja kaitsta, muudab võimekamaks ka selle ründamise. Ühendkuningriigi National Cyber Security Centre hindab, et AI muudab lähiaastatel küberrünnete erinevad etapid tõhusamaks, eriti haavatavuste avastamise ja ärakasutamise, ning võib suurendada nii rünnete sagedust kui intensiivsust.[3]

See toob tänapäevase tarkvarapinu killustatuse teravamalt esile. Üks rakendus võib sõltuda kümnetest teenustest, võtmetest, administraatorikontodest, andmebaasiseadetest, võrgureeglitest ja integratsioonidest. Iga komponent võib eraldi olla hästi kaitstud, kuid iga lisakiht on ka uus koht, mida tuleb õigesti seadistada, uuendada, jälgida ja usaldada. AI ei loonud neid probleeme, kuid kiirendab korraga nii meie võimet süsteeme hallata kui ka nende nõrkusi leida.

Krüptopilv ei ole siin võluvits. Agent võib kirjutada halva äriloogika, anda valesid õigusi või teha ohtliku otsuse ning protokoll ei muuda vigast programmi õigeks. Samuti loeb jätkuvalt, kes saab rakendust uuendada ja milline on selle juhtimismudel. Uue aluse tähendus seisneb selles, et märkimisväärne osa tavapärase pilve infrastruktuursest keerukusest saab liikuda rakendusest alusprotokolli tasandile.

See erinevus on praktiline. Kui rakenduse jaoks ei ole vaja samal kujul hallata serveri operatsioonisüsteemi, SSH-ligipääsu, eraldi andmebaasiserverit, tulemüüri, koormusjaoturit ja suurt hulka nendevahelisi konfiguratsioone, võib nii infrastruktuurne ründepind kui ka halduskulu oluliselt väheneda. Internet Computeri serverivaba mudel ongi üles ehitatud nii, et kood ja olek töötavad replikeeritud keskkonnas ning arendaja või agent peab haldama vähem liikuvaid osi.[1]

See ei kõrvalda riski, vaid muudab riski asukohta. Rohkem vastutust liigub rakendusloogikale, õigustele, juhtimisele ja protokollile endale, samal ajal kui suur osa klassikalise pilve operatsioonilisest keerukusest kaob arendaja vaateväljast. Agentse tarkvara ajastul on see märgiline, sest mida suurema autonoomia me tarkvarale anname, seda vähem soovime selle alla käsitsi kokku ühendatud ja raskesti kontrollitavaid infrastruktuurikihte.

Andmeresidentsusest arhitektuurilise suveräänsuseni

Pilvesuveräänsus ei ole enam abstraktne tulevikuteema. Sellest on saanud reaalne hangete, regulatsiooni ja digitaalse infrastruktuuri küsimus. 2026. aastal avas AWS eraldi European Sovereign Cloudi, Euroopa Komisjon sõlmis EL-i institutsioonidele kuni 180 miljoni euro väärtuses suveräänse pilve hankeraamistiku ning on loonud ka laiema Cloud Sovereignty Frameworki, mis hindab suveräänsust juriidilise, operatiivse, tehnoloogilise, turvalisuse, tarneahela ja teiste mõõtmete kaudu.[11][13a][13b]

See areng näitab, et muutumas on ka sõna „suveräänne“ tähendus. Andmete hoidmine oma riigis või Euroopa Liidus on oluline, kuid andmeresidentsus üksi ei loo täielikku tehnoloogilist suveräänsust. Sama olulised on küsimused, kes infrastruktuuri tegelikult opereerib, millise jurisdiktsiooni alla teenusepakkuja kuulub, kui sõltuv on süsteem ühest ettevõttest ja tehnoloogilisest pinust ning kas klient saab aluskomponente päriselt kontrollida või vajadusel välja vahetada. Euroopa Komisjoni enda uus suveräänsusraamistik vaatabki serveri asukohast kaugemale ning käsitleb muu hulgas operatiivset autonoomiat, tehnoloogilist avatust, tarneahelat ja pikaajalist sõltumatust.[13a]

Jurisdiktsioon muudab selle erinevuse eriti nähtavaks. USA CLOUD Acti järgi võib USA jurisdiktsioonile alluvalt teenusepakkujalt kehtiva õigusliku menetluse alusel nõuda tema valduses või kontrolli all olevaid elektroonilisi andmeid sõltumata sellest, millises riigis need füüsiliselt paiknevad.[12] See ei tähenda, et USA ametiasutustel oleks piiramatu ligipääs Euroopa pilveandmetele, ega tee andmeresidentsust ebaoluliseks. See tähendab, et serveri füüsiline asukoht ei lahenda iseenesest küsimust, mis on ühtaegu juriidiline, ettevõtteline ja arhitektuuriline.

Ka traditsioonilised pilvepakkujad reageerivad sellele vajadusele sisuliselt. AWS European Sovereign Cloud on füüsiliselt ja loogiliselt eraldatud teistest AWS-i piirkondadest, tegutseb eraldiseisvate Euroopa juriidiliste üksuste kaudu ning selle igapäevane operatiivne kontroll on mõeldud paiknema Euroopa Liidus.[11] Need on reaalsed sammud suurema andmeresidentsuse, operatiivse autonoomia ja jurisdiktsioonilise kontrolli suunas.

Samas toob see esile ühe sügavama erinevuse. Suur osa tänasest suveräänse pilve liikumisest tugevdab geograafilisi, juriidilisi ja organisatsioonilisi kontrollikihte olemasoleva pilvemudeli ümber. Tarkvara alusloogika jääb suuresti samaks teenusepakkuja hallatavaks pilvepinuks, kus suveräänsus saavutatakse eelkõige ettevõttelise juhtimise, ligipääsukontrolli, lepinguliste garantiide ja tehnilise eraldatuse kaudu.

ICP lisab sellele arutelule veel ühe võimaliku kihi: arhitektuurilise suveräänsuse. Küsimus ei ole enam ainult selles, kelle andmekeskuses tarkvara töötab, vaid selles, kui suure osa usaldusmudelist saab viia avatud ja kontrollitava protokolli enda sisse. Rakenduse kood ja püsiv olek saavad töötada replikeeritud käituskeskkonnas, samal ajal kui alusvõrgu sõlmed, operaatorid, geograafia ja replikatsioonimudel võivad olla seadistatud vastavalt avaliku võrgu, ettevõtte või riigi vajadustele.

See ei muuda suveräänsust absoluutseks ega kaota ära õigust, juhtimist või institutsionaalset usaldust. See muudab arhitektuuri, mille kaudu neid usaldusvorme realiseeritakse. Valik ei pea olema ainult „nende pilv“ või „meie pilv“. Tekib uus küsimus: kas pilv ise saab olla kontrollitav protokoll?

Üks pilveprotokoll, erinevad pilved

Just siin muutuvad ICP erinevad pilvemudelid eriti oluliseks. Sama pilveprotokoll ei pea eksisteerima ainult ühe globaalse avaliku võrgu kujul. Internet Computeri põhivõrk toimib avaliku internetipilvena, kus rakendused kasutavad ühist protokollilist arvutuskihti. Selle kõrvale on tekkinud pilvemootor ehk Cloud Engine: eraldatud ICP alamvõrk, mille arvutusressurss on konkreetse kliendi või organisatsiooni kasutuses.[1][4]

Pilvemootori omanik saab valida, millised sõlmed keskkonna moodustavad, kes neid opereerib, kus need geograafiliselt asuvad ja millist replikatsiooni kasutatakse. Sõlmed võivad paikneda organisatsiooni enda taristus, sõltumatute teenusepakkujate juures või ka olemasolevates suurtes pilvedes. Pilvemootor ise on konfiguratsioon, mitte üks konkreetne masin, mistõttu saab alusriistvara, teenusepakkujaid ja geograafiat muuta ilma rakenduse arhitektuuri ümber ehitamata.[4]

See eristus on oluline ka suveräänsuse mõistmiseks. Eraldatud pilvemootor ei anna automaatselt täpselt sama usaldusmudelit nagu võimalikult laialt hajutatud avalik võrk; selle eesmärk on anda organisatsioonile võimalus oma usalduspiirid teadlikult kujundada. Riik võib nõuda, et arvutus toimuks tema territooriumil ja valitud operaatorite riistvaral, pank võib valida reguleeritud teenusepakkujad ning ettevõte võib kombineerida enda ja väliste pakkujate arvutusressurssi. Protokolliline käituskeskkond jääb samaks, kuid kontroll selle füüsilise aluse üle muutub seadistatavaks.

Open Cloud ehk avatud pilv annab selliste pilvemootorite moodustamiseks ja haldamiseks kasutuskihi. Nii tekib ühe pilveprotokolli sees spekter globaalsest avalikust internetipilvest kuni ettevõtte või riigi tingimustele vastava eraldatud suveräänse krüptopilveni.[4] Avatus ja suveräänsus ei pea selles mudelis olema vastandid: ühine protokoll saab töötada erineva geograafia, operaatorite ja kontrollitasemega.

Sellest joonistub välja ka uue pilvepinu lihtne süsteemne kuju: interneti pilveprotokoll → suveräänne pilv → AIware → inimesed, ettevõtted ja riigid. Need ei ole eraldiseisvad tehnoloogiad, vaid üksteisele toetuvad kihid. Protokoll loob pilve, pilv loob keskkonna uut tüüpi tarkvarale ning tarkvara mõju jõuab lõpuks kõigi digitaalse maailma osalisteni.

Süsteemivaade: interneti pilveprotokoll, suveräänne pilv ja AIware
Süsteemivaade: interneti pilveprotokoll, suveräänne pilv ja AIware

Alus, mis ulatub inimesest riigini

Pilvetaristu eripära on, et sama alus puudutab väga erinevaid skaalasid, kuigi igaüks kogeb seda erinevalt. Tavakasutaja jaoks võib tulemuseks olla lihtsalt sõnumirakendus, digitaalne rahakott või isiklik AI ning infrastruktuur jääb nähtamatuks. Tarkvaralooja jaoks tähendab uus pinu võimalust ehitada terviklikumaid rakendusi väiksema operatsioonilise koormusega. Ettevõtte jaoks tulevad mängu süsteemide omand, turvalisus, halduskulu ja pilvepakkujast sõltuvus. Riigi ja rahvusvahelise organisatsiooni jaoks muutuvad samad tehnilised valikud juba digitaalse suveräänsuse, jurisdiktsiooni ja strateegilise vastupidavuse küsimusteks.

See ei tähenda, et ICP oleks iga töökoormuse jaoks parem kui küps traditsiooniline pilv või et olemasolevad süsteemid tuleks ümber ehitada. AWS-il, Azure'il, Google Cloudil ja teistel pilvedel on aastakümnetega loodud tohutu teenuste, oskuste ja tööriistade ökosüsteem. ICP eriline võimalus avaneb eelkõige seal, kus oluliseks saavad terviklik protokolliline käituskeskkond, väiksem infrastruktuurne killustatus, krüptograafiline kontrollitavus, agentne tarkvara või suurem suveräänsus.

Just sellistes skoopides hakkab tehnoloogia nüüd ka päriselt proovile jõudma. Pakistan Digital Authority ja DFINITY sõlmisid 2026. aastal kokkuleppe Pakistanile mõeldud suveräänse ICP pilvetaristu loomiseks. Pakistan Subnet on kavandatud hoidma tundlikku arvutust riigis ning koostöö esimeste projektide hulka kuulub riikliku sõnumirakenduse piloot ja AI-põhise tarkvara arendamine.[5]

Sama aasta augustis käivitasid UNDP ja DFINITY laiemat tüüpi partnerluse, mille eesmärk on katsetada suveräänset pilvetaristut ja AI-põhist tarkvara UNDP riigibüroodes, kodanikuühiskonna organisatsioonides ning koos valitsuste ja avalike institutsioonidega.[6] Esimese valitsustele suunatud etapi jaoks kavandati viis riiki, kus iga piloot lähtub konkreetsest avaliku sektori probleemist ja kus hinnatakse ka seda, millal selline infrastruktuur päriselt väärtust loob ning millal mitte.[7]

Need projektid ei tõesta veel, milliseks globaalne pilvetaristu lõpuks kujuneb. Nende tähendus on teistsugune: ICP arhitektuuri hakatakse katsetama tasandil, kus küsimus ei ole enam ainult krüptorakenduses, vaid organisatsiooni või riigi enda tarkvaralises aluses.

Eesti järgmine digitaalne hüpe

Eesti jaoks on see areng erilise tähendusega. Meie digitaalne edu ei tekkinud turu suurusest, vaid võimest võtta uusi aluslahendusi piisavalt vara tõsiselt ning siduda need toimivaks tervikuks. Tiigrihüpe ei tähendanud lihtsalt arvutite ostmist koolidesse; see aitas kujundada põlvkonna ja ühiskonna, mille jaoks internetist sai loomulik alus järgmisele digitaalsele arengule.

Krüptopilve mõte ei ole Eestis päris uus. 2024. aasta mais käsitles Eesti pikaajaline tarkvarapodcast Algorütm Internet Computerit ja krüptopilve episoodis kõneka pealkirjaga „Miks mitte keegi krüptopilvest aru ei saa?“.[14] Episoodi kirjeldus võttis toonase olukorra tabavalt kokku: ICP ja krüptopilv olid saatejuhtide senise tarkvarakogemusega võrreldes „parajalt teistmoodi maailm“. See oli aeg, mil ICP-d oli keeruline paigutada olemasolevatesse kategooriatesse. Plokiahela mõiste jäi selle ulatuse kirjeldamiseks kitsaks, samal ajal kui tavapärane pilv lähtus hoopis teisest arhitektuurilisest mudelist.

Vahepeal on muutunud nii tehnoloogia kui ka laiem tarkvaramaailm. ICP on liikunud järjest selgemalt tervikliku pilvepinu, pilvemootorite, suveräänse pilve ja agentse infrastruktuuri suunas. AI muudab samal ajal tarkvara loomist, kasutamist ja haldamist sellise kiirusega, et vajadus lihtsama, kontrollitavama ja agentidele sobiva aluse järele on muutunud palju nähtavamaks. See, mida oli mõni aasta tagasi raske olemasolevate tarkvarakategooriate kaudu seletada, asetub nüüd järjest loomulikumalt pilve, AI ja digitaalse suveräänsuse ühisesse arengusse.

Tänane TI-Hüpe ehk AI Leap on teadlikult kujundatud selle pärandi jätkuna. Programmi enda kirjeldus nimetab inspiratsiooniallikana 30 aasta tagust Tiigrihüpet ning keskendub sellele, kuidas Eesti haridussüsteem saaks tehisaru ajastuga sisuliselt kohaneda.[8] Selle kõrval on Eesti.ai juba laiem riiklik algatus, mille eesmärk on rakendada AI-d süsteemselt majanduses, avalikus sektoris ja ühiskonnas tervikuna.[9]

Eesti liigub samal ajal ka agentse tarkvara suunas. Eesti.ai nõukoda on käivitanud töö AI-agentide digitaalse identiteedi ja volituste mudeliga, mille eesmärk on võimaldada tarkvaral tulevikus inimese, ettevõtte või asutuse nimel tegutseda selgelt määratud õiguste piires, kontrollitavalt ja auditeeritavalt.[10] See on sisuliselt sama küsimus, millega tegeleb agentne pilvetaristu teisel kihil: kes tegutseb, kelle nimel, milliste õigustega ning millisele tehnoloogilisele alusele seda tegevust usaldatakse.

Kui soovime teha AI-ajastul uue digitaalse hüppe, ei ole seetõttu oluline ainult see, milliseid mudeleid või rakendusi kasutame. Sama oluline on küsida, millisele alusele me järgmise tarkvarakihi ehitame.

See ei tähenda, et X-tee, olemasolevad riiklikud pilved või muu Eesti digitaristu tuleks ICP vastu välja vahetada. X-tee lahendab turvalise andmevahetuse probleemi infosüsteemide vahel ning jääb oma rollis väärtuslikuks. Agentse tarkvara levik võib aga tuua selle kõrvale uue infrastruktuurse küsimuse: millistes tuleviku teenustes oleks väärtus ühisel, püsival ja krüptograafiliselt kontrollitaval käituskeskkonnal, kus tarkvara ja agendid saavad määratud õigustega tegutseda?

Just siin võiks krüptopilvel olla oma koht Eesti järgmises digitaalses arhitektuuris. Mõnes süsteemis võib õige valik olla tavapärane avalik pilv, mõnes olemasolev riiklik infrastruktuur ja mõnes uus protokolliline või suveräänne pilvemudel. EFTI jaoks ei ole oluline suruda kõike ühe tehnoloogia peale, vaid näha piisavalt vara, kus uus alus annab päriselt uue võimekuse.

Eesti on varem olnud tugev just selliste kihtide ühendamises. Me ei pea olema maailma suurim tehnoloogiaturg, et saada järgmise infrastruktuuri uurimis-, katsetamis- ja rakenduskohaks. Väikese digiriigi eelis võib olla võime liikuda tervikuna kiiremini ning siduda haridus, ettevõtlus, avalik sektor ja uus tehnoloogiline alus üheks toimivaks süsteemiks.

Pilv kui ühendav signaal

Interneti arengut saab selle vaate kaudu näha ühe suurema liikumisena. Web1 lõi avatud ülemaailmse võrgu ja informatsiooniruumi. Web2 pilv muutis interneti globaalseks tarkvarakeskkonnaks, kuid koondas suure osa taristust väheste teenusepakkujate ümber. Web3 krüpto tõi tagasi avatud võrgu, digitaalse omandi ja matemaatiliselt kontrollitava usalduse, kuid lisas enamasti uue spetsialiseeritud kihi olemasoleva pilve kõrvale.

Krüptopilv ühendab need arenguliinid. Selle keskne mõte on viia krüptograafilise võrgu omadused arvestusraamatust kogu tarkvara käituskeskkonda ning ühendada Web2 pilve kasutatavus ja ulatus Web3 avatud võrgu, omandi ja kontrollitavusega.

AI annab sellele arengule nüüd uue tähenduse. Tarkvara muutub paindlikumaks ja agentsemaks, inimene saab sellega üha rohkem lihtsalt suhelda ning AI saab tarkvara nii luua, hallata kui ka kasutada. Samal ajal teeb sama areng vana killustunud tarkvarapinu piirangud, halduskoormuse ja turvariskid teravamalt nähtavaks. Seetõttu kohtuvad ühes punktis nii võimalus kui vajadus uue aluse järele.

EFTI jaoks on Internet Computer Protocol oluline just selles tervikpildis. Mitte universaalse lahendusena kõikidele IT-probleemidele ega ühe plokiahelana teiste seas, vaid märgilise katsena laiendada interneti avatud protokollilist loogikat pilvele endale. Kui see areng õnnestub, ei ole selle skoop ühe krüptoturu või rakenduskategooria suurune, vaid ulatub sinna, kus töötab peaaegu kogu digitaalne maailm: pilvetaristusse. Mida võimekamaks muutub tarkvara, seda olulisemaks muutub pilv, millele me selle ehitame.

Uus tehnoloogiapinu: interneti pilveprotokoll, suveräänne pilv, AIware ja agentne ühiskond
Uus tehnoloogiapinu: interneti pilveprotokoll, suveräänne pilv, AIware ja agentne ühiskond

ICP kogukonna joonised

Järgmised joonised on ICP kogukonnalt. Need vaatavad sama küsimust teise nurga alt: kus lõpeb arvestusraamat ja algab terve pilv, ning mida tähendab tarkvara, mis ei vaja selle kõrvale eraldi vana taristut.

Web 2.5 vs Web 3.0
Web 2.5 vs Web 3.0

Arvestusraamatud vs krüptopilv
Arvestusraamatud vs krüptopilv

Hübriid vs kõik ahelas
Hübriid vs kõik ahelas

Krüptopilv
Krüptopilv

Ehitades killustunud krüpto- ja pilvetaristul vs ICP krüptopilvel
Ehitades killustunud krüpto- ja pilvetaristul vs ICP krüptopilvel

Viited

  1. 1. Internet Computer. The New Cloud Tech Stack / Sovereign agentic infrastructure. Internet Computeri ametlik ülevaade ICP pilvepinust, kanistritest, WebAssemblyst, agentse infrastruktuuri käsitlusest ja AIware’ist.
  2. 2. DFINITY. A Journey into Stellarator: Part 2 — Motoko’s Enhanced Orthogonal Persistence. Tehniline ülevaade püsivast mälust ja Motoko ortogonaalsest püsivusest.
  3. 3. UK National Cyber Security Centre. Impact of AI on cyber threat from now to 2027. Hinnang AI mõjule haavatavuste leidmisele, ärakasutamisele ja küberrünnete skaalale.
  4. 4. Open Cloud. Sovereign Cloud Engines on the Internet Computer. Pilvemootorite, sõlmede valiku, replikatsiooni, OpenSaaS-i ja agentse käituskeskkonna ametlik kirjeldus.
  5. 5. Pakistan Digital Authority. Pakistan Digital Authority and DFINITY Partner for Sovereign Cloud Infrastructure and AI Software Systems. 10. veebruar 2026. Pakistan Subnet, riikliku sõnumirakenduse piloot ja kohaliku AI-taristu koostöö.
  6. 6. United Nations Development Programme. UNDP and DFINITY Foundation Collaborate on Exploring Sovereign Cloud Infrastructure and Decentralized AI Deployment for Public Good. 25. august 2026. UNDP riigibüroode, kodanikuühiskonna ja valitsustega tehtavate pilootide ametlik raamistik.
  7. 7. Axios. UN agency looks beyond Big Tech for AI. 25. august 2026. Täiendav info viie esialgse riikliku piloodi ja nende hindamise kohta.
  8. 8. TI-Hüpe. About AI Leap / TI-Hüpe. Programmi ametlik kirjeldus ja seos varasema Tiigrihüppega.
  9. 9. Riigikantselei. Eesti.ai algatus. Riikliku AI-programmi eesmärgid, juhtimine ja valdkondadeülene suund.
  10. 10. Riigikantselei. Michal: Eestist saab esimene riik maailmas, mis loob AI-agentidele digitaalse identiteedi. 17. juuni 2026. AI-agentide identiteedi, volituste ja auditeeritavuse kavandatav mudel.
  11. 11. Amazon Web Services. “Opening the AWS European Sovereign Cloud.” 14. jaanuar 2026.
  12. 12. U.S. Department of Justice. “The Purpose and Impact of the CLOUD Act” / CLOUD Act resources.
  13. 13a. European Commission. “Cloud Sovereignty Framework”. 1. juuni 2026. Euroopa Komisjoni suveräänsusraamistik, mis hindab suveräänsust juriidilise, operatiivse, tehnoloogilise, turvalisuse, tarneahela ja teiste mõõtmete kaudu.
  14. 13b. European Commission. Commission advances cloud sovereignty through strategic procurement. 17. aprill 2026. EL-i institutsioonide suveräänse pilve hankeraamistik.
  15. 14. Algorütm. „23.05 Algorütm: Miks mitte keegi krüptopilvest aru ei saa?“ Episood 237, 23. mai 2024.

Arutelu

Arutelu avaneb sisselogimisel. Ostu ei ole vaja.

Crypto Cloud: ICP as a Cloud Protocol and the Internet’s Next Software Foundation

We are living through a period of profound change in which several technological shifts are converging at once. Artificial intelligence is rapidly changing how software is created and used. Cryptographic networks have introduced new models of digital ownership and trust, while companies and governments are looking more closely at technological dependencies and digital sovereignty. These developments are not separate. Software has become one of the foundational layers of the economy, communication, education, business and government, which means that fundamental changes in software increasingly propagate throughout society.

Attention is understandably focused on AI because its effects are immediately visible. A single conversation can already be used to analyse data, write code, build an application or automate work that previously required people to perform it manually. Alongside this visible transformation, however, another shift is taking place at a deeper level: the foundation on which this new software runs is changing as well. The more capable, adaptive and autonomous software becomes, the more important the cloud beneath it becomes.

To an everyday user, the cloud may mean Google Drive, iCloud or simply a place where photos and documents are stored. In reality, cloud infrastructure is the computational foundation of much of the modern digital world. Web services, enterprise systems, databases, applications and increasingly AI itself run on it. The cloud has become so deeply embedded in software that users rarely see it, yet its architecture strongly determines how the digital world can be built, operated, secured and trusted.

From the Open Internet to the Cloud

The first major breakthrough of the Internet was open global connectivity. Shared protocols allowed different computers and networks to communicate without the entire system being controlled by a single company. The Web built a common information space on top of this foundation, and in the early Internet almost anyone could operate a server and become a direct participant in the network.

The next major infrastructural transformation of Web2 was not limited to better websites and user interfaces. One of its most important innovations was the cloud. Computing power, databases, storage and an expanding range of services became available on demand, without every software creator having to build and operate physical infrastructure. Small teams could create services used by millions of people, forming the foundation for SaaS, social networks, mobile services and much of today’s global software economy.

This success also created a deeper architectural tension. The connectivity layer of the Internet remained open and protocol-based, while a growing share of the software running on top of it moved into infrastructure controlled by a small number of large cloud providers. The software stack itself became increasingly layered: an application may depend on separate compute, databases, storage, authentication, APIs, key management, networking, security services and numerous external providers. The cloud made this complexity far easier to consume, but the cloud itself did not become an open protocol in the same way as the Internet beneath it.

Crypto + Cloud

Crypto introduced another important evolutionary line into the Internet. Bitcoin demonstrated that a shared digital ledger could be maintained without a single central record keeper. Cryptography, consensus and publicly verifiable rules made it possible to create digital money whose operation did not depend on one company’s database. Ethereum and subsequent networks extended the same principle to programmable agreements, digital assets and shared state.

The deeper significance of crypto therefore goes beyond tokens or a new asset class. It revived the open-network logic of the early Internet and added digitally enforceable ownership and stronger forms of verifiable trust. Yet most blockchains have remained centred primarily around shared state transitions: transactions, assets, permissions, contracts and other forms of recorded change.

From the perspective of full-stack software, much of Web3 therefore remained dependent on the Web2 cloud. A smart contract may run on an open cryptographic network while the user interface, files, indexing, RPC services, APIs and other application logic live elsewhere. Even in the case of an NFT, the token may exist on-chain while much of the underlying media is stored in a different system. Decentralized storage, compute and identity networks have enriched the landscape, but they can also make the architecture of a complete application more fragmented as more specialized networks and services are connected together.

This is where the idea of Crypto Cloud emerges. The Web2 cloud gave software extraordinary flexibility, usability and scale, while crypto introduced open networks, digital ownership and verifiable trust. Crypto + Cloud is the convergence of these two evolutionary paths: not a cloud for cryptocurrency, but the extension of cryptographic network principles to the entire software execution environment.

It is in this comparison space that the true scope of the Internet Computer Protocol becomes visible.

Global software landscape: Web2, Web2.5, Web3 and crypto cloud
Global software landscape: Web2, Web2.5, Web3 and crypto cloud

From the Ledger to a Cloud Protocol

ICP can technically be placed within the broader blockchain family, but that category alone is too narrow to explain what it is attempting to do. Its architectural objective is to extend a protocol-coordinated and cryptographically secured environment to general-purpose software execution. The Internet Computer is now explicitly positioned as a new cloud technology stack: an open mathematical network that combines independently operated machines into a cloud capable of running web services, enterprise software and AIware.[1]

Several technical differences matter here. ICP uses a runtime based on the open WebAssembly, or Wasm, standard, while the primary application unit is the canister. A canister combines program code and persistent state into an autonomous execution unit replicated across the nodes of a subnet. Applications can store and process data, communicate with other canisters and serve web applications directly without requiring developers to operate a traditional application server, operating system and database server in the same way.[1]

Persistence is worth noting because it illustrates the architectural direction. ICP allows persistent application state to be part of the runtime itself, while the Motoko programming language takes the model further through orthogonal persistence. This allows program data structures to persist across upgrades without requiring a conventional database layer to sit at the centre of the application architecture.[2] The technical term itself is not important for most users; the important idea is that the program and its memory can form a much more integrated system.

The same principle extends across the wider infrastructure. Application developers do not manage a traditional server operating system, SSH access or firewall in the usual way, while the network itself handles replicated computation and much of the underlying resilience. Identity systems such as Internet Identity operate within the same ecosystem, and ICP includes cryptographic capabilities that allow applications to interact securely with other networks. This does not mean that every possible infrastructure service disappears. It means that many core problems of the traditional cloud can move from the application layer into the underlying protocol.[1]

This represents an important change of category: cryptographic trust expands from the ledger into the cloud infrastructure itself. The question is no longer only how to place more transactions or smart contracts on a blockchain, but whether the cloud itself can become a protocol-level foundation of the Internet.

Internet Computer Protocol — and Internet Cloud Protocol

The official name of ICP is Internet Computer Protocol. EFTI also deliberately uses the term Internet Cloud Protocol alongside it. This is not an attempt to rename the protocol or compete with its official name. It is a deliberate wordplay and an architectural signal intended to make the scale of the technology easier to see.

Over recent years, DFINITY and the Internet Computer ecosystem itself have become increasingly aligned with the cloud as the central category: The New Cloud Tech Stack, Cloud Engines, Open Cloud, sovereign cloud and agentic cloud infrastructure are now part of the project’s own language and direction.[1][4]

The word cloud matters because it does not describe one ICP feature among many. It describes the category of infrastructure that ICP is attempting to reimagine. Compute, persistent state, networking, cryptography and increasingly intelligent software come together within one integrated cloud stack.

Internet Cloud Protocol is therefore an EFTI signal for a larger idea:

Seen this way, the comparison space changes completely. If ICP is considered only alongside other blockchains, much of its potential remains hidden. Once the category becomes cloud, the possible scope extends to the infrastructure beneath a significant share of global software.

This is not a short-lived technological experiment. ICP has been under development for roughly a decade, and according to a 2026 DFINITY and Pakistan Digital Authority announcement, more than half a billion dollars has been invested in research and development spanning distributed systems, cryptography, programming languages and network protocols.[5] Those figures do not by themselves prove the future success of one architecture, but they help illustrate the depth and scale of the underlying technical effort.

When Software Becomes Agentic

The significance of a new cloud infrastructure does not lie only in the infrastructure itself. The value of any foundation is ultimately determined by what can be built on top of it, and this is where AI begins to change the nature of software itself.

Traditional applications are largely predesigned artefacts. Developers define the data model, user interface and functions, while users operate within the possibilities that have been built in advance. AI makes this relationship more fluid. Software can be addressed in natural language, understand context, retrieve and modify data, use tools and increasingly act on behalf of a person or organization. At the same time, AI can increasingly create, extend, test and operate the software itself.

In this sense, software becomes more alive. Not biologically, and not necessarily conscious, but in the way it behaves. We are moving from fixed products toward systems that can be shaped through conversation and can flexibly combine their own data and capabilities to accomplish a user’s goal. Every possible action no longer needs to be represented by a separately designed button, form or workflow. Graphical interfaces will not disappear, but they can be complemented by a more universal interaction layer in which a person increasingly tells the software what they want to know or accomplish.

This gives AIware a more substantive meaning. It is not simply conventional software with a chatbot added to one corner of the interface. It is software whose functions, data and permissions are structured so that an AI agent can meaningfully act within the application. The current Internet Computer cloud stack is increasingly being designed around precisely this model: an agent can become a builder, operator and user of software within the same environment.[1]

This can also change the shape of enterprise software. OpenSaaS, currently being developed around Open Cloud, provides an early example of the direction. The idea is to bring accounting, HR, expenses, CRM, projects, calendars and other common business functions into a more open AIware environment. An agent could work across these functions within the user’s permissions, while the human would no longer need to manually move between a collection of separate SaaS interfaces for every task. OpenSaaS is still emerging, but the architectural direction is significant: enterprise software can evolve from a collection of isolated user interfaces toward a more conversational and agentic system.[4]

This is also where the idea of agentic cloud infrastructure becomes important. AI is no longer only a capability inside an application; it begins to participate throughout the software lifecycle, including creation, modification, operation and use. If infrastructure is increasingly operated by machine agents as well as humans, it becomes much more important how many separate servers, keys, databases, accounts and configurations those agents must be trusted to control.

More Capable Software Requires a Stronger Foundation

The same AI that allows software to be built and secured more quickly can also make attacking software more effective. The UK National Cyber Security Centre expects AI to increase the efficiency of multiple stages of cyber operations, particularly vulnerability discovery and exploitation, while increasing the scale and intensity of cyber activity.[3]

This makes the fragmentation of the modern software stack more consequential. A single application may depend on dozens of services, keys, administrator accounts, database configurations, network rules and integrations. Each component can individually be well secured, but every additional layer creates another place that must be configured, updated, monitored and trusted correctly. AI did not create these problems, but it accelerates both our ability to manage systems and our ability to find weaknesses within them.

Crypto Cloud is not a magic solution to this problem. An agent can still write poor business logic, grant the wrong permissions or make dangerous decisions, and a protocol cannot make an incorrect application correct. Governance and upgrade authority continue to matter. The deeper difference lies elsewhere: a significant share of traditional cloud infrastructure complexity can move from the application layer into the underlying protocol.

That difference is practical. If an application no longer requires the same separate management of a server operating system, SSH access, database server, firewall, load balancer and the configurations connecting all of these components, both the infrastructure attack surface and operational burden can be substantially reduced. The Internet Computer’s serverless model is designed around code and persistent state running together in a replicated environment, leaving developers and agents with fewer moving parts to manage.[1]

This does not eliminate risk; it changes where risk resides. More responsibility moves toward application logic, permissions, governance and the protocol itself, while much of the operational complexity of the traditional cloud disappears from the application developer’s field of responsibility. In an age of increasingly agentic software, this is significant: the more autonomy we give software, the less desirable it becomes to place beneath it a manually assembled maze of infrastructure components.

From Data Residency to Architectural Sovereignty

Cloud sovereignty is no longer an abstract concern. It is becoming a concrete procurement, regulatory and infrastructure question. In 2026, AWS opened its European Sovereign Cloud, while the European Commission awarded a sovereign-cloud procurement framework worth up to €180 million for EU institutions. The Commission has also introduced a Cloud Sovereignty Framework that evaluates sovereignty across legal, operational, technological, security, supply-chain and other dimensions.[11][13a][13b]

This development reveals an important shift in what “sovereign cloud” means. Keeping data inside a country or region is valuable, but data residency alone does not create full technological sovereignty. The deeper questions are who ultimately operates the infrastructure, which jurisdiction can reach the provider, how dependent the system remains on a particular vendor and technology stack, and whether the customer can meaningfully control or replace the underlying components. The European Commission’s own sovereignty framework now explicitly looks beyond server location toward operational autonomy, technological openness, supply-chain control and long-term independence.[13a]

Jurisdiction makes this distinction especially visible. Under the US CLOUD Act, a service provider subject to US jurisdiction can, through valid legal process, be required to produce electronic data within its possession, custody or control regardless of where that data is physically stored.[12] This does not mean that US authorities have unrestricted access to European cloud data, nor that European data residency is irrelevant. It means that the physical location of a server cannot by itself resolve a question that is also legal, corporate and architectural.

Traditional cloud providers are responding seriously to this demand. The AWS European Sovereign Cloud, for example, is physically and logically separated from other AWS regions, operates through dedicated European legal entities and places day-to-day operational control with personnel located in the EU.[11] These are meaningful advances in data residency, operational autonomy and jurisdictional control.

Yet they also reveal a deeper distinction. Much of today’s sovereign-cloud movement strengthens geographical, legal and organizational controls around the existing cloud model. The underlying software architecture remains largely the same provider-operated stack, with sovereignty expressed through corporate structures, access controls, contractual guarantees and technical isolation.

ICP introduces an additional layer to this discussion: architectural sovereignty. The question is no longer only whose data centre runs the software, but how much of the trust model itself can move into an open and verifiable protocol. Code and persistent state can run in a replicated execution environment, while the underlying nodes, operators, geography and replication model can still be configured according to the needs of a public network, enterprise or state.

This does not make sovereignty absolute, nor does it remove governance, law or institutional trust. It changes the architecture through which those forms of trust are expressed. Instead of choosing only between “their cloud” and “our cloud”, another question becomes possible: can the cloud itself become a verifiable protocol?

One Cloud Protocol, Different Clouds

This is where ICP’s different deployment models become especially relevant. The same cloud protocol does not need to exist only as one global public network.

The Internet Computer mainnet operates as a public Internet cloud, where applications use a shared protocol-based compute layer. Alongside it, Cloud Engine introduces an isolated ICP subnet whose compute resources are dedicated to a particular customer or organization.[1][4]

The owner of a Cloud Engine can select which nodes form the environment, who operates them, where they are geographically located and what replication level is used. Nodes can run in the organization’s own infrastructure, at independent providers or even inside existing hyperscale clouds. The Cloud Engine itself is a configuration rather than one particular machine, which means the underlying hardware, providers and geography can be changed without redesigning the application architecture.[4]

This distinction is important for understanding sovereignty. An isolated Cloud Engine does not automatically provide exactly the same trust model as the most widely distributed public network. Its purpose is to allow an organization to deliberately define its trust boundaries. A state may require computation to remain within its jurisdiction and on hardware operated by approved providers. A bank may choose regulated infrastructure operators. A company may combine its own hardware with independent providers and traditional cloud resources.

The protocol-level execution environment remains consistent while control over the physical infrastructure becomes configurable. Sovereignty therefore means more than simply saying that “the data is located in our country.” It also concerns who operates the compute, how it is replicated, which external dependencies exist and how easily the underlying hardware or infrastructure providers can be changed.

Open Cloud provides the management layer through which these Cloud Engines can be created and operated. This produces a spectrum within one cloud protocol, ranging from a global public Internet cloud to an isolated sovereign Crypto Cloud configured for the needs of a company, institution or country.[4] Openness and sovereignty do not have to be opposites: the same protocol can operate under different geographic, operational and control models.

This gives the emerging technology stack a simple systemic form:

Internet Cloud Protocol → Sovereign Cloud → AIware → People, Companies and Governments

These are not separate technologies. Each layer builds upon the one beneath it. The protocol creates the cloud; the cloud creates an environment for a new kind of software; and that software ultimately reaches every participant in the digital world.

System view: Internet cloud protocol, sovereign cloud and AIware
System view: Internet cloud protocol, sovereign cloud and AIware

A Foundation That Scales from the Individual to the State

The distinctive property of cloud infrastructure is that the same foundation can matter at very different scales, even though each participant experiences it differently. For an ordinary user, the result may simply be a messaging application, a digital wallet or a personal AI, while the underlying infrastructure remains invisible. For a software creator, the new stack can mean building more integrated applications with less operational overhead. For a company, questions of ownership, security, operating cost and dependence on individual cloud providers become more important. For states and international organizations, the same technical choices become questions of digital sovereignty, jurisdiction and strategic resilience.

This does not mean that ICP is superior to mature traditional clouds for every workload, or that existing systems should simply be rebuilt. AWS, Azure, Google Cloud and other platforms have accumulated enormous ecosystems of services, skills and tools over decades. The distinct opportunity for ICP appears where an integrated protocol-based runtime, reduced infrastructure fragmentation, cryptographic verifiability, agentic software or greater sovereignty become especially valuable.

It is precisely at these scales that the technology is beginning to be tested. In 2026, the Pakistan Digital Authority and DFINITY agreed to develop sovereign ICP cloud infrastructure for Pakistan. The planned Pakistan Subnet is intended to keep sensitive computation within the country, while early projects include a pilot for a national messaging service and locally operated AI software systems.[5]

In the same year, UNDP and DFINITY launched a broader partnership to explore sovereign cloud infrastructure and AI-based public-interest software through UNDP country offices, civil society organizations and cooperation with governments and public institutions.[6] The first government-focused phase has been described as involving five country pilots, each focused on a concrete public-sector problem and on evaluating where this form of infrastructure genuinely creates value and where it does not.[7]

These pilots do not prove what the dominant global cloud architecture will eventually become. Their significance is different: ICP is beginning to be tested at a scale where the question is no longer merely about a crypto application, but about the software foundation of organizations and states.

Estonia’s Next Digital Leap

For Estonia, this development has particular significance. The country’s digital success did not emerge from the size of its market, but from its ability to take new foundational technologies seriously early enough and combine them into functioning systems. The original Tiger Leap was not simply about buying computers for schools. It helped shape a generation and a society for which the Internet became a natural foundation for further digital development.

The idea of Crypto Cloud is not entirely new in Estonia. In May 2024, the long-running Estonian software podcast Algorütm discussed the Internet Computer and Crypto Cloud in an episode with the revealing title “Miks mitte keegi krüptopilvest aru ei saa?” — “Why Does Nobody Understand Crypto Cloud?”[14] The episode description captured the situation at the time well: ICP and Crypto Cloud represented “quite a different world” compared with the hosts’ previous experience in software. It was a time when ICP was difficult to place within the categories that already existed. “Blockchain” was too narrow to describe its architectural scope, while the conventional cloud was based on a very different model.

Since then, both the technology and the wider software environment have changed. ICP has moved increasingly clearly toward a complete cloud stack, Cloud Engines, sovereign cloud and agentic infrastructure. At the same time, AI is transforming the creation, use and operation of software so rapidly that the need for a simpler, more verifiable and agent-ready foundation has become far easier to see. What was difficult to explain through established software categories only a few years ago now fits increasingly naturally into the convergence of cloud infrastructure, AI and digital sovereignty.

Today’s AI Leap, or TI-Hüpe, is explicitly framed as a continuation of that legacy. The programme draws inspiration from the Tiger Leap of roughly three decades ago and focuses on helping the Estonian education system adapt meaningfully to the age of AI.[8] Alongside it, Eesti.ai is a broader national initiative aimed at systematically applying AI across the economy, public sector and society.[9]

Estonia is also moving toward an agentic software environment. Work is underway on a model for digital identity and delegated authority for AI agents, with the goal of allowing software to act on behalf of a person, company or institution within clearly defined permissions and with auditable accountability.[10] At another layer, this is the same fundamental question addressed by agentic cloud infrastructure: who is acting, on whose behalf, with which permissions, and on what technological foundation that activity can be trusted.

If Estonia wants to make another digital leap in the AI era, the question therefore cannot be limited to which models or applications should be adopted. It is equally important to ask what foundation the next software layer should be built upon.

This does not mean replacing X-Road, existing government clouds or Estonia’s current digital infrastructure with ICP. X-Road solves the problem of secure data exchange between information systems and remains valuable in that role. The rise of agentic software may, however, introduce an additional infrastructural question: in which future services would there be value in a shared, persistent and cryptographically verifiable runtime where software and agents can act under clearly defined permissions?

This is where Crypto Cloud may have a role within Estonia’s next digital architecture. In some systems, the right choice may remain a traditional public cloud; in others, existing national infrastructure; and in some, a new protocol-based or sovereign cloud model. EFTI’s interest is not in forcing everything onto one technology, but in seeing early enough where a new foundation provides a genuinely new capability.

Estonia has historically been strong precisely at connecting such layers. It does not need to be the world’s largest technology market to become a meaningful place for researching, testing and deploying the next generation of digital infrastructure. The advantage of a small digital state may lie in its ability to move coherently and connect education, business, the public sector and a new technological foundation into one functioning system.

Cloud as the Connecting Signal

The evolution of the Internet can be seen through this lens as one larger movement. Web1 created an open global network and information space. The Web2 cloud turned the Internet into a global software environment, while concentrating much of the underlying infrastructure in a small number of providers. Web3 crypto brought back open networks, digital ownership and mathematically verifiable trust, but largely added a new specialized layer beside the existing cloud.

Crypto Cloud connects these evolutionary paths. Its core idea is to extend the properties of cryptographic networks from the ledger into the entire software execution environment, combining the usability and scale of the Web2 cloud with the openness, ownership and verifiability of Web3.

AI now gives this development a new meaning. Software is becoming more adaptive and agentic; people can increasingly communicate with it directly, while AI can create, operate and use software itself. At the same time, this development makes the limitations, operational burden and security risks of fragmented software stacks increasingly visible. Opportunity and necessity therefore begin to converge around the need for a stronger foundation.

For EFTI, the Internet Computer Protocol is important within this larger picture. Not as a universal solution to every IT problem, and not merely as one blockchain among many, but as a significant attempt to extend the open protocol logic of the Internet into the cloud itself. If that direction succeeds, its scope is not limited to one crypto market or one category of application. It reaches the layer beneath almost the entire digital world:

the cloud infrastructure itself.

The more capable software becomes, the more important the cloud on which we build it becomes.

New technology stack: Internet cloud protocol, sovereign cloud, AIware and an agentic society
New technology stack: Internet cloud protocol, sovereign cloud, AIware and an agentic society

Drawings from the ICP community

The following drawings come from the ICP community. They look at the same question from another angle: where the ledger ends and a full cloud begins, and what it means when software no longer needs a separate legacy stack beside it.

Web 2.5 vs Web 3.0
Web 2.5 vs Web 3.0

Ledgers vs crypto cloud
Ledgers vs crypto cloud

Hybrid vs all on-chain
Hybrid vs all on-chain

Crypto cloud
Crypto cloud

Building on fragmented crypto and cloud infrastructure vs the ICP crypto cloud
Building on fragmented crypto and cloud infrastructure vs the ICP crypto cloud

References

  1. 1. Internet Computer. The New Cloud Tech Stack / Sovereign Agentic Infrastructure. Official overview of the ICP cloud stack, canisters, WebAssembly, sovereign infrastructure and AIware.
  2. 2. DFINITY. A Journey into Stellarator: Part 2 — Motoko’s Enhanced Orthogonal Persistence. Technical overview of persistent memory and orthogonal persistence in Motoko.
  3. 3. UK National Cyber Security Centre. Impact of AI on cyber threat from now to 2027. Assessment of AI’s impact on vulnerability discovery, exploitation and the scale of cyber activity.
  4. 4. Open Cloud. Sovereign Cloud Engines on the Internet Computer. Official description of Cloud Engines, infrastructure selection, replication, OpenSaaS and agentic cloud infrastructure.
  5. 5. Pakistan Digital Authority / DFINITY Foundation. Pakistan Digital Authority and DFINITY Partner for Sovereign Cloud Infrastructure and AI Software Systems. 2026.
  6. 6. United Nations Development Programme. UNDP and DFINITY Foundation Collaborate on Exploring Sovereign Cloud Infrastructure and Decentralized AI Deployment for Public Good. 2026.
  7. 7. Axios. UN agency looks beyond Big Tech for AI. 2026. Supporting reporting on the initial five government pilots.
  8. 8. TI-Hüpe / AI Leap. Official programme description and its connection to Estonia’s original Tiger Leap.
  9. 9. Government Office of Estonia. Eesti.ai initiative. National framework for the systematic adoption of AI.
  10. 10. Government Office of Estonia. Announcement on the development of digital identity and delegated authority for AI agents. 2026.
  11. 11. Amazon Web Services. “Opening the AWS European Sovereign Cloud.” 14 January 2026.
  12. 12. U.S. Department of Justice. “The Purpose and Impact of the CLOUD Act” / CLOUD Act resources.
  13. 13a. European Commission. “Cloud Sovereignty Framework”. 1 June 2026. Framework for assessing sovereignty across legal, operational, technological, security, supply-chain and other dimensions.
  14. 13b. European Commission. Commission advances cloud sovereignty through strategic procurement. 17 April 2026. Sovereign-cloud procurement framework for EU institutions.
  15. 14. Algorütm. “23.05 Algorütm: Miks mitte keegi krüptopilvest aru ei saa?” Episode 237, 23 May 2024.

Discussion

Discussion opens when you sign in. No purchase required.