Merge pull request 0xPolygon#1565 from 0xPolygon/pos-meta-transactions-update

PoS: update meta transaction page

Author: hsutaiyu

docs/pos/concepts/transactions/meta-transactions.md

@@ -1,41 +1,21 @@
-Daily smart contract calls are at their highest, hitting around 2.5 to 3 million per day.
-dApps are starting to realize their utility but are becoming victims of their success or others’
-success due to gas fees. Not to mention, the onboarding hurdles of users and the challenges of current UX are no easy fix.
-
-## Servicing smart contracts
-
-By design, smart contracts are deterministic state machines that execute when transaction fees are
-paid to service the contract’s logic by using the network’s computational resources.
-This is accomplished by a gas-metered model on Ethereum (and Polygon).
 
 ## The current state of transacting
 
-There are limitations to this traditional transaction model on Ethereum (and other blockchains alike).
-
-A common limitation is a user not having the means to pay for gas. By default, the sender of the
-transaction acts as the payer, as these behaviors are coupled, so if a user attempts to create and send a transaction, they are responsible for the associated gas fees. Likewise, if a user builds, interacts with, or runs a dApp, the user is required to pay gas.
+The traditional transaction model on Ethereum and similar blockchains has notable limitations. One key issue is that users must pay gas fees to initiate transactions, which can be a barrier, as they often need to acquire cryptocurrency first.
 
-It is unrealistic to expect the average user to buy crypto and pay for gas to interact with an
-application. What can be done to address this is to decouple the sender of a transaction from acting as a payer, enabling the opportunity to scale transaction execution and initiate a seamless transacting
-experience.
+To address this, the transaction sender can be decoupled from the gas payer. This allows for scaling transaction execution and creating a more seamless user experience. 
 
-Instead of direct transaction execution, a middleware would exist (via a third party) to handle the gas. This is where meta transactions come in.
+By implementing middleware through a third party, gas payments can be handled separately. This is where meta transactions come in.
 
 ## What are meta transactions?
 
-Meta transactions allow anyone to interact with the blockchain. They do not require users to have
-tokens to pay for the network’s services through transaction fees. This is done by decoupling the
-sender of a transaction and the payer of gas.
+Meta transactions enable users to interact with the blockchain without needing tokens to cover transaction fees. This is achieved by decoupling the transaction sender from the gas payer.
 
-A solution that can onboard new users and helps current ones.
+In this model, the executor submits a transaction request by signing the intended action with their private key, rather than paying gas directly. The meta transaction consists of a standard Ethereum transaction augmented with additional parameters.
 
-The executor of a transaction acts as a sender. Rather than spending gas, they only create a
-transaction request by signing their intended action (the transaction parameters) with their private key. The meta transaction is a regular Ethereum transaction that includes additional parameters to craft transactions.
+The signed transaction parameters are sent to a secondary network acting as a relayer. Relayers validate transactions based on relevance to the dApp, then wrap the request into a standard transaction, paying the gas fee. The network broadcasts this transaction, and the contract unwraps it by validating the original signature, executing the action on behalf of the user.
 
-The signed transaction parameters are passed onto a secondary network, which acts as a relayer.
-While there are different schemes for this, relayers would generally choose which transactions are worth submitting by validating the transaction (e.g., being relevant to the dApp). Upon validation, the relayer will wrap the request (the signed message) into an actual transaction (which means paying the gas fee) and broadcast it to the network, where the contract unwraps the transaction by validating the original signature and executes it on behalf of the user.
-
-!!! note "The words 'meta' and 'batch' may sound analogous to some"
+!!! info "Meta transactions vs. batch transactions"
 
     To clarify: a meta transaction is different from a batch transaction, where a batch transaction is a transaction that can send multiple transactions at once and are then executed from a single sender (single nonce specified) in sequence.
 
@@ -52,11 +32,21 @@ the *sender*, the *sender* becomes more like an *intender* - the sender shows th
 
 One can imagine the capabilities of meta transactions for scaling dApps and interactions with smart contracts. Not only can a user create a gasless transaction, but they can also do so many times, and with an automation tool, meta transactions can influence the next wave of applications for practical use cases. Meta transactions enable real utility in smart contract logic, which is often limited because of gas fees and the interactions required on-chain.
 
-### Example with voting
+Let's look at a few scenarios highlighting how meta transactions can enhance user experience in dApps.
+
+### Voting
 
-A user wants to participate in on-chain governance, and they intend to vote for a particular outcome via a voting contract. The user would sign a message which states the user’s decision in a vote in this particular contract. Traditionally, they would need to pay a gas fee for interacting with the contract (and know how to interact with the contract), but instead, they can sign a meta transaction (off-chain) with the necessary information for their vote and pass it to a relayer which would execute the transaction on their behalf.
+A user wishing to participate in on-chain governance can vote through a voting contract by signing a message with their decision. Traditionally, they would need to pay gas fees and know how to interact with the contract directly. But in this case they sign a meta transaction containing the vote details off-chain and send it to a relayer. 
 
-The signed message gets sent to a relayer (the signed transaction params about the voting information). The relayer validates that this transaction is a priority vote, wraps the voting request into an actual transaction, pays the gas fees, and broadcasts it to the voting contract. Everything checks out on the voting contract’s end, and the vote executes on behalf of the user.
+The relayer receives the signed message, validates the priority of the vote, wraps it into a standard transaction, pays the gas fees, and submits it to the voting contract. Once validated, the contract executes the vote on behalf of the user.
+
+### Gaming
+
+In blockchain-based games, players often need to pay gas fees to perform in-game actions like trading items or upgrading characters. By using meta transactions, players can interact with the game without needing to hold ETH, making it easier for casual gamers to enjoy the experience without the hassle of managing crypto.
+
+### Minting NFTs
+
+In NFT marketplaces, users often face high gas fees when minting, buying, or selling NFTs. By utilizing meta transactions, users can create or purchase NFTs without having to manage Ether for gas. They simply sign the transaction request, and a relayer submits it on their behalf, enhancing user experience and lowering the barrier to entry for those unfamiliar with handling cryptocurrencies.
 
 ## Try 'em out
 
@@ -86,7 +76,7 @@ For any action that requires blockchain interaction,
 - The relayer interacts with the blockchain to submit user's signature to the contract. A function on the contract called `executeMetaTransaction` processes the signature and executes the requested transaction (via an internal call).
 - The relayer pays for the gas making the transaction effectively free 🤑
 
-## Integrate network agnostic transactions in your dApp
+## Example implementation
 
 - Choose between a custom simple relayer node/Biconomy.
 
@@ -272,27 +262,4 @@ biconomy
 * use the getWeb3 object to define a contract and calling the function directly
 */
 
-```
-
-Account Abstraction is a blockchain technology that enables users to utilize smart contracts as their accounts. While the default account for most users is an Externally Owned Account (EOA), which is controlled by an external private key, it requires users to have a considerable understanding of blockchain technology to use them securely. Fortunately, smart contract accounts can create superior user experiences.
-
-## Benefits
-
-Contract accounts offer numerous benefits, including:
-
-- Arbitrary verification logic: Rather than use an external private key, contract accounts can use any arbitrary signature type. This feature supports single and multi-signature verification and any signature scheme.
-- Sponsored transactions: Users can pay transaction fees in ERC-20 tokens or create their fee logic, including sponsoring transaction fees on their app.
-- Account security: Contract accounts enable social recovery and security features such as time-locks and withdraw limits.
-- Atomic multi-operations: Users can perform multiple operations simultaneously, such as trading in a single click instead of approving and swapping separately.
-
-## Using account abstraction on Polygon
-
-There are two primary ways users can use account abstraction on Polygon PoS: by sending ERC-4337 transactions or with third-party meta transaction services.
-
-### ERC-4337
-
-ERC-4337, also known is EIP-4337, brings account abstraction to the Polygon ecosystem and all EVM-compatible chains.
-
-### Meta transactions
-
-Meta transactions are bespoke third-party services for achieving account abstraction.
+```

mkdocs.yml

@@ -385,7 +385,7 @@ nav:
           - Transactions:
             - EIP-1559: pos/concepts/transactions/eip-1559.md
             - EIP-4337: pos/concepts/transactions/eip-4337.md
-            - Meta-transactions: pos/concepts/transactions/meta-transactions.md
+            - Meta transactions: pos/concepts/transactions/meta-transactions.md
   - Miden:
       - Miden: miden/index.md
       - Miden base: '!import https://github.com/0xPolygonMiden/miden-base?branch=main'