Nybegynnerguide til Vyper Smart Contract Language

Vyper er et smart kontraktspråkparadigme som stammer fra Python 3-syntaksen og konvensjonene og retter seg mot Ethereum Virtual Machine (EVM).

EVM er en simulert global singleton-datamaskin som går parallelt med den blokkjedede hovedboken på Ethereum, noe som muliggjør bygging av mer komplekse transaksjoner og betingede selvutførende avtaler kodede smarte kontraktsobjekter..

Ethereum-plattformen i seg selv er uformell og agnostisk, og gir bare ryggraden i hvordan smarte kontrakter skal settes sammen og i sammenheng med hvilke applikasjoner.

Vyper er ment å være utnyttet med den kommende overgangen til Proof-of-Stake (Casper) og gi et mer pragmatisk minimalistisk regime for lesing og skriving av smarte kontrakter, med fokus på revisjon, syntaktisk enkelhet og greihet.

Vyper vs. soliditet

Soliditetslogo

I det avviker Vyper skarpt fra de facto mainstream Solidity. Siden beregninger på kjeden er begrenset med ressurser, bør de være så strengt definert i det minste nødvendige behov for den tiltenkte funksjonen, og Vyper tar denne reduktive tilnærmingen til smarte kontrakter, og rammer dem inn som lettlesbare brukerroller og historier, mens nesten alt annet er ute.

En umiddelbart merkbar avvik fra soliditet er å fjerne arv for å holde ting “på samme side” i stedet for å gå seg vill i å hoppe mellom flere kontraktsfiler i hierarkiet for deres forrang for å samle de spredte fragmentene av hva en programmet gjør under panseret.

I stedet blir det lagt vekt på raffinert, avskåret komposisjon og modularitet (med typer som eier, vedlikeholder, token, deadline og mulige uttrykk som “mens gass er igjen”) uten å samtidig slappe av noen sikkerhetsforutsetninger, men heller håndheve syntaktisk åpenhet for å gjøre ting umiddelbart åpenbare og lett kontrollerbare, i tråd med arten av kontrakter og distribuerte hovedbøker.

Sikkerhetsegenskaper

Sikkerhet er viktigst i sammenheng med smarte kontrakter i et konsensusintegrert, globalt distribuert miljø ment å fungere som et gjennomsiktig notarius og generalisert institusjonelt byrå for å skrive pålitelig forretningslogikk.

I tråd med disse målene fokuserer Vyper på uttrykksklarhet, streng, tydelig entydighet og sterk skriving, og som sådan fjerner operatørens overbelastning, prøver å være så ikke-fragmentert og artikulert som mulig (fokus på det strengt nødvendige) i for å gjøre det vanskelig å skrive misvisende kode. Faktisk forbyr det bevisst noen ting for å gjøre dem vanskeligere med målet om å øke smart kontraktssikkerhet ved å håndheve åpenbare, selvforklarende kodemønstre..

Rekursive samtaler og uendelige lengdesløyfer er også ekskludert fordi de åpner muligheten for gassbegrensningsangrep, og i stedet har Vyper som mål å optimalisere gassmålinger ved å estimere presise øvre grenser for gassforbruket til ethvert funksjonsanrop. Grenser og overløpskontroll for tilgang til matematikk og aritmetiske operasjoner er inkludert (ingen SafeMath-bibliotek nødvendig) og ingen modifikatorer eller konstanter har lov til å endre tilstand.

Compiler Internals og Code Syntax

Vyper prøver å holde seg til syntaktiske konvensjoner nær kjernen i det de beskriver, nemlig EVM. Vyper-skript kompileres direkte til EVM bytecode i stedet for å bli tolket, uvanlig måte å tenke på Python, som dette kan være. Under panseret kompileres både Vyper og Solidity for å bytekode på samme måte og sekvens av trinn, slik at de stort sett er interoperable (og i stand til å ringe eksterne samtaler mellom hverandres kontrakter).

Kort fortalt blir koden tatt opp av en parser som demonterer den til en abstrakt syntaks-trerepresentasjon av instruksjonene, og derfra går en typekontrollprosess gjennom treet og tildeler deres tilsvarende typer nedenfra og oppover. Etter utførelse av statisk analysekontroll blir bytekoden generert.

Generell struktur for en kontrakt

Vyper er funksjonsmessig komplett og venter for tiden på revisjoner og betatesting. Å navngi konvensjoner i Vyper prøver å være så nær kjernen i det den koden prøver å beskrive (dvs. EVM, som er så enkelt som det minste av det som kan kalles en prosessor) som mulig, selv om det er i en pyetonisk form av veien.

De to typer heltall er betegnet som unit256 og int128 som henholdsvis står for ikke-negative og signerte heltall. unit256 støttes ikke fullt ut som en numerisk type på grunn av kompleksitetsøkning, da de fleste applikasjoner bare krever int128. unit256 er inkludert for å sikre interoperabilitet med ERC-20-standarden.

En Ethereum smart kontrakt består vanligvis av tilstandsvariabler og funksjoner.

Tilstandsvariabler er verdier som er permanent lagret i kontraktlagring og kan være av antall, streng, adresse eller boolske sanne / falske uttrykkstyper.

Statlige variabler erklæres enkelt:

storeData: int256

Kartlegginger er tilstandsvariabler som definerer sett med nøkler og tilsvarende verdier. I Vyper er de definert og tilgjengelig slik:

plainMapping: desimal [int256]

vanlig kartlegging [0] = 10.1

Først blir verdien erklært og deretter typen. Når du får tilgang til en kartlegging, er posisjonen i tabellen spesifisert i parentes.

Funksjoner er kjørbare enheter av kode i en kontrakt som definerer hva slags oppførsel de kan utløse. I likhet med Python blir funksjoner i Vyper erklært med “def”.

Funksjoner i smarte kontrakter er enten lesefunksjoner (som er raske og ikke koster bensin) eller skrive / utføre funksjoner (som skriver inn på blockchain og derfor koster gass per syklus, og aktualiseres i neste blokk).

En konstruktorfunksjon, som etter soliditetskonvensjonen har samme navn som kontrakten, instantiserer den gitte kontrakten og dens grunnleggende parametere på blockchain som sådan. Denne funksjonen utføres bare én gang, og i Vyper tar den form av Python __init__-metoden (en spesiell metode som kalles når et objekt i den klassen blir opprettet). For eksempel i en enkel token-kontrakt:

@offentlig

def __init __ (_ navn: bytes32, _symbol: bytes32, _decimaler: uint256, _initialSupply: uint256):

  self.name = _name

  self.symbol = _symbol

  self.decals = _decimaler

  self.totalSupply = uint256_mul (_initialSupply, uint256_exp (convert (10, ‘uint256’), _decimals))

Selvmetoden hevder eksplisitt de spesifikke forekomstvariablene i klassen for semantisk klarhet.

Avhengig av synlighetsnivå, kan funksjoner være dekorert med enten @public eller (som standard) @private. Offentlig synlighet betyr at metoden blir eksponert i kontraktens ABI (Application Binary Interface) som gjør det mulig for eksterne aktører å kalle den.

I eksemplet ovenfor instanserer en konstruktorfunksjon de grunnleggende variablene som beskriver en tokenkontrakt, dvs. navn, ticker, desimalpunkt for delbarhet og total tilførsel av pregede poletter i omløp.

Andre dekoratører inkluderer @constant, for dekorasjonsmetoder som bare leser en tilstand, og @payable for designating metoder som kan kalles med betaling.

For eksempel:

@offentlig

@som skal betales

def bud (): // Funksjon

Eksterne samtaler støttes ved å definere den eksterne kontrakts ABI øverst i kontrakten:

klasse Foo ():

   foo (bytes32): pass

Hendelser kan logges i indekserte strukturer slik at klienter kan søke etter dem.

Betaling: __log __ ({beløp: int128, arg2: indeksert (adresse)})

total_betalt: int128

@offentlig

def lønn ():

  self.total_paid + = msg.verdi

  log.Payment (msg.value, msg.sender)

Hendelser må erklæres før globale erklæringer og funksjonsdefinisjoner.

Sette opp miljøet

I Ubuntu er installering av vyper som en ‘snap’ en rask måte å komme i gang hvis du har problemer med å kjøre Python 3.6:

$ sudo apt-get install snapd

$ sudo snap installere vyper –edge –jailmode

Å lage en kontrakt til bytecode er like grei som: vyper filnavn.v.py (filtypen er vanligvis ment som .vy, men holder for tiden .v.py for Python-syntaksmarkering)

For å få ABI:

huggorm -f json eksempel.vy

Alternativt leveres en integrert online kompilator på vyper online som også har et rikt sett med eksempler som en soliditetskompatibel ERC-20-token, en økonomisk begivenhet logger og en kjede markedsmaker. I motsetning til Remix for Solidity kommer den imidlertid ikke med en testutførelsesplattform, men kompilerer bare til bytekode og gir ABI i kontrakten.

For å teste kontrakter må vi spinne et lokalt blockchain-miljø, hvis formål er Ganache (tidligere TestRPC) fra Truffle-pakken er et alternativ, men migrasjoner må gjøres manuelt fra konsollen.

Et alternativ er i gang og kan kjøres med Parity-klienten i privat kjedemodus som det er gitt et forhåndskonfigurert Docker-bilde (med en enkeltnode Proof-of-Authority blockchain) her. Når beholderen er i gang, kan du få tilgang til det grafiske brukergrensesnittet fra nettleseren på localhost: 8180. Det nettleserbaserte grensesnittet tillater distribusjon og interaksjon med kontoer og kontrakter lokalt.

Imidlertid brukes pyethereum (Ethereum core library for Python) for det meste på grunn av at den er lett og generelt Python-kompatibel, med en plugg inn for naturlig testing av kontrakter i utvikling.

Utvikling og involveringer

Til tross for mangel på mye publisitet eller vanlig oppmerksomhet, eller til og med mye dokumentasjon til veldig nylig, har Vyper blitt jobbet stille i ganske lang tid nå og er bare i det siste.

Imidlertid har det begynt å tiltrekke seg oppmerksomhet fra smarte kontraktutviklere og sikkerhetsrevisorer fra OpenZeppelin, og en kontingent av mennesker som er misfornøyde med de korte innfallene av Solidity, på jakt etter mer intuitivt enkel og mindre sveitsisk hærkniv som alternativer.

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me