A különböző irányítási koncepciók alapján az EOSC közösség optimalizálta az EOSIO választási mechanizmust, elindította az EOSC főhálózatát az 1. Mózes magasságban, és folytatta az EOSC főhálózatának iterációját és frissítését, így az EOSC tovább fejlődik a decentralizált, nagy teljesítményű intelligens szerződéses platform felé, amely alapja az alapot a kripto gazdaság nagymértékű népszerűsítésének.

háttér

A kriptogazdaság kritikus szakaszba került a társadalmi kísérletektől a nagyszabású kereskedelmi felhasználásig.
A nagyszabású kereskedelmi felhasználás mögött óriási tranzakciós nyomást jelent. A hatalmas tranzakciós igények hatékony viselése érdekében a blokklánc -rendszernek először kellően erős teljesítményt kell biztosítania. Ennek elérése érdekében a teljes csomópontra, például a hardvergépek jobb konfigurációjára, a nagyobb tárolókapacitásra, a stabilabb hálózatra, a gyorsabb sávszélességre, az alacsonyabb késéssel stb., A teljes csomópont nagy küszöbértékének csökkentéséhez vezet a teljes csomópont jobb konfigurációja, a teljes csomópontok száma, amelyek stabilan működhetnek. Ha a POS -mechanizmust ilyen blokklánc -rendszerben használják, a rendszer gyorsan konvergál egy központosított helyzethez. A nagy teljesítmény és a decentralizáció közötti egyensúly elérése érdekében a DPOS konszenzus algoritmus kétségtelenül a legjobb választás és a legjobb megoldás néhány csomópont kezelésére.
A DPOS konszenzus algoritmuson alapuló EOSIO jött létre, és a közösség először látta a kriptogazdaság nagyszabású kereskedelmi használatát. A választási mechanizmus teljes mértékben hatékony -e, hogy a DPOS konszenzus mechanizmusának túlélésének kulcsa, és azzal is kapcsolódik, hogy a DPOS konszenzus mechanizmusa képes -e átadni a POW -ot a titkosítási hullám következő generációjának vezetéséhez.
A kriptogazdaság nagyszabású kereskedelmi felhasználásának korszakának felgyorsítása érdekében az EOSC közösség optimalizálta az EOSIO választási mechanizmust, elindította az EOSC főhálózatát a Genesis Height-nál, és folytatta az EOSC főhálózatának iterációját és frissítését, hogy az EOSC tovább fejlődjön egy tisztességes, nagy teljesítményű, intelligens szerződéses platform felé.

konszenzus mechanizmus

EOSC követi az EOSIO konszenzus mechanizmusát, nevezetesen a DPOS BFT csővezeték konszenzusát. Az EOSIO -val ellentétben az EOSC nem alkalmazza az EOSIO módját egy blokkkal 0,5 másodpercenként, és egy csomópont 6 blokkot generál. Az EOSC 3 másodpercenként a csomópontok nem generálnak blokkokat folyamatosan. Noha a csomópontok csökkenthetik a kicsomagolt tranzakciók várakozási idejét, a jelenlegi hálózati környezet gyakran nem ideális, a gyors blokkok generálása befolyásolja a lánc stabilitását, és nagyszámú mikrovillát okoz.
Az EOSIO jelenlegi konszenzus mechanizmusa nem elég tökéletes, de DAPP platformként a blokk -megerősítési idő nem a lánc optimalizálásának elsődleges prioritása. Az EOSC esetében a konszenzus mechanizmust nagy terhelésű környezetben kell figyelembe venni. A jelenlegi helyzetben, amikor a párhuzamos számítógépes rendszer nem tökéletes, a csővezetékes megerősítő mechanizmus sietve nagyon problematikus.
Az EOSC jövőbeli konszenzus mechanizmusa párhuzamosan fejlődik két irányból
1. Kompatibilis az EOSIO fejlesztéssel és frissítse konszenzus algoritmust. Az EOSIO jelenlegi fejlesztési fejlődése alapján ítéljük meg. Amikor az EOSIO befejezi a párhuzamos javulást, a konszenzusos algoritmust frissítik, hogy gyorsabb blokk -megerősítési időt érjenek el.
2. A megerősítő számokon alapuló egyéb konszenzus mechanizmusokat a meglévő DPO -k konszenzusának kiegészítésére adaptálják. Egyrészt a beágyazott 2. rétegű lánc konszenzus és a fő lánc közötti kölcsönhatás megvalósul. Másrészt egy decentralizáltabb keresztlánc-mechanizmus érhető el más konszenzus mechanizmusokkal.

EOSC technológia fejlesztése

Erőforrás -modell kezelési díjak alapján
Noha az EOSIO CPU és a Net Resource fizetési modellje jó tervezés a technológiában, ez túl bonyolult a felhasználók számára, és nem képes elősegíteni a DAPP fejlesztőket a szerződések optimalizálása érdekében. Másrészt az EOSIO RAM vásárlási módszere bizonyos felhalmozódási magatartást eredményez, ami nem segíti elő a DAPP ökoszisztéma kialakulását. Ezért az EOSC innovatívan új erőforrás -modellt tervezett. A gyakorlati optimalizálás révén feltárja az erőforrás -modellt, amely egy összetett intelligens szerződéses környezetben történő kezelési díjakon alapul, hogy teljes mértékben megoldja az EOS -ökoszisztémát sújtó erőforrások problémáit.
Mindenekelőtt az EOSC kezelési díj módban fizeti a felhasználó CPU -t és nettó erőforrás -fogyasztását. A DAPP fejlesztője által meghatározott művelethez a DAPP fejlesztői beállíthatják a művelethez szükséges kezelési díjat. A rendszer ennek alapján szabályozza a művelet használatát. Egyrészt ez megkönnyíti a felhasználókat az erőforrások fogyasztásának megértésében, másrészt pedig erősen elősegíti a DAPP fejlesztőket a szerződéses erőforrások használatának optimalizálására is, hogy az egész ökoszisztéma egészséges fejlődhessen.
Az EOSC felhőalapú gazdagépet használ a RAM -erőforrások elosztására, mint például a felhő -gazdagépek bérléséhez. A felhasználók a RAM -erőforrások bérleti költségeit a szavazási osztalék felhasználásával fizethetik, hogy a felhasználóknak ne kelljen aggódniuk a bérleti díj miatt, és kiküszöbölniük kell a bérleti hátralék problémáját. A "bérleti és eladási" módszerrel az EOSC hatékonyan elkerülheti a spekulatív viselkedést a RAM erőforrásokkal szemben, így a DAPP fejlesztését nem kell zavarni a RAM -árak, és hatékonyan elősegítve a DAPP ökoszisztéma felépítését.
Miközben merészen innovációt folytat és új erőforrásmodelleket vizsgál, az EOSC azt is feltárja, hogy az EOSIO erőforrás -modellekkel kompatibilisek legyenek. A CPU és a nettó erőforrások esetében a felhasználók az osztalékkor alapján fizethetnek díjakat az EOSIO jelzáloghoz hasonló CPU és nettó erőforrások megszerzése érdekében. A RAM esetében a felhasználók az EOSIO hatásait a piaci vásárlás alapján elérhetik a szavazási csere révén, így a DAPP fejlesztői gyorsan beléphetnek az EOSIO -ba más EOSIO láncokból, és zökkenőmentesen fordulhatnak az EOSC erőforrás -modellhez.
sima frissítési mechanizmus
Az EOSC választási mechanizmusa arra ösztönzi a szuper csomópontokat, hogy aktívan vegyen részt a technológiai frissítések előmozdításában. Az EOSIO közösségi csomópont verziójának megosztásával ellentétben az EOSC aktívan támogatja a technológiai frissítéseket és a frissítéseket a gyakorlatban.
A simább, összeegyeztethetetlen frissítési eljárás elérése érdekében az EOSC hozzáadott egy sor frissítési mechanizmushoz, amely a tényleges blokk magassága alapján. A közösség több jelzésen keresztül megerősítheti a funkció tényleges blokkjának magasságát, hogy decentralizálja a sima frissítési folyamatot. Az EOSIO nemrégiben javasolt címkézési sémájával ellentétben, a blokk -bővítési adatok alapján, az EOSC frissítési mechanizmusa barátságosabb és elősegíti a megértést. Az EOSC első gyakorlata az EOSIO-alapú láncban a decentralizált "Soft Fork" frissítési folyamatról, amely az EOSC alapvető garanciája a különféle mechanizmusproblémák megoldása érdekében.
Másrészt, a lánc-attribútumok több jel alapján történő meghatározásának funkciója biztosíthatja a közösség számára a decentralizált lánckonfigurációs és láncrendszereket. Különböző paraméterek és konfigurációk decentralizálhatók a tényleges fejlesztés szerint, hogy a közösség jobban fejlődhessen.
csomóponti szívverés mechanizmus és stabil blokk kimeneti intervallum
A fő hálózat stabilitásának elősegítése érdekében az EOSC megerősíti az alternatív csomópontok felépítését a gazdasági modell szempontjából. Ugyanakkor az EOSC hozzáad egy csomóponti szívverés mechanizmust a láncon, hogy elősegítse a csomópontokat, hogy erősítse és javítsa stabilitásukat, és elősegítse a teljes főhálózat nagyobb stabilitását.
A szívverés -mechanizmus alapján az EOSC megerősítheti a csomópont működését, így a hibás csomópontokat a lánc alapján büntetik, ezáltal tovább sürgeti a csomópontok felépítését és megakadályozva, hogy a csomópontok instabilitása a teljes főhálózatban való hatással legyen.
A blokkgenerációs intervallum időtartama az indítás elején növekszik, hogy elkerülje a fő hálózat alkalmi lágy villáit, ha a jelenlegi hálózati infrastruktúra még nem tökéletes. Az EOSIO által tervezett fél másodperces blokkgenerációs intervallum és a hat blokk egy csomóponthoz történő csatlakoztatásának mechanizmusa minden bizonnyal javíthatja a lánc elérhetőségét a jövőben, de ez nem alkalmazható a jelenlegi hálózati környezetben. Pragmatikus hozzáállás mellett a blokkgenerációs intervallum idejét először növelik, és miután a feltételek a jövőben érettek, a gyors blokkok generálására változik. Ez hatékonyan csökkentheti a lágy villákat. Ugyanakkor a blokkok számának csökkentése jelentősen növelheti a teljes csomópont szinkronizálási sebességét, így több teljes csomópont is lehet, ezáltal javítva a teljes hálózat elérhetőségét.
Több szerződéses réteg API
Annak érdekében, hogy a DAPP fejlesztői számára kényelmesebbé tegyék a szerződések kidolgozását, néhány API -t adtak hozzá, és néhány konkrét kiigazítást végeztek a rendszerszerződésekhez.
Először egy API hozzáadódik a blokkmagasság eléréséhez, és a fejlesztők könnyen és hatékonyan megszerezhetik az aktuális blokkmagasságot. Ezen API alapján a szerződések hatékonyan elkerülhetik a blokk-támadások és más újbóli alapú támadások blokkolását. Másodszor, hozzáadunk egy API -t a lánckonfigurációs információk beszerzéséhez, és a fejlesztők különféle paraméter -korrekciókat és láncfrissítéseket tudnak adaptálni a láncba a szerződésrétegnél, hogy a szerződés zökkenőmentesen kövesse a láncfrissítési funkciót. Végül, a hamis valuta támadások elkerülése érdekében, a lánc megkezdése előtt független alapvető token -szerződéseket kell használni, hogy a felhasználók egyértelműen megkülönböztessék a hamis valuta támadásokat.
A lánc-szolgáltatások adaptálása
A bevezetés elején az erõcsoport előre látta, hogy a láncok támogatása lesz a nyilvános láncok alapvető funkciója a jövőben. Ezért a Force csapata elindította a Codex projekt fejlesztését, és létrehozta a Codex.Relay relé láncot, hogy relé szolgáltatásokat nyújtson az egyes láncok számára, hogy megvalósítsa az egyes láncok közötti keresztezési mechanizmust, amely teljesebb támogatást nyújthat a Codex.Relay számára. A két egymással működő lánc szuper csomópontjain keresztül egy "teljes" keresztlánc-mechanizmus érhető el, azaz a lánc decentralizációjának mértéke nem csökken a láncok közötti folyamat során.
A keresztlánc-mechanizmus révén nagy méretezhetőség lehet elérni. A relé-szolgáltatások alapján a 2. réteg alláncai hozzáadhatók. Egyes szolgáltatások és DAPP-k, amelyek magas erőforrás-fogyasztással rendelkeznek, alláncok alapján futtathatók, és a számítási eredmények vagy az alapállapotok szinkronizálhatók a váltószolgáltatásokkal. Ilyen módon speciális alláncok, például tárolás, számítástechnika, DAPP és véletlenszerű számok hozzáadhatók a funkciók bővítéséhez.
A nagymértékben testreszabható EOSIO Blockchain fejlesztési keretrendszer
A relé-szolgáltatások alapján hozzáadhatja a 2. réteg alláncait. A jövőben a különféle alláncok nagy szerepet játszanak az EOSIO ökoszisztémában. Meg kell azonban jegyezni, hogy jelenleg az EOSIO -n alapuló testreszabott funkciókkal rendelkező blokklánc -projektnek továbbra is magas a küszöbérték. Ezért a Force Team elindította a Codex.io projektet, amely egy nagyon testreszabható EOSIO Blockchain fejlesztési keretrendszer, csökkentve az alláncok fejlesztési küszöbét, és gazdaságosabb és barátságosabb allánc-fejlesztési tapasztalatokat nyújt.
A Force csapata sok tapasztalatot halmozott fel a blokklánc fejlesztésében az EOSIO alapján a fejlesztési folyamat során, és reméli, hogy teljes játékot ad a legnagyobb értéknek. A Codex.io egy "Out the Box" eosio blockchain fejlesztési keret. A fejlesztők gyorsan elindíthatják a láncot a codex.io alapján. Az egyszerű konfiguráció után testreszabhatják a különféle szimbólumokat, és szabadon kiválaszthatják a gazdasági rendszereket és az erőforrás -modelleket. Ennek alapján a fejlesztőknek csak figyelmet kell fordítaniuk azokat a problémákat, amelyeket maga a láncnak meg kell oldani. Ennek megfelelően dönthetnek úgy, hogy szerződések vagy láncos rétegek alapján hajtják végre őket. A Codex.io megkönnyítheti a fejlesztőket a lánc natív rétegében történő kibővítésében, hogy megoldja bizonyos teljesítményproblémákat, és jelentősen kibővítheti a lánc funkcióit.
A CODEX.IO integrálja a legtöbb EOSIO lánc által javasolt bővítési funkciókat. Befogadó hozzáállással a Codex.io lehetővé teszi a fejlesztők számára, hogy szabadon kombinálják a láncon belüli funkciókat: beleértve a minimális életbiztonsági rendszert, a fiókrendszert, a különféle fekete-fehér lista mechanizmusokat, a közös kormányzási mechanizmusokat és a szavazási mechanizmusokat, valamint a különféle plug-ineket.
A Codex.io révén a jövőben számos 2. réteg alláncot integrálnak, amelyek végtelen bővítést biztosítanak.