Decentraliseret, open source affiliate program på Waves blockchain

Et decentraliseret affiliate-program på Waves blockchain, implementeret som en del af en Waves Labs-bevilling af Bettex-teamet.

Indlægget er ikke reklame! Programmet er open source, dets brug og distribution er gratis. Brugen af ​​programmet stimulerer udviklingen af ​​dApp-applikationer og fremmer generelt decentralisering, hvilket gavner enhver internetbruger.

Den præsenterede dApp for affiliate programmer er en skabelon til projekter, der inkluderer affiliate som en del af deres funktionalitet. Koden kan bruges som en skabelon til kopiering, som et bibliotek eller som et sæt ideer til teknisk implementering.

Funktionsmæssigt er der tale om et almindeligt affiliate-system, der implementerer registrering hos en referer, multi-level optjening af belønninger for henvisninger og motivation for registrering i systemet (cashback). Systemet er en "ren" dApp, det vil sige, at webapplikationen interagerer direkte med blockchainen, uden at have sin egen backend, database mv.

Anvendte teknikker, som også kan være nyttige i mange andre projekter:

• Gælder en smart konto med øjeblikkelig tilbagebetaling (på tidspunktet for opkaldet er der ingen tokens på kontoen til at betale for opkaldet, men de vises der som følge af opkaldet).
• PoW-captcha - beskyttelse mod højfrekvente automatiserede opkald til smart kontofunktioner - analogt med captcha, men gennem bevis for brugen af ​​computerressourcer.
• Forespørgsel efter datanøgler ved hjælp af en skabelon.

Ansøgningen består af:

• smart kontokode i ride4dapps-sproget (som som planlagt er flettet ind i den primære smartkonto, for hvilken affiliate-funktionalitet skal implementeres);
• js wrapper, der implementerer et abstraktionsniveau over WAVES NODE REST API;
• kode på vuejs frameworket, som er et eksempel på brug af biblioteket og RIDE-koden.

Lad os beskrive alle de nævnte funktioner.

Ringer en smart konto for gæld med øjeblikkelig tilbagebetaling

Opkald til InvokeScript kræver betaling af et gebyr fra den konto, der starter transaktionen. Dette er ikke et problem, hvis du laver et projekt for blockchain-nørder, der har en vis mængde WAVES-tokens på deres konto, men hvis produktet er rettet mod brug af den brede offentlighed, bliver dette et alvorligt problem. Brugeren skal jo sørge for at købe WAVES-tokens (eller et andet passende aktiv, som kan bruges til at betale for transaktioner), hvilket øger den i forvejen betydelige barriere for at komme ind i projektet. Vi kan distribuere et aktiv til brugere, som vil være i stand til at betale for transaktioner og står over for risikoen for deres misbrug, når der oprettes automatiserede systemer til at pumpe et likvidt aktiv ud fra vores system.

Det ville være meget praktisk, hvis det var muligt at kalde InvokeScript "på bekostning af modtageren" (den smarte konto, som scriptet er installeret på), og en sådan mulighed eksisterer, selvom det ikke er på en indlysende måde.

Hvis du inde i InvokeScript laver en ScriptTransfer til den, der ringer op, som kompenserer for de brugte gebyrtokens, så vil et sådant opkald være vellykket, selvom der på tidspunktet for opkaldet ikke var nogen aktiver på den kaldende konto. Dette er muligt, fordi kontrollen for tilstrækkelige tokens foretages efter, at transaktionen kaldes, snarere end før den, så transaktioner kan foretages på kredit med forbehold for øjeblikkelig tilbagebetaling.

ScriptTransfer(i.caller, i.fee, unit)

Koden nedenfor refunderer det brugte gebyr ved at bruge smartkontomidler. For at beskytte mod misbrug af denne funktion er det nødvendigt at bruge en kontrol af, at den, der ringer, bruger gebyret i det påkrævede aktiv og inden for rimelige grænser:

func checkFee(i:Invocation) = {
if i.fee > maxFee then throw(“unreasonable large fee”) else
if i.feeAssetId != unit then throw(“fee must be in WAVES”) else true
}

For at beskytte mod ondsindet og meningsløst spild af midler kræves automatisk opkaldsbeskyttelse (PoW-captcha).

PoW-captcha

Selve ideen med proof-of-work captcha er ikke ny og er allerede blevet implementeret i forskellige projekter, inklusive dem, der er implementeret på basis af WAVES. Tanken er, at for at udføre en handling, der tærer på vores projekts ressourcer, skal den, der ringer, også bruge sine egne ressourcer, hvilket gør et ressourceudtømningsangreb ret dyrt. For en meget nem og billig validering af, at afsenderen af ​​transaktionen har løst PoW-problemet, er der en transaktions-id-kontrol:

if take(toBase58String(i.transactionId), 3) != “123” then throw(“proof of work failed”) else

For at udføre en transaktion skal den, der ringer, vælge sådanne parametre, så dens base58-kode (id) begynder med tallene 123, hvilket i gennemsnit svarer til et par XNUMX-sekunders processortid og generelt er rimeligt for vores opgave. Hvis der kræves en enklere eller mere kompleks PoW, så kan opgaven nemt ændres på en indlysende måde.

Forespørgsel efter datanøgler ved hjælp af en skabelon

For at bruge blockchain som en database er det vigtigt at have API-værktøjer til at forespørge databasen som nøgleværdi baseret på skabeloner. Et sådant værktøjssæt dukkede op i begyndelsen af ​​juli 2019 i form af en parameter ?Tændstikker på REST API-anmodningen /adresser/data?matches=regexp. Hvis vi nu skal have mere end én nøgle fra en webapplikation og ikke alle nøgler på én gang, men kun en gruppe, så kan vi foretage et valg efter nøglenavn. For eksempel, i dette projekt er udbetalingstransaktioner kodet som

withdraw_${userAddress}_${txid}

som giver dig mulighed for at få en liste over transaktioner til tilbagetrækning af midler for enhver given adresse ved hjælp af skabelonen:

?matches=withdraw_${userAddress}_.*

Lad os nu se på komponenterne i den færdige løsning.

Vuejs kode

Koden er en fungerende demo tæt på det rigtige projekt. Det implementerer login gennem Waves Keeper og arbejder med affiliate.js-biblioteket, hvormed det registrerer brugeren i systemet, forespørger transaktionsdata og giver dig også mulighed for at hæve optjente penge til brugerens konto.

Kode til RIDE

Består af registrerings-, fond- og udbetalingsfunktioner.

Registerfunktionen registrerer en bruger på systemet. Den har to parametre: referer (referrer-adresse) og salt-parameteren, som ikke bruges i funktionskoden, som er nødvendig for at vælge transaktions-id (PoW-captcha-opgave).

Funktionen (som andre funktioner fra dette projekt) anvender debt call-teknikken, resultatet af funktionen er at finansiere betalingen af ​​et gebyr for at kalde denne funktion. Takket være denne løsning kan en bruger, der lige har oprettet en tegnebog, straks arbejde med systemet og behøver ikke at bekymre sig om at købe eller modtage et aktiv, der giver ham mulighed for at betale et transaktionsgebyr.

Resultatet af registreringsfunktionen er to poster:

${owner)_referer = referer
${referer}_referral_${owner} = owner

Dette tillader frem- og tilbagesøgninger (henviseren af ​​en given bruger og alle henvisninger fra en given bruger).

Fondsfunktionen er mere en skabelon til at udvikle reel funktionalitet. I sin præsenterede form tager den alle de midler, der er overført ved transaktionen og distribuerer dem til konti hos referenter på niveau 1, 2, 3, til "cashback"-kontoen og "ændrings"-kontoen (alt, der er tilbage, når de distribueres til tidligere regnskab kommer her).

Cashback er et middel til at motivere slutbrugeren til at deltage i henvisningssystemet. Brugeren kan hæve den del af provisionen, som systemet har betalt i form af "cashback" på samme måde som belønninger for henvisninger.

Når du bruger et henvisningssystem, bør fondsfunktionen modificeres og integreres i hovedlogikken på den smarte konto, som systemet vil fungere på. For eksempel, hvis der udbetales en henvisningsbelønning for et væddemål foretaget, så skal fondsfunktionen være indbygget i logikken, hvor væddemålet placeres (eller en anden målrettet handling udføres, som belønningen betales for). Tre niveauer af henvisningsbelønninger er kodet ind i denne funktion. Skal du lave flere eller færre niveauer, så er dette også rettet i koden. Belønningsprocenten er sat af niveau1-niveau3 konstanterne; i koden beregnes det som beløb * niveau / 1000, dvs. værdien 1 svarer til 0,1 % (dette kan også ændres i koden).

Kaldning af funktionen ændrer kontosaldoen og opretter også poster til logning af formularen:

fund_address_txid = address:owner:inc:level:timestamp
Для получения timestamp (текущего времени) используется такая вот связка
func getTimestamp() = {
let block = extract(blockInfoByHeight(height))
toString(block.timestamp)
}

Det vil sige, at transaktionstiden er tidspunktet for den blok, hvori den er placeret. Dette er mere pålideligt end at bruge tidsstemplet fra selve transaktionen, især da det ikke er tilgængeligt fra den kaldbare.
Udbetalingsfunktionen viser alle akkumulerede belønninger til brugerens konto. Opretter poster til logningsformål:

# withdraw log: withdraw_user_txid=amount:timestamp

App

Hoveddelen af ​​applikationen er affiliate.js-biblioteket, som er en bro mellem tilknyttede datamodeller og WAVES NODE REST API. Implementerer et abstraktionsniveau uafhængigt af rammen (hvilket som helst kan bruges). Aktive funktioner (registrering, tilbagetrækning) forudsætter, at Waves Keeper er installeret på systemet; biblioteket selv kontrollerer ikke dette.

Implementerer metoder:

fetchReferralTransactions
fetchWithdrawTransactions
fetchMyBalance
fetchReferrals
fetchReferer
withdraw
register

Funktionaliteten af ​​metoderne fremgår tydeligt af navnene; parametrene og returnerede data er beskrevet i koden. Registerfunktionen kræver yderligere kommentarer - den starter en cyklus med valg af transaktions-id, så den starter ved 123 - dette er PoW-captchaen beskrevet ovenfor, som beskytter mod masseregistreringer. Funktionen finder en transaktion med det nødvendige id og signerer den derefter gennem Waves Keeper.

DEX affiliate program er tilgængeligt på GitHub.com.

Kilde: www.habr.com