Vraag maar raak-sessie met Dan Hughes, CTO bij Radix DLTDeze ‘AMA’ of ‘vraag maar raak-sessie’ met Dan Hughes vond plaats op 27 oktober 2020 in het officiële Radix DLT Telegram-kanaal.
Vraag van GuyJullie modelleren jullie system als een set van shards waar 2/3e van de actoren van iedere shard eerlijk zijn.
Hoe willen jullie dit bereiken wanneer er een hoop shards zijn? Ieder Sybil beschermingsmechanisme dat tot op heden bekend is schaalt slecht omdat het het opsplitsen vereist van de onderliggende bron in kleinere stukjes (zij het hashkracht of hoeveelheid tokens in PoS).
Welk Sybil beschermingsmechanisme gebruiken jullie om aan te nemen dat zelfs met een grote hoeveelheid shards jullie assumptie nog steeds geldig blijft?
Antwoord van DanDit is een vraag die vaak wordt gesteld met betrekking tot Cerberus en sharding in zijn algemeenheid en is misschien één van de meer gecompliceerde onderwerpen om uit te leggen en te begrijpen, dus ik doe mijn best.
Neem er notie van dat hierover al een discussie gaande is op onze Discord, waar de meeste van de tech-discussies nu plaatsvinden omdat het gewoon gemakkelijker is om te zoeken en te reageren. Telegram is eigenlijk nogal ongeorganiseerd voor dit soort dingen, dus ik wil sterk adviseren dat jullie allemaal daarheen gaan voor tech-dingen.
Hoedanook, ik zal aan die discussie wat refereren voor dit antwoord (en ik zal ook kopiëren / plakken) …
Het eerste dat je moet onthouden is dat er altijd een hoop shards zijn, omdat de ruimte vastligt op 2^256. Dat aantal is onhandelbaar voor welke account dan ook, dus valideerders worden *altijd* toegewezen aan meerdere shards. Wetende dat de laagste bond van veiligheid per shard 2f+1 is (waar f het aantal foute / slechte valideerders betreft) dan is het minimum valideerders per “shard” 3 (waarbij er 1 fout mag zijn). Laten we hier vanuit vertrekken voor nu om de aantallen eenvoudig te houden.
Laten we ook aannemen dat er 1000 valideer-kandidaten zijn in het netwerk, en dat ze allemaal een stake van 1XRD hebben, opnieuw om dingen voor nu eenvoudig te houden.
Vanuit de gekende informatie aanwezig in de globale- / staking-shard kennen alle 1000 valideerders in het netwerk dat er 1000 valideerders beschikbaar zijn. Verder weten al deze valideerders dat het minimum valideerders per shard 3 is. Natuurlijk is 1000 (~ 2^10) veel minder dan 2^256, dus we kunnen ALLEEN kiezen om meerdere shards per valideerder te hebben. Het minimum is 3, dus zullen er 1000/3=333 valideerder-sets zijn (met een reserve-node die ergens rondzweeft die niet geselecteerd kan worden omdat een shard dan zou bestaan uit 4 valideerders, wat 2f+1 zou overtreden).
Van daaruit kunnen we inschatten hoeveel shards bediend zullen worden per set, wat in dit geval ongeveer 2^248 is … een hoop! Omdat de meeste shards echter leeg zijn en geen expliciete informatie wordt opgeslagen over lege shards maakt dat niet uit.
Nu hebben we onze 333 valideerder-sets die elk informatie opslaan over 2^248 shards met in elk 3 valideerders. Iedere enkele valideerder in iedere shard kan fout zijn, en alles zal nog steeds goed voortgaan, en veilig zijn.
Wat echter als ik een kwaadwillende ben en ik alle f-valideerders controleer? Zelfs wanneer iedere validator slechts 1 XRD-stake heeft kan ik potentieel de shards laten vastlopen door de niet-foute valideerders foute dingen te vertellen, 2f zal mee gaan met X en 2f zal meegaan met Y.
Als ik geluk heb hebben 2 van mijn valideerders het gehaald in de valideerder-set voor een groep van shards, dus in elk van die shards kan de de stem controleren … misschien ten koste van het NIET in staat zijn om een verschillende set van valideerders te laten vastlopen (want mijn extra node in S2 die ik kan controleren zou anders in S5 zijn, die ik niet kan laten vastlopen).
In deze gevallen kunnen ofwel de valideerdersvereisten veranderen voor de veiligheid, zodat we 3f+1 valideerders per set nodig hebben (die ik nog steeds kan misbruiken) … OFWEL kunnen we het valideerders toestaan om verschillende hoeveelheden stake te hebben en aannemen dat daar van geprofiteerd wordt vanwege … redenen (prikkels, altruïsme, etc.).
De *f* in onze minimumvereiste representeert een stake die “fout” is en deze *f* kan verschillend zijn voor iedere valideerder-set omdat deze iets abstracts representeert en niet iets statisch, wat belangrijk is …
Als valideerders puur willekeurig werden geselecteerd naar diverse sets, en aangenomen dat een breed bereik aan hoeveelheden wordt gestaket naar die valideerders, dan is het bijna gegarandeerd dat op een bepaald moment een enkele valideerder in een set genoeg stemkracht zal hebben om de stem te verstoren of zelfs te controleren. In ons voorbeeld van 3 valideerders per set; als 2 daarvan een stake van 1XRD hebben, en de 3e heeft een stake van 4XRD, dan controleert die laatste de stem. Slecht.
Het spel is echter niet verloren, omdat *f* een variabele per valideerder-set is en we dat kunnen gebruiken in ons voordeel, samen met de manier waarop Cerberus acties over shards commiteert of verwerpt.
Ten eerste willen we kijken naar welke variabelen we hebben die deterministische eigenschappen hebben, of daartoe kunnen leiden, welke we kunnen gebruiken bij het selecteren van valideerders en de sets.
Het aantal valideerders die voldoen aan de minimum stake-vereisten is een vanzelfsprekende variabele die iedereen kent, en ook bekend is de hoeveelheid van stake die iedere valideerder beschikbaar heeft daarvoor, en iedere recente verandering aan die stake tijdens de laatste epoche (een epoche is een tijdsperiode die de minimum periode representeert waarin een valideerder deel kan uitmaken van een valideerder-set en de volooiïngsperiode voor alle staking-/destaking-activiteiten).
Bij een epoche-verandering willen wat van de valideerders in de valideerder-sets laten rondgaan, valideerders die niet langer bij ons zijn afwijzen (gede-staket, gecrasht, weg), inclusief nieuwe valideerders die niet goed genoeg zijn en in zijn algemeenheid iedere mogelijkheid aangrijpen om tegen te werken en die een beïnvloedende hoeveelheid stake in een set heeft. Natuurlijk; als een kwaadwillende 33% of meer van alle stakes in het netwerk heeft … wat we dan ook doen, dan zijn we de pineut omdat dat gewoon de limiet van consensus is die Sybil garandeert.
Maar wij willen echter de mogelijkheid van een slechtwillende die strategisch een controlerende of beïnvloedende hoeveelheid van stake plaatst in een bepaalde valideerder-set met belang verwijderen. Als ik in staat ben om dat te doen dan “win” ik. Het kan nog steeds gebeuren bij klein toeval, maar als ik winst wil maken dan kan ik niet rekenen op toeval en als rationele kwaadwillende zou ik dat niet nemen als een redelijke route van aanval om te profiteren.
In een open staking-protocol met slechts een kleinere bond zullen we een ‘longtail’ stake-distributie zien. De top 10% van de valideerders zal ergens in de buurt van 25-50% van staking-kracht controleren, met als bodem 10% die op zijn best 1-5% controleert. Dit is informatie die alle nodes kunnen zien en is gegarandeerd statisch voor een epoche, dus deze kan gebruikt worden als parameter voor valideerder-set-selectie.
Onze vereiste is dat geen individuele valideerder de shards die deze valideert kan controleren, en dat 2f+1 stemmen nodig zijn om een actie te committeren. F is in dit geval deterministisch variabel; *f* kan 10 zijn, 10.000.000 en de valideerder-selectie moet verzekeren dat er minstens 21 XRD of 20.000.000 XRD eerlijke* stake is in de respectievelijke validator-set.
* Een eerlijke/oneerlijke stake wordt niet “gekend” maar het wordt eenvoudigweg aangenomen dat het netwerk voldoet aan de laagste bonden van foutloosheid.
Omdat we de diverse informatie kennen over de valideerders maakt Cerberus het ons mogelijk om ons niet druk te maken over hoeveel stake er is of niet binnen de andere valideerder-sets die geen deel uit maken van de transactie. Het netwerk zou miljarden keren meer stake beschikbaar kunnen hebben, maar dat maakt niet uit. Wat er toe doet is dat aan een objectieve 2f+1 overeenkomst over ja of nee voor het committeren van een actie wordt voldaan.
Als een transactie meerdere shards raakt dan geldt het zelfde … we zouden 3 shard-transacties kunnen hebben, S1 zou 30 XRD kunnen hebben, S2 zou 100 XRD kunnen hebben en S3 zou 1.000.000 XRD kunnen hebben. Op het eerste gezicht kan dat slecht lijken, maar de valideerders in S3 hebben NIETS te zeggen in wat er gebeurt in S1 en S2. De regels zijn dat overeenkomst van 2f+1 moet gebeuren in ELKE shard ONAFHANKELIJK!
Zolang geen valideerder, of acteur-controlerende valideerder 10, 34 of 333.334 XRD heeft in één van de desbetreffende sets dan is alles goed in de wereld.
Het doel is dan te bepalen welke valideerders in welke sets moeten worden geplaatst, verzekerend dat geen enkele valideerder een controlerende beïnvloedende positie heeft binnen die set. Een vanzelfsprekende methode is om valideerders met een vergelijkbare stake gewoon samen te groeperen en dat een set te noemen, maar met een naïeve benadering zoals dat wordt snel gesjoemeld. Ik kan alleen een stel valideerders creëren met dezelfde stake-hoeveelheid op zo’n manier dat ik bijna zeker ben dat ze samen worden geplaatst.
Een oplossing komt in de vorm van gecombineerde optimalisatie, waar bonden en vereisten geplaatst kunnen worden op een set van elementen en de uitvoer is dan een oplossing die voldoet aan die specificaties. Een goedbekende gecombineerde optimalisatie is het knapzak-probleem waar er een knapzak is die een totaal gewicht van, laten we zeggen, 15kg kan bevatten, en er zijn een stel objecten met diverse gewichten en waarde. Het “probleem” is om een combinatie te vinden van deze objecten die de meeste waarde hebben zonder de gewichtscapaciteit van de knapzak te overschrijden. Een ander is het reizende verkopersprobleem en er zijn er veel meer.
We kunnen dezelfde principes toepassen om oplossingen te vinden voor het knapzak-probleem (en veel andere met een vergelijkbare aard in dat domein) om een set valideerders te produceren die voldoen aan de gestelde vereisten. Deze algoritmes vragen veel rekenkracht en een toename van valideerder-sets om te selecteren vergroot de complexiteit. Maar epochen zijn lang genoeg, zodat de volgende set van valideerders kan gebeuren op de achtergrond van iedere node, en klaar kan zijn voor de volgende epoche.
Verder zullen alle nodes, vanwege de aard van deze functies, komen tot dezelfde uitvoer met dezelfde invoer, dus er is geen “consensus” over het resultaat nodig.
*Zucht* … Er is meer over bovenstaande in het Discord-kanaal, dus ik zal deze groep niet nog meer inpeperen met meer over dat ontwerp. Hopelijk zet het echter minstens alle initiële zorgen voor iedereen terzijde en legt het tot op zekere hoogte uit waarom het niet zo’n probleem is als het in eerste instantie leek te zijn.
Website: https://www.radixdlt.com
Twitter: https://twitter.com/RadixDLT
Telegram: https://t.me/radix_dlt
Show Posts
