Tudom, tudom. Nagyon sok kriptoprojekt van, sok a konszenzus: munka és tulajdon alapján arany, olaj, sült piték (van, igen, igen). Mi kell még egytől? Ezt javaslom megvitatni, miután elolvastam a *Constellation projekt „könnyű” műszaki dokumentációjának fordítását (). Persze ez nem teljes leírás az algoritmusról, de érdekel a Habr közösség véleménye, van-e helye egy ilyen konszenzusnak, hogy „legyen”, vagy felesleges?
Nincs sokkal több levél, ezért ha csak azt szeretnéd írni, hogy „hú, amennyit csak tudsz a kriptoval kapcsolatban”, akkor kérlek, tartózkodj. Ha érdeklik az új fejlesztések az elosztott rendszerek területén, és van valami megosztanivalója a megjegyzésekben, kérjük, olvassa el a kat.
Ui. Nem én vagyok a technológia szerzője, a lényeg teljes átadásáért nem tudok kezeskedni, ezért szívesen fogadok észrevételeket esetleges módosításokkal.
Evolúció a szinkronból az aszinkron konszenzusba
A csomópontokat egy determinisztikus eljárással választják ki (ugyanazt, mint a DHT-kban, például a bittorrentben), amely dinamikusan módosítja a csomópontok felelősségét, hogy „könnyítse” az érvényesítést, vagy ami érthetőbb, a konszenzus elérése érdekében. 3 csomópontból álló csoportokat választunk ki, és párhuzamosan konszenzusos köröket futtatunk, így egy csomópont több blokkban is segítő lehet. Ez lehetővé teszi a tranzakciók aszinkron feldolgozását, ami lényegében azt jelenti, hogy egyszerre több blokklánc is létrejön. A folyamat olyan, mint egy pókháló, amelyet sok szál alkot, ellentétben a csomópontokkal, amelyek idővel egyetlen láncot alkotnak. Az aszinkron vagy párhuzamos feldolgozás a skálázható programozás alapja, mert lehetővé teszi az összes számítógépes erőforrás felhasználását, felgyorsítva az általános számítási folyamatot. Ezt a hálózatot irányított aciklikus gráfnak vagy DAG-nak nevezik a számítástechnikában.
Egy lineáris blokklánc csatornaszélessége a DAG multiplikatív hatásával szemben, ahol több párhuzamos blokklánc van.
Lineáris blokklánc geometriai megvalósítása DAG ellen. A fekete pontok blokkok, a fehér pontok csomópontok
Minden konszenzuskörben 3 csomópontot használunk, mert ez érdekes matematikai folyamatokat ad az állapotról való érveléshez, „felületi síkot” képezve az adatokon összekapcsolt háromszögek formájában. A protokoll ezután a háromszögek segítségével olyan optimális felületet varr össze, amely nem tartalmaz redundáns vagy inkonzisztens adatokat, és a lehető legkisebb háromszöggel rendelkezik. Algoritmikusan ez analóg egy gráf „minimális vágásához”, matematikailag pedig egy derivált vagy optimalizáló függvényhez (amelyből a függvény megtalálja a legrövidebb utat, amelyet a felületen bejárhat). Ez a legrövidebb út megfelel az adatok (tranzakciók) DAG-ban való optimális tárolásának. Ütköző háromszög alakú „csempék”, hogy az esemény felülete sima és konfliktusmentes legyen.
Konfliktusészlelés/konfliktuskezelés geometriai megvalósítása. Egy ütköző blokk további felületlapkát hoz létre. További felületi csempéket távolítunk el a sík (= konfliktusmentes) eseményfelület fenntartása érdekében.
A jó hírnéven alapuló konszenzus
Egy optimális decentralizált p2p hírnévrendszerben minden csomópontnak képesnek kell lennie arra, hogy önállóan meghatározza a többi csomópontba vetett bizalmát. Rendszerünk egy speciális modellt használ, amely tranzitív kapcsolatokat tartalmaz, vagy olyan kapcsolatokat, amelyekkel egy csomópont más csomópontokkal rendelkezik, amikor globális pontszámot rendel hozzá. "Csak annyira vagy jó, amennyire a társaságod." A végeredmény egy „ferdítés” vagy gradiens, amely tranzitív bizalmon vagy hírnéven alapul a $DAG vagy a normál csatorna összes csomópontjában. Ez felfogható egy ecsettel vagy sajtreszelővel, amely áttöröl egy „felületi síkot”, és kiválasztja, hogy mely „háromszög alakú csempéket” törölje, és melyiket hagyja el. Így távolítja el a konfliktuslogika a „háromszöglapkákat”.
Egy ütköző lapkával rendelkező DAG egy „görbült” mezőn megy keresztül, amely a sajtreszelőhöz hasonló gradiens, és eltávolítja vagy „törli” az ütköző lapkát.
Részleges/teljes csomópont-skálázás
A hálózatelméletben az optimális allokációt általában „skálázásmentesnek” nevezik, amely egy hierarchikus elrendezésként írható le, amelyben nagy központi csomópontok sok kisebb perifériás csomópontot kezelnek. Ez az eloszlás látható a természetben és mindenekelőtt az interneten. A Constellation ezt az architektúrát használja a grafikonunk „kiskálázására”, illetve az átviteli sebesség vagy a szélességének növelésére.
A hierarchikus felosztás hatása. A sávszélesség növelésével további csomópontokat adhatunk hozzá
Hylochain – Csatorna alapú alkalmazások támogatása
Az alkalmazástámogatással kapcsolatos megközelítésünket „decentralizált intelligens szerződéses platformnak” tekinthetjük. Ahelyett, hogy egy központi hálózat futtatná az összes logikát és feldolgozná az alkalmazásból származó összes adatot, a Constellation összehangolja az alkalmazás adatait a „házi csatornákkal”, amely a házrendszer összes adatát sugárzó televíziónak tekinthető. Minden személyzeti csatorna megvalósíthatja a saját ellenőrzési logikáját az oracle probléma megoldására az adatelőállítók végpontok közötti hitelesítésével és az összetett személyzeti rendszerek tranzitív ellenőrzésével. Az állami csatornahálózatok párhuzamos támogatást nyújtanak az alkalmazások számára, felgyorsítva az elfogadási időt, amelyet az intelligens szerződéses hálózatok hagyományos szinkron konszenzusa korlátoz.
Két szabványos csatorna, amelyek „kompatibilisek” a $DAG hálózaton keresztül. Kölcsönhatásba léphetnek, vagy értelmezhetők, mivel mindkettő „integrálva van” a $DAG-val hibrid $DAG + csatorna csomópontok telepítésével.
Azért hívják Hylochainnek, mert az alkalmazástámogatási megközelítésünk a Recursion Schemes funkcionális programozási modelljét használta a MapReduce felület létrehozásához. Különösen a Hylomorphism és Metamorphism rekurziós sémák integrálhatók ellenőrizhető lekérdezések és adatfolyam-kapcsolatok létrehozásához natív csatornákon keresztül, az algebrai adattípusok érvényesítésével ugyanúgy, mint az intelligens szerződések műveleti kódjait. A végeredmény egy funkcionális MapReduce interfész, amely ismerős az adatmérnökök számára, és kompatibilis a meglévő big data technológiával.
A Hylomorphic és a Metamorphic szabványos kontrasztcsatornák. Metamorf állapotban két szabályos csatorna adatait küldik a metacsatorna egy blokkjába. A Gilo-ban felvesszük egy csatorna előző állapotát, és felhasználjuk két másik csatorna lekérdezésére (egy konkrét kérdés feltevésére), majd a lekérdezés eredményét egy blokkban tároljuk.
Tokenomika és kapcsolata a Hylochainnel
A natív csatorna létrehozása után integrálható a $DAG csatornába, de az ACI vagy az Application Chain Interface használatával. Ez az interfész egyszerűen egy JSON-objektum konfigurációs információkkal és a csatornához társított nyilvános kulccsal. Azért társítunk egy nyilvános kulcsot egy normál csatornához, hogy közvetítői mechanizmust hozzunk létre a normál csatornaadatokhoz. A normál csatorna üzembe helyezésekor a fejlesztők maguk állítják be, hogy a $DAG hálózatból érkező kifizetések hogyan oszlanak meg a csomópontok és az operátorok között.
Folyamat az információkhoz való hozzáférés megvásárlásához vagy az információk módosításához. A kérelmet elküldik a $DAG-nak, a pénzeszközöket a csatorna számlájára, az eredményt a vevőnek, a tranzakciós ellenőrző összeget pedig a $DAG hálózatnak küldik, amely azután pénzeszközöket bocsát a normál csatornán.
Forrás: will.com