Nej, at lancere en decentraliseret applikation (dapp) på blockchain vil ikke føre til en succesfuld forretning. Faktisk tænker de fleste brugere slet ikke over, om applikationen kører på blockchain — de vælger bare det produkt, der er billigere, hurtigere og nemmere.

Desværre, selvom blockchain har sine unikke funktioner og fordele, er de fleste applikationer, der kører på den, meget dyrere, langsommere og mindre brugervenlige end deres centraliserede konkurrenter.

Ret ofte kan man i whitepapers for applikationer, der er bygget på blockchain, finde et afsnit, hvor det står: "blockchain er dyrt og kan ikke understøtte det nødvendige antal transaktioner pr. sekund. Heldigvis arbejder mange kloge mennesker på at skalere blockchain, og ved lanceringen af vores applikation vil den være tilstrækkeligt skalerbar."

I et enkelt afsnit kan udvikleren af dapp'en undgå en dybere diskussion om skaleringsproblemer og alternative løsninger. Dette fører ofte til en ineffektiv arkitektur, hvor smart contracts, der kører på blockchain, fungerer som backend og kerne af applikationen.

Der er dog stadig uafprøvede tilgange i arkitekturen af decentraliserede applikationer, der tillader langt bedre skalering ved at reducere afhængigheden af blockchain. For eksempel arbejder Blockstack på en arkitektur, hvor de fleste data og logik for applikationen opbevares uden for blockchain.

Lad os først se på en mere traditionel tilgang, hvor blockchain bruges som en direkte mellemmand mellem applikationsbrugere, og som ikke skalerer særlig godt.

Tilgang nr. 1: Blockchain som backend

For at gøre det mere klart, lad os tage hotelindustrien som eksempel. Det er en enorm industri, hvor mellemled som Booking.com, tager enorme gebyrer for at forbinde gæster og hoteller.

I enhver situation, hvor vi ønsker at overgå en sådan mellemmand ved at bruge denne tilgang, vil vi forsøge at gentage dens forretningslogik ved hjælp af smart contracts på en blockchain som Ethereum.

Smart contracts with open source code, launched on the "world computer," can connect sellers with consumers without a third party in between, ultimately reducing the fees and commissions charged by intermediaries.

As shown in the image below, hotels use a decentralized application to place information about rooms, their availability, and prices during weekdays or weekends on the blockchain, as well as descriptions of the rooms and any other relevant information.

Anyone wishing to book a room uses this application to search for hotels and rooms listed on the blockchain. Once the user selects a room, the booking is made by sending the required amount of tokens to the hotel as a deposit. In response, the smart contract updates the information on the blockchain, indicating that the room is no longer available.

This approach has two sides of the scalability issue. Firstly, the maximum number of transactions per second. Secondly, the amount of data that can be stored on the blockchain.

Let’s make some rough calculations. Booking.com claims to have nearly 2 million hotels registered. Suppose each hotel has an average of 10 rooms and each room is booked only 20 times a year — this gives us an average of 13 bookings per second.

To estimate this number, it is worth noting that Ethereum can handle about 15 transactions per second.

In addition, it should be considered that our application will also have transactions from hotels — for uploading and continuously updating information about their rooms. Hotels update room prices very frequently, sometimes even daily, and each change in price or description requires a transaction on the blockchain.

There are also size problems — the weight of the Ethereum blockchain recently exceeded 2TB. If applications with such an approach were to become truly popular, the Ethereum network would become extremely unstable.

Such a blockchain-based system can exclude outsiders due to its impartiality and lack of centralization — the main advantages of blockchain technology. But blockchain also has other features — it is distributed and immutable, which are excellent characteristics, but they come at the cost of transaction speed and fees.

Derfor skal udviklerne af dapp'er nøje vurdere, om distribution og uforanderlighed virkelig er nødvendige for hver funktion, der bruger blockchain.

For eksempel: Hvad er fordelene ved at fordele dataene fra hvert hotel på hundreder af maskiner rundt omkring i verden og konstant opbevare dem der? Er det virkelig vigtigt, at historiske data om priser og tilgængelighed af værelser altid er inkluderet i blockchain? Formodentlig ikke.

Hvis vi begynder at stille disse spørgsmål, vil vi begynde at se, at vi ikke nødvendigvis har brug for alle de dyre egenskaber ved blockchain til alle vores funktioner. Så hvad er alternativet?

Tilgang #2: Arkitektur inspireret af Blockstack

Selvom der er fokus på Blockstack i applikationer, hvor brugerne ejer deres egne data (såsom Airtext, BentenSound, ImageOptimizer eller Graphite), har Blockstack også en filosofi omkring begrænset brug af blockchain — kun når det er absolut nødvendigt. Deres hovedargument er, at blockchain er langsom og dyr, og derfor kun bør bruges til enkeltstående eller sjældne transaktioner. Alt andet interaktion med applikationer skal ske via peer-to-peer, dvs. brugerne af decentrale applikationer skal dele data direkte med hinanden i stedet for gennem blockchain. I sidste ende blev de ældste og mest succesfulde decentrale applikationer, som BitTorrent, email og Tor, skabt længe før konceptet om blockchain eksisterede.

Til venstre: den første tilgang, hvor brugerne interagerer gennem blockchain. Til højre: brugerne interagerer direkte med hinanden, og blockchain anvendes kun til identifikation og lignende.

Lad os vende tilbage til eksemplet med hotelreservationer. Vi vil have en upartisk, uafhængig og åben protokol til at forbinde gæster med hoteller. Med andre ord ønsker vi at fjerne den centraliserede mellemmand. Vi har ikke behov for f.eks. konstant at opbevare priser på værelser i en delt distribueret ledger.

Hvorfor skal vi ikke bare lade gæster og hoteller interagere direkte, i stedet for gennem blockchain? Hoteller kan gemme deres priser, tilgængelighed af værelser og enhver anden information hvor som helst, hvor de er tilgængelige for alle – for eksempel IPFS, Amazon S3, eller endda deres egen lokale server. Det er netop det, som det decentraliserede lagringssystem fra Blockstack kaldet Gaia. Det giver brugerne mulighed for at vælge, hvor de vil gemme deres data og kontrollere, hvem der kan få adgang til dem gennem en tilgang kaldet multibruger-lagring.

For at etablere tillid bliver alle hoteldatas kryptografisk underskrevet af selve hotellet. Uanset hvor disse data gemmes, kan deres integritet verificeres ved hjælp af de offentlige nøgler, der er knyttet til identitetsoplysningerne for dette hotel, som er gemt i blockchainen.

I tilfælde af Blockstack gemmes kun dine identitetsoplysninger i blockchainen. Oplysninger om, hvordan man får adgang til data for hver bruger, gemmes i zonefiler og distribueres gennem et peer-to-peer netværk via noder. Og igen – du skal ikke stole på de data, som noderne giver, fordi du kan kontrollere deres ægthed ved at sammenligne dem med de hashes, der er gemt i blockchainen og hos andre brugere.

I en forenklet version af systemet vil gæsterne bruge Blockstack peer-to-peer netværket til at finde hoteller og få oplysninger om deres værelser. Og ægtheden og integriteten af alle de data, du modtager, kan verificeres ved hjælp af offentlige nøgler og hashes, der er gemt i den virtuelle kæde Blockstack.

Denne arkitektur er mere kompleks end den første tilgang og kræver mere omfattende infrastruktur. Faktisk er det netop her, Blockstack kommer ind i billedet og leverer alle de nødvendige komponenter til at opbygge et sådant decentraliseret system.

Med en sådan arkitektur gemmer vi kun data i blockchainen, som virkelig skal være distribuerede og ikke-overskrivbare. I tilfælde af Blockstack har du kun brug for transaktioner i blockchainen for at registrere dig og angive, hvor dine data skal gemmes. Du kan få brug for flere transaktioner, hvis du ønsker at ændre noget af denne information, men det er ikke en gentagen begivenhed.

Desuden fungerer applikationens logik, i modsætning til den første tilgang, på klientsiden og ikke på smarte kontrakter. Dette giver udvikleren mulighed for at ændre denne logik uden dyre eller undertiden endda umulige opdateringer af den smarte kontrakt. Ved at holde data og applikationslogik uden for blokchainen kan decentrale applikationer opnå et niveau af ydeevne og skalerbarhed svarende til traditionelle centraliserede systemer.

Konklusion

Applikationer, der kører på Blockstack, kan skalere meget bedre end almindelige blockchain-applikationer, men det er en yngre tilgang med sine egne problemer og ubesvarede spørgsmål.

For eksempel, hvis en decentral applikation ikke kører på smarte kontrakter, reducerer det behovet for utility-tokens. Dette kan skabe problemer for virksomheder, da ICO'er var den primære finansieringskilde for decentrale applikationer (herunder selve Blockstack).

Der er også tekniske problemer her. For eksempel er det relativt enkelt at implementere en hotelbookingfunktion i en smart kontrakt, hvor en atomar operation booker værelser i bytte for tokens. Og det er ikke helt klart, hvordan bookingen vil fungere i en Blockstack-applikation uden smarte kontrakter.

Applikationer, der sigter mod globale markeder med potentiale for millioner af brugere, skal skalere meget godt for at blive succesfulde. Det ville være en fejl at stole udelukkende på blockchain for at opnå et sådant niveau af skalerbarhed i den nærmeste fremtid. For at kunne konkurrere med store centraliserede spillere på markedet, såsom Booking.com, må udviklere af decentrale applikationer overveje alternative tilgange til design af deres applikationer, som dem, Blockstack tilbyder.

Kilde: habr.com