🚨RGB 0.12 RC1 er nå tilgjengelig I mine 2 år med sporing av RGB-protokollen var dette sannsynligvis det mest spennende øyeblikket For bare 14 timer siden, i RGB-WG github, kunngjorde Maxim endelig RC1-versjonen, som vil være den mest stabile versjonen av RGB, og han foreslo også at alle RGB-utviklere går til den nyeste versjonen så snart som mulig, og neste kapittel i BTC-økosystemet kommer La oss dykke inn 👇 🧵 ———————— 🔶 Forenkling av protokollen Denne gangen er endringen hovedsakelig i konsensuslaget, med den nye arkitekturen som introduserer for første gang zk-AluVM, en kompakt, høyytelses Turing-komplett zk virtuell maskin designet for klientverifisering Hvis du ikke vet mye om RGB, kan du tro at det er det mest innfødte smarte kontraktssystemet til BTC, selvfølgelig kan ikke bare BTC, men alle offentlige kjeder i UTXO-modus bruke RGB-protokollen til å fullføre smarte kontrakter utenfor kjeden Tilbake til oppdateringen, i arkitekturen er det også noen optimaliseringer av kontraktstilstandsrefaktorering + konsensusverifisering, som ikke vil bli vist i detalj her I følge Github, denne gangen v0.12 - 4x reduksjon i mengden konsensuskode og 2x reduksjon i standardbiblioteket; - redusere antall datatyper med 30 % i generiske parametere i API-en 🔶 Staten er forent Kanskje for vanlige mennesker er den mest merkbare endringen foreningen av kontraktstilstanden, som pleide å ha tre typer kontraktstilstander (FT/NFT/annet) og nå er alle forent, og en ny tokenmal kan være nødvendig (den forrige v0.11-malen skal være ugyldig) 🔶 Forbedringer av betaling Det er noen store forbedringer her, og jeg vil plukke ut de viktigste 1. Kontrakter med flere eiendeler Det er nå mulig å inkludere flere interoperable tokens i en kontrakt, som kan kalles uavhengig eller i fellesskap eks: For eksempel kan jeg definere 100 mynter + 500 NFT-er + noen andre vedlegg i en kontrakt (det mest grunnleggende) 2. Skript for betaling For eksempel støtter CoinJoin/PayJoin med flere signaturer, transaksjonsbatchbehandling, lynkanaloperasjon osv., en-til-mange eller mange-til-en 🔶 Optimalisering av ytelse Den gamle versjonen av forsendelsesdata må lastes helt inn i minnet, v0.12 endres til streamingautentisering, minnet opptar bare noen få hundre byte, og det er egnet for mobil-/maskinvarelommebøker Jeg vil ikke skrive mer, og det vil være forskjellig fra alles bruk | pepper 花椒解盘㊂正EV OKX Feed

🚨RGB 0.12 RC1 er nå tilgjengelig I mine 2 år med sporing av RGB-protokollen var dette sannsynligvis det mest spennende øyeblikket For bare 14 timer siden, i RGB-WG github, kunngjorde Maxim endelig RC1-versjonen, som vil være den mest stabile versjonen av RGB, og han foreslo også at alle RGB-utviklere går til den nyeste versjonen så snart som mulig, og neste kapittel i BTC-økosystemet kommer La oss dykke inn 👇 🧵 ———————— 🔶 Forenkling av protokollen Denne gangen er endringen hovedsakelig i konsensuslaget, med den nye arkitekturen som introduserer for første gang zk-AluVM, en kompakt, høyytelses Turing-komplett zk virtuell maskin designet for klientverifisering Hvis du ikke vet mye om RGB, kan du tro at det er det mest innfødte smarte kontraktssystemet til BTC, selvfølgelig kan ikke bare BTC, men alle offentlige kjeder i UTXO-modus bruke RGB-protokollen til å fullføre smarte kontrakter utenfor kjeden Tilbake til oppdateringen, i arkitekturen er det også noen optimaliseringer av kontraktstilstandsrefaktorering + konsensusverifisering, som ikke vil bli vist i detalj her I følge Github, denne gangen v0.12 - 4x reduksjon i mengden > konsensuskode og 2x reduksjon i standardbiblioteket; - > redusere antall datatyper med 30 % i generiske parametere i API-en 🔶 Staten er forent Kanskje for vanlige mennesker er den mest merkbare endringen foreningen av kontraktstilstanden, som pleide å ha tre typer kontraktstilstander (FT/NFT/annet) og nå er alle forent, og en ny tokenmal kan være nødvendig (den forrige v0.11-malen skal være ugyldig) 🔶 Forbedringer av betaling Det er noen store forbedringer her, og jeg vil plukke ut de viktigste 1. Kontrakter med flere eiendeler Det er nå mulig å inkludere flere interoperable tokens i en kontrakt, som kan kalles uavhengig eller i fellesskap eks: For eksempel kan jeg definere 100 mynter + 500 NFT-er + noen andre vedlegg i en kontrakt (det mest grunnleggende) 2. Skript for betaling For eksempel støtter CoinJoin/PayJoin med flere signaturer, transaksjonsbatchbehandling, lynkanaloperasjon osv., en-til-mange eller mange-til-en 🔶 Optimalisering av ytelse Den gamle versjonen av forsendelsesdata må lastes helt inn i minnet, v0.12 endres til streamingautentisering, minnet opptar bare noen få hundre byte, og det er egnet for mobil-/maskinvarelommebøker Jeg vil ikke skrive mer, og det vil være forskjellig fra alles bruk

22,91k

Innholdet på denne siden er levert av tredjeparter. Med mindre annet er oppgitt, er ikke OKX forfatteren av de siterte artikkelen(e) og krever ingen opphavsrett til materialet. Innholdet er kun gitt for informasjonsformål og representerer ikke synspunktene til OKX. Det er ikke ment å være en anbefaling av noe slag og bør ikke betraktes som investeringsråd eller en oppfordring om å kjøpe eller selge digitale aktiva. I den grad generativ AI brukes til å gi sammendrag eller annen informasjon, kan slikt AI-generert innhold være unøyaktig eller inkonsekvent. Vennligst les den koblede artikkelen for mer detaljer og informasjon. OKX er ikke ansvarlig for innhold som er vert på tredjeparts nettsteder. Beholdning av digitale aktiva, inkludert stablecoins og NFT-er, innebærer en høy grad av risiko og kan svinge mye. Du bør nøye vurdere om handel eller innehav av digitale aktiva passer for deg i lys av din økonomiske tilstand.