Hva skjer i hver prosess med å spille labitbu? Lang advarsel, viss kunnskap om kryptografi og bitcoin-handel er nødvendig Labitbu er et lite bilde av Bitcoin-hovednettet som starter klokken 2 i dag, i motsetning til tidligere inskripsjons- eller kvasi-inskripsjonsprotokoller, er det avhengig av taproot-protokollen for å lagre lastinformasjon Prosjektet ble utviklet av @stutxo, den andre vinneren av årets @PlebFi hackathon, og det ser ut til at hackathonet har deltakelse fra utviklere fra Bitcoin Wizard og Ordinals, og det har fortsatt et visst gullinnhold GitHub-repositorium: Det er tre trinn når du caster et nettsted: 1. Koble til lommeboken og generer en tilfeldig labitbu. 2. Overføring til P2TR-adressen fra og med bc1p, nettstedet vil overføre 10 000 sats til denne adressen som standard; 3. Fullfør preging, fyll inn bc1p-adressen som tilsvarer lommebokens offentlige nøkkel i inntastingsboksen og send pregingstransaksjonen til kjeden. Koble først til lommeboken for å få den offentlige nøkkelen til bc1p-lommeboken, og generer deretter Labitbu basert på den offentlige nøkkelen. I følge json-filen i repoen kan det være kjent at det er 8 stiler for hver labitbu, og den største forskjellen er fargen. Men hvis det er en 10k NFT-samling, ser ikke fargen ut til å være nok til å skille mange labitbuer? Siden hver labitbu genereres basert på den offentlige nøkkelen til lommeboken, vil teoretisk sett alle labitbuer preget av hver lommebok ha samme stil (men noen ganger vil det være et tilfelle der lommeboken er preget i en annen stil under selve pregingen tidlig om morgenen, noe som kan skyldes noen utelatelser eller besvimelse 😇 om morgenen) Etter forrige trinn konverteres den genererte labitbuen til en bytedatanyttelast, og nettsiden bygger en kontrollblokk basert på denne nyttelasten. Det kalles build her, og den faktiske kontrollblokken er [kontrollbyte] + [indeks offentlig nøkkel] + [bildenyttelast]. I selve taproot-skriptet er kontrollblokken [kontrollbyte] + [intern offentlig nøkkel] + [Merkle-bane], og labitbu bruker bildenyttelasten direkte som Merkle-banen. TAPROOT Control Block Relatert innhold: Etter å ha brukt nyttelast som Merkle-banen og lommebokens offentlige nøkkel som låseskript, kan en P2TR-adresse genereres, som er BC1P-adressen på nettsiden, og prosessen med å sende BTC til denne lommeboken kan betraktes som en forpliktelse i inskripsjonsprotokollen. Til slutt må du fylle ut bc1p-adressen og lommeboken din for å fullføre den endelige pregingsoperasjonen. I denne prosessen låses fronten opp med bildenyttelasten som kontrollblokk, og det offentlige nøkkellåsskriptet brukes som utdata fra innløsningsskriptet, og lommeboken brukes til å signere og sende den endelige transaksjonen, som ligner på avsløringstransaksjonen i inskripsjonsprotokollen. Ovennevnte er det tekniske innholdet i prosessen med å støpe labitbu-protokollen, de tekniske detaljene i konstruksjonen av taproot-skriptet og genereringen av adresser er ikke skrevet, interesserte venner kan sjekke informasjonen og ta en titt Mynteprosessen til labitbu ligner mer på inskripsjoner, men fordelen med inskripsjoner er at forpliktelsen til pregingsprosessen ikke trenger å generere en ny adresse som et relé, og hele pregingsprosessen kan fullføres med en enkelt lommebok, noe som til en viss grad er mer praktisk. Det er imidlertid en begrensning at kontrollblokkstørrelsen er 4 kb, noe som begrenser størrelsen på bildebelastningen som kan lagres. I GitHub bruker dev en fast intern offentlig nøkkel for preging for enkel indeksering, så det kan sees at dev også planlegger å utføre neste trinn i indekseringen, og om det kan implementeres for transaksjoner kan bare ventes.

På dette tidspunktet bør pregingsvolumet overstige 10k, og ifølge tidligere erfaring er antall små bildesamlinger vanligvis 10k, så det anbefales ikke å fortsette pregingen nå