Frontend plokiahela olekukanalid: ahelaväline tehingute töötlemine skaleeruvate dAppide jaoks

Plokiahela tehnoloogia, kuigi revolutsiooniline, seisab silmitsi oluliste skaleeruvuse väljakutsetega. Iga tehingu töötlemine ahelas võib põhjustada kõrgeid tehingutasusid (gaasitasud), aeglaseid kinnitusaegu ja võrgu ülekoormust. See mõjutab negatiivselt detsentraliseeritud rakenduste (dAppide) kasutajakogemust (UX), takistades laiemat kasutuselevõttu. Üks paljutõotav lahendus nendele väljakutsetele on olekukanalite kasutamine. See artikkel süveneb frontend plokiahela olekukanalitesse, uurides nende funktsionaalsust, eeliseid, väljakutseid ja praktilisi rakendusi. Keskendume sellele, kuidas need kanalid võimaldavad ahelavälist tehingute töötlemist, et luua kiiremaid, odavamaid ja skaleeruvamaid dAppe.

Mis on olekukanalid?

Oma olemuselt on olekukanalid Layer 2 skaleerimislahendus, mis võimaldab osalejatel teha mitmeid tehinguid peamisest plokiahelast väljaspool. Mõelge sellele kui otsese, privaatse suhtlusliini avamisele kahe või enama osapoole vahel, kes soovivad sageli tehinguid teha. Ainult kanali avamine ja sulgemine nõuavad ahelasiseseid tehinguid, vähendades oluliselt koormust peamisele plokiahelale.

Siin on lihtsustatud analoogia: kujutage ette, et mängite sõbraga panustega mängu. Selle asemel, et iga üksikut panust avalikku pearaamatusse (plokiahelasse) kirja panna, nõustute te omavahel skoori ja panuste summasid eraldi paberilehel (olekukanal) jälgima. Alles siis, kui olete mängimise lõpetanud, salvestate lõpptulemuse avalikku pearaamatusse.

Kuidas olekukanalid töötavad

Üldine protsess hõlmab järgmisi samme:

1. Kanali lähtestamine: Osalejad deponeerivad vahendid mitme allkirjaga nutilepingusse peamises plokiahelas. See leping toimib olekukanali alusena.
2. Ahelavälised tehingud: Osalejad vahetavad allkirjastatud sõnumeid, mis esindavad tehinguid kanalis. Need tehingud uuendavad kanali olekut (nt saldod, mängu seis). Oluline on, et neid tehinguid *ei* edastata plokiahelasse.
3. Oleku uuendused: Iga ahelaväline tehing esindab uut pakutud olekut. Osalejad allkirjastavad need olekuuuendused digitaalselt, pakkudes krüptograafilist tõendit kokkuleppest. Kõige uuemat, kokkulepitud olekut peetakse kanali kehtivaks olekuks.
4. Kanali sulgemine: Kui osalejad on tehingute tegemise lõpetanud, esitab üks osapool lõpliku oleku (kõigi osalejate poolt allkirjastatud) nutilepingule. Nutileping kontrollib allkirju ja jaotab vahendid vastavalt lõplikule olekule.

Miks frontend olekukanalid?

Traditsiooniliselt nõuavad olekukanalite implementatsioonid märkimisväärset backend-infrastruktuuri. Frontend olekukanalite eesmärk on protsessi lihtsustada, viies suure osa kanali haldusloogikast kliendi poolele (brauserisse või mobiilirakendusse). See pakub mitmeid eeliseid:

• Vähendatud serveripoolne infrastruktuur: Väiksem sõltuvus tsentraliseeritud serveritest vähendab tegevuskulusid ja parandab detsentraliseerimist.
• Parem kasutajakogemus: Kiiremad tehingukiirused ja madalamad tasud loovad reageerivama ja nauditavama kasutajakogemuse.
• Täiustatud privaatsus: Tehingud toimuvad otse kasutajate seadmete vahel, minimeerides tehinguandmete kokkupuudet kolmandate osapooltega.
• Lihtsustatud arendus: Frontend-teegid ja raamistikud võivad abstraheerida suure osa olekukanalite haldamisega seotud keerukusest, muutes arendajatele olekukanalite integreerimise oma dAppidesse lihtsamaks.

Frontend olekukanali implementatsiooni põhikomponendid

Tüüpiline frontend olekukanali implementatsioon hõlmab järgmisi komponente:

• Nutileping: Mitme allkirjaga nutileping, mis on kasutusele võetud plokiahelas. See leping haldab esialgset deposiiti, vahendite väljavõtmist ja vaidluste lahendamist. See määratleb olekukanali reeglid ja tagab, et kõik osalejad järgivad neid.
• Frontend-teek/SDK: JavaScripti teek või SDK, mis pakub API-sid olekukanali haldamiseks frontendist. See teek tegeleb ülesannetega nagu allkirjade genereerimine, sõnumite saatmine ja nutilepinguga suhtlemine. Näideteks on teegid, mis on ehitatud Ethers.js või Web3.js ümber, kuid optimeeritud olekukanalite spetsiifilisteks operatsioonideks.
• Kommunikatsioonikiht: Mehhanism osalejatele omavaheliseks ahelaväliseks suhtlemiseks. See võib olla peer-to-peer (P2P) võrk, tsentraliseeritud sõnumiteenus või nende kombinatsioon. Kommunikatsioonikiht vastutab allkirjastatud olekuuuenduste turvalise edastamise eest osalejate vahel. Näideteks on WebSockets, libp2p või isegi kohandatud sõnumiprotokoll.
• Olekuhaldus: Loogika kanali oleku haldamiseks kliendi poolel. See hõlmab saldode, mänguseisu ja muu asjakohase teabe jälgimist. Tõhus olekuhaldus on andmete järjepidevuse tagamiseks ja konfliktide vältimiseks ülioluline.

Frontend olekukanalite kasutamise eelised

Frontend olekukanalid pakuvad dAppide arendajatele ja kasutajatele mitmeid eeliseid:

Täiustatud skaleeruvus

Töödeldes enamikku tehinguid ahelaväliselt, vähendavad olekukanalid oluliselt koormust peamisele plokiahelale, võimaldades suuremat tehingute läbilaskevõimet ja paremat skaleeruvust. See on eriti oluline dAppide jaoks, mis nõuavad sagedasi interaktsioone, nagu võrgumängud, mikromaksete platvormid ja sotsiaalmeedia rakendused.

Vähendatud tehingutasud

Ahelavälistel tehingutel on oluliselt madalamad tasud võrreldes ahelasiseste tehingutega. See muudab olekukanalid ideaalseks mikromaksete ja muude kasutusjuhtude jaoks, kus kõrged tehingutasud oleksid takistuseks. Kujutage ette voogedastusteenust, mis võimaldab kasutajatel maksta vaatamisminuti eest – olekukanalid võimaldavad neid mikrotehinguid ilma suurte gaasikulude koormata.

Kiiremad tehingukiirused

Ahelavälised tehingud töödeldakse peaaegu hetkega, pakkudes palju kiiremat kasutajakogemust võrreldes plokikinnituste ootamisega peamises plokiahelas. See on hädavajalik rakenduste jaoks, mis nõuavad reaalajas interaktsioone, nagu võrgumängud ja kauplemisplatvormid. Mõelge detsentraliseeritud börsile (DEX), kus kauplejad peavad turu kõikumistele kiiresti reageerima; olekukanalid võimaldavad peaaegu hetkelist orderite täitmist.

Parem kasutajakogemus

Kiiremate tehingukiiruste ja madalamate tasude kombinatsioon toob kaasa oluliselt parema kasutajakogemuse dAppide kasutajatele. See võib viia suurema kasutajate kaasamise ja detsentraliseeritud rakenduste kasutuselevõtuni. Eemaldades ahelasiseste tehingutega seotud hõõrdumise, muudavad olekukanalid dAppid tundlikumaks ja intuitiivsemaks.

Suurenenud privaatsus

Kuigi mitte olemuselt privaatsed, võivad olekukanalid pakkuda suuremat privaatsust võrreldes ahelasiseste tehingutega, kuna avalikku plokiahelasse salvestatakse ainult kanali avamise ja sulgemise tehingud. Kanalisisesete üksikute tehingute üksikasjad jäävad osalejate vahel privaatseks. See võib olla kasulik kasutajatele, kes soovivad hoida oma tehingute ajalugu konfidentsiaalsena.

Frontend olekukanalite implementeerimise väljakutsed

Kuigi frontend olekukanalid pakuvad mitmeid eeliseid, on ka mõningaid väljakutseid, mida tuleb arvesse võtta:

Keerukus

Olekukanalite implementeerimine võib olla keeruline, nõudes sügavaid teadmisi krüptograafiast, nutilepingutest ja võrgundusest. Arendajad peavad hoolikalt kavandama ja implementeerima kanali loogika, et tagada turvalisus ja vältida haavatavusi. Kaasatud krüptograafilisi primitiive, nagu digitaalallkirjad ja hashlock'id, võib olla raske mõista ja õigesti implementeerida.

Turvariskid

Olekukanalid on haavatavad mitmesugustele turvariskidele, nagu topeltkulutamise rünnakud, kordusrünnakud ja teenusetõkestamise rünnakud. Nende riskide leevendamiseks on ülioluline rakendada tugevaid turvameetmeid. Näiteks peavad osalejad hoolikalt valideerima kõik olekuuuendused ja veenduma, et need on korralikult allkirjastatud. Lisaks on nutilepingus vaidluste lahendamise mehhanismide korrektne implementeerimine elutähtis pahatahtlike osalejate eest kaitsmiseks.

Kasutatavus

Olekukanalite kasutajasõbralikuks muutmine võib olla keeruline. Kasutajad peavad mõistma olekukanalite põhimõisteid ja nendega suhtlemist. Kasutajaliides peaks olema intuitiivne ja lihtne kasutada. Rahakotid nagu MetaMask ei toeta loomupäraselt keerulisi olekukanalite operatsioone, seega on sageli vaja kohandatud kasutajaliidese komponente ja kasutajate harimist.

Võrgu latentsus

Olekukanalite jõudlust võib mõjutada võrgu latentsus osalejate vahel. Kõrge latentsus võib põhjustada viivitusi tehingute töötlemisel ja halvendada kasutajakogemust. Õige kommunikatsiooniprotokolli ja infrastruktuuri valimine on latentsuse minimeerimiseks ja reageerimisvõime tagamiseks ülioluline.

Sõltuvus usaldusväärsest kommunikatsioonikanalist

Olekukanalid tuginevad osalejate vahelisele usaldusväärsele kommunikatsioonikanalile. Kui kommunikatsioonikanal katkeb, ei saa tehinguid töödelda. Seetõttu on oluline valida tugev ja vastupidav kommunikatsioonimehhanism, mis mõnikord hõlmab üleliigseid teid sõnumite edastamiseks.

Frontend olekukanalite kasutusjuhud

Frontend olekukanaleid saab kasutada mitmesugustes rakendustes, sealhulgas:

• Mikromaksete platvormid: Võimaldavad kiireid ja odavaid mikromakseid sisuloojatele, veebiteenustele ja muudele kasutusjuhtudele. Kujutage ette, et annate striimerile jootraha sentide murdosa iga vaatamise eest – olekukanalid muudavad selle majanduslikult teostatavaks.
• Võrgumängud: Hõlbustavad reaalajas interaktsioone ja mängusiseseid tehinguid detsentraliseeritud võrgumängudes. Mängijad saavad kaubelda esemetega, teha panuseid ja osaleda turniiridel ilma kõrgete tehingutasudeta.
• Detsentraliseeritud börsid (DEXid): Parandavad detsentraliseeritud börside kiirust ja tõhusust, võimaldades ahelavälist orderite sobitamist ja täitmist. Kauplejad saavad ordereid täita palju kiiremini ja odavamalt võrreldes ahelasisese kauplemisega.
• Sotsiaalmeedia platvormid: Võimaldavad mikrojootrahasid, sisu monetiseerimist ja muid sotsiaalseid interaktsioone detsentraliseeritud sotsiaalmeedia platvormidel. Kasutajad saavad premeerida loojaid nende sisu eest ilma kõrgete tehingutasude koormata.
• IoT (asjade interneti) seadmed: Võimaldavad masinatevahelisi makseid ja andmevahetust IoT-võrkudes. Seadmed saavad automaatselt maksta teenuste eest, vahetada andmeid ja osaleda detsentraliseeritud turgudel. Näiteks elektriautod saaksid olekukanalite abil laadimisjaamas laadimise eest automaatselt maksta.

Olekukanalite implementatsioonide ja projektide näited

Mitmed projektid arendavad ja implementeerivad aktiivselt olekukanalite tehnoloogiaid. Siin on mõned märkimisväärsed näited:

• Raiden Network (Ethereum): Projekt, mis keskendub skaleeruva maksekanalite võrgu ehitamisele Ethereumi jaoks. Raideni eesmärk on võimaldada kiireid ja odavaid tokenite ülekandeid kogu Ethereumi ökosüsteemis. See on üks varasemaid ja tuntumaid olekukanalite projekte.
• Celer Network: Layer-2 skaleerimisplatvorm, mis toetab olekukanaleid ja muid skaleerimistehnoloogiaid. Celer Networki eesmärk on pakkuda ühtset platvormi skaleeruvate dAppide ehitamiseks. Nad toetavad mitmeid plokiahelaid ja pakuvad arendajatele tööriistade ja teenuste komplekti.
• Connext Network: Modulaarne, mitte-halduslik koostalitlusvõime protokoll, mis võimaldab kiireid ja turvalisi väärtusülekandeid erinevate plokiahelate vahel. Nad kasutavad olekukanaleid ja muid tehnoloogiaid ahelatevaheliste tehingute võimaldamiseks.
• Counterfactual: Raamistik olekukanalite rakenduste ehitamiseks. Counterfactual pakub tööriistade ja teekide komplekti, mis lihtsustavad olekukanalite rakenduste arendamist. Nad keskenduvad üldise olekukanalite infrastruktuuri ehitamisele, mida saab kasutada mitmesuguste kasutusjuhtude jaoks.

Tehniline süvaanalüüs: lihtsa frontend olekukanali implementeerimine

Kirjeldame lihtsustatud näidet, et illustreerida frontend olekukanali implementeerimise põhimõisteid. See näide kasutab JavaScripti, Ethers.js-i (Ethereumi plokiahelaga suhtlemiseks) ja lihtsat WebSocket-serverit ahelaväliseks kommunikatsiooniks.

Lahtiütlus: See on lihtsustatud näide illustratiivsetel eesmärkidel. Tootmisvalmis implementatsioon nõuaks robustsemaid turvameetmeid ja veakäsitlust.

1. Nutileping (Solidity)

See lihtne nutileping võimaldab kahel osapoolel raha deponeerida ja selle allkirjastatud oleku alusel välja võtta.

            
pragma solidity ^0.8.0;

contract SimpleStateChannel {
    address payable public participant1;
    address payable public participant2;
    uint public depositAmount;
    bool public isOpen = false;

    mapping(address => uint) public balances;

    constructor(address payable _participant1, address payable _participant2, uint _depositAmount) payable {
        require(msg.value == _depositAmount * 2, "Initial deposit must be twice the deposit amount");
        participant1 = _participant1;
        participant2 = _participant2;
        depositAmount = _depositAmount;
        balances[participant1] = _depositAmount;
        balances[participant2] = _depositAmount;
        isOpen = true;
    }

    function closeChannel(uint participant1Balance, uint participant2Balance, bytes memory signature1, bytes memory signature2) public {
        require(isOpen, "Channel is not open");

        // Hash the state data
        bytes32 hash = keccak256(abi.encode(participant1Balance, participant2Balance));

        // Verify signatures
        address signer1 = recoverSigner(hash, signature1);
        address signer2 = recoverSigner(hash, signature2);

        require(signer1 == participant1, "Invalid signature from participant 1");
        require(signer2 == participant2, "Invalid signature from participant 2");

        require(participant1Balance + participant2Balance == depositAmount * 2, "Balances must sum to total deposit");

        // Transfer funds
        participant1.transfer(participant1Balance);
        participant2.transfer(participant2Balance);

        isOpen = false;
    }

    function recoverSigner(bytes32 hash, bytes memory signature) internal pure returns (address) {
        bytes32 r;
        bytes32 s;
        uint8 v;

        // EIP-2098 signature
        if (signature.length == 64) {
            r = bytes32(signature[0:32]);
            s = bytes32(signature[32:64]);
            v = 27; // Assuming Ethereum mainnet/testnets

        // Standard signature recovery
        } else if (signature.length == 65) {
            r = bytes32(signature[0:32]);
            s = bytes32(signature[32:64]);
            v = uint8(signature[64]);
        } else {
            revert("Invalid signature length");
        }

        return ecrecover(hash, v, r, s);
    }
}

            

              
                Copy
              
            
          

2. Frontend (JavaScript koos Ethers.js-iga)

            
// Assume you have initialized ethersProvider and signer
// and have the contract address and ABI

const contractAddress = "YOUR_CONTRACT_ADDRESS";
const contractABI = [...]; // Your contract ABI

const contract = new ethers.Contract(contractAddress, contractABI, signer);

async function openChannel(participant1, participant2, depositAmount) {
    const tx = await contract.constructor(participant1, participant2, depositAmount, { value: depositAmount * 2 });
    await tx.wait();
    console.log("Channel opened!");
}

async function closeChannel(participant1Balance, participant2Balance) {
    // Hash the state data
    const hash = ethers.utils.keccak256(ethers.utils.defaultAbiCoder.encode(["uint", "uint"], [participant1Balance, participant2Balance]));

    // Sign the hash
    const signature1 = await signer.signMessage(ethers.utils.arrayify(hash));
    const signature2 = await otherSigner.signMessage(ethers.utils.arrayify(hash)); // Assuming you have access to the other signer

    // Call the closeChannel function on the smart contract
    const tx = await contract.closeChannel(participant1Balance, participant2Balance, signature1, signature2);
    await tx.wait();
    console.log("Channel closed!");
}

            

              
                Copy
              
            
          

3. Ahelaväline kommunikatsioon (WebSocket - lihtsustatud)

See on väga lihtne illustratsioon. Reaalses rakenduses vajaksite robustsemat ja turvalisemat kommunikatsiooniprotokolli.

            
// Client-side (Participant A)
const socket = new WebSocket("ws://localhost:8080");

socket.onopen = () => {
 console.log("Connected to WebSocket server");
};

socket.onmessage = (event) => {
 const message = JSON.parse(event.data);
 if (message.type === "stateUpdate") {
 // Verify the state update (signatures, etc.)
 // Update local state
 console.log("Received state update:", message.data);
 }
};

function sendStateUpdate(newState) {
 socket.send(JSON.stringify({ type: "stateUpdate", data: newState }));
}

            

              
                Copy
              
            
          

            
// Simple Server-side (Node.js)
const WebSocket = require('ws');

const wss = new WebSocket.Server({ port: 8080 });

wss.on('connection', ws => {
 console.log('Client connected');

 ws.onmessage = message => {
 console.log(`Received message: ${message.data}`);
 wss.clients.forEach(client => {
 if (client !== ws && client.readyState === WebSocket.OPEN) {
 client.send(message.data.toString()); // Broadcast to other clients
 }
 });
 };

 ws.on('close', () => {
 console.log('Client disconnected');
 });
});

console.log('WebSocket server started on port 8080');

            

              
                Copy
              
            
          

Selgitus:

1. Nutileping: `SimpleStateChannel` leping haldab esialgset deposiiti, hoiab saldosid ja kontrollib allkirju enne vahendite väljavõtmise lubamist. `closeChannel` funktsioon on ülioluline, kuna see kontrollib, et mõlema osapoole esitatud allkirjad on lõpliku oleku (saldode) jaoks kehtivad, enne kui vahendid vabastatakse.
2. Frontend: JavaScripti kood kasutab nutilepinguga suhtlemiseks Ethers.js-i. See sisaldab funktsioone kanali avamiseks ja sulgemiseks. `closeChannel` funktsioon allkirjastab lõpliku oleku (saldod) kasutaja privaatvõtmega ja esitab allkirjad nutilepingule.
3. Ahelaväline kommunikatsioon: WebSocket-server pakub lihtsat kommunikatsioonikanalit osalejatele olekuuuenduste vahetamiseks. Reaalses olukorras kasutaksite tõenäoliselt keerukamat kommunikatsiooniprotokolli sisseehitatud turvafunktsioonidega.

Töövoog:

1. Osalejad võtavad nutilepingu kasutusele ja deponeerivad vahendid.
2. Nad ühenduvad WebSocket-serveriga.
3. Nad vahetavad allkirjastatud olekuuuendusi (nt saldomuudatusi) WebSocket-serveri kaudu.
4. Kui nad on lõpetanud, kutsuvad nad nutilepingus välja `closeChannel` funktsiooni koos lõplike saldode ja allkirjadega.

Frontend olekukanalite turvakaalutlused

Turvalisus on olekukanalite implementeerimisel esmatähtis. Siin on mõned peamised turvakaalutlused:

• Allkirjade kontrollimine: Kontrollige alati hoolikalt olekuuuenduste allkirju enne nende aktsepteerimist. Kasutage tugevat allkirjateeki ja veenduge, et allkiri on genereeritud õige privaatvõtmega. Nutileping *peab* kontrollima allkirju enne vahendite vabastamist.
• Nonce'ide haldamine: Kasutage nonce'e (unikaalseid identifikaatoreid) kordusrünnakute vältimiseks. Iga olekuuuendus peaks sisaldama unikaalset nonce'i, mida iga tehinguga suurendatakse. Veenduge, et nutileping ja frontend-loogika jõustaksid korrektse nonce'ide kasutamise.
• Oleku valideerimine: Valideerige põhjalikult kõik olekuuuendused, et tagada nende vastavus kanali reeglitele. Näiteks veenduge, et maksekanali saldod ei ületaks kogu deposiidi summat.
• Vaidluste lahendamine: Implementeerige nutilepingusse tugev vaidluste lahendamise mehhanism. See mehhanism peaks võimaldama osalejatel vaidlustada kehtetuid olekuuuendusi ja lahendada vaidlusi õiglaselt. Nutilepingus peaks olema ajapiirang, mille jooksul saab vaidlustuse esitada.
• DoS-kaitse: Rakendage meetmeid teenusetõkestamise (DoS) rünnakute vastu kaitsmiseks. Näiteks piirake teatud aja jooksul esitatavate olekuuuenduste arvu.
• Turvaline võtmehaldus: Hoidke ja hallake turvaliselt privaatvõtmeid, mida kasutatakse olekuuuenduste allkirjastamiseks. Kasutage riistvaralisi rahakotte või muid turvalisi võtmete hoidmise lahendusi. Ärge kunagi hoidke privaatvõtmeid lihttekstina.
• Auditeerimine: Laske oma kood auditeerida mainekal turvafirmal, et tuvastada ja lahendada potentsiaalseid haavatavusi.

Frontend olekukanalite tulevik

Frontend olekukanalid esindavad olulist sammu edasi plokiahela skaleeruvuses ja kasutatavuses. Kuna dAppid muutuvad keerukamaks ja nõudlikumaks, suureneb vajadus tõhusa ahelavälise tehingute töötlemise järele. Võime oodata edasisi edusamme olekukanalite tehnoloogias, sealhulgas:

• Parem tööriistade valik: Arendajasõbralikumad teegid ja raamistikud muudavad olekukanalite rakenduste ehitamise ja kasutuselevõtu lihtsamaks.
• Standardiseerimine: Standardiseeritud protokollid olekukanalite kommunikatsiooniks ja andmevorminguteks parandavad erinevate implementatsioonide koostalitlusvõimet.
• Integratsioon olemasolevate rahakottidega: Sujuv integratsioon populaarsete rahakottidega muudab kasutajatele olekukanalites osalemise lihtsamaks.
• Tugi keerukamatele olekusiiretele: Olekukanalid suudavad toetada keerukamaid olekusiirdeid, võimaldades laiemat rakenduste valikut. Näiteks tugi mitme osapoolega kanalitele keerukama mänguloogikaga.
• Hübriidsed lähenemised: Olekukanalite kombineerimine teiste Layer-2 skaleerimislahendustega, nagu rollup'id, et saavutada veelgi suurem skaleeruvus.

Kokkuvõte

Frontend plokiahela olekukanalid pakuvad võimsat lahendust dAppide skaleerimiseks ja kasutajakogemuse parandamiseks. Võimaldades kiireid, odavaid ja privaatseid ahelaväliseid tehinguid, avavad olekukanalid uusi võimalusi detsentraliseeritud rakenduste jaoks. Kuigi ületamist vajavaid väljakutseid on, on olekukanalite eelised vaieldamatud ja nad on valmis mängima olulist rolli plokiahela tehnoloogia tulevikus. Tehnoloogia küpsedes ja rohkemate arendajate poolt olekukanalite kasutuselevõtuga võime oodata uue põlvkonna skaleeruvaid ja kasutajasõbralikke dAppe, mis suudavad jõuda laiema publikuni.