Taro, en ny protokoll foreslått av Lightning Labs, utnytter Taproot og Lightning Network for å bringe nye eiendeler og skalerbarhet til Bitcoin.
Lightning Labs har introdusert et nytt protokollforslag for Bitcoin og Lightning Network, Taro, som søker å bringe nye brukstilfeller til nettverket. Selskapet har publisert en serie utkast til Bitcoin Improvement Proposals (BIPs) og den ber om tilbakemelding fra samfunnet på det foreslåtte designet.
Taro søker å muliggjøre utstedelse av eiendeler og samleobjekter, som er protokollens form for ikke-fungible eiendeler, på Bitcoin samt overføring av dem på Lightning på en privat og sikker måte uten å blåse opp blokkjeden. For å gjøre det planlegger den å utnytte protokollens siste oppgradering, taproot.
"Designprinsippene til Taro on Lightning trekker fra internett, hvor du har kompleksitet i kantene, men du beholder enkelheten i mellom," fortalte Elizabeth Stark, administrerende direktør i Lightning Labs. Bitcoin Magazine.
De fleste eksisterende måter å utstede og bruke eiendeler på Bitcoin i dag enten utnytter en annen blokkjede helt, som legger til en ny tillitsmodell med forskjellige sikkerhetsgarantier, eller er avhengige av å legge til ekstra data direkte på kjeden, noe som er ineffektivt for å holde styr på informasjon om eiendeler på lang sikt og er farlig for brukernes personvern.
I stedet bruker Taro Taproot.
The Future Of Taproot: Skalerbarhet og personvern
Taproot lar komplekse forbruksbetingelser settes for en Bitcoin UTXO, samtidig som det sikres at bare tilstanden som til slutt blir vant til å bruke mynten, avsløres på kjeden for alle Bitcoin-brukere. Som et resultat er et slikt forbruk mer privat, fordi en passiv observatør ikke kan se om det var andre forbruksbetingelser for den transaksjonen; og mer skalerbar, fordi nå legger den komplekse ordningen betydelig mindre data på kjeden. Dette er meningsfullt fordi tidligere programmatisk oppførsel i Bitcoin betydde at transaksjoner måtte avsløres i sin helhet når de ble brukt, noe som skadet brukernes personvern og gjorde svært komplekse ordninger umulige på grunn av en lineær vekst i lagringsbehov.
Ved å bruke Taproot kan Taro også stole på Bitcoins proof-of-work (PoW) konsensusmekanisme for å sikre riktig bestilling av transaksjoner og forhindre dobbeltforbruk, samtidig som det definerer spesielle direktiver for hvordan man skal samhandle med og validere de nye aktivadataene.
Som et resultat skiller Taro seg også fra andre aktivaløsninger på "svært programmerbare" blokkjeder, som Ethereums ERC-20 og ERC-721 tokens, fordi den er basert på Bitcoins UTXO-modell i stedet for en kontomodell, noe som betyr at den er både mer sikker på grunn av unngåelse av gjenbruk av nøkkel og mer privat siden det ikke avsløres informasjon om saldoer. Taros tilnærming er også mer skalerbar og er kompatibel med lette klienter.
Mer spesifikt bringer Taro eiendeler til Bitcoin gjennom "bladene" til Taproot-skripttreet, ettersom hvert blad i treet er helt uavhengig og kan avsløres selektivt – noe som muliggjør strukturert forpliktelse. Ved å legge til informasjon om disse eiendelene (kjent som metadata) i Taproot-skripttreet, kan den foreslåtte protokollen fungere som et lag bygget på toppen av Bitcoin, slik at Taro-aktivatransaksjoner kan se ut som vanlige Bitcoin-transaksjoner, ettersom bare Taproot-utdataene er på kjeden. avsløres, samtidig som det muliggjør bevis på bevegelsen av eiendeler over transaksjonsgrafen.
Bitcoin er skalerbar
"Dette er ganske elegant fordi det lar deg skille disse aktivaforpliktelsene fra selve manuset," fortalte Lightning Labs CTO, Olaoluwa Osuntokun, Bitcoin Magazine. "Taproot, i dette tilfellet, lar oss logisk skille det som er det viktigste Bitcoin-skriptlaget fra selve aktivalaget. Selv om de faktisk er innenfor samme utgang, fordi Bitcoin-laget ikke bryr seg om hva som ikke blir avslørt, kan vi bruke det til å ha ytterligere strukturerte data."
Som et resultat gjør denne konstruksjonen det mulig for en enkelt Taproot UTXO å effektivt forplikte seg til (det vil si inkludere hashen til) et ubegrenset antall eiendeler som bare avsløres for de spesifikke partene som trenger den informasjonen – uten å belaste hele Bitcoin-nettverket.
"Det gjør ting litt enklere og gjør det også mye lettere for utviklere å forstå fordi overleggslaget i utgangspunktet ser ut og føles som Bitcoin med noen små justeringer, ekstra forpliktelser, validering, ting som det," sa Osuntokun.
Ved å utnytte Taproot for utstedelse og overføring av eiendeler, muliggjør Taro effektivt ny funksjonalitet i kantene av Bitcoin ved å utnytte bitcoin-likviditet etter hvert som eiendelen blir rutet gjennom Lightning Network, alt uten å legge til unødvendige data på kjeden.
"Hvis folk gjør flere transaksjoner ved å bruke disse eiendelene, betyr det at vi faktisk trenger mer kapasitet i selve Lightning Network," sa Osuntokun. "Etterspørselen etter eiendeler på kantene, så langt som strukturell kapasitet, oversettes deretter til økt produktiv aktivitet på nettverket og flere ruteavgifter, så en større nettverkseffekt også."
Som et resultat kan Taro ta ett skritt i retning av å øke etterspørselen etter blokkrom på kjede, og bidra til å sikre at Bitcoin kan holde seg bærekraftig når gruvearbeidere begynner å bli betalt bare gjennom transaksjonsgebyrer når blokktilskuddet nærmer seg null i neste århundre.
Et finjustert Merkle-tre
Taro utnytter en datastruktur kjent som et Merkle-Sum Sparse Merkle-tre (MS-SMT) for å gjøre det mulig for eiendeler å forplikte seg til Taproot-skripttrær, og fungerer som en overleggsprotokoll. MS-SMT føyer sammen egenskapene til et vanlig Merkle-tre, et Merkle-Sum-tre og et Sparse Merkle-tre.
Et Merkle-tre er konstruert ved å hashe en liste over elementers hash i par til vi kommer til en enkelt hash, kalt rothash. For eksempel, i en liste med fire elementer, vil vi først hash hver vare separat. Deretter ville vi slå sammen hashene til element én og to og hashe den sammenkoblingen, og gjøre det samme med hashen til tre og fire. Til slutt ville vi hash de resterende to hashen for å bestemme rothasjen.
Et Merkle-tre er nyttig fordi det kan lagre masse data, det gjør det enkelt å bevise at noen data finnes i treet, og det lar oss også sjekke at data ikke er tuklet med. Med andre ord, et vanlig Merkle-tre muliggjør skalerbarhet, bevis på medlemskap og manipulasjonsmotstand.
Dessuten trenger vi bare å lagre rothasjen til Merkle-treet på kjeden for å verifisere slike egenskaper. Det er fordi hvis dataene i ett blad blir tuklet med, for eksempel, vil hashen også endre seg, og ytterligere endre alle hashen på nivåene over det, noe som til slutt vil endre rothasjen – som kan få endringen attestert gjennom sammenligning med den lagrede versjon.
Merkle-Sum-treet tar dette et skritt videre ved å tillate oss å forplikte oss til summen av alle bladverdier, noe som betyr at rothashen også kan inkludere informasjon om summen av verdiene til hvert blad i treet. Når det gjelder eiendeler, gjør denne egenskapen det lettere å revidere en eiendelsforsyning, i tillegg til å tillate delbarheten av eiendelen og forhindre uønsket utstedelse av nye eiendeler i transaksjoner som bare skal overføre dem. I vårt fiktive Merkle-tre ovenfor, hvis hvert blad hadde en verdi på én, ville rothashen ha en verdi på fire.
Det sparsomme Merkle-treet legger til enda en egenskap. Alle bladene er indeksert, noe som gir tilgang til informasjon om treet på en nøkkelverdi-par-måte, og den har tomme blader, som faktisk har "null"-verdien, slik at vi kan sjekke om noen data er ikke i treet. Denne egenskapen, kjent som bevis på ikke-medlemskap, er mulig ved bevise medlemskap av null i et gitt blad som kan nås gjennom indeksen. For eksempel, hvis det er en påstand om at bladet med indeks seks lagrer noe informasjon om en eiendel, kan vi bevise at slik informasjon ikke er der ved å attestere at bladet faktisk har en verdi «null».
Overføring av en Taro-aktiva
Taro representerer aktiva med nestede MS-SMT-er, en for hver aktiva-ID eller aktivatype. Protokollen gjør det mulig for disse trærne å legges oppå hverandre, og forgrener seg fra det opprinnelige Taproot-skripttreet for å representere et effektivt ubegrenset antall eiendeler i en enkelt Taproot UTXO. Taro-eiendeler utstedes derfor på kjede.
På grunnlag av aktivafunksjonalitet på Taro er et aktivaskript, et sett med direktiver etablert av en utvikler for å programmere definere hvordan en gitt ressurs kan overføres på protokollen. Hash-en til det skriptet blir deretter inkludert i MS-SMT, slik at det enkelt kan håndheves senere - og dermed få ressursen og dens attributter til å forplikte seg til asset-skript-hashen.
Den første versjonen av Taro foreslår bruk av en undergruppe av Bitcoin-skript, som lar eiendeler uttrykke vilkårlige betingelser for gyldig overføring av en eiendel. Ettersom aktivaskripter arver et nivå av programmerbarhet på nivå med Bitcoin Script, kan Taro-aktiva overføres over Lightning i multi-hop-transaksjoner utenfor kjeden gjennom hash-tidslåste kontrakter (HTLCs) innebygd i aktivaskriptet. Imidlertid kan fremtidige versjoner introdusere nye opkoder og ekstra funksjonalitet som bare vil eksistere på Taro-nivå.
"Å gjøre Taproot-within-Taproot gjør den første versjonen enklere og gir oss mer tid til å finne ut hvilke brukstilfeller som dukker opp og ønsker mer uttrykksevne," sa Osuntokun.
For overføringer i kjeden bruker Taro et nytt adresseformat basert på bech32 som også inkluderer asset script hash. For å motta en Taro-aktiva på kjede, må mottakeren opprette en adresse med nok data som beskriver hvordan avsenderen kan konstruere en ny aktivaskriptgruppe som inneholder informasjonen som trengs for å bruke eiendelen når den er overført til den nye eieren. Med andre ord, den ekstra informasjonen, i asset script hash, forteller mottakeren hva opplåsingsevnen er for eiendelen som blir overført, slik at den til slutt kan overføres igjen.
Siden mottakeren har all denne informasjonen, kan de beregne aktivabladet, som deretter lar dem beregne aktivaroten, og til slutt hele produksjonen selv, slik at de kan se på Bitcoin-blokkjeden for resultatet de beregnet.
I tillegg, ved å la mottakeren sende den definerende informasjonen på forhånd, er den eneste måten avsenderen kan gjøre transaksjonen gyldig på hvis de sender nøyaktig det mottakeren forventer. Hvis feil aktiva eller feil beløp sendes, vil ikke hashen samsvare, og mottakeren kan enkelt fortelle at avsenderen gjorde noe galt.
Eiendeler og samleobjekter på Bitcoin
Utstedelse og overføring av eiendeler i Taro varierer, avhengig av om eiendelen er en vanlig eller et samleobjekt.
En samleobjekt, eller ikke-fungibel eiendel, er en unik representasjon av verdi, med en unik identifikator som etablerer et krav på en eiendel på Bitcoin-kjedenivå eller på virkelighetsnivå og gjør det umulig å falskt eierskap. Et samleobjekt på Taro kan for eksempel være et symbolisert sjeldent baseballkort. Samleobjekter opprettes i en enkelt batch-transaksjon, kan ikke deles eller slås sammen, og må overføres utenfor kjeden eller settes inn i en flerpartskanal for å overføres mellom et kjent sett med deltakere.
En vanlig eiendel, på den annen side, forplikter seg til en total verdi av eiendeler og kan deles og slås sammen. Splittinger kan skje innenfor et tre, konfigurere en intern splitt, eller på tvers av forskjellige Taproot-utganger, konfigurere en ekstern splitt. Under overføring beviser eiendelsinnehaveren at de har en gyldig splittelse med et Merkle-Sum-bevis, og de tilsvarende opprettede eiendelene forplikter seg til en ny Merkle-Sum output-split som sikrer at det totale beløpet av eiendeler etter overføring er lik det totale beløpet det var før transaksjonen .
Eiendeler ved kantene: Lyn som et desentralisert betalingsnettverk
Som nevnt tidligere, kan Taro portere eiendeler utstedt på kjeden til Lightning Network, på samme måte som bitcoin kan sendes gjennom Lightning etter å ha blitt låst opp i en to-av-to multisignaturutgang som blir bekreftet på Bitcoin-blokkjeden. En Lightning-kanal som inneholder Taro-aktiva utnytter den samme flyten, men to-av-to Schnorr Taproot-utgangen vil også forplikte seg til settet med aktiva i kanalen.
"Ved å bruke Taro-protokollen, er Lightning-kanaler forankret med en Taproot-utgang i stand til å sende både bitcoin- og Taro-eiendeler utenfor kjeden, med multi-hop-betalinger tilrettelagt av nye HTLC-er på Taro-nivå, som bruker skriptsystemet til å implementere det forventede ende-til-ende betalingssikkerhetsgarantier," fortalte Osuntokun Bitcoin Magazine.
Osuntokun la til at Lightning Labs' foreslåtte distribusjonsbane for Taro på Lightning Network søker å først bare introdusere eiendeler i kantene, noe som betyr at det vil unngå både å måtte modifisere kjernen av nettverket og starte opp et nytt nettverk med tilstrekkelig likviditet for hver Taro-aktiva. . Snarere vil selskapets planer ha Taro til å koble til bitcoin-likviditet på Lightning og kreve at bare avsender og mottaker av en gitt eiendel bruker Taro-bevisste kanaler.
"Den eneste begrensningen er at for å motta/sende ved å bruke en bestemt eiendel, kreves tilsvarende inngående/utgående likviditet," sa Osuntokun.
I tillegg til det lignende Lightning on-ramp-oppsettet, ville multi-hop-overføringer av Taro-eiendeler over Lightning utnytte et lignende faktureringssystem som er vanlig på det andre laget i dag. I stedet for å angi fakturaen i BTC, vil imidlertid fakturaen være denominert i selve Taro-eiendelen.
"Som et eksempel, hvis Alice ønsker å sende Bob en Taro stablecoin-eiendom, vil hun lage en ny faktura som siterer for eksempel $10," sa Osuntokun. "Bob vil da bruke et "hop hint", som er ekstra rutedetaljer som er oppgitt på fakturaen for å fullføre ruten og beregne mengden nettverksavgifter (betalt i bitcoin) for å sende over hans første hopp, som vil krysse den interne Bitcoin-ryggraden og til slutt slippe av nok BTC ved det siste hoppet til å fullføre betalingen."
Taro-protokollen vil spesifisere den ekstra informasjonen som må sendes til Lightning-kollegene i kantene for å oppdatere alle kanaler riktig, la han til.
Gjør Bitcoin til De-Facto Base Layer
Taro søker å utnytte Bitcoins siste soft fork-oppgradering for å bringe eiendeler med ekte ordbruk, som amerikanske dollar stablecoins, inn i peer-to-peer (P2P) digitale valutastabel. Det muliggjør utstedelse av et nesten ubegrenset antall eiendeler med en enkelt Taproot UTXO, samt overføring av slike eiendeler med umiddelbare, lavpris multi-hop-transaksjoner på Lightning.
Ved å utnytte Bitcoin og Lightning som sine skinner, kan Taro etablere et interoperabelt økosystem av eiendeler som kan forene ulike brukstilfeller uten å påvirke parter som kanskje ikke bryr seg om slike eiendeler. Samtidig bidrar protokollen også tilbake til Bitcoin ved å øke nettverkseffektene i tilfelle en popularisering av konseptet driver trafikk på nettverket, og øker dermed gebyrutbetalingen til gruvearbeidere og øker BTC-likviditeten på Lightning Network.
Selv om den første iterasjonen rommer et begrenset antall brukstilfeller, i et forsøk på å gjøre hoppet til den nye protokollen enklere for utviklere gjennom en kjent Bitcoin-skriptpakke, er mulighetene for utvidelser og videreutvikling nesten uendelige, ettersom byggere og gründere blir kreative og spinne protokollen for å passe deres behov.
"Håpet er å åpne opp folks øyne for hva fremtiden til Bitcoin bringer og hva Taproot kan muliggjøre," sa Stark Bitcoin Magazine. "Målet er å få Bitcoin til å være det underliggende globale monetære nettverket drevet av åpne protokoller."
- Om oss
- adgang
- Logg inn
- tvers
- aktivitet
- tillegg
- Ytterligere
- adresse
- Alle
- tillate
- blant
- beløp
- En annen
- tilnærming
- eiendel
- Eiendeler
- attributter
- baseball
- I utgangspunktet
- basis
- være
- Bit
- Bitcoin
- bitcoin transaksjoner
- Bitcoin UTXO
- Blokker
- blockchain
- BTC
- Kapasitet
- hvilken
- saker
- konsernsjef
- kjede
- endring
- kanaler
- Coin
- samleobjekter
- engasjement
- samfunnet
- Selskapet
- Selskapets
- helt
- komplekse
- Beregn
- konsept
- tilstand
- Konsensus
- konstruksjon
- inneholder
- kontrakter
- Kjerne
- kunne
- Falske
- opprettet
- Kreativ
- CTO
- valuta
- dato
- desentralisert
- Etterspørsel
- avhengig
- distribusjon
- utforming
- Utvikler
- utviklere
- utviklingen
- gJORDE
- forskjellig
- digitalt
- digital valuta
- direkte
- ikke
- Dollar
- dobbelt
- Drop
- lett
- økosystem
- effekt
- effekter
- muliggjøre
- muliggjør
- sikrer
- gründere
- ERC-20
- etablere
- etablert
- Event
- eksempel
- forventet
- utvidelser
- Mote
- tilbakemelding
- avgifter
- Figur
- Endelig
- Først
- flyten
- gaffel
- skjema
- format
- funksjon
- funksjonalitet
- videre
- framtid
- Global
- mål
- større
- Gruppe
- Vekst
- skje
- hash
- hashing
- å ha
- hold
- holder
- holder
- Hvordan
- Hvordan
- HTTPS
- iverksette
- umulig
- I andre
- inkludere
- inkludert
- økt
- økende
- indeks
- informasjon
- Internet
- utstedelse
- IT
- selv
- bli medlem
- tiltrer
- hoppe
- holde
- nøkkel
- kjent
- Labs
- siste
- lagdelte
- Nivå
- Leverage
- utnytter
- utnytte
- lett
- Lyn
- Lynnettet
- Begrenset
- Likviditet
- Liste
- lite
- låst
- Lang
- GJØR AT
- Making
- måte
- Match
- betyr
- Miners
- modell
- mer
- bevegelse
- nettverk
- ikke-fungible
- Antall
- One-of-a-like
- åpen
- rekkefølge
- Annen
- eieren
- eierskap
- p2p
- betalt
- deltakere
- betaling
- betalinger
- Ansatte
- muligheter
- mulig
- PoW
- pen
- hindre
- privatliv
- privat
- bevis
- Proof-of-arbeid
- eiendom
- forslag
- foreslått
- protokollen
- protokoller
- beviser
- motta
- regelmessig
- gjenværende
- representerer
- krever
- påkrevd
- Avslørt
- Rute
- Sa
- skalerbarhet
- skalerbar
- ordningen
- sikre
- sikkerhet
- Serien
- sett
- lignende
- SIX
- So
- Myk gaffel
- Solutions
- noen
- noe
- spesielt
- bruke
- utgifter
- Snurre rundt
- splittet
- spagaten
- stablecoin
- Stablecoins
- stable
- lagring
- oppbevare
- butikker
- strukturert
- subsidie
- levere
- bærekraftig
- system
- forteller
- Gjennom
- tid
- i dag
- sammen
- symbolbaserte
- tokens
- topp
- spor
- trafikk
- Transaksjonen
- Transaksjoner
- overføre
- overføres
- overføringer
- Stol
- oss
- forstå
- unik
- Oppdater
- us
- bruke
- brukernes personvern
- Brukere
- verdi
- Se
- Hva
- Hva er
- om
- mens
- innenfor
- uten
- ord
- ville
- null