ReactJS项目中如何为合格用户分配ERC20的MINTER/BURNER角色

问题1：React端是否可以分配MINTER_ROLE/BURNER_ROLE，怎么操作？ #

完全可以，但你首先要明确一个链上权限的核心规则：只有持有DEFAULT_ADMIN_ROLE（合约部署时默认授予部署地址的管理员角色）的地址签名发起交易，才能成功调用grantRole方法给其他地址分配角色，前端没有任何办法绕过链上权限校验私自给用户加角色。

具体操作步骤如下：

• 前置准备
  • 导出你部署的ERC20合约完整ABI，确保包含AccessControl相关的grantRole、hasRole方法，以及你合约自己实现的mint、burn方法
  • React项目里接入web3交互库（ethers.js、wagmi、viem都可以，下面以最常用的ethers v6为例），完成钱包连接逻辑
• 代码实现
  1. 初始化合约实例

  import { ethers } from 'ethers'
  // 替换为你的代币合约部署地址
  const TOKEN_CONTRACT_ADDRESS = '0x_你的合约地址'
  // 替换为你的合约ABI
  const TOKEN_ABI = [/* 合约ABI数组 */]
  
  // 连接钱包后初始化可写合约实例
  const provider = new ethers.BrowserProvider(window.ethereum)
  const signer = await provider.getSigner()
  const tokenContract = new ethers.Contract(TOKEN_CONTRACT_ADDRESS, TOKEN_ABI, signer)
  

  2. 计算角色对应的bytes32值，AccessControl的角色标识是固定格式的keccak256哈希：

  const MINTER_ROLE = ethers.keccak256(ethers.toUtf8Bytes('MINTER_ROLE'))
  const BURNER_ROLE = ethers.keccak256(ethers.toUtf8Bytes('BURNER_ROLE'))
  

  3. 先做业务资格校验：你自己的业务侧（前端+后端配合，不要纯前端做校验，很容易被篡改绕过）判断用户是否满足铸造/销毁权限要求，比如完成任务、资产达标等。
  4. 资格校验通过后发起角色分配交易：

  这里必须注意：绝对不要把管理员地址的私钥硬编码在前端代码里，任何人打开浏览器控制台都能窃取私钥拿走整个合约的权限。生产环境应该把管理员私钥托管在后端签名服务里，前端只把符合资格的用户地址传给后端，后端二次校验资格后再发起grantRole交易；如果是测试环境可以手动用管理员地址连接钱包触发交易。

  // 替换为需要授权的用户钱包地址
  const targetUserAddress = '0x_用户地址'
  // 发起分配铸造角色的交易
  const grantTx = await tokenContract.grantRole(MINTER_ROLE, targetUserAddress)
  // 等待链上交易确认
  await grantTx.wait()
  // 校验授权结果
  const checkRole = await tokenContract.hasRole(MINTER_ROLE, targetUserAddress)
  console.log('用户铸造权限授权结果:', checkRole)
  

  分配BURNER_ROLE的逻辑完全一致，只需要把角色常量替换成BURNER_ROLE即可。

问题2：有没有更适合SLP/VIS类场景的铸造资格校验方案？ #

如果你要做的是类似链游代币那种、用户满足业务条件就可以自助铸造的场景，其实每次给用户单独分配MINTER_ROLE的方案效率很低，每次授权都要付gas费，海量用户场景下成本很高，更推荐下面3种成熟方案：

• 方案1：后端签名 mint（SLP/VIS类业务最常用方案）
  不用提前给用户分配任何链上角色，只需要在合约里设置一个可信签名地址（SIGNER_ROLE），私钥托管在后端服务。用户满足业务条件后，后端用签名私钥给「用户地址、可铸造数量、签名过期时间、业务流水号」这些参数做EIP-712标准签名，前端把签名参数传到合约的mint方法里，合约只需要校验签名是可信签名地址签发、参数合法、没有被使用过，就直接允许用户铸造。这种方案不需要频繁发grantRole交易，gas成本低，业务规则调整灵活，不需要改合约逻辑。
• 方案2：纯链上资格校验
  如果你的铸造资格条件是完全可以通过链上数据判定的（比如用户持有指定NFT、用户锁仓了对应数量的平台币、用户在指定区块前完成过交互），可以直接把校验逻辑写在mint方法里，用户调用mint的时候合约直接读取链上状态判断资格，不需要后端参与，也不需要提前分配角色，完全去中心化。
• 方案3：默克尔树白名单校验
  如果是固定批次的白名单铸造活动，可以提前把所有符合资格的用户地址生成默克尔树根存在合约里，用户铸造的时候只需要提供自己地址对应的默克尔证明，合约校验证明有效就允许铸造，适合一次性活动、创世用户铸造这类场景。

内容的提问来源于stack exchange，提问作者MxG