Baserat på olika styrningskoncept optimerade EOSC-samhället EOSIO-valmekanismen, lanserade EOSC: s huvudnätverk på Genesis höjd 1 och fortsatte att iterera och uppgradera EOSC: s huvudnätverk, vilket gjorde att EOSC fortsätter att utvecklas mot ett decentraliserat högpresterande smart kontraktsplattform och lägga grunden för den storskaliga populariseringen av kryptoekonomin.

bakgrund

Kryptoekonomin har inlett ett kritiskt steg från sociala experiment till storskalig kommersiell användning.
Bakom storskalig kommersiell användning innebär ett stort transaktionstryck. För att effektivt bära enorma transaktionskrav måste ett blockchain -system först tillhandahålla tillräckligt stark prestanda. För att uppnå detta krävs högre krav för hela noden, såsom bättre konfiguration av hårdvarumaskiner, större lagringskapacitet, mer stabilt nätverk, snabbare bandbredd, lägre latens, etc. Det är uppenbart att den höga tröskeln för hela noden kommer att leda till en minskning av antalet blockproducerande noder som kan fungera stabilt. Om POS -mekanismen används i ett sådant blockchain -system kommer systemet snabbt att konvergera till en centraliserad situation. För att skapa en balans mellan hög prestanda och decentralisering är DPOS -konsensusalgoritmen utan tvekan det bästa valet för närvarande och den bästa lösningen för att hantera ett litet antal noder.
EOSIO baserat på DPOS-konsensusalgoritm kom till, och samhället såg början av storskalig kommersiell användning av kryptoekonomin för första gången. Huruvida valmekanismen är fullt effektiv är nyckeln till överlevnaden av DPOS -konsensusmekanismen, och det är också relaterat till om DPOS -konsensusmekanismen kan vidarebefordra POW för att leda nästa generation av krypteringsvåg.
För att påskynda ankomsten av eran med storskalig kommersiell användning av kryptoekonomin optimerade EOSC-samhället EOSIO-valmekanismen, lanserade EOSC: s huvudnätverk på Genesis höjd 1 och fortsatte att iterera och uppgradera EOSC: s huvudnätverk, så att EOSC fortsätter att utvecklas mot ett decentraliserat smart-plattform med hög prestanda.

konsensusmekanism

EOSC följer konsensusmekanismen för EOSIO, nämligen DPOS BFT -rörledningskonsensus. Till skillnad från EOSIO antar Eosc inte läget för EOSIO med ett block var 0,5 sekunder och en nod genererar 6 block. Var tredje sekund i EOSC kommer noder inte att generera block kontinuerligt. Även om noder kan minska väntetiden för packade transaktioner, är den nuvarande nätverksmiljön ofta inte idealisk, snabbblockgenerering kommer att påverka kedjans stabilitet och orsaka ett stort antal mikrogafflar.
Den nuvarande konsensusmekanismen för EOSIO är inte tillräckligt perfekt, men som en DAPP -plattform är blockbekräftelsetid inte den första prioriteringen av kedjoptimering. För EOSC måste konsensusmekanismen övervägas i en högbelastningsmiljö. I den nuvarande situationen där det parallella datorsystemet inte är perfekt är snabbt att förbättra den pipelinerade bekräftelsemekanismen mycket problematisk.
Den framtida konsensusmekanismen för EOSC kommer att utvecklas parallellt från två riktningar
1. Kompatibel med EOSIO -utveckling och uppdatera dess konsensusalgoritm. Vi bedömer utifrån den nuvarande utvecklingsframstegen för EOSIO. När EOSIO slutför parallell förbättring kommer konsensusalgoritmen att uppgraderas för att uppnå snabbare blockbekräftningstid.
2. Andra konsensusmekanismer baserade på bekräftelsesnummer kommer att anpassas för att komplettera den befintliga DPO: s konsensus. Å ena sidan kommer interaktionen mellan det inbäddade skikt 2 -kedjekonsensus och huvudkedjan att realiseras. Å andra sidan kan en mer decentraliserad tvärkedjemekanism uppnås med andra konsensusmekanismer.

eosc teknikförbättring

resursmodell baserad på hanteringsavgifter
Även om EOSIO: s CPU- och Net Resources -betalningsmodell är en bra design inom teknik, är den för komplex för användare och kan inte marknadsföra DAPP -utvecklare att optimera sina kontrakt. Å andra sidan kommer inköpsmetoden för EOSIO: s RAM att leda till vissa hamstringsbeteenden, vilket inte bidrar till utvecklingen av DAPP -ekosystemet. Av denna anledning designade EOSC innovativt en ny resursmodell. Genom praktisk optimering undersöker den resursmodellen baserad på hanteringsavgifter i en komplex smart kontraktsmiljö för att helt lösa resursproblemen som plågar EOS -ekosystemet.
Först och främst betalar EOSC användarens CPU- och nettoresursförbrukning i ett hanteringsavgiftsläge. För åtgärden som definieras av utvecklaren i DAPP kan DAPP -utvecklare ställa in den nödvändiga hanteringsavgiften för åtgärden. Systemet styr användningen av åtgärden baserat på detta. Å ena sidan underlättar detta användare att förstå konsumtionen av resurser, och å andra sidan främjar det också DAPP -utvecklare att optimera användningen av kontraktsresurser, så att hela ekosystemet kan utvecklas hälsosamt.
EOSC använder en molnuthyrningsvärd för att fördela RAM -resurser på ett sätt som liknar den för att hyra molnvärdar. Användare kan betala utgifterna för att hyra RAM -resurser genom att använda röstutdelningar, så att användare inte behöver oroa sig för hyresbetalning och också eliminera problemet med hyresavskott. Genom metoden "hyra och sälja" kan EOSC effektivt undvika spekulativt beteende mot RAM -resurser, så att utvecklingen av DAPP inte behöver störas av RAM -priser och effektivt främja byggandet av DAPP -ekosystem.
Medan han är djärvt innovativa och utforska nya resursmodeller undersöker EOSC också mekanismen som är förenlig med EOSIO -resursmodeller. För CPU- och nettoresurser kan användare betala avgifter baserade på utdelningsålder för att uppnå effekten av att få CPU- och nettoresurser som liknar EOSIO -inteckning. För RAM kan användare uppnå effekten av EOSIO baserat på marknadsköp genom att göra omröstningsutbyte, så att DAPP -utvecklare snabbt kan komma in i EOSIO från andra EOSIO -kedjor och smidigt vända sig till EOSC -resursmodellen.
smidig uppdateringsmekanism
Eoscs valmekanism uppmuntrar supernoder att aktivt delta i att främja tekniska uppgraderingar. Till skillnad från splittringen av Eosio Community Node -versionen, främjar EOSC aktivt tekniska uppgraderingar och uppdateringar i praktiken.
För att uppnå en jämnare inkompatibel uppgraderingsprocess har EOSC lagt till en uppsättning uppdateringsmekanismer baserade på höjden på det effektiva blocket. Gemenskapen kan bekräfta höjden på det effektiva blocket för en funktion genom flera tecken för att decentralisera den smidiga uppgraderingsprocessen. Till skillnad från EOSIO: s nyligen föreslagna taggningsschema baserat på blockutvidgningsdata är EOSC: s uppdateringsmekanism mer vänlig och gynnsam för förståelse. Eoscs första praxis av den decentraliserade "Soft Fork" -uppdateringsprocessen i den EOSIO-baserade kedjan, som är den grundläggande garantin för EOSC att fortsätta utvecklas för att lösa olika mekanismproblem.
Å andra sidan kan funktionen för att ställa in kedjedribut baserat på flera tecken ge samhället en uppsättning decentraliserad kedjekonfiguration och på kedjor. Olika parametrar och konfigurationer kan decentraliseras decentraliseras enligt den faktiska utvecklingen, så att samhället kan utvecklas bättre.
nodhjärtslagsmekanism och stabilt blockutgångsintervall
För att främja stabiliteten i huvudnätverket stärker EOSC: s konstruktion av alternativa noder ur den ekonomiska modellens perspektiv. Samtidigt lägger EOSC till en nodhjärtmekanism på kedjan för att främja noder för att stärka och förbättra deras stabilitet och främja mer stabilitet i hela huvudnätverket.
Baserat på hjärtslagsmekanismen kan EOSC bekräfta driften av noden, så att de felaktiga noderna straffas baserat på kedjan och därigenom ytterligare uppmanar konstruktionen av noder och förhindrar instabiliteten hos noderna från att agera i hela huvudnätverket.
Blockgenereringsintervallet ökas i början av starten, för att undvika tillfälliga mjuka gafflar på huvudnätverket när den nuvarande nätverksinfrastrukturen ännu inte är perfekt. Det halvsekunders blockgenereringsintervallet designat av EOSIO och mekanismen för att ansluta sex block till en nod kan säkert förbättra kedjans tillgänglighet i framtiden, men det är inte tillämpligt i den nuvarande nätverksmiljön. Med en pragmatisk inställning kommer blockgenereringsintervallet att ökas först, och efter att förhållandena är mogna i framtiden kommer den att ändras till snabb blockgenerering. Detta kan effektivt minska mjuka gafflar. Samtidigt kan minskningen av antalet block kraftigt öka synkroniseringsgraden för hela noden, så att det kan finnas fler fullständiga noder och därmed förbättra tillgängligheten för hela nätverket.
Fler kontraktslager API: er
För att göra det mer bekvämt för DAPP -utvecklare att utveckla kontrakt har vissa API: er lagts till och vissa specifika justeringar har gjorts på systemkontrakten.
Först läggs ett API för att erhålla blockhöjden, och utvecklare kan enkelt och effektivt få den aktuella blockhöjden. Baserat på detta API kan kontrakt effektivt undvika att blockera blockattacker och andra försök attacker. För det andra läggs ett API för att erhålla kedjekonfigurationsinformation, och utvecklare kan anpassa olika parameterkorrigeringar och kedjeuppgraderingar till kedjan vid kontraktslagret, så att kontraktet också kan följa kedjans uppgraderingsfunktion. Slutligen, för att undvika förfalskade valutaattacker, används oberoende kärntokenkontrakt innan kedjan startas, så att användare tydligt kan skilja förfalskade valutaattacker.
Anpassning av tvärkedjetjänster
I början av lanseringen förutspådde Force-teamet att stödet för korskin kommer att vara den grundläggande funktionen för offentliga kedjor i framtiden. Därför lanserade Force-teamet utvecklingen av Codex-projektet och etablerade Codex.Relay-stafettkedjan för att tillhandahålla relatjänster för varje kedja, för att inse korskolmekanismen mellan varje kedja, vilket kan ge mer fullständigt stöd för Codex.Relay. Genom supernoderna från de två kedjorna som driver varandra kan en "komplett" tvärkedjemekanism uppnås, det vill säga graden av decentralisering av någon kedja kommer inte att reduceras under tvärkedjeprocessen.
Genom tvärkedjemekanismen kan stor skalbarhet erhållas. Baserat på relatjänster kan lag 2-underkedjor läggas till. Vissa tjänster och DAPP med hög resursförbrukning kan köras baserat på underkedjor, och beräkningsresultaten eller kärntillstånd kan synkroniseras med relatjänsterna. På detta sätt kan speciella underkedjor som lagring, dator, dapp och slumpmässiga nummer läggas till för att utöka funktioner.
Den mycket anpassningsbara EOSIO -blockchainutvecklingsramen
Baserat på stafettjänster kan det lägga till lager 2-underkedjor. I framtiden kommer olika underkedjor att spela en stor roll i EOSIO-ekosystemet. Det bör emellertid noteras att för närvarande har blockchain -projektet med anpassade funktioner baserade på EOSIO fortfarande en hög tröskel. Av denna anledning har Force Team lanserat Codex.IO-projektet, som är en mycket anpassningsbar EOSIO-blockchain-utvecklingsram, sänker utvecklingströskeln för underkedjor och ger utvecklare en mer ekonomisk och vänlig underkedjan utvecklingsupplevelse.
Force Team har samlat mycket erfarenhet av att utveckla blockchain baserat på EOSIO under utvecklingsprocessen och hoppas också kunna ge fullt spel till sitt största värde. Codex.io är en "Out of the Box" Eosio Blockchain -utvecklingsram. Utvecklare kan snabbt starta en kedja baserad på Codex.io. Efter enkel konfiguration kan de anpassa olika symboler och fritt välja ekonomiska system och resursmodeller. På grundval av detta behöver utvecklare bara vara uppmärksamma på de problem som själva kedjan behöver lösa. Enligt detta kan de välja att implementera dem baserat på kontrakt eller infödda lager. Codex.io kan underlätta utvecklare att expandera i det ursprungliga lagret i kedjan för att lösa vissa prestationsproblem och kan också utöka kedjans funktioner.
Codex.io integrerar de expansionsfunktioner som föreslagits av de flesta EOSIO -kedjor. Med en inkluderande attityd tillåter Codex.io utvecklare att fritt kombinera funktioner på kedjan: inklusive minsta levande säkerhetssystem, kontosystem, olika svarta och vita listmekanismer, vanliga styrningsmekanismer och röstmekanismer och olika plug-ins.
Genom Codex.io kommer ett stort antal underkedjor i Layer 2 att integreras i framtiden, vilket kommer att ge oändlig expansion.