Bityuan er et simpelt, stabilt og udvideligt offentligt kædenetværk. I december 2013 blev BitYuan født. Oprindeligt blev det produceret af pre-mining airdrop + POW-konsensusmekanismen. I 2015 blev BitYuan-konsensusmekanismen opdateret til POS. Efter mere end fire års design og forskning blev BitYuan Blockchain 3.0 den 17. maj 2018 udviklet og testet, hovednetværket blev lanceret, og det blev opgraderet til: SPOS (Safe POS), det vil sige en sikker POS-konsensusmekanisme der optimerer tilfældige tal. Mere end 6 måneder senere, den 7. december 2018, blev Bitcoin (BTY) officielt åbnet på Github.
Forskningen og udviklingen af ​​Bityuan anvender den underliggende teknologi fra Hangzhou Complex Beauty Chain33, som er et offentligt kædeprojekt med en flerkædet (parallel offentlig kæde) arkitektur, der er blevet implementeret og implementeret. Flere parallelle offentlige kæder kan udvikles på Bityuan blockchain.Hver parallel offentlige kæde har ikke kun forskelligartet og uafhængig blockchain økologisk konstruktion og DAPP-udvikling, men kan også realisere tværkædeudvekslingsfunktioner mellem flere kæder. Anvendelsesområderne for parallelle offentlige kædeprojekter omfatter: stabil valuta, røde kuverter, sociale netværk, e-handel, aktiv i kæden, gæld i kæden, certifikatindbetaling og spil.

Lagringsmetoder understøttet af projektet

BitYuan blockchain tog føringen i innovativ implementering af MVCCKVDB (multi-version KV data storage). Traditionelle blockchains gemmer data i form af merkle træer eller MPT træer. Hver gang dataene ændres,< br> Træet vil blive refaktoreret én gang, hvilket er relativt ineffektivt. For et 20-lags Merkle-træ kræver forespørgsel til data fra en bladknude for eksempel 20 læseoperationer at gennemføre, hvilket resulterer i, at effektiviteten af ​​dataforespørgsel kun er 1/20 af forespørgselseffektiviteten for almindelige databaser, som kan gennemføres pr. sekund Et system med 100.000 læseoperationer kan kun læse data på 5.000 transaktioner i sekundet, hvilket i høj grad begrænser systemets læseydelse. Ved skrivning af data er det også nødvendigt at indlæse data fra flere noder på trægrenen, og til sidst skrive det til disken efter opdatering Driftsforbruget i denne er også relativt stort. BitYuan trækker på MVCC-konceptet (Multi-Version Concurrency Control) i databasedesign og designer et originalt KVMVCC-datalagringsformat for at forbedre ineffektiviteten af ​​MAVL- eller MPT-strukturer. Opfylde behovet for at opretholde høj datalæse- og skriveydeevne efter blockchain-dataene vokser til en vis skala.
Hash-beregning:
statehash=hash (prevstatehash, KVSet, højde), som indeholder tilstands-hash-informationen for den forrige blok, tilstandsdata-KVSet-informationen for denne blok og den aktuelle blokhøjdeoplysninger (det vil sige versionsoplysninger).
Følgende korrespondance vil blive gemt i databasen for hver node:
hash->height(version)
height(version)->hash
key:height(version)->value
lastest:key->value
Dataforespørgsel:
Den tilsvarende højde (version) kan findes i henhold til statehash, og når den tilsvarende højde kan findes i henhold til højden, den specifikke nøgleværdi svarer til Værdiværdien.
Databekræftelse:
For et KVSet med en specifik højde kan Hash-operationer udføres i henhold til hash-værdierne prevstatehash, KVSet og højden af ​​den forrige blok. værdierne matcher, dataene er ikke blevet manipuleret, ellers er dataene ændret, eller dataene er forkerte (højden er forkert, eller KVSet-dataene er forkerte).
Vedligeholdelse af den seneste version af data:
Især, når du gemmer nøglen og værdien af ​​den seneste blok, skal du samtidig beholde (ny nøgle) eller opdatere (har allerede historikken) Versionsnøgle) nøgle:nyeste->værditilknytningsforhold gemmes i den lokale nøgleværdidatabase. Når du har brug for at indhente de seneste batchdata, kan du forespørge de seneste data i batches i henhold til det seneste præfiks (kan tilpasses). Da den sædvanlige nøgleværdidatabase godt kan understøtte præfiksmatchende forespørgsler, vil forespørgselseffektiviteten være relativt høj, meget højere end forespørgslen i Merkle-trælagerstrukturen.

Projekt super node

For at forbedre blockchainens ydeevne vedtager den parallelle offentlige kæde generelt DPOS (Share Authorization Proof Mechanism) konsensus, det vil sige, at flere superknudepunkter er udvalgt i kæden for at betale computerkraft og bredbåndsstøtte
Transaktionsinformationen skal pakkes ind i blokken, og blokinformationen udsendes til andre knudepunkter, og transaktionsinformationen gemmes på blokken for at spille funktionen til i fællesskab at styre fællesskabet.
Uanset om en offentlig kæde er vellykket eller ej, er en af ​​nøglemålingerne antallet af noder i kæden. Superknudemekanismen kan hjælpe den parallelle offentlige kæde til hurtigt at etablere en økologi på kæden og stole på driften og vedligeholdelsen af ​​hver superknude for at fremme velstanden i den parallelle offentlige kædeøkologi og realisere et mere stabilt, kraftfuldt og decentraliseret område Blockchain system.
Samtidig kan den parallelle offentlige kædeoperatør oprette et parallelkædefundament for at fremme initiativet og entusiasme fra superknudepunkter gennem forskellige symbolske incitamentsmekanismer og driftsmetoder for fonden for superknudepunkter og gennem tilbagekøb af tokens , transaktionsprocedurer At fremme en sund og bæredygtig udvikling af den parallelle offentlige kæde.

Projektet understøtter Oracle-funktion

Orakelmaskinen indser koblingen mellem blockchain og den virkelige verden. Orakelmaskinen er en betroet enhed, der introducerer information om tilstanden i den ydre verden gennem signaturer, og derved tillader deterministiske smarte kontrakter at bestemme det usikre. br> Omverdenen reagerer. Orakelmaskinen har karakteristika af ikke-manipulerbar, stabil service og auditerbar.
Oracle kontraktens frigivelsesdata er opdelt i tre trin:
(1) Frigivelsesdatafrigivelsesbegivenhed (underret hele netværket om, at resultatet af en begivenhed vil blive annonceret i fremtiden, og tildel et unikt hændelses-id, hvis hændelsen er ikke fundet og kan fortrydes).
(2) Forudgivelsesresultater (dataudbyderen udgiver tidsresultaterne på forhånd, hvis resultaterne viser sig at være problematiske af revisionen, kan de tilbagekaldes).
(3) Offentliggør resultaterne (efter at præ-release-resultaterne er revideret, vil de endelig blive frigivet på hele netværket, som ikke kan ændres og kan revideres og spores).
Andre kontrakter (såsom gættekontrakter) kan bruge begivenheds-id'et og specifikke begivenheder i ovenstående trin 1 til at udføre (gætte) aktiviteter. Når resultaterne af trin 3 annonceres, vil gættekontrakten udløse kontrakten til at fuldføre gætteafregningen i henhold til resultatet svarende til hændelses-ID , for at opnå en objektiv, troværdig, reviderbar og sporbar retfærdig gæt uden menneskelig indblanding.