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

கேஸ் இல்லாத

Solidity

EIP-712

மெட்டா-பரிவர்த்தனைகள்

இடைநிலையாளர்

ஓரி பொமரன்ட்ஸ்

27 பிப்ரவரி, 2026

9 நிமிட வாசிப்பு

அறிமுகம்

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

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

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

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

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

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

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

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

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

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

ரெபோசிட்டரியை குளோன் செய்து தேவையான மென்பொருளை நிறுவவும்.
```
1git clone https://github.com/qbzzt/260301-gasless.git
2cd 260301-gasless/server
3npm install
```
Sepolia-இல் ETH உள்ள ஒரு வாலெட்டிற்கு PRIVATE_KEY-ஐ அமைக்க .env-ஐத் திருத்தவும். உங்களுக்கு Sepolia ETH தேவைப்பட்டால், ஒரு ஃபாசெட்டைப் பயன்படுத்தவும். உங்கள் உலாவி வாலெட்டில் உள்ள தனிப்பட்ட திறவுகோலிலிருந்து இது வேறுபட்டதாக இருப்பது சிறந்தது.
சர்வரைத் தொடங்கவும்.
```
1npm run dev
```
http://localhost:5173 (opens in a new tab) என்ற URL-இல் உள்ள பயன்பாட்டிற்குச் செல்லவும்.
ஒரு வாலெட்டுடன் இணைக்க Connect with Injected என்பதைக் கிளிக் செய்யவும். வாலெட்டில் அங்கீகரிக்கவும், தேவைப்பட்டால் Sepolia-க்கான மாற்றத்தையும் அங்கீகரிக்கவும்.
ஒரு புதிய வாழ்த்துச் செய்தியை எழுதி, Update greeting via sponsor என்பதைக் கிளிக் செய்யவும்.
செய்தியில் கையொப்பமிடவும்.
சுமார் 12 வினாடிகள் காத்திருக்கவும் (Sepolia-இல் பிளாக் நேரம்). காத்திருக்கும்போது பரிவர்த்தனையைப் பார்க்க சர்வரின் கன்சோலில் உள்ள URL-ஐ நீங்கள் பார்க்கலாம்.
வாழ்த்துச் செய்தி மாறியிருப்பதையும், கடைசியாகப் புதுப்பிக்கப்பட்ட முகவரி மதிப்பு இப்போது உங்கள் உலாவி வாலெட்டின் முகவரியாக இருப்பதையும் பார்க்கவும்.

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

பயனர் இடைமுகம்

பயனர் இடைமுகம் WAGMI (opens in a new tab)-ஐ அடிப்படையாகக் கொண்டது; இதைப் பற்றி இந்த டுடோரியலில் நீங்கள் படிக்கலாம்.

செய்தியில் நாம் எவ்வாறு கையொப்பமிடுகிறோம் என்பது இங்கே:

1const signGreeting = useCallback(

React ஹூக் useCallback (opens in a new tab) கூறு மீண்டும் வரையப்படும்போது அதே செயல்பாட்டை மீண்டும் பயன்படுத்துவதன் மூலம் செயல்திறனை மேம்படுத்த அனுமதிக்கிறது.

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

கணக்கு இல்லை என்றால், ஒரு பிழையை எழுப்பவும். இது ஒருபோதும் நடக்கக்கூடாது, ஏனெனில் signGreeting-ஐ அழைக்கும் செயல்முறையைத் தொடங்கும் UI பட்டன் அந்த நிலையில் முடக்கப்பட்டிருக்கும். இருப்பினும், எதிர்கால புரோகிராமர்கள் அந்தப் பாதுகாப்பை அகற்றலாம், எனவே இந்த நிபந்தனையை இங்கும் சரிபார்ப்பது நல்லது.

1        const domain = {
2            name: "Greeter",
3            version: "1",
4            chainId,
5            verifyingContract: contractAddr,
6        }

டொமைன் பிரிப்பானுக்கான (domain separator) (opens in a new tab) அளவுருக்கள். இந்த மதிப்பு மாறிலியானது, எனவே சிறப்பாக உகந்ததாக்கப்பட்ட செயலாக்கத்தில், செயல்பாடு அழைக்கப்படும் ஒவ்வொரு முறையும் அதை மீண்டும் கணக்கிடுவதற்குப் பதிலாக ஒரு முறை மட்டுமே கணக்கிடலாம்.

name என்பது பயனர் படிக்கக்கூடிய பெயராகும், அதாவது நாம் கையொப்பங்களை உருவாக்கும் dapp-இன் பெயர்.
version என்பது பதிப்பாகும். வெவ்வேறு பதிப்புகள் இணக்கமானவை அல்ல.
chainId என்பது நாம் பயன்படுத்தும் செயின் ஆகும், இது WAGMI-ஆல் (opens in a new tab) வழங்கப்படுகிறது.
verifyingContract என்பது இந்தக் கையொப்பத்தைச் சரிபார்க்கும் ஒப்பந்த முகவரியாகும். பல Greeter ஒப்பந்தங்கள் இருந்து, அவை வெவ்வேறு வாழ்த்துச் செய்திகளைக் கொண்டிருக்க வேண்டும் என்று நாம் விரும்பினால், ஒரே கையொப்பம் பல ஒப்பந்தங்களுக்குப் பொருந்தக்கூடாது.

1
2        const types = {
3            GreetingRequest: [
4                { name: "greeting", type: "string" },
5            ],
6        }

நாம் கையொப்பமிடும் தரவு வகை. இங்கே, greeting என்ற ஒற்றை அளவுரு மட்டுமே உள்ளது, ஆனால் நிஜ வாழ்க்கை அமைப்புகளில் பொதுவாக அதிகமாக இருக்கும்.

1        const message = { greeting }

நாம் கையொப்பமிட்டு அனுப்ப விரும்பும் உண்மையான செய்தி. greeting என்பது புலத்தின் பெயர் மற்றும் அதை நிரப்பும் மாறியின் பெயர் ஆகிய இரண்டையும் குறிக்கிறது.

1        const signature = await signTypedDataAsync({
2            domain,
3            types,
4            primaryType: "GreetingRequest",
5            message,
6        })

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

1        const r = `0x${signature.slice(2, 66)}`
2        const s = `0x${signature.slice(66, 130)}`
3        const v = parseInt(signature.slice(130, 132), 16)
4
5        return {
6            req: { greeting },
7            v,
8            r,
9            s,
10        }
11    },

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

1    [account, chainId, contractAddr, signTypedDataAsync],
2)

இந்த மாறிகளில் ஏதேனும் மாறினால், செயல்பாட்டின் புதிய நிகழ்வை (instance) உருவாக்கவும். account மற்றும் chainId அளவுருக்களைப் பயனர் வாலெட்டில் மாற்றலாம். contractAddr என்பது செயின் Id-இன் ஒரு செயல்பாடாகும். signTypedDataAsync மாறக்கூடாது, ஆனால் நாம் அதை ஒரு ஹூக்கிலிருந்து (opens in a new tab) இறக்குமதி செய்கிறோம், எனவே நாம் உறுதியாகச் சொல்ல முடியாது, மேலும் அதை இங்கே சேர்ப்பது சிறந்தது.

இப்போது புதிய வாழ்த்துச் செய்தி கையொப்பமிடப்பட்டுள்ளதால், நாம் அதை சர்வருக்கு அனுப்ப வேண்டும்.

1  const sponsoredGreeting = async () => {
2    try {

இந்தச் செயல்பாடு ஒரு கையொப்பத்தை எடுத்து அதை சர்வருக்கு அனுப்புகிறது.

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

நாம் வந்த சர்வரில் உள்ள /server/sponsor என்ற பாதைக்கு அனுப்பவும்.

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

தகவலை JSON-குறியாக்கம் செய்து அனுப்ப POST-ஐப் பயன்படுத்தவும்.

1      const data = await response.json()
2      console.log("Server response:", data)
3    } catch (err) {
4      console.error("Error:", err)
5    }
6  }

பதிலை வெளியிடவும். ஒரு தயாரிப்பு அமைப்பில் நாம் பயனருக்கும் பதிலைக் காண்பிப்போம்.

சர்வர்

எனது முன்-முனையாக (front-end) Vite (opens in a new tab)-ஐப் பயன்படுத்த நான் விரும்புகிறேன். இது தானாகவே React லைப்ரரிகளை வழங்குகிறது மற்றும் முன்-முனை குறியீடு மாறும்போது உலாவியைப் புதுப்பிக்கிறது. இருப்பினும், Vite-இல் பின்-முனை (backend) கருவிகள் இல்லை.

இதற்கான தீர்வு index.js (opens in a new tab)-இல் உள்ளது.

1  app.post("/server/sponsor", async (req, res) => {
2    ...
3  })
4
5  // மற்ற அனைத்தையும் Vite கையாளட்டும்
6  const vite = await createViteServer({
7    server: { middlewareMode: true }
8  })
9
10  app.use(vite.middlewares)

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

1  app.post("/server/sponsor", async (req, res) => {
2    try {
3      const signed = req.body
4
5      const txHash = await sepoliaClient.writeContract({
6        address: greeterAddr,
7        abi: greeterABI,
8        functionName: 'sponsoredSetGreeting',
9        args: [signed.req, signed.v, signed.r, signed.s],
10      })
11    } ...
12  })

இது ஒரு நிலையான viem (opens in a new tab) பிளாக்செயின் அழைப்பு மட்டுமே.

ஸ்மார்ட் ஒப்பந்தம்

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

1    constructor(string memory _greeting) {
2        greeting = _greeting;
3
4        DOMAIN_SEPARATOR = keccak256(
5            abi.encode(
6                keccak256(
7                    "EIP712Domain(string name,string version,uint256 chainId,address verifyingContract)"
8                ),
9                keccak256(bytes("Greeter")),
10                keccak256(bytes("1")),
11                block.chainid,
12                address(this)
13            )
14        );
15    }

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

1    struct GreetingRequest {
2        string greeting;
3    }

இதுவே கையொப்பமிடப்படும் கட்டமைப்பாகும். இங்கே நமக்கு ஒரு புலம் மட்டுமே உள்ளது.

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

இது கட்டமைப்பு அடையாளங்காட்டி (structure identifier) (opens in a new tab) ஆகும். இது பயனர் இடைமுகத்தில் ஒவ்வொரு முறையும் கணக்கிடப்படுகிறது.

1    function sponsoredSetGreeting(
2        GreetingRequest calldata req,
3        uint8 v,
4        bytes32 r,
5        bytes32 s
6    ) external {

இந்தச் செயல்பாடு கையொப்பமிடப்பட்ட கோரிக்கையைப் பெற்று வாழ்த்துச் செய்தியைப் புதுப்பிக்கிறது.

1        // EIP-712 டைஜஸ்ட்டைக் கணக்கிடவும்
2        bytes32 digest = keccak256(
3            abi.encodePacked(
4                "\x19\x01",
5                DOMAIN_SEPARATOR,
6                keccak256(
7                    abi.encode(
8                        GREETING_TYPEHASH,
9                        keccak256(bytes(req.greeting))
10                    )
11                )
12            )
13        );

EIP 712 (opens in a new tab)-இன் படி டைஜெஸ்ட்டை (digest) உருவாக்கவும்.

1        // கையொப்பமிட்டவரை மீட்டெடுக்கவும்
2        address signer = ecrecover(digest, v, r, s);
3        require(signer != address(0), "Invalid signature");

கையொப்பமிட்டவரின் முகவரியைப் பெற ecrecover (opens in a new tab)-ஐப் பயன்படுத்தவும். தவறான கையொப்பம் கூட செல்லுபடியாகும் முகவரியை வழங்கலாம், ஆனால் அது ஒரு சீரற்ற முகவரியாக இருக்கும் என்பதை நினைவில் கொள்ளவும்.

1        // கையொப்பமிட்டவர் அழைத்தது போலவே வாழ்த்தைச் செயல்படுத்தவும்
2        greeting = req.greeting;
3        emit SetGreeting(signer, req.greeting);
4    }

வாழ்த்துச் செய்தியைப் புதுப்பிக்கவும்.

பாதிப்புகள்

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

இந்தத் தாக்குதல்களில் சிலவற்றைப் பார்க்க, Attacks தலைப்பின் கீழ் உள்ள பட்டன்களைக் கிளிக் செய்து என்ன நடக்கிறது என்பதைப் பார்க்கவும். Invalid signature பட்டனுக்கு, பரிவர்த்தனை பதிலைப் பார்க்க சர்வர் கன்சோலைச் சரிபார்க்கவும்.

சர்வரில் சேவை மறுப்பு (Denial of service)

சர்வரில் நடக்கும் சேவை மறுப்பு (denial-of-service) (opens in a new tab) தாக்குதல் மிகவும் எளிதான தாக்குதலாகும். சர்வர் இணையத்தில் எங்கிருந்தும் கோரிக்கைகளைப் பெறுகிறது மற்றும் அந்தக் கோரிக்கைகளின் அடிப்படையில் பரிவர்த்தனைகளை அனுப்புகிறது. செல்லுபடியாகும் அல்லது செல்லுபடியாகாத பல கையொப்பங்களை வழங்குவதிலிருந்து தாக்குபவரைத் தடுப்பது எதுவுமில்லை. ஒவ்வொன்றும் ஒரு பரிவர்த்தனையை ஏற்படுத்தும். இறுதியில் கேஸ் கட்டணம் செலுத்த சர்வரில் ETH தீர்ந்துவிடும்.

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

முகவரிகளைக் கண்காணித்து, செல்லுபடியாகும் வாடிக்கையாளர்களிடமிருந்து மட்டுமே கையொப்பங்களை அனுமதிப்பது மற்றொரு தீர்வாகும்.

தவறான வாழ்த்துச் செய்தி கையொப்பங்கள்

நீங்கள் Signature for wrong greeting என்பதைக் கிளிக் செய்யும்போது, ஒரு குறிப்பிட்ட முகவரி (0xaA92c5d426430D4769c9E878C1333BDe3d689b3e) மற்றும் வாழ்த்துச் செய்திக்கு (Hello) செல்லுபடியாகும் கையொப்பத்தைச் சமர்ப்பிக்கிறீர்கள். ஆனால் அது வேறு வாழ்த்துச் செய்தியுடன் அதைச் சமர்ப்பிக்கிறது. இது ecrecover-ஐக் குழப்புகிறது, இது வாழ்த்துச் செய்தியை மாற்றுகிறது ஆனால் தவறான முகவரியைக் கொண்டுள்ளது.

இந்தச் சிக்கலைத் தீர்க்க, கையொப்பமிடப்பட்ட கட்டமைப்பில் (opens in a new tab) முகவரியைச் சேர்க்கவும். இதன் மூலம், ecrecover சீரற்ற முகவரி கையொப்பத்தில் உள்ள முகவரியுடன் பொருந்தாது, மேலும் ஸ்மார்ட் ஒப்பந்தம் செய்தியை நிராகரிக்கும்.

ரீப்ளே தாக்குதல்கள் (Replay attacks)

நீங்கள் Replay attack என்பதைக் கிளிக் செய்யும்போது, அதே "நான் 0xaA92c5d426430D4769c9E878C1333BDe3d689b3e, வாழ்த்துச் செய்தி Hello ஆக இருக்க வேண்டும் என்று நான் விரும்புகிறேன்" என்ற கையொப்பத்தை, சரியான வாழ்த்துச் செய்தியுடன் சமர்ப்பிக்கிறீர்கள். இதன் விளைவாக, முகவரி (அது உங்களுடையது அல்ல) வாழ்த்துச் செய்தியை மீண்டும் Hello ஆக மாற்றியதாக ஸ்மார்ட் ஒப்பந்தம் நம்புகிறது. இதைச் செய்வதற்கான தகவல் பரிவர்த்தனை தகவலில் (opens in a new tab) பொதுவில் கிடைக்கிறது.

இது ஒரு சிக்கலாக இருந்தால், ஒரு நான்ஸை (nonce) (opens in a new tab) சேர்ப்பது ஒரு தீர்வாகும். முகவரிகளுக்கும் எண்களுக்கும் இடையே ஒரு மேப்பிங்கை (mapping) (opens in a new tab) வைத்து, கையொப்பத்தில் ஒரு நான்ஸ் புலத்தைச் சேர்க்கவும். நான்ஸ் புலம் முகவரிக்கான மேப்பிங்குடன் பொருந்தினால், கையொப்பத்தை ஏற்றுக்கொண்டு அடுத்த முறைக்கு மேப்பிங்கை அதிகரிக்கவும். அது பொருந்தவில்லை என்றால், பரிவர்த்தனையை நிராகரிக்கவும்.

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

விடுபட்ட பிற அம்சங்கள்

ஒரு தயாரிப்பு அமைப்பில் நாம் சேர்க்கக்கூடிய கூடுதல் அம்சங்கள் உள்ளன.

பிற சர்வர்களிலிருந்து அணுகல்

தற்போது, எந்தவொரு முகவரியும் sponsorSetGreeting-ஐச் சமர்ப்பிக்க நாம் அனுமதிக்கிறோம். பரவலாக்கத்தின் நலன் கருதி, இதுவே நாம் விரும்புவதாக இருக்கலாம். அல்லது ஸ்பான்சர் செய்யப்பட்ட பரிவர்த்தனைகள் நமது சர்வர் வழியாகச் செல்வதை உறுதிசெய்ய நாம் விரும்பலாம், அப்படியானால் ஸ்மார்ட் ஒப்பந்தத்தில் msg.sender-ஐ நாம் சரிபார்ப்போம்.

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

பிழை கையாளுதல்

ஒரு பயனர் வாழ்த்துச் செய்தியைச் சமர்ப்பிக்கிறார். ஒருவேளை அது அடுத்த பிளாக்கில் புதுப்பிக்கப்படலாம். ஒருவேளை புதுப்பிக்கப்படாமலும் போகலாம். பிழைகள் கண்ணுக்குத் தெரியாது. ஒரு தயாரிப்பு அமைப்பில், பயனர் இந்த நிகழ்வுகளுக்கு இடையே வேறுபடுத்திப் பார்க்க முடியும்:

புதிய வாழ்த்துச் செய்தி இன்னும் சமர்ப்பிக்கப்படவில்லை
புதிய வாழ்த்துச் செய்தி சமர்ப்பிக்கப்பட்டுள்ளது, அது செயல்பாட்டில் உள்ளது
புதிய வாழ்த்துச் செய்தி நிராகரிக்கப்பட்டுள்ளது

முடிவுரை

இந்தக் கட்டத்தில், சில மையப்படுத்தலின் விலையில், உங்கள் dapp பயனர்களுக்கு கேஸ் இல்லாத அனுபவத்தை உங்களால் உருவாக்க முடியும்.

இருப்பினும், இது ERC-712-ஐ ஆதரிக்கும் ஸ்மார்ட் ஒப்பந்தங்களில் மட்டுமே வேலை செய்யும். எடுத்துக்காட்டாக, ஒரு ERC-20 டோக்கனை மாற்ற, ஒரு செய்திக்கு பதிலாக உரிமையாளரால் பரிவர்த்தனை கையொப்பமிடப்பட வேண்டும். இதற்கான தீர்வு கணக்கு சுருக்கம் (account abstraction) (ERC-4337) (opens in a new tab) ஆகும். இதைப் பற்றி எதிர்காலத்தில் ஒரு டுடோரியல் எழுத நம்புகிறேன்.

எனது மேலும் பல பணிகளுக்கு இங்கே பார்க்கவும் (opens in a new tab).

பக்கம் கடைசியாகப் புதுப்பிக்கப்பட்டது: 3 மார்ச், 2026