Hva er JavaScript-smartkontrakter

Hva er JavaScript-smartkontrakter. Er programmer som automatiserer regler og transaksjoner på en blokkjede eller annen distribuert hovedbok, og som helt eller delvis er skrevet i JavaScript eller TypeScript. De kan blant annet brukes til betalinger, handel med digitale eiendeler, utlån, styring av organisasjoner, spill, markedsplasser og automatisert datadeling.

Begrepet må brukes presist. På enkelte plattformer kjører en sikkerhetsbegrenset versjon av JavaScript direkte som smartkontrakt. På andre plattformer blir JavaScript- eller TypeScript-koden kompilert til WebAssembly før den distribueres. JavaScript brukes også ofte utenfor blokkjeden til å kommunisere med smartkontrakter som egentlig er skrevet i Solidity, Rust eller et annet språk.

JavaScript-smartkontrakter er viktige fordi JavaScript er et av verdens mest utbredte programmeringsspråk. Teknologien kan derfor gjøre blokkjedebasert utvikling tilgjengelig for flere utviklere. Samtidig kan ikke vanlig nettleser- eller Node.js-kode uten videre flyttes til en blokkjede. Smartkontrakter krever deterministisk kjøring, strenge ressursgrenser, sikker håndtering av verdier og kontroll med hvilke systemfunksjoner programmet får bruke.

Viktige punkter

• En JavaScript-smartkontrakt er programlogikk skrevet i JavaScript eller TypeScript som kjøres i et blokkjedesystem eller distribuert register.
• JavaScript brukes ikke på samme måte på alle plattformer. Koden kan kjøres i et begrenset JavaScript-miljø, kompileres til WebAssembly eller kjøres som Node.js-basert chaincode.
• Solidity er ikke JavaScript, selv om språkene har enkelte syntaktiske likheter.
• JavaScript-biblioteker som ethers.js brukes normalt til å kommunisere med Ethereum-kontrakter, ikke til å kjøre JavaScript som kontraktskode i Ethereum Virtual Machine.
• Smartkontrakter må være deterministiske, slik at alle noder kommer frem til samme resultat.
• Vanlige funksjoner som Date.now(), Math.random(), fetch() og direkte filtilgang er normalt utilgjengelige eller strengt kontrollert.
• Pengebeløp bør behandles med heltall, BigInt eller plattformens egne beløpstyper, ikke vanlige flyttall.
• JavaScripts store pakkeøkosystem gir høy utviklingshastighet, men skaper også risiko knyttet til avhengigheter og programvareforsyningskjeden.
• Smartkontraktens programmeringsspråk avgjør ikke hvilke lover som gjelder. Reguleringen avhenger av tjenesten, eiendelen, databehandlingen og den økonomiske aktiviteten.
• Feil i en distribuert smartkontrakt kan få irreversible eller svært kostbare konsekvenser.

Hva betyr JavaScript Smart Contracts?

Uttrykket brukes vanligvis om smartkontrakter der hele eller deler av forretningslogikken utvikles i JavaScript eller TypeScript. En smartkontrakt er i denne sammenhengen et program som lagrer tilstand og utfører forhåndsdefinerte handlinger når det mottar en gyldig transaksjon eller melding.

En smartkontrakt kan for eksempel kontrollere at en bruker har tilstrekkelig saldo, overføre en digital eiendel, registrere en stemme eller beregne hvordan midler skal fordeles. Nettverket kontrollerer utførelsen etter plattformens konsensus- og valideringsregler.

[Intern lenke: Hva er en smartkontrakt?]

Begrepet kan bety tre forskjellige ting

Det er nyttig å skille mellom tre former for JavaScript-basert blokkjedekode:

Form	Hvor kjører JavaScript?	Eksempel
JavaScript som kontraktskode	I et begrenset eller herdet kjøremiljø på plattformen	Agoric
JavaScript kompilert til et annet format	Koden kompileres før distribusjon	JavaScript til WebAssembly på NEAR
JavaScript som klientkode	Utenfor blokkjeden, for eksempel i en nettleser eller server	ethers.js som kommuniserer med Ethereum-kontrakter

Bare de to første kategoriene er JavaScript-smartkontrakter i streng forstand. Den tredje kategorien er en desentralisert applikasjon eller integrasjon som bruker JavaScript til å kalle en kontrakt skrevet i et annet språk.

Er Solidity det samme som JavaScript?

Nei. Solidity er et eget, statisk typet programmeringsspråk utviklet for Ethereum Virtual Machine. Språket er påvirket av blant annet JavaScript, C++ og Python, men Solidity-kode kompileres til EVM-bytecode og følger helt andre regler enn JavaScript.

Ethereum støtter JavaScript-biblioteker som kan lese kontraktens ABI, sende transaksjoner og kalle kontraktsfunksjoner. Dette betyr ikke at Ethereum kjører JavaScript som ordinær smartkontraktskode. De mest aktive smartkontraktspråkene i Ethereum-økosystemet er Solidity og Vyper.

Hvordan fungerer JavaScript-smartkontrakter?

En JavaScript-smartkontrakt går normalt gjennom følgende livssyklus:

1. Utvikleren skriver kontraktslogikken.
2. Koden testes, pakkes eller kompileres i plattformens utviklingsverktøy.
3. Kontrakten installeres eller distribueres til nettverket.
4. Kontrakten får en identifikator, konto, adresse eller installasjonsreferanse.
5. En bruker eller en annen kontrakt sender en transaksjon eller melding.
6. Nettverkets noder utfører eller validerer kontraktslogikken.
7. Gyldige tilstandsendringer registreres i hovedboken.
8. Kontrakten kan produsere kvitteringer, hendelser eller meldinger til andre kontrakter.

En smartkontrakt våkner normalt ikke av seg selv. Den må utløses av en transaksjon, en melding, en planleggingstjeneste eller en ekstern aktør som sender en transaksjon. På NEAR kan kontrakter eksempelvis ikke foreta vanlige HTTP-kall eller kjøre automatisk uten å bli kalt.

Hvorfor må utførelsen være deterministisk?

Deterministisk utførelse betyr at samme kode, starttilstand og input alltid skal gi samme resultat. Dette er nødvendig fordi flere noder må kunne kontrollere den samme transaksjonen og bli enige om den nye tilstanden.

Vanlig JavaScript inneholder funksjoner som kan gi forskjellige resultater på forskjellige maskiner. Eksempler er lokal systemtid, tilfeldig generering, nettverkskall og tilgang til operativsystemet. En smartkontraktplattform må derfor fjerne, erstatte eller kontrollere slike funksjoner.

Agorics Hardened JavaScript-miljø gjør eksempelvis Math.random() og Date.now() utilgjengelige i standardkonfigurerte compartments. Nettleser- og Node.js-funksjoner som window, document, process, fetch, require og lokal lagring er heller ikke automatisk tilgjengelige.

Hvordan lagres kontraktens tilstand?

Tilstand er informasjon som skal bevares mellom transaksjoner. Det kan være saldoer, eierskap, aktive tilbud, stemmer, priser eller tilgangsrettigheter.

Lagringsmodellen varierer mellom plattformene. På NEAR er kontrakten knyttet til en konto og kan lagre data i kontoens tilstand. Agoric bruker blant annet vedvarende objekter og plattformtjenester for å bevare kontraktstilstand. Hyperledger Fabric-kontrakter leser og oppdaterer registertilstanden gjennom transaksjoner.

Utvikleren kan derfor ikke anta at en vanlig JavaScript-variabel, database eller Map oppfører seg likt på alle plattformer. Plattformens egne lagringsmekanismer og serialiseringsregler må brukes.

Hva er gas og ressursmåling?

Offentlige blokkjeder må begrense hvor mye prosessortid, lagring og andre ressurser en transaksjon kan bruke. Ellers kunne en kontrakt inneholde en uendelig løkke eller tvinge alle noder til å utføre svært kostbare beregninger.

Mange plattformer bruker gas eller en tilsvarende måleenhet. Brukeren betaler for ressursene transaksjonen krever, og utførelsen avbrytes dersom grensen overskrides. Ressursmodellen påvirker hvordan JavaScript-koden bør struktureres. Store løkker, voksende datastrukturer og omfattende serialisering kan gjøre kontrakten dyr eller umulig å kjøre.

Hvor kan JavaScript-smartkontrakter brukes?

JavaScript-smartkontrakter er ikke knyttet til én bestemt blokkjede. Plattformene bruker imidlertid svært forskjellige sikkerhets-, konsensus- og kjøremodeller.

Plattform	JavaScript-modell	Nettverkstype	Viktig særtrekk
Agoric	Hardened JavaScript i isolerte miljøer	Offentlig Cosmos-basert blokkjede	Objektkapabiliteter, Zoe og asynkron kommunikasjon
NEAR	JavaScript eller TypeScript kompileres til WebAssembly	Offentlig blokkjede	Konto- og lagringsmodell med asynkrone kontraktskall
Hyperledger Fabric	Node.js-basert chaincode	Tillatelsesbasert distribuert register	Organisasjoner avtaler regler og godkjenningspolicy
Ethereum	JavaScript brukes hovedsakelig utenfor kjeden	Offentlig blokkjede	Kontraktene skrives normalt i Solidity eller Vyper

Agoric og Hardened JavaScript

Agoric er en Cosmos-basert blokkjede der smartkontrakter kan utvikles med en sikkerhetsbegrenset variant av JavaScript. Plattformen bruker Secure ECMAScript-teknologi, compartments og objektkapabiliteter for å kontrollere hvilke ressurser et program får tilgang til.

En objektreferanse fungerer som en tillatelse. Kontrakten skal bare få de rettighetene den faktisk trenger, i tråd med prinsippet om minste myndighet. Funksjonen harden() brukes til å gjøre objekter motstandsdyktige mot senere endringer, mens globale objekter og innebygde prototyper låses ned.

Agorics Zoe-rammeverk er laget for handel og utveksling av digitale eiendeler. Brukere beskriver hva de vil gi og motta, mens Zoe kontrollerer at omfordelingen følger tilbudsbetingelsene og bevarer eiendelene. Plattformen omtaler dette som blant annet «offer safety».

NEAR og JavaScript kompilert til WebAssembly

NEAR lar utviklere skrive smartkontrakter i blant annet JavaScript og Rust. Uavhengig av kildespråket kompileres kontrakten til WebAssembly før den distribueres og kjøres på plattformen.

NEARs dokumentasjon anbefaler Rust for produksjonskontrakter som håndterer reelle verdier, fordi Rust-verktøyene er mer modne og gir sterkere sikkerhetsgarantier. JavaScript-SDK-en beskrives som særlig egnet for læring og prototyper. Dette viser at støtte for et språk ikke nødvendigvis betyr at språket er plattformens anbefalte valg for alle risikonivåer.

Hyperledger Fabric og Node.js-chaincode

Hyperledger Fabric er utviklet for tillatelsesbaserte nettverk der kjente organisasjoner samarbeider. Smartkontrakter distribueres i pakker som kalles chaincode. Chaincode kan skrives i Go, Java eller Node.js.

JavaScript-koden kjører i en separat prosess og bruker Fabric-grensesnittet til å lese og oppdatere registertilstanden. Nettverkets organisasjoner kan fastsette en endorsement policy som bestemmer hvilke deltakere som må godkjenne en transaksjon før den blir gyldig.

Et forenklet eksempel

Følgende pseudokode viser den grunnleggende logikken i en kontrakt som overfører en intern saldo:

const balances = new Map();

export const transfer = ({ sender, recipient, amount }) => {
  assert(typeof sender === "string");
  assert(typeof recipient === "string");
  assert(typeof amount === "bigint");
  assert(amount > 0n);

  const senderBalance = balances.get(sender) ?? 0n;
  assert(senderBalance >= amount);

  balances.set(sender, senderBalance - amount);

  const recipientBalance = balances.get(recipient) ?? 0n;
  balances.set(recipient, recipientBalance + amount);

  return {
    senderBalance: balances.get(sender),
    recipientBalance: balances.get(recipient),
  };
};

Eksemplet illustrerer validering, heltallsberegning og atomisk oppdatering av to saldoer. Det er ikke en komplett kontrakt som kan distribueres direkte. En virkelig implementasjon må bruke plattformens lagringsmodell, autentisering, transaksjonskontekst, tilgangskontroll, feilmodell og ressursmåling.

Hva brukes JavaScript-smartkontrakter til?

Desentralisert finans

Smartkontrakter kan automatisere bytte av tokens, sikkerhetsstillelse, utlån, renteberegning, likviditetsbassenger, derivater og fordeling av gebyrer.

[Intern lenke: Hva er DeFi?]

Tokens og digitale eiendeler

En kontrakt kan registrere eierskap, kontrollere overføringer og implementere regler for fungible tokens eller NFT-er.

[Intern lenke: Hva er en token?]

[Intern lenke: Hva er en NFT?]

Markedsplasser og escrow

Kontrakten kan holde digitale eiendeler midlertidig og frigjøre dem når bestemte vilkår er oppfylt. Dersom vilkåret avhenger av en fysisk levering eller annen hendelse utenfor blokkjeden, kreves det normalt en betrodd datakilde.

Styring og desentraliserte organisasjoner

JavaScript-smartkontrakter kan registrere forslag, stemmer, fullmakter og beslutninger i en desentralisert autonom organisasjon.

[Intern lenke: Hva er en DAO?]

Spill og digitale verdener

Kontrakter kan administrere gjenstander, poeng, turneringer, medlemskap og andre digitale rettigheter. Tilfeldighet må leveres gjennom en sikker mekanisme og kan ikke baseres på vanlig Math.random().

Forsyningskjeder og bedriftsnettverk

Tillatelsesbaserte løsninger som Hyperledger Fabric kan brukes når flere bedrifter vil dele et transaksjonsregister, men samtidig kontrollere identiteter, tilgang og godkjenningsregler.

Kommunikasjon mellom blokkjeder

JavaScript-baserte kontrakter kan også koordinere operasjoner på tvers av flere nettverk. Agoric har eksempelvis utviklet verktøy for asynkron orkestrering av tjenester og eiendeler mellom kjeder.

Kilde: https://docs.agoric.com/guides/orchestration/

Hvilke fordeler har JavaScript-smartkontrakter?

Et stort utviklermiljø

Mange utviklere kjenner allerede JavaScript, TypeScript, moduler, testverktøy og asynkron programmering. Dette kan redusere terskelen for å begynne med smartkontraktutvikling.

Felles språk i hele applikasjonen

En løsning kan i enkelte tilfeller bruke JavaScript eller TypeScript i brukergrensesnittet, serverkomponentene, testene og kontraktslaget. Det kan gjøre det enklere å dele datatyper, utviklingsverktøy og kompetanse.

Moden verktøykjede

JavaScript-økosystemet har omfattende støtte for testing, statisk analyse, pakkehåndtering, kontinuerlig integrasjon og utviklingsmiljøer.

Asynkron programmeringsmodell

JavaScripts løfter og meldingsbaserte mønstre kan passe godt i distribuerte systemer der svar fra andre kontrakter eller kjeder ikke kommer umiddelbart.

Fleksibel objektmodell

JavaScripts objekter, closures og funksjoner kan brukes til å bygge modulære grensesnitt. I objektkapabilitetssystemer kan referanser samtidig fungere som avgrensede tillatelser.

Hvilke ulemper har JavaScript-smartkontrakter?

Dynamisk typing

JavaScript kontrollerer mange typer først under kjøring. En verdi som utvikleren forventer er et tall, kan i stedet være en streng eller et objekt. TypeScript kan oppdage en del feil under utvikling, men typene finnes normalt ikke som sikkerhetskontroller under selve kjøringen.

Alle data som kommer fra brukere, andre kontrakter eller eksterne systemer må derfor valideres ved tillitsgrensen. Agorics dokumentasjon skiller uttrykkelig mellom rådgivende typekontroll og defensiv validering under kjøring.

Tall og presisjon

JavaScripts vanlige Number-type kan bare representere heltall nøyaktig opp til (2^{53}-1). Kryptografiske verdier, tokenbeløp og kontosaldoer kan være langt større.

Kontrakter bør derfor bruke BigInt, plattformens egne heltallstyper eller faste desimaler. Flyttall bør ikke brukes til kritiske pengeutregninger uten en uttrykkelig og sikker modell for avrunding.

Et stort avhengighetstre

npm gjør det enkelt å installere biblioteker, men en enkelt direkte avhengighet kan trekke inn mange indirekte pakker. En sårbar eller kompromittert pakke kan påvirke kildekoden, byggeverktøyet eller distribusjonsprosessen.

JavaScript oppfører seg ikke likt overalt

En utvikler kan ikke anta at en kontraktsplattform støtter alle funksjoner fra en nettleser eller Node.js. Modulsystem, serialisering, klokke, tilfeldig generering, feilhåndtering og lagring kan være helt annerledes.

Mindre modenhet på enkelte plattformer

På noen blokkjeder er Rust, Solidity eller andre språk bedre støttet av sikkerhetsverktøy, biblioteker og revisjonsmiljøer. Plattformens anbefalte produksjonsspråk bør veie tyngre enn utviklerens personlige preferanse.

Hvilke sikkerhetsrisikoer finnes?

Risiko	Konsekvens	Typisk tiltak
Manglende tilgangskontroll	Uautoriserte uttak eller endringer	Minste myndighet, tydelige roller og sikre administrasjonsnøkler
Feil talltype eller avrunding	Feil saldo eller økonomisk tap	BigInt, faste desimaler og grenseverdietester
Uvalidert input	Manipulert tilstand eller krasj	Skjemavalidering og kontroll av alle data ved tillitsgrenser
Ikke-deterministiske funksjoner	Uenighet mellom noder	Bruk bare plattformgodkjente kilder til tid og tilfeldighet
Asynkrone tilstandsfeil	Dobbeltbruk eller beslutninger basert på gammel tilstand	Eksplisitt tilstandsmaskin og håndtering av feil, forsinkelser og gjentakelser
Orakelmanipulasjon	Feil pris eller feilaktig automatisk handling	Flere datakilder, forsinkelsesgrenser og avviksbegrensninger
Ondsinnet npm-pakke	Kompromittert bygg eller kontrakt	Låste versjoner, revisjon, SBOM og avhengighetsskanning
Prototype pollution	Endrede objektegenskaper eller tilgangsregler	Herdede objekter, sikre datastrukturer og validerte nøkler
Feil i oppgraderingsmekanismen	Skjult kontroll eller ødelagt tilstand	Tidslås, multisignatur, åpen styring og testet migrering
Ubegrensede løkker og lagring	Tjenestenekt eller svært høye gebyrer	Ressursgrenser, paginering og begrenset datavekst

Prototype pollution er en JavaScript-spesifikk sårbarhetsklasse der angriperstyrte nøkler kan påvirke objekters prototypekjede. OWASP anbefaler blant annet å unngå usikre rekursive sammenslåinger og å bruke datastrukturer som ikke arver uønskede egenskaper.

Programvareforsyningskjeden er også en sentral risiko. Låsefiler kan gjøre avhengighetstreet reproduserbart, mens sikkerhetsrevisjoner kan identifisere kjente sårbarheter. Dette erstatter likevel ikke manuell vurdering av hva en pakke faktisk gjør.

Hvordan utvikles sikre JavaScript-smartkontrakter?

En sikker utviklingsprosess bør minst omfatte:

• En spesifikasjon av hvilke verdier og rettigheter kontrakten kontrollerer.
• Trusselmodellering før implementasjonen begynner.
• Prinsippet om minste myndighet for objekter, roller og administratorer.
• Validering av alle eksterne data under kjøring.
• Heltallsbasert økonomisk logikk med eksplisitte avrundingsregler.
• Enkle og tydelige tilstandsmaskiner.
• Enhetstester, integrasjonstester og tester mot et lokalt nettverk eller testnett.
• Egenskapsbasert testing og fuzzing av økonomiske invariants.
• Testing av feil, forsinkelser, dupliserte meldinger og avbrutte transaksjoner.
• Låste og kontrollerte avhengigheter.
• Uavhengig sikkerhetsrevisjon før kontrakten håndterer betydelige verdier.
• Overvåking, hendelseslogger og en dokumentert beredskapsplan.
• En uttrykkelig oppgraderings- og avviklingsmodell.

Ingen revisjon kan bevise at en kompleks kontrakt er feilfri. Sikkerhet må behandles som en kontinuerlig prosess, ikke som en engangsgodkjenning før lansering. Forskning på smartkontraktsikkerhet viser at programmeringsfeil, utilstrekkelige utviklingsrutiner og plattformspesifikke svakheter fortsatt er sentrale utfordringer.

JavaScript sammenlignet med Solidity og Rust

Egenskap	JavaScript/TypeScript	Solidity	Rust
Typing	Dynamisk, eventuelt statisk utviklingsstøtte med TypeScript	Statisk	Statisk med strengt eierskapssystem
Vanlig kjøremål	Begrenset JS-miljø eller WebAssembly	Ethereum Virtual Machine	WebAssembly eller plattformspesifikk bytecode
Læringskurve	Lav for webutviklere	Moderat for EVM-utvikling	Høyere for mange nybegynnere
Økosystem	Svært stort generelt økosystem	Stort EVM-spesifikt økosystem	Sterkt system- og blockchain-økosystem
Vanlige risikoområder	Dynamiske typer, tall, prototyper og avhengigheter	Tilgangskontroll, eksterne kall og EVM-spesifikke mønstre	Kompleksitet, logiske feil og plattformspesifikke konto- eller minnemodeller
Beste bruksområde	Plattform som uttrykkelig er laget for sikker JavaScript-kjøring	Ethereum og EVM-kompatible kjeder	Høyytelses- og WebAssembly-baserte kontrakter

Det finnes ikke ett språk som alltid er sikrest. Plattformens kjøremiljø, biblioteker, utviklingsverktøy, revisjonskompetanse og sikkerhetsmodell er minst like viktige som språket.

Er en JavaScript-smartkontrakt en juridisk kontrakt?

Ikke nødvendigvis. En smartkontrakt er først og fremst programkode. Den kan gjennomføre deler av en juridisk avtale, men kan også være et teknisk system uten selvstendig avtalestatus.

Om partene er juridisk bundet, må vurderes etter alminnelig avtalerett og andre relevante regler. Det kan blant annet ha betydning:

• Om partene har ment å binde seg.
• Hvordan vilkårene ble presentert.
• Om brukeren forsto konsekvensene.
• Om koden samsvarer med en skriftlig avtale.
• Hvordan feil, force majeure og tvister skal håndteres.
• Om forbrukervern eller ufravikelige regler begrenser avtalefriheten.
• Hvem som har kontroll over oppgraderinger og administrasjonsnøkler.

EUs Data Act presiserer at bruk av smartkontrakter til automatisert gjennomføring av datadelingsavtaler ikke erstatter relevant sivilrett, kontraktsrett eller forbrukervern.

Hvilke regler gjelder i Norge?

Det finnes ingen generell norsk lov som regulerer JavaScript-smartkontrakter ut fra programmeringsspråket. Regelverket avhenger av hva løsningen faktisk gjør.

En kontrakt som utsteder tokens, driver en handelsplass, oppbevarer kryptoeiendeler eller leverer andre regulerte tjenester, kan omfattes av finansmarkedsregler. En løsning som behandler personopplysninger kan omfattes av personopplysningsloven og GDPR. Markedsføring, forbrukeravtaler, regnskap, skatt, hvitvasking, verdipapirer og immaterielle rettigheter kan også være relevante.

MiCA og kryptoeiendelsloven

Den norske kryptoeiendelsloven gjelder fra 1. juli 2025 og gjennomfører EUs forordning om markeder for kryptoeiendeler, MiCA, i norsk rett. Reglene gjelder blant annet utstedelse og offentlig tilbud av visse kryptoeiendeler og tjenester som oppbevaring, handel og veksling.

Overgangsperioden for relevante kryptoeiendelstjenesteytere utløp 1. juli 2026. Virksomheter som leverer tjenester som omfattes av MiCA, må derfor undersøke om de trenger tillatelse fra Finanstilsynet. Det spiller ingen rolle om den tekniske løsningen er skrevet i JavaScript, Solidity eller Rust.

EUs Data Act

EUs Data Act gjelder i EU fra 12. september 2025. Artikkel 36 stiller særlige krav til profesjonelle leverandører og utplasserere av smartkontrakter som brukes til å gjennomføre datadelingsavtaler.

Kravene omfatter blant annet:

• Robusthet og beskyttelse mot manipulering.
• Sikre mekanismer for avbrudd og avslutning.
• Arkivering av transaksjonsdata, logikk og kode.
• Tilgangskontroll på både styrings- og kontraktsnivå.
• Samsvar mellom programkoden og datadelingsavtalen.
• Samsvarsvurdering og EU-erklæring om samsvar.

Kravene gjelder ikke alle smartkontrakter generelt. Virkeområdet er knyttet til automatisert gjennomføring av bestemte datadelingsavtaler.

Per juli 2026 var Data Act fortsatt under vurdering for innlemmelse i EØS-avtalen og ikke gjennomført som norsk rett. Norske virksomheter som tilbyr produkter eller tjenester i EU, kan likevel bli berørt gjennom sin aktivitet i EU-markedet eller gjennom kontrakter med europeiske kunder.

Personvern og GDPR

En blokkjede kan gjøre det vanskelig å rette eller slette informasjon etter at den er registrert. Samtidig kan transaksjoner, wallet-adresser, hendelseslogger og kontraktstilstand være personopplysninger dersom de direkte eller indirekte kan knyttes til en person.

European Data Protection Board vedtok endelige retningslinjer om behandling av personopplysninger med blokkjedeteknologi 7. juli 2026. Retningslinjene fremhever blant annet innebygd personvern, dataminimering, tydelig ansvarsfordeling og vurdering av personvernkonsekvenser ved behandling som sannsynligvis medfører høy risiko. Personopplysninger bør som hovedregel ikke lagres direkte på en blokkjede dersom dette kommer i konflikt med personvernprinsippene.

Hvordan skattlegges bruk av smartkontrakter i Norge?

Programkoden i seg selv utløser ikke en bestemt skattebehandling. Det er transaksjonens økonomiske innhold som er avgjørende.

For norske privatpersoner regnes kryptovaluta, tokens og andre virtuelle eiendeler normalt som formuesobjekter. Inntekter er skattepliktige, og kapitalinntekt fra slike formuesobjekter skattlegges etter gjeldende sats på 22 prosent. Eiendelene kan også inngå i grunnlaget for formuesskatt.

Bruk av en smartkontrakt kan skape én eller flere skattepliktige hendelser. Skatteetaten opplyser blant annet at:

• Bytte mellom kryptovalutaer og tokens normalt er realisasjon.
• Veksling til eller fra wrapped tokens normalt er realisasjon.
• Innskudd i et likviditetsbasseng mot mottak av et LP-token normalt er realisasjon.
• Avkastning fra likviditetsbassenger er skattepliktig inntekt.
• Mottak av styringstokens kan være skattepliktig ved mottak.
• Senere salg eller bytte kan utløse ny gevinst- eller tapsberegning.

Brukeren bør oppbevare dokumentasjon over tidspunkt, antall, token, markedsverdi i norske kroner, gebyrer, inngangsverdi og hva transaksjonen faktisk innebar. En enkelt smartkontraktoperasjon kan bestå av flere skattemessige disposisjoner.

Vanlige misforståelser

«Solidity er bare JavaScript for blokkjeder»

Solidity er et selvstendig, statisk typet språk med en egen kompilator og kjøremodell. Lik syntaks betyr ikke lik sikkerhet eller oppførsel.

«Alle blokkjeder kan kjøre JavaScript»

Støtten varierer. Ethereum kjører normalt EVM-bytecode produsert fra Solidity eller Vyper, mens Agoric og NEAR har egne modeller for JavaScript.

«TypeScript gjør kontrakten typesikker under kjøring»

TypeScript kan oppdage mange feil før distribusjon, men utviklingstypene erstatter ikke validering av faktiske transaksjonsdata.

«Smartkontrakten henter selv priser fra internett»

Smartkontrakter har normalt ikke fri nettilgang. Eksterne data må leveres gjennom et orakel eller en annen kontrollert mekanisme.

[Intern lenke: Hva er et blockchain-orakel?]

«Koden er sikker fordi den ligger på en blokkjede»

Blokkjeden kan beskytte historikken mot uautorisert endring, men den gjør ikke feil programlogikk riktig. En feil kan i stedet bli vanskeligere å rette.

«En uforanderlig kontrakt er alltid bedre»

Uforanderlighet reduserer risikoen for skjulte endringer, men gjør det vanskeligere å rette sårbarheter. Oppgraderbare kontrakter kan repareres, men gir administratorer eller styringssystemer mer makt. Dette er en styringsmessig avveining, ikke et rent teknisk spørsmål.

Hva er fremtiden for JavaScript-smartkontrakter?

JavaScript vil trolig fortsette å spille en stor rolle i blokkjedebaserte applikasjoner, først og fremst fordi språket allerede brukes av et svært stort utviklermiljø. Den videre utbredelsen avhenger likevel av om plattformene kan kombinere en kjent utvikleropplevelse med determinisme, isolasjon, sikker lagring og robuste verktøy.

Sentrale utviklingsområder er:

• Sikrere JavaScript-subsett og isolerte kjøremiljøer.
• Bedre statisk analyse og formell verifikasjon.
• Standardiserte grensesnitt mellom kontrakter og eksterne systemer.
• Orkestrering på tvers av blokkjeder.
• Reproduserbare bygg og sterkere kontroll med npm-avhengigheter.
• Personvernbevarende teknologier som zero-knowledge proofs.
• Bedre mekanismer for sikker oppgradering, stans og migrering.
• Regulering og tekniske standarder for automatisert datadeling.

JavaScript-smartkontrakter vil neppe erstatte Solidity eller Rust på alle områder. Det mest sannsynlige er et flerspråklig økosystem der utviklere velger språk etter plattform, sikkerhetskrav, ytelse og tilgjengelig kompetanse.

FAQ om JavaScript Smart Contracts

Hva er en JavaScript-smartkontrakt?

Det er en smartkontrakt der programlogikken er skrevet i JavaScript eller TypeScript og enten kjøres i et begrenset JavaScript-miljø eller kompileres til et format som plattformen kan utføre.

Kan JavaScript brukes til smartkontrakter?

Ja. Agoric, NEAR og Hyperledger Fabric er eksempler på plattformer som støtter forskjellige former for JavaScript-basert kontraktsutvikling.

Kan Ethereum-smartkontrakter skrives i JavaScript?

Ikke som ordinær, direkte EVM-kontraktskode. Ethereum-kontrakter skrives vanligvis i Solidity eller Vyper. JavaScript brukes ofte i brukergrensesnitt, tester, distribusjonsskript og biblioteker som ethers.js.

Er Solidity det samme som JavaScript?

Nei. Solidity er et eget statisk typet språk for Ethereum Virtual Machine. Det er inspirert av flere språk, blant annet JavaScript.

Er JavaScript sikkert nok for smartkontrakter?

JavaScript kan brukes sikkert når plattformen har et begrenset kjøremiljø og utvikleren følger strenge sikkerhetsrutiner. Vanlig JavaScript-kode er ikke automatisk egnet til å kontrollere digitale verdier.

Hva er Hardened JavaScript?

Hardened JavaScript er et sikkerhetsbegrenset JavaScript-miljø der innebygde objekter låses, globale rettigheter begrenses og programmer isoleres i compartments. Det brukes blant annet i Agoric og Endo.

Hvorfor kan ikke en smartkontrakt bruke Math.random()?

Vanlig tilfeldig generering kan gi forskjellige resultater på forskjellige noder. En blokkjede trenger en verifiserbar og deterministisk kilde til tilfeldighet.

Hvorfor bør kontrakter bruke BigInt?

Vanlige JavaScript-tall kan miste heltallspresisjon over (2^{53}-1). BigInt eller plattformens egne beløpstyper er bedre egnet til store tokenverdier og nøyaktige beregninger.

Kan en JavaScript-smartkontrakt koble seg til en API?

Normalt ikke direkte. Eksterne data leveres gjennom orakler, relayers, broer eller andre tjenester som sender en kontrollerbar transaksjon til kontrakten.

Er JavaScript-smartkontrakter juridisk bindende?

Ikke automatisk. Den juridiske virkningen avhenger av partenes hensikt, avtaleprosessen, vilkårene, relevant lovgivning og forholdet mellom programkoden og en eventuell skriftlig avtale.

Må en JavaScript-smartkontrakt følge MiCA?

Programmeringsspråket omfattes ikke i seg selv av MiCA. En virksomhet kan omfattes dersom kontrakten inngår i utstedelse, handel, oppbevaring eller andre regulerte tjenester knyttet til kryptoeiendeler.

Hvordan beskattes JavaScript-smartkontrakter?

Koden beskattes ikke som en egen kategori. Skatten avhenger av de økonomiske transaksjonene kontrakten gjennomfører, for eksempel tokenbytte, avkastning, likviditetstilførsel eller mottak av nye tokens.

Kan en JavaScript-smartkontrakt oppgraderes?

Det avhenger av arkitekturen. En kontrakt kan være uforanderlig, eller den kan bruke en oppgraderingsmekanisme. Oppgraderbarhet gjør feilretting mulig, men skaper også styrings- og tillitsrisiko.

Er JavaScript bedre enn Rust for smartkontrakter?

Ikke generelt. JavaScript kan være lettere for webutviklere, mens Rust tilbyr sterk statisk typing og ofte bedre ytelse. Plattformens anbefalinger og kontraktens risikonivå bør avgjøre valget.

Hva er den største risikoen ved JavaScript-smartkontrakter?

Den største risikoen er kombinasjonen av økonomisk forretningslogikk, dynamiske språkegenskaper, eksterne avhengigheter og irreversible konsekvenser. Feil tilgangskontroll eller regnelogikk kan føre til direkte tap av verdier.

Oppsummering

JavaScript Smart Contracts er smartkontrakter som utvikles med JavaScript eller TypeScript og kjøres gjennom en plattformtilpasset sikkerhetsmodell. Noen plattformer kjører herdet JavaScript, andre kompilerer koden til WebAssembly, mens JavaScript i Ethereum hovedsakelig brukes som klient- og integrasjonsspråk.

Teknologien gjør det mulig for webutviklere å bygge desentraliserte applikasjoner med et kjent språk, men den fjerner ikke de grunnleggende utfordringene ved smartkontrakter. Koden må være deterministisk, ressursbegrenset, nøyaktig, testbar og beskyttet mot både logiske feil og kompromitterte avhengigheter.

For norske utviklere og virksomheter må den tekniske vurderingen kombineres med regler om blant annet kryptoeiendeler, personvern, skatt, avtaler, forbrukervern og datadeling. Det avgjørende er ikke at koden er skrevet i JavaScript, men hvilke verdier, rettigheter, data og tjenester kontrakten faktisk kontrollerer.