Monad consensus client je nyní open source (odkaz níže). Je to výsledek tisíců hodin úsilí týmu společnosti @category_xyz. Vychutnat

Shrnutí průlomu v MonadBFT Včera Category Labs vydaly článek MonadBFT, popisující mechanismus konsensu, který bude pohánět Monad na mainnetu. MonadBFT je významným vývojem ve výzkumu konsensu, protože je to poprvé, kdy se Pipelined HotStuff stává odolným vůči rozvětvení ocasu. Tail-forking nastává, když vynechaný slot způsobí, že předchozí návrh bude zahozen a znovu vytěžen. Jedná se o závažný problém v předchozích formulacích Pipelined HotStuff, protože otevírá multiblokové MEV útoky, které destabilizují konsensus. Zmírnění tohoto problému je obrovský problém, protože nám poskytuje všechny výhody Pipelined HotStuff - časté bloky, nízkou latenci, velké sady validátorů - a zároveň se vyhýbá největší nevýhodě. MonadBFT také nabízí obrovský upgrade pro finalitu. Vyznačuje se jednoslotovou (500 ms) spekulativní konečností a dvouslotovou (1s) tvrdou konečností. "Spekulativní konečností" se rozumí "konečnost, která se vrátí pouze v případě dvojitého podpisu (dvojitého podpisu) většinou validátorů". Dvojznačnost je hlavním přestupkem ve většině blockchainových systémů a je běžně penalizována sekáním; Čím větší je trest za dvojsmysl, tím blíže můžete uvažovat o "spekulativní konečnosti" ke konečné. Jednoslotová spekulativní konečnost je obrovským odemknutím pro vysoce výkonné aplikace, které mohou s jistotou zobrazit aktualizovaný stav světa ihned po přijetí dalšího bloku. Tyto vlastnosti dělají z MonadBFT obrovský pokrok v konsensu a důstojný doplněk k dalším vylepšením v Monad, včetně asynchronního provádění, optimistického paralelního provádění a MonadDb. Zbytek tohoto článku slouží jako shrnutí toho, jak na sebe postupná vylepšení v HotStuff navazovala, aby se vysvětlil problém, který MonadBFT řeší. Abych to shrnul: 1. HotStuff nám dává lineární komunikační složitost, takže můžeme mít velké sady validátorů, ale není to příliš efektivní 2. Zřetězený HotStuff nám poskytuje efektivitu a nízkou latenci při navrhování bloků v každém slotu, ale trpí problémem koncových vidlic 3. MonadBFT nám dává odolnost proti zadní vidlici a spekulativní konečnost jedné pozice --- HotStuff: Složitost lineární komunikace umožňuje velký počet uzlů Algoritmy HotStuff se dokončují v průběhu několika kol komunikace, která má obecně podobu komunikace "fan out, fan in" přímo od lídrů přes validátory zpět k lídrům. Každé kolo začíná tím, že vedoucí pošle zprávu přímo ostatním validátorům, z nichž každý pošle zpět podepsanou zprávu potvrzující, že zprávu obdrželi. Za předpokladu, že kvalifikovaná většina (2/3) ověřovatelů zašle zpět osvědčení, každé kolo končí tím, že vedoucí agreguje podepsaná osvědčení do osvědčení o usnášeníschopnosti (QC), které slouží jako důkaz, že kvalifikovaná většina potvrdila předchozí zprávu. Algoritmy HotStuff mají několik kol komunikace, jako je tato. - První zprávou od vedoucího je návrh bloku - Druhá zpráva je kontrola kvality pro tento návrh bloku - Třetí zpráva je QC o předchozí QC (tj. QC-on-QC) - a tak dále Pokud je řízení přerušeno kdykoli před dokončením, blok se nepodaří dokončit a je zahozen; Transakce z tohoto bloku budou muset být znovu zahrnuty do dalšího bloku. Původní protokol HotStuff nemá žádné zřetězení a má 3 kola komunikace před finále; Stejný validátor hraje v každém kole roli vůdce. --- Pipelined HotStuff: Nový blok v každém slotu zvyšuje efektivitu Zřetězení je to, co všichni intuitivně děláme, když máme dokončit dvě várky prádla. Místo toho, abychom čekali, až náplň 1 dokončí celý cyklus před zahájením náplně 2, v potrubí vložíme náplň 1 do sušičky ve stejnou dobu, kdy náplň 2 půjde do pračky. Původní HotStuff si můžete představit jako naivní přístup k praní prádla (nezačínejte s náplní 2, dokud není zcela dokončena dávka 1), zatímco Pipelined HotStuff provádí intuitivní chování postupného posouvání více dávek prádla postupným způsobem. V Pipelined HotStuff rozložíme návrhy tak, aby v každém kole byl navržen nový blok, přičemž nový blok se přilepí na zprávu nesoucí QC z předchozího bloku. Návrhy bloků směřují k finalitě v průběhu několika kol. Výhody zřetězení jsou významné. Zřetězení zvyšuje hustotu návrhů bloků, protože návrh bloku je vytvořen v každém slotu, což zvyšuje propustnost a zkracuje dobu do dokončení. Existuje však jedna velká nevýhoda zřetězení, kterou lze nejlépe ilustrovat na příkladu. Předpokládejme, že vedoucí bloky N, N+1 a N+2 jsou Alice, Bob a Charlie. Pokud Bob zmešká svůj slot, pak bude Alicin návrh také zneplatněn, protože Bobova zpráva obsahuje jak jeho návrh, tak QC pro Alenčin návrh. Když se to stane, Charlie je nakonec vyzván, aby vytvořil blok, jako by Alicin návrh nikdy neexistoval. Toto chování označujeme jako "tail-forking" a lze si ho představit jako mini-reorganizaci hloubky 1. Možnost tail-forku má významné důsledky, protože vynechané sloty nemusí být nutně náhodné. Pokud se naskytne příležitost získat hodnotu opětovným vytěžením Alicina bloku a zároveň přeskupením nebo vynecháním některých transakcí, pak se Bob a Charlie mohou dohodnout, aby Bob záměrně minul svůj slot, což spustí příležitost pro Charlieho znovu vytěžit Alicin blok. To byla významná nevýhoda protokolů Pipelined HotStuff (z nichž některé jsou dnes v mainnetu). --- MonadBFT to mění MonadBFT je první protokol, který umožňuje zřetězení a zároveň činí algoritmus odolným proti vidlici. Tento odpor proti zadní vidlici pochází ze záložní procedury, když Bob mine svůj slot, což umožňuje validátorům poskládat dohromady své kolektivní znalosti o Alicině návrhu a jeho úrovni konsensu v rámci sady validátorů. Konkrétně podle MonadBFT, pokud Bob zmešká svůj slot, pak záložní procedura spočívá v tom, že validátoři spolu komunikují s podepsanými atestacemi, které uvádějí, zda viděli Alicin blok. Pokud kvalifikovaná většina potvrdí Alenčin blok, pak je Charlie nucen znovu navrhnout Alenčin blok. Pokud si Charlie přeje navrhnout jiný blok, musí poskytnout podepsané potvrzení od většiny validátorů, které potvrzuje, že neviděl Alicin blok včas. V typickém případě, kdy Charlie znovu navrhne Alicin blok, pak může navrhnout svůj blok v následujícím kole. Výsledkem jsou dvě důležité vlastnosti: odolnost proti rozvětvení a spekulativní konečnost jedné drážky. O odporu proti rozvětvení ocasu jsme již mluvili, ale pojďme pochopit dopad na konečnost. Stejně jako předtím předpokládejme, že vedoucí bloky N, N+1 a N+2 jsou Alice, Bob a Charlie. V rámci zřetězeného 2-fázového HotStuff - tj. před MonadBFT - jako validátor (nebo plný uzel) nemůžete dokončit Alicin návrh bloku, dokud neuvidíte Charlieho návrh bloku. Proč? Protože pokud dokončíte svůj návrh, jakmile uvidíte Bobův návrh, je možné, že si s vámi Bob zahrává tím, že vám svůj návrh přeposílá POUZE a ve skutečnosti plánuje neposlat svůj návrh všem ostatním, čímž přijde o svůj slot. Ale v MonadBFT, jakmile uvidíte Bobův návrh, můžete "spekulativně" dokončit Alicin návrh, protože Bobův návrh obsahuje QC na Alicině návrhu, což je důkazem, že 2/3 sítě potvrdily Alicin návrh. I když si s vámi Bob zahrává tím, že vám POUZE přeposílá svůj návrh a nakonec zmešká svůj slot, víte, že nadpoloviční většina televize viděla Alicin návrh, a když se zúčastní záložní procedury, znovu podepíše Alicin návrh. Jediný způsob, jak se Alicin blok nedokončí, je, že validátoři se vyhýbají a podepíší se s tím, že Alicinu zprávu neviděli. Tato chyba je snadno prokazatelná - podepsali jsme od nich protichůdné zprávy. Pokud je trest za dvojznačnost značný – a měl by být – tato "spekulativní" konečnost ve skutečnosti není tak spekulativní. --- Odnést MonadBFT je extrémně vzrušující vývoj pro konsensus a je důstojným doplňkem k dalším vylepšením v Monad, včetně asynchronního provádění, optimistického paralelního provádění a MonadDb. Obrovská gratulace @MohammadMJalal1 a @KushalBabel k tomuto významnému průlomu. MonadBFT bude brzy implementován na Monad Testnet, který v současné době implementuje zřetězený 2-fázový HotStuff. Další informace naleznete v odkazovaném příspěvku na blogu a v článku v dalším tweetu.

Přečtěte si prosím tento šíleně dobrý příspěvek na blogu od @category_xyz o RaptorCastu - umožňuje efektivní vysílání obrovských bloků při zachování odolnosti proti chybám a zároveň minimalizuje požadavky na šířku pásma Hodně se naučíte!