La oss gjøre dette klart: Arch er ikke en L2. Betegnelsen blir brukt fordi folk ser vår tilpassede utførelsesmodell og antar en kjent kategori. Men kategorier hjelper bare når de reflekterer hvordan et system faktisk fungerer. Å kalle Arch et L2 skaper bare forvirring om hva arkitekturen gjør. L2-er krever at brukere brygger eller pakker inn sine ressurser for å få tilgang til større programmerbarhet. De opprettholder en separat tilstandsmaskin som kun synkroniserer tilbake til Bitcoin, hvis noen gang, når transaksjoner postes tilbake som postforpliktelser eller bevis på basislaget. Deres transaksjoner er overhodet ikke avhengige av hva som skjer på Bitcoin-basislaget, siden deres utførelse og validator befinner seg helt et annet sted. ArchVM fungerer annerledes. ・De samme validatorene som godkjenner transaksjonene i ArchVM har også proporsjonale nøkkelandeler i Archs FROST + ROAST-kryptografi på Bitcoin. ・Tilstandsendringer reflekteres deretter, med en sanntids mempool-indekser og en DAG (Directed Acyclic Graph) som holder oversikt over tilstandsovergangene på Arch og tilsvarende aktivaoverføringer på Bitcoin for å sikre at de forblir atomiske. ・Dens rollback/reapply-metode sikrer tilstandkonsistens, slik at Arch kan gi applikasjoner en forhåndsbekreftelse, slik at brukerne kan bryte ut av de utfordringene med brukeropplevelsen som følger med Bitcoins trege blokkeringstider. Slik kan Arch bringe finansiell logikk til UTXO-baserte eiendeler på Bitcoin, ved å holde handlingene innenfor vår apppakke og tilpasse dem på alle trinn til basislaget. Utviklere kan koordinere aktivitet, håndheve regler og bygge onchain-applikasjoner uten å introdusere wrapped assets, bridging-modeller eller sikkerhetsforutsetninger som tvinger brukere til å flytte ressursene sine et annet sted. Det er en modell ulik noe Bitcoin noen gang har sett... og å låse opp en form for Bitcoin-programmerbarhet som aldri har vært mulig før nå.

Se hvordan Arch holder gjennomføringen innenfor Bitcoins tillitsgrenser: