Basert på forskjellige styringskonsepter har EOSC-fellesskapet optimalisert EOSIO-valgmekanismen, lansert EOSC-hovednettet på Genesis Height 1, og fortsatt å iterativt oppgradere EOSC-hovednettet, noe som får EOSC til å bevege seg mot en desentralisert høy. kontraktsplattformen fortsetter å utvikle seg, og legger grunnlaget for storskala popularisering av den krypterte økonomien.

Bakgrunn

Krypteringsøkonomien har innledet et kritisk stadium fra sosial eksperimentering til storskala kommersiell bruk.
Storskala kommersiell bruk betyr enormt transaksjonspress. For at et blokkjedesystem effektivt skal kunne bære en enorm mengde transaksjonskrav, må det først gi tilstrekkelig sterk ytelse. For å oppnå dette kreves det høyere krav til fulle noder, som bedre konfigurerte maskinvaremaskiner, større lagringskapasitet, mer stabilt nettverk, raskere båndbredde, lavere ventetid og så videre. Åpenbart vil en for høy terskel for fulle noder føre til en reduksjon i antall blokkproduserende noder som kan operere stabilt Hvis POS-mekanismen tas i bruk i et slikt blokkjedesystem, vil systemet raskt konvergere til en sentralisert situasjon. For å finne en balanse mellom høy ytelse og desentralisering, er DPOS-konsensusalgoritmen utvilsomt det beste valget for øyeblikket, og det er også den best mulige løsningen for å administrere et lite antall noder.
EOSIO basert på DPOS-konsensusalgoritmen ble til, og samfunnet så begynnelsen av storskala kommersiell bruk av krypteringsøkonomien for første gang. Hvorvidt valgmekanismen er fullt ut effektiv er nøkkelen til overlevelsen av DPOS-konsensusmekanismen, og det er også relatert til om DPOS-konsensusmekanismen kan etterfølge POW og lede neste generasjons kryptering.
For å akselerere ankomsten av æraen med storskala kommersiell bruk av krypteringsøkonomien, har EOSC-fellesskapet optimalisert EOSIO-valgmekanismen, lansert EOSC-nettverket på Genesis 1, og fortsatt å iterativt oppgradere EOSC-hovednettet, få EOSC til å bevege seg mot Retningen til en desentralisert høyytelses smart kontraktsplattform fortsetter å utvikle seg.

Konsensusmekanisme

EOSC følger konsensusmekanismen til EOSIO, det vil si DPOS BFT Pipeline Consensus. I motsetning til EOSIO, tar ikke EOSC i bruk EOSIOs modell med én blokk hvert 0,5 sekund, og én node kobler sammen 6 blokker. I EOSC, én blokk hvert 3. sekund , Noder vil ikke kontinuerlig produsere blokker, selv om kontinuerlig blokkproduksjon av noder kan redusere ventetiden for upakkede transaksjoner, men fordi det nåværende nettverksmiljøet ofte ikke er særlig ideelt, vil rask blokkproduksjon påvirke stabiliteten i kjeden, noe som resulterer i en stor antall mikrogafler.
Den nåværende konsensusmekanismen til EOSIO er ikke perfekt, men som en DAPP-plattform er ikke blokkbekreftelsestiden den første optimaliseringsprioriteten i kjeden. For EOSC må konsensusmekanismen vurderes i et miljø med høy belastning. I den nåværende parallelle databehandlingsmekanismen Hvis den ikke er perfekt, vil det å skynde seg å forbedre den pipelinede bekreftelsesmekanismen forårsake store problemer.
Den fremtidige konsensusmekanismen til EOSC vil utvikle seg parallelt fra to retninger
1. Kompatibel med EOSIO-utviklingen og oppdaterer konsensusalgoritmen, vurderer vi i henhold til den nåværende utviklingsfremgangen til EOSIO, når EOSIO fullfører den parallelle forbedringen, konsensusalgoritmen vil bli oppgradert, Oppnå raskere blokkbekreftelsestid.
2. Den vil tilpasse seg andre konsensusmekanismer basert på bekreftelsestall, som et supplement til eksisterende DPOS-konsensus, på den ene siden vil den realisere interaksjonen mellom innebygd Layer 2-kjedekonsensus og hovedkjeden. På den annen side kan den realisere en mer desentralisert tverrkjedemekanisme med kjeder av andre konsensusmekanismer.

EOSC-teknologiforbedring

Ressursmodell basert på serviceavgift
Selv om betalingsmodellen til EOSIOs CPU- og NET-ressurser er et godt design innen teknologi, er den for komplisert for brukere og kan ikke fremme DAPP-utviklere som optimaliserer kontraktene sine . På den annen side vil kjøpsmetoden til EOSIOs RAM føre til visse hamstringsatferder, noe som ikke bidrar til utviklingen av DAPP-økologi. Av denne grunn utformet EOSC innovativt et nytt sett med ressursmodeller. Gjennom optimalisering i praksis, utforske ressursmodeller basert på serviceavgifter i et komplekst smart kontraktsmiljø, og grundig løse ressursproblemene som plager EOS-økologien.
Først og fremst betaler EOSC brukerens CPU- og NET-ressursforbruk i gebyrmodus. For handlingen som er definert av utvikleren i DAPP, kan DAPP-utvikleren angi det nødvendige gebyret for handlingen, og systemet kontrollerer ressursen bruk av handlingen basert på dette , På den ene siden er det lett for brukere å forstå ressursforbruket, på den andre siden fremmer det også DAPP-utviklere sterkt til å optimalisere bruken av kontraktsressurser, slik at hele økologien utvikler seg godartet.
EOSC bruker en metode som ligner på å leie skyverter for å allokere RAM-ressurser. Brukere kan bruke stemmeutbytte til å betale for leie av RAM-ressurser. På denne måten trenger ikke brukere å bekymre seg for å betale husleie, og problemet med restanse på husleie er også eliminert. Gjennom metoden for "utleie og salg" kan EOSC effektivt unngå spekulasjoner i RAM-ressurser, slik at utviklingen av DAPP ikke trenger å bli forstyrret av prisen på RAM, og effektivt fremmer den økologiske konstruksjonen av DAPP.
Mens EOSC dristig innoverer og utforsker nye ressursmodeller, utforsker EOSC også mekanismer for å være kompatible med EOSIOs ressursmodeller. For CPU- og NET-ressurser kan brukere betale avgifter basert på alder for utbyttebillett for å oppnå et lignende EOSIO-lån for å få CPU og effekten av NET-ressurser, for RAM, brukere kan oppnå effekten av EOSIO basert på markedskjøp gjennom form av boliglånsstemmebytte, slik at DAPP-utviklere raskt kan skjære inn i EOSC fra andre EOSIO-kjeder, og jevnt bytte til EOSC-ressursen modell.
Smidig oppdateringsmekanisme
EOSCs valgmekanisme oppfordrer supernoder til å delta aktivt i å promotere teknologioppgraderinger. I motsetning til delingen av EOSIO fellesnodeversjoner, fremmer EOSC aktivt teknologioppgraderinger og fornyelse.
For å oppnå en jevnere inkompatibel oppgraderingsprosess har EOSC lagt til en oppdateringsmekanisme basert på den effektive blokkhøyden. Fellesskapet kan bekrefte den effektive blokkhøyden til en funksjon gjennom multisignatur, for å fullføre den jevne oppgraderingen i en desentralisert prosess, forskjellig fra EOSIOs nylig foreslåtte merkeordning basert på blokkutvidelsesdata, er EOSCs oppdateringsmekanisme mer vennlig og lett å forstå. EOSC var den første som praktiserte den desentraliserte «soft fork»-oppdateringsprosessen i den EOSIO-baserte kjeden, som Det er den grunnleggende garantien for den kontinuerlige utviklingen av EOSC for å løse ulike mekanismeproblemer.
På den annen side kan funksjonen med å sette kjedeattributter basert på multisignatur gi fellesskapet et sett med desentraliserte kjedekonfigurasjoner og on-chain-løsninger. Ulike parametere og konfigurasjoner kan endres på en desentralisert måte i henhold til faktiske utvikling, for bedre samfunnsutvikling.
Node-hjerteslagmekanisme og stabilt blokkeringsintervall
For å fremme stabiliteten til hovednettverket har EOSC styrket konstruksjonen av kandidatnoder fra økonomisk modellperspektiv. , EOSC har lagt til kjede. Hjerteslagmekanismen til noden på nettverket brukes til å fremme styrkingen av noden for å forbedre stabiliteten og fremme stabiliteten til hele hovednettverket.
På grunnlag av hjerteslagmekanismen kan EOSC bekrefte driften av nodene, slik at de defekte nodene kan straffes basert på kjeden, for å overvåke konstruksjonen av noder ytterligere og forhindre at nodenes passivitet forårsaker ustabiliteten til hele hovednettet.
Øk blokkeringsintervalltiden ved begynnelsen av lanseringen, for å unngå sporadiske myke gafler på hovednettverket når den nåværende nettverksinfrastrukturen ennå ikke er perfekt EOSIO designet et halvt sekunds blokkintervall og et selv om mekanismen til noder som produserer seks blokker på rad kan forbedre tilgjengeligheten til kjeden i fremtiden, det er ikke aktuelt i dagens nettverksmiljø. På en pragmatisk måte bør intervallet mellom blokkproduksjon økes først, og deretter endres til rask blokkproduksjon når forholdene er modne i fremtiden. Dette kan effektivt redusere myke gafler, og samtidig kan reduksjonen i antall blokker øke synkroniseringshastigheten til fulle noder, slik at det kan være flere fulle noder, og dermed forbedre tilgjengeligheten til hele nettverket.
Flere kontraktslag-APIer
For å gjøre det enklere for DAPP-utviklere å utvikle kontrakter, er noen API-er lagt til, og noen spesifikke justeringer er gjort i systemkontraktene.
Først og fremst legges det til et API for å oppnå blokkhøyden. Utviklere kan enkelt og effektivt få tak i gjeldende blokkhøyde. Basert på denne APIen kan kontrakten effektivt unngå blokkering av blokkeringsangrep og andre forsøksbaserte angrep. For det andre, add For å få API for kjedekonfigurasjonsinformasjon, kan utviklere tilpasse ulike parameterkorrigeringer og kjedeoppgraderinger av kjeden på kontraktslaget, slik at kontrakten også kan følge kjedeoppgraderingsfunksjonen jevnt. Til slutt, for å unngå falsk valuta angrep, før kjeden starter, brukes en uavhengig kjerne-token-kontrakt, slik at brukerne tydelig kan skille mellom falske valutaangrep.
Tilpasning til tverrkjedetjenester
Ved starten av lanseringen forutså Force-teamet at støtten for tverrkjeder i fremtiden vil være den grunnleggende funksjonen til den offentlige kjeden, så Force-teamet startet Codex-prosjektet Development, etablere Codex.Relay-relékjeden for å tilby relétjenester for hver kjede, for å realisere tverrkjedemekanismen mellom hver kjede, kan gi mer perfekt støtte for Codex.Relay, og samvirke gjennom supernodene til de to kjedene , kan oppnå en "komplett" krysskjedemekanisme, det vil si at graden av desentralisering av en hvilken som helst kjede ikke vil reduseres under krysskjedeprosessen.
Gjennom krysskjedemekanismen kan man oppnå stor skalerbarhet Basert på relétjenesten kan Layer 2 underkjeder legges til Enkelte tjenester og DAPPer som bruker store ressurser kan kjøres på basis av underkjeder. Gjennom relétjenesten synkroniseres Beregningsresultatene eller kjernetilstanden til , slik at spesielle underkjeder som lagring, beregning, DAPP og tilfeldige tall kan legges til i fremtiden for å utvide funksjoner.
Svært tilpassbart EOSIO blockchain-utviklingsrammeverk
Basert på relétjenester kan Layer 2-underkjeder legges til, og ulike underkjeder vil spille en rolle i EOSIO-økologien i fremtiden. har stor effekt, men det bør bemerkes at den nåværende utviklingen av et blokkjedeprosjekt med tilpassede funksjoner basert på EOSIO fortsatt har en høy terskel. Derfor har Force-teamet lansert Codex.io-prosjektet, som er et svært tilpassbart prosjekt. EOSIO blockchain-utviklingsrammeverket senker terskelen for underkjedeutvikling og gir utviklere en mer økonomisk og vennlig utviklingsopplevelse for underkjede.
Force-teamet har samlet mye erfaring med å utvikle blokkjeder basert på EOSIO under utviklingsprosessen, og håper å maksimere verdien av disse erfaringene Codex.io er en "out-of-the-box" EOSIO blokkjede utviklingsrammeverk, utviklere kan raskt starte sin egen kjede basert på Codex.io, etter enkel konfigurasjon kan de tilpasse ulike symboler, fritt velge økonomisk system og ressursmodell, på dette grunnlaget trenger utviklere bare å ta hensyn til kjeden Problemet med å løses av seg selv kan implementeres basert på kontrakten eller det opprinnelige laget i kjeden. Codex.io kan gjøre det lettere for utviklere å utvide i det opprinnelige laget av kjeden, for å løse noen ytelsesproblemer, og kan også utvide kjeden betydelig. Funksjon.
Codex.io integrerer utvidelsesfunksjonene foreslått av de fleste av de nåværende EOSIO-kjedene. Med en inkluderende holdning lar Codex.io utviklere fritt kombinere funksjoner i kjeden: inkludert kostpengersystem, kontosystem, ulike svarte og hvite lister mekanismer , vanlige styringsmekanismer og stemmemekanismer, og ulike plug-ins.
Gjennom Codex.io vil et stort antall Layer 2-underkjeder bli integrert i fremtiden, noe som vil gi ubegrenset skalerbarhet.