ప్రధాన కంటెంట్‌కు దాటవేయి

గ్యాస్ ఫీజులను స్పాన్సర్ చేయడం: మీ వినియోగదారుల కోసం లావాదేవీ ఖర్చులను ఎలా భరించాలి

గ్యాస్‌లెస్
Solidity
eip-712
మెటా-లావాదేవీలు
మధ్యస్థ స్థాయి
ఓరి పోమెరాంట్జ్
27 ఫిబ్రవరి, 2026
9 నిమిషాల పఠనం

పరిచయం

ఎథీరియం మరో బిలియన్ మందికి (కొత్త ట్యాబ్‌లో తెరవబడుతుంది) సేవలు అందించాలని మనం కోరుకుంటే, మనం అడ్డంకులను తొలగించి, దానిని వీలైనంత సులభంగా ఉపయోగించేలా చేయాలి. గ్యాస్ ఫీజులు చెల్లించడానికి ETH అవసరం కావడం ఈ అడ్డంకులలో ఒకటి.

వినియోగదారుల నుండి డబ్బు సంపాదించే వికేంద్రీకృత అప్లికేషన్ (dapp) మీకు ఉంటే, వినియోగదారులు మీ సర్వర్ ద్వారా లావాదేవీలను సమర్పించడానికి అనుమతించడం మరియు లావాదేవీ ఫీజులను మీరే చెల్లించడం సమంజసంగా ఉండవచ్చు. వినియోగదారులు ఇప్పటికీ తమ వాలెట్‌లలో EIP-712 అధికార సందేశం (కొత్త ట్యాబ్‌లో తెరవబడుతుంది)పై సంతకం చేస్తారు కాబట్టి, వారు ఎథీరియం యొక్క సమగ్రత హామీలను నిలుపుకుంటారు. లభ్యత అనేది లావాదేవీలను రిలే చేసే సర్వర్‌పై ఆధారపడి ఉంటుంది, కాబట్టి ఇది మరింత పరిమితంగా ఉంటుంది. అయినప్పటికీ, వినియోగదారులు స్మార్ట్ కాంట్రాక్ట్‌ను నేరుగా యాక్సెస్ చేసేలా (వారు ETH పొందితే) మీరు సెటప్ చేయవచ్చు మరియు ఇతరులు లావాదేవీలను స్పాన్సర్ చేయాలనుకుంటే వారి స్వంత సర్వర్‌లను సెటప్ చేసుకోవడానికి అనుమతించవచ్చు.

ఈ ట్యుటోరియల్‌లోని సాంకేతికత మీరు స్మార్ట్ కాంట్రాక్ట్‌ను నియంత్రించినప్పుడు మాత్రమే పనిచేస్తుంది. ఇతర స్మార్ట్ కాంట్రాక్ట్‌లకు లావాదేవీలను స్పాన్సర్ చేయడానికి మిమ్మల్ని అనుమతించే ఖాతా నైరూప్యత (కొత్త ట్యాబ్‌లో తెరవబడుతుంది)తో సహా ఇతర పద్ధతులు ఉన్నాయి, వీటిని నేను భవిష్యత్తు ట్యుటోరియల్‌లో కవర్ చేయాలని ఆశిస్తున్నాను.

గమనిక: ఇది ప్రొడక్షన్-స్థాయి కోడ్ కాదు. ఇది ముఖ్యమైన దాడులకు గురయ్యే అవకాశం ఉంది మరియు ప్రధాన ఫీచర్లు ఇందులో లేవు. ఈ గైడ్ యొక్క దుర్బలత్వాల విభాగంలో మరింత తెలుసుకోండి.

ముందస్తు అవసరాలు

ఈ ట్యుటోరియల్‌ను అర్థం చేసుకోవడానికి మీకు ఇప్పటికే వీటిపై అవగాహన ఉండాలి:

నమూనా అప్లికేషన్

ఇక్కడ ఉన్న నమూనా అప్లికేషన్ Hardhat యొక్క Greeter కాంట్రాక్ట్‌కి ఒక వేరియంట్. మీరు దీన్ని GitHubలో (కొత్త ట్యాబ్‌లో తెరవబడుతుంది) చూడవచ్చు. స్మార్ట్ కాంట్రాక్ట్ ఇప్పటికే Sepolia (కొత్త ట్యాబ్‌లో తెరవబడుతుంది)లో, 0xC87506C66c7896366b9E988FE0aA5B6dDE77CFfA (కొత్త ట్యాబ్‌లో తెరవబడుతుంది) చిరునామా వద్ద డిప్లాయ్ చేయబడింది.

ఇది ఎలా పనిచేస్తుందో చూడటానికి, ఈ దశలను అనుసరించండి.

  1. రిపోజిటరీని క్లోన్ చేయండి మరియు అవసరమైన సాఫ్ట్‌వేర్‌ను ఇన్‌స్టాల్ చేయండి.

    git clone https://github.com/qbzzt/260301-gasless.git
    cd 260301-gasless/server
    npm install
    
  2. Sepoliaలో ETH ఉన్న వాలెట్‌కి PRIVATE_KEYని సెట్ చేయడానికి .envని సవరించండి. మీకు Sepolia ETH అవసరమైతే, ఫాసెట్‌ను ఉపయోగించండి. ఆదర్శవంతంగా, ఈ ప్రైవేట్ కీ మీ బ్రౌజర్ వాలెట్‌లో ఉన్నదాని కంటే భిన్నంగా ఉండాలి.

  3. సర్వర్‌ను ప్రారంభించండి.

    npm run dev
    
  4. http://localhost:5173 (కొత్త ట్యాబ్‌లో తెరవబడుతుంది) URL వద్ద అప్లికేషన్‌ను బ్రౌజ్ చేయండి.

  5. వాలెట్‌కి కనెక్ట్ చేయడానికి Connect with Injectedపై క్లిక్ చేయండి. వాలెట్‌లో ఆమోదించండి మరియు అవసరమైతే Sepoliaకి మార్పును ఆమోదించండి.

  6. కొత్త గ్రీటింగ్‌ను వ్రాసి, Update greeting via sponsorపై క్లిక్ చేయండి.

  7. సందేశంపై సంతకం చేయండి.

  8. సుమారు 12 సెకన్లు వేచి ఉండండి (Sepoliaలో బ్లాక్ సమయం). వేచి ఉన్నప్పుడు మీరు లావాదేవీని చూడటానికి సర్వర్ కన్సోల్‌లోని URLని చూడవచ్చు.

  9. గ్రీటింగ్ మారిందని మరియు చివరిగా అప్‌డేట్ చేసిన చిరునామా విలువ ఇప్పుడు మీ బ్రౌజర్ వాలెట్ చిరునామా అని చూడండి.

ఇది ఎలా పనిచేస్తుందో అర్థం చేసుకోవడానికి, యూజర్ ఇంటర్‌ఫేస్‌లో సందేశం ఎలా సృష్టించబడుతుందో, సర్వర్ ద్వారా అది ఎలా రిలే చేయబడుతుందో మరియు స్మార్ట్ కాంట్రాక్ట్ దానిని ఎలా ప్రాసెస్ చేస్తుందో మనం చూడాలి.

యూజర్ ఇంటర్‌ఫేస్

యూజర్ ఇంటర్‌ఫేస్ WAGMI (కొత్త ట్యాబ్‌లో తెరవబడుతుంది)పై ఆధారపడి ఉంటుంది; మీరు దాని గురించి ఈ ట్యుటోరియల్‌లో చదవవచ్చు.

మనం సందేశంపై ఎలా సంతకం చేస్తామో ఇక్కడ ఉంది:

const signGreeting = useCallback(

React హుక్ useCallback (కొత్త ట్యాబ్‌లో తెరవబడుతుంది) కాంపోనెంట్‌ను మళ్లీ డ్రా చేసినప్పుడు అదే ఫంక్షన్‌ను మళ్లీ ఉపయోగించడం ద్వారా పనితీరును మెరుగుపరచడానికి అనుమతిస్తుంది.

    async (greeting) => {
        if (!account) throw new Error("Wallet not connected")

ఖాతా లేకపోతే, ఎర్రర్‌ను లేవనెత్తండి. ఇది ఎప్పుడూ జరగకూడదు ఎందుకంటే ఆ సందర్భంలో signGreetingని కాల్ చేసే ప్రాసెస్‌ను ప్రారంభించే UI బటన్ డిసేబుల్ చేయబడుతుంది. అయినప్పటికీ, భవిష్యత్తు ప్రోగ్రామర్లు ఆ రక్షణను తీసివేయవచ్చు, కాబట్టి ఈ పరిస్థితిని ఇక్కడ కూడా తనిఖీ చేయడం మంచిది.

        const domain = {
            name: "Greeter",
            version: "1",
            chainId,
            verifyingContract: contractAddr,
        }

డొమైన్ సెపరేటర్ (కొత్త ట్యాబ్‌లో తెరవబడుతుంది) కోసం పారామితులు. ఈ విలువ స్థిరంగా ఉంటుంది, కాబట్టి మెరుగ్గా ఆప్టిమైజ్ చేయబడిన అమలులో, ఫంక్షన్‌ను కాల్ చేసిన ప్రతిసారీ దాన్ని మళ్లీ లెక్కించే బదులు మనం దాన్ని ఒకసారి లెక్కించవచ్చు.

  • name అనేది వినియోగదారు చదవగలిగే పేరు, అంటే మనం సంతకాలను ఉత్పత్తి చేస్తున్న dapp పేరు లాంటిది.
  • version అనేది వెర్షన్. వేర్వేరు వెర్షన్‌లు అనుకూలంగా ఉండవు.
  • chainId అనేది మనం ఉపయోగిస్తున్న చైన్, ఇది WAGMI ద్వారా (కొత్త ట్యాబ్‌లో తెరవబడుతుంది) అందించబడింది.
  • verifyingContract అనేది ఈ సంతకాన్ని ధృవీకరించే కాంట్రాక్ట్ చిరునామా. ఒకవేళ అనేక Greeter కాంట్రాక్ట్‌లు ఉండి, వాటికి వేర్వేరు గ్రీటింగ్‌లు ఉండాలని మనం కోరుకుంటే, ఒకే సంతకం బహుళ కాంట్రాక్ట్‌లకు వర్తించకూడదని మనం భావిస్తాము.

        const types = {
            GreetingRequest: [
                { name: "greeting", type: "string" },
            ],
        }

మనం సంతకం చేసే డేటా రకం. ఇక్కడ, మనకు ఒకే పారామితి greeting ఉంది, కానీ నిజ జీవిత సిస్టమ్‌లు సాధారణంగా మరిన్నింటిని కలిగి ఉంటాయి.

        const message = { greeting }

మనం సంతకం చేసి పంపాలనుకుంటున్న అసలు సందేశం. greeting అనేది ఫీల్డ్ పేరు మరియు దాన్ని పూరించే వేరియబుల్ పేరు రెండూ.

        const signature = await signTypedDataAsync({
            domain,
            types,
            primaryType: "GreetingRequest",
            message,
        })

వాస్తవానికి సంతకాన్ని పొందండి. ఈ ఫంక్షన్ అసమకాలికమైనది (asynchronous) ఎందుకంటే డేటాపై సంతకం చేయడానికి వినియోగదారులు (కంప్యూటర్ కోణం నుండి) చాలా సమయం తీసుకుంటారు.

ఫంక్షన్ ఒకే హెక్సాడెసిమల్ విలువను అందిస్తుంది. ఇక్కడ మనం దానిని ఫీల్డ్‌లుగా విభజిస్తాము.

    [account, chainId, contractAddr, signTypedDataAsync],
)

ఈ వేరియబుల్స్‌లో ఏవైనా మారితే, ఫంక్షన్ యొక్క కొత్త ఇన్‌స్టాన్స్‌ను సృష్టించండి. account మరియు chainId పారామితులను వినియోగదారు వాలెట్‌లో మార్చవచ్చు. contractAddr అనేది చైన్ Id యొక్క ఫంక్షన్. signTypedDataAsync మారకూడదు, కానీ మనం దానిని ఒక హుక్ (కొత్త ట్యాబ్‌లో తెరవబడుతుంది) నుండి దిగుమతి చేస్తాము, కాబట్టి మనం ఖచ్చితంగా చెప్పలేము మరియు దానిని ఇక్కడ జోడించడం ఉత్తమం.

ఇప్పుడు కొత్త గ్రీటింగ్‌పై సంతకం చేయబడింది కాబట్టి, మనం దానిని సర్వర్‌కు పంపాలి.

  const sponsoredGreeting = async () => {
    try {

ఈ ఫంక్షన్ సంతకాన్ని తీసుకుంటుంది మరియు దానిని సర్వర్‌కు పంపుతుంది.

      const signedMessage = await signGreeting(newGreeting)
      const response = await fetch("/server/sponsor", {

మనం వచ్చిన సర్వర్‌లోని /server/sponsor పాత్‌కి పంపండి.

        method: "POST",
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify(signedMessage),
      })

సమాచారాన్ని JSON-ఎన్‌కోడ్ చేసి పంపడానికి POSTని ఉపయోగించండి.

      const data = await response.json()
      console.log("Server response:", data)
    } catch (err) {
      console.error("Error:", err)
    }
  }

ప్రతిస్పందనను అవుట్‌పుట్ చేయండి. ప్రొడక్షన్ సిస్టమ్‌లో మనం వినియోగదారుకు ప్రతిస్పందనను కూడా చూపుతాము.

సర్వర్

నా ఫ్రంట్-ఎండ్‌గా Vite (కొత్త ట్యాబ్‌లో తెరవబడుతుంది)ని ఉపయోగించడం నాకు ఇష్టం. ఇది స్వయంచాలకంగా React లైబ్రరీలను అందిస్తుంది మరియు ఫ్రంట్-ఎండ్ కోడ్ మారినప్పుడు బ్రౌజర్‌ను అప్‌డేట్ చేస్తుంది. అయితే, Vite బ్యాకెండ్ టూలింగ్‌ను చేర్చదు.

పరిష్కారం index.js (కొత్త ట్యాబ్‌లో తెరవబడుతుంది)లో ఉంది.

ముందుగా మనం స్వయంగా హ్యాండిల్ చేసే అభ్యర్థనల కోసం ఒక హ్యాండ్లర్‌ను నమోదు చేస్తాము (POST నుండి /server/sponsor వరకు). ఆపై అన్ని ఇతర URLలను హ్యాండిల్ చేయడానికి మనం Vite సర్వర్‌ను సృష్టించి ఉపయోగిస్తాము.

ఇది కేవలం ఒక ప్రామాణిక viem (కొత్త ట్యాబ్‌లో తెరవబడుతుంది) బ్లాక్‌చైన్ కాల్.

స్మార్ట్ కాంట్రాక్ట్

చివరగా, Greeter.sol (కొత్త ట్యాబ్‌లో తెరవబడుతుంది) సంతకాన్ని ధృవీకరించాలి.

కన్స్ట్రక్టర్ పైన ఉన్న యూజర్ ఇంటర్‌ఫేస్ కోడ్ మాదిరిగానే డొమైన్ సెపరేటర్ (కొత్త ట్యాబ్‌లో తెరవబడుతుంది)ని సృష్టిస్తుంది. బ్లాక్‌చైన్ అమలు చాలా ఖరీదైనది, కాబట్టి మనం దానిని ఒకసారి మాత్రమే లెక్కిస్తాము.

    struct GreetingRequest {
        string greeting;
    }

ఇది సంతకం చేయబడే స్ట్రక్చర్. ఇక్కడ మనకు ఒకే ఫీల్డ్ ఉంది.

    bytes32 private constant GREETING_TYPEHASH =
        keccak256("GreetingRequest(string greeting)");

ఇది స్ట్రక్చర్ ఐడెంటిఫైయర్ (కొత్త ట్యాబ్‌లో తెరవబడుతుంది). ఇది యూజర్ ఇంటర్‌ఫేస్‌లో ప్రతిసారీ లెక్కించబడుతుంది.

    function sponsoredSetGreeting(
        GreetingRequest calldata req,
        uint8 v,
        bytes32 r,
        bytes32 s
    ) external {

ఈ ఫంక్షన్ సంతకం చేసిన అభ్యర్థనను స్వీకరిస్తుంది మరియు గ్రీటింగ్‌ను అప్‌డేట్ చేస్తుంది.

EIP 712 (కొత్త ట్యాబ్‌లో తెరవబడుతుంది)కి అనుగుణంగా డైజెస్ట్‌ను సృష్టించండి.

        // సంతకం చేసినవారిని తిరిగి పొందండి
        address signer = ecrecover(digest, v, r, s);
        require(signer != address(0), "Invalid signature");

సంతకం చేసినవారి చిరునామాను పొందడానికి ecrecover (కొత్త ట్యాబ్‌లో తెరవబడుతుంది)ని ఉపయోగించండి. చెడ్డ సంతకం ఇప్పటికీ చెల్లుబాటు అయ్యే చిరునామాకు దారితీయవచ్చని గమనించండి, అది కేవలం యాదృచ్ఛికమైనది కావచ్చు.

        // సంతకం చేసినవారు కాల్ చేసినట్లుగా గ్రీటింగ్‌ను వర్తింపజేయండి
        greeting = req.greeting;
        emit SetGreeting(signer, req.greeting);
    }

గ్రీటింగ్‌ను అప్‌డేట్ చేయండి.

దుర్బలత్వాలు

ఇది ప్రొడక్షన్-స్థాయి కోడ్ కాదు. ఇది ముఖ్యమైన దాడులకు గురయ్యే అవకాశం ఉంది మరియు ప్రధాన ఫీచర్లు ఇందులో లేవు. వాటిని ఎలా పరిష్కరించాలో ఇక్కడ కొన్ని ఉన్నాయి.

ఈ దాడులలో కొన్నింటిని చూడటానికి, Attacks శీర్షిక క్రింద ఉన్న బటన్‌లను క్లిక్ చేసి, ఏమి జరుగుతుందో చూడండి. Invalid signature బటన్ కోసం, లావాదేవీ ప్రతిస్పందనను చూడటానికి సర్వర్ కన్సోల్‌ను తనిఖీ చేయండి.

సర్వర్‌పై డినైయల్ ఆఫ్ సర్వీస్

అత్యంత సులభమైన దాడి సర్వర్‌పై డినైయల్-ఆఫ్-సర్వీస్ (కొత్త ట్యాబ్‌లో తెరవబడుతుంది) దాడి. సర్వర్ ఇంటర్నెట్‌లో ఎక్కడి నుండైనా అభ్యర్థనలను స్వీకరిస్తుంది మరియు ఆ అభ్యర్థనల ఆధారంగా లావాదేవీలను పంపుతుంది. దాడి చేసే వ్యక్తి చెల్లుబాటు అయ్యే లేదా చెల్లని సంతకాల సమూహాన్ని జారీ చేయకుండా నిరోధించడానికి ఖచ్చితంగా ఏమీ లేదు. ప్రతి ఒక్కటి లావాదేవీకి కారణమవుతుంది. చివరికి గ్యాస్ కోసం చెల్లించడానికి సర్వర్‌లో ETH అయిపోతుంది.

ఈ సమస్యకు ఒక పరిష్కారం ఏమిటంటే, రేటును బ్లాక్‌కి ఒక లావాదేవీకి పరిమితం చేయడం. బాహ్యంగా స్వంతమైన ఖాతాలకు గ్రీటింగ్‌లను చూపించడమే ఉద్దేశ్యమైతే, బ్లాక్ మధ్యలో గ్రీటింగ్ ఏమిటనేది ఏమైనప్పటికీ పట్టింపు లేదు.

మరొక పరిష్కారం ఏమిటంటే, చిరునామాలను ట్రాక్ చేయడం మరియు చెల్లుబాటు అయ్యే కస్టమర్ల నుండి మాత్రమే సంతకాలను అనుమతించడం.

తప్పు గ్రీటింగ్ సంతకాలు

మీరు Signature for wrong greetingపై క్లిక్ చేసినప్పుడు, మీరు నిర్దిష్ట చిరునామా (0xaA92c5d426430D4769c9E878C1333BDe3d689b3e) మరియు గ్రీటింగ్ (Hello) కోసం చెల్లుబాటు అయ్యే సంతకాన్ని సమర్పిస్తారు. కానీ అది వేరే గ్రీటింగ్‌తో సమర్పిస్తుంది. ఇది ecrecoverని గందరగోళానికి గురిచేస్తుంది, ఇది గ్రీటింగ్‌ను మారుస్తుంది కానీ తప్పు చిరునామాను కలిగి ఉంటుంది.

ఈ సమస్యను పరిష్కరించడానికి, సంతకం చేసిన స్ట్రక్చర్‌కు (కొత్త ట్యాబ్‌లో తెరవబడుతుంది) చిరునామాను జోడించండి. ఈ విధంగా, ecrecover యాదృచ్ఛిక చిరునామా సంతకంలోని చిరునామాతో సరిపోలదు మరియు స్మార్ట్ కాంట్రాక్ట్ సందేశాన్ని తిరస్కరిస్తుంది.

రీప్లే దాడులు

మీరు Replay attackపై క్లిక్ చేసినప్పుడు, మీరు అదే "నేను 0xaA92c5d426430D4769c9E878C1333BDe3d689b3e, మరియు గ్రీటింగ్ Helloగా ఉండాలని నేను కోరుకుంటున్నాను" అనే సంతకాన్ని సమర్పిస్తారు, కానీ సరైన గ్రీటింగ్‌తో. ఫలితంగా, చిరునామా (అది మీది కాదు) గ్రీటింగ్‌ను తిరిగి Helloకి మార్చిందని స్మార్ట్ కాంట్రాక్ట్ నమ్ముతుంది. దీన్ని చేయడానికి సమాచారం లావాదేవీ సమాచారంలో (కొత్త ట్యాబ్‌లో తెరవబడుతుంది) పబ్లిక్‌గా అందుబాటులో ఉంటుంది.

ఇది సమస్య అయితే, ఒక పరిష్కారం నాన్స్ (కొత్త ట్యాబ్‌లో తెరవబడుతుంది)ని జోడించడం. చిరునామాలు మరియు సంఖ్యల మధ్య మ్యాపింగ్ (కొత్త ట్యాబ్‌లో తెరవబడుతుంది)ని కలిగి ఉండండి మరియు సంతకానికి నాన్స్ ఫీల్డ్‌ను జోడించండి. నాన్స్ ఫీల్డ్ చిరునామా కోసం మ్యాపింగ్‌తో సరిపోలితే, సంతకాన్ని ఆమోదించండి మరియు తదుపరిసారి మ్యాపింగ్‌ను పెంచండి. అది సరిపోలకపోతే, లావాదేవీని తిరస్కరించండి.

మరొక పరిష్కారం ఏమిటంటే, సంతకం చేసిన డేటాకు టైమ్‌స్టాంప్‌ను జోడించడం మరియు ఆ టైమ్‌స్టాంప్ తర్వాత కొన్ని సెకన్ల పాటు మాత్రమే సంతకాన్ని చెల్లుబాటు అయ్యేదిగా ఆమోదించడం. ఇది సరళమైనది మరియు చౌకైనది, కానీ సమయ విండోలో రీప్లే దాడుల ప్రమాదం మరియు సమయ విండో మించిపోతే చట్టబద్ధమైన లావాదేవీల వైఫల్యం ప్రమాదం ఉంటుంది.

ఇతర తప్పిపోయిన ఫీచర్లు

ప్రొడక్షన్ సెట్టింగ్‌లో మనం జోడించే అదనపు ఫీచర్లు ఉన్నాయి.

ఇతర సర్వర్‌ల నుండి యాక్సెస్

ప్రస్తుతం, sponsorSetGreetingని సమర్పించడానికి మనం ఏ చిరునామానైనా అనుమతిస్తాము. వికేంద్రీకరణ ప్రయోజనాల దృష్ట్యా, మనం కోరుకునేది ఖచ్చితంగా ఇదే కావచ్చు. లేదా స్పాన్సర్ చేయబడిన లావాదేవీలు మన సర్వర్ ద్వారా వెళ్లేలా చూసుకోవాలని మనం కోరుకోవచ్చు, ఆ సందర్భంలో మనం స్మార్ట్ కాంట్రాక్ట్‌లో msg.senderని తనిఖీ చేస్తాము.

ఏది ఏమైనప్పటికీ, ఇది స్పృహతో కూడిన డిజైన్ నిర్ణయం అయి ఉండాలి, కేవలం సమస్య గురించి ఆలోచించకపోవడం వల్ల వచ్చిన ఫలితం కాదు.

ఎర్రర్ హ్యాండ్లింగ్

వినియోగదారు గ్రీటింగ్‌ను సమర్పిస్తారు. బహుశా అది తదుపరి బ్లాక్ వద్ద అప్‌డేట్ చేయబడవచ్చు. బహుశా కాకపోవచ్చు. ఎర్రర్‌లు కనిపించవు. ప్రొడక్షన్ సిస్టమ్‌లో, వినియోగదారు ఈ కేసుల మధ్య తేడాను గుర్తించగలగాలి:

  • కొత్త గ్రీటింగ్ ఇంకా సమర్పించబడలేదు
  • కొత్త గ్రీటింగ్ సమర్పించబడింది మరియు అది ప్రాసెస్‌లో ఉంది
  • కొత్త గ్రీటింగ్ తిరస్కరించబడింది

ముగింపు

ఈ పాటికి, కొంత కేంద్రీకరణతో మీ వికేంద్రీకృత అప్లికేషన్ (dapp) వినియోగదారుల కోసం మీరు గ్యాస్‌లెస్ అనుభవాన్ని సృష్టించగలరు.

అయినప్పటికీ, ఇది ERC-712కి మద్దతు ఇచ్చే స్మార్ట్ కాంట్రాక్ట్‌లతో మాత్రమే పనిచేస్తుంది. ఉదాహరణకు, ఒక ERC-20 టోకెన్‌ను బదిలీ చేయడానికి, కేవలం ఒక సందేశంపై మాత్రమే కాకుండా లావాదేవీపై యజమాని సంతకం చేయడం అవసరం. దీనికి సులభమైన పరిష్కారం ఏమిటంటే, ఆస్తులు EOA చిరునామా స్వంతంగా కాకుండా, ఒక ప్రత్యేక కాంట్రాక్ట్ స్వంతంగా ఉండేలా చేయడం (ఖాతా నైరూప్యత యొక్క సాధారణ రూపం). దీని గురించి మీరు తదుపరి ట్యుటోరియల్‌లో మరింత చదవవచ్చు.

నా మరిన్ని పనుల కోసం ఇక్కడ చూడండి (కొత్త ట్యాబ్‌లో తెరవబడుతుంది).