Belønninger og straffer på Ethereum 2.0 [Fase 0]

blogg 1NyheterUtviklereEnterpriseBlockchain ExplainedBegivenheter og konferanserPresseNyhetsbrev

Abonner på vårt nyhetsbrev.

Epostadresse

Vi respekterer personvernet ditt

HomeBlogCodefi Aktiver

Belønninger og straffer på Ethereum 2.0 [Fase 0]

av James Beck 2. mars 2020 Publisert 2. mars 2020

Bilde fra iOS

Introduksjon

ConsenSys Codefi bygger blockchain-operativsystemet for handel og finans for å hjelpe globale markeder mot “Finance 2.0.” En kritisk del av denne innsatsen er å muliggjøre opprettelse og bruk av innfødte digitale eiendeler som stimulerer maksimalt desentraliserte nettverk til å fungere pålitelig som ryggrader for nye finansielle produkter og markeder. Aktivering av “Ethereum 2.0” og overgangen til bevis på innsats er i sentrum for oss, og vi er glade for å begynne å dele vår erfaring, ekspertise og mye mer om disse emnene, inkludert her tokenøkonomien.

Den store etterspørselen etter Ethereum 1.0 har noen ganger resultert i uønskede brukeropplevelser som lang ventetid på at transaksjoner skal inngå i kjeden, og volatile transaksjonsgebyrpriser. Massiv skalerbarhet – muligheten til å behandle tusenvis av transaksjoner per sekund i stedet for de nåværende 15-eller-så-transaksjonene per sekund – har lenge vært en del av planen for Ethereum.

Vi er nå i den første fasen – fase 0 – av lanseringen av Ethereum 2.0. Når alle faser på 2.0 er fullstendig implementert, vil volumet av transaksjoner forbedre seg dramatisk. To store oppgraderinger i Ethereum-koden vil gjøre dette mulig: sharding og Proof-of-stake. Denne oppgraderingen vil resultere i et nettverk med redesignet økonomi, konsensus og driftsmekanisme, som vi vil forklare mer detaljert nedenfor.

Motivasjon

Ethereum 1.0 er en Proof-of-work blockchain: For å lage en blokk, løser gruvearbeidere et puslespill med en sannsynlighet proporsjonal med hashrate de har tilgjengelig, og omvendt proporsjonal med vanskeligheten i kjeden. Hvis gruvearbeideren lykkes, får den en belønning på 2 ETH pluss transaksjonsgebyrer. Det er alt. Ved å undersøke vanskeligheten med den siste blokken, kan du anslå nettverkets hashrate, som igjen vil gi deg beskjed om hva som er oddsen din for å få neste blokk, slik at du kan forutsi utbetalinger.

Ethereum 2.0 er litt mer teknisk i denne avdelingen.

Hvis du ankom hit, og bare vil ha baksiden av konvoluttreferansen, kan du hoppe til seksjonen “Et nyttig estimat av nettverksutstedelsen”.

Hensikten med dette dokumentet er å gi leseren en oversikt over implementeringen av bevis på stav av Ethereum 2.0, samt system for belønninger og straffer. Vi vil dele opp insentivene i et sammendrag, med en rask vurdering av hva som kan være avkastningen på en innsats gitt visse forutsetninger. Vi avslutter med en teaser av en simulering Codefi Staking-as-a-Service-teamet bygger for å få en mer detaljert forståelse av dette emnet.

The Honest Validator

Hvis du foretar en eller flere innbetalinger til innskuddskontrakt distribuert i Eth1-kjeden, som beløper seg til et beløp som er lik eller større enn 32 ETH, kan du kvalifisere deg for å være en validator av Eth2 Beacon-kjeden.

Det er ingen grenser for hvor mye ETH du kan legge til en validators innsats. Det er imidlertid en øvre grense – nemlig effektiv balanse, satt til 32 ETH – på hva som er det faktiske beløpet som teller for dets interaksjoner i Beacon-kjeden. Med andre ord kan saldoen din være så høy som 1000 ETH, men belønningene og straffene dine er en funksjon av den effektive saldoen din som er begrenset til 32 ETH.

På den annen side, hvis validatoren din blir påvirket av straffer og balansen synker til eller under 16 ETH, utløser den det som kalles en kraftig (eller ufrivillig) utgang.

Den såkalte ærlige validatorer vil kjøre godt utformede kunder, som overholder Beacon-kjedespesifikasjonene, og unngå straffer for feil stemmegivning. Eller hva som kan være verre, kutter for protokollfeil.

Det er viktig å nevne det å motta en straff er ikke det samme som å bli kuttet: Førstnevnte representerer bare en reduksjon i balansen på validatoren på grunn av for eksempel en feilkastet stemme (innenfor visse parametere) eller å være frakoblet. En validator som blir tatt på seg med en skråstrekningsattest trekkes kraftig ut av Beacon-kjeden, med balansen straffet i hver epoke i perioden den er i den forlate køen.

On Block Minting and Consensus i Ethereum 2.0

Strømmen til Beacon-kjeden er bygget på en tidsenhet kalt spor. Som et hjerterytme – hvert 12. sekund – blir en validator valgt til å være forslagsstiller. Når blokken er myntet og forplantet, stemmer en attesterkomité for validatorer for at denne blokken skal være en del av den kanoniske kjeden..

Formålet med komiteer i Beacon-kjeden er å distribuere validatorene, slik at hver og en er i stand til å stemme en gang pr. epoke (hver 32 spor). Validatorer i komiteer sladrer hverandre, slik at det kan samles attester.

Hvis det under en spalte ikke er foreslått en blokk, blir den identifisert som en hoppet over spor. I denne situasjonen er ytterligere forslag eller attester bygget på den siste blokken som er tilgjengelig fra et tidligere spor.

Forslagsstiller velger over hvilken blokk den vil utføre tilstandsovergangen til den nye kanoniske hode av kjeden. Dette valget er laget av algoritmen LMD GHOST gaffelvalg: Fremgangsmåten plukker den gaffelen som det er rekursivt den største vekten av mottatte stemmer. Når validatorer bekrefter denne blokken, stemmer de faktisk for dette gaffelvalget.

For å gi endeligheten til blockchain, det vil si forsikringen om at staten ikke kan reverseres, utnytter ærlige validatorer Eth2 implementering av Casper the Finalality Gadget (FFG), og gir i sine attester to ekstra stemmer: En for den siste berettigede epoken (kilde), og en for den siste epokegrensen (mål).

 

Kilde: ConsenSys Codefi-analyse

Kilde: ConsenSys Codefi-analyse

 

begynnelsen av hver epoke, attester telles. Hvis det eksisterer en overmengde (to tredjedeler), vil det siste rettferdiggjorte epokepunktet bli flyttet fremover i tid, og under visse regler vil sluttføring oppnås enten for den forrige epoken, eller for dens forgjenger.

Hvis systemet ikke har oppnådd finalitet i en rekke epoker (4 etter gjeldende spesifikasjon), blir alle validatorene i fyrkjeden slått med en inaktivitetsstraff.

Det er mye å pakke ut her! Hvis du vil utforske detaljene nærmere, er de beste referansene Gasper (som i GHOST + Casper) papir (Buterin et al), den faktiske spesifikasjonene til kjeden i fase 0 (Ethereum Foundation), Fase 0 for mennesker (Danny Ryan), og Beacon chain ethereum forklareren du trenger å lese først (Joseph Chow).

Belønninger og straffer

Slashing

Å være kuttet betyr at validatoren blir tvunget til å gå ut fyrkjeden på et tidspunkt i fremtiden, mottar en rekke straffer til den forlater.

Det er tre måter en validator kan få den skråstilte tilstanden på:

  1. Ved å være en forslagsstiller og signer to forskjellige fyrblokker for samme spor.

  2. Ved å være en attester og signer et attest som “omgir” et annet.

  3. Ved å være attester og signere to forskjellige attester som har samme mål.

I alle disse tilfellene må lovbryteren bli tatt for at kuttprosessen skal utløses. Varslervalidatoren vil opprette og formidle en spesifikk melding som inneholder lovbruddet, slik at en forslagsstiller kan inkludere den i en blokk. Både forslagsstiller og varsleren vil ha rett til en belønning.

Det er ikke helt opplagt i spesifikasjonen, men i fase 0 bare forslagsstiller får varsleren – det er, forslagsstiller får hele skarpe belønningen (8/8 av det).

Kilde: ConsenSys Codefi-analyse

Kilde: ConsenSys Codefi-analyse

Antagelser

  • Konstant MIN_SLASHING_PENALTY_QUOTIENT = 32

  • Konstant WHISTLEBLOWER_REWARD_QUOTIENT = 512

  • Konstant PROPOSER_REWARD_QUOTIENT = 8

Forbryteren blir en kuttet validator, og får tildelt et uttrekkbart epokesett 36 dager (8192 epoker) i fremtiden.

Videre mottas den skråstrekkede validatoren

  1. EN minimumsstraff for øyeblikket inkluderer forslagsstiller varslingsmeldingen i en blokk

  2. Et straffespark på begynnelsen på hver epoke, for manglende leder / FFG-stemmer, til validatoren forlater utgangskøen

  3. EN spesiell straff brukes midt mellom tidspunktet da varslingsmeldingen er inkludert i en blokk, og tiden da den kuttede lovbryteren kan trekke seg tilbake.

Denne spesielle straffen er proporsjonal med hvor mange andre validatorer som også har blitt kuttet i løpet av perioden. Det maksimale anvendte kan være så høyt som hele lovovertrederens effektive balanse.

Kilde: ConsenSys Codefi-analyse

Kilde: ConsenSys Codefi-analyse

Antagelser

 

Skjermbilde 2020-03-02 kl 19.47.04.png

 

Epokebehandling

begynnelsen av hver epoke (hver 32 spor, unntatt GENESIS), skjer det flere ting, inkludert

  1. Begrunnelse og sluttføring av kjeden

  2. Tildeling av belønninger og straffer til attester

  3. Oppdatering av validatorregisteret

  4. Den spesielle kuttstraffen (se ovenfor), og

  5. Noen endelige oppdateringer (beregning av effektive saldoer, tilbakestillinger osv.)

En validator må ha hatt aktiv status på forrige epoke for å motta belønninger og / eller straffer. Inntil de går ut, kommer også skråstrekkede validatorer inn i denne prosessen, der de bare blir straffet i FFG-samsvarskategoriene.

Hvis en validator har vært aktiv i forrige periode, men stemte ikke, det vil bli straffet for ikke å matche FFG-stemmene. Validatorer blir ikke kuttet for å være frakoblet.

Kilde: ConsenSys Codefi-analyse

Kilde: ConsenSys Codefi-analyse

Antagelser

 

Skjermbilde 2020-03-02 kl 19.47.04.png

 

  • Finality Delay = Forrige epoke – Avsluttet epoke

  • Attesting Balance = Summen av uslipt attesterbalanse

  • Konstant BASE_REWARD_FACTOR = 64

  • Konstant BASE_REWARDS_PER_EPOCH = 4

  • Konstant PROPOSER_REWARD_QUOTIENT = 8

  • Konstant MIN_EPOCHS_TO_INACTIVITY_PENALTY = 4

  • Konstant INACTIVITY_PENALTY_QUOTIENT = 2 ** 25

 

Kilde: ConsenSys Codefi-analyse

Kilde: ConsenSys Codefi-analyse

 

Et nyttig estimat av nettverksutstedelsen

La oss bruke vår nyervervede kunnskap til å produsere en bakside av konvoluttestimeringen av belønningene og straffene for en vilkårlig periode. Vi vil gjøre det enkelt, og starte med bare to parametere.

Kilde: ConsenSys Codefi-analyse

Kilde: ConsenSys Codefi-analyse

Førstnevnte er selvforklarende, mens sistnevnte kan sees på som sannsynligheten for at en tilfeldig valgt validator er i stand til å delta i fyrkjeden (vertsmaskinen er slått på), har en fungerende internettforbindelse eller andre faktorer.

Hvis vi antar det alle validatorer i fyrkjeden har både balanse og effektiv balanse lik 32 ETH, og vi bruker den online sannsynligheten vi har

Kilde: ConsenSys Codefi-analyse

Kilde: ConsenSys Codefi-analyse

Nå er vi i forhold til å beregne følgende belønninger og straffer for hver validator

Kilde: ConsenSys Codefi-analyse

Kilde: ConsenSys Codefi-analyse

Det er nødvendig å jobbe litt for de to siste insentivene: Blokkattesterne antas å være online validatorene i et spor, jevnt fordelt over epoken; For attesterinsentiv skal vi gjøre det konvergerer den geometriske serien som vi får etter å ha definert sannsynlighetstreet for den forventede verdien, siden denne belønningen er omvendt proporsjonal med forskjellen på spor, er den inkludert fra attesten.

Vi ser at forslagsstillerens insentiv i større mengde overstiger de andre beløpene. Husk at en forslagsstiller blant alle validatorene i fyrkjeden er valgt i hvert spor, noe som gjør oddsen for å bli en mindre ettersom den totale innsatsen vokser. Med andre ord, innenfor en epoke, bare 32 av N-validatorer blir forslagsstillere.

Vær også oppmerksom på at vi ikke tar noen antagelse eller beregninger om kuttede validatorer og deres varslere, og heller ikke inaktivitetsforsinkelsen.

Hvis vi multiplisere de individuelle verdiene oppnådd av den respektive mengden online eller offline validatorer, og vi legger dem til, kommer vi til et estimat av beløpet generert fra de opprinnelige forholdene gitt.

Kilde: ConsenSys Codefi-analyse

Kilde: ConsenSys Codefi-analyse

Det vil si rundt 1,25 ETH per epoke (6,4 minutter) fra en total innsats på 500.000 ETH og antar en online sannsynlighet på 95%.

Det er fristende å gå, beregne og kartlegge – med en 95% sannsynlighet på nettet – mengden ETH som ble opprettet i løpet av en epoke ved forskjellige innsatser.

Kilde: ConsenSys Codefi-analyse

Kilde: ConsenSys Codefi-analyse

Innpakning

Skal vi bare fortsette og multiplisere dette beløpet vi har fått per epoke, å gi en årlig anslag?

Før du svarer ja, la oss vurdere følgende faktorer:

Balansere

Det er mange forskjellige måter som balanser påvirker etableringen av ETH i hver epoke. For eksempel hvis en validator får belønninger på toppen av effektiv balanse cap (det vil si 32 ETH), vil ikke alle disse overskytende midlene påvirke beregningene i neste periode. Også på grunn av hysterese anvendt på effektive saldoer, er det faktisk en del av ETH “tapt” på hver validator.

Tenk også på hva som skjer når validatorer er det kastet ut på grunn av manglende opprettholdelse av minimumsbeløpet (16 ETH), når validatorer er aktivert ettersom nye innskudd vil bli betalt til Eth1 innskuddskontrakten, eller når spillere utløser frivillige utganger.

Slashing

Slashing-operasjoner vil være i god tid ikke trivielt å modellere. Til å begynne med må Eth2-klientutviklere og innsatstjenester lære å unngå at forholdene blir kuttet. På den annen side kan vi bare gjette hva som vil være andelen ærlige spillere i systemet; Eller om lovbruddene deres vil bli oppdaget, kringkastet og inkludert i blokker.

Sannsynligheter

Vi har allerede berørt emnet med andelen ærlige spillere, og oddsen for å publisere for en varsleren. La oss også tenke på de forskjellige måtene vi kan måle og estimere at en node vil være online, godt koblet og fungere skikkelig. At attestene blir samlet og inkludert i tide, eller å få utsikt over sporet som flertallet ser.

Fyrkjeden er en komplekst adaptivt system. Selv om vi oppnår en perfekt forståelse av hver av dens individuelle deler, er det ikke garantert at vi ville få en perfekt forståelse av helheten.

Mestring av ethvert emne starter med å velge metoder og verktøy som passer oppgaven. Av modellering og simulering aspekter av validatoren og dens interaksjoner i kjeden – under en rekke innledende forhold, antakelser og begrensninger – bør vi kunne bygge innsikt i komplikasjonene i denne Proof-of-stake-implementeringen.

Anerkjennelser

Skrevet av Herman Junge, en arkitekt og teknisk leder for Staking-as-a-Service-plattformen til ConsenSys Codefi.

Vi takker Joseph Chow, Ben Edgington, Sylvain Laurent, Diederik Protolambda Loerakker, Tim Lowe, Danny Ryan, Alex Stokes og Kuhan Tharmananthar for kommentarer til manuskriptet.

Vil du lære mer om staking som en tjeneste? Ta kontakt med ConsenSys Codefi her.

Desentraliserte nettverkDeFiEthereum 2.0Industry InsightNyhetsbrev Abonner på vårt nyhetsbrev for de siste Ethereum-nyhetene, bedriftsløsninger, utviklerressurser og mer.

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me
Like this post? Please share to your friends:
map