Autor: PolkaWorld
Gavin Wood, spoluzakladatel Etherea, tvůrce Polkadotu a propagátor vize Web3.
Než začneme, podělme se o některé citáty Gavina v této části!
Jaký je dosud největší úspěch Etherea? — Možná CryptoKitties, nevím, vlastně si nejsem jistý. Slyšel jsem, že Ethereum vytvořilo nejvíce milionářů v historii.
Je Ethereum úspěšný projekt? — Pokud se podívám podle mých měřítek úspěchu? Zjevně nevyhovují všem kritériím, možná jen malá část z nich. Samozřejmě, že je úspěšné finančně.
S příchodem JAM se změnila orientace Polkadotu. Může být považována za nativně navrženou Rollup hostingovou řetěz, zatímco technologie, kterou vyvíjíme, daleko převyšuje optimistické Rollupy a zero-knowledge Rollupy na Ethereu.
Jaký je dosud největší úspěch Polkadotu? — Vytvoření bezpečné shardované blockchainové struktury.
Jaký je největší problém, kterému Polkadot dnes čelí? — Právě shardování.
Jak tyto problémy vyřešit? — JAM
Pokračujte ve čtení a podívejte se na celý obsah!
Jaký je dosud největší úspěch Etherea?
Kevin: Takže říkáš, že jsi v roce 2014 spoluzaložil Ethereum? Proč jsi se k nim připojil jako spoluzakladatel a CTO?
Gavin: Myslím, že to byla vzácná příležitost, okamžitě jsem si uvědomil, že bych měl chytit a dát do toho všechno. Možná to není investice na celý život, ale aspoň na nějakou dobu se do toho plně zapojit. Je to inovační projekt, který se objevil v pravý čas, s některými schopnými a soustředěnými lidmi v týmu a také s malým trhem, který je otevřený novým věcem a ochotný zkoušet. Upřímně, byl jsem tímto projektem fascinován, myslím, že má obrovský potenciál, aby se dostal daleko a přispěl alespoň k principům osvobozujícího liberalismu, jak je chápu.
Kevin: Co to je?
Gavin: Základně jde o optimistický pohled na společnost a rozvoj, tenhle myšlenkový směr se vyvinul asi před čtyřmi nebo pěti sty lety na Západě.
Kevin: Jaký je dosud největší úspěch Etherea?
Gavin: Možná CryptoKitties, nevím, vlastně si nejsem jistý. Slyšel jsem, že Ethereum vytvořilo nejvíce milionářů v historii. Možná je to kvůli tomu, že se na crowdfundingu účastnilo mnoho lidí a cena pak vzrostla dostatečně vysoko. Takže to může být jeho největší přínos. Ale upřímně, těžko říct, kolik užitečného skutečně přineslo. Určitě to nedosáhlo mých očekávání před deseti lety.
Kevin: Takže pokud se tě zeptám, zda si myslíš, že Ethereum je úspěšný projekt? Je tvá odpověď záporná?
Gavin: Moje odpověď je, že osobně ho považuji za úspěšné? Pokud se podívám podle mých měřítek úspěchu? Zjevně nevyhovují všem kritériím, možná jen malá část z nich. Samozřejmě, že je úspěšné finančně. Myslím, že možná někteří zakladatelé Etherea očekávali, že to bude fungovat lépe.
Kevin: Jaká měřítka by ti dovolila považovat ho za úspěšné?
Gavin: Užitečnost (Utility)
Kevin: Jak měříš užitečnost?
Gavin: Měření užitečnosti spočívá v tom, kolik věcí mohou lidé nyní dělat, co dříve dělat nemohli.
Kevin: Není to problém celého kryptoprůmyslu, a nejen Etherea?
Gavin: Oprávněně. To je opravdu problém, kterému čelí celý kryptoprůmysl. V roce 2014 a 2015 jsme měli spoustu vizí, jak odemknout některé dříve nedostupné ekonomické oblasti pomocí 'bez nutnosti důvěry'. Jedním z příkladů, který se mi obzvlášť líbí, je dodavatelský řetězec. Například, když jdete do supermarketu, všechny produkty mají QR kód, který můžete naskenovat a zjistit všechny složky tohoto produktu: kdy, kde a kolik atd. Doufám, že když si koupím tričko, budu vědět, odkud pochází jeho bavlna.
Dnes je to velmi těžké provést v centralizovaném modelu a také nákladné. Ale pokud bychom to udělali decentralizovaně, myslím, že to je možné. Avšak tyto aplikace nebyly skutečně nasazeny. I když existuje několik kryptoprojektů souvisejících s dodavatelským řetězcem, jsou velmi niche a zaměřují se na konkrétní tržní segmenty. Nedodržely slib této oblasti.
A to není jen problém dodavatelského řetězce, myslím, že kryptoprůmysl má bohatou představivost, ale je obtížné přetvořit tyto představy na skutečné akce a skutečné tržní aplikace, což je opravdu zklamáním. Myslím, že hlavní důvod není technologický problém, i když technologie určitě zaostává za našimi představami, zejména základní technologie potřebuje velké zlepšení. To je také důvod, proč teď dělám JAM, abych se pokusil vylepšit základní technologie, aby podpořily ty myšlenky, které považuji za cenné, a pomohly kryptoprůmyslu hrát větší roli.
Ale pouhé zlepšení technologie nestačí. Také musíte lidi naučit chápat, jaká je její hodnota. A to je těžké, částečně proto, že se snažíte bojovat s ekonomikou pozornosti.
Proč odejít z Etherea?
Kevin: Proč jsi odešel z Etherea v roce 2016?
Gavin: Vlastně na konci roku 2015. Tehdy jsme se rozhodli, že Ethereum potřebuje udělat spoustu věcí, aby se rozšířilo. Hledali jsme externí investice a jedním z nejzřejmějších způsobů bylo založit startup související s Ethereem a hledat externí financování. To byla původně společná rozhodnutí Vitalika a Jeffa (hlavního vývojáře a inženýra).
Později se Jeff vlastně neadaptoval na život startupu. Oprávněně, brzy odešel z Etherea a šel se věnovat své kariéře videoher. Takže nakonec zůstal jen Vitalik. Vitalik cítil, že je nutné zůstat ve fondu Etherea a hrát více akademickou roli a zároveň být poradcem naší tehdy založené dceřiné společnosti Ethcore.
V té době jsme získali nějaké financování a přivedli přibližně polovinu technického týmu Etherea do Ethcore a vyvinuli Ethereum klienta. Když jsem na konci roku 2015 opustil fond Etherea, vlastně jsem to udělal, abych založil tuto dceřinou společnost s cílem vytvořit v ekosystému Etherea subjekt s podporou soukromého financování.
Ale skutečně jsem úplně opustil ekosystém Etherea na konci roku 2017, kdy jsem založil Polkadot.
Polkadot vyvíjí technologii Rollup
Kevin: Jak bys vysvětlil Polkadot své matce? Co bys jí řekl?
Gavin: No... Polkadot se za ta léta trochu změnil. Původní vize byla integrovat různé architektury blockchainu, aby mohly vzájemně spolupracovat a sdílet stejný bezpečnostní rámec. Díky tomuto sdílenému bezpečnostnímu rámci může výrazně zvýšit ekonomickou efektivitu. Například, pokud je to dobře navrženo, můžete s tímto stejným nákladem chránit 100 řetězců najednou, místo aby každý řetězec jako u jiných návrhů (například Cosmos) potřeboval samostatnou ochranu.
Po léta se Polkadot snažil odlišit v tomto ohledu od Cosmosu. Protože v modelu Cosmos každý řetězec musí nést vlastní bezpečnost. Polkadot to řeší sdílenou bezpečností. Ale bohužel, obě tyto věci ve skutečnosti řeší velmi odlišné problémy. Kdybych se ohlédl, možná bych Polkadot raději popsal jako 'shardový systém', než jako 'multi-chain systém'. Zpětně je tento popis velmi klíčový při vysvětlování a komunikaci základní myšlenky Polkadotu. Zvlášť když komunikujete s ostatními nebo propagujete Polkadot, toto rozlišení pomáhá jasněji popsat jeho technické vlastnosti a odlišnosti od jiných projektů (jako je Cosmos).
Nyní, s příchodem JAM, se tento směr změnil. Technologie, kterou vyvíjíme pro Polkadot, může být považována za určitou Rollup technologii, zatímco Polkadot sám může být považován za speciálně navrženou Rollup hostingovou řetěz. Vývoj a design této technologie není jednoduchý, takže není překvapením, že vidíme, jak se jiné dvě konkurenční technologie v účinnosti daleko zaostávají za technologiemi, které jsme vyvinuli pro Polkadot. Konkrétně jde o optimistické Rollupy (Optimistic Rollups) a zero-knowledge Rollupy (ZK Rollups), které byly již použity na Ethereu. Takže Polkadot můžeme popsat jako nativní Rollup hostingovou řetěz — samozřejmě, toto tvrzení nemusí být vhodné pro vysvětlení matce, ale pro ty, kteří mají určité znalosti o kryptoměnách, to funguje.
S pomocí JAM, což je další vývojový cíl Polkadotu, se snažíme přetvořit Polkadot z modelu multi-chain do obecnějšího modelu výpočetních zdrojů. V modelu multi-chain sdílejí různé řetězce Polkadotu (v rámci ekosystému Polkadotu nazývány paralelními řetězci) stejný bezpečnostní rámec a mohou si vzájemně interagovat. V novém modelu je naším cílem dále rozšířit užitečnost Polkadotu, podobně jako Ethereum rozšířilo základní funkce Bitcoinu na obecné výpočetní zdroje. Chceme odstranit příliš mnoho subjektivních designových omezení, aby Polkadot podporoval širší spektrum použití.
Jaká je tedy budoucnost Polkadotu? Fundamentálně se stane velkým sdíleným počítačem, který vždy funguje tak, jak očekáváte. Na tomto sdíleném počítači můžete nahrávat programy, které mohou být službami řešícími konkrétní problémy. protože je to sdílený počítač, tyto služby mohou spolupracovat a koordinovat se navzájem.
Klíčové je, že je to jeden velký sdílený počítač. Co nechceme, je rozdělit ho na různé části, které nemohou skutečně interagovat.
Největším úspěchem Polkadotu je jeho největší problém.
Kevin: Myslím, že možná odkazuješ na skutečnost, kterou všichni známe, a to v dnešním ekosystému Etherea ve skutečnosti vyvolalo mnoho zmatku. Co je tedy dosud největší úspěch Polkadotu?
Gavin: Vytvoření bezpečné shardované blockchainové struktury.
Kevin: Jaký je největší problém, kterému Polkadot dnes čelí?
Gavin: Je to shardování.
Kevin: Co to konkrétně znamená?
Gavin: Shardování bylo vždy považováno za 'svatý grál' rozšiřitelnosti blockchainu, jehož koncept pochází z návrhu databází. V databázi můžete rozdělit jednu databázi (v podstatě soubor záznamů) do více shardů. Každý shard běží nezávisle a pouze v některých velmi jasných rozhraních mohou shardy interagovat, například určitý záznam se může přesunout z jednoho shardu do druhého.
Jednoduchý fyzický příklad může pomoci pochopit. Představte si kancelář ze 60. let, například lékařskou ordinaci, kde jsou uchovávány zdravotní záznamy pacientů. Tyto záznamy jsou obvykle uloženy ve staromódních šuplících. Pokud záznamy obsahují pouze 20 lidí, může se do jednoho šuplíku snadno vejít a je snadné je uspořádat abecedně. Ale pokud záznamy překročí kapacitu jednoho šuplíku, například je více lidí, musíte záznamy rozptýlit do více šuplíků. Pokud se počet šuplíků dále zvyšuje, například potřebujete čtyři nebo pět šuplíků, budete potřebovat také další skříň.
Každý šuplík skříně může být považován za shard. Tyto šuplíky běží nezávisle: můžete otevřít jeden šuplík, aniž byste museli otevřít ostatní, a můžete prohledávat jeden šuplík, aniž byste museli procházet všechny šuplíky. To je v kontrastu s jediným zvlášť dlouhým šuplíkem (například 10 metrů dlouhým šuplíkem). Pokud máte jen jeden dlouhý šuplík, pak jeho používání zjevně není příliš praktické, protože potřebujete 10 metrů dlouhou místnost, abyste ho uložili. A když hledáte osobu, jejíž jméno začíná na „W“, možná budete muset vytáhnout celý šuplík a projít celou cestu k pozici „W“, což je zjevně neefektivní.
Takže z této perspektivy je návrh shardování rozumný. Avšak to také přináší problémy. Například, co když je nějaký šuplík plný? Možná budete muset přenastavit distribuci záznamů, například změnit záznamy původně patřící A až E na A až D a přenést záznamy začínající na E do dolního šuplíku. Ale to může vést k tomu, že další šuplík také nebude mít místo, a tak budete muset upravit, a každá změna bude vyžadovat změnu štítku na vnějším šuplíku. Celý tento proces se může stát složitým a problematickým.
Takže shardování také přináší vlastní řadu problémů.
Jádrem je, že tyto 'šuplíky' (shardy) běží nezávisle, a to jak v návrhu shardového blockchainu, tak v návrhu databáze. V podstatě, jakmile jsou data rozdělena, zůstanou rozdělena, pokud nevykonáte velmi specifickou operaci, která je obvykle velmi časově náročná, nákladná a náročná na zdroje, abyste mohli přenést záznamy nebo data z jednoho šuplíku (shardu) do druhého. To znamená, že reorganizace záznamů uvnitř jednoho šuplíku může být snadná, ale reorganizace záznamů mezi různými šuplíky je velmi obtížná. To je problém shardování. Pro data to nemusí být tak vážný problém, což je důvod, proč se shardování široce používá v návrhu databází. Ale pro služby, jako jsou inteligentní kontrakty, které potřebují častou interakci a změny, to není ideální. Pokud jsou inteligentní kontrakty považovány za objekty umístěné v šuplících a chcete, aby jeden inteligentní kontrakt v jednom šuplíku interagoval s jiným inteligentním kontraktem ve druhém šuplíku, musíte otevřít oba šuplíky současně. To znamená, že budete muset vytáhnout dva šuplíky a propojit je, abyste provedli všechny interakce potřebné pro inteligentní kontrakty a poté je oddělit a vrátit zpět do jejich šuplíků. Tento proces je složitý a neefektivní, velmi nevhodný pro aplikace, které vyžadují častou interakci.
Pokud operujete jen mezi dvěma šuplíky, je to už dost těžké, ale pokud chcete, aby více šuplíků interagovalo současně, stane se to velmi složitým a obtížným. Problémem je, že bráníte volné interakci mezi šuplíky, což znamená, že ostatní inteligentní kontrakty v šuplících mohou sledovat pouze tento jediný interakční model. Celý systém se rychle stane složitým, obtížným a neefektivním.
Alternativní přístup je umožnit šuplíkům komunikovat prostřednictvím zpráv. Jeden šuplík (shard) může publikovat zprávu, která se později přenese do jiného šuplíku. To je přesně to, co Polkadot dělá pomocí XCM (Cross-Consensus Messaging). Ačkoli to může být použitelné, problém je, že to nemůže dosáhnout tak úzké, efektivní a flexibilní interakce, jako když vše běží ve stejném prostoru nebo 'hracím hřišti'.
Například, představte si, že škola má čtyři různá hrací hřiště, což odpovídá čtyřem různým blockchainům. Pokud hrajete hru 'schovávaná' na jednom hřišti, není to žádný problém, hra může probíhat hladce. Ale pokud chcete hrát 'schovávanou' přes dvě hřiště, stane se to velmi obtížné. Musíte poslat zprávu na druhé hřiště, například 'teď jsem ten, kdo hledá, pokud vstoupíš do této oblasti, chytím tě.' A hráči na druhém hřišti musí vědět, ale nemohou to úplně pochopit, celá hra se rychle stane zmatenou.
Takže, schovávaná je hra, kterou lze hrát pouze na jednom hřišti. To je přesně problém mezi shardy, že interakce napříč shardy je jako pokus hrát hru napříč hřišti, což je obtížné provést efektivně.
Pokud některá řešení musí fungovat velmi asynchronně, bude velmi obtížné je zprovoznit. Je to jako hrát hru pouze prostřednictvím zpráv. Pokud je to hra jako šachy, možná to nebude tak těžké; ale pokud je to hra jako schovávaná, je to téměř nemožné.
Ve světě inteligentních kontraktů je to podobná situace. Některé inteligentní kontrakty v tomto modelu fungují, možná jen o něco pomaleji než obvykle, ale není to velký problém. A některé aplikace, jako je ověřování identity (KYC), jsou relativně jednoduché. Například můžete mít jeden řetězec, který se stará o ověřování identity, a jiný řetězec, který se stará o převody. Řetězec pro převody může potřebovat potvrdit, zda cílová adresa prošla ověřením KYC a AML, než provede převod. Může poslat zprávu, aby se zeptal 'Byla tato adresa ověřena KYC a AML?' Řetězec pro ověřování identity odpoví 'ano', a poté řetězec pro převody provede převod. Celý proces může trvat několik sekund navíc, ale není to velký problém.
Nicméně existují také jiné případy, jako decentralizované burzy (DEX), které jsou mnohem složitější. Například potřebujete zjistit aktuální cenu a poté se rozhodnout, zda obchodovat. V tomto okamžiku možná budete potřebovat poslat zprávu do jiného řetězce, a ten druhý řetězec odpoví 'Aktuální cena je tato a obchod může probíhat tímto způsobem.' Poté se zpráva vrátí zpět do původního řetězce, který potvrdí 'Přijímám tuto cenu, prosím, proveď obchod.' Ale když je obchod téměř proveden, druhý řetězec může znovu říct 'Cena se změnila, nyní je to tato cena.' Zprávy se rychle pohybují zpět a vpřed, a celá procedura se brzy stane velmi neefektivní, dokonce se nemusí efektivně dokončit.
Takže, v takovém případě musí být obchod proveden téměř současně, jinak se to nemůže uskutečnit. Tento jev je podobný hře na hřišti. Některé hry, jako schovávaná, mohou být provedeny pouze v jednom prostoru, asynchronní interakce by hru úplně znesnadnily.
Řešení je JAM
Kevin: Jaké jsou možné řešení?
Gavin: No, JAM je můj návrh, což znamená Join Accumulate Machine (Spojovací akumulační stroj).
Kevin: Co je JAM?
Gavin: JAM je flexibilní způsob, jak shromáždit hráče z různých 'hracích hřišť' a vytvořit dočasné hřiště, kde mohou hrát hru schovávanou. Zde je příklad, který jsem si teď vymyslel (možná to je trochu šílené, omlouvám se). Pokračujeme s hrou schovávaná: Představte si, že máte čtyři stálá hřiště, v návrhu JAM již nejsou taková stálá hřiště.
Hřiště už nejsou stálá, hráči už nejsou vázáni na jedno hřiště a náklady na přemístění mezi různými hřišti už nejsou tak vysoké. Místo toho máme širokou herní oblast, kde se hřiště mohou rychle formovat a zanikat. V takovém případě se zaměříme na hráče ve hře a shromáždíme hráče, kteří jsou blízko sebe a mohou se navzájem 'chytit', dočasně je shromáždíme v jednom hřišti, kde mohou pokračovat v hře schovávaná.
Když část těchto hráčů běží z tohoto dočasného hřiště, znovu upravíme polohu hřiště a podle těch, kteří jsou stále blízko sebe, předefinujeme nové hranice hřiště. Pokud jsou někteří hráči od sebe příliš daleko, víme, že se v krátkodobém horizontu nebudou moci 'chytit', a proto se nemusí účastnit tohoto hřiště. Jsou dočasně 'mimo hru', dokud se opět nepřiblíží jiným hráčům a nepotřebují se zúčastnit hry, pak budou zahrnuti do nového hřiště.
Pokud bychom takto implementovali systém, můžeme si představit systém, který je jak rozšiřitelný, tak podporuje synchronní kombinace. Jeho jádro spočívá v tom, že trvalé 'stavy' (state) nebudou odděleny. Jinými slovy, hráči nebudou trvale vázáni na nějaké konkrétní hřiště, ale budou se dynamicky skupinovat podle potřeby v reálném čase. Systém rozdělí hráče do různých skupin podle aktuálních potřeb a podporuje hru podle těchto skupin.
Ve scénáři inteligentních kontraktů je implementace tohoto konceptu podobná jako umístit všechny inteligentní kontrakty do sdířeného 'tavicího hrnce', ale tento hrnec nezajišťuje, že všechny kontrakty neustále interagují mezi sebou, nýbrž se mohou dynamicky dělit. Například, systém může vybrat 10, 50 nebo 2 inteligentní kontrakty z tohoto hrnce, spojit je, aby mohly synchronně interagovat a běžet, a poté je opět oddělit. Poté znovu vyhodnotí a vybere jinou skupinu inteligentních kontraktů, znovu je spojí a poté je oddělí.
Tento způsob nám umožňuje zpracovávat více paralelních skupin inteligentních kontraktů současně, místo abychom mohli provádět synchronní kombinace a běh pouze jedné skupiny inteligentních kontraktů. Díky této metodě paralelního zpracování můžeme výrazně zvýšit interakční kapacitu systému a podpořit množství interakcí, které je několikanásobně vyšší než v tradičních metodách, čímž dosáhneme skutečné rozšiřitelnosti.