Hoe we 96 gekozen verificateurs voortbrachten

(Indika) (5 september 2019)

De laatste keer dat ik een artikel publiceerde, was vijf jaar geleden, en het was getiteld: Een webserver koken met Chef . Vijf jaar is lang om niet te schrijven. Het is niet dat ik mijn interesse in het onderwerp had verloren; in plaats daarvan leerde ik stilletjes van de besten.

Het onderwerp van discussie is echter niet veranderd, behalve dat het nu een orde van grootte groter is. Destijds was ik een enkele webserver aan het koken, en nu breng ik 96 Elected Verifiers (EVs) voort.

Waarom 96?

Bij Unification veranderen we het onderliggende consensusalgoritme van Ethereum. Onze Distributed Stake Governance-implementatie omvat vier groepen van 24 EVs, die in en uit blokvalidatie draaien. Het beheer van deze rotaties wordt vergemakkelijkt door een proces van stemmen en uitzetten. Het eindresultaat is een meer gedistribueerd consortiumnetwerk.

Het theoretisch leren van dit onderwerp op whitepapers en in simulaties kan ons slechts tot nu toe brengen. De beste manier om verder te gaan is door het te produceren, ermee te spelen en eventuele tekortkomingen te ervaren.

Continue levering

We willen in staat zijn om onze ideeën snel te evalueren . Testgestuurde ontwikkeling hoeft niet beperkt te blijven tot het schrijven van unit-tests.

Voor elke gegeven Git SHA willen we elke versie van onze Mainchain laten draaien door een enkele opdracht uit te voeren, de staat ervan te evalueren en vervolgens verfijningen van het DNA.

We willen dit proces blijven verfijnen, totdat we denken dat we iets gereed hebben voor productie. Het proces van softwareontwikkeling is niets meer dan deze simpele iteratie:

Hoe complexer een systeem wordt, hoe moeilijker elk van deze onderdelen wordt. Het instantiëren van 96 elektrische voertuigen is een niet-triviaal probleem, en dit is de focus van dit artikel.

Definitie

We beginnen met te definiëren wat we willen inzetten. Een geïnstantieerd cluster zal meestal bestaan ​​uit EVs, waarvan een paar RPC hebben ingeschakeld en andere niet. Het cluster kan ook een UND-kraan, een blokverkenner en misschien zelfs een controleknooppunt bevatten.

Deze clusters worden gespecificeerd door JSON-bestanden, en het doel van de provisioning-stack kan ze zo maken.

Elk knooppunt in het cluster heeft een unieke handle nodig, en het volgende adresschema is gekozen:

x = "{cluster\_name}-{configuration}-{instance\_type}-{index}"

Bijvoorbeeld:

alpha-basic-ev-1

In de bovenstaande verklaring verwijst het woord “basic” naar een configuratie, waarin er vier EVs en één blokverkenner zijn. Het woord ‘alpha’ is de naam van het experiment.

The Stack

We hadden Kubernetes kunnen gebruiken.

We willen echter ook investeren in tools creëren die onze gemeenschap kan gebruiken om hun eigen EVs te lanceren. We kiezen voor Ansible vanwege zijn eenvoud, en de playbooks die gericht zijn op CentOS werken op elke architectuur of kunnen gemakkelijk worden aangepast.

Hoewel ik in het verleden zowel Chef als Puppet heb geëvalueerd, heb ik Ik heb ze allebei gedumpt vanwege de eenvoud van Ansible. Chef en Puppet hebben softwarecomponenten nodig op de doelcomputer, maar Ansible heeft alleen een SSH-verbinding nodig.

Er is hier geen kwantumfysica met betrekking tot de stapel; slechts noodzakelijke stappen op weg naar succes. Onze stack is samengesteld uit:

  • AWS-gebruikers en AWS API
  • AWS-lanceringssjabloon
  • AWS-tags
  • Minimalistische bash-startup script
  • Een bash-script uit Github curlen
  • Ansible-hostvars configureren op basis van tags
  • De host inrichten met Ansible

AWS API en AWS-gebruikers

AWS biedt extreem gedetailleerde controle over it-services via de API en geautoriseerde gebruikers. De API is fatsoenlijk toegankelijk via de Python boto3-bibliotheek. Een voorloper van het gebruik van de API is het aanmaken van de relevante Gebruiker via de IAM-interface. Een gebruiker is een typisch gebruikerstoegang-ID en een geheim paar.

Een gebruiker kan worden toegevoegd aan een of meer beleidsregels. Een beleid bestaat uit een reeks toegestane of geweigerde acties op een reeks bronnen.

Onze spawn-gebruiker heeft een beleid bijgevoegd met minimalistische acties om een ​​EC2-instantie te maken, en acties om de volledige resource set te lezen.

Launch Templates

Een van de belangrijkste functies die AWS ons biedt, zijn Launch-sjablonen.

Met een Launch-sjabloon kan men een basis-AMI specificeren (de identificatie voor de virtuele machine-image om een ​​instantie van te maken) en vooraf configureren instellingen, inclusief twee essentiële componenten: Tags en een Run Script. Bovendien kan men de beveiligingsgroep specificeren waartoe de machine behoort.

Startsjablonen kunnen worden voorzien van een versie, en instanties kunnen worden gestart vanaf de AWS-gebruiker.

Tags

Elke EC2-instantie is uniek op basis van de tags waarmee deze is geconfigureerd. De volgende informatie wordt naar het knooppunt gestuurd:

  • Naam (unieke identificatie van het knooppunt)
  • Klasse (het type instantie)
  • Index ( de positie van de instantie)
  • Configuratie (de verscheidenheid aan clusters die worden geïnstantieerd)
  • SHA (een Git SHA)
  • RegistrationIP (het IP-adres van de Registration Tower)

Elk van deze tags is ingesteld in de Ansible hosts-vars.

Bootstrapping met Bash

Het Bash-bootstrap-script bereidt de host voor voor bevoorrading. Enkele van de taken die worden uitgevoerd, zijn het installeren van een standaard Python-omgeving, het ontleden van AWS-tags, het schrijven van deze naar het Ansible-hostvars-bestand en het selecteren van het juiste Ansible-playbook voor het type knooppunt.

Ansible

Ten slotte is het knooppunt voorzien van Ansible. Ik zal niet afdwalen in Ansible omdat er genoeg andere bronnen op internet zijn. Er is hier niets speciaals, behalve dat men doorgaans een externe server configureert met Ansible, maar in ons geval configureren we de lokale server.

Registratietoren

We gebruiken een registratietoren in plaats van een Bootnode om het netwerk op te starten. EVs registreren hun IP-adressen na instantiatie met het registratieknooppunt en er wordt een lijst met statische knooppunten verkregen voordat de service wordt geactiveerd.

Het voordeel van het gebruik van zon Tower is dat we willekeurige gegevens kunnen gaan registreren, zoals gezondheidsstatistieken, waardoor de evaluatielus kan worden gesloten.

Wanneer een EV wordt geïnstantieerd, schrijft deze naar de registratie-API, zijn clusternaam, IP-adres, index en instantietype.

Evaluatie

De belangrijkste focus van evaluatie is om te bepalen hoe succesvol was het experiment. Wat de voorwaarden voor succes zijn, komt in een ander artikel aan de orde. Een onmiddellijke statistiek om in de gaten te houden, zijn echter de kosten.

De prijs voor een t2-micro-instantie is 0,012 / uur. De kosten om 96 hiervan gedurende één uur te laten draaien, zouden slechts een dollar moeten zijn. Dit kan worden bevestigd in de kostenverkenner.

Verder

Deze stapel werkt prachtig. Een enkele opdracht brengt consequent en foutloos een volledig verbonden en block-propagerende Mainchain naar voren. Wat ik het leukst vind aan deze stapel is dat het vuur is en vergeet; Ik kan het cluster starten, de verbinding met internet verbreken en gaan jongleren. Als ik terugkom, staat er een Mainchain voor me klaar.

Dit dient als een sterke basis voor onze volgende stap. We kunnen verschillende configuraties van ons consensus-DNA gaan evalueren. We zullen ons huidige eenvoudige consensusalgoritme laten rijpen en evalueren tegen de brute realiteit, in ons volgende artikel getiteld “Distributed Stake Governance”.

De broncode voor de EV Provisioning-stack is hier te vinden: https://github.com/unification-com/ev-provision

Doe mee met Unification Gitter: https://gitter.im/unification-com

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *