Aktualizační volání je klíčová operace v Internet Computer Protocol, která umožňuje uživatelům provádět změny v kontejnerech (inteligentních smlouvách hostovaných na Internet Computer). Tento článek zkoumá každý krok životního cyklu aktualizačního volání a zdůrazňuje, jak milník Tokamak optimalizoval jeho latenci koncových bodů.
Pozadí
Pro úplné pochopení životního cyklu aktualizačního volání je nezbytné znát některé základní komponenty architektury Internet Computer.
1. Kontejner
Kontejner je inteligentní smlouva na Internet Computer Protocol (ICP), která slouží k ukládání stavu a provádění kódu. Uživatelé interagují s kontejnerem podáním aktualizací, čímž spouští operace na inteligentní smlouvě.
2. Podsíť
Podsíť je skupina uzlů, které hostují a spravují kontejnery. Každá podsíť funguje jako nezávislá blockchainová síť, což umožňuje ICP škálovat tím, že rozděluje zatížení mezi více podsítí. Každá podsíť spravuje sadu jedinečných kontejnerů, inteligentní smlouva v jedné podsíti může komunikovat s jinou inteligentní smlouvou v jiné podsíti prostřednictvím zasílání zpráv.
3. Kopie
V každé podsíti uzly (nazývané kopie) ukládají kód a data každého kontejneru v této podsíti, každá kopie navíc vykonává kód kontejneru, tato replikace ukládání a výpočtů zajišťuje odolnost proti chybám, i když některé uzly selžou nebo jsou napadeny škodlivými aktéry, inteligentní smlouvy v kontejnerech mohou spolehlivě fungovat.
4. Hraniční uzly
Hraniční uzly jsou odpovědné za směrování požadavků na odpovídající podsíť a vyvažování zatížení mezi kopiemi v této podsíti.
Životní cyklus aktualizačního volání
Následující obrázek shrnuje životní cyklus aktualizačního volání na Internet Computer Protocol:
1. Internet Computer (IC) obdrží aktualizační oznámení
Aktualizační volání začíná u uživatele, který pomocí implementace IC agent (např. agent-rs nebo agent-js) odesílá požadavek. Tyto knihovny poskytují uživatelsky přívětivé rozhraní pro interakci s ICP, zpracovávají formáty požadavků, podpisy a komunikační protokoly. Poté je požadavek odeslán na hraniční uzel, který je rozlišen přes DNS.
2. Směrování přes hraniční uzly
Hraniční uzly směrují aktualizační volání na kopie v podsíti, která hostuje cílový kontejner. Metoda cyklického výběru rozděluje zatížení požadavků na F+1 kopií, aby se zajistil výkon a spolehlivost, kde F představuje prahovou hodnotu odolnosti ICP - maximální počet selhávajících kopií, které mohou být v každé podsíti tolerovány. Pro více informací o odolnosti Internet Computer navštivte tento odkaz:
internetcomputer.org/how-it-works/fault-tolerance
3. Vysílání aktualizačního volání
Jakmile kopie obdrží aktualizační volání, použije přerušitelné vysílací primitiva k vysílání požadavku ostatním kopiím v podsíti. Tato metoda zajišťuje silné záruky dodání, i za podmínek síťové zácpy, peer-to-peer nebo poruchy spojení a zpětného tlaku.
Přerušitelné vysílání je zásadní pro efektivní komunikaci mezi kopiemi v prostředí byzantské odolnosti (BFT), šetří šířku pásma, zajišťuje, že všechny datové struktury zůstávají omezené i za přítomnosti škodlivých peerů, a udržuje spolehlivou komunikaci pro konzistentní zpracování aktualizací v ICP. Pro více technických detailů můžete odkázat na tuto studii vysvětlující řešení přerušitelného vysílání:
arxiv.org/abs/2410.22080
4. Návrh bloku (tvorba bloku)
Jedna kopie (označená jako výrobce bloku) je zodpovědná za vytvoření nového bloku obsahujícího aktualizační volání. Poté výrobce bloku tento blok předloží ostatním kopiím v podsíti k zpracování.
Kroky 4 až 7 tvoří fáze konsensuálního cyklu na Internet Computer, kde se kopie společně spolupracují na dosažení shody ohledně navrhovaného bloku. Podrobnější informace o mechanismu konsensu si můžete přečíst zde:
internetcomputer.org/how-it-works/consensus
5. Notářská latence
Zavedení krátké latence, nazývané notářská latence, pro synchronizaci sítě a umožnění všem kopiím mít čas přijmout návrh bloku, tato latence je klíčová pro udržení konzistentního stavu mezi kopiemi.
6. Notářství
Během notářské fáze kopie přezkoumá platnost navrhovaného bloku a souhlasí s jeho notářským schválením. Notářství je počáteční krok konsensu, který ukazuje, že blok splňuje standardy ICP.
7. Konečné potvrzení
Po notářském schválení bude blok konečně potvrzen - všechny kopie v podsíti souhlasí s jeho platností, což zajišťuje, že bude přijat a přidán do řetězce. Konečné potvrzení zajišťuje, že všechny uzly potvrdí blok, čímž se zajistí konsensus v celé síti.
8. Provádění
Po dokončení bloku přejde do fáze provádění, v této fázi se stav kontejneru aktualizuje na základě aktualizačního volání, existuje několik faktorů, které ovlivňují latenci této fáze, včetně:
Složitost kódu kontejneru: Složitost kódu kontejneru přímo ovlivňuje rychlost provádění, složitější logika nebo operace s vysokou datovou náročností mohou způsobit dodatečnou latenci;
Zátěž podsíťě: Protože každá podsíť hostí více kontejnerů, vykonávací zdroje jsou sdílené, vysoká zátěž podsítě může zvyšovat latenci, protože kontejnery soutěží o výpočetní zdroje.
Na základě aktivit podsítě, i jednoduché operace mohou čelit latenci. Během špičkového používání mohou aktualizační volání zažívat latenci při čekání na zdroje.
9. Sdílená autentizace
Jakmile je provedeno, kopie sdílí informace o autentizaci v podsíti, ověřují, zda bylo aktualizační volání správně provedeno a zda jsou výsledné změny stavu konzistentní.
10. Kopie reagují certifikátem
Po autentizaci kopie odešle hraničnímu uzlu odpověď obsahující certifikát, který potvrzuje úspěšné dokončení aktualizačního volání.
11. Hraniční uzly předávají odpovědi
Nakonec hraniční uzly předávají certifikované odpovědi uživateli, což značí konec životního cyklu aktualizačního volání.
Milník Tokamak
Zjednodušený proces životního cyklu aktualizačního volání, jak je popsáno výše, byl výrazně posílen milníkem Tokamak, který přinesl několik klíčových vylepšení pro Internet Computer:
Implementace přerušitelného vysílání přes QUIC: Přerušitelné vysílací primitiva implementované nad protokolem QUIC nyní řídí veškerou komunikaci mezi kopiemi, čímž zajišťují spolehlivé a efektivní zasílání zpráv v síti, toto řešení může výrazně snížit notářskou latenci, čímž zrychlí konsensus bez obětování spolehlivosti.
Vylepšené směrování hraničních uzlů: Vylepšená logika směrování v hraničních uzlech optimalizuje přidělování aktualizačních volání kopiím, jak je znázorněno ve druhé fázi životního cyklu.
Synchronizace aktualizačních volání: Zavedení synchronizovaných aktualizačních volání umožňuje okamžitou přímou odpověď uživateli po autentizaci, čímž se zjednodušuje a zrychluje poslední fáze životního cyklu.
Tyto pokroky společně zlepšily efektivitu, rychlost a spolehlivost aktualizačních volání Internet Computer, což vedlo k hladšímu uživatelskému zážitku a silnějšímu protokolu.
Klíčové faktory ovlivňující latenci aktualizačních volání
Konečná latence Internet Computer je ovlivněna několika významnými faktory:
Topologie podsítě: Fyzické a síťové uspořádání podsítě ovlivňuje čas potřebný na cestu tam a zpět (RTT) mezi kopiemi. Kratší RTT pomáhá urychlit komunikaci, zatímco větší geografická vzdálenost mezi kopiemi zvyšuje latenci.
Zátěž podsítě: Počet kontejnerů v podsíti a objem zpracovávaných zpráv ovlivňují latenci. Protože ICP funguje jako sdílená infrastruktura, kontejnery umístěné v podsítích s vysokým zatížením mohou vykazovat vyšší latenci kvůli soutěžní poptávce po stejných zdrojích.
Architektura pipeline: Architektura ICP je navržena tak, aby maximalizovala propustnost prostřednictvím fázového konsensu a provádění. Tento design umožňuje provozování více procesů současně, ale přináší kompromis - i když se propustnost zvyšuje, každá fáze v pipeline může zažívat dodatečnou latenci při čekání na dokončení předchozích fází.
Design ICP upřednostňuje vysokou propustnost a škálovatelnost, vyvažuje tyto požadavky s inherentními výkonnostními kompromisy distribuovaných, decentralizovaných sítí.
Referenční hodnoty ICP před a po Tokamak
Abychom změřili dopad milníku Tokamak, měřili jsme latenci koncových bodů (E2E) tří různých inteligentních smluv hostovaných na ICP. Jako základ jsme provedli benchmark před uvedením milníku Tokamak a poté jsme benchmark po dokončení milníku zopakovali pro srovnání.
Výsledky jsou velmi vzrušující a naznačují, že uživatelé mohou očekávat nižší latenci ICP v budoucnu, což přinese lepší uživatelský zážitek.
Pro každý případ, který jsme testovali, jsme přiložili tabulku a graf, abychom ukázali latenci E2E od 0 do 99,99 percentilu.
Kniha ICP
Kniha ICP je inteligentní smlouva hostovaná na podsíti NNS, která slouží jako kniha pro tokeny ICP. Uživatelé mohou s knihou interagovat různými způsoby, ale nejoblíbenější dapp a frontend je dapp NNS, který je také hostován na podsíti NNS.
V průběhu několika dní jsme prováděli benchmarky, během nichž jsme cyklicky odesílali tokeny ICP a zaznamenávali čas od podání transakce po obdržení odpovědi z ICP (včetně certifikátu potvrzujícího, že token byl odeslán), průměrná latence se snížila z 4,57 sekundy na 2,23 sekundy, což představuje snížení o 51%.
Internet Identity
Dapp Internet Identity je hostován v podsíti Internet Identity a je to služba federované autentizace běžící na Internet Computer. Pokud jste někdy interagovali s dapp na ICP, pravděpodobně jste strávili čas přihlašováním pomocí Internet Identity. Tento benchmark měří čas potřebný k přihlášení pomocí služby Internet Identity.
Naše výsledky ukazují, že průměrná latence času přihlášení klesla z 7,12 sekundy na 3,9 sekundy, což představuje snížení o 45,2%! Následující obrázek 2 ukazuje výsledky před a po pro různé percentily, přičemž pro 50. percentil, tedy medián, se čas přihlášení snížil z 6,9 sekundy na 3,2 sekundy.
Fialová oblast zvýrazňuje čas ušetřený na každém percentilu, pro podrobnější výsledky na každém percentilu se můžete podívat na tabulku 2.
Aplikační podsíť
Máme kontejner hostovaný v aplikační podsíti snjp, která má 13 uzlů. Tato podsíť nám umožňuje testovat zlepšení aplikační podsítě s 13 uzly po milníku Tokamak. Naše benchmarky ukazují, že průměrná latence E2E klesla z 2,43 sekundy na 1,35 sekundy, což představuje snížení o přibližně 44%.
Obsah IC, který vás zajímá
Technologický pokrok | Informace o projektu | Globální aktivity
Sledujte kanál IC na Binance
Zůstaňte informováni
