எரிவாயு கட்டணங்களை ஸ்பான்சர் செய்தல்: உங்கள் பயனர்களுக்கான பரிவர்த்தனை செலவுகளை எவ்வாறு ஈடுசெய்வது

அறிமுகம்

எத்திரியம் இன்னும் ஒரு பில்லியன் மக்களுக்கு (புதிய தாவலில் திறக்கப்படும்) சேவை செய்ய வேண்டுமென்றால், நாம் தடைகளை அகற்றி, அதைப் பயன்படுத்துவதை முடிந்தவரை எளிதாக்க வேண்டும். இந்தத் தடைகளில் ஒன்று எரிவாயு கட்டணங்களைச் செலுத்த ETH தேவைப்படுவதாகும்.

பயனர்களிடமிருந்து பணம் சம்பாதிக்கும் பரவலாக்கப்பட்ட செயலி (dapp) உங்களிடம் இருந்தால், பயனர்கள் உங்கள் சேவையகம் மூலம் பரிவர்த்தனைகளைச் சமர்ப்பிக்க அனுமதிப்பதும், பரிவர்த்தனை கட்டணங்களை நீங்களே செலுத்துவதும் அர்த்தமுள்ளதாக இருக்கும். பயனர்கள் தங்கள் பணப்பைகளில் EIP-712 அங்கீகார செய்தியில் (புதிய தாவலில் திறக்கப்படும்) இன்னும் கையொப்பமிடுவதால், அவர்கள் எத்திரியத்தின் ஒருமைப்பாட்டு உத்தரவாதங்களைத் தக்கவைத்துக்கொள்கிறார்கள். கிடைக்கும் தன்மை பரிவர்த்தனைகளை ரிலே செய்யும் சேவையகத்தைப் பொறுத்தது, எனவே இது மிகவும் வரையறுக்கப்பட்டுள்ளது. இருப்பினும், பயனர்கள் திறன் ஒப்பந்தத்தை நேரடியாக அணுகும் வகையிலும் (அவர்களுக்கு ETH கிடைத்தால்), மற்றவர்கள் பரிவர்த்தனைகளை ஸ்பான்சர் செய்ய விரும்பினால் தங்கள் சொந்த சேவையகங்களை அமைக்கும் வகையிலும் நீங்கள் விஷயங்களை அமைக்கலாம்.

இந்த வழிகாட்டியில் உள்ள நுட்பம் நீங்கள் திறன் ஒப்பந்தத்தைக் கட்டுப்படுத்தும்போது மட்டுமே வேலை செய்யும். மற்ற திறன் ஒப்பந்தங்களுக்கு பரிவர்த்தனைகளை ஸ்பான்சர் செய்ய உங்களை அனுமதிக்கும் கணக்குச் சுருக்கம் (புதிய தாவலில் திறக்கப்படும்) உள்ளிட்ட பிற நுட்பங்களும் உள்ளன, அவற்றை எதிர்கால வழிகாட்டியில் நான் விவரிக்க நம்புகிறேன்.

குறிப்பு: இது தயாரிப்பு-நிலை குறியீடு அல்ல. இது குறிப்பிடத்தக்க தாக்குதல்களுக்கு ஆளாகக்கூடியது மற்றும் முக்கிய அம்சங்களைக் கொண்டிருக்கவில்லை. இந்த வழிகாட்டியின் பாதிப்புகள் பிரிவில் மேலும் அறிக.

முன்நிபந்தனைகள்

இந்த வழிகாட்டியைப் புரிந்துகொள்ள நீங்கள் ஏற்கனவே இவற்றைப் பற்றி அறிந்திருக்க வேண்டும்:

• Solidity
• JavaScript
• React மற்றும் WAGMI. இந்த பயனர் இடைமுகக் கருவிகளைப் பற்றி உங்களுக்குத் தெரியாவிட்டால், அதற்கான வழிகாட்டி எங்களிடம் உள்ளது.

மாதிரிப் பயன்பாடு

இங்குள்ள மாதிரிப் பயன்பாடு Hardhat இன் Greeter ஒப்பந்தத்தின் ஒரு மாறுபாடாகும். இதை நீங்கள் GitHub இல் (புதிய தாவலில் திறக்கப்படும்) பார்க்கலாம். திறன் ஒப்பந்தம் ஏற்கனவே Sepolia (புதிய தாவலில் திறக்கப்படும்) இல், 0xC87506C66c7896366b9E988FE0aA5B6dDE77CFfA (புதிய தாவலில் திறக்கப்படும்) என்ற முகவரியில் பயன்படுத்தப்பட்டுள்ளது.

இது எவ்வாறு செயல்படுகிறது என்பதைப் பார்க்க, இந்தப் படிகளைப் பின்பற்றவும்.

1. களஞ்சியத்தை குளோன் செய்து தேவையான மென்பொருளை நிறுவவும்.

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

   நகலெடுShell

2. Sepolia இல் ETH உள்ள பணப்பைக்கு PRIVATE_KEY ஐ அமைக்க .env ஐத் திருத்தவும். உங்களுக்கு Sepolia ETH தேவைப்பட்டால், ஒரு பாசெட்டைப் பயன்படுத்தவும். உங்கள் உலாவி பணப்பையில் உள்ளதிலிருந்து இந்த தனிப்பட்ட திறவுகோல் வேறுபட்டதாக இருப்பது சிறந்தது.

3. சேவையகத்தைத் தொடங்கவும்.

   npm run dev
   

   நகலெடுShell

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,
        })

உண்மையில் கையொப்பத்தைப் பெறுங்கள். பயனர்கள் தரவில் கையொப்பமிட நீண்ட நேரம் (கணினியின் கண்ணோட்டத்தில்) எடுத்துக்கொள்வதால் இந்தச் செயல்பாடு ஒத்திசைவற்றது.

        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,
        }
    },

செயல்பாடு ஒற்றை ஹெக்ஸாடெசிமல் மதிப்பை வழங்குகிறது. இங்கே நாம் அதைப் புலங்களாகப் பிரிக்கிறோம்.

    [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 (புதிய தாவலில் திறக்கப்படும்) இல் உள்ளது.

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

  // மற்ற அனைத்தையும் Vite கையாளட்டும்
  const vite = await createViteServer({
    server: { middlewareMode: true }
  })

  app.use(vite.middlewares)

முதலில் நாம் நாமே கையாளும் கோரிக்கைகளுக்கான ஹேண்ட்லரைப் பதிவு செய்கிறோம் (POST முதல் /server/sponsor வரை). பின்னர் மற்ற அனைத்து URLகளையும் கையாள ஒரு Vite சேவையகத்தை உருவாக்கிப் பயன்படுத்துகிறோம்.

  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 (புதிய தாவலில் திறக்கப்படும்) தொகுதிச்சங்கிலி அழைப்பு மட்டுமே.

திறன் ஒப்பந்தம்

இறுதியாக, Greeter.sol (புதிய தாவலில் திறக்கப்படும்) கையொப்பத்தைச் சரிபார்க்க வேண்டும்.

    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)
            )
        );
    }

மேலே உள்ள பயனர் இடைமுகக் குறியீட்டைப் போலவே, ஆக்கி டொமைன் பிரிப்பானை (புதிய தாவலில் திறக்கப்படும்) உருவாக்குகிறது. தொகுதிச்சங்கிலி செயலாக்கம் மிகவும் விலை உயர்ந்தது, எனவே நாம் அதை ஒரு முறை மட்டுமே கணக்கிடுகிறோம்.

    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 சுருக்கத்தைக் கணக்கிடுக
        bytes32 digest = keccak256(
            abi.encodePacked(
                "\x19\x01",
                DOMAIN_SEPARATOR,
                keccak256(
                    abi.encode(
                        GREETING_TYPEHASH,
                        keccak256(bytes(req.greeting))
                    )
                )
            )
        );

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 முகவரியால் அல்லாமல், ஒரு தனி ஒப்பந்தத்தால் (கணக்குச் சுருக்கத்தின் ஒரு எளிய வடிவம்) சொத்துக்களைச் சொந்தமாக வைத்திருப்பதே எளிமையான தீர்வாகும். இதைப் பற்றி தொடர்ச்சியான வழிகாட்டியில் நீங்கள் மேலும் படிக்கலாம்.

எனது மேலும் சில பணிகளை இங்கே காணுங்கள் (புதிய தாவலில் திறக்கப்படும்).