---
title: "గ్యాస్ ఫీజులను స్పాన్సర్ చేయడం: మీ వినియోగదారుల కోసం లావాదేవీ ఖర్చులను ఎలా భరించాలి"
description: "ప్రైవేట్ కీ మరియు చిరునామాను సృష్టించడం సులభం; సరైన సాఫ్ట్‌వేర్‌ను రన్ చేస్తే సరిపోతుంది. కానీ లావాదేవీలను పంపడానికి ETH పొందడం ప్రపంచంలోని అనేక ప్రదేశాలలో చాలా కష్టం. ఈ ట్యుటోరియల్‌లో, మీ స్మార్ట్ కాంట్రాక్ట్‌లో వినియోగదారు సంతకం చేసిన, ఆఫ్‌చైన్ స్ట్రక్చర్డ్ డేటాను అమలు చేయడానికి ఆన్‌చైన్ గ్యాస్ ఖర్చులను ఎలా భరించాలో మీరు నేర్చుకుంటారు. లావాదేవీ సమాచారాన్ని కలిగి ఉన్న స్ట్రక్చర్‌పై మీరు వినియోగదారుతో సంతకం చేయిస్తారు, ఆపై మీ ఆఫ్‌చైన్ కోడ్ దానిని బ్లాక్‌చైన్‌కు లావాదేవీగా సమర్పిస్తుంది."
author: "ఓరి పోమెరాంట్జ్"
tags: ["గ్యాస్‌లెస్", "Solidity", "eip-712", "మెటా-లావాదేవీలు"]
skill: intermediate
breadcrumb: "గ్యాస్ స్పాన్సరింగ్"
lang: te
published: 2026-02-27
---

## పరిచయం {#introduction}

ఎథీరియం [మరో బిలియన్ మందికి](https://blog.ethereum.org/category/next-billion) సేవలు అందించాలని మనం కోరుకుంటే, మనం అడ్డంకులను తొలగించి, దానిని వీలైనంత సులభంగా ఉపయోగించేలా చేయాలి. గ్యాస్ ఫీజులు చెల్లించడానికి ETH అవసరం కావడం ఈ అడ్డంకులలో ఒకటి.

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

ఈ ట్యుటోరియల్‌లోని సాంకేతికత మీరు స్మార్ట్ కాంట్రాక్ట్‌ను నియంత్రించినప్పుడు మాత్రమే పనిచేస్తుంది. ఇతర స్మార్ట్ కాంట్రాక్ట్‌లకు లావాదేవీలను స్పాన్సర్ చేయడానికి మిమ్మల్ని అనుమతించే [ఖాతా నైరూప్యత](https://eips.ethereum.org/EIPS/eip-4337)తో సహా ఇతర పద్ధతులు ఉన్నాయి, వీటిని నేను భవిష్యత్తు ట్యుటోరియల్‌లో కవర్ చేయాలని ఆశిస్తున్నాను.

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

### ముందస్తు అవసరాలు {#prerequisites}

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

- Solidity
- JavaScript
- React మరియు WAGMI. మీకు ఈ యూజర్ ఇంటర్‌ఫేస్ సాధనాల గురించి తెలియకపోతే, [దాని కోసం మా వద్ద ఒక ట్యుటోరియల్ ఉంది](/developers/tutorials/creating-a-wagmi-ui-for-your-contract/).

## నమూనా అప్లికేషన్ {#sample-app}

ఇక్కడ ఉన్న నమూనా అప్లికేషన్ Hardhat యొక్క `Greeter` కాంట్రాక్ట్‌కి ఒక వేరియంట్. మీరు దీన్ని [GitHubలో](https://github.com/qbzzt/260301-gasless) చూడవచ్చు. స్మార్ట్ కాంట్రాక్ట్ ఇప్పటికే [Sepolia](https://sepolia.dev/)లో, [`0xC87506C66c7896366b9E988FE0aA5B6dDE77CFfA`](https://eth-sepolia.blockscout.com/address/0xC87506C66c7896366b9E988FE0aA5B6dDE77CFfA) చిరునామా వద్ద డిప్లాయ్ చేయబడింది.

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

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

   ```sh
   git clone https://github.com/qbzzt/260301-gasless.git
   cd 260301-gasless/server
   npm install
   ```

2. Sepoliaలో ETH ఉన్న వాలెట్‌కి `PRIVATE_KEY`ని సెట్ చేయడానికి `.env`ని సవరించండి. మీకు Sepolia ETH అవసరమైతే, [ఫాసెట్‌ను ఉపయోగించండి](/developers/docs/networks/#sepolia). ఆదర్శవంతంగా, ఈ ప్రైవేట్ కీ మీ బ్రౌజర్ వాలెట్‌లో ఉన్నదాని కంటే భిన్నంగా ఉండాలి.

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

   ```sh
   npm run dev
   ```

4. [`http://localhost:5173`](http://localhost:5173) URL వద్ద అప్లికేషన్‌ను బ్రౌజ్ చేయండి.

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

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

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

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

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

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

### యూజర్ ఇంటర్‌ఫేస్ {#ui-changes}

యూజర్ ఇంటర్‌ఫేస్ [WAGMI](https://wagmi.sh/)పై ఆధారపడి ఉంటుంది; మీరు దాని గురించి [ఈ ట్యుటోరియల్‌లో](/developers/tutorials/creating-a-wagmi-ui-for-your-contract/) చదవవచ్చు.

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

```js
const signGreeting = useCallback(
```

React హుక్ [`useCallback`](https://react.dev/reference/react/useCallback) కాంపోనెంట్‌ను మళ్లీ డ్రా చేసినప్పుడు అదే ఫంక్షన్‌ను మళ్లీ ఉపయోగించడం ద్వారా పనితీరును మెరుగుపరచడానికి అనుమతిస్తుంది.

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

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

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

[డొమైన్ సెపరేటర్](https://eips.ethereum.org/EIPS/eip-712#definition-of-domainseparator) కోసం పారామితులు. ఈ విలువ స్థిరంగా ఉంటుంది, కాబట్టి మెరుగ్గా ఆప్టిమైజ్ చేయబడిన అమలులో, ఫంక్షన్‌ను కాల్ చేసిన ప్రతిసారీ దాన్ని మళ్లీ లెక్కించే బదులు మనం దాన్ని ఒకసారి లెక్కించవచ్చు.

- `name` అనేది వినియోగదారు చదవగలిగే పేరు, అంటే మనం సంతకాలను ఉత్పత్తి చేస్తున్న dapp పేరు లాంటిది.
- `version` అనేది వెర్షన్. వేర్వేరు వెర్షన్‌లు అనుకూలంగా ఉండవు.
- `chainId` అనేది మనం ఉపయోగిస్తున్న చైన్, ఇది [WAGMI ద్వారా](https://wagmi.sh/react/api/hooks/useChainId) అందించబడింది.
- `verifyingContract` అనేది ఈ సంతకాన్ని ధృవీకరించే కాంట్రాక్ట్ చిరునామా. ఒకవేళ అనేక `Greeter` కాంట్రాక్ట్‌లు ఉండి, వాటికి వేర్వేరు గ్రీటింగ్‌లు ఉండాలని మనం కోరుకుంటే, ఒకే సంతకం బహుళ కాంట్రాక్ట్‌లకు వర్తించకూడదని మనం భావిస్తాము.

```js

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

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

```js
        const message = { greeting }
```

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

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

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

```js
        const r = `0x${signature.slice(2, 66)}`
        const s = `0x${signature.slice(66, 130)}`
        const v = parseInt(signature.slice(130, 132), 16)

        return {
            req: { greeting },
            v,
            r,
            s,
        }
    },
```

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

```js
    [account, chainId, contractAddr, signTypedDataAsync],
)
```

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

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

```js
  const sponsoredGreeting = async () => {
    try {
```

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

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

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

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

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

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

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

### సర్వర్ {#server}

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

పరిష్కారం [`index.js`](https://github.com/qbzzt/260301-gasless/blob/main/server/index.js)లో ఉంది.

```js
  app.post("/server/sponsor", async (req, res) => {
    ...
  })

  // మిగతావన్నీ Vite నిర్వహించనివ్వండి
  const vite = await createViteServer({
    server: { middlewareMode: true }
  })

  app.use(vite.middlewares)
```

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

```js
  app.post("/server/sponsor", async (req, res) => {
    try {
      const signed = req.body

      const txHash = await sepoliaClient.writeContract({
        address: greeterAddr,
        abi: greeterABI,
        functionName: 'sponsoredSetGreeting',
        args: [signed.req, signed.v, signed.r, signed.s],
      })
    } ...
  })
```

ఇది కేవలం ఒక ప్రామాణిక [viem](https://viem.sh/) బ్లాక్‌చైన్ కాల్.

### స్మార్ట్ కాంట్రాక్ట్ {#smart-contract}

చివరగా, [`Greeter.sol`](https://github.com/qbzzt/260301-gasless/blob/main/contracts/src/Greeter.sol) సంతకాన్ని ధృవీకరించాలి.

```solidity
    constructor(string memory _greeting) {
        greeting = _greeting;

        DOMAIN_SEPARATOR = keccak256(
            abi.encode(
                keccak256(
                    "EIP712Domain(string name,string version,uint256 chainId,address verifyingContract)"
                ),
                keccak256(bytes("Greeter")),
                keccak256(bytes("1")),
                block.chainid,
                address(this)
            )
        );
    }
```

కన్స్ట్రక్టర్ పైన ఉన్న యూజర్ ఇంటర్‌ఫేస్ కోడ్ మాదిరిగానే [డొమైన్ సెపరేటర్](https://eips.ethereum.org/EIPS/eip-712#definition-of-domainseparator)ని సృష్టిస్తుంది. బ్లాక్‌చైన్ అమలు చాలా ఖరీదైనది, కాబట్టి మనం దానిని ఒకసారి మాత్రమే లెక్కిస్తాము.

```solidity
    struct GreetingRequest {
        string greeting;
    }
```

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

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

ఇది [స్ట్రక్చర్ ఐడెంటిఫైయర్](https://eips.ethereum.org/EIPS/eip-712#definition-of-hashstruct). ఇది యూజర్ ఇంటర్‌ఫేస్‌లో ప్రతిసారీ లెక్కించబడుతుంది.

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

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

```solidity
        // EIP-712 డైజెస్ట్‌ను లెక్కించండి
        bytes32 digest = keccak256(
            abi.encodePacked(
                "\x19\x01",
                DOMAIN_SEPARATOR,
                keccak256(
                    abi.encode(
                        GREETING_TYPEHASH,
                        keccak256(bytes(req.greeting))
                    )
                )
            )
        );
```

[EIP 712](https://eips.ethereum.org/EIPS/eip-712)కి అనుగుణంగా డైజెస్ట్‌ను సృష్టించండి.

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

సంతకం చేసినవారి చిరునామాను పొందడానికి [`ecrecover`](https://www.evm.codes/precompiled?fork=osaka#0x01)ని ఉపయోగించండి. చెడ్డ సంతకం ఇప్పటికీ చెల్లుబాటు అయ్యే చిరునామాకు దారితీయవచ్చని గమనించండి, అది కేవలం యాదృచ్ఛికమైనది కావచ్చు.

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

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

## దుర్బలత్వాలు {#vulnerabilities}

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

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

### సర్వర్‌పై డినైయల్ ఆఫ్ సర్వీస్ {#dos-on-server}

అత్యంత సులభమైన దాడి సర్వర్‌పై [డినైయల్-ఆఫ్-సర్వీస్](https://en.wikipedia.org/wiki/Denial-of-service_attack) దాడి. సర్వర్ ఇంటర్నెట్‌లో ఎక్కడి నుండైనా అభ్యర్థనలను స్వీకరిస్తుంది మరియు ఆ అభ్యర్థనల ఆధారంగా లావాదేవీలను పంపుతుంది. దాడి చేసే వ్యక్తి చెల్లుబాటు అయ్యే లేదా చెల్లని సంతకాల సమూహాన్ని జారీ చేయకుండా నిరోధించడానికి ఖచ్చితంగా ఏమీ లేదు. ప్రతి ఒక్కటి లావాదేవీకి కారణమవుతుంది. చివరికి గ్యాస్ కోసం చెల్లించడానికి సర్వర్‌లో ETH అయిపోతుంది.

ఈ సమస్యకు ఒక పరిష్కారం ఏమిటంటే, రేటును బ్లాక్‌కి ఒక లావాదేవీకి పరిమితం చేయడం. [బాహ్యంగా స్వంతమైన ఖాతాలకు](/developers/docs/accounts/#key-differences) గ్రీటింగ్‌లను చూపించడమే ఉద్దేశ్యమైతే, బ్లాక్ మధ్యలో గ్రీటింగ్ ఏమిటనేది ఏమైనప్పటికీ పట్టింపు లేదు.

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

### తప్పు గ్రీటింగ్ సంతకాలు {#wrong-greeting-sigs}

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

ఈ సమస్యను పరిష్కరించడానికి, [సంతకం చేసిన స్ట్రక్చర్‌కు](https://github.com/qbzzt/260301-gasless/blob/main/server/src/Greeter.jsx#L122-L124) చిరునామాను జోడించండి. ఈ విధంగా, `ecrecover` యాదృచ్ఛిక చిరునామా సంతకంలోని చిరునామాతో సరిపోలదు మరియు స్మార్ట్ కాంట్రాక్ట్ సందేశాన్ని తిరస్కరిస్తుంది.

### రీప్లే దాడులు {#replay-attack}

మీరు **Replay attack**పై క్లిక్ చేసినప్పుడు, మీరు అదే "నేను 0xaA92c5d426430D4769c9E878C1333BDe3d689b3e, మరియు గ్రీటింగ్ `Hello`గా ఉండాలని నేను కోరుకుంటున్నాను" అనే సంతకాన్ని సమర్పిస్తారు, కానీ సరైన గ్రీటింగ్‌తో. ఫలితంగా, చిరునామా (అది మీది కాదు) గ్రీటింగ్‌ను తిరిగి `Hello`కి మార్చిందని స్మార్ట్ కాంట్రాక్ట్ నమ్ముతుంది. దీన్ని చేయడానికి సమాచారం [లావాదేవీ సమాచారంలో](https://eth-sepolia.blockscout.com/tx/0xa66afe4bbf886f59533e677a798c802ceab1ac0f9db6e83a4d4b59a45cf7c1b1) పబ్లిక్‌గా అందుబాటులో ఉంటుంది.

ఇది సమస్య అయితే, ఒక పరిష్కారం [నాన్స్](https://en.wikipedia.org/wiki/Cryptographic_nonce)ని జోడించడం. చిరునామాలు మరియు సంఖ్యల మధ్య [మ్యాపింగ్](https://docs.soliditylang.org/en/latest/types.html#mapping-types)ని కలిగి ఉండండి మరియు సంతకానికి నాన్స్ ఫీల్డ్‌ను జోడించండి. నాన్స్ ఫీల్డ్ చిరునామా కోసం మ్యాపింగ్‌తో సరిపోలితే, సంతకాన్ని ఆమోదించండి మరియు తదుపరిసారి మ్యాపింగ్‌ను పెంచండి. అది సరిపోలకపోతే, లావాదేవీని తిరస్కరించండి.

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

## ఇతర తప్పిపోయిన ఫీచర్లు {#other-missing-features}

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

### ఇతర సర్వర్‌ల నుండి యాక్సెస్ {#other-servers}

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

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

### ఎర్రర్ హ్యాండ్లింగ్ {#error-handling}

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

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

## ముగింపు {#conclusion}

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

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

[నా మరిన్ని పనుల కోసం ఇక్కడ చూడండి](https://cryptodocguy.pro/).