Deploy Smart-kontrakt til Arbitrum: 12 Steg, 45 Min [2026]

Ethereum mainnet koster fortsatt for mye for de fleste vanlige transaksjoner, og det er derfor utviklere i økende grad flytter applikasjonene sine til Layer 2. I april 2026 lå Arbitrum One på mellom 13,8 og 16,9 milliarder dollar i låst verdi (TVL), ifølge en sammenstilling fra spotedcrypto.com, mens Base fulgte tett bak med 10,7 til 11,2 milliarder dollar. Til sammen kontrollerer Arbitrum og Base rundt 77 prosent av all DeFi-likviditet på Layer 2, ifølge samme kilde. For en norsk eller nordisk utvikler som vil bygge noe reelt i 2026, er spørsmålet ikke lenger «bør jeg bruke Layer 2», men «hvordan deployer jeg trygt til riktig kjede».

Denne guiden tar deg gjennom hele prosessen: fra et tomt prosjekt til en verifisert smart-kontrakt som kjører på både Arbitrum Sepolia og Base Sepolia. Du får konkrete kodeeksempler, versjonsnumre du kan stole på, og en liste over fallgruver som får nybegynnere til å miste testnett-ETH eller deploye feil kontrakt til feil kjede. Vi bruker Hardhat som utviklingsmiljø, siden det fortsatt er det mest brukte rammeverket for Ethereum-kompatible kjeder, men vi nevner også Foundry som alternativ underveis.

Hva er Layer 2, og hvorfor trenger Ethereum skalering?

Layer 2 (L2) er en samlebetegnelse for nettverk som prosesserer transaksjoner utenfor selve Ethereum mainnet (Layer 1), men som likevel arver sikkerheten fra Layer 1 ved å publisere data eller bevis tilbake dit. De fleste av dagens store L2-er, deriblant Arbitrum, Base og Optimism, er såkalte optimistic rollups. De samler tusenvis av transaksjoner i én batch, kjører dem raskt på egen infrastruktur, og legger så en komprimert versjon av resultatet ut på Ethereum. Modellen antar at transaksjonene er gyldige med mindre noen beviser det motsatte innen en tvisteperiode, derav navnet «optimistic».

Alternativet er ZK-rollups, som zkSync Era, StarkNet og Scroll. Disse genererer et kryptografisk bevis (et zero-knowledge-bevis) for at hver batch med transaksjoner er korrekt, og trenger derfor ingen tvisteperiode. Ifølge en rapport fra rzlt.io kontrollerer optimistic rollups fortsatt rundt 80 prosent av DeFi-TVL på Layer 2 i 2026, mens ZK-baserte kjeder samlet står for rundt 10 prosent av markedet, men vokser raskere i institusjonelle piloter. zkSync Era hadde ifølge yellow.com kommet seg opp i rundt 16 millioner dollar TVL i mai 2026, etter en tøff periode i 2025.

Gevinsten for en utvikler er konkret: gebyrene faller fra titalls kroner til brøkdeler av en øre per transaksjon. En sammenligning fra eco.com viser at medianoverføringen på Arbitrum One kostet rundt 0,04 dollar i august 2026, mens Base lå enda lavere på rundt 0,02 dollar. Samtidig håndterer Base rundt 89 transaksjoner per sekund i snitt og Arbitrum rundt 62, ifølge samme kilde, mot noen få titalls TPS på Ethereum mainnet i perioder med høy trafikk. For norske utviklere som er vant til at Vipps og BankAxept «bare fungerer», er dette endelig en brukeropplevelse som kommer i nærheten.

Arbitrum, Base eller Optimism: hvilken rollup passer prosjektet ditt?

Før du skriver en eneste linje kode bør du velge kjede bevisst, ikke bare kopiere det første eksempelet du finner på nett. De tre store optimistic rollup-nettverkene har ulike styrker. Arbitrum One har mest total verdi låst og det bredeste økosystemet av DeFi-protokoller, noe som gjør det til et naturlig valg for finansielle applikasjoner. Base er tettest integrert med Coinbase og dominerer forbrukerrettede apper; ifølge sanj.dev sto Base for rundt 46 prosent av alle L2-transaksjoner tidlig i 2026, drevet av små, hyppige betalinger og sosiale dApper. Optimism har i tillegg en egen strategi kalt Superchain, der flere kjeder (inkludert Base) bygges på samme underliggende teknologi, OP Stack, slik at de kan dele likviditet og infrastruktur.

Sikkerhetsmodenhet er også noe du bør sjekke før produksjonslansering. L2BEAT klassifiserer kjeder i stadier fra 0 til 2, der høyere stadium betyr mindre tillit til en sentral operatør og flere reelle sikkerhetsgarantier. Flere 2026-kilder, deriblant eco.com, oppgir at Arbitrum One er klassifisert som Stage 1, mens Base fortsatt lå på Stage 0 i deler av 2026 fordi sekvenseren ikke er fullt desentralisert ennå. Dette er ikke en dealbreaker for et testprosjekt, men det er relevant hvis du skal forvalte reelle midler i produksjon.

Nettverk	Type	TVL (april 2026)	Median gebyr	Snitt TPS	L2BEAT-stadium
Arbitrum One	Optimistic rollup	13,8–16,9 mrd. USD	~0,04 USD	~62	Stage 1
Base	Optimistic rollup	10,7–11,2 mrd. USD	~0,02 USD	~89	Stage 0
Optimism (OP Mainnet)	Optimistic rollup / Superchain	~4–8 mrd. USD	Under 0,05 USD	Ikke separat rapportert	Stage 1
zkSync Era	ZK-rollup	~15 mill. USD	Under 0,05 USD	Ikke separat rapportert	N/A (ZK-bevis)

Tallene varierer noe mellom kilder avhengig av om de måler total verdi sikret (L2BEAT) eller ren DeFi-TVL (DefiLlama), så bruk dem som størrelsesorden, ikke eksakte fasit-tall. Du finner et oppdatert, levende dashbord over disse tallene på L2BEATs TVL-oversikt, som er den mest siterte uavhengige kilden i bransjen. I denne guiden deployer vi til både Arbitrum Sepolia og Base Sepolia, testnettene til de to største kjedene, slik at du ser at samme kontrakt og nesten identisk konfigurasjon fungerer på begge.

Slik fungerer gebyrmodellen: utførelse på L2 og data på L1

For å forstå hvorfor gebyrene på Arbitrum og Base er så mye lavere enn på mainnet, hjelper det å skjønne hva du faktisk betaler for. En transaksjon på en optimistic rollup består av to kostnadskomponenter. Den første er selve utførelsen, altså at sekvenseren kjører koden din og oppdaterer tilstanden på L2. Denne delen er billig, siden L2-en har sin egen, raske infrastruktur uten å konkurrere om plass i en global Ethereum-blokk. Den andre komponenten er et L1-databasegebyr: sekvenseren må jevnlig publisere komprimerte transaksjonsdata tilbake til Ethereum, slik at hvem som helst kan rekonstruere L2-tilstanden fra L1 alene hvis noe går galt.

Frem til 2024 var dette L1-databasegebyret den klart største kostnadsposten på de fleste rollups. Etter at Ethereum innførte såkalte blob-transaksjoner (EIP-4844, ofte kalt “Proto-Danksharding”), fikk L2-er en egen, billigere datakanal for akkurat dette formålet, og prisene falt kraftig. Det er hovedgrunnen til at Arbitrum og Base i 2026 kan tilby gebyrer ned mot noen få hundredeler av en dollar per transaksjon i stedet for titalls øre. Som utvikler trenger du ikke administrere dette manuelt. Hardhat og RPC-leverandøren estimerer gassprisen automatisk basert på nåværende nettverksforhold, men det er nyttig å vite hvorfor gebyret av og til svinger mer enn du forventer i perioder med høy aktivitet på Ethereum mainnet, siden L1-delen av kostnaden fortsatt følger etterspørselen der.

Velg riktig RPC-leverandør for prosjektet ditt

RPC-URL-en (Remote Procedure Call) er koblingen mellom skriptet ditt og selve blokkjeden, og valget av leverandør påvirker både stabilitet og hvor mye du kan skalere før du må betale. De tre vanligste alternativene for norske og nordiske utviklerteam er:

• Alchemy. Har dedikerte endepunkter for både Arbitrum Sepolia og Base Sepolia, med et gratis nivå som er mer enn nok til utvikling og testing. Se Alchemys dokumentasjon for full oversikt over støttede nettverk og grenser.
• Infura. Konsortiets opprinnelige Ethereum-infrastruktur, med tilsvarende støtte for de store L2-ene og en lignende gratis-tier.
• Din egen node. For team med høyt transaksjonsvolum eller strenge krav til datasuverenitet kan det lønne seg å kjøre en egen Arbitrum- eller Base-node. Dette krever mer driftskompetanse, men fjerner avhengigheten til en tredjepart helt.

Uansett hvilken leverandør du velger, bør du sette opp separate nøkler for testnett og mainnet, og aldri dele en produksjonsnøkkel med et utviklingsteam bredere enn nødvendig. De fleste leverandører lar deg også sette opp varsler når forbruket nærmer seg grensen på gratis-nivået, noe som er lurt å aktivere før du glemmer det og et skript plutselig feiler midt i en demo.

Hvordan lese TVL-tall riktig

Når du ser overskrifter om at «Base har 46 prosent av L2-markedet» eller «Arbitrum leder med 16 milliarder dollar», er det verdt å spørre hvilken metrikk som faktisk måles. L2BEAT måler total verdi sikret (Total Value Secured), altså alt som er låst i selve rollup-broen, uavhengig av om det brukes aktivt i DeFi. DefiLlama måler derimot ren DeFi-TVL, altså kun verdier som er aktivt plassert i låne-, handels- eller likviditetsprotokoller. Disse to tallene kan gi ulik rangering av samme kjede, avhengig av hvor mye kapital som bare ligger passivt i broen versus aktivt i bruk. Når du presenterer tall for eget prosjekt eller egen ledelse, oppgi alltid hvilken kilde og metrikk du bruker, slik at sammenligningen blir ærlig.

Forutsetninger: dette trenger du før du starter

Sett av rundt 45 minutter til hele guiden hvis det er første gang du deployer til en L2. Du trenger følgende installert og klart:

• Node.js versjon 20 LTS eller nyere (sjekk med node -v)
• npm versjon 10 eller nyere, følger med Node.js
• Hardhat, installeres som prosjektavhengighet i steg 1 (siste stabile versjon fra npm)
• En kodeeditor, for eksempel VS Code
• En kryptolommebok, for eksempel MetaMask, satt opp for testnett (se vår egen guide om MetaMask-oppsett for trygg L2-bridging hvis du ikke har gjort dette før)
• En privat nøkkel til en TEST-lommebok, aldri en lommebok med reelle midler
• En Alchemy- eller Infura-konto for RPC-tilgang til Arbitrum Sepolia og Base Sepolia (gratis nivå er nok)
• Testnett-ETH på Ethereum Sepolia, som du senere bridger videre til L2-testnettene

Merk at Base Sepolia og Arbitrum Sepolia begge er testnett som etterligner Ethereum Sepolia, ikke selve mainnet. Det betyr at «ETH» du bruker her er verdiløst og kun til testing. Bruk aldri en produksjonsnøkkel i et .env-prosjekt du eksperimenterer med.

Steg 1–2: Sett opp Hardhat-prosjektet

Start med et tomt prosjekt og installer Hardhat via npm. Kjør følgende i terminalen:

mkdir l2-kontrakt-demo && cd l2-kontrakt-demo
npm init -y
npm install --save-dev hardhat @nomicfoundation/hardhat-toolbox dotenv
npx hardhat init

Velg «Create a JavaScript project» når Hardhat spør deg. Dette gir deg en standard mappestruktur med contracts/, scripts/ og test/. Opprett deretter en .env-fil i rotmappen for hemmeligheter, og legg den til .gitignore med det samme, slik at du aldri committer en privat nøkkel ved et uhell.

# .env
PRIVATE_KEY=din_test_private_key_uten_0x_prefiks
ARBITRUM_SEPOLIA_RPC=https://arb-sepolia.g.alchemy.com/v2/DIN_API_NOKKEL
BASE_SEPOLIA_RPC=https://base-sepolia.g.alchemy.com/v2/DIN_API_NOKKEL

Steg 3–4: Skriv og kompiler smart-kontrakten

Vi bruker en enkel, men realistisk kontrakt: en lagringskontrakt med tilgangskontroll, bygget på OpenZeppelins reviderte biblioteker i stedet for å skrive tilgangslogikken fra bunnen av. Installer OpenZeppelin Contracts:

npm install @openzeppelin/contracts

Opprett contracts/MeldingsRegister.sol:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

import "@openzeppelin/contracts/access/Ownable.sol";

contract MeldingsRegister is Ownable {
    string private melding;
    uint256 public oppdateringer;

    event MeldingOppdatert(string nyMelding, address avsender);

    constructor(string memory startMelding) Ownable(msg.sender) {
        melding = startMelding;
    }

    function settMelding(string calldata nyMelding) external onlyOwner {
        melding = nyMelding;
        oppdateringer += 1;
        emit MeldingOppdatert(nyMelding, msg.sender);
    }

    function hentMelding() external view returns (string memory) {
        return melding;
    }
}

Kompiler kontrakten for å fange opp syntaksfeil før du bruker gass på en faktisk deploy:

npx hardhat compile

Ser du meldingen «Compiled 2 Solidity files successfully», er du klar for neste steg. Kommer det en feilmelding om manglende import, sjekk at @openzeppelin/contracts faktisk ligger i node_modules. Vil du lese mer om selve tilgangskontroll-mønsteret Ownable bygger på, finner du full dokumentasjon i OpenZeppelin Contracts-dokumentasjonen, som også dekker mer avanserte mønstre som rollebasert tilgang (AccessControl) hvis prosjektet ditt vokser forbi én enkelt eier.

Steg 5–6: Konfigurer Hardhat for Arbitrum Sepolia og Base Sepolia

Fordi begge kjedene er EVM-kompatible (Ethereum Virtual Machine), trenger du ikke egne kompilatorer eller egen kode for hver kjede. Alt du endrer er nettverkskonfigurasjonen i hardhat.config.js:

require("@nomicfoundation/hardhat-toolbox");
require("dotenv").config();

module.exports = {
  solidity: "0.8.24",
  networks: {
    arbitrumSepolia: {
      url: process.env.ARBITRUM_SEPOLIA_RPC,
      accounts: [process.env.PRIVATE_KEY],
      chainId: 421614,
    },
    baseSepolia: {
      url: process.env.BASE_SEPOLIA_RPC,
      accounts: [process.env.PRIVATE_KEY],
      chainId: 84532,
    },
  },
  etherscan: {
    apiKey: {
      arbitrumSepolia: process.env.ARBISCAN_API_KEY,
      baseSepolia: process.env.BASESCAN_API_KEY,
    },
  },
};

Chain ID 421614 tilhører Arbitrum Sepolia, mens 84532 tilhører Base Sepolia. Skriver du feil chain ID her, vil deploy enten feile umiddelbart eller, i verste fall, sende transaksjonen til feil nettverk. Dobbeltsjekk alltid disse tallene mot den offisielle dokumentasjonen til Arbitrum og Base før produksjonsbruk, siden nettverkene av og til legger til nye RPC-endepunkter.

Steg 7–8: Skaff testnett-ETH og bridge til Layer 2

Du trenger testnett-ETH på selve L2-kjeden for å betale gass, ikke bare på Ethereum Sepolia. Fremgangsmåten er:

1. Hent gratis Sepolia-ETH fra en faucet, for eksempel Alchemys Sepolia-faucet.
2. Bruk den offisielle Arbitrum-broen for å flytte ETH fra Ethereum Sepolia til Arbitrum Sepolia. Dette tar normalt under ti minutter siden det er en testnett-bro.
3. Gjenta med Base-broen for Base Sepolia, eller bruk en faucet som tilbyr Base Sepolia-ETH direkte.
4. Bekreft saldoen i MetaMask ved å legge til de riktige nettverkene manuelt (RPC-URL, chain ID og symbol ETH).

Mange faucets krever at hovedlommeboken din har en viss mengde ekte ETH eller aktivitet på mainnet for å hindre misbruk. Har du ikke det, finnes det community-faucets for Arbitrum og Base, men vær obs på at kapasiteten der svinger fra dag til dag.

Hva gjør du hvis faucet-en er tom?

Faucets for testnett går tidvis tomme, spesielt rundt store hackathons når mange utviklere ber om midler samtidig. Har du allerede litt ETH på Ethereum Sepolia, er den mest pålitelige løsningen å bruke den offisielle broen direkte, siden den ikke er avhengig av en tredjeparts faucet-saldo. Et alternativ er å be en kollega med overskudd på testnettet sende deg en liten sum, siden testnett-ETH ikke har noen reell verdi og fritt kan deles innad i et team. Unngå tjenester som lover «garantert» testnett-ETH mot betaling; det finnes ingen legitim grunn til at verdiløse tokens skal koste penger, og slike tilbud er ofte forsøk på phishing rettet mot lommeboken din.

Steg 9–10: Deploy kontrakten til Layer 2

Opprett scripts/deploy.js:

const hre = require("hardhat");

async function main() {
  const startMelding = "Hei fra Layer 2";
  const Kontrakt = await hre.ethers.getContractFactory("MeldingsRegister");
  const kontrakt = await Kontrakt.deploy(startMelding);
  await kontrakt.waitForDeployment();

  console.log("Kontrakt deployet til:", await kontrakt.getAddress());
}

main().catch((error) => {
  console.error(error);
  process.exitCode = 1;
});

Deploy til Arbitrum Sepolia først:

npx hardhat run scripts/deploy.js --network arbitrumSepolia

Ser alt bra ut, gjenta nøyaktig samme kommando med --network baseSepolia. Fordi begge kjedene er EVM-kompatible, trenger du ikke endre en eneste linje i selve kontrakten eller deploy-skriptet, kun nettverksflagget. Dette er selve poenget med å teste på flere L2-er tidlig: du oppdager fort om koden din utilsiktet har avhengigheter til én bestemt kjede.

npx hardhat run scripts/deploy.js --network baseSepolia

Et vellykket kall returnerer en kontraktadresse, for eksempel Kontrakt deployet til: 0x8f3Cc...92aD. Noter adressen, du trenger den i neste steg.

Steg 11–12: Verifiser kontrakten på blokkutforskeren

En uverifisert kontrakt er en svart boks for alle andre enn deg selv. Verifisering laster opp kildekoden slik at hvem som helst kan lese nøyaktig hva kontrakten gjør, noe som er avgjørende for tillit i produksjon. Kjør:

npx hardhat verify --network arbitrumSepolia 0xDIN_KONTRAKTADRESSE "Hei fra Layer 2"
npx hardhat verify --network baseSepolia 0xDIN_KONTRAKTADRESSE "Hei fra Layer 2"

Merk at konstruktørargumentet («Hei fra Layer 2») må matche eksakt det du brukte i deploy-skriptet, ellers feiler verifiseringen med en bytekode-mismatch. Etter vellykket verifisering finner du kontrakten med lesbar kildekode på Arbiscan for Arbitrum og på Basescan for Base, hvor du også kan kalle funksjoner direkte i nettleseren via «Read/Write Contract»-fanen.

Test og samhandle med kontrakten fra terminalen

Før du stoler på en kontrakt i produksjon, bør du samhandle med den programmatisk, ikke bare gjennom blokkutforskerens nettgrensesnitt. Opprett scripts/interact.js:

const hre = require("hardhat");

async function main() {
  const adresse = "0xDIN_KONTRAKTADRESSE";
  const kontrakt = await hre.ethers.getContractAt("MeldingsRegister", adresse);

  const gammelMelding = await kontrakt.hentMelding();
  console.log("Nåværende melding:", gammelMelding);

  const tx = await kontrakt.settMelding("Oppdatert fra script");
  await tx.wait();

  const nyMelding = await kontrakt.hentMelding();
  console.log("Ny melding:", nyMelding);
  console.log("Antall oppdateringer:", await kontrakt.oppdateringer());
}

main().catch((error) => {
  console.error(error);
  process.exitCode = 1;
});

Kjør med npx hardhat run scripts/interact.js --network arbitrumSepolia. Du bør se to konsollmeldinger, én før og én etter oppdateringen, samt en oppdatert teller. Skriv også en enkel testfil under test/ med Hardhats innebygde Mocha/Chai-oppsett, slik at du kan kjøre npx hardhat test lokalt før hver deploy. Dette fanger opp logiske feil billig, uten å bruke ekte gass på testnettet.

Gassavgifter i praksis: Layer 1 mot Layer 2

Tallene fra rapportene over blir mer konkrete når du ser dem i kontekst av en typisk overføring. En sammenligning fra flere 2026-rapporter, deriblant eco.com og rzlt.io, viser omtrent følgende bilde for en enkel token-overføring:

Nettverk	Typisk gebyr per overføring	Bekreftelsestid	Arver sikkerhet fra
Ethereum mainnet (L1)	Flere dollar, ofte 1–5 USD i perioder med trafikk	~12–15 sekunder per blokk, ofte flere blokker for trygghet	Seg selv
Arbitrum One	~0,04 USD	Under ett sekund lokalt, ~7 dager til full L1-finalitet	Ethereum
Base	~0,02 USD	Under ett sekund lokalt, ~7 dager til full L1-finalitet	Ethereum (via OP Stack)

Legg merke til forskjellen mellom «lokal» bekreftelse, som skjer nesten øyeblikkelig fordi sekvenseren på L2 svarer raskt, og full finalitet, som venter på tvisteperioden mot Ethereum. For de fleste brukervendte applikasjoner holder lokal bekreftelse mer enn godt nok. For store uttak eller kritisk infrastruktur bør du derimot vente på full finalitet, spesielt hvis du bygger noe som skal integreres med en krypto-bro mellom flere kjeder.

Vanlige fallgruver ved Layer 2-utvikling

Disse feilene dukker opp igjen og igjen hos utviklere som er nye på Layer 2. Selv erfarne Ethereum-utviklere går ofte i disse fellene første gangen:

• Å blande sammen chain ID-er. Arbitrum Sepolia (421614) og Base Sepolia (84532) ligner ikke på hverandre, men det er lett å kopiere feil verdi fra et gammelt prosjekt.
• Å anta at gass fungerer identisk på L1 og L2. Noen L2-er har egne gassmodeller med et ekstra L1-datagebyr oppå selve utførelsen, noe som kan overraske deg hvis du kun har budsjettert for L2-kjøring.
• Å stole på øyeblikkelig finalitet for store uttak. Optimistic rollups har en tvisteperiode på typisk rundt syv dager for uttak tilbake til L1. Bygg aldri en applikasjon som antar at midler er hundre prosent endelige før den perioden er over.
• Å gjenbruke en privat nøkkel med reelle midler i et testprosjekt. Selv testnett-skript bør bruke en dedikert nøkkel, siden feilkonfigurerte RPC-er eller skript i verste fall kan lekke nøkkelen til logger.
• Å hoppe over verifisering av kontrakten. En uverifisert kontrakt gjør det umulig for brukere og revisorer å se hva den faktisk gjør, noe som skader tilliten selv om koden er ufarlig.
• Å ikke teste på mer enn én L2 før produksjonslansering. Kode som fungerer perfekt på Arbitrum kan feile på en kjede med andre forhåndskompilerte kontrakter eller andre opcode-forskjeller.

Feilsøking: 8 vanlige feil og hvordan du løser dem

De fleste feilmeldingene du møter under Layer 2-utvikling kommer fra ett av tre steder: en feilkonfigurert RPC-tilkobling, en lommebok uten nok testnett-ETH, eller en mismatch mellom det som ble deployet og det du senere prøver å verifisere. Tabellen under dekker de meldingene du mest sannsynlig støter på gjennom denne guiden, sortert etter hvor i prosessen de typisk dukker opp.

Feilmelding	Vanligste årsak	Løsning
insufficient funds for gas	Lommeboken mangler testnett-ETH på riktig L2	Bridge mer ETH via offisiell bro, eller bruk en faucet for kjeden
nonce too low	En tidligere transaksjon fra samme lommebok henger fortsatt	Vent på at forrige transaksjon bekreftes, eller nullstill kontoen i MetaMask
invalid project id / 401 Unauthorized	Feil eller manglende API-nøkkel i RPC-URL-en	Sjekk .env-filen og at nøkkelen faktisk er aktivert for riktig nettverk hos RPC-leverandøren
contract creation code storage out of gas	Kontrakten er for stor til å deployes innenfor blokkgrensen	Aktiver Solidity-optimizer i hardhat.config.js, eller del opp kontrakten
Already verified	Du prøver å verifisere en kontrakt som allerede er verifisert	Sjekk statusen direkte på Arbiscan eller Basescan før du kjører kommandoen på nytt
Bytecode does not match	Feil eller manglende konstruktørargumenter ved verifisering	Bruk nøyaktig samme argumenter som i deploy-skriptet, i samme rekkefølge
Timeout ved bridging	Broen venter på bekreftelser fra L1, som kan ta lengre tid i perioder	Vent, sjekk transaksjonsstatus på L1-utforskeren før du prøver på nytt
execution reverted uten grunn	Kontrakten mangler en revert-melding, eller onlyOwner blokkerer kallet	Legg til beskrivende feilmeldinger i require/revert, og sjekk hvem som faktisk eier kontrakten

Avanserte tips for produksjonsklare Layer 2-prosjekter

Når testnett-deployet fungerer stabilt, er neste skritt å tenke som et team som faktisk skal drifte kontrakten. Noen konkrete anbefalinger:

• Bruk et multisig-skjema, for eksempel Safe, som eier-adresse i stedet for én enkelt privat nøkkel, spesielt hvis kontrakten skal håndtere reelle midler.
• Kjør en statisk sikkerhetsanalyse før hver produksjonsdeploy. Vi har en egen guide om å teste smart-kontrakter for sårbarheter med Slither og Echidna som passer godt sammen med dette oppsettet.
• Overvåk kontraktens events kontinuerlig, ikke bare ved deploy. Verktøy som Tenderly eller egne indekserere basert på RPC-loggene fanger opp uventet aktivitet raskt.
• Vurder å deploye til flere L2-er samtidig for redundans, men vær bevisst på at likviditet og brukere da splittes mellom kjedene med mindre du også bygger en bro mellom dem.
• Sett opp separate RPC-nøkler for testnett og mainnet hos leverandøren din, slik at et lekket testnett-skript aldri kan påvirke produksjonstrafikk.
• Følg med på L2BEATs stadium-klassifisering jevnlig. Kjeder oppgraderer desentraliseringen av sekvenseren over tid, og det kan endre risikobildet for prosjektet ditt.

Kostnadsplanlegging for et Layer 2-prosjekt i produksjon

Selve deployen koster nesten ingenting sammenlignet med Ethereum mainnet, men et produksjonsprosjekt har flere kostnadsposter enn bare gass. Sett opp et enkelt budsjett før du lanserer, slik at du ikke blir overrasket underveis. De største postene for et typisk team er:

• Deploygass. Selve utrullingen av kontrakten koster typisk noen få dollar totalt på Arbitrum eller Base, langt under det samme ville kostet på mainnet.
• Løpende transaksjonsgebyrer. Med median gebyrer på 0,02 til 0,04 dollar kan et prosjekt med titusenvis av brukerhandlinger i måneden fortsatt holde totalkostnaden på gass under noen få hundre dollar, avhengig av hvor gass-tunge funksjonene dine er.
• RPC-forbruk utover gratis-nivået. Vokser trafikken forbi det gratis Alchemy- eller Infura-tilbyr, går du over på et betalt nivå som normalt prises per antall kall (compute units).
• Sikkerhetsrevisjon. Dette er ofte den klart største enkeltposten før en seriøs produksjonslansering, og bør budsjetteres tidlig i prosjektet, ikke som en ettertanke rett før lansering.
• Overvåking og verktøy. Tjenester for events-overvåking, varsling og indeksering har egne abonnement, men er billige sammenlignet med kostnaden av å oppdage et angrep for sent.

En vanlig feil hos nye team er å bruke all budsjettoppmerksomhet på selve utviklingen og glemme driftskostnadene helt. Sett av en fast prosentandel av utviklingsbudsjettet, gjerne 15 til 20 prosent, til revisjon og overvåking før dere regner prosjektet som produksjonsklart.

Foundry som alternativ til Hardhat

Hardhat er valgt i denne guiden fordi det har lavest terskel for JavaScript- og TypeScript-utviklere, men mange team i 2026 bruker Foundry for raskere testing, siden testene der skrives i Solidity selv i stedet for JavaScript. Vil du sammenligne, installer Foundry og kjør forge init i et separat prosjekt, deploy med forge create mot samme RPC-URL-er som over, og bruk forge verify-contract i stedet for Hardhats verify-kommando. Konseptene er identiske, kun verktøybeltet er annerledes. Se Foundry-boken for full dokumentasjon.

Det komplette prosjektet: mappestruktur og filer

Når du er ferdig, bør prosjektmappen din se omtrent slik ut:

l2-kontrakt-demo/
├── contracts/
│   └── MeldingsRegister.sol
├── scripts/
│   ├── deploy.js
│   └── interact.js
├── test/
│   └── MeldingsRegister.test.js
├── .env
├── .gitignore
├── hardhat.config.js
└── package.json

Dette er et fullt fungerende prosjekt: du kan klone strukturen, fylle inn dine egne RPC-nøkler og privatnøkkel i .env, kjøre npx hardhat compile, deploye til begge testnettene og verifisere kontraktene, alt uten å skrive noe mer kode enn det som står i denne guiden. Herfra kan du bygge videre med et frontend-grensesnitt (for eksempel med ethers.js eller viem og en wallet-connector), legge til flere funksjoner i kontrakten, eller koble den til en indekserer for historikk.

Sikkerhet: hva L2-utvikling endrer, og hva som forblir likt

Det er en vanlig misforståelse at Layer 2 er «tryggere» enn Layer 1 fordi det er nyere teknologi. Realiteten er at de fleste sikkerhetsprinsippene fra Ethereum mainnet gjelder uendret: reentrancy-angrep, integer-feil og tilgangskontroll-feil fungerer akkurat like ødeleggende på Arbitrum eller Base som på mainnet. Det som faktisk endrer seg, er operasjonell risiko knyttet til selve broen og sekvenseren. Går sekvenseren på en L2 ned, eller sensurerer den transaksjoner, kan brukere i verste fall måtte vente på en tvangsmekanisme for å presse gjennom transaksjonen via L1, noe som kan ta timer i stedet for sekunder.

Bruk denne korte sjekklisten før du regner en kontrakt som klar for reelle midler, uavhengig av hvilken L2 du deployer til:

• Alle funksjoner som endrer tilstand og skal begrenses, bruker eksplisitte modifiers som onlyOwner eller rollebasert tilgang, ikke bare kommentarer i koden.
• Eventuelle eksterne kall (til andre kontrakter) skjer etter at intern tilstand er oppdatert, ikke før, for å unngå reentrancy.
• Alle brukerinnsendte tall er sjekket mot rimelige grenser, selv om Solidity 0.8 og nyere har innebygd overflow-beskyttelse.
• Kontrakten er kjørt gjennom minst ett statisk analyseverktøy, og alle høyalvorlighetsfunn er enten fikset eller eksplisitt vurdert som falske positiver med begrunnelse.
• Eierskap eller adminrettigheter ligger i en multisig, ikke en enkelt lommebok, før noe reelt beløp flyttes inn.

For lommebok- og bruker-siden av dette anbefaler vi å lese vår guide om hvordan Ethereum-lommebøker kapres via autorisasjonstransaksjoner, siden mange av de samme angrepsmønstrene rammer brukere av dApper på L2 like hardt som på mainnet. Kombinerer du kontrakten din med et DeFi-produkt, bør du også lese vår gjennomgang av DeFi-sikkerhet etter fjorårets store hack før lansering, samt vår guide til å stoppe MEV-angrep, siden MEV-boter opererer aktivt på Layer 2 nå.

Neste steg: fra testnett til mainnet

Når kontrakten er testet, verifisert og gjennomgått på både Arbitrum Sepolia og Base Sepolia, gjenstår selve overgangen til mainnet. Dette bør aldri gjøres i hastverk, siden en feil her koster ekte penger, ikke testnett-ETH. Fremgangsmåten ligner mye på det du allerede har gjort, men med noen ekstra sjekkpunkter:

1. Legg til mainnet-nettverkene (chainId 42161 for Arbitrum One og 8453 for Base) i hardhat.config.js, med separate RPC-URL-er og en helt annen privat nøkkel enn testnettet.
2. Kjør hele testsuiten på nytt lokalt, og bekreft at alle tester fortsatt passerer uendret.
3. Deploy først til én kjede, vent til kontrakten er verifisert og fungerer som forventet i praksis, før du gjentar prosessen på den andre kjeden.
4. Flytt eierskapet fra deploy-nøkkelen til en multisig med det samme kontrakten er bekreftet stabil, ikke uker senere.
5. Publiser kontraktadressene offentlig, for eksempel i et GitHub-repo eller på nettsiden til prosjektet, slik at brukere kan verifisere at de samhandler med riktig adresse.

Et poeng mange team undervurderer: hold testnett-versjonen av prosjektet i live drift selv etter mainnet-lansering. Den er uvurderlig når dere senere skal teste en oppgradering eller en ny funksjon, uten å risikere noe på produksjonskontrakten.

Overvåking og drift etter lansering

Deploy er ikke slutten på arbeidet, det er starten på driftsfasen. En kontrakt som fungerer perfekt ved lansering kan likevel rammes av uventet oppførsel senere, enten fra en avhengighet, en ny type angrep, eller rett og slett uvanlig brukeratferd. Sett opp minst disse tre overvåkingslagene før dere regner prosjektet som produksjonsklart:

• Event-basert varsling. Lytt til kontraktens events i sanntid og send varsel til Slack eller e-post ved uventede mønstre, for eksempel uvanlig mange kall til en sensitiv funksjon på kort tid.
• Saldo- og tilstandssjekk. Sjekk jevnlig at kontraktens tilstand samsvarer med det du forventer, spesielt hvis kontrakten holder på verdier eller eierskap som kan endres av flere parter.
• RPC- og sekvenser-status. Følg med på driftsstatus for selve L2-kjeden. Både Arbitrum og Base publiserer statussider der du kan se om sekvenseren har nedetid, noe som direkte påvirker om brukerne dine får gjennomført transaksjoner.

De fleste team starter enkelt, med et skript som poller RPC-en for nye events hvert par minutter og sender varsler via en webhook. Det er billig å sette opp, og fanger opp det aller meste av det du faktisk trenger å vite om i sanntid.

Ofte stilte spørsmål om Layer 2-utvikling

Må jeg skrive om kontrakten min for å kjøre på Arbitrum eller Base?
Nei. Begge kjedene er EVM-kompatible, så Solidity-koden din kjører uendret. Det eneste du normalt endrer er nettverkskonfigurasjonen i deploy-verktøyet.

Hvor lang tid tar det før en L2-transaksjon er «endelig»?
Lokal bekreftelse på selve L2-en skjer på under ett sekund. Full finalitet mot Ethereum, altså at transaksjonen ikke lenger kan reverseres via tvisteperioden, tar for optimistic rollups som Arbitrum og Base typisk rundt syv dager for uttak.

Koster det noe å deploye til testnett?
Nei, testnett-ETH er gratis og skaffes via faucets, men det har ingen reell verdi og kan ikke veksles til noe annet.

Bør jeg velge Arbitrum eller Base for et nytt prosjekt?
Arbitrum har mest DeFi-likviditet og et modent økosystem, mens Base har lavere gebyrer og sterkere forbrukertrafikk gjennom Coinbase-integrasjonen. Mange team deployer etter hvert til begge for å nå flest mulig brukere.

Hva er forskjellen på en optimistic rollup og en ZK-rollup i praksis for meg som utvikler?
Som Solidity-utvikler merker du lite til forskjellen i det daglige, siden begge er EVM-kompatible for de fleste formål. Forskjellen ligger i hvordan transaksjonene bevises overfor Ethereum: optimistic rollups antar gyldighet med en tvisteperiode, mens ZK-rollups beviser gyldighet matematisk med det samme.

Kan jeg bruke samme private nøkkel for testnett og mainnet?
Du kan teknisk sett gjøre det, men du bør ikke. Bruk alltid separate nøkler, slik at et testskript eller en lekket .env-fil aldri kan sette reelle midler i fare.

Hvorfor feiler verifiseringen selv om deploy fungerte?
Den vanligste årsaken er at konstruktørargumentene du sender til verify-kommandoen ikke er identiske med det som ble brukt ved selve deployen. Sjekk skript og kommando side om side.

Trenger jeg en revisjon før jeg lanserer på mainnet?
For alt som håndterer reelle brukermidler, ja. Kombiner statisk analyse (Slither, Echidna) med en ekstern revisjon fra et anerkjent selskap før du flytter fra testnett til produksjon.

Kan jeg bruke Hardhat mot en L2 uten å endre selve kompilatoren?
Ja. Solidity-kompilatoren fungerer identisk uansett hvilken EVM-kompatibel kjede du deployer til. Kompilatorversjonen du angir i hardhat.config.js gjelder for alle nettverkene i prosjektet.

Hva skjer hvis Arbitrum eller Base opplever nedetid på sekvenseren?
Transaksjoner kan stoppe opp midlertidig for vanlige brukere. De fleste rollups har en mekanisme for å tvinge gjennom transaksjoner direkte via Ethereum L1 hvis sekvenseren er nede over lengre tid, men dette er langsommere og mer teknisk krevende enn normal bruk.

Related Coverage

• MetaMask Oppsett: 14 Steg til Trygg L2-Bridging
• Test Smart-Kontrakter for Sårbarheter: 14 Steg
• Krypto-Bro Sikkerhet: 12 Steg Etter $292M-Hack
• Ethereum-lommebok Kapret: 63% Angrepsrate
• DeFi-Sikkerhet: 12 Steg Etter $942M i Hack
• Slik Stopper Du MEV-Angrep: 14 Steg, 45 Min