@LiskLisk

We bieden ontwikkelaars een softwareontwikkelingskit voor blockchaintoepassingen die in JavaScript zijn geschreven.

In het Moosty-team leren we door te doen. Door proof of concepts te bouwen, leren we over blockchain-technologie en het creëren van netwerkdynamiek. We werken samen met communities (online & offline), kennisinstituten en organisaties en hebben een sterke band met de Lisk-community, de LCU-community & het lokale bedrijfsleven in Utrecht. Ga je mee op deze innovatiereis? Laten we samen een proof of concept bouwen.

Project introductie

Terugkerende betalingen is een proof of concept gemaakt met de Lisk-SDK. Het toont een relatief eenvoudige technische oplossing die gebruikmaakt van aangepaste transacties om een ​​deterministisch contract op te bouwen tussen twee partijen (peer-to-peer). Hiermee kunt u een contract afsluiten met iedereen die een account (wallet) in het systeem aanmaakt. De accounts, het contract, al zijn wijzigingen en alle activiteiten worden opgeslagen op de blockchain, die speciaal voor deze PoC is gemaakt.

Het project heeft een verworven Lisk-bouwers studiebeurs. Hierna gaan we dieper in op de proof of concept. 

Use Case “Subsidie ​​door overheidsorganisatie”

Huidige situatie

Een organisatie (A) vraagt ​​subsidie ​​aan bij de overheid (B). Deze wordt momenteel in één keer uitbetaald voor een periode van 1 jaar. De ontvangende partij moet gedurende deze periode aan bepaalde voorwaarden voldoen. Als de ontvanger aan het einde van het jaar niet aan de voorwaarden heeft voldaan, moet de subsidie ​​geheel of gedeeltelijk worden terugbetaald.

Waarom zou het anders moeten werken?

In de situatie dat partij A niet aan de voorwaarden heeft voldaan en de subsidie ​​geheel of gedeeltelijk moet worden terugbetaald, loop je tegen het probleem aan dat in de meeste gevallen het gehele bedrag al is uitgegeven. Dit zorgt ervoor dat de subsidieverstrekker (partij B) niet verzekerd is van het terug te vorderen bedrag en dat partij A in financiële problemen kan komen.

Hoe werkt de periodieke betaling?

Partij A stelt het contract op met de betalingsvoorwaarden, inclusief hoe vaak, wanneer en het bedrag. Partij B vult de kluis met tokens om aan de contractvoorwaarden te voldoen. Elke periode waarin partij A recht heeft op tokens uit het contract, kan partij A een transactie uitvoeren om de tokens voor die periode te ontvangen.

Indien partij B het contract voortijdig wil beëindigen, dient de vooraf bepaalde vergoeding betaald te worden aan partij A en ontvangt partij B de resterende tokens uit de kluis. Dit is te vergelijken met het voortijdig beëindigen van een contract.

toekomst

“In de toekomst kun je een contract sluiten tussen jezelf en je buurman die toevallig gitaarleraar is. Je sluit een contract af voor 1 jaar, waarbij je hem maandelijks een afgesproken bedrag betaalt. U stort dan een maand vooruitbetaling en als een van de partijen het contract beëindigt, wordt de laatste maand aan de leraar verstrekt. Eenmaal opgesteld is het contract onveranderlijk en ontstaat er een transparante, leesbare overeenkomst tussen de twee partijen.”

Een flexibele service-infrastructuur

Tegenwoordig gebruikt de tool alleen een handvol aangepaste transacties. Met deze zes aangepaste transacties hebben we het potentieel om een ​​krachtige blockchain-applicatie te bouwen die een flexibele contractoplossing tussen twee partijen creëert. Het geeft je de mogelijkheid om het volgende te creëren:

• Een maandelijks uitbetalingsmechanisme.
• Zorg voor een subsidie ​​waarbij het geld na 3 (of meer) maanden automatisch vrijkomt, tenzij iemand het contract opzegt.
• Een abonnement waarbij je het volledige bedrag vooraf betaalt (om korting te krijgen).
• Een servicecontract waarbij u 2 termijnen vooruit betaalt.
• Zet zakgeld opzij voor je kinderen.
• Plan maandelijkse donaties in tot een maximumbedrag.

Er ontstaat een veelheid aan mogelijkheden wanneer we de functionaliteit van deze transacties uitbreiden, of wanneer er nieuwe aangepaste transacties worden toegevoegd en we 10 of misschien wel 20 verschillende transacties integreren.

Bijvoorbeeld: Creëer een crowdfund met een (maximale) maandelijkse uitbetaling aan de crowdfunder. 

Laat ons weten als je nog betere ideeën hebt! 

Technische details

Deze sectie bevat een inleiding tot de technische details en geeft een overzicht van de verschillende gebruikte frameworks, de gemaakte aangepaste transacties en ten slotte onze ervaring met het werken met de Lisk SDK.

Onderdelen van de PoC

• Back-end: Werkende aangepaste transacties die op een blockchain kunnen draaien.
• Een uitgebreide HTTP API die de back- en frontend met elkaar verbindt.
• Front-end: een ReactJS front-end wallet om contracten te beheren (interactie met de transacties).

Aangepaste transacties

“Transacties zijn een essentieel onderdeel van blockchain-applicaties die zijn gemaakt met behulp van de Lisk SDK, omdat ze de reeks acties definiëren die door gebruikers in het netwerk kunnen worden uitgevoerd. Elke transactie hoort bij een specifiek transactietype dat in het netwerk is geregistreerd.”  Lisk SDK-documentatie.

Deze proof of concept maakt gebruik van zes verschillende aangepaste transacties. Verschillende transacties kan communiceren met contractportefeuilles zoals hieronder vermeld:

• Creëren - het contract maken.
• Beoordelen/accepteren – bekijk en valideer het contract.
• Fondscontract – stortingstokens in het contract.
• Opnemen – ontvang tokens van het contract. 
• Beëindigen – Voortijdige beëindiging van het contract. 
• Kraantransactie – voorziet de portemonnee van tokens en gebruikersnaamregistratie.

Opmerking: in deze proof of concept werken transacties met eenheden van minuten om contracten sneller te simuleren.

Zie de  Open Lisk Transactietype Registratierepository voor een lijst met alle geregistreerde Lisk-transactietypes. Iedereen kan een pull request doen om nieuwe registraties toe te voegen of bestaande registraties bij te werken, en ook de geregistreerde aangepaste transacties hergebruiken om snel je eigen blockchain-app op te zetten.

Contract

Een contract wordt gemaakt met verschillende regels die moeten worden nageleefd, zoals hieronder weergegeven:

• Eenheid: tijdseenheid [dagelijks, wekelijks, maandelijks, jaarlijks].
• Eenheidsprijs: hoeveel tokens kan elke eenheid uit de kluis halen.
• Prepaid units: hoeveel units * prijs moeten in de kluis liggen.
• Start: wanneer het contract ingaat.
• Totaal aantal eenheden: hoeveel eenheden bevat het contract.
• Beëindigingsvergoeding: hoeveel vergoeding wordt betaald bij voortijdige beëindiging van het contract.
• Ontvanger: op welk adres kan elke eenheid tijdfiches uit de kluis halen (partij A).
• Contractant: welk adres mag de kluis invullen (kavel B).
• Omschrijving: omschrijving contract.
• Naam: naam van het contract. 

Hoe werkt het?

Een contract kan worden gesloten door de toekomstige afzender of de ontvanger van een contract. Dit contract kan door de andere partij worden goedgekeurd of gewijzigd via de validatietransactie.

Als het contract wordt gewijzigd, moet de eerste partij deze wijziging goedkeuren of afwijzen. Dit proces kan worden herhaald totdat beide partijen het eens zijn. Een kluis kan door de afzender (partij B) worden gevuld met een aangepaste fondstransactie die volledige betalingsbedragen gebruikt en het contract activeert.

De ontvangende partij (A) kan met een transactie tokens uit de kluis halen als het contract dat op dat moment toestaat. Als niet aan de prepaidvoorwaarden wordt voldaan, wordt het contract niet geactiveerd.

Beide partijen kunnen het contract voortijdig beëindigen met een beëindigingstransactie waarbij het resterende bedrag na aftrek van de korte vergoeding wordt teruggegeven aan partij (B) en vervolgens de korte vergoeding wordt betaald aan partij A.

SDK4.0

Deze PoC maakt gebruik van de Lisk SDK 4.0. Dit levert Dynamic Fees en Chain State op. De chain state store wordt gebruikt om het tijdstip van de transactie te bepalen en kan aan de hand van de contractstatus bepalen hoeveel tokens ontgrendelbaar zijn. In deze versie van de SDK wordt het tijdstempel verwijderd uit de basistransactie en wordt een nonce ingevoerd.

Vanwege het incrementele karakter van de nonce, haalt de front-end de account nonce elke keer op uit de blockchain, net voordat een transactie wordt ondertekend. 

// slotTypes = [minutes, hours, days, months] in seconds
export const getPastSlots = ( start, now, type, length, unit
) => { const slot = slotTypes[type] * length; return Math.floor((now - start) / slot) - unit;
}
const unitsAvailable = getPastSlots( contract.asset.start, store.chain.lastBlockHeader.timestamp, contract.asset.unit.type, contract.asset.unit.typeAmount, contract.asset.payments
);

Dynamic Fees-oplossing

Dynamische vergoedingen werken als een tierelier. Vanwege ontbrekende documentatie (omdat we v4 te vroeg begonnen te gebruiken), kostte het wat tijd om uit te zoeken hoe we deze moesten berekenen. We hebben het op de volgende manier opgelost, zoals hieronder beschreven:

const tx = new FundContractTransaction({ nonce: nonce.toString(), senderPublicKey: publicKey, asset: { ...data }
}); tx.fee = (tx.minFee + BigInt(65000)).toString();
tx.sign(config.networkIdentifier, passphrase);

bigint

Voor de front-end hadden we een probleem met BigInt (kwestie), omdat BigInt een bufferbibliotheek voor js in de browser gebruikt die de integratie van

`buffer.readBigUint64BE()`

. Deze functie wordt gebruikt in de Lisk SDK en is nodig voor het ondertekenen van transacties.

Het pull-verzoek voor deze functie zit in de pijplijn, maar is op het moment van schrijven nog niet geaccepteerd. We hebben het opgelost door de bufferrepository te splitsen en samen te voegen met het pull-verzoek om het voor nu te laten werken.

HTTP API

De standaard Lisk HTTP API is uitgebreid met een extra API-module om het zoeken op gedeeltelijke gebruikersnamen, contractspecifieke activavelden en transactiespecifieke activavelden mogelijk te maken.

Elk contract heeft bijvoorbeeld transacties die bij zichzelf horen, maar de rekening is nooit de afzender van transacties.

Om alle transacties die bij een contract horen te verzamelen, zal de API de transacties van de transactie-entiteit ontvangen door een toe te voegen

`asset_contains`

filter naar de entiteit Transactie. Hierdoor is het mogelijk om verder te zoeken

`.asset.contractPublicKey`

===

`contract.publicKey`

. 

Front-end

Het maken van aangepaste transacties in de back-end is relatief eenvoudig als je het onder de knie begint te krijgen. Het meest tijdrovende element is de front-end, afhankelijk van de UI-vereisten, en het met elkaar verbinden van de twee. Het verzamelen van data uit de blockchain kan verder worden geoptimaliseerd, maar valt buiten de scope van deze proof of concept. 

De undoAsset()-methode 

Bovendien, de

UndoAsset()

methode in een aangepaste transactie kan moeilijk te maken zijn met statische nominale gegevens. We kijken uit naar de nieuwe oplossing om aangepaste transacties te maken zonder de UndoAsset()-methode, die al is gepland in een latere versie van de SDK. Als u dit oplost, zorgt u ervoor dat de beoordelingstransactie veel minder gegevens verzendt en dus minder netwerkbronnen gebruikt, wat op zijn beurt resulteert in lagere dynamische kosten.

Resources

Als je je geïnspireerd voelt en je eigen proof of concept blockchain-applicatie wilt bouwen, bekijk dan het Lisk Builders-programma. Meer informatie over het programma en de aanmeldingsprocedure is te vinden op de Lisk-webpagina voor de Lisk Builders-programma.

Disclaimer: dit blogbericht is geschreven door ons communitylid, Jurre (Lisk.chat gebruikersnaam: Jurre | Moosty) als onderdeel van zijn deelname aan het Lisk Builders-programma.

Coinsmart. Beste Bitcoin-beurs in Europa
Bron: https://hackernoon.com/what-is-the-recurring-payments-poc-and-how-does-it-work-6ql323i?source=rss